- Overview of Oracle Mobile Data Offloading
- Overview of Oracle Mobile Data Offloading
- Utilizing Oracle Event Processing (OEP), Mobile Data Offloading (MDO) provides telecommunication service providers with a server-based solution to help make informed decisions according to pre-defined automated policies for offloading mobile data from wireless cellular networks to alternate networks such as Wi-Fi. Oracle MDO identifies mobile users entering an area of interest covered by an alternate network. It determines if these devices are stationary within the pre-defined zone. The premise is that a stationary device may continue to remain within the zone, and that it is beneficial to offload data traffic to an alternate network. In some cases, the policy for a specified zone may be to attempt to offload mobile traffic from the mobile user immediately. This may be the case in zones such as sporting arenas or concert venues. For these facilities, the quality of service on the primary cellular network may begin to degrade as more users enter the zone. Switching mobile users to alternate networks as soon as possible could improve the quality of service and overall customer experience. Oracle MDO provides dashboards to provide an Operator with reporting statistics.
- Oracle MDO is a role based solution; your role determines the tasks you can perform. Oracle MDO delivers the following roles:
- An Operator enters the Wi-Fi tower location details, defines the areas of interest, and the offloading policies for each area of interest.
- Oracle MDO uses an Event Processing Network (EPN) to illustrate the basic event flow of data through the mobile data offloading process. The MDO Event Processing Network diagram is depicted as follows, with an explanation of the process.
- MDO Event Processing Network
- MDO Event Processing Network [Part 1]
- The MDO EPN has adapters that receive data from applications and cache loaders that pre-load into memory data from the databases for faster access.
- First, the DeviceLocationAdapter receives the device location in the form of latitude and longitude using the International Mobile Equipment Identity (IMEI) number as the identifying attribute. This latitude and longitude data is sent to the DeviceLocationProcessor via a DeviceLocationInputChannel.
- The CacheLoader event-bean loads the OffloadAreaCache, the AreaPolicyCache, and the WiFiTowerCache. The former is loaded with information about already defined areas of interest, or locations where a Wi-Fi network is available. When mobile users enter these areas, their data traffic could potentially be offloaded to an alternate wireless network. The OffLoadAreaCacheListener receives data from this cache and creates from it an Oracle Spatial Geometry object, used by Oracle Spatial functions embedded directly in the event processing engine. The OffLoadAreaRelation channel holds these areas of interest that the DeviceLocationProcessor can use as needed by the processor's logic. The latter cache, AreaPolicyCache, stores policies and rules concerning the offloading, such as the waiting period before initiating the offloading process.
- The DeviceLocationProcessor has access to the stream of incoming device location events and the relation of areas of interest. It uses the Spatial Cartridge capability (an extension of the Continuous Query Language) to create a spatial geometry object from the latitude and longitude information, and then calls a function within Continuous Query Language (CQL) to determine if the device is currently located within one of the areas of interest. The processor then sets an attribute to indicate whether this device location is present within the defined areas of interest.
- The DeviceLocationOutputChannel outputs an event that contains information as to whether the device is within an area of interest as determined by the DeviceLocationProcessor.
- MDO Event Processing Network [Part 2]
- The InputEventStatisticsAdapter collates data related to incoming events and sends the statistics to Oracle Business Activity Monitoring (BAM).
- The ManageDevicesInAreaOfInterest event-bean has access to a Coherence cache that holds the state of previously processed devices including whether they are known to be within an area of interest. It uses the Coherence Entry Processor concept to make the correct state updates to the cache. In addition, it compares the current device context with the previous ones and updates the devices state to either 0,1, 2, and 3
- which stand for Entered, Still in Area, Exited Area, and Changed Areas respectively.
- The AreaOfInterestStateChannel receives the state change events according to the preceding logic.
- The AreaOfInterestStatisticsProcessor sends statistics related to the state change of events relative to the areas of interest to BAM. It also sends detailed state messages to BAM via the DeviceInAreaStateBAMAdapter with detailed statistics for the BAM dashboard. A production application may decide to disable these statistics to improve performance. This adapter uses OutboundBAMJMSMapMessageConverter to convert the event to a MapMessage, since the date formats that need to be converted using Java functions. A JMS MapMessage is used because BAM can easily be configured to pick up these messages from a JMS queue and populate the relevant data object without any additional coding. It only requires some simple configuration.
- The OffloadPolicyProcessor joins directly to the AreaPolicyCache using CQL to retrieve the policy applicable to the area, to determine if the device’s mobile data should be offloaded to the Wi-Fi network.
- The QualifiedOffloadStatisticsAdapter reports the resulting policy compliance data to BAM.
- The
- WiFiTowerCache
- The WiFiTowerCacheListener is an Oracle Event Processing event bean configured as a Coherence MapListener class to receive any updates to the WiFiTowerCache. It populates the WiFiTowerRelation with Spatial Geometry objects that represent the locations of the Wi-Fi towers. Like the OffloadAreaCacheListener, the Wi-Fi tower locations are converted to OEP’s spatial geometry objects, so OEP can perform the indexing.
- The WiFiTowerDistanceProcessor receives events corresponding to devices that have newly entered an area of interest or have changed from one area of interest to another, and meet the policy requirements for remaining stationary, if applicable. It also has access to the spatial geometry objects of the Wi-Fi Tower locations. It uses an Oracle Spatial Nearest Neighbor (NN) distance function to determine the nearest Wi-Fi tower. Once that is done, the range of the distance is validated. If necessary, it initiates the offload process to the RequestOffloadAdapter via the RequestOffloadChannel. The RequestOffloadAdapter sends detailed statistics about the offload events to BAM, and in a production system would send the request to downstream systems.
- The WiFiDistanceStatisticsAdapter sends statistics about whether the events that have reached this stage have met the acceptable distance range requirements, to BAM. The cache is updated when a new Wi-Fi tower location is added to the database via the user interface.