Manufacturers
make many important decisions in selecting the appropriate platform for the
UTRAN, including how to manage the diverse protocol processing requirements
between the NodeB, RNC, and Core Network, as well as how to identify,
terminate, switch, and interwork disparate traffic types whilst not
compromising Quality of Service in the form of latency through the different
interfaces.
Both operators
and manufacturers, through standards bodies like 3GPP, are focusing on how to
leverage the benefits of ATM (Asynchronous Transfer Mode) with reduced costs
and feature enhancements concurrent with efforts to anticipate raw ‘IP
technologies’. Investigating fragmentation, segmentation, and prioritisation
schemes similar to those used in ATM will provide insight into how to
administer adequate Quality of Service in an ‘all IP’ RAN.
Every equipment manufacturer has preferred platforms they utilise in their current NodeB and RNCs. They all seek to lower costs and improve performance of their existing equipment by supporting different layer 2 protocols over transport media such as E1/T1/J1, E3/T3, and STM-1.
Many are looking to collapse different “line cards”
into one simple, flexible product development in
order to provide a way to migrate to IP today
or whenever operators are ready by simply configuring software.
The UTRAN
comprises three main interfaces to interconnect NodeB’s and Radio Network
Controllers (RNC). This architecture is
shown in Figure 1. This represents line card functions within the Media
Gateway, RNC, and NodeB. Each of these
line cards are required to handle some form of protocol processing in the
transport network, whether this be termination within the box, switching from
one interface to another of the same traffic type, or interworking different
traffic types from one interface to another. In R’99, all the traffic on the
Iub interface is required to be ATM; however, in R’4 and R’5, this traffic can
be ATM, IP, or IP frames carried over ATM using ATM Adaptation Layer 5
(AAL5). For example, the line card
highlighted ‘I’ in Figure 1 must support a number of different configurations
to meet the requirements of a 3GPP specified network. ‘I’ could be required to:
·
Terminate
ATM traffic from multiple NodeB’s either through a series of E1/T/J1 or
SDH/SONET physical interfaces;
·
Switch
ATM/AAL2 or ATM/AAL5 cells or UDP/IP traffic from E1/T1/J1 or STM-1 physical
interfaces;
Figure 1. 2/3G Component Design Requirements
In the UTRAN, the transport network is used to carry
three ‘planes’ of information: User, Control, and Management. In order to
perform service class definition and congestion control management, a series of
mechanisms have to be adopted to secure appropriate QOS. In addition, the Transport Network Iub
interface has to be engineered to support the QOS requested by the RNC for the
Radio Network. As such,
bandwidth-optimising techniques have to be adopted to allow efficient
utilisation of potentially low bandwidth links on the Iub and Iur interfaces
especially.
In R’99, ATM is
the default transmission technology and is utilised to manage QOS. A layer 2 technology, ATM contains inbuilt
techniques that allow traffic shaping. In
3GPP R’4 and R’5 specifications, IP as well as ATM can be utilised as over the
Transport Network. IP is a layer 3
technology and generally utilises much larger frame lengths. Unlike ATM, it has no inbuilt traffic shaping
techniques, and to utilise IP over the transport medium effectively, one has to
rely on additional fragmentation and segmentation techniques.
This flexibility
to adopt wide-ranging, changing standards of various bodies like the IETF and
3GPP and the ability to mix and match standards that allow NodeB and RNC
equipment to meet QOS and performance requirements are essential in the design
of 3G equipment technology.
Disparate line card
designs have traditionally been developed to accommodate either one of these
technologies. It has not been possible
to mix and match technologies and mix QOS techniques on one card. Designs have been built around either ASIC or
ASSP technology, so that the line card or the whole system had to be
re-engineered whenever a designer needed to migrate to new standards.
Figure 2. NodeB Design with Flexible, Programmable
Network Processors.
New Network
Processor (NP) silicon and associated software architectures have increased the
flexibility that can be achieved in 3G equipment line card designs. Silicon devices with interfaces like POS and
UTOPIA allow programmable selection on the TNL of either IP or ATM traffic
types through Layer 1 PHY devices. The
availability of appropriate bandwidth and new parallel processing techniques
allow tasks to be apportioned in the processors to allow power consumption and
board space constraints to be managed effectively.
As shown in Figure 2, a line card can be now be configured in at least
three different ways that meet the requirements of the latest 3GPP
specification. The silicon can be
programmed to support Options 1, 2, and 3 (ATM, IP, or IPoATM).
Figure 3 below illustrates a typical line card architecture where NP
silicon is used in this case to manage traffic from an STM-1/OC-3 rate
interface to the NodeB. The NP
classifies the traffic and determines if it is destined for a terminal controlled
by this particular NodeB. If so, the
traffic is routed over the gigabit interface to RBB and Radio Rx/Tx
circuitry. When the payload is not
destined for the particular NodeB, the Network Processor either routes the
payload back out on the STM-1 interface or routes the traffic onto E1/T1
interfaces that in turn are interfaced to additional NodeB’s.
Figure 3. Line Card
Architecture for 16 E1/T1 to OC3 Interworking (capable of handling IP and ATM
Traffic)
For PicoBTS designs, the
complexity of equipment in terms of concentration of functionality is significant since the transport interface,
control processing and aggregation to the Radio Base Band Digital Signal
Processors move from discrete board level functions and are typically all
centralised. Figure 4 illustrates the different modules that constitute BTS
designs. For PicoBTS designs the RBB and
LIU functions are collapsed from multiple cards to sometime a single device. The
benefit of using Network Processor silicon and software to reduce Bill of
Materials costing whilst maintaining flexibility is significant.
Figure
4. Base Station Architecture.
The Iub interface to
PicoBTS is typically either through 2 or 4 ATM E1/T1 carrying ATM traffic of
through an Ethernet connection through a private or metro Ethernet
connection. The processor controlling
the PicoBTS must be able to provide enough compute power for all of the
application and signalling requirements whilst being able to handle the
transport interface to extract the payload and control data from the Iub
interface and aggregate the traffic to the appropriate DSP for Symbol and chip
rate processing. With HS-DPA features now
being supported in 3G equipment it is essential that PicoBTS equipment also target
this new standard to allow the wireless operators to compete with technologies
like WiMAX. This provides equipment
manufacturers challenges on how to integrate all of these features to support
handling the Iub transport interface, application processing, aggregation and
scheduling of traffic into one piece of silicon whilst still being able to
adapt to the still changing 3GPP standards.
End-to-end
QOS to support a variety of applications has become of major importance to
operators in their roll out or 3G-equipment.
Since the perceived QOS has an impact on user perception of service, QOS
will be a differentiating factor for operators offering UMTS services. By
adopting cost optimised flexible, Network Processor based line card designs in
Micro, Macro and PicoBTS equipment, suppliers can provide operators a way to
upgrade their NodeB and RNC equipment in the field to by supporting techniques
like different configuration of ATM and IP transports on Iub interfaces and
through HSDPA scheduling at the radio interface. Network Processors allow fast
development and reconfiguration of existing equipment to support new QOS
management techniques as they become standardised. Companies like Wintegra are developing solutions
that are optimised for these types of functions. Alongside silicon devices, equipment manufacturers
can find that much of the software for not only handling of the transport
network but for functions like HSDPA MAC-HS scheduling and Frame Protocol
processing is available.