Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
General
General TopicsGSMBluetooth
Providers
AlltelATT WirelessCingularFidoNextelSprint PCST-MobileVerizon
Manufacturers
EricssonNokiaMotorola
Country Specific
Australian GroupUK Group
Related Topics
PocketPCPalmMore Topics ...

Cellular Phone Forum / General / GSM / June 2005

Tip: Looking for answers? Try searching our database.

SIM Toolkit and NMR in idle mode

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Dominique Blas - 27 Jun 2005 12:49 GMT
Hi,

>In general the answer will depend on the phone manufacturer.
>The specs tell manufacturers what they must do to claim
>compliance, and many do more than the bare minimum.  It's
>really up to them.

>I use STK to read and log NMR from Siemens phones.  I'm able to
>get much the same data (and more) using specific commands on a
>Wavecom modem, and I find no real discrepancy between my
>Siemens and Wavecom data (ignoring RXQUAL, which is hopeless in
>idle mode).  Signal strengths (serving cell and 6 strongest
>neighbours) will vary a bit, but that's to be expected.
>Reassuringly, I get good agreement on the BSIC and BCCH of the
>neighbouring cells, even in dynamic environments.  And most
>importantly, BSIC and BCCH always pair with each other exactly.

>GSM 04.08, as mentioned in GSM 11.14.  And that raises an
>interesting issue.  One of the parameters buried within NMR is
>the MEAS-VALID bit which "indicates if the measurement results
>for the dedicated channel are valid or not" (GSM 04.08, Table
>10.5.47).  A strict interpretation of GSM 11.14 indicates that
>we shouldn't rely on this bit's value, but my feeling is that
>it's probably OK.  It certainly seems to be dependable on
>Siemens phones.

>As to how often they're updated, my Siemens experience suggests
>at least every 10 seconds.

>John

John, could it be possible for you to post (*) a code example (whatever
language it could be) of such a use of STK for retrieving NMR informtion
from Siemens phones ?
By NRM, I mean RXlevel from neighbour cells as well as their cellid (or
BCCH) and the current cell ID.

I've just acquired a S65 for doing such things (among others) and would
like to develop a location application as a proof of concept.

Which kind of SIM do you use ? Is is a JavaCard one ?

BTW, do you know if it exists, for Siemens phones, a gateway between KVM
and STK in order to directly interpret the information retrieven by the SIM.

Best of all would be to retrieve directly these informations (NMR) from
within the KVM but ... I guess it's not time up yet for mobile
manufacturers to publish such things.

Regards,

db

(*) Or to send me a mail to the following address (insert a '@' and a
'.' in the respective blanks).
Signature


Courriel : usenet blas net

John Henderson - 27 Jun 2005 22:42 GMT
> John, could it be possible for you to post (*) a code example
> (whatever language it could be) of such a use of STK for
> retrieving NMR informtion from Siemens phones ?
> By NRM, I mean RXlevel from neighbour cells as well as their
> cellid (or BCCH) and the current cell ID.

Unfortunately, I can't find any way of reading cell ID or BCCH
of neighbouring cells using STK.  GSM 11.14 has no mechanism
that I've been able to see.

> I've just acquired a S65 for doing such things (among others)
> and would like to develop a location application as a proof of
> concept.

You can read Timing Advance with STK.  As you're probably aware,
this gives you a distance to the serving cell with about
half-kilometre accuracy.  You can read only the last value
negotiated, but can ping the cell for a fresh value at any
time.

> Which kind of SIM do you use ? Is is a JavaCard one ?

Just any old SIM.

> BTW, do you know if it exists, for Siemens phones, a gateway
> between KVM and STK in order to directly interpret the
> information retrieven by the SIM.

I've been meaning to look into this myself, but haven't got
anywhere yet.  I'm a complete Java novice.

> Best of all would be to retrieve directly these informations
> (NMR) from within the KVM but ... I guess it's not time up yet
> for mobile manufacturers to publish such things.
>
> (*) Or to send me a mail to the following address (insert a
> '@' and a '.' in the respective blanks).

My attempt to e-mail you directly just bounced.  But you can
make the obvious adjustment to my address to reply to me.

John
John Henderson - 27 Jun 2005 22:56 GMT
Earlier, I wrote:

> Unfortunately, I can't find any way of reading cell ID or BCCH
> of neighbouring cells using STK.  GSM 11.14 has no mechanism
> that I've been able to see.

That's not right.  NMR (read by STK) gives the BCCH of the
neighbouring cells, but not the cell ID.  And I can't find any
means of reading the BCCH of the serving cell in either GSM
07.07 or 11.14.  So we've got the cell ID (but no BCCH) from
the serving cell, and the BCCHs (but no IDs) of the neighbours.
This gap in the available data is a nightmare to fill
programmatically.

John
Dominique Blas - 29 Jun 2005 21:54 GMT
John Henderson a écrit :
> Earlier, I wrote:
>
[quoted text clipped - 6 lines]
> means of reading the BCCH of the serving cell in either GSM
> 07.07 or 11.14.

That's normal, the neighbour CellIds are not transmitted only the BCCH are.
That the way it works, the BTS on which the mobile is camped on
transmits continuously a list of the near stations BCCH as well as other
informations like stations barred, etc.
Then the mobile listens to these channels, record some informations
(color codes, reselection levels [in general difference between minimum
reception level and the current level], etc) and selects the 6 first
best reception levels.

I knew you had these informations through the STK because you displayed
them in a post for Zeldus 2 years ago.
The table you posted was exactly like the network monitor in the S45 (my
previous mobile) displayed it.

To summarize we have the complete id of current cell, the reception
level of the BCCH for this cell, the reselection levels C1 & C2 as well
as the list of neighbour BCCH channels as well as their color code,
their reception level and their reselection levels.

> This gap in the available data is a nightmare to fill
> programmatically.

That's not a problem for me : I have a database (not complete at this
time but enough filled for my goal) that maps BCCH, color codes and
current CellId to the CellId corresponding to the BCCH of the list.

For example, if the current CellId is
2080:00EE:8BF3 (Bouygues Telecom in France)
I can tell you that the BCCH 490 and color codes 72 that appear in the
list belongs to cellId 2080:00EE:12B7.
If the database was large the answer could be obtain through a query
over the network for a application developed under J2ME or the OS (or
through SMS under the STK).

db

Signature

Courriel : usenet blas net

Dominique Blas - 29 Jun 2005 22:34 GMT
John Henderson a écrit :
[...]

> You can read Timing Advance with STK.  As you're probably aware,
> this gives you a distance to the serving cell with about
> half-kilometre accuracy.  You can read only the last value
> negotiated, but can ping the cell for a fresh value at any
> time.

Yeah but 554m of accuracy ... and sensitivity to echo (reflection) : too
bad.

> Just any old SIM.

Ok and in which langage ?

>>BTW, do you know if it exists, for Siemens phones, a gateway
>>between KVM and STK in order to directly interpret the
>>information retrieven by the SIM.
>
> I've been meaning to look into this myself, but haven't got
> anywhere yet.  I'm a complete Java novice.
I looked a bit around. Except JSR-177 that's coming up, there's nothing.
Except if Siemens has a secret API.
Do you have nay other idea ? Through SMS storage for example ?

> My attempt to e-mail you directly just bounced.  But you can
> make the obvious adjustment to my address to reply to me.

Follow the white rabbit :-)

Thank you John,

db

Signature

Courriel : usenet blas net

 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.