We give a formal definition of the scenario-format in this section. This definition is technical and may be hard to grasp at first glance. Before reading the definition, it can be helpful to have a look at the next section where the network Tiny is presented in scenario-format.
The basic concept is as follows. We use four keywords (FORMAT, GENERAL_INFORMATION, CELLS, CELL_RELATIONS) and curly braces ('{', '}') to break the file into sections and data sets. Data is given in fields. There are named and unnamed fields. Named fields are used, for example, for optional data entries. For named fields, the field's name precedes the data entry (separated by whitespace). All fields are typed and terminated by a colon (';').
It is possible to insert comments. A comment starts with a '#' and is terminated implicitly by the next line end. It is not possible to have comments within fields or between a field's name and the data entry. A comment has to be separated from a preceding entry by a whitespace. Furthermore, we use the following notation:
Each cell is identified by a unique cell_id. This cell_id is used when specifying cell relations and assignments.
Using the above notation and conventions, the format can be described as follows. (Some comments are inserted to indicate the meaning of the parameters where it is not clear from the discussion in the previous section.) We have a start section following "FORMAT" that contains information on the type of the format and the version of the format. This is useful for future extensions.
FORMAT { TYPE SCENARIO; VERSION 1.0; } GENERAL_INFORMATION { SCENARIO_ID name; [ANNOTATION text;] NETWORK_TYPE (GSM900 | GSM1800); SPECTRUM spectrum; [GLOBALLY_BLOCKED_CHANNELS (int)>=1;] CO_SITE_SEPARATION int; DEFAULT_CO_CELL_SEPARATION int; HANDOVER_SEPARATION (int)4; # BCCH->BCCH BCCH->TCH TCH->BCCH TCH->TCH [MINIMAL_SIGNIFICANT_INTERFERENCE double;] [MAXIMAL_TOLERABLE_INTERFERENCE double;] DEMAND_MODEL (ABSOLUTE | NORMALIZED_TRAFFIC); SITE_LOCATIONS bool; } CELLS { ( cell_idi { name; # site name int; # sector number double; # demand/traffic [LOC location;] [LBC (int)>=1;] [CCS int;] })>=0 } CELL_RELATIONS { ( cell_idi cell_idj { [H bool;] # handover [S int;] # separation [DA (double)<=2;] # downlink area-based interference rating # co- (and adjacent) channel interference [UA (double)<=2;] # uplink area-based interference rating # co- (and adjacent) channel interference [DT (double)<=2;] # downlink traffic-based interference rating # co- (and adjacent) channel interference [UT (double)<=2;] # uplink traffic-based interference rating # co- (and adjacent) channel interference })>=0 }
Next, we clarify what the types are.
A few comments are in place: We use a ``sparse'' format for presenting cell relations. An entry for a pair of cells has to be made only if at least one of the parameters is non-trivial. Considering that often less than 10% of all cell relations are non-trivial, this is a substantial saving of space. However, implementing a parser for files in this format is not straight forward. This can be taken as a drawback. Yet, this format is easy to extend, information is accessible to a human reader and can be grouped in a sensible way, and only one file has to be handled per scenario. These benefits outweigh the complexity of writing a parser--which can be done in collaboration.