RTN 360 V100R001C00 Feature Description 01

OptiX RTN 360 Radio Transmission System
V100R001C00
Feature Description
Issue 01
Date 2014-04-30
HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2014. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or representations
of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 01 (2014-04-30) Huawei Proprietary and Confidential i

Copyright Huawei Technologies Co., Ltd.
Feature Description About This Document
About This Document
Related Versions
The following table lists the product versions related to this document.
Product Name Version
OptiX RTN 360 V100R001C00
iManager U2000T V200R014C50
iManager U2000M V200R014C00
Intended Audience
This document describes the main features of the OptiX RTN 360 microwave transmission
system. It provides readers a comprehensive knowledge of the functionality, principles,
configuration, and maintenance of the product features.
This document is intended for:
l Network planning engineers

l Installation and commissioning engineers
l Data configuration engineers
l System maintenance engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
Indicates an imminently hazardous situation

which, if not avoided, will result in death or
serious injury.
Issue 01 (2014-04-30) Huawei Proprietary and Confidential ii

Symbol Description
Indicates a potentially hazardous situation

which, if not avoided, could result in death or
serious injury.

which, if not avoided, may result in minor or
moderate injury.

which, if not avoided, could result in
equipment damage, data loss, performance
deterioration, or unanticipated results.
NOTICE is used to address practices not
related to personal injury.
Calls attention to important information, best

practices and tips.
NOTE is used to address information not
related to personal injury, equipment damage,
and environment deterioration.
General Conventions
The general conventions that may be found in this document are defined as follows.
Convention Description
Times New Roman Normal paragraphs are in Times New Roman.
Boldface Names of files, directories, folders, and users are in

boldface. For example, log in as user root.
Italic Book titles are in italics.
Courier New Examples of information displayed on the screen are in

Courier New.
Command Conventions
The command conventions that may be found in this document are defined as follows.
Boldface The keywords of a command line are in boldface.
Issue 01 (2014-04-30) Huawei Proprietary and Confidential iii

Italic Command arguments are in italics.
[] Items (keywords or arguments) in brackets [ ] are optional.
{ x | y | ... } Optional items are grouped in braces and separated by

vertical bars. One item is selected.
[ x | y | ... ] Optional items are grouped in brackets and separated by

vertical bars. One item is selected or no item is selected.
{ x | y | ... }* Optional items are grouped in braces and separated by

vertical bars. A minimum of one item or a maximum of all
items can be selected.
[ x | y | ... ]* Optional items are grouped in brackets and separated by

vertical bars. Several items or no item can be selected.
GUI Conventions
The GUI conventions that may be found in this document are defined as follows.
Boldface Buttons, menus, parameters, tabs, window, and dialog titles

are in boldface. For example, click OK.
> Multi-level menus are in boldface and separated by the ">"

signs. For example, choose File > Create > Folder.
Change History
Changes between document issues are cumulative. The latest document issue contains all the
changes made in earlier issues.
Issue 01 (2014-04-30)
This issue is the first release for the product version V100R001C00.
Issue 01 (2014-04-30) Huawei Proprietary and Confidential iv

Feature Description Contents
Contents
About This Document.....................................................................................................................ii

1 Introduction to DCN.....................................................................................................................1
2 IP DCN Solution............................................................................................................................6
2.1 Introduction....................................................................................................................................................................7
2.2 Reference Standards and Protocols..............................................................................................................................10
2.3 Specifications................................................................................................................................................................11
2.4 Feature Updates............................................................................................................................................................12
2.5 Feature Dependencies and Limitations.........................................................................................................................13
2.6 Planning Guidelines......................................................................................................................................................13
2.6.1 General Planning Guidelines.....................................................................................................................................13
2.6.2 Planning Guidelines for NE IP Addresses and Routes in Typical Network Topologies...........................................15
2.7 Related Alarms.............................................................................................................................................................20
3 L2 DCN Solution.........................................................................................................................21
3.1 Introduction..................................................................................................................................................................22
3.3 Specifications................................................................................................................................................................25
3.4 Feature Updates............................................................................................................................................................26
3.7 Related Alarms.............................................................................................................................................................28
4 TDD................................................................................................................................................29
4.1 Introduction..................................................................................................................................................................30
4.2 Specifications................................................................................................................................................................32
4.3 Feature Updates............................................................................................................................................................32
4.6 Related Alarms.............................................................................................................................................................33
5 Interference Check and Dynamic Frequency Selection.......................................................34

5.1 Introduction..................................................................................................................................................................35
5.2 Specifications................................................................................................................................................................37
Issue 01 (2014-04-30) Huawei Proprietary and Confidential v

Feature Description Contents
5.3 Feature Updates............................................................................................................................................................37

5.6 Related Alarms.............................................................................................................................................................38
6 QinQ...............................................................................................................................................39
6.1 Introduction..................................................................................................................................................................40
6.3 Specifications................................................................................................................................................................43
6.4 Feature Updates............................................................................................................................................................44
6.7 Related Alarms.............................................................................................................................................................44
7 QoS.................................................................................................................................................45
7.1 Introduction..................................................................................................................................................................46
7.3 Specifications................................................................................................................................................................54
7.4 Feature Updates............................................................................................................................................................57
7.7 Related Alarms and Events...........................................................................................................................................60
8 ETH OAM.....................................................................................................................................62
8.1 Introduction..................................................................................................................................................................63
8.3 Specifications................................................................................................................................................................69
8.4 Feature Updates............................................................................................................................................................70
8.7 Related Alarms.............................................................................................................................................................72
9 Physical Layer Clock Synchronization....................................................................................74

9.1 Introduction..................................................................................................................................................................75
9.3 Specifications................................................................................................................................................................78
9.4 Feature Updates............................................................................................................................................................78
9.7 Related Alarms.............................................................................................................................................................79
A Glossary........................................................................................................................................81
Issue 01 (2014-04-30) Huawei Proprietary and Confidential vi

Feature Description 1 Introduction to DCN
1 Introduction to DCN
Through the data communication network (DCN), the NMS communicates with transmission
NEs to manage and maintain them.
DCN Composition
The DCN contains two types of node: NMS and NE. The DCN between the NMS and NEs are
called external DCN. The DCN among NEs are called internal DCN. The external DCN consists
of data communication devices, such as Ethernet switches and routers. The internal DCN consists
of NEs that are connected using DCN channels. Unless otherwise specified, the DCN mentioned
in this document refers to internal DCN.
DCN Channel
DCN channels fall into two types: outband DCN channel and inband DCN channel.
l Oubtband DCN channels do not occupy any service bandwidth. The RTN 300 supports
two types of outband DCN channel:
D1 to D3 bytes in microwave frames
Channels over NMS ports
Issue 01 (2014-04-30) Huawei Proprietary and Confidential 1

l Inband DCN channels occupy some service bandwidth. The RTN 300 supports two types
of inband DCN channel:
Some Ethernet service bandwidth of microwave links
Some Ethernet service bandwidth of Ethernet links
DCN Solutions
The RTN 300 provides the following DCN solutions:
l IP DCN solution
In the IP DCN solution, network management messages are encapsulated into IP packets.
NEs forward the IP packets based on the IP addresses contained in them. This solution
supports a maximum of 200 NEs and ensures high network stability. This solution is the
default and preferred solution.

l L2 DCN solution
In the L2 DCN solution, network management messages are encapsulated into IP packets,
which are carried by Ethernet frames. NEs forward the Ethernet frames based on the MAC
addresses contained in them. This solution supports a maximum of 1024 NEs. However,
this solution has the risk of broadcast packet flooding and provides poor network stability.
The RTN 300 also supports the HWECC solution, which is eliminated gradually.
NE Types on the DCN

Two types of NE are available on the DCN: gateway NE and non-gateway NE.
Gateway NE: The application layer of the NMS directly communicates with the application layer
of a gateway NE. Generally, an NE at the boundary of the internal DCN and external DCN is a

gateway NE. An NE located inside a DCN can also function as a gateway NE. The NEs between
the NMS and the gateway NE inside a DCN forward DCN packets at L2 or L3.
Non-gateway NE: The application layer of the NMS communications with the application layer
of a non-gateway NE through the application layer of a gateway NE. The NEs between the
gateway NE and non-gateway NE forward DCN packets at L2 or L3.
DCN Flags
An NE on the DCN must be configured with two DCN flags: NE ID and NE IP address.
An NE ID is used for application layer communication. An NE ID contains three bytes among

which the most significant byte represents the extended ID and the other two bytes represent the
basic ID. For example, if the extended ID is 9 and the basic ID is 1, the NE ID is represented as
9-1.

An NE IP address is used for IP communication. By default, the NE IP address and NE ID of

an NE are associated. Specifically, the last three bytes of the NE IP address correspond to the
three bytes of the NE ID. For example, if an NE ID is changed to 9-1, the corresponding NE IP
address automatically changes to 129.9.0.1.
Once an NE IP address is changed manually, the association relationship between the NE ID

and NE IP address becomes ineffective.

Feature Description 2 IP DCN Solution
2 IP DCN Solution
About This Chapter
In the IP DCN solution, NEs use unified DCN channels to transmit TCP/IP protocol data, which
enables the NMS to manage the NEs.
2.1 Introduction
This section describes the basic knowledge about IP DCN.
2.2 Reference Standards and Protocols

This section lists the standards and protocols associated with IP data communication network
(DCN).
2.3 Specifications
This section provides the IP data communication network (DCN) specifications that OptiX RTN
360 supports.
2.4 Feature Updates

This section provides a history of IP DCN solution updates.
2.5 Feature Dependencies and Limitations

This section describes the dependencies and limitations of IP data communication network
(DCN).
2.6 Planning Guidelines

This section provides guidelines for planning IP data communication network (DCN).
2.7 Related Alarms

This section describes the alarms related to IP DCN.

2.1 Introduction
This section describes the basic knowledge about IP DCN.
Application of the IP DCN solution

Huawei's IP DCN solution allows an NMS to manage NEs by encapsulating NMS messages in
the IP protocol stack and transmitting them over DCN channels between the NEs. If a network
has only OptiX RTN 300s or a combination of OptiX RTN 300s and third-party equipment
supporting the IP protocol stack, using an IP DCN is recommended.
IP DCN Protocol Stack

To implement IP DCN, equipment must support the IP protocol stack. IP DCN uses the standard
TCP/IP protocol stack architecture.

l The physical layer provides data transmission channels for data terminal equipment. The
OptiX RTN 300 provides the following DCN channels:
NMS port: all the bandwidth at the NMS port
DCC channel: three Huawei-defined DCC bytes in a microwave frame at a microwave
port
Inband DCN: a portion of Ethernet service bandwidth at an Ethernet or a microwave
port
l The data link layer ensures reliable data transmission across physical links. DCCs and
inband DCNs use the PPP protocol to set up data links. Therefore, IP addresses of adjacent
NEs do not need to be in the same IP network segment.
l The network layer specifies the network layer address for a network entity and provides
transferring and addressing functions. NEs implement network layer functions using the
IP protocol. The routes used for IP transferring can be dynamic routes generated running
the OSPF protocol, manually configured static routes, or direct routes discovered by
running link layer protocols. The OptiX RTN 300 provides various OSPF features. For
details, see the 2.3 Specifications.
l The transport layer provides end-to-end communication services for the upper layer. NEs
support the TCP/UDP protocol.
Transferring Packets Based on the IP Protocol Stack

In IP DCN, the packets are transferred in either gateway access mode or direct access mode.
In gateway access mode, the packets are transferred as follows:
1. The NMS transfers application layer packets to the gateway NE through the TCP
connection.
2. The gateway NE extracts the packets from the TCP/IP protocol stack and delivers them to
the application layer.
3. The application layer of the gateway NE queries the destination NE address of the packets.
If the address does not belong to the gateway NE, the gateway NE queries the core routing
table of the application layer. The gateway NE obtains the route to the destination NE and

the communication protocol stack of the transit NE according to the destination NE address.
Because the transit NE uses the IP protocol stack, the gateway NE transfers the packets to
the transit NE through the IP protocol stack.
4. The network layer of the transit NE queries the destination IP address of the packets. If the
address does not belong to the transit NE, the transit NE queries the IP routing table to
obtain the route to the destination NE and then transfers the packets.
5. The network layer of the destination NE passes the packets to its application layer through
the transport layer because the destination IP address of the packets is the same as the IP
address of the destination NE. The application layer then processes the packets.
In direct access mode, the packets are transferred in a different way.
The original gateway NE acts as an ordinary transit NE, and packets are transferred at the network
layer.
Traversing the L2 Network

In actual networking, the OptiX RTN 300 is often connects to a third-party L2 network. In this
scenario, IP DCN packets have to traverse the L2 network by enabling the access control function
at OptiX RTN 300's Ethernet ports.
The third-party L2 network may be located between the network consisting of OptiX RTN 300s
and the NMS or between two networks consisting of OptiX RTN 300s.
When the third-party L2 network is located between the network consisting of OptiX RTN 300s
and the NMS, the L2 network transmits Ethernet services and DCN packets between the NMS
and the gateway NE. In this instance, the NMS uses the LAN switch to remove the VLAN ID
carried by NMS messages and the access control function is enabled on the Ethernet port. After
the access control function is enabled:
l The Ethernet port functions as an Ethernet NMS port on the gateway NE.

l The IP address of the Ethernet port must be in the same network segment as that of the
NMS IP address and in a network segment different from that of NE IP addresses.
l The NMS communicates with the gateway NE based on the IP address of the Ethernet port.
When the third-party L2 network is located between two networks consisting of OptiX RTN
300s, NMS messages are encapsulated as L2 services for transmission. In this instance, the access
control function is enabled on the Ethernet ports of the two networks for connecting to the third-
party L2 network and their IP addresses are in the same network segment.
The third-party L2 network creates a dedicated L2VPN service for the DCN packets carrying a
specific inband DCN VLAN ID.

This section lists the standards and protocols associated with IP data communication network
(DCN).

l IETF RFC 1587: The OSPF NSSA Option

l IETF RFC 1661: The Point-to-Point Protocol (PPP)
l IETF RFC 1027: Using ARP to Implement Transparent Subnet Gateways
l IETF RFC 2328: OSPF Version 2
l IETF RFC 2370: The OSPF Opaque LSA Option
2.3 Specifications
This section provides the IP data communication network (DCN) specifications that OptiX RTN
360 supports.
Table 2-1 IP DCN specifications that OptiX RTN 360 supports
Item Specifications
Outband Channel type Microwave port: 3 bytes DCC channel (D1-D3)

DCN
Inband DCN Channel type l Microwave port for transmitting Ethernet

services: a portion of Ethernet service
bandwidth in a microwave frame
l GE service port: a portion of Ethernet service
bandwidth
Range of used VLAN 2 to 4094, with the default value of 4094

IDs
Bandwidth range 64 kbit/s to 1000 kbit/s. This parameter is set

based on the channel type.
Route type l Direct route

l Static route
l Dynamic route
Open OSPF global parameters The following parameters are configurable:

Shortest Path l Area ID
First (OSPF)
l Packet timer
l STUB type (NON-STUB, STUB, or NSSA)
OSPF port parameters The following parameters are configurable:

(microwave port) l OSPF enabled/disabled (enabled by default)
l Type-10 LSA enabled/disabled (enabled by
default)
l Port IP address (If not specified, the NE IP
address is used.)

Item Specifications

(NMS port, where NMS l OSPF enabled/disabled (enabled by default)
stands for network
management system) l Type-10 LSA enabled/disabled (enabled by
default)
NOTE
The port IP address is always the NE IP address.

(inband DCN port) l Port IP address (If not specified, the NE IP
address is used.)
NOTE
OSPF and Type-10 LSA are always enabled.
OSPF route flooding The following types of external routes can be

imported:
l Direct routes
l Static routes
l Default routes
NOTE
OSPF route flooding is applicable to all areas.
Maximum number of 64
nodes in an area
Proxy Address Resolution Protocol Supported

(ARP)
NMS access mode l Gateway access mode

l Direct access mode
Access control Supported
Scale of a DCN subnet l It is recommended that a DCN subnet contain

120 or less NEs. A DCN subnet allows a
maximum of 200 NEs.
l The network depth allows a maximum of 15
hops.
2.4 Feature Updates

This section provides a history of IP DCN solution updates.
Version Description
V100R001C00 IP DCN was first available in this version.


This section describes the dependencies and limitations of IP data communication network
(DCN).
Table 2-2 Dependencies and limitations of IP DCN
Item Description
Self-limitations l If an Ethernet port interconnects with the DCN through an

L2 network, access control must be enabled for the
Ethernet port. Besides, IP addresses of interconnected
ports at both sides of the intermediate L2 network must be
in the same network segment. If no DCN packet is
transmitted through the Ethernet port, disable inband DCN
channels and access control for the port.
l When access control is enabled for an Ethernet port, the
port IP address must be in a network segment different
from that of the NE IP address and the IP addresses of
other ports for which access control is enabled.
Dependencies and None

limitations between IP DCN
and other features

This section provides guidelines for planning IP data communication network (DCN).
NOTE
In the planning guidelines, OptiX equipment refers to Huawei OptiX transmission equipment that supports
IP DCN.
2.6.1 General Planning Guidelines

This section provides general guidelines for planning IP data communication network (DCN)
in various scenarios.
2.6.2 Planning Guidelines for NE IP Addresses and Routes in Typical Network Topologies
If operators do not have special requirements for NE IP addresses, you can set IP addresses to
simplify route settings.
2.6.1 General Planning Guidelines

This section provides general guidelines for planning IP data communication network (DCN)
in various scenarios.

Planning Guidelines for DCN Channels

l If NEs on a network connect through microwave links, both inband DCN and outband DCN
channels are used.
l If NEs on a network connect through GE links, ensure that the NEs use inband DCN
channels.
l When inband DCN channels are used, plan DCN channels as follows:
Ensure that all the NEs use the same management VLAN ID and that the management
VLAN ID is different from Ethernet service VLAN IDs. The default management
VLAN ID 4094 is recommended.
Generally, the inband DCN bandwidth is 512 kbit/s (default value). When the DCN
channels over a convergence GE link are used as inband DCN channels, you can increase
the inband DCN bandwidth to 1 Mbit/s.
Generally, inband DCN packets use their default priority. If required, you can change
the VLAN priority or differentiated services code point (DSCP) value of inband DCN
packets according to the network plan.
Planning Guidelines for NE IP Addresses

l Plan the IP address, subnet mask, and default gateway of the NE connected to an external
DCN in compliance with the requirements for planning external DCNs.
l The IP addresses of the NEs connected through network management system (NMS) ports
should be on the same network segment.
l When a network uses multiple Open Shortest Path First (OSPF) areas, plan the NE IP
addresses as follows:
Plan the NE IP address of an area border router (ABR) by considering the ABR as a
backbone NE.
Ensure that the IP addresses of NEs in different areas (including backbone and non-
backbone areas) are on different network segments.
If possible, ensure that the IP addresses of NEs in the same area are on the same network
segment. If special NE IP addresses are required, the IP addresses of NEs in the same
area can belong to different network segments.
Planning Guidelines for Routes in a Single OSPF Area

l A DCN subnet should use only a single OSPF area when the DCN subnet contains less
than or equal to 64 NEs with OSPF enabled.
l If a network has only OptiX equipment, configure only a single OSPF area as follows:
Plan the NE connected to the external DCN as a gateway NE and the other NEs as non-
gateway NEs.
Ensure that the area ID, packet timer, and router ID of each NE use their default values.
l If a network has both OptiX equipment and third-party equipment and if the OptiX
equipment provides channels for transparently transmitting third-party network
management information, configure only a single OSPF area as follows:
Plan the OptiX NE connected to the external DCN as a gateway NE of the OptiX NEs
and the other OptiX NEs as non-gateway NEs.
Ensure that the area ID, packet timer, and router ID of each NE use their default values.

On the OptiX gateway NE, configure a static route to the third-party NMS and enable
static route flooding.
On the OptiX NE connected to the third-party gateway NE, configure a static route to
the third-party gateway NE and enable static route flooding.
If the third-party NMS and the third-party gateway NE are on the same network segment,
enable proxy Address Resolution Protocol (ARP) on the OptiX NE connected to the
third-party gateway NE. If the OptiX gateway NE is also on the same network segment,
enable proxy ARP on the OptiX gateway NE.
l If a network has both OptiX and third-party equipment and they transmit OSPF packets to
each other, configure only a single OSPF area as follows:
Plan the OptiX NE closest to the external DCN as a gateway NE and the other OptiX
NEs as non-gateway NEs.
Configure the area ID, packet timer, area type, and router ID for each OptiX NE in
compliance with the requirements for third-party NEs.
On the NE connected to the external DCN, configure a static route to Huawei NMS and
a static route to the third-party NMS, and enable static route flooding.
Planning Guidelines for DCN Subnets

l CPU resource usage increases as the number of NEs on a DCN subnet increases.
l Plan the number of NEs in a DCN subnet based on network conditions. A DCN subnet
should ideally have 120 or fewer NEs, but no more than 200 NEs.
l If a DCN subnet has more than 150 NEs, divide the DCN subnet into several independent
subnets, and disable the DCN channels between the subnets.
l If possible, select either the central node of a star network or the NE connected to the most
DCN channels as the NE connected to an external DCN.
2.6.2 Planning Guidelines for NE IP Addresses and Routes in

Typical Network Topologies
If operators do not have special requirements for NE IP addresses, you can set IP addresses to
simplify route settings.
Plan NE IP addresses as follows:
l If a network has only OptiX NEs, the IP address of the gateway NE and the IP addresses
of non-gateway NEs must be on different network segments.
l If a network has both OptiX and third-party NEs, the IP addresses of the OptiX gateway
NE, the IP addresses of the OptiX non-gateway NEs not connected to a third-party NE, and
the IP address of the third-party gateway NE must be on different network segments. The
IP addresses of the OptiX non-gateway NEs connected to a third-party NE and the third-
party gateway NE must be on the same network segment.
Guidelines for planning NE IP addresses and routes in typical network topologies are described
in the following section.

Network Comprising Only OptiX NEs, with the IP Addresses of the NMS and
Gateway NE on the Same Network Segment
Figure 2-1 illustrates a network comprising only OptiX NEs. On the network, the IP addresses
of the network management system (NMS) and gateway NE are on the same network segment.
Figure 2-1 Diagram for planning NE IP addresses and routes (a network comprising only OptiX
NEs, with the IP addresses of the NMS and gateway NE on the same network segment)
NMS NE 1 NE 2 NE 3 NE 4
130.9.0.100
130.9.0.1 129.9.0.2 129.9.0.3 129.9.0.4
Ethernet link Microwave link
In Figure 2-1:
l The IP address of the gateway NE (NE 1) belongs to the network segment 130.9.0.0, and
the IP addresses of the non-gateway NEs belong to the segment 129.9.0.0.
l If the NMS requests direct access to a non-gateway NE (NE 2 or NE 3), configure a static
route from the NMS to the network segment 129.9.0.0, or set the IP address of NE 1
(130.9.0.1) as the default gateway.
Network Comprising Only OptiX NEs, with the IP Addresses of the NMS and
Gateway NE on Different Network Segments
Figure 2-2 illustrates a network comprising only OptiX NEs. On the network, the IP addresses
of the NMS and gateway NE are on different network segments.

Figure 2-2 Diagram for planning NE IP addresses and routes (a network comprising only OptiX
NEs, with the IP addresses of the NMS and gateway NE on different network segments)
NMS
10.2.0.200
RT 1
10.2.0.100
NE 1 NE 2 NE 3 NE 4
RT 2
130.9.0.100 130.9.0.1 129.9.0.2 129.9.0.3 129.9.0.4
Ethernet link Microwave link
In Figure 2-2:
l The IP address of the gateway NE (NE 1) belongs to the network segment 130.9.0.0, and
the IP addresses of the non-gateway NEs belong to the segment 129.9.0.0.
l On NE 1, configure a static route to the NMS (10.2.0.100), or set the IP address of RT 2
l On the NMS, configure a static route to NE 1 (130.9.0.1), or set the IP address of RT 1
l If the NMS requests direct access to a non-gateway NE (NE 2, NE 3, or NE 4), perform
the following configurations in addition to the preceding ones:
On NE 1, enable Open Shortest Path First (OSPF) route flooding, so that NE 2, NE 3,
and NE 4 can obtain routes to the NMS.
On the NMS, configure a static route to the network segment 129.9.0.0. Skip this
operation if the default gateway has been configured.
Configure routes from RT 1 and RT 2 to the network segment 129.9.0.0.
Network Comprising OptiX and Third-Party NEs, with the IP Addresses of the
Third-Party NMS and OptiX Gateway NE on the Same Network Segment (No
OSPF Interaction)
Figure 2-3 illustrates a network comprising OptiX and third-party NEs. On the network, the IP
addresses of the third-party NMS and OptiX gateway NE are on the same network segment, and
the OptiX NEs do not use OSPF to communicate with the third-party NEs.

Figure 2-3 Diagram for planning NE IP addresses and routes (a network comprising OptiX and
third-party NEs, with the IP addresses of the third-party NMS and OptiX gateway NE on the
same network segment)
NMS
130.9.0.100 External
DCN
Third-party
NMS NE 5 NE 6
NE 1 NE 2 NE 3 NE 4
130.9.0.200
131.9.0.5 131.9.0.6
130.9.0.1 129.9.0.2 129.9.0.3 131.9.0.4
Ethernet link Microwave link Third-party equipment
Compared with the scenario where a network comprises only OptiX NEs and the IP addresses
of the NMS and gateway NE are on the same network segment, planning NE IP addresses and
routes for this scenario has the following characteristics:
l The IP addresses of the gateway NE (NE 1), non-gateway NEs (NE 2 and NE 3, which do
not connect to a third-party NE), and third-party gateway NE (NE 5) are on the network
segments 130.9.0.0, 129.9.0.0, and 131.9.0.0, respectively.
l The IP addresses of NE 4, a non-gateway NE connected to a third-party NE, and NE 5 are
on the same network segment.
l On the third-party NMS, configure a static route to the third-party gateway NE (131.9.0.5),
or set the IP address of NE 1 (130.9.0.1) as the default gateway.
l On NE 5, configure a static route to the third-party NMS (130.9.0.200), or set the IP address
of NE 4 (131.9.0.4) as the default gateway.
Third-Party NMS and OptiX Gateway NE on Different Network Segments (No
OSPF Interaction)
Figure 2-4 illustrates a network comprising OptiX and third-party NEs. On the network, the IP
addresses of the third-party NMS and OptiX gateway NE are on different network segments,
and the OptiX NEs do not use OSPF to communicate with the third-party NEs.

Figure 2-4 Diagram for planning NE IP addresses and routes (a network comprising OptiX and
third-party NEs, with the IP addresses of the third-party NMS and OptiX gateway NE on different
network segments)
Third-party
NMS 10.2.0.200
RT 1
10.2.0.100
130.9.0.100
RT 2 NE 5 NE 6
NE 1 NE 2 NE 3 NE 4
NMS LAN 131.9.0.5 131.9.0.6

swtich 130.9.0.1 129.9.0.2 129.9.0.3 131.9.0.4
130.9.0.200
Ethernet link Microwave link Third-party equipment
l On NE 1, configure a static route to the third-party NMS (10.2.0.100).
l On NE 1, enable OSPF route flooding, so that NE 2, NE 3, and NE 4 can obtain routes to
the third-party NMS.
or set the IP address of RT 1 (10.2.0.200) as the default gateway.
l On NE 5, configure a static route to the third-party NMS (10.2.0.100), or set the IP address
of NE 4 (131.9.0.4) as the default gateway.
l Configure routes from RT 1 and RT 2 to the third-party gateway NE (131.9.0.5).
Third-Party NMS and OptiX Gateway NE on Different Network Segments (with
OSPF Interaction)
In this example, the OptiX and third-party NEs in Figure 2-4 use OSPF to communicate with
each other. On the network, the IP addresses of the third-party NMS and OptiX gateway NE are
on different network segments, and each NE runs OSPF.

l On NE 1, configure a static route to the third-party NMS (10.2.0.100).
l On NE 1, enable OSPF route flooding, so that NE 2, NE 3, NE 4, and NE 5 (a third-party
NE) obtain the routes to the third-party NMS.
or set the IP address of RT 1 (10.2.0.200) as the default gateway.
l Configure routes from RT 1 and RT 2 to the third-party gateway NE (131.9.0.5).
2.7 Related Alarms

This section describes the alarms related to IP DCN.
Related Alarms
l DCNSIZE_OVER
The DCNSIZE_OVER is an alarm indicating an over-sized DCN network.
l NEIP_CONFUSION
The NEIP_CONFUSION is an alarm indicating an NE IP address conflict.
l SUBNET_RT_CONFLICT
The SUBNET_RT_CONFLICT is an alarm indicating a subnetwork route conflict. This
alarm occurs when the subnet route of an NMS port, that is, the IP subnet route of an NE,
covers the learned route of an OSPF subnet whose mask is longer than that of the IP subnet.

Feature Description 3 L2 DCN Solution
3 L2 DCN Solution
About This Chapter
In the Layer 2 data communication network (L2 DCN) solution, Ethernet-encapsulated DCN
packets are transmitted between NEs based on L2 forwarding, enabling the NMS to manage the
NEs.
3.1 Introduction
This section describes the basic information about the Layer 2 data communication network (L2
DCN) solution.

This section describes the standards and protocols associated with L2 DCN.
3.3 Specifications
This section provides the L2 DCN specifications that OptiX RTN 360 supports.
3.4 Feature Updates

This section provides a history of L2 DCN solution updates.

This section describes the limitations of the L2 DCN solution and the dependencies between L2
DCN and other features.

This section provides the guidelines to be followed when you plan the L2 DCN solution.
3.7 Related Alarms

This section describes the alarms related to L2 DCN.

3.1 Introduction
This section describes the basic information about the Layer 2 data communication network (L2
DCN) solution.
Application of the L2 DCN Solution

In the L2 DCN solution, Ethernet-encapsulated DCN packets are transmitted between NEs based
on L2 forwarding, enabling the NMS to manage the NEs.
The L2 DCN solution is mainly applied to scenarios in which network management must be
implemented based on L2 forwarding. Centralized network management is achieved, with
communication between microwave equipment within a subnet implemented through L2 DCN
and DCN communication between subnets implemented based on L3 IP forwarding.
If an OptiX RTN 300 constructs a network with third-party equipment that supports L2 DCN,
the OptiX RTN 300 can use the L2 DCN to communicate with the third-party equipment, which
simplifies network configurations and eliminates the need for extra static routes.
L2 DCN Protocol Stack

To implement the L2 DCN solution, each NE must support the L2 DCN protocol stack. The L2
DCN protocol stack is an optimization of part of the standard TCP/IP protocol stack.

l Layer 1 of the protocol stack is the physical layer, which provides physical channels for
transmitting data between data terminal equipment. OptiX RTN 300 provides the following
DCN channels:
NMS port: transmitting DCN packets using all of its bandwidth
DCC channel on a microwave port: transmitting DCN packets using the three self-
defined DCC bytes in a microwave frame
Inband DCN channel on an Ethernet or microwave port: transmitting DCN packets using
part of Ethernet bandwidth
l Layer 2 is the data link layer, which provides reliable data transmission to the physical link
layer. The L2 DCN solution implements the functions of the data link layer based on MAC
address learning and forwarding.
l Layer 3 is the network layer, which performs addressing and packet forwarding. NEs run
the IP protocol to provide functions of the network layer.
DCN Transmission Based on the L2 DCN Protocol Stack

In the L2 DCN solution, the NMS transmits DCN packets by directly accessing NEs. The NMS
can directly access an NE regardless of whether the NE is in the same network segment as the
NMS.
If the NMS and the NE are in the same network segment, the process of DCN packet forwarding
is as follows:
1. The NMS obtains the MAC address of the destination NE using the ARP.
2. Intermediate NEs on the link between the NMS and the destination NE forward DCN
packets to the destination MAC address based on L2 forwarding.
3. When the destination NE returns DCN packets, the NE obtains the MAC address of the
NMS using the ARP.

4. Intermediate NEs on the link between the NMS and the destination NE forward DCN
When the NMS and the NE are in the different network segments, the process of DCN packet
forwarding is as follows:
1. The NMS sends DCN packets to the access NE based on IP forwarding.

2. The access NE obtains the destination MAC address using the ARP.
3. Intermediate NEs on the link between the NMS and the destination NE forward the DCN
4. When the destination NE returns DCN packets, the access NE functions as the next hop or
gateway NE. The destination NE obtains the MAC address of the access NE using the ARP,
and forwards the DCN packets to the access NE based on L2 forwarding.
5. The access NE sends the DCN packets to the NMS based on IP forwarding.

Traversal of an L2 Network by L2 DCN Packets

No special configuration is required when L2 DCN packets traverse an L2 network, because L2
DCN packets are forwarded at L2 by nature.

This section describes the standards and protocols associated with L2 DCN.
The following standards and protocols are associated with L2 DCN:
l IEEE 802.1d: Media Access Control (MAC) Bridges

l IETF RFC826: An Ethernet Address Resolution Protocol or Converting Network Protocol
Addresses to 48 bit Ethernet Address for Transmission on Ethernet Hardware.
3.3 Specifications
This section provides the L2 DCN specifications that OptiX RTN 360 supports.
Table 3-1 Specifications of the L2 DCN solution that Table 3-1 supports
Item Specifications
DCN channel type l DCC (microwave port)

l Inband DCN (Ethernet service port/microwave port)
l Ethernet NMS port
NOTE
OptiX RTN 360 can use only the Ethernet NMS port to implement Layer
2 forwarding and exchange of DCN packets with third-party microwave
equipment.
The L2 DCN function can be enabled for either inband DCN channels or
DCCs over a microwave port on the OptiX RTN 360.

Item Specifications
GE electrical port Supported

functioning as the
Ethernet NMS port
Scale of an L2 DCN A maximum of 30 NEs

subnet
Maximum frame length 1522 bytes (maximum valid payloads: 1500 bytes)
supported in L2 DCN
forwarding
RSTP NE-level RSTP supported
Type of entries in a MAC Dynamic entries are supported. Static entries are not supported.
address table
Huawei NMS packet l 802.3 (untagged frame)

format l 802.1Q (tagged frame)
Transmission scheme of l Third-party DCN packets that are not identified by VLAN IDs
third-party DCN packets are forwarded by the system control unit and transmitted over
the DCN channel.
l Third-party DCN packets that are identified by VLAN IDs are
forwarded by the Ethernet service switching unit and
transmitted over the service channel.
3.4 Feature Updates

This section provides a history of L2 DCN solution updates.
Version Description
V100R001C00 The L2 DCN solution was first available in

this version.

This section describes the limitations of the L2 DCN solution and the dependencies between L2
DCN and other features.
l When the OptiX RTN 360 uses the L2 DCN solution, the RSTP protocol can be used to
prevent L2 forwarding loops. It is recommended that the RSTP protocol use its default
enable/disable mode for the OptiX RTN 360 NE level. That is, the RSTP protocol is
automatically enabled/disabled depending on the enable/disable status of the L2 DCN
function over IF ports.
l When the OptiX RTN 360 is connected to a switch through its Ethernet network
management port, the STP/RSTP protocol needs to be enabled on the switch to prevent

broadcast storms and further prevent OptiX RTN 360 NEs from being unreachable to the
NMS.
l When being loaded with software, NEs on an L2 DCN network can be loaded only one by
one instead of in diffusion mode.
l CPRI ports cannot transmit DCN packets. Microwave ports for transmitting CPRI services
do not support inband DCN. DCN packets can be transmitted only through DCCs.
l When CPRI services are transmitted, the P&E port always functions as the Ethernet NMS
port.

This section provides the guidelines to be followed when you plan the L2 DCN solution.
Planning Guidelines on External DCNs

l For network stability and security, it is recommended that you do not use the office LAN
or Internet as transmission channels of external DCNs.
l It is recommended that you connect only one NE to the router.
Planning Guidelines on Internal DCNs

DCN packets need to be transmitted over a LAN between microwave equipment. In this scenario,
use a switch that supports the STP/RSTP, instead of a hub. If a hub is used to connect NEs, the
NEs are prone to being unreachable to the NMS.
Planning Guidelines on DCN Subnets

l An L2 DCN subnet contains a maximum of 30 NEs, including OptiX RTN 360 NEs, third-
party microwave NEs, and the NMS server.
l IP addresses of NEs on the same subnet must be in the same network segment.
l DCN communication between subnets is implemented based on L3 IP forwarding. Both
the L2 DCN and L3 IP communication functions need to be enabled for the OptiX RTN
360 NEs that are connected to different subnets. The L2 DCN function implements
communication between NEs within a subnet and the L3 IP communication function
implements communication between NEs within and outside the subnet.
Planning Guidelines on Interconnection with Third-Party Equipment Using the L2

DCN Solution
l TheOptiX RTN 360 allows only L2 forwarding of DCN packets to be implemented through
Ethernet network management port with third-party radio equipment.
l The Ethernet network management port on an OptiX RTN 360 NE supports L2 forwarding
of DCN packets with a maximum frame length of 1522 bytes and a maximum valid payload
of 1500 bytes. Therefore, when the OptiX RTN 360 needs to construct a network with third-
party microwave equipment, ensure that the maximum frame length of DCN packets
supported by the third-party equipment is equal to or smaller than 1522 bytes.
l If the L2 DCN function is enabled for the Ethernet network management port of an OptiX
RTN 360 NE, the automatic extended ECC function needs to be disabled for the port.

Planning Guidelines on L2 DCN over DCN Channels

Both DCCs and inband DCN over an IF port support the L2 DCN solution. DCCs are preferred
for the L2 DCN solution.
If the inband DCN is used for the L2 DCN solution, plan the inband DCN according to the
following principles:
l The NEs on the same subnet have the same management VLAN ID.
l The management VLAN ID used for the inband DCN is different from the VLAN IDs
carried by Ethernet services.
l The inband DCN bandwidth depends on the number of NEs on the subnet.
Planning Guidelines on RSTP

When the OptiX RTN 360 uses the L2 DCN solution, the RSTP protocol can be used to prevent
L2 forwarding loops. It is recommended that the RSTP protocol use its default enable/disable
mode for the OptiX RTN 360 NE level. That is, the RSTP protocol is automatically enabled/
disabled depending on the enable/disable status of the L2 DCN function over IF ports.
NOTE
Enable the STP/RSTP for a switch that is connected to the L2 DCN. Otherwise, loops may be generated
on an L2 DCN, causing broadcast storms and NEs to be unreachable to the NMS.
3.7 Related Alarms

This section describes the alarms related to L2 DCN.
Related Alarms
l DCNSIZE_OVER
The DCNSIZE_OVER alarm indicates that the DCN network is oversized. The gateway
NE reports the DCNSIZE_OVER alarm after detecting that the number of nodes (NEs,
NMS servers, and NMS clients on a network segment) on an L2 DCN subnet is larger than
30. To clear this alarm, it is recommended that you further divide the DCN network,
ensuring that each subnet consists of less than 30 nodes.
l NEIP_CONFUSION
The NEIP_CONFUSION is an alarm indicating an NE IP address conflict.

Feature Description 4 TDD
4 TDD
About This Chapter
4.1 Introduction
This section introduces time division duplex (TDD).
4.2 Specifications
This section lists the TDD specifications that OptiX RTN 360 supports.
4.3 Feature Updates

This section provides a history of TDD updates.

This section describes the dependencies and limitations of TDD.

This section provides guidelines for planning TDD.
4.6 Related Alarms

This section describes the alarms related to TDD.

4.1 Introduction
This section introduces time division duplex (TDD).
FDD vs TDD
The duplex technologies in digital communication include frequency division duplex (FDD) and
TDD.
FDD
In FDD mode, two independent symmetric channels are required; one transmits uplink services
and the other transmits downlink services. A hop of microwave link includes a TX high site and
a TX low site.
Figure 4-1 FDD
TDD
In TDD mode, a device alternately transmits and receives services using the same channel. The
devices at the two ends of a microwave link hop are not defined as TX high and TX low sites.
Figure 4-2 TDD
TDD Characteristics
l Frequency spectrum resources are not required in pairs.
OptiX RTN 360 uses frequency spectrum resources that do not require a license. Only one
frequency is required for a microwave link because both uplink and downlink services are
transmitted over the same channel.
l The devices at the two ends of a microwave link hop are not defined as TX high and TX
low sites.

One microwave link uses only one frequency. Therefore, the devices at the two ends of a
microwave link hop are not defined as TX high and TX low sites.
l Asymmetric transmission is allowed.
If a microwave link carries services with high downlink traffic (such as video services),
you can adjust the TDD timeslot ratio to implement asymmetric transmission of uplink and
downlink services. This ensures proper channel resource usage and service quality.
Master and Slave Devices

The devices at the two ends of a microwave link hop are defined as master and slave devices.
Master and slave devices differ in the following ways:
l The timeslot ratio on the slave device matches that on the master device. For example, if
the timeslot ratio on the master device is 3:1, the timeslot ratio on the slave device is 1:3.
l The slave device traces the clock of the master device through the microwave link.
l Automatic frequency selection is always initiated by the master device.
Figure 4-3 Master and Slave Devices
TDD Principles
Devices transmit and receive services through different timeslots, which is controlled by
switches.
1. In the transmit timeslot, the master device transmits services to the channel, and the slave
device receives the services from the channel.
2. In the interval between the transmit timeslot and receive timeslot, the master device turns
off the TX switch and turns on the RX switch. Meanwhile, the slave device turns off the
RX switch and turns on the TX switch.
3. In the receive timeslot, the slave device transmits services to the channel, and the master
device receives the services from the channel.
The service transmission duration ratio between the master and slave devices is the TDD timeslot
ratio. The default TDD timeslot ratio on the master device is 3:1.

Figure 4-4 TDD Principles
4.2 Specifications
This section lists the TDD specifications that OptiX RTN 360 supports.
Table 4-1 TDD specifications that OptiX RTN 360 supports
Item Specifications
Timeslot ratio switching Supported
Timeslot ratio l 1:1

l 2:1
l 3:1 (default value on the master device)
l 1:2
l 1:3
4.3 Feature Updates

This section provides a history of TDD updates.
Version Description
V100R001C00 The TDD feature is first available in this version.

This section describes the dependencies and limitations of TDD.
The TDD timeslot ratio can be configured only on the master device. The TDD timeslot ratio
on the slave device automatically matches that on the master device.

This section provides guidelines for planning TDD.

l Determine the master and slave devices on a hop of microwave link. Configure the device
on the macro base station side as the master device.
l Configure the timeslot ratio as required by services. For services with high downlink traffic,
you can configure the timeslot ratio as 2:1 or 3:1. For services with high uplink traffic, you
can configure the timeslot ratio as 1:2 or 1:3.
4.6 Related Alarms

This section describes the alarms related to TDD.
Alarms
None

Feature Description 5 Interference Check and Dynamic Frequency Selection
5 Interference Check and Dynamic Frequency

Selection
About This Chapter
Interference check and dynamic frequency selection can free you from frequency planning and
improve the anti-interference capability of microwave links.
5.1 Introduction
This section introduces interference check and dynamic frequency selection.
5.2 Specifications
This section lists the interference check and dynamic frequency selection specifications that
OptiX RTN 360 supports.
5.3 Feature Updates

This section provides a history of updates for interference check and dynamic frequency
selection.

This section describes the dependencies and limitations of interference check and dynamic
frequency selection.

This section provides guidelines for planning interference check and dynamic frequency
selection.
5.6 Related Alarms

This section describes the alarms related to interference check and dynamic frequency selection.

5.1 Introduction
This section introduces interference check and dynamic frequency selection.
Scenarios
The network life cycle involves two important scenarios: new network construction and network
maintenance.
Common Problems and Solutions

Problems:
l During the commissioning of a newly constructed network, the communication quality at
the current frequency is poor after microwave link parameters are configured according to
the network plan.
l During network maintenance, the microwave link quality is poor and the link needs to
switch to an available frequency.
Solutions:
l Interference check: checks for interference on microwave links, which will result in poor
link quality.
l Dynamic frequency selection: dynamically switches to an available frequency after link
interference is identified.
Advantages of Dynamic Frequency Selection

l Dynamic frequency selection frees you from frequency planning. You only need to select
a country name or configure a frequency range so that dynamic frequency selection will
be executed within the band supported by the country or within the configured range.
l Frequency switching is completed automatically, which reduces maintenance workload.
Principles of Interference Check

Interference check can be manually enabled in scenarios where a network is being constructed
or in scenarios where microwave links are not restored after dynamic frequency selection is
enabled. The interference check process is as follows:
1. A user mutes the slave device through the NMS. The slave device starts the timer.
2. After interference check is started, the master device scans frequencies, starting from the
lowest frequency, at a step of 200 MHz channel spacing within the entire band.
3. After the frequency scan is complete, the master device outputs results indicating whether
there is interference on any frequency in the band.
4. After the timer expires, the slave device is unmuted.

Figure 5-1 Principles of Interference Check
Principles of Dynamic Frequency Selection

The following describes the dynamic frequency selection process triggered by an MW_LOF
alarm on the slave device. The dynamic frequency selection process triggered by other alarms
is similar.
1. After the slave device generates an MW_LOF alarm, it is muted. The slave device performs
an interference check to obtain the available frequency list and meanwhile determines the
transmit frequency of the master device.
2. After the slave device is muted, the master device generates an MW_LOF alarm. The master
device then performs an interference check to obtain the available frequency list.
3. The master device switches to a new available frequency f1 and transmits services to the
slave device. The master device also attempts to receive services from the slave device at
f1.
4. After identifying the transmit frequency of the master device, the slave device switches to
the new frequency f1 to receive services and then unmutes the transmit port.
5. After the master and slave devices receive services from each other, the microwave link
recovers.
Figure 5-2 Principles of Dynamic Frequency Selection

5.2 Specifications
This section lists the interference check and dynamic frequency selection specifications that
OptiX RTN 360 supports.
Table 5-1 Interference check and dynamic frequency selection specifications that OptiX RTN
360 supports
Item Specifications
Frequency scan step in interference check 200 MHz, which is the same as the channel
spacing.
Dynamic frequency selection duration at an 5s

air interface
5.3 Feature Updates

This section provides a history of updates for interference check and dynamic frequency
selection.
Version Description
V100R001C00 Interference check and dynamic frequency selection are first

available in this version.

This section describes the dependencies and limitations of interference check and dynamic
frequency selection.
Table 5-2 Dependencies and limitations of interference check and dynamic frequency selection
Item Description
Self-limitations l Dynamic frequency selection and manual interference

check are mutually exclusive.
l During new network construction, a country name must
be selected or the planned frequency range must be entered
so that the available band can be determined in
interference check and dynamic frequency selection.

Item Description
Dependencie TDD The TDD timeslot ratio is automatically switched to 1:1

s and during dynamic frequency selection. The original TDD
limitations timeslot ratio is restored after dynamic frequency selection is
between complete.
interference
check and Frequency Dynamic frequency selection and frequency setting are
dynamic setting mutually exclusive.
frequency
selection and
other
features

This section provides guidelines for planning interference check and dynamic frequency
selection.
l It is recommended that dynamic frequency selection be enabled for a newly constructed

network.
l Determine the master and slave devices on a hop of microwave link.
l Select the name of the country where devices are located, or enter the planned frequency
range.
5.6 Related Alarms

This section describes the alarms related to interference check and dynamic frequency selection.
Alarms
None

Feature Description 6 QinQ
6 QinQ
About This Chapter
This chapter describes the 802.1Q in 802.1Q (QinQ) feature.
6.1 Introduction
This section introduces 802.1Q in 802.1Q (QinQ).

This section describes the standards and protocols related to QinQ.
6.3 Specifications
This section provides the QinQ specifications that OptiX RTN 360 supports.
6.4 Feature Updates

This section provides a history of 802.1Q in 802.1Q (QinQ) updates.

This section describes the dependencies and limitations of QinQ.

This section provides guidelines for planning 802.1Q in 802.1Q (QinQ).
6.7 Related Alarms

No alarm is related to 802.1Q in 802.1Q (QinQ).

6.1 Introduction
This section introduces 802.1Q in 802.1Q (QinQ).
Definition
QinQ is a Layer 2 tunnel protocol based on IEEE 802.1Q encapsulation. The QinQ technology
encapsulates a private virtual local area network (VLAN) tag into a public VLAN tag. Packets
carrying two VLAN tags are transmitted on the backbone network of an operator. QinQ provides
Layer 2 virtual private network (VPN) tunnels.
Figure 6-1 Application of QinQ in E-Line services
Purpose
Using QinQ based on VLAN stacking and nesting, services are differentiated by two VLAN
tags in data packets, which increases the number of available VLAN IDs. The inner VLAN tag
is a customer VLAN (C-VLAN) tag and the outer VLAN is a supplier VLAN (S-VLAN) tag.
The QinQ technology brings the following benefits:
l The number of available VLAN IDs can reach 4094 x 4094. This meets the increasing
requirements for VLAN IDs.
l Customers and operators can plan VLAN resources independently and flexibly. Network
configuration and maintenance are simplified.
l A cheaper and easier-to-implement Layer 2 VPN solution can be provided based on the
QinQ technology as compared with MPLS.
l Ethernet services can be extended from local area networks (LANs) to wide area networks
(WANs).

Frame Format
To identify S-VLANs carried in Ethernet packets, QinQ defines a C-TAG and an S-TAG based
on the tagged frame format specified in IEEE 802.1Q.
A C-TAG is an IEEE 802.1Q frame header.
The default TPID of an S-TAG is 0x88A8 and the TPID can be modified according to the
requirement. In addition, a field indicating the S-TAG frame priority is added.

Before being transmitted from a user network to an operator network, Ethernet packets may be
untagged frames or tagged frames. When the Ethernet packets are transmitted within the operator
network, they carry only S-TAGs or a combination of C-TAGs and S-TAGs.
Basic Principle
When Ethernet packets are transmitted from a user network to an operator network, S-TAGs are
added to the packets based on PORT or PORT+C-VLAN and then these packets are forwarded
based on S-VLAN tags (carried by E-Line services) or S-VLAN tags and destination MAC
addresses (carried by E-LAN services). Swapping of S-VLAN tags is allowed when E-Line
services are created to carry Ethernet packets.
The Ethernet packets are transmitted to the user network from the operator network after their
S-VLAN tags are removed.


This section describes the standards and protocols related to QinQ.
The following protocols are related to QinQ:
IEEE 802.1ad: Virtual Bridged Local Area Networks Amendment 4: Provider Bridges
6.3 Specifications
This section provides the QinQ specifications that OptiX RTN 360 supports.
Table 6-1 QinQ specifications
Item Specifications
Setting of the QinQ type field Supported, with the default value being
0x88A8
S-VLAN ID range 1 to 4094
Maximum number of QinQ-based E-Line 64

services
Maximum number of QinQ links 1024
Type of service flows carried by QinQ links PORT

PORT+CVLAN
PORT+SVLAN
QinQ operation type (QinQ-based E-Line Adding S-VLAN tags (from a UNI to an NNI)
services) Stripping S-VLAN tags (from an NNI to a
UNI)
Swapping S-VLAN tags (from an UNI to an
UNI)
Maximum number of 802.1ad bridges 1
Type of logical ports mounted to a bridge PORT

PORT or PORT+CVLAN
PORT+SVLAN
QinQ operation type (802.1ad bridge-based Adding S-VLAN tags based on PORT (UNI
E-LAN services) port)
Adding S-VLAN tags based on PORT+C-
VLAN (UNI port)
Mounting ports based on PORT+S-VLAN
(NNI port)

6.4 Feature Updates

This section provides a history of 802.1Q in 802.1Q (QinQ) updates.
Version Description
V100R001C00 QinQ is first available in this version.

This section describes the dependencies and limitations of QinQ.
None

This section provides guidelines for planning 802.1Q in 802.1Q (QinQ).
l Plan S-VLANs and QinQ service type (E-Line or E-LAN) based on service requirements.
l Set the same QinQ type field for the ports at both ends of a QinQ link (transmitting Ethernet
packets with S-VLAN IDs). The value 0x88A8 is recommended.
6.7 Related Alarms

No alarm is related to 802.1Q in 802.1Q (QinQ).

Feature Description 7 QoS
7 QoS
About This Chapter
This section describes quality of service (QoS). QoS provides different levels of service quality
in certain aspects of services as required, such as bandwidth, delay, jitter, and packet loss ratio.
This ensures that the request and response of a user or application reaches an expected quality
level.
7.1 Introduction
This section introduces quality of service (QoS).

This section lists the standards and protocols associated with quality of service (QoS).
7.3 Specifications
This section lists the quality of service (QoS) specifications that OptiX RTN 360 supports.
7.4 Feature Updates

This section provides a history of QoS updates.

This section describes the self-limitations of quality of service (QoS), and limitations and
dependencies between QoS and other features.

This section provides guidelines for planning quality of service (QoS). Before planning QoS,
identify the QoS requirement characteristics of services and the QoS requirements of carriers,
and consider network conditions.
7.7 Related Alarms and Events

This section describes the alarms and performance events related to quality of service (QoS).

7.1 Introduction
This section introduces quality of service (QoS).
Definition
QoS provides different levels of service quality in certain aspects of services as required, such
as bandwidth, delay, jitter, and packet loss ratio.
Purpose
QoS provides guaranteed bandwidth for important services, minimizes delay and jitter, and
properly allocates and monitors network resources.
The following figure illustrates how QoS is performed on Ethernet services.
Figure 7-1 QoS processing
DiffServ and Simple Traffic Classification

As shown in the following figure, in a DiffServ (DS) domain, DS boundary nodes identify the
classes of service (CoSs) carried by the packets that enter the DS domain and then map different
service flows to different PHBs.
The DS interior node performs traffic control based on packets' PHBs and forwards the packets
to the next-hop DS boundary node.

CoS is a priority-bit field in an Ethernet frame and is used to differentiate traffic.
In the ingress direction, OptiX RTN 360 maps the incoming packets to different PHBs based on
the CoS trusted by the ingress port. If some packets do not carry the CoS trusted by the port,
OptiX RTN 360 maps them to the best effort (BE) queue.
The following figure shows the default mappings from priorities of ingress packets to PHBs.
In the egress direction, OptiX RTN 360 modifies the CoS information carried by packets based
on the mapping between the PHB and the trusted CoS.
The following figure shows the default mappings from PHBs to priorities of egress packets.

Simple traffic classification maps packets carrying different CoSs to specific PHBs.
Complex Traffic Classification

Compared with simple traffic classification, complex traffic classification provides more match
items and QoS processing methods.
CAR
Committed access rate (CAR) is a traffic policing technology. CAR assesses the traffic rate in
a certain period (long term or short term). CAR assigns a high priority to traffic that does not
exceed the rate limit and drops or downgrades traffic that exceeds the rate limit. In this manner,
CAR limits the traffic entering a transmission network.
The following CAR operations are performed for traffic policing:
l Packets whose rate is lower than or equal to the committed information rate (CIR) are
colored green.
l Packets whose rate is higher than the peak information rate (PIR) are colored red.
l Packets whose rate is higher than the CIR but is lower than or equal to the PIR are colored
yellow.
l If the traffic rate in a certain period is lower than or equal to the CIR, traffic bursts are
allowed. The maximum traffic of burst packets is determined by the committed burst size
(CBS).
l If the traffic rate in a certain period is higher than the CIR but is lower than or equal to the
PIR, traffic bursts are allowed. The maximum burst size is equal to the peak burst size
(PBS).
l Green packets pass traffic policing.
l Red packets are dropped.
l Yellow packets pass traffic policing but are re-marked. To be specific, yellow packets are
re-colored green or mapped to a newly specified PHB.
The following figure shows how traffic changes after CAR processing.

Red packets are directly dropped. Green packets and yellow packets pass traffic policing, and
yellow packets are re-marked.
Congestion Avoidance
Congestion avoidance is a traffic control mechanism that monitors the usage of network
resources, such as queues or memory buffers, and drops packets under overload or congestion.
OptiX RTN 360 supports two congestion avoidance algorithms: tail drop and weighted random
early detection (WRED).
Tail Drop
With tail drop enabled, all newly arriving packets are dropped if the buffer queue is filled to its
maximum capacity.

WRED
With WRED enabled, yellow and red packets are preferentially dropped and green packets are
always transmitted first in the case of network congestion.
Queue Scheduling
OptiX RTN 360 supports three queue scheduling algorithms: strict priority (SP), weighted round
robin (WRR), and SP+WRR.
SP
During SP scheduling, packets are transmitted in descending order of queue priorities. Packets
in a lower-priority queue can be transmitted only after a higher-priority queue becomes empty.

Therefore, important services are placed in higher-priority queues and are transmitted with
precedence over unimportant services.
SP scheduling uses all resources to ensure the quality of service (QoS) of higher-priority services.
If there are always packets in higher-priority queues, packets in lower-priority queues will never
be transmitted.
WRR
WRR allocates a weight to each queue and a service time segment to each queue based on the
weight. Packets in a WRR queue are transmitted at the allocated service time segment. If the
queue does not have packets, packets in the next queue are transmitted immediately. Therefore,
if a link is congested, WRR allocates bandwidth based on the weights of queues.
Unlike SP, WRR schedules packets in every queue based on weights, so even packets in lower-
priority queues have a chance to be transmitted.
SP+WRR
The SP+WRR algorithm ensures the precedence of higher-priority services (for example, voice
services) and assigns time segments to transmit lower-priority services.

l If CS7, CS6, and EF queues, which have higher priorities than WRR queues, have packets,
packets in the CS7, CS6, and EF queues are transmitted using SP whereas packets in the
WRR queues are not transmitted.
l If the CS7, CS6, and EF queues have no packets, packets in the WRR queues (AF4, AF3,
AF2, and AF1) are transmitted using WRR.
l If both WRR queues and CS7, CS6, and EF queues have no packets, packets in the lower-
priority queue (BE) are transmitted using SP.
Traffic Shaping
Shaping limits the traffic volume and burst size of an outgoing traffic stream, so that the traffic
stream can flow at a regular speed.
OptiX RTN 360 supports queue shaping and port shaping.
If shaping is enabled and the buffer queue is empty, OptiX RTN 360 processes incoming packets
as follows:
l Forwards packets directly if the packet arrival rate is lower than or equal to the preset peak
information rate (PIR).
l Pushes packets into the buffer queue if the packet arrival rate is higher than the PIR.
l Forwards some packets as burst packets if the packet arrival rate is lower than or equal to
the PIR in a certain period. The maximum burst size is equal to the peak burst size (PBS).
If the buffer queue is not empty, the system pushes newly arriving packets into the buffer queue
and then forwards them at the PIR.

QoS Model
The following figure shows QoS technologies applicable to each QoS application point in the
QoS model for Native Ethernet services.

This section lists the standards and protocols associated with quality of service (QoS).

l IETF RFC 2309: Recommendations on Queue Management and Congestion Avoidance in

the Internet
l IETF RFC 2597: Assured Forwarding PHB Group
l IETF RFC 2598: An Expedited Forwarding PHB
l IEEE 802.1p: Traffic Class Expediting and Dynamic Multicast Filtering
7.3 Specifications
This section lists the quality of service (QoS) specifications that OptiX RTN 360 supports.
Table 7-1 QoS specifications that OptiX RTN 360 supports
Item Specifications
DiffServ Maximum 1
number of
DiffServ (DS)
domains
Types of DS- Ethernet port

supporting Microwave port
ports
Classes of C-VLAN priority

service (CoSs) S-VLAN priority
trusted by ports
DSCP value
MPLS EXP value
NOTE
OptiX RTN 360 can enable or disable the mapping between DSCP
values and PHBs in the egress direction (by default, the mapping is
enabled).
l If the mapping is enabled, OptiX RTN 360 changes the DSCP
values of packets based on the mapping when the packets leave a
port.
l If the mapping is disabled, OptiX RTN 360 does not change the
DSCP values of packets when the packets leave a port.

Item Specifications
Per-hop l CS7
behaviors l CS6
(PHBs)
l EF
l AF4 (AF41, AF42, and AF43)
l BE
NOTE
l Packets mapped to the AF11, AF21, AF31, and AF41 queues are
green by default.
yellow by default.
red by default.
Comple Application Ingress direction of a port

x traffic point of
classific complex traffic
ation classification
Traffic For details, see Table 7-2.

classification
methods and
related QoS
operations
Traffic Application CAR based on ports or complex traffic classification

policing point of
committed
access rate
(CAR)
Packet Green packets pass traffic policing.

processing Red packets are dropped.
modes
Yellow packets:
l Pass traffic policing.
l Are dropped.
l Are re-marked.
Are re-colored green.
Are mapped to a newly specified PHB.
CAR Committed information rate (CIR), committed burst size

parameters (CBS), peak information rate (PIR), and peak burst size (PBS)

Item Specifications
Congesti Tail drop Both microwave ports and Ethernet ports support tail drop.
on
avoidanc WRED Both microwave ports and Ethernet ports support WRED.
e
Queue Maximum 8
scheduli number of
ng egress queues
Queue Strict priority (SP)

scheduling Weighted round robin (WRR)
algorithms
SP+WRR
NOTE
Ethernet ports and microwave ports use SP+WRR by default. The
queues in descending order of priory are CS7, CS6, EF, AF4-AF1
(WRR queues), and BE.
Weight When WRR is applied to the AF4, AF3, AF2, and AF1 queues,
allocation of the default weight (25%) of each AF queue is changeable.
WRR
Traffic Traffic shaping PIR and PBS settings are supported.

shaping for egress
queues
Traffic shaping
at egress ports
QoS Performance Counts of received and transmitted packets, traffic

related measurement performance statistics, and count of error packets, which are
perform calculated by port
ance Counts of received and transmitted packets, traffic
statistics performance statistics, and count of packets lost due to
congestion, which are calculated by traffic classification
Counts of received and transmitted packets, traffic
performance statistics, and count of packets lost due to
congestion, which are calculated by egress port queue
Table 7-2 Complex Traffic Classification
Match Item QoS Processing
C-VLAN ID l Passes or discards flows according to a preset access

control list (ACL).
C-VLAN priority
l Maps flows to new per-hop behaviors (PHBs).
S-VLAN ID l Performs rate limiting for flows based on the
committed access rate (CAR) in the ingress direction.
S-VLAN priority

Match Item QoS Processing
DSCP value
C-VLAN ID+C-VLAN priority
S-VLAN ID+S-VLAN priority
Source IPv4 address
Destination IPv4 address
Source MAC address
Destination MAC address
Protocol type
Protocol type (TCP/UDP)+Source

port ID
Protocol type (TCP/UDP)

+Destination port ID
Protocol type (ICMP)+ICMP

packet type code
7.4 Feature Updates

This section provides a history of QoS updates.
Version Description
V100R001C00 QoS was first available in this version.

This section describes the self-limitations of quality of service (QoS), and limitations and
dependencies between QoS and other features.
Table 7-3 describes the self-limitations of QoS, and limitations and dependencies between QoS
and other features.
Table 7-3 Feature dependencies and limitations
Item Description
Self- WRR At each port of the OptiX RTN 360, WRR queues must be
limitations consecutive. That is, WRR queues and SP queues cannot
interleave.

Item Description
CAR When creating CAR, specify the PHBs to which port traffic
will map, so that CAR coloring will take effect (yellow
packets can be re-colored green).
When creating port-based CAR, create a PORT+C/SVLAN-
based flow (VLAN ID = 0) and apply CAR.
Limitations Adaptive If AM is enabled, it is recommended that QoS be configured

and modulation for Ethernet services transmitted over microwave ports on the
dependencie (AM) OptiX RTN 360. After QoS is configured, Ethernet services
s between with higher priorities are transmitted first when radio links
QoS and work in a low-order modulation scheme.
other
features Data The VLAN priority of an inband DCN packet takes the default
communicati value 6. Inband DCN packets are scheduled and mapped to
on network the egress queue CS6 by default.
(DCN)

This section provides guidelines for planning quality of service (QoS). Before planning QoS,
identify the QoS requirement characteristics of services and the QoS requirements of carriers,
and consider network conditions.
Obtaining QoS Requirement Characteristics of Typical Services
Table 7-4 QoS requirement characteristics of typical services
Servi Characteristic Notes to QoS Planning

ce
Type
Voice l Low bandwidth l Network planning includes

servic l High QoS requirements (low delay, bandwidth estimation and
e low jitter, and low packet loss ratio) reservation for voice services.
l A mobile backhaul network
consisting of OptiX RTN 360s
ensures high-priority service
scheduling. It is recommended that
voice services be mapped to the EF
queue.

Servi Characteristic Notes to QoS Planning

ce
Type
Data l High bandwidth l Bandwidths are not converged for

servic l Diverse services with different QoS data services at the terminal access
e requirements layer but reserved at the convergence
layer based on the convergence ratio.
l Low delay, low jitter, and low packet
loss ratio for real-time services, such l A mobile backhaul network
as video phone and online game consisting of OptiX RTN 360s
services ensures high-priority service
l Statistical multiplexing for non-real- data services be mapped to the AF1,
time services such as Internet AF2, AF3, or AF4 queue.
accessing services, allowing a high
convergence ratio
Contr l Low bandwidth l Network planning includes

ol l High QoS requirements (low delay, bandwidth estimation and
packet low jitter, and no packet loss) reservation for control packets and
management packets.
Mana
l A mobile backhaul network
geme
consisting of OptiX RTN 360s
nt
ensures high-priority service
packet
control packets and management
packets be mapped to the CS6 or CS7
queue.
Determining QoS Requirements

When planning QoS, determine:
l Whether an end-to-end bandwidth guarantee is required.

l Whether bandwidth limiting is required.
l Whether a minimum bandwidth is required for low-priority services.
l Priority plans for various services.
Obtaining Information About Network Situations

When planning QoS, obtain the following information:
l CoSs trusted by ports

l Whether the mapping between service priorities and per-hop behaviors (PHBs) has been
specified in the wireless network plan
l Whether the transport network incorporates released third-party networks and their
available bandwidths, if any

l Bandwidths provided by the OptiX RTN 360 network and bandwidths required by service
access and transmission
l Special network situations (for example, whether there are ports that carry both services
with and without priorities)
Working out QoS Plans

If an end-to-end bandwidth guarantee is required, perform the following:
l Select simple traffic classification using DS or complex traffic classification based on the
trusted CoS.
l Configure DS based on the mapping between service priorities and PHBs. If wireless
network engineers have not yet worked out the mapping, liaise with them to determine the
mapping.
CS6 and CS7 queues always have higher priorities, and the packets in these two queues
are always scheduled first. It is recommended that these queues be used for control
packets and management packets, which require the highest scheduling priority and
very low bandwidth.
Do not place services that require high bandwidth and are insensitive to delay in high-
priority strict priority (SP) queues, such as EF. Otherwise, high-priority SP queues will
occupy all port bandwidth. It is recommended that voice services be placed in the EF
queue.
It is recommended that data services be placed in AF1, AF2, AF3, and AF4 queues
using the weighted round robin (WRR) algorithm. The scheduling weights determine
the proportion of bandwidth allocated to each queue.
l If the OptiX RTN 360 network provides a bandwidth lower than the total bandwidth to be
guaranteed, expand the network capacity.
If bandwidth limiting is required, consider the following:
l To restrict the bandwidth of services entering the RTN network based on the service type,
specify the rate limits at ingress ports for flows that are created in complex traffic
classification.
l To restrict the bandwidth of services based on PHBs (queues), perform shaping for port
queues.
l To better share the air-interface link bandwidth, do not perform shaping for microwave
ports on OptiX RTN 360 unless necessary.
If low-priority services require a guaranteed minimum bandwidth, perform shaping for port
queues of high-priority services, or configure an appropriate queue scheduling policy.
To avoid congestion, it is recommended that you configure weighted random early detection
(WRED) for microwave ports on OptiX RTN 360. WRED ensures the transmission of high-
priority services.
7.7 Related Alarms and Events

This section describes the alarms and performance events related to quality of service (QoS).

Alarms
l PORT_EXC_TRAFFIC
This alarm indicates that the bandwidth utilization at an Ethernet port has crossed the
threshold because of heavy traffic at the Ethernet port.
l ETH_NO_FLOW
This alarm indicates that there is no traffic at an enabled Ethernet port or microwave port
when the connected link is in the Up state.
l FLOW_OVER
This alarm indicates that the traffic transmitted or received at an Ethernet port or microwave
port has crossed the threshold.
Performance Events
l RXGOODFULLFRAMESPEED
This performance event indicates the rate of receiving good packets at a port.
l TXGOODFULLFRAMESPEED
This performance event indicates the rate of transmitting good packets from a port.

Feature Description 8 ETH OAM
8 ETH OAM
About This Chapter
ETH OAM detects and monitors the connectivity and performance of service links using OAM
protocol data units (PDUs). ETH OAM does not affect services.
8.1 Introduction
This section introduces ETH OAM.

This section lists the standards and protocols associated with ETH OAM.
8.3 Specifications
This section provides the ETH OAM specifications that OptiX RTN 360 supports.
8.4 Feature Updates

This section provides a history of ETH OAM updates.

This section describes the dependencies and limitations of ETH OAM.

This section provides guidelines for planning ETH OAM.
8.7 Related Alarms

This section describes the alarms related to ETH OAM.

8.1 Introduction
This section introduces ETH OAM.
Definition
ETH OAM uses OAM protocol data units (PDUs) to perform OAM operations at Ethernet Layer
2. ETH OAM is a low-rate protocol that is independent of the transmission medium. It occupies
minimal bandwidth and, therefore, does not affect services.
l Ethernet service OAM focuses on end-to-end maintenance of Ethernet links. Based on

services, Ethernet service OAM manages each network segment that a service traverses.
l Ethernet port OAM focuses on point-to-point maintenance of Ethernet links between two
directly connected devices in the last mile. Ethernet port OAM, independent of services,
performs OAM automatic discovery, link performance monitoring, remote loopback
detection, and local loopback detection to maintain a point-to-point Ethernet link.
Ethernet Service OAM

OptiX RTN 360 supports Ethernet service OAM that uses the management architecture defined
in IEEE 802.1ag. This management architecture specifies maintenance points (MPs),
maintenance domains (MDs), maintenance associations (MAs), allowing services to be managed
by section and by layer.
MPs are classified into maintenance association end points (MEPs) and maintenance association
intermediate points (MIPs).
l MEP
An MEP specifies the start and end positions of an MA. It initiates or terminates an OAM
packet, and is associated with services.
l MIP
An MIP cannot initiate an OAM packet but can respond to an OAM test.

An MD refers to a network that requires OAM.
Ethernet service OAM performs end-to-end detection based on the MD. In OAM, an MD is a
collection of all the MPs in a service instance. These MPs include MEPs and MIPs.
An MA is a domain that is associated with services.
On an operator network, one VLAN corresponds to one service instance. With regard to OAM,
one VLAN corresponds to one or more MAs. By defining MAs, you can detect faults in a VLAN
service instance.
Ethernet service OAM provides layered management by adding the management level fields to
OAM protocol packets.
Currently, the ETH OAM protocol supports an 8-level division, from level 0 to level 7, where
0 is the lowest level and 7 the highest. In addition, eight maintenance entity (ME) levels are
allocated for identifying OAM packets used by customers, service providers, and operators.
l Customer ME levels: 7, 6, 5
l Service provider ME levels: 4, 3
l Operator ME levels: 2, 1, 0
ME levels are ordered from highest to lowest as follows: customer ME levels > service provider
ME levels > operator ME levels. If OAM operations are performed based on different layers, a
high-layer MP must not be located between low-layer MPs.

The following table provides details on the operations and their application scenarios of Ethernet
service OAM.
Table 8-1 Operations and application scenarios of Ethernet service OAM
Operation Description Application Scenario
CC Periodically exchanges l CC tests unidirectional

continuity check messages continuity of links in real
(CCMs) to detect the time.
connectivity between MEPs. l To locate a faulty link
NOTE segment, use LT, because
Only an MEP can initiate or CC cannot accurately
respond to a CC test.
locate a faulty link
segment.
LB Detects the status of a link l LB tests bidirectional

from the source MEP to any continuity of links in real
MEP in an MD. time.
NOTE l Unlike CC, LB provides
Only an MEP can initiate or one-time detection. One
terminate an LB test.
command initiates one
LB test.
l LB cannot locate which
link is faulty in one
attempt.

LT Locates which link is faulty l LT is also used to locate a

in one attempt. LT is an faulty point.
enhancement of LB. l Unlike those in an LB test,
NOTE all the MPs in an LT test
Only an MEP can initiate or respond to link trace
terminate an LT test.
messages (LTMs). The
response messages
identify all the MIPs from
the source MEP to the
sink MEP.
AIS activation Reports a fault to a higher- AIS activation is used when a

level MP. When an MP with fault must be reported to a
AIS enabled detects a fault, it higher-level MP.
sends the AIS packet to its
higher-level MP to notify its
higher-level MP of the fault.
If AIS is disabled for an MP,
the MP does not report any
detected fault.
LM Measures the packet loss rate LM measures the packet loss

between two MEPs. It works rate of Ethernet services.
in two modes:
l Single-ended LM
l Dual-ended LM
NOTE
The OptiX RTN 360 supports
only single-ended LM.
DM Measures the delay generated DM measures the delay of

in the transmission of E-Line Ethernet services.
services between two MEPs.
It works in two modes:
l One-way DM
l Two-way DM
NOTE
The OptiX RTN 360 supports
only two-way DM.
Service loopback Checks whether packets in an Service loopback checks

E-LAN service are looped whether packets in an E-LAN
back. service are looped back.
NOTE
Service loopback does not
require MEPs.

Ethernet Port OAM

The following table provides details on the operations and application scenarios of Ethernet port
OAM.
Table 8-2 Operations and application scenarios of Ethernet port OAM
OAM automatic discovery Two nodes periodically l OAM automatic

exchange information OAM discovery searches for
protocol data units (PDUs) to network nodes and
inform each other of their identifies their OAM
capabilities in supporting capabilities.
IEEE 802.3ah. l An alarm is reported
when OAM automatic
discovery fails.
l A successful OAM
automatic discovery is a
prerequisite for
implementing link
performance monitoring
and remote loopbacks.
That is, link performance
monitoring and loopback
operations are available at
a port only when an OAM
automatic discovery is
successful.

Link performance Monitors the bit error l This function monitors

monitoring performance (error frames or the performance of
error signals) of a link. On services on a link in real
detecting excessive bit time.
errors, the local end sends the l This function can achieve
bit error event to the opposite quantitative analysis and
end through the event precise monitoring.
notification OAM PDU. The
opposite end then reports the l Based on actual
corresponding alarm. requirements, configure
window values and
threshold values of link
performance events on
the NMS. Then, whether
the link performance
degrades to the threshold
can be detected.
NOTE
Link performance
monitoring provides
detailed statistics about
error frames, error frame
seconds, and error frame
periods.
Remote loopback The OAM entity at the local In a remote loopback, the
end transmits the loopback initiator transmits and
control OAM PDU to the receives a number of packets.
remote OAM entity to By comparing the two
request a loopback. The numbers, you can check the
loopback data is analyzed for bidirectional performance of
fault locating and link the link between the initiator
performance testing. and the responder.
Local loopback detection Enables an Ethernet unit to l This function detects a

detect whether a port receives port loopback.
packets that are transmitted l This function also
by itself. facilitates loop detection
during networking and
report the specific alarm
to users.

This section lists the standards and protocols associated with ETH OAM.
l IEEE 802.1ag: Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault
Management

l IEEE 802.3ah: Media Access Control Parameters, Physical Layers, and Management
Parameters for Subscriber Access Networks
l ITU-T Y.1731: OAM functions and mechanisms for Ethernet based networks
8.3 Specifications
This section provides the ETH OAM specifications that OptiX RTN 360 supports.
Table 8-3 ETH OAM specifications that OptiX RTN 360 supports
Item Specifications
OAM operation CC
LB
LT
AIS activation
LM
DM
Service loopback
Maximum number of MDs 16
Maximum number of MAs 16
Maximum number of MEPs 16

and MIPs
Supported MP type Standard MP (IEEE 802.1ag Draft 8.0)
CCM transmission period 3.3 ms

10 ms
100 ms
1s (default value)
10s
1 min
10 min
NOTE
The CC packet transmission interval for E-LAN services on OptiX
RTN 360 must be no less than 1s.

Table 8-4 Specifications of Ethernet port OAM
Item Specifications
OAM operation OAM automatic discovery

Link performance monitoring
Remote loopback
Local loopback detection
Error frame monitoring Supported

events
Frame seconds monitoring Supported

events
Frame periods monitoring Supported

events
OAM mode Active

Passive
8.4 Feature Updates

This section provides a history of ETH OAM updates.
Version Description
V100R001C00 ETH OAM was first available in this version.

This section describes the dependencies and limitations of ETH OAM.

Table 8-5 Dependencies and limitations of ETH OAM
Item Description
Self-limitations l The OptiX RTN 360 supports only single-ended LM.

l The OptiX RTN 360 supports two-way DM.
l The OptiX RTN 360 supports LM and DM only when it
transmits VLAN-based E-line servicesa.
NOTE
a: VLAN-based E-line services refer to the Native Ethernet E-
line services from PORT+CVLAN (source) to PORT+CVLAN
(sink) and from PORT+SVLAN List (source) to PORT+CVLAN
List (sink).
l An MEP responds only to OAM operations initiated by
the MEPs that belong to the same MA. For the OptiX RTN
360, to include the initiator MEPs and responder MEPs in
the same MA, you must configure an MEP that will initiate
OAM operations as a remote MEP.

This section provides guidelines for planning ETH OAM.
Planning Guidelines for Ethernet Service OAM

l To run Ethernet service OAM, first plan maintenance domains (MDs), maintenance
associations (MAs), and maintenance points (MPs).
l When you create an MD, follow these guidelines:
An MD name identifies a unique MD on a network.
Multiple MDs can be embedded or tangent. A higher level MD can embed a lower level
MD, but higher level MDs and lower level MDs cannot be alternative.
To test Ethernet services between edge nodes of a transport network, create a level 4
MD; to test Ethernet services between intermediate nodes of a transport network, create
an MD with a level lower than 4.
l When you create an MA, follow these guidelines:
An MA must belong to only one MD.
An MA name must be unique in the MD to which it belongs. MAs in different MDs can
have the same name.
An MA must be associated with a service.
Set the same CCM transmission period for all MEPs that belong to the same MA. A
shorter CCM transmission period results in faster CC operation but occupies more NE
and bandwidth resources. Set the CCM transmission period to the default value (1s).
l When you create an MP, follow these guidelines:
To perform the CC, LB, LM, or DM, create MEPs at both ends of a service; to perform
the LT, create MEPs at both ends and MIPs at the intermediate nodes of a service.

All MEPs and MIPs involved in an OAM test must belong to the same MA.
The MAC addresses of the MEPs and MIPs involved in an OAM test must be different.
Each MP in a single MA must have a unique ID.
If a service being tested passes a packet switching unit, set the MEP direction to Ingress;
if a service being tested does not pass any packet switching unit, set the MEP direction
to Egress.
For each NE that has an MEP, configure a list of remote MEPs with which that MEP
interacts.
l When you plan OAM operations, follow these guidelines:
Select appropriate OAM operations.
When performing an LB/LT test, you can use an MP ID or a MAC address to identify
a sink.
Activate the CC function before you use an MP ID to identify a sink.
If the AIS is activated on an MEP, the level of the customer layer should be higher than
that of the MD to which the MEP belongs.
Service loop detection does not require the creation of MDs, MAs, or MPs.
Planning Guidelines for Ethernet Port OAM

l Only the end in Active mode can initiate OAM automatic discovery or a remote loopback.
The OAM modes can be set to Active at both ends, or Active at one end and Passive at the
other end. The Passive mode cannot be set at both ends.
l Select appropriate OAM functions.
l Local loopback detection does not require the cooperation of OAM automatic discovery.
8.7 Related Alarms

This section describes the alarms related to ETH OAM.
Alarms
l ETH_CFM_AIS
This alarm indicates local MEP AIS. This alarm occurs when the system receives AIS
messages, indicating that a fault occurred at the server layer.
l ETH_CFM_LOC
This alarm indicates loss of continuity. When the system does not receive any CCMs from
its peer for an interval 3.5 times the CCM transmission period, the system reports an
ETH_CFM_LOC alarm.
l ETH_CFM_MISMERGE
This alarm indicates an incorrect connection. When the system receives a CCM with an
incorrect MA name, the system reports an ETH_CFM_MISMERGE alarm.
l ETH_CFM_RDI
This alarm indicates that the remote MEP fails to receive CCMs. When the system receives
a CCM that contains the RDI from its peer, the system reports an ETH_CFM_RDI alarm.

l ETH_CFM_UNEXPERI
This alarm indicates error frames. When the system receives an invalid CCM (that is, the
transmission period of the received CCM is different from the preset value), the system
reports an ETH_CFM_UNEXPERI alarm.
l ETH_EFM_DF
This alarm indicates the failure of OAM automatic discovery. When point-to-port OAM
protocol negotiation fails on Ethernet ports, the system reports an ETH_EFM_DF alarm.
l ETH_EFM_EVENT
This alarm indicates that a performance event occurs at the remote end. When the system
receives the event notification OAM PDU (indicating bit errors on the link) from its peer,
the system reports an ETH_EFM_EVENT alarm.
l ETH_EFM_LOOPBACK
This alarm indicates that a loopback is performed. When the system initiates or responds
to a loopback, the system reports an ETH_EFM_LOOPBACK alarm.
l ETH_EFM_REMFAULT
This alarm indicates that a fault occurs at the remote end. When the system receives the
event notification OAM PDU (indicating a fault at the remote end) from its peer, the system
reports an ETH_EFM_REMFAULT alarm.
l ETHOAM_SELF_LOOP
This alarm indicates that a local loopback occurs. After the local loopback detection is
enabled on a port, the port reports the ETHOAM_SELF_LOOP alarm if it receives the
OAM packet that it transmitted previously.

Feature Description 9 Physical Layer Clock Synchronization
9 Physical Layer Clock Synchronization
About This Chapter
Physical layer clock synchronization enables RTN equipment to obtain clock information from
data code streams to implement clock synchronization.
9.1 Introduction
This section introduces the physical layer clock synchronization solution.

This section describes the standards and protocols associated with physical layer clock
synchronization.
9.3 Specifications
This section lists the physical layer clock synchronization specifications that OptiX RTN 360
supports.
9.4 Feature Updates

This section provides a history of physical layer clock synchronization updates.

This section describes the dependencies and limitations of physical layer clock synchronization.

This section provides guidelines for planning physical layer clock synchronization.
9.7 Related Alarms

This section describes the alarms related to physical layer clock synchronization.

9.1 Introduction
This section introduces the physical layer clock synchronization solution.
Clock Synchronization
In a broad sense, clock synchronization includes frequency synchronization and time
synchronization. Generally, clock synchronization refers to frequency synchronization.
Frequency synchronization means that the frequencies or phases of signals maintain a certain
and strict relationship. The valid instants of these signals appear at the same average rate so that
all the equipment on the communications network can operate at the same rate. That is, the phase
difference between signals is constant.
Clock synchronization is a basic condition for synchronous digital communication. Different

from asynchronous communication, synchronous communication does not require byte
preambles, which more effectively leverages channel bandwidth.
l For transport networks, clock synchronization must be implemented to accurately sample

digital signals transmitted over the networks. Clock synchronization ensures that all the
digital devices on a communications network work at the same nominal frequency, and
therefore minimizes the impacts of slips, burst bit errors, phase jumps, jitters, and wanders
on digital communications systems.
Figure 9-1 Clock synchronization diagram
l For mobile communication networks and other service networks, not only signal
transmission but also communication services require clock synchronization. If clock
synchronization is not implemented, exceptions will occur, such as call drops and inter-cell
handover failures.

physical Layer Clock Synchronization

Physical layer clock synchronization is a process that clock frequencies are recovered directly
from physical signals. Physical layer clock synchronization is the most commonly used and the
most reliable clock synchronization mode.
Digital signals transmitted on lines or links are coded or scrambled to reduce consecutive '0's or
'1's. Therefore, the code stream carries plentiful clock information. The clock information can
be extracted by applying phase lock and filter technologies and used for synchronization
references.
Microwave links, synchronous Ethernet links, and SDH lines can all provide timing information.
For example, gigabit Ethernet uses 8B/10B encoding signals. Even all '0's or all '1's original data
can be converted into line encoding signals with balanced "0"s and "1"s.
Figure 9-2 Clock information and line encoding signals
Clock Source
A clock source is a signal source carrying timing reference information. To achieve clock
synchronization, an NE keeps its local clock in phase with the timing information by using the
phase-locked loop (PLL).
The Product supports the following clock sources:

l Microwave clock source: Timing information is extracted from signal streams on radio
links.
l Ethernet clock source: Timing information is extracted from Ethernet signal streams.
Multiple clock sources can be configured for an NE. Clock source protection is implemented
based on the priorities configured in the clock source priority list. When the clock source of a
higher priority fails, the clock source of a lower priority is used.

Figure 9-3 Clock source selection and protection
Clock Synchronization of One Microwave Link Hop

When two OptiX RTN 360s form a microwave link hop, the OptiX RTN 360s at the two ends
of the link are configured as the master and slave NEs. By default, the master NE traces the
synchronous Ethernet clock, and the slave NE traces the microwave link clock. Therefore,
configure the OptiX RTN 360 on the macro base station side as the master NE, and the OptiX
RTN 360 on the small cell base station side as the slave NE.
Figure 9-4 Ring network and SSM protection.


This section describes the standards and protocols associated with physical layer clock
synchronization.
l ITU-T G.781: Synchronization layer functions

l ITU-T G.8261/Y.1361: Timing and Synchronization aspects in Packet Networks
l ITU-T G.8262: Timing characteristics of synchronous Ethernet Equipment slave clock
(EEC)
l ITU-T G.8264: Distribution of timing through packet networks
9.3 Specifications
This section lists the physical layer clock synchronization specifications that OptiX RTN 360
supports.
Table 9-1 Physical layer clock synchronization specifications that OptiX RTN 360 supports
Item Specification
Working mode of clock l Tracing mode

l Free-run mode
Clock source l Microwave link clock

l Synchronous Ethernet clock
Clock tracing mode In one hop of microwave links:

l By default, the master NE traces the synchronous Ethernet
clock.
l By default, the slave NE traces the microwave link clock.
Synchronous Ethernet Supported.
External clock interface Not supported
Clock frequency accuracy 50 ppb

(locked mode)
Synchronization status Supported

message (SSM) protocol and NOTE
extended SSM protocol OptiX RTN 360 does not support ring networking, but can work with
upstream NEs to use the SSM protocol and extended SSM protocol.
9.4 Feature Updates

This section provides a history of physical layer clock synchronization updates.

Version Description
V100R001C00 Physical layer clock synchronization was first

available in this version.

This section describes the dependencies and limitations of physical layer clock synchronization.
Table 9-2 describes the dependencies and limitations of physical layer clock synchronization.
Table 9-2 Dependencies and limitations of physical layer clock synchronization
Item Description
Synchronous Ethernet Ethernet ports that use SFP electrical modules or work in 10BASE-
T mode or half-duplex mode do not support synchronous Ethernet.

This section provides guidelines for planning physical layer clock synchronization.
NOTE
OptiX RTN 360 is usually used for transmitting services from small cell base stations at the network tail.
The following describes only the clock planning guidelines of OptiX RTN 360. For the clock planning
guidelines of upstream NEs, see the planning guidelines of the corresponding products.
l When two OptiX RTN 360s form a microwave link hop, the OptiX RTN 360s at the two
ends of the link are configured as the master and slave NEs. By default, the master NE
traces the synchronous Ethernet clock, and the slave NE traces the microwave link clock.
Therefore, configure the OptiX RTN 360 on the macro base station side as the master NE,
and the OptiX RTN 360 on the small cell base station side as the slave NE.
l It is recommended that an OptiX RTN 360 chain network contain a maximum of three
microwave link hops, that is, 6 NEs.
l Small cell base stations at the network tail connected to OptiX RTN 360 can obtain
reference clock signals through synchronous Ethernet ports.
9.7 Related Alarms

This section describes the alarms related to physical layer clock synchronization.
l The CLK_LOCK_FAIL alarm indicates a clock locking failure.

l The CLK_NO_TRACE_MODE alarm indicates that the clock source is not in trace mode.
l The LTI alarm indicates loss of all synchronization sources.
l The S1_SYN_CHANGE alarm indicates that the clock source is switched because of a
change in synchronization status messages (SSMs) of the S1 byte.

l The SYNC_C_LOS alarm indicates that the class of a synchronization source is lost.

Feature Description A Glossary
A Glossary
Numerics
802.11n A wireless transmission standard released after 802.11a/b/g by Wi-Fi Alliance. As a new
member to the 802.11 protocol family, 802.11n supports the 2.4 GHz and 5 GHz
frequency bands and provides a higher bandwidth (300 Mbit/s, much higher than the 54
Mbit/s provided by 802.11a/g) for WLAN access users. In addition, 802.11n supports
the MIMO technology, which provides two methods of increasing the communication
rate: by increasing the bandwidth and by improving the channel usage.
802.1Q in 802.1Q A VLAN feature that allows the equipment to add a VLAN tag to a tagged frame. The
(QinQ) implementation of QinQ is to add a public VLAN tag to a frame with a private VLAN
tag to allow the frame with double VLAN tags to be transmitted over the service
provider's backbone network based on the public VLAN tag. This provides a layer 2
VPN tunnel for customers and enables transparent transmission of packets over private
VLANs.
A
AC alternating current
adjacent-channel Interference from the adjacent channel. Adjacent-channel interference is caused by the
interference defect in the receiver filter, which allows the signal on the adjacent channel to penetrate
into the transmission bandwidth.
B
baseband A form of modulation in which the information is applied directly onto the physical
transmission medium.
blacklist A list containing information about subscribers who are prohibited from using certain
permissions or services due to certain reasons.
bridge A device that connects two or more networks and forwards packets among them. Bridges
operate at the physical network level. Bridges differ from repeaters because bridges store
and forward complete packets, while repeaters forward all electrical signals. Bridges
differ from routers because bridges use physical addresses, while routers use IP
addresses.

C
CAR committed access rate
CBS See committed burst size.
CIR committed information rate
CPU See central processing unit.
cabinet Free-standing and self-supporting enclosure for housing electrical and/or electronic
equipment. It is usually fitted with doors and/or side panels which may or may not be
removable.
cell A cell is a radio coverage area identified by either base station identity code or cell global
identification (CGI). A cell with an omni-directional antenna is a BTS area.
central processing unit The computational and control unit of a computer. The CPU is the device that interprets
(CPU) and executes instructions. The CPU has the ability to fetch, decode, and execute
instructions and to transfer information to and from other resources over the computer's
main data-transfer path, the bus.
channel spacing The center-to-center difference in frequencies or wavelengths between adjacent channels
in a WDM device.
committed burst size A parameter used to define the capacity of token bucket C, that is, the maximum burst
(CBS) IP packet size when information is transferred at the committed information rate. This
parameter must be greater than 0 but should be not less than the maximum length of an
IP packet to be forwarded.
D
DC direct current
DCC See data communications channel.
DCN See data communication network.
DIP switch dual in-line package switch
DSCP See differentiated services code point.
DiffServ See Differentiated Services.
Differentiated Services An IETF standard that defines a mechanism for controlling and forwarding traffic in a
(DiffServ) differentiated manner based on CoS settings to handle network congestion.
data communication A communication network used in a TMN or between TMNs to support the data
network (DCN) communication function.
data communications The data channel that uses the D1-D12 bytes in the overhead of an STM-N signal to
channel (DCC) transmit information on the operation, management, maintenance, and provisioning
(OAM&P) between NEs. The DCC channel composed of bytes D1-D3 is referred to as
the 192 kbit/s DCC-R channel. The other DCC channel composed of bytes D4-D12 is
referred to as the 576 kbit/s DCC-M channel.

differentiated services According to the QoS classification standard of the Differentiated Service (Diff-Serv),
code point (DSCP) the type of services (ToS) field in the IP header consists of six most significant bits and
two currently unused bits, which are used to form codes for priority marking.
Differentiated services code point (DSCP) is the six most important bits in the ToS. It is
the combination of IP precedence and types of service. The DSCP value is used to ensure
that routers supporting only IP precedence can be used because the DSCP value is
compatible with IP precedence. Each DSCP maps a per-hop behavior (PHB). Therefore,
terminal devices can identify traffic using the DSCP value.
E
E-LAN See Ethernet local area network.
E-Line See Ethernet line.
ESD electrostatic discharge
ETSI See European Telecommunications Standards Institute.
Ethernet A LAN technology that uses the carrier sense multiple access with collision detection
(CSMA/CD) media access control method. The Ethernet network is highly reliable and
easy to maintain. The speed of an Ethernet interface can be 10 Mbit/s, 100 Mbit/s, 1000
Mbit/s, or 10,000 Mbit/s.
Ethernet line (E-Line) A type of Ethernet service that is based on a point-to-point EVC (Ethernet virtual
connection).
Ethernet local area A type of Ethernet service that is based on a multipoint-to-multipoint EVC (Ethernet
network (E-LAN) virtual connection).
European A standards-setting body in Europe. Also the standards body responsible for GSM.
Telecommunications
Standards Institute
(ETSI)
F
FDD See frequency division duplex.
FE fast Ethernet
FEC See forward error correction.
forward error A bit error correction technology that adds correction information to the payload at the
correction (FEC) transmit end. Based on the correction information, the bit errors generated during
transmission can be corrected at the receive end.
frequency division An application in which channels are divided by frequency. In an FDD system, the uplink
duplex (FDD) and downlink use different frequencies. Downlink data is sent through bursts. Both
uplink and downlink transmission use frames with fixed time length.
G
GE Gigabit Ethernet
GUI graphical user interface

H
hop A network connection between two distant nodes. For Internet operation a hop represents
a small step on the route from one main computer to another.
I
ICMP See Internet Control Message Protocol.
IDU See indoor unit.
IEC International Electrotechnical Commission
IF See intermediate frequency.
Internet Control A network layer protocol that provides message control and error reporting between a
Message Protocol host server and an Internet gateway.
(ICMP)
indoor unit (IDU) The indoor unit of the split-structured radio equipment. It implements accessing,
multiplexing/demultiplexing, and intermediate frequency (IF) processing for services.
intermediate frequency The transitional frequency between the frequencies of a modulated signal and an RF
(IF) signal.
J
jitter The measure of short waveform variations caused by vibration, voltage fluctuations, and
control system instability.
L
LLDP See Link Layer Discovery Protocol.
LOS line of sight
LPT link-state pass through
Layer 2 switching A data forwarding method. In a LAN, a network bridge or 802.3 Ethernet switch
transmits and distributes packet data based on the MAC address. Since the MAC address
is at the second layer of the OSI model, this data forwarding method is called Layer 2
switching.
Link Layer Discovery The Link Layer Discovery Protocol (LLDP) is an L2D protocol defined in IEEE 802.1ab.
Protocol (LLDP) Using the LLDP, the NMS can rapidly obtain the Layer 2 network topology and changes
in topology when the network scales expand.
M
MAC See Media Access Control.
MD5 See message digest algorithm 5.
MDI medium dependent interface
MPLS See Multiprotocol Label Switching.
MTBF See mean time between failures.

MTTR See mean time to repair.

Media Access Control A protocol at the media access control sublayer. The protocol is at the lower part of the
(MAC) data link layer in the OSI model and is mainly responsible for controlling and connecting
the physical media at the physical layer. When transmitting data, the MAC protocol
checks whether to be able to transmit data. If the data can be transmitted, certain control
information is added to the data, and then the data and the control information are
transmitted in a specified format to the physical layer. When receiving data, the MAC
protocol checks whether the information is correct and whether the data is transmitted
correctly. If the information is correct and the data is transmitted correctly, the control
information is removed from the data and then the data is transmitted to the LLC layer.
Multiprotocol Label A technology that uses short tags of fixed length to encapsulate packets in different link
Switching (MPLS) layers, and provides connection-oriented switching for the network layer on the basis of
IP routing and control protocols.
mean time between The average time between consecutive failures of a piece of equipment. It is a measure
failures (MTBF) of the reliability of the system.
mean time to repair The average time that a device will take to recover from a failure.
(MTTR)
message digest A hash function that is used in a variety of security applications to check message
algorithm 5 (MD5) integrity. MD5 processes a variable-length message into a fixed-length output of 128
bits. It breaks up an input message into 512-bit blocks (sixteen 32-bit little-endian
integers). After a series of processing, the output consists of four 32-bit words, which
are then cascaded into a 128-bit hash number.
microwave The portion of the electromagnetic spectrum with much longer wavelengths than infrared
radiation, typically above about 1 mm.
N
NE network element
NE Panel A graphical user interface, of the network management system, which displays subracks,
boards, and ports on an NE. On the NE Panel, the user can complete most of the
configuration, management and maintenance functions for an NE.
NM network management
NSF non-stop forwarding
NTP Network Time Protocol
O
O&M operation and maintenance
OAM See operation, administration and maintenance.
OSPF See Open Shortest Path First.
Open Shortest Path A link-state, hierarchical interior gateway protocol (IGP) for network routing that uses
First (OSPF) cost as its routing metric. A link state database is constructed of the network topology,
which is identical on all routers in the area.

operation, A set of network management functions that cover fault detection, notification, location,
administration and and repair.
maintenance (OAM)
P
P&E power and Ethernet
PBS See peak burst size.
PIR peak information rate
PRBS See pseudo random binary sequence.
PSE See power sourcing equipment.
PoE power over Ethernet
patch An independent software unit used for fixing the bugs in software.
peak burst size (PBS) A parameter that defines the capacity of token bucket P, that is, the maximum burst IP
packet size when the information is transferred at the peak information rate.
polarization A kind of electromagnetic wave, the direction of whose electric field vector is fixed or
rotates regularly. Specifically, if the electric field vector of the electromagnetic wave is
perpendicular to the plane of horizon, this electromagnetic wave is called vertically
polarized wave; if the electric field vector of the electromagnetic wave is parallel to the
plane of horizon, this electromagnetic wave is called horizontal polarized wave; if the
tip of the electric field vector, at a fixed point in space, describes a circle, this
electromagnetic wave is called circularly polarized wave.
power sourcing A piece of equipment that provides power to network devices (switches or hubs for
equipment (PSE) instance) by setting up a Power over Ethernet (PoE).
pseudo random binary A sequence that is random in the sense that the value of each element is independent of
sequence (PRBS) the values of any of the other elements, similar to a real random sequence.
Q
QinQ See 802.1Q in 802.1Q.
QoS See quality of service.
quality of service (QoS) A commonly-used performance indicator of a telecommunication system or channel.
Depending on the specific system and service, it may relate to jitter, delay, packet loss
ratio, bit error ratio, and signal-to-noise ratio. It functions to measure the quality of the
transmission system and the effectiveness of the services, as well as the capability of a
service provider to meet the demands of users.
R
RADIUS An authentication mode in which the BRAS sends the user name and the password to
authentication the RADIUS server by using the RADIUS protocol. The RADIUS server authenticates
the user, and then returns the result to the BRAS.
RF See radio frequency.
RFC remote feature control

RMON See remote monitor.

RSL See received signal level.
RSSI See received signal strength indicator.
RTN radio transmission node
RoHS restriction of the use of certain hazardous substances
radio frequency (RF) A type of electric current in the wireless network using AC antennas to create an
electromagnetic field. It is the abbreviation of high-frequency AC electromagnetic wave.
The AC with the frequency lower than 1 kHz is called low-frequency current. The AC
with frequency higher than 10 kHz is called high-frequency current. RF can be classified
into such high-frequency current.
received signal level The signal level at a receiver input terminal.
(RSL)
received signal strength The received wide band power, including thermal noise and noise generated in the
indicator (RSSI) receiver, within the bandwidth defined by the receiver pulse shaping filter, for TDD
within a specified timeslot. The reference point for the measurement shall be the antenna
remote monitor A widely used network management standard defined by the IETF, and it enhances the
(RMON) MIB II standard greatly. It is mainly used to monitor the data traffic over a network
segment or the entire network. RMON is completely based on the SNMP architecture,
including the NMS and the Agent running on each network device.
S
S-VLAN service virtual local area network
SFTP See Secure File Transfer Protocol.
SNMP See Simple Network Management Protocol.
SNR See signal-to-noise ratio.
SSID service set identifier
SSL See Secure Sockets Layer.
Secure File Transfer A network protocol designed to provide secure file transfer over SSH.
Protocol (SFTP)
Secure Sockets Layer A security protocol that works at a socket level. This layer exists between the TCP layer
(SSL) and the application layer to encrypt/decode data and authenticate concerned entities.
Simple Network A network management protocol of TCP/IP. It enables remote users to view and modify
Management Protocol the management information of a network element. This protocol ensures the
(SNMP) transmission of management information between any two points. The polling
mechanism is adopted to provide basic function sets. According to SNMP, agents, which
can be hardware as well as software, can monitor the activities of various devices on the
network and report these activities to the network console workstation. Control
information about each device is maintained by a management information block.
signal-to-noise ratio The ratio of the amplitude of the desired signal to the amplitude of noise signals at a
(SNR) given point in time. SNR is expressed as 10 times the logarithm of the power ratio and
is usually expressed in dB.

T
TCP/IP Transmission Control Protocol/Internet Protocol
TDD time division duplex
TLS Transport Layer Security
TMN See telecommunications management network.
tail drop A congestion management mechanism, in which packets arrive later are discarded when
the queue is full. This policy of discarding packets may result in network-wide
synchronization due to the TCP slow startup mechanism.
telecommunications A protocol model defined by ITU-T for managing open systems in a communications
management network network. TMN manages the planning, provisioning, installation, and OAM of
(TMN) equipment, networks, and services.
throughput The maximum transmission rate of the tested object (system, equipment, connection,
service type) when no packet is discarded. Throughput can be measured with bandwidth.
traffic classification A function that enables you to classify traffic into different classes with different
priorities according to some criteria. Each class of traffic has a specified QoS in the entire
network. In this way, different traffic packets can be treated differently.
traffic shaping A way of controlling the network traffic from a computer to optimize or guarantee the
performance and minimize the delay. It actively adjusts the output speed of traffic in the
scenario that the traffic matches network resources provided by the lower layer devices,
avoiding packet loss and congestion.
U
UNI See user-to-network interface.
USB See Universal Serial Bus.
Universal Serial Bus A serial bus standard to interface devices. It was designed for computers such as PCs
(USB) and the Apple Macintosh, but its popularity has prompted it to also become commonplace
on video game consoles and PDAs.
user-to-network The interface between user equipment and private or public network equipment (for
interface (UNI) example, ATM switches).
V
V-UNI See virtual user-network interface.
VLAN virtual local area network
virtual user-network A virtual user-network interface, works as an action point to perform service
interface (V-UNI) classification and traffic control in HQoS.
W
WAN wide area network
WEEE waste electrical and electronic equipment
WRED See weighted random early detection.

WRR weighted round robin

Web LCT The local maintenance terminal of a transport network, which is located at the NE
management layer of the transport network.
Wi-Fi See Wireless Fidelity.
Wireless Fidelity (Wi- A short-distant wireless transmission technology. It enables wireless access to the
Fi) Internet within a range of hundreds of feet wide.
weighted random early A packet loss algorithm used for congestion avoidance. It can prevent the global TCP
detection (WRED) synchronization caused by traditional tail-drop. WRED is favorable for the high-priority
packet when calculating the packet loss ratio.


RTN 360 V100R001C00 Feature Description 01

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RTN 360 V100R001C00 Feature Description 01

Uploaded by

Copyright:

Available Formats

OptiX RTN 360 Radio Transmission System

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 01 (2014-04-30) Huawei Proprietary and Confidential i

About This Document

Product Name Version

OptiX RTN 360 V100R001C00

iManager U2000T V200R014C50

iManager U2000M V200R014C00

This document is intended for:

l Network planning engineers

Indicates an imminently hazardous situation

Issue 01 (2014-04-30) Huawei Proprietary and Confidential ii

Indicates a potentially hazardous situation

Indicates a potentially hazardous situation

Indicates a potentially hazardous situation

Calls attention to important information, best

Times New Roman Normal paragraphs are in Times New Roman.

Boldface Names of files, directories, folders, and users are in

Italic Book titles are in italics.

Courier New Examples of information displayed on the screen are in

Boldface The keywords of a command line are in boldface.

Issue 01 (2014-04-30) Huawei Proprietary and Confidential iii

Italic Command arguments are in italics.

[] Items (keywords or arguments) in brackets [ ] are optional.

{ x | y | ... } Optional items are grouped in braces and separated by

[ x | y | ... ] Optional items are grouped in brackets and separated by

{ x | y | ... }* Optional items are grouped in braces and separated by

[ x | y | ... ]* Optional items are grouped in brackets and separated by

Boldface Buttons, menus, parameters, tabs, window, and dialog titles

> Multi-level menus are in boldface and separated by the ">"

Issue 01 (2014-04-30) Huawei Proprietary and Confidential iv

About This Document.....................................................................................................................ii

5 Interference Check and Dynamic Frequency Selection.......................................................34

Issue 01 (2014-04-30) Huawei Proprietary and Confidential v

5.3 Feature Updates............................................................................................................................................................37

9 Physical Layer Clock Synchronization....................................................................................74

Issue 01 (2014-04-30) Huawei Proprietary and Confidential vi

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 1

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 2

NE Types on the DCN

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 3

An NE ID is used for application layer communication. An NE ID contains three bytes among

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 4

An NE IP address is used for IP communication. By default, the NE IP address and NE ID of

Once an NE IP address is changed manually, the association relationship between the NE ID

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 5

About This Chapter

2.2 Reference Standards and Protocols

2.4 Feature Updates

2.5 Feature Dependencies and Limitations

2.6 Planning Guidelines

2.7 Related Alarms

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 6

Application of the IP DCN solution

IP DCN Protocol Stack

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 7

Transferring Packets Based on the IP Protocol Stack

In gateway access mode, the packets are transferred as follows:

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 8

In direct access mode, the packets are transferred in a different way.

Traversing the L2 Network

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 9