Академический Документы
Профессиональный Документы
Культура Документы
From our current data files, create a way to use it at the Hunter System, in the provided
Example Modules.
For this, we choose a module: 'Hunter Network'. This is the module that contains the
network physical data, stored in a standard table 'tbl_Network' in standard database
'Hunter_Network_DB.mdb' in the standard local directory 'C:\Hunter\Network\Database\'.
In our examples, we present data from a fictitious GSM and UMTS network.
These data are already available in the cited table, with the standard names of fields as
well!
For example, this table contains a field called 'LATITUDE', which contains the given Latitude
of each cell. It also has a field called 'LONGITUDE', with the given Longitude of each cell. It
has a field called 'ANT_AZIM' with the data of Antenna Azimuth of each cell, and so on, as
the fields shown below.
This is a very simple table with only a few fields needed for all the modules presented till
today.
For example, in module 'Hunter GE Network', the data in this table are treated, and a KML
file is generated. Each module was developed as a complete 'example', and uses these
sample data to obtain the final result. For example, the direction of plotted cells is
determined by our standard field 'ANT_AZIM', ie the azimuth of the antenna, and the
opening of the symbol is in turn defined by the value of field 'ANT_HBW'.
We know that such modules do not yet cover all your needs. But it is very important to
realize that serves to know and learn how to obtain such results.
For example, we still have no data 'Frequency' in this table. This is because we have not
published a specific example module for this purpose yet!
Anyway, you can play all existing modules, simply adjust its data, that is, put your data in
the standard Hunter format (mainly namings).
Lets see how to do this, using our module 'Hunter Network' as example.
To begin, let's assume that the physical data ('Network') of your network are available in an
Excel spreadsheet, with our specific format - for example with different names. For this, we
use the data (also ficticious) as shown below - in file 'MyCustomNetworkTable.xls'.
Note that the network data has the 'same' fields, with only the names of fields a bit different
(for example, in our sample table Latitude is given by the 'Lat' field, while our standard
table uses 'LATITUDE').
Our sample table still has some less fields (eg missing field 'ANT_HBW'), and a few more
fields (eg 'FREQUENCY').
Fields in red have not yet been demonstrated and / or used in example modules, and there
is nothing to do with them at this time.
Fields in blue are the most important, and will be used in our applications. For this, let's see
how the fit.
The same standardized table (and therefore the same fields and terminology) is used by
several other modules. In the specific case of our example, all Hunter Modules using
network physical data fetch data from this particular table.
This is done in a very simple way by Access - simply create a link for this table in the
modules where it is needed. This ensures, among other advantages, that all the output
data/report is always up to date, simply keeping updated a single table with data from our
network! In addition, whenever there is a change in the original - and only - table, such as
adding a new field to a new purpose / module, all links are already automatically updated,
sinbce our linked tables already reflect the changes carried out.
all the queries, codes and scripts that expect our standardized nomenclature. Anyway, you
have total freedom to use it the way want.
The great advantage of using the first option is that everyone wins with the standardization
that with time and with the publication of new modules, it is becoming even greater.
The number of worldwide Hunter Users grows every day, and increasingly we seek to unify
and standardize all the best practices used in all areas of Telecommunications and IT.
We point to the file name where to find our spreadsheet (in the case of this example, we
store the original worksheet in the same place where our underlying database is) (1). And
we chose the option of 'Link' (2).
After completing the Wizard, we have linked our spreadsheet. It's now like a 'table'.
In our database, rename the original table 'tbl_Network' to any one other name, eg
'tbl_Network (Original Expected Format used in HUNTER)'. This table is now NOT accessible
to all other modules. They expect a table called 'tbl_Network', and that is what we are
creating now.
For this, we'll create a query based on our Excel spreadsheet - that in turn, is linked with
our real data.
Note: Remember that all terms used have already been demonstrated in other tutorials, and
always keep repeating it would be redundant and unnecessary. If you have doubts, read
previous tutorials.
At this point then we need to define each calculated field, as appropriate. Let's do some step
by step, as an example.
We begin with the first field in our table: 'PLMN'.
This field does not exist in our Excel spreadsheet (although there should be). We have two
options: assign a value ('NA' or '') or the actual value ('MyPLMNName').
We chose to use the value 'NA' (1), even because we can change this later. Thus, we insert
the first field in the query. Running it (2), we have our 'table' with just the default field
'PLMN' (3).
Our next expected fields are 'MSC' and 'BSCRNC' - important ones, but also lacking in the
original spreadsheet.
Thus, we follow the same procedure, and assign 'NA' for them.
Note that our 'table' pattern is already taking shape - even if the field values are not the
best way possible - as they are not also present in our spreadsheet.
Note: The correct thing is to update these data in our original spreadsheet, and update
those references - instead of assigning the value 'NA' for example, apportioned the
corresponding field.
Let's continue. Next required field is 'sitePROP'. This is the field with the value of the
property, the physical location of our site.
In our original spreadsheet, this particular field does not exist, but the same is inserted in
its 'Site' field, the second character onwards. Then, simply create a calculated field
'sitePROP', extracting the values properly.
We could continue with this show until the end of the required fields (not many). But you
should have understood the procedure. It follows then, our query with all existing and
required fields in our standard.
That done, now we only need to put data from this query into a - 'new' - table
'tbl_Network'.
So, when executed, our table is created! (For ease of implementation, we create a new
macro 'Update_Network_with_MyData_RUN').
And done! All our other modules now have an updated table - with the actual data from our
network - from where they can fetch its data.
Remember that the modules were written as an example, and has the standard
results/outputs. These results are always being improved, as we demonstrate new modules
as well as we're updating existing ones.
The modules of the Roadmap, as well as modifications of its results are discussed by all
Hunter Users, and increasingly with the participation of all we will create all new modules
that can suit everyone.
Many other modules are being published gradually. This week for example, we began the
series of modules and algorithms for Performance / KPI Analysis. Do not miss out,
contributing at least with suggestions, so you help in the evolution of the system and the
benefits apply directly to you!
No problem, the procedure for adjustment is exactly the same: to bind its real data format,
and change the query that matches the fields. That's it.
Anyway, it's good you're back to work with the methodology as organized as possible.
Regardless of your network vendors, the results can be standardized, so getting all the
benefits mentioned above.