Dynamic Bandwidth Shaper for ISPs, the Hospitality Industry, and Education
 

Self-Service Web Portal for the Hospitality Industry

New: E-commerce Web Portal that lets your subscribers’ purchase their own bandwidth service levels.


This is a sample screen shot illustrating how entry into a branded Self-Service Web Portal might look for a new subscriber.

Contents

Introduction

The Self-Service Web Portal (SSWP) is a companion product to the DBS software as a service (SaaS). The SSWP provides an e-commerce shopping cart that facilitates the sale and automatic provisioning of bandwidth service levels through the DBS.

Upon a subscriber’s successful payment through the credit card gateway, a MAC Ticket is automatically generated in the DBS for the selected tier of service and its duration. The DBS then provisions the service within a minute of the MAC Ticket’s creation.

The SSWP can be run as a stand-alone website, and / or can be seamlessly integrated with Mikrotik’s Hotspot service. When integrating with Mikrotik’s Hotspot, no radius server is required for subscriber authentication. All authentication is provided by the SSWP itself. Integration with the Hotspot is enabled through a special configuration and a modified version of the login.html file stored on each Mikrotik router.

The SSWP can support any number of Mikrotik routers and their associated locations simultaneously, assuming that all routers are being managed by the same DBS instance.

Branding can also be varied based upon the subscriber’s location. For example, one ISP (or WISP) might be providing service to many different hospitality locations. Through the use of location based web templates the SSWP automatically provides the branding, look, feel, and optional integration with any existing venue’s website.

Features

  • Seamless integration with Mikrotik’s Hotspot server (hotspot on steroids)
  • Mobile phone aware: excellent subscriber experience for laptops, tablets, mobile Androids, and iPhones alike.
  • No need for a radius server
  • Hospitality branding by location
  • Secured credit card processing through Intuit Quick Books MS or Authorize.net
  • Sell any number of DBS service tiers
  • Set sales limits by DBS service tier by location
  • Dashboard monitoring of sales in real time by tier of service, service level, and location
  • Subscribers that hit the “penalty box” can be automatically kicked out of the hotspot, thus giving them the opportunity to upgrade their bandwidth service level.
  • Monetize unused bandwidth by upselling “stand-by” bandwidth
  • Advertise through Mikrotik’s Hotspot server based upon a subscriber’s DBS status
  • i18n (internationalization) language message bundle for easy translation into other languages

This is a sample screen shot illustrating how entry into a branded Self-Service Web Portal might look for a new subscriber on an Android phone.

Requirements

  • All potential subscribers must receive their IP addresses via DHCP from one or more of the Mikrotik routers being managed by the DBS
  • Hosted or local server running Tomcat 7 or equivalent Servlet 3.0 container.
  • Ownership or control of unique domain name that can be associated with a digital certificate
  • A digital SSL certificate (HTTPS) issued by a Trusted Certificate Authority used to provide secure communications between subscribers and the Self-Service Web Portal
  • Access to a supported credit card processing gateway and associated Merchant Account. The currently supported payment gateways are Quick Books MS from Intuit and Authorize.net. Other gateways can be created and provided on a consulting basis.
  • External SMTP mail server to email subscriber receipts
  • A current DBS subscription

A discussion on integration with Mikrotik’s Hotspot Server

When we first started architecting the DBS Self-Service Web Portal (SSWP) we wanted to make sure that we could provide a simple, seamless, secure integration with Mikrotik’s Hotspot server without the need for a Radius server. We didn’t want to have to maintain a separate list of users on both the SSWP as well as the Hotspot server. To that end, our requirements broke down subscribers into three distinct classifications, which would be treated differently in regard to their interaction with the Hotspot and the SSWP. These categories are as follows:

  1. Paying Subscribers in good standing (Level 1)
  2. Paying Subscribers in the Penalty Box (Level 2)
  3. Guests that have paid nothing (Level 3)

Paying Subscribers in good standing (Level 1)

The idea here is that “Level 1” subscribers are treated as royalty. And by royalty, we mean that they shouldn’t have to deal with the SSWP until they fall out of favor and into one of the other two classifications. When connecting to the network, they’re briefly delayed to verify their status, and are automatically logged into the hotspot and sent on their way.

Paying Subscribers in the Penalty Box (Level 2)

“Level 2” subscribers are treated a little less royally and redirected to the SSWP before being allowed to continue. The idea here is to give paying subscriber’s in the penalty box the option of upgrading to a higher level of service.

In case you’re unfamiliar with DBS’s concept of the “Penalty Box”, each DBS subscriber is allotted a certain amount of bandwidth within a certain time frame, usually twenty-four hours, which is based upon their tier of service. If a subscriber exceeds their allotment within the given time frame, they are placed in the penalty box and their speed is reduced.

If a subscriber chooses to upgrade, they progress through the shopping cart, make their bandwidth choice, pay for their purchase, and then are automatically logged into the hotspot at “Level 1”. If the subscriber chooses to skip the upgrade, they automatically logged into the hotspot at “Level 2”, and remain in the Penalty Box.

Level 2 subscriber’s might also be potentially exposed to advertising that asks if they wish to upgrade their bandwidth service level.

Guests that have paid nothing (Level 3)

Finally, “Level 3” guests are treated as pure commoners since they haven’t paid for any service. By definition they aren’t subscribers but simply guests. And depending upon the venue, they may or may not even be allowed to connect to the network. Upon initial connection to the network guests are automatically redirected to the SSWP. Again, the idea here is to give guests the option of becoming subscribers and upgrading their default level of service (if they have one) to a higher bandwidth speed and / or capacity while being connected to the network.

If guests choose not to upgrade by paying for it, and are allowed “free” access at the given venue, they could be subjected to advertising that asks if they “wish to upgrade their bandwidth service level” periodically. Additionally, it’s our opinion that other advertising for the venue, say a local restaurant or other guest service, as well as paid advertising for other local services could be displayed on the guest’s screen.


This is a sample screen shot illustrating how a branded Self-Service Web Portal bandwidth service menu might look.

Mikrotik Hotspot Server Setup

Now that you’re familiar with the theory of operation of the various subscriber levels you may ask, how is it implemented? Well, it’s really quite straight forward when using either Webfig, or Winbox. It’s much harder with a Telnet connection.

You’ll essentially need to perform the following steps on each of your Mikrotik routers being integrated with the SSWP:

  1. Create three separate user profiles for each of the three levels as described above, including rules for timeouts, and advertising
  2. Create and / or assign IP address pools
  3. Create the three users. Note: since we’re reusing users here, i.e., all subscribers use one of three hotspot logins, you’ll need to make sure that you’re not limiting the number of logins available for each of the three users.
  4. Create a Hotspot Server profile
  5. Configure a Walled Garden to include the SSWP server, and any advertising web content
  6. Modify the Login.html version we have provided to point at the SSWP server. Then using FTP, and Telnet respectively, upload and replace the standard Login.html file.

Note: The details of these steps are beyond the scope of this discussion.

How SSWP Login.html version works

Using Asynchronous JavaScript and XML (Ajax), the Login.html securely inquires the SSWP to find out the current status of a subscriber or guest (user). If the SSWP classifies the subscriber as Level 1, then the Level 1 user name, and encrypted password are provided for automatic login into the Hotspot. If not Level 1, then the user is automatically redirected to the SSWP.

For a fast seamless integration, subscribers and guests must have Javascript enabled in their browser. If Javascript is not enabled, users are met with a [Continue] button and an explanation of why they need to enable Javascript.

In the case that “free” access is allowed and the guest chooses not to upgrade their level of service, they are automatically returned to Login.html and automatically logged in as Level 3. If “free” access is not allowed, then the guest is notified and kept in the SSWP until they change their mind or abandon the effort.

In the case that a subscriber or guest chooses to upgrade their service, they are returned to Login.html and automatically logged in as Level 1.

FAQs

Q: Where is the SSWP installed?
Q: I see that Intuit Quick Books MS and Authorize.Net credit card gateways are supported. Can any other credit card gateways be used?
Q: We have our own hospitality billing system. How can charges be automatically added to a guest’s room charges?
Q: How is the SSWP priced?
Q: Can a Radius server be used with the SSWP?
Q: Can the SSWP be used without the DBS?
Q: How does the SSWP communicate with the DBS?

Q: Where is the SSWP installed?

A: The SSWP can be installed on your own server hardware or in a cloud instance. For more information, please see the “Requirements” above.

Q: I see that Intuit Quick Books MS and Authorize.Net credit card gateways are supported. Can any other credit card gateways be used?

A: Yes. The system has been architected to allow credit card gateway plugins to be built. At this time, these are the only gateway plug-ins provided. We can provide a custom implementations on a consulting basis. As plugins are developed by our staff these plugins are made available to our clients. The next payment gateway that we're considering support for is Dwolla. If the Dwolla payment gateway is of interest to you please let us know.

Q: We have our own hospitality billing system. How can charges be automatically added to a guest’s room charges?

A: We can build a customized payment gateway plugin to integrate with your existing billing system’s API. However, a way to uniquely associate guests and their rooms would need to be developed. A possible voucher or token number could be provided to guest upon check-in and then entered instead of a credit card number.

Q: How is the SSWP priced?

A: Pricing has not been determined at this point. We are considering a number of options including but not limited to a free license in exchange for a revenue sharing agreement.

Q: Can a Radius server be used with the SSWP?

A: Not at this time. Mikrotik Hotspot authorization is provided directly by the SSWP.

Note: If a large potential customer requires this capability we would certainly consider it’s implementation.

Q: Can the SSWP be used without the DBS?

A: No. The SSWP is a companion product and relies on the DBS to provision the various service levels that are sold. All Mikrotik routers being used by the SSWP must first be configured in the DBS as well as all potential subscriber IP addresses must be pre-allocated.

Q: How does the SSWP communicate with the DBS?

A: The SSWP uses a secured HTTPS web services connection via a SOAP based application program interface (API.)

Beta Release

For a limited time we are looking for a few potential customers that would like to try out the SSWP in a test environment on their own server hardware. We’ll provide installation instructions, documentation, a WAR file to be installed on a Tomcat7 server, a customized “login.html” file for each Mikrotik hotspot, and a appliance or cloud based DBS evaluation server on our end.

Please let us know about your interest in becoming a beta tester through the “Contact Us” page.

... everyone is enjoying high speed access, whereas before the DBS was doing its thing, bandwidth was completely consumed by a handful of people and the experience was lousy for everyone ... The majority wins, the ISP makes money and the handful of bandwidth hogs are dealt with.

River District Manager, Swift Wireless

  << Prev       Next >>  

“Automatically manage open Wi-Fi traffic 24/7”

 

Copyright © 2011-2013 DynamicBandwidthShaper.com. All rights reserved.