We will be installing GPRS/EDGE cards in company laptops. Our application
requires that the card pass the cell tower's ID to the laptop so our laptop
can know which cell tower it's currently connected to. Is this possible?
> We will be installing GPRS/EDGE cards in company laptops. Our
> application requires that the card pass the cell tower's ID to
> the laptop so our laptop can know which cell tower it's
> currently connected to. Is this possible?
It should be possible, given a few assumptions.
When you say "which cell tower it's currently connected to",
will these devices be actually connected (with a
circuit-switched connection), attached with an active GPRS
session, or in idle mode (camped on a cell but not interacting
with it)?
Reading the cell ID should be straightforward in idle mode, but
will be trickier if the laptop is talking to something else
/through/ the card at the time. You may have to momentarily
suspend that connection/session, in order to have a brief
conversation with the card itself.
Some networks in some parts of the world broadcast a textual
cell name (a "cell broadcast" or "area info" message) as well
as a unique numeric cell ID. With most modern GSM modem cards,
reading both should be possible.
But good luck if you're looking for software "off-the-shelf" to
do these things.
> When you say "which cell tower it's currently connected to",
> will these devices be actually connected (with a
> circuit-switched connection), attached with an active GPRS
> session, or in idle mode (camped on a cell but not interacting
> with it)?
We are interested in knowing which cell tower we are connected to, just
prior to initiation of the GPRS session. Connection will be telemetry data,
no voice. The mobile laptop with GPRS card will be camped on a cell site
but not interacting with it. Then our server will attempt to initiate a
connection to it. The GPRS network will find our laptop. Our laptop needs
to know at that time (or immediately before) which cell site it is connected
to so it can report that in its response back to the server. We prefer
connections to be TCP-IP rather than circuit-switched. Does all this sound
possible?
> Reading the cell ID should be straightforward in idle mode, but
> will be trickier if the laptop is talking to something else
> /through/ the card at the time. You may have to momentarily
> suspend that connection/session, in order to have a brief
> conversation with the card itself.
That should be fine. We only need to know the cell ID when in idle, waiting
for a request from our server. That's the ID we will report back through
our laptop application after the connection is made.
> Some networks in some parts of the world broadcast a textual
> cell name (a "cell broadcast" or "area info" message) as well
> as a unique numeric cell ID. With most modern GSM modem cards,
> reading both should be possible.
Can you refer me to a Website where this information is available? We'll
need to write the S/W to get the cell site ID from the card. We'll also
need to be able to do a lookup of the cell site ID to determine its physical
location.
> But good luck if you're looking for software "off-the-shelf" to
> do these things.
> We are interested in knowing which cell tower we are connected
> to, just prior to initiation of the GPRS session. Connection
> will be telemetry data, no voice. The mobile laptop with GPRS
> card will be camped on a cell site but not interacting with
> it. Then our server will attempt to initiate a connection to
> it. The GPRS network will find our laptop. Our laptop needs
> to know at that time (or immediately before) which cell site
> it is connected to so it can report that in its response back
> to the server. We prefer connections to be TCP-IP rather than
> circuit-switched. Does all this sound possible?
Assuming your modem card supports the necessary commands, this
will be easy. Below is an annotated log of a session with a
Siemens S55 phone. I'll start by using "AT+CREG?" to ask about
phone registration status.
AT+CREG?
+CREG: 0,1
OK
I'm now changing the "+CREG" behaviour to report cell ID as
well, and also give me unsolicited results. By "unsolicited
results" I mean that the phone will report all changes of cell
ID automatically, when they happen, without my entering any
more commands.
AT+CREG=2
OK
I'll ask again about registration status, and this time the LAC
and cell ID will be reported as well.
AT+CREG?
+CREG: 2,1,"1030","639E"
OK
LAC (location area code) is 1030 hex (4144 decimal), and cell ID
is 639E hex (25502 decimal).
+CREG: 1,"1030","1401"
The above is an unsolicited result code, showing me that the
phone has now camped on another cell (same LAC, but cell ID is
now 5151 decimal).
I'll now ask which network I'm using. This will show my SIM's
home network, because the second argument in the "+CREG:"
result above, "1", says that the phone is currently registered
on the home network (rather than roaming).
AT+COPS?
+COPS: 0,0,"Telstra"
OK
Now I want to see the registered network in numeric format, so
I'll ask for that.
AT+COPS=0,2
OK
AT+COPS?
+COPS: 0,2,"50501"
OK
The operator part of the result consists of a 3-digit country
code "505" (MCC = Australia), and a 2-digit network code within
that country (MNC = Telstra). Note that some countries (North
America) use a 3-digit MNC as well as a 3-digit MCC).
The reason I'm showing the MCC + MNC detail is that the cell ID
is only guaranteed to be absolutely unique if it consists of
the whole MCC + MNC + LAC + ID string, eg "505 01 1030 639E"
+CREG: 1,"1030","639E"
That was another unsolicited result showing that the phone
changed cell again.
Now I'll ask the phone to scan all possible channels (takes a
while) and give me a list of all visible carriers.
> Can you refer me to a Website where this information is
> available? We'll need to write the S/W to get the cell site
> ID from the card. We'll also need to be able to do a lookup
> of the cell site ID to determine its physical location.
Any version of GSM 07.07 (or the later 2G/3G replacement, 3GPP
27.007) will give you the full syntax of the above commands.
They're widely available on the net, including free official
downloads from www.etsi.org or www.3gpp.org
John, that was extremely helpful. Thank you very much.
One final question, that I now realize I should have asked earlier but
didn't think it would be an issue.
The purpose of obtaining the cell ID is so that we can determine approximate
location of the tower and our client connected to it. I was just told,
however, that the networks keep tower locations secret. If that's true we
would be unable to determine tower location even if we have the cell ID. Do
you know if this is the case?
Henry.
"John Henderson" <jhenRemoveThis@talk21.com> wrote in message
news:67hp92F2nuafjU1@mid.individual.net...
> Henry VIII wrote:
>
>> We are interested in knowing which cell tower we are connected
>> to, just prior to initiation of the GPRS session. Connection
>> will be telemetry data, no voice. The mobile laptop with GPRS
>> card will be camped on a cell site but not interacting with
>> it. Then our server will attempt to initiate a connection to
>> it. The GPRS network will find our laptop. Our laptop needs
>> to know at that time (or immediately before) which cell site
>> it is connected to so it can report that in its response back
>> to the server. We prefer connections to be TCP-IP rather than
>> circuit-switched. Does all this sound possible?
>
> Assuming your modem card supports the necessary commands, this
> will be easy. Below is an annotated log of a session with a
> Siemens S55 phone. I'll start by using "AT+CREG?" to ask about
> phone registration status.
>
> AT+CREG?
> +CREG: 0,1
>
> OK
>
> I'm now changing the "+CREG" behaviour to report cell ID as
> well, and also give me unsolicited results. By "unsolicited
> results" I mean that the phone will report all changes of cell
> ID automatically, when they happen, without my entering any
> more commands.
>
>
> AT+CREG=2
> OK
>
> I'll ask again about registration status, and this time the LAC
> and cell ID will be reported as well.
>
> AT+CREG?
> +CREG: 2,1,"1030","639E"
>
> OK
>
> LAC (location area code) is 1030 hex (4144 decimal), and cell ID
> is 639E hex (25502 decimal).
>
>
> +CREG: 1,"1030","1401"
>
> The above is an unsolicited result code, showing me that the
> phone has now camped on another cell (same LAC, but cell ID is
> now 5151 decimal).
>
> I'll now ask which network I'm using. This will show my SIM's
> home network, because the second argument in the "+CREG:"
> result above, "1", says that the phone is currently registered
> on the home network (rather than roaming).
>
> AT+COPS?
> +COPS: 0,0,"Telstra"
>
> OK
>
> Now I want to see the registered network in numeric format, so
> I'll ask for that.
>
> AT+COPS=0,2
> OK
> AT+COPS?
> +COPS: 0,2,"50501"
>
> OK
>
> The operator part of the result consists of a 3-digit country
> code "505" (MCC = Australia), and a 2-digit network code within
> that country (MNC = Telstra). Note that some countries (North
> America) use a 3-digit MNC as well as a 3-digit MCC).
>
> The reason I'm showing the MCC + MNC detail is that the cell ID
> is only guaranteed to be absolutely unique if it consists of
> the whole MCC + MNC + LAC + ID string, eg "505 01 1030 639E"
>
> +CREG: 1,"1030","639E"
>
> That was another unsolicited result showing that the phone
> changed cell again.
>
> Now I'll ask the phone to scan all possible channels (takes a
> while) and give me a list of all visible carriers.
>
> AT+COPS=?
> +COPS: (2,"Telstra",,"50501"),(3,"vodafone
> AU",,"50503"),(3,"YES OPTUS",,"50502)
>
> OK
>
>> Can you refer me to a Website where this information is
>> available? We'll need to write the S/W to get the cell site
>> ID from the card. We'll also need to be able to do a lookup
>> of the cell site ID to determine its physical location.
>
> Any version of GSM 07.07 (or the later 2G/3G replacement, 3GPP
> 27.007) will give you the full syntax of the above commands.
> They're widely available on the net, including free official
> downloads from www.etsi.org or www.3gpp.org
>
> John
>John, that was extremely helpful. Thank you very much.
>
>One final question, that I now realize I should have asked earlier but
>didn't think it would be an issue.
>
>The purpose of obtaining the cell ID is so that we can determine approximate
>location of the tower and our client connected to it. I was just told,
>however, that the networks keep tower locations secret. If that's true we
>would be unable to determine tower location even if we have the cell ID. Do
>you know if this is the case?
Thanks, but I didn't see a way to look up individual tower locations on that
site, but it's for the U.K. anyway.
I've been told that U.S. carriers keep their tower locations secret. The
only way I've found to get tower location info so far is to use Websites
that cellular users contribute to, where they report the locations and cell
IDs of towers using their cell phones.
That seems like it's bound to be incomplete and full of inaccuracies. Hope
there's a better way.
Henry.
"Chris Blunt" <mail@nospam.com> wrote in message
news:4pn714ld5neif3njlt0kavujq482sp0qsq@4ax.com...
> On Sat, 26 Apr 2008 18:28:02 -0700, "Henry VIII"
> <donteventhink@emailingmehere.com> wrote:
>
>>John, that was extremely helpful. Thank you very much.
>>
>>One final question, that I now realize I should have asked earlier but
>>didn't think it would be an issue.
>>
>>The purpose of obtaining the cell ID is so that we can determine
>>approximate
>>location of the tower and our client connected to it. I was just told,
>>however, that the networks keep tower locations secret. If that's true we
>>would be unable to determine tower location even if we have the cell ID.
>>Do
>>you know if this is the case?
>
>
> Perhaps this might be of some help.
>
> http://www.sitefinder.ofcom.org.uk/
>
> Chris
>Hi Chris,
>
>Thanks, but I didn't see a way to look up individual tower locations on that
>site, but it's for the U.K. anyway.
>
>I've been told that U.S. carriers keep their tower locations secret. The
>only way I've found to get tower location info so far is to use Websites
>that cellular users contribute to, where they report the locations and cell
>IDs of towers using their cell phones.
>
>That seems like it's bound to be incomplete and full of inaccuracies. Hope
>there's a better way.
> John, that was extremely helpful. Thank you very much.
>
> One final question, that I now realize I should have asked
> earlier but didn't think it would be an issue.
>
> The purpose of obtaining the cell ID is so that we can
> determine approximate location of the tower and our client
> connected to it. I was just told, however, that the networks
> keep tower locations secret. If that's true we would be
> unable to determine tower location even if we have the cell
> ID. Do you know if this is the case?
For the USA, I don't know if you can look up that info anywhere.
If you're working in a limited area, some GSM devices can help
you find cell locations for yourself. I have Siemens phones,
and Wavecom and Falcom (Wavecom engine) modems which let me
read TA (timing advance). This will give distance to the cell
with an accuracy of about 550 metres. Do some intensive
automated logging with GPS correlation from a moving device,
and you can quickly build up a good picture of where the cells
are.
Here's a Wavecom modem, using "AT+CREG=2" to tell me about cell
ID changes, and "AT+CCED=1,4" (a Wavecom proprietary command)
to tell me the last-negotiated TA value:
+CREG: 1,"1030","639E"
AT+CCED=1,4
OK
+CCED: 8
TA = 8, so I'm about 4 to 4.5 km from this cell.
Now I'll do a free "supplementary services" command to force the
modem to interact with the network. This automatically
refreshes the TA value (the distance to the cell).
AT+CLIP?
+CLIP: 0,1
OK
I didn't get a fresh "+CCED:" unsolicited result, so the TA
value remains at 8 (valid TA range is 0 through 63).
+CREG: 1,"1030","1401"
We've had a change of serving cell, so I'll do:
AT+CLIP?
+CLIP: 0,1
OK
and get
+CCED: 4
discovering from this that this new cell is about 2 km away.
Unfortunately, there isn't a GSM standard command for reading
TA, so you're reliant on your device manufacturer providing
one. On the Siemens phone, I use a variant of the Siemens
proprietary "AT^SSTK" command.
> For the USA, I don't know if you can look up that info anywhere.
I agree - so far I haven't found an open database of GSM tower locations in
the U.S. except for a couple user-contributed ones such as: http://www.navizon.com/navizon_v-gps.asp which I doubt are accurate or
complete for all GSM service providers.
> If you're working in a limited area, some GSM devices can help
> you find cell locations for yourself. I have Siemens phones,
> and Wavecom and Falcom (Wavecom engine) modems which let me
> read TA (timing advance). This will give distance to the cell
> with an accuracy of about 550 metres. Do some intensive
> automated logging with GPS correlation from a moving device,
> and you can quickly build up a good picture of where the cells
> are.
In my case, however, I have to determine my geographic location
independently of GPS. All I need to do is to relate a GSM tower's cell ID
to a location very roughly. But even that rough tower location data seems
to be unavailable.
I assume a way around this would be to purchase an API from every service
provider, but this involves considerable expense, and there is no assurance
that all providers would be willing to do this.
So ONLY the network service providers can sell tower-based geo-location
services (ie - triangulation) because they alone have the tower location
data?
Mobile Laptop on EDGE/GPRS
Linear Mode
