BMS

Demo Application Design Document

Version 1.0 Pim Moerenhout

Introduction
The BMS (Broadband Mobility Suite) involves several systems as described in the BMS 1.0 Solution Architecture document. The BMS demo environment must reveal the activity of the handset and BMS systems. The BMS demo application described in this document will implement an application to show information and activity of the BMS systems. The demo application will show the activity on several screens, described in the BMS Demo and Testing Requirements A02 document. The information in the demo must demonstrate the defined use cases to new BMS customers.

Architecture
The most important design decision is the fact that all data needed to display the BMS state, is saved into a data layer. For this data layer, a common database (MySQL) is chosen. Using a database layer makes it possible to run the demo even without actual BMS systems. Some stubs could alter the data in the data layer, which will trigger events on the screens. The demo application is using is a typical Model-View-Controller (MVC) framework. The application GUI is the view of the model. The model is the logic in the application. The controller can be represented by the data layer. The data layer is filled by so-called collectors. The data collectors are responsible to collect information from the BMS systems and store this information into the data layer at regular intervals. The following picture shows the overview:

Systems
One (server) PC running Linux (Fedora Core 11), using KDE, will run the demo application, host the database and run the collectors. This PC is located in the Acision data centre. The displaying of the screens will be done by a separate PC, which is in the demo room. This displaying PC will connect via VNC to the server PC. The display PC can have multiple display interfaces, to connect multiple displays. This will limit the number of necessary PCs. The screens have a resolution of 1280 x 1024 pixels.

Software
The application will be developed with Qt (http://www.qtsoftware.com/), using the Python binding (PyQt). Only one application will be developed. Via the menu, the use case user to be displayed, can be chosen. By using the Python script language, it will make the application easily modifiable. The database for the data layer will be MySQL. MySQL is supported by Qt natively and by Java. The data is the data layer consists of several tables: Table User
Column Type Example ID TINYINT 1 Name VARCHAR(32) Bob Picture VARCHAR(255) bob.png Device VARCHAR(255) laptop.png Description TEXT Bob is a business user.. BundleID TINYINT 1=Mobility, 2=Business, 3=Budget MSISDN VARCHAR(20) 31652525252 The most important data in the BMSUser table is defined as:

ID 1 2 3 4 5

Name Bob (mobile) Bob (laptop) Chris Christina Tina

BundleID 2 2 1 1 3

MSISDN 31652526406 31654688783 31654688781 31654688782 31652526101

Table Screen
Column ID MenuName Description User1ID User2ID Column ID Name Description Icon TypeOfPlan QuotaHome QuotaHomeShared QuotaOnTheGo QuotaOnTheGoShared QuotaRoaming QuotaRoamingShared ServiceModem ServiceVoIP ServiceFTP ServiceP2P QoSHomeInside QoSHomeOutside QoSOnthegoInside QoSOnthegoOutside QoSRoamingInside QoSRoamingOutside QoSTimePeriodInside QoSTimePeriodOutside QoSTimePeriodStart QoSTimePeriodEnd BaseCost Column ID Type Label Description IpAddress Port Type TINYINT VARCHAR(255) VARCHAR(255) TINYINT TINYINT Example 1 Chris && Christina The couple Chris and Christina 2 = Chris 3 = Christina, or NULL

Table Bundle with all bundle data

Type INTEGER VARCHAR(255) TEXT VARCHAR(255) VARCHAR(32) INTEGER TINYINT INTEGER TINYINT INTEGER TINYINT TINYINT TINYINT TINYINT TINYINT INTEGER INTEGER INTEGER INTEGER INTEGER INTEGER INTEGER INTEGER TIME TIME DECIMALS(5,2) Example 1 Home Mobility (name of the bundle) homemobility.png Prepaid or Postpaid specified in kb 0=not shared, 1=shared specified in kb 0=not shared, 1=shared specified in kb 0=not shared, 1=shared 0=n/a, 1= available 0=n/a, 1= available 0=n/a, 1= available 0=n/a, 1= available specified in kb/s specified in kb/s specified in kb/s specified in kb/s specified in kb/s specified in kb/s specified in kb/s specified in kb/s in US Dollars currency

Table BMSSystem with BMS system information

Type TINYINT TINYINT VARCHAR(32) VARCHAR(255) VARCHAR(15) SMALLINT Example 2 2 PCRF PCRF 10.227.152.32 3434

Table BMSData
Column Type Example

ID BMSSystemID Occurred UserID KeyID ValueVarchar ValueInteger

INTEGER TINYINT DATETIME TINYINT TINYINT VARCHAR(255) BIGINT

1 (AUTO_INCREMENT, PRIMARY_KEY) 3 2009-08-14 23:23:18 3 2 22 22

Table BMSKey
Column Type Example ID INTEGER 1 Description VARCHAR(255) Bundle Home Used Label VARCHAR(32) Home Used ValueTypeID TINYINT 1=VARCHAR, 2=BIGINT The IDs used in the BMSKey table are defined as: ID Label Description ValueTypeID 1 Location Location 1 2 Home Bundle usage Home bundle actual usage in KB 2 3 OnTheGo Bundle usage On The Go bundle actual usage in KB 2 4 Roaming Bundle usage Roaming bundle actual usage in KB 2 5 Home Bundle size Home bundle actual size in KB 2 6 OnTheGo Bundle size On The Go bundle actual size in KB 2 7 Roaming Bundle size Roaming bundle actual size in KB 2 8 QoS Actual QoS in Kbps 2 9 Peak usage Peak actual usage in KB 2 10 Peak max Peak actual size in KB 2 11 Day Pass usage Day Pass usage in kB/s 2 12 Day Pass max Day Pass actual size in kB (0=not active) 2 13 Congestion Congestion color (green,amber,red) 1 14 Compression Compression (0/1) 2

Views will ease the retrieval of the data. For each BMS key, a view must be made. The following views can be identified: vw_Screens vw_Bundles vw_UserBundles vw_Locations vw_HomeBundle vw_OnTheGoBundle vw_RoamingBundle vw_HomeBundleSize vw_OnTheGoBundleSize vw_RoamingBundleSize vw_QoS vw_PeakBundle vw_PeakBundleSize vw_DayPassBundle vw_DayPassBundleSize vw_Congestion vw_Compression

 No hardcode configuration data will be build into the application. The MySQL IP address and authentication data must be given on the command line, or will be fetch from application settings (registry/.plist/.ini). The data collectors will be written in plain Java, running in Java JDK 1.6 Update 16. JDBC drivers are available for MySQL, Informix and PostgreSQL. The collector applications do not have a graphical user interface. A simple shell script will start them. They can be stopped by pressing Ctrl-C or kill the process. Each collector will output information to the standard out and standard error to interact with the operator. The following Java libraries are used: commons-lang-2.4 jna.jar jsch-0.1.42.jar mysql-connector-java-5.1.8-bin.jar The following C libraries are used: libAPIClient.so ACE Client API 64-bit shared library Apache Utilities Java Native Library wrapper Java Secure Channel SSH2 MySQL JDBC driver

User screens
The application displaying the screens for the user personae will be one application, capable of displaying different user screens. The different user(s) are selectable via the menu and must be selected before running the demonstration of the case demo. The menu will also have an option to start and stop the retrieval of the data from the data layer. For the layout of the user persona screens the following considerations are made: The user picture is located in the left upper corner. For couples, the pictures are located in the left and right upper corners. The device picture is displayed partially on the user picture. The static bundle name is displayed right to the first user picture, between the two user pictures when there is a couple active. The services (VoIP, P2P, FTP and /or modem) are displayed under the bundle name. A horizontal grayed line will divide the bundle data from the speed and system applied settings (congestion, compression, etc.) The dynamic data is displayed in appropriate groups (bundle usage/service/QoS/location/bill/compression). For data types which represent data usage, it is displayed in colored bars. Yes/No options, like the compression, are displayed with green and red coloring for ease of recognition.

Example of User Persona screen: