IPv6 Transmission (SRAN18.1 - Draft A)

SingleRAN
IPv6 Transmission Feature

Parameter Description
Issue Draft A
Date 2021-12-30
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2022. 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: https://www.huawei.com
Email: support@huawei.com
Issue Draft A Copyright © Huawei Technologies Co., Ltd. i

(2021-12-30)
SingleRAN
IPv6 Transmission Feature Parameter Description Contents
Contents
1 Change History.........................................................................................................................1
1.1 SRAN18.1 Draft A (2021-12-30)........................................................................................................................................ 1
2 About This Document.............................................................................................................3

2.1 General Statements................................................................................................................................................................ 3
2.2 Applicable RAT......................................................................................................................................................................... 3
2.3 Features in This Document.................................................................................................................................................. 4
3 IPv6 Transmission Basic Configuration...............................................................................6

3.1 IPv6 Transmission Interfaces............................................................................................................................................... 6
3.2 Transmission Configuration Model................................................................................................................................... 6
4 Transmission Protocol Stacks................................................................................................8

4.1 Overview.................................................................................................................................................................................... 8
4.2 Physical Layer........................................................................................................................................................................... 8
4.3 Data Link Layer........................................................................................................................................................................ 8
4.3.1 MAC.......................................................................................................................................................................................... 8
4.3.2 Interface.................................................................................................................................................................................. 9
4.3.3 VLAN........................................................................................................................................................................................ 9
4.4 Network Layer....................................................................................................................................................................... 10
4.4.1 Basic IPv6 Information..................................................................................................................................................... 11
4.4.1.1 IPv6 Packet Format........................................................................................................................................................11
4.4.1.2 IPv6 Address..................................................................................................................................................................... 15
4.4.1.2.1 Format of IPv6 Addresses........................................................................................................................................ 15
4.4.1.2.2 IPv6 Address Types..................................................................................................................................................... 15
4.4.1.3 IPv6 Static Routes.......................................................................................................................................................... 22
4.4.2 ICMPv6.................................................................................................................................................................................. 24
4.4.2.1 Types of ICMPv6 Error Packets.................................................................................................................................. 24
4.4.2.2 Types of ICMPv6 Information Packets.................................................................................................................... 25
4.4.3 Neighbor Discovery...........................................................................................................................................................25
4.4.3.1 Neighbor Discovery Packet Format......................................................................................................................... 25
4.4.3.2 Address Resolution........................................................................................................................................................ 29
4.4.3.3 Neighbor Unreachability Detection......................................................................................................................... 30
4.4.3.4 Duplicate Address Detection...................................................................................................................................... 32
4.4.3.5 ND Proxy and DAD Proxy............................................................................................................................................ 33
Issue Draft A Copyright © Huawei Technologies Co., Ltd. ii

(2021-12-30)
SingleRAN
4.4.3.6 Router Discovery............................................................................................................................................................ 33

4.4.3.7 Route Redirection........................................................................................................................................................... 34
4.4.4 IP Layer Fragmentation................................................................................................................................................... 34
4.4.4.1 Interface MTU................................................................................................................................................................. 34
4.4.4.2 Path MTU Discovery......................................................................................................................................................35
4.5 Transport Layer...................................................................................................................................................................... 37
4.6 IPv6 Transport Protocol Stacks for Interfaces............................................................................................................. 38
4.6.1 Protocol Stacks for LTE Transport Interfaces............................................................................................................38
4.6.2 Protocol Stacks for NSA NR Transport Interfaces...................................................................................................40
4.6.3 Protocol Stacks for SA NR Transport Interfaces...................................................................................................... 42
4.6.4 Protocol Stacks for Other Transport Interfaces....................................................................................................... 44
4.6.5 Restrictions.......................................................................................................................................................................... 46
5 IPv6 Transmission Networking for Interfaces.................................................................48

5.1 Overview.................................................................................................................................................................................. 48
5.2 LTE Interface Networking...................................................................................................................................................48
5.3 NSA NR Interface Networking......................................................................................................................................... 51
5.4 SA NR Interface Networking............................................................................................................................................. 54
6 IPv4/IPv6 Dual-Stack Networking for Interfaces...........................................................58

6.1 Overview.................................................................................................................................................................................. 58
6.2 Dual-Stack Transmission for Different Base Stations............................................................................................... 61
6.3 Intra-Base Station Dual-Stack Scenario 1: Dual-Stack Transmission for Different Interfaces................... 61
6.4 Intra-Base Station Dual-Stack Scenario 2: Dual-Stack Transmission for Different Peer Devices over the
X2/Xn Interface............................................................................................................................................................................. 64
6.5 Intra-Base Station Dual-Stack Scenario 3: Dual-Stack Transmission on the User Plane and Control
Plane of the S1/NG Interface................................................................................................................................................... 68
7 Transmission Reliability....................................................................................................... 71
7.1 Introduction............................................................................................................................................................................ 71
7.2 Control-Plane SCTP Multihoming................................................................................................................................... 71
7.3 User Plane Backup................................................................................................................................................................ 73
7.4 IP Route Backup.................................................................................................................................................................... 74
7.5 OM Channel Backup............................................................................................................................................................ 76
7.6 Ethernet Link Aggregation.................................................................................................................................................79
7.6.1 Basic Principles................................................................................................................................................................... 79
7.6.2 Application on the Base Station................................................................................................................................... 80
8 Transmission Maintenance and Detection...................................................................... 82

8.1 Overview.................................................................................................................................................................................. 82
8.2 ICMPv6 Ping............................................................................................................................................................................84
8.3 Trace Route............................................................................................................................................................................. 84
8.3.1 Route Reachability Detection........................................................................................................................................ 85
8.3.2 DSCP Change Detection.................................................................................................................................................. 85
8.4 GTP-U Echo............................................................................................................................................................................. 85
Issue Draft A Copyright © Huawei Technologies Co., Ltd. iii

(2021-12-30)
SingleRAN
8.5 LLDP.......................................................................................................................................................................................... 86
8.6 BFD............................................................................................................................................................................................ 87
8.6.1 Detection Mechanism...................................................................................................................................................... 87
8.6.2 Configuration Requirements..........................................................................................................................................88
8.6.3 Binding Relationship Between SBFD and IP Route................................................................................................ 89
9 Engineering Guidelines........................................................................................................ 91
10 Reference Documents........................................................................................................ 92
Issue Draft A Copyright © Huawei Technologies Co., Ltd. iv

(2021-12-30)
SingleRAN
IPv6 Transmission Feature Parameter Description 1 Change History
1 Change History
This chapter describes changes not included in the "Parameters", "Counters",

"Glossary", and "Reference Documents" chapters. These changes include:
● Technical changes
Changes in functions and their corresponding parameters
● Editorial changes
Improvements or revisions to the documentation
1.1 SRAN18.1 Draft A (2021-12-30)

This issue introduces the following changes to SRAN17.1 05 (2021-11-27).
Technical Changes
Change Description Parameter Change Base Station
Model
Deleted descriptions of None ● 3900 and 5900

ALM-25952 User Plane Path series base
Fault. For details, see: stations
● 8.1 Overview ● DBS3900
● 8.4 GTP-U Echo LampSite and
DBS5900
LampSite
Added support for TEID-based Added the ● 3900 and 5900

load sharing trunk by the main TRANSFUNCTIONSW. series base
control board. For details, see: ETHTRKLBMODE (LTE stations
● Basic Packet Header in eNodeB, 5G gNodeB) ● DBS3900
4.4.1.1 IPv6 Packet Format parameter. LampSite and
● 7.6.2 Application on the DBS5900
Base Station LampSite
Issue Draft A Copyright © Huawei Technologies Co., Ltd. 1

(2021-12-30)
SingleRAN
IPv6 Transmission Feature Parameter Description 1 Change History
Change Description Parameter Change Base Station

Model
Optimized the alarm reporting Modified the ● 3900 and 5900

mechanism about IP address ND.NDREACHABLETI series base
conflicts in DAD proxy detection ME (LTE eNodeB, 5G stations
in IPv6 backplane-based co- gNodeB) parameter. ● DBS3900
transmission scenarios. For The default value and LampSite and
details, see 4.4.3.3 Neighbor recommended value DBS5900
Unreachability Detection. have been changed LampSite
from 20 minutes to 30
seconds.
Added support for OM channel None ● 3900 and 5900

switchback. For details, see 7.5 series base
OM Channel Backup. stations
● DBS3900
LampSite and
DBS5900
LampSite
Editorial Changes
Added descriptions and precautions of ND proxy and duplicate address detection
(DAD) proxy in backplane-based co-transmission scenarios. For details, see 4.4.3.5
ND Proxy and DAD Proxy.
Added the PING6 command. For details, see 8.2 ICMPv6 Ping.
Revised descriptions in this document.

(2021-12-30)
SingleRAN
IPv6 Transmission Feature Parameter Description 2 About This Document
2 About This Document
2.1 General Statements

Purpose
Feature Parameter Description documents are intended to acquaint readers with:
● The technical principles of features and their related parameters

● The scenarios where these features are used, the benefits they provide, and
the impact they have on networks and functions
● Requirements of the operating environment that must be met before feature
activation
● Parameter configuration required for feature activation, verification of feature
activation, and monitoring of feature performance
NOTE
This document only provides guidance for feature activation. Feature deployment and
feature gains depend on the specifics of the network scenario where the feature is
deployed. To achieve optimal gains, contact Huawei professional service engineers.
Software Interfaces
Any parameters, alarms, counters, or managed objects (MOs) described in Feature
Parameter Description documents apply only to the corresponding software
release. For future software releases, refer to the corresponding updated product
documentation.
2.2 Applicable RAT

This document applies to LTE FDD, LTE TDD, NR, and NB-IoT.
For details about the definition of base stations in this document, see section
"Base Station Products" in SRAN Networking and Evolution Overview.

(2021-12-30)
SingleRAN
2.3 Features in This Document

This document describes the following features.
RAT Feature ID Feature Name Chapter/Section
NR FOFD-021212 IPv6 3 IPv6 Transmission

Basic Configuration
LTE TDD TDLBFD-003003 VLAN Support (IEEE 4.3.3 VLAN

802.1p/q)
LTE FDD LBFD-003003 VLAN Support (IEEE 4.3.3 VLAN

802.1p/q)
NB-IoT MLBFD-1200030 VLAN Support (IEEE 4.3.3 VLAN

3 802.1p/q)
NR FBFD-010019 VLAN Support 4.3.3 VLAN

(IEEE802.1p/q)
LTE FDD LOFD-003017 S1 and X2 over IPv6 4.6 IPv6 Transport

Protocol Stacks for
Interfaces
LTE TDD TDLOFD-003017 S1 and X2 over IPv6 4.6 IPv6 Transport

Protocol Stacks for
Interfaces
NB-IoT MLOFD-003017 S1 over IPv6 4.6 IPv6 Transport

Protocol Stacks for
Interfaces
LTE FDD LBFD-003006 IPv4/IPv6 Dual Stack 6 IPv4/IPv6 Dual-Stack

Networking for
Interfaces
LTE TDD TDLBFD-003006 IPv4/IPv6 Dual Stack 6 IPv4/IPv6 Dual-Stack

Networking for
Interfaces
NB-IoT MLBFD-1200030 IPv4/IPv6 Dual Stack 6 IPv4/IPv6 Dual-Stack

7 Networking for
Interfaces
NR FBFD-021101 IPv4/IPv6 Dual Stack 6 IPv4/IPv6 Dual-Stack

Networking for
Interfaces
LTE FDD LBFD-00202103 SCTP Multi-homing 7.2 Control-Plane SCTP

Multihoming
LTE TDD TDLBFD-0020210 SCTP Multi-homing 7.2 Control-Plane SCTP

3 Multihoming

(2021-12-30)
SingleRAN
RAT Feature ID Feature Name Chapter/Section
NB-IoT MLBFD-1200041 SCTP Multi-homing 7.2 Control-Plane SCTP

9 Multihoming

(2021-12-30)
SingleRAN
IPv6 Transmission Feature Parameter Description 3 IPv6 Transmission Basic Configuration
3 IPv6 Transmission Basic Configuration
3.1 IPv6 Transmission Interfaces

Interfaces that support IPv6 transmission include:
● S1, X2, and eX2 interfaces of LTE
● S1, X2, and eXn interfaces of non-standalone (NSA) NR
● NG, Xn, and eXn interfaces of standalone (SA) NR
● OM channel interface and clock synchronization interface of a base station
For the position of each interface on a network, see IPv4 Transmission.
3.2 Transmission Configuration Model

IPv6 transmission or IPv4/IPv6 dual-stack transmission supports only the new
transmission configuration model.
When GTRANSPARA.TRANSCFGMODE (5G gNodeB, LTE eNodeB) is set to NEW,
the new transmission configuration model is used. The transmission model is
independent from the device model. Only the INTERFACE MO needs to be
configured. The cabinet, subrack, or slot number does not need to be configured.
This facilitates the extension of new transmission functions and reduces
transmission configuration parameters.
NOTE
For details about how to configure transmission resource management and IPsec, see
Transmission Resource Management and IPsec.
The transmission configuration models of different RATs in a co-MPT multimode

base station must be the same. When the co-MPT multimode base station is
configured with IPv4/IPv6 dual-stack transmission, the old IPv4 transmission
model on the live network needs to be reconstructed. For example, if NR is
superimposed on LTE, then NR uses IPv6 transmission and LTE still uses IPv4
transmission. In this case, the old IPv4 transmission model of LTE needs to be
reconstructed into the new transmission model. The northbound tool must
support the new IPv4 and IPv6 transmission models. The old IPv4 transmission

(2021-12-30)
SingleRAN
IPv6 Transmission Feature Parameter Description 3 IPv6 Transmission Basic Configuration
model of the northbound tool must be reconstructed into the new IPv4
transmission model.
A separate-MPT multimode base station can be considered as multiple single-
mode base stations. The transmission configuration model of each RAT is
independent. The RAT that uses IPv4 transmission can use either the old or new
model.

(2021-12-30)
SingleRAN
IPv6 Transmission Feature Parameter Description 4 Transmission Protocol Stacks
4 Transmission Protocol Stacks
4.1 Overview
This chapter describes the basic protocols for IPv6 transmission at the physical,
data link, network, and transmission layers, as well as the protocol stacks of IP
transmission interfaces.
The physical layer protocols for IPv6 and IPv4 transmission are the same on the
base station side. The data link layer, network layer, and transmission layer
protocols for IPv6 transmission are different from those for IPv4 transmission. This
chapter describes the differences between IPv6 and IPv4 transmission protocols.
For details about other information, see IPv4 Transmission.
4.2 Physical Layer

The physical layer is the bottom layer of the general transmission protocol stack
and is identical between IPv4 and IPv6 transmission. The main physical layer port
involved in base station IPv6 transmission is the Ethernet port.
4.3 Data Link Layer

The data link layer is the second layer of the Transmission Control Protocol/
Internet Protocol (TCP/IP) protocol stack. It receives and processes data from the
physical layer and provides reliable data transmission for the network layer. Base
station IPv6 transmission supports only Ethernet ports.
4.3.1 MAC
IPv6 and IPv4 use the same MAC address and frame format. Ethernet has multiple
MAC frame formats. The Ethernet II frame format is defined in RFC 894, as shown
in Figure 4-1. The upper-layer protocol type value 0x86DD in the Ethernet frame
indicates the IPv6 protocol.

(2021-12-30)
SingleRAN
Figure 4-1 Ethernet II frame format
4.3.2 Interface
An interface can be configured for a physical port (for example, an Ethernet port
or an Ethernet trunk group) or for a logical port (loopback interface) on a base
station. Interfaces are classified into common interfaces and VLAN sub-interfaces
based on whether VLAN tags are contained in packets. The INTERFACE.ITFTYPE
(5G gNodeB, LTE eNodeB) parameter specifies the interface type.
● Common interfaces can be configured for a physical port or a logical interface
on a base station. Packets sent from a common interface do not contain
VLAN tags. If the link type of the port on the peer transmission device
connected to the base station is set to Access or Hybrid, packets sent from
the peer transmission device to the base station do not contain VLAN tags.
NOTE
IPv6 does not support VLAN configuration using the VLANMAP and VLANCLASS
MOs.
● VLAN sub-interfaces must be configured for a physical port. Packets sent from
or received by a VLAN sub-interface contain VLAN tags. Each VLAN sub-
interface is planned as a VLAN and corresponds to only one VLAN ID. The
base station attaches VLAN tags to traffic flows before sending the traffic
flows to a VLAN interface.
Interfaces are configured in the INTERFACE MO on the base station and
shared by IPv4 and IPv6 transmission. IPv4 transmission is supported by
default. To enable IPv6 transmission, set the INTERFACE.IPV6SW (5G
gNodeB, LTE eNodeB) parameter to ENABLE. IPv6 transmission must be first
enabled for an interface and then IPv6 addresses or IPv4/IPv6 dual-stack
addresses can be added to the INTERFACE MO.
4.3.3 VLAN
IPv6 transmission has the same VLAN format and functions as IPv4 transmission.
However, VLAN configuration modes supported on the base station side are
different between IPv6 and IPv4 transmission. Table 4-1 lists the VLAN
configuration requirements for base stations using IPv4, IPv6, or IPv4/IPv6 dual-
stack transmission.

(2021-12-30)
SingleRAN
Table 4-1 VLAN configuration requirements for different transmission types

Transmission Transmission VLAN Requirement
Type Configuration
Model
IPv6 New model The VLAN works in interface VLAN

transmission mode.
IPv4 New model The VLAN works in single VLAN mode,

transmission group VLAN mode, or interface VLAN
mode.
Old model The VLAN works in single VLAN mode

or group VLAN mode.
IPv4/IPv6 New model VLANs for both IPv4 and IPv6

dual-stack transmission work in interface VLAN
transmission mode. IPv6 and IPv4 transmission can
use the same or different VLAN IDs.
In IPv6 or IPv4/IPv6 dual-stack transmission, VLANs can be configured only in

interface mode. A VLAN includes VLAN ID and VLAN priority.
● A VLAN ID is specified by the INTERFACE.VLANID (5G gNodeB, LTE eNodeB)
parameter.
● The DSCP value and VLAN priority are specified by the DSCP2PCPREF.DSCP
and DSCP2PCPREF.PCP parameters, respectively. The
INTERFACE.DSCP2PCPMAPID parameter specifies a mapping relationship
between DSCP values and VLAN priorities in the DSCP-PCP mapping list
(DSCP2PCPMAP MO).
4.4 Network Layer

The network layer uses IP as the principal protocol and is also referred to as the IP
layer. IPv6 is the second-generation standard network layer protocol and has the
following improvements based on the first generation:
● More IP addresses
IPv6 increases the IP address size from 32 bits to 128 bits, and therefore
provides many more IP addresses.
● Auto-configuration mechanism
IPv6 supports auto-configuration of addresses. That is, a host automatically
detects network provisioning and obtains the IPv6 address assigned to the
host.
● Enhanced transmission security
IPv6 standard extension headers are used for IPsec. IPv6 nodes support IPsec,
which provides end-to-end security.
During the IPv4-to-IPv6 transition, the two protocols will coexist. Base stations
support IPv4/IPv6 dual-stack transmission to ensure a smooth evolution from IPv4
to IPv6.

(2021-12-30)
SingleRAN
During IPv4/IPv6 dual-stack transmission, a dual-stack node communicates with

an IPv4 node using the IPv4 protocol, whereas it communicates with an IPv6 node
using the IPv6 protocol.
4.4.1 Basic IPv6 Information
4.4.1.1 IPv6 Packet Format

An IPv6 packet consists of three parts: basic packet header, extension packet
header, and upper-layer protocol data unit.
Basic Packet Header

A basic IPv6 packet header occupies 40 bytes, including basic information about
packet forwarding. This header is mandatory for IPv6 packets. Figure 4-2 shows
the format of a basic IPv6 packet header.
Figure 4-2 Format of the basic IPv6 packet header
The fields in an IPv6 packet header are described as follows:

● Version: This field indicates the IP protocol version and occupies four bits. The
value is 6 for IPv6 transmission.
● Traffic Class: This field occupies eight bits and identifies the class or priority of
IPv6 packets. This field is similar to the Type of Service (TOS) field for IPv4
transmission.
● Flow Label: This field occupies 20 bits and indicates the specific packet
sequence which a packet belongs to between the source and the destination
nodes. This field needs to be processed by the intermediate IPv6 router.
Generally, a flow can be determined by the IPv6 address and flow label of the
source node or destination node.
For GTP-U packets, the Flow Label field is filled with the last 20 bits of the
tunnel endpoint identifier (TEID).
For UDP packets on the user plane, the Flow Label field is filled with the last
20 bits of the hash value of the source port number and destination port
number.

(2021-12-30)
SingleRAN
For other IP packets, the Flow Label field is filled with 0.

● Payload Length: This field occupies 16 bits and specifies the length of the
valid payload of an IPv6 packet. A valid payload is the part that follows the
basic IPv6 packet header in a packet. A valid payload includes the extension
packet header and upper-layer protocol data unit.
● Next Header: This field occupies eight bits and specifies the type of the
extension header that follows the IPv6 packet header or the type of the
transmission layer protocol. If a packet has an extension header, this field
identifies the header following the IPv6 header. If the packet has no extension
header, this field specifies the transport layer protocol type. For example, the
value 17 indicates UDP and the value 6 indicates TCP.
● Hop Limit: This field occupies eight bits and specifies the maximum number
of hops allowed by IPv6 packets. The value of this field decreases by 1 each
time the packet is forwarded by a router. A router will discard a packet if it
finds out that the value of this field in the packet is 0.
● Source Address: This field occupies 128 bits and specifies the source IP address
of packets.
● Destination Address: This field occupies 128 bits and specifies the destination
IP address of packets.
Extension Packet Header

IPv6 reduces the payload of the header by moving the optional fields to the
extension packet header. This improves the packet handling efficiency of the
network device. The extension packet header is optional and is used for specific
functions. After receiving an IPv6 packet whose destination IP address is the IP
address of the local base station, the base station checks the IPv6 extension
header. A packet sent by the peer device (router, core network, base station, clock
server, or security gateway) must contain only the following extension headers.
Otherwise, the packet is discarded by the base station. When forwarding IPv6
packets whose destination IP address is not the IP address of the local base
station, the base station can only forward the packets based on routes and does
not check or process IPv6 extension headers.
● Hop-by-hop options header
This header is used for multicast snooping discovery protocol packets. Base
stations can contain this header only in the multicast listener discovery (MLD)
protocol packets.
This header specifies the sending parameters for each hop on the
transmission path. Each intermediate node on the transmission path needs to
read and process this header. The value of the Next Header field is 0. Figure
4-3 shows the format of the hop-by-hop options header.
Figure 4-3 Format of the hop-by-hop options header

(2021-12-30)
SingleRAN
● Fragment header
A packet needs to be fragmented if it exceeds the maximum transmission unit
(MTU). A fragment header is used for packet fragmentation. IPv6
intermediate nodes do not allow for IPv6 packet fragmentation. IPv6 packets
must be fragmented by the source node. The value of the Next Header field
of the fragment header is 44. Figure 4-4 shows the format of the fragment
header.
Figure 4-4 Format of the fragment header.
The fields in this header are described as follows:

– Next Header: This field occupies eight bits and specifies the value of the
next packet header. This value is the type value of the next extension
header or transmission layer protocol.
– Reserved: The field occupies eight bits. The initial value is 0. This field is
ignored during reception.
– Fragment Offset: This field occupies 13 bits and specifies the offset of the
current packet content in the original packet.
– Res: This field occupies two bits. The initial value is 0. This field is ignored
during reception.
– M: This field occupies one bit. The value 1 indicates that there are
subsequent fragments. The value 0 indicates that the current packet is
the last fragment.
– Identification: This field occupies 32 bits. The source node allocates an ID
to each packet fragment. This ID identifies the packet to which a
fragment belongs. The destination node assembles packet fragments
based on this ID. The ID of a packet fragment must be unique. The value
of the Identification field is incremented by one for one more packet
fragment. A 32-bit value ensures that each packet fragment can have a
unique ID.
A fragment with the Fragment Offset and the M flag both set to 0 is referred
to as an atomic fragment. The base station does not support the processing
of packets containing atomic fragments and will discard such packets.
● Authentication header: This header is used to ensure IP security and provides
authentication services. The value of the Next Header field is 51. This header
is the same in IPv4 and IPv6. Figure 4-5 shows the header format.

(2021-12-30)
SingleRAN
Figure 4-5 Format of the authentication header
The fields in this header are described as follows:

– Next Header: This field occupies eight bits and specifies the value of the
next packet header. This value is the type value of the next extension
header or transmission layer protocol.
– Payload Len: This field occupies eight bits and specifies the length of the
authentication extension header.
– RESERVED: This field occupies 16 bits. The initial value is 0. This field is
ignored during reception.
– Security Parameters Index: This 32-bit field can be set to any value. This
field, the destination IP address, and security protocol AH uniquely
identify the security status of packets. The value 0 is reserved locally. The
value 1 to 255 is reserved for Internet Assigned Numbers Authority
(IANA).
– Sequence Number: This field occupies 32 bits. The value of this field is
incremented by one each time an AH packet is sent. The initial value is 0.
– Integrity Check Value-ICV: It is variable in length and is used to check the
integrity of a packet. The value must be an integral multiple of 32 bits. If
the length is insufficient, padding is required.
● Encapsulating security payload (ESP)
An ESP ensures IP security. The value of the Next Header field is 50. Similar to
the authentication header, an ESP is the same for both IPv4 and IPv6
transmission. An ESP is also referred to as an IPsec ESP. For descriptions of the
fields in an ESP, see the descriptions of fields in the authentication header.

(2021-12-30)
SingleRAN
Figure 4-6 Format of the ESP
Upper-Layer Protocol Data Unit

An upper-layer protocol data unit includes the upper-layer protocol packet header
and its valid payload, such as the TCP and UDP. This part is the same as that in an
IPv4 packet.
4.4.1.2 IPv6 Address
4.4.1.2.1 Format of IPv6 Addresses

An IPv6 address is a 128-bit value in the format of X:X:X:X:X:X:X:X.
● A 128-bit IPv6 address is divided into eight groups. The 16 bits in each group
are represented by four hexadecimal characters (0 to 9 and A to F). The
groups are separated by colons (:). Each X represents a group of hexadecimal
numbers. For example, 2001:db8:130f:0000:0000:09c0:876a:130b is an IPv6
address. For the convenience of writing, the leading zeros in each group can
be omitted. This address can be written as 2001:db8:130f:0:0:9c0:876a:130b.
Two or more consecutive groups in which all values are 0 in an IPv6 address
can be replaced with double colons (::). In this way, the length of an IPv6
address can be reduced. The preceding address can be written as
2001:db8:130f::9c0:876a:130b.
● In an IPv6 address, only one double colon (::) can be used. Otherwise, the
number of 0 in each segment cannot be determined when the compressed
address is restored to a 128-bit value.
4.4.1.2.2 IPv6 Address Types

There are three types of IPv6 addresses: unicast addresses, multicast addresses,
and anycast addresses. Unlike IPv4 transmission, IPv6 transmission does not
support broadcast addresses. IPv6 transmission uses multicast addresses to replace
broadcast addresses used for IPv4 transmission. IPv6 transmission also uses
anycast addresses.
● A unicast address identifies a network interface of a transmission node. If the
destination address of an IPv6 packet is a unicast address, this packet is sent
to the port identified by this unicast address.

(2021-12-30)
SingleRAN
● A multicast address identifies a group of interfaces that belong to different

nodes. An IPv6 multicast address is similar to an IPv4 broadcast address.
Packets sent to a multicast address are sent to all interfaces identified by this
multicast address. Unlike IPv4 transmission, IPv6 transmission does not
support broadcast addresses. IPv6 transmission uses multicast addresses to
replace broadcast addresses used for IPv4 transmission.
● An anycast address identifies a group of interfaces that generally belong to
different nodes. Packets sent to an anycast address are transmitted to an
interface closest to the source node in a group of interfaces identified by this
address. The distance is determined based on the routing protocol.
NOTE
Base stations support only unicast and multicast addresses, and do not support anycast
addresses.
Table 4-2 lists the IPv6 address types supported by a base station.
Table 4-2 IPv6 address types and configurations supported by a base station
Category Sub-category Description Parameter Settings
on the Base Station
Unicast Globally The global unicast address Parameters in the

addresses scoped and unique local unicast ADD IPADDR6
unicast address are included. This command
address address is a service IP
address or interface IP
address. It is configured
for an Ethernet port, an
Ethernet trunk, or a
loopback interface.
Link-local This address is used in The parameters are

address many IPv6 protocols, such automatically
as the neighbor discovery configured by the
protocol, DHCPv6 base station. Manual
protocol, and multicast configuration is not
snooping discovery supported.
protocol.
This is an IP address for Parameters in the SET

local maintenance. LOCALIP6 command
Multicast All-node This address is used in the The base station

address multicast neighbor discovery automatically adds
address protocol. all-node multicast
addresses.

(2021-12-30)
SingleRAN
Category Sub-category Description Parameter Settings

on the Base Station
Solicited-node This address is used in the After the base station

multicast neighbor discovery configures Ethernet
address protocol. ports or automatically
generates a unicast
address, it
automatically
generates a solicited-
node multicast
address.
Unicast Address
A unicast address consists of a subnet prefix and an interface ID, as shown in
Figure 4-7. As in IPv4, a subnet prefix in IPv6 is associated with one link. An
interface ID identifies a link interface. A unicast address must be unique in a
subnet.
Figure 4-7 Unicast address format
● Network prefix: This field occupies N bits. It is equivalent to the network ID in

an IPv4 address.
● Interface ID: This field occupies 128–N bits. It is equivalent to the host ID in
an IPv4 address.
A unicast address can be converted from a MAC address at the link layer or be
manually planned. An IPv6 address in the IEEE EUI-64 format is converted from a
MAC address at the link layer. The interface ID occupies 64 bits. To convert a 48-
bit MAC address into a 64-bit interface ID, insert the hexadecimal number FFFE
(1111 1111 1111 1110) into the MAC address. Then, set the U/L bit (the seventh
bit starting from the most significant bit) to 1 to obtain the interface ID in EUI-64
format. The calculation is illustrated in Figure 4-8.

(2021-12-30)
SingleRAN
Figure 4-8 Converting a MAC address to an interface ID in EUI-64 format
IPv6 defines several types of unicast addresses. Base stations support the following
types of unicast addresses:
● Global unicast address

A global unicast address refers to an IP address that can be used globally. Like
an IPv4 public address, the subnet prefix of a global unicast address must be
unique. Figure 4-9 shows the global unicast address format. On the base
station side, global unicast address can only function as service IP addresses
for communication with the S-GW, MME, EMS, and IP clock server. IPv6
addresses are manually configured in the IPADDR6 MO. The subnet prefix
length in an IPv6 address is specified by the IPADDR6.PFXLEN (5G gNodeB,
LTE eNodeB) parameter. An IPv6 address is specified by the IPADDR6.IPV6
(5G gNodeB, LTE eNodeB) parameter.
Figure 4-9 Global unicast address format
Global unicast addresses are organized into a three-level hierarchy:

– Global route prefix: This is a prefix provided by the provider for an
organization (end site). The first three digits of the global route prefix
allocated by the IANA are 001.
– Subnet ID: This ID is used for subnet division.
– Interface ID: This ID uniquely identifies an interface.
● Unique local unicast address

(2021-12-30)
SingleRAN
A unique local unicast address is a type of IPv6 address. It contains a global

ID in the address structure. In the RFC standard, the unique local unicast
address and the global unicast address are collectively called globally scoped
unicast address. A unique local unicast address cannot be routed globally and
can only be used for communication between sites on the local network. It is
equivalent to a private IPv4 address. Routers on the local network must
support IPv6 packets with the source address or the destination address being
the unique local unicast address. The peer equipment must also support the
unique local unicast address. The unique local unicast address on the base
station is configured in the IPADDR6 MO, which is the same as the global
unicast address.
Figure 4-10 Unique local unicast address format
The fields shown in Figure 4-10 are as follows:

– Link-local address prefix: fc00:: /7
– L: 1 indicates local assignment; 0 indicates reservation for future
definition.
– Global ID: This ID is a unique prefix for creating a global ID. The RFC
4193 standard provides a method of creating a global ID.
– Subnet ID: This ID is used to divide the subnets of local sites.
– Interface ID: This ID uniquely identifies an interface.
● Link-local address
The prefix of a link-local address is fe80:: /10. A link-local address is used for
communication between local link nodes compliant with the neighbor
discovery protocol, DHCPv6, and multicast snooping discovery protocol. IPv6
packets whose destination address is a link-local address are not forwarded by
the router. Each interface on the network node must have a link-local address.
Figure 4-11 shows the link-local address format.
Figure 4-11 Link-local address format
Link-local addresses can be automatically generated over Ethernet or Ethernet

aggregation group interfaces for base stations. The interface ID of the link-
local address of a physical interface is converted from the MAC address into a
value in IEEE EUI-64 format and cannot be manually configured in the
IPADDR6 MO. A link-local address generated based on a MAC address is

(2021-12-30)
SingleRAN
globally unique. A link-local address can be set as the IPv6 address of the
local maintenance channel using the LOCALIP6.IP6 (5G gNodeB, LTE
eNodeB) parameter locally.
● Unassigned address
An unassigned address is also called an all-zero address, which is
0:0:0:0:0:0:0:0/128. This address is not assigned to any interface and cannot be
used as the destination address of packets. After a node is started, when no IP
address is assigned to any interface, an unassigned address can function as
the source address of packets. For example, an unassigned address can
function as the source address of Neighbor Solicitation (NS) packets during
address conflict detection.
● Loopback address
A loopback address is 0:0:0:0:0:0:0:1/128. It is used within a node and is not
allocated to any interface. A loopback address is equivalent to the loopback
address 127.0.0.1 in IPv4 transmission. If the destination address of an IPv6
packet is a loopback address, this packet is sent to the sender itself.
● IPv4-mapped IPv6 address
The address format is 0:0:0:0:0:ffff:X.X.X.X. X.X.X.X is a 32-bit IPv4-address,
which allows applications that support only IPv6 transmission to run on dual-
stack nodes.
NOTE
● In IPv6 networking, base stations support only global unicast addresses and unique local
unicast addresses.
● In this version, IPv4 addresses cannot be mapped to IPv6 addresses.
● The prefix length of the IP address of the Ethernet port can be set to 127 bits. During
the planning of the transport network, the network segments other than the directly
connected 127-bit network segment cannot be all 0s or all 1s.
Multicast Address
A multicast address identifies a set of network ports, which typically belong to
different nodes. If the destination address of an IPv6 packet is a multicast address,
the packet is sent to all the ports identified by this address. Multicast addresses in
IPv6 transmission serve the role of broadcast addresses in IPv4 transmission.
Multicast addresses are used for one-to-many communications. eNodeBs/gNodeBs
do not support multicast addresses, but they can receive and parse packets with a
multicast address as the destination address.
Figure 4-12 shows the multicast address format.
Figure 4-12 Multicast address format
In a multicast address:
● The most significant eight bits are always 1.

(2021-12-30)
SingleRAN
● Flag: This field occupies four bits and specifies whether a multicast address is
permanent. The value 0000 indicates permanent. The value 0001 indicates
temporary.
● Range: This field occupies four bits and specifies the range of multicast
addresses.
– The value 1 indicates the local interface range.
– The value 2 indicates the local link range.
– The value 5 indicates the local site range.
– The value 8 indicates the local organization range.
– The value E indicates the global range.
● Group ID: This field specifies a multicast group.
Ff00::/16 to ff0f::/16 are reserved multicast addresses and cannot be allocated by
multicast groups. They serve the role of the broadcast function of IPv4
transmission.
● An all-node multicast address (ff02::1) is the destination address of router
advertisement (RA) packets compliant with the neighbor discovery protocol.
All nodes join this multicast group to receive packets whose destination
address is this multicast address.
The trigger conditions for generating multicast addresses of all nodes for an
interface are as follows:
– An INTERFACE MO is added. The INTERFACE.IPV6SW (5G gNodeB, LTE
eNodeB) parameter is set to ENABLE.
– An INTERFACE MO exists. The INTERFACE.IPV6SW (5G gNodeB, LTE
eNodeB) parameter is set to ENABLE.
The trigger conditions for deletion are as follows:
– The INTERFACE MO with INTERFACE.IPV6SW (5G gNodeB, LTE
eNodeB) set to ENABLE is deleted.
– The INTERFACE.IPV6SW (5G gNodeB, LTE eNodeB) parameter is set to
DISABLE.
● An all-router multicast address (ff02::2) is the destination address of Router
Solicitation (RS) packets compliant with the neighbor discovery protocol. All
routers use this multicast address to receive packets whose destination
address is this multicast address.
● A solicited-node multicast address is Ff02::1:ffXX:XXXX. X indicates the least
significant 24 bits of the generated unicast address or anycast address. For
example, if the unicast address is 2001:db8::800:200e:8c6c, the automatically
generated solicited-node multicast address is ff02::1:ff0e:8c6c. After a unicast
or multicast address is configured or automatically generated for an interface
of the node, a solicited-node multicast address is automatically generated.
Multiple unicast addresses on a base station can be mapped to a solicited-
node multicast address. If a unicast address is configured for an interface, a
solicited-node multicast address is automatically generated if there is no
corresponding solicited-node multicast address. If the unicast address is
deleted, the solicited-node multicast address will be deleted only after the last
unicast address is deleted. This address functions as the destination address
for address resolution or address conflict detection packets compliant with the
neighbor discovery protocol.

(2021-12-30)
SingleRAN
Anycast Address
An anycast address identifies a set of ports, which belong to different nodes. If a
network port of a node is configured with an anycast address, the node becomes a
member of the anycast set. The information about anycast members must be sent
to relevant routers on the network. Irrelevant routers do not need to learn this
information.
NOTE
Base stations do not support anycast addresses.
If the destination address of a packet is an anycast address, the packet is routed to

the "nearest" anycast set member rather than to all the members. This is the most
significant difference between the anycast service and multicast service.
The anycast address format is the same as the unicast address format, as shown in
Figure 4-9. RFC 4291 defines a subnet router anycast address with an interface ID
of 0.
4.4.1.3 IPv6 Static Routes

The principle for forwarding IPv6 static routes is the same as that for forwarding
IPv4 static routes. Base stations support static destination-based routing and
source-based routing in IPv6 transmission.
● The packet sending principle of static destination-based routing in IPv6
transmission is the same as that in IPv4 transmission. Base stations search for
the egress port and gateway IP address based on the destination IP address of
a packet. The following routes are supported:
– Active/standby route: Static routes with the same IPv6 destination
address and prefix length but different priorities function as the active
and standby routes. Packets are forwarded using the route with the
highest priority.
– Direct route: This is a type of destination route. A base station
automatically generates the direct route whose destination address is
located in the network segment of the interface IP address. A direct route
does not require manual maintenance and has the highest priority.
– Host route: This is a manually configured route with a 128-bit prefix.
– Network segment route: The manually configured prefix length is not 128
bits.
– Default route: The destination route of a default route is an all-zero
value.
NOTE
Base station IPv6 transmission does not support equal-cost routes with the same
priority.
Base station IPv6 static destination-based routes are configured in the new
transmission model. IPv6 static route entries are configured in the IPROUTE6
MO. The DSP IPROUTE6 command output displays routes taking effect on a base
station.
● Static source-based IP routing: With this mechanism, IP addresses of egress
ports and gateways for IPv6 packets are determined based on the source IP

(2021-12-30)
SingleRAN
addresses. The base station supports source-based routing and source-based

route backup. If the source IP addresses of two routes are the same but the
next-hop IP addresses of the two routes are different, the two routes work in
active/standby mode when they have different priorities. Packets are
forwarded using the route with the highest priority. Base station IPv6 source-
based routing does not support equal-cost routes with the same priority. Base
station IPv6 static source-based routes can be configured only in the new
transmission model. IPv6 static source-based route entries are configured in
the SRCIPROUTE6 MO. The DSP SRCIPROUTE6 command output displays
source-based routes taking effect on a base station.
Figure 4-13 shows the recommended scenario for source-based routing
supported by the base station. Routes to be configured on a base station have
the same service IP address but different next-hop IP addresses and different
destination IP addresses. In this case, source-based routing is recommended
for simplifying route configurations on the base station side.
Figure 4-13 Recommended scenario for source-based routing on the base

station
For example:
– In the MME pool scenario, the S1 interface of the base station is
connected to multiple peer IP addresses.
– In the core network capacity expansion and migration scenarios, the peer
IP address of the S1 interface on the base station changes dynamically.
– In the X2/Xn interface networking and base station L3 networking,
multiple peer IP addresses are interconnected to multiple base stations. It
is recommended that the X2/Xn interface should use one IP address and
the X2/Xn and S1 interfaces should use the same next hop in L3
networking.
If there are multiple service IP addresses on the base station side, the next-
hop IP addresses are different, and there is only one destination IP address on
the peer end, source-based routing is not recommended for the base station.

(2021-12-30)
SingleRAN
If there is only one service IP address on the base station side, the next-hop IP
addresses are different, and there are multiple destination IP addresses on the
peer end, source-based routing is not supported for the base station.
4.4.2 ICMPv6
Internet Control Message Protocol for the Internet Protocol Version 6 (ICMPv6) is
one of the basic IPv6 protocols. ICMPv6 packets include error packets and
information packets. IPv6 neighboring nodes use these packets to report errors
and information during packet processing. For details, see RFC 4443. Figure 4-14
shows the format of an ICMPv6 packet.
Figure 4-14 ICMPv6 packet format
The fields in the packet are described as follows:
● Type: This field specifies the packet type. The values from 0 to 127 indicate
error packets. The values from 128 to 255 indicate information packets.
● Code: This field specifies the subtype of packets.
● Checksum: This field specifies the checksum of ICMPv6 packets.
4.4.2.1 Types of ICMPv6 Error Packets

ICMPv6 error packets are classified into the following types:
● Destination Unreachable Message

If an IPv6 node finds that no route is available to the destination or that the
destination address or port is unreachable when forwarding an IPv6 packet, it
sends an ICMPv6 Destination Unreachable Message to the source node.
● Packet Too Big Message
If an IPv6 node finds that the packet size exceeds the link MTU of the egress
port, it sends an ICMPv6 Packet Too Big Message to the source node. The
error packet contains the link MTU of the egress port.
● Time Exceeded Message
During IPv6 packet sending and receiving, when the Hop Limit value decrease
to 0, the device sends an ICMPv6 Time Exceeded Message to the source node
sending the IPv6 packet. If packet fragmentation or assembling times out, an
ICMPv6 Time Exceeded Message is generated.
● Parameter Problem Message
A destination node checks the validity of a received IPv6 packet. If a field in
the IPv6 basic header or extension header is incorrect, the NextHeader value
is unknown, or the extension header has unknown options, an ICMPv6
Parameter Problem Message is sent to the source node.

(2021-12-30)
SingleRAN
4.4.2.2 Types of ICMPv6 Information Packets

ICMPv6 information packets are classified into request information (Echo Request)
and response information (Echo Reply). ICMPv6 packets are used for network fault
diagnosis, PMTU discovery, and neighbor discovery. During the connectivity test
between two nodes, the node that receives the Echo Request packet returns an
Echo Reply packet to the source node. In this way, packets are transmitted and
received between the two nodes.
4.4.3 Neighbor Discovery

Neighbor discovery is a group of messages and processes that determine the
relationship between neighboring nodes. Neighbor discovery implements the
functions in 4.4.3.2 Address Resolution, 4.4.3.4 Duplicate Address Detection,
4.4.3.6 Router Discovery, and 4.4.3.7 Route Redirection using ICMPv6
information packets.
4.4.3.1 Neighbor Discovery Packet Format

Neighbor discovery defines five types of ICMPv6 messages. Table 4-3 lists the
types and functions of these messages.
Table 4-3 Types and functions of ICMPv6 messages

Message Type Function
Neighbor solicitation (NS) ● Obtains the data-link-layer address of a

neighbor.
● Detects address conflicts.
● Checks whether the neighbor is reachable.
Neighbor advertisement ● Responds to an NS message.

(NA) ● If the data-link-layer address of a node
changes, the node sends an unsolicited NA
message to inform the neighbor of the
change.
Router solicitation (RS) Requests the prefix and other configuration

information for automatic configuration of the
host node after the host node is started.
Router advertisement (RA) ● Responds to an RS message.

● If RA messages are not suppressed, the router
periodically sends RA messages, which
include prefix information option and flag
bits.
NOTE
Whether a router sends information contained in
RA messages needs to be configured on the router.
Routers must be deployed on the network.

(2021-12-30)
SingleRAN
Message Type Function
Redirection packet If certain conditions are met, the default router

sends a redirection packet to the source host so
that the host selects the correct next hop
address to send subsequent packets.
NOTE
Routers must be deployed on the network.
The base station does not support the redirection
function and discards received redirection messages.
● Neighbor solicitation (NS)

An IPv6 node obtains the data-link-layer address of the neighbor from an NS
packet, checks whether the neighbor is reachable, and performs duplicate
address detection. Figure 4-15 shows the NS packet format.
Figure 4-15 NS packet format
– Type: The value is 135.

– Code: The value is 0.
– Checksum: This is the checksum field.
– Reserved: The sender must initialize the field value to 0. The receiver
must ignore this field.
– Target Address: This field specifies the IP address of the solicited
destination. It cannot be a multicast address. It can be a local-link, local-
site, or global address.
– Options: This field specifies the data-link-layer address of the packet
sender. Only address options at the source data link layer can be used in
NS packets. If the source address of an IPv6 header is an unassigned
address, this field cannot be contained.
● NA: An NA packet is a response of an IPv6 node to an NS packet. An IPv6
node can proactively send an NA packet when the data link layer changes to
notify the adjacent node that its data-link-layer address or role changes.
Figure 4-16 shows the NA packet format.
Figure 4-16 NA packet format

(2021-12-30)
SingleRAN

– R: This field is the router flag and indicates the role of the NA packet
sender. The value 1 indicates that the sender is a router. The value 0
indicates that the sender is a host. The router flag is used for NUD to
determine when a router becomes a host.
– S: This field is the solicited flag, which is a response to the NA packet sent
by the unicast NS. In NUD, S is a neighbor reachability acknowledgment
flag. During the multicast advertisement or non-solicited unicast
advertisement, S must be set to 0. For example, during DAD detection,
NS packets use the multicast address of the solicited node. When the
addresses conflict with each other, S in the returned NA packet must be
set to 0.
– O: This field is the override flag. The value 1 indicates that a data-link-
layer address among available destination data-link-layer addresses is
used to update the neighbor cache table. The value 0 indicates that a
target data-link-layer address can be used to update the neighbor cache
table only when the data-link-layer address is unknown. In a solicited NA
packet, if the destination address of the corresponding NS packet is an
anycast address or the solicited agent advertisement, the override flag
should not be set to 1. In other cases, such as DAD, this flag should be set
to 1.
– Target Address: This field is the destination address. If the NA message is
sent in response to an NS message, the field value is the destination
address of the NS message. If the NA message is not sent in response to
an NS message, the field value is the IP address of the network node
whose data-link-layer address has changed. The destination address
cannot be a multicast address.
– Options: This field can only be set to a destination data-link-layer
address, which is a data-link-layer address of the advertisement sender.
● Router solicitation (RS)
After being started, the host sends an RS packet to the router, and the router
responds with an RA packet. Figure 4-17 shows the RS packet format.
Figure 4-17 RS packet format


(2021-12-30)
SingleRAN
– Options: This field specifies the data-link-layer address of the packet
sender. Only address options at the source data link layer can be used in
RS packets. If the source address of an IPv6 header is an unassigned
address, this field cannot be contained.
● Router advertisement (RA)
A router sends RA packets, which include the prefix and flag bits, to respond
to the RS packets sent by the host or RA packets periodically sent by the host.
Figure 4-18 shows the RA packet format.
Figure 4-18 RA packet format

– Cur Hop Limit: This field specifies the maximum number of hops for
packet sending of a router.
– M: This is the managed address configuration field. The value 0 indicates
stateless address allocation. The host obtains the prefix in the prefix
information option and automatically generates IPv6 addresses. The
value 1 indicates stateful address allocation. The client obtains IPv6
addresses using the DHCPv6 protocol.
– Rsv: This is a reserved field. The sender must initialize the field value to 0.
The receiver must ignore this field.
– Router Lifetime: This field specifies the life cycle of the router that sends
RA packets as the default router (unit: s).
– Reachable Time: This field specifies the reachable time (unit: ms). A
router sends RA packets over an interface to enable all nodes on the
same link to use the same reachable time.
– Retrans Timer: This field specifies the retransmission timer (unit: ms). This
timer indicates the interval for retransmitting NS packets. It is used for
unreachable neighbor detection and address resolution.
– Options: This is the option field.

(2021-12-30)
SingleRAN
NOTE
A node sends RA packets only if the node works in router mode and supports
router forwarding. A node does not send RA packets as a host or a Layer 2
switch.
● Redirection packet
IPv6 routers send redirection packets to redirect packets to a more suitable
router. Redirection packets inform the host to select a more suitable next hop
address. Figure 4-19 shows the redirection packet format.
Figure 4-19 Redirection packet format

– Target Address: This field specifies the target address, which is the next
hop address of the destination address. If the destination is a router
(packets outside the local link), the local link address of the router must
be used. For a host (local-link packets), the target address and
destination address must be the same.
– Destination Address: This field specifies the destination address, which is
the destination address of the IPv6 packet header.
– Options: This is the option field.
4.4.3.2 Address Resolution

The address resolution function is similar to the Address Resolution Protocol (ARP)
function of IPv4 transmission. The principles are as follows:
● When sending a service packet, a network node queries the neighbor cache
table to obtain the link-layer address. If the link-layer address is not found,
the network node sends an NS packet with the source IP address set to the
link-local address of the NE and the destination IP address set to the
multicast address of the solicited node. Multicast addresses can reduce the
risk of network storms.
● When the solicited-node multicast address of the neighbor node on the link is
the same as the destination IP address in the IP header of the NS packet and
the destination address in the ICMP header is the same as the IP address of
the local node, the NA packet is sent as a response. The neighbor discovery
protocol on the node establishes a neighbor discovery entry according to

(2021-12-30)
SingleRAN
information such as the link-layer address and IP address in the NS packet or

the NA packet.
● When the link-layer address of a node changes, a non-solicited NA packet is
sent to inform the neighbor on the link to update the neighbor cache entry.
On the base station side, run the DSP ND command to query the neighbor cache
table.
4.4.3.3 Neighbor Unreachability Detection

The neighbor discovery protocol is used to detect whether a neighboring node
that has established the neighbor relationship with a node is reachable. If the
node receives an NA message in response to the NS message, the message sent to
the neighboring node has been received by the neighboring node at the IP layer.
In this case, the neighboring node is regarded as reachable. After a node
determines the link-layer address of a neighboring node, the node traces the
status of the neighbor cache entry and periodically sends an NS message. The
destination IP address in the IP header of the message is a unicast address. If the
neighboring node cannot respond with an NA message within the specified time,
the neighbor cache entry is deleted.
Table 4-4 describes the five states of a neighbor cache entry.
Table 4-4 Summary of neighbor cache entry states
State Meaning
Incomplete The destination IP address is being resolved. The link-layer

address of the neighboring node is unknown. The NS
message whose destination IP address is the solicited-
node multicast address has been sent, but the NA
response message from the peer node has not been
received.
Reachable The forwarding path of the neighboring node is normal,

and the neighboring node is reachable within the
neighbor discovery reachable time.
Stale The neighboring node is no longer regarded as reachable.

If the time in which the entry is in the Reachable state
exceeds the neighbor discovery reachable time, the state
changes to Stale. If no message is sent when the entry is
in the Stale state, the state remains unchanged.
Delay The entry enters the Delay state if either of the following
conditions is met:
● A message is sent when the entry is in the Stale state.
● The time when the entry is in the Stale state expires.
After the entry enters the Delay state, the node sends an
NS message. If the node receives an NA response message
from the peer node, the entry changes to the Reachable
state.

(2021-12-30)
SingleRAN
State Meaning
Probe ● In the Delay state, the node sends an NS message to

check whether the peer node is reachable. If the node
does not receive an NA response message from the
peer node within the Delay_First_Probe_Time (5s), the
entry changes to the Probe state.
● In the Probe state, the node sends NS messages for
multiple times. If the node receives an NA response
message from the peer node, the entry changes to the
Reachable state. If no NA response message is received
from the peer node, the entry is deleted.
For example, if node A needs to access node B and the neighbor cache entry of
node A does not contain the entry of node B, the state of the neighbor cache
entry changes as shown in Figure 4-20.
Figure 4-20 Neighbor discovery states
● Node A sends an NS message and generates a neighbor cache entry that is in

the Incomplete state.
● If node B replies with an NA message, the neighbor cache entry changes from
the Incomplete state to the Reachable state. Otherwise, the neighbor cache
entry is deleted after 3s.
● In the Reachable state, if a non-request NA message is received from node B
and the link-layer address is different before the neighbor discovery reachable
time expires, the entry state changes to Stale immediately.
● In the Stale state, if node A needs to send data to node B, node A changes the
entry state to the Delay state.
● In the Delay state, if no NA message is received within the
Delay_First_Probe_Time (5s), the state changes to Probe. If an NA message is
received, the state changes from Delay to Reachable.
● In the Probe state, a unicast NS message is sent every Retrans_Timer (1s). If a
response is received after an NS message is sent for MAX_UNICAST_SOLICIT

(2021-12-30)
SingleRAN
(three times), the entry state changes to Reachable. Otherwise, the entry is
deleted.
● As defined in the RFC4861 standard, when a node receives other ND packets
(such as RA and NS), it generates neighbor cache entries and is in the Stale
state.
On the base station side, run the SET ND command with the
ND.NDREACHABLETIME (5G gNodeB, LTE eNodeB) parameter set to 30000 as
the neighbor discovery reachable time in the Reachable state. The neighbor
discovery reachable time must be planned together with the switch and router on
the local link. If the value is too small, an excessive number of NS and NA
messages will be generated on the network.
4.4.3.4 Duplicate Address Detection

Duplicate address detection (DAD) is a detection mechanism used to determine
whether an IPv6 address is available. Neighbor discovery performs DAD before the
unicast IPv6 address of an interface takes effect. The effective unicast address is
known as a detection address. Neighbor discovery checks whether there are
duplicate IP addresses on the network by sending an NS message to the detection
address. The destination IP address in the NS message is set to the IP address to
be detected. The source IP address in the IPv6 packet header is set to an
unspecified address, and the destination IP address to the solicited-node multicast
address. The DAD process is as follows:
● When a node is configured with or automatically generates an IPv6 unicast

address, it immediately sends an NS message to check whether the IP address
is available.
● After receiving the NS message, the neighbor node configured with the IPv6
address replies to the source node with an NA message carrying the IPv6
address.
● The source node receives the NA message from the neighboring node and
considers that the IPv6 address is used by the neighboring node and is invalid.
Conversely, if the source node does not receive any NA message from the
neighboring node, the configured IPv6 address is available.
● If a link-local address conflict occurs, the response interface of the link-local
address is inactive.
A base station performs DAD on the configured global unicast address and
automatically generated link-local address.
NOTE
To enable address conflict detection in special fault scenarios, the base station sends a
small number of NS packets in the multicast domain after the unicast IPv6 address takes
effect.
The link-local address generated based on the MAC address in EUI 64 format on the
physical port of a base station is globally unique and does not conflict with IP addresses of
other network devices. If the link-local addresses of other devices on the network are
automatically generated using other methods or manually configured, they may conflict
with the link-local address of the base station. When this occurs, the interface of the base
station is unavailable. In this case, the link-local addresses of these network devices need to
be changed. The link-local addresses of base stations cannot be configured manually. This
prevents link-local address conflicts caused by incorrect configuration.

(2021-12-30)
SingleRAN
4.4.3.5 ND Proxy and DAD Proxy

The base station supports ND proxy and DAD proxy on an Ethernet port for IP
addresses of different modes in backplane-based co-transmission scenarios. The
Ethernet port acts as a proxy port and uses its own MAC address to establish the
mapping between the proxy IP address and the MAC address for the router. In
addition, the Ethernet port supports DAD for the proxy IP address.
As shown in Figure 4-21, the main control and transmission board of NR
implements co-transmission through backplane interconnection with the main
control and transmission board of LTE. IP2 is configured and ND proxy and DAD
proxy are enabled on the Ethernet port of NR. Logical IP1 is configured on the LTE
side. If IP1 is included in the network segment of IP2 and IP1 has taken effect, the
Ethernet port can perform ND proxy for IP1, and the router can directly obtain the
MAC address, MAC2, mapped from IP1. In addition, the Ethernet port sends NS
packets for IP1 to detect address conflicts.
Figure 4-21 ND proxy and DAD proxy in backplane-based co-transmission

scenarios
4.4.3.6 Router Discovery

In IPv6 transmission networking, the router discovery mechanism supports
automatic address generation, default router discovery, and parameter discovery.
This mechanism requires that routers be deployed on the transmission network.
This mechanism is implemented using RS and RA messages. The host sends an RS
message and receives an RA response message during interface startup, or
receives RA messages periodically sent by the router during normal operation. The
RA message contains the following information:
● Address auto-configuration type
● Prefix information option, indicating the lifetime of the link-local address
prefix
● Route information option
● Other information related to the host, such as the neighbor discovery
reachable time and MTU that can be used by the message sent by the host
● Automatic address generation: If the auto-configuration type in an RA
message is stateless auto-configuration, the host automatically generates an
IPv6 address based on the prefix and local interface ID in the RA message.
● Default router discovery: The host sets the default router based on the default
router information in the RA message.

(2021-12-30)
SingleRAN
● Parameter discovery: The host updates the interface parameters based on the
parameter information in the RA message.
NOTE
Base stations do not support router discovery.
4.4.3.7 Route Redirection

A router notifies the originating node on the local link through a redirect message
that a preferred neighboring router is available on the same link for packet
forwarding. The node that receives the message modifies its local router entry
accordingly. This function requires that routers be deployed on the transmission
network.
Base stations do not support route redirection, and packets are forwarded based
on static routes.
4.4.4 IP Layer Fragmentation

IPv6 has a different IP layer fragmentation mechanism from IPv4. In IPv6
transmission, the router does not support packet fragmentation. The router
discards the packet whose length exceeds the MTU size. Then the router sends an
ICMPv6 Packet Too Big message to the source NE to notify the source NE of the
router's MTU capability. Only the source NE supports fragmentation of the packet
whose length exceeds the MTU size and the destination NE reassembles the
received fragments.
NOTE
A base station can fragment and reassemble only IP packets with a maximum of five
fragments. Therefore, plan the MTU properly to prevent transmission exceptions of large-
packet services.
4.4.4.1 Interface MTU

The IPv6 MTU can be configured on an interface of a base station through the
INTERFACE.MTU6 (5G gNodeB, LTE eNodeB) parameter.
It is recommended that the MTU of an interface be set to the minimum MTU on
all backhaul networks of the interface.
By default, the base station complies with the RFC 8201 protocol and supports
Path MTU Discovery. If the MTU is not set as recommended and the MTU of the
interface is greater than the minimum MTU on all backhaul networks of the
interface, the base station automatically adjusts the Path MTU of each link based
on the ICMPv6 Packet Too Big message sent by the router. Figure 4-22 shows the
interface MTU configuration.

(2021-12-30)
SingleRAN
NOTE
Path MTU Discovery of the base station requires that the router support the sending of
ICMPv6 Packet Too Big messages and the network firewall allow such packets to pass
through. If the L2+L3 networking is used, the maximum receive unit (MRU) of the L2 switch
must be greater than the interface MTU of the base station. Otherwise, the router cannot
send ICMPv6 Packet Too Big messages.
The default value of PMTUCFG.MODE (5G gNodeB, LTE eNodeB) is PASSIVE for the base
station and the base station does not send discovery packets. If the base station receives
the ICMPv6 Packet Too Big message from the router, this indicates that the router has
discarded a small number of service packets.
In passive mode, if the MTU size of the actual outbound interface (INTERFACE.MTU6)
increases, the Path MTU entry will be updated the next time.
The maximum IPv6 receive unit before reassembly is limited over the Ethernet port on the
base station. The maximum IPv6 receive unit among boards on the base station is equal to
the maximum IPv6 MTU of the base station. For details, see the notes in the ADD
INTERFACE command help.
To prevent packet loss in the receive direction of the base station because the packet size
exceeds the maximum IPv6 receive unit, you are advised to properly plan the MTUs of the
base station and router.
Figure 4-22 Configuring an interface MTU
4.4.4.2 Path MTU Discovery

The base station supports path MTU discovery when PMTUCFG.MODE (5G
gNodeB, LTE eNodeB) is set to ACTIVE. The base station actively sends packets
for path MTU discovery on each service link. If the MTU is not set as
recommended, this function can adjust the path MTU of each link in time.
Figure 4-23 shows the path MTU discovery process.

(2021-12-30)
SingleRAN
Figure 4-23 Path MTU discovery process
1. The base station initiates the MTU discovery to the destination node on each
service link. The initial length of a discovery packet is the interface MTU size.
During the discovery, the path MTU size is 1280 bytes. For an IKE link, if
IKEPEER.IPSECPREFRGSW (5G gNodeB, LTE eNodeB) is set to OFF before
encryption, the first detection result is the Path MTU in passive mode after
the passive mode is switched to the active mode.
2. If an ICMPv6 Packet Too Big message is received within the period specified
by PMTUCFG.TIMEOUTDUR (5G gNodeB, LTE eNodeB), this indicates that
the length of the detection packet exceeds the MTU of the router. After
recording the MTU of the router, the base station adjusts the length of the
detection packet and initiates the detection again.
3. If another ICMPv6 Packet Too Big message is received within the period
specified by PMTUCFG.TIMEOUTDUR (5G gNodeB, LTE eNodeB), repeat
step 2. If an ICMPv6 Destination Unreachable message is received within the
period specified by PMTUCFG.TIMEOUTDUR (5G gNodeB, LTE eNodeB), this
indicates that the discovery is successful.
Successful Discovery
After the discovery is successful, the base station uses the router MTU that is last
recorded as the path MTU of the link. If the base station does not receive an
ICMPv6 Packet Too Big message during the discovery, the base station changes
the path MTU to the interface MTU.

(2021-12-30)
SingleRAN
Abnormal Discovery
In the discovery process, the following are true within the period specified by
PMTUCFG.TIMEOUTDUR (5G gNodeB, LTE eNodeB):
● If neither the ICMPv6 Packet Too Big nor ICMPv6 Destination Unreachable
message is received, the Path MTU of the link is changed to the interface
MTU.
● If the ICMPv6 Packet Too Big message is received but the ICMPv6 Destination
Unreachable message is not, the Path MTU of the link is changed to the
router MTU recorded last time.
Aging and Update

● After the discovery is successful, set the PMTUCFG.AGINGTIME (5G gNodeB,
LTE eNodeB) parameter to specify the aging time of the path MTU. After the
path MTU is aged out, if the service data of a link is sent within 4 hours, the
discovery is started again. During the discovery, the path MTU is the value
before the aging. If no service data is sent over a link within 4 hours, the path
MTU value before the aging is cleared. When there is service data to be sent,
the discovery is started again, which follows the same process.
● If the discovery is abnormal, the base station automatically uses the default
path MTU discovery mechanism after the path MTU is aged out.
NOTE
If the following deployment conditions of path MTU discovery are not met, path MTU
discovery will be abnormal:
● The router must support the sending of ICMPv6 Packet Too Big messages.
● The peer NE must support the sending of ICMPv6 Destination Unreachable messages,
and the destination port of the discovery (specified by PMTUCFG.PORTNO (5G
gNodeB, LTE eNodeB)) on the base station must be a non-service port of the peer NE.
● The network firewall must allow the preceding ICMPv6 packets and discovery packets of
the base station to pass through.
UDP packets are sent during path MTU discovery. If there are a large number of links in a
base station, the peer NE will receive a large number of discovery packets.
During path MTU discovery, if the route of the base station or the MTU of the router is
adjusted, the new MTU may fail to be discovered. The MTU can be obtained after the next
discovery is complete.
During a base station upgrade, the first discovered MTU may be inaccurate due to the
sequence in which the base station routes take effect. The MTU can be updated after the
next discovery is complete.
4.5 Transport Layer

The IPv6 transport layer consists of four protocols: User Datagram Protocol (UDP),
Stream Control Transmission Protocol (SCTP), Transmission Control Protocol (TCP),
and GPRS Tunneling Protocol-User Plane (GTP-U). The protocol functions are the
same as those of IPv4. For details, see IPv4 Transmission.
● UDP is used to transmit data. UDP is a connectionless and unreliable
transport layer protocol based on the IP layer.
● SCTP runs over the IP layer and provides reliable connection-oriented
transmission between two SCTP endpoints by establishing an SCTP

(2021-12-30)
SingleRAN
association. For details, see RFC4960. Only one SCTP association is established
between two endpoints.
● TCP is a reliable connection-oriented transport layer protocol. It is used for
carrying OM channels of LTE and NR.
● GTP-U is used to transmit user data of the S1 and X2 interfaces of LTE and
NR. It complies with 3GPP TS 29.281 and runs over UDP.
4.6 IPv6 Transport Protocol Stacks for Interfaces

4.6.1 Protocol Stacks for LTE Transport Interfaces
Transmission interfaces on the E-UTRAN include the S1 and X2/eX2 interfaces.
Control- and user-plane protocols for these interfaces are essential to the
communications between an eNodeB and its peer devices and support IPv6
transmission.
NB-IoT supports only S1 and X2-C (control plane) interfaces and supports IPv6
transmission.
The transport bearer protocols above the IP layer in the following interface
protocol stacks are the same as those in IPv4 transmission. For details, see IPv4
Transmission.
S1 Interface
As shown in Figure 4-24, the control plane and user plane of the S1 interface use
IPv6, and the data link layer and physical layer use Ethernet.
● The control plane of the S1 interface uses SCTP at the transport layer.
● The user plane of the S1 interface uses GTP-U over UDP/IP at the transport
layer.
Figure 4-24 Protocol stack for the S1 interface

(2021-12-30)
SingleRAN
X2 Interface
As shown in Figure 4-25, the control plane and user plane of the X2 interface use
● The control plane of the X2 interface uses SCTP at the transport layer.
● The user plane of the X2 interface uses GTP-U over UDP/IP at the transport
layer.
Figure 4-25 Protocol stack for the X2 interface
eX2 Interface
As shown in Figure 4-26, the control plane and user plane of the eX2 interface
use IPv6, and the data link layer and physical layer use Ethernet.
● The control plane of the eX2 interface uses SCTP at the transport layer.
● The user plane of the eX2 interface uses UDP/IP at the transport layer.

(2021-12-30)
SingleRAN
Figure 4-26 Protocol stack for the eX2 interface
4.6.2 Protocol Stacks for NSA NR Transport Interfaces

Transmission interfaces on the NSA NR RAN include the S1-U, X2, and eXn-U
interfaces. Control- and user-plane protocols for these interfaces are essential to
the communications between a gNodeB and its peer devices.
Transmission.
S1 Interface
Figure 4-27 shows the protocol stack for the S1 interface. The transmission bearer
protocols above the IP layer are the same as those in IPv4 transmission. The user
plane uses IPv6, and the data link layer and physical layer use Ethernet.
The user plane of the S1 interface uses GTP-U over UDP/IP at the transport layer.

(2021-12-30)
SingleRAN
Figure 4-27 Protocol stack for the S1 interface user plane
X2 Interface
As shown in Figure 4-28, the control plane and user plane of the X2 interface use
IP, and the data link layer and physical layer use Ethernet.
● The control plane of the X2 interface uses SCTP at the transport layer.
● The user plane of the X2 interface uses GTP-U over UDP/IP at the transport
layer.
Figure 4-28 Protocol stack for the X2 interface

(2021-12-30)
SingleRAN
eXn Interface
As shown in Figure 4-29, the user plane of the eXn interface uses IP, and the data
link layer and physical layer use Ethernet.
The user plane of the eXn interface uses UDP/IP at the transport layer.
Figure 4-29 Protocol stack for the eXn interface
4.6.3 Protocol Stacks for SA NR Transport Interfaces

Transmission interfaces on the 5G RAN include the NG, Xn, and eXn-U interfaces.
Control- and user-plane protocols for these interfaces are essential to the
communications between a gNodeB and its peer devices. IPv6 transmission is
supported.
Transmission.
NG Interface
As shown in Figure 4-30, the control plane and user plane of the NG interface use
● The control plane of the NG interface uses SCTP at the transport layer.
● The user plane of the NG interface uses GTP-U over UDP/IP at the transport
layer.

(2021-12-30)
SingleRAN
Figure 4-30 Protocol stack for the NG interface
Xn Interface
As shown in Figure 4-31, the control plane and user plane of the Xn interface use
● The control plane of the Xn interface uses SCTP at the transport layer.
● The user plane of the Xn interface uses GTP-U over UDP/IP at the transport
layer.
Figure 4-31 Protocol stack for the Xn interface

(2021-12-30)
SingleRAN
eXn Interface
As shown in Figure 4-32, the user plane of the eXn interface uses IP, and the data
link layer and physical layer use Ethernet.
The user plane of the eXn interface uses UDP/IP at the transport layer.
Figure 4-32 Protocol stack for the eXn interface
4.6.4 Protocol Stacks for Other Transport Interfaces

In addition to LTE and NR service interfaces, IPv6 transmission supports the
management-plane interface and IP clock synchronization interface for wireless
devices.
OM
The management-plane interface is the interface between the OSS and the base
station.
The management-plane interface mainly uses the TCP over IP protocol stack. In
addition to the TCP protocol, some protocols use UDP over IP. For example, NTP.
The OM channel for the base station uses IPv6 transmission over FE or GE ports.

(2021-12-30)
SingleRAN
Figure 4-33 OM channel protocol stack
OM channel IPv6 transmission can be configured by specifying parameters in the

OMCH MO. The OMCH.BEAR (LTE eNodeB, 5G gNodeB) parameter is set to
IPV6, and the OMCH.IP6 (LTE eNodeB, 5G gNodeB) parameter can be set to an
IPv6 address shared with other interfaces or to an independent IPv6 address.
The local IPv6 address of the OMCH can be configured using either of the
following methods:
● Configure the IPADDR6 MO, and then set the OMCH.IP6 (LTE eNodeB, 5G
gNodeB) parameter to the same value as the IPADDR6.IPV6 (LTE eNodeB,
5G gNodeB) parameter. This method can be used when the IPv6 address of
the OMCH needs to be set to an interface IP address.
● Set the OMCH.IP6 (LTE eNodeB, 5G gNodeB) parameter in the OMCH MO.
You do not need to configure the IPADDR6 MO. This IP address is the IP
address of the loopback interface. This method is used when main control
boards work in active/standby mode.
For both configuration methods, ensure that the IPv6 route between the local IPv6
address of the OMCH and the MAE is reachable.
NOTE
The OMCH can be established only when the remote maintenance IP address of the base
station configured in the MAE topology view is the same as the local IPv6 address of the
OMCH.
IP Clock Interface
The IP clock interface is used to provide 1588v2-based clock synchronization for
base stations through IPv6 packets. For more information, see Synchronization.
The IP layer of the 1588v2 layer 3 unicast protocol stack uses IPv6, and layer 2
multicast does not involve the IP layer, as shown in Figure 4-34.

(2021-12-30)
SingleRAN
Figure 4-34 Protocol stack for the IP clock interface
4.6.5 Restrictions
● Base station models
BTS3900, BTS3900 LTE, BTS5900, BTS5900 LTE, and BTS5900 5G
● Board type
Only the UMPT and UMDU boards support this function.
● Base station software version
A base station of SRAN15.1 or later is required in the following scenarios:
– The base station is configured with IPv6 or dual-stack transmission.
– The base station is configured with only IPv4 transmission but the peer
device (base station or core network device) is configured with dual-stack
transmission. The peer device sends a dual-stack message to the base
station for interface self-setup.
● Base station networking
IPv6 transmission does not support the following networking scenarios:
– The base station is configured with multiple main control boards. For
example, two UMPT boards are configured for transmission load sharing,
or one UMPT is used to transmit data and the other is used as a signaling
extension board.
– The base station is configured with extension transmission boards to
transmit data.
– IPv6 transmission is implemented through inter-BBU interconnection.
– The base station implements IPv6 co-transmission through the backplane.
● VLAN planning and configuration
In dual-stack transmission, both IPv4 and IPv6 must be configured with
VLANs based on interfaces.
● Interconnection

(2021-12-30)
SingleRAN
The IPv6 packets sent by the peer device can carry only the following
extension headers. Otherwise, the packets will be discarded by the base
station.
– Hop-by-hop options header: This header can be carried only in packets
compliant with the MLD snooping discovery protocol.
– Fragment header: This header is used for packet fragmentation.
– Authentication header: This header is used to ensure IP security.
– ESP header: This header is used to ensure IP security.

(2021-12-30)
SingleRAN
IPv6 Transmission Feature Parameter Description 5 IPv6 Transmission Networking for Interfaces
5 IPv6 Transmission Networking for

Interfaces
5.1 Overview
This chapter describes IPv6 transmission networking for the interfaces of LTE and
NR.
5.2 LTE Interface Networking

On a live network, the eNodeB generally connects to other NEs, such as the S-GW,
MME, eNodeB, IP clock server, and MAE, through a transport bearer network
(backhaul). LTE IPv6 transmission supports Layer 2 and Layer 3 networking.
NOTE
In LTE networking, only the main control board of the eNodeB can provide IPv6
transmission.
Layer 2 Networking
IPv6 transmission supports Layer 2 networking. The Layer 2 network in the LTE
system is the Ethernet switch network, which consists of Ethernet switches. The
eNodeB accesses this network through the FE/GE/10GE port. There is no router on
the Layer 2 network.

(2021-12-30)
SingleRAN
Figure 5-1 Layer 2 network
As shown in Figure 5-1, a Layer 2 network provides the bearer function at the
MAC layer. An eNodeB does not provide the Layer 2 Ethernet switching function,
and supports only packet forwarding based on IPv6 addresses. After the eNodeB
encapsulates packets into Ethernet frames, the Layer 2 switch forwards Ethernet
frames based on the source and destination MAC addresses.
You need to configure the Ethernet port, MAC layer, and IP layer, as described in
Table 5-1.
Table 5-1 Layer 2 network configuration items
Configuratio MO Configuration Description Interface

n Item
Ethernet ETHPORT Ethernet negotiation parameters, FE/GE/

such as the duplex mode and 10GE
rate, must be set. Automatic
negotiation is used by default.

(2021-12-30)
SingleRAN

n Item
MAC layer INTERFACE Interfaces, IEEE 802.1p/q, and -

MTUs must be configured.
IP layer IPADDR6 IPv6 addresses must be IPv6

configured. Services must use the address
global unicast address instead of
the link-local address.
Layer 3 Networking
A Layer 3 network is an IP route-based switching network and mainly consists of
routers. The eNodeB accesses the Layer 3 network through the FE/GE/10GE port.

(2021-12-30)
SingleRAN
Figure 5-2 shows a Layer 3 network that provides the bearer function at the IPv6
layer, which is commonly applied to LTE networks. Users must configure the
physical layer, data link layer, and IP layer. Table 5-2 describes the configurations
of a Layer 3 network over the FE/GE/10GE port.
Table 5-2 Configuration of a Layer 3 network over the FE/GE/10GE port

n Item
Physical layer ETHPORT The configuration items are the FE/GE/

same as those on a Layer 2 10GE
network. For details, see Table
5-1.
Data link INTERFACE The configuration items are the None

layer same as those on a Layer 2
5-1.
IP layer IPADDR6 and IPv6 addresses, IPv6 routing IPv6

IPROUTE6 tables, and DiffServ values must address
be configured.
5.3 NSA NR Interface Networking

On a live network, the gNodeB generally connects to other NEs, such as the S-GW,
eNodeB, IP clock server, and MAE, through a transport bearer network (backhaul).
In IP-based networking, transport bearer networks are classified into Layer 2 and
Layer 3 networks.
NOTE
In NR NSA networking, only the main control board of the gNodeB can provide IPv6
transmission.
Layer 2 Networking
A Layer 2 network is an Ethernet switching network and mainly consists of
Ethernet switches. The gNodeB accesses this network through the FE/GE/10GE
port.

(2021-12-30)
SingleRAN
MAC layer. A gNodeB does not provide the Layer 2 Ethernet switching function,
and supports only packet forwarding based on IPv6 addresses. After the gNodeB
You need to configure the Ethernet port, data link layer, and IP layer, as described
in Table 5-3.
Configuration MO Configuration Description

Item
Ethernet port ETHPORT Ethernet negotiation parameters,

such as the duplex mode and rate,
must be set. Automatic negotiation
is used by default.
Data link layer INTERFACE Interfaces and IEEE 802.1p/q must

be configured.

(2021-12-30)
SingleRAN

Item
IP layer IPADDR6 IPv6 addresses must be configured.
Layer 3 Networking
routers. The gNodeB accesses this network through the FE/GE/10GE port.
layer, which is commonly applied to NR networks. Users must configure the

(2021-12-30)
SingleRAN

Item
Physical layer ETHPORT The configuration items are the

same as those on a Layer 2
5-3.
Data link layer INTERFACE The configuration items are the

5-3.
IP layer IPADDR6 and IPROUTE6 IPv6 addresses, IPv6 routing

tables, and DiffServ values must
be configured.
5.4 SA NR Interface Networking

On a live network, the gNodeB generally connects to other NEs, such as the 5GC,
gNodeB, IP clock server, and MAE, through a transport bearer network (backhaul).
In IP-based networking, transport bearer networks are classified into Layer 2 and
Layer 3 networks.
NOTE
In NR SA networking, only the main control board of the gNodeB can provide IPv6
transmission.
Layer 2 Networking
A Layer 2 network is an Ethernet switching network and mainly consists of
Ethernet switches. The gNodeB accesses this network through the FE/GE/10GE
port.

(2021-12-30)
SingleRAN
MAC layer. A gNodeB does not provide the Layer 2 Ethernet switching function,
and supports only packet forwarding based on IPv6 addresses. After the gNodeB
You need to configure the Ethernet port, data link layer, and IP layer, as described
in Table 5-5.

Item
Ethernet port ETHPORT Ethernet negotiation parameters,

such as the duplex mode and rate,
must be set. Automatic negotiation
is used by default.
Data link layer INTERFACE Interfaces and IEEE 802.1p/q must

be configured.
IP layer IPADDR6 IPv6 addresses must be configured.

(2021-12-30)
SingleRAN
Layer 3 Networking
routers. The gNodeB accesses this network through the FE/GE/10GE port.
layer, which is commonly applied to NR networks. Users must configure the

Item
Physical layer ETHPORT The configuration items are the

5-5.
Data link layer INTERFACE The configuration items are the

5-5.

(2021-12-30)
SingleRAN

Item
IP layer IPADDR6 and IPROUTE6 IPv6 addresses, IPv6 routing

tables, and DiffServ values must
be configured.

(2021-12-30)
SingleRAN
IPv6 Transmission Feature Parameter Description 6 IPv4/IPv6 Dual-Stack Networking for Interfaces
6 IPv4/IPv6 Dual-Stack Networking for

Interfaces
6.1 Overview
As shown in Figure 6-1, a dual-stack node can be configured with both IPv4 and
IPv6 protocol stacks. The transport layer protocols, such as TCP, UDP, and SCTP, are
the same for IPv4 and IPv6. Dual-stack nodes can communicate with both nodes
that support IPv4 and those supporting IPv6.
Figure 6-1 IPv4/IPv6 dual stack
An eNodeB or gNodeB can be configured with only one type of protocols to work
as a single-stack node, or be configured with both IPv4 and IPv6 protocols to work
as a dual-stack node.
● IPv6 single-stack node

(2021-12-30)
SingleRAN
When only IPv6 transmission is used between the base station and the peer
device, only the user plane and control plane complying with the IPv6
protocol are configured on the base station.
● IPv4 single-stack node
When only IPv4 transmission is used between the base station and the peer
device, only the user plane and control plane complying with the IPv4
protocol are configured on the base station.
● IPv4/IPv6 dual-stack node
When IPv4 transmission is used between the base station and some peer
devices and IPv6 transmission is used between the base station and the other
peer devices, the user plane and control plane complying with the IPv4 and
IPv6 protocols need to be configured on the base station.
The IP protocol version of the base station must be consistent with that of the
peer device. Otherwise, the link cannot be set up.
Table 6-1 Summary of IP protocol configurations between the base station

and the peer device
IP Protocol Version IP Protocol Version for IP Protocol Version for
for the eNodeB or the Peer Device (Such Link Setup
gNodeB as the Core Network
and eNodeB/gNodeB)
IPv4 IPv4 IPv4
IPv6 IPv6 IPv6
IPv4/IPv6 IPv4 IPv4
IPv4/IPv6 IPv6 IPv6
IPv4 IPv4/IPv6 IPv4
IPv6 IPv4/IPv6 IPv6
IPv6 IPv4 The link cannot be set

up.
IPv4 IPv6 The link cannot be set

up.

(2021-12-30)
SingleRAN
IP Protocol Version IP Protocol Version for IP Protocol Version for

for the eNodeB or the Peer Device (Such Link Setup
gNodeB as the Core Network
and eNodeB/gNodeB)
IPv4/IPv6 IPv4/IPv6 For details about how to

configure both the local
and peer ends of a
service interface as
dual-stack nodes, see:
● LTE: S1 and X2 Self-
Management, eX2
Self-Management,
and IP eRAN
Engineering Guide
● 5G NSA: X2 and S1
Self-Management in
NSA Networking and
eXn Self-
Management
● 5G SA: NG and Xn
Self-Management, IP
NR Engineering
Guide, and eXn Self-
Management
Dual-stack networking may be used in NR deployment or LTE/NR IPv4-to-IPv6

transition scenarios. This section describes two typical dual-stack transmission
networking scenarios.
● Dual-stack transmission for different base stations
Different base stations use IPv4 or IPv6 single-stack transmission. When the
base stations are connected to the same peer device (core network/OSS/clock
server), the peer device must be configured with dual-stack transmission.
● Intra-base-station dual-stack transmission
– 6.3 Intra-Base Station Dual-Stack Scenario 1: Dual-Stack Transmission
for Different Interfaces
– 6.4 Intra-Base Station Dual-Stack Scenario 2: Dual-Stack Transmission
for Different Peer Devices over the X2/Xn Interface
For example, the X2 interface between eNodeBs uses IPv4 transmission,
and the X2 interface between the eNodeB and gNodeB uses IPv6
transmission.
Base stations do not support IPv4-mapped IPv6 addresses, that is, IPv4
addresses cannot be mapped to IPv6 tunnels. In dual-stack networking,
the bearer network must support dual-stack transmission. Different
scenarios have different requirements for the peer core network devices,
OSS, and base stations. Before network planning, you need to check
whether the conditions for dual-stack networking are met and learn
about the requirements for configuration planning. An interconnection
test is required before the dual-stack networking can be used.

(2021-12-30)
SingleRAN
6.2 Dual-Stack Transmission for Different Base Stations

When the LTE/NR network is reconstructed from IPv4 to IPv6 or different
networking modes are used in different areas, base stations may use different IP
protocol versions for transmission. In this case, dual-stack transmission needs to
be deployed for peer devices. For example:
● When base stations using different IP protocol versions connect to the same
core network device over the S1 and NG interfaces, the core network device
must support dual-stack transmission. IPv4 and IPv6 addresses and routes
must be configured. Base stations using different IP protocol versions can
access the network at the same time. Correct IP addresses can be selected for
base stations using different IP protocol versions. The format of the delivered
dual-stack IP address complies with 3GPP specifications (a 160-bit dual-stack
IP address, of which the first 32 bits are an IPv4 address, and the last 128 bits
are an IPv6 address). For other requirements, see the requirements for core
network devices.
● The O&M channels of base stations use different IP protocol versions. For
example, the O&M channel of the LTE/5G base station uses IPv6 transmission,
and the O&M channel of the existing GSM/UMTS base station uses IPv4
transmission. If they need to connect to the same EMS, the EMS must support
dual-stack transmission.
The bearer network must support dual-stack transmission, and IPv4 and IPv6
routes must be configured between the base station and peer device.
For a single base station, single-stack transmission is used. For details, see the
single-stack configuration. However, if the core network device delivers dual-stack
IP addresses, the base station must support the processing of the dual-stack IP
addresses in 3GPP-defined format. The eNodeB/gNodeB version must be
SRAN15.1 or later.
6.3 Intra-Base Station Dual-Stack Scenario 1: Dual-

Stack Transmission for Different Interfaces
On an LTE/NR network, different interfaces on a base station may use different IP
protocol stacks. The bearer network must use IPv4 and IPv6 routes for
communication, and dual-stack transmission must be configured for the base
station.
The following uses the S1 and X2 interfaces of the LTE network as an example.
The S1 interface uses IPv6 transmission, and other interfaces use IPv4
transmission, as shown in Figure 6-2.

(2021-12-30)
SingleRAN
Figure 6-2 Example of dual-stack networking for different interfaces
Check whether the peer device meets the following conditions before network
planning:
● The peer device supports IPv6 transmission or IPv4/IPv6 dual-stack
transmission.
● The IPv4 and IPv6 routes between the base station and the peer device are
normal.
● If the signaling from the peer device (eNodeB, gNodeB, or core network
device) carries a dual-stack IP address, the IP address format must comply
with 3GPP specifications (a 160-bit dual-stack IP address, of which the first 32
bits are an IPv4 address, and the last 128 bits are an IPv6 address). The
eNodeB/gNodeB version must be SRAN15.1 or later. The eNodeB and gNodeB
must support IPv6 transmission or can receive signaling that carries dual-stack
IP addresses from the peer device.
For details about the interface self-setup requirements, see:
● LTE: S1 and X2 Self-Management and eX2 Self-Management
● NSA: X2 and S1 Self-Management in NSA Networking and eXn Self-
Management
● SA: NG and Xn Self-Management and eXn Self-Management
Table 6-2 describes the dual-stack configuration requirements for the eNodeB and
gNodeB.

(2021-12-30)
SingleRAN
Table 6-2 Configuration requirements for dual-stack transmission over different

interfaces
Configuratio Base Station Configuration Remarks
n Item Requirement
Ethernet port ● IPv4 transmission and IPv6 None

transmission can share physical ports
or do not share physical ports.
● IPv4 transmission and IPv6
transmission have the same
requirements for physical layer
configurations.
Data link ● When IPv4 and IPv6 share an None

layer Ethernet port, IPv4 and IPv6 can
share a VLAN. If they share a VLAN,
they can share a VLAN interface.
Otherwise, different VLAN interfaces
need to be configured.
● When IPv4 and IPv6 do not share the
same Ethernet port, different
Ethernet ports can be connected to
different Ethernet networks. The
VLAN IDs of the interfaces of
different ports can be the same or
different. It is recommended that
different VLAN IDs be configured.
NOTE
For details about the VLAN configuration
requirements, see 4.3.3 VLAN. For details
about the interface configuration
requirements, see 4.3.2 Interface.
● The MTUs for IPv4 and IPv6 are
configured separately based on the
IPv4 and IPv6 transport network
plans. For details, see 4.4.4 IP Layer
Fragmentation.
IP layer Interface IP addresses, service IP None

addresses, and static routes must be
configured separately for IPv4 and IPv6
transmission.
IP addresses and routes for IPv4 and
IPv6 transmission are independent of
each other.

(2021-12-30)
SingleRAN
Configuratio Base Station Configuration Remarks

n Item Requirement
Transport Parameters in the SCTPHOST, For details, see

layer SCTPPEER, USERPLANEHOST, and Transmission
USERPLANEPEER MOs, and the OM Resource
channel or IP clock link must be Management for LTE.
configured. For details, see
IPv4 addresses are used for IPv4 Transmission
transmission, and IPv6 addresses are Resource
used for IPv6 transmission. Management for NR.

Stack Transmission for Different Peer Devices over the
X2/Xn Interface
During NR/LTE base station deployment or IPv4-to-IPv6 transition, some base
stations use IPv6 transmission, and some use IPv4 transmission. The X2/Xn
interfaces of different base stations use different IP protocol versions.
For example, in the NSA architecture, the X2 interface between the gNodeB and
eNodeB uses IPv6 transmission, the X2 interface between eNodeBs uses IPv4
transmission, and the X2 interface between gNodeBs uses IPv6 transmission, as
shown in Figure 6-3. In this case, IPv4/IPv6 dual-stack transmission needs to be
configured for the X2 interface of the gNodeB.
Figure 6-3 Example of IPv4/IPv6 dual-stack transmission for different peer devices
over the same interface
The following conditions must be met in this scenario:
● The bearer network must meet the requirements described in 6.3 Intra-Base
Station Dual-Stack Scenario 1: Dual-Stack Transmission for Different
Interfaces.
● The version of the neighboring eNodeB or gNodeB that is connected to the
gNodeB through an X2 link must be SRAN15.1 or later.

(2021-12-30)
SingleRAN
● IPv4/IPv6 dual-stack addresses are configured for the local ends of the user
plane and control plane of the X2 interface on the eNodeB.
● IPv6 single-stack addresses are configured for the local ends of the user plane
and control plane of the X2 interface on the gNodeB.
● The dual-stack transmission base station meets the configuration
requirements described in Table 6-3.
Table 6-3 Configuration requirements of IPv6 transmission between the eNodeB

and the gNodeB using dual-stack transmission over the X2 interface and IPv4
transmission between the eNodeB and the eNodeB (NSA networking)
Config eNodeB gNodeB Remarks
uratio Configuration Configuration
n Item Requirement Requirement
Ethern The configuration IPv4 transmission and -

et port requirements are IPv6 transmission
the same as those have the same
described in Table requirements for
6-2. physical layer
configurations.
Data The configuration For details about the -

link requirements are VLAN configuration
layer the same as those requirements, see
described in Table 4.3.3 VLAN. For
6-2. details about the
interface
configuration
requirements, see
4.3.2 Interface.
IP The configuration Interface IP addresses, -

layer requirements are service IP addresses,
the same as those and static routes must
described in Table be configured for IPv6
6-2. transmission.

(2021-12-30)
SingleRAN

Transp IPv4 and IPv6 user- IPv6 user-plane and ● For details, see
ort plane and control- control-plane Transmission
layer plane configurations for the Resource
configurations for X2 interface: Management for
the X2 interface: ● X2-C between the LTE.
● X2-C between eNodeB and ● For details, see
eNodeBs: gNodeB: Configure Transmission
Configure the the SCTPHOST Resource
SCTPHOST and and SCTPPEER Management for
SCTPPEER MOs MOs for IPv6. NR.
for IPv4. ● X2-U between ● When the service
● X2-C between gNodeBs or interfaces such as X2
the eNodeB and between the and Xn use dual-
gNodeB: eNodeB and stack transmission,
Configure the gNodeB: Configure only one IPv4
SCTPHOST and the control-plane host
SCTPPEER MOs USERPLANEHOST and one IPv6
for IPv6. and control-plane host
● X2-U between USERPLANEPEER can be configured
the eNodeB and MOs for IPv6. and added to the
gNodeB: ● Endpoint group: endpoint group of
Configure the Set the the interface.
USERPLANEHOS IPVERPREFERENC Multiple user-plane
T and E parameter in the hosts, user-plane
USERPLANEPEE EPGROUP MO for peers, or control-
R MOs for IPv6. the X2 interface to plane peers can be
IPv6. configured for IPv4
● X2-U between and IPv6.
eNodeBs: ● Add the control-
Configure the plane and user-
USERPLANEHOS plane
T and configurations of
USERPLANEPEE IPv6 addresses to
R MOs for IPv4. the EPGROUP MO
● Endpoint group: for the X2
Set the interface.
IPVERPREFEREN
CE parameter in
the EPGROUP
MO for the X2
interface to IPv4.
● Add the control-
plane and user-
plane
configurations of
IPv4 and IPv6
addresses to the

(2021-12-30)
SingleRAN

EPGROUP MO
for the X2
interface.
For details about
the interface self-
setup requirements
in dual-stack
scenarios, see S1
and X2 Self-
Management.
When a dual-stack IP address is configured for the X2/Xn interface, the

networking requirements are as follows:
● The X2/Xn interface supports only the same IP protocol for transmission on
the user plane and control plane. When you manually configure the
SCTPPEER or USERPLANEPEER MO for the control plane, do not configure all
the dual-stack IP addresses of the peer base station. Otherwise, the IP
protocol on the control plane may be different from that on the user plane,
and the X2/Xn interface cannot work properly.
● The same IP protocol is used over the X2/Xn interfaces between base stations
for which all the SCTP host IP addresses or user-plane host IP addresses are
dual-stack IP addresses. This is controlled by the
EPGROUP.IPVERPREFERENCE (LTE eNodeB, 5G gNodeB) parameter. For
example, if the control- or user-plane host IP addresses of base stations A, B,
and C are dual-stack addresses, the X2/Xn interfaces between A, B, and C
must use the same IP protocol for transmission. As shown in Figure 6-4, the
EPGROUP.IPVERPREFERENCE parameter for the X2 interface of eNodeB C is
set to IPv6, which is different from those of eNodeB A and eNodeB B. As a
result, the X2 interface between eNodeB C and eNodeB A cannot work
properly. The gNodeB uses IPv6 single-stack transmission.

(2021-12-30)
SingleRAN
Figure 6-4 Example of IPv4 transmission over some X2 interfaces between

eNodeBs and IPv6 transmission over some other X2 interfaces

Stack Transmission on the User Plane and Control
Plane of the S1/NG Interface
NOTE
This scenario is complex and not recommended. It is recommended that the user plane and
control plane of the core network evolve to IPv6 at the same time.
Typical scenarios of IPv6 transmission over the S1 and NG interfaces are as

follows:
New NR base station deployment:
● In SA networking, it is recommended that the same IP protocol be used on

the control plane and user plane of the NG interface.
● In NSA networking, the S1-U interface of the gNodeB uses IPv6 transmission,
and the S1 interface of the existing eNodeB still uses IPv4 transmission. In this
case, the user plane and the control plane use different IP protocols. As shown
in Figure 6-5, in NSA networking, the S1-U interfaces of gNodeBs use IPv6
transmission, and the S1-U and S1-C interfaces of eNodeBs use IPv4
transmission.
If the LTE network evolves from IPv4 to IPv6, it is recommended that the S1-U and
S1-C interfaces evolve to IPv6 at the same time.

(2021-12-30)
SingleRAN
Figure 6-5 Example of IPv6 transmission over the gNodeB S1-U interfaces and
IPv4 transmission over the eNodeB S1-C/S1-U interfaces (NSA networking)
The following conditions must be met in this scenario:

● The requirements for the bearer network are the same as those described in
6.3 Intra-Base Station Dual-Stack Scenario 1: Dual-Stack Transmission for
Different Interfaces.
● If core network devices need to support different IP protocol versions on the
user plane and control plane for the same user. IPv4 and IPv6 addresses and
routes for the control plane and user plane must be planned separately.
● If the signaling from the core network carries a dual-stack IP address, the IP
address format must comply with 3GPP specifications (a 160-bit dual-stack IP
address, of which the first 32 bits indicate an IPv4 address, and the last 128
bits are an IPv6 address). The eNodeB/gNodeB must be of SRAN15.1 or later
to support IPv6 transmission or receive signaling that carries dual-stack IP
addresses from the peer device.
● The S1 interface of the eNodeB uses the IPv4 single stack transmission, and
the S1 interface of the gNodeB uses the IPv6 single-stack transmission.
For IPv4-to-IPv6 transition on the X2/Xn interface between base stations, it is
recommended that the user plane and control plane use the same IP protocol
version. Otherwise, interface self-setup will fail. For details, see S1 and X2 Self-
Management.
Table 6-4 Configuration requirements for dual-stack transmission on the user

plane and control plane
Configuration Base Station Configuration Remarks
Item Requirement
Ethernet port The configuration requirements None

are the same as those described in
Table 6-2.
Data link layer The configuration requirements None

Table 6-2.

(2021-12-30)
SingleRAN
Configuration Base Station Configuration Remarks

Item Requirement
IP layer The configuration requirements None

Table 6-2.
Transport Parameters in the SCTPHOST, ● For details, see

layer SCTPPEER, USERPLANEHOST, Transmission Resource
and USERPLANEPEER MOs must Management for LTE.
be configured. IPv4 addresses are ● For details, see
used for IPv4 transmission, and Transmission Resource
IPv6 addresses are used for IPv6 Management for NR.
transmission.

(2021-12-30)
SingleRAN
IPv6 Transmission Feature Parameter Description 7 Transmission Reliability
7 Transmission Reliability
7.1 Introduction
Table 7-1 lists the reliability features supported by a base station in IPv6
transmission networking.
Table 7-1 Reliability features in IPv6 transmission networking

Port/Link Protocol Layer Base Station Support for IPv6
Backup Transmission Transmission
Reliability
Ethernet port/ Physical layer - -

link backup
Data link layer Ethernet Link Supported
Aggregation
IP layer IP Route Backup Supported
Service link Application layer (Control-plane) Supported

backup SCTP Multihoming
(Management- Supported
plane) OM Channel
Backup
7.2 Control-Plane SCTP Multihoming

For details about SCTP, see 4.5 Transport Layer.
If an SCTP endpoint has multiple destination addresses, the SCTP endpoint is a
multi-homing endpoint.
The base station supports the following multi-homing scenarios:
● Both SCTP endpoints are multi-homed, and only parallel paths are supported.
See Figure 7-1. The path between the first local IP address and the first peer

(2021-12-30)
SingleRAN
IP address serves as the primary SCTP path by default. The path between the
second local IP address and the second peer IP address serves as the
secondary SCTP path. Both primary and secondary transmission paths must
be set up. If a peer address is unreachable, ALM-25955 SCTP Link IP Address
Unreachable is reported.
● An endpoint of an SCTP association is multi-homed. See Figure 7-2. When the
SCTP path between the endpoint and the first peer IP address is faulty, the
SCTP path between the endpoint and the second peer IP address is used. This
requires that the peer devices, such as the base station controller, core
network, or base station, support this multi-homing mode.
– The base station checks multiple destination IP addresses at the same
time only when the peer SCTP endpoint is multi-homed. The base station
reports ALM-25955 SCTP Link IP Address Unreachable only when some
destination IP addresses are unreachable.
– If the peer SCTP endpoint is a single IP endpoint, the local end checks the
path from the first IP address to the peer IP address by default. If the
path is unreachable, the local end checks the path from the second IP
address to the peer IP address. In this scenario, the base station does not
report ALM-25955 SCTP Link IP Address Unreachable.
The base station only allows multiple IP addresses of SCTP multi-homed endpoints
to use the same IP protocol version. Dual-stack IP addresses cannot be configured
on one endpoint.
In endpoint configuration mode, the SCTPTEMPLATE.SWITCHBACKFLAG (5G
gNodeB, LTE eNodeB) parameter specifies whether services are switched back to
the primary path after it becomes functional. The value ENABLE is recommended.
Figure 7-1 Scenario where the two endpoints of an SCTP association are both
multi-homed and only parallel paths are supported

(2021-12-30)
SingleRAN
Figure 7-2 Scenario where one SCTP association endpoint is multi-homed
NOTE
If both endpoints of an SCTP association are multi-homed, configure SCTP links on the base
station side as follows:
The first local IP address, second local IP address, first peer IP address, and second peer IP
address are all set to valid IP addresses.
If one endpoint of an SCTP association is multi-homed, configure SCTP links on the base
station side as follows:
● If the peer SCTP endpoint is multi-homed, the first local IP address is set to a valid IP
address, the second local IP address is set to 0:0:0:0:0:0:0:0, and the first and second
peer IP addresses are set to valid IP addresses.
● If the peer SCTP endpoint is a single IP endpoint, the first and second local IP addresses
are set to valid IP addresses, the first peer IP address is set to a valid IP address, and the
second peer IP address is set to 0:0:0:0:0:0:0:0.
SCTP multi-homing is not equivalent to multiple Transport Network Layer Associations
(TNLAs). SCTP multi-homing is used only for reliability. Only one SCTP link is generated,
and only one path to a peer IP address takes effect. In the case of multi-TNLA, multiple
SCTP links are generated and all SCTP links take effect at the same time. For details about
multi-TNLA, see NG and Xn Self-Management Feature Parameter Description.
7.3 User Plane Backup

User plane backup includes active/standby user plane and user plane load sharing.
The eNodeB, gNodeB, and LTE and NR co-MPT base station support user plane
backup.
● When the transport network provides active/standby transmission path, the
base station can use the active/standby user plane function to support user
plane E2E redundancy backup. The backup function does not depend on the
active/standby IP route of the transport network.
● When the transport network provides multiple transmission paths for load
sharing, the base station can use the user plane load sharing function to
support user plane E2E load sharing, improving transmission bandwidth and
enhancing reliability.

(2021-12-30)
SingleRAN
NOTE
● The active/standby user plane and user plane load sharing can be configured only in
endpoint mode.
● Currently, only the S1 and NG interfaces support active/standby user plane and user
plane load sharing. For the X2, eX2, Xn, or eXn interface, multiple user-plane hosts
cannot be configured for the same IP protocol version.
● The active/standby user plane scenario is supported only in IPv4 transmission, and
source-based routes need to be configured.
● Both IPv4 transmission and IPv6 transmission support user-plane load sharing, and
source-based routes need to be configured.
● Currently, only the UMPT board supports user plane load sharing.
As shown in Figure 7-3, for all user-plane hosts (USERPLANEHOST MOs) that are
added to the same EPGROUP MO, load sharing is implemented among the user-
plane hosts with the same priority, and active/standby user plane is implemented
among the user-plane hosts with different priorities.
Figure 7-3 User plane backup for a base station
The base station uses the GTP-U to detect the connectivity of active and standby
user-plane paths.
● When the base station detects that the active path is faulty but the standby
path is normal, new services are established on the standby path.
● When the base station detects that the standby path is faulty, new services
are established on the active path and services on the standby path are not
switched to the active path.
7.4 IP Route Backup

As shown in Figure 7-4, the base station supports both source-based and
destination-based routes in IP route backup.
● For destination-based routes, two routes with the same destination IP address
but different next-hop IP addresses and priorities must be configured in
active/standby mode.
● For source-based routes, two routes with the same source IP address but
different next-hop IP addresses and priorities must be configured in active/
standby mode.

(2021-12-30)
SingleRAN
Figure 7-4 Active and standby IP routes of the base station
Configure the logical IP routes to the base station on the gateway routers RT1 and
RT2.
● On RT1, configure two routes to the base station with the next hops as the
port IP1 and RT2.
● On RT2, configure two routes to the base station with the next hops as the
port IP2 and RT1.
The route priority determines whether a route is active or standby. The principles
for activating route priorities are as follows:
● The high-priority route is preferentially activated.

● If this route is faulty, the base station activates the other route. After being
restored, the high-priority route is automatically activated.
NOTE
● IPv6 does not support equal-cost routes.

● Active and standby routes are not supported in IPv6 DR redundancy scenarios.
● Only two source-based routes with the same route type (specified by
SRCIPROUTE6.RTTYPE (5G gNodeB, LTE eNodeB)) can form active and standby routes.
● Active and standby IPv6 routes (destination- or source-based routes) cannot be
configured between an IPv4 IPsec tunnel and an IPv6 IPsec tunnel.
In this scenario, the base station is connected to two gateway routers, which work
in active/standby mode. In the versions earlier than SRAN17.0, the active and
standby IPv6 routes do not support BFD-based route switchovers. They can be
switched only based on the physical port status. In SRAN17.0, the active and
standby IPv6 routes bound to IPv6 BFD can be switched over.

(2021-12-30)
SingleRAN
NOTE
● If RT1 becomes faulty, although its BFD session with the base station can become
normal soon after a restart, RT1 needs time to learn its routes to peer service NEs, such
as core network NEs. Therefore, route switchover delay is specified on the base station
so that a route switchback can be performed after RT1 has learned the routes to its peer
service NEs.
● The base station does not support inter-board route backup.
● The GTRANSPARA.SBTIME (5G gNodeB, LTE eNodeB) parameter setting (specifying
the time of an active/standby route switchback) is valid only when the active and
standby routes are bound to a BFD session, and does not apply when the active and
standby routes are switched based on the physical port status.
7.5 OM Channel Backup

On the base station side, OM channel backup is introduced between the base
station and the MAE to provide redundancy backup for OM channels in scenarios
such as hybrid transmission of high-QoS and low-QoS links and hybrid
transmission of security and non-security domains. The gNodeB, eNodeB, and co-
MPT base station support IPv6 OM channel backup.
As shown in Figure 7-5, IPv6 OM channel backup supports the following modes:
● IPv6 single-stack networking: Two OM channels for IPv6 transmission can
work in active/standby mode.
● IPv4/IPv6 dual-stack networking: An OM channel for IPv4 transmission and an
OM channel for IPv6 transmission work in active/standby mode.
Figure 7-5 OM channel backup for the base station

(2021-12-30)
SingleRAN
The active and standby OM channels of the base station can share an IP address
with another interface or use a separate IP address. In addition, the route from the
base station to the MAE must be planned. The OM IP address and route for each
base station needs to be configured on the MAE.
IP addresses used by the active and standby OM channels:
● Base station: Two IP addresses need to be configured as the local IP addresses

of the active and standby OM channels.
● MAE: Only one IP address needs to be configured as the peer IP address of
the active and standby OM channels.
NE attribute parameters, IP address 1 and IP address 2, need to be configured
on the MAE. The two IP addresses are the two OM IP addresses of the NE,
that is, the two local IP addresses of the active and standby OM channels on
the base station. The MAE automatically sets up OM channels with the two IP
addresses. Therefore, when an NE is disconnected, the MAE automatically
switches between IP address 1 and IP address 2 to ensure OM channel
communication. OM channel communication can be ensured as long as either
IP address is valid. If both IP addresses are reachable, the MAE preferentially
uses IP address 1. The MAE does not automatically switch to the other IP
address when the NE connection is normal.
For the IP routes used by the active and standby OM channels, in IPv6
transmission scenarios, the active and standby OM channels can be bound to the
routes or not bound to the routes.
● In route-binding mode, if two OM channels for IPv6 transmission work in
active/standby mode and destination-based routes are configured, you need
to configure separate IPROUTE6 MOs for the OM channels. In addition,
specify OMCH.BEAR (LTE eNodeB, 5G gNodeB), set OMCH.BRT (LTE
eNodeB, 5G gNodeB) to YES, and enter the indexes of the routes to be
bound for OMCH.RTIDX (LTE eNodeB, 5G gNodeB). If the MAE uses the
remote HA system and different routes are required by the active and standby
MAE servers, bind routes to the active and standby MAE servers through the
active and standby OM channels.
After the base station is started, the route bound to the active OM channel
takes effect when the active OM channel takes effect, and the standby OM
channel and the route bound to the standby OM channel do not take effect.
After services are switched from the active OM channel to the standby OM
channel, the route bound to the standby OM channel takes effect when the
standby OM channel takes effect. Then, the active OM channel and the route
bound to the active OM channel do not take effect.
Therefore, ensure that the route bound to the OM channel forwards only the
OM channel traffic, not other service flows. Otherwise, when the OMCH does
not take effect, the route bound to the OMCH does not take effect, affecting
forwarding of other service flows.
● In route-unbinding mode, if two OM channels for IPv6 transmission work in
active/standby mode and source-based routes are configured, or if a single
OM channel for IPv4 transmission and a single OM channel for IPv6
transmission work in active/standby mode, no route needs to be bound during
OM channel configuration. Instead, routes for the OM channels are added by
adding destination- or source-based routes, and OMCH.BRT (LTE eNodeB, 5G
gNodeB) is set to NO.

(2021-12-30)
SingleRAN
NOTE
● The active and standby OM channels must correspond to the same MAE-Access.
● When the active and standby OM channels are bound to routes, the active and standby
OM channels cannot share the routes with services. This is because the route of the
active or standby OM channel becomes unavailable if the active and standby OM
channels are switched.
● For active and standby IPv6 OM channels, the MAE software version must be SRAN16.1
or later. Otherwise, OM channel backup is not supported in IPv6 transmission scenarios.
● When a base station is configured with two main control boards, the active and standby
OM channels cannot be configured on different main control boards in IPv6
transmission scenarios.
● If the OM channel for IPv4 single-stack transmission and that for IPv6 single-stack
transmission work in active/standby mode, IPv4 transmission supports only the new
model.
The MAE detects the OM channel connectivity status by using a handshake

mechanism at the application layer. If the active OM channel fails, the MAE
instructs the base station through the standby OM channel to initiate an OM
channel switchover.
After the active OM channel recovers, the OM channel is automatically switched

back to the active OM channel, which is called the OM channel switchback
function.
● When the GTRANSPARA.OMCHSWITCHBACK (LTE eNodeB, 5G gNodeB)

parameter is set to ENABLE to enable the OM channel switchback function,
the OMCH.CHECKTYPE (LTE eNodeB, 5G gNodeB) parameter of the active
OMCH must be set to AUTO_UDPSESSION. When the OSS connects to the
standby OMCH, the base station automatically creates a UDP session from
the local IP address of the active OMCH to the MAE, and the OM channel
switchback function depends on status detection of this automatically created
UDP session. After detecting that the active OM channel recovers, the base
station disconnects the TCP connection of the standby OM channel, which
enables the MAE to initiate a connection on the active OM channel again.
If the PACKETFILTERING MO is configured for the base station, ACL rules
(defined by the ACLRULE6 MO) must be manually configured for
automatically established UDP sessions in the ACL6 MO associated with the
PACKETFILTERING MO. Otherwise, the OM channel switchback function does
not take effect.
On the base station, manually configure the ACLRULE6 MO corresponding to
the UDP session to allow the MAE packets to reach the base station. The
configuration requirements are as follows:
– Set the source IPv6 address (specified by ACLRULE6.SIP (LTE eNodeB, 5G
gNodeB)) of the ACL rule to the IPv6 address of the MAE.
– Set the destination IPv6 address (specified by ACLRULE6.DIP (LTE
eNodeB, 5G gNodeB)) of the ACL rule to the local IPv6 address of the
active OMCH on the base station.
– Set the protocol type (specified by ACLRULE6.PT (LTE eNodeB, 5G
gNodeB)) to UDP, source port 1 (specified by ACLRULE6.SPT1 (LTE
eNodeB, 5G gNodeB)) to 31252, and destination port 1 (specified by
ACLRULE6.DPT1 (LTE eNodeB, 5G gNodeB)) to 65043.

(2021-12-30)
SingleRAN
– Set ACLRULE6.ACLID (LTE eNodeB, 5G gNodeB) of the ACL rule to be

the same as the value of PACKETFILTERING.ACLID (LTE eNodeB, 5G
gNodeB).
● When GTRANSPARA.OMCHSWITCHBACK (LTE eNodeB, 5G gNodeB) is set
to DISABLE to disable the OM channel switchback function, neither the MAE
nor the base station automatically switches back to the active OM channel
after the active OM channel recovers. The MAE initiates a connection on the
active OM channel again only after the standby OM channel becomes faulty.
A security mechanism is introduced that allows the MAE or base station to
perform authentication on OMCH switchover messages transmitted by the
MAE over the active or standby OM channel. This helps prevent a spoofed
MAE from delivering fake switchover instructions and protect switchover
messages against replay attacks or from being tampered with.
7.6 Ethernet Link Aggregation

Link aggregation (IEEE802.3ad) combines two or more Ethernet links that are
added to the same link aggregation group (LAG) into a logical link. If a link in a
LAG working in active/standby mode is faulty, services on this link will be switched
over to functional links, preventing service interruption and improving reliability.
When a LAG works in load sharing mode, the transmission link rate can be
increased. However, the rate of the LAG cannot exceed the board capability
specifications. Currently, Huawei base stations support only intra-board load
sharing in link aggregation.
7.6.1 Basic Principles

The parameters of member links in a LAG, such as the optical/electrical mode,
rate, and duplex mode, must be the same. In addition, the number of links, rate,
and duplex mode at the local end must be the same as those at the peer end of
the LAG. Each member port in a LAG must be configured with a priority (specified
by ETHTRKLNK.PRI (LTE eNodeB, 5G gNodeB)). Port priorities are used to
determine the ports to be used during Link Aggregation Control Protocol (LACP)
negotiation. The MAC address of a LAG is the MAC address of the port first added
to the group.
The type of a LAG can be set to static or manual by setting the ETHTRUNK.LACP
(LTE eNodeB, 5G gNodeB) parameter.
● Member ports are manually added to a static LAG, but LACP is used between
the two ends to negotiate the actual member ports.
● Member ports are manually added to a manual LAG, and all these ports are
actual member ports without LACP negotiation.
The LAG type must be consistent between the two ends.
According to the IEEE 802.3ad standard, the intervals for sending LACPDUs are
classified into long timeout and short timeout. The base station supports short
timeout, and its peer end must also support short timeout to enable fast link fault
detection.

(2021-12-30)
SingleRAN
7.6.2 Application on the Base Station

The typical application scenario of link aggregation on the base station side is that
multiple FE/GE/10GE/25GE ports on the main control board or transmission
extension board of a base station form a link aggregation group and connect to a
layer 2 or layer 3 transmission device. The link aggregation mode is static and the
working mode is load sharing.
Figure 7-6 Base station connecting to the Layer 2 or Layer 3 transmission device
through link aggregation
The Ethernet link aggregation load balancing factor of Layer 2 packets on the
base station side is source MAC address+destination MAC address.
Table 7-2 lists the load balancing factors for Layer 3 packets.
In heavy traffic scenarios, different load balancing effect can be obtained by
selecting different factors. If Layer 4 or higher-layer packet information is used as
the load balancing factor, traffic is evenly distributed to member ports.
Table 7-2 Ethernet link aggregation load balancing factor of Layer 3 packets on
the base station side
Packet Type Load Balancing Factor
GTP-U If TRANSFUNCTIONSW.ETHTRKLBMODE (LTE eNodeB,

5G gNodeB) is set to LB_MODE_1(Load Balancing Mode
1), the load balancing factor is source IP address
+destination IP address+Flow Label.
Flow Label is filled with the last 20 bits of the TEID.
If TRANSFUNCTIONSW.ETHTRKLBMODE (LTE eNodeB,

+destination IP address+DSCP.
UDP (including If TRANSFUNCTIONSW.ETHTRKLBMODE (LTE eNodeB,

user-plane service 5G gNodeB) is set to LB_MODE_1(Load Balancing Mode
packets and 1), the load balancing factor is source IP address
feature packets +destination IP address+Flow Label.
such as IKE, Flow Label is filled with the hash value of the source port
TWAMP, BFD, and number and destination port number.
clock packets)

(2021-12-30)
SingleRAN
Packet Type Load Balancing Factor
If TRANSFUNCTIONSW.ETHTRKLBMODE (LTE eNodeB,

+destination IP address+DSCP.
Other IP packets The load balancing factor is source IP address+destination

(such as TCP and IP address+DSCP.
SCTP packets)
NOTE
● A member port in a link aggregation group of the base station cannot be configured
with a non-AUTOPORT transmission resource group configured using the IPRSCGRP
MO. If a port is manually or automatically configured with a non-AUTOPORT
transmission resource group, delete the transmission resource group before adding the
port to a link aggregation group.
● The TRANSFUNCTIONSW.ETHTRKLBMODE (LTE eNodeB, 5G gNodeB) parameter
takes effect only on UMPT/UMDU boards in non-IPsec scenarios.

(2021-12-30)
SingleRAN
IPv6 Transmission Feature Parameter Description 8 Transmission Maintenance and Detection
8 Transmission Maintenance and

Detection
8.1 Overview
The fault detection technologies of the IPv6 transport network include 8.2 ICMPv6
Ping, 8.3 Trace Route, 8.4 GTP-U Echo, 8.5 LLDP, and IP Active Performance
Measurement, which are applied to different protocol layers. Fault detection
improves network reliability.
Table 8-1 describes the mapping between maintenance and detection

mechanisms and their applicable layers.
Table 8-1 Transmission reliability and maintenance and detection methods

supported by the base station
Protocol Object Maintenance and Detection Interval

Layer Detection
Mechanism
Transport Base OM handshake The detection is performed

layer/ station OM protocol once every minute.
Application channel NOTE
layer By default, if the MAE-Access
detects three consecutive
handshake failures, ALM-25901
Remote Maintenance Link Failure
is reported.
Control- SCTP By default, the base station

plane link detects SCTP heartbeats once
every 5000 ms. The detection
interval is configurable.
NOTE
After detecting an SCTP link
disconnection, the base station
reports ALM-25888 SCTP Link
Fault.

(2021-12-30)
SingleRAN

Layer Detection
Mechanism
S1/X2/eX2/ GTP-U Echo The base station checks the

NG/Xn/eXn connectivity of the GTP-U
user-plane tunnel once every minute.
path NOTE
After detecting three (default
value) consecutive GTP-U tunnel
disconnections, the base station
reports ALM-25954 User Plane
Fault.
Network IP-layer link ICMPv6 ping By default, the base station

layer performs the detection once
every 1000 ms.
Trace route None
BFD By default, the base station

detects the route reachability
once every 100 ms. The
detection interval is
configurable within the range
of 10 ms to 1000 ms.
NOTE
By default, after detecting that a
route is unreachable for three
consecutive times, the base
station reports ALM-25899 BFD
Session Fault.
Neighbor If service data is continuously

unreachability transmitted on a link, the
detection detection time is determined
by the neighbor discovery
reachable time, which can be
configured using the
ND.NDREACHABLETIME (5G
gNodeB, LTE eNodeB)
parameter.
If no service data is sent or
heartbeat detection is not
performed for a long time on a
link, the base station performs
the detection after the timer
for a neighbor cache entry
being in the Stale state expires
and the entry enters the Delay
state.
For details, see 4.4.3.3
Neighbor Unreachability
Detection.

(2021-12-30)
SingleRAN

Layer Detection
Mechanism
S1/NG/X2/X IP Active For details on TWAMP, see IP

n/eXn user- Performance Active Performance
plane path Measurement Measurement.
Data link Ethernet LLDP By default, the detection is
layer link performed once every 30s. This
function is configured using
the parameter specifying the
interval for transmitting LLDP
packets, which can be set to a
value in the range of 5 to
32768, in seconds.
8.2 ICMPv6 Ping

Different from other fault detection technologies, ICMPv6 ping detection requires
that the peer device should support the ICMPv6 Echo response message, and that
the bearer network should not filter the ICMPv6 Echo response message. In this
way, E2E link fault detection is implemented. However, peer NEs may regard
ICMPv6 ping packets as attack packets and discard them. As a result, the local end
considers that the transmission link is faulty when it fails to receive ICMPv6 Echo
response messages.
The implementation principle of ICMPv6 ping detection is as follows: A base
station sends an ICMPv6 Echo request message to the peer device. After receiving
the message, the peer device sends an ICMPv6 Echo response message to the base
station.
The base station supports continuous detection. By continuously sending ICMPv6
ping requests to the peer end, the base station can continuously detect the
connectivity of the link to the destination IPv6 addresses. This continuous ping
detection function is controlled by the CONTPING parameter in the PING6
command. Users can press CTRL+Q on the keyboard or run the STP PATHCHK
command to stop continuous ping detection.
ICMPv6 ping can be used to send packets with the destination IPv6 address being
a link-local address or a global unicast address to check whether the peer end is
reachable.
● If the destination IPv6 address is a link-local address, specify the destination
IPv6 address and local outbound interface index.
● If the destination IPv6 address is a global unicast address, specify the source
IPv6 address and destination IPv6 address.
8.3 Trace Route

The IPv6 trace route functions include route reachability detection and DSCP
change detection.

(2021-12-30)
SingleRAN
NOTE
IPv6 trace route can be used only when the transport network supports response to the
ICMPv6 timeout messages and destination unreachable messages and the firewall on the
transport network does not filter out UDP packets used by IPv6 trace route and ICMPv6
packets.
8.3.1 Route Reachability Detection

Trace route IPv6 packets pass through all routers on the path. If a router is faulty,
no ICMPv6 response packet will be returned. The transmit end then knows which
hop is not reachable.
Each router decreases the Hop Limit value of an IPv6 packet by 1 when routing
the packet. A router will discard a packet and notify the source node if it finds out
that the value of this field in the packet is 0. IPv6 trace route sends a UDP
detection packet. The initial value of Hop Limit is 1. After an ICMPv6 response
packet is received, Hop Limit is increased to 2. The value of Hop Limit can be
gradually increased to learn the IPv6 address and connectivity of each hop on the
path. The maximum value of Hop Limit is specified by the MAXHOPLIMIT
parameter.
8.3.2 DSCP Change Detection

The process of DSCP change detection is as follows:
● A base station sends an IPv6 trace route packet with the initial value of Hop
Limit being 1. Each time the IPv6 packet passes through a router, the Hop
Limit value of this packet decreases by 1. When the value of Hop Limit
decreases to 0, the router discards the IPv6 packet and sends an ICMPv6 Time
Exceeded Message that contains the header of the received IPv6 packet to
notify the transmit end that Hop Limit expires. The base station can learn the
DSCP value of the packet received by the router based on the packet returned
by the router and print the DSCP value.
● The base station gradually increases the Hop Limit value and prints the DSCP
values received by the router hop by hop.
● By checking for inconsistencies in all received DSCP values, users can learn
whether the DSCP value has been changed, and if so, which router has
changed the DSCP value.
To enable DSCP change detection, run the TRACERT6 command with
PATHDSCPSW set to ON on the base station side.
8.4 GTP-U Echo

GTP-U echo for the eNodeB and gNodeB is classified into static GTP-U echo and
dynamic GTP-U echo.
● When enabled, static GTP-U echo is performed regardless of whether there
are services. In endpoint configuration mode, the base station reports
ALM-25954 User Plane Fault after detecting a fault, and reports the fault to
the service layer.
In endpoint configuration mode, static GTP-U echo has a global switch, a link-
level switch, and an endpoint group switch.

(2021-12-30)
SingleRAN
– The global switch is configured using the GTPU.STATICCHK (5G gNodeB,

LTE eNodeB) parameter.
– The endpoint group switch is configured using the EPGROUP.STATICCHK
(5G gNodeB, LTE eNodeB) parameter.
– The link-level switch is configured using the
USERPLANEPEER.STATICCHK (5G gNodeB, LTE eNodeB) parameter.
When GEPMODELPARA.STATICCHKMODE (5G gNodeB, LTE eNodeB) is
set to UPPEERSTATICCHK and USERPLANEPEER.STATICCHK is not set to
FOLLOW_GLOBAL, the link detection setting takes precedence over the
global switch setting. When USERPLANEPEER.STATICCH is set to
FOLLOW_GLOBAL, the global switch setting takes precedence over the
link-level switch setting. By default, the link-level switch setting is the
same as the global switch setting.
When GEPMODELPARA.STATICCHKMODE (5G gNodeB, LTE eNodeB) is
set to EPSTATICCHK, the endpoint group switch setting is used. The
endpoint group switch is turned off by default.
NOTE
● If the USERPLANEPEER MO has been configured, the system automatically updates the
configuration of this MO when static GTP-U echo is enabled, without changing the
value of the USERPLANEPEER.STATICCHK (5G gNodeB, LTE eNodeB) parameter.
● ALM-25954 User Plane Fault of the major severity is reported when the total number of
user-plane path faults is greater than or equal to 16 for the same service type.
ALM-25954 User Plane Fault of the critical severity is reported when all user-plane paths
corresponding to the S1/NG interface are faulty.
● In the simplified endpoint mode, as the EPGROUP MO cannot be manually configured,
static GTP-U echo does not support the endpoint group configuration mode.
● Dynamic GTP-U echo takes effect only when there are services and static
GTP-U echo is disabled. When a fault occurs, dynamic GTP-U echo does not
report ALM-25954 User Plane Fault (in endpoint configuration mode) but
only reports the fault to the service layer.
It is recommended that static GTP-U echo be enabled. This prevents UEs from
being released without any prompt information when a transmission link becomes
faulty. Users can specify the timeout duration of echo frames using
GTPU.TIMEOUTTH (5G gNodeB, LTE eNodeB) and the number of echo frame
timeouts using GTPU.TIMEOUTCNT (5G gNodeB, LTE eNodeB). The two
parameters are globally configured and cannot be set to different values for single
links.
In endpoint configuration mode, GTP-U echo uses the IP addresses of the
USERPLANEHOST and USERPLANEPEER MOs in the same EPGROUP MO as the
source and destination IP addresses, respectively. In this case, the DSCP values of
GTP-U control packets are globally configured.
NOTE
In base station IPv6 transmission, only the endpoint configuration mode is supported.
8.5 LLDP
Link Layer Discovery Protocol (LLDP) is a Layer 2 discovery protocol defined in the
IEEE 802.1ab standard. It allows network devices to advertise local information in

(2021-12-30)
SingleRAN
the local subnet, including the system name, system description, port ID, and MAC
address. An OSS can use LLDP to quickly obtain the Layer 2 network topology
information and topology changes of the base station and to further obtain the
topology relationship between the base station and the peer device. With this
information, transmission faults can be quickly located.
The base station supports manual and automatic LLDP configurations. The LLDP
configuration mode can be specified by setting LLDPGLOBAL.PORTCFGMODE
(LTE eNodeB, 5G gNodeB) to MANUAL or AUTO.
● Manual LLDP configuration
Users can run the ADD LLDP command to add the local end information of
an LLDP port.
– If the peer device is configured with a VLAN, the LLDP.BNDVLAN (LTE
eNodeB, 5G gNodeB) parameter that specifies the VLAN bound to the
LLDP local port must be set to YES. The LLDP.VLANID (LTE eNodeB, 5G
gNodeB) parameter that specifies the VLAN ID and the LLDP.VLANPRI
(LTE eNodeB, 5G gNodeB) parameter that specifies the VLAN priority
must be set based on the configuration on the peer device.
– If the peer device is not configured with a VLAN, LLDP.BNDVLAN (LTE
eNodeB, 5G gNodeB) must be set to NO.
● Automatic LLDP configuration
The base station automatically configures LLDP port information based on the
configured Ethernet port. The automatically configured LLDP port is not
bound to any VLAN.
The SET LLDPGLOBALINFO command is used to set the LLDP global
configuration information, including the interval for transmitting LLDP packets
(LLDPGLOBAL.TXINTVAL (LTE eNodeB, 5G gNodeB)), LLDP TTL multiplier
(LLDPGLOBAL.HOLDMULTI (LTE eNodeB, 5G gNodeB)), reinitialization delay
(LLDPGLOBAL.REINITDELAY (LTE eNodeB, 5G gNodeB)), and LLDP packet
transmission delay (LLDPGLOBAL.DELAY (LTE eNodeB, 5G gNodeB)).
8.6 BFD
BFD is a type of high-speed independent Hello protocol and supports link fault
detection in the millisecond range.
After a fault is detected, fault isolation can be triggered by association with upper-
layer protocols, reducing service loss and improving system reliability.
BFD is classified into single-hop BFD (SBFD) and multi-hop BFD (MBFD).
SBFD applies to end-to-end direct connections in Layer 2 networking.
MBFD applies to end-to-end indirect connections in Layer 3 networking. Multiple
intermediate nodes can exist between the two ends of an MBFD session.
8.6.1 Detection Mechanism

BFD requires the setup of a BFD session with which the BFD detects the
connection between two ends.
A BFD end plays either an active role or a passive role during session initialization.

(2021-12-30)
SingleRAN
● A BFD end playing the active role can send BFD control packets for a
particular session, regardless of whether it has received any BFD packets for
that session.
● A BFD end playing the passive role can start sending BFD control packets for
a particular session only after it receives a BFD packet for that session.
A BFD session can be established only when at least one of the devices at both
ends plays the active role. The base station always plays the active role in BFD.
BFD uses BFD messages as heartbeat messages. If a BFD end transmits several
BFD messages over a link but does not receive any response messages, it considers
the link faulty.
Figure 8-1 illustrates BFD messages exchanged when a link is disconnected.
Figure 8-1 BFD message exchange when the link is disconnected
In asynchronous BFD mode, both BFD ends periodically send BFD control packets
to each other. If the BFD control packets are received within the detection time
shown in Figure 8-1, the session is considered UP. If BFD control packets are not
received within the detection time, the BFD session is considered DOWN.
The interval for transmitting BFD control packets is proportional to Max(Minimum

transmit interval, Minimum receive interval). The proportion is determined by the
detection multiplier. The detection time can be calculated at the BFD transmit end
by using the following formula: Detection time = Detection multiplier of the
transmit end x Max(Minimum transmit interval, Minimum receive interval)
8.6.2 Configuration Requirements

The requirements for configuring the BFD function are as follows:
● Both ends of a BFD session must support BFD.

● BFD must be started on both ends of a BFD session, and the detection time
must be equal or nearly equal.

(2021-12-30)
SingleRAN
● SBFD requires a physical port on the end that sends BFD control packets to be
bound to the source and destination IP addresses of a connection to which
the SBFD applies.
● MBFD requires the source IP address to be bound to the destination IP
address of a connection at the end that sends BFD control packets.
Either device IP addresses or interface IP addresses of an interface board can
be used as the local IP address of an MBFD session. The peer IP address
cannot be on the same segment as any of the local IP addresses.
The link-local address cannot be used as the source or destination IP address
of a BFD session.
● Detection results can be linked with upper-layer protocols.
If BFD is linked with upper-layer protocols and a fault is detected, the active
and standby ports can be switched and the route with the detection IP
address of the BFD session as the next- hop IP address will be removed.
● BFD in asynchronous mode is supported and BFD in demand mode is not
supported.
If BFD control packets are transmitted in plaintext, security risks such as bogus
packets and replay attacks exist. Therefore, BFD authentication is introduced to
support SBFD on base stations and base station controllers.
NOTE
BFD authentication complies with the RFC5880 protocol. The protocol version for BFD
sessions must be standard and cannot be Draft 4.
● To enable BFD authentication for a base station, ensure that the peer router
also supports BFD authentication. If the peer router does not, the
authentication will fail.
● After BFD authentication is enabled, the number of configured keys and key
values must be consistent between the local and peer ends. Otherwise, the
authentication will fail.
Parameter configuration on the base station side:

● BFD.HT (5G gNodeB, LTE eNodeB): used to configure the BFD hop type.
● BFD.DM (5G gNodeB, LTE eNodeB): used to configure the detection
multiplier of a BFD session.
● BFD.MINTI (5G gNodeB, LTE eNodeB): used to configure the effective
minimum transmit interval.
● BFD.MINRI (5G gNodeB, LTE eNodeB): used to configure the effective
minimum receive interval.
● BFD.CATLOG (5G gNodeB, LTE eNodeB): used to configure whether to allow
port switchovers.
8.6.3 Binding Relationship Between SBFD and IP Route

In the current version, only SBFD sessions can be bound to IP routes. To implement
SBFD, an SBFD session must be bound to an IPROUTE6/SRCIPROUTE6 MO.
After BFD authentication is enabled on a base station, associated route switchover

is performed after BFD. Once BFD authentication fails or a link fault occurs, link

(2021-12-30)
SingleRAN
switchover is triggered. The switchover procedure is the same as that after the
existing BFD.
The parameters used to configure a binding relationship between an SBFD session
and an IP route on the base station side are as follows:
● On the base station side, the BFD.CATLOG (5G gNodeB, LTE eNodeB) (in the
new model) parameter is used:
– When this parameter is set to RELIABILITY:
If an SBFD session detects a fault, the base station will automatically
isolate the route with the peer IP address as the next-hop address.
If active and standby routes have been configured, a route switchover will
be performed after the fault is detected. After the faulty route is restored,
a route switchback will take place when the time specified by
GTRANSPARA.SBTIME (5G gNodeB, LTE eNodeB) elapses.
– When this parameter is set to MAINTENANCE:
If an SBFD session detects a fault, the base station will not automatically
isolate the route with the peer IP address as the next-hop address.
A route switchover will not occur even if active and standby routes have
been configured.

(2021-12-30)
SingleRAN
IPv6 Transmission Feature Parameter Description 9 Engineering Guidelines
9 Engineering Guidelines
● For details about eRAN IPv6 transmission, see IP eRAN Engineering Guide in
eRAN Feature Documentation.
● For details about NR IPv6 transmission, see IP NR Engineering Guide in NR
Feature Documentation.

(2021-12-30)
SingleRAN
IPv6 Transmission Feature Parameter Description 10 Reference Documents
10 Reference Documents
● 3GPP TS 29.281, "General Packet Radio System (GPRS) Tunnelling Protocol

User Plane (GTPv1-U)"
● IP Performance Monitor
● Ethernet OAM
● IP Active Performance Measurement
● Common Transmission
● SRAN Networking and Evolution Overview
● IPv4 Transmission
● IPsec
● X2 and S1 Self-Management in NSA Networking
● Feature parameter description documents in eRAN Feature Documentation:
– Transmission Resource Management
– Synchronization
– IP eRAN Engineering Guide
– eX2 Self-Management
– S1 and X2 Self-Management
● Feature parameter description documents in 5G RAN Feature Documentation:
– Transmission Resource Management
– Synchronization
– eXn Self-Management
– NG and Xn Self-Management
– IP NR Engineering Guide

(2021-12-30)

IPv6 Transmission (SRAN18.1 - Draft A)

Uploaded by

Copyright:

Available Formats

IPv6 Transmission (SRAN18.1 - Draft A)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IPv6 Transmission (SRAN18.1 - Draft A)

Uploaded by

Copyright:

Available Formats

SingleRAN

IPv6 Transmission Feature

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue Draft A Copyright © Huawei Technologies Co., Ltd. i

2 About This Document.............................................................................................................3

3 IPv6 Transmission Basic Configuration...............................................................................6

4 Transmission Protocol Stacks................................................................................................8

Issue Draft A Copyright © Huawei Technologies Co., Ltd. ii

4.4.3.6 Router Discovery............................................................................................................................................................ 33

5 IPv6 Transmission Networking for Interfaces.................................................................48

6 IPv4/IPv6 Dual-Stack Networking for Interfaces...........................................................58

8 Transmission Maintenance and Detection...................................................................... 82

Issue Draft A Copyright © Huawei Technologies Co., Ltd. iii

Issue Draft A Copyright © Huawei Technologies Co., Ltd. iv

This chapter describes changes not included in the "Parameters", "Counters",

1.1 SRAN18.1 Draft A (2021-12-30)

Deleted descriptions of None ● 3900 and 5900

Added support for TEID-based Added the ● 3900 and 5900

Issue Draft A Copyright © Huawei Technologies Co., Ltd. 1

Change Description Parameter Change Base Station

Optimized the alarm reporting Modified the ● 3900 and 5900

Added support for OM channel None ● 3900 and 5900

Issue Draft A Copyright © Huawei Technologies Co., Ltd. 2

2 About This Document

2.1 General Statements

● The technical principles of features and their related parameters

2.2 Applicable RAT

Issue Draft A Copyright © Huawei Technologies Co., Ltd. 3

2.3 Features in This Document

RAT Feature ID Feature Name Chapter/Section

NR FOFD-021212 IPv6 3 IPv6 Transmission

LTE TDD TDLBFD-003003 VLAN Support (IEEE 4.3.3 VLAN

LTE FDD LBFD-003003 VLAN Support (IEEE 4.3.3 VLAN

NB-IoT MLBFD-1200030 VLAN Support (IEEE 4.3.3 VLAN

NR FBFD-010019 VLAN Support 4.3.3 VLAN

LTE FDD LOFD-003017 S1 and X2 over IPv6 4.6 IPv6 Transport

LTE TDD TDLOFD-003017 S1 and X2 over IPv6 4.6 IPv6 Transport

NB-IoT MLOFD-003017 S1 over IPv6 4.6 IPv6 Transport

LTE FDD LBFD-003006 IPv4/IPv6 Dual Stack 6 IPv4/IPv6 Dual-Stack

LTE TDD TDLBFD-003006 IPv4/IPv6 Dual Stack 6 IPv4/IPv6 Dual-Stack

NB-IoT MLBFD-1200030 IPv4/IPv6 Dual Stack 6 IPv4/IPv6 Dual-Stack

NR FBFD-021101 IPv4/IPv6 Dual Stack 6 IPv4/IPv6 Dual-Stack

LTE FDD LBFD-00202103 SCTP Multi-homing 7.2 Control-Plane SCTP

LTE TDD TDLBFD-0020210 SCTP Multi-homing 7.2 Control-Plane SCTP

Issue Draft A Copyright © Huawei Technologies Co., Ltd. 4

RAT Feature ID Feature Name Chapter/Section

NB-IoT MLBFD-1200041 SCTP Multi-homing 7.2 Control-Plane SCTP

Issue Draft A Copyright © Huawei Technologies Co., Ltd. 5

3 IPv6 Transmission Basic Configuration

3.1 IPv6 Transmission Interfaces

3.2 Transmission Configuration Model

The transmission configuration models of different RATs in a co-MPT multimode

Issue Draft A Copyright © Huawei Technologies Co., Ltd. 6

Issue Draft A Copyright © Huawei Technologies Co., Ltd. 7

4 Transmission Protocol Stacks

4.2 Physical Layer

4.3 Data Link Layer