MobSim

A GSM Network Simulator





MobSim Programming Group

Hannu Arvelo		         arvelo@vipunen.hut.fi
Ismo Kangas		ismo.kangas@research.nokia.com
Riku Linnanen		          riku.linnanen@hut.fi
Janne Pelkonen		    jpelkone@niksula.cs.hut.fi
Jaakko Tiainen		     jtiaine@niksula.cs.hut.fi

Table of Contents


1. Introduction

In order to understand this document, it is essential to understand the basic GSM terminology. To help out, we have provided a small GSM dictionary.

1.1 Overview

The aim of the MobSim (Mobile Phone Simulator) project is to implement an information system simulating a GSM network and demonstrating its operation. GSM consists of the following parts:

The MobSim project will implement these as protocol stacks, plus a system that demonstrates the signalling traffic going on in the mobile network. The end product will consist of four protocol implementations with a textual user interface and a graphical program to monitor the signalling. Project uses HP-UX with X Windows as developement platform.

MobSim system will be used as a tool to demonstrate selected signalling functionality of a real GSM network. The following functionality will be implemented in the system

The main goal of the project is to provide a means to effectively demonstrate the signalling taking place in a GSM network during these operations. It should be noted, however, that the signaling used is not a complete implementation of the GSM signaling. Signalling is not complete and the signals used are specified using CASN (see below) BER coding, not according to the GSM specifications.

Besides this, the system is intended to serve as an exercise environment for students. The idea is to make additions to the system as an exercise e.g. to add ciphering and authentication signalling to MobSim. It is believed that this kind of environment would be quite realistic - in telecommunications software engineering it is rare to start from scratch. Most often one sets out to enhance and add functionality to an existing system.

The project uses the following main tools:

CVOPS is an environment developed by Technical Research Centre of Finland. It is an operating system-like environment specially intended for protocol development. CASN is a compiler for Abstract Syntax Notation One language developed in Nokia Research Centre, Finland. CVOPS and CASN work nicely together.


1.2 Limitations of MobSim

MobSim is aimed at demonstarating the main aspects of a GSM network. Thus, some decisions have been made to reduce the complexity of the system. Among the biggest differences to a real GSM network are:


2. Structure of MobSim

MobSim has six main components. Four of them simulate the main parts of GSM networks: Mobile System, Base Tranceiver Station, Base Station Controller and Mobile Switching Centre. GUI-tool, or Monitor, is used to monitor the signalling traffic going on in the network. Transmitting data between the Monitor and the various parts of the simulated GSM network is the Virtual Transport Layer (VTL). In OSI terminology, VTL simulates Physical, Link and partly Network layers.

Figure 1: The structure of MobSim

The main functions of the MobSim components are:

The signalling implemented by the system shows several design choices made during planning of the system:

Each signal used in the description is specified shortly in our signals dictionary.


3. Using MobSim

In this chapter we describe how to use MobSim. Central to the operation of MobSim are two files - the MobSim configuration file describing the MobSim network elements, and HLR (Home Location Register) file which holds data of the Mobile Systems available in the system. Throughout this document, we will use the following exemplary MobSim configuration file - for a description of the file format, see chapter 3.3.

VTL	3110	lk-hp-16.hut.fi
MSC	1	0	1001
BSC	10	1	2001
BSC	11	1	2002
BTS	100	10	300	20
BTS	110	10	301	30
BTS	120	11	500	60

3.1 Starting MobSim

MobSim is started with a shell script that sets up different environment variables and starts the network elements described in the configuration file. These environment variables are used to pass parameters to the network element executables - CVOPS does not allow command line parameters. These environment variables are used:

Environment variable              Meaning                                 
MOBSIM_CONFIG                     Path to MobSim configuration file       
MOBSIM_HLR                        Path to MobSim HLR file                 
MOBSIM_BTS_INDEX                  ID (field 2 in config file) of the BTS  
MOBSIM_BSC_INDEX                  ID (field 2 in config file) of the BSC  
MOBSIM_MSC_INDEX                  ID (field 2 in config file) of the MSC  
MOBSIM_MS_IMSI                    IMSI of the MS to start                 
MOBSIM_MS_ISDN_NUMBER             Phone number of the MS to start         

This example start-up script starts the network elements described in the example configuration file, a single MS with IMSI 000000000000001, phone number 94012345678 and one instantation of the MobSim Monitor program. This example assumes that the various simulator executables can be found in the search path. We have to wait for some time after starting VTL, since we have to ensure that VTL starts listening to its I/O port before we start the various netowork element simulators.

	#!/bin/csh
	setenv MOBSIM_CONFIG mobsim.cnf
	setenv MOBSIM_HLR hlr.dat
	# Virtual Transport Layer
	xterm -e vtl &
        # Wait untill VTL starts listening...
        sleep 5
	# MSC
	setenv MOBSIM_MSC_INDEX 1
	xterm -e mscsim &
        unsetenv MOBSIM_MSC_INDEX
	# BSCs
	setenv MOBSIM_BSC_INDEX 10
	xterm -e bscsim &
        unsetenv MOBSIM_BSC_INDEX
	setenv MOBSIM_BSC_INDEX 11
	xterm -e bscsim &
        unsetenv MOBSIM_BSC_INDEX
        # BTSs
	setenv MOBSIM_BTS_INDEX 100
	xterm -e btssim &
        unsetenv MOBSIM_BTS_INDEX
	setenv MOBSIM_BTS_INDEX 110
	xterm -e btssim &
        unsetenv MOBSIM_BTS_INDEX
	setenv MOBSIM_BTS_INDEX 120
	xterm -e btssim &
        unsetenv MOBSIM_BTS_INDEX
	# MSs
	setenv MOBSIM_MS_IMSI 000000000000001
	setenv MOBSIM_MS_ISDN_NUMBER 94012345678
	xterm -e mssim &
	unsetenv MOBSIM_MS_IMSI
	unsetenv MOBSIM_MS_ISDN_NUMBER
	# Monitor
	gui &

When the various network elements start up, they read the configuration file and HLR file (in MSC) further. For a closer description, see Chapter 4.


3.2 User Interfaces

3.2.1 Mobsim Monitor

Mobsim Monitor provides a graphical user interface to preview the signalling of the Mobsim system. It monitors continuously the network and draws the signalling as a message sequence chart onto its drawing area. In the chart vertical lines represent network elements, and horizontal arrows signalling between them. User can get a detailed information about every message by clicking the message arrow. GSM-network and its signalling can be quite complex. In order to make the monitoring easier three kinds of filters can be applied to the message sequence chart. Using filters user can choose which messages he or she wants to be displayed on the screen and which he doesn't.

Received message sequence charts can be saved to the disk.

3.2.1.1 Monitor Window

Monitor window is the main window of the Mobsim Monitor. it contains a menu bar, a drawing area and a button panel (fig 1).

Figure 1. Monitor Window

3.2.1.2 Menu Bar

Menu bar contains the following menus:

File

Save: Saves the current chart to the disk

Load: Loads a previously saved chart from the disk

Exit: Quits the Mobsim Monitor.

Edit

Clear: Clears the current chart

Filter: Opens the filter dialogue

Help

About: Shows information about the Mobsim Monitor

3.2.1.3 Drawing area

The message sequence chart is drawn onto the scrollable drawing area. Network elements are shown in the top of the chart. Signalling between the elements are shown as horizontal arrows from the source element to the target element. Over the arrow is the name of the message.

User can get a detail information of a message by clicking the message arrow. This opens a popup window in which the actual data of that message is displayed.

Beside the drawing area there are scroll bars that can be used to scroll the chart horizontally and vertically if it doesn't fit in the drawing area. Mobsim Monitor provides two scrolling modes: automatic and manual. When the automatic scrolling is on, the drawing area scrolls automatically when a new message is received. The last received message is always displayed on the bottom of the drawing area in that case. In manual mode the drawing area remains static even if new messages are received. User must use the scroll bars to move within the chart.

3.2.1.4 Button panel

On the bottom of the monitor window there is a button panel that contains three buttons:
Start/Stop      Start button turns the monitoring on and Stop button turns it off. When    
                the monitoring is on, the Mobsim Monitor records the received messages     
                into its data structures and updates the message sequence chart in the     
                drawing area.                                                              
Scroll/Hold     Scroll button turns the automatic scrolling on and Hold button turns it    
                off. In the automatic scrolling mode the drawing area scrolls              
                automatically when a new message is received.                              
Clear           Clear button clears the current chart.                                     

3.2.1.5 Filter Dialogue

User can choose which messages he or she wants to be displayed on the drawing area. Three kinds of filters is provided: network element filter, protocol filter and mobile station filter. Filter can be applied in the Filter dialogue which is opened from the monitor window by choosing the menu Edit | Filter. Filter dialogue is represented in fig 3.

Figure 3. Filter Dialog Box

In the Filter dialog there are there different group boxes, one for each filter type:

Network element -filter  User can select which network elements are visible in    
                         the chart.  By default all the elements are visible      
Protocol -filter         By protocol filter user can select which protocols are   
                         visible in the chart. Each message belongs to one of     
                         the five protocols: CC, RR, MM, BTSM, BSSAP.             
Mobile station -filter   Each message relates to one mobile station. When there   
                         are more than one mobile station in the network, the     
                         message sequence chart becomes quite complex. By using   
                         the mobile station -filter user can select the mobile    
                         stations whose messages he or she wants to be            
                         displayed in the drawing area.                           

In the filter dialog box there are one toggle button group for each filter type. If a toggle button is up the respective messages are filtered and they are not shown in the chart.

Mobsim Monitor records every message it receives even if a filter is applied. Applying a filter means only that filtered messages are not shown in the chart.

On the bottom of the filter dialog there is a button panel with three buttons:

Apply                                    Applies the selected filter to the       
                                         chart.                                   
Cancel                                   Cancels the changes made in the filter   
                                         dialog.                                  
Close                                    Closes the filter dialog.                

3.2.1.6 Popup Windows

A detailed information about one message is represented in a popup window. By clicking a message arrow in the monitor window user can show a popup window that displays the data of the selected message.

3.2.1.7 Loading and Saving Charts

A received message sequence chart can be saved to the disk and a previously saved chart can be loaded from the disk. File menu of the monitor window contains menus Load and Save for this purpose. They open a file selection dialog box in which user can choose the name of the saved or loaded chart. A file selection dialog box is represented in fig 4.

Figure 4. File Selection Dialog Box

3.2.2 Mobile Station

Conventions used in this and the next chapter:
Italics means user input.
Bold text means prompt by the application or CVOPS.

These commands are available in MobSim-MS:

call
Give number to call: number
Starts a Mobile Originating Call (MOC) in the mobile station. It sends CCs_Setup_Req primitive to the CC.

answer
Answers to the Mobile Terminating Call (MOT). It sends CCs_Call_Conf_Req primitive to the CC.

disconnect
Disconnect call that is already connected or terminates call establishment phase. It sends CCs_Disconn_Req primitive to the CC.

3.2.3 Mobile Switching Centre

The following commands are available for the user in MSC:

call
Starts a Mobile Terminated Call in MSC. The user is asked both calling and called number:
Give calling number: number
Give called number: number
The accepted input is 0-15 numerical characters. This action simulates a normal telephone user calling a GSM phone under MSC's control. Actions taken in a successful case (see MSC description for a complete description) are as follows:
1. Called number analysis
2. Mapping called number onto IMSI
3. Sending CC CCs_Paging message containing IMSI to be found (no connection is made)
4. CC sends MMs_Paging message to MM (no connection is made)
5. MM sends BSSAP_Paging to BSSAP (no connection is made)
6. BSSAP Fills in needed SCCPS data
7. BSSAP send SCCPS_UnitDataReq message to SCCPS
8. SCCPS part of VTL routes this message to all BSCs
This will start the signalling needed in MTC. In erroneous cases an error message indicating the cause of the error is given - see Troubleshooting in description of MSC.

show
Shows a list of all calls currently in progress. This action is mainly needed for checking the ID number of calls. Useful information of the calls in progress is also presented with this call.

ID	SOURCE	        DESTINATION
1	950-1234567	90-4775876
2	922-22921	950-1234567

connect
<CVOPS shows a list of active calls, including their ID>
cepID: ID
Simulates network outside of MSC: the call ID has been successfully connected with the receiving party. Used in conjunction with MOC. In practise this command sends CCs-CALL-DELIVERED-IND to the CC related with this MOC.

answer
<CVOPS shows a list of active calls, including their ID>
cepID: ID
Also simulates network outside of MSC: the receiving party of MOC answers the phone. Sends CCs-CALL-CONNECTED-IND to CC.

disconnect
<CVOPS shows a list of active calls, including their ID>
cepID: ID
Closes the connection in question (Disconnect by Network). Sends CCs-DISC-IND to CC.



3.3 Network Configuration

The configuration of MobSim system network is described by a configuration file. The environment variable MOBSIM_CONFIG should point to this file. The configuration file is a text file with whitespace as field delimiters. The following table describes the file format in detail.

AN = alphanumeric field

N = numeric field

Field               Type                Length              Contents            
Tag                 AN                  3 + 1 delimiter     `VTL' or `MSC' or   
                                                            `BSC' or `BTS'      
Id                  N                   6 + 1               VTL: I/O port       
                                                            used for sockets    
                                                            MSC, BSC, BTS:      
                                                            Unique network      
                                                            component ID        
                                                            number              
Info1               AN                  VTL: until EOL      VTL: host name      
                                        MSC, BSC, BTS: 6    BSC, BTS:           
                                        + 1                 parent's ID         
Info2               AN                  10 + 1              MSC, BSC: SCCPS     
                                                            point code BTS:     
                                                            Location area code  
Info3               AN                  10 + 1              BTS: Carrier          
                                                            number used        

An example of a legal configuration file looks like this:

VTL 3110  lk-hp-16.hut.fi
MSC 1     0      1001
BSC 10    1      2001
BSC 11    1      2002
BTS 100   10     300       20
BTS 110   10     301       30
BTS 120   11     500       60

This would create a GSM network that shown in figure 5.

Figure 5: An example of a MobSim GSM network

The network elements would be connected with VTL in host lk-hp-16.hut.fi port 3110.


3.4 Home Location Register

HLR (Home Location Register) file stores the central information for each phone under MSC's control. Other MSCs query information from HLR when an MS in roaming. This file read and updated during location updating, paging and MOC. An environment variable MOBSIM_HLR will point to this file.

Field               Type                Length              Contents            
IMSI                N                   15 + 1                                  
CurrCountry         N                   3 + 1               Country code        
CurrMSC             N                   6 + 1               MSC Id              
CurrLAC             N                   10 + 1              LAC within the      
                                                            above-mentioned     
                                                            MSC                 
Number              N                   15 + 1              Phone number        
SubsData            AN                  30 + 1              Arbitrary           
                                                            subscriber          
                                                            information         
nCalls              N                   6 + 1               Calls since last    
                                                            billing             
tCalls              N                   6 + 1               Duration of calls   
                                                            since last          
                                                            billing, in         
                                                            seconds             

SubsData field could contain the supplementary services in use, the level of authentication etc. It has as of yes not been implemented in full detail. An exemplary HLR file looks like this:

000000000000001 358 000001 0000000111 9405559114 xxxxxxxxxxxxxxxxxxx 000000 0000000 
000000000000002 358 000001 0000000100 9405006868 xxxxxxxxxxxxxxxxxxx 000000 000000000 
000000000000003 358 000002 0000000100 9505503305 xxxxxxxxxxxxxxxxxxx 000000 00000000000 


4. MobSim Components

The symbols in Figure 6 are used in the description of MobSim components.

Figure 6. Symbols used in MobSim component description


4.1 Graphical User Interface (GUI)

4.1.1 Overview

Mobsim Monitor is implemented using C++ with motif Xm, Xt and Xlib libraries. The purpose of the Mobsim Monitor is to create a socket connection to the virtual transport layer and record the received messages in its data structures so that the can be displayed in a message sequence chart or saved to the disk. User can choose using the scroll bars of the monitor window which portion of the message structure is drawn on the screen.

4.1.2 Module: Gui

gui.h
gui.cc

Gui is the main module of the Mobsim Monitor in which the monitor window is created and initialised. Callback functions are defined and an input handler is assigned. Input handler is called automatically when socket has a new message.

4.1.2.1 Global Variables

Widget toplevel   Top level shell.                                                                     
Widget vsb,hsb    Vertical and horizontal scroll bars for the drawing area.                            
int index         Index to the message list. Its value tells which is the topmost message on the       
                  drawing area.                                                                        
int hor_pos       Value of the horizontal scroll bar.                                                  
Display *display  Display of the drawing area.                                                         
Window window     Window of the drawing area.                                                          
GC gc             Graphic context                                                                      
int monitoring    1 if monitoring is on. When monitoring is on, received messages are saved in the     
                  allMessages-strucuture of the Network class. Monitoring is toggled using the         
                  Start/Stop button. Default 0.                                                        
int scrolling     1 if autoscroll mode is on. When autoscroll is on, the drawing area scrolls          
                  automatically when a new message is received from the socket. Autoscrolling is       
                  toggled using Scroll/Hold button. Default 1.                                         

4.1.2.2 Callback Functions

Function             Caller           Action                                                            
start_cb()           Start/Stop       Toggles the monitoring variable.                                  
                     button                                                                             
hold_cb()            Scroll/Hold      Toggles the scrolling variable.                                   
                     button                                                                             
clear_cb()           Clear button     Frees the memory reserved by the received message sequence.       
                                      Calls network.clear() -function and initializes index to 0.       
file_cb()            File menu        Load, Save: Opens a File selection dialog box Exit: Exits the     
                                      Mobsim Monitor                                                    
edit_cb()            Edit menu        Filter: Shows the filter dialog. Calls ShowFilterDlg()-function   
                                      from the gui_filter-module. Clear: Calls the                      
                                      clear_cb()-callback function.                                     
help_cb()            Help menu        About: Shows the information dialog about the Mobsim Monitor.     
scroll_action_cb     Scrollbars       Sets index to the value of the vertical scrollbar and hor_pos     
                                      to the value of the horizontal scrollbar.                         
draw_area_cb()       Drawing area     When user clicks the drawing area, rightClick()-function in the   
                                      draw-module is called.  Calls the redraw()-function in the        
                                      draw-module whenever the window needs to be repainted.            
fileopen_cb()        FileOpen         If Ok is choosed in the FileOpen dialog box, calls                
                     dialog box       network.load()-function.                                          
filesave_cb()        FileSave         If Ok is choosed in the FileOpen dialog box, calls                
                     dialog box       network.save()-function.                                          
SocketHandler_cb()   Socket           Whenever a new message is received from the socket this           
                                      callback function is called automatically. It calls               
                                      GetNextMessage()-function in the gui_network-module to read       
                                      that message from the socket.                                     

4.1.3 Module: Gui_network

gui_network.h
gui_network.cc

Gui_Network module contains the functions that handles the socket connection to the virtual transport layer. It provides also functions and data structures to store and handle received messages.

4.1.3.1 Constants

MESSAGE_STRUCTURE_SIZE                        Maximum size of the messageList in Network-class.       
MAX_NUM_ELEMENTS                              Maximum number of network elements in system.           
MAX_NUM_PROTOCOLS                             Maximum number of different protocols in system.        
MAX_NUM_MOBILES                               Maximum number of mobile stations in system.            
MAX_DATA_SIZE                                 Maximum size of the message data in system.             

4.1.3.2 Data Structures

Networkelement_type                           Type of the network element: MS, BTS, BSC or MSC        
ProtocolType                                  Type of the protocol: CC, MM , RR, BSSAP, BTSM          
MonitorMessage                                Structure of one message. Includes the source, source   
                                              index, target, target index, name, mobile index,        
                                              protocol and data of the message.                       
NetworkElement                                Structure of one network element. Includes type,        
                                              index, name and visibility of the element.              
Protocol                                      Structure of one protocol. Includes the type, name      
                                              and visibility of the protocol.                         

4.1.3.3 Classes

Network

Network is class that provides all necessary functionality to handle the messages that are received from the socket or loaded from the disk.

MonitorMessage *allMessages                   All the received messages are stored in this data       
                                              structure using addLast-member function.                
int allIndex                                  Index to the allMessages array. It points to the next   
                                              free location in that structure.                        
MonitorMessage *messages                      All the messages that are not filtered are stored in    
                                              this data structure. Member function filter updates     
                                              this array.                                             
int index                                     Index to the messages array. It points to the next      
                                              free location in that structure.                        
int ms, bts, bsc, msc                         Number of each network elements that are source or      
                                              target of the received messages that are not filtered   
                                              out.                                                    
all_ms                                        Number of all Mobile stations that are source or        
                                              target of the all of the received messages.             
NetworkElement *allElements                   All the used network elements are stored in this        
                                              array.                                                  
int numAllElements                            Number of used network elements                         
NetworkElement *elements                      All the used network elements, that are not filtered    
                                              out, are stored in this array.                          
int numElements                               Number of used network elements that are not filtered   
                                              out.                                                    
int getNMessages()                            Returns the number of the message that are not          
                                              filtered out.                                           
int getNAllElements()                         Returns the number of the network elements.             
int getNElements()                            Returns the number of the network elements that are     
                                              not filtered out.                                       
int getNAllMS()                               Returns the nuber of the mobile stations.               
int getAllElementNum(int element, int index)  Returns the order number of the element.                
int getElementNum(int element, int index)     Returns the order number of the element that are not    
                                              filtered out.                                           
char *getAllElementName(int I)                Returns the name of the element i.                      
char *getElementName(int i)                   Returns the name of the element I that isn't filtered   
                                              out.                                                    
MonitorMessage *getMessage(int I)             Returns the ith message.                                
int addLast(MonitorMessage *)                 Appends the received message to the                     
                                              allMessages-array. If the message passes the filter     
                                              then it is appended to the messages-array too.          
void addNewElement(Networkelement_type, int   Appends a new network element to the                    
index)                                        allElements-array. If the elements passes the filter    
                                              it is appended to the elements-array too.               
void setVisible(int I, Boolean b)             Sets the visibility of the ith network element.         
Boolean isVisible(int i)                      Returns the visiblity of the ith network element.       
void clear()                                  Clear the Network-class. Empties all the data           
                                              sturctures and initializes all the variables.           
void filter()                                 Applies the filter to messages. The messages from the   
                                              allMessages-list that passes the filter criteria are    
                                              copied to the messages-list..                           
void load(char *filename)                     Loads a saved message sequece chart from the disk.      
void save(char *filename)                     Saves the current message sequence chart to the disk.   

ProtocolList

int NProtocols                                Number of different protocols.                          
Protocol *Protocols                           Data structure that stores all the different            
                                              protocols.                                              
void SetVisible(int i, Boolean b)             Sets the visibility of the ith protocol.                
Boolean isVisible(int i)                      Returns visibility of the ith  protocol.                
int getNProtocols()                           Returns the Number of different protocols.              
char *getProtocolName(int i)                  Returns the name of the ith protocol.                   

4.1.3.4 Global Variables

Network network                               Network variable contains all information about the     
                                              gsm-network and the received messages.                  
ProtocolList protocolList                     Handles the protocols.                                  
int sock                                      Socket to the virtual transport layer.                  

4.1.3.5 Functions

int CreateSocketConnection(char *host, long   Creates a socket connection to the virtual transport    
port)                                         layer. Assigns the sock-variable.                       
int GetNextMessage()                          Reads the next message from the socket. If the          
                                              monitoring is on, parses the received character         
                                              string and calls the network.addLast()-member           
                                              function to store the message to the                    
                                              network-structure. Returns 1 if message of a corrcet    
                                              type was received succesfully.                          

4.1.4 Module: Gui_filter

gui_filter.h
gui_filter.cc

Filter dialog is created and shown here. Also all the filtering functions are in this module.

4.1.4.1 Global Variables

Widget filterDialog                           Filter dialog widget.                                   
Static Widget element_buttons[]               Toggle buttons for the element-filter.                  
Static Widget protocol_buttons[]              Toggle buttons for the protocol-filter.                 
Static Widget mobile_buttons[]                Toggle buttons for the mobile-filter.                   
int Position x, y                             Position of the Filter dialog. When the filter dialog   
                                              is recreated it can restore the previous position on    
                                              screen.                                                 

4.1.4.2 Functions

void ShowFilterDlg()                     Shows the filter dialog. If filter       
                                         dialog isn't created, creates it.        
void UpdateFilter()                      Updates the filter dialog if new         
                                         network elements have been added to      
                                         the system.                              

4.1.4.3 Callback Functions

apply_cb()        Apply Button           Apply the filter to the network          
                                         elements, protocols and mobile           
                                         stations by setting their visibility     
                                         property. Then it calls the              
                                         network.filter()-member function in      
                                         the gui_network-module to filter the     
                                         messages.                                
cancel_cb()       Cancel Button          Cancels the changes user has done in     
                                         the filter dialog.                       
close_cb()        Close button           Closes the filter dialog.                

4.1.5 Module:Gui_draw

gui_draw.h
gui_draw.cc

Gui_draw module handles the drawing of the message sequence chart to the monitor window.

4.1.5.1 Constants

HSPACING                                 Horizontal spacing of the network        
                                         elements in the drawing area.            
VSPACING                                 Vertical spacing of the network          
                                         elements in the drawing area.            
LEFTOFFSET                               Left offset of the drawing area.         
TOPOFFSET                                Top offset of the drawing area.          

4.1.5.2 Functions

void drawArrow(int x1, int y1, int x2,   Draws an arrow from (x1,y1) to (x2,y2)   
int y2, char *text)                      and draws the name of the message over   
                                         the arrow.                               
void updateScrollbars(int width,         Updates the the scrollbars of the        
height)                                  drawing area.                            
void redraw(int clear)                   Redraws the drawing area. Calls the      
                                         updateScrollbars-function to update      
                                         the scroll bars. Draws a selected        
                                         protion of the message sequce chart to   
                                         the drawing area.  If Clear = 1 then     
                                         clears the drawing area first.           
void rightClick(int x, int y)            This function is called from the         
                                         gui-module when user has clicked in      
                                         the drawing area at (x,y). Checks if     
                                         user has clicked an arrow, if so,        
                                         calls the ShowPopupWindow()-function     
                                         in the gui_popup-module to show a        
                                         popup window.                            

4.1.6 Module:Gui_popup

gui_popup.h
gui_popup.cc

This module handles the creating and showing the popup window that displays a detailed information about the clicked message arrow from the monitor window.

4.1.6.1 Constants

DEFAULT_HEIGHT                           Default height of the popup window       
DEFAULT_WIDTH                            Default width of the popup window        

4.1.6.2 Functions

void ShowPopupWindow(int x, int y,       Creates and shows a popup window at      
char *message)                           (x,y).                                   

4.1.7 Troubleshooting

The Mobsim Monitor is compiled with g++ version 2.5.8. There is some kind of bug in the version 2.6.3 that raises a bus error when user tries to open a fileSelectionBox with load or save commands.


4.2 Virtual Transport Layer (VTL)

MobSim-VTL connects the other elements of MobSim simulation system. It acts like a switch by receiving and sending continuously messages from and to the elements of the system. MobSim-VTL recognises several different types of interfaces and routes a message according to the protocol defined for the interface the message came from.

4.2.1 Invoking MobSim-VTL

When MobSim-VTL is invoked, it reads the general Mobsim configuration file. In order to find out the name of the configuration file, it checks the environment variable named MOBSIM_CONFIG, which should contain it. The information MobSim-VTL needs to know from the file is the IP port number of the socket it starts to listen. See chapter 3.1 for more information.

4.2.2 The Operation of MobSim-VTL

MobSim-VTL is a server-type program. It waits the other elements to connect to it, and then passes messages between them. MobSim-VTL does not need to be operated explicitly. When it is started, it simply sits there and handles the connections. MobSim-VTL can simultaneously wait for new connections and deliver messages between its clients.

4.2.2.1 Connecting to MobSim-VTL

MobSim-VTL uses the TCP/IP sockets for communicating with the other MobSim-elements. Because it communicates with a number of several types of interfaces simultaneously, it is always the server side of the connection. It therefore creates a listen socket to wait for incoming connections. The port number of the listen socket is read from the MobSim configuration file. When a MobSim-element connects to MobSim-VTL, it has to define the type of interface it uses. It also has to send some interface-type-specific initialisation information to MobSim-VTL. When a new incoming connection is created, MobSim-VTL prints a message:

	 "new <interface type> connection, fd = ..."
to the file associated with the stderr descriptor. The message contains information of the type of the connection, the newly created file descriptor and some type-specific information. If the connecting or initialisation phase fails for some reason, MobSim-VTL tries to recover by closing the newly opened file descriptor. In such case it also sends an error message to stderr. The message contains the information of the failed file descriptor and the type of the interface involved.

4.2.2.2 Connection types

MobSim-VTL recognises five different types of connections. The types and the type-specific initialisation and addressing schemes are explained below:

4.2.3 Troubleshooting MobSim-VTL

When MobSim-VTL is started, it usually does not need any attention. It just operates as a switch creating new connections and passing messages between the existing one. In order to get it started correctly, it is required that the environment and the configuration file is set up. If there is not enough information, or the information is inconsistent, MobSim-VTL gives an error message and exits. When receiving incoming connections and when passing messages there might happen some kind of error. In such cases MobSim-VTL prints an error message and closes the file descriptor involved. Here is a list of the error messages, and for each an explanation.


4.3 Mobile Station (MS)

Mobsim-MS consists of five CVOPS virtual tasks (vtask). Three of them are protocol implementations (RR, MM , CC), one is interface vtask to VTL (LAPMIF), and one is a MobSim-MS application vtask (MSA). Figure 6 presents the structure of MobSim-MS.

Figure 6. The structure of MobSim-MS

4.3.1 Invoking MobSim-MS

MobSim-MS gets its own IMSI (International Mobile Subscriber Identity) from environment variable called MOBSIM_MS_IMSI and its own phone number from environment variable called MOBSIM_MS_ISDN_NUMBER. If one of environment variables is missing, corresponding value is initialised to be an empty string.

When MobSim-MS process is started ("power on"), it tries to establish connection to the virtual layer. When connection exists between MS and virtual layer, virtual layer sends system information to the MobSim-MS. System information tells cell, location area and channel configuration. If connection establishment is failed, an error message is given and MobSim-MS exists.

4.3.2 The structure of MobSim-MS

MobSim-MS consists of six CVOPS vtasks. Three of them (RR, MM and CC) represent GSM protocols, two represent interfaces to MobSim-VTL (LAPMIF and GUIIF) and one acts as the user interface of MS (MSA).

4.3.2.1 RR (Radio Resources)

The general purpose of RR protocol is to establish, maintain and release radio connections between the network and Mobile Station. This includes the cell selection/reselection procedures [GSM 04.08].

The CVOPS implementation of RR-protocol consists of:

4.3.2.2 MM (Mobility Management)

The main function of the MM is to support the mobility of Mobile Stations [GSM 04.08]. The functions of MM include:
- normal location updating procedure
- MM connection management procedures

The CVOPS implementation of MM-protocol consists of

4.3.2.3 CC (Call Control)

The functions of CC include [GSM 04.08]:
- call establishment services
- call clearing services
- call information phase services

The CVOPS implementation of CC-protocol consists of

4.3.2.4 LAPMIF (LAPDm Interface)

LAPMIF-interface vtask provides the needed LAPDm services to upper layers. LAPMIF vtask connects to the Virtual Transport Layer, tells its own index, and uses the index of the neighbour element for addressing. The function is simply LAPDm information transfer service.

The CVOPS implementation of LAPMIF-protocol consists of:

4.3.2.5 GUIIF (GUI InterFace)

GUIIF-interface vtask connects to the Virtual Transport Layer. It received messages containing the received pdus from every protocol vtask. For each received message it sends a tracing message to active GUI-tools via the Virtual Transport Layer. The functions of GUIIF includes:
- tracing messages handling service

The CVOPS implementation of GUIIF consists of:

4.3.2.6 MSA (MS Application)

MSA is the user interface of MobSim-MS. It provides the following functions to the user:
- call establishment
- call release
- answering to the call

See Chapter 3.2.2 for a closer look on these commands.

The CVOPS implementation of MSA consists of:


4.4 Base Tranceiver Station (BTS)

MobSim-BTS consists of five CVOPS virtual tasks (vtask). Two of them are protocol implementations (RR' , BTSM), two are interface vtasks (LAPMIF, LAPDIF), and one is a MobSim-BTS application vtask (BTSA). Figure 7 presents the structure of MobSim-BTS.

Figure 7: Structure of MobSim-BTS

4.4.1 Invoking MobSim-BTS

When MobSim-BTS is started, it behaves like a normal CVOPS system. The system can be operated by using the CVOPS command interpreter. Initially, the system is set up by giving it the CVOPS run-command, which asks user the protocol structure file. This initialisation step is automated by defining a specific macro called CVOPS_init in the CVOPS default macro file macro.mac. A sample macro file containing this initialisation macro looks like:

	$CVOPS_init$
	run
	bts.str
	macro end

When the vtasks of MobSim-BTS are initialised, they read the general Mobsim configuration file. MobSim-BTS needs information of the network addresses of itself and the BSC it is connected to. It also needs to know the indices of the BTSs, which it controls. In order to find out the name of the configuration file, it checks the environment variable named MOBSIM_CONFIG, which should contain it. MobSim-BTS needs also knowledge of its own index in the file. The index must be given in the environment variable named MOBSIM_BTS_INDEX. See chapter 3.1 for more information and an example configuration file. For example, the MobSim-BTS with index 110 can be found in the file, and there exists a BSC for it also. If either of the environment variables is absent, or if MobSim-BTS cannot find the information it needs from the configuration file, a short error message is given and MobSim-BTS then exits.

After MobSim-BTS has successfully read the needed information from the configuration file, both of its interface vtasks try to connect to the virtual transport layer. Again, if there happens some error during making the connections, a short error message is given and MobSim-BTS exits.

4.4.2 The structure of MobSim-BTS

The structure of MobSim-BTS has its roots in the role of BTS as a bridge connecting mobile stations and the network. BTS relays messages between two quite different interfaces, namely the Air interface and the A-bis interface. The MobSim-BTS, however, simplifies this situation by defining the protocol stack only down to LAPM and LAPD interfaces, where the physical differences are well hidden.

MobSim-BTS consists of six CVOPS vtasks. Two of them (BTSM, RR') represent GSM protocols, one is has the conversion logic between the Air and A-bis interfaces (BTSA), and three are interfaces to MobSim-VTL (LAPDIF, LAPMIF and GUIIF).

4.4.2.1 BTSM

The function of BTSM vtask is to receive controlling messages from the BSC counterpart. These controlling messages drive the whole element. BTSM uses LAPD services and provides its own services for BTSA. Since LAPD only provides a two-way data communication service, BTSM operations are mainly controlled by BSC BTSM PDU's and BTSM primitives triggered by BTSA.

4.4.2.2 BTSA

The function of BTSA vtask is to provide a link between RR' and BTSM. Since not all related BTSM and RR data types are matching, some data manipulation is necessary. Since BTSA is connection-oriented, and RR' is not, some special attention needs to paid. In this case, the sole responsibility for correct CEP_id matching is left to RR'.

4.4.2.3 RR'

The function of RR' is to relay messages from and to the mobile station using the correct channel. While most of the messages received are passed on intact, some pdus have to be changed. The pdus listed below are transformed:

Direction                  Received PDU               Transmitted PDU            
Uplink                     CHANNEL_REQUEST            CHANNEL_REQUIRED           
Downlink                   IMM_ASSIGNMENT_CMD         IMMED_ASSIGNMENT           
Downlink                   PAGING_COMMAND             PAGING_REQUEST             
Downlink                   BCCH_INFORMATION           SYSTEM_INFORMATION 1-4     
Downlink                   SACCH_FILLING              SYSTEM_INFORMATION 5-6     

To cope with the connection-oriented BTSA, RR' must do some bookkeeping. It has to preserve the CEP_id and the related channel information every time BTSA sends information, so the correct CEP_id can be found via matching channels.

During channel assignment, MS sends a layer 2 pdu to the BTS, which RR' sees as a primitive from LAPM. RR' generates ESTABLISHMENT_INDICATION pdu, which is then transferred to BSC.

4.4.2.4 LAPDIF

LAPD-interface virtual vtask provides the data transfer service for MobSim-BTS's BTSM. When LAPDIF hooks itself to the VTL, it tells its index and the corresponding BSC index for addressing.

LAPDIF does not provide other services than data request and data indication.

4.4.2.5 LAPMIF

LAPM-interface virtual vtask provides the data transfer service between MobSim-BTS's RR' and MSs. When LAPMIF fires up, it reads the carrier number from the config file. LAPMIF provides data transfer and link establishment services.

4.4.2.6 GUIIF (GUI InterFace)

GUIIF-interface vtask connects to the Virtual Transport Layer. It received messages containing the received pdus from every protocol vtask. For each received message it sends a tracing message to active GUI-tools via the Virtual Transport Layer. The functions of GUIIF include:
- tracing messages handling service

The CVOPS implementation of GUIIF consists of:

4.4.3 Procedures in MobSim-BTS

The MobSim-BTS is totally controlled by its BSC. Everything it does is a result of a command from BSC, using BTSM protocol.


4.5 Base Station Controller (BSC)

MobSim-BSC consists of seven CVOPS virtual tasks (vtask). Three of them are protocol implementations (BSSAP, RR , BTSM), three are interface vtasks (SCCPIF, LAPDIF, GUIIF), and one is a MobSim-BSC application vtask (BSCA). Figure 8 presents the structure of MobSim-BSC.

Figure 8: Structure of MobSim-BSC

4.5.1 Invoking MobSim-BSC

When MobSim-BSC is started, it behaves like a normal CVOPS system similar to that described in chapter 4.4.1. When the vtasks of MobSim-BSC are initialised, they read the general Mobsim configuration file. MobSim-BSC needs to know the host name and the IP port number of the Virtual Transport Layer . It also needs information of the network addresses of itself and the MSC it is connected to. Further, it needs to know the indices of the BTSs , which it controls. In order to find out the name of the configuration file, it checks the environment variable named MOBSIM_CONFIG, which should contain it. MobSim-BSC needs also knowledge of its own index in the file. The index must be given in the environment variable named MOBSIM_BSC_INDEX. See chapter 3.1 for more information and an example configuration file. For example, the MobSim-BSC with index 10 can be found in the file, and there exists an MSC for it also. If either of the environment variables is absent, or if MobSim-BSC cannot find the information it needs from the configuration file, a short error message is given and MobSim-BSC then exits (see Troubleshooting MobSim-BSC).

After MobSim-BSC has successfully read the needed information from the configuration file, all of its interface vtasks try to connect to the Virtual Transport Layer. Again, if there happens some error during making the connections, a short error message is given and MobSim-BSC exits (see Troubleshooting MobSim-BSC).

4.5.2 The structure of MobSim-BSC

MobSim-BSC is a relay element, with two different kinds of external interfaces defined in GSM specifications. This comes from the fact that a GSM BSC relays messages from MSC to MS via BTS. BSC also communicates itself with MS and BTS when it comes to the management of radio resources. The interfaces between the vtasks of MobSim-BSC are defined using the ASN.1 language. An interface is defined by a set of service primitives. The protocol data units (pdu) are passed within these service primitives. The protocol specific pdus are part of the protocol specification and are defined formally, whereas the service primitives are typically implementation-specific. The pdus need to be formally defined because they are eventually passed to the peer entity in the other network element.

All the pdus which are received and decoded are also sent to the GUIIF vtask. GUIIF decodes the pdu it receives, and sends a message to Virtual Transport Layer which routes the messages to the active GUI-tools. The message contains information of the sender and the receiver of the pdu and also an ASCII-form tracing of the contents of it.

CVOPS implementation of MobSim-BSC consists of seven CVOPS vtasks. Three of them are GSM protocol implementations (BTSM, RR and BSSAP), one has the conversion logic between A-bis and A interfaces (BSCA), and three are interface vtasks to MobSim-VTL (LAPDIF, SCCPIF and GUIIF).

4.5.2.1 BTSM (Base Tranceiver Station Management)

BTSM-protocol handles the A-bis interface between BSC and BTS [GSM 08.58]. The functions of BTSM include:
- activation and deactivation of radio channels
- system information broadcast
- activation of ciphering
- paging service
- conveying pdus of the upper layers

The CVOPS implementation of BTSM-protocol consists of:

4.5.2.2 BSSAP (Base Station System Application Part)

BSSAP-protocol handles the A interface between BSC and MSC [GSM 08.08]. The functions of BSSAP includes:
- terrestrial circuit management
- paging service
- conveying pdus of the upper layers

The CVOPS implementation of BSSAP-protocol consists of:

4.5.2.3 RR (Radio Resources)

RR-protocol managed the radio resources [GSM 04.08]. The functions of RR includes:
- allocating and deallocating radio channels
- paging service
- system information broadcast
- relaying non-RR L3-messages to A-interface

The CVOPS implementation of RR-protocol consists of:

4.5.2.4 SCCPIF (SCCP InterFace)

SCCPIF-interface vtask provides the needed SCCP services [CCITT Q.711 - Q716] to upper layers. SCCPIF vtask connects to the Virtual Transport Layer, and uses the point codes of network elements for addressing. The functions of SCCPIF includes:
- SCCP connection-oriented services
- SCCP connectionless services
- addressing by means of network point codes

The CVOPS implementation of SCCPIF consists of:

4.5.2.5 LAPDIF (LAPD InterFace)

LAPDIF-interface vtask provides the needed LAPD services [CCITT Q.920 - Q921] to upper layers. LAPDIF vtask connects to the Virtual Transport Layer, tells its own index, and uses the index of the neighbour element for addressing. The functions of LAPDIF includes:
- LAPD information transfer service

The CVOPS implementation of LAPDIF consists of:

4.5.2.6 GUIIF (GUI InterFace)

GUIIF-interface vtask connects to the Virtual Transport Layer. It received messages containing the received pdus from every protocol vtask. For each received message it sends a tracing message to active GUI-tools via the Virtual Transport Layer. The functions of GUIIF includes:
- tracing messages handling service

The CVOPS implementation of GUIIF consists of:

4.5.2.7 BSCA (BSC Application)

BSCA-vtask is the application vtask of BSC. It relays messages from A-interface to A-bis interface. The functions of BSCA includes:
- relaying A-interface services to A-bis-interface services
- triggering inter-BSC handovers

The CVOPS implementation of BSCA consists of:

4.5.3 Procedures in MobSim-BSC

MobSim-BSC operates similarly as a real BSC like a relay element between MSC on one side and MSs plus BTSs on the other. BSC does not get involved directly in the procedures between MSC and MS. It merely gets instructions from MSC in BSSAP protocol, which is interprets, and acts accordingly. It also manages the radio resources of the BSS. The procedures in MobSim-BSC are:

4.5.4 Troubleshooting MobSim-BSC

BSC provides varius error diagnostics. Each time an error occurs a message is printed on the screen and BSC exits. The MobSim- BSC error list contains all error messages of BSC.


4.6 Mobile Switching Centre (MSC)

Mobile Switching Centre (MSC) is the central data repository of the mobile network. It also acts as the connection point between mobile network and normal phone networks, including other mobile networks. Of central importance in MSC is Home Location Register (HLR), which contains all data pertaining to Mobile Stations under this MSC's control. The area under one MSC's control is called a HLR area.

A real MSC always has Visitor Location Register (VLR) containing central information needed for operation of MS outside of their own HLR area. There is no VLR as such in MobSim, since it only simulates one MSC.

MobSim's MSC consists of five CVOPS virtual tasks. Three of these represent GSM protocols, one is an interface to the virtual layer (SCCPSIF), and one manages MSC. This management vtask we will call MSC Application (MSCA), or just Application. Application is responsible for bookkeeping, checking that called numbers make sense (number analysis) and simulating networks outside of MSC. Figure 9 presents the structure of MobSim-MSC.

Figure 9: Structure of MobSim-MSC

4.6.1 Invoking MobSim-MSC

When MobSim-MSC is started, it behaves like a normal CVOPS system similar to that described in chapter 4.4.1. When the vtasks of MobSim-MSC are initialised, they read the general Mobsim configuration file. MobSim-MSC needs to know the host name and the IP port number of the Virtual Transport Layer . It also needs information of the network addresses of itself. Further, it needs to know the indices of the BSCs which it controls. In order to find out the name of the configuration file, it checks the environment variable named MOBSIM_CONFIG, which should contain it. MobSim-MSC needs also knowledge of its own index in the file. The index must be given in the environment variable named MOBSIM_MSC_INDEX. See chapter 3.1 for more information and an example configuration file. For example, the MobSim-MSC with index 1 can be found in the file. If either of the environment variables is absent, or if MobSim-MSC cannot find the information it needs from the configuration file, a short error message is given and MobSim-MSC then exits (see Troubleshooting MobSim-MSC).

After MobSim-MSC has successfully read the needed information from the configuration file, all of its interface vtasks try to connect to the Virtual Transport Layer. Again, if there happens some error during making the connections, a short error message is given and MobSim-MSC exits (see Troubleshooting MobSim-MSC <href chapter Troubleshooting MobSim-MSC).

4.6.2 The structure of MobSim-MSC

The CVOPS implementation of MobSim-MSC consists of six CVOPS vtasks. Three of them represent GSM protocols (BSSAP, MM and CC), one is the user interface to MSC (MSCA) and two are interfaces to MobSim-VTL (SCCPSIF and GUIIF).

4.6.2.1 SCCPSIF (SCCPS InterFace)

SCCPIF-interface vtask provides the needed SCCP services [CCITT Q.711 - Q716] to upper layers. SCCPIF vtask connects to the Virtual Transport Layer, and uses the point codes of network elements for addressing. The functions of SCCPIF includes:
- SCCP connection-oriented services
- SCCP connectionless services
- addressing by means of network point codes

The CVOPS implementation of SCCPIF consists of:

The purpose of SCCPS vtask if to connect MSC to BSCs under its control. SCCPS routes messages between MSC and BSC according to SCCPS addresses, which consist of a pair of a point code and a subsystem address. Every MSC and BSC has its own point code, which is defined in the MobSim configuration file.

Upon reception of SCCPS connection-oriented message (location updating, mobile originated call, paging response), SCCPS decodes it long enough to find out the calling and called address and reserves a connection between these. Hereafter all data messages pertaining to this connection will use this connection. SCCPS disconnect message frees the connection.

A Special case in SCCPS is paging, which is handled as connectionless data. Paging requests are sent to all BSCs as unit data. Upon finding the requested MS, the right BSC sends a normal SCCPS connection message - see paging response above.

4.6.2.2 GUIIF (GUI InterFace)

GUIIF-interface vtask connects to the Virtual Transport Layer. It received messages containing the received pdus from every protocol vtask. For each received message it sends a tracing message to active GUI-tools via the Virtual Transport Layer. The functions of GUIIF include:
- tracing messages handling service

The CVOPS implementation of GUIIF consists of:

4.6.2.3 BSSAP (Base Station System Application Part)

BSSAP-protocol handles the A interface between BSC and MSC [GSM 08.08]. The functions of BSSAP include:
- terrestrial circuit management
- paging service
- conveying pdus of the upper layers

The CVOPS implementation of BSSAP-protocol consists of:

The duties of BSSAP include communication between MSC and BSC plus transmitting data to MM and CC. BSSAP connection is started by BSC closed by the MM protocol. Paging data goes through the BSSAP entity automaton as connectionless data.

BSSAP receives two kinds of messages from the DOWN interface: SCCPS_Conn_Ind (connection primitive, which also contains the first PDU) and SCCPS_Data_Ind. They are decoded as follows:
1. Decode as BSSAP_Msg
2. If transparent bit is set to zero, this is a BSSAP message, which is decoded further
3. If transparent bit is non-zero, MM connection is created and BSSAs_Compl_L3_Info service primitive containing the message is sent to MM

Encoding in BSSAP follows an analogous procedure in reverse direction. Messages to peer interface are marked as transparent=0, whereas Layer 3 data received in BSSAS_Data_Req is marked as transparent=1. Besides this encoding and decoding procedure BSSAP does not do significant processing, it mainly transmits data to Layer 3.

MSC performs paging by first transmitting IMSI to BSSAP protocol, which in turn checks HLR for the LAC of this the MS corresponding to this IMSI. With this LAC, we can find the network config file the BTS to which the MS has recently been connected to. In the network configuration file we can find the BSC and its point code which controls this BTS. After these searches we are ready to send Paging Request to (presumably) right BSC - see Chapter 4.6.3 for a flow chart of this procedure.

4.6.2.4 MM (Mobility Management)

The main function of the MM is to support and control the mobility of Mobile Stations [GSM 04.08]. MM protocol in MSC also manages HLR, the Home Location Register. The functions of MM include:
- HLR management (location updating, CM service checks...)
- MM connection management procedures
- Transmitting pdus to the upper layers

The CVOPS implementation of MM-protocol consists of:

The role of MM protocol in different MobSim-MSC procedures is described in chapter 4.6.3.

4.6.2.5 CC (Call Control)

The functions of CC include [GSM 04.08].:
- call establishment services
- call clearing services
- call information phase services

The CVOPS implementation of CC-protocol consists of:

4.6.2.6 MSCA (MSC Application)

The functions of MSCA are
- simulate networks outside of this GSM network
- number analysis
The simulation of the outside networks is achieved through a simple user interface providing the following commands to the user:

The CVOPS implementation of MSCA consists of:

4.6.3 Procedures in MobSim-MSC

Here we will present the steps taken by MSC as a whole during MobSim's various tasks using flow charts.

4.6.4 Troubleshooting MobSim-MSC

MSC provides varius error diagnostics. Each time an error occurs a message is printed on the screen. Some of the errors are so severe that they cause MSC to exit. The MobSim- MSC error list contains all error messages of MSC.


5. References

The following material might prove useful in working with MobSim: