UMTS Model Desc

38—UMTS

38 UMTS

This document provides an overview of the features of the UMTS model suite, shipped as part of the specialized model library. The manual assumes that you are familiar with the UMTS protocol and that you are comfortable using OPNET Modeler. For your convenience, a brief protocol overview and a list common UMTS acronyms are included in the appendices. For more detailed information about UMTS, see one of the documents listed in Reference Documents on page SPM-38-8.

UMTS modeling topics:

• General Model Description

• Model Features and Limitations

• Creating a UMTS Network Topology

• Model Architecture

• Model Interfaces

• Model Attributes

• Simulation Attributes

• UMTS Statistics

• Appendix I: Acronyms and Abbreviations Used in UMTS

• Appendix II: UMTS Protocol Background

General Model Description

Universal Mobile Telecommunications System (UMTS) is a Third Generation (3G) wireless protocol that is part of the International Telecommunications Union’s IMT-2000 vision of a global family of 3G mobile communications systems. UMTS is expected to deliver low-cost, high-capacity mobile communications, offering data rates up to 2-Mbps. The UMTS model suite allows you to model UMTS networks to evaluate end-to-end service quality, throughput, drop rate, end-to-end delay, and delay jitter through the radio access network and core packet network. It can also be used to evaluate the feasibility of offering a mix of service classes given quality of service requirements. This model is available as part of the specialized model library.

OPNET Modeler/Release 14.5 SPM-38-1

38—UMTS

The UMTS model of the packet wireless network is based on 3rd Generation Partnership Project (3GPP) Release-5 standards. The network architecture of this release is divided into the radio access network (RAN) and the core network as shown in Figure 38-1. The UMTS module models the UMTS RAN and the UMTS functionality of the core network (see highlighted elements in Figure 38-1). The radio access network for UMTS contains the User Equipment (UE), which includes the Terminal Equipment (TE) and Mobile Terminal (MT), and the UMTS Terrestrial Radio Access Network (UTRAN), which includes the Node-B and Radio Network Controller (RNC).

UMTS uses Wideband Code Division Multiple Access (W-CDMA) access scheme. This version of W-CDMA uses direct spread with a chip rate of 3.84 Mcps and a nominal bandwidth of 5 MHz. The model supports one of W-CDMA’s two duplex modes: Frequency Division Duplex (FDD). Time Division Duplex (TDD) is not supported. In FDD mode, uplink and downlink transmissions use different frequency bands. The radio frame has a length of 10 ms and is divided into 15 slots. Spreading factors vary from 256 to 4 for an FDD uplink and from 512 to 4 for an FDD downlink. With these spreading factors, data rates of up to 2 Mbps are attainable.

The packet domain core network includes two types of network nodes: serving GPRS support nodes (SGSNs) and the gateway GPRS support node (GGSN). The GPRS support nodes (GSNs) include all GPRS functionality needed to support GSM and UMTS packet services. SGSNs monitor user location and perform security functions and access control. The GGSN contains routing information for packet-switched (PS) attached users and provides interworking with external PS networks such as the packet data network (PDN). The model’s CN nodes include both SGSN and GGSN functionality.

The circuit switched (CS) core network, which is not currently modeled, includes the mobile switching center/visitor location register (MSC/VLR). The MSC/VLR is used in the packet domain architecture to efficiently coordinate PS and CS services and functionality. The Home Location Register (HLR) contains GSM and UMTS subscriber information. The Charging Gateway Functionality (CGF)

SPM-38-2 OPNET Modeler/Release 14.5

38—UMTS

collects charging records from the SGSN(s) and GGSN. The Equipment Identity Register (EIR) stores information about user equipment identity. The HLR, CGF, and EIR are included in this description for completeness, but are not currently modeled.

Figure 38-1 Overview of Packet Domain Architecture

Representation in OPNET Modeler

Standards Representation


38—UMTS

Model Features and Limitations

Model Features

The following table lists the main UMTS features included in the implementation of the UMTS model.

Table 38-1 Model Features

Feature Description

GPRS attach The GPRS attach procedure informs the SGSNs when the user equipment (UE) is at power-on and of its GPRS capability. The model assumes that a PS signaling connection is already set up.

For more information, see GPRS Attach on page SPM-38-43.

GTP The GPRS Tunneling Protocol (GTP) protocol, which is used in the RNC/SGSN/GGSN nodes to encapsulate IP packets in the core network is modeled. The CN can be configured using Service GPRS Support Nodes (SGSN) and Gateway GPRS Support Nodes (GGSN). The core network supports IP, ATM, or Ethernet technologies as a part of the backbone that interconnects SGSN and GGSN nodes. GTP tunnels are extended up to the Radio Network Controller (RNC).

For more information, see CN Architecture on page SPM-38-31.

PDP context activation On receipt of PDUs (protocol data units), the UE or network activates a PDP (Packet Data Protocol) context if one is not already activated. The PDP context activation includes the requested QoS (Quality of Service) profile associated with the traffic class of the PDUs received. Once activated, a PDP context remains active for the rest of the simulation. The model assumes that a PS (packet switched) signaling connection is already established for the PDP context activation procedure.

For more information, see PDP Context Activation and RAB Assignment (MS-Connected State) on page SPM-38-44.

RAB Setup, Release, Negotiation, Renegotiation, and Preemption

When a UE receives data belonging to a traffic class for which a PDP context has already been activated, but no RAB (Radio Access Bearer) exists, it can dynamically request the setup of a RAB through the service request procedure. RABs are set up by the network, which later releases the RAB if it detects that the RAB has been idle for some time.

RABs can also be released due to preemption to free resources in the cell for the admission of higher priority QoS RABs.

RABs can also be released due to the failure of RAB modification.

An SGSN can also initiate a RAB for a UE that receives data for a QoS category for which it does not have an active RAB.

During setup, a RAB can be admitted with its maximum bit rate or guaranteed bir rate. Negotiation occurs when the RAB cannot be admitted with its maximum rate, but is admissible with a guaranteed rate that is lower than the maximum rate.

The admission of a high-priority RAB may cause a lower-priority RAB to be renegotiated instead of being preempted. When this occurs, the rate of the low-priority RAB is reduced from its maximum rate to its guaranteed rate.

For more information, see RAB Assignment with Prior PDP Activation (MS-Connected State) on page SPM-38-46.

Service Request See above (RAB setup/release).

Repeaters A repeater can be used to extend the coverage area of a Node-B cell, improve signal strength (especially in downlink), and get around physical obstacles.


38—UMTS

RLC Modes: AM, UM, TrM

Three RLC modes are supported: acknowledged mode (AM), unacknowledged mode (UM), and transparent mode (TrM). RLC modes impact throughput and delay due to their different algorithms.

For more information, see UE Process Model Architecture on page SPM-38-18.

Priority handling of data flows based on traffic class at MAC

Each traffic class is assigned a different priority and the MAC can handle data flows of different priority levels.

For more information, see UE Node Model Architecture on page SPM-38-16.

Traffic classes The four traffic classes defined in UMTS are supported: conversational, streaming, interactive, and background. You can use a mix of different traffic classes for each UE.

One QoS profile per traffic class of a UE

Each traffic class is associated with a configurable QoS profile (consisting of: data rate, priority level, preemption capability, vulnerability,...). This QoS profile is the QoS requested by the UE in the PDP context activation procedure.

Support of TCP/IP stack

TCP (UDP) and IP layers are implemented at the UE. The IP layer is also implemented at CN nodes.

For more information, see UE Node Model Architecture on page SPM-38-16.

W-CDMA air interface (FDD mode only)

Only the FDD mode is supported. Packet dropping probability is based on curves obtained from another set of simulations of the W-CDMA air interface (accurate to the waveform level).

Admission Control Two admission control algorithms are modeled: a default algorithm and a throughput-based algorithm.

For more information, see RNC Process Model on page SPM-38-28.

DCH Uplink and downlink dedicated signaling channels (DCHs) are used for all signaling messages between UE and UTRAN/CN. Signaling DCHs are established when needed and modeled with high fidelity. DCHs are configurable on a per-QoS basis for each RNC.

DSCH The model supports the DSCH (Downlink Shared Channel), which can be used by UEs in CELL_DCH state for downlink communications. Each RNC deploys a single DSCH for each cell it manages. All DSCHs of an RNC use the same customizable configuration.

For more information, see RNC Process Model on page SPM-38-28.

FACH (Forward Access channel)

RACH (Random Access Channel)

The UE CELL_FACH state is modeled. A UE in the FACH state uses the RACH channel for uplink transmissions and the FACH channel for downlink transmissions. FACH scheduling follows a weighted round-robin approach and allows you to assign weights according to QoS class.

Contention in the RACH channel is based on the Slotted ALOHA approach with fast acquisition indication. The power ramp up procedure is modeled as an open loop power control feature. Access service classes are configurable and can be mapped from the UMTS QoS classes.

For more information, see UE Process Model Architecture on page SPM-38-18.

UMTS RLC SDU (Service Data Unit) Concatenation

The model supports RLC concatenation of SDUs. When this feature is enabled, the RLC layer may concatenate multiple SDUs on every transmission time interval (TTI). This feature is supported only for RLC acknowledged and unacknowledged modes. It can be enabled/disabled on per QoS basis within the data channel configuration (per QoS) at the RNC node.

Table 38-1 Model Features (Continued)

Feature Description


38—UMTS

Model Limitations

The following UMTS protocol features are not explicitly modeled.

• IPv6 over UMTS. This type of configuration is not supported.

• Synchronization at power-on. The various synchronization that occurs when a user powers-on is not modeled, with the exception of the GPRS attach procedure.

• GMM-Idle mode. Only the GMM-Connected mode is modeled.

Power control Outer loop power control is supported.

For outer loop power control, the model increases the receiver’s target signal to noise ratio (Eb/No) by 1.0 dB for every received packet it rejects because of unrecoverable bit errors. When the receiver gets a packet that has no unrecoverable errors the model decreases the target Eb/No by x dB, where x is 1* requested BLER (block error rate). Then, by using the new target Eb/No, changes, the model adjusts the power accordingly. (Based on algorithm presented in Holma and Toskala—see reference documents.)

UE mobility Movement of a UE within a cell is modeled.

Logical and transport channels

UMTS models allow the mapping of logical channels to transport channels, and enable a queuing scheme for logical channel to transport channel multiplexing.

UE can have up to 4 data transport channels for uplink and downlink, and 1 signaling transport channel for uplink and downlink. Three scheduling schemes will be used for logical channel multiplexing in the MAC: Strict Priority, Weighted Round Robin, and Modified Weighted Round Robin.

Signaling messages Signaling messages will be queued until signaling DCH is established. No expiration means no matter how long establishment takes, and Infinite queue means no matter how many messages must be queued. The following procedure will be followed for each signaling message to be sent: Send message on existing signaling DCH. If no existing signaling DCH, request one from admission control. If request is rejected, use common channels to forward the message

Intra-RNC hard and soft handovers

UMTS models both hard and soft handovers of the UEs between the Node-Bs of the same RNC. Soft handovers within an RNC is modeled based on 3GPP’s release 1999 standards. UMTS also supports soft handover events 1A, 1B, and 1C (active cell addition, removal, and replacement procedures, respectively.

Softer handovers—among the cells/sectors of a Node-B—are also modeled.

For more information, see Signal Flows for Hard Handover on page SPM-38-50 and Signal Flows for Soft Handover on page SPM-38-51.

IP Support between RNC and Node-B

RNC and Node-B node models are enhanced to include the IP protocol stack. These enhancements provide the option of using IP transport for Radio Access Network (RAN) signaling, in addition to AAL5 transport.

RNC to SGSN connectivity

An RNC node is able to connect to multiple SGSN nodes. Load sharing is possible between multiple SGSNs connected to a single RNC.

End of Table 38-1

Table 38-1 Model Features (Continued)

Feature Description


38—UMTS

• GPRS detach. It is assumed that a UE remains attached for the remainder of the simulation.

• PDP context deactivation and reactivation. During a simulation, PDP context activation occurs only once for each QoS profile. The PDP context is not deactivated and is reused the next time a UE requests the QoS profile associated with the PDP.

• QoS Parameters. Uplink and downlink data rates are the only negotiable QoS parameters. Maximum Bit Rate Uplink/Downlink are the desired data rates for a UE. Guaranteed Bit Rate Uplink/Downlink are the lowest data rates a UE can accept. The UE will accept either maximum bit rate or guaranteed bit rate through a negotiation or renegotiation process initiated by the RNC.

• QoS negotiation/renegotiation. QoS negotiation during the relocation procedure (Section 7 in TS25.946) is not supported. QoS negotiation/ renegotiation are solely initiated by the RNC. The RNC knows all QoS parameters acceptable to the UE. The UE will always accept the negotiated/ renegotiated bit rates from the RNC.

• No support for repeater chaining. Repeater chaining is not supported.

• IP Support between RNC and Node-B. Only UDP will be used for Iub transport layer. Only IP transport will be supported for Node-B to RNC transport. Simultaneous use of ATM and IP interfaces for Node-B to RNC transport will not be supported.

• No support for parallel spreading codes on dedicated channel. Dedicated channels do not support parallel codes. This limits the maximum data rate a single channel can support.

• CPCH, PCPCH. The common packet channel (CPCH) and the physical common packet channel (PCPCH) are not modeled.

• System information, cell selection, and PLMN are not modeled.

• No mobility prior to attachment. At start time, the model attaches each UE to the closest Node-B (determined based on path loss). No mobility is modeled prior to attachment and UEs begin monitoring their location after attachment.

• RNC to SGSN connectivity. RNCs must be connected to SGSNs directly using ATM, Ethernet, or PPP links. The models do not support having routers or switches between RNCs and SGSNs. An RNC will be able to be served by any SGSN to which it is directly connected. There is no explicit signaling between the RNC and its SGSNs for discovery of serving SGSNs.

• Load Sharing. User will configure each UE with the ID of the SGSN it is to use. Dynamic load sharing in the RNC will not be modeled.

• Load Balancing. RNCs will not do load balancing. The UE will specify the serving SGSN.


38—UMTS

• Inter-RNC and inter-SGSN handovers. UE handovers are not supported between RNCs or between SGSNs.

• Handover in FACH/RACH. Handover is not supported for UEs using the common channels FACH/RACH (that is, the UEs in the CELL_FACH state).

Reference Documents

This manual documents the UMTS simulation model and assumes that you are familiar with the UMTS protocol. For background information about UMTS, see the appendix for a basic summary of UMTS or to one of the references listed below for detailed information.

The UMTS model suite is implemented based on information available from the following sources.

H. Holma, A. Toskala, WCDMA for UMTS Radio Access for Third Generation Mobile Communications, John Wiley & Sons, 2000.

T.S. Rappaport, Wireless Communications: Principles and Practice, Prentice Hall, 1996.

3G TR 25.922: Radio resource management strategies (Release 1999).

3G TR 25.931: Technical Specification Group RAN (Release 1999).

3G TS 22.060: General Packet Radio Service (GPRS); Service description; Stage 1 (Release 1999).

3G TS 23.003: Numbering, addressing and identification (Release 1999).

3G TS 23.060: General Packet Radio Service (GPRS); Service description; Stage 2 (Release 1999).

3G TS 23.107: Quality of Service, Concept and Architecture (Release 1999).

3G TS 24.007: Mobile radio interface signaling layer 3; General aspects (Release 1999).

3G TS 24.008: Mobile radio interface layer 3 specification; Core Network Protocols – Stage 3 (Version 5.4.0).

3G TS 25.211: Physical channels and mapping of transport channels onto physical channels (FDD) (Release 1999).

3G TS 25.212: Multiplexing and channel coding (FDD) (Release 1999).

3G TS 25.213: Spreading and modulation (FDD) (Release 1999).

3G TS 25.214: Physical layer procedures (FDD) (Release 1999).

3G TS 25.301: Radio Interface Protocol Architecture (Version 5.1.0).

3G TS 25.303: Interlayer Procedures in Connected Mode (Release 1999).

3G TS 25.321: Medium Access Control (MAC) Protocol Specification (Version 5.9.0).

3G TS 25.322: RLC Protocol Specification (Version 5.9.0).

3G TS 25.331: RRC Protocol Specification (Version 5.1.0).


38—UMTS

3G TS 25.401: UTRAN Overall Description (Release 1999).

3G TS 25.402: Synchronization in UTRAN Stage 2 (Release 1999).

3G TS 25.413: UTRAN Iu Interface RANAP Signaling (Version 5.1.0).

3G TS 25.433: UTRAN Iub Interface NBAP Signaling (Release 1999).

3GPP TS 23.107: Quality of Service (QoS) concept and architecture. version 5.5.0.

3GPP TS 24.008: Mobile radio interface Layer 3 specification: Core network protocols, Stage 3. version 5.4.0.

3GPP TS 25.101: Technical Specification Group Radio Access Networks; UE Radio Transmission and Reception (FDD) (Release 1999).

3GPP TS 25.322: Radio Link Control (RLC) protocol specification. version 5.1.0.

3GPP TS 25.331: Radio Resource Control (RRC) protocol specification. version 5.1.0.

3GPP TS 25.413: UTRAN lu interface Radio Access Network Application Part (RANAP) signaling. version 5.1.0.

3GPP TS 25.433: UTRAN lub interface Node B Application Part (NBAP) signaling. version 5.1.0.

3GPP TS 25.851: RAB Quality of Service (QoS) renegotiation over lu. version 4.0.0.

3GPP TS 25.946: RAB Quality of Service (QoS) negotiation over lu. version 4.0.0.


38—UMTS

Creating a UMTS Network Topology

Available Node Models

The node models shipped as part of the UMTS specialized model library are grouped in the UMTS and UMTS_advanced object palettes.

Figure 38-2 UMTS Object Palette

Table 38-2 Node Models

Node model Description

UE umts_station General client node that includes UE and generic traffic generation functionality. This node can only send traffic to (and receive traffic from) other umts_station nodes served by the same SGSN.

umts_wkstn General workstation node (with full OSI stack) that includes UE and client/server application functionality.

umts_server General server node (with full OSI stack) that includes UE and client/server application functionality.


38—UMTS

Cell Creator Utility

While creating or working with your UMTS network topology, you may want a visual depiction of the hexagonal cell sectors in a UMTS network. The Cell Creator utility allows you to draw a grid of cells on a map in the Project Editor.

The Cell Creator utility takes an existing map and superimposes on it a grid structure with the parameters you specify. It then creates a new map that you can use in your network topology. When using the utility, you specify the rectangular area of the map where you would like to draw the cells. Define the rectangle using the longitude and latitude coordinates of two diagonally

UTRAN umts_node_bumts_node_b_atmumts_node_b_ethernetumts_node_b_slip

Node-B portion of the UTRAN.

umts_node_b_3sectorumts_node_b_3sector_atmumts_node_b_3sector_ethernetumts_node_b_3sector_slip

Node-B portion of the UTRAN. This node_b model has 3 directional antennas, which handle connections with the UEs in their sector.

umts_node_b_6sectorumts_node_b_6sector_atmumts_node_b_6sector_ethernetumts_node_b_6sector_slip

Node-B portion of the UTRAN. This node_b model has 6 directional antennas, which handle connections with the UEs in their sector.

umts_rncumts_rnc_ethernet_atm_slipumts_rnc_atm2_eth2_slip2

RNC portion of the UTRAN.

CN umts_sgsn Simple CN node—has core network functionality, but does no IP routing. Routes packets to and from umts_station nodes, exclusively.

umts_ethernet_slip8_gtwyumts_ethernet_slip8_large_gtwy

Gateway CN node—general gateway node that includes SGSN and GGSN routing functionality and Ethernet and SLIP interfaces. Used only in networks with umts_wkstn and umts_server nodes. Not used with umts_station nodes.

umts_ggsn_slip8umts_ggsn_atm8_ethernet8_slip8umts_ggsn_ethernet2_slip8

GGSN portion of the CN

umts_sgsn_ethernet9_atm_slip umts_sgsn_ethernet_atm9_slipumts_sgsn_ethernet_atm_slip9

SGSN portion of the CN

Repeater umts_repeater Add to extend coverage area of Node-B cell, improve signal strength (especially in downlink), and get around physical obstacles.

End of Table 38-2

Table 38-2 Node Models (Continued)

Node model Description


38—UMTS

opposite corners of the rectangle. For example, you can specify either the upper-right corner and lower-left corner, or the lower-right corner and the upper-left corner. The order that you specify the corners in doesn’t matter, what’s important is that the corners you specify are diagonally opposite each other.

The Cell Creator utility’s input parameters are listed below.

Procedure 38-1 Using the Cell Creator Utility

1 Configure the machine to use the External Model Access (EMA) package by verifying that the following directory listed in your PATH environment is one of the following:

Windows: <install_dir>/<rel_dir>/sys/pc_intel_win32/bin

Linux: <install_dir>/<rel_dir>/sys/unix

2 Configure the LD_LIBRARY_PATH environment attribute to include the full path to the directory of kernel libraries (Linux).

Windows: No special configuration is required.

Table 38-3 Cell Creator Input Parameters

Input Parameter Description

longitude 1 Longitude (in degrees) of the first corner of the rectangular area of cells.

latitude 1 Latitude (in degrees) of the first corner of the rectangular area of cells.

longitude 2 Longitude (in degrees) of the second corner of the rectangular area of cells. This corner should be diagonally opposite the first.

latitude 2 Latitude (in degrees) of the second corner of the rectangular area of cells. This corner should be diagonally opposite the first.

radius Distance from the center of the hexagon to the furthest vertex. Note that the hexagons drawn by this utility are not regular hexagons, so all vertices are not equidistant from the center.

miles|kilometers Unit of the cell radius.

input map name Name of the map on which the cell grid is drawn. Include the filename of the map only, do not include the file extension.

output map name Name for the modified map.

End of Table 38-3


38—UMTS

Linux: At the command prompt, enter the following command:

setenv LD_LIBRARY_PATH <reldir>/sys/pc_intel_linux/lib:$LD_LIBRARY_PATH

3 Change to <reldir>/models/std/umts, the umts directory.

4 Run cell_creator in the OPNET Modeler console (Windows) or at the command prompt (Linux).

cell_creator -input <longitude 1> <latitude 1> <longitude 2> <latitude 2> <radius> [miles | kilometers] <input map name> <output map name>

End of Procedure 38-1

Supported Configurations

You can configure your UMTS network model to use either of the following configurations:

• UMTS workstation nodes routing application traffic (e-mail, ftp,...) through one or more CN nodes to other UMTS workstation or server nodes, or to workstations and servers running over other technologies, such as Ethernet or WLAN.

• UMTS station nodes sending generic data traffic to other UMTS station nodes though a single or multiple SGSN nodes.

You cannot send application traffic to a UMTS station node, nor can you send traffic generated by a station node to a UMTS workstation or server node. When using the UMTS workstation nodes, use the application models to generate traffic as you would for any workstation node. See the application model documentation for additional information on configuring application traffic.

Using the station and SGSN nodes allow you to configure a traffic generation pattern that is not application-based. This avoids the need to use the application models when you are not interested in application-specific performance in the UMTS network. Consider using the station nodes and SGSN nodes when the following apply:

• You want to model raw traffic data within the UMTS network

• You are not interested in the external IP network

• You are not modeling CN to CN data transfer


38—UMTS

The following diagrams illustrate the supported types of UMTS network configurations:

Figure 38-3 Simple UMTS Network Using Application Traffic

Figure 38-4 Simple UMTS Network Using Raw Traffic Generation


38—UMTS

Model Architecture

The GPRS network architecture is shown in Figure 38-5. This section describes the nodes shown in Figure 38-5, including their process and node models.

Figure 38-5 UMTS Network Architecture

When a user powers-on, the model assumes that synchronization and a PS signalling connection are established. This PS signaling connection is kept for the entire simulation. Because of this, when a user powers-on it can immediately do a UMTS GPRS attach with the SGSN(s) to access to GPRS services.

Packets are queued when they are received from higher layers. Since each user supports four QoS profiles, the traffic is queued on one of four QoS queues. If no PDP context has been activated for that QoS profile, an Activate PDP Context Request is sent to the SGSN(s). This PDP context activation message includes the QoS requested. The model assumes that the SGSN(s), after consulting the RNC, either grants the QoS requested by the user in its entirety or rejects it. No negotiation by the SGSN/GGSN or RNC of the requested QoS is done at this stage.

On receipt of the Activate PDP Context Request, the SGSN(s) sends a RAB Assignment Request to the RNC along with the QoS requested. The UTRAN performs admission control to determine if the request can be granted. If the uplink and downlink have sufficient capacity to accommodate the request, the request can be granted. If the request can be granted, the RNC sends a Radio Bearer Setup request to the UE.


38—UMTS

On receipt of the Radio Bearer Setup request, the UE sets up the channel as specified in the request and sends a Radio Bearer Complete to the RNC. On receipt of the Radio Bearer Complete, the RNC sends a RAB Assignment Response, which includes the granted QoS, to the SGSN/GGSN. The SGSN(s) then sends the Activate PDP Context Accept message, which also includes the granted QoS.

The UE can send packets to the destination on receipt of the Activate PDP Context Accept message from the SGSN(s). Before reaching their destination, these packets are first tunneled through serving the RNC and SGSN/GGSN, then routed through the IP cloud. If the destination network is also a UMTS network, then they are finally queued at the destination SGSN/GGSN node. Once a channel is set up at the destination, the packets are forwarded to the destination UE.

UE Architecture

Three types of UEs are supported in the UMTS model: simple mobile stations (umts_station), advanced workstations (umts_wkstn), and advanced servers (umts_server). You can model your UE nodes as either fixed (fix) or mobile (mob). Use the mobile node when the UE you are modeling moves during the simulation. You can reduce simulation run times by using the fixed nodes to model UEs that do not move during simulation.

UE Node Model Architecture

The UMTS station model shown in Figure 38-6 includes an application layer that feeds directly into the GMM layer. It also includes the RLC/MAC layer, a radio transmitter and receiver, and one antenna.

The advanced workstation and server (Figure 38-6) include the full TCP(UDP)/IP protocol stack between the application layer and GMM layer.

The GMM layer contains functions from the GMM, GSM, and RRC layers. It has mobility management functions (such as GPRS attach), session management functions (such as PDP context activation), and radio resource control functions (such establishment and release of radio bearers). The RLC/MAC layer contains the RLC and MAC layers. It includes priority handling of data flows, the three types of RLC modes, and segmentation and reassembly of higher-layer packets.

The links between the radio transmitter and the RLC/MAC layer and between the radio receiver and the RLC/MAC layer represent transport channels. On the uplink, there can be one random access channel (RACH), one common packet channel (CPCH), and one dedicated channel (DCH) where signaling and data traffic converges. Each transport channel in the dedicated channel has a unique spread code that distinguishes it from other transport channels. On the downlink, there can be one forward access channel (FACH), one downlink shared channel (DSCH), one acquisition indicator channel (AICH), and one


38—UMTS

dedicated signaling channel per user, and up to four data channels. The number of signaling and data channels on the downlink is equal to the number of signaling and data channels on the uplink; the exception to this is the DSCH, which has one extra channel. Each channel is assigned a different spread code and traffic on all channels can be sent simultaneously.

Figure 38-6 Simple and Full-Protocol Stack UE Node Models

The RLC is assigned a logical channel according to an application’s DiffServ characteristics. MAC uses a queuing scheme in combination with logical channel weights/priorities to multiplex and schedule data from logical to transport channels. Logical channels transport control/data between L2/RLC and L2/MAC. Transport channels transport data between L2/MAC and L1. Users can map higher layer data to logical channels using either ToS or DiffServ priority handling, and multiplex logical channels to transport channels using a queuing scheme. This capability allows custom classes to be defined (i.e., prioritizing certain cell phone traffic sources over others), and increases the granularity of application performance metrics to observe scheduling behavior.

The queue structure at the GMM and RLC/MAC layers is shown in Figure 38-7. The GMM layer has four queues, one for each QoS class the UE can support. When a data packet from the application layer arrives at the GMM layer, it is forwarded to the RLC/MAC layer if a channel has already received a RAB setup message for the RAB of the packet’s QoS class. Otherwise, the packet is enqueued at the GMM layer in the queue corresponding to its QoS profile. The

umts_station: contains only traffic source/sink and UMTS layer

umts_wkstn and umts_server:contains full stack


38—UMTS

RLC/MAC layer uses queues to transmit packets coming from higher layers, to retransmit packets in RLC acknowledged mode, and to receive packets from lower layers and reassemble them to build the PDUs from these packets. Each category requires one queue for signaling and four queues for each QoS supported.

Figure 38-7 Queue Structure for GMM and RLC/MAC Layer at the UE Node

UE Process Model Architecture

The process models for the application layer of the UE station node model are shown in Figure 38-8 (umts_client_mgr) and Figure 38-9 (umts_client_child). When the umts_client_mgr process model is invoked—either at the start of a new session for a particular QoS class or when triggered by another user (passive session)—it spawns the umts_client_child process. The child process is killed when the session ends. There are as many simultaneous child processes opened, as there are simultaneous sessions active at the UE.

When peer-to-peer communication is enabled at the caller side, transfer is done in both directions. In this case, the application layer at the originating UE, referred to as the mobile origination, first starts an active session. To set up a channel, the mobile origination (MO) sends a SETUP message to the mobile

Data (QoS 0)

Data (QoS 1)

Data (QoS 2)

Data (QoS 3)

Signalling

Data (QoS 0)

Data (QoS 1)

Data (QoS 2)

Data (QoS 3)

Signalling

Data (QoS 0)

Data (QoS 1)

Data (QoS 2)

Data (QoS 3)

Signalling

Data (QoS 0)

Data (QoS 1)

Data (QoS 2)

Data (QoS 3)

UE—GMM/SM UE—RLC/MAC

Transmission buffers

Retransmission buffers

Reception/Reassembly buffers


38—UMTS

termination (MT). Once a channel is set up, the mobile termination sends a CONNECT message to the MO and starts sending data to MO. When the MO receives the CONNECT, it also starts sending data packets to MT. When peer-to-peer communication is not enabled, transfer occurs only in one direction. When a channel is setup on the mobile origination side, packets are sent directly to the mobile termination. No initial message sent to set up the channel on both sides as in peer-to-peer communication. Therefore, data packets are queued at the termination side until a channel is set up with the mobile termination.

Figure 38-8 umts_client_mgr—Application Manager Process for the UE Station Node

Figure 38-9 umts_client_child—Application Child Process for the UE Station Node

Figure 38-10 shows the process model for the UE’s GMM layer. Upon completion of GPRS attach, the UE waits in the CONNECTED state. As soon as the GMM layer receives packets from higher layers for a new QoS class, it sends a request to the SGSN to activate the PDP context. Once the PDP context is activated and a channel is set up, the UE can send packets to their destination. Modification of active PDP context is also supported. If the GMM


38—UMTS

layer receives packets from higher layers in the CONNECTED state when the PDP context is already activated but no radio bearer is set up, the UE sends a service request to SGSN. A channel is then set up and the UE can start sending packets to its destination. The radio bearer release and reconfiguration is also modeled in this process model. If the PS connection is released, the user moves to the IDLE state. The IDLE state and the RAU (Routing Area Update) state are not modeled in the current release.

Figure 38-10 umts_gmm—GMM Layer Process Model on the UE

Figure 38-11 shows the process model for the RLC/MAC layer, umts_rlc_mac. This process handles segmentation and reassembly of higher layers PDUs into and from smaller RLC PUs. It also handles transparent, unacknowledged, and acknowledged RLC modes. In unacknowledged and acknowledged RLC modes, umts_rlc_mac adds RLC and MAC headers to each PU. Packets coming from higher layers are buffered in different queues according to the channel a packet will be sent on. Packets are taken out of the buffer in each frame. If the frame boundary corresponds to the beginning of a transmission time interval (TTI) for that channel and the packet was received early enough to


38—UMTS

allow for processing time, the packet is segmented, RLC and MAC headers are added when appropriate, and the resulting packet is sent to the transmitter on the correct channel. For packets received from lower layers, packets are simply delayed by the processing time, and then forwarded to higher layers.

Figure 38-11 umts_rlc_mac Process for the UE’s RLC/MAC Layer

The RLC/MAC layer models all three RLC retransmission modes. For RLC Transparent Mode (TrM), Protocol Data Units (PDUs) from higher layers are segmented into smaller RLC Payload Units (PUs) and transparently transmitted to lower layers, and vice versa for reassembling PDUs from lower layers. There is no need to add RLC/MAC headers to or remove RLC/MAC headers from these packets. In RLC Unacknowledged Mode (UM), PDUs are segmented and reassembled, and RLC/MAC headers are added to each segment. Each segment is tagged with a sequence number but missing segments are not retransmitted.

For RLC Acknowledged Mode (AM), PDUs from higher layers are segmented into smaller RLC PUs, and RLC and MAC headers are added to each segment. Similarly, the RLC and MAC headers are removed from segments from lower layers, which are then reassembled into PDUs. As in the unacknowledged mode, each segment is tagged with a sequence number.

When the RLC/MAC layer of the receiving UE or RNC detects a missing segment, it sends a STATUS REPORT to the transmitting RNC or UE asking for the missing segment. On receipt of the STATUS REPORT from the receiver, the transmitting UE or RNC retransmits the missing segment. Retransmitted segments have higher priority than segments being transmitted for the first time. A segment can be retransmitted up to MAX_DAT times before it is discarded.


38—UMTS

When segment is discarded after the maximum number of failed retransmissions attempts, the channel is locked and is reset. The RLC AM reset procedure can be triggered at the UE or at the RNC and is handled differently in each case.

• For RLC AM reset cases at the UE—the affected channel is blocked and all data traffic intended for that channel is discarded. Other transport channels serving different QoS classes remain active unless they also encounter a reset situation.

• For RLC AM reset cases at the RNC—the affected logical/transport channel (identified by IMSI and QoS) is blocked and the radio bearer (RB) corresponding to that channel is released. The model also considers the possibility that the RB release procedure with the UE can also fail if the UE loses communication through the signalling channel. In these cases, the RB is released after a certain number of trials.

In both reset cases, the model does not support recovery from a reset situation—a channel blocked during reset will remain blocked for the remainder of the simulation.

The transmitter and receiver also have a Transmission Window Size and a Receiver Window Size. The Maximum Send state variable (VT(MS)) is equal to the Transmission Window Size plus the sequence number of the next in-sequence PU expected to be acknowledged (VT(A)) plus the sequence number of the next PU to be transmitted for the first time (VT(S)). The Maximum acceptable Receive state variable (VR(MR)) is equal to the Receiver Window Size plus the sequence number of the next in-sequence PU expected to be received. The number of segments sent to the receiver, but awaiting acknowledgement should not exceed the Transmission Window Size. Similarly, the receiver will not accept segments exceeding the Receiver Window Size from the transmitter, and discards excess segments.

The RLC Acknowledged Mode also uses several timers. STATUS REPORT messages are sent every Timer_Status_Periodic and each time a missing segment is detected at the receiver if the Missing_PU_indicator is set to TRUE. Every time a STATUS REPORT is sent, another timer Timer_Status_Prohibit is started. The receiver cannot send a STATUS REPORT while the Timer_Status_Prohibit is active. On expiry of Timer_Status_Prohibit, a STATUS REPORT is sent if Timer_Status_Periodic expired or missing segments were detected while Timer_Status_Prohibit was active.

Every segment sent by the transmitter for the first time is copied and saved in a retransmission buffer. When the transmitter receives an acknowledgement from the receiver, it removes the acknowledged segments from the retransmission buffer. If a segment stays in the retransmission buffer longer than Timer_Discard, it is discarded. This prevents build-up of buffer length at the transmitter when there are frequent retransmissions.


38—UMTS

Figure 38-12 shows the retransmission procedure in RLC acknowledged mode between the RNC (transmitter) and the UE (receiver) including the variables required to keep track of missing packets. In Figure 38-12, the Transmission Window Size and the Receiver Window Size are 8 PUs. When VT(S) and VT(MS) equal 8, the transmitter cannot send additional PUs until it receives an acknowledgement from the receiver. When the transmitter receives a STATUS REPORT, it retransmits the missing PUs and updates its VT(A) and VT(MS) variables based on the sequence number acknowledged in the STATUS REPORT.

Figure 38-12 RLC AM Retransmission

When the UE is in the CELL_FACH state, the RACH (random access channel) is used to transmit data in the uplink direction. When packets are buffered at the RLC/MAC layer, the RLC/MAC spawns the umts_rach process, which models the random access channel. The umts_rach process model, shown in

VR(R)=0, VR(H)=0, VR(MR)=8 VT(S)=0, VT(A)=0, VT(MS)=8

VR(R)=1, VR(H)=1, VR(MR)=9

VR(R)=2, VR(H)=2, VR(MR)=10

VR(R)=2, VR(H)=5, VR(MR)=10

VR(R)=2, VR(H)=9, VR(MR)=10

VR(R)=3, VR(H)=9, VR(MR)=11

VR(R)=4, VR(H)=9, VR(MR)=12

VR(R)=6, VR(H)=9, VR(MR)=14

VR(R)=7, VR(H)=9, VR(MR)=15

VR(R)=9, VR(H)=9, VR(MR)=17

VR(R)=10, VR(H)=10, VR(MR)=18

VT(S)=1, VT(A)=0, VT(MS)=8

VT(S)=2, VT(A)=0, VT(MS)=8

VT(S)=3, VT(A)=0, VT(MS)=8

VT(S)=4, VT(A)=0, VT(MS)=8

VT(S)=5, VT(A)=0, VT(MS)=8

VT(S)=6, VT(A)=0, VT(MS)=8

VT(S)=7, VT(A)=0, VT(MS)=8

VT(S)=8, VT(A)=0, VT(MS)=8

VT(S)=8, VT(A)=2, VT(MS)=10

VT(S)=9, VT(A)=2, VT(MS)=10

UE (rx) RNC (tx)

seq num = 0

seq num = 1

seq num = 2

seq num = 3

seq num = 4

seq num = 5

seq num = 6

seq num = 7

seq num = 8

seq num = 2

seq num = 3

seq num = 5

seq num = 6

seq num = 7

seq num = 9

status report (2,3)

…

status report (2,3,5,6,7)


38—UMTS

Figure 38-13, follows the slotted aloha contention algorithm. The process uses the preamble ramp-up procedure to begin sending preambles. Once it receives an acknowledge from the node B, umts_rach notifies the RLC/MAC so that data messages can be sent.

Figure 38-13 umts_rach Process Model on the UE

Node-B Architecture

The Node-B manages the network’s air interface for UEs in the same sector as the Node-B. There are both ATM and IP-enabled Node-Bs. The model suite includes a single-sector Node-B, a three-sector Node-B, and a six-sector Node-B. An RNC connects to one or more Node-Bs to communicate with the UEs of the network and to manage multiple calls.

Node-B Node Model Architecture

The Node-B node models include one node_b processor module for each sector it manages. The node_b processor module is connected to an ATM or IP protocol stack, a transmitter module, and a receiver module. Each packet stream between the node_b module and the transmitter represents a downlink channel and each stream between the node_b module and the receiver represents an uplink channel. In the downlink direction, packets are forwarded to the transmitter on the FACH or DSCH streams, or on the dedicated channel


38—UMTS

via op_pk_deliver(). In the uplink direction, all packets travel over the RACH, CPCH (not modeled in the current release), or DCH streams. All DCH packets converge at the DCH input stream, regardless of their channel or spreading code.

Figure 38-14 Node-B Node Model

Node-B Process Model Architecture

When the simulation starts, Node-Bs initialize the data structures used in the pipeline stages, sets radio transmitter and receiver attributes for all UEs and Node-Bs in the UMTS network (only the first Node-B to start performs this task), and initializes ATM-VC or IP connections to the RNC for each QoS class and signalling data channel.

Besides relaying packets between UEs and the RNC, the Node-B also assists the RNC with radio resource management through NBAP (Node-B Application Protocol) signalling messages. When the RNC receives a request to add a new radio link, it informs the Node-B of the addition of this link for the call. The Node-B then responds to the request with assigned spreading code for the radio link. A similar communication happens between Node-B and RNC for radio link deletions. RNC informs Node-B about the deletion request, and Node-B frees the spreading code assigned for that link, before responding to the RNC.


38—UMTS

When the RNC receives a request to modify a radio link, it informs Node-B of the modification of this link. Once complete, Node-B responds to the RNC.

Figure 38-15 umts_node_b Process Model

Node-B Repeaters

A repeater can be used to extend the coverage area of a Node-B cell, improve signal strength (especially in downlink), and get around physical obstacles. For example, UE travels from one cell to another through an area of coverage loss. With a repeater added to the first cell, UE can travel from one cell to another without losing connectivity.

Repeaters transmit received Node-B transmissions in the downlink direction, and UE transmissions in the uplink direction. Repeater transmissions add to interference in both directions, which must be considered in interference computations.

• Uplink: Interfere with simultaneous receptions at donor Node-B (unless fiber link to donor Node-B is used.) A given Node-B cell does not hear packets or interference from any repeaters to which it is not associated.

• Downlink: Interfere with simultaneous receptions at all UEs. A repeater only repeats packets with its donor Node-B cell.

A repeater forwards packets regardless of number of bit errors. Bit errors in packets received at the repeater are still present in the packet when it is received at the final destination (or next hop.)

Repeaters amplify received packets in accordance with repeater gain settings (may be different in uplink/downlink directions.) Each Node-B cell may have multiple associated repeaters.


38—UMTS

RNC Architecture

The RNC manages the resources of the air interface of all the UEs on Node-Bs serviced by the RNC. The RNC does the following management tasks:

• Coordinates the admission control process of establishing and tearing down RABs for UEs requesting service over various QoS classes.

• Finds needed resources for new requests by reorganizing the resource allocations and negotiating/renegotiating QoS parameters on new or already established RABs.

• Manages the handovers of UEs between its Node-B due to UE’s movements between the cells.

• Buffers packets destined for UEs per QoS class.

• Communicates with the SGSN(s) allowing the SGSN(s) to send and receive data to and from the UEs it services.

• Performs related tasks as the peer of the RLC and MAC layers of the served UEs.

• Monitors the activity on the established radio bearers to tear them down in case of inactivity.

RNC Node Model

The RNC Node model consists of the “RNC Manager” and three child processes that perform the functionality of the RNC. The RNC Manager has nine ATM or IP stacks attached to it, one of which connects to the SGSN(s) servicing the RNC. The other eight will connect to Node-B ATM or IP stacks. The RNC process models can determine which type of node exists at the other end of any given connection, so the RNC can connect any of these stacks to either a Node-B or SGSN so long as no more than one RNC connects to it and at least one Node-B connects to it. The total number of supported node-Bs can be increased by adding more ATM or IP stacks to the node structure.

Figure 38-16 RNC Node Model

ATM stackATM stackATM stack

IP stack

ATM stack ATM stack



38—UMTS

RNC Process Model

The model suite includes four process models: umts_rnc (the RNC Manager), umts_rnc_rlc_mac, umts_rnc_ranap_nbap, and umts_rnc_rrc.

Figure 38-17 RNC Model Root and Child Processes

Specifically:

• The umts_rnc_rlc_mac process implements Radio Link Control (RLC)/ Medium Access Control (MAC) functions.

• The umts_rnc_ranap_nbap process implements handle signaling with Node B Application Part (NBAP), and handle serving gateway support node (SGSN) signaling with Radio Access Network Application Part (RANAP), and

• The umts_rnc_rrc process implements initialization and user equipment (UE) signaling with Radio Resource Control (RRC) procedures, including admission control, handover, and mobility related procedures.

The umts_rnc_rlc_mac process receives stream/remote interrupts to the RNC module. Once created, it is responsible for invoking other child processes accordingly.

The umts_rnc_rlc_mac process maintains arrays of queues that each serve a specific purpose: transmission, reception, retransmission, segmentation, and reassembly. Each position in the array represents the set of buffers (or queues) that are assigned to a specific channel. Some of these channels are assigned and released dynamically during the simulation while others are assigned for the duration of the simulation. The RNC designates an equal number of slots in this array for each Node-B it services. A queue array created for a Node-B has the structure depicted in Figure 38-18.


38—UMTS

Figure 38-18 Queue Allocation Structure at the RNC

The active connections for the FACH/RACH and DSCH channels are stored in two distinct arrays.

When the simulation starts, the RNC dedicates slot 0 to the FACH/RACH and slot 1 to the DSCH, both of which point to the appropriate connection arrays. After startup of the UEs via the GPRS Attach procedure, the RNC establishes a signalling DCH for each UE. As the RNC creates DCHs, it dedicates slots in the array in the section it reserved for the Node-B serving the UE that the RNC establishes the channel for. As the simulation progresses and as the UEs send service request messages to get DCH RABs, the RNC creates channels for the new RABs that do not run over common channels. The RNC also designates unused slots in its queue arrays to service the UE’s newly established RABs. If the newly created RAB runs over common or shared channels, a new connection slot is assigned.

Figure 38-19 Sample Queue Allocation for an RNC

Node-B 0 Node-B 1 Node-B N...

FACH/RACH DSCH DCH DCH DCH DCH ...

ReassSegRetxRxTxBuffers

Connection 0 Connection 1 Connection MConnection 2 ...

ReassSegRetxRxTxBuffers

Queue array for Node-B 1

Connection array for FACH/RACH

[DSCH | DCH(UE0 sig) | DCH(UE1 sig) | DCH (UE0 QoS0) | DCH (UE1 QoS0)]




Tx

Retx

Seg

Reass


38—UMTS

Figure 38-20 umts_rnc and umts_rnc_rlc_mac Process Models

Figure 38-21 umts_rnc_ranap_nbap Process Model

Figure 38-22 umts_rnc_rrc Process Model

RANAP_MSG: RANAP control messageNBAP_MSG: NBAP control messageRRC_MSG = MOBILITY_MSG || RAB_RESP

umts_rnc_rlc_mac process model

umts_rnc process model


38—UMTS

CN Architecture

The model includes two options for modeling CN nodes:

• CN node models combine SGSN and GGSN functionality.

— Gateway CN node: generic gateway nodes that include SGSN and GGSN functionality

— Simple CN node: a simple SGSN node that includes UMTS functionality and packet-switching functionality between the SGSN’s UE station nodes

See CN Node Models.

• SSGN and GGSN node models let you model the CN components individually:

— GGSN nodes

— SGSN nodes: generic SGSN nodes that can connect to up to 8 RNCs and one GGSN

See SGSN Node Models and GGSN Node Models.

CN Node Models

The simple CN node model (Figure 38-23) includes the SGSN module and variable ATM stacks for communications with the RNCs. You can configure the nodes’s Network Delay attribute to model the delay that would be introduced by the network cloud between the source and destination UMTS network within the node model.

Figure 38-23 Simple CN Node Model: umts_sgsn


ATM stackATM stack



38—UMTS

The gateway CN node models, umts_ethernet_slip8_gtwy or umts_ethernet_slip8_large_gtwy, include the SGSN module, variable ATM stacks for communications with the RNCs, and a router node protocol stack with an IP module and IP interfaces running other layer-2 technologies.

Figure 38-24 Gateway CN Node Model

GGSN Node Models

The model suite includes three GGSN node models, umts_ggsn_slip8 umts_ggsn_atm8_ethernet8_slip8, and umts_ggsn_ethernet2_slip8. The GGSN node models are similar to the gateway CN node model, except that they do not include the SGSN module and ATM stacks. The GPRS Tunneling Protocol (GTP) runs in the IP module on these nodes and sets up GTP tunnels between the GGSN and SGSN.

SGSN Node Models

The model suite includes two SGSN node models, umts_sgsn_ethernet_slip and umts_sgsn_atm_ethernet_slip. The SGSN nodes are similar to the simple CN node model, except that they also include an ATM, Ethernet, or IP interface to connect to a GGSN node as Gn interfaces. The GPRS Tunneling Protocol (GTP) runs in the IP module on these nodes and sets up GTP tunnels between the SGSN and GGSN.

SGSN Module The SGSN module is modeled as a queue and is common to both CN nodes and to the SGSN nodes. The number of queues depends on the number of users in the cells and on the number of QoS classes supported per user. Data packets arriving at the CN node are queued when no PDP context has been activated for that QoS class or when no channel has been set up with


IP stack

ATM stackATM stack



38—UMTS

the terminating UE. The packets are queued by QoS class as shown in Figure 38-25. If the PDP context is already activated for the packet’s QoS class and if a channel is already set up, the packet is transparently forward to the RNC.

Figure 38-25 Queue Structure in the SGSN Module

CN Process Model

The process model that resides in the SGSN module of the CN node model is shown in Figure 38-26. The current model implements the GPRS attach procedure, PDP context activation, and RAB establishment and release. The paging state is used to receive data packets from the RNC or IP network.

The current release does not model the following:

• GPRS detach state

• PDP context deactivation state

• Security state

Data QoS0 (UE0)

Data QoS1 (UE0)

Data QoS2 (UE0)

Data QoS3 (UE0)

Data QoS0 (UE1)

Data QoS1 (UE1)

Data QoS2 (UE1)

Data QoS3 (UE1)

UE 0

UE 1


38—UMTS

Figure 38-26 SGSN Process Model

UMTS Timing

The following timing delays are modeled:

• Encoder delay

• Processing delay

• Buffering delay

• Propagation delay (configurable)

• IP delay (configurable)

Figure 38-27 shows how these delays are implemented in the model. The encoder delay represents all delay incurred by the encoder in the first and subsequent frames of a burst (Tdelay). At the RLC/MAC layer, data is first buffered for one transmission time interval (TTI), which can last from one to eight times the length of one radio frame (10-80 ms). Data is then processed (coded, interleaved,...).

The processing delay is the time required by the transmitter and receiver to process the packet. The processing delays at the UE, RNC, and SGSN/GGSN are labeled tpc1, tpc2, and tpc3, respectively.

At the UE and UTRAN, packets can be sent on a frame boundary if the channel is not already busy. For example, if a packet at the UE is received from higher layers at least tpc1 before the frame boundary, the packet can be sent at the next frame boundary, if it is available. Otherwise, it waits an additional transmission time interval.


38—UMTS

At the receiver, the buffering time (Tbuffer) represents the time needed by the receiver to buffer all of the radio frames required to decode the signal. The propagation delay is based on the distance and on the type of channel link: tpd1 represents the propagation delay between the UE and UTRAN and tpd2 represents the propagation delay between the UTRAN and SGSN/GGSN. The IP delay (tip) is the delay through the IP cloud.

Figure 38-27 Delay in RAN and CN Network

Radio-Air Interface

The Wireless module includes 13 pipeline stages to model the radio interface. You can model the air interface between the UE and the UTRAN by modifying some of these pipeline stages.

To model specific W-CDMA behavior, the following pipeline stages must be modified:

Received Power

The standard received power pipeline stage (dra_power.ps.c) is modified to include a path loss model and shadow fading model that depends on the environment (pedestrian outdoor, vehicular outdoor, indoor office).

The propagation path loss models are based on formulas specified by the International Telecommunications Union as shown below (Recommendation ITU-R M.1225 Guidelines for Evaluation of Radio Transmission Technologies for IMT-2000, 1997). The Hata model for frequency between 1500 MHz and 2000 MHz and the free space model are also supported. Shadow fading is modeled as a log-normal distribution with zero mean and a standard deviation depending on the environment but settable by the operator. The environment is settable by the operator.


38—UMTS

Vehicular Outdoor

where R is the distance between the mobile station and base station in kilometers, ∆hb is the base station antenna height (meters), and freq is the carrier frequency in MHz.

Pedestrian Outdoor

where R is the distance between the user and base station in kilometers, freq is the carrier frequency in MHz, and LpMax is valid in non-line-of-sight case and describes worst case propagation.

Indoor Office

where R is the distance between the user and base station in kilometers, n is the number of floors in the path, and LpMax is valid in non-line-of-sight case and describes worst case propagation.

Background Noise

The background noise pipeline stage (dra_bkgnoise.ps.c) includes thermal noise and noise figure of the mobile and base station receiver.

LpMax 40 1 4 10 3– hb∆⋅–( ) R10log 18 hb∆10log– 21 freq10log 80+ +=

LpMax 40 R10log 30 freq10log 49+ +=

LpMax 30 R 1000×( )10log 18.3n

n 2+n 1+------------ 0.46–⎝ ⎠⎛ ⎞

37+ +=


38—UMTS

Interference Noise

Interference noise is calculated in the following pipeline stages.

• RACH and AICH channels:

— umts_ue_dra_inoise

— umts_utran_dra_inoise

• DCH and FACH channels:

— umts_ue_dra_power

— umts_utran_dra_power

Bit Error Rate

The bit-error rate pipeline stage (dra_ber.ps.c) is modified to include the signal-to-noise ratio (SNR) versus block error ratio (BLER) curves that depend on the coding scheme and rate and transmission time interval for each transport channel, and the transport format combination chosen. The model supports convolutional codes rate half and rate third in AWGN and in multipath conditions with three equal paths and assumes perfect power control. Bounds on the BLER have been developed under these different conditions. These bounds have then been verified using detailed link-level simulations (to the chip level) of the W-CDMA air interface for uplink and downlink reference measurement channels as specified in [7]. Details on the air interface modeling are given in Appendix 1.

Air Interface Modeling

Error Probability Bounds for Convolutional Coding

A convolutional code has a “transfer function”.

Figure 38-28 Transfer Function for Convolutional Code

The coefficient is the number of alternative paths through trellis which differ in coded bit positions from the correct path; is sometimes called the Hamming distance between the two paths (or more precisely, between the code vectors associated with the paths).

The lower limit is known as the free distance, which is the minimum Hamming distance between the two alternative paths.

The exponent is the number of information bits that differ between two paths, which differ by a Hamming distance of .

T D N,( ) adDdNfd

d df=

∞

∑=

add d

df

fd d


38—UMTS

The union bound is an upper bound on the total probability of error. Assuming coherent detection and soft-decision Viterbi decoding, the union bound on the probability of choosing the wrong path through the trellis at a given stage is

where

If is the code rate, , where is the energy per symbol (coded bit) and is the energy per data bit. is the two-sided noise power spectral density, assumed to include other-user interference as well as thermal noise.

For a rate 1/n code, each stage in the trellis corresponds to a data bit (n coded bits), so the union bound on the block error probability, for a block of B bits, is

Pe adPe d( )

d df=

∞

∑ adQ2dEsN0

------------⎝ ⎠⎜ ⎟⎛ ⎞

d df=

∞

∑=≤

Q x( ) 12π

---------- e t2 2⁄– td

x

∞

∫=

r Es rEb= EsEb

20N

PB B adQ2dEsN0

------------⎝ ⎠⎜ ⎟⎛ ⎞

d df=

∞

∑≤


38—UMTS

The union bound on the bit error probability is

where .

The coefficients and depend on the specific code.

Clearly the larger the free distance , the better the code performance in general.

For rate-1/2 code:

For rate-1/3 code:

Pb adfdPe d( )

d df=

∞

∑≤ βdQ2dEsN0

------------⎝ ⎠⎜ ⎟⎛ ⎞

d df=

∞

∑=

βd adfd=

ad{ } fd{ }

df

df 12=

df 18=


38—UMTS

The coefficients and are shown for the two codes in the tables below, and Figure 38-29 on page SPM-38-42 shows the union bounds on block error rate vs. Eb/N0 for a block length of bits, for the two rates.

Table 38-4 Transfer Function Coefficients for Rate-1/2 Convolutional Code

12 11 33

14 50 281

16 286 2179

18 1630 15,035

20 9639 105,166

22 55,152 692,330

24 320,782 4,580,007

26 1,859,184 29,692,894

28 10,777,264 190,453,145

End of Table 38-4

Table 38-5 Transfer Function Coefficients for the Rate-1/3 Convolutional Code

18 5 11

20 7 32

22 36 195

24 85 564

26 204 1473

28 636 5129

30 1927 17,434

32 5416 54,092

34 15,769 171,117

End of Table 38-5

ad{ } βd{ }

B 100=

d ad βd

d ad βd


38—UMTS

As can be seen, the curves can be closely approximated by first-order regression lines of the form:

where and are as shown in the graph below.

Since the bound on is proportional to the block length ,

and

Thus, in terms of the specific coefficients derived from the curves,

For a specific target block error rate, therefore, the required is closely approximated as:

PB b0 b1 Eb N0⁄( )dB+≅log

b0 b1

PB B

PB B P100 100⁄⋅=

PBlog P100log Blog 2–+=

PBlog Blog b0 2– b1 Eb N0⁄( )dB⋅+ +=

Eb N0⁄

Eb N0⁄( )dB

Blog b0 2– PBlog–+

b1–------------------------------------------------------≅


38—UMTS

Figure 38-29 Block Error Rate (Union Bound) for Rates 1/2 and 1/3 Convolutional Codes

For the specific cases of interest here, this becomes:

Figure 38-30 Rate 1/2

Eb N0⁄( )dB

Blog 0.35 PBlog–+

1.71--------------------------------------------------≅


38—UMTS

Figure 38-31 Rate 1/3

Signal Flows

GPRS Attach

For completeness, the entire GPRS Attach procedure without prior CS (Circuit Switched) traffic is shown in Figure 38-32. However, the model assumes (and does not explicitly model) that a PS signaling connection is already established at power-on. The GPRS Attach procedure is performed to inform the SGSN(s) of a user’s location and to set up a PS signaling connection. Once a PS signaling connection is established, the UE and SGSN(s) move from the PMM-Detached State to the PMM-Connected State.

The PS signaling connection includes the RRC signaling connection between the UE and UTRAN, and the Iu signaling connection between the UTRAN and CN. If there has been no prior CS traffic, a signaling connection is set up between the UE and UTRAN. Once an RRC signaling connection is established between the UE and UTRAN, a Service Request (signaling) message is sent to the SGSN(s) to set up the Iu connection between the UTRAN and SGSN. Once the PS signaling connection is established, the UE initiates the GPRS Attach procedure by sending a GPRS Attach Request message to the SGSN(s). The GPRS Attach Request includes the Follow On Request indication that indicates that the Iu connection should be released or kept after the GPRS Attach procedure. At this stage, the model assumes that the PS signaling connection is maintained for the duration of the simulation.

Figure 38-32 GPRS Attach with no Prior CS Traffic

Eb N0⁄( )dB

Blog 0.67– PBlog–

1.54-------------------------------------------------≅


38—UMTS

Here is how OPNET Modeler explicitly models GPRS attach signalling:

1) UE initiates the GPRS Attach procedure by sending a GPRS Attach Request (IMSI, Attach Type, Follow On Request) message to the SGSN. UE starts timer T3310 when sending the GPRS Attach Request message. The Attach Type is set to GPRS Attach only and the Follow On Request indication is set to keep the Iu connection.

2) Upon receipt of the GPRS Attach Request message, the SGSN sends the UE an Attach Accept (P-TMSI) message and starts timer T3350. In the current model, P-TMSI is always included in the Attach Accept message.

3) Upon receipt of the GPRS Attach Accept message, the UE stops timer T3310 and responds to the SGSN with an GRPS Attach Complete message.

On receipt of the GPRS Attach Complete message, the SGSN stops timer T3350, which completes the GPRS Attach procedure.

PDP Context Activation and RAB Assignment (MS-Connected State)

The PDP Context Activation procedure is required when the PDP context for the requested class of service is inactive. Figure 38-33 and Figure 38-34 show the PDP Context Activation procedures initiated by the UE and CN, respectively. If the UE is in PMM-Idle State, the UE first performs a Service Request Procedure to set up a PS signalling connection and enter the PMM-Connected State before initiating the PDP Context Activation procedure. Once the GPRS Attach procedure is completed, the UE remains in the PMM-Connected State for the rest of the simulation.

Figure 38-33 PDP Context Activation Procedure Initiated by the UE (Connected State)

1) When the UE receives Protocol Data Units (PDUs) from higher layers, it initiates the PDP Context Activation Procedure if the PDUs belong to a quality of service that does not yet have an activated PDP context. The UE initiates the PDP Context Activation procedure by sending an Activate PDP


38—UMTS

Context Request (PDP Type, QoS Requested) message to SGSN. The UE starts T3380 when sending an Activate PDP Context Request message. In the model, only one PDP Context per QoS is set up and the PDP Type corresponds to the QoS requested.

2) On receipt of the Activate PDP Context Request, the SGSN sends a RAB Assignment Request message to the RNC (Radio Network Controller) to establish a RAB (Radio Access Bearer). The SGSN starts the TRABAssgt timer when sending a RAB Assignment Request message.

3) On receipt of a RAB Assignment Request message, the RNC performs admission control. If sufficient uplink and downlink capacity is available, the RNC establishes the appropriate radio bearer by sending a Radio Bearer Setup message to the UE.

4) On receipt of a Radio Bearer Setup message, the UE sets up the appropriate radio bearer as specified by the RNC. The UE then sends a Radio Bearer Complete message to the RNC.

5) On receipt of the Radio Bearer Complete message, the RNC sends a RAB Assignment Response message to the SGSN.

6) On receipt of a successful RAB Assignment Response, the SGSN normally sends a Create PDP Context Request (PDP Type, QoS Negotiated) to the GGSN. However, since the SGSN and GGSN are modeled as a single node, this procedure is not modeled. However, a new entry in the PDP context table is created as would be done at the GGSN. When completed, the SGSN sends an Activate PDP Context Accept message to the UE. If the RAB Assignment procedure is unsuccessful because the requested QoS profile cannot be provided, the UE tries to activate the PDP Context at a later time. Because the model always negotiates a QoS that matches the QoS Requested, the SGSN model does not send a new RAB Assignment Request message with a different QoS profile. On receipt of a RAB Assignment Response, the SGSN stops the TRABAssgt timer.

7) The UE stops the T3380 timer on receipt of an Activate PDP Context Accept message, completing the PDP Context Activation procedure. The UE is now ready to send any PDUs with a QoS matching the PDP context it has activated.


38—UMTS

Figure 38-34 PDP Context Activation Procedure Initiated by the Network (Connected State)

8) Since the SGSN and GGSN are modeled as a single node, the PDU Notification procedure is not modeled. Instead, the combined SGSN/GGSN node initiates the Network-Requested PDP Context Activation procedure by sending a Request PDP Context Activation message to the UE. It starts T3385 when sending the Request PDP Context Activation message. The combined SGSN/GGSN stores any subsequent PDUs for the same quality of service until the PDP context has been activated.

9) On receipt of the Request PDP Context Activation message, the UE initiates the PDP Context Activation procedure, as described above. The CN stops T3385 on receipt of the Activate PDP Context Request message from the UE.

RAB Assignment with Prior PDP Activation (MS-Connected State)

If an active PDP context for the requested QoS already exists, the PDP Context Activation procedure is not required. However, if there is no radio access bearer for the active PDP context, the RAB Assignment procedure must be initiated. Figure 28 and 29 show the RAB Assignment procedure initiated by the UE and CN, respectively when a PDP context for the requested QoS is already active. If the UE is in the PMM-Idle State, the UE first needs to perform a Service Request Procedure to set up a PS signalling connection and enter the


38—UMTS

PMM-Connected State before initiating the RAB Assignment procedure. Once the GPRS Attach procedure is completed, the UE remains in the PMM-Connected State for the rest of the simulation. Thus, the diagrams assume that the UE is already in PMM-Connected State.

Figure 38-35 RAB Assignment Procedure Initiated by the UE (Connected State)

1) On receipt of PDUs from higher layers, the UE initiates the RAB Assignment procedure if these PDUs belong to a quality of service for which a PDP context has already been activated but for which no radio bearer has been established. The UE initiates the RAB Assignment procedure by sending a Service Request (P-TMSI, Service Type) message to the SGSN. Service Type specifies the requested service. Service Type can be set to Data or Signaling. In this case, the Service Type is set to Data. The UE starts T3317 when sending the Service Request message.

2) On receipt of the Service Request, the SGSN sends a Service Accept message to UE. The UE stops its timer T3317 on receipt of the Service Accept message.

3) On receipt of the Service Request (Data), the SGSN initiates the RAB Assignment procedure by sending a RAB Assignment Request to the RNC. The RAB Assignment procedure was previously described.

Figure 38-36 RAB Assignment Procedure Initiated by the Network (Connected State)


38—UMTS

4) On receipt of PDUs, the CN determines if the Network-Requested PDP Context Activation procedure has to be initiated. Since a PDP Context is already active for the quality of service requested, the combined CN node initiates the RAB Assignment procedure previously described.

PDP Context Modification with RAB Modification

The signaling flow for PDP context modification with RAB modification are shown in the following diagram:

Figure 38-37 Signal Flows for PDP Context Modification with RAB Modification

1) The RNC modifies an existing RAB by sending a RAB Modification request to the SGSN.

2) On receipt of the RAB Modification request, the SGSN initiates a PDP Modification procedure by sending a PDP Context Modification request to the UE. The SGSN starts its timer T3386.

3) On receipt of the PDP context modification request, the UE responds to the SGSN with a PDP Context Modification Accept message.

4) On receipt of the PDP Context Modification Accept message from the UE, the SGSN modifies the appropriate RAB by sending a RAB Assignment request (Modification) to the RNC. The SGSN stops its timer T3386 and starts the timer TRABAssgt.


38—UMTS

5) On receipt of the RAB Assignment request (Modification), the RNC modifies the appropriate radio bearer by sending a Radio Bearer Reconfiguration message to the UE.

6) On receipt of the Radio Bearer Reconfiguration message, the UE reconfigures the appropriate radio bearer as specified by the RNC. The UE then sends a Radio Bearer Complete (Reconfiguration) message to the RNC.

7) On receipt of the Radio Bearer Complete (Reconfiguration) message, the RNC modifies the appropriate radio link by sending a Radio Link Reconfiguration message to the node B.

8) On receipt of the Radio Link Reconfiguration message, the node B reconfigures the appropriate radio link as specified by the RNC. The node B then responds to the RNC with a Radio Link Reconfiguration Response message.

9) On receipt of the Radio Link Reconfiguration Response, the RNC sends RAB Assignment Response (Modification) message to the SGSN.

10) On receipt of the RAB Assignment Response (Modification) message, the RNC modifies the appropriate PDP context. The SGSN stops its timer TRABAssgt.

RNC to Node-B Signal Flow

The signalling messages for adding and deleting a radio link are shown in the following diagram:

Figure 38-38 Signal Flows for Adding and Deleting a Radio Link

Adding a Radio Link Deleting a Radio Link

Node-B RNC

NBAP Radio Link

Add Request

NBAP Radio Link Add Response

Node-B RNC

NBAP Radio Link

Delete Request

NBAP Radio Link Delete Response


38—UMTS

Signal Flows for Hard Handover

Figure 38-39 illustrates the signalling messages used in hard handover.

Figure 38-39 Signaling Messages for Hard Handover

GMM RLC/MAC

Node-B RNC

Uu InterfaceLayer1 Mgr Iub Interface

UE

measurement report

measurement reportadmission to the new cell

NBAP RL Add Request

NBAP RL Add Response

RRC Physical Channel Reconfiguration Complete

RRC Physical Channel Reconfiguration

NBAP RL Delete Request

NBAP RL Delete Response

CRLC Configuration Request

Resource released from old cell for new admissions


38—UMTS

Signal Flows for Soft Handover

Figure 38-40 illustrates the signalling messages used in soft handover.

Figure 38-40 Signaling Messages for Soft Handover: In Case of Event 1C (Cell Replacement)

GMM RLC/MAC

Node-B RNC

Uu InterfaceLayer1 Mgr Iub Interface

UE

measurement report

measurement reportadmission to the new cell(s)

NBAP RL Add Request(s)

NBAP RL Add Response(s)

RRC Active Set Update Complete

RRC Active Set Update

NBAP RL Delete Request(s)

NBAP RL Delete Response(s)

CRLC Configuration Request

Resource released from old cell(s) for new admissions


38—UMTS

Model Interfaces

The following sections describe topics needed to interface with the UMTS model.

Packet Formats

The UMTS model suite uses the following packet formats. See the descriptions provided (in the Packet Editor) for each packet field for more details.

Table 38-6 Packet Formats

Packet format Description

umts_L1_pdu.pk.m Physical layer packet.

umts_client_message.pk.m Station UE data packet.

umts_clock.pk.m Clock packet used to synchronize UEs with the RNC that services it.

umts_crlc_config_req.pk.m Packet carrying channel configuration data from the UE's GMM to the UE's RLC/MAC.

umts_gmm_attach_accept.pk.m GPRS attach accept packet.

umts_gmm_attach_comp.pk.m GPRS attach complete packet.

umts_gmm_attach_req.pk.m GPRS attach request packet.

umts_gmm_service_accept.pk.m Service accept packet.

umts_gmm_service_reject.pk.m Service reject packet.

umts_gmm_service_req.pk.m Service request packet.

umts_gsm_activate_pdp_accept.pk.m PDP activation accept packet.

umts_gsm_activate_pdp_reject.pk.m PDP activation reject packet.

umts_gsm_activate_pdp_req.pk.m PDP activation request packet (UE to SGSN).

umts_gsm_mod_pdp_accept.pk.m Modify PDP Context Accept.

umts_gsm_req_pdp_activation.pk.m Request for PDP activation request packet (SGSN to UE).

umts_mac_pdu.pk.m MAC layer packet.

umts_nbap_rl_add_req.pk.m NBAP radio link addition request packet.

umts_nbap_rl_add_resp.pk.m NBAP radio link addition response packet.

umts_nbap_rl_del_req.pk.m NBAP radio link addition request packet.


38—UMTS

umts_nbap_rl_del_resp.pk.m NBAP radio link deletion response packet.

umts_pdcp_pdu.pk.m PDCP PDU packet.

umts_ranap_rab_assgn_req_release.pk.m RANAP RAB assignment (release) packet.

umts_ranap_rab_assgn_req_setup.pk.m RANAP RAB assignment (setup) packet.

umts_ranap_rab_assgn_resp.pk.m RAB modify request.

umts_ranap_rab_mod_req.pk.m RANAP RAB response packet.

umts_ranap_rab_release_req.pk.m RANAP RAB release request packet (UTRAN to SGSN).

umts_rlc_am_pdu.pk.m Acknowledged mode PDU packet (RLC layer).

umts_rlc_status_pdu.pk.m Status PDU for acknowledged mode transmissions packet (RLC layer).

umts_rlc_um_pdu.pk.m Unacknowledged mode PDU packet (RLC layer).

umts_rrc_conn_setup.pk.m Radio resource control connection setup packet.

umts_rrc_measurement_report.pk.m Measurement report packet (UE to UTRAN) packet.

umts_rrc_phy_chnl_reconfig.pk.m Physical channel reconfiguration request packet.

umts_rrc_phy_chnl_reconfig_comp.pk.m Physical channel reconfiguration complete packet.

umts_rrc_rb_comp.pk.m RB procedure complete packet.

umts_rrc_rb_release.pk.m RB release packet.

umts_rrc_rb_setup.pk.m RB setup packet.

End of Table 38-6

Table 38-6 Packet Formats (Continued)

Packet format Description


38—UMTS

ICI Formats

The following table lists the interface control information (ICI) formats used in the UMTS model suite.

Debugging/Simulation Tracing

The UMTS model provides several simulation runtime tracing and debugging features. These include labeled traces and diagnostic block code execution when simulation is run under the control of the OPNET simulation debugger (ODB).

The following table lists the various label traces you can use in ODB to view the behavior of the UMTS models.

Table 38-7 ICI Formats

ICI Description

umts_control_pkt_ici Contains modeling information for signaling packets.

umts_data_pkt_ici Contains modeling information for data packets.

umts_rrc_conn_setup Contains modeling information used when establishing RRC connections.

End of Table 38-7

Table 38-8 UMTS Traces

Use this trace label... To print information about...

umts_atm umts_atm_iface process model

umts_attach GPRS attach procedure

umts_gmm umts_gmm process model

umts_layer1_mgr umts_layer1_mgr process model

umts_node_b umts_node_b process model

umts_rab RAB procedures

umts_rlc_mac umts_rlc_mac process model

umts_sgsn umts_sgsn process model

umts_utran RNC process models

umts all of the above

End of Table 38-8


38—UMTS

Model Attributes

Local Attributes

Local attributes apply to individual nodes in the network model. This section lists the most important model attributes for the UE, Node-B, RNC, CN, and Repeater node models. For detailed information about a particular attribute, see its description by clicking on the Details button in the Attributes dialog box.

UE Attributes

.

Table 38-9 UE Attributes

Use This Attribute… To…

UE IMSI Specify the International Mobile Subscriber Identity of the UE. You should set this attribute if you need to specify a source and destination for traffic that is going to be generated between station UE nodes.

UE Serving SGSN ID Specify the CN Identifier of the CN (SGSN) node that the UE should attach to (applies only to workstation and server UE nodes). When auto-assigning IP addresses, the model uses this attribute value to ensure that the UE is in the same IP subnet as the CN node. If the network modeled contains only one CN, no configuration is necessary since the default value of all SGSN IDs and UE Serving SGSN IDs is 0.

UMTS GMM Timers Specify the following timers:

• T3310, which starts when the UE sends a GPRS attach request message.

• T3380, which starts when the UE sends an activate PDP context request message to the SGSN.

• T3317, which starts when the UE sends a service request message to the SGSN.

UMTS Logical Channel Configuration

Specify channel mapping type, logical channel assignments, and MAC queuing scheme (priority and weight details).

UMTS PDCP Compression Configure the PDCP Header Compression feature on the UE node for uplink transmissions.

If activated, IP/UDP and TCP/IP headers will be compressed for all higher layer packets arriving to the UMTS layer. Header compression ratio is computed based on the configured probability distribution function and its argument(s). Notice that just UDP/IP compression will be used for UMTS station models.

A different compression ratio can be specified for IP/UDP and TCP/IP cases.

QoS Profile Configuration Configure each UMTS service class (conversational, streaming, interactive, and background). The majority of UMTS QoS profile configuration attributes are described below.


38—UMTS

Node-B Attributes

Allocation/Retention Priority

(sub-attribute of QoS Profile Configuration)

Configure parameters for the allocation and retention of a RAB during admission control. Use this attribute to enable queuing for the RAB request, and to specify if the RAB request can preempt or be preempted by other requests.

Bit Rate Config


Specify the expected maximum and guaranteed bit rates for the uplink and downlink communication. These values need to be specified carefully. A too low value may cause consistent saturation of the QoS buffer and hence the loss of communication. A too high value would cause resource wastage in the cells with which the UE has established radio links.

Delivery Order


Specify if SDUs must be delivered in order. When set to Yes, this attribute ensures that SDUs are delivered to higher layers in sequence.

UMTS RACH QoS to ASC Mapping

Map the QoS classes to RACH access service classes available in the current cell.

UMTS RLC Processing Time Specify the Reliable Link Control processing time, which is primarily due to software processing and information transfer within nodes. The default value is15ms for uplink and downlink communication. (modeled on 3G TR 25.853)

UMTS UE Cell State Specify the state the UE is in, CELL_FACH or CELL_DCH.

End of Table 38-9

Table 38-9 UE Attributes (Continued)


Table 38-10 Node-B Attributes


Serving RNC ID Specify ID of the RNC in the scenario that acts as its network controller.

UMTS CPICH Transmission Power

Specify the transmission power of the Node-B common pilot channel in Watts. This is a key parameter of cell evaluation (and consequently handover procedures).

UMTS Cell ID Specify an identifier for the Node-B and the cell that it is associated with, which can be useful to identify the cells in the debugger.

UMTS Cell Pathloss Parameters

Specify the environment around the Node-B. The environment settings determine how the model computes cell pathloss. (Based on UMTS 30.03 TR 101 V3.2.0)


38—UMTS

RNC Attributes

Shadow Fading Standard Deviation

(sub-attribute of UMTS Cell Pathloss Parameters)

Specify the standard deviation of the log normal distribution used to model shadow fading of the antenna signal. Typical attribute values are 12dB for indoor environments and 10dB for outdoor and vehicular environments.

Pathloss Model

(sub-attribute of UMTS Cell Pathloss Parameters)

Specify the surrounding environment (Vehicular, Pedestrian, Indoor Office,...), which defines the path loss model used for the cell.

Number of Floors

(sub-attribute of UMTS Cell Pathloss Parameters.

specify the number of floors when using Indoor office Environment in the Pathloss Model. Set this attribute to Not Used for other path loss models.

UMTS FACH Transmission Power

Specify the FACH transmission power of the surrounding Node-B. The FACH transmission power can be explicitly configured in watts or it can be computed as distance-based to cover an imaginary circle of the specified radius around the Node-B.

End of Table 38-10

Table 38-10 Node-B Attributes (Continued)


Table 38-11 RNC Attributes


RNC ID ID of the RNC on the UTRAN. In order for a Node-B to communicate with this RNC over a network connection, it is necessary to set the Serving RNC ID on the Node-B to this RNC's ID.

UMTS RNC Handover Parameters Configure the RNC to support hard or soft handovers and the parameters used in handover decisions. Based on TR 25.922.

UMTS RNC Admission Control Parameters

Specify parameters (such as uplink and downlink loading factors and maximum available power) used to compute uplink and downlink capacity in the admission control algorithm.

UMTS RNC Timers Configure RNC Timers

Processing Time

(sub-attribute of UMTS RNC Timers)

Specify how long packets are delayed for processing at the RNC. This attribute does not include the time required for buffering on a transmission time interval. (Based on 3GPP TR 25.853)

Tinactivity (Data Channel)


Specify the maximum length of time a radio bearer can be inactive before it is released.

Tinactivity (Signaling Channel)


Specify the maximum length of time a radio signal can be inactive before it is released.


38—UMTS

Tqueuing


Specify the maximum time a RAB assignment for setup can be queued during admission control. If the assignment is not served within this time, it is discarded.

UMTS RNC Channel Configuration Configure dedicated, common, and shared transport channels carrying data and signaling traffic. For data channels, you can configure channel parameters for each UMTS service class. The main transport channel attributes are described below. Note that the configurable transport channel parameters depend on the channel type. For example, RB Mapping info does not apply to common channels because it is specified on a per-UMTS-class basis for the UEs in CELL_DCH state.

RLC Info

(sub-attribute of UMTS RNC Channel Configuration Signaling Channel Config)

Configure parameters for radio link control operations.

UL RLC Mode and DL RLC Mode

(sub-attributes of RLC Info)

Specify the RLC mode used on the uplink (UL) and downlink (DL) channels. Because retransmissions triggered by TCP can incur larger delay in the unacknowledged mode, using an RLC in the acknowledged mode may reduce response times when TCP is running over a noisy channel.

Transmission Window Size and Receiving Window Size

(sub-attributes of RLC Info)

Specify the number of RLC PUs that can be sent or received without an acknowledgement. This attribute applies only to the RLC Acknowledged Mode.

RLC Discard Info

(sub-attribute of RLC Info)

Specify the timers used to determine when and how packets in the transmitter’s RLC buffer are discarded.

In-Sequence Delivery


Specify if the RNC preserves the order of packets received from higher layers. When this attribute is set to “No”, the RNC forwards packets to the SGSN as they are received. When this attribute is set to “Yes”, the RNC will only send packets to the SGSN in sequenced order. That is, if the RNC receives packet 21 but has not received packet 20, it will hold packet 21 until it receives and forwards packet 20 to the SGSN or until it realizes that packet 20 will never be fully received and sent to the SGSN.

DL RLC Status Info


Specify how often downlink status reports are sent from the RNC to the CN. When the Missing PU Indicator sub-attribute is set to True, status reports are sent out each time a missing PU is detected, subject to the maximum and minimum intervals permitted between status reports. These maximum and minimum values are specified by the Timer Status Periodic and Timer Status Prohibit sub-attributes, respectively.

Timer Status Prohibit

(sub-attribute of DL RLC Status Info)

Specify how often the RNC checks to see if it should send status reports to the UEs. Once the time specified by this attribute has elapsed, the RNC determines if it needs to send status reports to UEs. If a status report is required, the RNC sends the report and resets this timer.

Table 38-11 RNC Attributes (Continued)



38—UMTS

Missing PU Indicator


Specify if a missing PU triggers the RNC to send a status report to the UEs. After the Timer Status Prohibit timer elapses, the RNC checks to see if a missing PU was detected. When this attribute is set to “True”, the RNC will send a status report to the appropriate UEs if it detects a missing PU. When this attribute is set to “False”, missing PUs do not trigger a status report.

Timer STATUS Periodic


Define how often the RNC sends status reports to UEs if it detects missing PDUs. The RNC starts this timer when it receives its first AM packet and the timer is continually reset after expiration. Upon detection of a missing PDU, this timer triggers a status report to be sent at the end of the current Timer Status Prohibit timer.

RB Mapping Info

(sub-attribute of Transport channel Parameters)

Configure the parameters required to map the radio bearers to different channel types for the UEs that are in CELL_DCH state. The radio bearers for UEs in CELL_FACH state are mapped to FACH and RACH for down link and uplink, respectively.

UL TrChnl Info and DL TrChnl Info

(sub-attribute of Transport channel Parameters)

Define parameters required to compute the channel data rate from the information rate based on the channel coding employed. Currently, the model supports convolutional channel coding types, with puncturing.

UMTS to ATM QoS Mapping Define the QoS of each ATM SVC that carries a particular class of UMTS traffic.

Scheduling Weights Assign weights to each QoS class for use in the FACH’s weighted round-robin scheduling algorithm.

UE ID Type Specify the format of the UE identification number used over FACH communications. Both C-RNTI (16-bit) and U-RNTI (32-bit) are supported.

AICH Transmission Timing Set the timing relation between PRACH and AICH channels.

ASC Parameters Configure the RACH access service classes that define the level of service for RACH procedures.

End of Table 38-11

Table 38-11 RNC Attributes (Continued)



38—UMTS

CN Attributes

Table 38-12 CN Attributes


UMTS CN ID Define the CN identifier, which is used by IP Auto-Addressing to ensure that the UEs connected to this CN are in the same IP subnet. All nodes bearing the same CN ID or UE CN ID are assigned to the same IP subnet. Note that each CN must have a unique CN ID.

UMTS CN Timers Specify timers used in the operation of the CN.

T3350

(sub-attributes of UMTS CN Timers

Specify the length of the GPRS attach timer.

TRABAssgt


Specify the length of the RAB assignment timer.

T3385


Specify the length of the PDP activation timer.

T3386


Specify the length of the retransmission timer for MODIFY PDP CONTEXT request.

Processing Time


Specify the processing time for data services, transcoding, and so on.

Maximum Retry on Timer Expiry


Specify the maximum number of times a signaling message is sent after the RAB assignment timer expires.

End of Table 38-12


38—UMTS

Repeater Attributes

Table 38-13 Repeater Attributes


Donor Node-B Cell ID Specify Node-B cell to which repeater has directional link. Required to associate repeater with its donor Node-B cell.

Downlink Gain Specify repeater gain (amplification) of a signal from Node-B to UE.

Downlink Packet Loss Ratio Specify probability used to determine if a packet is dropped while going from Node-B to repeater.

Max Downlink Transmit Power

Specify maximum transmit power from repeater to UE.

Max Uplink Transmit Power Specify maximum transmit power from repeater to Node-B. (Used to calculate interference with other UE packets received at Node-B.)

Node-B Connection Technology

Specify type of link used between repeater and its donor Node-B. Can be either a directional radio link (Air) or an optical fiber link (Fiber.) Impacts interference calculation at Node-B.

Noise Figure Specify magnitude of noise generated by repeater.

Uplink Gain Specify repeater gain (amplification) of a signal from UE to Node-B. (Used to calculate interference with other UE packets received at Node-B.)

Uplink Packet Loss Ratio Specify probability used to determine if a packet is dropped while going from repeater to Node-B.

End of Table 38-13


38—UMTS

Simulation Attributes

Unlike local attributes, which apply to individual nodes, simulation attributes apply collectively to all nodes in the network. The UMTS model suite has the following simulation attributes.

Table 38-14 Simulation Attributes

Attribute Description

UMTS UE Mobility Distance Threshold

This attribute defines the shortest (distance) movement of a UE that triggers an update of the tables tracking UE location and related parameters. In other words, the UE is considered to be in the same location as long as it does not move more than the threshold distance away from its last recorded location.

This attribute does not affect simulations that use only fixed nodes.

UMTS Sim Efficiency Mode There are two simulation efficiency modes:

• None—efficiency mode is not active,

• Constant BLER—disables outer loop power control and uses the initial BLER negotiated for each radio link (at the start of the connection) for the remainder of the simulation. This mode reduces simulation run times avoiding repeated power and interference calculations.

End of Table 38-14


38—UMTS

UMTS Statistics

To analyze the performance of your UMTS network, you can collect several statistics during a simulation.

Node Statistics

The following UMTS node statistics are available. For details on a particular statistic, see its description by right-clicking on the statistic name in the Choose Results dialog box and selecting View Description from the pull-down menu.

Table 38-15 Node Statistics

Statistic Group Statistic Name

Repeater Normalized Downlink Transmitted PowerNormalized Uplink Transmitted PowerTotal Downlink Received Power (dBm)Total Uplink Received Power (dBm)Total Uplink Throughput (bits/sec)Total Downlink Throughput (bits/sec)

UMTS Cell (recorded by Node-B model)

Active Data DCH CountTotal Downlink Throughput (bits/sec)Total Downlink Throughput (packets/sec)Total Uplink Throughput (bits/sec)Total Uplink Throughput (packets/sec)Received Total Wide Band Power (dBm)Transmitted Carrier PowerActive Signaling DCH Count

UMTS CN Total Number Requests GrantedTotal Number Requests QueuedTotal Number Requests ReleasedPDP Context Modification Delay (sec)Percent of Total Renegotiated RABsTotal Number Requests NegotiatedTotal Number Requests RejectedTotal Number Requests Renegotiated

UMTS CN (per QoS) CN-CN Delay (sec)Number of Requests GrantedNumber of Requests NegotiatedNumber of Requests QueuedNumber of Requests RejectedNumber of Requests ReleasedNumber of Requests RenegotiatedPercent of Renegotiated RABsTotal UTRAN-CN Delay (sec)UTRAN-CN Delay per ATM Link per QoS (sec)

UMTS CN ATM VC LoadThroughputUtilization


38—UMTS

UMTS GMM GPRS Attach DelayPDP Context Activation DelayService Activation DelaySignaling Channel Setup Delay (sec)

UMTS GMM (per QoS) End-to-End DelayRAN Downlink Delay

UMTS GTP (per SGSN) Downlink Traffic Received (bits/sec)Downlink Traffic Received (packets/sec)Uplink Traffic Sent (bits/sec)Uplink Traffic Sent (packets/sec)

UMTS Handover Active Set Cell CountCells Added to Active SetCells Removed from Active Set

UMTS Node-B Cell Active Data DCH countIP Interface StatisticsIP StatisticsLayer 2 Statistics (i.e, Internet)Total Cell Downlink ThroughputTotal Cell Uplink ThroughputUDP Statistics

UMTS Node-B ATM VC LoadThroughputUtilization

UMTS RACH Access DelayAcknowledgments ReceivedAcquisition Indicators ReceivedMessages SentNegative Acknowledgments ReceivedPreamble Cycles Per MessagePreamble Power LevelPreambles SentPreambles Sent Per MessageUnsuccessful Contentions

UMTS RNC Total Received ThroughputTotal Transmit Load

Table 38-15 Node Statistics (Continued)



38—UMTS

UMTS RNC (per logical channel) Buffer Usage (bytes)Buffer Usage (packets)Downlink Load (bits/sec)Downlink Load (packets/sec)Queue Delay Deviation (sec)Queuing Delay (sec)Traffic Dropped (bits/sec)Traffic Dropped (packets/sec)Traffic Received (bits/sec)Traffic Received (packets/sec)Traffic Sent (bits/sec)Traffic Send (packets/sec)

UMTS RNC (per Node-B) DSCH Number of Active RABsFACH Number of Active RABs

UMTS RNC (per QoS class) CN-UTRAN DelayRAN Uplink Delay

UMTS RNC (per transport channel) Downlink Retransmission DelayNumber of Downlink Transmissions RequiredRAN Uplink DelayReceived Sequence NumberReceived ThroughputTransmit Load

UMTS RNC ATM VC LoadThroughputUtilization

UMTS SGSN Total Number of Signaling Ch Requests GrantedTotal Number of Signaling Ch Requests QueuedTotal Number of Signaling Ch Requests ReleasedTotal Number of Signaling Ch Requests Rejected

UMTS UE (per logical channel) Buffer Usage (bytes)Buffer Usage (packets)Queue Delay Deviation (sec)Queuing Delay (sec)Traffic Dropped (bits/sec)Traffic Dropped (packets/sec)Traffic Received (bits/sec)Traffic Received (packets/sec)Traffic Sent (bits/sec)Traffic Send (packets/sec)Uplink Load (bits/sec)Uplink Load (packets/sec)

UMTS UE GMM (per QoS class) End-to-End DelayRAN Downlink Delay




38—UMTS

Global Statistics

The following UMTS global statistics are available. For details on a particular statistic, see its description by right-clicking on the statistic name in the Choose Results dialog box and selecting View Description from the pull-down menu.

UMTS UE RLC/MAC Total Received ThroughputTotal Transmit Load

UMTS UE RLC/MAC (per physical channel)

Uplink Actual Eb/NoUplink Average InterferenceUplink reception PowerUplink Target Eb/NoUplink transmission Power

UMTS UE RLC/MAC (per transport channel)

Number of Uplink Transmissions RequiredReceived Sequence NumberReceived ThroughputTransmit LoadUplink Retransmission Delay

End of Table 38-15



Table 38-16 Global Statistics

UMTS GMM GPRS Attach Delay

PDP Context Activation Delay

Service Activation Delay

UMTS GMM (per QoS) End-to-End Delay

End of Table 38-16


38—UMTS

Appendix I: Acronyms and Abbreviations Used in UMTS

Table 38-17 Acronyms and Abbreviations Used in UMTS

Abbreviation Description

2G 2nd generation

3G 3rd generation

3GPP 3rd Generation Partnership Project

AAL ATM Adaptation Layer

AM Acknowledged Mode

ATM Asynchronous Transfer Mode

BLER Block Error Rate

BSC Base Station Controller

BSS Base Station Subsystem

BTS Base Transceiver Station

CGF Charging Gateway Functionality

CN Core Network

CPICH Common Pilot Channel

CPCH Common Packet Channel

CS Circuit Switched

DCCH Dedicated Control Channel

DCH Dedicated Channel

DL Downlink (Forward Link)

DPCCH Dedicated Physical Control Channel

DPCH Dedicated Physical Channel

DPDCH Dedicated Physical Data Channel

DSCH Downlink Shared Channel

DTCH Dedicated Traffic Channel

EIR Equipment Identity Register

EMA External Model Access


38—UMTS

FACH Forward Access Channel

FER Frame Error Rate

GGSN Gateway GPRS Support Node

GPRS General Packet Radio Service

GSM Global System for Mobile Communications

GTP GPRS Tunneling Protocol

HLR Home Location Register

IMSI International Mobile Subscriber Identity

IP Internet Protocol

MAC Medium Access Control

MCC Mobile Country Code

MM Mobility Management

MNC Mobile Network Code

MSC Mobile Switching Center

OSI Open System Interconnection

PCCH Paging Control Channel

PCH Paging Channel

PCPCH Physical Common Packet Channel

PCCPCH Primary Common Control Physical Channel

PDCP Packet Data Convergence Protocol

PDN Packet Data Network

PDP Packet Data Protocol

PDSCH Physical Downlink Shared Channel

PDU Protocol Data Unit

PMM Packet Mobility Management

PRACH Physical Random Access Channel

Table 38-17 Acronyms and Abbreviations Used in UMTS (Continued)



38—UMTS

PS Packet Switched

PU Payload Unit

QoS Quality of Service

RAB Radio Access Bearer

RACH Random Access Channel

RAN Radio Access Network

RANAP Radio Access Network Application Part

RB Radio Bearer

RRC Radio Resource Control

RLC Radio Link Control

RNC Radio Network Controller

SCH Synchronization Channel

SGSN Serving GPRS Support Node

SM Session Management

TCP Transport Control Protocol

TDMA Time Division Multiple Access

TE Terminal Equipment

TMSI Temporary Mobile Subscriber Identity

TrM Transparent Mode

TTI Transmission Time Interval

UE User Equipment

UL Uplink (Reverse Link)

UM Unacknowledged Mode

UMTS Universal Mobile Telecommunications System




38—UMTS

UTRAN UMTS Terrestrial Radio Access Network

VLR Visitor Location Register

W-CDMA Wideband Code Division Multiple Access

End of Table 38-17




38—UMTS

Appendix II: UMTS Protocol Background

The packet domain core network includes two network nodes: the serving GPRS support node (SGSN) and the gateway GPRS support node (GGSN). The GPRS support nodes (GSNs) includes all the GPRS functionality required to support GSM and UMTS packet services. Using the notation defined in Figure 38-41 on page SPM-38-71, 3G-SGSN and 3G-GGSN refer to the UMTS functionality of the SGSN and GGSN respectively. The SGSN monitors users’ location and performs security functions and access control. The GGSN contains routing information for packet-switched (PS) attached users and provides interworking with external PS networks such as the packet data network (PDN). The circuit switched (CS) core network includes the mobile switching center / visitor location register (MSC/VLR). The MSC/VLR is used in the packet domain architecture to coordinate PS and CS services and functionality more efficiently.

The association between SGSN and MSC/VLR is created, for example, to coordinate users that are both GPRS-attached and IMSI (International Mobile Subscriber Identity)-attached. The Home Location Register (HLR) contains GSM and UMTS subscribers’ information. The Charging Gateway Functionality (CGF) collects charging records from the SGSN and GGSN. The Equipment Identity Register (EIR) stores information about user equipment identity.

Figure 38-41 Overview of Packet Domain Architecture

Figure 38-42 Equivalent Representation in OPNET Modeler


38—UMTS

Protocol Stack (Control and User Plane)

The user plane and control plane of the layered protocol structure between the UE and 3G-GGSN is shown in Figure 3 and Figure 4 respectively.

In both planes, the Medium Access Control (MAC) layer handles functions such as priority handling between data flows of one UE, and multiplexing/demultiplexing of higher layer protocol data units (PDUs) into/from transport blocks delivered to/from the physical layer. The Reliable Link Control (RLC) layer supports transfer of user data in transparent, unacknowledged, and acknowledged mode. Transparent mode supports segmentation/reassembly of higher layer PDUs into/from smaller RLC payload units (PUs) and transfer of user data. Unacknowledged mode supports segmentation and reassembly, concatenation, padding, transfer of user data, ciphering, and sequence number check. The acknowledged mode supports segmentation and reassembly, concatenation, padding, transfer of user data, error correction, in-sequence delivery of higher layer PDUs, duplicate detection, flow control, and ciphering.

In the user plane, the Packet Data Convergence Protocol (PDCP) layer handles transmission and reception of PDUs using services provided by the RLC protocol, and header compression and decompression.

The GPRS Tunneling protocol for the user plane (GTP-U) uses a tunneling mechanism to carry data packets between UTRAN and 3G-SGSN, and between the GSNs in the backbone network. The GPRS tunneling protocol for the control plane (GTP-C) tunnels signaling messages between SGSNs and GGSNs, and between SGSNs in the backbone network. Control Plane signaling is used to create, modify and delete tunnels. The Radio Access Network Application Protocol (RANAP) in the control plane encapsulates and carries higher-layer signaling, handles signaling between the UTRAN and 3G-SGSN, and manages the GTP connections on the Iu interface.

In the control plane, signaling is transferred via a Signaling Connection Control Part (SCCP) connection on the Iu interface. The Radio Resource Control (RRC) layer handles functions such as the establishment, maintenance, and release of RRC connections between the UE and UTRAN, establishment, reconfiguration,


38—UMTS

and release of Radio Bearers, RRC connection mobility functions, and UE measurement reporting functions. The GPRS Mobility Management and Session Management (GMM) layer handles functions such as attach, detach, security, routing area update, and PDP context activation and deactivation.

Figure 38-43 MS-GGSN User Plane for UMTS

Figure 38-44 MS-GGSN Control Plane for UMTS

Mobility Management and Session Management

Figure 38-45 shows the Packet Mobility Management (PMM) States for UMTS only. These functions are handled in the GMM layer of the UE and 3G-SGSN in Figure 38-44. A mobile station cannot use GPRS services before registering in the GPRS network. A mobile station is in the Packet Mobility Management Detached (PMM-Detached) State if it is not registered in the GPRS network as shown in Figure 38-45. In that state, there is no communication between the UE and the 3G-SGSN. The 3G-SGSN cannot reach the UE because it has no valid location or routing information for the UE. The UE makes its presence known to the network by performing the GPRS Attach procedure. This makes the UE available for paging via the 3G-SGSN.


38—UMTS

A PS (Packet Switched) signaling connection is also established between UE and 3G-SGSN by performing the GPRS Attach procedure. When the PS signaling connection is established between the UE and 3G-SGSN, UE and 3G-SGSN move to the PMM-Connected State. The PS signaling connection consists of an RRC connection between UE and UTRAN and an Iu connection between the UTRAN and 3G-SGSN. If the PS signaling connection is released or broken, the UE and 3G-SGSN move to the PMM-Idle State.

Once in the PMM-Connected State, the mobile station needs to request a Packet Data Protocol (PDP) address used in the Packet Data Network (PDN) if it wants to exchange packet data with external packet networks. The mobile station accomplishes this by activating the PDP context that it wants to use. The PDP context characterizes the session. It includes the PDP type (such as IPv4 or Ipv6), PDP address, QoS requested, etc. With an active PDP context, the mobile station is known to external packet data networks and can send and receive PDP PDUs. The MS and SGSN can move to the PMM-Detached State by performing a GPRS Detach procedure.

In the PMM-Idle State, the mobile station is attached to the GPRS network but data transmission and reception is not possible. There is no PS signaling connection between the UE and 3G-SGSN. To re-establish the PS signaling connection between the UE and 3G-SGSN in the PMM-Idle State, the UE performs a Service Request procedure with the 3G-SGSN. Once the PS signaling connection is re-established, the UE and 3G-SGSN move back to the PMM-Connected State. The mobile station may initiate the activation of a PDP context while in the PMM-Idle State.

Figure 38-45 UE PMM States

Radio Resource Management

Radio resources are allocated to the mobile station in a very flexible manner depending on the level of activity and the amount of data that needs to be sent. Packets can be sent over the physical random access channel (PRACH), the physical common packet channel (PCPCH), or the dedicated physical data channel (DPDCH). For a small amount of data, the PRACH is normally used. For small to medium amounts of data, the PCPCH is preferred. For large amounts of data, the DPDCH can be used.

PMM-Detached

PMM-Idle PMM-Connected

PS Detach PS Attach PS Detach

PS Signaling Connection Release

PS Signaling Connection Establish

PMM-Detached

PMM-Idle PMM-Connected

PS Detach PS Attach PS Detach

PS Signaling Connection Release

PS Signaling Connection Establish


38—UMTS

On receipt of PDUs from higher layers, the UE begins the RAB (Radio Access Bearer) Assignment procedure if no radio bearer has been established. If these PDUs do not belong to a quality of service for which a PDP context has been activated, the UE first initiates the PDP Activation Procedure. On the other hand, if a PDP context already exists, the UE initiates the RAB Assignment procedure by sending a Service Request message to the 3G-SGSN as shown in Figure 6. The Service Request procedure is used to setup a PS signaling connection with the network if the UE is in PMM-Idle State or to request resource reservation to the network if the UE is in PMM-Connected State. In the RAB Assignment procedure, the 3G-SGSN sends a RAB Assignment Request message to the UTRAN to establish one RAB. The UTRAN establishes the appropriate radio bearer by sending a Radio Bearer Setup message to the UE if there is sufficient uplink and downlink capacity available to support the new radio link. On receipt of a Radio Bearer Setup message, the UE setups the appropriate radio bearer as specified by the UTRAN. Once a radio bearer is set, the UE can start sending/receiving PDUs on the uplink/downlink.

Figure 38-46 RAB Assignment Procedure


38—UMTS
