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.

Potential real coverage of a cell

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.

Sunday, September 11, 2011

Sponsored networks and outbound roamer steering

There are different solutions allowing small operators to be able to inter-operate with quite large number of partner operators without the need of individual interworking agreements. Such solutions enable the new operators a global coverage with the support of the sponsor network.

Both sponsored and sponsor networks employ some products (which some might be called as roaming replicator), to make the message originated from sponsored network look like it is sponsor network’s traffic. Sponsor network route the traffic for the sponsored network properly too, which allows the sponsored network to access all the partners of the sponsor network.


As shown in the figure, when a subscriber attempts to camp to a network which receives service from a sponsor network, the registration request arrives from sponsor network to the HPLMN HLR. As the replicator products change both SCCP calling and VLR addresses with IMSI, from the point of HPLMN the subscriber is like being abroad in sponsor network country.

Issues with steering
Operators may prefer their outbound roamers to register to certain operators even though they may have roaming agreements with many operators in the same country. The motivation of having “preferred” partners can be cost (having discounts) or technical reasons (like better Camel / data support).

Steering solutions determine the country of the outbound roamer and try to steer the subscriber to a preferred partner using different methods. While one of the methods is network based steering which intercepts the subscribers’ registration messages, another method is SIM based steering which updates the preferred list of the subscriber’s SIM properly for the country.

For the sponsored network as the VPLMN, the HPLMN believes that the subscriber is trying to register to sponsor network actually. Besides this confusion, concluding the subscriber is at another country (Country Y instead of X) is a worse problem. There might be different settings for two countries and if the parameters are looser for the sponsor network’s country, this will cause problems for you.

The sponsor network might be a preferred partner and this prevents you to steer the subscriber to the preferred partners in country X. This may not be a problem if the sponsor network is “more preferred” than your preferred partners in the sponsored network’s country. But for the other case, this may mean that you lose some revenue.

Even though the sponsor network is more preferred than any preferred partner in the sponsored network’s country, you still should fix this case with configuration of the steering solution; to be able to retrieve correct reports grouped by countries.

Solution
Sponsor networks let the partners know about the sponsored network in general. They may publish the sponsorship as well the GT prefix for the VLRs used for that sponsored network. What you should do is to look for such publications from partner networks and alter the settings for your steering solution.

You will possibly need to create a new network to represent the sponsored network with the published GT range from the sponsor network's GT range. Considering your steering solutions allows that, then you should assign this new created network to the country / zone of the sponsored network.

With such setting, you will be able to correctly perform steering configuration for both sponsor and sponsored networks' countries. As roaming business is a considerable part of the revenues of the operators, having correct steering settings can be crucial to keep the costs minimized.