System Description Manual 3HH13800BAAATQZZA10

System Description for FD 100/320Gbps NT and FX NT
7302 INTELLIGENT SERVICES

ACCESS MANAGER
ACCESS MANAGER FTTN
ACCESS MANAGER FX
RELEASE 6.0.01
System Description for FD 100/320Gbps NT and FX

NT
3HH-13800-BAAA-TQZZA
Issue: 10
December 2018
Nokia — Proprietary and confidential

Use pursuant to applicable agreements
NT
Nokia is a registered trademark of Nokia Corporation. Other products and company

names mentioned herein may be trademarks or tradenames of their respective
owners.
The information presented is subject to change without notice. No responsibility is
assumed for inaccuracies contained herein.
© 2016-2018 Nokia.
Contains proprietary/trade secret information which is the property of Nokia and must
not be made available to, or copied or used by anyone outside Nokia without its
written authorization. Not to be used or disclosed except in accordance with
applicable agreements.
2 3HH-13800-BAAA-TQZZA Issue: 10
NT
Table of contents
1 Preface...........................................................................................41
1.1 Scope ........................................................................................................41
1.2 Audience....................................................................................................41
1.3 Required knowledge..................................................................................41
1.4 Acronyms and initialisms ...........................................................................41
1.5 Safety information......................................................................................41
1.6 Documents ................................................................................................41
1.7 Product Naming.........................................................................................42
1.8 Special information ....................................................................................42
1.9 Release notes............................................................................................42
2 Introduction...................................................................................43
2.1 General......................................................................................................43
2.2 Supported Network Interfaces ...................................................................44
2.3 Supported User Interfaces.........................................................................45
2.4 Integrated DSL, Voice, Point-to-point Ethernet, GPON and
Universal NG-PON system........................................................................46
2.5 Document Structure...................................................................................46
3 System interface overview...........................................................47
3.1 General......................................................................................................47
3.2 Overview....................................................................................................48
3.2.1 Link transmission technology ....................................................................48
3.2.2 Transfer modes .........................................................................................49
3.2.3 Bonding .....................................................................................................50
3.3 Multi-ADSL ................................................................................................50
3.3.1 ADSL1 .......................................................................................................50
3.3.1.1 Asymmetric nature of ADSL ......................................................................51
3.3.1.2 Bidirectional transport................................................................................51
3.3.1.3 ADSL services ...........................................................................................51
3.3.1.4 Operational modes ....................................................................................52
3.3.2 ADSL2 .......................................................................................................52
3.3.3 ADSL2plus.................................................................................................54
3.3.4 Reach Extended ADSL2............................................................................54
3.4 VDSL .........................................................................................................55
3.4.1 VDSL1 .......................................................................................................55
3.4.2 VDSL2 .......................................................................................................55
3.4.2.1 VDSL2 features .........................................................................................55
3.4.2.2 VDSL2 Operational Modes........................................................................56
3.4.2.3 VDSL2 profile parameter overview............................................................56
3.5 SHDSL.......................................................................................................57
3.5.1 Regional settings .......................................................................................58
3.5.2 Payload rates.............................................................................................58
Issue: 10 3HH-13800-BAAA-TQZZA 3
NT
3.6 Ethernet .....................................................................................................58

3.6.1 Half and full duplex mode ..........................................................................59
3.6.2 Hardware Auto-negotiation........................................................................59
3.6.3 Fiber speed auto-sensing ..........................................................................60
3.6.4 Software Auto-negotiation .........................................................................61
3.7 GPON ........................................................................................................61
3.7.1 Encapsulation ............................................................................................62
3.7.2 Dynamic Bandwidth Assignment ...............................................................62
3.7.3 Delay tolerance..........................................................................................62
3.7.4 Forward Error Correction...........................................................................62
3.7.5 OMCI .........................................................................................................62
3.8 TWDM-PON ..............................................................................................63
3.8.1 Encapsulation ............................................................................................63
3.8.2 Dynamic Bandwidth Assignment ...............................................................64
3.8.3 Delay tolerance..........................................................................................64
3.8.4 Forward Error Correction...........................................................................64
3.8.5 OMCI .........................................................................................................64
3.9 Inverse multiplexing for ATM .....................................................................64
3.10 ATM/PTM bonding.....................................................................................65
3.10.1 ATM bonding .............................................................................................65
3.10.2 PTM bonding .............................................................................................65
3.11 Overview of ISAM Voice interfaces ...........................................................66
3.11.1 POTS.........................................................................................................66
3.11.2 ISDN BA ....................................................................................................66
3.12 E1 TDM Interface ......................................................................................67
3.13 Overview of ONU Based UNI and Service Interfaces ...............................67
3.13.1 Ethernet UNIs ............................................................................................68
3.13.2 VDSL UNIs ................................................................................................68
3.13.3 DS1/E1 UNIs in CES Encapsulation .........................................................68
3.13.4 POTS UNIs in VoIP ...................................................................................69
3.13.5 RF Video....................................................................................................69
3.14 Overview of ISAM support for remote management of third-party
equipment..................................................................................................69
3.14.1 Purpose .....................................................................................................69
3.14.2 Assumptions made on third-party equipment management traffic ............70
3.14.3 Stand-alone ISAM with NT functions.........................................................70
3.14.3.1 Physical interface ......................................................................................70
3.14.3.2 Third-party management traffic handling and security ..............................70
3.14.4 Remote LT equipment without NT functions .............................................71
3.14.5 Third-party management traffic handling and security ..............................71
4 Failure protection and redundancy provisions in ISAM ...........73
4.1 Overview....................................................................................................73
4.1.1 Redundancy aspects .................................................................................73
4.1.1.1 Relation between essential and redundant resources...............................73
4.1.1.2 Operational mode of the additional redundant resources..........................74
4.1.1.3 The scope of the protection - the impact of a failure .................................75
4.1.1.4 The average duration of an outage - time to repair ...................................75
4.1.1.5 The number of simultaneous failures that have to be coped with .............76
4.1.2 Redundancy provision ...............................................................................76
NT
4.1.2.1 Redundancy on FD 100Gbps/320Gbps NT and FX NT systems ..............76

4.2 ISAM single shelf configurations ...............................................................77
4.2.1 Single NT...................................................................................................78
4.2.1.1 External link protection: active/standby NT links .......................................78
4.2.1.2 External link protection: Link aggregation..................................................79
4.2.2 Single NT, with NTIO.................................................................................79
4.2.3 Dual NT (loadsharing), no NTIO................................................................80
4.2.3.1 NT equipment protection with distributed external links ............................80
4.2.3.2 NT equipment protection with distributed external links (load
aggregation) ..............................................................................................82
4.2.4 Dual NT, with NTIO operating in Active/Standby mode.............................83
4.2.5 Dual NT, with NTIO operating in Active/Active mode ................................84
4.2.6 LT Loadsharing..........................................................................................85
4.3 ISAM subtending system protection ..........................................................85
4.4 Failure protection at layer 3 .......................................................................88
4.5 Subscriber interface redundancy...............................................................89
4.5.1 Ethernet link protection..............................................................................89
4.5.2 PON Link Protection ..................................................................................91
4.5.3 Protection via ONU Wavelength Mobility on TWDM-PON ........................93
5 Management..................................................................................97
5.1 Overview....................................................................................................97
5.2 Management interfaces .............................................................................98
5.2.1 SNMP ........................................................................................................99
5.2.1.1 SNMPv3 ..................................................................................................100
5.2.2 TL1 ..........................................................................................................101
5.2.3 CLI ...........................................................................................................102
5.2.4 xFTP ........................................................................................................102
5.2.4.1 File Transfer Protocols ............................................................................102
5.2.4.2 External xFTP servers .............................................................................103
5.2.4.3 xFTP Protocol selection...........................................................................104
5.2.5 xNTP........................................................................................................104
5.2.5.1 SNTP Client.............................................................................................104
5.2.5.2 NTP Client ...............................................................................................105
5.2.5.3 Manual setting .........................................................................................105
5.2.5.4 Time zone offset ......................................................................................106
5.2.5.5 SNTP Server towards ONT/MDU ............................................................106
5.2.5.6 Additional notes .......................................................................................106
5.2.6 SSH .........................................................................................................107
5.2.7 System logging ........................................................................................108
5.2.7.1 File sets ...................................................................................................108
5.2.7.2 Configuring system logs ..........................................................................108
5.2.7.3 System log filters .....................................................................................109
5.2.7.4 Operator access to the system logs ........................................................110
5.2.7.5 Viewing and monitoring system logs .......................................................111
5.3 Management interfaces security..............................................................111
5.3.1 Management interfaces ...........................................................................111
5.3.2 Encryption and authentication .................................................................112
5.3.3 Security configuration ..............................................................................112
5.3.4 Default username and password.............................................................112
NT
5.3.5 Trace and Debug interface ......................................................................113

5.4 Management access models...................................................................113
5.4.1 Introduction..............................................................................................113
5.4.2 Management via Layer 3 SAP (IES SAP) ...............................................114
5.4.2.1 All the management plane packets are passing via a dedicated
external Management v-VPLS (VLAN)....................................................114
5.4.2.2 There is no explicit external management v-VPLS (VLAN).....................115
5.4.3 Management via an IP interface directly connected to a network
port ..........................................................................................................116
5.4.4 IPv6 Management ...................................................................................118
5.5 Counters and statistics ............................................................................118
5.6 Alarm management .................................................................................119
5.6.1 Alarm categories and definition ...............................................................119
5.6.2 Alarm severity..........................................................................................120
5.6.3 Alarm lists and logs .................................................................................121
5.6.4 Current and snapshot alarm lists.............................................................122
5.6.5 Alarm severity delta logging list ...............................................................122
5.6.6 Alarm clearing..........................................................................................122
5.6.7 Alarm filters..............................................................................................123
5.6.8 Programmable alarm filters .....................................................................123
5.6.8.1 Temporal and spatial alarm filters ...........................................................123
5.6.8.2 Configuring programmable alarm filters and derived alarms...................126
5.6.8.3 Alarm reporting ........................................................................................126
5.6.9 External alarms profiles ...........................................................................127
5.6.10 ONT Type specific alarms .......................................................................127
5.7 Software and database management......................................................127
5.7.1 OSWP and databases .............................................................................128
5.7.2 Software upgrade and migration .............................................................128
5.7.3 Backup and restore .................................................................................130
5.7.4 Active load ...............................................................................................131
5.7.5 Voice service management .....................................................................132
5.8 Equipment monitoring..............................................................................132
5.8.1 NT & LT CPU load...................................................................................132
5.8.2 NT & LT memory usage ..........................................................................133
5.8.3 Thermal sensor data................................................................................133
5.9 Zero Touch Provisioning..........................................................................134
5.9.1 Introduction..............................................................................................134
5.9.2 IP connectivity through DHCP .................................................................135
5.9.3 Downloading and executing turn-up config file........................................135
5.9.4 AMS Supervision and Connectivity test...................................................135
6 Line testing features...................................................................137
6.1 Overview..................................................................................................137
6.2 Single-Ended Line Testing ......................................................................139
6.2.1 SELT support...........................................................................................140
6.2.2 SELT measurements...............................................................................140
6.3 Dual-ended line testing............................................................................140
6.3.1 DELT support ..........................................................................................141
6.3.2 DELT measurements...............................................................................141
6.4 Metallic-Ended Line Testing ....................................................................141
NT
6.4.1 MELT support ..........................................................................................142

6.4.2 MELT measurements ..............................................................................142
6.4.3 MELT status and increased robustness ..................................................145
6.5 ATM F5....................................................................................................145
6.6 Link Related Ethernet OAM.....................................................................145
6.6.1 Introduction..............................................................................................145
6.6.2 General description .................................................................................146
6.6.3 Link-Related Ethernet OAM procedures..................................................146
6.6.3.1 Discovery.................................................................................................146
6.6.3.2 Link monitoring ........................................................................................147
6.6.3.3 Remote failure indication .........................................................................147
6.6.3.4 Remote Loopback ...................................................................................147
6.7 Narrowband Line Testing ........................................................................148
6.7.1 NBLT support on POTS...........................................................................148
6.7.1.1 NBLT type categories ..............................................................................150
6.7.1.2 Group Test...............................................................................................151
6.7.1.3 Busy-Overwrite TRUE/FALSE (SIP Integrated Voice Service only)........152
6.7.1.4 Test-Access ON/OFF (SIP Integrated Voice Service only) .....................153
6.7.1.5 Enhanced NBLT test result reporting (SIP Integrated Voice Service
only):........................................................................................................153
6.7.1.6 Forced Ringing ........................................................................................153
6.7.1.7 Diagnosis Call..........................................................................................154
6.7.2 H.248: NBLT support on ISDN BRA........................................................155
6.7.2.1 NBLT type categories ..............................................................................155
6.7.2.2 Group Test...............................................................................................156
6.7.3 SIP: NBLT support on ISDN PRA E1 interface .......................................156
6.7.4 SIP: NBLT support on CAS-R2 E1 interface ...........................................157
6.7.5 Extended Test modes..............................................................................157
6.7.6 Enhanced NBLT result reporting (SIP based VoIP service only) ............158
6.8 SFP diagnostics.......................................................................................158
6.9 Embedded OTDR ....................................................................................158
7 Network timing reference support in ISAM ..............................161
7.1 Introduction..............................................................................................161
7.1.1 Scope ......................................................................................................161
7.1.2 Applications as driver for specific clock or NTR and ‘Phase and
ToD’ requirements ...................................................................................161
7.1.3 Overview of NTR support on ISAM .........................................................164
7.2 ISAM clock system and NTR extraction ..................................................167
7.2.1 High level description of the external port selection for NTR...................167
7.2.2 Possible External NTR sources...............................................................168
7.2.3 Single NT clock operation........................................................................169
7.2.4 Clock protection: Overview......................................................................170
7.2.5 Clock protection: External NTR source protection...................................170
7.2.6 Clock protection: NT redundancy ............................................................172
7.2.7 Detailed behavior of internal system NTR ...............................................172
7.2.8 NTR management ...................................................................................175
7.2.8.1 Configuration: external NTR clock source priority list..............................175
7.2.8.2 Configuration: SSU/BITS input interface(s) .............................................175
7.2.8.3 Configuration: AIS sensitivity...................................................................175
NT
7.2.8.4 Configuration: Synchronous Ethernet input interface(s)..........................176

7.2.8.5 Configuration: IEEE1588 .........................................................................176
7.2.8.6 Configuration: NTR Switching Mode .......................................................176
7.2.8.7 Configuration: enabling of Synchronization Status Messaging
(SSM) ......................................................................................................177
7.2.8.8 Configuration: forcing selection of the internal system NTR clock ..........178
7.2.8.9 Status: nominated NTR clock status .......................................................178
7.3 Downstream NTR clock distribution ........................................................178
7.4 Time phase and ToD support ..................................................................180
7.4.1 Overview of Time Phase and ToD support on ISAM...............................180
7.4.2 ISAM clock system and time phase/ToD extraction ................................181
7.4.2.1 One or more PTP clock sources per NT..................................................181
7.4.2.2 One 1PPS+ToD source per NT...............................................................183
7.4.3 Clock protection.......................................................................................183
7.4.4 ToD synchronization management..........................................................184
7.4.4.1 The external ToD source to be used: ......................................................184
7.4.4.2 SyncE/BITS as backup of ToD source ....................................................184
7.4.4.3 Clock DataSet..........................................................................................185
7.4.4.4 IEEE1588v2 management.......................................................................186
7.5 Applicable standards ...............................................................................188
8 ADSL/VDSL features ..................................................................191
8.1 Overview..................................................................................................191
8.2 Configurable impulse noise protection ....................................................193
8.2.1 Reed-Solomon.........................................................................................194
8.2.2 Interleaving ..............................................................................................194
8.3 RFI Notching............................................................................................195
8.4 Low-power modes ...................................................................................195
8.4.1 L2 low-power mode .................................................................................195
8.4.2 L3 idle mode ............................................................................................196
8.5 Seamless rate adaptation........................................................................197
8.6 Upstream power back-off ........................................................................198
8.6.1 UPBO policing .........................................................................................199
8.6.2 Equal RXPSD UPBO...............................................................................199
8.6.3 Equal FEXT UPBO ..................................................................................199
8.7 Downstream power back-off....................................................................200
8.8 Impulse noise monitor .............................................................................201
8.9 Virtual noise.............................................................................................202
8.10 Physical Layer Retransmission (G.INP) ..................................................203
8.11 Per-line configuration overrule.................................................................204
8.12 Configurable US/ DS memory split..........................................................206
8.13 Vectoring .................................................................................................206
8.14 Fall-back configuration for vectoring........................................................210
8.15 Save Our Showtime (SOS)......................................................................211
8.16 VDSL2 35b ..............................................................................................212
8.17 VDSL2-LR ...............................................................................................213
9 ADSL/VDSL Bonding..................................................................215
9.1 Overview..................................................................................................215
9.2 Bonding levels .........................................................................................216
NT
9.3 Bonding group configuration....................................................................216

9.4 Bonding group initialization......................................................................216
9.4.1 Bonding group initialization when operating in init mode 1......................216
9.4.2 Bonding group initialization when operating in init mode 2......................217
9.5 Interoperability with non-bonding capable CPE.......................................218
9.6 Delay equalization in IFEC mode ............................................................218
10 GPON Network Architecture......................................................219
10.1 Introduction: GPON Network ...................................................................219
10.2 GPON Network Architecture....................................................................220
10.2.1 Standards ................................................................................................221
10.3 GPON Implementation of ISAM...............................................................222
10.3.1 Transmission Convergence Layer - Multiplexing Architecture ................222
10.3.2 Transmission Convergence Layer - GPON Media Access Control .........224
10.3.3 Transmission Convergence Layer - Upstream and Downstream
Frames ....................................................................................................224
10.3.4 Transmission Convergence Layer - GEM Encapsulation of Ethernet
Packets....................................................................................................225
10.3.5 Dynamic Bandwidth Assignment .............................................................226
10.3.6 Forward Error Correction.........................................................................226
10.3.7 Delay Tolerance ......................................................................................227
10.3.8 Security....................................................................................................227
10.3.9 ONU Ranging and Discovery ..................................................................227
10.3.9.1 Concurrent Use of Activation/Ranging Methods:.....................................228
10.3.9.2 SLID/LOID-Serial_Number Bundling and Anti Snooping Function:.........228
10.3.9.3 Delayed SW Activation Method ...............................................................229
10.3.10 ONU Activation ........................................................................................229
10.3.11 OMCI .......................................................................................................230
10.3.12 Transmission Convergence Layer Performance Monitoring ...................230
10.3.13 Rogue ONT Detection and Defense Mechanism ....................................230
10.3.13.1 On Demand ON/OFF Test.......................................................................231
10.3.13.2 On-Demand Pattern Test ........................................................................231
10.3.13.3 Background Pattern Tests .......................................................................231
10.3.13.4 Background On/Off Test..........................................................................232
10.3.14 Automatic RF Service Shutdown.............................................................232
10.4 V-OLT GPON Functions..........................................................................232
10.4.1 Radio Frequency Video Signal Distribution .............................................232
10.4.2 RF Video Services...................................................................................233
10.5 Protection ................................................................................................233
10.6 ONU Functions ........................................................................................233
11 ISAM Support for the GPON ONU .............................................235
11.1 Introduction..............................................................................................235
11.1.1 P-OLTs and V-OLTs................................................................................236
11.1.2 GPON ONUs ...........................................................................................236
11.1.3 Indoor ONU .............................................................................................237
11.1.4 Outdoor ONU...........................................................................................237
11.1.5 MDU ONU ...............................................................................................237
11.1.6 Business ONUs .......................................................................................237
NT
12 Universal Next Generation PON Network Architecture...........239

12.1 Introduction..............................................................................................239
12.2 Universal NG-PON Network Architecture................................................241
12.3 Universal NG-PON Implementation of ISAM...........................................243
12.3.1 Transmission Convergence Layer...........................................................243
12.3.1.1 Media Access Control..............................................................................244
12.3.1.2 Upstream and Downstream Frames........................................................245
12.3.1.3 XGEM Encapsulation of Ethernet Packets ..............................................247
12.3.2 Dynamic Bandwidth Assignment .............................................................248
12.3.3 Forward Error Correction.........................................................................249
12.3.4 Delay Tolerance ......................................................................................249
12.3.5 Security....................................................................................................250
12.3.5.1 Authentication..........................................................................................250
12.3.5.2 Payload encryption ..................................................................................250
12.3.6 ONU Ranging and Discovery ..................................................................251
12.3.7 ONU Activation ........................................................................................251
12.3.8 ONU wavelength (re-)assignment (NG-PON2 specific) ..........................252
12.3.9 Transmission Convergence Layer Performance Monitoring ...................253
12.3.10 Power Management Mode ......................................................................253
12.4 OMCI .......................................................................................................254
12.5 Time of Day .............................................................................................254
12.6 Protection on Next Generation PON .......................................................255
12.7 ONU Functions ........................................................................................255
12.8 Wavelength Multiplexer Functions...........................................................255
12.9 Coexistence Element Functions ..............................................................255
12.10 Deployment models for Universal NG-PON ............................................256
13 Integrated Voice Service ............................................................257
13.1 Introduction..............................................................................................258
13.2 Supported Features per Product .............................................................259
13.3 Overall network topology .........................................................................261
13.3.1 Megaco Integrated Voice Service in a NGVN network............................261
13.3.2 SIP Integrated Voice Service in a TISPAN-compliant NGN-IMS
network ....................................................................................................264
13.3.3 SIP Integrated Voice Service in a non-IMS-compliant network ...............267
13.3.4 CESoPSN (Cicuit Emulation Service over Packet Switched
Network) ..................................................................................................268
13.4 Voice cluster topology .............................................................................270
13.4.1 H.248 Integrated Voice Service...............................................................270
13.4.2 SIP Integrated Voice Service...................................................................274
13.5 Product Definition and Dimensioning ......................................................274
13.5.1 H.248 .......................................................................................................274
13.5.2 SIP...........................................................................................................274
13.5.3 Mix of SIP POTS and H.248 ISDN BRA..................................................275
13.5.4 Mix of SIP POTS/ISDN PRA/CAS R2 and H.248 POTS .........................275
13.6 Traffic types and forwarding ....................................................................276
13.6.1 Traffic Types............................................................................................276
13.6.1.1 H.248 Integrated Voice Service...............................................................276
13.6.1.2 SIP Integrated Voice Service...................................................................277
13.6.2 Traffic forwarding.....................................................................................277
NT
13.6.2.1 User-to-user communication ...................................................................278

13.6.2.2 Layer 4 forwarding...................................................................................278
13.6.2.3 H.248 Integrated Voice Service : Conceptual Forwarding models ..........280
13.6.2.4 SIP Integrated Voice Service : Conceptual Forwarding models..............282
13.6.2.5 Subtending model....................................................................................286
13.6.2.6 Megaco Integrated Voice Service as switching device............................288
13.6.2.7 H.248 Integrated Voice Service as routing device...................................294
13.6.2.8 SIP Integrated Voice Service as switching device...................................301
13.6.2.9 SIP Integrated Voice Service as routing device ......................................305
13.7 Layer 2/layer 3 addressing topologies.....................................................310
13.7.1 H.248 Integrated Voice Service embedded in ISAM switching
device ......................................................................................................310
13.7.1.1 Distinct VLAN topology............................................................................310
13.7.1.2 Shared VLAN topology ............................................................................314
13.7.1.3 Private VLAN Topology ...........................................................................317
13.7.2 H.248 Integrated Voice Service embedded in ISAM routing device........321
13.7.2.1 Distinct VLAN / IP address topology........................................................321
13.7.2.2 Shared VLAN / IP address topology........................................................325
13.7.2.3 Private VLAN / IP address reduction topology ........................................328
13.7.3 SIP Integrated Voice Service embedded in ISAM switching device........332
13.7.3.1 Distributed IP address Architecture - Shared VLAN topology .................332
13.7.3.2 Distributed IP address Architecture - distinct VLAN topology..................333
13.7.3.3 Centralized IP address Architecture - distinct VLAN topology.................335
13.7.3.4 Centralized IP address Architecture - shared VLAN topology.................337
13.7.4 SIP Integrated Voice Service embedded in ISAM routing device............338
13.7.4.1 Distributed IP address Architecture - shared VLAN/IP address
topology ...................................................................................................339
13.7.4.2 Distributed IP address Architecture - Distinct VLAN/IP address
topology ...................................................................................................340
13.7.4.3 Centralized IP address Architecture - distinct VLAN/IP adress
topology ...................................................................................................343
13.7.4.4 Centralized IP address Architecture - shared VLAN/IP address
topology ...................................................................................................345
13.8 Protocol stacks ........................................................................................346
13.8.1 H.248 Integrated Voice Service Signaling Protocol Stack.......................346
13.8.2 SIP Integrated Voice Service Signaling Protocol Stack (Switching /
Routing) ...................................................................................................352
13.8.3 Media protocol stack................................................................................355
13.9 Management interface.............................................................................355
13.9.1.1 CLI / SNMP Interface...............................................................................356
13.9.1.2 Batch configuration CLI command support for subscriber
management............................................................................................356
13.9.3 CESoPSN Service...................................................................................357
13.9.4 CDE Profile..............................................................................................358
13.9.5 SIP Service Profile...................................................................................359
NT
13.10 Permanent data storage ..........................................................................360

13.10.1 Megaco Integrated Voice Service............................................................360
13.10.3 CESoPSN Service...................................................................................360
13.11 Management model.................................................................................360
13.11.1.1 H.248 Protocol and Network Management Model...................................362
13.11.1.2 VoIP Database Model..............................................................................363
13.11.1.3 VoIP Narrowband Line Test Management Model....................................363
13.11.2.1 SIP Protocol and Network Management Model.......................................367
13.11.2.2 Performance Monitoring Management Model .........................................368
13.11.2.3 CDE File Management Model .................................................................369
13.11.2.4 Narrowband Line Test Management Model ............................................370
13.11.2.5 IF-MIB (SIP POTS Terminations) ............................................................370
13.11.3 CESoPSN Service...................................................................................371
13.11.3.1 CESoPSN conceptual Management Model.............................................372
13.12 SIP Integrated Voice Service: Shared Line Connection ..........................372
13.13 H.248 Integrated Voice Service: Shared Line Connection ......................373
13.14 Number Manipulation Rules ....................................................................374
13.14.1 SIP POTS Integrated Voice Service........................................................375
13.14.2 SIP ISDN PRA Integrated Voice Service.................................................375
13.14.3 SIP CAS R2 Integrated Voice Service.....................................................377
13.15 Reliability, Equipment / Connectivity / Overload Protection.....................378
13.15.1 Equipment Protection ..............................................................................378
13.15.1.1 H.248 Integrated Voice Service: Media Gateway redundancy ................378
13.15.2 Connectivity Protection............................................................................379
13.15.2.1 H.248 Integrated Voice Service: Network Connectivity Protection..........379
13.15.2.2 Megaco Integrated Voice Service: Redundancy .....................................379
13.15.2.3 LOCAL and GEO-Redundancy (POTS and ISDN BA)............................381
13.15.2.4 External ESA-MGC (Emergency Stand Alone) Redundancy ..................386
13.15.2.5 Co-Located ESA-MGC (Emergency Stand Alone) Redundancy.............387
13.15.3 SIP POTS Integrated Voice Service: Redundancy..................................388
13.15.3.1 SIP Server Redundancy and SIP Server Fail-Over / Fail-Back...............388
13.15.3.2 GEO Redundancy and GEO Fail-Over / Fail-Back..................................393
13.15.3.3 ESA (Emergency Stand Alone) Redundancy and ESA Fail-Over /
Fail-Back..................................................................................................395
13.15.3.4 LSA (Local Stand Alone) SIP Server and LSA Fail-Over / Fail-Back
for SIP POTS and SIP ISDN PRA voice service .....................................396
13.15.3.5 SIP Integrated Voice Service: NT switch-over interaction with SIP
server Redundancy .................................................................................401
13.15.4 SIP ISDN PRA / CAS R2 Integrated Voice Service: Redundancy ..........401
13.15.4.1 SIP Server Fail-over ................................................................................401
13.15.4.2 SIP Server Fail-over and Session-Refresh..............................................402
13.15.4.3 SIP Server Fail-back................................................................................402
13.15.4.4 SIP Server Fail-back and Session-Refresh .............................................403
13.15.4.5 Deliberate Update....................................................................................403
13.15.4.6 SOS SIP Server Fail-over........................................................................403
13.15.4.7 SOS SIP Server Fail-over and Session-Refresh .....................................404
NT
13.15.4.8 SOS SIP Server Fail-back .......................................................................404

13.15.4.9 SOS SIP Server Fail-back and Session-Refresh ....................................405
13.15.4.10 GEO Fail-over..........................................................................................405
13.15.4.11 GEO Fail-back .........................................................................................406
13.15.5 Overload Protection.................................................................................406
13.15.5.1 H.248 Integrated Voice Service: MG (Voice access node Server)
Overload Protection.................................................................................406
13.15.5.2 SIP Integrated Voice Service: SIP Overload Handling ............................408
13.16 Multiple Voice Service Gateway ..............................................................410
13.17 Licensed Voice Service Features ............................................................412
13.17.1 Multiple Voice Service Gateway ..............................................................412
13.17.2 Local Stand Alone Server & Emergency Call Service. ............................412
13.18 Combo DSL - Naked DSL Line................................................................413
13.19 Quality of Service ....................................................................................413
13.20 DHCP Interworking..................................................................................414
13.21 DNS interworking.....................................................................................415
13.21.2.1 A Resource record look-up......................................................................416
13.21.2.2 Time To Live............................................................................................416
13.21.2.3 DNS server selection...............................................................................417
13.22 BITS Support ...........................................................................................418
13.23 Narrowband Line Testing ........................................................................418
13.23.3 SIP ISDN PRA Integrated Voice Service.................................................418
13.23.4 SIP CAS R2 Integrated Voice Service.....................................................418
13.24 Subscriber Line Showering......................................................................419
13.25 Lawful Intercept .......................................................................................419
13.25.1 Overall Lawful Intercept strategy .............................................................419
13.25.2 Megaco Integrated Voice Service: External Packet Forwarding
(EPF) .......................................................................................................420
13.25.3 SIP Integrated Voice Service: External Packet Forwarding (EPF) ..........422
13.26 Voice Traffic Mirroring .............................................................................425
13.27 Integrated Voice Service migration..........................................................426
13.27.1 Software Upgrade / Off-line Software Migration ......................................426
13.27.1.1 H.248 Integrated Voice Service...............................................................426
13.27.1.2 SIP Integrated Voice Service migration...................................................430
13.27.2 H.248 to SIP functional Migration ............................................................430
13.27.3 Switching to Routing functional Migration................................................431
14 Integrated Narrowband Support................................................433
14.1 Introduction..............................................................................................433
14.2 Coverage .................................................................................................434
NT
14.3 MEGACO Feature Portfolio .....................................................................434

14.3.1 Registration .............................................................................................434
14.3.2 Basic Call Setup ......................................................................................435
14.3.3 DTMF RFC 2833 Processing ..................................................................438
14.3.4 Supplementary services ..........................................................................445
14.3.5 Combo-Shelf Application .........................................................................448
14.3.6 Performance monitoring ..........................................................................448
14.3.6.1 Voice Qos (packet loss, jitter, loop delay) Metrics Alarm Reporting........449
14.4 SIP Integrated Voice Service - POTS Feature Portfolio ..........................450
14.4.1 Transport Protocols .................................................................................450
14.4.2 SIP User Authentication ..........................................................................452
14.4.3 Registration .............................................................................................452
14.4.4 Basic Call.................................................................................................453
14.4.4.1 General....................................................................................................453
14.4.4.2 Outgoing call............................................................................................457
14.4.4.3 Incoming Call...........................................................................................458
14.4.4.4 Mid Call....................................................................................................458
14.4.4.5 Direct Collect Call ....................................................................................459
14.4.4.6 Media.......................................................................................................459
14.4.4.7 Session refresh........................................................................................459
14.4.4.8 Overlap dialing.........................................................................................459
14.4.4.9 Metering...................................................................................................460
14.4.5 Fax and modem.......................................................................................460
14.4.6 Supplementary services ..........................................................................462
14.4.6.1 General....................................................................................................463
14.4.6.2 Call Forwarding Notification:....................................................................464
14.4.6.3 Malicious Call Identification extended with below Malicious Call
Tracking :.................................................................................................465
14.4.6.4 Tightly Coupled Model.............................................................................465
14.4.6.5 Loosely Coupled Model ...........................................................................466
14.4.6.6 Additional Info..........................................................................................469
14.4.7 Release Control.......................................................................................470
14.4.8 SMS.........................................................................................................470
14.4.9 PANI Header ...........................................................................................470
14.4.10 Dial Tone Management ...........................................................................472
14.4.11 Flash-hook handling for SIP termination with or without
supplementary service.............................................................................472
14.4.12 Last Dialed Number List ..........................................................................472
14.4.13 Message Waiting Indication upon off-hook..............................................474
14.4.14 Performance Monitoring ..........................................................................474
14.4.14.1 History Interval framework.......................................................................474
14.4.14.2 Short-Lived Framework ...........................................................................481
14.4.15 Validating Origin of SIP request ..............................................................482
14.4.16 SIP POTS Termination States.................................................................483
14.4.17 Self Ringing Service ................................................................................485
14.5 SIP Integrated Voice Service - ISDN PRA ..............................................486
14.5.1 General....................................................................................................486
14.5.2 ISDN PRA User Connection Modes ........................................................487
14.5.3 Transport Protocols .................................................................................492
NT
14.5.4 Management Interface.............................................................................494

14.5.6 Implicit Registration (Direct Dial In service and No Direct Dial In
Service) ...................................................................................................495
14.5.7 Explicit Registration .................................................................................497
14.5.8 Dialing Mode............................................................................................498
14.5.9 Digit Analysis ...........................................................................................498
14.5.10 Number Screening and Mapping.............................................................499
14.5.11 Basic Call (Originating and Terminating).................................................499
14.5.11.1 Codecs ....................................................................................................500
14.5.11.2 Echo Cancellation....................................................................................500
14.5.11.3 Adaptive Jitter Buffer ...............................................................................500
14.5.11.4 Fax and Modem.......................................................................................500
14.5.12 Supplementary Services..........................................................................501
14.5.13 PANI header ............................................................................................502
14.6 SIP Integrated Voice Service - CAS R2 ..................................................504
14.6.1 General....................................................................................................504
14.6.2 Management Interface.............................................................................507
14.6.4 Registration (Direct Dial In service and No Direct Dial In Service)..........509
14.6.5 SIP Invite .................................................................................................511
14.6.6 Dialing Mode............................................................................................511
14.6.7 Basic Call (Originating and Terminating).................................................512
14.6.7.1 Supported R2 Line Signals......................................................................512
14.6.7.2 Supported R2 Interregister Signals (Forward).........................................513
14.6.7.3 Supported R2 Interregister Signals (Backward) ......................................514
14.6.7.4 Supported R2 Timers ..............................................................................516
14.6.7.5 Codecs ....................................................................................................517
14.6.7.6 Echo Cancellation....................................................................................517
14.6.7.7 Adaptive Jitter Buffer ...............................................................................517
14.6.7.8 Fax and Modem.......................................................................................517
14.6.8 Supplementary Services..........................................................................518
14.6.9 PANI header ............................................................................................519
14.7 CESoPSN Service...................................................................................520
14.8 Voice Service related alarms...................................................................522
14.9 Compliance to standards.........................................................................522
14.9.1 Megaco....................................................................................................522
14.9.2 SIP...........................................................................................................523
15 Layer 2 forwarding......................................................................525
15.1 Introduction..............................................................................................525
15.2 The concept of Virtual LAN (VLAN).........................................................526
15.2.1 VLAN tagging in IEEE 802.1q .................................................................526
15.2.2 VLAN Tagging as a Means to support Virtual LAN (VLAN).....................526
15.3 The ISAM is an Access Device ...............................................................527
15.3.1 Generic L2 Forwarder..............................................................................529
15.3.2 Usage of VLANs in an “1:1” and “1:N” Access Network Deployment......531
15.3.3 Dual-tag L2 Forwarders...........................................................................532
NT
15.3.4 Multi-service Configurations on the Access Link .....................................533

15.3.5 The VLAN port: Supporting Concept for Multiservice Access .................535
15.3.6 Configuration Scenario Example for Multiservice Deployment................539
15.3.7 Use of MPLS encapsulation in the ISAM generic forwarding model .......542
15.3.8 ISAM support for VULA operations .........................................................542
15.4 ISAM Internal Architecture.......................................................................544
15.4.1 L2 forwarding on the NT board and the LT boards..................................544
15.4.2 L2 forwarding on for VULA operations ....................................................549
15.4.3 Detailed configuration models .................................................................552
15.4.3.1 iBridge Configuration Model with Direct Network VLAN
Encapsulation ..........................................................................................552
15.4.3.2 VLAN Cross-connect Configuration Model with Direct Network
VLAN Encapsulation................................................................................553
15.4.3.3 iBridge or VLAN Cross-connect Configuration Model with MPLS
Pseudo-wire Encapsulation .....................................................................554
15.4.3.4 VLAN Cross-connect Configuration Model with MPLS Pseudo-wire
Encapsulation and E-PIPE ......................................................................555
15.4.3.5 Full Bridge Emulation for Business Customer .........................................555
15.4.3.6 Forwarding models and VULA uplink operations ....................................556
15.5 Subscriber interface stack on the LT board.............................................559
15.5.1 Frame Encapsulation on PVCs ...............................................................559
15.5.1.1 Auto-detect encapsulation possibilities....................................................560
15.5.2 Attaching subscribers to iBridges and VLAN cross-connect
forwarders................................................................................................561
15.5.3 Support for Jumbo Frames......................................................................562
15.6 iBridges....................................................................................................562
15.6.1 General considerations on iBridges.........................................................564
15.6.1.1 DHCP option 82.......................................................................................564
15.6.1.2 Network side and subscriber side............................................................565
15.6.1.3 Prevention of broadcast problems...........................................................565
15.6.1.4 Multicast Protocols forwarding control.....................................................566
15.6.1.5 IPv4 multicast traffic control.....................................................................567
15.6.1.6 IPv6 multicast traffic control.....................................................................567
15.6.1.7 Ethernet multicast traffic control ..............................................................568
15.6.1.8 Protocol Specific Multicast traffic control .................................................568
15.6.1.9 Upstream Frame types accepted by iBridges..........................................569
15.6.1.10 iBridge Deployment .................................................................................569
15.6.1.11 Hub-ISAM LT NNI iBridge deployment example .....................................570
15.6.2 MAC learning...........................................................................................571
15.6.2.1 MAC address learning on the NT board ..................................................572
15.6.2.2 MAC address learning on the LT board...................................................572
15.6.2.3 MAC aging time .......................................................................................574
15.6.3 Ingress Frame Handling: which Forwarder and which Frame Tag
Manipulation? ..........................................................................................575
15.6.3.1 Finding out the right L2 forwarder for an Ingress Frame .........................575
15.6.3.2 Manipulations on the VLAN Tag(s) of an ingress frame..........................576
15.6.4 VLAN tagging modes in the iBridge.........................................................578
15.6.4.1 Forwarding of untagged/priority-tagged frames received from the
subscriber ................................................................................................578
NT
15.6.4.2 Forwarding of C-VLAN tagged frames ....................................................580

15.6.5 VLAN tagging modes in the stacked iBridge modes ...............................581
15.6.5.1 Concepts .................................................................................................581
15.6.5.2 Forwarding of untagged/priority-tagged/VLAN tagged frames in
S+C iBridge .............................................................................................582
15.6.5.3 Forwarding of untagged/priority-tagged/VLAN tagged frames in S-
iBridge .....................................................................................................584
15.6.6 VLAN tagging modes in the iBridge (Hub-ISAM LT NNI ports
concept)...................................................................................................584
15.6.6.1 Concepts .................................................................................................585
15.6.6.2 Forwarding of untagged/priority-tagged/VLAN tagged frames in C-
VLAN iBridge ...........................................................................................585
15.6.6.3 Forwarding of untagged/priority-tagged/VLAN tagged frames in
S+C iBridge .............................................................................................586
15.6.6.4 Forwarding of untagged/priority-tagged/VLAN tagged frames in S-
VLAN iBridge ...........................................................................................586
15.7 VLAN cross-connect mode......................................................................587
15.7.1 VLAN cross-connect usage .....................................................................587
15.7.2 Supported models in ISAM......................................................................588
15.7.2.1 C-VLAN cross-connect (basic VLAN cross-connect) ..............................588
15.7.2.2 S+C-VLAN cross-connect: VLAN stacking for residential
subscribers ..............................................................................................589
15.7.2.3 Tunnel-VLAN cross-connect: VLAN stacking for business
subscribers ..............................................................................................591
15.7.3 MAC learning and VLAN port handling....................................................592
15.7.4 Transparent VLAN cross-connect ...........................................................593
15.8 Protocol-aware cross-connect mode .......................................................596
15.8.1 VLAN cross-connect for business and residential subscribers................597
15.8.1.1 Business cross-connect features.............................................................599
15.8.1.2 Residential cross-connect features .........................................................600
15.9 IPoA cross-connect mode .......................................................................602
15.9.1 IPoA cross-connect features ...................................................................603
15.9.2 Cross-connect from IPoA to IPoE (upstream) .........................................603
15.9.3 Cross-connect from IPoE to IPoA (downstream).....................................604
15.10 Secure forwarding in iBridge and VLAN cross-connect...........................604
15.10.1 IP session awareness..............................................................................606
15.10.2 IP address anti-spoofing..........................................................................606
15.10.3 ARP relay ................................................................................................607
15.10.4 ICMPv6....................................................................................................608
15.10.5 IPoA support for secure forwarding .........................................................608
15.11 Virtual MAC .............................................................................................608
15.11.1 Deployment scenario example ................................................................609
15.11.2 vMAC features.........................................................................................611
15.11.2.1 Enable/disable vMAC support per network VLAN ...................................611
15.11.2.2 Maximum number of vMAC addresses per port is programmable ..........612
15.11.2.3 Silent discard ...........................................................................................612
15.11.2.4 DSL/Eth vMAC format .............................................................................613
15.11.2.5 xPON vMAC format .................................................................................613
15.11.2.6 DHCP Algorithm ......................................................................................614
NT
15.11.2.7 ARP Algorithm .........................................................................................614

15.11.2.8 ICMPv6 Algorithm....................................................................................615
15.11.2.9 Ethernet OAM Algorithm..........................................................................615
15.11.2.10 User-to-user communication can optionally be blocked ..........................615
15.11.2.11 vMAC address - MAC address translation table recovery.......................615
15.12 PPP cross-connect mode ........................................................................616
15.12.1 PPP Cross-connect inside the ISAM .......................................................619
15.13 Dynamic VLAN ........................................................................................620
16 Protocol handling in a Layer 2 forwarding model ...................621
16.1 Introduction..............................................................................................621
16.1.1 Layer 2 Control Protocol handling ...........................................................622
16.1.2 Application protocol handling...................................................................622
16.2 Link Aggregation......................................................................................623
16.2.1 Link Aggregation Control Protocol...........................................................624
16.2.2 Link aggregation support .........................................................................625
16.2.3 Active / Standby Subgroup in Link Aggregation ......................................627
16.2.3.1 Static LAG Subgroups .............................................................................627
16.2.3.2 Dynamic LAG subgroups.........................................................................628
16.3 RSTP and MSTP .....................................................................................629
16.3.1 RSTP .......................................................................................................629
16.3.2 MSTP.......................................................................................................630
16.3.3 Support of RSTP and MSTP ...................................................................630
16.4 Ethernet Ring Protection Switching (ERPS)............................................631
16.4.1 Support of ERPS in ISAM........................................................................634
16.4.2 Limitations of ERPS in ISAM ...................................................................634
16.5 Connectivity Fault Management ..............................................................634
16.5.1 CFM elements .........................................................................................635
16.5.2 CFM functions .........................................................................................637
16.5.3 CFM support in the ISAM ........................................................................638
16.5.3.1 ISAM equipped with xDSL LTs................................................................638
16.5.3.2 ISAM equipped with P2P GE Ethernet LTs: ............................................639
16.5.3.3 ISAM equipped with P2P 10 GE Ethernet LTs: .......................................640
16.5.3.4 ISAM equipped with PON LTs.................................................................641
16.5.3.5 ISAM equipped with IHUB NT .................................................................642
16.6 802.1X support ........................................................................................643
16.7 ARP .........................................................................................................644
16.8 DHCP ......................................................................................................645
16.8.1 Layer 2 DHCP Relay Agent.....................................................................646
16.8.1.1 Relaying DHCP messages to and from network and subscriber
interfaces .................................................................................................647
16.8.1.2 Option 82 handling ..................................................................................648
16.8.1.3 Customer ID ............................................................................................649
16.8.1.4 Physical line ID ........................................................................................649
16.8.1.5 Bandwidth information .............................................................................651
16.8.2 (Layer 3) DHCP Relay Agent ..................................................................651
16.8.3 DHCP snooping.......................................................................................651
16.9 IGMP .......................................................................................................652
16.10 PPPoE .....................................................................................................652
16.10.1 PPPoE relay ............................................................................................652
NT
16.10.1.1 PPPoE relay tag ......................................................................................653

16.10.2 PPPoA to PPPoE interworking ................................................................654
16.10.3 PPPoE relay with MAC address concentration .......................................656
16.11 DHCPv6...................................................................................................656
16.11.1 Lightweight DHCPv6 Relay Agent...........................................................657
16.11.2 Bandwidth information .............................................................................658
16.11.3 DHCPv6 trusted/untrusted port configuration..........................................658
16.11.4 DHCPv6 Relay Agent ..............................................................................658
16.11.5 DHCPv6 snooping ...................................................................................659
16.12 ICMPv6....................................................................................................659
16.13 LLDP........................................................................................................659
17 IP routing .....................................................................................661
17.1 Introduction..............................................................................................661
17.2 IP routing features ...................................................................................661
17.2.1 Packet forwarding based on the IP addresses ........................................662
17.2.2 Next hop behavior ...................................................................................662
17.2.3 Subscriber interface - Encapsulation types .............................................662
17.2.4 802.1X/RADIUS authentication ...............................................................662
17.2.5 Subscriber interface - Unnumbered.........................................................663
17.2.6 DHCPv4 relay agent................................................................................663
17.2.7 DHCPv6 relay agent................................................................................663
17.2.8 Subscriber routes - Dynamically learned through DHCP snooping.........663
17.2.9 Network routes - Dynamically learned through routing protocol..............665
17.2.10 Routes advertised to network and subscribers........................................665
17.2.11 User-to-user communication ...................................................................665
17.2.12 IPv4 option processing ............................................................................666
17.2.13 MTU.........................................................................................................666
17.2.14 ECMP ......................................................................................................666
17.2.15 Directed broadcast ..................................................................................666
17.2.16 ICMP Redirect .........................................................................................666
17.2.17 ICMPv6 redirect.......................................................................................666
17.3 IP routing model ......................................................................................667
17.3.1 Public IP routing instance ........................................................................667
17.3.2 Private IP routing instance.......................................................................670
17.4 Routing in case of subtended ISAMs ......................................................672
17.4.1 Subtended nodes operating as Layer 2 devices (Preferred) ...................673
17.4.2 Subtended nodes operating as L3 devices .............................................674
18.1 Introduction..............................................................................................675
18.2 IPv4 Routing Protocols ............................................................................676
18.3 ARP .........................................................................................................676
18.3.1 ARP handling on the user side ................................................................676
18.3.2 ARP handling on the network side ..........................................................677
18.4 DHCP relay agent....................................................................................677
18.4.1 Layer 2 DHCP relay agent.......................................................................677
18.4.2 Layer 3 DHCP relay agent.......................................................................678
18.5 DHCP snooping.......................................................................................679
18.6 DHCPv4 server........................................................................................680
NT
18.7 TWAMP Light ..........................................................................................680

18.8 IPv6 routing protocols..............................................................................681
18.8.1 OSPFv3 ...................................................................................................681
18.8.2 IS-ISv6.....................................................................................................681
18.8.3 BGP-4......................................................................................................682
18.9 Neighbour Discovery (ICMPv6) ...............................................................682
18.9.1 Proxy ND .................................................................................................682
18.9.2 Dynamic Neighbor Cache population based on Neighbour
Discovery.................................................................................................682
18.10 DHCPv6 Relay Agent ..............................................................................683
18.10.1 Lightweight DHCPv6 Relay Agent...........................................................683
18.10.2 DHCPv6 Relay Agent ..............................................................................683
18.11 DHCPv6 Snooping ..................................................................................683
18.12 Bidirectional Forwarding Detection..........................................................684
19 Multicast and IGMP.....................................................................687
19.1 Overview..................................................................................................687
19.1.1 Data plane ...............................................................................................688
19.1.2 Control plane ...........................................................................................690
19.2 Advanced capabilities..............................................................................691
19.2.1 Static infeed.............................................................................................692
19.2.2 Cross-VLAN multicasting.........................................................................693
19.2.3 Source Specific Multicasting....................................................................694
19.2.4 Fixed multicast VLAN per IGMP channel ................................................695
19.2.5 Fast leave ................................................................................................697
19.2.6 Resource admission control on the subscriber port ................................698
19.2.7 Resource admission control on the uplink...............................................698
19.2.8 Access control .........................................................................................698
19.2.9 Call Detailed Records..............................................................................699
19.2.10 Static router ports ....................................................................................699
19.2.11 IGMP forking............................................................................................700
19.2.12 PIM-SSM .................................................................................................701
19.3 System decomposition ............................................................................702
19.3.1 OMCI-based access rights and CAC control...........................................703
19.3.2 System decomposition ............................................................................705
19.4 Multicast and forwarding models .............................................................706
19.5 Multicast support for ISAM acting as pre-aggregator ..............................707
20 Quality of Service .......................................................................709
20.1 Introduction..............................................................................................709
20.2 Upstream QoS handling ..........................................................................710
20.2.1 Overview..................................................................................................710
20.2.2 Classification ...........................................................................................711
20.2.3 Marking....................................................................................................712
20.2.4 Policing ....................................................................................................715
20.2.5 Mapping and queueing ............................................................................716
20.2.6 Scheduling and shaping ..........................................................................719
20.2.6.1 Standard Scheduling Model ....................................................................719
20.2.6.2 Flexible Scheduling Model.......................................................................720
20.2.6.3 PON Scheduling and Shaping.................................................................720
NT
20.2.6.4 Shaping on network ports........................................................................721

20.2.7 Connection Admission Control ................................................................721
20.2.8 MPLS.......................................................................................................721
20.2.9 Per Line dot1p troubleshooting counters.................................................721
20.3 Downstream QoS ....................................................................................722
20.3.1 Classification ...........................................................................................722
20.3.2 Marking....................................................................................................722
20.3.3 Policing ....................................................................................................723
20.3.4 Mapping and queuing ..............................................................................723
20.3.5 Scheduling and Shaping..........................................................................724
20.3.6 Connection Admission Control ................................................................724
20.4 Hardware mapping of QoS functions.......................................................725
20.4.1 QoS on the NT boards.............................................................................725
20.4.2 QoS on the LT boards .............................................................................726
20.4.2.1 QoS on layer 3/layer2+ LT boards ..........................................................726
20.4.2.2 QoS on the layer2 LT boards ..................................................................728
20.4.2.3 QoS on the GPON and XGS-PON / TWDM-PON LT boards and
the ONTs .................................................................................................729
20.4.2.4 QoS on a GE Ethernet LT board .............................................................738
20.4.2.5 QoS on a 10GE Ethernet LT board .........................................................741
20.4.2.6 Overview on remarking rules on the 10GE Ethernet LT..........................743
20.4.2.7 Overview on Policing options on the 10GE Ethernet LT .........................746
20.4.3 Downstream QoS for VULA operations...................................................748
20.5 Configuration of QoS ...............................................................................750
20.5.1 IACM part ................................................................................................751
20.5.1.1 CAC profile ..............................................................................................751
20.5.1.2 Ingress QoS profile (p-bit to traffic class mapping)..................................751
20.5.1.3 Queue configuration and queue profile ...................................................752
20.5.1.4 Shaper profile ..........................................................................................755
20.5.1.5 Bandwidth profile .....................................................................................756
20.5.1.6 Priority contract profile.............................................................................756
20.5.1.7 Scheduler node profile.............................................................................757
20.5.1.8 Session profile .........................................................................................757
20.5.1.9 Marker profile...........................................................................................758
20.5.1.10 Policer profile...........................................................................................759
20.5.1.11 Policy framework .....................................................................................761
20.5.1.12 DSCP to p-bit alignment profile ...............................................................763
20.5.1.13 Counters and Threshold Crossing Alarms...............................................763
20.5.2 IHub part..................................................................................................767
20.5.2.1 Service ingress access policy..................................................................767
20.5.2.2 Service ingress network policy ................................................................768
20.5.2.3 Service egress network policy .................................................................768
20.5.2.4 Per-service egress rate limit ....................................................................769
20.5.2.5 Per-service ingress rate limit ...................................................................770
20.5.2.6 Base router network policy ......................................................................771
20.5.2.7 Forwarding class to egress queue mapping............................................771
20.5.2.8 Buffer and queue acceptance..................................................................772
20.5.2.9 Egress scheduler and rate limiter ............................................................774
20.5.2.10 QoS parameters of packets generated by the control plane ...................777
NT
21 Resource management and authentication .............................779

21.1 Introduction..............................................................................................779
21.2 RADIUS features .....................................................................................779
21.3 802.1X authentication via RADIUS..........................................................780
21.3.1 Dynamic Authorization Extensions for RADIUS with 802.1X ..................780
21.4 Operator authentication via RADIUS.......................................................781
21.5 Encryption of authentication data ............................................................782
21.6 Fast recovery of 802.1X sessions ...........................................................782
21.7 Lawful Interception ..................................................................................783
21.8 Authenticate, authorize and account operator via TACACS+ .................783
22 MPLS............................................................................................785
22.1 Introduction..............................................................................................785
22.2 Label Switched Path................................................................................786
22.3 Label Distribution Protocol.......................................................................787
22.4 Resource Reservation Protocol...............................................................789
22.5 Pseudo-wires and T-LDP ........................................................................790
22.6 BGP Auto-Discovery................................................................................791
22.7 L2 VPN services ......................................................................................792
22.7.1 VLL Tunneling approach .........................................................................793
22.7.2 VLL Mapping approach ...........................................................................793
22.7.3 VPLS iBridge approach ...........................................................................794
22.8 QoS .........................................................................................................794
22.9 Redundancy and resilience .....................................................................794
22.10 Support for MPLS rings ...........................................................................795
22.11 Support for MPLS flow label ....................................................................796
22.12 Supporting integrated voice services over MPLS....................................797
22.13 Supporting MPLS and VLAN Traffic on "Hybrid Port" .............................798
23 ATM Pseudowire emulation.......................................................799
23.1 Introduction..............................................................................................799
23.2 Solution description .................................................................................799
23.3 Cell concatenation ...................................................................................801
23.4 QoS .........................................................................................................801
23.5 Known restrictions ...................................................................................802
23.6 Support on the ISAM ...............................................................................802
24 Application Intelligence Platform..............................................803
24.1 Introduction..............................................................................................803
24.2 Solution description .................................................................................803
24.3 Benefits....................................................................................................805
24.4 Support in ISAM ......................................................................................806
24.5 Functionality on Application Intelligence Platform ...................................806
24.5.1 Network Address and Port Translation (NAPT).......................................806
24.5.2 Dynamic Host Configuration Protocol (DHCP) Server ............................807
25 Cross-domain solutions.............................................................809
25.1 Overview..................................................................................................809
25.1.1 Mobile Backhaul ......................................................................................809
25.1.2 E1/T1 Leased Line Replacement ............................................................809
25.1.3 Ethernet Business Access.......................................................................810
NT
25.1.4 ISAM Backhaul (Rural DSL, Ultra-high Broadband)................................810

25.1.5 Hospitality solution...................................................................................810
25.1.6 Open Community Broadband for Smart Communities ............................810
25.2 Mobile backhaul.......................................................................................810
25.2.1 Scope ......................................................................................................811
25.2.2 Introduction..............................................................................................811
25.2.3 Technical challenges ...............................................................................812
25.2.3.1 Bandwidth................................................................................................812
25.2.3.2 TDM/ATM/Ethernet service delivery........................................................813
25.2.3.3 Synchronization .......................................................................................813
25.2.3.4 QoS and High Availability for mission critical traffic.................................814
25.2.3.5 Demarcation ............................................................................................815
25.2.4 Solution description .................................................................................816
25.3 E1/T1 Leased Line Replacement (SHDSL/PON) ....................................819
25.3.1 Scope ......................................................................................................819
25.3.2 Introduction..............................................................................................819
25.3.3 Technical Challenges ..............................................................................820
25.3.3.1 Leased line emulation..............................................................................820
25.3.3.2 Symmetrical bandwidth ...........................................................................820
25.3.3.3 Key Performance Indicators (KPIs) for loss and delay ............................820
25.3.3.5 High Availability .......................................................................................821
25.4 E1/PRA Interfaces on ISAM ....................................................................824
25.4.1 Scope ......................................................................................................824
25.4.2 Introduction..............................................................................................824
25.4.3 Technical characteristics .........................................................................826
25.4.3.1 Line termination .......................................................................................826
25.4.3.2 Pseudowire capabilities ...........................................................................826
25.4.3.4 Alarms .....................................................................................................828
25.4.3.5 Service diagnostic capabilities.................................................................828
25.5 Ethernet Business Access over ISAM .....................................................830
25.5.1 Scope ......................................................................................................830
25.5.2 Introduction..............................................................................................830
25.5.3 Technical Challenges ..............................................................................831
25.5.3.1 Bandwidth................................................................................................831
25.5.3.2 Ethernet Business Service Delivery ........................................................831
25.5.3.3 High availability........................................................................................833
25.5.3.4 QoS .........................................................................................................834
25.5.3.5 OAM, including SLA monitoring...............................................................834
25.6 ISAM Backhaul (Rural DSL, Ultra-high Broadband)................................837
25.6.1 Introduction..............................................................................................837
25.6.2.1 Bandwidth................................................................................................839
25.6.2.2 Transparency...........................................................................................839
25.6.2.3 Service differentiation ..............................................................................839
NT
25.6.2.4 Resiliency ................................................................................................842

25.6.2.5 Ethernet bridging converter options.........................................................843
25.7 Hospitality solution...................................................................................843
25.7.1 Introduction..............................................................................................844
25.7.2.1 High level architecture hospitality solution...............................................845
25.7.2.2 DSL and POTS in hospitality solutions....................................................847
25.7.2.3 Broadband bandwidth requirements........................................................849
25.8 Open Community Broadband for Smart Communities ............................850
25.8.1 Introduction..............................................................................................850
25.8.2 OCB context ............................................................................................851
25.8.2.1 Wholesaling .............................................................................................851
25.8.2.2 Roles and responsibilities........................................................................852
25.8.3 Solution description: Active architecture..................................................853
25.8.3.1 Requirements ..........................................................................................853
25.8.3.2 Architecture: Ethernet open access.........................................................853
25.8.4 Solution description: Management subsystem ........................................855
26 RADIUS Attributes ......................................................................857
26.1 RADIUS Attributes...................................................................................857
26.1.1 NAS-Port .................................................................................................857
26.1.2 NAS-Port-Id .............................................................................................857
26.2 Vendor specific RADIUS attributes..........................................................858
26.2.1 General....................................................................................................858
26.2.2 VRF-Name...............................................................................................859
26.2.3 VLAN-ID ..................................................................................................859
26.2.4 QoS-Profile-Name ...................................................................................859
26.2.5 QoS-Parms..............................................................................................859
26.2.6 TL1 domain parameters ..........................................................................860
26.2.7 CLI domain parameters ...........................................................................860
26.2.8 CLI profile parameters .............................................................................862
NT
List of figures
2 Introduction...................................................................................43
Figure 1 ISAM Network Architecture .......................................................................44
Figure 2 IMA ............................................................................................................65
Figure 3 Link protection with active/standby external NT link..................................78
Figure 4 Link protection with load-sharing external NT links ...................................79
Figure 5 Link protection with load-sharing external NT links ...................................80
Figure 6 NT equipment protection with distributed external links ............................81
Figure 7 NT equipment protection with distributed external links (load
aggregation) ..............................................................................................82
Figure 8 Independent load sharing external link and NT protection with NT ...........84
Figure 9 NTIO operating in Active/Active mode.......................................................85
Figure 10 Example of an ISAM subtending star topology..........................................86
Figure 11 Example of an ISAM subtending daisy chain topology..............................87
Figure 12 Example of an ISAM subtending ring topology..........................................88
Figure 13 Example of layer3-based protection ..........................................................89
Figure 14 Type-B PON Protection .............................................................................92
Figure 15 Protection switching via autonomous ONU re-tuning on a TWDM
PON system (normal operation) ................................................................94
PON system (at failure) .............................................................................94
PON system (protected mode) ..................................................................95
5 Management..................................................................................97
Figure 18 ISAM management....................................................................................98
Figure 19 Secure and insecure management interfaces ...........................................99
Figure 20 SSH client-server architecture in the NE .................................................107
Figure 21 Management via a Layer 3 SAP - external management v-VPLS
(VLAN).....................................................................................................115
Figure 22 Management via a Layer 3 SAP - No external management v-
VPLS .......................................................................................................116
Figure 23 Management via an IP interface directly connected to a network
port ..........................................................................................................117
Figure 24 Temporal alarm by quantity .....................................................................124
Figure 25 Temporal alarm by time...........................................................................125
Figure 26 Zero Touch Provisioning..........................................................................134
Figure 27 Position line testing capabilities for DSL - POTS/ISDN lines...................139
Figure 28 Embedded OTDR main advantages........................................................159
Figure 29 Overview of possible NTR support on some LTs and some NTs in
the FD 100/320Gbps ISAM NT family .....................................................164
NT
Figure 30 NTR options for FX NT ISAM family........................................................165

Figure 31 Port selection for external NTR (SyncE and BITS)..................................167
Figure 32 ISAM configuration for NTR provisioning with single NT.........................169
Figure 33 States and state transitions for the internal NTR clock............................170
Figure 34 NTR distribution over access lines for different services.........................179
Figure 35 ToD topology for 480G/1.28T NT ISAM family (FX) ................................181
Figure 36 L2/L3 power modes .................................................................................196
Figure 37 Seamless Rate Adaptation ......................................................................198
Figure 38 Far end cross-talk....................................................................................199
Figure 39 Crosstalk in mixed CO-RT deployment ...................................................200
Figure 40 Impulse Noise Monitor in XTU-R and XTU-C ..........................................201
Figure 41 Virtual noise concept ...............................................................................203
Figure 42 DSL physical layer retransmission concept.............................................204
Figure 43 Per-line configuration overrule.................................................................205
Figure 44 Typical vectoring gains ............................................................................207
Figure 45 Cross-DSLAM Level Vectoring................................................................209
Figure 46 VDSL2 35b fills the gap between VDSL2 vectoring and G.fast...............212
Figure 47 VDSL2 35b mixed vectoring with VDSL2 17a .........................................213
Figure 48 Example Mode selection and Performance of VDSL2-LR.......................214
9 ADSL/VDSL Bonding..................................................................215
Figure 49 xDSL bonding deployment scenarios ......................................................215
10 GPON Network Architecture......................................................219
Figure 50 ISAM GPON Network Architecture..........................................................221
Figure 51 GPON Functional Blocks.........................................................................223
Figure 52 PON media access control concept ........................................................224
Figure 53 PON Downstream Frame format .............................................................225
Figure 54 PON Upstream Frame Format ................................................................225
Figure 55 Ethernet encapsulation over GEM...........................................................225
Figure 56 Fragmentation Examples.........................................................................226
11 ISAM Support for the GPON ONU .............................................235
Figure 57 ISAM GPON Network Architecture..........................................................235
12 Universal Next Generation PON Network Architecture...........239
Figure 58 ISAM Universal NG-PON Network Architecture ......................................242
Figure 59 TC-layer Information flow ........................................................................243
Figure 60 Media Access Control concept ................................................................245
Figure 61 Downstream Frame format......................................................................246
Figure 62 Upstream Frame Format .........................................................................247
Figure 63 Ethernet encapsulation over XGEM ........................................................248
Figure 64 Fragmentation Example ..........................................................................248
Figure 65 7302 ISAM/7330 ISAM FTTN/ISAM 7360 FX: NGVN Network
Architecture .............................................................................................262
Figure 66 The TISPAN IMS-PES functional architecture ........................................265
Figure 67 The TISPAN IMS-PES Solution...............................................................265
NT
Figure 68 7302 ISAM/7330 ISAM FTTN/7360 ISAM FX: TISPAN IMS-PES

Network Architecture ...............................................................................266
Figure 69 SIP Integrated Voice Service in a non-IMS-compliant network ...............267
Figure 70 Structured (Nx64) E1 Leased Line (PW3) in ISAM via NIAT-A ...............269
Figure 71 CESoPSN reference model.....................................................................269
Figure 72 Megaco Integrated Voice Service: Voice Cluster topology A ..................271
Figure 73 Megaco Integrated Voice Service: Voice Cluster topology B ..................271
Figure 74 Megaco Integrated Voice Service: Voice Cluster topology C ..................272
Figure 75 Megaco Integrated Voice Service: Voice Cluster topology D ..................272
Figure 76 Megaco Integrated Voice Service: Voice Cluster topology E ..................273
Figure 77 Megaco Integrated Voice Service: Voice Cluster topology F ..................273
Figure 78 Layer 4 forwarding approach...................................................................280
Figure 79 Megaco Integrated Voice Service: switched model.................................280
Figure 80 Megaco Integrated Voice Service: routed model.....................................281
Figure 81 SIP Integrated Voice Service (centralized architecture): switched
model.......................................................................................................282
Figure 82 SIP Integrated Voice Service (centralized architecture): routed
model.......................................................................................................283
Figure 83 SIP Integrated Voice Service (distributed architecture): switched
model.......................................................................................................284
Figure 84 SIP Integrated Voice Service (distributed architecture): routed
model.......................................................................................................285
Figure 85 MEGACO/SIP Integrated Voice Service - Subtended topology:
Switched mode ........................................................................................286
Figure 86 Megaco/SIP Integrated Voice Service - Subtended topology:
Routed mode ...........................................................................................287
Figure 87 Megaco Integrated Voice Service - Switched: Signaling forwarding .......288
Figure 88 Megaco Integrated Voice Service - Switched: XLES packet
originating at the Voice packet server .....................................................290
originating at the Voice LT board.............................................................290
Figure 90 Megaco Integrated Voice Service - Switched: Voice packet
originating at the Voice LT board.............................................................293
Figure 92 Megaco Integrated Voice Service - Routed: signaling forwarding...........295
Figure 93 Megaco Integrated Voice Service - Routed: XLES packet
forwarding at the Voice LT board. ...........................................................297
Figure 95 Megaco Integrated Voice Service - Routed: Voice packet
originating at the LT board.......................................................................299
Figure 97 SIP Integrated Voice Service - Switched - Centralized: Signaling
packet originating at the Voice LT/Upstream layer 3 forwarding at the IHub
301
NT

packet destined to the Voice LT/Downstream layer 4 forwarding at the
IHub .........................................................................................................302
Figure 99 SIP Integrated Voice Service - Switched - Distributed: Signaling
packet originating at the Voice LT/Upstream layer 3 forwarding at the
Voice LT ..................................................................................................303
IHub .........................................................................................................303
Figure 101 SIP Integrated Voice Service - Routed - Centralized: Signaling
packet originating at the Voice LT/Upstream layer 3 forwarding at the IHub
306
IHub .........................................................................................................307
Figure 103 SIP Integrated Voice Service - Routed - Distributed: Signaling
packet originating at the Voice LT/Upstream layer 3 forwarding at the
Voice LT ..................................................................................................308
IHub .........................................................................................................308
Figure 105 ISAM Voice : Distinct VLAN topology - HUB Voice access node ............312
Figure 106 ISAM Voice : Distinct VLAN topology - Subtending Voice access
node.........................................................................................................313
Figure 107 ISAM Voice : Distinct VLAN topology - Remote Voice access node .......313
Figure 108 7363 ISAM MX / 7367 ISAM SX : Distinct VLAN topology ......................314
Figure 109 ISAM Voice : Shared VLAN topology - HUB Voice access node ............316
Figure 110 ISAM Voice : Shared VLAN topology - Subtending Voice access
node.........................................................................................................316
Figure 111 ISAM Voice : Shared VLAN topology - Remote Voice access node .......316
Figure 112 7363 ISAM MX / 7367 ISAM SX : Shared VLAN topology ......................317
Figure 113 ISAM Voice : Private VLAN topology - HUB Voice access node.............319
Figure 114 ISAM Voice : Private VLAN topology - Subtending Voice access
node.........................................................................................................320
Figure 115 ISAM Voice : Private VLAN topology - Remote Voice access node........320
Figure 116 ISAM Voice : Distinct VLAN / IP address topology - HUB Voice
access node ............................................................................................323
Figure 117 ISAM Voice : Distinct VLAN / IP address topology - Subtending Voice
access node ............................................................................................324
Figure 118 ISAM Voice : Distinct VLAN / IP address topology - Remote Voice
access node ............................................................................................324
Figure 119 ISAM Voice : Shared VLAN / IP address topology - HUB Voice
access node ............................................................................................327
Figure 120 ISAM Voice : Shared VLAN / IP address topology - Subtending Voice
access node ............................................................................................327
Figure 121 ISAM Voice : Shared VLAN / IP address topology - Remote Voice
access node ............................................................................................328
Figure 122 ISAM Voice : Private VLAN / IP address topology - HUB Voice
access node ............................................................................................330
NT
Figure 123 ISAM Voice : Private VLAN / IP address topology - Subtending Voice
access node ............................................................................................331
Figure 124 ISAM Voice : Private VLAN / IP address topology - Remote Voice
access node ............................................................................................331
Figure 125 ISAM Voice : Distributed IP address Architecture - Shared VLAN
topology ...................................................................................................333
Figure 126 ISAM Voice : Distributed IP address Architecture - Distinct VLAN
topology ...................................................................................................334
Figure 127 ISAM Voice : Centralized IP address Architecture - Distinct VLAN
topology ...................................................................................................336
Figure 128 7363 ISAM MX : Centralized IP address Architecture - Distinct
VLAN topology.........................................................................................336
Figure 129 ISAM Voice : Centralized IP address Architecture - Shared VLAN
topology ...................................................................................................337
Figure 130 7363 ISAM MX : Centralized IP address Architecture - Shared
VLAN topology.........................................................................................338
Figure 131 ISAM Voice : Distributed IP address Architecture - Shared VLAN/IP
address topology .....................................................................................340
Figure 132 ISAM Voice : Distributed IP address Architecture - Distinct VLAN/IP
Figure 133 ISAM Voice : Centralized IP address Architecture - Distinct VLAN/IP
Figure 134 ISAM Voice : Centralized IP address Architecture - Shared VLAN/IP
Figure 135 H.248 signaling protocol stack - Voice POTS access node as
Switching Device .....................................................................................347
Routing Device ........................................................................................347
Figure 137 H.248 signaling protocol stack - Subtending Voice POTS access
node as Switching Device - HUB Voice access node as Switching device...
348
node as Switching Device - HUB access node as Routing Device .........348
Figure 139 H.248 signaling protocol stack - Remote Voice POTS access node
as Switching Device - HUB Voice access node as Routing Device ........348
Figure 140 H.248 signaling protocol stack - Remote Voice POTS access node
as Switching Device - HUB Voice access node as Routing Device ........349
Figure 141 ISDN BRA signaling protocol stack - HUB Voice access node as
Switching Device .....................................................................................349
Routing Device ........................................................................................350
Figure 143 ISDN BRA signaling protocol stack - Subtending Voice access
node as Switching Device - HUB Voice access node as Switching Device ..
350
node as Switching Device - HUB Voice access node as Routing Device351
Figure 145 ISDN BRA signaling protocol stack - Remote Voice access node as
Switching Device - HUB Voice access node as Switching Device ..........351
NT
Figure 146 ISDN BRA signaling protocol stack - Remote Voice access node as
Switching Device - HUB Voice access node as Routing Device .............351
Figure 147 SIP signaling protocol stack - Distributed IP address Architecture -
HUB Voice access node as Switching Device - POTS Line....................352
Figure 148 SIP signaling protocol stack - Distributed IP address Architecture -
HUB Voice access node as Routing Device - POTS Line ......................352
Figure 149 SIP signaling protocol stack - Centralized IP address Architecture -
Upstream - HUB Voice access node as Switching Device - POTS
Line..........................................................................................................353
Upstream - HUB Voice access node as Routing Device - POTS
Line..........................................................................................................353
Downstream - HUB Voice access node as Switching Device -
POTS Line ...............................................................................................353
Downstream - HUB voice access node as Routing Device - POTS
Line..........................................................................................................354
Figure 153 ISDN PRA to SIP signaling protocol stack - Centralized/Distributed
IP address Architecture - ISDN PRA Line ...............................................354
Figure 154 CAS R2 to SIP signaling protocol stack - Centralized/Distributed IP
address Architecture - CAS R2 Line........................................................354
Figure 155 RTP/RTCP protocol stack - Upstream/Downstream ...............................355
Figure 156 Megaco Integrated Voice Service Conceptual Management Model........361
Figure 157 SIP Protocol and Network Conceptual Management model ...................364
Figure 158 Performance Monitoring Conceptual Management Model - POTS .........365
Figure 159 CDE File Conceptual Management model ..............................................366
Figure 160 Narrowband Line Test Conceptual Management Model .........................366
Figure 161 CESoPSN Conceptual Management model............................................371
Figure 162 LOCAL and GEO redundancy .................................................................381
Figure 163 Single MGC and single ASP....................................................................382
Figure 164 Single MGC and two ASPs......................................................................382
Figure 165 Local MGC switch-over ...........................................................................384
Figure 166 Local ASP switch-over.............................................................................384
Figure 167 GEO MGC switch-over ............................................................................385
Figure 168 GEO ASP switch-over (caused by GEO MGC switch-over)....................385
Figure 169 SIP Server redundancy ...........................................................................388
Figure 170 SIP GEO redundancy ..............................................................................394
Figure 171 SIP ESA redundancy...............................................................................395
Figure 172 LSA Server Conceptual Management Model ..........................................400
Figure 173 SIP overload handling .............................................................................410
Figure 174 H.248 Integrated Voice Service - Switched device - External
Packet Forwarding enabled.....................................................................421
Packet Forwarding disabled ....................................................................422
Figure 176 SIP Integrated Voice Service - Switched device - External Packet
Forwarding enabled.................................................................................424
Forwarding disabled ................................................................................425
NT
Figure 178 Device connected directly to the Voice access node ..............................426
Figure 179 Device connected remotely to the Voice access node ............................426
Figure 180 Voice upgrade/migration cluster (centralized topology)...........................428
Figure 181 Voice upgrade/migration cluster (distributed topology) ...........................429
Figure 182 SIP ISAM Voice Performance Monitoring Result Post-Processing .........475
Figure 183 SIP Integrated Voice Service - ISDN PRA ..............................................486
Figure 184 SIP Integrated Voice Service ISDN PRA protocols .................................487
Figure 185 ISDN PRA User Connections ..................................................................488
Figure 186 SIP Integrated Voice Service CAS R2.....................................................504
Figure 187 SIP Integrated Voice Service CAS R2 protocols .....................................505
Figure 188 Structured (Nx64) E1 Leased Line (PW3) in ISAM via ISDN PRA
LT Board..................................................................................................520
Figure 189 Untagged and tagged/priority-tagged Ethernet frames ...........................526
Figure 190 Example of VLAN ....................................................................................527
Figure 191 ISAM as an Access Device .....................................................................528
Figure 192 The generic L2 forwarder ........................................................................529
Figure 193 A VLAN cross-connect ............................................................................532
Figure 194 Dual-Tag S+C-VLAN cross-connect........................................................532
Figure 195 L2 multiservice by means of VLAN ports.................................................537
Figure 196 VLAN ports hiding the line transport technology .....................................538
Figure 197 Multi-VLAN and VLAN translation example.............................................541
Figure 198 MPLS as network encapsulation technique.............................................542
Figure 199 ISAM support for VULA operations .........................................................543
Figure 200 Distributed Layer 2 Forwarding in ISAM (GPON/XGS-PON /
TWDM-PON OLT-ONT) ..........................................................................545
Figure 201 Layer 2 Forwarding in ISAM ....................................................................546
Figure 202 Subtended network elements ..................................................................549
Figure 203 Three stage forwarding for ISAM operating as a VULA node .................551
Figure 204 iBridge with direct network VLAN encapsulation .....................................552
Figure 205 VLAN Cross-connect with direct network VLAN encapsulation...............553
Figure 206 iBridging using with MPLS pseudo-wires towards the NSP ....................554
Figure 207 C- and S-VLAN cross-connect with MPLS pseudo-wires and E-
PIPE ........................................................................................................555
Figure 208 Full Bridge emulation (direct Network VLAN encapsulation shown) .......556
Figure 209 Combining forwarders on uplink/downlink LTs for VULA operations.......557
Figure 210 Combining forwarders on uplink LT and UNI/NNI on downlink LTs
for VULA operations ................................................................................557
Figure 211 Subscriber access interface model for iBridges and VLAN cross-
connect ....................................................................................................561
Figure 212 Support for Jumbo frames .......................................................................562
Figure 213 VLAN with two ISAMs..............................................................................570
Figure 214 Hub-ISAM with iBridge ............................................................................571
Figure 215 Finding out the right L2 forwarder for an Ingress Frame .........................576
Figure 216 Possible Manipulations on Frames VLAN Tag by VLAN ports................577
Figure 217 Forwarding untagged/priority-tagged frames in an iBridge (iBridge
shown with only one subscriber) .............................................................578
NT
Figure 218 Protocol-based VLAN selection (iBridge shown with only one
subscriber)...............................................................................................579
Figure 219 Subscriber-side VLAN-IDs with a network-wide scope (iBridge
shown with only one subscriber) .............................................................580
Figure 220 Support for VLAN translation (iBridge shown with only one
subscriber)...............................................................................................581
Figure 221 C-VLAN cross-connect concept ..............................................................589
Figure 222 S+C-VLAN cross-connect concept ..........................................................590
Figure 223 S-VLAN cross-connect model concept....................................................592
Figure 224 Tunnel-VLAN, C-VLAN and S+C-VLAN cross-connects on same
bridge port ...............................................................................................592
Figure 225 Use of transparent VLAN cross-connect .................................................594
Figure 226 One transparent VLAN cross-connect per PVC/EFM..............................596
Figure 227 IP network model for business cross-connect .........................................597
Figure 228 IP network model for residential cross-connect using IP
connectivity..............................................................................................598
Figure 229 IP network model for residential cross-connect using PPP
connectivity..............................................................................................599
Figure 230 IP network model for business IPoA cross-connect ................................602
Figure 231 Ethernet network model for business IPoA cross-connect ......................603
Figure 232 Enhanced iBridge architecture ................................................................605
Figure 233 iBridge .....................................................................................................610
Figure 234 iBridge with vMAC enabled .....................................................................610
Figure 235 General PPP cross-connect engine ........................................................617
Figure 236 Subscriber access interface stack for PPP client ports ...........................618
Figure 237 Accepted ATM encapsulation for PPP cross-connect Forwarding
with MAC address concentration.............................................................618
Figure 238 PPP cross-connect inside the ISAM........................................................619
Figure 239 Link aggregation ......................................................................................624
Figure 240 Link aggregation support .........................................................................626
Figure 241 Active / standby subgroup for aggregation ..............................................627
Figure 242 Spanning Tree between NE and EMAN ..................................................629
Figure 243 Ethernet Ring Topology...........................................................................632
Figure 244 Normal state of Ethernet Ring Protection ................................................632
Figure 245 Path Failure and R-APS message flow to RPL Owner Node ..................633
Figure 246 Reconfiguration to protected path ...........................................................633
Figure 247 CFM on the access aggregation network ................................................637
Figure 248 MEPs supported on ISAM equipped with DSL or P2P GE LTs...............640
Figure 249 MEPs supported on ISAM equipped with DSL or P2P 10 GE LTs..........640
Figure 250 802.1X in the ISAM..................................................................................644
Figure 251 Layer 2 DHCP relay implementation) ......................................................647
Figure 252 PPPoE Relay Implementation .................................................................653
Figure 253 Network Topology....................................................................................654
17 IP routing .....................................................................................661
Figure 254 IPv4 routing - Base router with IES service .............................................668
Figure 255 IPv6 routing - Base router with IES service .............................................668
Figure 256 IPv4 routing - VPRN service....................................................................671
NT
Figure 257 IPv6 routing - VPRN service....................................................................671

Figure 258 ISAM sub-network configuration for video traffic (e.g VDSL) ..................673
Figure 259 Subtended ISAM operating as a L3 device .............................................674
Figure 260 L3 DHCP Relay .......................................................................................679
Figure 261 IGMP enabled bridges.............................................................................688
Figure 262 Multicast data plane.................................................................................689
Figure 263 Common network VLAN for L3 unicast and multicast .............................690
Figure 264 IGMP control plane..................................................................................691
Figure 265 Static infeed.............................................................................................692
Figure 266 Cross-VLAN multicast - forwarding view .................................................693
Figure 267 Cross-VLAN multicast - network view .....................................................694
Figure 268 Source Specific Multicasting....................................................................695
Figure 269 Fixed Multicast VLAN per IGMP channel ................................................696
Figure 270 Fast leave on subscriber ports ................................................................697
Figure 271 Example of static router port....................................................................700
Figure 272 Example of IGMP forking.........................................................................701
Figure 273 SSM Translate Overview.........................................................................702
Figure 274 Modes of multicast provisioning at the ONT............................................704
Figure 275 System decomposition for multicast ........................................................705
Figure 276 System decomposition for multicast (GPON and XGS-PON /
TWDM-PON with ONT-to-OLT signaling)................................................706
TWDM-PON with IGMP snooping on the ONT) ......................................706
Figure 278 IGMP processing .....................................................................................707
Figure 279 Qos Overview - Standard Model .............................................................710
Figure 280 QoS Overview - Flexible Model ...............................................................711
Figure 281 QoS: classification ...................................................................................711
Figure 282 QoS: marking...........................................................................................713
Figure 283 QoS: policing ...........................................................................................716
Figure 284 Policing implementation framework.........................................................716
Figure 285 QoS queues for standard model..............................................................717
Figure 286 QoS: scheduling ......................................................................................719
Figure 287 Reference scheduling hierarchy for standard model ...............................720
Figure 288 PW data packet .......................................................................................721
Figure 289 QoS flow in IHub......................................................................................725
Figure 290 Logical architecture for QoS on layer 3 LT boards ..................................726
Figure 291 Per DSL-port scheduler ...........................................................................727
Figure 292 Ethernet-to-ATM QoS transition ..............................................................727
Figure 293 GPON and XGS-PON / TWDM-PON LT and ONT combined into a
single management entity........................................................................730
Figure 294 T-CONT bandwidth parameters and DBA mechanism............................732
Figure 295 Upstream traffic mapping to queues and TC layer parameters...............733
Figure 296 Downstream scheduling and shaping on the GPON and XGS-PON
/ TWDM-PON LT .....................................................................................736
Figure 297 Service-based flat scheduling..................................................................737
NT
Figure 298 QoS session profile on the VULA uplink..................................................745

Figure 299 CoS based trTCM principles....................................................................747
Figure 300 QoS for VULA operations ........................................................................749
Figure 301 RED configuration parameters ................................................................753
Figure 302 Three color WRED ..................................................................................754
Figure 303 Three color tail drop.................................................................................754
Figure 304 Composition of QoS session profile ........................................................757
Figure 305 Policy building blocks ..............................................................................762
Figure 306 QoS Counters and TCAs on layer 3 Boards............................................764
Figure 307 Buffer pool regions on IXP boards...........................................................765
Figure 308 Buffer and queue acceptance (TCP Traffic) ............................................773
Figure 309 Buffer and queue acceptance (non-TCP traffic) ......................................774
Figure 310 IHub egress port scheduler topology.......................................................774
Figure 311 IHub egress port scheduler topology (default 4 queue FD 320Gbps
and FX NT) ..............................................................................................775
Figure 312 IHub egress port scheduler topology (default 8 queue FD 320Gbps
and FX NT) ..............................................................................................776
Figure 313 QoS in IHub upstream for services..........................................................777
Figure 314 QoS in IHub downstream for services .....................................................778
Figure 315 QoS in IHub for base router.....................................................................778
22 MPLS............................................................................................785
Figure 316 Label switched path.................................................................................786
Figure 317 Label distribution .....................................................................................788
Figure 318 T-LDP and PW ........................................................................................790
Figure 319 LT-NT mapping........................................................................................793
Figure 320 MPLS switchover principles.....................................................................796
23 ATM Pseudowire emulation.......................................................799
Figure 321 ATM Pseudowire network architecture....................................................800
24 Application Intelligence Platform..............................................803
Figure 322 AI platform hardware resources ..............................................................804
Figure 323 ISAM Applications life cycle management...............................................805
Figure 324 High availability: points of failure .............................................................815
Figure 325 Mobile backhaul cell site device portfolio ................................................816
Figure 326 Mobile backhaul end-to-end-topologies (logical) .....................................817
Figure 327 ISAM physical layer synchronization architecture (DSL and point-to-
point)........................................................................................................818
Figure 328 ISAM physical layer synchronization architecture (GPON) .....................818
Figure 329 Access components for E1/T1 leased line replacement..........................822
Figure 330 End-to-end topologies for E1/T1 leased line emulation...........................823
Figure 331 Dual-Channel TDM Pseudowire SFP ......................................................825
Figure 332 E1/PRA Termination (pseudowire) in ISAM: MEF8 interworking ............825
Figure 333 E1 TDM SFP, End-to-End Synchronization options ................................827
Figure 334 2E1-SFP loopback towards E1 (including framer)...................................828
Figure 335 2E1-SFP loopback towards network (including framer) ..........................829
Figure 336 Solution Description ISAM E1/PRA backhaul..........................................830
Figure 337 Ethernet Business Service Delivery ........................................................832
NT
Figure 338 Implementing service requirements at the UNI .......................................833

Figure 339 High Availability: points of failure.............................................................834
Figure 340 Ethernet Business Access Portfolio.........................................................835
Figure 341 ISAM fiber backhaul ................................................................................838
Figure 342 Encapsulation overhead GFP versus HDLC ...........................................840
Figure 343 ISAM backhaul with point-to-multipoint converter ...................................841
Figure 344 ISAM backhaul with point-to-point converter ...........................................842
Figure 345 ISAM backhaul options............................................................................843
Figure 346 Standard offering for voice and internet access in hotel guest
rooms.......................................................................................................844
Figure 347 Enhanced multi-media experience in hotel guest rooms with xDSL........844
Figure 348 IP DSLAM Deployment scenario for hospitality, centralized ...................846
Figure 349 IP DSLAM Deployment scenario for hospitality, distributed (single
building) ...................................................................................................846
Figure 350 IP DSLAM Deployment scenario for hospitality, distribute (multiple
sites) ........................................................................................................847
Figure 351 ISAM in hospitality: triple-play high-level network topology.....................848
Figure 352 Hotel Room Bandwidth requirement........................................................849
Figure 353 OCB: roles and wholesaling levels ..........................................................852
Figure 354 OCB: roles and responsibilities ...............................................................852
Figure 355 L2 access architecture for OCB (residential user depicted with 1
RGW per RSP) ........................................................................................854
NT
NT
List of tables
Table 1 ADSL operational modes...........................................................................52
Table 2 ADSL2 operational modes.........................................................................53
Table 3 ADSL2plus operational modes ..................................................................54
Table 4 READSL2 operational modes....................................................................55
Table 5 VDSL2 operational modes.........................................................................56
Table 6 VDSL2 profile parameter overview............................................................57
Table 7 SHDSL regional settings ...........................................................................58
Table 8 Overview of link protection options in function of the Ethernet LT
interface types ...........................................................................................91
5 Management..................................................................................97
Table 9 Contents ....................................................................................................97
Table 10 Message type and log severity parameters.............................................110
Table 11 Supported SSH and SNMP Authentication and Encryption
Schemes..................................................................................................112
Table 12 NBLT type categories ..............................................................................150
Table 13 NBLT type categories on ISDN ...............................................................155
Table 14 Specific clock requirements per application ............................................162
Table 15 ISAM used as VULA node.......................................................................166
Table 16 G.8275.1 profile .......................................................................................187
Table 17 G.8265.1 profile .......................................................................................188
Table 18 CCSA profile............................................................................................188
Table 19 Customer profile ......................................................................................188
Table 20 Supported xDSL features ........................................................................192
Table 21 Supported VDSL2 profiles .......................................................................192
Table 22 Supported VDSL2 bandplans ..................................................................193
Table 23 Supported Features.................................................................................259
Table 24 SIP ISDN PRA: Supported number manipulation rules...........................375
Table 25 SIP ISDN PRA: Supported number manipulation rules...........................376
Table 26 SIP CAS R2: Supported number manipulation rules...............................378
Table 27 Supported DHCP options ........................................................................414
Table 28 ISAM Access Node as OFFER side (DTMF audio).................................438
Table 29 ISAM Access Node as OFFER side (DTMF RFC2833). .........................439
Table 30 ISAM Access Node as OFFER side (DTMF both)...................................440
Table 31 ISAM Access Node as OFFER side (Mandatory audio)..........................441
Table 32 ISAM Access Node as ANSWER side (DTMF audio). ............................442
NT
Table 33 ISAM Access Node as ANSWER side (DTMF RFC2833).......................443

Table 34 ISAM Access Node as ANSWER side (DTMF both). ..............................444
Table 35 ISAM Access Node as ANSWER side (Mandatory audio). .....................445
Table 36 Overview of the supported supplementary services................................446
Table 37 Performance monitoring ..........................................................................448
Table 38 Detection matrix.......................................................................................462
Table 40 Overview of Per-line Statistics and Counters ..........................................476
Table 41 Overview of Per-call Statistics and Counters ..........................................478
Table 42 Overview of the Per-Board statistics and counters..................................479
Table 43 Overview of the System-wide Resource Utilization Statistics and
Counters ..................................................................................................482
Counters ..................................................................................................482
Table 45 Overview of the port states......................................................................484
Table 47 Relationship for Invite without SDP .........................................................511
Table 48 supported R2 line signals ........................................................................512
Table 49 Supported R2 Interregister Signals (Forward, use-case 1) .....................513
Table 50 Supported R2 Interregister Signals (Forward, use-case 2) .....................514
Table 51 supported R2 Interregister Signals (Backward, use-case 1) ...................515
Table 52 supported R2 Interregister Signals (Backward, use-case 2) ...................516
Table 54 Frame types.............................................................................................526
Table 55 combinations of forwarder types among downlink LTs............................558
Table 56 combinations of forwarder types among uplink and downlink LTs ..........558
Table 57 combinations of VlanPort / forwarder types allowed on the VULA
uplink .......................................................................................................559
Table 58 vMAC format for data traffic forwarding...................................................613
Table 59 vMAC format for data traffic forwarding...................................................613
Table 60 Layer 2 control protocol handling ............................................................622
Table 61 Application protocol handling...................................................................623
Table 62 Supported LAG configurations ................................................................625
Table 63 CFM elements .........................................................................................635
Table 64 Handling of IGMP packets and multicast frames in forwarders...............707
Table 65 Multicast support per port type ................................................................708
Table 66 Classes, application, and recommended 802.1p value ...........................712
Table 67 Mapping of Traffic Classes into Queues..................................................717
Table 68 QoS capabilities of UNI ports and NNI ports on GE Ethernet LT
boards......................................................................................................739
Table 69 10GE LT QoS feature list ........................................................................741
Table 70 VULA feature list per port type ................................................................742
Table 71 Downstream QoS for VULA behaviour....................................................743
NT
Table 72 VULA marker profiles ..............................................................................745

Table 73 Mapping CIR, AIR and EIR to T-CONT type ...........................................756
Table 74 Forwarding class to egress queue mapping (FD 100Gbps NT) ..............771
Table 75 Default FC to egress queue mapping (4 queue - FD 320Gbps and
FX NTs) ...................................................................................................772
FX NTs) ...................................................................................................772
22 MPLS............................................................................................785
Table 77 RSVP-TE main features ..........................................................................789
Table 78 BGP supported signaling models ............................................................791
Table 79 GFP Encapsulation overhead calculation................................................841
26 RADIUS Attributes ......................................................................857
Table 80 TL1 domain parameters ..........................................................................860
Table 81 CLI domain parameters ...........................................................................861
Table 82 CLI profile parameters .............................................................................862
NT
System Description for FD 100/320Gbps NT and FX Preface
NT
1 Preface
This preface provides general information about the documentation set for the
7302 Intelligent Services Access Manager (7302 ISAM), the 7330 Intelligent
Services Access Manager Fiber to the Node (7330 ISAM FTTN) and the 7360 ISAM
FX.
1.1 Scope
This documentation set provides information about safety, features and functionality,
ordering, hardware installation and maintenance, CLI and TL1 commands, and
software upgrade and migration procedures.
1.2 Audience
This documentation set is intended for planners, administrators, operators, and
maintenance personnel involved in installing, upgrading, or maintaining the
7302 ISAM, the 7330 ISAM FTTN or the 7360 ISAM FX.
1.3 Required knowledge

The reader must be familiar with general telecommunications principles.
1.4 Acronyms and initialisms

See the Glossary Guide for the expansion and initialisms used in this documentation
set.
1.5 Safety information

For safety information, see the Safety Manual for your product.
1.6 Documents
Refer to the Product Information document for your product to see a list of all the
relevant customer documents and their part numbers for the current release.
Preface System Description for FD 100/320Gbps NT and FX
NT
1.7 Product Naming

When the term “ISAM” is used alone, both the 7302 ISAM, the 7330 ISAM FTTN and
the 7360 ISAM FX are meant. If a feature is valid for only one of the products, the
applicability will be explicitly stated.
1.8 Special information

The following are examples of how special information is presented in this document.
Danger — Danger indicates that the described activity or
situation may result in serious personal injury or death; for
example, high voltage or electric shock hazards.
Warning — Warning indicates that the described activity or

situation may, or will, cause equipment damage or serious
performance problems.
Caution — Caution indicates that the described activity or

situation may, or will, cause service interruption.
Note — A note provides information that is, or may be, of

special interest.
1.9 Release notes

Be sure to refer to the release notes (such as the Customer Release Notes or Priority
Package Release Notes) issued for software loads of your product before you install
or use the product. The release notes provide important information about the
software load.
System Description for FD 100/320Gbps NT and FX Introduction
NT
2 Introduction
2.1 General
2.2 Supported Network Interfaces
2.3 Supported User Interfaces
2.4 Integrated DSL, Voice, Point-to-point Ethernet, GPON and Universal

NG-PON system
2.5 Document Structure
2.1 General
This document provides the system description for the following products:
• 7302 Intelligent Services Access Manager (ISAM) equipped with an FD 100 or
320Gbps NT
• 7330 ISAM Fiber To The Node (FTTN) equipped with an FD 100 or 320Gbps NT
• 7360 Intelligent Services Access Manager (ISAM) FX
For specific product details on each of these systems, see the:
• 7302 ISAM Product Information
• 7330 ISAM FTTN Product Information
• 7360 ISAM FX Product Information
The ISAM is a frame-based Multi Service Access Platform, offering high-density
copper and fiber connections for multimedia, high-speed internet access, voice and
business services.
The position of the ISAM in the network is visualized in Figure 1, showing on the left
side the different types of user interfaces that terminate on the Line Termination (LT)
boards in the system.
The ISAM can be deployed with numerous interfaces and in different network
environments.
The ISAM network architecture is shown in Figure 1.
Introduction System Description for FD 100/320Gbps NT and FX
NT
Figure 1 ISAM Network Architecture

IP Edge Router
/ BRAS
Ethernet
NSP IP backbone
Switch
ISAM
xDSL
Ethernet FE/GE/10GE/100GE
Voice EMAN NSP IP backbone

DS1/E1 FE/GE/10GE/100GE
-
Video
Wi-Fi
NSP IP backbone
ISAM
ISAM shelf
xDSL
xDSL LT
FE/GE/10GE/100GE
DS1/E1 Eth
LT GENERIC UPLINKS
Ethernet
Voice NT FE/GE/10GE/100GE
LT
Voice FE/GE/10GE
Eth
LT VULA UPLINKS
Video ONT/ OMCI GPON
ONU GPON LT FE/GE/10GE
Wi-Fi
ONT/ WM Universal
CEx
ONU NG-PON
LT
ISAM OLT
2.2 Supported Network Interfaces

Depending on the system and the deployment requirement, below uplink types can
be supported:
• GE uplink, providing different flavors with 1G, 2.5G and 10G (depending on the
selected member of ISAM product family)
• GPON uplink, choices with:
• embedded GPON MAC
• authorized GPON SFP ONT
• Bonded xDSL uplink
System Description for FD 100/320Gbps NT and FX Introduction
NT
Two types of Ethernet uplinks are supported by the ISAM:

• Generic uplink : Point-to-Point Ethernet Ethernet link (FE/GE/10GE), hosted by
the NT card, usually interconnecting the ISAM with an Aggregation Network
• VULA uplink : Point-to-Point Ethernet Ethernet link (FE/GE/10GE), hosted by an
Ethernet LT card, specifically used whenever the ISAM is used as a VULA (Virtual
Unbundled Local Access) node, that is, when Content Providers need to directly
interface with the ISAM. These links are restricted to L2 operations but offer more
VLAN/QoS features to support SLA enforcement across Content Providers
More details on every of these interfaces are available in chapter “System interface
overview”.
2.3 Supported User Interfaces

Depending on the system and the Network Termination (NT) used in that system, the
list of supported user interfaces will be different.
Depending on the type of LT boards plugged into the system, three types of user
interfaces are available:
• a number of different DSL interfaces (depending on the related DSL line board
family),
• Ethernet interfaces
• voice interfaces
In case a GPON (Gigabit Passive Optical Network) or Universal NG-PON LT is used,
depending on the type of ONU connected, the same 3 types of user interfaces are
available. In addition, also RF video overlay, Wi-Fi, and DS1/E1 interfaces can be
available via the Optical Network Units (ONU).
Every type of ONU has a number of user interfaces of a certain type, so they have to
be chosen in function of the required interfaces and functionality.
Although it is clear that the ONUs are physical units outside the ISAM shelves, often
located at customer premises, they belong to the ISAM system architecture and are
also managed from the ISAM.
It is worthwhile to emphasize the physical and conceptual place of the GPON and
Universal NG-PON functionality in the ISAM because it extends the system
boundaries up to 128 ONUs over a fiber plant that can reach tens of kilometers from
the GPON or Universal NG-PON LTs.
More details on every of these interfaces are available in chapter “System interface
overview”.
Note — Nokia Universal Next Generation PON (Universal

NG-PON) solution converges the different ITU-T 10G PON
technologies on one platform: XGS-PON (and by extension
XG-PON1) and TWDM-PON.
Introduction System Description for FD 100/320Gbps NT and FX
NT
2.4 Integrated DSL, Voice, Point-to-point

Ethernet, GPON and Universal NG-PON
system
A combination of all of above mentioned user interfaces and functionality can be
supported simultaneously in one single ISAM system, as shown in Figure 1. By
deploying xDSL, Voice, point-to-point Ethernet, GPON and Universal NG-PON LTs
together in a single shelf, a single system can support all these types of interfaces.
Therefore we can talk about an 'integrated system'.
The ISAM system can on the other hand also be used as a DSL-only, Voice-only,
point-to-point Ethernet-only, GPON-only or Universal NG-PON-only system in
function of the available network strategy decided on by the operator.
Even though the ISAM LTs and ONUs may have similar interface types (Ethernet,
xDSL and voice) they are treated separately and in a number of cases managed
through different commands and procedures.
However, for any higher layer functionality, such as Layer2 and Layer3 forwarding
protocols, ISAM provides a common management model and common
implementation
2.5 Document Structure

Following a general chapter about all system interfaces, this document is organized
in a number of functional areas providing an end-to-end view of the various ISAM
feature domains.
All chapters related to the higher layers in this document cover the ISAM as an
integrated system (see chapter “System interface overview”) because of the
common management model and implementation between xDSL, Voice,
point-to-point Ethernet, GPON and Universal NG-PON architecture.
The GPON and Universal NG-PON architecture is covered in a dedicated chapter
followed by a chapter that provides an overview of all ONU types and their respective
physical user interfaces.
System Description for FD 100/320Gbps NT and FX System interface overview
NT
3 System interface overview

3.1 General
3.2 Overview
3.3 Multi-ADSL
3.4 VDSL
3.5 SHDSL
3.6 Ethernet
3.7 GPON
3.8 TWDM-PON
3.9 Inverse multiplexing for ATM
3.10 ATM/PTM bonding
3.11 Overview of ISAM Voice interfaces
3.12 E1 TDM Interface
3.13 Overview of ONU Based UNI and Service Interfaces
3.14 Overview of ISAM support for remote management of third-party

equipment.
3.1 General
This chapter provides a general description of the system interfaces.
The ISAM can be deployed with numerous interfaces and in different network
environments. In a basic deployment, the ISAM is used to provide High-Speed
Internet (HSI), Video, and Voice over IP (VoIP) services to subscribers.
A specific use of the ISAM is to provide classic telephony services to subscribers
being connected with classic Plain Old Telephone Service (POTS) or Integrated
Services Digital Network (ISDN) lines, and to convert within the ISAM the
corresponding signals to VoIP signaling and data packets. This specific use of the
ISAM is known as ISAM Voice.
System interface overview System Description for FD 100/320Gbps NT and FX
NT
In case a Passive Optical Network (PON) is used as physical access technology, the
GPON LT or TWDM-PON LT connects via fiber interfaces to the PON and physically
terminates into the Optical Network Units (ONUs) that provides the user interfaces
for all services.
ONUs are access devices that are located at the user/customer premises. Several
types of ONU exist, more details are described in a dedicated section further in this
document
It should be clear that, due to the positioning of the ONU, this device provides the
actual user interfaces and is, together with the GPON LT respectively TWDM-PON
LT fully ISAM-internal.
Note 1 — Throughout this document, the terminology as
defined in Rec. ITU-T G.984.1 (03/2008) will be adopted for
GPON and TWDM-PON. The Optical Network Unit (ONU) is
the generic term denoting a device that terminates any one of
the distributed (leaf) endpoints of an Optical Distribution
Network, implements a PON protocol, and adapts PON PDUs
to subscriber service interfaces. In some contexts, an ONU
implies a multiple-subscriber device. The Optical Network
Termination (ONT) is a single subscriber device and is a
special case of an ONU.
Note 2 — Throughout this document, GPON is generally meant
to convey ITU based PON families (2.5/1.25G GPON, 10/2.5G
and 10/10G XGS-PON / TWDM-PON).
3.2 Overview
The following section provides an overview of the different relevant aspects for
subscriber links.
Note 1 — For ease of understanding, the ISAM Voice links are
described separately, see section “Overview of ISAM Voice
interfaces”.
Note 2 — For a clear delineation, Optical Network Unit
(ONU)-based user-facing interfaces (UNIs) are also discussed
separately, see section “Overview of ONU Based UNI and
Service Interfaces”.
3.2.1 Link transmission technology

In general, the subscriber links are terminated on the Line Termination (LT) boards.
The ISAM supports LT boards with various transmission types:
• ADSL, ADSL2, ADSL2plus, and READSL2 (ITU-T G.992)
• VDSL2 (ITU-T G.993.2)
NT
• SHDSL (ITU-T 991.2, YD/T1185-2002), IEEE 802.3

• Ethernet (IEEE 802.3)
• GPON (G.984)
• NG-PON2 - more specifically TWDM-PON (G.989)
The Ethernet subscriber links can also be terminated on the Network Termination
(NT) boards or the NT I/O boards.
In addition, Gigabit-capable Passive Optical Network (GPON) line boards provide
ISAM OLT interfaces to ONU to deliver high quality voice, video, and data services
to both single-family, multi-dwelling residential and business subscribers. The ISAM
OLT implementation is based on ITU-T and IEEE specifications, see
sections “GPON” and “TWDM-PON”.
Different boards are involved in supporting the following interfaces :
• Network links (ISAM uplinks) are terminated by the NT boards or the NTIO boards
or an Ethernet Line Termination board operating in VULA uplink mode.
• Subtending links (to the subtended ISAM) or inter-shelf links (ISAM downlinks
from the host shelf to standalone remote shelves or Remote Expansion Modules
(7356 ISAM FTTB REMs)) are terminated by the NT boards, by the NTIO boards
or by an Ethernet Line Termination board operating in
Network-to-Network-Interfacing (NNI) modus
• Expansion links to Remote Expansion Modules (7356 ISAM FTTB REMs)
operated in distributed mode are terminated by the NTIO boards.
Note — VULA : Virtual Unbundled Local Access. When a

VULA uplink is hosted by the ISAM, the Content Providers are
directly interfacing with the ISAM, requiring the ISAM to perform
SLA enforcement across Content Providers when receiving
traffic from the network.
3.2.2 Transfer modes

The ISAM supports the following transfer modes for the preceding transmission
types:
• Asynchronous Transfer Mode (ATM) is supported for all ADSL types and SHDSL.
• Packet Transfer Mode (PTM) with 64/65 octet encapsulation/Ethernet in the First
Mile (EFM) is supported for SHDSL, VDSL2, and some ADSL2/2+ LT boards.
This transfer mode uses 64/65 byte block coding of variable size frames or frame
fragments at the transmission convergence sublayer in the modem.
For PTM over ADSL2/2+, preemption is supported in the upstream direction and
enabled by default (not configurable).
• IEEE 802.3 Ethernet frame transfer
• Time Division Multiplex Mode (TDM) is supported in SHDSL
NT
• Time Division Multiplex Mode (TDM) is supported for GPON

• Time and Wavelength Division Multiplex Mode (TWDM) is supported for Universal
NG-PON (TWDM-PON)
3.2.3 Bonding
A number of methods exist to combine multiple physical links that apply the
preceding transmission types and transfer modes to a single logical subscriber
interface. This allows increasing either:
• the available service bandwidth for a subscriber
• the distance across which a standard service bandwidth package can be offered,
in case of transmission types for which the achievable link bandwidth depends
strongly on the length of the local loop
• a combination of the preceding two methods.
The same methods of combining multiple physical links can also be used to provide
a bonded copper backhaul pipe for backhaul of a subtended access node (typically
a smaller micro-node) to a hub access node.
Bonding of multiple links is possible at different levels in the ISAM, where the traffic
of DSL links is aggregated. The broader the scope of the bonding capability, the
more flexibility an operator has to configure bonding groups.
The following bonding methods are defined within the standards:
• Inverse Multiplexing for ATM (IMA): ATM Forum Specification af-phy-0086.001
• ATM Bonding: ITU-T G.998.1
• PTM Bonding: ITU-T G.998.2
• M-pair operation for SHDSL: ITU-T G.991.2
3.3 Multi-ADSL
The ISAM supports multi-ADSL subscriber lines. This section describes the different
supported ADSL types.
3.3.1 ADSL1
Asymmetric Digital Subscriber Line (ADSL) is used on existing metallic twisted pairs
(one per subscriber) between the Customer Premises Equipment (CPE) and a
Central Office (CO) exchange.
NT
A Frequency Division Multiplexing (FDM) technique allows the simultaneous use of

high-speed data services and the existing Plain Old Telephone Service (POTS) or
Integrated Services Digital Network (ISDN).
Other advantages of ADSL are:
• The existing network is used by the network operator (reducing costs).
• The existing telephone service, including equipment, is retained by the customer.
3.3.1.1 Asymmetric nature of ADSL

The digital transmission capacity of the ADSL system is asymmetric in that the
downstream and upstream bit rates are different:
• The downstream bit rate can range from 32 kb/s up to 8 Mb/s (or 15 Mb/s with the
optional S=0.5). The bit rate granularity is 32 kb/s.
• The upstream bit rate can range from 32 kb/s to 1.5 Mb/s. The bit rate granularity
is 32 kb/s.
Note — In practice, the maximum achievable upstream bit rate
is typically below 1.5 Mb/s. For example, the maximum
achievable upstream bit rate for Annex A is 1.2 Mb/s.
The chosen rate depends on the bidirectional services to be supported and the loop
characteristics.
This transmission type allows high-bandwidth services, for example, digital audio
and video (multimedia), Ethernet interconnection to the customer, and so on.
3.3.1.2 Bidirectional transport

With ADSL, the transport system provides bidirectional asymmetric communication
over a single twisted pair without repeaters.
3.3.1.3 ADSL services

The multi-ADSL mode and maximum physical bit rate is automatically determined
during initialization of the modem, based on line conditions and the line configuration.
Modem initialization is done using a predefined noise margin and within the
constraints of the transmit power spectral density. This allows various levels of
service, for example, offering the highest bit rates at a premium or ensuring a
guaranteed bit rate.
NT
3.3.1.4 Operational modes

Table 1 lists the supported ADSL1 operational modes.
Table 1 ADSL operational modes
Operation Mode Description
T1.413 Issue 2 ANSI standard; operation over POTS non-overlapped spectrum
DTS/TM-06006 ETSI standard; operation over ISDN non-overlapped spectrum
G.992.1 Annex A Also known as G.dmt; operation over POTS non-overlapped spectrum
G.992.1 Annex B Operation over ISDN non-overlapped spectrum
G.992.2 Annex A Also known as G.lite; operation over POTS non-overlapped spectrum. This standard is
a medium bandwidth version of ADSL that allows Internet access at up to 1.5 Mb/s
downstream and up to 512 kb/s upstream.
3.3.2 ADSL2
The ADSL2 family of ADSL standards adds features and functionality that boost the
performance, improve interoperability, and support new applications, services, and
deployment scenarios.
ADSL2 includes the following:
• Better rate and reach:
Improved modulation efficiency, improved initialization state machine, enhanced
signal processing algorithms, reduced framing overhead, and framing extension
allowing higher coding gain.
• Loop diagnostics:
Real-time performance-monitoring capabilities provide information regarding line
quality and noise conditions at both ends of the line (see chapter “Line testing
features”, section “Single-Ended Line Testing”). In addition, ADSL2 provides
Carrier Loop diagnostics based on Dual-Ended Line Testing (DELT) (see
chapter “Line testing features”, section “Dual-ended line testing”).
• Packet-based services:
ADSL2 amendment 1 brings native transport of packets such as Ethernet
• Impulse Noise Protection (INP):
See chapter “ADSL/VDSL features”, section “Configurable impulse noise
protection”.
• Physical Layer Retransmission (RTX):
See chapter “ADSL/VDSL features”, section “Physical Layer Retransmission
(G.INP)”.
NT
• Bonding:
ADSL2 also specifies IMA. However, this has been replaced by bonding support
as per G.998.1; see section “ATM/PTM bonding”.
• Low-power modes (L2/L3):
See chapter “ADSL/VDSL features”, section “Low-power modes”.
• Seamless Rate Adaptation (SRA):
See chapter “ADSL/VDSL features”, section “Seamless rate adaptation”.
• Carrier masking:
The carrier mask allows the suppression of each individual carrier in the upstream
and downstream direction.
• Mandatory receiver support of bit swapping:
Bit swapping reallocates data and power (that is, margin) among the allocated
subcarriers without modification of the higher layer features of the physical layer.
After a bit swapping reconfiguration, the total data rate is unchanged and the data
rate on each latency path is unchanged.
• Radio Frequency Interference (RFI) egress control and means for RFI ingress
control:
To minimize the impact of radio frequency interference from and with AM radio
and radio amateurs, multi-ADSL provides RFI egress control and means for RFI
ingress control.

Table 2 lists the supported ADSL2 operational modes.
Table 2 ADSL2 operational modes
G.992.3 Annex A Operation over POTS non-overlapped spectrum

G.992.3 Annex M Extended upstream operation (up to 3 Mb/s) over POTS non-overlapped spectrum
G.992.3 Annex J All Digital Mode operation with non-overlapped spectrum and extended upstream band
(spectrally compatible with ADSLx over ISDN)
A license counter keeps track of all the installed lines on which G.992.3 or G.992.5
Annex M is enabled.
Annex J is enabled.
NT
3.3.3 ADSL2plus
A number of applications, such as some video streams or combinations of video and
data streams, can benefit from higher downstream rates than are currently possible
with ADSL2. By doubling the ADSL frequency range up to 2.2 MHz, downstream bit
rates of up to about 25 Mb/s can be provided.

Table 3 lists the supported ADSL2plus operational modes.
Table 3 ADSL2plus operational modes
G.992.5 Annex A Operation over POTS non-overlapped spectrum
G.992.5 Annex M Extended upstream operation (up to 3 Mb/s) over POTS non-overlapped spectrum
G.992.5 Annex J All Digital Mode operation with non-overlapped spectrum and extended upstream band
(spectrally compatible with ADSLx over ISDN)
Annex M is enabled.
Annex J is enabled.
3.3.4 Reach Extended ADSL2

Reach Extended ADSL2 (READSL2) is specified by ADSL2 Annex L, proposing new
Power Spectral Density (PSD) masks that can result in a significant increase in ADSL
reach.

Table 4 lists the READSL2 operational modes.
NT
Table 4 READSL2 operational modes
G.992.3 Annex L (WIDE) Operation over POTS non-overlapped spectrum, Range-Extended Mode 1
G.992.3 Annex L (NARROW) Operation over POTS non-overlapped spectrum, Range-Extended Mode 2
3.4 VDSL
Very high bit rate Digital Subscriber Line (VDSL) allows very high speed data
transmission on a metallic twisted pair between the operator network and the
customer premises. This service is provisioned by using the existing unshielded
copper twisted pairs, without requiring repeaters. By using a Frequency Division
Multiplexing (FDM) technique, the existing POTS or ISDN services can still be
provided on the same wires. VDSL transceivers use Frequency Division Duplexing
(FDD) to separate upstream and downstream transmission.
3.4.1 VDSL1
VDSL1 mode is not supported.
3.4.2 VDSL2
The VDSL2 standard (G.993.2) is an enhancement to VDSL1. VDSL2 specifies
Discrete Multi-Tone (DMT) modulation and is reusing concepts of G.993.1 (VDSL1)
and G.992.3 (ADSL2) recommendations, using also the G.994.1 handshake
procedure.
3.4.2.1 VDSL2 features

The main features of VDSL2 are:
• VDSL2 offers Packet Transport Mode (PTM) with 64/65B encapsulation:
• The definition of profiles supports a wide range of deployment scenarios:
• deployment from the exchange (Fiber To The Exchange (FTTEx))
• deployment from the cabinet (Fiber To The Cabinet (FTTCab))
• deployment from the building (Fiber To the Building (FTTB))
NT
• VDSL2 supports higher bit rates than VDSL1; up to 100 Mb/ symmetrical.
The attainable maximum data rate depends on the VDSL2 profile used. Support
of 100 Mb/s requires the 30 MHz profile. Other profiles are better suited for
operation on longer loops, but with reduced maximum bit rate.
• VDSL2 offers improved performance over VDSL1:
• addition of Trellis coding
• increased maximum allowable transmit power
• VDSL2 features provide better support for triple play over VDSL
• improved Impulse Noise Protection (INP)
• physical layer retransmission (RTX)
• virtual noise (optional)
• VDSL2 has some ADSL2-like features:
• similar: loop diagnostics
• improved: PSD shaping
• improved management with regard to VDSL1
3.4.2.2 VDSL2 Operational Modes

Table 5 lists the supported VDSL2 operational modes.
Table 5 VDSL2 operational modes
G.993.2 profile 8A VDSL2 profile 8A

G.993.2 profile 8B VDSL2 profile 8B
G.993.2 profile 8C VDSL2 profile 8C
G.993.2 profile 8D VDSL2 profile 8D

3.4.2.3 VDSL2 profile parameter overview

VDSL2 profiles mainly define variants with different bandwidths and transmit powers.
Table 6 provides a VDSL2 profile parameter overview.
NT
Table 6 VDSL2 profile parameter overview
Parameter(1) VDSL2 profile
8A 8B 8C 8D 12A 12B 17A 35B
Max. aggregate DS transmit power (dBm) 17.5 20.5 11.5 14.5 14.5 14.5 14.5 17
Max. aggregate US transmit power (dBm) 14.5 14.5 14.5 14.5 14.5 14.5 14.5 14.5
US0 support(2) M M M M M O O M
Annex A (998) DS upper frequency (MHz) 8.5 8.5 8.5 8.5 8.5 8.5 17.664 N/A
US upper frequency (MHz) 5.2 5.2 5.2 5.2 12 12 12 N/A
Annex B (997) DS upper frequency (MHz) 7.05 7.05 7.05 7.05 7.05 7.05 N/A N/A
US upper frequency (MHz) 8.83 8.83 5.1 8.83 12 12 N/A N/A
Annex B DS upper frequency (MHz) 7.05 7.05 7.05 7.05 7.05 7.05 14 N/A
(997E)
US upper frequency (MHz) 8.832 8.832 5.1 8.832 12 12 17.664 N/A
Annex B DS upper frequency (MHz) 8.5 8.5 8.5 8.5 8.5 8.5 17.664 N/A
(998E)
Annex B DS upper frequency (MHz) 8.5 8.5 8.5 8.5 8.5 8.5 17.664 N/A
(998ADE)
Annex B DS upper frequency (MHz) N/A N/A N/A N/A N/A N/A N/A 35.3
(998E35)
US upper frequency (MHz) N/A N/A N/A N/A N/A N/A N/A 14
Annex B DS upper frequency (MHz) N/A N/A N/A N/A N/A N/A N/A 35.3
(998ADE35)
US upper frequency (MHz) N/A N/A N/A N/A N/A N/A N/A 12
Notes
(1) US=upstream; DS=downstream
(2) M=Mandatory; O=Optional; N=Not supported
3.5 SHDSL
The Symmetric High-speed Digital Subscriber Line (SHDSL) technology is a physical
layer standard based on the ITU-T Recommendation G.991.2 (G.shdsl). The
recommendation describes a versatile transmission method for data transport in the
telecommunication access networks. SHDSL supports ATM, TDM, PTM and EFM
transport.
SHDSL transceivers are designed primarily for duplex operation over mixed gauges
of two-wire twisted metallic pairs. Four-wire and M-pair operations can be used for
extended reach or bit rate. M-pair operation is supported for up to four pairs.
The use of signal regenerators for both the two-wire and multi-wire operations is
optional.
NT
Multiple SHDSL circuits may be combined to support higher bandwidth using Inverse
Multiplexing for ATM (IMA) interface or the payload can be shared by multiple circuits
(using the M-pair mode). IMA and M-pair do not work simultaneously over the same
port or circuit. Generally, an SHDSL LT in the system can support ATM or IMA, or
ITU-T G.991.2 PTM or IEEE 802.3ah EFM on a per-port basis. On certain SHDSL
LTs a number of the SHDSL ports is capable of TDM (ITU G991.2 Annex E.1 to E.8)
transport.
SHDSL transceivers are capable of supporting selected symmetric user data rates
ranging from 192 kb/s to 2312 kb/s, and optional up to 5696 kb/s, using Trellis Coded
Pulse Amplitude Modulation (TCPAM) line code. For spectral compatibility with
legacy services (including ADSLx), reach limitations can be imposed (typically by the
national regulator) in function of the SHDSL bit rate.
SHDSL transceivers support Cross-Talk Cancellation (CTC).
SHDSL transceivers do not support the use of analogue splitting technology for
coexistence with either POTS or ISDN.
3.5.1 Regional settings

Table 7 lists the supported regional settings.
Table 7 SHDSL regional settings
Standards Description
G.991.2 Annex A/F Standards applicable for North America (region 1) (ANSI)
G.991.2 Annex B/G Standards applicable for Europe (region 2) (ETSI)
3.5.2 Payload rates

The following payload rates are supported:
• 192 to 2304 kb/s in 64 kb/s steps for Annex A/B
• 192 to 5696 kb/s in 64 kb/s steps for Annex F/G
3.6 Ethernet
The ISAM supports the following Ethernet interfaces:
• Fast Ethernet (FE): supported on NT boards, NT I/O boards, and LT boards.
• Gigabit Ethernet (GE): supported on NT boards, NT I/O boards, and LT boards.
• 2.5 Gigabit Ethernet (2.5GE): supported on LT boards.
NT
• 10 Gigabit Ethernet (10GE): supported on NT boards, NT I/O boards and LT

boards.
• 100 Gigabit Ethernet (100GE): supported on NT boards,
Note 1 — The 7330 ISAM FTTN supports additional optical

uplinks through the expander unit, as well as optical expansion
links (downlinks).
Note 2 — For Ethernet features supported by the Ethernet Line
Termination (LT) boards, refer to the Unit Data Sheet (UDS) of
the relevant boards.
Ethernet offers the following advantages:

• high network reliability
• general availability of management and troubleshooting tools
• scalable to fit future needs
• low cost both in purchase and support
• easy migration from Ethernet or FE to GE
• flexible network design
3.6.1 Half and full duplex mode

Ethernet can operate in two modes:
• Half duplex: In half duplex mode, a station can only send or receive at one time.
• Full duplex: In full duplex mode, send and receive channels are separated on the
link so that a station can send and receive simultaneously.
The ISAM NTs supports both modes and can adapt to either mode by way of
auto-negotiation or manual configuration.
The ISAM Ethernet LTs only support the full duplex mode.
3.6.2 Hardware Auto-negotiation

Hardware auto-negotiation provides the capability for a device at one end of the link
segment to:
• advertise its abilities to the device at the other end (its link partner)
• detect information defining the abilities of the link partner
• determine if the two devices are compatible.
Auto-negotiation provides hands-free configuration of the two attached devices.
NT
Using auto-negotiation, the ISAM can determine the operational mode (full or half
duplex) and the speed (only for electrical interfaces) to be applied to the link.
Note 1 — It is also possible to manually configure the
transmission mode and speed on the link.
Note 2 — Auto-negotiation is supported for both optical and
electrical GE.
Auto-negotiation is supported as follows in ISAM:

For ISAM NTs: full support
For Ethernet LT:
• NELT-A: Not supported
• Non NELT-A Ethernet LTs:
• Optical GE: Supported in “advertising mode” only, i.e. the interface will communicate
its settings (default or fixed by the operator) to the peer but will not change them as
a result of the negotiation, i.e. it is up to the peer to line up its configuration to the
advertised settings.
• Electrical GE: the interface will automatically advertise support for 1000 and 100
Mb/s speeds and will adapt its speed in function of the peer capabilities. Other
parameters are only advertised and not negotiated.
3.6.3 Fiber speed auto-sensing

Dual speed optical SFPs support both 100 Mb/s and 1 Gb/s modes of operations.
When using dual speed SFPs, it is sometimes operationally easier to leave the ISAM
automatically select the link speed in function of the CPE capabilities.
Though speed selection by means of auto-negotiation is standardized for electrical
interfaces, it is not the case for optical interfaces. In order to overcome this situation,
the ISAM supports a proprietary extension allowing the operator to enable the
so-called “fiber speed auto-sensing”. Once enabled, the ISAM will automatically
detect the operating speed of the CPE and adapts its own line rate.
Note 1 — Whenever supported by the CPE (only standardized
for Gigabit Ethernet optical lines), the fiber speed auto-sensing
process will use auto-negotiation, allowing for faster
convergence (1 Gb/s line only).
Note 2 — When 100 Mb/s and 1 Gb/s rates are both supported
by the ISAM and the CPE, the highest available rate (that is, 1
Gb/s) is always selected.
See the ISAM Product Information manual for supported dual speed optical SFP
modules per board type.
NT
3.6.4 Software Auto-negotiation

Software auto-negotiation institutes a propriety protocol to negotiate a higher
communication bandwidth between two capable boards (NT board on one side and
LT board on the other side). These two boards do not necessarily have to reside in
the same shelf.
The operator can configure the highest possible bandwidth between two capable
boards via the regular management channels. The software auto-negotiation
protocol will, based on the configured values, bring the bandwidth between two
capable boards to the configured maximum speed.
In case of 7356 ISAM REM equipment, auto-negotiation will check the end-to-end
configuration based on a capability matrix of 1Gb/s / 2.5Gb/s components (for
example, SFP+/XFP capabilities, NTIO, controller board), and configure a 2.5Gb/s
link speed end-to-end if all the components support 2.5Gb/s.
3.7 GPON
The GPON interface is an optical interface that provides the ability to transport data
between the Optical Line Termination (OLT) and the Optical Network Units (ONUs).
Each GPON interface is shared by up to 128 ONUs. Some ONUs are used to
connect individual residential or business subscribers: the Single Family Unit (SFU);
others connect more residential or business subscribers: the Multi-Dwelling Unit
(MDU) and Multi-Tenant Unit (MTU).
The GPON interfaces must be considered as internal (user) interfaces while the
ONU/ONT service interfaces are the actual (external) user interfaces in this specific
case.
GPON interfaces can also be configured as subtending interfaces, similar to
subtending interfaces as offered on NT and NT I/O ports. See L2 Forwarding section
for additional details
All ISAM implementations of ONU and OLT are based on the following GPON ITU-T
standards:
• G.984.1 (GPON Service requirements)
• G.984.2 (GPON PMD layer)
• G.984.2 (GPON PMD layer) amendment 1
• G.984.3 (GPON TC Layer)
• G.984.3 (GPON TC Layer) amendments 1 and 2
• G.988 (GPON OMCI)
• G.988 (GPON OMCI) amendments 1 and 2
NT
3.7.1 Encapsulation
Data sent over the GPON interface is encapsulated in the GEM header, where GEM
stands for GPON Encapsulation Method. The GEM header includes a “GEM port” ID
which uniquely identifies a traffic flow or group of traffic flows for a specific UNI. GEM
port IDs are not exposed to the operator, but are assigned, for example, when a
VLAN port is created on a UNI. In the ONU, a GEM port ID is associated with a
specific traffic queue towards the PON. Thus the GEM port can be conceptualized
as identifying a specific traffic class within a UNI.
3.7.2 Dynamic Bandwidth Assignment

In GPON, upstream traffic from all of the ONUs on a PON is managed by the OLT
using DBA (Dynamic Bandwidth Assignment). A number of “traffic containers” or
T-CONTs are defined, each with individual upstream bandwidth attributes. Each
T-CONT is associated with a specific ONU and aggregates the traffic for one or more
GEM ports on that ONU. ONUs cannot transmit upstream data for a T-CONT without
permission from the OLT. The OLT issues a “grant” to the ONU to give it permission
to transmit data for a specific T-CONT. This way the OLT can control the upstream
transmission for all T-CONTs and ensure that all BW requirements are honored.
3.7.3 Delay tolerance

For the upstream GPON transmission, the ISAM system provides a configurable
Delay Tolerance parameter to realize optimal latency and delay variation
characteristics on the GPON link.
3.7.4 Forward Error Correction

Forward Error Correction (FEC) is used by the GPON transport layer, which involves
transmitting the data in an encoded format. The encoding introduces redundancy,
which allows the decoder to detect and correct transmission errors.
For further details, see chapter “GPON Network Architecture”.
3.7.5 OMCI
ONT Management and Control Interface (OMCI) is the ITU-T G988 based open
interface definition that provides the management model for provisioning and
surveillance related functions between OLT and ONU.
NT
3.8 TWDM-PON
The TWDM-PON interface is an optical interface that provides the ability to transport
data between the Optical Line Termination (OLT) and the Optical Network Unit
(ONU) over different wavelength pairs (also known as Channel Pairs).
Each TWDM-PON interface can be shared by up to 256 TWDM-PON ONUs. Each
wavelength pair can be shared by up to 128 TWDM-PON ONUs. Similar to GPON,
different kinds of ONUs can be distinguished: ONUs that connect individual
residential or business subscribers: the Single Family Unit (SFU) or Single Business
Unit (SBU); ONUs that connect more residential or business subscribers - the
Multi-Dwelling Unit (MDU) and Multi-Tenant Unit (MTU).
Initially, the TWDM-PON interfaces are considered to be direct user interfaces from
a capabilities and scaling perspective. In the future use of the TWDM-PON interface
as a subtending-type interface is envisioned similar to such interfaces offered on NT
and NT I/O ports. See L2 Forwarding section for additional details.
The TWDM-PON interfaces must be considered as internal (user) interfaces while
the TWDM-PON ONU/ONT service interfaces are the actual (external) user
interfaces in this specific case.
All the ISAM implementations of TWDM-PON ONU and OLT are based on the
following ITU-T standards:
• G.989.1 (NG-PON2 Service requirements)
• G.989.2 (NG-PON2 Physical media dependent (PMD) layer specification)
• G.989.3 (NG-PON2 TC Layer)
• G.988 (OMCI)
Note — The NG-PON2 standard specifies both TWDM-PON

and Point-to-Point (P2P) WDM PON. Currently, ISAM supports
TWDM-PON. Wherever NG-PON2 is mentioned in ISAM
customer documentation it should be understood as
TWDM-PON.
3.8.1 Encapsulation
Data sent over the TWDM-PON interface is encapsulated in the XGEM header. The
XGEM header includes a “XGEM port” ID which uniquely identifies a traffic flow or
group of traffic flows for a specific UNI. XGEM port IDs are not exposed to the
operator, but are assigned, for example, when a VLAN port is created on a UNI. In
the ONU, an XGEM port ID is associated with a specific traffic queue towards the
PON. Thus the XGEM port can be conceptualized as identifying a specific traffic
class within a UNI.
NT

In TWDM-PON, upstream traffic from all of the ONUs on a PON is managed by the
OLT using DBA (Dynamic Bandwidth Assignment). A number of “traffic containers”
or T-CONTs are defined, each with individual upstream bandwidth attributes. Each
T-CONT is associated with a specific ONU and aggregates the traffic for one or more
XGEM ports on that ONU. ONUs cannot transmit upstream data for a T-CONT
without permission from the OLT. The OLT issues a “grant” to the ONU to give it
permission to transmit data for a specific T-CONT. This way the OLT can control the
upstream transmission for all T-CONTs and ensure that all BW requirements are
honored.
3.8.3 Delay tolerance

For the upstream TWDM-PON transmission, the ISAM system provides a
configurable Delay Tolerance parameter to realize optimal latency and delay
variation characteristics on the TWDM-PON link.

Forward Error Correction (FEC) is used by the TWDM-PON transport layer, which
involves transmitting the data in an encoded format. The encoding introduces
redundancy, which allows the decoder to detect and correct transmission errors.
For further details, see chapter “Universal Next Generation PON Network
Architecture”.
3.8.5 OMCI
ONT Management and Control Interface (OMCI) is the ITU-T G988 based open
surveillance related functions between OLT and ONU.
3.9 Inverse multiplexing for ATM

Inverse Multiplexing for ATM (IMA) is specified by ATM Forum Specification
af-phy-0086.001.
IMA allows an ATM cell stream to be transported on a number of lower-rate physical
links. This is done by grouping these physical links into a single logical transport
channel. The bandwidth of this logical channel is approximately equal to the sum of
the transmission rates of the individual links in the IMA group.
NT
Figure 2 IMA
IMA Group IMA Group

Physical link #0
PHY PHY
Physical link #1
PHY PHY
Single ATM Cell stream Original ATM Cell
from ATM layer stream to ATM layer
Physical link #2
PHY PHY
IMA Virtual Link
IMA requires that all bonded links operate at the same nominal rate. The original cells
are not modified, and control (ICP) cells are inserted for OAM communication
between the two ends.
• In the Tx direction, the ATM cells are distributed across the links in a round robin
sequence.
• In the Rx direction, the ATM cells are recombined into a single ATM stream.
The IMA type of bonding is supported on SHDSL LT boards.
3.10 ATM/PTM bonding
3.10.1 ATM bonding

ATM bonding is specified by ITU-T G.998.1.
ATM bonding is applied to combine ATM-based transmission links with limited or
reach-dependent bandwidth, which do not exhibit an identical transmission speed,
specifically all types of ADSL. This technique does add sequence information to ATM
cells, and thus allows resequencing, that is, delay variation due to speed variation
across multiple physical links in one bonding group. Up to 2 transmission links can
be combined in one bonding group with ADSL ATM bonding.
3.10.2 PTM bonding

PTM bonding is specified by ITU-T G.998.2.
NT
PTM bonding applies to DSL links with or without identical transmission speed,
because PTM implies the use of variable size PDUs, which make the use of IMA
techniques impossible. PTM bonding is applied to combine EFM-based transmission
links with limited or reach- dependent bandwidth, specifically VDSL2, SHDSL, and
ADSL2(+). This technique adds sequence information to transmitted frames or frame
fragments, and thus allows resequencing, that is, delay variation due to speed
variations or to PDU size variations, or both, across multiple physical links in one
bonding group. Up to 8 transmission links can be combined in one bonding group
with VDSL2 or ADSL2(+) PTM bonding.
3.11 Overview of ISAM Voice interfaces

This section provides an overview of the different links of the ISAM Voice.
ISAM Voice supports LT boards with various types of Narrow Band (NB) subscriber
links:
• Plain Old Telephone Service (POTS) link
• Integrated Services Digital Network (ISDN) Basic Access (BA) link
ISAM Voice is connected to the network through Ethernet links as documented for
the ISAM. See section “Ethernet”.
3.11.1 POTS
The POTS interface is the Z interface, that is, an analog subscriber line for
connecting, for example, a POTS line. However, also other equipment such as faxes
can be connected. The principles of this interface are as standardized in ITU-T Q.551
and Q.552.
The Z interface carries signals such as speech, voice band analog data,
multi-frequency push button signals, and so on. In addition, the Z interface must
provide for DC feeding of the subscriber set and ordinary functions such as DC
signaling, ringing, metering, and so on, where appropriate.
The characteristics of this interface are as standardized in ITU-T Q.551 and Q.552.
It is recognized that the characteristics of analog interfaces vary considerably from
country to country and therefore the characteristics other than those defined in
Recommendations Q.551 and Q.552 are not subject to ITU-T Recommendations.
Within the ISAM, these are typically handled with the concept of a CDE profile.
3.11.2 ISDN BA
The ISDN BA interface corresponds to the U reference point of the Digital
Transmission System.
NT
The interface provides full-duplex and bit-independent transmission via two wires at
a net bit rate of 144 kb/s. The net bit rate of 144 kb/s offers 1 D-channel of 16 kb/s
and 2 B-channels of 64 kb/s.
The ISDN BA layer 1 specification is given in ITU-T I.430. Both 2B1Q and 4B3T
encoding are applied through the use of different HW variants.
The D-channel signaling procedures are defined in the Q.920 and Q.930-Series, for
the basis particularly in Q.921 and Q.931.
3.12 E1 TDM Interface

The ISAM supports E1 interfaces by means of a dedicated E1 TDM pseudo-wire
SFP. The E1-TDM SFP can be inserted in a standard GE SFP cage of the ISAM's
NT, NT I/O or LT board. Per need basis any Gigabit Ethernet SFP port can be
converted into a TDM port and back. See the Product Information document for your
system for supported SFP modules per board type.
By performing Circuit Emulation Services (CES) encapsulating, the E1 TDM traffic is
transported in Ethernet Layer2 packets across the ISAM and Ethernet based
network. Allowing interoperability with other CES interworking devices the E1-TDM
SFP is using the Metro Ethernet Forum standard (MEF-8) payload format and
pseudo-wire (PW) technology.
The E1-TDM SFP is a dual-channel SFP allowing terminating up to two E1 TDM
lines, with a data-rate of 2,048 Mbps per E1. The CES interworking function of the
E1-TDM SFP initiates and terminates a dedicated pseudo-wire per E1 tributary.
The E1-TDM SFP supports structure agnostic E1 operation modes only. The
line-interface supports framed-E1 for Loss Of Framing detection and CRC-4 checks.
DS0 grooming or fractional E1 is not supported.
Different line impedances (75Ω, 120Ω) are software selectable. The receiver
sensitivity can be configured depending on the required distances (Long Haul, Short
Haul). The interface type is RJ45.
Using Synchronous Ethernet between the host board and the SFP, a high accurate
clocking reference is provided to meet the wander requirements for TDM traffic.
3.13 Overview of ONU Based UNI and Service

Interfaces
The Nokia ONU products are access devices that use GPON technology to extend
a fiber optic cable from a GPON port in the ISAM to a subscriber residence or
business location. There is a variety of ONU applications including single-family
residences, multi-dwelling residences such as an apartment building, and small
office home office applications.
NT
Next to a GPON uplink towards the ISAM GPON port, the Nokia ONU products
provide the following end-user interfaces:
• Ethernet UNIs (IEEE 802.3)
• xDSL UNIs (ITU-T G.993.2 VDSL2)
• DS1/E1 UNIs (Structured and Unstructured) in CES encapsulation with MEF-8
compliant packetization format
• Voice interworking function from analog POTS lines to the VoIP/Ethernet layer
(SIP)
• RF Video for Overlay Service
3.13.1 Ethernet UNIs

The Ethernet interfaces on the ONUs support the following primary features:
• IEEE 802.3 Physical Layer
• IEEE 802.1Q, 802.1x port-based authentication, and 802.1p (QoS classification
per Ethernet port support)
• Layer 3 DSCP to 802.1p mapping to allow L3 Class of Service (CoS) over the
Layer 2 network
• Full or half duplex operations
• Auto-negotiation or manual setting of speed and operation mode
3.13.2 VDSL UNIs

The VDSL service is provided using unshielded copper twisted pairs and without
requiring repeaters. By using a Frequency Division Multiplexing technique, the
existing POTS or BR ISDN services can still be provided on the same wires. VDSL
transceivers use Frequency Division Duplexing (FDD) to separate upstream and
downstream transmission.
Additional details are provided in chapter “ADSL/VDSL features”.
3.13.3 DS1/E1 UNIs in CES Encapsulation

TDM traffic based on structured and unstructured DS1 / E1 interfaces of ONUs are
transported using Circuit Emulation Services (CES) encapsulation in Ethernet
layer-2 over the GPON using the Metro Ethernet Forum standard MEF-8 payload
structure and pseudo-wire (PW) technology, primarily for Business Services.
Additional details are provided in chapter “ISAM Support for the GPON ONU”.
NT
3.13.4 POTS UNIs in VoIP

The ONUs support the voice interworking function from the analog POTS lines to the
VoIP/Ethernet using SIP.
SIP implementation is based on RFC 3261 which contains the primary methods or
signaling messages. Additional RFCs are defined that expand on this base to provide
more complete functionality so that a complete set of call features that phone users
are accustomed to can be supported.
The connection model uses SDP in conformance with RFC 2327. The media stream
or bearer channel is based on its own protocol, RTP, which is defined in RFC3550
and RFC 3551.
3.13.5 RF Video
The ONU provides RF video service through the video overlay function. The function
operates downstream in the 1550 nm optical band. Signals sent over the overlay
network are presented to the subscriber as RF signals from a video F-type connector
in the ONU.
This service is an alternative to IGMP-based in-band video provided over HSI
services supported on Ethernet and VDSL2 UNIs.
3.14 Overview of ISAM support for remote

management of third-party equipment.
3.14.1 Purpose
ISAM supports dedicated interfaces for the remote management of co-located
third-party equipment through Ethernet connections.
Examples are power supplies, timing supplies, Automatic Distribution Frames,
environment monitoring and conditioning equipment.
NT
3.14.2 Assumptions made on third-party equipment

management traffic
The following assumptions are made about the third-party equipment management
traffic:
• The equipment uses an Ethernet interface with untagged frames for remote
management.
• The third-party equipment can be identified in the network through either:
• a pre-configured IP address, for which a destination MAC address can be retrieved
through use of the ARP protocol.
• a public MAC address.
• The third-party equipment traffic is conveyed in a dedicated VLAN. This VLAN is
configurable by the operator
• The communication protocol used for remote managing of the third-party
equipment allows detection of communication corruption or disruption.
3.14.3 Stand-alone ISAM with NT functions
3.14.3.1 Physical interface

In this case, the third-party equipment can be connected to a free Ethernet port of the
NT function. This port has to be configured as a “direct user” port. The different ISAM
NT board types either:
• provide a combo electrical 100/1000 Base-T and optical 1 GE interface as “direct
user” port
• support the use of electrical 100/1000 Base-T SFPs in external port SFP cages.
3.14.3.2 Third-party management traffic handling and

security
The applied NT port has to be configured for:
• VLAN-port tagging, with a dedicated third-party equipment management VLAN
value
• VLAN cross-connect.
NT
3.14.4 Remote LT equipment without NT functions

In the case of ISAM REM and SEM equipment, the third-party equipment can be
connected to:
• any REM/SEM equipment by means of a DSL modem with 10/100Base-T
subscriber port connected to one of the REM/SEM ports. VLAN tagging/stripping
and destination MAC address filtering are configured on the bridge port
associated to the REM/SEM DSL line used for this purpose.
• FD-REM equipment by means of a 10/100Base-T electrical interface, provided on
the REM control board NRCD-x.
In this configuration, the average traffic load must not exceed 50 kb/s, or 50
packets/s.
With the introduction of the NRCD-C control board, the allowed average traffic
load is increased to 10Mbps of mixed size packets.
3.14.5 Third-party management traffic handling and

security
The FD-REM external equipment management port has to be configured for
VLAN-port tagging, with a dedicated third-party equipment management VLAN
value.
VLAN cross-connect behavior is default and not configurable on this port.
For enhanced security in remote cabinets, it is possible to restrict allowed destination
MAC addresses in upstream Ethernet traffic on this port to a white-list of 20 MAC
address ranges. Each entry of this list consists of:
• an Original manufacturer Unique Identifier (OUI) value, covering the three Most
Significant Bytes (MSB) of the public MAC address
• a start value and an end value of a single consecutive range of MAC addresses
for the above OUI, covering at maximum the full three Least Significant Bytes
(LSB) of the public MAC address.
The ISAM itself does not support detection of malfunctions on the FD-REM external
equipment management port, and will not generate alarms related to usage of this
port
NT
System Description for FD 100/320Gbps NT and FX Failure protection and redundancy provisions in ISAM
NT
4 Failure protection and

redundancy provisions in ISAM
4.1 Overview
4.2 ISAM single shelf configurations
4.3 ISAM subtending system protection
4.4 Failure protection at layer 3
4.5 Subscriber interface redundancy
4.1 Overview
When you provide protection for system functions and subsystems by use of
redundancy, you improve the reliability of those parts of the ISAM, and hence the
availability of the whole ISAM.
4.1.1 Redundancy aspects

Redundancy has different aspects, and each aspect has its advantages and
disadvantages which must be taken into account. The following aspects are
described:
• Relation between essential and redundant resources
• Operational mode of the additional redundant resources
• The scope of the protection - the impact of a failure
• The average duration of an outage - time to repair
• The number of simultaneous failures that have to be coped with
4.1.1.1 Relation between essential and redundant

resources
Bilateral:
One redundant resource can back up only a single dedicated essential resource
(notation 1:1 or 1+1).
Failure protection and redundancy provisions in ISAM System Description for FD 100/320Gbps NT and FX
NT
The advantage is that the redundant resource can be fully preconfigured, and that
protection normally takes a minimal time. Also, the configuration data (static, or
dynamic, or both) necessary for the redundant resource can be kept on the
redundant resource itself.
The disadvantage is that each essential resource has to be duplicated, which adds
to the cost, the space requirements, and the power consumption.
Dynamic:
A redundant resource can replace any one resource out of a group of identical
essential resources (notation N:1 or N+1, or N:M or N+M in general).
Because each essential resource does not have to be duplicated, one or a few
additional resources can protect a much larger group of identical essential resources.
The disadvantage is that this scheme only is applicable when multiple identical
essential resources are present in the ISAM. In many cases, the redundant resource
cannot be fully preconfigured. The redundant resource can only be configured after
the failing resource has been identified, which means the time for protection has to
be increased by the configuration time. Also, an up-to-date copy of the static and/or
dynamic configuration data for the multiple essential resources has to be kept in a
location which is not affected by failure of the related resource. This requires either
additional storage on the redundant resource, or a more complex data storage
mechanism across all the protected resources.
4.1.1.2 Operational mode of the additional redundant

resources
Standby:
One or more redundant resources are kept inactive or on standby while one or more
essential resources perform all the required processing (notation 1:1, N:1,N:M in
general).
The advantages are that the ISAM architecture is relatively simple, and the
configuration and initialization of the redundant resource(s) starts from a well-known
state at the time of activation of the redundant resource(s) in case of a protection
switchover. The standby state can apply on the data path, the control path and/or the
management path (see “Redundancy provision” for more information and practical
examples).
The disadvantages are that the redundant resource does not contribute to the
operation (performance) of the ISAM for 99.9% or more of the time, while requiring
an additional, up to 100% investment in cost, space and power consumption. Also,
in many cases the redundant resource cannot be monitored or tested for 100% of the
functions that it has to perform, so a certain risk of dormant faults exists.
Active and load sharing:
NT
All resources (reflected in the data path, control path and/or management path) are
active or operational, normally in a load-sharing mode, but the number of resources
in the ISAM exceeds the minimum needed to perform all the necessary processing
by one, or more (notation 1+1, N+1, or N+M in general). Some resources can be
implemented in load-sharing mode, while others are implemented in active/standby
mode (see “Redundancy provision” for more information and practical examples).
If one or more of the active resources fail, the remaining resources take over the
whole processing load. Also, all the resources can be monitored in operational
conditions, and dormant faults cannot occur.
The advantage of this type of redundancy is that the ISAM performance increases
while no faults occur, by virtue of the more-than-necessary active resources.
The disadvantages are that the ISAM usually becomes more complex. A dispatching
or processing load distribution function is necessary, which must be fair (that is, the
load must be shared evenly over all the resources) and must be able to recognize
resource failures in time and to respond to them. Also, this function must not
constitute a (significant) single-point-of-failure in itself.
4.1.1.3 The scope of the protection - the impact of a failure

Usually, it is not economical to protect functions or sub-systems that affect only a
limited number of subscribers, interfaces or a limited amount of traffic. An often
applied principle is that central or aggregation resources (that is, resources whose
availability determines the availability of the whole ISAM) are protected, while
tributary resources are not protected. However, it depends on the specifics of each
individual case whether this principle is economically viable, in either direction.
4.1.1.4 The average duration of an outage - time to repair

Redundancy of a resource nearly always should be optional. In many cases the need
for providing redundancy or not for a given resource is determined by the average
time to repair. A resource in a system may be reliable enough (that is, its Mean time
Between Failure (MTBF) is low enough) to operate in a non-protected way. For
example, in an attended CO environment, where a spare parts stock and skilled staff
are available and where short detection and intervention times can be guaranteed.
However, the same resource may require redundancy when deployed in an
unattended outdoor cabinet, in order to meet the same availability as in the CO.
NT
4.1.1.5 The number of simultaneous failures that have to be

coped with
Individual Replaceable Items (RI) in modern, carrier-grade telecommunication
equipment are already highly reliable, and provide an intrinsic availability of 99.99%
or even 99.999%, within the boundaries of the specified environmental operating
conditions. In order to achieve the generally required 99.9999% availability, coping
with a single resource failure (that is, providing at most one redundant resource) is
sufficient in all circumstances. The probability of dual simultaneous failures, affecting
the same type of resource, is low enough, and does not have to be taken into account
for protection.
4.1.2 Redundancy provision

The ISAM basically provides redundancy as an option for essential central or
aggregation functions and resources. These include:
• External link protection for:
• network links
• links with sub-tended ISAMs
• Equipment protection for the ISAM:
• Data path: the Ethernet switch fabric
• Control path: the Network Termination (NT) board processor
• Management path: the NT board processor
The ISAM does not protect all the central functions or resources by default. Essential
functions and resources reside on the NT board, which can be made redundant. In
practice, a number of different configurations with single, redundant NT and single
NT IO board are possible, each supporting a different amount or type of protection.
4.1.2.1 Redundancy on FD 100Gbps/320Gbps NT and FX

NT systems
An ISAM can be configured in loadsharing mode by means of an optional second FD
100/320GbpsNT board or FX NT board. In this case the faceplate ports on both NT
boards can be configured to carry traffic (that is, active-active data plane).
The NTIO boards supported in ISAM FD will switch traffic to and from a single NT
board (that is, the “active” NT board) only. Because of this, loadsharing over the ports
connected to the NTIO board is not possible.
In addition to above mode (also known as Active/Standby), a new mode has been
introduced for specific NTIO in ISAM FX. In this new mode (also known as
Active/Active) the NTIO will exchange traffic with both NTs in a redundant pair, that
is, half of the NTIO ports are controlled/fed by NT_a, while the other half of the ports
is controlled/fed by NT_b. In this Active/Active mode, loadsharing over the ports
connected to the NTIO board is possible.
NT
Note that if an NT fails in this Active/Active mode then also the corresponding NTIO
ports will be out of service, that is, EPS and APS are no longer decoupled.
NTs with a throughput equal or higher than 320Gbps may also connect to the
network through an Ethernet LT operating in "VULA uplink" mode. These "uplink
Ethernet LTs" have a reduced set of redundancy options compared with the NT
uplinks: path and equipment redundancy can be achieved by using LAG (within the
same LT or across two different LTs) or IP routing (from the NT through different
uplink Ethernet LTs). STP, ERPS and MPLS options are not supported on VULA
uplinks.
Some LT boards are only capable of sending/receiving traffic to/from a single NT
board (that is, the “active” NT board). Consequently, no loadsharing is possible
between the NT board and these LTs. This means that all traffic to/from these LTs
will pass through the “active” NT board. Other LT boards (predominantly fiber line
cards) are capable of sending/receiving traffic to/from both NT boards. Hence,
loadsharing is possible between the NT board and these LTs.
The control plane is managed on the active NT board but the control plane is fully
synchronized between the two NT boards. The control plane is fully synchronized for
the following protocols:
• L1: port state configuration synchronization and port state changes are forwarded
and handled by the active control plane
• L2: MAC learning, LACP, 802.1X and IGMP snooping
• 802.1X sessions recover after switchover. That is, all the users that have been
authenticated remain authenticated.
• L3:
• static routes, IP interfaces and ARP
• Routing protocols: OSPF, IS-IS, BGP, PIM-SSM
• DHCPv4 and DHCPv6 state information
• QoS, ACLs and security configuration, that is, filters.
For a number of protocols such as SyncE, no hitless control plane switchover is

supported. After switchover these protocols will need to be established from scratch
as if on a simplex system.
After switchover, the data plane and the control plane (for the supported protocols)
are immediately recovered. The management plane recovery is artificially delayed
and is restored at the moment the new active NT board is fully initialized.
4.2 ISAM single shelf configurations

.
NT
4.2.1 Single NT
When using a single NT board in the ISAM shelf, only redundancy for external
(network or subtending) links is available, and hence only external link protection is
possible. None of the central functions and resources are duplicated, except for the
external Ethernet interfaces on the faceplate of the NT board itself. The actual
number of these interfaces may vary with the NT type, but equals at least two. This
implies that one or more external network or subtending links can be configured to
protect other network or subtending links on the same NT board.
It must be clear that this link-only protection model does not protect equipment. If the
NT board fails, connectivity on all the links will be lost. The supported mechanisms
are described below.
4.2.1.1 External link protection: active/standby NT links

External NT links of the ISAM can be configured in active/standby mode on the single
NT board of the ISAM. In case an active NT link fails, all traffic will be switched to the
designated standby NT link as shown in Figure 3.
Figure 3 Link protection with active/standby external NT link
LT1 NT
Active
PHY
Standby
µP PHY
LTn
Link failure on the active NT link is detected by either:

• detection of “Loss of Signal” on the NT link
• the (Rapid) Spanning Tree Protocol (RSTP) or Multiple Instances Spanning Tree
Protocol (MSTP). Normally, xSTP will allow only one network link to be active,
while all other network links will be forced to standby, in order to avoid loops in the
Ethernet network.
NT
4.2.1.2 External link protection: Link aggregation

A set of N (1 ≤ N ≤ 8) physical NT interfaces can be configured in load-sharing mode
(link aggregation) as shown in Figure 4. Apart from increasing the capacity of the
resulting ISAM single network interface, this configuration also provides link
protection.
Figure 4 Link protection with load-sharing external NT links
LT1 NT
PHY 1
µP PHY 2
LTn
If an external link for a single NT with multiple external links in a load-sharing group
is lost, the traffic is redistributed across the remaining links of the load-sharing group,
by means of the link failure detection capability of the Link Aggregation Control
Protocol (LACP).
4.2.2 Single NT, with NTIO

When extending the preceding configuration with an additional NTIO board in the
ISAM shelf, only the number of external Ethernet interfaces is increased by the
number available on the NTIO board faceplate. This number may vary with the NTIO
board type.
Still none of the central functions and resources are duplicated beyond what is
available on the NT + NTIO board itself. Again, one or more external network or
subtending links can be configured to protect others on the same NT board, by either
(R)STP, MSTP or by LACP.
NT
Figure 5 Link protection with load-sharing external NT links

LT1 NT
PHY
µP PHY
NTIO
PHY
PHY
LTn PHY
PHY
PHY
PHY
4.2.3 Dual NT (loadsharing), no NTIO

The FD 100/320Gbps NT/ FX NT system supports loadsharing of the data and
control layer. The dataplane is physically loadshared and the control plane is fully
synchronized between the two NT boards. This means that the external links on the
faceplate of both NT boards can be used to connect to the network and that every
one of these links is active at the same time.
Note — For DSL LTs, the data plane is only physically
loadshared on the network side. Loadsharing from NT towards
the DSL LTs is not supported yet, but it is supported on GPON
LTs, TWDM-PON LT’s and P2P LTs.
The FD 100/320Gbps NT/ FX NT system supports an active/standby NT equipment

protection at the same time (that is, only one of the two NT boards can be active at
a time). After switchover, the control plane on the new active NT board will get full
control over the synchronized control plane. The dataplane via the faceplate ports is
possibly impacted by the reset of the previous active NT board. An LAG over the
faceplate ports of the two NT boards is a good protection in this case. NT switchover
is not revertive after the repair of a failed NT board. The following protection
capabilities exist:
4.2.3.1 NT equipment protection with distributed external

links
Figure 6 illustrates the usual configuration with a redundant NT pair, supporting a
loadshared external link configuration. The active external links are connected to the
active NT board and the standby NT board.
NT
The operator can:

• configure a number of external link groups on the NT board (active and/or
standby)
• designate any external link of the NT board to be a member of one of the groups
• configure a threshold for the minimum number of operational external links in
each group.
Figure 6 NT equipment protection with distributed external links
LT1 NT
Active
PHY
µP PHY
LTn
LT1 NT
Active
PHY
µP PHY
LTn
NT protection, that is, switchover of control and management traffic from the active
NT board to the standby NT board, and a related status change for both NT boards,
is only triggered by the failure or removal of the NT board itself, detected by means
of a dedicated protection interface between both NT boards.
This means that a failure of the active NT board or the standby NT board will have
an impact on the data traffic over the external links that can be active on both NT
boards (this can be protected by configuration of a LAG protection group over the
faceplate ports of the two NT boards, though, see “NT equipment protection with
distributed external links”), but also that a failure of the external faceplate links will
have no influence on the switchover between the active NT board and the standby
NT board.
NT
4.2.3.2 NT equipment protection with distributed external

links (load aggregation)
Figure 7 shows a configuration with multiple external links that are grouped in a load
aggregation group over the two NT boards.
Figure 7 NT equipment protection with distributed external links (load
aggregation)
LT1 NT
PHY 1
µP PHY 2
LTn
LT1 NT
PHY 3
µP PHY 4
LTn
NT protection, that is, switchover of control and management traffic from the active
NT board to the standby NT board, and a related status change for both NT boards,
is only triggered by the failure or removal of the NT board itself, detected by means
of a dedicated protection interface between both NT boards.
This means that a failure of the active NT board or the standby NT board will have
an impact on the data traffic over the external links that can be active on both NT
boards (protected by the LAG), but also that a failure of the external faceplate links
will have no influence on the switchover between the active NT board and the
standby NT board.
NT
4.2.4 Dual NT, with NTIO operating in Active/Standby

mode
Figure 8 shows a redundant NT pair configuration with NTIO board. The NTIO board
enables independent external link protection and NT board equipment protection, for
external links connected to the NTIO board. The NTIO board replaces the passive
optical splitter(s) with an active board. The NTIO board eliminates the optical power
budget reduction caused by the use of an optical splitter, and enables independent
external link protection and NT board equipment protection, for electrical external
links, if connected to the NTIO board.
The external links on the NTIO board can be configured in active/standby mode, or
in load aggregation group mode, as already discussed above.
There is also no different behavior for the FD 100/320Gbps NT board / FX NT board
system (see “NT equipment protection with distributed external links”) since the
external links via the NTIO board are shared over the active NT board and the
standby NT board and only the active NT board will be able to use these links. This
means that FD 100/320Gbps NT system uplinks and FX NT system uplinks are only
data-path loadshared for the faceplate ports. The uplinks connected to the current
NTIOs are not loadshared, but physically flipped (SAS controlled) towards the active
NT.
In a redundant NT pair configuration with NTIO board, the external links on the
faceplate of each NT board, and the external links on the face plate of the common
NTIO board in practice cannot be combined as such in a same group, for example
for constructing a bigger load aggregation group.
The reason is that in case of NT board switchover, the external links of the NTIO
board will be reconnected automatically to the new active NT board, while the same
is not possible for external links plugged directly to the NT board faceplate. It is
possible to combine both types of external links in a same load aggregation group
when an optical splitter is used for connecting the external links to the NT board
faceplate(s), as discussed for previous configurations.
It should be noted that the NTIO board is not duplicated, and, therefore, not
protected. However, the probability of an NTIO failure that affects all of its external
interfaces is low, so in case of a failure, outage for all of its external links will be
limited to the actual duration of the board replacement.
NT
Figure 8 Independent load sharing external link and NT protection with

NT
LT1 NT
PHY
µP PHY
NTIO
PHY Active
PHY
PHY 1
LTn
PHY 2
LT1 NT PHY
PHY PHY
µP PHY
LTn
4.2.5 Dual NT, with NTIO operating in Active/Active mode

Figure 9 shows a redundant NT pair configuration with NTIO board operating in
Active/Active mode as supported on some FX NTIOs. In this mode external link
protection and NT board equipment protection are coupled, that is, if one NT fails
then also the corresponding links on the NTIO will be out of service..
The external links on the NTIO board can be configured in active/standby mode, or
in load aggregation group mode.
Both the active NT and the standby NT will be able to use (part of) the NTIO links
when the NTIO is operating in Active/Active mode. From a loadsharing point of view
these NTIO ports are not different from the faceplate ports
In a redundant NT pair configuration with NTIO board operating in Active/Active
mode, the external links on the faceplate of each NT board, and the external links on
the face plate of the common NTIO board can be combined in a same group, for
example for constructing a bigger load aggregation group.
NT
Figure 9 NTIO operating in Active/Active mode
LT1 NT
µP
NTIO
PHY Active
PHY
PHY 1
LTn
PHY 2
LT1 NT PHY
PHY
µP
PHY
PHY
LTn
4.2.6 LT Loadsharing
In a redundant NT configuration, the backplane links from the LT to the two NTs are
able to loadshare the upstream and downstream traffic.
In downstream the load sharing NTs should be capable of splitting the traffic across
the backplane links towards the LT and in upstream direction the loadsharing LT
should be capable of distributing the traffic towards the NT, thus doubling the
backplane capacity.
4.3 ISAM subtending system protection

You can cascade multiple single-shelf ISAM systems using standard Ethernet
subtending links. ISAM shelves can be connected together to provide a consolidated
interface to the network.
In principle, all of the above protection techniques and configurations can be applied,
for either network type links and subtending type links, or both. This depends on the
required link capacity for each type, and on the interface capacity of the applied NT
and NTIO board types. (R)STP, MSTP and LACP are supported on ISAM external
interfaces for subtending.
NT
The following topologies show some examples for cascading of ISAM equipment
with protection:
• star topology; see Figure 10
• daisy-chain topology; see Figure 11
• ring topology: daisy chain with the last node connected to the first; see Figure 12.
Up to three levels of cascading can be supported by the ISAM. It depends on the
operator network requirements what the actual appropriate number can be in
practice.
The last ISAM in the cascaded system can be any DSLAM, such as:
• a 7302 ISAM
• a 7300 ASAM with a FENT or GENT
• a 7325 Remote Unit
• a 7330 ISAM FTTN
• a 7360 ISAM FX
Figure 10 Example of an ISAM subtending star topology

NT
μP PHY
PHY
Subtending
NTIO LAG links
PHY
PHY
PHY
μP NT PHY
N
PHY
T
PHY PHY
PHY
NT
μP PHY
PHY
NTIO
PHY
PHY
PHY Network
μP NT PHY
N
PHY links
T
PHY PHY
PHY
NT
μP PHY
PHY
NTIO LAG
PHY
PHY
PHY Subtending
μP NT PHY links
N
PHY
T
PHY PHY
PHY
NT
Figure 11 Example of an ISAM subtending daisy chain topology

NT
μP PHY
PHY Subtending
NTIO links active
PHY
PHY
PHY
NT
LAG
μP N
PHY
PHY
T
PHY PHY
PHY
NT NT
μP PHY μP PHY
PHY PHY
NTIO LAG NTIO
PHY PHY
PHY PHY
PHY PHY
μP NT PHY μP NT PHY
N
PHY N
PHY
T
PHY PHY T
PHY PHY
PHY PHY
Network
NT
links
μP PHY
PHY
NTIO
PHY
PHY
PHY LAG
μP NT PHY
N
PHY
T
PHY PHY
PHY
NT
Figure 12 Example of an ISAM subtending ring topology

NT
μP PHY
PHY Subtending
NTIO links active
PHY
PHY
PHY
μP NT PHY
N
PHY
T
PHY PHY
PHY
NT NT
μP PHY μP PHY
PHY PHY
NTIO NTIO
PHY PHY
PHY PHY
PHY PHY Network
μP NT PHY μP NT PHY links
N
PHY N
PHY
T
PHY PHY T
PHY PHY
PHY PHY
NT
μP PHY
PHY
NTIO
PHY
PHY
PHY
μP NT PHY
N
PHY
T
PHY PHY
PHY
4.4 Failure protection at layer 3

When the ISAM is configured as a router in an layer 3 network, then connectivity
protection can be achieved by enabling one or more of the following layer 3 features:
• Routing protocols: RIP, OSPF
• ECMP (supported on static routes and OSPF routes)
An example is given below whereby the ISAM is used as a router in a layer 3 network
and connected to more than one edge router on different subnets and physical ports.
Layer 3 packets will be routed over the best route selected by OSPF.
NT
Figure 13 Example of layer3-based protection

Subnet 1
LT 1 NT
PHY Edge router 1
µP
PHY Edge router 2
Subnet 2
L3 switching and
OSPF enabled
LT n
4.5 Subscriber interface redundancy

The ISAM provides subscriber interface redundancy for important subscriber
interface which can be:
• lines that are connected with business users or small access Nodes (PON/LAN
ONU/ONT)
• lines that representing high-capacity access points (Point to point fiber, GPON)
4.5.1 Ethernet link protection

Ethernet interfaces hosted by the Ethernet LT can be used to connect critical
resources like business users, mobile base station, or subtended DSLAMs where
link protection is often required.
The redundancy options offered by GE LTs are as follows:
• LAG:
Up to eight links can be grouped into a LAG, provided the following conditions are
fulfilled:
• they share the same interface type (UNI, HC-UNI or NNI)
• they share the same fixed line rate (FE, GE)
• all the link members of the LAG are hosted by the same LT (intra-card LAG) and they
all belong to either the port range 1…18 or the port range 19…36
Dynamic (with LACP) and static (without LACP) LAG variants can be configured.
Load sharing is based on MAC and/or IP addresses (configuration options).
NT
• RSTP/MSTP:
Any link (including a logical link corresponding to a LAG) can be associated with
an xSTP instance provided they share the same interface type (NNI) and are
located onto the same LT board (intra-card xSTP). The following additional
constraints apply:
• xSTP is only supported with the iBridge model (not with VLAN cross-connect)
• xSTP on the Ethernet LT assumes the LT interface to be root bridge and must be
configured accordingly by the operator.
NT and LT xSTP instances are split, that is the NT links and the LT links are not
part of the same protection domain. A link event failure at the LT side is not
signaled by the NT towards the network and inversely meaning that cross-LT or
cross-ISAM link protection schemes are not supported
The redundancy options offered by 10GE LTs are as follows:

• LAG:
Up to eight links can be grouped into a LAG, provided they share the same fixed
line rate (FE, GE, 10GE) and are of the same type (Uplink, NNI, UNI).
Two variants are supported:
• Intra-LT LAG:
Beside the fact that all LAG members must reside on the same LT, there is no
restriction on the port position.
Dynamic (with LACP) and static (without LACP) LAG variants can be configured.
Load sharing is based on MAC and/or IP addresses (configuration options).
• Inter-LT LAG:
This LAG variant combines link and equipment protection by distributing the LAG
members over two different LTs. Switch-over from the active link to the standby one
can be triggered by various events: LACP event, link failure, board failure, forced
switch-over request from the operator.
Inter-LT LAGs are subject to following deployment rules:
* Only Active/Standby LAG is supported.
* Revertive and non-revertive switch-over options are supported for tighter path
control (for instance increase reliability when considering multiple faults, traffic
engineering needs and so on)
* The two LAG members must be located on two 10GE LT positioned in adjacent
slots (1 and 2, 3 and 4, …) but there is no restriction on the port position of each LAG
member on the 10GE LTs themselves.
* Dynamic LAG (with LACP) is recommended for optimal performances.
NT
• RSTP/MSTP:
Any link, including a logical link corresponding to a LAG, can be associated with
an xSTP instance provided they share the same interface type (NNI) and are
located onto the same LT (intra-card xSTP). Following additional constraints
apply:
• xSTP is only supported with the i-bridge model (no VLAN-CC)
• xSTP on the Ethernet LT assumes the LT interface to be root bridge and must be
configured accordingly by the operator.
NT and LT xSTP instances are split: the NT and LT links are not part of the same
protection domain (that is, a link event failure at the LT side is not signaled by the
NT towards the network and inversely meaning that cross-LT or cross-ISAM link
protection schemes are not supported)
Table 8 Overview of link protection options in function of the Ethernet LT

interface types
Ethernet LT type GE LT 10GE LT
Supported link protection option LAG xSTP LAG xSTP
Intra-LT Inter-LT
UNI Y N Y Y N.A.
Hi-Cap UNI N N N.A. N.A. N.A.
NNI Y Y Y Y N
Uplink N.A. N.A. Y Y N
4.5.2 PON Link Protection

.
Note 1 — In his release, the GPON Link Protection feature is
supported both on 7302/7330 ISAM FD (in combination with
NANT-E) and on 7360 ISAM FX (in combination with
FANT-F/FANT-G). The XGS-PON Link Protection feature is
supported on FWLT-B in combination with FANT-F/FANT-G on
7360 ISAM FX.
Note 2 — Two LTs involved in a PON Link protection
arrangement must be of the same board type.
Large bundles of feeders in a cable or duct increase the risk of intolerable repair
times in case of a breach or an accident.
NT
The increasing number of split ratios and deployment of business-critical services

highlight the importance of implementing PON protection schemes. This is even
more relevant as the PON standards evolve towards technologies providing always
higher throughputs.
ITU-T specification G984 and G.sup51 describe multiple PON protection schemes.
ISAM GPON and XGS-PON line cards implement the Type-B PON protection
defined by ITU-T, which addresses route diversity to the first splitter in a 1:1
active/standby arrangement as shown in Figure 14.
Figure 14 Type-B PON Protection
ONU #1
PON LT N:2 optical splitter

OLT
PON
LT (1)
PON
LT (0)
ONU #N
PON LT
The ports (or channel-pairs) of the ISAM can be configured in Protection Groups (that
is a pair of ports protecting each other) on the LT boards across the shelf. In case of
failure of the active PON link, all traffic is switched to the associated protecting PON
link without loss of service. At any time, only one of the two ports will transmit on the
fiber in downstream (active-standby), while both will monitor the upstream signal
coming from the ONTs.
From the topology point of view, the Type-B PON protection arrangement can be
achieved by connecting two fibers from their respective ISAM PON interface to the
first level 2:N optical splitter. Link failure on the active PON feeder is detected by a
"Loss of Signal" condition. Note that the operator also has the ability to trigger a
manual PON switchover.
In the current ISAM implementation, inter-card protection among the LT boards of the
same type is supported. This is the most logical use case from an equipment
protection perspective. It implies that:
• two ports belonging to the same board cannot be paired into protection groups,
• the PONs in a protection group must be terminated by LT boards of the same
type.
NT
Service continuity is achieved by:

• a replication of the - static - configuration data from the active PON towards the
standby PON, at provisioning time;
• a continuous background synchronization of the - dynamic - service-related data,
from the active port towards the standby port.
The system can raise an alarm if it detects that the standby side is not in condition to
take over all traffic and services immediately in case of active PON failure.
Note — The current implementation does not provide

protection coverage for IPv6/DHCPv6 relay, CFM/OAM, PM
and Troubleshooting counters.
For 802.1x/RADIUS authentication, the static configurations
will be duplicated between protected PON ports. However,
there will be no dynamic synchronization of 802.1x related data,
so the existing secure sessions will not be maintained. Upon
PON switchover, the system will clean the previous 802.1x
session and trigger re-authentication on the new-active PON
port.
Continuity and recovery of other services and protocols after
switchover are guaranteed.
A license counter keeps track of the number of configured Protection Groups, with a
current maximum of 62 configurable protection pairs allowed in the same OLT
system.
4.5.3 Protection via ONU Wavelength Mobility on

TWDM-PON
In NG-PON2 (ITU-T G.989 series), a TWDM PON system is defined as a multiple
wavelength PON system in which each wavelength channel may be shared among
multiple ONUs by employing time division multiplexing and multiple access
mechanisms. The intrinsic multi-wavelength characteristic of this technology can be
leveraged on to increase, among others, the PON network resilience.
An operator will typically configure a channel-pair (a set of one downstream
wavelength channel and one upstream wavelength channel that provides
connectivity between an OLT and one or more ONUs, terminated on a specific OLT
port) as the "preferred" channel-pair for each ONU provisioned on the TWDM PON
system, respectively. This is the channel-pair on which a specific ONU is expected
to be in service.
Next to the "preferred" channel-pair, the operator can also configure a "protection"
channel-pair on a per-ONU basis. Such protected ONU will autonomously re-tune its
laser to the protection (standby) channel as soon as it detects a loss of downstream
signal on its current (active) channel. Doing so, the traffic interruption will be
minimized and the services won't be lost.
NT
Next to protecting the channel attachment fiber, this feature can also protect the
ONUs from OLT equipment failure (that is a linecard failure): if the board hosting the
active channel-pair of a set of protected ONUs fails, the affected ONUs will
autonomously re-tune their transceiver to their respective standby channel-pair,
hosted by a different linecard. This is the reason why, for each ONU, its "preferred"
and "protection" channel-pair attributes must be terminated by two different
linecards. Additionally, this feature can also be useful to minimize the service
interruption during maintenance operations.
Figure 15 up to Figure 17 show the protection mechanism.
Figure 15 Protection switching via autonomous ONU re-tuning on a TWDM PON system
(normal operation)
OLT
WM
1 λ
λ1u,d
3 λ
λ2u,d
λ3u,d
λ4u,d
Figure 16 Protection switching via autonomous ONU re-tuning on a TWDM PON system (at
failure)
OLT
WM λ
1
λ1u,d
3 λ
λ2u,d
λ3u,d
λ4u,d
NT
Figure 17 Protection switching via autonomous ONU re-tuning on a TWDM PON system
(protected mode)
OLT
WM
1
λ1u,d
3
λ2u,d
λ3u,d
λ4u,d
This protection feature can be enabled at a per-ONU granularity. Multiple ONUs can
share the same "preferred" and/or "protection" channel-pair attributes. Also, a same
channel-pair may be configured as "preferred" channel-pair for a particular (set of)
ONU(s) and in parallel be configured as "protection" channel-pair for another
(non-overlapping set of) ONU(s).
Note 1 — In the current release, this feature is supported on
FWLT-A in combination with FANT-F and covers protection for
cross-connect services when MAC address learning is disabled
in the NT.
Note 2 — The system does not support the consistent
equalization delay method (cf. G.989.3 - section VII.2) in the
current release. Consequently, to avoid a re-ranging of the
ONUs upon automatic re-tuning, the channel attachment fiber
(the individual pieces of fiber connecting an TWDM PON
OLT-port to each WM input) must have the same length for all
the channel-pairs sharing the same subchannel-group.
NT
System Description for FD 100/320Gbps NT and FX Management
NT
5 Management
5.1 Overview
5.2 Management interfaces
5.3 Management interfaces security
5.4 Management access models
5.5 Counters and statistics
5.6 Alarm management
5.7 Software and database management
5.8 Equipment monitoring
5.9 Zero Touch Provisioning
5.1 Overview
This chapter describes various management related topics of the ISAM. Table 9
below lists the information available in this chapter.
Table 9 Contents
Contents Section
Management interfaces 5.2
Management interfaces security 5.3
Management access models 5.4
Counters and statistics 5.5
Alarm management 5.6
Software and database management 5.7
Equipment monitoring 5.8
The Nokia-recommended management architecture is shown in Figure 18.
Management System Description for FD 100/320Gbps NT and FX
NT
Figure 18 ISAM management

OSS
SOAP XML TL1 SOAP XML

xFTP
TL1 5529 5529 5529
5529 GW IDM OAD APC
5530 SDC
NA 5520 AMS PBMT
TL1
xFTP xFTP CLI xFTP
SNMP SNMP
Remote
CT
TL1
CLI
CLI SNMP
TL1 xFTP
Local TL1
ISAM
CT CLI
Nokia has an extensive management suite of products available (5520, 5529, 5530
range of Nokia products) to allow an efficient management of an ISAM network.
Southbound, towards the ISAM, it takes care of all ISAM specifics and related
protocols, while northbound it provides standard SOAP/XML interfaces for an easy
and smooth integration with any other OSS applications, shielding from the DSLAM
complexity.
Of course a direct interaction with the ISAM itself, using CLI or TL1, remains
possible, either directly connected to the ISAM or using a remote Craft terminal.
5.2 Management interfaces

The ISAM supports the following management interfaces:
• Simple Network Management Protocol (SNMP)
• Command Line Interface (CLI)
• Transaction Language 1 (TL1)
• File Transfer Protocols: TFTP, SFTP, and FTP
• Simple Network Time Protocol (SNTP)
• Secure Shell (SSH)
• System logging (Syslog)
• Debug port for troubleshooting
NT
These management interfaces are all supported “inband”. This means that the
management interface is supported on top of an Ethernet / IP stack for which the
Ethernet links are the Ethernet network links as mentioned in chapter “System
interface overview”. If one such network link or uplink is dedicated only for
management traffic, outband management can be realized as well.
Note — When a firewall is in place between the network

management stations and the ISAM network, it is required that
the following UDP ports are opened on the firewall (for
troubleshooting and migration reasons):
• UDP port 23 as destination port
• UDP ports 928 – 939 (928 and 939 included) as source and
destination ports
Not opening these ports on the firewall may lead to a reduced

or failed troubleshooting access, or a failure to perform an
ISAM migration, or both.
Figure 19 Secure and insecure management interfaces
Individual security control per management channel
RS232
serial interface
CLI TL1 SNMP File transfer
CLI Agent TL1 Agent SNMP SNMP Client Server Client Server Client
v1/v2 v3 TFTP SFTP FTP
SNMP
Telnet SSH Telnet SSH 161/162
server server server server 13001
23 22 1023 1022 69 115 20
UDP
TCP TCP UDP UDP TCP
Secure Secure Secure Secure

Insecure Insecure Insecure Insecure Insecure Insecure
Mutually exclusive
5.2.1 SNMP
The Simple Network Manager Protocol (SNMP) is used by network management
applications like the 5520 AMS, the 5529 Statistics and Data Collector, or the 5530
Network Analyser to manage the ISAM.
NT
Three versions of SNMP exist:

• SNMP version 1 (SNMPv1) uses a community string (that is, a plain-text
password in the SNMP messages) to verify if a request may be executed or not.
This is very insecure.
• SNMP version2 (SNMPv2) has the same syntax and security level as SNMPv1,
but has more commands, more error codes, different trap, and improved
response
• SNMP version 3 (SNMPv3) provides authentication, privacy and administration
for safe configuration and control operation. SNMPv3 also offers
transaction-by-transaction security configuration settings.
Note — SNMPv3 is supported by default. but also SNMPv2

and SNMPv1 messages can be processed.
5.2.1.1 SNMPv3
The security mechanisms defined in SNMPv3 protect against threats such as
masquerade, modification of information, message stream modification, and
disclosure.
The SNMPv3 security mechanisms provide:
• data origin authentication
• data integrity checks
• timeliness indicator
• encryption
SNMPv3 allows for three different security levels in that messages between agent
and manager can be:
• unauthenticated and unencrypted
• authenticated but unencrypted
• both authenticated and encrypted
Two security-related capabilities are defined in SNMPv3:
1 User-based Security Model (USM):
The USM provides authentication and privacy (encryption) functions and
operates at the message level. In addition, the USM includes a key management
capability that provides for key localization and key updates. The USM is used to
authenticate entities, and provides encryption services to secure communication
between agents and managers. Each agent keeps track of the authorized user
access via an internal table of user/secrets/access entries. Both authentication

NT
and encryption utilize symmetric keys, which can be generated from a password.
Localization of the authentication, and encryption of keys by hashing the
generated key with the ID of each agent entity is strongly recommended.
2 View-based Access Control Model (VACM):
The VACM verifies whether a given user is allowed to access a particular MIB
object and perform particular functions (MIB views: read, write or notify access).
The VACM makes an access control decision on the basis of:
• the principal asking for access
• the security model and security level used for communicating the request
• the context to which access is requested
• the type of access requested (read, write, notify)
• the actual object to which access is requested.
5.2.2 TL1
The ISAM supports Transaction Language 1 (TL1) as management interface. This
cross-vendor, cross-technology man-machine language is supported over UDP,
telnet and SSH.
Please check the following documents for the full list and details of all the supported
TL1 commands and events in the ISAM:
• Operations and Maintenance Using TL1 for FD 100/320Gbps NT and FX NT
• TL1 Commands and Messages Guide for FD 100/320Gbps NT and FX NT
In total, maximum 16 TL1 parallel sessions are supported. The following restrictions
and conditions apply depending on the type of session:
A maximum of 10 TL1 sessions that can be of the following type:
• two sessions are reserved for CRAFT/Serial access
• up to five parallel TL1 sessions over Telnet (TCP) can be used
• up to five parallel TL1 sessions over SSH (TCP) can be used
In addition another maximum of 6 UDP sessions are supported.
When using TL1 scripts, it is recommended to strictly limit the number of active,
parallel TL1 scripts to two. Anyway the TL1 response should be awaited before
launching a new TL1 command to the ISAM.
An alarm is raised whenever a TL1 user logs in (successful or not), indicating the IP
address, account name and timestamp of the login trial. Severity, reporting and so
on of this alarm can be configured as with any other alarm. If the login was not
successful, the corresponding alarm needs to be cleared manually by the operator.

NT
To avoid an overflow of failed login alarms (for example, due to a malicious user), a
new failed login alarm will only be generated either when 3 minutes have passed
since the last failed login alarm or when 90 failed logins occurred, whichever comes
first.
The TL1 login banner is configurable.
Note — The ISAM will refuse any TL1/UDP connection with a

source port < 12 to protect the ISAM against malicious attacks.
5.2.3 CLI
The ISAM supports a Command Line Interface (CLI) as management interface. This
interface is primarily intended as a man-machine interface for the ISAM and is
supported over telnet, SHH, and using the serial interface (Craft).
Please check the following documents for the full list and details of all the supported
CLI commands and events in the ISAM:
• Operations and Maintenance using CLI for FD 100/320Gbps NT and FX NT
• CLI Command Guide for FD 100/320Gbps NT and FX NT
The ISAM supports up to ten parallel CLI sessions, be it over telnet or over SSH.
There can only be 1 local Craft session.
An alarm is raised whenever a CLI user logs in (successful or not), indicating the IP
address, account name and timestamp of the login trial. Severity, reporting and so
on of this alarm can be configured as with any other alarm. If the login was not
successful, the corresponding alarm needs to be cleared manually by the operator.
To avoid an overflow of failed login alarms (for example, due to a malicious user), a
new failed login alarm will only be generated either when 3 minutes have passed
since the last failed login alarm or when 90 failed logins occurred, whichever comes
first.
5.2.4 xFTP
5.2.4.1 File Transfer Protocols

The ISAM supports 3 file transfer protocols: FTP, TFTP and SFTP.

NT
TFTP is the simplest of the 3 file transfer protocols, but lacks reliability and security
capabilities. It runs on top of UDP and does not require any username-password
combination. There is also no encryption of data. The ISAM supports both a TFTP
client and server. In server mode, the ISAM can handle up to 14 TFTP sessions.
FTP also lacks any encryption, but requires a username-password identification
(“anonymous” access is not allowed) and runs on top of TCP/IP. The ISAM only
supports an FTP client.
SFTP has been introduced as part of the SSH implementation. When the ISAM acts
as an SFTP client towards an external SFTP server, the ISAM uses an
operator-configured username and password. The security settings like encryption,
hashing and signature protocols can be configured by the operator via CLI or
SNMPv3. The ISAM supports both an SFTP client and server. In server mode, the
ISAM supports two SFTP sessions simultaneously. Also, in SFTP server mode, the
user authentication coincides with the SSH authentication, that is, the same
username/password or username/key-pair combinations apply. This means that
once the operator has been configured for CLI or TL1 with a username/password or
for SSH with a username/key pair, the same username can be used for setting up an
SFTP session with the ISAM.
5.2.4.2 External xFTP servers

External (software download, backup/restore…) xFTP servers can be configured in
the ISAM. One and the same external server machine can be used as software
download and backup/restore server, but they can be different machines as well. The
servers might also be used in a redundant mode: if the first server cannot be
reached, automatically the redundant one is tried. Multiple configurations are
possible, depending on the situation and/or requirement of the customer.
Only one account (name, password) can be defined in the ISAM per external server:
• Even in case of multiple applications (software download, backup…) on one and
the same server, only one account can be specified
• The account data is stored in encrypted format
• The account data is not readable from any management interface, not even from
the SNMP manager.
In case of SFTP, only one account can be specified. This account will be used
towards all external xFTP servers.
In case of FTP, up to 8 external servers/accounts can be specified, each with their
own account.
In case of TFTP, no account is required, so also none (0) can be specified.

NT
5.2.4.3 xFTP Protocol selection

The xFTP protocol to be used for example for software download/backup/restore/…
operations can be configured in the ISAM as a system-wide selection. That is, only
one xFTP protocol can be selected at a time per ISAM. The selected xFTP protocol
will be used for all applications requiring xFTP, independent of the used xFTP server
or application.
Note — The automatic PM file upload will work, only when
SFTP is configured as file transfer protocol.
5.2.5 xNTP
The ISAM system time can be set in three ways:
• the system time can be retrieved using the SNTP protocol to retrieve the time from
a (S)NTP time server
• the system time can be retrieved using the NTP protocol to retrieve the time from
(S)NTP time servers
• the system time can be set manually by the operator
This is a system wide setting in the ISAM. While SNTP and NTP is mutually exclusive
(that is, either SNTP or NTP can be enabled, but not both at the same time), the
ISAM system time can always be set manually by the operator, even if SNTP or NTP
is enabled.
5.2.5.1 SNTP Client

Typically, the ISAM system time is retrieved using the Simple Network Time Protocol
(SNTP); the ISAM can cope with both SNTP and NTP servers, in both cases using
the SNTP protocol.
On a per ISAM level, also the polling rate can be specified, applicable for all specified
(S)NTP servers.
Apart from defining the (S)NTP servers, first of all SNTP must be set as the
system-wide option for the ISAM. The (S)NTP server will always provide the UTC
(Coordinated Universal Time): no time zone or daylight savings settings are passed
over the SNTP protocol.
The (S)NTP server can be configured in the ISAM by specifying:
• The IP address of the server
• The port to be used

NT
Up to three (S)NTP servers can be configured in the ISAM, specifying:

• The port to be used
• The relative priority among the three possible servers
The relative priority defines which server will be polled first to get the time. If none of
the time servers can be reached, even after three retries, an alarm is raised.
5.2.5.2 NTP Client

Alternatively the ISAM can also retrieve its system time using the NTP protocol
(NTPv3), with up to 5 NTP servers used. Also in this case the NTP servers can be
pre-configured, but no priority is to be specified as this is irrelevant in case of the NTP
protocol. Note the xNTP servers need to be configured separately for the SNTP and
the NTP protocol: the servers defined for the SNTP protocol will not be used by the
NTP protocol and vice versa.
The following can be specified per NTP server:
• The port to be used (default = 123)
On a per-ISAM level, also the polling rate can be specified, applicable for all specified
NTP servers. If none of the servers can be reached, even after three retries, an alarm
will be raised.
Also when selecting NTP to set the system time, the server will always provide the
UTC time.
5.2.5.3 Manual setting

The ISAM system time can also be set manually by the operator. However, if SNTP
or NTP is enabled (see above), the set system time will be overwritten at the next
xNTP poll by the UTC time.
Note — As all the management time stamping (such as alarms,
syslog messages, PM, …) is based on the ISAM system time,
Nokia highly recommends to use either SNTP or NTP instead
and discourages any manual time setting in the operational
network.

NT
5.2.5.4 Time zone offset

An operator can also specify a time zone offset in the ISAM, allowing the operator to
mimic “local” time. This time zone offset:
• Is taken into account once the ISAM system time is set for the first time, be it via
SNTP (at the first synchronization with the (S)NTP server), via NTP (when time is
set using the NTP protocol) or manually (time set by the operator)
• As long as the ISAM system time has not been set, the system time will remain fixed
to January 1, 1970
• The ISAM system time (taking into account the time zone offset) is also stored in
prozone and restored after a reset of the ISAM. If the time cannot be restored from
prozone, the ISAM system time is set fixed to January 1, 1970 again, until the time is
set, either manually or by using xNTP.
• Is independent of the fact whether xNTP is enabled or not, that is, it will also be
applied when SNTP and/or NTP are disabled
• Has an allowed range of -780 to +780 minutes, with a default value of 0 minutes
• Is stored persistently
The time zone offset is applied consistently for all applications in the ISAM, including
SNMP, Syslog and so on, that is the time applied by an application is always ISAM
system time + time zone offset (note the default value being 0, even in case the
operator did not specify any time zone offset value, the above statement still is
correct).
5.2.5.5 SNTP Server towards ONT/MDU

The ISAM can also act as SNTP server towards the ONTs/MDUs. This means the
ONT/MDU can retrieve its system time directly from the ISAM by using SNTP. The
ISAM acts on behalf of the SNTP server in the network.
The SNTP server addresses are learned by the ONT/MDU using DHCP option 42.
5.2.5.6 Additional notes

• Daylight savings can not be specified nor are applied automatically in the ISAM.
• ISAM management applications (5520 AMS, 5529 SDC, 5530 NA, …) typically
expect UTC timestamps from the managed nodes: the ISAM management
application machine will typically apply a time zone and daylight savings
correction on the timestamps received from the nodes, before displaying on the
GUI, just like a with a PC. This also implies that if a time zone offset is set in the
ISAM, different from 0, the timestamps on the GUI will be wrong as time
corrections will be applied twice (once in the ISAM with the time zone offset and

NT
again on the management application itself). The ISAM management application

typically will not take into account any time (zone) correction done in the node
itself. Please check on the management applications for this aspect.
• The granularity of the ISAM time information, as provided by the ISAM
applications exposing ISAM time information to external applications (Syslog,
5520 AMS, OSS, …), is seconds and has following format
“yyyymmdd-hh:mm:ss”.
5.2.6 SSH
Secure Shell (SSH) is a protocol that provides authentication, encryption, and data
integrity to secure network communications. On top of this protocol, SSH
implementations offer secure replacements for rsh, rlogin, rcp, ftp, and telnet, all of
which transmit data over the network as clear text. In addition, it offers secure
data-tunneling services for TCP/IP-based applications.
SSH has a client-server architecture. The ISAM can act both as an SSH server or an
SSH client; see Figure 20.
Figure 20 SSH client-server architecture in the NE
SSH Appl. protocol

SSH CLI SSH CLI
client appl server appl
SSH transport
ssh client ssh server
authentication,
connnection
- DB of client
EMS NE - Public keys or
Server authentication
passwords
Secure link for CLI/TL1 SSH
SSH
Server
Client
- NE public key
Client authentication - NE private key
SFTP
Secure link for SFTP InterPeak - Supported algorithms
Server
SFTP
Client
SFTP
- SFTP client
File Client
- Username/password
SFTP
Secure link for Server
Secure link for the transfer
SW&DB from FileServer to NE (SW&DB)
SFTP Appl. protocol

SFTP server SFTP client
application application
SSH transport, authentic,
SSH server SSH client
connection protocol

NT
5.2.7 System logging

System logging (SYSLOG) allows you to trace and audit system behavior related to
operator and /or system activities. System log entries are issued by actions such as
CLI and TL1 user logins, but also by alarms and video CDR records, for example:
With system logging, you can do the following:
• create up to 64 custom system logs that can be saved locally or to a remote server
location
• create filters to determine which messages are sent to the system log files
• monitor system logs
You can configure system logs using CLI, TL1 or an EMS. Locally stored syslog files
can be transferred to an external server using xFTP.
5.2.7.1 File sets

The system logging works with file sets consisting of two log files. The operator can:
• Trigger the wrap-around from file1 to file2 in order to upload a stable file1.
Note — The ISAM will also automatically copy file1 to file2
when file1 is full. Both actions (automatic by system / manual
by operator) are performed independently of each other.
• Assign a name to this file set

• Specify the maximum size of the file set
5.2.7.2 Configuring system logs

You can configure the following for each system log file:
• system log filename (local only), entered using up to eight alphanumeric
characters followed by a dot separator and a three-alphanumeric character
extension. Example: Alrmhigh.txt
• destination server type:
• all active TL1 and CLI terminals (all-users)
• all active CLI terminals (all-CLI)
• all active TL1 terminals (all-TL1)
• single active TL1 terminal (TL1-user)
• local file (file:name:size)
• remote host (udp:port:serv-ip-addr)

NT
• destination server address, entered as an alphanumeric host name or in standard

dot format (maximum value 255.255.255.255); where 0.0.0.0 is entered for local
files
• enable or disable logging
• delete a system log file
When a system log file is full, the ISAM will automatically copy the file (file1) to a
backup file (file2) and start overwriting the oldest entries in file1 again.
You can also view system-wide information for system logs. This system-wide
information includes the maximum message size allowed and statistics on the
amount of combined disk space used by the local system logs. The combined
maximum size of all locally saved system log files is 2 Mb.
5.2.7.3 System log filters

You can configure filters to define which messages get logged to which system log
files, based on the message type; by default, all message types are logged to the
system log files.
Table 10 lists the possible message type and log severity parameters. You can select
which messages are sent to specific system log files using filters and can group
multiple message types.

NT
Table 10 Message type and log severity parameters
Item Description Parameter
Message type Authentication actions AUTH
CLI commands CLI_CONFIG
TL1 commands TL1_CONFIG
CLI messages CLI_MSG
TL1 messages TL1_MSG
All message types ALL
Log severity Emergency EM

Alert AL
Critical CR
Error ER
Warning WN
Notice NO
Information IN
Debug DBG
Note — Besides these message types, the alarms and the

errors encountered in the system are also logged in the system
log files.
5.2.7.4 Operator access to the system logs

The operator access to the log file is determined by the allowed priority (access
control). Different users have different access rights to the system log file, that is,
some users only have read priority, while other users with higher priority have read
and write (=delete) priority.
The local log files can be retrieved via xFTP to upload to an external server. In this
case the operator can access the log file only after successful xFTP authentication.
System log files are to be deleted explicitly by operator command.
By default, only read permission is provided to the syslog files.

NT
5.2.7.5 Viewing and monitoring system logs

The contents of a system log can be viewed either dynamically or statically.
You can monitor remote system logs dynamically on your CLI or TL1 terminal.
Setting the destination server type for the system log file to all active CLI or all active
TL1 terminals sends all messages to the active terminals that have a management
session with the ISAM. When you are finished monitoring the system log, deactivate
system logging for that server.
You can view the static contents of a system log file that is saved to a remote server
location using any text-based editor.
5.3 Management interfaces security

In order to make the ISAM securely managed, the operator must make sure that:
• A dedicated management access model is applied.
• The secure variants of the used management channels are used.
• A secure operator authentication method is used
• Unused management interfaces are closed.
• The debug port for troubleshooting is closed.
5.3.1 Management interfaces

The following management interfaces can be secured (refer to Figure 19):
• Simple Network Management Protocol (SNMP)
Can be secured by way of SNMPv3:
• Command Line Interface (CLI):
Can be secured by way of Secure Shell (SSH)
• Transaction Language 1 (TL1):
Can be secured by way of SSH
• Trivial File Transfer Protocol (TFTP) and File Transfer Protocol (FTP):
Can be secured by way of Secured File Transfer Protocol (SFTP)
Apart from xFTP, which is a system-wide, exclusive setting, the system allows both
the secure and the insecure variant of a management interface to coexist, so that the
operator is still able to contact the system in case the security setup would fail.
Simple Network Time Protocol (SNTP) does not have a secure variant. It is
configured to listen to a single SNTP server (for example the Element Management
System). This configuration is done via one of the management interfaces listed
above. Since the operator can secure these interfaces, the SNTP configuration can
be secured.

NT
5.3.2 Encryption and authentication

SSH, SFTP and SNMPv3 support encryption and authentication. Table 11 shows the
supported combinations.
Table 11 Supported SSH and SNMP Authentication and Encryption
Schemes
Security Encryption Authentication Key Exchange Authentication Combinations

protocol algorithm algorithm algorithm mechanism
SSH, SFTP 3DES, blowfish, Hmac-sha-1, Diffie-Hellman-gr Username/password(1) • Nothing

AES, DES-56 Hmac-sha-1-96 oup1-Sha1, Username/public and • Encryption only
3DES-CBC Hmac-sha-2-256 Diffie-Hellman-gr private key • Authorization only
Hmac-sha-2-512 oup14-Sha1 • Encryption and
DES-CBC
authorization
Blowfish-CBC
AES-CBC
(128/192/256)
AES-CTR
(128/192/256)
ARC four
CAST128-CBC
SNMPv3 DES-56 Hmac-sha-1, - Username/password(1) • Authorization only

AES-128-CFB Hmac-md5 Note: Different password • Encryption and
per SNMP engine. authorization
Note
(1) The username/password combinations of SSH and SNMPv3 cannot be reused.
5.3.3 Security configuration

The configuration of the initial security parameters and user names in the system is
only possible via CLI. Only the operator with security administrator rights has the
authorization to change the security configuration and to add or remove users.
Once the secure channel has been setup, the SNMPv3 parameters can also be
configured by way of the secured SNMPv3. For TL1 and CLI, the security
configuration remains a privilege of the security administrator (concept known in both
TL1 and CLI).
5.3.4 Default username and password

Two command session interfaces (CLI and TL1) are available to the operator to
configure the system. To access these interfaces for the first time, the operator has
to use the default username and password.

NT
For security purposes, the default username and password must be changed as
soon as possible. The system prompts the operator to do this when he or she logs in
for the first time.
5.3.5 Trace and Debug interface

The ISAM also supports a Trace&Debug (T&D) interface for troubleshooting
purposes. This interface gives access to low level ISAM functionality and is intended
to be used by trained Nokia personnel only. Nokia highly recommends to disable this
interface at any time during normal network operations.
Moreover, as an alternative management interface, the ISAM T&D interface is also
vulnerable to security issues. This can be avoided as much as possible by disabling
this interface whenever it is not used.
The T&D interface can be enabled or disabled using the configure system security
ssh access command: please refer to the CLI Command Guide for FD 100/320Gbps
NT and FX NT for all details.
5.4 Management access models

.
5.4.1 Introduction
In most deployment models, the ISAM will use a specific management VLAN for
management. Management access security in this case is guaranteed as follows:
• Any management access to the ISAM via a VLAN which is not the management
VLAN is not possible. Such traffic will be dropped.
• There is a clear separation between management traffic and user traffic.
• Management access is only possible via network ports. The aggregation and core
network should be designed in such a way that non-authorized users cannot get
access to the management VLAN on the network port.
The management access policy will always be a combination of access checks on

different layers:
• Layer 1: specific serial connector (for example, CRAFT cable)
• Layer 2:
• a dedicated management v-VPLS
• a dedicated management pseudo-wire tunnel over an MPLS network.
• Layer 3: specific IP ACLs
• Checks for all traffic destined for the CPU (CPU filters) for IPv4 and IPv6 traffic

NT
• Layer 4-7: authentication on protocol level

• Using SSH: user password or private public key
• Using Telnet: user password
• Using UDP: user password
The ISAM can support different management models to secure the access to the
management plane depending on the system configuration:
• Management model via a Layer 3 SAP
• Management model via an IP interface directly connected to a network port
5.4.2 Management via Layer 3 SAP (IES SAP)

Two different models are possible:
1 All the management plane packets are passing via a dedicated external
Management v-VPLS (VLAN)
2 There is no explicit external management v-VPLS (VLAN).
5.4.2.1 All the management plane packets are passing via

a dedicated external Management v-VPLS (VLAN)
A dedicated external management v-VPLS (VLAN) isolates the management plane
traffic from the user plane traffic in the access network.
All the user plane traffic is passing via another v-VPLS and not via the external
management v-VPLS.

NT
Figure 21 Management via a Layer 3 SAP - external management v-VPLS

(VLAN)
Management traffic
User traffic
Regular v-VPLS IHub IES IHub

Ports SAPs v-VPLS SAP IES
Phy Ext. mgnt.

v-VPLS
VLAN
4093
IES v-VPLS
iBridge
VLAN 23
VLAN 23
Phy v-VPLS
(No VLAN
LAG VLAN 11
CPU filter translation
Phy shown
on user side)
OBC
LT
NT
ISAM
In this case, the security is based on:

• No layer 2 checks
• Layer 3 checks: By using CPU filters, the operator will only allow management
traffic from the VPLS service of the management VLAN (external management
v-VPLS).
Optional: in combination with checks on the source IP address of the
management stations
• Layer 4-7: specific authentication mechanisms on application level
5.4.2.2 There is no explicit external management v-VPLS

(VLAN)
On the access network the user and management traffic is not separated.

NT
Figure 22 Management via a Layer 3 SAP - No external management

v-VPLS
User and Management traffic
Regular v-VPLS IHub IHub IES

Ports SAPs v-VPLS IES SAP
Phy
v-VPLS
VLAN 11
IES v-VPLS
iBridge
VLAN 23
VLAN 23
Phy (No VLAN
LAG CPU filter translation
Phy shown
on user side)
OBC
LT
NT
ISAM

• Layer 3 checks: by using CPU filters, the operator will only allow management
traffic from the source IP address of the management stations.
5.4.3 Management via an IP interface directly connected

to a network port
On a network port it is possible to configure an IP interface with a corresponding
encaps-value (VLAN). All IP packets which are destined for the interface IP address
are lifted to the OBC. However, all IP packets which have access to the Base Router
can also access the OBC by using the IP address of the interface as destination IP
address.
If no special protection mechanisms are activated, all packets which have access to
the base router can access the OBC. If a v-VPLS is connected to the base router via
a L3 SAP, all user traffic which is passing via the v-VPLS, can access the OBC. This
is possible by using the IP address of the IP interface (connected to the network port)
or via the IP address of the L3 SAP. All packets which have access to the OBC can
access the management protocols.

NT
IPv6 control plane traffic that ingresses at the IES/VPRN/Base router interface on
Network ports can be filtered so that the CPU load can be managed with added
security. IPv6 ACLs can be configured to include IPv6 CPU filters.
Figure 23 Management via an IP interface directly connected to a network
port
Management traffic
User traffic
L3
Network IP SAP
Port interface
Phy v-VPLS
IES VLAN 23
iBridge
VLAN 23
(No VLAN
translation
Phy v-VPLS CPU filter shown
VLAN 11
on
user side)
Access OBC
LT
Port NT
ISAM

• Layer 3 checks: by using CPU filters, the operator will only allow management
traffic from the source IP address of the management stations (and also the
allowed protocols).
The source IP address of a loopback interface of the IES service can be modified.
This allows the operator to control the source IP address that is used for unsolicited
packets generated by the following applications: SNMP trap, TFTP, FTP, RADIUS,
ICMP ping, ICMP traceroute and NTP.

NT
5.4.4 IPv6 Management

Next to an IPv4 address, also an IPv6 address can be configured to manage the
ISAM, and this for the following protocols: SNMPv2/v3, FTP, TFTP, SFTP, SSH,
Telnet, CLI, TL1, SNTP, NTP, Syslog. It is possible to use both an IPv4 and an IPv6
address to manage the same ISAM, also for the same protocol: for example, some
CLI sessions may be with IPv4, while simultaneously others with IPv6, or, FTP may
use IPv4 while SNMP may use IPv6.
Note 1 — IPv6 management is not supported on FANT-F
Note 2 — The IPv6 address needs to be statically configured on

the node. Dynamic IPv6 assignment is not supported (and
hence neither auto-installation scenarios or zero touch
provisioning).
Note 3 — Only the above listed protocols are supported, and
not others such as RADIUS, TACACS, LLDP (non-exhaustive
list).
Note 4 — Only global IPv6 addresses are supported, and not
IPv6 LinkLocal addresses.
Note 5 — It is not supported to use multiple IPv6 addresses
simultaneously to reach ISAM management server
applications.
5.5 Counters and statistics

Counters and statistics serve various purposes in the ISAM, like troubleshooting,
network dimensioning and SLA adherence and are defined on both the network and
subscriber side of the ISAM.
They can be retrieved from the ISAM using CLI, TL1, or an Element Management
System (EMS). See the following documents for detailed information and the detailed
command definitions for retrieving the ISAM counters and/or statistics using CLI or
TL1:
• Operations and Maintenance Using CLI for FD 100/320Gbps NT and FX NT
• TL1 Commands and Messages for FD 100/320Gbps NT and FX NT

NT
5.6 Alarm management

Alarm management enables you to manage alarm reporting for the ISAM. You can
manage the following alarm attributes and alarm reporting functions for all basic
system alarms, interface related alarms, derived alarms, and Threshold Crossing
Alarms (TCA) indications:
• alarm category and definition (fixed per release)
• alarm severity (ignore, intermediate, warning, minor, major, and critical)
• alarm is service affecting (yes, no)
• alarm must be reported (yes, no)
• alarm must be logged (yes, no)
• alarm lists and logs severity thresholds, that is, the minimum severity of an alarm
in order to be logged or reported in the alarm snapshot and the alarm-changed
trap)
• alarm filters: affect the way in which the ISAM reports its own alarms, as well as
the alarms from connected remote expansion units.
See the CLI Commands for FD 100/320Gbps NT and FX NT and the TL1 Commands
and Messages for FD 100/320Gbps NT and FX NT documents for alarm
management command definitions.
5.6.1 Alarm categories and definition

There are four alarm categories:
• non-interface related alarms: these alarms include basic system alarms such as
equipment failure alarms.
• interface related alarms: these alarms involve ATM and xDSL interfaces.
• derived alarms: these alarms are raised in the system when programmed
temporal or spatial alarm filters are used (that is, alarms generated when the
conditions set in an alarm filter are met). See section “Programmable alarm filters”
for more information about temporal and spacial alarm filters and the derived
alarms.
• TCA alarms: these alarms are generated when a Performance Monitoring (PM)
counter or actual value of a parameter crosses a defined threshold value
(Threshold Crossing Alert).
Alarms use the same definition method that consists of two main parts:
• the alarm type, which provides a general definition of the type of alarm; for
example, an xDSL alarm.
• the alarm number, which identifies a specific alarm within that type; for example,
a near-end LOS alarm

NT
You can view alarm types and definitions as they are recorded in alarm lists and logs
using the TL1, CLI or an EMS like the 5520 AMS. See the Operation and
Maintenance Using CLI for FD 100/320Gbps NT and FX NT and Operation and
Maintenance Using TL1 for FD 100/320Gbps NT and FX NT document for a
complete listing of all alarms, along with their definitions. Alarm definitions are not
user configurable.
5.6.2 Alarm severity

For each individual alarm the operator can configure:
• whether spontaneous reporting should take place or not and
• the severity level of the alarm.
There are six alarm severity levels listed in ascending order of severity:
• ignore
• indeterminate
• warning
• minor
• major
• critical
In addition to the individual alarm reporting control above, the operator has the
capability to select which alarm severity he wants to see spontaneously reported.
This is useful to avoid being overwhelmed by a flood of non-important alarms. There
are five levels available for the minimum severity which alarms must have to be
reported, listed in ascending order of severity:
• indeterminate
• warning
• minor
• major
• critical
For additional flexibility this minimum reporting severity level is separately

configurable for:
• non-interface related alarms, (cfr. CLI: “configure alarm...”);
• interface related alarms, per interface type like xDSL, Ethernet, Gpn,... (cfr. CLI:
“configure interface...”)
When the severity level of an alarm equals or exceeds the (system-wide) minimum
severity level, that particular alarm is forwarded to the alarm reporting and logging
filters where it is reported and logged as defined for that particular alarm.

NT
For TCA alarms, when the TCA feature is enabled for an xDSL subscriber line, alarm
indications are always sent to the alarm reporting and logging filters. Whenever a
minor, major, or critical alarm is received, the corresponding alarm LED, on the
faceplate of the alarm control unit installed in the shelf, is activated as well.
You can configure the (system-wide) minimum alarm severity level and the individual
severity level of an alarm using CLI, TL1 or an Element Management System. See
the 7302 ISAM | 7330 ISAM FTTN CLI Commands and 7302 ISAM | 7330 ISAM
FTTN Operations and Maintenance Using TL1 documents for alarm management
command definitions.
Changing the severity level for an alarm only affects new alarm events and does not
affect alarm indications that have already passed through the alarm reporting and
logging filters.
Note that when the severity level of an alarm is set to ignore (lowest level), these
alarms are completely ignored by the system and no processing will happen
whatsoever - the ISAM will behave as if this alarm just does not exist.
5.6.3 Alarm lists and logs

You can set the alarm logging and reporting mode for individual alarms. When alarm
logging and reporting are enabled, alarm indications are always sent to the
appropriate alarm list and alarm log when the minimum alarm severity level for the
alarm is reached. Alarm logging and reporting are enabled by default, unless
otherwise specified.
There are three types of alarm list:
• current alarm list
• snapshot alarm list
• alarm severity delta logging list
The current alarm list and the snapshot alarm list display only the currently active
alarms. When the alarm reporting mode is enabled, alarm indications are sent to the
current alarm list.
The alarm severity delta logging list is a log (one for each alarm severity) of alarm
indications that can be accessed at any time and contains a historic record of alarm
events (start and end of active alarm). Only alarms that have their alarm logging
mode enabled appear on these alarm severity delta lists.
Note — There is no alarm severity delta log for the ignore
severity.

NT
5.6.4 Current and snapshot alarm lists

The current alarm list changes dynamically as alarms are detected and pass through
the alarm filters. Because the list changes dynamically, it is impossible to get a
consistent view of the active alarm status. Therefore, if a stable view of the alarms is
preferred, the snapshot alarm list captures a momentary view of the active alarm
status at the time it is requested by the user. You can configure the minimum severity
level of the active alarms in the snapshot list and you have access to the snapshot
alarm list for a maximum time period of up to 120 seconds. The snapshot alarm list
provides the active alarms ordered first by severity (high to low), and then on
time-of-occurrence.
5.6.5 Alarm severity delta logging list

A separate alarm severity delta logging list exists for five alarm severity levels, there
is no alarm severity delta log for the ignore severity. Each change in the alarm
condition, such as a change of alarm state from alarm-on to alarm-off, is logged.
Alarm state changes are logged in order of occurrence, with a limited number of
entries per alarm severity delta logging list.
You can set the action to be taken when the alarm severity delta logging list reaches
the configured maximum size:
• continuous wrap entries, where newer entries overwrite the oldest ones. A flag is
set to indicate that there was a wrap-around
• halt alarm logging when the logging list is full. In this case, alarm logging resumes
only after the alarm logging list is manually reset by the operator.
Resetting an alarm severity delta logging list empties the contents of that list.
5.6.6 Alarm clearing

Most alarms are cleared autonomously. Both the alarm-on and alarm-off situation are
detected and reported. The alarm-off will result in the automatic clearing of the
alarm-on from the current alarm list.
However, some alarms cannot be cleared automatically and require operator
intervention to clear the alarm: OSWP-Download-failure is an example of such an
alarm. Also a group of IHUB alarms will not be cleared automatically.
In order to clear these alarms, explicit operator intervention is needed using CLI
and/or an Element Management System. The list of alarms that need clearing
through operator intervention is specified in the alarm description document as
specified before.

NT
5.6.7 Alarm filters

There are three types of filters:
• alarm logging filter: determines if the alarm indication should be processed and
recorded in one of the five alarm severity delta logging lists.
• alarm reporting filter: determines if the alarm indication should be processed for a
current view or snapshot list.
• programmable alarm filters: enable you to customize how alarm reporting occurs
for specific diagnostic and monitoring scenarios.
Alarm filtering applies to both non-interface related alarms, such as equipment failure
alarms, and to interface related alarms, such as ATM and xDSL interfaces. It is
possible to enable and disable alarm filtering for individual alarms.
5.6.8 Programmable alarm filters

There are two types of programmable alarm filters:
• temporal alarm filters
• spatial alarm filters.
You can define a maximum of 31 temporal alarm filters and 31 spatial alarm filters.
See the TL1 Commands and Messages for FD 100/320Gbps NT and FX NT and CLI
Command Guide for FD 100/320Gbps NT and FX NT documents for programmable
alarm filter command definitions. The filters can also be configured using an EMS.
When you use programmable temporal or spatial alarm filters, the ISAM raises a
derived alarm whenever the conditions of the alarm filter are met. The resulting
derived alarm has the same identification parameters as the alarm filter that
generated the derived alarm.
5.6.8.1 Temporal and spatial alarm filters

Using temporal alarm filters, you can limit the number of alarm state changes that are
reported for a particular alarm. For alarms that are frequently raised, you can create
a temporal alarm filter that will report only one alarm state change for a set number
of state changes that occur over a specified length of time. You can configure the
threshold for the number of state changes, and the time period of the filtering window.
Since temporal alarm filters are severity based, only alarm indications that equal or
exceed the alarm severity level are counted. In other words, it makes no sense to
configure a temporal alarm filter on an alarm that has a severity below the global
alarm severity level.

NT
A temporal alarm is raised in the ISAM when:

• the number of alarm events reaches the set threshold during the filtering window
time period, OR
• the alarm event remains active for at least the filtering window time (even if the set
threshold is not met)
Figure 24 shows how a temporal alarm filter raises a derived alarm after the
configured threshold is reached (in this case set to 3). In the first case only 2 alarm
events occur during the filtering window time T, so no derived alarm is raised. In the
other cases, 3 alarm events occur in the window T, and a derived alarm is raised.
Figure 24 Temporal alarm by quantity
Only 2 events in time T:
no temporal alarm is
raised
Alarm
event
T T T
Threshold = 3
Temporal
alarm
Temporal alarm is cleared when

the alarm event is cleared
Figure 25 shows how a temporal alarm filter raises a derived alarm when the alarm
event is active for at least the filtering window time T. In the first case the alarm event
is cleared before T, so no derived alarm is generated; in the second case an alarm
event remains active for more then T, in which case the derived alarm is raised.

NT
Figure 25 Temporal alarm by time

Event is cleared again
before time T expires:
no temporal alarm is raised
Alarm
event
T T
Threshold = 3
Temporal
alarm
Temporal alarm is cleared when

the alarm event is cleared
So the temporal alarm is always raised when the condition is met, and cleared
whenever the alarm event, triggering the alarm filter condition, is cleared,
independent of the filtering window time. See also Figure 24 and Figure 25.
A temporal alarm filter becomes active whenever the alarm event is raised on an
ISAM object (for example, on a port, ONT, …), i.e. at that moment timer T is started
(see figures above) and the number of occurrences is counted. Each such filter can
be activated (by the alarm event) on at most 50 different objects at a time. A filter
becomes inactive again for a certain object whenever the condition is cleared (and
so no derived alarm is generated, or the derived alarm is cleared).
Temporal alarm filters are useful for, for example, TCA alarms that can be raised
frequently. Using temporal alarm filters, you can filter out minor TCA alarm
indications and provide better visibility of major TCA alarm conditions.
Using spatial alarm filters, you can create a unique alarm condition such that when
a specified group of individual alarms are raised, a derived alarm is reported. This is
used to identify alarm conditions that are characterized by a certain set of alarm
conditions occurring simultaneously. Say, for example, that 100 objects in the system
can experience the same alarm condition. A spatial alarm can be configured on top
of the basic alarm. The spatial alarm is generated (that is, derived alarm-ON
condition) at the moment that a predefined number of these objects are in alarm (that
is, basic alarm-ON condition).
Identification of alarm filters and derived alarms consists of two main parts: a type
identifier and a number. Temporal and spatial alarm filters have a unique filter type
identifier. Derived alarms have a unique alarm type identifier. The number used in
the identification of derived alarms matches the number assigned to the alarm filter
that generates the derived alarm. Additionally, each derived alarm entry recorded in
alarm reporting and logging lists contains the identification of the affected
component. In the case of an interface related derived alarm, the identification of the
affected interface is provided.

NT
The state change of a derived alarm must pass through the alarm reporting and
logging filters before being added to the alarm reporting lists (current and snapshot
alarm lists) and the alarm severity delta logging lists respectively. A derived alarm
that is generated from a temporal filter is identified as an interface-related alarm if the
basic alarm, referenced by the filter, is also an interface-related alarm. The derived
alarms generated from spatial alarm filters are always identified as
non-interface-related alarms.
5.6.8.2 Configuring programmable alarm filters and

derived alarms
You can activate and deactivate alarm filters after they are created using TL1 and/or
an EMS like the 5520 AMS. When you create a temporal or spatial alarm filter, the
ISAM automatically copies the parameter settings of the basic alarm to which the
alarm filter applies, and uses those parameter settings as default settings for the
derived alarm. The settings include:
• alarm category
• severity level
• service affecting or non-service affecting
• reporting mode
• logging mode
You can change these settings for the derived alarm, but not if the alarm filter is
active. You must first deactivate the alarm filter.
After the filter is deactivated, you can configure the filtering threshold, filtering
window, and the alarm to which the filter applies. Once configured, you must
manually reactivate the alarm filter.
5.6.8.3 Alarm reporting

Alarm reporting of the basic and derived alarms occurs differently, depending on
whether or not alarm filters are configured for the basic alarm.
If no alarm filters are configured for the basic alarm, then alarm state changes of the
basic alarm are always reported to the appropriate alarm reporting and logging lists
when the alarm conditions are met.
If a temporal alarm filter is configured for a basic alarm, only state changes of the
derived alarm are recorded in the appropriate alarm reporting and logging lists during
the time period when the derived alarm is on. During the off period, state changes of
the basic alarm are recorded in the appropriate alarm reporting and logging lists.
With spatial alarm filters, both the derived alarm state changes and the basic alarm
state changes are recorded in the appropriate alarm reporting and logging lists.

NT
5.6.9 External alarms profiles

The ISAM equipment practices provide an external alarm interface to which up to 5
external alarms can be connected, be it in a CO or cabinet environment. Upon alarm
condition detection, the ISAM will raise an external alarm, also known as
'customizable alarm' and/or 'environmental alarm', and are configured and handled
in the ISAM like any other, internal ISAM alarm (severity, logging, filtering, …).
For these external alarms, also an external alarms profile can be defined, reflecting
a configuration of external alarms parameters that correspond to a certain
environment where the ISAM is located (outdoor cabinet, CO, basement cabinet, …).
Using these external alarms profiles, we avoid the need to specify these parameters
for each ISAM separately.
The external alarms profile can be assigned either to the NT, or to the remote LT (in
case of a REM).
Note this profile is only applicable for the external alarms.
5.6.10 ONT Type specific alarms

In case of GPON deployment, ONT alarms can be made ONT Type (SFU, SOHO
and MDU) specific by downloading an ONT Mapping file to the ISAM. The ONT
Mapping file is optionally downloaded to the ISAM together with the ONT software
files.
The ONT Mapping file is used by the ISAM to determine the ONT Type based on the
hardware part number which is retrieved through the OMCI channel.
Based on this ONT Type, the ISAM will generate ONT Type specific alarms when an
ONT alarm occurs.
This mechanism allows to configure the alarm attributes (like severity) for the
different ONT Types differently
5.7 Software and database management

Software and database management is all about controlling the OSWP (Operation
SoftWare Package) on the system. On the ISAM a set of software and database
management features are available, that are both powerful and efficient from an
operational point of view.
A Push-Button Migration tool (PBMT) is delivered together with the ISAM software.
This tool provides all the required functionality to migrate and/or upgrade an ISAM to
a new software load, automating all the different steps of the software upgrade and
migration process.
The PBMT is expected to run on the same machine as the 5520 AMS, as the PBMT
needs certain specific files for its proper execution.

NT
The PBMT is supported on both a Sparc and x86 platform (Solaris OS), delivered as
one installation package. At run tim, the correct libraries and executables will be
selected. Support is only provided for migrations to the target release (that is, the
release for which the PBMT is delivered).
5.7.1 OSWP and databases

The ISAM is capable of hosting an active (operational) and a non-active (stand-by)
Operational SoftWare Package (OSWP). Each package consists of a software
version and a set of system databases. Only one of the 2 OSWP packages can be
active in the ISAM, but the operator can switch between packages, making the one
operational, and the other stand-by.
Each package also consists of a set of system databases, more in particular the
IHUB database, the IACM database and the xVPS databases (one physical
database per xVPS pair). From an operational point of view, if not mentioned
otherwise explicitly, the actions (backup, restore, migrate…) will be executed on the
set as a whole, not on an individual database of the set.
What is not part of these packages however is the GPON respectively TWDM-PON
ONT software. All ONT software files are stored in a dedicated 800 MB partition on
the compact flash (CF) of the NT. All ONT data, managed via the ISAM, is part of the
IACM database: the ONT can have its own database as well, this however not being
managed by/via the ISAM. The OLT software and database is part of the OSWP as
described above. The link between the ONT type and/or a specific ONT instance and
its (specific) ONT software is (persistently) stored in the ISAM MIB - the partition on
the NT CF is only a storage for the ONT software files. Management of these
software files (downloading to the ISAM, deleting, …) is done via an external
manager, be it the 5520 AMS, the PBMT (Push-Button Migration Tool) or using CLI
and/or TL1.
5.7.2 Software upgrade and migration

Of course there are rules on compatibility between software and databases: a
package can only become active, when the software version and the system
databases in the OSWP are compatible with one another. In this context, we make
a distinction between:
• Software upgrade is the process to upgrade a network element to a higher
software release not involving a migration of the system databases - there is no
system database change
This procedure is typically to be used when upgrading to a release in the same
software stream, for example, from R3.6.01 to R3.6.03c
• Migration is the process to upgrade a network element to a higher software
release requiring a migration of the system databases
This procedure is normally to be used when upgrading to a release from a higher
software stream, for example, from R3.6.01 to R4.0.02

NT
A complete software upgrade/migration activity consists of a sequence of actions:

1 The operator demands the system to download a new OSWP. This demand is
the trigger for the system to initiate a file transfer session with the external file
server specified by the operator. So it is not the operator who puts the software
on the system disk.
2 In case of GPON and XGS-PON/TWDM-PON, new ONT software is placed on
the NT CF by the 5520 AMS, PBMT and/or using CLI or TL1, potentially together
with a clean-up of older software files.
3 The operator starts an off-line conversion of the database from the source
release to the destination release. It is the responsibility of the off-line migration
tool to upload the complete database, convert it to the destination release and to
download it to the node again. In case of new ONT software, the description of
the to-be-used software version on the ONT, is updated in the database as well,
as part of the off-line migration.
4 In case of GPON and XGS-PON/TWDM-PON, the ONT software is
pre-downloaded to the ONTs at operator demand. The software is downloaded
to the ONT via the OMCI channel, but is not activated yet on the ONT - also the
ONT can have an active and a standby software load in parallel
5 When the new OSWP is downloaded, and, in case of GPON and
XGS-PON/TWDM-PON, the new ONT software is pre-downloaded to the ONTs,
the operator activates this new OSWP. The system will restart and come up with
an upgraded software version. All persistent configuration data remains
available. Due to the new ONT software description in the ISAM database, the
ISAM will trigger the ONTs to restart with the new ONT software.
6 Once the upgrade is successful, the operator can remove the former OSWP from
the system in order to free space for the next upgrade.
Some remarks:
• The maximum size of the ONT Software image that can be actively managed
through 7360 ISAM FX or 7362 ISAM DF OLTs is 64 MB.
• The ONT software is pre-downloaded to the ONTs using the OMCI channel, prior
to the activation of the new OSWP.
• The ONT software activation is triggered by the ISAM, also using the OMCI
channel.
• ISAM and ONT software activation are not coupled: ISAM and ONT software can
be upgraded independently if required.
• The behavior with respect to service continuity at the ONT when the planned ONT
SW at the ISAM is different from the active ONT SW, is user defined on a per
system basis. (That is, service flow may be blocked or allowed in such cases via
a per-system management option)
Note that migrations and software upgrades do not have to be between consecutive
software releases/streams: the necessary functionality has been provided to be able
to 'skip' intermediate upgrade/migration steps. While no point for software upgrades,
this is less evident for migrations.

NT
Also, in case of a failure to upgrade, the ISAM will automatically switch back to the
OSWP and resume services. This also implies that the ONT will also re-start with the
old, previous software, as the ONT software activation is triggered by the ISAM,
following the configuration settings done before. If the ONT itself fails to start with the
new software load, the ONT will also re-start autonomously with the previous, old
software load. The ISAM software will NOT be restarted in that case. This implies
that the ONT will not be able to support the services and features of the correct, new
load, but, as the ONT becomes active again, a new load can be downloaded and the
restart of the ONT retried.
Note — Due to the introduction of a new version of the IPD
stack (SROS ed.08) in R4.3.01, a R4.3.01 (or higher) ISAM
database is NOT backwards compatible with a R4.3 ISAM
database!
The necessary functionality has been added to make sure the
R4.3 OSWP, with related (R4.3) database, can still be activated
again, even after a successful R4.3.01 upgrade. The changes
done with R4.3.01 will of course be lost as the R4.3 OSWP can
-not- work with a R4.3.01 (or higher) version of the database.
R4.3.01 (or higher) can work with any R4.3.x database; in case
R4.3.01 (or higher) starts with a R4.3 version of the ISAM
database, the R4.3 database will be upgraded first.
The 7360 ISAM FX supports different OSWP upgrade procedures. Their applicability
depends on the ISAM equipment, configuration and state (that is, single NT/dual NT,
NT redundancy status, LT board type, parameter used for OSWP activation).
Please refer to the "Software Upgrade and Migration Application Procedures"
document (SUMAP) and to the "Software Installation" document (SWI) for more
information.
5.7.3 Backup and restore

Next to a software upgrade and/or migration, database management also requires
the regular creation of backups in order to minimize the configuration loss in case of
a system crash. This can be done either manually or automatically. These ISAM
backups can afterwards be restored on the ISAM if needed.
For IHUB-based NT boards, only one type of backup can be taken, always containing
all the ISAM configuration data and all the ISAM OAM data for remote management
(such as the IP address, next-hop and so on).
Note that in case of automatic backup enabled, the TFTP protocol cannot be used,
as the TFTP protocols implies the file name to be known already up front at the server
side. Given the format of the generated backup file name, this is however not
possible. Alternatively SFTP or FTP can be used.

NT
The configuration data of the ISAM is autonomously saved to the ISAM database on
the NT CF at different criteria:
• IACM: the database changes are cached in the system and autonomously saved
to the CF
• Every 60 seconds, and/or
• Whenever the cache of 5K is full (corresponds to 22 database updates), and/or
• On request of an IACM application, for example to safeguard some critical data
(software steered), and/or
• As part of an ISAM database backup request
• xVPS: the database changes are autonomously saved to CF
• Every 10 minutes if the xVPS configuration has changed indeed and the last xVPS
configuration change is at least 1 minute ago, and/or
• IHUB: the database changes are autonomously saved to CF
• Every 10 minutes if the IHUB configuration change, and/or
The IHUB configuration data can be saved to NT CF (database) at operator request
as well, for example, at the end of a IHUB configuration script. This is however not
possible for the IACM data.
Note — Due to the introduction of a new version of the IPD
stack (SROS ed.08) in R4.3.01, a R4.3.01 (or higher) ISAM
database is NOT backwards compatible with a R4.3 ISAM
database!
This implies that R4.3 can only work with a R4.3 version of the
ISAM database and it is NOT possible to start R4.3 with a
R4.3.01 (or higher) version of the database.
R4.3.01 (or higher) can work with any R4.3.x version of the
ISAM database; in case a R4.3 version of the database is
detected, it will be upgraded to a higher version first.
Practically this implies that R4.3 backups can also work with
R4.3.01 or higher, but R4.3.01 (or higher) backups cannot work
with R4.3.
5.7.4 Active load

The release name of the current active ISAM software package (for example, R5.0)
can be consulted via EMS, TL1 and CLI.

NT
5.7.5 Voice service management

The behavior of POTS voice services on ONTs can be controlled by downloading a
service configuration in XML format onto the ONT. This XML file can be sent to the
ONT via the in-band communication channel, used to provide data service.
In some cases, operators may require that the XML is downloaded to the ONT via
the Management VLAN, in order to provide a higher level of security. This approach
includes the following steps:
1 The Element Manager generates the ONT service configuration in XML format
and makes it available on an FTP server reachable by the ISAM
2 The ISAM NT downloads the XML file from the FTP server
3 The XML file is sent to ONT using an internal OMCI channel
This approach is supported on Nokia Single Family Unit (SFU) and Multi-Dwelling
Unit (MDU) ONTs that do not use TR-069 for voice provisioning.
5.8 Equipment monitoring
5.8.1 NT & LT CPU load

The average NT CPU load can be monitored using CLI, TL1 and/or an Element
Management System.
For IHUB-based systems, only the IACM CPU load can be consulted this way: the
IHUB CPU load can be measured using an IHUB dedicated mechanism (see the
IHUB configuration guides for more specifics).
On the LT side the retrieval of the CPU usage feature is supported by all GPON and
TWDM-PON LTs.
The CPU load is expressed as a percentage, ranging from 0% (no load at all) to
100% (full load), and represents the average CPU load over the monitored period.
Monitoring period is the period between the start by the operator and the present
time, with a special case for the ISAM restart.
The Monitoring period is to be started and stopped explicitly at operator request. By
default (at ISAM start-up), the monitoring is not active. Once started at operator
request, the monitoring period of the CPU load continues until the operator explicitly
stops the monitoring.
After a restart of the ISAM the monitoring is also restarted as soon as possible if
previously activated by the operator.

NT
5.8.2 NT & LT memory usage

The actual NT memory usage can be polled using CLI, TL1 and/or an Element
Management System.
For IHUB-based systems, only the actual memory usage of the IACM is counted: the
memory usage of the IHUB can be measured using an IHUB dedicated mechanism
(see the IHUB configuration guides for more specifics). Moreover, in the IHUB not all
memory is allocated up front during the initialization phase, but is rather dynamically
allocated whenever there is a need: an out-of-memory alarm is generated when the
IHUB gets into memory problems.
On the LT side the retrieval of the memory utilization feature is supported by all
GPON and TWDM-PON LTs.
Both the absolute value (expressed in Mbytes) as well as the relative value (used
percentage of the total available memory) is returned: always the actual values as of
the moment of the request are returned.
5.8.3 Thermal sensor data

Thermal sensor data can be retrieved from each board equipped with thermal
sensors and running software (so, for example, not from a passive splitter board).
Per thermal sensor, the following data can be retrieved (all expressed in degrees
Celsius):
• actual temperature
• low threshold temperature for TCA (T0_low)
• high threshold temperature for TCA (T0_high)
• low threshold temperature for shutdown (T1_low)
• high threshold temperature for shutdown (T1_high)
Only read access is provided for these parameters and none of the threshold
temperature parameters can be changed by the operator. They are fine-tuned by
Nokia in function of the actual board type and board variant.
The thermal sensor data as specified above can be retrieved via CLI, TL1 and/or
using an Element Management System, and are always the actual values as
measured at the moment of the request.

NT
5.9 Zero Touch Provisioning
5.9.1 Introduction
Broadband access (such as G.fast) nodes are evolving towards smaller nodes,
installed closer to the end-user. The size of the nodes, number of subscribers per
node, is getting smaller, but the number of nodes in the access network is increasing.
Hence there is a need to simplify the installation of the small, remote micro-nodes.
Customers are looking at truck roll-out deployments where a micro-node is installed
and commissioned and brought into service without the installer needing to apply any
configuration command on-site by connecting a portable PC (for example via craft).
This process is called Zero Touch Provisioning (ZTP) as shown on Figure 26,
depicting the entire turn-up flow automation while the installer can focus on
mechanical mounting, cable connection, turn-up and progress monitoring.
Figure 26 Zero Touch Provisioning
ZTP feature on ISAM offers:

• Dynamic IP address assignment through DHCP
• Automatic download customer configuration via TFTP
• Triggering AMS connectivity and supervising via SNMP
Via AMS an Automated SW upgrade (optional) can be triggered.

NT
5.9.2 IP connectivity through DHCP

When the ISAM powers up and Zero Touch Provisioning is enabled, the ISAM
management application gets into DHCP operations to request a dynamic IP
address. The ISAM broadcasts the DHCP discovery messages over all uplink
management ports associated to the management VLAN. In a default configuration,
there will be only one uplink port. If the customer network topology deviates from the
default configuration, ISAM factory pre-configuration is required to align port settings,
bridge-port and VLAN configuration/tagging in order to make sure connectivity can
be established with the DHCP server. The ISAM pre-configuration to activate
discovery is done by CTO (Configure To Order).
In the DHCP Discovery message, the ISAM provides its system MAC address
(DHCP CHADDR Field) and the serial number (DHCP Option 61 Client Id)
Via DHCP relay (DHCP Option 82) on the hub node (daisy-chaining) or aggregation
node, a physical location is coupled to the DHCP request. The IP address
assignment and configuration file can be linked to that location. DHCP option relay
tagging functionally is needed on the NNI interfaces of the hub node and the DHCP
server replies with DHCP lease Offer message to the ISAM with "temporary" IP
information, together with subnet mask, next hop gateway IP address. On top, the
DHCP server also provides the name of the turn-up config file (DHCP Option 67) and
the IP address of the TFTP server where the turn-up config file can be downloaded
(DHCP Option 66) specific for this location.
5.9.3 Downloading and executing turn-up config file

The ISAM downloads the turn-up config file from the TFTP server. The turn-up config
file must at least contain OAM (VLAN/IP) connectivity information for this node
together with AMS connectivity information (for example SNMP community string,
AMS IP address). After downloading, the ISAM loads the configuration changes
according to the file received.
Operators have indicated that DHCP servers may not be able to reserve the same
IP address persistently for the ISAM each time it asks. Therefore, it is the intention
that the turn-up config file contains the static IP address assignment for the OAM
interface.
5.9.4 AMS Supervision and Connectivity test

When the auto-configuration has completed, the ISAM will register via SNMP with
the AMS. The AMS will take control and start to supervise the ISAM node. The AMS
will register itself as trap manager in the ISAM. The registration of the AMS in the trap
manager table is an indication of the ISAM that the zero touch provisioning has been
completed successfully.
After a connectivity check, alarm registration and making the node (NE) fully SNMP
reachable, the AMS is actively supervising the node.

NT

System Description for FD 100/320Gbps NT and FX Line testing features
NT
6 Line testing features

6.1 Overview
6.2 Single-Ended Line Testing
6.3 Dual-ended line testing
6.4 Metallic-Ended Line Testing
6.5 ATM F5
6.6 Link Related Ethernet OAM
6.7 Narrowband Line Testing
6.8 SFP diagnostics
6.9 Embedded OTDR
6.1 Overview
This chapter describes the various line testing features within the ISAM and ISAM
Voice.
All line testing capabilities provide a means to execute pro-active and/or re-active
measurements to diagnose (potential) issues with the deployed equipment. As such
they can:
• bring OPEX savings such as the ability to save on buying external test equipment,
avoiding truck rolls
• increase customer satisfaction due to decreased service degradations or
interrupts.
The line testing capabilities depend upon the type of interface. For an overview of the
different types of interfaces (both for ISAM and ISAM Voice), see chapter “System
interface overview”.
ISAM supports line testing for:
• Ethernet network and subtending interfaces
• DSL interfaces (ATM or PTM mode) at the subscriber side
• Active Ethernet interfaces
• POTS and ISDN lines at the subscriber side
• xPON interfaces

Line testing features System Description for FD 100/320Gbps NT and FX
NT
But before considering the line test capabilities of these lines, we have to consider
the nature of DSL versus POTS and ISDN.
DSL is a transmission technology that works in overlay with POTS or ISDN lines:
• “narrowband” is used for the POTS or ISDN signals
• “broadband” is used for the DSL signal.
Both narrowband and broadband signals can be transported simultaneously on one
physical line and a splitter technology is used to multiplex or split these signals. The
part of the ISAM processing broadband is named the DSL line. The part of the ISAM
Voice processing narrowband is named the POTS line or the ISDN line. Therefore,
although a DSL line and a POTS or ISDN line are distinct lines from the perspective
of the ISAM or the ISAM Voice, they can correspond to one physical line.
Therefore, some tests will test the DSL line (broadband), other tests will test the
POTS or ISDN line (narrowband), but some tests will affect both.
The splitter technology can be integrated or can be outside of the ISAM or the ISAM
Voice (refer to the 7302 ISAM Product Information or the 7330 ISAM FTTN Product
Information). If integrated, this technology is supported by dedicated boards
(appliques) that are managed from the ISAM, or is integrated within the DSL board.
The splitter boards work in conjunction with the DSL LT boards. The physical lines,
carrying both broadband and narrowband, are identified with the same identifier as
the DSL line.
The overview of the line testing features:
• tests for a DSL line:
• Single-Ended Line Test (SELT)
• Dual-Ended Line Test (DELT)
• Metallic-Ended Line Testing (MELT)
• the DSL line can be of ATM or of PTM mode:
• For DSL lines of ATM mode: ATM F5
• For DSL lines of PTM mode: Link related Ethernet OAM
• tests for a POTS or ISDN line:
• Narrowband Line testing
• tests for an Ethernet subscriber line:
• Link related Ethernet OAM
• SFP diagnostics
• tests for an Ethernet network or subtending interface:
• SFP diagnostics
• tests for an xPON interface:
• SFP diagnostics
• Embedded OTDR

NT
Figure 27 Position line testing capabilities for DSL - POTS/ISDN lines
DSL applique
RTU (MTA)
Relays Subscriber line
DSL LT (SELT, DELT)

DSL
Modem LPF
line
Towards PSTN or ISAM Voice

Voice LT
POTS/ISDN Relays
SLIC
line
(Narrowband
line testing) Voice applique
6.2 Single-Ended Line Testing

Single-Ended Line Testing (SELT) tests the DSL line from the DSL LT board. SELT
does not require CPE to be connected to the peer side of the line.
SELT can be used as a base for a DSL service level agreement between provider
and customer, and for fault detection, and monitoring of line degradation. SELT
works together with external data analysis software, such as the Nokia 5530 Network
Analyzer (5530 NA), to provide loop pre-qualification and maintenance of the
network.
Note — See the 5530 Network Analyzer User Guide for more
information about SELT using the 5530 NA.
SELT can be performed from the DSL LT board without need for support by the CPE
or for a craftsman to be present at the customer premises.
SELT is based on Frequency Domain Reflectometry (FDR). An excitation signal is
sent on the line and its echo response is analyzed. Processing of the echo response
is done in the 5530 NA. The polarity and position of the reflections indicate the loop
length, attenuation, presence of a gauge wire change, and an open, short, or bridged
tap and its distance from the DSL LT board of the line under test.
SELT provides a line test tool built inside the xDSL modem to measure the loop
characteristics between the U-C and the U-R interface and allows for:
• detection and location of metallic faults (open/short).
• detection, location and length of bridge taps.
• noise measurement and detection of interferences.
• measurement of the line attenuation.
• estimation of the maximum achievable bit rate.
• estimation of the line length.

NT
The operator can check the presence and quality of, for example, a wire termination
Main Distribution Frame (MDF) or SAI / DFI (Service Area / Feeder Distribution
Interface). This feature can be of help in situations where this interconnection is
being provisioned by a third party.
6.2.1 SELT support

SELT measurements are supported on the following boards:
• multi-ADSL LT boards
• VDSL LT boards
• VDSL2 LT boards
These boards can be located in the main subrack or in remote subracks (FD-REM,
VSEM-D, …).
6.2.2 SELT measurements

The following SELT measurements and tests are supported:
• uncalibrated echo response
• echo variance
• noise
The ISAM allows up to 5 simultaneous SELT measurements per LT board.
6.3 Dual-ended line testing

Dual-Ended Line Testing (DELT) tests the DSL line from the DSL LT board. DELT
requires a CPE to be connected to the peer side of the line.
This loop diagnostics function enables the immediate measurement of line
conditions at both ends of the line without dispatching maintenance technicians to
attach test equipment to the line. The resulting information helps to isolate the
location (inside the premises, near the customer end of the line, or near the network
end of the line) and the sources (cross-talk, radio frequency interference, and
bridged tap) of impairments.

NT
The diagnostics data can be obtained in two distinct ways:

• through LOOP DIAGNOSTICS activation: this executes a robust dedicated Loop
Diagnostics protocol. This test mode interrupts normal operation. This mode is
typically referred to as DELT operation.
• through CDA (Carrier Data Acquisition): this collects data available during normal
initialization and L0 operating mode. As activation of CDA requires to go through
the initialization sequence, there is the option to either force this re-initialization or
to defer the data collection to the next scheduled or spontaneous re-initialization.
When a line has L2 mode enabled or is operating in the L2 mode, the data
returned by the CDA function is the L0 data.
6.3.1 DELT support

DELT measurements are supported on the following boards:
• VDSL LT boards
6.3.2 DELT measurements

The following diagnostic measurement data are collected during a test using DELT:
• actual operational mode
• operational mode capabilities (ATU-C/ATU-R)
• SNR margin (US/DS)
• loop attenuation (US/DS)
• signal attenuation (US/DS)
• aggregate output power (US/DS)
• actual PSD (US/DS)
• attainable bit rate (US/DS)
• modem identification parameter: ATU-R ModemVendorID
• carrier-related data: Hlog (US/DS), Hlin (US/DS), QLN PSD (US/DS), SNR
(US/DS)
6.4 Metallic-Ended Line Testing

Metallic-Ended Line Testing (MELT) tests the DSL line from the DSL LT board. MELT
does not require the CPE to be connected to the peer side of the line.
MELT can be used as a base for fault detection and monitoring of line degradation.

NT
MELT works together with external data analysis software, such as the Nokia 5530
Network Analyzer (5530 NA), to provide loop pre-qualification and maintenance of
the network. Also basic management, to start measurements and report results, is
provided through CLI.
Note — See the 5530 Network Analyzer User Guide for more
information about MELT using the 5530 NA.
MELT is performed from the DSL LT board without need for support by the CPE or
for a craftsman to be present at the customer premises.
The MELT functionality is based on the technology for the narrowband POTS
subscriber lines.
MELT provides a line test tool built inside the ISAM to measure the loop
characteristics between the U-C and the U-R interface and allows for:
• detection and location of metallic faults (open/short/bad contacts)
• detection of cable degradation (for example, due to cable moisture)
• detection of external voltages
• line pair identification
• detection of signature topologies
6.4.1 MELT support

MELT measurements are supported on the following boards:
• VDSL LT boards
• SHDSL boards
The list of xDSL LT boards for which MELT testing is supported can be found in the
Product Information manual.
6.4.2 MELT measurements

ISAM limits to execute only one MELT session at a time at an LT board.
The following MELT tests are supported:
• Foreign AC voltage:
Measures foreign AC voltage of a/Earth, b/Earth, and a/b.
Result values:
• Measured AC Voltage of a/Earth, b/Earth, and a/b.
• Measured AC voltage frequency of a/Earth, b/Earth, and a/b.

NT
• Foreign DC voltage:
Measures foreign DC voltage of a/Earth, b/Earth, and a/b.
Result values:
• Measured DC Voltage of a/Earth, b/Earth, and a/b
• Capacitance:
Measures capacitance of a/Earth, b/Earth, and a/b
Result values:
• Measured capacitance of a/Earth, b/Earth, and a/b
• Measurement AC voltage used for determining the capacitance of a/Earth, b/Earth,
and a/b
• Measurement AC voltage frequency used for determining the capacitance of a/Earth,
b/Earth, and a/b
• On-board capacitance used for correcting the measured capacitance value of
a/Earth, b/Earth, and a/b
• Insulating resistance:
Measures insulating resistance of a/Earth, b/Earth, a/b and b/a.
Result values:
• Measured resistance of a/Earth, b/Earth, a/b and b/a
• Measurement DC voltage used for determining the resistance of a/Earth, b/Earth, a/b
and b/a.
• Measurement DC current used for determining the resistance of a/Earth, b/Earth, a/b
and b/a.
• Capacitance of Signature
• Resistance of Ringer
• Cable Pair identification (search tone generation)
• Hazardous voltage (DC>120V or AC>50V).
• Galvanic Signature Detection (For ADSL/VDSL; not for SHDSL).
• End Device Capacitance Detection.
• PPA Detection (ppa / ppa-invers / ppa-not-detected / analysis-not-available)
• ROH Detection (For ADSL/VDSL, not for SHDSL)
• Conductance (a/Earth, b/Earth and a/b).
• Susceptibility (a/Earth, b/Earth and a/b).
• Zener Resistance (For ADSL/VDSL, not for SHDSL)
• Zener Voltage (For ADSL/VDSL, not for SHDSL)
Enhanced MELT Test result reporting offering the following information:

• The time stamp the MELT test has finished
• The remaining time the search tone will be played (Cable pair Identification)
• Validity flag indicating whether the result of a MELT test:
• was not taken or the result is not reliable
• was taken and the result is reliable.
• Textual clarification of the returned MELT test result status.

NT
The MELT Group test capability supports the following execution modes:
• Legacy MELT Group test including
• Foreign DC Voltage
• Insulating Resistance
• Capacitance
• Capacitance Of Signature
and only providing the MELT test results.
• MELT Group test with extended reporting including
• Capacitance
and providing the MELT test result values together with the conditions (Used
AC/DC voltage, frequency, calibration capacitance) under which the tests were
executed
• MELT Collective Group test including
• Foreign AC Voltage
• Capacitance
• Conductance
• Susceptibility
• PPA Detection
• Galvanic Signature Detection
• End Device Capacitance Detection
• ROH-Detection
• Zener Resistance
• Zener Voltage
and providing the MELT test result values together with the conditions (Used
AC/DC voltage, frequency, calibration capacitance) under which the tests were
executed
Further on, the capability is offered to request:

• The Chipset Vendor Identity / HW version / FW version
• During MELT session execution, an overview of the busy ports and busy reason
(awaiting execution, execution on-going, playing search tone, test finished).

NT
6.4.3 MELT status and increased robustness

Regular MELT self-tests are run and will reset the MELT functionality in case issues
are detected.
User will get an indication of the MELT operational status to know upfront if there is
something wrong. The user can check/control MELT functionalities:
• SLIC selftest
• SLIC restart
• SLIC status retrieval
SLIC status provides information to the user about the operational status of the
MELT functionality. If there is a SLIC issue, a MELT measurement will not be
possible because it would return non-valid data. There is still the possibility to force
a MELT measurement.
6.5 ATM F5
On ATM based DSL interfaces it is possible to use ATM F5 loopback. The following
functionality, as is specified in ITU-T I.610, is supported:
• active: the operator asks for a loopback test
• passive: the CPE triggers a loopback test and the ISAM responds
6.6 Link Related Ethernet OAM
6.6.1 Introduction
Link-Related Ethernet OAM (IEEE 802.3 clause 57 standard) enables network
operators to monitor the health of the network and quickly determine the location of
failing links or fault conditions. The feature allows remote side information to be
retrieved for a link connected with a node for which SNMP may not be available as
default.
The feature does not include functions such as station management, bandwidth
allocation or provisioning functions, which are considered outside the scope of IEEE
802.3 section-clause 57 standard.
Link-Related Ethernet OAM is active between the ISAM subscriber side and the
CPE.

NT
6.6.2 General description

Link-Related Ethernet OAM information is conveyed in Slow Protocol frames called
OAM Protocol Data Units (PDUs). Link-Related Ethernet OAM PDUs contain the
appropriate control and status information used to monitor, test, and troubleshoot
OAM-enabled links. Link-Related Ethernet OAM PDUs traverse a single link, and as
such, are not forwarded by MAC clients (for example, bridges or switches).
Link-Related Ethernet OAM provides a mechanism, called discovery, to detect the
presence of an OAM sub-layer at the remote DTE. During the Discovery process, the
ISAM and the CPE exchange their respective configuration information and evaluate
the remote information to determine compatibility. The decision for accepting remote
configuration is based on the remote system OAM mode, version, maximum PDU
size, Parser Action, Multiplexer Action, and function supported information. If these
parameters are accepted, the discovery will complete and-Link Related Ethernet
OAM will be operational. Otherwise, the remote configuration is rejected and requires
operator intervention to rectify the conflicting parameters.
Link-Related Ethernet OAM has provision to retrieve one or more MIB variables, also
referred to as attributes, from the CPE. The operator can retrieve MAC layer counters
and PME counters from the CPE after successful completion of discovery.
The ISAM supports some Link-related Ethernet OAM functions on its Ethernet and
EFM user interfaces, that is, on interfaces terminated on LT boards.
6.6.3 Link-Related Ethernet OAM procedures

The following sections describe the different Link-Related OAM procedures, as
defined in the standard IEEE 802.3 clause 57, and its support within the ISAM.
6.6.3.1 Discovery
The first phase of Link Related Ethernet OAM is discovery. This phase is started
when the operator enables the Link Related Ethernet OAM feature.
Discovery has 3 main functions:
• provide a mechanism to detect the presence of an OAM sub-layer
• identify the devices in the network, along with OAM capabilities
• setup of the OAM link
During this discovery procedure the ISAM always negotiates to become the active
DTE. The ISAM never accepts to become the passive DTE. The ISAM never accepts
the peer DTE to become active (the standard allows both sides to be active).

NT
6.6.3.2 Link monitoring

The standard defines link monitoring tools for detecting and indicating link faults
under a variety of circumstances. Both Event Notification and Variable Retrieve are
part of link monitoring.
1 Link monitoring uses the Event Notification OAM PDU, and sends events to the
peer OAM entity when the number of problems detected on the link cross a
threshold.
2 The manager can initiate a Variable Request to retrieve data about the link from
the peer side. This capability allows emulating a non-intrusive loopback. It
behaves like a “L2 ping” as each Variable Request shall be replied with a Variable
Response.
The ISAM does not support Event notifications: it does not generate Event
Notifications and ignores received Event Notifications.
The ISAM allows the manager to initiate a Variable Request to retrieve remote CPE
data to know the current link status. It supports to retrieve:
• Physical Medium Entity (PME) data
• PME Aggregation Function (PAF) data
By forcing the peer side to be in passive mode, the ISAM does not support the peer
side to retrieve data from the ISAM through Variable Requests / Responses.
6.6.3.3 Remote failure indication

A set of flags in the header of any OAM PDU allows an OAM entity to convey severe
error conditions to its peer.
The ISAM does not report critical events to the peer side.
The ISAM reports reception of following critical events from peer:
• Dying Gasp
• Critical Event
• Link Fault
6.6.3.4 Remote Loopback

Link-Related Ethernet OAM provides an optional data link layer frame-level loopback
mode, which is controlled remotely. This means: one side forces the peer side to go
in a loop mode and to send back the received frames.

NT
The ISAM Ethernet line card supports a method to invoke remote loopback at the
peer end. The looped back traffic can be monitored using performance counters at
the Ethernet physical layer of the line card. ISAM does not support generation of test
traffic towards the peer and relies on network traffic (or an upstream device) to be
used during loopback.
As an active DTE, ISAM ignores any remote loopback request received from the
peer.
GPON / DSL LT boards do not support invocation of remote loopback at the peer
end.

Narrowband Line Testing provides a set of tests for the narrowband on POTS / ISDN
BRA / ISDN PRA subscriber lines, to tests the line from the SLIC on the Voice LT
board. Narrowband line testing support is LT board hardware and software
dependent.
Management of the narrowband line test feature for the Integrated Voice Service is
supported by the 5530 Network Analyzer. Also basic management to start
measurements and report results is provided through CLI and 5520 AMS.
Narrowband line testing is supported for POTS/ISDN LT boards operating in the
H.248 and SIP environment.
6.7.1 NBLT support on POTS

The following NBLT types can be executed for SIP POTS ports:
• Feeding AC/DC Voltage: between a/Earth, b/Earth and a/b wires.
• Foreign AC/DC Voltage: between a/Earth, b/Earth and a/b wires.
• Feeding Current
• Insulating Resistance: between a/Earth, b/Earth, a/battery, b/battery and a/b
wires
• Capacitance: between a/Earth, b/Earth, and a/b wires.
• Impedance: between a/Earth, b/Earth, and a/b wires.
• Low Capacitance Phone detection
• Dial Tone Delay
• M-Socket Detection
• AC Current: between a/Earth, b/Earth, and a/b wires.
• DC Current: between a/Earth, b/Earth, and a/b wires.
• Noise Level
• Howler Tone
• Status Monitoring
• Cable Pair Identification

NT
• Talking
• Line Reverse
• Private Meter Pulse
• Ring Subscriber
• DP / DTMF Signal
• Resistance of User Loop
• Capacitance Of Signature (NPOT-B/C only)
• Resistance Of Ringer (NPOT-B/C only)
• Longitudinal Current (NPOT-B/C only)
• Conductance (NPOT-B/C only)
• Susceptance (NPOT-B/C only)
• Hazardous Voltage (NPOT-B/C only)
• Capacitive End Device (NPOT-B/C only)
• PPA Variant (NPOT-B/C only)
• Receiver Off-Hook (NPOT-B/C only)
• Electric Ringer (NPOT-B/C only)
• Zener Resistance (NPOT-B/C only)
• Zener Voltage (NPOT-B/C only)
• Forced Ringing (NPOT-B/C only)
• Diagnosis Call
The following NBLT types can be executed for H.248 POTS ports:
• Feeding AC/DC Voltage: between a/Earth, b/Earth and a/b wires.
• Feeding Current
• Insulating Resistance: between a/Earth, b/Earth, a/battery, b/battery and a/b
wires
• Impedance: between a/Earth, b/Earth, and a/b wires.
• Low Capacitance Phone detection
• Dial Tone Delay
• M-Socket Detection
• AC Current : between a/Earth, b/Earth, and a/b wires.
• DC Current : between a/Earth, b/Earth, and a/b wires.
• Noise Level
• Howler Tone
• Status Monitoring
• Cable Pair Identification
• Talking
• Line Reverse
• Private Meter Pulse
• Ring Subscriber

NT
• DP / DTMF Signal
• Resistance of User Loop
• Forced Ringing (NPOT-B/C only)
• Diagnosis Call
6.7.1.1 NBLT type categories

NBLT types of the same category can be invoked in the same NBLT session
requested for a POTS port.
Table 12 NBLT type categories
Electric DialTone AC DC Noise Howler Status Cable Talking Forced

Current Level Tone Monitored Identity Ringing
Feeding AC Dial Tone AC Noise Howler Status Cable Talking Forced

Voltage delay Current Level Tone Monitoring Pair Ringing
Identifi-
cation
Foreign AC DC Line
Voltage Current Reverse
Feeding DC Private
Voltage Meter
Pulse
Foreign DC Ring
Voltage Subscrib
er
Feeding DP /
Current DTMF
Signal
Resistance
Of User Loop
Insulating
Resistance
Capacitance
Impedance
Low
Capacitance
Phone Detect
M-socket
Capacitance
Of Signature
Resistance
Of Ringer
Conductance
(1 of 2)

NT
Electric DialTone AC DC Noise Howler Status Cable Talking Forced

Current Level Tone Monitored Identity Ringing
Susceptance
Hazardous
Voltage
Capacitance
End Device
PPA Variant
Receiver
Off-Hook
Electronic
Ringer
Zener
Resistance
Zener
Voltage
Noise Level
AC current
DC current
(2 of 2)
6.7.1.2 Group Test

The Legacy Group test (SIP and H.248), providing the raw NBLT test results,
supports the execution of the following NBLT test types:
• Foreign DC Voltage (tr, tg, rg)
• Foreign AC Voltage (tr, tg, rg)
• Insulating Resistance (tr, rt, tg, rg)
• Capacitance (tr, tg, rg)
The Group test with extended reporting (SIP integrated voice service only), providing
the raw NBLT test results together with the conditions (Used AC/DC voltage,
frequency, calibration capacitance) under which the tests were executed, supports
the execution of the following NBLT test types:

NT
The Collective Group test (SIP integrated voice service only), providing the raw
NBLT test results together with the conditions (Used AC/DC voltage, frequency,
calibration capacitance) under which the tests were executed, supports the
execution of the following NBLT test types:
• Resistance Of Ringer
• Conductance (tr, tg, rg)
• Susceptance (tr, tg, rg)
• PPA Detection
• Termination Electronic Ringer Detection
• Zener Resistance
• Zener Voltage
6.7.1.3 Busy-Overwrite TRUE/FALSE (SIP Integrated Voice

Service only)
The "Busy-Overwrite" feature introduced at NBLT session level allows to forcibly
execute a NBLT test.
Requesting a new NBLT test at a particular port with the busy-overwrite parameter
set to "false”:
• While another NBLT test is still running at the same voice LT board (same or
different POTS port), this will cause the new NBLT test request to be rejected.
• While a call is ongoing at the same POTS port, this will cause the new POTS
NBLT test request to be rejected if that new POTS NBLT test cannot concurrently
execute with an ongoing call at that same port.
Starting a new NBLT test at a particular port with the busy-overwrite parameter set
to "true”:
• While another NBLT test is still running at the same voice LT board (same or
different POTS port), this will cause the new NBLT test request to be rejected.
• While a call is ongoing at the same POTS port, this will cause the ongoing call to
be aborted if that new NBLT test cannot concurrently execute with an ongoing call
at that same port before the new NBLT test starts executing.

NT
6.7.1.4 Test-Access ON/OFF (SIP Integrated Voice Service

only)
The "Test-Access" feature introduced at individual SIP termination level allows a
particular line to enter the "Test-Access" state and this for a well defined time period.
When a line has entered the "Test-Access" state, then only NBLT testing can be
performed at that line. Incoming as well as outgoing call attempts are blocked at that
line.
Both the enabling/disabling of the "Test-Access" state for a particular line as well as
the time period during which the "Test-Access" state applies are configurable at
individual SIP termination level.
In addition, the system allows, again via configuration, a line to forcibly enter the
"Test-Access" state in case a call would be ongoing at that line at the moment the
"TestAccess" ON state is requested. Any ongoing call gets immediately dropped
when a line is requested to forcibly enter the "Test-Access" state.
6.7.1.5 Enhanced NBLT test result reporting (SIP

Integrated Voice Service only):
Following results are reported:
• The time stamp the NBLT test has finished.
• The validity flag indicating whether the result of a NBLT test
• was taken and the result is reliable
• was not taken or the result is not reliable
• Textual clarification of the returned NBLT test result status.
6.7.1.6 Forced Ringing

The purpose of the Forced Ring Test is to allow the operator to verify whether the
line has been properly wired and a phone is connected. Executing the Forced Ring
results in putting ringing tone at the subscriber line. The maximum ringing duration is
hardcoded to 120s.
The test results indicate whether the ringing is stopped by subscriber off-hook, 120
sec timeout or ended by the operator.

NT
6.7.1.7 Diagnosis Call

After the operator has created a new termination in the NE and has set the
termination in admin-up, the NE offers the capability to initiate an automated voice
diagnostic test call to the DN of the newly created termination.
The voice diagnostic test call is initiated by means of the usual CLI/SNMP
management interface.
The purpose of this voice diagnostic test call is to check whether the SIP/H248
termination has been well configured E2E and is capable to establish a basic voice
call over the negotiated bearer path.
When the CLI/SNMP command requesting the set-up of a voice diagnostic test call
is received and the termination under test is in idle on-hook state, then the NE
attempts to establish a basic call to the given DN.
When the CLI/SNMP command requesting the set-up of a voice diagnostic test call
is received and the termination under test is not in idle on-hook state, the NE rejects
the request.
The diagnostic voice call is supervised by a maximum test call duration timer and
measures the bearer traffic delay.
The diagnostic voice call is ended from the moment bearer traffic has been detected
and the signaling process has completed.
Otherwise, the call is ended upon maximum test call duration time-out.
The operator can retrieve the result of the diagnostic voice call by means of the usual
For the termination under test, the incoming test call is identical to a normal incoming
basic voice call.
The CLI/SNMP command to request the diagnostic voice call has the following input
parameters defined:
• Test mode:
• Normal mode, deny test if termination is BUSY.
• Forced mode, not implemented yet (defined for future use).
• Destination number:
• DN of the termination to which the diagnostic voice call is to be established.
• Maximum test call duration timer
The following diagnostic voice call output/result is provided by the NE:
• Test est result (Passed/Failed/Call Fail Busy/Call Fail Other).
• Bearer traffic delay.
• In case of a failure, the fail reason is provided by means of an ASCII formatted
text string.

NT
6.7.2 H.248: NBLT support on ISDN BRA

The following NBLT types can be executed for H.248 ISDN ports:
• Insulating Resistance: between a/Earth, b/Earth and a/b wires
• ISDN loopback:
ISDN BA loopback test with test pattern:
• Complete loopback with test pattern.
Loopback of full bit stream (B1 and B2 and D channel)
• Loopback at ISDN LT and NT/NT1
Self test on layer 1 by the ISAM-V: ISAM-V generates a test pattern and activates a
loopback at the LT + verification and evaluation of received test pattern.
Test towards the NT/NT1: ISAM-V generates a test pattern and activates a loopback
at the NT + Verification and evaluation of received test pattern
Only when the transmitted and received patterns are exactly the same, the test is
considered as passed.
The test pattern is hard-coded (NOT configurable).
• Precondition for executing ISDN BA loop back test:
The ISDN BA loop back test will be rejected in case the ISDN B channel would be
busy.
Otherwise the ISDN BA loop back test (including loopback test to the NT board and
loopback test to the LT board) will be accepted and executed (on condition that the
ISDN user port has been provisioned).
6.7.2.1 NBLT type categories

NBLT types of the same category can be invoked in the same NBLT session
requested for an ISDN port.
Table 13 NBLT type categories on ISDN
Electric ISDN Loopback
Foreign AC Voltage ISDN Loop Back
Foreign DC Voltage
Insulating Resistance
Capacitance

NT
6.7.2.2 Group Test

The Legacy Group test, providing the raw NBLT test results, supports the execution
of the following NBLT test types:
6.7.3 SIP: NBLT support on ISDN PRA E1 interface

The following NBLT types can be executed for SIP ISDN PRA ports:
• Remote line loop back: this test is to loop back data/clock at the transmitter
(before framer and decoder). It will not reframe the E1 frame sent by the Bit Error
Rate Tester equipment.
• Remote payload loop back: this test is to loop back data after passing the receiver
(including wander and jitter compensation). It will reframe the E1 frame then loop
back to Bit Error Rate Tester equipment.
• Local loop back: this test is to loop back local generated data via the analogue
receiver which is disconnected from the receiver line.
• Cable loop back: this test checks the entire data path. This test requires the
plug-in of an E1 loop cable into the RJ45 connector on the front panel of the ISDN
LT board.
Loopback is done with the full bit stream (all B channels and D channel)
Once a loopback test session has started, outgoing calls are blocked and incoming
calls are rejected.
A loop back test session can only be started when all B channels of an E1 interface
are in idle state. Ongoing calls cannot be interrupted by a loop back test.
An ISDN PRA termination cannot be deleted nor locked/unlocked while a loop back
test is running.
A loop back test can run regardless of the ISDN PRA termination administrative and
operational state.

NT
6.7.4 SIP: NBLT support on CAS-R2 E1 interface

The following NBLT types can be executed for SIP CAS-R2 ports:
• Remote line loop back: this test is to loop back data/clock at the transmitter
(before framer and decoder). It will not reframe the E1 frame sent by the Bit Error
Rate Tester equipment.
• Remote payload loop back: this test is to loop back data after passing the receiver
(including wander and jitter compensation). It will reframe the E1 frame then loop
back to Bit Error Rate Tester equipment.
• Local loop back: this test is to loop back local generated data via the analogue
receiver which is disconnected from the receiver line.
• Cable loop back: this test checks the entire data path. This test requires the
plug-in of an E1 loop cable into the RJ45 connector on the front panel of the CAS
R2 LT board.
Loopback is done with the full bit stream (all B channels and D channel)
Once a loopback test session has started, outgoing calls are blocked and incoming
calls are rejected.
A loop back test session can only be started when all B channels of an E1 interface
are in idle state. Ongoing calls cannot be interrupted by a loop back test.
A CAS R2 termination cannot be deleted nor locked/unlocked while a loop back test
is running.
A loop back test can run regardless of the CAS R2 termination administrative and
operational state.
6.7.5 Extended Test modes

The following extended test modes can be performed:
• Block Reading Mode:
One extended new test mode (only for Foreign Voltage AC/DC, Capacitance,
Insulation Resistance) for the basic POTS electrical test types, it will return 20
reading results of one electrical test item in a session.
• Continuous Reading Mode:
Another extended new test mode (only for Foreign Voltage AC/DC, Capacitance,
Insulation Resistance) for the basic POTS electrical test types, in one test
session, the operator can repeat the test item after the last test result is reported
to it. This mode also accepts only one electrical test item in a session.
Note — Both extended test modes are not supported on ISDN.

NT
6.7.6 Enhanced NBLT result reporting (SIP based VoIP

service only)
The NBLT result reporting offers the following additional information:
• The time stamp the NBLT test has finished
• Textual clarification of the returned NBLT test result status.
Further on, the capability is offered to request during NBLT session execution, an
overview of the busy ports and busy reason (awaiting execution, execution on-going,
playing search tone, test finished).
6.8 SFP diagnostics

SFPs are used to terminate network, subtending, inter-shelf, line board Ethernet
interfaces or xPON.
The ISAM supports the digital diagnostics function in line with SFF-8472.
When isolating a data path problem, for example, fiber degradation, the operator can
use the management interface to retrieve the instantaneous received optical power
level and transmitted optical power level from an SFP.
This diagnostics functionality is available on all SFP, SFP+ and XFP interfaces of the
ISAM system.
6.9 Embedded OTDR

Optical time-domain reflectometry (OTDR) is an opto-electronic measurement
technology used to characterize an optical fiber plant. Classical OTDR uses external
measuring equipment which injects a series of optical pulses into the tested fiber.
From the same end of the fiber the equipment then extracts light that is scattered
(Rayleigh backscatter) or reflected back from points along the fiber.
OTDR may be used for estimating the fiber length and the overall attenuation,
including splice and mated-connector losses. OTDR is also commonly used for fault
finding on installed systems.
Figure 28 shows the main advantages of the embedded OTDR solution.
• the easy deployment
• the integrated management
• the OTDR measurements are possible without the requirement for expensive
external test equipment
• the measurement capability is always available and is non-service affecting
• the measurements do not require an operator to be on-site

NT
Figure 28 Embedded OTDR main advantages

GPON
OLT Fibre coupler
(signal attenuated) Filter at ONT
Splitter to block OTDR
signal
F1
Optical switch F2
ONT
λ OTDR
Analysis OTDR
tool 1310 1490 1625 nm
GPON
OLT
Splitter
F1
F2
Embedded OTDR
SFP
ONT
Network
1310 1490
analyzer
Also used as λ OTDR
The ISAM supports SFPs for GPON interfaces that have an embedded OTDR
capability, allowing OTDR measurements without the requirement for expensive
external test equipment. Therefore, the measurement capability is always available,
is non-service affecting and does not require an operator to be on-site.
The 5530 NA-Fiber provides the necessary support to interpret the results of the
OTDR measurements.

NT

System Description for FD 100/320Gbps NT and FX Network timing reference support in ISAM
NT
7 Network timing reference support

in ISAM
7.1 Introduction
7.2 ISAM clock system and NTR extraction
7.3 Downstream NTR clock distribution
7.4 Time phase and ToD support
7.5 Applicable standards
7.1 Introduction
.
7.1.1 Scope
This chapter describes the different clock systems and Network Timing Reference
(NTR) and ‘Phase and ToD’ synchronization capabilities of the ISAM. The
capabilities depend on the hardware variants. A specific ISAM board will not support
all of these capabilities. To know which of these functions are supported on a specific
ISAM board, refer to the Product Information document and/or the Unit Data Sheet
(UDS) of that board.
A summary of NTR and ‘Phase and ToD’ capabilities of the most advanced board
variants in each family is given in Figure 29 and Figure 30. In many cases, less
advanced board variants with fewer or no NTR and ‘Phase and ToD’ capabilities are
available. These can be used for deployments where these capabilities are not
needed. The next section will clarify this at a high level.
7.1.2 Applications as driver for specific clock or NTR and

‘Phase and ToD’ requirements
This section discusses high-end NTR and ‘Phase and ToD’ capabilities on the ISAM
such as BITS, SyncE, NTR on DSL, IEEE1588v2 and so on. However, many
applications such as High Speed Internet (HSI), Video, Packet Voice, Data Offload
in Mobile Backhaul do not require such high-end clock system (see Table 14). For
these applications the usual and less complex NTs and LTs are sufficient for network
deployments.

Network timing reference support in ISAM System Description for FD 100/320Gbps NT and FX
NT
Each access technology (ADSL, VDSL2, SHDSL, Ethernet, PON) may have its
specific clock requirements to guarantee synchronization and proper functioning
between both ends (CO and end-user). However, in general, these clock
requirements are taken care of in the design of line boards (LTs) for that specific
access technology, and do not impose any restrictions on the specific NTs which can
be used. Some exceptions exist (for example, voice over POTS line) and they will be
covered in the section on that access technology. Clock requirements or restrictions
related to a specific access technology, are in general not in the scope of this
chapter.
Table 14 Specific clock requirements per application
Application (over DSL, Ethernet or Required on NT Required on LT

PON)(1)
High Speed Internet (HSI), External NTR source: not required All LTs are suited, that is, no
Video, Local Clock Accuracy: low (32 or 50 specific clock requirements
ppm is sufficient) on LT.
Packet Voice
Voice via POTS line External NTR source: not required All voice LTs are suited, that
Local Clock Accuracy: 4.6 ppm is is, no specific clock
required requirements on LT.
Long fax or modem calls via POTS External NTR source: SyncE In or All voice LTs are suited, that
line BITS In is, no specific clock
requirements on LT.
NTR distribution from network node • External NTR source: SyncE In or NT or NTIO output can be
to network node (for example, to BITS In used, and then no
other DSLAMs) • NTR Out: SyncE Out or BITS Out requirements on LT.
Alternatively, SyncE output
on an Ethernet LT.
Mobile backhaul data offload External NTR source: not required All LTs are suited, that is, no
Local Clock Accuracy: low (32 or 50 specific clock requirements
ppm is sufficient) on LT.
Full mobile backhaul (with frequency External NTR source: SyncE In or • DSL LTs: NTR on VDSL2
synchronization) BITS In or IEEE1588v2 In or SHDSL (Note: NTR on
ADSL is not supported on
DSL-LTs)
• Ethernet LTs: SyncE out
• PON LTs: no specific
clock requirements on LT
(Note: ONT with BITS out
or SyncE out needed)
Full mobile backhaul with phase External NTR and ‘Phase and ToD’ PON LTs: ToD out on LT
synchronization or ToD requirement source: IEEE1588v2 In or 1PPS+ToD
in
Note: Phase synchronization or ToD is
only required for some mobile
applications, and even then in most
cases an alternative option exists
which does not require these features.
Alternative solution: Provide Mobile
Backhaul data offload only, with phase
sync or ToD via a different channel (for
example, GPS/ GNSS receiver)
(1 of 2)

NT
Application (over DSL, Ethernet or Required on NT Required on LT

PON)(1)
Packet-based Business applications External NTR source: not required All LTs are suited, that is, no
Local Clock Accuracy: low (32 or 50 specific requirements on LT.
ppm is sufficient)
Business applications with NTR External NTR source: SyncE In or • DSL LTs: NTR over
requirements (for example, TDM BITS In SHDSL or VDSL2
leased lines) • Ethernet LTs: SyncE out
• PON LT: no specific clock
requirements on LT
(2 of 2)
Note
(1) DSL is a generic term in this chapter referring to ADSL, ADSL2, ADSL2plus, VDSL2 and SHDSL. PON is a
generic term in this chapter referring to both GPON and XGS-PON / TWDM-PON
Only some applications such as Full Mobile Backhaul (with frequency

synchronization) and some Business Applications (for example, TDM leased lines)
will require NTR support (see Table 14). This then means that NT boards are
required which either support BITS inputs or SyncE inputs, or IEEE1588v2 inputs
and LT boards supporting NTR over DSL in case of SHDSL or VDSL2, and SyncE
out on Ethernet lines. For PON LTs, there are no specific requirements, since the
framing of PON has inherent sufficient high clock quality (assuming the appropriate
NT is used). But, an ONT needs to be selected with an NTR output (for example,
SyncE on an Ethernet output port, or a BITS out).
NTR in mobile applications, and especially in mobile backhaul, frequency
synchronization has always been sufficient in the past, and phase synchronization or
ToD was not required. However, with new mobile generations (for example, LTE)
also the latter requirements may appear. In general, different options exist in the new
mobile standards, and only some of these options (for example, TDD technology, or
eMBMS/eICIC features over FDD) require ToD, It depends very much on the
selected technology which will be used in a mobile network, if phase synchronization
or ToD will be possibly required there. And even if the latter is the case, the ISAM is
then still capable to transport the mobile data, if the phase synchronization or ToD
timing signal is transported in parallel via IEEE1588v2 or an alternative way (for
example, via GPS/ GNSS).
To know which NT boards and LT boards in the ISAM portfolio support the specific
NTR and and ‘Phase and ToD’ requirements for a certain application (according to
for example, Table 14), please consult the Product Information document and/or the
UDS of that board.
The ISAM NTR features support a very wide range of applications. On the market
other clock solutions are available, which in most cases are just alternatives, that is,
they just support the same applications in a different way. In some cases, they may
be transparent to the ISAM, and could therefore also be used. An example is
Adaptive Clock Recovery (ACR). ACR requires larger buffers and a better local
oscillator in the end-receiver, and will therefore be more expensive. An investment in

NT
a somewhat more expensive ISAM NT board with SyncE or BITS support will then
probably be better than having to deploy a more expensive receiver with ACR at
every end-user. Secondly, the larger buffers needed for ACR increase the
end-to-end delay and may therefore require echo-cancellation for interactive
services (for example, voice or video calls).
7.1.3 Overview of NTR support on ISAM

Table 14 made clear that NTR is not required for all applications. However, in some
cases it is required. Figure 29 gives a high-level view on the supported options on
NT boards and LT boards for the 100/320Gbps ISAM NT family.
Figure 29 Overview of possible NTR support on some LTs and some NTs
in the FD 100/320Gbps ISAM NT family
GPON
8 kHz GPON PHY

BITS backplane GPON
G.703
8 kHz
DSL
8 kHz Sync Eth NTR
LT
Eth
backplane GE PHY backplane DSL
CTRL
Sync Eth
DSL
8 kHz NTR
NT
LT
Voice
GE PHY 8 kHz
backplane DSL
backplane
NTIO
POTS/ISDN
Voice
8 kHz
SEM/Distributed REM
backplane POTS/ISDN
Sync Eth
GPON
GE PHY 8 kHz GPON PHY
Sync Eth Sync Eth backplane GPON
BITS or Sync Eth
GE PHY
GE PHY GE PHY
NTIO Sync Eth
8 kHz
Eth
Hub ISAM Sync Eth Optional GE backplane GE PHY
GE PHY network
DSL
8 kHz NTR
NT
LT
G.703
backplane DSL
NT
Voice
8 kHz
backplane POTS/ISDN
Optional BITS Sync Eth
NT
PDH/SDH G.703 GE PHY

network
Collocated ISAM shelves Outdoor ISAM
In addition, the 480G/1.28T bps FX NT also supports IEEE1588 as NTR source as

indicated in Figure 30.

NT
Figure 30 NTR options for FX NT ISAM family
GPON GPON GPON

8 kHz GPON PHY
BITS backplane GPON
G.703
8 kHz GPON PHY
backplane GPON
Sync Eth
NT
GE PHY 8 kHz GPON PHY
backplane GPON
NTIO 8 kHz Sync Eth
Eth
IEEE1588
backplane GE PHY
GE
GPON
8 kHz GPON PHY
GE PHY backplane GPON
Sync Eth Sync Eth
BITS or Sync Eth
GE PHY
GE PHY GE PHY
NTIO
GPON
8 kHz GPON PHY
Hub ISAM Sync Eth Optional GE backplane GPON
GE PHY network
IEEE1588
NT
GPON
IEEE1588 8 kHz GPON PHY
GE
G.703
GE backplane GPON
8 kHz Sync Eth
Eth
NT
backplane GE PHY
Optional BITS Sync Eth
PDH/SDH G.703 GE PHY
NT
network
Outdoor ISAM
Collocated ISAM shelves
The 1.28 Tbps NT (FX) has the same NTR capabilities as the 480 Gbps NT (FX)
The 320G and 480G NT variants can be deployed in ISAMs used as a VULA node,
a configuration where Content Providers directly interface with the ISAM network
interfaces. This scenario requires SLA enforcement on the traffic received from the
Content Providers, enforcement performed by a 10GE Ethernet LT hosting the uplink
interfaces. When combining this network model with an NTR distributed over the
network (SyncE / IEEE ToD), the 10G Ethernet LT can be involved in retrieving the
network clock if there is no NT interface connected to the network. This can be the
case when:
• The Access Provider belongs to an organization that also owns a Content
Provider, whose traffic must be handled in exactly the same way as other Content
Providers by regulation (that is, through the 10GE Ethernet LT)
• Some network simplification wants to be achieved by reusing the interface
established between the Access and Content Providers belonging to same
organization, that is, where NTR can be considered trusted
In order to support this specific scenario, the 10G Ethernet LT, operating in uplink
mode, allows to retrieve SyncE from its first Ethernet port (position hard coded, GE
or 10GE rates are both supported through provisioning) and passes the retrieved
clock to the NT card(s) using a dedicated cable connected to the NT BITS interfaces,
allowing to fully reuse the NT BITS operations.

NT
Table 15 ISAM used as VULA node
NT 10GE
P2P LT
Simplex Simplex 10GE P2P LT

• SyncE extraction from the first uplink
NT FELT
• Generate BITS to one NT
NT
• “Legacy" mode, that is the same as using an
external BITS sources
Duplex Not supported, NT only supports one single BITS input
NT FELT
FELT
Duplex Simplex 10GE P2P LT

NT FELT
• Generate BITS to both NTs using a Y cable
NT
NT Y BITS-cable • “Legacy" mode, that is the same as using an
Note: no full BITS redundancy (that is, FELT-B failure

case is not covered)
Duplex 10GE P2P LT

NT FELT
• Generate BITS to one NT
• Same implementation as the simplex/simplex case
NT
NT FELT
• “Legacy" mode, that is the same as using an
If the ISAM is operating as a VULA node using a 10GE Ethernet LT as uplink, the
remaining of this chapter still applies, considering the 10GE Ethernet LT as an
"external NTR" source interfaced with the NT BITS interface.
Note — For an overview of which NT boards and which LT

boards support the required synchronization functions, refer to
the Product Information document of your system and/or the
Unit Data Sheet (UDS) of that board.

NT
Although not shown in these figures, also deployments with a mix of nodes are
possible from both figures. For example, a standalone REM connected via SyncE to
an Ethernet output on an Hub ISAM with NT from the FD 100/320Gbps NT and FX
NT family.
Note — The distributed REM requires a fiber connection per LT

board for the data transport. However, only the fiber to LT1
transports the NTR signal, which is then distributed in the REM
to both LT boards. Hence, when that fiber link is broken, the
NTR features described in this chapter are not fully supported
anymore for all lines in that distributed REM.
7.2 ISAM clock system and NTR extraction
7.2.1 High level description of the external port selection

for NTR
Figure 31 gives a high level description on how the external port is selected that will
be used for NTR extraction. This is valid for BITS, SyncE and IEEE1588 which are
linked to physical ports.
An ISAM hardware configuration has a number of external ports RJ45-a, RJ45-b,
SFP-1,…, SFP-n, XFP-1,…, XFP-m available on NT-A, and possibly also on NT-B,
and NTIO, in case the latter are also present. Not every port can be used for
synchronization input. Hardware design of the specific ISAM boards determine which
ports can be used for SyncE input (some Ethernet ports) or BITS input (some RJ45
ports), and this will then form a subset of the total number of external ports (see
Figure 31).
Figure 31 Port selection for external NTR (SyncE and BITS)
External
ports on NT-A, Ports which
(NT-B and support
NTIO) synchronisation
input (BITS, SyncE
or IEEE1588)
Static
selection of Dynamic
RJ45-a 2 ports for selection of
RJ45-b Static NTR input ISAM 1 port for
HW design RJ45-a configur- clock NTR Clock
SFP-1 of specific RJ45-b ation on system distribution
card ISAM operation
e
… SFP-f on ISAM
T
renc
… … backplane
=R
R ef e
SFP-n SFP-g to LTs

U
XFP-r and then
XFP-1 ... to access lines
… XFP-s
…
XFP-m
Note:
RJ45-a is the connector for BITS-A on NT-A
RJ45-b is the connector for BITS-B on NT-B

NT
The operator needs to configure which of these ports are valid inputs for NTR in his
network deployment. Maximum two ports can be configured for this (T and U in
Figure 31).
The ISAM clock subsystem will then dynamically select one of these two ports as
NTR reference, according to the actual quality of the NTR signals on these ports,
configured priority of these ports, and so on, according to the ITU Rec G.871 section
5.6 criteria and selection algorithm.
7.2.2 Possible External NTR sources

The ISAM supports the following external NTR clock sources:
• One BITS / SSU interface per NT faceplate:
This interface supports a 2.048 MHz plain clock signal, an E1 framed signal, or a
DS1 framed signal. For ETSI markets, the default expected input is an E1 framed
signal.
SSM is supported on this interface for the 480G and 1.28T NT family (7360 ISAM
FX) but not on 100G/320G NT.
BITS has been a very common way of clock distribution in PDH/SDH networks for
already a long time, and is therefore available in many COs. Even after migration
from PDH/SDH networks to Metro Ethernet, it is still available in many cases for
clock distribution. Because Synchronous Ethernet requires new specific hardware
not yet available on first generations of Metro Ethernet networks, BITS is still an
important option for providing NTR to ISAMs in COs.
• One or more Synchronous Ethernet interfaces on the NT or NTIO faceplates:
This can be only supported on optical 1 GE and 10 GE interfaces, and not at other
speeds (for example, 100 Mbps), nor on any electrical interface.
SSM can be enabled on these interfaces.
Further network rationalization is the driver to move all functions to the Metro
Ethernet, so the PDH/SDH network becomes completely obsolete. Consequently,
over time, SyncE will become the more important solution for NTR. Since
SyncE-support requires specific hardware, upgrades of some nodes in the Metro
Ethernet network may be required.
• One or more PTP (also known as IEEE1588v2) clock sources:
This is a packet-based clock synchronization method using Ethernet packets via
an optical interface. Next to support for frequency synchronization this protocol
also provides support for time synchronization over a packet network. Only the
480G and 1.28T bps NT family (FX) ISAM supports both frequency
synchronization and time synchronization with IEEE1588v2 PTP mode.
Figure 29 and Figure 30 give a high-level view of the possible interfaces to external
NTR sources for both the 100G and 320G NT (FD) respectively the 480G and 1.28T
NT (FX) family. More detailed information on the actual capabilities of specific boards
is available in the Product Information document for your product and/or the UDS.
Also there one can find which ports on these boards can be used as external NTR
sources (and which ones not).

NT
7.2.3 Single NT clock operation

Figure 32 shows the NTR configuration with a single NT board, and with an NTIO
board added as a possible option. The internal system NTR clock can be
synchronized to any of the external NTR sources described in the previous
subsection: BITS, SyncE and IEEE1588.
Figure 32 ISAM configuration for NTR provisioning with single NT.
SFP
NT Front plate LT 1
1 GE Ethernet Sync Eth out
Sync Eth out µP
SFP
NT Front plate
1 / 10 GE SFP+
Sync Eth in
SFP
NTIO Front plate
1 GE Sync Eth out
SFP
LT 18
PHY
NTIO Front plate SFP Sync Eth out
1 GE Sync Eth in PHY
SFP PTP
NTR clock generation

Sync Eth out T4 : BITS/SSU
NTR clock source

IEEE
1 GE NTIO 1588 1 out
selection
T3 : BITS /SSU 1 in
T0 8 kHz
S
NTIO Front plate NTR 1 to
XFP E
LT 1 -18
10 GE Sync Eth in L TC/
Sync Eth out OC XO
XFP
10 GE NTIO Single NT
The 8 kHz NTR signal generated by the internal system NTR clock is distributed to
the subscriber interface logic on the LT boards.
Up to two ports can be configured as valid external NTR input ports (see “High level
description of the external port selection for NTR”). One will be the reference, and the
other one is for protection (see “Clock protection: Overview”).
If all available external NTR clock sources fail, then this clock will switch to Hold-over
mode, if locking to the external NTR clock source was completed at the time of
failure.
In case no valid external NTR clock source is connected during system start-up, the
internal NTR clock will remain in free-running mode, that is, it will adapt to the output
frequency of its local oscillator.

NT
7.2.4 Clock protection: Overview

When applications are running on equipment connected to ISAM which require NTR,
it is important that this NTR signal is provided uninterrupted, and that protection is
available against degradation or failure of selected external NTR sources. This is
supported in the following ways:
• Switching to another redundant external NTR clock source, if available
(see “Clock protection: External NTR source protection”).
• An internal NTR clock hold-over function (see Figure 33), which continues to
apply the last known clock correction data to the internal NTR clock, in order to
keep the NTR clock to dependent equipment as stable as possible during
absence of external references.
• Switching to a second NT with identical NTR clock system when the active NT
fails (see “Clock protection: NT redundancy”)
Figure 33 States and state transitions for the internal NTR clock
AUTONOMOUS MODE
Holdover mode Free-run mode

- freeze holdover - rest holdover
memory memory
- lock clock to - free-run clock Configure autonomous mode
holdover memory
Valid reference
available No valid reference
No valid reference nor memory
nor memory Locked mode available
available
- update holdover FORCED FREE-RUN MODE
memory
- lock clock to
selected reference Free-run mode
- rest holdover
Configure forced memory
free-run mode - free-run clock
7.2.5 Clock protection: External NTR source protection

Up to two ports can be configured as valid external NTR input ports (see “High level
description of the external port selection for NTR”). One port will be the reference,
the other port is for protection. If the reference fails, then the other selected NTR
input port will be used for clock synchronization.

NT
NTR clock source failure is detected from:

• Loss of Signal
• A signal frequency that falls outside the capture range of the internal system NTR
clock
• AIS signal on BITS interface.
• Failure to receive SSM messages on an SSM enabled Synchronous Ethernet link
during more than 5 seconds
• Reception of SSM messages with a QL value below the configured threshold
value.
• Not locked on PTP packet stream (IEEE1588)
Per external NTR source type, the following protection is supported:

• BITS input redundancy always requires 2 NT boards, since maximum one BITS
input interface is available on NT boards. If the reference BITS input fails, then the
BITS input on the other NT will be used as NTR, even if this other NT board is in
standby mode. BITS input redundancy is supported on all NTs, with BITS input.
• SyncE source redundancy is supported with all input ports either on one NT, or
with one input port on an NT board (for example NT-A) and a second input port
on the NTIO board that is finally oriented towards the same NT (that is the NT-A).
The system:
• supports 2x SyncE on simplex NT
• supports 1x SyncE on simplex NT + 1x SyncE on NTIO
• supports 2x SyncE on NTIO (simplex and redundant NT)
• NOT supported is 2x SyncE on redundant NT (1x per NT) or NTIO except for
480G/1.2T FX NTs.
• IEEE1588: the PTP circuitry on the NT supports two kinds of IEEE1588 packet
encapsulation modes:
• IP Unicast mode, which performs the IEEE1588 Best Master Clock Algorithm
(BMCA) based on three different, configured PTP Masters, but tracks only one of
these actively: the highest one in the Acceptable Master Table (AMT).
• Ethernet Multicast mode, which performs BMCA on several different input PTP
masters and tracks only one of these actively.
Actively tracking two redundant Grand Masters will require a redundant NT pair.
Resilience with respect to L2 connectivity can be guaranteed via the usual means
like LAG.
If two PTP Masters need to be actively tracked, then each NT in a redundant
configuration has to track one of those two.
Any mix of BITS and SyncE is supported when both inputs are on the same NT, or
on one NT and NTIO. For example, BITS as the reference for NTR, while SyncE as
NTR source protection.
Note — On a redundant NT, IEEE1588 cannot be mixed with

BITS or SyncE.

NT
However, such combinations are expected to be less common in the field, since
either the long-existing BITS on the PDH/SDH network is used, or else this network
has been completely outphased and the network has moved fully to metro Ethernet
aggregation and uses SyncE or IEEE1588.
7.2.6 Clock protection: NT redundancy

Also in ISAM configurations with NT redundancy, the NTR function should restore
and this to the same quality, when an NT fails and the redundant NT takes over. The
following restrictions have to be taken into account:
• In case SSU / BITS is applied, a valid signal has to be provided to both NT board
front plates. This will guarantee that the system NTR clock on the stand-by NT
board can be synchronized to the network in case the active NT board hardware
fails or is removed.
The BITS signal on the NT in stand-by mode can be monitored
• In case NT redundancy needs to be provided with SyncE for NTR, the SyncE
input(s) should be connected to the NTIO board which has connections to both
NTs. In this way, also SyncE input redundancy can be supported.
• In case IEEE1588 is applied, both the active and the standby NT can actively track
one PTP Grand Master out of the maximum three devices configured per NT. Full
clock redundancy is also supported in PTP mode.
Once the redundant NT has taken over from the failing NT and has arrived in a stable
state, the NTR function will be compliant to the typical related standards. These
standards also define the maximum allowed phase jump during a transient effect.
Switch-over from a failing NT to a redundant NT is one of these transient effects, and
ISAM does exceed in that case the maximum allowed phase jump. Since such NT
switch-overs are exceptional, and since phase jumps may be filtered to some extent
by end-user equipment, the impact on services is expected to be limited.
7.2.7 Detailed behavior of internal system NTR

The operator can configure the following elements regarding NTR:
• The external NTR source(s) to be used:
• BITS/SSU
• Synchronous Ethernet interfaces
• IEEE1588
• Enabling and disabling of the reception of SSMs that carry a QL, on the one or two
external NTR clock sources that have been configured as nominated for network
synchronization purposes by the operator.
The default setting is “DISABLE”. For IEEE1588 interface, this setting cannot be
changed (that is the QL is to be configured statically by the operator). For the
BITS/SSU interface, the setting can be changed for 480G and 1.28T NT family
boards but not on 100G/320G NTs.

NT
• The QL value applied for an external NTR clock source, in the algorithm that
performs the selection of one external NTR clock source from up to two
configured as nominated, and in case reception of SSM for that NTR clock source
is disabled.
The default setting for the value is equal to “QL-PRC” (code 0010b) for ETSI, and
“QL-STU” (code point 0000b) for ANSI.
• The target QL value that is applied as minimum threshold for eligibility of an
external NTR clock source, in the algorithm that performs the selection of one
external NTR clock source from up to two configured as nominated, and in case
reception of SSM for that NTR clock source is enabled.
The default setting for the value is equal to “QL- DNU” (code 1111b).
• The static relative priority to be applied for an external NTR clock source, in the
algorithm that performs the selection of one external NTR clock source from up to
two configured as nominated, in case the respective Quality Levels (QL) of the
two sources are identical. The QL for each of both NTR clock sources can be
either communicated via the Synchronization status Messages, or is fixed to a
default value.
• Revertive or non-revertive operation of the external NTR clock signal selection.
The default setting is “Revertive mode”
• Override of synchronization to any external NTR clock source, and forcing of
free-running or hold-over mode for the internal NTR clock function.
• The target QL to be applied as minimum threshold for the internal system NTR
clock, for generating an SSU / BITS out signal.
The default setting for this target QL value is equal to “QL- DNU” (code 1111b).
The system performs the following autonomous NTR clock management functions:
• Monitoring of the signal status (signal present, frequency within the capture
range) and the QL of up to two external NTR clock sources that are configured by
the operator as nominated.
• Selection of the external NTR clock source that fits best the selection criteria, from
up to two sources configured as nominated. Selection happens as specified
further.
• Disabling of the SSU / BITS output signal(s) in case the QL, which can be
attributed to the internal system NTR clock, drops below the configured threshold.
The operator can retrieve the following information:

• The status of BITS / SSU, Synchronous Ethernet and/ or IEEE1588 interfaces
nominated as external NTR source(s): “not available”, “available but not used”,
“used”.
• The number of switch-over actions between nominated external NTR clock
sources. In revertive mode, switch-over between nominated external NTR clock
sources may happen without further alarm generation.

NT
The operator can receive the following alarms:

• Unavailability of any nominated external NTR clock source for reasons that
include:
• Frequency out of range
• Loss of Signal
• AIS signal on BITS interface
• Time-out for SSM reception, if enabled
• Received SSM-QL below the target QL, default or configured
• Not locked on PTP packet stream (IEEE1588)
• Unavailability of all nominated external NTR clock sources for the reasons
mentioned above, with defaulting to hold-over mode for the internal NTR clock.
• BITS output signal disabled:
• Internal system NTR clock QL drops below the output threshold QL, default or
configured.
In the default NTR switching mode (revertive mode), the ISAM selects the most
appropriate NTR clock source for synchronizing its output NTR signals, and for
protecting against failure of external NTR clock sources, as follows:
• In case two external NTR clock sources have been configured by the operator as
nominated, and both are active, then selection of the external NTR clock source,
to which the internal system NTR clock will synchronize, is subject to the following
rules:
• The external NTR clock with highest Quality Level (QL), is selected as actual
reference for the internal NTR clock. The QL of an external NTR clock source is
communicated by means of SSM messages received on the interface related to the
source. If SSM reception is not supported, or disabled on that interface, then a QL
value configured by the operator, or a default QL value is applied, as described
above.
• In case both external NTR clock sources exhibit the same QL, then their relative
priority is determined by the external NTR clock source priority list as configured by
the operator.
• After restoration or upgrading of an external NTR clock source, the selection
depends on revertive or non-revertive mode setting, as configured by the
operator.
• In case only one external NTR clock source has been configured by the operator
as nominated, or in case only one is active, then the internal system NTR clock
will switch to hold-over mode when this external NTR clock source fails, or is
removed.
In hold-over mode, the internal system NTR clock maintains application of the last
stored correction values which describe the deviation of the own free-running
oscillator signal relative to the external NTR clock source signal which was
applied last.

NT
7.2.8 NTR management
7.2.8.1 Configuration: external NTR clock source priority

list
This command allows the operator to configure two NTR clock sources, with an
operator assigned priority between them, as nominated references for the internal
system NTR clock. Each of these two sources can be independently designated to
be:
• The BITS interface on the faceplate of an NT board.
• The 1GE /10GE /100GE interface on the faceplate of an NT board.
• One of the two dedicated 1GE interfaces on the faceplate of a 1 GE NTIO board.
• 10GE interfaces on the faceplate of a NTIO board.
• The IEEE1588 interface receiving PTP messages from Master(s) over any
external interface.
The system factory default is “none”: no external clocks are selected. In this case the
system automatically selects the internal free-run system NTR clock for downstream
NTR timing.
7.2.8.2 Configuration: SSU/BITS input interface(s)

This command allows the operator to configure the BITS mode of the external clock
source to E1, DS1, 2048KHz or auto-select. The BITS mode applies to the system,
that is, any configured BITS clock source.
The system factory default is “auto-select”. In this case, the system automatically
selects E1 for the system with the NT capabilities for clock device type of E1, or DS1
for clock device type of T1. This setting can be viewed in the clock status command.
When the BITS mode is configured to “auto-select”, the actual BITS mode will display
“E1” or “DS1” depending on the NT capabilities.
However, the system does not restrict the manual configuration of “DS1” or “E1” to a
specific NT capability of the clock device type.
7.2.8.3 Configuration: AIS sensitivity

Default is "Disable" and this gives the same ISAM behavior as before R5.0 when this
configuration was not available. In that case, if AIS is sent on the BITS interface,
ISAM continues to see this as a valid NTR signal.
If AIS sensitivity is configured "Enable", AIS on a BITS input signal will be detected
as an NTR clock failure.

NT
7.2.8.4 Configuration: Synchronous Ethernet input

interface(s)
This command allows the operator to configure the Ethernet interface(s) which can
provide their extracted data clock as external NTR clock source. As mentioned
above, 1 or 2 external NTR sources can be configured as clocks for synchronizing
the internal system NTR clock too. Therefore, between 0 and 2 synchronous
Ethernet links can be designated as external NTR clock sources.
The selected Ethernet interface(s) is (are) identified by means of:
• The board slot: NT-A, NT-B, NTIO slot, or none
• The port type: SFP, XFP or none
• The port number on the board: depends on SyncE port supported, or none
The system factory default is “none”.
7.2.8.5 Configuration: IEEE1588

The following needs to be configured for IEEE1588:
• The IEEE1588 interface as well as the external interface on which PTP messages
will be received have to be attached to a L2 forwarder.
• Host IP address of the IEEE1588 slave and gateway IP address + mask
• Host IP address and priority of acceptable Master(s) from which PTP messages
will be received and used as external NTR clock source.
• IEEE1588 protocol specific parameters (PTP Domain and mode)
• For more details, follow IEEE1588v2 management on ToD synchronization
management.
7.2.8.6 Configuration: NTR Switching Mode

This command allows the operator to configure the external NTR selection mode to
be either:
• Revertive:
the system NTR clock always selects as reference the external NTR clock source
with highest QL, or the one configured as preferred by the operator if the QLs of
both nominated external NTR clock sources are equal, whenever this clock
source is available.
• Non-revertive:
the system NTR clock keeps the currently selected external NTR clock source as
a reference, until it is no longer available for selection, for reasons listed above,
or until it is disabled by the operator. This is the case even if another external NTR

NT
clock source, with better QL or higher preference as configured by the operator,

has become available since the selection of the currently selected external NTR
clock source.
The system factory default is “revertive”
7.2.8.7 Configuration: enabling of Synchronization Status

Messaging (SSM)
Synchronization Status Messages (SSM) are required to allow the downstream
element that requires synchronization to know the quality of the upstream clock.
Typically, it allows a downstream element which has the choice between different
upstream clocks to select the one with the best quality, or the one which meets the
minimum required quality. Even when there is only one upstream clock available,
such as, for example, in the case of a mobile base station connected to a DSL line,
SSM has value. If SSM indicates that the quality of the upstream clock degrades
below the quality of the local clock of the base station, the latter can switch to the
local clock for synchronization. More information about SSM can be found in G.781
with extensions for Synchronous Ethernet in G.8264.
Several commands exist to enable or disable the support of the Synchronization
Status Message (SSM):
• enable or disable the handling of received SSM messages on ports configured as
NTR clock source(s).
• enable or disable transmitting SSM messages per port, and this for the following
cases:
• Synchronous Ethernet output ports on NT cards, NTIO cards and Ethernet LT boards
• VDSL2 ports and SHDSL ports on some LT cards (only SSM transmission and not
SSM reception). And then it is only supported in EFM mode and not ATM mode.
• SyncE with SSM on GPON or XGS-PON ONT output ports. SSM output on
TWDM-PON interface is not supported.
The system factory default is “disable”.

SSM is not supported for IEEE1588-A (on NT-A) and IEEE1588 (on NT-B). SSM is
supported for BITS-A (on NT-A), BITS-B (on NT-B) on the 480G and 1.28T NT family
(FX) but not on 100G/320G NTs.

NT
7.2.8.8 Configuration: forcing selection of the internal

system NTR clock
This command allows the operator to force the transmitted downstream NTR clock
to be synchronous to the internal system NTR clock, without synchronization to any
external NTR clock source. The internal NTR clock can be in free-running, or in
hold-over mode, when it was synchronized previously to an external NTR clock
source.
7.2.8.9 Status: nominated NTR clock status

This command allows the operator to query the status of the NTR clock source(s).
The following command results are listed:
• the NTR clock source: BITS-A (on NT-A), BITS-B (on NT-B), Sync Eth 1 (from NT
or NTIO), Sync Eth 2 (from NT or NTIO), IEEE1588-A (on NT-A), IEEE1588-B (on
NT-B), local.
• the Quality Level (QL) of the source: code points 0000b - 1111b (0 … 15)
• the operator configured priority of the source: 1 … 3
• only priority1 or 2 can be configured, priority 3 is always the internal clock
• The operational status of the source:
• REFERENCE: the clock source is selected as the reference clock.
• VALID: the clock source is available for selection.
• FAILED: the clock source failed or is not available for selection.
• DO_NOT_USE: the clock must not be used as indicated by SSM (or time-out).
• UNKNOWN: the clock status is unknown (start-up, system fault).
• FORCED: the clock is manually selected.
• NO_SYNCE_CONFIG: the synchronization source is not bound to a physical port.
• NO_SYNCE_SUPPORT: the syncE is bound to a port that does not support syncE
clock extraction.
• ON_PEERNT_NOT_READY: the clock is configured on the faceplate of a peer NT
that is not ready to participate in clock management.
• SYNCE_NOT_AVAILABLE: the syncE is not available because the required
equipment is not available.
• MISSING: No SSM packets received for 5 seconds
• INVALID: Incoming signal is valid on the hardware level, but the source is rejected
for quality reasons (below target QL).
7.3 Downstream NTR clock distribution

In the introduction of this chapter the drivers for NTR where explained, and include
distribution of NTR to other network nodes, as well as distribution of NTR over
access lines to the end-user or business user.

NT
Figure 34 NTR distribution over access lines for different services

Mobile backhauling
ISAM Accurate synchronization
of base stations
Network Timing Reference
High-stability
clock on NT Leased lines
Network Timing Reference
Cost-effective central
BITS interface clock for synchronization
on NT of all CPEs
NTR support
Voice
on LTs
High-stability clock for
long-lasting fax and
modem calls
The typical options provided for delivering NTR to other network nodes are:
• BITS out on some NT boards
• SyncE out on some Ethernet interfaces on some NT, NTIO and Ethernet LT
boards.
This can be supported on optical Ethernet interfaces only, and not on electrical
ones. Secondly, it can be supported at speeds of 1 Gbps and 10 Gbps, but not at,
for example, 2.5 Gbps and 100 Mbps.
In the normal default case, the BITS out on the NT board is filtered by the SETG
function (see Annex 7 in G.8262/G8264) in order to achieve compliance to G.813
option 1 for BITS out. But alternative configurations of the ISAM clock system are
possible as suggested in Annex7 in G.8262/G8264, allowing that the SyncE input(s)
are passed through unfiltered to the BITS output. Typically the unfiltered BITS output
will then be connected to an SSU device.
The typical options provided for delivering NTR to access lines or end-users are:
• NTR on VDSL2
• NTR on ADSL/ADSL2/ADSL2plus is not supported
• NTR on SHDSL
• SyncE out with SSM on some Ethernet interfaces on some NT, NTIO and
Ethernet LT boards.
This can be supported on optical Ethernet interfaces only, and not on electrical
ones. Secondly, it can be supported at speeds of 1 Gbps and 10 Gbps, but not at,
for example, 2.5 Gbps and 100 Mbps.
• NTR on GPON or XGS-PON.
SyncE with SSM out from GPON or XGS-PON ONT (For supported ONT, please
check the ONT datasheet)
• NTR on TWDM-PON

NT
To know which specific NT, NTIO, or LT boards do support the above NTR
distribution on their outgoing interfaces, refer to the Product Information document
and/or the UDS. A high-level view of the capabilities of the 24G, 100Gbps, 320G,
480G and 1,28T NT family and the FX NT family is represented in Figure 29 and
Figure 30 respectively.
7.4 Time phase and ToD support

This chapter gives an overview of the Time phase and ToD support on ISAM.
7.4.1 Overview of Time Phase and ToD support on ISAM

The provision of some types of communication services across modern
communication networks requires support for time phase and absolute Time and
Date, or Time of Day (ToD) synchronization activities in Network Elements,
especially on Mobile backhaul.
Synchronization of the time phase and ToD, that is the setting of a wall clock, which
includes alignment of the change of that setting, or the phase, also determines
unambiguously the applied pace for advancing the time. Support for synchronization
of phase and the absolute Time in an NE is limited to:
• Packet communication means using Precision timing Protocol (PTP, e.g.
IEEE1588v2) over the network side interface.
• Satellite communication (GNSS, for example GPS).
• Frequency, Phase and Time conveyed by a Passive Optical Network at the
network side.
Phase and time synchronization in ISAM is limited to the ISAM 7360 FX product line
only.
IEEE1588v2 is supported from Network side via PON OLT and from subscriber side
via the PON ONU (see Section 11.1):
• Using 1588v2 PTP following ITU-T G.8275.1 profile with SyncE/BITs as Layer 1
companion for full path timing support.
• Using G.984.3 Amd 2 ToD over GPON or G.9807.1 ToD over XGS-PON between
OLT and ONT to resolve the high radom jitter due to PON asymmetry
characteristic
1PPS+ToD with a companion L1 network clock (BITS/SyncE) is introduced to

support phase/ToD synchronization.
Besides of PON, phase sync has been introduced on the 10GE Ethernet LT,
operating in downlink mode, also for MBH application.
IEEE1588v2 phase sync with L1 Freq via Boundary Clock (BC) mode for ISAM
cascading, including star, daisy chain and ring topology is not supported yet.

NT
Figure 35 ToD topology for 480G/1.28T NT ISAM family (FX)
ONU
ONU Cell
GPON
Cell
1588v2 1588v2PTP
Master
Cell
ToD over GPON ONU

via G.984.3 Amd2 Cell
Packet
network Freq over GPON
Primary Clock via GPON PMD Splitter SFU Triple-play-
reference ISAM FX served home
backplane FTTBusiness
FANT-F FGLT
BITS GPON
1pps + TOD Time pulse B-ONT
SyncE 8 kHz
1588v2
1588v2 PTP slave 7360 ISAM FX
27576
7.4.2 ISAM clock system and time phase/ToD extraction

External port selection for phase/ToD is the same as with NTR.
Possible External ToD sources:
7.4.2.1 One or more PTP clock sources per NT

IEEE1588v2 PTP system is a distributed, networked system consisting of a
combination of PTP enabled and non-PTP enabled Network Elements (NE) or
devices. PTP devices include ordinary clocks, boundary clocks, end-to-end
transparent clocks, peer-to-peer transparent clocks, and management nodes.
Non-PTP devices include bridges, routers, and other infrastructure devices, and
possibly devices such as computers, printers, and other application devices.

NT
The IEEE1588v2 protocol is a distributed protocol that specifies how the real-time
clocks in the system synchronize with each other. These clocks are organized into a
master slave synchronization hierarchy with the clock at the top of the hierarchy the
grandmaster clock determining the reference time for the entire system. The
synchronization is achieved by exchanging PTP timing messages, with the slaves
using the timing information to adjust their clocks to the time of their master in the
hierarchy.
The IEEE 1588v2 protocol provides a means to synchronize the frequency (NTR),
time phase (1PPS) and absolute time (ToD) setting of the system clock of the NE
across an asynchronous packet network, to an IEEE1588v2 GrandMaster (GM) or
Boundary Clock (BC) deeper in the upstream network and to a subtending BC or
SOOC (Slave Only Ordinary Clock) in the downstream network, using an in-band
packet data stream.
In 7360 ISAM FX PON access system, both OLT and ONU work together as a
distributed BC, OLT acts as SOOC to terminate the PTP stream while ONU side acts
as MOOC (Master Only Ordinary Clock) to initiate a new PTP stream.
On the NT, acting as a PTP slave, the system supports 1PPS and ToD extraction
based on IEEE1588 input PTP packets, coming from the GM or BC deeper in the
network, computes the absolute time and generates a system clock from it.
Then this time information is distributed to the PON LT(s) through the backplane and
can be transported over a PON link towards ToD-capable ONU(s), following G.988
and G.984.3 Amd2. A master port can be created on the ONU UNI to deliver PTP
packets to subtending slaving elements.
IEEE 1588v2 has the advantage that timing information can be conveyed in-band
through an asynchronous packet network to any NE or CPE connected to that
network. It has the disadvantage that the accuracy of the Time and Frequency
derived from the packet stream depends very much on the Packet Delay Variation
(PDV), that is, on the traffic load, and on possible structural or long term packet delay
asymmetries in the packet network.
For this reason, state-of-the-art equipment for regeneration of a local Time and
frequency clock from the IEEE 1588v2 Sync packet stream (Receiver part of an OC
or BC) can support two modes:
• Pure packet mode: the receiver Time and Frequency clock regeneration only uses
the PTP Synchronization event packets to interact with the GM/Master.
• Hybrid mode: the receiver Time and Frequency clock regeneration uses both the
OSI layer 2/3 PTP Synchronization event packets to interact with the GM/Master,
and an OSI Layer 1 based network reference clock received via different means
(BITS / SSU, Synchronous Ethernet).
Each NT can support up to three external PTP sources as inputs over LAG and lock
with the best of three based on BMCA. One will be a reference, the other works as a
backup. The selection depends on ClockClass and Priority.

NT
7.4.2.2 One 1PPS+ToD source per NT

Time synchronization of ToD clocks of an NE can also be obtained as a byproduct of
a Global Navigation Satellite System(GNSS), such as GPS, GLONASS, GALILEO,
BEIDOU, IRNSS and so on.
A GNSS receiver is connected to the system SEC / EEC clock of the NE. The timing
information contained in the GNSS signal is used to synchronize the System clock of
the NE. It is typically provided as a combination of:
• A 1 Pulse Per Second (1 PPS): the leading edge of the pulse marks the roll-over
to the next second
• An absolute Time and Date information frame: it provides the exact time, down to
the second level, valid at the next 1 PPS edge. This information is typically coded
in a serial asynchronous format, such as NMEA0183 format or CCSA ToD format.
• A companion L1 network clock (BITS/SyncE)
The 1 PPS and absolute Time and Date, or Time of Day (ToD) signals are
instrumental for synchronizing the system ToD clock in the NE.
L1 network clock(BITS/SyncE) can be derived from the GNSS receiver or from
network NTR system. It is used to provide frequency synchronization and stability.
Each NT can support one 1PPS+ToD source as input. One will be a reference, the
other works as a backup. The selection depends on ClockClass and Priority.
1pps+ToD per NT can be configured as outputs.
The supported ToD format includes NMEA0183 GPRMC and CCSA defined format.
7.4.3 Clock protection

Clock protection is important for services with no time discontinuity or less
degradation. It is similar to NTR clock protection in the following ways:
• Switching to another redundant external ToD source:
• Another redundant external ToD source on the same simple NT on a simple NT setup
• Another redundant external ToD source on the redundant NT on duplex NTs setup.
• An internal ToD wall clock hold-over function with or without existing L1 frequency
that, when the system locks an external ToD source and no external ToD source
is available, continues to apply the last known clock correction data to the internal
ToD wall clock, in order to keep the clock to the dependent equipment as stable
as possible during absence of external references.
• Without L1 frequency, the ToD hold-over will enter ‘out of holdover’ specification
state immediately and cannot be adopted by the for downstream clock node
anymore.
• With L1 frequency existing, the ToD hold-over will enter ‘within holdover’ specification
state with a timer. Once the timer has expired, it will reach ‘out of holdover’
specification state.

NT
• An internal ToD wall clock free-running mode in case no valid external ToD source
is connected during system start-up, that is, it will adapt to the output
frequency/phase of its local oscillator.
• When an NT switches over:
• In case the ToD wall clock is used as reference on the active NT, switch to the backup
reference on the standby NT and revert when the switch-over has been done.
• In case the ToD wall clock reference on the standby NT is used, there is no impact.
• At a type-B switch-over, the system will trigger a new ToD message to the ONU
for resynchronization.
7.4.4 ToD synchronization management

The operator can configure the following elements regarding ToD:
7.4.4.1 The external ToD source to be used:

• IEEE1588v2
An IEEE1588v2 source is used for frequency as well as for ToD synchronization.
• IEEE1588v2 with L1 network clock (BITs/SyncE)
An IEEE1588v2 source is used for ToD synchronization.
The L1 network clock (BITs or SyncE) is used for frequency synchronization
Note — For hybrid mode, the IEEE1588v2 and L1 network
clock must be located in the same NT.
• 1PPS+ToD with L1 network clock (BITs/SyncE)

1PPS+ToD source is used for ToD synchronization
L1 network clock (BITs or SyncE) is used for frequency synchronization.
Note — For hybrid mode, the 1PPS+ToD and L1 network clock
must be located in the same NT.
7.4.4.2 SyncE/BITS as backup of ToD source

After an external ToD source is introduced, the ISAM host system shall still support
the second nominated frequency source as frequency backup.
When the ToD related primary source is not available, a second nominated
frequency source will take over for frequency synchronization, ToD will enter
hold-over mode.

NT
7.4.4.3 Clock DataSet

An appropriate clock Data Set definition is used to configure for a nominated external
network Time and Phase reference source, typically for synchronization via the IEEE
1588v2 PTP protocol, but also for GNSS external sources.
The system supports the dynamic extraction of these parameters from the PTP
packets coming from the GrandMaster or Master(s).
For a downstream clock node, it needs the parent PTP dataset information for quality
traceability and BMCA (Best Master Clock Algorithm). Currently, the operator can
statically define them using Clock DataSet. This can also be useful in case sources
do not support these parameters (like GNSS). The operator can also dynamically
extract Clock DataSet parameters from the PTP packets and transfer them to the
downstream clock node.

NT
7.4.4.4 IEEE1588v2 management

• IEEE1588v2 PTP profiles
The 1588v2 standard includes the concept of a PTP profile. The purpose of a PTP
profile is to allow organizations to specify specific selections of attribute values
and optional features of PTP that, when using the same transport protocol,
inter-work and achieve a performance that meets the requirements of a particular
application.
In the telecommunications industry, the ITU-T is the body that develops these
profiles. They have generated a profile for frequency distribution (G.8265.1) and
a profile for time distribution (G.8275.1).
The 7360 ISAM FX system supports several different IEEE1588v2 PTP profiles
for easy management.
• ITU-T Telecom profile for time with full timing support (G.8275.1).
It defines accurate frequency and phase synchronization from an Ethernet Interface
over L2 MC IEEE1588v2 Packets (T-BC) with an L1 companion frequency
(Equipment Clock is either EEC or SEC) that eliminates the need for GPS that are
Full On-Path Support.
See Table 16.
• ITU-T Telecom profile for frequency (G.8265.1).
It defines Frequency Synchronization from Ethernet Interface via L3 UC IEEE1588v2
PTP packets(PEC-S) eliminates the need for GPS which are Partial On-Path Support
with transparent forwarding in intermediate nodes.
See Table 17.
• CCSA profile for phase synchronization.
CCSA defines accurate frequency and phase synchronization from Ethernet
Interface over L2 MC IEEE1588v2 Packets (T-BC).
See Table 18.
• Customized profile for phase or frequency synchronization.
The system supports customer defined profile for frequency and phase sync to meet
some particular applications. Due to Timing synchronization that has strict
performance requirements, it is recommended to follow ITU-T profiles that will be
helpful for the IOP and performance assurance such as T-GM, T-BC from various
vendors.
See Table 19.
• PTP packet encapsulation mode
The PTP slave device on the NT supports UDP encapsulation over IP Packet or
over Ethernet directly, the encapsulation modes including:.
• IP Unicast mode
• Ethernet Multicast mode
For IP encapsulation mode, the PTP device on the NT uses one pre-configured
acceptable master table including a priority list with the Source Addresses of
acceptable master clocks in the network to decide which master to slave on.
For Ethernet encapsulation mode, BMCA will be used to select which master to
slave on.
The PTP master device on the 10GE Ethernet LT and ONU supports Ethernet
Multicast mode only.

NT
• E2E mode
The PTP slave port on the NT and master port on the ONU uses by default the
end-to-end (e2e) delay mechanism to compute the mean path delay between the
client and the PTP master in the network
The system currently does not support the peer-to-peer (p2p) delay mechanism.
• One step/Two Steps
The system supports the PTP slave/master clock that provides the time
information using a single event message (one-step) or using the combination of
an event message and a subsequent general message (two-steps).
• Configurable Packet Rate
The Delay Req messages are sent by the PTP slave device on the NT to the
Master. The permitted mean time interval between successive messages is
configurable between 1/16 per second to 128 per second, This parameter is
applicable when the PTP device is configured to use the e2e delay mechanism.
The Announce and Sync messages are sent by the PTP master device on the
ONU. The interval indicates the mean time interval between successive
messages. The permitted mean time interval between successive announce
messages is configurable between 1/16 per second to 16 per second. The
permitted mean time interval between successive Sync messages is configurable
between 1/16 per second to 256 per second.
• Leap second
A leap second is a second which is added to UTC in order to synchronize atomic
clocks with astronomical time to within 0.9 seconds. The reason we have to add
a second every now and then, is that Earth's rotation around its own axis, is
gradually slowing down whereas Atomic clocks are programmed to tick away at
pretty much the same speed over millions of years.
The 7360 ISAM FX supports configurable leap second adjustment and dynamic
leap second adjustment. For configurable mode, before leap second adjustment,
the operator shall set the correct leap second in the system.
• Phase compensation.
Due to PTP asymetric path, different Ethernet speed, 1pps+ToD link length, extra
phase deviation is likely to be introduced.
7360 ISAM FX supports time delay compensation per NT level and per link level
for 1,2T NT and 10GE Ethernet LT
• PTP monitoring.
In order to assist an operator to troubleshoot network timing sync, ISAM supports
PTP packet statistics, external master information retrieval and ISAM clock status
show on the various interfaces.
Table 16 G.8275.1 profile
Frequency Phase Performance
BITS / SyncE L2 MC PTP Follow G.8273.2 performance (Class A)

NT
Table 17 G.8265.1 profile
L3 UC PTP NA Follow G.8263/G.823 SSU performance
Table 18 CCSA profile
BITS / SyncE 1PPS+ ToD
Table 19 Customer profile

L3 UC PTP NA Follow G.8263/G.823 SSU performance
L2 MC PTP L2 MC PTP Max TE less than +/- 200 ns

BITS / SyncE L3 UC PTP Follow G.8273.2 performance (Class A)
BITS / SyncE 1PPS+ ToD Follow G.8273.2 performance (Class A)
7.5 Applicable standards

• Output NTR clock support on ADSL(2)(plus) lines: The NTR section in ITU Rec
G.992.1 / G.992.3 / G.992.5 is not supported. NTR for ADSL is not supported.
• Output NTR clock support on SHDSL lines: ITU Rec G.991.2
NTR for SHDSL is supported on selected ISAM SHDSL Line Termination board
types.
• Output NTR clock support on VDSL2 lines: ITU Rec G.993.2
NTR for VDSL is supported on selected ISAM VDSL Line Termination board
types.
• Output NTR clock support on POTS lines: Not Applicable
An analogue POTS interface does not provide a clock signal in downstream
direction
• Output NTR clock support on Synchronous Ethernet lines: ITU Rec
G.8261/Y.1361
NTR by means of Synchronous Ethernet is supported on selected ISAM Ethernet
Line Termination board types.

NT
• Output NTR clock quality on ISAM NT:

• Output NTR clock free running accuracy, hold-over frequency accuracy, Jitter and
wander generation, phase variation in case of interruptions on synchronization input
signals:
- ETSI SSU: ITU-T G.813 Option 1 (Note: As explained above, ISAM is not
fully compliant in case of transient behavior.)
- ETSI Synchronous Ethernet: ITU-T G.8262 Option 1
• Output NTR clock jitter and wander transfer
- ETSI SSU: ITU-T G.813 Option 1
• Input external NTR clock source quality on ISAM NT
• Input NTR signal clock pull-in & pull-out ranges:
- ETSI SSU: ITU-T G.813 Option 1
• Input NTR signal jitter and wander tolerance:
- ETSI SSU: ITU-T G. 813 Option 1, G.823
- ETSI/ANSI PTP: ITU-T G.8261 (note: PDVs indirectly specified by means of
network topologies and traffic models)
• NTR management, including SSM: ITU-T G.781 781 Option 1 to a large extent
• SSM transport
• BITS / SSU: ITU-T G.704 (1998)
ISAM does not support SSM reception or generation on BITS / SSU interfaces.
• Synchronous Ethernet: IEEE 802.3 Organization Specific Slow Protocol (OSSP)
Annex 43B (2005), ITU-T G.8264
• External ToD signal clock input
• Standard for a Precision Clock Synchronization Protocol for Networked
Measurement and Control Systems IEEE 1588-2008
• E2E Timing characteristics for Phase performance: G.8273.2 ClassA

NT

System Description for FD 100/320Gbps NT and FX ADSL/VDSL features
NT
8 ADSL/VDSL features
8.1 Overview
8.2 Configurable impulse noise protection
8.3 RFI Notching
8.4 Low-power modes
8.5 Seamless rate adaptation
8.6 Upstream power back-off
8.7 Downstream power back-off
8.8 Impulse noise monitor
8.9 Virtual noise
8.10 Physical Layer Retransmission (G.INP)
8.11 Per-line configuration overrule
8.12 Configurable US/ DS memory split
8.13 Vectoring
8.14 Fall-back configuration for vectoring
8.15 Save Our Showtime (SOS)
8.16 VDSL2 35b
8.17 VDSL2-LR
8.1 Overview
Table 20 lists the different features described in this chapter, indicating for which
xDSL mode the feature is supported on xDSL LT boards and ONUs.

ADSL/VDSL features System Description for FD 100/320Gbps NT and FX
NT
Table 20 Supported xDSL features
Feature xDSL LT xDSL

ONU
ADSL ADSL2 ADSL2 READSL2 VDSL2 VDSL2

plus
Configurable impulse noise protection X X X X X X
RFI Notching X X X
Low-power modes X X X X X
L2 low-power mode X X X
L3 idle mode X X X X X
Seamless rate adaptation X X X X
Upstream power back-off X X
UPBO policing X
Equal RXPSD UPBO X X
Equal FEXT UPBO X
Downstream power back-off X X X
Impulse noise monitor X

Virtual noise X X
Physical Layer Retransmission (G.INP) X X X X X
Per-line configuration overrule X X X X X
Configurable US/ DS memory split X
Vectoring X
Fall-back configuration for vectoring X
Save Our Showtime (SOS) X
VDSL2 35b X
VDSL2-LR X
Table 21 gives an overview of the supported VDSL2 profiles. Each profile defines
normative values for a set of parameters, as defined by G.993.2.
Table 21 Supported VDSL2 profiles
VDSL2 Profile xDSL LT xDSL ONU
8a, 8b, 8c, 8d X
12a, 12b X
17a X X
30a X
(1 of 2)

NT
VDSL2 Profile xDSL LT xDSL ONU

35b X
(2 of 2)
Table 22 gives an overview of the supported VDSL2 bandplans. A bandplan is a

partitioning of the frequency spectrum into non-overlapping frequency bands, each
of which is allocated for either upstream or downstream transmission.
Table 22 Supported VDSL2 bandplans
VDSL2 Bandplan xDSL LT xDSL ONU
Region A(1) 998 X X
Region B(2) 998 X
Region B 998E X X
Region B 998ADE X X
Region B 997 X
Region B 997E X
Region B 998E35 X
Region B 998ADE35 X
Notes
(1) Region A = North America
(2) Region B = Europe
8.2 Configurable impulse noise protection

Standards specify that a DSL link must comply with a Bit Error Ratio (BER) < 10-7, in
the presence of a Signal-to-Noise Ratio (SNR) margin of 6 dB. For some types of
service (for example IPTV, when using codecs with insufficient error concealing),
subscriber comfort requires even higher line quality, that is, BER < 10-10 or better.
DSL modems can be trained at initialization to achieve these quality levels in the
presence of stationary background noise.
Impulse Noise Protection (INP) is the ability to protect the transmission against
impulse noises. These impulse noises differ from the stationary noise in the sense
that they are transitory noises and that their power levels are high enough to be able
to cause data errors on the xDSL lines. INP is important in the IPTV network. With
the general evolution from pure High-Speed Internet (HSI) to triple play service
offering, there is an increasing need for techniques that help to improve and assure
the stability of the DSL line.
Configuring INP provides the ability to configure the upstream and downstream
minimum INP parameters in the service profile.

NT
The standards include several provisions to reduce the number of errors that occur
due to impulse noise. The primary one is interleaving combined with Forward Error
Correction (FEC) using Reed-Solomon (RS) error correcting codes.
8.2.1 Reed-Solomon
Reed-Solomon (RS) adds extra bytes to a group of data bytes when it is sent. These
bytes are also known as the “RS word”. When data corruption is detected at
reception, the RS decoder is able to use the extra bytes to locate the errors and to
recover the original message. However, this only is effective up to a certain
maximum number of errored bytes. In order to correct impulse noise errors, RS
needs to be combined with interleaving.
8.2.2 Interleaving
Instead of transmitting the RS words directly on the line, the different RS words are
first mixed and spread over time. This process is called “interleaving”. This has the
advantage that when a burst of errors occurs on the line, it will hit bytes of different
RS words. After reconstruction of the original RS words (by the de-interleaver), the
errors will be spread over multiple RS words, such that each RS word is only affected
by a small amount of errors and is therefore much easier to correct. The RS word can
be corrected if its number of errors is within the RS correction boundaries.
The main disadvantage of interleaving is an extra “interleaving delay”. Constructing
the blocks that will finally be transmitted over the line takes time, as the modems
have to wait for a while before they can actually start transmitting. At the receiving
side, it also costs extra time to reconstruct the original RS word. The first original RS
word cannot be reconstructed before all of its bytes have been received.
Using smaller interleaving depths, that is, by taking bigger chunks of the original RS
words, can lead to a lower interleaving delay. This has the disadvantage that errors
will be spread over less RS words on the receiving side, with the possibility that they
cannot be corrected.
In the case that a high INP together with a low delay is required, extra RS bytes will
have to be added to increase the RS correction capability. This however can lead to
reduced bit rates.
It becomes clear from the above that when configuring the INP, a trade-off has to be
made between:
• robustness of the line against impulse noise
• interleaving delay
• achievable bit rate

NT
8.3 RFI Notching

Radio Frequency Interference (RFI) notching is used to alleviate signal interference
in certain frequency bands. VDSL2 and ADSL2Plus provide the capability to reduce
the Power Spectral Density (PSD) within certain frequency bands and thus notch the
PSD in areas to reduce egress into certain services such as HAM radio. HAM radio
is an Amateur Radio service enjoyed by radio enthusiasts. Shortwave radio can
broadcast over long distances aided by relay signals.
8.4 Low-power modes

.
8.4.1 L2 low-power mode

First-generation ADSL transceivers operate in full-power mode day and night, even
when not in use. With several millions of deployed ADSL modems, a significant
amount of electricity can be saved if the modems engage in a stand-by mode or
sleep mode just like computers. This would also save power for ADSL transceivers
operating in small remote units and Digital Loop Carrier (DLC) cabinets that operate
under very strict heat dissipation requirements.
To address these concerns, the ADSL2/ADSL2plus standards define L2 low-power
mode in addition to the full power mode (called “L0” power mode). This power
management mode helps reduce the overall power consumption while maintaining
the ADSL “always-on” functionality for the subscriber.
This mode enables statistical powers savings at the ADSL transceiver unit in the
central office (ATU-C) by rapidly entering and exiting low power mode based on the
downstream subscriber traffic running over the ADSL connection.
By enabling the L2 low-power mode, the average power consumption and
dissipation of a line is reduced because the modem reduces dynamically the
downstream transmit Power Spectral Density (PSD) in case there is no subscriber
data to transmit in the downstream direction. A low-rate connection is however
always assured for minimum keep-alive data. The DSL line automatically returns to
the full PSD/full data rate if subscriber data arrives, without loss of data.
In the L2 mode, only the downstream data rate is lowered. The data rate of the
upstream remains unchanged. This because in ADSLx the downstream transmitter
constitutes a much larger consumer of power than the upstream transmitter.
The L2 entry and exit mechanisms and resulting data rate adaptations are
accomplished without any service interruption or even a single bit error, and as such,
are not noticed by the subscriber.
However, L2 low-power modes will lead to time varying crosstalk which might impact
the stability of customers sharing the same binder.

NT
Exit out of L2 mode into L0 mode can also be triggered from the CPE end, in case of
significantly changed channel conditions.
With the support of the enhanced L2 defined in ITU-T G.992.3 (2009) Amendment 4,
it is now possible to use:
• Extended range of Lp values in the L2 low power mode:
This allows to support higher bit rates in low power mode, thus limiting the delay
incurred by delay-sensitive services, or to support higher bit rate services while
maintaining high levels of power saving.
• Extended range for the Gi gain scaling in L2 low power mode:
This provides finer control of power reduction via Gi scaling, leading to better
power savings than previously possible with flat power reduction only.
8.4.2 L3 idle mode

This mode enables overall power savings at both the XTU-C and the remote xDSL
transceiver unit (XTU-R) by entering into sleep/stand-by mode when the connection
is not being used for extended periods of time (that is, subscriber asleep, modem
asleep).
The L3 power mode is a total sleep mode where no traffic can be communicated over
the xDSL connection. When the subscriber goes back on-line, the line has to be
re-initialized to enter the L0 state again.
The modem can enter the L3 state upon guided power removal (L3 Request
exchange between xTU-R and xTU-C, also known as orderly shutdown), power loss
or persistent link failures during Showtime (also known as disorderly shutdown).
During the L3 state, power savings at the XTU-C are realized independent of the
used ADSLx or VDSL2 mode by putting certain Analog Front End (AFE) blocks and
line drivers in power down mode. This power saving mechanism is also available in
case no xTU-R is attached but the ports are in “listening mode” and configured in
admin-up.
Figure 36 illustrates the L2/L3 power modes.
Figure 36 L2/L3 power modes
Initialization Low traffic causes switch to L2
Showtime
Resynchronisation or (L0) High traffic causes
L3 Power mode switchback to L0
Resynchronisation or “Low Power”

“Low Power”
IDLE (L3) L3 Power mode
Showtime (L2)
Showtime (L2)

NT
8.5 Seamless rate adaptation

ITU-T G.997.1 defines 3 types of Rate Adaptation (RA) modes:
• RA Mode 1 (Operator Controlled):
Bit rate is configured by operator, no rate adaptation
• RA Mode 2 (Rate adaptive at startup):
At startup, the bit rate is selected between a configured minimum and a
configured maximum. The actual bit rate remains fixed while the modem is in
showtime.
• RA Mode 3 (Dynamic rate adaptive):
The bit rate dynamically changes between a configured minimum and a
configured maximum, even while the modem is in showtime.
The dynamic rate adaptive mode is also called “Seamless Rate Adaptation” (SRA).
This feature is supported in all ADSL2x (ADSL2, ADSL2plus, READSL2) modes of
operation and in VDSL2 mode of operation.
SRA improves the stability of the line (that is, reduces the number of spontaneous
retrains) by dynamically reducing the bit rate, without loss of data and without bit
errors, in case of a slow decrease of the SNR to an SNR below a preset value. SRA
can also assure that at any moment in time the line operates at the maximum
achievable bit rate by dynamically increasing the bit rate, without loss of data and
without bit errors, in case the SNR increases above a preset value.
SRA enables the modem to change the data rate of the connection while in operation
without any service interruption. The modem detects changes in the channel
conditions (for example, increase in noise level) and adapts the data rate to the new
channel condition without a need to resynchronize the line.
The upshift and downshift noise margin thresholds and time intervals for SRA are
fully configurable.
Figure 37 illustrates SRA.

NT
Figure 37 Seamless Rate Adaptation

Maximum Noise Margin
Increase data rate if Upshift
time interval has elapsed
Upshift Noise Margin Increase
data rate
Target Noise Margin
Downshift Noise Margin Decrease

Decrease data rate if Downshift data rate
time interval has elapsed
Minimum Noise Margin
0 dB Margin
The upshift and downshift rate adaptation events due to SRA are counted in
15-minute and 24-hour Performance Monitoring (PM) intervals.
SRA can encounter upshift and downshift limitations on lines activated with
interleaving:
• ADSL2(+):
The SRA protocol can only change parameter L (number of bits per DMT symbol).
SRA downshifts are limited by the configured maximum interleaving delay as SRA
downshift results in an increase of the delay.
SRA upshifts are limited by the configured minimum impulse noise protection as
SRA upshift results in a decrease of the impulse noise protection.
• VDSL2:
The SRA protocol can change both parameter L (number of bits per DMT symbol)
and parameter D (interleaving depth). This allows to keep the delay and impulse
noise protection constant after a rate adaptation. When all allocated interleaving
memory is used, upshift rate adaptations are still limited by the configured
minimum impulse noise protection.
8.6 Upstream power back-off

Upstream Power Back-off (UPBO) is a remedy to the upstream far-end cross-talk
(FEXT) problem, see Figure 38.

NT
Figure 38 Far end cross-talk

NE
CPE
short loop
FEXT CPE
long loop
weak Rx signal; strong FEXT signal from short loop
It allows to reduce the upstream transmit PSD on short lines in order not to impact
the upstream performance on longer lines unreasonably. Without UPBO, the nearby
CPE would transmit at full power and would inject excessive FEXT in the upstream
receiver of the long line.
8.6.1 UPBO policing

The main purpose of VDSL2 UPBO policing is to avoid the usage of a CPE not
complying with the UPBO configuration. When the CO modem detects such a
non-compliant CPE, an alarm is raised and optionally the line is automatically
shutdown. The expected behavior is configurable.
A line that has been automatically shut down because of policing can be triggered to
re-initialize by toggling its administrative state (down/up).
8.6.2 Equal RXPSD UPBO

This is the form of UPBO first standardized in G.993.2. The goal of this UPBO is to
equalize the upstream received signal PSD. The support of this form of UPBO is
mandatory at both DSLAM and CPE.
8.6.3 Equal FEXT UPBO

The goal of this second form of UPBO is to equalize the level of FEXT VDSL2
self-crosstalk noise. This results in available upstream bitrates that are further
optimized compared to the bitrates obtained with Equal RXPSD UPBO.
This form of UPBO is introduced because the equal RXPSD UPBO does not exactly
equalize the impact of all lines to each other, but gives a different FEXT level impact
proportional to the loop length, i.e. the short lines give a lower FEXT impact to long
lines then vice versa. As a consequence, the equal RXPSD UPBO is actually
implying too much power cutback on the short lines.

NT
The Equal FEXT UPBO can be explained as first applying the equal RXPSD method
but adding a loop-length-dependent delta FEXT factor, thereby equalizing the impact
among the lines. This equalization is executed with respect to a reference FEXT
level, characterized by a reference electrical length (kl0_ref). This parameter is
configurable for each upstream band. Alternatively an automatic configuration mode
is available: if the Equal FEXT parameters for all bands are all set to automatic, the
modem uses a dedicated mechanism to automatically calculate good values for the
Equal FEXT parameters, without manual configuration by the operator.
The equal FEXT UPBO method is standardized in G.993.2 Amendment 2, and is
supported in the ISAM.
8.7 Downstream power back-off

With the introduction of remote cabinets, one can have deployment of DSL lines from
different locations: some from the central office (CO), some from the remote
terminals (RT). In case lines deployed from the CO and lines deployed from the RT
share the same cable binder, a near-far crosstalk problem occurs.
The crosstalk from the near-end disturbers can be much higher than before, such
that the signal from the far-end transmitter is completely degraded. Very often this
results in a loss of the service on the line deployed from the CO.
This near-far effect both occurs in upstream and in downstream direction. In
upstream direction however, the typical services from the CO (ADSL2/2+) only use
lower frequencies, where the coupling is much lower than on higher frequencies.
That is why this problem mainly affects downstream communication (for the CO
lines).
In order to give equal priority both to CO and RT, the RT applies downstream power
reduction (also called Downstream Power Back-Off (DPBO)) on the frequencies that
it has in common with the lines from the CO. As such, the lines from the CO can be
protected, and also the RT can still have a decent bit rate on those overlapping
frequencies. See Figure 39.
Figure 39 Crosstalk in mixed CO-RT deployment
PSD
Remote Terminal Customer Premises

frequency
Central Office
RT NT
CO NT
PSD
Remote Terminal
PSD
PSD
frequency frequency

NT
Initially, it was only possible to configure downstream PSD shaping by configuration

of a PSD Mask using a list of breakpoints, as part of the xDSL spectrum profile.
Although such a list of breakpoints allows for a high degree of flexibility, it lacks user
friendliness. Within ITU-T, the so-called E-side Model for Downstream PSD Shaping
has been defined, which provides several high-level parameters that are used to
configure the PSD shape at the RT.
The E-side parameters are configurable via a special DPBO profile, which can be
assigned either to an xDSL LT board or to an xDSL port.
Since DPBO PSD shapes can be configured in several ways, a number of priority
rules apply:
• The DPBO profile parameters take precedence upon the downstream PSD shape
configured via the xDSL spectrum profile.
• The DPBO profile parameters configured at LT board level apply, unless
port-specific DPBO parameters are configured as well.
The DPBO profile parameters apply to ADSL2plus and VDSL2.
8.8 Impulse noise monitor

The Impulse Noise Monitor (INM) collects data characterizing the impulse noise on
a particular line. This data can eventually be used to optimize the line configuration
for triple play (for example, minimum INP and maximum delay).
An impulse noise measurement can be started or stopped on a particular line for the
upstream direction, for the downstream direction, or for both. The upstream
measurements are performed by the XTU-C (CO side) and the downstream
measurements are performed by the XTU-R (CPE side), as illustrated in Figure 40.
The collected data is eventually represented as a set of impulse noise histograms,
both for the 15 minute and 24 hour PM intervals:
• Impulse Noise Inter arrival time histogram
• Impulse Noise Equivalent INP histogram
Figure 40 Impulse Noise Monitor in XTU-R and XTU-C
US xTU-C
INM PM
Impulse Noise INM Anomaly
counters
Sensor Counters 15min and 24h
Indication of xTU-R
Severely
Degraded Data DS
Symbols
EOC INM PM
Impulse Noise anomalies INM Anomaly
counters
Sensor Counters 15min and 24h

NT
Impulse noise measurements can be performed without service interruption.
8.9 Virtual noise

By configuring virtual noise, it is possible to minimize the impact of time varying
crosstalk on the stability of a DSL line. Virtual noise is an operator specified noise
PSD, using a piecewise linear model with breakpoints and a special SNRM mode. It
can be configured as a transmitter-referred noise PSD (TxRefVN, supported for
downstream and upstream) or as a receiver-referred noise PSD (RxRefVN,
supported for upstream only).
The transmitter-referred virtual noise PSD (TxRefVN) is converted by the receiver to
a receiver virtual noise PSD. The receiver determines its bitloading based on the
maximum of the received virtual noise and the received real noise. For a given
transmit signal PSD, the definition of a transmit virtual noise PSD can also be seen
as equivalent with setting a limit to the SNR that can be used by the receiver in the
bitloading process.
In downstream, when protecting a fixed data rate for all lines against VDSL2 self
FEXT crosstalk, the VN configuration is loop length independent. For more elaborate
cases, the TxRefVN can be configured using a limited set of profiles (for example, to
cover data rate with the loop length dependency, non FEXT noise, and so on).
Transmitter referred virtual noise can also be used with a single or a limited set of
profiles in upstream if no UPBO is enabled.
When UPBO is enabled or in the presence of other noise (non FEXT), the TxRefVN
becomes highly loop length dependent. To cope with this loop length dependency,
the per line overrule mechanism can be used. In case the operator does not wish to
use a per line management, an alternative for upstream (where UPBO is applied) is
to use the receiver referred virtual noise (RxRefVN) configuration option that can be
configured with a unique VN profile setting independently of the loop length.
As indicated in Figure 41, during initialization, the DSLAM forwards the virtual noise
downstream (DS) breakpoints to the CPE. The CPE calculates the DS virtual noise
based on the DS loop attenuation and takes the maximum of this virtual noise and
the actual received DS noise. The DSLAM does the same in upstream (US) direction,
based on the received US noise, the US virtual noise and the US loop attenuation (in
case of TxREFVN).
Transmitter-referred virtual noise is included in the VDSL2 standard (G.993.2) as an
optional feature.

NT
Figure 41 Virtual noise concept

Loop attenuation
VN Breakpoints
DS/US
VDSL2
[Loop
attenuation]
CPE
DSLAM Received Received

Noise US Noise DS
8.10 Physical Layer Retransmission (G.INP)

The Bit Error Rate (BER) requirements for providing High Speed Internet (HSI)
service are not too stringent. Transmission errors on the line are effectively hidden
by retransmissions at the TCP-IP layer. With the evolution towards IPTV, much lower
BER figures are required.
Impulse noise is the common cause for errors on the DSL line. Two types of impulse
noise are defined:
• Single High Impulse Noise Environment (SHINE): impulse noise occurring at
random time instants
• Repetitive Electrical Impulse Noise (REIN): periodic impulse noise, occurring at
near equidistant time instants
Forward Error Correction (FEC) is the traditional error correction technique to deal
with impulse noise, as defined in the ADSL, ADSL2(Plus) and VDSL2 standards.
FEC is very well suited to protect against REIN, but due to the fixed overhead, FEC
is not very efficient to protect against SHINE.
An alternative technique for impulse noise protection is to use retransmission.
Because there is no fixed overhead, retransmission is best suited to protect against
SHINE. Retransmission is available at the higher layers (TCP-IP retransmission for
HSI, End-to-end retransmission for video), but is now also defined for the DSL
physical layer.
ITU-T recommendation G.998.4 (G.inp) specifies techniques beyond those defined
in the existing DSL recommendations to provide enhanced protection against
impulse noise or to increase the efficiency of providing impulse noise protection. Both
REIN and SHINE are handled efficiently on the DSL physical layer.

NT
G.998.4 defines downstream retransmission both for VDSL2 mode and ADSL2(Plus)
mode. Support of retransmission in upstream is optional and only defined for VDSL2
mode.
The concept of DSL physical layer retransmission is illustrated in Figure 42:
• The transmitter groups user data in Data Transfer Units (DTUs) and adds a Cyclic
Redundancy Check (CRC) and sequence number.
• The receiver uses the CRC to detect errors and requests a retransmission of a
DTU when in error.
Figure 42 DSL physical layer retransmission concept
??
DTU CPE

DTU
DSLAM
The configuration parameters for retransmission are defined within a separate RTX
profile. The RTX profile is optional when configuring an xDSL port. If no RTX profile
is assigned, retransmission will be disabled.
A specific set of Performance Monitoring (PM) parameters is defined, monitoring the
quality of the line when retransmission is enabled.
8.11 Per-line configuration overrule

The configuration parameters for xDSL lines are provisioned by means of profiles.
Typically, the same configuration profile is used on multiple lines that share similar
line characteristics and offer the same type of service. If a small deviation is required
for the configuration of a particular line, then a completely new profile has to be
assigned to this line.
The per-line configuration overrule feature allows to overrule part of the xDSL
configuration parameters on a per-line basis, as shown in Figure 43.

NT
Figure 43 Per-line configuration overrule
XDSL Profiles
Parameter 1
Parameter 2 Actual
configuration
… Parameter 3
… Parameter 1
Parameter N
Parameter 2
merge
Parameter 3
XDSL per-line …
overrule parameters Parameter N
Parameter 2
Parameter N
This allows fine-tuning the configuration of individual lines, deviating from the overall
settings configured via the profiles.
When using this feature, one should take care that the overruled parameter values
do not result in an inconsistency with the parameters that are configured via the
profiles.
For bonded xDSL lines, the data rate, impulse noise protection and delay
configuration of the individual lines are derived from the bonding profile parameters.
A subset of the per-line configuration overrule parameters related to data rate,
impulse noise protection or delay will also be taken into account for bonded lines:
with RTX not active:
• Maximum data rate
• Minimum INP (Impulse Noise Protection)
with RTX active:
• Maximum ETR (Expected Throughput) and Maximum NDR (Net Data Rate)
• Minimum INP for SHINE and Minimum INP for REIN
• SHINE ratio
• LEFTR threshold

NT
8.12 Configurable US/ DS memory split

The aggregate interleaver or G.inp (G.998.4) memory supported for the different
VDSL2 profiles is defined by the VDSL2 standard (G.993.2). This aggregate memory
has to be split in the upstream and downstream direction, making a trade-off between
upstream and downstream data rate.
By default, a vendor discretionary algorithm is used to determine the memory split
between upstream and downstream. The configurable US/DS memory split feature
gives the operator manual control of the memory split. The percentage of memory
allocated to the downstream direction can be configured in steps of 1 percent. The
remaining memory is automatically allocated to the upstream direction.
By manually configuring the VDSL2 memory split, the operator has full control and
can make a better trade-off between upstream and downstream performance in case
the automatic algorithm does not provide the expected results.
8.13 Vectoring
VDSL2 vectoring takes full advantage of existing copper binders by making
conditions in the field as close to ideal as possible. Vectoring is not a method for
raising the theoretical maximum transport speeds. Instead, this noise-cancellation
technology addresses the gap between the theoretical maximum rate and the
speeds that service providers can deliver in typical field conditions.
In most deployments, telephone lines that carry VDSL2 signals are part of cables
(sometimes partitioned in smaller cable bundles) that contain 10 to a few hundred
lines positioned very closely together. This close proximity results in crosstalk, and
the higher the number of lines in a cable (bundle), the more crosstalk is generated.
Crosstalk is the main reason why lines in the field perform significantly lower than
their theoretical maximum. Vectoring enables each line to perform as if it is alone,
that is, without crosstalk. In a dynamic process, vectoring continually measures and
cancels this “crosstalk”, so all lines can operate at much higher capacity, as shown
in Figure 44.

NT
Figure 44 Typical vectoring gains

120
Optimal VDSL2 performance

100
80
Mbps
Near-optimal
field performance
60
with vectoring
40
Reduced field
performance due
20
to crosstalk
0
100 200 300 400 500 600 700 800 900 1000 1100 1200
Although most of the processing and necessary intelligence for vectoring resides in
the Digital Subscriber Line Access Multiplexer (DSLAM), minimal support is needed
at the Customer Premises Equipment (CPE) for the efficient estimation of the
crosstalk from the line into the neighboring lines and vice versa. This additional
functionality at the CPE side is defined by the International Telecommunication
Union (ITU) vectoring standard, G.993.5 (G.vector).
In order to achieve the full vectoring gain, all VDSL2 lines in the cable need to
participate in the crosstalk estimation. Otherwise, the crosstalk from some lines will
remain un-cancelled, reducing bit rates on vectored lines. The ultimate situation is
where all VDSL2 lines operate in G.vector mode.
Most of the existing VDSL2 CPEs in the field can be software upgraded to support
vectoring, or to be at least “vectoring-friendly”. The latter has been defined by the ITU
in Annexes X and Y of the VDSL2 standard (G.993.2) and allows the crosstalk from
the legacy line into the neighboring vectored lines to still be measured. Annex X
defines requirements for downstream friendliness such that the crosstalk from the
legacy line into the neighboring vectored lines can be estimated and cancelled in
downstream direction only. Annex Y defines requirements for full friendliness,
allowing estimation of crosstalk from the legacy line into the neighboring vectored
lines in up- and downstream direction. In principle, “friendly” customers do not benefit
from vectoring gains but their equipment no longer impairs vectoring for subscribers
who are paying for this enhancement.
For legacy VDSL2 CPEs that cannot be upgraded to support vectoring or
vector-friendliness, optionally the ZTV (Zero-Touch Vectoring) feature can be
enabled to cancel the crosstalk from such legacy line into the neighboring vectored
lines, in downstream direction only. To protect the neighboring vectored lines in
upstream, optionally the legacy UPBO feature can be enabled. When this feature is
enabled, legacy lines will be forced to use the legacy UPBO profile settings instead
of the normal UPBO settings configured on the line.

NT
Depending on the deployment scale (that is, the considered VDSL2 lines in the cable
binder) two vectoring types can be distinguished:
• Board Level Vectoring (BLV):
• Vectoring on one LT board (for example, 48 lines) and consequently only suited for
deployment scenario with deep fiber penetration where small remotes are installed.
• Only the crosstalk between the lines on the same board can be cancelled.
• System Level Vectoring (SLV):
• Vectoring over multiple LT boards and consequently suited for deployment scenarios
where bigger cabinets are installed.
• Crosstalk between lines on different LTs can be cancelled
The main additional functional blocks for a vectoring system (compared to a
non-vectoring VDSL2 system) are the following:
• Vectoring Control Entity (VCE):
The VCE will control the Vectoring state machine and will use the incoming error
samples to do the calculation of the crosstalk coefficients.
The VCE is located on the LT board for BLV, whereas it is on the Vector
Processing board for SLV.
• Pre-/Post-coder
The Pre-/Post-coder will perform the actual crosstalk cancellation by manipulating
the outgoing/incoming signals from the different DSPs.
To configure vectoring on the ISAM you have to create two new profiles: the
vectoring profile and the VCE profile. The VCE profile is assigned to the board
containing the VCE (LT board for BLV and Vector Processing board for SLV) while
the vectoring profile is assigned to the lines.
In case of SLV, the Vector Processing board is communicating with the LT boards by
means of dedicated front cabling. There are two modes of operation:
1 Auto-discovery mode disabled on VP and LT boards (default mode):
When auto-discovery is disabled, the connection between the VP links and LT
boards has to be configured. This is a precondition for being able to assign a
vectoring profile to an LT port. Failures of the VP-LT cable are reported on the
corresponding VP link.
2 Auto-discovery mode enabled on VP and LT boards:
When auto-discovery is enabled, there is no need any more to configure the
connection between the VP links and LT boards. Once auto-discovery is enabled
on the LT, vectoring profiles can be assigned to the LT ports. Failures of the
VP-LT cable are reported on the corresponding LT.
Vectoring operation requires synchronization between the LT and the VP card. When
installing the VP-LT cable, this synchronization will automatically be executed in case
at least one LT port has been configured in vectored mode. In case all LT ports are
still configured in non-vectored mode, the synchronization will be postponed until a
vectoring profile gets assigned to at least one port of this LT. The VP-LT
synchronization results in a resynchronization of all DSL lines of this LT.

NT
A System Level Vectoring group can be composed of VP and SLV LT boards located
in different ISAM shelves, managed as separate network elements. This type of
setup is called Cross-DSLAM Level Vectoring (XDLV) and is shown in Figure 45.
Because of the limited VP-LT cable length, the equipment still has to be collocated.
Figure 45 Cross-DSLAM Level Vectoring
ISAM 1
VP
NT LT
LT
QSFP
cables
ISAM 2
LT
NT
LT
Constraints:
• XDLV is only possible when auto-discovery mode is enabled. Without
auto-discovery, the VP and the LT boards have to be managed by the same
ISAM.
• XDLV requires compatible SW releases for the VP and LT boards. In case a SW
incompatibility is detected, a VP/LT mismatch alarm will be raised. By default, the
xDSL LT ports with a vectoring profile will not synchronize anymore, but the
system can be configured to autonomously switch such lines to a fall-back VDSL2
configuration with limited spectrum usage.
Recommended configurations with vectoring:

• With vectoring, the use of G.inp and SRA is strongly recommended.
• With G.inp, it is strongly recommended to combine with the intra-DTU block
interleaver for extra protection against varying RFI or other varying narrowband
interference, for example crosstalk from handshake tones (G.994.1 or G.hs) on
neighboring lines.
• With vectoring, the application of UPBO remains recommended.
In theory, with perfect vectoring, there is no need for UPBO. In practice however
some type of UPBO may still be required, for example because of residual
crosstalk or dynamic range limitations of the receiver. Also, UPBO must still be
applied in case non-vectored lines, for example G.vector friendly lines (G.993.2
Annex X or Annex Y) or legacy lines (with reduced spectrum or reduced transmit
PSD to limit the impact on the vectored lines), are mixed with vectored lines in the
same cable.
• It is strongly recommended to disable the V43 G.hs toneset on the CPE in order
not to disturb active vectored lines.

NT
Vectoring restrictions:
• For bonded legacy VDSL2 lines, ZTV support is limited to 2-pair bonding.
• ZTV lines do not perform automoding with an open VDSL2 profile (17a, 12a, …),
similar to G.Vect lines.
• The reported QLN is always without crosstalk cancellation.
• VDSL2 special Loop Diagnostics mode (that is robust initialization without
transition to showtime) is not supported on vectored lines or lines operating in ZTV
mode.
• VDSL 997 bandplan is not supported in vectored mode.
8.14 Fall-back configuration for vectoring

The system can be configured to automatically switch the configuration of a vectored
line to a fall-back non-vectored VDSL2 configuration with limited spectrum usage for
any of the following conditions:
1 Vectoring CPE capability mismatch
The vectoring profile specifies the type of CPE allowed on a line:
• G.Vector CPE
• G.Vector friendly CPE for downstream direction (G.993.2 Annex X)
• Full G.Vector friendly CPE (G.993.2 Annex Y)
• Legacy VDSL2 CPE
In case the connected type of CPE does not match any of the allowed types, the
line will by default not initialize anymore in order not to disturb the other lines of
the vectoring group. As an alternative, the system can be configured to
automatically switch the line to a fall-back non-vectored VDSL2 configuration with
limited spectrum usage. When the mismatch disappears, the line will
automatically switch back to the normal configuration.
2 VP-LT communication problems (only applicable to SLV)
In case of communication problems between the LT and the VP board in case of
SLV, the lines configured with a vectoring profile will by default not initialize
anymore in order not to disturb the other lines of the vectoring group. As an
alternative, the system can be configured to automatically switch the lines to a
fall-back non-vectored VDSL2 configuration with limited spectrum usage. When
the communication recovers, the lines will automatically switch back to the
normal configuration.
3 Vectoring configuration not feasible (only applicable to XDLV)
In case of XDLV, the LT board and the VP board can temporarily be running a
different SW version (e.g. during a SW upgrade). When both SW versions are
compatible but the SW version running on the VP does not support yet a specific
vectoring feature that has been enabled on a line of the LT, this line will by default
not initialize anymore. As an alternative, the system can be configured to

NT
automatically switch such line to a fall-back non-vectored VDSL2 configuration

with limited spectrum usage. When the mismatch disappears (e.g. after VP SW
upgrade), the line will automatically switch back to the normal configuration
The definition of the fall-back configuration as well as the enabling of the fall-back
mechanism can be specified at xDSL LT board level.
For bonded lines, additionally a fall-back bonding configuration can be specified.
8.15 Save Our Showtime (SOS)

RA Mode 1 to RA Mode 3 are described in section Seamless rate adaptation
ITU-T G.997.1 and ITU-T G.993.2 have defined a fourth mode of Rate Adaptation:
• RA mode 4 (Dynamic rate adaptation with SOS):
• At startup: start up shall be the same as in RA Mode 2.
• At showtime: SRA behavior is identical to RA Mode 3, unless the actual net data rate
is below the Minimum net data rate as a result of the SOS procedure. Additionally,
SOS may be performed when the conditions specified by the SOS trigger parameters
are satisfied.
• If at startup, it is detected that SOS is not supported in a direction by either CO or
CPE, but SRA is supported by CO and CPE, both CO and CPE fall back to RA Mode
3. If SRA is not supported by either CO or CPE, both CO and CPE fall back to RA
Mode 2.
Save Our Showtime (SOS) prevents the line from retraining when the external noise
suddenly increases. A retrain may take 60 seconds or more during which time the
physical link is disrupted. The higher layers may be disrupted as well and may take
also some time to recover. Such disruptions are undesirable for QoS of IPTV and
many other services.
• SOS allows the application to maintain at least a minimal connection during a
period of degradation. The goal of SOS is to avoid a full system retrain while
maintaining the minimum required quality of service.
• After a SOS procedure, if the noise condition improves, SRA optimizes the data
rate to match the new noise condition. Depending on the noise condition, SRA
may even fully recover to the data rate that was present before the SOS
procedure was activated. Therefore, compared with a full retrain, the combination
of SOS and SRA avoids interruption of service in the presence of a sudden noise
event.
SOS is supported only on VDSL2 and as a recent enhancement to the

recommendation.
SOS is only supported on vectoring line cards.

NT
8.16 VDSL2 35b

VDSL2 35b is a perfect match for operators who need to deliver the highest possible
speeds in a cost-effective way on medium-length loops. VDSL2 35b is a new
technology that:
• Delivers aggregate speeds of 200 Mbps and more over traditional copper
telephone lines at distances up to 500 meters, and 300 Mbps and more on loops
shorter than 250m
• Extends the frequency range used by VDSL2 17a to 35 MHz to achieve these
higher speeds.
• Can be mixed with existing VDSL2 17a deployments to fill the gap between
VDSL2 17a vectoring (100 Mbps aggregate at 700m) and G.fast (500 Mbps+
aggregate at 100m)
• Offers higher speeds (up to double) compared to VDSL2 on loops shorter than
550m
• Offers longer reach (higher bit rates beyond 250m) and higher density (100-200
subscribers) compared to G.fast
Figure 46 illustrates the typical performances that can be expected expect from
VDSL2 vectoring, G.fast, and VDSL2 35b. Aggregate bit rates (upstream +
downstream) are used for a fair comparison between technologies. G.fast
performance is based on the ITU-T standard (G.9701 12/2014), that is, using up to
106 MHz of spectrum, and excluding VDSL2 (17a) spectrum to allow a mixed
technology deployment.
Figure 46 VDSL2 35b fills the gap between VDSL2 vectoring and G.fast
VDSL2 35b
In terms of bit rate, VDSL2 35b fills the gap between VDSL2 vectoring and G.fast. At
loop lengths between 250 and 550 meters. VDSL2 35b delivers 200+Mbps up to
500m and outperforms both VDSL2 vectoring and G.fast.
At shorter distances (less than 250m) VDSL2 35b does not match G.fast's speeds,
but still delivers over 300Mbps. So even on short loops, VDSL2 35b makes a strong
case for operators who need to deliver up to 300Mbps.

NT
On longer loops, VDSL2 35b falls back to VDSL2 17a vectoring performance.
Figure 47 VDSL2 35b mixed vectoring with VDSL2 17a
VDSL2 35b allows mixed vectoring with VDSL2 17a

(VDSL2 30a does not)
VDSL2 30a
138 kHz to 30 MHz
No vectoring possible between 17a and 30a
VDSL2 17a
25 kHz to 17 MHz
VDSL2 35b
25 kHz to 35 MHz
35 MHz VDSL2 but with the same tone spacing as 17a
Vectoring possible between 17a and 35b lines
Using higher frequencies for VDSL2 has already been applied with the VDSL2 30a
standard profile. However, the 30a tone spacing is different from the 17a tone
spacing preventing crosstalk cancellation between 17a and 30a lines as shown in
Figure 47). This makes upgrades of the existing 17a deployments to 30a unattractive
as it would require a full swap of the VDSL2 CPE installed base.
VDSL2 35b overcomes this limitation by using the same tone spacing as 17a. This
allows vectoring across VDSL2 35b and 17a lines, and thus mixed deployments and
a smooth introduction of VDSL2 35b. Since only tone spacing changes, existing 30a
band plans could in principle be reused. However, on request of operators new
VDSL2 35b band plans reaching out to 35MHz have been adopted by ITU-T (in
Annex B of the VDSL2 standard).
VDSL2 35b is described in a new Annex Q of Amendment 1 of the VDSL2 standard
(G.993.2 2015).
For operators that already deploy VDSL2 17a vectoring, VDSL2 35b offers a fast and
cost effective upgrade path to 300Mbps services on short loops without the need for
bonding or deploying new cabinets. As existing VDSL2 vectoring and VDSL2 35b
lines can be mixed in the same cable without performance impact, only subscribers
that sign up for the premium VDSL2 35b service need to change CPE.
8.17 VDSL2-LR
VDSL2-LR or VDSL2-Long Reach is a technology that enables VDSL2 to have an
ADSL like reach, while preserving VDSL2 performances on shorter loops. It
increases throughput by avoiding the ATM cell tax (overhead due to ATM
encapsulation) and support of vectoring.

NT
As VDSL2-LR is vectoring capable, it can be mixed with other VDSL2 vectored lines
resulting in an overall data rates increase of the whole vectoring group, by removing
the 'ADSL' crosstalk from the binder and allowing vectoring also in the ADSL DS
frequency band.
At the same time VDSL2-LR simplifies the management of the network by removing
the need for separate ADSL and VDSL specific profiles.
It is thus the technology of choice for migrating ADSL lines towards a single
technology vectored VDSL2 network.
For VDSL2 lines, it removes the need for configuring multiple VDSL2 profiles (e.g.
17a and 8b automoding) as VDSL2-LR automatically controls the bandwidth and
transmit power depending on loop distance.
VDSL2-LR has three operating modes: Short, Medium and Long loop. The selection
of the operating mode is automatic during an additional probing phase.
The management system can overrule this automatic selection and can also report
the actual operating type(mode).
Figure 48 provides an example of the VDSL2-LR mode selection and downstream
performance on PE04 wire compared to ADSL2plus. The VDSL2-LR line was
configured for 17a operation with all VDSL2-LR modes allowed.
Figure 48 Example Mode selection and Performance of VDSL2-LR
VDSL2 35b

System Description for FD 100/320Gbps NT and FX ADSL/VDSL Bonding
NT
9 ADSL/VDSL Bonding
9.1 Overview
9.2 Bonding levels
9.3 Bonding group configuration
9.4 Bonding group initialization
9.5 Interoperability with non-bonding capable CPE
9.6 Delay equalization in IFEC mode
9.1 Overview
xDSL bonding allows multiple physical xDSL lines to be combined into one logical
link to increase the bit rate capacity to the subscriber and/or extend the reach of
existing services. Figure 49 illustrates both deployment scenarios for 2-pair xDSL
bonding. This xDSL bonding chapter covers both ADSLx and VDSL2 bonding.
Figure 49 xDSL bonding deployment scenarios
double the bit rate at the same reach extend reach for the same bit rate
The ISAM supports bonding groups of two up to eight pairs. The type and level of
bonding support (ATM/PTM and number of pairs) is xDSL line card dependent.
ATM bonding is compliant with ITU-T ATM-based multi-pair bonding standard
G.998.1:
• Supported for ADSL, ADSL2 and ADSL2plus mode of operation
• Maximum 2-pair bonding supported
PTM bonding is compliant with ITU-T Ethernet-based multi-pair bonding G.998.2:
• Supported for VDSL2, ADSL2 and ADSL2Plus mode of operation
• Maximum 8-pair bonding supported

ADSL/VDSL Bonding System Description for FD 100/320Gbps NT and FX
NT
9.2 Bonding levels

There are two levels of xDSL bonding, depending on whether the ports of the xDSL
LT that make up a bonding group can be chosen in a flexible way or not.
• Odd-even pair bonding
• The ports to be configured for bonding must be adjacent ports on the LT board.
• Only an odd-numbered port can be the primary port of a bonding group. The bonding
group index number is derived from the primary port number.
• Board-level bonding:
• The ports to be configured for bonding do not have to be adjacent ports on the LT
board.
• Any port can be the primary port, up to a maximum of N/2 primary ports on an N-port
LT. The bonding group index number is derived from the primary port number.
9.3 Bonding group configuration

Once the xDSL lines are configured, a bonding group can be created consisting of
these lines. As an alternative, first the bonding group can be created before
configuring the individual xDSL lines.
A bonding group is configured by assigning a bonding group profile. Optionally a
bonding group RTX profile can be assigned, allowing the lines to operate in RTX
mode (G.inp/G.998.4).
The bonding init mode to be applied for PTM bonding can be selected at system
level:
• By default, PTM bonding groups will be operating in init mode 1, which includes a
probe training
• As an alternative, PTM bonding can be configured to operate in init mode 2, which
does not include a probe training
ATM bonding groups will always be operating in init mode 1.
9.4 Bonding group initialization
9.4.1 Bonding group initialization when operating in init

mode 1
Bonded xDSL lines do not necessarily have the same length or have the same noise
conditions. When initializing a bonding group, the goal is to allocate a fair share of
the overall configured bonding group bit rate to each of the contributing lines,
depending on the individual line conditions.

System Description for FD 100/320Gbps NT and FX ADSL/VDSL Bonding
NT
At initial startup of the bonding group, a probe training is executed. Each line of the
bonding group is trained to determine its maximum bit rate capacity. This information
is used to make an optimal selection of lines and to calculate an optimal split of the
configured bonding group bit rates. The algorithm guarantees that at any time the
lines will be operating within a maximum bit rate ratio of 4:1.
Besides the bit rates configured at bonding group level, the bandwidth split algorithm
additionally takes into account a subset of the bit rate parameters of the configuration
profiles of the individual lines:
• xDSL lines configured in RA Mode 1 (MANUAL) are forced to operate at the
planned bit rate configured at line level.
• xDSL lines configured in RA Mode 2 (AT_INIT), 3 (DYNAMIC) or 4 (SOS) are only
allowed to operate at a bit rate higher than or equal to the minimum bit rate
configured at line level. The maximum bit rate configured at line level is ignored.
The final initialization phase of the bonding group will only include the selected lines
during the probe training, using the bit rate configuration calculated by the bandwidth
split algorithm. Lines which are not selected will not be able to contribute to the
bonding group. This decision is maintained until the next full initialization of the
group, which includes a new probe training. The bonding group is only brought into
service if the configured minimum group bit rate is reached.
For ATM bonding, the probe training will be executed during each initialization of the
bonding group. For PTM bonding, the bonding group will first try to become
operational using the bandwidth split parameters calculated during a previous
successful initialization, unless the planned bonding group bit rate was not achieved.
Reconfiguring the bonding group or setting the bonding group admin down/up will
always result in a full re-initialization of the bonding group (hence including a new
probe training).
For odd-even pair bonding, if either line of the bonded pair is out of service during
probe training, the bonding group will not initialize. This contrasts with board-level
bonding, for which the bonding group can be brought in service even if only a subset
of the lines is available during probe training, depending on the configured bonding
group assembly timer. This timer limits the duration of the probe training phase.
9.4.2 Bonding group initialization when operating in init

mode 2
In init mode 2, bonding groups will always initialize without probe training. The
bonding group initialization time at initial start-up will be significantly shorter
compared to init mode 1.
For an N-pair bonding group, a simplified bandwidth split algorithm will assign an
equal share (1/Nth) of the configured bonding group bit rates to each of the lines. The
algorithm does not enforce that all lines of the group are operating within the 4:1 bit
rate ratio.

ADSL/VDSL Bonding System Description for FD 100/320Gbps NT and FX
NT
Besides the bit rates configured at bonding group level, the bandwidth split algorithm
additionally takes into account all bit rate parameters of the configuration profiles of
the individual lines:
• xDSL lines configured in RA Mode 1 (MANUAL) are forced to operate at the
planned bit rate configured at line level.
• for xDSL lines configured in RA Mode 2 (AT_INIT), 3 (DYNAMIC) or 4 (SOS), the
minimum and maximum bit rates at line level are set as follows:
• the minimum bit rate actually configured on the line is the maximum of the minimum
bit rate configured at line level and 1/Nth of the minimum bit rate configured at group
level.
• the maximum bit rate actually configured on the line is the minimum of the maximum
bit rate configured at line level and 1/Nth of the maximum bit rate configured at group
level.
Exception: When the maximum bit rate configured at line level is 0, this value is not
taken into account (that is, considered as infinite)
The bonding group is brought into service when at least one of its lines is operational,
even when the configured minimum group rate is not reached.
All configured lines of the bonding group are always selected for bonding, even lines
that were failing during initial start-up of the bonding group. These lines can join the
group at any time, without a need for a re-initialization of the group.
9.5 Interoperability with non-bonding capable

CPE
For board-level bonding, automatic switchover to non-bonded operation is supported
when connecting a non-bonding capable CPE to a bonded user port. In this case, the
bit rates configured at bonding group level will be assigned to this single line.
For odd-even pair bonding, initialization with a non-bonding capable CPE is not
supported.
9.6 Delay equalization in IFEC mode

When operating in init mode 1, during the probe training phase the maximum
interleaving delay of all lines of the bonding group will be set as configured in the
bonding group profile. During the final training phase, the maximum delay configured
on the individual lines may be changed in order to optimize the differential delay
between the lines.
This mechanism is not supported when operating in init mode 2.

System Description for FD 100/320Gbps NT and FX GPON Network Architecture
NT
10 GPON Network Architecture

10.1 Introduction: GPON Network
10.2 GPON Network Architecture
10.3 GPON Implementation of ISAM
10.4 V-OLT GPON Functions
10.5 Protection
10.6 ONU Functions
10.1 Introduction: GPON Network

An Optical Distribution Network (ODN) based on Gigabit Passive Optical Network
(GPON) technology consists of two main parts that may be implemented by network
equipment that can be categorized as follows:
• Optical Line Termination (OLT):
This unit provides central processing, switching, and control functions. This
equipment is located at the network side of the Optical Distribution Network
• Optical Network Unit (ONU):
This unit is located at the subscriber premises as distributed end-points of the
ODN. This equipment implements the GPON protocol and adapts GPON Protocol
Data Units to subscriber service interfaces.
Note — There is a specific case for ONU equipment that is
generally referred to as Optical Network Termination (ONT).
This specific term is generally used to designate a single-user
subscriber premise equipment.

GPON Network Architecture System Description for FD 100/320Gbps NT and FX
NT
10.2 GPON Network Architecture

In the Nokia GPON network architecture, the OLT function is provided via three
distinct equipment types:
• Packet - Optical Line Termination (P-OLT) unit which corresponds to the ISAM
7360 FX and 7362 ISAM DF/SF products.
• Video - Optical Line Termination (V-OLT) unit which distributes Radio Frequency
(RF) overlay video signals across the GPON if the network provider chooses this
method for providing Video Services. (This optional equipment is provided by a
third-party supplier and hence outside of the scope of ISAM)
• Wavelength Division Multiplexer which is only needed in case of V-OLT presence
in the network, and which is used to mix and separate the RF Video signal
into/from the optical fiber going towards ONUs. (This optional equipment is also
outside of the scope of ISAM)
Nokia also provides a wide variety of ONU equipment which works seamlessly
together with the ISAM (P-OLT) products to form a fiber access network capable of
delivering high quality voice, video, and data services to both single-family or
multi-dwelling residential subscribers and business subscribers.
This model is shown in Figure 50.

NT
Figure 50 ISAM GPON Network Architecture
Network Central office or Fiber Passive ONTs End user

remote terminal distribution outside
plan
Optical link length 1
Optional RF
RF Video router
1,550 nm
provider V-OLT/EDFA
network
Ethernet IPTV
MDU
1,490 nm
WDM 1,550 nm 2.4 Gb/s
Internet 1,310 nm 1.2 Gb/s

Edge switch
router ISAM
PSTN
Voice
gateway
EMS/NMS
Class 5 Softswitch
switch
1 The maximum optical link length depends on the specific equipment and deployment conditions
10.2.1 Standards
The Nokia GPON network is developed based on the following ITU-T standards:
• G.984.3 (GPON TC Layer) amendment 1 and 2
• G.984.4 (GPON OMCI)
• G.984.4 (GPON OMCI) amendments 1 and 2

NT
10.3 GPON Implementation of ISAM

ISAM provides the core processing, switching, and control functions and interacts in
the upstream direction with the Ethernet switch and voice gateway using the NT
cards. The ISAM shelves with their NT and GPON LT boards comprise the
conceptual P-OLT system from the GPON Network point of view.
The Nokia ONU products are edge devices that use GPON technology to extend a
fiber optic cable from a P-OLT shelf to a subscriber residence, including single-family
residences, multi-dwelling residences such as an apartment building, and small
office / home office applications.
10.3.1 Transmission Convergence Layer - Multiplexing

Architecture
ITU-T GPON recommendations provide two multiplexing mechanisms: ATM base
and GEM base.
ISAM only supports GEM multiplexing. The ATM partition is not supported.

NT
Figure 51 GPON Functional Blocks
PLOAM OMCI
TC Adaptation sub-layer
OMCI adapter
VPI/VCI Port-ID
filter filter
ATM TC GEM TC
adapter adapter
GTC Framing sub-layer

- BW Granting
Alloc-ID Alloc-ID Embedded - Key Switching
filter filter OAM - DBA
PLOAM Frame
ATM partition GEM partition
partition header
Multiplexing based on frame location
• In downstream direction, the GEM frames are carried in the GEM partition, and
arrive at all the ONUs. The ONU framing sublayer extracts the frames, and the
GEM TC adapter filters the GEM fragment based on their 12-bit port ID. Only
frames with the appropriate port IDs are allowed through to the GEM client
function at the ONU.
• In upstream direction, the GEM traffic is carried over one or more Transmission
Containers (T-CONTs). The OLT receives the transmission associated with the
T-CONT, and the frames are forwarded to the GEM TC adapter, and then to the
GEM client function at the OLT.
One ONU can be served by one or several T-CONTs, but a given T-CONT can only
be used by a single ONU. Also, a given T-CONT can transport traffic from several
GEM ports, but traffic from a given GEM port can only be carried by a single T-CONT.
Both GEM ports and T-CONTs are internal GPON protocol constructs/abstractions
that are not directly exposed to the operator for convenience and ease of
management.

NT
10.3.2 Transmission Convergence Layer - GPON Media

Access Control
The Transmission Convergence layer in ISAM provides media access control for
upstream traffic.
Figure 52 PON media access control concept
Downstream
Frame header (PCBd)

Payload for downstream
US BW Map
Alloc ID Start End Alloc ID Start End Alloc ID Start End
1 100 300 2 400 500 3 520 600
Upstream
T-CONT1 T-CONT2 T-CONT3

(ONU1) (ONU2) (ONU3)
Slot Slot Slot Slot Slot Slot
100 300 400 500 520 600
In the basic concept, downstream frames indicate permitted locations for upstream
traffic and upstream frames synchronized with downstream frames as outlined in
Figure 52.
The ISAM sends pointers in the frame header Physical Control Block downstream
(PCBd). The pointers indicate the time at which each ONU must begin and end its
upstream transmission. In this way, only one ONU can access the GPON at any time,
and there is no contention in normal operation. The pointers are 2 bytes long and
given in units of bytes, allowing the OLT to control the GPON at an effective static
bandwidth granularity of 64 kb/s. The size of the GTC frame is 125 µs. The
downstream payload contains GEM packets that are uniquely destined to some
specific T-CONT/ONUs. The ONUs examine the GEM header and only process the
GEM packets which port IDs match its own.
10.3.3 Transmission Convergence Layer - Upstream and

Downstream Frames
Figure 53 shows the PON downstream frame format.

NT
Figure 53 PON Downstream Frame format
PCBd PCBd PCBd

Payload n Payload n+1
n n+1 n+2
TP-Frame = 125 µS
"Pure" ATM cells TDM & Data Fragments over GEM
Section Section
N x 53 bytes
Figure 54 shows the PON upstream frame format.

Figure 54 PON Upstream Frame Format
Upstream Frame
PLOu PLOAMu PLSu

DBRu
Payload X DBRu
Payload Y PLOu DBRu Payload Z
X Y Z
ONT A ONT B
10.3.4 Transmission Convergence Layer - GEM

Encapsulation of Ethernet Packets
Ethernet packets are encapsulated by ISAM and ONUs into GEM as shown in
Figure 55. Each packet is mapped into the GEM frame. The Preamble and SFD
bytes are not included in the GEM frame.
Figure 55 Ethernet encapsulation over GEM
Ethernet Packet GEM Frame
PLI
12 Inter Packet Gap
Port-ID 5 Bytes
7 Preamble PTI
1 SFD CRC
6 DA
6 SA
2 Length/Type GEM Payload
MAC client Data
4 FCS
1 EOF

NT
Each produced GEM fragment is transmitted contiguously. A fragment cannot

straddle a frame boundary. Therefore, the fragmentation process must be aware of
the amount of time remaining in the current partition or payload, and must fragment
its user data frames appropriately.
Figure 56 shows different possibilities of user frames fragmentation.
Figure 56 Fragmentation Examples
Case 1 Case 2 Case 3
User Frame User Frame User Frame
GEM GEM GEM GEM GEM GEM

Full
PTI: PTI: #1 PTI: #2 PTI: #1 PTI: #2 PTI: #3
Frame
001 001 001 001 001 001

Dynamic Bandwidth Assignment (DBA) is the process by which ONTs and their
associated Transmission Containers (T-CONTs) dynamically request upstream
bandwidth (either implicitly through idle cell monitoring at OLT or explicitly through
buffer status reporting from ONT to OLT) and whereby the OLT reassigns upstream
bandwidth accordingly.
ISAM bandwidth reassignment is applied to the distribution of the non-guaranteed or
un-assured portion of the service traffic in order not to disturb the guaranteed traffic
contracts.
T-CONTs are used for the management of upstream bandwidth allocation in the
GPON section of the Transmission Convergence layer. As such, T-CONTs are
primarily used to improve the upstream bandwidth use on the GPON.

Forward Error Correction (FEC) is used by the transport layer of ISAM and it is based
on transmitting the data in an encoded format. The encoding allows the decoder to
detect and correct the transmission errors. For example, for input BER of 10-4, the
BER at the FEC decoder's output may drop to 10-15. By using the FEC technique,
data transmission with low error rates can be achieved, and retransmissions are
avoided.
FEC results in an increased link budget. Therefore, higher bit rate and longer
distance from the ISAM to the ONUs can be supported. Alternatively, by using this
process a higher number of splits per single GPON tree can be achieved over an
equivalent distance.
The FEC encoding and decoding of ISAM is based on Reed-Solomon (block based
FEC).

NT
Reed-Solomon (RS) is a block-based code, which takes a data block of constant size
and adds extra “redundant” bits at the end, thus creating a code word. Using those
extra bits, the FEC decoder processes the data stream, discovers errors, corrects
errors, and recovers the original data. Reed-Solomon code is specified in CMTT
recommendation CCIR 723.
When using a block-based FEC, original data is preserved. Therefore, by ignoring
the parity bits, even if the other side does not support FEC, the original data can be
processed.
However, block-based FEC error correction is not efficient for very high BER levels
(for example, for 10-3 BER, a decoding error will be generated).
10.3.7 Delay Tolerance

For the upstream GPON transmission, ISAM provides a configurable Delay
Tolerance parameter to realize optimal latency and delay variation characteristics on
the GPON link.
10.3.8 Security
ISAM uses Advanced Encryption Standard (AES) for security. Internally AES is
enabled/disabled by ISAM for individual port IDs in conformance with the GPON
protocol standards. However, management model granularity is provided on a
per-ONU basis.
Advanced Encryption Standard is a block cipher that operates on 16 byte (128 bit)
blocks of data. It accepts 128, 192, and 256 bit keys. This algorithm is described in
documents published by the National Institute of Standards and Technology (NIST)
in the USA.
There are several modes of operation for this standard. However, only the “Counter”
(CTR) mode is used by ISAM. In this mode, the cipher generates a stream of 16-byte
pseudorandom cipher blocks which are exclusive-ORed with the input clear-text to
produce the output of cipher-text. The cipher-text is exclusive-ORed with the same
pseudorandom cipher blocks to regenerate the clear-text. The key length is fixed at
128 bits.
10.3.9 ONU Ranging and Discovery

When ISAM is ranging new ONUs, working ONUs must temporarily stop
transmissions. This is done by opening a ranging window to discover new ONUs.

NT
Two activation/ranging methods supported by ISAM

• Configured-S/N:
The serial number of the ONU is registered in advance at the OLT and used for
authentication of the matching ONT.
• Discovered-S/N:
The serial number of the ONU is not registered at the OLT. It requires an
automatic detection mechanism of the serial number of the ONU based on the
operator-assigned ONU Registration ID that is provisioned locally at the ONU and
at the ISAM for a match. In case a new ONU is detected, an ONU ID is assigned
and the ONU is activated.
• Operator-assigned ONU Registration ID can take two forms: a simple Subscriber
Location IDentifier (SLID) or a LOgical IDentifier (LOID, which consists of a logical
subscriber location designation and an associated password).
• The use of SLID vs. LOID based authentication is provisionable on a per-PON basis.
10.3.9.1 Concurrent Use of Activation/Ranging Methods:

ISAM allows a special per-PON configuration in order to support ONUs conforming
to either Configured-S/N or LOID-based Discovered-S/N authentication methods to
be mixed on the same PON. In this case LOID-based Discovered-S/N has
precedence over Configured-S/N mode in processing each ONT.
In addition, ISAM also allows another per PON configuration to support concurrent
existence of ONTs working in S/N, LOID or SLID modes on the same PON. In this
particular arrangement, the discovery of an ONT which has not been provisioned yet
shall trigger a new ONT alarm that includes its LOID, SLID and S/N along with the
type of the ONT. ISAM also allows the retrieval of the ONT type via the management
interface.
10.3.9.2 SLID/LOID-Serial_Number Bundling and Anti

Snooping Function:
SLID or LOID (G.988) association with a S/N may to be locked after a user defined
time period (for example, 4h/24h) following the first ranging of the ONT with a certain
Serial Number. This will allow for changing of ONT during installation. In this case,
after the defined period of time, the installed ONT hence its Serial Number shall be
considered as final per operator's intentions and the SLID/LOID association to this
Serial Number shall be frozen.
After this defined transition period any detected mismatch results in an alarm.
The function of bundling or un-bundling between SLID/LOID with SN is configurable
per ONT.

NT
There are three triggers for initiating the activation of an ONU:

• The network operator enables the activation process to start when it is known that
a new ONU has been connected.
• The OLT automatically initiates the activation process, when one or more of the
previously working ONUs are 'missing', to see if those ONUs can return to service.
The frequency of polling is programmable.
• The OLT periodically initiates the activation process, testing to see if any new
ONUs have been connected. The frequency of polling is programmable.
10.3.9.3 Delayed SW Activation Method

Operators may want to avoid interrupting end-user service continuity during the ONT
SW upgrade procedure. ISAM provides a special "delayed activation" method to
cover such cases. In this mode of operation the desired ONT SW version is
downloaded to the passive SW bank of the ONT, however the activation of the SW
load is delayed until a naturally occurring interruption such as an ONT Power-Off or
PON Plug-Out , or, after clearance of certain fault conditions impacting the ONT
ranging such as a PON or board failure.
This feature is available in the same manner via both individual ONT SW
configuration and bulk configuration by means of ONT SW Control Table.
10.3.10 ONU Activation

The activation process is performed under the control of ISAM.
The activation procedure is performed by the exchange of upstream and
downstream flags and Physical Layer Operations Administration and Maintenance
(PLOAM) standard messages defined for GPON, as follows:
1 ONU receives the requested GPON operating parameters from ISAM.
2 ONU adjusts it parameters accordingly.
3 ISAM discovers the Serial Number of a new connected ONU.
4 ISAM assigns an ONU-ID to the ONU.
5 ISAM measures the round-trip delay of the ONU transmission.
6 ISAM notifies the ONU of the equalization delay.
7 ONU adjusts the transmission phase to the notified value.
In the normal operating state, all the transmissions can be used for monitoring the
phase of the arriving transmission. Based on the monitoring transmission phase
information, the equalization delay can be updated.

NT
ISAM broadcasts the Serial-Number requests to all ONUs in the Serial-Number

state. Consequently, more than one Serial-Number transmission can simultaneously
arrive at the OLT causing a collision. The Random Delay Method is used to resolve
this problem.
Based on the Random Delay Method, each Serial-Number transmission is delayed
by a random number of delay units generated by each ONU. The delay units are 32
bytes long for all bit rates. The random delay must be an integral number of delay
units. Following each response to a Serial-Number request, the ONU generates a
new random number, thus collisions are easily and efficiently prevented.
10.3.11 OMCI
The ONT Management and Control Interface (OMCI) is the ITU-T G984.4-based
open interface definition that provides the management model for provisioning and
surveillance related functions between ISAM and ONUs.
10.3.12 Transmission Convergence Layer Performance

Monitoring
ISAM provides on-demand counters to monitor GPON TC layer traffic and
performance. The related counters are collected internally on a GEM-port basis from
both ends of the GPON section, and are presented to the operator on a per-ONU and
per-UNI basis. In addition, the same set of counters is also supported for the shared
Multicast GEM port of the PON.
10.3.13 Rogue ONT Detection and Defense Mechanism

The Rogue ONT Diagnostic feature of the ISAM provides a means of monitoring
ONT behavior on the PON and identifying rogue ONT(s) through the problematic
symptoms of other ONTs on the optical network. Alarm notifications are generated
upon detection of Rogue ONTs.
There are four Rogue ONT detection methods:
• The on-demand ON/OFF test which is a service-affecting test whether or not a
rogue ONT is detected.
• The on-demand pattern test which is a non-service affecting test unless a rogue
ONT is present on the PON.
• The background pattern test which is run in background mode on the ONTs at
regular intervals or on a given ONT when it ranges. This test is disabled by default.
• The background ON/OFF test which is triggered by PON LOS to run a test on
each ONT.

NT
10.3.13.1 On Demand ON/OFF Test

This test is also called the manual stuck laser test or the manual on/off test.
This test is service affecting as all ONTs on the PON are disabled during the test.
The Disable Serial Number PLOAM message is used for testing. This PLOAM is sent
to each ONT in turn. G984.3 states that on receiving this message the ONT should
go to Emergency Stop State and disable the TX optics.
The ISAM supports a broadcast option to the Disable Serial Number PLOAM
message to allow the disabling of ONTs which have been added to the PON but are
not yet provisioned at the time of the test. This enhancement is not defined in
G984.3.
10.3.13.2 On-Demand Pattern Test

An ONT which is exhibiting rogue behavior by transmitting outside its assigned time
slot should impact other ONTs on the PON. The on-demand pattern test uses the
Diagnostic PLOAM message to trigger a test mode on an individual ONT while
monitoring for adverse impacts on the other ONTs. The impacts may include a
change in alarms or an ONT moving to INACT state.
The pattern test enabled on one ONT generally does not have an impact on other
subscribers unless the ONT being tested is rogue. However, in case of RF overlay,
and depending on specific channel line up frequencies, a small amount of transitory
interference might be observed on the video signal. If a rogue ONT is found, other
subscribers would be impacted for a few seconds on the first check.
This test is implemented via an ONT Diagnostic Vendor Specific PLOAM message
not detailed in G984.3.
10.3.13.3 Background Pattern Tests

The background pattern test utilizes the same algorithm as the on-demand Pattern
Test and is disabled by default.
When enabled, the diagnostics will trigger a test under two conditions:
• An ONT ranges
• The background timer expires.
Execution of the background test is scheduled at a configurable interval. The default
background run time interval is 12 hours.

NT
10.3.13.4 Background On/Off Test

This test is also called the background stuck laser test or Background On/Off test.
The test algorithm is the same as the manual on/off test. The test is disabled by
default and is service affecting.
The trigger for this test is a PON LOS event where the RX laser is detected to be on,
corresponding to an ONT continuously transmitting irrespective of its allowed
window
10.3.14 Automatic RF Service Shutdown

ISAM supports the management capability to provision the automatic RF Video
service shutdown function. This capability consists in provisioning a configurable
setting for ONTs supporting the underlying function to use in order to determine the
period of time to assure continued video service for, in case of communication loss
between the OLT and the ONT. RF video service in such ONTs is only restored after
a successful re-range with the OLT.
10.4 V-OLT GPON Functions

V-OLT is an optional network equipment that is used to distribute Radio Frequency
(RF) video signal from service providers to the ONUs. This equipment is not part of
ISAM. The following description of the V-OLT function is provided for informational
purposes.
Note however that occasionally, when fiber and equipment in the GPON network are
shared, a so-called Raman Effect can occur where signals cross over from
downstream digital signals in the lower spectrum and cause visible lines on overlaid
broadcast RF video signals. The effect is usually more prominent in the low end
video channels that are in the 1550 to 1560 nm range.
The ISAM GPON ports provide a Raman crosstalk reduction feature that can be
enabled if distortion, caused by downstream digital data signals on the GPON
network, is visible on the lower spectrum video channels.
10.4.1 Radio Frequency Video Signal Distribution

The V-OLT uses Erbium Doped Fiber Amplifiers (EDFA). The distribution requires a
Wavelength Division Multiplexer (WDM) to be overlaid into the fiber path.

NT
The distribution of the optical video signal is described as follows:

• The V-OLT receives an incoming wavelength optical signal with embedded video
channels through a fiber path from the cable TV head-end equipment.
• The V-OLT amplifies and splits the optical signal into multiple optical feeds to the
video coupler.
• The video coupler merges the video signal over the fiber paths.
• The fiber paths carry the optical signals between the P-OLT and the ONUs.
10.4.2 RF Video Services

The V-OLT supports the full cable television (CATV) spectrum from 47 MHz to 862
MHz.
Access to video services may require a Set-Top Box (STB) between the video output
of the ONU equipment and other Customer Premises Equipment (CPE).
The V-OLT requires a separate Element Management System (EMS) to control
video output signals from the V-OLT equipment.
10.5 Protection
ISAM supports Type-B protection per ITU-T specification G984.1. Refer to
section “Subscriber interface redundancy” in chapter “Failure protection and
redundancy provisions in ISAM” for further information.
10.6 ONU Functions

ONU functions are described in chapter “ISAM Support for the GPON ONU”.

NT

System Description for FD 100/320Gbps NT and FX ISAM Support for the GPON ONU
NT
11 ISAM Support for the GPON ONU

11.1 Introduction
11.1 Introduction
The Optical Network Unit (ONU) in conjunction with the ISAM OLT products work
seamlessly together to form a fiber access network capable of delivering high quality
voice, video, and data services to both single-family or multi-dwelling residential
subscribers and business subscribers
This chapter describes the ONU support in ISAM on a high level. For more details
consult the 7368 ISAM ONT product overview.
Figure 57 ISAM GPON Network Architecture

plan
Optional RF
RF Video router
1,550 nm
provider V-OLT/EDFA
network
Ethernet IPTV
MDU
1,490 nm
WDM 1,550 nm 2.4 Gb/s
Internet 1,310 nm 1.2 Gb/s

Edge switch
router ISAM
PSTN
Voice
gateway
EMS/NMS
Class 5 Softswitch
switch

ISAM Support for the GPON ONU System Description for FD 100/320Gbps NT and FX
NT
11.1.1 P-OLTs and V-OLTs

The P-OLT and V-OLT reside in the central office (CO) or controlled environment
vault (CEV) and provide interfaces between the network and the Gigabit-capable
Passive Optical Network (GPON).
11.1.2 GPON ONUs

The Nokia GPON ONU products are subscriber/customer co-located edge devices
that use GPON technology to extend a fiber optic cable from a P-OLT shelf at a CO
to a subscriber residence, including single-family residences (SFU), multi-dwelling
residences (MDU) such as an apartment building, and small office home office
applications. The ONUs terminate the GPON physical and transmission
convergence layer and provide the specific service interworking function required at
the subscriber residence (for example, High Speed Interface, POTS, DS1 CES and
so on).
The Nokia GPON ONU products provide the following functions and services:
• network demarcation for all services
• voice interworking function from the analog POTS lines to the VoIP/Ethernet
layers
• interworking functions between the GEM and Ethernet layers
• interworking functions between the PON optical overlay and the RF video
interface
• CES encapsulation of DS1/E1 using the MEF-8 packetization format for transport
across the layer 2 Ethernet PON
• mux and demux functions to the PON
• optical to electrical conversion
• located at subscriber residence
All Nokia GPON ONUs were developed using the following GPON ITU-T standards:
• G.984.3 (GPON TC Layer) amendment 1 and 2
• G.984.4 (GPON OMCI)
• G.984.4 (GPON OMCI) amendments 1 and 2

System Description for FD 100/320Gbps NT and FX ISAM Support for the GPON ONU
NT
• G.988 (OMCI)
• OIG Implementers Guide
Note — As already stated in chapter “GPON Network

Architecture”, the term ONT (Optical Network Termination) is
an implementation of the more general used term ONU (Optical
Network Unit). This document uses the general term for all
Optical Network devices
11.1.3 Indoor ONU

The indoor ONU terminates services at the subscriber premises and is used for
subscribers living in single-family residences. The indoor ONU is suitable for
installation on a desktop or for attaching to an interior wall.
11.1.4 Outdoor ONU

The outdoor ONU terminates services at the subscriber premises and is suitable for
single residences and Small Office Home Office (SOHO) applications. The single
residence and SOHO outdoor ONUs have environmentally-hardened enclosures
that can be installed outside the subscriber premises.
11.1.5 MDU ONU

The MDU ONU terminates GPON layer services and is suitable for multi-dwelling unit
(MDU) applications. The MDU ONU supportsVDSL2 interfaces and Ethernet
interfaces that are terminated at the customer's premise.
11.1.6 Business ONUs

All business ONUs are suitable for small business applications and provide voice,
data and IP video, and optional RF video services to subscribers and support CES
DS1 or E1 connections at the business premises.

ISAM Support for the GPON ONU System Description for FD 100/320Gbps NT and FX
NT

System Description for FD 100/320Gbps NT and FX Universal Next Generation PON Network Architecture
NT
12 Universal Next Generation PON

Network Architecture
12.1 Introduction
12.2 Universal NG-PON Network Architecture
12.3 Universal NG-PON Implementation of ISAM
12.4 OMCI
12.5 Time of Day
12.6 Protection on Next Generation PON
12.7 ONU Functions
12.8 Wavelength Multiplexer Functions
12.9 Coexistence Element Functions
12.10 Deployment models for Universal NG-PON
12.1 Introduction
Note — Nokia Universal Next Generation PON (Universal

NG-PON) solution converges the different ITU-T 10G PON
technologies on one platform: XGS-PON (and by extension
XG-PON1) and TWDM-PON.
It allows operators to connect XGS-PON ONUs (10Gbps up /
10Gbps down), XG-PON1 ONUs (2.5Gbps up / 10Gbps down)
and TWDM-PON ONUs (10Gbps up / 10Gbps down or
2.5Gbps up / 10Gbps down) on the same OLT equipment, in
combination with the appropriate OLT optics. The wavelength
bands are defined by the standards such that these
technologies can coexist on the same ODN, even when GPON
is already deployed.

Universal Next Generation PON Network Architecture System Description for FD 100/320Gbps NT and FX
NT
An Optical Distribution Network (ODN) based consists of two main parts that may be
implemented by network equipment that can be categorized as follows:
• Optical Line Termination (OLT):
This unit provides central processing, switching, and control functions. This
equipment is located at the network side of the Optical Distribution Network. Nokia
Universal NG-PON OLT platforms and linecards are capable of supporting
XGS-PON and/or TWDM-PON.
• Optical Network Unit (ONU):
This unit is located at the subscriber premises as distributed end-points of the
ODN. This equipment implements the PON protocol and adapts the PON Protocol
Data Units to subscriber service interfaces.
Note that there is a specific case for ONU equipment that is generally referred to
as Optical Network Termination (ONT). This specific term is generally used to
designate a single-user subscriber premise equipment.
Note — There is a specific case for ONU equipment that is

generally referred to as Optical Network Termination (ONT).
This specific term is generally used to designate a single-user
subscriber premise equipment.
Among the next generation PON technologies, TWDM-PON is the primary

embodiment of ITU's NG-PON2 standard series, G.989. The fundamental
characteristic of TWDM-PON is its multi-wavelength capability, effectively allowing
stacking of four (up to eight) 10G channels. This provides an effective bandwidth on
the PON of a minimum of 40Gbps, extend-able up to 80Gbps (symmetrical). The
ISAM as an NG-PON2 OLT currently supports four different TWDM wavelengths,
allowing to deploy a 40Gpbs symmetric rate.
The XGS-PON technology is a 10-Gigabit-capable symmetric technology, defined in
the G.9807.1 standard. It is essentially a single wavelength version of the
TWDM-PON standard for a 10Gbps up / 10Gbps down rate, where the wavelength
control and management specific to NG-PON2 is inhibited. By definition, an
XGS-PON OLT port is also inter-operable with XG-PON1 ONUs. Coexistence
between XGS-PON ONUs (10Gbps up / 10Gbps down) and XG-PON1 ONUs
(2.5Gbps up / 10Gbps down) through a native TDM scheme in downstream and
TDMA scheme in upstream, combined with a dual-rate support at the OLT receiver.
The ISAM as an XGS-PON OLT supports both single- and dual-rate XGS-PON
deployments, using the default wavelength set of XGS-PON standard.

NT
12.2 Universal NG-PON Network Architecture

In the Nokia Universal NG-PON network architecture, the OLT function is provided
via three distinct equipment types:
• Packet - Optical Line Termination (P-OLT) unit which corresponds to the 7360
ISAM FX and 7362 ISAM DF/SF products.
• Coexistence Element (CEx), a broadband Wavelength Division Multiplexer that is
required in case several PON systems (for example GPON,
XG-PON1/XGS-PON, TWDM-PON) need to coexist on the same ODN via
wavelength overlay. It is used to combine and isolate the different PON signals
onto the same optical fiber (this optional equipment is outside of the scope of
ISAM).
• Wavelength Multiplexer (WM), a narrow-band WDM component that is needed to
combine and isolate the individual TWDM wavelength channels of NG-PON2. It
can handle four or eight wavelengths depending on the model chosen. Nokia WM
device is a separate six RU shelf, housing multiple WM cards. It is only needed
when NG-PON2 is deployed.
Nokia also provides ONU equipment which works seamlessly together with the ISAM
(P-OLT) to form a fiber access network capable of delivering high quality voice,
video, and data services to single-family subscribers, multi-dwelling residential
subscribers and business subscribers
This model is shown in Figure 58.

NT
Figure 58 ISAM Universal NG-PON Network Architecture

plan
1,490 nm
RF Video
1,310 nm
provider GPON
network
Ethernet IPTV 1,577 nm

MDU
CEx
1,270 nm
10 Gb/s
Internet Edge switch 1,596nm - 10 Gb/s,

router ISAM WM 1,603 nm 2.5 Gb/s
1,524 nm -
PSTN 1,544 nm
Voice
gateway
EMS/NMS
Class 5 Softswitch
switch
The Nokia Universal NG-PON solution is developed based on the following ITU-T
standards:
• G.989 (NG-PON2: Definitions, abbreviations and acronyms)
• G.989.1 (NG-PON2 General Requirements)
• G.989.2 (NG-PON2 PMD layer Requirements)
• G.989.3 (NG-PON2 TC Layer Requirements)
• G.9807.1 (XGS-PON specification, including General/PMD layer/TC layer
Requirements)
• G.988 (OMCI Requirements - common for
GPON/XG-PON1/XGS-PON/NG-PON2)
The Nokia Universal NG-PON OLT currently supports a maximum fiber distance and
maximum differential fiber distance of respectively 20 km and 40 km using N1 (29dB)
class optics. 40 km differential fiber distance capability depends on having at least
40 km capable optics.

NT
12.3 Universal NG-PON Implementation of ISAM

The 7360 ISAM FX provides the core processing, switching, and control functions
and interacts in the upstream direction with the aggregation network and voice
gateway using the NT cards. The ISAM shelves with their NT cards, GPON and
Universal NG-PON (XGS-PON and TWDM-PON) linecards comprise the conceptual
P-OLT system from the PON Network point of view.
The Nokia ONU products are edge devices that use a Next Generation PON
technology (XGS-PON, XG-PON1, TWDM-PON) to extend a fiber optic network from
a P-OLT shelf to a subscriber residence.
12.3.1 Transmission Convergence Layer

The TC layer information flow of G.989.3 and G.9807.1 - Annex C is represented in
Figure 59
Figure 59 TC-layer Information flow
User Data OMCI

Client Client
TC Layer
(3)
TWDM TC functions:
PM User Data OMCI
PLOAM Security key mgmt Adapter Adapter
processor ONU power mgmt
TWDM channel mgmt
Protection XGEM Engine
(2)
Upstream
Bandwidth mgmt
AMCC DBA Control FS
framing frame burst
PLOAM
Embedded header fields XGEM partition
partition
(1)
AMCC
PHY burst timing
PHY
and profile control
adaptation
PMD Layer

NT
The sublayer (1) is the PHY adaptation sublayer and encompasses the functions that
modify the bitstream modulating the optical transmitter with the goal to improve the
detection, reception and delineation properties of the signal transmitted over the
optical medium. The sublayer (2) is the framing sublayer, responsible for the
construction and parsing of the overhead fields that support the necessary PON
management functionality. The sublayer (3) is the service adaptation sublayer,
responsible for upper layer service data unit (SDU) encapsulation, multiplexing and
delineation.
In the downstream, the traffic multiplexing functionality is centralized at the OLT. The
OLT multiplexes XGEM frames onto the transmission medium using XGEM Port-IDs.
The XGEM Port IDs delineate the respective XGEM frames that belong to different
downstream logical connections. XGEM frames are carried in the XGEM partition,
and arrive at all the ONUs. The ONU framing sublayer extracts the frames, and the
XGEM TC adapter filters the XGEM fragment based on their 16-bit XGEM Port-ID.
Only frames with the appropriate XGEM Port-IDs are allowed through to the XGEM
client function.
In the upstream, the traffic multiplexing functionality is distributed between the OLT
and the ONU. The OLT controls the upstream bandwidth allocation while the ONU
responds to the allocation by transmitting upstream traffic that is the recipient of the
bandwidth allocation. The XGEM traffic is carried over one or more T-CONTs (traffic
container). One ONU can be served by one or several T-CONTs, but a given
T-CONT can only be used by a single ONU. A given T-CONT can transport traffic
from several XGEM Port-IDs, but traffic from a given XGEM Port-ID can only be
carried by a single T-CONT. The OLT receives the transmission associated with the
T-CONT, and the frames are forwarded to the XGEM TC adapter, and then the
XGEM client.
Both XGEM ports and T-CONTs are internal PON protocol constructs/abstractions
that are not directly exposed to the operator for convenience and ease of
management.
12.3.1.1 Media Access Control

The TC layer in ISAM provides media access control for upstream traffic. The Media
Access Control for Universal NG-PON technologies is represented in Figure 60

NT
Figure 60 Media Access Control concept
Downstream PHY frame Upstream PHY frame
OLT Bitmap
Alloc Start Grant Alloc Start Grant Alloc Start Grant

ID Time Size ID Time Size ID Time Size
Y X 1050
ONU X
Alloc-ID X Alloc-ID 1050
Burst of ONU X
ONU Y
Alloc-ID Y
Burst of ONU Y
The OLT controls and manages the upstream media access for all ONUs on the
PON. The OLT inserts specific ONU upstream bandwidth maps in its downstream
frames. These bandwidth maps indicate the permitted locations for upstream ONU
transmissions. They contain a number of allocation structures, each allocation
structure being addressed to a particular Alloc-ID (associated to a given T-CONT) of
a specific ONU.
For each bandwidth allocation, the OLT sends a start pointer and grant size field in
the PHY frame header. The start pointers and grant size indicate the time at which
the respective ONU must begin and end its upstream transmission. In this way, only
one ONU can access the PON at any time, and there is no contention in normal
operation. The start pointers and grant sizes are expressed in units whose
granularity depend on the upstream line rate of the target ONU: one word (4 bytes)
for an ONU transmitting at 2.48832 Gbps in upstream, and one block (16 bytes) for
an ONU transmitting at 9.95328 Gbps in upstream.
The duration of a PHY frame is always 125 µs. The downstream payload contains
XGEM frames that are uniquely destined to a specific ONU. The ONUs will examine
all of the XGEM headers and only process the XGEM frames with port-IDs that
belong to it. In the upstream direction, each ONU transmits a series of relatively short
PHY bursts and remains silent, disabling the transmitter, in-between the bursts.
Upstream frames are synchronized with downstream frames as outlined in
Figure 60.
12.3.1.2 Upstream and Downstream Frames

Figure 61 shows downstream frame format for next generation PON technologies.

NT
Figure 61 Downstream Frame format

Downstream PHY frame, 125 µs
24 bytes 155496 bytes
PSBd PHY frame payload PSBd PHY frame payload

OLT
Downstream PHY frame at ONU i
ONU X
Downstream PHY frame at ONU j
ONU Y
Downstream XGTC frame, 135432 bytes
XGTC
XGTC payload
header
HLend BWmap PLOAMd
BWmap length PLOAM count HEC

11 bits 8 bits 13 bits
Figure 62 shows the upstream frame format (with FEC enabled) for next generation
PON technologies.

NT
Figure 62 Upstream Frame Format

PHY burst PHY burst PHY burst
PSBu PSBu
PSBu
Upstream PHY frame, 125 µs Upstream PHY frame, 125 µs
Upstream XGTC burst
XGTC Upstream Upstream XGTC

...
header allocation allocation trailer
232 bytes 232 bytes L < 232 bytes
Data bytes of Data bytes of Data bytes of

...
Codeword #1 Codeword #l last codeword
Data bytes of Data bytes of Data bytes of

PSBu Parity ... Parity Parity
Codeword #1 Codeword #l Codeword #l
232 16 232 16 232 16
Codeword #1 Codeword #K Last (short) codeword
Upstream PHY burst
12.3.1.3 XGEM Encapsulation of Ethernet Packets

The Universal NG-PON technologies support two modes of operation : "Ethernet
over XGEM" mode and "MPLS over XGEM" mode. The ISAM Universal NG-PON
platform supports the "Ethernet over GEM" multiplexing.
Ethernet packets are encapsulated by ISAM and ONUs into XGEM frames as shown
in Figure 63. Each packet is mapped into an XGEM frame. The Preamble and SFD
bytes are not included in the XGEM frame.
Nokia Universal NG-PON solution supports Jumbo Ethernet Frames up to a
maximum payload size of 9190 bytes (assuming a 26-byte overhead in case of QinQ,
for a total frame size of 9216 bytes).

NT
Figure 63 Ethernet encapsulation over XGEM

Ethernet frame XGEM frame
PLI KI
12 Inter-packet gap
XGEM Port-ID
8
Options
7 Preamble
LF
1 SFD HEC
6 DA
6 SA
2 Length/type
N + 18
XGEM Payload
N MAC client data
4 FCS
Padding 0-3
Each produced XGEM fragment is transmitted contiguously.

An SDU fragmentation may occur when the data available to be transmitted in the
upstream or downstream direction needs to be partitioned in two or more XGEM
frames. Figure 64 shows an example of such SDU fragmentation.
Figure 64 Fragmentation Example
SDU
SDU SDU
fragment A fragment B
XGEM XGEM XGEM XGEM

header payload header payload
XGEM frame A XGEM frame B

Dynamic Bandwidth Assignment (DBA) is the process by which ONUs and their
associated Transmission Containers (T-CONTs) get their upstream bandwidth
dynamically allocated (either implicitly through monitoring of idle cells during
upstream bursts at the OLT - also known as Traffic-monitoring or TM-DBA - or
explicitly through buffer occupancy reporting from ONUs to OLT - also known as
Status-reporting or SR-DBA) and whereby the OLT reassigns upstream bandwidth
accordingly.

NT
The DBA mechanism improves the upstream bandwidth utilization by reacting

adaptively to the ONUs' burst traffic patterns. DBA uses T-CONTs to manage the
upstream bandwidth allocation in the PON section of the Transmission Convergence
layer.
The ISAM bandwidth reassignment is applied to the distribution of the
non-guaranteed (un-assured and un-committed) portion of the service traffic in order
not to disturb the guaranteed traffic contracts. The ISAM, as Universal NG-PON OLT,
supports TM-DBA as well as SR-DBA.

The ISAM Universal NG-PON ports support both Upstream and Downstream FEC.
Forward Error Correction (FEC) is used by the ISAM transport layer on XGS-PON
and TWDM-PON. Both Downstream and Upstream FEC is active by default, as this
is generally needed in order to meet the optical link budgets. Additionally, both
Downstream and Upstream FEC can be statically disabled, although significant
impairment to the upstream link is likely to happen, specifically in TWDM-PON. It is
therefore not advised to disable FEC on TWDM-PON unless the link is significantly
lower loss than the applied optical budget class (low split, short distance etc.). Note
that the XGS-PON standard requires FEC to always be enabled in the downstream.
FEC is based on transmitting the data in an encoded format. The encoding
introduces redundancy, which allows the decoder to detect and correct the
transmission errors. By using the FEC technique, data transmission with low error
rate can be achieved, and retransmissions are avoided.
The FEC encoding and decoding is based on Reed-Solomon codes (Block based
FEC). Reed-Solomon (RS) is a Block based code, which takes a data block of
constant size and adds extra 'redundant' bits at the end, thus creating a codeword.
Using those extra bits, the FEC decoder processes the data stream, discovers
errors, corrects errors, and recovers the original data. Reed-Solomon code is
specified in CMTT recommendation CCIR 723.
When using a block-based FEC, original data is preserved. Therefore, by ignoring
the parity bits, even if the other side does not support FEC, the original data can be
processed.
12.3.4 Delay Tolerance

For the upstream transmission, ISAM provides a configurable Delay Tolerance
parameter to realize optimal latency and delay variation characteristics on the
Universal NG-PON link.

NT
12.3.5 Security
The ISAM Universal NG-PON system is protected by two different types of security
features: Authentication and Advanced Encryption Standard (AES).
12.3.5.1 Authentication
Authentication security includes the use of Registration-ID, executed in the course of
ONU activation. Upon authentication failure, the OLT may undertake measures to
restore functionality and to prevent a potential security breach, which may include
repeating authentication using the same or alternative mechanism, blocking
upstream and downstream traffic, deactivating or disabling the offending ONU. This
registration-based authentication mechanism provides a basic level of authentication
of the ONU to the OLT.
Additionally, the PLOAM (Physical Layer Operation, Administration and
Maintenance) messaging channel is verified and protected by the use of the 8-byte
Message Integrity Check (MIC) field of the PLOAM message format. The MIC field
of the PLOAM message format is generated using the cipher-based message
authentication code (CMAC) algorithm specified in [NIST SP800-38B] with AES-128
encryption algorithm [NIST FIPS-197] as the underlying block cipher.
Additionally, the OMCC is verified and protected by the use of the 4-byte Message
Integrity Check (MIC) field of the OMCI message format. The MIC field of the PLOAM
message format is generated using the cipher-based message authentication code
(CMAC) algorithm specified in [NIST SP800-38B] with AES-128 encryption algorithm
[NIST FIPS-197] as the underlying block cipher.
12.3.5.2 Payload encryption

XGEM payloads can also be encrypted for transmission to provide data privacy in the
presence of a potential eavesdropping threat. The algorithm used for this encryption
is AES-128. AES can be enabled/disabled for individual XGEM port-IDs in
conformance with the standard. XGEM payload encryption may apply for any unicast
transmission in the downstream and upstream directions, and to one specified
multicast service stream for the downstream broadcast transmission. The OLT
ensures that at all times there is a PON-wide broadcast key pair which is used for the
broadcast XGEM Port-ID and there is a unicast key pair for each ONU which is used
for all the XGEM Port-IDs that belong to that ONU.
The encryption algorithm to be used is the Advanced Encryption Standard (AES). It
is a block cipher that operates on 16 byte (128 bit) blocks of data. The secure key
derivation procedure employs the cipher-based message authentication code
(CMAC) algorithm specified by the National Institute of Standards and Technology
(NIST-SP800-38B), with the AES encryption algorithm [NIST FIPS-197] as the
underlying block cipher.

NT
There are several modes of operation for this AES standard. The ISAM supports the
"Counter" (CTR) mode, where the cipher generates a stream of 16-byte
pseudo-random cipher blocks which are XOR-ed with the input clear-text to produce
the output of cipher-text. The cipher-text is XOR-ed with the same pseudo-random
cipher blocks to regenerate the clear-text. The key length is fixed at 128 bits.
12.3.6 ONU Ranging and Discovery

When ISAM is ranging new ONUs, working ONUs must temporarily stop
transmissions. The ISAM OLT can discover new ONUs by opening a ranging
window, during which already activated ONUs are not allowed to transmit in the
upstream.
Two activation/ranging methods supported by ISAM:
• Configured-S/N:
The serial number of the ONU is registered in advance at the OLT (for example,
it was provisioned by the operator). In case an ONU with a serial number that is
not yet registered in the OLT is detected, it is declared as an "unexpected" ONU
by the ISAM.
• Discovered-S/N:
The serial number of the ONU is not registered at the OLT. It requires an
automatic detection mechanism of the serial number of the ONU based on an
operator-assigned Registration-Id (REG-ID) that is provisioned locally at the ONU
and at the ISAM for a match. In case a new ONU is detected, an ONU-ID is
assigned and the ONU is activated. The ISAM Universal NG-PON platform
currently supports a 10-byte REG-ID (that is SLID) as opposed to a standard
36-byte REG-ID provisioned locally at the ONU.
There are two triggers for initiating the activation of an ONU:

• The network operator enables the activation process to start when it is known that
a new ONU has been connected.
• The OLT periodically initiates the activation process, testing to see if any new
ONUs have been connected. The frequency of polling is programmable.
12.3.7 ONU Activation

The activation process is performed under the control of the OLT. The ONU
responds to messages, which are initiated in the OLT.
The activation process consists of three primary phases:
1) Synchronization phase:
ONU synchronizes to the downstream PHY frame, while its transmitter is turned off.

NT
2) Serial number acquisition phase:

• ONU learns the burst profile parameters to be used for upstream transmissions.
• ONU announces its presence on the PON by responding to serial number grants.
A serial number grant is an allocation structure that is addressed to the broadcast
Alloc-ID and has the PLOAMu flag set.
• OLT discovers a new ONU by its serial number and assigns a unique ONU-ID to
the ONU.
3) Ranging phase:
• ONU responds to directed ranging grants. A ranging grant is an allocation
structure that is addressed to the default Alloc-ID of the ONU and has the
PLOAMu flag set.
• OLT measures round-trip delay, the ONU calculates respective equalization delay
(EqD), and communicates it to the ONU.
• ONU adjusts the start of its upstream PHY frame clock based on equalization
delay received from OLT
• ONU completes activation; regular operation proceeds
• This procedure is performed by the exchange of upstream and downstream flags
and PLOAM messages.
In the normal operating state, all transmissions can be used for monitoring the phase
and BER of the arriving transmission. Based on monitoring transmission phase
information, the equalization delay can be updated dynamically by OLT.
Since the Serial-Number request is broadcast to all ONUs in the Serial-Number
state, a response from more than one ONU might be produced. A problem may occur
when more than one Serial-Number transmission arrives at the same time at the
OLT, thus causing a collision. The Random Delay Method is used to resolve this
problem.
Based on the Random Delay Method, each Serial-Number transmission is delayed
by a random number of delay units generated by each ONU. Following each
response to a Serial-Number request, the ONU generates a new random number,
thus collisions are easily and efficiently prevented.
The Random delay range is measured from the beginning of the earliest possible
transmission to the end of the latest possible transmission.
12.3.8 ONU wavelength (re-)assignment (NG-PON2

specific)
The TWDM-PON ONUs are equipped with tunable transceivers and have thus the
ability to re-tune among the different wavelength pairs available on the TWDM-PON
system. Currently, up to four different pair of wavelengths (couples of downstream
and upstream wavelengths) can be deployed on a single channel group.

NT
Except during their activation process or in case of protection switching, ONUs that
are in service on a given channel-pair don't decide to re-tune autonomously: they
typically follow instructions from the OLT, that are conveyed via standardized
Tuning_Control PLOAM messaged. The decision to force a given ONU to re-tune to
a different wavelength pair than its operating one can be driven by different factors,
for instance, equalize the number of end-subscribers on the channel-pairs, equalize
the bandwidth utilization on the channel-pairs, re-group ONUs on a channel-pair to
allow maintenance actions affecting the other channels and so on.
Moving an ONU from a channel-pair to another can be the result of a decision logic
algorithm implemented at the Management Layer (typically referred to as a
Wavelength Mobility Manager, cf. BBF WT-352); but it can also be an
operator-triggered action.
In this release, the ISAM 7360 FX only supports individual ONU wavelength
re-assignment between two channel-pairs hosted by two TWDM-PON OLT ports
situated on two different linecards.
The ONU movement sequence can be triggered via the OLT Management Interface
and always targets a specific ONU.
12.3.9 Transmission Convergence Layer Performance

Monitoring
The ISAM supports on-demand XGEM PM counters at the OLT side of the PON.
On-demand XGEM PM counters at the ONU side of the PON are not supported in
the initial release.
On-demand PM counters monitor TC layer traffic and performance. The related
counters are collected internally on a XGEM-port basis from both ends of the PON
section and are presented to the operator on a per-ONU and per-UNI basis. In
addition, the same set of counters is also supported for the shared Multicast XGEM
port of the PON.
12.3.10 Power Management Mode

Efficient power realization of ONUs is an evolutionary trend for which the industry is
moving towards. Two TC layer power down modes are defined by the standards:
• Doze mode (Listen mode):
The ONU receiver is on; the transmitter is off. The ONU listens to the downstream
signal and forwards downstream traffic, while retaining the ability to reactivate the
transmitter on local stimulus or receipt of Sleep Allow (SA) PLOAM OFF from the
OLT.

NT
• Cyclic Sleep mode (Asleep mode):

The ONU shuts down both its receiver and transmitter, retaining the ability to
wake up on local stimulus.
Note — The ISAM currently does not support the Power

Management modes of operation.
12.4 OMCI
The ONU Management and Control Interface (OMCI) is the ITU-T G.988-based open
surveillance related functions between ISAM and ONUs via the ONU Management
and Control Channel (OMCC). This layer is common across the different ITU-T PON
technologies.
12.5 Time of Day

An accurate ToD method of synchronization between the OLT and ONU is defined
in the TC Layer of the XGS-PON and TWDM-PON specifications.
The OLT informs the ONU of the Time of Day when a certain downstream PHY frame
would arrive at a hypothetical ONU that had zero equalization delay and zero ONU
response time (that is, at a loop length of zero). This certain downstream frame is
identified by N, the value of its superframe counter.
The OLT informs the ONU of the ToD arrival via the OMCI channel, which does not
need to be in real-time. Once the ONU has learned the ToD arrival time of frame N,
the ONU can use its equalization delay and response time to compute the ToD
associated with the arrival of an arbitrary downstream frame with very high accuracy.
Once the ONU has learned the ToD arrival time of frame N, the ONU can use its
equalization delay and response time to compute the ToD associated with the arrival
of an arbitrary downstream frame with very high accuracy.
Note — ToD transport is currently not supported on the

Universal NG-PON technologies

NT
12.6 Protection on Next Generation PON

Various types of protection are possible with Universal NG-PON equipment.
• The ISAM, as an NG-PON2 OLT, currently supports wavelength protection across
LTs with ONU involvement (re-tuning to a pre-defined protection wavelength).
• On XGS-PON, Type-B protection is the most common fiber protection scheme.
It is also supported on ISAM.
For more information about the Protection Schemes supported by the ISAM OLT,
please refer to Chapter “Failure protection and redundancy provisions in ISAM”.
12.7 ONU Functions

ONU functions are generally described in chapter “ISAM Support for the GPON
ONU”.
12.8 Wavelength Multiplexer Functions

In NG-PON2, the WM is used to combine and isolate the individual TWDM
wavelength channels associated with the TWDM signal.
The downstream (from OLT to ONU) 100GHz spaced channels are WDM combined
and output to the coexistence element, or directly to the PON, depending on
configuration.
Similarly the 100GHz spaced TWDM wavelength channels for upstream (from ONU
to OLT) are separated by the WM and output to the individual optical ports on the
P-OLT.
The WM is required when more than one TWDM wavelength channel within one
ODN is deployed.
12.9 Coexistence Element Functions

The CEx is used to combine and isolate TWDM-PON and/or XGS-PON ports with
other PON ports or optical systems. Unlike the WM, which is a DWDM type device,
the CEx is a broader band device, more similar to a CWDM type of WDM.
Depending on the presence of other optical systems, the CEx is optional to deploy.
If future evolution to XGS-PON and/or TWDM is anticipated, then placing a CEx at
the beginning of a PON deployment allows these technologies to be added later
without impacting the ODN.

NT
Nokia is not developing a CEx unit, but has provided certain industry partners with
CEx specifications developed by Nokia for use in XGS-PON and TWDM-PON
systems. Two definitions have been developed: a basic CEx that facilitates
coexistence with GPON, XG-PON1/XGS-PON, and TWDM-PON; and an Enhanced
CEx that also adds capabilities for PtP WDM PON and External (1650nm) OTDR.
12.10 Deployment models for Universal NG-PON

The following section gives an overview of the possible deployments models
supported by Nokia is Universal NG-PON platforms:
• ISAM as an XGS-PON OLT, equipped with dual-rate capable XGS-PON OLT
optics:
• Scenario 1: coexistence of XGS-PON (10Gpbs/10Gbps capable) ONUs and
XG-PON1 (10Gbps/2.5Gbps capable) ONUs on the same PON through TDM/TDMA
and dual-rate support at the XGS-PON OLT port
• Scenario 2: pure 10Gpbs/10Gbps deployment, with XGS-PON ONUs connected to
the XGS-PON OLT port (first particular case of scenario-1)
• Scenario 3: pure 10Gpbs/2.5Gbps deployment, with XG-PON1 ONUs connected to
the XGS-PON OLT port (second particular case of scenario-1)
• ISAM as an XGS-PON OLT, equipped with 10Gpbs/10Gbps symmetrical-only
XGS-PON OLT optics:
• Scenario 4: pure 10Gpbs/10Gbps deployment, with XGS-PON ONUs connected to
the XGS-PON OLT port (same as above scenario 2, but with a different OLT optics).
For pure 10Gpbs/10Gbps deployments, Nokia recommends to follow scenario 2.
• ISAM as a TWDM-PON OLT, equipped with TWDM-PON OLT optics :
• Scenario 5: pure N x 10Gpbs/10Gbps deployment, with 10Gpbs/10Gbps capable
TWDM-PON ONUs connected to the 10Gpbs/10Gbps capable TWDM-PON OLT
port (N = number of TWDM-PON wavelengths deployed)
• Scenario 6: pure N x 10Gpbs/2.5Gbps deployment, with 10Gpbs/2.5Gbps capable
TWDM-PON ONUs connected to the 10Gpbs/2.5Gbps capable TWDM-PON OLT
port (N = number of TWDM-PON wavelengths deployed)
With Nokia Universal NG-PON solution operators can migrate from one deployment
scenario to the other without needing to change the OLT equipment, simply by
adapting the type of optical module used at the OLT.

System Description for FD 100/320Gbps NT and FX Integrated Voice Service
NT
13 Integrated Voice Service

13.1 Introduction
13.2 Supported Features per Product
13.3 Overall network topology
13.4 Voice cluster topology
13.5 Product Definition and Dimensioning
13.6 Traffic types and forwarding
13.7 Layer 2/layer 3 addressing topologies
13.8 Protocol stacks
13.9 Management interface
13.10 Permanent data storage
13.11 Management model
13.12 SIP Integrated Voice Service: Shared Line Connection
13.13 H.248 Integrated Voice Service: Shared Line Connection
13.14 Number Manipulation Rules
13.15 Reliability, Equipment / Connectivity / Overload Protection
13.16 Multiple Voice Service Gateway
13.17 Licensed Voice Service Features
13.18 Combo DSL - Naked DSL Line
13.19 Quality of Service
13.20 DHCP Interworking
13.21 DNS interworking
13.22 BITS Support

Integrated Voice Service System Description for FD 100/320Gbps NT and FX
NT
13.24 Subscriber Line Showering
13.25 Lawful Intercept
13.26 Voice Traffic Mirroring
13.27 Integrated Voice Service migration
13.1 Introduction
The integrated VoIP service provides classic telephony services to subscribers being
connected with classic POTS or ISDN BRA / ISDN PRA / CAS R2 lines and to
convert the corresponding signals to VoIP signaling and data packets.
The integrated VoIP service provides POTS or ISDN BRA or ISDN PRA or CAS R2
service to subscribers over copper and fiber together or without xDSL service.
The voice information is converted to VoIP in the access device and forwarded to and
from the service provider's Ethernet and IP network over optical fibers along with the
HSI and IPTV services carried by the access device
VoIP networks are subject to standardization. Within standardization there are two
different approaches for the signaling:
• A set of standards driven by ITU-T, centered around ITU-T document H.248. In a
nutshell: a network based on this standard uses RTP for the voice and Megaco
for the signaling.
• A set of standards driven by IETF SIP. In a nutshell: a network based on this
standard uses RTP for the voice and SIP for the signaling.
The Integrated VoIP Service supports both signaling methods and can be deployed
in the corresponding network topologies.
In addition, the integrated VoIP service supports CESoPSN (Cicuit Emulation
Service over Packet Switched Network). That is a method for encapsulating
structured (PW3: NxDS0) Time Division Multiplexed (TDM) signals as pseudowires
over packet-switching networks (PSNs).
Note 1 — Voice over Broadband (VoBB) is not in the scope of
this "Integrated Voice Service" Chapter.
Note 2 — The "Integrated Voice Service" chapter describes the
behaviour and characteristics of the POTS and ISDN ports
associated with the ALU access devices offering the integrated
voice service.

NT
13.2 Supported Features per Product

The following chapters generically describes different features. This table lists the
currently supported features.
Table 23 Supported Features
Integrated Voice Service 7302 ISAM

7330 ISAM FTTN
7360 ISAM FX
Standalone node Yes
Subtending node Yes
H.248 : Switched Model Yes
H.248 : Routed Model Yes

H.248 : MG at Virtual server board Yes (Multi-core NT only)
H.248 : MG at Physical server board Yes
SIP : Switched Model Yes
SIP : Routed Model Yes
SIP : POTS interface Yes
SIP : ISDN PRA interface Yes
SIP : CAS/R2 interface Yes

H.248 : POTS interface Yes
H.248 : ISDN BRA interface Yes (not for 7360 ISAM FX)
H.248 : Voice Cluster Topology Yes

SIP : Individual Access Node Topology Yes
SIP : Centralized IP architecture Yes
SIP : Distributed IP architecture Yes
H.248 : Centralized IP architecture Yes
H.248 : Transport Protocol = UDP Yes
SIP : Transport Protocol = UDP Yes
SIP : Transport Protocol = TCP Yes
Downstream L4 forwarding Yes
Internal node hairpinning Yes
Voice Daisy Chaining: U2U communication supported (Hub-Subtending and Yes

Subtending-Subtending Topology)
H.248 Distinct VLAN Topology Yes
H.248 Shared VLAN Topology Yes
H.248 Private VLAN Topology Yes
(1 of 3)

NT

7330 ISAM FTTN
7360 ISAM FX
SIP Distinct VLAN Topology Yes
SIP Shared VLAN Topology Yes
H.248 Signaling Protocol Stack Yes
SIP Signaling Protocol Stack Yes
XLES Signaling Protocol Stack (H.248) Yes
Media Protocol Stack Centralized IP@ Architecture Yes
Media Protocol Stack Distributed IP@ Architecture Yes
H.248 Voice Service & DHCP No
SIP Voice Service & DHCP Yes (Distributed IP address

Architecture with Shared
VLAN approach)
SIP: SIP Server Redundancy / Fail-Over / Fail-Back Yes
SIP: GEO Redundancy / Geo Fail-Over / Geo Fail-Back Yes
SIP: ESA Redundancy / ESA Fail-Over / ESA Fail-Back Yes
SIP: LSA SIP Server / LSA Fail-Over / LSA Fail-Back Yes (7356 supports FO to/ FB
from LSA server but cannot
host LSA server)
SIP: LSA Server & Emergency Call Service Licensing Yes

SIP: LSA Server at Virtual server board Yes (Multi-core NT only)
External Path Forwarding Yes (SHUB only)
Voice Traffic Mirroring Yes (SHUB only)
H.248 : Quality Of Service Yes
SIP: Quality Of Service Yes
H.248: DNS Interworking No
SIP: DNS Interworking Yes
CDE profile Yes
Single SIP Service Profile SIP only
Multiple SIP Service Profile SIP only (Max 5,

POTS service only)
Multiple Service Gateway Yes (16 VSP/VAG)
Multiple Service Gateway Licensing Yes
SIP: Shared line Connection Only supported on 7302/7330

with NANT-A or NANT-D
H.248: Shared line Connection Only supported on 7302/7330

with NANT-A or NANT-D
SIP: Number Manipulation rules Yes (POTS, ISDN and CAS

R2)
(2 of 3)

NT

7330 ISAM FTTN
7360 ISAM FX
Encapsulation of structured (PW3: NxDS0) Time Division Multiplexed (TDM) Yes

signals as pseudo wires over packet switching networks (PSNs) supporting
CESoPSN
Multiple Voice Access Gateway (VAG) Yes (7302 and 7330))

SIP only
Max 16
IF-MIB support Yes (7302 FD)
Naked DSL user (H.248) Yes
FO/FB/DU alarm (SIP) Yes (7302 and 7330)
(3 of 3)
13.3 Overall network topology

This section describes the overall network topologies for an access node offering:
• H.248 signaling based Integrated Voice Service situated in a Next Generation
Voice Network (NGVN).
• SIP signaling based Integrated Voice Service situated in a non-TISPAN and
TISPAN-compliant NGN-IMS network.
13.3.1 Megaco Integrated Voice Service in a NGVN

network
The Megaco Integrated Voice Service supports Narrowband (NB) services and
provides the connection to the NGVN for legacy Public Switching Telephone Network
(PSTN) users via Voice over IP (VoIP). It plays the role of Media Gateway (MG), also
called Access Media Gateway (AG).

NT
Figure 65 7302 ISAM/7330 ISAM FTTN/ISAM 7360 FX: NGVN Network

Architecture
Subtending
ISAM Voice
Softswitch
PSTN
RTP
TGW P I
MGC ASP O S
T D
S N
Central Office
ISAM Voice POTS /
Servers ISDN
IP Network
H.248 / SIGTRAN
. P
O
T
L2 Aggregation M
S
IP G
BAS Network
edge
POTS/
ISDN
Remote
ISAM Voice
P I
P I O S
O S T D
T D S N
S N
POTS/ POTS/
ISDN ISDN
Remote
ISAM Voice
Megaco Integrated Voice Service connects legacy Narrow Band (NB) user
interfaces, including Plain Old Telephone Services (POTS) and Integrated Services
Digital Network (ISDN) BRA, to the NGVN.
Megaco Integrated Voice Service supports centralized configurations, where the NB
user interfaces and MG are integrated in the same access node, and distributed
configurations, where the MG is located in a hub access node and the NB user
interfaces in remote access nodes. The remote access nodes can be subtended to
the hubb access node acting as an MG, or located within the layer 2 aggregation or
IP network.
A voice cluster is the aggregation of a Voice packet server (pair), residing in the hub
access node, together with its voice associated access nodes, that is, together with
the access nodes that contain Voice Line Termination (LT) boards that are managed
by that particular Voice packet server (pair). A voice cluster supports maximum 5K
subscribers. These subscribers may be scattered over maximum 32 access nodes
and maximum 104 Voice LT boards.
An access node can be equipped with:
• one or multiple physical voice packet servers running in simplex mode,
• one or multiple pairs of physical voice packet servers running in full redundant
active/standby mode,
• one virtualized voice packet server running in simplex mode,
• a pair of virtualized voice packet servers running in non-redundant active/standby
mode.

NT
The physical voice packet server requires a single dedicated physical board or a pair
of dedicated physical boards to be planned and inserted at the LT slot position, at
which the H.248 MG SW image is downloaded and running.
In case of an active/standby configuration, hitless redundancy is supported between
the active and standby physical voice packet server board.
Up to eight physical voice packet servers running in simplex mode or up to eight pairs
of physical voice packet servers running in full redundant active/standby mode can
be planned in an access node (the hub access node). Or in other words, a hub
access node may be the hub node for up to eight different Voice Clusters.
The physical voice packet server supports a voice cluster with maximum 5K
subscribers and these subscribers may be scattered over maximum 32 access
nodes and maximum 104 voice LT boards.
The virtualized voice packet server requires a single dedicated virtual board or a pair
of dedicated virtual boards to be planned on top of the present multi-core NT
configuration, at which the H.248 MG SW image is downloaded and running.
In case of a simplex multi-core NT configuration, the H.248 MG runs also in simplex
mode.
In case of an active/standby multi-core NT configuration, the H.248 MG may run in
simplex or 'paired' mode. 'Paired' mode means that in case of an NT switch-over, the
H.248 MG service can be continued, however the service starts again from its
initialization phase since the MSAN does not support redundancy between the active
and the standby virtualized voice packet server board.
Only one virtualized voice packet server (pair) can be planned in an access node and
supports a maximum of 1.2K subscribers all hosted at the local access node (with
maximum 16 LT boards).
The key benefit of this virtualized voice packet server board is that it allows for a
higher density (there are no longer LT slots required to plan and insert the voice
packet server).
From a H.248 MG point of view, full feature parity is guaranteed between the
virtualized and physical voice packet server for POTS subscribers.
The virtualized voice packet server does not support the ISDN BRA service.
In subsequent chapters the generic term 'voice packet server’ will be used and the
voice packet server will be shown as a separate logical block in all drawings.
The hub access node, combined with the subtending and remote access node(s),
provides the view of a unique centralized MG. In subtending or remote
configurations, the connection to the hub is via Fast or Gigabit Ethernet (optical or
electrical). The Trunk MG links the NGVN with a legacy PSTN network.
The Softswitch is responsible for call control and charging, and communicates with
the Media Gateways (Megaco Integrated Voice Service) via the Media Gateway
Control (Megaco) protocol H.248.

NT
SIGTRAN is used for ISDN BRA users, that is, Q921 is terminated in the access node
and SIGTRAN is implemented to transfer Q931 messages transparantly between the
access node and the ASP.
13.3.2 SIP Integrated Voice Service in a TISPAN-compliant

NGN-IMS network
SIP Integrated Voice Service is a ETSI TISPAN PES compliant VGW.
The ALU IMS PES Solution is a PSTN Emulation IMS subsystem specifically tailored
to allow TDM equipment replacement, while keeping legacy terminals unchanged. It
is based on TISPAN IMS-PES functional Architecture and provides
• Access for legacy POTS-line towards an IMS network through Access gateways
• Access for ISDN PRA-line towards an IMS network through Access gateways
• Access for ISDN CAS R2-line towards an IMS network through Access gateways
• A PSTN Service emulation in the IMS domain
• Interconnection with PSTN networks
• Interconnection with peer IP networks
The SIP based Voice gateway (VGW)

• Terminates the z-interface (z Reference point)
• Terminates the E1
• Directly connects to the IMS-core (P_CSCF)
• Associates POTS / ISDN PRA /CAS R2 lines with an IMS user identity
• REGISTERS each user at the IMS-core.
• Media conversion Voice-band => RTP packets
• Interacts with the AS based on the tightly coupled model

NT
Figure 66 The TISPAN IMS-PES functional architecture
Application Servers Rf/Ro

Ut
Rf/Ro
Ut Other types of service logic Charging
PSTN/ISDN Emulation logic
Functions
Network Sh Rf/Ro
Attachment ISC/Ma Dh
UPSF SLF
Iw
Subsystem Cx Dx IWF
P3 Ib
IMS-based PES
e2
e2 AGCF M Mx
w
IBCF Ic
Mw I/S-CSCF Mx
Mi Mk
P1 BGCF
Mw Mr
Other IP Networks
Mj Gq'
Gm Mx
SIP/Gm P-CSCF Mg
SGF
MRFC MGCF Ie
PSTN/ISDN
Gq' Gq'
Ut Mp Mn
Resource and Admission Control Subsystem
VGW
Z MRFP T-MGF
IP Transport (Access and Core) I-BGF

MG
Z
Figure 67 The TISPAN IMS-PES Solution

5020 MGC - 8
5020 MGC - 12 5420 CTS
5020MGC - 10
ISUP
Feature 5450 ISC 8650 SDM
SIP
SS7 Server
PSTN MGCF Session Control HSS

SIP
MGW H.248
Voice IP Network 7342
7302 ISAM 7302/
7510 MGW VGW ISAM OLT 7330
7515 MGW SIP
7520 MGW ISAM
3rd party IP Access
VGW
7330 SIP
SIP
ISAM SIP
TDM Access FTTN
ONT
PRA, GR-303,
PRI TR-08, ONT
V5.2 RG
RG
The SIP based Voice Network architecture :

NT
Figure 68 7302 ISAM/7330 ISAM FTTN/7360 ISAM FX: TISPAN IMS-PES

Network Architecture
DHCP
Mgmt DN S
Se r ve r
Pla tfo r m Se r ve r
PSTN
SG F/ T-MG F
S_CSCF
MG CF ISAM Voice
AS I_CSCF
P P U
O O A
P_CSCF RTP T T
S S
POTS
HSS ISAM Voice

SIP
SBC
IMS
ER P P U
Co r e IP O O A
MRF T T
N e two r k S S
Vo ice L2 Ag g r e g a tio n POTS
x- CSCF/ BG CF
G a te wa y
N e two r k
IBCF/ IBGF
ISAM Voice
ER
O th e r IP P
O
P U
O
T A
Networks Se rve rs
T
S S
ISAM Voice POTS
P I PBX
O SU POTS
T DA
S N
BAS
ISDN PRA (E1)
Each of access the nodes connected to the layer 2 aggregation or IP network has the
SIP UA locally integrated on the Voice LT. The local instance of the SIP UA serves
all NB user interfaces connected to a Voice LT.
The Call Session Control Function (CSCF) establishes, monitors, supports and
releases multimedia sessions and manages the user's service interactions. The
CSCF can act as Proxy CSCF (P-CSCF), Serving CSCF (S-CSCF) or Interrogating
CSCF (I-CSCF):
• The P-CSCF is the first contact point for the access node within the IM subsystem
(IMS).
• The S-CSCF fulfils the role of registrar and handles the session states in the
network.
• The I-CSCF is mainly the contact point within an operator's network for all IMS
connections destined to a subscriber of that network operator, or a roaming
subscriber currently located within that network operator's service area.
The Home Subscriber Server (HSS) is a master user database that supports the IMS
network entities that handle calls. It contains the subscription-related information
(user profiles), performs authentication and authorization of the user, and can
provide information about the user's physical location.

NT
Interconnection with legacy PSTN networks is guaranteed at the signaling level via
the Signaling Gateway Function (SGF) (transport) and the Media Gateway Control
Function (MGCF) (call and service control). Interconnection at the media level is
provided by the Trunk Media Gateway Function (T-MGF).
Interconnection with other IP-based service subsystems (including other IMS
subsystems) is performed via the Intermediate Breakout Control function (IBCF) at
the signaling level and the Interconnection-Border Gateway Function (I-BGF) at the
media level.
Very often, to support lawful intercept, Voice traffic is switched along the Legal
Intercept gateway.
13.3.3 SIP Integrated Voice Service in a

non-IMS-compliant network
SIP Integrated Voice Service supports the Narrowband (NB) services and provides
the connection to an IMS-like New Generation Network (NGN) for legacy PSTN
users via Voice over IP (VoIP).
The access node plays the role of Voice Gateway (VGW) and can interface with
voice feature servers acting as back-to-back SIP Servers via the SIP protocol.
Figure 69 SIP Integrated Voice Service in a non-IMS-compliant network
Management
DHCP server
Platform
ISAM
Voice
DHCP
SNMP/
CLI/TL1 P I
O S POTS
IP T D
S N
ISDN
SIP PRA
(E1)
RTP / RTCP PBX
Media
Gateway Back-toBack
server
The access node connects legacy Narrow Band (NB) user interfaces, the Plain Old
Telephone Services (POTS) and/or ISDN PRA and/or CAS R2, to a non-IMS
compliant network.
Each of the access nodes connected to the IP network has the SIP UA locally
integrated on the Voice LT. The local instance of the SIP User Agent (UA) serves all
NB user interfaces connected to a Voice LT.

NT
The role of the SIP Integrated Voice Service is twofold:

• Access Gateway.
• Access Gateway Controller (maintains AG states, manages AG features,
implements SIP UA).
13.3.4 CESoPSN (Cicuit Emulation Service over Packet

Switched Network)
The CESoPSN Nx64 DS0 Pseudo Wire Emulation feature provides encapsulating of
structured (NxDS0) Time Division Multiplexed (TDM) signals as pseudo-wires over
packet-switching networks (PSN).
Emulation of NxDS0 circuits provides for saving PSN bandwidth, supports DS0-level
grooming and distributed cross-connect applications. It also enhances resilience of
Customer Edge (CE) devices to effects of packet loss in the PSN.
The CESoPSN solution fits the Pseudo Wire Emulation Edge-to-Edge (PWE3)
architecture [RFC3985], and satisfies the general requirements [RFC3916] and
specific requirements for structured TDM emulation [RFC4197].
The access node plays the role of Voice Gateway (VGW) and can interface with
voice feature servers acting as back-to-back SIP Servers via the SIP protocol.
Figure 70 shows an ISDN PRA LT (NIAT-A) that allows to terminate Nx64 E1 Leased
Line in ISAM. It supports:
• 8xE1 baseband interfaces (G.703/G.704)
• 1 Nx64 E1 Leased Line per E1 interface
• 1 CESoPSN Pseudo Wire per E1 interface per E1 interface as per RFC5086
• N (N=1~31) continuous DS0 timeslots per Nx64 E1 Leased LinexE1 baseband
interfaces (G.703/G.704)
Two alternative transport methods towards ISAM are supported:

• (1) Direct connection via E1 baseband 4 wire transmission (G.703): < 1km
• (2) Connection via TDM over G.SHDSL transport: > 1km

NT
Figure 70 Structured (Nx64) E1 Leased Line (PW3) in ISAM via NIAT-A
ETH/IP/MPLS
ISA M ETH/IP/MPLS
DTE/DCE
e1
Wir
udo
SHDSL
16x G.SHDSL
NT
LT Board
Pse 2
PSN
(PTM/ATM)
So W ire
CE
PTM
Business and udo
ATM
N Pse
S
oP e3 DTE/DCE
customer C ES Wir
8x G.SHDSL
udo
environment (PTM/ATM/TDM) Pse
PSN
PTM T
2 o
ATM D CE S
TDM TDM M
l
CPE*
s hds
/G. DTE/DCE
TDM T
DTE/DCE
D
E1
Le M TDM bus
as
ed 4x 2xE1
Lin
e E1 front
ISDN PRA
cable
LT Board
LL -
PBX IW
1 4x 2xE1
(*): Compatibility of existing

CPE to be verified.
Ref CPE RAD ASMi-54L - 54L
(variant: 4ETH/2W/E1)
Figure 71 shows the Structure-Aware Time Division Multiplexed (TDM) Circuit

Emulation Service over Packet Switched Network (CESoPSN) network reference
model.
The two PEs (PE1 and PE2) have to provide one or more PWs on behalf of their
client CEs (CE1 and CE2) to enable the client CEs to communicate over the PSN.
A PSN tunnel is established to provide a data path for the PW.
The PW traffic is invisible to the core network and the core network is transparent to
the CEs. Native data units (bits, cells, or packets) arrive via the AC, are encapsulated
in a PW-PDU and are carried across the underlying network via the PSN tunnel. The
PEs perform the necessary encapsulation and de-capsulation of PW-PDUs and
handle any other functions required by the PW service, such as sequencing or
timing.
Figure 71 CESoPSN reference model
Emulated Service
Pseudo Wire
PSN Tunnel
Native Native
Service (TDM) Service (TDM)
Attachment PW1
CE1 Circuit PE1 PE2 Attachment
Circuit CE2
(e.g. E1) ISAM1 ISAM 2 (e.g. E1)
PW2
Provider Provider
Customer Edge 1 Edge 2
Customer
Edge 1 Edge 2

NT
13.4 Voice cluster topology
13.4.1 H.248 Integrated Voice Service

The H.248 Integrated Voice Service supports the "Voice cluster" topology. A "Voice
cluster" is to be understood as the aggregation of a main ISAM Voice access node
together with its associated subtending and/or remote ISAM Voice access nodes.
The latter ISAM Voice nodes are managed by the Media Gateway (active standby
pair) that resides in the main ISAM Voice node. It is to be noted that:
• All voice LTs equipped in one ISAM Voice node are managed by one and the
same Media Gateway.
• A main ISAM Voice node may host multiple Media Gateways (Media Gateway
active/standby pairs).
• Voice LTs, co-located with one or multiple Media Gateways (Media Gateway
active/standby pairs) in the same ISAM Voice node, are managed by only one
Media Gateway (pair) in that same ISAM Voice node
• One ISAM Voice node, always belongs to at most 1 Voice cluster.
ISAM Voice access nodes that belong to a Voice cluster may be connected to their
Media Gateway (pair) by a layer 2, a layer 3 or even a mixture of a layer 2 and a layer
3 aggregation network
The supported Voice Cluster topologies are shown in Figure 72, Figure 73, Figure
74, Figure 75, Figure 76 and Figure 77.

NT
Figure 72 Megaco Integrated Voice Service: Voice Cluster topology A
MG MG MG
pair 1 pair 2 pair 8
Main shelf
Voice Voice Voice LT shelf 1 Voice

LT 1 LT 2 Belongs to voice cluster LT 16
supervised by NVPS pair 1

supervised by NVPS pair2

Figure 73 Megaco Integrated Voice Service: Voice Cluster topology B
MG MG MG
Main shelf




NT
Figure 74 Megaco Integrated Voice Service: Voice Cluster topology C
MG MG MG Voice Voice Voice

pair 1 pair 2 pair 3 LT 1 LT 2 LT 10
Voice LTs belongs to voice cluster

Main shelf supervised by NVPS pair 1



Figure 75 Megaco Integrated Voice Service: Voice Cluster topology D

Voice LTs belong to different voice clusters

Main shelf supervised by NVPS pair 1, 2 or 3




NT
Figure 76 Megaco Integrated Voice Service: Voice Cluster topology E
MG MG MG
Main shelf
Voice LTs in Voice LTs in

Voice shelf 1 belong to voice Voice Voice shelf 1 belong to voice Voice
LT 1 LT N LT N+1 cluster supervised by
LT 16
cluster supervised by
NVPS pair 1 NVPS pair 2

LT 1 LT M LT M+1 cluster supervised by
LT 16
Voice Voice Voice LT shelf 8 (multiple) Voice

Figure 77 Megaco Integrated Voice Service: Voice Cluster topology F

Voice LTs belong to different voice clusters

Main shelf supervised by NVPS pair 1, 2 or 3

LT 1 LT N LT N+1 cluster supervised by
LT 16

LT 1 LT M LT M+1 cluster supervised by
LT 16

LT 1 LT 2 Belongs to different voice clusters LT 16
supervised by NVPS pair 1, 2 or 3

NT
13.4.2 SIP Integrated Voice Service

The SIP integrated voice service does not support the voice cluster topology. The
SIP user Agent is integrated in each individual access node
ISAM Voice access nodes may be connected by layer 2, layer 3 or even a mixture of
a layer 2 and a layer 3 aggregation network.
13.5 Product Definition and Dimensioning
13.5.1 H.248
The H.248 (Megaco) based integrated voice service is supported for the following
products:
• 7302 ISAM:
• POTS and ISDN BRA services supported.
• Maximum 18 Voice LT slot positions (with single NT).
• 7330 ISAM FTTN:
• POTS and ISDN BRA services supported.
• 7360 ISAM FX:
• POTS services supported.
• Maximum 16 Voice LT slot positions.
13.5.2 SIP
The SIP based integrated voice service is supported in:
• 7302 ISAM:
• POTS / ISDN PRA / CAS R2 services supported.
• 7330 ISAM FTTN:
• 7360 ISAM FX:
• Maximum 16 Voice LT slot positions.

NT
13.5.3 Mix of SIP POTS and H.248 ISDN BRA

The SIP POTS voice service and the H.248 (Megaco) ISDN BRA service can be
mixed in the same access node.
• In an IMS network topology, H.248 ISDN-BRA subscribers register to their Media
Gateway Controller and are managed by the local Media Gateway (Physical
Voice Packet Server only) while SIP POTS subscribers register to their registrar
and are managed by the local SIP User Agent.
• Any VLAN topology for this mixed SIP/H.248 voice services is allowed, on the
condition that not more than 2 VLANS (Public or Private) of type Voice-VLAN are
configured per shelf.
• The mixed SIP POTS and H.248 (Megaco) ISDN BRA service is supported for
both, the switched as well as the routed voice model.
• H.248 clustering is supported (Hub/Subtending/Remote access node).
• Integrated Narrow band Line Test is supported for SIP signaling POTS
terminations (full NBLT set) and H.248 ISDN BRA terminations (limited NBLT set).
• Basic call service and Supplementary services are supported for both SIP POTS
and H.248 ISDN BRA.
13.5.4 Mix of SIP POTS/ISDN PRA/CAS R2 and H.248 POTS

The SIP POTS / ISDN PRA / CAS R2 and the H.248 (Megaco) POTS services can
be mixed in the same access node (but cannot be mixed in the LT board).
• Support of a single or multiple (pairs of) Media Gateway physical voice packet
server board(s).
• Support of a single or a pair of Media Gateway virtualized voice packet servers.
• The POTS H.248 voice cluster supports HUB, subtending and remote access
nodes (Physical voice packet server only).
• The SIP POTS / ISDN PRA / CAS R2 service can be co-located with the H.248
POTS service in the HUB and/or subtending and/or remote access node.
• The POTS H.248 service supports the distinct, shared and private VLAN
approach.
• The SIP POTS / ISDN PRA / CAS R2 service supports the distributed and the
centralized internal IP address architecture.
• The SIP POTS / ISDN PRA / CAS R2 service supports the distinct and shared
VLAN approach.
• The possibility to select an internal IP@ architecture and a particular VLAN
approach for the co-located SIP/H.248 voice service combination highly depends
on the maximum number of voice VLANs (U2U capability) with or without L4
forwarding capabilities supported by the NT equipped in the access node
(different for SHUB and IHUB based NT).
• The Hub access node can be deployed as L2 switching device or L3 routing
device.
• The subtending access node can be deployed as L2 switching device.

NT
• The remote access node can be deployed as L2 switching device or L3 routing

device.
• All H.248 and SIP / ISDN PRA services are supported by the co-located H.248 /
SIP voice service combination.
• H.248 POTS voice service: support of the co-located Emergency Stand-Alone
(co-located with Media Gateway)
• SIP POTS / ISDN PRA voice service: support of LSA SIP server (either hosted at
the physical voice packet server board or hosted at the virtual voice packet server
board running on top of the multi-core NT).
• Support of multiple VSG (SIP POTS and ISDN PRA voice service) and multiple
SIP service Profiles (SIP POTS voice service) per access node.
• H.248 and SIP voice service:
• Support of external packet forwarding
• Support of Integrated Narrowband Line Testing
* H.248 POTS subscriber line : full NBLT set
* SIP POTS subscriber line: full NBLT set
* SIP ISDN PRA / CAS R2 subscriber line: loopback test only
• Support of voice traffic mirroring (SHUB based NT only)
13.6 Traffic types and forwarding
13.6.1 Traffic Types
13.6.1.1 H.248 Integrated Voice Service

Three traffic types can be distinguished:
• Management traffic (SNMP, CLI, TL1 (alarm display only)) exchanged between
the OSS/BSS platform and the Voice management at the access node.
• Signaling traffic (Megaco, SIGTRAN) exchanged between the Media Gateway
Controller (MGC)/Application Server Process (ASP) and the Media Gateway of
the access node.
• Media traffic (RTP, RTCP, Voice Band data).

NT
In addition, for the voice cluster topology, an additional traffic type applies i.e. the
XLES signaling :
• The Internal signaling traffic, also called "XLES" traffic, is exchanged between the
Media Gateway and its associated Voice LT board hosted in either the hub,
subtending or remote access node and allows the Media Gateway.
• To monitor the voice LT board operational status
• To exchange events with the voice LT board, and vice versa, in the course of the
protocol stack convertion between H.248 signaling and the Z-Interface.
Management traffic is exchanged in the external management communication VLAN

and as such kept separate from the other traffic types. This is done for security
reasons.
Media (together with XLES - if applicable) traffic always share the same VLAN.
H.248 (together with SIGTRAN - if applicable) signaling traffic may be exchanged in
a dedicated signaling VLAN or may even share the same VLAN as the media traffic.
The latter situation applies when IP address/IP subnet optimization is given priority
to signaling and media traffic isolation.
13.6.1.2 SIP Integrated Voice Service

Three traffic types can be distinguished:
• Management traffic (SNMP, CLI, TL1 (alarm display only)) exchanged between
the OSS/BSS platform and the Voice Management agent at the access node.
• Signaling traffic (SIP) exchanged between the SIP Server and the SIP User Agent
at the access node.
• Media traffic (RTP, RTCP, Voice Band data).
Management traffic is exchanged in the external management communication VLAN
and as such kept separate from the other traffic types. This is done for security
reasons.
SIP signaling traffic may be exchanged in a dedicated signaling VLAN or may even
share the same VLAN as the media traffic. The latter situation applies when IP
address/IP subnet optimization is given priority to signaling and media traffic
isolation.
13.6.2 Traffic forwarding

The forwarding method depends on whether packets are sent upstream or received
in downstream direction.

NT
Following forwarding methods may apply:

• Layer 2 forwarding (upstream and downstream)
• Layer 3 forwarding (upstream and downstream)
• Layer 4 forwarding (downstream)
In addition, User-to-User communication must be enabled for the VLAN carrying
media traffic.
13.6.2.1 User-to-user communication

The integrated voice service requires that User-to-User communication is enabled in
the VLAN carrying media traffic.
Depending on the product, User-To-User communication gets autonomously
enabled by the system or must explicitly be enabled by the operator for the VLAN
carrying the media traffic.
U2U communication allows media traffic to be switched
• Internally in the access node between subscribers connected to the same access
node.
• Where ethe hub-subtending topology is applicable, internally in the
Hub-subtending access node cluster between subscribers connected to the Hub
and subscribers connected to the subtending access node (and vice versa).
• Layer 4 forwarding (downstream)
13.6.2.2 Layer 4 forwarding

The layer 4 forwarding applies to downstream traffic only and is installed on a
per-VLAN basis. This forwarding method uses the content of the destination
transport protocol port field in the transport protocol header of the IP packet to
forward the packet to the correct voice LT board.
At the SHUB, the L4 forwarding property is autonomously installed by the system
upon the configuration of an IP interface on top of a VLAN of type "Voice-VLAN".

NT
At the IHUB, the L4 forwarding property is autonomously installed by the system

when the following conditions are fulfilled:
1 The number of VLAN to be created depends on the operating mode of the ISAM:
• ISAM behaving as switching device:
A single VLAN is created and associated with ASAM ports and the Network ports.
• ISAM behaving as routing device:
One user VLAN and one or multiple network VLANs are created whereby the user
VLAN is associated with ASAM ports, while the network VLAN is associated with
Network ports
2 A VPRN service, identified by the VFR ID, is created.
3 An IP interface and an IP address are created as part of the VPRN service.
4 The IP interface is bound to the (user) VLAN.
5 The VLAN has at least one Voice LT board connected.
Each LT slot position gets assigned a fixed transport protocol port range. The xHub
port that connects to a LT slot position LT inherits this fixed transport protocol port
range mapping
The transport protocol port range for free usage (IANA) that is, 49153 - 65535 is
divided in 32 equal portions and the lower part of each portion (256 ports) is mapped
to the different xHub ports. The mapping of the 32 transport protocol portions to the
xHub ports is fixed and identical for every access node.
Upon receipt of a downstream packet within a layer 4 forwarding assigned VLAN and
with the destination IP address bound to this VLAN, the destination port value of the
transport protocol header included in the packet is compared against all defined
transport protocol ranges. When a match is found, the corresponding xHub port
mapping is looked-up and the packet is forwarded to the voice LT that connects to
this xHub port.
As described, the layer 4 forwarding uses the combination {VRF-ID + destination IP
address + destination Transport Protocol port} to decide about the further
downstream forwarding of an IP packet..
Layer 4 forwarding is applied to both signaling and media traffic.
Layer 4 forwarding supports packet fragmentation at IP layer because, unlike Voice
traffic, SIP signaling traffic may be fragmented at the IP layer.
The described algorithm is schematically shown in Figure 78.

NT
Figure 78 Layer 4 forwarding approach
xHub
Match (Transport Prot port range1, port a1 )

Network (VRF ID + (Transport Prot port range2, port a2 )
Y
side own
…
IP address)?
(Transport Prot port rangeN, port an )
Ingress N Egress
Layer 4 forwarding
Layer 3 IP table
Layer 2 VLAN/MAC table
Layer 2/layer 3 forwarding
13.6.2.3 H.248 Integrated Voice Service : Conceptual

Forwarding models
Figure 79 shows the Megaco Integrated Voice Service switched model.
Figure 79 Megaco Integrated Voice Service: switched model
Main ISAM Voice

Fast path VRF
Voice LT IP address voice Voice VLAN
Signaling VLAN
IP address
XLES
Voice NT
server
IP address
signalling
• The network signaling VLAN terminates at the Voice packet server.

• The network RTP/RTCP (XLES) VLAN terminates at the voice LT board/Voice
packet server.
• The source/destination IP address for H.248 signaling traffic is configured at the
Voice packet server.

NT
• The source/destination IP address for XLES traffic is configured at the Voice

packet server.
• The source/destination IP address for RTP/RTCP traffic is configured at the IHub
and is shared by all the Voice LT boards
• The IHub performs L4 forwarding for RTP/RTCP/XLES traffic destined to the
voice LT board
• The IHub performs L2 forwarding for upstream/downstream signaling traffic
• The IHub performs L3 forwarding for upstream RTP/RTCP/XLES traffic.
Figure 80 shows the Megaco Integrated Voice Service routed model.

Figure 80 Megaco Integrated Voice Service: routed model
Main ISAM Voice

Fast path VRF
Network
Voice LT IP address VLAN 1
IP address
Internal
network 1
Voice
Voice
VLAN IP address IP address
User 1 network 2 Network
VLAN 2
IP address
XLES
Voice NT
Internal
server signaling
IP address VLAN
signalling
The conceptual architecture shows different VLANs carrying H.248 signaling and
RTP/RTCP/XLES traffic at the network side than at the user side (VLAN) of the VRF.
The internal VLAN that carries RTP/RTCP/XLES traffic performs L4 forwarding in
downstream direction.
At the IHub:
• VRF user side: a numbered IP interface is configured on top of the internal voice
VLAN for the following reasons:
• This IP interface is used as the destination IP address for RTP/RTCP/XLES packets
addressed to the voice LT board. For this purpose, the Voice subnet is advertised (as
host subnet) to the upstream network.
• The IHub is considered as the first next hop for the RTP/XLES packets sent in the
upstream direction by the NVPS
• VRF user side: A numbered IP interface is configured on top of the internal
signaling VLAN. The IHub is seen as the first next hop for the H.248 signaling
traffic that originates from the Media Gateway running at the NVPS board.
The signaling subnet is advertised (as host subnet) to the upstream network.

NT
• Network side: A numbered IP interface is configured on top of the network-side

signaling VLAN.
• Network side: A numbered IP interface is configured on top of the network-side
TP/RTCP/XLES VLAN.
In the upstream direction, the selection of the network interface/VLAN will happen as
the result of the IP DA look-up in the L3 forwarding table, and this for all the voice
service related traffic (H.248 signaling, XLES, RTP and RTCP).
In the downstream direction, voice-service-related traffic (H.248 signaling, XLES,
RTP and RTCP) may be received at any network interface/VLAN. The IHub must
perform the further L3 forwarding to:
• the appropriate internal VLAN
• and to the destined NVPS
• and to the destined voice LT board (by L4 forwarding)
From a downstream forwarding perspective, seen from the edge router, the voice
access node is configured as the next-hop.
13.6.2.4 SIP Integrated Voice Service : Conceptual

Forwarding models
Figure 81 shows the SIP Integrated Voice Service (centralized architecture) switched
model.
Figure 81 SIP Integrated Voice Service (centralized architecture): switched
model
Main ISAM Voice

Fast path VRF Network
Voice v-VPLS 1
Voice LT IP address voice
v-VPLS /VLAN 1
Signaling Network
v-VPLS IP address v-VPLS 2
signalling /VLAN 2
NT
• The network signaling VLAN terminates at the voice LT board

• The network RTP/RTCP VLAN terminates at the voice LT board

NT
• The source/destination IP address for SIP signaling traffic is configured at the

IHub. It is shared by all the voice LT boards
• The source/destination IP address for RTP/RTCP traffic is configured at the IHub.
It is shared by all the voice LT boards
• The IHub performs L4 forwarding for SIP signaling/RTP/RTCP traffic destined to
the voice LT board
• The IHub performs L3 forwarding for upstream SIP signaling/RTP/RTCP traffic.
Figure 82 shows the SIP Integrated Voice Service (centralized architecture) routed
model.
Figure 82 SIP Integrated Voice Service (centralized architecture): routed
model
Main ISAM Voice

Internal
Voice v-VPLS 1
Voice LT v-VPLS IP address /VLAN 1
IP address
network 1
Voice
IP address IP address
Internal
signaling network 2 Network
signaling
v-VPLS v-VPLS 2
/VLAN 2
NT
The conceptual architecture shows different VLANs carrying SIP signaling and
RTP/RTCP traffic at the network and the user side (VLAN) of the VRF.
Both internal VLANs perform L4 forwarding in downstream direction.
At the IHub:
• IHub VRF user side: A numbered IP interface is configured on top of the internal
voice VLAN. This IP address is used as destination IP address for RTP/RTCP
packets addressed to the voice LT board. For this purpose, the Voice subnet is
advertised (as host subnet) to the upstream network.
• IHub VRF user side: A numbered IP interface is configured on top of the internal
signaling VLAN. This IP address is used as destination IP address for SIP
signaling packets addressed to the voice LT board. For this purpose, the signaling
subnet is advertised (as host subnet) to the upstream network.
• IHub VRF network side: A numbered IP interface is configured on top of the
network voice VLAN.
• IHub VRF network side: A numbered IP interface is configured on top of the
network signaling VLAN.

NT
In the upstream direction, the selection of the network interface/VLAN will happen as
the result of the IP DA look-up in the L3 forwarding table. And this for all the voice
service related traffic (SIP signaling, RTP and RTCP).
In the downstream direction, voice service related traffic (SIP signaling, RTP and
RTCP) may be received at any network interface/VLAN. The IHub must perform the
further L3 forwarding to the appropriate internal VLAN and to the destined voice LT
board (by L4 forwarding)
From a downstream forwarding perspective, seen from the edge router, the access
node is configured as the next-hop.
Figure 83 shows the SIP Integrated Voice Service (distributed architecture) switched
model.
Figure 83 SIP Integrated Voice Service (distributed architecture): switched
model
Main ISAM Voice

Voice v-VPLS 1
IP address v-VPLS /VLAN 1
voice
IP address Signaling Network

signalling v-VPLS v-VPLS 2
/VLAN 2
Voice LT
NT
• The network signaling VLAN terminates at the voice LT board

• The network RTP/RTCP VLAN terminates at the voice LT board
• The source/destination IP address for SIP signaling traffic is configured at the
voice LT board. Each voice LT board owns a different signaling IP address.
• The source/destination IP address for RTP/RTCP traffic is configured at the voice
LT board. Each voice LT board owns a different RTP/RTCP IP address.
• The IHub performs L2 forwarding for SIP signaling/RTP/RTCP traffic destined to
the voice LT board
• The IHub performs L2 forwarding for upstream SIP signaling/RTP/RTCP traffic.
Figure 84 shows the SIP Integrated Voice Service (distributed architecture) routed
model.

NT
Figure 84 SIP Integrated Voice Service (distributed architecture): routed

model
Main ISAM Voice

Internal
Voice v-VPLS 1
Voice
v-VPLS
IP address /VLAN 1
network 1
user 1
IP address Internal
user 2 network 2 Network
signaling signaling
v-VPLS v-VPLS 2
/VLAN 2
Voice LT
NT
The conceptual architecture shows different VLANs carrying SIP signaling and
RTP/RTCP traffic at the network and the user side (VLAN) of the VRF.
At the IHub:
• VRF user side: A numbered IP interface is configured on top of the internal voice
VLAN.
Note — The IP address configured at the voice LT board is
used as destination IP address for RTP/RTCP packets
addressed to the voice LT board. For this purpose, the Voice
subnet is advertised (as host subnet) to the upstream network.
• VRF user side: A numbered IP interface is configured on top of the internal
signaling VLAN.
Note — The IP address configured at the voice LT board is
used as destination IP address for SIP signaling packets
addressed to the voice LT board. For this purpose, the
signaling subnet is advertised (as host subnet) to the upstream
network.
• VRF network side: A numbered IP interface is configured on top of the network
voice VLAN.
• VRF network side: A numbered IP interface is configured on top of the network
signaling VLAN.
The IHub will be considered as the first next hop for the SIP signaling and for the
RTP/RTCP traffic that originates from the voice LT board. For this reason, a
numbered IP interface is configured on both the internal signaling VLAN and the
internal RTP/RTCP VLAN at the VRF user side.
In upstream direction, the selection of the network interface/VLAN will happen as the
result of the IP DA look-up in the L3 forwarding table. And this for all voice service
related traffic (SIP signaling, RTP and RTCP).

NT
In downstream direction, voice service related traffic (SIP signaling, RTP and RTCP)
may be received at any network interface/VLAN. The IHub must perform the further
L3 forwarding to the appropriate internal VLAN and to the destined voice LT board.
From a downstream forwarding perspective, seen from the edge router, the access
node is configured as the next-hop.
13.6.2.5 Subtending model

Figure 85 shows the MEGACO/SIP Integrated Voice Service subtended topology for
the switched model.
Figure 85 MEGACO/SIP Integrated Voice Service - Subtended topology:
Switched mode
Main ISAM Voice

Fast path VRF
NT
Subtending ISAM
Fast path VRF
NT
Figure 86 shows the MEGACO/SIP Integrated Voice Service subtended topology for
the routed model.

NT
Figure 86 Megaco/SIP Integrated Voice Service - Subtended topology:

Routed mode
Main ISAM Voice

Fast path VRF
IP address
IP address
network 1
User 1
User 2 network 2
NT sub 1 sub 2
Main ISAM Voice

Fast path VRF
NT
The subtending access node remains configured as a switching device. Only the
main access node fulfills the routing service.
The conceptual traffic forwarding models depicted above for the IHub based system
without Remote Expansion Module also apply to the IHub based system with Remote
Expansion Module. (The physical position of the voice LT board, locally connected
in the host access node or remotely connected by means of a REM, is transparent
to the operational behavior of the VoIP service)
• Megaco Integrated Voice Service:
• Remote Expansion Module may host 1 or 2 voice LT boards: Voice LT board can be
planned for both the “master” (72-line LT board only) and the “non-Master” (48-line
and 72-line LT board) slot position.
• Remote Expansion Module cannot host the Voice packet server.
• SIP Integrated Voice Service:
• Remote Expansion Module may host 1 or 2 voice LT boards: Voice LT board can be
planned for both the “master” (72-line LT board only) and the “non-Master” (48-line
and 72-line LT board) slot position.

NT
13.6.2.6 Megaco Integrated Voice Service as switching

device
Signaling traffic
Signaling traffic originates and terminates at the Voice packet server.
In the upstream direction, the Voice packet server determines the IP next hop for the
destination IP address of the packet, performs ARP the next hop IP address and
forwards the IP packet appropriately. The local IHub and any potential intermediate
IHub perform layer 2 forwarding.
In the downstream direction: The local IHub and any potential intermediate IHub
perform layer 2 forwarding.
Figure 87 Megaco Integrated Voice Service - Switched: Signaling
forwarding
L4 forwarding
L3 forwarding
Remote node Main node
NT board Signaling
NT board L2 forwarding IP address Voice
XLES server
IP address
IHub Voice IHub Voice
Voice LT IP address IP address Voice LT
board L2 board
aggregation
network
L4 forwarding
Remote node Subtending node
NT board NT board
L3
aggregation
network
board board
L4 forwarding
MGC ASP
SoftSwitch

NT
XLES traffic
XLES traffic originates at the Voice packet server or at the Voice LT board and
terminates respectively at the Voice LT board or the Voice packet server.
• XLES traffic originating at the Voice packet server and destined to the Voice LT
board (see Figure 88):
The destined Voice LT board is connected either to the local access node, to an
access node subtending to the local access node, or to an access node
connected via a layer 2 aggregation network with the local access node.
The destination (IHub) IP address of the packet can directly be reached in the
local subnet: the Voice packet server performs ARP for the destination (IHub) IP
address and forwards the IP packet to this (IHub) IP address.
The destined Voice LT board is reachable via a layer 3 aggregation network. The
Voice packet server determines the IP next hop for the destination (IHub) IP
address of the packet, performs ARP for the next hop IP address and forwards
the IP packet appropriately.
The (destined) IHub that connects the destined Voice LT performs layer 4
forwarding.
Any potential intermediate IHub in between the Voice packet server and the
destined IHub performs layer 2 forwarding.
• XLES traffic originating at the Voice LT board and destined to the Voice packet
server (see Figure 89):
The Voice LT board forwards the XLES packet to the local IHub.
• The access node of the Voice LT board and the access node of the Voice packet
server are the same or
• The access node of the Voice LT board subtends to the access node of the Voice
packet server or
• The access node of the Voice LT board is connected via a layer 2 aggregation
network with the access node of the Voice packet server
The local IHub detects that the destination IP address of the packet can directly
be reached via the local subnet. The local IHub performs ARP for the destination
IP address and forwards the IP packet appropriately.
The destined Voice packet server is reachable via layer 3 aggregation network:
The local IHub determines the IP next hop for the destination IP address of the
packet, performs ARP the next hop IP address and forwards the IP packet
appropriately.
The IHub that connects the Voice packet server performs layer 2 forwarding.
Any potential intermediate IHub in between the Voice LT's local IHub and the
Voice packet server L2 forwarding.

NT

originating at the Voice packet server
L4 forwarding
L3 forwarding
NT board Signaling
XLES server
IP address
board L2 board
aggregation
network
L4 forwarding
NT board NT board
L3
aggregation
network
board board
L4 forwarding
MGC ASP
SoftSwitch

originating at the Voice LT board
L3 forwarding
NT board Signaling
XLES server
IP address
board L2 board
aggregation
network
L3 forwarding
NT board NT board
L3
aggregation
network
board board
L3 forwarding
MGC ASP
SoftSwitch
Voice traffic
Voice traffic originates at the Voice LT board and is destined to a voice termination
point either at the same Voice LT board, another Voice LT board in the same Voice
cluster or outside the voice cluster.
In some cases the voice traffic is sent along the Voice packet server (to support some
supplementary services or an optimized IP addressing scheme).

NT
Voice traffic is relayed to the IHub prior to the forwarding to the destined voice
termination point. This relay is either done by the Voice LT board (voice traffic that
may not pass the Voice packet server) or the Voice packet server (voice traffic that
must pass the Voice packet server).
A. Voice traffic not passing the Voice packet server:
• Voice traffic destined to an external termination point:
• The voice LT board forwards the voice traffic to the local IHub.
• The local IHub determines the IP next hop for the voice traffic destination IP address.
• The local IHub performs ARP for the next hop IP address and forwards the IP packet
appropriately.
• Any potential intermediate IHub between the local IHub and the next hop performs
layer 2 forwarding.
• Voice traffic destined to a voice termination point at the same Voice LT board in
the local access node:
• The voice LT board forwards the upstream voice traffic to the local IHub.
• The local IHub detects that the destination IP address of the voice traffic is identical
to the own Voice IP address and treats the voice traffic locally.
• The local IHub performs layer 4 forwarding to the Voice LT board from which the
voice traffic originated.
• Voice traffic destined to a voice termination point residing at a different Voice LT
board in the local access node:
• The voice LT board forwards the upstream voice traffic to the local IHub.
• The local IHub detects that the destination IP address of the voice traffic is identical
to the own Voice IP address and treats the voice traffic locally.
• The local IHub performs layer 4 forwarding to the Voice LT board to which the
destined voice termination point is connected.
• Voice traffic destined to a voice termination point residing at a Voice LT in another
access node of the voice cluster:
• The voice LT forwards the upstream voice traffic to the local IHub.
• One of the following takes place:
1. The destined Voice termination point is reachable via a layer 3 aggregation
network:
The local IHub determines the IP next hop for the destination IP address of the voice
traffic. The local IHub performs ARP the next hop IP address and forwards the voice
traffic appropriately.
2. The destined Voice termination point reachable via a layer 2 aggregation network:
The local IHub detects that the destination of the voice traffic is reachable via the
local subnet. The local IHub performs ARP the destination IP address and forwards
the voice traffic appropriately.
• Any potential intermediate IHub between the local IHub and the destined IHub
performs layer 2 forwarding.
• The IHub that connects the destined voice termination point (Voice LT board)

NT
B. Voice traffic passing the Voice packet server:

• Voice traffic destined to the Voice packet server:
• The voice LT forwards the upstream voice packet to the local IHub.
• If the destined Voice packet server is reachable via layer 3 aggregation network:
The local IHub determines the IP next hop for the Voice packet server, performs ARP
for the next-hop IP address and forwards the voice traffic appropriately.
• If the destined Voice packet server is reachable via layer 2 aggregation network (in
case the access node of the Voice LT board is either equal to the access node of the
Voice packet server, or to an access node that subtends to the access node of the
Voice packet server or to an access node connected via a layer 2 aggregation
network with the access node of the Voice packet server):
the local IHub detects that the Voice packet server is reachable within the local
subnet. The local IHub performs ARP for the IP address of the Voice packet server
and forwards the IP packet appropriately
• The IHub that connects the Voice packet server performs layer 2 forwarding.
• Any potential intermediate IHub between the local IHub and the IHub that connects
the Voice packet server performs layer 2 forwarding.
• Voice traffic relayed by the Voice packet server to a voice termination point
connected to a Voice LT board in the same access node:
• The Voice packet server invokes the NAPT facility and forwards the packet along the
local IHub to itself (this is a basic forwarding condition to allow the support of external
packet forwarding serving Lawful Intercept).
• The Voice packet server detects that the destination of the voice traffic is reachable
via the local subnet and forwards the voice traffic to the IP address of the local IHub.
• The local IHub performs layer 4 forwarding to the Voice LT board that connects the
Voice termination point.
connected to a Voice LT board in another access node of the voice cluster:
• The destined Voice Termination point is reachable via layer 3 aggregation network.
The Voice packet server determines the IP next hop for the destination of the voice
traffic, performs ARP for the next hop IP address and forwards the voice traffic
appropriately.
• The destined Voice Termination point is reachable via layer 2 aggregation network
(in case the Voice Termination point is connected to an access node subtending to
the local access node or an access node connected via a layer 2 aggregation
network with the local access node):
The Voice packet server invokes the NAPT facility and forwards the voice traffic
along the local IHub to itself (this is a basic forwarding condition to allow the support
of external packet forwarding serving Lawful Intercept).
The Voice packet server detects that the destination of the voice traffic is reachable
via the local subnet, performs ARP for the destination IP address and forwards the
voice traffic appropriately.
• The IHub that connects the Voice termination point (Voice LT board) performs layer
4 forwarding.
• Any potential intermediate IHub between the Voice packet server and the IHub
connecting the destined voice termination performs layer 2 forwarding.

NT
outside the voice cluster:
• The Voice packet server determines the IP next hop for the destination of the voice
appropriately.
• Any potential intermediate IHub in between the Voice packet server and the next hop

originating at the Voice LT board
L4 forwarding
NT board Signaling
XLES server
IP address
board L2 board
aggregation
network
L3 forwarding
NT board NT board
L3
aggregation
network
board board
L4 forwarding L3 forwarding
MGC ASP
SoftSwitch

L4 forwarding
L3 forwarding
NT board Signaling
XLES server
IP address
board L2 board
aggregation
network
L2 forwarding
L2 forwarding
NT board NT board
L3
aggregation
network
board board
L3 forwarding
MGC ASP
SoftSwitch

NT
OAM traffic
The management platform of the customer forwards the Voice OAM traffic to the
public OAM IP address of the access node hosting the Voice packet server.
Voice OAM traffic is distinguishable by a Voice specific SNMP community
string/context identifier from non-Voice OAM traffic and in addition distinguishable
through the same SNMP community string/context identifier amongst the Voice
packet server pairs (maximum 8) that may be hosted in the same access node.
Internally, the voice-specific OAM traffic is relayed to the Voice packet server.
Voice OAM responses generated by the Voice packet server are internally passed to
the ISAM SNMP agent that forwards them to the management platform of the
customer.
Any potential intermediate IHub performs layer 2 forwarding and this in both
directions.
Refer also to chapter “Management”.
13.6.2.7 H.248 Integrated Voice Service as routing device

The following routing topologies are supported:
• Single access node topology:
in this topology, only the main shelf is present. The main shelf behaves as a
routing device.
• Subtending access node topology:
in this topology, the main shelf and one or more subtending shelves are present.
Only the main shelf behaves as routing device. The subtending shelves behave
as switching device.
Summarized: An access node that is directly connected to the upstream voice

network can be configured as a routing device. An access node that is not directly
connected to the upstream voice network must be configured as switching device.
Security considerations
The IHUB has the capability of defining different VRFs for narrowband and
Broadband traffic. As a result, for access nodes that are deployed in mixed mode
(that is, meaning that narrowband and broadband services are concurrently
deployed by the same access node) shall assign different VRFs to narrowband and
broadband services to guarantee that data is kept secret against unwanted,
unintended and malicious listeners.
Signaling traffic
Signaling traffic originates and terminates at the Voice packet server.

NT
In the upstream direction, the Voice packet server determines the IP next hop for the
destination IP address of the packet, performs ARP for the next hop IP address and
forwards the IP packet appropriately.
The local IHub is configured as the next hop for signaling packets originating at the
Voice packet server.
The local IHub performs layer 3 forwarding in upstream and downstream direction.
Figure 92 Megaco Integrated Voice Service - Routed: signaling forwarding
L3 forwarding Main node
Remote node
L3 forwarding NT board Signaling

NT board IP address Voice
IHub signaling
IHub network user IP XLES server
IP address address IP address
IHub network
IHub Voice IP address
Voice LT user IP Voice LT
board address board
L3 IHub Voice
aggregation user IP
network address
NT board NT board
IHub network
IP address

Voice LT user IP IP address Voice LT
board address board
Signaling
MGC ASP
SoftSwitch
XLES traffic
XLES traffic originates at the Voice packet server or at the Voice LT board and
terminates respectively at the Voice LT board or the Voice packet server.
• XLES traffic originating at the Voice packet server and destined to the Voice LT
board:
The destined Voice LT board is connected:
• to the local access node, or
• to an access node subtending to the local access node, or
• to an access node connected via a L3 aggregation network with the local access
node.
In the upstream direction, the Voice packet server determines the IP next hop for
the destination IP address of the packet, performs ARP for the next hop IP
address / destination IP address and forwards the IP packet appropriately.
The local IHub is configured as the next hop for the XLES packets originating at
the Voice packet server (in case the destined voice LT board connects to the local
access node, the local IHub IP address is equal to the destination IP address).
The (destined) IHub that connects the destined Voice LT board performs layer 3
followed by layer 4 forwarding.

NT
• XLES traffic originating at the Voice LT board and destined to the Voice packet
server:
The Voice LT board relays the XLES packet to the local IHub.
The access node of the Voice LT board and the access node of the Voice packet
server are the same: the local IHub detects that the destination IP address of the
packet can directly be reached via the local subnet. The local IHub performs ARP
for the destination IP address and forwards the IP packet appropriately.
The access node of the Voice LT board subtends to the access node of the Voice
packet server: The local IHub determines the IP next hop for the destination IP
address of the packet, performs ARP for the next hop IP address and forwards
the IP packet appropriately.
The access node of the Voice LT Board is connected via a layer 3 aggregation
network with the access node of the Voice packet server: The local IHub
determines the IP next hop for the destination IP address of the packet, performs
ARP for the next hop IP address and forwards the IP packet appropriately.
The IHub that connects the Voice packet server performs layer 3 forwarding.

L4 forwarding
Remote node

IHub signaling
IHub network L3 forwarding user IP XLES server
IHub network
board address board
L3 IHub Voice
aggregation user IP L4 forwarding
network address
NT board NT board
IHub network
IP address

board address board
L4 forwarding
L3 forwarding
MGC ASP
SoftSwitch

NT

forwarding at the Voice LT board.
L3 forwarding
Remote node

IHub signaling
IHub network
board address board
L3 IHub Voice
aggregation user IP
network address
NT board NT board
IHub network
IP address

board address board
L3 forwarding
MGC ASP
SoftSwitch
Voice traffic
Voice traffic originates at the Voice LT board and is destined to a voice termination
at the same Voice LT board, a voice termination at another Voice LT board in the
Voice cluster or a voice termination outside the voice cluster.
In some cases the voice traffic must be sent along the Voice packet server (to
support some supplementary services or an optimized IP addressing scheme).
In all cases, voice traffic is relayed to the IHub prior to the forwarding to the destined
voice termination. This relay is either done by the Voice LT board (voice traffic that
does not pass the Voice packet server) or the Voice packet server (voice traffic that
passes the Voice packet server).
A) Voice traffic not passing the Voice packet server.
• Voice traffic destined to a termination outside the voice cluster:
• The voice LT board relays the upstream voice traffic to the local IHub.
• The local IHub determines the IP next hop for the voice traffic destination.
• The local IHub performs ARP for the next hop IP address and forwards the IP packet
appropriately.
• Voice traffic destined to a voice termination connected to the same Voice LT
• The Voice LT board relays the upstream voice traffic to the local IHub.
• The local IHub detects that the destination of the voice traffic equals the local Voice
IP address and treats the voice traffic locally.
• The local IHub performs layer 4 forwarding to the Voice LT board from which the
voice traffic originated.

NT
• Voice traffic destined to a voice termination connected to a different Voice LT

• The local IHub detects that the destination of the voice traffic equals the local Voice
IP address and treats the voice traffic locally.
destined voice termination is connected.
• Voice traffic destined to a voice termination connected to a Voice LT board in
another access node of the voice cluster:
• The local IHub determines the IP next hop for the destination of the voice traffic. The
local IHub performs ARP for the next hop IP address and forwards the voice traffic
appropriately.
• The IHub that connects the destined voice termination (Voice LT board) performs
layer 3 followed by layer 4 forwarding.
B) Voice traffic passing the Voice packet server.

• Voice traffic destined to the Voice packet server:
• The local IHub determines the IP next hop for the Voice packet server, performs ARP
for the next hop IP address and forwards the voice traffic appropriately.
• In case the access node of the Voice LT board and the access node of the Voice
packet server are the same, the local IHub performs ARP for the Voice packet server
IP address and forwards the IP packet appropriately.
• Voice traffic relayed by the Voice packet server to a voice termination connected
to a Voice LT board in the same access node:
• The Voice packet server invokes the NAPT facility and forwards the voice traffic
• The Voice packet server detects that the destination of the voice traffic is reachable
within the local subnet, performs ARP for the destination IP address and forwards the
IP packet appropriately.
• The local IHub performs layer 4 forwarding to the Voice LT board that connects the
Voice termination point.
• Voice traffic relayed by the Voice packet server to a voice termination connected
to a Voice LT board in another access node of the voice cluster:
appropriately.
• The Voice termination is connected to an access node subtending to the local access
node:
The Voice packet server invokes the NAPT facility and forwards the voice traffic
The Voice packet server detects that the destination of the voice traffic is reachable
within the local subnet, performs ARP for the destination IP address and forwards the
voice traffic appropriately.
• The IHub that connects the Voice termination (Voice LT board) performs layer 4
forwarding.

NT
• Voice traffic relayed by the Voice packet server to a voice termination outside the
voice cluster:
traffic, performs ARP the next hop IP address and forwards the voice traffic
appropriately.

originating at the LT board
L4 forwarding
Remote node L3 forwarding Main node

IHub signaling
IHub network
board address board
L3 IHub Voice
IHub
aggregation subtended user IP L3 forwarding
network IP address address
NT board NT board
IHub network
IP address

board address board
L3 forwarding L3 forwarding
L4 forwarding
MGC ASP
SoftSwitch

NT

L4 forwarding

IHub signaling
IHub network L3 forwarding user IP XLES server
IHub network
board address board
L3 IHub Voice
IHub
aggregation subtended user IP L3 forwarding
network IP address address
NT board NT board
IHub network
IP address

board address board
L3 forwarding
MGC ASP
SoftSwitch
OAM traffic
public OAM IP address of the access node hosting the Voice packet server.
Voice OAM traffic is distinguishable by a Voice specific SNMP community
string/context identifier from non-Voice OAM traffic and in addition distinguishable
through the same SNMP community string /context identifier amongst the Voice
packet server pairs (maximum eight) that may be hosted in the same access node.
Internally, the voice specific OAM traffic is relayed to the Voice packet server.
the SNMP agent that forwards them to the management platform of the customer.

NT
13.6.2.8 SIP Integrated Voice Service as switching device

Signaling traffic
Signaling traffic originates at the Voice LT board.
• Centralized SIP architecture = single IP address:
• In upstream direction: the Voice LT board forwards the signaling packet to the local
IHub. The Local IHub determines the IP next hop for the destination IP address of the
packet, performs ARP for the next hop IP address and forwards the IP packet
appropriately.
• In downstream direction: upon the receipt of a signaling packet, the local IHub
performs layer 3 forwarding followed by layer 4 forwarding to the destined Voice LT
board.

packet originating at the Voice LT/Upstream layer 3 forwarding
at the IHub
L3 forwarding
NT board NT board
L2 forwarding

Voice LT IHub signaling Voice LT

IHub signaling
board IP address L2 IP address board
aggregation
network
NT board NT board
L3
aggregation
network
Voice LT Voice LT
IHub signaling IHub signaling
board IP address IP address board
S-CSCF L3 forwarding
I-CSCF
AS
IP
HSS IMS
MRF Core

NT

packet destined to the Voice LT/Downstream layer 4 forwarding
at the IHub
Remote node L4 forwarding Main node
NT board NT board
L2 forwarding

Voice LT IHub signaling Voice LT

IHub signaling
board IP address L2 IP address board
aggregation
network
NT board NT board
L3
aggregation
network
Voice LT Voice LT
IHub signaling IHub signaling
board IP address IP address board
I-CSCF
AS
IP
HSS IMS
MRF Core
• Distributed SIP architecture = Multiple IP address:

• In the upstream direction: the Voice LT board determines the IP next hop for the
destination IP address of the packet and forwards the IP packet appropriately. Any
potential intermediate IHub performs layer 2 forwarding.
• In the downstream direction: upon the receipt of a signaling packet, the local IHub
performs layer 2 forwarding to the destined Voice LT board.

NT

at the Voice LT
L3 forwarding
Voice LT NT board Voice LT

board L2 forwarding NT board
board
Signaling Signaling
Voice Voice
IP address L2 IP address
aggregation
network

NT board
board L3 board
aggregation
Signaling Signaling
IP address network IP address
Voice Voice
I-CSCF
AS
L2 forwarding
IP
HSS IMS
MRF Core

at the IHub
Main node Main node

NT board L2 forwarding board
board
Signaling Signaling
Voice Voice
IP address L2 IP address
aggregation
network
Main node Subtending node

NT board
board L3 board
aggregation
Signaling Signaling
IP address network IP address
Voice Voice
I-CSCF
AS
IP
HSS IMS
MRF Core

NT
Voice traffic
Voice traffic originates at the Voice LT board.
For both the centralized as well as the distributed architecture, the forwarding of the
voice traffic in upstream as well as in downstream direction is identical as shown
above for the signaling traffic.
• Voice traffic exchanged between a local and a remote voice termination:
The forwarding behavior is identical to signaling traffic.
• Voice traffic exchanged between two voice terminations connected to the same
voice LT board:
The forwarding behavior depends on the destination IP address received from the
IMS core, for example, all the voice traffic might be forced to be forwarded along
a voice gateway.
Should the IMS core have decided that the voice traffic may be switched internally
in the access node then this voice traffic will be switched either internally on the
Voice LT board or along the local IHub depending on the Voice LT board type
being planned.
• Voice traffic exchanged between two voice terminations connected to different
voice LT boards in the same access node:
The forwarding behavior depends on the destination IP address received from the
IMS core, for example, all the voice traffic might be forced to be forwarded along
a voice gateway.
Anyhow, switching voice traffic between Voice Terminations, connected to the same
Voice LT board, along the local IHub is only possible in the centralized SIP
architecture, not in the distributed SIP architecture.
Centralized SIP architecture:
• The voice LT board forwards the voice packet to the local IHub.
• The local IHub detects that the destination IP address of the packet is identical to
the own Voice IP address and treats the packet locally.
destined voice termination point is connected (that is, the Voice LT board from
which the voice packet originated).
Summarized, the SIP Integrated Voice Service forwards the voice traffic in
accordance with the destination IP address dictated by the SIP signaling and the
Voice LT board type.
The external Packet Forwarding facility serving Lawful Intercept is not supported,
neither for the Distributed, nor for the Centralized SIP architecture.
OAM traffic
management IP address of the access node hosting the Voice packet server.

NT
Any potential intermediate IHub performs layer 2 forwarding and this in both
directions.
13.6.2.9 SIP Integrated Voice Service as routing device

Security considerations
The IHub can define different VRFs for narrowband and broadband traffic. As a
result, for access nodes that are deployed in mixed mode, meaning that narrowband
and broadband services are concurrently deployed by the same access node,
different VRFs must be assigned to narrowband services and to broadband services
to guarantee that data is kept secret against unwanted, unintended and malicious
listeners.
Signaling traffic
Signaling traffic originates at the Voice LT board.
• Centralized SIP architecture = single IP address:
• In upstream direction: the Voice LT board forwards the signaling packet to the local
IHub. The Local IHub determines the IP next hop for the destination IP address of the
packet, performs ARP for the next hop IP address and forwards the IP packet
appropriately.
• In downstream direction: upon the receipt of a signaling packet, the local IHub
performs layer 3 forwarding followed by layer 4 forwarding to the destined Voice LT
board.

NT

at the IHub
L3 forwarding
L3 forwarding
NT board IHub netw. IHub netw. NT board
Signaling Signaling IHub user
IHub user
IP address IP address Signaling
Signaling
IP address
IP address
IHub netw.
Voice LT Voice Voice LT
board IHub netw. IP address
IHub user IHub user
board
Voice
Voice IP address Voice
L3
IP address IHub IP address
aggregation subtending
network IP address
NT board IHub netw. NT board

IHub user Signaling
Signaling IP address
IP address IHub dignaling
IP address
Voice LT Voice LT
IHub Voice
board IHub netw. IP address board
IHub user Voice
Voice IP address
IP address
I-CSCF
AS
IP
HSS IMS
MRF Core

NT

at the IHub
L3 forwarding
L3 forwarding
NT board IHub netw. IHub netw. NT board
IHub user
IP address IP address Signaling
Signaling
IP address
IP address
IHub netw.
Voice LT Voice Voice LT
board IHub netw. IP address
IHub user IHub user
board
Voice
L3
IP address IHub IP address
aggregation subtending
network IP address

IHub user Signaling
Signaling IP address
IP address IHub dignaling
IP address
Voice LT Voice LT
IHub Voice
board IHub netw. IP address board
IHub user Voice
Voice IP address
IP address
I-CSCF
AS
IP
HSS IMS
MRF Core
• Distributed SIP architecture = Multiple IP address:

• In the upstream direction: the Voice LT board determines the IP next hop for the
destination IP address of the packet and forwards the IP packet appropriately.
• In the downstream direction: upon the receipt of a signaling packet, the local IHub
performs layer 3 forwarding to the destined Voice LT board.

NT

at the Voice LT
L3 forwarding
Main node Main node
L3 forwarding
Voice LT NT board IHub netw. IHub netw. NT board Voice LT
board IP address IP address Signaling board
Signaling IP address Signaling
IHub user
Signaling IHub netw.
IP address Voice
IHub netw.
IP address IHub user IP address
IHub user Voice
IP address Voice
Voice L3
IHub IP address
IP address aggregation subtending
network IP address
Mainnode Subtending node
Voice LT NT board IHub netw. NT board Voice LT

board IHub user
Signaling board
IP address
Signaling Signaling Signaling
IP address IP address IP address
Voice Voice
IHub netw.
Voice
IHub user
IP address
Voice
IP address
I-CSCF
L2 forwarding
AS
IP
HSS IMS
MRF Core

at the IHub
L3 forwarding
Main node Main node
L3 forwarding
Voice LT IHub netw. IHub netw. NT board Voice LT
NT board Signaling Signaling
IHub user
board Signaling board
Signaling Signaling
IHub user
Signaling IHub netw.
IP address Voice
Voice Voice
IHub netw. IP address
Voice IHub user
IHub user
IP address Voice
Voice L3
IHub IP address
IP address aggregation subtending
network IP address
Main node Subtending node
Voice LT Voice LT
board Signaling board
IHub user IP address
Signaling Signaling
Signaling
IP address
Voice Voice
IHub netw. IP address
IP address Voice
IHub user
Voice IP address
IP address
I-CSCF
AS
IP
HSS IMS
MRF Core

NT
Voice traffic
Voice traffic originates at the Voice LT board.
For both the centralized as the distributed architecture, the forwarding of the voice
traffic in upstream as well as in downstream direction is identical as shown above for
the signaling traffic:
• Voice traffic exchanged between a local and a remote voice termination: The
forwarding behavior is identical to signaling traffic.
• Voice traffic exchanged between two voice termination connected to the same
voice LT board: The forwarding behavior depends on the destination IP address
received from the IMS core, for example, all the voice traffic might be forced to be
forwarded along a voice gateway.
Should the IMS core have decided that the voice traffic may be switched internally
in the access node then this voice traffic will be switched either internally on the
Voice LT board or along the local IHub depending on the Voice LT board type
being planned.
• Voice traffic exchanged between two voice terminations connected to different
voice LT boards in the same access node: The forwarding behavior depends on
the destination IP address received from the IMS core, for example, all the voice
traffic might be forced to be forwarded along a voice gateway.
Switching voice traffic between Voice Terminations, connected to the same Voice LT
board along the local IHub is only possible in the Centralized SIP architecture, not in
the Distributed SIP architecture.
Centralized SIP architecture:
• The Voice LT board forwards the voice packet to the local IHub.
• The local IHub detects that the destination IP address of the packet is identical to
the own Voice IP address and treats the packet locally.
destined voice termination point is connected (that is, the Voice LT board from
which the voice packet originated).
Summarized, the SIP Integrated Voice Service forwards the voice traffic in
accordance with the destination IP address dictated by the SIP signaling and the
Voice LT board type.
The External Packet Forwarding facility serving Lawful Intercept is not supported,
neither for the Distributed, nor for the Centralized SIP architecture.
OAM traffic
management IP address of the access node hosting the Voice packet server.

NT
13.7 Layer 2/layer 3 addressing topologies
13.7.1 H.248 Integrated Voice Service embedded in ISAM

switching device
In the scope of sending signaling and media traffic between the network and the
access node, following addressing topologies are supported :
• Distinct VLAN topology
• Shared VLAN topology
• Private VLAN topology
Irrespective of the addressing topology being applied:
• The Management traffic is exchanged within the external management
communication VLAN.
• The Management traffic is addressed to the public OAM IP address configured at
the access node.
For the management characteristics: see chapter “Management”
13.7.1.1 Distinct VLAN topology

Voice Cluster topology:
Distinct VLANs for signaling and Media/XLES traffic.
• Signaling VLAN:
• Configurable
• Ports associated with this VLAN are the network port(s) and the L2 switch port(s)
connecting the Media Gateway.
• The signaling VLAN terminates at the access node and carries the Megaco (and
SIGTRAN) signaling traffic exchanged between the MGC (Call Server) (/ ASP
(Application Server Process)) and the Media Gateway.
• Media VLAN:
• Configurable
• Ports associated with this VLAN are the network port(s), the extension (subtending)
port(s) and the L2 switch port(s) connecting the Media Gateway and the L2 switch
port(s) connecting the Media Gateway and the L2 switch port(s) connecting the Voice
LT board(s).
• The media VLAN terminates at the access node and carries:
* RTP/RTCP traffic exchanged between end users
* XLES traffic exchanged between the Media Gateway and the Voice LT boards
Non-Voice Cluster topology:

NT
Distinct VLANs for signaling and Media traffic.

• Signaling VLAN:
• Configurable
• Ports associated with this VLAN are the network port(s) and the L2 switch port(s)
connecting the Media Gateway.
• The signaling VLAN terminates at the access node and carries the Megaco signaling
traffic exchanged between the MGC (Call Server) and the Media Gateway.
• Media VLAN:
• Configurable
port(s) and the L2 switch port(s) connecting the Media Gateway and the L2 switch
port(s) connecting the Media Gateway and the L2 switch port(s) connecting the
Voice LT board(s).
• The media VLAN terminates at the access node and carries:

Distinct public IP interfaces / IP addresses for signaling, media and XLES traffic.
• Public Signaling IP address:
• Configurable
• Owned by the Media Gateway
• One IP address per Voice Cluster.
• In case of Media Gateway redundancy, the signaling IP address shared by both
instances of the redundant MG.
• Public Voice IP address:
• Configurable
• One IP address per access node.
• Public XLES IP address:
• Configurable
Distinct public IP interfaces / IP addresses for signaling and media traffic.
• Public Signaling IP address:
• Configurable
• Configurable

NT

• Upstream Signaling traffic is L3 forwarded by the access node
• Upstream Media / XLES traffic is L3 forwarded by the access node
• Downstream signaling traffic is internally L2 switched in the access node.
• Downstream media / XLES traffic may be L4 forwarded or L2 switched in the
access node.

• Upstream Media traffic is L3 forwarded by the access node
• Downstream media traffic is L2 switched in the access node.
The distinct VLAN topologies are shown in the following figures:

• For a hub Voice access node, see Figure 105
• For a subtending Voice access node, see Figure 106
• For a remote Voice access node, see Figure 107
• For a 7363 ISAM MX/7367 ISAM SX Voice access node, see Figure 108
Figure 105 ISAM Voice : Distinct VLAN topology - HUB Voice access node
MG
In te r n a l O AM VLAN
Vo ice Se r ve r 1
Exte r n a l O AM VLAN
MG
IACM
Vo ice Se r ve r N
SIG N ALIN G VLAN
Vo ice LT 1
IHub
NT
VO ICE VLAN
Public O AM IP Address
Public Signa ling IP Address
Public Voice / XLES IP Address
Priva te O AM IP Address
Vo ice LT M
Public Voice IP Address

NT
Figure 106 ISAM Voice : Distinct VLAN topology - Subtending Voice access
node
IACM
Vo ice LT 1
IHub
NT
VO ICE VLAN
Public Voice IP Address Vo ice LT M
Figure 107 ISAM Voice : Distinct VLAN topology - Remote Voice access
node
IACM
Vo ice LT 1
IHub
NT
VO ICE VLAN
Public Voice IP Address Vo ice LT M

NT
Figure 108 7363 ISAM MX / 7367 ISAM SX : Distinct VLAN topology
MG
O AM VLAN
VO ICE VLAN
SIG N ALIN G VLAN
Interworking Vo ice LT 1
Fumction (IWF)
O AM IP Address
Signa ling IP Address
Voice IP Address
Vo ice LT M
13.7.1.2 Shared VLAN topology

This model intends to reduce the number of IP subnets (that is, the total amount of
reserved IP addresses), required for the voice service.
• Shared VLAN for signaling and Media/XLES traffic.
• Configurable
port(s), the L2 switch port(s) connecting the Media Gateway and the L2 switch port(s)
connecting the Voice LT board(s).
• The shared VLAN terminates at the access node and carries:
* the Megaco (and SIGTRAN) signaling traffic exchanged between the MGC (Call
Server) (/ ASP (Application Server Process)) and the Media Gateway.
* XLES traffic exchanged between the Media Gateway and the Voice LT boards

• Shared VLAN for signaling and Media traffic:
• Configurable
port(s), the L2 switch port(s) connecting the Media Gateway and the L2 switch port(s)
connecting the Voice LT board(s).
• The shared VLAN terminates at the access node and carries:
* the Megaco signaling traffic exchanged between the MGC (Call Server) and the
Media Gateway.

NT

• Shared public IP interface / IP address for signaling, Media and XLES traffic:
• Configurable
• Distinct public IP interface / IP address for Media traffic.:
• Configurable
• Shared public IP interface / IP address for signaling and Media traffic.:
• Configurable
• Upstream Media / XLES traffic is L3 forwarded by the access node
• Downstream media / XLES traffic may be L4 forwarded or L2 switched in the
access node.

• Upstream Media traffic is L3 forwarded by the access node
• Downstream media traffic is L2 switched in the access node.
The shared VLAN topologies are shown in the following figures:

• For a hub Voice access node, see Figure 109.
• For a subtending Voice access node, see Figure 110.
• For a remote Voice access node, see Figure 111.
• For a 7363 ISAM MX/7367 ISAM SX Voice access node, see Figure 112.

NT
Figure 109 ISAM Voice : Shared VLAN topology - HUB Voice access node
MG
Vo ice Se r ve r 1
MG
IACM
Vo ice Se r ve r N
Shared SIG N ALIN G/VOICE VLAN
Vo ice LT 1
IHub
NT
Public shared Signaling/Voice/XLES IP Address
Vo ice LT M
Figure 110 ISAM Voice : Shared VLAN topology - Subtending Voice access
node
IACM
Vo ice LT 1
IHub
NT
Public OAM IP Address

Vo ice LT M
Figure 111 ISAM Voice : Shared VLAN topology - Remote Voice access
node
IACM
Vo ice LT 1
IHub
NT

Vo ice LT M

NT
Figure 112 7363 ISAM MX / 7367 ISAM SX : Shared VLAN topology

MG
O AM VLAN
SHARED SIGNALING/
VO ICE VLAN
Interworking Vo ice LT 1
Fumction (IWF)
O AM IP Address
Shared Signaling/Voice IP Address
Vo ice LT M
13.7.1.3 Private VLAN Topology

This model further reduces the total amount of public IP addresses required for the
deployment of the integrated voice service.
This Private VLAN topology only applies to the Voice Cluster topology.
Note — For topologies that contain remote Voice access
nodes, two options are possible:
• Case A: the remote Voice access node is associated with
the public signaling/Voice/XLES VLAN. In this case a public
voice IP interface is configured at the xHub of the remote
Voice access node.
• Case B: the remote Voice access node is associated with
the private Voice/XLES VLAN. In this case a private voice IP
interface is configured at the xHub of the remote Voice
access node.
• A single, shared public VLAN is used for (case A) signaling/Voice/XLES or (case
B) signaling/Voice traffic.
• A single, shared private VLAN is used for Voice/XLES traffic.
• A shared public (case A) signaling/Voice/XLES or (case B) signaling/Voice IP
interface is configured at the Voice packet server.
• A private voice IP interface is configured at the IHub.
• A private XLES IP interface is configured at the Voice packet server.

NT
• Upstream packet forwarding in shared VLAN for signaling and Voice/XLES traffic:
• Signaling traffic originating at the Voice packet server:
layer 3 forwarding at the Voice packet server and layer 2 forwarding at the xHub.
• Voice/XLES traffic originating at the Voice packet server:
• Voice/XLES traffic originating at the remote Voice access node (Figure 115 - CASE
A):
Voice/XLES packet internally relayed from the Voice LT to the xHub and layer 3
forwarding at the xHub.
• Downstream packet forwarding in shared VLAN for signaling and Voice/XLES
traffic:
• Signaling traffic destined to the Voice packet server:
layer 2 forwarding at the xHub.
• Voice/XLES traffic destined to the Voice packet server:
• Voice/XLES destined to the Voice LT in Remote Voice access node (Figure 115 -
CASE A):
layer 4 forwarding from the xHub to the Voice LT.
• Upstream packet forwarding in the private Voice VLAN:
• Voice/XLES traffic:
Voice/XLES packet internally relayed from Voice LT to the xHub and layer 3
forwarding at the xHub.
• Downstream packet forwarding in the private Voice VLAN:
• Voice/XLES traffic:
layer 4 forwarding from the xHub to the Voice LT.
• Case A: Shared public signaling/Voice/XLES VLAN:
• Configurable.
• Ports associated with this VLAN are the ASAM port(s) connecting the Voice packet
server in the Hub Voice access node, the ASAM port(s) connecting the voice LT
boards in the remote Voice access node, and the network port(s).
• The shared VLAN terminates at the Voice packet server and at the Voice LT in the
Remote Voice access nodes. It carries:
* Megaco and SIGTRAN signaling traffic exchanged between the MGC (Call Server)/
ASP (Application Server Process) and the MG (Voice access node).
* RTP traffic originated from or destined to end users connected to a remote Voice
access node.
* RTP traffic originated from an external end user and destined to an end user
connected to the hub access node or subtending access node.
* RTP traffic originated from an end user connected to the hub or Subtending access
node and destined to an external end user.
* RTCP traffic
* XLES traffic (internal signaling, control and management) exchanged between the
Voice packet server and the Voice LT hosted in the remote Voice access node.

NT
• Case B: Shared public signaling/Voice VLAN:

• Configurable.
server in the Hub Voice access node and the network port(s).
• The shared VLAN terminates at the Voice packet server. It carries:
connected to the Hub access node, Subtending access node or Remote access
node.
* RTP traffic originated from an end user connected to the Hub, Subtending or
Remote access node and destined to an external end user.
* RTCP traffic.
• Private Voice VLAN:
• Configurable.
server, the ASAM port(s) connecting the Voice LT and the subtending port(s).
• The private Voice VLAN terminates at the Voice packet server and the Voice LT and
the IHub of the Hub, the Subtending (Case B) and/or Remote Voice access node. It
carries:
* RTP traffic originated or destined to end users connected to the hub and subtending
and/ or remote Voice access nodes.
* RTCP traffic.
Voice packet server and the Voice LT residing in the Hub, the Subtending (Case B)
and/or the Remote Voice access node.
The basic layer 2/layer 3 addressing topology with IP subnet reduction and IP
address reduction is shown in the following figures:
Figure 113 ISAM Voice : Private VLAN topology - HUB Voice access node
MG
Vo ice Se r ve r 1
MG
IACM
Vo ice Se r ve r N
Private VOICE/XLES VLAN
Vo ice LT 1
IHub
NT
Shared SIGNALING/VO ICE VLAN
Private Voice IP Address
Public shared Signaling/Voice / XLES IP Address
Vo ice LT M
Private XLES IP Address

NT
Figure 114 ISAM Voice : Private VLAN topology - Subtending Voice access
node
IACM
Private VOICE/XLES VLAN
Vo ice LT 1
IHub
NT
Vo ice LT M
Figure 115 ISAM Voice : Private VLAN topology - Remote Voice access node
CASE A
IACM
Vo ice server N
Shared SIGNALLING/VO ICE VLAN
Vo ice LT 1
IHub
NT

Vo ice LT M
CASE B
IACM
Vo ice server N
Shared SIGNALLING/VO ICE VLAN
Vo ice LT 1
IHub
NT

Vo ice LT M
The IP address topology then looks as follows:

• Shared public signaling/Voice/XLES IP address:
• Configurable.
• Residing at the Voice packet server.
• Single IP address shared by a redundant pair of Voice packet servers.

NT
• Public Voice IP address (for remote Voice access node):

• Configurable.
• Single IP address per Voice access node.
• Residing at the xHub.
• Private Voice IP address (for hub Voice access node and subtending Voice
access node):
• Configurable.
• Private XLES IP address (for hub Voice access node):
• Configurable.
• Shared by a redundant pair of Voice packet servers.
13.7.2 H.248 Integrated Voice Service embedded in ISAM

routing device
• Distinct VLAN / IP address topology
• Shared VLAN / IP address topology
• Private VLAN /IP address topology
communication VLAN.
the access node.
For the management characteristics: see chapter “Management”
13.7.2.1 Distinct VLAN / IP address topology

• Distinct VLANs for signaling and for Voice/XLES traffic at the user side of the fast
path VRF.
• Distinct VLANs for signaling traffic and for Voice/XLES traffic at the network side
of the fast path VRF.
• Different VLAN for Voice/XLES traffic exchanged with the subtending Voice
access node at the user side of the fast path VRF.
• Public Voice IP interface at the user side of the fast path VRF.
• Public signaling IP interface at the Voice packet server.

NT
• Public XLES IP interface at the Voice packet server.

• Next hop IP interface on top of the signaling VLAN at the user side of the fast path
VRF.
• Next hop IP interface on top of both the network-side signaling VLAN and the
network-side Voice/XLES VLAN at the network side of the fast path VRF.
• A user-side next hop IP interface is configured on top of the subtending VLAN at
the user side of the fast path VRF.
• Upstream packet forwarding:
• Signaling traffic and XLES traffic originating at the Voice packet server:
• Voice traffic and XLES traffic originating at the Voice LT board:
the Voice/XLES packet is internally relayed from the Voice LT board to the xHub and
• Voice traffic and XLES traffic originating at the subtending interface:
• Downstream packet forwarding:
• Signaling traffic and XLES traffic destined to the Voice packet server:
layer 3 forwarded at the xHub.
• Voice traffic and XLES traffic destined to the Voice LT:
layer 3 followed by layer 4 forwarded from the xHub to the Voice LT board.
• Voice traffic and XLES traffic destined to the subtending interface:
layer 3 forwarded at the xHub.
• Signaling VLAN at the user side of the fast path VRF:
• Configurable.
server(s).
• The signaling VLAN terminates at the IHub/Voice packet server and carries the
Megaco and SIGTRAN signaling traffic exchanged between the MGC (Call Server)/
• Voice/XLES VLAN at the user side of the fast path VRF:
• Configurable.
server and the ASAM port(s) connecting the Voice LT board.
• The VLAN terminates at the IHub and both, the Voice packet server and the Voice
LT board and carries:
* RTP traffic exchanged between end users
* RTCP traffic
Voice packet server and the Voice LT board.
• Subtending Voice/XLES VLAN at the user side of the fast path VRF:
• Configurable.
• Ports associated with this VLAN are the subtending port(s).
• The VLAN terminates at the IHub and the Voice LT board(s) connecting to the
subtending Voice access node and carries:
* RTCP traffic

NT
* XLES traffic exchanged between the Voice packet server and the subtending Voice
LT board(s)
The distinct VLAN / IP address topology is shown in the following figures:

• For a hub Voice access node, see Figure 116
• For a subtending Voice access node, see Figure 117
• For a remote Voice access node, see Figure 118
Figure 116 ISAM Voice : Distinct VLAN / IP address topology - HUB Voice
access node
MG
Internal OAM VLAN
Voice Server 1
External OAM VLAN

MG
SIGNALING VLAN Voice Server N
Network VLAN Fast-path VRF
Voice LT 1
Network VLAN
NT
Voice LT M
Subtending
VLAN
VOICE VLAN
Public OAM IP address Public Voice IP address

Public Signaling IP address Network IP address
Public Voice /XLES IP address User IP address
Private OAM IP address Subtending IP address

NT
Figure 117 ISAM Voice : Distinct VLAN / IP address topology - Subtending

Voice access node
External OAM VLAN
Fast-path VRF
Voice LT 1
NT
Subtending VLAN
Public OAM IP address

Public Voice IP address Voice LT M
Figure 118 ISAM Voice : Distinct VLAN / IP address topology - Remote Voice
access node
External OAM VLAN
Voice LT 1
NT
VOICE VLAN
Network IP address Voice LT M
The IP address topology looks then as follows:

• Public signaling IP address:
• Configurable

NT

• Configurable
• Single IP address per Voice access node configured at the user side of the fast path
VRF.
• Public XLES IP address:
• Configurable.
• Signaling path:
• User-side next hop IP address configured at the user side of the fast path VRF (xHub)
• Network-side next hop IP address configured at the network side of the fast path VRF
(xHub)
• Voice / XLES path:
Network-side next hop IP address configured at the network side of the fast path
VRF (xHub)
• User-side next hop IP address configured at the user side of the fast path VRF
(xHub) for the subtending link.
13.7.2.2 Shared VLAN / IP address topology

This model intends to reduce the number of IP subnets (that is, the total amount of
reserved IP addresses), required for the integrated voice service.
• Shared VLAN for signaling and Voice/XLES traffic at the user side of the fast path
VRF.
• Shared VLAN for signaling and Voice/XLES traffic at the network side of the fast
path VRF.
• The public Voice IP interface is configured at the user side of the fast path VRF at
the xHub.
• A shared public signaling/XLES IP interface is configured at the Voice packet
server.
• Different subtending VLAN for Voice/XLES traffic exchanged with the subtending
Voice access node at the user side of the fast path VRF.
• Next hop IP interface on top of the network side signaling/ Voice/XLES VLAN at
the network side of the fast path VRF.
• A user-side next hop IP interface is configured on top of the subtending VLAN at
the user side of the fast path VRF.
• Signaling traffic and XLES traffic originating at the Voice packet server: layer 3
forwarding at the Voice packet server and layer 3 forwarding at the IHub.
• Voice/XLES traffic originating at the Voice LT: Voice/XLES packet internally relayed
from Voice LT board to IHub and layer 3 forwarding at the IHub.
• Voice/XLES traffic originating at the subtending interface: layer 3 forwarding at the
IHub.

NT

• Signaling traffic and XLES traffic destined to the Voice packet server: layer 3
forwarded at the IHub.
• Voice traffic and XLES traffic destined to the Voice LT: layer 3 followed by layer 4
forwarded from the IHub to the Voice LT board.
• Voice traffic and XLES traffic destined to the subtending interface: layer 3 forwarded
at the IHub.
• Shared signaling/Voice/XLES VLAN at the user side of the fast path VRF:
• Configurable.
server and the ISAM port(s) connecting the Voice LT.
• The shared VLAN terminates at the IHub/Voice packet server and the Voice LT board
and carries:
ASP (Application Server Process) and the MG (Voice access node)
* RTCP traffic
Voice packet server and the Voice LT.
• Configurable.
* RTCP traffic
LT board(s)
The shared VLAN / IP address topology is shown in the following figures:


NT
Figure 119 ISAM Voice : Shared VLAN / IP address topology - HUB Voice
access node
MG
Internal OAM VLAN
Voice Server 1
External OAM VLAN

MG
Shared SIGNALING
Voice Server N
/VOICE VLAN
Voice LT 1
NT
Subtending
VLAN
Public OAM IP Address Private OAM IP Address Voice LT M

Public Voice IP Address Network IP address
Public shared Signaling/Voice/XLES Subtending IP address
IP Address
Figure 120 ISAM Voice : Shared VLAN / IP address topology - Subtending

Voice access node
External OAM VLAN
VOICE VLAN
Fast-path VRF
Voice LT 1
NT

Voice LT M

NT
Figure 121 ISAM Voice : Shared VLAN / IP address topology - Remote Voice
access node
External OAM VLAN
Voice LT 1
NT
VOICE VLAN
Network IP address Voice LT M

• Shared public signaling/XLES IP address:
• Configurable.
• Configurable.
• Single IP address per Voice access node at the user side of the fast path VRF at the
IHub.
• Residing at the IHub.
• Signaling/Voice path:
• Network-side next hop IP address configured at the network side of the fast path VRF
(IHub
• User-side next hop IP address configured at the user side of the fast path VRF (IHub)
for the subtending link.
13.7.2.3 Private VLAN / IP address reduction topology

This model further reduces the total amount of public IP addresses, required for the
integrated voice service.
• A public VLAN shared by signaling/Voice/XLES traffic at the user side of the fast
path VRF
• A private VLAN for Voice/XLES traffic at the user side of the fast path VRF
(Applies to the HUB and subtending Voice access node only)
• A public VLAN shared by signaling/Voice/XLES traffic at the network side of the
fast path VRF.
• A public IP interface shared by signaling/Voice/XLES traffic at the Voice packet
server.
• A private voice IP interface at the user side of the fast path VRF at the IHub.

NT
• A private XLES IP interface is configured at the Voice packet server.

• A different private subtending VLAN for Voice/XLES traffic exchanged with the
subtending Voice access node at the user side of the fast path VRF.
• A next-hop IP interface on top of the shared signaling/ Voice/XLES VLAN at the
network side of the fast path VRF.
• A next-hop IP interface on top of the shared signaling/Voice/XLES VLAN at the
user side of the fast path VRF.
• A next-hop IP interface on top of the subtending VLAN at the user side of the fast
path VRF.
• Upstream packet forwarding in shared VLAN for signaling/Voice/XLES traffic:
• Signaling traffic and XLES traffic + Voice traffic originating at the Voice packet server:
• Voice traffic and XLES traffic originating at the Remote Voice access node:
Voice/XLES packet is internally relayed from the Voice LT board to the xHub and
• Downstream packet forwarding in shared VLAN for signaling/Voice/XLES traffic
• Signaling traffic and XLES traffic + Voice traffic destined to the Voice packet server:
• Voice traffic and XLES traffic destined to the Voice LT board (Remote Voice access
node):
layer 3 followed by layer 4 forwarding from the xHub to the Voice LT board.
• Upstream packet forwarding in the private Voice VLAN (HUB / Subtending Voice
access node only):
Voice traffic and XLES traffic originating at the voice LT board:
Voice/XLES packet is internally relayed from Voice LT board to the IHub and layer
3 forwarding at the IHub.
• Downstream packet forwarding in the private Voice VLAN (HUB / Subtending
Voice access node only):
Voice traffic and XLES traffic destined to the voice LT:
layer 3 followed by layer 4 forwarding from the IHub to the Voice LT board.
• Shared public signaling/Voice/XLES VLAN at the user side of the fast path VRF:
• Configurable.
server in the Hub Voice access node and the ASAM port(s) connecting the voice LT
boards in the remote Voice access node.
• The shared VLAN terminates at the IHub / Voice packet server and at the Voice LT
board in the Remote Voice access nodes. It carries:
* RTP traffic originated from or destined to end users connected to a remote Voice
access node.
connected to the hub or subtending access node.
* RTP traffic originated from an end user connected to the hub or Subtending access
node and destined to an external end user.
* RTCP traffic.
Voice packet server and the Voice LT board hosted in the remote Voice access node.

NT
• Private Voice VLAN:

• Configurable.
server and the ASAM port(s) connecting the Voice LT.
• The private Voice VLAN terminates at the IHub, Voice packet server and the Voice
LT. It carries:
* RTP traffic originated or destined to end users connected to the Hub, Subtending
(Case B:) and/or Remote Voice access nodes.
* RTCP traffic.
Voice packet server and the Voice LT board residing in the Hub, the Subtending
(Case B) and/or the Remote Voice access node.
• Configurable.
* RTCP traffic
LT(s)
The private VLAN / IP address topology is shown in the following figures:

Figure 122 ISAM Voice : Private VLAN / IP address topology - HUB Voice
access node
MG
Internal OAM VLAN
Shared SIGNALING/VOICE VLAN Voice Server 1
External OAM VLAN

MG
Voice Server N
Private VOICE VLAN
Fast-path VRF
Network VLAN
Voice LT 1
NT
Voice LT M
Subtending
VLAN
Public OAM IP Address Private XLES IP Address
Private Voice IP Address Network IP address
Public shared Signaling/XLES IP Address User IP address
Private OAM IP Address Subtending IP address

NT
Figure 123 ISAM Voice : Private VLAN / IP address topology - Subtending

Voice access node
External OAM VLAN
Private VOICE VLAN

Fast-path VRF
Voice LT 1
NT

Voice LT M
Figure 124 ISAM Voice : Private VLAN / IP address topology - Remote Voice
access node
External OAM VLAN
Shared SIGNALLING
/VOICE VLAN
Voice server N
Voice LT 1
NT

Network IP address
Voice LT M

• Shared public signaling/Voice/XLES IP address:
• Configurable.
• Public Voice IP address (for remote Voice access node):
• Configurable.
VRF.
• Private Voice IP address (for hub and subtending Voice access node):
• Configurable.
VRF.

NT
• Private XLES IP address (for hub Voice access node):

• Configurable.
• Public Signaling / Voice path:
Network-side next hop IP address configured at the network side of the fast path
VRF (HUB and Remote IHub).
User-side next hop IP address configured at the user side of the fast path VRF
(HUB IHub).
• User-side next hop IP address configured at the user side of the fast path VRF
(IHub) for the subtending link.
13.7.3 SIP Integrated Voice Service embedded in ISAM

switching device
• Distributed IP address architecture - shared VLAN topology
• Distributed IP address architecture - distinct VLAN topology
• Centralized IP address architecture - distinct VLAN topology
• Centralized IP address architecture - shared VLAN topology

communication VLAN.
the access node
For the management characteristic, see chapter “Management”.
13.7.3.1 Distributed IP address Architecture - Shared VLAN

topology
• Shared VLAN for signaling and Media traffic:
• Configurable.
• Ports associated with this VLAN are the ASAM port(s) connecting the Voice LT, the
network port(s) and the subtending port(s).
• The shared signaling/media VLAN terminates at the Voice LT and carries:
* SIP signaling traffic exchanged between the SIP server and the SIP UA (Voice
access node).
* RTP/RTCP traffic exchanged between end users.

NT
• Shared IP interface for signaling and Media traffic at the voice LT board
• Configurable.
• IP interface per voice LT board
• Layer 3 forwarding of signaling/media packet at the Voice LT.
• Layer 2 forwarding of signaling/media packet at the IHub.
• Layer 2 forwarding of signaling/media packet from subtending to network side.
• Layer 2 forwarding of signaling/media packet from network to subtending side.
Figure 125 shows the addressing topology for this model.
Figure 125 ISAM Voice : Distributed IP address Architecture - Shared VLAN
topology
SIP UA
Voice LT 1
OAM VLAN
SIP UA
Voice LT K
Shared SIGNALING/VOICE VLAN
Fast-path VRF SIP UA
Voice LT L
NT SIP UA
OAM IP Address
Shared signaling/Voice IP Address
Voice LT X
Subtending
node
13.7.3.2 Distributed IP address Architecture - distinct VLAN

topology
Distinct VLANs for signaling and media traffic:
• Signaling VLAN:
• Configurable.
network port(s0 and the subtending port(s).
• The signaling VLAN terminates at the Voice LT and carries the SIP signaling traffic
exchanged between the SIP server and the SIP User Agent (Voice access node)..

NT
• Voice VLAN:
• Configurable.
network port(s) and the subtending port(s).
• The Voice VLAN terminates at the Voice LT and carries the RTP traffic exchanged
between end users and RTCP traffic.
Distinct IP interfaces for signaling and media traffic at the Voice LT.
• Signaling interface:
• Configurable.
• IP interface per Voice LT board,
• Voice IP address:
• Configurable.
• IP interface per Voice LT board,
Upstream packet forwarding:
• Layer 2 forwarding of signaling/media packet at the xHub.
Downstream packet forwarding:
• Layer 2 forwarding of signaling/media packet at the xHub
Figure 126 ISAM Voice : Distributed IP address Architecture - Distinct VLAN
topology
SIP UA
External OAM VLAN Voice LT 1
SIP UA
SIGNALING VLAN
Fast-path VRF Voice LT K
SIP UA
Voice LT L
VOICE VLAN
NT SIP UA

Public Signaling IP Address
Voice LT X
Subtending
node

NT
13.7.3.3 Centralized IP address Architecture - distinct VLAN

topology
Distinct VLANs for signaling and media traffic:
• Signaling VLAN:
• Configurable.
• Ports associated with this VLAN/V_VPLS are the ASAM port(s) connecting the Voice
LT, the network port(s0 and the subtending port(s).
• The signaling VLAN terminates at the Voice LT and carries the SIP signaling traffic
exchanged between the SIP server and the SIP and the SIP User Agent (Voice
access node)..
• Voice VLAN:
• Configurable.
• Ports associated with this VLAN are the ASAM port(s) connecting the SIP UA, the
network link(s) and the subtending link(s).
• The Voice VLAN terminates at the access node and carries the RTP/RTPC traffic
exchanged between end users.
Distinct IP interfaces for signaling and media traffic.

• Signaling interface:
• Configurable.
• IP interface per access node,
• Configurable.
• IP interface per access node,
• Signaling/media packet is internally relayed from Voice LT to xHub.
• Layer 4 forwarding of signaling/media packet from the xHub to the Voice LT
board.

NT
Figure 127 ISAM Voice : Centralized IP address Architecture - Distinct VLAN

topology
SIP UA
Voice LT 1
External OAM VLAN

SIP UA
Voice LT K
SIGNALING VLAN
Fast-path VRF
SIP UA
Voice LT L
VOICE VLAN SIP UA
NT
Voice LT X

Public Voice IP Address Subtending
node
Figure 128 7363 ISAM MX : Centralized IP address Architecture - Distinct

VLAN topology
SIP UA
Voice LT 1
External OAM VLAN
VOICE VLAN
Voice LT 2
SIGNALING VLAN
Interworking
function Voice LT N
NT


NT
13.7.3.4 Centralized IP address Architecture - shared VLAN

topology
• Shared VLAN for signaling and media traffic:
• Configurable.
• Ports associated with this VLAN are the port(s) connecting the SIP UA, the network
link(s) and the subtending link(s.
• The signaling/media VLAN terminates at the access node and carries the SIP
signaling traffic exchanged between the SIP server and the SIP User Agent (Voice
access node) together with the RTP/RTCP traffic exchanged between end users
• Shared IP interface for signaling and media traffic:
• Configurable.
• Single IP interface per access node
• Signaling/media packet is internally relayed from Voice LT to xHub.
• Layer 4 forwarding of signaling/media packet from the xHub to the Voice LT
board.
Figure 129 ISAM Voice : Centralized IP address Architecture - Shared VLAN
topology
SIP UA
Voice LT 1
External OAM VLAN
SIP UA
Shared SIGNALING/VOICE VLAN

Voice LT K
Fast-path VRF
SIP UA
NT Voice LT L
OAM IP Address
SIP UA
Subtending Voice LT X
node

NT
Figure 130 7363 ISAM MX : Centralized IP address Architecture - Shared

VLAN topology
SIP UA
Voice LT 1
External OAM VLAN
SHARED SIGNALING/
MEDIA VLAN
Voice LT 2
Interworking
function Voice LT N
NT

Shared Signaling/Media IP Address
13.7.4 SIP Integrated Voice Service embedded in ISAM

routing device
• Distributed IP address architecture - shared VLAN/IP address topology
• Distributed IP address architecture - distinct VLAN/IP address topology
• Centralized IP address architecture - distinct VLAN/IP address topology
• Centralized IP address architecture - shared VLAN/IP address topology

communication VLAN.
the access node
For the management characteristics : ref. chapter “Management”.

NT
13.7.4.1 Distributed IP address Architecture - shared

VLAN/IP address topology
• Shared VLAN for signaling and media traffic at the user side of the fast path VRF.
• Configurable.
• Ports associated with this VLAN are the ASAM port(s) connecting the Voice LT.
• The signaling/media VLAN terminates at the Voice LT and carries:
access node).
• Shared VLAN for signaling and media traffic at the network side of the fast path
VRF.
• Shared IP interface for signaling/media traffic at the Voice LT.
• Different subtending VLAN shared by signaling and media traffic at the user side
of the fast path VRF.
• Configurable.
• Ports associated with this VLAN are the subtending port(s
• The user side subtending signaling/Voice VLAN terminates at the Voice LT(s)
connected to the subtending Voice access node and carries:
access node).
• A Next Hop IP interface is configured on top of the signaling/media VLAN at the
user side of the fast path VRF
• A Next Hop IP interface is configured on top of the signaling/media VLAN at the
network side of the fast path VRF.
• A Next Hop IP interface is configured on top of the subtending VLAN at the user
side of the fast path VRF.
• Layer 3 forwarding of signaling/media packet from subtending to network side
Figure 131 shows the routing model.

NT
Figure 131 ISAM Voice : Distributed IP address Architecture - Shared

SIP UA
Shared SIGNALING/VOICE user v-VPLS
Vo ice LT 1
Exte r n a l O AM v-VPLS
SIP UA
IACM
Vo ice LT K
SIP UA
Vo ice LT L
IHub
NT
Network v-VPLS
SIP UA
Shared Signaling/Voice IP Address at user v-VPLS
Network IP Address at network v-VPLS
User IP address Vo ice LT X
Subtending IP address
subtending node

• Signaling/media IP interface:
• Configurable.
• IP interface per Voice LT board
• User side signaling/media VLAN: Next hop IP interface configured at the user side
of the fast path VRF (IHub)
• Network side signaling/voice VLAN: Next hop IP interface configured at the
network side of the fast path VRF (IHub)
• User side subtending signaling/media VLAN: Next hop IP interface configured at
the user side of the fast path VRF (IHub)
13.7.4.2 Distributed IP address Architecture - Distinct

Distinct VLANs for signaling and media traffic at the user side of the fast path VRF.:
• Signaling VLAN:
• Configurable.
• The signaling VLAN terminates at the Voice LT and carries:
access node).

NT
• Voice VLAN:
• Configurable.
• Ports associated with this VLAN are the ASAM port(s) connecting the Voice LT
• The Voice VLAN terminates at the Voice LT and carries:
Distinct VLANs for signaling and media traffic at the network side of the fast path
VRF.
Distinct IP interfaces for signaling and media traffic at the Voice LT board.
Distinct subtending VLANs for signaling and media traffic at the user side of the fast
path VRF.
• Signaling/Voice VLAN:
• Configurable.
• Ports associated with these VLANs are the subtending port(s).
• The subtending signaling/Voice VLAN terminates at the Voice LT(s) connected to the
access node).
* RTP / RTCP traffic exchanged between end users
Next Hop IP interface on top of the signaling VLAN at the user side of the fast path
VRF
Next Hop IP interface on top of voice VLAN at the user side of the fast path VRF
Next Hop IP interface on top of the signaling VLAN at the network side of the fast
path VRF.
Next Hop IP interface on top of the voice VLAN at the network side of the fast path
VRF.
Next Hop IP interface on top of the subtending signaling VLAN at the user side of the
fast path VRF.
Next Hop IP interface on top of the subtending voice VLAN at the user side of the fast
path VRF.
• Layer 3 forwarding of signaling/media packet from network to subtending side

NT
Figure 132 ISAM Voice : Distributed IP address Architecture - Distinct

SIGNALING user v-VPLS SIP UA
VO ICE user v-VPLS

Vo ice LT 1
SIP UA
IACM
Vo ice LT K
SIP UA
Network v-VPLS
Vo ice LT L
IHu b
NT
SIP UA
Signaling IP Address at user v-VPLS
Voice IP Address at user v-VPLS
Public Voice IP Address at network v-VPLS
Vo ice LT X
User IP address
Subtending IP address subtending node

• Public Signaling IP interface:
• Configurable.
• IP interfaces per Voice LT board.
• Public Voice IP interface:
• Configurable.
• IP interfaces per Voice LT board.
• User side signaling and user side voice VLAN: Next hop IP interface configured
at the user side of the fast path VRF (IHub).
• Network side signaling and network side voice VLAN: Next hop IP interface
configured at the network side of the fast path VRF (IHub).
• User side subtending signaling and user side subtending voice VLAN: Next hop
IP interface configured at the user side of the fast path VRF (IHub).

NT
13.7.4.3 Centralized IP address Architecture - distinct

VLAN/IP adress topology
Distinct VLANs for signaling and media traffic at the user side of the fast path VRF.:
• Signaling VLAN:
• Configurable.
• The signaling VLAN terminates at the Voice LT and carries:
access node).
• Voice VLAN:
• Configurable.
• Ports associated with this VLAN are the ASAM port(s) connecting the Voice LT
• The Voice VLAN terminates at the Voice LT and carries:
Distinct IP interfaces at the user side of the VRF at the xHub

Distinct IP interfaces for signaling and media traffic at the Voice LT board.
Distinct subtending VLANs for signaling and media traffic at the user side of the fast
path VRF.
• Signaling/media VLAN:
• Configurable.
access node).
Next Hop IP interface on top of the signaling VLAN at the network side of the fast
path VRF.
Next Hop IP interface on top of the media VLAN at the network side of the fast path
VRF.
Next Hop IP interface on top of the subtending signaling VLAN at the user side of the
fast path VRF.
Next Hop IP interface on top of the subtending media VLAN at the user side of the
fast path VRF.
• signaling/media packet internally relayed from Voice LT to xHub

NT

• Layer 3 followed by Layer 4 forwarding of signaling/media packet from the xHub
to the Voice LT..
Figure 133 ISAM Voice : Centralized IP address Architecture - Distinct
SIGNALING user v-VPLS SIP UA
VO ICE user v-VPLS

Vo ice LT 1
SIP UA
IACM
Vo ice LT K
SIP UA
Network v-VPLS
Vo ice LT L
IHu b
NT
SIP UA
Signaling IP Address at user v-VPLS
Voice IP Address at user v-VPLS
Vo ice LT X
User IP address
Subtending IP address subtending node

• Signaling IP address:
• Configurable
• Configurable.
• Network-side signaling VLAN and network-side Voice VLAN: next-hop IP
interface configured at the network side of the fast path VRF (IHub).
• User-side subtending signaling VLAN and user-side subtending voice VLAN:
next-hop IP interface configured at the user side of the fast path VRF (IHub).

NT
13.7.4.4 Centralized IP address Architecture - shared

Shared VLANs for signaling and media traffic at the user side of the fast path VRF.:
• Configurable.
• The signaling/Voice VLAN terminates at the Voice LT and carries:
access node).
Shared VLAN for signaling and media traffic at the network side of the fast path VRF.
A single IP interface at the user side of the VRF at the xHub
Subtending VLAN shared by signaling and media traffic at the user side of the fast
path VRF
• Configurable.
access node).
Next Hop IP interface on top of the signaling/media VLAN at the network side of the
fast path VRF.
Next Hop IP interface on top of the subtending VLAN at the user side of the fast path
VRF.
• signaling/media packet internally relayed from Voice LT to xHub
• Layer 3 followed by Layer 4 forwarding of signaling/media packet from the xHub
to the Voice LT..

NT
Figure 134 ISAM Voice : Centralized IP address Architecture - Shared

SIP UA
SHARED SIGNALING/
VO ICE user VLAN
Vo ice LT 1
SIP UA
IACM
Vo ice LT K
SIP UA
Network VLAN
Vo ice LT L
xHu b
NT
SIP UA
Vo ice LT X
Subtending IP address
subtending node

• Signaling/media IP interface:
• Configurable.
• Single IP interface per Voice access node.
• Network-side VLAN sharing signaling and media traffic: next-hop IP interface
configured at the network side of the fast path VRF (IHub).
• User-side subtending VLAN sharing signaling and media traffic: next-hop IP
interface configured at the user side of the fast path VRF (IHub).
13.8 Protocol stacks
13.8.1 H.248 Integrated Voice Service Signaling Protocol

Stack
Signaling packets are exchanged between the Media Gateway and the Media
Gateway Controller.
The XLES proprietary protocol is used to exchange internal signaling packets
between the Media Gateway and the Voice LT boards residing in the hub, subtending
or remote Voice access nodes. The XLES protocol only applies to the Voice Cluster
topology.

NT
H.248 and XLES signaling packets are encapsulated with UDP, IP and layer 2
frames. SIGTRAN signaling packets are encapsulated with SCTP, IP and layer 2
frames. The layer 2 frames are formatted according to Ethernet II format (that is,
using the type field) and VLAN 802.1Q tagged including priority setting according to
IEEE 802.1p.
H.248, SIGTRAN and XLES signaling packets include configured DSCP and .1P
values.
• HUB access node : The Z interface is terminated at the Voice LT. User events like
for example hook off, hook on, are converted into XLES/LAPV5 packets which are
sent to the Media Gateway.
• Subtending and remote access node : The Z interface is terminated at the Voice
LT residing at the remote/subtending access node. Information transfer between
the remote/subtending access node and the Media Gateway happens through the
proprietary XLES/LAPV5 protocol.
• The Media gateway in turn converts the internal proprietary XLES/LAPV5 protocol
into Megaco messages sent to the MGC.
Switching Device
(Hub) Voice access Voice
XLES XLES
H.248 H.248
LapV5 LapV5
UDP UDP UDP UDP
IP IP IP IP IP
L3 IP
802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q

Generic Generic
Z Itf Z Itf
PHY PHY
802.3 802.3 802.3 802.3 802.3 802.3
Termination Voice LT Media Gateway IWF EMAN Edge Router MGC
Routing Device
(Hub) Voice access node
XLES XLES
H.248 H.248
LapV5 LapV5
UDP UDP UDP UDP
IP IP IP IP IP IP
L3 IP
802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q

Generic Generic
Z Itf Z Itf
PHY PHY
802.3 802.3 802.3 802.3 802.3 802.3

NT
node as Switching Device - HUB Voice access node as Switching
device
Subtending Voice Hub Voice access node
access node
XLES XLES
H.248 H.248
LapV5 LapV5
UDP UDP UDP UDP
IP IP IP IP IP
L3 IP
802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q

Generic Generic
Z Itf Z Itf
PHY PHY
802.3 802.3 802.3 802.3 802.3 802.3 802.3 802.3
Termination Voice LT IWF IWF Media gateway IWF EMAN Edge Router MGC
node as Switching Device - HUB access node as Routing Device
access node
XLES XLES
H.248 H.248
LapV5 LapV5
UDP UDP UDP UDP
IP IP IP IP IP IP
L3 IP
802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q

Generic Generic
Z Itf Z Itf
PHY PHY
802.3 802.3 802.3 802.3 802.3 802.3 802.3 802.3
Termination Voice LT IWF IWF Media Gateway IWF EMAN Edge Router MGC
Figure 139 H.248 signaling protocol stack - Remote Voice POTS access
node as Switching Device - HUB Voice access node as Routing
Device
Remote Voice Hub Voice access node
access node
XLES XLES
H.248 H.248
LapV5 LapV5
UDP UDP UDP UDP
IP IP IP IP IP
L3 IP
802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q

Generic Generic
Z Itf Z Itf
PHY PHY
802.3 802.3 802.3 802.3 802.3 802.3 802.3 802.3 802.3
Termination Voice LT IWF EMAN IWF Media gateway IWF EMAN Edge Router MGC

NT
Figure 140 H.248 signaling protocol stack - Remote Voice POTS access
Device
access node
XLES XLES
H.248 H.248
LapV5 LapV5
UDP UDP UDP UDP
IP IP IP IP IP
L3 IP
IP
802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q

Generic Generic
Z Itf Z Itf
PHY PHY
802.3 802.3 802.3 802.3 802.3 802.3 802.3 802.3 802.3
Termination Voice LT IWF EMAN IWF Media Gateway IWF EMAN Edge Router MGC
For ISDN BRA terminations, the Media Gateway behaves as the signaling Gateway
(SG). It communicates with the ASP through the SIGTRAN protocol. The D-channel
layer 2 protocol (Q.921) is terminated at the Voice LT. The D-channel layer 3 protocol
(Q.931) is fully transparent to the Media Gateway. Q.931 is encapsulated with
SIGTRAN and fully transparently forwarded to the ASP.
The Voice access node still acts as the MG for the call control in calls involving
B-channels.
Switching Device
Hub Voice access node
Q931 Q931
XLES XLES
IUA IUA
Q921 Q921 LapV5 LapV5
UDP UDP SCTP SCTP
IP IP IP IP IP
L3 IP
I410 I410 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q

Generic
PHY
802.3 802.3 802.3 802.3 802.3 802.3 802.3

NT
Routing Device
Hub Voice sccess node
Q931 Q931
XLES XLES
IUA IUA
UDP UDP SCTP SCTP
IP IP IP IP IP IP
L3 IP
I410 I410 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q

Generic
PHY
802.3 802.3 802.3 802.3 802.3 802.3 802.3
For ISDN BRA Terminations connected to a remote or subtending Voice access

node, the D-channel layer 2 protocol (Q.921) is terminated at the Voice LT residing
at the remote or subtending Voice access node. Information transfer between the
remote or subtending Voice access node and the Media Gateway node happens
through the proprietary XLES/LAPV5 protocol. The Media Gateway in turn converts
the internal proprietary XLES/LAPV5 protocol into SIGTRAN messages sent to the
ASP.
node as Switching Device - HUB Voice access node as Switching
Device
access node
Q931 Q931
XLES XLES
IUA IUA
UDP UDP SCTP

L3 SCTP
IP IP IP IP IP IP
I410 I410 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q
Generic
PHY
802.3 802.3 802.3 802.3 802.3 802.3 802.3 802.3 802.3
Termination Voice LT IWF IWF Media gateway IWF EMAN Edge Router MGC

NT
Device
access node
Q931 Q931
XLES XLES
IUA IUA
UDP UDP SCTP

L3 SCTP
IP IP IP IP IP IP IP
I410 I410 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q
Generic
PHY
802.3 802.3 802.3 802.3 802.3 802.3 802.3 802.3 802.3
Termination Voice LT IWF IWF Media Gateway IWF EMAN Edge Router MGC
Figure 145 ISDN BRA signaling protocol stack - Remote Voice access node
as Switching Device - HUB Voice access node as Switching
Device
access node
Q931 Q931
XLES XLES
IUA IUA
UDP UDP SCTP L3 SCTP
IP IP IP IP IP IP
I410 I410 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q
Generic
PHY
802.3 802.3 802.3 802.3 802.3 802.3 802.3 802.3 802.3 802.3
Termination Voice LT IWF EMAN IWF Media Gateway IWF EMAN Edge Router MGC
Figure 146 ISDN BRA signaling protocol stack - Remote Voice access node
as Switching Device - HUB Voice access node as Routing Device
access node
Q931 Q931
XLES XLES
IUA IUA
UDP UDP SCTP L3 SCTP
IP IP IP IP IP IP IP IP IP
I410 I410 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q 802.1Q
Generic
PHY
802.3 802.3 802.3 802.3 802.3 802.3 802.3 802.3 802.3 802.3
Termination Voice LT IWF EMAN IWF Media gateway IWF EMAN Edge Router MGC

NT
13.8.2 SIP Integrated Voice Service Signaling Protocol

Stack (Switching / Routing)
The SIP Integrated Voice Service supports POTS, ISDN PRA and CAS R2 lines.
SIP signaling packets are exchanged between the SIP User Agent and the SIP
server.
All signaling packets are encapsulated with UDP/TCP, IP and layer 2 frames. The
layer 2 frames are formatted according to Ethernet II format (that is, using the type
field) and VLAN 802.1Q tagged including priority setting according to IEEE 802.1p.
SIP signaling packets will include configured DSCP and .1P values.
The Z or E1 interface is terminated at the Voice LT. User events like hook off, hook
on, and so on are converted into SIP messages sent to the SIP server.
Figure 147 SIP signaling protocol stack - Distributed IP address
Architecture - HUB Voice access node as Switching Device -
POTS Line
SIP SIP
UDP/ UDP/
TCP TCP
IP IP IP
L3 IP
802.1Q 802.1Q 802.1Q 802.1Q

Generic Generic
Z Itf Z Itf
PHY PHY
802.3 802.3 802.3 802.3
Termination SIP User Agent IWF EMAN Edge Router SIP Server
Figure 148 SIP signaling protocol stack - Distributed IP address

Architecture - HUB Voice access node as Routing Device - POTS
Line
SIP SIP
UDP/ UDP/
TCP TCP
IP IP IP IP
L3 IP
802.1Q 802.1Q 802.1Q 802.1Q

Generic Generic
Z Itf Z Itf
PHY PHY
802.3 802.3 802.3 802.3

NT
Figure 149 SIP signaling protocol stack - Centralized IP address

Architecture - Upstream - HUB Voice access node as Switching
Device - POTS Line
SIP SIP
UDP/ UDP/
TCP TCP
IP IP IP IP
L3 IP
802.1Q 802.1Q 802.1Q 802.1Q

Generic Generic
Z Itf Z Itf
PHY PHY
802.3 802.3 802.3 802.3

Architecture - Upstream - HUB Voice access node as Routing
Device - POTS Line
SIP SIP
UDP/ UDP/
TCP TCP
IP IP IP IP
L3 IP
802.1Q 802.1Q 802.1Q 802.1Q

Generic Generic
Z Itf Z Itf
PHY PHY
802.3 802.3 802.3 802.3

Architecture - Downstream - HUB Voice access node as
Switching Device - POTS Line
SIP SIP
UDP/ UDP/ UDP/

TCP TCP TCP
IP IP IP IP
L3 IP
802.1Q 802.1Q 802.1Q 802.1Q

Generic Generic
Z Itf Z Itf
PHY PHY
802.3 802.3 802.3 802.3

NT

Architecture - Downstream - HUB voice access node as Routing
Device - POTS Line
SIP SIP
UDP/ UDP/ UDP/

TCP TCP TCP
IP IP IP IP IP
L3 IP
802.1Q 802.1Q 802.1Q 802.1Q 802.1Q

Generic Generic
Z Itf Z Itf
PHY PHY
802.3 802.3 802.3 802.3 802.3
Figure 153 ISDN PRA to SIP signaling protocol stack -

Centralized/Distributed IP address Architecture - ISDN PRA Line
3%; ,6'1VLS,:)
SIP
4 4 6,3
UDP/
8'3 L3 TCP
7&3 IP IP IP
4 4 IP
,3
802.1Q 802.1Q
T 802.1Q Gen. Gen.
, , 802.3 802.3 PHY PHY
802.3
EMAN Edge Router 6,36HUYHU

ISDN PRA Voice LT Board xHUB
Figure 154 CAS R2 to SIP signaling protocol stack - Centralized/Distributed

IP address Architecture - CAS R2 Line
3%; &$65VLS,:)
SIP
6,3
&$65 &$65 8'3 UDP/

L3 TCP
7&3
IP IP IP
IP
,3
802.1Q 802.1Q
T 802.1Q Gen. Gen.
, , 802.3 802.3 PHY PHY
802.3
EMAN Edge Router 6,36HUYHU

ISDN PRA Voice LT Board xHUB

NT
13.8.3 Media protocol stack

Voice traffic, using Real-Time Protocol (RTP) providing the information needed to
restore the original digital voice stream, is encapsulated in UDP/IP. The same
encapsulation method is applied to Real-Time Control Protocol (RTCP), the control
protocol associated to RTP.
The encapsulated voice traffic (RTP/RTCP) includes a configurable DSCP and .1P
bit value. As a result the voice packets can use separate queues in the layer 2/layer
3 network to minimize delay and jitter.
Figure 155 RTP/RTCP protocol stack - Upstream/Downstream
ISAM
RTP/ RTP/
RTCP RTCP
UDP UDP
IP IP IP IP
L3 IP
802.1Q 802.1Q 802.1Q 802.1Q

Generic Generic
Z Itf Z Itf
PHY PHY
802.3 802.3 802.3 802.3
Termination EMAN Edge Router Voice Gateway
13.9 Management interface

The provisioning of the H.248 Integrated Voice Service service parameters happens
via the a CLI / SNMPv3 (MIB) management interface together with a CDE.tar file
downloaded from a file server.
The CDE.tar file includes CDE profiles for the different voice HW boards that will be
equipped in the access node.
Configuration by means of DHCP is not supported.
The H.248 Integrated VoIP service cannot be managed via TL1. Although, as an
exception, VoIP service alarms can be retrieved via TL1.

NT
13.9.1.1 CLI / SNMP Interface

Voice Cluster Topology :
• The SNMPV3 agent hosted at the Voice packet server serves as the management
interface for the integrated VoIP service. However, neither CLI nor SNMP
commands can directly be addressed to the Voice packet server.
• All CLI or SNMP commands to manage the integrated VoIP service are
addressed to the public OAM IP address of the access node and are
subsequently relayed to the chosen Voice packet server by means of the “Voice
packet server context name” present in the management command.
• A Voice packet server context name is mapped to a private IP address assigned
to a Voice packet server. This IP address to Voice packet server mapping is fixed
and based on the physical or virtual slot position of the Voice packet server.
• SNMP commands, carrying a “Voice packet server context name”, are addressed
to the NT SNMP agent which in turn relays the command to the destined Voice
packet server.
• CLI commands, carrying a “Voice packet server identifier”, are addressed to the
NT CLI agent, where it becomes translated into the appropriate SNMP command
and forwarded to the NT SNMP agent The NT SNMP agent in turn relays the
SNMP command to the destined Voice packet server.
Non-Voice Cluster Topology :

• The CLI Handler / SNMPV3 agent hosted at the access node serves as the
management interface for the integrated VoIP service.
• All CLI or SNMP commands to manage the integrated VoIP service are
addressed to the public OAM IP address of the access node.
13.9.1.2 Batch configuration CLI command support for

subscriber management
A subscriber is a logical entity managed by the MG that sources and/or sinks media
and/or control streams. Subscriber have unique identities, called “TerminationIDs”
assigned by the MG at the time of their creation. The Voice access node allows to
make use of 3 different formats for the “TerminationID”:
• The FLAT termination ID:
Typical Format: 'prefix<tidXXXXX>'
• The LEGACY HIERARCHICAL termination ID:
Typical format: “Prefix/Dslam_Id/rack/shelf/slot/port(/channel”
• The IMPROVED HIERARCHICAL termination ID:
Typical format:
“Prefix/Dslam_Id/rackXXXXX/shelfXXXXX/slotXXXXX/portXXXXX/channel”

NT
In case the customer decides to make use of the FLAT termination ID format, then
such termination id is to be configured for each of the terminations.
The FLAT termination ID can be provisioned in two different ways:
• By initiating a single “create” command per termination and provisioning the value
for the Flat Termination ID.
• By initiating a batch “create” command for a series of terminations (typically within
the limits of a voice LT board). In this case, the operator doesn't provision a value
for the Flat termination ID parameter. The system autonomously creates the
terminations for a voice LT board and assigns autonomously the value of the Flat
Termination ID, starting from 1 or previously successfully completed “create”
command. and increment it by 1 for every subsequent termination being created.
If the customer decides to make use of the HIERARCHICAL termination ID format,

then the desired pattern is to be configured once and the system will autonomously
create the appropriate hierarchical termination id for each of the terminations.
It must be noted, that in this case also the flat termination ID is to be configured for
each of the terminations as this is still internally used by the Voice access node.

The provisioning of the POTS and ISDN PRA SIP Integrated Voice Service service
parameters happens via the a CLI / SNMPv3 (MIB) management interface together
with a CDE.tar file downloaded from a file server.
The CDE.tar file includes the SIP Service Profile(s) as well as the CDE profiles for
the different voice HW boards that will be equipped in the access node.
Configuration by means of DHCP is optionally supported.
The SIP Integrated VoIP service cannot be managed via TL1. Although, as an
exception, VoIP service alarms can be retrieved via TL1.

All CLI or SNMPv3 commands to manage the integrated VoIP service are addressed
to the public OAM IP address of the voice access node.
13.9.3 CESoPSN Service

The provisioning of the CESoPSN service parameters happens via the a CLI /
SNMPv3 (MIB) management interface together with a CDE.tar file downloaded from
a file server. The CDE.tar file includes the CDE profile for the voice HW boards that
will be equipped in the access node.

NT
The CESoPSN service cannot be managed via TL1.

All CLI or SNMPv3 commands to manage the CESoPSN service are addressed to
the public OAM IP address of the voice access node.
13.9.4 CDE Profile

Besides the usual management interface to configure the network infrastructure, the
SIP / H.248 Protocol Stack, the SIP / H.248 termination parameters for the integrated
POTS / ISDN voice service and the parameters for the CESoPSN service, the voice
access node makes use of additional configuration input under the format of a
downloadable file.
Allowing the integrated voice and CESoPSN service to become fully operational
requires the presence of the CDE profile at the access node.
The content of CDE profile is customer dependent and generated by ALU. The
content is collected by means of a questionnaire that is filled in by the customer. The
content is considered to be of static nature and mainly deals with the Z- or
E1-interface and its HW characteristics.
Different CDE profiles are generated for the different forms of telephony i.e. the
POTS service and the ISDN service, as well as the different HW boards suppported
by the integrated voice and CESoPSN service.
The CDE profile is signaling protocol independent meaning that a CDE profile
generated for a particular form of telephony can be used by both the H.248 and the
SIP Signaling based integrated voice service on the condition that this form of
telephony is supported by both integrated voice services.
The CDE profiles are delivered to the customer in the format of CDE.tar file, together
with the SW package and all other associated files that are required to install a Voice
access node in the access network. This file must be downloaded and activated in
the Voice cluster and /or individual Voice access nodes (product and integrated voice
service dependent).
The system itself takes care of the further downloading of the different CDE profiles
to the suitable HW entities.
The system supports CDE profile upgrade. They are an integral part of the offline
database migration during software upgrade.

NT
13.9.5 SIP Service Profile

The SIP Integrated Voice Service has introduced the concept of “Service profile” to
achieve a maximum on flexibility for:
• IOT with multiple Application Servers, including the flexibility of a new IOT during
a Maintenance phase of an ISAM release.
• re-using application SW; as such, application SW shall be data driven, based on
the selected options out of the SIP Service profile.
The content of the Service profile is customer dependent. It is generated by the BU

with the content based on the voice service and call flow requirements defined by the
customer.
A different Service profile is created for the SIP POTS voice service and the SIP
ISDN PRA / CAS R2 service (SIP ISDN PRA and SIP CAS R2 parameters
concatenated into a single Service profile).
A Service profile supports either the SIP tightly mode or the SIP loosely coupled
mode.
A CDE.tar file includes the CDE profiles for the different LT board types (POTS or
ISDN PRA / CAS R2) that are equipped in the ISAM node.
The Service profile that applies to a particular voice service is appended to the CDE
profile of the LT board that serves that same voice service.
Up to 5 different POTS Service profiles can be appended to the CDE profile of a
POTS LT board type.
Only one ISDN PRA / CAS R2 Service profile can be appended to the CDE profile of
the ISDN PRA / CAS R2 LT board type.
A Voice Service Gateway (VSG) needs an association with a Service profile present
in the activated CDE profile.
By default (no Service profile name configuration input received for the VSG), the
Service profile with the lowest ID found in the LT board type CDE profiles (different
voice services) of the activated CDE.tar file is assigned to the Voice Service
Gateway.
The system raises an alarm "SSP missing" upon changing the Admin state of a VSG
from down to up, in case this VSG is associated with a Service profile that is not
found in the activated CDE.tar file.
The alarm gets cleared when either another Service profile (found in the CDE.tar file)
is associated with the VSG or another CDE.tar file is activated with this configured
Service profile present in that CDE.tar file or the VSG gets associated with the default
Service profile.

NT
13.10 Permanent data storage
13.10.1 Megaco Integrated Voice Service

The VoIP service configuration data is archived by the VoIP database(s) stored on
the system disk.
The voice database is managed by the integrated voice service management agent.
Voice Cluster Topology:
The system maintains a separate voice database for each of the Voice packet
servers. Up to eight VoIP database(s) may be present on the system disk.
A voice database at the Voice packet server temporary archives the configuration
data received via the usual voice service management interface. At regular time,
each Voice packet server uploads its voice database to the system disk.

The VoIP provisioned data is archived by the VoIP database stored on the system
disk of the NT. The VoIP database is managed by integrated voice service
management entity hosted at the NT board.

The CESoPSN service provisioned data is archived by the CESoPSN database
stored at the NT's system disk. The CESoPSN database is managed by the
CESoPSN management entity hosted at the NT board.
13.11 Management model

Figure 156 shows the Megaco Integrated Voice Service conceptual management
model.

NT
Figure 156 Megaco Integrated Voice Service Conceptual Management

Model
Read-only H.248 Protocol and Network Management Model
Read-Write
Equipment Equipment
Base Class Board 1..24 Node
1
1 0..32
1
File Input 0..72 1 1
1
H.248 0..5000 Voice XLES
Termination Server
1 1 1
0..1 0..1 1 0..1

1..N 1..N 1
POTS ISDN Media
Line Line Gateway
0..72 0..24 1
1 1 0..1
POTS ISDN Signaling Line Id Syntax
LT Board LT Board Gateway 1..2 Profile
Voice
LT Board
1 1
LT Board POTS ISDN Voice Server

CDE Profile CDE Profile CDE Profile
NT Board CDE Profile
VoIP NarrowBand Line Test Management Model
Line Test
Session Voice Server
Parameters 1..1024 1
1 1
1 1
1..72 1
Available
Line Identity Session
1..N
Session
Report
VoIP Database Model
VoIP Database Voice Server

1 1
• The classes “SYSTEM”, “NT”, “LT Board” and “Voice Server” reflect the Access
Node, the Network Termination, the Line Termination and Voice server hardware
being involved in the integrated voice service.

NT
These classes are not further elaborated in subsequent sections.

• The class “Voice LT Board” is an instantiation of the class “LT Board”.
This class is not further elaborated in subsequent sections.
• The classes “POTS LT Board” and “ISDN LT Board” are instantiations of the class
“Voice LT Board”. This class is not further elaborated in subsequent sections.
• The classes “POTS Line” and “ISDN Line” are instantiations of the class “H.248
Termination”.
The class “H.248 Termination” is elaborated in subsequent sections.
• The class "H.248 Termination" is an instantiation of the classes "POTS Line" and
"ISDN Line".
The class “H.248 Termination” is elaborated in subsequent sections.
• The classes “POTS CDE Profile”, “ISDN CDE Profile” and “Voice Server CDE” are
instantiations of the class “CDE Profile”.
The class “POTS CDE Profile” is elaborated in subsequent sections.
13.11.1.1 H.248 Protocol and Network Management Model.

This management model offers the capability to provision the Voice Cluster, the
Media and Signaling gateway as well as the network related H.248 protocol
parameters.
A Voice Cluster is the aggregation of the Voice access node controlled by a single
Voice Server (pair). The entire Voice Cluster is provisioned by means of the following
2 classes:
• The class “EquipmentNode” includes the attributes and methods that allow the
provisioning of the Voice access nodes that belong to the voice cluster.
• The class “EquipmentBoard” includes the attributes and methods that allow the
provisioning of the Voice LT boards that belong to each of the voice access nodes
in the voice cluster.
The class “Media Gateway” includes the attributes and methods that allow the
provisioning of the H.248 protocol, L2 and L3 network connection and the network
redundancy parameters as well as the quality of service characteristics for the
signaling as well as the voice stream.
The class “H.248 Termination” includes the attributes and methods that allow the
provisioning of the individual POTS or ISDN termination characteristics.
The class “XLES” includes the attributes and methods that allow the provisioning of
the internal Voice cluster signaling characteristics.
The class “Signaling Gateway” includes the attributes and methods that allow the
provisioning of the L3/L4 and network redundancy characteristics of the Assignment
Source Point (ASP).
The Class “Line Id Syntax Profile” includes the attributes and methods that allow the
provisioning of the POTS and / or ISDN termination ID format.

NT
The classes “POTS CDE Profile”, “ISDN CDE Profile” and “Voice Server CDE
Profile” include the attributes and methods that allow the provisioning of the physical
subscriber line, the Z-interface, the tone pattern, the protocols that run at the end
user side and LT board hardware characteristics.
13.11.1.2 VoIP Database Model

The class “VoIP Database” includes the attributes and methods that allow managing
the SIP Voice Database.
13.11.1.3 VoIP Narrowband Line Test Management Model

The class “Available Session” includes the attributes and methods to schedule a new
narrowband line test session.
The class “Session” includes the attributes and methods that allow the provisioning
of the narrowband line test session characteristics.
The class “Line Identity” includes the attributes and methods that allow the
provisioning of the subscriber lines involved in the narrowband line test session.
The class “Line Test Parameters” includes the attributes and methods that allow the
provisioning of the parameters to be considered in the course of a narrowband line
test session.
The class “Session Report” includes the attributes and methods that allow retrieving
the results of the completed narrowband line test session.

The following figures show the SIP Integrated Voice Service conceptual
management models.

NT
Figure 157 SIP Protocol and Network Conceptual Management model
1 0..144 0..1296
Session Timer [1] VSG [1..17]
RW 0..1 1 RW ISDN PRA / CAS R2 POTS
1 TerminationRW TerminationRW
Dial Plan [1..16]
1 0..1 0/1/2
RW
1 1 1
1
1 ISDN PRA / CAS R2 POTS
User Agent [1..16]
1..256 (Max 4K) RW Line Line
Digit Map [1..16] 1 8 48/72

RW
1..18 1 1
Line Id Syntax
Profile [1] RW User Agent ISDN PRA / CAS R2 POTS
1 LT Board
Access Point RW LT Board
SIP Server [1..128]

RW 1..N
1 1 Voice
SIP Timers [1]
RW LT Board
DNS Server [0..96]
RW 0..6
DHCP
Authentication [72]
1..4 RW LT
Common to all VSG Board
Transport
Protocol [1..16] RW 1 1 SIP Redundancy
Comnand [1]
RW
NT
Registration [1..17]
RW 1
SIP Port State
Multiple Service [1296] RO
Profile [5] RO 1..1296
1
Network
Redundancy RW
1
Network Redundancy LSA Server [1]
TCA Threshold [1] 1..576 State [576] RO RW
RW 1
1 1
8
Stats Config [1] LSA ServerInstance
DHCP SIP Server
RW 1 [8] RW
1 [16] RO

NT
Figure 158 Performance Monitoring Conceptual Management Model - POTS
Per-Port Per-Call Per-Board Per-System
96 1920 1
Stats Previous N Stats Previous Stats Previous Stats Configurfed
15 min RO 15 min RO 15 min RO Available Ports RO
1
1 Stats Current 20 Stats Configured
Stats Current
15 min RO 15 min RO UnAvailable Ports RO
3 60 1
Stats Previous Stats Previous Stats Spare Ports
1 day RO 1 day RO RO
1 20
Stats Current Stats Current
1 day RO 1 day RO
1 1
Stats Performance Stats Performance
Info RO Info RO

NT
Figure 159 CDE File Conceptual Management model
1 0..144 0..1296
SIP SIP
SIP Service Profile VSG [1..17]
1 RW Termination RW Termination RW
1
0..1 0..1
1 1
1
POTS CDE Profile ISDN PRA / CAS R2 POTS
Line Line
8 48/72
1
1..18
CAS R2
CDE Profile POTS
LT Board
1
1..18
ISDN PRA / CAS R2
LT Board
CDE Profile
ISDN PRA
1 CDE Profile
1..18
Voice
LT Board
LT
Board
NT
Figure 160 Narrowband Line Test Conceptual Management Model

LINE ID [72] NBLT Session [16] NT
RW RW
1..72 1 0..16
NBLT Parameters
[1024] RW
0..N
Vendor Info
[256] RO
NBLT Report
[57600] RO
0..N
Busy Port
[1152] RO
1..N
• The classes “NT” and “LT Board” reflect the Network Termination and the Line
Termination hardware being involved in the integrated voice service.

NT

• The classes “POTS LT Board” and “ISDN PRA / CAS R2 LT Board” are an
instantiation of the class “Voice LT Board”.
• The class “SIP POTS Termination” is an instantiation of the class “POTS Line”.
The class “SIP POTS Termination” is elaborated in subsequent sections.
• The class “SIP ISDN PRA Termination” is an instantiation of the class “ISDN PRA
Termination Line”.
The class “SIP ISDN PRA Termination” is elaborated in subsequent sections.
• The class “SIP CAS R2 Termination” is an instantiation of the class “SIP ISDN
PRA Line”.
The class “SIP CAS R2 Termination” is elaborated in subsequent sections.
• The class “POTS CDE Profile” is an instantiation of the class “CDE Profile”.
The class “POTS CDE Profile” is elaborated in subsequent sections.
• The class “ISDN PRA CDE Profile” is an instantiation of the class “CDE Profile”.
The class “ISDN PRA CDE Profile” is elaborated in subsequent sections.
• The class “CAS R2 CDE Profile” is an instantiation of the class “CDE Profile”.
The class “CAS R2 CDE Profile” is elaborated in subsequent sections.
13.11.2.1 SIP Protocol and Network Management Model

This management model offers the capability to configure both the SIP protocol and
the L2/L3/L4 network attributes for the integrated voice service
The class "VSG" includes the attributes and methods that allow to configure the
Voice Service Provider or Voice Access Gateway properties.
The class “SIP Timers” includes the attributes and methods that allow to configure
the SIP protocol timers.
The class “Dial Plan” includes the attributes and methods that allow to configure the
dial plan(s).
The class “Digit Map” includes the attributes and methods that allow to configure the
Digit Map(s).
The class “SIP Server” includes the attributes and methods that allow to configure
the list of SIP first hop servers.
The class “DNS Server” includes the attributes and methods that allow to configure
the pool of DNS servers.
The class “Session Timer” includes the attributes and methods that allow to configure
the Session Timer extension of the SIP protocol.
The class “Line Id Syntax Profile” includes the attributes and methods that allow to
configure the POTS / ISDN PRA / CAS R2 termination ID format.

NT
The class “Transport Protocols” includes the attributes and methods that allow to
configure the underlying transport protocol for SIP as well as the L4 port to which the
SIP User Agent will listen to for incoming SIP requests.
The class “Registration” includes the attributes and methods that allow to configure
the SIP Register URI and other parameters.
The class “Network Redundancy” includes the attributes and methods that allow to
configure the SIP first hop redundancy parameters, including with the expected SIP
User Agent redundancy behaviour.
The classes “User Agent” and “User Agent Access Point” includes the attributes and
methods that allow to configure the L2/L3 network connection parameters as well as
the QOS settings for the signaling and voice streams.
The class "TCA Threshold " includes the attributes and methods that allow to
configure the alarm crossing threshold per SIP termination.
The class "Stats Configuration" includes the attributes and methods that allow to
configure the performance monitoring parameters.
The class "DHCP Authentication" includes the attributes and methods that allow to
configure the DHCP authentication parameters.
The class "SIP Port State" includes the attributes and methods that allow to display
the SIP termination line/call state.
The classes “POTS Termination”, “ISDN PRA Termination” and “CAS R2
Termination” include the attributes and methods that allow to configure the SIP
POTS / ISDN PRA / CAS R2 termination and its parameters.
The class "Multiple Service Profile" includes the attributes and methods that allow to
display the SIP Service Profiles that are downloaded and activated in the access
node.
The class "DHCP server" includes the attributes and methods that allow to display
the SIP First Hop Server IPaddress/FQDN retrieved via DHCP Option 120.
The class "LSA server" includes the attributes and methods that allow to
enable/disable the LSA server system and to configure the overall system
parameters.
The class "LSA server Instance" includes the attributes and methods that allow to
configure a Local Stand Alone SIP server instance and its parameters.
13.11.2.2 Performance Monitoring Management Model

This management model offers the capability for viewing performance data of the
SIP POTS termination and the voice LT board, both in real time and from log files.
The class "Per-Port Stats Current 15 min" includes the attributes and methods that
allow to retrieve the per-port statistics during the current 15-minutes interval.

NT
The class "Per-Port Stats History 15 min" includes the attributes and methods that
allow to retrieve the per-port statistics for the past 96 15-min intervals.
The class "Per-Port Stats Current 1 day" includes the attributes and methods that
allow to retrieve the per-port statistics during the current 1-day interval.
The class "Per-Port Stats History 1 day" includes the attributes and methods that
allow to retrieve the per-port statistics for the past 3 1-day intervals.
The class "Per-Board Stats Current 15 min" includes the attributes and methods that
allow to retrieve the per-board statistics during the current 15-minutes interval.
The class "Per-Board Stats History 15 min" includes the attributes and methods that
allow to retrieve the per-board statistics for the past 96 15-min intervals.
The class "Per-Board Stats Current 1 day" includes the attributes and methods that
allow to retrieve the per-board statistics during the current 1-day interval.
The class "Per-Board Stats History 1 day" includes the attributes and methods that
allow to retrieve the per-board statistics for the past 3 1-day intervals.
The class "Per-Call Stats History 15 min" includes the attributes and methods that
allow retrieving the per-call measured values for the past 96 15-minutes intervals.
The classes "Per-System Stats Configured Available Ports", "Per-System Stats
Configured Unavailable Ports" and "Per-System Stats Spare Ports" include the
attributes and methods that allow to retrieve the degree of allocation of SIP
terminations in the access node as well as the actual service state of the allocated
SIP terminations.
The classes "Per-Port Stats Performance Info" and "Per-board Stats Performance
Info" include the attributes and methods that allow to retrieve the validity and duration
of the measurements done during the several intervals.
13.11.2.3 CDE File Management Model

This management model offers the capability to provision the physical line interface,
the Z-interface, the tone patterns, the Basic call and Supplementary Services call
flow related parameters.
The provisioning of these parameters happens by means of the CDE profile and the
SIP Service profile. These profiles are included in the CDE.tar file that is downloaded
and activated in the access node. These files are generated in the factory and cannot
be modified by the customer.
The class “SIP Service Profile” includes the attributes and methods that allow to
provision the Basic call and Supplementary service call flows characteristics.
The class “POTS CDE Profile” includes the attributes and methods that allow to
provision the physical subscriber line, the Z-interface, the tone pattern, the protocols
that run at the end user side and the voice LT board HW characteristics.

NT
The class “ISDN PRA CDE Profile” includes the attributes and methods that allow to
provision the physical subscriber line, the Z-interface (E1), the tone pattern, the
protocols that run at the end user side and the voice LT board HW characteristics.
The class “CAS R2 CDE Profile” includes the attributes and methods that allow to
13.11.2.4 Narrowband Line Test Management Model

The class " Session" includes the attributes and methods that allow to configure a
narrowband line test session.
The class “Line Identity” includes the attributes and methods that allow to configure
the ports involved in the narrowband line test session.
The class “Line Test Parameters” includes the attributes and methods that allow to
configure the parameters to be used by the narrowband line test session.
The class “Session Report” includes the attributes and methods that allow to retrieve
the results of the completed narrowband line test session.
13.11.2.5 IF-MIB (SIP POTS Terminations)

The conceptual management model is defined by RFC 1573.
A SIP POTS termination is configured on top of a voiceFXS interface.
The administrative and operational state of a voiceFXS interface are maintained by
the IF MIB and the IF CLI command set.
The administrative and operational state of a SIP POTS termination are maintained
by the SIP MIB and the SIP CLI command set.
For the support of the administrative state of the voiceFXS interface [interface type
102 (VoiceFXS)], the ifAdminStatus object of the ifTable in the IF-MIB is maintained
as READ-ONLY object. With regard to the VoIP service, the ITF manager shall treat
this object as READ-ONLY.
For the support of the administrative state of the SIP POTS termination, the
sipTerminationAdminStatus of the sipTerminationTable in the SIP MIB is maintained
as READ-WRITE object (as actually defined in the SIP MIB)
A voiceFXS interface may exist with or without a SIP POTS termination being
created on top of that voiceFXS interface

NT
Upon the planning of a voice POTS LT board, the Interface Manager auto-creates
the necessary entries (with default values) in the ifTable, ifXTable, ifStackTable,
ifInvStackTable and the asamIfExtTable. The number of voiceFXS interface entries
created in the IF-MIB for a particular voice POTS LT board equals the number of
physical POTS ports available at that same voice POTS LT board.
A voiceFXS interface entry in the IF-MIB cannot be manually deleted by the operator
The VoiceFXS interface entries of a voice POTS LT board become auto-deleted by
the system at the moment the voice POTS LT board gets un-planned
The LinkUp, LinkDown and ChangeOccurred trap is supported for the voiceFXS
interface.

Figure 161 shows the CESoPSN conceptual management model.
Figure 161 CESoPSN Conceptual Management model
0..144
CESoPSN PW CESoPSN PW
Port 1
1
0..1
1
E1 interface
1
1..18
ISDN PRA
CESoPSN
CDE Profile LT Board
CDE Profile
1
1..18
Voice
LT Board
LT
Board
NT
• The classes “NT” and “LT Board” reflect the Network Termination and the Line
Termination hardware being involved in the integrated voice service.
• The class “ISDN PRA LT Board” is an instantiation of the class “Voice LT Board”.
• The class “CESoPSN PW” is an instantiation of the class “E1 Interface”.
The class “CESoPSN PW” is elaborated in subsequent sections.

NT
• The class “CESoPSN CDE Profile” is an instantiation of the class “CDE Profile”.
The class “CESoPSN CDE Profile” is elaborated in subsequent sections.
13.11.3.1 CESoPSN conceptual Management Model

This management model offers the capability to configure a CESoPSN Pseudo wire.
The class "CESoPSN PW" includes the attributes and methods that allow to
configure the pseudo wire properties as well as to display the pseudo wire
operational state.
The class “SIP Timers” includes the attributes and methods that allow to configure
the SIP protocol timers.
The class "CESoPSN PW Port" includes the attributes and methods that allow to
display the source UDP port that is autonomously allocated by the system for the
pseudo wire.
The class "CESoPSN CDE Profile" includes the attributes and methods that allow to
13.12 SIP Integrated Voice Service: Shared Line

Connection
The shared line connection is an optional configuration that offers the capability to
connect two SIP POTS terminations to one subscriber line.
ISAM allows an operator to create both SIP POTS terminations for paired phones
connected to a shared line.
Paired phones share the same if-index but have a different directory number.
From a HW perspective, this technology uses central paired equipment located in the
central office and subscriber units providing separation of circuits based on diodes.
When a shared line service is deployed on a single subscriber line, the physical line
will connect to a specific blocker that will separate two physical lines and connect two
POTS phones.

NT
There are different types of blockers. Some examples:

• Blockers having two POTS ports: in this case, the blocker will do the actual POTS
port separation. This type of blocker typically could be installed outside the house
(for example in a MDF cabinet, or somewhere in a facility room in an apartment
complex).
• “Individual" line blockers which have only one POTS port. As such individual
blockers all have the same design, the two shared users have the a/b wires
coming from the CO connected in a "reversed" way for the prime and the
secondary port for the "blocker" function to work correctly.
Only one SIP POTS termination can make an outgoing or incoming call at a time.
While one SIP POTS termination is involved in a call, the other SIP POTS termination
becomes internally blocked, meaning that if that other SIP termination goes off-hook,
then it hears silence (no dial tone is put at that line) and an incoming call for that
internally blocked SIP termination is rejected by the system.
When one of the SIP terminations is involved in a call, an incoming call for the other
SIP termination is rejected with a 486 'Busy Here'.
An incoming call is received only by one SIP termination: only the phone of the SIP
termination whose number has been dialed will ring.
The two POTS phones have different directory numbers, different configurations,
and the prime term will implement the prime termination specific together with the
common configuration while the secondary term will implement the secondary
termination specific configuration.
Operators can configure at maximum 82 SIP POTS terminations at a voice LT board
regardless the mixture of shared line and non-shared line connections.
The registration of the SIP terminations configured on top of a shared subscriber line
as well as the supported services are identical to SIP terminations configured on top
of a non-shared subscriber line, with following exceptions:
• The "Line Power Feeding when not registered" feature is not supported.
• NBLT is not supported for a shared subscriber line.
• Per-Port / Per-call / Per-Board and Per-System PM statistics are not supported at
voice LT boards with shared subscriber lines being configured.
13.13 H.248 Integrated Voice Service: Shared Line

Connection
The shared line connection is an optional configuration that offers the capability to
connect two H.248 POTS terminations to one subscriber line.
ISAM allows an operator to create both H.248 POTS terminations for paired phones
connected to a shared line. Both H.248 POTS terminations are configured with the
same equipment ID and Port ID but with a different Termination ID and directory
number.

NT
Operators can configure at maximum 82 H.248 POTS terminations at a voice LT

board regardless the mixture of shared line and non-shared line connections.
The prime term will implement the prime termination specific together with the
common configuration while the secondary term will implement the secondary
termination specific configuration.
From a HW perspective, this technology uses central paired equipment located in the
central office and subscriber units providing separation of circuits based on diodes.
When a shared line service is deployed on a single subscriber line, the physical line
will connect to a specific blocker that will separate two physical lines and connect two
POTS phones.
There are different types of blockers. Some examples:
• Blockers having two POTS ports: in this case, the blocker will do the actual POTS
port separation. This type of blocker typically could be installed outside the house
(for example in a MDF cabinet, or somewhere in a facility room in an apartment
complex).
• “Individual" line blockers which have only one POTS port. As such individual
blockers all have the same design, the two shared users have the a/b wires
coming from the CO connected in a "reversed" way for the prime and the
secondary port for the "blocker" function to work correctly.
Only one H.248 POTS termination can make an outgoing or incoming call at a time.
While one H.248 POTS termination is involved in a call, the other H.248 POTS
termination becomes internally blocked, meaning that if that other H.248 termination
goes off-hook, then it hears silence (no dial tone is put at that line) and an incoming
call for that internally blocked H.248 termination is rejected by the system.
An incoming call is received only by one H.248 termination: only the phone of the
H.248 termination whose number has been dialed will ring.
The supported services are identical to H.248 POTS terminations configured on top
of a non-shared subscriber line, with following exception:
• NBLT is not supported for a shared subscriber line.
13.14 Number Manipulation Rules

The NE supports system-wide as well as termination specific rules. A system-wide
rule applies to all terminations configured in the NE.
A termination specific rule applies to a single or a subset of the terminations
configured in the ISAM node. For such rule an explicit assignment needs to be
manually configured per termination for which the rule applies.

NT
13.14.1 SIP POTS Integrated Voice Service

A System-wide rule as well as a termination specific rule needs to be manually
configured by the operator via the usual CLI/SNMP management interface.
System-wide as well as termination-specific rules assigned to a particular POTS
termination are every time again checked and executed upon the receipt of the
original outgoing call attempt for that same POTS termination.
System-wide rules are checked and executed according the increasing rule id found
in the rule table. System-wide rules are checked prior to the termination-specific
rules. Termination-specific rules are checked and executed from right to left (based
on the order configured in the termination's rule set object).
When a matching rule is found and executed, Tthe system proceeds with checking
for that particular termination, whether system-wide or termination-specific rules with
other key-phrases might apply
Overview of the supported POTS termination-specific rules:
Table 24 SIP ISDN PRA: Supported number manipulation rules
Supported Description Supported for

Key-Phrases and
associated Outgoing Incoming
parameter(s) call call
out-dialedprefix- Replace the dialled prefix with out-prefix of calling number Yes No
outprefix Defined as termination-specific rule
Parameters:
<Dialled Prefix>
<Out Prefix>
13.14.2 SIP ISDN PRA Integrated Voice Service

A system-wide rule as well as a termination specific rule needs to be manually
System-wide and/or termination specific rules assigned to a particular ISDN-PRA
termination are every time again checked and executed upon the receipt of an
incoming / outgoing call attempt for that same ISDN-PRA termination.
on the order configured as found in the termination's rule set object).
When a matching rule is found and executed, the system proceeds with checking for
that particular termination, whether system-wide or termination-specific rules with
other key-phrases might apply.

NT
Overview of the supported ISDN-PRA system-wide and termination-specific rules:

Table 25 SIP ISDN PRA: Supported number manipulation rules

Key-Phrases
and associated Outgoing Incoming
inc-add-phone- Convert number in 'From' and "phone-context" tag into calling No Yes
context-to- number with a prefix.
number If the calling number in the "From" header is a local or national
number, then add the phone-context value (country code or
country-area code) to the calling number.
The inc-add-phone-context-to-number" rule is only applicable
in case of TEL URI.
inc-short-number- Replace number in 'To' tag by the extension of the called No Yes
len number.
Parameter:
<Short Number
Length>
outg-use-default- Replace the calling number by the 'pilot number' (default PBX Yes No
pbx-number number).
Parameter: Only when the calling party number is invalid and the rule is
<Numeric Value> configured as 'outg-use-default-pbx-number:1', the calling
number is replaced by the default PBX number.
The rules outg-use-default-pbx-number and
outg-add-prefix-in-cpn are Mutual Exclusive, that is, both rules
must not be simultaneously associated with a SIP ISDN PRI
termination created on behalf of an ISDN PRI PBX that
provides a "partial" calling party number.
outg-add-country- Add phone-context to the 'To' tag (number itself is not Yes No
area-code-in-pho changed)
ne-context • For local number, add country-area code in phone context.
Parameters: • For national number, add country code in phone context
<Country Code> • For international number, don't add phone context
<Area Code> parameter.
The rule applies to SIP INVITE requests with the 'TEL URI'
scheme only.
This rule is mutual exclusive with the
'outg-add-domain-name-in-phone-context' meaning that it
cannot be assigned to an ISDN-PRA termination together with
the 'outg-add-domain-name-in-phone-context'.
outg-add-domain- Add the domain name to the phone-context: Yes No

name-in-phone-c Add a "phone-context" to the "TO" header in the outgoing SIP
ontext invite request. The "phone-context" being added is to be
understood as the SIP first hop server address name
addressed by this SIP invite request.
This rule is mutual exclusive with the
'outg-add-country-area-code-in-phone-context' meaning that it
cannot be assigned to an ISDN-PRA termination together with
the 'outg-add-country-area-code-in-phone-context'.
(1 of 2)

NT

Key-Phrases
outg-add-prefix-in The number screening and mapping procedure supported in Yes No

-cpn this release has a limited scope.
Parameter: For ISDN-PRI PBX's that provide a "partial" calling party
<CgPnLength> number (that is, the PBX just provides the digits specific to the
Direct-Dialling-In service), the MSAN supports the
configuration of a digit manipulation rule, that is
"outg-add-prefix-in-cpn: CgPnLength", that allows to
complement the received "partial" calling party number with
the missing prefix of the default PBX number (GDN) as to
become a "complete" E.164 telephone number.
Should such rule not be configured upon the receipt of an
originating call attempt including a partial CgPn, the MSAN
considers the received partial number (the received digits in
CgPn IE) as an invalid DN and replaces the received digits in
CgPN IE by the configured global default number (GDN) of the
PBX before to proceed with the call set-up.
In case such digit manipulation rule is configured for the ISDN
PRI PBX with partial number property and the CgPnLength
parameter is set to the length of the partial number (usually the
number of received digits in CgPn IE equals 3 or 4), then upon
the receipt of an originating call attempt, the MSAN will derive
the missing digits (that must precede the digits received in the
CgPn IE in order to shape a "complete" E164 telephone
number) from the configured default PBX number (GDN) and
add the missing digits to the received CgPn IE content. This
completed E164 telephone number is then used during the
further proceeding of the call set-up.
The rules outg-use-default-pbx-number and
outg-add-prefix-in-cpn are Mutual Exclusive, that is both rules
must not be simultaneously associated with a SIP ISDN PRI
termination created on behalf of an ISDN PRI PBX that
provides a "partial" calling party number.
This rule is introduced as a temporary solution in this release.
(2 of 2)
13.14.3 SIP CAS R2 Integrated Voice Service

A system-wide rule as well as a termination specific rule needs to be manually
System-wide and/or termination specific rules assigned to a particular CAS R2
termination are every time again checked and executed upon the receipt of an
incoming / outgoing call attempt for that same CAR R2 termination.
on the order configured as found in the termination's rule set object).

NT
When a matching rule is found and executed, the system proceeds with checking for
that particular termination, whether system-wide or termination-specific rules with
other key-phrases might apply.
Overview of the supported CAS R2 system-wide and termination-specific rules:
Table 26 SIP CAS R2: Supported number manipulation rules

Key-Phrases
inc-short-number- Replace number in 'To' tag by the extension of the called No Yes
len number.
Parameter:
<Short Number
Length>
inc-del-local-coun Remove digits from the calling and called party received in No Yes
try-code-in-cpn order to send it via R2 address signaling. For the calling party
Parameter: number, the "+CC" will be deleted before sending it in the R2
signaling. For the called party number, the number of digits to
<countrycode> be deleted may be more than just "+CC". In some cases, only
the last four digits of the called party are requested to be sent
in the R2 signaling.
outg-add-country- Add digits to the calling party number received via R2 address Yes No
area-code-in-cpnt signaling in order to populate the appropriate headers in SIP
Parameters: with a full E.164 number. Since the subscriber number format
has a fixed length the provisioning will be restricted by defining
<Country Code> if the received number will be appended with "+CC" or "+CC
<Area Code> Area Code".
13.15 Reliability, Equipment / Connectivity /

Overload Protection
13.15.1 Equipment Protection
13.15.1.1 H.248 Integrated Voice Service: Media Gateway

redundancy
The Media Gateway may be installed as a 1+1 Redundancy pair. Both Media
Gateways of a 1+1 redundancy pair must be equipped in adjacent slot positions.

NT
One Media Gateway is active while the other runs in standby mode. In case the
active Media Gateway encounters a hardware or a software problem, the standby
Media Gateway takes over and becomes the active Media Gateway for the voice
cluster.
Upon switchover, the recovery time is less than 7 s for call signaling and less than 3
s for voice traffic.
Stable calls are not lost during the switchover. Non-stable calls, that is, calls in the
set-up phase may be lost due to a Media Gateway switchover. This applies to both,
POTS and ISDN BRA calls.
13.15.2 Connectivity Protection

Besides the support of Spanning Tree Protocol (STP), Rapid Spanning Tree Protocol
(RSTP) or Multiple Spanning Tree Protocol (MSTP) and Link Aggregation Control
Protocol (LACP) on the network links of the Voice access node, some additional,
more voice specific connectivity protection concepts are introduced.
13.15.2.1 H.248 Integrated Voice Service: Network

Connectivity Protection
Voice Cluster Topology:
"Network Connectivity Protection" is also known as "Path Connectivity Check and
Protection" (PCCP).
This protection technique aims at consolidating the connectivity between an access
node running the H.248 Integrated Voice Service and a network device, mostly its
default gateway.
The Network Connectivity Protection must not be active when the Voice access node
behaves as routing device.
For further details about Network Connectivity Protection: ref. Section
chapter “Failure protection and redundancy provisions in ISAM”.
13.15.2.2 Megaco Integrated Voice Service: Redundancy

Redundancy implies the provisioning of multiple Softswitchs / ASPs with each of
these Softswitches / ASPs being provisioned with an IP address and UDP/SCTP
port, and allowing, in case of a failure of the primary control association, to make a
switch-over to another Softswitch / ASP preserving of stable calls. It is to be noted
that the possibility to preserve stable calls during a switch-over depends on the
capabilities supported by the Softswitch / ASP.

NT
The system autonomously notifies the operator about control association changes
via SYSLOG notifications.
A SYSLOG notification is sent upon:
• The control association being lost due to:
• Timer expiry
• Heartbeat expiry
• The control association being administratively locked by the operator.
• The control association being disconnected due to a handoff, forced, graceful
service change method initiated by MG / MGC or disconnect service change
method initiated by the MG.
• The control association being established with the MGC
A failure of the current control association may be detected as described hereafter:
• Upon no reply received on a transaction request initiated by the MG:
Megaco Integrated Voice Service allows to provision the maximum number of
retries per transaction together with the retry mode. The latter being either the
fixed retry interval mode or the increasing retry interval mode. In the latter case,
the retry interval doubles for each subsequent retry.
• Through the support of the Inactivity Timer package:
The purpose of this package event is to allow the MG to detect periods of silence
of messaging from the MGC. Once the period of silence exceeds a threshold, the
MG assumes a control connection failure with that MGC.
• Active Heartbeat mode:
The MG checks the connectivity with the MGC at regular time interval by means of
the “notify” package. The following modes are supported:
- Configured heartbeat interval: The interval by which the “notify” packages are
initiated by the MG is provisioned.
- Learnt heartbeat interval: The interval by which the “notify” packages are initiated
by the MG is learnt from the “Inactivity Timer” package notification of the MGC.
The system decides upon a failure of the current control association from the moment
7 subsequent “notify” packages were not replied by the MGC.
A “Notify” package is sent on the condition that no other Megaco message is received
from the MGC within the learnt/configured heartbeat interval.
• Passive Heartbeat mode:
The MGC checks the connectivity with the MG at regular time interval by means of
the “audit” package. The following modes are supported:
- Configured heartbeat interval: The interval by which the “audit” packages are
initiated by the MGC is provisioned.
- Learnt heartbeat interval: The interval by which the “audit” packages are initiated by
the MGC is dynamically learnt by the MG. The MG awaits 3 consecutive “audit”
packages from the MGC to calculate the heartbeat interval.
The system decides upon a failure of the current control association from the moment
8 subsequent heartbeat intervals have passed without receiving neither an “audit”
nor a regular Megaco package from the MGC.

NT
13.15.2.3 LOCAL and GEO-Redundancy (POTS and ISDN BA)

Figure 162 LOCAL and GEO redundancy
GEO Redundancy
H.248 control
associaon
Site 1 10.190.28.36:2944 Site 2 10.190.28.56:2944
MGC MGC MGC MGC

Main Standby Main Standby
ASP ASP ASP ASP

Main Standby Main Standby
Acve Standby Acve Standby

10.190.28.36:9900 10.190.28.36:9901 10.190.28.56:9900 10.190.28.56:9901
IUA /SCTP connecon
LOCAL Redundancy
ALU MSAN
10.190.19.54:2944 10.190.19.54:9900
Single MG IP@ & port Single SCTP/IUA IP@ & port
The Voice 's Megaco management interface allows to configure:

• A single Media Gateway IP address and UDP port.
• Up to four Media Gateway Controller IP addresses and associated destination
UDP ports.
• A single Signal Gateway IP address (ASP SCTP port number is hard-coded to
9900)
• Up to four ASP IP addresses and associated destination SCTP ports.
Network Local-Redundancy implies the provisioning, at the Voice access node side,
of:
• either a single MGC and a single Application Server Process (ASP). At the
network side, both instances of the MGC together with both instances of the ASP
share the same IP address; see Figure 163.
• or a single MGC and two ASP instances.
At the network side, both instances of the MGC share the same IP address while
each instance of the ASP owns a different IP address which is different form the
IP address shared by the Softswitch instances; see Figure 164.

NT
Figure 163 Single MGC and single ASP
ISAM Voice MGC1

Active
n
MG/SG tio IP@_1
cia
s so
o la ASP1
ntr
8 co n Active
.24 iatio
H ol assoc
contr IP@_1
IP address of MGI SCTP
IP address of SGI
H.248
contr MGC2
SC ol ass
TP ociati Standby
on
co
ntr
ol IP@_1
as
so
cia
tio ASP2
n
Standby
IP@_1
Figure 164 Single MGC and two ASPs
ISAM Voice MGC1

Active
ion IP@_1
MG/SG iat
soc
l as ASP1
ntro
8 co Active
on
.24 ociati
H ol ass
contr IP@_2
IP address of MGI SCTP
IP address of SGI
H.248
contr MGC2
SC ol ass
TP ociati Standby
on
co
ntr
ol IP@_1
as
so
cia
tio ASP2
n
Standby
IP@_3
Network Geo-Redundancy implies the provisioning, at the Voice access node side,
of :
• One MGC per GEO site.
Each GEO site supports network local redundancy, this is an active and standby
MGC per site sharing the same IP address.
And :
• A single ASP per GEO site.
At the network side, both instances of the MGC together with both instances of
the ASP share the same IP address.

NT
• Two ASP instances per GEO site.

At the network side, both instances of the MGC share the same IP address while
each instance of the ASP owns a different IP address which is different form the
IP address shared by the Softswitch instances.
The H.248 based integrated Voice service supports:

• A single H.248 Control Association to a single MGC IP address. The H.248
Control Association is always established by the MG.
• A single H.248 Control Association to a local redundant MGC pair sharing the
same IP address. The H.248 Control Association is always established by the MG
(Voice access node).
• A switch-over of the H.248 control association from the currently addressed MGC
to another configured MGC with different IP address.
• A single SCTP connection to a single ASP. The SCTP connection is always
established by the ASP towards the Voice access node. But, the SCTP
connection can be stopped by both the ASP as well as the Voice access node.
• Up to four simultaneous SCTP connections (to four ASP with different IP
address).
• A single SCTP connection to a local redundant ASP pair sharing the same IP
address.
Upon MGC / ASP switch-over, the Integrated Voice service supports preservation of
stable calls on the condition that a MGC / ASP becomes active prior to recovery timer
T(r) expiry.
New POTS / ISDN calls cannot be established during the time period that the
recovery timer T(r) is running.
A network local redundancy MGC switch-over is triggered by the MGC and is fully
transparent to the MG, while a GEO switch-over can be triggered by both, the MGC
as well as the MG and is not transparent to the MG.
A network local redundancy / GEO redundancy ASP switch-over is always triggered
by the ASP and neither the Local redundancy nor the GEO redundancy ASP
switch-over are transparent to the MG (Voice access node).
Usually the following scenario is followed:
• Upon ASP/SCTP switch-over, the new active SCTP instance initiates an SCTP
INIT to the MG.
• Upon the receipt of such SCTP-INIT, the MG starts the recovery timer T(r), does
not remove any termination context and starts queuing Q.931 messages for
terminations involved in a stable ISDN call (Q.931 messages from terminations
involved in calls that have not reached the stable phase are NOT queued).
• In compliancy to RFC4233, the recovery timer T(r) can be configured to a value
in the range 1 - 5 s in the CDE profile
• The MG is able to buffer Q.931 messages for up to 564 stable ISDN calls with the
restriction that only the most recent Q.931 data message is queued.

NT
• Upon the receipt of “ASP active” notification, prior to T(r) expiry, all the buffered
Q.931 messages are sent to the active ASP. The MG gradually forwards the
messages to the new active ASP as to avoid ASP overload.
• Should the recovery timer expire prior to the receipt of an ASP active notification,
then the Voice access node turns the signaling gateway status to operational
down, drops the queued Q.931 messages, removes all ISDN termination contexts
and sends Service Change “904” for all ISDN terminations
Note — The buffer for queueing SCN messages is not

synchronized to the standby Voice Server.
Figure 165 Local MGC switch-over
Site X
10.190.28.36:2944
MGC MGC
Acve Standby
H248
Control
Associaon
ALU MSAN
10.190.19.54:2944
Figure 166 Local ASP switch-over

Site X
10.190.28.36:9900 10.190.28.36:9901
ASP ASP
Acve Standby
SCTPLNK1 SCTPLNK2
ALU MSAN
10.190.19.54:9900

NT
Figure 167 GEO MGC switch-over

Site 1 10.190.28.36:2944 Site 2 10.190.28.56:2944
MGC MGC MGC MGC
Switch-over
H248
Control
Associaon
ALU MSAN
10.190.19.54:2944
Figure 168 GEO ASP switch-over (caused by GEO MGC switch-over)

Site 1 Site 2
10.190.28.36:9900 10.190.28.36:9901 10.190.28.56:9900 10.190.28.56:9901
ASP_1 ASP_2 ASP_3 ASP_4
SCTPLNK2 SCTPLNK3
SCTPLNK4
SCTPLNK1
ALU MSAN
10.190.19.54:9900

NT
13.15.2.4 External ESA-MGC (Emergency Stand Alone)

Redundancy
An external ESA-MGC is to be understood as an MGC that is installed outside (but
in close proximity of) the NE and that supports a minimum feature set, such that the
basic and the emergency call can remain supported in situations of a simultaneous
failure of the usual MGCs (primary, secondary an tertiary). In that respect, it is
assumed that the external ESA-MGC functionality is limited to:
• Basic POTS calls (ISDN calls and supplementary services are not supported
during ESA mode activation).
• Establishing calls between user ports controlled by the MG(s) that has (have) a
control association with the external ESA-MGC.
• Emergency call.
Based on the above, external ESA-MGC Redundancy requires the provisioning of at
least 2 MGCs with the strict condition that the ESA-MGC must be provisioned as the
lowest priority MGC. The provisioning of Primary + ESA-MGC, Primary + Secondary
+ ESA-MGC and Primary + Secondary + Tertiary + ESA-MGC is allowed.
In case of a failure of the Primary (Primary + ESA) or Primary and Secondary
(Primary + Secondary + ESA) MGC or Primary, Secondary and Tertiary (Primary +
Secondary + Tertiary + ESA), the MG will make a switch-over to the MGC with the
lowest priority potentially allowing for the preservation of stable calls. The possibility
to preserve stable calls during a switch-over depends on the capabilities supported
by the MGC.
The access node, from a perception of being an MG, does not have any notion about
the capabilities of a SoftSwitch being configured as primary, secondary, tertiary or
Quaternary MGC. The MG treats all configured MGCs equally.
The MG assumes that:
• The external ESA-MGC accepts “on-hook” notifications for calls that were
established in the course of the control association being established between the
MG and the Primary / Secondary / Tertiary MGC but finished in the course of the
control association being established between the MG and the ESA-MGC.
• The ESA-MGC is responsible to “subtract” the contexts for calls that were
established in the course of the control association being established between the
MG and the Primary / Secondary / Tertiary MGC but finished in the course of the
control association being established between the MG and the ESA-MGC.
• The ESA-MGC is responsible for the alive monitoring of Primary (and Secondary
and Tertiary) MGC when ESA mode is active.
• While the ESA-MGC has an active control relationship with the MG, it shall
continuously monitor all the Primary, Secondary and Tertiary MGC by repeating to
send a ServiceChange message with method = “FailOver SVC Forced”.
• Should a reply “ERROR 403 syntax Error” be received from either the Primary,
Secondary or Tertiary MGC, the ESA-MGC will immediately send a ServiceChange
message with Method = “HandOff” and [Primary/Secondary/Tertiary MGC] address
to the MG.

NT
The capability of the ESA-MGC to poll only one MGC or multiple MGCs does not
have any impact on the access node in its capacity as MG. This may only influence
the time period after which the usual voice service can be resumed.
Control association failure detection and switch-over from

Primary/Secondary/Tertiary MGC to ESA-MGC is identical as described for the
GEO-Redundancy.
13.15.2.5 Co-Located ESA-MGC (Emergency Stand Alone)

Redundancy
The Co-Located ESA-MGC redundancy intends to guarantee the basic voice service
amongst H.248 terminations of the voice cluster that gets isolated from its usual
MGC (pool) by placing the ESA-MGC functions in the voice access node (ESA-MGC
co-located with the Media Gatway). Therefore, supporting Co-Located ESA across
the entire voice network requires deployment in all voice access nodes.
Co-Located ESA allows calling within a voice access node or HUB + Subtending
voice access node, but not across voice access nodes connected via a network link.
For emergency call handling, each voice access node must have connectivity to
emergency services, such as a direct line to a emergency station.
Co-Located ESA functionality enables local calls to be established between the user
ports of a single voice access node ( + Subtending ) when the voice access node (
+ Subtending ) gets isolated from the network. Any subscriber connected to the voice
access node (+ Subtending ) can call any other subscriber connected to the same
voice access node ( + Subtending ).
For emergency call handling during voice access node isolation, a single,
configurable emergency directory number (DN) can be defined (for example, 911,
112). This directory number can be associated to a physical line connected to a local
emergency support resource, such as a police station, hospital, or other emergency
service.
When the Co-Located ESA functionality is enabled, the MG monitors the connectivity
with the primary, secondary, tertiary and quaternary media gateway controller
function (MGC). When a communications loss with the upstream voice network is
detected, the MG switches autonomously to ESA mode. Once ESA mode is active,
the MG keeps on monitoring the primary, secondary, tertiary and quaternary MGC.
When a MGC is operational again, all established calls are dropped and MGC is
reconnected.
During isolation, any POTS subscriber connected to an voice access node ( +
subtending) can call any other subscriber connected to the same voice access node
( + subtending ). To be able to route calls between subscribers, the MG maintains a
database with the DN information associated to the local subscribers. To do this, an
optional subscriber DN field is available on the set of provisionable parameters
associated with a POTS subscriber. This DN value can be established together with
the rest of subscriber data during subscriber provisioning. This field is only used by
the Co-Located ESA application for call routing purposes.

NT
In normal H.248 operation, this internal DN will not be used, just the subscriber
termination identifier.
Working in Co-Located ESA mode, one local port connected to the voice access
node can be configured to receive emergency calls during isolation. The following
points must be considered when working in Co-Located ESA mode:
• Only basic calls are considered under this functionality. Ssupplementary services
are not provided during Co-Located ESA mode activation. .
• This functionality is applicable for POTS services. Integrated Services Digital
Network (ISDN) is not supported in Co-Located ESA mode.
• Co-Located ESA is only supported for local user ports. User ports located on
remote units that are hubbed into the voice access node via VoIP hubbing
functionality are not covered by the Co-Located ESA feature.
13.15.3 SIP POTS Integrated Voice Service: Redundancy
13.15.3.1 SIP Server Redundancy and SIP Server Fail-Over /

Fail-Back
SIP Server Redundancy entails the grouping of individual SIP servers that as a group
can support the ability for a SIP User Agent in the access node to recover and
resume service in spite of a failure of one or multiple of the individual SIP servers.
Figure 169 SIP Server redundancy
L2 / L3 Primary Site
Network
I-CSCF HSS
Voice access node
Site connection S-CSCF

P-CSCF
1_1
First Hop SIP Server Redundancy

Voice access node

NT
The SIP User Agent supports the interworking with a group of “first hop SIP servers”
that form a SIP server redundancy group and whereby all SIP servers get assigned
a different priority. The SIP server with the highest priority acts as the primary SIP
server, while the rest of the SIP servers act as secondary SIP servers. A “first hop
SIP Server” is to be understood as the SIP Server being selected by the SIP User
Agent to send the initial REGISTER/INVITE requests. Such SIP server redundancy
group consist of a primary and one or multiple secondary SIP servers.
A SIP server redundancy group can be provisioned by means of:
• A Domain Name whereby the IP address of the individual SIP servers must be
resolved through the Domain Name Service NAPTR, SRV and A resource record
look-up,
• A list of Fully Qualified Domain Names whereby the IP address of the individual
SIP servers must then be resolved through the Domain Name Service A resource
record look-up,
• A list of IP addresses of the individual SIP Servers.
The SIP User Agent triggers autonomously a SIP server Fail-over upon the failure of
the actually selected first hop SIP server. A failure is to be understood as a situation
where a reply is no longer received for an out-of-dialog SIP request or the receipt of
an unsuccessful response code to an out-of-dialog SIP request. In the course of a
SIP Server Fail-Over, the SIP terminations that are currently registered via the failing
SIP server are moved to another SIP server within the same redundancy group.
The SIP server Fail-over trigger default conditions can be customized by means of
SIP Service Profile provisioning.
Once the failed primary SIP server is back in service, the SIP User Agent triggers
autonomously a SIP server Fail-back. In the course of a SIP server Fail-back, the SIP
terminations that are currently registered via a secondary SIP server are moved to
the primary SIP server within the same redundancy group.
The SIP server fail-back is performed gracefully meaning that the SIP User agent
triggers a fail-back for a SIP termination from the moment it has the on-hook state.
Neither ongoing dialogs nor ongoing transactions are interrupted.
Neither for the SIP server Fail-over nor for the SIP server fail-back ongoing dialogs
and transactions are transferred to the selected fail-over / fail-back SIP server, and
this neither at the signaling plane (SIP) nor at the media plane (RTP).
Once it has been detected that the currently addressed SIP server has failed, the SIP
User Agent triggers a fail-over. Subsequently, the auto-server-failover timer is
started and the SIP User Agent registers the POTS SIP terminations that are in "idle"
state to a newly selected SIP server (Might be the SOS SIP server).
The POTS SIP terminations involved in an ongoing call at the moment the fail-over
is triggered, 'remain connected' to the original signaling and media path and the RTP
traffic will be maintained along that original media path till a subscriber or protocol
event is detected that results in the call to be terminated or the auto-server-failover
timer expiry.

NT
The fail-over for these POTS terminations is until the call has completed or the
auto-server-failover timer has expired.
For SIP Server Fail-over and Session-Refresh, if the session-refresh service is
enabled and in case a fail-over is triggered, the session-refresh timer (if any) will be
restarted and auto-server-failover timer is started.
• Case 1: the session-refresh timer expiry happens prior to the auto-server-failover
timer expiry:
• Upon the session-refresh timer expiry and being the 'refresh' TX-side:
the SIP user agent sends a re-invite/update.
• Upon the session-refresh timer expiry and being the 'refresh' RX-side:
the SIP user agent releases the call immediately.
• If calls (established via the failed SIP server) are no longer ongoing, the
auto-server-failover timer is stopped.
• Case 2: the auto-server-failover timer expiry happens prior to the session-refresh
timer expiry:
• Upon the auto-server-failover timer expiry, the ongoing call(s) (established via the
failed SIP server) are immediately released and the session-refresh timer is stopped.
For SIP Server Fail-back and Session-Refresh, if the session-refresh service is

enabled:
• If a fail-back is triggered while there is still a call (that was established via the
recovered primary SIP server) ongoing and the re-started session-refresh timer
for this call is still running and:
• being the 'refresh' TX-side: the SIP user agent immediately sends the session refresh
message to the recovered primary server.
• being the 'refresh' RX-side: the SIP user agent keeps on counting the restarted
'session-refresh' timer.
secondary SIP server / SOS SIP server) ongoing and the re-started
session-refresh timer for this call is still running, the session-refresh treatment is
not affected since the secondary SIP server is still reachable.
Foreground Service Health Monitoring

NT
Foreground Service Health Monitoring helps the SIP User Agent to rapidly detect
whether the currently selected first hop SIP server can still be addressed for new SIP
requests. Foreground Service Health Monitoring makes use of either the SIP
REGISTER or the SIP OPTIONS Method.
• In case the SIP register method applies, one termination out of the group of
terminations re-registers with a configurable high frequent interval (typically 90 s)
while the rest of the terminations re-register with the usual frequency. The group
of terminations must have the following in common (SIP Termination Group):
• These SIP terminations get the same service route returned upon successful
registration
• These SIP terminations addressed the same First Hop SIP server for their initial
registration.
• In case the SIP options method applies, the SIP User agent will periodically send
(period typically equals 90 s) a SIP options request to the active SIP first hop
server.
Passive Heartbeat
As opposed to Foreground Service Health Monitoring, the main purpose of the
Passive Heartbeat is to help the SIP first hop server to rapidly detect whether a SIP
user Agent can still be addressed for new SIP requests.
When Passive Heartbeat is enabled, the SIP User Agent must reply to the SIP
OPTIONS request that is periodically sent by the SIP first hop server.
The Passive Heartbeat interval configured at and used by the SIP first hop server can
also provisioned at the access node side.
By watching the regular receipt of a SIP OPTIONS request from the SIP first hop
server, the SIP User Agent is able to detect whether the SIP first hop server is still
up and running.
Note — The Passive Heartbeat and Foreground Service

Health Monitoring methods are mutually exclusive.
Background Service Health Monitoring

Background Service Health Monitoring applies to all First Hop SIP Servers being a
fail-over candidate SIP server. The SIP user Agent transmits periodically
(configurable period) an out-of-dialog OPTIONS message to determine the health
status of the fail-over candidate First Hop SIP Server.
Having this information in advance helps to reduce the elapse time to perform
fail-over and subsequently the establishment of new call sessions.
Background Service Health Monitoring makes use of the OPTIONS method.
Fail-Over Hysteresis Threshold

NT
In order to allow the SIP User Agent to distinguish accidental from persistent error
conditions and as such to prevent connection toggling between first hop SIP servers
within a redundancy group, a Fail-over Hysteresis Threshold can be configured.
A SIP Server Fail-over is triggered from the moment the amount of error conditions
has exceeded the Fail-Over Hysteresis Threshold.
Stable Operation Observation Period
Stable operation observation intends to observe the stability of the SIP server once
this SIP server has resumed service after having failed.
Should an observed SIP server remain uninterrupted in-service from the start till the
expiry of the (configurable) stable operation observation period, then this SIP server
is declared stable and ready to be a fail-over / fail-back candidate SIP server.
The stable-operation observation starts from the moment a failed SIP server has
resumed operation, detected by the SIP User Agent via the background service
health monitoring.
Deliberate Update
For reason of maintenance activities, a SIP server may be temporarily put out of
service. To avoid service interruption, the SIP UA allows to announce such upcoming
activity by an update of the list of SIP servers being part of a redundancy group:
• Update of DNS zone file
• Update of list of SRV resource records
• Update of list of A resource records
• Update of IP address in an A resource record
• Update of the SIP server table
In case such update is recognized by the SIP User Agent and the removed SIP
server is a SIP server via which SIP terminations are registered, then the SIP User
Agent will transfer the SIP terminations to the highest priority SIP Server still present
in the list.
A Deliberate Update is performed gracefully meaning that the SIP User agent
triggers a fail-over for a SIP termination from the moment it has the on-hook state.
Neither ongoing dialogs nor ongoing transactions are interrupted.
(De-)Registration at Fail-Over / Fail-Back / Deliberate Update.
By means of pre-configuration in the SIP Service Profile, the following behaviour is
possible upon fail-over, fail-back or deliberate update:
• Upon fail-over, whether or not de-registration of a SIP termination is required to
the NEWLY selected SIP first hop server prior to the initial registration of that
same SIP termination to the NEWLY selected SIP first hop server.
• Upon fail-over, whether or not an initial registration of a SIP termination is required
to the NEWLY selected SIP first hop server.

NT
• Upon fail-back, whether or not de-registration of a SIP termination is required to

the CURRENT SIP first hop server prior to the initial registration of that same SIP
termination to the PRIMARY SIP first hop server.
• Upon fail-back, whether or not the initial registration of a SIP termination is
required to the primary SIP first hop server
• Upon deliberate update, whether or not de-registration of a SIP termination is
required to the CURRENT primary SIP first hop server prior to the initial
registration of that same SIP termination to the NEW PRIMARY SIP first hop
server
• Upon deliberate update, whether or not the initial registration of a SIP termination
is required to the NEW primary SIP first hop server.
Alarm Notification at Fail-Over / Fail-Back / Deliberate Update.

By means of pre-configuration (enable/disable alarm notification) in the SIP Service
Profile, the system raises an alarm upon the occurrence of a SIP server level failover,
SIP server failback or deliberate update.
Upon completion of the SIP server level failover, SIP server failback or deliberate
update, the alarm gets autonomously reset by the system.
13.15.3.2 GEO Redundancy and GEO Fail-Over / Fail-Back

Geographic redundancy entails the physical distribution of individual SIP servers or
SIP server redundancy groups that can support the ability for a SIP User Agent in the
access node to recover and resume service in spite of a failure or a catastrophe at a
particular physical location.

NT
Figure 170 SIP GEO redundancy

L2 / L3 GEO Primary Site
Network
I-CSCF HSS
Voice access node
GEO primary site connection S-CSCF

P-CSCF
1_1
GEO back-up site connection
GEO Back-up Site

Voice access node GEO
redundancy
GEO Back-up Site
I-CSCF HSS
Voice access node
GEO primary site connection S-CSCF

P-CSCF
1_1
GEO back-up site connection
GEO Primary Site

Voice access node
The SIP User Agent supports the interworking with a first hop Geo-redundant SIP
server topology.
A Geo-redundant SIP server topology can be provisioned by means of:
• The Domain Names of the geo primary and geo back-up site whereby the IP
address of the individual SIP servers of these sites must be resolved through the
Domain Name Service NAPTR, SRV and A resource record look-up,
• A list of Fully Qualified Domain Names for both the geo primary and the geo
back-up site whereby the IP address of the individual SIP servers must then be
resolved through the Domain Name Service A resource record look-up,
• A list of IP addresses of the individual SIP Servers for both the geo primary and
the geo back-up site.
The SIP User Agent triggers a Geo Fail-Over / Geo Fail-Back upon explicit request
of the operator. See the related documents for detailed information and the detailed
command definitions for initiating such Geo Fail-Over / Geo Fail-back (ISAM
Operations and Maintenance Guide Using CLI).
The SIP User Agent supports manually triggered GRACEFUL GEO Fail-over /
Fail-Back, meaning that a SIP termination is individually moved to the GEO Back-Up
/ Primary site on the condition that the SIP termination has the call state “on-hook”.
For any other call state, the system will defer the GEO Fail-Over for this SIP
termination till the call state has become “on-hook”.

NT
The SIP User Agent supports manually triggered FORCED GEO Fail-over /
Fail-Back, meaning that all ongoing dialogs and transactions are immediately
aborted and that all SIP terminations become immediately moved to the GEO
Back-up / Primary site (The system does not await the “on-hook” call state of the SIP
termination to perform the GEO Fail-over / Fail-Back).
Neither in the graceful, nor in the forced GEO Fail-over / Fail-back, ongoing dialogs
and transactions are transferred, and this neither at the signaling plane (SIP) nor at
the media plane (RTP).
13.15.3.3 ESA (Emergency Stand Alone) Redundancy and

ESA Fail-Over / Fail-Back
Emergency StandAlone redundancy is considered to be a restrictive redundancy
mode of the GEO redundancy. The ESA Primary side has an identical SIP server
topology as if it was a Geo Primary side. However, the Back-up side only hosts a
single ESA SIP server that locally maintains the subscriber database, consistent with
the ESA Primary site IMS provisioning, and that supports a minimum call handling
feature set:
• The Basic Call Service.
• Special lines can be directly connected to Emergency Offices for Emergency Call
• The Billing system is not available
Figure 171 SIP ESA redundancy
L2 / L3 ESAPrimary Site
Network
I-CSCF HSS
Voice access node
ESA Primary S-CSCF

P-CSCF
Site connection
1_1
First Hop SIP Server Redundancy

Voice access node
ESA redundancy
ESA Back-up ESA

Site connection SIP server

NT
The SIP User Agent triggers an autonomous ESA Fail-Over at the moment that the
connectivity with the ESA Primary Site has completely been lost (none of the First
Hop SIP servers at the ESA primary sites are still addressable).
A SIP termination is individually moved to the ESA Back-Up site on the condition that
the SIP termination is not involved in a stable call. For any other call state, the system
will defer the ESA Fail-Over for this SIP termination till the call state has become
“on-hook”.
The SIP User Agent does not support the DNS location service for the ESA Back-up
site.
The SIP User Agent triggers an autonomous ESA Fail-Back at the moment that at
least one of the SIP servers located at the ESA Primary Site can again be addressed.
A SIP termination is individually moved to the ESA Primary site on the condition that
the SIP termination has the call state “on-hook”. For any other call state, the system
will defer the ESA Fail-Back for this SIP termination till the call state has become
“on-hook”.
The SIP User Agent does not transfer neither ongoing dialogs nor ongoing
transactions to the ESA Primary / Back-up site, and this neither at the signaling plane
(SIP) nor at the media plane (RTP).
13.15.3.4 LSA (Local Stand Alone) SIP Server and LSA

Fail-Over / Fail-Back for SIP POTS and SIP ISDN
PRA voice service
The LSA SIP Server intends to guarantee the basic voice service amongst SIP
terminations of an individual voice access node that gets isolated from its pool of
usual SIP servers (none of the usual SIP first hop servers are still reachable).
For the LSA SIP server hosted at a physical voice packet server board:
• The LSA SIP server is supported for a single NE, for a HUB + subtending topology
as well as for a clustered topology, that is several NEs associated with a single
LSA SIP server hosted in a particular NE of that cluster.
• The LSA SIP server is hosted at a the physical voice packet server board that is
to be planned and equipped in the NE. At most 1 server board, supporting the LSA
SIP server, can be planned and equipped in the NE.
• Configuration of the LSA SIP server happens via the common CLI/SNMP agent
present at the NT board.

NT
• The LSA SIP server supports the POTS / ISDN PRA basic call service amongst
subscribers registered to the LSA SIP server regardless of their usual "home"
Service Gateway.
• The ISDN PRA service supports Direct In-Dialing when running in LSA mode. The
SIP User Agent includes the PUID list that was received from the register server
at the moment the SIP ISDN PRA termination did register to the usual register
server, in the registration request that is sent to the LSA server-LSA mode.
For the LSA SIP server hosted at a virtual voice packet server board:
• The LSA SIP server is supported for a single NE, for a HUB + subtending topology
as well as for a clustered topology, that is several NEs associated with a single
LSA SIP server hosted in a particular NE of that cluster.
• The LSA SIP server is hosted at a the virtual voice packet server board planned
on top of the multi-core NT in the NE. At most 1 LSA SIP server can run at the NE.
• Configuration of the LSA SIP server happens via the common CLI/SNMP agent
present at the NT board.
• The LSA SIP server supports the POTS / ISDN PRA basic call service amongst
subscribers registered to the LSA SIP server regardless of their usual "home"
Service Gateway.
• The ISDN PRA service supports Direct In-Dialing when running in LSA mode. The
SIP User Agent includes the PUID list that was received from the register server
at the moment the SIP ISDN PRA termination did register to the usual register
server, in the registration request that is sent to the LSA server-LSA mode.
The supplementary Service call is not supported.

It is not possible to set-up a call between a SIP termination registered to the LSA SIP
server and another SIP termination registered to another SIP server.
Fail-over to the LSA SIP Server happens at the moment none of the "usual" SIP
servers are still reachable (neither primary nor secondary SIP server(s) are still
reachable, that is, the node becomes isolated from its usual SIP servers).
Ongoing dialogs and transactions at the moment of fail-over are not transferred to
the LSA SIP server, and this neither at the signaling plane (SIP) nor at the media
plane (RTP). The ongoing dialogs and transactions will be maintained along the
current signaling and media path until any SIP termination interaction happens that
terminates the call or the SIP Session Timer expiry.
For a SIP termination involved in an ongoing call at the moment the SIP UA decides
to make a fail-over to the LSA SIP server, the fail-over shall be postponed till the
ongoing call has ended or the SIP Session Timer expiry.
In case of a multiple Service Gateway voice network, the fail-over being triggered for
one Service Gateway to the LSA SIP server does not automatically result in a
fail-over to the LSA SIP server for all Service Gateways. The fail-over to the LSA SIP
server only happens for the Service Gateway(s) for which their usual SIP server pool
is not reachable anymore.
The LSA SIP server acts as register as well as proxy server.

NT
A SIP User Agent and its SIP terminations can connect to a LSA SIP server on the
condition that it gets authorized by the LSA SIP server. Authorization will be allowed
when the Lsa-md5-realm and lsa-md5-password are configured with the same value
as the SIP User Agent and the LSA SIP server.
The LSA SIP server periodically monitors the terminations registered at the LSA SIP
server and checks whether the termination register period has expired. If expired, the
termination is removed from the LSA register table.
Once the SIP UA has connected to the LSA SIP server, it keeps on polling the usual
SIP server pool with a frequency that allows to detect as soon as possible the
availability of the usual SIP server. This polling happens on a per individual Service
Gateway and on a per individual voice LT board / SIP UA basis.
The SIP UA decides to make a fail-back to the usual SIP server pool, from the
moment one of the SIP servers of the usual SIP server pool is again reachable and
in service.
A SIP termination is subject for fail-back from the moment it is in "idle" state. Ongoing
dialogs and transactions are not transferred to the usual SIP server, and this neither
at the signaling plane (SIP) nor at the media plane (RTP).
It is possible to enable/disable the LSA SIP server and to configure its properties and
attributes by means of the usual CLI/SNMP management interface and this on a per
individual Service Gateway.
LSA server redundancy is not supported.
The LSA SIP server is able to establish a basic call amongst SIP Terminations for
which their SIP UAs are connected via different signaling VLANs to the LSA server.
For SIP terminations usually assigned to different Service Gateways and these
Service Gateways are configured with different media VLANs, once these SIP
terminations are registered to the LSA SIP server, it is possible to establish a basic
call amongst these SIP terminations and exchange media traffic amongst them.
In order to allow subscribers of different Service Gateways to speak to each other via
a call established by a LSA SIP server, a common Media VLAN is to be configured.
SIP POTS voice service: LSA Emergency Call Support
ISAMV supports emergency call treatment when running in LSA mode, that is, the
Local Stand-Alone server is able to detect and accept Emergency Calls with
Emergency or Priority Header in SIP.
Overall configuration approach:
• At most 4 emergency entries can be configured per VSG.
• An emergency entry allows to configure both an emergency number and the
emergency service center to which a call for this emergency number can be
routed.

NT
• An emergency service center (a SIP termination) must be registered to the LSA

server. (The emergency call is supported on the condition that also the
emergency center is registered to the LSA SIP server. Each voice service
provider must have a direct connection to an emergency center).
• A single emergency number can be mapped to multiple emergency service
centers.
• An emergency call made by a SIP termination that belongs to a particular VSG
can only be routed to a emergency service center that belongs to that same VSG.
• An emergency call initiated by a SIP termination of a particular VSG is routed to
the LSA server which in turn routes the received emergency call to a free (call
status = idle) emergency service center configured for that same VSG.
SIP ISDN PRA voice service: LSA Emergency Call Support

ISAMV supports emergency call treatment when running in LSA mode for the SIP
ISDN PRA voice service, that is, the Local Stand-Alone server is able to detect and
accept Emergency Calls with Emergency or Priority Header in SIP.
The ISDN PRA emergency service center can be addressed by means of the GDN
or by the GDN + DDI number.
In case a GDN + DDI number is configured, the emergency call will be forwarded to
the DDI number.
An emergency DN (911 for example) can have multiple entries (different ISDN PRA
emergency service center DNs ), but each entry must be configured with a GDN and
can optionally be configured with a DDI number.
PUID List:
The PUID list of a SIP ISDN PRA termination is received from the 'usual' SIP server
upon registration.
In order to support DDI in LSA mode, the PUID list received from the 'usual' SIP
server, is saved in LT board reset-save memory.
The following scenarios apply:
• If the SIP ISDN PRA termination is registered successfully to the 'usual' SIP
server, the PUID list is received in the 200 OK and saved in reset-save memory
at the voice LT board and then also backup-ed to the LSM module.
• Should the NE become isolated from the voice core network, the SIP ISDN PRA
termination registers to the LSA Server with the PUID list received before.
• Should the LT board/NE reset and afterwards not be able to connect to the 'usual'
SIP server, the SIP ISDN PRA termination registers to the LSA Server with the
PUID list retrieved from reset-save memory.
The PUID list will be deleted in case the associated SIP ISDN PRA termination is
deleted or in case of LT board HW replacement.

NT
Overall configuration approach:

• At most 4 emergency entries can be configured per VSG.
• An emergency entry allows to configure both an emergency number and the
emergency service center to which a call for this emergency number can be
routed.
• An emergency service center (a SIP termination) must be registered to the LSA
server. (The emergency call is supported on the condition that also the
emergency center is registered to the LSA SIP server. Each voice service
provider must have a direct connection to an emergency center).
• A single emergency number can be mapped to multiple emergency service
centers.
• An emergency call made by a SIP termination that belongs to a particular VSG
can only be routed to a emergency service center that belongs to that same VSG.
• An emergency call initiated by a SIP termination of a particular VSG is routed to
the LSA server which in turn routes the received emergency call to a free (call
status = idle) emergency service center configured for that same VSG.
LSA Server Conceptual Management Model

Figure 172 LSA Server Conceptual Management Model
LSA Server System
[1] RW
LSA Server Instance

[8] RW
LSA Emergency Service

[128] RW
The class “LSA Server System” includes the attributes and methods that allow to
configure LSA server system attributes: country code, area code and position of the
LSA server in the NE.
The class “LSA Server Instance” includes the attributes and methods that allow to
configure the several LSA server instances together with their attributes: Signaling
IP address, Port, VLAN and Gateway, associated VSG, MD5 realm and password.
The class “LSA Emergency Service” includes the attributes and methods that allow
to configure the emergency number together with its emergency service provider.

NT
13.15.3.5 SIP Integrated Voice Service: NT switch-over

interaction with SIP server Redundancy
The Voice LT board monitors the receipt of the Uplink Switch-over notification from
the NT. Upon the receipt of this signal, meaning that an NT switch-over was
triggered, the LT board starts a 3 minutes “restoration-blocked” timer. While this timer
is running, the complete Geo and SIP server Fail-over / Fail-back handling becomes
blocked meaning that neither a SIP server Fail-over, nor a SIP server Fail-back, Geo
Fail-Over or Geo Fail-back can be triggered and this neither autonomously nor
manually.
The ISAM-V does not block any out-of-dialog request, any in-dialog request,
foreground health service monitoring, background health service health monitoring,
DNS look-up request during the period that the “restoration-blocked” timer is running.
13.15.4 SIP ISDN PRA / CAS R2 Integrated Voice Service:

Redundancy
The SIP first hop server redundancy feature supported for the SIP POTS integrated
voice service applies to the SIP ISDN PRA / CAS R2 integrated voice service.
13.15.4.1 SIP Server Fail-over

Once it has been detected that the currently addressed SIP server has failed, the SIP
User Agent triggers a fail-over and the auto-server-failover timer is started. Next the
SIP User Agent registers all ISDN PRA / CAS R2 SIP terminations to the newly
selected SIP server (regardless of a call is ongoing at an ISDN PRA / CAS R2 SIP
termination or not).
For those ISDN PRA / CAS R2 terminations, for which a call is ongoing at the
moment the fail-over is triggered:
• The B-channels involved in the ongoing calls 'remain connected' to the original
media path and the RTP traffic will be maintained along that original media path
till a subscriber or protocol event is detected that results in the call to be
terminated or till the timer expiry.
• Upon the expiry of the auto-server-failover timer, a forced fail-over is triggered,
that is, the PBX is requested to release the ongoing calls and subsequently the
B-channels that became idle are associated with the newly selected SIP server.
• New calls can only be established via the idle B-channels that are associated with
the newly selected SIP server.

NT
13.15.4.2 SIP Server Fail-over and Session-Refresh

If the session-refresh service is enabled and In case a fail-over is triggered, the
session-refresh timer (if any) will be restarted and the auto-server-failover timer is
started.
timer expiry:
timer expiry:
13.15.4.3 SIP Server Fail-back

Once it has been detected that the primary SIP server is back in service, the stable
observation period timer is started. Upon the expiry of the stable observation period
timer, the SIP User Agent triggers a fail-back. Subsequently, the auto-server-failback
timer is started. The SIP User Agent registers the ISDN PRA / CAS R2 SIP
terminations that are in 'idle' state to the primary SIP server.
Regarding the ISDN PRA / CAS R2 SIP terminations for which a call is ongoing at
the moment the fail-back is triggered:
• The fail-back for these ISDN PRA / CAS R2 SIP terminations is postponed.
• These ISDN PRA / CAS R2 SIP terminations remain registered to the secondary
SIP server till a subscriber or protocol event is detected that results in the call to
be terminated, that is, the ISDN PRA / CAS R2 SIP termination becomes 'idle' or
till the auto-server-failback timer expiry.
• Upon the expiry of the auto-server-failback timer, a forced fail-back is triggered,
that is, the PBX is requested to release the ongoing call and subsequently the
ISDN PRA / CAS R2 SIP termination is registered to the primary SIP server.

NT
13.15.4.4 SIP Server Fail-back and Session-Refresh

If the session-refresh service is enabled:
secondary SIP server / SOS SIP server) ongoing and the re-started
session-refresh timer for this call is still running, the session-refresh treatment is
not affected since the secondary SIP server is still reachable.
13.15.4.5 Deliberate Update

The MSAN does not check the call state of the SIP ISDN PRA / CAS R2 termination
upon the occurrence of a DU condition, that is, the MSAN triggers a DU from the
current primary SIP server to the new primary SIP server for all SIP ISDN PRA / CAS
R2 terminations regardless of whether a SIP ISDN PRA / CAS R2 termination is in
"idle" state or involved in an ongoing call.
For a SIP ISDN PRA / CAS R2 termination involved in an ongoing call (stable call
phase) at the moment the DU is triggered, the call will continue via the existing path
till a subscriber or protocol event occurs that terminates the call.
For a SIP ISDN PRA / CAS R2 termination at which a call is in call set-up phase at
the moment the DU is triggered, the MSAN proceeds with the call set-up via the
existing path.
13.15.4.6 SOS SIP Server Fail-over

Once a SOS fail-over condition has been detected, the SIP User Agent triggers a
SOS fail-over and the auto-server-failover timer is started. Next the SIP User Agent
registers all ISDN PRA / CAS R2 SIP terminations to the SOS SIP server (regardless
of a call is ongoing at an ISDN PRA / CAS R2 SIP termination or not).

NT
For those ISDN PRA / CAS R2 terminations, for which a call is ongoing at the
moment the fail-over is triggered:
• The B-channels involved in the ongoing calls 'remain connected' to the original
media path and the RTP traffic will be maintained along that original media path
till a subscriber or protocol event is detected that results in the call to be
terminated or till the timer expiry.
• Upon the expiry of the auto-server-failover timer, a forced SOS fail-over is
triggered, that is, the PBX is requested to release the ongoing calls and
subsequently the B-channels that became idle are associated with the SOS SIP
server.
• New calls can only be established via the idle B-channels that are associated with
the SOS SIP server.
13.15.4.7 SOS SIP Server Fail-over and Session-Refresh

If the session-refresh service is enabled and In case a fail-over is triggered, the
session-refresh timer (if any) will be restarted and the auto-server-failover timer is
started.
timer expiry:
timer expiry:
13.15.4.8 SOS SIP Server Fail-back

Once it has been detected that the usual SIP server is back in service, the stable
observation period timer is started. Upon the expiry of the stable observation period
timer, the SIP User Agent triggers a SOS fail-back. Subsequently, the
auto-SOS-server-failback timer is started. The SIP User Agent registers the ISDN
PRA / CAS R2 SIP terminations that are in 'idle' state to the SIP server that is back
in service.

NT
Regarding the ISDN PRA / CAS R2 SIP terminations for which a call is ongoing at
the moment the fail-back is triggered:
• The fail-back for these ISDN PRA / CAS R2 SIP terminations is postponed.
• These ISDN PRA / CAS R2 SIP terminations remain registered to the SOS SIP
server till a subscriber or protocol event is detected that results in the call to be
terminated, that is, the ISDN PRA / CAS R2 SIP termination becomes 'idle' or till
the auto-server-failback timer expiry.
• Upon the expiry of the auto-SOS-failback timer, a forced SOS fail-back is
triggered, that is, the PBX is requested to release the ongoing call and
subsequently the ISDN PRA / CAS R2 SIP termination is registered to SIP server
that is back in service.
13.15.4.9 SOS SIP Server Fail-back and Session-Refresh

If the session-refresh service is enabled:
secondary SIP server) ongoing and the re-started session-refresh timer for this
call is still running, the session-refresh treatment is not affected since the
secondary SIP server is still reachable.
13.15.4.10 GEO Fail-over

Upon the receipt of the command to perform GEO fail-over, the MSAN does not
check the call state of the SIP ISDN PRA / CAS R2 terminations. Upon the
occurrence of a GEO FO condition, the MSAN triggers a GEO FO from the primary
site to the GEO back-up site for all SIP ISDN PRA / CAS R2 terminations regardless
of whether a SIP ISDN PRA / CAS R2 termination is in "idle" state or involved in an
ongoing call.
phase) at the moment the GEO FO is triggered, the call will continue via the existing
path till a subscriber or protocol event occurs that terminates the call.
the moment the GEO FO is triggered, the MSAN will try to proceed with the call
set-up via the existing path.

NT
13.15.4.11 GEO Fail-back

Upon the receipt of the command to perform GEO fail-back, the MSAN does not
check the call state of the SIP ISDN PRA / CAS R2 terminations. Upon the
occurrence of a GEO FB condition, the MSAN triggers a GEO FB from the GEO
back-up site to the primary site for all SIP ISDN PRA / CAS R2 terminations
regardless of whether a SIP ISDN PRA / CAS R2 termination is in "idle" state or
involved in an ongoing call.
phase) at the moment the GEO FB is triggered, the call will continue via the existing
path till a subscriber or protocol event occurs that terminates the call.
the moment the GEO FB is triggered, the MSAN will try to proceed with the call set-up
via the existing path.
13.15.5 Overload Protection
13.15.5.1 H.248 Integrated Voice Service: MG (Voice access

node Server) Overload Protection
The overload protection, based on software Watchdog monitoring, as supported by
the Voice server aims at guaranteeing self-protection and robustness for the Voice
access node.
Software Watchdog Monitoring
The Software Watchdog monitors the system in verifying whether all defined
software tasks become scheduled in a reasonable time frame. Should this not be the
case anymore, the software Watchdog will trigger a software application-defined
call-back function in trying to resolve the actual CPU overload problem. The actions
taken by the several software applications depend on these software application
policies.
The responsibility of the software Watchdog is to detect that there is a problem in the
system, not to resolve the problem. The latter aspect is the responsibility of the
clients that subscribed to the software Watchdog warnings.

NT
An overload situation is reached when the board that hosts the Voice Service
application runs at 100% of its CPU capacity. In such a situation, the received
Megaco packets get a priority treatment; Received Line events (off-hook, on-hook,
flash-hook, dialed digits…) run the risk to be ignored. This depends on the
robustness level being applicable at that moment:
• Robustness Level 1: reached when the board that hosts the Voice Service
application remains running at 100% of its CPU capacity during the next 40
seconds.
• A Megaco “ADD” command being received from the MGC is replied with error 510
(Insufficient Resources).
• Any incoming “auditvalue” or “auditcapability” command is discarded (this includes
the “heartbeat” audit too).
• Robustness level 2: reached when the board that hosts the Voice Service
application runs in Level 1 mode and remains running at 100% of its CPU capacity
during the next 160 seconds.
• Any new Megaco command (Add, Modify, Subtract, Move, AuditValue,
AuditCapabilities and ServiceChange) being received from the MGC is discarded by
the Voice server.
• Intra voice subsystem polling intervals are enlarged (This also includes the intervals
to establish / maintain the XLES connection with the voice LT boards)
• Commands been received from the MGC but not yet replied by the Voice server, are
treated with long timer timeout; no “pending” will be sent for those transactions.
• Robustness level 3: reached when the board that hosts the Voice Service
application runs in Level 2 mode and remains running at 100% of its CPU capacity
during the next 320 seconds.
• The Voice server initiates a board reset.
Outgoing Megaco packets as well as outgoing internal signaling (XLES) packets
remain treated as is the case when the Voice server runs in a non-overload situation.
MG Control Overload package
An additional overload mechanism based on CPU load monitoring and in line with
H.248.11 (MG Control Overload Package) is implemented (ocp).
This package protects an MG from processing overload that prevents the timely
execution of Megaco transactions.
The MGC, supporting the MG Control Overload Package, adaptively throttles the
rate it sets up calls to maximize the MG's effective throughput whilst bounding its
response times
It does this by throttling the rate at which transactions that set-up new calls or that
new call legs are sent to the overloaded MG, so the rate of overload notifications
which the MGC receives from the overloaded MG converges to a suitably low level.
To prevent a toggling between CPU-overload and end-of-CPU-overload, an (End of)
Overload Persistency Time has been introduced.

NT
The Overload Persistency Time is the time period the CPU load of the Voice access
node Server must exceed the High-Water-Mark before it can enter the CPU overload
state.
Similarly, the End of Overload Persistency Time is the time period the CPU load of
the Voice access node Server must be below the Low-Water-Mark before it leaves
the CPU overload state.
The End of Overload Persistency Time is set larger than the Overload Persistency
time to ensure that the CPU load is for a sufficient long time below the
Low-Water-Mark as not to immediately cause a new CPU overload situation.
• CPU load monitoring:
• Monitors the overall CPU load of the board that hosts the Voice Service application
by measuring the run time of the IDLE task.
• Informs registered software applications in case of overload detection
• Upon being notified of an overload situation, the software application takes action to
reduce the load.
• CPU load monitoring parameters (not configurable):
• High water (percentage): 95% (5% IDLE task)
• Low water (percentage): 93% (7% IDLE task)
• Overload persistency (time): 2000 ms
• End of overload persistency (time): 3000 ms
* Sample interval (time): 1000 ms (each sample period, the CPU load as a function
of the time given to the idle task) is measured)
• Upon the receipt of Overload-condition notification, the Voice server takes the
following actions:
• If requested by MGC and after having received and replied to a Megaco “ADD”
command, report the ocp/mg_overload event (irrespective of the events reporting
settings being configured in the H.248 MIB.
• If not requested by the MGC, reports the ocp/mg_overload event if the MG-Overload
event is enabled in the H.248 MIB (after having received and replied to a Megaco
“ADD” command).
• Raise the MG-Overload alarm.
• Upon the receipt of Overload-condition-Ended notification, the Voice server takes
the following actions:
• Stop the reporting ocp/mg_overload event.
• Clear the MG-Overload alarm
13.15.5.2 SIP Integrated Voice Service: SIP Overload

Handling
Transactions are the main building blocks of the SIP protocol; Each dialog is
composed out of a number of independent message exchanges called transactions.
A SIP transaction consists of a single request and any responses to that request,
which include zero or more provisional responses and a final response.

NT
Limiting the total number of simultaneous active transactions at the board that hosts
the SIP User Agent has proven to be an effective way to safeguard the system. By
introducing a Maximum Transaction Limit (MaxTx), the board that hosts the SIP User
Agent becomes protected against consuming all the available system resources
when high loads of incoming SIP traffic need to be processed.
The MaxTx value is an internal system dimensioning parameter set by ALU in
accordance with the engineered capacity of the system. However, if MaxTx Limit is
reached, the system does not simply react by gently rejecting all new, incoming,
out-of-dialog SIP requests by sending a 503 “Service Unavailable” response
including a Retry-After header.
Instead, the following rules were incorporated as a local prioritization policy when
applying the MaxTx Limit:
• Requests for ongoing sessions have priority over requests that setup a new
session.
• Response messages are not be targeted by overload protection.
• Requests that relieve stress from the system are not targeted by overload
protection mechanisms
• Outgoing calls/requests are not subjected to MaxTx
The following incoming SIP requests are considered “priority” requests:
• Session refreshes (in-dialog INVITE requests with Session-Expires header)
• in-dialog requests such as BYE, PRACK, UPDATE and INFO
• CANCEL requests
• out-of-dialog OPTIONS requests (typically used for heartbeat/polling)
Figure 173 shows the system behavior.

NT
Figure 173 SIP overload handling

Nbr of transactions in use
Zone 3
Total Tx Limit
margin Zone 2
MaxTx limit
Zone 1
time
• Zone 1: Incoming traffic stays below Max Tx Limit: All incoming SIP requests are
accepted
• Zone 2: Incoming traffic rises above MaxTx but below Total Tx Limit: All
low-priority SIP requests are rejected with a 503 Service Unavailable response;
High priority requests are still handled
• Zone 3: Incoming traffic reaches Total Tx Limit: No more SIP transactions
available in the system; All incoming SIP requests are rejected with a 503 Service
Unavailable response
13.16 Multiple Voice Service Gateway

The multiple Voice Service Gateway (VSG) concept supports the multiple VSP
(Voice Service Provider) as well as the multiple VAG (Voice Access Gateway)
network topology.
The multiple Voice Service Provider topology: to support wholesale in a customer's
network, that is, multiple voice service providers are connected to the same access
network offering their voice service to the voice subscribers.
The multiple Virtual Access Gateway topology: to allow the customer to increase
gradually the voice service capacity of its voice network by gradually installing
additional access gateways (SIP servers) offering the voice service to the new voice
service subscriptions. This must be entirely considered in the scope of a single voice
service provider connected to the access network.
The multiple VSP network topology and a multiple VAG network topology CANNOT
be simultaneously supported in a customer's voice network.

NT
Up to 16 Voice Service Gateways are simultaneously supported. A SIP termination

can be associated to one and only one Voice Service Gateway.
Different Service Gateways may have a different configuration settings.
The number of voice specific VLANs supported by a particular product for the
integrated voice service may put a limitation on the number of Service Gateways that
can be supported by this product.
The Voice Service Gateway concept supports the Domain Name Service. It is
allowed to configure a different DNS server (pool) per VSG. It is also allowed to
configure a DNS server (pool) to be shared by multiple VSGs.
A different DNS server selection procedure can be configured per VSG, if each VSG
owns a different signaling VLAN. The same DNS server selection procedure can be
configured for all VSGs sharing the same signaling VLAN.
The Voice Service Gateway concept supports SIP Server redundancy per VSG. It is
allowed to configure a different SIP First Hop server (pool) per VSG. It is also allowed
to configure a SIP First Hop server (pool) to be shared by multiple VSGs.
The Voice Service Gateway concept supports DHCP with OPTION 82 and 120.
It is allowed to configure the IP address mode as "manual" or "DHCP" per Service
Gateway.
DHCP is only supported in case of the distributed IP address architecture with shared
signaling/media VLAN approach.
All Service Gateways shall share the same Z-Interface definition (CDE profile).
All Service Gateways shall share the same end-user experience: codecs (same
preferred codec), same tones,...
The multiple Voice Service Gateway concept supports the white list feature. It
contains all IP addresses of all service gateways that are manually configured in the
voice access product or retrieved by means of DHCP options 120 or retrieved via
DNS look-up.
A white list per (pool of) service gateway(s) is not supported.
Traffic mirroring is supported at node level, not at the service gateway level. (There
is no such mirrored traffic filtering done at the voice access product).
External Path Forwarding is supported at node level, not at the service gateway level.
(There is no such external packet filtering done at the voice access product).

NT
13.17 Licensed Voice Service Features
13.17.1 Multiple Voice Service Gateway

The "Multiple Service Gateway" capability, introduced in the SIP Protocol based
integrated Voice Service, is offered as a network wide licensed feature to the access
provider with license limits put on the number of SIP terminations created in the voice
network.
The "Multiple Service Gateway" capability allows an operator / Access provider to:
• deploy a multiple Voice Service Provider network ( a "Wholesale" voice network),
• choose for the multiple Virtual Access Gateway network approach ( easy network
capacity planning).
When the "Multiple Service Gateway" license key is enabled, the license limits the
number of SIP terminations that can be created in the customer's voice network.
The SIP termination configuration threshold is watched by means of a network wide
threshold counter calculated by the 5520 AMS.
The license counter is maintained per access node (shelf) and counts the number of
SIP terminations configured at the access node (shelf).
The 5520 AMS retrieves periodically the individual access node counters and checks
whether the network wide license threshold has become exceeded.
Should the license threshold be exceeding, a license violation alarm will appear at
the 5520 AMS screen.
The license violation alarm cannot be cleared and it keeps appearing on the AMS as
long as the license threshold remains exceeded.
13.17.2 Local Stand Alone Server & Emergency Call

Service.
The "Local Stand Alone Server" and "LSA Emergency Service" capability, introduced
in the SIP Protocol based integrated Voice Service, are offered as network wide
licensed features to the access provider with license limits put on the number of SIP
terminations (POTS, ISDN PRA and CAS R2) created in the voice network.
The "Local Stand Alone Server" capability allows an NE to fail-over to the Local
Stand Alone (LSA) SIP Server when the NE became isolated form the usual external
SIP servers and to proceed with the voice service into the LSA mode meaning that
still basic calls can be made amongst the terminations of the LSA voice cluster.
The "LSA Emergency call" capability allows the LSA server to recognize emergency
calls and to forward these emergency calls to the configured local emergency center.

NT
When the "LSA server" and/or "LSA emergency call service" license key is enabled,
the license limits the number of SIP terminations (POTS, ISDN PRA and CAS R2)
that can be created in the customer's voice network.
The SIP termination configuration threshold is watched by means of a network wide
threshold counter calculated by the 5520 AMS.
The license counter is maintained per access node (shelf) and counts the number of
SIP terminations configured at the access node (shelf).
The 5520 AMS periodically retrieves the individual access node counters and checks
whether the network wide license threshold has become exceeded.
Should the license threshold be exceeded, a license violation alarm will appear at the
5520 AMS screen.
The license violation alarm cannot be cleared and it keeps appearing on the AMS as
long as the license threshold remains exceeded.
13.18 Combo DSL - Naked DSL Line

Some customer deploy combo DSL which implies that the twisted pair that comes
from the user premises terminates at both the xDSL LT board and the Voice LT board
(via splitter) and is as such ready to support the Broadband as well as the H.248
Integrated Voice service.
Combo DSL users that subscribe to the Broadband service but that do not subscribe
to the H.248 Integrated Voice service are known as "Naked DSL users".
Naked DSL users are not known (not configured) to the MGC.
The H.248 Integrated Voice service allows to configure whether a port is a Naked
DSL user port.
A specific busy tone (number_not_assigned tone, defined in CDE profile) is played
in case an off-hook event would be received for such user.
13.19 Quality of Service

For VoIP to be a realistic replacement for standard public switched telephone
network (PSTN) telephony services, customers need to receive the same quality of
voice transmission they receive with basic telephone services, meaning consistently
high-quality voice transmissions. Like other real-time applications, VoIP is extremely
sensitive with regard to bandwidth and delay. For VoIP transmissions to be
intelligible to the receiver, voice packets should not be dropped, excessively delayed,
or suffer varying delay (otherwise known as jitter).
VoIP can guarantee high-quality voice transmission only if the voice packets, for both
the signaling and the voice channel, are given priority over other kinds of network
traffic.

NT
For VoIP to be deployed so that users receive an acceptable level of voice quality,
VoIP traffic must be guaranteed certain compensating bandwidth, latency, and jitter
requirements. QOS ensures that VoIP voice packets receive the preferential
treatment they require.
P-bit marking (layer 2) and DSCP marking (layer 3) for signaling and voice (including
fax and modem) traffic are supported.
The p-bit as well as the DSCP values are configurable for signaling and voice traffic

• Signaling traffic: The p-bit and DSCP values are configurable at Media Gateway
level.
• Voice traffic (including fax and modem): The p-bit and DSCP values are
configurable at Media Gateway and Termination level.

• Signaling traffic: the p-bit and DSCP values are configurable at SIP UA level.
• Voice traffic (including fax and modem): the p-bit and DSCP values are
configurable at SIP UA level.
13.20 DHCP Interworking

DHCP interworking is not supported.

The ISAM allows part of the configuration data to be retrieved through a DHCP
request. Following DHCP options are supported :
Table 27 Supported DHCP options
Option Name
1 Subnet-Mask
3 Router
(1 of 2)

NT
Option Name
6 Domain Name Server
50 DHCP Requested Address
51 DHCP Lease Time

53 DHCP Message Type
55 DHCP Parameter Request List
57 DHCP Maximum Message Size
58 DHCP Renewal Time
59 DHCP Rebinding Time
60 DHCP Class Identifier
61 DHCP Client Identifier
81 Client FQDN
82 Client ID (1)
90 Authentication
120 SIP Servers
121 Classless Static Routes (2)
124 Vendor-Identifying Vendor Class
(2 of 2)
Note
(1) The insertion of Option 82 by the DHCP client at the voice LT board can be enabled/disabled through
configuration.
Only the sub-option “Remote-ID” is supported.
The content of the “Remote-ID” is configurable. The default value equals the Physical LT Board-ID i.e.
rack/shelf/slot.
(2) The routes specified in the option 121 are installed, except if specified in the Local Subnet Routes section.
Both the classless static route option (option 121) and the Router option (option 3) can be in the DHCP
Parameter Request List.
If the DHCP server returns both option 121 and option 3, option 3 must be ignored.
13.21 DNS interworking

DNS interworking is not supported.

The usual Management interface (SNMP, CLI) allows configuring the SIP servers by
manual input or for these values to be retrieved through DNS access.

NT
In the latter case, either the Domain Name or the Fully Qualified Domain Name
(FQDN) must be specified to allow the system to resolve the related IP address by
making use of the Domain Name Service.
To resolve Domain names and/or Fully Qualified Domain Names, the Integrated
Voice service supports the NAPTR, SRV and/or A resource record look-up to
recursive Domain Name Servers.
13.21.2.1 A Resource record look-up

ISAM Voice supports A resource record look-up whereby a single FQDN gets
resolved into a single A resource record as well as an A resource record look-up
whereby a single FQDN gets resolved into multiple A resource records.
In the latter case, by means of pre-configuration in the SIP Service Profile, it can be
specified whether all or part of the A resource records returned by the DNS server
shall be cached in the local DNS cache.
13.21.2.2 Time To Live

By means of pre-configuration in the SIP Service Profile, it can be specified whether
a resource record shall be refreshed upon TTL expiry or whether the TTL is ignored
and resource record refresh shall happen upon (re-)registration of a SIP termination.
In the latter case, by means of pre-configuration in the SIP Service Profile, it can be
specified whether all or part of the A resource records returned by the DNS server
shall be cached in the local DNS cache.

NT
13.21.2.3 DNS server selection

The ISAM supports DNS server redundancy with configurable DNS server selection
mode:
• dns_redun_primary:
Multiple DNS servers can be provisioned whereby the DNS Server being
provisioned with the highest priority is addressed as the primary DNS server.
Any new DNS look-up request gets always sent to the highest priority DNS server
irrespective of whether the previous DNS look-up request got replied by the
highest priority DNS server or not.
Should no reply be received from the primary DNS Server, then the DNS look-up
is repeated to the DNS server with the next higher priority in the list. This repeat
cycle may be continued till a reply is received from a particular DNS server in the
list or the end of the list is reached.
Should all Domain Name servers once been queried but without success and the
DNS Maximum Number of Retransmissions parameter has been provisioned with
a value different from zero, then the NE shall again retransmit the DNS look-up to
the Name Servers in the list, starting again with the highest priority DNS server.
Should still no reply be received from none of the DNS servers in the list, then the
re-initiation of the DNS look-up over the complete list will be repeated for as many
times as provisioned in the afore mentioned parameter. Upon the maximum
number of Retransmissions been handled, an alarm is raised notifying the
customer that none of the DNS servers do reply.
• dns-redun-successful:
Multiple DNS servers can be provisioned, The very first DNS look-up is addressed
to the DNS Server being provisioned with the highest priority.
Any new DNS look-up request gets sent to the DNS server that successfully
replied to the previous DNS look-up request. This DNS server remains addressed
for as long as a reply gets received from this DNS server during the initial
retransmission interval.
However, when no response is received in the initial retransmission interval then
the query is repeated to the DNS server with the next higher priority in the list.
When no response is received after all provisioned DNS servers have been tried,
the above procedure continues for another two retries with an exponentially
increasing time-interval.
If three DNS servers were configured, and the primary DNS server fails, while the
query to the second DNS server gets successfully replied, then the following DNS
query will start from the seconds DNS server. But if now the second DNS server
also fails, the query will be repeated to the third DNS server. The overall retrying
sequence in this loop shall be 2, 3, 1 before giving up.
If all three DNS servers fail after three times retransmission, the next loop query
shall be trying from the primary DNS server and the trying sequence is 1, 2, 3.
To support the Domain Name Service for GEO redundant network topologies, the
ISAM allows to provision a separate list of DNS servers for the Geo Primary and the
Geo Back-up site.

NT
The ISAM caches the retrieved NAPTR, SRV and A resource records for a period
equals
{MIN {DNS Purge Time; MIN of [NAPTR,SRV,A] TTL values for a particular DN}}
whereby the provisionable DNS Purge Timer allows to limit the TTL value, should
some of the resource records own an excessively long TTL value.
In order to reduce the call set-up elapse time and/or to reduce the burden on the
network, where possible, the DNS Resolver limits the number of DNS queries to a
strict minimum. This is achieved by supporting the “additional section” in the DNS
server reply.
13.22 BITS Support

An accurate synchronization is mandatory for the voice service, especially for
voice-band-data services and ISDN services. The NT can be connecting by an
external BITS clock or using its integrated BITS module (< 5ppm) to reach a decent
voice quality. The NTs without BITS module (50ppm) are not valid and not permitted
for voice application.

See chapter “Line testing features”.

13.23.3 SIP ISDN PRA Integrated Voice Service

13.23.4 SIP CAS R2 Integrated Voice Service


NT
13.24 Subscriber Line Showering

In case the amount of on-hook and/or off-hook events for a particular subscriber line
exceeds 20 events / minute, the subscriber line will be put in Line Showering state,
this service change is notified to the Media Gateway Controller and an alarm is
raised.
This means that all subsequent events still occurring on this subscriber line will be
ignored by the system; the subscriber is not able anymore to make outgoing calls nor
is the subscriber able to receive terminating calls.
Also from a narrowband line test perspective, when in showering state, the
subscriber line is observed as being out-of-service.
Once the amount of on-hook and/or off-hook events decreases to less than 10
events / minute, the system will put the subscriber line back into normal operation
state.
The upper and lower event thresholds are not configurable, neither in the CDE profile
nor in the MIB.

In case the amount of on-hook and/or off-hook events for a particular subscriber line
exceeds 20 events / minute, the subscriber line will be put in Line Showering state.
No alarm is raised; The system continues to handle the subscriber line being put in
showering state as if it was not put in this state.
13.25 Lawful Intercept
13.25.1 Overall Lawful Intercept strategy

The global Lawful Intercept (LI) solution complies with the international
standardization definition of ETSI TISPAN WG7 and ES 201 671(ETSI TC LI). LI is
considered to be fully transparent for the access node:
• Voice packet replication is assumed to be done by external equipment situated in
the voice network.
• The control path is assumed to provide the IP address of the external equipment
as the destination address of the bearer channel.

NT
13.25.2 Megaco Integrated Voice Service: External Packet

Forwarding (EPF)
In order to support Lawful Intercept, voice traffic exchanged between two voice
termination points must be intercepted by an interception point (CCIF and IRIIF) prior
to receipt at the destination voice termination point.
In the feature described hereafter, the interception point is situated outside the Voice
access node, further upstream in the voice network of the customer.
Obviously, all voice traffic originating at a Voice access node and destined to either
a termination point connected to the same Voice access node, or a termination point
connected to a Voice access node that subtends to the originating Voice access
node, or a termination point connected to a remote Voice access node, or a
termination point that resides outside the Voice access node cluster, must be brought
outside of the originating Voice access node as to allow this voice traffic to be tapped
to the Lawful Intercept device.
To serve such Lawful intercept topology, Megaco Integrated Voice Service allows
enabling the External Packet Forwarding facility. In addition, the EPF facility requires
the IP address of the external device to which the voice traffic is to be forwarded as
a configuration input. The external destination device must be directly connected to
the Voice access node.
When EPF is enabled, all voice traffic that originates from a voice termination point
A connected to the Voice access node and destined to a voice termination point B,
either connected to the same Voice access node, or connected to a Voice access
node that subtends to the former Voice access node, or connected to a Voice access
node that together with the former Voice access node subtends to the same Hub
Voice access node, or to a Voice access node connected by means of a layer 2/layer
3 aggregation network with the former Voice access node, is forwarded in upstream
direction to the external device as being pointed to by the configured IP address prior
to the downstream forwarding to the destined voice termination point.
The same forwarding principle as mentioned before, applies when either voice
termination point A or voice termination point B becomes replaced by the Voice
server due to the support of some supplementary services or the support of an
optimized IP addressing scheme.
Local ISAM Voice RTP traffic switching:
To allow the support of the External Packet Forwarding facility, the RTP traffic will
always be switched along the IHub, even if the two voice terminations among which
the RTP traffic is to be exchanged are connected to the same voice LT board.
Restrictions:
1 The External Packet Forwarding facility is supported on all equipment practices.
2 The External Packet Forwarding facility is supported on the HUB, Subtending
and Remote Voice access nodes.
3 The External Packet Forwarding facility is supported on VLANS of type
“Voice-VLAN” and “Residential Bridge”/v-VPLS.

NT
4 The External Packet Forwarding facility supports L2 aggregated network links

through static L2 aggregation group configuration.
through LACP.
6 The External Packet Forwarding facility supports xSTP.
7 The External Packet Forwarding facility is supported for POTS only.
8 The External Packet Forwarding facility is supported in case the Voice Access
node connects directly or by means of (an) intermediate Voice access node(s) to
the external EPF device by means of a L2 switching network.
9 Supporting (enabling) the External Packet Forwarding facility is mutual exclusive
to the support (configuration) of the private IP addressing topology (IP Address
and IP Subnet reduction topology).
10 The External Packet Forwarding facility shall only be enabled for the VLAN that
carries the RTP traffic (might be a vlan sharing both RTP and signaling traffic).
11 The External EPF device must allow to disable the ICMP Redirect facility.

Packet Forwarding enabled
NT board Signaling
XLES server
IP address
IWF Voice IWF Voice
board L2 board
aggregation
network
NT board NT board
L3
aggregation
network
IWF Voice IWF Voice
board board
Edge Router serves as

"external device" from
MGC ASP where the voice traffic
is tapped to the LI device
SoftSwitch

NT

Packet Forwarding disabled
NT board Signaling
XLES server
IP address
IWF Voice IWF Voice
board L2 board
aggregation
network
NT board NT board
L3
aggregation
network
IWF Voice IWF Voice
board board
MGC ASP
SoftSwitch
13.25.3 SIP Integrated Voice Service: External Packet

Forwarding (EPF)
In order to support Lawful Intercept, voice traffic exchanged between 2 voice
termination points must be intercepted by an interception point (CCIF and IRIIF) prior
to receipt at the destination voice termination point.
In the feature described hereafter, the interception point is situated outside the Voice
access node, further upstream in the voice network of the customer.
Obviously, all voice traffic originating at a Voice access node and destined to either
a termination point connected to the same Voice access node, or a termination point
connected to a Voice access node that subtends to the originating Voice access
node, or a termination point that resides outside the Voice access node, must be
brought outside of the originating Voice access node to allow this voice traffic to be
tapped to the Lawful Intercept device.
To serve such Lawful intercept topology, SIP Integrated Voice Service allows
enabling the External Packet Forwarding facility. In addition, the EPF facility requires
the IP address of the external device to which the voice traffic is to be forwarded as
a configuration input. The external destination device must be directly connected to
the Voice access node.

NT
When EPF is enabled, all voice traffic that originates from a voice termination point
A connected to the Voice access node and destined to a voice termination point B,
either connected to the same Voice access node, or connected to a Voice access
node that subtends to the former Voice access node, or connected to a Voice access
node that together with the former Voice access node subtends to the same Hub
Voice access node, is forwarded in upstream direction to the external device as
being pointed to by the configured IP address prior to the downstream forwarding to
the destined voice termination point.
Local ISAM Voice RTP traffic switching:
To allow the support of the External Packet Forwarding facility, the RTP traffic will
always be switched along the IHub, even if the 2 voice terminations among which the
RTP traffic is to be exchanged are connected to the same voice LT board.
This RTP switching model applies to the SIP Centralised Model only.
(SIP Distributed model: when RTP traffic is to be exchanged among 2 voice
terminations connected to the same voice LT board, the RTP traffic is switched
internally at the voice LT board.)
Restrictions:
1 The External Packet Forwarding facility is supported on all equipment practices.
2 The External Packet Forwarding facility is supported on the HUB and Subtending
Voice access nodes.
3 The External Packet Forwarding facility is supported for the SIP Centralized
model only.
4 The External Packet Forwarding facility is supported on VLANS of type
“Voice-VLAN”/V-VPLS.
through static L2 aggregation group configuration.
through LACP.
7 The External Packet Forwarding facility supports xSTP.
8 The External Packet Forwarding facility is supported for POTS as well as for
ISDN PRI.
9 The External Packet Forwarding facility is supported in case the Voice Access
node connects directly or by means of (an) intermediate Voice access node(s) to
the external EPF device by means of a L2 switching network.
10 The External Packet Forwarding facility shall only be enabled for the VLAN that
carries the RTP traffic (might be a VLAN sharing both RTP and signaling traffic).
11 The External EPF device must allow to disable the ICMP Redirect facility.

NT
Forwarding enabled
NT board NT board

board L2 board
aggregation
network
NT board NT board
L3
aggregation
network
board board
Edge Router serves as

"external device" from
MGC ASP where the voice traffic
is tapped to the LI device
SoftSwitch

NT
Forwarding disabled
NT board NT board

board L2 board
aggregation
network
NT board NT board
L3
aggregation
network
board board
MGC ASP
SoftSwitch
13.26 Voice Traffic Mirroring

The traffic mirroring feature:
• Supports the mirroring of all packets sent by the voice access node.
• Supports the mirroring of all packets received by the voice access node.
• Supports the mirroring of all packets sent and received by the voice access node.
• Does not support filtering, neither packet nor VLAN based filtering at the voice
access node.
• Requires S-VLAN tagging
• Broadcasts S-VLAN tagged traffic in upstream direction.
• Requires the installation of a L2 ACL filter at the network port that broadcasts the
mirrored traffic to the network side with Qualifier = S-VLAN. The L2 ACL filter
intends to drop S-VLAN tagged packets received from the network side.
Voice Packet Mirroring feature is supported for following topologies:

• Capturing device DIRECTLY connected to the Voice access node; see
Figure 178.
• Capturing device REMOTELY connected to Voice access node by means of L2
aggregation network; see Figure 179.

NT
Figure 178 Device connected directly to the Voice access node
S-VLAN
Capturing
ISAM Voice
device
Figure 179 Device connected remotely to the Voice access node
L2
S-VLAN Aggregation S-VLAN
Network
Capturing
ISAM Voice
device
13.27 Integrated Voice Service migration
13.27.1 Software Upgrade / Off-line Software Migration

The Integrated Voice service uses the ISAM offline migration procedure, that is, the
integrated voice service databases and related CDE profiles are considered to be an
integral part of the ISAM offline database migration (next to the NT and IHub
databases). This implies that at software migration time:
• The integrated voice service databases and related CDE profiles are uploaded to
the migration server offline migrated via the Push Button Migration Tool.
• The offline migrated integrated voice service database and associated CDE
profiles are downloaded to the ISAM and activated together with the new software
package.
13.27.1.1 H.248 Integrated Voice Service

Note — This chapter applies to the physical voice packet
server board only.

NT

An “Upgrade/Migration cluster” is the aggregation of all Voice clusters served by a
hub Voice node, this hub ISAM Voice access node included.
Note — The following restriction applies:
All Voice servers equipped in a hub Voice access node are

supervised by one and the same Voice Service Provider.
In order for the integrated voice service to work correctly, the same software package
must be downloaded to all Voice access nodes of a Voice cluster, that is, in particular
with focus on the integrated voice service, the software (maintenance) release on the
voice LT boards must be the same as the software (maintenance) release on the
Voice server and this for the complete Voice cluster.
The same applies within one Voice access node. Only one software (maintenance)
release can be active at a Voice access node at the same time.
This implies that all Voice server pairs in the hub Voice access node must run the
same software (maintenance) release. As a consequence, for the integrated voice
service to work, all Voice access nodes within the same upgrade/migration cluster
must be on the same software (maintenance) release.
The above rules imply that for both a software upgrade and a software migration, the
upgrade/offline migration procedure for the full upgrade/migration cluster must be
completed in a single maintenance window.

NT
Figure 180 Voice upgrade/migration cluster (centralized topology)

Voice Upgrade / Migration Cluster concept in the context of
a Centralised Voice Topology.
Upgrade / Migration Cluster

Main ISAM Voice Node
Voice Voice Voice Voice Voice Voice Voice Voice

Server Server Server Server Server Server Server Server
Pair 1 Pair 2 Pair 3 Pair 4 Pair 5 Pair 6 Pair 7 Pair 8
LTs LTs LTs LTs LTs LTs LTs LTs

Non-main Non-main Non-main Non-main Non-main Non-main Non-main Non-main
node 1a node 2a node 3a node 4a node 5a node 6a node 7a node 8a

node 1b node 2b node 3b node 4b node 5b node 6b node 7b node 8b

node 1x node 2x node 3x node 4x node 5x node 6x node 7x node 8x

Cluster 1 Cluster 2 Cluster 3 Cluster 4 Cluster 5 Cluster 6 Cluster 7 Cluster 8

NT
Figure 181 Voice upgrade/migration cluster (distributed topology)

Voice Upgrade / Migration Cluster concept in the context of
a Distributed Voice Topology.
Upgrade / Upgrade / Upgrade / Upgrade / Upgrade / Upgrade / Upgrade / Upgrade /

Migration Migration Migration Migration Migration Migration Migration Migration
Main ISAM Main ISAM Main ISAM Main ISAM Main ISAM Main ISAM Main ISAM Main ISAM
Voice Node 1 Voice Node 2 Voice Node 3 Voice Node 4 Voice Node 5 Voice Node 6 Voice Node 7 Voice Node 8

Server Server Server Server Server Server Server Server
Pair Pair Pair Pair Pair Pair Pair Pair

Non -main Non -main Non -main Non -main Non -main Non -main Non -main Non -main
node 1a node 2a node 3a node 4a node 5a node 6a node 7a node 8a

node 1b node 2b node 3b node 4b node 5b node 6b node 7b node 8b

node 1x node 2x node 3x node 4x node 5x node 6x node 7x node 8x

H.248 Integrated Voice Service Backwards Compatibility in the Migration

Scenario
Under the conditions and constraints as stipulated in the section below, the
Integrated Voice service indeed strives for backwards compatibility between
releases, starting from R4.0v onwards, in that any next voice release after R4.0v will
take backwards compatibility into account. That is, both the R4.0v maintenance
releases and the R4.1v releases (main and maintenance) will take into account
backwards compatibility with R4.0v.
Disclaimer: Nokia, though remaining confident that this might be a rare case, is not
in a position to guarantee backwards compatibility at all time, as, due to new feature
introduction or problem resolution reasons, Nokia can be forced to break the
backwards compatibility in a certain release, even under the conditions and
constraints as stipulated below. In case of such happening, the customer will be
informed by Nokia, clearly specifying the reasons why the backwards compatibility
had to be broken and the related consequences for the customer. Also, Nokia will
recover the backward compatibility on the earliest successive release possible.
Conditions and restrictions:

NT
Backwards compatibility over ISAM Voice releases is considered:

• Between a main release and its maintenance releases (for example, R4.0v and
R4.0.02c), starting from R4.0v onwards
• Between 2 releases of 2 consecutive release streams (for example, R4.0.03d and
R4.1.02c), starting from R4.0v onwards
• From the NVPS pair to the voice boards, that is, it is assumed the voice boards
are always at a lower or equal release then the NVPS pair, but never at a higher
release
This ISAM Voice backwards compatibility has the following restriction:

• New services, as part of the newly introduced release, might not work as long as
there is more then one release active in the network.
ISAM Voice backwards compatibility is supported only at following conditions:

• At any time there are no more then 2 different releases in the network, being main
or maintenance releases of consecutive release streams
• Having 2 releases in the network can last for at most 2 weeks
Failing to do so will not only block any roll-out of new services in the network of
the customer, but will also make it impossible to guarantee tracking and fixing
problems in the voice network
• Before an upgrade or migration is started to a next release, all Voice access
nodes in the network must be at the same release (main or maintenance)

A SW upgrade/migration of a Voice Service access node follows the general SW
upgrade and offline migration procedure of ISAM.
13.27.1.2 SIP Integrated Voice Service migration

A SW upgrade/migration of a Voice Service access node follows the general SW
upgrade and offline migration procedure of ISAM..
13.27.2 H.248 to SIP functional Migration

The integrated Voice service allows a Voice access node / voice cluster running in
an H.248 integrated voice service mode, to migrate to a SIP integrated voice service.

NT
The following restrictions apply:

• It is not allowed that such a H.248 to SIP functional migration coincides with either
a software upgrade or an off-line software migration or a Switching to Routing
functional migration (see next chapter).
• The target migration SIP architecture is the centralized architecture.
• A complete voice cluster is functionally migrated in one maintenance window.
• Distinct VLANs for signaling and RTP traffic.
• The same VLAN is used to carry RTP traffic in H.248 and SIP mode.
• The same VLAN is used to carry signaling traffic in H.248 and SIP mode.
• The same VLAN is used to carry OAM traffic in H.248 and SIP mode.
The main logical steps to be taken in the H.248 to SIP functional migration are:
1 Configure the SIP voice database
2 Check the ongoing calls and the emergency calls for graceful shutdown
3 Lock the H.248 MGI interface
4 Disconnect the Voice server at L2 from the voice LT boards
5 (re-)Configure the L2/L3 topology to run in SIP mode
6 Unplan the voice LT boards (configured with capability profile = H.248-profile)
7 Replan the voice LT boards with capability profile = SIP-profile
8 Reload the voice LT board with the SIP software package
9 Perform a SIP voice database NT-LT audit
10 Register the SIP terminations
11 Verify the SIP-based voice service
12 Unplan the Voice server (the Voice server must be kept running till the verification
has proven that the SIP-based voice service behaves correctly)
13.27.3 Switching to Routing functional Migration

The integrated Voice service allows a voice access node being deployed in a
switched mode, to migrate to a routed mode.
The switching to routing functional migration applies to a Voice access node
deployed in SIP mode.
The following restrictions apply:
• It is not allowed that such a Switching to Routing functional migration coincides
with either a software upgrade or an off-line software migration.
• The integrated Voice service does not support the functional migration of a
subtending access node. In other words, the subtending access node remains at
all times behaving as switched devices.

NT
• The same Signaling VLAN ID remains used at the IACM part of the Voice access
before and after the migration from “switching” to “routing” device.
• The same RTP VLAN ID remains used at the IACM part of the Voice access
before and after the migration from “switching” to “routing” device.
• The same source / destination Signaling IP address remains configured at the
IHub.
• The same source / destination RTP IP address remains configured at the IHub.
The main logical steps to be taken in the switching to routing functional migration are:
1 Configure the routing protocol (OSPF / RIP)
2 Optional: Configure the static routes
3 (re-)Configure L2/L3 topology to run in route mode.
4 Reset the NT pair.

System Description for FD 100/320Gbps NT and FX Integrated Narrowband Support
NT
14 Integrated Narrowband Support

14.1 Introduction
14.2 Coverage
14.3 MEGACO Feature Portfolio
14.4 SIP Integrated Voice Service - POTS Feature Portfolio
14.5 SIP Integrated Voice Service - ISDN PRA
14.6 SIP Integrated Voice Service - CAS R2
14.7 CESoPSN Service
14.8 Voice Service related alarms
14.9 Compliance to standards
14.1 Introduction
The integrated VoIP service provides classic telephony services to subscribers being
connected with classic POTS / ISDN BRA / ISDN PRA /CAS R2 lines, and to convert
the corresponding signals to VoIP signaling/data packets.
The integrated voice service provides POTS or ISDN BRA/ISDN PRA or CAS R2
service to subscribers over copper pairs together or without xDSL service.
The voice information is converted to VoIP in the ISAM Voice access node and
forwarded to/from the service provider's Ethernet/IP network over optical fibers along
with the HSI and IPTV services carried by the access device.
VoIP networks are subject to standardization. Within standardization there are two
different approaches for the signaling:
• A set of standards driven by ITU-T, centered around ITU-T document H.248. In a
nutshell: a network based on this standard uses RTP for the voice and Megaco
for the signaling.
• A set of standards driven by IETF SIP. In a nutshell: a network based on this
standard uses RTP for the voice and SIP for the signaling.

Integrated Narrowband Support System Description for FD 100/320Gbps NT and FX
NT
The integrated VoIP Service supports both signaling methods and can be deployed
in the corresponding network topologies.
Note 1 — Voice over Broadband (VoBB) is not in the scope of
this chapter
Note 2 — The “Integrated Voice Service” chapter describes the
behavior and characteristics of the POTS/ ISDN ports
associated with the Nokia access devices offering the
integrated voice service.
14.2 Coverage
The following chapters summarize the VoIP service features supported by the
different Nokia Voice access products: 7302 ISAM-V and 7330 ISAM-V FTTN.
It is the aim to offer the customer a common feature set and common voice end-user
experience at all Nokia access products offering the integrated VoIP service.
Nevertheless, slight differences in product roadmaps and product's feature
prioritization might result in deviations from the listed feature set and external
behavior. Please contact the responsible Nokia Copper /Fiber Product Units for
further details.
14.3 MEGACO Feature Portfolio
14.3.1 Registration
The Voice Server acting as Media Gateway (MG) announces its existence to the
Media Gateway Controller by means of a registration (Service Change) command.
This registration instantiates a control association between MG and Media Gateway
Controller (MGC).
The Voice Server notifies the MGC that a termination or group of terminations is
about to be taken out of service or has just been returned to service. A situation
where such notification is to be done simultaneously for multiple terminations might
create an overload situation at the MGC.
To guarantee that all terminations are “registered” at the MGC with the correct state,
the Voice Server invokes the termination-state-notify recovery procedure that verifies
the termination state at periodic time interval and that initiates “state change” retries
when necessary.

NT
14.3.2 Basic Call Setup

• Analogue Z interface.
• Configurable line feeding
• Symmetrical programmable ringing
• Metering tone insertion
• Polarity reversal
• Programmable line impedance with echo cancellation.
• Overvoltage protection
• Integrated Narrowband Line Test facility
• Digit collection by detecting either DTMF tones or pulse dialing.
• FSK/DTMF (provisionable per subscriber line).
• Signaling events processing
• En-bloc dialing.
• Voice activity detection, comfort noise, and packet loss concealment.
• Configurable jitter buffer: adaptive or fixed size (per call).
• Echo cancellation:
• Voice, low speed voice band data, fax (per subscriber line)
• In compliancy to G.168
• High-speed data transmission: with echo tail length up to 16ms
• Silence suppression:
• Detection of silence descriptors in the bearer channel
• Voice Activity Detection
• Transmission of comfort noise to (near-end) customer interface when silence
suppression is activated at the far end packet voice transmitter
• Tonegen package
• Tone generation: Ring tone, Dial Tone, Special (Information) Dial Tone, Ring
Back Tone, Congestion Tone, Busy Tone, and Howler tone.
• Balanced ringing
• Flexible Termination ID format including wildcard
• Flat termination ID format
• Hierarchical termination ID format
• Configurable ephemeral termination ID range.
• Audit of ephemeral termination with support of the wildcard *.
• 2 dial plans / digit maps provisionable in the CDE profile. (max size of each dial
plan / digit map = 4 kB).
• S (Short Timer), T (Start Timer) and L (Long Timer)
• Capability to store up to 512 (basic call)+51 (emergency call) dial plans (1 dial
plan/call; downloaded by the MGC). (maximum size dial plan = 4 kB).

NT
• T.38 fax
• Softswitch is responsible of voice/T.38 call control and charging.
• Fax over IP according in compliancy to ITU-T Rec. T.38
• Between 2 Group 3 facsimile terminals.
• UDP transport.
• V21 flag detection.
• Byte based and frame based
• FEC and redundancy
• 2400 bps, 4800 bps, 7200 bps, 9600 bps, 12200 bps, 14400 bps.
• Maximum speed is 14400bps depending on network situation.
• ISDN: Support of T.38 MGC Transitioning method. (T.38 Autonomous transitioning
method is NOT supported.)
• Port allocation:
* When the call is switched from voice to T.38 fax and MGC does not offer an UDP
port (set UDP port as $) in the local media description, the same UDP port is
allocated for the fax stream as was allocated for voice; this port is notified to MGC as
UDP port for T.38 fax.
* When the call is switched from voice to T.38 fax and MGC offers the same UDP port
as for voice in the media description, the UDP port is reused for the fax stream; this
port is notified to MGC as UDP port for T.38 fax.
* Once the T.38 fax stream has completed, the switch back from T.38 fax to voice
happens by means of the same UDP port.
• T30 fax/modem, requiring full control at the MGC:
• Detected tones reported to MGC
• Switch to VBD mode upon receipt of MGC command.
• Transparent modem/fax service (v.150 VBD mode).
• Capability to detect fax/modem tones from network side or local side.
• In-band tones in compliancy to RFC 2833.
• The flexibility is provided to set the required DTMF tone RFC2833 mode and the
required fax/modem tone RFC2833 mode simultaneously via separated
configuration inputs.
• “In-band tone detection” of fax/modem/text tones from remote side (voice band
codecs, commonly G.711, etc.), which serves as both a VBD stimulus and a
coordination technique to guarantee autonomous behavior.
• In-band fax/modem tones trigger integrated VoIP service to switch to VBD mode.
• For H.248, only tone detected from local side will be reported to MGC in case of
T30/modem full control by MGC.
• Support of the reception of all RFC4734 NTE events, allowing to swap to VBD.
• Support of enhanced fax/modem in-band tone detection from local / IP side with
additional tones treated in compliancy with RFC4733 (when defined). Additional
fax/modem tones support together with IP side in-band tone detection can be
activated simultaneously however by causing some density decrease (Density of
48-lines voice LT board becomes 40 instead of 48). IP-side in-band tone detection
can be turned off via CDE Profile.
• Fax: V.21, V.17, V.27ter, V.29, V.34
• Modem (or text phone): V.18, V.21, V.22, V.22bis, V.23, V.32, V.32bis, V.32ext,
V.34, V.90, V.92, Baudot, Bell103, Bell 212A, V.25/V.8/V.8bis compliance.

NT
• Support of reverse polarity as a (configurable) pulse type as well as 12k/16kHz

metering pulses in the amet package.
• Public Pay phone (reverse polarity)
• Line Polarity Reverse at answer. (H.248: driven by CDE profile input and MGC
command input)
• 12 /16 Khz Metering (1 TR 110 - 1) for POTS lines connected to public coin boxes
and pay phones.
• Periodic Pulsing Only
• Burst once then Periodic Pulsing
• Periodic Bursts
• Periodic bursts with Periodic Pulsing in between the bursts
• Burst once at the begin of a call
• Tariff changes during a call
• Payload format 'audio/telephone_event' and associated dynamic payload type
number.
• Reduce power feed in case the subscriber line is detected to be in Off-Hook state
for a longer time period without being involved in a call; provisionable delay to
enter reduced power feed state.
• Termination of the ISDN BRA U interface (ITU G.961).
• 2B1Q encoding
• 4B3T encoding
• Q921 protocol termination.
• Q931 protocol relay via SIGTRAN.
• CODECs:
• G.711 A/u law (10ms, 20ms, 30ms), G.729AB (10ms, 20ms, 30ms, 40ms, 50ms, 60
ms), G.723.1 (20ms 30ms), T.38, RFC2833
• Packet loss concealment capability for G.711
• End-to-End codec negotiation at call set-up. In case codec information is absent, the
system shall use the default codec settings: G.711 with 20ms packetization interval.
• RTCP:
• SR, RR, SDES and BYE supported
• The deterministic calculated interval Td is set to 5 s.
• No support for RTP session membership
• ISDN: Test based formatted ISDN IUA Interface identifier.
• Jitter Buffer monitoring on a per subscriber line.
• Support of following packages H.248.2, H.248.3, H.248.8, H.248.11, H.248.14,
H.248.16, H.248.23, H.248.26, H.248.27, H.248.34, H.248.45.
For further details about full or partial compliancy with these standards, please
contact the Nokia Product Unit.
• Configurable DSCP & 802.1p bit value for signaling and voice traffic
• ISDN: support to show the state of power source 1 and power source 2 received
from NT1 (to know whether an ISDN user port is locally powered on NT or
remotely powered).

NT
14.3.3 DTMF RFC 2833 Processing

The following tables show how DTMF RFC 2833 is processed
Table 28 ISAM Access Node as OFFER side (DTMF audio).
DTMF-2833 FAX-MODEM SDP offer SDP answer DTMF FAX/

-2833 MODEM
Tone
Audio Audio No RFC2833 No RFC2833 Audio Audio
RFC2833:16-255 Audio Both
RFC2833:0-15 RFC2833 Audio
RFC2833:0-15, 16-255 RFC2833 Both
RFC2833 No RFC2833 No RFC2833 Audio Audio
RFC2833:16-255 Audio RFC2833
RFC2833:0-15, 16-255 RFC2833 RFC2833
Both RFC2833:16-255 No RFC2833 Audio Audio

RFC2833:0-15, 16-255 RFC2833 Both
Mandatory No RFC2833 No RFC2833 Audio Audio

Audio
RFC2833:16-255 Audio Audio
RFC2833:0-15, 16-255 RFC2833 Audio

NT
Table 29 ISAM Access Node as OFFER side (DTMF RFC2833).

-2833 MODEM
Tone
RFC2833 Audio RFC2833:0-15 No RFC2833 Audio Audio
RFC2833:0-15, 16-255 RFC2833 Both
RFC2833 RFC2833:0-15, 16-255 No RFC2833 Audio Audio
RFC2833:16-255 Audio RFC2833
RFC2833:0-15, 16-255 RFC2833 RFC2833
Both RFC2833:0-15, 16-255 No RFC2833 Audio Audio
RFC2833:0-15, 16-255 RFC2833 Both
Mandatory RFC2833:0-15 No RFC2833 Audio Audio

Audio
RFC2833:0-15, 16-255 RFC2833 Audio

NT
Table 30 ISAM Access Node as OFFER side (DTMF both).

-2833 MODEM
Tone
Both Audio RFC2833:0-15 No RFC2833 Audio Audio
RFC2833:0-15 Both Audio
RFC2833:0-15, 16-255 Both Both
RFC2833 RFC2833:0-15, 16-255 No RFC2833 Audio Audio
RFC2833:16-255 Audio RFC2833
RFC2833:0-15, 16-255 Both RFC2833
Both RFC2833:0-15, 16-255 No RFC2833 Audio Audio
RFC2833:0-15, 16-255 Both Both
Mandatory RFC2833:0-15 No RFC2833 Audio Audio

Audio
RFC2833:0-15, 16-255 Both Audio

NT
Table 31 ISAM Access Node as OFFER side (Mandatory audio).

-2833 MODEM
Tone
Mandatory Audio No RFC2833 No RFC2833 Audio Audio

Audio
RFC2833:0-15, 16-255 Audio Audio
Both No RFC2833 No RFC2833 Audio Audio

Audio

NT
Table 32 ISAM Access Node as ANSWER side (DTMF audio).
DTMF-2833 FAX-MODEM SDP offer from SDP answer DTMF FAX/

-2833 Remote Side MODEM
Tone
Audio Audio No RFC2833 No RFC2833 Audio Audio
RFC2833:16-255 RFC2833:16-255 Audio Both
RFC2833:0-15 RFC2833:0-15 RFC2833 Audio
RFC2833:0-15, 16-255 RFC2833:0-15, 16-255 RFC2833 Both
RFC2833:16-255 RFC2833:16-255 Audio RFC2833
RFC2833:0-15 RFC2833:0-15 RFC2833 Audio
RFC2833:0-15, 16-255 RFC2833:0-15, 16-255 RFC2833 RFC2833
RFC2833:0-15 RFC2833:0-15 RFC2833 Audio
RFC2833:0-15, 16-255 RFC2833:0-15, 16-255 RFC2833 Both

Audio
RFC2833:16-255 No RFC2833 Audio Audio
RFC2833:0-15 RFC2833:0-15 RFC2833 Audio
RFC2833:0-15, 16-255 RFC2833:0-15 RFC2833 Audio

NT
Table 33 ISAM Access Node as ANSWER side (DTMF RFC2833).

Tone
RFC2833 Audio No RFC2833 No RFC2833 Audio Audio
RFC2833:0-15 RFC2833:0-15 RFC2833 Audio
RFC2833:0-15, 16-255 RFC2833:0-15, 16-255 RFC2833 Both
RFC2833:16-255 RFC2833:16-255 Audio RFC2833
RFC2833:0-15 RFC2833:0-15 RFC2833 Audio
RFC2833:0-15, 16-255 RFC2833:0-15, 16-255 RFC2833 RFC2833
RFC2833:0-15 RFC2833:0-15 RFC2833 Audio
RFC2833:0-15, 16-255 RFC2833:0-15, 16-255 RFC2833 Both

Audio
RFC2833:0-15 RFC2833:0-15 RFC2833 Audio
RFC2833:0-15, 16-255 RFC2833:0-15 RFC2833 Audio

NT
Table 34 ISAM Access Node as ANSWER side (DTMF both).
DTMF-2833 FAX-MODEM SDP offer from SDP answer DTMF FAX/MO

-2833 Remote Side DEM
Tone
Both Audio No RFC2833 No RFC2833 Audio Audio
RFC2833:0-15 RFC2833:0-15 Both Audio
RFC2833:0-15, 16-255 RFC2833:0-15, 16-255 Both Both
RFC2833:16-255 RFC2833:16-255 Audio RFC2833
RFC2833:0-15, 16-255 RFC2833:0-15, 16-255 Both RFC2833
RFC2833:0-15, 16-255 RFC2833:0-15, 16-255 Both Both

Audio
RFC2833:0-15, 16-255 RFC2833:0-15 Both Audio

NT
Table 35 ISAM Access Node as ANSWER side (Mandatory audio).

Tone
Mandatory Audio No RFC2833 No RFC2833 Audio Audio

Audio
RFC2833:0-15, 16-255 No RFC2833 Audio Audio

Audio
14.3.4 Supplementary services

Supplementary services are widely used in a traditional PSTN network. Customers
considering to evolve/migrate from a TDM network to a NGN IP-based network,
expect feature parity with the TDM network. Therefore, the support of supplementary
services is mandatory.
The H.248 protocol specifies a master/slave architecture for decomposed gateways.
In the master/slave architecture, MGC is the master server and MGs are the slave
clients that behave as simple switches. The integrated VoIP service acts as a voice
access gateway.
A supplementary service will be provisioned by the operator at the MGC or registered
to the MGC through a registration procedure by subscriber's operation. Such service
registration and withdrawing operation will be transparent to the integrated VoIP
service. The integrated VoIP service replies to the H.248 requests of the MGC and
allocates resources for a subscriber liner when a supplementary service gets invoked
for this subscriber.

NT
Table 36 Overview of the supported supplementary services
No Supplementary Service POTS ISDN
Multiparty Services Call Waiting (CW) ✓ ✓
Call Hold (HOLD): Hold For Enquiry / Stockbroker ✓ ✓
3-Party Conference (3PTY) ✓ ✓
Explicit Call Transfer (ECT) ✓
Add-on Conference (CONF) ✓
Abbreviated Address / Dialling (AA) ✓ ✓
Administrative Call Barring (ACB)/ Bad Payer ✓

Alarm Call (transparent) ✓ ✓
Announcement connection via MS ✓
Anonymous Call Rejection (ACR) ✓
Call Completion to Busy Subscriber (CCBS) / Ring Back (transparent) ✓ ✓
Call Completion on no Reply (CCNR) ✓
Calling Line Calling Line Identification Presentation (CLIP) ✓ ✓

Identification Services
Calling Line Identification Restriction (CLIR): Permanent / On a ✓ ✓
per call basis
CWID service ✓
Calling Line Identification Rejection Override (CLIR-O) ✓ ✓
Malicious Call Identification (MCID) ✓ ✓

Call Diversion Call Forwarding Unconditional (CFU) (transparent) ✓ ✓
Services
Call Forwarding Busy (CFB) (transparent) ✓ ✓
Call Forwarding No Reply (CFNR) (transparent) ✓ ✓
Call Forwarding to Fixed Announcement (CFFA) ✓
Call Forwarding to Voice Mail (transparent) ✓
Call Pick-Up (CPU) ✓
Call Return (CR) ✓
Coin Box (CB) ✓
Connected Line Identification Presentation (COLP) ✓ ✓

Connected Line Identification Restriction (COLR) ✓ ✓
Connected Line Identification Restriction Override (COLR-O) ✓
Distinctive Ringing ✓
Fixed Destination Call HotLine ✓ ✓
(FDC)
WarmLine ✓ ✓
General Deactivation (GD) ✓
(1 of 2)

NT
No Supplementary Service POTS ISDN

Call Barring Services Incoming Call Barring (ICB) (transparent) ✓ ✓
Outgoing Call Barring (OCB) (transparent) ✓ ✓
Do Not Disturb (DND) (transparent) ✓ ✓

Inhibition of Incoming Forwarded Calls (IIFC) [a.k.a. Incoming Calls Barring for diverted ✓ ✓
calls]
Line Hunting (LH) (transparent) ✓
Message Waiting Indication (MWI): with special dial tone connection, no VMWI ✓
Outgoing Call Screening (OCS) ✓
Special Dial Tone ✓
Call Park ✓
Last Call Return ✓
Emergency Call ✓
Multiple Subscriber Number (MSN) ✓
Sub Addressing (SUB) ✓
Terminal Portability (TP) ✓
Direct Dialling In (DDI) ✓
Change Password ✓
VoiceMail ✓
VMWI: VMWI via H.248.3 ind package ✓
VMessage Waiting Indication (MWI) announcement via Huawei proprietary H.248 package ✓
SG{x_nvaft/x_mwt} followed by cg/dt (with locally stored .wav file)
(The subscriber line shall only ring once when receiving MWI set/clear command from
MGC)
(2 of 2)
Note — With respect to the POTS supplementary service

"3-Party Conference (3PTY)" :
• Maximum 3 termination IDs per context (1 physical + 2
ephemeral termination IDs)
• Local audio (RTP stream) mixing at AGW possible
Interoperability of the integrated VoIP service access device with a 3rd party Voice
application Server can be supported through commercial agreement.
Please contact the ISAM PU for the supported supplementary services list.

NT
14.3.5 Combo-Shelf Application

For subscribers having a service level agreement for the xDSL service but no service
level agreement for the POTS voice service, the system offers the capability to create
the POTS termination into the subscriber database such that the corresponding
POTS port is kept powered by the voice LT board although the registration of this port
will be rejected by the MGC.
If the subscriber should attempt to connect a POTS phone or a CPE to the line at
home, then upon going off-hook, the AGW shall autonomously start playing a
pre-configurable ‘number_not_assigned’ tone.
14.3.6 Performance monitoring

The statistics are autonomously enabled by the system. They are reported to the
MGC in either the subtract or the audit reply, once the call has finished.
These statistics are not supported through the usual management interface.
The Megaco integrated VoIP service supports the “nt” as well as the “rtp” package
for the permanent and ephemeral terminations.
Table 37 Performance monitoring
Package Statistics Contained in Contained in CLI/SNMP Notes

substract audit reply
reply
nt dur ✓ ✓ - Provides the duration of time the

termination has existed or been
out of the NULL context.
os ✓ ✓ - Provides the number of octets
sent from the termination or
stream since the termination has
existed or been out of the NULL
Context. The octets represent
the egress media flow excluding
all transport overhead. At the
termination level, it is equal to
the sum of the egress flows over
all streams.
or ✓ ✓ - Provides the number of octets

received on the termination or
Context. The octets represent
the ingress media flow excluding
all transport overhead. At the
termination level, it is equal to
the sum of the ingress flows over
all streams.
(1 of 2)

NT
Package Statistics Contained in Contained in CLI/SNMP Notes

substract audit reply
reply
rtp ps ✓ ✓ - Provides the number of packets

sent from the termination or
Context.
pr ✓ ✓ - Provides the number of packets

received on the termination or
Context.
pl ✓ ✓ - Provides the current rate of

packet loss on an RTP stream,
as defined in RFC 3550. Packet
loss is expressed as percentage
value: number of packets lost in
the interval between two
reception reports, divided by the
number of packets expected
during that interval.
jit ✓ ✓ - Provides the current value of the

inter-arrival jitter on an RTP
stream as defined in RFC 3550.
Jitter measures the variation in
inter-arrival time for RTP data
packets.
delay ✓ ✓ - Provides the current value of

packet propagation delay
expressed in timestamp units.
This is the same as average
latency.
(2 of 2)
14.3.6.1 Voice Qos (packet loss, jitter, loop delay) Metrics

Alarm Reporting
The system allows to enable / disable the RTP QOS Metrics Alarm reporting feature
at a per single subscriber.
The system allows to configure 3 TCA thresholds at a per single subscriber :
• Packet Loss Upper-Threshold (Expressed in %)
• Interarrival Jitter Upper-Threshold (Expressed in milli-seconds)
• Round Trip Delay Upper-Threshold (Expressed in milli-seconds)

NT
Three RTP QOS Metrics Threshold Crossing Alarms (TCA) have been defined :
• Low-QOS-Packet-Loss :
• Raised in case the Packet Loss threshold is exceeded.
• Alarm content : Peer IP-address ,Packet loss (%) in "Additional info" section of the
alarm.
• Low-QOS-Jitter :
• Raised in case the Interarrival Jitter threshold is exceeded.
• Alarm content : Peer IP-address , Jitter (msec) in "Additional info" section of the
alarm.
• Low-QOS-Delay :
• Raised in case the Round Trip Delay threshold is exceeded.
• Alarm content : Peer IP-address , Delay (msec) in "Additional info" section of the
alarm.
All three RTP QOS Metric thresholds are checked upon call completion.
All three RTP QOS Metric thresholds are checked against the statistics collected in
the scope of RTCP.
Alarm-ON reporting :
• On a per call basis.
• Upon call completion in case a threshold is exceeded
• A RTP QOS Metrics Threshold Crossing Alarm can only be reported once during
a call.
• Up to three different RTP QOS Metrics Threshold Crossing Alarm identities can
be reported per call (upon call completion).
Alarm RESET :
• A RTP QOS Metrics Threshold Crossing Alarm is autonomously reset by the
system.
• A RTP QOS Metrics Threshold Crossing Alarm is immediately reset after this RTP
QOS Metrics Threshold Crossing Alarm has been reported.
14.4 SIP Integrated Voice Service - POTS Feature

Portfolio
14.4.1 Transport Protocols

The UDP and TCP transport protocols are supported as underlying transport protocol
for SIP

NT
The MSAN supports the following TCP transport protocol strategy:

• Support of the "Two Persistent TCP connections" strategy meaning that two
persistent TCP connections are established between a MSAN SIP UA instance
and its peer first hop SIP server whereby a persistent TCP connection is
established in each direction.
• A TCP connection established by one side is used by that same side to initiate
SIP requests to the peer side.
• A persistent connection being established between two SIP peers may be closed
at any time by either peer when the peer-defined conditions are met.
• In order to have two persistent connections, the first hop SIP server must support
this approach too. However, should a first hop SIP server not follow this approach,
but for example implements a per-dialog connection approach, then more than
two connections will be active between the MSAN SIP UA and the first hop SIP
server.
• A SIP request and the associated response must be sent over the same TCP
connection.
• Under error conditions, the peer side may attempt to open a new TCP connection
to send the response.
• When the MSAN wants to send a response and the TCP connection on which the
request was received is no longer existing, it will open a new TCP connection to
the source IP address and port of the corresponding request.
• Support of concurrent "TCP peering" relationships with different first hop SIP
servers in order to support first hop SIP server redundancy.
• A persistent TCP connection is still maintained for a period equal to the
configurable TCP connection maximum idle time, after the last message was sent
or received over that TCP connection.
• An established TCP connection is closed:
• upon the expiry of the configurable TCP connection maximum idle time.
• upon TCP connection failure.
• Confirmed dialogs, that is calls in conversation state, are not released upon a
failure of the persistent TCP connection along which these dialogs were
established.
• Keeping the various SIP layers independent from each other, a failure of a
persistent TCP connection is not notified to the application layer. Such failure
results in User Agent layer as well as Transaction layer time-outs that are reported
as SIP request transmission failures to the application layer.
• In case of the distributed IP address policy, the tcp-listen-to port is configurable;
the TCP source port is autonomously allocated by the MSAN SIP UA.
• In case of the centralized IP address policy, both the tcp-listen-to port and the tcp
source port are autonomously allocated by the MSAN SIP UA.
• Also, if the size of a SIP request with UDP as underlying transport protocol
exceeds a configurable maximum UDP packet size threshold, the transport
protocol is switched from UDP to TCP.

NT
14.4.2 SIP User Authentication

The following user authentication methods are supported:
• MD5.
• Authentication and Key Agreement (AKA) in compliance with the standard IETF
RFC 3310.
• The RFC specifies an Authentication and Key Agreement (AKA) based one-time
password generation mechanism for Hypertext Transfer Protocol (HTTP) Digest
access authentication. The HTTP Authentication Framework includes two
authentication schemes: Basic and Digest. Both schemes employ a shared secret
based mechanism for access authentication.
• The AKA mechanism performs user authentication and session key distribution in
Telecom Operator's networks. AKA is a challenge-response based mechanism that
uses symmetric cryptography.
• Support of AKAv1-MD5 / AKAv2-MD5 / AKAv1-SHA-256 / AKAv2-SHA-256 /
AKAv1-SHA-512-256 / AKAv2-SHA-512-256 in compliance with RFC 3310.
14.4.3 Registration
From a system perspective, the registration of SIP terminations is done by all SIP
UAs in parallel.
From a SIP UA perspective, as a general rule, SIP terminations are registered on an
individual basis and in the order that the SIP terminations become administratively
enabled.
• SIP Registration method in compliancy to RFC3261 (including de-registration and
re-registration)
• Header fields: Call ID, CSeq, From tag, Path, Service-Route, Random contact
• Response codes: 200/404/413/480/486/500/503/401/407/423.
• “reg” event package in compliancy with RFC3680. (Event header present in
SUBSCRIBE and NOTIFY requests.)
• Subscription upon successful registration
• Subscribe / Notify dialog complies to RFC 3265.
• Anti-avalanche register procedure as to avoid stressing the register server.
• MD5 digest encryption of registration password.
The SIP UA allows (can be enabled/disbled) to play a pre-configurable tone
sequence when the subscriber goes off-hook and its line is not registered due to:
• First Hop SIP server unavailability
• First Hop server fail-over
• Initial registration failure (Incorrect MD5 username/password,... )

NT
14.4.4 Basic Call
14.4.4.1 General
• Analogue Z interface.
• Configurable line feeding
• Symmetrical programmable ringing
• Metering tone insertion
• Polarity reversal
• Programmable line impedance with echo cancellation.
• Overvoltage protection
• Integrated Narrowband Line Test facility
• Configurable end-of-dialling indicator: *, #, * and #
• Tone generation: Ring tone, Dial Tone, Special (Information) Dial Tone, Ring
Back Tone, Congestion Tone, Busy Tone, and Howler tone.
• Echo cancellation:
• Voice (per subscriber line): configurable as enabled/disabled
• low speed voice band data (per subscriber line)
• In compliancy to G.168
• Echo tail length up to 128 ms.
• Silence suppression:
• Detection of silence descriptors in the bearer channel
• Voice Activity Detection
• Transmission of comfort noise to (near-end) customer interface when silence
suppression is activated at the far end packet voice transmitter
• Voice activity detection, comfort noise, and packet loss concealment.
• CLIP mode: FSK / DTMF (Provisionable per subscriber line).
• Telcordia FSK and ETSI FSK simultaneously supported per voice access node.
• Formatting SIP signaling messages in compliancy to RFC3261 (including
escaped characters in SIP URI).

NT
• SIP INFO method:

• Report hook flash event via SIP INFO with Content-Type: application/sscc
• Ability to handle per-port hookflash and play different dial tone.
* Configurable Hook-flash timer per termination via the usual CLI/SNMP
* Maximum 16 different dial tones pre-provisioned in the CDE profile.
* Per service dial tone pre-provisioned in the SIP Service Profile.
• Recognize the following tone types and generate them:
* special dial tone
* Beep tone
* Ring-Back tone
* Ringing tone
* Re-call dial tone
* Busy tone
• Support (tightly and loosely coupled mode) of sending DTMF digits during active call
via the signaling path using SIP INFO messages (basic call only) meaning:
* The sending access node detects the DTMF digits during the active call, converts
them into SIP INFO messages and sends them to the IMS core.
* The IMS core has the choice to handle the SIP INFO message locally at the
Telephone Application Server or forwards it to the terminating access node.
* At the termination access node the DTMF-tone might have to be regenerated and
played towards the subscriber.
• SIP BYE method (receiving, sending) in compliancy to RFC3261 to terminate call.
• Per line configurable Clear Forward capability upon the receipt of the BYE.
* Clear Forward is an 800-1.100 ms disconnect of the positive lead, that is the lead
that is positive when in the idle condition.
(Note: legacy behavior: system wide pre-provisioning whereby, if enabled,
simultaneously Tip and Ring are disconnected.)
* Clear Forward applied to a terminating call to indicate to the called subscriber that
the calling party has released the call.
* Clear forward can be enabled or disabled per subscriber line.
• SIP CANCEL method in compliancy to RFC3261 to cancel outgoing call.
• Response codes: 481 / 487
• Release timer: Call gets released upon release timer expiry and no final response
received.
• SIP CANCEL method in compliancy to RFC3261 to cancel incoming call.
• Outgoing call rejected by remote endpoint:
• Response codes: 400, 403, 404, 406, 408, 415, 480, 486, 487, 488, 500, 501, 503,
504, 600, 604, 606.
• Upon receipt of 486 / 600: play tone as provisioned in SIP Service Profile.
• Upon receipt of 480: play tone as provisioned in SIP Service Profile.
• Upon receipt others: play tone as provisioned in SIP Service Profile.
• Retry-after header received in error 500, 404, 413, 480, 486, 600, 603: retry call
set-up upon retry-after timer expiry.

NT
• Incoming call rejection: Lack of DSP resource, CODEC not supported, Line busy,
Termination not known, not supported media type in SDP offer body, Termination
with administrative state = down.
Response codes: 400, 404, 420, 480, 481, 486, 488, 500
• Line busy: 486.
• Not supported media type in SDP offer: 488 (warning header included).
• Termination not known: 404.
• Termination with administrative state = down: 480.
• Timer A, B, C and F in compliancy to RFC3261
• Authentication challenges in compliancy to RFC3261 and RFC 2617.
• Line Polarity Reverse for incoming as well as for outgoing call.
• Support of polarity reverse for the line of the originating coin-box when the
terminating party answering the call.
• Polarity reverse triggered by the access node i.e. without any special signaling
required from the AS.
• Polarity reverse enabled/disabled provisionable per line.
• Polarity reverse cannot be triggered on non-coin box lines.
• Usual polarity applied to the line upon the receipt of on-hook event.
• SIP OPTIONS method in compliancy to RFC3261 (Tightly and Loosely couple
mode)
• Support for receipt of In-dialog INFO or OPTIONS method originating at network
side to confirm connectivity with integrated voice service during an ongoing call.
• Support for receipt of in-dialog UPDATE or OPTIONS method originating at
network side for session and audit refresh.
• Support for local or remote ring-back tone depending on P-Early-Media header
settings (Tightly and Loosely coupled mode).
• Support for Reliability of Provisional Responses in compliancy to RFC 3262.
• Support for TEL URI scheme in compliancy to RFC 3961.
• Support of “isub-encoding” parameter in compliancy to RFC 4715.
• Support of TEL URI to SIP URI conversion in compliancy to RFC 3261.
• Support for 300 / 302 response code to new INVITE.
• Provisionable Dial Plan / Digit Map.
• Configurable "Digit Map Match" Mode :
• Maximum Digit Map match mode (Inter-digit timer expiry mode).
• Minimum Digit Map match mode.
• Digit Map restrictions :
• A Digit Map pattern must not exceed 100 bytes.
• The total amount of Digit Map patterns must not exceed 50.
• The total Digit Map size must not exceed 4 Kbytes.
• ZTE SIP server specific : Support for proprietary SIP message "MESSAGE" to
play the dial tone a second time when the subscriber dials the prefix as received
in the body of the SIP message "MESSAGE" :
• “Content-Type: text/plain Second-Dial-Tone:yes;Intra-Group-Outgoing-Call-Prefix:9"

NT
• CODECs:
• G.711 A/u law (10ms, 20ms, 30ms), G.729AB (10ms, 20ms, 30ms, 40ms, 50ms,
60ms), G.723.1 (30ms), T.38, RFC2833
• Packet loss concealment capability for G.711
• End-to-End codec negotiation at call set-up. In case codec information is absent, the
system shall use the default codec and ptime settings: (default codec and ptime
setting is provisionable in the CDE profile).
• RTCP:
• SR, RR, SDES and BYE supported
• The deterministic calculated interval Td is set to 5 s.
• No support for RTP session membership
• Support of PreConditions in compliancy to RFC 4032:
• Enable/disable SIP Preconditions.
• Backwards compatibility (remote party not supporting SIP Preconditions).
• Segmented QoS precondition - basic call origination:
• Resource reservation before sending initial INVITE.
• Indicate the support of SIP preconditions in the Supported header of the INVITE.
• Prevent media stream from flowing until the SIP preconditions are met.
• Segmented QoS precondition - basic call termination:
• Resource reservation before returning SDP answer.
• Hold ringing the callee until the preconditions are met.
• Hold call waiting tone and/or CLIP for incoming call until the required SIP
preconditions are met.
• Prevent media stream from flowing until SIP preconditions are met.
• Segmented QoS precondition - supplementary services:
• Hold ringing, call waiting tone and/or CLIP for incoming call until the required SIP
preconditions are met.
• Segmented QoS precondition - early dialog:
• Only when the SIP preconditions are met, the system decides whether to present
the received early media to the user.
• Reduce power feed in case the subscriber line is detected to be in Off-Hook state
for a longer time period without being involved in a call; provisionable delay to
enter reduced power feed state.
• Flexible SIP URI provisioning.
• Flexible Termination ID provisioning.
• Jitter Buffer monitoring on a per subscriber line.
• Configurable DSCP & 802.1p bit value for signalling and voice traffic.
• Domain Name Service (DNS) support.
• Dynamic Host Configuration Protocol (DHCP) support.

NT
14.4.4.2 Outgoing call

SIP Invite method in compliancy to RFC3261
• Header fields: Accept header; Supported header (100rel, timer, in-dialog);
Allow header (“INVITE”, “ACK”, “CANCEL”, “BYE”, “UPDATE”, “PRACK”, “INFO”,
“NOTIFY”, “OPTIONS”); User-Agent header; Date header; P-Preferred-Id;
P-Early-Media; Route header.
• Media resource negotiation
• Response codes: 180/181/182/183.
• “Forking”
• Response with/without SDP
• Response with same/different to-tag
• Alert timer: started upon the receipt of 18x. Call gets released upon alert timer expiry
and no non-100 response received.
• Ability to handle the 180 ringing response including “Alert-info”.
• Ability to handle the 183 response including “Required: in-dialog”.
• Support of 183 with SDP followed by 180 without SDP.
• Response code: 200OK.
• Response with/without SDP
• SDP body:
• Offer/Answer approach:
• Outgoing INVITE always with initial SDP offer.
• Early dialog, most recent SDP offer in response overrules previously received
SDP offer. Non conformity with RFC3261.
• Multiple active early dialogs:
• dialog confirmed by 200 response without SDP: last received SDP applies.
• dialog confirmed by 200 with SDP: this last received SDP applies.
• SDP content:
• Session description: v=; o=; s=; c=*; a=*;
• Time description: t=.
• Media description: m=; a=*
• Attribute:
• sendonly/recvonly/sendrecv/inactive
• ptime (not sent in offer).
• Rtpmap
• Fmtp
• Date header included in the INVITE message as GMT (Tightly and Loosely
coupled mode)
• Enable/disable decadic dialling on a per termination level by means of the usual
CLI/SNMP management interface.

NT
14.4.4.3 Incoming Call

• History-Info / Diversion header present in incoming INVITE copied in 18x
response.
• Incoming INVITE with/without SDP.
• Optional header fields incoming INVITE: History-Info, Allow, Supported, Accept,
Content-Length, Content-Type, Allow-Events, Record-Route, User-Agent,
Session- Expires, Min-SE, Privacy, P-Asserted-identity, and so on. Also, it should
be noted that many headers can be received but will be ignored.
• Optional header fields outgoing 180 Ringing: History-Info, Allow, Supported,
Accept, Content-Length, Content-Type, Allow-Events, Record-Route,
User-Agent, Require.
• Per subscriber line configurable Fast Guard option, that is a subscriber port can
be manually configured (via the usual CLI/SNMP management interface) to
enable/disable Fast Guard.
• Fast Guard is the polarity reversal applied to the subscriber line upon the receipt of
a terminating call. As such, the subscriber (PBX) gets signaled that the line is seized
by a terminating call and prevents the subscriber (PBX) from initiating a call which
would result in a call collision.
• A DC line polarity reversal is immediately applied upon line seizure and throughout
the ringing sequence (that is including the silent periods) in the following way:
* “negative on idle" wire connected to positive lead (earth)
* “positive on idle" wire connected to negative lead (-50 V battery)
• Upon the receipt of an INVITE request, the line polarity is reversed and ringing gets
applied at the subscriber line; subsequently the 180 "Ringing" is sent.
• Upon the called subscribers answering the call, that is the ISAM node detects the
"off-hook", normal polarity is restored.
• Should the calling subscriber release the call prior to the called subscriber answering
the terminating call, the ISAM node will receive a CANCEL request. The ISAM node
will respond to the CANCEL request and subsequently will restore the normal
polarity.
14.4.4.4 Mid Call

In case a mid-call session modification request (that is re-INVITE or UPDATE) is
received with an SDP offer containing the "inactive" direction attribute for the ongoing
voice media stream, the SIP UA:
• Responds with a 200 OK including a SDP answer containing the "inactive"
direction attribute
• Generates hold tone to the end-user.
• Does not generate media towards the network.
• Continues to generate local hold tone until either:
• The network modifies the direction of the RTP stream via the "sendrecv", "sendonly"
or "recvonly" direction attributes in a new session modification request.
• The held end user hits flash-hook
• The call is released.

NT
The characteristics of the hold tone to be generated are specified in the CDE profile.
14.4.4.5 Direct Collect Call

• Support of Direct Collect Call. that is when user A makes a direct collect call to
user B, it will be user B who pays for the call. This means that the call control is
passed to user B.
• A direct collect call is immediately released when user B goes on-hook. In case
user A goes on-hook, the call is also immediately released.
• The supplementary services apply as usual. The configured supplementary
service behavior, for example an immediate release of a call when a specific user
goes on hook, has priority.
• Supported for tightly coupled and loosely coupled mode.
14.4.4.6 Media
• Dynamic payload type kept unchanged during a session.
• Support of Early-Dialog Handling. SDP handling in 18x with different/same to-tag.
• Generation of audible ringing upon receipt of 180-Ringing response.
• Media update upon receipt of RE-INVITE or UPDATE methods with new SDP.
• RFC 2833 (Tightly and Loosely coupled mode)
• Digit collection by detection of DTMF tones / Pulse dialing (Tightly and Loosely
coupled mode)
• Dynamic payload negotiation is compliant with RFC 2833 / RFC 3264.
14.4.4.7 Session refresh

• Session Timer in compliancy to RFC 4028
• Response code: 422
• Support for receipt of RE-INVITE and UPDATE methods for session refresh
• UPDATE method is used for session refresh initiated by Integrated Voice Service.
14.4.4.8 Overlap dialing

• Overlap Dialing: Multiple-Invite method in compliancy with RFC 3578.
• Response code: 484.

NT
• Overlap Dialing: In-Dialog method (INFO method)

Support of “second dialling”:
• Notifying softswitch about capability to support “in-dialog” mode by including
“in-dialog” in Supported header of outgoing INVITE method.
• Establish Early dialog upon the receipt of 183 response with Require header
including “In-dialog”. (No ring-back tone played).
• Play/stop dial tone upon receipt of 180 response including specific “Alert Info”
• Collected digits are sent by means of INFO method.
14.4.4.9 Metering
• 12/16 Khz metering.
• Support of metering parameters in XML body in compliancy to ETSI TS 183 047.
• Periodic / Burst pulsing
• For 2-party and multi-party calls
• For multi-party calls: to generate the pulses for the sum of the two rates on the line
• Up to 30 pulses per 10 sec and 300 ms >= Tpulse + Tpauze <= 320 ms
• Burst pulsing in compliancy to ETSI TS 0373_96 part 6.
• Supported modes:
• Periodic pulsing only.
• Burst once then Periodic pulsing.
• Periodic Bursts.
• Periodic bursts with Periodic Pulsing in between the bursts.
• Burst once at the begin of a call.
• Support of tariff type changes during a call.
• Changing from the current tariff type to a new tariff type
• Rate change within a tariff type
• Support of “Free Charge” POTS metering mode.
• Support of Metring types: “Override” & “Period of Day”.
• Support of enable/disable reverse polarity prior to sending of metering pulse.
• Support of sending a 12/16 KHz metering pulse to the originating coin-box when
the terminating party answering the call
• Metering pulse autonomously generated by the access node i.e. without any special
signaling required from the AS.
• Single metering pulse enabled/disabled provisionable per line.
• Single metering pulse cannot be sent on non-coin box lines.
14.4.5 Fax and modem

• Fax over IP in compliancy to ITU-T Rec. T.38
• Redundancy

NT
• Incoming/Outgoing fax with G.711 VBD or T.38.

• sending/receiving 491 response
• Incoming fax fallback from T.38 to VBD fax call.
• Outgoing fax fallback from T.38 to VBD fax call.
• Sending 488 to fallback to VBD when lack of T.38 resources.
• Fax call termination upon the receipt of 415 response
• Receipt of NTE event 52 “swapping to VBD” in compliancy to RFC 4734.
• Voice Band data modem and fax modem operation in compliance with GR-909 s.
5.2.1.5, R5-14by using:
• Fax/Modem Pass-through
• Fax/Modem Relay.
• V.152 Playout tones triggered by RTP events:
• AG SDP offer contains the support of RFC 4733 RTP events for DTMF and modem
signals and fax tones.
• In case the remote AG also indicates the support of IETF RFC 4733 for modem
signals and fax tones, then the local AG will :
• Render the corresponding Data modem and fax tones from the received RFC
4733 RTP events
• Only transmit the Data modem and fax tones via RFC 4733 RTP events
• Suppress the transmission of Data modem and fax tones via RTP audio packets
• Detection of T.30 CNG tone to identify a fax call.
• Detection of the 2100 Hz (with periodic phase reversals) echo canceller disabling
tone (ANS or ANSam tone) to identify a data modem call or a V.34-modulated fax
call; in compliancy to GR-909 s. 5.2.1.5.3, R5-17.
• Disable voice band echo cancellers upon detection of a 2100 Hz tone (with
periodic phase reversals); in compliancy to GR-909 s. 5.2.1.3, R5-10.
• CNG detection upon the receipt of a 1100 Hz tone [0.5 s. ON; 3 s. OFF] in
compliancy to T.30.
• Detection of voice, fax, or data modem call types in accordance with the matrix
(GR-909 s. 5.2.1.5.4, R5-18) shown in Table 38.
• Support for automatic upspeed to G.711 when fax and data modem tones are
detected.
• Support of media parameter attributes : a=X-fax and a=X-modem.
• Detection of 2225 Hz Bell 103 modem tone, used with security panels and other
very low bit rate devices, with automatic upspeed to G.711.
• Detection of 2300 Hz tone causing automatic disabling RFC 2833 DTMF transport
if it was active during the call.
• In the transition from voice to T.38, the ability to re-use the audio media stream
and UDP port for the T.38 image media stream.
• In the transition from T.38 to voice, The same UDP port used with the T.38 image
media shall be used with the SDP offer for the audio.
• Transition to T.38 upon detection of V.21 flags received at the POTS port.
• Fax: V.21, V.17, V.27ter, V.29, V.34 compliance.
• Modem (or text phone): V.18, V.21, V.22, V.22bis, V.23, V.32, V.32bis, V.32ext,
V.34,V.90, V.92, Baudot, Bell103, Bell 212A, V.25/V.8/V.8bis compliance.

NT
• Configurable T.38 Error Correction Mode (ECM) : enabled / disabled.

• When T.38 ECM is disabled, the system intercepts the analog DIS/DTC signal
received from the fax terminal and resets the ECM (Error Correction Mode) bit (bit
#27).
• When T.38 ECM is enabled. the system transmits the T.4 ECM packet in smaller
packets in accordance to the provisioned packetization time.
• Put the channel in ECM mode (set the ECM bit #27)
• When the parameter T38_ECM_Ptime is set to 0, the T.38 channel will transmit
the T.4 ECM packet as one packet.
• When the parameter T38_ECM_Ptime is set to a value <> 0, then the system
transmits the T.4 ECM packet in smaller packets in accordance with the provisioned
packetisation time (20, 30, 40 ms).
Table 38 Detection matrix
Tone detected at near-end Tone detected from far-end
None DNG 2100 Hz with Phase rev
None Voice Fax Data
CNG Fax - Data
210 Hz with Phase Rev Data Data -
14.4.6 Supplementary services

The TISPAN PES emulates the PSTN services to subscribers with full transparency
regarding the “look and feel” of the services. Subscribers can continue to use their
legacy terminals connected to the IMS network via gateways.
TISPAN PES defines two models on how the Voice Gateway interacts with the
Application Server with respect to SIP call manipulation for supplementary services.
In the tightly coupled model, the VGW remains mostly ignorant to the call control
logic of the supplementary service. It simply acts under the direction of the AS and
will report any event to the AS who will manipulate the call leg(s). Supplementary
service logic is mostly centralized in the AS.
In the loosely coupled model, service logic is pushed into the VGW. The VGW will
autonomously interpret user events and will autonomously manipulate the call legs
accordingly.
The Integrated VoIP service supports both models. Although both models cannot run
in parallel.

NT
14.4.6.1 General
Table 39 lists the representative supplementary services that work in conjunction
with the Nokia IMS solution. More extensive treatment of the supplementary services
supported is available in the associated Nokia IMS documentation.
No Supplementary Service POTS
Multiparty Services Call Waiting (CW): ✓

• activation / deactivation / explicit or implicit subscription
• Subscriber controlled behavior per line, configurable via SNMP /
CLI management interface
• subscription of CW
• activation / deactivation / interrogation of CW
• invocation of CW
Call Hold (HOLD): activation / deactivation / explicit or implicit ✓
subscription
3-Party Conference (3PTY): activation / deactivation / explicit or ✓

implicit subscription
Explicit Call Transfer (ECT): activation / deactivation / explicit or ✓

implicit subscription
Call Completion to Busy Subscriber (CCBS) / Ring Back (transparent) ✓

Calling Line Calling Line Identification Presentation (CLIP) ✓
Identification Services
Calling Line Identification Restriction (CLIR): Permanent / On a per call ✓
basis
CWID service ✓
Malicious Call Identification (MCID): Permanent / After call ended ✓
Call Diversion Services Call Forwarding Unconditional (CFU) ✓
Call Forwarding Busy (CFB) ✓

Call Forwarding No Reply (CFNR) ✓
Call Forwarding to Voice Mail ✓
Selective Call Forwarding (SCF) ✓
Notification Services Special dial tone in case diversion service activated ✓
Special dial tone in case Message waiting service activated and new ✓
waiting messages at VMS for the user's account.
SIP based Integrated VoIP access device supports the TS183 043 ✓
standardized solution (Annex A) for dial tone management based on
unsolicited NOTIFY SIP messages using the ua-profile XML body
Distinctive Ringing ✓
(1 of 2)

NT
No Supplementary Service POTS

Call Barring Services Outgoing Call Barring (OCB): Administrative / User Controlled ✓
Incoming call barring (ICB): Administrative / User Controlled ✓
Do Not Disturb (DND) ✓

Bad Payer ✓
Selective Call Baring Selective call rejection ✓

Services
Selective call acceptance ✓
Anonymous Call Rejection (ACR) ✓
Fixed Destination Call HotLine ✓

(FDC
WarmLine: activation / deactivation / explicit or implicit subscription ✓
(interrogation via service code).
(2 of 2)
14.4.6.2 Call Forwarding Notification:

The system supports Call Forwarding Notification (Ring-Ping) using :
• SIP SUBSCRIBE/NOTIFY method with Comm-div-info + XML body in compliancy
with 3GPP TS 24.604
• SIP MESSAGE method with comm-div-info + xml
The system supports Call Forwarding Reminder Ring and status indications (NA
customers)
• For loosely Coupled Model
• The system supports " CF Reminder Ring " using SUBSCRIBE/NOTIFY.
• The system supports " CF Status indications active/inactive (stutter dial tone) "
using SUBSCRIBE/NOTIFY.
Interoperability of the SIP based Integrated VoIP access device with a 3rd party
Voice Application Server can be supported through commercial agreement. Please
contact the ISAM PU for the supported supplementary services list.

NT
14.4.6.3 Malicious Call Identification extended with below

Malicious Call Tracking :
• Upon identifying a malicious call the callee flash hooks to put the caller on hold
• Next, the callee dials the service code causing the SIP UA to send a re-INVITE
message to the Application server with XML including McidRequestIndicator=1
• Upon the receipt of the mutual acknowledge by the callee's SIP UA and the
Application Server, the latter sends the malicious call identification information to
the network management server.
14.4.6.4 Tightly Coupled Model

• “Call Waiting”:
• Flash-hook only: Calling termination presses the flash-hook to switch between the
current called termination and a 3rd party.
• Flash-hook + SOC (Switch Order Command): Calling termination presses flash-hook
and dials an additional digit to switch between the current called termination and a
3rd party
• “Call Hold”:
• Hard Hold:
• Only calling and called termination involved.
• Allowing calling termination to Flash Hook once to put the called termination on
hold, and to Flash Hook once again to resume the call with the hold termination.
• Call Hold Consultation:
• Calling termination, called termination and 3rd party involved.
• Allowing calling termination to put an existing call on hold and to initiate a second
call to a 3rd party
• ANSI: Full Consultive Call Hold support via feature code.
• “3-party Conference”:
• Automatically bridged call by AS
• User dialing decided conference call
• “Explicit Call Transfer”:
• Consultative call transfer: for forwarding a call after the first person who was called
spoke to the caller. (e.g. This is useful if a secretary is called and forwards the call
afterwards to the responsible person).
• 3-Way Call transfer: With 3-Way Call Transfer, a termination can set up a 3-way call
and then disconnect, allowing the remaining parties to continue the conversation.
• Blind call transfer: to transfer a call without talking to the called party.

NT
• “Malicious Call Identification”:

• Permanent (transparent to Integrated VoIP service access device).
• After call completion.
• During call (transparent to Integrated VoIP service access device).
Note — In this case the Application Server cannot make any

different between flash-hook for MCID or flash-hook for other
supplementary service e.g. put call on hold.
As such, the Application Server does either support MCID or
the rest of the supplementary service activated by flash-hook,
but cannot support both simultaneously.
14.4.6.5 Loosely Coupled Model

• “Call Waiting”:
• Supported in compliancy with ETSI TS183043 C.9.1/C.16.1 Loose Coupling, 3GPP
ES 23.228 chap5.11.1, ES 24.228 chap10.1, and China Mobile spec. Generates
re-INVITE message when the supplementary service becomes activated due to
pressing the hook-flash.
• The user is notified by a CW-tone that a 2nd incoming call arrived. The user can
either decide to ignore the call waiting tone or accept the waiting call. Two variants
are supported:
• Simplified CW with Flash-hook only: Calling termination presses the flash-hook to
accept the waiting call and hold the current call. Continuously switching between
both parties by subsequent flash-hook events. To reject the waiting call, the user just
ignores the CW-tone.
• CW with Flash-hook + SOC (Switch Order Command): Calling termination
presses flash-hook and dials an additional digit to either indicate:
• Accept waiting call with release of current call
• Accept waiting call with hold of current call
• Reject waiting call
• Toggle between two calls
• Merge two calls into a 3-way-call conference
• Cancel Call Waiting (CCW) controlled by 485 (confirmation tone played) / 489 (no
confirmation tone played) in response to INVITE sent after subscriber dialled CCW
access code
• Cancel Call Waiting (CCW) in compliancy with GR-572-CORE - LSSGR: Cancel Call
Waiting, FSD 01-02-1204:
• Use of configurable feature code for subscriber requests.
• The “S” modifier without an “R” modifier must be present in the Dial Plan.

NT
• “Call Hold”:
• Complies with ETSI TS183043 C.9.1/C.16.1 Loose Coupling, 3GPP ES 23.228 chap
5.11.1, ES 24.228 chap10.1, and China Mobile specification. Generate re-INVITE
message when the supplementary service becomes activated due to pressing the
hook-flash.
• The user can hold the initial call and initiate an enquiry call to a 3rd party by making
a hook-flash event and dial the 3-party number. Once the enquiry call is established
the user can switch between two calls by making a subsequent hook-flash event.
Following flavours are supported:
• Simplified Call hold with HF-only: the user can continuously switch between two
calls by making a Hook-flash event
• Call Hold with Hook-flash + SOC: user makes a hook-flash event and gets dial
tone. User dials a 1 digit SOC to either:
• Release held call and continue with current active call
• Go back to held call with release of current active call
• Switch continuously between both calls
• Join both calls into a 3-way-call conference
• Support of provisionable Call Hold Failure option "call release and play dial tone":
• SIP server replies with error response in case a subscriber tries to hold a call whilst
the supplementary service is enabled for the same subscriber.
• Upon the receipt of the SIP error response, the SIP UA releases the call and
subsequently plays the dial tone.
• ANSI: Full Consultive Call Hold support via feature code.
• “3 Party Conference”:
• Compliant to both TISPAN and NON-TISPAN specification, noted that the Y-function
hosts in the MRF/MS, not in SIP based Integrated VoIP access device. Although, the
72 lines Voice LT board is also able to do audio mixing. (NON-TISPAN
implementation only supports IOT with Broadworks FS.)
• Supported with the media-stream mixing being done at the IMS core MRF, in
compliancy with 3GPP specification TS24.147 subclauses 5.3.1.3.2 “Conference
creation with a conference factory URI”, 5.3.1.3.3 “Three-way session creation”,
5.3.1.5.3 “User invites other user to conference by sending a REFER request to the
conference focus” and 5.3.1.6.1 “Conference participant leaving a conference”.
• Supported in compliancy with ETSI TS183 043 C.14.2 Loose Coupling option 1 (with
local RTP-stream mixing at the SIP based Integrated VoIP access device) and option
3 (with RTP-stream mixing at the MRF of the core under control of the core
application server).
• The user can hold the initial call and initiate an inquiry call to a 3th party by making a
hook-flash event and dial the 3-party number. Once the enquiry call is established
the user can join both calls into 3-way conference by a subsequent Hook-flash event.
• Support of “Isfocus” parameter in compliancy with GR-577-CORE - LSSGR:
Three-Way Calling, FSD 01-02-1301, with contact header of the form
“username3wc@host” where username is the configured username of the line / user
part of address_of_record appended with the string “3wc”.

NT
• “Explicit Call Transfer”:

• Compliant to both TISPAN and NON-TISPAN specification. (NON-TISPAN
implementation only supports IOT with Broadworks FS.)
• Supported in compliancy with 3GPP ES 23.228 chap 5.11.6 Session Transfer and
ES 24.228 chap 10.5.
• Support REFER message to send the DTMF to the AS according to RFC 3515
“REFER Method/Refer-to header” and RFC 3892 “Referred-By header”.
• Consultative call transfer: for forwarding a call after the first person who was called
spoke to the caller. (e.g. This is useful if a secretary is called and forwards the call
afterwards to the responsible person).
• 3 Way Call transfer: With 3-Way Call Transfer, a termination can set up a 3-way call
and then disconnect, allowing the remaining parties to continue the conversation.
• Blind call transfer: to transfer a call without talking to the called party.
For example, in case *23 is the blind call transfer service code, the digit map shall
include “*23S” as prefix of those patterns to be dialed as transfer target of blind call
transfer service. Those patterns are used for blind call transfer only.
For example, pattern 11xxx is used for basic call, and *23S11xxx is used for blind call
transfer.
• “Malicious Call Identification”
• Permanent (transparent to SIP based Integrated VoIP access device).
• After call is finished (Not supported during a call).
• “Emergency Call”
• Support Emergency number dialing (e.g. 911)
• By adding priority headers in the INVITE message subsequent to dialing.
• Priority: “emergency” in compliancy with RFC 3261
• “Resource-Priority: emrg.0” in compliancy with
draft-ietf-sip-resource-priority-10
• The dial plan contains a specific method of identifying when an emergency
number has been dialed (the “E” modifier).
• Allow an emergency number to be dialed whenever digit collection is performed
• Support Emergency Call E911 for a standard 2-party call with
• call feature blocking
• provisionable forced hold option.

NT
14.4.6.6 Additional Info

• “CLIP”:
• Primary source for the Calling Line Identity is either the “From” header or the
“P-Asserted Identity” header (RFC3325). The primary source to be considered is
configurable in SIP based Integrated VoIP access device.
• In case the end-user becomes identified to the CLIP service as “No subscription”,
“Private” or “Unavailable”, part of the “From” header or from the “P-Asserted Identity”
header will be set to a dedicated value by the IMS core network. SIP-based
Integrated VoIP access device allows to configure whether either “Display Name” or
“User Part” (PAI / From) or both do include this dedicated value.
• The dedicated value(s) for “No Subscription”, “Private” and “Unavailable” are
configurable in SIP based Integrated VoIP access device.
• Should a termination not be subscribed to the CLI service, then no CLI data
transmission signalling sequence is applied.
• Should a termination be identified as “Private CLI”, then the calling Line identity
parameter is omitted. Instead, “Reason for absence of calling line ID=private” is
propagated.
• Should a termination be unavailable, then the calling Line identity parameter is
omitted. Instead, “Reason for absence of calling line ID=unavailable” is propagated.
• Should both, a tel-uri as well as a sip-uri formatted P-Asserted Identity header be
present, then precedence is given to one of these headers in accordance with the
precedence policy configured in SIP based Integrated VoIP access device.
• In general, IMS networks do provide calling number information in the global number
format identified by the leading “+” character (Ref. RFC3966). SIP based Integrated
VoIP access device is able to convert the leading “+” into a configurable
international-prefix before the CLI propagated in the CLIP FSK data message.
• SIP-based Integrated VoIP access device allows to configure whether the “Date and
Time” parameter is to be included in the CLIP FSK data message. SIP based
Integrated VoIP access device allows to configure whether the date and time shall
be taken from the SIP INVITE Date Header or from the local SIP based Integrated
VoIP access device time reference.
• The Privacy header with value “id”, “user”, “header” is used for Calling Party
Number/Name restriction. Number only, Name only, both Number and Name
restriction are configurable by SIP based Integrated VoIP access device.
• Privacy header with value “none” means that CLI is not forbidden by Privacy header.
Whether CLI is presented or not still depends on the CLIP subscription status.
• Audible and Visual Message Waiting Indication:
• SIP-based Integrated VoIP access device supports the NOTIFY messages with
Messages-Waiting parameter in the application/simple-message-summary body. If
the message waiting indicator state is ON, then Stutter Tone (Message Waiting
Indicator Tone) will be output during call origination (replacing normal Dial Tone).
• Visual Indication FSK will be output to the telephone set.

NT
• Fixed line SMS service.

• SIP-based Integrated VoIP access device supports the “Fixed line SMS” service in
compliancy with SIN413 “Fixed Line SMS”.
• As to be able to make use of this service, the termination needs to install an SMS
enabled terminal (SM-TE).
• Once the call between the SM-TE and SM_SC has been successfully established,
either SM-TE or SM-SC will initiate the FSK data transmission in compliancy with
ETSI EN 300 659 -2 (Off-hook data transmission).
• The TE-alerting signal (TAS) is used to signal that data-transmission shall be carried.
Upon the receipt of the TAS (line side & IP side), the SIP based Integrated VoIP
access device switches to VBD mode.
• Only the Dual Tone TE-alerting signal can be used for off-hook data transmission, as
is specified in EN 300 659 - 1 (On-hook data transmission).
14.4.7 Release Control

• Called Subscriber Held (a.k.a re-answer),
• Calling party hold by emergency operator,
• Other calls to/from non-emergency operators for which to hold
• Calling party hold for malicious calling indication in compliancy with the call flow
diagrams documented in NICC ND1021 (v.0.13.1), chapter E.2.7 & E.2.8 (support
of INVITE 'no ring').
14.4.8 SMS
• Fixed Line SMS service.
• FSK Data transmission in compliancy to ETSI EN 300 659 - 2.
• TE-altering signal (TAS) used to signal the data transmission and to force the
receiver to switch to VBD mode.
14.4.9 PANI Header

PANI Header insertion is done in compliancy with the 3GPP TS24.229 standard:
• Initial REGISTER / User initiated reregistration / User initiated deregistration:
if available to the UE (as defined in the access technology specific annexes for
each access technology), a P-Access-Network-Info header field set as specified
for the access network technology (see subclause 7.2A.4)

NT
• UE-originating case :
If available to the UE (as defined in the access technology specific annexes for
each access technology), the UE shall insert a P-Access-Network-Info header
field into any request for a dialog, any subsequent request (except ACK requests
and CANCEL requests) or response (except CANCEL responses) within a dialog
or any request for a standalone method (see subclause 7.2A.4).
• UE-terminating case :
If available to the UE (as defined in the access technology specific annexes for
each access technology), the UE shall insert a P-Access-Network-Info header
field into any response to a request for a dialog, any subsequent request (except
CANCEL requests) or response (except CANCEL responses) within a dialog or
any response to a standalone method (see subclause 7.2A.4).
(Thus : PANI-header not included ACK, (response to) CANCEL, 100 Trying,
(response to) session refresh request).
Following formats are supported:
Format 1:
• Format = P-Access-Network-Info: ADSL; dsl-location=”quoted string”
• The PANI header (dsl location) is based on part of the ISAM System Id and used
by the IMS core to identify the originating access device of a SIP request.
Format 2:
• Format = P-Access-Network-Info : <AccessType>; dsl-location=
"$LineID;$IPsip;$UserID;;;"
• The PANI header (dsl location) is based on part of the ISAM Termination Line Id.
Authentication by the IMS core is based on IMPU (=RN) (From) & Access-Id
(PANI Line-Id)
Format 3:
• Format = P-Access-Network-Info: <AccessType>; dsl-location=
"line-id=<MSAN-SIP-IP>;cc=39;oc=204;lac=<MSAN-LAC>;ali=;";network-provid
ed

NT
14.4.10 Dial Tone Management

If there is a MWI by means of a message-summary event and CFx dialtone
management requires special dial tone via ua-profile, then the system applies the
following policies :
• For a SIP termination without Voice Mail messages waiting in the Voice Mail
Server and no CFx activated, the normal dial tone is applied during a time period
of 15 sec.
• For a SIP termination without Voice Mail messages waiting in the VoiceMail
Server and CFx activated, the special dialtone is applied during a time period of
15 sec.
• For a SIP termination with Voice Mail messages waiting in the VoiceMail Server
and CFx activated, the Message waiting tone is applied during a time period of 4
sec., followed by the special dialtone during a time period of 11 sec.
• For a SIP termination with Voice Mail messages waiting in the VoiceMail Server
and CFx activated, the Message waiting tone is applied during a time period of 4
sec., followed by the special dialtone during a time period of 11 sec.
• If the end-user starts to dial digits at any time during the 15 sec time period, the
playing of the actual tone is stopped
14.4.11 Flash-hook handling for SIP termination with or

without supplementary service
• For all call states, except 'connected', the Flash hook event is handled as an
"on-hook" event followed by an "off-hook" event.
• In ‘connected' state:
• With supplementary services, the Flash hook event triggers the relevant service.
• Without supplementary services, the Flash hook event is handled as an "on-hook"
event followed by an "off-hook" event.
14.4.12 Last Dialed Number List

By building a self learning list of dialed numbers, the user experiences no extra call
setup delays due to the inter-digit timer timeout for "open" numbering destinations
when they dial the number regularly.
• An LDN list is maintained per subscriber line
• The LDN lists are stored in volatile Voice LT board memory. No copy is stored in
the DB at the MSAN's system disk
• The Digit Map matching mode must be set to "MINIMUM".
• The Digit Sending mode must be set to "EN-BLOC"
• The LDN list can contain a maximum of 50 entries per line.
• An LDN list entry can contain a dialed directory number of max 24 digits.

NT
• The LDN list feature is enabled when the regular rule "x.T" is present in the dial
plan.
• The LDN list feature is disabled when the regular rule "x.T" is missing in the dial
plan.
• Additional regular rules, different from "x.T", with full match, must be added to the
dial plan for those DNs that should not be stored in the LDN list.
• A dialed DN is a candidate DN to be stored in the LDN list on the condition that it
matches the "x.T" rule.
• The following SIP responses to the SIP INVITE are considered "valid" responses
resulting in the storage of the dialed DN in the LDN list:
• 200 OK
• 180 ringing (only 180 (with/without SDP) is considered, other 18x messages are
excluded),
• 486 busy
• The dialed DN shall be removed from the LDN list (on the condition that the DN
was already stored because of a "valid" response received to the initial INVITE
request) in case subsequently one of the following SIP response messages
should be received:
• ‘no service'(404),
• ‘non-existing number' (484).
• The LDN list of a subscriber line or multiple subscriber lines can be manually reset
by means of one of the following operator / subscriber actions :
• Lock / unlock the subscriber line (operator action)
• Lock / unlock the VSP (operator action)
• Lock / unlock the SIP UA (operator action)
• Lock / unlock the SIP server (redundancy = disabled) (operator action)
• Any change to the digit map, e.g. remove x.T, add new rule, etc… (operator action)
• Reboot LT board (operator action)
• The dialing of the special "ScForLDNErase" service code e.g. **#93# (subscriber
action).
At a successful erase of the LDN list via the service code, a 60 sec congestion tone
gets played (followed by parking tone in case the subscriber remains off-hook)
• The LDN list of all subscriber lines shall autonomously be reset by the MSAN upon
• SW Upgrade
• SW Migration
• System reset
• LDN list per line structured as a sequentially accessed array
• Last dialed DN not present in the list and list not full: add last dialed DN at the top
• Last dialed DN not present in the list and list full: remove last DN in list and add last
dialed DN at the top
• Last dialed DN present in the list and list not full: move last dialed DN to the top
• Last dialed DN present in the list and list full: Move last dialed DN to the top
• The minimum number of digits of a DN that shall be stored in the LDN list is
preprovisioned in the CDE file.

NT
14.4.13 Message Waiting Indication upon off-hook

The feature implies that for those SIP users that have Voice Mail subscription and
MWI activated and "not-listened" voice messages being present at the voice Mail
Server, upon off-hook, a MWI announcement is played notifying the user that one or
more new "not-listened" voice-messages are present at the Voice Mail Server.
When the message has finished, the user hears the tone for selection.
It is possible to stop the voice message by pushing any button.
It is possible to modify the MWI announcement definition without installing a new
ISAM release. The MWI announcement is defined in the CDE profile.
When the user starts dialing during the MWI announcement, the announcement is
stopped and normal digit collection applies.
14.4.14 Performance Monitoring

The statistics can be retrieved using CLI or an Element Management System (EMS
/ SDC). See the related documents for detailed information and the detailed
command definitions for retrieving the VoIP service counters and/or statistics.
(Operations and Maintenance Guide Using CLI, 5529 Statistics and Data Collector
Installation and User Guide).
The SIP based integrated VoIP service supports different performance monitoring
methods. Access products may support all or a subset of these methods. Please
contact the ISAM PU for further details.
The different performance monitoring methods are explained hereafter.
14.4.14.1 History Interval framework

One of the methods supported by the SIP-based integrated VoIP service for the
collection and reporting of statistics and counters is the History Interval Framework.
This basic framework relies on current and historical intervals to store the history of
the statistics and counters. This is typically one interval per 15 minutes or 24 hours.
The start and end time of each interval (15 minutes / 24 hours) are aligned with the
quarter hours / 24 hours of the wall clock.
Should the duration of a call session exceed the interval boundary, then the statistics
and counters for such call session will be collected and reported spread over multiple
intervals. The post-processing i.e the concatenation / sum-up of all portions for such
statistics and counters, in order to calculate the results for the full call, is not
supported by the Integrated Voice Service access device; It is to be done by an
external expert system (e.g. SDC).

NT
Figure 182 SIP ISAM Voice Performance Monitoring Result Post-Processing

OSS Platform
2. Associate PM record 1. Generate PM record
with CDR record by using the for dialog A including
Dialog Reference Dialog Reference
CDR
Other NE
SDC
2. Generate PM record for dialog A including Dialog Reference.
1. Retrieve all PM portions for dialog A using Dialog Reference
Dialog A “Elapse” time

Dialog A “active” time – portion 1 Dialog A “active” time – portion 2
Dialog A Dialog A
Dialog A Dialog A e.g. put Dialog A Dialog A
Portion_1 Portion_2 on hold Portion_3 Portion_4
PM record PM record PM record PM record
Recent 15 min interval N-1 Recent 15 min interval N Recent 15 min interval N+1
1 PM record for dialog A 2 PM records for dialog A 1 PM record for dialog A

in this 15 min interval in this 15 min interval in this 15 min interval
The SIP based Integrated VoIP Service supports voice related per-line, per-board
and per call statistics / counters.
For the per-line statistics and counters, the current 15 min / 24 hours interval together
with a set of 96 x 15 min and 3 x 24 hours history intervals is supported. (Only a
subset of the per-line statistics and counters is supported for the 15 min interval)
For the per-call statistics and counters, a set of 96 x 15 min history intervals is
supported (The current 15 min interval is not supported).
For the per-board statistics and counters, the current 15 min / 24 hours interval
together with a set of 96 x 15 min and 3 x 24 hours history intervals is supported.
(Only a subset of the per-line statistics and counters is supported for the 15 min
interval)
For a history interval, the interval number, interval start time stamp, measured time
and invalid data flag attributes are supported.
For a current interval, the measured time and invalid data flag attributes are
supported.
The SIP based Integrated VoIP Service supports TCA handling. The TCA can be
enabled / disabled for each individual subscriber line. Both the high and the low TCA
threshold are configurable.
Statistics can be explicitly enabled / disabled by means of the regular management
channel. The system does not allow to enable/disable a particular performance
monitoring category. Either PM is enabled for all categories (per-Line, per-Board,
per-Call) or PM is disabled for all categories (per-Line, per-Board, per-Call).

NT
Table 40 Overview of Per-line Statistics and Counters
Statistics Description
Packets Sent The number of RTP packets sent by a SIP termination during a single
Packets Received The number of RTP packets received by a SIP termination during a single
interval
Octets Sent The number of octets sent by a SIP termination during a single interval
Octets Received The number of octets received by a SIP termination during a single interval
Average Inter-Arrival Jitter The average Inter-Arrival Jitter for (an) RTP data stream(s) of a SIP
termination in a single interval.
Peak Inter-Arrival Jitter The peak Inter-Arrival Jitter measured for (an) RTP data stream(s) exchanged
by a SIP termination during a single interval.
Average Round Trip Delay The average Round Trip Delay for (an) RTP data stream(s) of a SIP
termination during a single interval
Peak Round Trip Delay The peak Round Trip Delay measured for (an) RTP data stream(s) exchanged
by a SIP termination during a single interval
Average Jitter Buffer Fill level The average jitter buffer fill level for a SIP termination during a single interval
Average Jitter Buffer Fill level The average jitter buffer fill level measured during the receipt of (an) RTP
G711a stream(s), encoded with G711_a by a SIP termination during a single interval
G711u stream(s), encoded with G711_u by a SIP termination during a single interval
G723 stream(s), encoded with G723 by a SIP termination during a single interval
G729 stream(s), encoded with G729 by a SIP termination during a single interval
Total Packet Loss The total (absolute) amount of packets lost for a SIP termination during a
single interval.
Successful (Re-) Register The number of (re-)registration requests which are successfully replied in this
requests interval i.e. a response = 200 OK with expire header time = 0 or expire header
<> 0 has been returned by the Registrar.
Failed (Re-) Register requests The number of (re-)registration requests which failed in this interval i.e a
response <> 200 OK was returned by the SIP First Hop server / Registrar or
that SIP transaction timed-out.
Active Registrations The number of registrations being active at a subscriber port at the start of the
interval. In the current implementation, only 1 registration can be active at a
subscriber port at a time. An active registration is counted when a registration
request has been successfully completed in the past (200 OK received to
register request with “expire header” time <> 0) and the register expiration
interval hasn't expired.
Outgoing Calls Answered The number of outgoing call attempts in this interval for which an initial INVITE
(Outgoing Calls Connected) request is sent AND for which a response is received. The system allows to
provision what kind of response must be received as to be counted as a
successful outgoing call attempt. The system offers the following options:
• Any response received (irrespective of whether this is a successful or
unsuccessful response).
• A successful response received (180 or 200 response only).
• A 200 OK response received.
(1 of 3)

NT
Incoming Calls Answered The number of incoming call attempts in this interval for which a SIP response
(Incoming Calls Connected) is sent being the result of the off-hook event been detected. The system allows
to provision the kind of response that will be considered as to be counted as
a successful incoming call attempt. The system offers the following options:
• Any response sent.
• 180 response sent.
• 200 OK response sent.
Outgoing Call Attempts The number of off-hooks being detected and considered as being the starting
event to make an outgoing call attempt (The detection of an off-hook event as
the result of an incoming call attempt must not be considered).
This counter counts both the off-hook events detected as being the starting
event of an outgoing call attempt in the scope of a basic call and the
Hook-flashes as being the starting event of a new outgoing call attempt in the
scope of a conference call.
Outgoing Call Seizure Duration The port seizure time for outgoing call attempts. This counter is only
applicable to the outgoing call attempts whereby the subscriber dials a valid
digit before the starting dial timer expiry.
(With "valid digit" is to be understood a digit that at least partially matches one
digit map pattern in the configured digit map.)
Incoming Call Attempts The total number of incoming SIP INVITE requests, considered as being a SIP
INVITE request for a new incoming call attempt, and this regardless of
whether the incoming call attempt has successfully been processed / replied
or not.
Incoming Call Seizure Duration The port seizure time for incoming call attempts. The port seizure duration is
the time elapsed from the moment the called subscriber gets notified that an
incoming call attempt has arrived (ringing / call-waiting tone put at the line till
one of the following events is detected:
• the receipt of the off-hook or
• the receipt of the flash-hook event or
• the receipt of the SIP CANCEL request or
• the expiry of the ringing tone sequence or
• the expiry of the (call forwarding no reply) "No Answer Timeout" or
• the receipt of the call-waiting tone sequence.
Accepted RTP Packets The number of ACCEPTED RTP packets equals the number of expected RTP
packets minus the number of missed RTP packets minus the number of defect
RTP packets minus the number of doubled RTP packets minus the number of
later arrived RTP packets minus the number of early received RTP packets.
Or in other words, the number of ACCEPTED RTP packets equals the number
of RTP packets used for voice generation at the receiving side.
Expected RTP Packets The number of RTP packets EXPECTED is defined to be the extended last
sequence number received, less the initial sequence number received.
Discarded RTP Packets The number of DISCARDED RTP packets other than late or early arrived
equals the number of received but not used downstream RTP packets which
can be assigned to the port and without early or late package loss.
Equals the number of defect RTP packets plus the number of duplicated RTP
packets.
(2 of 3)

NT
RTP Packets lost due to Early The number of DISCARDED RTP packets due to early or late arrival equals
or Late Arrival the number of received RTP packets which can be assigned to the port but are
received too early (Jitter buffer over-flow) or too late (Jitter buffer under-run)
and that are consequently not used for the generation of the voice stream.
Equals the number of early received RTP packets plus the number late
received RTP packets.
Port Registration Duration The total amount of time that, from an MSAN point of view, a SIP termination
configured at a voice LT board is considered to be successfully registered at
the IMS core.
Port Availablility Duration The total amount of time that a SIP termination configured at a voice LT board
is considered to be administratively available, that is, the elapse time that the
port's administrative state as well as its higher layer object's administrative
status (SIP User Agent admin state, SIP User Agent Access Point admin
state, Voice Service Provider admin state) are all set to "unlocked".
Outgoing call attempts that The number of outgoing call attempts that could not successfully be
failed due to a lost seizure completed because of a lost seizure with the control network.
towards the control network Or in other words, the number of outgoing call attempts that fail because of an
access failure to the voice network.
Incoming call attempts that The number of received incoming call attempts that could not successfully be
failed due to a lost seizure completed because of a lost seizure with the control network.
towards the control network Or in other words, the number of incoming call attempts that fail because of an
Outgoing Successful Invites The number of initial SIP INVITE requests that are replied by the IMS core with
a 100-Trying followed by:
Or in other words, the number of outgoing call attempts that fail because of an
• A 180-Ringing Provisional Response
• A 183-Session Progress Provisional Response.
• A 200 OK (No 18x Provisional Response in between the receipt of the
100-trying and the 200 OK)
(3 of 3)
Table 41 Overview of Per-call Statistics and Counters
Packets Sent The number of RTP packets sent by a SIP termination since the call is
established/ the start of the interval and the end of the call/ the expiry of the
interval
Packet Received The number of RTP packets received by a SIP termination since the call is
interval
Octets Sent The number of octets sent by a SIP termination since the call is established /
the start of the interval and the end of the call/ the expiry of the interval
Octets Received The number of octets received by a SIP termination since the call is
interval
Average Inter-Arrival Jitter The average Inter-Arrival Jitter for the RTP data stream since the call is
interval.
(1 of 2)

NT
Peak Inter-Arrival Jitter The peak Inter-Arrival Jitter for the RTP data stream since the call is
interval.
Average Round Trip Delay The average Round Trip Delay for the RTP data stream since the call is
interval.
Peak Round Trip delay The peak Round Trip Delay for the RTP data stream since the call is
interval.
Total Packet Loss The total (absolute) amount of packets lost for the RTP data stream since the
call is established/ the start of the interval and the end of the call/ the expiry of
the interval.
Total Packet Loss due to Jitter The total (absolute) amount of packets lost due to Jitter Buffer Overrun for the
Buffer Overrun RTP data stream since the call is established/ the start of the interval and the
end of the call/ the expiry of the interval.
(2 of 2)
Table 42 Overview of the Per-Board statistics and counters
Packets Sent The number of RTP packets sent by all SIP terminations of an LT board during
a single interval
Packets Received The number of RTP packets received by all SIP terminations of an LT board
during a single interval
Octets Sent The number of octets sent by all SIP terminations of an LT board during a
single interval
Octets Received The number of octets received by all SIP terminations of an LT board during
a single interval
Average Inter-Arrival Jitter The average Inter-Arrival Jitter for (an) RTP data stream(s) exchanged by an
LT board during a single interval.
Peak Inter-Arrival Jitter The peak Inter-Arrival Jitter measured for (an) RTP data stream(s) exchanged
by an LT board during a single interval.
Average Jitter Buffer Fill level The average jitter buffer fill level for an LT board during a single interval
Average Round Trip Delay The average Round Trip Delay for (an) RTP data stream(s) exchanged by an
LT board during a single interval
Peak Round Trip Delay The peak Round Trip Delay measured for (an) RTP data stream(s) exchanged
by an LT board during a single interval
Total Packet Loss The total (absolute) amount of packets lost by an LT board during a single
interval.
stream(s), encoded with G711_a for an LT board during a single interval
G711u stream(s), encoded with G711_u for an LT board during a single interval
G723 stream(s), encoded with G723 for an LT board during a single interval
(1 of 3)

NT
G729 stream(s), encoded with G729 for an LT board during a single interval
Spare POTS Ports Total amount of POTS ports, which are not configured in the SIP termination
Table, but present at the LT board. The value is taken at the beginning of the
respective interval
Active POTS Ports Total amount of available configured (configured and not administratively
blocked) POTS ports (independent of line status and registration) at the LT
board. The value is taken at the beginning of the respective interval
Inactive POTS Ports Total amount of not-available configured (configured and administratively
blocked) POTS ports (independent of line status and registration) at the LT
board. The value is taken at the beginning of the respective interval.
Average CPU Load Average CPU load measured at an LT board during a single interval
Average Memory Utilization Average amount of semi and dynamic memory being used at an LT board /
NT board) during a single interval. Expressed as a percentage.
Average Free Memory Average amount of free semi and dynamic memory measured at an LT board
/ NT board during a single interval. Expressed in MB.
Average Memory Used Average amount of semi and dynamic memory being used at an LT board /
NT board) during a single interval. Expressed in MB.
Total Memory The total amount of semi and dynamic memory available at an LT board / NT
board. Expressed in MBytes
Successful (Re-) Register The number of (re-)registration requests which are successfully replied in this
requests interval i.e. a response = 200 OK with expire header time = 0 or expire header
<> 0 has been returned by the Registrar.
Failed (Re-) Register requests The number of (re-)registration requests which failed in this interval i.e a
response <> 200 OK was returned by the SIP First Hop server / Registrar or
that SIP transaction timed-out.
Active Registrations The number of registrations being active at a subscriber port at the start of the
interval. In the current implementation, only 1 registration can be active at a
subscriber port at a time. An active registration is counted when a registration
request has been successfully completed in the past (200 OK received to
register request with “expire header” time <> 0) and the register expiration
interval hasn't expired.
Outgoing Calls Answered The number of outgoing call attempts in this interval for which an initial INVITE
request is sent AND for which a response is received. The system allows to
provision what kind of response must be received as to be counted as a
successful outgoing call attempt. The system offers the following options:
• Any response be received (irrespective of whether this is a successful or
unsuccessful response).
• A successful response received (180 or 200 response only).
Incoming Calls Answered The number of incoming call attempts in this interval for which a SIP response
is sent being the result of the off-hook event been detected. The system
allows to provision the kind of response that will be considered as to be
counted as a successful incoming call attempt. The system offers the
following options:
• Any response sent.
• 180 response sent.
Port Registration Duration The total amount of time that, from an MSAN point of view, a SIP termination
configured at a voice LT board is considered to be successfully registered at
the IMS core.
(2 of 3)

NT
Port Availablility Duration The total amount of time that a SIP termination configured at a voice LT board
is considered to be administratively available, that is, the elapse time that the
port's administrative state as well as its higher layer object's administrative
status (SIP User Agent admin state, SIP User Agent Access Point admin
state, Voice Service Provider admin state) are all set to "unlocked".
Number of Broken Ports The number of ports that, due to a HW failure, cannot be operational.
The counter is event driven, upon both HW fault detection and HW fault
resolved/disappearing.
The counter cannot be reset upon the beginning of a new current interval
since the HW fault event for an already existing HW fault is not going to be
received once again at the start of a new interval. (HW faults that were
detected in an earlier interval and that were still not resolved).
The following fault events can be detected by the SW at the voice LT board
• /** Device detected battery fault */
• /** Device detected clock fault */
• /** Thermal Overload condition */
• /** DC Fault detected on line */
• /** AC Fault detected on line */
• /** SLAC Synchronization fault */
• /** Low loop resistance while on-hook */
• /** Sealing current error */
• /** Watchdog timer fault */
• /** event queue overflow fault */
• /** VCP2 system fault */
The previous interval reflects the number of broken ports at the Line Card at
the start of the current interval for which this previous interval has been
created.
Number of Active Connections The number of incoming or outgoing stable call connections that are active at
the Line Card.
An active connection is considered a call in stable phase regardless of
whether this call is on hold (3 party call) or not on hold (basic call and 3 party
call).
In the scope of this counter, a connection is considered to be "active" from the
moment an outgoing or incoming call attempt is replied with a "200 OK" (200
OK sent to an incoming call attempt or 200 OK received on an outgoing call
attempt.
The previous interval contains a snapshot of the number of connections that
were active at the Line Card at the at the start of the current interval for which
this previous interval has been created.
(3 of 3)
14.4.14.2 Short-Lived Framework

The short-lived method supported for the System-wide resource utilization related
statistics / counters and System-wide Subscriber Line Utilization and service
availability statistics / counters makes use of operational counters.

NT

Counters
Average CPU Load The average CPU load for a particular LT board (180 s)
Detailed CPU load Detailed list of the CPU load measured with a 1 s interval over a total period
of 180 s
Absolute Memory Utilization The absolute value of the total amount of memory resources utilized by a
particular LT board.
Percentage of Memory The percentage of memory resource utilization compared to the available
Utilization dynamic memory resources for a particular LT board

Counters
Non-Configured Lines The amount of planned/equipped subscriber lines for which no entry could be
found in the SIP Termination Table.
Operational Configured Lines The amount of subscriber lines configured in the SIP Termination Table and
for which the operational state equals “up”.
Non-Operational Configured The amount of subscriber lines configured in the SIP Termination Table and
Lines for which the operational state equals “down”.
14.4.15 Validating Origin of SIP request

The system allows to check the origin of a received SIP request (Invite, Options,
Notify) message.
Following origin check options are supported:
1 A SIP request gets accepted irrespective of the origin of the request (SIP request
is accepted from any SIP first hop server)
2 A SIP request gets accepted on the condition that it originates from the SIP first
hop server that has been selected as the SIP first hop server currently to be
addressed (Active SIP server) for outgoing SIP requests.A SIP request received
from SIP first hop server other than the ACTIVE SIP server is rejected with
response code “403”.

NT
3 A SIP request gets accepted on the condition that it originates from one of the
SIP first hop servers that are maintained in the locally created SIP first hop server
White List. This “White List” includes all configured (IP@, FQDN, DN) and
administratively enabled SIP first hop servers (primary + secondary) in the SIP
Server Table (SIP MIB).
A SIP request received from SIP first hop server other than the SIP first hop
servers appearing in the White List is rejected with response code “403”.
The system allows to check the origin of a received SIP response message.
A SIP response message gets dropped if it does not originate from the Active SIP
server / a SIP first hop server appearing in the White List.
14.4.16 SIP POTS Termination States

Following states are supported and can be displayed by means of the SNMP/ CLI
management interface on a per individual SIP termination:
• Administrative State [Up, Down]:
• The administrative state of the SIP termination.
• Manually configured by the operator.
• Operational State:
• The operational state of the SIP termination.
• Autonomously set by the system.
• Can only become "UP" if the administrative status equals "UP".
• Changed to "UP" upon the successful registration of the SIP termination to the IMS
core.
• Changed to "DOWN" in case :
• The administrative status of the SIP termination is configured to "DOWN" (SIP
termination becomes de-registered)
• An alarm is raised on the SIP termination's physical line.
• The SIP termination becomes de-registered (various reasons for instance
connection with SIP first hop server lost, unsuccessful re-registration)

NT
• Call State [Onhook(1), Offhook(2), Dialing(3), Calling(4), Connected(5),

IdleOffhook(6), Ringing(9), Releasing(10), Ringback(11)]:
• Most of these call states are only relevant when the operational status equals "UP".
• Onhook: the line is on-hook i.e. an open loop of a subscriber line.
• Offhook: the closure of the subscriber loop prior to the dialing phase.
• Dialing: the action of initiating a call by operating the keypad of a telephone. The
terminal device transmits pulse or DTMF dialing signals.
• Calling: end of dialing indication received or the dialing information received so far
was evaluated as routable address by the digit map; An initial INVITE has been sent.
The SIP UA is awaiting the reply
• Connected: The subscriber line is in the stable call phase.
• IdleOffhook: parking state. The telephone has been left off-hook for an extended
period effectively disabling the subscriber line.
• Ringing: An audible indication i.e. the ringing tone is sent to the subscriber line of the
called subscriber as to notify the called subscriber about an incoming call
• Releasing: The SIP UA is releasing the call.
• Ringback: An audible indication i.e. the ringback tone is sent to the subscriber line of
the calling subscriber while the phone of the called subscriber is being rung
• Port state [ P0, P1, P2, P2.1, P3, P4, P4.1, P4.2, P4.3, P4.4, P5.1, P5.2, P5.3, P6,
P7]
• See table 45 for details
• Test State [noTesting(1), intgLineTesting(3) ]:
• The "integrated line test busy" state.
• Autonomously set by the system.
• Changed "intgLineTesting (3)" when a POTS NBLT test is executing at the
line(irrespective of whether Test Access State equals ON or OFF)
An NBLT test can be forcibly executed by making use of the "busy-overwrite = true"
option when initiating the NBLT test command.
• Changed to "NoTesting(1)" when no POTS NBLT test is executing at the line.
(irrespective of whether Test Access State equals ON or OFF)
• Test Access State [on (1), off (2)] :
• The "reserved for integrated line test" status.
• Manually configured by the operator.
• When set to "ON" : The line is reserved for integrated NBLT testing only. Both,
outgoing as well as incoming calls, are blocked at this line
• When set to "OFF" : integrated NBLT testing can be executed as well as outgoing
and incoming calls can be made at this line. However integrated NBLT testing might
be affected by a call being made.
• The "reserved for integrated line test" status can be forcibly set to "ON" by making
use of the "busy-overwrite = true" option when initiating the status configuration
command. In this case, the ongoing call will immediately be dropped.
Table 45 Overview of the port states
Port Short designation Comment
P0 Not created Port exists but is not configured and initialized by the system management
system.
(1 of 2)

NT
Port Short designation Comment

P1 Idle state Port is ready to operate; off-load DC voltage is applied at a/b wires of the port
P2 Outgoing seizure From closure of DC loop in terminal device until reception of initial dial
information
P2.1 IExtended dialing Initial address information has been acknowledged by returning a response
"183 - Session Progress" and a dialog is set up.
P3 Incoming seizure Port is ready to operate; call resources are available and SIP message INVITE
was received from the Call Control
P4 Communication An outgoing or incoming connection setup attempt has been completed by

sending a "200 OK".
P4.1 Hold 1 An existing connection is in HOLD state.
P4.2 Hold 2 In addition to an already held connection, another (now active) connection has
been set up completely.
P4.3 Service A hookflash signal was detected in HOLD state. The system is waiting for the
entry of procedure digits.
P4.4 Conference There are two active connections at at port, which are interconnected into a joint
conference.
P5.1 Release A connection setup attempt has failed; the subscriber busy tone or all trunks
request 1 busy tone has been applied.
There is no further connection in HOLD state.
P5.2 Release A connection setup attempt has failed or an event terminating the
request 2 communication has occurred. Another connection is in HOLD state.
P5.3 Release An event terminating the communication has occurred.

request 3
P6 Port blocked Port was blocked by the system management for operational reasons
P7 Test Port is in test mode
(2 of 2)
14.4.17 Self Ringing Service

The Self Ringing Service allows the subscriber, by dialing the prefix 162 followed by
its own DN, to verify whether it subscriber line is properly connected to the access
node (without SIP server supervision).
Overall scenario:
1 The subscriber goes off-hook and dials the prefix 162.
2 The access node puts dial tone at the subscriber line and awaits further input
from the subscriber.
3 The subscriber now dials its own DN (no national code and/or area code required
as input)

NT
4 Upon the receipt of all digits

• If the dialed DN is validated, the access node puts the ring back tone at the
subscriber line with hard-coded ring back timer of 120 sec.
Should the ring-back timer expire, the access node will move the subscriber line to
the re-order state and the re-order tone sequence will be played. The subscriber
goes onhook.
Should the subscriber go on-hook before the ring-back tone timer expires, the access
node will let the subscriber's phone to ring with a hard-coded ringing timer: the value
is read from the CDE profile.
Should there be an incoming call for the subscriber for which the self ringing test is
ongoing, the incoming call will be replied with a 486 'Busy here'.
• If the dialed DN is found to be not the DN of the subscriber or the inter-digit timer has
expired, the access node puts the re-order tone at the subscriber line till the
subscriber goes on-hook.
Should the subscriber go off-hook again, the dial tone is played.
The rule "162S" is to be configured in the digit map.
14.5 SIP Integrated Voice Service - ISDN PRA

Figure 183 SIP Integrated Voice Service - ISDN PRA
14.5.1 General
The MSAN supports eight E1 ISDN PRA interfaces at an ISDN PRA voice LT board.
The ISDN PRA voice LT board behaves as "stand-alone" meaning that the E1 loop
is directly connected to the end-user.
The Q.921 and Q.931 protocols are terminated at the ISDN PRA voice LT board. See
Figure 184.

NT
Figure 184 SIP Integrated Voice Service ISDN PRA protocols
The MSAN configures an ISDN PRA port in point-to-point mode, meaning that, at
layer 1 for each direction, only one source (transmitter) and one sink (receiver) is
connected to the E1 interface.
The maximum reach of the E1 interface in such point-to-point configuration is limited
by the specification of the electrical characteristics of transmitted and received
pulses and the type of interconnecting cable.
There can be only one signaling entity present at the ISDN PRA port.
The L1 layer interface for the ISDN PRA port is kept active at all times.
The ISDN PRA port may be connected to a short-haul or long-haul E1 loop. The
registers of the E1 chip set are fixed configured to long-haul mode.
14.5.2 ISDN PRA User Connection Modes

Definitions:
• E1 Cluster: The entire set of E1 interfaces with which an ISDN PRA user (PBX) is
connected to the MSAN (cabinet) is called an "E1 interface Cluster" or in short "E1
cluster". An E1 cluster might consist of one up to maximum 32 E1 interfaces.
• Virtual E1 Group: The set of E1 interfaces with which an ISDN PRA user (PBX) is
connected to the same ISDN PRA voice LT board is called a "Virtual E1 Group"
(abbreviated as VG). A Virtual E1 Group might consist of one up to maximum
eight E1 interfaces. The E1 Cluster with which an ISDN PRA (PBX) connects to
the MSAN (cabinet) might consist of one or multiple Virtual E1 Groups. In case all
E1 interfaces of an E1 cluster are connected to one and the same ISDN PRA

NT
voice LT board board, (The E1 cluster consists of maximum eight E1 interfaces)

then the E1 cluster contains only one Virtual E1 Group and that Virtual E1 Group
embraces the entire set of E1 interfaces of the E1 cluster.
• Cabinet: a cabinet is defined as a local site MSAN node topology that consist of
one HUB MSAN node together with n subtending MSAN nodes.
Figure 185 shows the ISDN PRA user connections

Figure 185 ISDN PRA User Connections
The ISDN PRA PBX is connected to the MSAN through Virtual E1 Groups (VG 1..N). The E1
E1 interface interfaces terminate at diﬀerent ISDN PRA voice LT boards. A VG groups all the E1
interfaces that terminate at the same ISDN PRA voice LT board.
1
2 SIP SIP
DDI -Ext 1
V UA Term
DDI -Ext 2 G
ISDN PRA voice LT
1 DDI-ext
DDI -Ext 3 E 8 board
List IMS Core Registrar
1
DDI -Ext 4 1
2 SIP SIP
UA Term DDI-ext m
C V
ISDN PRA l G ISDN PRA voice LT
2 8 board
PBX u
The IMS Core Registrar stores in a dynamic way
s and per DDI-ext, the list of SIP User Agent contact
t addresses (and oponally the Q-value for in case
SIP Forking applies).
e 1
SIP SIP
2
DDI -Ext n-1

r V
UA Term
Via the registraon process, each of the SIP User Agents does idenfy itself to the IMS
G ISDN PRA voice LT core registrar as one locaon from where the registering ISDN PRA PBX user is
DDI -Ext n n 8 board reachable
The MSAN supports three different connection modes for an ISDN PRA "user":
• Mode_1: An ISDN PRA user connected by means of a single E1 interface.
The ISDN PRI user is managed by the ISDN PRA voice LT board local SIP User
Agent instance.
Specific IMS core requirements: none.
Required input to the IMS core: none.
• Mode_2: An ISDN PRA user connected to one ISDN PRA voice LT board with two
up to maximum eight E1 interfaces.
The ISDN PRA user is managed by the NIAT-A local SIP User Agent instance.
Specific IMS core requirements: none.
Required input to the IMS core: none.

NT
• Mode_3: An ISDN PRA user is connected to multiple ISDN PRA voice LT boards
planned and equipped in a single or multiple MSANs. (one up to eight E1
interfaces per ISDN PRA voice LT board and maximum 32 E1 interfaces in total).
The E1 interfaces connected to an ISDN PRA voice LT board are managed by the
ISDN PRA voice LT board local SIP User Agent instance. Each ISDN PRA voice
LT board behaves totally independent from the other. The connection to multiple
ISDN PRA voice LT boards by one ISDN PRA user is known to the IMS core only,
that is fully transparent to the MSAN.
Specific IMS core requirements: parallel and/or sequential SIP Forking.
Required input to the IMS core: Q-value in SIP Register request.
All three modes require the configuration of an ISDN PRA SIP termination at each of
the involved ISDN PRA voice LT boards.
The MSAN supports the following deployment and registration alternatives:
• An ISDN PRA SIP termination on top of a single E1 interface:
• The implicit registration of the ISDN PRA SIP termination (GDN-ext Directory
Number / URI).
• The list of implicit registered DDI-EXTs is returned by the register server.
• An ISDN PRA SIP termination on top of an E1 cluster that consists of only one E1
interface (only applicable to 100/320 Gbps NT and FX NT):
• The explicit registration of the GDN-ext directory number / URI and all configured
DDI-EXTs associated with the ISDN PRI SIP termination.
• The configuration of the DDI-EXT list is mandatory.
• An ISDN PRA SIP termination on top of an E1 cluster that consists of only 1 E1
interface:
Number / URI).
• No DDI-EXT list is configured.
• An ISDN PRA SIP termination on top of an E1 cluster that consists of two up to
eight E1 interfaces (only applicable to 100/320 Gbps NT and FX NT):
• The explicit registration of the GDN-ext directory number and all configured
DDI-EXTs of the ISDN PRA SIP termination.
• An ISDN PRA SIP termination on top of an E1 cluster that consists of two up to
eight E1 interfaces:
Number / URI).

NT
• Multiple ISDN PRA SIP terminations with each ISDN PRA SIP termination created
on top of one Virtual E1 Group (one up to eight E1 interfaces) and all Virtual E1
Groups belonging to the same E1 cluster (only applicable to 100/320 Gbps NT
and FX NT):
• Each ISDN PRA SIP termination performs the explicit registration of the GDN-ext
directory number and all configured DDI-EXTs.
• Multiple ISDN PRA SIP terminations with each ISDN PRA SIP termination created
on top of one Virtual E1 Group (1 up to 8 E1 interfaces) and all Virtual E1 Groups
belonging to the same E1 cluster:
• Each ISDN PRA SIP termination performs the implicit registration of the ISDN PRA
SIP termination (GDN-ext Directory Number / URI).
• The list of implicit registered DDI-EXTs is returned by the register server to each of
the SIP terminations.
E1 interfaces that are part of a Virtual E1 Group may have consecutive or

non-consecutive port numbers at the ISDN PRA voice LT board.
For the use case whereby an ISDN PRA user (PBX) is connected to multiple ISDN
PRA voice LT boards, multiple SIP User Agent instances are involved. In case a call
attempt is to be forwarded to the MSAN (cabinet), the selection of a candidate SIP
User Agent instance to handle the call attempt, is done by the IMS core and this by
means of the SIP FORKING standardized approach. The selection is made based
on the q-value received during the registration of the GDN-ext / DDI-ext. As such,
each SIP User Agent instance's contact-address is assigned a q-value for
contact-address ordering.
The MSAN supports a configurable q-value at ISDN PRA SIP termination level.
A SIP User Agent instance sends a SIP REGISTER request for an ISDN PRA user
(PBX) using the respective SIP User Agent instance's contact-address and the
configured q-value.
The IMS core registrar will dynamically store, for the registered ISDN PRA user
(PBX), the contact-address and q-value as received by their SIP register requests
that originated from the different SIP User Agent instances.
One GDN-ext is to be configured for the entire E1 Cluster). In case the E1 cluster
consists of multiple Virtual E1 Groups, the same GDN-ext must be configured for all
ISDN PRA SIP terminations (Virtual E1 Groups.)
The registration mode of an E1 cluster can be configured as 'implict' or 'explicit'. (The
latter registration mode applies only applicable to 100/320 Gbps NT and FX NT)
The same registration mode must be configured for all Virtual E1 Groups of an E1
cluster.
In case the explicit registration mode applies, it is mandatory to configure a DDI-EXT
list (only applicable to 100/320 Gbps NT and FX NT).

NT
The amount of DDI-EXTs that can be configured for an ISDN PRA user (PBX) is not
fixed. The only limitation is the overall maximum number of DDI-ext entries (for all E1
clusters together) that can be configure, that is 45K DDI-exts.(only applicable to
100/320 Gbps NT and FX NT)
For the use case whereby the E1 interfaces of an E1 cluster are connected to
different ISDN PRA voice LT boards (multiple Virtual E1 Groups), each of the SIP
User Agent instances must register the GDN-ext and the entire DDI-EXT list to the
IMS core.(The configuration of the DDI-EXT list is only applicable to 100/320 Gbps
NT and FX NT)
The NOKIA MSAN cabinet supports ISDN PRA PBXs with a maximum of 10 K
subscribers.
The following E1 interface hunting methods (the method by which an E1 interface is
selected within a Virtual E1 Group upon the receipt of an incoming call attempt) are
supported:
• E1 interface sequential hunting:
Selection of a candidate E1 interface always starts with the same E1 interface and
then follows a fixed order until all E1 interfaces in the E1 cluster have been
searched or a candidate E1 interface is found:
• Forward: fixed order is from low to high (sequential_forward_fl)
• Reverse: fixed order is from high to low (sequential_reverse_fl)
• Fully Loaded: The next E1 interface in the ordered series of E1 interfaces is selected
if all B-channels of the one used last are busy.
• E1 interface cyclic hunting:
Selection of a candidate E1 interface always starts at the next in the ordered
series of E1 interfaces following the one used last, and follows a fixed order. When
the first/last E1 interface in the E1 cluster is reached, the search continues from
the end/beginning of the E1 cluster until all E1 interfaces in the E1 Cluster have
been searched:
• Forward: fixed order is from low to high (cyclic_forward)
• Reverse: fixed order is from high to low (cyclic_reverse)
• E1 interface random hunting:
Selection of a candidate E1 interface from across the entire search space (the E1
cluster) using a uniform probability distribution. Each future selected E1 interface
is independent of the selected E1 interfaces that come before it in that same E1
cluster.
In case the randomly selected E1 interface cannot handle the call, the selection
of a new candidate E1 interface starts at the next in the ordered series of E1
interfaces following the one being randomly selected, and follows a fixed order.
When the first/last E1 interface in the E1 cluster is reached, the search continues
from the end/beginning of the E1 cluster until all E1 interfaces in the E1 Cluster
have been searched.
• Forward: fixed order is from low to high (random_forward)
• Reverse: fixed order is from high to low (random_reverse)
The same E1 interface selection mechanism applies to all Virtual E1 Groups of an
E1 Cluster.

NT
The following B-channel hunting method (the method by which a B-channel is

selected within an E1 interface upon the receipt of an incoming call attempt) are
supported:
• B channel sequential hunting:
Selection of a free B-channel always starts with the same B-channel and then
follows a fixed order until all B-channels in the E1 interface have been searched
or a free B-channel is found:
• Forward: fixed order is from low to high (sequential_forward)
• Reverse: fixed order is from high to low (sequential_reverse)
• B channel cyclic hunting:
Selection of a free B-channel always starts at the next in the ordered series of
B-channels following the one used last, and follows a fixed order. When the
first/last B-channel in the E1 interface is reached, the search continues from the
end/beginning of the E1 interface (last/first B-channel) until all B-channels in the
E1 interface have been searched.:
• Forward: fixed order is from low to high (cyclic_forward)
• Reverse: fixed order is from high to low (cyclic_reverse)
• B channel random hunting:
Selection of a B-channel from across the entire search space (the E1 interface)
using a uniform probability distribution. Each future selected B-channel is
independent of the selected B-channels that come before it in that same E1
interface.
If the randomly selected B-channel is busy, the selection of a new candidate
B-channel starts at the next in the ordered series of B-channels following the one
been randomly selected, and follows a fixed order.
When the first/last B-channel in the E1 interface is reached, the search continues
from the end/beginning of the E1 interface until all B-channels in the E1 interface
have been searched.
• Forward: fixed order is from low to high (random_forward)
• Reverse: fixed order is from high to low (random_reverse)
The same B-channel hunting method applies to all E1 interfaces of the E1 Cluster.
All users behind the ISDN PRA SIP termination share the same set of services.
The MSAN supports ISDN PRI PBXs that own the partial numbering property.
14.5.3 Transport Protocols

The UDP and TCP transport protocols are supported as underlying transport protocol
for SIP

NT
The MSAN supports the following TCP transport protocol strategy:

• Support of the "Two Persistent TCP connections" strategy meaning that two
persistent TCP connections are established between a MSAN SIP UA instance
and its peer first hop SIP server whereby a persistent TCP connection is
established in each direction.
• A persistent connection being established between two SIP peers may be closed
at any time by either peer when the peer-defined conditions are met.
• In order to have two persistent connections, the first hop SIP server must support
this approach too. However, should a first hop SIP server not follow this approach,
but for example implements a per-dialog connection approach, then more than
two connections will be active between the MSAN SIP UA and the first hop SIP
server.
• A SIP request and the associated response must be sent over the same TCP
connection.
• Under error conditions, the peer side may attempt to open a new TCP connection
to send the response.
• When the MSAN wants to send a response and the TCP connection on which the
request was received is no longer existing, it will open a new TCP connection to
the source IP address and port of the corresponding request.
• Support of concurrent "TCP peering" relationships with different first hop SIP
servers in order to support first hop SIP server redundancy.
• A persistent TCP connection is still maintained for a period equal to the
configurable TCP connection maximum idle time, after the last message was sent
or received over that TCP connection.
• An established TCP connection is closed:
• upon the expiry of the configurable TCP connection maximum idle time.
• upon TCP connection failure.
• Confirmed dialogs, that is calls in conversation state, are not released upon a
failure of the persistent TCP connection along which these dialogs were
established.
• Keeping the various SIP layers independent from each other, a failure of a
persistent TCP connection is not notified to the application layer. Such failure
results in User Agent layer as well as Transaction layer time-outs that are reported
as SIP request transmission failures to the application layer.
• In case of the distributed IP address policy, the tcp-listen-to port is configurable;
the TCP source port is autonomously allocated by the MSAN SIP UA.
• In case of the centralized IP address policy, both the tcp-listen-to port and the tcp
source port are autonomously allocated by the MSAN SIP UA.
• Also, if the size of a SIP request with UDP as underlying transport protocol
exceeds a configurable maximum UDP packet size threshold, the transport
protocol is switched from UDP to TCP.

NT
14.5.4 Management Interface

The Management interface is supported by means of CLI and SNMP.
Up to 144 ISDN PRA terminations can be created per MSAN.
The MSAN allows to configure an ISDN PRA SIP termination, with the following, for
this feature most relevant, attributes:
• the list of E1 interfaces associated with the ISDN PRA SIP termination,
• the E1 interface hunting method,
• the B channel hunting method,
• the register method: 'implicit' or 'explicit' (the 'explicit' register mode is applicable
to the 100/320 Gbps NT and FX NT only.),
• the q-value,
• the GDN-EXT together with the associated SIP User Name, SIP URI, SIP Display
Name, Authentication parameters,
• the list of DDI-EXTs associated with the ISDN PRA SIP termination (mandatory in
case the 'explicit' register method applies) together with the SIP User Name, SIP
URI, SIP Display Name and Authentication parameters,
• an operator friendly name for the E1 cluster / Virtual E1 Group.
• the admin state (common to GDN-EXT and DDI-EXTs)
• the rule set that applies to the ISDN PRA SIP termination.
The MSAN allows to configure ISDN PRA Termination Line Identifier Profile:
pra/Channel/Port/Slot/Frame/Rack/Access_Node_ID
Where:
• <pra> is a fix ed prefix
• <channel> uniquely identifies each of the ISDN-PRA B channels,
• <Port> uniquely identifies the port at the ISDN PRA voice LT board
• <Slot> uniquely identifies the slot id of the ISDN PRA voice LT board
• <Frame> uniquely identifies the shelf in which the ISDN PRA voice LT board is
equipped
• <Rack> uniquely identifies the rack in which the shelf is equipped
• <Access_Node_ID> uniquely identifies the node
The MSAN allows to display the SIP User Contact Info (The SIP Line Id Syntax
Pattern cannot be configured as 'PhysicalLineId' when the ISDN PRA SIP
termination is configured on top of multiple E1 interfaces) as well as, at any moment
in time, the number of B-Channels that are in use or in idle state for a ISDN PRA
termination (Number of B-channels depends on the number of E1 interfaces that are
associated with the ISDN PRI SIP termination).

NT
The MSAN supports the following termination related alarms:

• AIS (Alarm Indication Signal) (Ref. ITU-T I.431).
• RAI (Remote Alarm Indication) (Ref. ITU-T I.431).
• LOS (Loss Of Signal) (Ref. ITU-T I.431).
• E1 SIP termination Sip Reg failure, reason: Resolve domain name
• E1 SIP termination Sip Reg failure, reason: Authentication failure
• E1 SIP termination Sip Reg failure, reason: Register timeout
• E1 SIP termination Sip Reg failure, reason: Failure response from sip server
• E1 SIP termination Sip Inv failure, reason: Invalid domain name
• E1 SIP termination Sip Inv failure, reason: Authentication failure
• E1 SIP termination Sip Inv failure, reason: Invite timeout
• E1 SIP termination Sip Inv failure, reason: Failure resp from sip server
• E1 SIP termination Emergency call ongoing
In case of explicit registration, the register failure alarms can be raised for the
GDN-EXT as well as for the DDI-EXTs.

• MD5.
RFC 3310.
14.5.6 Implicit Registration (Direct Dial In service and No

Direct Dial In Service)
The registration of an ISDN PRA SIP termination happens by the on-board SIP UA
instance. The SIP UA instances at the different ISDN PRA voice LT boards perform
the registration of their locally configured ISDN PRA terminations simultaneously.

NT
An ISDN PRA SIP termination can be configured on top of a single E1 interface or

on top of multiple (max 8) E1 interfaces. All E1 interfaces associated with an ISDN
PRA SIP termination must terminate a the same ISDN PRA voice LT board.
The MSAN supports IMPLICIT registration for the AOR configured in the ISDN PRA
SIP termination entry regardless of whether DDI or no-DDI is to be applied (In
compliance with RFC 5947).
For both DDI and Non-DDI, only the GDN-EXT must be explicitly configured
Scenario 1 (no DDI):
• One AOR to be registered for an ISDN PRA SIP termination.
All phones behind the ISDN PRA SIP termination share the same external
directory number. For an incoming call, the PBX performs the final selection of the
phone extension to answer.
Scenario 2 (DDI):
• Multiple AORs to be registered for an ISDN PRA SIP termination supporting DDII,
that is enabling a subscriber to directly call another subscriber on an integrated
services private branch exchange or other private system without attendant
intervention.
The MSAN generates a SIP REGISTER request using a mutually agreed GDN-EXT
(typically based on the PBX's main attendant-/reception-desk number). The
GDN-EXT is often in the domain of the Service Provider, and both the To and From
URIs used for the REGISTER request identify that GDN-EXT. In all respects, it
appears on the wire as a "normal" SIP REGISTER request, however, it implicitly
registers all DDI-EXTs associated with the PBX.
The 200 OK response to the REGISTER request, sent after a successful
authentication challenge, contains one or multiple P-Associated-URI (PAU)
[RFC3455] header fields listing the other SIP URIs or TEL URIs (that is phone
numbers) of the PBX, which are the implicitly registered DDI-EXTs.
The registered DDI-EXTs are in the P-associated-URI via exhaustive list or using a
wildcard.
As the MSAN SIP stack limits the maximum number of header fields in a SIP
message, the exhaustive list of implicitly registered DDI-EXts that can be contained
in a REGISTER response is limited. (Regardless of the implicitly registered
DDI-EXTs returned in different P-Associated-URI header fields or returned as
different values in a single P-Associated-URI header field, each implicitly registered
DDI-EXT is counted as a separate header field).
The MSAN SIP supports up to 80 implicitly registered DDI-EXTs that can be returned
in the REGISTER response. If the number of implicitly registered DDI-EXTs would
exceed 80, it is suggested to use the wildcard instead of using exhaustive list.
A "wildcard" syntax model is defined [3GPP.23.003], that uses a regular expression
syntax in the user field of the URI to express multiple DDI-EXTs in a compressed
manner.

NT
The registered reachability information from the REGISTER request will be used to
reach not only the single explicitly registered GDN_EXT but also each of the implicitly
registered DDI-EXTs.
If there is more than one sip phone extension contained in the P-Associated-URI
header (explicit list of implicit registered DDI-EXTs or wildcard ), then the ISDN PRA
SIP termination will be treated with DDI enabled.
If there is only one phone extension found in the P-Associated-URI header or even
no P-Associated-URI header, the ISDN PRA SIP termination will be treated with DDI
disabled.
The MSAN allows to display DDI-EXTs returned in the 200 OK response to the
Register request. The DDI-EXTs are displayed with the same format as returned in
the P-Associated URI header.
The entire SIP Registration method is in compliance with RFC3261 and RFC5947.
The ISDN Layer1/Layer2 status does not have an influence on the ISDN PRA SIP
termination register status. The ISDN PRA SIP register status can be "up" even if the
ISDN layer1 status is inactive.
14.5.7 Explicit Registration

Supported for the 100/320 Gbps NT and FX NT only.
The registration of a ISDN PRA SIP termination happens by the on-board SIP UA
instance. The SIP UA instances at the different ISDN PRA voice LT boards perform
the registration of their locally configured ISDN PRA terminations simultaneously.
An ISDN SIP PRA termination can be configured on top of a single E1 interface or
on top of multiple (maximum eight) E1 interfaces. All E1 interfaces associated with
an ISDN PRA SIP termination must terminate on the same ISDN PRA voice LT
board.
The MSAN supports EXPLICIT registration for an ISDN PRA SIP Termination. In
such case, the MSAN generates a SIP REGISTER request for the GDN-EXT and for
each of the DDI-EXTs that are configured and associated with the ISDN PRA SIP
termination.
The DDI-EXTs cannot be configured by means of the wildcard approach,
The MSAN allows to display the individual register / operational status for all, the
GDN-EXT and each of the DDI-EXTs.
ISDN PRA SIP terminations are registered in the order that the SIP terminations
become administratively enabled.
The ISDN Layer1/layer2 status does not have an influence on the ISDN PRA SIP
termination register status. The ISDN PRA SIP register status can be "up", even if
the ISDN layer1 status is inactive.

NT
14.5.8 Dialing Mode

The MSAN supports:
• Enbloc dialing: one SETUP message received from the subscriber side (all
required address info is contained in the SETUP message) results in one SIP
INVITE request sent to the network side (SIP IMS core).
• The MSAN determines that the SETUP message contains all the information
requireall attempt.
• The MSAN sends a CALL PROCEEDING message to the subscriber side. This
acknowledges the SETUP message and indicates that the outgoing call attempt is
being processed.
• The MSAN sends a SIP INVITE request to the SIP IMS core.
• Overlap dialing: one SETUP message plus one/multiple INFO messages
received from the subscriber side result in one SIP INVITE request sent to the
network side (SIP IMS core)
• The SETUP message does not include all required address info; one or multiple
INFO messages need to be awaited/received from the subscriber side, carrying the
remaining address info.
• The MSAN converts the content of the SETUP message together with the content
of one or more INFO messages to a single SIP INVITE message if one of the
following conditions is fulfilled:
* The receipt of a sending complete indication from the subscriber side, or
* The outcome of the MSAN analysis indicates that all information necessary to make
an outgoing call attempt has been received.
• The MSAN sends a CALL PROCEEDING message to the subscriber side. This
acknowledges the SETUP message and indicates that the outgoing call attempt is
being processed.
• The MSAN sends a SIP INVITE request to the SIP IMS core.
14.5.9 Digit Analysis

The Digitmap is provisioned at the MSAN.
By means of digit analysis, the MSAN:
• checks whether the collected digits (Received via SETUP and INFO packets)
match a pattern in the configured Digitmap: when digits are collected from the
SETUP/INFO messages, all collected digits are compared with the Digitmap. If
one pattern is matched, a SIP INVITE request is sent out in compliance with TS
183 036.
• checks whether the SENDING COMPLETE indicator has been received: the
SENDING COMPLETE indicator may be present as Sending Complete
Information Element or together with the digits in the Called Party Number

NT
Information Element. Upon the receipt of the SENDING COMPLETE indicator, the
MSAN sends the CALL PROCEEDING message to the user and stops collecting
digits.
Note — Emergency calls are handled as normal basic calls: In

case a SIP ISDN PRA termination cannot successfully register,
the E1 interface will not be powered-on meaning that no Q931
message can be recived from the subscriber.
14.5.10 Number Screening and Mapping.

The number screening and mapping procedure has a limited scope.
For ISDN-PRI PBX's which provide a "partial" calling party number (that is, the PBX
just provides the digits specific to the Direct-Dialling-In service), the MSAN supports
the configuration of a digit manipulation rule which allows to complement the
received "partial" calling party number with the missing prefix of the default PBX
number (GDN) as to become a "complete" E.164 telephone number.
Should such rule not be configured upon the receipt of an originating call attempt
including a partial CgPn, the MSAN considers the received partial number (the
received digits in CgPn IE) as an invalid DN and replaces the received digits in CgPN
IE by the configured global default number (GDN) of the PBX before to proceed with
the call set-up.
In case such digit manipulation rule is configured for the ISDN PRI PBX with partial
number property and the CgPnLength parameter is set to the length of the partial
number (usually the number of received digits in CgPn IE equals 3 or 4), then upon
the receipt of an originating call attempt, the MSAN will derive the missing digits (that
must precede the digits received in the CgPn IE in order to shape a "complete" E164
telephone number) from the configured default PBX number (GDN) and add the
missing digits to the received CgPn IE content. This completed E164 telephone
number is then used during the further proceeding of the call set-up.
14.5.11 Basic Call (Originating and Terminating).

To support the ISDN PRA basic call, all the signaling messages / parameters
received on the ISDN PRA-UNI interface, are converted into corresponding SIP
messages / parameters and sent on the SIP (Gm) interface towards P-CSCF and
vice versa.
The Q.931 recommendation specifies the procedures for the establishing,
maintaining and clearing of network connections at the ISDN user-network interface.
These procedures are defined in terms of messages exchanged over the D-channel
of (basic and) primary rate interface structures. The functions and procedures of this
protocol, and the relationship with other layers, are described in general terms in
recommendation Q.930/I.450.

NT
The interworking requirements for the basic call service are specified in TS 183 036.
14.5.11.1 Codecs
The MSAN supports the following codecs for the basic call:
• G.711 A/u law (10ms, 20ms, 30ms packetization length), including support for
• Packet Loss Concealment (PLC)
• Support of Silence suppression by using Voice Activity Detection (VAD) and Comfort
Noise Generation (CNG).
• G.729AB (10ms, 20ms, 30ms, 40ms, 50ms, 60ms packetization length)
• G.723.1 (5.3kbps, 6.3kbs, with 30ms packetization length)
14.5.11.2 Echo Cancellation.

The MSAN supports G.168/G.165 echo cancellation with an echo tail length from 8
ms upto 128 ms.
14.5.11.3 Adaptive Jitter Buffer

The MSAN supports a configurable jitter buffer up to 135ms.
14.5.11.4 Fax and Modem

The MSAN supports the following features:
• Incoming/Outgoing fax with G.711 VBD or T.38
• sending 488 to fallback to VBD when lack of T.38 resources.
• Voice Band data modem and fax modem operation by using

NT
call; in compliance to GR-909 Sec. 5.2.1.5.3, R5-17.
periodic phase reversals); in compliancy to GR-909 Sec. 5.2.1.3, R5-10.
• CNG detection upon the receipt of a 1100 Hz tone [0.5 sec. ON; 3 sec. OFF] in
compliancy to T.30.
detected.
• Fax: V.21, V.17, V.27 ter, V.29, V.34 compliance.
• Modem (or textphone): V.18, V.21, V.22, V.22bis, V.23, V.32, V.32bis, V.32ext,
• Configurable T.38 Error Correction Mode (ECM): enable / disabled.
#27).
* Put the channel in ECM mode (set the ECM bit #27)
* When the parameter T38_ECM_Ptime is set to 0, the T.38 channel will transmit the
T.4 ECM packet as one packet.
* when the parameter T38_ECM_Ptime is set to a value <> 0, then the system
14.5.12 Supplementary Services.

Some supplementary services are fully transparent to the MSAN which means that
the logic behind the supplementary service is transparent to the MSAN (The
supplementary service logic is fully handled by the PBX; for some of the
supplementary services like 3PTY, ECT, CW and CH, from a MSAN point of view,
this may result in just a new call to be established ). Nevertheless, the MSAN is still
responsible to do the translation from the received Q.932 message to a SIP message
to be sent to the network side (and vice versa).
The following table lists the supplementary services that are supported by the MSAN:

NT
Service Description
DDI Direct Dialling In
CLIP Calling Line Identification Presentation
CLIR Calling Line Identification Restriction
CLIRO Calling Line Identification Restriction Override
CW Call Waiting
CH Call Hold
CR Call retrieve
MCID Malicious Call Identification
CFU Call Forward Unconditional
CFB Call Forward on Busy
CFNR Call Forward on No Reply
ECT Explicit Call transfer
NP Number Portability
3PTY 3 Party Call
OCB Outgoing Call Barring
C(P)S Carrier (Pre) Selection
ACB-OOS Administratice Call Barring - Out Of Service
The following services are fully transparent for the ISAM access node:
• Outgoing call Barring
• Three Party Call
• Number Portability
• Call Waiting
14.5.13 PANI header

PANI Header insertion is done in compliancy to the 3GPP TS24.229 standard:
• Initial REGSITER / User initiated reregistration / User initiated deregistration: if
available to the UE (as defined in the access technology specific annexes for each
access technology), a P-Access-Network-Info header field set as specified for the
access network technology (see subclause 7.2A.4)
• UE-originating case: If available to the UE (as defined in the access technology
specific annexes for each access technology), the UE shall insert a
P-Access-Network-Info header field into any request for a dialog, any subsequent

NT
request (except ACK requests and CANCEL requests) or response (except

CANCEL responses) within a dialog or any request for a standalone method (see
subclause 7.2A.4).
• UE-terminating case: If available to the UE (as defined in the access technology
P-Access-Network-Info header field into any response to a request for a dialog,
any subsequent request (except CANCEL requests) or response (except
CANCEL responses) within a dialog or any response to a standalone method (see
subclause 7.2A.4).
Thus: PANI-header not included ACK, (response to) CANCEL, 100 Trying,
(response to) session refresh request.
• Format 1:
• Format = P-Access-Network-Info: ADSL; dsl-location="quoted string”
• The PANI header (dsl-location) is based on part of the ISAM System Id and used by
the IMS core to identify the originating access device of a SIP request.
• Format 2:
• The PANI header (dsl-location) is based on part of the ISAM Termination Line Id.
Authentication by the IMS core is based on IMPU (=RN) (From) & Access-Id (PANI
Line-Id)
• Format 3:
"line-id=<MSAN-SIP-IP>;cc=39;oc=204;lac=<MSAN-LAC>;ali=;";network-provided

Notify) message.

NT
14.6 SIP Integrated Voice Service - CAS R2

Figure 186 SIP Integrated Voice Service CAS R2
14.6.1 General
The MSAN supports eight E1 CAS R2 interfaces at a CAS R2 voice LT board.
The CAS R2 voice LT board behaves as "stand-alone" meaning that the E1 loop is
directly connected to the end-user.
The CAS R2 protocols are terminated at the voice LT board. See Figure 187.

NT
Figure 187 SIP Integrated Voice Service CAS R2 protocols

9RLFH/7ERDUG
3%; 5VLSLQWHUZRUNLQJIXQFWLRQ 3&6&)
6,3 6,3
&$65 &$65 8'3 8'3
,3 ,3
T T
, ,

A PBX can be connected to only one E1 port (and vice versa).

Configurable PBX types:
• ‘Normal' type: the PBX supports all, the group A and group B signals. The ISAM
node can send B-4 or other group B signals to the PBX upon the receipt of a 4xx
from the SIP Server during outgoing call attempt.
• ‘Compelled_A3_and_B1' type: the PBX supports only the B-1 signal. Should any
other B-x signals be sent, then these will be ignored by the PBX. The ISAM node
sends compelled A-3 after DML analysis has completed. Upon the receipt of 4xx,
only the B-1 signal is sent to the PBX followed by playing busy or congestion tone,
depending on the reason header field in the final response. It is then expected that
the subscriber cancels the call when hearing the busy/congestion tone.
• ‘Pulsed_A3_and_B1' type: the PBX supports only the B-1 signal. The ISAM node
sends pulsed A-3 after DML analysis has completed. The ISAM node can only
send B-1 and play busy/congestion tone too. Upon the receipt of 4xx, only the B-1
signal is sent to the PBX followed by playing busy or congestion tone, depending
on the reason header field in the final response. It is then expected that the
subscriber cancels the call when hearing the busy/congestion tone.
One CAS R2 termination per E1 port (E1 loop). All users behind the CAS R2
termination share the same set of services.
There can be only one signaling entity present at the E1 port.
Supported features:
• Implicit SIP registration
• Basic Call (Originating & Terminating)
• En-bloc dialing
• Direct Dialing In (DDI)
• Codecs : G.711, G729/G.723.
• Play Ring-Back Tone
• Play Busy Tone

NT
• Configurable backward clear call tone:

For PBXs that only support the B-1 signal, when to clear a call in backward
direction, the CLEAR BACK line signal cannot be sent because the signal will be
recognized as SEIZURE ACK signal in seizure ack state.
Therefore the busy or congestion tone is to be played and the caller onhook state
to be awaited.
Supported tone types:
• Busy tone: play busy tone as defined in the CDE profile when to clear a call in seizure
ack state.
• Congestion tone: play congestion tone as defined in the CDE profile when to clear a
call in seizure ack state.
• VBD Fax/Modem:
• VBD Mode (usual CLI/SNMP management interface configurable):
* Autoswitch:
Use default codec without negotiation.
No SDP offer will be sent for neither Voice to VBD or VBD to Voice. Should a specific
trigger tone be received, the ISAM node will switch this R2 termination to VBD mode.
The ISAM node switches to VBD mode when any fax/modem tone defined in
RFC4734 is detected from local/remote side with G.711a or G.711u/ remote side
with RFC2833/RFC4733.
* No support for renegotiation, v152fb-autoswitch and v152fb-reneg.
• Fax/modem mode (CDE profile pre-provisionable)
* Audio:
No fax/modem 2833 payload type will be included in SDP offer and answer
fax/modem events. If the SDP negotiation results indicate no support for fax/modem
events, the ISAM node will send fax/modem tones via audio.
* mandatory-audio:
No fax/modem 2833 payload type will be included in ISAM SDP offer and answer.
The ISAM node will always send fax/modem tones by audio.
• VBB bulk call
• DTMF (Configurable options):
• Audio:
No 2833 payload type will be included in SDP offer. If 2833 payload negotiation result
does not support rfc2833, the access device will send DTMF and telephone event
tones by audio.
If 2833 payload negotiation result supports rfc2833, the access device will send
DTMF and telephone event tones both by audio and 2833.
• Rfc2833:
Configured 2833 payload type value will be included in SDP offer. If 2833 payload
negotiation result does not support rfc2833, the access device will not send DTMF
and telephone event tones by 2833.
If 2833 payload negotiation result supports rfc2833, the ISAM node will send DTMF
and telephone event tones by 2833.
• Both:
Configured 2833 payload type value will be included in SDP offer. If 2833 payload
negotiation result does not support rfc2833, the access device will not send DTMF
and telephone event tones by both audio and 2833.
If 2833 payload negotiation result supports rfc2833, the access device will send
DTMF and telephone event tones both by audio and 2833.
• Mandatory-audio:

NT
No 2833 payload type will be included in SDP offer and answer. Always send DTMF
and telephone event tones by audio.
14.6.2 Management Interface

The Management interface is supported by means of CLI and SNMP.
Up to 144 CAS R2 terminations can be created per MSAN.
The MSAN allows to configure:
• the GDN (The GDN is used for implicit registration),
• the digit map,
• the PUID ("Public User Identity"; both TEL URI and SIP URI are supported),
• the SIP User Name,
• the SIP URI,
• the SIP Display Name,
• the DS0 channel hunting method (for incoming calls only)
• Cyclical - channels are allocated cyclically. The preference is for the allocation of the
subsequent idle channel in a cyclical manner.
• Increasing - Channel assignment according to increasing channel numbers. The
preference is for the allocation of the idle channel with the lowest number.
• Decreasing - Channel assignment according to decreasing channel numbers. The
preference is for the allocation of the idle channel with the highest number.
• Random - Channel assignment at random
• the admin state,
• the PANI header line ID,
• the applicable rule set,
• the remote clear tone type (busy tone, congestion tone)
• the exchange (PBX or Public) type,
• the calling party category (CPC),
• the AKA/MD5 authentication for the ISDN PRA termination.
• to enable/disable the ACC restriction,
• to enable/disable the calling party number (CPN) screening.
• the applicable rule set,
• and the AKA/MD5 authentication for the ISDN PRA termination.
The MSAN allows to configure CAS R2 Termination Line Identifier Profile:

r2/Channel/Port/Slot/Frame/Rack/Access_Node_ID
Where:
• <r2> is a fix ed prefix
• <channel> uniquely identifies each of the B channels,
• <Port> uniquely identifies the port at the CAS R2 voice LT board

NT
• <Slot> uniquely identifies the slot id of the CAS R2 voice LT board

• <Frame> uniquely identifies the shelf in which the CAS R2 voice LT board is
equipped
• <Rack> uniquely identifies the rack in which the shelf is equipped
• <Access_Node_ID> uniquely identifies the node
The MSAN supports the following termination related alarms:
• AIS (Alarm Indication Signal) (Ref. ITU-T I.431).
• RAI (Remote Alarm Indication) (Ref. ITU-T I.431).
• LOS (Loss Of Signal) (Ref. ITU-T I.431).
• E1 SIP termination Sip Reg failure, reason: Resolve domain name
• E1 SIP termination Sip Reg failure, reason: Authentication failure
• E1 SIP termination Sip Reg failure, reason: Register timeout
• E1 SIP termination Sip Reg failure, reason: Failure response from sip server
• E1 SIP termination Sip Inv failure, reason: Invalid domain name
• E1 SIP termination Sip Inv failure, reason: Authentication failure
• E1 SIP termination Sip Inv failure, reason: Invite timeout
• E1 SIP termination Sip Inv failure, reason: Failure resp from sip server
• E1 SIP termination Emergency call ongoing
The MSAN supports the following channel related alarms:

• Channel blocked, fail in the reception of SEIZURE ACK signal: This is an alarm to
inform that a given channel was blocked due to failure in the reception of the
SEIZURE ACK signal.
• Channel blocked, fail in the reception of DISCONNECTION ACK signal: This is an
alarm to inform that a given channel was blocked due to failure in the reception of
the DISCONNECTION ACK signal.
• Channel blocked, fail in the reception of FORCED RELEASE ACK signal: This is
an alarm to inform that a given channel was blocked due to failure in the reception
of the FORCED RELEASE ACK signal.

NT

• MD5.
RFC 3310.
14.6.4 Registration (Direct Dial In service and No Direct

Dial In Service)
The registration of SIP CAS R2 terminations happens by all SIP UA instances (for
different CAS R2 voice LT boards simultaneously.
The MSAN supports IMPLICIT registration for the AOR configured in the SIP CAS
R2 Termination entry regardless of whether DDI or no-DDI is to be applied (In
compliance with RFC 5947).
Scenario 1 (no DDI):
• One AOR to be registered for a SIP CAS R2 termination (E1 interface). All phones
behind the E1 interface share the same external directory number. For an
incoming call, the PBX performs the final selection of the phone to answer.
Scenario 2 (DDI):
• Multiple AORs to be registered for a SIP CAS R2 termination (E1 interface)
supporting DD, that is, enabling a subscriber to directly call another subscriber on
an integrated services private branch exchange or other private system without
attendant intervention.
The MSAN generates a SIP REGISTER request using a mutually agreed SIP AOR
(typically based on the PBX's main attendant-/reception-desk number). The AOR is
often in the domain of the Service Provider and both the To and From URIs used for
the REGISTER request identify that AOR. In all respects, it appears on the wire as a
"normal" SIP REGISTER request, however, it generally implicitly registers other
AORs associated with the PBX.

NT
The 200 OK response to the REGISTER request, sent after a successful

authentication challenge, contains one or multiple P-Associated-URI (PAU)
[RFC3455] header fields listing the other SIP URIs or TEL URIs (that is phone
numbers) of the PBX, which are implicitly registered AORs.
The registered PUID are in the P-associated-URI via exhaustive list or using
wildcards.
As the MSAN SIP stack limits the maximum number of header fields in a SIP
message, the exhaustive list of implicitly registered AORs that can be contained in a
REGISTER response is limited. (Regardless of the implicitly registered AORs
returned in different P-Associated-URI header fields or returned as different values
in a single P-Associated-URI header fields, each implicitly registered AOR is counted
as a separate header field).
The MSAN SIP supports up to 80 implicitly registered AORs that can be returned in
the REGISTER response. If the number of implicitly registered AORs would exceed
80, it is suggested to use the wildcard AOR(s) instead of using an exhaustive list.
A "wildcard" syntax model is defined [3GPP.23.003], which uses a regular
expression syntax in the user field of the URI to express multiple AORs in a
compressed manner.
reach not only the single explicitly registered AOR but also each of the implicitly
registered AORs.
If there is more than one SIP AOR contained in the P-Associated-URI header
(explicit list of implicit registered AORs or wildcard AOR(s)), the SIP CAS R2
termination will be treated with DDI enabled.
If there is only one AOR found in the P-Associated-URI header or even no
P-Associated-URI header, the SIP CAS R2 termination will be treated with DDI
disabled.
For both DDI and Non-DDI, only one PUID / GDN / AOR must be explicitly
configured.
The MSAN allows to display PUIDs returned in the 200 OK response to the
REGISTER request. The PUIDs are displayed with the same format as returned in
the P-Associated -URI header.
reach not only the single explicitly registered AOR but also each of the implicitly
registered AORs.
SIP CAS R2 terminations are registered in the order that the SIP terminations
become administratively enabled.
In case a SIP CAS R2 termination fails to successfully register, the E1 interface is
not powered-on.

NT
Contact URI formats:

• Physical line id format: r2/Channel/Port/Slot/Frame/Rack/Access_Node_ID
@IP-Address:IP-Port whereby 'Channel' is always "0" because 'Channel' only
makes sense inside the node. There is only one contact per E1 interface.
• Termination URI format: the termination URI is included in the contact header.
14.6.5 SIP Invite

Support is provided for:
• Invite with SDP offer (200 OK with SDP answer)
• Invite without SDP without "Supported:100rel"/ "Requre:100rel" (200 OK - ACK
SDP offer-answer model to perform SDP negotiation)
• Invite without SDP but with "Requre:100rel" (180 with "Require:100rel" sent - use
180-PRACK to perform SDP negotiation.
• Invite without sdp but with "Supported:100rel":
• If PRACK-100rel-For18x is enabled in the SIP Service Profile: 180 with
"Require:100rel" is sent and 180-PRACK is used to perform SDP negotiation.
• If PRACK-100rel-For18x is disabled, 180 with "Supported:100rel" is sent.
200OK-ACK offer-answer model is used to perform SDP negotiation.
The relationship regarding "Supported:100rel", "Require:100rel" and

“pre-provisionable SIP Service Profile parameter” is summarized for "invite without
SDP" in Table 47
Table 47 Relationship for Invite without SDP
Invite PRACK100relFor18x 18x 100rel SDP negotiation

(SSP parameter)
No 100rel Yes / No No 100rel 200OK-ACK
Supported: 100rel No Supported: 100rel 200OK-ACK
Supported: 100rel Yes Require: 100rel 180-PRACK
Require: 100rel Yes / No Require: 100rel 180-PRACK
14.6.6 Dialing Mode

The MSAN supports 'Enbloc dialing' only:
• Digit map is required in the MSAN in order to know when to start the signaling
exchange in the SIP side.
• Dialed digits length will be defined based on the leading digits, allowing the MSAN
to decide when the complete called party number has been received.

NT
After receiving the complete R2 signaling information from the originating R2 peer,
that is the Calling Party Number, Calling Party's Category and Called Party Number,
the ISAMV shall send an INVITE.
14.6.7 Basic Call (Originating and Terminating).

To support the CAS R2 basic call, all the signaling messages / parameters received
at the E1 interface, are converted into corresponding SIP messages / parameters
and sent on the SIP (Gm) interface towards P-CSCF and vice versa.
14.6.7.1 Supported R2 Line Signals

The R2 line signals that are applicable to a customer's deployment are
pre-provisionable in the CDE Profile.
Table 48 supported R2 line signals
Call phase Signal Signal direction Signalling channels Remarks

designation
af bf ab bb
Trunk idle - - 1 0 1 0 -
Trunk seizure Seizure signal Forward 0 0 1 0 -

Seizure Backward 0 0 1 1 -
acknowledgement
signal
Call establishment - - 0 0 1 1 -
in progress
Call answering Answer signal Backward 0 0 0 1 -
Call established - - 0 0 0 1 -
Call established Charge signal Backward 0 0 1 1 Pulse of (150 +/- 30ms) in the
charging bit ab that goes from "0' to "1"
Call disconnection Backward Backward 0 0 1 1 -

in progress disconnection
signal
Forward Forward 1 0 X 1 x=0 A disconnects first

disconnection x=1 B disconnects first
signal
Disconnection Backward 1 0 1 0 -
acknowledgement
signal
Forced release Backward 0 0 0 0 -

signal
(1 of 2)

NT
Call phase Signal Signal direction Signalling channels Remarks

designation
af bf ab bb
Special situations Forced release Forward 1 0 0 0 -
acknowlegdgment
signal
Blocking signal Backward 1 0 1 1 -
Fail signal Forward 1 1 1 0 -
Unblocking signal Backward 1 0 1 0 -
(2 of 2)
14.6.7.2 Supported R2 Interregister Signals (Forward)

The Forward R2 interregister signals that are applicable to a customer's deployment
are pre-provisionable in the CDE Profile.
Use-case 1:
Table 49 Supported R2 Interregister Signals (Forward, use-case 1)
Signal Forward Signal
Group I Group II
1 DIGIT 1 REGULAR SUBSCRIBER

2 DIGIT 2 SUBSCRIBER WITH SPECIAL
CHARGING
3 DIGIT 3 MAINTENANCE EQUIPMENT
4 DIGIT 4 LOCAL PAY PHONE

5 DIGIT 5 OPERATOR
6 DIGIT 6 DATA COMMUNICATION

EQUIPMENT
7 DIGIT 7 TOLL PAY PHONE
8 DIGIT 8 COLLECT CALL
9 DIGIT 9 SPARE
10 DIGIT 0 SPARE
11 ORIGIN ECHO SEMI-SUPRESSOR TRANSFERRED CALL
INSERTION
12 REQUEST REFUSED OR SPARE

INTERNATIONAL TRAFFIC
INDICATION
13 ACCESS TO TEST EQUIPMENT SPARE
(1 of 2)

NT
Group I Group II
14 DESTINATION ECHO SPARE
SEMI-SUPRESSOR INSERTION OR
INTERNATIONAL TRAFFIC
INDICATION
15 NUMBER END OR INDICATION SPARE

THAT THE CALL TRACED
SATELLITE LINK
(2 of 2)
Use-case 2:
Table 50 Supported R2 Interregister Signals (Forward, use-case 2)
Group I Group II-3 Group III
1 DIGIT 1 OPERATOR DIGIT 1
2 DIGIT 2 NORMAL SUBSCRIBER DIGIT 2
3 DIGIT 3 SPARE DIGIT 3

6 DIGIT 6 MAINTENANCE EQUIPMENT DIGIT 6
11 SPARE SPARE SPARE

13 SPARE - Individual Selection SPARE SPARE
15 SPARE SPARE END OF

NUMBERING
14.6.7.3 Supported R2 Interregister Signals (Backward)

The Backward R2 interregister signals that are applicable to a customer's
deployment are pre-provisionable in the CDE Profile.
Use-case 1:

NT
Table 51 supported R2 Interregister Signals (Backward, use-case 1)
Signal Backward Signal
Group A Group B
1 SEND NEXT DIGIT SUBSCRIBER LINE FREE, WITH

CHARGING
2 ECHO SEMI-SUPRESSOR BUSY LINE

REQUIRED AT THE DESTINATION
OR SEND THE FIRST DIGIT
3 PREPARE FOR RECEIVING CHANGED NUMBER

GROUP-B SIGNALS
4 CONGESTION CONGESTION
5 SEND CALLING SUBSCRIBER SUBSCRIBER LINE FREE,

CATEGORY AND IDENTIFICATION WITHOUT CHARGING
6 SPARE SUBSCRIBER LINE FREE, WITH

CHARGING, AND PLACE
RETENTION UNDER CALLED
SUBSCRIBER'S CONTROL
7 SEND DIGIT N-2 VACANT NUMBER
8 SEND DIGIT N-3 SUBSCRIBER LINE OUT OF

SERVICE
9 SEND DIGIT N-1 SPARE
10 SPARE SPARE
11 SEND INTERNATIONAL TRAFFIC SPARE

INDICATION
12 SPARE SPARE
13 SEND THE INDICATION OF THE SPARE

ORIGIN INTERNATIONAL
REGISTER SITE
14 REQUEST INFORMATION ON THE SPARE

NECESSITY OF INSERTION OF
DESTINATION ECHO
SEMI-SUPRESSOR
15 CONGESTION IN THE GATEWAY SPARE
Use-case 2:

NT
Table 52 supported R2 Interregister Signals (Backward, use-case 2)
Signal Backward Signal Meaning
Group A Group B Group C
Request destination Line status Request for origin information

information
1 SEND GROUP I SIGNAL SUBSCRIBER LINE SEND GROUP III SIGNAL FIRST
SEND NEXT DIGIT FREE, AND NEXT DIGIT FOR SIGNAL
CHARGE AND CHANGE TO RECEPTION
OF GROUP A
2 SEND GROUP I SIGNAL SUBSCRIBER LINE BUSY SEND GROUP I SIGNAL FIRST
SEND NEXT DIGIT DIGIT AND CHANGE TO
RECEPTION OF GROUP A
3 SEND SIGNAL OF GROUP II SPARE SEND GROUP II SIGNAL AND

AND CHANGE TO RECEPTION CHANGE TO RECEPTION OF
OF GROUP B GROUP B
4 CONGESTION BLOCKING CONGESTION
5 SPARE SPARE SEND GROUP I SIGNAL NEXT

DIGIT AND CHANGE TO
RECEPTION OF GROUP A
6 SPARE SPARE SEND SANE DIGIT OF THE

CALLED NUMBER AND
SSEND SIGNAL OF GROUP II CHANGE TO RECEPTION OF
AND CHANGE TO RECEPTION GROUP A
OF GROUP C
14.6.7.4 Supported R2 Timers

The MSAN supports the following timers for the basic call:
• Timer for the reception of the SEIZURE ACK Signal.
• Timer for the reception of the DISCONNECTION ACK Signal.
• Timer for the reception of the FORCED RELEASE ACK Signal.
• Timer that defines the interval for the presence of the FORWARDING Signal.
• Timer that defines the interval for the reception of the FORWARDING Signal.
• The re-answer timer on terminated calls to the TDM R2 side.
• The call process timer is started after digit collection completed. It is stopped upon
the callee answering or caller going on-hook.

NT
14.6.7.5 Codecs
The MSAN supports the following codecs for the basic call:
• G.711 A/u law (10ms, 20ms, 30ms packetization length), including support for
• Packet Loss Concealment (PLC)
• Support of Silence suppression by using Voice Activity Detection (VAD) and Comfort
Noise Generation (CNG).
• G.729AB (10ms, 20ms, 30ms, 40ms, 50ms, 60ms packetization length)
• G.723.1 (5.3kbps, 6.3kbs, with 30ms packetization length)
14.6.7.6 Echo Cancellation.

The MSAN supports G.168/G.165 echo cancellation with an echo tail length from 8
ms upto 128 ms.
14.6.7.7 Adaptive Jitter Buffer

The MSAN supports a configurable jitter buffer up to 135ms.
14.6.7.8 Fax and Modem

The MSAN supports the following features:
• Incoming/Outgoing fax with G.711 VBD or T.38
• sending 488 to fallback to VBD when lack of T.38 resources.
• Voice Band data modem and fax modem operation by using
call; in compliance to GR-909 Sec. 5.2.1.5.3, R5-17.
periodic phase reversals); in compliancy to GR-909 Sec. 5.2.1.3, R5-10.

NT
• CNG detection upon the receipt of a 1100 Hz tone [0.5 sec. ON; 3 sec. OFF] in
compliancy to T.30.
detected.
• Fax: V.21, V.17, V.27 ter, V.29, V.34 compliance.
• Modem (or textphone): V.18, V.21, V.22, V.22bis, V.23, V.32, V.32bis, V.32ext,
• Configurable T.38 Error Correction Mode (ECM): enable / disabled.
#27).
* Put the channel in ECM mode (set the ECM bit #27)
* When the parameter T38_ECM_Ptime is set to 0, the T.38 channel will transmit the
T.4 ECM packet as one packet.
* when the parameter T38_ECM_Ptime is set to a value <> 0, then the system
14.6.8 Supplementary Services.

The following table lists the supplementary services that are supported by the MSAN:
Service Description
DDI Direct Dialling In

NT
14.6.9 PANI header

PANI Header insertion is done in compliancy to the 3GPP TS24.229 standard:
• Initial REGSITER / User initiated reregistration / User initiated deregistration: if
available to the UE (as defined in the access technology specific annexes for each
access technology), a P-Access-Network-Info header field set as specified for the
access network technology (see subclause 7.2A.4)
• UE-originating case: If available to the UE (as defined in the access technology
P-Access-Network-Info header field into any request for a dialog, any subsequent
request (except ACK requests and CANCEL requests) or response (except
CANCEL responses) within a dialog or any request for a standalone method (see
subclause 7.2A.4).
• UE-terminating case: If available to the UE (as defined in the access technology
P-Access-Network-Info header field into any response to a request for a dialog,
any subsequent request (except CANCEL requests) or response (except
CANCEL responses) within a dialog or any response to a standalone method (see
subclause 7.2A.4).
Thus: PANI-header not included ACK, (response to) CANCEL, 100 Trying,
(response to) session refresh request.
• Format 1:
• Format = P-Access-Network-Info: ADSL; dsl-location="quoted string”
• The PANI header (dsl-location) is based on part of the ISAM System Id and used by
the IMS core to identify the originating access device of a SIP request.
• Format 2:
• The PANI header (dsl-location) is based on part of the ISAM Termination Line Id.
Authentication by the IMS core is based on IMPU (=RN) (From) & Access-Id (PANI
Line-Id)
• Format 3:
"line-id=<MSAN-SIP-IP>;cc=39;oc=204;lac=<MSAN-LAC>;ali=;";network-provided

Notify) message.

NT

14.7 CESoPSN Service

Figure 188 Structured (Nx64) E1 Leased Line (PW3) in ISAM via ISDN PRA
LT Board
ETH/IP/MPLS
ISA M ETH/IP/MPLS
DTE/DCE
e1
Wir
udo
SHDSL
16x G.SHDSL
NT
LT Board
Pse
(PTM/ATM)
oP SN e2
Wir
C ES
PTM
do
Business and seu
NP
ATM
S
o P e3 DTE/DCE
customer C ES Wir
8x G.SHDSL
udo
environment (PTM/ATM/TDM) PTM N Pse
2 T
oPS
ATM D C ES
TDM TDM M
l
CPE*
.s hds
M/G DTE/DCE
DTE/DCE TD T
D
E1
Le M TDM bus
as
ed 4x 2xE1
Lin
e E1 front
ISDN PRA
cable
LT Board
LL -
PBX IW
1 4x 2xE1
(*): Compatibility of existing

CPE to be verified.
Ref CPE RAD ASMi-54L - 54L
(variant: 4ETH/2W/E1)
The ISDN PRA LT board allows to terminate Nx64 E1 Leased Line in the ISAM node:
• 8xE1 baseband interfaces (G.703/G.704).
• 1 Nx64 E1 Leased Line per E1 interface.
• 1 E1 interface per CESoPSN Pseudo Wire.

NT
• 1 CESoPSN Pseudo Wire per E1 interface as per RFC5086.

• N (N=1~31) continuous DS0 timeslot(s) per Nx64 E1 Leased Line.
Two alternative transport methods towards the ISAM node are supported:
• Direct connection via E1 baseband 4 wire transmission (G.703): <1km.
• Connection via TDM over G.SHDSL transport: >1km.
Packetization latency, number of timeslots, and payload size are linked by the
following relationship: L = 8*N*D whereby:
• D is the packetization latency (milliseconds).
• L is the packet payload size (octets).
• N is the number of DS0 channels.
The CESoPSN implementation deals with a configurable packetization interval that
must fit to the following equations:
• [N * packetization interval] <= 31.
• The maximum package size must be: 8*N*D<=248.
A CESoPSN Pseudo Wire can be configured with the distinct-IP-mode or the
shared-IP-mode:
• Distinct-ip-mode:
• The local IP address of the Pseudo Wire is configured at the ISDN PRA LT board.
Different ISDN PRA LT boards must have a different local IP address.
• The local IP address assigned to a Pseudo Wire identifies the ISDN PRA LT board
at which the Pseudo Wire is established.
• Different Pseudo Wires established at the same ISDN PRA LT board might share the
same local IP address (the different Pseudo Wires are distinguished by means of
their locally assigned UDP port).
• Different Pseudo Wires established at the same ISDN PRA LT board might have a
different local IP address. (the different Pseudo Wires are distinguished by means of
their locally assigned IP address).
• The local UDP port is autonomously assigned by the system according to the
following rule: 49152 + (E1 index - 1) * 30 * 2 + 2 whereby the E1 index equals the
ISDN PRA LT board port number of the E1 interface.
• Shared-ip-mode:
• The local IP address is shared by all Pseudo Wires established in the NE
(established at different ISDN PRA LT boards) and is configured at the xHUB. The
local UDP port assigned to a Pseudo Wire identifies the ISDN PRA LT board at which
the Pseudo Wire is established. The xHUB identifies the destination ISDN PRA LT
board by means of L4 forwarding.
Different ISDN PRA LT boards must have a different local IP address.
• The local UDP port is autonomously assigned by the system according to the
following rule: 49152 + (slot ID - 1) * 512 + (E1 index - 1) * 30 * 2 + 2 whereby the E1
index equals the ISDN PRA LT board port number of the E1 interface.

NT
14.8 Voice Service related alarms

Several alarms are defined for the Megaco and SIP based voice service.
Please see the ‘ISAM alarms guide’ for further details.
14.9 Compliance to standards

ISAM Voice is fully/partially compliant to the following standards (further details are
provided in the related Protocol Information Compliancy Sheets (PICS documents)):
14.9.1 Megaco
• RFC768, RFC791, RFC792, RFC826, RFC894, RFC919, RFC920, RFC950,
RFC1157, RFC2327, RFC2960, RFC3057, RFC3389, RFC3550, RFC4233,
RFC4734
• IEEE Std 802.3, IEEE Std 802.1Q, IEEE Std 802.1P
• ITU-T Study Group 16: H.248.1v2, H.248.1v3 annex F, H.248.2, H.248.3,
H.248.8, H.248.11, H.248.14, H.248.16, H.248.23, H.248.26, H.248.27,
H.248.34, H.248.45
• ITU-T Study Group II: Basic Call Progress Tones Generator with Directionality,
Expanded Call Progress Tones Generator Package, Basic Services Tones
Generation Package.
• ITU-T Recommendation Q.921, ITU-T T.38 Recommendation fax over IP,
• ITU-T recommendation V.23 (FSK), ITU-T recommendation Q.552: Transmission
characteristics at a 2-wire analogue interface of digital exchanges
• ITU-T Recommendation Q.1950: Bearer independent call bearer control protocol,
• ITU-T Recommendation V.152: Procedures for supporting voice-band data over
IP networks
• ITU-T I.603 SERIES I: INTEGRATED SERVICES DIGITAL NETWORK (ISDN)
Maintenance principles; Application of maintenance principles to ISDN basic
accesses
• Telcordia Bell 202 (FSK)
• ETSI EN 300 659-1 V1.3.1 DTMF for on-hook data transmission
• ETSI EN 300 659-1 V1.3.1, ETSI EN 300 659-2 V1.3.1, ETSI EN 300 659-3
V1.3.1: Subscriber line protocol over the local loop for display (and related)
services.
• ETSI EMC 300 386 v1.3.1: Electromagnetic Compatibility Requirements
• ETSI ES 283 002: H.248 Profile
• Telcordia recommendation GR-30 LSSR: “LSSR: Voice band Data Transmission
Interface (FSD 05-01-0100)”, 1998
• Calling Line Identification service SIN 227, issue 3.2. British Telecom
specification, 2002

NT
14.9.2 SIP
• RFC768, RFC791, RFC792, RFC950, RFC919, RFC920, RFC2131, RFC2327,
RFC2833, RFC2976, RFC3261 (ETSI TS102 027-1), RFC3262, RFC3263,
RFC3264, RFC3265, RFC3311,RFC3321, RFC3323, RFC3325, RFC3326,
RFC3389, RFC3515, RFC3550, RFC3551, RFC3665, RFC3680, RFC3725, RFC
3842, RFC3891, RFC3892, RFC3959, RFC3960, RFC4028, RFC4244,
RFC4780, RFC5009, RFC5366, RFC5806
• Draft-kaplan-sip-session-id-02: A Session Identifier for the Session Initiation
Protocol (SIP)
• Draft-ietf-sipping-sip-offer/answer: SIP (Session Initiation Protocol) Usage of the
Offer/Answer Model
• ITU-T Recommendation V.152: Procedures for supporting voice-band data over
IP networks
• 3GPP ETSI TS 23.167: IP Multimedia Subsystem (IMS) emergency sessions
• 3GPP ETSI TS 23.228: IP Multimedia Subsystem (IMS)
• 3GPP ETSI TS 24.228: Signalling flows for the IP multimedia call control based
on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)
• 3GPP ETSI TS 24.229: IP multimedia call control protocol based on Session
Initiation Protocol (SIP) and Session Description Protocol (SDP)
• 3GPP ETSI TS 24.406: Message Waiting Indication (MWI)
• 3GPP ETSI TS 24.407: Originating Identification Presentation (OIP) and
Originating Identification Restriction (OIR)
• 3GPP ETSI TS 24.408: Terminating Identification Presentation (TIP) and
Terminating Identification Restriction (TIR)
• 3GPP ETSI TS 24.410: Communication HOLD (HOLD)
• 3GPP ETSI TS 24.447: Advice Of Charge (AOC)
• 3GPP ETSI TS 24.504: Communication Diversion (CDIV)
• 3GPP ETSI TS 24.505: Conference (CONF)
• 3GPP ETSI TS 24.529: Explicit Communication Transfer (ECT)
• 3GPP ETSI TS 24.615: Communication Waiting (CW) using IP Multimedia (IM)
Core Network (CN) subsystem
• 3GPP ETSI TS 183.043: IMS-based PSTN/ISDN Emulation
• 3GPP ETSI TS 183.047: NGN IMS Supplementary Services; Advice Of Charge
(AOC)
• Q.931: ISDN user-network interface layer 3 specification for basic call control,
May 1998
• Q.932: Generic procedures for the control of ISDN supplementary services, May
1998
• 3GPP ETSI TS 183.036: TISPAN ISDN/SIP Interworking, Protocol specification,
version 3.4.1, Feb 2011
• ITU-T Q4xx: Specifications of signaling system R2
• ETSI TS 183 036 - TISPAN; ISDN/SIP interworking: Protocol specification

NT

System Description for FD 100/320Gbps NT and FX Layer 2 forwarding
NT
15 Layer 2 forwarding
15.1 Introduction
15.2 The concept of Virtual LAN (VLAN)
15.3 The ISAM is an Access Device
15.4 ISAM Internal Architecture
15.5 Subscriber interface stack on the LT board
15.6 iBridges
15.7 VLAN cross-connect mode
15.8 Protocol-aware cross-connect mode
15.9 IPoA cross-connect mode
15.10 Secure forwarding in iBridge and VLAN cross-connect
15.11 Virtual MAC
15.12 PPP cross-connect mode
15.13 Dynamic VLAN
15.1 Introduction
This chapter focuses on L2 forwarding, consistent with the standards of the Electrical
and Electronics Engineers (IEEE).
Concretely in the ISAM this involves the iBridge and VLAN cross-connect and
E-PIPE forwarding mode.
Note — Strictly speaking, only iBridge and VLAN
cross-connect forwarding modes can be considered as L2
forwarding in term of IEEE context. For practical reasons
however, this chapter will also cover an additional forwarding
mode not really part of L2 forwarding family but still closely
related: PPP cross-connect forwarding. Although PPP
cross-connect mode has distinctive differences with iBridge
and VLAN cross-connect, it has also similarities. See
section “PPP cross-connect mode”.

Layer 2 forwarding System Description for FD 100/320Gbps NT and FX
NT
15.2 The concept of Virtual LAN (VLAN)

VLANs are standardized by the Institute of Electrical and Electronics Engineers
(IEEE) in 802.1q (VLAN basic concept) and the 802.1ad/D6.0 (VLAN stacking).
15.2.1 VLAN tagging in IEEE 802.1q

Tagging of an Ethernet frame consists of adding a IEEE 802.1q tag of four bytes that
specifies the VLAN ID and the priority (from 0 to 7) that indicate the QoS class. Table
54 shows the frame types used with their properties.
Table 54 Frame types
Property Tagged frame Priority-tagged frame Untagged frame
Carries the tag of four bytes Yes Yes No
Value of VLAN ID Non-zero value Zero NA
Indication priority bits QoS class QoS class NA
Figure 189 shows an untagged and a tagged/priority-tagged Ethernet frame.

Figure 189 Untagged and tagged/priority-tagged Ethernet frames
Untagged frame
dest src length
preamble SFD data + pad FCS
addr addr type
7 1 6 6 2 46…1500 4
(priority-)tagged frame
MAC client
dest src 802.1q VLAN
preamble SFD length data + pad FCS
addr addr tag tag
type
7 1 6 6 2 2 2 46...1500 4
15.2.2 VLAN Tagging as a Means to support Virtual LAN

(VLAN)
The use of VLAN Tagging on Ethernet frames has allowed the co-existence of a
multiplicity of Virtual LANs (VLANs) which are logically isolated from each other
although sharing the same physical infrastructure. Each VLAN is only aware of the
Ethernet Frames tagged with the specific VLAN tag of this VLAN.

NT
By using the frames VLAN tags as VLAN discriminator, end-stations and frame
forwarders within a given VLAN have no contact with end-stations or frame
forwarders operating in another VLAN even when they share the same physical
infrastructure. Figure 190 shows an example of VLANs.
Figure 190 Example of VLAN
e VLAN A
on 8
9
c kb i tch 7
Ba
6
Sw 5
4
2
3
VLAN B
1
9
h 8
itc 7
Sw 6 VLAN C
5
4
3
2
1
In general the VLAN is shared between a group of several end-stations, forming a

meshed configuration. In some special cases, the VLAN is used in a strict
point-to-point configuration between two end-stations. Within a VLAN, frame
forwarding takes place at layer 2 (L2) by using Ethernet-related information.
The ISAM supports the VLAN concept applied to access networks.
15.3 The ISAM is an Access Device

The ISAM is a DSLAM or OLT type access device i.e. a device which supports the
VLAN concept applied to access networks. Its basic function is to interconnect
subscribers with Network Service Providers (NSP) over a public Ethernet
Metropolitan Area Network (EMAN) network. Depending on the business model of
the Access provider, an NSP may offer one or several Services, for instance HSI,
VoIP, TV,... which subscribers want to enjoy.

NT
Consequently, the ISAM is an asymmetrical machine:

• In all practical deployments, the number of subscribers is quite larger than the
number of service providers.
• By definition, the ISAM makes the distinction between interfaces facing users and
interfaces facing the EMAN network side:
• Interfaces which are directly facing subscribers or which are connected to subtending
ISAMs instantiate the so-called “User Side”. Such interfaces are generally
considered untrusted, especially when facing individual subscribers.
• Interfaces connected to the EMAN or directly to service provider equipment (for
example, BRAS) instantiate the so-called “Network Side”. Network side interfaces
are either:
* Trusted (the most typical case) when the ISAM is connected to some aggregation
network in charge of dispatching the traffic further on towards the various service
providers and taking responsibility for SLA enforcement between these service
providers.
* Untrusted when the ISAM directly interfaces with service providers' network and is
directly in charge of SLA enforcement between these service providers. This type of
untrusted network interface will be called "VULA uplink" further on in this document.
Figure 191 ISAM as an Access Device
NNIs
UNIs
EMAN
Forwarder
Instances
ISAM
Network Side User Side
One will also note that in case of subtending ISAM, the access functionality is spread
over the Hub and Subtending ISAMs. Much of the subscriber related functionality will
obviously be performed in the subtending ISAM, alleviating the hub ISAM
requirements to that respect. For what concerns frame forwarding, the Hub ISAM will
just perform a simpler aggregation of subtending traffic. To reflect the difference in
the handling of subscriber traffic vs. subtended traffic, one has introduced the notion
of UNI (User Network Interface) for the links connected to individual subscribers and
NNI for links connected to subtending ISAMs.
Note 1 — Throughout this document and generally in all ISAM
documentation User and Subscriber are synonyms and are
indifferently used.
Note 2 — Even if features on UNI and NNI sometimes differ, L2
Forwarding concepts apply similarly to UNI and NNI.

NT
Because of this asymmetry, the functions on the subscriber side are generally
different from those on the network side, in particular considering privacy and
security aspects.
Beyond the obvious capability of terminating of DSL and PON circuits, much of the
added value of the ISAM compared with utility Ethernet switches resides in its unique
capability to exploit and preserve the difference between user side and network side,
in particular around L2 forwarding.
15.3.1 Generic L2 Forwarder

In a L2 access network, each NSP Service is offered on a particular network VLAN
over the EMAN. The role of the ISAM is to attach every subscriber to the NSP
Service(s) of their choice, that is, to the VLAN corresponding to this NSP Service in
the EMAN.
For that purpose, the ISAM uses a generic L2 forwarder model. In this model the
ISAM associates to every NSP Service a dedicated L2 forwarder, operating within
the context of this network VLAN and to which uplink(s) and subscriber(s) can be
attached by means of forwarder interfaces.
The basic generic L2 forwarder is shown in Figure 192.
Figure 192 The generic L2 forwarder
L2 Forwarder
Forwarder
Forwarding
Identifier Forwarder
data
(Network Vlan for Interfaces
structures
the NSP Service)
E.g. FDB,
Network VLAN PortTable,
NSP for etc…
Server this NSP Service
Generic
L2 Forwarder
EMAN

NT
It makes use of the following data structures which form its operational context:
• Forwarder Identifier:
This is reflecting the fact that the ISAM typically hosts several instances of L2
forwarders, one per NSP Service. Each L2 forwarder instance operates within the
context of a dedicated network VLAN used to identify the forwarder. Depending
on the network deployment strategy, this VLAN can be identified by one of the
following:
• a single VLAN tag (say C-VLAN): this can be for instance when an NSP only provides
one service, say HSI. The forwarder is then a single tag forwarder.
• a dual tag (say S+C-VLAN): this can be for instance when the S VLAN tag identifies
a multiservice-NSP and the C VLAN tag identifies a given service offered by this NSP
(alternate VLAN tag usage are possible as well, e.g. where the C VLAN tag identifies
the individual subscriber rather than a service). The forwarder is then a dual tag
forwarder (sometimes also called a stacked forwarder).
Some L2 Forwarding properties can generally be configured at L2 forwarder level
(e.g. vMAC, downstream broadcast traffic enable, secure forwarding, etc.… see
further)
• Forwarder Interfaces:
Forwarder Interfaces are the access points of the forwarder to the external world,
typically the subscribers and the NSPs. It is through these Interfaces that the
forwarder receives or transmits frames.
Some L2 Forwarding properties can generally be configured on an individual
interface basis (e.g. VLAN Translation,… see further)
• Forwarding Data Structures:
This is the means by which the forwarder knows to which egress forwarder
interface a frame should be directed to. This data structure typically consists in an
FDB (Forwarding DataBase) containing the associations between MAC address
and the VLAN ports on which they were learned (or statically configured).
It should be emphasized that consistent with the concept of VLAN isolation seen in
section “VLAN Tagging as a Means to support Virtual LAN (VLAN)”, each L2
forwarder has its own private context. For instance, a L2 forwarder interface cannot
belong to two L2 forwarders and each L2 forwarder has its own private FDB.
Note — IEEE leaves the possibility open to have a shared FDB

between several L2 forwarders. This sometimes is unavoidable
due to hardware limitations but is typically not desirable in an
access network because of the restrictions it brings.

NT
15.3.2 Usage of VLANs in an “1:1” and “1:N” Access

Network Deployment
According to DSL Forum TR-101, an NSP VLAN can be used in 1:N or 1:1
deployment mode:
• In the 1:N mode, the NSP network VLAN is shared by a group of N subscribers.
In the ISAM this deployment is supported by a L2 forwarder specialized as an
iBridge.
• In the 1:1 mode, the NSP network VLAN is used by only one subscriber. In the
ISAM this deployment is supported by a L2 forwarder specialized as a VLAN
cross-connect.
The iBridge is derived from the standard self-learning IEEE 802.1q-Bridge which
makes use of destination MAC addresses lookup to discriminate subscribers from
each other. A standard bridge however is not suitable for residential DSL access
because it lacks a number of essential security and privacy features. Adding those
features turns a standard bridge into an iBridge (also known as Intelligent Bridge).
Note — In CLI and MIB and in some documentation the term

Residential Bridge (RB) is sometimes used as an equivalent for
iBridge.
Since the ISAM has the notion of user side and network side, it has the capability to
deviate from a normal standard bridge in particular in term of controlling traffic
switching (or flooding) and controlling MAC address learning.
On the other side, due to its very 1:1 nature a VLAN cross-connect does not rely on
MAC address lookup to identify a given subscriber, the network VLAN ID is sufficient.
Note however that in case of several uplinks, an FDB is still needed for the VLAN
cross-connect to find out the right uplink. So actually, a VLAN cross-connect usually
exhibits a bridge behavior on the network side.
Although privacy is not as a concern as for iBridges, VLAN cross-connects are also
aware of user side versus network side for other access related features (e.g. DHCP
Opt82).
A typical VLAN cross-connect is shown in Figure 193.

NT
Figure 193 A VLAN cross-connect
Network VLAN
for User Vlan
NSP FDB
this NSP Service (19)
Server
(17)
VLAN Cross-Connect (17)
EMAN
Because they are both affiliated to the same L2 Generic forwarder iBridges and
VLAN cross-connect follow the same configuration model despite their differences.
Moreover most of L2 access related features apply to both of them as well (e.g. VLAN
translation, DHCP Opt 82, …). This will be further detailed in later sections.
15.3.3 Dual-tag L2 Forwarders

This section will elaborate a bit on dual-tag L2 forwarder mentioned in
section “Generic L2 Forwarder”.
These forwarders has the special feature that subscriber upstream frames get their
single-tag outer VLAN replaced by the dual-tag VLAN of the forwarder before being
forwarded to the network. Conversely dual-tagged network frames matching the
forwarder dual-tag identifier will have their dual-tag outer VLAN replaced by the
genuine single-tag subscriber VLAN before being passed to the subscriber.
Figure 194 illustrates a dual-tag cross-connect (also called S+C cross-connect)
Figure 194 Dual-Tag S+C-VLAN cross-connect
Dual-tag
Network VLAN User VLAN
NSP for this NSP Service FDB (19)
Server (100,19)
VLAN Cross-Connect (100,19)
EMAN

NT
15.3.4 Multi-service Configurations on the Access Link

In general subscribers enjoy multiservice offering i.e. each subscriber needs to get
access to different NSPs simultaneously. Consider for instance a residential
end-user that is subscribed to a triple-play service offering. This end-user must be
capable of accessing HSI, Video (VoD and Broadcast TV) and VoIP services over
his DSL line/access link.
As we told previously the role of the ISAM is to forward subscriber traffic to the right
NSP VLAN on the EMAN though the corresponding L2 forwarder.
The following basic question then arises: how will multi-service traffic that is
originating from a residential end-user be discriminated and forwarded to the correct
service-VLAN at the network side, through the correct iBridge or VLAN CC instance?
Several possibilities exist upon operator's deployment preference:
• The multi-PVC model:
For DSL interfaces in ATM mode it is possible to provide a separate PVC per
service. Each PVC is then coupled to a L2 or L3 forwarder that gives access to
the service VLAN of interest. The multi-PVC model assumes that user frames are
untagged.
A multiple PVC solution is often encountered with access providers that have
evolved from ATM to Ethernet aggregation networks, while keeping their CPE
configuration unchanged. A multiple PVC solution is also used when upstream
QoS guarantees must be given for delay-sensitive applications (such as VoIP) on
low-bandwidth DSL links
• Reducing the number of PVCs: protocol-based forwarding context selection
In many cases, access providers want to minimize the number of PVCs used on
a DSL interface to reduce operational complexity. The protocol-based model
assumes that user frames are untagged.
A popular scheme is the following:
• Provision a single PVC per end-user with bridged encapsulation
• Deliver the HSI service through a PPPoE session that is set-up between the CPE and
a central BRAS. The ISAM is capable of segregating the end-user's PPPoE traffic
from the rest by applying an Ether-type filter, and will forward this PPPoE traffic in a
L2 forwarder that is coupled to the “HSI” VLAN. This procedure is known as
protocol-based VLAN selection
• Deliver IPoE-based multimedia services using another L2 or L3 forwarder, which is
coupled to the “Multimedia” VLAN. The IPoE traffic is separated from the rest via
Ether-type filtering as well
• If for some reason it is appropriate to carry multicast streams in a separate “Multicast”
VLAN this can be done as well. IGMP packets sent by the end-user to join a given
multicast stream are intercepted by the ISAM to perform its IGMP proxy function. For
each configured multicast stream the operator can specify what network VLAN this
stream originates from. This feature is referred to as cross-VLAN multicast.

NT
• PTM/Ethernet subscriber interfaces: protocol-based forwarding context selection

Protocol-based VLAN selection, being an Eth-type based segregation technique
can equally be applied on PTM or Ethernet subscriber interfaces (VDSL, SHDSL
or ADSLx in PTM mode, subscriber interfaces on the Eth LT). Again
protocol-based VLAN selection assumes that end-user frames are sent untagged.
While the use of just untagged frames on an PTM/Ethernet interface is in itself
quite simple and straightforward, it also limits the number of different NSPs that
can be reached by a given end-user to two (or more when cross-VLAN multicast
is used).
Some access providers want more control over the forwarding context selection,
which they can achieve if they start using single-tagged frames on the access link.
• PTM/Ethernet subscriber interfaces: the multi-VLAN model
The “multi-VLAN model” refers to an architecture whereby on the access link
tagged frames are used, with multiple VLAN-ids that indicate the services of
interest. This is similar to the multi-PVC model on ATM-based DSL lines. Traffic
tagged with different VLAN-ids is to be handled differently in the ISAM, i.e. to be
forwarded via separate forwarders.
An important driver for going to the multi-VLAN model on PTM/Ethernet
subscriber interfaces is service wholesaling. In case of VDSL or fiber there is
more bandwidth compared to the ADSL case, so it makes sense to subdivide the
available BW and wholesale part of it to 3rd party service providers. In the
aggregation network each 3rd party wholesale provider is given a separate VLAN,
and the multi-VLAN scheme provides a flexible way of mapping end-user traffic
onto these wholesale provider VLANs.
The multi-VLAN model implies that VLAN-ids are present both on the
subscriber-side and the network-side. Two sub-cases can be identified here:
• A subscriber-side VLAN-id can have network-wide significance, which means that
the frame is forwarded at L2 while leaving the VLAN-id unaltered
• A subscriber-side VLAN-id can have a local significance, which means that the
VLAN-id is just used to select a particular forwarder. Once this is done, the
subscriber-side VLAN-id is stripped off from the packet, the forwarding decision is
made and a new network-side VLAN-id is stamped onto the packet when it is
transmitted on the network interface. From an end-to-end perspective this
mechanism amounts to performing a VLAN translation
The multi-VLAN model offers the equivalent of the multi-PVC model in ATM, and
that implies that also multicast handling is equivalent to what is offered in a
multi-PVC environment.
Two variants can be considered:
• The basic model, equivalent to the multi-PVC model: in this case multicast services
can only be offered on 1 VLAN on the user-to-network interface (UNI).
The ISAM can treat 1 VLAN on the UNI as “the VLAN for IGMP”. IGMP messages
coming from this VLAN are handled in the IGMP proxy, and this allows to support all
the IGMP/multicast related features of ISAM identically as in case of ATM
• The advanced model, offering multicast services on more than 1 VLAN on the UNI.
This is the equivalent of “IGMP/multicast on multiple PVCs”.
Since the ISAM supports cross-VLAN multicast, the VLAN ID on the UNI can be
different from the VLAN of the multicast stream used on the uplink.

NT
• The multi-VLAN model on top of a single ATM PVC

While the multi-VLAN model is most natural in case of PTM/Eth interfaces, it can
be applied as well on top of a single ATM PVC.
A first possible reason to choose for this model is to achieve a uniform
configuration for VDSL and ADSLx access. For instance on a given VDSL LT it is
possible to connect both ADSL(2+) and VDSL subscribers depending on the
individual end-user's service subscription. Above the physical layer, the end-user
configuration can be kept the same if multi-VLANs are used on top of a “bridge
port” which is either stacked on top of a bridged encapsulated PVC or on top of
the VDSL port.
Another reason for using a multi-VLAN model on top of a single ATM PVC may
have to do with CPE limitations: some cheaper ADSL(2+) CPEs support at most
one active ATM PVC.
The ISAM can support these various deployment models by means of the generic L2
concepts detailed in the next section.
15.3.5 The VLAN port: Supporting Concept for

Multiservice Access
In the previous section we have seen different possibilities for supporting
multi-services on the subscriber's line. It should be noted that once the L2 service
forwarder is identified, the frame forwarding process itself does not depend on the
way the service was multiplexed on the subscriber's line, by means or multi-PVC,
multi-VLAN or both.
To reflect this, the concepts of VLAN port and bridge port have been introduced in
the ISAM, which form a common denominator for all the different service multiplexing
methods.
More specifically, VLAN ports, bridge ports and some additional objects are defined
as follows:
• bridge port:
a bridge port is a generic Ethernet interface. In practice, a bridge port can be a
PVC carrying Ethernet, an EFM link or a physical user Ethernet link. A bridge port
can carry a mix of untagged, priority-tagged or tagged frames.
Note — Despite the name, in ISAM, a bridge port is not related
to a specific iBridge! A better name for bridge port would have
been virtual Ethernet port!
• VLAN port:
a VLAN port is a generic tagged Ethernet interface on a bridge port, more
specifically it is only related to the frames tagged with a specific VLAN ID on this
bridge port. In the ingress direction, a VLAN port can be best seen as picking-up
frames with a specific VLAN tag received from the bridge port. For all practical
purposes, a VLAN port is the ISAM implementation of the L2 Forwarder Interface

NT
introduced in section “Generic L2 Forwarder”. Tagged frames received by the

ISAM which cannot be related to any configured VLAN port are discarded.
The VlanPort concept is extended to dual tagged traffic on all interfaces hosted
by the 10GE LT (VULA Uplink, NNI and UNI), that is the L2 Forwarder Interface
is now defined by a pair of stacked VlanId's on the Bridgeport. When VLAN
translation is applied on stacked VlanPorts, both VLAN tags are replaced.
Note 1 — The ISAM allows to configure the TPID (802.1q tags)
used on each network interface (NT uplinks or VULA uplinks),
from a set of four possible values per ISAM.
Note 2 — On VULA uplinks, any TPID out of the four available
values (including the default 0x8100) can be specified for every
outer VLAN associated with a VlanPort (stacked or unstacked).
For stacked VlanPorts, the TPID of the inner VLAN carried by
the received traffic must be 0x8100 (not programmable). Mind
that a given VLAN Id may not be simultaneously provisioned as
C- and S-VLAN on the various VlanPorts on a VULA uplink.
• Port Default VLAN ID (PVID):
A bridge port can be configured with a PVID. The PVID has only relevance for
iBridging or VLAN cross-connect. It is the VLAN ID which untagged or
priority-tagged traffic should inherit from this bridge port when subjected to
iBridging or VLAN cross-connect. In that case, untagged frames are considered
by the ISAM “as if” tagged by the user with the PVID.
Note — Port default PVID variants are not supported on the
VULA uplinks
• Port Protocol Default VLAN ID (ProtocolVID):

A bridge port can be configured with a Protocol VLAN ID. A ProtocolVID has the
same purpose as a PVID except that it takes into account the Ethertype of the
packet.
In practice, the ISAM operator can configure up to three port-Protocol-VLAN IDs
per bridge port:
• One ID per PPP
• One ID for IPv4 and related protocols (for example, ARP)
• One ID for the IPv6
When a PPP (respectively IPv4, IPv6) protocol VLAN ID is configured on a bridge
port, all untagged or priority-tagged PPP (respectively IPv4, IPv6) frames will be
considered as if tagged with this VLAN ID. Like the PVID, the ProtocolVID has
only relevance for iBridging or VLAN cross-connect.
When a PVID and Port-Protocol-VLAN ID(s) are both configured on a given bridge
port and an untagged frame is received, the ISAM always selects the ProtocolVID
if the protocol type matches.

NT
• PVID tagging flag:

This is a parameter that can be configured at bridge port level, for the GPON or
XGS-PON / TWDM-PON ports. It indicates whether the ONT or the ISAM should
perform the operation of adding the PVID for the untagged and priority-tagged
traffic. By default this is done by the ONT. Note that PVID handling at the ISAM
has certain restrictions:
• protocol-based PVID is not supported;
• it does not support S-Tunnel iBridge and S-Tunnel cross-connect;
• certain p-bit marking/remarking options are also not supported (for example there is
no support for DSCP to p-bit alignment).
So in summary, a L2 forwarder interacts with the external world, i.e. subscribers and
EMAN by means of VLAN ports, whatever line technology is used (PVC, EFM,
Ethernet, and so on) and whatever L2 forwarder type, iBridge or VLAN
cross-connect.
In Figure 195 below, one VLAN port is created for each service on a given
subscriber's line.
Similarly, if VULA uplinks are used for interfacing the ISAM with the network,
VlanPorts are also created on these VULA uplinks.
Figure 195 L2 multiservice by means of VLAN ports
VlanPort
L2 Fwd1
NSP1 BridgePort
VLAN 1
EFM
NSP2 VLAN 2 L2 Fwd2
VLAN 3
EMAN
NSP3
L2 Fwd3
Figure 196 illustrates some examples on how VLAN ports and bridge ports help to
make abstraction of the line transport technology and frame encapsulation.

NT
Figure 196 VLAN ports hiding the line transport technology

VlanPort BridgePort PVC Phy Line
PVID Untag_Serv1
PVID Untag_Serv2
PVID Untag_Serv3
IP-VID Untag_Serv1 (IP)

Untag_Serv2 (PPP)
PPP-VID Untag_Serv3 (other)
PVID
Tag_Serv1
Tag_Serv2
Tag_Serv3
EFM Tag_Serv1
Untag_Serv2 (PPP)
IP-VID Untag_Serv3 (other)
PVID
An interesting feature of this generic L2 forwarding model is VLAN translation by

which subscribers can access an NSP using frames tagged with another VLAN than
the NSP VLAN.
Obviously, de-coupling user VLAN from network VLAN allows more flexibility in
terms of network deployment: VLAN ID values may be locally assigned at the user
side CPE without being constrained with the VLAN ID values used within the EMAN.
In particular, this makes flexible wholesaling possible without local CPE
(re)configuration. Assume for instance a deployment where all subscribers have a
CPE hard coded with a given VLAN ID for HSI service. Assume also that the access
provider wants to offer subscribers the choice between competing NSPa and NSPb
for HSI service, on a subscription basis.
VLAN translation allows the access provider to do that without reconfiguring CPE
VLANs: selecting the right NSP per subscriber will be done in the ISAM by translating
each subscriber VLAN to the proper NSP VLAN.

NT
The configuration of S+C-VLAN cross-connects, (see section “S+C-VLAN

cross-connect: VLAN stacking for residential subscribers”) uses an extreme case of
VLAN translation: a user single-tag VLAN ID say “CLocal” is translated into a network
dual-tag VLAN ID say “SNetwork+CNetwork”. As an example, CLocal could be the same
for all users hard coded in their CPE, while CNetwork could carry the identity of each
subscriber and SNetwork would carry the identity of the NSP.
When using stacked VlanPorts in conjunction with S+C VLAN cross-connects, the
VLAN translation is then extended : a user dual tag VLAN Id, say “SUser+CUser” is
now translated into a network dual tag VLAN Id, say “SNetwork+CNetwork”.
Note that with VLAN translation capabilities on the user side, there is usually no point
to support VLAN translation on the network side, except when considering VULA
uplinks where multiple Content Providers are directly interfacing with the ISAM.
Since each Content Provider may use his own VLAN addressing scheme, potentially
conflicting with other Content Providers, VLAN translation is supported on VULA
uplinks
As indicated in previous sections, although multi-VLAN originally came from the
requirement to support multi-services above VDSL, P2P ETH and GPON subscriber
access lines, some customers may want to use multi-VLAN on top of PVC for ADSL
as well.
Doing so can be interesting to create a uniform network configuration, or to alleviate
some possible CPE limitation.
To limit the configuration complexity of ADSL lines, the operator must however make
a decision per ADSL line and segregate services either via PVCs or via VLANs. In
the latter case, a single PVC will carry all the different VLANs.
15.3.6 Configuration Scenario Example for Multiservice

Deployment
So to summarize the previous sections, the L2 processing of a frame in the ISAM can
be, roughly speaking, partitioned in three stages for both the upstream and
downstream direction:
• User/subscriber side processing
• L2 forwarding itself and
• Network side processing

NT
This partitioning is handy to deal with the ISAM functional asymmetry emphasized at
the beginning of section “The ISAM is an Access Device”
• Subscriber side processing:
This involves the functions related to VLAN ports on the user side. Depending on
configuration:
• support of various underlying user frame encapsulation types, e.g. Ethernet PVCs,
Ethernet VDSL EFM, Ethernet Phy, IPoA PVC, PPPoA PVC,...
• support of various VLAN tagging mode: untagged, priority tagged, single tagged or
multiple tagged
• User VLAN tag manipulations: preserve/translate user VLAN IDs, add (upstream) or
remove (downstream) an extra VLAN tag to a specific user frame.
Note: these VLAN translations are not supported on the GE Ethernet LT NNI
interfaces.
• IPoA to IPoE conversion (see further).
• find out which forwarder instance a received upstream frame has to be submitted to.
This takes place by matching the frame VLAN tag(s) to a VLAN port configured on
the bridge port on which the frame has been received.
Of course, the ISAM performs additional functions on the user side but they are
considered outside the scope of this Chapter because not related or only indirectly
related to L2 Forwarding:
• subscriber management related functions like Opt 82, PPP relay tag, QOS, Filters,…
• redundancy mechanisms like Link Aggregation, Spanning tree,...
• L2 Forwarding:
The role of the L2 forwarder is essentially to decide on which outgoing forwarder
interface(s) an ingress frame has to be sent out. Naturally the iBridge and VLAN
CC use different mechanism to forward frames.
• Network side processing:
This involves the functions related to VLAN ports on network side:
• The ISAM only supports Ethernet frames on the network side: they can be single- or
multiple-tagged (untagged and priority tagged frames are normally never deployed).
• Finding-out which L2 forwarder instance a received downstream stream frame has
to be submitted to.
• Note that no VLAN translation is supported on the network side
Of course, the ISAM performs additional functions on the network side but they are
considered outside the scope of this chapter because not related or only indirectly
related to L2 Forwarding:
• Termination/Relaying of various subscriber or network related protocols (GMP,
DHCP, PPPoE, Routing protocols, OAM, Link aggregation, Spanning Tree …)
• QoS-related functions
To conclude, here is a typical scenario for an operator to establish the connectivity
between subscribers and NSP Servers:
• for each NSP, create an iBridge or VLAN cross-connect L2 forwarder associated
to the NSP's VLAN
• attach network uplinks to the L2 Forwarder(s) (see further for details)

NT
• create a bridge port on every user PVC/EFM (a Bridgeport is shared by all

services)
• attach subscribers to L2 Forwarder(s) by creating on each subscriber's bridge port
a VLAN port corresponding to each L2 Forwarder. If necessary, the operator has
the possibility to create a VLAN port translating a user VLAN ID into the L2
Forwarder VLAN ID.
• If untagged frames are expected on a bridge port the operator can configure a
PVID or ProtocolVlanId on this bridge port referring to the VLAN port to be used
when the frame is received.
Figure 197 shows an example of multi-VLAN access with VLAN translation. In this
example, there are two VDSL access lines: EFM1 and EFM2. PVCs supporting
multi-VLANs are also shown. Note that this example applies to ADSL, VDSL, P2P
ETH, GPON and XGS-PON / TWDM-PON subscriber access lines.
Figure 197 Multi-VLAN and VLAN translation example
BrPort VlanPorts VlanPorts BrPorts

PVC1-VLAN1
Tr
PVC1
MAC
GE1-VLAN1 PVC2-VLAN1
FDB Tr
NSP1
EFM1-VLAN1 DSL
iBridge Tr PVC2 Phy
PVC2-VLAN2
Tr
MAC PVC3
GE1-VLAN2 FDB PVC3-VLAN17 DSL
NSP2 Tr
Phy
iBridge EFM1-VLAN2
Tr
Eth EFM1
DSL
Phy Phy
GE1-VLAN3 EFM1-VLAN3
NSP3 Vlan CC Tr
NSP4 Vlan CC Tr EFM2
DSL
Phy
NSP5 Vlan CC Tr
EMAN ISAM

NT
15.3.7 Use of MPLS encapsulation in the ISAM generic

forwarding model
The MPLS technique is an interesting alternative to connecting the ISAM to the NSP.
With MPLS, the ISAM reaches a given NSP via an MPLS pseudo-wire rather than
via a network VLAN dedicated to the NSP. Actually the introduction of MPLS does
not change the generic forwarding model presented above, it just adds another
network encapsulation possibility. For more details on MPLS see chapter “MPLS”.
The use of MPLS on the network side is illustrated in Figure 198.
Note — MPLS is not supported on VULA uplinks.
Figure 198 MPLS as network encapsulation technique
Ethernet
T PVC1_VLAN1
MPLS_PW1 Ethernet
NSP 1 VLAN MAC T PVC2_VLAN1
ports FDB
Ethernet
iBridge T EFM1_VLAN1
Ethernet
T PVC1_VLAN2
MPLS_PW2 VLAN MAC Ethernet
NSP 2 T PVC3_VLAN17
ports FDB
iBridge Ethernet EFM2_VLAN2
T
MPLS_PW3 Ethernet
NSP 3 VLAN CC T EFM1_VLAN3
MPLS_PW4 Ethernet
MPLS_PW5 Ethernet
MPLS network ISAM

(overlayed on EMAN)
15.3.8 ISAM support for VULA operations

Subscriber traffic is usually collected using an Access Network (hosting DSLAM and
OLTs) directly interfacing with the subscriber and an Aggregation Network, further
grooming traffic from multiples DSLAMs/OLTs towards hand-over points towards the
Content Providers' BRAS and/or BNGs.
Access and Aggregation Networks are typically owned by the same Network
Provider: in this case, Service Level Agreement (SLA) enforcement between Content
Providers is performed within the Aggregation Network.

NT
In some other network architectures, and in order to maximize competition between

Content Providers (and consequently, allow for maximum differentiation between
them), some Network Providers (the Access Provider in this case) limit their
responsibility to the sole Access Network. It is then up to the Content Providers to
build up their own infrastructure to connect their services to the Access Network.
When the Access Network is directly hosting the handover interfaces to the Content
Providers, there is no trusted Aggregation Network anymore to regulate the resource
usage of each Content Provider and consequently, the ISAM becomes responsible
for service provider SLA enforcement.
In this mode of operation, the ISAM network side is not trusted anymore :
downstream traffic from the network is therefore monitored by the ISAM to ensure it
remains within the pre-established limits. In order to keep this model economically
viable for the service providers, the amount of subscribers who can be accessed
through an ISAM acting as a point of handover must be large enough. Consequently,
the "handover" ISAM will typically be an OLT aggregating traffic from:
• Local subscribers connected through GPON or XGS-PON / TWDM-PON.
• Remote subscribers connected through remote DSL nodes (VDSL cabinets,
small VDSL/G.fast modules) connected to the OLT through either point-to-point
Ethernet or GPON or XGS-PON / TWDM-PON lines.
Figure 199 ISAM support for VULA operations

Service Provider R esponsibility Dom ain
Upstream SLA DownstreamSLA

enforcement enforcement
RGW CPE 10 GE
DSLAM
RGW CPE
N x GE
RGW CPE
2 x GE Or 10G
DPU CP 1
RGW CPE
RGW CPE
Dow nlink OLT VULA
Uplink
DPU N x GE
RGW CPE Or 10G
CP N
RGW ONT
GPON
NGPON2
RGW ONT
A ccess Provider R esponsibility Dom ain

NT
The VULA uplink interfaces being untrusted interfaces, they will differ from the
standard uplink interfaces in the sense they will support a very similar L2 forwarding
feature set as the user interfaces, but with a much higher scalability:
• Highly flexible VLAN operations, including the ability to translate VLANs (both
single and dual tagged VLANs)
• Highly flexible QoS operations, allowing to remark and police a large amount of
traffic flows received from the Content Providers and identified by their single or
dual tagged VLANs.
If SLA is enforced on a per-subscriber basis, it might also be relevant to propagate

the "SLA enforcement decision" towards subtended nodes allowing for a coherent
end-to-end enforcement process. This propagation is then performed by updating
the packets (p-bit or DEI update) so this information becomes available to all
elements of the Access Network in order to take the appropriate traffic management
decisions (see the “Quality of Service” chapter for more details).
15.4 ISAM Internal Architecture
15.4.1 L2 forwarding on the NT board and the LT boards

Layer 2 forwarding in ISAM is generally distributed over the LT boards and NT board
in a two stage architecture. There may be also cases where only the NT board takes
part in the Layer 2 forwarding - when users are directly connected to the NT board
or when a subtending ISAM comes in the picture. This is shown in Figure 201.
Note — Figure 201 does not show the VLAN translation

capability on the user side of the LT board.
The distributed Layer 2 forwarding in ISAM also applies to GPON and XGS-PON /
TWDM-PON access solutions. In this case, the OLT - ONT sub-system is acting as
a single ISAM LT entity. This is shown in Figure 200.

NT
Figure 200 Distributed Layer 2 Forwarding in ISAM (GPON/XGS-PON /

TWDM-PON OLT-ONT)
VDSL
LT
NT
xDSL
GLT-ONT
Eth
OLT ONT CES
POTS
Note — An ISAM may have xDSL, Point-to-Point Fiber and

GPON/XGS-PON / TWDM-PON all within a single shelf. The
specific supported mixed configurations depend on the actual
ISAM hardware configuration.

NT
Figure 201 Layer 2 Forwarding in ISAM
L2 Fwdr
NSP A
L2 Fwdr
NSP B
L2 Fwdr LT
Phy NSP A
L2 Fwdr
Phy NSP A
L2 Fwdr
NSP B
L2 Fwdr
NT NSP B
LT
ISAM
Note — Figure 201 does not show the VLAN translation

capability on the user side of the LT.
The basic strategy for the layer 2 forwarding data plane is that:
• When subscribers are connected to LT boards (directly or via the ONT), the NT
board forwards downstream frames to the proper LT board(s) and the LT board
forwards downstream frames to the proper subscriber line/VLAN (directly or via
the ONT).
• It is the LT board that implements the difference between the VLAN
cross-connect, the iBridge mode and the stacked iBridge mode. The NT board
behavior is identical for the iBridge and VLAN cross-connect.
Note — When MPLS pseudo-wires are used on the network
side, the NT board can be optimized to directly support
cross-connect forwarding (called E-PIPE service) next to the
regular iBridging (VPLS service)

NT
• The LT board translates user VLAN into network VLAN (optionally). In case of
GPON and XGS-PON / TWDM-PON access, there are two alternative modes for
VLAN translation:
• ‘Remote' translation: the ONT translates user VLAN into network VLAN
• ‘Local' translation: the GPON LT translates user VLAN into network VLAN
The configuration of remote or local translation mode is possible at the ONT level.
The default mode is remote translation, that is, VLAN translation performed at the
ONT.
• The NT board behaves as much as possible as a standard bridge (except when
it performs E-PIPE forwarding). However, some restrictions may be required or
desired for a consistent interworking with the specific LT boards forwarding
modes, iBridge or VLAN cross-connect. User security and privacy may also
require specific rules in the NT board, as further developed below.
• In some cases, the operator only wants to accept single-tagged Ethernet frames
from end-users. This is possible by combining VLAN handling on the LT board
with additional filtering on the NT board. The LT board can be configured to use a
forwarding model that adds a second tag to the incoming customer traffic (for
example, S/C VLAN cross-connect). By attaching the VLAN to an SAP on a
VPLS, the NT board can be configured to only accept Ethernet frames having 2
C-VLANs (using Ethertype 0x8100). If the user sends untagged traffic, it will arrive
at the NT board as a single-tagged frame and will be discarded.
• The NT board and the LT board behave as much as possible as two independent
Layer 2 systems. For example, they both will learn and age independently on
MAC addresses. Note that the ageing timer is independent in the NT board and
the LT boards but for proper operation it should be configured identical. There is
one ageing timer common for all LT boards. Note that in case of GPON and
XGS-PON / TWDM-PON, the term "LT" refers to the combination of the line card
plus the ONT, as shown in figure 200
Note — When a VPLS is used (for example, to support MPLS

pseudo-wires on the network side), the NT board is also able to
translate user VLANs.
Although the NT board is originally derived from a standard bridge, its behavior will
typically be constrained to fit access network requirements such as for instance
security and privacy. For that purpose the ISAM makes the distinction between ports
facing users and ports facing the EMAN network side:
• Ports connected to subtending ISAMs, to LT boards or directly facing users
instantiate the so-called “user side”. Such ports are considered untrusted.
• Ports connected to the EMAN or directly to service provider equipment (for
example, BRAS) instantiate the so-called “network side”. Such ports are
considered trusted.
With the notion of User side and Network side, the NT board has the capability to
deviate from a normal standard bridge in particular in term of controlling traffic
switching (or flooding) and controlling MAC address learning.

NT
In typical network deployment, the NT board will be constrained such that:

• Frames received from the network side (with pseudo-wire or direct VLAN
encapsulation) can be passed:
• back to the network side possibly on the same physical interface but using another
pseudo-wire or direct VLAN encapsulation (this is to support a ring).
• to the user side (an LT board, a user, or a subtending ISAM).
• Frames received from the user side (an LT board, a user or a subtending ISAM)
can only be passed to the network side.
Note 1 — The forwarding of broadcast frames or frames with

unknown (unicast / multicast) destination MAC address will be
based on these rules: flood to all allowed interfaces only.
Note 2 — The operator can enable communication from user
side back to user side provided that both users are on different
physical NT interfaces thereby allowing inter-LT traffic
forwarding. Up to 10 VLAN per NT can support communication
from user side back to user side.
Note 3 — The operator can enable communication from user
side back to the same user side (that is, the same LT board) for
the VLAN supporting communication from user side back to
user side. This system level provisioning command allows
intra-LT traffic forwarding. When this voice services feature is
used, the operator must also invoke secure-forwarding on the
LT (see “Secure forwarding in iBridge and VLAN
cross-connect”).
Obviously, when the network VLAN is directly mapped to an NSP, every NT bridge
instance operates within the context of a single distinct VLAN. Only tagged frames
matching the VLAN of a bridge will be handled by that bridge. If the frame is multiple
tagged, only the most exterior VLAN tag is used to determine whether the frame
should be handled by a given bridge or not.
When a frame is received from a pseudo-wire, it is the inner VC label that defines the
NT bridge instance.
Another strategy employed to enable ISAM to participate in a maximum of network
deployments scenarios is to subtend network elements (such as remote ISAM)
directly from the LT, as shown in Figure 202.

NT
Figure 202 Subtended network elements
UNI port
L2 Fwder
NSP A
L2 Fwder
NSP B UNI port
L2 Fwder LT
NSP A
L2 Fwder
NSP A
L2 Fwder L2 Fwder
L2 Fwder
NSP A
NSP B NSP A
L2 Fwder
L2 Fwder
NSP B L2 Fwder
NT NSP B
NSP B
LT
LT NT
ISAM Subtended ISAM
NNI port
The connection between the Hub ISAM and the subtended ISAM can be over an
Ethernet interface (optical, electrical), or alternatively, over a bonded copper
backhaul interface.
15.4.2 L2 forwarding on for VULA operations

The ISAM acting as a VULA node, also known as "handover ISAM" (see
section “ISAM support for VULA operations”) is an extension of the Hub ISAM
concept described in the previous paragraph where the network side interfaces are
hosted by a line card instead of the NT card. In this specific case the ISAM also
supports VLAN ports on its network interfaces hosted by a P2P Ethernet LT
operating in "uplink" mode.
In order to support this handover mode, another type of interface (next to the UNI and
NNI types) is needed, that is the so-called "uplink" mode. This "uplink" interface
provides an alternative to the network interface hosted by the NT card and
consequently, should provide similar features.
The VULA uplink interface hosted by an LT is characterized as follows:
• Hosted by an LT configured to operate in "uplink" mode, that is all interfaces
hosted by this LT will operate as "uplinks"
• Subscriber related protocol handling and security features is not performed at this
level since already done by the LT at the "downlink" interfaces.

NT
• Downstream SLA enforcement: since the uplink is used as handover interface to

the Content Providers, this is also the place where the traffic received from the
Content Providers will be checked to verity whether it complies with the
established SLA (priority settings, rate, …). The SLA can be enforced down to the
subscriber level (that is the S+C VLAN), so the ISAM can guarantee that each
subscriber can receive traffic according to its subscription (like for example the
committed rate guarantee). This fine grain SLA enforcement requires a large
amount of VLAN and QoS resources (each subscriber directly or indirectly
connected to the OLT needs to be identified and rate limited at the handover
interface)
• The uplink emulating a network interface of the NT, frames with unknown
destination MAC addresses are flooded. Additionally, link protection features like
link aggregation, dual homing / ring are also relevant for this type of interface
(though not all supported yet in this release)
As a consequence, an ISAM operating as a VULA node will host three levels of

forwarding:
• LT at the user side ("downlink LT"): same responsibilities as for the 2-stage model
• NT: the NT mostly behaves as it does for the 2-stage model except that the
"network side interface" (as seen from the NT) is not located anymore on one of
the visible NT ports (NT front plate or NTIO) but is now located on an internal
NT-LT interface (that is the backplane) towards the "uplink LT"
• LT at the network side ("uplink LT") with following responsibilities:
• Downstream SLA enforcement required when the ISAM is acting as a point of
handover towards the service providers
• Flexibility point allowing to convert the service provider VLAN addressing scheme
into the access network VLAN addressing scheme

NT
Figure 203 Three stage forwarding for ISAM operating as a VULA node
L2 Forwarder
From 3FQ-90082-0062-DTZZA
Phy Link
Vlan19
Downlink LT Phy Link

or LAG
or LAG
Uplink LT
L2 Fwdr
Vlan19
L2 Fwdr
Vlan19
L2 Fwdr
Vlan19 L2 Fwdr
Phy Link
L2 Forwarder
Vlan23
Phy Link or LAG

Vlan19
or LAG Uplink LT
L2 Fwdr
L2 Fwdr Vlan23
Vlan 23
L2 Fwdr
Vlan19
L2 Fwdr
L2 Fwdr
L2 Forwarder
Vlan47
Vlan 47
Vlan47
L2 Fwdr
Vlan47
ISAM NT
Downlink LT
ISAM
Logical view Actual Implementation
Though the ISAM operating in VULA mode is supporting all forwarding models from
a black box point of view, the actual forwarding at the uplink LT is currently simplified,
that is, all forwarders are internally converted into "transparent VLAN
cross-connects" by the uplink LT data plane. Practically speaking, this means that
the traffic received from the Content Providers is directly passed to the NT (after
potential VLAN/QoS manipulation) only based on the VLAN tag(s) without any other
forwarding processing, that is:
• There is no MAC learning and consequently, no MAC based forwarding and/or
limit
• There is no subscriber related protocol handling like DHCP, PPP, IGMP.
One can see the "VULA uplink" as a kind of NT interface enhanced with extra
QoS/VLAN features: the traffic is passed from the Content Provider to the NT card,
where the standard processing described in the previous paragraph applies again
(VLAN bridging, VLAN cross-connect, protocol handling, …)
• Ports connected to subtending ISAMs, to LT boards or directly facing users
instantiate the so-called “user side”. Such ports are considered untrusted.
• Ports connected to the EMAN or directly to service provider equipment (for
example, BRAS) instantiate the so-called “network side”. Such ports are
considered trusted.

NT
This current simplification of the uplink LT forwarding introduces the restriction that
a Content Provider cannot be connected through dual homed interfaces using L2
resilience techniques (dual homing or ring using MSTP or G.8032 ERPS).
Note — Dual homing or ring configurations are possible using
IP routing at the NT but this is in contradiction with the L2
paradigm defined by the VULA concept
15.4.3 Detailed configuration models
15.4.3.1 iBridge Configuration Model with Direct Network

VLAN Encapsulation
When the network VLAN is directly mapped to a given NSP, the NT makes use of a
special type of VPLS, the VLAN-VPLS (v-VPLS). The v-VPLS emulates the behavior
of a VLAN bridge. The main difference with a usual VPLS is that all Service Access
Points (SAPs) of a v-VPLS must be defined with the same VLAN ID, that is, the NSP
VLAN. Also, a v-VPLS is not able to support MPLS pseudo-wires.
Figure 204 iBridge with direct network VLAN encapsulation
RB
VLAN 19
Regular v-VPLS on v-VPLS Residential
Ports network VLAN SAPs Ports
RB
VLAN 23
v-VPLS LT
Phy VLAN 19
RB
Phy VLAN 19
v-VPLS
VLAN 23
RB
NT_IHUB VLAN 23
LT
ISAM_IHUB

NT
To configure a bridge for a given VLAN in the NT, the operator needs to:
• Create a v-VPLS operating in this VLAN
• Configure SAPs on this v-VPLS for each appropriate Regular or Residential port
15.4.3.2 VLAN Cross-connect Configuration Model with

Direct Network VLAN Encapsulation
The configuration of the NT board is the same as for the iBridge forwarding model,
only the configuration of the LT board is different, as shown in Figure 205.
Figure 205 VLAN Cross-connect with direct network VLAN encapsulation
C 11
v-VPLS C-VLAN CC
VLAN CC
VLAN 11
S17 +C23
v-VPLS S+C-VLAN CC
VLAN CC
VLAN 17
LT
(No VLAN translation
shown on user side)
v-VPLS S17 +C29

VLAN 13 S+C-VLAN CC
VLAN CC
S 13
v-VPLS S-VLAN CC
VLAN 19 VLAN CC
LT
NT
C-, S+C- or
ISAM S-VLAN CC
Note — The different types of VLAN cross-connect (C-VLAN,

S+C-VLAN and S-VLAN) are explained further in this chapter.

NT
15.4.3.3 iBridge or VLAN Cross-connect Configuration

Model with MPLS Pseudo-wire Encapsulation
When the MPLS pseudo-wire encapsulation is used on the network side, the NT
board needs to make use of a general VPLS. Figure 206 shows the case of a
wholesale access provider.
Figure 206 iBridging using with MPLS pseudo-wires towards the NSP
RB
Residential
VLAN 19
Network VPLS access
ports VPLS SAPs ports
RB
VLAN 23
VPLS LT
NSP_a
Phy PW NSP_a
MPLS tunnel
RB
NSP_b Phy VLAN 19
VPLS
Wholesale provider NSP_b
access point
RB
NT VLAN 23
Mapping of MPLS tunnel
on physical network port is LT
not shown
ISAM
Generally speaking, similar to the direct Network VLAN encapsulation, the iBridge
configuration model is applicable as well to the case of VLAN cross-connect except
for the LT configuration. The case of C-VLAN can however be optimized as shown
in section “VLAN Cross-connect Configuration Model with MPLS Pseudo-wire
Encapsulation and E-PIPE”.
Note — In general, it is not possible to combine an MPLS
pseudowire with another VLAN bridged or IP routed service on
the same physical port. However, starting from ISAM R5.2.01,
it is possible to configure an ISAM uplink port in "network mode"
for MPLS services, and also support PIM-SSM multicast
routing on the same port. In this model it is not needed to create
a separate VLAN or L2 SAP on the interface. In other words, an
IP routed IES service is configured but instead of having to
create a separate v-VPLS, the PIM-SSM routing is natively
supported on the uplink interface. In this model, the IES can
implicitly use the base L3 interface to forward multicast traffic.

NT
15.4.3.4 VLAN Cross-connect Configuration Model with

MPLS Pseudo-wire Encapsulation and E-PIPE
An alternative configuration model is possible for the C-VLAN and S-VLAN
cross-connect modes as shown in Figure 207. These cases make use of the E-PIPE
forwarder in the NT board.
Figure 207 C- and S-VLAN cross-connect with MPLS pseudo-wires and
E-PIPE
Residential
Network EPIPE access
EPIPE C-VLAN
ports SAPs ports
CC
VLAN 19
EPIPE LT
NSP_a
Phy PW NSP_a
MPLS tunnel
NSP_b Phy
EPIPE S-VLAN
Wholesale provider NSP_b CC
access point
VLAN 23
NT
Mapping of MPLS tunnel
on physical network port is LT
not shown
ISAM
15.4.3.5 Full Bridge Emulation for Business Customer

This is a special case of VPLS usage where an unrestricted L2 connectivity is
provided between business customers and with the network. Network access can be
realized by means of a pseudo-wire or by means of a direct Network VLAN
encapsulation. In this mode, both the user side and the network side are considered
equally trusted. In particular, there is no restriction for MAC address relearning in
contrary to the iBridge forwarding based on v-VPLS (see for instance section “MAC
address learning on the NT board”).

NT
Figure 208 Full Bridge emulation (direct Network VLAN encapsulation

shown)
LT 1
NT
VLAN-CC VLAN 1
DSL
VPLS VLAN x
LT n
VLAN-CC VLAN 2
VLAN-CC VLAN 3
DSL
15.4.3.6 Forwarding models and VULA uplink operations

As described in the previous paragraphs, a forwarder engine (bridge or VLAN-CC)
defined at ISAM level is instantiated at two stages, that is NT and LT levels. When
the ISAM operates as a VULA node, this needs to be extended with three stages,
that is LT uplink, NT and LT downlink.
The configuration for VULA uplink operations allows all forwarding models from an
ISAM black point of view, despite the following restrictions:
• NT can only forward traffic based on the outer VLAN
• LTs hosting NNI interfaces (like GE Ethernet and GPON/NG-PON2 LTs) do not
necessarily support S+C VLAN Ports and/or do not have the scalability to support
as many S+C VLANs as desired and consequently, the model should also support
NNI operating on the outer VLAN as the NT does.
There are two main scenarios:

• The uplink LT and downlink LT(s) support the requested black box forwarding
model. In this case, this LT forwarder model can be provisioned by the operator
as one command, taking into account the potential restrictions introduced by the
NT forwarding based on the outer VLAN.
• The uplink LT and downlink LT(s) either do not support directly the requested
black box forwarding model, or do not support it with the right scalability, or the
operator wants to minimize his provisioning work on some interfaces used for
aggregation purposes. In this case, the operator can program two different LT
forwarding models, that is one for the uplink LT and another one for the downlink,
for maximum flexibility. These two forwarders are combined together by sharing
at least the same outer VLAN tag at the NT level.

NT
Figure 209 Combining forwarders on uplink/downlink LTs for VULA

operations
l2fwder-vlan
Downlink LT NT Uplink LT
One forwarder S+C-FWD S-FWD S+C-FWD
Residential Port Regular Port

S+C-FWD
l2fwder-vlan
Downlink LT NT Uplink LT
Two forwarders S-FWD S-FWD S+C-FWD
Residential Port Regular Port

S+C-FWD
These combinations of uplink/downlink forwarders might be further extended with the

UNI/NNI forwarder combinations described in the previous paragraphs to obtain
even more advanced combinations.
Figure 210 Combining forwarders on uplink LT and UNI/NNI on downlink LTs for VULA
operations
Uplink LT NT Downlink LT
UNI S+ C UNI
S+ C S
NNI Zoom NNI
UNI S S+ C UNI
S+ C S+ C

NT
To summarize, following are allowed combinations of forwarders:

• Among downlink LTs
• The same forwarder can only be shared between downlink LTs whenever it is a
bridge.
• In some cases, an S-Forwarder (Bridge only) on an NNI can be combined with an
S+C forwarder on a UNI
Table 55 combinations of forwarder types among downlink LTs
Downlink
Downlink C-CC C-RB S+C-CC S+C-RB S-CC S-RB
C-CC No No No No No No
C-RB No Yes No No No No
S+C CC No No No No Yes Yes

S+C RB No No No Yes No Yes
S-CC No No No No No No
S-RB No No Yes Yes No Yes
• Among uplink and downlink LTs

• More combinations are allowed to cope with all possible scenarios described earlier
in this paragraph
Table 56 combinations of forwarder types among uplink and downlink

LTs
Uplink
Downlink C-CC C-RB S+C-CC S+C-RB S-CC S-RB
C-CC Yes No No No No No
C-RB No Yes No No No No
S+C CC No No Yes No Yes Yes
S+C RB No No No Yes No Yes
S-CC No No Yes No Yes No

S-RB No No Yes Yes No Yes
In order to achieve fine grain VLAN/QoS processing combined with a high scalability,
the 10GE Ethernet supports stacked VlanPorts on its interfaces, that is the VlanPort
is now defined by the combination of the S-VLAN and C-VLAN tags. When using a
stacked VlanPort, the VLAN/QoS processing now focuses on the S+C VLAN flow,
the C-VLAN tag becoming the reference for QoS operations.

NT
Following combinations of VlanPort / forwarder types are allowed on the VULA

uplink:
Table 57 combinations of VlanPort / forwarder types allowed on the VULA
uplink
Uplink Fwd
VLAN Port C-CC C-RB S+C-CC S+C-RB S-CC S-RB
C Yes Yes Yes Yes No No
S+C No No Yes Yes No No

S No No No No Yes Yes
15.5 Subscriber interface stack on the LT board

The ISAM can receive user frames from ATM PVCs (ADSL), EFM (VDSL), ONT UNI
or Ethernet Physical interfaces on the LT board.
15.5.1 Frame Encapsulation on PVCs

ATM PVCs are configured on top of the ATM-based DSL links. A maximum of eight
PVCs can be configured per DSL link. AAL5 is used to transport frames over ATM
PVCs.
When a frame is received on a PVC, the ISAM will try to determine whether the AAL5
frame carries:
• an IPoA frame
• a PPPoA frame
• an Ethernet frame
For this, the ISAM inspects the encapsulation of each received AAL5 frame and
compares it with the encapsulation allowed on the PVC receiving the frame.
The ISAM supports the following ATM AAL5 encapsulation types:
• LLC/SNAP bridged (Ethernet)
• VC Mux bridged (Ethernet)
• LLC/SNAP routed (IPoA)
• VC Mux routed (IPoA)
• LLC/NLPid (PPPoA)
• VC Mux PPP (PPPoA)

NT
The operator can configure each PVC in such a way that either:
• one single encapsulation only is allowed on the PVC. This is called static
encapsulation mode. Only the frames matching this encapsulation will be
accepted.
• several encapsulations are allowed on the PVC. In this case, the PVC works in
auto-detect encapsulation mode: the ISAM adapts itself to the encapsulation
selected by the CPE. If the encapsulation of the received frame matches one of
the allowed encapsulations, the frame is accepted. Otherwise, the frame is
discarded. This mode allows the subscriber to change his CPE without requiring
the operator to reconfigure the ISAM.
15.5.1.1 Auto-detect encapsulation possibilities

It is not possible to have a universal auto-detect function accommodating any frame
format without ambiguity. Hence, several auto-detect modes have been defined,
each one with a limited number of allowed encapsulations. When an operator wants
a PVC to work in auto-detect mode, he can configure the PVC with one of the
following modes:
• Autodetect_IP allows auto-detection of the following frame encapsulations:
• LLC-SNAP-Routed (then it is for IPoA) or
• LLC-SNAP-Bridge (then it is for IPoE) or
• VCMUX-Routed (then it is for IPoA)
Note 1: VCMUX-Bridge cannot be detected in this mode since it is ambiguous with
VCMUX-Routed when the IP address starts with 00 (hex)
Note 2: This autodetect mode is deprecated. Apart from an IP interface for IP aware
bridging (deprecated), no interface can be created on top of a PVC in Autodetect_IP
mode.
• Autodetect_PPP allows auto-detection of the following frame encapsulations:
• LLC-NLPID-PPP (then is for PPPoA) or
• VCMUX-PPP (then it is for PPPoA) or
• LLC-SNAP-Bridge (then it is for PPPoE) or
• VCMUX-Bridge (then it is for PPPoE)
• Autodetect_PPPoA allows auto-detection of the following frame encapsulations:
• VCMUX-PPP (then is for PPPoA)

NT
• Autodetect_IPoE_PPP allows auto-detection of the following frame

encapsulations:
• VCMUX-PPP (then is for PPPoA) or
• LLC-SNAP-Bridge (then it can be for PPPoE or IpoE) or
• VCMUX-Bridge (then it can be for PPPoE or IpoE)
Note 1 — Note: LLC-SNAP-Routed and VCMUX-Routed (that

is, for IPoA) cannot be detected in this mode.
Note 2 — The auto-detect feature is aimed to cope with
occasional CPE reconfiguration: when the ISAM detects a valid
change of encapsulation, it will clear data related to PPP or
DHCP sessions related to this PVC, if any is present. Also, it is
possible that a few frames are lost during the transition.
15.5.2 Attaching subscribers to iBridges and VLAN

cross-connect forwarders
VLAN ports are always used to attach subscribers to iBridges and VLAN
cross-connect, as shown in Figure 211.
This obviously applies to tagged Ethernet frames, but also to untagged Ethernet
frames, via Port Default VLAN (PVID) and even to IPoA frames via the so-called
Interworking Layer (IWL) located on the LT board. The IWL takes care to convert
IPoA frames into IPoE frames; see section “Protocol-aware cross-connect mode” for
more information.
Figure 211 shows the subscriber access interface model.
Figure 211 Subscriber access interface model for iBridges and VLAN
cross-connect
Of frame tag or
Managed
VLAN port PVID if untagged VLAN port (from PVID) by IWL
frame
Bridge port Bridge port
PVC EFM UNI PVC
ATM ONT ATM
ADSLx VDSLx Eth Phy PON ADSLx
PPPoE or IPoE IPoA

Frames Frames

NT
15.5.3 Support for Jumbo Frames

To take care of various encapsulation protocols overhead, Jumbo frames with 2048
bytes are supported in the data plane all over the ISAM, including all forwarding
modes (iBridge, VLAN cross-connect, PPP cross-connect, VRF) and all Ethernet
interface types. However, the final frame size will be constrained by the LT hardware
limitation (the hardware of some LT boards cannot support more than 1580 bytes).
This requirement is to allow some room to add protocol overhead to upstream user
frames, in function of the forwarder used.
Note — The requirements for large MTU do not make a

distinction between the network and the user side. Of course,
frames from the user side which are for instance encapsulated
with MPLS should be smaller than the allowed maximum.
Figure 212 Support for Jumbo frames
3, 4
DSL line
Ethernet MAC larger subscriber Ethernet payload
specific
DA, SA,
SA Qtags, Type/Length, FCS
Edge
1 2 3, 4
MPLS & larger subscriber Ethernet payload
Ethernet MAC (with additional VLAN tags)
other blue sky
DA, SA, Qtags, type/length, FCS
Scope of jumbo frames:

1. To cope with more VLAN tags being added on network side
2. To cope with additional encapsulating protocols, for example, MPLS on network side
3. To cope with user having larger payload data
4. NOT to cope with user having larger payload control
Note 1 — NT supports jumbo frames up to 9216 bytes

(including Ethernet FCS) for data plane traffic.
Note 2 — For information of Ethernet frame size supported on
different LTs, please refer to Table "Ethernet Frame Size for
different LT boards" in ISAM FX Product Information Manual.
15.6 iBridges
For the sake of clarity, this section only considers the case of network VLAN
encapsulation directly mapped to NSP. This discussion can however be generalized
to the cases where MPLS pseudo-wire encapsulation is used instead.

NT
In alignment with customer-evolving deployment models, the ISAM platform also

supports a stacked VLAN iBridge mode in addition to the original single tagged
network VLAN. The ISAM with a stacked VLAN iBridge mode can perform bridging
operations and can also add/remove a VLAN header to the customer upstream /
downstream traffic. This allows support of different broadband access solutions.
Examples of use cases for stacked VLAN iBridge mode:
• The outer-tag (S-TAG) represents the NSP, while the inner-tag (C-TAG)
represents the NSP-Service; or
• The outer-tag (S-TAG) represents the AN PON port, while the inner-tag (C-TAG)
represents an NSP-Service for a specific user; or
• The outer-tag (S-TAG) represents the AN PON port, while the inner-tag (C-TAG)
represents the end-customer ONT.
A stacked VLAN iBridge is considered to be a VLAN aware bridge, where each N:1
VLAN (S-Bridge) is a separate Virtual Bridge (VB) instance. Each VB performs
independent source MAC address learning and frame forwarding processing.
The ISAM with a stacked VLAN iBridge offers two modes of operations:
• S+C iBridge; and
• S-iBridge
The S+C iBridge mode allows C-VLAN tag operations, such as C-VLAN translation,
in addition to adding/removing an S-VLAN header. This forwarding mode requires
the operator to configure a VLAN port for each C-VLAN.
The S-iBridge mode supports two sub-modes of operation:
• S-Tunnel iBridge mode
• S-VLAN mapped mode.
The S-Tunnel iBridge mode allows the operator to minimize provisioning by creating
a tunnel VLAN port on a specific bridge port. On this bridge port all tagged / untagged
customer frames which match the tunnel VLAN port are encapsulated by an S-VLAN
header.

NT
The S-VLAN mapped mode is used on Hub-ISAM NNI ports. See “VLAN tagging
modes in the iBridge (Hub-ISAM LT NNI ports concept)” for further details.
Note 1 — The GPON, XGS-PON / TWDM-PON and P2P
Ethernet LTs allow the same S-VLAN ID to be shared between
an S-iBridge and S+C iBridge or S+C cross-connect. For other
interfaces, S-VLAN ID cannot be shared between S+C iBridge
and S- iBridge.
Note 2 — The S-tunnel iBridge mode is currently supported on
GPON access solutions. It is also supported on the NNI ports
of the Ethernet LTs. It is currently not supported on the
XGS-PON / TWDM-PON access solution.
Note 3 — The S-VLAN mapped mode is supported on the NNI
ports of the GPON, XGS-PON / TWDM-PON, GE/10GE
Ethernet LTs, on the NNI ports of LTs supporting bonded
copper backhaul and on the VULA uplinks.
15.6.1 General considerations on iBridges

This section describes the general considerations on iBridges including information
about DHCP option 82, network and subscriber sides, prevention of broadcast
problems, multicast protocols forwarding control, IPv4, IPv6, Ethernet, and Protocol
specific multicast traffic control, upstream frame types accepted, and deployment.
15.6.1.1 DHCP option 82

iBridge supports the DHCP snooping features for DHCP Option 82 handling.
Likewise, iBridge supports DHCPv6 snooping for the insertion of DHCPv6 Option 18
and Option 37. For more information on DHCP, see chapter “Protocol handling in a
Layer 2 forwarding model” and chapter “Protocol handling in a Layer 3 forwarding
model”.
Note 1 — DHCP option 82 is not supported on traffic received
on hub-ISAM NNI ports for the GE Ethernet LT. The remote
aggregator access node (connected to the hub-ISAM) will
perform such function if required.
Note 2 — DHCP option 82 is supported on Hub-ISAM NNI ports
of LTs supporting bonded copper backhaul and 10 GE LTs.
This functionality is only intended to be enabled in the context
of zero-touch provisioning (ZTP), in the scope of the
management VLAN of the subtended ISAM.

NT
15.6.1.2 Network side and subscriber side

The iBridge and stacked iBridge mode make a distinction between network ports and
subscriber ports, in contrast with standard bridging where all ports are treated
equally. Frames received from a subscriber will always be sent towards the network
and never to another subscriber.
Note 1 — The ability to allow subscriber-to -subscriber traffic is
configurable on the NT.
Note 2 — For GPON and XGS-PON / TWDM-PON access, it is
not recommended to configure subscriber-to-subscriber traffic
switching in conjunction with allowing downstream network
broadcast (see “Prevention of broadcast problems”).
This behavior is also true when the iBridge mode is used to forward traffic from
Hub-ISAM LT NNI ports: All upstream traffic will be sent towards the network and
never to another NNI port.
15.6.1.3 Prevention of broadcast problems

To prevent broadcast storms, the amount of broadcast traffic on each port can be
controlled.
When standard bridging is used, a broadcast frame (ARP, PPPoE, DHCP, ICMPv6
or DHCPv6) will be sent to all ports in a particular VLAN. In iBridge mode, broadcast
traffic from the subscriber only goes to the network. Broadcast traffic from the
network is either passed to all ports or blocked on the subscriber ports. This behavior
can be configured per VLAN.

NT
Note however that broadcast traffic is always forwarded to NNI interfaces

independent of that configuration option.
Note 1 — This behavior is also true for stacked iBridge modes.
Note 2 — For GPON and XGS-PON / TWDM-PON access,

when configured to do so, the broadcast frames from the
network will be broadcasted to all users. There are two modes
available for sending the broadcast:
• Mode 1. The broadcast packet is transmitted on via a
dedicated transport channel, the so-called “incidental
broadcast GEM port” (see G.984.4, 12-2008).
This normally does not require replication of the packet.
However, in the case that VLAN translation is performed by
the LT, it will be necessary to replicate the packet for each
unique user-side C-VLAN.
• Mode 2. The broadcast packet is replicated for each
member port of the VLAN, with each copy of the packet
being transmitted on a dedicated GEM port belonging to a
member port.
A configurable option exists at the forwarder level to select

between these two modes, with use of the incidental broadcast
GEM port being the default. In both modes, the broadcast traffic
is placed on the dedicated incidental broadcast/multicast
queue on the PON. It is possible to configure a shaper on this
queue so that incidental broadcast/multicast traffic can be rate
limited.
Also broadcast as a consequence of flooding, which happens with standard bridging

when the MAC DA is unknown is typically not done towards the subscriber side.
In context of Hub-ISAM LT NNI ports, all NNI upstream broadcast traffic will be sent
towards the network and never to another NNI port. Broadcast from the network is
passed to all NNI ports. This behavior is not configurable for NNI ports.
Downstream unicast traffic is also passed to all NNI ports when the MAC DA is
unknown. Again, this behavior is not configurable.
15.6.1.4 Multicast Protocols forwarding control

In context of GPON and XGS-PON / TWDM-PON access solutions and 10GE
Ethernet LT UNI, to take full advantage of the point to multi-point topology of the
GPON network, the iBridge mode does support multicast forwarding optimization.
Configured on a per VLAN basis, multicast traffic (from the network to the subscriber
port and from the subscriber port to the network) is either passed to all ports or
blocked on the subscriber ports, depending on the type of multicast traffic. (Here we
discuss the 'incidental' multicast traffic, for example related to certain protocols,
rather than the multicast video traffic which is typically controlled via IGMP). When

NT
configured to do so, the multicast frames from the network will be broadcasted to all
users. As for the handling of broadcast packets (see “Prevention of broadcast
problems”), there are the two modes available: using the incidental broadcast GEM
port, or using the dedicated GEM port of each member port in the VLAN. As for the
broadcast traffic, the multicast traffic is placed on the dedicated incidental
broadcast/multicast queue on the PON, and there exists the option to shape this
queue.
The following different multicast protocols forwarding controls are possible:
• Allow, upstream and downstream, IPv4 multicast traffic on user ports
• Allow, upstream and downstream, IPv6 multicast traffic on user ports
• Allow, upstream and downstream, Ethernet multicast traffic on user ports
• Allow, upstream and downstream, Protocols specific multicast traffic on user ports
Note — For stacked iBridge forwarding modes, all multicast

protocol forwarding controls are based on the S-VLAN iBridge.
Therefore, in case of an S+C iBridge mode, all C-VLAN vlan
ports will have a unique common behavior inherited from the
parent S-VLAN ibridge.
15.6.1.5 IPv4 multicast traffic control

This feature allows upstream multicast IPv4 traffic, and flood downstream IPv4
multicast traffic. The frames that are affected are in the following MAC address
range: Dest MAC: 01-00-5E-00-00-00 to 01-00-5E-7F-FF-FF, insofar there is no
IGMP managed tree, see chapter “Multicast and IGMP”.
Note — Protocol Specific Multicast traffic control offers a more
granular control for some specific multicast frames. See
“Protocol Specific Multicast traffic control”
This control is ignored for NNI ports, in which case the behavior depends on whether
there is any multicast VLAN configured on the NNI port. If no multicast VLAN is
configured, then IPv4 multicast traffic will be forwarded. If a multicast VLAN is
configured, then IPv4 multicast traffic will be forwarded according to the multicast
tree structure (i.e. if the corresponding multicast stream has been joined on the NNI
port). Note however that group addresses in the range 224.0.0.0/24 will always be
forwarded.
15.6.1.6 IPv6 multicast traffic control

This feature allows upstream multicast IPv6 traffic, and flood downstream IPv6
multicast traffic. The frames that are affected are in the following MAC address
range: dest MAC: 33-33-00-00-00-00 to 33-33-FF-FF-FF-FF.

NT
This control is ignored for NNI ports where IPv6 multicast traffic is always forwarded.
15.6.1.7 Ethernet multicast traffic control

This feature results in flooding downstream Ethernet multicast traffic. The frames that
are affected are frames with the lowest significant bit set to 1. Example of these
frames are L2 IS-IS frames.
Note — This feature will not affect Broadcast, L2 Control
Protocol, IPv4 Multicast and IPv6 Multicast frames.
This control is ignored for NNI ports where Ethernet multicast traffic is always
forwarded.
15.6.1.8 Protocol Specific Multicast traffic control

This feature allows upstream protocol specific multicast traffic, and flood
downstream protocol specific multicast traffic. The following specific Multicast
protocols supported are:
• NTP multicast protocol frames using the IPv4 multicast frame format
• RIP multicast protocol frames using IPv4 multicast frame format.
Note — When the Protocols Specific Multicast control is not

enabled, the forwarding behaviors of all IPv4 Protocol multicast
frames are controlled as per “IPv4 multicast traffic control”.
This control is ignored for NNI ports where protocol specific multicast traffic is always
forwarded.

NT
15.6.1.9 Upstream Frame types accepted by iBridges

In iBridge mode, only the following frame types are accepted from the subscriber
ports:
• IP over Ethernet (IPoE) (IPv4)/ARP/Reverse Address Resolution Protocol
(RARP)
• IPv6 over Ethernet (IPv6oE), including Neighbor Discovery and ICMPv6
Note — Neighbor Discovery and ICMPv6 are identified by a
Next Header value of 58 in the immediately preceding IPv6
header
• PPPoE (discovery and session)

• PPPoE relay
• IPoE (IPv4)/ARP/RARP/PPPoE (discovery and session)
• IPoA (per enhanced iBridge) (for IPv4 only)
• all Ethernet types
• Extensible Authentication Protocol Over LAN (EAPOL):
EAPOL frames are dedicated packets that are never forwarded but are processed
by the ISAM.
Other upstream frames, including multicast data frames, will be discarded (see
section “Protocol Specific Multicast traffic control” on multicast traffic control).
In the context of hub-ISAM LT NNI ports, in iBridge mode, only the following frame
types are accepted from the NNI ports:
• IP over Ethernet (IPoE) (IPv4)/ARP/Reverse Address Resolution Protocol
(RARP)
• IPv6 over Ethernet (IPv6oE)
• PPPoE
• all Ethernet types
Other frames, including multicast data frames, will be sent towards the network and
never to another NNI port.
15.6.1.10 iBridge Deployment

In iBridge mode, the operator will avoid putting two ISAMs within the same network
VLAN on the same Ethernet Metropolitan Area Network (EMAN) to reach the same
NSP IP router.

NT
Sharing the same VLAN between two ISAMs would allow inter-ISAM user-to-user
traffic to by-pass the NSP, which is undesirable. Figure 213 details this scenario:
• The Ethernet switch will learn all subscriber MAC addresses. If subscriber A can
obtain the MAC address of subscriber C, then subscriber A can send traffic
directly to subscriber C without the traffic going to the NSP IP router. This is direct
user-to-user communication and should be prevented in iBridge mode.
• In such a configuration, an ISAM would receive all broadcast/flooded frames from
any ISAM in the VLAN. This causes potential performance problems and should
not be allowed in iBridge mode.
Figure 213 VLAN with two ISAMs

ISAM 1
A
EMAN
B VLAN
NSP
Not allowed NSP IP backbone
ISAM 2
An operator may still choose to deploy such a configuration for VLAN scalability
reasons. In these scenario's care must be taken to prevent undesirable user-to-user
traffic by:
• enabling split horizon functionality in aggregation network, or
• enable vMAC on ISAMs and use vMAC filters at the ISAM to discard ingress
network traffic with vMAC source addresses.
15.6.1.11 Hub-ISAM LT NNI iBridge deployment example

As described in “L2 forwarding on the NT board and the LT boards”, the ISAM
supports the ability to subtend network elements (such as remote ISAM) directly from
the LT. This is done by using the NNI port type on the GE or 10GE Ethernet LT,
GPON or XGS-PON / TWDM-PON LT or on an LT supporting bonded copper
backhaul.
As shown in Figure 214, by using the iBridge mode on the NNI ports, the operator
can leverage the Hub-ISAM access aggregation capabilities in order to aggregate
traffic towards the EMAN network.

NT
Figure 214 Hub-ISAM with iBridge

E
UNI
F
UNI
A
UNI
S-ISAM 1
NNI
NSP IP B
EMAN
Backbone UNI
C
UNI
S-ISAM 1
NNI
D
UNI
Hub-ISAM Remote Aggregator

(subtended ISAM)
Note — The Hub-ISAM can also perform local access and

access aggregation, as shown in Figure 214.
15.6.2 MAC learning

In the ISAM, each layer 2 forwarder has its own MAC learning process, independent
from the other layer 2 forwarders. In other words, the text in the section below has to
be understood “within the same network VLAN context”. This means that a MAC
address is unique within a VLAN, but not across VLANs. If a port is connected to two
VLANs, the MAC address is learned twice.

NT
15.6.2.1 MAC address learning on the NT board

When a frame is received with an unknown MAC Source Address (SA) or the MAC
SA is received on a different bridge port than previously learned, the ISAM will learn
this MAC address with the following restrictions:
• If the MAC address is learned from a residential (user) port but the number of
MAC addresses already learned on that service has reached a certain maximum,
the MAC address is not learned and the frame is dropped.
Note — The MAC learning mechanism can be disabled to
allow, for example, an unlimited number of MAC addresses in
case of cross-connect mode.
• If the MAC address is learned from a residential port, but the same MAC address
is already learned from the EMAN network, the MAC address is not learned and
the frame is dropped (MAC address duplication).
• If the MAC address is learned from a residential port, but the same MAC address
was already on another residential port, the new MAC address is not learned and
the frame is dropped (MAC address duplication).
• If the MAC address is first learned on a residential port, and then learned from the
EMAN network, this movement is accepted and the MAC address is learned. This
means that the MAC address is removed from the residential port (MAC address
movement, that is, the last learned MAC address takes priority).
• If the MAC address is first learned on a subtending, user or internal LT port and
then on another subtending, residential or internal LT port, then the MAC address
is not learned on the second port (that is, no MAC address movement is
performed)
• Well-known MAC addresses (for example, multicast MAC addresses, MAC
addresses allocated for IEEE protocols, and so on) are not learned.
These principles apply also for subtending ports. In this context, a subtending port
behaves at the same level as a residential (user) port.
15.6.2.2 MAC address learning on the LT board

The ISAM LT boards provide a protection about the maximum number of MAC
addresses that can be learned per port:
• On ATM-based interfaces, the limit is applied per PVC.
• On PTM-based DSL interfaces and Ethernet physical interfaces and ONT UNI,
the limit is applied per interface.

NT
The way this protection is implemented depends on the LT board type:

• On layer 2+ and point-to-point Ethernet HC-UNI LT boards, this protection allows
the operator to configure a maximum per port and this maximum is also
committed. On NNI interfaces, the maximum number of MAC addresses is not
committed.
• On layer 3 boards (including NNI ports on layer 3 LT boards supporting bonded
copper backhaul), point-to-point Ethernet UNI and GPON/ONT LT boards, this
protection allows the operator to work with overbooking. The operator can
configure a maximum per port and a committed number per port.
• Additionally, for the GPON ONT, it is possible to configure a limit per VLAN port.
In this case, the limit on the ONT UNI is also applied. That means a MAC address
will only be learned if the limit has not been exceeded on the VLAN port AND the
limit has not been exceeded on the UNI.
• Additionally, for Layer 3 DSL LT boards (including NNI ports on layer 3 LT boards
supporting bonded copper backhaul), it is possible to configure a limit per VLAN
port. In this case, the limit on the DSL line is also applied. That means that a MAC
address will only be learned if the limit has not been exceeded on the VLAN port
AND the limit has not been exceeded on the DSL port. Additionally it is also
possible to enable or disable MAC learning per VLAN port for VLAN
cross-connects.
GE Ethernet LT UNI, HC-UNI and 10GE LT NNI also support MAC learning and
its associated limit of MAC addresses per VLAN port.
Note however that the MAC address allocation process slightly differs on HC-UNI
interfaces:
• Limit per VLAN port is only supported for VLAN-CC. The VLAN ports associated with
bridges share the same MAC address pool, upper bounded by the limit per port.
• Limit per VLAN port cannot be overbooked, that is, the sum of all VLAN Port limits
must be smaller or equal to the port limit.
• The MAC pool size used by the VLAN ports associated with bridges is defined as the
bridge port limit - sum of VLAN port limits.
The committed number of MAC addresses per port is the number of entries reserved
in the forwarding database for that port(not supported by Ethernet GE LT HC-UNI
and NNI ports). This number of entries can be used by the subscriber connected to
that port at all times, that is, independent of any activity of other subscribers. Note
that, for GPON, the committed number of MAC addresses can only be configured at
the UNI level, not at the VLAN port level.
However, if not all the available entries on an LT board have been assigned to a port,
then the remaining entries are dynamically assigned to ports based on MAC address
learning with the protection that the total number of entries per port cannot exceed
the configured maximum number of MAC entries per port.
The ISAM LT boards also provide protection against duplicate MAC addresses in the
VLAN context of the forwarder.

NT
When a frame is received on a subscriber port with a source MAC address which was
already learned on another port for this VLAN, this generates a duplicate MAC
address alarm and:
• On layer 2 LT boards, the frame is discarded and the MAC address is not moved
from the original port. Moreover, the offending end-subscriber PVC gets locked.
The subscriber port is unlocked again (and the duplicate MAC address alarm is
cleared) after a time period equal to three times the MAC address aging time.
• On layer 3, point-to-point Ethernet, GPON/ONT and XGS-PON /
TWDM-PON/ONT LT boards, the frame is discarded and the MAC address is not
moved from the original port. The port carrying the offending frame remains fully
operational for frames received with non-offending source MAC address. The
alarm is cleared after a time period free of MAC address conflict.
• As such, the MAC address learning and the associated duplicate MAC address
alarming does apply to UNI and NNI ISAM LT ports with the same level of
precedence between the two port types.
The GPON LT also supports enabling of MAC movement within the same LT.
Enabling or disabling of MAC movement can be configured per iBridge, with the
default being 'disabled'. The feature is useful to allow a wireless device to move from
one UNI to another within a Wi-Fi 'hot spot'. MAC movement is not permitted
between LTs. Movement is only permitted for dynamically learned MAC addresses,
statically configured MAC addresses are not permitted to move. When MAC
movement is performed, the MAC address is deleted from the old port and relearned
on the new port. In this case no duplicate MAC alarm is raised.
Note — MAC addresses are never learned for VLAN
cross-connects configured on NNI ports of the GE Ethernet LT,
and this independently of the MAC learning mode defined at the
interface level.
Consequently, the maximum amount of MACaddresses that
may be learned per GE Ethernet LT NNI port is only applied for
the iBridge forwarders.
15.6.2.3 MAC aging time

A MAC address that was previously learned on a given L2 forwarder is automatically
removed from the MAC forwarding table of that L2 forwarder when no traffic has
been received from that MAC address during the MAC aging time.

NT
It is important that the MAC aging time is properly configured, otherwise data-plane
connectivity may get lost between the network and the ISAM subscribers (due to the
fact that traffic is not flooded to these subscribers when their MAC address is no
longer present in the forwarding database):
• For PPPoE traffic, the MAC aging time can be kept small, because PPP has a
built-in keep-alive mechanism.
• For DHCP-based service scenarios (IPv4 or IPv6), the MAC aging time must be
taken in the same order of magnitude as the DHCP lease time (unless there is
another time that can be used, for example, an ARP refresh interval with secure
forwarding and ARP relay enabled, an application-layer keep-alive time, and so
on).
The MAC aging time is configurable between 10 s and 1.000.000 s with a default
value of 300 s.
Note — On layer 2 LT boards, the MAC aging time is limited to

a maximum of 1096 s by the hardware. In that case, the
management interface allows the operator to configure a higher
aging time, but the hardware caps this configured value to 1096
s.
A MAC aging time can be configured per L2 forwarding instance as for some services
the MAC aging time should be kept low, while for other services (for example,
DHCP-based services) the MAC aging time should be increased.
15.6.3 Ingress Frame Handling: which Forwarder and

which Frame Tag Manipulation?
This section will address the following two questions in more detail:
• To which L2 forwarder should an ingress frame be passed (or discarded)?
• Which manipulations should be done on the ingress frame VLAN tag(s)?
For both questions the answer resides in the configuration of VLAN ports on the
receive bridge port.
15.6.3.1 Finding out the right L2 forwarder for an Ingress

Frame
As we know from section “Generic L2 Forwarder”, VLAN ports are the means for the
iBridge to know
• in ingress which frames it should be concerned with.
• in egress to which user/ethernet network link it should pass a frame

NT
Let's focus on the ingress direction.

Finding out which forwarder should accept an ingress frame is done by finding out
which VLAN port on the bridge port should pick-up the frame. In figurative terms, “the
VLAN port catches the ingress frame”.
Once the VLAN port in charge is identified, the frame will be processed by the iBridge
or VLAN cross-connect which is attached to this VLAN port.
Note — For completeness: it is possible - although atypical - to

create a VLAN port which is not attached to an iBridge nor to a
VLAN CC. This can be for instance when the VLAN port is
exclusively destined to create a PPP CC client port.
Figure 215 shows the flowchart which provides the formal details about this process.
Figure 215 Finding out the right L2 forwarder for an Ingress Frame
Exists a PVID Do as if Frame
Frame is
Untagged or applicable was tagged with
received on Process frame
Frame ? ProtoVID on BrPort:PVID or Frame Dual-tags
BridgePort Dual-tag by the Dual-tag
Bridgeport ? BrPort:ProtoVID matching a Dual-tagged
Frame ? iBridge/VlanCC
VlanPort on Bridgeport ?
pointed by Vlanport
Discard Frame
Process frame
Frame Outer-tag
by the Single-tag
Matching a Single-tagged
iBridge/VlanCC
VlanPort on BridgePort?
pointed by Vlanport
Discard Frame
? yes
Process frame
Frame Outer-tag
no Single-tag by the Single-tag
Matching a Single-tagged
Frame ? iBridge/VlanCC
VlanPort on BridgePort?
pointed by Vlanport
Discard Frame
The important thing to note in this figure is that in a dual-tagged frame - say with
(100,17) - would match both a dual-tag VLAN port (100,17) and a single-tag VLAN
port (100). The rule is that the dual-tag VLAN port is the only one to consider for this
frame because it is a better match.
15.6.3.2 Manipulations on the VLAN Tag(s) of an ingress

frame
Business in ingress always boils down to matching the received frame outer tag(s)
with the network VLAN ID of the L2 forwarder.
In practice, if the frame VLAN tag is not identical to the L2 forwarder VLAN ID (i.e.
the one used on the network side) the ingress frame will need to have its outer tag
replaced by another tag or even possibly get an additional outer tag. For both cases,
one liberally uses the term “VLAN Translation”.

NT
Since the VLAN port is at the junction between the external world and the L2
forwarder, it is the VLAN port configuration data which will drive this process. In
figurative terms, “the VLAN port makes the frame fit to the L2 forwarder
environment”.
Of course, the reverse process is done on egress.
Figure 216 illustrates several examples of VLAN tag manipulations on user iBridge
interfaces in ISAM. Remember the following when looking at the figure:
• PVID configuration is systematically indicated but it is optional
• Protocol VID are optional and not indicated in the figure
• PVID and Protocol VID can coexist on the same bridge port
• The figure illustrates one VLAN port per subscriber. Of course, several VLAN
ports could belong to the same subscriber.
Figure 216 Possible Manipulations on Frames VLAN Tag by VLAN ports

VlanPorts
Ut, Data Untagged frame

VlanId - Is accepted only if
(11) 11, *, Data optional PVID is configured
i-Bridge VlanId (11)
Ut, Data
PVID 11, *, Data A frame with
NetVlan (11) 11, *, Data FDB11
21, *, Data - OuterTag = 11
Tr VlanId (21) - no or any number of
Ut, Data
PVID InnerTag of any value
VlanId Single-tag VlanPort for “VlanId”

(31,12) 12, *, Data with no tag manipulation
i-Bridge + VlanId (12)
- Ut, Data
PVID
NetVlan (31,12) 31, 12, *, Data d FDB31,12 Tr Single-Tag VlanPort for “VlanId”
21, *, Data with Vlan translation
+- Tr VlanId (21)
PVID Ut, Data
+- Single-Tag VlanPort for “VlanId”
with upstr_add/dwnstr_removal
VlanId of extra tag
(31,13) i-Bridge + VlanId (13) 13, *, Data Single-Tag VlanPort for “VlanId”
- Ut, Data
Tr
PVID with Vlan translation and
NetVlan (31,13) 31, 13, *, Data d FDB31,13 with upstr_add/dwnstr_removal
+- 17, *, Data of extra tag
Tr VlanId (17)
PVID Ut, Data
Dual-tag VlanPort for “VlanId”
d with no tag manipulation
(No VlanPort) 666, *, Data
• Phy lines and BridgePorts not Legend

shown
• ProtocolVID not shown
Note — To avoid figure overload, bridge ports are not

indicated. Note that if two VLAN ports have the same VLAN ID
(cfr. “21” in the figure), by definition they must relate to distinct
bridge ports.

NT
15.6.4 VLAN tagging modes in the iBridge
15.6.4.1 Forwarding of untagged/priority-tagged frames

received from the subscriber
Figure 217 Forwarding untagged/priority-tagged frames in an iBridge
(iBridge shown with only one subscriber)
Network-side Configured VLAN
User-side traffic
traffic ports
Bridge port BP1
Ut,C1 VLAN port (BP1/ 0,C1)

iBridge (C1) Ut,Ut
BP1:PVID = 0,C1
Si,X (any i) or
Ut,Cj (j ≠ 1)
Legend for traffic characterization:

Ut,C1 means S-VLAN = untagged and C-VLAN = C1
S1,X means S-VLAN = S1 and C-VLAN = do not care (tagged or untagged)
Ut,Ut means no S-VLAN, no C-VLAN
Legend for VLAN port configuration:
0,C1 means a C-VLAN port
S1,0 means an S-VLAN port

NT
Figure 218 Protocol-based VLAN selection (iBridge shown with only one
subscriber)
User-side traffic
traffic ports
Bridge port BP1

iBridge (C1) Ut,Ut
BP1: IPoE VID = 0,C1

Ut,C2 PPPoE VID = 0,C2
iBridge (C2) VLAN port (BP1/ 0,C2)
Si,X (any i) or
Ut,Cj (j ≠ 1,2)

S1,0 means an S-VLAN port
Note — The behavior described in this section is also true

when the iBridge mode is used to forward traffic from
Hub-ISAM LT NNI ports.

NT
15.6.4.2 Forwarding of C-VLAN tagged frames

The ISAM receives C-VLAN-tagged frames on a given bridge port, and forwards
these in the context of an iBridge. To achieve this, the operator creates a C-VLAN
port on top of the bridge port, and couples it to the iBridge.
• When no VLAN translation is needed, the VLANs used in the network are
extended all the way to the subscribers. In this case, the subscriber side VLAN
IDs are said to have a network-wide scope; see Figure 219.
Note — The behavior described in this section is also true
when the iBridge mode is used to forward traffic from
Hub-ISAM LT NNI ports.
• In case of VLAN translation, the network-side and subscriber-side VLAN IDs are
different. iBridging, in combination with VLAN translation, is typically used when a
loose coupling is needed between the C-VLAN IDs used on the access link and
the C-VLAN IDs used in the aggregation network; see Figure 220.
Figure 219 Subscriber-side VLAN-IDs with a network-wide scope (iBridge

shown with only one subscriber)
User-side traffic
traffic ports
Bridge port BP1

iBridge (C1) Ut,C1

iBridge (C2) Ut,C2
BP1: no PVID
Si,X (any i) or
Ut,Cj (j ≠ 1,2) or
Ut,Ut


NT
Figure 220 Support for VLAN translation (iBridge shown with only one
subscriber)
User-side traffic
traffic ports
Bridge port BP1

iBridge (C1) T Ut,C3

iBridge (C2) T Ut,C4
BP1: no PVID
Si,X (any i) or
Ut,Cj (j ≠ 3,4) or
Ut,Ut

Note — In case of GPON and XGS-PON / TWDM-PON

access, there are two alternative modes for VLAN translation:
ONT based translation and ISAM based translation, as
explained in “L2 forwarding on the NT board and the LT
boards”.
15.6.5 VLAN tagging modes in the stacked iBridge modes

Section “VLAN tagging modes in the iBridge” explained VLAN tagging modes in the
iBridge for normal ISAM LT bridge ports.
This section focuses on VLAN tagging modes in the stacked iBridge mode.
15.6.5.1 Concepts
The concepts of Bridge Ports and VLAN ports defined on the subscriber side and
used by iBridges and VLAN cross-connects are also valid for stacked iBridge modes.

NT
Two stacked iBridge modes are currently supported:

• S+C iBridge
• S-iBridge
The S+C iBridge mode allows C-VLAN tag operations, such as C-VLAN translation,
in addition to adding/removing an S-VLAN header. This forwarding mode requires
the operator to configure a VLAN Port for each C-VLAN.
The S-iBridge mode supports two sub-modes of operation:
• S-Tunnel iBridge mode
• S-VLAN mapped mode.
The S-Tunnel iBridge mode allows the operator to minimize provisioning by creating
a tunnel VLAN port on a specific bridge port. On this bridge port all tagged/ untagged
customer frames which match the tunnel VLAN port are encapsulated by an S-VLAN
header.
The S-VLAN mapped mode is used on Hub-ISAM NNI ports. See “VLAN tagging
modes in the iBridge (Hub-ISAM LT NNI ports concept)” for further details.
15.6.5.2 Forwarding of untagged/priority-tagged/VLAN

tagged frames in S+C iBridge
The forwarding behaviors described in Section “VLAN tagging modes in the iBridge”
are mostly also pertinent for the operations of an S+C iBridge forwarding model.
Therefore, the S+C iBridge supports forwarding of untagged / priority-tagged and
VLAN-tagged customer frames.
• Forwarding of untagged / priority-tagged customer frames requires the
configuration of the PVID.
• Forwarding of tagged customer frames requires the configuration of a VLAN port.
The main difference is that an S+C iBridge offers the ability of VLAN stacking (see
section “C-VLAN cross-connect (basic VLAN cross-connect)”). An S+C iBridge is
considered to be an S-VLAN aware bridge on PON and 10 GE LTs, where each N:1
In case of DSL and Ethernet (UNI) S+C iBridge is S+C VLAN aware, where each N:1
VLAN (S+C) is a separate Virtual Bridge (VB) instance with independent source
MAC address leaning and frame forwarding processing.

NT
This forwarding mode resembles the ISAM S+C VLAN cross-connect forwarding
model. The main difference is that in the S+C iBridge mode, the C-VLAN ID can be
shared across multiple UNIs. This is not the case for the S+C cross-connect mode,
whereby a C-VLAN ID is restricted to a single UNI.
Note 1 — The S+C iBridge mode supports both
protocol-unaware and protocol-aware modes of operations. For
example, DHCP option 82 insertion, PPPoE Intermediate
Agent and secure forwarding (ARP Relay, DHCP Snooping, IP
anti-spoofing) are supported for protocol-aware S+C iBridge
access solutions.
Protocol awareness is supported for customer untagged and
single-tagged frames.
Protocol unaware is supported for customer untagged,
single/dual/multi -tagged frames.
In context of GPON and XGS-PON / TWDM-PON access
solutions, some restrictions may apply on the ONT for the
ability to support dual and multi-tagged frames.
Note 2 — A given S-VLAN ID can only be shared between S+C
iBridge and S-iBridge for GPON and XGS-PON / TWDM-PON
access. Other interfaces do not support sharing.
Note 3 — DSL LT boards support stacked iBridge mode for
unicast traffic only.
Note 4 — Multicasting traffic by means of an IGMP proxy is not
supported by stacked iBridges, a standard iBridge must be
used instead.
Note 5 — The following restrictions apply to GE Ethernet LTs:
• UNI: Stacked iBridge is supported for unicast traffic only

• HC-UNI: Stacked iBridge is not supported
• NNI: Only the (S,*) variant of the stacked iBridge is
supported, that is, multi-tagged frames are bridged in
function of their outer VLAN, see further
Note 6 — On DSL LT boards, stacked iBridge does not support

PPP MAC address concentration, IPoA, PPPoX Relay and
VRRP Proxy
On DSL LT boards, secure-forwarding, broadcast control and aging time may be

controlled at the S level and inherited at S+C level while other configurations are
configured at the S+C level.

NT

tagged frames in S-iBridge
The forwarding behaviors described in section “VLAN tagging modes in the iBridge”
are mostly pertinent for the operations of an S-iBridge. The main difference is that an
S-VLAN iBridge offers the ability of VLAN stacking. The S-iBridge can be configured
either in the S-Tunnel iBridge mode or in the S-VLAN mapped mode. The S-Tunnel
iBridge is described in more detail in the following paragraphs. The S-VLAN mapped
mode is supported only for the NNI ports of the GPON and GE Ethernet LTs and on
LTs supporting bonded copper backhaul. Further details of the S-VLAN mapped
mode can be found in “VLAN tagging modes in the iBridge (Hub-ISAM LT NNI ports
concept)”.
The S-Tunnel iBridge supports forwarding of untagged / priority-tagged and
VLAN-tagged customer frames via the configuration of a tunnel VLAN port.
The S-Tunnel iBridge also supports the ability to forward dual and multi-tagged
customer frames via the configuration of a tunnel VLAN port. For GPON and
XGS-PON / TWDM-PON access solutions some restrictions may apply on the ONT
for the ability to support dual and multi-tagged frames.
An S-Tunnel iBridge is considered to be an S-VLAN aware bridge, where each N:1
This forwarding mode resembles the ISAM S-Tunnel cross-connect forwarding
model. The main differences are that in the S-Tunnel iBridge mode, a tunnel VLAN
port can exist across multiple UNIs. This is not the case for the S-Tunnel
cross-connect mode, where a tunnel VLAN port is restricted to a single UNI.
The S-Tunnel iBridge is mainly protocol unaware. Therefore, secure forwarding
(ARP Relay, DHCP Snooping, IP anti-spoofing) is not supported. Nonetheless, the
following subscriber identification features are supported on GPON LT NNIs:
• DHCP option 82 insertion for untagged and single-tagged customer Ethernet
frames
• PPPoE Intermediate Agent for untagged and single-tagged customer Ethernet
frames
Note — The S-Tunnel iBridge mode is only supported on

GPON and GE and 10 GE Ethernet LT NNI access solutions.
15.6.6 VLAN tagging modes in the iBridge (Hub-ISAM LT

NNI ports concept)
Section “VLAN tagging modes in the iBridge” has explained the VLAN tagging modes
in the iBridge for normal ISAM LT bridge ports, also known as UNI ports.

NT
15.6.6.1 Concepts
The concepts of bridge ports and VLAN ports defined on the subscriber side and
used by iBridges and VLAN cross-connects are also valid for iBridges defined on NNI
ports.
As noted earlier, the Hub-ISAM LT NNI ports concept is currently supported on the
GE and 10GE Ethernet LTs, on the GPON and XGS-PON / TWDM-PON LT and on
LTs supporting bonded copper backhaul. For the GPON LT, the NNI interface
supports connection to the 7353 MDU.
There are three VLAN iBridge models supported on NNI ports:
• C-VLAN iBridge: Basic VLAN bridge mode (as defined in “VLAN tagging modes
in the iBridge”)
• S+C iBridge: As described in “VLAN tagging modes in the stacked iBridge
modes”, but only supported on GPON and 10GE Ethernet line boards.
• S-VLAN iBridge: Supporting Mapped and Tunnel VLAN bridge modes (Tunnel
mode is described in “VLAN tagging modes in the stacked iBridge modes” and a
description of Mapped mode follows).
For GPON NNI ports, the concept of transparent mode versus non-transparent mode
is introduced. Transparent mode provides a simplified interface between the OLT
and the ONT that connects to the subtending system. It is currently supported for the
7353 MDU and can be summarized as follows:
• All packets will be transparently forwarded without VLAN translation, EtherType
filtering, P-bit marking, and so on.
• The GEM ports are allocated according to P-bit only.
• The maximum number of VLAN ports per NNI port is 512.
In contrast, the non-transparent mode re-uses the UNI interface between OLT and
ONT. Therefore packet manipulations are possible but the number of VLAN ports per
NNI is restricted to 8.
Note that, in transparent mode, the P-bit to traffic class mapping used is the system
level mapping, rather than the per forwarder mapping normally used for GPON.

tagged frames in C-VLAN iBridge
Section “VLAN tagging modes in the iBridge” explains the forwarding behaviors of a
C-VLAN iBridge configured on the GE Ethernet line board port type.

NT

tagged frames in S+C iBridge
The S+C iBridge on NNI port is only supported for 10GE Ethernet and GPON line
boards. Section “VLAN tagging modes in the stacked iBridge modes” explains the
forwarding behaviors of the S+C iBridge.

tagged frames in S-VLAN iBridge
The forwarding behaviors described in section “VLAN tagging modes in the iBridge”
are, for the most part, also pertinent for the operations of an S-VLAN iBridge
configured on the GE Ethernet line board NNI port type.
The main difference is that an S-VLAN iBridge offers the ability of VLAN stacking
(see “VLAN tagging modes in the stacked iBridge modes”)
When the Hub-ISAM NNI port is configured with an S-VLAN iBridge, the ISAM
Access Node is considered to be a VLAN aware bridge, where each N:1 SVLAN is
a separate Virtual Bridge (VB) instance. Each VB performs independent source MAC
address learning and frame forwarding process as described in 802.1D and 802.1Q.
The S-iBridge forwarder, supported on the NNI port type, does support Mapped and
Tunneled modes:
• In Tunnel Mode, the ISAM systematically adds a VLAN tag to frames originating
from the NNI. This mode is enabled by configuring an S-VLAN PVID on the Bridge
Port. It is to be noted that S-VLAN iBridge accepts indifferently untagged and
single-tagged frames.
• In Mapped Mode, the ISAM considers NNI traffic as if already inside a tunnel. In
Mapped mode, the ISAM just extends the NNI tunnel further to the EMAN without
adding any extra VLAN Tag. With Mapped mode, it is not possible to translate the
NNI S-VLAN into a different network S-VLAN.
Both the Tunnel mode and the Mapped mode can co-exist simultaneously in the
ISAM. Whether a frame has to be handled in S-VLAN Tunnel or Mapped iBridge
results from a comparison between the most external frame tag (if any) and the
Bridge port PVID.

NT
Thus the NNI port S-iBridge forwarding behaviors can be summarized as follows:
• When upstream traffic on a given NNI bridge port does not match a defined
S-VLAN port attached to a given S-ibridge and no S-VLAN port default VLAN
exists on that bridge port, then this traffic is dropped.
• When upstream traffic on a given NNI bridge port matches a defined S-VLAN port
attached to a given S-ibridge and no S-VLAN port default VLAN exist on that
bridge port, then this traffic is accepted into the VB instance for bridging functions.
In this case, no new tag will be added on upstream egress. This mode of operation
is called mapped mode.
• When an S-VLAN port default VLAN has been defined on an NNI bridge port, then
all traffic is accepted into the VB instance for bridging functions and this traffic will
be added an S-VLAN tag on upstream egress. This mode of operation is called
tunnel mode.
15.7 VLAN cross-connect mode
15.7.1 VLAN cross-connect usage

Because it associates only one subscriber to one network VLAN, VLAN
cross-connect forwarding is generally not well adapted to residential deployments
where many subscribers need to be connected taking into account that a VLAN tag
can only identify up to 4 K different VLANs.
Hence the VLAN cross-connect mode should preferably be used for business
applications or in small networks, where the ISAM is directly connected to the IP
edge router or Broadband Remote Access Server (BRAS) of a Network Service
Provider (NSP).
Dual-tag VLAN cross-connect (see further) alleviates the scalability issue, but still
requires intensive configuration action in the ISAM which generally makes VLAN
cross-connect less attractive for residential mass deployment.
Note — For the sake of clarity, this section only considers the
case of direct VLAN encapsulation on the EMAN. This
discussion can however be generalized to the cases where
MPLS pseudo-wire encapsulation is used in the EMAN instead.

NT
15.7.2 Supported models in ISAM

There are several VLAN cross-connect models supported:
• C-VLAN cross-connect: basic VLAN cross-connect
• S+C-VLAN cross-connect: more scalable and hierarchical grouping possible (e.g.
the Headquarter of a given company identified by the S-VLAN in touch with
several subsidiaries each one identified by a specific C-VLAN tag)
• Tunnel -VLAN cross-connect: transports the traffic of a given subscriber with total
unawareness of subscriber tagging (or untagging). A tunnel can be identified with
either a single tag (that is called S-VLAN tunnel) or 2 tags (that is called
S+C-VLAN tunnel)
Note 1 — These VLAN cross-connect models are also

supported on the Hub-ISAM LT NNI ports.
Note 2 — S+C VLAN tunnels are only supported by GPON,
XGS-PON/TWDM-PON and 10GE Ethernet LTs.
15.7.2.1 C-VLAN cross-connect (basic VLAN cross-connect)

C-VLAN cross-connect is the most straightforward VLAN cross-connect model,
where a single VLAN ID at the EMAN side is associated with a C-VLAN port at the
subscriber side. In the ISAM, a bridge port is either an Ethernet PVC, an EFM link,
an ONT UNI or a physical user Ethernet link. Any kind of traffic issued by the
subscriber is forwarded transparently to the network using the selected VLAN ID.
As illustrated in Figure 221, similar to iBridging the C-VLAN cross-connect allows:
• user-VLAN to network-VLAN translation
• handling of untagged traffic by means of PVID or Port-Protocol-VLAN ID default
VLANs.
Forwarding of C-VLAN tagged frames in C-VLAN cross-connect

The operator creates a C-VLAN port on top of the bridge port, and couples it to the
C-VLAN cross-connect. When the ISAM receives C-VLAN-tagged frames on a
bridge port it forwards them in the context of a C-VLAN cross-connect.
When no VLAN translation is needed, the VLANs used in the network are extended
all the way to the end subscribers. In this case, the end-subscriber side VLAN IDs
are said to have a network-wide scope. VLAN translation allows that the
network-side and subscriber-side VLAN IDs are different.
Forwarding of untagged/priority-tagged frames in C-VLAN cross-connect

NT
In addition to the configuration above, the operator configures on the Bridge Port a
PVID or a Port-protocol-default VLAN that points to the VLAN port. When The ISAM
receives untagged or priority-tagged frames on a given Bridge Port it adds a Vlan tag
to the frame corresponding to the PVID and forwards the frames in the context of the
C-VLAN CC.
Note that in GPON and XGS-PON / TWDM-PON, a Bridgeport is configured on an
ONT UNI.
In case of GPON and XGS-PON / TWDM-PON access, there are two alternative
modes for VLAN translation: ONT based translation and ISAM based translation; see
“L2 forwarding on the NT board and the LT boards”.
Note — For GPON NNI ports, VLAN translation is not

supported in the ONT, if transparent mode is configured. See
“Concepts” for an explanation of transparent mode. However,
note that VLAN translation in the OLT is still supported for the
transparent mode.
Figure 221 shows the concept of the C-VLAN cross-connect mode.

Figure 221 C-VLAN cross-connect concept
11, *, Data
NetVlan (11) 11, *, Data CC: 1-1 VlanId (11)
Ut, Data
PVID
NetVlan (21) 21, *, Data CC: 1-1 Tr VlanId (11) 11, *, Data
Only VlanPorts are shown
15.7.2.2 S+C-VLAN cross-connect: VLAN stacking for

residential subscribers
In the basic VLAN cross-connect mode, the number of VLAN identifiers is limited to
4 K. Since the VLAN is an EMAN-wide identifier, there is a scalability issue: there
cannot be more than 4 K subscribers connected to the whole EMAN. To solve this
issue, two VLANs are stacked and the cross-connection is then performed on the
combination (S-VLAN, C-VLAN), theoretically reaching up to 4 M subscribers.
An S+C-VLAN cross-connect can be seen as the generalization of a C-VLAN
cross-connect. It has the same mode of operation and the same configuration model
except that with an S+C-VLAN cross-connect, the user C-VLAN is always translated
into a dual tag S+C Network VLAN.
Figure 222 shows the concept of the S+C-VLAN cross-connect mode.

NT
Figure 222 S+C-VLAN cross-connect concept
12, *, Data
31, 12, *, Data CC: 1-1 +- VlanId (12)
NetVlan (31,12) PVID Ut, Data
31, 17, *, Data CC: 1-1 +- VlanId (17) 17, *, Data

NetVlan (31,17)
31, *, Data
31, 23, *, Data CC: 1-1 +- Tr VlanId (13) 13, *, Data

NetVlan (31,23)
EMAN
(Outer Tag switches)
31, 21 *, Data CC: 1-1 +- Tr VlanId (11) 11, *, Data
NetVlan (31,21)

NetVlan (41,27)
41, *, Data

NetVlan (41,39)
Note 1 — In the ISAM, the S+C-VLAN cross-connect is always

performing VLAN translation, even when the subscriber-side
and network-side C-VLAN IDs are the same. For instance in
Figure 222 the subscriber-side VLAN (0, 12) is translated into
the network-side VLAN (31,12).
Note 2 — In case of GPON and XGS-PON / TWDM-PON
access, there are two alternative modes for VLAN translation:
ONT based translation and ISAM based translation; see “L2
forwarding on the NT board and the LT boards”
Special note about MAC address conflict prevention

The purpose of S+C-VLAN cross-connect is to regroup different subscribers
identified by their own C-VLAN in the same shared S-VLAN. Doing so improves the
EMAN scalability by allowing the EMAN to collectively bridge all users' traffic in the
same S-VLAN context.
Because the EMAN is only aware of the S-VLAN context when performing bridging,
the ISAM must make sure that no two subscribers use the same source MAC
address in upstream when put in the same S-VLAN.

NT
While on the LT boards, each S+C VLAN cross-connect defines a distinct forwarding
context, and hence there cannot be any MAC address conflict, this is not true on the
NT board. The NT board acts as an S-VLAN bridge, unaware of the C-VLANs so
traffic of multiple end-users that share the same S-VLAN ID is treated in the same
forwarding context. If a given MAC address is learned on a 1st LT port and later on
a 2nd LT port, then no MAC movement occurs, but instead a “duplicate MAC
address” alarm is raised by the NT board.
15.7.2.3 Tunnel-VLAN cross-connect: VLAN stacking for

business subscribers
A tunnel-VLAN cross-connect is characterized by the fact that any incoming packets
will be encapsulated into a "VLAN tunnel", that is, the ISAM is unconditionally adding
one or two VLAN tags to frames originating from the subscriber. When sending traffic
back to the subscriber, the ISAM will systematically remove one or two tags,
reversing the ingress operation at the egress.
This provides a "transport pipe" between the subscriber and the remote site, making
the ISAM and the EMAN totally unaware of the traffic transported over the tunnel
(untagged, single or multi-tagged frames).
As indicted above, we have two variants of the Tunnel-VLAN cross-connect in
function of the amount of tags being pushed/popped at the user interface:
• Single tagged tunnel-VLAN: one tag is pushed or popped - supported by all LTs
• Stacked tunnel-VLAN: two tags are pushed or popped - only supported by PON
LTs and 10 GE Ethernet LTs.
To configure a single tagged Tunnel cross-connect for DSL, Ethernet or GPON

subscribers (not supported for XGS-PON / TWDM-PON and 10GE Ethernet LT
subscribers), the operator needs to configure the ISAM with the following:
• configure a network S-VLAN with mode cross-connect
• configure an S-VLAN port on the bridge port of the subscriber using the tunnel
• use this S-VLAN port as PVID
To configure a single tagged Tunnel cross-connect on the 10GE P2P LT and a
stacked Tunnel Cross-connect for PON subscribers
(GPON/XGS-PON/TWDM-PON) and 10GE P2P LTs, the operator needs to
configure the ISAM with the following:
• configure a Network S-VLAN (single tagged) or S+C VLAN (stacked) with mode
"Cross-connect"
• configure a "tunnel VLAN Port" on the Bridge Port of the subscriber using the
tunnel
Figure 223 shows the S-VLAN cross-connect model (DSL, Ethernet or GPON case
shown).

NT
Figure 223 S-VLAN cross-connect model concept
NetVlan 51 51, *, Data CC: 1-1 +- VlanId (51,0) */Ut, Data

PVID
It should be noted that a Tunnel-VLAN cross-connect can coexist with C-VLAN and
S+C-VLAN based forwarders (i.e. VLAN Cross-Connect or i-Bridge) on the same
bridge port. When this is the case, upstream user traffic is preferably sent to the C-
or S+C-VLAN forwarders if the user VLAN matches the corresponding VLAN ports.
The rest of the upstream traffic is sent by default through the Tunnel-VLAN
cross-connect. Figure 224 illustrates this case.
Figure 224 Tunnel-VLAN, C-VLAN and S+C-VLAN cross-connects on same
bridge port
NetVlan 11 11, *, Data CC: 1-1 VlanId (11) 11, *, Data
NetVlan 31,23 31, 23, *, Data CC: 1-1 +- Tr VlanId (13) 13, *, Data
NetVlan 51 51, *, Data CC: 1-1 +- VlanId (51,0) */Ut, Data

PVID
“*, Data “
here means any frame except
with outertag = 11 or 13
15.7.3 MAC learning and VLAN port handling

The same MAC learning concepts and VLAN port handling as for iBridge apply to
VLAN CC; see section “iBridges”.

NT
Although VLAN cross-connects do not rely on MAC address to forward frames to

subscribers, VLAN cross-connects also perform MAC address learning in a similar
way as for iBridges as a DOS protection means (enforcing the port limit and avoid
rogue users stealing network MAC addresses). When DOS protection is not of
primary concern however, MAC address learning can be disabled within a VLAN
cross-connect allowing an unrestricted number of source MAC addresses to flow
through the VLAN cross-connect.
Note — MAC learning is always disabled for VLAN

cross-connects established on GE Ethernet LT NNI ports
15.7.4 Transparent VLAN cross-connect

The ISAM supports transparent VLAN cross-connect for use in a business
environment on all LT boards except layer 2 LT boards.
A transparent VLAN cross-connect is a special mode of operation of the C-VLAN
cross-connect, the S+C-VLAN cross-connect or the Tunnel-VLAN cross-connect.
Transparent VLAN cross-connect is also supported on the hub-ISAM LT NNI ports.
A transparent VLAN has the following additional features compared with the usual
VLAN cross-connect:
• L2CP frames are transparently forwarded (except pause frames and ESMC
frames which are related to the physical interface).
• MAC address learning is disabled in the NT board for better scalability.
L2CP frames are those frames with the following destination MAC addresses:
• 01-80-C2-00-00-00 through 01-80-C2-00-00-0F
• 01-80-C2-00-00-10
• 01-80-C2-00-00-20 through 01-80-C2-00-00-2F
Note — The ECNT-A can only partly support fully transparent

VLAN-cross-connect. It can only recognize those L2CP frames
which have the following MAC addresses:
• 01-80-C2-00-00-00
• 01-80-C2-00-00-10
• 01-80-C2-00-00-20 through 01-80-C2-00-00-2F
L2CP protocols is a family of link-related protocols. It comprises the following
protocols:
• Spanning Tree protocol
• Rapid Spanning Tree protocol

NT
• Multiple Spanning Tree protocol

• Pause (802.3x) protocol
• Link Aggregation protocol
• Marker protocol
• Authentication (802.1X) protocol
• LAN Bridge Management Group Block of protocols
• Generic Attribute Registration Protocol (GARP) Block of protocols
• and so on
Pause frames are those L2CP frames identified by:

• Destination MAC address = 01-80-C2-00-00-01
• Ethernet type and op-code can be anything
The purpose of transparent VLAN cross-connect is to emulate a physical link, as
illustrated in Figure 225.
Figure 225 Use of transparent VLAN cross-connect
L2CP: Sp. tree

Br
Br Br
L2CP: Sp. tree
Br
Br Link aggregate L2CP:LACP Br
Br
LAG
LAG
LAG
Br
Br L2CP:LACP Br
Over Transparent VLAN-CC
L2CP
VLAN1
Br
Br x x Br
Br
Br
Br VLAN2 L2CP Br
Br
x x
LAG
LAG
LAG
LAG
Br
Br VLAN3 L2CP Br
Br
x x
EMAN
Assu m p tio n :
EMAN tr a n sp a r e n t to ta g g e d L2 CP traffic

NT
In the upstream direction, in a transparent VLAN cross-connect, untagged

subscriber L2CP frames are considered as data traffic and are tagged by the default
PVID configured on the PVC/EFM/ONT UNI with the exception of:
• tagged pause frames, which are always discarded
• untagged 802.1X frames, which are extracted to the LT OBC when 802.1X is
enabled, whether L2CP transparency is enabled or disabled on the LT board
Note — For GPON access, the IEEE802.1X frames are always
terminated on the ONT UNI. This means that if no PVID has
been configured on the ONT UNI bridge port, then the
IEEE802.1X frames will be discarded. If a PVID has been
configured and associated with a forwarding context,
IEEE802.1X frames will be forwarded to the OLT using the
PVID VLAN ID. Once at the OLT if IEEE802.1X is:
• Disabled, then these frames will be dropped.
• Enabled, then these frames will be extracted to the LT OBC.
• untagged link-based Ethernet OAM, which is extracted to the OBC when
link-based Ethernet OAM is enabled, whether L2CP transparency is enabled or
disabled on the LT board.
Note 1 — IEEE802.3ah OAM is currently not supported on ONT
UNI ports and on Hub-ISAM GPON LT and 10GE Ethernet LT
ports.
Note 2 — IEEE802.3ah OAM is currently not supported on
XGS-PON / TWDM-PON access solutions.
• Untagged ESMC frames, which are always discarded on Ethernet LT card.
• Whatever Untagged or tagged ESMC frames, which are always discarded on
GPON LT card.
In the downstream direction, in a transparent VLAN cross-connect, tagged

subscriber L2CP frames are considered as data traffic and are passed untagged to
the subscriber. The handling of untagged downstream L2CP frames is not affected
by the transparent VLAN cross-connect.
Because L2CP protocols are link related, the deployment model implies that only one
transparent VLAN cross-connect is configured per PVC (or per EFM/ONT UNI); see
Figure 226. Having more than one cross-connect can lead to undesired effects in
L2CP protocols.

NT
Figure 226 One transparent VLAN cross-connect per PVC/EFM
L2CP
CPE PVC/EFM x x PVC/EFM CPE

VLAN1
PVID = VLAN1
EMAN
CPE PVC/EFM x
L2CP
VLAN1
x
PVC/ EFM CPE
x
VLAN2
CPE PVC/EFM x PVID= VLAN1

EMAN
15.8 Protocol-aware cross-connect mode

The protocol-aware cross-connect mode behaves like the formerly described
cross-connect modes for the dataplane, but it also adds some protocol awareness
similar to the iBridge mode, for protocols such as 802.1X, DHCP, IGMP, PPPoE,
DHCPv6 and ICMPv6.
This mode provides a connectivity scheme compatible with a fully centralized
subscriber management, where each individual subscriber is connected to an IP
Edge (IP connectivity) or a BRAS (PPP connectivity) through a single bit-pipe. In this
configuration, the subscribers are sharing the same subnet for scalability reasons
and do not present their private network configuration to the network.

NT
15.8.1 VLAN cross-connect for business and residential

subscribers
The VLAN cross-connect feature is aimed at cross-connecting a subscriber PVC (or
DSL line in case of EFM, Ethernet link in case of point-to-point Ethernet or ONT UNI)
with a “private” VLAN at the EMAN side. Depending on the subscriber type, two
VLAN cross-connect configurations are considered:
• Business cross-connect:
This mode provides a connectivity scheme for business subscribers which is as
transparent as possible and emulates a fully featured routed network. In this
configuration, the IP subnets of the private subscribers are made visible to the
network and the configuration data of those private subnets and the subnets
further in the network are exchanged through routing protocols.
Figure 227 shows the IP network model for business cross-connect.
Figure 227 IP network model for business cross-connect

Edge EMAN NE CPE
VRF
VL
VRF
Services VRF
VRF
VRF
Customer
premises
IP subnet IP address VLAN IP subnet
• Residential cross-connect:
This mode provides a connectivity scheme compatible with a fully centralized
subscriber management where each individual subscriber is connected to an IP
edge (IP connectivity; see Figure 228) or a BRAS (PPP connectivity; see
Figure 229) through a single bit pipe. In this configuration, the subscribers are
sharing the same subnet for scalability reasons and (normally) do not present
their private network configuration to the network.

NT
Figure 228 IP network model for residential cross-connect using IP

connectivity
Edge EMAN NE CPE
VLAN-CC
Services VRF
IP subnet IP address VLAN

NT
Figure 229 IP network model for residential cross-connect using PPP

connectivity
Edge EMAN NE CPE
VLAN-CC
IP PPP
Services Routing Termina-
tion
IP subnet IP address
PPP session VLAN
Note — Figure 228 and Figure 229 apply for residential

subscribers that are using bridged CPE or router CPEs with
NAT. In those cases, only single IP address(es) are allocated
to the subscriber, and no (directly or non-directly) attached
subnets.
Though not typically associated with residential subscribers,
router CPEs without NAT can be supported too. The data
forwarding in the VLAN cross-connect model is fully based on
the VLAN tag(s) and does not need to look at the IP addresses
(that is, need to support an IP next-hop behavior in the
downstream direction).
However, this possibility is rather heavy from an operational
point of view: subscriber subnets need to be configured by the
operator in the IP edge. If IP address anti-spoofing is switched
on in the ISAM, the subscriber subnets must be configured
there as well.
15.8.1.1 Business cross-connect features

In a business context, the VLAN cross-connect model is used to provide a
transparent VPN service which supports the following features:
• point-to-point Ethernet UNI/HC-UNI and ONT UNI interface types
• Supported on the Hub-ISAM GPON LT NNI ports.

NT
• DSL interfaces types:

• ATM:
• Bridged encapsulation carrying IPoE or PPPoE traffic
• IPoA with the required interworking to convert the traffic to IPoE
• PPPoA encapsulation or encapsulation auto-detection is not expected in a
business context
• VDSL EFM
• IPoE or PPPoE traffic
• Subscriber identification:
A single or a stacked VLAN tag towards the network is associated to a single
business subscriber. Various VLAN assignment schemes exist:
• C-VLAN cross-connect: The C-VLAN indicates the end subscriber.
• S+C-VLAN cross-connect: The C-VLAN indicates the subscriber, while the S-VLAN
indicates the ISAM (or the ISAM-PE pair).
• Single tagged Tunnel-VLAN cross-connect: The S-VLAN indicates the end
subscriber, while the C-VLANs represent various subscriber-defined services.
• Stacked Tunnel-VLAN cross-connect: The C-VLAN indicates the end subscriber,
while the S-VLAN indicates the ISAM (or the ISAM-PE pair). The tunneled VLANs
represent various subscriber-defined services.
• Security features:
For bridged encapsulation: optional limitation of the number of MAC addresses
per VLAN cross-connect.
• Service enforcement:
Policing per end-subscriber VLAN port or bridge port
15.8.1.2 Residential cross-connect features

The VLAN cross-connect supports the following features in the context of residential
subscribers:
• point-to-point Ethernet and ONT UNI interface types
• supported on the hub-ISAM LT NNI ports
• DSL interfaces types:
• ATM:
• Bridged encapsulation carrying both PPPoE and IPoE traffic
• PPPoA with the required interworking to convert the traffic to PPPoE
• Encapsulation auto-detection as the encapsulation of residential subscribers is
generally unknown
• VDSL EFM
• IPoE or PPPoE traffic

NT
• Subscriber identification:
• A single (C-VLAN) or a stacked (S+C-VLAN) VLAN tag towards the network is
associated to a single residential subscriber.
• Optional addition of the PPPoE relay tag (that is, the line ID parameter) in the PPPoE
control messages.
• Optional addition of the DHCP Option 82 (that is, the line ID parameter) in the DHCP
messages.
• Optional addition of the DHCPv6 Option 18 and/or Option 37 (that is, the interface ID
and the relay agent remote ID parameters) in the DHCPv6 messages.
• These subscriber identification options are transparent on the NNI ports of the GE
Ethernet line board. The NNI ports of the GPON line board will add the OLT part of
the line ID in these options, based on the syntax configuration.
• Security features:
• 802.1X authentication allowing to allow or disallow the traffic (PPPoE and IPoE)
through the pre-configured VLAN cross-connect in function of the connected CPEs
(this is not supported however on the hub-ISAM LT HC-UNI and NNI ports)
• Optional limitation of the number of MAC addresses per VLAN cross-connect
• ACLs: though this should typically be done by the IP edge, it might happen that the
latter does not own enough processing capacity to support that feature
• IP address anti-spoofing: this should ideally be done centrally in the network, but IP
address anti-spoofing might not always be available centrally and/or might suffer
from some dimensioning/performance issues when used for a large amount of
subscribers
• Service enforcement:
• Policing per end-subscriber VLAN port
• Further detailed policing actions based on CoS and/or ACL results should be typically
performed centrally where the service awareness is present.
• QoS policy: in case a single PVC is used to carry multiple services and the CPE is
not generating priority tagged frames, segregating services is then only possible at
IP level using the QoS policies offered by the ISAM QoS Policy framework. For
instance, one can define IP sub-flows based on, for example, DSCP values, IP
source or destination addresses or even UDP/TCP port addresses. Each of these
sub-flows can then have its QoS parameters re-marked and/or can be policed. The
same applies for VDSL ports that only carry untagged frames.
• Service selection: performed centrally
• Service accounting: performed centrally
• Local multicast handling: driven by IGMP
See also “Protocol handling in a Layer 2 forwarding model” for more information.

NT
15.9 IPoA cross-connect mode

The IPoA cross-connect mode offers a solution for connecting subscribers with
RFC-2684-routed encapsulation (IPoA) via the GE uplink with the same services as
in an ATM environment. For example, it offers no changes in IP configuration,
transparency for the involved (routing) protocols, QoS, and so on. IPoA is only
supported for IPv4.
Note — The IPoA cross-connect mode is comparable with the
VLAN cross-connect mode, but with IPoA instead of IPoE at the
CPE side.
The IPoA cross-connect model implies a cross-connection between the PVC of a

subscriber whose encapsulation is IPoA with a VLAN at the EMAN side.
The following applies for the subscriber subnet behind the customer CPE:
• the CPE performs Network Address Translation (NAT), that is, the subscribers
behind the CPE have a private subnet and the CPE translates the private
subscriber IP address to the public CPE IP address
• the subscribers have IP addresses from the public range and, as a consequence,
the public subscriber IP addresses become visible in the IP network.
In any case, the subnet configuration at the subscriber side (behind the CPE) is
transparent to the ISAM. The ISAM only sees the IP address of the CPE and the IP
address of the edge router; see Figure 230 and Figure 231.
Figure 230 IP network model for business IPoA cross-connect
NE CPE
IP
100.100.100.9 100.100.100.8 /30 Network CPE 100.100.100.10
side side
CPE
Edge IP
100.100.100.13 100.100.100.12 /30 100.100.100.14
Router
CPE
100.100.100.17 100.100.100.16 /30 IP 100.100.100.18
= IP interface IPoE IPoA

NT
Figure 231 Ethernet network model for business IPoA cross-connect

IPoE IPoA
IP PVC11
C_VLAN1 CPE1
PVC12
Edge PVC21
Router S_VLAN IP
C_VLAN2 CPE2
PVC22
PVC31
C_VLAN3 IP
CPE3
PVC32
= L2 interface
15.9.1 IPoA cross-connect features

The following features are supported for the IPoA cross-connect mode:
• The IP address of the CPE is static (no dynamic CPE IP address assignment via
DHCP).
• The ISAM is transparent for routing protocols between CPE and PE.
• Only /30 subnet is supported between the ISAM and the CPE.
• A given CPE can be associated with up to 30 different subnets (multi-VPN). Each
of these subnets will then be served with a separate PVC and separate VLAN.
• There is VLAN stacking on the GE uplink. Typically, the C-VLAN indicates the
CPE and the S-VLAN indicates the ISAM (or the paired ISAM-PE).
• There is internal prioritization based on Differentiated Services CodePoint
(DSCP) bits, both for the upstream and the downstream direction.
• There is upstream p-bit marking.
15.9.2 Cross-connect from IPoA to IPoE (upstream)

The IP packet is extracted from ATM (IPoA) and encapsulated into Ethernet (IPoE),
as follows:
• Unicast IP packets:
The LT MAC address is used as the source MAC address and the destination
MAC address is the MAC address of the edge router which is resolved from the
edge router IP address via ARP.
• Broadcast and multicast IP packets:
The LT MAC address is used as the source MAC address and the destination
MAC address is derived from the broadcast or multicast destination IP address.

NT
15.9.3 Cross-connect from IPoE to IPoA (downstream)

The IP packet is extracted from Ethernet (IPoE) and encapsulated into ATM (IPoA).
The CPE interface (PVC) is determined from the VLAN (or S-VLAN and C-VLAN
combination) since it is cross-connect mode.
The destination MAC address can either be the LT MAC address (the ISAM
responds to an ARP request for the CPE IP address generated by the edge router),
or a broadcast or multicast MAC address.
15.10 Secure forwarding in iBridge and VLAN

cross-connect
Secure forwarding is a feature applicable to iBridge and VLAN cross-connect
forwarders. It increases the network security by making use of the IP characteristics
of the traffic. It is applicable both for IPoA (IPv4 only) and IPoE (Ipv4 or IPv6) user
traffic.When enabled, secure forwarding provides the following features:
• IP session awareness:
DHCP messages are snooped to dynamically learn IP session information.
• IP address anti-spoofing is activated both for dynamic IP sessions and statically
configured IP addresses/subnets.
Any IP packets whose IP source address does not match any of the following are
discarded:
• any IP addresses allocated to the subscriber interface through DHCP
• any static IP addresses
• any IP subnets programmed by the operator
In case of IPv6, the ISAM discards any IPv6 packets whose IPv6 source address
does not match any IPv6 addresses or prefixes that are either statically configured
or dynamically to the user interface. By default, the ISAM will only check the first
64 bits of the 128-bit IPv6 address. This is sufficient because the last 64 bits of
the IPv6 address hold the “Interface Identifier”; the Interface ID is typically based
on the interface MAC address and therefore not of relevance to the IPv6
anti-spoofing function. In the specific case of PON-based access networks, the
ISAM can also be configured to perform anti-spoofing based on the full 128-bit
IPv6 address. This may be useful in case the same 64-bit IPv6 prefix is shared
among multiple wholesale subscribers that are connected to the same ONT.
• ARP relay is performed both for dynamic IP sessions and statically configured IP
addresses/subnets.
Downstream broadcast ARP messages are forwarded to the correct subscriber
port only. This provides some security against malicious subscribers doing a “theft
of service”.
Secure forwarding relies on DHCP snooping (for more information on DHCP, see
chapter “Protocol handling in a Layer 2 forwarding model” and chapter “Protocol
handling in a Layer 3 forwarding model”.

NT
The operator can enable or disable the secure forwarding feature per iBridge / VLAN
cross-connect.
When secure forwarding is applied to iBridges, it is sometimes referred to as
Enhanced iBridge forwarding.
Figure 232 Enhanced iBridge architecture
IS AM
Useer r
Us CPE L
LT
DHCP s nooping/ ARP
Useer r
Us CPE S tatic config. Relay
VLAN IP Subnet
Useer r
Us CPE iBridge
Useer r
Us CPE L
LT NT
DHCP s nooping/ ARP
Useer r
Us Relay EMA IP
CPE S tatic config. IP
network
Useer r
Us iBridge Bridge IP edge
CPE
Useer r
Us CPE L
LT
DHCP s nooping/ ARP
Useer r
Us CPE S tatic config. Relay
Useer r
Us CPE iBridge
Us ers can belong to a

different public s ubnet
ubnet.
• Secure forwarding of IPv4 traffic is supported by all ISAM LT boards: DSL,

point-to-point Ethernet (UNI/HC-UNI), GPON and XGS-PON / TWDM-PON LTs.
• Secure forwarding of IPv6 traffic is supported by all ISAM LT boards: DSL,
point-to-point Ethernet (UNI/HC-UNI), GPON and XGS-PON / TWDM-PON LTs.
• Secure forwarding is supported for S+C iBridge on point-to-point Ethernet (UNI)
and on GPON and XGS-PON / TWDM-PON and EPON access solutions.
• Secure forwarding is supported for S+C VLAN cross-connect on GPON and
XGS-PON / TWDM-PON access solutions. However secure forwarding must be
configured at the S-VLAN level. All S+C VLAN cross-connects having the same
S-VLAN ID share the same secure forwarding configuration.
• Secure forwarding is supported for untagged and single-tagged customer frames
in S-Tunnel iBridge on GPON access solutions. (S-Tunnel is not supported on
XGS-PON / TWDM-PON in the current release)
• Secure forwarding is not supported on the hub-ISAM LT NNI ports.

NT
15.10.1 IP session awareness

The ISAM snoops DHCP messages to learn what IP addresses/subnets have been
allocated to a subscriber port.
Note — For more information about DHCP, see Chapter
“Protocol handling in a Layer 2 forwarding model” and Chapter
“Protocol handling in a Layer 3 forwarding model”.
The ISAM keeps the IP session information (that is, IP address and associated
subnet of the subscriber, lease time, default gateway IP address, DHCP server IP
address, and so on) during the lifetime of the DHCP session.
The IP session information is used during ARP relay and to install IP anti-spoofing
filters.
15.10.2 IP address anti-spoofing

The following applies for IP address anti-spoofing:
• IPv4 address anti-spoofing for dynamic IP addresses learned through DHCP.
Any IP packets whose IP source address does not match any IP addresses
allocated to the subscriber interface through DHCP are discarded.
Though the main scenario when considering IP awareness in the iBridge VLAN
cross-connect context is a configuration where IP addresses are dynamically
allocated by a DHCP server, static IP addresses and/or subnets must also be
supported to cover the following cases:
• migration from legacy network where CPEs are already configured with a static IP
address
• DHCP servers that do not support Option 82
• IPv6 address anti-spoofing for dynamic IPv6 addresses learned through
DHCPv6.
The ISAM discards any IPv6 packets whose IPv6 source address does not match
any IPv6 addresses or prefixes allocated to the user interface. By default, the
ISAM checks the first 64 bits of the 128-bit IPv6 address. In the specific case of
PON-based access networks, the ISAM can also be configured to perform
anti-spoofing based on the full 128-bit IPv6 address.
• IPv6 address anti-spoofing for static IP addresses and/or IP subnets (IP prefix +
length) configured by the operator.
Any IPv6 packets whose IPv6 source address does not match any static IPv6
addresses and/or prefixes programmed by the operator are discarded. By default,
the ISAM checks the first 64 bits of the 128-bit IPv6 address. In the specific case
of PON-based access networks, the ISAM can also be configured to perform
anti-spoofing based on the full 128-bit IPv6 address.

NT
• IP address anti-spoofing for control messages.

IP address anti-spoofing is applied to control messages like ARP, IGMP, and
DHCP.
15.10.3 ARP relay

The iBridge forwarding rules allow a basic ARP handling:
• Downstream ARP messages
When setting the broadcast flag for a given iBridge, downstream ARP requests
are forwarded to all subscribers connected to the iBridge.
• Upstream ARP messages
ARP requests originating from the subscriber are broadcast to all network bridge
ports.
A more intelligent way of dealing with ARP messages is ARP relay.
Note — ARP relay is not the same as the so-called

“ARP-proxy” defined in the context of IP forwarding. Indeed, the
ISAM will never answer with its own MAC address in the
context of iBridging but will direct the message to the host in
charge of answering.
ARP relay is composed of the following features:

• Broadcast ARP messages received from the network are forwarded to the single
relevant subscriber bridge port.
The ISAM does not broadcast ARP messages to all subscribers. Instead, the
ISAM only forwards an ARP message to the subscriber interface whose IP
address(es) and/or subnet(s) match the IP address targeted by the ARP
message. This in order to reduce the load on the subscriber interfaces and avoid
security flaws by broadcasting ARP messages to all subscribers in an
uncontrolled way. It is then up to the subscriber to reply the ARP message (there
is no ARP state machine in the ISAM).
To simplify the downstream forwarding of ARP messages in the ISAM, the IP
addresses that are statically configured or learned via DHCP on a subscriber port
must be non-overlapping with any other IP addresses that exist on the same or
any other subscriber port. This is guaranteed in the following way:
• Configuring a static IP address/subnet that overlaps with any other static one is
prevented at the time of configuration.
• When a DHCP session is set up that contains overlapping IP address, the DHCP
message exchange between the subscriber client and the DHCP server is completed
as usual. However, the IP address/subnet is not learned on the subscriber port, so
no data traffic will be possible with that IP address/subnet due to the IP anti-spoofing
filter. In addition, an alarm is generated.

NT
• Non-local ARP messages received from the subscribers are broadcast to all
network bridge ports.
ARP messages coming from a subscriber, provided they are not targeted to the
same subscriber, are simply broadcast to all network interfaces, allowing the edge
routers to reply with their own MAC address. To avoid bothering the network with
ARP messages intended for hosts located on the local network of the subscriber,
the ISAM discards any ARP messages, whose targeted IP address belong to the
list of IP addresses and/or subnets defined for IP address anti-spoofing on that
subscriber’s interface.
Because iBridging in the ISAM does not allow user-to-user traffic, the edge router
must support local ARP proxy and IP traffic hair-pinning (that is, traffic received
on a given interface that must be forwarded to the same interface based on the
routing table) if user-to-user traffic is needed.
15.10.4 ICMPv6
The details of ICMPv6 protocol handling are captured in chapter “Protocol handling
in a Layer 2 forwarding model”.
15.10.5 IPoA support for secure forwarding

By similarity with IPoA VLAN cross-connect, secure forwarding is supported with
IPoA encapsulation: IPoA upstream traffic is converted into IPoE traffic and
vice-versa.
15.11 Virtual MAC

Layer 2 forwarding models typically identify a subscriber device using a MAC
address. However, since these devices are not directly controlled by the operator,
their MAC address cannot be trusted. Various mechanisms have been put in place
to deal with this, such as the duplicate MAC address control of the ISAM iBridge.
However, this only partially solves the issue, because:
• MAC address uniqueness can only be guaranteed at the ISAM level and not
across the whole access network
• The ISAM can detect a duplicate MAC address but cannot differentiate the
well-meaning subscriber from the malicious one

NT
The concept of virtual MAC (vMAC) offers a complete solution by replacing the MAC
address of the subscriber with a MAC address defined by the operator (and
therefore, fully controlled). Enabling vMAC allows improving layer 2 forwarding
models in the following two areas:
• Security:
Translating the MAC address of the subscriber by an operator-defined MAC
address ensures, by definition, the uniqueness of the MAC address across the
whole access network, automatically alleviating all issues related with duplicate
MAC addresses.
• Scalability:
By guaranteeing that a MAC address is unique across the whole access network,
an operator can now choose to connect multiple DSLAMs to the edge router
through the same network VLAN. By doing so, the operator increases the number
of subscribers sharing the same subnet and, consequently, improves the pooling
effect when allocating IP addresses.
Caution — Although vMAC addresses are saved during an LT

board reset, they are not saved if the LT board is powered
down.
Note 1 — vMAC is not supported on the Hub-ISAM LT NNI, GE

Ethernet LT HC-UNI and 10GE Ethernet LT ports.
Note 2 — vMAC is supported with S+C iBridge and S-Tunnel
iBridge on GPON and U-NGPON access solutions on UNI ports
only.
15.11.1 Deployment scenario example

One possible deployment scenario for vMAC is shared network VLAN for IP address
pooling.
Without enabling vMAC, the iBridge implementation only guarantees MAC address
uniqueness at ISAM level, that is, not across the whole access network. In that case,
you can only avoid duplicate MAC addresses by guaranteeing that the traffic from a
DSLAM is not mixed with the traffic from another DSLAM in the EMAN, before
entering the IP edge. In other words, avoiding duplicate MAC addresses is achieved
by assigned a dedicated network VLAN per DSLAM; see Figure 233.

NT
Figure 233 iBridge

Edge EMAN ISAM CPE
I-Bridge
VRF Bridge
I-Bridge
IP subnet IP address
Activating vMAC support in iBridge removes the preceding constraint and allows
sharing a same network VLAN across multiple DSLAMs. This network VLAN sharing
improves the scalability of the access network regarding IP address allocation; see
Figure 234.
Figure 234 iBridge with vMAC enabled
Edge EMAN ISAM CPE
vMAC
bridge
VRF Bridge
vMAC
bridge
VLAN / IP subnet IP address
Sharing a network VLAN across multiple DSLAMs might lead to enabling

user-to-user communication between subscribers connected to different DSLAMs
through the Ethernet switches. This is typically not wanted by the access network
operators and must be blocked by either the Ethernet switch (using the concept of
split horizon at layer 2) or by the DSLAM itself.

NT
15.11.2 vMAC features

vMAC has the following features:
• vMAC support can be enabled or disabled per network VLAN
• maximum number of vMAC per port is programmable
• silent discard of packets received with a new subscriber MAC address when no
free vMAC is left
• vMAC translation is not applied to multicast, broadcast and invalid MAC address
• the DSLAM ID is programmable by the operator
• handling in DHCP Application Layer Gateway (ALG)
• handling in ARP ALG
• handling in ICMPv6 ALG
• handling in Ethernet OAM ALG
• user-to-user communication can optionally be blocked
• vMAC address - MAC address translation table recovery
• application or not of vMAC to DHCP Option61 user MAC address
15.11.2.1 Enable/disable vMAC support per network VLAN

vMAC support can be enabled per network VLAN and this independently of the
forwarding model.
vMAC can be used in conjunction with:
• C-VLAN cross-connect
• S+C-VLAN cross-connect (vMAC is an S-VLAN level attribute)
• iBridge
• stacked iBridge
Note 1 — vMAC cannot be used in conjunction with

Tunnel-VLAN cross-connect.
Note 2 — vMAC is controlled at S Level for an S+C iBridge
Note 3 — Static MAC are not permitted on a vMAC enabled

network VLAN. vMAC cannot be enabled when static MAC is
configured on a network VLAN.
vMAC can also be used in conjunction with IP routing where the NT board acts as IP
router and the LT board as iBridge.
vMAC support together with the IP routing model (and LT board acting as iBridge) is
advised, so that any issues with duplicate MAC addresses are avoided. This is what
you would expect with a black box IP router DSLAM (that is, the IP router should still
work even if all subscribers were using the same MAC address).

NT
vMAC support is characterized as follows:

• Upstream traffic:
• Each time a new MAC address is received from the subscriber, a free vMAC is
associated with the MAC address of that subscriber.
• The MAC source addresses of the Ethernet packets are overwritten with the vMAC
associated with the subscriber MAC address found into the MAC source address
field.
• vMAC ALGs might be applied to control plane messages (ARP, DCHP, Link Related
Ethernet OAM, and so on).
• Downstream traffic:
• The MAC destination addresses of the Ethernet packets are overwritten with the
subscriber MAC address associated with the vMAC found in the MAC destination
address field. Multicast and broadcast destination addresses have a special format
and are not impacted by the vMAC ALG (when allowed to get through).
• vMAC ALGs might be applied to control plane messages (ARP, DCHP, Link Related
Ethernet OAM, and so on).
When unused, vMAC are freed based on the standard MAC address aging process.
Note — All the dimensioning parameters related to the

standard MAC address (for example, average number of MAC
addresses per subscriber, maximum number of MAC
addresses per subscriber, and so on) also apply when vMAC is
enabled within a given network VLAN.
15.11.2.2 Maximum number of vMAC addresses per port is

programmable
The maximum number of vMAC addresses that are allowed on a given subscriber
port can be specified.
Note — This limit is programmed by setting the maximum

number of MAC address per port (generic MAC address related
feature).
15.11.2.3 Silent discard

Packets received with a new subscriber MAC address when no free vMAC is left are
silently discarded.
Any packet received from a subscriber, and whose MAC source address should be
learned because it is still unknown, will be silently discarded if there is no free vMAC
left for that subscriber.

NT
15.11.2.4 DSL/Eth vMAC format

In the vMAC format, the DSLAM ID can be set by the operator, see Table 58.
To ensure uniqueness of the vMAC within the EMAN, vMAC cannot be enabled on
any network VLAN until the DSLAM ID has been programmed by the operator. It is
the responsibility of the operator to ensure that unique DSLAM IDs are assigned;
otherwise duplicate vMAC addresses may be generated by different DSLAMs.
Table 58 vMAC format for data traffic forwarding
MAC Address Configurable Description
Bit 47...45 No Rack ID (minus 1)
Bit 44 No ISAM xDSL vMAC set to 0

Bit 43...42 No Reserved field for other applications, set to 0’s for the vMAC
application
Bit 41 No U/L field set to 1 (local MAC address validity)
Bit 40 No I/G field set to 0 (unicast address)
Bit 39...21 Yes DSLAM ID set by the operator [1…524287]

A unique DSLAM ID within an EMAN connected to the same IP
edges
Bit 20...15 No Slot ID of the line board [0…63]
The logical position of the line board within the DSLAM.
Bit 14...6 No Port ID of the subscriber interface [0…511]
Bit 5...0 No MAC ID unique to each subscriber MAC address
15.11.2.5 xPON vMAC format

In the vMAC format, the DSLAM ID can be set by the operator, see Table 59.
To ensure uniqueness of the vMAC within the EMAN, vMAC cannot be enabled on
any network VLAN until the DSLAM ID has been programmed by the operator. It is
the responsibility of the operator to ensure that unique DSLAM IDs are assigned;
otherwise duplicate vMAC addresses may be generated by different DSLAMs.
Table 59 vMAC format for data traffic forwarding
Bit 47...45 Yes DSLAM ID part 1 (3 Most Significant Bits). Remaining bits: see Bit
39…27
Bit 44 No vMAC xPON MAC set to 1
Bit 43 No vMAC (0) / CFM MAC (1)
(1 of 2)

NT

Bit 42 No For vMAC always 0 / for CFM MAC (future; PON Identifier: OLT /
ONT)
Bit 41 No U/L field set to 1 (local MAC address validity)
Bit 40 No I/G field set to 0 (unicast address)
Bit 39...27 Yes GPON vMAC format DSLAM ID part 2 [1…64K]

A unique DSLAM ID within an EMAN connected to the same IP
edges
Bit 26...22 No Slot ID of the line board [0…31]

The logical position of the line board within the DSLAM.
Bit 21...8 No Port ID [0...16k]

Logical identification of the bridge port, unique within the DSLAM.
Bit 7 No Reserved
Bit 6...0 No MAC ID unique to each subscriber MAC address
(2 of 2)
15.11.2.6 DHCP Algorithm

The chaddr field of the DHCP messages must be translated as follows:
• Upstream: the subscriber MAC address is replaced by the associated vMAC
address
• Downstream: the vMAC address is replaced by the associated subscriber MAC
address
Note — When vMAC is enabled, the DHCP lease time must be

less than the MAC aging timer (on the ISAM or on the VLAN),
or else the vMAC address for the subscriber will be forgotten
before the DHCP session expires. In this case, when the
subscriber attempts to renew the session, it is possible that the
network is reached using a different vMAC address, causing it
to be discarded.
15.11.2.7 ARP Algorithm

The MAC address field present in the ARP message payload is updated in a similar
way as for DHCP.

NT
15.11.2.8 ICMPv6 Algorithm

The MAC address field present in the ICMPv6 Neighbor Discovery message payload
is translated as follows:
• Upstream Neighbor Solicitation (NS): translate the MAC address carried in the
“source link-layer address” option. This option contains the MAC address of the
routed modem (or PC behind a bridged modem), hence it must be translated to
the vMAC address;
• Upstream Neighbor Advertisement (NA): translates the MAC address carried in
the “target link-layer address”;
• Upstream Router Solicitation: translate the MAC address carried in the “source
link-layer address” option.
15.11.2.9 Ethernet OAM Algorithm

The MAC address field present in the payload of Ethernet OAM messages
exchanged with the subscribers is updated in a similar way as for the DHCP case.
15.11.2.10 User-to-user communication can optionally be

blocked
If an operator wants to share a VLAN across multiple DSLAMs, but the Ethernet
switches are unable to block user-to-user traffic, the operator can enable dedicated
filters at ISAM level to discard subscriber traffic received from other DSLAMs. Those
filters must be implemented so that they do not prevent using typical access network
topologies (for example, star, ring, dual homing, and so on).
The filter is implemented per VLAN at LT board level so that the NT board still
behaves as a normal bridge, in order to support all access network topologies (for
example, ring).
The LT filter discards any Ethernet packet received from the NT board within the
specified VLAN and whose MAC source address matches the non-DSLAM specific
fields of the vMAC (that is, DSLAM ID, rack/shelf/slot/Port/MAC IDs).
15.11.2.11 vMAC address - MAC address translation table

recovery
Enabling vMAC support makes the iBridge implementation state full. The ISAM
recovers the stable states in case of LT software failure, LT board reset or LT
software upgrade.

NT
In this manner, a correct vMAC-address-to-IP-address mapping is maintained to

avoid issues with:
• DCHP servers: for example, IP address lease renewal, where the subscriber is
identified using the vMAC (that is, chaddr)
• IP routers implementing IP address anti-spoofing by coupling the vMAC and the
IP address learned through DHCP snooping
15.12 PPP cross-connect mode

This chapter covers the so-called “PPP cross-connect forwarding mode”. Although it
shares many concepts with iBridges and VLAN CC L2 forwarders, this mode is quite
different.
PPP cross-connect is a forwarding mode in which the ISAM forwards traffic from PPP
sessions from the user side through PPP sessions at the network side towards a
BRAS and conversely, and this as long as the user PPP session is living. There is
always a 1:1 relationship between the PPP session at user side and the PPP session
at network side. This justifies the use of the term “cross-connect” which must be
understood as “PPP session cross-connect”.
Like iBridges and VLAN CC, a PPP cross-connect is defined in the context of a
network VLAN ID. A PPP CC forwarder (often called PPP CC Engine) interacts with
the user side world through PPP CC client port interfaces.
By nature the PPP session is PPPoE at the network side. The network VLAN of a
PPP cross-connect can be single tagged (like an iBridge or a C-VLAN cross-connect)
or dual tagged (like an S+C-VLAN cross-connect).
It should be noted that PPP cross-connect does not require that the user
encapsulation is Ethernet. It works as well with PPPoA as with PPPoE although the
PPP session setup handling is different:
• In case of PPPoA, the ISAM is responsible for setting up and releasing the PPPoE
session which will encapsulate the user PPP packets.
• In case of PPPoE, the PPPoE session is set up and released by the user himself
and the ISAM just relays it to the network side.
For this to happen, the following must take place:

• The operator statically configures the PPP cross-connect forwarder, which
network VLAN it uses and which users may use it. It is possible that multiple user
sessions are multiplexed via PPPoE in one N:1 network VLAN, and it is possible
that there is a 1:1 relationship between the user and the network VLAN.
• Each time a user initiates a PPP session, the ISAM goes though a dynamic PPP
session marking phase: during this phase, the ISAM sets up information
necessary to forward packets between user and network.
When the PPP session is terminated, the ISAM deletes the marked session
information.

NT
A property of PPP cross-connect is that the ISAM sends PPPoE packets to the
network using its own MAC address as source address. Thus, for the network, the
ISAM looks like the PPP client itself and actually performs user MAC address
concentration.
Note — It is possible - for legacy purpose - to configure PPP

cross-connect without MAC address concentration. In this
mode, only PPPoA traffic is accepted by the PPP
cross-connect, whereas PPPoE is automatically iBridged or
VLAN cross-connected to the same network VLAN as the PPP
cross-connect. When not specified, the term “PPP
cross-connect” must always be understood as “PPP
cross-connect with MAC address concentration”.
The general model of a PPP cross-connect engine with MAC address concentration
is quite intuitive. It is shown in Figure 235.
Figure 235 General PPP cross-connect engine
PPP CC Client Port PVC, EFM, VLANPort or GE
iBridge VLAN
PPPoE
PPPoE
or PPPCCE
PPPCCE
Server
Server
CC VLAN
PPPoA
&
PPPoE
In case of PVC
The VLAN which is attached to a PPP cross-connect Engine on the network side
must be of iBridge or VLAN cross-connect type. Of course, when the VLAN is of type
cross-connect, only one user is attached to the engine.
The type of interface on the user side on which a PPP client port can be configured
must be one of the following:
• EFM interface for untagged PPPoE traffic
• PVC for PPPoA and/or untagged PPPoE traffic
• Ethernet interface for untagged PPPoE traffic
• VLAN port interface for tagged PPPoE traffic
Note — It is not intended to create a client port on a bridge port.
The interfaces stack for PPP client ports is shown in Figure 236.

NT
Figure 236 Subscriber access interface stack for PPP client ports
PPP client port PPP client port PPP client port PPP client port
VLAN port
Bridge port
PVC EFM PVC EFM
ATM ATM
ADSLx VDSLx Eth Phy ADSLx VDSLx Eth Phy
Tagged PPPoE PPPoA or untagged PPPoE Untagged PPPoE

Frames Frames on PVC Frames on EFM or Eth Phy
All the supported encapsulations for PVCs are shown in Figure 237.
Figure 237 Accepted ATM encapsulation for PPP cross-connect Forwarding
with MAC address concentration
asamAtmVclEncapsAutodetect
Client
Client Port
Port disabled(1) or
autoDetectPPPoA(4)
PPPCCE
PPPCCE PPPoA
VC
VC asamAtmVclEncapsType
llcNlpid(3) or
vcMuxPppoa(6)
Client
Client Port
Port
Untagged
PPPCCE
PPPCCE
PPPoE
VC
VC asamAtmVclEncapsAutodetect
disabled(1),
asamAtmVclEncapsType
Client
Client Port
Port llcSnapBridged(1) or
Tagged vcMuxBridged(4)
PPPCCE
PPPCCE
PPPoE
VlanPortBridgePort VC
VLANPort VC
asamAtmVclEncapsAutodetect
autoDetectPPP(3) or
Client
Client Port autoDetectIpoePpp (5)
Port PPPoA
PPPCCE
PPPCCE
or asamAtmVclEncapsType
Untagged llcSnapBridged(1),
VC
VC
PPPoE llcNlpid(3),
vcMuxBridged(4),
vcMuxPPPoA(6)
PPP cross-connect implementation

NT
The object model of a PPP cross-connect depicted in Figure 235 is quite simple:
• a PPP cross-connect engine applying PPP cross-connect forwarding rules
• one network VLAN
• one or several client ports on top of PVCs, VLAN port interfaces, EFM interface
or Ethernet interface to attach users
Note 1 — PPP cross-connect is not supported in Hub-ISAM LT

NNI and GE Ethernet LT HC-UNI and 10GE Ethernet LT ports.
Note 2 — PPP cross-connect is not supported in GPON and
15.12.1 PPP Cross-connect inside the ISAM

PPP cross-connect forwarding is implemented by a cooperation of functions in the
LT board and NT board as shown in Figure 238.
Note — PPP cross-connect is not supported in GPON or

Figure 238 PPP cross-connect inside the ISAM

PVC, EFM, VlanPort or EthPhy
PPP CC Client Port
PPP CC Engine
L2 Fwd PPPCCE
PPPCCE
EMAN L2 Fwd
LT
NT
DSLAM

NT
15.13 Dynamic VLAN

Different from traditional static configuration VLANs for end-user services, ISAM also
provides the dynamic assignment of VLANs as may particularly be needed in
enterprise environments when connecting devices such as IP-cameras, sensors,
PCs, printers, VoIP phones with PC cascading and so on to network based services.
This feature allows for the association of the end users towards a network service
VLAN, based on IEEE 802.1X (Radius) authentication results.
In addition to determining the service VLAN association, the 802.1X authentication
results can also lead to modification of the users QoS profile as well as to the
application of MAC Address Bypass in authentication.
Note — In the current implementation of the feature, ONT UNIs

extended by switches or multiple dummy devices connected to
the same UNI are not covered.

System Description for FD 100/320Gbps NT and FX Protocol handling in a Layer 2 forwarding model
NT
16 Protocol handling in a Layer 2

forwarding model
16.1 Introduction
16.2 Link Aggregation
16.3 RSTP and MSTP
16.4 Ethernet Ring Protection Switching (ERPS)
16.5 Connectivity Fault Management
16.6 802.1X support
16.7 ARP
16.8 DHCP
16.9 IGMP
16.10 PPPoE
16.11 DHCPv6
16.12 ICMPv6
16.13 LLDP
16.1 Introduction
Layer 2 protocol handling can be divided into two parts:
• Layer 2 Control Protocol handling:
Layer 2 Control Protocols are protocols defined for use within the Layer 2 network.
They are defined to influence the forwarding behavior within this Layer 2 network
and/or to maintain and troubleshoot this Layer 2 network. This includes protocols
that have an individual or group of interfaces as scope, and it includes protocols
that have the end-to-end connectivity within this Layer 2 network as scope.
• Application protocol handling:
These are protocols defined at a layer higher than Layer 2. They are used for
communication between nodes connected to the Layer 2 network and/or nodes
deeper in the IP (Layer 3) network. Participation of the ISAM - being the boundary

Protocol handling in a Layer 2 forwarding model System Description for FD 100/320Gbps NT and FX
NT
node of the service provider network - in processing these protocols, enables the
general network or nodes deeper in the network to provide better services to
subscribers.
Note — MPLS-related protocols are handled in chapter

“MPLS”.
16.1.1 Layer 2 Control Protocol handling

Table 60 shows the protocols of the Layer 2 control protocol handling.
Table 60 Layer 2 control protocol handling
Protocol Described in Section

Link Aggregation 16.2
Rapid Spanning Tree Protocol and Multiple Spanning Tree Protocol 16.3
Ethernet Ring Protection Switching (ERPS) 16.4

Connectivity fault management 16.5
802.1X 16.6
Note 1 — VULA (Virtual Unbundled Local Access) links are

links used to directly interconnect the ISAM to Content
Providers in some network architectures. These links are
hosted by an Ethernet LT acting as uplink interface.
Note 2 — As indicated in the chapter describing L2 forwarding,
the VULA uplinks are transparent to subscriber related control
protocols, these aspects being handled at the user interfaces.
Note 3 — The VULA uplinks do not offer dual homing based link
redundancy and consequently do not support protocols like
RSTP/MSTP, ERPS and IGMP.
16.1.2 Application protocol handling

Table 61 shows the protocols of the application protocol handling.

NT
Table 61 Application protocol handling
Protocol Described in Section
ARP 16.7
DHCP 16.8
IGMP 16.9
PPPoE 16.10
DHCPv6 16.11
ICMPv6 16.12
LLDP 16.13
These protocols play an important role in the way subscribers establish connectivity
and/or access broadband services. The ISAM supports a set of protocol processing
features in order to maintain network security and allow customer identification and
troubleshooting. These are defined in the next sections.
The use of these control protocols can lead to security issues when malicious users
try to perform a (Distributed) Denial of Service attack towards the systems handling
the user-generated control traffic (for example, a BRAS, an Edge Router or a DHCP
server). In order to protect these systems, the ISAM can be configured to perform
upstream policing for the following protocols: ARP, DHCP, DHCPv6, IGMP, ICMPv6,
PPPoE and Connectivity Fault Management. The policing rate and maximum burst
size can be configured separately for each of the mentioned protocols.
Note that the protocol policer operates in a specific way for IGMP packets: rather
than policing on the number of IGMP packets, it will take into account the fact that
one IGMP packet may include requests for several multicast groups. Hence, the
protocol policer will calculate the equivalent number of "virtual IGMP packet" and use
this as input to the policer.
16.2 Link Aggregation

Link Aggregation allows one or more links to be aggregated together to form a Link
Aggregation Group, such that a MAC client can treat the Link Aggregation Group as
if it were a single link. Link aggregation is defined in IEEE 802.3-2005, clause 43.
This specification specifies the establishment of Link Aggregation Groups, consisting
of N parallel instances of full duplex point-to-point links operating at the same data
rate.
This Link Aggregation Group provides increased bandwidth and/or increased
availability. Link aggregation is defined with a load sharing mechanism that
distributes the traffic over the active links of the Link Aggregation Group. When one
of the physical links of the link Aggregation Group is no longer active, then the load
sharing adapts and distributes the traffic over the remaining active links. If the total
traffic exceeds the bandwidth of an active link, then normal QoS handling applies.
Figure 239 shows an example of link aggregation.

NT
Figure 239 Link aggregation

IP Edge Router /
BRAS
Link Aggregation
Ethernet
Group 1 NSP IP backbone
Bridge
NE
ADSL
m x FE/GE
FE/GE n x FE/GE
EMAN NSP IP backbone
Link Aggregation
Group 2
NSP IP backbone
Link Aggregation is defined for use between any type of Ethernet nodes (that is, both
bridges and end stations). The binding of links into Link Aggregation Groups may be
under manual control by an operator. In addition, automatic determination,
configuration, binding, and monitoring may occur through the use of a Link
Aggregation Control Protocol (LACP).
If enabled by the operator, the cost of the Link Aggregation Group, as used by OSPF
for making routing decisions, is based on the available aggregated operational
bandwidth.
16.2.1 Link Aggregation Control Protocol

The Link Aggregation Control Protocol (LACP) is part of the IEEE 802.3-2005 clause
43. The LACP provides a standardized means for exchanging information between
Partner Systems on a link to allow their Link Aggregation Control instances to reach
agreement on the identity of the Link Aggregation Group to which the link belongs,
move the link to that Link Aggregation Group, and enable its transmission and
reception functions in an orderly manner.
Also the use of LACP requires some operator control. Especially important is the
configuration of actor-keys per physical link. This parameter identifies the Link
Aggregation Group and is exchanged within the protocol to the peer side to assure
that the links of one link aggregate really connect to the same node.
When an inconsistency is detected between the configured information and the
connectivity of a link, the involved link is not activated.
If a link fails, this is detected by LACP. It removes the link from the active set of the
link aggregate. When the link comes up again, LACP puts the link back in the active
set of the link aggregate.

NT
16.2.2 Link aggregation support

Link aggregation is supported on:
• network links hosted by the NT or the 10GE Ethernet line card (that is VULA
uplinks)
• subtending links to remote nodes connected to either the NT or to a GE or 10GE
Ethernet line card NNI port.
• user links connected to a GE or 10GE Ethernet line card UNI port.
For LAGs hosted by the Ethernet LT cards, all link members must be of the same
speed and type.
LAG can be deployed according to two main schemes:
• Intra-LT LAG
• All link members must be hosted by the same Ethernet card.
• Load sharing operations, with or without LACP. Up to eight links per LAG.
• Inter-LT LAG
• The link members must be hosted by two adjacent Ethernet cards.
• Only Active/Standby operations with LACP enabled are supported for up to 8:8
configurations.
Table 63 shows the supported configurations.

Table 62 Supported LAG configurations
Ethernet LT variant Intra-LT LAG Inter-LT LAG
GE LT UNI, NNI -
10GE LT VULA Uplink, NNI, UNI VULA Uplink, NNI, UNI
The ISAM NT interacts with the network side by means of SAPs and/or MPLS
Pseudowires:
• SAPs facing the network side are configured on regular access ports, not on
network ports.
• MPLS Pseudo Wires are always facing the network side and are exclusively
configured on genuine network ports.
The ISAM NT exclusively interacts with the subscriber side (that is, LT boards,
directly attached subscribers or subtending ISAMs) by means of SAPs:
• SAPs facing the subscriber side are configured on residential access ports.
LAG is currently supported only on regular access ports and those residential access
ports used for subtending.

NT
Link Aggregation Groups are defined by configuring individual physical links with
identical link aggregation parameters. Especially the parameter actor-key is
important as the Link Aggregation Group is defined as the set of links with the same
value for this parameter.
The use of the LACP protocol can be enabled or disabled.
Load balancing across links is supported. Depending on the type of traffic (L2, IP,
MPLS) the load balancing is based on the combination of traffic parameters like
SrcMAC, DstMAC,SrcIP, DstIP, Tunnel/Service Label, Physical Port and/or
TCP/UDP Port numbers.
This load balancing algorithm is not user configurable.
Figure 240 shows link aggregation support.
Figure 240 Link aggregation support
Network Subscriber
side side
SDP
bindings
SDPs
EMAN LAG
EMAN
LAG
LT
LT
NT
Residential access port
Regular access port
Network port
SAP
Note — Link aggregation is not supported on subscriber links

(with the exception of the P2P Ethernet LT board subscriber
links).

NT
16.2.3 Active / Standby Subgroup in Link Aggregation

Access Nodes connected to Upstream Network Equipment (Bridges, Routers and
Servers) need to protect against various kinds of upstream failures:
• Protection against Uplink level failures
• Protection against Upstream NE circuit pack failures
• Protection against Upstream NE failure
Link Aggregation subgroups are configured by combining physical links of a Link
Aggregation Group in a subgroup. The subgroups are supported for static and
dynamic (LACP enabled) Link Aggregation Groups.
The subgroups are given a preference value and a threshold. On this basis, the
subgroup will act as an active subgroup or as a standby subgroup.
The subgroup with the highest preference will always be selected as the active
subgroup. When the threshold on the active subgroup reaches a pre-defined
threshold, the subgroup with the next highest preference will be selected as active.
It is essential that the IP address and MAC address of the links on the two upstream
network elements be configured identically towards the Access Node.
Multiple links of a Link Aggregation Group from redundant control cards and / or
NTIO cards can be combined to form the Link Aggregation Subgroup.
Figure 241 Active / standby subgroup for aggregation
Active Upstream
Subgroup NE 1
APS
L
Logic A EMAN
G
Standby
Subgroup Upstream
NE 2
16.2.3.1 Static LAG Subgroups

In case of static subgroups the link state of standby subgroups are not known
(physical link state is down). As a result, static subgroups only support non-revertive
behavior.
After initialization or changing LAG operation status (shutdown / no shutdown), the
most preferred subgroup will be made active based on the preference value.

NT
In non-revertive mode of static LAG the current active subgroup will continue to carry
traffic as long as the threshold is not reached. Once the threshold is reached, a
switchover is initiated by bringing down links of current active subgroup. This is
followed by designating the standby subgroup as active and the links of the newly
active subgroup are enabled.
In case the number of links, coming up during the switchover, is less than the
threshold, the newly designated active subgroup continues to be active. This
condition is cleared if the operator forces a manual switchover to a subgroup or the
number of links in the newly active subgroup exceeds the threshold.
If during switchover no ports / links are active on the standby side for a pre-configured
time, then the switchover is aborted.
16.2.3.2 Dynamic LAG subgroups

LACP-based LAG subgroups support both revertive and non-revertive behavior.
In revertive behavior the most preferred subgroup remains the active subgroup as
long as the number of active links exceeds the threshold value. In case the threshold
value is reached the traffic will switch over to the standby subgroup and will be
restored to the active subgroup once the number of active links exceeds the
threshold value.
In non-revertive mode, once the switchover from active to standby subgroup takes
place, the traffic continues on this newly active subgroup irrespective of the number
of active links exceeding the threshold value on the most preferred subgroup. Only
when the threshold value of this newly active subgroup drops below the threshold the
traffic will switch to the most preferred subgroup.
Similar to the NT cards, the Active/Standby LAG implementation of the 10GE
Ethernet LT supports following options:
• Always dynamic mode of operations (that is LACP enabled)
• Two sub-groups of LAG link members, each hosted by one of the two redundant
10GE Ethernet LTs. Traffic load sharing is applied among all links belonging to
the same 10GE Ethernet LT (that is sub-group), while only one LT carries traffic
by definition of the active/standby concept.
• The criteria for selecting an active subgroup can be controlled by operator as
follows:
• No threshold programmed: the sub-group with the largest number of active links will
be selected.
• Threshold programmed: a sub-group remains active until its number of active links
becomes smaller than the threshold. This mechanism allows to build in some
redundancy to reduce the switch-over frequency between the two sub-groups.
• Revertive or Non-Revertive mode.

NT
16.3 RSTP and MSTP

The ISAM can be configured with several network interfaces. They can be used to
connect the ISAM to multiple Ethernet Bridges, see Figure 242 as example, or
directly to end stations such as, for example, a Router or a BRAS.
For an Ethernet network to function properly, only one active path can exist
throughout an EMAN Network between two end stations. These paths are
symmetrical, that is, they are used for both directions of communication.
Figure 242 Spanning Tree between NE and EMAN
IP Edge Router /
BRAS
Ethernet
NSP IP backbone
Bridge
NE m x FE/GE
ADSL
FE/GE
EMAN NSP IP backbone
n x FE/GE
: Link disabled by spanning tree protocol NSP IP backbone

Selected root of spanning
16.3.1 RSTP
The Rapid Spanning Tree Protocol (RSTP) as defined in IEEE 802.1D-2004, clause
17, is a Layer 2 Control Protocol that provides path redundancy while preventing
undesirable loops in the network.
Providing path redundancy starts with having a physical redundant network topology.
Multiple active paths between end stations cause L2 loops in the network. If a loop
exists in the network topology, the potential exists for duplication of messages.
Therefore, the task of RSTP is defining a single active path between each pair of end
stations.
To realize this single active path, RSTP forces certain redundant data paths into a
standby (blocked) state. The logical topology that is realized in this way is a single
tree with a selected root end station and with the other end stations at leave
positions. Ethernet Bridges are involved in selecting the active path and blocking the
standby paths. After a network node or link has become unavailable, RSTP will run
again to define a new tree topology.

NT
16.3.2 MSTP
If the network contains more than one VLAN, the logical network configured by a
single RSTP would work, but better use can be made of the available redundant
nodes by using an alternate spanning tree for different (groups of) VLANs.
Multiple Spanning Tree Protocol (MSTP), which uses RSTP for rapid convergence,
enables VLANs to be grouped into a spanning-tree instance. Each instance has a
spanning-tree topology independent of other spanning-tree instances. This
architecture provides multiple forwarding paths for data traffic, enables load
balancing and limits the number of spanning-tree instances required to support a
large number of VLANs. MSTP is defined in IEEE 802.1Q clause 13.
16.3.3 Support of RSTP and MSTP

The ISAM can be configured to act as an Ethernet Bridge within an EMAN Network.
Then RSTP and MSTP are supported on network links, on subtending links, and on
subscriber links terminated on the NT board. The MSTP protocol is also supported
on the GE and 10 GE Ethernet LT board NNI port type.
The ISAM can be configured to act as Router. This router functionality is provided on
top of the Layer 2 Bridging functionality. All ISAM links are considered as being part
of a single EMAN Network. In that case, the ISAM acts as an end station connected
to this EMAN Network. Then, as before, RSTP and MSTP are supported within this
EMAN Network on network links, on subtending links, and on subscriber links
terminated on the NT board.
The GE and 10 GE Ethernet LT board NNI port type, used for access aggregation or
business services access (but not as a network uplink interface) also supports
RSTP/MSTP. The following restrictions apply:
• All interfaces must be of the same type (NNI) and located onto the same GE or 10
GE Ethernet LT board
• RSTP/MSTP is only supported with the iBridge model (no VLAN-CC)
• RSTP/MSTP on the Ethernet LT assumes the LT interface to be root bridge and
must be configured accordingly by the operator
• NT and LT xSTP instances are split, that is, the NT and LT links are not part of the
same protection domain. A link event failure at the LT side is not signaled by the
NT towards the network and inversely meaning that cross-LT or cross-ISAM link
protection schemes are not supported.
In some network topologies the use of RSTP or MSTP will not provide any benefit.
This is the case when the single active path is already realized at physical level. An
example is that the user equipment connected to LT boards (must) have already by
construction a single physical interface and inherently this will form a single active
path. Therefore and because of this RSTP and MSTP are not supported on these

NT
interfaces. Other examples are the use of a single link (aggregation group) between
a hub and a subtending ISAM. Therefore, RSTP and MSTP can be enabled or
disabled per Ethernet interface of the ISAM. As an example, RSTP and MSTP shall
be disabled on the network interface of the subtending ISAM in case it is disabled on
the corresponding subtending interface in the Hub ISAM.
Note 1 — The 7302 ISAM supports RSTP and MSTP towards
DSLAMs in a ring.
Note 2 — The 7302 ISAM and the 7330 ISAM FTTN supports
STP (IEEE 802.1D-1998, clause 8) for inter-operability with
older routers.
Note 3 — The terminology of network links, subtending links,
and subscriber links is not used on the management interface
of the ISAM. The operator configures a link as “regular” to make
it behaving as a network link and configures it as “residential” to
make it behaving as subtending or subscriber link.
Note 4 — RSTP and MSTP shall only be supported in the
m-VPLS. Only a single m-VPLS can be configured. RSTP and
MSTP do not run concurrently on the system.
Note 5 — No Spanning Tree protocol is supported on MPLS
Pseudo Wires (on Network links).
16.4 Ethernet Ring Protection Switching (ERPS)

Several ISAM nodes can be connected to each other in a ring topology in some
networks. In an Ethernet Ring, each Ethernet ring node is connected to adjacent
Ethernet ring nodes participating in the same Ethernet ring, using two independent
links.
The G.8032 ERPS standard defines the mechanisms and protocols to achieve a fast,
highly reliable and stable protection in case any link or node of an Ethernet ring fails.
This mechanism ensures that L2 forwarding loops are never formed as forwarding
loops would fatally affect network operation and service availability. xSTP protocols
are not needed when ERPS is used and are disabled on the ring ports.
For ring protection G.8032 specifies a protocol known as the R-APS protocol that
runs between the nodes of a ring. The R-APS protocol messages are carried in a
dedicated VLAN known as the R-APS VLAN and is based on the Y.1731 Ethernet
OAM CCM message.

NT
Figure 243 Ethernet Ring Topology
A B
F C
RPL Link
Data VLANs
E D
ERP VLAN
RPL owner
Two modes of protection switching have been defined in G.8032: revertive mode and
non-revertive mode.
In the revertive mode after the condition(s) causing a switch-over has (have been)
cleared, the traffic path on the ring is restored to the normal working state, that is,
blocked on the RPL. Note that switching back to the normal state causes an
additional traffic interruption.
In the non-revertive operation, the traffic channel continues to use the RPL, if it has
not failed, after a switch condition has cleared. The operator has to block the RPL
link manually in order to restore the ring to the normal state.
Figure 244 Normal state of Ethernet Ring Protection
A B
F C
E D
RPL owner

NT
Figure 245 Path Failure and R-APS message flow to RPL Owner Node
A B R-APS
F C
R-APS E D
RPL owner
Each time a link failure occurs that affects reachability, the nodes that detect the
failure initiate R-APS messages on either side of the ring. The nodes that initiate
R-APS (Signal Fail abbreviated as SF) also flush their FDBs on the ring links. Every
node that receives the R-APS (SF) message also flushes the FDB. The RPL owner
unblocks the RPL link when it receives the R-APS message and initiates its own
R-APS messages in either direction. Every node that receives the R-APS messages
from the RPL owner once again flushes the FDB. The nodes that are connected to
the failed link periodically transmit the R-APS messages as long as the Signal Fail
condition persists.
Figure 246 Reconfiguration to protected path
A B
F C
E D
RPL owner

NT
16.4.1 Support of ERPS in ISAM

In the ISAM, ERPS is supported on uplink ports of ISAM-FD shelves with NANT-E
(1G and 10G), and on uplink ports of ISAM-FX shelves with FANT-F (1G and 10G)
and FANT-G (1G, 10G and 100G) NT boards. Note that these uplink ports can be on
any of the active/standby NT cards. The port mode shall be “access” or “hybrid”.
ERPS is supported on uplinks that are NTIO ports as well.
ERPS is not supported on VULA uplinks.
ERPS is supported on a single ring instance per pair of ports. The ISAM can act as
a node on the ERPS ring, with the RPL owner being a 7750 Service Router or third
party router. The ISAM can also act as the RPL owner: it supports dynamic election
of the RPL owner, as well as manual configuration of the RPL owner.
Sub-ring topologies are not supported.
ERPS in ISAM is supported for VPLS and v-VPLS services. A maximum of two ring
instances can be associated to the same pair of ports to assist traffic load balancing.
The maximum number of Ethernet Rings in an ISAM FD/FX shelf with NANT-E,
FANT-F, FANT-G boards supporting 100ms CCM interval is six.
16.4.2 Limitations of ERPS in ISAM

• RPL neighbor function is not supported.
• The failure protection occurs within one second; 50 millisecond switchover is not
guaranteed.
• Sub-rings and ladder topologies are not supported.
• ERPS is supported on LAG ports of ISAM, but with limited functionality:
• In a ring of ISAMs, link failures should still result in Automatic Laser Shutdown and
the other ports in the LAG should take over immediately
• Facility MEP is not supported. CCM messages can still be sent, but will only be sent
in a round robin on each link in the LAG. In case there is a failure on a few links of
the LAG, the failure will not be detected by the CCM messages unless and until CCM
messages fail on all the links of the LAG.
• A LAG failure will be indicated if the number of active ports in the LAG goes below a
configurable threshold. Only if the LAG failure condition exists, ERPS will be
triggered (and not in case of a few individual ports of the LAG failing). In case the
entire LAG goes down (could be due to the LAG configuration), then the failure needs
to be detected through LACP messages and switch-over performed.
16.5 Connectivity Fault Management

This section describes Connectivity Fault Management (CFM) and identifies the level
of support in the ISAM.

NT
Connectivity Fault Management (CFM) is an Ethernet Operations and Maintenance

(OAM) capability that allows service providers or network operators to verify and
isolate connectivity faults and configuration problems at layer 2 (Ethernet) . CFM is
specified in the standard IEEE 802.1ag and ITU-T Y.1731.
IEEE 802.1ag defines the generic CFM OAM procedures like Loopback, Link Trace
and Connectivity Check. ITU-T Y.1731 defines essentially the same procedures, but
extends those functionalities with Performance Monitoring like, among others, Frame
Loss & Delay Measurement and Alarm Indication Signal.
16.5.1 CFM elements

To support CFM functionality, network operators must configure software entities
called Maintenance Points (MPs) on selected bridge ports on the network. MPs are
points where CFM messages are inserted, extracted, or monitored to verify
connectivity within part of or within the whole of the Layer 2 network.
MPs are organized into Maintenance Domains (MDs) and Maintenance Associations
(MAs) on a network. Table 63 describes the CFM elements that must be configured
on an Ethernet network.
Table 63 CFM elements
CFM element Description
MD An MD corresponds to the administrative OAM domain and is assigned a level from 0 to 7.

A typical example is that an administrative OAM domain is defined per operator involved in
the offering of a service with the Layer 2 network.
Associated to an MD are one or multiple MAs.
MA An MA is defined as an OAM maintenance entity per service instance per MD. The service
instance could be a VLAN or a set of VLANs. The OAM maintenance entity scope is defined
by a set of associated Maintenance end Points (MEP). The MEPs define a closed segment
of the VLAN in the Layer 2 network. The segment matches the scope or involvement of a
particular administrative OAM domain (operator) in that VLAN.
As such, MDs/MAs allow network operators to test the segment of a given VLAN that is within
their own scope. For example, it allows them to perform a test on all links and nodes of their
own network and being used by the VLAN or service. Typically, the set of operator segments
are all at the same MD level and then the MDs/MAs cannot overlap.
MDs/MAs also allow network operators to divide a network into separate hierarchical
administrative OAM domains. An MD/MA at a higher level has no visibility inside an MD/MA
at a lower level. Also at the higher level the same concepts apply: the scope is delimited by
MEPs and the MDs/MAs at the same higher level cannot overlap.
There may be one or more MA, that is, service instances, per MD. There may be multiple
MAs for the same service instance (VLAN) if these are within different MDs and the lower
level MDs/MAs are terminated with MEPs.
(1 of 2)

NT
CFM element Description

MP MPs are organized into MAs and MDs and are configured on ports within an MD/MA (VLAN).
There are two types of MPs:
• Maintenance end points (MEPs)
• Maintenance intermediate points (MIPs)
MEPs are points that identify the border of a maintenance entity. MEPs can initiate or
terminate CFM messages.
MIPs are points inside the network segment that is defined as a maintenance entity. MIPs
can respond to and allow the transit of CFM frames originated from another MP.
(2 of 2)
Broadband Forum TR-101 section 7 defines the usage of the OAM entities and
procedures in a Layer 2 Access Network. Broadband Forum TR-156 section 6
defines the OAM-related requirements in the context of a (G)PON Access Network.
Broadband Forum TR-167 section 8 defines the OAM-related requirements in the
context of a (G)PON Aggregation Network.
An access aggregation network typically has the following MD levels (in decreasing
order):
• Customer domain, spanning from the BNG up to the CPE/RG
• Carrier domain, spanning from the BNG (in case of normal broadband access
model) or Ethernet Aggregation node (in case of broadband access with
wholesale services model) up to the user access port on the Access Node;
• Intra-carrier domain, spanning from the BNG (in case of normal broadband
access model) or Ethernet Aggregation node (in case of broadband access with
wholesale services model) up to the network uplink (WAN port) on the Access
Node;
• Access link domain, spanning from the user access port on the Access Node up
to the CPE/RG.
There are eight possible MD levels in total, numbered 0-7. The values are not
imposed by the standards, however the following constraints must be respected: the
Customer level must have a higher value than the Carrier level, which must have a
higher value than the Intra-Carrier level, which must have a higher value than the
Access Link level.
Note that in the context of GPON Access, the Access Node designates the
combination of the OLT and the ONU, with an ODN connecting the two entities (as
opposed to only one DSLAM device in a DSL Access context).
Figure 247 represents those entities in a typical access and aggregation network,
with a DSLAM as an Access Node. Note that the MD level values shown are typical,
but illustrative.
When a customer contacts the service provider helpdesk because of lack of service,
the service provider can run a test in the service provider domain from the BNG
toward the CPE/RG. If the fault is isolated to a specific section, the service provider
can notify the owner of that section who can run tests at a lower level within his
domain. This continues until the failing point is identified.

NT
Figure 247 CFM on the access aggregation network

MD Service provider
MD level 7
MD carrier
MD level 5
MD Intra-carrier
MD level 3
Access link MD
MD level 1
CPE
Ethernet
access Regional
network network
RG Ethernet
DSLAM
switch BNG
MEP Scope of access Scope of service

MIP network operator provider operator
16.5.2 CFM functions

The CFM protocols define multiple functions that act as tools to test and measure the
connectivity and to isolate connectivity faults in the network.
The CFM link trace acts as an ICMP traceroute command. Multicast Link Trace
Messages (LTMs) are sent from the originating MEP and are addressed to another
MEP of the MA. Each MIP along the trace path inspects the message to determine
whether the target MAC address of the LTM is known. If the MIP knows the MAC
address, the MIP forwards the LTM to the MEP, and a response in the form of a Link
Trace Reply (LTR) message is sent back to the originating MEP. An MIP that does
not know the target MAC address does not send back an LTR. When the target MP
responds with a successful LTR message, the link trace test is successfully
completed.
A CFM loopback acts as an ICMP ping command. Multicast or unicast loopback
messages (LBMs) are sent from the originating MEP. In the case of a unicast LBM,
the MAC address of the destination MP is inserted. When the target MP receives the
LBM with the matching MAC address, it sends back a loopback response (LBR) to
the originating MP. When the originating MP receives the LBR, the loopback is
complete. In the case of a multicast LBM, each MEP within the targeted MA in the
MD level that receives the LBM request will reply with an LBR.
Connectivity check messages (CCMs) are messages multicast to all MEPs in the
same MA at fixed intervals. When a MEP did not receive a specified number of CCMs
from (one of) its peer MEP(s) in a given time, a fault is raised.

NT
The above Fault Monitoring (FM) functions are defined in both IEEE 802.1ag and
ITU-T Y.1731 standards. The Performance Monitoring (PM) functions, such as loss
and delay measurement, are defined in ITU-T Y.1731. The ISAM supports a number
of FM and PM functions on the different NT and LT boards, depending on the
transport technology used.
16.5.3 CFM support in the ISAM

The ISAM supports the configuration of MDs, MAs and MEPs. MIPs are auto-created
by the ISAM based on the parameter setting of the MA.
The service instance managed by an MA covers a single VLAN. The MEPs at both
ends of such an MA are thus referred to as VLAN-aware MEPs.
16.5.3.1 ISAM equipped with xDSL LTs

The system supports network facing MEPs at the DSL ports (Up-MEPs) for the
following functions:
FM:
• Reception of LoopBack Message (LBM) and generation of LoopBack Response
(LBR)
• Reception of Link Trace Messages (LTM) and generation of Link Trace Response
(LTR)
• Generation of on-demand LBM and/or LTM towards the network
• Generation/reception of Continuity Check Messages (CCMs) to/from network
PM (below items are subject to LT board capabilities):
• Reception of Synthetic Loss Measurement (SLM), generation of Synthetic Loss
Reply (SLR)
• Generation of on-demand Synthetic Loss Measurement (SLM), reception of
Synthetic Loss Reply (SLR)
• Generation of on-demand and pro-active Synthetic Loss Measurement (SLM),
reception of Synthetic Loss Reply (SLR)
• Reception of Delay Measurement Message (DMM), generation of Delay
Measurement Reply (DMR)
• Reception of Loss Measurement Message (LMM), generation of Loss
Measurement Reply (LMR)
• Generation of LMM, reception of LMR for proactive measurement of traffic loss

NT
• Remarks:
• loss measurements supported in either of two modes: per pbit or per VLAN
(aggregate of all dot1p priorities);
• for (SLM- or LMM-based) loss measurement tests, support calculation of frame loss
and frame loss ratio
• for proactive measurements, maintain historical counters for 15 minute and 1 day
intervals.
The system also supports MIPs at the DSL ports, GE UNI ports, GE NNI ports and
GE HC-UNI ports for the following functions:
• Receive and respond to LBM and to LTM from the network
On DSL LTs, the system also supports network-facing MEPs at the LT uplink
(Down-MEPs). Within these MEPs the ISAM can receive LBMs and LTMs coming
from the network and respond with LBRs and LTRs, respectively.
16.5.3.2 ISAM equipped with P2P GE Ethernet LTs:

On P2P GE linecards, the ISAM supports network facing MEPs on the LT backplane
interface (Down-MEPs) and at its GE UNI ports (Up-MEPs), but not on the GE
HC-UNI/NNI ports. Within these MEPs the ISAM can receive LBMs and LTMs
coming from the network and respond with LBRs and LTRs, respectively.

NT
Figure 248 MEPs supported on ISAM equipped with DSL or P2P GE LTs
Up MEPs
Down MEPs DSL (PTM)/
PVC (ATM)
Up MEPs
DSL (PTM)/
DSL-LT PVC (ATM)
Up MEPs
GE UNI
Eth Phy
Uplink
Up MEPs
GE UNI
Down MEPs
NT
(No Up MEP
support)
GE NNI/
(No Down MEP HC UNI
support)
ISAM
(No Up MEP
support)
GE NNI/
HC UNI
NELT-B LT
16.5.3.3 ISAM equipped with P2P 10 GE Ethernet LTs:

Figure 249 MEPs supported on ISAM equipped with DSL or P2P 10 GE LTs

NT
The VULA uplinks of the 10GE Ethernet LT support on-demand connectivity

validation according to the following scenarios:
• LBM/LTM between the VULA uplink and the aggregation network: Up-MEP/MIP
(both Originator and Responder roles)
• LBM/LTM between the VULA uplink and the end user: Down-MEP/MIP (both
Originator and Responder roles)
The UNI supports MIP and Up-MEP for following scenarios:

• LBM/LTM responder and originator
• AIS processing by Up-MEP with following options:
• Escalate the AIS received from the network to a higher maintenance level and pass
it to the end user.
• Shutdown the Ethernet port to signal network issues to an end user device that would
not support AIS processing.
This feature, combined with the Facility MEP supported by the NT card (see section
16.5.3.4), allows to inform the end user device about any network failure, triggering
that device to enable end-to-end path protection, that is:
• Network failures result in sending AIS to the ISAM, ending up at the LT interfaces.
• Uplink failures result in internally generating AIS from the NT to LT interfaces.
• The LT interface either propagates the AIS or shutdown the Ethernet port in
function of the configuration options.
• The end user device, triggered by receiving either an AIS or detecting its uplink
failure, starts looking for alternate route.
16.5.3.4 ISAM equipped with PON LTs

For PON access solutions (system with GPON or XGS-PON / TWDM-PON LTs to
which ONTs are connected), the operator can configure the MD, MA, MEP and MIP
objects as follows:
• within a given MD, the ISAM allows to configure a VLAN-aware MA on an ONT.
The MEP configured on the ONT UNI to terminate such MA is facing the network
(Up-MEP). Such MEP can receive LBM/LTM from the network, and respond with
LBR/LTR respectively. The configuration is conveyed to the ONT through OMCI
MEs;
• within a given MD, the ISAM allows to configure a VLAN-unaware MA on the ONT.
The MEP configured on the ONT UNI to terminate such MA is facing the
end-subscriber or the residential gateway (Down-MEP). Such MEP can receive
LBM/LTM from the subscriber, and respond with LBR/LTR respectively. The
configuration is conveyed to the ONT through OMCI MEs;
• within a given MA in an MD, the ISAM also allows to configure a network-facing
MEP on the uplink of the PON LT. Such Down-MEP can process unicast LBM
coming from the network or generated by the NT and respond with LBR.

NT
• within a given MA in an MD, the ISAM also allows to configure a network-facing

MEP on the virtual bridge-port of the PON LT. Such Up-MEP can process unicast
LBM coming from the network or generated by the NT and respond with LBR.
• the ISAM also allows to configure a MEP such as when it receives an alarm
indication signal (AIS), it propagates the AIS to an MA at the higher MD level in its
opposite direction (that is, away from the fault). An option also allows to configure
the ONT UNI such as it autonomously goes operationally down when its
corresponding Up-MEP detects a downstream AIS coming from the network. The
configuration is conveyed to the ONT through OMCI MEs.
For voice services via ONT RJ-11 & ETH UNI, the ISAM supports CFM on an iBridge
VLAN. Please refer to the ONT user documentation for a more complete description
of the supported CFM functions on the optical network units.
16.5.3.5 ISAM equipped with IHUB NT

The system supports the following on NT:
• configuration of MIP and Down-MEP on network-facing V-VPLS SAP and VPLS
SDP
• configuration of Up-MEP on LT SAP (that is the internal LT port on the network
card)
• configuration of a facility MEP on network-facing interfaces, in charge of
propagating any uplink failure event by injecting AIS messages into the various
v-VPLS SAP instantiated on top of that uplink and where AIS propagation is
enabled.
• support generation of LTM and unicast LBMs from a MEP, towards the user and
towards the network
• support reception of LTM and unicast/multicast LBMs, from NT and user
• support reception of LMM (single ended loss measurement) messages and
generation of LMR messages on V-VPLS SAPs and VPLS (VLAN SAPs)
• support for reception of DMM (two way delay measurement) messages and
generation of DMR messages on V-VPLS SAPs and VPLS (VLAN SAPs)
• support for generation/reception of LMM (single ended loss measurement)
messages and generation/reception of LMR messages on V-VPLS SAPs and
VPLS (VLAN SAPs)
• support for generation/reception of DMM (two way delay measurement )
messages and generation/reception of DMR messages on V-VPLS SAPs and
VPLS (VLAN SAPs)
• support for generation/reception of SLM (synthetic loss measurement) messages
and generation/reception of SLR messages on V-VPLS SAPs and VPLS (VLAN
SAPs)
• support for calculation of frame loss, frame loss ration and frame delay for Y.1731
tests

NT
• support for15 min and 1 day historical counters for Y.1731 tests
• support for generation and processing of CCM Messages on Down-MEPs on
network facing V-VPLS SAPs and VPLS SDPs
16.6 802.1X support

The 802.1X protocol complies with both the IEEE 802.1X and the CCSA
specification. Its purpose is to control the access of users to the Layer 2 Access
Network. It applies to both point-to-point networks based on DSL or Ethernet access
and to point-to-multipoint networks based on GPON or XGS-PON / TWDM-PON.
Each 802.1X enabled user port is by default in a closed status and successful
authentication is needed to open the port.
Packets from unauthenticated subscribers are dropped at the LT until an 802.1X
session is set-up after authentication by an external RADIUS server, see Figure 250.
• For an un-authenticated port, all subscriber frames are discarded.
• For an authenticated port, all subscriber frames are processed based on the
Layer 2 configuration
In the case of GPON and XGS-PON / TWDM-PON, 802.1X authentication involves

the Residential Gateway, the ONT and the OLT. The Residential Gateway supports
the 802.1X supplicant and is connected to the ONT located at the customer
premises. The ONT forwards the authentication messages to the OLT, which in turn
act as the 802.1X Authenticator. The authentication is done for the ONT UNI port.
Note 1 — To speed up port authentication, the ISAM sends an
EAPOL message towards the CPE or ONT as soon as the port
is in service. When the message is sent, the 802.1X port state
is moved to "connecting" state. In deployment scenarios
whereby the 802.1X supplicant does not exist on the CPE or
ONT (for example bridged CPE or ONT), the port will appear in
"connecting" state until a residential gateway (which contains
the 802.1X supplicant) is connected to the CPE or ONT.
Note 2 — The GE Ethernet LT board HC-UNI and NNI ports and
all 10GE Ethernet LT interface types do not support 802.1X.
Note 3 — The TWDM-PON LT card UNI ports do not support
802.1X in the current release.

NT
Figure 250 802.1X in the ISAM
LT IHub Ethernet ER
802.1x Performs authentication

NT by means of contacting
LT a RADIUS server.
Control The result is sent back
CPE
to the LT.
Handles the 802.1x protocol, communicates with the system

controller to perform the authentication, controls the port state.
16.7 ARP
The IETF RFC 826 defined Address Resolution Protocol (ARP) is a protocol defined
within the context of using IP over Ethernet. An IP node uses the ARP protocol to
obtain the Ethernet MAC address of another IP node identified by a known IP
address and connected to the same Layer 2 network.
The ISAM provides ARP handling functionality sufficient to prevent broadcast storms
toward the subscribers. This is achieved in the following ways:
• iBridge mode
• When an ARP request is received from a user port, the ARP request is broadcast to
the Ethernet network interface only. This deviates from the standard Ethernet
broadcast because the ARP request is not broadcast to the other user ports. This
behavior is also true for the GE Ethernet LT board NNI ports.
• When an ARP request is received from an Ethernet network interface, the ARP
request is only broadcast in the VLAN when downstream broadcast is enabled in the
VLAN. Otherwise, the ARP request is dropped. In case of P2P Ethernet and PON LT
board NNI ports, the ARP request is always broadcast in the VLAN (not
configurable).
For GPON and TWDM-PON access solutions, the above description is also
applicable to stacked iBridge mode.
• ARP reply messages receive no special treatment compared to any other data
packet.
• in VLAN cross-connect mode:
ARP requests are forwarded transparently downstream and by default are policed
upstream using the control protocol packet policer. A system level configuration
allows RIP/ARP frames to be either policed by control packet policer or be treated
as data frames for upstream session based policing.

NT
• in both forwarding modes:

ARP reply messages receive no special treatment compared to any other data
packet.
• in Secure-forwarding-enabled iBridge/VLAN cross-connect mode
An ARP relay function exists to forward the downstream ARP request messages
to the right user only. This is achieved by forwarding downstream ARP request
messages to the user port that owns the IP address that is to be resolved via the
ARP request.
In the upstream direction this ARP relay will perform IP address anti-spoofing, that
is, it checks the <IP,MAC> binding of a specific customer, learned via DHCP
snooping. An ARP packet is only accepted if the MAC source address and the IP
source address in the ARP payload correspond to a specific customer having
established IP connectivity on that port. Valid ARP requests will be forwarded to
the network. In case of static IP address configuration, the ARP relay performs a
similar check for the sender IP address. The packet is accepted if this address is
configured on that port.
The ISAM supports counters that track the number of ARP packets that have
been dropped per VLAN port because they contain spoofed information in the
ARP payload.
Note 1 — The ARP relay function learns the IP addresses from

the end-users either via DHCP snooping or via static
configuration.
Note 2 — The P2P Ethernet LT board NNI ports do not support
secure forwarding.
Note 3 — For DSL LTs, GE and 10GE Ethernet LT board UNIs,
the above description also applies to S+C iBridge forwarding
mode.
Note 4 — For GPON and TWDM-PON LT boards, the above
description also applies to S+C iBridge forwarding.
Note 5 — For GPON and TWDM-PON LTs in S+C
cross-connect mode, secure forwarding cannot be enabled
16.8 DHCP
The Dynamic Host Configuration Protocol (DHCP) is a client-server protocol that
enables DHCP Servers to configure internet hosts. The DHCP protocol is defined on
top of UDP/IP. DHCP simplifies the configuration of a host since no IP addresses,
subnet masks, default gateways, domain names, or DNSs must be locally configured
within the host. Instead, with DHCP, this information is dynamically leased from the
DHCP Server for a predefined amount of time. Because the information is stored on
a server, it centralizes IP address management, it reduces the number of IP
addresses to be used, and it simplifies maintenance. DHCP is defined in IETF RFC
2131.

NT
A problem to solve when using this technology is that the DHCP Client must be able
to communicate to the DHCP Server. This is achieved by the DHCP Client starting
the communication with a broadcast message. The DHCP Server will receive this
message in case the server is connected to the same Layer 2 network as the client.
IETF RFC 2131 and RFC 3046 define a DHCP Relay Agent for when this is not the
case. Then a DHCP Relay Agent connected to the Layer 2 network of the Client will
convert the broadcast message to a unicast message and send it to a server further
in the IP network. In doing so, the DHCP Relay Agent can add 'option 82' information.
That information can be used by the DHCP Server to identify the subscriber, and
when mirrored back in reply messages it helps the DHCP Relay Agent to forward the
replies to the correct client. In its definition this DHCP Relay Agent is a function within
a router for which it can be referred to as a 'Layer 3' DHCP Relay Agent.
Broadband Forum TR-101 defines a “Layer 2” DHCP Relay Agent, that is, a Relay
Agent functionality in the middle of the Layer 2 Access Network. The Layer 2 DHCP
Relay Agent is assigned to be a responsibility of the DSLAM. It shall add option 82
information (which allows the server to identify the subscriber) but leaves the
broadcast message a broadcast message. Converting the broadcast message to a
unicast message is not needed when the DHCP Server is connected directly to the
Layer 2 Access Network, or is the responsibility for a real Layer 3 DHCP Relay Agent
at the edge of the Layer 2 Access Network.
The ISAM provides Layer 2 DHCP Relay Agent functionality when it is configured for
Layer 2 forwarding and a full Layer 3 DHCP relay when it acts as an IP Router.
16.8.1 Layer 2 DHCP Relay Agent

The ISAM provides Layer 2 DHCP Relay Agent functionality for IPoE and IPoA
subscriber access interfaces for all of the Layer 2 forwarding modes that provide
IPoE and/or IPoA access:
• the iBridge,
• the protocol-aware cross-connect (that is, C-VLAN cross-connect and S/C-VLAN
cross-connect)
• the iBridge and cross-connect with IPoA to IPoE interworking function
The Layer 2 DHCP relay agent is supported for the L2 forwarding modes above,
irrespective of whether secure forwarding is enabled or not.
The Layer 2 DHCP Relay Agent functions can be split in two parts:
• Relaying DHCP messages to and from network and subscriber interfaces
• Option 82 handling
Ethernet line cards support a layer 2 DHCP relay agent on following interface types:
• GE Ethernet Line card: UNI and HC-UNI
• 10GE Ethernet Line Card: UNI and NNI, but only in the context of auto-configuring
a trusted remote node.

NT
16.8.1.1 Relaying DHCP messages to and from network and

subscriber interfaces
Relaying DHCP messages in iBridge and VLAN cross-connect
The Layer 2 DHCP Relay Agent for the iBridge and for the protocol-aware
cross-connect forwarding modes is distributed over the LT boards.
Figure 251 Layer 2 DHCP relay implementation)
US: Bridge to the network interfaces (unicast packet forward based on FDB, broadcast
packet: flood to all the network interfaces that participate in the VLAN
DS: Bridge to the LTs/subtending interfaces (unicast packet: forward based on FDB,
broadcast: flood to all network interfaces that participate in the VLAN
DHCP relay
LT IHub Ethernet ER
IP
DHCP client network
LT NT
CPE DHCP
server
US/DS: DHCP boadcast US: adds option 82 and sends packet to xHub
or unicast packet DS: remove option 82 and send on to correct user port
The DHCP client can send broadcast or unicast DHCP messages. These will be
forwarded in the upstream direction:
• if the insertion of option 82 is enabled, the ISAM verifies the DHCP message and
adds option 82 to a valid DHCP message as described further on.
• if the insertion of option 82 is disabled, the ISAM still verifies the DHCP message
as described further but does not add an option 82.
Again, note that, with or without option 82 insertion, in a Layer 2 DHCP Relay Agent,
the broadcast message remains a broadcast message, the unicast message
remains a unicast message. For more information on the handling and configuration
of DHCP Option 82; see section “Option 82 handling”.
In the downstream direction the DHCP Relay within the Edge Router (or the DHCP
server in case it is directly connected to the Layer 2 Access Network) sends
broadcast or a unicast DHCP messages. The choice between broadcast or unicast
depends on the broadcast flag inside the DHCP message sent from the DHCP
Client. In all cases the Layer 2 DHCP Relay Agent will forward the DHCP message
to the correct user only. For a unicast DHCP message the user is identified from the
MAC address in the Ethernet header. For broadcast DHCP messages the user is
identified from the payload of the DHCP messages, for example, chaddr. In any case
the option 82 is removed before forwarding the DHCP message.

NT
Relaying DHCP messages in the iBridge and Cross-connect mode with

IPoA-to-IPoE interworking function
The Layer 2 DHCP Relay Agent for the iBridge and cross-connect mode with IPoA
to IPoE interworking function is very similar to the Layer 2 DHCP Relay Agent when
the IPoA-to-IPoE interworking function is absent.
Its implementation is also distributed over the LTs.
The possibilities for option 82 insertion are also the same.
Note : IPoA packets from and to the user do not have an Ethernet header. As such,
the chaddr in the upstream DHCP messages is normally not a MAC address. The
ISAM inserts an identifier in the chaddr of upstream messages. This field being
returned by the DHCP Server allows the ISAM to identify the correct user. The ISAM
restores the original chaddr before sending the DHCP message to the user.
16.8.1.2 Option 82 handling

IETF RFC 3046 defines a “Relay Agent Information option” and assigns it the code
82. In this way the option is often referred to as “option 82". Option 82 provides
security when DHCP is used in public access networks. It provides the DHCP Server
with trusted information on who is requesting an IP address.
To make it really a trustable identifier the ISAM shall also discard upstream
messages with an option 82 already added by the user. Therefore the ISAM also
makes some validity checks on upstream DHCP messages.
In the upstream direction, the insertion of DHCP option 82 is configurable. If enabled,
option 82 parameters are inserted both for unicast and broadcast DHCP messages.
If disabled the ISAM obviously does not add option 82. The validity checks are
however executed also when option 82 insertion is disabled.
IETF RFC 3046 defines option 82 as containing two sub-options: the circuit-id being
sub-option 1 and the remote-id being sub-option 2.
A L2 DHCP relay agent on the 10GE Ethernet line card NNI interfaces can be
enabled to support auto-configuration of a node subtended from this card.
This supports addition of relay agent identifier sub-option 12, defined in IETF RFC
6925.
In addition to enabling or disabling option 82 insertion, it is possible to control the
insertion and contents of the sub-options:
• the circuit ID can be configured with one of the following values:
• do not add this sub-option into option 82
• add the customer ID into the circuit-id sub-option
• generate a physical line ID and add this into the circuit-id sub-option

NT
• the remote ID can be configured with one of the following values:

• do not add this sub-option into option 82
• add the customer ID into the remote-id sub-option
• generate a physical line ID and add this into the remote-id sub-option
Insertion of the circuit ID and/or remote ID can be enabled or disabled per VLAN in
iBridge or VLAN cross-connect mode.
16.8.1.3 Customer ID
The Customer ID is fully configurable for each DSL line, ATM PVC, Ethernet
interface or VLAN port by the operator (string with a length between 0 and 64 bytes).
In case the Customer ID is configured for one user at various levels, for example, at
ATM PVC and at DSL line level, then the most fine grained level will be used. In the
example the Customer ID configured for an ATM PVC will take precedence over the
customer ID configured at the DSL line.
It is possible to configure a system-level Customer ID. When doing so, the system
has the following behavior:
• If the customer ID at the interface level (VLAN port, UNI) is set to the default value
“available”, then the customer ID configured at system-level will be used for that
interface. This can be useful in case an operator wants to use the same Customer
ID on all UNIs, without having to configure it on each individual UNI.
• In case a specific user value is configured for a UNI or VLAN port, it takes
precedence over the system-level customer ID setting.
16.8.1.4 Physical line ID

By default, the Physical line ID is auto-generated by the ISAM and contains
information used to identify the precise circuit from which the DHCP message
originates (for example, DSL line, ATM PVC, Ethernet interface or VLANport).
The Physical line ID syntax is configurable. The Physical line ID syntax is a
concatenation of keywords, separators, and free text strings:
• for ATM-based DSL interfaces, the default value is “Access_Node_ID atm
Rack/Frame/Slot/Port:VPI.VCI”
• for EFM-based DSL and for Ethernet interfaces, the default value is
“Access_Node_ID eth Rack/Frame/Slot/Port”
• for Ethernet[/DSL] based user interfaces that are served via a GPON LT, the
default value is “Access_Node_ID eth Rack/Frame/Slot/Port/ONU/OnuSlt/UNI”
• for Ethernet[/DSL] based user interfaces that are served via a TWDM-PON LT,
the default value is "Access_Node_ID eth
Ng2/Channelgroup/Subchannelgroup/ONU/OnuSlt/UNI"

NT
One can use the following predefined keywords:

• Access_Node_ID: identifies the ISAM. The ISAM will insert the identifier that is
configured as “System ID”
• Rack: rack number in the access node
• Frame: shelf number in the rack. The variable is called “Frame” to be in line with
TR-101
• Slot: slot number in the shelf.
• Port: port number on the LT board. On DSL/Point-to-Point LTs the “Port” stands
for an end-user DSL/fiber interface, while on the GPON LT the “Port” stands for
an entire PON
• LzPrt: Same as “Port” but with a different syntax: it uses 3 ASCII characters that
correspond to the port number with leading zeros (for example: '001', '002', '015',
'064')
• ONU (for GPON and TWDM-PON): denotes the ONT/MDU identifier on the PON
• Ng2 (only for TWDM-PON): denotes a TWDM-PON network, this prefix is used in
order to differentiate from GPON interfaces.
• Channelgroup (only for TWDM-PON): denotes a set of channel pairs carried over
a common fiber. A channel pair consists of one downstream wavelength channel
and one upstream wavelength channel that together provide connectivity
between an OLT and one or more ONUs, in a TWDM-PON context.
• Subchannelgroup (only for TWDM-PON): a logical subset of a channelgroup,
containing one or more of the channel pairs that constitute the channelgroup.
• LzOnu (for GPON and TWDM-PON): denotes the ONT/MDU identifier on the
PON, with 3 digits and leading zeroes (for example, ONU 1 denoted as 001, ONU
10 denoted as 010 and ONU 100 denoted as 100).
• OnuSlt (for GPON and TWDM-PON): slot number on the ONT/MDU
• UNI (for GPON LT and TWDM-PON): UNI within the ONU-Slot
• VPI: VPI on user interface in case of ATM over DSL
• VCI: VCI on user interface in case of ATM over DSL
• Q-VID: VLAN ID on user interface (when applicable)
• NVID: refers to the C-VLAN ID at the network-side, which may be different from
the user-side “Q-VID”
• U-VID: VLAN ID on user interface in case of tagged frames and nothing inserted
as VLAN id in case of untagged frames. The special character / delimiter in front
of this keyword in case of untagged frames is not inserted.
• DUVID: same as U-VID, but in this case the special character / delimiter in front
of this keyword in case of untagged frames is inserted.

NT
• LzQVID: VLAN ID on user interface with 4 digits and leading zeroes (for example,
VLAN ID 1 denoted as 0001, VLAN ID 10 denoted as 0010, VLAN ID 100 denoted
as 0100 and VLAN ID 1000 denoted as 1000).
• I-VID: Refers to the second or inner VLAN-id in dual-tagged Ethernet frames.
Note — <ShSlt> and <ShPrt> keywords can also be used

instead of respectively <slot> and <port>. The keywords
<ShSlt> and <ShPrt> can be used to specify the slot and port
number without leading zero. This gives an alternative for the
<Slot> and <Port> keywords as defined above and provides full
flexibility as to the wanted/required syntax.
16.8.1.5 Bandwidth information

Broadband Forum TR-101 defines additional sub-options on top of those defined in
IETF RFC 3046. Among others it specifies a set of sub-options to pass DSL line
bandwidth characteristics.
The insertion of the line rate characteristics per VLAN in iBridge or VLAN
cross-connect mode can also be enabled or disabled.
The ISAM can be configured to either add only the actual line rate information in
DHCP option 82, or to add the full set of access line parameters defined in TR-101.
For example, this includes the minimum, maximum, attainable and actual line rates
and interleaving delays.
This functionality is supported on the DSL and Ethernet LT boards.
This functionality is not supported on GPON or TWDM-PON LT boards. However,
the option may be added by the MDU ONT. In this case, the OLT will transparently
forward the associated information.
16.8.2 (Layer 3) DHCP Relay Agent

This is further described in chapter “Protocol handling in a Layer 3 forwarding model”,
section “Layer 3 DHCP relay agent”.
16.8.3 DHCP snooping

If secure forwarding in Enhanced iBridge respectively in VLAN cross-connect is
configured, DHCP messages are snooped in order to learn the IP address
associated with the end user.
More information on DHCP snooping can be found in chapter “Protocol handling in
a Layer 3 forwarding model”.

NT
16.9 IGMP
For more information about IGMP, see chapter “Multicast and IGMP”.
16.10 PPPoE
Point-to-Point Protocol over Ethernet (PPPoE) is a network protocol for
encapsulating Point-to-Point Protocol (PPP) frames inside Ethernet frames. PPP is
the commonly used protocol in dialup connections. PPPoE allows to connect one or
multiple PPP Client computer subscribers through an Ethernet LAN to a PPP Server.
PPPoE is defined in IETF RFC 2516.
16.10.1 PPPoE relay

In many cases the Layer 2 (Ethernet) Access network extends Ethernet into the
home network. A CPE in the home network terminates the DSL link or Ethernet
interface that provides the connectivity with the Access Network. One possibility is
that the CPE is a router. Then this router CPE will be the single PPP Client
establishing PPPoE sessions. Another possibility is that a bridge CPE transparently
bridges the request coming from a device deeper in the home network. Something
in between can be that a CPE multiplexes PPPoE sessions coming from multiple
devices deeper in the home network.
All these cases have in common that PPPoE frames are sent from the user
equipment, through the ISAM, to a BRAS more centrally in the network. Broadband
Forum TR-101 specifies that in such case the DSLAM has to add some subscriber
information to the upstream discovery messages, that is, to the PADI, PADR and
upstream PADT packets.
So for PPPoE relay, the ISAM inserts a PPPoE Relay tag in all the upstream PPPoE
messages in the discovery phase (that is, frames with EtherType = 0x8863). This
information insertion is the only intervention of the ISAM on PPPoE frames in the
upstream direction. This means that all PPPoE messages forwarded to the BRAS will
still contain the MAC address of the subscriber as source MAC address (MAC SA)
and the broadcast MAC (PADI) or the MAC address of the PPPoE Server (PADR,
PADT) as destination MAC address (MAC DA).
The ISAM does not make an intervention in the downstream direction.
All PPPoE messages in the session phase are forwarded without any processing.
Note — PPPoE Relay is not supported on the P2P Ethernet LT

board NNI port type.

NT
Figure 252 PPPoE Relay Implementation
PPPoE traffic
LT IHub Ethernet ER
PPPoE traffic
CPE
LT NT
CPE
US/DS: PPPoE session

setup frames US: add PPPoE relay session ID, and forward
DS: forward
16.10.1.1 PPPoE relay tag

The “PPPoE Relay tag” is in fact a confusing name. It refers to the “PPPoE vendor
specific tag” that can be inserted by the ISAM in order to provide access loop
identification data towards the PPPoE Server (typically a BRAS).
The access loop identification conveyed by the PPPoE vendor specific tag is similar
as for DHCP option 82. Its format is defined in BBF TR-101. As for DHCP option 82,
the tag contains the identification of the access loop on which the PADI, PADR, or
PADT packet was received in the ISAM and possibly the line rate information about
this loop.
The insertion of the PPPoE vendor specific tag and the sub-options to be added are
configurable per VLAN.
The ISAM can be configured to either add only the actual DSL line rate information
in PPPoE discovery messages, or to add the full set of access line parameters
defined in TR-101, such as the minimum, maximum, attainable and actual line rates
and interleaving delays.
This functionality is supported for the DSL and p2P Ethernet LTs (UNI, HC-UNI).
The functionality of adding access line parameters is not supported on GPON or
TWDM-PON,

NT
16.10.2 PPPoA to PPPoE interworking

In some cases the Layer 2 (Ethernet) Access network does not extend Ethernet into
the home network. In some situations the home network is connected to the Access
Network with a traditional PPP over ATM over DSL interface. Because the remainder
of the Access Network is using Ethernet at the physical layer, it becomes the
responsibility of the ISAM to provide an interworking function between both
technologies. This interworking function is also specified in BBF TR-101.
Figure 253 Network Topology
PPPoA - PPPoE Interworking
ATM
termination
IP Edge
USB Local Loop ISP
USB Modem EMAN

Ethernet
IP Srv: Video
Bridge
I
IP
Routing
NE Srv: VoIP
Gateway
L2TP
PPP-L2TP
interworking
In case of PPPoA to PPPoE interworking, the PPP forwarder is a further

enhancement of the iBridge. The PPP forwarder is still essentially a Layer 2
forwarding model, but it also uses information from the PPP layer in its forwarding
decisions.
PPPoA packets on the DSL line are translated into PPPoE on the uplink as follows:
1 When a subscriber initiates a PPPoA session, the ISAM first initiates a PPPoE
session towards the BRAS. The involved PAD-x messages are sent with a VLAN
tag with priority 7.
2 Once the PPPoE session is established, the initial PPP (LCP) request from the
subscriber is forwarded within that PPPoE session.
3 The remainder of the PPP negotiation happens between the subscriber terminal
and the BRAS.
The initial PPP request packet and all further packets sent within the established
PPPoE session are sent with a VLAN tag with the priority configured for the PPP
client port.

NT
During the session, every upstream PPP packet is encapsulated in PPPoE, where
the MAC address of the ISAM is used as MAC source address. Downstream, the
reverse operation takes place and the MAC layer is stripped. From a BRAS
perspective, the session looks like any normal standard PPPoE session.
To give the Access Service Provider (ASP) the maximum information that can help
him to accept a PPPoE session establishment or to silently ignore the request, the
ISAM provides the PPPoE Server with access loop identification and line rate
information just as for PPPoE Relay.
Beside all these similarities there is still something special:
The ISAM can inform the PPPoE Server that the PPPoE session being established
is an “interworked session, that is, a session established on behalf of a user. This
could be useful for the BRAS, for example, to use a different approach for limiting the
number of sessions per client. This information is provided through the insertion of
the BBF-IWF-tag sub-option in the PPPoE vendor specific tag. This sub-option is
defined in BBF TR-101.
Adding this sub-option can be enabled or disabled per PPP cross-connect Engine.
A second special thing relates to the Maxim Transmit Unit (MTU). In this scenario the
PPP Client is a PPPoA user and it assumes it can send PPP packets of 1500 bytes.
To encapsulate these frames in Ethernet, the interworking function shall add 8 bytes
of PPPoE header and as such the frame does no longer fit in a standard Ethernet
frame with a maximum payload of 1500 bytes. The normal procedure then requires
the PPP Client and the PPP Server to negotiate about the MTU. To facilitate the
convergence of this negotiation, the ISAM supports Ethernet frames that are 8 bytes
longer than standard Ethernet. This facility is signaled in the PADI message to the
PPPoE Server by adding the PPP-Maximum-Payload tag. This tag is defined in IETF
RFC 4638.
Adding this tag can be enabled or disabled per PPP cross-connect Engine.
The ISAM actively participates in the PPP connection release phase. When the PPP
session is terminated, the ISAM also terminates the corresponding PPPoE session.
The involved PAD-T message is sent with a VLAN tag with priority 7.
Normally, when a DSL line has gone out of service, the PPPoE session will only
time-out in the BRAS after a certain time (typically 3 minutes). This delay is
considered too long, for example, by service providers that offer a PPP-based HSI
service with time-based billing.
Therefore, the ISAM removes state for an interworked PPPoE session and sends a
PPPoE PAD-T message to the BRAS upon a loss-of-connectivity to the subscriber
(this can be indicated by loss of DSL synchronization on the associated subscriber
line).
Note — PPPoA to PPPoE interworking is not supported on the
GPON and TWDM-PON LT, nor on the Ethernet LTs. It is also
not supported on a stacked iBridge on DSL LTs.

NT
16.10.3 PPPoE relay with MAC address concentration

In theory, if a CPE terminates the PPPoE protocol, there should be no issue to
establish an end-to-end connectivity between the CPE and a BRAS located into the
Ethernet network through bridging in the EMAN and with the ISAM performing
Residential Bridging (or Vlan Cross-connect). In that scheme downstream frames
are forwarded using the own CPE MAC address.
Some legacy Ethernet Bridges cannot cope however with the large number of MAC
addresses required to forward PPPoE frames to the large number of subscribers
connected to the EMAN through the ISAMs (at least 1 MAC address per subscriber).
This scalability issue is solved by the PPPoE relay with MAC address concentration
feature: the ISAM replaces the large number of MAC addresses, issued by the
subscribers, with the ISAM MAC address(es). The EMAN now only needs to cope
with a few MAC addresses per connected ISAM instead of tens of thousands of MAC
addresses for all connected subscribers. For the BRAS, it looks as though there is a
single PPP Client with a huge number of PPP connections.
Next to solving the scalability issue, the PPPoE relay with MAC address
concentration also increases the security within the network. The MAC address of
the subscriber does not enter the EMAN anymore. This address is replaced by the
own MAC address(es) of the ISAM and, consequently, all issues related to duplicate
subscriber MAC addresses are solved. The subscriber MAC address has only a local
meaning (that is, local to the PVC, or DSL line) and, consequently, even if all the
subscribers would present the same MAC address to the ISAM, they could still be
connected to the BRAS without any problem.
Spoofing the MAC address of another subscriber will not allow to grab its traffic
because the subscriber MAC address is not used by the EMAN nor by the ISAM to
route the traffic.
MAC address concentration can be enabled or disabled per PPP cross-connect
Engine at creation time.
If enabled the ISAM behaves very much like in the PPPoA to PPPoE interworking
scenario with the difference that the interworking applies to multiple PPPoE sessions
coming from users instead of to PPPoA sessions.
Note 1 — PPPoE relay with MAC address concentration is not
supported on the GE Ethernet LT board HC-UNI and NNI and
on the 10GE Ethernet LTs.
Note 2 — PPPoE relay with MAC address concentration on a
stacked iBridge is not supported on DSL LTs.
16.11 DHCPv6
This section provides information about the lightweight DHCPv6 relay agent,
bandwidth, DHCPv6 trusted/untrusted port configuration, DHCPv6 relay agent, and
DHCPv6 snooping.

NT
16.11.1 Lightweight DHCPv6 Relay Agent

The ISAM can be configured to act as a Lightweight DHCPv6 Relay Agent (LDRA).
In this configuration, the Edge Router deeper in the network will act as a DHCPv6
Relay Agent.
The DHCPv6 packet headers will be created in accordance with
draft-ietf-dhc-dhcpv6-ldra. The DHCPv6 packet received from the user is copied in
the Relay-Message option of the relayed DHCPv6 packet.
The Access Node is able to encode the access loop identification in the Interface-ID
Option (option 18, defined in RFC 3315) to the DHCPv6 Relay-forward messages
sent to the BNG.
The encoding must uniquely identify the Access Node and the access loop logical
port on the Access Node on which the DHCPv6 message was received. The
Interface-ID contains a locally administered ASCII string generated by the Access
Node, representing the corresponding access loop logical port.
The actual syntax of the access loop identification in the Interface-ID can take the
same values as the ones supported for the DHCP option 82 sub-option 1:
• No Circuit ID (empty)
• Syntax defined in TR-101 section 3.9.3, that is, physical line ID using a default or
a configured syntax at system level
• Customer-ID
• Physical line ID in CCSA format
This allows the operator to migrate to IPv6 in a VLAN cross-connect model, without
losing access line information.
The Access Node is also able to add the Relay Agent Remote-ID Option (option 37,
defined in RFC 4649) to the DHCPv6 Relay-forward messages sent to the BNG. This
is used in order to further refine the access loop logical port identification.
The Relay Agent Remote-ID contains an operator-configured string of 63 characters
maximum that (at least) uniquely identifies the user on the associated access loop
on the Access Node on which the DHCPv6 Solicit message was received.
The actual syntax of the user identification in the Relay Agent Remote-ID can take
the same values as the ones supported for the DHCP option 82 sub-option 2:
• No Remote ID (empty)
• Customer-ID
• Physical line ID (using a default or a configured syntax at system level)
In the ISAM implementation the LDRA is enabled when either option 18 insertion or
option 37 insertion is enabled, and LDRA is disabled when both option 18 insertion
and option 37 insertion are disabled. The operator can enable/disable the insertion
of option 37 into upstream DHCPv6 messages for each lightweight DHCPv6 Relay
Agent instance.

NT
Ethernet line cards support the lightweight DHCPv6 relay agent on following
interfaces:
• GE Ethernet LT: UNI and HC-UNI.
• 10GE Ethernet LT: UNI and NNI, but the latter in the context of auto-provisioning
a trusted node subtended from the card. Option 53 for Relay-ID is added to the
DHCPv6 client packets received on the NNI. Relay-ID takes the format of
DUID-LL.
16.11.2 Bandwidth information

The Lightweight DHCPv6 Relay Agent supports the insertion of the “Vendor-specific
Information” Option (option 17) as defined in RFC 3315 in order to add information
about access loop characteristics. This is similar to the DHCP behavior specified for
IPv4 (see section “Bandwidth information”). The ISAM can be configured to add the
full set of access line parameters in DHCPv6 option 17, as defined in TR-101. This
includes among others the minimum, maximum, attainable and actual line rates and
interleaving delays.
This functionality is supported for the DSL LT boards (except the 72-port ADSL2plus
LT board) and Ethernet LT boards (except the NNI port type). The functionality is not
supported on the GPON and TWDM-PON LT boards.
16.11.3 DHCPv6 trusted/untrusted port configuration

The interface (VLAN) where the LDRA is enabled, can be configured as trusted or
untrusted interface.
When the interface is configured as trusted, then the LDRA accepts DHCPv6
Relay-Forward messages from user side with options 18 and/or 37 already inserted.
The ISAM will relay these Relay-Forward messages in accordance with
draft-ietf-dhc-dhcpv6-ldra. In that case hop count is incremented in the upstream and
is decremented in the downstream.
When the interface is configured as untrusted, then Relay-Forward messages from
the user side will be discarded and not relayed.
16.11.4 DHCPv6 Relay Agent

See chapter “Protocol handling in a Layer 3 forwarding model”, section “DHCPv6
Relay Agent”.

NT
16.11.5 DHCPv6 snooping

See chapter “Protocol handling in a Layer 3 forwarding model”.
Note — DHCPv6 snooping is not supported by the GE Ethernet

LT board NNI port types.
16.12 ICMPv6
ICMPv6 includes Neighbor Discovery (ND) messages as well as Multicast Listener
Discovery (MLD) messages. In general, upstream and downstream ICMPv6
messages are handled transparently without specific processing. This means that
downstream multicast ICMPv6 messages are typically flooded by default.
The filtering of ICMPv6 unicast and multicast ICMPv6 packets in an iBridge or VLAN
cross-connect forwarder can be enabled or disabled. This allows fine tuning of the
ICMPv6 message handling for security purposes.
When enabled, the following ND and MLD messages must be discarded:
• Downstream Router Solicitation (RS)
• Upstream Router Advertisement
• Upstream Redirect
• Upstream MLD Multicast Listener Queries
• ND messages which are not originated from the local network, that is those with
a hop limit less than 255
When using MAC address translation or virtual MAC addresses, the MAC address
field present in the ICMPv6 Neighbor Discovery message payload must be
translated. See section “Virtual MAC” for more information on virtual MAC
addresses.
16.13 LLDP
ISAM supports advertising using Link Layer Discovery Protocol (LLDP) (IEEE
802.1AB 2009) on its uplink ports, this allows upstream node to discover ISAM as
part of network topology.
LLDP Implementation on ISAM can be configured on a per uplink port basis to
advertise to following destinations:
• 'nearest bridge' MAC Address (01-80-C2-00-00-0E)
• 'nearest non-Two Port MAC Relay bridge' MAC Address (01-80-C2-00-00-03)
• 'nearest customer bridge' MAC Address (01-80-C2-00-00-00)

NT
Following TLVs are supported:

• Chassis ID
• Port ID
• Time To Live
• Port Description
• System Name
• System Description
• Management Address
Each uplink port on ISAM can be configured to advertise different TLVs to different
destination MAC address. A maximum of 3 LLDP sessions i.e. one per destination
MAC address can be configured.
ISAM shall process any untagged LLDP PDUs received on network/access ports if
corresponding LLDP destination MAC bridge is enabled on that port. Any tagged
LLDP PDUs are forwarded in the context of the service associated.
LLDP packets are not blocked due to xSTP or LACP port states.

System Description for FD 100/320Gbps NT and FX IP routing
NT
17 IP routing
17.1 Introduction
17.2 IP routing features
17.3 IP routing model
17.4 Routing in case of subtended ISAMs
17.1 Introduction
The IP routing model of the ISAM is a typical router implementation with increased
security and scalability, allowing to use cheaper devices (that is, simple Ethernet
switches) in the aggregation network. It can be characterized as follows:
• Packets are forwarded based on the IP Destination Address (DA) with the ISAM
acting as a next hop.
• IP connectivity towards the end user can be established statically by the operator
or learned dynamically by inspecting the DHCP messages exchanged between
the subscriber and the DHCP server during the IP session establishment.
• IP connectivity towards the network and the subtending nodes can be established
statically by the operator or dynamically by routing protocols.
• Service Level Agreement (SLA) enforcement can be achieved by means of
policing and Access Control List (ACL), and this at various granularity levels.
• Improved security:
• Subscriber MAC addresses are never propagated to the network
• ARP messages do not cross the ISAM leading to not broadcasting ARP messages
to all subscribers
• IP address anti-spoofing and ACL
• Improved scalability
• The ISAM presents a single MAC address towards the network
• The broadcast message load generated by the subscribers towards the network is
reduced by either handling them locally (for example, ARP) or by converting them
into unicast messages (for example, L3 DHCP relay).
17.2 IP routing features

In the next sections, unless stated differently, the description applies to both IPv4 and
IPv6.

IP routing System Description for FD 100/320Gbps NT and FX
NT
17.2.1 Packet forwarding based on the IP addresses

Implementing a forwarding based on IP addresses allows to:
• terminate the Ethernet segment at the subscriber side and consequently, avoid
the need to propagate the MAC address of the subscriber to the network solving
at the same time many security and scalability issues.
• forward packets based on addresses assigned by the operator, enforcing a high
security level.
• introduce IP awareness in the DSLAM, which facilitates support of enhanced
features such as IP address anti-spoofing, ACLs and so on.
17.2.2 Next hop behavior

The ISAM is seen as a next hop by the network and the subscribers, which allows
increased scalability. Indeed, the IP edge router does not have to know each
subscriber individually (which results in a reduced ARP table size or reduced IPv6
Neighbor Cache size) and ARP messages issued by the subscribers are terminated
by the ISAM, reducing the control plane load at the IP edge.
17.2.3 Subscriber interface - Encapsulation types

• The IP routing model supports all types of subscriber interface IPoX
encapsulations, which can be connected to an iBridge on the LT:
• ATM subscriber interface (IPoE over ATM and IP over ATM)
• EFM/Ethernet subscriber interface (IPoE)
• IPoE subscriber interface:
• User interface can be authenticated through 802.1/RADIUS protocols before
connecting to a router in ISAM.
• vMAC can be enabled when subscribers do not have unique MAC address
• PPPoE and PPPoA subscriber interface encapsulations are not supported by IP
routing.
17.2.4 802.1X/RADIUS authentication

Subscriber interfaces (IPoE over ATM or EFM/Ethernet) can be authenticated
through 802.1/RADIUS protocols before connecting to a router in ISAM.

NT
17.2.5 Subscriber interface - Unnumbered

In order to make the subscriber addressing scalable, subscriber interfaces (on the
DSL lines or ONT UNIs) are considered as unnumbered IP interfaces attached to the
IP router. That is, there is no need to allocate an IP address (note that this is only
from the logical point of view and no need to explicitly configure unnumbered IP
interface on the subscriber lines). This allows to share a subnet across many
subscribers and, consequently, to increase the scalability and ease of operations.
17.2.6 DHCPv4 relay agent

DHCP messages from the subscribers are forwarded through a layer 3 DHCP relay
instance. This allows to:
• Convert broadcast messages into unicast messages towards a set of predefined
DHCP servers to reduce the broadcast traffic load in the network.
• Add option 82 to uniquely identify the requesting subscriber by inserting the
identification of his DSL line or ONT UNI into the DHCP messages.
17.2.7 DHCPv6 relay agent

When performing IPv6 forwarding/routing, the ISAM supports a DHCPv6 Relay
Agent according to RFC 3315. This allows to:
• Convert IPv6 multicast messages into unicast messages towards a set of
predefined DHCPv6 servers to reduce the IPv6 multicast traffic load in the
network.
• Add option 18 and/or option 37 to uniquely identify the requesting subscriber by
inserting the identification of his DSL line or ONT UNI into the DHCPv6 messages.
More details on the DHCPv6 processing can be found in chapter “Protocol handling
in a Layer 2 forwarding model” and chapter “Protocol handling in a Layer 3
forwarding model”.
17.2.8 Subscriber routes - Dynamically learned through

DHCP snooping
For a router in general, interfaces are usually configured statically (by the operator),
and the routes are learned dynamically via routing protocols. This is not typical for
the subscriber side in ISAM because the devices of the subscriber do not typically
support routing protocols and secondly the amount of subscribers to be configured
in a DSLAM is high. The better method for ISAM is to learn the IP addresses by
snooping DHCP messages.

NT
The ISAM can automatically manage the forwarding parameters associated with the
interfaces of the subscribers by snooping the DHCP messages exchanged with
these subscribers (populate the snooped IP address of the subscriber, remove that
IP address once the snooped IP address lease time is elapsed). This basically
reduces the operator's cost of operation since the connectivity establishment is
performed dynamically at IP session set-up time without any involvement of the
operator.
However, an operator may still configure subscribers statically if desired (for
example, business users). Static configuration is required whenever a subnet needs
to be assigned to a subscriber, while ISAM only supports dynamic subscriber's IP
address allocation for an individual IP address.
In the case of IPv6, DHCPv6 snooping is performed to learn the subscriber routes:
• When DHCPv6 is used for Prefix Delegation, the IPv6 forwarding table is
populated with the delegated prefix, indicating this is a non directly attached
subnet. These are so-called “DHCPv6 managed routes”. The ISAM maintains the
relation between the delegated IPv6 prefixes, its lease time and the
corresponding subscriber-facing interfaces.
• In case of stateful DHCPv6 address assignment, managed (DHCPv6) entries are
created in the Neighbor Cache for the /128 IPv6 addresses that are assigned to
the IPv6 hosts. The ISAM maintains the relation between the IPv6 address, its
lease time and the corresponding MAC address.
• When Prefix Delegation is used, it is also possible to preserve the prefix when a
subscriber moves from one location to another. For this to be possible, the DHCP
server must detect that the subscriber has moved and assign the same prefix at
the new location. This feature is known as Prefix Stability. This new location can
be connected to the same 7360 ISAM FX node or to a different 7360 ISAM FX
node. If the new location connects to the same 7360 ISAM FX node, the ONU
status on the line is used to confirm the subscriber movement.
When the subscriber has moved to a new OLT, the prefix will be populated as a
route in the IPv6 forwarding table of that OLT. For a short time this route will exist
in parallel at both the old and the new OLTs. However, the new OLT will advertise
this route and when the route is distributed to the old OLT, it will remove and
replace the old route with the new route (or) keep the old route - based upon the
ONU status on the line and based upon the hold-timer started after the route is
seen from the other OLT (for handling flaps). If at both OLTs, the ONUs status
indicates no subscriber movement, an alarm is reported to indicate this condition.

NT
17.2.9 Network routes - Dynamically learned through

routing protocol
Network routes can be learned dynamically through routing protocols, hence
reducing the cost of operation. Connectivity to the network is automatically
established by means of IP routing protocols. Additionally, routing protocols can also
be used to increase the network reliability by advertising alternative routes whenever
a failure occurs in the network (for example, dual homing from the ISAM to two
different routers).
The operator can also configure static routes to the network if desired.
Routing protocols can support retention of routes advertised from neighbor routers
undergoing graceful restart triggered by the operator. This enables quicker recovery
of route paths after maintenance actions on network node(s).
17.2.10 Routes advertised to network and subscribers

IPv4 network routes can be advertised to the subscribers using RIP. IPv6 network
routes cannot be advertised to the subscribers.
IPv4 subscriber routes (individual or aggregated routes) can be advertised to the
network using RIP, and other routing protocols. This reduces the provisioning work
at the network and/or CPE side.
IPv6 subscriber routes (individual or aggregated routes) can be advertised to the
network using OSPFv3, BGP-4 and IS-ISv6.
The ISAM supports maintaining multiple distinct IP topologies. This can be used for
instance for maintaining a different IPv4 and IPv6 routing topology in the same
domain. Multi Topology IS-IS is supported. Note that IS-ISv6 and Multi Topology
IS-IS are not supported in VPRNs, but only in the IES service.
17.2.11 User-to-user communication

User-to-user communication is always enabled via the IP router. ISAM provides local
ARP proxy or local Neighbor Discovery proxy for all directly connected subscriber
subnets (which need to be explicitly enabled when user-to-user communication is
required).
Note that user-to-user communication can still be prevented by means of ACLs.

NT
17.2.12 IPv4 option processing

ISAM supports the processing of following IPv4 options:
• Router alert
• Time stamp
• Record route
ISAM does not process source route option, that is, IP packets including source route
options are forwarded transparently.
17.2.13 MTU
The L2 MTU size is fixed to 2048 and not configurable.
The L3 MTU size can be configured per interface. The default value is 2030, but if
required a lower value can be configured.
Implementation notes:
• The ISAM does not perform IP packet fragmentation for forwarded packets
(packets generated by the ISAM itself are subject to fragmentation)
• Packets received with a length larger than the MTU are discarded.
17.2.14 ECMP
Up to eight Equal Cost Multi Path (ECMP) next-hops are supported per route.
17.2.15 Directed broadcast

ISAM does not support forwarding of the broadcast IP packets directed to the directly
connected subscriber subnets (where subnet is all zeros or all ones). Directed
broadcast IP packets are discarded by ISAM.
17.2.16 ICMP Redirect

ISAM does not support ICMP Redirect.
17.2.17 ICMPv6 redirect

ISAM supports generation of ICMPv6 redirect messages. Generation of ICMPv6
redirect messages can be controlled at IPv6 interface level.

NT
17.3 IP routing model

The IP routing model of the ISAM consists of iBridge forwarders (with secure
forwarding enabled) on the LT boards connected to a standard IP router on the NT
board.
17.3.1 Public IP routing instance

Base router is the default IP router instance that is connected to the public IP network
domain and manages the topology of the public domain.
The base router is connected to the public IP network via the network facing ports of
ISAM. Network facing ports can be configured in two exclusive modes: network or
access.
• On a port of mode network, an IP interface can be directly created.
• On ports of mode access, an IP interface cannot be directly created. It needs to
be done in two steps:
• Associate the access port(s) for a particular encapsulation value with a v-VPLS
• Create an IP interface on top of this v-VPLS by using the Internet Enhanced Service
(IES) and a virtual port.
Subscribers can also access the services offered via the public IP network domain.
In this case, Internet Enhance Service (IES) needs to be explicitly created and needs
to be enabled on the subscriber access interfaces. The IES service provides a way
to attach subscribers to the base router since the base router cannot have IP
interfaces directly on the subscriber interfaces. These concepts are illustrated in
Figure 254 and Figure 255.
Even if it is not required to provide public network access to subscribers, still IES
service needs to be explicitly configured to attach the base router to the public
domain.

NT
Figure 254 IPv4 routing - Base router with IES service
User IP address part iBridge VLAN with

secure forwarding
ISAM / OLT
of the user gateway
interface subnet enabled
IPoE user interface 802.1x authentication NT
(tagged or untagged) can be enabled
GPON LT Base Router

User gateway IP interface
Interface Local ARP DHCP Routing facing network
Proxy Relay Agent Protocols
iBridge
VLAN
RG ONT SAP
IES Service
……
IPoA user interface LT ports

EMAN IP
v-VPLS
v-VPLS
(DSL/PVC) (facing users) network
IP edge
IPoA - IPoE vMAC can Virtual port
IPoE user interface interworking be enabled
(DSL/PVC/VLAN
or DSL/VLAN)
LT User gateway Network
v-VPLS v-VPLS L2 switch
CPE IPoA/IPoE
iBridge
User gateway VLAN

VLAN
Physical port
CPE (VLAN attached to user facing network
gateway interface)
CPE
iBridge VLAN with secure
forwarding enabled
User IP address part of the IPoE user interface
802.1x authentication
user gateway interface (DSL/PVC or DSL),
can be enabled
subnet untagged
Figure 255 IPv6 routing - Base router with IES service
Not applicable
ISAM
for IPv6
Bridged, routed or
NT
routed unnumbered
LT Base Router
CPE IPoA/IPoE
iBridge
VLAN
CPE SAP
CPE IES Service
……

EMAN
v-VPLS
IP
v-VPLS
(DSL/PVC) (facing users)

IPoA - IPoE IP edge network
Virtual port
interworking vMAC can
IPoE user interface
not applicable be enabled
(DSL/PVC/VLAN
or DSL/VLAN)
CPE IPoA/IPoE
iBridge
User gateway VLAN

VLAN
Physical port
gateway interface)
CPE
forwarding enabled
can be enabled
subnet untagged

NT
IP routing with IES service is achieved by enabling “Base router”, “IES service” and
“iBridge” components in ISAM.
• Base router:
• IP interfaces facing the network (on ports of mode network) need to be configured
• Routing protocols can be enabled on the IP interfaces which are defined directly on
the ports of mode network or which have been created as part of the IES service in
order to dynamically learn network routers and/or advertise the subscriber routes to
the network (refer to chapter “Protocol handling in a Layer 3 forwarding model”).
• Supported IPv4 routing protocols: BGP, IS-IS, OSPF, RIP, PIM-SSM
• Supported IPv6 routing protocols: BGP, OSPFv3, IS-ISv6
• IES service:
• IP interfaces facing the network (on ports of mode access) need to be configured in
the IES service.
• In the context of the IES service: a User gateway IP interface (containing the subnet
of the subscriber) needs to be configured on top of the user gateway v-VPLS, on
behalf of the iBridge VLAN).
• The subnet of the subscriber gateway IP interface is shared among the subscribers
connected to the iBridge VLAN on the LT boards. The IP address of the subscriber
gateway interface is used as the gateway IP address for the subscribers directly
attached to the subnet of the subscriber gateway interface.
Multi-netting is also supported for the subscriber gateway interface to allow multiple
subscriber subnets.
• DHCP relay agent can be enabled on the user gateway IP interface in order to allow
subscribers to retrieve their IP addresses dynamically from DHCP servers (refer to
chapter “Protocol handling in a Layer 3 forwarding model”).
• Local ARP proxy or local Neighbor Discovery proxy needs to be enabled on the user
gateway interface in order to enable user-to-user communication (refer to
• ARP anti-spoofing security feature can be enabled on IP interface to detect ARP
spoofing and to prevent ARP cache poisoning.
• iBridge:
• iBridge VLAN needs to be enabled on those subscriber interfaces which need to get
access to the IES services.
• Secure forwarding needs to be configured for the iBridge VLAN: Secure forwarding
enables IP anti-spoofing (in upstream, that is, packets received from users) and
dynamic learning of the IP addresses assigned to subscribers via DHCP snooping
(refer to chapter “Layer 2 forwarding” and chapter “Protocol handling in a Layer 2
forwarding model”).
• Adding DHCP Option-82 can be enabled for the iBridge VLAN (refer to
• Adding DHCPv6 Option 18 and/or option 37 can be enabled for the iBridge VLAN
(refer to chapter “Protocol handling in a Layer 2 forwarding model”).
• 802.1X/RADIUS authentication can be enabled for IPoE subscriber interfaces (refer
to chapter “Protocol handling in a Layer 2 forwarding model”).
• vMAC shall be enabled when IPoE subscribers do not have unique MAC address
• IPoA/IPoE interworking needs to be configured on those IPoA subscriber interfaces
which need to get access to the IES services. Note that IPoA is supported for IPv4
only.

NT
IES service with uplink ports in "network mode"

It is possible to configure an IES service for IPv4 and/or IPv6 routed traffic and
configure the ISAM uplink port in "network mode". This can, for example, be useful
in order to support MPLS services, IPv4 unicast and multicast routed services and
IPv6 unicast routed services, all on the same port.
This model supports the following features:
• IPv4 unicast routing using static routes, RIP, OSPF, ISIS and BGP.
• IPv4 multicast routing using PIM-SIM.
• IPv6 unicast routing using static routes, ISISv6, OSPFv3 and BGPv6.
Using this approach, one does not need to create a separate VLAN or Layer 2 SAP
on the uplink port. In other words, an IPv4/IPv6 routed IES service is configured but
instead of having to create a separate v-VPLS, IPv4/IPv6 routing is natively
supported on the uplink interface. The IES service implicitly uses the base router
IPv4/IPv6 interface as uplink interface.
Note 1 — It is possible to statically route IPv4 unicast traffic
received via a MPLS tunnel towards other VLAN tagged ports.
This routing is only uni-directional, that is from MPLS tunnel
towards non-MPLS VLAN Ethernet ports, not vice-versa.
Note 2 — It is not possible to support any other form of IP
routing on top of an MPLS service. In other words, the IP
unicast and multicast routed traffic must use VLAN-based
transport.
Note 3 — It is not possible to support IP routing in a VPRN
service on top of a port in "network mode". This service
configuration relies on ports in "access mode".
17.3.2 Private IP routing instance

The Virtual Private Routed Network (VPRN) service allows creating a private IP
routing instance de-coupled/isolated from the public IP network domain. Each VRPN
service gets it's own private routing/forwarding instance. ISAM supports multiple
VPRN services.
The VPRNs are isolated from one another, likewise the VPRNs are isolated from the
Base Router with its IES services.
VPRN IP interfaces can only be created on user-facing ports or on network-facing
ports of mode access.
VPRN IP interface can also be created on top of a GREv4 tunnel which in turn is
created on top of another IP interface associated with an IES router instance or
another VPRN router instance.

NT
Figure 256 IPv4 routing - VPRN service

User IP address part ISAM / OLT Multiple VPRN
of the user gateway instances
interface subnet
IPoE user interface 802.1x authentication NT
(tagged or untagged) can be enabled
GPON LT VPRN Service

iBridge
VLAN
RG ONT SAP
……

EMAN IP
v-VPLS
v-VPLS
(DSL/PVC) (facing users) network
IP edge
IPoA - IPoE vMAC can Virtual port
IPoE user interface interworking be enabled
(DSL/PVC/VLAN
or DSL/VLAN)
CPE IPoA/IPoE
iBridge
User gateway VLAN

VLAN
Physical port
gateway interface)
CPE
forwarding enabled
can be enabled
subnet untagged
Figure 257 IPv6 routing - VPRN service
Not applicable
ISAM Multiple VPRN
instances
for IPv6
NT
Bridged, routed or
routed unnumbered
LT VPRN Service
CPE IPoA/IPoE
iBridge
VLAN
CPE SAP
CPE
……

EMAN
v-VPLS
IP
v-VPLS
(DSL/PVC) (facing users)

IPoA - IPoE IP edge network
Virtual port
interworking vMAC can
IPoE user interface
not applicable be enabled
(DSL/PVC/VLAN
or DSL/VLAN)
CPE IPoA/IPoE
iBridge
User gateway VLAN

VLAN
Physical port
gateway interface)
CPE
forwarding enabled
can be enabled
subnet untagged

NT
A private IP routing instance is achieved by enabling “VPRN service” and “iBridge”

components in ISAM.
• VPRN service:
• A VPRN service needs to be created.
• IP interfaces facing the network need to be configured, network facing ports should
be defined as mode access.
• In the context of the VPRN service: a user gateway IP interface (containing the
subnet of the subscriber) needs to be configured on top of the user gateway v-VPLS,
on behalf of the iBridge VLAN.
• The subnet of the subscriber gateway IP interface is shared among the subscribers
connected to the iBridge VLAN on the LT boards. The IP address of the subscriber
gateway interface is used as the gateway IP address for the subscribers directly
attached to the subnet of the subscriber gateway interface.
Multi-netting is also supported for the subscriber gateway interface to allow multiple
subscriber subnets.
• DHCPv4 or DHCPv6 relay agent can be enabled on the user gateway IP interface in
order to allow subscribers to retrieve their IP addresses dynamically from DHCP
servers (refer to chapter “Protocol handling in a Layer 3 forwarding model”).
• Local ARP proxy or local Neighbor Discovery proxy needs to be enabled on the user
gateway interface in order to enable user-to-user communication (refer to
• ARP anti-spoofing security feature can be enabled on IP interface to detect ARP
spoofing and to prevent ARP cache poisoning.
• Routing protocols can be enabled in order to dynamically learn network routers
and/or advertise the subscriber routes to the network (refer to chapter “Protocol
handling in a Layer 3 forwarding model”).
• Supported IPv4 routing protocols: BGP, OSPF, RIP
• Supported IPv6 routing protocols: BGP
• iBridge:
• The same as in section “Public IP routing instance”.
17.4 Routing in case of subtended ISAMs

When grooming traffic from multiple subtended ISAMs into a Hub ISAM, the ISAM
supports two approaches:
• Subtended nodes operating as Layer 2 devices (Preferred)
• Subtended nodes operating as L3 devices

NT
17.4.1 Subtended nodes operating as Layer 2 devices

(Preferred)
In this node, IP routing and L3 DHCP relay are kept centralized on the Hub ISAM
(H-ISAM) so that remote nodes - subtended ISAM or S-ISAM - can be kept as simple
as possible (both from a hardware implementation and from a provisioning point of
view). This allows centralizing routing protocols and subnet management at the
H-ISAM while keeping the S-ISAMs untouched, that is, any addition of a new pool of
IP addresses will only impact the H-ISAM.
The potential drawbacks of this configuration are related to H-ISAM scalability:
• larger Forwarding Database and ARP tables
• higher processing load.
This configuration is shown in Figure 258. In the H-ISAM, the router function is
configured while in the S-ISAMs layer 2 forwarding is in place.
Figure 258 ISAM sub-network configuration for video traffic (e.g VDSL)
Seen by the operator as

one big virtual router
ONT
RG
R
Aggregation
Network
DHCP
Relay
L2
One single IP subnet

over all Hub + Sub ISAMs
Hub ISAM
LT NT
EiB R
LT NT
Identical LT configuration
EiB B in Hub and Sub ISAMs
Sub ISAM
EiB: Enhanced iBridge
EiB: Enhanced -Bridge

NT
17.4.2 Subtended nodes operating as L3 devices

All nodes operate as IP routers, allowing the operator to define a similar configuration
for all nodes. The approach leads to inefficient IP subnet usage.
The S-ISAM does forward upstream traffic to the H-ISAM as per the default route
announced from the H-ISAM.
Figure 259 provides a network view. The assumption is that RIP is used to distribute
routes towards the subscribers. The red dots indicate where an IP interface is
configured.
Figure 259 Subtended ISAM operating as a L3 device
IGP
L3
IGP
Aggregation
L3 Network
IGP
L3

NT
18 Protocol handling in a Layer 3

forwarding model
18.1 Introduction
18.2 IPv4 Routing Protocols
18.3 ARP
18.4 DHCP relay agent
18.5 DHCP snooping
18.6 DHCPv4 server
18.7 TWAMP Light
18.8 IPv6 routing protocols
18.9 Neighbour Discovery (ICMPv6)
18.10 DHCPv6 Relay Agent
18.11 DHCPv6 Snooping
18.12 Bidirectional Forwarding Detection
18.1 Introduction
This section addresses layer 3 protocols in the scope of a layer 3 forwarded model
as described in chapter “IP routing”.
Layer 3 protocols can be divided into two parts:
• routing protocols: see section “IPv4 Routing Protocols” and “IPv6 routing
protocols”
• user access protocols:
• ARP: see section “ARP”
• DHCP Relay: see section “DHCP relay agent”
• DHCP: see section “DHCP snooping”
• Neighbour Discovery (ICMPv6): refer to section “Neighbour Discovery (ICMPv6)”
• DHCPv6 Relay: refer to section “DHCPv6 Relay Agent”
• DHCPv6 Snooping: refer to section “DHCPv6 Snooping”

NT
18.2 IPv4 Routing Protocols

The following IPv4 routing protocols are supported:
• on network interfaces: RIP, OSPF, IS-IS, and BGP (both i-BGP and e-BGP).
• on interfaces towards a subtended ISAM, directly connected to the NT card (that
is, not supported on the GE Ethernet card NNI port type): RIP and OSPF
• on subscriber interfaces: RIP to advertise the routes towards the routers at the
network side of the ISAM. The ISAM does not accept any route advertisement
from the subscribers for security reasons.
Note — These routing protocols are extensively described in

the FD 100Gbps and 320Gbps NT Router Configuration and
Protocol Guide.
The ISAM will report alarms to inform the Manager about lack of resources, major
issues and state transitions in the protocol.
18.3 ARP
The IETF RFC 826 defined Address Resolution Protocol (ARP) is a protocol defined
within the context of using IP over Ethernet. An IP node uses the ARP protocol to
obtain the Ethernet MAC address of another IP node identified by a known IP
address and connected to the same Layer 2 network.
This section describes ARP handling in ISAM in case of an IP routing model.
Note — For more information on ARP relay; see section “ARP

relay”.
18.3.1 ARP handling on the user side

• ARP request from users, for another user in the same subnet:
The ISAM acts as an ARP proxy for local user subnet IP addresses.
When the ISAM receives an ARP request for another user in the same subnet, the
ISAM sends an ARP response. However the request will be discarded for the
following exceptions:
• IP address anti-spoofing verification reveals that the user is not known: the source IP
address is not known to belong to the incoming interface
• both users are connected to the same user interface: subscribers should
communicate by way of the internal interface at the subscriber side.

NT
• ARP request from users, for the user gateway IP address;

When the ISAM receives an ARP request for the user gateway IP address, the
ISAM will send an ARP response when the IP anti-spoofing verification is
successful.
• ARP initiated by the ISAM to resolve a user MAC:
An ARP request for a user IP address is not broadcast to all users attached to the
same gateway IP interface. It is relayed to the user interface where the target user
is learned.
ARP responses from the user are validated with respect to IP address
anti-spoofing.
ARP protocol tracing can be enabled on a few subscriber interfaces. The system can
provide the list of messages exchanged with the subscriber to the ISAM syslog utility
that will determine the destination of the traces (that is, CLI screen, remote server,
local file).
18.3.2 ARP handling on the network side

Standard ARP Handling applies at the network side:
• for ARP requests received from the network.
• for ARP requests ISAM sends to the network.
18.4 DHCP relay agent

DHCP is a subscriber access protocol that enables DHCP servers to configure
internet hosts. The ISAM provides DHCP relay agent functionality for IPoE/IPoA
subscriber access interfaces in the IP routing mode.
The DHCP relay agent functionality is composed of two main components:
• layer 2 DHCP relay agent
• layer 3 DHCP relay agent
18.4.1 Layer 2 DHCP relay agent

The functionality is equal to the functionality of the DHCP Relay Agent as described
in chapter “Protocol handling in a Layer 2 forwarding model”.
DHCP protocol tracing can be enabled on a few subscriber interfaces. The system
can provide the following to the ISAM syslog utility that will determine the destination
of the traces (that is, CLI screen, remote server, local file):
• the stable states and/or exceptional events related with DHCP handling
• the list of messages exchanged with the subscriber

NT
18.4.2 Layer 3 DHCP relay agent

The ISAM can act as layer 3 DHCP relay agent for the subscribers when configured
in router mode.
The layer 3 DHCP relay agent is responsible to relay DHCP messages between the
subscribers and the DHCP servers as follows:
• Upstream: Broadcast DHCP messages received from the subscribers are unicast
to the a list of configured DHCP servers. This list is configured per incoming IP
interface associated with the subscribers of a VPRN or IES (base router).
Note — The L3 DHCP relay agent only relays broadcast
packets to the configured servers. The L3 DHCP Relay agent
never forwards or relays unicast DHCP packets from
subscribers to servers.
• Downstream: Unicast DHCP messages received from the DHCP servers are
either unicast or broadcast (based on the broadcast flag) to the correct subscriber
interfaces (using services of the L2 DHCP Relay Agent).
Subscribers connected to the same interface may get IP addresses in the same
subnet or from different subnets. User-to-user communication between those
subscribers would be via the ISAM.
Note — The layer 2 DHCP relay agent is located at the LT

board and the layer 3 DHCP relay agent is located at the NT
board.
Layer 3 DHCP relay in routed mode is configurable per IP interface of a VPRN or an

IES (base router).
When layer 3 DHCP relay is enabled on a particular IP interface one can configure:
• a list of up to eight DHCP servers
• the Gi address to be used: by default the primary address of the IP interface is
used, to overrule the default behavior the operator can specify any other
primary/secondary IP address of the concerned router instance
• whether or not to use the Gi-address as the source IP address
As an IP interface will be associated with a VLAN, the L3 DHCP relay agent instance
will be different for services that use another VLAN or another PVC.

NT
Figure 260 L3 DHCP Relay
LT 1 NT
VLAN 1
LT x VPRN / IES
LT16 VLAN 2
Per IP interface at user side:

- primary IP address
- [secondary IP address(es)]
- L3 DHCP relay data:
-list of DHCP servers
: IP interface -[gi address]
-[source IP Address]
18.5 DHCP snooping

In the IP routing model, the iBridge model and the VLAN cross-connect models
(assuming secured forwarding is enabled for the last two models), the ISAM
maintains the relation between the subscriber IP addresses and the corresponding
subscriber interfaces by snooping the DHCP messages. The DHCP snooping is
distributed and performed by every LT board.
The LT board snoops the following information:
• the subscriber IP address:
required for IP anti-spoofing in the upstream direction (that is, an IP packet
received with a source IP address which is not learned from the incoming
subscriber interface is discarded).
• IP address lease:
The ISAM also monitors the IP address lease. The relation between the
subscriber IP address and the subscriber interface is removed when the lease
time is expired. In case the lease is infinite, the subscriber IP address can only be
removed by a manual operator action (by locking the subscriber interface or
powering-off the corresponding LT board).
Usually, the NT board does not need to perform DHCP snooping except for the
following two cases:
• The Lawful Intercept functionality is enabled on the system. In this case, the NT
board snoops DHCP messages in order to establish filters in the data plane for
specific customer traffic. More details can be found in chapter “Resource
management and authentication”.
• IPv6 routing is enabled on the system. In this case, the NT board snoops DHCPv6
messages to learn the IPv6 prefixes assigned to the subscribers attached to the
ISAM and to dynamically populate the IPv6 routing table (FIB).

NT
In all cases, the DHCP sessions are preserved against:

• an NT board reset due to a software or a hardware failure
• an NT board reset due to software upgrade
The ISAM supports counter that track the number of packets that have been dropped
per line because they contain a spoofed IPv4 source address. These counters can
be made available to an external management system for troubleshooting.
The DHCP sessions are stored in the reset-safe memory of the LT and the NT boards
and are preserved against:
• an LT board reset due to recoverable or unrecoverable software failure leading or
not to the power-on reset
• an LT board reset due to software upgrade
• an LT board reset due to hardware failure
• an LT board replacement
In cases where the DHCP sessions could not be preserved (exceptional case of
combined NT and LT failures, for example, a complete ISAM power down), the
subscribers will have to re-establish DHCP sessions in order to recover the IP
connectivity.
18.6 DHCPv4 server

ISAM supports a local DHCP server for providing IP address allocation service for
subscribers. Subscribers and interconnect devices can use the address allocated for
communication within the access network and towards the external network.
Multiple local DHCP server instances can be created and mapped to different DHCP
relay interfaces depending on the requirement of the access network.
The DHCP server can be configured to choose IP subnet address pools based upon
the relay interface assigned to that subscriber. A user can also provide static
mapping between the subscriber device MAC address and an IP address through the
DHCP server.
The DHCP server provides options whereby address allocation can be controlled
based upon the relay interface path, intermediate relay nodes and end device id and
device type. The DHCP server also provides means for relay agents to specify an
alternate giAddress for allocation of secondary IP subnet addresses.
18.7 TWAMP Light

ISAM supports Two Way Active Measurement Protocol (TWAMP) light responder
function (RFC5357 Appendix I).
TWAMP Light session-reflector supports multiple TWAMP sessions which are
initiated by external TWAMP controllers for two-way round-trip delay measurements.

NT
TWAMP Light session-reflector function is supported for both base router and virtual
router instances.
ISAM supports a maximum of 32 TWAMP Light sessions and can reflect up to a
maximum of 10 TWAMP packets/second per session.
18.8 IPv6 routing protocols

The following IPv6 routing protocols are supported:
• OSPFv3, IS-ISv6 and BGP-4 (both i-BGP and e-BGP).
Note — These Routing Protocols are extensively described in

the FD 100Gbps and 320Gbps NT IHub Router Configuration
and Protocols Guide.
18.8.1 OSPFv3
All features that relate to OSPFv2 in the context of an IPv4 routed network remain
applicable to OSPFv3.
OSPFv3 for distribution of IPv6 routes is supported in the Base Router only.
18.8.2 IS-ISv6
The ISAM supports "IS-ISv6" which refers to advertising IPv6 routes using two IS-IS
TLVs: the reachability TLV and the interface address TLV. These enable distributing
the necessary IPv6 information throughout a routing domain. Using this method,
IPv4 and IPv6 routes can both be routed in the same domain.
The ISAM supports "Multi Topology IS-IS", which allows to maintain multiple distinct
IP topologies. This can be used amongst others for maintaining a different IPv4 and
IPv6 routing topology in the same domain.
The following (pre-)RFCs are supported:
• draft-ietf-isis-ipv6-05 (pre-draft of IETF RFC 5308)
• draft-ietf-isis-wg-multi-topology-xx (pre-draft of IETF RFC 5120)
Note — IS-ISv6 and Multi Topology IS-IS are not supported in

VPRNs, but only in the IES service.

NT
18.8.3 BGP-4
All BGP features used for IPv4 remain applicable to IPv6. In addition, the following
RFCs are supported:
• RFC 4760 - Multiprotocol Extensions for BGP-4
• RFC 2545 - Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing
BGP-4 is supported in the Base Router as well as in VPRNs.
18.9 Neighbour Discovery (ICMPv6)
18.9.1 Proxy ND
Proxy Neighbor Discovery (ND) is similar to local proxy ARP. This feature is useful
in a residential bridging environment where end users are not allowed to
communicate to each other directly, even when they would belong to the same
globally routable IPv6 subnet.
Proxy ND can be enabled per IPv6 interface of a VPRN or IES (base router), and
when enabled, the router will behave as follows:
• Respond to all neighbor solicitation messages received on the interface for IPv6
addresses in the subnet(s) with system MAC address as Link-layer address.
• Forward traffic between hosts in the subnet(s) of the interface.
• Drop traffic between hosts if the link-layer address information for the IPv6
destination has not been learned.
18.9.2 Dynamic Neighbor Cache population based on

Neighbour Discovery
Upon receiving a Neighbour Solicitation message from the host or Residential
Gateway, the ISAM adds an entry to the Neighbor Cache for the IPv6 (link-local)
address and corresponding MAC address (provided no entry exists yet). The entry is
put as STALE. Next, the ISAM performs a reachability check by sending a unicast
Neighbour Solliciation to the host / Residential Gateway. When successful, the entry
in the Neighbour Cache is updated to state REACHABLE.

NT
18.10 DHCPv6 Relay Agent
18.10.1 Lightweight DHCPv6 Relay Agent

The functionality is equal to the functionality of the Lightweight DHCPv6 Relay Agent
as described in chapter “Protocol handling in a Layer 2 forwarding model”.]
18.10.2 DHCPv6 Relay Agent

When performing IPv6 forwarding/routing, the ISAM supports a DHCPv6 Relay
Agent according to RFC 3315.
The operator can enable multiple instances of a DHCPv6 Relay Agent per VRF (that
is, per IPv6 interface), each instance being characterized by:
• A global unicast IPv6 address (which will be used as the value of the link-address
field in the DHCPv6 messages sent on that interface)
• A list of up to 4 DHCPv6 servers to be addressed
The ISAM relays DHCPv6 messages to all configured DHCPv6 servers. It is up to
the user to accept one of these servers (ISAM forwards DHCPv6 replies from
multiple DHCPv6 servers to the same user).
This could be useful for operators that combine multiple services within a single VRF,
while using a dedicated DHCPv6 server per service. In that case, the ISAM must be
able to forward DHCPv6 messages associated with a given service to the relevant
DHCPv6 server and send those messages with a dedicated link-address field value
per service.
Next to the LDRA behavior, the DHCPv6 Relay Agent on the NT board can optionally
insert a second “Interface-ID” (option 18) or “Relay Agent Remote-ID” (option 37).
This may be used in case the DHCPv6 server and/or the Residential Gateway are
not handling DHCPv6 options that could help discriminating the requested service
(for example, the User Class Option (option 15) or the Vendor Class Option (option
16)). The DHCPv6 server will use the Interface-ID in order to select the IPv6 address
pool to use for assigning the requested service related IPv6 address.
18.11 DHCPv6 Snooping

The LT board snoops the following information from the DHCPv6 packets:
• the user IPv6 address or prefix:
The ISAM discards any IPv6 packets whose IPv6 source address does not match
any IPv6 addresses or prefixes allocated to the user interface. The ISAM will only
check the first 64 bits of the 128-bit IPv6 address. This is sufficient because the

NT
last 64 bits of the IPv6 address hold the “Interface Identifier”; the Interface ID is
typically based on the interface MAC address and therefore not of relevance to
the IPv6 anti-spoofing function.
• IPv6 address or prefix lease:
The ISAM also monitors the IPv6 address or prefix lease. The relation between
the subscriber IPv6 address or prefix and the subscriber interface is removed
when the lease time is expired.
In case of IPv6 forwarding, DHCPv6 snooping is also performed at the NT board.

• When DHCPv6 is used for Prefix Delegation, the IPv6 forwarding table is
populated with the delegated prefix, indicating this is a non directly attached
subnet. These are so-called “DHCPv6 managed routes”. The ISAM maintains the
relation between the delegated IPv6 prefixes, its lease time and the
corresponding subscriber-facing interfaces.
• In case of stateful DHCPv6 address assignment, managed (DHCPv6) entries are
created in the Neighbor Cache for the /128 IPv6 addresses that are assigned to
the IPv6 hosts. The ISAM maintains the relation between the IPv6 address, its
lease time and the corresponding MAC address.
18.12 Bidirectional Forwarding Detection

To protect key applications, a network is usually designed with redundant backup
links. Devices need to quickly detect communication failures and restore
communication through backup links as soon as possible.
On some links, such as Packet over SONET (POS) links, devices detect link failures
by sending hardware detection signals. However, some other links, such as Ethernet
links, provide no hardware detection mechanism.
In order to detect network failures, devices can use the failure detection mechanisms
that are built into signaling protocols (for example, routing protocols), based on the
use of hello messages. These messages typically use low message rates, resulting
in failure detection times of more than one second. This is too slow for some
applications.
Some routing protocols, such as OSPF and IS-IS, provide a fast hello mechanism for
failure detection. Such a mechanism still has a failure detection rate of at least one
second and is protocol-dependent.

NT
Bidirectional Forwarding Detection (BFD) provides a general-purpose, standard,

medium and protocol-independent fast failure detection mechanism. It has the
following benefits:
• Detecting failures on any bidirectional forwarding paths, such as direct physical
link, virtual link, tunnel, MPLS Pseudowire, multi-hop path, and unidirectional link,
between network devices.
• Providing consistent fast fault detection time for upper-layer applications.
• Providing a configurable failure detection time which can be sub-second to speed
up network convergence, short application interruptions, and enhance network
reliability.
The ISAM supports BFD for fast failure detection with the following protocols:
• Static routing (for example, configured routes)
• OSPF
• IS-IS
• BGP
• PIM-SSM
• MPLS Pseudowires (T-LDP)
• RSVP-TE
• Ethernet Link Aggregation Group (LAG)
BFD can operate either over a single IP hop, or over multiple hops, for example,
across different routing areas. The latter is the case, for example, when protecting a
BGP session running between two routers that are not directly attached.
The ISAM can configure the message rate for each BFD session. Multiple BFD
sessions can be supported in parallel (for example, one BFD session per IP
interface, terminated on the directly attached peer). The BFD message rate can be
configured according to the required detection speed: high message rates provide
for faster failure detection. It is an operator decision to select the balance between
the number of BFD sessions and the message rate.
The configuration of the BFD polling interval should take into account the time
required for the packet to reach the destination. For instance, when using multi-hop
BFD, the polling interval may be set higher than one second to avoid the BFD
session from timing out before the packets reach the destination.
When using multi-hop BFD over an Ethernet LAG, one should take care that the
failure detection time is set greater than the LAG failure detection time of one second.
Otherwise, the BFD session would time out too soon, which would defeat the
purpose of using an LAG.

NT

System Description for FD 100/320Gbps NT and FX Multicast and IGMP
NT
19 Multicast and IGMP

19.1 Overview
19.2 Advanced capabilities
19.3 System decomposition
19.4 Multicast and forwarding models
19.5 Multicast support for ISAM acting as pre-aggregator
19.1 Overview
Multicast is the simultaneous transmission from a single device (such as a video
head end) to a group of recipients (such as video Set Top Boxes) using the most
efficient strategy to deliver the data over each link of the network only once.
The ISAM supports IP Multicast based on VLAN bridging (layer 2) technology.
Internet Group Management Protocol (IGMP) is the control protocol for multicast in
a layer 2 network. It is used between the recipients (hosts) and multicast routers to
join and leave a group.
Note — IGMP is specified in IETF RFC 2236 (IGMPv2) and

RFC 3376 (IGMPv3).
By default, bridges flood multicast frames as well as IGMP packets between the
multicast router and the hosts. This not only creates a security issues when end
users can see each other's IGMP messages, but also the resulting bandwidth waste
is unacceptable on relatively low bandwidth interfaces like xDSL. Bridges can
optimize the bandwidth usage by snooping the IGMP control packets exchanged
between hosts and multicast router. Efficient multicast trees are constructed from the
learned information. The ISAM supports IGMP proxy, which serves as an alternative
variant for IGMP snooping.
Note — IGMP snooping is specified in IETF RFC 4541.

Multicast and IGMP System Description for FD 100/320Gbps NT and FX
NT
Figure 261 IGMP enabled bridges

Member group A Host
Video
Head
Member group A end
Edge
Router
LAN
Bridge IP network
Bridged
Member group A VLAN
Member group B
data
IGMP
Member group B
19.1.1 Data plane

IP Multicasting uses IP datagrams with a multicast destination IP address, which is
a class D address in the range “224.0.0.0” through “239.255.255.255”.
In the layer 2 network between the hosts and the edge router, the IP datagrams are
encapsulated in Ethernet frames with a multicast destination MAC address that is
derived from the multicast destination IP address. Hosts should not only accept
frames with a destination MAC address matching their own MAC address, but also
frames with a multicast destination MAC address of the groups of which they are a
member.
Note — Remark that multiple (32) IP addresses map to the
same multicast IEEE 802 MAC address.
Besides a forwarding database for unicast traffic, bridges maintain multicast

forwarding tables, also known as multicast Forwarding Data Base (FDB),
representing the replication trees.
The ISAM maintains a multicast forwarding table per VLAN. The entries are known
as multicast trees in the management plane. Multicast trees are indexed with the
multicast IP address, rather than with the multicast MAC address. This makes it easy
to correlate the data plane with the control plane (IGMP) which is based on IP
addresses.
Note — The use of IP addresses does not eliminate the issue
of many-to-1 mapping from IP addresses to MAC addresses,
since there are still components in ISAM that forward based on
the MAC address.

NT
In Figure 262, the multicast forwarder is shown as segregated from the unicast
forwarder for the same VLAN. Multicasting, as opposed to flooding, is only supported
in VLANs that have IGMP enabled, so-called multicast VLANs.
Figure 262 Multicast data plane
DSL interfa ce Port P2
Unicast forwarding VLAN Port GE interface
iBridge
Multicast forwarding 224.0.10.2

Port P1
240.0.10.1
Multicast Fwd Ta ble

VLAN Multicast IP address Egress ports
15 240.010.1 { P1 }
15 240.010.2 { P1, P2 }
IGMP can only be enabled on network VLANs whose unicast forwarder is an iBridge,
but not a cross-connect VLAN.
IGMP can also be enabled on a network VLAN terminated in an IP interface. But
then, for multicast traffic, this network VLAN must have user-side ports besides
network-side ports, see Figure 262.

NT
Figure 263 Common network VLAN for L3 unicast and multicast
ISAM
Edge Router
IHub
LT
CPE
VRF VLAN B
Edge Router
VLAN A
L3 unicast data traffic (IP routed...)
multicast data traffic
L2 unicast data traffic (bridged...)
Note — IGMP can also be enabled in L2 VPN (VPLS) whose

unicast forwarder is an iBridge.
If IGMP is not enabled, then the forwarder is either transparent for or discards IGMP
packets and multicast frames. Refer to Table 64.
19.1.2 Control plane

The ISAM supports an IGMP Proxy. Compared to an IGMP Snooper, an IGMP Proxy
maintains independent “Router” state machines towards the hosts and “Host” state
machines towards the routers. This offers some advantages, such as spreading the
load of queries towards subscribers.
The IGMP Proxy updates the multicast forwarding tables dynamically, based on the
control plane events (join requests, leave requests).
Note — IGMP Proxy is defined in IETF RFC 4605.

NT
Figure 264 IGMP control plane
IGMP
R Proxy H
upda te
join 240.0.10.1
join 240.0.10.2 Multica st Fwd
join 240.0.10.1
VLAN port
By default, IGMP version 2 as well as IGMP version 3 are supported. The system can
be configured to only accept IGMPv3 and drop incoming IGMPv2 messages.
IGMPv1 messages will always be dropped.
Multicast services are configured on subscriber ports by creating an IGMP channel
on top of the subscriber port. This enables IGMP proxy on the subscriber port.
By enabling IGMP on a network VLAN, that is, making it a multicast VLAN, IGMP
snooping is enabled on all the network ports and the subtending ports that are in that
VLAN.
When IGMP is encapsulated over PPP, it is handled transparently.
IGMP proxy as an alternate to PIM-SSM is enhanced to provide multicast
forwarding/routing with interface level redundancy. Active/Active or Active/Standby
redundancy states for IGMP Proxy version 2/3 support is enabled once configured
on Proxy enabled IES interfaces. Hashing of Multicast traffic distribution occurs in a
simple round-robin manner spread across all active proxy interfaces. ISAM does
aggregation of joins/leaves from IES interfaces as well as converts them to
appropriate IGMPv2/v3 report type before sending in upstream direction to PIM
enabled Routers.
19.2 Advanced capabilities

The regular multicast mechanisms are suited to provide a very basic video service.
More advanced capabilities are available. Most of these capabilities require the
configuration of the list of IP addresses of the multicast channels that can be joined
by the ISAM subscribers. This is known as the list of preconfigured multicast
channels, or “premium” video channels.
Join requests received from the subscribers are identified as targeting a
preconfigured multicast channel by comparing the join (multicast IP address, source
IP address) against the list of preconfigured multicast channel identified as follows:
• cross-VLAN multicast: (multicast IP address, source IP address) (see
section “Cross-VLAN multicasting”)
• fixed multicast VLAN per IGMP channel: (multicast IP address, source IP
address, multicast VLAN) (see section “Fixed multicast VLAN per IGMP channel”

NT
Some of the advanced capabilities also apply to non-configured “best-effort” video

channels, that is, to IP addresses that are not configured in the ISAM.
Provisioning multicast channels can be simplified by manipulating “ranges of
channels”. A range of channels is characterized by a set of channels sharing the
same characteristics (source IP address, multicast VLAN (optional), bandwidth
parameters, …) and whose multicast IP address belongs to a given range.
Such a “channel range” can be manipulated as one management object by the
operator.
19.2.1 Static infeed

The availability and join latency of popular multicast channels can be improved by
feeding them statically up to the ISAM. The channel is semi-permanently streamed
in the aggregation network up to the ISAM uplink, whether hosts joined the channel
or not. There is no need for the edge router to react on IGMP requests to join this
channel.
To take full advantage of statically-fed channels towards the ISAM, no specific
configuration in ISAM is needed, since ISAM continuously dynamically learns from
which port(s) a multicast channel is fed. These ports need not be the same as the
port having the Querier. The root of the replication tree can be static, but ISAM does
not take this into account. Statically fed channels towards subtending nodes or to
individually selected PON UNIs are configured in the ISAM by configuring static
multicast branches, as opposed to the dynamic multicast branches created through
IGMP signaling.
Note — Statically fed channels still support dynamic branches,

controlled through IGMP signaling.
Figure 265 Static infeed

Subtending ISAM ISAM Aggregation network
No IGMP
necessary Edge
Router
No IGMP
necessary
IGMP static
Branch Root
dynamic

NT
19.2.2 Cross-VLAN multicasting

Multicasting in an iBridge is normally contained within the same VLAN. As a
consequence multicast-enabled subscriber ports would need to be VLAN ports
within the multicast VLAN.
With cross-VLAN multicasting ALL the subscriber ports that are multicast-enabled
can receive multicast traffic from ALL the multicast VLANs. This makes it possible to:
• mix multicast and other services at the subscriber ports, yet segregate these
services in the aggregation network in different VLANs.
• offer multicast services on subscriber ports of different iBridges, yet share the
multicast channels in a common VLAN. Cross-VLAN thus reduces the number of
copies of the same multicast channel.
• offer multicast services on subscriber ports that employ other forwarding modes
than iBridge, such as VLAN cross-connects. Without cross-VLAN, multicast traffic
would be discarded or would be transparent, implying no efficient replication.
• organize multicast channels in multiple multicast VLANs, without limiting the
access possibilities of the subscriber.
Figure 266 Cross-VLAN multicast - forwarding view

240.0.10.2
Multicast VLAN
forwarding
(network-side)
SAP
Unicast forwarding VLAN

VLAN port (iBridge)
(network-side)
SAP
Unicast forwarding
VLAN
(VLAN-CC)
VLAN port (network-side)
SAP
In cross-VLAN multicasting, when the subscriber joins a channel, the ISAM finds the
multicast VLAN from the preconfigured multicast channel. If the requested multicast
IP address, possibly extended with source IP address (see Section “Source Specific
Multicasting”) is not in the list of multicast channels, then the join is handled in the
scope of the subscriber VLAN. In case the subscriber VLAN forwarder is an iBridge
(that is, multicasting is supported), the join is proxied as a “best-effort” video service.
Otherwise, the join is transparently forwarded or is discarded, see Table 64.

NT
Figure 267 Cross-VLAN multicast - network view

ISAM Aggregation network
STB Edge
router
Fwd BTV VLAN 15
BTV + VOD
Fwd VOD VLAN 16
Multicast
channel list
Multicast
VLAN
IP address
240.0.10.1 15
240.0.10.2 15
19.2.3 Source Specific Multicasting

The multicast IP address range is unique. In a wholesale environment, different
multicast service operators would need to make agreements to use non-overlapping
subranges.
Source Specific Multicasting (SSM) makes it possible for multicast service operators
to use overlapping multicast IP address ranges because SSM-mode multicast
channels are identified by the combination of the multicast IP address and a source
IP address, which refers to the multicast service provider. When configured in
IGMPv3, subscribers can join to SSM-mode channels and the ISAM can distinguish
the requests by means of the source IP address, even if the multicast IP address is
the same.
Even though subscribers can join based on the combination of multicast IP address
and source IP address, the multicast forwarding table of the ISAM (and possibly also
in the aggregation network) does not support the source IP address. That is, the data
plane is SSM-unaware. For this reason, the same multicast IP address can only be
re-used in combination with a different VLAN. When receiving a join for an
SSM-mode channel, the ISAM finds the associated VLAN in the list of preconfigured
multicast channels. SSM channels must therefore be preconfigured as multicast
channels.

NT
Next to preconfigured SSM channels, GPON and XGS-PON / TWDM-PON access

also supports unconfigured SSM channels with following restrictions:
• The system does not support that a subscriber joins simultaneously multiple
multicast channels with the same group address but different source addresses
• The source address is not controlled, leading to a potential security risk
Note 1 — The method to use SSM in the control plane but not
in the data plane of L2 networks is specified in BBF TR-101.
Note 2 — For GPON and XGS-PON / TWDM-PON access
IGMPv3-SSM is supported for selected ONTs only.
Figure 268 Source Specific Multicasting
Aggregation network Video
ISAM
Head End
STB
Edge
(240.0.10.1,140.20.20.1) router
Fwd 140.20.20.1
BTV VLAN 15
(240.0.10.1,144.30.30.1)
Fwd
VOD VLAN 36
144.30.30.1
Multicast Multicast
Fws table channel list
Multicast Multicast Source
VLAN VLAN
240.0.10.1 15 240.0.10.1 140.20.20.1 15
240.0.10.1 36 240.0.10.1 144.30.30.1 36
19.2.4 Fixed multicast VLAN per IGMP channel

Using a fixed multicast VLAN per IGMP channel offers an alternative to SSM-based
IPTV wholesale with the following characteristics:
• ASM-based deployment (IGMPv2 or IGMPv3 ASM) with overlapping group
address ranges across Video Service Providers:
This approach simplifies multicast address management within the access
network. Indeed, there is no need anymore for Video Service Providers to agree
upon non-overlapping multicast address sub-ranges when using IGMPv2 or
IGMPv3-ASM.

NT
• SSM-based deployment with overlapping source addresses across Video Service

Providers:
An example of such a configuration is a network where multiple Video Service
Providers distribute IPTV services from the same Video Content Provider
generating video traffic over IP, including its source IP address. Each Video
Service Provider wants to keep control on its own offering, leading to overlapping
IP source addresses in the network.
In order to support overlapping “Group Address” or “Source Address” across Video

Service Providers, the ISAM allows to assign a dedicated Video Service Provider
(that is, Multicast VLAN) per subscriber (that is, IGMP channel) so that the (S,G)
processing is instantiated per Video Service Provider, allowing full freedom.
This feature changes the algorithm for determining the multicast VLAN, as it was
explained in “Cross-VLAN multicasting”. With “fixed multicast VLAN per IGMP
channel”, the multicast VLAN for preconfigured and non-configured multicast
channels, is determined by the per-IGMP channel configured multicast VLAN.
Figure 269 Fixed Multicast VLAN per IGMP channel
SP own (unique)
Access/ NNI Mcast groups
Aggregation
network
Mcast content provider
(for example, Free-To-Air TV)
Fwd
BTV S-VLAN 15
BTV + VOD SP #2
Fwd
BTV S-VLAN 16
Unicast (VOD, HSI, ...)

Fwd S-VLAN (+ C-VLANs) SP #1
Example:
(S,G)=(140.20.20.1,240.0.10.1) stream
will be requested by end-users over
SP own (unique) both BTV VLANs 15 and 16
Mcast groups
The “fixed Multicast VLAN per IGMP channel” mode is defined at system level and
cannot be used simultaneously with other modes where multiple Video Service
Providers can be selected by the subscribers by means of either the “Group Address”
(ASM) or the “Source Address” (SSM).
Note — For GPON and XGS-PON / TWDM-PON access, the

“fixed Multicast VLAN per IGMP channel” is supported when
ONT-to-OLT signaling is enabled or when the ONT supports
the provisioning of “multicast ACLs” through ONT Management
Control Interface (OMCI) (see section “System
decomposition”).

NT
19.2.5 Fast leave

In the normal leave procedure of IGMP, when a host leaves a multicast channel, the
router queries the port for any other hosts that must still receive the multicast
channel. It typically takes more than 1 second before the router can decide there is
no more interest in the multicast channel and that the Multicast Fwd table is updated
to stop replication on that port.
Note — The situation of multiple hosts on a user port can occur
in case of a bridged CPE and multiple STBs.
Zapping behavior is such that the host which left the multicast channel does not wait
until the multicast channel is stopped and immediately joins another multicast
channel. During a short time, both the old and the new multicast channel are
therefore present on the subscriber port. For xDSL lines, which bandwidth is often
tailored to accommodate a limited number of multicast channels, the extra bandwidth
from the old channel may lead to frame loss.
With fast leave, the ISAM keeps track of all the hosts that joined a certain multicast
channel and immediately knows when the last host on the subscriber port has left the
multicast channel. If that is the case, then the ISAM immediately updates the
Multicast Fwd table to stop replication on that port.
Fast leave can be enabled per multicast channel.
Figure 270 Fast leave on subscriber ports
normal leave fast leave
ISAM ISAM
STB STB
CPE CPE
bandwidth bandwidth
240.0.0.1 240.0.0.1
Leave 240.0.0.1 Leave 240.0.0.1

Query 240.0.0.1 240.0.0.1
Join 240.0.0.2 Join 240.0.0.2
240.0.0.2 240.0.0.2
> 1 sec
Query 240.0.0.1
240.0.0.1
time time

NT
19.2.6 Resource admission control on the subscriber port

Video services can tolerate only very minimal frame loss, therefore an
oversubscription of video bandwidth should be avoided. Also, it may not be
acceptable that lower-priority services, such as HSI, are completely blocked by video
traffic. In this respect, the ISAM supports 2 mechanisms to control the resources on
the subscriber ports. If any of the checks fail, then join messages are rejected.
• Control the number of multicast channels per subscriber port:
This mechanism, which is primarily intended for access control, can be used as a
simple multicast-only RAC assuming that all multicast channels have more or less
the same bandwidth.
The maximum number of multicast channels is configured per IGMP channel.
• Control the downstream bandwidth per physical (for example xDSL) line
This mechanism takes into account the actual bandwidth of each multicast
channel, as configured per multicast channel. It is integrated in a multi-service
RAC.
A maximum video bandwidth can be configured in the CAC profile, refer to
chapter “Quality of Service”, section “CAC profile”.
Note — For GPON and XGS-PON / TWDM-PON access, RAC

on the subscriber port is supported when ONT-to-OLT signaling
is enabled or when the ONT supports the provisioning of
“multicast ACLs” through OMCI; see section “System
decomposition”.
19.2.7 Resource admission control on the uplink

An ISAM with an FD 100/320Gbps NT or an FX NT has no configuration for resource
admission control on the uplink. It is assumed that resource admission control, and
in particular bandwidth control, is done by the edge router, for example, by using
IGMP forking.
19.2.8 Access control

Access control limits subscribers access to multicast services.
The ISAM can restrict the access to a predefined set of multicast channels and
disallow joining any other multicast channels, like some kind of ACL. For this purpose
multicast packages are configured, containing a set of preconfigured multicast
channels. The set of multicast packages that are allowed to be viewed is then
configured per IGMP channel.

NT
Packages can also be used to give limited preview access to multicast channels. The
set of multicast packages that are allowed to be previewed is then configured per
IGMP channel. With preview access, subscribers can view the multicast channel
during a short time period.
Note — For GPON and XGS-PON / TWDM-PON access,

access control is supported when ONT-to-OLT signaling is
enabled or when the ONT supports the provisioning of
“multicast ACLs” through OMCI.; see section “System
decomposition”.
19.2.9 Call Detailed Records

The ISAM can generate Call Detailed Records (CDRs). The CDRs log the actual
viewing behavior of the individual subscribers. CDRs for example report the identity
of the subscriber port, the multicast channel joined, the start time and view duration.
They are sent in real time to a server using TFTP or syslog protocol. The server can
use the information to bill the subscribers on a Pay-Per-View basis.
CDR generation can be enabled and configured in the IGMP system.
19.2.10 Static router ports

The IGMP Proxy dynamically learns the router port as the network port from which it
received the queries, that is, behind which the multicast router resides. Join
messages and leave messages are sent on that learned router port. There can be
only one dynamic router port.
In some network topologies there is a need for multiple router ports. Configuring
network-side Service Access Points (SAP) respectively SDP binding as multicast
router (MR) offers this capability.
For example, a network topology may have two multicast routers directly attached to
the ISAM. In that case, only one multicast router will assume the role of the querier,
the other multicast router serves as backup. To be fully prepared to take over in the
event of a failure of the querier router, the non-querier router must also be aware of
the multicast channels that need to be injected in the aggregation network. By
configuring both network-side SAP as multicast router (MR), all the join messages
and the leave messages are sent to both routers.

NT
Figure 271 Example of static router port

ISAM
non-Querier
STB
Join 240.0.0.1
0.1
Join 240.0.
Join 240.0.0.
1
Query
Querier
MR SAP
The ISAM is able to process IGMP query messages having a source IP address
0.0.0.0. These messages may be sent by an Ethernet switch acting as IGMP proxy,
which does not have an allocated IP address. Processing such IGMP messages is
useful to speed up network convergence for network topologies with ISAMs
connected in a ring that is connected to a separate Ethernet switch acting as a Root
of the Spanning Tree or acting as the Ring Protection Owner.
19.2.11 IGMP forking

An Edge Router implementing hierarchical scheduling, shapes downstream traffic
according to the actual user line rate, minus the bandwidth taken by multicast
channels streamed on this user line. Such Edge Router needs to be aware of that
bandwidth.
An IGMP Proxy enhanced with IGMP forking copies every upstream IGMP packet
towards the Edge Router into the same VLAN on which it has been received. The
forked packets contain the original source MAC and IP address from the STB. By
monitoring all the IGMP traffic on the user line, the Edge Router can thus calculate
the bandwidth taken by multicast channels on this user line.
IGMP Forking can be enabled in the IGMP system or on the IGMP channel.

NT
Figure 272 Example of IGMP forking

ISAM
Aggregation network Edge
Proxy Router
( Proxied Join )
Join
STB Fwd
BTV VLAN 15
Forked Join
BTV+HSI+Voice Fwd
HSI+Voice VLAN 16
Warning — IGMP forking generates many IGMP packets.
To be effective in avoiding overload issues, the operator should make sure that these
forked IGMP packets are not snooped/proxied in the ISAM or elsewhere in the
aggregation network. In particular, the operator should:
• choose a BTV VLAN different from any unicast forwarding VLAN in which forked
packets are inserted
• not deploy non-configured (best effort) multicast service in any unicast VLAN in
which forked packets are inserted
• not deploy L2 LT boards in the ISAM (because such cards apply IGMP proxy on
ALL the network VLANs, even on unicast VLANs that may carry forked IGMP
traffic)
19.2.12 PIM-SSM
The ISAM implements the PIM Source Specific Multicast (PIM-SSM) variant of
PIM-SM (PIM Sparse Mode) because it is better suited for the one-to-many topology
typically used for IPTV deployments.
ISAM supports PIM-SSM on network interfaces according to RFC 4601 with the
following remarks:
• Due to the location of the ISAM in the network, the PIM-SSM roles supported by
the ISAM are limited to “Designated Router” (DR) and “Last Hop Router” (LHR).
• PIM-SSM is only supported for the base router (that is, not supported for VPRNs)

NT
• ECMP based load sharing is supported

• Ring configurations are supported by configuring the ISAM as “Intermediate
Router”, using a different VLAN on each leg of the ring (PIM snooping not
supported)
As LHR, the ISAM is responsible for converting IGMP messages received from the
subscribers into PIM-SSM ones. In order to support subscribers generating “Any
Source Multicast” (ASM) messages (that is, IGMPv2 or IGMPv3-SSM), the ISAM
provides an “SSM translation function” that will convert ASM messages into SSM
ones by adding an IP source address selected in function of the “Group Address”,
provided the “Group Address” belongs to the ASM range as indicated in Figure 273.
Figure 273 SSM Translate Overview
SSM txl
Provider A1 IPSA1
ASM
Group IP Address
Provider A2 IPSA2
Provider A3 IPSA3
SSM
Provider Provider Provider

N.A.
S1 S2 S3
Multicast routing using PIM-SSM enables source-based tree approach for multicast
traffic forwarding with PIM neighbors established via IP connectivity discovered
using unicast routing protocols such as OSPF/ISIS/BGP. Reverse path forwarding is
performed using the Source-Unicast address to validate the upstream interface for
the given multicast source. MP-BGP is capable of supporting two sets of routing
information, one set for unicast routing and another for multicast routing.
Using AFI=1 SAFI=2 BGP exchanges IPv4 prefixes used for RPF checks against
each multicast packet to verify the upstream interface to be the one in which the
multicast source is advertised and reachable.
19.3 System decomposition

Multicast services impact both the LT boards and the NT board.
The LT board implements a multicast forwarder and IGMP proxy. The LT forwards
multicast streams from internal LT-NT ports to user ports. Advanced features like
cross-VLAN multicasting, fast leave, most of SSM, RAC on the user line, access
control and CDRs are implemented in the LT board.

NT
For GPON and XGS-PON / TWDM-PON based access, the ISAM performs the same
functions as a DSL LT, but in this case the multicast forwarder replicates multicast
packets to the various OLT ports, that is the various PON interfaces. The PON
technology itself, due to its point-to-multipoint nature, ensures that all ONTs coupled
to the PON receive all multicast streams that were forwarded onto the PON. The
ONT also acts as a multicast forwarder, which replicates multicast streams to the
correct ONT ports (UNIs).
There are two basic models for configuring the ONT multicast forwarding table:
1 The ONT is transparent for IGMP messages. IGMP messages are handled on
the OLT in the IGMP proxy, and once an IGMP JOIN is accepted, possibly after
performing a RAC check on the subscriber port or an Access Control check, the
ONT is instructed to create multicast branches to the right UNIs via a
Nokia-proprietary ONT-to-OLT signaling
2 The ONT performs IGMP snooping in order to learn what multicast branches it
needs to create towards the UNIs. Depending on the ONT Management Control
Interface (OMCI) capabilities supported by the ONT, two sub-modes can be
considered:
• RAC/Access rights management by OMCI not supported:
In this mode, no RAC checks on the subscriber port are done on the ONT, neither
Access Control checks. Next the IGMP messages are further sent to the OLT where
they are processed in the IGMP proxy.
• RAC/Access right management by OMCI supported:
In this mode, the OLT delegates some part of the RAC and access rights control to
the ONT by provisioning through OMCI a set of rules (“multicast ACLs”) specifying:
* The list of allowed channels
* The bandwidth associated to the channel
* The default behavior for unconfigured channels
Once those rules are provisioned on the ONT, the ONT snooper can directly apply
those rules to check if an IGMP join can be granted or not. If granted, the IGMP join
is passed to the OLT for further processing (and it might happen that RAC / access
right controls at OLT level leads to decide not to grant the join).
This approach is a fully standard and therefore interoperable approach for managing
multicast services on ONTs.
Note that the “channel preview” cannot be provisioned through OMCI standards and
consequently, the feature cannot be used together with that ONT management
model.
19.3.1 OMCI-based access rights and CAC control

Figure 274 shows the multicast provisioning modes at the ONT.

NT
Figure 274 Modes of multicast provisioning at the ONT

Multicast provisioning by means of
the proprietary OLT-ONT signalling channel
2
1
Join
Join
Proxy
3
Proprietary
Join
Multicast provisioning through OMCI

1
OMCI
Snooper
Proxy
2 3
Join Join
Snooper
Proxy
Multicast provisioning by means of the proprietary OLT-ONT signalling channel:

1 No snooper at the ONT: the Join is passed transparently to the OLT
2 The OLT performs CAC. If Ok, a multicast branch is created towards the PON
and the Join is propagated to the network (if needed)
3 Proprietary Join sent by the OLT to the ONT to provision the required multicast
branch
Multicast provisioning through OMCI:

1 The OLT provisions the ACL through the OMCI (at ONT start-up or
reconfiguration)
2 The snooper at the ONT performs UNI CAC. If Ok, a multicast branch is
configured at ONT level and the Join is propagated to the OLT (if needed)
3 Proxy at the OLT performs additional CAC. If Ok, a multicast branch is created
towards the PON and the Join is propagated to the network (if needed)

NT
19.3.2 System decomposition

The IHub implements a multicast forwarder and an IGMP proxy snooper. The IHub
IGMP proxy snooper operates completely in the scope of a VLAN and VPLS, that is,
there is no cross-VLAN support in the IHub.
To make that the IHub does IGMP proxy, as opposed to snooping, Service Access
Points (SAPs) on LT-side ports must be configured as SQ SAPs (Send Query SAP).
To support redundant Queriers in the network, for example, in a ring structure,
Service Access Points (SAPs) respectively Service Distribution Point bindings to
VPLS (SDP bindings) on network ports must be configured as Multicast Router (MR)
port, so that Reports and Leaves are forwarded to both upstream Queriers (or
multicast edge routers) in order to keep them in synchronization. General Queries
are also forwarded to all ports so that ISAM participates in the Querier Election
process transparently.
MR SAPs behave as IGMP hosts towards the network. They can be configured
statically, or can be learned by receiving a General Query from the network.
SQ SAPs behave as IGMP router towards the LT boards.
Figure 275, Figure 276 and Figure 277 show the system decomposition for multicast
and how the management concepts map on the system components.
Figure 275 System decomposition for multicast
LT
STB IGMP Proxy
Unicast VLAN
mcast fwd
IHub
Multicast IGMP Snooper
VLAN Aggregation
LT mcast fwd
network
IGMP Proxy
mcast fwd
Multicast VLANs
Multicast channels
Multicast VLANs Multicast bundles
Multicast channels Router ports
IGMP channels Multicast trees
Multicast packages

NT

TWDM-PON with ONT-to-OLT signaling)
ONT-to-OLT signalling
STB ONT
Unicast VLAN
LT
mcast fwd IGMP Proxy
mcast fwd
ONT IHub
VLAN Aggregation
LT mcast fwd
network
IGMP Proxy
mcast fwd
Multicast VLANs
Multicast channels
Multicast packages

TWDM-PON with IGMP snooping on the ONT)
STB ONT
Unicast VLAN IGMP snooping
LT
mcast fwd IGMP Proxy
mcast fwd
ONT IHub
VLAN Aggregation
LT mcast fwd
network
IGMP Proxy
mcast fwd
Multicast VLANs
Multicast channels
Multicast packages
19.4 Multicast and forwarding models

This section focuses on the case where the ISAM participates in the multicast data
and control plane. Depending on the forwarding model and on the configuration
(multicast enabled or not, joined channel in the list of multicast channels or not), the
ISAM does or does not participate. If the ISAM does not participate, the ISAM may
discard or transparently pass the multicast data and control frames. Table 64
provides a summary of the handling of IGMP packets and multicast frames in
forwarders.

NT
Table 64 Handling of IGMP packets and multicast frames in forwarders
Forwarder to which the IGMP channel not IGMP channel created, IGMP channel created,
user is linked for unicast created requested multicast requested multicast
traffic channel not in list channel in list
VLAN Cross-Connect IGMP and mcast IGMP and mcast IGMP proxy and mcast
transparent transparent replication
iBridge (IPoE) IGMP and mcast IGMP proxy and mcast IGMP proxy and mcast
discarded replication replication
iBridge (PPPoE) IGMP and mcast Not supported Not supported

transparent
PPP cross-connect IGMP and mcast Not supported Not supported

transparent
19.5 Multicast support for ISAM acting as

pre-aggregator
Traffic from small remote nodes can be "pre-aggregated" by an ISAM acting as a hub
in order to optimize the bandwidth utilization of the aggregation network ports.
This can be achieved by connecting the subtended nodes to either:
• an NT port
• an LT port, configured in NNI mode (GE or 10GE Ethernet LT, GPON or
XGS-PON / TWDM-PON LT)
Figure 278 shows the IGMP processing

Figure 278 IGMP processing
Hub ISAM
UNI
Sub 1 NNI LT
NT
UNI
Sub 2
Subtending
NT Port
IGMP processing (proxy or snooper)

NT
End-to-end multicast features are fully supported when using such a cascaded
network architecture where each switching state is equipped with either an IGMP
proxy or snooper to maximize the multicast scalability.
Note however that the IGMP proxy in charge of the UNI will support features
associated with subscriber management for multicast services while the NNI proxy
will focus on setting up the multicast infrastructure, mimicking the NT behavior.
The functional split is shown in Table 65.
Table 65 Multicast support per port type
Feature UNI NNI NT Sub.

port
Add/Remove mcast branch Y Y Y
Cross-VLAN multicast Y N N
Fast leave Y Y Y
Resource admission control (# channels, bandwidth) Y Y N
Access right control (video package, preview,…) Y N N
Call Data Record Y N N
Forking Y N N
In case of multicast wholesale, a large amount of multicast VLANs might have to be

propagated (efficiently thanks to the IGMP proxy) from the network to all remotes,
requiring NNI ports to support enough VLANs to cope with all video providers
connected to the ISAM (for details on dimensioning, please consult the relevant
ISAM Product Information Guide).

System Description for FD 100/320Gbps NT and FX Quality of Service
NT
20 Quality of Service
20.1 Introduction
20.2 Upstream QoS handling
20.3 Downstream QoS
20.4 Hardware mapping of QoS functions
20.5 Configuration of QoS
20.1 Introduction
In addition to delivering best-effort, high-speed Internet services, xDSL access
networks are evolving to multiservice access networks that must be capable of
supporting a whole range of services, such as:
• conversational services (Voice over IP (VoIP), video telephony)
• video services (Video on Demand (VoD), Broadcast TV)
• transparent LAN services for business customers
• data services for business customers
• data services for residential customers
These services must be delivered with the appropriate level of QoS. In the case of
xDSL access networks with Ethernet aggregation, there are a number of network
elements, for example, BRAS, IP edge routers, ISAM, or CPE, that must each give
the correct priority treatment to the various application flows. Network performance
objectives for the different service types are documented in the ITU-T
Recommendation Y.1541 (Network performance objectives for IP-based services).
This is achieved by classifying these application flows at the ingress of the network
into a limited set of aggregate flows that are characterized by certain QoS markings.
The different network elements will then provide per-QoS class queuing and
scheduling for these aggregate flows.
As explained in the “Layer 2 forwarding” chapter, the ISAM, operating as a VULA
node, will connect to the network through untrusted uplinks where SLA enforcement
will be performed on traffic received from the network to guarantee fairness between
the various Content Providers directly interfacing with the ISAM. The result of the
SLA enforcement is then propagated downstream through the whole Access
Network by remarking either the p-bit or DEI fields of the packets.
This SLA enforcement is performed by an Ethernet LT hosting the network
interfaces, that is, the so-called "VULA uplinks".

Quality of Service System Description for FD 100/320Gbps NT and FX
NT
The following section provides an overview of the role played by the ISAM in
end-to-end QoS.
20.2 Upstream QoS handling

This section deals with subscriber- or ISAM-originated traffic that is transmitted on
the network link.
20.2.1 Overview
Figure 279 shows the standard QoS model which includes a configurable
system-wide p-bit to traffic class mapping, four queues and a fixed scheduling
scheme. Some LT board types support an eight-queue model, as explained in the
following notes. If an LT board type is not explicitly mentioned in the following, then
it only supports the standard QoS model.
The GE and 10 GE Ethernet LT board always supports 8 queues.
Figure 279 Qos Overview - Standard Model
ISAM Traffic
.1p
queues Classes
TC7 111
Voice TC6 110
TC5 101
GE/FE WRR
Video TC4 100
WFQ
TC3 011
CL TC2 010
WRR
WFQ TC1 001
BE TC0 000
DSCP to P-bits
Traffic Classes
Classification
p-bit marking
Mapping of
Scheduling
Mapping to
Mapping to
queues
Figure 280 illustrates a flexible QoS model which allows:

• a flexible mapping of p-bits to traffic class, configurable per forwarder
• a flexible number of queues (either four or eight)
• a flexible scheduling of the queues, where each queue has a configurable priority
and weight

NT
The flexible model can be configured for GPON and XGS-PON / TWDM-PON
subscribers. Both the standard model and the flexible model are described in more
detail in the following sub-sections.
The same model, but a fixed number of 8 queues, is also supported by the 10GE
Ethernet LT board.
Figure 280 QoS Overview - Flexible Model
.1p
ISAM Traffic
queues classes
110 VoIP
VLAN 1
Queue7 TC 7 101
Queue6 TC 6
Queue5 TC 5
GigE/FE
SP+WFQ Queue4 TC 4
Scheduler
Queue3 TC 3 001 HSI #1
VLAN 2
Queue2 TC 2 000
Queue1 TC 1
001 HSI #2
Queue0 TC 0 VLAN 3
000
20.2.2 Classification
The purpose of classification is to identify flows or streams of traffic which need a
different treatment, that is, which require a different quality of service.
Figure 281 QoS: classification
1. Voice
2. Video (VoD, BTV)
3. Controlled load (home working)
4. Best effort (HSI)
classification
For the Standard Model of Figure 279, four main traffic classes have been identified:
Voice, Video, Controlled Load (CL) and Best Effort (BE). These traffic classes are
listed in Table 66, together with their application and recommended 802.1p value.
For LT boards that only support four queues, the eight traffic classes are mapped to
four queues, according to a fixed scheme. See “Mapping and queueing” for details.
For LT boards that support 8 queues, each traffic class is mapped to its own queue.

NT
This approach segregates network control, voice and video-telephony into the
highest priority queue, broadcast video and video-on-demand into the second
queue, business customer data traffic into a third queue, and residential customer
data traffic into the fourth.
Table 66 Classes, application, and recommended 802.1p value
Traffic class Application Recommended 802.1p value
Voice • Voice 110

• Video telephony (111)
• + network control)
Video • Broadcast video 100

• Video-on-demand
Controlled load HSI for business access 011
Best effort HSI for residential access 000
Classification is based on layer 2/layer 3/layer 4 parameters

Note — The classification can already be done by the CPE
(priority tagged frames or tagged frames), but the ISAM can be
configured to overrule the marking done by the CPE.
When the outcome of classification is “discard”, we are dealing with Traffic filtering
by means of Access Control Lists (ACLs). In this way, it is possible to filter out certain
packet flows based on multi-field classification at layer 3/4 or layer 2.
Control plane and management plane traffic is separately classified based on
protocol type.
20.2.3 Marking
Marking is defining the value of:
• layer 2: p-bits - part of the VLAN-tag
• layer 3: DSCP - part of the IP packet header

NT
Figure 282 QoS: marking

.1p
111
110
101
100
011
010
001
000
p-bit marking classification
In upstream direction, there are four possibilities:

• Trusted Subscriber Interface:
• No re-marking of DSCP or p-bit; QoS markings received by the user are accepted as
they are. This possibility is useful in case of trusted subscribers (for example, in a
business context).
• DSCP or p-bit contract enforcement/re-marking. In this case, QoS markings received
from the subscriber are taken into account, but they are subject to a contract that
specifies what DSCP or p-bit markings are allowed and what QoS markings need to
be re-marked. In essence, this functionality provides support for correct marking in
case of multi-QoS Service Access Points (SAPs).
• Non-trusted Subscriber Interface:
• Default DSCP or p-bit marking per subscriber interface. In this case, all the packets
on the interface will be re-marked to the configured value.
• DSCP or p-bit marking per QoS subflow using layer 2/layer 3/layer 4 filters (based on
multi-field classification into QoS subflows).
In addition to the above policies it is also possible to align the p-bits, i.e. p-bits are
derived from the DSCP codepoint, or IPv6 Traffic Class field. The upstream mapping
of DSCP codepoint to p-bit value can be achieved in two ways:
• Using a system-wide p-bit alignment table, or
• Associating a p-bit alignment profile with a subscriber
The second option is only available for GPON and XGS-PON / TWDM-PON
subscribers, but has the advantage that different mappings can be used for different
groups of subscribers. This is useful, for example, if the ISAM is used in a wholesale
environment where different mappings are needed for different service providers.

NT
For stacked VLANs, there are some additional points to note related to p-bit marking
• In case of S+C VLAN cross-connect or S+C VLAN RB, following four options can
be configured separately for S+C cross-connect and S+C iBridge and for
upstream and downstream direction.
• In upstream direction:
* both S and C-VLAN p-bits are set to the same value.
* For tagged traffic C VLAN p-bit is left untouched and only S VLAN p-bit is marked.
For untagged traffic both S and V VLAN will be marked with same value.
• In downstream direction:
* S-VLAN p-bit is used as input for determining the downstream p-bit and related
scheduling.
* C-VLAN p-bit is used as input for determining the downstream p-bit and related
scheduling.
• In case of S-VLAN CC tunnel or S-VLAN RB tunnel, the C-VLAN p-bit is never
modified. The S-VLAN p-bit is set according to the preceding explanation. The
default behavior for tagged frames is to copy the C-VLAN p-bit, if no other marking
is specified.
P-bit marking for the S-VLAN CC tunnel can optionally be modified to provide
backward compatibility with the so-called "wildcard flow" option offered by the
7342 FTTU platform. If this mode is enabled, the p-bit marking rule assigned to
the S-VLAN tunnel takes as input the received p-bit, and the resulting p-bit is set
on both C-VLAN and S-VLAN.
Some limitations apply to tunnel VLANs for GPON and XGS-PON / TWDM-PON
subscribers:
• For S-VLAN tunnel, the S-VLAN p-bit is set to the VLAN port default p-bit when it
is enabled (that is, VLAN port marking policy = 'regenerated p-bit'). When the
VLAN port default p-bit is not enabled, then the p-bit is copied from the C-VLAN
p-bit (tagged frames) or is set to the bridge port default p-bit (untagged frames).
Note that other methods of marking the S-VLAN p-bit are not supported for GPON
and XGS-PON / TWDM-PON S-VLAN (for example, deriving the p-bit from the
DSCP codepoint).
• For S-VLAN RB tunnel, the p-bit contract enforcement/re-marking is not
supported on most ONT types.
The p-bit marking of protocol frames is handled in a different way to data plane traffic.
The handling differs according to the protocol.
Handling of protocol frames for non-GPON and XGS-PON / TWDM-PON
subscribers:
• IGMP frames sent by the ISAM are always marked with highest priority, that is,
p-bits=7.
• DHCP frames:
• When traffic is received with p-bits marked at user side, the marking is left
unchanged.
• When unmarked traffic is received, the default p-bit marking for the given VLAN is
applied.

NT
• PPP control frames (for example, PADI/PADO) are marked with fixed p-bits=7.
The CDE option exists to configure in the same way as done for DHCP:
• When traffic is received with p-bits marked at user side, the marking is left
unchanged.
• When unmarked traffic is received, the default p-bit marking for the given VLAN is
applied.
• ARP frames are tagged always with highest priority (p-bit=7)
Handling of protocol frames for GPON and XGS-PON / TWDM-PON subscribers:
The VLAN port, on which a protocol frame is forwarded, may not have p-bit 7
configured. Some additional accommodation must be made to ensure that the
protocol frames are correctly forwarded.
• For IGMP frames generated by the LT board, the p-bit used is the highest p-bit
configured for the VLAN. This is true for both upstream and downstream packets.
• For ARP and DHCP, the p-bit marking follows the same rules as used for the data
plane traffic.
• PPP control frames are marked with fixed p-bit=7. There is also a CDE option to
configure in the same way as done for DHCP. The p-bit marking follows the same
rules as used for the data plane traffic.
20.2.4 Policing
Subscribers are subject to certain traffic contracts that specify how much traffic they
can send towards the network. Policers are installed to enforce these contracts.
A policer may apply to an entire subscriber interface, a VLAN or to QoS subflows
within the subscriber interface. In this context, a QoS subflow (or subclass) is defined
as the aggregate of packets flowing through the interface that are bound by a
subcontract and require a specific common treatment.
The 10GE Ethernet LT supports QoS subflows across multiple VLANs and/or
interfaces of the same LT allowing, for instance, to police multiple VLANs as a single
aggregate (for example business services implementing path redundancy using two
VLANs located on the same or different physical ports and operating in
active/standby mode).
Two types of policer are supported:
• single token bucket policer
• two-rate three-color policer (supported only on GE and 10GE Ethernet LT boards,
GPON and XGS-PON / TWDM-PON LT boards)
The characteristics of these two types are explained in “Policer profile”.

NT
Figure 283 QoS: policing

.1p
P
111
110
P
101
100
P
011
010
001
P
000
p-bit marking classification
Figure 284 illustrates the policing feature implementation for a single token bucket
policer.
Figure 284 Policing implementation framework
QoS Session Profile
QoS Policer QoS Policer QoS Policer QoS Policy

Profile UP Profile DOWN Profile DOWN List DOWN
L2 filter
CIR L3 filter
CBS Policy-action=
Policer-Profile
Per-SAP policing
Subflow policing
L2 filters L3+ filters

DST MAC address + prefix length DST IP address + prefix length
SRC MAC address + prefix length SRC IP address + prefix length
Ethertype Min/max DST port ID
P-Bit Min/max SRC port ID
User-side VLAN ID Protocol
CFI DSCP value
20.2.5 Mapping and queueing

Mapping to queues is the action of assigning a frame to the appropriate queue based
on the p-bit determined during classification (see above). Queue sizes and
scheduling mechanisms can then be tuned to fit optimally to the traffic class at hand.
Traffic is classified into four or eight traffic classes. At any congestion point in the
system, ISAM supports either four or eight queues to distinguish four or eight
different delay precedences.

NT
Figure 285 shows the different QoS queues for the standard QoS model, employing
four traffic classes and four queues. The configurable mapping of p-bits to traffic
class is system-wide. The mapping of traffic class to queue is non-configurable on
the LT boards and on the FD 100Gbps NT, but is configurable on the FD 320Gbps
NT and the FX NT.
Figure 285 QoS queues for standard model
ISAM Traffic
.1p
queues Classes
TC7 111
Voice TC6 110
TC5 101
Video TC4 100

TC3 011
CL TC2 010
TC1 001
BE TC0 000
DSCP to P-bits
Traffic Classes
Classification
p-bit marking
Mapping of
Mapping to
Mapping to
queues
The eight traffic classes are mapped either to four queues or to eight queues. The
selection of which mapping to use is hardware dependent, depending on how many
hardware queues are supported by a specific LT board type. Again this mapping is
non-configurable on the LT boards and on the FD 100Gbps NT, but is configurable
on the FD 320Gbps NT and the FX NT. The non-configurable mappings (used on the
LT boards and the FD 100Gbps NT) are as shown in Table 67. Details of the default
mappings used on the FD 320Gbps NT and the FX NT can be found in Table 75 and
Table 76.
Table 67 Mapping of Traffic Classes into Queues
Traffic Class 4-Queue Mapping 8-Queue Mapping
7 3 7
6 3 6
5 2 5
4 2 4
3 1 3
2 1 2
(1 of 2)

NT
Traffic Class 4-Queue Mapping 8-Queue Mapping

1 0 1
0 0 0
(2 of 2)
For UNI ports on a GE Ethernet LT board, it is advised to align the p-bit to traffic class
mapping per forwarder, for use in the downstream direction, to the system-wide
mapping. This alignment must be done explicitly because the mapping per forwarder
is not explicitly defaulted to the system-wide mapping when not programmed. This
explicit alignment is not needed when the system-wide mapping is kept identical to
the default configuration. Refer to “QoS on a GE Ethernet LT board” for further
details.
The GPON, XGS-PON / TWDM-PON and 10G Ethernet LT boards also use a
configurable per forwarder p-bit to traffic class mapping. However, for these boards,
the per forwarder mapping is required, since the system-wide mapping is not used.
It is also optionally possible to define a mapping of p-bits to color marking. There are
two types of color marking available:
• Policer color marking (green, yellow, or red)): based on received p-bit value,
applicable to the GE Ethernet LT board
• Per forwarder color marking (green, yellow, red): based on re-marked p-bit value,
applicable to the GPON, XGS-PON / TWDM-PON and 10GE Ethernet LT boards.
An option exists to mark the color based on the DEI bit in the packet, rather than
the p-bits.
The NT card provides a similar behavior, that is, the ability to map a p-bit value to
a color on a per-forwarder basis with the option to use the DEI in place of the p-bit
for that purpose.
• System wide Drop Precedence (DP) color marking (either green or yellow), based
on re-marked p-bit value, applicable to other LT board types. The GE Ethernet LT
board also supports the option to use DEI in place of the p-bit value to mark the
color.
The color marking is used as input to color-aware BAC. See “Queue configuration
and queue profile” for description of color-aware BAC. The policer color marking is
used as input to color-aware policing.
Note — (The output of the policing will also be used as input to

color-aware BAC.)

NT
In the upstream direction, only a GE Ethernet LT board supports color-aware BAC.

Both the GE Ethernet LT board, the GPON LT and XGS-PON / TWDM-PON LT
support color-aware policing.
Note 1 — The GPON and XGS-PON / TWDM-PON LT board
has an MDU option to police at the MDU rather than at the LT
board, in which case only single token bucket policing is
supported.
Note 2 — The 10GE Ethernet LT supports color-aware BAC in
both up- and downstream directions.
20.2.6 Scheduling and shaping
20.2.6.1 Standard Scheduling Model

Figure 286 QoS: scheduling
ISAM Traffic
.1p
queues Classes
TC7 111
Voice TC6 110
TC5 101
GE/FE WRR
Video TC4 100
WFQ
TC3 011
CL TC2 010
WRR
WFQ TC1 001
BE TC0 000
DSCP to P-bits
Traffic Classes
Classification
p-bit marking
Mapping of
Scheduling
Mapping to
Mapping to
queues
The standard scheduling model is presented in Figure 287.

NT
Figure 287 Reference scheduling hierarchy for standard model

Voice
Video SP
CL
WFQ
BE
The priority scheduling is as follows:

1 Voice traffic is scheduled first (strict priority)
2 Video traffic is scheduled next (strict priority)
3 CL and BE packets compete for bandwidth in a fair manner (Weighted Fair
Queuing or Deficit Round Robin). The bandwidth ratio is determined by the
weight of CL respectively BE.
Scheduling is work-conserving, that is, lower QoS classes can occupy bandwidth
that is not actually consumed by higher QoS classes.
This model implies that both voice and video traffic are very well contained and only
trusted sources are allowed to use the high-priority traffic classes.
20.2.6.2 Flexible Scheduling Model

In the flexible scheduling model, each queue can be provisioned with a priority and
a weight. The scheduler uses these settings as follows:
1 Queues with a higher priority are scheduled ahead of queues with a lower priority.
2 Queues with the same priority are scheduled according to their relative weights.
The flexible scheduling model is applicable to GPON, XGS-PON / TWDM-PON,

10GE Ethernet LT and in future will be applied to other LT boards using eight queues.
The FD 320Gbps NT and the FX NT also support the flexible scheduling model; see
“Egress scheduler and rate limiter” for details.
20.2.6.3 PON Scheduling and Shaping

Since the GPON / XGS-PON interface (or Channel Pair of a TWDM-PON interface)
is shared by up to 128 ONTs, the LT board manages the transmission upstream over
the PON, including both scheduling and shaping functions. The reader is referred to
section “QoS on the GPON and XGS-PON / TWDM-PON LT boards and the ONTs”,
which describes the QoS of the GPON and XGS-PON / TWDM-PON LT board and
ONT in more detail.

NT
20.2.6.4 Shaping on network ports

ISAM supports port-level shaping of traffic on the network ports.
20.2.7 Connection Admission Control

For GPON and XGS-PON / TWDM-PON, PON level CAC is supported. Upstream,
each T-CONT can be created with a guaranteed bandwidth (either CIR or AIR). ISAM
executes a CAC to ensure that the total guaranteed bandwidth is not exceeding the
physical bandwidth of the PON.
20.2.8 MPLS
VPLS/EPIPE L2 VPN services allow to pass Ethernet frames from a user in a
transparent manner over an MPLS network using pseudo-wires (PWs). The LSRs in
the MPLS network use the EXP bits of the outer label to define the QoS handling.
Therefore the ISAM offers the possibility to configure the setting of these EXP bits.
Two models are supported:
• Fixed EXP value per service provider
• EXP value derived from the forwarding class
Note — The EXP bits of the outer label (transport) and the inner
label (service) are set identical. In case the MPLS packets are
sent tagged, the p-bit of the added DLC header will be set equal
to the EXP value.
Figure 288 PW data packet
DLH OuterLabel Inner Label

+ + + DMAC SMAC [VLAN] [p-bit] Payload
p-bit EXP EXP
20.2.9 Per Line dot1p troubleshooting counters

Some operators offer multiple services differentiated through dot1p settings. These
counters allow operators to monitor and troubleshoot services per subscriber line.
These 64 bit counters can be configured per VLAN port for individual p-bit or for a
consecutive range of dot1p in upstream and downstream direction.
Upstream dot1p byte counter: Total upstream user traffic, successfully forwarded to
the NT, in number of bytes, counted after policing.

NT
Downstream dot1p byte counter: Total downstream user traffic, successfully

forwarded to the bridge port/DSL line, in number of bytes, counted after the policing
and queuing.
Up to eight counter pairs can be configured per subscriber line.
20.3 Downstream QoS

This section deals with traffic received from the network link and transmitted on the
subscriber link or locally terminated on the ISAM.
Downstream traffic is subject to similar QoS actions as upstream traffic. This section
will focus on the differences between downstream and upstream QoS handling.
20.3.1 Classification
Same capabilities as for upstream QoS handling (see “Classification”) with the
following addition for MPLS PW packets:
For packets entering a VPLS/EPIPE via a PW the classification can be based on the
EXP value of the inner service label or the p-bit of the encapsulated Ethernet frame.
20.3.2 Marking
In the downstream direction, frames usually arrive in the ISAM with DSCP or p-bits
properly marked by service-aware edge devices (such as BRAS, edge router,
application gateway, and so on). If this is not practical for some reason, the p-bits can
be aligned to the DSCP found in the packet IP header.
For GPON and XGS-PON / TWDM-PON subscribers, if a priority contract profile is
used to map the p-bits in the upstream direction, then the inverse mapping is applied
in the downstream direction. For example, if p-bit 1 is mapped to p-bit 2 upstream,
then p-bit 2 is mapped to p-bit 1 downstream.
For GPON and XGS-PON / TWDM-PON subscribers, there is also a CDE option
that, when enabled, will result in downstream p-bit being unchanged, so that the
inverse mapping will not be applied.
Further, multi-field based marking is supported in downstream; SAP-based marking
is only supported in upstream.
Same capabilities for marking of protocol frames as for upstream QoS handling
(see “Marking”) with the following addition for MPLS PW packets:
When a PW is defined of type ether, then a VLAN and p-bits need to be added. These
p-bits are then derived from the forwarding class defined by the classification logic.

NT
20.3.3 Policing
No traffic engineering will be done at ingress on the network interfaces. The idea
here is that ingress policing and ACLs at the service provider level have already been
applied in a (access provider-owned) box deeper in the network.
However, after the forwarding decision egress policing may apply. Subscribers are
subject to certain traffic contracts that specify how much traffic they can receive on
their connection. Policers are installed to enforce these contracts. A policer may
apply to an entire subscriber interface or to a QoS subflow within the subscriber
interface.
As for upstream, it is possible to configure either single token bucket policers or
two-rate three-color policers.
20.3.4 Mapping and queuing

In the downstream direction, separate QoS queues are provided per DSL line,
Ethernet line or per GPON and XGS-PON / TWDM-PON UNI. Frames are mapped
to the appropriate queue based on the p-bit determined during classification.
Optionally, it is possible (as for the upstream case) to define a mapping of p-bits to
color marking. There are three types of color marking available:
• Policer color marking (green, yellow, or red), based on received p-bit value,
applicable to the GE Ethernet LT board.
• Per forwarder color marking (green, yellow, red), based on re-marked p-bit value,
applicable to the GPON, XGS-PON / TWDM-PON and 10GE Ethernet LT boards.
There is also an option to mark the color based on the DEI bit in the packet, rather
than the p-bits.
As for the upstream direction, the NT card provides a similar behavior, that is, the
ability to map a p-bit value to a color on a per-forwarder basis with the option to
use the DEI in place of the p-bit for that purpose.
• Syetem wide Drop Precedence (DP) color marking (either green or yellow), based
on re-marked p-bit value, applicable to other LT board types.
For the GE Ethernet LT, there is also an option to mark the color based on the DEI
bit in the packet, rather than the p-bits
The use of the color marking is similar to the upstream case.

For GPON as well as well as for XGS-PON / TWDM-PON ports, downstream queues
can be configured per UNI or per ONT.
Buffer Acceptance Control (BAC) can be done by means of Tail Drop or Random
Early Detect (RED).). The Tail Drop or RED can optionally be color-aware.

NT
20.3.5 Scheduling and Shaping

In the downstream direction, for the DSL lines, there are the same scheduling
capabilities as in upstream for the Standard Model (see “Scheduling and shaping”).
The scope of shaping is different though. In the downstream direction shaping
applies to the per-subscriber queues.
A GE Ethernet LT board supports the following scheduling and shaping capabilities:
• Scheduling of queues at the port level. The scheduling can be strict priority or
WFQ and is configurable per queue (applies to both UNI, HC-UNI and NNI ports)
• Scheduling of ports at the board level with configurable port weights (applies to
UNI ports only)
• Shaping at both the queue level and the port level (applies to both UNI, HC-UNI
and NNI ports)
A 10GE Ethernet LT board supports the following scheduling and shaping

capabilities:
• Scheduling of queues at the port level. The scheduling can be strict priority or
WFQ and is configurable per queue.
• Shaping at both the queue and the port level.
Additionally, the GPON and XGS-PON / TWDM-PON LT board provides hierarchical
scheduling and shaping. The reader is referred to section “QoS on the GPON and
XGS-PON / TWDM-PON LT boards and the ONTs”, which describes the QoS of the
GPON and XGS-PON / TWDM-PON LT board and ONT in more detail.
20.3.6 Connection Admission Control

The ISAM allows associating bandwidth parameters to known multicast video
streams. Per subscriber line, a maximum bandwidth (in kb/s) can be configured for
(downstream) multicast. In addition, a portion of the link bandwidth can be reserved
for voice and data. Based on the bandwidth available for multicast, the ISAM
executes a CAC for known multicast sessions(*).
For GPON and XGS-PON / TWDM-PON LT, PON level CAC is also supported.
Downstream, a maximum multicast bandwidth is configurable on the PON. ISAM
executes a CAC when a multicast stream is joined to ensure that the maximum
bandwidth is not exceeded.
For GPON and XGS-PON / TWDM-PON LT there is also a CAC check for
downstream Committed Information Rate on queues. This CAC is enabled when
auto-scheduling is enabled. (See “QoS on the GPON and XGS-PON / TWDM-PON
LT boards and the ONTs” for a description of auto-scheduling.) The CAC involves
checking that the sum of CIRs of all queues on the PON is less than or equal to (total
bandwidth on the PON minus maximum multicast bandwidth).

NT
ISAM also supports CAC for multicast on the uplink.
Note — (*) Video on Demand (VoD) traffic is not taken into

account.
20.4 Hardware mapping of QoS functions

This section provides hardware mapping of QoS functions on the NT boards, and
QoS functions on the LT boards.
20.4.1 QoS on the NT boards

The QoS functions of the NT are fully implemented at the switch port/service level.
In the ISAM, per-flow or per-session QoS is handled on the LT boards, for example,
QoS at the user port bottleneck and rate limitation of user sessions.
The QoS flow of a packet in IHub is shown in Figure 289.
Figure 289 QoS flow in IHub
Fixed egress
Ingress
port queue
QoS policy
policy
Service lookup Apply per Map flow Buffer

Map packet Switch to Port egress
at packet service egress class to acceptance
to flow class egress port rate limiter
reception rate limit queue & scheduling
The following QoS features are supported in the IHub switch hardware:
• Mapping packets to a flow class based on DSCP, PREC, p-bits/DEI or LSP EXP
(MPLS)
• Per service egress or ingress rate limitation
• Mapping of flow classes to egress queues
• Mapping of flow classes to LSP EXP value (MPLS)
• Buffer acceptance and scheduling at egress port side
• Per-port egress rate limitation
Note — The IHub does not generate pause frames, neither

downstream nor upstream, but the switch correctly handles
pause frames coming from the network.

NT
The IHub does not support the following QoS features:

• DSCP-to-p-bit alignment
• Uplink CAC
On top of the above, the operator will be able to create:
• profiles to specify the QoS parameters of control packets which are
self-generated by the IHUB. The NE manager will be able to specify per service a
QoS profile for self-generated control traffic.
• profiles to specify the QoS parameters of packets ingressing the base router via
network facing ports.
• statistics of packets handled at NT level based upon ingress rate limiting, egress
flow-class assignment and congestion status are maintained.
20.4.2 QoS on the LT boards
20.4.2.1 QoS on layer 3/layer2+ LT boards

Figure 290 shows the logical architecture for QoS on layer 3/layer 2+ LT boards. This
includes all the ISAM LT boards except the layer 2 LT boards.
Figure 290 Logical architecture for QoS on layer 3 LT boards
downstream
Per-DSL line ATM or EFM
Logical Policing, segmentation DSL
GE Input segregation Classification, PVC
aggregate processing per DSL line Queuing, forwarding
Scheduling decision
upstream
Segregation into DSL
GE output buffers
Per-DSLline
Per-DSL li Input ATM or EFM
aggregate (802.1P aggregates) Policing processing
processing reassembly
The input-processing entity stands for all the protocol and forwarding-plane
processing functions. Each frame received from the network interface will have a
handler or meta-data that will contain all the fields needed by subsequent
QoS-related functions.
The next phase is the classification, policing and segregation process within a DSL
link; see Figure 291.
Session rate limitation is achieved by way of policing. Policing can be done at
different subscriber SAPs: bridge port, VLAN port, IP interface, or PPP CC client port.

NT
Both upstream and downstream policing is possible with possibly asymmetrical

values.
The ISAM handles policer conflicts in such way that, for each frame, the policer
installed on the highest layer of the interface hierarchy will be applicable. No frame
will be policed by more than one policer.
Figure 291 Per DSL-port scheduler
BACC voice
Traffic BAC video DSL

Policing SP
SP
class
entity BAC CL
switch
WFQ
WFQ
Rule per SAP: Based on: BAC BE
• PVC • 802.1P
• PPP Modes:
• VLAN ID • Taildrop
• 802.1X • RED
• IP interface
Traffic class mapping on the LT boards is governed by a system wide p-bit-to-queue

mapping table.
Note — The traffic class mapping on the NT boards is
governed by another system wide table.
BAC is either Tail Drop or RED per downstream queue (optionally DP-aware).
A WFQ scheduler ensures fair redistribution of the remaining bandwidth between CL
and BE traffic. Some boards also support shaping per downstream queue.
Figure 292 shows the Ethernet-to-ATM QoS transition.
Figure 292 Ethernet-to-ATM QoS transition
Frame Domain Cell Domain
Segmentation
VOICE buffers VC1
Add correct
1 frame VPI/VCI VC2
VIDEO
SP
SP fields
VC3
CL Rate limitation to
WFQ
WFQ DSL bandwidth
DSL
BE
Ethernet (frame level)
scheduler
Scheduling is done solely on the Ethernet frame level, even for ATM-based DSL
transmission types.

NT
The queuing decision (within a DSL port) is independent from the forwarding
decision. There is no explicit fairness between different PPPoE or IPoE sessions
within a DSL link. Their peak rate is enforced independently by way of policing, and
then they share the same First In First Out (FIFO) per traffic class.
Marking is generally applicable upstream, although with the policy framework, it is
possible to modify downstream p-bit and DSCP values. Packets may arrive from user
ports tagged, untagged, or priority-tagged. At the bridge port and VLAN port level,
the ISAM supports a re-marking table which maps all user-defined P-values to
allowed values. Untagged frames can be marked based on subscriber SAP defaults
(statically configured).
The ISAM allows also DSCP-marking for various subscriber SAPs. DSCP-to-DSCP
re-marking is also possible, just like p-bit re-marking for tagged and priority-tagged
frames. Finally, a global DSCP-to-p-bit alignment table is provided to align
DSCP-marked traffic on selected interfaces to p-bits, as traffic segregation still relies
on p-bits.
PPP-session marking for p-bits is possible based on the QoS session profile
attributes.
20.4.2.2 QoS on the layer2 LT boards

Layer 2 LT boards have a different QoS architecture. Queuing is per PVC, and all the
downstream unicast frames are using the same First In First Out (FIFO) queue. This
queue is scheduled with a priority that is inferred from the upstream p-bits attached
to the bridge port that was created on top of the VC.
Layer 2 LT boards support four priority levels downstream. Upstream there is no
bottleneck, hence no queuing other than AAL5 reassembly is required.
Traffic within a VC can have different priorities:
• unicast traffic priority is inferred from the port default upstream p-bits
• broadcast traffic has the same priority as unicast traffic
• multicast has priority 2 (second highest) if the multicast source is preconfigured in
the multicast source table, otherwise 0 (lowest)
Prioritization within a VC is strict priority. Also, across multiple VCs, fairness is

guaranteed only per datagram-priority and not per VC bandwidth.
Upstream PVCs are mono-QoS (that is, one P code point can be attached to them).
Each PVC will have an attribute that contains the default and unique VLAN ID and
the 802.1-bit value. The default 802.1-bit value can be specified by the operator by
means of the management interface.

NT
The bit used for marking upstream frames is also used for downstream prioritization
of unicast traffic (the priority level equals p-bits/2).
Note — Only fixed p-bit value marking is supported; no DSCP

marking, nor dot1p-alignment.
Traffic segregation into downstream queues is combined with the forwarding

decision: determining the outgoing port and PVC and determining the correct queue
with the appropriate priority is done in a single shot. For normal data traffic, this relies
on the VLAN ID (which is configured by the operator manually) and the MAC DA
(which is learned) and does not rely on the 802.1-bits.
Session rate limitation is achieved by way of policing. Policing can be done per PVC.
20.4.2.3 QoS on the GPON and XGS-PON / TWDM-PON LT

boards and the ONTs
This section describes the QoS aspects of both the GPON and XGS-PON /
TWDM-PON LT boards and the ONTs, noting which functions are performed by the
LT board and which are performed by the ONT. Capabilities specific to the GPON
and XGS-PON / TWDM-PON implementation are highlighted, as well as any
deviations from the DSL capabilities.
In the discussion of the GPON and XGS-PON / TWDM-PON QoS, it is important to
understand the high-level implementation of the GPON and XGS-PON /
TWDM-PON QoS management model. In accordance with TR-156 and the ITU-T
G.984 series, the NGLT and ONT should be considered as one “virtual” entity from
a management point of view. See Figure 293.

NT
Figure 293 GPON and XGS-PON / TWDM-PON LT and ONT combined into a
single management entity
xDSL
NE xDSL
LT
Eth
Network NT Eth
LT
DSL
GPON ONT ETH
LT ONU CES
POTS
Classification and marking

Upstream classification and marking for GPON and XGS-PON / TWDM-PON
subscribers is performed mostly by the ONT, with the exception of some types of
stacked VLANs, where the OLT is involved for the p-bit marking of the outer VLAN.
Marking is only applied to p-bits (not DSCP). A number of options are available.
• Packets can be marked based on subscriber SAP defaults, or protocol default
(IPoE or PPPoE).
• If a packet is already tagged, the p-bits can be re-marked using one of 32 priority
contract profiles that map the received p-bit to a new value. See “Priority contract
profile” for details.
• Untagged IPoE packets can be marked at the ONT using the global DSCP to p-bit
alignment table, when the DSCP is trusted. This is supported for IPv4 packets
and, for the majority of ONT types, also IPv6 packets. As mentioned in “Marking”,
the DSCP to p-bit alignment can be derived either from a system level table or by
associating one of a number of profiles to the UNI on the ONT.

NT
Packets can also be marked at the GPON and XGS-PON / TWDM-PON line card as
outlined here:
• The GPON and XGS-PON / TWDM-PON linecard can be configured to perform
upstream DSCP to p-bit alignment, for untagged and tagged IPv4 and IPv6 traffic.
Both encapsulation in PPPoE as well as in plain Ethernet are supported. The
DSCP to p-bit alignment on the GPON and XGS-PON / TWDM-PON linecard
must be based on the system level DSCP to p-bit alignment table
• Marking of p-bits as a policy action is supported at the GPON and XGS-PON /
TWDM-PON line card (i.e. a p-bit value can be set as a filter action). However,
marking of DSCP as a policy action is not supported. Also note the that:
• Since the subflow p-bit marking is applied in the ISAM, upstream QoS actions on the
ONT and on the PON will not use the subflow marking.
• The subflow p-bit marking is applied as follows to the different forwarder types:
* S+C forwarder: applied to both S tag and C tag
* S forwarder: applied only to S tag
* C forwarder: applied to C tag
Policing
As for DSL subscribers, policing is possible for GPON and XGS-PON / TWDM-PON
subscribers, both in the upstream and downstream directions. Downstream policing
is always performed by the ISAM; upstream policing can also be performed by the
ISAM, except VLAN port policing for MDU subscribers, which is performed by the
MDU itself. Note that for GPON and XGS-PON / TWDM-PON, a policer can be
attached to a VLAN port or to a bridge port. As for DSL subscribers, for GPON and
XGS-PON / TWDM-PON a policer can also be attached to a filter.
Upstream scheduling and shaping
Inherent to the GPON and XGS-PON / TWDM-PON network architecture, upstream
transmission introduces an additional challenge as multiple ONTs share a common
medium: transmissions could collide if they were transmitted at random times. For
this, a TDMA-based Dynamic Bandwidth Allocation (DBA) mechanism has been
implemented at the GPON and XGS-PON / TWDM-PON control plane as part of the
of the Transmission Convergence (TC) layer. This layer thus manages the upstream
bandwidth efficiency, and provides support for differentiated services. Therefore, the
actual mapping of the traffic into queues and possible scheduling of the queues
within a certain traffic subflow should be understood with reference to the underlying
TC layer parameters. Two key entities used in the TC layer are the Traffic Container
(T-CONT) and the port ID of the GPON Encapsulation Method, or GEM port id, as it
is known for GPON, respectively XGEM port is as it is known for XGS-PON /
TWDM-PON.
The T-CONT can be thought of as a bandwidth pipe. At the egress of the UNI
interfaces towards the PON link, rate shaping is activated on the T-CONT level and
triggered by the DBA mechanism. The DBA will issue grants to ensure that the rate
allocated to a T-CONT will not exceed its provisioned traffic contract (reflected by
CIR, AIR and EIR). For example, for a fixed bandwidth T-CONT (Type 1), the rate is
limited to the CIR; for a best effort bandwidth T-CONT (Type 4), the rate is limited to
the EIR. The Nokia GPON and XGS-PON / TWDM-PON solution supports all
T-CONT types, from 1 to 5.

NT
Figure 294 T-CONT bandwidth parameters and DBA mechanism
EIR
Best-Effort Bandwidth
Additional
Bandwidth
Non-Assured Bandwidth DBA
AIR
Assured Bandwidth
Guaranteed CIR
Bandwidth Statically
Fixed Bandwidth reserved
Data sent over the PON is encapsulated in the GEM header. The GEM header
includes the GEM port id which uniquely identifies a traffic flow or group of traffic
flows for a specific UNI. In the ONT, a GEM port is associated with a specific traffic
queue towards the PON.
By default, GEM ports are allocated for each VLAN port, with a separate GEM port
allocated for each traffic class used (defined by the p-bit to traffic class mapping,
see “Ingress QoS profile (p-bit to traffic class mapping)”). There is also an option,
configurable at the UNI level, to share the same GEM ports for all VLAN ports on the
UNI. When this option is used, the p-bit to traffic class mapping used for the VLAN
ports must be ‘non-conflicting’. For example, it is not possible to have p-bit 1 map to
TC1 for one VLAN port and have p-bit 1 map to TC2 for a second VLAN port.
The main features of the upstream scheduling and shaping are as follows.
• Each UNI on a PON is allocated either four or eight queues. (The number is
configurable per ONT.) These queues are located on the ONT. Each queue is
configured with priority and weight parameters. A T-CONT is also associated with
each queue. There is also an option to share the queues between all UNIs on an
ONT.
• An option exists to configure the upstream ONT queues on the VLAN port level,
rather than on a UNI or ONT level. In this case, T-CONTs are also allocated at the
VLAN port level. This has he benefit that bandwidth parameters can be configured
individually for each VLAN port.
• The characteristics of the T-CONT are configured in a bandwidth profile and
include rate parameters CIR, AIR, EIR. Grants are issued by the GPON and
XGS-PON / TWDM-PON LT to the ONTs on the PON, to ensure for each
T-CONT, the committed rate and (on average) the assured rate. Also, for each
T-CONT, the traffic is shaped to the maximum of CIR, AIR and EIR.
• Queues are scheduled using strict priority or WFQ algorithms, within the T-CONT,
according to the configured priorities and weights. It is also possible to configure
a mixture of strict priority and WFQ. The WFQ queues should all be configured
with the same priority. Note that more than one WRR group in a mixed SP+WRR
scheduling mode is not supported. When more than one WRR group is

NT
config-ured in a mixed SP+WRR mode, the OLT will use the configured weights
to support a pure WRR mode. In other words, the configured priorities will be
ignored by the OLT and only the weights will be used.
• The 'bandwidth profile sharing' attribute allows a T-CONT to be shared by multiple
queues within a UNI and also across multiple UNIs within the same ONT.
However, a T-CONT cannot be shared between ONTs.
• When queues are configured at the VLAN port level, bandwidth profile sharing
can be set to 'vlan-port-sharing' which will result in a single T-CONT for each
VLAN port, shared by all queues for the VLAN port.
• When the upstream traffic is forwarded from the LT to the NT, a simple,
non-configurable queuing mechanism is used. Traffic enters a single queue per
uplink and is classified as critical, high or low priority. Critical priority is reserved
for internal LT-to-NT communications and other traffic is classified as high or low
priority based on p-bits. The queue fill level has two thresholds: when the queue
fills to the lower threshold, low priority traffic is dropped; when the queue fills to
the higher threshold, low and high priority traffic is dropped.
• For some ONT types, there is the option to perform shaping of upstream traffic for
individual queues, before the traffic reaches the T-CONT. In this way, when a
T-CONT serves multiple queues, a hierarchical shaping is achieved by shaping at
the queue level and also at the T-CONT level. This option is supported for queues
both at the UNI level and at the VLAN port level. It is configured by associating a
shaper profile to the upstream queue.
Figure 295 illustrates the mapping of traffic to queues and the TC layer parameters,
as well as bandwidth profile sharing.
Figure 295 Upstream traffic mapping to queues and TC layer parameters
Different priorities: SP
BW profile Identical priorities: WFQ BW profile sharing
ENABLED
-> T-CONT
GEM
SP
T-CONT Pbitx
WFQ .
GEM Pbit-to-queue .
mapping .
Pbitz
T-CONT GEM
BW profile sharing
DISABLED
Downstream scheduling and shaping

1) Subscriber-based hierarchical scheduling

NT
The GPON and XGS-PON / TWDM-PON LT board provides a hierarchical

downstream scheduling and shaping as depicted in Figure 296. The main features
are as follows:
• A fixed number of downstream queues can be assigned to each UNI/ONT of a
PON. The fixed number is either 4 or 8 and can be configured independently on
each PON. On NGLT-C/FGLT-A, it is configured per pair of neighboring PONs:
that is, if the operator modifies the parameter on PON-1, the same value is also
configured on PON-2 automatically (and so on for the other pairs: PON-3 and
PON-4, PON-5 and PON-6, and so on). Each queue can be configured by the
operator with a weight and priority, which are used to control the scheduling of the
queues at the UNI/ONT level.
Note — Before changing the number of downstream queues
per UNI/ONT parameter of a PON on NGLT-C/FGLT-A, please
be aware of the following restrictions:
• make sure there is no UNI/ONT already created on the
neighboring PON.
• make sure the neighboring PON is not already protected by
another PON (see “PON Link Protection” in chapter “Failure
protection and redundancy provisions in ISAM”.
• A scheduler node profile is assigned to each UNI on the PON, unless “queue
sharing” is used. Each scheduler can be configured by the operator with a weight,
which is used to control the scheduling of the UNIs at the ONT level. Up to 32
UNIs can be included in the same ONT scheduler.
• A scheduler node profile can be assigned to an ONT. The scheduler can be
configured by the operator with a weight, which is used to control the scheduling
of the ONT at the PON level. The ONT scheduler node is required if “queue
sharing” is used; otherwise, it is optional.
• A shaper profile can be configured at queue level, at UNI level, and at ONT level.
Note that this shaping is applied to unicast traffic only. Multicast traffic is queued
separately, and is therefore shaped separately (see Figure 296).
However, there is a configurable option to include the multicast traffic in the UNI
level shaping. When this option is enabled, as a multicast stream is joined (via
IGMP protocol), then its bandwidth is subtracted from the configured bandwidth
of the shaper on the corresponding UNI. Since the configured multicast bandwidth
is used, note that the actual (dynamic) use of bandwidth by the multicast stream
is not taken into account.
Note — Including the multicast traffic in the UNI level shaping
is not possible when auto-shaping is used.
When shaping is performed at multiple levels (for example, queue level and UNI
level) it is advised to set the rate at the lower level to a lower value than the rate
at the higher level. For example, in the case that queue and UNI level shaping are
configured, the queue rate should be configured to a lower value than the UNI
rate. Not following this rule can lead to unexpected behavior because the
operation of the two shapers is not synchronized.

NT
• The auto-scheduling option allows the weight of the queues to be calculated

automatically, rather than using configured or default values. The weight of a
queue is calculated based on the CIR of the queue. The value is selected so that
the queue will be guaranteed sufficient service to allow its CIR to be honored.
Note that the CIR is a parameter of the shaper profile associated with a queue.
Also, when auto-scheduling is enabled, the weight of the next scheduler level is
calculated automatically. Again, the value is selected to guarantee sufficient
service to allow the CIRs of all queues to be honored. Auto-scheduling option can
be enabled on a per-PON basis. When it is enabled, it is mandatory to configure
CIR for each queue, since the CIRs of the queues are used to derive the weights.
The automatically calculated weights can be displayed by the operator and are
stored separately from configured weights.
Auto-scheduling entails a downstream CAC to ensure that configured CIRs can
be honored. See “Connection Admission Control”
Note — The CIR of a queue can only be guaranteed if either:
• all queues (attached to the same scheduler node) are

scheduled in weighted mode; or
• any queues (attached to the same scheduler node)
scheduled as strict priority are rate limited to their configured
CIR (that is, EIR = CIR).
It is the responsibility of the operator to ensure that the

scheduling is configured correctly when CIRs are used.
• Auto-shaping. This option allows the EIR of a shaper attached to a scheduler
node to be automatically calculated. The option is applicable in two cases:
• when queues are scheduled at the UNI level, the EIR of the UNI is automatically
calculated;
• when queues are scheduled at the ONT level, the EIR of the ONT is automatically
calculated.
The EIR value is calculated based on the configured CIRs/EIRs of the queues on
the UNI/ONT.
EIR of UNI/ONT = max (sum of CIRs of queues, maximum EIR of queues).
The auto-shaping option can be enabled or disabled per shaper profile.
• PON level queues for the following:
• OMCI queue (which is also used for trace and debug packets)
• Multicast streams - a scheduler block consisting of two queues scheduled SP, with
higher priority for configured multicast streams and lower priority for unconfigured
multicast streams
• Incidental multicasts/broadcasts
• VoIP traffic. A forwarder (VLAN) may be configured so that its traffic is sent to the
voice queue. Use of this queue has the advantage that latency is minimized
The OMCI, VoIP, and incidental multicasts/broadcasts queues are scheduled as

strict priority, with OMCI as the highest priority and VoIP as the second highest.
The multicast streams scheduler block is also scheduled as strict priority in
conjunction with a rate limiting to the configured maximum multicast bandwidth.

NT
Figure 296 Downstream scheduling and shaping on the GPON and

XGS-PON / TWDM-PON LT
OMCI
OMCI R SP
Voice
R SP
Voice
Hig h Pr io r ity
R SP
Low Priority R WFQ
Multicast streams R SP
broadcasts and R SP
Bincidental multicasts
TC w
R
Unicast traffic for one TC x

R
UNI distributed to 4 or R
GPON
TC y
8 queues R
INTERFACE
TC z
R
R WFQ
TC w
R
Unicast traffic for one TC x

R
UNI distributed to 4 or R
8 queues TC y
R
TC z
R
UNI level
scheduler
ONT level
scheduler
PON level
scheduler
The GPON and XGS-PON / TWDM-PON LT board supports both tail drop and
color-aware RED buffer admission control. The GPON and XGS-PON / TWDM-PON
ONT only supports tail drop
For many ONT types, the downstream queues on the ONT are not configurable. The
exact implementation varies by ONT type. The number of queues used can be eight
(for example, Freescale ONT), four, or two (for example, Broadcom ONT). Generally,
traffic is assigned to the queues based on p-bit marking, and traffic with higher p-bit
values is scheduled ahead of traffic with lower p-bit values.
Some ONT types support configuration of priority and weight for the downstream
queues. To distinguish these queues from the downstream queues on the ISAM,
they are referred to as “remote queues”. Per UNI, either four or eight remote queues
may be configured with priority and weight. Scheduling is performed in accordance
with the configured priorities and weights.
2) Service-based flat scheduling

NT
In addition to the above model, the FGLT-B and FWLT-A/B boards also offer a
scheduling option called "service-based flat scheduling". The model is shown in
Figure 297.
Figure 297 Service-based flat scheduling
Traffic prioritization
only on p-bit for ALL
customers, not per
Multicast and ONT
Unicast VOD to use
same queue 010G
P1,
Pbit 5
P2,
GPON B-010G
Pbit 3, 6, 7 010G
ALL TRAFFIC
W1
Pbit 2, 4
SP
P3,
WFQ
010G
B-010G
Pbit 0, 1
W2
This model uses service-based scheduling across all subscribers, using a flat
class-based scheduler and aggregated queues associated with the PON port. In
other words, traffic prioritization is not done per ONT, but is done per p-bit for all
customers connected to the same PON port.
The model uses 8 queues per PON port, and all downstream traffic is mapped to the
appropriate queue based on the p-bit (depending on the configuration some queues
can remain unused if desired).
Downstream multicast traffic is not sent using a dedicated queue. Instead, multicast
traffic is treated in the same way as unicast traffic: it is mapped to one of 8 queues
based on the p-bit. This also implies that unicast video and multicast video share the
same queue.
Traffic prioritization is done based on the p-bit for ALL customers, not per ONT. The
QoS behavior is the same for ALL customers, both residential as well as business
customers.
Configuration of priorities and weights is done in a similar way to the
subscriber-based hierarchical scheduler, but limited to a single scheduling level.

NT
In order to accommodate various deployment models (especially wholesale ones),

the latest generation of GPON / XGS-PON / TWDM-PON LTs provides two
scheduling options in case of S+C forwarders:
• Both OLT and ONT are queuing/scheduling the traffic based on C-VLAN QoS
markings.
This mode of operation is usually applied when hierarchical scheduling is
deployed because the traffic is scheduled within the end user context at both OLT
(virtual UNI part of the H-QoS hierarchy) and ONT (physical UNI) levels. Indeed,
the C-VLAN is typically carrying the QoS markings associated with the service
providers and therefore the end user.
• OLT is queuing/scheduling traffic based on the S-VLAN QoS markings while the
ONT does it based on the C-VLAN QoS markings.
This mode of operation is usually applied when flat scheduling is deployed
together with differentiated markings at S- and C-VLAN levels:
• The S-VLAN typically carries QoS characteristics defined by the Access Providers
and to be used on interfaces aggregating traffic of multiple users (PON interface in
this case).
• The C-VLAN carries QoS characteristics defined by the Service Provider and to be
used on interfaces associated with a single user (UNI and therefore ONT).
20.4.2.4 QoS on a GE Ethernet LT board

A GE Ethernet LT board supports UNI, HC-UNI and NNI ports. The NNI port is
typically employed to connect a subtending system (such as another ISAM) or a
business customer. Therefore it is expected that NNI ports will have simplified
upstream QoS requirements, since many QoS functions will have already been
performed. In the case of a GE Ethernet LT board, the QoS capabilities of both UNI
and NNI ports are summarized in Table 68.

NT
Table 68 QoS capabilities of UNI ports and NNI ports on GE Ethernet LT boards
Feature UNI HC-UNI NNI
P-bit-handling P-bit-based classification Y Y Y
P-bit to queue mapping VLAN (1) System System
Port default p-bit (untagged frames) Y Y Y
VLAN-based priority (tagged frames) Y Y Y

P-bit regeneration profile Y Y Y
DEI handling Ingress DEI to internal color mapping N Y Y
Internal color propagation to egress DEI N Y Y
DSCP-handling DSCP-to-p-bit alignment BP, VP BP BP
DSCP-to-DSCP contract table N N N
Subflow L2/L3 filters BP, VP BP, VP(2) BP, VP(2)
Subflow policing and marking BP, VP BP, VP(2) BP, VP(2)
DSCP range support for L3 filters Y Y Y
Policing SAP based policing BP, VP BP, VP(3) BP, VP(3)
trTCM (Two Rate Three Colour Metering) – Colour aware and Y Y Y

blind variants
Queueing WRED (# of colours) 3C 3C 3C
Weighted tail drop (# of colours) 3C 3C 3C
Downstream programmable weights between WFQ queues Y Y Y

Downstream configurable SP/WRR queue scheduler at port level Y Y Y
Downstream programmable weights between ports (scheduling at Y NA NA

board level)
Shaping Port shaping Y Y Y

Queue shaping Y Y Y
Legend:
BP: supported at Bridge Port level
VP: supported at VLAN port level
Notes
(1) VLAN-based p-bit to queue mapping is only supported in the downstream direction. System level mapping is recommended
(2) Upstream only
(3) Downstream limited to VLAN Cross-connect models

NT
The following limitations apply to the NNI and HC-UNI ports:

• downstream L2/L3 filters are not supported
• downstream policers are only supported on VLAN port level for VLAN
cross-connect forwarding models
• L2 filter with MAC address is not supported
Caution — Caution regarding p-bit to traffic class mapping
Usually, it is expected that both system-level and VLAN-level

mappings will be configured identically. There are cases where
a different mapping could be used at the VLAN level. For
example where it is desired to have a 'queue per VLAN' model
(for example, to allow per-VLAN shaping downstream) all p-bits
for a VLAN are mapped to a single traffic class which then is
mapped to a specific queue.
Link Aggregation on a GE Ethernet LT board

The GE Ethernet LT board supports link aggregation of up to eight ports per link
aggregation group (LAG). The ports must be:
• of the same type (UNI, HC-UNI or NNI)
• on the same LT board
• all operating at the same link speed.
There are some special considerations related to the QoS for the LAG:
• Downstream queues, queue profiles and scheduler node profiles are all
configured on the LAG port and the configuration is applied identically to each
physical port in the LAG.
• A downstream queue shaper applies across all ports of the LAG, for the queues
of a specific traffic class. In the case of a UNI LAG, the aggregate of the traffic
across all queues is shaped. In the case of an NNI LAG, if the shaper rate is R
and the number of links is N, then each queue is shaped to a rate of R/N.
• A downstream port shaper applies across all ports of the LAG. In the case of a
UNI LAG, the aggregate of the traffic across all ports is shaped. In the case of an
NNI LAG, if the shaper rate is R and the number of active links is N, then each
port is shaped to a rate of R/N.
• A policer associated with an LAG will be applied to traffic for all active links in the
LAG.
• As usual, a session profile is attached to a bridge port or a VLAN port. Since the
bridge port or VLAN port is associated with the entire LAG (not just one physical
port) then the session profile applies to all physical ports in the LAG. This is also
true for the marker profile, policers and filters that belong to the session profile.
• p-bit marking/re-marking configured on the bridge port or a VLAN port of an LAG
is applicable to all physical ports of the LAG.

NT
• CAC checks are made using the aggregate bandwidth of the LAG, not the
bandwidth of the individual physical ports.
• QoS counters apply to the LAG, not to the individual physical ports of the LAG.
20.4.2.5 QoS on a 10GE Ethernet LT board

A 10GE Ethernet LT currently supports two interface types: uplink and downlink (NNI
and UNI). These two modes cannot be combined onto the same board, that is, the
mode "uplink" or "downlink" (UNI and/or NNI) is a mode to be defined at board level
when planning the LT board: all links must be either uplink or downlink.
The "uplink" mode is used to implement VULA operations into the ISAM, that is. the
LT card is used to directly interface with Content Providers' networks for SLA
enforcement purposes, while NNI is used for pre-aggregation purposes and UNI, for
business users and mobile backhaul applications..
QoS capabilities supported by the 10GE Ethernet LT card are summarized in
Table 69 and 70.
Table 69 10GE LT QoS feature list
10GE LT QoS feature list NNI / Uplink

P-bit-handling P-bit-based classification: Y
Pbit/DEI (Traffic Class, Colour) per VLAN
Port default p-bit (untagged frames) Y
VLAN-based priority (tagged frames) Y
P-bit regeneration profile Y
DSCP-handling DSCP-to-p-bit alignment Y
DSCP-to-DSCP contract table N

Subflow L2/L3 filters Y
Subflow policing and marking Y
Policing VLAN based policing Y
Single token bucket Y
trTCM (Two Rate Three Colour Metering) Y

• Color aware and blind variants
• CoS based enhancement variant
• Optional color propagation based on p-bit or DEI
Scheduler Queues 8
Programmable SP/WFQ queue scheduler Y
Queueing WRED (# of colours) 3
Weighted tail drop (# of colours) 3
(1 of 2)

NT
10GE LT QoS feature list NNI / Uplink

Shaping Port shaping Y
Queue shaping Y(1)
VLAN shaping N
(2 of 2)
Notes
(1) Supported on UNI / NNI only
Table 70 VULA feature list per port type
VULA feature list per port type User Backplane
Queues 8 queues per port (egress queuing, user or backplane port) Y Y

Priority and weights programmable per queue Y Y
Flexible allocation of queues in function of the hierarchical N X

scheduling needs
Programmable Tail drop Y Y

Discard Policy
RED Y X
Color aware tail drop (3 colors) Y Y
WRED (3 colors) Y Y
Queue statistics Performance monitoring (15min) of forwarded and Y Y

discarded traffic per queue
Shaping Per Port Y X
Per Queue Y(1) X
Hierarchical N X
Notes
(1) Supported on NNI only
Note — In the table, ‘X’ means that there is no plan to support

the feature because the feature is not relevant for that interface
type and/or there is some hardware restriction
The 10GE Ethernet LT is fully modeling the LAG as a logical interface while
performing Traffic Management operations. In other words, forwarding and QoS
operations (queuing, scheduling, shaping, remarking, policing, …) are all performed
on the LAG logical interface and not on the individual LAG link members.

NT
20.4.2.6 Overview on remarking rules on the 10GE Ethernet

LT
When an operator configures:
• a .1Q VLAN Port (C-VLAN or S-VLAN Port), he is only interested in the outer tag
(in case the traffic would be multi-tagged) and consequently, the outer VLAN tag
is taken as reference for QoS processing.
• a QinQ VLAN Port (S+C VLAN Port), he wants to look at the inner flow and
consequently, the inner VLAN tag is taken as reference for QoS processing.
Note — These two bullets specifying which VLAN needs to be

used for remarking are also valid for any other actions related
to the VLAN port (for example policing, CCL).
The table below shows the different options:

Table 71 Downstream QoS for VULA behaviour
Forwarder Mode VLAN Port Behaviour
Outer tag (Legacy) .1Q .1Q

The received outer tag pbit is taken as reference for a single
remarking rule. The resulting p-bit is applied to the outer tag.
R1
O1 O-F O2
(1 of 2)

NT
Forwarder Mode VLAN Port Behaviour

S+C Outer based .1Q The received outer tag (by definition of the .1Q VLAN port)
single rule p-bit is taken as reference for a single remarking rule. The
(Legacy) resulting p-bit is applied to both egress inner and outer tags.
R1
C1 S+C-F C2 S
Inner based QinQ The received inner tag p-bit is taken as reference for a single
single rule remarking rule. The resulting p-bit is applied to both egress
inner and outer tags. If R1 does not modify the p-bit value,
this mode allows to copy the inner tag p-bit to the outer tag.
R1
C1 S1 S+C-F C2 S2
Dual remark .1Q The received outer tag (by definition of the .1Q VLAN port)
p-bit is taken as reference for a double remarking :
• R1: Remarking to egress inner tag
• R1: Remarking to egress outer tag
This mode can be used to emulate QOS-95, that is, pass

C-VLAN p-bit transparently while marking the S-VLAN p-bit
by using a "transparent" R1 rule.
R1
C1 S+C-F C2 S
R2
QinQ The received inner tag p-bit is taken as reference for a double
remarking :
• R1: Remarking to egress inner tag
• R1: Remarking to egress outer tag
R1
C1 S1 S+C-F C2 S
R2
(2 of 2)

NT
In order to support all these options, the QoS Session Profile described in
section “Session profile” is extended with a new "Ingress Outer Marker" Profile on top
of the existing "QoS Up Marker" Profile.
Figure 298 QoS session profile on the VULA uplink
QoS Policer
Profile Up
QoS Policer
Profiles
QoS Policer
Profile Down CIR, CBS L2 Filter
EIR, EBS
Mode, …
Dest MAC@
QoS Session Profile
Src MAC@
QoS Up VLAN Id
Marker Profile Ethertype
QoS Marker
OR Pbit
Profiles
Ingress Outer
Marker Profile L3 Filter
Pbit
DSCP
Dest IP@
Src IP@
Dest Port Range
Src Port Range
1…16 Protocol Id
QoS Policy
DSCP
List Up
QoS Policy Policy Action
QoS Policy List
Down Discard / Pass
1…4
Set Pbit
Set DSCP
Police
These two marker profiles can be combined as follows:

Table 72 VULA marker profiles
Marker Profiles Resulting actions
Up Ingress Outer
None None Transparently forward the ingress inner and outer tag p-bits
Present Pass inner tag p-bit transparently
Mark outer tag p-bit according to the Ingress Outer Marker Profile
Present None Mark both inner and outer tag p-bits according to the Up Marker Profile
Present Mark inner tag p-bit according to the Up Marker Profile

Mark outer tag p-bit according to the Ingress Outer Marker Profile

NT
Restrictions:
• The only Ingress Outer Marker Profile being currently supported is a p-bit
regeneration profile where all p-bits are remarked to the same value
20.4.2.7 Overview on Policing options on the 10GE Ethernet

LT
Following policers can be used (see also section “Policer profile”
• Single token bucket policer
• Two Rate Three Colour Meter (trTCM)
• Classical trTCM based on RFC 4114 (CIR/CBS, EIR/EBS, colour blind, colour aware,
coupling flag)
• CoS based trTCM (specific to VULA uplink)
This trTCM variant is enhanced to prioritize the traffic subject to the CIR guarantee
in function of the received p-bit:
* CoS based RFC 2698 trTCM (CIR/CBS, PIR/PBS, coupling flag)
* CoS based RFC 4115 trTCM (CIR/CBS, EIR/EBS, coupling flag)
For all trTCM variants, one can specify the actions to be taken in function results:
• Set the internal color
• Set the internal color and remark the p-bit (both S- and C-VLAN in case double
tagged traffic
• Set the internal color and remark the DEI (both S- and C-VLAN in case double
tagged traffic)
• Set the internal color and remark the DEI of the outer tag only.
The policing algorithms of the CoS based trTCM are extended in such a way that the
token bucket sizes (CBS/PBS or CBS/EBS) are virtually split in function of the packet
CoS parameters (that is, p-bit value) so that high priority packet would see the full
bucket size while lower priority ones would only see a smaller bucket size. This
allows to somehow prioritize packets in function of their CoS while using a single
policer, for example packets with low priority will be marked yellow or red sooner than
high priority packets.
The priority based trTCM policer is defined as follows :
• Up to 8 priorities can be defined
• A burst size percentage ("priority threshold") is associated with each priority (for
example 100% for p-bit 7, … 40% for p-bit 0). The same percentage is applied to
both trTCM buckets
• Packets are marked yellow / red whenever the bucket filling level > Burst Size x
the Burst Size percentage associated with that packet
• Token buckets are updated as usual based on in-profile/out-profile result of the
trTCM taking into account the percentage defined above

NT
Figure 299 CoS based trTCM principles
100% 2 100%
A typical application of a priority based trTCM is Service Level Agreement (SLA)

enforcement per subscriber, knowing that a subscriber is usually generating traffic
with multiple priorities. Using this meter, the operator can specify, per subscriber, a
guaranteed minimum rate (CIR) and a peak rate (PIR or EIR) without having to
specify any rate limit per priority : the meter takes care of assigning the available
bandwidth in function of the traffic priority. This combines a simple provisioning
scheme (SLA per subscriber) while remaining QoS aware.
In order to accommodate various deployment models (especially wholesale ones),
the 10GE Ethernet LT provides two scheduling options in case of S+C forwarders,
based on either C-VLAN or S-VLAN QoS markings. This is typically useful for
wholesale scenarios where the C-VLAN markings are typically set by the content
providers while the S-VLAN markings are set by the access provider.

NT
20.4.3 Downstream QoS for VULA operations

Since Content Providers are directly connected to the ISAM, it is now the ISAM
responsibility to enforce fairness between the different Content Providers and their
related subscribers. This is achieved by policing each subscriber's traffic as follows :
• Upstream traffic: Standard process described in section 20.2
• Downstream traffic: A more advanced rate control is performed, allowing to
guarantee a minimum rate for each subscriber even in case of congestion. This is
achieved by applying a trTCM meter to the VLAN assigned to each subscriber
(one C-VLAN or S+C-VLAN per subscriber at the hand-over interface). That
meter behaves as follows:
• Each subscriber is assigned a CIR (guaranteed minimum rate) and a PIR (peak rate).
Traffic below CIR is marked green, traffic above PIR is discarded and the traffic in
between is marked yellow.
• The resulting color is then used throughout the access network to tune the drop
precedence in every queue carrying traffic of multiple subscribers. The color can be
propagated by either updating the p-bit or the DEI so that information can then be
translated into different queue drop precedences
Additionally, the access network being agnostic to the delivered services, the
priorities defined by the service providers and/or their associated Residential
Gateway must be passed transparently between the Service Provider and the end
users. This is achieved by encapsulating the user traffic (C-VLAN) into an extra
VLAN (S-VLAN) so the Access Network Provider can apply its own p-bit marking
rules on the S-VLAN while keeping the C-VLAN untouched. According to this
scheme, traffic prioritization is then based on :
• S-VLAN pbit on all interfaces shared by multiple subscribers (and therefore
multiple service providers)
• C-VLAN p-bit on the interface attached to the subscribers (UNI), that is, queuing
is then performed into the context of that single subscriber, that is, using the p-bit
defined by the Content Provider
All these advanced QoS/VLAN operations are performed by a 10GE Ethernet LT

card operating in "uplink mode" leading to the end-to-end architecture shown in
Figure 300

NT
Figure 300 QoS for VULA operations
S-VLAN Pbit = f (Rx Pbit)

C-VLAN based QoS (Pbit)
trTCM
CPE Remote DSLAM Hub-ISAM
Downlink P2P LT NT Uplink 10GE P2P LT
UNI NNI Bckpl Bckpl R Uplink

RGW CP
R N x GE
N x GE
Or 10G
S-VLAN Pbit = f (Rx Pbit)
Peak Rate Policing
S-VLAN based QoS (Pbit / DEI)
S-VLAN based QoS (Pbit / DEI)
Access QoS F (S-VLAN)

CP QoS f(C-VLAN) CP QoS f(C-VLAN)
Focusing on the downstream directions and assuming internal forwarders based on

S+C VLAN, following QoS operations are performed at the ISAM - Content Provider
interface hosted by the 10GE Ethernet LT card operating in "uplink" mode:
• Characterization of a subscriber flow based on either C-VLAN or S+C VLAN and
p-bit (for higher scalability on the Content Provider interface). Note that when an
S+C VLAN Port is used for QoS purposes, QoS operations will take the C-VLAN
as reference (for example p-bit remarking, policing, filters).An operator only
interested by the outer tag should use a C-VLAN Port
• Traffic remarking where inner and outer tags will be remarked using different
rules, both based on the C-VLAN.
• TrTCM that will define the colour of the packet and propagate that color by
updating the packet DEI (or potentially pbit) of the S-VLAN.
• The S-VLAN Pbit and DEI will then be used by all downstream queues attached
to interfaces carrying traffic associated with multiple subscribers so fairness can
be guaranteed across all subscribers sharing the same interface:
• Uplink P2P LT queue towards the NT card (corresponding to the black box behavior
of FELT-B but there is no traffic classification based on S-VLAN CoS, that is, the
actual queuing is based on the internal priorities/colors resulting from the QoS
processing that took the C-VLAN p-bit CoS parameters as input as indicated above)
• NT card queue towards the downlink P2P LT card hosting the NNI
• Downlink P2P LT queue towards the remote DSLAM
• Potentially, if the remote DSLAM is hosting an NT card (for example 7330 ISAM FD
or 7360 ISAM FX-4/8), the NT card queue towards the remote DSL LT card
• The traffic is finally queued within the context of a single UNI using the C-VLAN
pbit, that is, the p-bit that will be carried over the UNI (Remote DSLAM UNI and
CPE).

NT
Upstream QoS processing reuses the generic upstream QoS features (see
section 20.2):
• Characterization of a subscriber flow based on the C-VLAN and p-bit
• Traffic remarking where inner and outer tags will be remarked using different
rules, both based on the C-VLAN (most often the C-VLAN p-bit is passed
transparently into the S-VLAN)
• Peak policing at the remote DSLAM UNI
• P-bit based queuing all the way upstream
Summarizing the downstream QoS features specific for an ISAM operating as a
VULA node:
• QoS handling based on S+C VLAN Port
• Dedicated remarking rules for S and C-VLAN
• TrTCM with color propagation at S-VLAN level (default is to propagate at both C
and S-VLAN levels), most typically using DEI (more flexibility)
20.5 Configuration of QoS

The ISAM uses QoS profiles to perform ingress and egress traffic policing, class
queuing, and scheduling. QoS profiles can be created and then assigned to QoS
resources and SAPs.
QoS profiles supported on the LTs (IACM part):
• CAC profile
• Ingress QoS profile (p-bit to traffic class mapping)
• Queue profile (bac)
• Scheduler node profile
• Shaper profile
• Bandwidth profile (used for GPON and XGS-PON / TWDM-PON T-CONT)
• Priority contract profile (p-bit regeneration profile)
• Session profile
• Marker profile
• Policer profile
• Policy profile
• Layer 2 filter
• Layer 3 filter
• Policy action profile
• DSCP to p-bit alignment profile
QoS profiles supported on the NTs (IHub part):

• Service Ingress access profile
• Service Ingress network profile

NT
• Service Egress network profile

• Base router network policy
20.5.1 IACM part
20.5.1.1 CAC profile

A CAC profile is primarily used to perform multicast video admission control for an
individual xDSL port in the downstream direction. The maximum downstream
bandwidth to be occupied by video can be further constrained by setting the
maximum multicast bandwidth parameter in the CAC profile.
A CAC profile contains three configurable rate parameters:
• the minimum reserved bandwidth for voice
• the maximum allowed bandwidth for multicast video
• the minimum reserved bandwidth for data traffic
The ISAM derives the line rate from the physical interfaces and calculates an
estimate of the available Ethernet bandwidth using configurable overhead factors.
The line rate taken into account may be the guaranteed sync rate or the actual line
rate in case of xDSL, based on a global configuration. In the profile, a part of the
available downstream bandwidth can be reserved for voice and data applications.
The remaining part will be kept by the system as the available bandwidth for multicast
video. Only pre-configured multicast streams are considered for CAC. Unicast video
is ignored by the CAC function, even if it concerns premium content or generic
internet streaming video.
A CAC profile can be associated with a subscriber interface, using the relevant QoS
configuration command, see the 7360 /7302 ISAM | 7330 ISAM FTTN CLI
Commands and the 7360 /7302 ISAM | 7330 ISAM FTTN Operations and
Maintenance using CLI documents for more information.
20.5.1.2 Ingress QoS profile (p-bit to traffic class mapping)

The ingress QoS profile is used to map traffic to the correct traffic class. A profile is
associated with each forwarder (VLAN) or per VLAN port. The configurable profile
specifies, for each p-bit value, the traffic class to which it is mapped. Up to eight traffic
classes can be specified.
The ingress QoS profile is currently supported on GE Ethernet LT board (UNI ports
only, downstream direction), 10GE Ethernet LT board, GPON LT boards and GPON
ONT, XGS-PON / TWDM-PON LT board and XGS-PON / TWDM-PON ONT.

NT
For other LT board types, and UNI in the upstream direction, and NNI and HC-UNI
ports of the GE Ethernet LT boards, there is a single configurable system-wide
mapping table that maps p-bits to traffic class.
For the GE Ethernet LT board:
• NNI ports use the system-wide mapping table
• UNI ports use the system-wide mapping table if no ingress QoS profile has been
configured.
For the 10GE Ethernet, GPON and XGS-PON / TWDM-PON LT board, the ingress
QoS profile also defines how p-bits are mapped to color. The color marking is used
for color-aware policing and color-aware RED. There is also an option to use the DEI
bit in the packet to mark color, rather than using the p-bits.
20.5.1.3 Queue configuration and queue profile

For the Layer 3 LT boards, in the downstream direction, the queue weight is
configured for the Controlled Load (CL) queue and the Best Effort (BE) queue. The
default weight of the CL queue is 66 and the default weight of the BE queue is 34.
The GE Ethernet LT supports flexible scheduling, that is priority and weight can be
freely configured on all its eight queues per user port.
The 10GE Ethernet LT supports flexible scheduling, i.e. priority and weight can be
freely configured on all 8 queues per interface, being user or backplane interfaces.
For GPON and XGS-PON / TWDM-PON LT boards, since flexible scheduling is
supported, it is possible to configure all queue weights and priorities.
For GPON ONT, some ONT types support configuration of priority and weight for the
downstream queues. To distinguish these queues from the downstream queues on
the LT, they are referred to as “remote queues”. XGS-PON / TWDM-PON ONTs do
not yet support downstream remote queues.
A queue profile is associated with each queue. The queue profile is a BAC profile that
contains admission control information for frames arriving at the buffer from the
services side of the network. There are a number of default BAC profiles which can
be used, but which can not be modified nor deleted.
Two basic BAC types are supported in downstream: RED and tail drop. However,
their color-aware variants are also available on some LT boards:
• Two color tail drop
• Two color RED
• Three color tail drop (GE and 10GE Ethernet LT boards only)
• Three color RED (GE and 10GE Ethernet LT, GPON LT and XGS-PON /
TWDM-PON LT boards only)

NT
A RED queue has three configurable parameters:

• MinThreshold: the average queue filling level for which frame discard will start to
occur (threshold expressed in number of packets)
• MaxThreshold: the average queue filling level for which frame discard will start be
100% (threshold expressed in number of packets)
• DropProbability: the probability of frame discards for average queue filling levels
just below the maximum threshold.
Figure 301 RED configuration parameters

Drop probability
Discard
probability
Minimum Maximum Weighted average

threshold threshold Filling level
Note — The weight, used for calculating average buffer sizes in

RED, is not configurable.
Arriving frames are accepted as long as the average queue filling level remains
below the minimum threshold. Frames received at the moment the minimum
threshold is exceeded will be dropped with a probability as indicated by the RED
curve.
For tail drop queues, only a max queue size has to be configured. Queue size is set
as the number of frames that can be stored in the queue. Arriving frames are queued
as long as the queue is not full. After the queue is full, all incoming frames are
discarded until the queue can transmit a frame over the subscriber line and space in
the queue is made available
In the case of color-aware BAC, a separate curve must be configured for each color.
That means, in the case of color-aware RED, that MinThreshold, MaxThreshold and
DropProbability are configured separately for each color. In the case of color-aware
tail drop, only MaxThreshold needs to be configured for each color. The following two
figures illustrate the three color WRED and the three color tail drop, respectively.

NT
Figure 302 Three color WRED

Drop
probability
100%
Averaged queue
filling level
red red yellow green

min max/ max/ max
yellow green
min min
Figure 303 Three color tail drop

Drop
probability
100%
Actual queue
filling level
red yellow green

max max max
Queue buffers on GPON and XGS-PON / TWDM-PON LT boards form a shared

pool. Therefore, the guaranteed minimum queue size and the maximum queue size
are configurable for both tail drop and color-aware RED queues. In the case of
prolonged congestion on the PON, the shared pool can come close to empty since
many packets will be queued. In this scenario, the BAC policy will be temporarily
modified to ensure that the pool remaining is sufficient to satisfy the guaranteed
minimum of all queues. In this temporary congestion state, all queues operate in a
simple tail drop fashion by using the guaranteed minimum queue size as the drop
threshold. The normal BAC policy is temporarily suspended until there are more
buffers available.

NT
For some GPON and XGS-PON / TWDM-PON ONT types, it is possible to configure
the maximum queue size for the upstream queues on the ONT. A queue profile is
used for that purpose. Due to a hardware limitation in the ONT types that support this
feature, currently all upstream queues on the ONT must use the same maximum
queue size. Therefore, all queues on an ONT should be configured with the same
queue profile.
Note 1 — BAC configuration for upstream queues on LT is
fixed, except for the 10GE Ethernet LT where it can be
provisioned.
Note 2 — L3 LT boards support buffer oversubscription.
20.5.1.4 Shaper profile

ISAM uses shaper profiles to capture shaper configuration parameters. For a DSL
line, a shaper profile contains the following configuration parameters:
• Type: only single-token bucket shapers are currently supported.
• Committed Information Rate (CIR): in 16 kb/s increments up to a maximum of 128
Mb/s.
• Committed Burst Size (CBS): in byte increments up to a maximum of 256Mbyte
(this parameter is not used by shapers on GPON, XGS-PON / TWDM-PON and
10GE LT).
A DSL shaper profile may be associated with a downstream queue. For a GE

Ethernet LT board, a shaper may also be associated with a port (UNI, HC-UNI or
NNI). The 10GE Ethernet LT only supports shaping per port (uplink, NNI, UNI) and
per queue (NNI, UNI).
For GPON and XGS-PON / TWDM-PON subscribers, a shaper profile contains the
following configuration parameters:
• Type: only single-token bucket shapers are currently supported
• Excess Information Rate (EIR): used on the GPON and XGS-PON / TWDM-PON
LT board to rate limit a queue, a UNI level scheduler or ONT level scheduler.
• Committed Information Rate (CIR): When the auto-scheduling option is enabled
on the PON, the shaper profile specifies a CIR value for the downstream queue.
The CIR is used to automatically configure the queue weight. Additionally, when
the auto-shaping option is enabled on a UNI or ONT, the CIR of the associated
queues may be used to calculate the rate limit on a UNI or ONT. See “QoS on the
GPON and XGS-PON / TWDM-PON LT boards and the ONTs” for a description

NT
of auto-scheduling and auto-shaping.

Note — The CIR value is not applicable when both
auto-scheduling and auto-shaping are disabled, although the
CIR value may still be provisioned.
• A GPON and XGS-PON / TWDM-PON shaper profile may be associated with a

downstream queue, UNI level scheduler, or ONT level scheduler. A GPON and
XGS-PON / TWDM-PON shaper may be associated with an upstream queue on
an ONT. Note that shaping in the upstream direction is also configured at the
T-CONT level using the bandwidth profile rather than the shaper profile. Thus
hierarchical shaping is possible in both downstream direction (queue/UNI/ONT)
and upstream direction (queue/T-CONT).
20.5.1.5 Bandwidth profile

ISAM uses bandwidth profiles to capture the upstream scheduling and shaping
requirements of a T-CONT, as described in section “QoS on the GPON and
XGS-PON / TWDM-PON LT boards and the ONTs”. The following parameters can
be configured:
• Committed Information Rate (CIR).
• Assured Information Rate (AIR).
• Excess Information Rate (EIR)
• Delay tolerance.
The T-CONT type is determined by the CIR, AIR and EIR configuration; see
Table 73).
Table 73 Mapping CIR, AIR and EIR to T-CONT type
Delay Assignment Applicable T-CONT types

Sensitive Type
Type 1 Type 2 Type 3 Type 4 Type 5
CIR Yes Provisioned CIR 0 0 0 CIR
AIR No Provisioned AIR = CIR AIR AIR 0 AIR ≥ CIR
EIR No Provisioned EIR = AIR EIR = AIR EIR > AIR EIR EIR ≥ AIR
20.5.1.6 Priority contract profile

A priority contract profile may be associated with a bridge port or a VLAN port. For
non-GPON and non-XGS-PON / TWDM-PON subscribers one of ten profiles can be
selected. Refer to the CLI command guide for details. These ten profiles are not
configurable.

NT
For GPON and XGS-PON / TWDM-PON subscribers, there are 22 additional

configurable profiles available. Each profile consists of the mapping of each p-bit to
a different p-bit (or the same p-bit).
20.5.1.7 Scheduler node profile

The GE and 10GE Ethernet LT, the GPON and XGS-PON / TWDM-PON LT board
use the scheduler node profile. It provides the flexibility needed for flexible,
hierarchical scheduling and shaping. The scheduler node profile does not specify
weight or priority for its associated queues. Instead, the queues themselves have
weight and priority parameters. Also the scheduler node profile can have a variable
number of associated queues (either four or eight). The scheduler node profile
includes the following parameters:
• Weight and priority:
used to schedule at the next level scheduler. For example, if the scheduler node
is at the UNI level, its output will be next scheduled at the board level (GE Ethernet
LT board) or at ONT level (GPON and XGS-PON / TWDM-PON LT board).
• Shaper profile:
used when the output of the scheduler node requires shaping.
20.5.1.8 Session profile

The QoS session profile is the main building block for conveying user traffic,
contractual rights, and treatment of subscriber services through the network element.
This profile is a macro profile that has its own parameter settings, as well as
references to other profiles. See Figure 304
A QoS session profile is always instantiated at a user logical interface or Service
Access Point (SAP). See the CLI Commands for FD 100/320Gbps NT and FX NT
document for the most recent list of supported SAP types.
A QoS session profile is composed of a logical flow type, a marker profile and two
policer profiles for up and downstream policing of the logical interface to which a
certain session profile is attached.
Figure 304 Composition of QoS session profile
QoS Session Profile
Logical Flow QoS Policer QoS Policer QoS Marker QoS Policy QoS Policy
Type Profile Up Profile Down Profile Up List Up List Down

NT
The logical flow type is a mandatory parameter but is ignored from R4.0 onwards,
that is, the logical flow type is always considered null (generic). Hence, the QoS
Session profile can be attached to any interface, provided that the settings inside the
profile can be configured on the target hardware. Unsupported fields/actions are
silently ignored at run-time.
QoS Session profiles are assigned statically, as specified by the operator.
The scope of a QoS Session profile is always a user logical interface or Service
Access Point (SAP). The following are examples of such “logical interface” types
supported:
• PVC: all frames on a PVC
• 802.1X session: all frames on a bridge port that was opened via a 802.1X
authentication
• PVC.VLAN: all frames on a bridge port with the same VLAN ID
• IPoE VLAN CC: all IPoE frames in a VLAN CC interface
• PPPoE iBridge: all PPPoE frames in iBridge interface
• GPON UNI: all frames on a UNI of an ONT
• GPON VLAN port: all frames on a UNI with the same VLAN ID
20.5.1.9 Marker profile

The marker profile is a building block of the QoS session profile. The marker profile
is used to convey upstream marking settings to the Service Access Point (SAP).
The marker profile carries a flag for enabling DSCP to p-bit alignment of the SAP,
based on the global DSCP to p-bit alignment table, or alternatively in case of GPON
and XGS-PON / TWDM-PON subscribers, based on the associated DSCP to p-bit
alignment profile. It further allows specification of the SAP default p-bits, the DSCP,
or the DSCP contract table (depending on the SAP type). The marker profile can also
be used to re-mark the p-bit based on trTCM packet color.
Seven types of marker profiles exist:
• d1p: fixed value imposed for p-bit
• dscp-contract: DSCP code-point translated
• d1p-dscp: fixed value imposed both for p-bit and DSCP code-point
• dscp: fixed value imposed for DSCP code-point
• d1p-dscp-contract: fixed value imposed for p-bit, while DSCP code-point
translated
• d1p-alignment: p-bit value derived from DSCP code-point. This mapping to p-bit
markings applies to the IPv4 DSCP value as well as to the IPv6 Traffic Class field.
A configurable system level mapping is used. In addition, for GPON and
XGS-PON / TWDM-PON subscribers, it is possible to use a DSCP to p-bit

NT
alignment profile, as described in “DSCP to p-bit alignment profile”.

When used for GPON and XGS-PON / TWDM-PON, the alignment can be done
in two different ways:
At the ONT: this functionality is only applicable to untagged IPoE frames. The
IPv4 and IPv6 alignments are configured separately, as explained in the following
notes:
• For IPv4 alignment, a port default VLAN must first be configured, e.g. VLAN1. The
alignment must then be configured in the marker profile associated with the VLAN
port for VLAN1.
• For IPv6 alignment, an IPv6oE protocol default VLAN must first be configured, e.g.
VLAN2. The alignment must then be configured in the marker profile associated with
the VLAN port for VLAN2.
The VLANs used for IPv4 and IPv6 may be the same (VLAN1 equals VLAN2) or
different (VLAN1 does not equal VLAN2).
At the OLT: this functionality applies across all ONTs. The GPON and XGS-PON
/ TWDM-PON ports can be configured to perform upstream DSCP to p-bit
alignment for untagged and tagged IPv4 and IPv6 traffic. Both encapsulation in
PPPoE and in plain Ethernet are supported. The DSCP to p-bit alignment on the
GPON and XGS-PON / TWDM-PON ports must be based on the system level
DSCP to p-bit alignment table.
• d1p-re-mark: mapping of p-bit to another p-bit is to be used in conjunction with the
trTCM. (The profile is attached to the policer as a color-specific action. This allows
re-marking p-bits as a function of the color determined by the policer.) This option
is only supported by the GPON and XGS-PON / TWDM-PON ports.
All types of marker profile are supported in the upstream direction. The marker profile
is not supported in downstream direction.
Only the following types of marker profile are supported for IPv6 packets:
• a fixed value imposed for p-bit
• d1p-alignment
See the CLI Commands for FD 100/320Gbps NT and FX NT and the Operations and
Maintenance Using CLI for FD 100/320Gbps NT and FX NT documents for more
information about marker profiles.
20.5.1.10 Policer profile

The ISAM uses policer profiles to enforce predetermined limits on upstream and
downstream subscriber traffic. Single-token bucket policers are supported where the
action upon the conformance result is either pass or discard. The layer 3 LT boards
support policing, both upstream and downstream.

NT
A single-token bucket policer profile contains following policer parameters can be

set:
• Committed Information Rate (CIR) in 16 kb/s increments up to a maximum of 128
Mb/s for both upstream and downstream policing.
Note — For GPON and XGS-PON / TWDM-PON LT boards,
CIR is in 64 kb/s increments up to 1 Gb/s.
• Committed Burst Size (CBS) up to a maximum of 128 Mbyte. Note that the
maximum is dependent on the LT type:
• L3 LT based on Intel or CATE: 256 KB
• NELT-A: 2 MB
• L3 DSL LT based on CATAN: 64 MB
• NELT-B:
• UNI downstream: 64 MB
• UNI upstream: 128 MB
• NNI upstream/downstream: 128 MB
• GPON and XGS-PON / TWDM-PON LT: 64 MB
• 10GE LT: 64 MB
The GE and 10GE Ethernet LT, the GPON and XGS-PON / TWDM-PON LT board
also support the two-rate Three Color Marker (trTCM). This is a type of policer that
marks each packet with a color - green, yellow, or red.
Note — The GPON and XGS-PON / TWDM-PON LT board has

an MDU option to police at the MDU rather than the LT board.
In this case only single token bucket policing is supported.
The trTCM contains some additional parameters:

• Excess information rate (EIR)
• Excess Burst Size (EBS)
• Color mode: either color-aware or color-blind
• For the GE Ethernet LT board:
• Green action: forward
• Yellow action: forward, discard
• Red action: forward, discard
• For the GPON and XGS-PON / TWDM-PON LT board:
• Green action: forward, or forward and re-mark the green packets. Re-marking can
either re-mark the p-bit or set the DEI based on the color.
• Yellow action: forward, discard, or forward and re-mark the yellow packets
• Red action: forward, discard, or forward and re-mark the red packets
• Coupling flag: enabled or disabled.

NT
• For 10GE Ethernet LT, GPON and XGS-PON / TWDM-PON LT board, per color,
a marker profile of type “dot1p re-mark” can be associated. This allows re-marking
of p-bit as a function of the color output of the policer
• The 10GE Ethernet LT supports the option to remark the outer VLAN only
The trTCM is intended to be used in conjunction with the color-aware BAC types
described in “Queue configuration and queue profile”. The color-aware mode makes
use of the color marking described in “Mapping and queueing”. The color marking
can be green, yellow or red. The coupling flag is defined in the MEF 10.1 and only is
applicable for color-aware mode.
You need to create a separate policer profile for each direction. When you create and
configure a session profile, you have the option to associate both an upstream and
a downstream policer profile with that session profile. Once configured and
associated, policing is applied to all the frames within the session with which the
policer profiles are associated. As such, rate enforcement is performed uniformly for
all subscriber lines that are associated with that session profile.
In addition to this fast path policer, there is also a slow path policer that limits the
number of (upstream) control frames that are excepted to the on-board processor for
each subscriber line. This mechanism has been put in place to protect this shared
resource against DoS attacks from malicious users.
The slow path policer is also a single token bucket policer with Committed
Information Rate expressed in terms of packets per second and Committed Burst
Size expressed in terms of number of packets. This policer type is not subject to
profiling.
For GPON and XGS-PON / TWDM-PON, the OLT can instruct the ONT to either
police upstream DHCP, ARP and IGMP packets at a specific rate, or disable policing
of these protocols.
If an IGMP channel is configured, then IGMP packets are rate limited to the same
CIR as the slow path policer (described above).
20.5.1.11 Policy framework

A generic policy framework provides finer-grained control over subscriber traffic. It
provides for generic layer 2 or layer 3 classifiers and associated policy rules, which
can be attached with a certain priority to subscriber Service Access Points (SAPs).
One pair of classifier (or policy condition) and policy action list form the basic building
block of a unidirectional policy. On each supported SAP, a QoS session profile can
be attached, which contains two lists of policies: one for upstream and one for
downstream. The policy precedence defines the order in which policy conditions (the
filters) are configured in hardware per SAP. The rule is that the first filter that a given
packet matches will cause its associated actions to be carried out and no further
filtering rules are verified for that frame.

NT
Two types of L3 filters are supported: filters applicable to IPv4 traffic and filters
applicable to IPv6 traffic. The type of traffic is explicitly mentioned in the L3 filter
definition with default applicable to IPv4 traffic. For the sake of simplicity, IPv4
terminology is used for the different fields in an IPv4 filter and an IPv6 filter. As such
DSCP refers to DSCP in IPv4 and traffic class in IPV6. The protocol field refers to
protocol field in IPv4 and the next header field in IPv6.
Figure 305 shows the policy building blocks.
Figure 305 Policy building blocks
L2 Filter L3 Filter Policy Action

MAC Destination Address Address Type Default Disposition
MAC DA Prefix IP Destination Address Set DSCP
MAC Source Address IP DA Prefix Set P-bits
MAC SA Prefix IP Source Address Police
Ethertype IP SA Prefix Sharing
P-bits DSCP
CFI bit Protocol Type
VLAN ID Destination Port Range
Source Port Range
Note — P-bits and DSCP relate to the re-marked values when

used as a policy match condition. For example, a policy match
condition specifies p-bit value two. When a packet is received
with p-bit value two, but is subsequently re-marked to p-bit
value three, it would not match the policy. However, for the GE
Ethernet LT board, the received p-bit is used.
A set of non-conflicting actions can be grouped in a Policy Action list. This includes
a default disposition (permit/deny statement for ACL functionality), setting p-bit,
DSCP and policing. All packets identified by way of the associated filter can be rate
limited by a policer instance. Some subflow policies can share common attributes,
such as policing. The “Sharing” property of a policy action table enables or disables
policer sharing. Policer sharing will be used when the same policy action list is
referenced more than once on the same SAP in the same direction, and if the
Sharing attribute was set to “enable”.
The ISAM LT boards support more policies in the upstream direction than in the
downstream direction. This is in line with the typical requirements, as more security
policies are required in the ingress direction, while in the egress, mostly only traffic
class rate limitation applies.
In the downstream direction, p-bit/DSCP code point modifications can only be
realized by means of a policy action.

NT
Some restrictions apply to IPv6 packets:

• Layer 3 filters are not supported for IPv6 packets. This implies that corresponding
policy actions are not possible for such packets, unless applied via a Layer 2 filter.
• It is not possible to set the DSCP field in an IPv6 packet as a Layer 2 filter action.
For the GPON and XGS-PON / TWDM-PON ports, filter policies are applied to
protocol packets lifted to the CPU, as well as data packets. For the non-GPON and
XGS-PON / TWDM-PON LT boards, filter policies are not applied to the protocol
packets lifted to the CPU. For example, suppose that a policy is defined to discard
upstream broadcast packets. For a DSL subscriber with PPPoE service, this policy
would not discard a PPPoE PADI packet. However, for a GPON and XGS-PON /
TWDM-PON subscriber, this policy would discard a PPPoE PADI packet. To avoid
discarding the PADI packet, an additional policy must be added in the case of the
GPON and XGS-PON / TWDM-PON subscriber, with higher precedence than the
discard policy. This policy should match on the Ethertype of the PADI and specify
action as 'allow packet'.
In addition to existing L3 Filters defined in Figure 305, TCP Established flag is added
with the same set of policy actions applicable.
20.5.1.12 DSCP to p-bit alignment profile

For GPON and XGS-PON / TWDM-PON subscribers, it is possible to configure
DSCP to p-bit alignment profiles. Each profile defines an explicit mapping of each
DSCP codepoint to a p-bit value. The profile may be linked to an upstream marker
profile.
20.5.1.13 Counters and Threshold Crossing Alarms

QoS counters and related alarms serve the purpose of debugging the network for
traffic problems. SLA-based accounting is served by SAP-counters and as such
queue counters should only be enabled when debugging or testing the network.
Enabling the queue counters may reduce the maximum throughput of the system.
QoS counters are designed to provide evidence of traffic issues in case there are
problems. The queue counters are a basic building block which can be used by a
network operator to learn whether queue overflows occur in a certain traffic class,
and if so how often.
In a normal troubleshooting scenario the operator would enable or reset queue
counters and start up the services to observe whether the queue drop and pass
counters are incrementing. Queue drop counters provide evidence of buffer
overflows, which needs to be avoided in high-priority traffic classes transporting
non-responsive flows. Queue pass counters provide evidence of ongoing traffic,
which is a basic feedback whether there is connectivity or not and if traffic falls into
the right queues.

NT
Alarms are useful to observe events that occur rarely. QoS alarms have been defined
to detect in part traffic misbehaviors and in part system performance issues. While
queue counters can be used for device-under-study testing, alarms are useful to
detect conditions that occur rarely and would cost too much to be tracked by OAM
engineers.
The counters and threshold crossing alarms (TCAs) can be divided in two categories:
line/ queue based and line-card based.
Figure 306 QoS Counters and TCAs on layer 3 Boards
Queue Counters:
Passed Bytes/Frames
Dropped Bytes/Frames
OBC counters: Load
Dropped OBC frames US
Dropped OBC frames DS Queue TCAs:
OBC Dropped Frames
OBC TCAs: Load
Dropped OBC frames US
Dropped OBC frames DS
Tx
SP
WFQ System Bus Counters
(per Traffic Class):
Passed Bytes/Frames
Load
Memory Pool Master
Tx
Downstream
System Bus TCA):
Load
SP
WFQ
Tx
Aggregate buffer counters:
Dropped frames US
Dropped frames DS
Dropped low prio frames High
priority Line Counters:
Passed Bytes/Frames
Aggregate buffer TCAs: threshold Droppedd Bytes/Frames
Dropped frames US Load
Dropped frames DS
Dropped low prio frames
The 10GE Ethernet LT also supports queue monitoring on its backplane interface.
For the GPON and XGS-PON / TWDM-PON LT board, downstream queue based
counters are enabled/disabled on a per UNI basis, being disabled by default. The
counters can be enabled on up to 32 UNIs per PON. Packets passed/dropped, and
bytes passed/dropped are counted. Load per queue is not calculated. There is also
a, per queue, threshold crossing alarm for dropped packets.
For the non-GPON and non-XGS-PON / TWDM-PON LT boards, the following
line/queue based counters and alarms are supported:
• number of packets passed (per queue/line)
• number of packets dropped (per queue/line)
• number of bytes passed (per queue/line)
• number of bytes dropped (per queue/line)
• threshold crossing alarm for dropped packets (per queue)

NT
• queue load meter per queue (sync rate vs. bytes passed in this queue)
• total load meter per line (sync-rate vs. bytes passed per line)
• threshold crossing alarm for the load inflicted by traffic in one queue on the parent
physical interface (taking into account sync rate and encapsulation format)
In addition to the color blind counters listed above, the 10GE Ethernet LT, GPON,
XGS-PON / TWDM-PON LTs support the following color aware counters per
queue/line:
• number of passed packets per color (green, yellow, red)
• number of discarded packets per color (green, yellow, red)
• number of passed bytes per color (green, yellow, red)
• number of discarded bytes per color (green, yellow, red)
The queue/line loads and counters are calculated on a 15-minute basis. No long
history is kept; only the current and previous 15-minute counters are retrievable.
The total buffer pool is divided in two regions: a common region and a region saved
for high-priority traffic (that is, voice or video packets). The preliminary buffer pool
threshold can be specified in terms of percentage of total buffer pool, above which
only high-priority traffic is permitted into the buffer pool (both upstream and
downstream).
Figure 307 Buffer pool regions on IXP boards
Max usage of a queue
Total Physical Packet from the total pool (no
memory guaranteed minimum
on L3 boards)
Area that can

be saved for
high priority
traffic via
configuring
partial buffer Area for both low and
overflow high priority traffic
threshold
(configurable in
% of total pool)

NT
For upstream and downstream (which share the same pool on L3 cards) there are
dedicated threshold crossing alarms that can be triggered when more than a
programmable number of OBC, resp. non-OBC packets are dropped. Packet loss in
the total buffer pools may occur when:
• the egress queue sizes have been enlarged to a large extent, and many egress
ports on multiple queues suffer large backlogs
• when exceptionally high loads with smallest packet sizes persist over a long
duration (basically several hundreds of packets at gigabit speeds with less than
100 bytes each)
OBC-directed packets (that is, control packets) are also tracked for packet loss and
associated threshold crossing alarms can be activated. The queues towards the
OBC may overflow when:
• there are large bursts of control frames in the downstream direction
• there are large and correlated bursts on many ingress lines in the upstream
direction
Due to the fact that each subscriber line has a programmable packet policer for
control traffic it is inconceivable that the OBC-directed queues should overflow as a
result of just one subscriber line.
For the GPON and XGS-PON / TWDM-PON LT board, the following line-card level
counters are supported:
• high-priority packets to the OBC, dropped packets and bytes,
• low-priority packets to the OBC, dropped packets and bytes,
• high-priority packets towards the NT-LT link, dropped packets and bytes,
• low-priority packets towards the NT-LT link, dropped packets and bytes.
For the non-GPON and non-XGS-PON / TWDM-PON LT boards, the following

line-card level counters and alarms are supported:
• number of packets passed (per Traffic Class)
• number of bytes passed (per Traffic Class)
• total system bus load meter (per Traffic Class)
• threshold crossing alarm for system bus total load
• aggregate buffer overflow events for upstream resp. downstream traffic
• aggregate buffer overflow events for upstream resp. downstream OBC directed
traffic
• partial buffer overflow events for low priority traffic (that is, Controlled Load and
Best Effort)
• threshold crossing alarm for dropped upstream resp. dropped downstream traffic
due to aggregate buffer overflow
• threshold crossing alarm for dropped upstream resp. dropped downstream OBC
directed traffic due to aggregate buffer overflow
• threshold crossing alarm for dropped low priority traffic due to partial buffer
overflow

NT
The system maintains 32 15-minute counter sets and one previous and current 1-day
counter set related to aggregate buffer overflow (aggregate upstream, aggregate
downstream, aggregate upstream OBC, aggregate downstream OBC and partial
buffer pool overflow).
Fan-out load per traffic class is useful to trigger operator attention to unusually high
load conditions per LT board. In case the system bus gets overloaded (via normal
but rare or abnormal load conditions) this information can be used to take action in
terms of limiting the number of subscribers provisioned per LT board or finding
problems with multicast sources. The system automatically calculates fan-out loads
(that is, the load that goes down the system bus after multicast replication has
occurred) vs. the actual system bus bandwidth (as this varies with hardware
versions).
For fan-out load the system keeps 96 15-minute counters sets (load, pass
bytes/frames per Traffic Class) and one previous and current 1-day counter set (pass
bytes/frames) in addition to rolling counters. The 15-minute history counters are
useful for tracking system load evolutions over the day. Since the load is calculated
per traffic class, not only per LT board, this information can be used to track the
system load and bandwidth usage for the multicast video service (as this could not
possibly be tracked deeper in the network).
20.5.2 IHub part

This section provides information about the IHub service ingress access policy,
service ingress network policy, service egress network policy, per-service egress
rate limit, per-service ingress rate limit, base router network policy, forwarding class
to egress queue mapping, buffer and queue acceptance, egress scheduler and rate
limiter, and QoS parameters of packets generated by the control plane.
20.5.2.1 Service ingress access policy

Ingress access policies can be assigned to layer 2 services V-VPLS/VPLS/EPIPE
and to layer 3 services VPRN/IES. This effectively means that Ingress access
policies mappings can be defined and applied per service provider. Ingress access
policy profiles describe the mapping of packets received from SAPs to a forwarding
class and in/out profile color:
• The forwarding class is used to identify the egress queue in which the packet will
be queued.
• The profile color will be used for queue acceptance in the egress queue (WRED:
see later)
The mapping of packets to forwarding class and color can be based on combinations
of customer QoS markings, including IEEE 802.1p bits (with the option to derive the
color from DEI in place of p-bit), DSCP (IPv4 or IPv6), and TOS precedence
codepoints (IPv4 or IPv6).

NT
Each service is associated at creation time to a default ingress access policy.
Note — Untagged packets will be assigned a default p-bit

codepoint. This codepoint is also configurable in the policy.
In case ingress access policies are configured for a v-VPLS and this v-VPLS is
associated with a VPRN/IES service, then the VPRN/IES service ingress access
policy takes precedence.
20.5.2.2 Service ingress network policy

Ingress network policies can be assigned to the following L2 services: VPLS/ EPIPE.
This effectively means that Ingress network policies mappings can be defined and
applied per service provider. Ingress network policy profiles describe the mapping of
packets received from MPLS PW (that is, SDP binding) to a forwarding class and
in/out profile color:
be queued.
see later)
The mapping of packets to forwarding class and color is based on service label EXP
value or based on the IEEE 802.1p bits of the encapsulated Ethernet packet.
Each service is associated at creation time a default ingress network policy.
Note — Using the inner p-bit is only meaningful when the

encapsulated Ethernet packet is tagged. This is not guaranteed
when the PW VC-type is ether.
20.5.2.3 Service egress network policy

Egress network policies can be assigned to the following L2 services: VPLS/EPIPE.
This effectively means that egress access policies mappings can be defined and
applied per service provider. Egress access policy profiles describe how the EXP
value and the outer p-bit of packets sent out of a MPLS PW (SDP binding) are
generated based on a forwarding class and in/out profile color.
• The outer EXP value and/or outer p-bit will be used by subsequent LSRs.
• The inner EXP value is set identical to the outer EXP value, and can be used by
eLER as described in section “Service ingress network policy”

NT
Each service is associated at creation time a default egress access policy.
Note — Mapping in the policy all forwarding classes to the

same EXP value allows to have a particular EXP per service
provider.
20.5.2.4 Per-service egress rate limit

The IHub allows applying an egress rate limit:
1 Per service for all received traffic, associated to a V-VPLS/VPLS/EPIPE or
VPRN/IES service, which is egressing on network ports, or
2 Per class of service (CoS) within a specific service, again for all received traffic,
associated to a V-VPLS service, which is egressing on network ports.
In case a packet matches an egress rate limit for both a V-VPLS and a VPRN/IES
service, the VPRN/IES rate limit shall always have priority over the per V-VPLS rate
limit (so the latter will not be applied). For the type (2) rate limiter, the CoS is identified
by a p-bit or by multiple p-bits. Both type (1) and type (2) rate limiting can co-exist on
the same service. However, traffic that matches a type (2) rate limiter will not be
included in the type (1) rate limiter, since only a single rate limiter can be applied to
a packet.
The metering is based on two rate, three color marking. Lower priority packets will
be dropped first. The packets will be marked green (in profile) or yellow (out of profile)
using a configurable system-wide mapping of p-bit to color. The metering will then
update the color (green can change to green, yellow, or red; yellow can change to
yellow or red). The per-service rate limiter function will include an action to drop the
red packets.

NT
It is possible to re-mark the p-bit after policing has occurred, based on the color
determined by the policer. There is a configurable system-wide mapping for each
(p-bit, color) combination. Each network port can be configured to enable or disable
this re-marking.
Note — See sections “Service ingress access policy” and

“Service ingress network policy” for details on interaction of
per-service egress rate limiting with service ingress
access/network policies.
Both per-service egress rate limiting and service ingress
access/network policies provide a means to color mark
packets. If no rate limiting is applied to a packet, then the
applicable service ingress access/network policy determines
the color marking. However, if per- service egress rate limiting
is applied to a packet, then the color determined by it overrides
the color determined by the service ingress access/network
policy, except for the following case:
• Rate limiter has determined that a packet is green (in
profile), but the applicable service access/network policy
determines that the packet is yellow (out of profile). The
resulting color is yellow (out of profile).
When the NT uplink redundancy is distributed with traffic egressing out of both NTs
, then separate rate limiting is required in both NT boards. In this case, the configured
rate limit is split between each NT board, according to the configuration via the CLI
command configure qos-servicerouter active-nt-loadshare. Normally, this should be
set to 50%-50% for the two NT boards.
Note — In the active/active configuration, the rate limiting

function will not work for subtending interface on the NT, for
example, if a subtending ISAM is connected directly to the NT.
20.5.2.5 Per-service ingress rate limit

The FD 320Gbps NT and the FX NT allow applying an ingress rate limit per service
for all received traffic associated to a v-VPLS/VPLS or VPRN/IES service, which is
ingressing on network ports.
Note — This feature is not supported on EPIPE, VPLS used for
MPLS, or VPLS with multiple VLANs associated to it. It is also
not supported on the FD 100Gbps NT.
As for the per service egress rate limiting, the ingress rate limiting uses metering
based on two rate, three color marking. See “Per-service egress rate limit” for details.

NT
20.5.2.6 Base router network policy

Network policy is assigned to the base router. Base router network policy profiles
describe the mapping of packets received on network IP interfaces (of this base
router) to a forwarding class and in/out profile color:
be queued.
see later)
The mapping of packets to forwarding class and color can be based on combinations
of network QoS markings, DSCP (IPv4 or IPv6), and TOS precedence codepoints
(IPv4 or IPv6).
Note 1 — Untagged packets will be assigned a default p-bit
codepoint. This codepoint is also configurable in the policy.
Note 2 — This policy is similar as the service access ingress
policy associated with a VPRN/IES service.
Note 3 — The policy is applicable for all network interfaces.
20.5.2.7 Forwarding class to egress queue mapping

For the FD 100Gbps NT, the mapping of the forwarding classes to egress queues is
fixed and does not need configuration. The mapping table is shown in Table 74.
Table 74 Forwarding class to egress queue mapping (FD 100Gbps NT)
Flow Class Name FC Numbers Egress Queue
Best Effort (BE) 0, 1 0
Controlled Load (CL) 2, 3 1
Video 4, 5 2
Voice 6, 7 3
For the FD 320Gbps NT and the FX NT, it is possible to configure:

• the number of unicast queues as either 4 or 8
• the FC to queue mapping.
Since there are separate queues for unicast traffic and multicast traffic, for each
traffic class, both the unicast queue and the multicast queue can be specified. The
default mappings are shown in the following two tables. Note that the default for 8
queues is selected to correspond to the default queue prioritization. Refer to “Egress
scheduler and rate limiter” for details of the default queue prioritization.

NT

FX NTs)
Flow Class Name FC Numbers Egress UC Queue Egress MC Queue
Best Effort (BE) 0, 1 0 0
Controlled Load (CL) 2, 3 1 1
Video 4, 5 2 2
Voice 6, 7 3 3

FX NTs)
Flow Class Name FC Numbers Egress UC Queue Egress MC Queue
be 0 0 0
l2 1 4 0
af 2 1 1
l1 3 5 1
h2 4 2 2
ef 5 6 2
h1 6 3 3
nc 7 7 3
20.5.2.8 Buffer and queue acceptance

Buffer and queue acceptance features Weighted Random Early Discard (WRED).
The configuration of the buffer dimensioning and the buffer acceptance parameters
is fixed and does not need configuration.
The WRED supports two colors: in-profile (green) and out-of-profile (yellow) packets.
For each of these profiles, a start average queue filling level, a maximum average
queue filling level and a maximum drop probability applies, as shown in Figure 308,
which is applicable for TCP traffic.

NT
Figure 308 Buffer and queue acceptance (TCP Traffic)
Drop Probability
100%
In profile
max. probability
=
Out profile 50%
max. probability
Average queue
filling level
50% 70% 90%
Out profile Out profile

av. start av. maximum
In profile In profile
av. start av. maximum
The following applies for the packets:

• Green packets:
the packet drop rate starts at 70% average queue filling level and increases
linearly from 0 to 50% packet drop rate at 90% average queue filling level. When
the average queue filling level goes beyond 90%, all packets are dropped. Below
70% average queue filling level, there is no WRED drop.
• Yellow packets:
the packet drop rate starts at 50% average queue filling level and increases
linearly from 0 to 50% packet drop rate at 70% queue filling level. When the
average queue filling level goes beyond 70%, all packets are dropped. Below 50%
average queue filling level, there is no WRED drop.
For non-TCP traffic, the handling as shown in Figure 309 applies.

NT
Figure 309 Buffer and queue acceptance (non-TCP traffic)
Drop Probability
100%
Average queue
filling level
70% 90%
Out profile In profile

av. maximum av. maximum
20.5.2.9 Egress scheduler and rate limiter

For the FD 100Gbps NT, the Egress queue schedulers are fixed and do not need
configuration.
The scheduler topology is a combination of strict priority (SP) served queues and
Weighted Round Robin (WRR) served queues, as shown in Figure 310.
Figure 310 IHub egress port scheduler topology
Voice
Port rate
Video SP limiter
CL
WRR
BE
For the FD 320Gbps NT and FX NT, it is possible to configure the queue priorities
and weights. Weighted queues are treated as the lowest priority. There are default
configurations for both 4 queue and 8 queue modes, as shown in Figure 311 and
Figure 312. Note that there are separate queues for unicast and multicast traffic.
Each multicast queue is always scheduled in a round robin fashion with the
corresponding unicast queue. For example, multicast queue 3 and unicast queue 3
are scheduled together as a round robin group.
In the 4 queue default, the unicast/multicast queue 3 are scheduled at highest
priority, then the unicast/multicast queue 2, and finally unicast/multicast queue 1 and
queue 0, in a 2:1 weighted fashion.

NT
Figure 311 IHub egress port scheduler topology (default 4 queue FD

320Gbps and FX NT)
UC Q0
RR
MC Q0 W=1
UC Q1 W=2 WRR
RR
MC Q1
SP
UC Q2 SP
RR
SP
MC Q2
SP
UC Q3
RR
MC Q3

NT
Figure 312 IHub egress port scheduler topology (default 8 queue FD

320Gbps and FX NT)
UC Q0
RR
MC Q0 SP
UC Q4 SP
UC Q1
RR SP
MC Q1
SP
UC Q5 SP
SP
UC Q2
RR
MC Q2 SP
UC Q6 SP
SP
UC Q3
RR
MC Q3
UC Q7
In the 8-queue mode, there are 8 unicast queues but still only 4 multicast queues
(queues 0, 1, 2 and 3). As for the 4-queue case, each multicast queue is always
scheduled in a round robin fashion with the corresponding unicast queue. The 4 extra
unicast queues are numbered queue 4, 5, 6 and 7. In the 8-queue default, all queues
are scheduled in strict priority (except for the round robin grouping for each pair of
unicast/multicast queues). In terms of queue priorities, the 4 extra queues are
interleaved with the 4 paired queues. At first sight, this order of prioritization looks
strange as it means queue 7 is scheduled first priority, then queue 3, then queue 6,
then queue 2, and so on (as shown in Figure 312). One would expect instead queue
7, then queue 6, then queue 5, and so on. However, such an order of prioritization
would imply that 4 unicast queues would be scheduled at a higher priority than any
multicast queue. The interleaving of the extra unicast queues avoids this problem.
For each port, connected to the network or connected to a subtending ISAM, a port
rate limiter function may be applied. The port rate limiter parameters are:
• Port egress rate
• Burst size

NT
20.5.2.10 QoS parameters of packets generated by the

control plane
IHub supports the creation of policies for packets generated by the control plane.
Each policy defines the following QoS parameters for packets generated by the
control plane:
• p-bit codepoint
• DSCP codepoint
• EXP value
Each service is associated to a default policy for packets generated by the control
plane. It is allowed to change this association, so that a service is associated with a
customized policy, instead of the default policy.
The QoS parameters will be added when the control packet is sent out on an external
interface and will apply to all protocols associated to the service.
Note — The policy does not apply to packets relayed by the

control plane.
Figure 313 QoS in IHub upstream for services
Service Egress Rate Limiting

- CIR, PIR, CBS, PBS Egress QoS policy
Ingress QoS Policy
(applies to all SAPs)
(applies to all SDP bindings)
Set FC based on
Set EXP based on FC
DSCP, PREC,P-bits
VPLS/EPIPE VPLS/EPIPE/VPRN/IES
Egress Port Rate Limiter Application

- maximum rate
Self-Generated
Traffic Policy Access port
Network Residential
port
FC1
Access port FC2
regular
FC8
Port
SERVICE SAP
ISAM
SDP binding
Egress Port FC Queue

Queue Policy Map Policy
Egress Queue System wide defined mapping
Slope Policy of FCx to egress COS queue
WRED
Defines Characteristics of each egress COS queue:
- CBS, MBS, CIR, PIR
Per-port definition of scheduling over egress queues: SP,WRR,..

NT
Figure 314 QoS in IHub downstream for services
Ingress QoS policy Ingress QoS Policy

(applis to all SDP bindings) (applies to all SAPs)
Set FC based on Set FC based on
EXP, inner p-bit DSCP, PREC,p-bit
VPLS/EPIPE VPLS/EPIPE/VPRN/IES
Application Egress Port Rate Limiter
- CIR, PIR, CBS, PBS
Access port Self-Generated
regular Traffic Policy 1
4
1 Access port
Network 4 Residential
port 1
4
FC1
FC2 Defines characteristics of each
FC8 egress COS queue:
SERVICE - CBS, MBS, CIR, PIR
System-wide definition of scheduling
ISAM
over egress queues: SP,WRR,..
FC Queue Egress Port

Map Policy Queue Policy
Egress Queue
ISAM wide
Slope Policy
WRED
Figure 315 QoS in IHub for base router
Network QoS Policy

(applies to all network IP interfaces)
Ingress: set FC based on DSCP, PREC, p-bit
Egress: empty
Egress Port
Application
Rate Limiter
Self-Generated
Traffic Policy
Network
port FCx
Port
Base router IP interface
ISAM
Egress Port
Egress Queue Queue Policy
Slope Policy FC Queue
WRED Map Policy
Defines characteristics
of each [1..4] queue ISAM wide

System Description for FD 100/320Gbps NT and FX Resource management and authentication
NT
21 Resource management and

authentication
21.1 Introduction
21.2 RADIUS features
21.3 802.1X authentication via RADIUS
21.4 Operator authentication via RADIUS
21.6 Fast recovery of 802.1X sessions
21.7 Lawful Interception
21.8 Authenticate, authorize and account operator via TACACS+
21.1 Introduction
Remote Authentication Dial-in User Service (RADIUS) is a standardized method of
information exchange between a device that provides network access to users
(RADIUS clients) and a device that contains authentication and profile information for
the users (RADIUS server). The ISAM supports RADIUS for both layer 2 and layer 3
forwarding.
Authentication via RADIUS provides the following advantages:
• password management is centralized so there are fewer password databases and
passwords to maintain.
• support of strong authentication in a cost-effective way. The same RADIUS server
or a back-end authentication server supports strong authentication. In the case of
local authentication, strong authentication may not be feasible.
The ISAM supports RADIUS authentication via base router and VPRN services.
21.2 RADIUS features

The following features are supported:
• Operator (CLI/TL1) authentication via an external RADIUS authentication server.
• Subscriber (802.1X) authentication via an external RADIUS authentication server.

Resource management and authentication System Description for FD 100/320Gbps NT and FX
NT
• Dynamic Authorization Extensions::

• Disconnect Message (DM) support, used to disconnect the specified 802.1X session.
• Change-of-Authorization (CoA) message support, used to change the customer
network VLAN ID and QoS session profile on the specified 802.1X session.
• A RADIUS Authentication client:
• Encrypts all password fields in the messages.
• Supports multiple RADIUS Authentication servers.
• A flexible authentication mechanism:
• Support of Password Authentication Protocol (PAP) and Challenge-Handshake
Authentication Protocol (CHAP) authentication
• Support of Extensible Authentication Protocol (EAP)
• Fallback to a configurable default operator profile when the RADIUS server does
not support vendor specific attribute.
21.3 802.1X authentication via RADIUS

RADIUS support provides the ability to authenticate 802.1X sessions at an external
database (residing at the RADIUS server). Apart from authentication, RADIUS can
also be used to provide accounting for 802.1X sessions.
In addition, when authenticating the subscriber, RADIUS can return configuration
parameters to the ISAM, which enables the dynamic provisioning of certain
subscriber aspects. These aspects include dynamic mapping to a service provider
(service selection), QoS, and ACL. RADIUS not only provides secure authentication
and accounting, but also facilitates subscriber provisioning.
21.3.1 Dynamic Authorization Extensions for RADIUS with

802.1X
The original RADIUS protocol does not provide support for unsolicited messages
sent from the RADIUS server towards the Network access server (NAS). There is
however a need to control the subscriber session characteristics when using 802.1X
authentication.
Dynamic Authorization Extensions (RFC 5176) are used to send unsolicited
Change-of-Authorization (CoA) or Disconnect Messages (DM) from the RADIUS
server (CoA server) to the ISAM in order to disconnect the specified 802.1X session
or to change the customer network VLAN ID and QoS session profile on the specified
802.1X session.
The following attributes are recognized by the ISAM to identify the correct 802.1X
session:
• Calling-Station-Id (the Client MAC address)
• Acct-Session-ID
• User-Name

NT
• NAS-Port
• NAS-Port-Id
21.4 Operator authentication via RADIUS

CLI and TL1 operators can be authenticated either locally on each DSLAM or
remotely via a central RADIUS server.
In case of remote authentication via RADIUS, besides the username and password,
also the terminal IP address from where the operator is initiating the Telnet session
or the SSH session with the ISAM, is sent to the RADIUS server. This will allow the
RADIUS server to also use the IP address of the operator during authentication. The
IP address is always sent. It is up to the RADIUS server to check the IP address or
not during authentication. If the operator is connected thought a CRAFT (serial)
terminal there is no operator IP address hence no attribute with IP address in the
Access Request is sent to the RADIUS server.
CLI also supports interactive authentication. It is a convenient way to update an
expired operator password or for other purposes. When the RADIUS server sends
back an ‘Access Challenge’, the DSLAM will echo the Reply-Message, (that is
included in the Access Challenge), on the terminal at the prompt and wait for the
operator input. After the operator provides input, the DSLAM will add the State (if it
is in the Access Challenge), update the User-Password (encrypted operator input) in
the new Access Request and send it out. The DSLAM will continue to interact with
the RADIUS server when it receives the Access Challenge, until the DSLAM receives
an ‘Access Accept’ or ‘Access Reject’ from the RADIUS server or until the CLI
session is canceled by the operator.
TL1 does not support interactive authentication, each ‘Access Challenge’ received
from the RADIUS server will be treated as an ‘Access Reject’.
There is one restriction: if CLI or TL1 over SSH with key authentication is used, the
authentication has to be done locally. RADIUS does not support keys.
This functionality is only supported for CLI and TL1. The authentication occurs once
for a complete session. Operator authentication is not supported for SNMP operators
as SNMP does not work with the concept of session. Communication with a RADIUS
server would have to be set up for each SNMP request, in order to authenticate the
originator.
A centralized authentication server has a lot of benefits for the management of
operator accounts, but is a danger with regard to availability and security. It is
advisable to support redundant RADIUS servers (this is supported by the ISAM). In
addition, the ISAM will fallback to local authentication in case the communication with
the RADIUS server fails.

NT
Typically, the local database only contains the administrator account in case
RADIUS is used. To prevent isolation, one default local operator profile can be
configured, which applies when RADIUS is not reachable and when the operator is
not configured in the local database.
Note — No accounting is performed for authenticated CLI/TL1

operator sessions.
21.5 Encryption of authentication data

Passwords, RADIUS secrets, and other authentication data are encrypted in such a
way in the system database that the plain form cannot be derived from the system
database when this is not required for normal operation (for example, passwords for
PAP local authentication). In cases where it is necessary to retrieve the plain text
form, adequate encryption (MD5) is used to avoid unauthorized retrieval. This
applies for authentication on all the management interfaces and on all the user
interfaces.
21.6 Fast recovery of 802.1X sessions

For any LT restart not triggered by a hardware failure or a power-on event (for
instance a software upgrade or LT reset), the ISAM supports fast recovery of 802.1X
sessions that were previously authenticated. The ISAM does not perform a fast
recovery on ports that were not authenticated or in the process of authenticating
when the event occurred.
Once the LT resets, it recovers all active 802.1X sessions and opens all
authenticated ports, allowing traffic to pass. To do this, an unsolicited EAP-Success
message is sent to the 802.1X client (force authorize). The 802.1X port state will
show "force-auth". In addition, an IGMP GMQ is sent out on the end-user port.
At this point, some of the force-authorized 802.1X ports may not have a
corresponding RADIUS session. The ports remain in force-auth state for a minimum
of 10 minutes, after which the LT starts a random timer (with a maximum value of 10
minutes) for each 802.1X port in force-auth sate. Once expired, the LT triggers a
re-authentication with the supplicant, which includes RADIUS re-authentication. The
random timer allows the system to spread the load of re-authenticating ports over
time to prevent the overload of systems with many ports.
Once a force-authorized port is re-authenticated, then the 802.1X session is also
restored via RADIUS in the AAA server.
When using MAC-based 802.1X authentication, a different recovery method is used
in case the LT restart is not triggered by a hardware failure or a power-on event. In
this case, once the UNI port is operationally up, the ISAM sends an "EAP-Req"
message to force the client to perform authentication again.

NT
21.7 Lawful Interception

Lawful Interception (LI) is done by Law Enforcement Agencies (LEA) of governments
in order to combat crime and other anti-constitutional activities.
ISAM family performs the role of Content of Communication Interception Function
(CCIF) by mirroring the data to be intercepted. The target to be intercepted is
identified by an external Lawful Intercept Administration Function (LIAF) by means of
interfacing with the RADIUS and/or the DHCP servers.
The LIAF then triggers the ISAM to intercept the associated target based on
identifiers received from RADIUS and/or DHCP servers.
Once the data is mirrored (duplicated) in ISAM the same is forwarded to an external
Lawful Interception Mediation Function (LIMF), which in turn securely transmits the
data towards the LEA.
Due to the sensitive nature of Lawful Interception, the administration of Lawful
Interception is restricted to authenticated operators only. Non-authenticated
operators would not be able to administer the Lawful Interception function in the
ISAM. Lawful Interception administration on the ISAM can be done either via CLI or
by SNMPv3 by exclusively authenticated operators.
In order to securely transmit the content of communication data, all intercepted
(mirrored) packets are encapsulated before forwarding to the LIMF.
The upstream / downstream traffic to the user is not impacted by enabling lawful
interception on the user. The intercepted traffic is forwarded to the LIMF by means
of tunneling techniques. It shall be possible to set the priority of the intercepted
packets.
21.8 Authenticate, authorize and account operator

via TACACS+
Just like RADIUS, Terminal Access Controller Access-Control System Plus
(TACACS+) refers to a family of related protocols handling remote authentication
and related services for networked access control through a centralized server.
The ISAM only supports authentication, authorization and accounting (AAA) for CLI
operators using TACACS+, 802.1X session and TL1 operators are not supported.
RADIUS servers handle authentication and authorization in a single transaction with
the server. Once authenticated, the RADIUS server will assign corresponding
access privileges via Vendor Specific Attributes. For TACACS+, however, these
separate authentication, authorization, and accounting (AAA) components can be
handled by independent servers. SinceTACACS+ authorizes each command in real
time, TACACS+ authorization servers should be duplicated and authorization
configuration should be synchronized across TACACS+ servers to ensure a
consistent set of authorized commands to the user during a CLI session.

NT
The ISAM supports a mixed deployment for RADIUS and TACACS+. For example,
RADIUS is used for authentication and authorization while TACACS+ is used for
accounting. ISAM supports three combinations:
• RRN: indicates to authenticate and authorize using RADIUS, without any
accounting server(s)
• TTT: indicates to authenticate, authorize and account using TACACS+. There are
some limitations for TACACS+ protocol such as only "Inbound ASCII Login"
authentication mode and "AUTHEN_METH_TACACSPLUS" authentication
method in authorization requests.
• RRT: indicates to authenticate and authorize using RADIUS while accounting is
done via TACACS+. Note that only "stop-only" is supported in an accounting
request.
For each AAA component, multiple servers should be available for redundancy and
network failures. The ISAM selects the server via the configured priority, and
switches to the backup server once the unavailability of the active service is
detected. The newly inactive server will not be selected during the 'dead' period in
order to avoid frequent switchover. In the case where all servers are unreachable,
the ISAM will fall back to local CLI user configuration. The local user configuration
may have a different passwords and command profile than the remote servers. Note
that for both RADIUS and TACACS, if authentication reverts to local due to
unreachable server(s), authorization also falls back to local. TACACS accounting, if
configured and reachable, will continue in local authentication and authorization
case, since the local default ‘syslog auth’ file and TACACS accounting should be
kept synchronized for audit purposes.
The ISAM supports dynamically changing the combination mode. As such a change
occurs, the ISAM will terminate all existing CLI sessions automatically and force all
online operators to login again with the updated mode.

System Description for FD 100/320Gbps NT and FX MPLS
NT
22 MPLS
22.1 Introduction
22.2 Label Switched Path
22.3 Label Distribution Protocol
22.4 Resource Reservation Protocol
22.5 Pseudo-wires and T-LDP
22.6 BGP Auto-Discovery
22.7 L2 VPN services
22.8 QoS
22.9 Redundancy and resilience
22.10 Support for MPLS rings
22.11 Support for MPLS flow label
22.12 Supporting integrated voice services over MPLS
22.13 Supporting MPLS and VLAN Traffic on "Hybrid Port"
22.1 Introduction
Multi-protocol Label Switching (MPLS) is a label switching technology that provides
the ability to set up connection-oriented paths over a connectionless IP network.
MPLS sets up a specific path for a sequence of packets. The packets are identified
by a label inserted into each packet.
MPLS is used in the ISAM as a building block to support L2 VPN services like Virtual
Leased Line (VLL) and Virtual Private LAN Service (VPLS). In this case, the ISAM is
acting as Label Edge Router (LER) and the distribution/reception of MPLS transport
labels is based on Label Distribution Protocol (LDP).
MPLS can also be used in the ISAM to support deploying an MPLS ring. In that case,
the ISAM is acting as a Label Switch Router (LSR) and the distribution/reception of
the MPLS transport labels is based on Resource Reservation Protocol (RSVP-TE)
and LDP.

MPLS System Description for FD 100/320Gbps NT and FX
NT
In both cases, the ISAM originates and terminates pseudo-wires (PWs) to support
VLL/VPLS services. The distribution/reception of service labels to identify these
pseudo-wires is based on Targeted LDP (T-LDP) or the Border Gateway Protocol
(BGP).
22.2 Label Switched Path

The MPLS traffic is originated/terminated on the uplinks of the NT/NTIO board.
It needs explicit configuration to define which uplinks can be configured as
supporting MPLS (that is, by setting the port mode of the link to network).
The MPLS traffic can be sent tagged or untagged. This depends on the configuration
of the network IP interface that is selected as the next best hop when sending the
packet.
For traffic arriving on an access port which needs to be sent towards the aggregation
network, the system is acting as an ingress Label Edge Router (iLER). In the other
direction, the system is acting as an egress Label Edge Router (eLER).
In order to support deploying an MPLS ring, the Access Nodes in Transit also support
MPLS LSR functionality. This is used to switch the MPLS LSP traffic to the next node
in the ring, without having to terminate MPLS connections on each node.
Figure 316 Label switched path
POP SWAP SWAP PUSH
eLER iLER
LSR LSR
Label Switched Path
DATA LABEL DATA LABEL DATA LABEL DATA DATA
As MPLS is introduced as a vehicle to support L2 VPN services, one can state that
MPLS data traffic will mostly carry two labels:
• the first label is the transport label (received via LDP or statically configured)
• the second label is a service demultiplexer as described in PWE3 (received via
T-LDP,BGP or statically configured).
Label switched paths (LSPs) are either configured statically or are setup via LDP or
RSVP-TE. Transit LSPs can be established using RSVP-TE or LDP.

NT
For troubleshooting of LSPs, the system will respond to LSP ping messages and
traceroute messages received from remote peers.
22.3 Label Distribution Protocol

The Label Distribution Protocol (LDP) is used by the ISAM as an MPLS label
distribution protocol.
LDP is enabled on the IP interfaces defined on top of the network-facing ports (and
which have been enabled to support MPLS). These IP interfaces have to be created
part of the base router as described in chapter “IP routing”.
The system has the following LDP characteristics:
• LDP can operate in either Downstream Unsolicited (DoU) mode or Downstream
on Demand (DoD) mode.
• When using DoU, an LER/LSR is allowed to distribute label bindings to a peering
LER/LSR (for example, ISAM) that has not explicitly requested these label bindings.
Hence, the ISAM will receive all label bindings for reachable far-end IP addresses of
the PE nodes.
• When using DoD, the ISAM will explicitly send label request messages to its directly
connected peers, in order to obtain label bindings for the far-end IP addresses of PE
nodes (provided that the peer is the next hop to reach the far-end IP address, and
that the next hop is the IGP shortest path). The ISAM will send a label request
message whenever an SDP is created. This greatly reduces the amount of label
bindings that need to be stored on the ISAM.
The use of DoU or DoD mode is configurable on system level. Note that DoD is
not supported for T-LDP, according to the PWE3 standards.
• By default the ISAM only advertises the label binding(s) for its system IP address
(/32).
• The ISAM uses the “liberal label retention” mode, that is, the ISAM stores the
bindings between a label and an FEC which are received from LERs/LSRs which
are not its next hop for that FEC. The liberal label retention mode allows for
quicker adaptation to routing changes. The Label Information Base (LIB) is the
database where all received label bindings are stored.
• The ISAM uses a per-platform label space, that is, the labels that are advertised
are identical on all the MPLS network links.
• LDP can be enabled or disabled per network interface. The LDP protocol
parameters can be configured globally and can be overruled per IP interface. By
default, the system IP address is used as transport address to establish the LDP
TCP session.
• The ISAM supports dynamically signaled LSPs in combination with the following
IP routing protocols: static routing, OSPF, IS-IS and RIP. In addition, MPLS LSPs
can be statically configured or dynamically signaled on top of an Ethernet Link
Aggregation Group (LAG).
• The ISAM does not require other LSRs to support “Penultimate Hop Popping”.
The ISAM will neither advertise NULL labels nor support receiving implicit NULL
labels.

NT
• The ISAM supports LDP message reception, requesting to use the explicit NULL
label towards the directly attached LER. This allows the ISAM to be interoperable
with peering LERs that require MPLS packet reception having an MPLS tunnel
label of value 0.
• The ISAM supports LDP message reception, requesting to use the implicit NULL
label towards the directly attached LER for the purpose of Penultimate Hop
Popping (PHP). This allows the ISAM to be fully interoperable with peering LERs
that require MPLS packet reception having no MPLS tunnel label. The ISAM as
an LDP LSR does not support PHP.
Figure 317 Label distribution
LDP session
ISAM
LSR
LIB
RIB
LSR
LDP session
LDP DoU
Routing protocol
• When receiving a Label Mapping message from an LSR for a Prefix or Host
Address FEC Element (for example, the system IP address of another access
node) the ISAM can use the label for forwarding even when its routing table (RIB)
does not contain an entry that exactly matches the FEC Element. The ISAM
supports so-called aggregated prefix matching, meaning that it is sufficient for the
routing table to contain a longest matching prefix entry for the corresponding FEC
Element. Population of the ISAM routing table (RIB) can be done manually but
due to the large number of host addresses it is preferred to have a routing protocol
activated (OSPF, RIP,…) on the ISAM node. The RIB is the database where all
received or configured routes are stored.
• When there are multiple LSPs that contain a Host Address FEC element (for
example the system IP address of another access node) which is identical to the
destination address of the packet, then the packet is mapped to one of those
LSPs. The choice of LSP is made based on the IGP next-hop for that host
address. In case there are multiple equal-cost IGP next-hops available (that is,

NT
several equal-cost tunnel LSPs that allow to reach the same Provider Edge node)
then the ISAM will select one of those LSPs. This selection is performed on a
per-service base in order to allow load balancing of upstream traffic
22.4 Resource Reservation Protocol

RSVP-TE support is mainly introduced to allow deploying the ISAMs in an MPLS
ring. It allow establishing LSPs that will be switched through the ISAM which acts as
an LSR. See section “Support for MPLS rings” for the basic description.
The following table summarizes the main features supported in relation to RSVP-TE
Table 77 RSVP-TE main features
Features Description
RSVP-TE base protocol Base RSVP-TE protocol support
RSVP-TE parameters • RSVP-TE reservation styles

• Message pacing
• Refresh reduction
• Refresh time
RSVP-TE LSP without The LSP is setup using the best path as advertised with a routing
Constrained-based Shortest Path protocol (for example, OSPF or IS-IS)
First (CSPF)
RSVP-TE LSP with Traffic engineering and LSP CSPF constraints can be used to control
Constrained-based Shortest Path the LSP setup
First (CSPF)
RSVP-TE Primary and secondary The LSP can be setup using path constraints (for example, hop-limit)
Parameter support for primary and secondary paths
RSVP-TE BFD BFD support for RSVP interface to speed up failure detection
RSVP Authentication Protects against spoofed RSVP-TE packets
Note — The RSVP-TE, the MPLS Fast Reroute (FRR) and the
MPLS LSR functionality can also be applied to non-ring
networks. However, the ISAM currently only supports
one-to-one backup tunnels (that is, detour LSPs). This means
that in large networks, the number of LSPs may become large.
Care should be taken to keep the total number of LSPs under
control.

NT
22.5 Pseudo-wires and T-LDP

By using PWs the ISAM offers an emulated L2 service over an MPLS tunnel, that is,
it acts as a Provider Edge (PE) device or a Multi-Tenant Unit Switch (MTU-s)
(RFC4762) offering Pseudo Wire Emulation Edge to Edge (PWE3) services.
The ISAM supports both spoke PW and hub PW.
The ISAM uses T-LDP by default to set up PWs (although static provisioning of
service labels is also supported).
Figure 318 T-LDP and PW
PE/MTU-s
T-LDP session (exchange service labels)
PE
DATA LSR
LT1 AC1 LDP session LDP session
AC2
AC3
DATA
LTn
DATA
ISAM Service 1
Service 2
DATA LABEL LABEL DATA LABEL LABEL DATA DATA
DATA LABEL LABEL DATA LABEL LABEL DATA DATA
Second label identifying service
The T-LDP session is set up between the ISAM (using the configured system IP
address) and each configured far-end IP address that terminates service tunnels.
To define which LSP is used for a particular service tunnel, the ISAM uses the
concept of Service Delivery Points (SDPs). An SDP identifies the IP address of the
end of the tunnel and the LSP to reach that endpoint. The LSP can be either static
or dynamic (when LDP is enabled on it). An SDP binding is created by associating a
service instance (VLL, VPLS) with an SDP (this is in fact nothing else than a
pseudo-wire.
When using T-LDP, the ISAM has the following T-LDP characteristics:
• FEC128 is used for reception and distribution of service labels
• the configured VC-TYPE of the SDP binding is passed: ether or VLAN

NT
• indication of whether a control word will be used

• indication of the maximum MTU size (which is configurable per service)
For troubleshooting of a PW, the system will react on Virtual Channel Connectivity
Verification (VCCV) messages.
The ISAM supports two types of pseudo-wires: mesh or spoke. A spoke is used for
H-VPLS or to connect an ISAM in a redundant manner.
22.6 BGP Auto-Discovery

Next to LDP and T-LDP, the ISAM supports BGP Auto-Discovery to automatically
find all the PEs that participate in a given VPLS instance. Moreover, BGP can be
used to establish the corresponding Pseudowires for the VPLS instance, as
described in RFC 4761. Alternatively, BGP-AD is only used for Auto-Discovery and
the actual Pseudowire signaling is done using T-LDP. This model is defined in RFC
6074.
The following table shows the supported signaling models and associated RFCs.
There are several mechanisms to establish the Ethernet Pseudowires:
Table 78 BGP supported signaling models
Multipoint to multipoint Point to point

(VPLS/ELAN) (VPWS/ELINE/EPIPE)
LDP sig BGP sig LDP sig BGP sig
Manual RFC 4762 (NOT supported) RFC 4447 (NOT supported)

discovery (FEC 128) (FEC 128)
BGP auto RFC 6074 RFC 4761 RFC 6074 RFC 6624
discovery (FEC 129) (FEC 129) (NOT suppported)
(NOT supported)
• Manual discovery:
In this model, Target LDP signaling is used and the PWid FEC element (the
so-called FEC 128) is used to identify the Pseudowire at both endpoints of the
connection.
• Auto discovery:
In this model, BGP is used to automatically find all the PEs that participate in a
given VPLS instance. This model has two sub-variants:
• Pseudowire setup using T-LDP: in this model, BGP-AD is only used for
auto-discovery and the actual Pseudowire signaling is done using T-LDP, using the
Generalized FEC (so-called FEC 129). This model is defined in RFC 6074.
• Pseudowire setup using BGP: in this mode, BGP is used to establish the
corresponding Pseudowires for the VPLS instance, as described in RFC 4761.

NT
In all of the above models, the signaling of the MPLS transport tunnel is supported
on ISAM using LDP.
When BGP-AD is used, the SDP bindings will be automatically instantiated using the
information advertised by BGP-AD. This is done for every auto-discovered SDP
binding through the use of the "pseudowire template" concept. A pseudowire
template contains a list of specific layer 2 VPN parameters that are relevant for the
pseudowire setup. Each VPLS service that is configured to use BGP-AD, will also be
configured with a binding to a suitable pseudowire template.
The BGP-based SDP binding is programmed as a spoke-SDP by default. This allows
forwarding traffic between the Pseudowires within the same service.
The ISAM BGP-AD implementation has the following restrictions:
• To support mesh topology split horizon group configuration is mandatory to avoid
traffic loop.
• The use of transport tunnel signaling based on RSVP-TE and MPLS FRR is not
supported in combination with BGP-AD or LDP FEC 129 signaling.
• No Inter-AS support
• Related to BGP-AD (RFC 6074):
• BGP-AD is not supported for VPWS/EPIPE services.
• No support for Distributed VPLS (Pseudowire splicing).
• No simultaneous support of mesh and spoke pseudowires (as part of H-VPLS)
• Related to BGP for Auto-Discovery and Signaling (RFC 4761):
• No multi-homing support for VPLS.
22.7 L2 VPN services

The MPLS service configuration on the IHUB system can be summarized in next
steps:
1 Creation of a service instance (VLL or a VPLS)
2 Creation of SAPs within the service instance:
SAPs represent user traffic entering the NT board from a connected LT
board/user port.
A SAP is identified via an LT board/user port number and an encapsulation value.
3 Creation of an SDP binding within the service instance
The SDP binding represents a PW and is created by associating the service with
an SDP.

NT
Figure 319 LT-NT mapping
DSL
LT NT
PW
VLAN cross-connect Tunnel VLAN 1
VLL1
(Tunnel)
LSP 1
SDP
DSL 1
VLAN cross-connect PW
Mapped VLAN VLL2
(Mapped) 2
SDP
iBridge VLAN B 2 PW
VPLS1 LSP 2
3
VLAN B SDP
3
iBridge
VPLS2
PW
4
LSP 3
SAP PW
5
SDP binding
22.7.1 VLL Tunneling approach

The LT board unconditionally adds a “tunnel VLAN” when sending traffic to the NT
board. The <incoming port, tunnel VLAN ID> pair is used to determine the VLL
instance in the NT board. Before encapsulating the L2 frame in the associated PW,
the tunnel VLAN can be removed by configuring the PW of type ether. This
mechanism achieves full transparency of customer traffic. Specifically, it supports
receiving dual-tagged frames and sending them on a VLL towards the aggregation
network.
22.7.2 VLL Mapping approach

The LT board maintains the VLAN(s) in the frames received from a customer. The
<incoming port, tunnel VLAN ID> pair is used to determine the VLL instance in the
NT board. Before encapsulating the L2 frame in the associated PW, the outer VLAN
can be removed by configuring the PW of type ether.

NT
22.7.3 VPLS iBridge approach

The LT multiplexes incoming untagged traffic or single-tagged traffic of several
residential subscribers in an (enhanced) iBridge instance. At the user-side, frames
may arrive untagged or priority tagged, in which case a Port-default-VLAN (PVID)
selection or a protocol-based VLAN selection is used to select the appropriate
iBridge. Frames are sent to the NT board using a single VLAN tag. This VLAN ID is
used to map traffic to the corresponding VPLS instance on the NT board. Before
encapsulating the L2 frame in the associated PW, the outer VLAN can be removed
by configuring the PW of type ether.
22.8 QoS
QoS details can be found in chapter “Quality of Service”.
In a nutshell, two types of PW-related policies can be configured:
• Service egress network policy:
allows to define the setting of the EXP and the outer p-bits based on the
forwarding class
• Service ingress network policy:
allows to derive the forwarding class from the EXP or the inner p-bit.
These policies are associated with a VLL instance or a VPLS instance.

In addition to offering QoS to LSPs that are initiated or terminated, the ISAM can
provide QoS to transit LSPs (when the ISAM acts as an LSR). To do this, separate
policies have to be configured that map the traffic with a specific MPLS exp-bit value
to a given Traffic Class and provide the appropriate QoS.
Before sending the traffic to the egress interface, a Traffic Class to MPLS exp-bit
mapping is performed, using a fixed mapping table. This two-step process allows
remarking the MPLS exp-bit values of transit LSPs.
22.9 Redundancy and resilience

The ISAM supports ECMP for IP (non-MPLS) routed packets. In case there are
multiple equal-cost paths to the same peer PE, that is, there are multiple equal-cost
LSPs to reach the PE, a single LSP will be selected out of that set for sending MPLS
traffic.
This selection is done per SDP binding, that is, per PW. In this way, traffic from
different services sent on different PWs can still be sent over different LSPs towards
the PE. This enables service-based load balancing of upstream traffic.

NT
The following failures can be protected:

• Failure of an Access Node uplink: this is achieved by relying on MPLS protection
using active/standby LSPs and the use of MPLS Fast Reroute (when the ISAM
acts as an LSR).
• Failure of the Aggregation Node connected to the Access Node: this is also
achieved by relying on MPLS protection using active/standby LSPs.
• Failure of a PE node that terminates the PWs that are initiated on the Access
Node. This can be covered by means of active/standby PWs in a VPLS
configuration. When the primary peer PE fails, packets will be sent to the
secondary peer PE using the standby PW.
The current system allows MPLS support in a duplex configuration, that is, with two
NT boards. This is supported in combination with static routing or dynamic routing via
OSPF.
Control traffic (that is, LDP), L2 VPN data traffic and IP traffic can be
received/transmitted on the links of both NT boards.
22.10 Support for MPLS rings

Traditionally, rings have been used in order to protect against a link or node failure,
by allowing traffic to use the other half of the ring as a backup path. This approach
has been used for a long time, using a variety of different technologies (for example,
SDH/SONET, Ethernet Spanning Tree / Multiple Spanning Tree).
Rings of Ethernet Access Nodes could use RSTP / MSTP in order to recover from a
link or node failure. Unfortunately the xSTP algorithm is not designed for ring
networks and will give a poor switchover performance due to slow re-convergence.
To overcome this limitation, MPLS can be used to establish connections over the ring
of Access Nodes. LDP can be used on ISAM to establish Label Switched Paths in
Access Rings.
By using RSVP-TE, an operator can pre-provision one or more backup paths, the
so-called “detour LSPs”, that provide protection in case of a failure. Next, whenever
an Access Node detects a local failure, it can use MPLS Fast-ReRoute (MPLS FRR)
to send traffic over the detour LSPs. This provides a very fast local failure detection
process, much faster than with xSTP.
The basic principle is shown in Figure 320.

NT
Figure 320 MPLS switchover principles
eLER eLER
iLER iLER
Optimized
path
Local
switchover
Step 1: wrapping Step 2: Make-Before-Break (MBB)
- Using detour LSPs to guide traffic around the link failure - Re-optimize path to avoid traffic loops
- Very fast, local protection - Improves bandwidth usage and QoS
In Step 1, Fast ReRoute is used to recover from the failure. Once this has been done,
the node that detected the failure will inform the ingress LER (usually by means of
RSVP-TE Path Error messages).
This is the trigger for the ingress LER to calculate a new optimal path and reconfigure
the network to use a different LSP. This process is called “Make-Before-Break”,
referring to the principle of first establishing the new path and afterwards performing
the switchover to this path. By doing so, the outage in the second step can be
minimized or even completely avoided.
22.11 Support for MPLS flow label

In some cases an operator wants to have the flexibility to identify different sub-flows
within one Ethernet Pseudo Wire. This is possible by means of an “MPLS Flow
Label”, as defined in IETF draft-ietf-pwe3-fat-pw. The MPLS Flow Label (also
referred to as “Hash Label” or “Entropy Label”) allows LSR nodes in a network to load
balance labeled packets in a more granular fashion than would otherwise be possible
by only hashing on the standard label stack. Instead, by taking the MPLS Flow Label
into account in the hashing algorithm, load balancing within a Pseudowire becomes
possible. This also removes the need to have an LSR inspect the payload below the
label stack to check for an IPv4 or IPv6 header.
The ISAM can insert an MPLS Flow at the bottom of the label stack in packets
forwarded over an LSP. The value of the label is the result of the hashing of the
packet headers. The ISAM hashing routine assigns the same label to all packets
within the same conversation. This ensures that when an LSR load balances the
packets over multiple ECMP paths or multiple paths over a LAG network, packet
ordering is kept within a conversation.

NT
The MPLS flow label insertion/removal can be configured per SDP binding.
To support insertion / removal of the MPLS flow label, the NANT-D CB NT board
variant is required.
In addition to the NANT-D CB board variant, flow label insertion/removal is also
supported on the NCNC-H. This NTIO board can be freely combined with any of the
existing NANT-D or NANT-E NT boards.
22.12 Supporting integrated voice services over

MPLS
The ISAM Voice (ISAM-V) allows the conversion of a legacy voice service (for
example, POTS) into a VoIP service (H.248 or SIP-based), thereby moving to an
integrated packet-based network.
In current deployment scenarios, the ISAM-V connects to the packet-based
aggregation network by means of an Ethernet interface.
When migrating to an MPLS-based access network, operators need to be able to
support legacy voice services over the same MPLS-based access network. This can
be done by:
• Subtending:
The ISAM-V shelf is subtended to a hub ISAM which operates as an MPLS LER.
The ISAM-V continues to operate as in the present non-MPLS network, while the
hub ISAM performs the necessary interworking to send the ISAM-V traffic onto an
MPLS pseudowire.
• Adding ISAM-V cards into an MPLS-enabled ISAM by using:
• SIP Distributed IP addressing model
Each voice LT board is assigned a different IP address. The Network Termination
board simply bridges the signaling and RTP traffic via a VPLS service.
• SIP Centralized IP addressing model
All voice LT boards share the same IP address for RTP and/or for signaling traffic.
The Network Termination board performs L3/L4 routing using a Virtual Router (VRF).
This VRF is connected to a “VLAN VPLS” (V-VPLS) service instance, which in turn
connects to a full VPLS service instance to encapsulate the traffic into an MPLS
pseudowire.
• H.248 model
All voice LT boards share the same IP address for RTP and/or internal signaling
(XLES) traffic. The Network Termination board performs L3/L4 routing using a Virtual
Router (VRF). This VRF is connected to a V-VPLS service and a VPLS service.
Additionally, when sending traffic to/from the NVPS card, the same V-VPLS and
VPLS service instances are used to bridge the (internal) signaling and the RTP traffic
from the NVPS card onto the MPLS pseudowire.
It is possible to provide a combination of the above models when needed for a

specific deployment.

NT
In order to achieve the last configuration (that is, supporting a VRF on top of a
V-VPLS (doing L3 forwarding), which in turn is connected to a VPLS (doing the
MPLS encapsulation/decapsulation)), the operator needs to associate the V-VPLS
and the VPLS to the same physical port using SAPs with different encapsulation
values. The port itself must be placed in loopback, so that packets are sent from the
V-VPLS SAP to the VPLS SAP and vice versa.
The port chosen to be placed in loopback can be any of the faceplate ports of either
the NT or the NTIO board. As a consequence, this port can no longer be used for
external network connectivity.
Note — When using a faceplate port on an NTIO, the loopback

configuration can be performed, even when this NTIO is not
physically equipped in the system (but only “planned” in the
system configuration).
22.13 Supporting MPLS and VLAN Traffic on

"Hybrid Port"
To address MPLS support for business customers along with a VLAN Based
connectivity model for residential customers on the same NT/NTIO port, "Hybrid"
Mode provides additional capabilities on the Access Node in terms of deployment.
Specifically a mix of Service Access Point (SAP) and Service Distribution Path (SDP)
ports on the same Access Node uplink interface is provided.
The support matrix to enable residential bridge and Layer 3/MPLS based business
models is:
• Enable MPLS and Ethernet L2 services simultaneously
• Enable IES routed and MPLS services simultaneously
A Single NT/NTIO Physical and LAG port supports Layer 2, Layer 3(IPv4 and IPv6)
and MPLS simultaneously by inheriting properties of the Network mode and Access
mode on "Regular Ports".
VLAN Tagged traffic needs to be unique with corresponding SAPs and services (IES,
VPRN, VPLS or EPIPE). The existing services on Network ports (Regular and
Residential) will continue to be supported under "Hybrid" Mode.

System Description for FD 100/320Gbps NT and FX ATM Pseudowire emulation
NT
23 ATM Pseudowire emulation

23.1 Introduction
23.2 Solution description
23.3 Cell concatenation
23.4 QoS
23.5 Known restrictions
23.6 Support on the ISAM
23.1 Introduction
When migrating from an ATM-based access network to an Ethernet packet-based
access network, operators are faced with the challenge to maintain their existing
ATM-based services. Many ATM services are based on AAL5 encapsulation (that is,
these services are packet-based) and are rather straightforward to migrate by
terminating the AAL5 layer in an Ethernet Access Node. However, also
non-AAL5-based ATM services are commonly used, in which case this is not
possible. Moreover, an operator offering wholesale services to 3rd party service
providers has no view on the legacy ATM services that are used by the wholesaler.
The ISAM supports ATM Pseudowire (ATM PWE3) technology on a number of
ADSL2plus and SHDSL LT boards. This enables the transport of legacy ATM
services over a packet-based access network.

The ATM Pseudowire network architecture is shown in Figure 321.

ATM Pseudowire emulation System Description for FD 100/320Gbps NT and FX
NT
Figure 321 ATM Pseudowire network architecture

Protocol stack
ATM
VLAN or S-VLAN
PWE3
MPLS Pseudowire
VLAN
IP DSLAM ATM PVC
PWE3 in N:1
8/35 mode with N > 1
80/32
PWE3 GW
Residential
8/35
80/33
Aggregation Network
8/35
80/32
80/34 80/33
80/34
8/35 90/32
OLO with shared
90/32
bandwidth
9/40 90/33 90/33

8/35 VLAN A 90/34
90/34
92/32
92/32 92/33
8/35
OLO with dedicated
bandwidth/business
92/33 93/33
8/36
8/35 93/33 94/33
8/35 94/33
PWE3 in N:1
mode with N = 1
The “ATM Pseudowire” feature is based on IETF RFC 4717, and is also referred to
as ATM Pseudowire Emulation Edge to Edge (ATM PWE3). In this mode, the ISAM
can receive upstream ATM traffic from DSL subscribers and encapsulate this traffic
into one or more ATM Pseudowires sent over an MPLS tunnel towards the
aggregation network. On the other side of the network, a Pseudowire Gateway (for
example, the Nokia 7750) terminates the ATM Pseudowires from several ISAMs and
aggregates the traffic on one or more STM-1 interfaces connected to the ATM core
network.
In downstream direction, the PWE3 Gateway encapsulates the received ATM traffic
into the corresponding ATM Pseudowires, and sends them in MPLS tunnels towards
the different ISAMs. The ISAM terminates the MPLS tunnels and ATM Pseudowires,
extracts the ATM cells and sends them on the correct DSL line.
The feature co-exists with the standard ISAM L2 forwarding behavior, that is, on the
same ISAM LT board some user ports can be configured as regular Ethernet / AAL5
lines while other user ports can be configured for ATM Pseudowire handling.
Each ATM Pseudowire can be configured to either carry traffic from a single ATM
PVC or from multiple ATM PVCs:
• “N-to-One mode, with N=1”: the ATM Pseudowire only carries traffic from a single
ATM PVC. Each ATM Pseudowire packet either contains a single ATM cell, or
multiple ATM cells all using the same VPI/VCI
• “N-to-One mode, with N>1”: the ATM Pseudowire carries traffic from multiple ATM
PVCs. Each ATM Pseudowire packet either contains a single ATM cell, or multiple
ATM cells using the same or different VPI/VCIs

System Description for FD 100/320Gbps NT and FX ATM Pseudowire emulation
NT
In order to establish the MPLS tunnels and ATM Pseudowires, the ISAM supports
the necessary commands to configure the connections.
It should be noted that the ATM Pseudowire functionality is supported on the DSL LT
board, with no intervention of the NT card. As a result of this, each DSL LT board
which offers ATM Pseudowire services will have to be configured with one or more
separate IP interfaces and MPLS tunnels. This increases the total number of MPLS
tunnels at the system level. For instance, if each DSL LT board would be configured
with one MPLS tunnel, then there will be 16 MPLS tunnels at system level.
23.3 Cell concatenation

In case each ATM cell is encapsulated in a separate ATM Pseudowire packet, the
additional overhead of the MPLS header can become very high, making the solution
less bandwidth efficient. To avoid this, it is possible to group multiple ATM cells into
a single ATM Pseudowire packet. This “cell concatenation” feature reduces the
encapsulation overhead, making the solution more bandwidth efficient.
The maximum number of ATM cells that may be concatenated into a single ATM
Pseudowire packet can be configured. Up to eight cells can be concatenated.
Configuring a high value of cell concatenation could result in putting an additional
transmission delay on the ATM cells, since the ATM Pseudowire packet would only
be sent out once the ATM Pseudowire packet has been filled up to its maximum
number of concatenated cells. To avoid excessive transmission delays, the
maximum additional transmission delay that may be put on the ATM cells can be
configured. When the configured transmission delay is reached, the ATM
Pseudowire packet will be sent out, regardless of whether or not it contains the
maximum number of concatenated cells.
23.4 QoS
The QoS implementation is based on the regular DSL LT QoS framework. All QoS
features are packet-based, not ATM cell-based. QoS is based on the use of the
Ethernet priority bits and the MPLS Exp bits. This means there is no ATM QoS, no
cell-based QoS, and no F4/F5 termination. Different service types can be defined
which are identified with different Ethernet p-bits or MPLS Exp bits. This allows
mixing Residential/shared bandwidth and Business/dedicated bandwidth services
over the ATM Pseudowires.
When mapping ATM cells into an ATM Pseudowire packet, the ISAM supports
setting the p-bits and MPLS Exp bits of those packets according to a two-rate Three
Color Marker. Policing can be done on a combination of the Committed Information
Rate (CIR) and the Excess Information Rate (EIR).
In downstream direction, color-aware RED can be applied to the different queues, in
order to discard traffic with a relative lower priority.

ATM Pseudowire emulation System Description for FD 100/320Gbps NT and FX
NT
23.5 Known restrictions

The MPLS control plane is not supported. In other words, MPLS tunnel and ATM
Pseudowire configuration needs to be provisioned rather than signaled.
Note — Please consult the Customer Release Notes for
additional details concerning the restrictions of the ATM
Pseudowire Emulation implementation.
23.6 Support on the ISAM

The ISAM supports configuring ATM Pseudowires (ATM PWE3) in combination with
the NANT-D Network Termination board.
Note that the ATM Pseudowire functionality is independent of the MPLS functionality
supported on IHub-based NT boards. In other words, it is perfectly possible to
configure the ATM Pseudowire functionality on the DSL LT boards, and continue to
use Ethernet switching on the NT board.

System Description for FD 100/320Gbps NT and FX Application Intelligence Platform
NT
24 Application Intelligence Platform

24.1 Introduction
24.3 Benefits
24.4 Support in ISAM
24.5 Functionality on Application Intelligence Platform
24.1 Introduction
The ISAM high-capacity NT cards (NANT-E and FANT-F) introduce the ISAM
Application Intelligence Platform (AI Platform), as a generic capability for hosting
applications in the ISAM.
The AI Platform enables the ISAM base node functionality to be enhanced with
future, generic or customer specific application level functionalities.
Target fields for enhanced application level functionality in ISAM may exploit the
location and unique knowledge and control of the access node for such value-add
features as active and passive traffic/triple play QoE monitoring, service assurance,
troubleshooting agents, management and provisioning helper agents, virtualization
of home network functions, and so on.
Dedicated applications on the ISAM AI Platform may be developed by Nokia or by
Nokia customers and/or third parties, in cooperation with Nokia.
For any proposals on porting application level functionality on the ISAM AI Platform,
please contact your local Nokia sales representative.

The ISAM AI Platform leverages the NANT-E/FANT-F NT hardware. Specifically,
NANT-E and FANT-F feature dedicated processing resources, reserved for
applications: dedicated CPU cores, as well as dedicated partitions in DRAM and
flash memories, and dedicated full duplex 10Gbps interface bandwidth into the
central IHub switch (Figure 322).

Application Intelligence Platform System Description for FD 100/320Gbps NT and FX
NT
Figure 322 AI platform hardware resources
NT on-board processor
Flash RAM
ISAM ISAM AI platform & Apps

SW SW Linux OS
core0 core1 core2 core3
Packet dispatcher
core0/core1 10Gbps to core2 and 3

interfaces
IHub
Network
NANT-E/FANT-F
NT board
LTs
The AI Platform can be enabled on a live ISAM node. It provides a management

framework for downloading and installing applications on the AI Platform, networking
them to the ISAM forwarder(s) and starting/stopping them, all under ISAM operator
control. The AI Platform also provides facilities for health monitoring, alarms and
system recovery.
Optionally, applications may be managed and provisioned through their own MIB,
reachable through the ISAM public management IP address, using a separate
SNMP community string/context identifier, or by application-specific CLI extensions
through a Telnet into the AI Platform from the ISAM CLI prompt. Applications may be
supported in AMS through dedicated AMS plug-ins. Alternatively, the model where
application management and provisioning is decoupled from the ISAM/AMS
management framework, is also fully supported.
The AI Platform offers an SMP linux OS to applications.
Applications on the AI Platform can exchange packets with subscriber and network
sides through the ISAM forwarders. Applications can also be defined as the target of
an IHub port mirror.
In addition, applications can retrieve and/or control ISAM state through the SNMP
protocol.

NT
The concept and design of the ISAM AI Platform is such that applications running on
the AI platform will not impact the operation of the base node in terms of stability and
performance. This is enabled by virtue of dedicated processing resources for
applications, isolated from the ISAM core forwarding and control functions, as well
as by careful design and testing of the interfaces between applications and the core
ISAM.
In this way, the AI Platform enables the life cycle of applications to be fully decoupled
from the release cycle of the ISAM base software, meaning that applications can be
updated without a dependency to the ISAM base release.
Applications will be made available as separately downloadable executables, with an
independent life cycle (see Figure 323).
Figure 323 ISAM Applications life cycle management
AI Platform Software on core0&1 AI Platform Software on core2&3
• Manage AI platform • Start/stop/restart application instances
• Download&install applications on AI platform • Bind network interface to application instances
• Enable external communication • (optional) Application Management (SNMP/CLI)
• (optional) Application Management relay (SNMP/CLI)
ISAM Rx.y
Application Utilities
AI platform
Application_1
subject
to
ISAM licensing
Application_n
ISAM Applications
(individually downloadable executables)
= versioned
24.3 Benefits
Benefits of the ISAM AI Platform include:
• Enabling applications to make use of the location and unique knowledge and
control of the access node.
• Leveraging cost-effective and industrially rated hardware, as well as centralized
platform management, for hosting applications.
• Dedicated hardware resources and carefully controlled interfaces between
applications and the core ISAM, ensuring stability and security of the core ISAM
functions.

NT
• Base system control over hosted applications, such as application download and
install, start and stop, access to ISAM forwarders, health monitoring and recovery.
• Application life cycle management, fully decoupled from the ISAM base release,
enabling agile fast-track application development and shorter life-cycles for
applications.
24.4 Support in ISAM

The ISAM AI Platform is supported on NANT-E and FANT-F NT boards equipped
with 4 GB of compact flash.
The ISAM AI Platform is supported in combination with any access flavor (xDSL,
PTP, GPON and TWDM-PON) and any ISAM LT.
24.5 Functionality on Application Intelligence

Platform
This chapter describes the functionality on the AI Platform
24.5.1 Network Address and Port Translation (NAPT)

The ISAM supports dynamic Network Address Port Translation (NAPT) function on
the application intelligence platform. NAT is a technology that is mapping one IP
address space into another by modifying the network address in the header of the IP
datagram. NAT is widely used in following cases:
• to solve the shortage of public network addresses
• to hide the private network from a public network
NAPT is the terminology used in RFC2663. Normally, when an IP datagram is
transmitted from a private network to a public network, the source IP address will be
modified. Multiple private network addresses are mapped to a single public network
address (N:1 mapping). NAPT uses the private network address and port information
bundle (TCP/UDP) to make sure the return packet can be correctly forwarded to the
intended destination.
Note — only IPv4 NAPT is supported

NT
24.5.2 Dynamic Host Configuration Protocol (DHCP)

Server
The ISAM supports DHCP server functionality on the application intelligence
platform. It is usually used to assign private network addresses for the ONT
management interface. The ONT management can be established on top of IP
connections such as connecting to a TR69 ACS server/bulk data collector server.
It can also be linked with NAPT functionality to set up an end-to-end IP path from a
private network towards a public network.
Note — only a continuous IP address pool is supported and

only one IP pool can be configured.

NT

System Description for FD 100/320Gbps NT and FX Cross-domain solutions
NT
25 Cross-domain solutions
25.1 Overview
25.2 Mobile backhaul
25.3 E1/T1 Leased Line Replacement (SHDSL/PON)
25.4 E1/PRA Interfaces on ISAM
25.5 Ethernet Business Access over ISAM
25.6 ISAM Backhaul (Rural DSL, Ultra-high Broadband)
25.7 Hospitality solution
25.8 Open Community Broadband for Smart Communities
25.1 Overview
This section provides a description of various applications for which the ISAM
provides an effective solution.
25.1.1 Mobile Backhaul

Fixed operators and converged fixed/mobile operators can benefit from leveraging
cost-optimized residential broadband access infrastructure for backhauling traffic
from mobile base stations. The ISAM access node, in cooperation with dedicated cell
site devices fulfills the requirements for backhaul of 2G/3G and LTE base stations in
terms of bandwidth, TDM/ATM/ETH service delivery, high availability, QoS and base
station synchronization; for data as well as for mission critical voice services, and this
for the range of DSL, GPON and point-to-point fiber access technologies.
25.1.2 E1/T1 Leased Line Replacement

Legacy E1/T1 leased line services can be converged over the modern IP DSLAM.
This allows to decommission legacy line systems or ATM DSLAMs. The ISAM
access node, in combination with a pseudowire capable device at the business
premises fulfills the requirements for leased line replacement in terms of bit error
rate, delay, availability and synchronization.

Cross-domain solutions System Description for FD 100/320Gbps NT and FX
NT
25.1.3 Ethernet Business Access

Access and service providers are migrating the delivery of business access services,
originally dominated by TDM and ATM-based offerings, to Ethernet access. This
migration is driven mainly to achieve converged access and aggregation networks,
thereby reducing CAPEX and OPEX. In a fully converged access network, we expect
residential-, business- and mobile backhaul customers to be served from the same
access node. The ISAM, in conjunction with a portfolio of CPEs/NTU/ONTs is
equipped with best-in-class features to fulfill the requirements for Ethernet business
access services, and this over a choice of copper and fiber access technologies.
25.1.4 ISAM Backhaul (Rural DSL, Ultra-high Broadband)

The ISAM (remote or CO) relies on the availability of Gigabit Ethernet fiber to provide
uplink network connectivity. In some cases this fiber is not available. This is typically
the case in rural areas or emerging and developing countries. But this is also true for
industrialized countries having fiber-dark-spots. For both cases a solution can be
proposed allowing broadband deployment with ISAM in all areas. For rural areas and
industrialized areas different bandwidth requirements apply and hence different
architectural solutions can be proposed.
25.1.5 Hospitality solution

To remain competitive in their market segment many hoteliers are looking to increase
the overall guest experience in their hotel. The ISAM can provide triple-play and
enhanced media applications in the hotel guest room, conference rooms, lobby, and
so on, by leveraging on the existing copper wiring (Cat3). The existing Cat3 wiring,
currently used for Voice (PABX), can be enabled with xDSL without rewiring or other
labor cost.
25.1.6 Open Community Broadband for Smart

Communities
The aim of the Open Community Broadband solution is to offer a very flexible
wholesaling framework allowing sharing of access and aggregation infrastructure by
multiple service providers allowing end-users to pick-and-play in flexible and
on-demand way.
25.2 Mobile backhaul

This section provides information about mobile backhaul.

NT
25.2.1 Scope
This section describes solutions for backhaul of 2G/3G and LTE mobile base stations
over 7302 ISAM, 7330 ISAM FTTN or 7360 ISAM FX.
Mobile backhaul over (bonded) ADSL2plus, over (bonded) SHDSL, over (bonded)
VDSL2, over point-to-point Ethernet (FE/GE) and over GPON is included, covering
solutions for data off-load as well as full backhaul of voice and data.
Apart from the 7302 ISAM, 7330 ISAM FTTN or 7360 ISAM FX node, the solution
also proposes the cell site devices (residential DSL CPE/ONT, dedicated DSL
CPE/ONT for business/mobile backhaul, 7705 SAR-F/7705 SAR-M) for which the
solution is validated.
Apart from this, an end-to-end mobile backhaul solution also requires an aggregation
network and a gateway device that interfaces to the mobile gateways. These are not
specified here. Please refer to the Nokia Mobile Backhaul Blueprint Solutions for a
description of Nokia end-to-end mobile backhaul solutions.
25.2.2 Introduction
Mobile backhaul (mobile backhaul) is about transporting traffic between mobile base
stations (2G BTS, 3G NodeB, LTE eNodeB) and a centralized mobile gateway (2G
BSC, 3G RNC, LTE S-GW).
Mobile backhaul comes from a legacy of 2G base stations, carrying low volumes of
traffic (voice and low BW data) and backhauled over a TDM (PDH/SDH) network,
with first mile access to the TDM network typically over 1 or 2 copper (or microwave)
E1/T1. The TDM network inherently provided synchronization as well as resilience
and QoS for mission critical services.
With the growth of data services in 3G and LTE, traffic volumes are increasing rapidly
and exponentially and mobile operators need more bandwidth fast. On the other
hand, mobile ARPU is more or less flat and consequently there is pressure on the
cost per bit, also for backhaul. The legacy TDM backhaul infrastructure cannot scale
in a cost effective way.
The following evolutions are happening:
• transition from copper (and TDM microwave) to fiber (and packet microwave) in
mobile backhaul access, at a pace allowed by investment levels
• transition from TDM transport to packet transport (carrier Ethernet, IP/MPLS)
• convergence of residential/business/mobile backhaul over a common transport
infrastructure (the High Leverage Network)
In this context there is a clear incentive for fixed access operators to leverage
residential broadband assets (existing or new rollouts) for mobile backhaul.

NT
Using broadband access technologies for mobile backhaul allows to re-use existing
outside plant (copper and GPON feeder fiber). Moreover, broadband access
technologies (DSL, GPON, point-to-point Ethernet) are existing, cost optimized
platforms and will enable significantly reduced port cost per mobile base
station/mobile site.
25.2.3 Technical challenges

The following technical challenges arise when leveraging broadband access
infrastructure for mobile backhaul:
25.2.3.1 Bandwidth
Mobile backhaul bandwidth requirements have evolved from 1-2 E1/T1 (2-4Mbps)
for a 2G site to more than 250Mbps for a full blown multi-provider, multi-generation
2G/3G/LTE site.
With respect to this bandwidth evolution, the different broadband access
technologies can be positioned as follows:
• (bonded) ADSL2plus and (bonded) SHDSL can be positioned as short-to-mid
term tactical solutions for 3G bandwidth relief. For example, 4-pair bonded
g.SHDSL.bis can support symmetrical bandwidth up to 22.8 Mbps. ADSL2plus
deployment will in practise be limited to data off-load, while SHDSL can and will
typically be used in full off-load scenarios (*). For SHDSL, ATM IMA and EFM
bonding are preferred for reasons of resiliency (if one pair goes down, the group
will not be impacted). Of the two, EFM bonding is superior with respect to
bandwidth efficiency, provisioning and flexibility in data rates for the different
pairs.
• With bandwidths of, for example, ~ 400/100 Mbps downstream/upstream at
500m, 250/50 Mbps downstream/upstream at 1000m for 8-pair bonded VDSL2,
bonded VDSL2 is a strategic, rather than a tactical solution for evolution to and
including LTE. VDSL2 could be deployed in off-load scenarios but definitely have
full backhaul as the final goal (*).
• GPON and point-to-point fiber are full-blown solutions capable of supporting all
scenarios to LTE. Again, GPON and point-to-point fiber could be deployed in
off-load scenarios but definitely have full backhaul as the final goal (*).
Note — (*): See section “QoS and High Availability for mission
critical traffic” for distinction between data off-load and full
backhaul.
Access node features: Physical layer interfaces, DSL bonding.

NT
25.2.3.2 TDM/ATM/Ethernet service delivery

2G base stations have TDMoE1 interfaces. 3G base stations can come in any of 3
flavors: all ATM IMAoE1, hybrid ATM IMAoE1 (for voice) and Ethernet (for data), all
Ethernet. LTE base stations have all Ethernet interfaces. Typically, 2G/3G/LTE base
stations will be collocated on a single site and will be backhauled over a common
access link.
Transport of TDM and ATM services over a packet network (potentially along with
Ethernet service) requires the use of pseudo wires (PWE3 TDM/ATM/Ethernet
pseudo wires for IP/MPLS, MEF-8 TDM pseudo wire for Carrier Ethernet). Pseudo
wires are typically set up between by a dedicated cell site gateway (CSG) device at
the cell site and a peer device at the mobile controller site.
Access node features: Transparent for the access node.
25.2.3.3 Synchronization
Base stations with legacy E1 interfaces need frequency synchronization for the
purpose of TDM transport (that is, to avoid frame slips).
All base stations also need frequency synchronization for the purpose of providing
an accurate wireless carrier frequency.
In addition, TDD (time division duplex) base stations need phase synchronization for
the TDD mechanism to operate. FDD (frequency division duplex) systems may also
need phase synchronization for specific advanced wireless features like MBMS and
network MIMO, but deployment of these must be considered longer term and is of no
immediate concern.
Base stations can be synchronized in multiple ways:
• using a synchronized E1/T1 from a TDM network (frequency synchronization
only)
This is the synchronization method in the legacy TDM network. It is also the
synchronization method in a data off-load approach, where synchronization (and
voice) remain to be transported by the TDM network, but data is off-loaded to the
packet network.
• using an on-site GPS (frequency and phase synchronization)
This is the synchronization mechanism in CDMA and will most likely be the first
synchronization mechanism in TDD and FDD deployments requiring phase sync.
• using synchronization from the packet network
These synchronization methods classify in 2 flavours:
• Physical layer mechanisms
These provide end-to-end synchronization on the physical layer. Several physical
layer synchronization mechanisms are standardized: NTR for DSL, GPON PHY for
GPON, SyncE for Ethernet.
• Packet layer mechanisms

NT
These include NTP, 1588v2 point-to-point, ACR, DCR. Of these, 1588v2 is the more
forward looking with evolution to provide phase synchronization as well as frequency
sync.
In contrast to packet layer mechanisms, physical layer mechanisms are inherently

deterministic and insensitive to network traffic load conditions and QoS design.
It is recommended to use physical layer synchronization mechanisms whenever
available. For instance, BITS or SyncE into the ISAM in CO and physical layer
synchronization (NTR, GPON PHY, SyncE) from there to the business site. If no
BITS or SyncE is available in CO, we recommend to terminate 1588v2 in an external
client in the CO, to feed the output of that client into the BITS of the ISAM and to go
with physical layer synchronization from there.
Access node features:
• NT with BITS/SyncE/1588v2 in
• DSL NTR/GPON PHY/SyncE on the last mile.
25.2.3.4 QoS and High Availability for mission critical traffic

Today, mobile operators have mission critical voice services running over a TDM
backhaul network, with stringent guarantees for loss, delay, jitter and availability
provided by the PDH/SDH network.
By no means should these guarantees be impacted when moving to a packet based
backhaul.
A conservative approach is to move into a data off-load scenario as a first step: voice
and synchronization remain on the TDM network, whereas high volume data traffic
(with less stringent QoS requirements) is off-loaded to the packet network.
In the full backhaul scenario, the mobile backhaul solution needs to provide QoS and
High Availability inherently.
• The ISAM access node, being already engineered for triple play services is well
positioned to provide differentiated QoS for mobile voice and data traffic streams
of varying nature, also in competition with residential and business traffic in the
same node.
• In terms of High Availability, prime concerns are focused on the network links and
- elements that aggregate a (large) number of base stations and less so on the
first mile. For these links/nodes, High Availability is taken care of by either
IP/MPLS mechanisms (possibly initiated from an IP/MPLS capable cell side
device) or carrier Ethernet mechanisms, or a mixture thereof. Dual homing of the

NT
access node to the aggregation network is essential for protecting the second mile
(with LAG or xSTP) and the first aggregation node (with multi-chassis LAG or
xSTP).
For PON access, ISAM provides enhanced Type-B protection shortly in a future
release.
DSL bonding inherently provides a level of resiliency for a first mile over bonded
DSL.
Figure 324 High availability: points of failure

ISAM dual uplinks with LAG,
multi-chassis LAG, mSTP
ISAM NT
redundancy
TDM
ATM AGG GTW
ETH
CSG AN L2 aggregation
AGG GTW
Base station Controller
inherent redundancy in DSL bonding
IP/MPLS or Carrier
Ethernet repair mechanisms

• QoS (as for triple play)
• NT redundancy
• dual homed ISAM uplinks (with LAG, multi-chassis LAG or xSTP)
• transparent for IP/MPLS based redundancy (handled in the cell site gateway
and/or in the IP/MPLS core)
• enhanced Type-B protection (future release)
• inherent redundancy in DSL bonding (for ATM IMA and EFM).
25.2.3.5 Demarcation
End-to-end OAM features and SLA monitoring (including the first mile) are typically
handled by the cell site gateway device, either by IP/MPLS mechanisms or by carrier
Ethernet mechanisms. 802.1ag and Y.1731 can be used between the cell site device
and the gateway device for end-to-end checks of connectivity, loss and delay, either
on a continuous basis or on-demand. Optionally, 802.1ag MEPs and MIPs can be
placed in ISAM for further troubleshooting and fault isolation.

NT

• Transparent for end-to-end IP/MPLS OAM and 802.1ag/Y.1731 OAM.
• Optional 802.1ag MIP/MEPs in the access node for troubleshooting.
25.2.4 Solution description

Figure 325 shows the different access options for mobile backhaul over ISAM and
the associated cell site gateway portfolio.
Figure 325 Mobile backhaul cell site device portfolio
ADSL2+ CPE (o)
1-2p ADSL2+
rd
3 party SHDSL CPE
1-4p SHDSL
1-4p SHDSL + 1-2p xDSL
SAR-M combo 2p VDSL2

CellPipe 5Ve.A4010 (o)
7302/7330 ISAM
2-8p VDSL2 or 2p ADSL2+
SAR-M xDSL
point-to-point Ethernet (FE|GE) (o) offload only
SAR-M/SAR-F
Data ONT (o)
GPON
SAR-M GPON
Business ONT
Low-end residential type DSL CPEs/ONTs (ADSL2plus, 7130 Cellpipe VDSL2),

indoor/outdoor ONT are low-cost solutions for data off-load of 3G base station
Ethernet interfaces (for base stations with hybrid ATM/Ethernet interfaces).
Dedicated 3rd party SHDSL CPEs for business/mobile backhaul can be positioned as
mid-range solutions for full backhaul of TDM, ATM and Ethernet services over
(bonded) SHDSL.
The Business ONT is a mid-range solution for off-load and full backhaul of TDM and
Ethernet services over GPON. The Business ONT is MEF8 pseudowire based.
7705 SAR-F (fiber uplink) and 7705 SAR-M (with modular uplink of fiber), GPON,
2-8pair bonded VDSL2, 4-pair bonded SHDSL + 2-pair bonded ADSL2plus (SAR-M
combo) are high-end solutions for off-load and full backhaul of TDM, ATM and
Ethernet services. 7705 SAR-F and 7705 SAR-M are IP/MPLS based.
Figure 326 shows the logical end-to-end topologies for mobile backhaul between
multiple mobile base stations and a centralized mobile controller.

NT
Figure 326 Mobile backhaul end-to-end-topologies (logical)

IP/MPLS
TDM TDM
ATM ATM
ETH ETH
CSG AN AGG L2 tunnel (IP/MPLS) GTW

PWE3 IP/MPLS pseudowire (TDM/ATM/ETH)
Mixed
TDM TDM
ETH ETH
CSG AN AGG L2 tunnel (IP/MPLS) GTW

MEF8 PW (TDM) + raw Ethernet
Carrier Eth
TDM TDM
ETH Carrier Ethernet ETH
CSG AN AGG GTW

MEF8 PW (TDM) + raw Ethernet
The solution components are:

• A cell site gateway (CSG) that performs media adaptation between the base
station interfaces (TDMoE1, ATM IMAoE1, Ethernet) and the first mile physical
layer (DSL, GPON, point-to-point FE/GE) and initiates pseudo wires when
applicable. In addition, it can perform synchronization and demarcation functions
when applicable. On the network side, the cell site gateway can be either
IP/MPLS based (TDM/ATM/Ethernet PWE3 pseudo wires) or Ethernet based
(raw Ethernet + TDM MEF8 pseudo wires).
• The access node (AN) is typically operated in L2 transparent VLAN cross-connect
mode for mobile backhaul, with each cell site gateway or service cross-connected
to the first aggregation node.The access node is typically shared with residential
and possibly other business users.

NT
• The aggregation network can be carrier Ethernet based or IP/MPLS based. In the
latter case IP/MPLS from the cell site gateway is typically tunneled in a L2
IP/MPLS service. A flat IP/MPLS model is also possible in principle, but requires
hybrid (access/MPLS) interfaces on the first aggregation node.
• A controller side Gateway Device (GTW), peering with the cell site gateway on the
pseudo wire level and interfacing to the mobile controller(s) over TDM STM-x,
ATM STM-x or Ethernet interfaces.
Access nodes can be dual homed to redundant aggregation nodes and mobile
controllers can be dual homed to redundant gateway devices for High Availability
purposes.
Figure 327 and Figure 328 show the physical layer synchronization architecture of
ISAM.
Figure 327 ISAM physical layer synchronization architecture (DSL and
point-to-point)
BITS G.703 SHDSL.bis PHY NTR E1

FE/GE (SAR-M)
SHDSL
GigE FE/GE unsynchronized
LT 3rd party CPErd
SyncE 7705 SAR-M (3 party CPE)
Base station interface

NT
VDSL2 PHY NTR E1
FE/GE
VDSL2
LT
7705 SAR-M
Optical GE SyncE E1
FE/GE
PTP
GE LT
7705 SAR-M
8 kHz
backplane Optical GE SyncE Optical GE SyncE
to 7354 REM direct connection to base station
7302/7330 ISAM
Figure 328 ISAM physical layer synchronization architecture (GPON)
BITS G.703 E1
GPON
GigE ODN
LT
SyncE FE/GE
Business ONT
unsynchronized
Base station interface
NT 8 kHz
backplane
E1
7302/7330 ISAM
FE/GE
7705
SAR-M

NT
Physical layer synchronization can be fed into ISAM either via BITS or via SyncE
from the network through synchronization-capable dedicated NT variants. If no BITS
or SyncE is available in the CO, we recommend to terminate 1588v2 in an external
client in the CO, to feed the output of that client into the BITS of the ISAM and to go
with physical layer synchronization from there.
Synchronization can then be propagated over the first mile to a
synchronization-capable cell site gateway through a physical layer mechanism:
SHDSL NTR, VDSL2 NTR, GPON PHY or SyncE (GE point-to-point LT board).
Finally, the cell site gateway provides synchronization to the base station either
through a synchronized E1 or through a SyncE interface.
The physical layer synchronization entails frequency synchronization only.
Apart from physical layer synchronization, the Business ONT also provides ACR and
DCR clock recovery mechanisms.
25.3 E1/T1 Leased Line Replacement

(SHDSL/PON)
This section provides the scope and introduction information about E1/T1 leased line
replacement including technical challenges.
25.3.1 Scope
This section describes solutions for emulation of (E1/T1) leased line services with
access over ISAM:
• over SHDSL, using 3rd party SHDSL CPEs (single or multiple E1/T1 interface).
• over GPON, using the Business ONT (up to four E1/T1 interfaces)
In principle, E1/T1 leased lines can also be emulated over point-to-point ethernet
access, with a dedicated fiber CPE.
25.3.2 Introduction
Operators may benefit from consolidation of legacy (E1/T1) leased line services on
broadband access equipment rolled out for residential (and business) services.
This may allow them to, for example, decommission dedicated line systems for
(E1/T1) leased line access. It may also be an element in an ongoing
decommissioning (partial or full) of the legacy TDM network in favour of a packet
switched network.

NT
25.3.3 Technical Challenges

This section provides information for technical challenges such as leased line
emulation, symmetrical bandwidth, KPIs for loss and delay, synchronization, and
high availability feature solutions.
25.3.3.1 Leased line emulation

TDM pseudo wire technology is used for emulation of (E1/T1) leased line services
over a Packet Switched Network (PSN). Structured and unstructured E1/T1 can be
transported using RFC 4553 SAToP (Structure Agnostic TDM over Packet) and RFC
5086 CESoPSN (Circuit Emulation Service over PSN) encapsulations respectively.
The TDM pseudo wire can be transported over Ethernet (MEF8), over MPLS, or over
MPLS/GRE.
In this solution, TDM pseudo wires are set up between a dedicated device on the
customer premises (3rd party SHDSL CPE, Business ONT) and a peer device (either
a peer CPE or Business ONT on another customer site or a centralized device
interfacing to the core TDM network, usually over STM1/STM4).
25.3.3.2 Symmetrical bandwidth

Physical layer bandwidth requirements for transporting an E1/T1 will depend on the
encapsulation type (Ethernet, MPLS) and the TDM payload size in the pseudo wire,
but will amount to more than 2 Mbps symmetrical per E1/T1. In practise, for copper
access this (together with delay and synchronization requirements) rules out
ADSL2plus in favour of SHDSL. Bonded SHDL links, as well as SHDSL repeaters
can be used to increase the reach of SHDSL segments for leased line replacement.
ATM IMA and EFM bonding are preferred for SHDSL for reasons of resiliency (if one
pair goes down, the group will not be impacted). Of the two, EFM bonding is superior
with respect to bandwidth efficiency, provisioning simplicity and flexibility in data
rates for the different pairs.
25.3.3.3 Key Performance Indicators (KPIs) for loss and

delay
The legacy TDM network guarantees stringent requirements for loss and delay for
TDM traffic. These cannot be impacted by moving to an emulated service over a
packet switched network under load (in competition with residential and other
business services).
The ISAM access node, being already engineered for triple play services (including
loss sensitive video and delay/jitter sensitive voice) is well positioned to provide low
loss/low delay guarantees.

NT
SHDSL is a low latency technology that complies to delay requirements for leased
line, and so is GPON.
Tuning of the payload size and de-jitter buffer size of the pseudowire allows to meet
delay and loss requirements under background network packet delay variation
(PDV).
Both ends of an E1/T1 leased line connection need to be synchronized to avoid
frame slips in the TDM transport (that is, wander needs to comply to the ITU-T G.823
traffic mask).
This solution assumes a network clock is imposed upon the customer TDM
equipment.
For leased line emulation, the clock reference has to be distributed through the
packet network. As discussed in the mobile backhaul section, this can be done via
physical layer mechanisms (SHDSL NTR, GPON PHY, SyncE) or via packet layer
mechanisms (NTP, 1588v2 PTP, ACR, DCR).
It is recommended to use physical layer synchronization mechanisms whenever
available. For instance, BITS or SyncE into the ISAM in CO and physical layer
synchronization (NTR, GPON PHY, SyncE) from there to the business site.
If no BITS or SyncE is available in the CO, we recommend to terminate 1588v2 in an
external client in the CO, to feed the output of that client into the BITS of the ISAM
and to go with physical layer synchronization from there.
• NT with BITS/SyncE/1588v2 in
• SHDSL NTR/GPON PHY on the last mile.
25.3.3.5 High Availability

In terms of High Availability, prime concerns are focused on the network links and
network elements that aggregate a (large) number of customers and less so on the
first mile. For these links/nodes, High Availability is taken care of by either IP/MPLS
mechanisms (possibly initiated from an IP/MPLS capable business CPE) or Carrier
Ethernet mechanisms, or a mixture thereof. Dual homing of the access node to the
aggregation network is essential for protecting the second mile (with LAG or xSTP)
and the first aggregation node (with multi-chassis LAG or xSTP).
For PON access, ISAM provides enhanced Type-B protection shortly in a future
release.
DSL bonding inherently provides a level of resiliency for a first mile over bonded DSL.

NT

• NT redundancy
• dual homed ISAM uplinks (with multi-chassis LAG or xSTP), transparent for
IP/MPLS based redundancy (handled in business CPE)
• inherent redundancy in DSL bonding (ATM IMA and EFM).

Figure 329 shows the access components for a leased line replacement solution
over (bonded) SHDSL and GPON.
Figure 329 Access components for E1/T1 leased line replacement
3 rd party SHDSL CPE
1-4p shdsl
1-4 * E1/T1 (+ Eth)
GPON
4* E1/T1 (+Eth)
7302/7330 ISAM
Business ONT
3rd party SHDSL business CPEs provide circuit emulation for a single or multiple
E1/T1 (possibly in conjunction with Ethernet access) over SHDSL (single pair
g.SHDSL at max 2.3Mbps Mbps up to 4-pair EFM bonded g.SHDSL.bis at max 22.8
Mbps). The pseudo wire encapsulation is IP/MPLS with static MPLS labels. SAToP
and CESoPSN encapsulations are supported.
The Business ONT provides circuit emulation for up to 4 E1/T1 (possibly in
conjunction with Ethernet access) over GPON. The pseudo wire encapsulation is
MEF-8. SAToP and CESoPSN encapsulations are supported.
Figure 330 shows the logical end-to-end topologies for leased line emulation
between 2 business customer sites.

NT
Figure 330 End-to-end topologies for E1/T1 leased line emulation
TDM pseudowire (MEF-8 or IP/MPLS)
E1 CPE/ Aggregation CPE/ E1

ONT AN AN ONT
(ETH, IP/MPLS)
Customer Customer
TDM equipment TDM equipment
TDM pseudowire (MEF-8 or IP/MPLS)
E1 CPE/ Aggregation(*) CES SDH E1

ONT
AN GTW
ADM
(ETH, IP/MPLS)
Customer Customer
TDM equipment TDM equipment
(*): optionally, AN could also directly connect to CES GTW in CO
Two connectivity models can be envisaged and will possibly be deployed in parallel:
• A business CPE/ONT connected back-to-back over an end-to-end pseudo wire to
a peer business CPE/ONT, without crossing an SDH/PDH segment.
• A business CPE/ONT connected over a pseudowire to a core SDH/PDH network
(typically groomed over an STM1/STM4 interface). The pseudo wire could cover
the access segment only (with the pseudo wire terminated and dropped on TDM
equipment in the CO). Alternatively, it could span the full metro Ethernet
aggregation network (TDM equipment in a centralized PoP location).

• A business CPE/ONT that performs media adaptation to the access technology
(SHDSL, GPON) and initiates/terminates the TDM pseudo wire(s). It will also
perform synchronization functions.
• The access node (AN) is typically operated in L2 transparent VLAN cross-connect
mode for leased line emulation, with each business CPE cross-connected to the
first aggregation node.The access node is typically shared with residential and
possibly other business and mobile backhaul users.
• The aggregation network can be carrier Ethernet based or IP/MPLS based. In the
latter case IP/MPLS from the cell site gateway is typically tunneled in a L2
IP/MPLS service. A flat IP/MPLS model is also possible in principle, but requires
hybrid (access/MPLS) interfaces on the first aggregation node. See
section “Mobile Backhaul” for more details on the aggregation options.
• A CES gateway device (CES GTW) (not present in the back-2-back scenario),
peering with the TDM core network.

NT
Access nodes can be dual homed to the aggregation network and SDH equipment
can be dual homed to redundant gateway devices for High Availability purposes.
In this solution, the customer TDM equipment is timed by the network clock. In the
second connectivity model, this is also the clock of the core TDM network. As per the
Nokia synchronization strategy, an end-to-end physical layer synchronization is
preferred. This means that physical layer synchronization is fed into ISAM either via
BITS or via SyncE from the network through synchronization capable dedicated NT
variants.
If no BITS or SyncE is available in the CO, we recommend to terminate 1588v2 in an
external client in the CO, to feed the output of that client into the BITS of the ISAM
and to go with physical layer synchronization from there.
Synchronization can then be propagated over the first mile to the business CPE/ONT
over SHDSL NTR/GPON.
Finally, the business CPE/ONT provides a synchronized E1/T1 to the customer TDM
equipment.
25.4 E1/PRA Interfaces on ISAM

This section provides the scope and introduction information for E1/PRA interfaces
on ISAM including technical characteristics and a solution description.
25.4.1 Scope
This chapter describes the ISAM capabilities to terminate E1 TDM lines or ISDN PRA
(PRI) on an ISAM faceplate port. A similar approach is taken as in the previous
section “E1/T1 Leased Line Replacement (SHDSL/PON)”but with this difference that
we are not using a CPE or ONT to terminate the E1 but an SFP (Small Form-factor
Pluggable) instead. The E1 or the ISDN PRA is directly terminated on the ISAM. The
ISAM can be in a central office location or in a remote outdoor cabinet.
The E1 TDM SFP is terminating the TDM circuits and carrying the TDM data via
Ethernet packets through the ISAM and across a packet switched network (i.e. using
pseudowire technology). We are NOT referring to Trunking Gateway functionality
where PSTN data is converted into VoIP.
25.4.2 Introduction
The SFP (SmartSFP) used in this solution is a dual-channel TDM SFP, capable of
terminating up to two E1 ports. The SFP is MSA compliant and fits into a standard
Gigabit Ethernet SFP cage.

NT
Figure 331 Dual-Channel TDM Pseudowire SFP
E1
SFP cage
VLAN ECID PAYLOAD
CES
CES
E1 VLAN ECID PAYLOAD
RJ45 GE
shielded
connector
Via its build-in TDM pseudowire interworking function (CES), the SFP is
encapsulating/extracting TDM traffic into/from Ethernet packets. The Metro Ethernet
Forum standard (MEF-8) payload format and pseudo-wire (PW) technology is used
to allow interoperability with third-party CES interworking devices.
Figure 332 E1/PRA Termination (pseudowire) in ISAM: MEF8 interworking
Using an SFP-based approach provides a flexible and scalable solution for legacy
interfaces on the ISAM. No dedicated board is required, it is a port-based solution:
any GE SFP port can be converted in an E1/PRA port by plugging in the E1 TDM PW
SFP.
Fully integrated in the ISAM management system, the E1 TDM PW SFP can be
provisioned and monitored via ISAM TL1 and through the 5520 AMS.

NT
25.4.3 Technical characteristics

This section describes the technical characteristics of E1/PRA Interfaces on ISAM
including information about line termination, pseudowire capabilities,
synchronization, alarms, service diagnostic capabilities, performance monitoring
using E1 CRC4 checks, and TDB pseudowire packet loss detection.
25.4.3.1 Line termination

The E1 TDM PW SFP is a dual-channel SFP capable of terminating two independent
tributaries. Each tributary has its own pseudowire to transport its TDM data across
the packet switched network.
The connector type of the SFP is a shielded RJ45 connector which is standard pin
compliant for a single E1. If two E1 needs to be terminated on the RJ45 connector a
dedicated Y-split cable is required to terminate the 2nd E1.
The E1 line impedance can be configured to 75Ω or 120Ω. An unbalanced (Coax) or
balanced (RJ45) cable is provided according the requested line/impedance type.
The TDM line interface supports both framed (LOF and CRC4 checks only) and
unframed E1.
Depending on the distance requirement the receiver sensitivity can be configured for
Short Haul or Long Haul applications.
25.4.3.2 Pseudowire capabilities

As shown in Figure 331, a pseudowire is applied per tributary. The pseudowire is
constructed according to the implementation agreement for the emulation of PDH
circuits over Metro Ethernet Networks (MEF8).
Although the line interface framer supports both framed and unframed lines, the
pseudowire encapsulation is structure-agnostic. The TDM payload is backhauled
transparently via the pseudowire over the packet switched network.
Due to the structure-agnostic emulation only, DS0 grooming or fractional E1
backhaul is not supported.
The tributary pseudowire will be uniquely identified via its circuit-identifier in
compliance with MEF8. Dedicated VLAN, CoS priority, source and destination MAC
addresses can be configured per pseudowire (per tributary) if required.

NT
To meet the TDM wander requirements (per ITU-T G.823), both ends of the
pseudowire connection need to be synchronized.
Different options exist to provide an end-to-end solution to synchronize the
interconnected circuits (E1/PRA). The solution requires a PRC-traceable network
clock to be provided to the E1 TDM SFP. There are several ways in providing the
network clock (derived from PRC) to the SFP. This is depending on the node (NT)
features where the SFP is residing. Depending on the controller type of the ISAM,
the NT can be synchronized via BITS, SyncE or IEEE1588v2. Through the
backplane clock circuit, all boards in the shelf are being synchronized. The
synchronization of the SFP itself is done via SyncE (SERDES) to provide the network
timing from the NE (ISAM).
The network clock can be imposed upon the customer TDM network, both tributaries
of the SFP can be synchronized from the SFP (host) clock which is derived from the
network clock via SyncE, as described above.
Alternatively, the SFP can take one of the E1s as clock source.
The 2E1-SFP solution in ISAM does not support the transport of the E1 service clock
across the packet network.
An overview of the different synchronization options in an end-to-end solution is
provided in Figure 333.
Figure 333 E1 TDM SFP, End-to-End Synchronization options

NT
25.4.3.4 Alarms
E1 and TDM related alarms detected by the SFP are autonomously reported to the
ISAM and AMS. On request the operator can also retrieve the active alarms on the
SFP through the ISAM.
Depending on the configuration of the E1 line interface, whether in framed or
unframed mode additional alarm detection and reporting is supported. In unframed
mode, the SFP supports LOS and AIS detection. In the framed mode, the SFP can
also detect RDI, REI, LOF, LOMF and CRC4 bit failure on top of the LOS and AIS.
Besides the alarm detection and reporting, the SFP allows also the forwarding of
alarms, either towards the network via circuit emulation (MEF8) or towards the line
interface (E1). The forwarding of alarms can be configured per alarm (AIS, RDI and
REI) and for each direction (network or E1) independently.
25.4.3.5 Service diagnostic capabilities

Loopbacks
The 2E1-SFP supports different type of loopbacks. Loopbacks can be activated in
both, E1 and packet network direction. In each direction, loopback points can be set
on different places on the SFP, e.g. framer only, including the pseudowire
interworking function or not. The following loopback options are supported:
• Loopbacks towards E1 (see Figure 334):
• Loopback towards E1 line interface without including the framer function
• Loopback towards E1 line interface, including the framer function
• Loopback towards E1 on SGMII, including the framer and CES IWF.
• Loopbacks towards packet network (see Figure 335):
• Loopback towards Ethernet network, passing the CES IWF, without including the
framer
• Loopback towards Ethernet network, passing the CES IWF and including the framer
• Loopback towards Ethernet network on SGMII. This loop will be in front of the CES
IWF and only does the MAC address swap on the pseudowire packets.
• Loopback on SERDES towards Ethernet network, not passing any function of the
SFP.
Figure 334 2E1-SFP loopback towards E1 (including framer)

FRAMER
SERDES
ETH-ITF
CESoP
SGMII
(IWF)
LIU
E1 ISAM (PSN)

NT
Figure 335 2E1-SFP loopback towards network (including framer)
FRAMER
SERDES
ETH-ITF
CESoP
SGMII
(IWF)
LIU
E1 ISAM (PSN)
Performance monitoring via E1 CRC4 checks

For framed E1 the 2E1-SFP can perform bit error monitoring through CRC4. When
the CRC4 check is activated, the SFP will raise a CRC4 alarm when a frame with bad
CRC has been received.
An additional CRC4 threshold alarm is raised when the bad CRC4 frame count
reaches a certain threshold (currently set to 915 frames).
TDM Pseudowire packet-loss detection
The 2E1-SFP has ability to detect packet-loss on the pseudowire. A time window (in
msec) can be configured in which packet-loss is being monitored.
In case a loss of packet is detected a LOS (from IWF) is asserted. When in the same
window no packet-loss is detected anymore, the LOS alarm is de-asserted.
A specific packet-loss LOS alarm is supported per tributary pseudowire.

The picture below illustrates possible deployment scenarios. In summary, the E1
TDM SFP based solution:
• Is providing a flexible pluggable solution: pay as you grow
• Leverages on existing ISAM and Ethernet based aggregation/service network for
TDM (V)LL for TDM service/network migration resulting in CAPEX and OPEX
savings.
• Is a scalable solution: SFP based, no need for dedicated board which consumes
a full slot.
• Supports solid synchronization through Synchronous Ethernet
• Is fully integrated in the ISAM provisioning system and element manager (5520
AMS)
• Is ITU (E1) compliant
• Uses MEF8 encapsulation ensuring transparency to any TDM networking
protocol

NT
Figure 336 Solution Description ISAM E1/PRA backhaul
25.5 Ethernet Business Access over ISAM

This section provides the scope and introduction information about Ethernet
business access over ISAM including information for technical challenges and
solution descriptions.
25.5.1 Scope
This section describes solutions for Ethernet business access over ISAM:
• Over (bonded) SHDSL, using a 7230 BG 3Se Series Cellpipe CPE, 1521 CLIP,
7705 SAR-M(E) combo or a third party SHDSL business CPE/NTU at the
customer premises.
• Over point-to-point ethernet, using the ISAM Gigabit Ethernet LT board + 1522
FLIP, 1850 TSS-3, 7705 SAR-F/SAR-M(E) or a third party fiber business
CPE/NTU at the customer premises.
• Over GPON, using an indoor or outdoor data ONT at the customer premises.
25.5.2 Introduction
Access and service providers are gradually migrating the delivery of business access
services, originally dominated by TDM and ATM-based offerings, to Ethernet access.

NT
This migration is driven mainly to achieve converged access and aggregation

networks, thereby reducing CAPEX and OPEX. In a fully converged access network,
we expect residential-, business- and mobile backhaul customers to be served from
the same access node.
The ISAM, in conjunction with a portfolio of CPEs/NTUs/ONTs is equipped with
best-in-class features to fulfill the requirements for Ethernet business access
services, and this over a choice of copper and fiber access technologies.
25.5.3 Technical Challenges

This section describes the technical challenges for Ethernet Business Access over
ISAM including information for bandwidth, Ethernet business service delivery, high
availability, QoS, and OAM (including SLA monitoring).
25.5.3.1 Bandwidth
Ethernet business access subscribers may have bandwidth requirements varying
anywhere from a few Mbps up to 1Gbps. A scalable solution tailored to the bandwidth
needs is required. Bandwidth requirements for Ethernet business access are mostly
symmetric (except for business internet access).
ISAM provides high symmetrical bandwidth over SHDSL by means of g.SHDSL.bis
(up to 5.7 Mbps per copper pair over 3km nominally) and g.SHDSL.bis bonding (up
to 8 pairs for ATM IMA; up to 4 pairs for PTM (providing a bandwidth of 22.8 Mbps
nominally)). Of the bonding flavors, ATM IMA and PTM bonding are preferred for
reasons of resiliency: if one pair goes down, the group will not be impacted. Of the
two, PTM bonding is superior with respect to bandwidth efficiency, provisioning
simplicity and flexibility in data rates for the different pairs.
With GPON and point-to-point Ethernet, ISAM can provide bandwidth scaling up to
hundreds of Mbps and 1Gbps respectively.
• g.SHDSL.bis and SHDSL bonding
• GPON
• Gigabit Ethernet LT
25.5.3.2 Ethernet Business Service Delivery

The Ethernet business services that this solution covers include:
• L2 VPN (E-LINE, E-LAN, E-TREE)
• L3 VPN
• Business Internet Access (BIA)

NT
In each of these service models, the function of the business CPE/NTU/ONT and the
access node is to provide a layer 2 access spoke to an aggregation network
implementing the layer 2 service (L2 VPN) or connecting to the layer 3 router (L3
VPN, BIA).
Figure 337 Ethernet Business Service Delivery
inter-metro
CPE L2 VPN
ETH
or AN AGG L2 aggregation inter-metro
NTU
L3 VPN
Customer
router internet
BIA
L2 access segment L2 aggregation
virtual line or virtual LAN
carrier Ethernet or IP/MPLS
Ethernet business services may be offered with varying levels of functionality and
quality; from low-end basic connectivity to high-end service delivery governed by
stringent SLAs.
For L2 VPNs (and in extrapolation also for the layer 2 access to L3 VPN and BIA
services), the Metro Ethernet Forum (MEF) provides a framework for the definition of
layer 2 services at the UNI between the customer equipment and the service
provider, and this for all but the more basic connectivity services.
MEF Service Requirements at the UNI (MEF6.1, MEF10.2) specify such things as:
• Service types: E-LINE, E-LAN, E-TREE.
• Service multiplexing and service selection: all:1, 1:1, n:1 VLAN mapping.
• Transparency for customer frames (VLANs, MTUs, L2CP, multicast/broadcast
and so on)
• Layer 2 control protocol (L2CP) handling: discard, tunnel, peer
• Ingress and Egress bandwidth profiles and - rate limiting.
Service Requirements at the UNI (MEF of other) can be implemented by either of two
architectures:
• In the UNI model, the UNI requirements are implemented by the access node LT
board. The customer premises device connecting to the customer router can be
a simple CPE or media convertor with basic functionality.
• In the NTU model, the UNI requirements are implemented by a dedicated,
operator managed NTU/ONT at the customer premises. The NTU/ONT has
enhanced demarcation features over a simple CPE/media convertor and is
possibly MEF-certified. The access node should be transparent in this model.

NT
Figure 338 Implementing service requirements at the UNI

UNI model
UNI
Customer site
UNI-N
ETH
CPE/MC AN L2 aggregation
Customer
router
NTU model
UNI
Customer site
UNI-N
ETH
NTU AN L2 aggregation
Customer
router
As a particular instance of the service requirements at the UNI, full transparency for
customer frames is required for particular L2 VPN service delivery models (for
example, Ethernet private lines). Transparency requirements may pertain to such
features as preservation of customer VLAN tags (including 802.1q p-bits), support of
customer MTUs, transparency for multicast/broadcast and for L2CP protocols that
the customer wants to use to manage his network end-to-end (like LACP, (m)STP
and so on).
ISAM implements full transparency for customer frames, by making use of
transparent VLAN cross-connect forwarding mode.
Alternatively, ISAM can initiate an IP/MPLS based VLL providing full transparency.
• UNI model: transparent VLAN cross-connect (1:1, tunneling mode, mapping
mode) or MPLS PE (VLL), L2CP handling (discard, tunnel), MTUs, ingress rate
limiting
• NTU model: transparency of VLAN cross-connect or MPLS PE (VLL)
25.5.3.3 High availability

In terms of high availability of the Ethernet business service, prime concerns are
focused on the network links and elements that aggregate a (large) number of
customers (ISAM node and ISAM uplinks, aggregation nodes and aggregation links,
edge routers implementing L3VPN or BIA, GPON feeder), and less so on the first
mile.

NT
Figure 339 High Availability: points of failure

ISAM dual uplinks with LAG,
multi-chassis LAG, mSTP
ISAM NT
redundancy
AGG
CPE/
NTU AN L2 aggregation
AGG
Customer
router
IP/MPLS or Carrier
Ethernet repair mechanisms

• NT redundancy
• dual homed ISAM uplinks
• Ethernet based redundancy (with LAG, multi-chassis LAG or xSTP)
• IP/MPLS based redundancy (LSP path redundancy, pseudowire redundancy)
• inherent redundancy in DSL bonding (ATM IMA and EFM bonding).
25.5.3.4 QoS
Business services come with more or less stringent SLAs governing QoS KPIs of
bandwidth, loss, delay and jitter for the service or services presented at the UNI. In
general, business traffic will have to compete with residential traffic (and possibly
mobile backhaul traffic) running in the same access node.
The ISAM access node, being already engineered for triple play services is well
positioned to provide differentiated QoS for business traffic streams of varying
nature, also in competition with residential and mobile traffic in the same node.
Access node features: Ingress policing/color marking, four queues per port, QoS
marking.
25.5.3.5 OAM, including SLA monitoring

Stringent SLAs on Ethernet service availability (% availability, maximum time to
restore, and so on) require that operators have tools for connectivity fault monitoring
and -troubleshooting.
Also, business access customers may require SLA monitoring and SLA reporting
(availability, loss, delay, jitter).

NT
In carrier Ethernet, 802.1ag/Y.1731 connectivity fault monitoring and its Y.1731

extensions for performance monitoring provide the means for above OAM functions,
while IP/MPLS has its own dedicated OAM tools.
• Transparency for end-to-end 802.1ag/Y.1731 OAM PDUs
• Optional 802.1ag MIP/MEPs in the access node for troubleshooting
• LSP ping/traceroute and VCCV ping for MPLS PE

Figure 340 shows the solution components for Ethernet business access over
(bonded) SHDSL, point-to-point Ethernet and GPON using ISAM 7302/7330/7360.
Figure 340 Ethernet Business Access Portfolio
1-4p SHDSL
1521 CLIP
rd
or 3 party SHDSL NTU/CPE
1-4p SHDSL + 1-2p xDSL
SAR-ME combo
point-to-point Ethernet (FE|GE)
1850 TSS-3
7302/7330 ISAM
or 1522 FLIP
or 3rd party fiber NTU/CPE
point-to-point Ethernet (FE|GE)
SAR-ME fiber
or SAR-F
Data ONT
GPON
SAR-ME GPON
Low-end SHDSL CPEs are low-cost solutions for basic ethernet business access
services, using UNI-N functionality of the ISAM SHDSL LT board.
1521 CLIP, 7705 SAR-ME combo and dedicated 3rd party SHDSL NTUs can be
positioned as mid-range to high-end solutions for SHDSL access in an NTU
architecture.
1522 FLIP, 1850 TSS-3, 7705 SAR-F, 7705-SAR-ME fiber, and dedicated 3rd party
fiber NTUs can be positioned as mid-range to high-end solutions for fiber access in
an NTU architecture.
Simpler 3rd party fiber CPEs/media convertors can be positioned, using UNI-N
functionality of the ISAM GE LT board.

NT
The Nokia indoor or outdoor residential type data ONT, or a more feature-rich 7705
SAR-ME GPON is positioned for GPON access.
For the logical end-to-end topologies for Ethernet business services (L2VPN,
L3VPN, BIA), see Figure 337.
• A customer router that connects to the L2 VPN/L3 VPN/BIA service. The
customer router is beyond the responsibility of the business access provider.
• A provider managed NTU at the customer premises, or a simpler CPE/media
convertor.
In the NTU model, the service selection is fully performed by the NTU, adding a
per-service VLAN. The NTU also performs other UNI-N functions (L2CP handling,
ingress rate limiting …) as well as non-UNI-N functions required for service
assurance (connectivity monitoring, SLA monitoring …).
• The access node (AN) cross-connects customer traffic, either to a per-service
VLAN or to a per-service MPLS VLL.
In the NTU model, this is a 1:1 cross-connect of the service VLAN added by the
NTU. In both VLAN cross-connect mode and MPLS VLL mode, full transparency
for customer frames is assured.
In the UNI model, the service selection (all:1, 1:1, n:1) is performed by the ISAM
LT board, along with other UNI-N functions.
The aggregation network implements either a point-to-point service (E-LINE) or a

LAN service (E-LAN). This L2 aggregation function is valid, both for a L2 VPN service
as for the L2 aggregation function towards a L3 edge router implementing a L3 VPN
or BIA service. Local bridging/VPLS in ISAM is not required to implement an E-LAN
service. Instead, a L2 spoke through the CPE/NTU and ISAM to the first aggregation
node can be implemented, while the aggregation network takes on the E-LAN
functionality.
The aggregation network can be either carrier Ethernet or IP/MPLS. In the case of
IP/MPLS based aggregation, the first aggregation router performs the MPLS PE
function. Alternatively, the MPLS PE function can be further distributed into the
access node.
For L3 VPN and BIA services, an edge router at a PoP location takes on the L3
functions and is fed by the L2 aggregation network. The L3 function could also be
distributed.
In terms of high availability, the access node can be dual homed to a single
aggregation node or to redundant aggregation nodes (with LAG, multi-chassis LAG
or xSTP for an Ethernet access node, with LSP path redundancy for an MPLS
access node).
The aggregation network is protected by either carrier ethernet or IP/MPLS based
resiliency mechanisms with no dependency on the access segment.
Access to resilient L3 edge routers is either handled by the customer router or by the
L2 aggregation network and has no dependency on the access segment.

NT
For SHDSL, ATM IMA bonding and PTM bonding inherently provide a level of
resiliency for the first mile.
In terms of QoS, the ingress bandwidth enforcement (optionally including color
marking) is performed by the NTU in the NTU-model and by the ISAM LT board in
the UNI-model. The regular ISAM QoS features enable differentiated treatment of
business traffic in competition with residential and mobile traffic inside the node as
well as correct marking of packets for further QoS treatment in the aggregation
network (upstream) or in the NTU (downstream).
In terms of OAM, end-to-end monitoring of the business access service (including the
first mile) is typically handled between an NTU at the customer premises and either
a peer NTU (for L2 VPN) or the edge router at the PoP location (for L3 VPN, BIA).
802.1ag and Y.1731 can be used for end-to-end checks, either on a continuous basis
(connectivity fault monitoring, SLA monitoring) or on-demand (troubleshooting). The
ISAM should be transparent for end-to-end 802.1ag/Y.1731 PDUs. Optionally,
802.1ag MEPS and MIPS can be placed in ISAM for further troubleshooting and fault
isolation.
For MPLS PE in the access node, LSP ping/traceroute and VCCV ping can be used
to troubleshoot the MPLS segment of the service.
25.6 ISAM Backhaul (Rural DSL, Ultra-high

Broadband)
This section provides introduction and solution description information for ISAM
backhaul including information for bandwidth, transparency, service differentiations,
resiliency, and Ethernet bridging converter options.
25.6.1 Introduction
The absence of fiber may not be blocking for remote ISAM deployments. Also in
fiber-poor areas, ISAMs for DSL broadband access can be deployed. Taking the
approach of backhauling the fiber-link (point-to-point Gigabit Ethernet) by an
alternative transport technology leaves no further constraints deploying the ISAM in
rural areas or other markets where the exclusive use (dark-fiber) of fiber is not
possible to connect the ISAM.
Depending on the market, available regional or national infrastructure or customer
requirements, we can distinguish possible domains:
• Rural areas (Broadband for all)
• Early/fast deployments in emerging markets re-using legacy (incumbent) network
• Re-use of high-capacity national infrastructure
• Complementing fiber based FTTN deployment

NT

The base of the solution is finding the best way for backhauling the Gigabit Ethernet
fiber link. The choice of the backhaul transport technology is depending on the
backhaul distance, the available infrastructure to leverage upon, regulations (for
example, in the case of wireless backhaul options) and required throughput.
The backhaul is accomplished by using a converter which converts the optical
Gigabit Ethernet transport layer into another Ethernet based transport layer
(illustrated by Figure 341). The new transport layer consists of a physical layer
depending on the available infrastructure and a data-layer supporting the transport
of Ethernet frames. Depending on the different physical layers different framing
options apply: EFM (G.SHDSL), GFP (Generic Framing Procedure ITU-T G.7041),
HDLC (High-level Data Link Control ISO-13239, ML-PPP (Multi-Link Point-to-Point
Protocol RFC-1990), …
Figure 341 ISAM fiber backhaul
Optical Remote / Cabinet Location
Central Office / Aggregation
Distribution
Location
Network
7330 ISAM FTTN

ODF
7302 ISAM CO
ISP 1
7354/7324 ISAM RU
Aggregation Active Optical
Network Network
ISP 2 7330 ISAM CO
7356 ISAM REM
7330 ISAM RA
Ethernet
7357 ISAMSEM
Corporations
and Residences
Remote / Cabinet Location

Central Office / Aggregation
Backhaul option
Location
7330 ISAM FTTN
7302 ISAM CO
ISP 1
7354/7324 ISAM RU
Converter
Converter
Aggregation
Network Transport
ISP 2 Network
7330 ISAM CO
7356 ISAM REM
7330 ISAM RA
Ethernet
7357 ISAMSEM
Corporations
and Residences

NT
A converter will be required at the Central Office location and at the Remote/Cabinet
location. These converters can be point-to-point, where one Ethernet link
corresponds to one link in the transport network or they can be point-to-multipoint
where Ethernet frames are bridged between one Gigabit Ethernet link on the ISAM
side and multiple transport links on the backhaul network side (for example,
ML-PPP).
25.6.2.1 Bandwidth
In many cases the backhaul transport network cannot offer the full 1 Gbps
connection which is supported on the ISAM product family. This is typically not an
issue for rural areas where the number of remote subscribers to be served are limited
per rural site with a limited total amount of bandwidth need, or for emerging markets
where connectivity with a rather limited bandwidth is the primary requirement. An
assessment must be made on a case-by-case base to see whether the network
capacity is sufficient in the backhaul transport network for the target end-user
services (Voice, High Speed Internet, and so on). Possibly, multiple links need to be
bundled to increase the bandwidth.
In industrialized countries with subscriber dense areas and high bandwidth per user
(for example, 20 Mbit/s), where typically fiber is being used for FTTN deployments,
higher capacities are required for the backhaul link. The backhaul approach is taken
for those locations which cannot be served by fiber (fiber black spots) to obtain 100%
user coverage with ISAM based broadband access.
25.6.2.2 Transparency
The backhaul connection between the remote ISAM and CO ISAM must provide a
transparent Ethernet service. The bridging function between the network port of the
ISAM (uplink and/or subtended link) and the backhaul transport network can be done
by an external converter. The converters and backhaul transport network must
ensure that, both the remote ISAM and the CO node, are able to extract the original
frames sent by the other side, in the same order as they were sent, that is, no
frame-reordering or fragmentation.
25.6.2.3 Service differentiation

ISAM deployments in a backhaul scenario, and especially in those cases with limited
backhaul capacity like rural areas, must support proper queuing and scheduling
mechanisms to provide service differentiation in both up- and downstream direction.
Voice must get strict priority over other services like Video and High-Speed Internet,
and management connectivity must be ensured at all times.

NT
Congestion is likely to occur on the backhaul link between the remote ISAM and the
CO node due to the limited available bandwidth on this link. The buffer-acceptance,
queuing and scheduling in the upstream direction on the remote ISAM and in the
downstream direction on the CO node are particularly important.
Next to the queuing and scheduling mechanisms, proper service classification must
be done on the backhaul link. At least the p-bits in the VLAN-tag should be
configurable as a means to map VLAN-tagged traffic in the appropriate queues.
To overcome congestion and eventually packet drop (high priority traffic) on the
backhaul link we can use the buffer mechanism of the ISAM, in both upstream and
downstream direction. Using the interface rate-limiting capabilities of the ISAM
network ports, uplink at the remote ISAM and subtended link at the CO node, service
differentiation can be done based on the available bandwidth on the backhaul link.
The port rate-limiting allows traffic scheduling (queue handling) to be done at a speed
(bit rate) matching the available bandwidth in the backhaul transport network. The
dimensioning of the rate-limited on ISAM network ports will depend on the
encapsulation overhead added by framing mechanism implemented on the backhaul
transport equipment (that is, converters) and the Ethernet frame sizes used by the
data services. When forwarding the Ethernet frames over the transport link, headers
and trailers are added to the Ethernet frame. This results in a lower Ethernet packet
throughput than natively supported by the backhaul link. The overhead, headers and
trailers added, depends on the encapsulation method used. Figure 342 gives an
example of the header/trailer bytes added by the GFP and HDLC encapsulation
method.
Figure 342 Encapsulation overhead GFP versus HDLC
GFP Encapsulation HDLC Encapsulation

NT
As a result the port rate-limit will be set to a rate according the supported packet
bit-rate and not to bit-rate natively (on the wire) supported by the transport network,
which can be a lot lower, depending the Ethernet frame sizes. See below an example
based on GFP-F on E1 to illustrate this.
Table 79 GFP Encapsulation overhead calculation
Framed E1 (31 Timeslots) = 1984 kbit/s

GFP-F Overhead = 12 bytes
Ethernet frame size Max throughput Overhead Rate limiter ISAM

(bytes) (kbit/s) (%) (x 64 kbit/s)
64 1670 15,83 26
128 1813 8,62 28

256 1895 4,49 29
512 1938 2,32 30
1024 1961 1,16 30
1500 1968 0,81 30
In a second step packet buffers and schedulers of the converters can be used to deal
with service differentiation when sudden bandwidth drop occurs on the backhaul link
(for example, link failure). The priority scheduler in the converter will ensure high
priority traffic (for example, voice) gets precedence over other concurrent traffic in
case of congestion. This is illustrated in Figure 343.
Figure 343 ISAM backhaul with point-to-multipoint converter
Central Office / Aggregation Remote / Cabinet Location

Location Backhaul option
PDH (nxE1)
NT NT LT
Protocol based
VLAN tag. + Pbit
Converter Converter
ML-PPP
DSL Link Policies
DSL
1
E1
VoIP VoIP
VoIP VoIP
shaping
GE UP
shaping
SP SP
NW Ctrl FE/ NW Ctrl
FE/ NW Ctrl SP SP NW Ctrl
GE ... GE
GE
WRR HSI HSI WRR
HSI HSI
E1
VoIP DOWN
NW Ctrl SP
WRR DSL
HSI 48
NT
GE
Mgmt IP
VoIP : Strict Priority 1

NW Ctrl : Strict Priority 2
HSI : Best Effort
In case of point-to-point converters (see Figure 344), the ISAM ensures the service
differentiation. Flushing the queues will be done at the rate of the available bit-rate
on the link giving precedence to the frames in the highest priority queue.

NT
Figure 344 ISAM backhaul with point-to-point converter

Central Office / Aggregation Remote / Cabinet Location
Location Backhaul option
PDH (nxE1)
NT NT LT
Protocol based
VoIP
VLAN tag. + Pbit
VoIP
shaping
SP SP
shaping
NW Ctrl NW Ctrl
DSL Link Policies

GE E1 E1 GE
WRR WRR
HSI HSI
DSL
1
VoIP VoIP
shaping
SP GE
NW Ctrl SP UP
shaping
NW Ctrl
GE E1 E1 GE
WRR
L WRR
HSI L HSI
A
A
GE G VoIP
VoIP G VoIP DOWN
shaping
shaping
NW Ctrl SP
NW Ctrl SP SP
NW Ctrl
GE E1 E1 GE
WRR DSL
WRR WRR
HSI
HSI HSI 48
VoIP VoIP
NT
shaping
SP SP
shaping
NW Ctrl NW Ctrl
GE E1
E1 GE
GE
WRR WRR Mgmt IP
HSI HSI
VoIP : Strict Priority 1

NW Ctrl : Strict Priority 2
HSI : Best Effort
25.6.2.4 Resiliency
To limit the impact of single failures, the backhaul solution should provide the
necessary resiliency at all levels of the architecture. Depending on the backhaul
transport network different resiliency mechanisms apply: ML-PPP, EFM bonding,
SDH VCAT (Virtual Concatenation), APS (Automatic Protection Switching), and so
on. On top packet based link-aggregation can be done using LACP (LAG) or path
redundancy using RSTP.
Bonding or aggregation functions do not only allow a level of resiliency but also offer
the means to provide more aggregated bandwidth on the backhaul link.
As shown in Figure 344, the LAG function of the ISAM is being used to aggregate 4x
E1 based backhaul links into one pipe. Figure 343 shows an example where the
bonding of the backhaul link is done in the transport network using ML-PPP (typically
16xE1).
The end-to-end path resiliency will only work when “fault-propagation” is supported
by the converters and any other intermediate node. Any link-failure causing a service
outage in the path must be propagated in the forward and backward direction
towards the connected ISAM. The CO ISAM will take proper measures when the
link-failure (operational down) is detected: an alternative route might be chosen
based on the implemented resiliency function (for example, LAG) and a port-down
alarm (LOS) is presented to the management system. In a non-redundant backhaul
scenario the alert should indicate that the remote site is no longer reachable.

NT
25.6.2.5 Ethernet bridging converter options

Nokia offers a wide range of products supporting different transport network options
combined with the required Ethernet interfaces and Ethernet bridging functionality.
Given the rich Nokia portfolio supporting any transport option, the ISAM can be
deployed in any environment:
• Re-using available incumbent transport infrastructure which lowers the CAPEX
investment for the remote DSLAM deployment
• Leveraging on equipment already used by the Telecom provider to have limited
OPEX impact: no new logistical processes required, re-use of in-house skills,
unified management …
• Fast go-to-market with Broadband access by providing early connectivity prior to
fiber roll-out. No DSLAM replacement is required after upgrading the network
infrastructure later on.
Figure 345 provides a high-level overview of possible ISAM configurations and

converters to provide the backhaul connectivity.
Figure 345 ISAM backhaul options
25.7 Hospitality solution

This section provides an introduction and solution description information for the
hospitality solution.

NT
25.7.1 Introduction
Many hotels and retirement homes are wired with Category3 cable which was very
popular in the 1990's. The Cat3 twisted pair is mainly used to provide hotel and public
telephony services for the hotel guests, in the room and in public areas, and the hotel
staff.
With the emergence of broadband internet access, Wi-Fi (shared) hotspots were
made available to which the hotel guest can connect. In many cases the internet
hotspot belongs to an ISP. The user connects to the internet via the user registration
portal of the ISP after paying a connection fee (pre-paid) via a credit card.
Figure 346 Standard offering for voice and internet access in hotel guest
rooms
In order to remain competitive, to increase revenue opportunities and to enrich the

guest experience, hotels need to upgrade their IT infrastructure to offer high-speed
and secure internet access, voice and multi-media applications and need to get into
the value chain.
Via similar ways a Telecom operator offers Triple play services to residential
subscribers via xDSL and IP DSLAM. The hotelier can offer IP based triple play
services to the hotel guest with xDSL provided by an IP DSLAM.
By re-using the existing Cat3 wiring for xDSL the hotelier can achieve this over the
existing infrastructure, without too costly cabling costs. So no “rip and replace” but
fully leverage on the existing infrastructure providing triple play-services. The choice
between ADSL2plus or VDSL2 depends on the length of the copper-wire and the
required data throughput.
Figure 347 Enhanced multi-media experience in hotel guest rooms with
xDSL

NT

This section describes the hospitality solution information including a high level
architecture hospitality solution, DSL and POTS in hospitality solutions, and
broadband bandwidth requirements.
25.7.2.1 High level architecture hospitality solution

The ISAM is installed in the existing telecom closet/room near the existing terminal
blocks or distribution frame.
From here DSL connectivity is provided to each room to offer voice (VoIP), video (IP
TV), high speed internet and other data services (multi-media, gaming, and so on)
using a single copper pair.
A modem (for example, ALU 7130 CellPipe gateway) distributes the services within
the hotel room by providing connectivity to STBs, VoIP or POTS phones, laptop PCs,
(personal) multimedia devices and in-room control (wake-up call, mini-bar, …).
Gigabit Ethernet interfaces from the ISAM provide connectivity to the supporting
network for the different data services, billing servers/firewalls and management
systems.
Not all hotels or retirement homes are the same. They differ not only in size, in terms
of number of guest rooms, but also in building architecture. Depending on the
building and infrastructure architecture different product solutions can be offered:
• Small to medium size hotels consisting out of one building, having a single,
centralized equipment room where all the terminal blocks are residing. In such a
case a CO ISAM or a standalone FTTN node is used to terminate the copper pairs
from all the guest rooms on one central location; see Figure 348.
• Medium to large size hotels with multiple equipment rooms (for example, on each
floor) in one building are addressed using the distributed ISAM solution. In such a
case a 7356 ISAM REM chassis can be installed at the different terminal blocks.
An aggregation node aggregates the distributed nodes via GigE optical
connections and provides a single uplink to the network; see Figure 349.
• A variant to the previous deployment scenario is with larger properties where the
hotel guest rooms are distributed over different buildings or multiple, collocated,
remote sites (for example, a campus). The same ISAM solution applies as in the
previous case; see Figure 350.

NT
Figure 348 IP DSLAM Deployment scenario for hospitality, centralized
Figure 349 IP DSLAM Deployment scenario for hospitality, distributed

(single building)

NT
Figure 350 IP DSLAM Deployment scenario for hospitality, distribute

(multiple sites)
25.7.2.2 DSL and POTS in hospitality solutions

Proven xDSL technology is used on the existing copper pair towards the guest rooms
for the IP/Ethernet based services. This copper pair is used traditionally to provide
telephony (POTS) services.

NT
Figure 351 ISAM in hospitality: triple-play high-level network topology
Two options apply:

• The existing telephony/POTS can co-exist on the same pair as the DSL services.
Voice and DSL use a different frequency band (POTS uses narrowband, DSL
broadband) on the copper wire. Splitters are used to separate the POTS from
DSL.
The DSL terminates on the DSL LT of the ISAM and POTS is further relayed to
the voice switching system of the hotel. If desired, the splitter function can be
provided by the ISAM using a dedicated POTS splitter board or a DSL LT board
with integrated splitter technology.
The same splitter technology is required on the modem side. The POTS splitter is
usually supplied via wall socket with a connector for both the POTS/analogue
phone and the modem (see Figure 351, “room 1”).
• The copper pair is used for DSL only (naked or dry-loop DSL) and the existing
telephony/POTS is replaced by a Voice-over-IP service. In this case the IP
telephony service is delivered to the guest room over the DSL connection.
This scenario does not require any splitter technology. The analogy voice is
packetized into a VoIP (RTP) stream via the DSL gateway in the guest room or a
VoIP phone set is being used (see Figure 351, “room 2 and 3"). In both cases the
VoIP is handled as any other data stream on DSL. A higher quality of service
treatment is applied to the voice, than the concurrent data streams (Internet,
IPTV, and so on) on the same DSL line.

NT
25.7.2.3 Broadband bandwidth requirements

The total bandwidth required is determined by the services offered to the hotel guest.
To a large extent the bandwidth requirements are defined by the IPTV service
offering. IPTV is recognized as a high value added service for the hotelier. Especially
with the emergence of HD TV an attractive offering for the hotel guests can be made.
The capacity required for IPTV is determined by:
• High Definition (HD) or Standard Definition (SD) TV or both (for example, SD
broadcast TV combined with HD Video-on-Demand)
• Encoding used: MPEG2, MPEG4
• Number of TVs in the room or suite.
Internet access is no longer a nice-to-have service but has become a necessity. On
top, with the use of internet for social networking, file sharing, video-conferencing,
business, and so on, internet is no longer seen as a best-effort service. Also
high-speed internet access comes with a minimum of bandwidth guarantees and
quality of service.
IP Telephony is probably the least bandwidth consuming service but requires the
highest quality of services and needs to be prioritized accordingly.
Other services are online gaming (might be part of Internet service), in-room control,
hotel camera views (for example, bar, swimming pool, and so on),
Figure 352 Hotel Room Bandwidth requirement
SD TV MPEG2 Channel: 2 - 5 Mb/s
HSI: 1 - 5 Mb/s
HD TV MPEG4 Channel: 5 - 10 Mb/s
Online gaming: 4 - 8 Mb/S
SD TV MPEG4 Channel: 1.5 - 2 Mb/s
In control room: 0.5 Mb/s
VoIP: 160 Kb/s
All the data-streams described in Figure 352 can run over a single DSL copper pair.
In the ISAM and the DSL gateway in the room the proper quality of service
provisioning is done for each of the services. Policing and rate-limiting might apply
depending on the guest profile and service package subscribed to.

NT
The available DSL bandwidth on the copper pair depends on the DSL technology
used:
• ADSL2plus with a theoretical maximum downstream bandwidth of 25 Mb/s.
• Supports longer loops than VDSL2
• Typically 15-20 Mb/s
• VDSL2 (17a profile) has a theoretical maximum downstream bandwidth of 100
MB/s
• Due to the use of higher frequencies on the copper pair the distance is limited
• Typically 25-40 Mb/s
• Virtual Noise increases stability
Other factors influencing the actual copper and therefore the bandwidth are:
• Cable type: Gauge, twisted-pair, shielding, and so on
• Distance: loop length limits, especially for VDSL2
• Bridged Taps: copper pairs that are interconnected together are causing reduced
DSL performance
• Environment Interference: air-conditioning, elevator engines, and so on
• Interference by cross-talk: caused by other services on adjacent pairs.
Global or individual DSL line settings can be applied on the ISAM to minimize the
impact of the different factors described above by configuring DSL profiles
accordingly. DSL profiles can be DSL line specific or uniform across a line card
and/or ISAM chassis.
25.8 Open Community Broadband for Smart

Communities
This section provides an introduction, OCB context, and solution information about
open community broadband for smart communities.
25.8.1 Introduction
End-user's expectations on access to Broadband connectivity are becoming nearly
as widespread as for the classic commodities (water, gas, electricity, telephony). Not
just private end-users but also businesses and local authorities need broadband
access. However, the geographical coverage by the classic operators is not total,
and not all greenfield opportunities are covered. Backed by government incentives,
more and more local authorities are considering the deployment of a
community-wide access network to fill the gaps and ensure digital attractiveness of
their locality (for social and economic reasons). This is the Smart community
concept, whereby there is a variety of levels for the “community”: building site,

NT
campus or estate, city district, and complete city. One important aspect for
attractiveness is the openness to multiple service providers, promoting service
competition rather than access competition. The applications include but go beyond
the classic triple play, also encompassing business services and specific services for
public authorities like municipalities.
The aim of the Open Community Broadband solution is to offer a way for those new
entrants to build out, deploy and manage such a single access and aggregation
infrastructure at their local level, which can then be opened to and shared by multiple
third party service providers, from which the end-users can select a mix of
applications. In other words, to offer a very flexible wholesaling framework.
The OCB solution as such comprises the passive infrastructure, the active
infrastructure, the management sub-system, and the professional services for
guidance of the local authority to roll out the infrastructure. OCB is part of the wider
context of Smart Communities, developed by Strategic Industries. The scope is
greenfield deployments, encompassing FTTH networks (point-point Ethernet and
GPON) and other flavours of FTTx depending on the case-by-case needs.
The converged ISAM can play a prominent and competitive role in the OCB solution,
by offering a variety of access technologies (point-point optical, GPON access,
FTTx) in a single platform with the necessary mechanisms to create and manage the
connectivities in an open context. Other advantages of the ISAM are port density, the
modular approach (extend-as-you-grow with LTs), and high temperature range.
25.8.2 OCB context

This section describes the open community broadband context information including
wholesaling, and roles and responsibilities.
25.8.2.1 Wholesaling
Three layers can be identified in the delivery of broadband access. The first is the
passive infrastructure (ducts, cables, fibers, splitters). The active infrastructure
consists of all network equipment, and uses the passive infrastructure for giving
connectivity between the end-users and the applications. Finally, the service layer
uses the active and passive infrastructure to deliver the applications.
In traditional networks the approach is a vertically integrated one; the different
incumbent operators integrate all layers, competing with each other on access
infrastructure and less on the services offered.
It is possible to introduce wholesaling to this situation, splitting the responsibilities
over multiple roles, to varying degrees, as illustrated in Figure 353. In the passive
wholesale case, a single passive network is shared and made accessible to multiple
vertical service providers. In the active wholesale case, a single vertical infrastructure
provider offers connectivity to multiple retail service providers (RSPs). Finally, in the

NT
most separated case, a single passive provider gives access to its infrastructure to
the active network operated by a single network operator which connects towards
multiple service providers. Note that even here a single player can combine the roles
of active infrastructure owner and service provider (by offering its own services), but
the important point is that it remains open to third party retail service providers.
Figure 353 OCB: roles and wholesaling levels
The focus of OCB lies on the full separation case.
25.8.2.2 Roles and responsibilities

As shown in Figure 354, in the fully separated case there are distinct responsibilities
at each level.
Figure 354 OCB: roles and responsibilities

NT
25.8.3 Solution description: Active architecture

This section describes the OCB solution description of the active architecture
including information about requirements, and Ethernet open access.
25.8.3.1 Requirements
The OCB network must carry residential (triple play + RF video), business (L2 VPN,
L3 VPN, Business Internet Access) and public applications (VPN, e-care, and so on)
with the corresponding levels of security, availability and QoS differentiation. It can
hence be based on existing converged network architectures for residential and
business applications (public applications can be mostly considered as business
services). There are some new requirements though with respect to existing
environments, namely the level of wholesaling and the need for an integrated
management approach:
• each end-user is able to select applications from multiple service providers
simultaneously
• the network operator can sell white label services to third-party service providers
who can then include this service next to their own into their commercial bundle
towards the end-user
• the network operator must have the management tools to operate the network,
the users and their selection of services in the most integrated possible way. A
certain level of dynamism is introduced by allowing end-users to select the
services per service provider via a self-provisioning portal.
• The network operator needs to provide the ability for Retails Service Providers
(RSP) to offer competitive and differentiating service offerings. The OCB network
has to support a very granular configuration of bandwidth and QoS per RSP per
end-user.
25.8.3.2 Architecture: Ethernet open access

The Customer Premises Network (CPN) can either consist of a CPE followed by one
RGW per RSP (delivered by the RSP), or of a CPE followed by a single RGW
(delivered by the network operator). In both cases, there is one IP address allocated
per RSP. Note that in the first case each RGW falls under responsibility of its
corresponding RSP, and that in the second case the RGW is managed by the
network operator.
The access and edge network is characterized by the following features;
• Generic:
In general the connectivity is similar to the broadband networks for residential and
business applications. As a single user can now connect to different service
providers simultaneously, the service provider separation on the first-mile is done
by means of VLAN tagging by the CPE (port-based). Traffic is further separated

NT
in the network at L2 by means of VLANs (separate broadcast domains) and at

MPLS level by means of VPLS or VLL instances. There is also a separate VLAN
and VPLS instance for the CPE management (for example, TR-069), which is fully
terminated by the network provider. At the edge of the network operator, there is
a L2 hand-off to the different service providers. In other words, there is no routing
within the network operator domain.
A new feature introduced in OCB is the self-provisioning portal, offering the
possibility for end-users to dynamically check their service subscriptions and
select specific services from the service providers they have subscribed to. The
portal is best positioned at the network operator, to consolidate the view of the
end-user on all its services (see paragraph on management subsystem).
• Specifically for residential services:
All requirements of classic triple-play deployments apply, in terms of L2 and L3
security, QoS handling, connectivity capabilities, IGMP handling, DHCP proxying,
and so on….
However, a couple of features are additionally required in the specific context of
OCB:
• the support of multiple service providers (with potentially overlapping multicast
addressing schemes) in the network, possibly also multiple multicast IPTV services
per subscriber. This must be taken into account in the multicast replication points and
in the CDRs (Charging Detailed Record) for viewing statistics.
• the QoS, access control and resource control policies in the network also have to be
applicable at per-service subscriber level.
• Specifically for business/public services:
There are no specific OCB requirements on the architecture other than the
simultaneous co-existence of multiple VPNs offered by multiple service providers.
Note that for business services there is a separation per service instance in the
access and aggregation network.
The Ethernet open access is the most straightforward deployment model in terms
of node complexity and involvement burden of the network operator (IP
auto-configuration and service configuration can be left to the service providers).
Note however that it implies a mapping of CPN (Customer Premises Network)
terminals on service providers.
Figure 355 L2 access architecture for OCB (residential user depicted with 1
RGW per RSP)

NT
25.8.4 Solution description: Management subsystem

The management subsystem covers the set of applications in charge of managing
the telecommunication infrastructure, the end users, the services and the service
providers.
A solution for the OSS/BSS/CRM (Customer Relation Management)/EMS of the
network operator plays an important role in the OCB context. It must support the
traditional roles of subscriber provisioning and management, service provisioning
and management, statistics gathering, alarm management, and customer care in the
wholesale context to multiple service providers per end-user. Additionally, in the case
of OCB a self-provisioning portal would allow the end-user to select and monitor its
services. Note that in OCB the network provider is a new entrant, meaning that it
does not have experience or legacy systems to rely upon. Hence the importance of
an affordable and comprehensive solution.
This can be fulfilled by a combination of the classic EMS platforms (AMS for ISAM
and SAM for ESS and SR) with an integrated management platform, which acts as
OSS/BSS/CRM by interacting with end-users, network operator and service
provider:
• customer self-provisioning portal (restricted access by end-user): users monitor
their profile and select their services
• service provider portal (restricted access by service providers): service providers
monitor and manage their subscribers
• technical portal (restricted access by network operator): network operator sets the
per-subscriber service policies, keeps usage statistics, by directly interacting with
the corresponding network elements
• customer care portal (restricted access by service providers): allows the service
providers to manage the customer trouble tickets
The dedicated EMS platforms take care of the initial user provisioning and
consolidated alarm management.

NT

System Description for FD 100/320Gbps NT and FX RADIUS Attributes
NT
26 RADIUS Attributes
26.1 RADIUS Attributes
26.2 Vendor specific RADIUS attributes
26.1 RADIUS Attributes
Note — The below description is a collection of all attributes

that are supported across the ISAM 7302, 7330, 7360, 7362,
7363, 7367 product family. Not all attributes apply to all product
types. In particular, the 7362 DF/SF does not support Layer 3
forwarding, nor TL-1, so the VRF-Name and TL-1 related
attributes do not apply.
26.1.1 NAS-Port
The system sets the NAS-port attribute as described below:
• 802.1X sessions:
The NAS-port attribute contains the ifIndex of underlying bridge port.
• PPPoE sessions:
The NAS-port attribute contains the ifIndex of the PPPoE sessions.
26.1.2 NAS-Port-Id
The system sets the NAS-Port-Id attribute according to the following text format:
atm <rack>/<shelf>/<slot>/<DSL-Line>:<VPI>.<VCI>
The fields indicated between “<” and” “>” is the information retrieved from the
management model:
• Rack & shelf:
Rack and shelf number of the board that terminates the DSL line. Each item is
represented with 1 ASCII character.

RADIUS Attributes System Description for FD 100/320Gbps NT and FX
NT
• Slot & DSL-line:

Slot number and port number of the board and of the DSL-line within the board,
each item is represented with 2 ASCII characters that correspond with the decimal
number.
For example, port 12 is represented with character “1” followed by character “2”.
Port 5 is represented by character “0” followed by character “5”.
• VPI:
VPI represented with between 1 and 3 ASCII characters, using the number of
characters that is needed.
For example, VPI 12 is represented with character “1” followed by character “2”.
VPI 5 is represented by character “5”. VPI 0 is represented by character “0”.
• VCI:
VCI represented with between 1 and 5 ASCII characters, using the number of
characters that is needed.
For example, VCI 32 is represented with character “3” followed by character “2”.
The fixed separators, including the blanks are characters that are inserted in
between the previous characters.
26.2 Vendor specific RADIUS attributes
26.2.1 General
Vendor ID 637 is used for ISAM.
The “Vendor type” field has a length of two bytes where the highest byte is the project
ID and the lowest byte is the project specific attribute ID.
The “Vendor length” field has a length of one byte.
The project ID 7 is assigned to ISAM project. This means that the vendor specific
attribute range from 1792 to 2047 will be used for the ISAM.
Note — If the radius server supplies the 7330 with VSA
privileges in the authentication response for a CLI operator, the
response must contain a VSA and privilege level for all
supported VSA's on the 7330. Otherwise, the 7330 will use the
default values for ALL attributes as set in the default-profile on
the ISAM. The default-profile settings can be viewed in CLI
using the info configure system security default-profile
command.

NT
26.2.2 VRF-Name
• Vendor Type: 1792

• Vendor Length: 4 < length < 35
• Vendor Value: STRING
• Packet: Access-Accept
26.2.3 VLAN-ID

• Vendor Length: 7
• Vendor Value: INTEGER
26.2.4 QoS-Profile-Name
The QoS-Profile-Name is a character string of maximum 32 characters identifying
the QoS user profile configured in the system. The QoS user profile contains both
marker and policer information.
Note: This attribute cannot be specified together with QoS-Parms attribute.
26.2.5 QoS-Parms
Note: This attribute cannot be specified together with QoS-Profile-Name attribute.

NT
Possible values are:

• [marker up {.1p <value(0:7)>}]
• [policer up {cir <value> cbs <value>}]
• [policer down {cir <value> cbs <value>}]
where:
• cir: 4 bytes in kbit/s
• cbs: 4 bytes in bytes
26.2.6 TL1 domain parameters

Table 80 lists the VSAs and their default values for the TL1 domain.
Table 80 TL1 domain parameters
Domain VSA Value Default Value

Maintenance 1536 Integer (0..7) 4
Provisioning 1537 Integer (0..7) 4
Security 1538 Integer (0..7) 7

Test 1539 Integer (0..7) 0
The possible values for each domain are:

• 0: no privilege
• 1: privilege level 1
26.2.7 CLI domain parameters

Table 81 lists the VSAs and their default values for the CLI domain.

NT
Table 81 CLI domain parameters
Domain VSA Value Default Value
AAA 1801 Integer (0..3) 1
ATM 1802 Integer (0..3) 3
Alarm 1803 Integer (0..3) 3
DHCP 1804 Integer (0..3) 3
EQP 1805 Integer (0..3) 3
IGMP 1806 Integer (0..3) 3
CPEproxy 1807 Integer (0..3) 3

IP 1808 Integer (0..3) 3
PPPoE 1809 Integer (0..3) 3
QoS 1810 Integer (0..3) 3
SWMgt 1811 Integer (0..3) 3
Transport 1812 Integer (0..3) 3
VLAN 1813 Integer (0..3) 3
xDSL 1814 Integer (0..3) 3
Security 1815 Integer (0..3) 0
Cluster 1816 Integer (0..3) 3
SLOT-NUMBERING 1820 Integer (0..2) 2
Service 1821 Integer (0..3) 3
Debug 1822 Integer (0..3) 3
Debugmirror 1823 Integer (0..3) 3
Filter 1824 Integer (0..3) 3
Link 1825 Integer (0..3) 3
Log 1826 Integer (0..3) 3

OAM 1827 Integer (0..3) 3
SIP 1828 Integer (0..3) 3
MEGACO 1829 Integer (0..3) 3

LACP 1830 Integer (0..3) 3
MSTP 1831 Integer (0..3) 3
DROUTER 1832 Integer (0..3) 3
CONFIRM_PROMPT 1834 Integer (0..1) 0

NT
The possible values for each domain are (except for domain SLOT-NUMBERING
and CONFIRM_PROMPT):
• 0: no privilege
• 1: read privileges
• 2: write privileges
• 3: read-write privileges
The possible values for domain SLOT-NUMBERING:

• 0: type based
• 1: position based
• 2: legacy based
The possible values for domain CONFIRM_PROMPT:
• 0: no confirm prompt
• 1: confirm prompt
26.2.8 CLI profile parameters

Table 82 lists the VSAs and their default values for the CLI profile.
Table 82 CLI profile parameters
Profile parameter VSA Value Default Value Length
Prompt 1817 String (< 19 characters) %n%d%c 18 bytes
Password timeout 1818 Integer (0..365 days) 0 -
Description 1819 String (< 31 characters) ““ 30 bytes

Customer document and product support
Customer documentation
Customer Documentation Welcome Page
Technical Support
Customer Documentation Technical Support
Documentation feedback
Customer Documentation Feedback
Copyright 2016-2018. Nokia
3HH-13800-BAAA-TQZZA

System Description Manual 3HH13800BAAATQZZA10

Uploaded by

Copyright:

Available Formats

System Description Manual 3HH13800BAAATQZZA10

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

System Description Manual 3HH13800BAAATQZZA10

Uploaded by

Copyright:

Available Formats

System Description for FD 100/320Gbps NT and FX NT

7302 INTELLIGENT SERVICES

System Description for FD 100/320Gbps NT and FX

Nokia — Proprietary and confidential

Nokia is a registered trademark of Nokia Corporation. Other products and company

3.6 Ethernet .....................................................................................................58

4.1.2.1 Redundancy on FD 100Gbps/320Gbps NT and FX NT systems ..............76

5.3.5 Trace and Debug interface ......................................................................113

6.4.1 MELT support ..........................................................................................142

7.2.8.4 Configuration: Synchronous Ethernet input interface(s)..........................176

9.3 Bonding group configuration....................................................................216

12 Universal Next Generation PON Network Architecture...........239

13.6.2.1 User-to-user communication ...................................................................278

13.10 Permanent data storage ..........................................................................360

13.15.4.8 SOS SIP Server Fail-back .......................................................................404

14.3 MEGACO Feature Portfolio .....................................................................434

14.5.4 Management Interface.............................................................................494

15.3.4 Multi-service Configurations on the Access Link .....................................533

15.6.4.2 Forwarding of C-VLAN tagged frames ....................................................580

15.11.2.7 ARP Algorithm .........................................................................................614

16.10.1.1 PPPoE relay tag ......................................................................................653

18.7 TWAMP Light ..........................................................................................680

20.2.6.4 Shaping on network ports........................................................................721

21 Resource management and authentication .............................779

25.1.4 ISAM Backhaul (Rural DSL, Ultra-high Broadband)................................810

25.6.2.4 Resiliency ................................................................................................842

Figure 30 NTR options for FX NT ISAM family........................................................165

Figure 68 7302 ISAM/7330 ISAM FTTN/7360 ISAM FX: TISPAN IMS-PES

Figure 98 SIP Integrated Voice Service - Switched - Centralized: Signaling

Figure 257 IPv6 routing - VPRN service....................................................................671

Figure 298 QoS session profile on the VULA uplink..................................................745

Figure 338 Implementing service requirements at the UNI .......................................833

Table 33 ISAM Access Node as ANSWER side (DTMF RFC2833).......................443

Table 72 VULA marker profiles ..............................................................................745

1.3 Required knowledge

1.4 Acronyms and initialisms

1.5 Safety information

1.7 Product Naming

1.8 Special information

Warning — Warning indicates that the described activity or

Caution — Caution indicates that the described activity or

Note — A note provides information that is, or may be, of

1.9 Release notes

2.2 Supported Network Interfaces

2.3 Supported User Interfaces

2.4 Integrated DSL, Voice, Point-to-point Ethernet, GPON and Universal

2.5 Document Structure

Figure 1 ISAM Network Architecture

Voice EMAN NSP IP backbone

2.2 Supported Network Interfaces

Two types of Ethernet uplinks are supported by the ISAM:

2.3 Supported User Interfaces

Note — Nokia Universal Next Generation PON (Universal

2.4 Integrated DSL, Voice, Point-to-point

2.5 Document Structure

3 System interface overview

3.9 Inverse multiplexing for ATM

3.10 ATM/PTM bonding

3.11 Overview of ISAM Voice interfaces