Sie sind auf Seite 1von 246

Cisco Network Planning Solution SPM Specialized Models User Guide

Software Release 11.5

Corporate Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 526-4100

Text Part Number: OL-8621-01

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS. THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY. The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCBs public domain version of the UNIX operating system. All rights reserved. Copyright 1981, Regents of the University of California. NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED AS IS WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

CCSP, CCVP, the Cisco Square Bridge logo, Follow Me Browsing, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.; and Access Registrar, Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, FormShare, GigaDrive, GigaStack, HomeLink, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, LightStream, Linksys, MeetingPlace, MGX, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, ProConnect, RateMUX, ScriptShare, SlideCast, SMARTnet, StrataView Plus, TeleRouter, The Fastest Way to Increase Your Internet Quotient, and TransPath are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries. All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0502R)

Cisco Network Planning Solution SPM Specialized Models User Guide Copyright 2005 Cisco Systems, Inc. All rights reserved.

Specialized Models User Guide

Copyright

Copyright

Document Copyright Title: Specialized Models User Guide Part Number: D00241 Version: 8 1987-2005 OPNET Technologies, Inc. All Rights Reserved. Reproduction, adaptation, or translation without prior written permission is prohibited, except as allowed under the copyright laws. Software Copyright Product Name: IT Guru Product Release: 11.5 1987-2005 OPNET Technologies, Inc. All Rights Reserved.

IT Guru/Release 11.5

STM-FM-iii

Documentation Conventions

Specialized Models User Guide

Documentation Conventions
OPNET documentation uses specific formatting and typographic conventions to present the following types of information:

Objects, examples, and system I/O Object hierarchies, notes, and warnings Computer commands Lists and procedures

Objects, Examples, and System I/O


Directory paths and file names are in plain Courier typeface: opnet\release\models\std\ip Function names in body text are in italics: op_dist_outcome() The names of functions of interest in example code are in bolded Courier typeface: /* determine the object ID of packets creation module */ src_mod_objid = op_pk_creation_mod_get (pkptr); Variables are enclosed in angle brackets (< >): <opnet_user_home>/op_admin/err_log

Object Hierarchies, Notes, and Warnings


Menu hierarchies are indicated by right angle brackets (>); for example:

Open File > Print Setup > Properties...


Attribute hierarchies are represented by angled arrows () that indicate that you must drill down to a lower level of the hierarchy:

STM-FM-iv

IT Guru/Release 11.5

Specialized Models User Guide

Documentation Conventions

Attribute level 1 Attribute level 2 Attribute level 3

NoteNotes are indicated by text with the word Note at the beginning of the paragraph. Notes advise you of important supplementary information.

WARNINGWarnings are indicated by text with the word WARNING at the beginning of the paragraph. Warnings advise you of vital information about an operation or system behavior.

Computer Commands
These conventions apply to windowing systems and navigation methods that use the standard graphical-user-interface (GUI) terminology such as click, drag, and dialog box.

Key combinations appear in the form press <button>+x; this means press the <button> and x keys at the same time to do the operation. The mouse operations left-click (or click) and right-click indicate that you should press the left mouse button or right mouse button, respectively.

Lists and Procedures


Information is often itemized in bulleted (unordered) or numbered (ordered) lists:

In bulleted lists, the sequence of items is not important. In numbered lists, the sequence of items is important.
Procedures are contained within procedure headings and footings that indicate the start and end of the procedure. Each step of a procedure is numbered to indicate the sequence in which you should do the steps. A step may be followed by a description of the results of that step; such descriptions are preceded by an arrow.

Procedure FM-1 Sample Procedure Format 1 Procedure step. Result of the procedure step. 2 Procedure step. End of Procedure FM-1

For more information about using and maintaining OPNET documentation, see the OPNET IT Guru Documentation Guide.
IT Guru/Release 11.5 STM-FM-v

Documentation Conventions

Specialized Models User Guide

STM-FM-vi

IT Guru/Release 11.5

Specialized Models User Guide

Document Revision History

Document Revision History


Release Date February 2005 Product Version 11.0 Chapter MPLS Description of Change Added information on static and directly-connected route redistribution into BGP. Replaced Configuring a One-Armed Router section with current technology. Replaced instance of RSM Node or RSM Switch with Layer-3 Switch. Added section Global IS-IS Configuration Moved chapter to Standard Models manual. Added feature support chart. Chapter moved to Planning and Design User Guide Section added to this manual.

VLAN

IS-IS August 2004 January 2004 11.0 10.5 IP Multicast MPLS MPLS TE September 2003 10.0 Revision History

SP Guru/Release 11.5

SPM-FM-vii

Document Revision History

Specialized Models User Guide

SPM-FM-viii

SP Guru/Release 11.5

Specialized Models User Guide

Contents

Contents
Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .STM-FM-iii Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . STM-FM-iv Document Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-FM-vii List of Figures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-FM-xv List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-FM-xix List of Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-FM-xx

Circuit-Switched Model User Guide

SPM-1-1

Model Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-1 Call Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-2 Conference Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-3 Call Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-4 Multi-Service Switching (MSS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-5 Multi-Trunk Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-7 Priority Preemption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-7 Failure and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-7 Circuit-Switched Modeling Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-8 Model Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-10 PBX Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-10 SSP Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-14 MSS Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-15 Circuit-Switched Attribute Definer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-19 Simulation Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-20 Available Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-20 Example Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-20

DOCSIS Model User Guide

SPM-2-1

Model Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-1 Model Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-2 DOCSIS Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-3 DOCSIS Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-4 Node and Link Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-5 CM Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-5 CMTS Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-5 Link Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-6 DOCSIS Attribute Configuration Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-6 Supported Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-7 Model Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-7 DOCSIS Configuration Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-7 CM Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-15 CMTS Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-17

SP Guru/Release 11.5

SPM-FM-ix

Contents

Specialized Models User Guide

Simulation Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Model Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DOCSIS Configuration Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MAP Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Management Message Intervals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . QoS Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CMTS Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Available Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simulation Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scenario Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Possible Project Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SPM-2-19 SPM-2-19 SPM-2-20 SPM-2-20 SPM-2-20 SPM-2-20 SPM-2-21 SPM-2-22 SPM-2-23 SPM-2-25 SPM-2-27 SPM-2-27 SPM-2-27 SPM-2-28 SPM-2-28

IPv6 Model User Guide

SPM-3-1

Model Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-2 Model Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-4 Menu Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-5 Configuring IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-5 Configuring IPv6 Addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-5 Configuring IPv6 Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-7 Dual-Stack Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-8 IPv4-Only, IPv6-Only and IPv4/IPv6 Node Configuration . . . . . . . . . . . . . . . . . . . . . . SPM-3-8 Application Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-9 Traffic Demand Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-9 Migrating to IPv6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-9 Manual IPv6 Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-10 Automatic IPv6 Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-11 6to4 Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-12 Using Mobile IPv6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-12 Configuring Mobile IPv6 (MIPv6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-12 Mobile Nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-13 Correspondent Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-14 Home/Foreign Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-14 Mobility Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-15 Router Advertisements, Advertise Interval, and Mobility Detection Factor . . . . . . . . SPM-3-15 Route Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-15 WLAN Roaming Capability on 802.11-Based Mobile Nodes. . . . . . . . . . . . . . . . . . . SPM-3-16 Analyzing IPv6 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-16 Available Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-16 Visualizing IPv6 Configuration in the Workspace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-17 Visualizing Route for Traffic Demands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-17 IPv6 Interface Configuration Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-17 Reference Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-19

SPM-FM-x

SP Guru/Release 11.5

Specialized Models User Guide

Contents

Mainframe Model User Guide

SPM-4-1

Model Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-4-1 Model Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-4-2 Mainframe Configuration Object Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-4-2 Mainframe Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-4-8 Available Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-4-13

MPLS Model User Guide

SPM-5-1

Model Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-1 MPLS for Traffic Engineering Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-3 Configuring Dynamic LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-3 Dynamic LSPs with Explicit Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-3 Dynamic LSPs with CSPF Routes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-4 Configuring Static LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-5 Sending Traffic Through LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-6 Static Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-6 IGP Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-8 Inter-Domain MPLS Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-9 Configuring Cisco Inter-Area LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-9 Configuring Cisco Inter-AS LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-10 Configuring Cross-Connect Circuits (CCC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-11 Traffic Engineering in MPLS Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-12 Traffic Engineering Without DiffServ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-12 Traffic Engineering With DiffServ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-13 Available Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-13 MPLS TE Design Actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-14 Fast-Reroute in MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-14 Facility Backup Using Bypass Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-14 Configuring Bypass Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-14 Setting Bandwidth Quota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-15 One-to-One Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-15 Design Actions for Fast Reroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-16 MPLS Failover Mode in Flow Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-16 MPLS for Layer-3 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-16 MPLS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-16 LDP-Based Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-16 Dynamic/Static LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-17 VPN Routing/Forwarding (VRF) Instance Configuration . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-17 Defining VRF Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-17 Associating VRF Tables with Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-17 Configuring Routes to PE and CE Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-18 Configuring BGP Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-18 BGP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-18 PE-CE Routing Protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-19 VPLS and L2 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-20 BGP-Based VPLS and Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-20 Creating Tunnel LSPs Between PE Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-20
SP Guru/Release 11.5 SPM-FM-xi

Contents

Specialized Models User Guide

Enabling LDP or RSVP-TE to Create Tunnel LSPs. . . . . . . . . . . . . . . . . . . . . . . . . . Dynamic/Static LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring an IGP on PE and P routers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LDP-Based VPLS and Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DES Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flow Analysis Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Display LSP Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Display Routes from Connections Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Troubleshooting MPLS Network Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unroutable LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VRF Tables Not Built Correctly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Model Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DES Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reference Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SPM-5-20 SPM-5-21 SPM-5-21 SPM-5-21 SPM-5-22 SPM-5-22 SPM-5-22 SPM-5-23 SPM-5-24 SPM-5-24 SPM-5-24 SPM-5-25 SPM-5-25 SPM-5-26 SPM-5-26 SPM-5-26 SPM-5-26 SPM-5-26 SPM-5-27

PNNI Model User Guide

SPM-6-1

Model Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-6-1 PNNI Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-6-2 Local Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-6-3 Simulation Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-6-8 Configuring Group and Hierarchy Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-6-10

Server Model User Guide

SPM-7-1

Model Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-1 Workflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-2 Model Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-3 Server Configuration Object Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-4 Server Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-12 Available Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-26 Example Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-31 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-33

UMTS Model User Guide

SPM-8-1

General Model Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-1 Model Features and Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-3 Model Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-3 Model Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-5 Reference Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-6 Creating a UMTS Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-7 Available Node Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-7 Cell Creator Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-8 Supported Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-10
SPM-FM-xii SP Guru/Release 11.5

Specialized Models User Guide

Contents

Model Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UE Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UE Node Model Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UE Process Model Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Node-B Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Node-B Node Model Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Node-B Process Model Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RNC Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RNC Node Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RNC Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CN Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CN Node Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GGSN Node Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SGSN Node Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CN Process Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UMTS Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Radio-Air Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Received Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vehicular Outdoor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pedestrian Outdoor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Indoor Office. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Background Noise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interference Noise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bit Error Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Air Interface Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Error Probability Bounds for Convolutional Coding . . . . . . . . . . . . . . . . . . . . . . . . . . Signal Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GPRS Attach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PDP Context Activation and RAB Assignment (MS-Connected State) . . . . . . . . . . . RAB Assignment with Prior PDP Activation (MS-Connected State) . . . . . . . . . . . . . RNC to Node-B Signal Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Signal Flows for Hard Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Signal Flows for Soft Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Model Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ICI Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Debugging/Simulation Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Model Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Local Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UE Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Node-B Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RNC Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CN Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simulation Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UMTS Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Node Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Global Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SPM-8-12 SPM-8-13 SPM-8-13 SPM-8-15 SPM-8-21 SPM-8-21 SPM-8-23 SPM-8-23 SPM-8-24 SPM-8-24 SPM-8-26 SPM-8-27 SPM-8-27 SPM-8-28 SPM-8-28 SPM-8-29 SPM-8-30 SPM-8-30 SPM-8-30 SPM-8-31 SPM-8-31 SPM-8-31 SPM-8-31 SPM-8-31 SPM-8-32 SPM-8-32 SPM-8-36 SPM-8-36 SPM-8-37 SPM-8-39 SPM-8-41 SPM-8-42 SPM-8-43 SPM-8-43 SPM-8-44 SPM-8-45 SPM-8-46 SPM-8-46 SPM-8-46 SPM-8-47 SPM-8-48 SPM-8-49 SPM-8-51 SPM-8-52 SPM-8-52 SPM-8-53 SPM-8-55

SP Guru/Release 11.5

SPM-FM-xiii

Contents

Specialized Models User Guide

Appendix I: Acronyms and Abbreviations Used in UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . Appendix II: UMTS Protocol Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocol Stack (Control and User Plane) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mobility Management and Session Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Radio Resource Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SPM-8-55 SPM-8-59 SPM-8-59 SPM-8-61 SPM-8-62

Index

SPM-IX-1

SPM-FM-xiv

SP Guru/Release 11.5

Specialized Models User Guide

List of Figures

List of Figures
Figure 1-1 Figure 1-2 Figure 1-3 Figure 1-4 Figure 1-5 Figure 1-6 Figure 1-7 Figure 1-8 Figure 1-9 Figure 1-10 Figure 1-11 Figure 1-12 Figure 1-13 Figure 1-14 Figure 1-15 Figure 1-16 Figure 1-17 Figure 1-18 Figure 2-1 Figure 2-2 Figure 2-3 Figure 2-4 Figure 2-5 Figure 2-6 Figure 2-7 Figure 2-8 Figure 2-9 Figure 2-10 Figure 2-11 Figure 2-12 Figure 2-13 Figure 2-14 Figure 2-15 Figure 2-16 Figure 2-17 Figure 2-18 Figure 2-19 Figure 2-20 Figure 2-21 Figure 2-22 Figure 2-23 Figure 2-24 Figure 2-25 Figure 3-1 Figure 3-2 Signalling Sequence for Call Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-2 Example of a Routing Table File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-5 Link Consisting of Three Trunks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-7 Circuit-switched Object Palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-8 Dialog Box for Specifying PBX Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-10 Dialog Box for Specifying Call Generation Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-11 Dialog Box for Specifying Dynamic Call Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-11 Dialog Box for Specifying Static Call Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-12 Generic Data File Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-12 Dialog Box for Specifying Conference Generation Attributes . . . . . . . . . . . . . . . . . . . . . SPM-1-13 Dialog Box for Specifying SSP Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-14 Attributes Dialog Box for a Multi-service Switch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-15 Pre-configured Schemes for VoATM Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-16 Dialog Box for Manually Configuring VoATM Parameters . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-16 Specifying Path Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-18 Specifying Call Path Preferences for IP Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-19 Circuit-switched Node Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-20 Example Circuit-switched Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-21 A Cable Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-4 Supported CM Nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-5 Supported CMTS Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-5 DOCSIS Link Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-6 DOCSIS Attribute Configuration Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-6 DOCSIS Configuration Object Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-7 Downstream Channel Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-8 Profile Details of the Default MAP Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-9 Time Covered by MAP Compound Attribute Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-9 Specifying Request/Data IE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-10 Specifying Modulation Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-11 Default PHS Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-11 Default Physical Media Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-12 Default Upstream Physical Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-13 Configuring Upstream Channel Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-14 DOCSIS CM Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-15 Configuring DOCSIS Parameters for a Router Interface . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-17 Configuring Upstream Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-18 Configuring the Downstream Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-18 DOCSIS Global Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-23 DOCSIS Node Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-24 DOCSIS MAP Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-25 A DOCSIS Simulation Log Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-26 Example DOCSIS Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-27 Packet End-to-end Delay for Example Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-28 Specifying Routing Protocols for an IPv6 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-8 Configuring a Home Agent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-14
SPM-FM-xv

SP Guru/Release 11.5

List of Figures

Specialized Models User Guide

Figure 3-3 Figure 3-4 Figure 3-5 Figure 4-1 Figure 4-2 Figure 4-3 Figure 4-4 Figure 4-5 Figure 4-6 Figure 4-7 Figure 4-8 Figure 4-9 Figure 4-10 Figure 4-11 Figure 4-12 Figure 4-13 Figure 4-14 Figure 4-15 Figure 4-16 Figure 4-17 Figure 5-1 Figure 5-2 Figure 5-3 Figure 5-4 Figure 5-5 Figure 5-6 Figure 5-7 Figure 5-8 Figure 5-9 Figure 5-10 Figure 5-11 Figure 6-1 Figure 6-2 Figure 6-3 Figure 6-4 Figure 6-5 Figure 6-6 Figure 6-7 Figure 6-8 Figure 6-9 Figure 6-10 Figure 6-11 Figure 7-1 Figure 7-2 Figure 7-3 Figure 7-4 Figure 7-5

IPv6 Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-16 Viewing Routing Protocol Configuration for IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-17 Generating IPv6 Interface Configuration Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-18 Mainframe Model Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-4-2 Mainframe Configuration Object Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-4-2 Mainframe Definitions Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-4-3 PU Configuration Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-4-3 Benchmark Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-4-4 Report Class Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-4-5 Service Class Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-4-5 Performance Goal Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-4-5 Workload Definition Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-4-6 Mainframe Modeling Attributes on Mainframe Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-4-8 Mainframe Parameters Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-4-9 Hardware Configuration Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-4-9 LPAR Configuration Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-4-10 Workload Group Configuration Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-4-11 Service Class Period Configuration Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-4-11 Workload Configuration Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-4-12 Available Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-4-13 Dynamic LSP in the Object Palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-4 Static LSP in the Object Palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-5 IGP Shortcuts in a Routing Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-9 Cisco Inter-Area LSP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-10 Inter-AS LSP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-11 Cross-Connect Circuit Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-12 A Bypass Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-15 BGP Configuration for Layer-3 VPNs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-18 Redistribution into BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-19 MPLS Related Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-24 Displaying LSP Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-25 Default Settings for PNNI Parameters Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-6-3 Specifying External Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-6-5 Specifying Administrative Weight on a Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-6-6 Specifying CTD and CDV on a Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-6-6 Complex Node Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-6-7 Exported Path Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-6-8 Exported ATM Address Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-6-9 Exported PNNI Node Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-6-9 Hierarchical Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-6-11 Level Information for Node 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-6-11 Level Information for Node 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-6-12 Server Modeling Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-3 Server Model Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-3 Server Configuration Object Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-4 Disk Drive Definitions Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-4 Disk Interface Definitions Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-5

SPM-FM-xvi

SP Guru/Release 11.5

Specialized Models User Guide

List of Figures

Figure 7-6 Figure 7-7 Figure 7-8 Figure 7-9 Figure 7-10 Figure 7-11 Figure 7-12 Figure 7-13 Figure 7-14 Figure 7-15 Figure 7-16 Figure 7-17 Figure 7-18 Figure 7-19 Figure 7-20 Figure 7-21 Figure 7-22 Figure 7-23 Figure 7-24 Figure 7-25 Figure 7-26 Figure 7-27 Figure 7-28 Figure 7-29 Figure 7-30 Figure 7-31 Figure 7-32 Figure 8-1 Figure 8-2 Figure 8-3 Figure 8-4 Figure 8-5 Figure 8-6 Figure 8-7 Figure 8-8 Figure 8-9 Figure 8-10 Figure 8-11 Figure 8-12 Figure 8-13 Figure 8-14 Figure 8-15 Figure 8-16 Figure 8-17 Figure 8-18 Figure 8-19 Figure 8-20

Operating System Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-6 Job Definitions Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-7 Memory Requirements Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-8 Server Definitions Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-10 Server Modeling Attributes on Server Nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-12 Advanced Server Configuration Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-13 CPU Partitions Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-14 CPU List Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-14 Paging System Definitions Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-15 Local Storage Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-16 Interface Configuration Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-16 Interface Channels Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-17 Disk Configuration Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-17 Storage Partitions Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-18 Direct Attached Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-19 Measured Access Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-20 Remote Access Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-21 Remote Storage Server Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-22 Replication Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-23 Jobs: Definitions Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-23 Storage Read Access Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-24 Instance Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-25 Available Statistics (Server Jobs). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-28 Remote Storage Server Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-29 Statistics with Annotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-30 Server Models Example Project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-31 Effects on Server Response Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-32 Overview of Packet Domain Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-2 UMTS Object Palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-7 Simple UMTS Network Using Application Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-11 Simple UMTS Network Using Raw Traffic Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-11 UMTS Network Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-12 Simple and Full-Protocol Stack UE Node Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-14 Queue Structure for GMM and RLC/MAC Layer at the UE Node . . . . . . . . . . . . . . . . . . SPM-8-15 umts_client_mgrApplication Manager Process for the UE Station Node . . . . . . . . . . . SPM-8-16 umts_client_childApplication Child Process for the UE Station Node . . . . . . . . . . . . . SPM-8-16 umts_gmmGMM Layer Process Model on the UE . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-17 umts_rlc_mac Process for the UEs RLC/MAC Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-18 RLC AM Retransmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-20 umts_rach Process Model on the UE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-21 Node-B Node Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-22 umts_node_b Process Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-23 RNC Node Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-24 Queue Allocation Structure at the RNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-25 Sample Queue Allocation for an RNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-25 umts_rnc Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-26 Simple CN Node Model: umts_sgsn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-27

SP Guru/Release 11.5

SPM-FM-xvii

List of Figures

Specialized Models User Guide

Figure 8-21 Figure 8-22 Figure 8-23 Figure 8-24 Figure 8-25 Figure 8-26 Figure 8-27 Figure 8-28 Figure 8-29 Figure 8-30 Figure 8-31 Figure 8-32 Figure 8-33 Figure 8-34 Figure 8-35 Figure 8-36 Figure 8-37 Figure 8-38 Figure 8-39

Gateway CN Node Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Queue Structure in the SGSN Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SGSN Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Delay in RAN and CN Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Block Error Rate (Union Bound) for Rates 1/2 and 1/3 Convolutional Codes . . . . . . . . . GPRS Attach with no Prior CS Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PDP Context Activation Procedure Initiated by the UE (Connected State) . . . . . . . . . . . PDP Context Activation Procedure Initiated by the Network (Connected State) . . . . . . . RAB Assignment Procedure Initiated by the UE (Connected State) . . . . . . . . . . . . . . . . RAB Assignment Procedure Initiated by the Network (Connected State) . . . . . . . . . . . . Signal Flows for Adding and Deleting a Radio Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Signaling Messages for Hard Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Signaling Messages for Soft Handover: In Case of Event 1C (Cell Replacement) . . . . . Overview of Packet Domain Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Equivalent OPNET Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MS-GGSN User Plane for UMTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MS-GGSN Control Plane for UMTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UE PMM States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RAB Assignment Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SPM-8-27 SPM-8-28 SPM-8-29 SPM-8-30 SPM-8-35 SPM-8-36 SPM-8-37 SPM-8-39 SPM-8-40 SPM-8-40 SPM-8-41 SPM-8-42 SPM-8-43 SPM-8-59 SPM-8-59 SPM-8-60 SPM-8-61 SPM-8-62 SPM-8-63

SPM-FM-xviii

SP Guru/Release 11.5

Specialized Models User Guide

List of Tables

List of Tables
Table 1-1 Table 1-2 Table 2-1 Table 2-2 Table 3-1 Table 3-2 Table 3-3 Table 3-4 Table 4-1 Table 4-2 Table 5-1 Table 5-2 Table 5-3 Table 6-1 Table 6-2 Table 6-3 Table 6-4 Table 7-1 Table 7-2 Table 8-1 Table 8-2 Table 8-3 Table 8-4 Table 8-5 Table 8-6 Table 8-7 Table 8-8 Table 8-9 Table 8-10 Table 8-11 Table 8-12 Table 8-13 Table 8-14 Table 8-15 Table 8-16 Circuit-Switched Model Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-1 Reference Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-1-2 Model Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-1 Simulating CM Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-2-5 IPv6 Model Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-2 Summary of IPv6 Support in SP Guru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-3 IPv6 Menu Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-5 Reference Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-19 Mainframe Model Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-4-1 Reference Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-4-1 MPLS Model Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-1 Summary of MPLS Support in SP Guru. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-1 Reference Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-27 PNNI Model Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-6-1 Reference Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-6-2 Derivation Rules Used to Generate Node and Peer Group IDs. . . . . . . . . . . . . . . . . . . . . . SPM-6-10 Node and Group IDs for Node 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-6-11 Server Model Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-1 Reference Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-7-2 Model Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-3 Node Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-8 Cell Creator Input Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-9 Transfer Function Coefficients for Rate-1/2 Convolutional Code. . . . . . . . . . . . . . . . . . . . . SPM-8-34 Transfer Function Coefficients for the Rate-1/3 Convolutional Code. . . . . . . . . . . . . . . . . . SPM-8-34 Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-44 ICI Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-45 UMTS Traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-46 UE Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-47 Node-B Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-48 RNC Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-49 CN Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-51 Simulation Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-52 Node Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-53 Global Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-55 Acronyms and Abbreviations Used in UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-55

SP Guru/Release 11.5

SPM-FM-xix

List of Procedures

Specialized Models User Guide

List of Procedures
Procedure 2-1 Procedure 2-2 Procedure 3-1 Procedure 3-2 Procedure 3-3 Procedure 3-4 Procedure 3-5 Procedure 3-6 Procedure 3-7 Procedure 5-1 Procedure 5-2 Procedure 5-3 Procedure 5-4 Procedure 5-5 Procedure 5-6 Procedure 5-7 Procedure 5-8 Procedure 5-9 Procedure 5-10 Procedure 5-11 Procedure 5-12 Procedure 5-13 Procedure 5-14 Procedure 5-15 Procedure 5-16 Procedure 5-17 Procedure 8-1 Creating a Profile for a DOCSIS Configuration Object Attribute . . . . . . . . . . . . . . . . SPM-2-20 Configuring One or More Upstream/Downstream Channel(s) on a CMTS Node . . . SPM-2-22 Manually Configuring IPv6 Addresses on Gateway Nodes . . . . . . . . . . . . . . . . . . . . . SPM-3-6 Manually Configuring IPv6 Addresses on Host Nodes . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-6 Designating a Routing Protocol on an IPv6 Interface . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-7 Configuring One End of a Bidirectional Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-10 Enabling Automatic Tunneling on a Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-11 Configuring a 6to4 Tunnel on a Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-12 Configuring a Mobile Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-3-13 Creating Dynamic LSPs with Explicit Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-3 Creating Dynamic LSPs Without Explicit Routes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-5 Creating Static LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-5 Creating FECs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-7 Creating a Traffic Trunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-7 Creating Static Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-8 Using DiffServ in Traffic Engineering Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-13 Configuring a Bypass Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-15 Defining VRF Tables on PE Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-17 Associating VRF Tables with Individual Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-17 Enabling MPLS on all Interfaces Between PE and P Routers. . . . . . . . . . . . . . . . . . SPM-5-20 Configuring LDP-Based Paths. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-20 Configuring an IBGP Session Between PE Routers . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-21 Configuring Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-21 Configuring VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-22 Configuring Layer-2 FECs on PE Routers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-23 Configuring VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-5-23 Using the Cell Creator Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPM-8-9

SPM-FM-xx

SP Guru/Release 11.5

Specialized Models User Guide

1Circuit-Switched Model User Guide

Circuit-Switched Model User Guide


Circuit-switching is a technique used to establish connections in telephone networks. Before a call in a circuit-switched system can begin, an end-to-end circuit must be established between two terminals. A fixed share of link bandwidth is then designated for the call. During the call, no other calls can use this bandwidth until the original connection is closed. At this time, the reserved bandwidth is de-allocated and made available for other calls. This document describes key features of the Circuit-Switched model shipped as part of the OPNET specialized model library.

Model Features
This section provides a list of the main features available in the Circuit-Switched model. The Circuit-Switched model suite captures the following circuit-switched network behavior:
Table 1-1 Circuit-Switched Model Features
Feature Call Generation Conference Calls Description Supports dynamic and static-table call generation. Supports conference calling, which connects more than two phones on the same call. The model performs source routing. Two routing options are available: dynamic and static routing. Multi-Service Switching (MSS) MSS allows you to connect circuit-switched networks to IP and ATM networks. Model supports multiple trunks between any two SSPs (Switching Service Point). The model supports call priorities. Low-priority calls can be dropped or blocked to accommodate high-priority calls. The model allows you to study the impact of trunk and SSP failures.

Call Routing

Multi-trunk Load Balancing

Priority preemption

Failure and Recovery

End of Table 1-1

SP Guru/Release 11.5

SPM-1-1

1Circuit-Switched Model User Guide

Specialized Models User Guide

Circuit-Switched models are implemented based on information available from the following sources.
Table 1-2 Reference Documents
GS-1364-CORE ITU-T Recommendation Q.709 GR-1364-CORE End of Table 1-2 published by Telcordia published by Telcordia

More detailed information on the models major features is given below.

Call Generation
The PBX module is responsible for generating signals that start and end the call. The signaling sequence to establish calls is illustrated in Figure 1-1:
Figure 1-1 Signalling Sequence for Call Generation
Source PBX Originating SSP Terminating SSP Destination PBX

N-th SSP

ST

1) The source PBX sends a setup message to the destination PBX. 2) As the setup message travels through the network, participating SSPs along its path allocate bandwidth. 3) If all SSPs in the path of the setup message can allocate the requested bandwidth (that is, if the requested bandwidth is available at all SSPs along the path), an acknowledgement is sent back by the final SSP to the source PBX. 4) If any SSPs in the path cannot allocate the requested bandwidth, then the call cannot be established. A negative acknowledgment is sent back, and the call is blocked.

SPM-1-2

SP Guru/Release 11.5

Specialized Models User Guide

1Circuit-Switched Model User Guide

5) The call is established when the source PBX receives the acknowledgment. The call setup time, ST, is the time between events and . 6) Once the call duration, T, is over, the source PBX sends out a tear-down message along the same path as the setup message, and participating SSPs de-allocate the bandwidth that was reserved for the call. To improve the efficiency of the simulation, the PBX sends no data for the duration of the call. This allows us to isolate the dynamics of the bandwidth allocation. Since all call signaling in the model is done by zero-length packets, call signaling is effectively out-of-band and is similar to SS7 signaling. The circuit-switched model accounts for the setup delays incurred by the SS7 network. These calculations are based on the number of STP (Signaling Transfer Point) pairs in the network and on the mean cross-switch delays specified in GS-1364-CORE, published by Telcordia. Users can simulate the effects of failure in the SS7 signaling by disabling any SSPs ability to receive SS7 signals. In a failure scenario, no new calls are established through that SSP, but all current calls are maintained and properly disconnected. Each PBX can generate dynamic or static-table calls. Dynamic call generation allows users to generate calls from one specific PBX to another specific PBX in the network. It is also possible to have a PBX generate calls to randomly chosen addresses. With this method, you cannot control the destination selection process. To control the destination selection process, use static-call tables to specify the exact traffic flow out of a given PBX to one or more PBXs in the network.

Conference Calls
The circuit-switched model supports conference calls, that is, calls that connect more than two phones at the same time. However, bandwidth for such calls is allocated differently than it is for regular calls. Bandwidth is allocated by SSPs only once along all sections of the route shared by two or more teleconference parties. Use the Circuit-Switched Attribute Definer to define call participants and specify the type of conference: voice or video.

SP Guru/Release 11.5

SPM-1-3

1Circuit-Switched Model User Guide

Specialized Models User Guide

Call Routing
When an SSP receives a setup packet from the source PBX, it determines a route to the destination PBX. Routing decisions are based on several factors: the number of hops, the cost, and the time of day. The circuit-switched model allows users to influence an SSPs routing decisions by changing these factors. For routing decision purposes, hops exist only between nodes which support circuit-switched technology. Specifically, hops exist between two SSPs, between an SSP and a multi-service switch, or between two multi-service switches. Links between two routers within an IP or ATM network are not regarded as hops. The model performs source routing: this means that a complete call route to the destination SSP is chosen at the first SSP. The other SSPs along the route cannot change the original route, but can only switch the signalling packet according to the route chosen by the first SSP. With multi-service switching, however, the route chosen by the first SSP may be changed by the multi-service switch. If an SSP fails to reserve the required bandwidth on its first-choice route, it will attempt to establish a call on the route with the next lowest cost. This process will repeat until either of the following events occurs: a valid route is found all routes have been tried If a multi-service switch is used to route calls over an ATM network, only one attempt is made to re-route a call which has been blocked by the ATM network. If the second attempt is unsuccessful, no further attempts will be made to set up the call and the call will not be established. For each failed attempt, an SSP will update its Calls Blocked statistic. There are two main options for routing: dynamic and static. Dynamic Routing. In the dynamic routing mode, the first SSP uses the OPNET routing package to perform minimum-cost routing: an SSP will choose a route with the smallest sum of all link costs on that route. You can influence routing decisions by changing the costs of the links. However, if several routes with the same minimum cost exist, you cannot specify which route will be chosen as the minimum-cost route: to do this, you must use static routing. Static Routing. The circuit-switched model allows you to control the routing decision process. You can associate SSPs with external routing tables that are specified in separate text files. The routes in these tables automatically supersede dynamically chosen routes. If you need to reinstate dynamic routing, choose Auto-Routing from the Static Table Properties menu.
SPM-1-4 SP Guru/Release 11.5

Specialized Models User Guide

1Circuit-Switched Model User Guide

Routes in the routing table are specified on a hop-by-hop basis, where each hop is the hierarchical name of an SSP. Each static route in the table has a weight value associated with it. The weight of a route appears in the first column of the table and corresponds to the percentage of times the route should be chosen by SSP from the pool of routes to the same destination. When static routing is active, an SSP chooses the route based on its weight, not its cost; a high-cost route with a greater weight will be chosen more often than a low-cost route with a lesser weight. If only one route exists, that route will always be chosen by an SSP. Therefore, you should list several alternate routes to the same destination in the routing tables you define. This gives an SSP some way to reroute a call if it is initially blocked. A sample file in a routing table is shown in Figure 1-2.
Figure 1-2 Example of a Routing Table File
0.8 0.2 top.ssp1 top.ssp1 top.ssp3 top.ssp4 top.ssp5 top.ssp5

hop names use the format: <subnetwork name>.<node name> 0.8 (80%) and 0.2 (20%) are the respective weights of two different routes from SSP1 to SSP5. Calls going from any PBX connected to SSP1 to any PBX connected to SSP5 will take the first route (through SSP3) 80% of the time and the second route (through SSP4) 20% of the time. Time of Day Routing. An additional feature of static routing is time-of-day routing. Different static routing tables can be loaded as a simulation progresses. This allows you to alter the route an SSP chooses depending on the time of day.

Multi-Service Switching (MSS)


You can connect circuit-switched networks to conventional packet-switched IP and ATM networks. This is done with the Multi-Service Switch node, which is a router node that can interface between these two types of networks. Using the multi-service switch to route calls to both types of networks has the following benefits: Compression. Calls routed across the IP or ATM network can be compressed, thus reducing the amount of bandwidth required. Bandwidth Efficiency. Calls routed through the IP or ATM network cost less. While a call is in progress over a circuit-switched network, the bandwidth allocated during call setup is unavailable for use by other calls until the call is torn down. Therefore, allocated bandwidth that is not in use for some period during a circuit-switched call when neither party is speaking, for example is unavailable for use by other calls. If a call is routed over an IP or ATM network, bandwidth that is not in use is available for other calls.
SP Guru/Release 11.5 SPM-1-5

1Circuit-Switched Model User Guide

Specialized Models User Guide

There are three types of multi-service switch router interfaces: IP (includes Ethernet, Token Ring, PPP) ATM Circuit-switched Circuit-switched interfaces are connected to an SSP node, which is available from the circuit-switched object palette. PBX nodes cannot be directly connected to a multi-service switch; it must first be connected to an SSP node. IP and ATM interfaces can be connected to any switches or routers that support IP or ATM. The following configuration is not supported at this time: Voice over Frame Relay (VoFR) Traffic routed through the multi-service switch is subject to the following limitations: Application traffic from an IP interface must be routed to an IP interface. Application traffic from an ATM interface cannot be routed through a multi-service switch. Application traffic generated by the application layer (through the Voice standard network application, for example) cannot be routed to a circuit-switched interface. Traffic generated by calls originating at a PBX can be routed to any node in the network. For example, you cannot route application layer traffic from an IP interface to an ATM interface. Also, although the voice traffic generated in a circuit-switched network can be sent to any type of interface (IP, ATM or circuit-switched), a circuit-switched interface can receive only voice traffic generated in a circuit-switched network. When using multi-service switching the following call routing exceptions are made: When routing calls over ATM networks, one attempt is made to re-route blocked calls. If the call is blocked twice, the call will not be established as no additional attempts are made to set up the call. When routing calls over IP networks, it is possible that calls are not set up, that packets are lost, or that packets arrive out-of-order. This is because IP does not support bandwidth reservation or guarantee the successful transmission of packets across an IP network.

SPM-1-6

SP Guru/Release 11.5

Specialized Models User Guide

1Circuit-Switched Model User Guide

Multi-Trunk Load Balancing


The circuit-switched model supports multiple trunks between any two SSPs. The total bandwidth of the link between two SSPs is the sum of all the trunks connecting those SSPs. Physical trunks can be added or removed, allowing you to change the bandwidth of the link. Each trunk (OPNET link) has a weight attribute that controls how often it is chosen for transmission.
Figure 1-3 Link Consisting of Three Trunks

For example, if a link consists of three trunks, A, B and C (as illustrated in Figure 1-3), with weights of 100, 50 and 25, respectively, then trunk A will be chosen twice as often as trunk B, and four times as often as trunk C.

Priority Preemption
The circuit-switched model supports call priorities. If a high-priority call arrives at an SSP when there is no available bandwidth on the outgoing links, the SSP disconnects the necessary number of active low-priority calls to accommodate the high-priority call. However, if the requested bandwidth of the high-priority call is greater that the SSP can accommodate with all low-priority calls disconnected, then the high-priority call is blocked. High-priority calls can preempt only low-priority calls, but not other high-priority calls. If a low-priority call cannot be accommodated, it is always blocked. All conference calls are high-priority calls.

Failure and Recovery


The circuit-switched model allows you to fail selected trunks (OPNET links) or SSPs by setting the Status attribute in the Failure/Recovery object to Fail. For an SSP failure, all calls going through the failed SSP are dropped. When a trunk is failed, all calls using that trunk are dropped and the trunk is no longer available to new calls.

SP Guru/Release 11.5

SPM-1-7

1Circuit-Switched Model User Guide

Specialized Models User Guide

When a link between two SSPs consists of several trunks, then a link will be valid for transmission as long as it has one operational trunk. However, if all the trunks of a link have failed, the link is no longer valid, and calls trying to go through it are blocked. To recover an SSP or a trunk, set the Status attribute in the Failure/Recovery object to Recover.

Circuit-Switched Modeling Elements


There are three main components in the circuit-switched system: Phone terminals, used for voice communication. A group of these terminals connected in a bundle comprises a PBX (private branch exchange). A PBX is a telephone hub that switches calls among local lines and between internal and external lines. A PBX reduces costs by not requiring a line to the phone company for each user. Switching centers are used to receive control signals, and to forward or connect the calls between phone terminals. In the SS7 notation, these switches are called Service Switching Points (SSPs). Links, used to convey the information and the control signals between the phone terminals and the SSPs. The circuit-switched object palette contains the following node and link models:
Figure 1-4 Circuit-switched Object Palette

PBX Node. PBXs can be configured to generate traffic that is equivalent to the traffic generated by one or more phones. SSP Node. The main functions of an SSP module are: to route and forward calls to control traffic
SPM-1-8 SP Guru/Release 11.5

Specialized Models User Guide

1Circuit-Switched Model User Guide

Multi-Service Switch Node. This router node allows you to connect circuit-switched networks to packet-switched networks (such as IP and ATM networks). Link Models. This model contains the following links: CKT-SW DS1 CKT-SW DS3 CKT-SW T1 CKT-SW T3 CKT-SW OC3 CKT-SW OC12 CKT-SW OC36 CKT-SW OC48 Circuit-Switched Attribute Definer. Use this object to specify conference groups and their members. Failure/Recovery object. Use this object to configure failure and recovery studies. Subnetwork objects. These objects represent logical and physical groupings of nodes and links within a larger topology. Subnetwork objects may be nested within other subnetworks, creating a subnet hierarchy. There are two types of attributes: Model Attributes, which have local significance on nodes, and Simulation Attributes, which apply to all nodes in the network.

SP Guru/Release 11.5

SPM-1-9

1Circuit-Switched Model User Guide

Specialized Models User Guide

Model Attributes
Attributes for the main circuit-switched node models are described below.

PBX Attributes
This section illustrates the main PBX configuration parameters of the circuit-switched model suite. Each PBX has several PBX-specific attributes that are grouped together as an attribute called PBX Parameters.
Figure 1-5 Dialog Box for Specifying PBX Parameters

The PBX Parameters compound attribute includes the following sub-attributes. Address: Specifies the surrounding node's address. If Auto Assigned is selected, then the address is automatically assigned. Call Generation: Specifies call generation parameters. Both dynamic and static calls can be generated, but only one type can be generated at any given time. Static call specification has precedence over dynamic calls.

SPM-1-10

SP Guru/Release 11.5

Specialized Models User Guide

1Circuit-Switched Model User Guide

Figure 1-6 Dialog Box for Specifying Call Generation Parameters

Call Generation is a compound attribute that includes the following attributes: Dynamic Call Parameters: Specifies the parameters for generating dynamic calls, such as the destination address and distributions for interarrival time and duration.
Figure 1-7 Dialog Box for Specifying Dynamic Call Parameters

Static Call Parameters: Specifies static call generation parameters, such as call and duration table names and distributions. Static calls are generated based on call tables specified in external text files (*.gdf). In addition, the traffic scaling attribute specifies the scaling factor applied to traffic flow in the static call table. The scaling factor could be either positive or negative.

SP Guru/Release 11.5

SPM-1-11

1Circuit-Switched Model User Guide

Specialized Models User Guide

Figure 1-8 Dialog Box for Specifying Static Call Parameters

The format of the external text files (*.gdf) for the Call Table Name fields is in erlangs within a matrix. The Call Table Name file specifies the matrix of calls from one PBX to another, where the first column indicates the source PBX addresses and the first row indicates the destination PBX addresses. Each row indicates a source PBX traffic flow, in erlangs, to all destination PBX in the network. The Duration Table Name file specifies the duration of the calls in minutes. Replace the dot placeholders in each file with actual values. To edit the files, from SP Guru, select File > Open. In Files of Type, choose Generic Data File, and select either call_table or dur_table, as shown. Edit the values as necessary.
Figure 1-9 Generic Data File Selection

SPM-1-12

SP Guru/Release 11.5

Specialized Models User Guide

1Circuit-Switched Model User Guide

Start Time: Specifies the simulation time when the PBX will start generating calls. If infinity is chosen, the PBX will not generate any calls. Call Bandwidth: Specifies the amount of bandwidth requested for the call, in bits/second. Call Priority Ratio: Specifies the ratio of high-priority calls to the total number of calls made. If the attribute value is 0, then only low-priority calls will be generated. If the attribute value is 1, then only high-priority calls will be generated. A value of 0.5 generates a 50-50 mix of high- and low-priority calls. Conference Generation: Like the Call Generation attribute, this compound attribute contains conference call generation parameters such as destination group, generation start time, and duration. The Destination Group attribute specifies the name of the conference group. It must contain the addresses of all PBXs that are members of the group. In addition, each conference call can be set up as either a teleconference call or a video conference call. Since video conference and teleconference calls have different bandwidths, your choice of bandwidth determines which kind of call is generated.
Figure 1-10 Dialog Box for Specifying Conference Generation Attributes

Number of Users: Specifies the number of users placing calls from this PBX. Observation Period: Specifies the period of time, or how long, the traffic flow will be observed. Traffic flow, expressed in Erlangs, is the number of packets sent divided by the observation period. Normally, the observation period is one hour. Call Type: Specifies the type of call Toll Free (for 800 and 888 calls), Surcharge (for 900 toll calls) and Regular (for all other types of calls). Voice Compression: Specifies the compression technique used to reduce the amount of bandwidth that is needed for voice calls. Maximum Calls Allowed: Specifies the maximum number of outgoing plus incoming calls that can be open simultaneously at the PBX.
SP Guru/Release 11.5 SPM-1-13

1Circuit-Switched Model User Guide

Specialized Models User Guide

SSP Attributes
This section discusses key SSP configurable parameters. Each SSP has several SSP-specific attributes, which are grouped together in the SSP Parameters compound attribute.
Figure 1-11 Dialog Box for Specifying SSP Parameters

Setup Delay: This compound attribute includes various delay parameters incurred by an SSP as a result of SS7 signaling. ISUP Message Delay: Delay incurred when sending ISUP message call segments. Alerting Delay: Delay incurred when the SSP alerts the originating and/or terminating lines. TCAP Message Delay: Delay incurred when sending TCAP messages to SCPs. This is done only when toll-free (800/888) or toll (900) numbers are used. Announcement/Tone Delay: Delay incurred when sending alerting call segments, which place or remove a tone and alert the originating and/or terminating lines. Connection Delay: Delay incurred when sending connection call segments if one or more users are connected to an SSP. Static Table Usage: Enables or disables the use of static routing tables. Static Table Properties: Specifies the routing table file and the simulation time when the routing tables should be loaded. Switching Capacity: Specifies the SSPs maximum switching capacity. An SSP will not be able to establish a circuit if its maximum bandwidth is less than the combined bandwidth of all the calls it supports.

SPM-1-14

SP Guru/Release 11.5

Specialized Models User Guide

1Circuit-Switched Model User Guide

Max Simultaneous Calls: Specifies the maximum number of active calls that can be processed simultaneously by the SSP. SS7 Signaling Status: Specifies the simulation times when the SSPs ability to receive SS7 signaling messages should be turned on or off. If the SSP cannot receive SS7 messages, no new calls will be established through that SSP, but calls that are already in progress will be maintained.

MSS Attributes
Use the multi-service switch node to configure the attributes determining whether a call is routed over a circuit-switched or packet-switched network.
Figure 1-12 Attributes Dialog Box for a Multi-service Switch

VoATM Parameters: This attribute specifies the encoder and compression schemes for calls that are routed over an ATM network. Figure 1-13 shows the available pre-configured schemes.

SP Guru/Release 11.5

SPM-1-15

1Circuit-Switched Model User Guide

Specialized Models User Guide

Figure 1-13 Pre-configured Schemes for VoATM Parameters

You can manually configure the VoATM Parameters attribute by selecting Edit... from the attribute pull-down menu and specifying the following attributes:
Figure 1-14 Dialog Box for Manually Configuring VoATM Parameters

Silence Length: This attribute specifies the duration of silent periods in the voice over ATM traffic flowing out of the router. The voice traffic generated by the caller and by the callee is modeled using a speech-silence-speech-silence-... pattern. Selecting Edit... from this

SPM-1-16

SP Guru/Release 11.5

Specialized Models User Guide

1Circuit-Switched Model User Guide

attributes pull-down menu allows you to specify an Incoming Silence Length (for the callees silences) and an Outgoing Silence Length (for the callers silences). To model calls where neither party is ever silent, select None from the Silence Length pull-down menu. Talk Spurt Length: This attribute specifies the duration of speech periods in traffic generated by the caller and by the callee. Selecting Edit... from this attributes pull-down menu allows you to specify an Incoming Talk Spurt Length (for the callee) and an Outgoing Talk Spurt Length (for the caller). To model the case where one of the parties never speaks, select None from the Incoming or Outgoing Talk Spurt Length pull-down menu. Encoder Scheme: This attribute specifies the encoder scheme used to packetize voice traffic. You can choose any of the encoder schemes defined in the Application Definition object. If you wish to define your own encoder scheme, or look at the configuration of an existing scheme, open the Application Definition objects attributes and select Edit... from the Voice Encoder Schemes pull-down menu. Voice Frames per Packet: This attribute specifies the number of voice frames in each packet sent out over the ATM network. Voice frames are defined as part of the Encoder Scheme configuration. Specifying too high a number for the Voice Frames per Packet attribute causes the called party to hear gaps in the voice traffic stream. In this case, no data is lost, but periods of silence are introduced as packets must wait for a sufficient number of voice frames before they are sent. Specifying too low a number for this attribute causes network congestion as many packets containing very little data flow across the network. Traffic Generation Mode: This attribute specifies whether or not this node generates traffic (packets) during a simulation. In Call Setup Only mode, calls are set up, but no traffic is generated during the call. Using this mode results in shorter simulation runs. Since the Call Setup Only mode does not generate voice traffic, you should not use this mode if you wish to study network delay or link utilization across the network. For these studies, use the Explicit Traffic mode, which sends packets, generated from the circuit-switched traffic, across the network. VoIP Parameters: This attribute specifies the encoder and compression schemes for calls that are routed over an IP network. From the VoIP Parameters pull-down menu, you can choose one of the pre-configured schemes (same as those listed above for VoATM parameters) or you can select Edit... and manually configure the following attributes: Silence Length Talk Spurt Length Encoder Scheme Voice Frames per Packet For details on any of the attributes listed above, see the description of the analogous VoATM Parameters attributes.
SP Guru/Release 11.5 SPM-1-17

1Circuit-Switched Model User Guide

Specialized Models User Guide

Voice Call Path Preference: This attribute is used to specify path usage preferences according to call priorities. For example, if the multi-service switch has two routing options for outgoing calls, through a circuit-switched network or an IP network, you can specify that only high-priority calls use the circuit-switched network while all low-priority calls use the IP network.
Figure 1-15 Specifying Path Preferences
high-priority calls use this path

low-priority calls use this path

If you are using Call Path Preferences to route calls over an IP network, note that it is not possible to specify which IP interface is used by the call. You can specify that the call is routed through one of the switchs IP interfaces, but you cannot specify which interface is used.

SPM-1-18

SP Guru/Release 11.5

Specialized Models User Guide

1Circuit-Switched Model User Guide

For example, if the multi-service switch is connected to several IP networks, as in the Figure 1-16, you cannot specify that a low-priority call is routed to IP Router 1, but not IP Router 2. When you specify that a call is routed to an IP interface (as shown Figure 1-16s Call Path Preference Table), the model selects one of the IP routers, based on IP routing tables, when the call is set up.
Figure 1-16 Specifying Call Path Preferences for IP Networks

Voice Call Processing Speed: This attribute specifies the number of call setups that the multi-service switch can process per second. A value of 100 indicates that the switch can process 100 call setups per second and that each call setup takes at least 0.01 seconds to process.

Circuit-Switched Attribute Definer


Use the Circuit-Switched Attribute Definer to define conference groups and characterize SS7 performance. Conference Groups: Specifies members of a conference group. Each row in this attribute can be used for an individual conference. SS7 Parameters: Specifies parameters of the SS7 network, such as the number of STP pairs, percentage of STP interconnections, and STP switching delay. (Average estimates for these numbers can be obtained from the ITU-T Recommendation Q.709 and GR-1364-CORE published by Telcordia.)

SP Guru/Release 11.5

SPM-1-19

1Circuit-Switched Model User Guide

Specialized Models User Guide

Simulation Attributes
Simulation attributes apply to all nodes in the network. This model has one simulation attribute. PBX Address Export: Specifies whether the automatically assigned names of PBXs should be exported to a file called pbx_names.gdf. To specify your own destination address for any PBX, you must first run a simulation with this attribute enabled. You need not let the simulation run for the entire duration, a few seconds will suffice. After the pbx_names.gdf file is created in your op_models directory, look up the proper address of each PBX and use it when assigning a destination address in subsequent simulations.

Available Statistics
To analyze the performance of a circuit-switched network, collect several statistics during simulation execution. Statistics are collected on a per-node basis for SSP, PBX, and multi-service switch nodes.
Figure 1-17 Circuit-switched Node Statistics

Example Network
In this section, we look at an example of a circuit-switched network. The example network is composed of three SSPs, each connected to six PBXs. Each SSP is connected to the other SSPs by links consisting of four T1 trunks. Each PBX has 16 users, each of whom makes a 20-minute call every 30 minutes (2 calls/hour). The calls are made to random destinations and all calls

SPM-1-20

SP Guru/Release 11.5

Specialized Models User Guide

1Circuit-Switched Model User Guide

are low-priority. (If the calls were not made to random destinations, we would first need to run the simulation with the PBX Address Export simulation attribute enabled. The first run would give us proper PBX addresses which we would use to specify call destinations.)
Figure 1-18 Example Circuit-switched Network

To verify if the available bandwidth is sufficient, we begin by calculating the amount of traffic generated by each PBX. 2 calls/hour * 16 users = 32 calls/hour Each call requires 64,000 bits of bandwidth, so the maximum load on each link will happen every 30 minutes and will require a capacity of 64,000 * 16 * 6 PBXs = 6,144,000 bits, assuming all calls from the PBX will go through the same link. However, since each link has a capacity of 6,400,000 bits, there will be no blocking due to unavailable bandwidth. Some of the useful statistics obtained from this example are listed below. At PBXs: Calls Connected Calls Blocked Calls Active Traffic Flow (Erlangs)

SP Guru/Release 11.5

SPM-1-21

1Circuit-Switched Model User Guide

Specialized Models User Guide

At SSPs: Link Utilization Bandwidth Switched

SPM-1-22

SP Guru/Release 11.5

Specialized Models User Guide

2DOCSIS Model User Guide

DOCSIS Model User Guide


Data-Over-Cable System Interface Specifications (DOCSIS) is a protocol for exchanging bi-directional signals over a cable network. This paper describes the implementation and usage of the DOCSIS model shipped as part of the specialized model library.

Model Features
The model suite incorporates the following DOCSIS features.
Table 2-1 Model Features
Feature Service Types Description The model supports the following service types: Unsolicited Grant (UG) Real-Time Polling (rtP) Non-Real-Time Polling (nrtP) Best Effort (BE) QoS The model supports the following DOCSIS 1.1 QoS features: Fragmentation Concatenation Contention Piggyback Payload Header Suppression (PHS) RF Specification The following Radio Frequency (RF) specifications are configurable for upstream and downstream channels: Modulation Channel width Data rate Central frequency Multiple channel support Device creator support End of Table 2-1 The model supports multiple channels in the upstream and downstream direction. You can use the Device Creator feature to create new DOCSIS node models.

The DOCSIS model implementation is based on the Radio Frequency (RF) Interface Specification 1.1. You can see this document for detailed background information on the DOCSIS protocol. DOCSIS Protocol on page SPM-2-3 of this chapter briefly describes some of the main protocol features.
SP Guru/Release 11.5 SPM-2-1

2DOCSIS Model User Guide

Specialized Models User Guide

Model Limitations
The following DOCSIS features have not been modeled: Dynamic creation, modification, or deletion of services. Once the service is established at ranging time, it is in effect until the end of the simulation. This affects the behavior of flows that use the upstream scheduling services that periodically receive grants (UGS, rtPS, nrtPS). These grants are issued from ranging time to the end of the simulation whether or not the CM has data to send. The grants are issued even if the data flow from the station that is connected to the CM has not yet started or has already finished. This does not affect behavior of best effort service because best effort service always sends a request before it sends data and does not send a request unless there is data to send. Multiple service types per cable modem. The model supports only one service type per cable modem and does not support several different service types running on the same cable modem in a simulation. If several applications are running on a station that is connected to a CM, all of them use the same service type as selected on the CM. Quality of service on the downstream channel. Because the DOCSIS MAC protocol is below the IP layer (which provides QoS services), you can work around this limitation by configuring IP QoS parameters to obtain the desired QoS. Oversubscription. This affects only service types that request grants (UGS, rtPS, nrtPS). The total number of slots allocated in each MAP is configured using the MAP Profiles > Time Covered by MAP > Map Interarrival Time attribute. Each MAP must contain at least the number of contention slots specified in the MAP Profiles > Request/Data IE > Number of Contention Slots attribute and typically a MAP also contains some management slots. Thus, the number of slots allocated to any grant service in a given MAP will be the total number of slots in a MAP minus the number of contention and management slots. The CMTS never issues more than this number of slots to CMs. Should any CM request a service for which this number is exceeded, the service is denied. Security features. Overhead due to security is not modeled. Fine granularity on QoS. Some QoS parameters, such as delay guarantee are not currently modeled. There are also some parameters, such as RTP Polling Interval, which are defined as macros in the current model and are not exposed as attributes. If requested, OPNET may model some or all of the missing features in an upcoming release.

SPM-2-2

SP Guru/Release 11.5

Specialized Models User Guide

2DOCSIS Model User Guide

DOCSIS Protocol
The DOCSIS protocol defines radio frequency interface specifications for high-speed data-over-cable systems. Transmission over the cable system is realized by the cable modem termination system (CMTS) at the headend and by a cable modem at each customer location. In the DOCSIS media access (MAC) protocol, the CMTS controls cable modem access to the upstream channels. The upstream channel is modeled as a stream of mini-slots whose use is defined by information element (IE) fields in the allocation MAP MAC Management message. The CMTS periodically transmits allocation MAP messages on the downstream channel. Mini-slots can be used as grants for stations to transmit data, as slots available for contention transmission, or as opportunities for new stations to join. The protocol defines the following IEs: request, request/data, short grant, long grant, initial maintenance, and station maintenance. Since its original specification (version 1.0), the protocol has been enhanced (in version 1.1) with quality of service and security features needed for voice communication. Some vendors implemented DOCSIS 1.0+, which includes some of the QoS features defined in DOCSIS 1.1. Key enhancements of DOCSIS 1.1 over the initial specification appear below: New QoS service flow model defining several service categories. Each service is tailored to a specific type of data flow. The basic services are listed below: Unsolicited Grant Service (UGS) Real-Time Polling Service (rtPS) Unsolicited Grant Service with Activity Detection (UGS-AD) Non-Real-Time Polling Service (nrtPS) Best Effort (BE) service Support for multiple service flows per cable modem allows a single modem to support a combination of video, voice and data packets. Dynamic service establishment allows MAC messages to dynamically create, modify and delete traffic service flows. Payload Header Suppression (PHS) conserves link-layer bandwidth by suppressing unnecessary packet headers on both upstream and downstream traffic flows. Layer 2 fragmentation on the upstream flow prevents large data packets from affecting real-time traffic. Concatenation allows a cable modem to send multiple MAC frames in the same transmission.
SP Guru/Release 11.5 SPM-2-3

2DOCSIS Model User Guide

Specialized Models User Guide

DOCSIS Network
In a typical cable network configuration, a headend cable modem termination system (CMTS) communicates with the cable modems (CMs) located in subscribers homes to create a virtual local area network (LAN) connection. The headend has two cable network interfaces and one point-to-point interface. Each cable network interface specifies a separate cable network domain and the point-to-point interface routes traffic to an external network (such as the Internet). The service allows transparent bi-directional transfer of Internet Protocol (IP) traffic between the CMTS and the CMs over an all-coaxial or hybrid-fiber/coax cable network. It delivers video, voice, and data for homes and businesses over a single broadband network. DOCSIS supports downstream (to the user) data rates of 27-56 Mbps and an aggregate upstream data rate of up to 10 Mbps, with individual upstream data rates between 500 kbps and 3Mbps.
Figure 2-1 A Cable Network
Bus tap

HeadendCMTS

To Internet DOCSIS Bus

CM Stations

SPM-2-4

SP Guru/Release 11.5

Specialized Models User Guide

2DOCSIS Model User Guide

Node and Link Models


This section describes the node and link models available in the DOCSIS model suite. To function, DOCSIS nodes must be connected to a DOCSIS bus. DOCSIS node and link models appear in the DOCSIS and DOCSIS_advanced object palettes. Full DOCSIS configuration is available in all DOCSIS node modelsno DOCSIS-related attributes are hidden in the basic node models.

CM Nodes
Cable modem hosts can send and receive application traffic from any of the standard network applications (voice, video conferencing, HTTP,...). The model has three node models that simulate CM functionality.
Table 2-2 Simulating CM Functionality
Use this node... docsis_ethernet_cable_modem docsis_cm_wkstn To model... a cable modem connected to an ethernet port a combined Ethernet workstation and cable modem a combined Ethernet server and cable modem

docsis_cm_server End of Table 2-2

Figure 2-2 Supported CM Nodes


s

CMTS Nodes
The CMTS nodes model cable network headend nodes. Two types of CMTS nodes are available: a CMTS gateway and a CMTS server.
Figure 2-3 Supported CMTS Nodes

SP Guru/Release 11.5

SPM-2-5

2DOCSIS Model User Guide

Specialized Models User Guide

Router and gateway nodes. Router and gateway nodes typically connect the bus to the cable network. Each RF interface is managed by a separate CMTS process and is independent of other RF interfaces. CMTS server model. This node incorporates all of the CMTS functionality, but can also send and receive application data. Other differences between the CMTS router and the CMTS server are listed below: the CMTS server has only one RF interface (routers have at least two interfaces) the CMTS server contains a server module that allows the node to send and receive application data (routers do not usually have a server) You can use this OPNET-specific node to simplify your network model if all of the following apply: traffic is exchanged between the cable network and the internet you are interested in the cable network only you do not have information about the infrastructure of the external network In this case, it is assumed that the delay caused by the outside network is negligible compared to the delay within the cable network.

Link Model
A DOCSIS bus link model connects the CMTS and cable modem hosts. Taps connect individual host and CMTS nodes to the bus (see Figure 2-1 on page SPM-2-4). The link is modeled as a bus with a single channel that uses different frequencies for CMTS and CM data.
Figure 2-4 DOCSIS Link Models

DOCSIS Bus

Bus tap

DOCSIS Attribute Configuration Object


This global configuration object allows you to configure general DOCSIS parameters that can be applied to DOCSIS nodes in the network. Use this object to configure profiles for MAP, modulation, physical media overhead, upstream physical properties, and payload header suppression parameters. These profiles can then be deployed on CMTS nodes in the network.
Figure 2-5 DOCSIS Attribute Configuration Object

SPM-2-6

SP Guru/Release 11.5

Specialized Models User Guide

2DOCSIS Model User Guide

Supported Communications
The model supports the following communication configurations: servers and workstations on the same bus servers and workstations on two different buses servers and workstations on separate networksfor example, the workstations may be on a cable interface while the servers are on an external non-cable network A cable modem host on one bus can establish a connection to any host that has TCP/IP on a cable bus or on an external network.

Model Attributes
The main DOCSIS model attributes are described below. Additional configuration information is provided in later sections of the paper.

DOCSIS Configuration Object


In the DOCSIS configuration object, you can define profiles for MAP, modulation, PHS, physical media overhead, and upstream physical parameters. Once defined, these profiles can be applied to any number of CM or CMTS nodes. Each DOCSIS configuration object attribute is described below.
Figure 2-6 DOCSIS Configuration Object Attributes

SP Guru/Release 11.5

SPM-2-7

2DOCSIS Model User Guide

Specialized Models User Guide

Downstream Channel Profiles. This attribute defines profiles that allow you to configure the RF specifications (modulation, channel width, data rate, and center frequency) and interleave latency of downstream channels. Profiles defined here are applied to the DOCSIS > DOCSIS CMTS Parameters > Physical Media Parameter > Downstream Channels attribute on a CMTS node model.
Figure 2-7 Downstream Channel Profiles

Modulation. This attribute specifies the channels modulation type. Because the values of other attributes depend on the modulation type, you should take care when changing this attribute. When you change the modulation type, the model automatically recalculates the data rate and the interleave latency. Data Rate. This attribute allows you to explicitly set the downstream data rate on the channel. Alternatively, you can specify the modulation and channel width and allow the model to automatically calculate the data rate. Since the model re-calculates the data rate whenever the modulation or channel width changes, be sure to set the data rate after the other two if you wish to use an explicitly specified data rate. Channel Width. This attribute specifies the width of the downstream channel. When you change the channel width, the model recalculates the data rate based on the modulation type. Center Frequency. This attribute specifies the channels center frequency. Interleave Latency. This attribute specifies the downstream delay introduced by the interleaver. Interleave latency determines the maximum number of packets transmitted on a downstream channel. The value of the interleave delay depends on the interleave depth, the increments, and the downstream modulation type. Standard values for these factors are tabulated in the DOCSIS 1.1 specifications. Higher values for the interleave depth offer protection from longer bursts, but introduce additional delay. The following sub-attributes comprise this attribute. I (Interleave Depth) J (Increment) Latency
SPM-2-8 SP Guru/Release 11.5

Specialized Models User Guide

2DOCSIS Model User Guide

You can explicitly specify the interleave latency delay by setting the Latency sub-attribute, or you can allow the model to automatically calculate the latency based on the modulation, interleave depth, and the number of taps the interleaver uses. MAP Profiles. This attribute defines the bandwidth allocation MAP profiles that are applied to the upstream channel parameters on CMTS nodes.
Figure 2-8 Profile Details of the Default MAP Profile

It consists of the following attributes: Time Covered by MAP. This compound attribute specifies the MAP interarrival time. It is defined by the following sub-attributes.
Figure 2-9 Time Covered by MAP Compound Attribute Table

Time Covered by MAP. This attribute specifies whether the MAP interarrival time is constant or variableif constant, its value is specified by the Map Interarrival Time attribute. MAP Interarrival Time. This attribute specifies the time covered by MAP when the MAP interarrival time is constant. The actual time covered by MAP is calculated as the sum of time required for the configured contention slots, UGS grants, and reservation requests. If the actual time covered by MAP is less than the time specified by this attribute, contention slots are added to make up the missing time. If the actual time covered by MAP is greater than the specified time, the MAP size is limited by the maximum number of MAP information elements (IEs) and the number of bytes covered by one MAP. Grant Interval. This attribute specifies how often the CMTS issues UGS grants to the CMs it manages. To use the individual settings specified in each CMs Nominal Grant Interval attribute, set this attribute to As Requested by CMs (the default setting). Otherwise, the grant interval specified here is used for each CM.

SP Guru/Release 11.5

SPM-2-9

2DOCSIS Model User Guide

Specialized Models User Guide

For UGS, when the time covered by MAP is constant, the MAP Interarrival Time should be large enough to accommodate all grants needed for UGS service plus the configured number of contention slots that use Request/Slots IE. If the configuration cannot accommodate all grants, a simulation log is generated indicating the total number of slots in the MAP and the configured number of slots for a MAP. When the time covered by MAP varies, the MAP Interarrival Time is automatically calculated each time a MAP is created. Request/Data IE. This attribute specifies parameters required to transmit request/data IEs in contention slots. Specifically, it allows you to set the following attributes: Data Backoff Start Data Backoff End Number of Contention Slots The CMs use Data Backoff Start and Data Backoff End to select their internal backoff window to start and end transmissions. The backoff window indicates the number of contention opportunities the CM must defer before transmitting. Number of Contention Slots specifies the number of slots allocated in each MAP for contention. The number of contention slots indicated in this attribute are inserted into the MAP when the MAP is created.
Figure 2-10 Specifying Request/Data IE

Short Grant IE. This attribute specifies the short grant limit, which is the maximum number of bytes that can be sent in a short IE. Long Grant IE. This attribute specifies the maximum payload size the CM can send in one long data slot. Initial Maintenance IE. This attribute specifies the initial maintenance area, which is the number of slots per second allocated for the initial ranging of CMs. Station Maintenance IE. This attribute specifies the number of slots per second needed for system maintenance on one station. Modulation Profiles. This attribute defines profiles that are applied to the Modulation Parameters attribute of upstream channels. Each modulation profile is a combination of four attribute settings. Request Frames Overhead
SPM-2-10 SP Guru/Release 11.5

Specialized Models User Guide

2DOCSIS Model User Guide

Request/Data Frames Overhead Short Data Frames Overhead Long Data Frames Overhead Each attribute is specified by a Physical Media Profile, which is described later in this section. You should, therefore, define the Physical Media Profiles attribute before configuring modulation profiles.
Figure 2-11 Specifying Modulation Profiles

Use the Physical Media Parameters attribute to view/edit configuration details of these values.

PHS Profiles. This attribute allows you to define payload header suppression profiles. These profiles can then be applied to individual CMs to suppress some of the header information sent out with each packet. When configuring a PHS profile, you can specify one of the preconfigured options in the Suppression Details attribute or you can create a custom configuration. The model allows you to suppress any combination of transport (TCP or UDP), IP, and Ethernet headers. When suppressing transport headers, be sure to specify the correct transport protocolspecifying the wrong protocol suppresses an incorrect number of bytes.
Figure 2-12 Default PHS Schemes

SP Guru/Release 11.5

SPM-2-11

2DOCSIS Model User Guide

Specialized Models User Guide

Physical Media Overhead Profiles. This attribute allows you to define the physical media (request, request/data, short data, and long data frames overhead) profiles that are the building blocks of the modulation profiles. The profile attributes (described below) allow you to configure the FEC codeword length and related parameters. These attributes determine the physical layer frame size. Before transmitting a packet received from a higher layer, the CMTS divides the packet into codewords. It then adds FEC error correction bytes to each codeword and preamble length bits to each frame. Preamble Length. This attribute specifies the preamble length of the frame, in bits. It defines the size of a synchronizing string of modulation symbols that let the receiver find the phase and timing of the transmitted burst. FEC Error Correction. This attribute specifies the strength of the FEC error correction code by specifying the number of bytes that can be corrected per FEC codeword. Valid values are 0 to 10, where 0 indicates that the FEC is off. FEC Codeword Length. This attribute specifies the number of bytes in a codeword. Guard Time. This attribute specifies the time between successive bursts. This time occurs at the end of a burst transmission and ensures that bursts do not overlap. Last Codeword Mode. This attribute specifies whether the last codeword is of type Fixed or Shortened.
Figure 2-13 Default Physical Media Profiles

SPM-2-12

SP Guru/Release 11.5

Specialized Models User Guide

2DOCSIS Model User Guide

Upstream Physical Profiles. This attribute defines the physical profiles applied to the upstream channels of CMTS nodes. The options appearing in this attributes pull-down menu allow you to specify modulation and data rate values only. To configure other parameters (described below), select Edit... from the pull-down menu.
Figure 2-14 Default Upstream Physical Profiles

modulation (data rate)

Physical Parameters. This attribute configures the RF specifications for upstream channels. The following physical parameters can be configured: modulation data rate channel width center frequency bytes per minislot As in the Upstream Physical Profiles attribute, the options appearing in this sub-attributes pull-down menu allow you to specify modulation and data rate values only. To configure other parameters, select Edit... from the pull-down menu. For information about the Modulation, Data Rate, Channel Width, and Center Frequency attributes, refer to the corresponding descriptions for the Downstream Channel Profiles attributes. Bytes per Minislot. This attribute determines the number of bytes per transmission opportunity (minislot). The MAP uses time units of minislots, where each minislot is a unit of transmission opportunity. In other words, a minislot is the byte-time needed for transmission of a fixed number of bytes. Minislots are expressed as an integer multiple of ticks, where each tick corresponds to 6.25 s. This attribute includes the Ticks per Minislot and Bytes per Minislot sub-attributes. When you specify the number of Ticks per Minislot, the model automatically calculates the corresponding number of bytes per minislot, based on the upstream data rate and the number of ticks. The model recalculates the number of bytes per minislot if either of the other parameters change.
SP Guru/Release 11.5 SPM-2-13

2DOCSIS Model User Guide

Specialized Models User Guide

QoS Parameters. This attribute specifies whether the channel supports fragmentation and concatenation. Management Message Intervals. This attribute specifies the timing intervals for UCD messages on a per-channel basis. The model allows you to specify the timing intervals of other management messages (namely, SYNC messages) on a per-CMTS basis. See CMTS Attributes on page SPM-2-17 for more information. UCD Interarrival Time. This attribute specifies the time between transmissions of UCD messages. The protocol-defined maximum value is 2 sec.
Figure 2-15 Configuring Upstream Channel Parameters

Default settings support fragmentation and concatenation.

SPM-2-14

SP Guru/Release 11.5

Specialized Models User Guide

2DOCSIS Model User Guide

CM Attributes
On CM nodes, all DOCSIS attributes are grouped in the DOCSIS CM Parameters attribute.
Figure 2-16 DOCSIS CM Parameters

station_address. This attribute specifies the nodes DOCSIS MAC address. Modifying this attribute does not usually affect simulation results, however, you may wish to specify a value when tracking CM behavior for debugging purposes. Protocol Version. This attribute specifies the DOCSIS version implemented in the cable modem. OPNET models DOCSIS 1.0, DOCSIS 1.0+, and DOCSIS 1.1 cable modems. Cable modems with different versions of the protocol can be connected to the same bus. Upstream Scheduling Service. This attribute defines the QoS service classes available at the CM. The models support the four service types described below. Unsolicited Grant Service offers fixed-size grants on a real-time periodic basis and was designed for service flows that generate fixed-size data packets on a periodic basis (such as Voice over IP). The unsolicited grant size is calculated based on the configured data size received from a higher layer and physical sublayer overhead. The grant interval can be configured individually on each CM or globally on the CMTS (for all CMs it manages). Real-Time Polling Service offers real-time periodic, unicast request opportunities. It supports variable grant sizes and was designed for real-time service flows that periodically generate data packets of variable size. Non-Real-Time Polling Service offers unicast polls on a regular basis to ensure that the flow receives request opportunities even during network congestion. In addition, the CMs can transmit in contention slots. This service was designed to support non-real-time service flows requiring variable-size data grants on a regular basis. Best Effort Service provides efficient service to best-effort traffic.

SP Guru/Release 11.5

SPM-2-15

2DOCSIS Model User Guide

Specialized Models User Guide

Grant Size. This is used to indicate the size of the grant requested for a CM using UGS. This attribute is not used for other service types. Nominal Grant Interval. This attribute, applicable only with UGS, specifies the requested time between grants issued to this CM. The CMTS may override this value if its MAP profiles Time Covered by MAP > Grant Interval attribute is set to a value other than As Requested by CMs. Priority. This parameter defines the priority for requests made by a cable modem. It determines the order in which CMTS grants requests. Since it is used when the CM sends requests, it applies to best effort, real-time, and non-real-time polling services. Valid values are 0 to 7, where 0 is the highest priority. Contention. This attribute specifies if the CM can send data in the contention slots. Contention is automatically enabled for service types using contention slots (best effort and non-real-time polling services). Piggyback. This attribute specifies if this node can piggyback requests to outgoing frames. It can be used with best effort and non-real-time polling services only. Fragmentation. When this attribute is enabled, the CM fragments large data packets and transmits them (on the upstream channel) in the available time slots. Note that upstream channel must also support fragmentation (in the QoS Parameter attribute of the Upstream Physical profile applied to the channel). Concatenation. When this attribute is enabled, the CM can send multiple MAC frames during one transmission opportunity, instead of making individual grant requests for each frame. This saves upstream bandwidth when sending many small packets (such as TCP acknowledgments). When enabling concatenation, also enable fragmentation. Otherwise, packets that are too large for transmission in a single MAP are not transmitted. Enabling fragmentation allows these packets to be divided into fragments that can be accommodated by the MAP. Note that the upstream channel must also support concatenation (in the QoS Parameter attribute of the Upstream Physical profile applied to the channel). PHS Profiles. This attribute specifies which PHS profiles are used at the cable modem. You can specify different profiles for the upstream and downstream channels. Before you can specify a PHS profile in this attribute, you must first define the profile in the DOCSIS configuration object.

SPM-2-16

SP Guru/Release 11.5

Specialized Models User Guide

2DOCSIS Model User Guide

CMTS Attributes
All DOCSIS attributes on the CMTS node are grouped in the DOCSIS CMTS Parameters attribute, which is configurable on a per-interface basis.
Figure 2-17 Configuring DOCSIS Parameters for a Router Interface

This CMTS has 2 DOCSIS interfaces, which are configured independently.

station_address. This attribute specifies the nodes DOCSIS MAC address. Modifying this attribute does not usually affect simulation results; however, you may wish to specify a value to track a node for debugging purposes. Physical Media Parameters. This compound attribute groups parameters defining the physical characteristics of the CMTS downstream and upstream channels. Upstream Channels. This attribute configures upstream channels on this CMTS. Configure each channel as a separate row in the Upstream Channels Table by assigning an integer Channel ID (used for identification purposes only), an Upstream Physical profile, a MAP profile, a Modulation profile, and a downstream channel ID. The profiles are defined in the DOCSIS configuration object. The Associated Downstream attribute specifies which downstream channel is associated with this upstream channel.

SP Guru/Release 11.5

SPM-2-17

2DOCSIS Model User Guide

Specialized Models User Guide

Figure 2-18 Configuring Upstream Channels


The Default Associated Downstream channel is Channel 0.

Downstream Channels. This attribute configures downstream channels on this CMTS. Configure each channel as a separate row in the Downstream Channels Table by assigning an integer Channel ID (used for identification purposes only) and a downstream channel profile. The downstream channel profiles are defined in the DOCSIS configuration object.
Figure 2-19 Configuring the Downstream Channel

SPM-2-18

SP Guru/Release 11.5

Specialized Models User Guide

2DOCSIS Model User Guide

Management Message Intervals. The CMTS and CM use MAP, SYNC, UCD, and ranging request messages for management purposes. The timing intervals for SYNC and ranging request messages are defined in this compound attribute. UCD is defined on a per-channel basis and MAP is defined in the MAP Parameters attribute. The following sub-attributes comprise Management Message Intervals: End of Ranging. This attribute specifies when ranging ends, which is also the time when a service registration is performed. Because the model does not support dynamic service establishment, ranging messages are exchanged only at the beginning of the simulation. Therefore, the ranging process should be completed before the first application packet is generated. Otherwise, a simulation error (abort) occurs and an error message is written to the simulation log. SYNC Interarrival Time. This attribute specifies the time between transmissions of SYNC messages. The protocol-defined maximum value is 0.2 sec.

Simulation Attributes
Simulation attributes apply to all nodes in the network model. The DOCSIS model suite has one simulation attribute. DOCSIS Sim Efficiency. When this attribute is enabled, only the first DOCSIS management messages (UCD and SYNC) are modeled. When disabled, management messages are sent periodically throughout the simulation. After the first UCD and SYNC messages, later management messages do not contain new information. This is because the network model does not change during a simulation. Simulation run time decreases when subsequent UCD and SYNC messages are not explicitly modeled. Consider enabling this attribute if DOCSIS management messages do not significantly impact system performance.

Model Configuration
There are three areas to configure when using DOCSIS in your network model. DOCSIS configuration object Cable Modem (CM) Cable Modem Termination Station (CMTS) This section discusses how to configure these objects to support DOCSIS.

SP Guru/Release 11.5

SPM-2-19

2DOCSIS Model User Guide

Specialized Models User Guide

DOCSIS Configuration Object


The DOCSIS configuration object contains default profiles for all attributes. You can edit these profiles or (preferably) create your own profiles.

Procedure 2-1 Creating a Profile for a DOCSIS Configuration Object Attribute 1 Double-click in the attributes Value field to open the attributes Profiles Table. 2 Add a row to the table and give the new profile a name. 3 Double-click in the attribute Details column to open the Details table and configure the profile. End of Procedure 2-1

Note the following guidelines when configuring the profile attributes described below.
MAP Parameters

Configure the Request/Data IE parameter to reflect the required values for Data Backoff Start, Data Backoff End, and Number of Contention Slots. Set the Short Grant IE to the required value for short grant limit. Configure Long Grant IE to set the required value for Maximum Payload Size.
Management Message Intervals

Configure the interarrival times according to simulation requirements. If the values are too low, many management messages are created, which can slow down the simulation.
QoS Parameters

It is a good idea to always support both fragmentation and concatenation in the CMTS profiles. You can use the CM attributes to control whether fragmentation and concatenation occurs. If the CMTS does not support these QoS parameters, fragmentation and concatenation will not occur, even if enabled at the CM node.

SPM-2-20

SP Guru/Release 11.5

Specialized Models User Guide

2DOCSIS Model User Guide

CM Configuration
On cable modem nodes, DOCSIS parameters are configured in the CM nodes DOCSIS CM Parameters compound attribute. First, configure the DOCSIS CM attributes listed below, in the order indicated. Once these have been configured, you can set the remaining attributes. 1) Protocol Version specifies the DOCSIS protocol version supported on the CM. Select DOCSIS 1.0, 1.0+, or 1.1 from the pull-down menu. Once the version is selected, only attributes meaningful for that version are configurable. If a particular attribute is not supported on the selected version, its value is set to N/A (not applicable). 2) Upstream Scheduling Service specifies the upstream scheduling service requested by the CM. The attributes below it (in the dialog box) depend on the service type specified here. For example, Best Effort service does not use grants, so the Grant Size is set to N/A. Similarly, Non-Real-Time Polling service automatically sets the Contention attribute to Enabled, in accordance with its service definition. 3) Grant Size specifies the size of the grant requested by the CM. The grant size should exceed the combined value of the maximum size of a segment expected from a higher layer and the physical layer overhead. For example, if using TCP over Ethernet, the requested grant size should exceed the combined value of the following: a) TCP Maximum Segment Size b) IP Header Size c) Ethernet size d) physical layer overhead Because the model does not support oversubscription and fragmentation, the CM cannot send the packet if the MSS is greater than the grant size. 4) Priority is defined for CMs with Best Effort and Non-Real-Time Grant services.

SP Guru/Release 11.5

SPM-2-21

2DOCSIS Model User Guide

Specialized Models User Guide

CMTS Configuration
On CMTS nodes (servers or gateways), DOCSIS parameters are configured in the CMTS nodes DOCSIS CMTS Parameters compound attribute. The default CMTS configuration has one upstream channel and one downstream channel. You can configure additional upstream or downstream channels in the Physical Media Parameters attribute.

Procedure 2-2 Configuring One or More Upstream/Downstream Channel(s) on a CMTS Node 1 Open the Physical Media Parameters > Upstream/Downstream Channels attribute dialog box. 2 Specify a Channel ID to identify the channel. 3 Specify the desired profiles in the Channels Table. 4 Add additional channels by increasing the number of rows in the table. Repeat steps 2 and 3 for each channel (row). End of Procedure 2-2

Note the following dependencies when configuring the Downstream Channel Profiles and the Physical Parameters attribute of the Upstream Physical profile (in the DOCSIS configuration object). changing the Modulation or Channel Width automatically adjusts the Data Rate attribute the data rate can be specified explicitly (be sure to setor resetthis value after changing the Modulation or Channel Width attributes) changing the Modulation affects the Interleave Latency (since modulation is used in calculating interleave latency)

SPM-2-22

SP Guru/Release 11.5

Specialized Models User Guide

2DOCSIS Model User Guide

Available Statistics
The following statistics are available to analyze your DOCSIS network: DOCSIS Global Statistics, DOCSIS Node Statistics, and DOCSIS MAP Node Statistics. DOCSIS Global Statistics capture the end-to-end delay of frames accepted by the MAC DOCSIS layer. This delay is measured from the time a frame is submitted for transmission to the MAC DOCSIS layer at the sending side (either CM or CMTS) to the time the frame is received at the receiving side.
Figure 2-20 DOCSIS Global Statistics

fig

DOCSIS Node Statistics comprise data statistics, management message statistics, delay statistics, and CM MAC statistics. These statistics are collected on a per-channel basis. Data statistics show the traffic received by the node and the load on that node. Management message statistics show the number of DOCSIS management messages (MAP, SYNC, UCD, ranging request) sent by CMTS and received by CM. Delay shows the end-to-end delay of frames accepted by the MAC DOCSIS layer at this node CM MAC statistics include collision count and deference window size (log2). Collision count shows the number of collisions encountered by the DOCSIS MAC layer in this node. This statistic is collected for both data and requests. Deference window size shows the size of the deference window.

SP Guru/Release 11.5

SPM-2-23

2DOCSIS Model User Guide

Specialized Models User Guide

Figure 2-21 DOCSIS Node Statistics

When using gateway nodes in your model, you can choose results on a per-interface basis.

DOCSIS MAP Statistics show information about MAP parameters such as contention time, number of different types of IEs in a MAP, request queue and subqueue lengths, reserved slot time in MAPs, and time between MAPs. By default, these statistics are collected in Average mode. To obtain exact values, you may want to collect the statistics in All Values mode. See the Tracing and Debugging section for more information on using the All Values collection mode.

SPM-2-24

SP Guru/Release 11.5

Specialized Models User Guide

2DOCSIS Model User Guide

Figure 2-22 DOCSIS MAP Statistics

Simulation Logs
Log messages are included in the model to provide feedback on events occurring during a simulation. A simulation log message may inform you of the following issues: configuration problems (such as oversubscription of services, which is not supported) insufficient resources to grant requests (which may be normal model behavior) It is a good idea to check the simulation log after running a simulation.

SP Guru/Release 11.5

SPM-2-25

2DOCSIS Model User Guide

Specialized Models User Guide

The next figure shows a simulation log message that states that there were not enough resources to grant all requests received in registration messages from cable modems. Since the model does not allow oversubscription, the simulation is terminated with a request to reconfigure the requested quality of service on cable modems or the MAP parameters on a CMTS.
Figure 2-23 A DOCSIS Simulation Log Message

SPM-2-26

SP Guru/Release 11.5

Specialized Models User Guide

2DOCSIS Model User Guide

Example Project
The example in this section looks at how changing the upstream scheduling service affects voice application end-to-end delay.

Scenario Description
The network shown in the next diagram is configured with 10 CM workstations running voice application sessions. Each voice application session is between a workstation in the cable domain and a workstation outside the cable domain. All of the external workstations are grouped as one point-to-point workstation, labelled External Node. The CMTS node, a gateway, acts as the interface between the cable domain and the external domain.
Figure 2-24 Example DOCSIS Network

Configuration
The network is configured as follows: The voice application traffic is configured in the Application and Profile configuration objects. The CMTS is configured such that the Time Covered by MAP attribute (in the MAP profile assigned to the CMTS) is large enough to accommodate all requests. All CM nodes support version 1.1 of the protocol. Two scenarios compare different service types: one scenario uses Best Effort service while another scenario uses Unsolicited Grant service.

SP Guru/Release 11.5

SPM-2-27

2DOCSIS Model User Guide

Specialized Models User Guide

Results
The results (shown in the next diagram) indicate that the packet end-to-end delay of the voice application is higher for Best Effort service than for Unsolicited Grant service. This is because a CM using UGS does not have to send a request before sending data.
Figure 2-25 Packet End-to-end Delay for Example Scenario

Possible Project Modifications


You can study other performance metrics by modifying certain scenario parameters. A few of these studies are suggested below. the effect of concatenation on end-to-end delay the effect of different grant sizes in UGS on the delay the effect of using different services (rTP, nRTP,...) the effect of changing physical link parameters (bandwidth, modulation,...) the effect of changing MAP parameters

SPM-2-28

SP Guru/Release 11.5

Specialized Models User Guide

3IPv6 Model User Guide

IPv6 Model User Guide


Internet Protocol, Version 6 (IPv6) is a newer version of the Internet Protocol that was designed as a successor to IP, Version 4 (IPv4). This document describes key features of the IPv6 model shipped as part of OPNETs specialized model library.

SP Guru/Release 11.5

SPM-3-1

3IPv6 Model User Guide

Specialized Models User Guide

Model Features
The model implements the following protocol features.
Table 3-1 IPv6 Model Features (Part 1 of 2)
Feature IPv6 address specification Description IPv6 link-local addresses and global addresses can be specified for individual IP interfaces. You can manually specify IPv6 addresses or you can use the Protocols > IP > IPv6 > Auto Assign IPv6 Addresses menu operation to automatically assign addresses before running a simulation. You can view the configured addresses in a network by creating a user defined report (UDR). Stateless address auto-configuration is also supported for host nodes running IPv6. Static routing table Static routes to IPv6 destinations can be configured on gateway nodes. Neighbor discovery is configurable on a per-interface basis on all router and host nodes. The following types of IPv6 tunnels are supported. Manual Automatic Automatic 6to4 Routing protocols The model supports the following routing protocols within an IPv6 network: RIPng OSPFv3 AODV, DSR, and OLSR (MANET routing protocols) Application support All of the application models (standard network applications and the custom application) also work with the IPv6 model. You can configure traffic demands between IPv6 interfaces, including mobile IPv6 interfaces, using the standard ip_traffic_flow demand. Both endpoints must be configured as IPv6 interfaces (or IPv4 interfaces) but you cannot configure a demand between an IPv6 interface and an IPv4 interface. Ping packets can be sent to IPv6 destinations. The model also includes an option to record the route chosen by the ping packet.

Neighbor discovery

IPv6 tunnels

Demand support

IPv6 ping

SPM-3-2

SP Guru/Release 11.5

Specialized Models User Guide

3IPv6 Model User Guide

Table 3-1 IPv6 Model Features (Part 2 of 2)


Feature Layer-2 support Description The model supports IPv6 on all standard layer-2 protocols (such as Ethernet, Token Ring, ATM, WLAN, and Frame Relay). All of the IP QoS features supported for IPv4 are also modeled for IPv6. For more information about the IP QoS model, see Chapter 11 IP QoS Model User Guide on page STM-11-1. Mobile nodes can connect within and across IPv6 networks.

QoS support

Mobile IPv6 End of Table 3-1

Table 3-2

Summary of IPv6 Support in SP Guru


Supports IPv6 No No No No No Yes Special Requirements None None None None None License for IPv6 specialized model.

Technology Device Configuration Import Import from VNE Server Virtual Network Interface NetDoctor Flow Analysis Discrete event simulation

End of Table 3-2

This chapter covers the following topics: Model Features Model Limitations Menu Operations Configuring IPv6 Migrating to IPv6 Using Mobile IPv6 Analyzing IPv6 Configuration Reference Documents

SP Guru/Release 11.5

SPM-3-3

3IPv6 Model User Guide

Specialized Models User Guide

Model Limitations
The following features have not been implemented. They may be included in upcoming model releases. Interface MTU. Since Path MTU discovery is not implemented, all IPv6 interfaces are assumed to have an MTU of 1500. This is the recommended minimum value of MTU for IPv6-enabled interfaces (according to RFC 2460. Sec 5). This value is needed to ensure that IPv6 packets are not fragmented at intermediate nodes (according to RFC 2460 Sec 4.5). Redistribution. Redistribution is not supported within IPv6 protocols (such as from OSPFv3 to RIPng) or between IPv4 and IPv6 (such as to/from RIPng and RIP).

SPM-3-4

SP Guru/Release 11.5

Specialized Models User Guide

3IPv6 Model User Guide

Menu Operations
The Protocols > IP > IPv6 menu includes several operations to help you configure IPv6 in a network model.
Table 3-3 IPv6 Menu Operations
Description Enables IPv6 and assigns IPv6 global addresses to physical and loopback interfaces in the network that do not yet have an IPv6 global address. If no links are selected in the workspace, this operation assigns an IPv6 address to all of the connected interfaces in the network. If you do not want to configure IPv6 addresses on all of the connected nodes, select the links connected to the interfaces you want to configure before selecting this menu operation. Clear IPv6 Addresses Deletes the global and link-local IPv6 addresses configured on all interfaces (physical, loopback, VLAN, tunnel, aggregate, and sub -interfaces) in the network. This operation also disables IPv6 on the affected interfaces by setting the link-local address to Not Active. Configure Interface Status... Lets you enable or disable IPv6 on all interfaces in the network or on the currently selected interfaces in the network. Configures all physical and loopback interfaces in the network to run IPv6. This is done by ensuring that the link-local address is set to a value other than Not Active for all interfaces in the network. Disables IPv6 functionality for all interfaces in the network. This is done by ensuring that the link-local address is set to Not Active for all interfaces in the network. Opens this document.

Menu Option Auto-Assign IPv6 Addresses

Enable IPv6 on All Interfaces

Disable IPv6 on All Interfaces

Model User Guide End of Table 3-3

Configuring IPv6
Configuring IPv6 Addresses
All IP nodes in the OPNET model library are dual-stack capable, which means that they can support both IPv4 and IPv6. In addition to IPv4 addresses, you can configure IPv6 link-local and global addresses on different interfaces. Link-local and global addresses can be manually configured and global addresses can be automatically assigned. Use the Protocols > IP > IPv6 > Auto-Assign IPv6 Addresses or Protocols > IP > Addressing > Auto-Assign IPv6 Addresses menu operations to assign IPv6 addresses.

SP Guru/Release 11.5

SPM-3-5

3IPv6 Model User Guide

Specialized Models User Guide

On gateway nodes (such as routers and multi-homed clients or servers), addresses are configured in the IP > IPv6 Parameters > Interface Information attribute, as described in Procedure 3-1.

Procedure 3-1 Manually Configuring IPv6 Addresses on Gateway Nodes 1 Open the nodes Attributes dialog box and go to the IP > IPv6 Parameters > Interface Information attribute. 2 Add a row to the IP > IPv6 Parameters > Interface Information attribute table. 3 In the Name column of the row you just created, select the name of the connected or WLAN interface being configured from the pull-down menu. Make sure that the name specified here is the name defined for this interface in the IP > IP Routing Parameters > Interface Information > Name attribute. 4 Configure the following attributes: Link-Local AddressIf this attribute is set to Default EUI-64, the model automatically assigns a unique link-local address during the simulation. Global Address(es) 5 Click OK in the open Attribute dialog boxes to save your changes. End of Procedure 3-1

The procedure for configuring IPv6 addresses on host nodes (single-homed workstations and servers) is similar to the procedure for gateway nodes.

Procedure 3-2 Manually Configuring IPv6 Addresses on Host Nodes 1 Open the nodes Attributes dialog box and go to the IP > IP Host Parameters > Interface Information > IPv6 Parameters attribute. 2 Configure the following attributes: Link-Local AddressIf this attribute is set to Default EUI-64, the model automatically assigns a unique link-local address during the simulation. (optional) Global Address(es)If you do not specify a global address, the model uses stateless address auto-configuration to determine the address of the host node. This only works if the host node is connected to a router. The host node uses the router advertisements from the router to compute its own address.

SPM-3-6

SP Guru/Release 11.5

Specialized Models User Guide

3IPv6 Model User Guide

3 Click OK in all open Attribute dialog boxes to save your changes. End of Procedure 3-2

NoteSetting the Link-Local Address attribute of an interface to Default EUI-64 enables IPv6 on that interface.

Configuring IPv6 Routing Protocols


You can configure IPv6 interfaces to one or more of the following protocols for routing in IPv6 networks: RIPng OSPFv3 AODV DSR OLSR Routing protocol configuration for IPv6 is very similar to that for IPv4. The following sections describe the minimal configuration requirements for designating routing protocols in IPv6 networks. For additional information, see the attribute descriptions in the software or the following model user guides: Chapter 19 RIP Model User Guide on page STM-19-1 Chapter 18 OSPF Model User Guide on page STM-18-1 Chapter 17 MANET Model User Guide on page STM-17-1 (for AODV, DSR, and OLSR)

Procedure 3-3 Designating a Routing Protocol on an IPv6 Interface 1 Enable the desired routing protocol(s) in the Routing Protocol(s) attribute on the interface. RIPng is the default routing protocol on all IPv6 interfaces. The location of the Routing Protocol attribute varies according to the type of interface as follows: Physical Interfaces: IP > IPv6 Parameters > Interface Information > Routing Protocol(s) Subinterfaces: IP > IPv6 Parameters > Interface Information > Subinterface Information >Routing Protocol(s) Loopback Interfaces: IP > IPv6 Parameters > Loopback Interfaces > Routing Protocol(s) Tunnel Interfaces: IP > IPv6 Parameters > Tunnel Interfaces > Routing Protocol(s)
SP Guru/Release 11.5 SPM-3-7

3IPv6 Model User Guide

Specialized Models User Guide

Figure 3-1 Specifying Routing Protocols for an IPv6 Interface

Enable the IPv6 routing protocols in this dialog box.

2 Configure protocol parameters for the enabled IPv6 protocols. RIPng is configured in the IP Routing Parameters > RIPng Parameters attribute of each router. OSPFv3 is configured in the IP Routing Parameters > OSPF Parameters attribute. To use OSPFv3, the process running on the IPv6 interface must have its Version attribute set to v3. (IPv6-only nodes) If a router does not have any IPv4 addresses (that is, if all IPv4 addresses are set to No IP Address), specify a Router ID in the IP > IP Routing Parameters > Router ID attribute. OSPFv3 uses the router ID when flooding link state advertisements, but the router ID always defined when there is at least one IPv4 interface. AODV is configured in the AD-HOC Routing Parameters > AODV Parameters attribute on MANET-capable nodes. DSR is configured in the AD-HOC Routing Parameters > DSR Parameters attribute on MANET-capable nodes. OLSR is configured in the AD-HOC Routing Parameters > OLSR Parameters attribute on MANET-capable nodes. End of Procedure 3-3

Dual-Stack Configuration
IPv4-Only, IPv6-Only and IPv4/IPv6 Node Configuration

Interfaces can be configured to support only IPv4, only IPv6, or both IPv4 and IPv6. You can use the Protocols > IP > IPv6 > Configure Interface Status menu operation to enable or disable IPv6 on all interfaces in the network or on the selected interfaces only. To manually enable or disable IPv6 on interfaces, do the following. To configure an interface to support IPv6 but not IPv4, set the IPv4 address of the interface to No IP Address.

SPM-3-8

SP Guru/Release 11.5

Specialized Models User Guide

3IPv6 Model User Guide

To configure an interface to support IPv4 but not IPv6, set the link local address to Not Active. To configure an interface to support both IPv4 and IPv6, configure IPv4 and IPv6 addresses on the interface. The IPv4 addresses can be left as Auto-Assigned.
Application Configuration

All of the standard network applications (such as FTP, HTTP, and Email) can also run on IPv6 nodes. No special configuration is needed for IPv6. The version of IP used for the application is determined as follows: If both the client and the server are dual-stack nodes, the application uses the version specified in the IP Version Preference attribute. IP Version Preference is a simulation attribute, which is set to IPv6 by default. Otherwise, the version of IP that is supported by both the nodes is used. If no such version is available the two nodes cannot talk to each other. There is no way to specify which address is used if the node has multiple IPv6 addresses. The address is chosen according to the following rules: For gateway nodes, the address of an IPv6-enabled loopback interface is used, if one is available. On other nodes, the first global address of an interface is used.
Traffic Demand Configuration

You can configure traffic demands between two IPv6 interfaces or two IPv4 interfaces, but not between an IPv6 interface and an IPv4 interface. By default, the source and destination IP addresses for the traffic demand are auto-assigned. The version of IP used for the demand is determined as follows: If both the client and the server are dual-stack nodes, the application uses the version specified in the IP Version Preference attribute. IP Version Preference is a simulation attribute, which is set to IPv6 by default. Otherwise, the version of IP that is supported by both the nodes is used. You can manually specify the source and destination interfaces of the traffic demand by editing the Source IP Address and Destination IP Address attributes of the traffic demand.

Migrating to IPv6
Tunneling mechanisms enable IPv6 sites to communicate with each other over an IPv4 backbone. The model currently supports three types of IPv6 tunnels. Manual tunnels (configured tunnels)
SP Guru/Release 11.5 SPM-3-9

3IPv6 Model User Guide

Specialized Models User Guide

Automatic tunnels Automatic 6to4 tunnels This section contains instructions for configuring each type of tunnel. Note that you cannot configure tunnels on host nodes, but you can use a multi-homed client/server to work around this limitation.

Manual IPv6 Tunnels


Manual tunnels are also referred to as configured tunnels. When configuring manual tunnels, note the following: The destination address of a manual tunnel must be explicitly specified. A separate tunnel is needed for each IPv6 site that the node communicates with. There is no limit on the number of manual tunnels you can configure on a router. Even though you can configure unidirectional tunnels, practical considerations require a matching tunnel in the opposite direction. To configure a bidirectional tunnel, follow Procedure 3-4 for both end nodes.

Procedure 3-4 Configuring One End of a Bidirectional Tunnel 1 In the nodes Attributes dialog box, create a tunnel interface by adding a row to the IP > IP Routing Parameters > Tunnel Interfaces attribute. Give this tunnel interface a unique name by configuring the Name attribute. 2 Set the Routing Protocols attribute to None. 3 Click in the Tunnel Information attribute to open the Tunnel Information table. 4 Set the Tunnel Mode to IPv6 (Manual). 5 Specify the destination address of the tunnel under the Tunnel Destination attribute. The destination address must be an IPv4 address. 6 Set the Tunnel Source attribute to the name of a connected interface on the node. 7 Click OK to close the Tunnel Information and Tunnel Interfaces attribute dialog boxes (or collapse the Tunnel Information and Tunnel Interfaces attribute if you are navigating using the treeview in the main Attribute dialog box). 8 Add a row to the IP > IPv6 Parameters > Tunnel Interfaces attribute. 9 Set the Name attribute to the same value used in step 1. 10 Configure the link-local address and global addresses. At least one global address must be configured.
SPM-3-10 SP Guru/Release 11.5

Specialized Models User Guide

3IPv6 Model User Guide

11 By default, RIPng will be enabled on the interface. Disable it if necessary. 12 Click OK in all open dialog boxes to save your changes. End of Procedure 3-4

For correct tunnel operation, the tunnels destination address for one direction should correspond to the source interface of the tunnel in the other direction. For example, if a tunnel is configured between Nodes A and B, the destination address specified on Node A must correspond to the Source interface specified for the tunnel on Node B, and vice versa.

Automatic IPv6 Tunnels


Automatic tunnels can be used to tunnel packets whose destination address is an IPv4-compatible IPv6 address. The operation of automatic tunnels is described in RFC 2893 Sec 5. For automatic tunnels to work properly, the IPv4-compatible addresses configured on a node must have a subnet mask length of 128 bits. You can use a single automatic tunnel on a router to tunnel packets to all destinations that have IPv4-compatible addresses. Because of this, the model does not support the configuration of multiple automatic tunnels on a node. Procedure 3-5 describes how to enable automatic tunneling on a router.

Procedure 3-5 Enabling Automatic Tunneling on a Router 1 In the nodes Attributes dialog box, create a tunnel interface by adding a row to the IP > IP Routing Parameters > Tunnel Interfaces attribute. Give this tunnel interface a unique name by configuring the Name attribute. 2 Set the Routing Protocols attribute to None. 3 Click on the Tunnel Information attribute to open the Tunnel Information table. 4 Set the Tunnel Mode to IPv6 (Auto). 5 Set the Tunnel Source attribute to the name of a connected interface on the node. 6 No additional configuration is needed for the IPv6 Parameters attribute. 7 Click OK in all open dialog boxes to save your changes. End of Procedure 3-5

SP Guru/Release 11.5

SPM-3-11

3IPv6 Model User Guide

Specialized Models User Guide

6to4 Tunnels
6to4 tunnels can be used to tunnel packets to destinations that use 6to4 addresses. 6to4 tunnels are described in RFC 3056. Modeling of 6to4 networks that have an ISP relay router, as described in RFC 3056 Sec 5.2.1, is supported. Procedure 3-6 describes how to configure a 6to4 tunnel on a router.

Procedure 3-6 Configuring a 6to4 Tunnel on a Router 1 In the nodes Attributes dialog box, create a tunnel interface by adding a row to the IP > IP Routing Parameters > Tunnel Interfaces attribute. Give this tunnel interface a unique name by configuring the Name attribute. 2 Set the Routing Protocols attribute to None. 3 Click in the Tunnel Information attribute to open the Tunnel Information table. 4 Set the Tunnel Mode to IPv6 (6to4). 5 Set the Tunnel Source attribute to the name of a connected interface on the node. 6 Add a row to the IP > IPv6 Parameters > Tunnel Interfaces attribute. 7 Set the Name attribute to the same value used in step 1. 8 Configure the link-local address and one global address. The global address of the interface must be a valid 6to4 address. 9 Add an IPv6 static route (IP > IPv6 Parameters > Static Routing Table) to the destination 2002::/16 with the next hop attribute set to the name of the 6to4 tunnel interface. 10 Click OK in all open dialog boxes to save your changes. End of Procedure 3-6

Using Mobile IPv6


Configuring Mobile IPv6 (MIPv6)
The following mobility features are supported: Route optimization Mobile node (MN)home agent (HA) bi-directional tunneling IPv6 extension headers Mobility extension headers Routing (type 2) and destination option extension headers

SPM-3-12

SP Guru/Release 11.5

Specialized Models User Guide

3IPv6 Model User Guide

IPv6 Neighbor discovery Router advertisements (movement detection, address auto-configuration (stateless), home agent address detection) Duplicate address detection (modeled as a delay)
Mobile Nodes

Use Procedure 3-7 to configure a WLAN workstation or server node as an MIPv6 mobile node.

Procedure 3-7 Configuring a Mobile Node 1 Open the Attributes dialog box for the node. 2 Set the IP > Mobile Host Node Parameters > Mobile IPv6 Parameters > Node Type attribute to Mobile Node. 3 Set the IP > Mobile Host Node Parameters > Mobile IPv6 Parameters > Route Optimization attribute to Enabled or Disabled. 4 If the mobile node is initially away from home and more than one access point exists, specify the address of the home agent (IP > Mobile Host Node Parameters > Mobile IPv6 Parameters > Home Agent Address). This can be learned from the home agents router advertisements when at home but needs to be specified if the mobile node is initially away from home. 5 (optional) Configure binding and return routability test parameters. IP > Mobile Host Node Parameters > Mobile IPv6 Parameters > Binding Parameters IP > Mobile Host Node Parameters > Mobile IPv6 Parameters > Return Routability Parameters 6 (optional) Specify the Mobility Detection Factor (IP > Mobile Host Node Parameters > Mobile IPv6 Parameters > Mobility Detection Factor). This is the number of lost router advertisements that constitute a Layer-3 handover indication. 7 If the mobile node is initially away from home and more than one access point exists on the network, specify the global address of the mobile node (IP > IP Host Parameters > Interface Information > IPv6 Parameters > Global Address(es) > Address). This address should use the same network prefix as the home agent. 8 Enable WLAN roaming on the node (Wireless LAN > Wireless LAN Parameters > Roaming Capability. End of Procedure 3-7

SP Guru/Release 11.5

SPM-3-13

3IPv6 Model User Guide

Specialized Models User Guide

Correspondent Nodes

Wireless and non-wireless workstations and servers can be configured as correspondent nodes. To configure a node as a correspondent node, set the IP >
Mobile Host Node Parameters > Mobile IPv6 Parameters > Node Type attribute to Correspondent Node.

Route optimization can be enabled or disabled for correspondent nodes. All regular workstation nodes behave as correspondent nodes with no route optimization support.
Home/Foreign Agents

Home agent functionality is configurable on a per-interface basis for router nodes. A router can have many interfaces that act as home agents; each needs to be configured individually. The home agent interface can be a wired interface or a wireless interface. An interface is configured as a home agent through the IP > Mobile IP Router Parameters > Mobile IPv6 Parameters attribute. You need to specify the name of the interface that will act as home agent within this attribute. Figure 3-2 shows how to configure a home agent.
Figure 3-2 Configuring a Home Agent

SPM-3-14

SP Guru/Release 11.5

Specialized Models User Guide

3IPv6 Model User Guide

Home and foreign agents also need to have router advertisements enabled so that mobile nodes can learn of the closest home agent. The Router Advertisement Parameters attribute (IP > IPv6 Parameters > Interface Information > Router Advertisement Parameters) lets you enable/disable router advertisements and configure how often advertisements are sent. Observe the following guidelines when configuring router advertisement intervals: Router advertisement intervals should be set to a value that is short enough to keep the routing tables accurate. If the router advertisement interval is too big, nodes locations may change too much before an update is sent. The Advertise Interval attribute should be set to Auto-Calculate. The IPv6 ND Simulation Efficiency simulation attribute should be set to Disabled.

Mobility Parameters
Mobility-related parameters play a role in call handoff. They are Router advertisements and advertise interval on routers Mobility detection factor on hosts Route Optimization WLAN roaming capability on 802.11 based mobile nodes.
Router Advertisements, Advertise Interval, and Mobility Detection Factor

These attributes are essential for Layer-3 handoff. If the router advertisements that a mobile node receives include an Advertisement Interval option, the mobile node uses its Advertisement Interval field to indicate the frequency with which it should expect to receive future advertisements from that router. If a mobile node does not receive a router advertisement for advertise_interval * mobility_detection_factor time, it concludes that it has moved away from the router. It then seeks router advertisements from a new router.
Route Optimization

This attribute lets mobile IPv6-capable correspondent nodes communicate directly with mobile nodes (without being routed through the home agent). If this is not enabled, bi-directional tunnels are established between the mobile node and its home agent. Traffic is always routed through the home agent. This attribute is configured in the Mobile IP Host Parameters attribute of a correspondent node. A mobile node informs the correspondent node about its new prefix after a Layer-3 handoff.

SP Guru/Release 11.5

SPM-3-15

3IPv6 Model User Guide

Specialized Models User Guide

WLAN Roaming Capability on 802.11-Based Mobile Nodes

This attribute is essential for Layer-2 handoff. You can enable roaming in the Wireless LAN > Wireless LAN Parameters > Roaming Capability attribute on mobile nodes.

Analyzing IPv6 Configuration


The model includes several features that you can use to analyze IPv6 network topologies. They are: Statistics Routing protocol visualization Address configuration reports

Available Statistics
The following global and node statistics are available for IPv6.
Figure 3-3 IPv6 Statistics
Global Statistics Node Statistics

You can also collect statistics for the individual routing protocols in the network on a global, per-node, or per-process basis.

SPM-3-16

SP Guru/Release 11.5

Specialized Models User Guide

3IPv6 Model User Guide

Visualizing IPv6 Configuration in the Workspace


You can see which routing protocols are configured on IPv6 physical interfaces by using the View > Visualize Protocol Configuration > IP Routing Protocols > IPv6 Routing Protocols menu operation. This feature adds icons in the Project Editor workspace that indicate which routing protocols are configured in the IPv6 network. NoteThis feature applies to IP routing protocols only (RIPng and OSPFv3)it does not show the MANET protocols configured in an IPv6 network.
Figure 3-4 Viewing Routing Protocol Configuration for IPv6

This interface is running RIPng.

This interface is running RIPng and OSPFv3.

Visualizing Route for Traffic Demands


You can view the routes computed for the traffic demands in the network by discrete event simulation. Use the following operation after running a discrete event simulation to access information on the configured traffic demands: Protocols > IP > Demands > Display Routes for Configured Demands

IPv6 Interface Configuration Reports


The software can generate reports that list the addresses and routing protocols configured on IPv6 interfaces. This feature is especially helpful when you use the Auto-Assign IPv6 Addresses feature and need to know the address that was assigned to a particular interface.

SP Guru/Release 11.5

SPM-3-17

3IPv6 Model User Guide

Specialized Models User Guide

Figure 3-5 Generating IPv6 Interface Configuration Reports


.

SPM-3-18

SP Guru/Release 11.5

Specialized Models User Guide

3IPv6 Model User Guide

Reference Documents
IPv6 models are implemented based on information available from the following sources.
Table 3-4 Reference Documents
Document RFC 2460 RFC 2373 RFC 2893 RFC 3056 RFC 2080 RFC 2740 RFC 3775 RFC 2461 RFC 1971 End of Table 3-4 Title Internet Protocol, Version 6 (IPv6) Specification IP Version 6 Addressing Architecture Transition Mechanisms for IPv6 Hosts and Routers Connection of IPv6 Domains via IPv4 Clouds RIPng for IPv6 OSPF for IPv6 Mobility Support in IPv6 Neighbor Discovery for IP Version 6 (IPv6) IPv6 Stateless Address Autoconfiguration

SP Guru/Release 11.5

SPM-3-19

3IPv6 Model User Guide

Specialized Models User Guide

SPM-3-20

SP Guru/Release 11.5

Specialized Models User Guide

4Mainframe Model User Guide

Mainframe Model User Guide


Mainframe modeling allows you to examine the performance of your mainframe as it interacts with other elements in your network model. This document describes key features of the Mainframe model shipped as part of OPNETs specialized model library.

Model Features
The Mainframe model suite implements the following features.
Table 4-1 Mainframe Model Features
Logical Partitioning It allows the machine to have up to 15 logical servers with each one of them running under Compatibility or Goal Mode. Multitasking CPU modeling uses a scheduling algorithm based on business importance of the workloads and their current performance index. Model tracks memory usage to help predict server memory requirements. Currently a simple I/O subsystem is modeled.

CPU Modeling

Memory

Disk I/O End of Table 4-1

Mainframe models are implemented based on information available from the following sources.
Table 4-2 Reference Documents
TSO (zSeries 900 20641C1) Manufacturer Specifications End of Table 4-2 LSPR benchmarks published by IBM (www.ibm.com)

Number of CPs, interfaces, memory and SRM constant information are obtained from manufacturer data sheets.

A workload can be a single thread, a process, or a group of threads and processes that represent the target workload. Each workload has specific resource requirements for CPU, memory, and I/O. Workloads can be executed as applications entirely within the mainframe, or as networked applications that scale with traffic load. If operating under Goal Mode, workloads can be associated with Service Classes thereby specifying performance goals and resource groups for these workloads.
SP Guru/Release 11.5 SPM-4-1

4Mainframe Model User Guide

Specialized Models User Guide

There are many predefined hardware configurations. Quick, simple mainframe reconfiguration facilitates what if scenarios. The model interoperates with existing simple CPU and specialized Server models.

Model Attributes
Mainframe model attributes are configured in two locations: Mainframe Configuration objectfor attributes common to all mainframes, such as hardware settings, workload, service class and report class information Individual mainframefor attributes specific to a particular mainframe
Figure 4-1 Mainframe Model Objects

Mainframe Configuration Object Attributes


The Mainframe Configuration object has several attributes describing the underlying mainframe hardware, service classes, report classes, and workloads. Attributes described in the Mainframe Configuration object are listed below:
Figure 4-2 Mainframe Configuration Object Attributes

Mainframe Definitions. This attribute specifies hardware characteristics of mainframes. Default values are obtained from manufacturer data sheets.

SPM-4-2

SP Guru/Release 11.5

Specialized Models User Guide

4Mainframe Model User Guide

Figure 4-3 Mainframe Definitions Attribute

Name. This attribute describes the physical mainframeit usually includes the manufacturer name and model number. PU Configuration. This attribute specifies the distribution of the given processor units depending upon the function being performed by them. Number of CE. Number of cryptographic elements in the system. Memory Capacity (GB). This attribute specifies the amount of memory in the system inGB. Number of STIs. This attribute specifies the number of self-timed interfaces in the system. These are the I/O interfaces. SRM constant. This attribute specifies the processors speed in terms of Service Units/sec. Benchmark. This attribute specifies the set of benchmark values used by this system for various subsystems such as TSO, CICS, DB2 etc. PU Configuration. This attribute specifies the number of processor units available for each type listed below.
Figure 4-4 PU Configuration Attribute

SP Guru/Release 11.5

SPM-4-3

4Mainframe Model User Guide

Specialized Models User Guide

Number of CPs. This attribute specifies the number of units which are used for processing of data. Number of SAPs. This attribute specifies the number of units which are used only for processing related to I/O. These are known as System Assist Processors. Number of ICFs. This attribute specifies the number of units which are used by the Coupling Facility. These are known as Integrated Coupling Facility. Number of IFLs. This attribute specifies the number of units which are used for Linux. These are known as Integrated Facility of Linux. Benchmark. This attribute specifies the benchmark values for various subsystems. For example, from the given figure, TSO is a subsystem and the base system against which its value is compared is Zseries 900 2064 1C1.
Figure 4-5 Benchmark Attribute

Report Class Definitions. This attribute allows the user to aggregate the results of various workloads as part of a single report class. For example, from the given figure, the Default Report Class has CICS Wkld and DB2 Wkld defined as part of it. These workloads are defined in Workload Definitions attribute.

SPM-4-4

SP Guru/Release 11.5

Specialized Models User Guide

4Mainframe Model User Guide

Figure 4-6 Report Class Attribute

Service Class Definitions. This attribute defines the service policy which can be used by the mainframes if they are running in Goal Mode.
Figure 4-7 Service Class Attribute

Name. Name of the service class. Performance Goal. This specifies the type of the goal and its criteria. Resource Group. This specifies the minimum and maximum amount of service units that should be allocated to this Service Class. Performance Goal. This attribute specifies the type of goal associated with the service class.
Figure 4-8 Performance Goal Attribute

SP Guru/Release 11.5

SPM-4-5

4Mainframe Model User Guide

Specialized Models User Guide

Type. Type of performance goal. It can be Velocity, Response Time or Discretionary. Response Time. If the goal is of type Response Time, the value is specified here. Velocity. If the goal is of type Velocity, the value is specified here. % Transactions Meeting Goal. It specifies the number of transactions that should be meeting this goal. Workload Definitions. This attribute specifies workload descriptions that include information on the measured performance of mainframe jobs. These definitions are independent of the mainframes they run on. The attributes described here apply to the representative instance of the workload.
Figure 4-9 Workload Definition Attribute

SPM-4-6

SP Guru/Release 11.5

Specialized Models User Guide

4Mainframe Model User Guide

Name. A user-defined value which uniquely describes the workload. Measured System. When simulating workloads for systems other than the one on which the measured values were obtained, the model needs to know how to scale these values. This attribute, along with the benchmark, allows scaling to be performed. The mainframe description for this system must already exist before this value can be obtained. Benchmark. As different workloads have different performance characteristics, each workload belonging to a subsystem can be assigned its own benchmark value. This value is obtained from the list of benchmarks provided for the mainframe described in the Measured System. Since this value is used to scale workloads, it must exist in both the measured system described above, and in the target system described on the individual mainframe. Average Processing Time. A distribution describing the amount of processor time consumed by the workload. Paging Information. A set of distribution describing the number of single and shared page faults generated by a single workload instance. This includes both hard (those requiring an I/O operation to exchange data with that on disk) and soft faults (those with data found in memory). This set of distributions is used to specify both Auxiliary and Expanded page faults. I/O Information. Distributions describing the typical I/O behavior of the workload. This includes the number of I/Os and the total I/O response time. Memory Information. Memory usage is also tracked on a single instance basis. This includes both central and expanded memory.

SP Guru/Release 11.5

SPM-4-7

4Mainframe Model User Guide

Specialized Models User Guide

Mainframe Attributes
In addition to the Mainframe Configuration attributes, a number of attributes are provided on the individual mainframes. These affect only the mainframe on which they're specified, although in many cases they rely on information provided in the Mainframe Configuration object.
Figure 4-10 Mainframe Modeling Attributes on Mainframe Nodes

Server: Modeling Method. For compatibility with the existing OPNET application models, and for those occasions when mainframe modeling is not necessary, you can select which modeling method is right for your scenario. Simple CPU. This method uses a simple contention model to simulate server activity. It is identical to previous OPNET models. Use this setting when using the standard network application models, such as FTP or HTTP. Detailed Server. The detailed server modeling method uses the advanced modeling capabilities. A specialized license is required to run in Detailed Server mode. Mainframe. This uses the mainframe modeling capabilities described in this document. A specialized license is required to run in Mainframe mode. Reports: Mainframe Workload Activity Table. This attribute controls the generation of the workload activity table report for this node. Mainframe Parameters. A description of the hardware and workload group configuration is given by this attribute. A detailed description of the subattributes follows.

SPM-4-8

SP Guru/Release 11.5

Specialized Models User Guide

4Mainframe Model User Guide

Figure 4-11 Mainframe Parameters Attributes

Hardware Configuration. This attribute specifies the mode in which mainframe operates and the configuration of the machine based on that mode. Workload Group Configuration. Once the hardware configuration is complete, this attribute is used to specify the workload groups and their configurations. Hardware Configuration.
Figure 4-12 Hardware Configuration Attributes

Mainframe. Name of the model mainframe which this node represents. Operational Mode. The node could be operating in the BASIC mode in which case there will be just one logical partition or it could be operating in LPAR mode, where there can be multiple logical partitions. LPAR Configuration. This attribute describes the configuration of the LPAR cluster. BASIC Mode Configuration. If the node is operating in BASIC mode, this attribute describes the configuration. LPAR Resource Management. If the node is operating in LPAR mode, we can enable / disable the dynamic management of resources and also specify how often this operation should be done. LPAR Configuration. This attribute describes the manner in which the logical partitions are defined for the mainframe node.

SP Guru/Release 11.5

SPM-4-9

4Mainframe Model User Guide

Specialized Models User Guide

Figure 4-13 LPAR Configuration Attribute

Name. Name of the logical partition. This should be unique. It will be used to specify under which LPAR does a given workload group runs. Cluster Name. Name of the cluster to which this logical partition belongs. Operating System. This specifies the operating system running on this logical partition. Number of Logical CPs. This specifies the number of logical processors (CPs) running under this partition. The number of LCPs for a given logical partition cannot be more than the total number of physical processors on the system. CP Type. The CPs can be shared among various logical partitions or they can be dedicated for this logical partition. The total number of dedicated CPs for all the logical partitions cannot be more than the number of the physical CPs in the system. Mode of Operation. The logical partition can operate in Compatibility or Goal Mode or it can act as a Coupling Facility. Initial Weight. Initial weight of the logical partition. When running in Goal Mode, this is used to determine the dispatching priority of the logical CP to the physical CP for all the partitions under the same cluster. Paging System Configuration. This attribute specifies the paging system for this partition. Average Processing Time. Average amount of processing time required with single paging operation. Page I/O Count. Number of I/O operations associated with a page fault which requires I/O operation. Page Size. Size of the I/O page. Aux Hard Fault Percentage. Specifies the number of auxiliary page faults which are hard faults (require I/O operation) as a percentage of the total page faults generated by the application.

SPM-4-10

SP Guru/Release 11.5

Specialized Models User Guide

4Mainframe Model User Guide

Exp Hard Fault Percentage. Specifies the number of expanded page faults which are hard faults (require I/O operation) as a percentage of the total page faults generated by the application. LPAR Capping. This attribute is used to enable or disable this function. If capping is enabled, when the limit to the amount of resources that should be allocated for this partition has been reached, even if there are more resources available, they will not be used. BASIC Mode Configuration. If the mainframe is operating in the BASIC mode, this attribute is used specify the following attributes. Operating System. Operating system running on this mainframe. Paging System Configuration. It specifies the paging system for the entire mainframe using the same attributes as described for the LPAR Configuration. Workload Group Configuration.
Figure 4-14 Workload Group Configuration Attribute

Name. Name of the workload group. Service Class Period Configuration. List of service class periods configured for this workload group. LPAR Assignment. Name of the LPAR under which this workload group will be running. Service Class Period Configuration.
Figure 4-15 Service Class Period Configuration Attribute

SP Guru/Release 11.5

SPM-4-11

4Mainframe Model User Guide

Specialized Models User Guide

Name. Name of the Service Class. They are defined in the Mainframe Configuration object. Workload Configuration. List of workloads configured under a given service class period. Business Importance. Importance value (1 - 5) associated for this service class. Value of 1 has the highest importance. Workload Configuration
Figure 4-16 Workload Configuration Attribute

Name. Name of the workload. They are defined in the Mainframe Configuration object. Transaction Trigger Mechanism. This attribute specifies the method by which transactions for this workload will be executed. In can either be triggered by the application or it can be started internally in which case the following attributes can be used to configure the starting and stopping the transactions. Start Time. Time at which the transactions for this workload will start executing. Number of Transactions. Total number of transactions that need to be executed for this workload. Transactions per Second. Number of transactions that are executed per second. Duration. Duration for which transaction will keep getting executed. This attribute along with the number of transactions determine the lower limit on the total number of transactions that are executed for the given workload. Transaction Policy. This attribute specifies the following Number of Parallel Transactions. Number of parallel transactions that can be executed for this workload. Transaction Limit Policy. Once the limit to the number of parallel transactions is reached, the new transaction can either be queued or it can be rejected based upon this attribute. Number of Threads. This attribute specifies the number of threads into which this transaction can be broken down.
SPM-4-12 SP Guru/Release 11.5

Specialized Models User Guide

4Mainframe Model User Guide

Available Statistics
To analyze Mainframe performance, you can collect several statistics during simulation execution. The statistics are collected on a per-node basis. Some of the available statistics are shown below. Node-based statistics provide grouped information for all Mainframe processes running in a node. These are useful to evaluate hardware and software bottlenecks within a mainframe or within a network. Many statistics are available on a workload, service class, workload group and LPAR specific basis as well as on a mainframe-wide basis.
Figure 4-17 Available Statistics

SP Guru/Release 11.5

SPM-4-13

4Mainframe Model User Guide

Specialized Models User Guide

SPM-4-14

SP Guru/Release 11.5

Specialized Models User Guide

5MPLS Model User Guide

MPLS Model User Guide


Multi-Protocol Label Switching (MPLS) is a multi-layer switching technology that uses labels to determine how packets are forwarded through a network. SP Guru includes several complementary technologies that you can use to model and analyze MPLS networks.

Model Features
This section contains a list of the main features available in the Multi-Protocol Label Switching model: The MPLS model captures the following protocol behavior:
Table 5-1 MPLS Model Features
Feature LSP (Label Switched Path) configuration Description LSPs can be created manually or automatically from traffic conversation pairs. LSPs are easily reused in other scenarios or projects by using the LSP import and export features. Both dynamic and static LSPs are created using the path object. Differential Services (DiffServ) DiffServ extensions, as defined in RFC-2475, are provided. The model enables you to perform QoS (quality of service) analyses by accounting for different types of service. Traffic Engineering Traffic engineered routes are computed using Constrained Shortest Path First (CSPF) with OSPF or IS-IS routing protocols.

End of Table 5-1

Table 5-2

Summary of MPLS Support in SP Guru


Supports MPLS Special Requirements Requires SP Guru or SP Sentinel. Requires SP Guru or SP Sentinel.

Technology Device Configuration Import

Import from VNE Server

SP Guru/Release 11.5

SPM-5-1

5MPLS Model User Guide

Specialized Models User Guide

Table 5-2

Summary of MPLS Support in SP Guru


Supports MPLS Special Requirements None. Requires SP Guru or SP Sentinel. Requires MPLS specialized model license.

Technology NetDoctor Flow Analysis

Discrete event simulation

End of Table 5-2

This chapter covers the following topics: MPLS for Traffic Engineering Studies on page SPM-5-3 Fast-Reroute in MPLS on page SPM-5-14 MPLS for Layer-3 VPNs on page SPM-5-16 VPLS and L2 VPNs on page SPM-5-20 Reports on page SPM-5-24 Troubleshooting MPLS Network Configurations on page SPM-5-26

SPM-5-2

SP Guru/Release 11.5

Specialized Models User Guide

5MPLS Model User Guide

MPLS for Traffic Engineering Studies


The MPLS model can be used for traffic engineering studies. You can configure MPLS automatically by importing the network configuration using the device configuration import or import from VNE Server features. This section describes how to manually configure MPLS for traffic engineering studies. The following topics are covered Configuring Label-Switched Paths (LSPs) Defining how traffic is assigned to LSPs Before LSPs are configured, the network devices should have MPLS enabled and should be running OSPF or ISIS as a routing protocol. To enable MPLS on routers select Protocol > MPLS > Configure Interface Status. All interfaces should have OSPF or ISIS enabled. OSPF and IS-IS are link state routing protocols that support extensions for traffic engineering. Routers that are the source or destination of an LSPs must have a loopback interface that is reachable from other sections of the MPLS domain.

Configuring Dynamic LSPs


The model suite includes two LSP models: a static LSP model and a dynamic LSP model. The dynamic LSP can be configured with explicit or Constraint-based Shortest Path First (CSPF) routes. At the beginning of the simulation, all dynamic LSPs are signalled using Resource Reservation Protocol (RSVP) or Constraint-based Label Distribution Protocol (CR-LDP). Static LSPs are not signalled.
Dynamic LSPs with Explicit Routes

When configuring a dynamic LSP with explicit routes, you need to click on each individual router along the route of the LSP to define the path taken by the LSP.

Procedure 5-1 Creating Dynamic LSPs with Explicit Routes 1 Click on the MPLS_E-LSP_DYNAMIC object in the MPLS object palette.

SP Guru/Release 11.5

SPM-5-3

5MPLS Model User Guide

Specialized Models User Guide

Figure 5-1 Dynamic LSP in the Object Palette

2 In the project workspace, click on the ingress Label Edge Router (LER) of the LSP. 3 Click on each router along the LSPs route. Be sure to click on the objects in the same order that they occur in the LSP. 4 Click on the egress LER of the LSP. 5 Double-click in the project workspace to finish drawing the LSP. 6 Draw additional LSPs, if desired. 7 Exit path definition mode by right-clicking in the project workspace and selecting Abort Path Definition. 8 Select Protocols > MPLS > Update LSP Details. End of Procedure 5-1

Dynamic LSPs with CSPF Routes

Dynamic LSPs with CSPF routes must use a routing protocol based on the SPF algorithm. Specifically, you must select OSPF or IS-IS as a routing protocol. The simulation engines might compute different CSPF routes for dynamic LSPs depending on the order in which the LSPs are considered by the algorithm. By default, the LSPs are routed in the order in which they were created in the network model. You can make flow analysis consider the LSPs in a random order by setting the Flow Analyis.ip_flow_analysis_random_seed_to_order environment preference (Edit > Preferences) to a positive number. Because of the effect that ordering has on the computed routes, the performance of a CSPF-based network can vary considerably from one sequence (ordering) to another. If you are comparing the results from simulation with a real network, you may also see routing differences between the model results and the results from the production network.
SPM-5-4 SP Guru/Release 11.5

Specialized Models User Guide

5MPLS Model User Guide

Procedure 5-2 Creating Dynamic LSPs Without Explicit Routes 1 Click on the MPLS_E-LSP_DYNAMIC object in the MPLS object palette. 2 In the project workspace, click on the LSPs ingress LER. 3 (Optional) If the LSP must use certain routers or links, click on the intermediate routers or links that must be used. Be sure to click on the objects in the same order that they occur in the LSP. 4 Click on the LSPs egress LER. 5 Double-click in the project workspace to finish drawing the LSP. 6 Draw additional LSPs, if desired. 7 Exit path definition mode by right-clicking in the project workspace and selecting Abort Path Definition. 8 Select Protocols > MPLS > Update LSP Details. End of Procedure 5-2

Configuring Static LSPs


With static LSPs you can specify the exact route used by the LSP. Static LSPs allow more routing control but offer less resiliency to node and link failures. For this reason, you should always specify at least one backup route when configuring static LSPs in your network.

Procedure 5-3 Creating Static LSPs 1 Click on the MPLS_E-LSP_STATIC object in the MPLS object palette. Figure 5-2 Static LSP in the Object Palette

2 In the project workspace, click on the LSPs ingress LER.


SP Guru/Release 11.5 SPM-5-5

5MPLS Model User Guide

Specialized Models User Guide

3 Click on the next link or router in the LSPs route. The tooltips indicate which links and routers can be added to the route. Hold the cursor over a link or router for details about adding it to the LSP. 4 Continue clicking on each link or router in the route until all have been added. 5 Right-click in the project workspace, and select Finish Path Definition to finish drawing the LSP. 6 If you are finished creating static LSPs, right-click in the project workspace, and select Abort Path Definition. Otherwise, draw the next static LSP. 7 From the Protocols > MPLS menu, choose Update LSP Details to configure label switching information on the LSP(s). End of Procedure 5-3

Sending Traffic Through LSPs


Before you can send traffic on an LSP, you need to configure the traffic mappings that associate traffic with a particular LSP. The model supports two ways of associating traffic with an LSP: static mappings and IGP shortcuts.
Static Mapping

With static mappings you create forwarding equivalence classes (FECs) and traffic trunks, which are used to define different types of traffic.

NoteA traffic trunk is an aggregate of traffic flows that are forwarded along a common path and share a common Quality of Service (QoS) requirement.

SPM-5-6

SP Guru/Release 11.5

Specialized Models User Guide

5MPLS Model User Guide

Procedure 5-4 Creating FECs 1 Place an MPLS configuration object in the project workspace and open its Attributes dialog box.

2 Double-click on the value for FEC Specifications. The FEC Specifications Table appears. 3 Change the Rows value to the number of FECs you want to create. 4 For each FEC, assign a name, then double-click in the Details column to describe the FEC. End of Procedure 5-4

To work correctly, the model requires that you set up at least one default traffic trunk. Additional trunks can be used to handle prioritized flows.

Procedure 5-5 Creating a Traffic Trunk 1 Place an MPLS configuration object in the project workspace and open its Attributes dialog box. 2 Double-click on the value for Traffic Trunk Profiles. The Traffic Trunk Profiles Table appears. 3 Change the Rows value to 1. 4 Specify a name for the trunk.

SP Guru/Release 11.5

SPM-5-7

5MPLS Model User Guide

Specialized Models User Guide

5 Configure the Trunk Details attribute. End of Procedure 5-5

After you create the LSPs, FECs, and traffic trunks, you can create the static mappings or TE bindings that govern which packets are sent to which LSPs. You do this in the LERs MPLS > MPLS Parameters > Traffic Mapping Configuration attribute.

Procedure 5-6 Creating Static Mappings 1 Open the LERs Traffic Mapping Configuration attribute dialog box (MPLS > MPLS Parameters > Traffic Mapping Configuration). 2 Add a row to the table. 3 Click in the Interface In column and specify which interfaces the binding applies to in the Interface Binding Specification table. To select an interface, click in the Apply Binding column for that interface to toggle the value to Yes. The interface(s) you selected appear in the Traffic Mapping Configuration dialog box. Note that the interface number for higher layers corresponds to the routers loopback interface. 4 Select a FEC for the binding from the FEC pull-down menu. 5 Select a traffic trunk for the binding from the Traffic Trunk pull-down menu. 6 Click in the LSP column to specify the primary and backup LSPs. End of Procedure 5-6

IGP Shortcuts

You can use IGP shortcuts instead of static mappings in an MPLS network. When you use IGP shortcuts, the network regards the LSP as a single link. To enable IGP shortcuts for a link, set the Announce IGP Shortcuts attribute on the LSP to Enabled.

NoteIGP shortcuts behave in the same way as CISCO's autoroute announce feature.

SPM-5-8

SP Guru/Release 11.5

Specialized Models User Guide

5MPLS Model User Guide

Figure 5-3 IGP Shortcuts in a Routing Table

Inter-Domain MPLS Traffic Engineering


For discrete event simulation studies, LSPs cannot traverse multiple areas or autonomous systems. If you want to run simulations that include Cisco inter-area LSPs, Cisco inter-AS LSPs, or Juniper cross-connect circuitsbased inter-area LSPs, you must use flow analysis.
Configuring Cisco Inter-Area LSPs

Inter-area LSPs are LSPs that traverse multiple areas in a network. To configure a Cisco inter-area LSP, you need to ensure the following: The explicit route of the LSP includes an area border router (ABR), which has interfaces in both areas traversed by the LSP. Explicit routes are configured in the MPLS > MPLS Parameters > Explicit Routes attribute on the ingress LSR. The ingress LSR includes a static route (or policy-based routing) to the egress LSR. This static route specifies the inter-area LSP as its next hop. Static routes are configured in the IP > IP Routing Parameters > Static Routing Tables attribute.

SP Guru/Release 11.5

SPM-5-9

5MPLS Model User Guide

Specialized Models User Guide

Figure 5-4 Cisco Inter-Area LSP Configuration


A is the ingress LSR for the red LSP and the green LSP D is an ABRit is in all three areas The red LSP is an inter-area LSP (traverses areas 0.0.0.1 and 0.0.0.2) The green LSP is an inter-area LSP (traverses areas 0.0.0.1 and 0.0.0.3)

This static route tells router A to use the RED LSP to reach H2, which is in 192.0.12.0/24. The RED LSP is configured to use explicit route RED, which is defined on the ingress LSR, A. The Explicit Routes attribute on router A defines the explicit routes available to the LSPs that start at this node. The path details for RED include router D, the AS-BR.

Configuring Cisco Inter-AS LSPs

Inter-AS LSPs are LSPs that traverse multiple ASes in a network. They are supported on Cisco router models only. To configure inter-AS LSP, you need to ensure the following: The explicit route of the LSP includes an AS boundary router, which has interfaces in both ASes traversed by the LSP. Explicit routes are configured on the ingress LSR. Explicit routes are configured in the MPLS > MPLS Parameters > Explicit Routes attribute on the ingress LSR. The ingress LSR includes a static route (or policy-based routing) to the egress LSR. This static route specifies the inter-AS LSP as its next hop. Static routes are configured in the IP > IP Routing Parameters > Static Routing Tables attribute.

SPM-5-10

SP Guru/Release 11.5

Specialized Models User Guide

5MPLS Model User Guide

Figure 5-5 Inter-AS LSP Configuration


The GREEN LSP is an inter-AS LSP. RED and BLUE are inter-area LSPs.

This static route tells router A to use the GREEN LSP to get to 192.0.21.1/24 The Explicit Routes attribute on router A defines the explicit routes available to the LSPs that start at this node. The path details for AS100_AS200 include router F, the AS-BR. The Configured Paths attribute on the GREEN LSP tells the LSP to use the AS100_AS200 explicit route, configured on ingress LSR A, for routing.

Configuring Cross-Connect Circuits (CCC)

In Juniper networks, inter-area LSP routing is supported using cross-connect circuits (CCCs). CCCs use LSP stitching to combine two LSPs, where each LSP is entirely within a single area and the egress LSR of the first LSP is the ingress LSR of the second LSP. To configure CCCs, you need to ensure the following: On the ingress LSR of the second LSP, define a stitched LSP in the MPLS Parameters > Cross-Connects Parameters > LSP Stitching attribute. Specifies the first LSP as the Receive LSP and the second LSP as the Transmit LSP. The ingress LSR includes a static route (or policy-based routing) to the egress LSR. This static route specifies the inter-AS LSP as its next hop. Static routes are configured in the IP > IP Routing Parameters > Static Routing Tables attribute.

SP Guru/Release 11.5

SPM-5-11

5MPLS Model User Guide

Specialized Models User Guide

Figure 5-6 Cross-Connect Circuit Configuration

RED_GREEN is a CCC that joins the RED and GREEN LSPs.

This static route tells router A to use the RED LSP to get to 192.0.7.0/24. You do not need to configure an explicit route to REDs egress router since it is in the same area.

Traffic Engineering in MPLS Networks


The first step in a traffic engineering study is to determine whether or not traffic engineering is required for a given network. You can make this determination by doing an IGP analysis of the network. If the IGP analysis shows that one or more links are highly utilized while others are virtually unused, the network can benefit from traffic engineering. In this case, the next step is to create LSPs in the network that will direct traffic from the over-utilized links towards the less utilized links. After you have determined that a traffic engineering analysis is needed and configured the LSPs to direct traffic to less congested links, you can do the analysis by running a discrete event simulation or a flow analysis.
Traffic Engineering Without DiffServ

You can create LSPs in the network topology by using one of the methods described in Configuring Dynamic LSPs on page SPM-5-3, or you can create LSPs based on the traffic flows configured in the network. This operation (Protocols > MPLS > Configure LSPs from Demands) creates an LSP with the same source and destination as each traffic flow in the network. By setting up constraints on the LSPs, such as requiring that links possess a fixed amount of available bandwidth, you can ensure that traffic will flow over some of the less utilized links in the network. After configuring LSPs, you can do another IGP analysis to make sure that traffic is flowing over the less-utilized links.

SPM-5-12

SP Guru/Release 11.5

Specialized Models User Guide

5MPLS Model User Guide

Traffic Engineering With DiffServ

Traffic Engineering with DiffServ (DS-TE) lets you control LSP routing on a service class basis. The main difference between traffic engineering with and without DiffServ is that DiffServ lets you associate an LSP with a specific class of service. Generally, there is only one class of service for each DS-TE LSP, however, you can assign more than one class of service (CoS) to an LSP. Cisco supports a maximum of two CoS, Juniper supports up to eight.

Procedure 5-7 Using DiffServ in Traffic Engineering Studies 1 Create one LSP for each class of service supported between a source and destination. Cisco implementation permits two or fewer classes per LSP, Juniper permits eight or fewer. 2 Configure policy routing on the interface to map the CoS to the appropriate LSP. 2.1 Define a route map in the IP > IP Routing Parameters > Route Map Configuration attribute that sets the next hop to the intended outgoing LSP. 2.2 Assign the route map to the appropriate interface in the IP Routing Parameters > Interface Information > Policy Routing attribute. 3 Size the LSPs. 3.1 Run the size LSPs design action to get the amount of traffic flowing through these LSPs. 3.2 Partition the DS-TE interfaces according to the aggregate BW for each class type. 4 Run the DS-TE design algorithm to get the optimal path setup for the LSPs of different class types. End of Procedure 5-7

Available Reports
The following reporting tools are available when analyzing MPLS traffic engineering: Link usage reports (discrete event simulation and flow analysis) Link throughput and usage statistics (discrete event simulation and flow analysis) Link visualizations (discrete event simulation and flow analysis) Cross Connect Config (flow analysis) Cross Connects (flow analysis) LSP usage report (flow analysis)
SP Guru/Release 11.5 SPM-5-13

5MPLS Model User Guide

Specialized Models User Guide

Link subscription report (flow analysis) LSP load and utilization statistics (discrete event simulation)

MPLS TE Design Actions


A design action is a high-level operation that automates the process of changing a network model, usually to achieve a design goal. The following design actions are available for MPLS traffic engineering. MPLS Traffic Engineering (mpls_te) Minimum Cost MPLS Topology Design (min_cost_mpls_net_design) For more information about these design actions, see the Planning and Design User Guide.

Fast-Reroute in MPLS
Fast reroute offers local protection against failures by using bypass tunnels. The model includes two methods of backup protection: Facility backup One-to-one backup One-to-one backup creates detour LSPs for each protected LSP at each potential Point of Local Repair (PLR) along the path. Facility backup (many-to-one backup) creates a bypass tunnel to protect a potential failure point. It protects a set of protected LSPs that have similar backup constraints.

Facility Backup Using Bypass Tunnels


Facility backup creates a bypass tunnel to protect a potential failure point. This section describes how to Configure a bypass tunnel Set bandwidth quotas
Configuring Bypass Tunnels

A bypass tunnel protects an interface on a point of local repair against downstream link/node failures. Procedure 5-8 describes how to set up bypass tunnels.

SPM-5-14

SP Guru/Release 11.5

Specialized Models User Guide

5MPLS Model User Guide

Figure 5-7 A Bypass Tunnel

Bypass tunnel protects against node and link failures.

Procedure 5-8 Configuring a Bypass Tunnel 1 Open the Attributes dialog box for the node at the start of the bypass tunnel. 2 Open the MPLS > MPLS Parameters > Interface Information > Bypass Tunnel Configuration attribute. 3 Set the LSP Name to the name of an LSP that should be used as a bypass tunnel in the event of a node or link failure. 4 Click OK to close the attribute dialog box(es). End of Procedure 5-8

Setting Bandwidth Quota

You can configure bandwidth protection that lets you limit the amount of bandwidth used for bypass tunnels. With bandwidth protection, the total bandwidth used by all LSPs using a bypass tunnel cannot exceed the bandwidth quota of the bypass. When assigning bypass tunnels, there must be sufficient backup bandwidth. You can set the bandwidth quota used for facility backup by configuring the Minimum Bandwidth attribute in the LSPs TE Parameters attribute.

One-to-One Backup
For one-to-one backup, detours are predetermined for all the potential points of local repair along the path of the protected LSP. When a PLR detects an immediate downstream link or node failure, it switches traffic to detour using label swapping. Another detour merges back to the protected LSP, if feasible. Only one detour can be used to protect one LSP.

SP Guru/Release 11.5

SPM-5-15

5MPLS Model User Guide

Specialized Models User Guide

Design Actions for Fast Reroute


The following design action is available for MPLS fast reroute. MPLS Minimum Fast Reroute Design (mpls_frr_bypass_lsp_routing) For more information about these design actions, see the Planning and Design User Guide.

MPLS Failover Mode in Flow Analysis


When you are using flow analysis to simulate fast reroute in MPLS networks, a configuration option is available that lets you specify the rerouting mode. The MPLS Rerouting Mode option has four settings: Head-End Reroute Only, Full Reroute (All LSPs), Fast Reroute Only, and Steady State (Head-end and Fast Reroute). See Chapter 2 Using Flow Analysis on page FA-2-1 for a description of this option.

MPLS for Layer-3 VPNs


Support for MPLS for Layer-3 VPNs is implemented, in accordance with RFC 2547. Configuration occurs on provider core routers (P), provider edge routers (PE), or customer edge routers (CE). The P and the PE routers form the MPLS domain and should have a full-mesh of LSPs.

MPLS Configuration
There are two ways to create LSPs when analyzing Layer-3 VPNs. The LSPs can be LDP-based paths, or you can create traffic engineered LSPs manually. Each method is described below.
LDP-Based Paths

To use this method, you need to enable LDP for all routers and router interfaces running LDP. Make sure that the following settings are configured: MPLS > LDP Parameters > Status attribute enabled on all routers MPLS > LDP Parameters > Interface Information > Status attribute enabled for all interfaces For an LDP-based path, the local LSR, on which LDP is enabled, finds other LDP-enabled devices through the use of a Hello protocol. The LDP-enabled devices form adjacencies by negotiating operational parameters. Eventually, these adjacent routers participate in the LSP, and the LSPs follow the IGP path through the network.

SPM-5-16

SP Guru/Release 11.5

Specialized Models User Guide

5MPLS Model User Guide

Dynamic/Static LSPs

You can also use dynamic or static LSPs for your Layer-3 VPN analysis. See Procedure 5-1, Procedure 5-2, and Procedure 5-3, for information on manually creating dynamic and static LSPs.

VPN Routing/Forwarding (VRF) Instance Configuration


The following steps are needed for VRF instance configurations: Define VRF instances on PE nodes Associate VRF instances with router interfaces Set up routes to PE/CE nodes. NoteThese routes can be static routes or generated by routing protocols Configure BGP neighbors
Defining VRF Tables

The first step in configuring a VRF instance in a network model is to define the VRF tables on each of the PE nodes in the network. Procedure 5-9 describes how to do this.

Procedure 5-9 Defining VRF Tables on PE Nodes 1 Open the Attributes dialog box for the PE node. 2 Configure the VRF tables in the VPN >Network Based > VRF Instances attribute. This compound attribute lets you specify the route distinguisher, route target, and import and export policies for each VRF on the node. 3 Close the Attributes dialog box by clicking OK. End of Procedure 5-9

Associating VRF Tables with Interfaces

After you have defined the VRF tables on the PE nodes, you must associate the tables with individual router interfaces.

Procedure 5-10 Associating VRF Tables with Individual Interfaces 1 Open the Attributes dialog box for the PE node. 2 Set the Routing Instance (IP > IP Routing Parameters > Interface Information > Routing Instance) attribute to the appropriate VRF table defined in Procedure 5-9.
SP Guru/Release 11.5 SPM-5-17

5MPLS Model User Guide

Specialized Models User Guide

3 Close the Attributes dialog box by clicking OK. End of Procedure 5-10

Configuring Routes to PE and CE Nodes

Next you must configure routes to the PE and CE nodes. You can configure these routes in two ways: static routes and routing protocols. See Chapter 9 IP Model User Guide on page STM-9-1 for information on configuring static routes and routing protocols.
Configuring BGP Neighbors

For BGP neighbors, you need to configure the neighboring nodes to recognize each other as neighbors and thus share routes. This is typically done between all of the PE nodes. See Chapter 3 BGP Model User Guide on page STM-3-1 for more information on configuring BGP neighbors. When using BGP-MPLS VPNs, you must also configure the Send-Community attribute on all PE neighbor connections to ensure that DES and Flow Analysis work properly. DES and Flow Analysis explicitly check the value of this attribute to determine whether to keep or strip the route target extended communities from the BGP update.

BGP Configuration
Some additional BGP configuration is needed when setting up Layer-3 VPNs. Send communities must be enabled for Layer-3 VPNs to work. Additional configuration is also needed to accommodate the different address families that exist in the network. BGP configuration is per address family. Layer-3 VPNs need both an IPv4 address family and a VPNv4 address family. Any VRFs that are configured also need a separate BGP configuration. Each address family is configured by adding a row to the BGP Parameters table, shown below.
Figure 5-8 BGP Configuration for Layer-3 VPNs

SPM-5-18

SP Guru/Release 11.5

Specialized Models User Guide

5MPLS Model User Guide

If the VRFs are configured to use BGP, you must set up the BGP neighbor relationships as described in Chapter 3 BGP Model User Guide on page STM-3-1. If the VRFs use another routing protocol, you need to configure redistribution between that routing protocol and BGP.

PE-CE Routing Protocols


BGP or an IGP is required to route traffic between the PE and CE. Choosing between three supported protocolsRIP, OSPF, or EIGRPconfigure redistribution between BGP and the selected IGP. You can also redistribute static routes or directly-connected routes into BGP. To do this, edit attributes on the PE node and select IP Routing Protocols > BGP Parameters > Address Family Properties > Redistribution.
Figure 5-9 Redistribution into BGP

SP Guru/Release 11.5

SPM-5-19

5MPLS Model User Guide

Specialized Models User Guide

VPLS and L2 VPNs


This section describes how to configure VPLS and Layer-2 VPNs over MPLS networks. BGP or LDP can be used for auto-discovery and signalling of VPLS and Layer-2 VPNs. The method for configuring VPLS and Layer-2 VPNs differs depending on the protocol used, BGP or LDP.

BGP-Based VPLS and Layer-2 VPNs


BGP-based VPLS and Layer-2 VPNs are configured on service provider core routers (P) and service provider edge routers (PE). Configuring BGP-based VPLS and Layer-2 VPNs consists of three main steps: 1) Create a tunnel LSP between PE routers 2) Configure an IGP on PE and P routers 3) Configure an IBGP session between PE routers
Creating Tunnel LSPs Between PE Routers

Tunnel LSPs are point-to-point interconnections between PE routers that aggregate and transfer individual customer traffic. Before creating tunnel LSPs, you first need to enable MPLS on all router interfaces.

Procedure 5-11 Enabling MPLS on all Interfaces Between PE and P Routers 1 Enable the following attributes on all routers and router interfaces between the PE and P routers. MPLS > MPLS Parameters > Status MPLS > MPLS Parameters > Interface Information > Status End of Procedure 5-11

Enabling LDP or RSVP-TE to Create Tunnel LSPs

There are two ways to create LSPs when analyzing VPLS or Layer-2 VPNs. The LSPs can be LDP-based paths or you can create traffic engineered LSPs manually. Procedure 5-12 describes the steps needed to enable the creation of LDP-based paths in the network.

Procedure 5-12 Configuring LDP-Based Paths 1 Enable the following attributes on all P and PE routers. MPLS > LDP Parameters > Status
SPM-5-20 SP Guru/Release 11.5

Specialized Models User Guide

5MPLS Model User Guide

MPLS > LDP Parameters > Interface Information > Status End of Procedure 5-12

Dynamic/Static LSPs

You can configure dynamic or static LSPs between PE routers, which use RSVP-TE or CR-LDP for signaling. For VPLS, PE routers should have a full-mesh of dynamic LSPs. For Layer-2 VPNs, the dynamic LSPs depend upon a point-to-point connection between PE routers. See Procedure 5-1, Procedure 5-2 or Procedure 5-3 for details on configuring dynamic LSPs.
Configuring an IGP on PE and P routers

For Layer-2 VPNs and VPLS to work properly, the PE and P routers should be able to exchange routing information. You must configure an IGP or static routes between these routers. If you configured dynamic or static LSPs to create tunnel LSPs, you must configure OSPF or IS-IS as the IGP. For label exchanges to occur, an IBGP session needs to be configured between the PE routers. The following configuration needs to be done:

Procedure 5-13 Configuring an IBGP Session Between PE Routers 1 Set the IP Routing Parameters > BGP Parameters > Address Family attribute to L2VPN. This lets BGP neighbors exchange labels in the BGP advertisements. 2 Set the IP Routing Parameters > BGP Parameters > Address Family Properties > Status attribute to Enabled. 3 Configure the IP Routing Parameters > BGP Parameters > Address Family Properties > Neighbor Information attribute so that it includes an entry for the other PE routers. The IP Address should be the address of the loopback interface of the neighboring PE router. 4 Set the Send-Community attribute to Enabled. End of Procedure 5-13

Configuring Layer-2 VPNs

This section describes the configuration needed for BGP-based Layer-2 VPNs. This configuration is done on PE routers.

Procedure 5-14 Configuring Layer-2 VPNs 1 Create a L2VPN instance in VPN > Network Based > L2VPN/VPLS Instances > BGP Based > Instance Information.
SP Guru/Release 11.5 SPM-5-21

5MPLS Model User Guide

Specialized Models User Guide

2 Set the Instance Type to L2VPN. 3 Configure the Route Target, Route Distinguisher, and Site Information attributes. 4 Associate the interface on the PE router with the L2VPN instance on which the router receives traffic from the customer. 5 Set the Status to enabled. 6 Configure the Site Name and Remote Site ID attributes. End of Procedure 5-14

Configuring VPLS

This section describes configuration required for BGP-based VPLS on PE routers.

Procedure 5-15 Configuring VPLS 1 Create a VPLS instance in VPN > Network Based > L2VPN/VPLS Instances > BGP Based > Instance Information. Make sure the Instance Type is set to VPLS. 2 Configure the Route Target, Route Distinguisher, and Site Information attributes. 3 Associate the interface on PE router with the VPLS instance on which the router receives traffic from the customer. 4 Set the Status to Enabled. 5 Set the Site Name. Make sure that Leave Remote Site ID is set to Not Configured. End of Procedure 5-15

LDP-Based VPLS and Layer-2 VPNs


LDP-based VPLS and Layer-2 VPNs use LDP as the auto-discovery and signaling protocol. The PE routers should have Layer-2 and Layer-3 modules. Customer Edge routers (CE) should connect to the Layer-2 module of the PE routers. The procedures for creating a tunnel LSP between PE routers and for configuring an IGP on PE and P routers are the same as for BGP-Based VPLS and Layer-2 VPNs. Refer to Procedure 5-12 and Procedure 5-13 for details.
Configuring Layer-2 VPNs

This section describes how to configure LDP-based Layer-2 VPNs. The first step in this process is to configure Layer-2 forwarding equivalence classes (FECs) on the PE routers

SPM-5-22

SP Guru/Release 11.5

Specialized Models User Guide

5MPLS Model User Guide

Procedure 5-16 Configuring Layer-2 FECs on PE Routers 1 Create a FEC for each customer in the VPN > Network Based > L2VPN/VPLS Instances > LDP Based > Layer-2 FECs attribute. You can use the VLAN ID, port, or both as the FEC. 2 Configure the remote peer in the Remote Peer Configuration attribute. Make sure that the VC ID and the Group ID match the Layer-2 FEC configuration. 3 If you are using VLAN ID as the FEC, configure the VLAN on the PE router. Create an entry for the VLAN in the VLAN Parameters > Supported VLANs. Map the VLAN to the ports by configuring Switch Port Configuration > VLAN Parameters. End of Procedure 5-16

Configuring VPLS

This section describes the specific configuration for LDP-based VPLS. To do this, you must configure VPLS Profiles on the PE routers.

Procedure 5-17 Configuring VPLS 1 Create an entry for a VPLS profile for each customer in the VPN > Network Based > L2VPN/VPLS Instances > LDP Based > VPLS Profiles attribute. 2 Configure the Customer ID, VLAN IDs and the Port List. 3 Specify the remote peers and their associated VC properties in the Remote Peer Configuration attribute. Make sure that the VC ID and the Group ID match the Layer-2 FEC configuration. 4 If you are using VLANs, configure the VLAN on the PE router. Create an entry for the VLAN in the VLAN Parameters > Supported VLANs attribute. Map the VLAN to the ports by configuring the Switch Port Configuration > VLAN Parameters attribute. End of Procedure 5-17

SP Guru/Release 11.5

SPM-5-23

5MPLS Model User Guide

Specialized Models User Guide

Reports
In addition to the reports covered in Available Reports on page SPM-5-13, the following reports and statistics are available for all MPLS studies.

DES Statistics
The following statistics are available for collection when running discrete event simulations.
Figure 5-10 MPLS Related Statistics

Flow Analysis Reports


The following reports are available when running a flow analysis for MPLS networks. Configuration reports: LSP Bypass Tunnel Parameters LSP Configuration LSP Fast Reroute Parameters LSR Configuration Performance reports: LSP Bypass Tunnel Usage
SPM-5-24 SP Guru/Release 11.5

Specialized Models User Guide

5MPLS Model User Guide

LSP Rerouting LSP Routes LSP Utilization LSR Usage

Display LSP Routes


You can use the Display LSP Routes feature to show the routes of LSPs in the Project Editor. This feature is available through the Protocols menu (Protocols > MPLS > Display LSP Routes) or by pressing Ctrl+Shift+L.
Figure 5-11 Displaying LSP Routes

Display Routes from Connections Browser


For flow analysis, you can also display LSP routes within the Connections Browser. This method of displaying routes is described in Viewing LSP Routes in the Connection Browser on page SPU-8-22 of the User Guide

SP Guru/Release 11.5

SPM-5-25

5MPLS Model User Guide

Specialized Models User Guide

Troubleshooting MPLS Network Configurations


This section covers some configuration problems that you might encounter while configuring MPLS network models.

Unroutable LSPs
When you show LSP routes after a discrete event simulation or flow analysis, some of the LSPs might be unroutable. The flow analysis Failed LSP report might also indicate that one or more LSPs are unroutable. When this occurs, you can determine the cause of an unroutable LSP by checking the following common causes: Loopback interface not configured with routing protocol. Make sure that the source and destination nodes of the LSP have the routing protocol properly configured for the loopback interfaces. IGP routing protocol not configured. The IGP routing protocol may not have a route for the source-destination pair of the LSP. Check the routing tables to make sure that a route exists.

VRF Tables Not Built Correctly


There are two main causes of VRF tables not being built correctly: No VRF on PE. If there are no VRFs configured on the PE node, first check the VRF configuration. Next, check the PE-CE routing protocol and adjacency. No remote peer routes in VRF. First, check the internal BGP configuration under VPNv4 address family. Next, make sure that the send community is enabled. Finally, make sure that there are LSPs on LDP paths between PE routes.

Model Limitations
DES Limitations
The following features are not modeled for discrete event simulations: Layer-2 VPNs and VPLS Inter-domain routing Detour paths for LSP fast reroute

SPM-5-26

SP Guru/Release 11.5

Specialized Models User Guide

5MPLS Model User Guide

Reference Documents
MPLS models are implemented based on information available from the following sources.
Table 5-3 Reference Documents (Part 1 of 2)
Model Features Traffic Engineering MPLS TE RFC-2702Requirements for Traffic Engineering Over MPLS RFC-3031Multiprotocol Label Switching Architecture draft-hsmit-mpls-igp-spf-00 Document

FECs

IGP shortcuts Label Switched Paths Dynamic LSPs Static LSPs LSP routing OSPF TE IS-IS TE Label distribution LDP CR-LDP RSVP-TE

RFC-3031Multiprotocol Label Switching Architecture

RFC-2676QoS Routing and OSPF Extensions

RFC-3036LDP Specification RFC-3212Constraint-based LSP Setup Using LDP RFC-3209RSVP-TE: Extensions to RSVP for LSP Tunnels

PP-VPNs A framework for layer-3 PP VPNs BGP/MPLS VPNs Quality of Service QOS Architecture RFC-2475An Architecture for Differentiated Services RFC-2547BGP/MPLS VPNs draft-ietf-ppvpn-framework-05

SP Guru/Release 11.5

SPM-5-27

5MPLS Model User Guide

Specialized Models User Guide

Table 5-3 Reference Documents (Part 2 of 2)


MPLS Support of Differentiated Services Restoration and Resiliency Fast reroute with bypass tunnels LSP protection with ingress backup End of Table 5-3 draft-ietf-mpls-rsvp-lsp-fastreroute-00 RFC-3270Multi Protocol Label Switching draft-ietf-mpls-diff-ext-08

SPM-5-28

SP Guru/Release 11.5

Specialized Models User Guide

6PNNI Model User Guide

PNNI Model User Guide


Private Network-to-Network Interface (PNNI) is a hierarchical ATM routing protocol that distributes information among switches and computes paths through the ATM network. This document describes key features of the PNNI model shipped as part of the specialized OPNET model library.

Model Features
This section provides a list of the main features available in the PNNI model. The PNNI model suite captures the following protocol behavior.
Table 6-1 PNNI Model Features (Part 1 of 2)
Feature Flexibility Description The model has many configurable parameters. The PNNI model allows you to configure the following: Up to 104 hierarchical levels External static routes to external PNNI domains Routing metric metrics can be administrative weights, cell transfer delay, or cell delay variation Complex node parameters to govern the costs of traversal of logical nodes Report generation The model provides several ways to easily display a networks configuration information. The PNNI model allows you to print the following: Node information, such as group IDs, peer group leader status, and node ID Route information for the PNNI domain Hierarchical addressing information Topology Database on a node at various times during the simulation NNI Signaling NNI (Network Node Interface) signaling is used during call setup and call tear-down procedures.

SP Guru/Release 11.5

SPM-6-1

6PNNI Model User Guide

Specialized Models User Guide

Table 6-1 PNNI Model Features (Part 2 of 2)


Feature Topology Discovery in Fast-Mode PNNI Description Topology information is instantaneously propagated to all nodes in the network. No latency is involved in updating changes in the network. Topology databases are maintained on a per-group basis instead of a per-node basis. Topology database is not subject to aging. Topology Discovery in Explicit PNNI Topology discovery is done in the explicit mode, where the Hello protocol first discovers the neighbor links and nodes. Then, database synchronization and flooding is done to propagate the topology information in the network. All changes in the network take time to propagate to other nodes in the network. Topology databases are maintained on a per-node basis. Topology database is subject to aging. Peer Group Leaders Peer group leaders are selected based on: 1) the peer group leader election algorithm 2) the peer group leader priority configured on each node in a peer group.

End of Table 6-1

OPNETs PNNI model follows the ATM forums PNNI 1.0 specification. Djkstras algorithm is used to compute shortest path routes through the network. PNNI models are implemented based on information available from the following sources:
Table 6-2 Reference Documents
P-NNI V1.0 PNNI 1.0 ATM Forums: Private Network-Network Interface Specification Version 1.0 (PNNI1.0)

End of Table 6-2

PNNI Modes
The ATM Dynamic Routing Protocol attribute determines the type of routing protocol running in the network. The three dynamic protocol options are: Explicit PNNI Fast-Mode PNNI Distance Vector routing

SPM-6-2

SP Guru/Release 11.5

Specialized Models User Guide

6PNNI Model User Guide

See Simulation Attributes on page SPM-6-8 for more details.

Local Attributes
Every NNI node (ATM switch) has an attribute called ATM > ATM Routing Parameters > PNNI Parameters, which is used to specify PNNI configuration parameters. Note that workstations, servers, and routers are not NNI nodes and do not have the PNNI Parameters attribute.
Figure 6-1 Default Settings for PNNI Parameters Attribute

The ATM PNNI Parameters attribute consists of several sub-attributes, which can be viewed by double-clicking in the Value field (or by selecting Edit... from the Value field pull-down menu). Some of the important PNNI model attributes are: Level Information. This compound attribute specifies hierarchy information for nodes using PNNI. The model uses the level information to configure the Physical Level Node IDs, Logical Group Node IDs, and Peer Group IDs that the PNNI protocol requires to make routing decisions. The default setting configures all nodes to be at the lowest level.

SP Guru/Release 11.5

SPM-6-3

6PNNI Model User Guide

Specialized Models User Guide

To configure the Level Information attribute, double-click in the Value column to open the Level Information Table dialog box. Set the number of rows to be equal to the number of levels the node is represented in. There should be one row for each level including the physical level. For example, if there are 4 levels (the physical level + 3 logical levels) the node is represented in, then the table should have 4 rows. The three Level Information parameters are described below: Level ID. This attribute specifies the nodes level as an integer value from 0 to 103, inclusive. Each row corresponds to a unique hierarchical level that is identified by the Level ID. The default value for the physical level, which is the level depicted when you build your network topology, is 80. The physical layer is denoted by the Level ID with the highest value, while higher hierarchical levels are denoted by lower values. Group ID. This attribute specifies which group the node belongs to, at the specified level. The value can be any integer from 1 to 999, inclusive. Peer Group Leader Priority. This attribute specifies a priority value that is compared to other nodes in the peer group. The node with the highest non-zero leadership priority is selected as the peer group leader. The peer group leader is the node through which all nodes in the group are visible to higher levels and groups. If the peer group leader node fails, the hierarchy above it collapses, and the other nodes in the group are no longer visible to the rest of the network. If there are multiple nodes in the peer group with the same Peer Group Leader priority, the node with the higher ATM address is chosen to be peer group leader. If all nodes in the peer group have a zero priority, there is no peer group leader in that group and it is not represented at any higher logical levels. By default, all nodes have a zero priority, which means that a network with default attribute settings, will be a flat PNNI network, and all nodes belong to the same peer group. For additional information on how to set up groups and hierarchies in your network model, see Configuring Group and Hierarchy Information on page SPM-6-10. Static External Routes. Inter-routing between NNI domains is accomplished by configuring external static routes. If you are inter-connecting two or more NNI domains, be sure to specify Static External Routes on all border nodes, which are the nodes that connect to other domains. To define external routes to NNI domains, add a row for each NNI domain, specifying the destination ATM address and the output port number for each domain.

SPM-6-4

SP Guru/Release 11.5

Specialized Models User Guide

6PNNI Model User Guide

Figure 6-2 Specifying External Routes

PNNI Metric. This attribute specifies the metric used to select the shortest path route to the destination. It is used by the ingress NNI node (entry border node) of every peer group to calculate the route through that peer group to reach the destination. One of the following metrics can be specified to determine the shortest path route: Administrative Weight (AW) Cell Transfer Delay (CTD) Cell Delay Variation (CDV) Administrative Weight is the default PNNI metric. For CBR and VBR traffic, the route selected must also meet the cell transfer delay and cell delay variation constraints specified by the traffic contract (a rule that applies to all PNNI metrics). Because these CTD and CDV constraints must be met, it is possible that when Administrative Weight is specified as the PNNI metric, the selected route may not have the lowest administrative weight value. For CBR and VBR traffic, if the shortest path computed using the administrative weights metric does not satisfy the CTD or CDV constraint, a new path is computed using the CTD metric. If this path does not satisfy the CDV constraint, a third path is computed using the CDV metric. If this path does not satisfy the CTD constraint, no route is found to the destination. A similar procedure applies if either CTD or CDV is selected as the metric. Administrative Weight. This per-port per-category attribute specifies the cost incurred when traversing the link on that port for the particular category. It is specified in the Per-Port Configuration attribute in the ATM Parameters attribute (see Figure 6-3).

SP Guru/Release 11.5

SPM-6-5

6PNNI Model User Guide

Specialized Models User Guide

Figure 6-3 Specifying Administrative Weight on a Port

maxCTD and ppCDV. Cell transfer delays (maxCTD) and cell delay variations (ppCDV) are node attributes, which are specified in a nodes QoS Parameters Table on a per-port per-category basis.
Figure 6-4 Specifying CTD and CDV on a Node

SPM-6-6

SP Guru/Release 11.5

Specialized Models User Guide

6PNNI Model User Guide

Complex Node Parameters. This attribute governs the cost of traversal of the logical node in the PNNI hierarchy. The complex node parameters are shown in Figure 6-5.
Figure 6-5 Complex Node Parameters

Load Balancing Scheme. This attribute determines the type of load balancing scheme used to differentiate between equal cost paths to a destination. The three load balancing options are Maximum Bandwidth, Random Uniform, or Disabled. Maximum Bandwidth. This approach selects the maximum bandwidth link at every node when walking backwards from the destination towards the source when building the shortest path tree. Random Uniform. This approach selects a random link at a node based on a uniform distribution when walking backwards from the destination towards the source when building the shortest path tree. Disabled. No load balancing takes place on this node if you specify Disabled. The same path is chosen for every call between a source and destination until there is not enough bandwidth to support the call. If GCAC fails on that route, a new route will be chosen. PNNI Node Information Print. This attribute specifies when to print out the topology database of the node to the simulation log. This attribute is used only by Explicit PNNI. Aggregation Token. This link attribute specifies link aggregation. If peer groups are connected by several links at the physical layer, you can specify that these links are represented by an aggregated link at the logical level. To specify that two or more links are aggregated at the logical level, specify the same Aggregation Token value for each link. Links with different aggregation tokens will not be aggregated. By default, all links are assigned the same aggregation token. Link aggregation is performed on all logical horizontal links and induced uplinks.
SP Guru/Release 11.5 SPM-6-7

6PNNI Model User Guide

Specialized Models User Guide

Simulation Attributes
The PNNI model suite has the following simulation attributes, which can be specified from the Configure Simulation dialog box. ATM Dynamic Routing Protocol. Specifies the type of dynamic routing protocol used in the network. You can select Distance Vector routing (no PNNI), or one of two PNNI routing protocols: Explicit PNNI and Fast-Mode PNNI. Explicit PNNI. This routing simulates PNNI routing based on explicit packet flows for topology discovery using the Hello protocol, database synchronization, and flooding. Explicit packet flow requires convergence time for discovery of the network. Any change in the network, such as link failures, take a finite time for propagation through the network. Fast-Mode PNNI. This routing simulates PNNI routing based on automatic discovery of the network. There is no explicit packet flow and hence no convergence time for discovery of the network. Any changes in the network are immediately known by all nodes in the network. The main difference between the two types of routing protocols are in the initial discovery on the network topology. After the routing protocol has stabilized and the entire topology is known, both routing protocols use Dijkstras shortest path algorithm to calculate the routes through the network based on the metrics specified. If you are only interested in the routes taken through the network, Fast-Mode PNNI is the best option. On the other hand, if you are more interested in the transient phase of convergence of the routing protocol or the propagation of information, Explicit Mode PNNI is the better option. ATM VC Routes Export. This attribute can be configured in the following ways: On source nodes (such as workstations) to export the path taken by each call established by the node. As a simulation attribute, or in the SPVX configuration utility object, to export routes for all calls set up in the network from all nodes. Setting this attribute to Export generates a text file containing the path information for each source node. The file is placed in your primary models directory (the first directory listed in your mod_dirs preference) and is named according to the following format: <project_name>-<scenario_name>-vc_routes.gdf
Figure 6-6 Exported Path Information

SPM-6-8

SP Guru/Release 11.5

Specialized Models User Guide

6PNNI Model User Guide

ATM Address Information Export. Setting this attribute to Export generates a text file containing the ATM addresses of each node in the network. The address information is exported to a file in your primary models directory with following naming format: <project_name>-<scenario_name>-atm_addresses.gdf
Figure 6-7 Exported ATM Address Information

PNNI Node Information Export. Setting this attribute to Export generates a text file containing a description of each peer group in the network. The PNNI node information is exported to the following file, which is placed in your primary models directory: <project_name>-<scenario_name>-pnni_node_info.gdf
Figure 6-8 Exported PNNI Node Information

SP Guru/Release 11.5

SPM-6-9

6PNNI Model User Guide

Specialized Models User Guide

PNNI Hello Stop Time. This attribute is used to specify the end time of hello packets exchanged in the network. By default, this attribute is Enabled, so that there will be no more routing updates after the specified time. Enabling this attribute speeds up the simulation run times. If you model failure-recovery, then set this attribute to Disabled. This attribute is used only by Explicit PNNI. PNNI Start Time. This attribute enables you to specify when the PNNI routing protocol is activated during the simulation. The PNNI start time should be at least 1 second before the SPVX start time, whose default value is 4 sec.

Configuring Group and Hierarchy Information


A networks group and hierarchy information is configured on a node-by-node basis. The models addressing scheme parallels the actual addressing scheme used in PNNI by modeling physical level node IDs, logical group node (LGN) IDs, and peer group IDs. The values specified for a nodes ATM Address, Level ID, and Group ID attributes determine its physical level node ID, LGN ID, and peer group ID. The rules used to derive a nodes addressing information from its attributes are described in the following table.
Table 6-3 Derivation Rules Used to Generate Node and Peer Group IDs
<level[n]_level_id>. <level[n-1]_level_id>. ... .<level[0]_level_id>.<level[n]_group_id>. <level[n-1]_group_id>. ... .<level[0]_group_id>.<atm_address> <level [n]_level_id>.<level [n-1]_level_id>. ... . <current_level_id>.<level [n]_group_id>.<level [n-1]_group_id>. ... . <current_group_id>.<atm_address> <level [n]_level_id>.<level [n-1]_level_id>. ... . <current_level_id>.<level [n]_group_id>.<level [n-1]_group_id>.....<current_group_id>

Physical Level Node ID

LGN ID

Peer Group ID
End of Table 6-3

SPM-6-10

SP Guru/Release 11.5

Specialized Models User Guide

6PNNI Model User Guide

Figure 6-9 Hierarchical Addresses

The following table shows the node and group IDs for Node 2 in Figure 6-9 (solid blue), whose ATM address is 1.
Table 6-4 Node and Group IDs for Node 1
Level 80 72 64 End of Table 6-4 Node ID 64.72.80.7.5.1.1 64.72.7.5.1 64.7.1 Peer Group ID 64.72.80.7.5.1 64.72.7.5 64.7

Figure 6-10 Level Information for Node 1

SP Guru/Release 11.5

SPM-6-11

6PNNI Model User Guide

Specialized Models User Guide

To define groups, configure each node in the group with the same Level ID and Group ID settings. Each node in the group, not just the peer group leader node, must be configured with all of its hierarchical information. Figure 6-11 shows the Level Information Table for Node 3. Note that the Level ID and Group ID settings are identical to those of Node 1, shown in Figure 6-10.
Figure 6-11 Level Information for Node 3

SPM-6-12

SP Guru/Release 11.5

Specialized Models User Guide

7Server Model User Guide

Server Model User Guide


Server processing delay is an integral part of the overall system response time and depends on the hardware and software configuration of the servers. Server modeling lets you examine the performance of the server as it interacts with other elements in the network. You can use server modeling to answer capacity-related questions, such as How much memory and how many CPUs and disks are needed? How do hardware resources affect application response time? How are the server components affected by increased application load? The server specialized model (SSM) is part of the specialized model library and works with discrete event simulation.

Model Features
The server model suite implements the following features.
Table 7-1 Server Model Features (Part 1 of 2)
Feature CPU Modeling Description Multitasking CPU modeling uses a prioritized preemptive round-robin scheduling algorithm for each CPU Partition CPUs can be grouped into CPU partitions and a CPU can be shared by several CPU partitions. Jobs that are bound to a CPU partition are executed only on CPUs in that partition. The model tracks memory usage to help predict server memory requirements. Hard and soft page faults are modeled. Jobs do I/O operations on storage partitions. The following storage partition types are modeled: Direct Attached Storage Measured Access Remote Storage Access Disk I/O Drives and drive interfaces are modeled.

CPU Partitions (Processor Sets)

Memory (RAM)

Page Faults Storage Partitions

SP Guru/Release 11.5

SPM-7-1

7Server Model User Guide

Specialized Models User Guide

Table 7-1 Server Model Features (Part 2 of 2)


Feature Multiple RAID levels Description RAID levels 0,1, 0+1, and 5 are modeled in the direct attached storage partition. Each write to a storage partition of any type can be replicated to a remote storage partition. Three modes of replication are modeled: Write-Replicate Replicate-Write Simultaneous In each mode, the replication can be synchronous or asynchronous. Write Caching Write operations to a storage partition can be cached so that the job that submitted the write does not incur an additional delay. The write operation will occur in the background.

Replication

End of Table 7-1

Server models are implemented based on information available from the following sources.
Table 7-2 Reference Documents
CPU2000 Manufacturer Specifications End of Table 7-2 Standard benchmarks published by SPEC (www.spec.org) Disk and interface performance are obtained from manufacturer data sheets.

Workloads are characterized by jobs. A job can be a single thread, a process, or a group of threads and processes that represent the target workload. Each job has its own resource requirements for CPU, memory, and I/O. Jobs can be executed as applications entirely within the server or as networked applications that scale according to the traffic load The model includes many predefined hardware configurations The model can operate with existing simple CPU server models

Workflow
Typical server modeling project should follow the workflow as shown below:

SPM-7-2

SP Guru/Release 11.5

Specialized Models User Guide

7Server Model User Guide

Figure 7-1 Server Modeling Workflow

In the Data Collection phase the server and applications to be modeled are identified and relevant data traces to model them is collected. In the Pre-Analysis phase the server data is used to characterize workload. OPNET Server Characterization Editor (SCE) module is a pre-analysis tool, see the SCE User Guide for more information about data collection and pre-analysis phases. The model definition and validation phase involves creating a model of the server in question and it network environment. Activities performed in the performance prediction phase depends on why the server is being modeled. The SSM can be used for these two phases.

Model Attributes
Server model attributes are configured in three locations: Server Configuration objectfor attributes common to all servers, such as hardware settings and job information Server Definitions are stored in an external file--for similar interface to the Server Definitions from both the SCE and project editor Individual server nodesfor attributes specific to a particular server
Figure 7-2 Server Model Objects

SP Guru/Release 11.5

SPM-7-3

7Server Model User Guide

Specialized Models User Guide

Server Configuration Object Attributes


The Server Configuration object has several attributes describing the underlying server hardware. Hardware attributes described in the Server Configuration object are listed below:
Figure 7-3 Server Configuration Object Attributes

Disk Drive Definitions. This attribute specifies hardware characteristics of common disk drives. Default values are obtained from manufacturer data sheets.
Figure 7-4 Disk Drive Definitions Attribute

SPM-7-4

SP Guru/Release 11.5

Specialized Models User Guide

7Server Model User Guide

Name. This attribute describes the physical driveit usually includes the manufacturer name and model number. Average Seek Time. This attribute specifies the average time required for the drives read/write head to position itself over the correct track. Maximum Seek Time. This attribute specifies the time required for the read/write head to travel from the first track to the last, or vice versa. It is similar to the Average Seek Time, but limited by the drives physical geometry. Average Latency. This attribute specifies the amount of time required for the drive to rotate to the correct position for the read/write operation to occur. Spindle Speed. This attribute specifies the maximum latency, which is determined from the rotational speed of the drive. The time required for one disk revolution is the maximum latency a drive can produce. Disk Transfer Rate. This attribute specifies the maximum rate at which data can be transferred over the drives interface bus (a drive may have faster internal transfer rates, however). Cylinders. Number of physical cylinders on the disk drive. This attribute value is not used by the server disk model. Capacity. The storage capacity of the disk drive in Megabytes. This attribute value is not used by the server disk model. Heads. Number of physical heads in the disk drive. This attribute value is not used by the server disk model. Disk Interface Definitions. The interface is a shared bus device that controls a variable number of disk drives. Many standard configurations are presented with the following attributes:
Figure 7-5 Disk Interface Definitions Attribute

SP Guru/Release 11.5

SPM-7-5

7Server Model User Guide

Specialized Models User Guide

Name. This attribute specifies a user-defined value that describes the physical interface. This typically includes the interface standard and any RAID (Redundant Array of Inexpensive Disks) configuration used by the device. RAID Configuration. This attribute has been deprecated, and the value is not being used by the server disk any longer. The RAID functionality has been moved to the local storage partition, hence the RAID configuration attribute is now a part of the Local Storage Partition definition attributes. Bus Transfer Rate. This attribute specifies the maximum data transfer rate between the drives and the interface. The actual transfer rate may be lower if the drives are slower. Only one drive can transfer data at a time. SSA - Serial Server Architecture. This is a standard developed by IBM to increase interface throughput by providing two read and two write buses. This allows up to four data transfer operations to occur concurrently, as long as they are to separate physical drives. Operating System Definitions. This attribute specifies operating system descriptions that include information on the default operating system and scheduling method used by the operating system.
Figure 7-6 Operating System Definitions

SPM-7-6

SP Guru/Release 11.5

Specialized Models User Guide

7Server Model User Guide

Name. A user-defined value which uniquely describes the operating system definition. Timeslice. This is the maximum amount of time a job will use the processor before giving up the CPU to another process. In general, smaller time slices will produce more events, resulting in longer simulation times. Scheduling Method. The algorithm used to dispatch jobs to processors. Currently two scheduling methods have been defined: Round-Robin. The algorithm schedules the first available highest priority job at the start of a timeslice or when the processor becomes free. The algorithm does not allow jobs to be pre-empted when a higher priority job becomes available. Pre-Emptive Round-Robin. The algorithm schedules the first available highest priority job at the start of a timeslice or when the processor becomes free. If a job becomes available when all the processors are busy, the lowest priority job with priority less than the newly available job, is preempted, so that the new job may execute. Job Definitions. This attribute specifies workload descriptions that include information on the measured performance of server jobs. These job definitions are independent of the servers they run on. When multiple copies of a job exist, the information is distilled into a single representative instance that can then be scaled. The attributes described here apply to the representative instance:
Figure 7-7 Job Definitions Table

SP Guru/Release 11.5

SPM-7-7

7Server Model User Guide

Specialized Models User Guide

Name. A user-defined value which uniquely describes the workload. Note: Job name remote_access is reserved and cannot be specified in the job definitions table. see the discussion of Job Definitions attribute in the Server Attributes section. Measured System. When simulating jobs for systems other than the one on which the measured values were obtained, the model needs to know how to scale these values. This attribute, along with the job class, allows scaling to be performed. The server description for this system must already exist before this value can be obtained. Job Class. As different jobs have different performance characteristics, each job can be assigned its own class. This value is obtained from the list of job classes provided for the server described in the Measured System. Since this value is used to scale jobs, it must exist in both the measured system described above, and in the target system described on the individual server. Average CPU Time. A distribution describing the amount of processor time consumed by the job. Average Page Faults. A distribution describing the number of page faults generated by a single job instance. This includes both hard (those requiring an I/O operation to exchange data with that on disk) and soft faults (those with data found in memory). Average I/O Reads/Writes. Distributions describing the typical I/O behavior of the job. These I/Os will be distributed evenly over the life of the job. Average I/O Read/Write Blocksize. Distributions describing the amount of data transferred by a single I/O operation. This will affect the I/O processing time. Memory Requirements. Memory usage is also tracked on a single instance basis. Since many applications use a minimum amount of memory regardless of the number of active instances, it may be desirable to define a job that consumes no resources other than memory to represent this baseline requirement.
Figure 7-8 Memory Requirements Table

SPM-7-8

SP Guru/Release 11.5

Specialized Models User Guide

7Server Model User Guide

Total Memory. All memory used by a job, including that resident in memory (the Resident Set Size), and that which is contained in swap. Resident Set Size. The amount of physical memory consumed by a job. This does not include any memory that resides in swap. Persistence. A distribution describing how long the memory is required. Typically this is set to Job Completion, which means the memory is relinquished when the job finishes. If the memory remains in use throughout the simulation, this should be set to End of Simulation. Server Definitions. Defines characteristics unique to specific servers. Predefined values are provided for systems with published SPEC ratings (see http://www.spec.org for more information). The Server Definition dialog provides the interface to the server definitions stored in an external file. The same dialog is displayed from both the Server Characterization Editor (SCE) and the project editor. The Server Definition dialog allows you to view and edit current server definitions, and create new server definitions. From the Project Editor, the server definitions can be accessed from the menu Protocols > Servers > Server Definitions > View (or in the SCE main window from the File > Server Definitions > View menu item). New server definitions can be defined either by entering the Edit mode from the View Server Definition dialog, or from the menu Protocols > Server Definitions > New... (and from the SCE main window from the menu File > Server Definitions > New...)

SP Guru/Release 11.5

SPM-7-9

7Server Model User Guide

Specialized Models User Guide

Figure 7-9 Server Definitions Dialog

SPM-7-10

SP Guru/Release 11.5

Specialized Models User Guide

7Server Model User Guide

Server Name. A user-defined value that describes the server. It typically includes the manufacturers name and model number, as well as other distinguishing information such as processor speed and number of CPUs. Each job definition refers to a server name, which identifies the server on which the job was measured. Also each server refers to a server name, which identifies the type of the server (processor type, number of processors, benchmarks, and default operating system). Server Manufacturer. This attribute specifies the manufacturer of the server. This attribute is not used by the server models, it is intended to be used by SCE for server matching. Processor Count. This attribute specifies the number of processors contained in the system. Processor Manufacturer. This attribute specifies the manufacturer of the processors used in the server. This attribute is not used by the server models, it is intended to be used by SCE for server matching. Processor Speed. This attribute specifies the speed (in MHz) of processors used in the server. This attribute is not used by the server models, it is intended to be used by SCE for server matching. Default Operating System. This attribute specifies the operating system on which the benchmark programs were executed. The operating system value refers to an entry in the Server Config objects Operating System Definitions attribute: which identifies the timeslice and scheduling algorithm to be used. Job Class Ratings. This is a list of standard benchmarks supported by the server. The predefined server configurations include the CPU2000 benchmarks published at http://www.spec.org. For multi-processor systems, the rate values have been divided by the number of processors to provide a per-processor rating.

SP Guru/Release 11.5

SPM-7-11

7Server Model User Guide

Specialized Models User Guide

Server Attributes
In addition to the Server Configuration attributes, a number of attributes are provided on the individual servers. These affect only the server on which theyre specified, although in many cases they rely on information provided in the Server Configuration object.
Figure 7-10 Server Modeling Attributes on Server Nodes

Server: Modeling Method. Currently the detailed server models can be used for standalone server modeling or can be used for end-to-end application performance modeling using Custom Application or ACE. Other existing OPNET application models continue to use the simple CPU model. And for those occasions when detailed modeling is not necessary, you can select which modeling method is right for a given server in your scenario. Simple CPU. This method uses a simple contention model to simulate server activity. The Simple CPU model is used to model the IP packet forwarding delays and application processing delays. Configuration specific to the simple CPU model is in the CPU Resource Parameters and CPU Background Utilization compound attributes (these attributes are not being described in this usage guide). Detailed Server. The detailed server modeling method uses the advanced modeling capabilities described in this document. A specialized license is required to run in Detailed Server mode. Note: In this mode, both the Simple CPU model and the detailed server models are active. The Simple CPU model continues to model IP packet forwarding delays and application processing delays (even custom application and ACE, unless the custom application and ACE configuration specifically are tied to the detailed server models).

SPM-7-12

SP Guru/Release 11.5

Specialized Models User Guide

7Server Model User Guide

All the attributes specific to the detailed server model are housed by the Server: Advanced Server Configuration attribute. These attributes are used to describe the CPU and IO subsystems of the server, to configure the storage partitions defined on the server and to list the workloads (jobs) to be run on the server.
Figure 7-11 Advanced Server Configuration Table

Server Type. The name of a server type as described in the Server Definitions dialog. It describes the characteristics of this, the target, server. The server name specified is used to obtain the following information: number of CPUs configured on the server, its benchmark ratings and the default operating system. CPU Partitions. Allows the CPUs of the server to be grouped into processor sets, called CPU Partitions. Each CPU Partition acts like an independent server, each CPU partition can run a different operating system and has its own paging system. Each CPU Partition maintains its own job queue. Workloads (jobs) are bound to CPU Partitions, which is to say that jobs run only on the CPUs which belong to that CPU Partition. A CPU can belong to multiple CPU Partitions, and these CPU Partition have an equal weight to use that CPU. A CPU is assigned the highest priority job among the ready job queues of all the CPU Partitions sharing that CPU. A default CPU Partition, identified by name Default should always be configured. All unassigned CPUs are assigned to this CPU Partition. By default, all jobs are assigned to this partition. CPU Partition configuration involves specifying an unique name, the list of CPUs belonging to the CPU Partition, specifying the operating system to run on it and its paging system definition. Each of these attributes are described in more detail next.

SP Guru/Release 11.5

SPM-7-13

7Server Model User Guide

Specialized Models User Guide

Figure 7-12 CPU Partitions Table

Name. A value used to uniquely identify this CPU Partition for binding jobs to it and for statistic reporting. CPU List. The list of CPUs belonging to this CPU Partition, the CPUs are identified by their index starting with zero.
Figure 7-13 CPU List Table

Each row in the CPU List Table specifies an index range. The list of CPU is formed by performing an union operation of all the index ranges. Operating System.An operating system description as given in the Server Configuration object. This describes the timeslice and the scheduling algorithm to be used for the CPUs belonging to this CPU Partition. Note: When a CPU is shared by multiple CPU Partitions, the operating systems configured on those CPU partitions should have the same timeslice. Paging System Definitions. Each CPU partition is associated its own paging system, definition includes the following:

SPM-7-14

SP Guru/Release 11.5

Specialized Models User Guide

7Server Model User Guide

Figure 7-14 Paging System Definitions Attribute

a) Average CPU Time (seconds). The amount of CPU time used by a single paging operation, whether hard (requiring an I/O) or soft (not requiring an I/O). b) Page I/O Read/Write Count. In the case of a hard fault, a paging operation requires I/O operations. These distributions determine the number of reads and writes required. c) Page Size (Bytes). Unlike standard I/O operations, paging operations are defined by the operating system, not the job. d) Storage Access Distribution. The paging system needs to know how paging operations will be distributed across the available storage partitions. Storage Partition Name. The name of the storage partition to receive the I/O operation. Access Weight. Each storage partition is assigned an access weight that determines which storage partition receives an I/O operation. Two storage partitions with equal weights receive an equal number of operations when averaged over a simulation. e) Hard Fault Percentage (%). The job definitions determine how many page faults are generated by an application. This parameter determines how many of those are found in memory, and how many require an I/O operation Local Storage Subsystem. A description of the physical layout of the disks and disk interfaces connected to a system. This represents the servers direct attached storage (DAS) configuration.

SP Guru/Release 11.5

SPM-7-15

7Server Model User Guide

Specialized Models User Guide

Figure 7-15 Local Storage Subsystem

Maximum Physical I/O. When defined, this parameter causes large data transfers to be divided into several smaller transfers. In the case of RAID configured systems (except for RAID 1, more about RAID configuration shortly), the lower of this and the data stripe size determine the maximum size of data transfer. Interface Configuration. As in a real server, an interface contains one or more interface channels to which are connected zero, one or more disk drives. They are specified in a similar fashion:
Figure 7-16 Interface Configuration Table

Interface Name. A value used to uniquely identify this interface for statistic and reporting purposes. Interface Type. An interface description as given in the Server Configuration object. This describes the hardware characteristics of the interface. Cache Hit Percentage. The portion of all disk reads that are retrieved directly from the controllers onboard cache without requiring a disk access. Interface Channels. Each disk interface can have one or more interface channel. The Interface Channel Table has only one column: the Disk Configuration. Each row of this table represents the disks attached to that interface channel which is index by the row number.

SPM-7-16

SP Guru/Release 11.5

Specialized Models User Guide

7Server Model User Guide

Figure 7-17 Interface Channels Table

Disk Configuration. A description of the disk drives connected to this interface.


Figure 7-18 Disk Configuration Table

Disk Name. A user-defined value that identifies the drive for configuring Local (direct attached) storage partitions, as well as for statistic and reporting purposes. Disk Type. A description of the drives hardware characteristics, as defined in the Server Configuration object. Cache Hit Percentage. A portion of all disk reads will be retrieved directly from the drives onboard cache without requiring access to the physical drive. Unlike cache hits at the interface level, hits at the drive level still require a data transfer operation. Storage Partition. Jobs (processes) do not read/write directly from/to disks, instead they read/write from/to storage partitions. For a every day example, your Windows machine may have one hard disk which is partitioned into two drives, C: and D:. When a file is to be saved you specify the drive (and the directory on that drive) in which you want save it. Further you may also have mapped drives which access data on a remote server. Similarly a Unix

SP Guru/Release 11.5

SPM-7-17

7Server Model User Guide

Specialized Models User Guide

systems normally has a number of partitions mounted, each partition could be a different disk or a different logical volume on the same disk, or may be NFS mounted. Storage partitions form one level of indirection, and facilitate use of different types to storage methods and devices. OPNET server models support three types of storage partitions: Local - storage partitions with direct attached storage Measured - storage partitions for which access times and throughputs are known but detailed disk/storage device information is not available Remote - storage partitions that access data from remote servers storage partitions
Figure 7-19 Storage Partitions Table

Name. A value used to uniquely identify this storage partition. Used in the job definitions and paging system definitions and for statistic reporting. Partition Type. The three types of storage partitions mentioned above. When the partition type is set to Local the Direct Attached attribute provides relevant information, when set to Measured attribute Measured Access is used and when set to Remote attribute Remote Access is used. Direct Attached. Specifies the information required for local storage partitions. The direct attached storage uses to the disks configured in the Local Storage Subsystem compound attribute. A local storage partition can span multiple disks and a disk can belong to multiple storage partitions. Further a local storage partition can have a RAID configuration.

SPM-7-18

SP Guru/Release 11.5

Specialized Models User Guide

7Server Model User Guide

Figure 7-20 Direct Attached Table

Disks. Allows you to specify the list of disks that belong to this storage partition. These disks need to be previously configured in the Local Storage Subsystem attribute. RAID Configuration. This attribute specifies the RAID parameters. Storage partitions support several common RAID standards, including: RAID 0 - Data Striping. Data is distributed over multiple drives in fixed size stripes. This allows data transfers to take place on one drive while a second or third drive positions itself to be ready for the next data transfer. This can greatly improve disk access performance. Unfortunately, the loss of a single drive in the RAID group leaves holes in the data, effectively rendering all information lost. At least two drives are required for data striping. RAID 1 - Data Mirroring. Designed primarily for improved fault tolerance , mirroring writes separate copies of the same data to two or more drives. The loss of one of the drives does not cause data loss. While there may be a slight improvement in read performance caused by accessing the first available drive, write performance is degraded because multiple physical writes are needed for a single logical write. Mirroring requires a minimum of two drives, with additional drives added in pairs. RAID 0+1 - Striping and Mirroring. To provide the performance of RAID 0 with the fault tolerance of RAID 1, the two are often used together. Striping is effectively done on two drives simultaneously, effecting a mirror. This is typically used on lower-end servers, as it makes inefficient use of available drive space. At least four drives are required, with additional drives added in pairs. RAID 5 - Parity. To use data storage resources more efficiently, RAID 5 uses a distributed parity scheme to maintain fault tolerance. While write operations require two physical writes similar to the mirroring scheme, RAID 5 combines data from several drives into a single parity block, which is then distributed across the drive groups. The result is that the loss of any one drive in the group does not result in the loss of all data. Distributing the parity evenly across all drives prevents any one drive

SP Guru/Release 11.5

SPM-7-19

7Server Model User Guide

Specialized Models User Guide

from becoming a bottleneck. Combining data from multiple drives into a single parity stripe means the storage overhead of the parity information decreases as the number of drives increases. At least three drives are required for RAID 5. RAID Stripe Size. Determines the size of a stripe when RAID 0 (striping), RAID 0+1 (striping and mirroring) and RAID 5 (distributed parity) is configured. Data transfers of size greater than the stripe size are broken up into multiple transfers of this or smaller size. RAID Implementation. RAID implementation can either be a hardware or a software implementation. Currently only hardware implementation is modeled. RAID Access Job. Will be used when software implementation modeling is supported. Currently this attribute value is not read. Measured Access. There are times when the exact storage partition being accessed by a job cannot be identified from the server performance data obtained from a data collector agent. However, what can be obtained is information about the access times and the throughput of the interface over which data was accessed. In such situations the measured storage partition could be used.
Figure 7-21 Measured Access Table

Access Time. A distribution describing the amount of time spent in accessing the data. This information can be obtained from the response times reported by the data collector. Transfer Rate. An integer that specifies the throughput of the interface over which data is being accessed. Remote Access. Operating systems and network protocol implementations have made possible seamless access to data on remote servers. Storage partitions of type Remote allow jobs to accessing remote data. This allows to model effect of remote storage access on job completion times, and also effects of the traffic load on the networks that carry this traffic.

SPM-7-20

SP Guru/Release 11.5

Specialized Models User Guide

7Server Model User Guide

Figure 7-22 Remote Access Table

Remote Server. The name of the server whoses storage partition is to be accessed. The active attribute handler lists all the Server Address attribute values of the servers whose Server Address attribute is not set to Auto Assigned. Remote Server Partition. The storage partition on the remote server specified above. The active attribute handler lists all the storage partitions defined on the remote server. Whenever the Remote Server value is changed, the value of this attribute is reset to None. Remote Access Method. The access method used to access remote partition. The access method defines the list of allowable transport protocols to access the remote partition. Remote Access Transport Protocol. The transport protocol to be used to access the remote partition. The server that initiates the remote partition access is called the Remote Storage Client and the server that processes the access request is called the Remote Storage Server. For the Remote Storage Client and the Remote Storage Server to communicate, this attribute value should match the Remote Storage Server Transport value specified in the Application: Transport Protocol Specification attribute of the Remote Storage Server.

SP Guru/Release 11.5

SPM-7-21

7Server Model User Guide

Specialized Models User Guide

Figure 7-23 Remote Storage Server Transport

Write Caching. Allows the user to enable or disable write caching. If write caching is enabled, a write operation submitted a job is started and the job is notified that the operation is complete, so that the job can continue with its next processing step. The write operation is carried out in the background. Note: The Storage Partition Response Time statistic in this case is added a value of zero and the Storage Partition Completion Time statistic is added the actual write completion time. Replication. The replication feature of the server models allows write operations to be replicated on to a remote servers storage partition. The primary storage partition can be of any type: Local, Measured or Remote. Three methods of replication are supported: Write-Replicate - write data to the primary partition, after the write operation is complete start the replication operation Replicate-Write - replicate first (that is write to the remote server first) and after the replication operation is complete start the write operation to the primary partition. Simultaneous - start the write operation to the primary partition and the replication operation at the same time. In each method the replication can either be Synchronous - wait for an acknowledgement from the remote server that the replication operation is complete. Asynchronous - do not wait for acknowledgement from the remote server, issue the replication operation and proceed. The primary storage partition may request the write to be replicated to multiple remote servers, each replication can have its own replication method.

SPM-7-22

SP Guru/Release 11.5

Specialized Models User Guide

7Server Model User Guide

Figure 7-24 Replication Table

Remote Server. Same as described above for the Remote Access compound attribute. Remote Partition. Same as described above for the Remote Access compound attribute. Remote Access Method. Same as described above for the Remote Access compound attribute. Remote Access Transport Protocol. Same as described above for the Remote Access compound attribute. Replication Method. Can be one of Write-Replicate, Replicate-Write and Simultaneous. See explanation above. Await Completion. Allows the user to control when the replication operation is deemed complete. Yes (Synchronous) waits for completion, No (Asynchronous) does not await completion. Job Definitions. Expanding on the job definitions provided in the Server Configuration object, this attribute lists the jobs that apply to this specific server, and how they are used.
Figure 7-25 Jobs: Definitions Attribute

SP Guru/Release 11.5

SPM-7-23

7Server Model User Guide

Specialized Models User Guide

Name. This is the name of a job defined in the Server Configuration object. You must first define the job in the Server Configuration object before you can assign it to a server. CPU Partition. The CPU Partition to which this job is to be bound. You must first define the CPU partition in the CPU Partitions attribute. Priority. The server supports 10 levels of priority0 (lowest) to 9 (highest). For convenience, there are three predefined priority levels: low, regular, and high. At the end of each time slice, the first available, highest-priority job is assigned to the CPU. If a higher priority job becomes active in a midst of a timeslice and a preemptive scheduling algorithm is employed, the lowest priority job holding a CPU is preempted. Storage Read/Write Access Distribution. While the general I/O characteristics, such as frequency of occurrence and average size of a process, are determined by its measured properties (and therefore defined in the Server Configuration object), the distribution of these I/O operations over the available storage partitions is dependent on the servers storage partition configuration.
Figure 7-26 Storage Read Access Distribution

Storage Partition Name. The name of the drive to receive the I/O operation. Access Weight. Each storage partition is assigned an access weight that determines which storage partition receives an I/O operation. Two storage partitions with equal weights receive an equal number of operations when averaged over a simulation. Job Interarrival Time. When a job is initiated as a result of a network operation, this parameter is normally set to None. Alternatively, you can specify an interarrival time that causes the job to be executed at a specified rate. This is normally the case for stand-alone applications for which no external interactions are necessary. A third alternative is Once

SPM-7-24

SP Guru/Release 11.5

Specialized Models User Guide

7Server Model User Guide

Only. This setting is intended for jobs that consume memory resources only, and allow them to be initiated at the start of the simulation. Such jobs should have their memory persistence set to Job Completion on the Server Configuration object. Calibration Delay. Used for model calibration, this attribute adjusts the response time of applications to match measured response times. It uses no system resources, such as CPU or disk, and corresponds to unmeasurable quantities like interprocess communications delays. Instance Limits. Many jobs have restrictions on the number of instances that can be active at a time. For example, your company may have purchased a software with a fixed number of licenses, say 6. Hence you can have a maximum of 6 instances active at any given time. This attribute allows you to configure just that.
Figure 7-27 Instance Limits

Instance Limit (Instances). The maximum number of instances that can be active at any point in time. Instance Limit Policy. Determines how a job is handled when the instance limit is reached. When set to Reject, the job is discarded and never executed. When set to Queue Requests the job is queued until an instance completes and the interprocess time expires. Job Interprocess Time. Under certain circumstances, it may be necessary to specify a minimum time between the end of one Job instance and the start of the next. This affects only jobs with instance limits in place and the Queue Requests instance limit policy is in use. Job remote_access: In order to support remote access to storage partitions, the Remote Storage Server needs to have a job that can be created dynamically to perform the IO operation. Job remote_access is a reserved job that is added by default to the job table of every server. This job is created and processed only on receiving a request from a remote client to access a storage partition (including request for a replication operation). If no such request is received, no instances of this job are created as evidenced by the all job specific statistics for job remote_access being grayed out and in case of some statistics having a zero value for the duration of the simulation.

SP Guru/Release 11.5

SPM-7-25

7Server Model User Guide

Specialized Models User Guide

Available Statistics
To analyze Server performance, you can collect several statistics during simulation execution. The statistics are collected on a per-node basis, and are reported under three different statistic groups: Server Jobs Remote Storage Client Remote Storage Server Statistic group - Server Jobs: Node-based statistics provide grouped information for all Server processes running in a node. These are useful to evaluate hardware and software bottlenecks within a server or within a network. Many statistics are available on a job-specific basis as well as on a server-wide basis. The statistics in this group can be further classified as pertaining to the following: CPU statistics - provides information of Total CPU utilization, CPU Partition utilization, and individual CPU utilization. Further is provides the breakup of about the amount of time the job spent in the CPU subsystem. The CPU completion time should be the sum of the CPU service time and the CPU wait time. Also reported is the job queue length for each CPU Partition and number of job instances of each type in the queue. Higher job queue sizes lead to higher CPU wait times increasing the CPU completion time of jobs. Storage Partition statistics - provides information about the amount of time the job spent for completing their IO requirements and provides a breakup of these delays. Also reported are the number of operations (reads/writes) received by each storage partition.

SPM-7-26

SP Guru/Release 11.5

Specialized Models User Guide

7Server Model User Guide

Note: The storage partition statistics include Storage Partition Completion Time and Storage Partition Response Time. The response time is the amount of time the job had to wait for getting an IO completion indication, and the completion time is the wall clock time for the IO to actually complete. The response time could be less than the completion time, for example in case of cached writes. Disk statistics - provides information about the number of operations (reads/writes) received by disks, the disk queue lengths, and the resulting disk utilizations. Disk Interface and Interface Channel statistics - provide information about the disk interface and interface channel queue lengths, and the resulting utilizations. Replication statistics - provides information about the number of replication operations started, the number that completed successfully and the number that were aborted. System statistics - provide information about the number of active jobs, their total completion time (which should be the sum of CPU completion time and Storage Partition response (or completion) time), the number of jobs that were aborted, total number of page faults (both soft and hard), the memory usage, and so on.

SP Guru/Release 11.5

SPM-7-27

7Server Model User Guide

Specialized Models User Guide

Figure 7-28 Available Statistics (Server Jobs)

SPM-7-28

SP Guru/Release 11.5

Specialized Models User Guide

7Server Model User Guide

Statistic group - Remote Storage Client: Provide information about the number of remote access requests sent, how many of them were reads and how many were writes. The number of operations that completed successfully and the number that were aborted. The most important statistics that this group provides is the break-up of delays. The response time as observed by the client is the sum of the connection setup time, the network delay of sending the request from the client to the server, the disk IO completion time and the network delay of sending the response back from the server to the client. Statistic group - Remote Storage Server: Provide information about the number of remote access requests received, how many of them were reads and how many were writes. The number of requests that were processed successfully.
Figure 7-29 Remote Storage Server Statistics

When viewing results, the per-job statistics are annotated to indicate the job they apply to, similarly the statistics that are related to the storage partitions, disk, disk interface, CPU partitions are annotated by the storage partition name, disk name, disk interface name, CPU partition name respectively. In case of statistics related to the disk interface channels, the statistics are annotated by the disk interface name and the interface channel index.
SP Guru/Release 11.5 SPM-7-29

7Server Model User Guide

Specialized Models User Guide

Figure 7-30 Statistics with Annotations

SPM-7-30

SP Guru/Release 11.5

Specialized Models User Guide

7Server Model User Guide

Example Project
An example project (called Server_Application_Example) is shipped with the OPNET specialized model library. It covers several common simulation problems, including modeling the effect of a large background job on the response time of a mission critical job, and modeling the limits of a simple server configuration. The following diagrams are from a simple network that has a few clients connected to a server that grants licenses for an engineering application. A large application is run on the server to determine how the license server application response time is affected. The client-server configuration looks like:
Figure 7-31 Server Models Example Project

SP Guru/Release 11.5

SPM-7-31

7Server Model User Guide

Specialized Models User Guide

Response times for three different scenarios are shown here:


Figure 7-32 Effects on Server Response Time

The simulation shows that running a large application on the server can have a major impact on the response time of the license server application, our mission critical application. The simple step of reducing the large applications priority can decrease the response time to a reasonable range with minimal impact on overall server throughput.

SPM-7-32

SP Guru/Release 11.5

Specialized Models User Guide

7Server Model User Guide

Frequently Asked Questions


Question: I configured the network with HTTP traffic, but no statistics are reported for my server. Whats wrong? Answer: The advanced server models work only with custom applications and ACE. Other OPNET standard applications can be integrated with the advanced server models by using backend custom applications. Question: I reconfigured the application to use custom applications, but I still get no results. What should I check? Answer: First, ensure that your Task configuration includes specific jobs as part of the phases (Task Specification > Manual Configuration > Source > Dest Traffic > Server Job Name, or Task Specification > Manual Configuration > Dest > Source Traffic > Server Job Name). Without this information, the server does not know which job should be executed. Also, make sure that the servers Server: Modeling Mode is set to Detailed Server. And that job has been configured to run on that server. Question: Im using a server from one of the server object palettes, but the server looks nothing like mine. Why not? Answer: The server palettes contain a typical configuration, as defined by the manufacturer. Most servers are shipped with additional options, such as disk drives, RAID interfaces, or other features which are not part of the standard configuration. Generally, you will need to set the disk configuration when creating your server. If you have many similar servers, consider creating your own palette entries consisting of OPNETs standard entries modified to match your disk configuration. Question: I changed the server type, but the disk configuration has not changed. Why not? Answer: As mentioned above, standard servers do not always have standard disk configurations. Therefore, you should always make sure that the configuration matches your actual server. Question: I dont really need detailed models for all my servers, and I dont have performance information for them all anyway. Can I use some servers in Simple CPU mode, and some in Detailed Server mode? If so, how will the statistics be reported?

SP Guru/Release 11.5

SPM-7-33

7Server Model User Guide

Specialized Models User Guide

Answer: Yes, the two types of servers may be mixed in the same network, just not on the same server. For example, you cannot model an FTP application (Simple CPU mode) and a Custom Application (Detailed Server mode) on the same machine. While the simulation will execute without errors, the statistics produced will not be accurate for either application type. On the other hand, having a Simple CPU machine as the client, and a Detailed Server as the application server is a valid configuration.

SPM-7-34

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

UMTS Model User Guide


This document provides an overview of the features of the UMTS model suite, shipped as part of OPNETs specialized model library. The manual assumes that you are familiar with the UMTS protocol and that you are comfortable using the OPNET software. 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-8-6.

General Model Description


Universal Mobile Telecommunications System (UMTS) is a Third Generation (3G) wireless protocol that is part of the International Telecommunications Unions 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 2Mbps. OPNETs 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 OPNETs specialized model library. The UMTS model of the packet wireless network is based on 3 Generation Partnership Project (3GPP) Release 1999 standards. The network architecture of this release is divided into the radio access network (RAN) and the core network as shown in Figure 8-1. The UMTS module models the UMTS RAN and the UMTS functionality of the core network (see highlighted elements in Figure 8-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-CDMAs 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.
rd

SP Guru/Release 11.5

SPM-8-1

8UMTS Model User Guide

Specialized Models User Guide

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) include all GPRS functionality needed to support GSM and UMTS packet services. The SGSN monitors user 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 models 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) collects charging records from the SGSN 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 8-1 Overview of Packet Domain Architecture
Standards Representation

OPNET Representation

UTRAN

SPM-8-2

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

Model Features and Limitations


As this model is still under development, there are several features that are not yet implemented, but are scheduled for inclusion in upcoming releases. The features and limitations described below are current as of the 11.0.A release.

Model Features
The following table summarizes the main UMTS features included in the implementation of the UMTS model.
Table 8-1 Model Features (Part 1 of 3)
Feature GPRS attach Description The GPRS attach procedure informs the SGSN 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. The GPRS Tunneling Protocol (GTP) protocol, which is used in the 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. 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. 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. Reference GPRS Attach on page SPM-8-36

GPT

CN Architecture on page SPM-8-26

PDP context activation

PDP Context Activation and RAB Assignment (MS-Connected State) on page SPM-8-37

RAB Setup, Release, and Preemption

RAB Assignment with Prior PDP Activation (MS-Connected State) on page SPM-8-39

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

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. Service Request RLC Modes: AM, UM, TrM See above (RAB setup/release). 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. Each traffic class is assigned a different priority and the MAC can handle data flows of different priority levels. UE Process Model Architecture on page SPM-8-15 UE Node Model Architecture on page SPM-8-13

Priority handling of data flows based on traffic class at MAC

SP Guru/Release 11.5

SPM-8-3

8UMTS Model User Guide

Specialized Models User Guide

Table 8-1 Model Features (Part 2 of 3)


Feature Traffic classes Description 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. 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. TCP (UDP) and IP layers are implemented at the UE. The IP layer is also implemented at CN nodes. Reference

One QoS profile per traffic class of a UE

Support of TCP/IP stack

UE Node Model Architecture on page SPM-8-13

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). Two admission control algorithms are modeled: a default algorithm and a throughput-based algorithm. Dedicated channels (DCH) are supported both in uplink and downlink directions, which are used by UEs in CELL_DCH state. DCHs are configurable on a per-QoS basis for each RNC. 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. 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.

Admission Control

RNC Process Model on page SPM-8-24

DCH

DSCH

RNC Process Model on page SPM-8-24

FACH (Forward Access channel) RACH (Random Access Channel)

UE Process Model Architecture on page SPM-8-15

Power control

Outer loop power control is supported. For outer loop power control, the model increases the receivers 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 Toskalasee reference documents.)

UE mobility

Movement of a UE within a cell is modeled.

SPM-8-4

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

Table 8-1 Model Features (Part 3 of 3)


Feature Intra-RNC hard and soft handovers Description 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 3GPPs release 1999 standards. UMTS also supports soft handover events 1A, 1B, and 1c (active cell addition, removal, and replacement procedures, respectively. Softer handoversamong the cells/sectors of a Node-Bare also modeled. Sectorization Cells can be divided into several sectors. The model suite includes two Node-B models, one for cells with a single sector and another for cells with multiple sectors. The model suite includes a cell creator utility that allows you to add a visual depiction of the hexagonal cell sectors of a UMTS network. Reference Signal Flows for Hard Handover on page SPM-8-42 and Signal Flows for Soft Handover on page SPM-8-43

Node-B Architecture on page SPM-8-21

Cell creator

Cell Creator Utility on page SPM-8-8

End of Table 8-1

Model Limitations
The following UMTS protocol features are not explicitly modeled. 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. PS signaling connection establishment. Since PS (packet-switched) signaling connection affects only set up time delay (to establish and re-establish the PS signaling connection), it is not modeled. The model assumes that a PS signaling connection is already established when a user powers-on and that this connection is maintained for the entire simulation. GMM-Idle mode. Only the GMM-Connected mode is modeled. 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. No negotiation of the requested QoS. The SGSN model either grants the UEs requested QoS in its entirety or rejects the request. One logical channel per transport channel. The model does not support multiplexing of dedicated channels on the MAC. The MAC header length varies depending on logical channel mapping into the transport channel. DPDCH, PCPCH. The model sends data and signaling traffic on dedicated channels only. The physical dedicated data channel (DPDCH) and physical common packet channel (PCPCH) are not modeled.
SP Guru/Release 11.5 SPM-8-5

8UMTS Model User Guide

Specialized Models User Guide

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 (distance-wise). No mobility is modeled prior to attachment and UEs begin monitoring their location after attachment. At least one UE per Node-B. The model requires that each Node-B has at least one UE attached to it at simulation start time for complete initialization. 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). Signaling over FACH/RACH. All signaling travels over a dedicated channel (DCH) rather than common channels. Only datanot signallingtravels over the FACH/RACH channels.

Reference Documents
This manual documents OPNETs 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 signalling layer 3; General aspects (Release 1999). 3G TS 24.008: Mobile radio interface layer 3 specification; Core Network Protocols Stage 3 (Release 1999). 3GPP TS 25.101: Technical Specification Group Radio Access Networks; UE Radio Transmission and Reception (FDD) (Release 1999). 3G TS 25.211: Physical channels and mapping of transport channels onto physical channels (FDD) (Release 1999).

SPM-8-6

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

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 (Release 1999). 3G TS 25.303: Interlayer Procedures in Connected Mode (Release 1999). 3G TS 25.321: Medium Access Control (MAC) Protocol Specification (Release 1999). 3G TS 25.322: RLC Protocol Specification (Release 1999). 3G TS 25.331: RRC Protocol Specification (Release 1999). 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 Signalling (Release 1999). 3G TS 25.433: UTRAN Iub Interface NBAP Signalling (Release 1999).

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 8-2 UMTS Object Palette

SP Guru/Release 11.5

SPM-8-7

8UMTS Model User Guide

Specialized Models User Guide

Table 8-2 Node Models


Node model UE umts_station Description 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. General workstation node (with full OSI stack) that includes UE and client/server application functionality. General server node (with full OSI stack) that includes UE and client/server application functionality. Node-B portion of the UTRAN. Node-B portion of the UTRAN. This node_b model has 3 directional antennas, which handle connections with the UEs in their sector. RNC portion of the UTRAN. Simple CN nodehas core network functionality, but does no IP routing. Routes packets to and from umts_station nodes, exclusively. Gateway CN nodegeneral 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. GGSN portion of the CN

umts_wkstn

umts_server

UTRAN

umts_node_b umts_node_b_3_sector

umts_rnc CN umts_sgsn

umts_ethernet_slip8_gtwy umts_ethernet_slip8_large_gtwy

umts_ggsn_slip8 umts_ggsn_atm8_ethernet8_slip8 umts_ggsn_ethernet2_slip8 umts_sgsn_ethernet_slip umts_sgsn_atm_ethernet_slip End of Table 8-2

SGSN portion of the CN

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 an OPNET map in the Project Editor. The Cell Creator utility takes an existing OPNET map and superimposes on it a grid structure with the parameters you specify. It then creates a new OPNET 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

SPM-8-8

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

diagonally 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 doesnt matter, whats important is that the corners you specify are diagonally opposite each other. The Cell Creator utilitys input parameters are listed below.
Table 8-3 Cell Creator Input Parameters
Input Parameter longitude 1 Description Longitude (in degrees) of the first corner of the rectangular area of cells. Latitude (in degrees) of the first corner of the rectangular area of cells. Longitude (in degrees) of the second corner of the rectangular area of cells. This corner should be diagonally opposite the first. Latitude (in degrees) of the second corner of the rectangular area of cells. This corner should be diagonally opposite the first. 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. Unit of the cell radius. Name of the OPNET map on which the cell grid is drawn. Include the filename of the map only, do not include the file extension. Name for the modified map.

latitude 1

longitude 2

latitude 2

radius

miles|kilometers input map name

output map name End of Table 8-3

Procedure 8-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: <opnet_dir>/<rel_dir>/sys/pc_intel_win32/bin Solaris: <opnet_dir>/<rel_dir>/sys/unix 2 Configure the LD_LIBRARY_PATH environment attribute to include the full path to the directory of OPNET kernel libraries (Solaris only). Windows: No special configuration is required.
SP Guru/Release 11.5 SPM-8-9

8UMTS Model User Guide

Specialized Models User Guide

Solaris: At the command prompt, enter the following command: setenv LD_LIBRARY_PATH <reldir>/sys/ sun_sparc_solaris/lib:$LD_LIBRARY_PATH 3 Change to <reldir>/models/std/umts, the umts directory. 4 Run cell_creator in the OPNET console (Windows) or at the command prompt (Solaris). cell_creator -input <longitude 1> <latitude 1> <longitude 2> <latitude 2> <radius> [miles | kilometers] <input map name> <output map name> End of Procedure 8-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 SGSN node. 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

SPM-8-10

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

The following diagrams illustrate the supported types of UMTS network configurations:
Figure 8-3 Simple UMTS Network Using Application Traffic

Figure 8-4 Simple UMTS Network Using Raw Traffic Generation

SP Guru/Release 11.5

SPM-8-11

8UMTS Model User Guide

Specialized Models User Guide

Model Architecture
The GPRS network architecture is shown in Figure 8-5. This section describes the nodes shown in Figure 8-5, including their process and node models.
Figure 8-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 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. This PDP context activation message includes the QoS requested. The model assumes that the SGSN, 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 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 is granted. If the request can be granted, the RNC sends a Radio Bearer Setup request to the UE.

SPM-8-12

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

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 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. 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 8-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 8-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 dedicated signaling channel per user, and up to four data channels. The number
SP Guru/Release 11.5 SPM-8-13

8UMTS Model User Guide

Specialized Models User Guide

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 8-6 Simple and Full-Protocol Stack UE Node Models

umts_station: contains only traffic source/sink and UMTS layer

umts_wkstn and umts_server: contains full stack

The queue structure at the GMM and RLC/MAC layers is shown in Figure 8-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 packets QoS class. Otherwise, the packet is enqueued at the GMM layer in the queue corresponding to its QoS profile. The RLC/MAC layer uses queues to transmit packets coming from higher layers, to

SPM-8-14

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

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 8-7 Queue Structure for GMM and RLC/MAC Layer at the UE Node
UEGMM/SM UERLC/MAC

Data (QoS 0) Data (QoS 1) Data (QoS 2)

Signalling Data (QoS 0) Data (QoS 1) Data (QoS 2) Transmission buffers

Data (QoS 3)

Data (QoS 3)

Signalling Data (QoS 0) Data (QoS 1) Data (QoS 2) Data (QoS 3) Retransmission buffers

Signalling Data (QoS 0) Data (QoS 1) Data (QoS 2) Data (QoS 3) Reception/Reassembly buffers

UE Process Model Architecture

The process models for the application layer of the UE station node model are shown in Figure 8-8 (umts_client_mgr) and Figure 8-9 (umts_client_child). When the umts_client_mgr process model is invokedeither 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 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
SP Guru/Release 11.5 SPM-8-15

8UMTS Model User Guide

Specialized Models User Guide

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 8-8 umts_client_mgrApplication Manager Process for the UE

Station Node

Figure 8-9 umts_client_childApplication Child Process for the UE

Station Node

Figure 8-10 shows the process model for the UEs 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. If the GMM 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
SPM-8-16 SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

sending packets to its destination. The radio bearer release 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 8-10 umts_gmmGMM Layer Process Model on the UE

Figure 8-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

SP Guru/Release 11.5

SPM-8-17

8UMTS Model User Guide

Specialized Models User Guide

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 8-11 umts_rlc_mac Process for the UEs 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.

SPM-8-18

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

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 UEthe 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 RNCthe 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 situationa 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.

SP Guru/Release 11.5

SPM-8-19

8UMTS Model User Guide

Specialized Models User Guide

Figure 8-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 8-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 8-12 RLC AM Retransmission
UE (rx) RNC (tx)

VR(R)=0, VR(H)=0, VR(MR)=8 VR(R)=1, VR(H)=1, VR(MR)=9 VR(R)=2, VR(H)=2, VR(MR)=10

seq num = 0 seq num = 1 seq num = 2 seq num = 3 seq num = 4

VT(S)=0, VT(A)=0, VT(MS)=8 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

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

status report (2,3) seq num = 5 seq num = 6 seq num = 7 seq num = 8

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

status report (2,3,5,6,7) seq num = 2 seq num = 3 seq num = 5 seq num = 6 seq num = 7 seq num = 9 ...

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

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

SPM-8-20

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

Figure 8-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 8-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. The model suite includes two Node-B models: a single-sector Node-B and a three-sector Node-B. In both cases, a one-to-one relationship must exist between the cells and Node-Bs in a UMTS network. That is, each Node-B represents and manages exactly one cell. However, the three-sector Node-B can manage multiple sectors in a single cell. 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 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 via

SP Guru/Release 11.5

SPM-8-21

8UMTS Model User Guide

Specialized Models User Guide

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 8-14 Node-B Node Models
Single-sector Node-B

Three-sector Node-B

SPM-8-22

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

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 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.
Figure 8-15 umts_node_b Process Model

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 a RABs for UEs requesting service over various QoS classes Manages the handovers of UEs between its Node-B due to UEs movements between the cells Buffers packets destined for UEs per QoS class, Communicates with the SGSN allowing the SGSN to send and receive data to and from the UEs it services.

SP Guru/Release 11.5

SPM-8-23

8UMTS Model User Guide

Specialized Models User Guide

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 don in case of inactivity.
RNC Node Model

The RNC Node model consists of a single processor module that runs a process that performs the functionality of the RNC. It has nine ATM stacks attached to it, one of which connects to the SGSN servicing the RNC. The other eight will connect to Node-B ATM stacks. The RNC process model 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 stacks to the node structure.
Figure 8-16 RNC Node Model

ATM stack

ATM stack ATM stack ATM stack ATM stack

ATM stack ATM stack ATM stack ATM stack

RNC Process Model

The RNC 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

SPM-8-24

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

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 8-17.
Figure 8-17 Queue Allocation Structure at the RNC
Tx Buffers Rx Retx Seg Reass

Connection 0

Connection 1

Connection 2

...

Connection M

Tx

Buffers Rx Retx Seg

Reass

Connection array for FACH/RACH FACH/RACH DSCH DCH DCH DCH DCH

...

Queue array for Node-B 1

Node-B 0

Node-B 1

...

Node-B N

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 UEs newly established RABs. If the newly created RAB runs over common or shared channels, a new connection slot is assigned.
Figure 8-18 Sample Queue Allocation for an RNC
Tx Retx Seg Reass [DSCH | DCH(UE0 sig) | DCH(UE1 sig) | DCH (UE0 QoS0) | DCH (UE1 QoS0) ] [DSCH | DCH(UE0 sig) | DCH(UE1 sig) | DCH (UE0 QoS0) | DCH (UE1 QoS0) ] [DSCH | DCH(UE0 sig) | DCH(UE1 sig) | DCH (UE0 QoS0) | DCH (UE1 QoS0) ] [DSCH | DCH(UE0 sig) | DCH(UE1 sig) | DCH (UE0 QoS0) | DCH (UE1 QoS0) ]

SP Guru/Release 11.5

SPM-8-25

8UMTS Model User Guide

Specialized Models User Guide

Figure 8-19 umts_rnc Process Model

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 SGSNs UE station nodes See CN Node Models on page SPM-8-27. 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 on page SPM-8-28 and GGSN Node Models on page SPM-8-27.

SPM-8-26

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

CN Node Models

The simple CN node model (Figure 8-20) includes the SGSN module and variable ATM stacks for communications with the RNCs. You can configure the nodess 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 8-20 Simple CN Node Model: umts_sgsn ATM stack ATM stack ATM stack ATM stack ATM stack ATM stack

ATM stack ATM stack

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 8-21 Gateway CN Node Mode
l

IP stack

ATM stack ATM stack ATM stack

ATM stack ATM stack ATM stack

ATM stack ATM stack

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.

SP Guru/Release 11.5

SPM-8-27

8UMTS Model User Guide

Specialized Models User Guide

SGSN Node Models

The model suite includes two SGSN node models, umts_sgsn_ethernet_slip and umts_sgsn_atm_ethernet_slip. The SGSN node 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 the terminating UE. The packets are queued by QoS class as shown in Figure 8-22. If the PDP context is already activated for the packets QoS class and if a channel is already set up, the packet is transparently forward to the RNC. Figure 8-22 Queue Structure in the SGSN Module
Data QoS0 (UE0) Data QoS1 (UE0) Data QoS2 (UE0) Data QoS3 (UE0) Data QoS0 (UE1) Data QoS1 (UE1) UE 1 Data QoS2 (UE1) Data QoS3 (UE1) UE 0

CN Process Model

The process model that resides in the SGSN module of the CN node model is shown in Figure 8-23. 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 modification and deactivation states Security state Tunneling between the RNC and the CN

SPM-8-28

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

Figure 8-23 SGSN Process Model

UMTS Timing
The following timing delays are modeled: Encoder delay Processing delay Buffering delay Propagation delay (configurable) IP delay (configurable) Figure 8-24 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.
SP Guru/Release 11.5 SPM-8-29

8UMTS Model User Guide

Specialized Models User Guide

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 8-24 Delay in RAN and CN Network

Radio-Air Interface
OPNETs 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.

Vehicular Outdoor L pMax


SPM-8-30

40(1 4 * 10

hb ) log10 R 18 log10 hb

21 log10 freq 80
SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

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 L pMax

40 log10 R 30 log10 freq 49

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
L pMax 30 log
10

( R * 1000 )

18 . 3 n

n 2 n 1

0 . 46

37

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) is modified to include thermal noise and noise figure of the mobile and base station receiver.

Interference Noise
The interference noise pipeline stage (dra_inoise.ps.c) has not been modified in Release 1 but will be modified in Release 2 to include same-cell and other-cell interference calculation.

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. Release 1 supports convolutional codes rate half and rate third in AWGN and in multipath conditions with three equal paths. Release 1 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.

SP Guru/Release 11.5

SPM-8-31

8UMTS Model User Guide

Specialized Models User Guide

Air Interface Modeling


Error Probability Bounds for Convolutional Coding

A convolutional code has a transfer function

T ( D, N ) =

d =d f

a D
d

N fd

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

d f 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 d. 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

fd

Pe

d =d f

ad Pe (d ) =
Q( x ) =

d =d f

a Q
d

2dEs N0

where

1 2

e
x

t 2 2

dt
.

If r is the code rate, and

E s = rEb

, where

Es

is the energy per symbol (coded bit)

is the energy per data bit. 0 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

Eb

N 2

SPM-8-32

SP Guru/Release 11.5

Specialized Models User Guide


2dE s PB B a d Q N d =d f 0

8UMTS Model User Guide

The union bound on the bit error probability is

Pb

d =d f

ad f d Pe (d ) =
d = ad f d .

d =d f

Q
d

2dEs N0

where

The coefficients

{ad } and { f d } depend on the specific code.


df
, the better the code performance in

Clearly the larger the free distance general. For the rate-1/2 code,

d f = 12

and for the rate-1/3 code,

d f = 18

SP Guru/Release 11.5

SPM-8-33

8UMTS Model User Guide

Specialized Models User Guide

The coefficients {ad } and { d } are shown for the two codes in the tables below, and Figure 7 shows the union bounds on block error rate vs. Eb/N0 for a block length of B = 100 bits, for the two rates.
Table 8-4 Transfer Function Coefficients for Rate-1/2 Convolutional Code

d
12 14 16 18 20 22 24 26 28
End of Table 8-4

ad
11 50 286 1630 9639 55,152 320,782 1,859,184 10,777,264

d
33 281 2179 15,035 105,166 692,330 4,580,007 29,692,894 190,453,145

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

d
18 20 22 24 26 28 30 32 34
End of Table 8-5

ad
5 7 36 85 204 636 1927 5416 15,769

d
11 32 195 564 1473 5129 17,434 54,092 171,117

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

log PB b0 + b1 (Eb N 0 )dB


where the coefficients:
SPM-8-34

b0 and b1 are as shown on the graph below.


SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

Since the bound on PB is proportional to the block length B,

PB = B P100 100
and

log PB = log P100 + log B 2


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

log PB = log B + b0 2 + b1 (Eb N 0 )dB


For a specific target block error rate, therefore, the required

Eb N 0
is closely approximated as:

(E b

N 0 )dB

log B + b0 2 log PB b1

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

1 0 -1
c o n v o lu tio n a l c o d in g , K = 9 c o h e re n t d e te c tio n s o ft-d e c is io n V ite rb i d e c o d in g n o s ig n a l v a ria tio n d u rin g a b lo c k u n io n b o u n d b lo c k le n g th = 1 0 0 b its

10 Block Error Probability

-2

1 0 -3
r e g r e s s io n c o e ffic ie n ts

ra te 1 /2 ra te 1 /3

1 0 -4

ra te 1 /2 b 0 = 2 .3 5 b1 = 1 .7 1

1 0 -5

ra te 1 /3 b 0 = 1 .3 3 b1 = 1 .5 4

1 0 -6

3 E b/N 0, d B

SP Guru/Release 11.5

SPM-8-35

8UMTS Model User Guide

Specialized Models User Guide

For the specific cases of interest here, this becomes:

(Eb (Eb

N 0 )dB

log B + 0.35 log PB 1.71 rate 1/2 log B 0.67 log PB 1.54 rate 1/3

N 0 )dB

Signal Flows
GPRS Attach

For completeness, the entire GPRS Attach procedure without prior CS (Circuit Switched) traffic is shown in Figure 8-26. 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 of a users location and to set up a PS signaling connection. Once a PS signaling connection is established, the UE and SGSN 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 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. 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 8-26 GPRS Attach with no Prior CS Traffic

SPM-8-36

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

Here is how OPNET 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 8-27 and Figure 8-28 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 8-27 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

SP Guru/Release 11.5

SPM-8-37

8UMTS Model User Guide

Specialized Models User Guide

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.

SPM-8-38

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

Figure 8-28 PDP Context Activation Procedure Initiated by the Network (Connected State)

8) Since the SGSN and GGSN are modeled as a singe 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

SP Guru/Release 11.5

SPM-8-39

8UMTS Model User Guide

Specialized Models User Guide

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 8-29 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 start T3317 when sending the Service Request message. The timer T3317 has not been modeled yet in the simulation model because the Service Accept message was missing from the standard 23.060 v3.4.0. 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 8-30 RAB Assignment Procedure Initiated by the Network (Connected State)

SPM-8-40

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

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.
RNC to Node-B Signal Flow

The signalling messages for adding and deleting a radio link are shown in the following diagram:
Figure 8-31 Signal Flows for Adding and Deleting a Radio Link
Node-B
ink adio L BAP R est N equ Add R

RNC

Node-B
Link Radio NBAP equest R Delete

RNC

NBAP Add R Radio Lin k espo nse

NBA P Delet Radio Lin e Re k spon se

Adding a Radio Link

Deleting a Radio Link

SP Guru/Release 11.5

SPM-8-41

8UMTS Model User Guide

Specialized Models User Guide

Signal Flows for Hard Handover

Figure 8-32 illustrates the signalling messages used in hard handover.


Figure 8-32 Signaling Messages for Hard Handover
UE GMM RLC/MAC Layer1 Mgr Uu Interface Node-B Iub Interface RNC

ort ment rep measure


measurement report

equest L Add R NBAP R


NBAP RL Add Respo ns

admission to the new cell

ration annel Reconfigu RRC Physical Ch

RRC Physical Channel

Reconfiguration Comp lete


eques t elete R P RL D NBA

CRLC Configuration Request

NBAP

RL D

elete

Resp on

se

Resource released from old cell for new admissions

SPM-8-42

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

Signal Flows for Soft Handover

Figure 8-33 illustrates the signalling messages used in soft handover.


Figure 8-33 Signaling Messages for Soft Handover: In Case of Event 1C (Cell Replacement)
UE GMM RLC/MAC Layer1 Mgr Uu Interface Node-B Iub Interface RNC

ort ment rep measure


measurement report

L NBAP R

uest(s) Add Req

admission to the new cell(s)

NBAP RL Add

Respon s

e( s )

Update RRC Active Set

RRC Active Set Updat

e Complete
equest( elete R P RL D NBA s)

CRLC Configuration Request

NBAP

RL D elete Resp onse

(s)

Resource released from old cell(s) for new admissions

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

SP Guru/Release 11.5

SPM-8-43

8UMTS Model User Guide

Specialized Models User Guide

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 8-6 Packet Formats (Part 1 of 2)
Packet format umts_L1_pdu.pk.m umts_client_message.pk.m umts_clock.pk.m Description Physical layer packet. Station UE data packet. Clock packet used to synchronize UEs with the RNC that services it. Packet carrying channel configuration data from the UE's GMM to the UE's RLC/MAC. GPRS attach accept packet. GPRS attach complete packet. GPRS attach request packet. Service accept packet. Service reject packet. Service request packet. PDP activation accept packet. PDP activation reject packet. PDP activation request packet (UE to SGSN). Request for PDP activation request packet (SGSN to UE). MAC layer packet. NBAP radio link addition request packet. NBAP radio link addition response packet. NBAP radio link addition request packet. NBAP radio link deletion response packet. PDCP PDU packet. RANAP RAB assignment (release) packet. RANAP RAB assignment (setup) packet.

umts_crlc_config_req.pk.m

umts_gmm_attach_accept.pk.m umts_gmm_attach_comp.pk.m umts_gmm_attach_req.pk.m umts_gmm_service_accept.pk.m umts_gmm_service_reject.pk.m umts_gmm_service_req.pk.m umts_gsm_activate_pdp_accept.pk.m umts_gsm_activate_pdp_reject.pk.m umts_gsm_activate_pdp_req.pk.m

umts_gsm_req_pdp_activation.pk.m

umts_mac_pdu.pk.m umts_nbap_rl_add_req.pk.m umts_nbap_rl_add_resp.pk.m umts_nbap_rl_del_req.pk.m umts_nbap_rl_del_resp.pk.m umts_pdcp_pdu.pk.m umts_ranap_rab_assgn_req_release.pk.m umts_ranap_rab_assgn_req_setup.pk.m

SPM-8-44

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

Table 8-6 Packet Formats (Part 2 of 2)


Packet format umts_ranap_rab_assgn_resp.pk.m umts_ranap_rab_release_req.pk.m Description RANAP RAB response packet. RANAP RAB release request packet (UTRAN to SGSN). Acknowledged mode PDU packet (RLC layer). Status PDU for acknowledged mode transmissions packet (RLC layer). Unacknowledged mode PDU packet (RLC layer). Radio resource control connection setup packet. Measurement report packet (UE to UTRAN) packet. Physical channel reconfiguration request packet. Physical channel reconfiguration complete packet. RB procedure complete packet. RB release packet. RB setup packet.

umts_rlc_am_pdu.pk.m

umts_rlc_status_pdu.pk.m

umts_rlc_um_pdu.pk.m

umts_rrc_conn_setup.pk.m

umts_rrc_measurement_report.pk.m

umts_rrc_phy_chnl_reconfig.pk.m

umts_rrc_phy_chnl_reconfig_comp.pk.m

umts_rrc_rb_comp.pk.m umts_rrc_rb_release.pk.m umts_rrc_rb_setup.pk.m End of Table 8-6

ICI Formats
The following table describes the interface control information (ICI) formats used in the UMTS model suite.
Table 8-7 ICI Formats
ICI umts_control_pkt_ici umts_data_pkt_ici umts_rrc_conn_setup Description Contains modeling information for signaling packets. Contains modeling information for data packets. Contains modeling information used when establishing RRC connections.

End of Table 8-7

SP Guru/Release 11.5

SPM-8-45

8UMTS Model User Guide

Specialized Models User Guide

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 OPNET simulation debugger (ODB). The following table describes the various label traces you can use in ODB to view the behavior of the UMTS models.
Table 8-8 UMTS Traces
Use this trace label... umts_atm umts_attach umts_gmm umts_layer1_mgr umts_node_b umts_rab umts_rlc_mac umts_sgsn umts_utran umts End of Table 8-8 To print information about... umts_atm_iface process model GPRS attach procedure umts_gmm process model umts_layer1_mgr process model umts_node_b process model RAB procedures umts_rlc_mac process model umts_sgsn process model RNC process models all of the above

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, and CN node models. For detailed information about a particular attribute, see its description by clicking on the Details button from within the attribute dialog box.

SPM-8-46

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

UE Attributes
.

Table 8-9 UE Attributes (Part 1 of 2)


Use This Attribute... UE CN ID To... 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 CN IDs and UE CN IDs is 0. 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. 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. QoS Profile Configuration Configure each UMTS service class (conversational, streaming, interactive, and background). The majority of UMTS QoS profile configuration attributes are described below. Specify the expected maximum 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. Specify if SDUs must be delivered in order. When set to Yes, this attribute ensures that SDUs are delivered to higher layers in sequence. 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. Map the QoS classes to RACH access service classes available in the current cell.

UE IMSI

UMTS GMM Timers

Bit Rate Config (sub-attribute of QoS Profile Configuration)

Delivery Order (sub-attribute of QoS Profile Configuration) Allocation/Retention Priority (sub-attribute of QoS Profile Configuration) UMTS RACH QoS to ASC Mapping

SP Guru/Release 11.5

SPM-8-47

8UMTS Model User Guide

Specialized Models User Guide

Table 8-9 UE Attributes (Part 2 of 2)


Use This Attribute... UMTS RLC Processing Time To... 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) Specify the UMTS QoS class (conversational, streaming,...) used for each IP application ToS class (best effort, background, standard,...). Available on workstation and server UEs. Specify the state the UE is in, CELL_FACH or CELL_DCH.

UMTS ToS to QoS Mapping

UMTS UE Cell State End of Table 8-9

Node-B Attributes Table 8-10 Node-B Attributes (Part 1 of 2)


Use This Attribute... UMTS CPICH Transmission Power To... 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). 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) 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. Specify the surrounding environment (Vehicular, Pedestrian, Indoor Office,...), which defines the path loss model used for the cell. 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 Cell Pathloss Parameters

Shadow Fading Standard Deviation (sub-attribute of UMTS Cell Pathloss Parameters) Pathloss Model (sub-attribute of UMTS Cell Pathloss Parameters) Number of Floors (sub-attribute of UMTS Cell Pathloss Parameters.

SPM-8-48

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

Table 8-10 Node-B Attributes (Part 2 of 2)


Use This Attribute... UMTS FACH Transmission Power To... 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. 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. Define the QoS of each ATM SVC that carries a particular class of UMTS traffic.

UMTS Node-B Cell ID

UMTS to ATM QoS Mapping

End of Table 8-10

RNC Attributes Table 8-11 RNC Attributes (Part 1 of 3)


Use This Attribute... UMTS Handover Parameters To... Configure the RNC to support hard or soft handovers and the parameters used in handover decisions. Based on TR 25.922. 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. Configure 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) Specify the maximum length of time a radio bearer can be inactive before it is released. 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. 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. Configure parameters for radio link control operations.

UMTS RNC Admission Control Parameters

UMTS RNC Timers Processing Time (sub-attribute of UMTS RNC Timers) Tinactivity (sub-attribute of UMTS RNC Timers) Tqueuing (sub-attribute of UMTS RNC Timers) UMTS RNC Channel Configuration

RLC Info (sub-attribute of UMTS RNC Channel Configuration)

SP Guru/Release 11.5

SPM-8-49

8UMTS Model User Guide

Specialized Models User Guide

Table 8-11 RNC Attributes (Part 2 of 3)


Use This Attribute... UL RLC Mode and DL RLC Mode (sub-attributes of RLC Info) To... 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. Specify the number of RLC PUs that can be sent or received without an acknowledgement. This attribute applies only to the RLC Acknowledged Mode.

Transmission Window Size and Receiving Window Size (sub-attributes of RLC Info) RLC Discard Info (sub-attribute of RLC Info) In-Sequence Delivery (sub-attribute of RLC Info)

Specify the timers used to determine when and how packets in the transmitters RLC buffer are discarded. 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. 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. 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. 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. 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. 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. 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.

DL RLC Status Info (sub-attribute of RLC Info)

Timer Status Prohibit (sub-attribute of DL RLC Status Info)

Missing PU Indicator (sub-attribute of DL RLC Status Info)

Timer STATUS Periodic (sub-attribute of DL RLC Status Info)

RB Mapping Info (sub-attribute of Transport channel Parameters) UL TrChnl Info and DL TrChnl Info (sub-attribute of Transport channel Parameters)

SPM-8-50

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

Table 8-11 RNC Attributes (Part 3 of 3)


Use This Attribute... UMTS to ATM QoS Mapping Scheduling Weights To... Define the QoS of each ATM SVC that carries a particular class of UMTS traffic. Assign weights to each QoS class for use in the FACHs weighted round-robin scheduling algorithm. Specify the format of the UE identification number used over FACH communications. Both C-RNTI (16-bit) and U-RNTI (32-bit) are supported. Configure the RACH access service classes that define the level of service for RACH procedures. Set the timing relation between PRACH and AICH channels.

UE ID Type

ASC Parameters

AICH Transmission Timing End of Table 8-11

CN Attributes Table 8-12 CN Attributes (Part 1 of 2)


Use This Attribute... UMTS CN ID To... 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. Specify timers used in the operation of the CN. Specify the length of the GPRS attach timer.

UMTS CN Timers T3350 (sub-attributes of UMTS CN Timers TRABAssgt (sub-attributes of UMTS CN Timers T3385 (sub-attributes of UMTS CN Timers

Specify the length of the RAB assignment timer.

Specify the length of the PDP activation timer.

SP Guru/Release 11.5

SPM-8-51

8UMTS Model User Guide

Specialized Models User Guide

Table 8-12 CN Attributes (Part 2 of 2)


Use This Attribute... Processing Time (sub-attributes of UMTS CN Timers Maximum Retry on Timer Expiry (sub-attributes of UMTS CN Timers UMTS CN ToS to QoS Mapping Specify the UMTS QoS class (conversational, streaming,...) used for each IP application ToS class (best effort, background, standard,...) for traffic arriving at the SGSN from higher IP layer and destined to UEs. To... Specify the processing time for data services, transcoding, and so on.

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

End of Table 8-12

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 8-13 Simulation Attributes
Attribute UMTS UE Mobility Distance Threshold Description 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:

Noneefficiency mode is not active, Constant BLERdisables 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 8-13

UMTS Statistics
To analyze the performance of your UMTS network, you can collect several statistics during a simulation.
SPM-8-52 SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

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 8-14 Node Statistics (Part 1 of 3)
UMTS CN Total Number of Requests Granted Total Number of Requests Queued Total Number of Requests Released UMTS CN (per QoS) CN-CN Delay Number of Requests Granted Number of Requests Queued Number of Requests Released Total UTRAN-CN Delay UTRAN_CN Delay per ATM Link per QoS UMTS CN ATM VC Load Throughput Utilization UMTS GMM GPRS Attach Delay PDP Context Activation Delay Service Activation Delay UMTS GMM (per QoS) End-to-End Delay RAN Downlink Delay UMTS Handover Active Set Cell Count Cells Added to Active Set Cells Removed from Active Set UMTS Node-B Cell Active Data DCH count Total Cell Downlink Throughput Total Cell Uplink Throughput UMTS Node-B ATM VC Load Throughput Utilization

SP Guru/Release 11.5

SPM-8-53

8UMTS Model User Guide

Specialized Models User Guide

Table 8-14 Node Statistics (Part 2 of 3)


UMTS RACH Access Delay Acknowledgments Received Acquisition Indicators Received Messages Sent Negative Acknowledgments Received Preamble Cycles Per Message Preamble Power Level Preambles Sent Preambles Sent Per Message Unsuccessful Contentions UMTS RNC Total Received Throughput Total Transmit Load UMTS RNC (per Node-B) DSCH Number of Active RABs FACH Number of Active RABs UMTS RNC (per QoS class) CN-UTRAN Delay RAN Uplink Delay UMTS RNC (per transport channel) Downlink Retransmission Delay Number of Downlink Transmissions Required RAN Uplink Delay Received Sequence Number Received Throughput Transmit Load UMTS RNC ATM VC Load Throughput Utilization UMTS UE GMM (per QoS class) End-to-End Delay RAN Downlink Delay

SPM-8-54

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

Table 8-14 Node Statistics (Part 3 of 3)


UMTS UE RLC/MAC Total Received Throughput Total Transmit Load UMTS UE RLC/MAC (per physical channel) Uplink Actual Eb/No Uplink Average Interference Uplink reception Power Uplink Target Eb/No Uplink transmission Power UMTS UE RLC/MAC (per transport channel) Number of Uplink Transmissions Required Received Sequence Number Received Throughput Transmit Load Uplink Retransmission Delay End of Table 8-14

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.
Table 8-15 Global Statistics
UMTS GMM GPRS Attach Delay PDP Context Activation Delay Service Activation Delay UMTE GMM (per QoS) End of Table 8-15 End-to-End Delay

Appendix I: Acronyms and Abbreviations Used in UMTS


Table 8-16 Acronyms and Abbreviations Used in UMTS (Part 1 of 4)
Abbreviation 2G 3G 3GPP AAL Description 2nd generation 3rd generation 3rd Generation Partnership Project ATM Adaptation Layer

SP Guru/Release 11.5

SPM-8-55

8UMTS Model User Guide

Specialized Models User Guide

Table 8-16 Acronyms and Abbreviations Used in UMTS (Part 2 of 4)


Abbreviation AM ATM BLER BSC BSS BTS CGF CN CPICH CPCH CS DCCH DCH DL DPCCH DPCH DPDCH DSCH DTCH EIR EMA FACH FER GGSN GPRS GSM Description Acknowledged Mode Asynchronous Transfer Mode Block Error Rate Base Station Controller Base Station Subsystem Base Transceiver Station Charging Gateway Functionality Core Network Common Pilot Channel Common Packet Channel Circuit Switched Dedicated Control Channel Dedicated Channel Downlink (Forward Link) Dedicated Physical Control Channel Dedicated Physical Channel Dedicated Physical Data Channel Downlink Shared Channel Dedicated Traffic Channel Equipment Identity Register External Model Access Forward Access Channel Frame Error Rate Gateway GPRS Support Node General Packet Radio Service Global System for Mobile Communications

SPM-8-56

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

Table 8-16 Acronyms and Abbreviations Used in UMTS (Part 3 of 4)


Abbreviation GTP HLR IMSI IP MAC MCC MM MNC MSC OPNET OSI PCCH PCH PCPCH PCCPCH PDCP PDN PDP PDSCH PDU PMM PRACH PS PU QoS RAB Description GPRS Tunneling Protocol Home Location Register International Mobile Subscriber Identity Internet Protocol Medium Access Control Mobile Country Code Mobility Management Mobile Network Code Mobile Switching Center Optimized Network Engineering Tool Open System Interconnection Paging Control Channel Paging Channel Physical Common Packet Channel Primary Common Control Physical Channel Packet Data Convergence Protocol Packet Data Network Packet Data Protocol Physical Downlink Shared Channel Protocol Data Unit Packet Mobility Management Physical Random Access Channel Packet Switched Payload Unit Quality of Service Radio Access Bearer

SP Guru/Release 11.5

SPM-8-57

8UMTS Model User Guide

Specialized Models User Guide

Table 8-16 Acronyms and Abbreviations Used in UMTS (Part 4 of 4)


Abbreviation RACH RAN RANAP RB RRC RLC RNC SCH SGSN SM TCP TDMA TE TMSI TrM TTI UE UL UM UMTS UTRAN VLR W-CDMA End of Table 8-16 Description Random Access Channel Radio Access Network Radio Access Network Application Part Radio Bearer Radio Resource Control Radio Link Control Radio Network Controller Synchronization Channel Serving GPRS Support Node Session Management Transport Control Protocol Time Division Multiple Access Terminal Equipment Temporary Mobile Subscriber Identity Transparent Mode Transmission Time Interval User Equipment Uplink (Reverse Link) Unacknowledged Mode Universal Mobile Telecommunications System UMTS Terrestrial Radio Access Network Visitor Location Register Wideband Code Division Multiple Access

SPM-8-58

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

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 8-34 on page SPM-8-59, 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 8-34 Overview of Packet Domain Architecture
A Iu UMTS TE R MT Uu UTRAN Iu Gb BSS MSC/VLR Gs D Gr SGSN Gn Ga GGSN Ga CGF EIR Gi PDN Billing System HLR

GSM

TE

MT

Um

Gf Signalling Interface Signalling and Data Transfer Interface

Figure 8-35 Equivalent OPNET Representation

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.
SP Guru/Release 11.5 SPM-8-59

8UMTS Model User Guide

Specialized Models User Guide

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, 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 8-36 MS-GGSN User Plane for UMTS
Application e.g. IP, PPP, PDCP RLC MAC L1 UE Uu PDCP RLC MAC L1 UTRAN relay GTP-U UDP/IP AAL5 ATM Iu-PS GTP-U UDP/IP AAL5 ATM 3G-SGSN relay GTP-U UDP/IP L2 L1 Gn e.g. IP, PPP, GTP-U UDP/IP L2 L1 3G-GGSN

SPM-8-60

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

Figure 8-37 MS-GGSN Control Plane for UMTS


GMM, SM RRC RLC MAC RRC RLC MAC relay RANAP SCCP Signaling Bearer AAL5 L1 UE Uu L1 UTRAN ATM Iu-PS GMM, SM RANAP SCCP Signaling Bearer AAL5 ATM 3G-SGSN L1 Gn L1 3G-GGSN relay GTP-C UDP/IP L2 GTP-C UDP/IP L2

Mobility Management and Session Management


Figure 8-38 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 8-37. 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 8-38. 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. 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 (e.g. 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

SP Guru/Release 11.5

SPM-8-61

8UMTS Model User Guide

Specialized Models User Guide

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 8-38 UE PMM States

PMM-Detached

PS Detach

PS Attach

PS Detach

PMM-Idle

PS Signaling Connection Release PMM-Connected PS Signaling Connection Establish

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

SPM-8-62

SP Guru/Release 11.5

Specialized Models User Guide

8UMTS Model User Guide

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 8-39 RAB Assignment Procedure

SP Guru/Release 11.5

SPM-8-63

8UMTS Model User Guide

Specialized Models User Guide

SPM-8-64

SP Guru/Release 11.5

Specialized Models User Guide

Index

Index
Numerics
6to4 tunnels configuring on a router, SPM-3-12 CM attributes, SPM-2-15 configuring, SPM-2-21 nodes, SPM-2-5 CMTS attributes, SPM-2-17 configuring, SPM-2-22 nodes, SPM-2-5 communication configurations, SPM-2-7 configuration object, SPM-2-7, SPM-2-20 configuring channel(s) on a CMTS node, SPM-2-22 CM nodes, SPM-2-21 management message intervals, SPM-2-20 MAP parameters, SPM-2-20 QoS, SPM-2-20 downstream channel profiles, SPM-2-8 link model, SPM-2-6 link models, SPM-2-5 log messages, SPM-2-25 MAP statistics, SPM-2-25 model configuration requirements, SPM-2-19 model features, SPM-2-1 model features , SPM-2-1 model limitations, SPM-2-2 node models, SPM-2-5 PHS schemes, SPM-2-11 physical media profiles, SPM-2-12 protocol information general, SPM-2-3 network characteristics, SPM-2-4 statistics, SPM-2-23 downlink shared channel, SPM-8-4

C
cable modem node model, SPM-2-5 cable modem termination system node model, SPM-2-5 Cell Creator. See UMTS, Cell Creator utility. circuit switching attributes attribute definer, SPM-1-19 conference generation, SPM-1-13 multiservice switch, SPM-1-15 PBX, SPM-1-10 simulation attributes, SPM-1-20 SSP, SPM-1-14 call generation, SPM-1-2 call path preferences for IP networks, SPM-1-19 call routing, SPM-1-4 conference calls, SPM-1-3 dynamic call parameters, SPM-1-11 failure and recovery, SPM-1-7 model features, SPM-1-1 model features , SPM-1-1 modeling elements, SPM-1-8 multiservice switching (MSS), SPM-1-5 multi-trunk load balancing, SPM-1-7 object palette, SPM-1-8 path preferences, SPM-1-18 PBX parameters, SPM-1-10 routing table file, SPM-1-5 signaling sequence for call generation, SPM-1-2 SSP parameters, SPM-1-14 static call parameters, SPM-1-12 statistics, SPM-1-20 VoATM parameters, schemes, SPM-1-16

F
FEC. See forward equivalence class. forward equivalence class, creating, SPM-5-7

D
dedicated channel, SPM-8-4 DOCSIS attribute configuration object, SPM-2-6 attributes CM, SPM-2-15 CMTS, SPM-2-17 configuration object, SPM-2-7 general, SPM-2-7 simulation attributes, SPM-2-19

H
hierarchical addresses, SPM-6-11

I
IPv6 automatic tunneling on a router, SPM-3-11 configuring addresses on gateway nodes, SPM-3-6 configuring addresses on host nodes, SPM-3-6 configuring one end of a bidirectional tunnel, SPM-3-10 features, SPM-3-2

SP Guru/Release 11.5

SPM-IX-1

Specialized Models User Guide

L
LSP dynamic creating manually, SPM-5-3, SPM-5-5 static, creating, SPM-5-5

S
SSP, SPM-1-8

T
traffic engineering creating a TE binding, SPM-5-8 traffic trunk, creating, SPM-5-7 tunnel interfaces, SPM-3-2, SPM-3-10, SPM-3-12, SPM-8-3, SPM-8-27 to SPM-8-28, SPM-8-60

M
MPLS definition, SPM-5-1 dynamic LSPs, SPM-5-3 facility backup, SPM-5-14 fast reroute, SPM-5-14 features, SPM-5-1 IGP shortcuts, SPM-5-8 layer-3 VPNs, SPM-5-16 LDP-based paths, SPM-5-16 LSP routes, SPM-5-25 model limitations, SPM-5-26 one-to-one backup, SPM-5-15 reports, SPM-5-24 static LSPs, SPM-5-5 static mappings, SPM-5-6 statistics, SPM-5-24 traffic engineering, SPM-5-3 troubleshooting, SPM-5-26 VRF configuration, SPM-5-17 MSS. See multiservice switch. multiservice switch, SPM-1-5, SPM-1-9

U
UMTS abbreviations used in, SPM-8-55 admission control, SPM-8-4 air interface modeling, SPM-8-32 architecture, SPM-8-12 attributes local, SPM-8-46 simulation, SPM-8-52 bit error rate, SPM-8-31 Cell Creator utility description, SPM-8-8 input parameters, SPM-8-9 using, SPM-8-9 CN, SPM-8-27 architecture, SPM-8-26 attributes, SPM-8-51 node model, SPM-8-27 process model, SPM-8-28 creating a network topology, SPM-8-7 DCH, SPM-8-4 debugging aids, SPM-8-46 delay in RAN and CN network, SPM-8-30 DSCH, SPM-8-4 FACH, SPM-8-4 features, SPM-8-3 GGSN. See UMTS, CN. GPRS attach, SPM-8-36 handovers, SPM-8-5 interfacing to, SPM-8-43 limitations of the model, SPM-8-5 network architecture, SPM-8-12 node models, SPM-8-7 node models , SPM-8-8 Node-B architecture, SPM-8-21 attributes, SPM-8-48 node model, SPM-8-22 process model, SPM-8-23 noise background, SPM-8-31 interference, SPM-8-31 packet domain architecture, SPM-8-2 packet formats, SPM-8-44

N
Node-B. See UMTS.

P
PBX, SPM-1-8 PNNI administrative weight on a port, SPM-6-6 attributes local, SPM-6-3 simulation, SPM-6-8 default settings for parameters attribute, SPM-6-3 exporting address information, SPM-6-9 node information, SPM-6-9 path information, SPM-6-8 external routes, SPM-6-5 features, SPM-6-1 group IDs, SPM-6-10 groups and hierarchies, configuring, SPM-6-10 hierarchical addresses, SPM-6-11 modes, SPM-6-2

Q
QoS in a DOCSIS model, SPM-2-20 SPM-IX-2

SP Guru/Release 11.5

Specialized Models User Guide PDP context activation, SPM-8-37 power control, SPM-8-4 protocol background, SPM-8-59 queue allocation at RNC, SPM-8-25 queue structure at UE, SPM-8-15 RAB assignment initiated by the network, SPM-8-40 initiated by the UE, SPM-8-40 with PDP activation, SPM-8-39 RACH, SPM-8-4 radio-air interface, SPM-8-30 received power, SPM-8-30 reference documents, SPM-8-6 RLC AM retransmission, SPM-8-20 RNC architecture, SPM-8-23 attributes, SPM-8-49 node model, SPM-8-24 process model, SPM-8-24 signal flow to Node-B, SPM-8-41 SGSN. See UMTS, CN. signal flows, SPM-8-36 for adding and deleting a radio link, SPM-8-41 for hard handover, SPM-8-42 for soft handover, SPM-8-43 statistics global, SPM-8-55 node, SPM-8-53 timing, SPM-8-29 traces , SPM-8-46 UE architecture, SPM-8-13 attributes, SPM-8-47 node model, SPM-8-13 process model, SPM-8-15 W-CDMA support, SPM-8-4

W
W-CDMA, SPM-8-4

SP Guru/Release 11.5

SPM-IX-3

Specialized Models User Guide

SPM-IX-4

SP Guru/Release 11.5