Skip to content

Interesting Research Problem for Mobile Networks

October 24, 2010

Mobile network operations are very resource-intensive, and with a growing number of network elements and technologies, the cost will escalate unless a higher level of process automation is introduced.

Network operators and system providers have been talking self-configuration, self-optimization, self-healing, and self-protection for more than a decade (see e.g. IBMs “Autonomic Vision & Manifesto” from 2001). Progress has been made, but the inherent uncertainty of a mobile network has been a huge obstacle in moving from research to practical applications. It often turns out that only the human brain is able to handle the complexity which comes from the size of the network as well as from uncertainty in e.g. aggregated data (details are removed to keep the amount of data manageable), randomness (e.g. a football match causes a sudden amount of network traffic), missing data (for various reasons data is not always available for all network elements), and conflicting data (data indicating multiple problems).

The solution for automated troubleshooting by 2operate released in 2009 was a breakthrough and a major step towards self-healing. By utilizing technology originally developed for automation of medical diagnostic problems, 2operate was able to provide a level of automation in the mobile network troubleshooting processes which was higher than any competing solution in the market. The key was a technology which was sufficiently strong to cope with the complexity and mentioned sources of uncertainty. The key technology used by 2operate is Bayesian network (or more generally, Probabilistic Graphical Models = PGMs).

This can be further exploited for self-healing and self-protection. Troubleshooting is becoming increasingly complex with increased network complexity from new communications technology (e.g. LTE) which must co-exist and interact with old technology (e.g. GSM and UMTS). Partly overlapping with troubleshooting is network security (some problems may be due to intruders with a desire to prevent or steal communication in the network). Security is becoming increasingly important in the network management community. With more automated operations (self-healing, self-optimization, self-configuration), the network will be more vulnerable to intruders, and automated detection and healing is necessary to keep costs down and to reduce downtime.

  • Investigate the problem domain: Which types of technical and security problems are foreseen? How are these prevented today?
  • Research and Development in self-healing/self-protection solution: What are the entities to monitor in an LTE network? What can be observed for an entity (indicators)? What can be concluded (root causes)?

Extract from a PHD Call for Application.


Installing and Configuring UEC’s Eucalyptus

October 17, 2010

In this article you will be dealing with the installation and configuration of a very basic Cloud topology with UEC. You will cover advance features and configurations after I cover an article on integration of the enterprise application with the cloud. I assume that the reader is a seasonal network and system administrator in Linux based environments. You should have at least one machine with hardware based virtualization as KVM is going to be used. This tutorial material should not be used at production systems at all because it is totally an experimental setup.The above diagram shows a minimalistic production topology. For simplicity and hardware constrained experimentation you can use only one server machine to host both CC and NC and this is the same use case that we have in this tutorial.

The core eucalyptus packages of UEC are:

  • eucalyptus-cloud – Cloud controller
  • eucalyptus-cc – Cluster controller
  • eucalyptus-walrus – Walrus (S3)
  • eucalyptus-sc – Storage controller
  • eucalyptus-nc – Node controller

If you are not aware of the architecture of Eucalyptus then please read Introduction to Private Cloud Computing with UEC’s Eucalyptus.

At this point you need to have a Ubuntu Server CD/DVD to install UEC.

Cluster Controller Installation

  1. At boot menu select “Install Ubuntu Enterprise Cloud”
  2. During installation, select Cluster installation. NC installation can be delayed easily.
  3. Select the same “eth0″ interface as public and private interface.
  4. Specify some arbitrary IP address range for Public IPs – to This can later be changed in /etc/eucalyptus/eucalyptus.conf.


1. Install system updates.

 $ sudo apt-get update
 $ sudo apt-get dist-upgrade

Network Configuration

At this point you start considering the NC. It expects a bridge so you will create a bridge and add eth0 as an interface. For this purpose you will need brctl command from bridge-utils package.

Configure the bridge for static IP with the following configuration in /etc/network/interfaces.

auto eth0
 iface eth0 inet manual
auto br0
 iface br0 inet static
 address cc.uec.shaz
 network uec.shaz.0
 broadcast uec.shaz.255
 gateway uec.shaz.1
 bridge_ports eth0
 bridge_fd 9
 bridge_hello 2
 bridge_maxage 12
 bridge_stp off

Node Controller Installation

1. Install Node Controller

$ sudo apt-get install eucalyptus-nc

Web Console

The CC can be accessed via a web console with https://cc.uec.shaz:8443. You will now be able to:

  • download the account credentials
  • view currently installed images
  • make available or disable the installed images
  • browse through the store and install available images
  • add/edit/delete/enable/disable users
  • change the CC configuration
  • access external links of Ubuntu and Eucalyptus community
  • register the cloud with Landscape or RightScale

Retrieving Credentials

After installing CC and NC, users of the cloud will need to retrieve their credentials. This can be done either from a web browser or from a command line.
For command line use the following commands:

$ mkdir -p ~/.euca
$ chmod 700 ~/.euca
$ cd ~/.euca
$ sudo euca_conf --get-credentials
$ unzip
$ cd -

Using Your Credentials

After obtaining the credentials, you need to setup EC2 API and AMI tools on the server using X.509 certificates. For this, source the included “eucarc” file to set up the Eucalyptus environment

$ . ~/.euca/eucarc

This can be added to the ~/.bashrc file, so that the Eucalyptus environment is set up automatically when you log in.

$ echo "[ -r ~/.euca/eucarc ] && . ~/.euca/eucarc" >> ~/.bashrc

Node Registration

Execute following command to register the node:

$ sudo euca_conf --no-rsync --discover-nodes

The above command will prompt for adding the discovered nodes

New node found on cc.uec.shaz; add it? [Yn]

Now euca-describe-availability-zones cleanly reports the node registration

$ euca-describe-availability-zones verbose
AVAILABILITYZONE        uec-cloud       cc.uec.shaz
AVAILABILITYZONE        |- vm types     free / max   cpu   ram  disk
AVAILABILITYZONE        |- m1.small     0002 / 0002   1    128     2
AVAILABILITYZONE        |- c1.medium    0002 / 0002   1    256     5
AVAILABILITYZONE        |- m1.large     0001 / 0001   2    512    10
AVAILABILITYZONE        |- m1.xlarge    0001 / 0001   2   1024    20
AVAILABILITYZONE        |- c1.xlarge    0000 / 0000   4   2048    20

Install store images

You cab install image available from the store. After installing from the store euca-describe-images shows the image details.

$ euca-describe-images
IMAGE   eri-0D4D117E    image-store-1268999725/ramdisk.manifest.xml     adminavailable       public  x86_64  ramdisk
IMAGE   eki-F8BF1114    image-store-1268999725/kernel.manifest.xml      adminavailable       public  x86_64  kernel
IMAGE   emi-E2861098    image-store-1268999725/image.manifest.xml       adminavailable       public  x86_64  machine


Before running an instance of this image, you should first create a keypair that can be used to log into the instance. Create a SSH keypair using the command:

if [ ! -e ~/.euca/mykey.priv ]; then
    touch ~/.euca/mykey.priv
    chmod 0600 ~/.euca/mykey.priv
    euca-add-keypair mykey > ~/.euca/mykey.priv

The default security group should be configured to allow SSH access (port 22). If you plan to use a Windows VM allow access to RDP as well.

$ euca-describe-groups
$ euca-authorize default -P tcp -p 22 -s
$ euca-authorize default -P tcp -p 3389 -s
$ euca-describe-groups
GROUP   admin   default default group
PERMISSION      admin   default ALLOWS  tcp     3389    3389    FROM    CIDR0.0.0.0/0
PERMISSION      admin   default ALLOWS  tcp     22      22      FROM    CIDR0.0.0.0/0

From euca-describe-images, get the EMI ID.

$ euca-describe-images
IMAGE   eri-0D4D117E    image-store-1268999725/ramdisk.manifest.xml     adminavailable       public  x86_64  ramdisk
IMAGE   eki-F8BF1114    image-store-1268999725/kernel.manifest.xml      adminavailable       public  x86_64  kernel
IMAGE   emi-E2861098    image-store-1268999725/image.manifest.xml       adminavailable       public  x86_64  machine

Now launch the instance.

$ euca-run-instances emi-E2861098 -k mykey

Sample eucalyptus.conf

NODES=” cc.uec.shaz”
# network configuration from the input configuration file

You should be able to get both SYSTEM and MANAGED_NOVLAN modes. Remember to do a cleanstop and cleanstart of eucalyptus services between changing network modes.

$ sudo service eucalyptus stop CLEAN=1
$ sudo service eucalyptus-nc stop CLEAN=1
$ sudo service eucalyptus start CLEAN=1
$ sudo service eucalyptus-nc start CLEAN=1

This tutorial should get you started for a basic configuration without understanding much at this early stage. The objective here is to get you started for further experimentation and learning. With my two more planned tutorials you will be able to understand the architecture more. Until next tutorial you are expected to practice the web console and play around with configurations and images.

For more details please visit Ubuntu UEC Community and Beginners Guide to UEC.

Introduction to Private Cloud Computing with Eucalyptus UEC

October 15, 2010

In this article I will introduce the reader to private cloud computing, while discuss the nature of a private cloud with UEC based Eucalyptus as a case study to maintain order.

Private Cloud

A private cloud is a cloud computing infrastructure implemented as a service provider rather using a public cloud as a consumer of the service.

The main thing that make private clouds apart from a commercial public cloud is where the infrastructure implemented and how it’s deployed and maintained. A private cloud is typically hosted on the company servers within their own network infrastructure and administrative domain.

The advantage with a private cloud is direct control over every aspect of the cloud’s design and implementation and most importantly the way security is implemented.

Ubuntu Enterprise Cloud

Ubuntu Enterprise Cloud (UEC) is a package stack of applications from Canonical (best with an Ubuntu server). UEC includes a number of open source tools to manage the infrastructure, apart from Eucalyptus. UEC makes cloud computing a set of friendly activities.

By default UEC uses KVM. You would want to consider Xen based setup if you do not have any VT extensions. It would be better to go for a pure Eucalyptus server configuration but still Xen based kernels are difficult to find these days! You might survive Xen based setup on Fedora12.


Elastic Utility Computing Architecture for Linking Your Programs To Useful Systems” is a GPL Licensed software, which provides tooling to create and manage a private cloud that can even be accessed as public cloud. It provides Amazon EC-2 compatible platform and S3 compatible storage platform. It  makes its services available through EC2/S3 compatible APIs. Therefore the client tools for Amazon Web Services (AWS) can be used with it as well.


  • Interface compatibility with EC2
  • Simple installation and deployment using Rocks
  • Simple set of extensible cloud allocation policies
  • Overlay functionality requiring no modification to the target Linux environment
  • Basic administrative tools for system management and user accounting
  • Configure multiple clusters with private network addresses into a single Cloud
  • Portability

Components of Eucalyptus

Eucalyptus has 3 major components:

  • Cloud Controller (CLC): includes the front-end services and the Walrus storage system.
  • Cluster Controller (CC):  provides support for the virtual network overlay
  • Node Controller (NC): that interacts with VT to manage individual VMs.

And for storage management the following two components are utilized:

  • Storage Controller (SC): provide persistent block storage for the instances
  • Walrus Storage Controller (WSC): provide persistent and simple storage service

Note: Packages provided by Ubuntu are: eucalyptus-cloud, eucalyptus-cc and eucalyptus-nc, eucalyptus-sc, eucalyptus-walrus.

architecture diagram

Component Model:

Node Controller (NC)

NC is a VT enabled server capable of running KVM as the hypervisor. UEC automatically installs KVM when the user chooses to install the UEC node. The VMs running on the hypervisor that are controlled by UEC are called instances.

The NC runs on each node and controls the life cycle of instances running on the node. The NC interacts with the OS and the hypervisor running on the node, while on the other hand it also interacts with the Cluster Controller (CC).

NC queries the OS on the node to discover the node’s resources. These are the number of cores, memory, disk space. It also monitors the state of the VM instances running on the node to propagate this data to the CC.


  • Collection of data related to the resource availability and utilization on the node and reporting the data to CC
  • Instance life cycle management

Cluster Controller (CC)

CC manages one or more Node Controllers to deploys and manages instances on them. CC also manages the networking for the instances running on the Nodes under certain types of networking modes of Eucalyptus.We will have to delay such advance topics for a while!

CC communicates with CLC and NCs as a managed middle tier.


  • Receive CLC requests to deploy instances
  • Select NCs for deploying the instances on
  • Control virtual network availability to the instances
  • Audit the registered NCs and report accordingly to CLC

Walrus Storage Controller (WS3)

It provides a persistent and simple storage service. WS3 uses REST and SOAP APIs, which are compatible with S3 API.


  • Store machine images
  • Store snapshots
  • Store and serve files using S3 API

It should be considered as a simple file storage system.

Storage Controller (SC)

It provides persistent block storage for the instances. SC is similar to the Elastic Block Storage service from Amazon Web Services.


  • Creates and manages persistent block storage devices
  • Creates snapshots of volumes

Cloud Controller (CLC)

CLC is the front end to the entire cloud infrastructure. It provides EC2/S3 compliant web services interface to the client tools. It also interacts with the rest of the components of the Eucalyptus infrastructure. CLC also provides a web interface for users to manage delegated aspects of the UEC infrastructure.


  • Monitor resources of the cloud infrastructure. This includes hypervisor nodes and the cluster controllers that manage the hypervisor nodes.
  • Resource arbitration
  • Monitor running instances

CLC has a comprehensive knowledge of the state of the cloud with respect to availability and usage of resources primarily.


For more details visit

In the next article we will cover installation and configuration.

Introduction to Amazon Web Services by Recluze and Toqeer, CSRDU

October 15, 2010

Getting Started with Amazon EC2 – Install, Configure, Connect.

Auto-scale with Amazon Elastic Compute Cloud Ec2.

Introduction to Amazon Web Services.

Effectiveness of Software Tokens – Virtualizing Security Modules

October 15, 2010

Earlier software tokens were considered weak against malicious activities because the chain of trust could not be established by putting trust on software available at the runtime of the token usage. These days software tokens have become more effective as the available hardware tokens, aka hardware assisted security modules (TPM, or read only and preferably tamper resistant memory), are used to provide a strong Root of Trust to the software tokens as they are used trust-worthily by using the OS platform trust engine to establish chain of trust for application engines.

Note that security modules like TPMs have additional protected capabilities that can be emulated with software modules if needed. Consider the use of vTPMs in cloud computing scenarios over Xen hypervisor.

Software tokens are easy to handle and are more flexible then the hardware counterparts and roots of trust!

For more details:

Public Key Infrastructure

October 12, 2010

Public key infrastructure (PKI) consists of programs, data formats, procedures, communication protocols, security policies, and public key cryptographic mechanisms working in a comprehensive manner to enable a wide range of dispersed people to communicate in a secure and predictable fashion. In other words, a PKI establishes a level of trust within an environment. PKI is an ISO authentication framework that uses public key cryptography and the X.509 standard. The framework was set up to enable authentication to happen across different networks and the Internet. Particular protocols and algorithms are not specified, which is why PKI is called a framework and not a specific technology.

PKI provides authentication, confidentiality, non-repudiation, and integrity of the messages exchanged. PKI is a hybrid system of symmetric and asymmetric key algorithms and methods.

There is a difference between public key cryptography and PKI. Public key cryptography is another name for asymmetric algorithms, while PKI is what its name states – it is an infrastructure. The infrastructure assumes that the receiver’s identity can be positively ensured through certificates and that an asymmetric algorithm will automatically carry out the process of key exchange. The infrastructure therefore contains the pieces that will identify users, create and distribute certificates, maintain and revoke certificates, distribute and maintain encryption keys, and enable all technologies to communicate and work together for the purpose of encrypted communication and authentication.

Public key cryptography is one piece in PKI, but many other pieces make up this infrastructure. An analogy can be drawn with the email protocol Simple Mail Transfer Protocol (SMTP). SMTP is the technology used to get email messages from here to there, but many other things must be in place before this protocol can be productive.

We need email clients, email servers, and email messages, which together build a type of infrastructure – an email infrastructure. PKI is made up of many different parts: certificate authorities, registration authorities, certificates, keys, and users. The following sections explain these parts and how they all work together.

Each person who wants to participate in a PKI requires a digital certificate, which is a credential that contains the public key for that individual along with other identifying information. The certificate is created and signed (digital signature) by a trusted third party, which is a certificate authority (CA). When the CA signs the certificate, it binds the individual’s identity to the public key, and the CA takes liability for the authenticity of that individual. It is this trusted third party (the CA) that allows people who have never met to authenticate to each other and communicate in a secure method. If Shahbaz has never met X, but would like to communicate securely with her, and they both trust the same CA, then Shahbaz could retrieve X’s digital certificate and start the process.

For additional details visit:

Features of OpenXPKI

October 12, 2010

OpenXPKI aims to be an enterprise-scale Public Key Infrastructure (PKI) solution, which supports well established infrastructure components like RDBMS and Hardware Security Modules (HSMs). It is the successor of OpenCA, and builds on the experience gained while developing it as well as on our experience in large public key infrastructures.

  • CA rollover: Usually trust center software does not account for the installment of a new CA certificate, thus if the CA certificate becomes invalid, a complete re-deployment has to be undertaken. OpenXPKI solves this problem by automatically deciding which CA certificate to use at a certain point in time.
  • Support for multiple so-called PKI realms: Different CA instances can be run in a single installation without any interaction between them, so one machine can be used for different CAs.
  • Private key support both in hardware and software: OpenXPKI has support for professional Hardware Security Modules. If such modules are not available, access to a key can be protected by using a threshold secret sharing algorithm.
  • Professional database support: The user can choose from a range of database backends, including commercial ones such as Oracle or DB2, which are typically used in enterprise scenarios.
  • Many different interfaces to the server: Currently, one can access the CA server using a web-interface (which also allows for client-side request generation using SPKAC). Embedded devices such as routers can also use the Simple Certificate Enrollment Protocol (SCEP) to talk to the server and apply for certificates – including automatic renewal.
  • Workflow Engine: OpenXPKI aims to be extremly customizable by allowing the definition of workflows for any process you can think of in the PKI area. Typical workflows such as editing and approving certificate signing requests, certificate and CRL issuance are already implemented. Implementing your own idea is normally pretty easy by defining a workflow in XML and (maybe) implementing a few lines in Perl. The workflow engine also comes with configuration versioning support – if you change the configuration while a workflow is still running, the workflow will still use the configuration it started with, while new workflows will be created using the new configuration. This allows for on-the-fly configuration changes that do not wreak havoc with the currently running system.
  • I18N: Localization of the application and interfaces is easily possible and OpenXPKI can of course deal with the whole range of Unicode characters in certificates.
  • Self-Service application for smart card/token personalization: A web application which allows a user to easily create and install certificates to a smartcard is available.
  • Template-based certificate details: Contrary to the typical CA system, your users do not need to know about how you would like the subject to look like – you can just ask them for the information they know (for example a hostname and port) and OpenXPKI will create the corresponding subject and subjectAlternativeNames for you. Regular expression support allows you to enforce certificate naming conventions easily.
  • Better support using Request Tracker: A heavy load of certificate requests that need additional communication with the requesters can be easily dealt with using the notification interface. Currently only Request Tracker, an open source ticketing system is supported, but the interface is implemented in a general way so that adding other ticket systems is pretty easy. Users can thus automatically receive e-mails once a certificate is issued for example.

Note: Adapted from OpenXPKI user manual.