Architecture de Communication pour les Applications Multimédia Interactives dans les Réseaux Sans Fil

Architecture de Communication pour les Applications Multimédia Interactives dans les Réseaux Sans Fil

Amélioration du contrôle d’admission basé sur un scénario SIP 

Pour résoudre ce problème, on propose d’apporter une amélioration à la phase de contrôle d’admission durant l’établissement de la session SIP dans le réseau satellite. Lorsque le proxy SIP du réseau satellite reçoit la liste de codecs que peut supporter la communication, on propose, comme le montre la Figure 43, de réorganiser cette liste de codecs selon les conditions d’admissibilité dans le réseau satellite. Cette amélioration apportée est complètement transparente pour les clients SIP. Lorsque le proxy SIP reçoit le premier message SIP INVITE, il en extrait la liste de codecs    et sauvegarde cette liste initiale dans une base de données. Puis pour chaque codec présent dans la liste, il interroge la base MTR pour obtenir leur débit de transmission associé. Le débit de transmission associé à chaque codec de la liste est alors envoyé au contrôle d’admission pour vérifier leur admissibilité pour la classe avec support de QdS. Les codecs dont le débit ne pourra pas être supporté par le contrôle d’admission sont supprimés de la liste. Une nouvelle liste est Il est primordial d’effectuer ce contrôle d’admission préalable sur le message SIP INVITE, avant qu’il n’arrive au client SIP destinataire. Car une fois que ce dernier répond avec le message SIP OK, la liste de codecs utilisés pour la communication est alors fixée. Si le client destinataire choisit arbitrairement un codec à débit élevé, le contrôle d’admission, en cas de ressources limitées, serait dans l’obligation de refuser le support QdS pour cette communication. Le proxy SIP intègre cette nouvelle liste de codec dans le message SIP INVITE en remplacement de celle initialement fournie par le client SIP appelant. Puis il le transmet au domaine distant (proxy SIP distant puis client SIP appelé). Lorsque le client SIP distant (appelé) reçoit le message SIP INVITE et consulte la nouvelle liste de codecs proposée, deux cas de figure peuvent se présenter : 1. Le client SIP distant supporte au moins l’un des codecs proposés dans la liste modifiée. Il accepte la communication multimédia en répondant avec le message SIP OK. Ce dernier contient la liste avec au moins un codec commun choisi pour la communication. Le proxy SIP reçoit ce message OK et lance une réservation de ressource pour le débit du codec choisi. En effet, ce codec a déjà passé le contrôle d’admission en amont. Ainsi la session multimédia démarre et son flux de données arrivant dans le ST et est dirigé vers la classe de service avec support de QdS. 2. Le client SIP distant ne supporte aucun des codecs proposés dans la liste modifiée. Il renvoie alors un message de refus de communication (415 Unsupported Media Type) jusqu’au proxy SIP du réseau satellite. Cette incompatibilité est peut être causée par la diminution du nombre de codecs, due à la suppression de codecs durant la phase de contrôle d’admission en amont. Dans tous les cas, cela signifie que les codecs compatibles entre les deux clients terminaux ne sont pas admissibles dans le réseau satellite pour un support QdS. Face à ce cas de figure, il est possible de : a. Accepter que la communication soit établie sans support de QdS. Ainsi, lorsque le proxy SIP reçoit le message SIP de refus de communication, on propose de rejeter ce message (c.f. Figure 44). Puis le proxy SIP retransmet un nouveau message SIP INVITE au client appelé (de manière transparente pour le client appelant). Cette fois‐ci, le proxy SIP intègre dans le message SIP INVITE la liste initiale de codecs (sauvegardée) proposée par le client appelant. Ainsi le prochain refus de communication ne sera pas causé par notre contribution. Après cela, si la communication est établie, le flux multimédia sera dirigé vers la classe Best‐Effort et ne recevra pas de support QdS. b. Empêcher l’établissement de la communication multimédia sans support QdS. Par conséquent, le proxy SIP transmet le message de rejet de communication au client SIP appelant. Et la communication ne démarre pas. 3.5.4. 

Adaptation de débit basée sur l’architecture SIP 

Il est toujours possible d’accepter davantage de sessions multimédia dans le réseau en adaptant le débit de transmission des applications multimédia en fonction de la charge du réseau satellite. Pour cela, on propose d’apporter une autre amélioration à notre système de contrôle d’admission en s’appuyant sur un contrôle de débit des flux multimédia présents dans la classe de service dédiée. • Lorsqu’une nouvelle connexion multimédia souhaite démarrer avec support de QdS, et que les ressources disponibles sont insuffisantes, on propose de diminuer la charge de la classe à QdS en diminuant le débit de transmission des autres connexions actuellement en cours. Pour cela, on change leur codec actuel en des codecs de plus faible qualité, requérant moins de bande passante. Ainsi des ressources réseau sont libérées. Ces dernières sont alors utilisées pour admettre et supporter la nouvelle connexion multimédia tout en garantissant une qualité minimum aux autres flux. Ainsi on satisfait le premier critère : supporter une capacité élevée de clients. • Lorsque l’une des connexions multimédia se termine, on propose de redistribuer ses ressources réseau aux autres connexions multimédia toujours actives. Leurs codecs actuels sont alors changés pour des codecs à plus grand débit, leur garantissant un média (audio et/ou vidéo) de meilleure qualité, et à fortiori un meilleur service. Ceci qui garantit le deuxième critère : fournir un service de qualité aux applications multimédia interactives.Pour pouvoir changer le codec des flux actifs présents dans la classe de service de manière transparente pour les clients SIP, il est nécessaire d’avoir connaissance de la liste des codecs capables d’être supportés par chaque flux multimédia en cours. Cette liste est préalablement négociée durant de la phase d’établissement de session. On propose alors d’enregistrer cette liste de codecs et de l’utiliser afin de pouvoir changer de codecs durant la communication multimédia. Deux scénarios typiques permettent de présenter cette amélioration. Réseau Satellite peu chargé Dans le premier scénario, le réseau satellite est peu chargé, la plupart des ressources réseau sont disponibles, par conséquent les demandes d’établissement de session multimédia avec support QdS sont acceptées. Cependant nous proposons tel que décrit en Figure 45, d’enregistrer dans une base de données, toutes les informations des sessions qui s’établissent : les adresses IP et numéros de port des clients SIP, la liste de codecs finale, et le codec choisi pour la communication, l’identifiant de la communication SIP

Réseau Satellite saturé

 Dans ce deuxième scénario, le réseau satellite est complètement saturé. L’ensemble des flux multimédia en cours dans la classe de service avec support QdS occupe la totalité des ressources allouées à cette classe. Dans ce scénario (c.f. Figure 47), durant l’établissement de session, lorsque le contrôle d’admission vérifie l’admissibilité des codecs pour la classe avec support de QdS, aucun des codecs n’est admissible.   Afin d’accepter le nouveau flux multimédia, soit on augmente la capacité maximale de la classe du ST, soit on diminue sa charge actuelle. On choisit de diminuer la charge de trafic présent de la classe de trafic. Pour cela, on propose de diminuer le débit des flux en cours. Sachant que les informations concernant les flux en cours ont été enregistrées dans une base de données, nous utilisons une méthode de changement de codec en cours de communication. Le codec en cours de chaque flux multimédia est remplacé par un codec à plus faible débit d’encodage, donc avec un plus faible débit de transmission. Cela permet alors de libérer des ressources réseau afin d’accepter le nouveau flux.   Afin de choisir le ou les codecs qui remplaceront le codec actuel de chaque flux en cours dans la classe (c.f. Figure 46), les données concernant les flux en cours dans la classe sont récupérées à partir de la base de données (liste de codecs supportables, codec en cours, débits associés, localisation des clients).