SETIT 2009

5th International Conference: Sciences of Electronic,

Technologies of Information and Telecommunications
March 22-26, 2009 – TUNISIA

Gestion de la Qualité de Services par les Règles de

Politiques dans IP au dessus de 802.16
Oumarou HALIDOU et Radouane MRABET
Université Mohammed V - Souissi
Ecole Nationale Supérieure d’informatique et d’Analyse des Systèmes
BP 713 Agdal, Rabat, Maroc
oumarhalid@yahoo.fr
mrabet@ensias.ma

Résumé: Dans cet article nous nous intéressons au standard IEEE 802.16, la dernière avancée technologique dans le
monde des réseaux sans fil. Cette technologie permet de fournir des bandes passantes élevées avec une garantie de la
qualité de services (QdS) au sein de la cellule. Afin de garantir la QdS de bout en bout à travers Internet nous proposons
une plateforme basée sur la gestion des réseaux par politiques (PBNM). Plateforme permettra un déploiement de la
QdS aussi bien au niveau de la cellule 802.16 qu’au niveau IP. Pour atteindre notre objectif, nous avons défini des règles
de mapping pour l’interfaçage des deux couches, et les mécanismes d’ordonnancement des différentes classes de
service.

Mots clés: 802.16, DiffServ, IntServ, QdS de bout en bout, PBMN, PDP, PEP, ordonnancement

Le groupe RAP (Ressource Allocation Protocol)

1. Introduction
La globalisation des technologies Internet et des
communications mobiles ainsi que la convergence de
ces deux mondes, suscitent un très grand intérêt pour
les chercheurs et les industriels et ouvre des
possibilités énormes devant les utilisateurs. On
s’achemine vers une nouvelle génération de réseaux
appelé NGN (Next Generation Networks).
Afin de s’adapter aux grandes tendances qui sont
la recherche de souplesse d’évolution de réseau, la
distribution de l’intelligence dans le réseau, et
l’ouverture à des services tiers, les NGN sont basés
sur une évolution progressive vers le « tout IP » et
sont modélisés en couches indépendantes dialoguant
via des interfaces ouvertes et normalisées.
Dans ce contexte, il devient dangereux, voir
impossible pour de grands réseaux, de configurer
manuellement l’ensemble des équipements du réseau à
cause de l’abondance des informations dont il faut
tenir compte et surtout de leur nature dynamique.
Le recours à des outils de gestion autonomes et
dynamiques se révèle donc indispensable. C’est dans
cette optique que fut créée la gestion par politiques,
couramment appelée PBNM (Policy-Based Network
Management).
de l’IETF est à l’origine de l’architecture utilisée de
nos jours pour la gestion par politiques [Yav 00]. Elle
repose sur un serveur de règles qui interprète et
combine des informations enregistrées dans des bases
de données circonstancielles pour prendre une
décision quant à la politique à adopter ; les directives
sont envoyées aux noeuds du réseau dans un second
temps. L’intérêt est de permettre la mise en place en
temps réel de services supportant par exemple de
nouvelles normes de la qualité de service (QdS) ou de
sécurité.
Dans ce papier, nous nous intéressons à la gestion
qualité de service dans un contexte IP avec le
standard 802.16 comme réseaux d’accès. Nous
proposons une architecture basée sur les PBNM pour
la gestion du réseau.
Dans la section 2 nous rappelons les propositions
de l’IETF pour l’intégration de QdS dans IP. La
section 3 sera consacrée aux mécanismes de QdS
dans le standard 802.16. La section 4 sera consacrée à
la présentation de notre architecture. Nous terminerons
par une conclusion suivit de quelques perspectives
2. Modèle de QdS dans IP
Le réseau Internet, a été basé initialement sur le
principe du Best Effort. Le modèle Best Effort assure
la connectivité sans aucune garantie de la qualité de

-1-
SETIT2009
service (QoS). Quand la mémoire d’un routeur est
saturée, les paquets arrivant sont rejetés. Les
mécanismes de retransmission de TCP recouvrent ces
pertes, garantissant un transfert sans faute de bout en
bout. Bien que le comportement de TCP répond aux
besoins d’applications traditionnellement majoritaires
dans le réseau comme telnet ou ftp, il est peu adapté
pour la transmission des flux avec des contraintes
temporelle (applications de visioconférence ou de
Voix sur IP (VoIP). La discipline de service FIFO n’est
plus suffisante pour satisfaire les contraintes requises
par les différentes applications. Les congestions
allongent les délais, génèrent de la gigue et
provoquent la perte des paquets.
Pour répondre à ces demandes d’amélioration de la
QdS dans l’Internet, l’IETF définit de approche :
IntServ et DiffServ.
L’approche IntServ (Integrated services) représente
la première tentative par l’IETFh pour améliorer la
QdS dans Internet [Bra 94]. La caractérisation
principale de IntServ est de garantir les niveaux de
QdS par un mécanisme de réservation de ressources
par flux.
IntServ inclut deux types de services qui ciblent le
trafic temps réel : service garanti et service prédictif.
Ils fonctionnent correctement en unicast et multicast.
Ces services, implémentés au sein des routeurs,
devraient allouer aux flots une certaine qualité de
service, à chaque traversée des routeurs, pour les
acheminer jusqu’à destination avec cette QdS. Il est
donc nécessaire de disposer de mécanismes de
réservation de ressources pour obtenir ces services.
Pour cela, l’émetteur envoie une requête de
réservation de bande passante qui doit être acceptée
par l’ensemble des équipements qui seront traversés
par les flux. La réservation s’effectue au moyen du
protocole RSVP [Bra 97]. Cependant, cette solution
s’est avérée insuffisante pour des réseaux à large
dimensionnement. IntServ n’est pas propice à des
réseaux de grande envergure.
C’est pourquoi un second groupe de travail a
abordé le problème en proposant une garantie se
service basée sur la différenciation de service. Le
groupe DiffServ (Differentiated Services) fonde son
concept sur une gestion de trafic par classe, sur des
méthodes de conditionnement du trafic à l’entrée du
réseau et sur le marquage de celui-ci en fonction de
son appartenance à une classe, pour un traitement
spécifique [Bla 98]. Trois principaux services de
DiffServ sont mis en oeuvre : le service « Best-Effort
» pour les paquets à traiter « au-mieux » comme le fait
Internet actuellement ; le service « Assured
Forwarding » [Hei 99] pour des classes à priorité plus
grande que le « Best-Effort » ; enfin le service «
Expedited Forwarding » [Dav 02] pour les classes les
plus prioritaires.
3. Mécanisme de la QdS dans 802.16
Le Standard 802.16 commercialement appelé
WiMAX (Worldwide Interoperability for Microwave
-2-
Access), a été adopté comme la solution aux réseaux
sans fils large bande (Broadband Wireless Access)
[Air 04]. Il permet des connexions sans-fil à haut débit
sur des zones de couverture de plusieurs kilomètres,
permettant des usages en situation fixe ou en mobilité.
Cette technologie permet de fournir des hauts débits et
une QdS implantée dans le standard dès sa conception.
Divers mécanismes ont été introduits dans 802.16
pour l’approvisionnement et la gestion de la QdS.
Dans les paragraphes suivantes nous allons décrire les
mécanismes implémentés au niveau de la couche
MAC à savoir la notion de service flow et la demande
et l’allocation de la bande passante.
3.1. Service flow
Le principal mécanisme pour fournir la qualité de
service est le fait d’associer un paquet de données à un
flux de service (service flow). Le flux de service est
une notion capitale dans le standard. Chaque
connexion est liée à un SFID (Service Flow
IDentifier) qui identifie les spécificités du flux de
données en termes de besoins en QdS. WiMAX
supporte cinq types de flux de service :

Unsolicited Grant Service (UGS) : Ce
type de service est utilisé pour supporter
des flux temps réel générant des paquets
de taille fixe et de façon périodique
comme VoIP (Voice over IP). Il offre une
garantie stricte du débit et du temps de
latence.

Extended rtPS : c’est une combinaison
entre UGS et rtPS. A la différence d’UGS,
la taille des paquets peut être modifiée
durant la vie d’une connexion suite à une
requête émise par une SS

real time Polling Service (rtPS): Service
supportant des paquets de données de
tailles variables. Ce sont en général des
flux multimédia comme la vidéo MPEG.
Il offre des garanties pour le débit avec
une grande tolérance vis-à-vis du temps
de latence.

non real time Polling Service (nrtPS): Ce
service garantit seulement le débit, il est
destiné pour des applications ne
dépendant pas du temps de latence
(comme par exemple les emails). C’est le
service qui supporte des profiles de burst
très variés.

Best Effort Service (BES) : Ce service ne
donne pas de garantie, mais offre toutes
les possibilités pour n’importe quelle
application. Il est surtout destiné pour des
applications comme l’accès au Web
3.2. Demande et allocation de la bande passante
A chaque connexion, la station de base demande
de la bande passante à travers un message MAC dit «
Bandwidth Request message ». Cette demande peut
SETIT2009
être envoyée soit dans un paquet autonome ou dans un
paquet de données (piggyback). La requête est basée
sur le nombre d’octets nécessaires pour transporter les
MAC PDUs sans compter la surcharge de la couche
physique.
La demande peut être soit incrémentale signifiant
combien de bande passante additionnelle a-t-on besoin
ou agrégée signifiant combien de bande passante
totale a-t-on besoin. Avec la demande piggyback, la
connexion ne peut faire qu’une demande incrémentale
alors que les deux sortes de demandes à savoir
incrémentale et agrégée sont acceptées par une
demande autonome.
L’allocation de la bande passante est strictement
dépendante des paramètres QdS demandés et des
ressources disponibles dans le réseau. Bien que la
demande est faite par connexion, la BS répond en
allouant la bande passante non pas par connexion mais
par SS. La tâche revient à la SS de répartir cette bande
passante entre ses différentes connexions. WiMAX
définit trois principales procédures d’allocation de
bande passante :

« unsolicited bandwidth grants » ou
allocation de bande non réclamée,

« polling » ou allocation de bande par
système d’interrogation des SSs,

« contention procedures » ou allocation
de bande selon un système de contention.
L’utilisation de ces procédures se fera en fonction
des données devant être transmises, pour les
applications temps réel par exemple, la station de base
envoie un message de polling à chaque station et ces
dernières répondent par les messages de requête de
bande passante.
4. Architecture IP au dessus de 802.16
Un des atouts majeurs d’IEEE 802.16 par rapport à
son prédécesseur IEEE 802.11 (Wifi) est le fait
d’intégrer la notion de la QdS dès sa conception. Mais
l’approvisionnement de QdS dans le standard se limite
seulement au niveau des connexions entre la BS et les
différentes SS qui lui sont attaché. Dans un contexte
de déploiement général de WIMAX, on retrouvera des
architectures ou les BS sont interconnectées via
l’Internet « Best Effort » (figure 1).
Figure 1: cellules 802.16 interconnectées via Internet
-3-
Ainsi pour avoir une QdS de bout en bout il faudra
développer des mécanismes supplémentaires pour
l’interconnexion de cellules 802.16 à travers IP.
Nous proposons une architecture fonctionnelle à
QdS multicouches ( la couche 802.16 et IP) présentée
à la figure 2. Cette architecture est basée sur les
modèles IntServ et DiffServ. Nous considérons que les
BS jouent le rôle de routeur de bordure. Nous avons
défini deux blocs fonctionnels : le SPM (Service
Provider Module) et le RCM (Resources Control
Module). Par ailleurs, on a défini des règles de
mapping entre les services et paramètres des
différentes couches.
Figure 2: architecture générale
4.1. SPM (Service Provider Module)
Le SPM assure plusieurs fonctions dans notre
architecture. Il est responsable du contrôle et de la
gestion de toutes les ressources du domaine.
Le SPM intègre les fonctionnalités d’un PDP
(Policy Decision Point). Au départ, il choisit les règles
de politique qu’il appliquera à un utilisateur en
considérant les informations du SLA-SLS négocié
avec l’utilisateur. Ces décisions sont ensuite envoyées
d’une manière asynchrone vers les RCM via le
protocole COPS [Dur 00] pour réaliser la
configuration décidée. Le SPM effectue un calcul de
probabilité en fonction de tous les SLA-SLS des
clients abonnés puis envoie l’information de
configuration au RCM, telle que le changement de
politique demandé directement par l’utilisateur en
modifiant son abonnement, à une heure
prédéterminée, à l’expiration d’un compte, etc. Le
RCM confirme que l’installation de configuration est
réussie à la suite du message de configuration.
Le SPM est en quelque sorte un organe de décision
qui recherche les informations dont il a besoin dans de
nombreux serveurs qui communiquent directement
avec lui de façon à prendre une décision. Ces serveurs
peuvent être locaux, ce qui est le cas le plus général,
mais ils peuvent aussi être distants. Les serveurs les
plus couramment utilisé sont :

La base de données des politiques (Policy
Repository) est en charge du stockage des
SETIT2009
règles de QdS (ou autre…). L’IETF
préconise l’utilisation d’annuaires pour
implémenter le Policy Repository et celle
du protocole LDAP (Lightweight
Directory Access Protocol) pour y
accéder.

Le gestionnaire de bande passante
(Bandwidth Broker) connaît la topologie
et les caractéristiques du réseau ce qui lui
permet de distribuer les ressources à bon
escient.

Le gestionnaire de sécurité (Security
Brocker) est généralement un serveur
AAA (Authentification, Autorisation and
Accounting).

Le serveur de mobilité (Mobility Brocker)
peut gérer la continuité du service
(comme la QdS) pendant un déplacement.

Le serveur de facturation sera essentiel
lorsque les réseaux feront de la QdS car
sans différenciation tarifaire entre les CoS
(Class of Service) il est impossible de
mettre en place une quelconque qualité de
service.
4.2. RCM, Resources Control Module
Le RCM est le composant central de notre
architecture. Il doit être présent dans tous les routeurs
de bordure. Il peut être vu comme une couche
intermédiaire entre la sous-couche « Service Specific
Convergence Sublayer » de la couche 802.16 et
DiffServ ou IntServ, dans le sens où c’est lui qui
effectue le mapping des paramètres QdS entre les
deux niveaux. Il intègre aussi le module AM
(Authorization Module) qui s’occupe localement du
contrôle de politique et du contrôle d’admission sur la
base des ressources qu’il s’est vu allouer par le SPM.
Le RCM intègre en même temps les
fonctionnalités d’un PDP et d’un PEP. Vu par le
SPM, le RCM est une PEP munie d’un LPDP.
L’intérêt est que le RCM pourra prendre lui-même une
première décision dans certaines circonstances pour
appliquer une décision locale (perte de la connexion
entre le RCM et le SPM, attente de décision trop
longue, …) mais le SPM conserve dans tous les cas
son autorité. Ce qui veut dire qu'une décision locale
doit être transmise au SPM dès que possible par un
objet de décision LPDP que le serveur de règles
confirmera ou remplacera.
Ainsi lorsqu’une application demande un service
avec QdS, le RCM interroge d’abord son PDP local.
Après avoir récupérer la réponse de celui-ci, deux
possibilités peuvent se présenter :

Soit le SPM est injoignable à cause d’une
panne. Le RCM applique alors cette
décision.

Soit le réseau fonctionne correctement.
Dans ce cas, le RCM envoie au SPM la
-4-
décision de local PDP accompagnée de la
question d’origine. Le SPM prend en
compte cette décision et d’autres
informations globales puis retourne la
décision finale prévalant sur celle du
local PDP se trouvant dans le RCM.
L’intérêt de ce mécanisme est double :

En temps normal, on peut imaginer que le
RCM dispose d’informations locales
inaccessibles au SPM. C’est pourquoi le
SPM doit tenir compte de la décision du
local PDP du RCM même s’il n’est pas
tenu de la suivre.

Lorsque le RCM ne peut plus joindre le
SPM, son local PDP lui permet de
continuer à fonctionner de façon
autonome au moins pendant un certain
temps. Cela suppose cependant que les
politiques que le local PDP a en mémoire
sont à jour par rapport à celles du SPM.
Aussi, le RCM gère la souscription et la
négociation des SLA (Service Level Agreement) entre
le domaine réseaux et les utilisateurs ou entre
domaines. Pour ce faire nous utilisons le protocole
COPS-SLS [Tra 03].
En effet, COPS-SLS est une extension du
protocole COPS qui a été développée pour la
négociation dynamique de SLS intra et inter domaine.
COPS-SLS permet, en particulier, d’échanger des
paramètres techniques caractérisant un niveau de
service (i.e. Service Level Specification) entre un
client et un réseau ou entre deux réseaux entre eux.
COPS-SLS est le premier protocole qui propose de
mettre le PEP dans un équipement terminal. Dans les
extensions indiquées précédemment, le PEP était mis
dans les équipements réseaux avec pour but de gérer
les routeurs du réseau (routeurs de bord, routeurs
coeur…). Dans le contexte d’une négociation de SLS,
mettre le PEP dans l’équipement terminal est une
solution originale permettant d’introduire la meilleure
politique correspondant à chaque type de client ou
même à chaque client.
L'intérêt de ce protocole concerne d’une part la
négociation du SLS par une automatisation du
processus : le client peut facilement gérer son SLS en
entrant en contact avec le RCM sur lequel il est
connecté. COPS-SLS peut également gérer
dynamiquement les modifications de SLS lors du
déplacement du client pour lui assurer une continuité
dans sa QdS. L'idée de COPS-SLS est d'appliquer la
technologie de gestion par politique pour la gestion
des niveaux de service dans un domaine. Le SPM crée
des politiques de négociation de SLS du domaine. Ces
politiques reflètent la stratégie de négociation du SPM
et permettent au PDP de savoir comment répondre à
une demande de SLS ou de modification du SLS.
SETIT2009

4.3. Règles de mapping entre services

Après une étude comparative des différentes
classes de services DiffServ, IntServ et WiMAX, nous
constatons que les classes EF de DiffServ, Guaranted
de Intserv et UGS du 802.16 ont les mêmes
caractéristiques. Elles ont pour but de fournir une
garantie de bande passante avec des taux de perte,
délai et gigue faibles. Elles sont destinées aux
applications temps réel comme la téléphonie sur IP.
Les services rtPS, ertPS et nrtPS ont aussi des
caractéristiques similaires à la famille AF DiffServ et
Controlled Load de IntServ. les Best Effort (BE)
seront associées entre elles. Figure 3: Ordonnancement dans DiffServ

Le tableau ci-dessus présente ces différentes

règles.
Classe Intserv Classe DiffServ Classe WiMAX

Guaranted EF UGS

Controlled Load AF rtPS,ertPS, nrtPS

BE BE BE

Tableau1: Correspondance entre les classes de services

4.4. Schémas d’ordonnancement

Dans l’architecture DiffServ, le traitement
différencié des paquets s’appuie sur trois opérations
fondamentales : la classification des flux en classes de
service, l’introduction de priorités au sein des classes
(Scheduling) et la gestion du trafic dans une classe
donnée (Queue Management). La deuxième opération
est assurée par les algorithmes d’ordonnancement,
servant à contrôler la distribution de ressources entre
les classes de service. Dans ce travail, nous utilisons
deux types d’Ordonnanceurs : PQ (Priority Queueing)
et WFQ (Weighted Fair Queuing).
L’algorithme d’ordonnancement basé sur des
priorités strictes (PQ) peut être utilisé pour offrir un
très faible délai pour la classe la plus prioritaire, ce qui
est désirable pour des applications à contraintes temps
réel très sensibles aux délais telles la voix sur IP. Nous
attribuons la priorité absolue aux paquets EF et UGS.
Dans l’algorithme d’ordonnancement WFQ on
associe à chacune des classes de service un poids
positif. Ce poids spécifie la capacité minimum
garantie pour la classe. En particulier, si une classe
n’utilise pas la totalité de sa capacité, alors l’excès de
capacité est distribué aux autres classes.
Figure 4: Ordonnancement dans le standard 802.16
Ainsi, comme illustré sur la figure 3 et 4, dans un
premier niveau les paquets des classes AF et BE sont
classifiés dans une fille d’attente à l’aide de
l’algorithme WFQ, idem pour ceux des services rtPS,
nrtPS et BE de WiMAX. Au deuxième niveau nous
appliquons une politique PQ entre la file issue de
l’ordonnanceur WFQ et la fille de la classe EF dans
DiffServ ou UGS au niveau de WiMAX. Nous
appliquons les memes principes pour les classes de
services Intserv.
5. Conclusion
Dans cet article, nous avons présenté une
architecture basé sur le standard 802.16 garantissant
une qualité de service de bout en bout à travers
Internet. Dans un premier temps, nous avons mis en
évidence les divers mécanismes de gestion de la QdS
dans les différentes couches, montrant ainsi les
limites de la gestion de la QdS au niveau des cellules
du standard 802.16.
Ainsi pour fournir aux stations mobiles (MS) une
QdS de bout en bout nous avons décidé de coupler le
standard 802.16 avec les modèle d’architecture définit
par IETF pour l’approvisionnement de la QdS. Cette
prise en charge de la QdS aux niveaux des deux
couches permettra un déploiement à grande échelle
des services à fortes contraintes de QdS à travers
Internet.
Pour automatiser la gestion d’une telle architecture

-5-
SETIT2009

et le processus de négociation des contrats de services

nous utilisons les règles de politiques avec les le
protocole COPS et son extension COPS-SLS.
Chaque couche ayant ces propres spécificités et
contraintes, nous avons définit des règles de mapping
pour le passage du trafic dans les deux. Aussi nous
avons choisi les algorithmes d’ordonnancement
adéquats pour garantir la différenciation des services

REFERENCES
[Yav 00] R. Yavatkar, D Pendarakis :A Framework for
Policy-based Admission Control RFC 2753, January
2000
[Bra 94] R. Braden, D. Clark, S. Shenker,: Integrated
Services in the Internet Architecture: an overview,
RFC 1633, Juin 94.
[Bra 97] R. Braden, et al : Resource ReSerVation
Protocol (RSVP), RFC 2205, Septembre 1997.
[Bla 98] S. Black et al: An Architecture for
Differentiated Services , RFC 2475, Déc 1998.
[Hei 99] J. Heinanen et al : Assured Forwarding
PHB, RFC 2597, Juin 1999.
[Dav 02] B. Davie et al : An Expedited Forwarding
PHB (Per-Hop Behaviour) , RFC 3246, Mars 2002.
[Air 04] Air Interface for Fixed Broadband Wireless
Access Systems , IEEE Standard 802.16-2004;
[Nic 99] K. Nichols et al., «Two-bit Differentiated
Services Architecture », RFC 2638, Juillet 1999.
[Tra 03] Trang Nguyen TM, Boukhatem N.;
Doudane, Y.G.; Pujolle, G. COPS-SLS usage for
dynamic policy-based QoS management over
heterogeneous IP networks. IEEE Communications
Magazine, Vol. 17, n°3, May-June 2003.

[Dur 00] The COPS (Common Open Policy Service)

Protocol RFC 2748 D. Durham, J. Boyle, R. Cohen,
S. Herzog, R. Rajan, A. Sastry Janvier 2000

-6-