Section 1 Product Overview: Do Not Delete This Graphic Elements in Here

12
Do not delete this graphic elements in here:
Section 1 Product Overview

Module 2 Architecture
3JK Edition 1.00
All Rights Reserved Alcatel-Lucent 2008
All Rights Reserved 2007, Alcatel-Lucent 3JK Edition 1.00 Section 1 Module 2 Page 1
Blank Page
122
Product Overview Architecture Alcatel Lucent 9500 MPR ALU 9500MPR rel. 1.1 O&M
This page is left blank intentionally
Document History Edition 01 Date 2008-11-08 Author External Consultant Remarks First edition
Objectives
Objectives: to be able to
describe the main functionalities of the 9500 MPR.
123
Objectives [cont.]
124
Table of Contents
Switch to notes view!
1 MSS-8 Architecture 1.1 MSS Architecture 1.2 PDH Terminal with PDH local accesses 1.3 Flash Cards with Licences 1.4 ODUs 2 Traffic Management (QoS) 2.1 Quality Of Services (QoS) 2.2 Switch QoS 2.3 Scheduler 2.4 QoS in switch to radio direction 2.5 Scheduler 3 Traffic profiles 3.1 Traffic profiles 3.2 TDM2TDM 3.3 TDM2Eth 3.4 ETH2ETH Blank Page 4 Synchronisation 4.1 Synchronisation 4.2 Differential clock recovery 4.3 Adaptive clock recovery 4.4 Synchronisation Interface Blank Page 5 All Rights Reserved Alcatel-Lucent 2008 1 2 5 Cross-connections Product Overview Architecture 5.1 Cross-connection Alcatel Lucent 9500 MPR ALU 9500MPR rel. 1.1 O&M 5.2 E1 Cross-connection 5.3 Ethernet Cross-connection 6 Protections 6.1 Protections 6.2 9500 MPR Packet Node Full Protection (Radio) 6.3 RPS Switching Criteria 6.4 EPS Switching Criteria 6.5 HSB Switching Criteria End of Module Page 7 8 9 10 12 13 14 15 16 17 18 19 20 23 25 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 43 44 45 46
Table of Contents [cont.]

Switch to notes view!
126
1 MSS-8 Architecture
127
1.1 MSS Architecture Core

Flash PSU Controller RAM
Access Peripherals
Radio Peripherals
32xE1 Access Module
GbEth
ETHERNET SWITCH
GbEth
MODEM 300 Module IF interface (ODU)
LIU 4x10/100/1000 Ethernet
128
Core platform symmetrical Cross-connection function able to manage different radio directions add-drop tributaries in case of local PDH/Ethernet accesses Peripherals 32 x E1 local access module (SCSI 68 32E1) 4 x Electrical GbEth Radio IF interface
1.2 PDH Terminal with PDH local accesses
PSU
Controller
Flash
RAM
MODEM
E1
PDH Access Module (TDMoP)
ETHERNET SWITCH
300 Module
ODU
MSS
Core
LIU
4xEth.
129
In the figure is shown the easiest configuration: PDH terminal.
1.3 Flash Cards with Licences

Super PDH licences:
SPDH Licence 6x18E1/40 Mbps SPDH Licence 1x37E1-80/5x18E1-40 Mbps SPDH Licence 2x37E1-80/4x18E1-40 Mbps SPDH Licence 1x48E1-100/5x18E1-40 Mbps SPDH Licence 2x48E1-100/4x18E1-40 Mbps SPDH Licence 1x68E1-150/5x18E1-40 Mbps SPDH Licence 2x68E1-150/4x18E1-40 Mbps SPDH Licence 1x136E1-150/5x18E1-40 Mbps SPDH Licence 2x136E1-150/4x18E1-40 Mbps
1 2 10
The licences are stored in the Flash card installed in the Core Module. The Flash card stores also the Equipment software, the equipment MIB and the equipment MAC address. Note: With these flash cards the available circuit emulations are: TDM2TDM, ETH2ETH.
1.3 Flash Cards with Licences [cont.]

Site Aggregator licences:
SA SA SA SA SA SA SA SA SA Licence Licence Licence Licence Licence Licence Licence Licence Licence 6x18E1/40 Mbps 1x37E1-80/5x18E1-40 Mbps 2x37E1-80/4x18E1-40 Mbps 1x48E1-100/5x18E1-40 Mbps 2x48E1-100/4x18E1-40 Mbps 1x68E1-150/5x18E1-40 Mbps 2x68E1-150/4x18E1-40 Mbps 1x136E1-150/5x18E1-40 Mbps 2x136E1-150/4x18E1-40 Mbps
1 2 11
The licences are stored in the Flash card installed in the Core Module. The Flash card stores also the Equipment software, the equipment MIB and the equipment MAC address. Note: With these flash cards the available circuit emulations are: TDM2TDM, ETH2ETH, TDM2ETH.
1.4 ODUs
ODU V2 are designed for direct-antenna mounting. ODU V2 supports:
Modulation rates from 16QAM, 32 QAM, 128QAM Bandwidths from 14 to 56 MHz Frequency bands from 6 to 38 GHz High transmit power
1 2 12
2 Traffic profiles
1 2 13
2 Traffic profiles
2.1 Traffic profiles

Three kinds of traffic profiles have been identified:
1. TDM2TDM ( 9500MPR 9500MPR, internal TDM ) 2. TDM2Eth ( 9500MPR TDM to Ethernet ) 3. DATA (Ethernet to Ethernet)
1 2 14
Profiles 1 and 2 meet MEF8 standard
2 Traffic profiles
2.1 Traffic profiles [cont.]
1 2 15
Case 1 The E1 stream is inserted in Node 1 and extracted in Node 2. In this case the two IWFs used to packetize the traffic for the Ethernet switch in the Core module are both internal to the 9500 MPR network. The Circuit Emulation Service is TDM2TDM in Node 1 and Node 2. The Cross connections to be implemented are PDH-Radio type.
Case 2 The E1 stream is inserted in Node 1 and extracted in Node 2. One IWF is inside the 9500 MPR, but the second IWF is external to the 9500 MPR network. The Circuit Emulation Service is TDM2ETH in Node 1 and Node 2. The Cross connections to be implemented are PDH-Radio type in Node 1 and Radio-Eth type in Node 2
Case 3 The E1 stream is inserted/extracted in Node 1. One IWF is inside the 9500 MPR, but the second IWF is external to the 9500 MPR network. The Circuit Emulation Service is TDM2ETH in Node 1 and Node 2. The Cross connections to be implemented are PDH-Eth type in Node 1.
2 Traffic profiles
2.1 Traffic profiles [cont.]
1 2 16
Cases 4 and 5 In these cases Ethernet packets enter Node 1 and are extracted in Node 2. In case 4 the Ethernet packets encapsulate the E1 stream; in case 5 the packets are native Ethernet packets. None of the IWFs belongs to the 9500 MPR network. The Circuit Emulation Service is ETH2ETH in Node 1 and Node 2. No Cross connections must be implemented. The path is automatically implemented with the standard auto-learning algorithm of the 9500 MPR Ethernet switch.
2 Traffic profiles
2.2 TDM2TDM
E1 traffic packetized only internally to 9500MPR equipment
RADIO
BTS
E1
RADIO RADIO
PDH
E1 BTS
E1 BSC
E1 BTS
1 2 17
Flow Id present (user defined) intermediate node configuration (E1 provisioning): node by node (building Cross-connection tables based on Flow Id) bandwidth guaranteed (according to QoS no flooding-autolearning necessary Highest Queue Priority association)
2 Traffic profiles
2.2 TDM2TDM [cont.]

Both the IWFs belong to 9500MPR and the packets are not supposed to exit the 9500 MPR network. The IWF parameters listed above, have predetermined values and dont need to be provisioned.
Mac addresses are determined as consequences of the cross connections. Payload size is fixed to 122 bytes ECID will be the same value as Flow Id TDM clock source: clock recovery differential, Flow Id provisioned by ECT/NMS
1 2 18
ECID = Emulated Circuit Identifier
2 Traffic profiles
2.3 TDM2Eth
E1 traffic both internal and external to 9500MPR equipment
E1 BTS
PSN
Eth E1 BTS Eth E1 BSC
E1 BTS
1 2 19
Flow Id present (user defined) all the parameters must be configured compliant with the MEF8 standard adaptive or differential clock recovery supported bandwidth guaranteed (according to QoS Highest Queue Priority association) destination MAC added before going into whole network (MEF8 compliant)
2 Traffic profiles
2.3 TDM2Eth [cont.]

Only one of the IWFs belongs to 9500MPR and the packets are supposed to exit the 9500MPR network.
MAC addresses: in all involved nodes are determined as consequences of the cross connections; the only exception is the Ethernet Terminal Node (the node where the TDM2ETH traffic goes through an user Ethernet port). In such ETN the source address is the node Mac address, the destination Mac address will be provisioned by ECT/NMS. Payload size: can be chosen (by ECT/NMS) between 256 and 1024 bytes ECID : provisioned by ECT/NMS, 2 different values may be used for each direction TDM clock source is provisioned by ECT/NMS: clock recovery adaptive, clock recovery differential, clock loopback (TDM line in) Flow Id is provisioned by ECT/NMS (One Vlan is assigned to each bi-directional circuit emulated E1 flow)
For this case the expected latency for 1 hop depends only on the payload size: 3.5 msec for 256 bytes, 6.5 msec for 1024 bytes.
1 2 20
ECID = Emulated Circuit Identifier
2 Traffic profiles
2.4 ETH2ETH
PSN
WiMAX (NodeB) Eth Eth Eth Eth RNC
PSN
WiMAX (NodeB) Eth WiMAX (NodeB) Eth Eth RNC
None of the IWFs belongs to 9500MPR. None of the parameters listed in the previous slide has to be configured (the 9500 MPR is transparent).
1 2 21
Product Overview Architecture Alcatel Lucent 9500 MPR ALU 9500MPR rel. 1.1 O&M All Rights Reserved Alcatel-Lucent 2008
Any packet belonging to an Eth2Eth TDM flow is treated as any other Ethernet packet with the only exception of giving it an higher priority based on the MEF 8 Ethertype.
Blank Page
1 2 22
3 Traffic Management (QoS)
1 2 23
3.1 Quality Of Services (QoS)

The QoS function inside 9500 MPR is the result of a distributed implementation in the switch and Radio Interface module. Both those QoS functions must be properly configured in order to get the wished behavior on Ethernet flows that will be transmitted towards the Radio.
1 2 24
3.2 Switch QoS
1 2 25
The figure shows an overview of the QoS implementation inside the switch. The Quality of Service feature of the Ethernet switch provides four internal queues per port to support four different traffic priorities. Typically the high-priority traffic experiences less delay than that low-priority in the switch under congested conditions. For each egress port according to method of QoS classification configured in the switch, the packets are assigned to each queue. The higher priority queue is reserved for TDM flows; the remaining queues are shared by all Ethernet flows according the classification mechanism configured by CT/NMS. For generic Ethernet flows in the switch it is possible by CT/NMS to assign the priority to each packet according to the information in:
1.
IEEE std 802.1p: the packet is examined for the presence of a valid 802.1P user-priority tag. If the tag is present the correspondent priority is assigned to the packet.
802.1P priority 111, 110 101, 100 011, 010, 001, 000 Queue Q3 (higher priority) Q2 Q1
2.
DiffServ: each packet is classified based on DSCP field in the IP header to determine the priority.
DiffServ priority 111000, 110000, 101110, 101000 100110, 100100, 100010, 100000 011110, 011100, 011010, 011000 All remaining values Queue Q3 (higher priority) Q2 Q1
3.3 Scheduler
With the Weighted Round Robin (WRR) scheduler algorithm assigning the weights, an average bandwidth percentage can be assigned to each queue. High Queue Pre-empt (HQP) attribute guarantees that when a packet arrives in the egress queue it is immediately transmitted.
QUEUE Q 4 (h ig h e r p rio rity ) Q3 Q2 Q1
W E IG H T HQP 4 2 1
1 2 26
In the table the configurations foreseen are listed.
3.4 QoS in switch to radio direction
1 2 27
In the figure is shown an overview of the QoS implementation inside the Radio Interface module. The QoS feature provides eight internal queues to support different traffic priorities. The QoS function can assign the packet to one of the eight egress transmit queues according to the information inside the packet as 802.1P field, DiffServ field, Ethertype or 802.1Q VLAN_ID. QoS based on IEEE std. 802.1p When 802.1p QoS mechanism is adopted, the reference is the standard IEEE 802.1D-2004 Annex G User priorities and traffic classes that defines 7 traffic types and the corresponding user priority values. Considering that in the Radio Interface module for generic Ethernet traffic there are five egress queues the mapping 802.1p value to queue is the following: 802.1p priority Queue 111, 110 Q5 (higher priority) 101 Q4 100 Q3 011, 000 Q2 010, 001 Q1 QoS based on DiffServ
DiffServ priority 111000, 110000, 101110, 101000 100110, 100100, 100010, 100000 011110, 011100, 011010, 011000 010110, 010100, 010010, 010000 001010, 001100, 001010, 001000, 000000 All remaining values Queue Q5 (higher priority) Q4 Q3 Q2 Q1
QoS based on VLAN_ID The VLAN_ID classification is always enabled, when a packet with VLAN is received the Radio Interface module search inside the local memory if the VLAN_ID has been configured. If the query is positive the packet is sent to the queue assigned to the VLAN_ID itself; if the query is negative the packet follow the classification flow described above in the flow chart. Inside the Radio Interface module up to 4096 VLAN can be assigned and to each one is associated one egress priority queue. This association in release 1.0 is predefined: For the VLAN_IDs used to configure TDM2TDM flows the egress priority queue is Q8; For the VLAN_IDs used to configure TDM2ETH flows the egress priority queue is Q7 For the VLAN_IDs used to configure internal control traffic flows the egress priority queue is Q6. All Rights Reserved 2007, Alcatel-Lucent 3JK Edition 1.00 Section 1 Module 2 Page 27
3.5 Scheduler
The scheduler algorithm implemented inside the Radio Interface module is High Queue Pre-empt: when a packet arrives in the higher priority queue it is immediately transmitted.
1 2 28
4 Synchronisation
1 2 29
4 Synchronisation
4.1 Synchronisation
TDM data flow is fragmented and the fragments are transmitted over a Packet Switched Network (PSN); The received fragments need to be reassembled in the original TDM data flow at the original bit rate Two main methods can be used to recover at the RX site, the original bit rate:
Differential clock recovery: recalculation of the original clock based of the Delta respect to a reference clock that is available at both TX and RX site Adaptive clock recovery: based on the average rate at which the packets (fragments) arrive at RX site
1 2 30
Adaptive: simpler network, but performances depends on the PDV (Packet Delay Variation) in the Network. Always used when the reference clock isnt distributed on the whole network. Differential: used in case of clock distribution on the whole network. Its more reliable than Adaptive; also used in TDM2TDM traffic (MPR to MPR). N.B.: In meshed networks (rings) do not close the synchronisation configuration.
4 Synchronisation
4.2 Differential clock recovery
End System1 IWF
PSN PSN
End System2 IWF
1 2 31
Common reference clock IS available at both Ends. IWF system, at RX side, generate output clock based on RTP TimeStamps which are sent together with each Fragments.
4 Synchronisation
4.3 Adaptive clock recovery
End System1 IWF
PSN PSN
End System2 IWF
1 2 32
Common reference clock is NOT available at both Ends. IWF system, at RX side, generate output clock based on data arrival rate: TDM clock is slowly adjusted to maintain the average fill level of a jitter buffer at its midpoint.
4 Synchronisation
4.4 Synchronisation Interface

To implement differential CK recovery, for each node must be defined: NE Role definition, related to NE CK
Master Slave
NE Synchronisation Source definition

Primary Secondary
Source choice, both for primary and secondary, with proper rule
free running PDH interface [port] external interface [2.048; 5.000; 10.000 MHz] radio interface
1 2 33
Blank Page
1 2 34
5 Cross-connections
1 2 35
5 Cross-connections
5.1 Cross-connection
SLOT 3 (PDH) SLOT 5
SLOT 4 (RADIO) SLOT 6 (RADIO)
SLOT 7
SLOT 8
ETH 4
ETH 1
ETH 3
ETH 2
1 2 36
The cross-connections between slots and between slot and Ethernet user ports are realized with a Layer-2 Ethernet Switch inside the Main Core. The decision made by the switch to forward the received packet is based on the destination MAC address.
5 Cross-connections
5.2 E1 Cross-connection
Each E1 can be cross connected independently E1 can be cross connected to any of the following interfaces:
Radio interface Ethernet interface
Each E1 (board #, port #) must be associated to a signal flow ID
1 2 37
5 Cross-connections
5.3 Ethernet Cross-connection

Ethernet cross connection is based on Ethernet switching (level 2) According to destination address each packet is switched to the correct port, as reported in an Address Resolution Table (ART) If destination address is not present in the ART a flooding mechanism is foreseen
1 2 38
6 Protections
1 2 39
6 Protections
6.1 Protections
Supported Protection types :
1) RPS (Radio Protection Switching) Hitless for each radio direction (RPS-RX)
RPS is distributed in 9500 MSS modules before termination of 9500 MSS frame.
2) EPS (Equipment Protection Switching) for each module type

Both Working and Spare modules send its own signal to the Core. Core selects the best signal.
3) HSB (Hot StandBy)

Spare ODU module is powered off.
1 2 40
6 Protections
6.2 9500 MPR Packet Node Full Protection (Radio)
2 2 1
1 2 41
Legend: 1 2 3 RPS EPS HSB
6 Protections
6.2 9500 MSS Packet Node Full Protection (Radio) [cont.]
2
1 2 42
Product Overview Architecture Alcatel Lucent 9500 MPR ALU 9500MPR rel. 1.1 O&M All Rights Reserved Alcatel-Lucent 2008
Legend: 2 EPS
6 Protections
6.3 RPS Switching Criteria
The switching criteria are:

Early Warning High BER Dem Fail Loss of Frame (LOF) on the radio signal coming from the direct way Loss of Frame (LOF) on the radio signal coming from the cross way
1 2 43
6 Protections
6.4 EPS Switching Criteria

The switching criteria are:
Peripheral Card Fail (switching off of the peripheral included) Peripheral Card Missing LOS of all the tributaries (of course only in case of PDH local access peripheral protection) managed via SW.
1 2 44
6 Protections
6.5 HSB Switching Criteria

The switching criteria are :
Radio Interface Peripheral Card Fail (switching off of the peripheral included) Radio Interface Peripheral Card Missing MSS-ODU cable loss ODU TX chain alarm (this is an OR of the following alarms: LOS at ODU input, modFail, txFail, ODU card fail)
1 2 45
End of Module Architecture
1 2 46

Section 1 Product Overview: Do Not Delete This Graphic Elements in Here

Uploaded by

Copyright:

Available Formats

Section 1 Product Overview: Do Not Delete This Graphic Elements in Here

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

Section 1 Product Overview: Do Not Delete This Graphic Elements in Here

Uploaded by

Copyright:

Available Formats

12

Do not delete this graphic elements in here:

Section 1 Product Overview

All Rights Reserved Alcatel-Lucent 2008

All Rights Reserved Alcatel-Lucent 2008

This page is left blank intentionally

All Rights Reserved Alcatel-Lucent 2008

All Rights Reserved Alcatel-Lucent 2008

This page is left blank intentionally

Table of Contents [cont.]

All Rights Reserved Alcatel-Lucent 2008

This page is left blank intentionally

All Rights Reserved Alcatel-Lucent 2008

1.1 MSS Architecture Core

32xE1 Access Module

MODEM 300 Module IF interface (ODU)

LIU 4x10/100/1000 Ethernet

All Rights Reserved Alcatel-Lucent 2008

1.2 PDH Terminal with PDH local accesses

PDH Access Module (TDMoP)

All Rights Reserved Alcatel-Lucent 2008

In the figure is shown the easiest configuration: PDH terminal.

1.3 Flash Cards with Licences

All Rights Reserved Alcatel-Lucent 2008

1.3 Flash Cards with Licences [cont.]

All Rights Reserved Alcatel-Lucent 2008

All Rights Reserved Alcatel-Lucent 2008

All Rights Reserved Alcatel-Lucent 2008

2.1 Traffic profiles

All Rights Reserved Alcatel-Lucent 2008

Profiles 1 and 2 meet MEF8 standard

2.1 Traffic profiles [cont.]

All Rights Reserved Alcatel-Lucent 2008

2.1 Traffic profiles [cont.]

All Rights Reserved Alcatel-Lucent 2008

All Rights Reserved Alcatel-Lucent 2008

2.2 TDM2TDM [cont.]

All Rights Reserved Alcatel-Lucent 2008

ECID = Emulated Circuit Identifier

All Rights Reserved Alcatel-Lucent 2008

2.3 TDM2Eth [cont.]

All Rights Reserved Alcatel-Lucent 2008

ECID = Emulated Circuit Identifier

All Rights Reserved Alcatel-Lucent 2008

This page is left blank intentionally

3 Traffic Management (QoS)

All Rights Reserved Alcatel-Lucent 2008

3 Traffic Management (QoS)

3.1 Quality Of Services (QoS)

All Rights Reserved Alcatel-Lucent 2008

3 Traffic Management (QoS)

3.2 Switch QoS

All Rights Reserved Alcatel-Lucent 2008

3 Traffic Management (QoS)

QUEUE Q 4 (h ig h e r p rio rity ) Q3 Q2 Q1

All Rights Reserved Alcatel-Lucent 2008

In the table the configurations foreseen are listed.

3 Traffic Management (QoS)

3.4 QoS in switch to radio direction