Deploy OpenAir Core Network vEPC on an arbitrary OpenStack Cloud using a Heat Template
Swisscom Innovations was looking for a simple solution to deploy OpenAir-CN (the core network part) on an arbitrary OpenStack public cloud and having that procedure automated as much as possible. Therefore we created a Heat Orchestration Template which can be used for this task. The template does everything automatically for you, from building the software directly from git master over installing and configuring openair-cn as vEPC in the cloud. We think it might be useful for the community, thats why Swisscom shares it here. Feel free to ask questions to the openair-cn mailinglist or directly to @dbalsige.
Since generic OpenStack clouds do not support transporting SCTP packets over Floating IPs yet, we use a simple VPN setup for carrying the S1 traffic between eNBs and MME/SPGW instances. This has the cute side-effect that eNB can be placed everywhere in the Internet even behind NATs, and you do not have the need for a second external network in OpenStack, so in principle any public OpenStack cloud can be used to deploy the core. In addition, S1 traffic between eNB and MME/SPGW is encrypted and eNBs are authenticated. Have a look at the following picture to understand which networks and instance interfaces are used for which traffic:
Access to an OpenStack tenant
Of course you need access to an OpenStack cloud. The template creates a router, a floating IP, an internal network, volumes, security groups, ports and instances in OpenStack. Keep in mind that your tenant has sufficient quotas to create those resources. The OpenStack version should be at least Kilo, with keystone, glance, nova, neutron, cinder and heat services enabled. We tested the template on Kilo, Liberty and Mitaka.
The HOT (Heat Orchestration Template)
The heat template is in openair-cn git. I created a new branch called 52-swisscom-heat-templates. The template can be found here: https://gitlab.eurecom.fr/oai/openair-cn/blob/52-swisscom-heat-templates/heat/OpenAir-vEPC.yml
Ubuntu image with os-*-config installed
Since the heat template uses OS::Heat::SoftwareDeployment, the base image for the instances needs to have os-collect-config/heat-config/os-apply-config tools installed. Such images can be created manually and uploaded to your cloud easily. Instructions for that are provided just at the beginning of the tutorial.
1. Create custom Ubuntu images
To create an os-*-config ready Ubuntu image you could use the following commands:
sudo apt-get install python-pip sudo pip install virtualenv virtualenv ~/dib-virtualenv . ~/dib-virtualenv/bin/activate pip install diskimage-builder mkdir custom-image cd custom-image git clone https://git.openstack.org/openstack/tripleo-image-elements.git git clone https://git.openstack.org/openstack/heat-templates.git export ELEMENTS_PATH=tripleo-image-elements/elements:heat-templates/hot/software-config/elements diskimage-builder/bin/disk-image-create vm ubuntu os-collect-config os-refresh-config os-apply-config heat-config heat-config-script -o ubuntu-xenial-os-config.qcow2
As a remark (12-12-2016), you can see above that we use trusty (14.04) version of Ubuntu ($DIB_RELEASE). In principle, the heat template works with Ubuntu xenial (16.04), however we have problems connecting UEs to the core when using xenial. So please test with trusty (14.04) version of Ubuntu first. Update (4-10-2017) It should be safe to use ubuntu 16.04 xenial as far as read the mailinglist... I updated instructions accordingly.
2. Upload your created image to OpenStack
Use the horizon GUI to upload the image you just created to your OpenStack cloud. Or have a look at the following example how to achieve that with the glance command-line client:
glance image-create --disk-format qcow2 --file ubuntu-$DIB_RELEASE-os-config.qcow2 ubuntu-$DIB_RELEASE-os-config
3. Create or upload an SSH keypair for logging into instances
You will need an SSH key to be able to login to instances created. Therefore an SSH keypair needs to be defined for your tenant. There are several possibilities to achieve this:
- You have already a keypair defined for your tenant. That is fine, you can use that one for your OAI deployment.
- You can create a new SSH keypair directly in OpenStack. Keep in mind to keep the key file at a secret place.
- You can import the public part of an existing SSH key to OpenStack.
4. Check tenant quotas
You are almost done with your cloud setup, once again check the following on your OpenStack tenant:
- Remember the name of the external network you want to use to connect your OAI deployment to. (One neutron Router and one neutron Floating IP will be created in that external network)
- Remember the flavors you want to use for your instances (the template uses one flavor for building and one flavor for running)
- Check you have sufficient quotas an all cloud resources (Volumes, RAM, CPU, instances, security groups, rules, floating IPs, routers, networks...)
- Check your heat service is running (e.g. by clicking on the Orchestration tab in horizon)
5. Start the deployment
Download the heat template (https://gitlab.eurecom.fr/oai/openair-cn/blob/52-swisscom-heat-templates/heat/OpenAir-vEPC.yml) and save it locally.
Go to horizons 'Orchestration' tab and click on 'Launch Stack'.
As template provide the file you downloaded before and click on 'Next'. No environment file is needed.
Now adjust the values your for your needs, and press on 'Launch'.
Here you have a little video how this look like:
Depending on your clouds performance and the flavors selected it can take more than the normal timeout (60 minutes). With build flavor of 4 cores you should be fine in 30 minutes.
When the stack is created successfully nodes need to be rebooted for using updated or custom (SPGW) kernels. TODO Rebooting instances by template.
After reboot the three programs oai_hss, mme and spgw on the respective instances need to be started and the core is up. TODO Auto starting the services by template.
6. Connecting eNBs to the core
In princple: first connect the eNB to the VPN by installing keys and starting the process. After that configuration is straight-forward. vEPC is reachable by VPN. We are planning to create eNB images for different sample H/W directly in the cloud by heat and provide some hardware configuration that were tested successfully. Stay tuned.
7. Connecting UEs