Loading...
 
Print

Documentation



Tutorial


Guidelines to NEM developers


There are two distinct sides in the deployment of a NEM instance
  1. related to which machines is the software of the NEM instance running.
  2. related to which equipments/services have to be managed by the NEM instance.

The side 1, is of a little importance regarding the NEM specs, as the NEM developer is free to do whatever he likes, the specs are imposing nothing related to that point more than stating in the manifest whether the NEM may need more than one machine to run (the isAtomic field).

The side 2, is far more important as the specs do specify this point. It is required that the URIs of the equipments/services to be managed are listed in the Mandate. So the whole rest of this text will deal with the deployment over managed equipments.

Hence the NEM developer must start with making an inventory of the kind of equipments that will be managed by its NEM. Basically, fit in the inventory the equipments that the NEM will be monitoring (more or less directly) or to which the NEM will send command (more or less directly). The equipments must belong to the operators and being manageable by the operator, as such the end-user equipments cannot be part of this inventory.

  • Directly can mean for example using SNMP to retrieve the value of a parameter (like an IP@).
  • Less directly may mean, sending command to a network manager which will forward the "roughly same" command to the final equipment (e.g. send to manager switch off the interface n°12 of router (@1.1.1.1), and the manager sends the corresponding SNMP command to the equipment). Be aware that the network manager or controller can also be part of the inventory if it is to receive commands from the NEM, especially if the command is a macro one, but this will be detailed later.

The NEM developer must make an inventory of the pieces of information used by its NEM. It can also classify these pieces of information according to whether those are directly monitored, or wished or required from another NEM.

Then he must associate to each of these pieces of information the equipment which would be the context of these pieces of information. To do so identify which is the first equipment managed by the operator which is accessing this information.
  • If the information is the emitted power by a WifiAP, it is likely that the context will be this WifiAP.
  • If the information is the power received by a terminal it is likely that the context will be the WifiAP to which the terminal is attached (though the monitoring device is the terminal, it is not managed by the operator, but it communicates first to the WifiAP this information.
  • The above information may be automatically transmitted to the manager/controller of the WifiAP, and the information may well be retrieved from this manager, the context will still be the WifiAP.
  • If the information is the number of users connected to a WifiAP, the context will be the WifiAP. In case multiple WifiAP are managed by a local manager, and all of them push this information to their local manager, this one may well compute the value corresponding to the local average number of users connected to the WifiAP. Then if a NEM retrieves this average value from the manager, the context will be the manager.

Achieving this inventory will help the NEM designer in determining its inventory of ManagementInfoSpecification. A ManagementInfoSpecification is describing a piece of information that is handled by the NEM, and as such it should be as atomic as possible, corresponding to what the NEM is actually capturing. A ManagementInfoSpecification contains 3 attributes/fields:
  1. A String named descriptor: which is used to identify the nature of the information, e.g. for the number of users of a wifiAP, it will be something like “APnbrOfUsers”. It must be commonly understood in the UMF system, meaning that wherever in the UMF system the same nature of information is referred the same descriptor must appear.
  2. A type identifier named type: which is used to identify how the information is encoded, e.g. for the number of users of a WifiAP this will be an integer.
  3. Another type identifier named contentType: which is used to identify the type of ManagementInfo that will be used to convey the information. SID information model is defining a whole hierarchy of ManagementInfo ranging from Alarms to Status Metrics, this attribute tells which of those to be used.

Then the NEM developer has to sort its inventory of ManagementInfoSpecification according to 3 categories:
  1. Acquired inputs: for the information that a NEM will be retrieving directly.
  2. Required inputs: for the information that a NEM needs to retrieve from the UMF environment and hence using Knowledge in order to get this information. If KNOW fails in providing this information (e.g. because no other NEM can acquire/create this information) then this NEM cannot reach the ready state (said another way the NEM cannot complete its registration, it is a bit like a plugin lacking the plugins it depends upon).
  3. Wished inputs: same as above but the NEM can work without being provided with this information.

To finish with the inventory of information, a NEM may (upon demand from KNOW) share some of the information acquired or some of the information produced, then the NEM developer has to complete the inventory with every piece of information produced, hence creating the possible output category:
  • Every acquired input is to be listed in the possible output.
  • For a knowledge building NEM, the built pieces of knowledge have to be listed.
  • For any NEM, any intermediate metric computed out of inputs may well be listed (e.g. a NEM achieving Handover optimization between multiple WifiAP may compute per WifiAP an access point load indicator out of multiple metrics, this information can be shared).
  • Finally, any action that a NEM may enforce is to have the corresponding piece of information listed as a possible output, this is a kind of report of the action performed (see in the following paragraphs related to actions for more details).

The NEM developer must also make an inventory of the kind of actions that may be enforced by its NEM.

Then he must associate to each of these actions the equipment which is the target of this information. To do so identify which is the last equipment managed by the operator which is executing this action.
  • If the action is setting the emitted power by a WifiAP, it is likely that the context will be this WifiAP.
  • If the same action is sent to the WifiController, which is actually pushing it to the WifiAP, the context will once again be the WifiAP.
  • If the action sent to the WifiController is “balancing a terminal from the controlled WifiAP 1 to the controlled WifiAP 3”, it is likely the context of the action is the WifiController, because the action is not directly sent to the WifiAP, but needs some routine to be performed in the WifiController, such as asking WifiAP 1 to release the terminal and asking WifiAP 3 to accept the terminal, and this possibly with some synchronization constraints.

Achieving this inventory will help the NEM designer in determining its inventory of ManagementActionSpecification. A ManagementActionSpecification is describing an action that may be enforced by the NEM, and as such it should be as atomic as possible, corresponding to what the NEM is actually executing. A ManagementActionSpecification contains 3 attributes/fields:
  1. A String named descriptor: which is used to identify the nature of the action, e.g. for setting the emission power of a wifiAP, it will be something like “APemittedPower”. It must be commonly understood in the UMF system, meaning that wherever in the UMF system the same nature of action is referred the same descriptor must appear.
  2. A Set<ControlState> named controlFlexibility: which is used to determine the range of possible ControlState that the NEM can manage over these kind of actions. The ControlState, can be ENABLED, DISABLED or INTERCEPTED, corresponding to how COORD can force the NEM not to enforce some actions.
  3. A type identifier named contentType: which is used to identify the type of ManagementAction that characterizes the enforced action. With similarity to the hierarchy of ManagementInfo, there is the possibility to use a hierarchy of ManagementActions, right now there is only ActionSetConfigOption type implemented.

To every ManagementActionSpecification corresponds a matching ManagementInfoSpecification and which will be listed among the possible outputs, for which the attributes will be:
  • A String named descriptor: same value as the one in the ManagementActionSpecification.
  • A type identifier named type: the proper value has to be identified (e.g. for setting the emission power of a wifiAP, the value will be numeric).
  • Another type identifier named contentType: the value will be InfoCfgSetting, as it is an information resulting from the enforcement of an action.

Having achieved these inventories will help the NEM developer in completing its Manifest, as for the following fields, the value will be:
  • ManageableEntities: the inventory of the equipments that can be managed by the NEM
  • Acquired Inputs: the list of ManagementInfoSpecifications corresponding to the first category determined above.
  • Required Inputs: the list of ManagementInfoSpecifications corresponding to the second category determined above.
  • Wished Inputs: the list of ManagementInfoSpecifications corresponding to the third category determined above.
  • Available Outputs: the list of ManagementInfoSpecifications corresponding to the additional category determined above (containing acquired inputs, intermediate metrics and actions results).
  • Possible Actions: the list of ManagementActionSpecifications corresponding the above inventory.

Then for the NEM to be deployed, the NEM developer has to understand that the UMF is generating a mandate, this one contains the list of equipments over which the NEM will have to deploy, the list of equipments over which deploying does not have to be homogeneous in term of equipments.
  • A NEM could well be deployed over WifiAP and corresponding WifiControllers.
  • A NEM could well be deployed over a set of routers and the ethernet switches interconnecting those.

The mandate is sent to the NEM instance which is comparing it to its current mandate (which may be non existing if the NEM was previously void_instantiated – meaning it had either never been deployed or it had been undeployed as the latest state-change). The comparison of mandate is meant to identify, equipments on which deploying and equipments from which undeploying. Then the NEM undeploys from the equipments no longer quoted and after that it deploys over the new equipments.
  • The NEMskin code is doing the identification of the 2 lists.
  • Then the NEMskin code is making successive calls to doUndeployFromEquipt
  • Then the NEMskin code is making successive calls to doDeployOverEquipt
  • Both these methods are abstract and must be implemented by the NEM developer when coding its NEM.

When deploying over new equipment, the NEM is supposedly initiating the communication with it.
  • e.g. opening the TCP connection to support the SNMP communication and issuing the SNMP credentials
  • e.g. retrieving initial values (as which is the current power set by the WifiAP), or what does this devices allows as a range for setting the power.
  • e.g. retrieving configuration information (how many interfaces are there on this router, where are those connected to, which of those are switched on)
  • e.g. identifying the model (a nem could deploy over WifiAP, but depending on the model, it may not be able to manage the same parameters, e.g. a Netgear WifiAP can activate a firewall, why a Soekris one cannot.

The previous step is required to help in building the instance description, as it describes how the NEM is being deployed (according to side2 of deployment).

The instance description is providing 4 lists of UMFInfoSpecifications. These ones are built from the association of the corresponding ManagementInfoSpecification and the list of corresponding URI representing the context of this piece of information.
  • If the NEM is deployed over 3 WifiAP (WifiAP_1, WifiAP_2 and WifiAP_3 the 2 first being Soekris, while the last one is a Netgear) and monitors the number of users on these access points there will be 3 UMFinfoSpecifications built out of the same ManagementInfoSpecification
  1. <UMFInfoSpec><descriptor>APnbOfUsers</descriptor><type>Integer</type><context>WifiAP_1</context></UMFInfoSpec>
  2. <UMFInfoSpec><descriptor>APnbOfUsers</descriptor><type>Integer</type><context>WifiAP_2</context></UMFInfoSpec>
  3. <UMFInfoSpec><descriptor>APnbOfUsers</descriptor><type>Integer</type><context>WifiAP_3</context></UMFInfoSpec>
  4. *If the same NEM is also monitoring the number of packets drop, which actually cannot be performed by Netgear machine, hence this information is not available on WifiAP_3, there will then be only 2 UMFInfoSpecification:
  5. <UMFInfoSpec><descriptor>APnbOfPacketsLost</descriptor><type>Integer</type><context>WifiAP_1</context></UMFInfoSpec>
  6. <UMFInfoSpec><descriptor> APnbOfPacketsLost</descriptor><type>Integer</type><context>WifiAP_2</context></UMFInfoSpec>

The instance description is also providing a list of NEMActionSpecifications. These ones are built from the association of the corresponding ManagementActionSpecification and the list of corresponding URI representing the context of this action.
  • Here the rules apply similarly to the ones for the UMFInfoSpecifications, there can be some actions which can only be performed on some of the manageable equipments but maybe not on all of them.

Achieving this work properly is useful as this will generate the Instance Description. This one is used for registering the NEM instance. This means:
  • KNOW needs to get the exhaustive list of information requested and available by any NEM. This is required to establish knowledge exchange between entities in the UMF system. (e.g. between a NEM producing some knowledge and another NEM using this knowledge).
  • COORD needs to identify all the control loops running in the system to detect conflicts between competing control loops. For this COORD needs the information handled by NEM instances and the Actions performs.
  • As COORD and KNOW needs to achieve match between UMFInformationSpecification (and/or NEMActionSpecification) coming from different NEM instances, those ones have to be both enough descriptive and commonly understood. Two NEMs manipulating the same parameter MUST describe this in an identifiable way, which is the reason, both the nature of the parameter and its context are required to avoid confusion.

For this purpose, it appears that a finer granularity than the equipment can be used for the context, i.e. equipment sub-sets which have a given durability in the network life-time, like an interface or a port, can be considered.
  • If a NEM deployed over a router is monitoring the load of the router ports:
  • The manifest could have:
  • <ManagementInfoSpec><descriptor>RtrPortLoad</descriptor><type>Numeric</type></ManagementInfoSpec>
  • The instance Description could have:
  • <UMFInfoSpec><descriptor>RtrPortLoad</descriptor><type>Numeric</type><context>Rtr@1.1.1.15:Port1</context></UMFInfoSpec>
  • <UMFInfoSpec><descriptor>RtrPortLoad</descriptor><type>Numeric</type><context>Rtr@1.1.1.15:Port2</context></UMFInfoSpec>
  • <UMFInfoSpec><descriptor>RtrPortLoad</descriptor><type>Numeric</type><context>Rtr@1.1.1.15:Port3</context></UMFInfoSpec>
  • <UMFInfoSpec><descriptor>RtrPortLoad</descriptor><type>Numeric</type><context>Rtr@1.1.1.16:Port1</context></UMFInfoSpec>
  • <UMFInfoSpec><descriptor>RtrPortLoad</descriptor><type>Numeric</type><context>Rtr@1.1.1.16:Port2</context></UMFInfoSpec>
  • <UMFInfoSpec><descriptor>RtrPortLoad</descriptor><type>Numeric</type><context>Rtr@1.1.1.16:Port3</context></UMFInfoSpec>
  • In the NEMSkin, it is coded in a way that once deployed a NEM can respond to the following abstract methods, where the assumption made is that the doDeployOverEquipt has created the corresponding entries:
  • List<UMFInfoSpec> listAcquiredInputs()
  • List<UMFInfoSpec> listWishedInputs()
  • List<UMFInfoSpec> listRequiredInputs()
  • List<UMFInfoSpec> listNonObviousAvailableOutputs() (do not return there the same one as getAcquiredInputs)
  • List<NEMActionSpec> listActions()
  • In the NEMSkin, there is an abstract method which is used to retrieve the value of an information out of description, the abstract method is called either getInfo or CollectLocalInformation (to be settled soon in favor of CollectLocalInformation), the signature is the following:
  • UMFInfo CollectLocalInformation(UMFInfoSpecification infoSpecToRetrieve)

Additionally, it is currently accepted (at least for demos) that a mandate can have entries in the list of URI named managedEquipments corresponding to bundles of equipments.
  • This rule is all the more welcome when the NEM cannot run on a sub-set of the bundle.
  • E.g. if the NEM is achieving Handover optimization between a given set of neighboring WifiAP which are then controlled by a given WifiControler, the target in the mandate can be the WifiControler.
  • This does not mean that the context of the UMFInfoSpecification not the ones of the NEMActionSpecification will be the URI of the bundle, it must be the URI of the targeted equipments, and as such there should be as many context as needed.
  • This does not forbid that some UMFInfoSpecification may have for context the URI of the bundle (e.g. if the information is an output of the NEM which is the areaStabilityIndicator the URI of the area is better suited).

Installation guides


Latest SON Coordination Prototype


This is a short guide on building and running the latest SON Coordination prototype.

Prerequisites:


  • Matlab (2006 or higher has been tested) or alternatively Octave which is a GNU software that is interpreting matlab code
  • JDK 1.7 or higher
  • SVN client
  • Eclipse (optional)
Regarding the SVN details, have a look at this topic(external link).

Building the sources


First of all you need to svn checkout the sources; 9 (Eclipse) projects:

  • http://poseidon.ds.unipi.gr:8080/svn/repo/univerself/UMFCommon/
  • http://poseidon.ds.unipi.gr:8080/svn/repo/univerself/USelf-KnowInterface/
  • http://poseidon.ds.unipi.gr:8080/svn/repo/univerself/USelf-NEMskin/
  • http://poseidon.ds.unipi.gr:8080/svn/repo/univerself/PolicyTranslationModule/
  • http://poseidon.ds.unipi.gr:8080/svn/repo/univerself/Uself-UMF~CoreAndH2N/
  • http://poseidon.ds.unipi.gr:8080/svn/repo/univerself/Demo-Commons/
  • http://poseidon.ds.unipi.gr:8080/svn/repo/univerself/DemoCoord-Matlab/
  • http://poseidon.ds.unipi.gr:8080/svn/repo/univerself/DemoCoord-NEMs/
  • http://poseidon.ds.unipi.gr:8080/svn/repo/univerself/Demo-UMF/

Setting up the simulator


As soon as you are synchronized with the sources, you need to setup your Matlab or your Octave.

Octave seems slower but it is a free software and is roughly compliant with matlab code.

Option 1: Setting up Matlab


If you're having Matlab, first make sure that it is not running. Then, you need to prevent Matlab from loading its own xstream.jar. One way to achieve this is by commenting the entry in Matlab's classpath.txt file (static classpath). It can be found in <MATLAB root dir>/toolbox/local/classpath.txt. You need to comment the line regarding the xstream library using a hash <#> (e.g. prepend the line $matlabroot/java/jarext/xstream.jar with <#> like this: #$matlabroot/java/jarext/xstream.jar). Warning: if you open classpath.txt with Windows' notepad.exe, you'll notice it's a bit scrambled, which is because of Unix-style newline characters (\n). It is recommended to use another text editor like Notepad++. Alternatively, you can prevent Matlab from loading its xstream.jar by locating it (usually under <Matlab installation dir>/java/jarext/) and renaming it (pretty much anything like _xstream.jar will do).

Next, and if under a Windows system, you can try running Matlab using DemoCoord-Matlab\matlab\run.bat. If it works and the "Simulation View" window pops up you can jump to this step. In case that fails for any reason (one candidate reason is matlab.exe not found on your PATH), you need to create a shortcut to Matlab's executable that sets the working directory from the early boot. To do so, create a regular shortcut to your matlab.exe, and then set up its' properties as shown in the screenshot below (assuming R:\ as the root directory of your local copy of the projects where you checked out):

Image

Additionally you can make sure your matlab is using the proper version of java, for this set an environment variable in your system that will be named MATLAB_JAVA and which will contain the path to either a jre7 or a jdk7, something like: "c:\Program Files\Java\jdk1.7.0_40"

Option 2: Setting up Octave


To start with you need installing Octave, for this please refer to the installation page of Octave(external link).

Then you need to prepare Octave for running Java, for this you can refer to octave's wiki(external link), though the 3 essential steps are provided below:

Then you need to set an environment variable in your system that will be named JAVA_HOME and which will contain the path to a jdk7 (or higher - nota a jre is not enough), something like: "c:/Program Files/Java/jdk1.7.0_40", be carefull that even under windows you have to use / (slashes) instead of \ (anti-slashes).

Then you need to add to the paths of your environment variable named PATH the path of the bin dir of the same jdk, something like: "c:/Program Files/Java/jdk1.7.0_40/bin", be carefull that even under windows you have to use / (slashes) instead of \ (anti-slashes).

Then you can start Octave and in the command line type the following instruction:

chdir("path to matlab dir in DemoCoord-Matlab project")
To avoid repeating it each time Octave is started, you can place the above instruction in a .octaverc file that you will create in your homedir.

To start the simulator type in the command line:

newTest

Building the sources


Now it's time to build the sources. A java compiler compliance level of 1.6 is required. In Eclipse, that setting is located in Window->Preferences->Java->Compiler->Compliance Level. Again, if using Eclipse, it is preferred to BuildAll (dependencies are configured automatically using subversive), otherwise, you may use buildall.bat on Windows which "calls" each project's build.bat. There are also Ant files available for packaging distributable releases (see build*.xml files and dist/ folders).

Running the prototype


  • start Matlab from the shortcut created earlier
  • run USelf-NEMskin/umf.common.nem.weblaunch.NEMHost and minimize it (will hide in tray)
  • run Demo-UMF/uself.demo.DemoH2Ngui
(note that if you are running them manually, the working directory must(!) be USelf-NEMSkin and Demo-UMF for each case respectively).
If on Linux under window manager other than Gnome, please select yours in NEMHost settings.
Unless H2N and NEMHost are running on the same machine please have a look at these 2-3 simple configuration steps.

Also, in the case that H2N and Matlab are running on different machines, H2N needs the address of the matlab running-machine configured into Demo-UMF/config/rest.conf, property named "uself.demo.matlabws", where "localhost" should be replaced with Matlab's IP/Hostname.

Now to start the simulation, navigate to the "Network" tab, select "CellB", and press "Launch SImulation" from the top-left corner of the window. After a few seconds, plots should appear in the Java window of Matlab titled "Network View". Also, the "Launch Simulation" button should turn into "Kill Simulation" as soon as it's started.

Image

The next thing is to instantiate some NEMs. Back to the "NEM Classes" list (Governance->NEM Catalog), you may select ExtendedSONBackhaulOptimNEM and SONloadBalNEM and then click on "Instantiate Selected" (please note that at the time of this writing, SONBackhaulOptimNEM is discontinued). That should bring up two new java processes and change the H2N view to the Network tab, where the NEMs should appear on the right side.

In order to deploy these NEMs now, you may drag'n'drop them over the simulated cell "CellB" (which in this case includes the Femtos attached to it). Note that if you attempt to deploy a NEM over a non-simulated cell (gray ones) it will crash.

In order to make it more interesting then, you may want to unbalance the traffic in the simulator by running DemoCoord-Matlab/uself.demo.matlab.TrafficConfigurer. The effects should be immediately visible in the simulation view.

Two other things you can try:
  1. reset the traffic to initial, balanced load, by clicking the green refresh button in H2N->Network->LTE RAN to the right of the "Kill Simulation" button.
  2. disable the coordination mechanism by going to H2N->Coordination->Mechanism Assignment->Uncheck SONTimeSeparation (No: x)

The last action should introduce some noticable instabilities in the network (in the KPI window), but it also might not. If it doesn't, it means that the NEMs have converged to a sufficient degree. In the latter case, all you need to do in order to observe the effects of the non-coordinated SONs is to reset the traffic (using the aforementioned button) if you've already changed it using TrafficConfigurer, or vice-versa. So, that is, change the traffic distribution in any way.


More details on the SON functionality and the coordination mechanism can be found on the respective poster(external link), leaflet(external link) and presentation(external link) given to FUNEMS 2013.


FUNEMS13 SON Coordination Demo


This is a short guide on building and running the SON Coordination demo presented at FUNEMS 2013, Lisbon.

Prerequisites:

  • Matlab (2006 or higher has been tested)
  • JDK 1.6 or higher
  • SVN client
  • Eclipse (optional)

Regarding the SVN details, have a look at this topic(external link).

Building the sources


First of all you need to svn checkout the sources:
  1. If you don't plan to modify, develop on top of this prototype, or if you don't use Eclipse,
svn checkout http://poseidon.ds.unipi.gr:8080/svn/repo/univerself/branches/funems13/(external link)
  1. Otherwise you may checkout each of the 8 Eclipse projects independently:
  • http://poseidon.ds.unipi.gr:8080/svn/repo/univerself/branches/funems13/U...
  • http://poseidon.ds.unipi.gr:8080/svn/repo/univerself/branches/funems13/U...
  • http://poseidon.ds.unipi.gr:8080/svn/repo/univerself/branches/funems13/U...
  • http://poseidon.ds.unipi.gr:8080/svn/repo/univerself/branches/funems13/U...
  • http://poseidon.ds.unipi.gr:8080/svn/repo/univerself/branches/funems13/D...
  • http://poseidon.ds.unipi.gr:8080/svn/repo/univerself/branches/funems13/D...
  • http://poseidon.ds.unipi.gr:8080/svn/repo/univerself/branches/funems13/D...
  • http://poseidon.ds.unipi.gr:8080/svn/repo/univerself/branches/funems13/D...


Setting up the simulator


As soon as you are synchronized with the sources, you need to setup your Matlab.

Classpath.txt

First thing is to prepare the Matlab classpath. Here is a sample classpath.txt(external link).

Your original file is to be found where Matlab is installed on your disk, precisely there: <MATLAB root dir>/toolbox/local/classpath.txt, )Although you are not going to make any major changes to your original classpath.txt, it is recommended to make a backup first.)

You need to add to the original classpath.txt the last lines (right after the comment reading "Entries added for Univerself Demo") while making sure you replace <INSERT YOUR ROOT DIRECTORY HERE> with the root dir you checked out into. Assuming that was R:\, it should look like:
(#)
(#) Entries added for Univerself Demo
(#)
R:/Demo-Commons/bin/
R:/DemoCoord-Matlab/bin/
R:/Uself-UMF~CoreAndH2N/bin/
R:/Uself-UMF~CoreAndH2N/lib/AlblfGui.jar
R:/Uself-UMF~CoreAndH2N/lib/jfreechart-1.0.14.jar
R:/Uself-UMF~CoreAndH2N/lib/piccolo2d-extras-1.3.1.jar
R:/Uself-UMF~CoreAndH2N/lib/piccolo2d-core-1.3.jar
R:/Uself-UMF~CoreAndH2N/lib/commons-codec-1.6.jar
R:/Uself-UMF~CoreAndH2N/lib/jadex_rt.jar
R:/Uself-UMF~CoreAndH2N/lib/jcommon-1.0.16.jar
R:/Uself-UMF~CoreAndH2N/lib/jcommon-1.0.16-junit.jar
R:/UMFCommon/bin/
R:/UMFCommon/lib/automaton.jar
R:/UMFCommon/lib/restbind.jar
R:/UMFCommon/lib/resty-0.3.1.jar
R:/UMFCommon/lib/simple-4.1.21.jar
R:/UMFCommon/lib/xeger-1.0-SNAPSHOT.jar
R:/UMFCommon/lib/xstream/jettison-1.3.2.jar
R:/UMFCommon/lib/xstream/xstream-1.4.3.jar

Also, you need to comment the line above regarding the xstream library using a sharp <#> (##$matlabroot/java/jarext/xstream.jar in the sample(external link)).

Setting up Matlab


Next, we need to create a shortcut to Matlab's executable that sets the working directory from the early boot. To do so, create a regular shortcut to your matlab.exe, and then set up its' properties as shown in the screenshot below (again assuming R:\ as the root directory of the projects):

Image

Additionally you can make sure your matlab is using the proper version of java, for this set an environment variable in your system that will be named MATLAB_JAVA and which will contain the path to either a jre7 or a jdk7, something like: "c:\Program Files\Java\jdk1.7.0_40"

Building the sources


Now it's time to build the sources. If using Eclipse, it is preferred to BuildAll (dependencies are configured automatically using subversive), otherwise, you may use buildall.bat on Windows which "calls" each project's build.bat. Although there is no build file yet for non-Eclipse, Linux/MacOS users, it should be fairly simple to use the javacs inside the individual build.bat files until we migrate to ant or maven.

Running the prototype

  • start Matlab from the shortcut created earlier
  • execute run_NEMHost.bat (or, from inside USelf-NEMskin, run umf.common.nem.weblaunch.NEMHost for non-Windows environments)
  • execute run_H2N.bat (or, from inside DemoCoord-UMF run uself.demo.CoordDemoH2Ngui)
(note that if you are running them manually, the working directory must(!) be USelf-NEMSkin and DemoCoord-UMF for each case respectively).

Unless H2N and NEMHost are running on the same machine you will need to configure NEMHost's address to GOV, by going to the "Launch Settings" tab and modifying the "GOV URL" field accordingly to point to http://<ip-hostname_of_H2N_machine>:7777/(external link) (note that NEMHost checks for a connection to GOV periodically every 5 seconds, so it won't connect immediately after you change the GOV address).

You may verify that NEMHost has registered correctly to GOV by its icon (turns colored when connected) or by going to H2N->Governance tab->GOV->NEM Classes and the 3 NEMs advertised should be appearing in the list.

Image

Image

Also, in the case that H2N and Matlab are running on different machines, H2N needs the address of the matlab running-machine configured into DemoCoord-UMF/config/rest.conf, property named "uself.demo.matlabws", where "localhost" should be replaced with Matlab's IP/Hostname.

Now to start the simulation, navigate to the "Network" tab, select "CellB", and press "Launch SImulation" from the top-left corner of the window. After a few seconds, plots should appear in the Java window of Matlab titled "Network View". Also, the "Launch Simulation" button should turn into "Kill Simulation" as soon as it's started.


Image

The next thing is to instantiate some NEMs. Back to the "NEM Classes" list (Governance->GOV), you may select ExtendedSONBackhaulOptimNEM and SONloadBalNEM and then click on "Instantiate Selected" (please note that at the time of this writing, SONBackhaulOptimNEM is discontinued). That should bring up two new java processes and change the H2N view to the Network tab, where the NEMs should appear on the right side.

In order to deploy these NEMs now, you may drag'n'drop them over the simulated cell ("CellB", which in this case includes the Femtos attached to it). Note that if you attempt to deploy a NEM over a non-simulated cell (gray ones) it will crash.

In order to make it more interesting then, you may want to unbalance the traffic in the simulator by running run_TrafficConf.bat (or, from inside DemoCoord-UMF run uself.demo.TrafficConfigurer). The effects should be immediately visible in the simulation view.


More details on the SON functionality and the coordination mechanism can be found on the respective poster(external link), leaflet(external link) and presentation(external link) given to FUNEMS 2013.


Configuring the UMF Prototype for Remote NEM Instantiation


Unless H2N and NEMHost are running on the same machine you will need to configure a few settings.

Assuming that H2N will be running on 1.1.1.1 and NEMHost will be running on 2.2.2.2:
1. in NEMHost Settings tab:
(note that NEMHost checks for a connection to GOV periodically every 5 seconds, so it won't connect immediately after you change the GOV address).
  • "NEM Address" should be the address of the machine running the NEMHost (in this example 2.2.2.2).
2. in Demo-UMF/config/rest.conf:
  • In case H2N fails to guess the address of itself (during startup, it prints out a message, which should point to 1.1.1.1) you can manually uncomment and set uself.demo.core.address equal to the address of the machine running the H2N (in this example 1.1.1.1)

You may verify that NEMHost has registered correctly to GOV by its icon (turns colored when connected) or by going to H2N->Governance tab->GOV->NEM Classes and the NEMs advertised should be appearing in the list.

Image

Image

Troubleshooting

Before starting to debug, it is always a good idea to make sure all firewalls have been set up to allow any TCP ports used (default 7777 for UMF Core, 7778 for NEMHost and 8090++ for NEMs), and that the hosting machines are accessible from one another (e.g. forwarded through the NAT). An easy test to ensure a UMF component is accessible (given its address and the port of its listening server) is to navigate to http://<address-of-hosting-machine>:<port>/(external link) using a web browser. If the response is 404 (or any other), then the server is accessible.


Javadoc

This section contains javadoc for the following projects:
  • UMFCommon
  • USelf-KnowInterface
  • USelf-NEMskin
  • USelf-UMF~CoreAndH2N
  • Demo-Commons
Please visit here(external link) to learn more.



Newest Blog Posts

No records to display