Iub over IP - Solution Overview

1 Introduction

This document provides an architectural design of an Iub over IP solution that may be used within the Telstra network. This document also covers product specification for the Node Bs and RNCs that were considered in arriving at this design.

2 Scope

The purpose of this document is to provide further explanation on AF’s standard Iub over IP configuration. In particular:

It captures an example of a possible end to end Iub over IP architecture based on a Layer 3 transport network.

3 Revision History

Revision Date Updated by Description

PA1 12/12/2007 Garry Cayzer First draft

4 Iub over IP Overview

The Iub interface is the interface between RNC and Node B. As part of the P6 software releases on the RNC and NodeBs, it is now possible that the Iub interface be transported over IP. This document covers a possible Iub over IP architecture solution that maybe considered for implementation into the Telstra network.

The Iub interface is made up of the Radio Network Layer and the Transport Network Layer as depicted in Figure 1. The Radio Network Layer carries:

Control Plane (network Signalling)

Network Synchronization traffic

User Plane (User traffic)

Each of these traffic types is carried over an IP network.

Figure 1: Iub over IP protocol stack

Operations & Maintenance traffic to the NodeB can also be carried over an IP network.

4.1 Control Plane

The Radio Network protocol for the control plane is called Node B Application Protocol (NBAP) and transports Radio Network control plane messages between the Node B and the RNC. NBAP is carried over SCTP.

4.2 User Plane

The RNC and the Node B support UDP over IP to transport the Radio Network Frame Protocols. The Radio Network User plane uses several frame protocols: FACH FP, RACH FP, PCH FP, DCH FP and HS-DSCH FP.

4.3 Synchronisation

Network Synchronisation is achieved using NTP. The Node B is configured as an NTP Client and the RNC is configured as an NTP Server.

5 Transport Network Design

The following sections cover the general design that Telstra may wish to use to integrate the Iub over IP interface into their network. Product specifications of the RNCs and Node Bs have been captured, so that this may assist Telstra in making any variations to this design they see fit in the future.

The following assumptions were used in putting this design together:

O&M traffic to the RNCs will remain via the present dedicated O&M ports terminating on the GPB interfaces.

The ET-MFX12 & 13 interfaces are capable of terminating 500Mbps of Iub traffic

The Type F, RNC is presently capable of terminating 800Mbps of Iub traffic

The following sections cover the Physical Layer, Logical Layer, IP Layer and Routing Layer of the Network design

6 Physical Layer

The Physical layer will be explained in two components, as follows:

RNC

Node B

There are a number of Ethernet interface hardware options available to support the Iub over IP feature on the RNCs, as follow:

ET-MFX12

ET-MFX13

The following Ethernet interfaces is available for the Node B:

ET-MFX11

All these hardware options provide multiport non-blocking Ethernet Switching with IP termination and inter-working functionality

The IP termination functionality on the switch can be used to terminate the various Network Layer protocols outlined in Section 4 on the RNC and Node B.

The inter-working functionality of the switches can be used to provide connectivity between all the ET-MFX interfaces and any external IP network.

Table 1, captures the physical capabilities of the different ET-MFX interfaces.

ET-MFX11 ET-MFX12 ET-MFX13

Number of External ports 1

7 7 7

Number of Optical ports (SFPs)

1 1 6

Number of Electrical interfaces

6 6 1

Number of simultaneous UDP sessions supported

5000 9000 9000

Table 1 - ET-MFX interface Physical capabilities

Electrical Interface

For the Electrical interfaces it is possible to auto negotiate or manually configure the speed and duplex on the interfaces

Optical Interface

The Optical SFPs available for the ET-MFX cards are as follows:

1000BaseSX

1000BaseLX/LX10

1000BaseLX40

1000BaseZX

Auto negotiation must be enabled for SFP ports and when port speed and duplex settings are configured as 1000_MB_Full or 1000_MB_Half.

6.1 RNC

The RNC is made up of a number of Sub Racks, namely the Main Sub rack (MS) and numerous Extension Sub Racks (ES). The number of ES depends on the size of the RNC installed. Telstra presently has Type F RNC, that consists of one Main sub rack and five Extension Sub racks.

The RNC supports the following Iub over IP Ethernet interfaces:

ET-MFX12

1 A logical internal port also exists on each of the ET-MFX cards. This interface is used to terminate IP traffic on the RNC

ET-MFX13.

The LX40 and ZX SPF variations are presently being ordered for Model testing.

In order for every IP host to be reachable, each ET-MFX must be inter-connected with each other using external cables. Figure 2 shows an example of how this may be done for a Type F RNC.

Figure 2: Cabling of ET-MFX interfaces for an RNC Type F

6.2 Node B

The Node B has the one Sub Racks and only has the one ET-MFX11 interface installed. The Node B will connect back to the Titan Network via the optical or Electrical interface as shown in Figure 3

The LX40 and ZX SPF variations are presently being ordered for Model testing.

Figure 3: Cabling of ET-MFXs for a Node B

7 Logical Layer

The following section contains the Logical network connections on the RNC and Node Bs. These sections cover the recommended VLAN and Spanning Tree Protocol configuration for the Telstra network.

All ET-MFX interfaces support up to:

256 VLANs per interface

8 terminated VLANs per interface

VLAN numbering range between 2 and 4096

Rapid Spanning Tree Protocol in accordance to IEEE 802.1D-2004 clause 17 is supported on the ET-MFX interfaces.

7.1 RNC

The following captures the VLAN and Spanning Tree Protocol recommendations on the RNC

7.1.1 VLANs

The proposed solution only needs the one VLAN to be configured on the RNC. This will be the default of VLAN 100 and used to carry all the Radio Network Layer protocols between the RNC and Node B

7.1.2 Spanning Tree Protocol

Rapid Spanning Tree Protocol (RSTP) is to be enabled on all the RNC interfaces to avoid any layer 2 loops

The RSTP instance configured on the RNC is recommended be terminated on the Titan Switches that directly connect to the RNC and to be isolated from any other Spanning Tree instances within the network.

The Spanning Tree algorithm calculates the best loop-free path through out a switched Layer 2 network by sending and receiving Bridge Protocol Data Units (BPDUs) at regular intervals. The BPDUs exchange information about other switches in the network. By changing some of BPDU parameters, it is possible to influence the RSTP algothirm into selecting the interfaces that will be placed into blocking mode when a Layer 2 loop is detected. This can be used to ensure that dual links to the Titan Switches have the lowest probability of been placed in blocking mode, hence providing multiple active links to and from the RNC.

The exchange of the BPDUs results in the:

Election of a unique root switch for each spanning-tree instance.

Election of a designated switch for every switched LAN segment.

Removal of loops in the switched network by blocking Layer 2 interfaces connected to redundant links

The root switch is the logical centre of the spanning-tree topology in a switched network. All paths that are not needed to reach the root switch from anywhere in the switched network are placed in the spanning-tree blocking mode.

The RSTP provides rapid convergence of the spanning tree by assigning port roles and by determining the active topology. One of the following port roles is assigned to individual ports:

Root port : it is the port that receives the best BPDU on a bridge, so it is the port that is the closest to the root bridge in terms of path cost. The root bridge is the only bridge in the network that does not have a root port. All other bridges receive BPDUs on at least one port.

Designated port : a port is designated if it can send the best BPDU on the segment to which it is connected. On a given segment, there can only be one path toward the root bridge.

Alternate port : it offers an alternate path toward the root switch. It receives more useful BPDUs from another bridge and is a port blocked.

Backup port : it acts as a backup for the path provided by a designated port. It receives more useful BPDUs from the same bridge it is on and is a port blocked. A backup port can exist only when two ports are connected together in a loopback by a point-to-point link or when a switch has two or more connections to a shared LAN segment.

Edge port : it has no role within the operation of the spanning tree.

A port with the root or a designated port role is included in the active topology. A port with the alternate or backup port role is excluded from the active topology.

RSTP parameter can be changed to help manage the active topology of the network. In particular, three attributes should be properly configured.

1. The relative priority of each switch in the network

2. The relative priority of each port in a switch

3. The port path cost for each port in a switch

In order to define an optimal RSTP topology, the proposal is to configure Titan switch #1 as “Root Switch and if this switch fails then Titan Swith#2 to become the Root Switch. The following Bridge Priorities are required to be configured on the relevant switches to achieve this:

RNC ET-MFX board – Bridge Priority 8192

Titan Switch#1 – Bridge Priority 32768

Titan Switch#2 – Bridge Priority 16384

It is strongly recommended to set the same port priority and path cost in all ports of a switch participating in RSTP. In this way the active topology is determined by the distance to the root switch.

Recommended configurations are as follow:

Port Priority = 128

Path Cost=20000 (1 Gbps)

In the ET-MFX board, when all ports have the same priority and all paths have the same cost the switch port “A” (physically located at the bottom of the board) has the lowest switch port number and RSTP therefore considers this port as the best choice.

Figure 4 shows the active Layer 2 topology under normal conditions. As shown the connections between the ET-MFX interfaces on the same RNC sub rack are placed in blocking mode.

Figure 4 - RSTP active topology for the RNC

7.2 Node B

The following captures the VLAN and Spanning Tree Protocol recommendations on the Node B.

7.2.1 VLANs

The proposed solution will need two VLAN to be configured on the Node B as follows:

VLAN 100 to carry all the Radio Network Layer protocols between the RNC and parented Node Bs.

VLAN 900 to carry all Operation and Maintenance between the Node Bs and OpNet.

Figure 5 – VLAN configuration on the Node B

7.2.2 Spanning Tree

There are no Layer two loops within the recommended physical layer architecture for the Node B, hence no need to enable Rapid Spanning Tree Protocol (RSTP)

8 IP Layer

The following section will cover the IP addressing requirements and recommendations for the network. This will be described on a per VLAN basis.

8.1 Radio Network Layer

VLAN 100 is used to carry the Radio Network Layer.

The largest RNC needs the following number of IP Addresses to be allocated:

16 IP Addresses for User Plane. This is one IP address per ET-MFX interface.

66 IP Addresses for Control Plane. The Control Plane IP addresses are configured on the RNC General Processor Board (GBP) and logically linked internally on the RNC to an ET-MFX interface

The Node B requires the following number of IP addresses to be allocated:

1 IP Address for the User Plane

1 IP Address for the Control Plane.

The maximum number of the NodeBs presently support on Telstra’s Type F RNC is 768

The IP Subnet allocated to VLAN 100 between one RNC and 768 Node B’s must be large enough to support up to 82 RNC IP addresses and 2 x the maximum number of support Node Bs

8.2 Operation and Maintenance

VLAN 900 is used to carry O&M traffic between the Node B and OpNet. One IP Address is required on each Node B, and three IP Address required on the dual OpNet Routers to be configured for HSRP. .

9 Routing Layer

The routing layer will once again be explained per configured VLAN. The Routing options available on the RNC and Node Bs are as follows:

Configuration of a Default Gateway.

Router Path Supervision (RPS). RPS allows the RNC or Node B to monitor up to three default routers. The supervision is preformed via ICMP echo requests/reply being sent from the Node B to the three possible default gateways. If the primary default gateway does not responding to an ICMP echo request, it is considered unreachable and the next available default gateway in the list selected as the default gateway and so on, until the primary gateway becomes active.

9.1 Radio Network Layer

The routers being used within the Telstra network will most likely be Cisco. Hot Standby Routing Protocol (HSRP) is recommended to be configured on the dual site routers.

The RNC and Node Bs will configured with default gateways to point towards the relevant HSRP IP address on the routers as shown in Figure 6. HSRP to be configured with interfaces tracking as a parameter to decide which routers is to be the active or standby.

Figure 6 – Radio Network Layer routing design

9.2 Operations and Maintenance

Routing is required for the O&M VLAN. HSRP is recommended to be configured between the dual OpNet Routers. The Node B will be configured with the HSRP IP address as its default Gateway as shown in Figure 7

The Node B has a SiteLAN network that is used to manage the Node Bs. The Node B, SiteLAN also connects to other IP devices that must be reachable from OpNet. The Dual OpNet routers are to be configured with a static route to each Node Bs SiteLAN IP subnetwork to go via the relevant VLAN 900 IP Address as its next hop.

Figure 7 – O&M network routing design

10 Synchronisation

The ET-MFX can be configured as an NTP Server or NTP Client. The RNC is configured as a server and the RBS is configured as the client.

The Server in the ET-MFX board (RNC) and the Client (Node B) communicate using NTP over UDP which runs on the same IP subnet/VLAN as the Iub user/control plane traffic.

Even though one ET-MFX in the RNC is capable of handling all Node Bs, even in the largest configuration, it is recommended to enable the Server capabilities in all ET-MFXs so that load is evenly distributed.

11 QoS

QoS separation in IP RAN networks is achieved using DiffServ marking. DiffServ mapping to Ethernet quality bits according to 802.1p specifications is also used.

11.1 DiffServ marking

The default DSCP values for each RAB are shown in Table 2.

RAB/RB DSCP default value

Comment

SRB 18 Configurable in RNC

CS conversational 18

CS, PS, HS streaming 18

PS interactive/background 0

HSDPA and A-DCH 0

Common channels 0 Configurable in RNC. It is recommended to set this to at least equal priority with SRB and CS conversational

Signalling 0 Configurable in RNC and RBS

O&M 0 Configurable in WCDMA RAN nodes and O&M nodes

Synchronisation 46 Hard-coded value

Table 2: Default DSCP values

11.2 P bit

The mapping of DSCP values to P bit is configurable. The default mappings are shown in Table 3.

DSCP Pbit

0, 48, 56 0

10, 12, 14 1

Spare 2

18, 20, 22 3

26, 28, 30 4

34, 36, 38 5

46 6

Not used 7

Table 3: Default DSCP to Pbit mapping

The Pbit can be mapped to the internal queues for each Ethernet port in the ET-MFX. There are four queues per Ethernet port.

Pbit Queue

0 0

1 0

2 1

3 1

4 2

5 2

6 3

7 3

Table 4: Recommended Pbit to Queue mapping

11.3 Delay Requirements

The following are suggested values.

Traffic Maximum delayMax Delay Variation

Maximum Packet Loss

Real Time 30 ms ( 5 ms) 10 ms 10-6

HS 100 ms ( 10 ms)

- 10-4 (10-6)

Non HS BE 50 ms ( 10 ms) 12 ms 10-4 (10-6)

Table 5: Delay requirements

12 IP Transport Dimensioning

The following sections list the capacity requirements for different traffic types in AF’s IP RAN.

12.1 Network Synchronisation

The capacity requirement for network synchronisation is negligible but it should be given the highest priority. The frequency of NTP requests is assumed to be in the range of 1 to 10 per second.

12.2 Common Channels

The common channels capacity (including node synchronisation) is detailed in .

Table 6: Common channel average capacity requirements (kbps)

12.3 MBMS

An MBMS streaming connection (FACH for MTCH PS Streaming) per broadcast channel per cell is needed (even if there is no users in the cell). A single MBMS RRC connection per cell (MCCH 7.6 kbps) is needed if there is MBMS streaming in the cell.

Common Channel

Downlink Uplink

RRC (MCCH 7.6) 29.2 0.5

MTCH 64 kbps 71.7 0.5

MTCH 128 kbps 138.1 0.5

MTCH 256 kbps 276.2 0.5

Table 7: MBMS average capacity requirements (kbps)

12.4 Guaranteed Bit rate Services

The following table shows the average capacity requirements for dedicated channels.

Common Channel Downlink Uplink

RACH 78.4

FACH1 38.0 0.5

FACH2 39.2 0.5

PCH 40.4 0.5

Dedicated Channel

Downlink Uplink

AMR 12.2 kbps 18.8 19.2

AMR 7.95 kbps 16.6 17.0

AMR 5.9 kbps 15.4 15.8

AMR 4.75 kbps 15.0 15.4

AMR WB 19.1 19.5

CS 64 84.8 85.6

CS 57 68 68.4

PS 64/64 66.0 66.6

PS 64/128 116.40 66.6

PS 64/384 333.63 66.6

PS 128/64 65.7 116.7

PS 128/128 116.1 116.7

PS 128/384 333.0 116.7

PS 384/64 65.72 334.2

PS 384/128 116.1 334.2

PS 384/384 333.0 334.2

PS 16/64 76.0 38.4

PS 16/128 113.1 28.0

PS 128/16 26.4 113.6

A-DCH 64 kbps N.A 87.6

A-DCH 384 kbps N.A 334.8

SRB 2.8 2.9

Table 8: Dedicated Channel average capacity requirements (kbps)

12.5 NBAP Signalling

An approximate capacity increase of 10% compared to ATM is expected due to different protocol overhead. Therefore, approximately 220 kbps should be allocated to NBAP signalling.

If NBAP is carried over the same priority flow as other higher priority QoS traffic, then over dimensioning is recommended.

12.6 Mub

The average Mub capacity requirement is 58 kbps. This is slightly lower than the ATM case due to different protocol overhead.

If Mub is carried over the same priority flow as other higher priority QoS traffic, then over dimensioning is recommended.

12.7 Best Effort Traffic

Best effort traffic is dimensioned using an Elastic User Model so that remaining capacity from higher QoS traffic can be used. The average and target bit rates should be specified in the traffic model.

13 Abbreviations

ARP Address Resolution Protocol

ICMP Internet Control Message Protocol

IP Internet Protocol

NBAP Node B Application Protocol

PCH Paging Channel

RAB Radio Access Bearer

RAN Radio Access Network

RACH Random Access Channel

RB Radio Bearer

RBS Radio Base Station

RNC Radio Network Controller

RNS Radio Network System

RSTP Rapid Spanning Tree Protocol

RTP Real-time Transport Protocol

UDP User Datagram Protocol

WCDMA Wideband Code Division Multiple Access

WFQ Weighted Fair Queuing