Using the SAS System to show traffic load in a mobile telephone network.

Backg:round.

Mikael D. Aagaard Sonofon, Dansk MobilTelefon liS.

Sonofon, Dansk MobilTelefon IIS, is the first private owned Danish mobile telephone company.

Sonofon is implementing the new, cellular, European GSM system in Denmark.

The network consists of af number of sites, placed on pre-planned locations, to give optimum performance and coverage for mobile telephones. The optimum position for a site is selected by the aid of a computer design tool, Planet.

Depending on configuration, each site consists of one to three cells, each with one or more transceivers.

To keep track of the traffic load on each cell, different parameters are measured. Load parameters can be: how many calls are placed and how much airtime they create, how are the failure rates according to the load, how are the succes in managing calls and how much the congestion are on the different channels. Congestion is defined as the frequency with which a user is not able to complete a call. Either because the call has to be repeated or because he or she must wait for service until the necessary radiochannels are free. There are different possibilities to detect congestion. One possibility is calculating the percentage of congestion, based on the knowledge of how much traffic each cell can carry. This is all based on the erlang-b formula, that gives the percentage of congestion according to the no. of channels in the cell and the traffic load. Another possibility is to monitor how many channels are in use and for how long time, if all channels are in use, there is a possibility of congestion.

It is obvious that congestion has to be kept as low as possible at all times, to maintain a satisfying grade of service in the network.

643

__ ~ ________ r· __ ",." _ Jr _ '

-. --- - " ,y ~-.;.:".-~~"'-.~-~-:.:~-:-~.~--:.:..~:~--- -." • ~ -

SDNDFDN Gsr:r.r

~OFON Gsr:r.r

To keep track of the performance of the GSM-network, the SAS system is used to process the raw data, make reports on each cell and make graphical presentations.

Overview of data collection and presentation.

Billing( call records):

Record of each call(time, duration etc.)

I I

Compression into SAS® dataset. All calls in a given quarter of an hour collected into one value/quarter/cell.

Calculating the four consecu-

Planet(radioplan.) :

Configuration of each cell (orientation, config.),

I I

converting to temp. SAS dataset, calculating start angles, for cells, converting Planet coor­dinates to SAS coordinates.

tive busiest quarters of an hour------------- I total traffic in a I given week. I

Calculating the most congested ------------ I

I I I

cells. I I I I

Find trend of traffic compared to----------- I last week for each cell. I

OMC

ORACLE database( congestion, failures, succesrates)

I

Using SAS/ACCESS® & SAS/CONNECT ® to extract data from database.

Compressing data into weekly meas­surements. Measurements of congestion, quality in the network and busyhour.

I I I I I I I I I I

Merging Planet, Billing and OMC data ----­on a cell to cell basis.

Using annotate to place cells, show quality, traffic, trends and congestion.

Using PROC GMAP to draw DK-map, annotating cells etc. to map.

644

Data collection:

Data are collected from different sources, as shown above. One source is the billing system, where the calls are registered. Each call is registered with a start time, an end time, who made the call, where the call took place (that is the site and sector of the site) and several other parameters. Data are in ascii format and are transported, from a Digital V AX where they are stored to a HP9000 workstation where they can be accessed directly by SAS, using a standard INPUT statement.

The second source is the OMC-database(OMC = Operations Maintenance Center). Data resides in an ORACLE database placed on a HP9000 workstation. Data are collected from all parts of the telephone network by specially designed software and transferred to the database. From the database it is possible to access information concerning parameters like: Handovers(the transfer of a call from one cell to another), the setup of a call(that is the establishment of the necessary communication parameters), different error situations and why they occured etc. Data are accessed using views and PROC SQL. Statements are remote submitted from the PC to a HP9000 workstation through SAS/CONNECT, This workstation is connected to the workstation where the ORACLE database is installed using SAS/ ACCESS to ORACLE.

The third source of information, is the network design tool(Planet). From here information about the geographical placement and the exact configuration of each site is collected. Data are stored in ascii format on a SUN workstation. Since the amount of data in this database are rather small, about 350 records, they are transported to the local PC for converting.

Reducing data:

Billing data.

Currently the raw data from the billing system are growing up to about 400 MB per week. So to be able to do calculations and analysis, data have to be reduced considerably.

The main issue of interest is the busy hour in every cell in the network. The busy-hour is defined as the four consecutive quarters of an hour with the highest load. This could be traffic(airtime) generated by calls taking place, or congestion on different channels. These parameters are calculated on a weekly basis and the busiest hour is found. The busy hour is especially interesting because the network has to be dimensioned to handle worst case situations. The reason beeing, that even in busiest part of the day, users should not experience any noticeable congestion Besides this, the source of the calls are tracked mobile originated, mobile terminated, roaming or call forwarded and if the calls were made by SONOFON employees.

If a call extends from one quarter of an hour into another, the call has to be split into the two

645

ff-:9-:'-~~~h"'h~:>_~-=..~03~~.::-.~~~t:~..,':c:--=-: ': ~'" ~-'.'~' ,~

1

quarters. This is is done so that the call itself is only registered in the fIrst quarter, but the time the call lasts is split between the two quarters.

To minimize the possibilty of loosing the call-record for a given call totally, because of network errors etc., a new call-record is made by the switch every 10 minutes. This of course is not a new call, so only the time is registered and appended to the call.

The SAS dataset containing the reduced data, consists of an observation for every celV15 min. for a week. The size of this dataset is about 20-25 MB, so there is reduction of data by a factor 20.

OMC data.

As mentioned earlier OMC data resides in an ORACLE database. The amount of data collected in this database are very large, data are uploaded to SAS and processed weekly. Data in the OMC database are typically -saved for every hour for most the important parameters, other parameters can be gathered on request.

As with the billing data the hour with the biggest load is selected for every cell. The loads in this context being different sorts of congestion. Along with the congestion handover success, quality in setting up calls and perfomance of calls are calculated as averages. These values are saved in SASdatasets for later use in analysis.

The data from the OMC are particularily important because they hold information about all aspects of the network. These different sorts of errors, congestion and performance of cells and network, gives us the possibilty to track cells or areas that behave strange or areas/cells that work extremely well. This again gives us the ability to see what parameters are not correct and what parameters are optimal giving the possibility to correct and fore see future errors.

The amount of data processed at present is about 60 MB a week. These data are reduced to about 1 MB of SAS data, because only the worst case situations are saved.

The busy hour:

To fInd the busy-hour, ie. the hour with the highest airtime value from billing data, only very few SAS statements are needed. The statements s.hown here are those necessary to fInd the busy-hour, the rest of the program is merely steps to prepare data for presentation. To fInd the busy-hour in the OMC-data the approach is similar. PROC MEANS provides the ability to fInd the maximum value of a given variable and the matching time by the use of the MAXID statement. The MAXID statement combines the max. value of airtime with the busiest hour in the week.

646

------------F"" :~:J~/.::::. .. __ -~~;:..-:.;_~~~_~_ "_

FORMAT FAKTOR DATETIME18.;

IF KV ARTl=15 THEN FAKTOR=DHMS(CH_ST_DT,H_OF _D,OO,OO); IF KVARTl=30 THEN FAKTOR=DHMS(CH_SLDT,H_OF_D,15,OO); 1. IF KVARTl=45 THEN FAKTOR=DHMS(CH_ST_DT,H_OF _D,30,oo); IF KVARTl=60 THEN FAKTOR=DHMS(CH_ST_DT,H_OF _D,45,oo); CELL_GR = FLOOR(CELL_ID/lO);

STEP3 = FAKTOR-LAG3(FAKTOR); STEP2 = FAKTOR-LAG2(FAKTOR); 2. STEPI = FAKTOR-LAG1(FAKTOR);

BESTlQT=LAG(TIM_SPLl); BESTIQT=LAG2(T1M_SPLl); 3. BEST3QT=LAG3(TIM_SPL 1);

IF STEPI NOTIN (,00:15'T 'OO:30'T '00:45'T) THEN BESTlQT=O; IF STEP2 NOTIN (,00:30'T 'OO:45'T) THEN BESTIQT=O; 4. IF STEP3 NE 'oo:45'T THEN BEST3QT=O;

BEST4QT = TIM_SPLl+BESTlQT+BEST2QT+BEST3QT; 5. UGE = INTCK(,WEEK', 'OlJAN94'D, CH_ST_DT-l);

PROC MEANS MAX DATA=FIND_4QT NOPRINT NWAY; 6. V AR BEST4QT; OUTPUT OUT=FOUND4QT MAX(BEST4QT)=MAX_ 4QT MAXID(BEST4QT(FAKTOR »=MAX_HOUR; CLASS CELL_ID;

1. Time values in the reduced dataset are changed to a SAS datetime format, this makes them easier to process.

2. The variables STEPI-STEP3 are to be used for checking the validity of the busy-1m

3. Find the 3 preceeding values, 15 min. intervals, of airtime.

4. To check the validity of the value that where found in 3. STEPI-STEP3 are used to check if data are consistent. If this was not done a situation like the following could occur.

Record 1.

Record 2.

date time value of the record: 19940312103000

2: 15 hours between the to values. 19940312124500

Since the values are valid, the airtime would be added making values uncorrect. For that reason the values have to be in the given interval, else the airtime value should be zero.

5. Summing up the individual values to an hour value.

6. The MEANS procedure makes it possible to find the busy-hour and the associated airtime. One value per cell per week is found. The values are stored in a permanent SAS dataset for later use.

647

", ".1.

i ~ 1 I",

Presenting data:

P-DFDN Gsr:r.r

As mentioned earlier data are presented in tabular and graphical form. There is a trend towards more and more use of graphs instead of tables, the reason being that it is easier to get an an overview with a graph than with a table.

Below there are two examples of tables that presents different sorts of traffic load. The fIrst shows the busy hour measured as airtime, based on billingdata (fig. 1).

The second tells us something about different types of congestion and when the hour with max. congestion occured (fig. 2).

As it is clearly seen it is not easy to get an overview of all the cells, the tables are more usefull when you want to see the exact performance of one or very few cells. So to pinpoint trouble areas or trouble cells graphs are used, after that tables are used to see if it is possible to explain the cause of the problem. There are often a relationship between problems in a whole area and a few cells making all the trouble.

Fig. 1

CALL MINUTES (CM) IN MOST BUSY HOUR, 11APR94 TO 17APR94

(1) (2)

(3)

* OF CAR-

(4)

RIE- HIGHEST RS 4QT, CM

(5)

LAST WEEK, HIGH.

4QT

(6)

% OEV. FROM LAST WEEK

(7) (8)

% OF CM IN BUSY

TOTAL CM HOUR -----------------------------~---+----+--------+--------+-----+----------+-----CELL_IO BUSY HOUR, START ---------------- AT XX001:1 ----------------

12APR94:15:00 2 425:59 381:30 11.7 3758:56 11.3 ----------------+----------------+----+--------+--------+-----+----------+-----YY004:1 112APR94:15:15 I I I I I I

2 376:03 350:59 7.1 3265:07 11.5 ----------------+----------------+----+--------+--------+-----+----------+-----YY004:2 117APR94:21:30 I I I I I I

2 174:13 203:07 -14.2 921:34 18.9 ----------------+----------------+----+--------+--------+-----+----------+-----YY004:3 114APR94:13:45 I I I I I I

1 181:11 172:21 5.1 1486:53 12.2 ----------------+----------------+----+--------+--------+-----+----------+-----ZZ005:1 114APR94:09:45 I I I I I I

2 202:10 185:16 9.1 1656:00 12.2 ----------------+----------------+----+--------+--------+-----+----------+-----ZZ005:2 111APR94:13:30 I I I I I I

2 183:17 228:13 -19.7 1578:28 11.6 ----------------+----------------+----+--------+--------+-----+----------+-----ZZ005:3 111APR94:13:00 I I I I I I

1 136:40 131:28 4.0 1160:59 11.8 ----------------+----------------+----+--------+--------+-----+----------+-----

\ TT006: 1 I 13APR94 : 13: 15 I I I I I I " 2 131:35 109:36 20.1 638:42 20.6 ~---------------+----------------+----+--------+--------+-----+----------+-----TT006:2 112APR94:15:30 I I I I I I

2 238:28 178:59 33.2 1557:30 15.3

648

(1) The name and the id no. of the cell.

(2) When did the busy hour start.

(3) No. of carriers tells something about the capa­city of the cell.

(4) How many min. of airtime in busy-. hour

(5) How many min. of airtime in last weeks busy hour.

(6) % deviation from last weeks busy hour.

(7) The total airtime this day.

(8) % of airtime in busy hour, dep­ends very much on the total load of the cell.

~

Fig. 2

uge 16

(1) (2) (3)

(4) (4) (4) (5)

Answer I I MS t~ Location ori~ina-lsDCCH

pag~ng update t~ng congo

(5)

TCH congo (rej. req.)

(5) (6) (6) (6)

TCH Max. for sdcch Max. for TCH Max. for TCH congo congo rej. req. congo

----------------------------+--------+--------+--------+------+------+------+----------------+----------------+----------------MSC IBsc ICELL_ID I I I I I I I I I

~~h-----i~~h;----i~i~~~----- 0.182 0.331 0.281 3.060 0.000 7.670 18APR94:18:00:29 18APR94:01:00:24 19APR94:15:00:29 -----------+--------+--------+--------+------+------+------+----------------+----------------+----------------

50991 I 0.0471 0.5701 0.1331 5.1001 0.0001 0.000119APR94:19:00:28118APR94:01:00:24118APR94:01:00:24 ---------+--------+--------+--------+------+------+------+----------------+----------------+----------------50992 I 0.0691 0.6611 0.100124.8901 0.007149.620120APR94:18:00:29121APR94:11:00:29121APR94:11:00:29 ---------+--------+--------+--------+------+------+------+----------------+----------------+----------------50993 I 0.2401 0.2401 0.3401 3.0601 0.0001 0.000118APR94:12:00:29118APR94:01:00:24118APR94:01:00:24 ---------+--------+--------+--------+------+------+------+----------------+----------------+----------------57600 I 0.1261 0.4371 0.2181 3.3301 0.000148.690120APR94:18:00:29118APR94:01:00:24121APR94:11:00:29 ---------+--------+--------+--------+------+------+------+----------------+----------------+----------------58611 I 0.1071 0.2501 0.2861 2.3601 0.0001 0.000118APR94:11:00:28118APR94:08:00:28118APR94:01:00:24 ---------+--------+--------+--------+------+------+------+----------------+----------------+----------------58612 I 0.1931 0.1931 0.3511 1.2201 0.0001 0.000119APR94:12:00:29118APR94:01:00:24118APR94:01:00:24 ---------+--------+--------+--------+------+------+------+----------------+----------------+----------------58660 I 0.0891 0.1961 0.4021 3.7401 0.0001 7.3ooI22APR94:22:00:27118APR94:01:00:24120APR94:16:00:29 ---------+--------+--------+--------+------+------+------+----------------+----------------+----------------70121 I . I . I . I 0.0001 0.0001 0.000118APR94:01:00:24118APR94:12:00:29118APR94:01:00:24 ---------+--------+--------+--------+------+------+------+----------------+----------------+----------------70122 I . I . I . I 0.0001 0.0001 0.000118APR94:01:00:24118APR94:08:00:28118APR94:01:00:24 ---------+--------+--------+--------+------+------+------+----------------+----------------+----------------70123 I 0.2971 0.2161 0.1351 2.6101 0.00014.28E7118APR94:14:00:29118APR94:07:00:26119APR94:12:00:29 ---------+--------+--------+--------+------+------+------+----------------+----------------+----------------70331 I . I . I . I 0.0001 0.0001 0.000118APR94:01:00:24118APR94:08:00:28118APR94:01:00:24 ---------+--------+--------+--------+------+------+------+----------------+----------------+----------------70332 I . I . I . I 0.0001 0.0001 0.000118APR94:01:00:24118APR94:09:00:28118APR94:01:00:24

(1) +(2) MSC and BSC are switching centers, that administers calls and directs them to other mobiles or to the PSTN.

(3) This the id. no. of the cell.

(4) This tells something about the SDCCH (Slow Dedicated Control CHannel) channel usage in busy hour.

(5) Different sources of congestion in busy hour

(6) When did the different sources of congestion take place.

~ a 1iJ'1I ma ~2

;

/1

.. 't'

e.DFDN Gsr:r.r

To accomodate the need for an effective way to present data, a program was constructed to show all sites/cells placed on a map of Denmark. The program is written as two macroes. One macro to control what is to be shown, that is the legend, the limits and the correct title. The other macro is the program the makes the graph.

This makes it easy to create a new graph when there is a need to see other types of network measurements. The only thing needed is to put the correct parameters in the first macro and the program can be executed

The program(macroes):

The control macro:

When the macro is called, the value of limit tells the macro what type of graph to select.

%MACRO OO_LIMIT(LIMIT);

* To be able to use the macro variables in both macroes they have to be made GWBAL;

%GLOBAL LlMI LlM2 LlM3 LlM4 LIM5 LlM6 TEXTI TEXT2 TEXTI TEXT4 TEXT5 TEXT6 TEXT7 TITLE FLAG FVI FV2 FV3 FV4 FV5 FV6 FV7 ANNOSIZE DATA_PIL; %LET ANNOSIZE=6;

*Color defInition, this color defInition is used for all types of graphs; %LET FVI='H0F096C8'; %LET FV2='HOC896C8'; %LET FV3='HOB47DFO'; %LET FV4='CREAM'; %LET FV5='GOLO'; %LET FV6='MAGENTA'; %LET FV7='RED';

*If Iimit=l we tell the macro that we want to show busy hour traffic (airtime); %IF &LIMIT = I %THEN %00;

*These 6 macro vars tell the graph program how to divide busy hour(airtime) values into groups; %LET LIMI = 3000; %LET LIM2 = 6000; %LET LIM3 = 9000; %LET LIM4 = 10800; %LET LlM5 = 13200; %LET LlM6 = 15000;

*These macro vars are used to make the legend, annotate statements in PROC GSLIDE; %LET TEXTl = 0 - 50 CM; %LET TEXT2 = 50 - 100 CM; %LET TEXTI = 100 - 150 CM; %LET TEXT4 = 150 - 180 CM; %LET TEXT5 = 180 - 220 CM; %LET TEXT6 = 220 - 250 CM; %LET TEXT7 = >= 250 CM; %LET TITLE = "TRAFFIC IN BusmsT HOUR, WEEK &UGE."; %END; RUN; %MEND;

"other possibilities"

650

~ ~ ~

". "-' ~',,;:"'",-.'~-':~'- - --" ~. ~ "~. ,-

To call the graph macro the macro needs to know the name of the dataset, the variable to use and the week to be shown.

The graph macro:

%MACRO DATAFANG(DATA]IL,BER_ VAR,UGE);

DATA DATA_FIL; SET &DATA_FIL;

WHERE UGE=&UGE; RENAME &BER_ VAR = D3 ALUE;

PROC SORT; BY CELL_GR CELL_ID;

*Input data from Planet database, to be able to place the sites and cells correct on the map; DATA SITES; INFILE IND MISSOVER; INPUT CELLE $1-5 SECT $ 9 EASTING 14-19 NORTHING 26-32 ALIGN 55-57 ANTEN $ 63-66;

*Changing coordinates from UTM 32 to SAS coordinates; SAS_X=(EASTING-441450)/I000; SAS_ Y=(NORTHING-6049944)/I000;

*Converting Planet cell id's to id's used in billing and OMC data; AREA = SUBSTR(CELLE,I,2); NUMBER = SUBSTR(CELLE,3,3);

SELECT (AREA); WHEN ('FN') CELL_ID=1 *(,2'IITRIM(NUMBER)IITRIM(SECT»; WHEN (' S1') CELL_ID=1 *(' I' IITRIM(NUMBER)IITRIM(SECT»; WHEN ('JD') CELL_ID=1 *('3'IITRIM(NUMBER)IITRIM(SECT»; WHEN ('BH') CELL_ID=I*(,4'IITRIM(NUMBER)IITRIM(SECT»; OTHERWISE; END;

PROC SORT; BY CELL_GR CELL_ID;

*To make PROC GMAP work we have to make a dummy value, because the only thing wanted is a map of Denmark with no; * values, values are added by annotate dataset; DATA DKFLYT; SET DKMAP.DANMARK; VAERDI=I;

DATA ANNOTATE; MERGE DATA_FIL SITES; BY CELL_GR CELL_ID;

*Define different parameters; LENGTH FUNCTION STYLE $8 TEXT $16 COLOR $8; RETAIN HSYS '3' XSYS YSYS '2' ST 'PSOLID'; IF CELLE=' , THEN DELETE; WHEN = 'A';

*Draw the lines that makes Copenhagen area "pop" out of the map; IF _N_ = 1 THEN DO; *Use _N_ because this is only done once; DO V=308 TO 428 BY 4; FUNCTION ='MOVE';X=280; Y=125.9375; ; OUTPUT; FUNCTION ='DRAW';X=V; Y=220; LINE=I; SIZE=.2; COLOR='LIGR'; OUTPUT; END; END;

~ontmued

651

./.i!::CFCN Gsr:r.r

'" Assigning colours to values according to limits given in control macro, makes possible to use different scales without changing the; *program ; IF D_VALUE < &LIMI THEN FV=&FV1; IF &LIMI <= D_ VALUE < &LIM2 THEN FV=&FV2; IF &LIM2 <= D_ VALUE < &LIM3 THEN FV=&FV3; IF &LIM3 <= D_ VALUE < &LIM4 THEN FV=&FV4; IF &LIM4 <= D_VALUE < &LIMS THEN FV=&FVS; IF &LIMS <= D_ VALUE < &LIM6 THEN FV=&FV6; IF &LIM6 <= D_ VALUE THEN FV=&FV7;

*some sites need to be moved in order not to block other sites; IF CELLE IN ( 'JDOO8' '10062' 'J0060' 'FNool' 'J0068' 'JD079' 'FNOlO' 'SJOI8') THEN 00; SELECT (CELLE); WHEN ('JOO6O') 00; START_Y=27S; START_X=I90; END; WHEN ('10008') DO; START_Y=2oo; START_X=190; END; WHEN ('J0079') DO; START_Y=18S; START_X=I90; END; WHEN ('10062') DO; START_Y=170; START_X=190; END; WHEN ('FNool') 00; START_Y=ISS; START_X=190; END; WHEN ('FNOlO') 00; START_Y=I40; START_X=190; END; WHEN ('SJOI8') DO; START_Y=170; START_X=224; END; OTHERWISE; END;

"'Draw a line from the correct position of the moved site to the new posistion; FUNCTION ='PIE';X=SAS_X; Y=SAS_Yi LINE=I; SIZE=.S; ROTATE=360; STYLE='PSOLID'; COLOR='BLACK'; OUTPUT; FUNCTION ='MOVE';X=SAS_X; Y=SAS_Y;; OUTPUT; FUNCTION ='DRAW';X=START_X; Y=START_Y; LINE=I; SIZE=.2; COLOR='BLACK'; OUTPUT; SAS_ Y=START_Y; SAS_X=START_X; END;

"'Place each site/cell according to coordinates, direction and angle; SELECT (SECTOR); WHEN (0,1) DO;

FUNCTION ='LABEL';X=SAS_X; Y=SAS_Y; LINE=I; SIZE=I; STYLE='SWISS'; TEXT=LEFT(PUT(CELLE,$S.»; COLOR='BLACK'; OUTPUT; FUNCTION ='PIE';X=SAS_X; Y=SAS_Y; LINE=I; SIZE=l.S; ANGLE=(STARTl); ROTATE=ROTl; STYLE=ST; COLOR=FV; OUTPUT; END;

*STYLE is always SOLID, COLOR is according to FV macro variables in control macro. TEXT is cell id as; *in Planet, looks like SJOOI; WHEN (2) DO;

FUNCTION ='PIE'; X=SAS-X; Y=SAS_Y; LINE=I; SIZE=l.S; ANGLE=(ST ART2); ROTATE=ROT2; STYLE=ST; COLOR=FV; OUTPUT; END;

WHEN (3) 00; FUNCTION ='PIE';X=SAS_X; Y=SAS_Y; LINE=I; SIZE=l.S; ANGLE=(ST ART3); ROTA TE=ROT3; STYLE=ST; COLOR=FV; OUTPUT; END;

OTHERWISE; END; RUN;

*Write the legend of the map; DATA DK_LEGND; LENGTH FUNCTION STYLE $8 TEXT $18 COLOR $8; RETAIN HSYS '3' XSYS YSYS '3' ; FUNCTION ='LABEL';X=12; Y=95; LINE=3; SIZE=8;COLOR='BLACK'; TEXT='Legend :'; STYLE=' SWISS' ;OUTPUT;

Continued

652

*Macro handles placement of legend items; *XI and Yl controls placement of legend, TEX takes the text from the control macro and use it for text in *the legend, FV takes color from control macro according to color scheme.; %MACRO WR_LEGND(Xl,Yl,TEX,FV); FUNCTION ='PlE';X=&Xl; Y=&Yl; LINE=3; SIZE=&ANNOSIZE;COLOR=&FV; ANGLE=O; ROTATE = 360; STYLE='PSOLID'; OUTPUT; FUNCTION ='LABEL';X=30; Y=&Yl; LINE=3; SIZE=&ANNOSIZE;COLOR='BLACK'; TEXT="&TEX"; STYLE='SWISS'; OUTPUT; %MEND;

%WR_LEGND(S,7S,&TEXT1,&FV1); %WR_LEGND(S,6S,&TEXT2,&FV2); %WR_LEGND(S,SS,&TEXT3,&FV3); %WR_LEGND(S,4S,&TEXT4,&FV4); %WR_LEGND(S,3S,&TEXTS,&FVS); %WR_LEGND(S,2S,&TEXT6,&FV6); %WR_LEGND(S,IS,&TEXT7,&FV7); RUN; DATA ANNO_SJ ANNO_DK; SET ANNOTATE;

*Data are divided so that values from the Copenhagen area, are placed in a seperate dataset, they are placed only on the enlarged; *Copenhagen area; IF CELL_GR IN (1011 1008 1007 1004 1002 1003 1001 1006 lOOS l00S 1014 1010 1013 1012

1016 1067 1021 1009 1046 lOIS lOS6) THEN DO;

*Size is adjusted, because Copenhagen area is enlarged; IF FUNCTION='PIE' THEN SIZE=SIZE*2; IF FUNCTION='LABEL' THEN SIZE=SIZE*2; OUTPUT ANNO_SJ; END; ELSE DO; OUTPUT ANNO_DK; END;

*Company Logo; PROC DATASETS LffiRARY=WORK; COPY IN=DATA OUT=WORK; SELECT DELFIN;

*Correct title statement, contolled by control macro; TITLE 1 TITLE 1 H=2 J=L C=BLACK &TITLE; *Pattem for dummy variable V AERDI;

PATTERN V ALUE=MSOLID R=200 C=WHITE;

*Draw maps, select correct areas to map etc.; PROC GMAP DATA=DKFL YT MAP=DKFL YT GOUT=DELFIN; IDKOMMUNE; CHORO VAERDI I DISCRETE COUTLINE--GREEN NOLEGEND ANNOTATE=ANNO_DK; RUN; TITLE I ' '; PATTERN VALUE=MSOLID R=200 C=LIGR; PROC GMAP DATA=DKFLYT MAP=DKFLYT GOUT=DELFlN; WHERE AMT IN (10 14 IS) OR KOMMUNE IN (181 20S 207); IDKOMMUNE;

*Selecting the area that forms the enlarged ; *Copenhagen area;

CHORO V AERDI I DISCRETE COUTLINE=BLUE NOLEGEND ANNOTA TE=ANNO_SJ; RUN;

*Make legend; PROC GSLIDE ANNOTATE=DK_LEGND GOUT=DELFlN; RUN;

continued

653

*Put everything together, save graph for later use; PROC GREPLAY TC=SASHELP.TEMPLT IGOUT=DELFIN NOFS GOUT=DATA.DICTRAF ; TEMPLATE DKSPEC; TREPLA Y 1 :GMAP 2:GMAPl 3:GSUDE 4:CGM; RUN; %MEND DATAFANG;

To make a graph like the one below, it is only necessary to submit the following two statements:

%DO _LIMIT(5);

%DATAFANG(OMC.AVG_LOAD,TCH_CON1,16);

MAX. CONGESTION DUE TO LACK OF RESOURCES, WEEK 18

,

The first statement tells the macro that it is "congestion due to lack of resources" that is to be displayed. The second tells macro no. 2 that the dataset is called A VG_LOAD, the variable to use is called TCH_CONI and the that data are from week 16.

The graph's are very effective to higlight areas that have high loads of congestion, traffic or other parameters of interest. Certain areas are known to have high loads, these are the Copenhagen area, where the roads go from JyUand to Fyn and around Aarhus. The reasons

654

,",":-, _-.-:'o.-',:"_-'_~ ___ 'J/'_-~',-'~ ~ • '''_' ~'J~ ~~ ,_ '

_ ~ ~--' ~ ___ ~~_. ~_ ~ • ___ JP~ ~~ ~_ ~ r ~ - -"" -... ~ .> -" -.-. -.. -~ ,'.r.:~ ::;'-~::'-;'~~';"_:.'~',.'J~~';~-_'_'~"-,-_

P-OFON Gsr:r.r

beeing either that they are business centres or heavy car traffic on the roads. As the load on the cells increase the problems with congestion etc. increases, so it is important to follow these areas closely. Another possibility is to detect cells or sites with strange behaviour, that is cells or sites that have lot of congestion, problems with handovers etc. even though there are no traffic on the cell or site. When such a cell or site has been detected it is possible to ask the OMC to do additional measurements to find the reason for the problem.

These two macroes makes it possible to follow the trend from week to week in parameters as different as handovers, congestion on different radiochannels, failures in different interfaces, ie. mobile to cell or cell to switch and failures due to changes in network configuring.

At the moment 15 different graphs are available, all the user needs to know is the name of the dataset, the name of the variable to be presented and the week that he or she wants to see.

"Future ideas."

When I wrote the abstract to this paper, I did not realise how close the future was. So many of the ideas I had at that time has become reality, that is why the title is in quotes.

One of the ideas was to move all reducing and manipulating of raw data to a workstation instead of a Pc. In doing so it would be possible to take advantage of the capabilities of the workstation, faster disk access and stronger CPU. What I did not realise at that time was the rate of growth in the amount of data to process. At the time the amount was around 200 MB a week, but now, four months later it is about 4-500 MB a week.

To be able to process this amount of data in a reasonable time the move has already been performed. The parts of the programs that processes the raw data are remote submitted to a HP9000 workstation and processed here. The processed data are either downloaded to the PC or accessed by remote library services to be presented.

To be able better to tune and adjust network parameters and discover erroneus cells, we planned to use OMC data extensively in graphs and tables. This project is already running , making graphs available to relevant people by the aid of the presentation screen in PROC GREPLA Y. The aim being to make the technical departement able better solve problems faster and maybe prevent new ones to appear.

It is obvious that in order to maintain a satisfying capacity in the network, cells have to be upgraded with extra transceivers now and then. To be able to do this in a safe manner and based on parameters like trend in traffic, amount of new customers and how customers behave, we have started to work with forecasting in SAS. This project needs to be investigated more to get reliable information. But the results until now looks good.

One thing is still future, integrating traffic data in an EIS. SONOFON will probably be

655

~~~_-,:.:s:""'''~:~~~:&''~"'h..~~~~~~~~~:...:--.;-'~-~,-------~.~~ . ~ ... ~ , 1 , 1

'\

/.i!::OFON Gsr:r.r

implementing an EIS system, it would of course be an obvious idea to implement the graphs and tables in such a system.

Conclusion:

What have been the main assets of using SAS to show traffic loads ?

- The ability to work work with large quantities of data; - To distribute dataprocessing to different platforms, without changing the code; - To access data from other sources directly from SAS;

The only drawbacks we experienced was when we installed the SAS/ACCESS product. This procedure seems to be a bit clumsy compared to other installation procedures in the SAS system. The other one is concerned with the very high rate of disk 110 when using SAS under Windows. This often slows things down even though the PC's are rather fast. I hope that this can be improved in later versions of SAS.

Aknowledgements :

Thanks to Bent Gabelgaard and Hanne Frandsen for their help in preparing this paper.

Authors adress:

SONOFON, Dansk MobilTelefon liS Mikael D. Aagaard Skelagervej 1, box 330 9100 Aalborg Denmark

Phone: +45 99 3672 12 fax: +45 99 36 70 70

SAS, SAS/ACCESS, SAS/CONNECT are registered trademarks of SAS Institute Inc., Cary, NC, USA.

SONOFON is a registered trademark of Dansk MobilTelefon liS.

All other brands and product names which appear in this paper are registered trademarks or trademarks of their respective holders.

656

,~.-.-~-~-~~-.~.--.~ ... " ... ~, ,,--.. ~. ~-, ~

• ':. ~.~~ .:.:" -:'.-'~ ~,~j'-;'..f~ c<_ ~ '. ~',- _.~. -_~'...:'-:: _._>~ ;/_-~.' ;;....'.:r:~ -.', - r: ,,;- J. '--:_._ --: "~-~.'''' _. -:.:,: : __ •