How do we develop features for our international customers that require the Internet Service Provider’s (ISP) very own infrastructure – without leaving our headquarter in Vienna?
m2bbb – far away but still in the office
Our leading product line – m2suite, with its home and mobile edition – integrates perfectly with home user equipment like routers, Wi-Fi extenders or powerline devices and additionally also seamlessly with the environment of an ISP. Authenticating a customer, querying backend data, communicating with microservices or configuration servers – m2suite integrates nicely. Often, all these services have one thing in common: they are so called “walled gardens” and thus only accessible from within the ISP’s network. It should be noted that many of our international customers are pretty far away from Austria, thus their networks are not reachable by natural means in Vienna. But how can we develop and test custom implementations without leaving our office? It’s all possible with the help of m2bbb – the m2 broadband bridge. Let’s find out more about it in this blog post!
Integrating software with custom hardware or a custom environment is a complex process. It’s eased by being provided with a good documentation. Practice, however, shows that devices not always act as expected and web services for machine-to-machine interactions change, too.
The integration process works best if there is direct access to hardware and services. That’s why we have a lot of different modems, routers, Wi-Fi extenders and more in our lab. Unfortunately, there is still one challenge to solve: how can we access the ISP’s walled garden from our office in Vienna? Some kind of VPN connection would be the most obvious solution. It would probably be sufficient for the implementation and mock testing of service integrations, however, it would not help for device related interactions or even acceptance tests.
For example, some web services (e.g. customer self services) need to identify the customer with the help of the DSL line ID. This would not be available with a generic VPN connection into the ISP’s network.
Another example is that DSL modems are managed by configuration servers (e.g. ACS, HDM, etc.) nowadays, often being the only way to configure them, e.g. to set the SSID and PSK of the Wi-Fi. For this kind of integration, they need to be connected to a DSL line. Therefore, a simple VPN solution is not good enough for us. We have to go even further: bringing the full stack of customer devices online, as if we were in the sales territory of an ISP.
How are residential customers connected to the Internet?
There are a lot of different Internet access technologies, it would be beyond the scope of this blog post to list all. The two most common technologies for broadband Internet access at home are DSL and cable, with optical fiber (FTTC/FTTB/FTTH) gaining slowly in popularity. Even if ISPs provide us with their specific modem devices, we can’t just plug them in and get online. ISPs offering our software solutions to their customers come from different countries. Although DSL or cable are based on common standards, every provider can utilise different configurations, so that modems may not be able to connect in a foreign network. In any case, a modem would not be within the walled garden of the proper ISP.
Getting a DSL line from anywhere to Vienna
The basic concept of broadband bridges
The basic idea of m2bbb is simple: take a DSL socket anywhere and make it available in our office – seamlessly to any device involved on either side. As an added bonus, it should be low-priced. To achieve this, we need to have a quick look into computer networking. Since we are online virtually 24/7, it’s easy to forget what it takes to, for example, access a website. When we use the browser of our smartphone to open the website of mquadr.at, then it establishes a connection to the server hosting it. For the browser and server being able to communicate with each other, a bunch of protocols are used, most commonly
TCP/IP, covering the
transport layer and
internet layer of the Internet protocol suite. But there is a fourth layer, the lowest one: the
link layer. It covers the physical connection between two devices. In our example, the smartphone will be connected to our Wi-Fi network at home. This connects the smartphone to the broadband router, which is connected to our provider’s network with DSL.
For m2bbb, we have two main parts to handle: the
internet layer as a group together, and the
link layer. The first one is encapsulated into a VPN connection, called
network bridge (thus the name
m2bbb, which is short for: m2 broadband bridge).
The second part is twofold (remote and office site) and a bit more complex. As we want m2bbb to be seamless, we have to handle the DSL connection (
link layer) at the remote site and provide a DSL socket at our office site. At the remote site, we could just use the broadband router provided by the ISP – but this approach has a downside. Nowadays, these devices are managed by configuration servers (further reading). The router at the remote site would not allow a connection between the configuration server and the router at our side. Some devices can be set to act in a
bridge mode, but functionality is often limited or locked down. Fortunately, there are generic DSL modems available, which allow to be configured and set up according to our needs.
Now that we are able to access the DSL connection at the remote site, encapsulate all data into a VPN tunnel and transmit it to our office site, we have to invert the process: we need to provide the connection as DSL. This is done with the help of a micro-DSLAM (access multiplexer).
If all is up and running, we are connected to the ISP network in some other country, right from our office in Vienna – seamlessly.
We habe been using broadband bridges for quite some time now. They share the same basic concept but differ in the implementation.
An ordinary VPN tunnel is a client-server setup: in order for the client to connect, the server needs to be publicly reachable. But static IP addresses for a regular residential Internet access are not common – we want to have a reasonable and simple (in terms of requirements on the remote site) solution, after all. Having a central server for all our m2bbbs out there not only reduces the setup requirements on the ISP side, but also acts as a central management and monitoring system. Costs are reduced greatly too, because additional hardware (acting as a VPN server on the remote site) can be omitted.
To deploy an m2bbb, the requirements on the ISP side are simple: at least one (more are always welcome) DSL line and general Internet access to connect to our central server (which can be shared with other devices). Our customer will get one preconfigured m2bbb DSL modem per DSL line from us. It’s a plug and play setup on their side, meaning: once the ISP gets the m2bbb hardware from us, they simply need to connect the cables and that’s it!
About cable and fiber routers
Up to now, we were only looking at m2bbb for DSL modems. The challenging part of m2bbb is to convert an Internet access technology (e.g. DSL) back and forth, so that the usual modem devices of the ISP can be put online in our office. Affordable solutions are available for DSL and fiber, but due to the lack of inexpensive “mini” access multiplexers for cable, we do not provide m2bbb for cable routers at the moment.
Swisscom quickly understood the advantages of a tunnel and set up our bridge to Switzerland in 2014. It’s been up and running ever since and is a tried and trusted part of realising any new project.
Telefónica Germany seamlessly set up our tunnel in 2018. Among other benefits, it has helped reduce feedback loops considerably and enabled us to adjust modem states whenever we needed to for developing and testing new software.
Our new customer NetCologne established their bridge to us earlier this year as part of our very first project together. With five modems connected to it, it has given us a great and easy way to work with different hardware configurations in parallel.
Let’s sum up the benefits of a broadband bridge. Development of software closely integrated with and thus highly dependent on ISP environments can’t be done flying blind. So, without m2bbb, either our developers would have to visit the ISP’s site regularly, or someone at the customer’s site would have to regularly test and provide feedback. m2bbb is a great benefit in saving travel expenses and does not strain our customers’ nerves. This also guarantees speedy release cycles, as time-consuming feedback loops can be avoided. Last but not least, acceptance testing represents a real-world condition this way. With m2bbb, we can cover a wide range of access technologies. It reduces development costs, speeds up the release cycles and leads to higher software quality. A win on both sides of the bridge.