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.

Scope
The purpose of this document is to provide further explanation on AFs 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.

Revision History
Revision PA1 Date 12/12/2007 Updated by Garry Cayzer Description First draft

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.

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

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 Number of External ports

1

ET-MFX12 7 1 6 9000

ET-MFX13 7 6 1 9000

7 1 6 5000

Number of Optical ports (SFPs) Number of Electrical interfaces Number of simultaneous UDP sessions supported

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

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 interconnected with each other using external cables. Figure 2 shows an example of how this may be done for a Type F RNC.
ES2 ES5

ES1

ES4

MS

ES3

Titan S witch #1

Titan S witc h #2

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.

Node B MS
SiteLAN

VLAN 100 & 900

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

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. 2. 3.

The relative priority of each switch in the network The relative priority of each port in a switch 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.
ES2 ES5

ES1

ES4

MS

ES3

VLAN 100

VLAN 100 VLAN 100

Titan S witc h #1

Titan S witch #2

Root Switch

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.

Node B MS
SiteLAN

VLAN 100 & 900

Titan Switch#1 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)

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 Telstras Type F RNC is 768 The IP Subnet allocated to VLAN 100 between one RNC and 768 Node Bs 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. .

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.

ES2

ES5

ES1

ES4

Node B MS
SiteLAN

MS

ES3

VLAN 100

VLAN 100 VLAN 100

Default route

Titan S witch #1

Titan Sw itch #2

Default route

Layer 2 network

HSRP

HSRP

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.
Node B MS
SiteLAN

Static route to SiteLAN

Titan S w itch #1

Default Gateway

Layer 2 network

HSRP

OpNet

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 SRB CS conversational CS, PS, HS streaming PS interactive/background HSDPA and A-DCH Common channels

DSCP default value 18 18 18 0 0 0

Comment Configurable in RNC

Configurable in RNC. It is recommended to set this to at least equal priority with SRB and CS conversational Configurable in RNC and RBS Configurable in WCDMA RAN nodes and O&M nodes Hard-coded value

Signalling O&M Synchronisation

0 0 46

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 0, 48, 56 10, 12, 14 Spare 18, 20, 22 26, 28, 30 34, 36, 38 46 Not used

Pbit 0 1 2 3 4 5 6 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 0 1 2 3 4 5 6 7

Queue 0 0 1 1 2 2 3 3

Table 4: Recommended Pbit to Queue mapping

11.3

Delay Requirements
The following are suggested values.

Traffic Real Time HS Non HS BE

Maximum delay 30 ms ( 5 ms) 100 ms ( 10 ms) 50 ms ( 10 ms)

Max Delay Variation 10 ms 12 ms

Maximum Packet Loss 10-6 10-4 (10-6) 10-4 (10-6)

Table 5: Delay requirements

12

IP Transport Dimensioning
The following sections list the capacity requirements for different traffic types in AFs 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 .

Common Channel RACH FACH1 FACH2 PCH

Downlink

Uplink 78.4

38.0 39.2 40.4

0.5 0.5 0.5

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 RRC (MCCH 7.6) MTCH 64 kbps MTCH 128 kbps MTCH 256 kbps

Downlink 29.2 71.7 138.1 276.2

Uplink 0.5 0.5 0.5 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.

Dedicated Channel AMR 12.2 kbps

Downlink 18.8

Uplink 19.2

AMR 7.95 kbps AMR 5.9 kbps AMR 4.75 kbps AMR WB CS 64 CS 57 PS 64/64 PS 64/128 PS 64/384 PS 128/64 PS 128/128 PS 128/384 PS 384/64 PS 384/128 PS 384/384 PS 16/64 PS 16/128 PS 128/16 A-DCH 64 kbps A-DCH 384 kbps SRB

16.6 15.4 15.0 19.1 84.8 68 66.0 116.40 333.63 65.7 116.1 333.0 65.72 116.1 333.0 76.0 113.1 26.4 N.A N.A 2.8

17.0 15.8 15.4 19.5 85.6 68.4 66.6 66.6 66.6 116.7 116.7 116.7 334.2 334.2 334.2 38.4 28.0 113.6 87.6 334.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 ICMP IP NBAP PCH RAB RAN RACH RB RBS RNC RNS RSTP RTP UDP WCDMA WFQ Address Resolution Protocol Internet Control Message Protocol Internet Protocol Node B Application Protocol Paging Channel Radio Access Bearer Radio Access Network Random Access Channel Radio Bearer Radio Base Station Radio Network Controller Radio Network System Rapid Spanning Tree Protocol Real-time Transport Protocol User Datagram Protocol Wideband Code Division Multiple Access Weighted Fair Queuing