1. General Business Information
1
General Business Information
Achieving Software Compatibility in Open Interface, Multi-vendor Networks
By
Elliot M. Stewart
QA3176@email.mot.com
+1-847-632-7590
David Bielat
QA2004@email.mot.com
+1-847-632-2317
Kiran Puri
QA5504@email.mot.com
+1-847-435-9802
Beena Connors
QA1395@email.mot.com
+1-847-632-7866
GSM Software Division / Network Solutions Sector
ABSTRACT – Third generation WCDMA cellular
networks will have standardized open interfaces between
the various network elements. Each of the elements can
potentially run unaligned releases of software, due to the
multi-vendor environment, customer software rollout
strategies, or varying software product release schedules.
A mechanism has been developed that achieves
interoperability between network elements in an open
interface environment running unaligned releases of
software
KEY WORDS – Software Compatibility, Open Interface,
Capability Exchange.
1. Introduction
The Third Generation Partnership Project (3GPP) is
currently overseeing the standardization of Wideband
Code Division Multiple Access (WCDMA) cellular
networks for Universal Mobile Telecommunications
System (UMTS). One of the decisions made in 3GPP is
that open interfaces shall exist between the different
elements of the WCDMA networks. As a result, part of
the standardization effort occurring in 3GPP involves
constructing the technical specifications to support an
open interface environment within the UMTS Terrestrial
Radio Access Network (UTRAN).
The decision to have open interfaces between UTRAN
elements allows cellular network operators to interconnect
equipment from multiple vendors. The ability to construct
networks using equipment from more than one vendor has
several advantages for the operator. One advantage is
cost, as multi-vendor networks tend to cost less than
proprietary, single-vendor networks due to the pricing
pressures of multiple suppliers. Standardized interfaces
also help to ensure compatibility and seamless roaming for
mobile users. However, with open interfaces comes the
added complexity of guaranteeing the interoperability of
equipment from different vendors. This interoperability
must exist even when network elements are running
software with different functionality and capabilities.
2. Background
As required in the 3GPP standards, UTRAN elements
must support open interfaces. Figure 1 depicts the
UTRAN architecture in relation to the core network (CN)
and highlights the open interfaces [1]. Table 1 lists the
three open interfaces in the UTRAN.
The UTRAN is comprised of Radio Network Controller
(RNC) and Node B network elements. The RNC controls
several Node B sites which serve as access points to the
radio network for mobile users. The RNC connects to the
CN, which typically contains both circuit and packet
switching equipment. RNC to RNC connections exist to
support macro-diversity selection / distribution, a property
of CDMA networks.

2. General Business Information
2
General Business Information
RNC RNC
Node B Node B Node B Node B
Iu Iu
Iur
Iub IubIub Iub
Core Network
Figure 1: UTRAN Architecture
Iu [2] CN – RNC interface
Iur [3] RNC – RNC interface
Iub [4] RNC – Node B interface
Table 1: UTRAN interfaces
Open interfaces pose a technical challenge for the
elements in the UTRAN. Software applications running
at the elements exchange messages over the UTRAN
interfaces to support call processing for mobile users.
However, the software applications at each element may
not support the same capabilities or features. Thus, the
elements are said to run unaligned releases of software.
Some reasons why elements may be running unaligned
releases are:
- Certain 3GPP UTRAN functionality is not
standardized as mandatory. Therefore, the
functionality supported by elements may differ
between equipment vendors.
- Due to product release schedules, vendors may
choose to offer certain UTRAN features, but deliver
those features at different times.
- Customer rollout and upgrade strategies may create
a situation where only a subset of elements contains
the software needed to support a particular feature.
Ultimately, a mechanism is required to allow unaligned
releases of software running at UTRAN elements to
function together in an open environment.
3. Overview
This paper details how interoperability between UTRAN
elements running unaligned releases of software can be
achieved. The mechanism for obtaining interoperability is
called a capability exchange and is a part of the application
software present in each of the UTRAN elements.
The remainder of this paper is presented as follows:
- A description of the properties and workings of the
capability exchange are documented.
- Scenarios requiring the use of the capability
exchange within the UTRAN are shown.
- The benefits of using a capability exchange over
alternative methods are enumerated.
4. Description of Capability Exchange
In order for two elements on separate ends of an open
interface to successfully communicate, each element must
understand what the other element is capable of in terms of
features and functionality. Otherwise, the receiving
element may not comprehend fields in messages and / or
entire messages sent by the other element over the
interface. One way to avoid the possibility of
non-comprehension of messages or fields over the
interface is to have the elements negotiate their
capabilities. One such negotiation, called a capability
exchange, is described below.
The following points are tenets of the capability
exchange:
- Each network element must support a capability
exchange. The exchange is a negotiation of
software capabilities to be used between network
elements.
- Capability exchange messages may be sent at any
time, as part of the software mitigation process.
- A capability exchange is bi-directional meaning that
either element may initiate the exchange.
- The greatest common capability between network
elements is what is supported. Cross-network
element features are only available when both
elements on the open interface support the feature.
- If a feature or functionality is isolated to a particular
network element (i.e., it does not affect the
interface), then that functionality is not controlled
by the capability exchange.
- A capability exchange must be completed before
any new functionality is used that affects the
interface.
- A capability exchange must be executed when an
interface between elements is established.
Example message sequence diagrams for a capability
exchange are shown in Figure 2 and Figure 3. Note that
either element on the open interface may initiate the
capability exchange.
CAPABILITY INDICATION
CAPABILITY INDICATION ACK
Element 1 Element 2
Figure 2: Capability Exchange Sequence, Element 1 Initiated

3. General Business Information
3
General Business Information
CAPABILITY INDICATION
CAPABILITY INDICATION ACK
Element 1 Element 2
Figure 3: Capability Exchange Sequence, Element 2 Initiated
A CAPABILITY INDICATION message is sent from
the network element initiating the capability exchange to
the element on the other end of the link. The indication
message contains a transaction ID, a list of features and
the versions supported by each feature. Here the versions
supported map directly to releases of the 3GPP standards
(e.g., release 99, release 00, etc…).
When a network element receives a CAPABILITY
INDICATION message, it responds with a CAPABILITY
INDICATION ACK message. The acknowledgement
message contains the transaction ID from the original
indication message and the greatest common capabilities of
itself and the originating network element. A network
element uses the transaction ID to distinguish between
capability exchanges with different network elements or
with a single network element.
One possible scenario that may arise is where a
capability exchange is simultaneously initiated by both
elements on each end of the interface. In this case, both
elements should continue with the capability exchange
procedure, by responding to the received CAPABILITY
INDICATION message. Even though simultaneous
capability exchange procedures are in progress between
the elements, both elements will acknowledge to the other
the same greatest common capabilities.
The list of features that may appear in a capability
exchange remains to be standardized. However, a
standardized feature list is not an issue since 3GPP is
responsible for specifying the contents of all messages
exchanged on all the open interfaces. If a feature in the
list is not recognized by an element receiving a
CAPABILITY INDICATION message, the feature is
ignored and not indicated in the CAPABILITY
INDICATION ACKNOWLEDGE message. Thus, a
feature only known by one of the two elements would not
be supported.
An example is given to illustrate the workings of a
capability exchange. Table 2 shows two elements and the
list of features and versions supported by each element.
Element 1 Element 2
Feature A A
Version(s) Release 99, 00 Release 99, 00
Feature
Version(s)
B
Release 00
B
Release 99
Feature
Version(s)
C
Release 99, 00
C
Release 00
Feature
Version(s)
D
Release 99
F
Release 99, 00
Table 2: Feature Lists Supported by Two Elements
Element 1 initiates a capability exchange by sending a
CAPABILITY INDICATION message to Element 2.
The message contains the list of features supported by
Element 1 and the release versions supported for each
feature, as seen in the column underneath Element 1 in
Table 2. Upon receipt of the indication message, Element
2 compares the received list of features and versions with
its own capabilities. Element 2 responds to Element 1
with a CAPABILITY INDICATION ACK message
containing the greatest common capabilities.
In the CAPABILITY INDICATION ACK message,
Element 2 includes feature A release 00, since release 00
represents the greatest common version for both elements.
Feature B is not included in the message. Although both
elements are aware of feature B, they do not support the
same versions. Feature C with release 00 is included in
the message, as both elements are aware of that version.
Feature D is not known by Element 2 and is not included
in the message, as only common capabilities are indicated
in the acknowledgement. Similarly, feature F is not
included in the message, as it is not known by Element 1.
5. Scenarios of Capability Exchange
One common scenario requiring the use of a capability
exchange is during element initialization. When an
element starts or restarts in a network, an exchange is
required to negotiate software capabilities with the other
elements to which it will communicate. Another scenario
requiring the capability exchange involves the changing of
a software version at one of the elements of the open
interface. There are two main cases, which are described
below.
The first case involves an element that undergoes either
a software upgrade or downgrade with a communication
outage. Here, the communication between elements is
terminated due to the software change and must be
re-established. Capabilities are exchanged when
communication is re-established but before service is
restored, as shown in Figure 4.

4. General Business Information
4
General Business Information
CAPABILITY INDICATION
CAPABILITY INDICATION ACK
Element 1 Element 2
UPGRADE / DOWNGRADE PROCEDURE
(Communication Loss)
Figure 4: Upgrade / Downgrade with Communication
Outage
The second case involves an element that undergoes a
software change with no communication outage, but either
with or without a service outage. If the software change
corresponds to an upgrade, the capabilities are exchanged
after the upgrade completes. Figure 5 illustrates an
Element 2 software upgrade with no communication loss.
The capabilities are exchanged after the successful upgrade
procedure, but before any new functionality is used that
affects the interface.
CAPABILITY INDICATION
CAPABILITY INDICATION ACK
Element 1 Element 2
UPGRADE PROCEDURE
(No Communication Loss)
Figure 5: Element 2 Software Upgrade with No
Communication Outage
Figure 6 illustrates an Element 2 software downgrade with
no communication loss. The capabilities are exchanged
before the software downgrade procedure, since some
functionality currently in use may be removed as a result of
the downgrade.
CAPABILITY INDICATION
CAPABILITY INDICATION ACK
Element 1 Element 2
DOWNGRADE PROCEDURE
(No Communication Loss)
Figure 6: Element 2 Software Downgrade with No
Communication Outage
6. Benefits Over Current Methods
As previously discussed, the capability exchange was
shown as a method for achieving interoperability between
network elements running unaligned releases of software.
In GSM (second generation cellular), the method
commonly used to obtain interoperability involves an
operator setting, via database options, the features a
particular element should utilize. All elements required to
support a feature must possess software for that feature, as
well as have the database option for that feature enabled.
There are several advantages to using a capability
exchange scheme over the traditional database option
scheme. Those advantages are enumerated here.
Automated versus manual control
The manual setting of element feature utilization via
database options is prone to error. An operator may not
correctly enable or disable a feature at a network element.
Additionally, the operator may overlook some elements
where the feature is to be utilized. The capability
exchange on the other hand is an automated process. All
elements within the network negotiate automatically with
one another, ensuring common features are supported.
There is also the added benefit that certain elements may
be able to develop a global picture of the features that are
supported in the network. For example, an RNC in the
UTRAN will know all the features supported by the Node
B elements that the RNC controls. The RNC may choose
to support a feature if known by all Node B elements.
Alternatively, the RNC may choose to support a feature at
a subset of Node B sites, allowing greater flexibility.
The manual setting of element feature support via
database options is also labor intensive. Cellular networks
in the field today typically contain hundreds or thousands
of elements. Setting feature options for an element to
support is also not a one-time task. New software
releases can in effect alter which features are supported
within a network and ultimately within each element. The
capability exchange minimizes operator intervention.
Support for software changes
As detailed in section 5, the capability exchange is an
integral part of an element software upgrade or
downgrade. The capability exchange allows the element
to change software versions and renegotiate the
functionality supported without requiring an element
outage. Functionality changes may be accomplished in
real time in the network during the software upgrade or
downgrade.
The alternative method of requiring an operator to set
database options has several drawbacks in regards to
software changes. First of all, manually setting in real
time the changed feature set that should be supported by
elements undergoing a software change is difficult. The
manual change has to be coordinated across the elements
so as to occur at the same time. Secondly, simultaneous

5. General Business Information
5
General Business Information
updates of the software and database at an element by the
operator may require an element outage.
7. Conclusion
Third generation WCDMA cellular networks have
embraced the concept of open interfaces between network
elements. Open interfaces allow cellular operators greater
flexibility in incorporating multiple vendors into their
network. Open interfaces also present the challenge of
interoperability in terms of software and the optional
features or functionality that an element may provide.
The capability exchange scheme presented provided a
means to achieve interoperability between network
elements in terms of software features supported. The
principles of how a capability exchange procedure is used
between elements were detailed. The benefits of a
capability exchange mechanism, both in terms of its
automation and its support of software changes in the
network, were enumerated.
An important point to highlight is that a capability
exchange scheme is not limited to WCDMA cellular
networks. The concept can, in general, be applied to any
other network that requires an automated method for
achieving interoperability between its elements.
8. References
[1] TS 25.401 v3.0.0, 3rd
Generation Partnership
Project (3GPP), Technical Specification Group
(TSG) RAN, UTRAN Overall Description.
[2] TS 25.410 v3.0.0, 3rd
Generation Partnership
Project (3GPP), Technical Specification Group
(TSG) RAN, UTRAN Iu Interface: General Aspects
and Principles.
[3] TS 25.420 v2.0.0, 3rd
Generation Partnership
Project (3GPP), Technical Specification Group
(TSG) RAN, UTRAN Iur Interface: General
Aspects and Principles.
[4] TS 25.430 v2.0.1, 3rd
Generation Partnership
Project (3GPP), Technical Specification Group
(TSG) RAN, UTRAN Iub Interface: General
Aspects and Principles.