Xavier LAGRANGE
Professeur
Dépt. Réseaux, Sécurité et Multimédia
Téléphone : 02 99 12 70 36
Télécopie : 02 99 12 70 30
Courriel : xavier.lagrange@telecom-bretagne.eu
Errata du livre GSM
Errata 5ème édition
- page 89, paragraphe 5.1.3, lire "Le HLR contient la table de correspondance entre le MSISDN et l'IMSI d'un abonné" au lieu de "Seul le HLR....". En effet le VLR, qui contient les mêmes données que le HLR pour les abonnés qu'il gère, a aussi la correspondance entre MSISDN et IMSI. Cela sert par exemple pour un appel sortant à indiquer le numéro de l'appelant.
- page 93, lire "En général, l'IMSI est transmis lors de la première mise sous tension du mobile et ensuite, seuls les TMSIs successifs du mobile sont transmis sur la voie radio, y compris pour les mises sous tension ultérieures". En effet, le TMSI est stocké dans la carte SIM. Même après une mise hors tension, le TMSI est conservé et il est utilisé à la mise sous tension suivante.
- page 108 à 118 dans les figures 5.16 à 5.18 et 5.23, l'établissement de la connexion SCCP n'est pas explicitement marqué. Il a lieu de façon identique à la figure 5.15. Le premier message émis pas le BSC est encapsulé dans un SCCP_CONNECTION_REQUEST. Il est suivi d'un acquittement envoyé par le MSC.
- Page 117, 3ème paragraphe , 4ème ligne lire "Le premier message émis... est le message RR PAGING RESPONSE" (et non MM).
- Page 118, figure 5.23, lire "RR PAGING RESPONSE" au lieu de "MM PAGING RESPONSE" (la figure 10.4 page 284 est en revanche correcte).
- page 198, dans la formule définissant l'auto-corrélation : lire s_j et non s_i dans le premier terme de l'exposant.
- page 266, la figure 9.23 est légèrement erronée : l'avant-dernière ligne correspond aux octets 36 et 37. L'octet 37 comprend uniquement des bits de parole. L'octet 38 comprend 5 bits de parole et 2 bits de contrôle.
- page 283 : lire à deux endroits "BTSM PAGING COMMAND" et non pas "RR PAGING COMMAND"
- page 382, lire "identiques à celles de la figure 14.14".
- page 392, la description du principe de codage est peu claire et légèrement erronée. Voir le texte ci-dessous
- page 385, dernier paragraphe : modifier en "les trames LLC sont composés ... d'un champ contrôle sur 1 à 3 octets typiquement mais qui peut s'étendre sur 32 ou 36 octets...". Page suivante, la figure 14.21 est à modifier en conséquence ; en face du champ control, mettre 1 à 3 octets, 32 ou 36 octets.
- pages 393 et 504, le PPCH est le Packet Paging Channel et non le Packet Paging Access Channel.
- page 400, avant dernier paragraphe. Une lecture trop rapide m'a fait mal interpréter le terme bloc-period de la norme. L'allocation statique sur la voie montante ne se fait pas de manière périodique. On peut avoir deux granularités : l'allocation concerne l'ensemble des slots d'un même numéro de bloc (on peut allouer à ce moment là une forte capacité) ou concerne chaque slot et chaque bloc (plus faible granularité). Cela n'a rien à voir avec la périodicité. Il est cependant possible de reconduire une allocation déjà transmise, soit à l'identique, soit en la réduisant.
Principe du codage des données en GPRS (compléments et précisions)
La couche physique de GPRS permet de transférer des blocs de données sous différents schémas de codage CS-1 à CS-4 et des blocs de contrôle en CS-1. La norme définit un format de bloc MAC-RLC avec un octet d'en-tête MAC et au moins 2 octets d'en-tête RLC pour les blocs de données. Les 3 premiers bits de l'en-tête MAC des blocs de données et des blocs de contrôle sur la voie descendante correspondent à l'USF (Uplink Status Flag). Ces 3 bits sont protégés de façon particulière sur la voie descendante et sur la voie montante. Sur la voie descendante, cela permet d'éviter des erreurs sur l'USF ; sur la voie montante, cela ne sert à rien mais çà ne fait aucun mal !
Comme indiqué à la figure 14.28 (modifiée par rapport au livre), le CRC s'applique sur le bloc entier. On applique une redondance particulière (sauf en CS-1) pour les 3 bits de poids faible. Le codage, tel qu'il est défini, s'applique sur des blocs de 184 bits en CS-1, de 271 bits en CS-2, de 315 bits en CS-3 et de 431 bits en CS-4. Au niveau MAC-RLC, on transmet que des octets. Les tailles des blocs sont en réalité respectivement 23, 33, 39 et 53 octets auxquels on rajoute respectivement 0, 7, 3 et 7 bits .
Figure 14.28. Principe général de codage des données dans GPRS
| Bloc MAC-RLC | Bloc en bits (valeur de i) | 3 bits de poids faible après protection |
CRC | N1 | m | k/n | Sortie codeur convolut |
Bloc encodé |
|
| CS-1 | 23 octets | 184 | 3 | 40 | 224 | 4 | 1/2 | 456 | 456 |
| CS-2 | 33 octets | 271 | 6 | 16 | 290 | 4 | 1/2 | 588 | 456 |
| CS-3 | 39 octets | 315 | 6 | 16 | 334 | 4 | 1/2 | 676 | 456 |
| CS-4 | 53 octets | 431 | 12 | 16 | 456 | 4 | 1 | 456 | 456 |
Les paramètres i, N1 et k/n sont indiqués dans la figure 14.28.
Figure 14.29. Paramètres du codage des données GPRS
Pour calculer les débits possibles pour un canal physique alloué, il faut prendre les tailles de blocs en octets (2ème colonne du tableau 14.29) et considérer qu'on a 3 octets d'en-tête (un pour MAC et au minimum 2 pour RLC). Seuls CS-1 et CS-2 sont possibles sur les interfaces Abis classiques. On peut transmettre un bloc par période de 20 ms. On trouve donc des débits de 8 et 12 kbit/s en CS-1 et CS-2.
| Débit annoncé (kbit/s) |
Taille de bloc en bits (avec USF) |
Taille d'un bloc en octets |
En-tête MAC en octets |
En-tête RLC en octets |
Taille des données RLC |
Débit niveau RLC (kbit/s) |
|
| CS-1 | 9,05 | 184 | 23 | 1 | >=2 | =<20 | 8 |
| CS-2 | 13,4 | 271 | 33 | 1 | >=2 | =<30 | 12 |
Figure 14.45. Débit de GPRS par canal
Merci à Romain Cavagna, Cécile Jan et Sylvie Picouet de m'avoir signalé des erreurs. Merci à Christophe Bourguignat pour les corrections sur le paging.
Si vous détectez une erreur ou une imprécision, merci de la signaler à Xavier Lagrange. Dernière miseà jour : 22/08/06.
Technopôle Brest-Iroise - CS 83818 - 29238 Brest Cedex 3 - France
Tél : 33 (0)2 29 00 11 11 - Fax : 33 (0)2 29 00 10 00
Tél : 33 (0)2 29 00 11 11 - Fax : 33 (0)2 29 00 10 00