Designing 3G Systems

In this article, we will examine the UMTS architecture and present a layer-by-layer description of the UMTS radio interface protocol. We'll also look at the formal languages used in the specifications and explain how they can be utilized for product development.

An Architectural Overview of UMTS

In the Standard, the mobile device is referred to as "User Equipment" (UE), which means a mobile device and multimedia terminal that takes care of voice (basically like a mobile phone) as well as transferring pictures and video. Compared to other existing mobile networks, features include prioritized lines, broadcast, power control, communicating between mobile units without base stations, and support for MobileIP and multimedia. As Figure 1 illustrates, the infrastructure of a UMTS network is similar to GSM.

On the terminal side, the UE is a mobile device that could contain a variety of functions — and not necessarily an ordinary mobile phone. On the infrastructure side, the UE is communicating with the Node B — the base station. In the next instance, Node Bs are communicating with the Radio Network Controller (RNC). The Mobile Switching Center is shared among all connected networks.

The UMTS Radio Interface Protocol

The UMTS radio interface consists of three layers, each of which provides services with specific tasks and functions. Figure 2 displays each layer's connections and correspondence. The Radio Interface protocol is divided into: Physical Layer (Layer 1), Data Link Layer (Layer 2), and Network Layer (Layer 3). The Data Link Layer, in turn, consists of four entities: Media Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Control (PDCP), and Broadcast Multicast Control (BMC). Finally, the Network Layer consists of the Radio Resource Control (RRC). All information is passed between the layers via channels (CH) or Service Access Points (SAP).

A SAP provides services for the upper layers or the application. A SAP comprises a set of operations (or primitives) for the upper layers to use to fulfill specific commissions. SAPs are divided into Control and Traffic SAPs, with the Control SAPs carrying Control information and the Traffic SAPs passing the user information.

Channels are defined between the lower layers in the protocol — PHY, MAC, and RLC. The Logical Channels are describing what type of data is transported, Control information or Traffic data (speech and/or data). The Transport Channels are characterized by how the data is transferred — Common or Dedicated. If data is transferred through the Common Channel, the data is distributed to several receivers in a cell and correspondingly, data on the Dedicated Channel is distributed to a specific receiver.

Physical Layer

The radio part in a UMTS network is based on Code Division Multiple Access (CDMA), a conflict-free protocol allowing transmission via frequency and time-division techniques. There are two duplex modes defined in the UMTS specification: Frequency Division Duplex (FDD) and Time Division Duplex (TDD). In FDD mode, a physical channel is characterized by the code, frequency, and in the uplink (the relative phase). In the TDD mode, the physical channels are characterized by timeslots. The uplink and downlink transmissions are carried over the same radio frequency, but in separate time intervals. Table 1 lists the frequency bands for UMTS in FDD operation. TTDD is working in different frequency spans, depending on geographical regions, and all frequencies are used for uplink and downlink; see Table 2.

The nominal channel bandwidth is 5 MHz but can be optimized in terms of performance and needed throughput in 200-KHz increments. This implies that the carrier frequency must be a multiple of 200 KHz. Other adjustable parameters are the power dynamics, both from the UE and the Node B side; see Figure 3. The physical layer continuously measures power on the physical channel to keep track of necessary weighting of the transmitted power, and to maximize the efficiency in the air. The power control cycles are 1500 and 1600 times per second, depending on uplink and downlink connections for the regulation of the transmitted power. The physical layer is controlled by RRC; see Figure 4. Other commissions for the physical layer include mapping the information between the Transport Channels and Physical Channels.

As Table 3 shows, the physical layer provides two different types of transport channels. Data is passed down through the layers, either to the Dedicated or the Common channels, depending on the application demands.

Medium Access Control

The main function of the Medium Access Control (MAC) layer (Figure 5) is to map the control information and user traffic to different channels provided by the physical layer; the logical channels to transport channels. Control Channels pass control information while Traffic Channels contain user information (for example, speech or data). As listed in Table 4, MAC provides the two categories of logical channels to the RLC layer.

Radio Link Control

The main task for the Radio Link Control (RLC) layer (Figure 6) is to transfer user data and provide the necessary quality of service (QoS) depending on the application and degree of insurance that the data will be transmitted to the peer. The RLC takes care of the error correction and retransmission as well as the segmenting and reassembling of data. Retransmission is used when an unrecoverable error has occurred, and it is controlled and configured by the RRC to provide different levels of QoS.

There are a number of services provided for the upper layers. Depending on the service, the information can be transmitted in three different modes:

• Transparent data transfer (Tr), which includes segmentation and reassembly functionality as necessary for data without adding any other protocol information.

• Unacknowledged data transfer (UM), which transmits data without guaranteeing delivery to the other device but will get an immediate delivery.

• Acknowledged data transfer (AM), which guarantees an error-free delivery of data to another device (peer entity). In the case where the data is not correct, the transmitter is notified and the data is retransmitted.

Packet Data Convergence Protocol

To use future Internet-related devices (MobileIP) and Packet Data-based services, the Packet Data Convergence Protocol (PDCP) layer (Figure 7) provides support for network layer protocols such as IPv4 and IPv6. The PDCP also handles functions such as header compression and decompression for TCP/IP packets to improve the data throughput and performance on the channels. The RRC controls which compression algorithm is to be used. The data is transmitted and received through one RLC channel in one of the RLC modes — acknowledged, unacknowledged, or transparent mode.

Broadcast Multicast Control

The requirements to get point-to-multipoint services for the protocol are fulfilled with the Broadcast Multicast Control (BMC) layer (Figure 8). Data is, of course, sent unacknowledged and the delivery of information is not guaranteed.

Radio Resource Control

By far, the most complex and largest layer in the radio interface protocol is the Radio Resource Control (RRC) because of the wide range of functions delivered and provided. The main tasks (see Figure 9) are to establish, maintain, and release a connection. However, the RRC also controls several other essential SAP functions, including:

• General Control (GC), used for information broadcast. This service broadcasts information to all UEs in a certain geographical area. Single or repeated transmission of the information is made by services in the BMC.
• Notification (Nt), which delivers paging and notification broadcasts. Paging means that information is sent to one or several specific UEs in a certain geographical area. Notification broadcast, on the other hand, transfers information to all UEs in a certain geographical area.

• Dedicated Control (DC), in which SAP controls the establishment/release of a connection and transfer of messages. The RRC establishes/releases one-to-one or one-to-many connections between peer RRC entities. Once a connection has been set up, transfer of messages takes place, possibly with a QoS requirement stated for each message.

The functions taken care of by the RRC include establishing and maintaining required QoS for a connection. This implies the controlling of the other layers and accomplishes right decisions out of reported/collected connection statistics and measurements. For example, the transmitted power control is controlled by the RRC.

The Specification and Description Language

The Specification and Description Language (SDL) is a graphical object-oriented language intended for the specification of complex event-driven, real-time systems involving many concurrent activities, such as communication protocols. (For more information, see http://www.sdl-forum .org/.)

In SDL, the specification of a system is divided into architecture and behavior. The static structure of a system is defined in terms of blocks and channels. A block corresponds to a logical or physical system unit, possibly connected to other blocks via channels. Channels are synonymous to communication paths, describing where signal interchange can take place. Behavior is described in processes located inside the blocks by means of finite state machines — a modeling concept commonly used in protocol and communication engineering. Well-defined graphical symbols are used to describe the behavior in a flowchart manner according to Figure 10. SDL processes can be created at system start or created and terminated at run time. Being a real-time language, full support for timers is also included. When it comes to handling data, ASN.1 can be used in addition to pre/user-defined data types.

SDL appears frequently in the UMTS Standard, describing various behavior.

Message Sequence Charts

A Message Sequence Chart (MSC) offers a powerful complement to SDL for describing communication between different entities in a system. Its graphical representation is well suited for presenting a complex dynamic behavior in a clear, unambiguous, and easily understandable way. This makes MSC ideal not only for UMTS standardization (as done by 3GPP) but also for a designer to use in execution tracing.

An MSC diagram (Figure 11) contains a chronological sequence of messages sent between system entities and their environment. In addition, several MSCs can be combined with high-level MSCs (HMSC).

Abstract Syntax Notation One

Abstract Syntax Notation One (ASN.1) is a language intended for abstract syntax definition, such as data types and values, typically found in a protocol message specification. It is used in conjunction with encoding rules describing the transfer syntax. By means of ASN.1 and encoding rules, a clear abstract description of data types and values used in a protocol, separate from any considerations regarding the bit stream eventually being transmitted, is achieved. This approach is used in the RRC specification for defining Protocol Data Units (PDU) and Information Elements (IE). Specifically, ASN.1 basic notation and Packed Encoding Rules (PER) are used.

With ASN.1, data types are described similarly to data structures in a regular programming language. A set of predefined types can be used (INTEGER, ENUMERATED, and OCTET STRING, for instance), while more complex user-defined types are created with constructs such as SEQUENCE and CHOICE. Listing One is an abbreviated example taken from the RRC specification. In addition, classes, constraints, and parameterization are used for more efficient definitions. Built-in support for extensibility lets a protocol version be compatible with extended future releases.

Tree and Tabular Combined Notation

Conformance tests for UMTS equipment are a part of Release 1999. In the UE case, Tree and Tabular Combined Notation (TTCN) is used for a detailed and executable description of test cases, eventually covering conformance with NAS protocols as well as RRC, RLC, and MAC. However, the first version will not address all aspects of these protocols.

In TTCN, an Abstract Test Suite (ATS) regards a system under test as a black box — control and observation is done via externally available interfaces only. It consists of four parts:

• Overview. Index and references to the different parts of the test suite.
• Declarations. PDU and Point of Control and Observation (PCO) declarations.

• Constraints. Values sent and/or received; for example, values assigned to PDU instances and other data structures.

• Dynamics. Test cases with test events and verdicts describing the execution behavior of the test suite.

Each test case is seen as a behavior tree, describing the actions to be performed at the PCOs and the expected responses. In TTCN, a behavior tree is represented in a tabular format. The table mirrors the tree by defining events in rows at different indentation levels. Rows with the same indentation are alternative events while rows on the next indentation represent the next step in the sequence. Eventually, a test case reaches a verdict of passed, failed, or inconclusive. Figure 12 illustrates the relationship between the tree and the table. ASN.1 is a part of TTCN and can thus be used for PDU definitions.

Specifications in Product Development

The nature of a standard restricts the reuse of behavioral descriptions in product development. Internal behavior is usually left out or described in a very abstract manner with the intention of not restricting implementations. Architectural choices, such as data buffering policies and memory handling, must be made, enabling all the semantics in the text to be represented as behavior diagrams or external procedures. In addition, a framework for creating, administering, and deleting protocol entities also must be added. The SDL specification, taken from the Standard, passes through stages successively more execution oriented, until an implementation may be generated. These steps are basically the same regardless of specification and tools used, with one big advantage in not having to start the system design from scratch. Another advantage is that a quite limited SDL specification allows executable code to be generated automatically. The design can thus be simulated, validated, and verified while still on the drawing board.

For ASN.1, the situation is more straightforward. Once the PDU and IE definitions have been extracted from the RRC specification, commercially available tools automatically generate PER encoder/decoder support as well as an implementation language representation, for example SDL.

Although intended for conformance testing, TTCN is also useful in earlier stages of protocol implementation, especially in combination with SDL. Integrated TTCN and SDL tools let cosimulations be performed on the host using the 3GPP ATSs and an SDL system as input. In a debugger-like fashion, suitable test cases are executed and the behavior is inspected in detail. However, some errors, such as those related to the hardware, cannot be detected. For this purpose, target testing is necessary. Here, a TTCN compiler automatically translates an ATS into an Executable Test Suite (ETS), which is run on the target. Working with TTCN and SDL can also make the process of regression testing automatic.

Conclusion

3GPP is currently preparing the UMTS Standard. The size and complexity of new technology introduced in the specifications (that is, the radio interface protocol) illustrates the need for formal methods, languages, and tools not only in the standardization work but also during system implementation. When integrated tools based on these languages are used in system development, many benefits can be observed, specifically:

• Rapid system design using extracts from the specifications as input.
• Abstract descriptions, yet automatic generation of fully executable and platform-independent code.

• Early system simulation and validation.

• A mature integrated methodology that can be used all the way to implementation.

• Early cosimulation, regression testing, and/or conformance testing via developed or imported test suites.

DDJ

Listing One

--*****************************************************
--
--Downlink CCH messages
--
--*****************************************************

DL-CCH-Message ::= SEQUENCE {
  integrityCheckInfo            IntegrityCheckInfo OPTIONAL,
  message                       DL-CCCH-MessageType
}

DL-CCCH-Message ::= CHOICE {
  rrcConnectionReEstablishment  rrcConnectionReEstablishment-CCCH,
  rrcCoonnectReject             rrcCoonnectReject,
  rrcConnectionRelease          rrcConnectionRelease,
  rrcConnectionSetup            rrcConnectionSetup,
  uraUpdateConfirm              uraUpdateConfirm-CCCH,
}
--*****************************************************
--
-- Uplink CCCH messages
--
--*****************************************************

UL-CCCH-Message ::= SEQUENCE {
   integrityCheckInfo           integrityCheckInfo OPTIIONAL,
   message                      UL-CCCH-MessageType
}

Back to Article