2009-07-27 19 views
0

J'utilise la fonction WML "providelocalinfo" pour envoyer des informations de localisation dans des messages courts envoyés via un menu WIB sur un téléphone GSM. J'utilise le WIG WML v.4 Spec de SmartTrust. La section pertinente est "9.4 providelocalinfo Element"Incorporation de cellulites GSM dans des messages courts

J'utilise le code comme dans l'exemple, puis je transmets la variable via SMS, et j'utilise Kannel pour récupérer le message du SMSC.

Voici le code que j'utilise, à l'exception de [myservicecentre] étant mon centre de service réel:

<?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"> 
<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> 

Ce que je vois dans mes messages reçus est « loc = » suivi de 7 octets (octets) ou des données binaires. J'ai essayé de trouver une documentation expliquant comment décoder ces données, mais je n'ai rien trouvé qui explique cela clairement.

Des décodés 7 octets, les 3 premiers octets sont toujours les mêmes, Les 2 octets suivants ont tendance à varier entre trois valeurs uniques, les 2 derniers octets semblent être le CellID. J'ai donc codé le récepteur pour tirer les deux derniers octets et construire un cellid GSM 16-bit. La plupart du temps, cela correspond aux cellidés connus du réseau. Mais assez souvent, la valeur ne correspond pas.

Je suis en train de trouver des informations sur les points suivants:

  1. Comment transmettre correctement les informations de localisation de manière sûre (encodages, moulages, etc.)
  2. Comment décoder les informations correctement
  3. Comment configurer Kannel pour honorer les données de localisation binaire

Je l'ai examiné les documents suivants dans ma recherche vaine, mais pas trouvé les données pertinentes: GSM 03.38, GSM 04.07, GSM 04.08, GSM 11.15, ainsi que le WIG WML Spec V .4

Tout aperçu de ce que je pourrais faire mal serait apprécié!

Répondre

2

Pour décoder les informations d'emplacement, vous devez regarder dans GSM 11.14 Page 48

1.19 LOCALISATION INFORMATIONS

  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 

Le code de pays mobile (MCC), le code de réseau mobile (MNC), le le code de zone de localisation (LAC) et l'identifiant de cellule sont codés comme dans TS GSM 04.08 [8]. D'après l'expérience personnelle, le premier octet mentionné ici est généralement désactivé, de sorte que vos trois premiers octets immuables sont la longueur et le pays. Les 2 suivants sont le code de l'opérateur réseau.

+0

Cela a été utile pour moi: saisir naïvement les deux derniers octets a manqué différentes valeurs LAC pour les mêmes cellules ou à proximité. Les informations envoyées par les différentes plates-formes WIB semblent varier légèrement de cette spécification (au moins SmartTrust), mais c'est un pas dans la bonne direction et indique une solution pour certains problèmes que nous avons vu. –

0

Pas trop de bouchées sur cette question! Je voulais résumer mes conclusions dans d'autres cas peuvent les trouver utiles:

  1. besoin d'envoyer des messages avec un dcs réglage pas égal à 0. dcs = « 0 » envoie des données emballé (honorant les plus bas 7 bits de chaque octet, ce qui permet des messages SMS de 160 caractères lorsque la taille maximale du message est en réalité de 140 octets)

  2. Besoin d'analyser les données de manière binaire: les expressions regex qui cessent de chercher lorsque 0x0A est rencontré échoueront lorsque les données binaires lui-même peut être cette valeur.

  3. Je n'ai pas jugé nécessaire de modifier la configuration par défaut de Kannel.

Vive

Disclaimer: Meilleure transmission de 16 bits GSM Cell-Ids demande de traiter les quelques paramètres que je comprends seulement parce qu'ils ne sont pas configurés par défaut. Il y a probablement d'autres valeurs par défaut dont je dépendais mais je ne sais pas qu'elles peuvent varier.