As part of the on-going work in MobileCloud Networking the project will demonstrate outputs of the project at this year’s Globecomm industry-track demonstrations. Globecomm is being held this year in Austin, Texas.
MobileCloud Networking (MCN) approach and architecture will be demonstrated aiming to show new innovative revenue streams based on new service offerings and the optimisation of CAPEX/OPEX. MCN is based on a service-oriented architecture that delivering end-to-end, composed services using cloud computing and SDN technologies. This architecture is NFV compatible but goes beyond NFV to bring new improvements. The demonstration includes real implementations of telco equipment as software and cloud infrastructure, providing a relevant view on how the new virtualised environment will be implemented.
For taking the advantage of the technologies offered by cloud computing today’s communication networks has to be re-designed and adapted to the new paradigm both as developing a comprehensive service enablement platform as well as through the appropriate softwarization of network components. Within the Mobile Cloud Networking project this new paradigm has been developed, and early results are already available to be exploited to the community. In particular this demonstration aims at deploying a Mobile Core Network on a cloud infrastructure and show the automated, elastic and flexible mechanism that are offered by such technologies for typical networking services. This demonstration aims at showing how a mobile core network can be instantiated on demand on top of a standard cloud infrastructure, leveraging key technologies of OpenStack and OpenShift.
The scenario will be as following:
A tenant (Enterprise End User (EEU), in MCN terminology) – may be an MVNO or an enterprise network – requests the instantiation of a mobile core network service instance via the dashboard of the MCN Service Manager – the the service front-end where tenants can come and request the automated creation of a service instance via API or user interface. In particular the deployment of such core network will be on top of a cloud hosted in Europe. At the end of the provisioning procedures, the mobile core network endpoints will be communicated to the EEU.
The EEU will have the possibility to access the Web frontend of the Home Subscriber Server (HSS) and provision new subscribers. Those subscribers information will be used also for configuring the client device (in our case a laptop).
The client device will send the attachment requests to the mobile core network and establish a connectivity service. Since at the moment of the demonstration the clients will be located in the USA, there will be a VPN connection to the eNodeB emulator through which the attachment request will be sent. At the end of the attachment procedure all the data traffic will be redirected to Europe. It will be possible to show that the public IPs assigned to the subscriber are part of the IP range of the European cloud testbed.
The clients attached to the network will establish a call making use of the IP Multimedia Subsystem provided by the MVNO. During the call the MVNO administrator can open the Monitoring as a Service tool provided by the MCN platform and check the current situation of the services. For this two IMS clients will be installed on the demonstration device.
At the end of the demonstration it will be possible to show that the MVNO can dispose the instantiated core network and release the resources which are not anymore necessary. After this operation the MVNO will receive a bill indicating the costs for running such virtualized core network.
It specifically includes:
An end-to-end Service Orchestrator, managing dynamically the deployment of a set of virtual networks and of a virtual telecom platform. The service is delivered from the radiohead all the way through the core network to service delivery of IMS services. The orchestration framework is developed on an open source framework available under the Apache 2.0 license and is where the ICCLab actively develops and contributes.
Interoperability is guaranteed throughout the stack through the adoption of telecommunication standards (3GPPP, TMForum) and cloud computing standards (OCCI).
A basic monitoring system for providing momentary capacity and triggers for virtual network infrastructure adaptations. This will be part of the orchestrated composition.
An accounting-billing system for providing cost and billing functions back to the tenant or the provisioned service instance. This will be part of the orchestrated composition.
A set of virtualised network functions:
A realistic implementation of a 3GPP IP Multimedia Subsystem (IMS) based on the open source OpenIMSCore
A realistic implementation of a virtual 3GPP EPC based on the Fraunhofer FOKUS OpenEPC toolkit,
ICCLab is just back from Open World Forum in Paris after being part of the organisation of the “Open Cloud, Open Standards” session that was run in conjunction with CloudCamp. It was an excellent session and Simon Wardley was the master of MC’ing. There was a number of presentations to kick off the day and that was followed by very interesting and energetic round table discussions. The ICCLab presented on OCCI and you can see that presentation here (PDF here):
The topics of discussion during the day revolved around:
“Does the Cloud need standards?”
“Government role in Cloud, beneficial or dangerous intervention?”
“What do we mean by standards anyway – specification or reference model?”
“Whose standards – de jeure or defacto?”
“Should those standards be open?”
“Is there any such thing as an open API or are all APIs open?”
Stay tuned for an upcoming blog post where we discuss the out comes of the session.
In coordination with ZH-Geeks, the ICCLab will be hosting the very first Swiss OpenStack user group meeting on the 15th of Novemeber. In addition to Tim Bell there will be a number of other speakers who will present on various OpenStack topics. Tim Bell runs the infrastructure team at CERN where they run a very large installation of OpenStack. Tim is also a member of the OpenStack foundation management board and one of the main drivers of the OpenStack-based IaaS needed to analyse the 25PB of data a year from the LHC. If anyone wants to submit a lightening talk (talk with slides of no more than 10 mins) on their work with OpenStack please let Andy Edmonds know. We would encourage as many of you to attend! Please sign up at the following site.
Recently, the [OCCI implementation](http://www.github.com/dizz/nova) for [OpenStack](http://www.openstack.org) was made available by [work done by Intel Labs Europe](http://wiki.openstack.org/occi) as part of the [FI-ware project](http://www.fi-ware.eu). Some of the install instructions are now somewhat out of date. In this post we’ll outline the steps necessary to get the OCCI implementation up and running. This updated install guide is also now reflected on the [OpenStack OCCI wiki](http://wiki.openstack.org/occi). A big thanks goes out to Piotr Kasprzak at [GDWG](http://www.gwdg.de) for some of the updates!
Create a fresh VM. Ubuntu 12.04 is a good baseline.
Install some necessaries:
Fix the `prettytable` issue:
Edit `~/devstack/stackrc` so it checks out the OCCI branch of OpenStack:
Create/Edit `~/devstack/localrc` with the following content:
Now execute devstack:
You will be now asked for a number of service admin passwords. Once the devstack process has completed you should see the following:
Once the stack is running you can then issue the commands that are on the [OpenStack OCCI wiki page](http://wiki.openstack.org/occi).
A virtual machine with both OpenStack and OCCI can be [downloaded from here](http://www.cloudcomp.ch/wp-content/uploads/2012/06/OCCI-OS.ova). The user name and password is `occi` and `occi`. It is in an OVA export format and you can easily import into VirtualBox. In `~/devstack/localrc` the `OFFLINE` parameter is set to `True`. If you want to update the devstack installation change this to `False`.
## Potential Issues
1. If the OCCI API blocks and does not return a response then please check your `/etc/nova/api-paste.ini` configuration. Ensure that the `[filter:authtoken]` section has the correct `service_host` and `auth_host` values.
We here in the ICCLab are very much interested in all activities related to standardisation in the Cloud. Standardisation forms part of our [overall strategy in bringing impact](http://www.cloudcomp.ch/research/) to the communities we take part in. One of these activities is our participation in the [Open Cloud Computing Interface (OCCI)](http://occi-wg.org/). OCCI is a standardisation activity ran out of the [Open Grid Forum](http://www.ogf.org). Briefly OCCI is:
> a Protocol and API for all kinds of Management tasks. OCCI was originally initiated to create a remote management API for IaaS model based Services, allowing for the development of interoperable tools for common tasks including deployment, autonomic scaling and monitoring. It has since evolved into a flexible API with a strong focus on integration, portability, interoperability and innovation while still offering a high degree of extensibility. The current release of the Open Cloud Computing Interface is suitable to serve many other models in addition to IaaS, including e.g. PaaS and SaaS.
Apart from contributing to the OCCI specifications, the ICCLab is contributing to the OCCI implementation for OpenStack and it is with this implementation that we take part in the various [Cloud Plugfest](http://www.cloudplugfest.org/) events, which “*is a co-operative community project designed to promote interoperability efforts on cloud-based software, frameworks, and standards among vendors, products, projects and implementations*”.