tags:

views:

427

answers:

2

I'm using the WML function "providelocalinfo" to put location information into Short Messages send via a WIB menu on a GSM handset.

I'm using the WIG WML v.4 Spec from SmartTrust. The relevant section is "9.4 providelocalinfo Element"

I use the code as in the example, and then transmit the variable via SMS, and use Kannel to retrieve the message from the SMSC.

Here's the code that I'm using, with the exception of [myservicecentre] being my actual service centre:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE wml PUBLIC "-//SmartTrust//DTD WIG-WML 4.0//EN"
  "http://www.smarttrust.com/DTD/WIG-WML4.0.dtd"&gt;
<wml wibletenc="UCS2">  

  <card id="s">
    <p>
      <providelocalinfo cmdqualifier="location" destvar="LOC"/>
      <setvar name="X" value="loc=" class="binary"/>
      <sendsm>
          <destaddress value="367"/>
          <userdata docudenc="hex-binary" dcs="245">
              $(X)$(LOC)
          </userdata>
          <servicecentreaddress value="[myservicecentre]"/>
      </sendsm>
    </p>
  </card>
</wml>

What I see in my received messages is "loc=" followed by 7 bytes (octets) or binary data. I have tried to find documentation explaining how to decode this data, but found nothing the explains this clearly.

Of the decoded 7 octets, the first 3 octets are always the same, The next 2 octets tend to vary between three unique values, the last 2 octets appear to be the cellid.

So I have coded the receiver to pull the last two octets and construct a 16-bit GSM cellid. Most of the time it matches known cellids from the network. But quite often, the value does not match.

So I'm trying to find information on the following:

  1. How to properly transmit the location information in a safe manner (encodings, casts, etc)
  2. How to decode the information properly
  3. How to configure Kannel to honor binary location data

I've examined the following documents in my vain searching, but not found the relevant data: GSM 03.38, GSM 04.07, GSM 04.08, GSM 11.15, as well as the WIG WML Spec V .4

Any insight into what I might be doing wrong would be appreciated!

A: 

Not too many bites on this question! I wanted to summarize my findings in case others can find them useful:

  1. Need to send messages with a dcs setting not equal to 0. dcs="0" sends data packed (honoring the lower 7-bits of each octet; this allows 160 character SMS messages when the max message size is actually 140 octets)

  2. Need to parse the data in a binary safe manner: regex expressions that stop searching when 0x0A is encountered will fail when the binary data itself can be that value.

  3. I found no need to change Kannel's default configuration.

Cheers

Disclaimer: Safe transmission of 16-bit GSM Cell-Ids requires dealing with a few settings that I understand only because they weren't configured by default. There are probably other defaults that I've depended on but am unaware that they can vary.

Joshua Berry
+1  A: 

To decode the location info, you need to look in GSM 11.14 page 48

1.19 LOCATION INFORMATION

          Byte(s)    Description                                           Length
            1         Location Information tag                               1
            2         Length (X) of bytes following                          1
           3-5        Mobile Country & Network Codes (MCC & MNC)             3
           6-7        Location Area Code (LAC)                               2
           8-9        Cell Identity Value (Cell ID)                          2

The mobile country code (MCC), the mobile network code (MNC), the location area code (LAC) and the cell ID are coded as in TS GSM 04.08 [8].

From personal experience, the first octet mentioned here is usually left off, so your first three unchanging bytes are the length and the country. The next 2 are the network operator code.

Michael
This was helpful for me: Naively grabbing the last two octets has missed different LAC values for the the same or nearby cells. The information sent by different WIB platforms seem to vary slightly from this spec (at least SmartTrust does), but it's a step in the right direction and indicates a solution for some problems we've been seeing.
Joshua Berry