2.1.1 Le processus de standardisation du 3GPP
Le 3GPP est structuré en TSG (Technical Specification Group), chacun ayant ses propres domaines d’expertise. Concernant les réseaux d’accès, deux TSG existaient : le GERAN pour la 2G et le RAN pour la 3G, 4G et la future 5G. Cette situation découle de l’héritage historique de la 2G, originellement spécifiée par l’ETSI, et antérieur à la création
du 3GPP1. Ainsi, ce Study Item fut logiquement confié au GERAN.
Étant en charge du Study Item, le GERAN a défini un certain nombre d’objectifs que devaient valider les solutions proposées, ainsi que les méthodes d’évaluation pour pouvoir les comparer. En effet, l’intérêt principal du Study Item est de dégager une ou plusieurs solutions, qui feront par la suite l’objet d’un travail de spécification dans le cadre d’un Work Item, en vue d’une inclusion dans une Release du 3GPP. Le Study Item a donc pour objectif essentiel d’identifier la ou les solutions pouvant servir de base à un Work Item. C’est donc un enjeu de taille pour les participants, car les intérêts sont multiples et varient suivant la nature des participants. Un opérateur soutiendra une solution qui est en accord avec des besoins qu’il a préalablement identifiés et qui limitera l’impact sur son réseau déjà établi. Un équipementier voudra prendre de l’avance sur une éventuelle implémentation matérielle, avec le but d’assurer son activité future. Une startup, de même que tout autre participant, pourra chercher à faire valoriser de la propriété intellectuelle, sous forme de brevets. On peut aussi noter que les investissements consacrés à une solution ne faisant pas, par la suite, l’objet d’un travail de spécification, seront en partie perdus. Mais au-delà des enjeux financiers et stratégiques, le simple fait de proposer ou de soutenir activement une solution au Study Item, donne une image forte à l’entreprise. C’est aussi un aspect important, car il est nécessaire d’avoir de l’influence lors des différentes discussions, et une participation active permet de cultiver cette influence, ce poids, auprès des autres membres du 3GPP.
Pour qu’une solution (ou plusieurs) puisse(nt) servir de base à un Work Item, il est nécessaire que l’ensemble des membres (ou presque2) approuve la proposition. Il est donc primordial d’obtenir, dès le Study Item, le soutien des autres membres, et notamment de membres influents. Pour cela, il faut effectuer un travail de persuasion lors des différentes réunions d’avancement organisées, le calendrier étant préparé à l’avance. Des réunions supplémentaires (dits ad-hoc) peuvent également s’intercaler si nécessaire. Ce Study Item était prévu pour durer un an, avec des réunions de 4 jours tous les 3-4 mois. Habituellement, chaque réunion donne lieu à de féroces discussions, où il faut à la fois défendre sa solution, attaquer les solutions adverses, et lier des alliances. L’ensemble des documents fournis par les participants sont soumis au vote, pour leur inclusion dans le TR. C’est donc une véritable bataille technologique et d’influence qui se déroule, avec pour objectif l’obtention du Work Item. Et c’est donc pour pouvoir comparer les solutions dans le cadre du Study Item, qu’un certain nombre d’objectifs et de méthodes d’évaluation sont définis précisément au sein du TR.
2.1.2 Objectifs du GERAN pour un support efficace de l’IdO
Les objectifs énoncés par le GERAN pour ce Study Item sont définis en termes de per-formances, et sont en accord avec les caractéristiques des cas d’usage de l’IdO, décrites au début de ce manuscrit, section 1.1. On retrouve tout d’abord la nécessité d’une couverture radio améliorée, certains objets pouvant être situés à des emplacements ne leur offrant que des conditions radio défavorables (dans un sous-terrain, en intérieur, etc ...). Ainsi, l’objec-tif d’une extension de couverture de 20 dB comparée au système GPRS est adopté. Pour mesurer la couverture d’un système, le 3GPP se base sur la valeur du Maximum Coupling Loss ou MCL (en dB). Le tableau 2.1 décrit le calcul du MCL du GPRS en voie montante
1. À la suite de la Release 13, le GERAN fut fermé et l’évolution des réseaux d’accès 2G fut confiée au TSG RAN. La spécification des systèmes 2G étant depuis longtemps effectuée par le 3GPP, cette séparation n’avait plus de réel intérêt.
2. Le système de vote est plus complexe, des recours étant possibles si un petit groupe persiste à voter contre l’avis majoritaire.
et descendante3. Dérivé du bilan de liaison, le MCL représente l’affaiblissement maximal admissible par le système. Dans le cadre du Study Item, la valeur retenue pour le GPRS est 144 dB, correspondant donc au MCL de la voie limitante. L’objectif de couverture à remplir par les solutions proposées s’élève donc à 164 dB. Le lecteur souhaitant plus de détails concernant la méthode de remplissage du tableau peut se référer à la méthodologie décrite dans le TR 36.888 du 3GPP [28], section 5.1. Le calcul du MCL du GPRS est ef-fectué à partir des informations contenues dans la spécification technique (TS ou Technical Specification) 45.005 du 3GPP [29].
MCL voie MCL voie montante descendante (2 antennes Rx) Transmetteur
(1) Puissance totale Tx (dBm) 43 33
Récepteur
(2) Densité thermique de bruit (dBm/Hz) -174 -174 (3) Figure de bruit du récepteur (dB) 5 3
(4) Marge due à l’interférence (dB) 0 0 (5) Bande passante occupée (kHz) 180 180
(6) Puissance de bruit effective -116.4 -118.4 = (2) + (3) + (4) + 10 log((5)) (dBm)
(7) SINR requis (dB) 10.4 12.4
(8) Sensibilité du récepteur -106.0 -106.0 = (6) + (7) (dBm)
(9) Gain de traitement en réception (dB) 0 5 MCL = (1) - (8) + (9) (dB) 149.0 144.0
Table 2.1 – Maximum Coupling Loss du système GPRS [11]. Concernant les autres objectifs que les solutions doivent remplir :
— La latence est fixée à une valeur maximale de 10 secondes en voie montante, certaines applications nécessitant une latence modérée, comme un système d’alarme. Cette valeur confirme une criticité faible de la latence.
— Le débit minimal est fixé à 160 bps de données utiles (défini au niveau de la couche réseau du modèle OSI) pour les voies montante et descendante. En général, les objets n’ont pas besoin d’un débit élevé, compte tenu des faibles quantités de données à transmettre (et de la contrainte en latence peu élevée).
— Pour la quantité d’objets à gérer (la capacité), une valeur d’un peu plus de 50000 objets par cellule de 1 km de diamètre en ville a été estimée (les détails du calcul se trouvent dans l’Annexe E. du TR [11]).
— La durée de vie minimale d’un objet est fixée à 10 ans pour un fonctionnement sur batterie de capacité 5 Wh, indépendamment de la situation d’extension de couver-ture dans laquelle se trouve l’objet.
— Les objets doivent être bon marchés pour pouvoir être déployés en masse, ce qui implique une faible complexité. En l’occurrence, la complexité et le coût de l’objet doivent être inférieurs à ceux d’un modem GPRS.
— Enfin, les solutions doivent vérifier des objectifs de compatibilité. En effet, les so-lutions proposées doivent peu impacter le fonctionnement des systèmes cellulaires
3. On peut calculer une valeur de MCL pour chaque type de canal logique, puisque la valeur de SINR requise peut varier.
classiques 2G, 3G et 4G. Elles doivent donc limiter leurs interférences avec ces sys-tèmes. De même, l’impact sur l’implémentation matérielle des stations de base doit être minimisé. Concernant l’interface avec le réseau cœur, les interfaces Gb (entre le BSC et le SGSN) et/ou S1 (entre l’eNode B et les MME et S-GW) doivent être utilisées préférentiellement, pour minimiser l’impact sur le réseau cœur. On peut aussi noter qu’une compatibilité des objets avec le système GPRS n’est pas requise.
2.1.3 Principales méthodes d’évaluation des solutions proposées
Une fois les objectifs définis, il est nécessaire d’imposer des méthodologies précises pour évaluer et comparer les solutions techniques proposées. Certaines méthodologies sont simples à définir, comme le calcul du MCL. D’autres sont moins évidentes, comme la mesure de la consommation d’énergie et de la durée de vie de l’objet. Cette section n’a pas pour but d’énumérer la totalité des méthodes d’évaluation utilisées, mais de fournir une vue d’ensemble simplifiée de ces dernières.
Décrivons tout d’abord succinctement les différents modèles de trafic considérés. Ils représentent les cas d’usage typiques pris en compte pour l’évaluation des performances. En voie montante, les profils d’émission sont, soit des compte-rendus périodiques, soit des compte-rendus spontanés (appelés exceptions). Dans tous les cas, il est question de Mobile Autonomous Reporting (MAR), c’est-à-dire de compte-rendus émis de manière autonome par l’objet. Par exemple, un compteur d’eau ou de gaz émettra des compte-rendus pé-riodiques, alors qu’un détecteur de fumée émettra une exception spontanément. En voie descendante, 2 types de trafics sont aussi identifiés : les commandes réseau Network Com-mand (NC) et les reconfigurations logicielles. Lors d’une Network Command, un serveur envoie une requête à un objet pour qu’il effectue une action particulière, comme allumer une lumière. Une transmission NC peut impliquer une émission consécutive sur la voie montante, sous forme d’exception. Des reconfigurations ou mises à jour logicielles seront certainement prévues pour un grand nombre d’objets, de sorte à pouvoir corriger à dis-tance d’éventuels bugs, modifier les conditions d’émission d’un compte-rendu ou encore ajouter de nouvelles fonctionnalités. Pour chaque modèle de trafic, les répartitions statis-tiques de la quantité de données utiles par compte-rendu, de la fréquence d’émission, de la nécessité d’un acquittement après réception et de la proportion de chaque modèle de trafic sur l’ensemble des transmissions en voie montante et descendante, sont définies. Avec un certain nombre de paramètres communs supplémentaires, il est ainsi possible de réaliser des simulations comparatives entre les différentes solutions, car elles sont réalisées dans les mêmes conditions. Ces simulations peuvent entre autres servir à donner une évaluation de la capacité et de la latence du système.
L’évaluation de la consommation d’énergie et de la durée de vie est également obtenue par le biais de simulations. Les différents niveaux de consommation d’énergie considérés sont illustrés sur la Fig. 2.1 issue du TR. Le scénario présenté ici est celui de l’échange d’un paquet IP via le GPRS. Sur cette figure, on peut constater que c’est l’émission d’un message qui consomme le plus d’énergie, suivie par la réception d’un message. Deux états intermédiaires sont disponibles. Un premier état dit “idle” (ou “veille active”), où l’objet reste dans une phase active globale, en vue d’une éventuelle émission ou réception, et où il maintient un certain niveau de synchronisation avec le réseau. C’est l’état classique dans lequel se trouve un téléphone mobile. Le second mode peut être assimilé à un mode “sommeil”, ici nommé PSS pour Power Saving State. Dans cet état, l’objet ne maintient allumé que le minimum de fonctionnalités pour assurer son bon fonctionnement, comme des minuteurs, et il n’est pas joignable par le réseau. Pour qu’un objet ait une durée de vie élevée, il est donc nécessaire qu’il passe le plus de temps possible en mode PSS et idle, et
que ses périodes d’émission et de réception soient les plus courtes possibles.
Figure 2.1 – Exemple d’événements affectant la consommation d’énergie pour l’échange d’un paquet IP avec le système GPRS [11].
À l’aide de simulations et en définissant des scénarios précis, il est donc possible d’éva-luer les performances d’une solution en termes de consommation d’énergie. Ces perfor-mances pourront ensuite être comparées à celles des autres solutions. Les perforperfor-mances obtenues par chaque solution seront résumées dans un tableau similaire au tableau 2.2. De plus, on peut constater que les autres performances, en termes de gestion de la capacité, de latence, etc ... vont influencer les performances de consommation d’énergie. On peut donc voir cette dernière performance comme un indicateur de l’efficacité globale du système, même s’il est bien sûr nécessaire que chaque paramètre soit observé individuellement.
Durée de vie en année (365 jours) Taille de paquet, GPRS MCL GPRS MCL GPRS MCL périodicité de compte-rendu +0 dB +10 dB +20 dB 50 octets, 2 heures 200 octets, 2 heures 50 octets, 24 heures 200 octets, 24 heures
Table 2.2 – Tableau d’évaluation de la durée de vie moyenne de catégories d’objets du système [11].
Enfin, on citera la méthodologie d’évaluation de la complexité, paramètre qui est sans nul doute le plus difficile à jauger pour l’ensemble d’un système. Le GERAN définit donc quelques métriques, comme la surface de silicium estimée, la quantité de mémoire requise ou la liste des composants externes. Sans une réelle implémentation matérielle il est délicat de s’avancer sur la complexité réelle du système, rendant difficiles les comparaisons entre solutions.