To stimulate usage while abroad, operators are offering aggressive roaming retail tariffs to their subscribers which are supported by negotiated IOT from partners. Because of flat rate retail tariff for a country and little margins, it is more important than ever to keep the steering effective to keep the costs under control.
Especially for data which has relatively higher IOT, the difference between the negotiated and regular IOT could be so high that even a small percentage of traffic loss to an unpreferred partner may mess all the business of your “ aggressive retail campaign”.
To achieve this, operators are working hard to tune their steering systems or support network based steering systems with SIM-based steering systems. As the loss of traffic to unpreferred partner is more serious for data traffic because of high difference of IOT for data, we need more than tuning the existing steering solutions.
Steering systems should be aware of data-heavy or data-only terminals and handle them with different settings, different preferred operator or in a more aggressive way. While the data-only terminals can be detected easily (no UpdateLocation but only GPRS UpdateLocation messages) by network-based steering systems, it is not possible for them to detect smart phones as not all the partners can send the IMEI information in the registration messages. This leads to using operator databases for subscriber - terminal type mapping which can let you know who is using a smartphone.
The definition for smartphone can be slightly different for everyone. From the data traffic perspective, we're more likely to be interested in the recent generation of smartphones with big screens and easy to use interfaces boosting data usage.
The ability to know which outbound roamer is using a smartphone may not be enough alone itself, as not all smartphone users are data-hungry subscribers. Checking their local and roaming usage history could be priceless to detect data-heavy roamers which we want to steer to our partners with negotiated data IOT.
Informa predicts that revenues from mobile data roaming will increase by a massive 246% between 2010 and 2015. With the growing trend of regulating roaming business more strictly, operators are working on data roaming business more to be able to compensate the losses.
Wednesday, April 25, 2012
Sunday, April 22, 2012
Drawing GSM cells on Google Maps
The GSM (radio) network is built on cells, which are served by base stations (BTS). A cell site may have multiple sectors, created by seperate antennas serving to separate angles from the same tower.
The coverage area of a cell is not certain as shown here in the figure. It can be quite chaotic and may even be built of separate "islands" of coverage, just because of geographical conditions and buildings around. The coverage area of the cell can be mathematically modeled taking the environment into consideration or better tried to be measured on the field to have the exact coverage information.
For the simplicity, each sector of a cell site can be considered as a slice of pie with the center as the tower and some depth which it can reach farmost. Theoretically the depth of a cell is 35km (6-bits time advance value), but in the cities the depth is much less. The depth of the cell can be calculated or verified by the calls made from farmost distance to the tower.
From time to time I needed to draw simplified pie-representation of GSM cells on Google Maps to be able to visualize the cell. Each cell can be identified by LAC and CID of the cell and can be described by coordinates of the tower, the start and stop angles and depth of the cell.
With my limited Javascript knowledge, I developed a quick and dirty class which can represent and draw a GSM cell on the map.
Defining cells you wanna draw as below, you can easily draw them on the map.
Adding the midpoint calculation to the class, you can show information on the cell too.
Another important function I needed was marking a time advance (TA) area, as it is used by CGI+TA based positioning method. In this method the location of the subscriber is estimated as an arc. Each TA slot is around 550 meters (for 2G). Below is a fictional cell with 2km depth.
You can see the working example and check the javascript code here. Once you populate all your cells in the module cells.js, you can play with them on the map.
Related post: converting Cell ID to coordinates
The coverage area of a cell is not certain as shown here in the figure. It can be quite chaotic and may even be built of separate "islands" of coverage, just because of geographical conditions and buildings around. The coverage area of the cell can be mathematically modeled taking the environment into consideration or better tried to be measured on the field to have the exact coverage information.
For the simplicity, each sector of a cell site can be considered as a slice of pie with the center as the tower and some depth which it can reach farmost. Theoretically the depth of a cell is 35km (6-bits time advance value), but in the cities the depth is much less. The depth of the cell can be calculated or verified by the calls made from farmost distance to the tower.
From time to time I needed to draw simplified pie-representation of GSM cells on Google Maps to be able to visualize the cell. Each cell can be identified by LAC and CID of the cell and can be described by coordinates of the tower, the start and stop angles and depth of the cell.
With my limited Javascript knowledge, I developed a quick and dirty class which can represent and draw a GSM cell on the map.
Defining cells you wanna draw as below, you can easily draw them on the map.
Adding the midpoint calculation to the class, you can show information on the cell too.
Another important function I needed was marking a time advance (TA) area, as it is used by CGI+TA based positioning method. In this method the location of the subscriber is estimated as an arc. Each TA slot is around 550 meters (for 2G). Below is a fictional cell with 2km depth.
You can see the working example and check the javascript code here. Once you populate all your cells in the module cells.js, you can play with them on the map.
Related post: converting Cell ID to coordinates
Monday, January 23, 2012
GSM positioning myths (or operators’ positioning solutions)
“Operators know –without any effort— where all subscribers are at any time with historical information”
Not just the subscribers but even some of the GSM operator employees have this idea. They even may base some ideas / solutions on this wrong assumption. But yes; as most are aware, this is a wrong statement.
Operators can determine the location of a subscriber, but not in a 1-meter precision. Worse, this has to be on demand, meaning you have to query the network for this information. Besides, this query has an impact on radio resources so that there is an upperbound on the number of concurrent queries on the network in a technically feasible way (in other words, letting subscribers to be able to talk).
In this post, we’ll go over the most common network based positioning solutions deployed on the GSM networks and their precision. Please note that not all the methods are discussed here, but only the most common ones. There are higher precision solutions than the ones described here, but most are not financially feasible requiring serious hardware investment. They are rarely used unless it is mandated by the regulatories. Below, the solutions are grouped in the way they are accessed or operating.
Mobile Termination Location Request (MT-LR)
Solutions in this category are queried to check the position of the subscriber on the network on demand. They query different nodes on the network to collect the position information and return the result to the service triggering the query.
MPS might be the most known solution in the category. Its accuracy is better than cell level, as it can return a slice of the cell with the calculation of the subscriber’s distance to the antenna.
If the antenna is serving only to a specific range of 360 degrees area, this results as an arc for the position of the subscriber. The ellipsoid arc is specified with the coordinates of the antenna, the inner/outer radius and start/stop angles. While the depth of the arc is about 550 meters (for 2G) in general, the size of the area depends on the antenna angles and the distance to the antenna. So the size of the arc can be >550m wide area for the downtown areas, but it can be a couple of kilometers for the rural.
As the distance to the antenna is calculated with time advance (Ta) information on the GSM network, this positioning method is also referred as CGI+TA method too. As this method requires active paging of the subscriber, it consumes some radio resource during the operation. As the radio resource is a quite valuable and limited resource for the GSM networks, it is clear how “expensive” the positioning in terms of both license and radio resources. Besides being expensive, the radio capacity introduces limits on how many positioning queries you can perform on a single cell.
CGI based positioning is another alternative in this category. Compared to CGI+TA, it provides a coarser area using only the serving cell ID of the subscriber. While the uncertainity area is as big as the cell itself, it is adequate for most of the 3rd party services. GSM vendors state that this method provides almost the same precision with CGI+TA method in the cities. CGI of the subscriber can be queried from the network without consuming the valuable radio resources but this will return the last CGI which the subscriber made any activity (mobile originated (MO) / terminated (MT) call/sms or data) or performed location area change. Alternatively, subscriber can be paged before the query to find out the active CGI of the subscriber.
Network Induced Location Request (NI-LR)
This platform works on the CGI+TA level. The main difference within them is that NI-LR does not need to be pulled for positioning. As it is intended for emergency calls, it queries the location of the call originator and pushes this information to a specific node on the network for each emergency call. Another pro of this method is that it can provide the location of the SIM-less subscribers making emergency call too.
Monitoring based systems
The solutions described above are active nodes, exchanging messages and consuming resources on the network. Considering messages are exchanged on the network for the mobility of the subscriber, one can consider monitoring these messages to be able to extract location information. This kind of working has the benefit of low effect on the network and ability of knowing all subscribers’ location at a time.
Here we have feasibility issues in terms of number of (and cost) monitoring probes and the amount of data processed. For a huge network, it is not financially feasible to monitor every single cell (BSC/BTS). Because of this, most operators monitor MSC-BSC communication (A-interface) only. At this level, Cell ID of subscribers is visible only for those performing any MO/MT activity or changing the “location area”.
Location area is a virtual concept, used to group a number of cells together to reduce the signalling cost. That’s why passive subscribers changing cells are not visible on this level, as long as they stay in the same location area. Based on this information, it is clear that the precision of such monitoring system is at “location area” scale. It may return cell level information but this information is the first cell the subscriber enters the location area, but not his active cell ID.
In short
With all the information above, we can sort the positioning solutions ordered with their precision as CGI+TA >> CGI >> A-interface monitoring.
Operators can locate the subscriber, but only within an area which is not small and varied depending on the area. Also, it is not possible to locate all subscribers at a time at the moment.
Finally, to comfort the subscribers, I have to note that most GSM operators are taking the subscriber privacy as serious issue and perform positioning only if the subscriber or the legal authorities (like emergency call cases) asks for it.
Subscribe to:
Posts (Atom)
