FR3016108B1

FR3016108B1 - Gestion de la qualite des applications dans un systeme de communication cooperatif

Info

Publication number: FR3016108B1
Application number: FR1403047A
Authority: FR
Inventors: David Gell; Stanwood Kenneth L.; Haibo Xu; Chinnathambi Gopinath Murali; Erik Colban
Original assignee: Taiwan Semiconductor Manufacturing Co TSMC Ltd; WiLAN Labs Inc
Current assignee: Taiwan Semiconductor Manufacturing Co TSMC Ltd
Priority date: 2013-12-30
Filing date: 2014-12-30
Publication date: 2019-06-28
Anticipated expiration: 2034-12-30
Also published as: KR102234927B1; KR20150079463A; FR3016108A1

Abstract

Un nœud de gestionnaire d'application dans un réseau de communication, comprenant un module émetteur/récepteur configuré pour surveiller la communication des données dans un réseau de communication, et un processeur couplé à l'émetteur/récepteur et configuré pour recevoir, à partir d'au moins un nœud terminal, des informations d'applications apparentées à au moins un flux de données d'application associé à au moins une application fonctionnant dans l'au moins un nœud terminal, la mise à jour, basée sur les informations d'application, d'une carte de relations qui comprend une relation entre chacun de l'au moins un flux de données d'application et un nœud d'accès, la détermination d'une valeur du critère de qualité globale associée au nœud d'accès basé au moins en partie sur les informations d'application reçues à partir de l'un ou de plusieurs de l'au moins un nœud terminal, et la sélection, en fonction de la valeur de critère de qualité globale, d'au moins une option d'atténuation pour l'un ou plusieurs de l'au moins un flux de données d'application.

Description

GESTION DE LA QUALITÉ DES APPLICATIONS DANS UN SYSTÈME DE COMMUNICATION COOPÉRATIF

RÉFÉRENCE CROISÉE AUX DEMANDES APPARENTÉES

Cette demande est en partie une continuation de la demande de brevet américain no. 13/744 101, déposée le 17 janvier 2013 et intitulée « Systems and Methods for Cooperative Applications in Communication Systems », qui est en partie une continuation de la demande de brevet américain no. 13/653 239, déposée le 16 octobre 2012 et intitulé « Systems and Methods for Cooperative Applications in Communication Systems », qui revendique les avantages de la demande américaine provisoire no. 61/658 774, déposée le 12 juin 2012 et intitulée « System and Method for Cooperative Applications in a Communication System » et la demande américaine provisoire no. 61/579 324, déposée le 22 décembre 2011 et intitulée « Congestion Induced Video Scaling ».

HISTORIQUE

La présente invention concerne généralement le domaine des systèmes de communication et la mise en œuvre, Tutilisation et la gestion des applications coopératives dans des systèmes de communication.

Dans un réseau de communication, tel qu’un réseau à protocole Internet (IP), chaque nœud et chaque sous-réseau possède des limites quant à la quantité de données qui peuvent réellement être transportées à un moment donné. Dans un réseau câblé, ceci est souvent une fonction de la capacité de l’équipement. Par ex., une liaison Ethernet gigabit peut transporter un maximum de 1 milliard d’octets de données par seconde. Dans un réseau sans fil, la capacité est limitée par la largeur de bande du canal, la technologie de transmission et les protocoles de communication utilisés. Un réseau sans fil est également contraint par la quantité de spectres permis vers une zone de service et par la qualité du signal entre les systèmes d’envoi et de réception. Étant donné que ces aspects peuvent être dynamiques, la capacité d’un système sans fil peut varier au cours du temps.

Historiquement, les systèmes de communication ont séparé les données en classes de service (CoS) dans le cœur, tels que dans une passerelle de paquet (P-GW) dans un système LTE. Ceci présente l’avantage que les services fournis par un opérateur, tels que la voix et la vidéo, provenant de son propre réseau ou d’un réseau de diffusion de contenu (CDN) coordonné peuvent être dotés de garantie de qualité de service (QoS) telle qu’un débit d’octets garantie (GBR). Le trafic qui n’est pas associé aux services fournis par l’opérateur est généralement moins différencié, entraînant des données groupées hétérogènes dans le même CoS. En outre, ce trafic est souvent doté de ressources sur le principe du meilleur effort, ignorant les besoins en QoS de l’application spécifique qui génère le trafic, et ignorant la qualité de l’expérience (QoE) perçue par l’utilisateur final.

Le trafic de communication additionnel peut être assuré par des services OTT (« over-the-top »), c.-à-d., des services qui ne sont pas fournis ou coordonnés par l’opérateur. La communication vocale sur protocole Internet (VoIP) de Skype, la vidéo en téléchargement progressif de YouTube, le flux vidéo de Netflix et le flux audio de la radio Pandora sont des exemples de services OTT. Les services voix et vidéo de l’OTT ont tendance à être regroupés sous forme de trafic de meilleur effort accompagné du service e-mail, le réseautage social et le transfert de fichier. Lorsqu’un réseau est congestionné, les services OTT sont généralement tous traités de la même façon quel que soit l’impact sur la qualité perçue par l’utilisateur final. Ils sont généralement programmés comme le même CoS. En outre, les services OTT sont généralement regroupés dans le même porteur logique. Dans les systèmes de communication d’aujourd’hui, le contrôle de l’admission est réalisé sur la base d’un porteur logique sans tenir compte du mélange de service sur le porteur. Par conséquent, des services en temps réel tel que la voix, le flux vidéo et le flux audio sont perçus comme ayant une dégradation importante de la QoE par rapport à des services différés tels que l’e-mail.

RESUME

Des systèmes, des dispositifs et des procédés pour des applications corporatives dans des systèmes de communication sont décrits. Dans un aspect, l’invention décrit un nœud de gestionnaire d’application dans un réseau de communication, comprenant un module émetteur/récepteur configuré pour surveiller la communication des données dans un réseau de communication, et un processeur couplé à l’émetteur/récepteur et configuré pour recevoir, à partir d’au moins un nœud terminal, des informations d’applications apparentées à au moins un flux de données d’application associé à au moins une application fonctionnant dans l’au moins un nœud terminal, la mise à jour, basée sur les informations d’application, d’une carte de relations qui comprend une relation entre chacun de l’au moins un flux de données d’application et un nœud d’accès, la détermination d’une valeur du paramètre de la qualité globale associée au nœud d’accès basée au moins en partie sur les informations d’application reçues à partir de l’un ou de plusieurs de l’au moins un nœud terminal, et la sélection, en fonction de la valeur de paramètre de qualité globale, d’au moins une option d’atténuation pour l’un ou plusieurs de l’au moins un flux de données d’application.

Dans un autre aspect, l’invention décrit un nœud terminal dans un réseau de communication comportant un nœud d’accès, comprenant un module émetteur/récepteur configuré pour envoyer des paquets de données vers, et de recevoir des paquets de données de, le nœud d’accès à travers le réseau de communication, et un processeur couplé à l’émetteur/récepteur et configuré pour détecter au moins un flux de données d’application en surveillant les paquets de données envoyés vers, et reçus de, le nœud d’accès à travers le réseau de communication, la détermination, pour chacun de l’au moins un flux de données d’applications détecté, des informations d’application apparentées à une application fonctionnant dans le nœud terminal qui est associé au flux de données d’application respectif, les informations d’application comprenant un paramètre de qualité du flux de données pour chaque flux de données d’application respectif, l’envoi, à travers le réseau de communication, des informations d’application pour chacun de l’au moins un flux de données d’application détecté, la réception, à travers le réseau de communication, d’au moins une instruction d’atténuation associée à un ou plusieurs de Tau moins un flux de données d’application, et la mise en œuvre de Tau moins une instruction d’atténuation pour l’un ou plusieurs de Tau moins un flux de données d’application associé.

Dans un aspect, l’invention décrit un procédé de gestion de la qualité d’application dans un réseau de communication, le procédé comprenant les étapes de réception d’au moins un nœud terminal, des informations d’applications apparentées à au moins un flux de données d’applications associé à au moins une application fonctionnant dans Tau moins un nœud terminal, la mise à jour, basée sur les informations d’application, d’une carte de relations qui comprend une relation entre chacun de l’au moins un flux de données d’application et un nœud d’accès, la détermination d’une valeur du paramètre de qualité globale basée au moins en partie sur les informations d’application reçues de l’un ou de plusieurs de l’au moins un nœud terminal, et la sélection, en fonction de la valeur du paramètre de qualité globale, d’au moins une option d’atténuation pour l’un ou plusieurs de Tau moins un flux de données d’application.

Dans un autre aspect, l’invention décrit un procédé pour la gestion de la qualité d’application dans un nœud terminal à l’intérieur d’un réseau de communication, le procédé comprenant la détection d’au moins un flux de données d’application en surveillant les paquets de données envoyés vers, et reçus de, un nœud d’accès dans le réseau de communication, la détermination, pour chacun de Tau moins un flux de données d’application détecté, des informations d’application apparentées à une application fonctionnant dans le nœud terminal qui est associé au flux de données d’application respectif, les informations d’application comprenant un critère de la qualité du flux de données pour chaque flux de données d’application respectif, et l’envoi, à travers le réseau de communication, des informations d’application pour chacun de Tau moins un flux de données détecté. Le procédé comprend également la réception, à travers le réseau de communication, d’au moins une instruction d’atténuation associée à l’un ou plusieurs de Tau moins un flux de données d’application, et la mise en œuvre de Tau moins une instruction d’atténuation pour un ou plusieurs de Tau moins un flux de données d’application associé. D’autres caractéristiques et avantages de la présente invention seront apparents à partir de la description suivante qui illustre, avec des exemples, les aspects de l’invention.

BREVE DESCRIPTION DES FIGURES

Les détails de la présente invention, à la fois concernant sa structure et son fonctionnement, peuvent être glanés en partie en étudiant les figures ci-jointes, dans lesquelles les chiffres de référence semblables correspondent à des parties semblables, et dans lesquelles : la FIG. 1 est un schéma d’un réseau de communication dans lequel les systèmes et les procédés divulgués ici peuvent être mis en œuvre conformément aux aspects de l’invention 5 la FIG. 2 est un schéma d’un nœud d’accès conformément aux aspects de l’invention ; la FIG. 3 est un schéma d’un nœud terminal conformément aux aspects de l’invention ; la FIG. 4 est une figure illustrant les aspects d’un nœud d’accès conformément aux aspects de l’invention ; la FIG. 5 est un schéma d’un système de communication qui illustre les relations du plan de commande conformément aux aspects de l’invention ; la FIG. 6 est un schéma des agents d’application et des applications conformément aux aspects de l’invention ; la FIG. 7 est un schéma d’un système de communication comportant des agents d’application et des applications conformément aux aspects de l’invention ; la FIG. 8 est un schéma d’un autre système de communication comportant des agents d’application et des applications conformément aux aspects de l’invention ; la FIG. 9 est un schéma d’un module d’inspection de paquet conformément aux aspects de l’invention ; la FIG. 10 est un schéma d’un environnement d’un réseau de communication comprenant un module de gestion de la qualité de l’expérience conformément aux aspects de l’invention ; la FIG. 11 est un schéma d’un environnement d’un réseau de communication comprenant un module de gestion de la qualité de l’expérience avec d’autres aspects de l’invention ; la FIG. 12 est un schéma d’un module d’application maître dans un nœud terminal qui supporte la gestion de la qualité de l’expérience conformément aux aspects de l’invention ; la FIG. 13 est un schéma d’un module de gestion de la qualité de l’expérience conformément aux aspects de l’invention ; la FIG. 14 est un organigramme illustrant la fonctionnalité d’un module d’application maîtresse dans un nœud terminal qui supporte la gestion de la qualité de l’expérience conformément aux aspects de l’invention ; la FIG. 15 est un organigramme illustrant la fonctionnalité d’un module de gestion de la qualité de l’expérience conformément aux aspects de l’invention ; la FIG. 16 est un organigramme illustrant la fonctionnalité d’atténuation d’un module d’application maîtresse dans un nœud terminal qui supporte la gestion de la qualité de l’expérience conformément aux aspects de l’invention ; la FIG. 17 est un schéma d’un module d’application maîtresse dans un nœud terminal qui effectue la gestion de la qualité de l’expérience conformément aux aspects de l’invention ; et la FIG. 18 est un organigramme illustrant la fonctionnalité d’un module d’application maîtresse dans un nœud terminal qui effectue la gestion de la qualité de l’expérience conformément aux aspects de l’invention.

DESCRIPTION DETAILLEE

Des systèmes et des procédés des systèmes de communication possédant des services de planification et de contrôle d’admission qui sont orientés vers les besoins d’application sont décrits. La coopération et la communication entre les applications de l’équipement utilisateur et le poste de base orienté applications (ou d’autres nœuds de réseau) peuvent améliorer la qualité de l’expérience (QoE) des utilisateurs. Les systèmes et les procédés sont particulièrement utiles dans des systèmes de communication multi-accès, limités par la capacité et le spectre. Dans un aspect, les systèmes et les procédés décrits ici peuvent être utilisés avec des classes de services qui sont associées aux flux de données ou aux flux provenant d’application hétérogènes.

Les systèmes et procédés divulgués ici peuvent être appliqués à divers systèmes de communication limitée par la capacité, y compris les technologies sur fil ou sans fil. Par ex., les systèmes et procédés divulgués ici peuvent être utilisés avec le 2G, 3G, 4G cellulaire (y compris la technologie d’évolution à long terme (LTE), la LTE avancée et le WiMAX), le raccordement cellulaire, le Wi-Fi, la large-bande ultramobile (UMB), le modem câble, ou d’autres technologies sur fil ou sans fil point-à-point ou point-à-multipoint. Pour un exposé concis, divers modes de réalisation sont décrits utilisant la terminologie et l’organisation des technologies et normes particulières. Cependant, les systèmes et les procédés décrits ici sont largement applicables à d’autres technologies et normes.

La FIG. 1 est un schéma d’un réseau de communication dans lequel les systèmes et les procédés divulgués ici peuvent être mis en œuvre conformément aux aspects de l’invention. Un poste de base macro 110 est connecté à un réseau central 102 à travers un réseau terrestre 170. Dans un mode de réalisation, le réseau terrestre 170 est une liaison bidirectionnelle ou deux liaisons unidirectionnelles. La direction à partir du réseau central 102 vers le poste de base macro 110 est appelée la direction avale ou descendante (DL). La direction à partir du poste de base macro 110 vers le réseau central 102 est appelée la direction amont ou ascendante (UL). Les postes d’abonnés 150(1) et 150(4) peuvent se connecter au réseau central 102 à travers le poste de base macro 110. Les liaisons sans fil 190 entre les postes d’abonnés 150 et le poste de base macro 110 sont des liaisons point-à-multipoint bidirectionnelles, dans un mode de réalisation. La direction des liaisons sans fil 190 à partir du poste de base macro 110 vers les postes d’abonnés 150 est appelée la direction descendante ou avale. La direction des liaisons sans fil 190 à partir des postes d’abonnés 150 vers le poste de base macro 110 est appelée la direction ascendante ou amont. Les postes d’abonnés sont quelquefois appelés l’équipement utilisateur (UE), utilisateurs, appareils utilisateur, combiné mobile, nœuds terminaux ou terminaux utilisateur et sont souvent des dispositifs mobiles tels que des téléphones intelligents ou des tablettes. Les postes d’abonnés 150 accèdent au contenu à travers les liaisons sans fil 190 utilisant les postes de base, tels que le poste de base macro 110, comme un pont. C.-à-d., les postes de base transfèrent généralement des données d’application de l’utilisateur et les messages de commande de l’application utilisateur entre les postes d’abonnés 150 et le réseau central 102 sans que le poste de base ne soit une destination pour les données et les messages de commande ou une source pour les données et les messages de commande. Dans la configuration de réseau illustrée dans FIG. 1, un immeuble à bureaux 120(1) cause une zone d’ombre de couverture 104. Un poste pico 130 peut procurer une couverture à des postes d’abonnés 150(2) et 150(5) dans la zone d’ombre de couverture 104. Le poste pico 130 est relié au réseau central 102 par une connexion terrestre 170. Les postes d’abonnés 150(2) et 150(5) peuvent être reliés aux postes pico 130 à travers des liens qui sont semblables aux où les mêmes que les liaisons sans fil 190 entre les postes d’abonnés 150(1) et 150(4) et le poste de base macro 110.

Dans l’immeuble à bureaux 120(2), une femtocell 140 pour entreprise assure une couverture à l’intérieur du bâtiment aux postes d’abonnés 150(3) et 150(6). La femtocell 140 de l’entreprise peut se connecter au réseau central 102 à travers un réseau de fournisseur de service Internet 101 en utilisant une connexion à bande large 160 fournie par la passerelle d’entreprise 103.

Afin d’aider à l’attribution des ressources de communication limitées, les systèmes de communication précédents ont séparé les données par classes de service (CoS) dans le réseau central, tel que dans une passerelle de paquet (P-GW) dans un système LTE. Le trafic à l’intérieur du CoS sont souvent traité de façon semblable dans le but de programmer les allocations de ressources. Le trafic dans des CoS différents est souvent traité séparément dans le but de programmer les allocations de ressources. Ceci permet aux services fournis par un opérateur, tels que la voix et la vidéo, provenant du réseau de l’opérateur ou d’un réseau de diffusion de contenu (CDN), d’être dotés de garantie QoS telle qu’un débit d’octets garanti (GBR).

Le trafic qui n’est pas associé aux services fournis par un opérateur peut être appelé le trafic OTT. Les systèmes précédents n’avaient généralement que très peu ou pas de différenciation entre les divers types de trafic OTT. Ainsi, le trafic hétérogène peut être regroupé dans le même CoS. En outre, ce trafic est généralement doté de ressources sur une base du meilleur effort avec, par ex., aucune garantie de débit d’octets. Ainsi, les systèmes précédents ignorent les besoins QoS pour l’application spécifique générant le trafic OTT et ignorent la qualité de l’expérience (QoE) perçue par l’utilisateur final. En particulier, les services OTT de voix et de vidéo, tels que la voix sur IP de Skype (VoIP), la vidéo en téléchargement progressif de YouTube, le flux vidéo de Netflix, les appels vidéo Facetime et le flux audio de la radio Pandora auraient pu être regroupés ensemble sous forme de données de meilleur effort avec l’e-mail, le réseau social et le transfert de fichiers. Lorsque le réseau est congestionné, ces services sont généralement tous traités de la même façon quelle que soit l’impact sur la qualité perçue par l’utilisateur final. Par conséquent, des services en temps réel (tel que la voix, le flux vidéo et le flux audio) sont perçus comme ayant une dégradation importante de la QoE par rapport à des services différés (par ex., l’e-mail).

Dans le réseau de communication de la FIG. 1, et dans d’autres réseaux sur fil et sans fil, on peut attribuer une importance et un niveau souhaité de performance à un ou plusieurs flux de données ou services. L’importance et le niveau souhaité de performance peuvent être utilisés pour attribuer des paquets à partir de chaque flux de données à un groupe de planification ou une file d’attente de données. Un algorithme de planification peut également utiliser les informations pour décider quelles files d’attente (et donc quels flux de données ou paquets) doivent être traitées de façon préférentielle par rapport aux autres. Les algorithmes de planification peuvent utiliser des pondérations de planification pour transmettre l’importance et le niveau de service souhaité de chaque file d’attente. Par ex., des procédés de planification de pondération circulaire (WRR) et de file d’attente équitable pondérée (WFQ), qui utilisent, les deux, une pondération pour ajuster le service parmi les files d’attente de données, peuvent être utilisés. Les algorithmes de planification peuvent également transmettre l’importance et le niveau de service souhaité de chaque file d’attente à travers l’utilisation de crédits et de débits. Par ex., un procédé de planification équitable proportionnelle (PFS) peut utiliser des crédits et des débits pour ajuster le service parmi les files d’attente. Les algorithmes de planification peuvent utiliser des pondérations et convertir les poids en crédit sous forme de nombre de paquets ou d’octets qui doivent être donnés au cours d’un cycle de planification.

Les nœuds dans les réseaux de communication peuvent améliorer la QoE en utilisant un facteur d’application (AF) pour modifier de façon dynamique les poids ou les crédits utilisés pour allouer des ressources dans un planificateur. L’AF peut être apparenté au niveau actuel de la session QoE. Un AF plus grand peut être appliqué pour des sessions avec des QoE faibles, augmentant ainsi l’attribution de ressources. Par contre, un AF peut être appliqué pour les sessions avec des QoE élevés réduisant ainsi les ressources attribuées à la session et libérant des ressources qui peuvent être utilisées par d’autres sessions. Les dispositifs dans le réseau de communication peuvent utiliser des procédés de planification décrits dans la demande de brevet américain no. 13/607 559, déposée le 7 septembre 2012 et intitulée « Systems and Methods for Congestion Détection for use in Prioritizing and

Scheduling Packets in a Communication Network », qui est incorporée ici à titre de référence.

Les postes d’abonnés 150 et les nœuds de communication dans le réseau de la FIG. 1 (tels que le poste de base macro 110, et le poste pico 130, la passerelle entreprise 103, la femtocell pour entreprise 140, des dispositifs dans le réseau central 102 et des dispositifs dans le réseau du fournisseur de services Internet 101) peuvent communiquer des informations reliées à l’application. La coopération entre les applications au niveau des postes d’abonnés et des agents d’application dans les nœuds de communication peut améliorer le réseau de communication, y compris l’expérience de l’utilisateur. Les informations apparentées à l’application peuvent être obtenues à travers l’inspection de paquet traversant les nœuds de communication. Pour plusieurs applications il pourrait y avoir des informations supplémentaires, telles que le taux d’occupation de la mémoire tampon du côté client, contenues dans une application au niveau d’un poste d’abonné qui pourraient permettre des communications plus efficaces et améliorées. De la même façon, il peut y avoir des informations, telles que des informations sur l’état de la congestion, disponibles dans un nœud de communication qui pourraient aider une application à faire des requêtes de ressources plus intelligentes qui entraîneraient, à leur tour, une amélioration de la performance du nœud de communication, par ex., au niveau des fonctions de la commande du planificateur et de l’admission. Par ex., le système de communication peut utiliser des informations d’application et des informations sur la congestion pour améliorer l’attribution de ressource du canal de communication et pour déterminer les sessions à admettre, rejeter ou modifier.

La communication apparentée à l’application ou la coopération entre des applications côté client et les fonctions de programmation et de contrôle de d’admission du nœud de communication peut améliorer la QoE pour les utilisateurs. La communication et la coopération apparentées à l’application peuvent améliorer la QoE même lorsque des garanties de ressources QoS sont disponibles. Par ex., les garanties de ressources pourraient ne pas comprendre des états instantanés tels que la congestion, les vitesses de bits pic versus les vitesses moyennes et l’hétérogénéité des données entre les applications.

La FIG. 2 est un schéma fonctionnel d’un nœud d’accès 275 conformément aux aspects de l’invention. Dans divers modes de réalisation, le nœud d’accès 275 peut être un poste de base WiMAX mobile, un système global pour une station de base émettrice/réceptrice (BTS) de GSM sans fil, un nœud B du système de télécommunications mobiles universelles (UMTS), un nœud B évolué LTE (eNB ou eNodeB), les têtes de câble modem, ou d’autres nœuds d’accès sur fil ou sans fil de diverses facteurs de forme. Par ex., le poste de base macro 110, le poste pico 130, ou la femtocell 140 de l’entreprise de la FIG. 1 peut être fournie, par ex., par le nœud d’accès 275 de la FIG. 2. Le nœud d’accès 275 comprend un module processeur 281. Le module processeur 281 est couplé à un module émetteur/récepteur (transceiver) 279, un module d’interface terrestre 285 et un module de stockage 283.

Le module émetteur/récepteur 279 est configuré pour transmettre et recevoir des communications vers et à partir des autres dispositifs. Dans plusieurs modes de réalisation, les communications sont transmises et reçues sans fil. Dans de tels modes de réalisation, le nœud d’accès 275 comprend généralement une ou plusieurs antennes pour la transmission et la réception des signaux radio. Dans d’autres modes de réalisation, les communications sont transmises et reçues sur des connexions physiques telles que des fils ou des câbles optiques. Les communications du module émetteur/récepteur 279 peuvent se faire avec des nœuds terminaux.

Le module d’interface terrestre 285 permet une communication entre le nœud d’accès 275 et un réseau central. La communication peut se faire à travers une connexion terrestre, par ex., la connexion terrestre 170 de la FIG. 1. Les communications reçues à travers le module émetteur/récepteur 279 peuvent être transmises, après traitement, sur la connexion terrestre. De la même façon, la communication reçue de la connexion terrestre peut être transmise par le module émetteur/récepteur 279. Même si le nœud d’accès 275 de la FIG. 2 est illustré avec un seul module d’interface terrestre 285, d’autres modes de réalisation d’un nœud d’accès 275 peuvent comprendre de multiple module d’interface terrestre. De la même façon, le nœud d’accès 275 peut comprendre de multiples modules émetteur/récepteur. Les multiples modules d’interface terrestres et les modules émetteur/récepteur peuvent fonctionner selon différents protocoles.

Le module processeur 281 peut traiter des communications qui sont reçues et transmises par le nœud d’accès 275. Le module de stockage 283 stocke des données devant être utilisées par le module processeur 281. Le module de stockage 283 peut également être utilisé pour stocker des instructions lisibles par ordinateur pour l’exécution par le module processeur 281. Les instructions lisibles par ordinateur peuvent être utilisées par le nœud d’accès 275 pour réaliser diverses fonctions du nœud d’accès 275. Dans un mode de réalisation, le module de stockage 283 ou des parties du module de stockage 283 peuvent être considérées comme un support lisible par une machine non transitoire. Pour une explication concise, le nœud d’accès 275 ou les modes de réalisation de celui-ci sont décrits comme ayant certaines fonctionnalités. Il sera compris que dans certains modes de réalisation, cette fonctionnalité est accomplie par le module processeur 281 en association avec le module de stockage 283, le module émetteur/récepteur 279 et le modules d’interface terrestre 285. En outre, en sus d’exécuter les instructions, le module processeur 281 peut comprendre du matériel spécialisé pour réaliser certaines fonctions.

Le nœud d’accès 275 peut communiquer des informations apparentées à l’application à d’autres dispositifs. Le nœud d’accès 275 peut recevoir des informations apparentées à l’application provenant d’autres dispositifs, transmettre des informations apparentées à l’application à d’autres dispositifs, ou les deux. Par ex., une application dans un nœud terminal peut fonctionner en coopération avec un nœud accès 275 pour améliorer la QoE pour l’utilisateur du nœud terminal.

La FIG. 3 est un schéma fonctionnel d’un nœud terminal 255 conformément aux aspects de l’invention. Dans divers modes de réalisation, le nœud terminal 255 peut être un poste d’abonné WiMAX mobile, un téléphone cellulaire GSM, un téléphone cellulaire UMTS et un équipement utilisateur LTE, un modem câble, ou d’autres nœuds terminaux sur fil ou sans fil de divers facteurs de forme. Les postes d’abonnés 150 de la FIG. 1 peuvent être fournis, par ex., par le nœud terminal 255 de la FIG. 3. Le nœud terminal 255 comprend un module processeur 261. Le module processeur 261 est couplé à un module émetteur/récepteur (transceiver) 259, un module d’interface utilisateur 265 et un module de stockage 263.

Le module émetteur/récepteur 259 est configuré pour transmettre et recevoir des communications vers et à partir d’autres dispositifs. Par ex., le module émetteur/récepteur 259 peut communiquer avec le nœud d’accès 275 de la FIG. 2 à travers le module émetteur/récepteur 279. Dans des modes de réalisation dans lesquels les communications sont sans fil, le nœud terminal 255 comprend généralement une ou plusieurs antennes pour la transmission et la réception des signaux radio. Dans d’autres modes de réalisation, les communications sont transmises et reçues sur des connexions physiques telles que des fils ou des câbles optiques. Même si le nœud terminal 255 de la FIG. 3 est illustré avec un module émetteur/récepteur 259 unique, d’autres modes de réalisation du nœud terminal 255 peuvent comprendre de multiples modules émetteur/récepteur. Les multiples modules émetteur/récepteur peuvent fonctionner selon différents protocoles.

Le nœud terminal 255, dans plusieurs modes de réalisation, transmet des données vers une personne (utilisateur) et reçoit des données à partir de celle-ci. Ainsi, le nœud terminal 255 comprend le module d’interface utilisateur 265. Le module d’interface utilisateur 265 comprend des modules pour la communication avec une personne. Le module d’interface utilisateur 265, dans un mode de réalisation, comprend un micro et un haut-parleur pour des communications vocales avec l’utilisateur, un écran pour afficher des informations visuelles à l’utilisateur et un clavier pour accepter des commandes alphanumériques et des données provenant de l’utilisateur. Dans certains modes de réalisation, un écran tactile peut être utilisé à la place d’un clavier ou en association avec celui-ci pour permettre des saisies graphiques en sus des saisies alphanumériques. Dans un mode de réalisation alternatif, le module d’interface utilisateur 265 comprend une interface informatique, par ex., une interface USB, pour interfacer le nœud terminal 255 à un ordinateur. Par ex., le nœud terminal 255 peut être sous la forme d’une clé électronique qui peut être reliée à un ordinateur portable à travers le module d’interface utilisateur 265. La combinaison d’ordinateur et de clé électronique peut également être considérée comme un nœud terminal. Le module d’interface utilisateur 265 peut avoir d’autres configurations et comprend des fonctions telles que des vibrateurs, des caméras et des lumières.

Le module processeur 261 peut traiter des communications qui sont reçues et transmises par le nœud terminal 255. Le module processeur 261 peut également traiter des entrées de et des sorties vers le module d’interface 265. Le module de stockage 263 stocke également des données devant être utilisées par le module processeur 261. Les instructions 263 lisibles par ordinateur peuvent être utilisées par le nœud terminal 255 pour réaliser les diverses fonctions du nœud terminal 255. Dans un mode de réalisation, le module de stockage 263 ou des parties du module de stockage 263 peuvent être considérées comme un support lisible par une machine non transitoire. Pour une explication concise, le nœud terminal 255 ou les modes de réalisation de celui-ci sont décrits comme ayant certaines fonctionnalités. Il sera compris que dans certains modes de réalisation, cette fonctionnalité est accomplie par le module processeur 261 en association avec le module de stockage 263, le module émetteur/récepteur 259 et le module d’interface utilisateur 265. En outre, en sus d’exécuter les instructions, le module processeur 261 peut comprendre du matériel spécialisé pour réaliser certaines fonctions.

Le nœud terminal 255 peut communiquer des informations apparentées à l’application à d’autres dispositifs. Le nœud terminal 255 peut recevoir des informations apparentées à l’application provenant d’autres dispositifs, transmettre des informations apparentées à l’application à d’autres dispositifs, ou les deux. Par ex., un agent d’application dans un nœud terminal peut fonctionner en coopération avec un nœud accès 255 pour améliorer la QoE pour l’utilisateur du nœud terminal.

La FIG. 4 est une figure illustrant les aspects d’un nœud d’accès 475 conformément aux aspects de l’invention. Le nœud d’accès 475 communique avec un nœud terminal 455 et un réseau central 410. Le poste de base macro 110, le poste pico 130, la femtocell 140 de l’entreprise ou la passerelle 103 de l’entreprise de la FIG. 1, dans certains modes de réalisation, sont mis en place par utilisation d’un nœud d’accès 475. Le nœud d’accès 475 peut être mis en place, par ex., en utilisant le nœud d’accès 275 de la FIG. 2. Le réseau central 410 peut également être un réseau de fournisseur de service, d’Internet ou une combinaison de réseau. Pour aider à la compréhension, dans la FIG. 4, les lignes solides représentent les données d’utilisateurs et les lignes pointillées représentent les données de contrôle. La distinction entre les données utilisateur et les données de contrôle se fait du point de vue du nœud d’accès 475. Étant donné que le nœud d’accès 475 agit comme un pont, il peut y avoir des données de contrôle provenant du nœud terminal 455 vers quelques entités, telles qu’un serveur vidéo, dans le réseau central 410 qui sont perçues par le nœud d’accès 475 comme des données utilisateur.

Le nœud d’accès 475 de la FIG. 4 facilite la communication entre le nœud terminal 455 et les entités dans un réseau central 410 et au-delà (par ex., des entités auxquelles on peut accéder par Internet tels que des serveurs vidéo). Une application 451 dans le nœud terminal 455 communique avec une application serveur dans, ou connecté au, réseau central 410 via un nœud d’accès 475. L’application 451 procure certaines fonctionnalités ou services pour un utilisateur du nœud terminal 455. Par ex., l’application 451 peut être un programme logiciel exécuté par le nœud terminal 455. L’application 451 dans le nœud terminal 455 communique également avec un agent d’application 470 dans le nœud d’accès 475. L’application 451 peut être un module fourni, par ex., par un module processeur 261 du nœud terminal 255 de la FIG. 3 en utilisant des instructions provenant du module de stockage 263. L’agent d’application 470 peut être un module fourni, par ex., par un module processeur 281 du nœud d’accès 275 de la FIG. 2 utilisant les instructions provenant du module de stockage 283. L’application 451 et l’agent d’application 470 communiquent via une voie de contrôle de la communication 403 en coopération avec un agent APP. Les communications entre l’application 451 et l’agent d’application 470 peuvent procurer une performance améliorée du système de communication, par ex., une QoE améliorée pour l’utilisateur du nœud terminal 455. Les applications qui procurent des communications sur la voie de contrôle de la communication 403 en coopération avec un agent APP peuvent être considérées comme des applications améliorées ou coopératives. Même si la FIG. 4 illustre des cas uniques de chaque élément, dans un mode de réalisation, il peut y avoir de multiple cas de divers éléments. Par ex., le nœud d’accès peut communiquer simultanément avec de multiples nœuds terminaux, et chacun des nœuds terminaux peuvent avoir de multiples applications qui peuvent coopérer simultanément avec un ou plusieurs agents d’application dans un ou plusieurs nœuds d’accès.

Le nœud d’accès 475 comprend un module d’inspection de paquet 429, un module de programmation 430 et un module émetteur/récepteur (transceiver) 479. Le module d’inspection de paquet 429, le module de programmation 430 est le module émetteur/récepteur 479 sont utilisés par le nœud d’accès 475 lors de la communication avec le nœud terminal 455. Le module émetteur/récepteur 479 permet des communications avec le nœud terminal 455. Le module émetteur/récepteur 479 peut, par ex., mettre en place une couche physique d’un réseau d’accès radio. Le nœud d’accès 475 comprend également un module de contrôle de ressources 480 qui est responsable de divers aspects du contrôle de ressource. L’agent d’application 470 peut également communiquer avec le module de contrôle de ressource 480.

Le module d’inspection de paquet 429 est dans une voie de données entre le réseau central 410 et le nœud terminal 455. Dans la direction descendante, le module d’inspection de paquet 429 reçoit des données provenant du réseau central 410 et décide quoi faire avec les données. Par ex., les données utilisateur destinées au nœud terminal 455 peuvent être séparées dans des files d’attente au niveau du module de programmation 430 pour la transmission vers le nœud terminal 455 via le module émetteur/récepteur 479. La séparation en file d’attente peut être basée sur diverses caractéristiques associées aux donnés utilisateurs, telles qu’une liaison logique, une source IP et des adresses de destination, ou des classes d’application. Dans un mode de réalisation, le module d’inspection de paquet 429 fait partie d’un pont de données/module de relais, ou est couplé à celui-ci. Le module d’inspection de paquet 429 peut comprendre une fonction de routage réalisé avant ou après le pont de données/module de relais.

Certaines données provenant du réseau central peuvent être des données de contrôle destinées au contrôle et à la configuration du nœud d’accès 475. Ces données peuvent être dirigées vers divers modules de contrôle ou de gestion d’une d’accès 475, par ex., le module de contrôle de ressource 480.

Le module de programmation 430 met en place certaines ou toutes les fonctionnalités nécessaires pour attribuer des ressources physiques au travers de la liaison de communication entre le nœud d’accès 475 et le nœud terminal 455. Le module de programmation 430 est généralement associé à une couche de contrôle d’accès au support (MAC), ou fait partie de celle-ci. Pour la direction descendante, le module de programmation 430 décide des données à transmettre et à quel moment. Les ressources peuvent être attribuées, par ex., sous forme de sous-porteuses ou créneaux horaires. Le module de programmation 430 peut également traiter des demandes de ressources ascendantes provenant du nœud terminal 455 et attribué des largeurs de bande ascendantes. Le module de programmation 430 peut utiliser des informations PHY provenant du module émetteur/récepteur 479, telles que le schéma de modulation et de codage, afin de déterminer la quantité de ressources qui doit être attribuée à des donnés utilisateurs spécifiques. Le module de programmation 430 peut également informer le module de contrôle de ressources 480 d’une congestion se produisant sur la liaison de communication ou des statistiques concernant la surveillance de la congestion (par ex., le taux d’occupation de la mémoire et les vitesses de sortie). Dans un mode de réalisation, le module de programmation 430 peut recevoir des mises à jour pour les paramètres de programmation, tels que des changements au niveau des poids et des crédits, provenant du module de contrôle de ressource 480.

Le module d’inspection de paquet 429 peut également détecter des applications et procurer des informations sur l’application, telles que la classe d’application, l’application spécifique, les débits de données et les durées, au module de contrôle de ressource 480. Dans un mode de réalisation, le module d’inspection de paquet 429 peut recevoir des informations de réponse du contrôle d’admission et aider à la mise en place de la réponse du contrôle d’admission, tels que le blocage des paquets pour une connexion ou une session donnée.

Le module de contrôle de ressource 480 illustré dans la FIG. 4 comprend un module d’estimation de la ressource 481, un module de surveillance de la congestion 482, un module de réponse au contrôle d’admission 483 et un module de calcul du paramètre de programmation 484. Le module d’estimation de ressource 481 estime les besoins en ressources attendus des applications actuellement actives. Le module d’estimation de ressource 481 peut utiliser des paramètres de l’application, tels que le débit de données attendu et les paramètres PHY, tels que les changements dans la modulation et le codage pour le nœud terminal 455, afin d’estimer les besoins en ressources attendus. Tout excès en ressource peut être disponible à de nouvelles applications ou être disponible pour augmenter les ressources attribuées à une application actuellement active.

Le module de surveillance de la congestion 482 surveille l’état actuel de la congestion. L’état actuel de la congestion peut varier par rapport à l’estimation de ressource effectuée par le module d’estimation de ressource 481. Par ex., lorsqu’un changement à court terme dans le débit de données se produit (par ex., un pic dans le débit de données pour une vidéo en streaming à débit de données variables), les informations provenant du module de programmation 430 peuvent indiquer une congestion actuelle (par ex., une augmentation du taux d’occupation de la mémoire pour une application ou une diminution de la vitesse de sortie pour une application) même si l’estimation de ressources à long terme n’indique aucune congestion. Le module de surveillance de la congestion 482 peut également conserver des informations historiques sur la congestion qui pourraient être utilisées pour prédire la congestion.

Le module de réponse au contrôle d’admission 483 peut créer des réponses de contrôle pour admettre, rejeter, retarder ou modifier les liaisons logiques, les connexions et/ou les flux créant ainsi des réponses au contrôle pour les sessions. Le module de réponse au contrôle d’admission 483 peut créer des réponses de contrôle en utilisant divers informations, par ex., des politiques (par ex., la priorité des utilisateurs ou un niveau acceptable de la QoE pour l’utilisateur), des informations sur le contrat du niveau de service (SLA), des paramètres d’application (par ex., application spécifique ou débit de données), les estimations de ressources, les communications en coopération avec un agent APP et les indicateurs de la congestion.

Le module de calcul du paramètre de programmation 484 peut calculer des modifications au niveau des paramètres de programmation, tels que les poids et les crédits. Le module de calcul du paramètre de programmation 484 peut calculer les modifications en utilisant diverses informations, par ex., des communications en coopération avec un agent APP, des politiques, des informations SLA, des paramètres d’application, des estimations de ressources, des indicateurs de congestion et des réponses au contrôle (par ex., réponses au contrôle d’admission).

Le module émetteur/récepteur 479, en sus de faciliter le transfert de données ascendants et descendants, peut surveiller ou conserver des paramètres et l’état de couche physique (PHY), tel que la modulation, le codage et le rapport signal/bruit (SNR) associé à la communication avec le nœud terminal 455. Les capacités d’une d’accès 475 à communiquer avec les nœuds terminaux dépendent en partie des paramètres et de l’état du PHY. Les informations concernant les paramètres et l’état du PHY peuvent être mis à la disposition du module de programmation 430 pour la prise de décisions de programmation et au module de contrôle de ressource 480 pour calculer les ajustements du paramètre de programmation ou pour déterminer les réponses au contrôle d’admission. Le module émetteur/récepteur 479 peut également faciliter ou générer une communication entre des modules de protocole d’accès radio au niveau d’une d’accès 475 et du nœud terminal 455. Dans la direction ascendante, le module d’inspection de paquet 429 reçoit des donnés utilisateur provenant du nœud terminal 455 via le module émetteur/récepteur 479 et transfert les données utilisateur vers le réseau central 410. Le module d’inspection de paquet 429 reçoit également des communications provenant du nœud terminal 455 destinées à l’agent d’application 470. Le module d’inspection de paquet 429 peut identifier ses communications et les transférer à l’agent d’application 470. L’agent d’application 470 et l’application 451 établissent la voie de contrôle de communication en coopération avec l’agent APP 403. La voie de contrôle de communication en coopération avec l’agent APP 403 peut être, par ex., une connexion TCP. La voie de contrôle de communication en coopération avec l’agent APP 403 est utilisée pour échanger des communications en coopération avec l’agent APP. L’acheminement des données sur la voie de contrôle de communication en coopération avec l’agent APP 403 peut être facilité par le module d’inspection de paquet 429. Par ailleurs, l’acheminement peut être facilité par une fonction d’acheminement qui peut être interne ou externe au nœud d’accès 475.

Les communications en coopération avec l’agent APP provenant de l’application 451 vers l’agent d’application 470 peuvent comprendre, par ex., des informations qui permettent au nœud d’accès 475 d’améliorer le contrôle de l’admission et de la programmation Les communications entre l’agent d’application 470 et l’application 451 peuvent, par ex., procurer des informations supplémentaires au module de contrôle de ressource 480.

Comme exemple de présentation de communication en coopération avec un agent APP, imaginons un réseau de communication dans lequel l’application 451 permet le flux vidéo

YouTube vers l’utilisateur du nœud terminal 455. Le flux vidéo peut être disponible en plusieurs formats avec différents débits de données associés. Les informations concernant les formats peuvent être communiquées par une application spécifique à YouTube vers un agent d’application compatible à YouTube qui peut, à son tour, procurer des informations concernant les formats au module de contrôle de ressource. Le module de contrôle de ressource peut utiliser les informations d’application pour générer une réponse de contrôle d’admission qui précise les formats, s’il y en a, qui correspondent aux estimations actuelles des ressources disponibles. L’agent d’application compatible à YouTube peut traiter la réponse de contrôle d’admission dans les communications en coopération avec un agent APP vers une application spécifique à YouTube en précisant les formats qui sont actuellement permis. Dans divers modes de réalisation, le choix spécifique du format peut être réalisé par l’agent d’application ou par l’application et renvoyé vers l’agent d’application. L’agent d’application peut informer le module de contrôle de ressource du format choisi et du débit de données associé. Le module de contrôle de ressource met à jour les estimations de ressource et les paramètres de programmation afin de refléter le format choisi.

La FIG. 4 illustre une attribution de fonctions donnée vers divers modules et une distribution de modules donnée dans divers nœuds de communication. Plusieurs autres agencements peuvent également être utilisés. Par ex., l’intégralité ou des parties du module d’inspection de paquet 429, de l’agent d’application 470 et du module de contrôle de ressource 480 peuvent être dans un nœud de passerelle dans le réseau central, par ex., dans une passerelle de service (S-GW) ou une passerelle de paquet (P-GW) dans un réseau LTE. En outre, il peut y avoir des dispositifs intermédiaires entre le nœud d’accès 475 et le réseau central 410 et le nœud terminal 455. Plusieurs combinaisons d’application et d’agents d’application et de leurs fonctions apparentées peuvent également être utilisées. Par ex., il peut y avoir un agent d’applications qui communiquent avec toutes les applications, un agent d’application pour chaque application donnée (par ex., un agent d’application de YouTube, un agent d’application de Pandora, etc.), un agent d’application pour chaque nœud terminal ou un agent d’application pour chacun application (par ex., un agent d’application de YouTube pour un premier nœud terminal et un autre agent d’application de YouTube pour un deuxième nœud terminal). Lorsqu’il existe de multiples applications et agents d’application, il peut y avoir des connexions de communication individuelle (par ex., des connexions TCP/IP) entre chaque paire d’application et d’agent d’application. Par ailleurs, la communication entre les multiples applications et agents d’application peut être regroupée et transportée à travers un nombre réduit de connexions. Par ex., une connexion TCP/IP unique peut être utilisée pour communiquer entre de multiples agents d’application et des applications pour un nœud terminal donné. L’agent d’application 470 peut assurer la gestion du cycle de vie de la connexion et la mise en mémoire du segment et la réorganisation des connexions TCP/IP et d’autres connexions à l’aide de protocoles basés sur le flux de bit ou orientés sur la connexion, par ex., en utilisant un cas de la pile TCP. Par ailleurs, la communication en coopération avec l’agent APP peut utiliser une connexion de communication simplifiée, par ex., l’UDP/IP.

La FIG. 5 est un schéma d’un système de communication qui illustre les relations du plan de commande conformément aux aspects de l’invention. Le système de communication comprend un nœud terminal 555, un nœud d’accès 575 et un serveur d’application 590. Le nœud terminal 555 comprend une application 551 qui communique avec un serveur d’application 592 dans le serveur d’application 590. La communication se fait à travers le nœud d’accès 575. L’application 551 communique également avec un nœud d’application 570 dans le nœud d’accès 575.

Les exemples de protocoles, les relations du plan de contrôle et d’autres descriptions de la FIG. 5 peuvent être utilisés pour mieux comprendre les aspects apparentés au nœud d’accès 475 de la FIG. 4. Le nœud d’accès 475 de la FIG. 4 peut être semblable à ou le même que le nœud d’accès 575 de la FIG. 5. Le nœud terminal 455 de la FIG. 4 peut être semblable à ou le même que le nœud terminal 555 de la FIG. 5. De la même façon, les communications entre le nœud d’accès 575 et le serveur d’application 590 peuvent utiliser un réseau semblable à ou le même que le réseau central 410 de la FIG. 4. En outre, le serveur d’application 590 de la FIG. 5 peut être dans ou connecté à un réseau semblable à ou le même que le réseau du fournisseur de services Internet 101 ou du réseau central 102 du réseau de communication de la FIG. 1. Le serveur d’application peut également être un réseau de serveurs localisé séparément. Alors que le système de communication de la FIG. 4 utilise des piles de protocole LTE, d’autres systèmes de communication peuvent utiliser d’autres piles de protocole. Il peut y avoir plus ou moins de couches de protocoles, les noms et la terminologie de la couche peuvent être différents, la fonctionnalité pourrait être différente et l’emplacement dans lequel une couche réside peut être différent.

Les dispositifs dans un réseau de communication communiquent généralement sur des voies de communication à travers des protocoles multicouches. Des piles de protocole dans les dispositifs de communication mettent en œuvre ces protocoles. Par ex., une voie de données d’application 501 transmet des communications entre le nœud terminal 555 et les serveurs d’applications 590 via le nœud d’accès 575 à l’aide de piles de protocole dans chaque dispositif. En sus des piles de protocole pour transférer des données et le contrôle d’application utilisateur, il peut y avoir des piles de protocole pour mettre en œuvre et gérer les liaisons de communication pour supporter l’application utilisateur.

Le nœud d’accès 575 de la FIG. 5 comprend une pile de protocole de plan de contrôle du réseau d’accès radio (RAN) pour mettre en œuvre le protocole de plan de contrôle RAN pour les communications de plan de contrôle dans le nœud d’accès 555 et le nœud d’accès 575. Le protocole de plan de contrôle RAN dans le nœud d’accès 575 peut être mis en œuvre en utilisant, par ex., le module processeur 281 du nœud d’accès 275 de la FIG. 2 en utilisant des instructions provenant du module de stockage 283. Le pile de protocole du plan de contrôle RAN dans le nœud d’accès 575 comprend un module de couches physiques (PHY) RAN 525, une couche de contrôle d’accès au support (MAC) 520, une couche de module de contrôle de la liaison radio (RLC) 515, une couche de module de convergence de données en paquet (PDCP) 510 est une couche de module de contrôle de la ressource radio (RRC) 505. Chacune de ces couches de piles de protocoles dans le nœud d’accès 575 possèdent une couche paire dans le nœud terminal 555. Ainsi, la pile de protocole de plan de contrôle RAN dans le nœud terminal 555 comprend un module de couche PHY 525', un module de couches MAC 520', un module de couches RLC 515', un module de couches PDCP 510' et un module de couches RRC 505'.

Dans le plan de contrôle, des informations de contrôle du RAN sont généralement échangées entre les couches supérieures et inférieures dans le même nœud, créant logiquement des liaisons de contrôle paire-à-paire entre une couche sur le nœud d’accès 575 et la couche correspondante sur le nœud terminal 555. Une voie de contrôle RAN 502 relie les couches paires du nœud d’accès 575 et du nœud terminal 555. Même si la FIG. 5 illustre un nœud terminal unique 555, une couche de plan de contrôle RAN sur le nœud d’accès 575 peut comporter des liaisons de contrôle logiques par rapport à de multiples paires sur de multiples nœuds terminaux.

Les modules de couche de plan de contrôle paire RAN échangent des informations de contrôle nécessaire pour contrôler et faire fonctionner la liaison de communication entre les deux dispositifs. Les informations de contrôle ont pour origine et se termine à l’intérieur du nœud d’accès 575 et d’un nœud terminal 555 et sont spécifiques pour le fonctionnement et la gestion de la liaison de communication. Par contre, les données d’application utilisateur et de la messagerie de contrôle de l’application ont pour origine et se terminent au niveau du nœud terminal 555 et du serveur d’applications 590. Du point de vue du nœud d’accès 575, les données d’application utilisateur et de la messagerie de contrôle de l’application peuvent être considérées comme étant transportées sur le plan de données plutôt que sur le plan de contrôle.

Le module de couche physique RAN 525 du nœud d’accès 575 possède une relation paire de message de contrôle avec le module de la couche physique RAN 525' du nœud terminal 555. Le module de la couche physique RAN 525 d’une d’accès 575 peut, par ex., demander des changements de puissance de transmission du module de la couche physique RAN 525' du nœud terminal 555. Le module de la couche physique RAN 525' d’un nœud terminal 555 peut envoyer des paramètres de qualité de liaison radio, tels que les mesures du rapport signal/bruit (SNR), vers le module de la couche physique RAN 525 sur le nœud d’accès 575. Le module de la couche MAC 520 du nœud d’accès 575 possède une relation paire de message de contrôle avec le module de la couche MAC 520' d’un nœud terminal 555. Les modules de la couche MAC peuvent, par ex., échanger des demandes et attributions de ressource. Le module de la couche RLC 515 du nœud d’accès 575 possède une relation paire de message de contrôle avec le module de la couche RLC 515' du nœud terminal 555. Le module de la couche RLC peut, par ex., échanger des données de segmentation et des informations de réassemblage. Le module de la couche PDCP 510 du nœud d’accès 575 possède une relation paire de message de contrôle avec le module de la couche PDCP 510' du nœud terminal 555. Les modules de la couche PDCP peuvent, par ex., échanger des informations de cryptage et de compression. Le module de la couche RRC 505 du nœud d’accès 575 possède une relation paire de message de contrôle avec le module de la couche RRC 505' du nœud d’accès 575. Les modules de la couche RRC peuvent, par ex., échanger des paramètres de qualité de service (QoS) des liaisons logiques. L’échange d’informations entre les couches paires à l’aide de la voie de contrôle 502 peut être basé sur l’utilisation d’un ou de plusieurs canaux logiques, physiques et de transport. Dans un LTE, par ex., des informations de système à grandeur de cellules sont définies au niveau du module de la couche RRC 505 dans le nœud d’accès 575 et sont communiquées au nœud terminal 555 via des ensembles de données formées sous forme de blocs d’informations principaux (MIB) et de l’un ou de plusieurs blocs d’information de système (SIB). Les MIB et les SIB sont transférés vers le bas de la pile à travers un canal de commande de diffusion (BCCH), un canal de diffusion de transport (BCH) et finalement le canal de diffusion physique (PBCH) et le canal physique partagé en liaison descendante (PDSCH). Des informations de commande de canal qui doivent être envoyées vers un nœud terminal spécifique sont communiquées via une connexion de support de radio de signalisation (SRB) et transférées par la pile utilisant le canal physique de commande descendante (DCCH), le canal de transport partagé en liaison descendante (DL-SCH) et le canal physique partagé en liaison descendante (PDSCH).

Pour la communication entre l’application 551 et le serveur d’application 592, un module de protocoles de transport et de connexion 550' sur le nœud terminal 555 et un module de protocole de transport par paire et de connexion 550 sur le serveur d’applications 590 sont utilisées pour établir le trajet de données de l’application 501. Le trajet de données de l’application 501 transporte des données de contrôle de l’application et des données d’utilisateurs de l’application. Dans divers modes de réalisation, le trajet de données de l’application 501 peut utiliser le même ou des différents protocoles de transport et de connexion pour les données de contrôle de l’application et les données d’utilisateurs de l’application. En outre, les mêmes ou différents cas (par ex., procédés logiciels) des piles de protocoles peuvent être utilisées pour les données de contrôle de l’application et les données d’utilisateur de l’application.

Le trajet de données de l’application 501 peut être considéré comme la communication des donnés utilisateurs par la pile de protocole RAN. Contrairement aux données sur le trajet de contrôle RAN 502, les données provenant du nœud terminal 555 sur le trajet de données de l’application 501 ne se terminent pas au niveau du nœud d’accès 575. Plutôt, les données sur le trajet de données de l’application 501 sont pontées par un module relai/pont de donnés 530 vers une liaison de communication pour un transport éventuel vers le serveur d’applications 590. Lorsque l’application ne fournit pas les communications en coopération avec un agent APP, tout le trafic d’application peut être ponté vers le nœud suivant. Pour une telle application, le contrôle d’application peut être limité à une communication entre l’application et une application serveur associée.

Le transport vers le serveur d’application 590 peut comprendre de multiples liaisons provenant d’un nœud d’accès 575, par ex., à travers un nœud de passerelle ou un nœud de routeur. Le nœud d’accès 575 peut utiliser un autre module de protocoles de transport et de connexion 563 pour communiquer avec un premier nœud de communication amont à travers un autre module de couche physique 565. Le module de protocoles de transport et de connexion 563 peut, par ex., utiliser le protocole de tunnelage basé sur le service général de radiocommunication en mode paquet (GPRS) (eGTP). Le module de couche physique 565 peut, par ex., transmettre de données sur une liaison terrestre micro-ondes ou une liaison de porteur Ethernet. Au niveau du serveur d’application 590, les données sont reçues à travers un module de couche physique 597 et envoyées vers le module de protocoles de connexion et de transport 550. Ainsi, le module de protocoles de connexion et de transport 550 au niveau du serveur d’application 590 peut procurer des protocoles qui sont des paires aux protocoles utilisés dans le module de protocoles de connexion et de transport 563 au niveau du nœud d’accès 575 et procurer des protocoles pour la communication avec d’autres nœuds de communication entre le serveur d’application 590 et le nœud d’accès 575 en sus des protocoles pour la communication avec le nœud terminal 555.

Les données sur le trajet de données de l’application 501, les données sur le trajet de contrôle RAN 502, et des données sur un trajet de contrôle de communication en coopération avec un agent APP 503 sont transportées entre le nœud terminal 555 et le nœud d’accès 575 via les piles de protocole RAN. Cependant, le module d’inspection de paquet 529 au niveau d’un nœud d’accès 575 peut détourner les communications en coopération avec un agent APP vers un agent d’application 570. La création et la communication des messages sur un trajet de contrôle de communication en coopération avec un agent APP 503 peut utiliser des protocoles supplémentaires sur le nœud d’accès 575 qui sont appariés aux protocoles utilisés dans le module de protocoles de transport et de connexion 550' dans le nœud terminal 555. Les protocoles supplémentaires peuvent être fournis, par ex., par le module d’inspection de paquet 529 lâchant application 570.

Les réseaux utilisent des couches de protocoles pour soustraire les fonctions d’une couche des fonctions fournies par une autre couche. La soustraction des couches peut permettre une plus grande portabilité des applications vers différents réseaux. L’initiation et la terminaison ultérieure des flux de paquet dans un réseau peuvent être déclenchées par des applications ou des services particuliers. Un flux de contrôle et des paquets de données utilisateurs apparentés à l’utilisation d’une application d’utilisateur final ou d’un service est appelé une session. Des exemples de cession comprennent un appel « voix sur protocole Internet (VoIP) » avec l’application Skype à partir d’un ordinateur portable, la lecture de vidéos en continu sur l’application YouTube avec un cellulaire androïde, et un appel vidéo bidirectionnel avec l’application iChat d’Apple.

Les nœuds de réseau, tels que des serveurs d’applications ou des serveurs proxy, et les nœuds terminaux, tels que les téléphones intelligents, les tablettes ou les ordinateurs portables, peuvent initier ou participer à une session. Les nœuds peuvent héberger une ou plusieurs sessions simultanément. Les sessions peuvent être indépendantes l’une de l’autre (par ex., un utilisateur utilisant Facebook et l’e-mail simultanément) ou apparentées l’une à l’autre (par ex., une session de navigation qui engendre deux sessions de lecture vidéo). Une session peut être établie entre deux nœuds. Par ailleurs, une session peut être visualisée comme une relation entre un nœud et plusieurs nœuds à travers l’utilisation, par ex., des protocoles de paquet multicast et de diffusion.

Les sessions peuvent être caractérisées ou catégorisées par divers critères. Une application spécifique se rapporte à une application particulière qui a été initiée par l’utilisateur et qui est responsable du déclenchement d’une session. Des exemples d’applications spécifiques comprennent l’application YouTube, le navigateur Internet Chrome et de logiciels d’appel vocal Skype. Plus généralement, une classe d’application peut être utilisée pour décrire une fonction globale assurée par une session donnée. Des exemples de classes d’application comprennent la lecture vidéo en continu, les appels vocaux, la navigation Internet, l’e-mail et les jeux en ligne.

Une session peut être composée d’un ou de plusieurs flux de données indépendants utilisant les mêmes ou des connexions sous-jacentes potentiellement différentes. Par ex., une seule session appelle téléphonique VoIP peut contenir deux flux de données. Un flux de données peut assurer le trafic de voix bidirectionnel (c.-à-d., paquet de contenu ou de données plan) avec une connexion de protocole de datagramme utilisateur (UDP). Un deuxième flux de données peut utiliser une ou plusieurs connexions de protocole de contrôle de la transmission (TCP) pour que les données de contrôle assurent l’initiation/1’arrêt d’un appel (c.-à-d., paquet de signalisations de données plan) comme, par ex., l’utilisation du protocole d’initiation de session (SIP). Dans un exemple de vidéo Skype, il peut y avoir un flux pour porter la signalisation SIP, pour démarrer, arrêter, et autrement contrôler la session, un deuxième flux pour transporter des paquets de voix avec le protocole de transport en temps réel (RTP) et un troisième flux pour transporter les paquets vidéo avec le RTP.

Lorsqu’une application est initiée par un utilisateur sur un nœud terminal, l’application peut débuter avec une signalisation de contrôle entre l’application et un serveur d’application associé. Par ex., lorsque l’application YouTube est lancée, elle demande des informations sur des sélections de vidéos disponibles à partir d’un serveur d’alimentation YouTube comportant plusieurs demandes simultanées de protocole de transfert hypertexte (HTTP). Le serveur d’alimentation YouTube répond avec des données concernant les flux en format comprimé dans les réponses HTTP. Chaque demande/réponse HTTP est réalisée sur des connexions TCP distinctes qui sont mises en œuvre à travers un protocole TCP (par ex., messages SYN, SYN-ACK et ACK) entre la pile TCP sur les nœuds terminaux et une pile TCP sur le serveur YouTube. Une fois les données de flux vidéos reçues, l’application YouTube peut demander des images vignettes auprès du serveur d’image de YouTube pour les vidéos énumérées dans le flux de données en utilisant de multiples demandes simultanées HTTP GET. Le serveur d’image de YouTube peut fournir les images vignettes demandées dans les réponses HTTP. Chaque demande/réponse vignettes est portée par sa propre connexion TCP distincte.

Pour chaque vidéo dans les flux vidéo et les résultats de recherche, de multiples localisateurs de ressource uniforme (URL) pour différents formats de vidéo sont fournis. L’application YouTube décide du format à utiliser selon les capacités et les configurations et les préférences de l’utilisateur. L’application YouTube envoie une demande HTTP GET au serveur avec l’URL de la vidéo dans le format choisi. Le serveur YouTube renvoie la vidéo demandée dans une réponse HTTP. La réponse HTTP est segmentée en plusieurs paquets IP. Le premier paquet IP de la réponse HTTP porte le code d’état de la réponse HTTP (200 = OK). Un exemple d’en-tête de réponse HTTP est illustré ci-dessous. HTTP/1.1 200 OK

Dernière modification : Samedi 11 février 2012 08:29:46 GMT

Type de contenu : vidéo/mp4

Date: Mardi 28 février 2012 00:31:10 GMT

expiration : Mercredi 29 février 2012 00:31:10 GMT

Cache-Contrôle : public, max-âge=86400

Accepte-Fourchettes : bytes

Contenu-Longueur : 56924607 X-Utilisateur-Agent-Options :

Connexion non-enregistrée : fermer X-Contenu-Type-Options : nosniff Serveur : gvs 1.0

Dans l’exemple ci-dessus, l’en-tête de la réponse HTTP « Type de contenu » indique que le format vidéo MP4 est inclus dans la réponse. L’en-tête de réponse HTTP « Contenu-Longueur » indique que la longueur de la vidéo MP4 comprise dans la réponse HTTP est d’environ 57 MB.

La FIG. 6 est un schéma des agents d’application et des applications conformément aux aspects de l’invention. Les agents d’application sont associés à un nœud d’accès 675 ; les applications sont associées à un nœud terminal 655. Les applications sur le nœud terminal 655 opèrent de façon coopérative avec les agents d’application dans le nœud d’accès 675. Les agents d’application et les applications peuvent être utilisés, par ex., dans le système de communication de la FIG. 4. Le nœud d’accès 675 de la FIG. 6 peut, dans divers modes de réalisation, être semblable à ou le même que le nœud d’accès 475 de la FIG. 4 ; le nœud terminal 655 de la FIG. 6 eut, dans divers modes de réalisation, être semblable à ou le même que le nœud terminal 455 de la FIG. 4.

Le nœud d’accès 675 comprend un agent d’application maîtresse 670. L’agent d’application maîtresse 670 communique avec une application maîtresse 651 dans le nœud terminal 655. Dans un mode de réalisation, l’application maîtresse 651 fait partie d’un système d’opération du nœud terminal 455. L’agent d’application maîtresse 670 et l’application maîtresse 651 facilite les communications entre les agents d’application spécifique 671(l)-671(n) au niveau du nœud d’accès 675 et des applications spécifiques 653(l)-653(n) dans le nœud terminal 655. L’agent d’application maîtresse 670 et l’application maîtresse 651 peuvent faciliter les communications entre tous les agents d’application spécifiques 671 et les applications spécifiques utilisant une connexion TCP unique. Un trajet IP, dans un mode de réalisation, est établi entre l’application maîtresse 651 et l’agent d’application maîtresse 670. L’application maîtresse 651 et l’agent d’application maîtresse 670 peuvent être au courant de l’adresse IP de sa paire, qui peut ou pas être la même que l’adresse IP du nœud d’accès ou terminal associé, par diverses techniques. Par ex., le nœud d’accès peut établir ou découvrir l’adresse IP d’un nœud terminal lorsque celui-ci entre dans le réseau. Dans plusieurs modes de réalisation, il existe de multiples nœuds terminaux fonctionnant simultanément et l’agent d’application maîtresse 670 est, de la même façon, au courant des multiples adresses de nœuds pairs. Le protocole de recherche d’adresse (ARP) peut être utilisé lorsqu’une adresse de Couche 2 sous-jacente, appropriée est disponible (par ex., une adresse MAC Ethernet) sur laquelle la fonction ARP peut être basée. Par ailleurs, l’agent d’application maîtresse 670 peut attribuer des adresses à l’application maîtresse 651 utilisant une technique d’attribution dynamique, par ex., un protocole DHCP. Par ailleurs, les informations du trajet IP peuvent être programmées dans une application maîtresse 651 et l’agent d’application maîtresse 670, par ex., par un opérateur à travers une connexion de gestion. Dans une autre alternative, le nœud d’accès 675 annonce l’adresse IP de l’agent d’application maîtresse 670. L’adresse IP peut être annoncée sous forme d’augmentation d’un canal de contrôle déjà en place pour contrôler le RAN (par ex., utilisation d’un trajet de contrôle RAN). Par ex., le nœud d’accès 675 peut comprendre l’adresse dans une réponse d’entrée de réseau vers les nœuds terminaux lorsqu’ils rejoignent le réseau ou diffuse l’adresse sur un canal de contrôle de diffusion (par ex., un canal SIB LTE). L’adresse IP n’a pas besoin d’être acheminée à l’extérieur du réseau défini par un nœud d’accès et les nœuds terminaux associés. Ainsi, diverses les adresses IP non-acheminables, bien connues, peuvent être utilisées. L’attribution des adresses IP non-acheminables dans un réseau LTE peut être basée sur une identité cellulaire physique (PCI) de l’eNodeB. Par ex., l’adresse IP d’un agent d’application maîtresse dans un eNodeB peut être attribuée une adresse de base de 172.16.0.0 plus un décalage de 9 bits (des 9 bits les moins importants) correspondant à sa valeur PCI de 9-bits. L’agent d’application maîtresse d’un eNodeB avec une valeur PCI de 255 sera attribué une adresse IP de 172.16.0.255. Étant donné que l’eNodeB PCI est diffusé à tous les UE dans le rayon de service de l’eNodeB, l’adresse IP d’un agent d’application maîtresse serait calculable avec un UE en absence de correction de la signalisation RAN. Cette technique pourrait également être appliquée à l’adressage IPv6.

De la même façon, l’adresse IP d’une application maîtresse dans un équipement utilisateur LTE peut également être une adresse non-acheminable. L’adresse non-acheminable peut être formée d’une composition d’une adresse de base (en utilisant l’IPv4 ou l’IPv6) plus un décalage. Le décalage peut être basé, par ex., sur un identifiant de porteuse radio par défaut ou identité de souscription mobile temporaire (M-TMSI). Étant donné que le schéma d’adressage peut être connu par un agent d’application maîtresse, l’adresse IP de l’application maîtresse peut être connue en absence de correction de la signalisation RAN. Par ailleurs, les datagrammes envoyés dans le cadre des communications en coopération avec un agent APP peuvent utiliser une combinaison d’adresses source tout-zéro (0.0.0.0) et des adresses de destination de diffusion ou multicast. Dans un mode de réalisation, la communication provenant d’un agent d’application maîtresse 670 vers l’application maîtresse 651 peut utiliser une adresse source IP de 0.0.0.0 est une adresse de destination de 255.255.255.255. Par ailleurs, une adresse multicast, dans la fourchette de 224.0.0.0 et de 239.255.255.255 peut être utilisée comme l’adresse de destination. Dans un mode de réalisation, l’adresse de destination multicast ou de diffusion peut être remplacée par l’adresse IP unicast appropriée, une fois attribuée et découverte avec les techniques décrites ci-dessus. Des procédés et des adresses semblables peuvent être utilisés pour les agents d’application spécifiques 671 et les applications spécifiques 653. Les procédés d’adressage IPv4 décrits ci-dessus peuvent être étendus pour fonctionner dans un réseau IPv6.

Dans un mode de réalisation, la communication entre l’application maîtresse 651 et l’agent d’application maîtresse 670 se fait sur un canal de contrôle de la communication spécifique à la technologie d’accès radioélectrique (RAT). Les communications peuvent utiliser, par ex., des messages individuels ou diffusés. Afin de faciliter de nouvelles applications spécifiques, les messages spécifiques aux RAT qui procurent un contenant pour les messages spécifiques à une application peuvent être utilisés. Par ex., dans un réseau LTE, en référence à la FIG. 5, un ou plusieurs supports radio de signalisation (SRB) peuvent être utilisés pour porter des messages de et vers une application 551 et l’agent d’application 570. Dans un mode de réalisation, les messages peuvent être portés sur un ou plusieurs SRB existant tel qu’il est défini par la norme du projet de partenariat de 3e génération (3GPP). Par ailleurs, les messages peuvent être portés sur un ou plusieurs SRB établis dans le but de porter des messages entre une application et un agent d’application. Dans un tel scénario, le module d’inspection de paquet 529 dans le nœud d’accès 575 peut intercepter, traiter et répondre à des messages de communication en coopération avec un agent APP envoyés sur un SRB entre le nœud terminal 555 et le nœud d’accès 575 plutôt que de transférer les messages vers un MME tel qu’il est défini par les normes 3GPP.

Dans un mode de réalisation alternatif, les communications en coopération avec un agent APP peuvent être utilisées comme un canal de communication de plans de données utilisateur existants ou spécialisés établis dans le but de communiquer le trafic de données d’application entre le nœud d’accès 575 et le nœud terminal 555. Dans ce cas, des communications en coopération avec un agent APP sur le trajet de contrôle logique de la communication en coopération avec un agent APP 503 et le trafic des donnés utilisateurs sur le trajet de données d’application logique 501 peut être hébergé sur le même canal de communication de plan de données utilisateur. Par ex., dans un réseau LTE, des communications en coopération avec un agent APP peuvent être portées sur un support de radio de données par défaut (DRB) ou un DRB spécialisé est identifiés ou marqués pour la consommation au niveau d’une de d’accès plutôt qu’un transfert vers le réseau central. Par ailleurs, un nouveau DRB spécialisé peut être créé dans le but de porter les communications en coopération avec un agent APP. En outre, les communications en coopération avec un agent APP peuvent être portées sur de multiples DRB ou sur une combinaison d’un ou de plusieurs SRB et un ou plusieurs DRB. Par ex., différents supports peuvent être associés à différentes applications spécifiques ou groupes d’applications spécifiques.

Dans un mode de réalisation, un DRB spécialisé au transport des communications en coopération avec un agent APP peut être créé sans utilisation de signalisation entre le nœud terminal 555 et le réseau central. Par ex., dans un réseau LTE, un DRB spécialisé au transport des communications en coopération avec un agent APP peut être créé sans implication d’une entité MME localisée dans le réseau central réduisant ainsi la signalisation et améliorant l’efficacité du réseau. Dans un tel scénario, le module d’inspection de paquet 529 dans le nœud d’accès 575 peut intercepter, traiter et répondre à des messages de communication en coopération avec un agent APP envoyés entre le nœud terminal 555 et le nœud d’accès 575 plutôt que de transférer les messages vers un MME ou S-GW tel qu’il est défini par les normes 3GPP pour la signalisation des messages et le trafic des données, respectivement. L’agent d’application maîtresse 670 et l’application maîtresse 651 peuvent également traiter les communications en coopération avec un agent APP. Par ex., l’agent d’application maîtresse 670 ou l’application maîtresse 651 peuvent coordonner, combiner ou manipuler les informations communiquées entre les agents d’application spécifiques 671 et les applications spécifiques 653. L’application maîtresse 651 peut traiter une communication en coopération avec un agent APP de sorte que les applications spécifiques 653 ne doivent pas être au courant ou impliqués dans les communications en coopération avec un agent APP. Ceci peut permettre des applications spécifiques préexistantes de bénéficier des communications en coopération avec un agent APP sans modification.

Dans un mode de réalisation, l’application maîtresse 651 peut intercepter des communications de lecture vidéo en continu entre une application sur un nœud terminal est une application serveur et filtrer les représentations vidéo disponibles en fonction des limites de la capacité du système. Par ex., pensez à l’exemple de la lecture vidéo en continu YouTube décrit ci-dessus. Une vidéo en lecture continue peut être disponible en multiples formats et représentations chacune avec une vitesse de données associée. Par ex., le serveur YouTube peut utiliser un format de téléchargement progressif permettant à l’application YouTube (un exemple d’une application spécifique 653) de choisir un fichier de lecture parmi un ensemble de fichiers, chacun ayant une vitesse de bit différente, via une commande HTTP GET. La liste des formats disponibles et des vitesses de bit est envoyée via une liste d’URL (un par fichier de lecture) et elle est normalement envoyée à partir du serveur YouTube vers l’application YouTube. Cette liste peut être interceptée par l’application maîtresse 651 et filtrée en fonction des limites de la capacité disponible avant d’être transmise vers l’application YouTube.

Le filtrage peut prendre plusieurs formes. Dans un mode de réalisation, la liste de formats disponibles interceptée par l’application maîtresse 651 est envoyée via des communications en coopération avec un agent APP vers l’agent d’application maîtresse 670 ou l’un des agents d’application spécifiques 671. Les formats peuvent être filtrés par l’agent d’application maîtresse 670 ou l’agent d’application spécifique 671. Le filtrage peut se faire après consultation avec un module de contrôle de la ressource (par ex., le module de contrôle de la ressource 480 de la FIG. 4). Par ex., pendant des périodes de congestion, le module de contrôle de la ressource peut procurer une réponse de contrôle d’admission qui limite toutes les lectures vidéo en continu à des vitesses de bit inférieur à 1 Mb/s. L’agent d’application maîtresse 670 ou l’agent d’application spécifique 671 utilise cette information pour supprimer toutes les options de lecture en continu (par ex., URL) avec des vitesses de bit supérieur à 1 Mb/s dans la liste de formats disponibles avant de renvoyer la liste filtrée vers l’application maîtresse. Dans un mode de réalisation alternatif, l’agent d’application maîtresse 670 peut procurer des mises à jour périodiques à l’application maîtresse 651 à travers des communications en coopération avec un agent APP décrivant les limites actuelles pour les vitesses de bit de lecture vidéo en continu. L’application maîtresse 651 utilise, à son tour, ces informations pour filtrer localement les options de vitesse de bit avant de les envoyer à l’application spécifique à YouTube. Les techniques susmentionnées peuvent être appliquées à une quelconque technologie de lecture vidéo impliquant des flux à multi-vitesses de bit, telles que la lecture en continu adaptative dynamique HTTP (DASH), la lecture en continu lisse de Microsoft, la lecture en continu en direct de Apple et la lecture en continue dynamique de Adobe.

Les informations ou les demandes qui peuvent être communes à de multiples applications différentes peuvent être regroupées. Par ex., l’agent d’application maîtresse 670 peut fournir à l’application maîtresse 651 une marge pour la congestion actuelle et l’excès de ressource. L’application maîtresse 651 peut ensuite fournir des informations de marge de congestion et de ressources aux applications spécifiques 653.

En outre, des requêtes communes, par ex., que ce soit d’une classe d’application particulière (par ex., voix, vidéo) à une vitesse de données particulière peuvent être supportées avec un niveau souhaité de qualité de service, peuvent être uniformément mises en œuvre dans une paire application maîtresse/agent d’application maîtresse unique plutôt que dans chaque application spécifique et chaque agent d’application spécifique. Les réponses de contrôle d’admission, telles que celles qui déterminent ou modifient un service, peuvent en outre être mises en œuvre au niveau de l’application maîtresse 651 et de l’agent d’application maîtresse 670.

En outre, afin de supporter des communications en coopération commune générées par une application, l’application maîtresse 651 et l’agent d’application maîtresse 670 peuvent passer à travers une quelconque communication en coopération avec un agent APP supplémentaire. C.-à-d., les communications spécifiques en coopération à une paire particulière des applications spécifiques 653 et des agents d’application spécifiques 671 peuvent passer à travers l’application maîtresse 651 et l’agent d’application maîtresse 670. Par ex., les communications en coopération concernant l’état de tampon d’une lecture de vidéo client peut passer de l’une des applications spécifiques 653 à travers l’application maîtresse 651 et l’agent d’application maîtresse 670 vers l’un des agents d’application spécifiques 671.

Utilisation d’un agent d’application maîtresse ou d’une application maîtresse peut réduire la correction de signalisation et réduire la charge sur les développeurs d’applications. Ceci peut également réduire la complexité de l’interfaçage du ou des les agents d’application 671 avec d’autres fonctions dans le nœud d’accès 675, tel qu’un module de contrôle de la ressource.

Plusieurs variations des agents d’application et des applications illustrées dans la FIG. 6 sont possibles. Par ex., une application maîtresse peut communiquer directement avec des agents d’application spécifiques dans un nœud d’accès qui ne comprend pas un agent d’application maîtresse. De la même façon, une application maîtresse peut communiquer directement avec des agents d’application spécifiques dans un nœud terminal qui ne comprend pas une application maîtresse. En outre, un nœud d’accès peut comporter un agent d’application maîtresse aussi bien qu’un ou plusieurs des agents d’application qui communiquent directement avec des agents spécifiques, et un nœud terminal peut comporter une application maîtresse aussi bien qu’une ou plusieurs applications qui communiquent directement avec des agents d’application spécifiques. En outre, les schémas d’adressage susmentionnés (ou des variants de ceux-ci) peuvent également être utilisés en absence d’un agent d’application maîtresse ou d’une application maîtresse.

La présence ou l’absence d’un agent d’application maîtresse dans un nœud d’accès peut être signalée en utilisant un champ de données ou une bit à l’intérieur d’un canal de contrôle de diffusion existant, par ex., dans un message LTE SIB ou MIB. Le champ de données ou le bit peut utiliser un emplacement non utilisé, mais existant, dans un message. Par ailleurs, un nouveau champ dans un message SIB existant ou un SIB complètement nouveau peut être créé dans le but d’indiquer la présence d’un agent d’application maîtresse.

Dans un mode de réalisation, le nœud d’accès 675 communique la présence ou l’absence de l’agent d’application maîtresse 670 via la communication à un élément dans le réseau central qui informe conséquemment le nœud terminal 655. Par ex., dans un réseau LTE, un eNB peut envoyer un message indiquant l’existence ou l’absence d’un agent d’application maîtresse sur l’eNB au serveur MME situé dans un réseau central EPC en utilisant le canal de communication SI défini par la 3GPP. La 3GPP Sl-Setup/mise à jour de la configuration eNodeB peut être améliorée pour indiquer le support d’agents d’application par l’utilisation d’un marqueur d’extension ASN.l est un nouveau champ utilisant un format de valeur de type longueur (TLV). Lors de la réception d’un message SI, le MME peut envoyer des informations de présence ou d’absence vers l’UE via un message 3GPP NAS. Plusieurs autres procédés de signalisation peuvent également être utilisés.

Le nœud terminal 655, dans un mode de réalisation, peut indiquer la présence ou l’absence d’une application maîtresse 651 à travers la communication à un élément dans le réseau central. Par ex., un LTE UE peut indiquer la présence d’une application maîtresse 651 via un message NAS envoyé au MME. Par ex., le message spécifique à l’UE « Sl-Initial Context Setup/E-RAB Setup/Modify » peut être modifié pour comprendre l’information de présence comme élément optionnel en format TLV. Suivant la réception par le MME, le MME communique ensuite cette information à l’eNB approprié.

Dans un mode de réalisation, le nœud d’accès 675 peut communiquer la présence ou l’absence d’un agent d’application maîtresse 670 en ajoutant un bit de présence à une entête de paquet d’une couche de la pile de protocoles RAN (par ex., les formats de paquet définis pour la couche de convergence des données de paquet, la couche de contrôle de liaison radio ou la couche de commande d’accès au support illustrée dans la FIG. 5). Une technique similaire peut être utilisée par le nœud terminal 655 pour indiquer la présence d’une application maîtresse 651 vers le nœud d’accès 675.

Des communications en coopération avec un agent APP peuvent être utilisées de plusieurs façons. Les paragraphes suivants décrivent des exemples de communication en coopération avec un agent APP. Beaucoup d’exemples sont décrits pour des applications spécifiques et des technologies de réseau spécifiques, mais il doit être compris que les exemples et les variations de ceux-ci sont largement applicables à d’autres applications et à d’autres technologies de réseau. De la même façon, beaucoup des exemples sont décrits pour des communications en coopération avec un agent APP entre un agent d’application dans un nœud d’accès est une application dans un nœud terminal, mais il doit être compris que les exemples et les variations de ceux-ci sont largement applicables à d’autres dispositifs.

Les communications en coopération avec un agent APP peuvent être utilisées pour adapter les communications vidéo à des conditions de réseau de communications changeantes, par ex., les conditions RAN. Dans les protocoles de lecture vidéo en continu en temps réel, par ex., un agent d’application peut informer l’application de lecture vidéo en continu en temps réel associée lorsque le système de communication possède plus ou moins de ressources disponibles. L’agent d’application peut, par ex., informer l’application sur les conditions du réseau en communiquant la disponibilité de la ressource ou en communiquant de nouvelles vitesses de données préférées ou maximales ou les résolutions pour la vidéo. Lors de la demande du nouveau bloc ou segment de la vidéo, l’application peut demander un segment possédant une vitesse de bit avec une moyenne ou pique différent ou une résolution différente afin d’adapter la vidéo au changement dans les ressources.

Dans un mode de réalisation, un agent d’application peut informer une ou plusieurs applications vidéo sur l’estimation de la disponibilité future de la source. L’estimation de la disponibilité future de la ressource peut être communiquée sous forme d’un chiffre unique (par ex., 2 Mb/s) sur une période définie (par ex., les 2 prochaines secondes). Par ailleurs, une estimation multipoint peut être utilisée pour illustrer la relation entre la capacité future et le temps sur un horizon plus long. Un exemple d’estimation multipoint est illustré dans le tableau ci-dessus. La deuxième colonne présente les capacités estimées aux temps donnés dans la première colonne.

Une application vidéo peut utiliser la capacité future estimée pour choisir le prochain segment vidéo pour que la vitesse de bit soit au niveau de ou en dessous de la capacité de vitesse de bit future estimée pour la durée du segment. Par ex., prenons un flux vidéo qui possède des segments de 2 secondes disponibles à 3 vitesses de bit différentes : 0,7 Mbps, 1,3 Mbps et 2,5 Mbps. Si l’application vidéo et informer que la vitesse de bit future estimée sera réduite de 1,5 Mb/s à 1,0 Mb/s, alors l’application qui est allée chercher des segments de 1,3 Mb/s peut choisir un segment de 0,7 Mb/s à la prochaine opportunité.

Une application vidéo peut utiliser la vitesse de bit future estimée pour justifier une vitesse de bit supérieure que la capacité actuelle quand il est attendu que cette capacité future puisse être commodément supérieure et que le taux d’occupation de la mémoire actuel est suffisant pour assurer un fonctionnement sans arrêt (par ex., la mémoire locale ne se videra pas) jusqu’à qu’une capacité supérieure soit disponible. Par ex., prenons une application vidéo qui va chercher des segments de 2,0 Mb/s et qui a 10 secondes vidéo stockée dans sa mémoire locale. L’application reçoit ensuite la capacité future estimée donnée dans l’exemple du tableau ci-dessus, qui prédit que la capacité chutera de la valeur actuelle (temps=0) de 2,0 Mb/s à un minimum de 0,5 Mb/s dans un temps 3 seconds dans le futur après quoi la capacité remontra rapidement et dépassera la valeur actuelle. Si la période de temps pour laquelle il y a une diminution de la capacité (c.-à-d., la capacité estimée est inférieure de la vitesse de bit du segment actuel) est plus courte que la quantité de vidéo dans la mémoire locale, l’application peut continuer à aller chercher des segments ayant une vitesse de bit supérieure que la capacité actuelle. Dans l’exemple ci-dessus, le manque de capacité commence à t=l seconde et se termine à t=4 secondes, et il est donc de 3 secondes. Etant donné que le taux d’occupation de la mémoire locale est de 10 secondes, l’application vidéo peut continuer à aller chercher des segments de 2,0 Mb/s.

Par ailleurs, une estimation que les ressources futures pourraient diminuer peut être utilisée par une application vidéo pour réduire la vitesse de bit pour le prochain segment de vidéo

avant la réduction, augmentant ainsi le taux d’occupation de la mémoire client et réduisant l’impact (par ex., arrêt de lecture) de la réduction qui s’en vient.

Divers procédés peuvent être utilisés pour estimer la disponibilité future de la ressource. Par ex., un historique de la disponibilité de ressources peut être stocké dans un module d’estimation de la ressource. Une corrélation de la disponibilité de ressources à l’heure du jour, du jour de la semaine, et d’autres événements, peut permettre à un agent d’application de prédire si les ressources futures seront supérieures ou inférieures que les ressources actuelles. Par ex., un LTE eNB servant une autoroute inter-état majeure peut avoir une demande maximale au cours des périodes pendant la matinée et la soirée de départ et de retour du travail en semaine. En se basant sur ces données historiques, un agent d’application peut, par ex., prédire que les ressources utilisateurs chuteront en moyenne d’une vitesse de 2 % par minute sur les 30 prochaines minutes lors de l’augmentation du trafic.

En outre, la disponibilité de la ressource entre un nœud terminal donné est un nœud d’accès peut être estimée en se basant sur un schéma répétitif des conditions de canal variant dans le temps. Par ex., le module d’estimation de la ressource 481 et le nœud d’accès 475 peuvent suivre la modulation DL et UL et le schéma de codage (MCS) d’un terminal donné et déterminer qu’un schéma répétitif existe. Par ex., les conditions de canal (et donc la capacité disponible) d’un utilisateur peut passer d’une condition excellente à une piètre condition est de retour à une condition excellente sur une période de 5 minutes, tous les jours autour de 17 heures. Un tel schéma peut être le résultat d’un employé de bureau qui quitte son bureau et qui marche vers sa voiture. Dans un mode de réalisation, un nœud d’accès peut déterminer qu’un utilisateur est une fois encore à l’intérieur d’un tel schéma en utilisant des données telles que l’heure du jour et en faisant la correspondance avec l’historique récent du canal (par ex., la dernière minute) en comparaison avec des schémas historiques du canal (par ex., établis sur des périodes de 5 minutes). Une fois qu’un schéma est détecté, la capacité future peut être estimée en se projetant en avant à partir de la position actuelle dans le schéma historique détecté. L’estimation de la disponibilité future de la ressource peut également être réalisée par extrapolation. Par ex., une régression linéaire de la capacité récente (à la fois par nœud terminal et pour un nœud d’accès complet) peut être utilisé pour prédire la capacité dans le futur proche. D’autres formes de lissage de courbe historique (par ex., polynomial, exponentiel) peuvent également être utilisées pour extrapoler la disponibilité de la ressource. Les communications en coopération avec un agent APP peuvent être utilisées pour ajuster l’ordonnancement des communications à partir d’un nœud d’accès.

Un dispositif qui utilise l’ordonnancement centré application pour obtenir des informations concernant l’application provenant des communications en coopération avec un agent APP. Cette information concernant l’application obtenue via les communications en coopération avec un agent APP pourrait sinon être difficile impossible à obtenir. Les communications coopération avec un agent APP peuvent réduire ou éliminer le besoin de détection d’application et la détection d’informations d’application pour les applications en coopération. Par ex., un dispositif qui peut réaliser la détection d’application et la détection d’informations d’application telle qu’il est décrit la demande de brevet américain no. 13/607 559, déposée le 7 septembre 2012 et intitulé « Systems and Methods for Congestion Détection for use in Prioritizing and Scheduling Packets in a Communication Network » peut réaliser moins de détection lorsqu’il communique avec des applications qui procurent des communications en coopération avec un agent APP. La coopération peut également procurer des informations plus précises sur l’état d’une application. Pour une session vidéo, par ex., les communications en coopération avec un agent APP peuvent communiquer si une vidéo est dans un état de mise en mémoire initial, un état de lecture/visualisation, un état de pause, un état arrêté, un état rembobiné ou un état d’avance rapide. Le nœud d’accès peut utiliser l’état de la vidéo dans des décisions de contrôle de l’ordonnancement ou de l’admission.

Un temps de mise en mémoire initial faible (la durée de la période de mise en tampon entre une demande de données initiale et le moment du début de la lecture) est important pour la qualité de l’expérience de l’utilisateur au cours de la lecture de la vidéo en lecture continue. Dans un mode de réalisation, l’ordonnancement des ressources appliqué à une session de vidéo en lecture continue par un nœud d’accès peut être temporairement augmenté afin de réduire le temps de mise en tampon initial. Ceci peut être réalisé en augmentant un AF pour la cession de lecture de vidéo en continu au cours de la période de mise en tampon initiale. Les informations concernant la période de mise en tension initiale peuvent être communiquées au nœud d’accès à travers des communications en coopération avec un agent APP. Des informations concernant la période de mise en tampon initiale peuvent comprendre, par ex., le fait que le nœud terminal possède une vidéo dans la période de mise en tampon initiale et le nombre de bits qui doit être reçu avant le début de la lecture (« bits restants »). Les ressources d’ordonnancement peuvent être augmentées jusqu’à ce que la transmission des bits restants soit complète. En outre, une demande de contrôle d’admission faite par un nouvel utilisateur peut être retardée jusqu’à ce que les nouvelles périodes de mise en tampon initiales d’une ou de plusieurs sessions vidéo pour un ou plusieurs utilisateurs existants soient complétées. Un nœud d’accès peut calculer le temps d’achèvement d’une période de mise en tampon initiale en divisant les bits restants par les ressources actuelles ou prédites (par ex., exprimé en bits par seconde) attribuées au flux vidéo.

Les communications en coopération avec un agent APP peuvent communiquer l’état de mise en tampon de la lecture, le taux d’occupation de la mémoire vidéo locale et les indications de gel provenant de l’application vidéo client. Les paramètres d’ordonnancement dans le nœud d’accès peuvent être ajustés de façon correspondante. Dans un mode de réalisation, les ressources de communications attribuées à une session vidéo par un nœud d’accès peuvent être basées sur le taux d’occupation de la mémoire actuel telle qu’il est communiqué par les communications en coopération avec un agent APP à partir d’un nœud terminal. Par ex., prenons un nœud terminal qui rapporte un faible taux d’occupation de la mémoire et qui risque de s’arrêter. Dans un tel cas, le nœud d’accès peut augmenter les ressources attribuées à la session vidéo en augmentant l’AF ou la priorité d’ordonnancement pour les paquets associés. Inversement, prenons un nœud terminal qui rapporte un taux élevé d’occupation de la mémoire. Pour cette session vidéo, les ressources d’ordonnancement peuvent être diminuées via une diminution de l’AF ou de la priorité d’ordonnancement libérant ainsi des ressources pour d’autres sessions.

Des communications en coopération avec un agent APP peuvent être utilisées dans les décisions de contrôle d’admission. Les communications en coopération avec un agent APP peuvent être utilisées pour créer une image plus précise de la demande en ressources pour les systèmes de contrôle d’admission centrés application. Par ex., une application en coopération sur un nœud terminal tel qu’une lecture vidéo en continu client peut rapporter la vitesse de bit moyenne et la durée d’une vidéo en lecture continue avec une communication en coopération avec un agent APP. De telles informations peuvent être utilisées par un nœud d’accès lors du calcul de la demande en ressource actuelle ou future. En soustrayant la demande en ressource de la capacité d’une d’accès, une mesure de la capacité en excès disponible est créée qui pourrait être appliquée à de nouveaux services demandant l’admission.

Les communications en coopération avec un agent APP peuvent être utilisées pour procurer des options supplémentaires pour l’admission d’une version modifiée d’une session ou pour procurer des options supplémentaires pour la modification d’autres sessions afin de permettre une nouvelle session. Par ex., une application en coopération sur un nœud terminal peut communiquer un ensemble d’options de vitesse de bit disponible pour un clip vidéo en utilisant une communication en coopération avec un agent APP (par ex., un ensemble de vitesses de bit de rendement transmis par un serveur « Lecture en continu adaptative dynamique sur HTTP » ou DASH vers une application DASH au cours de l’initialisation d’une session). En fonction de la capacité en excès disponible, le nœud d’accès peut éliminer ou interdire l’utilisation d’une de plusieurs des options à vitesse de bit supérieure dans la liste. La liste écourtée peut être retransmise au nœud terminal fournissant à l’application un ensemble réduit options de vitesse de bit. Ceci permet une lecture vidéo fiable à l’intérieur des contraintes de la capacité disponible du nœud d’accès. En outre par ailleurs, dans les réseaux comportant de multiples nœuds terminaux, le soutien d’une nouvelle session vidéo, tels que la cession DASH ci-dessus, peut impliquer l’emploi d’une liste de vitesses de bit mise à jour vers une plusieurs sessions vidéo déjà en cours. Par ex., afin de soutenir un nouveau 10e de la session vidéo DASH (la 10e session qui doit être ajoutée à neuf sessions en cours), un nœud d’accès peut réduire la vitesse de bit maximale disponible à la 10e session aussi bien que l’emploi de listes de vitesses de bit mises à jour (avec des options de vitesses de bit maximal plus faibles) à l’une ou plusieurs des 9 sessions en cours afin de libérer suffisamment de capacité pour soutenir la 10e session. Pendant le temps de l’augmentation de l’excès de capacité, les procédés susmentionnés peuvent être inversés (c.-à-d., étendre la liste de vitesses de bit en augmentant la vitesse de bit maximale permise) afin d’améliorer la qualité de l’expérience de l’utilisateur. En outre, dans des systèmes, tels que le LTE, dans lesquelles le contrôle de l’admission est mentionné sur la base d’un porteur logique brut plutôt que sur une base par session, les communications en coopération avec un agent APP peuvent être utilisées pour créer un contrôle d’admission plus fin qui répond avec des rejets et des modifications sur une base par session.

Les communications en coopération avec un agent APP peuvent être utilisées pendant la cession. Les informations provenant des communications en coopération avec un agent APP peuvent être utilisées pour optimiser la qualité de l’expérience de l’utilisateur pendant la cession. Par ex., les données mises en tampon dans une application peuvent être augmentées avant la cession afin d’éviter que la mémoire ne se vide au cours de la cession. Lorsqu’une cession est attendue pour un nœud terminal exécutant une application vidéo en coopération et que le nœud d’accès est impliqué, à travers communications en coopération avec un agent APP, et que la mémoire de lecture du vidéo client possède une capacité supplémentaire, les paramètres d’ordonnancement dans le nœud d’accès peuvent être ajustés pour augmenter la quantité de données vidéo mises en tampon dans le nœud terminal juste avant la cession. Le moment de la cession peut également être contrôlé de sorte que la cession se passe pendant un temps convenable pour l’application, c.-à-d., pendant un temps pendant lequel toute interruption ou délai dans la communication a moins d’impact sur la qualité de l’expérience. Par ex., si la cession est attendue nécessaire immédiatement, la cession peut être initiée immédiatement lorsque l’application indique à l’agent d’application que la vidéo a été mise en pause. De la même façon, un agent d’application peut fournir des informations de tolérance de délai de communication des applications, comme une application e-mail ou une application navigateur, pour retarder des demandes d’envoi et de réception jusqu’à qu’une cession soit complète. L’amélioration de la cession à travers des communications en coopération avec un agent APP peut améliorer l’efficacité à la fois pour l’application et pour le réseau de communication versus la retransmission des données perdues ou endommagées pendant la cession.

Des communications en coopération avec un agent APP peuvent être utilisées pour évaluer la qualité de la vidéo. Par ex., des communications en coopération avec un agent APP peuvent communiquer des informations provenant de rapports d’un protocole de contrôle RTP (RTCP). Les rapports RTCP contiennent des informations qui permettent d’accéder à la qualité de la vidéo. Alors que nœud d’accès pet détecter et extraire des informations à partir des rapports RTCP (par ex., avec l’utilisation d’un module d’inspection de paquet), les mêmes informations des informations semblables peuvent être transférées d’une application vers un agent d’application, réduisant les ressources de calcul nécessaires dans le nœud d’accès. La disponibilité des informations sur la qualité vidéo peuvent être utilisée pour ajuster les paramètres d’ordonnancement et les allocations de ressources. Par ex., le nœud d’accès peut augmenter les priorités de l’ordonnancement pour une application vidéo afin d’améliorer la qualité, si celle-ci est insuffisante, ou peut réallouer des ressources à d’autres applications si la qualité est supérieure à un seuil.

Les communications on coopération avec un agent APP peuvent être utilisées pour l’ordonnancement des accusés de réception. Les informations provenant des communications en coopération avec un agent APP peuvent être utilisé, par ex., pour l’ordonnancement des messages d’accusé de réception TCP (ACK). Un ordonnancement amélioré des messages TCP ACK sur la ligne ascendante peut éviter ou rectifier des situations qui pourraient causer un arrêt ou un manque de données dans la liaison descendante pour une application utilisant le TCP comme l’un de ces protocoles de transport et de connexion. Le nœud d’accès peut utiliser les informations concernant le timing des messages TCP ACK lorsque le nœud d’accès attribue la largeur de bande de la liaison montante au nœud terminal. Un choix de moment plus précis pour l’attribution de la largeur de bande de la liaison ascendante pour les messages TCP ACK peut être possible si une application en coopération procure des informations concernant la prévision de la survenue des messages TCP ACK. La largeur de bande de communications utilisée pour l’attribution de la largeur de bande peut également être réduite.

En outre, la robustesse des schémas de modulation et de codage peut être augmentée lorsque les messages TCP ACK sont attendus. Par ailleurs, une application en coopération peut envoyer un message TCP ACK après un délai même si aucune donnée n’a été reçue à fin de prévenir un arrêt ou un gel. Les cas de délai peuvent être rapportés à l’agent d’application, par ex., pour être utilisés pour ajuster les paramètres du programmeur afin d’améliorer la performance future. Cet agent d’application peut rapporter des conditions de congestion à l’application lui permettant de modifier seuil de délai pour l’envoi d’un message TCP ACK après un délai même si aucune donnée n’a été reçue. La modification du seuil peut se faire, par ex., lorsque le prochain segment de vidéo peut être demandé à une vitesse plus faible pour éviter des congestions futures et la probabilité de gel est élevée pour le restant du segment vidéo actuel.

Les communications on coopération avec un agent APP peuvent être utilisées pour la différenciation du service. Les informations provenant des communications en coopération avec un agent APP peuvent être utilisées, par ex., afin de distinguer entre des scénarios de service qui pourraient sinon être difficile ou impossible à détecter. Une application e-mail en coopération, par ex., peut indiquer à l’agent d’application correspondant l’événement qui a déclenché la synchronisation d’un e-mail. Lorsque la synchronisation d’un e-mail est déclenchée par une expiration de délai ou par un autre stimulus généré automatiquement, le nœud d’accès peut donner une priorité relativement faible à l’ordonnancement des données de la liaison descendante et du protocole de liaison ascendante correspondant, et lorsque la synchronisation d’e-mails est déclenchée par l’action d’un utilisateur, le nœud d’accès peut donner une priorité relativement grande à l’ordonnancement des données de liaison descendante et du protocole de liaison ascendante correspondant. Dans un mode de réalisation, une attribution de faible ou de haute priorité peut être établie en appliquant un AF plus faible ou plus élevé au service dans le planificateur, augmentant ou diminuant ainsi les ressources rendues disponibles au service. Ainsi, une priorité élevée est utilisée lorsque l’utilisateur est en attente et une faible priorité est utilisée lorsqu’il n’y a aucun utilisateur en attente. Ainsi, les communications en coopération avec un agent APP provenant d’un nœud terminal vers un nœud d’accès peuvent comprendre des informations concernant le stimulus d’une demande de communication, par ex., si un utilisateur est en attente de données demandées.

De la même façon, une application peut différencier entre le fait qu’un utilisateur demande spécifiquement à avoir une vidéo (par ex., l’utilisateur a cliqué sur une liaison vidéo) d’une vidéo intégrée par coïncidence dans une page Internet (par ex., l’utilisateur a choisi un lien vers un article qui contiendrait une vidéo intégrée). Lorsque l’utilisateur choisit spécifiquement une vidéo, la qualité de l’expérience de la vidéo est plus importante et un planificateur peut ajuster les paramètres d’ordonnancement selon les informations reçues des communications en coopération avec un agent APP. Par contre, lorsqu’une vidéo est secondaire, le planificateur peut donner plus de priorité au texte de l’histoire. Une démarche semblable peut être utilisée, par ex., pendant une congestion importante, pour les décisions de contrôle de l’admission.

En outre, une application qui combine de multiples médias dans une session peut indiquer l’importance relative du média à l’agent d’application. Une application d’appels vidéo, par ex., peut considérer la partie vocale de la session comme étant plus importante que la partie vidéo. En cas de ressources insuffisantes pour à la fois la partie vocale et la partie vidéo, le nœud d’accès peut utiliser des informations concernant l’importance relative reçues des communications en coopération avec un agent APP pour préserver la qualité de la partie audio alors que la partie vidéo est dégradée ou arrêtée.

Les communications en coopération avec un agent APP peuvent être utilisées pour éviter une réduction de la qualité de l’expérience causée par dépouillement du trafic. Les vitesses de trafic vers le terminal et à partir de celui-ci peuvent être limitées de plusieurs façons. Lorsque les limites de vitesse de trafic sont dépassées, le dépouillement du trafic peut être déclenché et certain paquets rejetés ou retardés. Le dépouillement du trafic peut se faire dans un nœud de communication qui n’est pas au courant des besoins des applications du nœud terminal. Un tel nœud de communications retardera ou rejettera ainsi des paquets sans égard aux effets sur la qualité de l’expérience. Les communications en coopération avec un agent APP peuvent être utilisées par des applications pour éviter la demande excessive de données qui pourrait déclencher le dépouillement. En ne déclenchant pas le dépouillement, la qualité de l’expérience peut être améliorée De la même façon, d’autres capacités de communication peuvent être signalées au nœud terminal et celui-ci peut ajuster sa demande en conséquence.

Un exemple de limite de vitesse est la vitesse de bit maximale agrégée (AMBR) qu’un système LTE applique à un nœud terminal (équipement utilisateur dans une nomenclature LTE). L’AMBR contrôle les ressources de largeur de bande qui pourraient être attribuées aux 2 terminaux, même si un excès de ressources de systèmes existe. La passerelle de paquet LTE est souvent conditionnée pour dépouiller les données acheminées vers le nœud terminal, retardant ou rejetant des paquets, afin d’assurer que la vitesse moyenne des donnée ne dépasse pas celle de l’AMBR.

Les vitesses de trafic pour le nœud terminal peuvent également être limitées de façon contractuelle par un accord au niveau du service (SLA). Les limites SLA peuvent s’appliquer à divers niveaux, par ex., le nœud terminal, le lien logique, un porteur ou une connexion.

Le nœud terminal peut avoir une connaissance limitée, ou aucune connaissance, de ses limites de vitesse. Par ex., le terminal peut connaître sa limite AMBR mais non pas sa limite SLA. Les applications individuelles ne connaissent généralement pas les limites de vitesse. En outre, l’application individuelle ne sera pas quelles autres applications sont actives ou les demandes en ressources des autres applications par rapport aux limites de vitesse. Par ex., une application vidéo peut ne pas être au courant qu’une résolution vidéo particulière entraînera le non dépassement d’une limite de vitesse, et ainsi déclencher des délais et des rejets de paquet pour toutes les applications sur le nœud terminal.

Dans un mode de réalisation, une application maîtresse ou un agent d’application maîtresse, par ex., telle qu’illustrée dans la FIG. 6, peut enregistrer les demandes en ressources d’application cumulée et suivre les ressources cumulées versus les limites de vitesse. D’autres modules, par ex., une partie du système d’exploitation d’un nœud terminal ou une partie de la pile de protocoles RAN (par ex., contrôle de ressource radio (RRC) ou gestion de ressource radio (RRM) pour le LTE), peut enregistrer les demandes de ressources d’application cumulative pour une utilisation par les applications. Une application en coopération peut communiquer avec l’application maîtresse, l’agent d’application maîtresse ou un autre module pour déterminer le restant des données disponibles et utilisé les informations de vitesse en guidant ses demandes pour des données. Dans divers modes de réalisation, la demande de ressource cumulative peut être suivie dans le nœud d’accès ou le nœud terminal. Le mécanisme par lequel les applications déterminent l’attribution de ressources et les informations sur la limite de vitesse varie selon l’emplacement où les informations sont disponibles. Par ex., une application peut communiquer avec un agent d’application qui communique avec un module dans la pile de protocoles RAN qui enregistre l’utilisation de ressources et les limites de vitesse pour le nœud terminal et sa collection d’applications actives.

Les communications en coopération avec un agent APP peuvent être utilisées pour analyser la performance d’un réseau de communications. Les informations concernant la performance peuvent être recueillies à partir de communications en coopération avec un agent APP. Par ex., lorsqu’une application communique des informations concernant des arrêts vidéo, des arrêts audio ou de dépassement de mémoire tampon, les informations peuvent être utilisées pour analyser la performance du nœud terminal, d’une d’accès et d’autres zones du système de communication. L’application peut également communiquer le nombre et la durée des arrêts de lecture ou une chronologie de lecture, les temps de début et d’arrêt pour chaque session vidéo ou audio. L’application peut communiquer une estimation de la qualité de la lecture vidéo ou audio, par ex., sous forme d’un score MOS. En outre, l’application peut communiquer des paramètres de qualité de service au niveau du paquet, par ex., le délai et les distorsions de paquet, mesurés au niveau du nœud terminal. L’application peut également rapporter des actions au niveau utilisateur (humain) qui peuvent signaler une insatisfaction grave par rapport à la performance du réseau, par ex., un ou plusieurs navigateurs ou applications se réinitialisent, dupliquent les « clics » ou les « touches » sur le même lien ou la même commande, ou la fermeture par l’utilisateur d’une application à la suite d’une piètre qualité du réseau ou d’une piètre capacité de réaction de l’application. Les diverses informations peuvent être utilisées pour déterminer un niveau de congestion qui est acceptable pour les différentes applications ou les différentes combinaisons d’application. Les informations peuvent également être utilisées par l’opérateur pour déterminer le moment d’ajouter d’autres ressources au réseau.

Il est clair à partir de ces exemples que les communications en coopération avec un agent APP peuvent être utilisées pour plusieurs types d’informations différents, utilisées avec plusieurs types d’applications différents et utilisées pour améliorer plusieurs aspects différents d’un réseau de communication.

La FIG. 7 est un schéma d’un système de communication comportant des agents d’application et des applications conformément aux aspects de l’invention. Un nœud terminal 755 héberge une application 751. L’application 751 peut communiquer avec un serveur d’application 790 pour faciliter la fourniture de services à un utilisateur du nœud terminal 755. Divers éléments du système de communication peuvent être le même ou être semblables aux éléments nommés correspondant décrit ci-dessus.

Le nœud terminal 755 dans le système de communication illustré dans la FIG. 7 communique avec un nœud d’accès 775 sur une liaison radio 720. Le nœud d’accès 775 est connecté à un nœud de passerelle 795. Le nœud de passerelle 795 procure un accès à l’Internet via la connectivité à un nœud de routeur 793. Le nœud de routeur 793 procure un accès au serveur d’applications 790. Ainsi, l’application 751 peut communiquer avec le serveur d’applications 790 en utilisant le trajet de données de l’application 701 à travers le nœud d’accès 775, le nœud de passerelle 795 et le nœud de routeur 793. Le trajet de données de l’application 701 transporte des données utilisateurs de l’application (par ex., des données vidéo) et de donner de contrôle de l’application (par ex., des informations concernant les vidéos possibles disponibles et leurs formats). Le nœud d’accès 775 agit comme un pont pour les communications sur le trajet de données de l’application 701, le passant à travers le nœud terminal 755 et le prochain nœud dans le système de communication. L’application 751 communique également avec un agent d’application 770 au niveau du nœud d’accès 775 à l’aide d’un trajet de contrôle 703 de la communication en coopération avec un agent APP. Le trajet de contrôle 703 de la communication en coopération avec un agent APP est transmis sur une liaison radio 720. Les communications sur le trajet de contrôle 703 de la communication en coopération avec un agent APP entre l’application 751 et l’agent d’application 770 peuvent être utilisées, par ex., pour améliorer l’ordonnancement, le contrôle d’admission, l’efficacité et la capacité de réaction.

La FIG. 8 est un schéma d’un autre système de communication comportant des agents d’application et des applications conformément aux aspects de l’invention. Le système de communication de la FIG. 8 est semblable au système de communication de la FIG. 7 et comprend un nœud terminal 855, un nœud d’accès 875, un nœud de passerelle 895, un nœud de routeur 893 et un serveur d’application 890 qui correspond à des dispositifs aux noms semblables dans le système de communication FIG. 7. Le nœud terminal 855 communique avec un nœud d’accès 875 sur une liaison radio 820. Le nœud d’accès 875 est connecté au nœud de passerelle 895. Le nœud de passerelle 895 permet l’accès à l’Internet via la connectivité du nœud de routeur 893. Le nœud de routeur 893 permet un accès au serveur d’application 890.

Une application 851 dans le nœud terminal 855 peut communiquer avec le serveur d’application 890 en utilisant le trajet de données de l’application 801 à travers le nœud d’accès 875, le nœud de passerelle 895 et le nœud de routeur 893. L’application 851 communique également avec un agent d’application 870 en utilisant un trajet de contrôle 803 d’une communication en coopération avec un agent APP 803. Dans le système de communication de la FIG. 8, l’agent d’application 870 se situe dans le nœud de passerelle 895. Les informations provenant de l’agent d’application 870 peuvent être fourni au nœud d’accès 875. Les informations en coopération avec un agent APP peuvent être fournies, par ex., à un module de planification et de contrôle de ressources dans le nœud d’accès 875. Le nœud d’accès 875 peut utiliser des informations en coopération avec un agent APP, par ex., pour améliorer la planification, le contrôle d’admission, l’efficacité et la capacité de réaction.

Dans un autre mode de réalisation, un agent d’application peut être situé dans un nœud de routeur 893 ou dans un autre nœud de réseau. Les fonctions d’un agent d’application peuvent également être distribuées sur plusieurs dispositifs.

En outre, si un trajet de contrôle 803 d’une communication en coopération avec un agent APP se fait via un trajet IP, le trajet peut se faire à travers des nœuds de communication supplémentaires. Par ex., les communications en coopération peuvent être acheminées à travers le nœud de routeur 893. La localisation de l’agent d’application à l’extérieur du nœud d’accès 875 peut éliminer ou réduire les besoins d’inspection de paquet de lignes ascendantes au niveau du nœud d’accès 875. Un agent d’application situé à distance peut également réaliser une fonction pour de multiples nœuds d’accès.

La FIG. 9 est un schéma d’un module d’inspection de paquet conformément aux aspects de l’invention. Le module d’inspection de paquet 429 du nœud d’accès 475 de la FIG. 4 peut être, par ex., fourni par le module d’inspection de paquet de la FIG. 9. Le module d’inspection de paquet, dans un mode de réalisation, est compris dans le nœud terminal 455 de la FIG. 4 pour détecter et déterminer la disposition des messages DL de communication en coopération avec un agent APP. Le module d’inspection de paquet peut, par ex., déterminer qu’un message doit être ignoré ou qu’une application maîtresse ou une ou plusieurs des applications spécifiques doivent être envoyées à un message. Le module d’inspection de paquet peut être utilisé dans un trajet de données entre une pile de protocoles RAN et d’autres entités, telles que des serveurs d’applications, hébergés dans un réseau central ou sur l’Internet.

Les données de lignes ascendantes peuvent venir vers le module d’inspection de paquet à travers un premier trajet 921 (par ex., sur une liaison radio) et être transférées à partir du module d’inspection de paquet via un 2e trajet 922 (par ex., sur une connexion terrestre). Les données de ligne descendante peuvent venir vers le module d’inspection de paquet via un 2e trajet 922 et être transférées à partir du module d’inspection de paquet via le premier trajet 921.

Le module d’inspection de paquet comprend un module de surveillance du trafic 925 qui peut surveiller le trafic sur le premier trajet 921 et le deuxième trajet 922. Le module de surveillance du trafic 925 identifie des communications en coopération avec un agent APP provenant d’une application destinée pour un agent d’application. En particulier, le module de surveillance du trafic 925 peut surveiller le trafic de ligne ascendante sur le premier trajet 921 pour identifier des communications en coopération avec un agent APP. Les communications en coopération avec un agent APP peuvent être identifiées en utilisant, par ex., des adresses IP. Par ex., le module de surveillance du trafic 925 et le module de détection de communication en coopération 928 peuvent utiliser l’inspection de paquet pour identifier des communications en coopération avec un agent APP en détectant les paquets UL qui contiennent une source multicast ou broadcast ou une adresse de destination attribuée pour les communications en coopération avec un agent APP. Cette détection peut être utilisée avec des procédés multicast ou broadcast décrits ci-dessus.

Le module d’inspection de paquet, par ailleurs ou en outre, peut identifier des communications en coopération avec un agent APP à travers la détection d’une ou plusieurs sources TCP/UDP uniques ou nombres de port de destination qui ne sont pas utilisées par d’autre trafic ou qui sont spécifiquement attribués pour les communications en coopération avec un agent APP. Cette technique peut être appliquée à la fois aux communications en coopération avec un agent APP UL et DL. Un nombre de port simple unique peut être utilisé pour identifier la source ou la destination des communications en coopération entre une application spécifique unique est un agent d’application spécifique, un groupe d’applications spécifiques et un groupe d’agents d’application spécifique, et diverses combinaisons.

Dans un mode de réalisation, le module de surveillance du trafic 925 est fourni par un module d’inspection de paquet 529 dans le nœud d’accès 575 de la FIG. 5 est peut détecter des communications en coopération avec un agent APP UL en détectant l’utilisation d’un type de protocole datagramme d’IP unique (par ex., défini par le module les protocoles de transport et de connexion 550' dans le nœud terminal 555). Par ex., le type de protocole peut être défini à une valeur non-attribuée (par ex., un chiffre entre 143 et 252). Des procédés similaires peuvent être utilisés pour détecter des communications en coopération avec un agent APP DL.

Dans divers modes de réalisation, diverses combinaisons d’adresses IP, de port source, de port de destination et de type de protocole sont utilisées pour créer des collections uniques pour les communications en coopération avec un agent APP DL.

Le module de surveillance du trafic 925 peut également surveiller le trafic au niveau du module d’inspection de paquet à d’autres fins, et le module d’inspection de paquet peut comprendre un autre module logique 927 pour répondre aux autres objectifs. Le module d’inspection de paquet peut également détecter des informations concernant les applications associées avec le trafic sur le premier et le deuxième trajets. D’autres exemples d’inspection de paquet, de surveillance de trafic et de systèmes de communication centrés application peuvent être trouvés dans la demande de brevet américain no. 13/549 106, déposée le 13 juillet 2012 et intitulé « Systems and Methods for Détection for Prioritizing and Scheduling Packets in a Communication Network », la demande américaine provisoire no. 61/640 984, déposée le 1er mai 2012 et intitulé « Application Aware Admission Control » and la demande de brevet américain no. 13/644 650, déposée le 4 octobre 2012 et intitulé « Congestion Induced Video Scaling », qui sont incorporés ici à titre de référence. L’autre module logique 927 peut suivre les adresses IP, les numéros de port et les types de protocole, utilisé pour l’application du trafic de données. Par ex., dans le réseau de communication de la FIG. 5, l’autre module logique 927 peut suivre les adresses IP, les nombres de port et les types de protocole sur le trajet de données de l’application 501. L’autre module logique 927 peut détecter des conflits entre les adresses IP, les nombres de port et les types de protocole utilisés pour les communications en coopération avec un agent APP et les adresses IP, les nombres de port et les types de protocole utilisé pour l’application de trafic de données. Dans le cas où la combinaison des adresses IP, les nombres de port et les types de protocole utilisée par les communications en coopération avec un agent APP est la même que la combinaison utilisée pour l’application trafic de données, l’autre module logique 927 peut choisir une nouvelle combinaison non utilisée et communiquer cette nouvelle combinaison aux nœuds terminaux affectés. La nouvelle combinaison peut être choisie à partir d’une liste fournie par l’opérateur du réseau.

Le trafic de communication en coopération avec un agent APP est détourné vers un module de détection de communication en coopération 928. Le trafic de communication en coopération avec un agent APP peut être détourné par le module de surveillance du trafic 925. Le module de détection de communication en coopération 928 permet davantage de traitement du trafic de communication en coopération avec un agent APP. Un exemple d’un autre traitement est le transfert du trafic vers un agent d’application approprié. L’autre traitement peut également comprendre une absence de traitement, par ex., lorsque le module de détection de communication en coopération 928 détermine que le trafic transféré vers lui n’est pas destiné à un agent d’application associé au module d’inspection de paquet.

Le module d’inspection de paquet, tel qu’il est illustré dans la FIG. 9, peut comprendre un module d’état 926. Le module d’état 926 peut suivre les informations concernant les cas de connectivité entre les applications et les agents d’application. Les informations peuvent comprendre, par ex., l’état (par ex., connecté, déconnecté, actif, inactif), les attentes actuelles en matière de ressources et les données historiques (par ex., les ressources demandées versus les ressources utilisées).

Dans d’autres aspects, les systèmes, les procédés et les dispositifs sont décrits pour la gestion des applications spécifiques en coopération, aussi bien que d’autres applications spécifiques, qui fonctionnent dans l’équipement utilisateur pour augmenter la qualité de l’expérience des utilisateurs de telles applications. La FIG. 10 est un schéma d’un exemple d’environnement de réseau de communication comprenant un module de gestion de la qualité de l’expérience conformément aux aspects de l’invention. Dans la Figure 10, l’environnement du réseau de communication peut comprendre l’Internet 1000 dans lequel un ou plusieurs serveurs de contenu 1010 peuvent être fournis. Un tel serveur de contenu peut être un serveur de contenu tiers procurant des pages Internet, des photos, des vidéos, des fichiers, etc., aux utilisateurs finaux, ou peut être un serveur de contenus privés fournisseur de telles informations à un groupe limité d’utilisateurs finaux, par ex. par abonnement. L’environnement du réseau de communication peut également comprendre un module de gestion 1020 de la qualité de l’expérience (QoE) qui, dans l’exemple illustré dans la Figure 10, est compris dans une architecture de réseau qui comprend également une passerelle PDN (P-GW) 1030, une passerelle S-GW 1040, une entité de gestion de la mobilité (MME) 1060 et un ou plusieurs nœuds d’accès (AN) 1050. Chaque nœud d’accès (AN) 1050 peut communiquer avec un ou plusieurs nœuds terminaux (TN), tels que TN1 1071 et TN2 1072, via une liaison de communication entre le nœud d’accès et le nœud terminal, la liaison de communication peut être une liaison de communication sans fil ou une liaison de communication sur fil. Une liaison de communication sans fil peut fonctionner selon l’un quelconque d’un nombre de protocoles de communication sans fil connus tels que CDMA, OFDM, LTE, WiMAX, etc. De la même façon, une liaison de communication sur fil peut fonctionner selon l’un quelconque d’un nombre de procédés de communication sur fil connus tels que l’Ethernet, DOCSIS, DSL (ligne d’abonné numérique), FTTH (fibre à la maison), HFC (réseau hybride à fibre) etc.

Dans l’exemple de l’environnement de réseau de communication illustré dans la Figure 10, des applications spécifiques fonctionnant dans les TN 1071 et 1072 sont gérés pour maintenir ou améliorer la qualité de l’expérience pour les utilisateurs de telles applications.

Dans un exemple de configuration, une application maîtresse (non illustrée dans la Figure 10) fonctionne dans chacun des TN 1071 et 1072, l’application maîtresse fonctionne pour détecter et caractériser l’activité du flux en ligne descendante de l’application des flux de données en ligne descendante qui sont envoyées au TN et de caractériser l’état du nœud terminal actuel. L’application maîtresse détermine ensuite un paramètre d’importance de flux et un paramètre de qualité du flux pour chaque flux de données en ligne descendante détecté. Dans l’exemple de configuration de la Figure 10, l’application maîtresse envoie ensuite le paramètre d’importance du flux et le paramètre de qualité du flux pour chaque flux de données en ligne descendante détecté associé à ce nœud terminal via un nœud d’accès 1050 vers un module de gestion de la QoE basé sur un cloud 1020. Même si le module de gestion de la QoE 1020 est positionné dans la Figure 10 entre le P-GW 1030 et l’Internet 1000, il doit être compris que dans d’autres aspects le module de gestion de la QoE 1020 peut être positionnés à d’autres emplacements dans l’environnement du réseau de communication telle que, par ex., entre le S-GW 1040 et le nœud d’accès 1050. Dans un aspect, le module de gestion de la QoE 1020 peut être positionnés à un emplacement à l’intérieur de l’environnement du réseau de communication qui permet au module de gestion de la QoE 1020 de surveiller, d’accéder à, de copier et/ou d’intercepter le trafic de flux de données vers et/ou provenant des nœuds terminaux, tels que les TN 1071 et 1072, ayant des applications spécifiques qui sont gérées par le module de gestion de la QoE 1020. À cet égard, selon les aspects de l’invention, le module de gestion de la QoE 1020 peut gérer des flux de données en ligne descendante et/ou en ligne ascendante apparentés à des applications spécifiques gérées. En outre, la fonctionnalité décrite par rapport au module de gestion de la QoE 1020 peut être distribuée parmi plusieurs dispositifs dans l’environnement du réseau de communication tels que, par ex., entièrement à l’intérieur du P-GW 1030 ou distribué parmi l’un quelconque de P-GW 1030, S-GW 1040, le nœud d’accès 1050 et/ou d’autres dispositifs et modules.

Le module de gestion de la QoE 1020 reçoit via le nœud d’accès 1050 le paramètre d’importance du flux est le paramètre de qualité du flux pour chaque flux de données envie descendante détecté associé à chaque nœud terminal. De cette façon, le module de gestion de la QoE 1020 collecte cette information à partir de tous les nœuds terminaux, et cartographie chacun des nœuds terminaux à une cellule associée à chaque nœud terminal. Dans un aspect, le module de gestion de la QoE 1020 utilise ces informations recueillies pour déterminer un paramètre global de la qualité de la cellule pour chaque cellule est, si le paramètre de qualité globale de la cellule est inférieur à un seuil, le module de gestion de la QoE 1020 détermine une option d’atténuation pour un ou plusieurs flux de données associés à l’un ou plusieurs des nœuds terminaux basés sur le paramètre de l’importance du flux et du paramètre de la qualité du flux pour le flux de données respectif. L’option d’atténuation peut être une ou plusieurs options, telles que par ex., pour réduire ou stopper les paquets de données envoyées dans le flux de données, ou peut-être de ne prendre aucune action actuelle sur l’un quelconque des flux de données mais de continuer à surveiller la situation. Dans certains aspects, l’option d’atténuation peut être réalisée soit au niveau du module de gestion de la QoE 1020 (par ex., dépouillement du trafic, rejet de paquet et/ou délai) ou au niveau du nœud terminal associé au flux de données sur lequel l’option d’atténuation est appliquée (par ex., rejet de paquet et/ou délai), ou au niveau à la fois du module de gestion de la QoE 1020 et du nœud terminal. De cette façon, par ex., le module de gestion de la QoE 1020 peut tenter de maintenir ou d’augmenter la qualité de l’expérience pour les utilisateurs d’applications spécifiques associées aux nœuds terminaux avec un nœud d’accès donné (par ex., une cellule RAN). Dans des aspects, par ex., le module de gestion QoE 1020 peut tenter d’optimiser la qualité de l’expérience pour les flux de données détectés à travers tous les nœuds terminaux associés à un nœud d’accès donnés (par ex., une cellule RAN) ou pour les nœuds d’accès détectés associés à un nœud terminal donné.

La FIG. 11 est un schéma d’un exemple d’environnement de réseau de communication comprenant un module de gestion de la qualité de l’expérience conformément aux autres aspects de l’invention. Tel qu’il est mentionné ci-dessus, le module de gestion de la QoE 1020 illustré dans la Figure 10 peut être positionné à d’autres emplacements à l’intérieur d’un environnement d’un réseau de communication. Dans la Figure 11, le module de gestion de la QoE 1120 peut, par ex., être fourni dans l’Internet 1100 dans lequel un ou plusieurs serveurs de contenu 1110 sont situés. D’autres nœuds de réseau, tels que la passerelle PDN (P-GW) 1130, la passerelle S-GW 1140, l’entité de gestion de la mobilité (MME) 1160 et un ou plusieurs nœuds d’accès (AN) 1150 sont fournis dans une infrastructure mobile 1190 qui est en communication avec l’Internet 1100. Chaque nœud d’accès (AN) 1150 peut communiquer avec un ou plusieurs nœuds terminaux (TN), tels que TN1 1171 et TN2 1172, via une liaison de communication entre le nœud d’accès et le nœud terminal, la liaison de communication peut être une liaison de communication sans fil ou une liaison de communication sur fil tel qu’il est décrit ci-dessus par rapport à la Figure 10. Le module de gestion de la QoE 1120 de la Figure 11 peut fonctionner de façon similaire à celle décrite ci-dessus pour la Figure 10, mais il ne fait pas partie de l’infrastructure mobile qui comprend le P-GW 1130, le S-GW 1140, le MME 1160 et le ou les nœuds d’accès 1150.

Comme il est mentionné ci-dessus, un module d’application maîtresse peut fonctionner dans chaque nœud terminal dans l’environnement de communication. Dans un aspect, le module d’application maîtresse peut être localisé au niveau du nœud terminal entre la pile TCP/IP et les applications spécifiques, et peut être utilisé pour surveiller et gérer les flux de données d’application apparentés aux applications spécifiques. Dans un aspect, le module d’application maîtresse peut être mis en œuvre dans une couche distincte entre les systèmes d’exploitation et les applications spécifiques, ou peut être mis en œuvre comme une partie d’un système d’exploitation.

Un flux de données d’application peut être un flux de données de communication de/vers un nœud terminal en support à une application spécifique fonctionnant dans ce nœud terminal. Par ex., un flux de données d’application peut être un flux de paquets de données vidéo provenant d’un serveur de contenu vers un nœud terminal via un nœud d’accès, le flux de données d’application étant un support d’une application vidéo fonctionnant dans le nœud terminal. Dans des aspects, plusieurs flux de données d’application peuvent être associés à un cas unique d’une application spécifique fonctionnant dans le nœud terminal. Les applications spécifiques fonctionnant dans le nœud terminal peuvent être des applications spécifiques en coopération qui communiquent et coordonnent avec le module d’application maîtresse, ou peuvent être des applications spécifiques qui ne sont pas en coopération et qui ne communiquent ou ne coordonnent pas avec le module d’application maîtresse. Dans un exemple d’aspect, le module d’application maîtresse dans le nœud terminal peut surveiller et/ou accéder à des paquets TCP à un point entre les piles TCP et HTTP dans lequel les paquets TCP sont des paquets de données qui supportent une application spécifique fonctionnant dans le nœud terminal. Le module d’application maîtresse dans le nœud terminal peut également interfacer avec des applications spécifiques en coopération qui fonctionnent dans la couche d’application du nœud terminal afin d’y obtenir des informations à partir des applications spécifiques et pour envoyer des instructions et/ou des données aux applications spécifiques. A cet égard, certaines ou toutes les fonctions du module d’application maîtresse décrites ici peuvent éventuellement être localisées dans certaines ou toutes les applications spécifiques en coopération fonctionnant dans le nœud terminal.

La FIG. 12 est un schéma d’un module d’application maîtresse dans un nœud terminal qui supporte la gestion de la qualité de l’expérience conformément aux aspects de l’invention. Dans la Figure 12, un exemple de mode de réalisation du module d’application maîtresse 1200 contient plusieurs modules qui sont en communication les uns avec les autres pour partager des données, des informations et/ou des instructions et des commandes. Dans un aspect, l’exemple de mode de réalisation du module d’application maîtresse 1200 contient plusieurs modules comprenant, sans limitation, le module d’interface du nœud terminal (TN) 1210, le module d’évaluation des caractéristiques 1220, un module de détermination du paramètre du flux 1230, d’autres logiques 1240, un module de classification et de détection de flux 1250, un module de communication du gestionnaire de QoE 1260, un module des réponse à la QoE 1270 et un module d’interface de trafic 1280.

Dans un exemple d’aspect, le module d’interface du nœud terminal 1210 interface avec la couche d’application du nœud terminal pour communiquer avec des applications spécifiques en coopération fonctionnant dans le nœud terminal et pour déterminer les caractéristiques et les paramètres de l’application actuelle qui sont utilisés pour calculer la qualité du flux de données pour chaque flux de données détecté qui est associé à une application spécifique. Le module d’interface du nœud terminal 1210 peut également interfacer avec une interface de réseau du nœud terminal, tel que la pile LTE Uu d’un système à base de LTE par ex., pour obtenir une qualité de service (QoS) et des informations d’identification de cellule (ID) (par ex., QCI et CellID) pour les flux du flux de données de l’application détectée. Par ex., de telles informations peuvent être obtenues pour chaque flux de données d’application détecté, au pour chaque groupe de flux détectés. À cet égard, l’exécution de ces fonctions peut ne pas être nécessairement appliquée à tous les flux de données, mais plutôt être appliquée à chacun d’un sous-ensemble (certains ou tous) des flux de données. Le module d’interface du nœud terminal 1210 peut également interfacer avec d’autres services du nœud terminal pour obtenir les caractéristiques du nœud terminal et d’autres caractéristiques d’application, par ex., la détermination à partir du système d’exploitation des applications spécifiques qui sont affichées sur l’écran. Dans un aspect, le module d’interface du nœud terminal 1210 peut également être utilisé pour mettre en œuvre des actions d’atténuation, comme il est discuté plus en détail ci-dessous. Dans un exemple d’aspect, le module de détection et de classification de flux 1250 fonctionne pour recevoir des paquets de données provenant du module d’interface d’un nœud terminal 1210 est pour les inspecter afin de déterminer s’ils appartiennent au flux de données qui est associé à une application spécifique fonctionnant dans le nœud terminal. Par ex., le module de détection et de classification de flux 1250 peut inspecter les paquets de données pour détecter l’initiation et la terminaison des connexions de données, telles que par ex., l’établissement d’une connexion TCP/IP et des flux de données, tels que par ex., le trafic de données s’écoulant à travers une connexion nouvellement établie. Dans un aspect, le module de détection et de classification de flux 1250 associe l’un ou plusieurs des flux de données identifiés à des applications spécifiques correspondantes fonctionnant dans le nœud terminal. Par ex., le module de détection et de classification de flux 1250 peut associer trois flux de données HTTP identifiés chacun étant porté sur des connexions TCP/IP uniques avec une application spécifique unique qui fonctionne sur le nœud terminal. En se basant sur l’inspection des paquets de données, le module de détection et de classification de flux 1250 peut classifier un ou plusieurs des flux de données identifiés dans une classe d’application et/ou une application spécifique. Par ex., le module de détection et de classification de flux 1250 peut classer un flux de données dans une classe vidéo parce que les paquets de données du flux de données comportent des données vidéo, et le module de détection et de classification de flux 1250 peut également placer le flux de données dans une application spécifique, tels que NetFix ce par ex., basées sur les caractéristiques particulières du flux de données. Un spécialiste du domaine sera au courant des techniques et procédés existants permettant de classer des flux de données, et en particulier pour déterminer une telle classification basée sur l’inspection d’un ou de plusieurs paquets de données dans le flux de données.

Dans un aspect, le module de détection et de classification de flux 1250 peut exécuter les fonctions susmentionnées en utilisant une signalisation d’application provenant d’une application spécifique en coopération qui fonctionne dans le nœud terminal. Par ex., une application spécifique en coopération qui fonctionne dans le nœud terminal peut envoyer une indication aux modules de détection et de classification de flux 1250 comme quoi l’application spécifique en coopération initie un nouveau flux de données, et l’indication peut également comprendre des informations concernant le nouveau flux de données telles que, par ex., la classe d’application et l’application spécifique associée au nouveau flux de données. Dans un aspect, le module de détection et de classification de flux 1250 peut utiliser l’inspection des paquets de données pour déterminer les informations de connexion, tels que par ex., des informations de prise, apparentées au nouveau flux de données.

Le module de détection et de classification de flux 1250 peut utiliser des techniques d’inspection et de classification de paquets de données connues. Dans un aspect, le module de détection et de classification de flux 1250 peut utiliser des techniques d’inspection et de classification de paquets de données décrites dans la publication de la demande de brevet américain no. 2012/0327779A1, intitulé « Systems And Methods For Congestion Détection For Use In Prioritizing And Scheduling Packets In A Communication Network », qui est incorporée ici à titre de référence. Par ex., les techniques d’inspection et de classification décrites par rapport aux modules de Classification/files d’attente décrites dans les Figures 4A-4C, et au moins dans les paragraphes [0056], [0057], [0060], [0061] et [0077] à [0091], entre autres, dans la publication de la demande de brevet américain no. 2012/0327779A1 peuvent être mises en œuvre dans les aspects et les modes de réalisation décrits ici. Dans un aspect, le module de détection et de classification de flux 1250 peut également procurer des informations et/ou des paramètres du flux de données aux modules d’évaluation des caractéristiques 1220, telles que par ex. HTTP, TCP et/ou information d’en-tête IP et métadonnées de fichiers, ou vers le module de détermination du paramètre de flux 1230, telles que, par ex., les compteurs de bit et des informations concernant l’arrivée des paquets qui peuvent être utilisés pour calculer la vitesse de bit fournie.

Dans un aspect, le module d’évaluation des caractéristiques 1220 peut déterminer un ensemble actuel de caractéristiques d’application pour chaque application spécifique qui est associée à un ou plusieurs flux de données détectés. Par ex., un ensemble de données des caractéristiques d’une application actuelle peut comprendre un type d’initiation qui indique si l’application spécifique associée a été initiée par un utilisateur du nœud terminal dans lequel l’application spécifique fonctionne aussi l’application spécifique associée a été initiée par le nœud terminal lui-même en absence d’initiation de la part de l’utilisateur. L’ensemble de données des caractéristiques de l’application actuelle peut également comprendre une indication concernant le fait que l’application spécifique est actuellement à l’avant ou à l’arrière de l’écran du nœud terminal associé, et peut également comprendre le fait que l’application spécifique est en attente d’une réponse de la part d’une autre entité telle qu’un serveur de contenu ou de la part de l’utilisateur du nœud terminal. Dans un aspect, le module d’évaluation des caractéristiques 1220 peut accéder au système d’exploitation du nœud terminal associé afin d’obtenir des informations à partir desquelles il peut déterminer quelques-uns ou tous les ensembles de données des caractéristiques de l’application actuelle pour une application spécifique. Dans un autre aspect, le module d’évaluation des caractéristiques 1220 peut recevoir des informations et/ou des paramètres de flux de données à partir du module de détection de classification de flux 1250 et utiliser ces informations et/ou ces paramètres dans la détermination de quelques-uns ou de tous les ensembles de données des caractéristiques d’une application actuelle pour une application spécifique. Dans un aspect, le module d’évaluation des caractéristiques 1220 peut recevoir des informations d’application directement, ou indirectement, à partir d’une application spécifique en coopération qui fonctionne dans le nœud terminal est ensuite utilisée ces informations dans la détermination de quelques-uns ou de tous les ensembles de données des caractéristiques de l’application actuelle pour cette application spécifique.

Dans un aspect, l’ensemble de données des caractéristiques de l’application actuelle déterminé par le module d’évaluation des caractéristiques 1220 peut comprendre un ou plusieurs de ce qui suit :

Paramètre de classe d’application :

Exemple de valeurs : Voix de conversation, vidéos de conversation, lecture audio en continu, lecture vidéo en continu, jeux en ligne interactif, données de navigateur, données d’application natives et inconnues Détermination : Techniques d’inspection de paquet en bande (décrites ci-dessus) peuvent être appliquées aux paquets de données surveillés par le module d’interface de trafic 1280 Paramètre d’initiation de flux :

Exemple de valeurs : Initiée par l’utilisateur et initiation automatique Détermination : Le paramètre du type d’initiation du flux peut être reçu à partir d’une application spécifique en coopération associée. Dans un autre aspect, ceci peut être déduit à partir d’une classe d’application associée déterminée avec un flux de données (par ex., on peut assumer qu’une application spécifique avec un flux vidéo à lecture en continu unique peut être initiée par l’utilisateur). Il doit être noté que l’initiation d’un flux de données peut être identique ou non à l’initiation de l’application spécifique correspondante. Par ex., une application spécifique initiée par un utilisateur peut avoir un « enfoncer-mettre à jour » qui est initié par l’utilisateur et qui possède également un rapport d’utilisation qui est automatiquement initiée (distincte de l’initiation de l’application spécifique).

Paramètre de mise à jour de l’interface utilisateur (UI) en attente :

Exemple de valeurs : En attente, pas en attente, sans objet Détermination : Ceci se rapporte au fait que le flux de données et ou non actuellement associé avec une mise à jour UI en attente, tel qu’une actualisation de l’écran. L’indication de la mise à jour UI en attente peut être reçue à partir de l’application spécifique associée en coopération, telle que par ex., un navigateur Internet ou une application native. Ceci peut également être analysé à partir des paquets de données dans le flux de données de l’application. Il est à noter que cette indication peut ne pas être applicable à toutes les classes d’application, telles que, par ex., la voie de conversation.

Paramètres de position de l’écran :

Exemple de valeurs : En avant, en arrière Détermination : Ce paramètre se rapporte au fait que l’application spécifique associée aux flux de données de l’application est affichée sur le nœud terminal en avant ou en arrière de l’UI. La position de l’écran peut être reçue à partir de l’application spécifique associée en coopération. Mais également, une indication de la position de l’écran peut être obtenue du système d’exploitation dans le nœud terminal.

Paramètre de qualité de service (QoS) du réseau :

Exemple de valeurs : QCI =1-9 Détermination : Ce paramètre peut être obtenu à partir de la pile de réseau dans le nœud terminal, (par ex., la pile Uu de LTE), à travers le module d’interface du nœud terminal 1210. Il est à noter que des alternatives à la QoS peuvent être utilisé telles que, sans limitation, la classe de service (CoS) telle qu’une classe de vitesse de bit garantie (GBR) ou une classe de vitesse de bit non garantie (non-GBR).

Paramètres de marge de la mémoire tampon :

Exemple de valeurs : 0 = inconnue, valeur 1-15 (8 = neutre). Détermination : Le paramètre de la marge de la mémoire tampon se rapporte à la marge de l’occupation de la mémoire tampon (BO) pour les services de lecture en continu de données. Ce paramètre peut être obtenu à partir de l’application spécifique associée en coopération. Dans le cas de la lecture vidéo en continu, le paramètre peut être déterminé en utilisant une estimation de la BO. Par ex., une estimation de BO peut être obtenue en utilisant les procédés et les techniques décrites dans la demande de brevet américain no. 13/789 462, intitulé « Systems And Methods For Using Client-Side Video Buffer Occupancy For Enhanced Quality Of Expérience In A Communication Network », qui est incorporée ici à titre de référence. Une estimation de BO d’une lecture en continu audio peut être obtenue avec des techniques semblables.

Dans un exemple d’aspect, le module d’évaluation des caractéristiques 1200 peut également déterminer un ensemble de données des caractéristiques du nœud terminal pour le nœud terminal, qui peut comprendre des données de caractéristiques actuelles apparentées à l’état du nœud terminal. L’ensemble de données des caractéristiques du nœud terminal peut comprendre, sans limitation, un paramètre d’attention de l’utilisateur qui indique le niveau d’attention que l’utilisateur donne au nœud terminal associé, un contrat de niveau de service utilisateur (SLA) qui indique que le SLA attribué à l’utilisateur du nœud terminal et un paramètre de type nœud terminal indiquant le type de nœud terminal qui est utilisé (par ex., tablette, téléphone intelligent, téléphone numérique, une télé à grand écran, un module M2M industriel, etc.). Dans un aspect, le module d’évaluation des caractéristiques 1220 peut évaluer le système d’exploitation du nœud terminal associé afin d’obtenir des informations à partir desquelles il peut déterminer quelques-uns ou toutes les données des caractéristiques du nœud terminal actuel. Par ex., le module d’évaluation des caractéristiques 1220 peut obtenir des données historiques provenant du système d’exploitation apparentées au type d’entrée utilisateur reçue, et le moment de l’entrée utilisateur reçue, par l’interface utilisateur graphique du nœud terminal qui est apparenté à une application spécifique et ensuite utiliser ces informations pour déterminer un paramètre d’attention de l’utilisateur associé à l’application spécifique. D’autres informations provenant du système d’exploitation peuvent également aider à déterminer le paramètre d’attention de l’utilisateur comprenant, par ex., une indication de la position ou du mouvement du téléphone, une indication si l’écran du nœud terminal s’est éteint ou a été interrompu, une indication du suivi des yeux de l’utilisateur du dispositif à partir d’une caméra ou d’un autre capteur au niveau du nœud terminal. Il doit être compris que d’autres types connus d’informations et de données provenant du système d’exploitation et/ou du nœud terminal peuvent être utilisées dans la détermination de quelques-unes ou de toutes les caractéristiques de l’ensemble de données du nœud terminal actuel.

Dans un aspect, l’ensemble de données des caractéristiques du nœud terminal actuel déterminé par le module d’évaluation des caractéristiques 1220 peut comprendre un ou plusieurs de ce qui suit :

Paramètre d’attention de l’utilisateur (UA) :

Exemple de valeurs : Assisté, non assisté, sans objet, inconnu

Détermination : Dans un aspect, il est à noter que la valeur « sans objet » du paramètre UA peut être utilisée pour des applications spécifiques non assistées, telles que la surveillance vidéo ou d’autres applications machine-to-machine (M2M). En outre, le paramètre UA pourrait également être une caractéristique application, plutôt qu’une caractéristique du nœud terminal, pour les dispositifs du nœud terminal qui peuvent, simultanément, afficher des informations pour les multiples applications spécifiques telles que des téléphones intelligents à grand écran et des tablettes.

Comme il est présenté ci-dessus, les informations apparentées à l’attention de l’utilisateur peuvent être obtenues du système d’exploitation du nœud terminal et/de divers types de capteurs dans le nœud terminal tel qu’un accéléromètre, une caméra, etc. Par ex., les informations concernant le suivi du regard (suivi des yeux) peuvent être obtenues à partir d’une caméra faisant face à l’avant pour évaluer si un utilisateur est présent et s’il porte son attention et pour indiquer l’objet de l’attention sur l’écran du nœud terminal. Voir, par ex., E. Miluzzo, T. Wang, and A. Campbell, “Eyephone: Activating Mobile Phones with Your Eyes,” Proc. 2nd ACM SIGCOMM Workshop on Networking, Systems, and Applications on Mobile Handhelds (MobiHeld 10), ACM Press, 2010, pp. 15-20. Les données de l’accéléromètre peuvent être utilisées pour déterminer l’orientation du nœud terminal, par ex., si le nœud terminal fait face vers le haut ou s’il est à l’envers. Voir, par ex., http://stackoverflow.com/questions/7590996/detecting-the-device-upside-down. La détection dans-la-poche ou dans-le-sac peut être déterminée selon des informations provenant de capteurs dans le nœud terminal. Voir, par ex., http://www.cs.dartmouth.edu/~campbell/papers/miluzzo-phonesense.pdf. De la même façon, la détection téléphone-dans-la-main peut être déterminée selon des informations provenant de capteurs dans le nœud terminal. Voir, par ex., http://www.cs.dartmouth.edu/~campbell/papers/miluzzo-phonesense.pdf. Un minuteur « dernier interaction de l’utilisateur » peut être utilisé en fonction des informations provenant du système d’exploitation ou directement provenant d’une application spécifique associée pour déterminer si une application interactive en fonctionnement est « périmée » (non assisté par l’utilisateur). Les informations sur le mode économiseur d’écran ou le mode écran éteint peuvent être obtenu du système d’exploitation dans le nœud terminal pour indiquer un état non assisté du nœud terminal.

Il doit être noté que l’un ou plusieurs des procédés et des techniques susmentionnés peuvent être utilisées en combinaison, telle qu’une combinaison logique, par ex., pour déterminer une valeur UA. En outre, la combinaison logique peut également utiliser la valeur de confiance (ou intervalle) rapportée par chaque procédé pour mieux définir la valeur du paramètre UA.

Paramètre du contrat de niveau de service réseau (SLA) :

Exemple de valeurs : Or, argent, bronze Détermination : Le SLA attribué à ce nœud terminal peut être demandé à partir d’une pile de réseaux, tels que par ex. la pile Uu de LTE et le réseau LTE. Par ex., un contrat de service peut être attribué au SLA pour le nœud terminal, qui est attribué au nœud terminal/utilisateur par l’opérateur du réseau.

Dans un exemple d’aspect, le module de détermination du paramètre du flux 1230 utilise l’ensemble de données des caractéristiques de l’application actuelle et l’ensemble de données les caractéristiques du nœud terminal actuel provenant du module d’évaluation des caractéristiques 1220, et d’autres informations, pour déterminer un ou plusieurs paramètres associés à chaque flux de données. Dans un aspect, le module de détermination du paramètre de flux 1230 détermine les paramètres du flux de données qui comprennent au moins un paramètre de l’importance du flux de données est un paramètre de la qualité du flux de données associés à chaque flux de données détecté. Dans un exemple d’aspect, le module de détermination du paramètre de flux 1230 détermine un paramètre de l’importance du flux de données pour un flux de données correspondants selon : SIS(x,y,z) = f{AppCharacteristics(x,y,z), TerminalNodeCharacteristics(x,y,z')} dans laquelle f{ } peut être une somme pondérée des données des caractéristiques de l’application actuelle et des données des caractéristiques du nœud terminal actuel, telles que :

SlS(x, y.z) = (CjAC + c2SI + c3UUP + c+DP + c5QOS+c6BM + c7UA + csSLA)

OU SIS(x, y,z) = (c5QOS) * (cgSLA) * (ctAC + c2SI + c3UUP + c4DP + c6BM + c7UÀ) ou

Sis(x, y.z) = (csQOS) * (c85U4) « (c6BM) * (cp4C+ c2SI+ c3UUP+c4DP + c7UA) dans laquelle x = appID, y = streamID, z = terminalnodelD, et ci..cg sont des coefficients pondérés utilisés pour augmenter/diminuer l’importance relative de chaque caractéristique associée, y compris l’utilisation d’un poids de zéro qui élimine l’effet de la caractéristique associée. Les caractéristiques de l’application et des caractéristiques du nœud terminal sont chacune une fonction de x,y,x, même s’il n’est pas illustré pour faciliter la présentation. Un spécialiste du domaine comprendra que les variables décrites dans les fonctions susmentionnées peuvent être exprimées sous forme d’un chiffre qui peut être utilisé dans le calcul. Les fonctions subventionnées sont des exemples et peuvent être exprimées dans d’autres formats et termes, et peuvent comprendre d’autres paramètres et/ou variables additionnelles, ou moins de paramètres et/ou variables. Dans un aspect, le module de détermination du paramètre de flux 1230 peut déterminer un paramètre de l’importance du flux de données pour un flux de données basées au moins en partie sur la tolérance au délai du flux de données. Dans un aspect, une telle tolérance au délai peut être indiquée par, ou dérivée de, la classe d’application du flux de données.

Dans un exemple d’aspect, le module de détermination du paramètre de flux 1230 détermine un paramètre de qualité du flux de données pour un flux de données correspondant sous forme d’une estimation normalisée, en temps réel de l’expérience utilisateur associée à l’application spécifique correspondant aux flux de données. A cet égard, les procédés et les techniques connus pour la détermination du paramètre de l’expérience utilisateur peuvent être utilisés, tels que l’estimation VMOS et les exemples donnés ci-dessous, avec d’autres techniques connues. Voir par ex., « OTT vs OTT: Comparing Video Chat Expérience », Spirent Communications, 2013, qui est incorporée ici à titre de référence. Dans un aspect, le module de détermination du paramètre de flux 1230 peut déterminer un paramètre de la qualité du flux de données de façon différente pour des flux de données différents en fonction de la classe d’application, et éventuellement, même l’application spécifique, associée à chaque flux de données. Dans un aspect, le module de détermination du paramètre de flux 1230 peut déterminer un paramètre de la qualité du flux de données pour un flux de données en utilisant un calcul basé sur les informations de la qualité du transport de données apparentées au flux de données, tels que des délais de paquets de données, des rejets, des retransmissions etc. Dans un autre aspect, le module de détermination du paramètre de flux 1230 peut déterminer un paramètre de la qualité du flux de données pour un flux de données basé sur un paramètre provenant d’une application spécifique opération, tel qu’une estimation du score VMOS, provenant d’une application de lecture vidéo en continu en coopération. Dans un autre aspect, le module de détermination du paramètre de flux 1230 peut déterminer un paramètre de la qualité du flux de données pour un flux de données basé sur une combinaison de ou des paramètres provenant d’une application spécifique correspondante en coopération. Par ex., une application vidéo en coopération peut procurer une vitesse de bit de la vidéo cible est ensuite le module de détermination du paramètre de flux 1230 peut comparer cette vitesse de bit cible à une valeur de vitesse de bit fournie (ou estimée) afin de déterminer un paramètre de la qualité du flux de données pour le flux de données associé. Dans un autre aspect, le module de détermination du paramètre de flux 1230 peut déterminer un paramètre de la qualité du flux de données pour un flux de données en incluant des informations de paramètre provenant d’autres nœuds du réseau, comprenant, par ex., des informations fournies par un agent d’application dans un nœud d’accès, comme il est décrit ci-dessus par rapport aux Figures 1 à 9.

Comme il est mentionné ci-dessus, le module de détermination du paramètre de flux 1230 peut déterminer un paramètre de la qualité du flux de données de façon différente pour des flux de données différents dépendamment de la classe d’application. Des exemples de différentes techniques de détermination du paramètre de la qualité, et des informations qui peuvent être utilisées, pour différentes classes d’application sont donnés ci-dessous :

Classe d’application : Voix de conversation

Technique(s) de mesure de la qualité : module de détermination du paramètre de flux 1230 peut obtenir et utiliser un ou plusieurs : d’une valeur de distorsion de paquet, un pourcentage de la valeur des retransmissions TCP, la valeur du temps d’un aller-retour d’un paquet et la vitesse de bit fourni versus ne paramètre de vitesse de bit cible (pondérée sur une période de temps). Par ex., ces informations peuvent être obtenues et/ou dérivées à l’aide du module de détection et de classification de flux 1250 et du module d’interface de trafic 1280.

Le paramètre obtenu à partir d’une application spécifique en coopération : une estimation du score MOS, un pourcentage du temps de la valeur des données manquantes et un pourcentage de temps, le nombre d’occurrences et/ou de durée pour une valeur de gel de l’application (c.-à-d., les périodes de temps pendant lesquelles la conversation chute ou elle est déformée), et une vitesse de bit cible.

Remarque : L’utilisation susmentionnée de la valeur de distorsion du paquet assume l’utilisation d’une transmission de paquets à période fixe. Mais également, des techniques connues peuvent être utilisées pour calculer une estimation MOS pour une voix de conversation basée sur des informations au niveau du paquet (par ex., IP, UDP, TCP, HTTP, SIP) provenant du module de détection et de classification de flux 1250.

Classe d’application : Conversation vidéo (peut comprendre voix de conversation) Technique(s) de mesure de la qualité : module de détermination du paramètre de flux 1230 peut obtenir et utiliser un ou plusieurs : d’une valeur de distorsion de paquet, un pourcentage de la valeur des retransmissions de paquet, la valeur du temps d’un aller-retour d’un paquet et la vitesse de bit fournie versus ne paramètre de vitesse de bit cible (pondérée sur une période de temps). Par ex., ces informations peuvent être obtenues et/ou dérivées à l’aide du module de détection et de classification de flux 1250 et du module d’interface de trafic 1280.

Le paramètre obtenu à partir d’une application spécifique en coopération : une estimation du score VMOS, un pourcentage du temps de la valeur et de la quantité des données manquantes et un pourcentage de temps ou de la quantité, le nombre d’occurrences et/ou de durée pour une valeur de gel de l’application (c.-à-d., les périodes de temps pendant lesquelles la conversation et/ou la vidéo gel, chute ou elle est déformée), et une vitesse de bit cible.

Remarque : La partie audio de cette classe d’application peut être portée sur un flux de données distinct ou non.

Classe d’application : Lecture audio en continu

Technique(s) de mesure de la qualité : module de détermination du paramètre de flux 1230 peut obtenir et utiliser un ou plusieurs : d’une vitesse de bit fournie versus une valeur de vitesse de bit cible, et une estimation de la valeur BO. Par ex., cette information peut être obtenue et/ou dérivée à l’aide d’un module de détection et de classification de flux mais 1250 est un module d’interface de trafic 1280. La valeur de l’estimation de la BO peut être déterminée par les procédés d’estimation de la BO semblable à ce mentionné ci-dessus par rapport à la classe de vidéos en lecture continue. Dans un aspect, l’estimation de la BO peut être basée sur une comparaison relative entre un temps actuel et un horodatage de présentation.

Le paramètre obtenu à partir d’une application spécifique en coopération : une estimation du score MOS, un pourcentage de temps de valeur de données manquantes et un pourcentage de temps ou de quantité d’occurrences ou de durée d’une valeur de gel de l’application, et une vitesse de bit cible.

Classe d’application : Vidéo en lecture continue

Technique(s) de mesure de la qualité : module de détermination du paramètre de flux 1230 peut obtenir et utiliser un ou plusieurs : procédé de détermination du paramètre de la qualité de vidéo en bande, comme par ex., les procédés et les techniques de paramètre de qualité décrits dans « Objective perceptual multimedia video quality measurement in the presence of a full reference » ITU Standard J.247, incorporé ici à titre de référence, (ci-après appelé « modèle Psytechnics »). Dans un autre aspect, le procédé de détermination du paramètre de la qualité vidéo en bande peut être basé sur la technique d’estimation de la BO, comme il est décrit ci-dessus. Un paramètre de qualité peut également être déterminé pour le flux vidéo d’une présentation vidéo en lecture continue.

Le paramètre obtenu à partir d’une application spécifique en coopération : une estimation du score VMOS, un pourcentage de temps de valeur de données manquantes et un pourcentage de temps ou de quantité d’occurrences ou de durée d’une valeur de gel de l’application, et une vitesse de bit cible. En outre, l’application spécifique en coopération peut fournir un paramètre de qualité pour le flux audio qui est associé à la présentation de vidéos en lecture continue.

Classe d’application : Jeux en ligne interactif

Technique(s) de mesure de la qualité : module de détermination du paramètre de flux 1230 peut obtenir et utiliser un ou plusieurs : un pourcentage de la valeur des retransmissions de paquet, la valeur du temps d’un aller-retour d’un paquet (par ex., SRTT), et le temps entre une demande HTTP et une première valeur de réponse HTTP. Par ex., ces informations peuvent être obtenues et/ou dérivées à l’aide du module de détection et de classification de flux 1250 et du module d’interface de trafic 1280.

Le paramètre obtenu à partir d’une application spécifique en coopération : une valeur de latence d’un aller-retour commande-réponse Classe d’application : Données de navigateur

Technique(s) de mesure de la qualité : module de détermination du paramètre de flux 1230 peut obtenir et utiliser un ou plusieurs : un temps entre une demande HTTP et une première valeur de réponse HTTP, et une valeur moyenne fournie de vitesse de bit. Par ex., ces informations peuvent être obtenues et/ou dérivées à l’aide du module de détection et de classification de flux 1250 et du module d’interface de trafic 1280.

Le paramètre obtenu à partir d’une application spécifique en coopération : un temps entre une demande utilisateur (ou automatique) et une valeur d’actualisation de l’écran qui peut être normalisée selon la taille de la demande (par ex., secondes par mégabit).

Classe d’application : Données d’applications natives

Classe d’application : Inconnu

Le paramètre obtenu à partir d’une application spécifique en coopération : sans objet pour une classe inconnue.

Dans un exemple d’aspect, le module de communication du gestionnaire de la QoE 1260 peut fonctionner pour générer un message de mise à jour du nœud terminal pour être envoyer au module du gestionnaire QoE dans le réseau, tel qu’un module du gestionnaire de la QoE 1020 de la Figure 10. Dans un aspect, le module de communication du gestionnaire de la QoE 1260 peut générer un message de mise à jour du nœud terminal qui comprend au moins un ou plusieurs des paramètres de l’importance du flux de données et un paramètre de la qualité du flux de données associé à chaque flux de données, et une identification du nœud terminal et une identification du nœud d’accès associé, et d’autres informations apparentées au nœud terminal et au nœud d’accès associé. Dans un aspect, le module de communication du gestionnaire de la QoE 1260 peut recevoir un message d’instruction d’atténuation provenant d’un module de gestionnaire de la QoE et peut aider à l’implémentation d’une instruction d’atténuation contenue dans le message d’instruction d’atténuation.

Dans un aspect, le message de mise à jour du nœud terminal préparé par le module de communication du gestionnaire de la QoE 1260 peut être envoyé pour les flux de données qui sont à l’intérieur d’un sous-ensemble d’une classe de service (CoS) ou d’une qualité de service (QoS) donnée. Par exemple, : le module de communication du gestionnaire de la QoE 1260 peut seulement préparer et envoyer des messages de mise à jour d’un nœud terminal pour les flux de données qui se trouvent dans les critères suivants : LTE QCI=6-9, Non-GBR, flux de meilleur effort. Cet exemple assume que d’autres systèmes d’attribution de ressources seront responsables pour l’assurance qualité des flux d’importance plus élevée, tels que par ex., un planificateur eNB Layer2 qui gérera convenablement les flux GBR.

Dans un aspect, le message de mise à jour d’un nœud terminal préparé par le module de communication du gestionnaire de la QoE 1260 peut être envoyé que quand il est déclenché. Les options pour un tel déclenchement sont : Périodiquement ; lors de la réception d’une demande provenant du module de gestionnaire de la QoE (tel que le module de gestionnaire de la QoE 1020 de la Figure 10) ; basée sur une mise à jour ou un changement dans l’état du flux de données ou dans les caractéristiques du flux de données ; et basée sur un relais vers un nouveau nœud d’accès de desserte. Dans un aspect, le module de communication du gestionnaire de la QoE 1260 peut envoyer le message de mise à jour du nœud terminal en utilisant un module d’interface de trafic 1280 pour insérer le message de mise à jour du nœud terminal dans le flux de trafic sortant du nœud terminal pour qu’il soit envoyé au nœud d’accès pour un transfert vers le module de gestionnaire de la QoE (tel que le module de gestionnaire de la QoE 1020 de la Figure 10). Des techniques permettant d’envoyer un message du nœud terminal vers un module externe via le nœud d’accès associé peuvent être utilisées, telles que celles décrites ci-dessus par rapport aux applications spécifiques en coopération, ou d’autres techniques connues dans le domaine. Dans un aspect, le module de communication du gestionnaire de la QoE 1260 peut envoyer le message de mise à jour du nœud terminal dans son intégralité, ou peut diviser l’information de mise à jour et l’envoyer sous forme de multiples messages. Dans un aspect, le message de mise à jour du nœud terminal peut seulement contenir des informations concernant un changement au niveau des caractéristiques du flux de données d’un flux de données ou des caractéristiques du terminal, plutôt que toutes les informations possibles concernant le nœud terminal ou tous les flux de données.

Dans un exemple d’aspect, le message de mise à jour du nœud terminal peut comprendre un ou plusieurs des champs de données suivant pour chaque flux de données :

Champ de données : TerminalNodelD

Source : obtenu à partir d’une pile de réseau via un module d’interface du nœud terminal 1210.

Description : identifiant pour le nœud terminal.

Exemples : peut être une quelconque d’une adresse MAC, d’une adresse IP (si public), d’un IMSI, ou d’une autre ID unique.

Champ de données : AppID

Source : attribuée par un module de détection et de classification de flux 1250.

Description : identifiant local unique de l’application spécifique associée aux flux de données.

Exemples : peut être un hachage n-bit de l’identité du procédé du système d’exploitation de l’application spécifique et de l’horodatage.

Champ de données : StreamID

Description : identifiant du flux de données, peut être un hachage n-bit d’information 5-tuple (IP src, IP dest, Port src, Port dest, protocole). Ce champ de données peut être optionnel parce qu’il peut être considéré comme étant redondant par rapport au champ de données de la classification de flux.

Champ de données : StreamClassification

Source : obtenue à partir d’une pile de réseau via un module d’interface du nœud terminal 1210.

Description : Ceci procure des informations sur le module du gestionnaire de la QoE pour réaliser une inspection de paquet afin d’associer les paquets de données à un flux de données particulier. Ce champ de données peut être une concaténation des informations 5-tuple du flux de données (adresse src IP, adresse dest IP, port src IP, port dest IP, protocole).

Champ de données : CellID

Description : identifiant du nœud d’accès associé au nœud terminal.

Exemples : Ce champ de données peut être une ID de cellules globales pour LTE eNB, par exemple.

Champ de données : Paramètre de l’importance du flux de données

Source : déterminée par le module de détermination du paramètre de flux 1230.

Description : indicateur de l’importance pour le flux de données (décrit ci-dessus). Ce champ de données peut plutôt être remplacé par un ou plusieurs des paramètres utilisés dans le calcul du paramètre de l’importance du flux de données pour ainsi permettre aux modules de gestionnaire de la QoE de calculer le paramètre de l’importance du flux de données pour le flux de données lui-même.

Exemples : ce champ de données peut être une valeur à 4 bits.

Champ de données : Paramètre de la qualité du flux de données

Description : indicateur de la qualité pour le flux de données (décrit ci-dessus). Ce champ de données peut plutôt être remplacé par un ou plusieurs des paramètres utilisés dans le calcul du paramètre de la qualité du flux de données pour ainsi permettre aux modules de gestionnaire de la QoE de calculer le paramètre de la qualité du flux de données pour le flux de données lui-même.

Exemples : ce champ de données peut être une valeur à 4 bits.

Champ de données : Paramètre de relais

Description : Indication que le nœud terminal a été relayé à un autre nœud d’accès. Ce champ de données peut être utilisé par le module du gestionnaire de la QoE pour re-cartographier le flux de données associé à la nouvelle cellule (nœud d’accès). Dans un aspect, ce champ de données est envoyé dans le premier message de mise à jour du nœud terminal suivant la détection d’une nouvelle CellID (nœud d’accès) par le module d’interface du nœud terminal 1210.

Exemples : ce champ de données peut être une valeur à 1 bit.

Dans un exemple d’aspect, le module de réponse de la QoE 1270 peut fonctionner pour recevoir un message d’instruction d’atténuation de la QoE provenant d’un module de gestion de la QoE dans le réseau, tel qu’un module de gestionnaire de la QoE 1020 dans la Figure 10, qui contient une instruction d’atténuation qui doit être exécutée dans le nœud terminal en association avec un ou plusieurs flux de données. Dans un aspect, le module de réponse de la QoE 1270 peut fonctionner pour exécuter une instruction d’atténuation en association avec un ou plusieurs flux de données. Une telle instruction d’atténuation peut comprendre, par ex., la coordination avec le module d’interface de trafic 1280 pour retarder ou rejeter les paquets de données associés à une application spécifique, et la coordination avec le module d’interface du nœud terminal 1210 pour mettre fin ou autrement ajuster le fonctionnement d’une application spécifique.

Dans un aspect, le module d’interface de trafic 1280 fonctionne comme une interface de trafic plan d’utilisateur, en bande, pour surveiller et/ou accéder aux paquets de données, de sorte qu’à un point entre les couches TCP et HTTP, par ex., et les couches IP et TCP. Les paquets de données surveillés par le module d’interface du trafic 1280 peuvent ensuite être inspectés par le module de détection et de classification de module 1250. Dans un aspect, le module d’interface du trafic 1280 peut également fonctionner pour insérer des messages, provenant du module de communication du gestionnaire de la QoE 1260, tel qu’un message de mise à jour du nœud terminal, dans le trafic plan de l’utilisateur du nœud terminal. Le module d’interface de trafic 1280 peut également fonctionner pour réaliser, ou aider à, la mise en œuvre d’une option d’atténuation commandée par le module de réponse de la QoE 1270. Par ex., le module d’interface de trafic 1280 peut retarder les paquets de données d’un flux de données d’atteindre l’application spécifique associée, ou peut rejeter des paquets de données d’un flux de données associé à une application spécifique. Le module d’interface de trafic 1280 peut également fonctionner pour communiquer de/à partir du module de gestionnaire de la QoE dans un réseau, tel que le module de gestionnaire de la QoE 1020 de la Figure 10, en utilisant les procédés décrits ci-dessus par rapport aux Figures 1-9, ou en utilisant d’autres procédés connus. Par ex., le module d’interface de trafic 1280 peut communiquer de/à partir d’un module de gestionnaire de la QoE dans le réseau en utilisant des prises TCP/IP, une procédure d’appel à distance, ou en utilisant d’autres techniques de communication connues.

Dans un exemple d’aspect, un autre module logique 1240 peut comprendre une logique ou une fonctionnalité nécessaire pour aider d’autres modules dans le module d’application maîtresse 1200 à exécuter leurs fonctions et communications comme il est décrit ici. Comme il est mentionné ci-dessus, dans un exemple d’aspect le module de gestionnaire de la QoE collecte des informations du flux de données provenant de plusieurs nœuds terminaux associés à une pluralité de nœud d’accès dans un environnement de réseau et utilise ensuite ces informations collectées pour déterminer si l’action d’atténuation est nécessaire sur l’un ou plusieurs des flux de données afin de maintenir ou d’améliorer un paramètre de qualité d’expérience pour chaque cellule. Dans un aspect, le module de gestionnaire de la QoE fonctionne pour maintenir ou pour améliorer un paramètre global de la qualité de l’expérience pour certains ou tous les flux de données associés à un nœud d’accès. Dans un aspect, le module de gestionnaire de la QoE utilise les informations collectées sur le flux de données pour cartographier chaque flux de données à une cellule, pour calculer un paramètre global de la qualité à travers toutes les cellules (CQM) pour chaque cellule, pour déterminer si une action d’atténuation est nécessaire pour les flux de données dans l’une quelconque des cellules et pour initier une action d’atténuation soit localement ou en envoyant des instructions au ou aux nœuds terminaux appropriés. Le module de gestionnaire de la QoE peut être implémenté dans son propre nœud de réseau spécialisé, de sorte que le module de gestionnaire de la QoE 1020 de la Figure 10, ou sa fonctionnalité peut être implémentée dans un ou plusieurs nœuds de réseau qui sont configurés pour assurer d’autres fonctions de réseau, tels que la passerelle P-Gateway 1030, la passerelle S-Gateway 1040, la MME 1060 et le nœud d’accès 1050 de la Figure 10, par exemple. Le module de gestionnaire de la QoE peut être localisé à un point dans l’environnement du réseau à travers lequel tous les flux de données desservant une cellule particulière vont passer. Par ex., un environnement de réseau LTE du module de gestionnaire de la QoE peut être localisé entre une passerelle P-Gateway et l’Internet si l’opérateur du réseau LTE utilise un PDN unique. Dans un autre exemple, dans un environnement de réseau LTE le module de gestionnaire de la the QoE peut être localisé entre une passerelle P-Gateway est une passerelle S-Gateway.

Dans un aspect alternatif, le module de gestionnaire de la QoE peut être localisé à un point à travers lequel un sous-ensemble souhaité de flux de données passera. Par ex., dans un environnement de réseau LTE le module de gestionnaire de la QoE peut être localisé entre l’Internet et une passerelle P-Gateway qui dessert le trafic de données de meilleur effort (non sponsorisé par un porteur) dans un réseau multi-PDN. Dans un tel exemple, le système est limité à la gestion des flux de données qui passent à travers une passerelle P-Gateway, qui peut par ex., être le flux de trafic de données de meilleur effort, QCI=9 data stream traffic. Comme il est mentionné ci-dessus, les fonctions du module de gestionnaire de la QoE peuvent être distribuées d’une façon basée sur le Cloud partout sur l’Internet, à l’exception du module d’atténuation et du module d’interface de trafic 1280, qui doit être localisé au niveau d’un des points de l’emplacement du réseau décrits ci-dessus. Dans un aspect alternatif, un gestionnaire QoE basées sur un cloud peut communiquer des changements de politique à des nœuds de l’infrastructure du réseau qui sont capables de débrouillage du trafic du flux de données et/ou de surveillance, par ex. la passerelle P-Gateway, un PCEF ou un eNB qui applique un MBR à chaque flux de données.

La FIG. 13 est un schéma d’un module de gestionnaire de la qualité de l’expérience (QoE) conformément aux aspects de l’invention. Dans un exemple d’aspect, le module de gestionnaire de la qualité de l’expérience (QoE) 1300 de la Figure 13 comprend plusieurs modules comprenant, sans limitation, le module d’interface de trafic 1370, le module de cartographie 1310, le module de détermination de paramètres 1320, un autre module logique 1330, un module de mise à jour de la réception 1340, un module d’atténuation 1350 et un module de communication 1360.

Dans un exemple d’aspect, le module d’interface de trafic 1370 et une interface de trafic plan d’utilisateur, en bande, qui peut surveiller, copier, retarder et/ou rejeter le trafic de flux de données dans un environnement de réseau, tels que le trafic de données entre un ou plusieurs serveurs de contenu 1010 et UE1 1071 et UE2 1071, par exemple. Dans un aspect, le module d’interface de trafic 1370 peut surveiller le trafic de données pour identifier et recevoir des messages de mise à jour du nœud terminal qui sont envoyés vers celui-ci à partir des nœuds terminaux dans l’environnement du réseau, pour être utilisé par le module de réception de la mise à jour 1340. Le module d’interface de trafic 1370 peut également supporter des actions d’atténuation sur un ou plusieurs flux de données commandées par le module de détermination du paramètre 1320 et le module d’atténuation 1350, tels que le délai ou le rejet de paquets de données d’un flux de données. Le module d’interface de trafic 1370 peut supporter une action d’atténuation en insérant un message dans le flux de trafic du réseau qui est envoyé du module de communication 1360, tel qu’un message d’instruction d’atténuation qui commande au nœud terminal respectif de prendre une action d’atténuation locale contre un ou plusieurs flux de données. Le module d’interface de trafic 1370 peut également faciliter et supporter la communication de et vers les nœuds terminaux, tels que, par ex., par des techniques de communication d’application en coopération telle qu’elles sont présentées ci-dessus ou par d’autres procédés de communication connus.

Dans un exemple d’aspect, le module de réception de la mise à jour 1340 peut recevoir des messages de mise à jour d’un nœud terminal qui lui sont envoyés du module d’interface de trafic 1370 et ensuite analyser chaque message de mise à jour reçu d’un nœud terminal de sorte que les informations contenues dans chaque message reçu de mise à jour d’un nœud terminal puissent être utilisées par d’autres modules dans le module de gestionnaire de la QoE 1300.

Dans un exemple d’aspect, le module de cartographie 1310 peut mettre à jour et maintenir une cartographie relationnelle de chaque flux de données à sa cellule correspondante ou au nœud d’accès basée sur les informations contenues dans chaque message de mise à jour d’un nœud terminal reçu qui est envoyé aux modules de cartographie 1310 à partir du module de réception de la mise à jour 1340. Dans un aspect, le nœud d’accès peut être un autre type de nœud dans le réseau à travers lequel le trafic de flux de données passe de/vers les nœuds terminaux, tels que par ex., un routeur. Dans un aspect, le module de 1310 peut utiliser le champ de données cellID pour chaque flux de données dans le message de mise à jour du nœud terminal pour générer, mettre à jour et maintenir une relation de cartographie pour chaque flux de données avec sa cellule ou son nœud d’accès associé. Le module de cartographie 1310 peut également générer, mettre à jour et maintenir une relation de cartographie de chaque flux de données avec son nœud terminal associé et de chacun des flux de données avec son application spécifique associée qui s’exécute dans le nœud terminal. Ces relations peuvent être déterminées et dérivées à partir des informations contenues dans le message de mise à jour du nœud terminal. Le module de cartographie 1310 peut contrôler et faciliter le stockage des informations de cartographie dans un fichier de données tel qu’un tableau, un tableur, une base de données, telle qu’une base de données SQL, ou une cartographie logique telle que des pointeurs, une liste enchaînée, une requête de base de données, ou d’autres procédés de cartographie de données connus. Dans un aspect, le module cartographie 1310 met à jour les informations de cartographie lorsque de nouveaux messages de mise à jour du nœud terminal sont reçus par le module de réception de mise à jour 1340 et mettra ainsi à jour le flux de données par rapport à la cartographie de cellules lorsqu’un relais de nœud terminal est indiqué dans l’un ou plusieurs des messages de mise à jour du nœud terminal nouvellement reçus, tels que par ex., le champ de données du paramètre Relais dans le message de mise à jour du nœud terminal. Dans un aspect, le module de cartographie 1310 coche tous les champs de données cellID pour chaque message de mise à jour du nœud terminal reçu afin de déterminer si le cell_ID a changé pour le terminal_ID, indiquant ainsi que le nœud terminal est passé à travers un relais vers une autre cellule.

Dans un exemple d’aspect, le module de détermination du paramètre 1320 détermine une valeur globale du paramètre de la qualité basée sur certains ou tous les flux de données rapportés des messages de mise à jour d’un nœud terminal qui sont associés à un nœud d’accès. Dans un aspect, une valeur globale du paramètre de la qualité peut être basée sur tous les flux de données rapportés associés à une cellule d’un nœud d’accès. Dans un aspect, le module de détermination du paramètre 1320 reçoit ou accède à des informations de cartographie du « flux de données vers nœud d’accès » et des informations du message de mise à jour du nœud terminal fournies par le module de réception de mise à jour 1340, tel que le paramètre de la qualité du flux de données pour chaque flux de données, pour être utilisé dans la détermination de la valeur du paramètre de la qualité globale pour chaque cellule. La valeur du paramètre de la qualité globale peut être déterminée sous forme d’une moyenne ou d’un médian du paramètre de la qualité du flux de données pour certains tous les flux de données associés au nœud d’accès particulier. Dans un aspect, la valeur du paramètre de la qualité globale peut être déterminée seulement pour un sous-ensemble de tous les flux de données associés à une cellule particulière d’un nœud d’accès, tel que par ex., seuls les flux de données qui sont associés aux connexions de meilleur effort, tels que celles avec un QCI=9.

Dans un aspect, la valeur du paramètre de la qualité globale peut être modifiée ou ajustée selon la valeur du contrat du niveau de service (SLA), d’une valeur de qualité de service (QoS) ou d’un paramètre de l’importance du flux de données qui est associé avec chaque flux de données utilisé dans la détermination de la valeur du paramètre de la qualité globale. Par ex., une valeur SLA, une valeur QoS ou un paramètre de l’importance du flux de données peut être fourni sous forme de champs de données associés à chaque flux de données dans le message de mise à jour du nœud terminal, et ensuite une pondération peut être appliquée aux paramètres de la qualité du flux de données de chaque flux de données dans la détermination de la valeur du paramètre de la qualité globale dans laquelle la pondération est basée sur la valeur SLA, la valeur QoS ou du paramètre de l’importance du flux de données pour le flux de données. De cette façon, l’importance d’un utilisateur de SLA élevé, tels que SLA Or, pèsera plus lourd sur la valeur du paramètre de la qualité globale et si l’utilisateur du SLA élevé reçoit un paramètre de qualité du flux de données faible, alors, ceci aura une plus grande influence pour entraîner une valeur du paramètre de la qualité globale plus faible qui pourrait entraîner une action d’atténuation. Dans un aspect, la détermination de la valeur du paramètre de la qualité globale pour chaque nœud d’accès peut être déterminée sur une durée de temps donnée, telle qu’en moyennant le paramètre de la qualité du flux de données pour chaque flux de données sur une fenêtre temporelle coulissante. Dans un aspect, la valeur du paramètre de la qualité globale peut être déterminée sur une base périodique, ou peut être déterminée lors de la réception de chaque message de mise à jour du nœud terminal. Dans un aspect, la valeur du paramètre de la qualité globale peut être déterminée après réception d’un nombre minimal de messages de mise à jour du nœud terminal, tels que par ex., 3 messages de mise à jour du nœud terminal, et/ou après écoulement d’une période de temps minimale depuis la dernière détermination, telle que par ex. 5 secondes. Dans un aspect, la détermination de la valeur du paramètre de la qualité globale peut exclure le paramètre de qualité du flux de données pour les flux de données qui sont intentionnellement dégradées via l’implémentation d’une option d’atténuation par le module de gestionnaire de la QoE ou par un nœud terminal associé.

Dans un aspect, un module de détermination du paramètre 1320 peut également comparer chaque valeur du paramètre de la qualité globale à un seuil afin de déterminer si la qualité globale est en-dessous d’un niveau souhaité. Le seuil pour chaque groupe de flux de données, chaque cellule ou chaque nœud d’accès peut être le même ou peut être différent en fonction du type de flux de données associés, par exemple. Dans un aspect, un seuil QMVthresh est établi et si la valeur du paramètre de la qualité globale descend en dessous du QMV thresh, un minuteur T est déclenché et l’atténuation est initiée pour cette cellule.

Ensuite, si la valeur du paramètre de la qualité globale est au-dessus du QMVthresh, le minuteur T est réinitialisé et l’atténuation pour cette cellule est arrêtée. La vérification du seuil peut comprendre une durée minimale To (utilisant T), et la valeur du paramètre de la qualité globale doit être en dessous de ce seuil avant qu’une action d’atténuation puisse être posée et peut également comprendre une hystérèse de la valeur globale du paramètre. Un spécialiste du domaine saura comment utiliser d’autres procédés et des techniques connues pour déterminer si une action d’atténuation est souhaitable, telle que la comparaison d’une valeur de dégradation de la valeur du paramètre de la qualité globale à un seuil, ou l’utilisation d’une cartographie entre la valeur globale du paramètre qualité et une ou plusieurs actions d’atténuation.

Dans un aspect, le module d’atténuation 1350 peut fonctionner pour déterminer une option d’atténuation parmi une pluralité d’options d’atténuation pour appliquer une action à l’un ou plusieurs des flux de données basée sur une indication provenant du module de détermination du paramètre 1320 qu’une valeur du paramètre de la qualité globale associée aux flux de données est inférieure à un niveau souhaité. En outre, pour sélectionner parmi une pluralité d’option d’atténuation, le module d’atténuation 1350 peut également indiquer un niveau d’atténuation au niveau duquel l’option d’atténuation doit être appliquée. Par ex., pour une option d’atténuation de rejet de paquets de données, le niveau d’atténuation associé peut être l’un ou plusieurs d’une durée de temps pour appliquer l’option de rejet du paquet de données, d’un nombre de flux de données pour appliquer l’option de rejet du paquet de données et une vitesse de rejet du paquet de données. Dans un aspect, le choix d’une option d’atténuation peut être en fonction de la durée du temps pendant laquelle la valeur du paramètre de la qualité globale est en-dessous du seuil, et/ou peut être une fonction de la valeur du paramètre de la qualité globale.

La pluralité d’options d’atténuation peut impliquer des techniques et/ou des procédures d’implémentation locales au niveau du gestionnaire de la QoE 1300, tel qu’un délai et/ou d’un rejet du paquet de données par le module d’interface de trafic 1370, par ex., ou peut impliquer l’implémentation de techniques et/ou de procédures au niveau du nœud terminal associé avec le ou les flux de données, tels que l’arrêt d’une application spécifique associée avec le ou les flux de données, par exemple. A cet égard, le module d’atténuation 1350 peut envoyer un message d’instruction d’atténuation au ou aux nœuds terminaux appropriés qui comprend une option d’atténuation et éventuellement un niveau d’atténuation qui doit être appliquée à l’un ou plusieurs des flux de données au niveau du nœud terminal. Dans un aspect, l’une des options d’atténuation consiste à ne prendre aucune action d’atténuation au niveau de la cellule et de continuer à surveiller la valeur du paramètre de la qualité globale pour la cellule.

Dans un aspect, la pluralité d’options d’atténuation pour la sélection par le module d’atténuation 1350 peut être composée de plusieurs niveaux d’action d’atténuation. Par ex., les options d’atténuation peuvent être agencées dans différents niveaux d’action d’atténuation en fonction de la durée de temps pendant laquelle la valeur du paramètre de la qualité globale est en-dessous du seuil, tel que chaque niveau possède une action d’atténuation plus forte au fur et à mesure que la durée de temps pendant laquelle la valeur du paramètre de la qualité globale est en-dessous du seuil. De la même façon, les options d’atténuation peuvent être agencées dans différents niveaux d’action d’atténuation en fonction de la valeur du paramètre de la qualité globale, de sorte que chaque niveau possède une action d’atténuation plus forte lorsque la valeur du paramètre de la qualité globale descend encore plus bas par rapport au seuil. Un exemple d’aspect montrant 3 niveaux d’option d’atténuation basée pendant la durée de temps (T) pendant laquelle la valeur du paramètre de la qualité globale est en dessous du seuil est décrit ci-dessus ; cependant, il est à noter que les niveaux des options d’atténuation peuvent plutôt être basés sur la valeur du paramètre de la qualité globale actuelle, ou basée sur une combinaison à la fois du T et de la valeur du paramètre de la qualité globale (QMV).

Niveau d’atténuation : Léger

Temps pendant laquelle le QMV est en-dessous du seuil : Moins de 5 secondes

Option d’atténuation au niveau du module de gestionnaire de la QoE : (1) implémenter le délai et/ou le rejet de paquets de données sur un sous-ensemble de flux de données, commençant avec les flux de données ayant le paramètre d’importance du flux de données le plus faible ; (2) implémenter le délai et/ou le rejet de l’accusé de réception de liaison montante (ACK) sur un sous-ensemble de flux de données, commençant avec les flux de données ayant le paramètre d’importance du flux de données le plus faible.

Option d’atténuation au niveau du nœud terminal : (1) délai et/ou rejet de paquets de données sur un sous-ensemble de flux de données, commençant avec les flux de données ayant le paramètre d’importance du flux de données le plus faible ; (2) délai et/ou rejet de l’accusé de réception de liaison montante (ACK) sur un sous-ensemble de flux de données, commençant avec les flux de données ayant le paramètre d’importance du flux de données le plus faible.

Niveau d’atténuation : Moyen

Temps pendant laquelle le QMV est en-dessous du seuil : entre 5 et 20 secondes Option d’atténuation au niveau du module de gestionnaire de la QoE : Le même que le niveau d’atténuation « léger », plus (3) implémenter le délai et/ou le rejet des demandes pour l’initiation de nouveaux flux de données associés à une application spécifique, telle qu’une application spécifique nouvellement lancée dans le nœud terminal, sur la base des informations supplémentaires du flux de données contenues dans les messages de mise à jour du nœud terminal.

Option d’atténuation au niveau du nœud terminal : Le même que le niveau d’atténuation « léger », plus (3) implémenter le délai et/ou le rejet des demandes pour l’initiation de nouveaux flux de données associés à une application spécifique, telle qu’une application spécifique nouvellement lancée dans le nœud terminal. Dans un aspect, une application spécifique en coopération peut recevoir une instruction que sa demande pour un nouveau flux de données est rejetée, et peut recevoir une instruction pour ne pas initier de demandes pour de nouveaux flux de données.

Niveau d’atténuation : Élevé

Temps pendant laquelle le QMV est en-dessous du seuil : supérieur à 20 secondes Option d’atténuation au niveau du module de gestionnaire de la QoE : Le même que le niveau d’atténuation « moyen », plus (4) implémenter la terminaison d’un sous-ensemble des applications spécifiques associées à des flux de données dans la cellule, commençant avec des applications spécifiques associées avec le paramètre d’importance du flux de données le plus faible, par ex., en rejetant tous les paquets pour tous les flux qui s’étaient associés avec l’application spécifique particulière. Dans un aspect, l’implémentation d’un délai infini de tous les paquets de données pour tous les flux qui sont associés à l’application spécifique particulière arrêtera réellement l’application spécifique.

Option d’atténuation au niveau du nœud terminal : Le même que le niveau d’atténuation « moyen », plus (4) implémenter l’arrêt d’un sous-ensemble d’applications spécifiques associées avec les flux de données dans la cellule, commençant avec des applications spécifiques associées aux paramètres d’importance de flux de données le plus faible. Dans un aspect, l’application spécifique particulière qui doit être arrêtée est une application spécifique en coopération et le module de gestionnaire de la QoE envoie un message d’instruction d’atténuation vers le nœud terminal associé qui est reçu par l’application spécifique en coopération après quoi, l’application spécifique en coopération se termine elle-même, et peut éventuellement également afficher un message utilisateur pour annoncer l’arrêt imminent. Dans un aspect, le module de gestionnaire de la QoE peut envoyer un message d’instruction d’atténuation vers le module d’application maîtresse dans le nœud terminal associé pour intercepter et rejeter tous les paquets de données pour tous les flux associés à l’application spécifique particulière. Dans un aspect, le message d’instruction d’atténuation vers le module d’application maîtresse dans le nœud terminal associé peut instruire à implémenter un délai infini sur tous les paquets de données pour tous les flux qui sont associés à l’application spécifique particulière qui arrêtera réellement l’application spécifique.

Comme il est mentionné ci-dessus, en sus du choix d’une option d’atténuation, le module d’atténuation 1350 peut également déterminer un niveau auquel l’option d’atténuation doit être appliquée, telle qu’une force d’atténuation ou une durée de temps d’atténuation, par exemple. Dans un aspect, la durée de temps pendant laquelle l’option d’atténuation doit être implémentée et le niveau de force avec lequel implémenter l’option d’atténuation peut être une fonction (1) de la durée de temps (T) pendant laquelle la valeur du paramètre de la qualité globale (QMV) est en-dessous du seuil et/ou (2) la valeur du paramètre de la qualité globale elle-même. Un niveau de force pour l’option d’atténuation peut, par ex., être un nombre ou un pourcentage de flux de données sur lequel implémenter l’option d’atténuation, un niveau de pourcentage de paquets de données à rejeter et/ou un temps de délai pendant lequel retarder les paquets de données. Dans un aspect, par ex., la détermination d’un pourcentage de flux à atténuer en utilisant le délai et/ou le rejet des paquets de données peut être basée sur le Tableau A ci-dessous.

Tableau A

Dans un aspect, par ex., la détermination d’un pourcentage de flux de données à rejeter pour les flux de données atténués peut être basée sur le Tableau B ci-dessous.

Tableau B

Dans un exemple d’aspect, le module de communication 1360 peut fonctionner pour générer et envoyer, via le module d’interface de trafic 1370, un message d’instruction d’atténuation au ou aux nœuds terminaux appropriés qui comprend une option d’atténuation choisie par le module d’atténuation 1350, et éventuellement un niveau d’atténuation qui doit être appliqué à un ou plusieurs flux de données au niveau du nœud terminal. De cette façon, le module de communication 1360 supporte les options d’atténuation qui doivent être totalement ou partiellement mises en œuvre au niveau du nœud terminal. Par ex., une option d’atténuation donnée peut être orientée à l’atténuation locale au niveau du module de gestionnaire de la QoE 1300 en rejetant des paquets de données d’un ou de plusieurs flux de données est également orientés vers une action d’atténuation au niveau du nœud terminal pour retarder des paquets de données d’un ou de plusieurs flux de données. Dans un tel exemple, le module de communication 1360 génère et envoie, via le module d’interface de trafic 1370, un message d’instruction d’atténuation au nœud terminal approprié qui comprend l’option d’atténuation instruisant le nœud terminal à retarder des paquets de données d’un ou de plusieurs flux de données. Dans un aspect alternatif, le module de communication 1360 peut générer et envoyer, via le module d’interface de trafic 1370, un message d’instruction d’atténuation vers le nœud terminal approprié qui contient des données brutes, telle qu’une valeur globale de paramètre de qualité et/ou une durée de temps pendant laquelle une valeur globale de paramètre de qualité est en-dessous d’un seul, et ensuite le module d’application maîtresse au niveau du nœud terminal peut utiliser les données brutes pour déterminer l’option d’atténuation à poser, de manière semblable à celle décrite ci-dessus par rapport au module de gestionnaire de la QoE 1300.

Dans un exemple d’aspect, un autre module logique 1330 peut comprendre une logique ou une fonctionnalité nécessaire pour aider d’autres modules dans le module de gestionnaire de la QoE 1300 à exécuter leurs fonctions et communications comme il est décrit ici.

La FIG. 14 est un organigramme illustrant la fonctionnalité de haut niveau d’un module d’application maîtresse dans un nœud terminal qui supporte la gestion de la qualité de l’expérience conformément aux aspects de l’invention. À l’étape 1401, le nœud terminal met à jour les informations du flux de données de l’application pour chaque flux de données qu’il détecte et qui dessert une application spécifique s’exécutant dans le nœud terminal. Par ex., comme il est décrit ci-dessus par rapport à la Figure 12, le module d’application maîtresse 1200 réalise cette tâche en utilisant le module d’interface de trafic 1280 et le module de détection et de classification de module 1250. Ensuite, à l’étape 1403, le nœud terminal met à jour l’ensemble de données des caractéristiques de l’application actuelle et un ensemble de données des caractéristiques du nœud terminal. Par ex., tel qu’il est expliqué ci-dessus par rapport à la Figure 12, un module d’application maîtresse 1200 réalise cette tâche en utilisant un module d’évaluation des caractéristiques 1220. À l’étape 1405, le nœud terminal détermine un paramètre d’importance du flux de données pour chaque flux de données, et à l’étape 1407, le nœud terminal détermine un paramètre de qualité du flux de données pour chaque flux de données. Par ex., comme il est expliqué ci-dessus par rapport à la Figure 12, le module d’application maîtresse 1200 réalise ces tâches en utilisant le module de détermination du paramètre de flux 1230.

Ensuite, le nœud terminal génère et envoie un message de mise à jour d’un nœud terminal au module de gestionnaire de la QoE qui est implémenté dans un ou plusieurs nœuds du réseau. Par ex., comme il est expliqué ci-dessus par rapport à la Figure 12, le module d’application maîtresse 1200 réalise cette tâche en utilisant le module de communication du gestionnaire de la QoE 1260 et le module d’interface de trafic 1280. Le nœud terminal attend à l’étape 1411 soit pour une période de temps périodique soit pour l’occurrence d’un événement déclencheur, tel que la réception d’un message provenant du système d’exploitation ou d’une application spécifique en coopération, avant de revenir au début du procédé à l’étape 1401. Il doit être noté qu’une ou plusieurs des étapes décrites ci-dessus dans la Figure 14 peuvent être optionnelles, et que la décision de réaliser ou non l’une ou plusieurs des étapes de la Figure 14 peut dépendre d’un type d’événement ou d’une condition qui a déclenché le début de la procédure de la Figure 14.

La FIG. 15 est un organigramme illustrant la fonctionnalité de haut niveau d’un module de gestionnaire de la qualité de l’expérience conformément aux aspects de l’invention. À l’étape 1501, le module de gestionnaire de la QoE reçoit des messages de mise à jour du nœud terminal provenant de plusieurs nœuds terminaux dans le réseau. Par ex., comme il est expliqué ci-dessus par rapport à la Figure 13, le module de gestionnaire de la QoE 1300 réalise cette tâche en utilisant le module de réception de la mise à jour 1340 et le module d’interface de trafic 1370. Ensuite, à l’étape 1503, le module de gestionnaire de la QoE met à jour une carte de relations qui relient chaque flux de données à sa cellule associée, et chaque flux de données à son nœud terminal associé. Par ex., comme il est expliqué ci-dessus par rapport à la Figure 13, le module de gestionnaire de la QoE 1300 réalise cette tâche en utilisant le module de réception de la mise à jour 1340 et le module d’interface de trafic 1370. À l’étape 1505, le module de gestionnaire de la QoE détermine une valeur globale du paramètre de la qualité pour chaque cellule basée sur le paramètre de la qualité du flux de données pour chaque flux de données qui est extrait des messages de mise à jour du nœud terminal. Par ex., comme il est expliqué ci-dessus par rapport à la Figure 13, le module de gestionnaire de la QoE 1300 réalise cette tâche en utilisant le module de détermination de paramètre 1320. Ensuite, à l’étape 1507, le module de gestionnaire de la QoE détermine une option d’atténuation pour l’un ou plusieurs des flux de données dans la cellule basée sur la valeur du paramètre de la qualité globale, l’option d’atténuation peut être une absence d’action. Par ex., comme il est expliqué ci-dessus par rapport à la Figure 13, le module de gestionnaire de la QoE 1300 réalise cette tâche en utilisant le module d’atténuation 1350. A l’étape 1509, le module de gestionnaire de la QoE exécute ensuite l’option d’atténuation pour l’un ou plusieurs des flux de données dans la cellule, qui peuvent être implémentés localement par le module de gestionnaire de la QoE ou au niveau du nœud terminal associé. Par ex., comme il est expliqué ci-dessus par rapport à la Figure 13, le module de gestionnaire de la QoE 1300 réalise cette tâche en utilisant le module d’atténuation 1350, le module d’interface du trafic 1370 et éventuellement le module de communication 1360. Il doit être noté que l’une ou plusieurs des étapes de la Figure 15 décrites ci-dessus peuvent être optionnelles, et que la décision de réaliser ou non l’une ou plusieurs des étapes de la Figure 15 peut dépendre d’un type d’événement de conditions au début de la procédure de la Figure 15.

La FIG. 16 est un organigramme illustrant la fonctionnalité d’atténuation de haut niveau d’un module d’application maîtresse dans un nœud terminal qui supporte la gestion de la qualité de l’expérience conformément aux aspects de l’invention. À l’étape 1601, le nœud terminal reçoit un message d’instruction d’atténuation provenant du module de gestionnaire de la QoE qui contient une instruction pour implémenter, partiellement ou intégralement, une option d’atténuation sur l’un ou plusieurs des flux de données associés au nœud terminal. Par ex., comme il est expliqué ci-dessus par rapport à la Figure 12, le module d’application maîtresse 1200 réalise cette tâche en utilisant le module de communication 1260 du gestionnaire de la QoE et le module d’interface de trafic 1280. Ensuite, le nœud terminal exécute l’option d’atténuation reçue dans le message d’instruction de l’atténuation sur un ou plusieurs flux de données associés au nœud terminal à l’étape 1603. Par ex., comme il est expliqué ci-dessus par rapport à la Figure 12, le module d’application maîtresse 1200 du nœud terminal réalise cette tâche en utilisant le module de réponse 1270 de la QoE, le module d’interface de trafic 1280 et éventuellement le module d’interface du nœud terminal 1210. De cette façon, le nœud terminal peut fonctionner en coopération avec le module de gestionnaire de la QoE pour surveiller la qualité des flux de données pour poser une action d’atténuation sur un ou plusieurs des flux, s’il y a lieu, pour maintenir ou améliorer une qualité de l’expérience poulet les utilisateurs du nœud terminal. Il doit être noté que, même si les aspects et les modes de réalisation décrits ci-dessus concernent la surveillance et la gestion des flux de données de liaison descendante apparentée aux applications spécifiques fonctionnant dans les nœuds terminaux, le module de gestionnaire de la QoE et le ou les modules d’application maîtresse peuvent, de la même façon, coopérer pour surveiller et gérer des flux de données en liaison ascendante apparentés à de telles applications spécifiques fonctionnant au niveau des nœuds terminaux. Dans un tel scénario, le serveur de contenu peut être localisé au niveau du nœud terminal et l’application client peut être localisée dans un autre nœud du réseau.

Dans un aspect alternatif, les nœuds terminaux dans un environnement de réseau peuvent chacun agir seul pour surveiller la qualité des flux de données associés à des applications spécifiques dans le nœud terminal et de poser une action d’atténuation sur l’un ou plusieurs des flux de données, s’il y a lieu, pour maintenir ou améliorer une qualité de l’expérience associée à l’une ou plusieurs des applications spécifiques du nœud terminal. Dans cet aspect, le nœud terminal fonctionne seul sans l’aide du module de gestionnaire de la QoE et implémente plutôt certaines des caractéristiques et des fonctions décrites ci-dessus par rapport au module de gestionnaire de la QoE directement dans le nœud terminal. De cette façon, chaque nœud terminal fonctionne localement pour surveiller et ajuster la qualité des flux de données associés à des applications spécifiques fonctionnant dans le nœud terminal respectif.

La FIG. 17 est un schéma d’un module d’application maîtresse dans un nœud terminal qui réalise la gestion de la qualité de l’expérience conformément aux aspects de l’invention. Le module d’application maîtresse 1700 de la Figure 17 est configuré pour fonctionner selon l’aspect alternatif susmentionné dans lequel le nœud terminal fonctionne seul, sans l’aide du module du gestionnaire de la QoE, pour surveiller et ajuster localement la qualité des flux de données associés à des applications spécifiques fonctionnant dans le nœud terminal. On peut voir sur la Figure 17 que le module d’application maîtresse 1700 contient plusieurs des mêmes modules précédemment décrits ci-dessus par rapport au module d’application maîtresse 1200 de la Figure 12. La fonctionnalité de chaque même module n’est pas répétée ici par souci de brièveté, excepté lorsque certaines différences peuvent s’appliquer dans cet aspect alternatif. L’une des différences clés dans cet aspect alternatif est que le module de communication 1260 du gestionnaire de la QoE et d’une module de réponse 1270 de la QoE dans le module d’application maîtresse 1200 de la Figure 12 ne sont pas compris dans le module d’application maîtresse 1700 de la Figure 17. Au lieu de cela, le module d’atténuation 1760 est fourni dans le module d’application maîtresse 1700 pour déterminer et exécuter une option d’atténuation, s’il y en a, basée sur un paramètre global de qualité pour les flux de données associés au nœud terminal, comme il est décrit plus en détail ci-dessous.

Sans répéter la fonctionnalité détaillée des mêmes modules que ceux illustrés dans la Figure 12, un bref résumé du flux de procédé pour le module d’application maîtresse 1700 est que le module de détection et de classification de flux 1750 et le module d’interface de trafic 1780 fonctionnent pour détecter, identifier et classer des flux de données qui supportent des applications spécifiques fonctionnant dans le nœud terminal, ensuite le module d’évaluation des caractéristiques 1720, avec un support probable du module d’interface du nœud terminal 1710, identifies l’ensemble de données des caractéristiques d’une application actuelle et l’ensemble de données des caractéristiques d’un nœud terminal actuel pour chaque flux de données, accompagnés d’autres informations apparentées. Le module de détermination du paramètre de flux 1730 détermine un paramètre de qualité du flux de données et un paramètre de l’importance du flux de données pour chaque flux de données en fonction de l’ensemble de données des caractéristiques de l’application actuelle et de l’ensemble des données des caractéristiques du nœud terminal actuel, accompagné d’autres informations apparentées, et détermine ensuite un paramètre de qualité globale (dans tout le nœud terminal) pour certains ou tous les flux de données associés au nœud terminal. À cet égard, le module de détermination du paramètre de flux 1730 peut déterminer le paramètre de qualité du flux de données, le paramètre de l’importance du flux de données et un paramètre de qualité globale (dans tout le nœud terminal) selon l’une quelconque des techniques et des méthodes décrites ci-dessus par rapport au module de détermination de paramètres 1320 du module de gestionnaire 1300 de la QoE dans la Figure 13. La différence dans cet aspect alternatif de la Figure 17 est que le paramètre de qualité globale (dans tout le nœud terminal) est basé sur le paramètre de qualité du flux de données seulement pour les flux de données associés au nœud terminal spécifique, contrairement à la valeur du paramètre de la qualité globale déterminée par le module de détermination de paramètre 1320 de la Figure 13 qui est basée sur le paramètre de qualité du flux de données pour certains tous les flux de données associés à tous les nœuds terminaux correspondant à un nœud d’accès dans le réseau. Le module de détermination du paramètre du flux 1730 peut ensuite utiliser des techniques et les méthodes décrites ci-dessus par rapport au module de détermination du paramètre 1320 de la Figure 13 pour comparer le paramètre de qualité globale (dans tout le nœud terminal) à un seuil.

Le module d’atténuation 1760 utilise des résultats de la comparaison du paramètre de qualité globale (dans tout le nœud terminal) à un seuil pour déterminer l’option d’atténuation à appliquer à l’un ou plusieurs des flux de données associés au nœud terminal. Comme il est mentionné ci-dessus, l’une des options d’atténuation peut consister à ne prendre aucune action actuelle et de continuer à surveiller le paramètre de qualité globale. Les techniques et les méthodes permettant la détermination d’une option d’atténuation, et les types d’options d’atténuation, décrites ci-dessus par rapport au module d’atténuation 1350 peuvent être utilisées par le module d’atténuation 1760 et ne sont pas répétées ici par souci de brièveté. Les options d’atténuation décrites ci-dessus qui peuvent être appliquées et/ou implémentées par le nœud terminal peuvent être utilisées. À cet égard, le module d’atténuation 1760, en coordination avec l’un ou plusieurs des modules d’interface de trafic 1780 et le module d’interface du nœud terminal 1710, peut ensuite exécuter l’option d’atténuation déterminée sur un ou plusieurs flux de données associés au nœud terminal. Cette façon d’exécuter une option d’atténuation, y compris la durée et le niveau (force) de l’implémentation, telle qu’elle est décrite ci-dessus par rapport au module d’atténuation 1350 de la Figure 13 peut être utilisée par le module d’atténuation 1760 de la Figure 17 pour exécuter l’option d’atténuation.

La FIG. 18 est un organigramme illustrant la fonctionnalité de haut niveau d’un module d’application maîtresse dans un nœud terminal qui réalise la gestion de la qualité de l’expérience conformément aux aspects de l’invention. En particulier, l’organigramme de la Figure 18 correspond à un module d’application maîtresse 1700 de la Figure 17. À l’étape 1801, le nœud terminal mais à jour les informations du flux de données de l’application pour chaque flux de données qu’il détecte et qui dessert une application spécifique fonctionnant dans le nœud terminal. Par ex., comme il est décrit ci-dessus, le module d’application maîtresse 1700 réalise cette tâche en utilisant le module d’interface de trafic 1780 et le module de détection et de classification de module 1750. Ensuite, à l’étape 1803, le nœud terminal met à jour un ensemble de données des caractéristiques de l’application actuelle et un ensemble de données des caractéristiques du nœud terminal actuel. Par ex., tel qu’il est expliqué ci-dessus, un module d’application maîtresse 1700 réalise cette tâche en utilisant un module d’évaluation des caractéristiques 1720. À l’étape 1805, le nœud terminal détermine un paramètre d’importance du flux de données pour chaque flux de données, et à l’étape 1807, le nœud terminal détermine un paramètre de qualité du flux de données pour chaque flux de données. Par ex., comme il est expliqué ci-dessus, le module d’application maîtresse 1700 réalise ces tâches en utilisant le module de détermination du paramètre de flux 1730. Ensuite, à l’étape 1809, le nœud terminal détermine un paramètre de qualité globale (dans tout le terminal) basé sur le paramètre de qualité du flux de données, le paramètre de l’importance du flux de données et d’autres informations apparentées à l’un ou plusieurs des flux de données associées aux applications spécifiques fonctionnant dans le nœud terminal. Par ex., comme il est expliqué ci-dessus, le module d’application maîtresse 1700 réalise ces tâches, en sus de comparer le paramètre de qualité globale (dans tout le terminal) à un seuil, en utilisant le module de détermination du paramètre de flux 1730.

Ensuite, à l’étape 1811, le nœud terminal détermine une option d’atténuation pour un ou plusieurs des flux de données associés au nœud terminal basé sur la valeur du paramètre de la qualité globale, l’option d’atténuation peut être de ne pas prendre d’action. Par ex., comme il est expliqué ci-dessus, le module d’application maîtresse 1700 réalise cette tâche en utilisant le module d’atténuation 1760. A l’étape 1813, le nœud terminal exécute l’option d’atténuation pour l’un ou plusieurs des flux de données associés à la cellule. Par ex., comme il est expliqué ci-dessus, le module d’application maîtresse 1700 réalise cette tâche en utilisant le module d’atténuation 1760, le module d’interface de trafic 1780 et éventuellement le module d’interface du nœud terminal 1710. De cette façon, chaque nœud terminal peut fonctionner indépendamment localement pour surveiller et ajuster la qualité des flux de données associés aux applications spécifiques fonctionnant dans le nœud terminal.

Il doit être noté que, même si les aspects et les modes de réalisation décrits ci-dessus par rapport aux Figures 17 et 18 concernent la surveillance et la gestion des flux de données de liaison descendante apparentée aux applications spécifiques fonctionnant dans le nœud terminal, le ou les modules d’application maîtresse peuvent, de la même façon, coopérer pour surveiller et gérer des flux de données en liaison ascendante apparentés à de telles applications spécifiques fonctionnant au niveau du nœud terminal. Dans un tel scénario, le serveur de contenu peut être localisé au niveau du nœud terminal et l’application client peut être localisée dans un autre nœud du réseau.

Les systèmes et les procédés et les dispositifs associés et les modules précédemment décrits sont susceptibles à diverses variations. En outre, pour la clarté et la précision, plusieurs descriptions de systèmes et de procédés ont été simplifiées. Par ex., les figures illustrent généralement l’un de chaque type de dispositif (par ex., un nœud d’accès, un nœud terminal), mais un système de communication peut posséder chaque type de dispositif. De la même façon, plusieurs descriptions utilisent la terminologie et les structures d’une norme sans fil spécifique telle que la norme LTE. Cependant, les systèmes et les procédés divulgués sont plus largement applicables, comprenant par ex., dans des systèmes de modem de câble de fibres coaxiaux hybrides.

Les spécialistes du domaine comprendront que divers blocs logiques illustratifs, modules, unités et étapes d’algorithmes décrits en relation avec les modes de réalisation divulgués ici peuvent souvent être implémentés sous forme de matériel électronique, de logiciel informatique ou d’une combinaison des deux. Afin de clairement illustrer cette interchangeabilité entre le matériel et le logiciel, divers composants, blocs, modules, circuits et étapes illustratives ont été décrits ci-dessus généralement en termes de leur fonctionnalité. La mise en œuvre de cette fonctionnalité sous forme de matériel ou de logiciel dépend des contraintes particulières imposées sur le système global. Les spécialistes peuvent mettre en œuvre la fonctionnalité décrite de diverses façons pour chaque système donné, mais de telles décisions de mise en œuvre ne doivent pas être interprétées comme étant un écart par rapport à la portée de l’invention. En outre, le regroupement des fonctions dans une unité, un module, un bloc, ou une étape est fait dans le but de faciliter la description. Les fonctions ou les étapes spécifiques peuvent être déplacées d’une unité, d’un module ou d’un bloc sans s’écarter de l’invention.

Les divers blocs logiques illustratifs, les unités, les étapes et les modules décrits en relation avec les modes de réalisation divulgués ici peuvent être mis en œuvre ou réalisés avec un processeur, tel qu’un processeur polyvalent, un processeur de signal numérique (« DSP »), un ASIC, un FPGA ou un autre dispositif logique programmable, une porte discrète ou une logique à transistor, des composants matériels discrets ou toute combinaison de ceux-ci conçus pour réaliser les fonctions décrites ici. Un processeur polyvalent peut être un microprocesseur, mais dans l’alternatif, le processeur peut être un quelconque processeur, contrôleur, microcontrôleur ou un automate. Un processeur peut également être mis en œuvre sous forme d’une combinaison de dispositifs de calcul, par ex., une combinaison d’un DSP est d’un microprocesseur, une pluralité de microprocesseurs, un ou plusieurs microprocesseurs en association avec un cœur DSP, ou une quelconque configuration de ce genre.

Les étapes d’un procédé ou d’un algorithme et les procédés d’un bloc ou d’un module décrits en relation avec les modes de réalisation divulgués ici peuvent être réalisées directement dans le matériel, dans un module logiciel exécuté par un processeur, ou dans une combinaison des deux. Un module logiciel peut être hébergé dans une mémoire RAM, une mémoire flash, une mémoire ROM, une mémoire EPROM, une mémoire EEPROM, des registres, un disque dur, un disque amovible, un CD-ROM, ou toute autre forme de support de stockage. Un exemple de support de stockage peut être couplé au processeur de sorte que le processeur puisse lire des informations à partir du support de stockage, et enregistrer des informations sur celui-ci. Dans le cas contraire, le support de stockage peut faire partie du processeur. Le processeur et le support de stockage peuvent également être sur un ASIC. En outre, le dispositif, les blocs ou les modules qui sont décrits comme étant couplés peuvent être couplés via un dispositif, des blocs ou des modules intermédiaires. De la même façon, un dispositif peut être décrit comme transmettant des données vers (ou recevant de) un deuxième dispositif lorsqu’il y a des dispositifs intermédiaires couplent le premier et le deuxième dispositif, mais également lorsque le premier dispositif n’est pas au courant de la destination ultime des données.

La description précédente des modes de réalisation divulgués est présentée pour permettre à tous les spécialistes du domaine de réaliser ou d’utiliser l’invention. Diverses modifications de ces matérialisations seront évidentes aux spécialistes du domaine, et les principes génériques décrits ici peuvent être appliqués à d’autres modes de réalisation sans s’écarter de l’esprit ou de la portée de l’invention. Ainsi, il doit être compris que la description et les illustrations présentées ici représentent un mode de réalisation de l’invention actuellement préférée et sont donc représentatives d’une matière qui est d’une manière générale envisagée par la présente invention. Il est également compris que la portée de la présente invention recouvre entièrement d’autres modes de réalisation qui deviendront évident aux spécialistes du domaine et que la portée de la présente invention est, de la même façon, limitée seulement par les revendications ci-jointes.

Claims

REVENDICATIONS

1. Nœud de gestionnaire d’application (275, 475) dans un réseau de communication, comprenant : un module émetteur/récepteur (279, 479) configuré pour surveiller des données de communication dans le réseau de communication ; et un processeur (281, 480) couplé au module émetteur/récepteur (279, 479) et configuré pour : recevoir, à partir d’au moins un nœud terminal (255, 455), des informations d’application apparentées à au moins un flux de données d’application associé à au moins une application (451) fonctionnant dans l’au moins un nœud terminal (255, 455), mettre à jour, en fonction des informations d'application, d’une carte de relation (1310) qui comprend une relation entre chacun de l’au moins un flux de données d’application et un nœud d’accès (275, 475), déterminer une valeur globale de la qualité du paramètre basé au moins en partie sur les informations d’application provenant d’un ou de plusieurs de l’au moins un nœud terminal (275, 475), et sélectionner, en fonction de la valeur du paramètre de la qualité globale, au moins une option d’atténuation pour l’un ou plusieurs de l’au moins un flux de données d’application, caractérisé en ce que la valeur du paramètre de la qualité globale est une valeur de la qualité du paramètre dans toute la cellule qui est déterminée en fonction du paramètre de la qualité du flux de données pour un ou plusieurs de l’au moins un flux de données d’application qui est associé à une cellule du nœud d’accès (275, 475), et la détermination de la valeur du paramètre de la qualité globale est basée sur une valeur moyenne du paramètre de la qualité du flux de données pour un ou plusieurs de l’au moins un flux de données d’application.
2. Nœud de gestionnaire d’application (275, 475) de la revendication 1, dans lequel la carte de relations (1310) comprend également une relation entre chacun de l’au moins un flux de données d’application et l’un de l’au moins un nœud terminal qui a envoyé l’information d’application pour le flux de données d’application respectif vers le nœud de gestionnaire d’application (275, 475).
3. Nœud de gestionnaire d’application (275, 475) de la revendication 1, dans lequel la valeur du paramètre de la qualité globale et basée au moins en partie sur les informations d’application provenant de l’un ou de plusieurs de l’au moins un nœud terminal (255, 455) qui est associé au nœud d’accès (275, 475).
4. Nœud de gestionnaire d’application (275, 475) de la revendication 1, dans lequel le processeur (281, 480) est également configuré pour initier l’au moins une option d’atténuation.
5. Nœud de gestionnaire d’application (275, 475) de la revendication 1, dans lequel la valeur du paramètre de la qualité globale est comparée à un seuil et le choix de l’atténuation est réalisé si la valeur du paramètre de la qualité globale dépasse le seuil.
6. Nœud de gestionnaire d’application (275, 475) de la revendication 1, dans lequel la liaison de communication à travers laquelle le nœud d’accès (275, 475) et le nœud terminal (255, 455) communiquent est l’un d’un réseau sans fil ou d’un réseau sur fil.
7. Nœud de gestionnaire d’application (275, 475) de la revendication 1, dans lequel les informations d’application est l’un d’un rapport périodique et d’un rapport apériodique provenant de l’au moins un nœud terminal (255, 455).
8. Nœud de gestionnaire d’application (275, 475) de la revendication 1, dans lequel les informations d’application comprennent des informations d’application et des informations sur le nœud terminal et la valeur du paramètre de la qualité globale est déterminée en fonction des informations d’application et des informations du nœud terminal.
9. Nœud de gestionnaire d’application (275, 475) de la revendication 1, dans lequel les informations d’application comprennent au moins l’un d’un paramètre de la qualité du flux de données et d’un paramètre de l’importance du flux de données apparentés à un ou plusieurs de l’au moins un flux de données associé à une application correspondante.
10. Nœud de gestionnaire d’application (279, 479) de la revendication 1, dans lequel une pondération est appliquée à chaque paramètre de qualité du flux de données lors de la détermination de la valeur du paramètre de la qualité globale, et dans lequel chaque pondération est basée sur au moins une valeur de contrat de niveau de service (SLA), une valeur de la qualité du service (QoS) et d’un paramètre de l’importance du flux de données.
11. Nœud de gestionnaire d’application (279, 479) de la revendication 1, dans lequel la valeur du paramètre de la qualité globale est déterminée en fonction d’un paramètre de qualité du flux de données pour chacun d’un sous-ensemble de l’au moins un flux de données d’application associé au nœud d’accès (275, 475).
12. Nœud de gestionnaire d’application (279, 479) selon la revendication 5, dans lequel le choix de l’au moins une option d’atténuation est réalisé si la valeur du paramètre de la qualité globale reste en dessous du seuil pour une durée de temps minimale.
13. Nœud de gestionnaire d’application (279, 479) selon la revendication 4, dans lequel l’initiation de l’au moins une option d’atténuation comprend l’envoi d’un message d’instruction d’atténuation à l’un de l’au moins un nœud terminal (275, 475) qui est associé au flux de données d’application sur lequel l’option d’atténuation doit être implémentée.
14. Nœud de gestionnaire d’application (279, 479) de la revendication 13, dans lequel le message d’instruction de l’atténuation comprend au moins une de la valeur du paramètre de la qualité globale et une durée de temps pendant laquelle la valeur du paramètre de la qualité globale est restée en dessous du seuil.
15. Nœud de gestionnaire d’application (279, 479) de la revendication 1, dans lequel l’au moins une option d’atténuation comprend un ou plusieurs de retarder les paquets de données, de rejeter les paquets de données, de retarder les accusés de réception, de rejeter les accusés de réception, de retarder les demandes d’initiation de nouveaux flux de données, de rejeter les demandes d’initiation de nouveaux flux de données, de mettre fin à une application, et de ne prendre aucune action.
16. Nœud de gestionnaire d’application (279, 479) selon la revendication 1, dans lequel le choix d’au moins une option d’atténuation associée à un ou plusieurs de l’au moins un flux de données d’application est basé en partie sur le paramètre de l’importance du flux de données pour chacun de l’au moins un flux de données d’application.
17. Nœud de gestionnaire d’application (279, 479) selon la revendication 4, dans lequel l’au moins une option d’atténuation choisie est implémentée en fonction de la durée de temps pendant laquelle la valeur du paramètre de la qualité globale est en-dessous d’un seuil.
18. Nœud de gestionnaire d’application (279, 479) selon la revendication 4, dans lequel l’au moins une option d’atténuation choisie est implémentée en fonction de la valeur du paramètre de la qualité globale.
19. Nœud terminal (255, 455) dans un réseau de communication comportant un nœud d’accès (275, 475), comprenant : un module émetteur/récepteur (259) configuré pour envoyer des paquets de données au, et de recevoir des paquets de données à partir de, nœud d’accès (275, 475) via le réseau de communication ; et un processeur (261) couplé au module émetteur/récepteur (259) et configuré pour : détecter au moins un flux de données d’application en surveillant les paquets de données envoyées vers, et provenant de, le nœud d’accès (275, 475) via un réseau de communication, déterminer, pour chacun de l’au moins un flux de données d’application détecté, des informations d’application apparentée à une application fonctionnant dans le nœud terminal (255, 455) qui est associé au flux de données d’application respectif, les informations d’application comprenant un paramètre de la qualité du flux de données pour chaque flux de données d’application respectif, d’envoyer, via le réseau de communication, les informations d’application pour chacun de l’au moins un flux de données d’application détecté, de recevoir, via le réseau de communication, au moins une instruction d’atténuation associée à un ou plusieurs de l’au moins un flux de données d’application, et d’implémenter l’au moins une instruction d’atténuation pour l’un ou les plusieurs de l’au moins un flux de données d’application associé, caractérisé en ce que l’au moins une instruction d’atténuation comprend au moins l’une d’une valeur du paramètre de la qualité globale et d’une durée de temps pendant laquelle la valeur du paramètre de la qualité globale et en dessous d’un seuil, et dans lequel l’implémentation de l’au moins une instruction d’atténuation comprend la détermination d’une action d’atténuation basée sur l’au moins une valeur du paramètre de la qualité globale et de la durée de temps.
20. Nœud terminal (255, 455) de la revendication 19, dans lequel le réseau de communication est un d’un réseau de communication sans fil est un réseau de communication surfil.
21. Nœud terminal (255, 455) selon la revendication 19, dans lequel des informations d’application pour chacun de l’au moins un flux de données d’application détecté est déterminé en fonction au moins en partie d’un ensemble de données des caractéristiques du nœud terminal.
22. Nœud terminal (255, 455) selon la revendication 19, dans lequel les informations d’application sont envoyées vers le nœud d’accès (275, 475) pour le transfert à partir du nœud d’accès (275, 475) vers un nœud de gestionnaire d’application (275, 475).
23. Nœud terminal (255, 455) selon la revendication 19, dans lequel le processeur (261) est également configuré pour classer un ou plusieurs de l’au moins un flux de données d’application détecté en inspectant un ou plusieurs paquets de données associés au flux de données d’application respectif et en attribuant une valeur de classe d’application au flux de données d’application en fonction de l’inspection d’un ou de plusieurs paquets de données, et dans lequel la valeur de la classe d’application est comprise dans les informations d’application pour le flux de données d’application respectif.
24. Nœud terminal (255, 455) selon la revendication 19, dans lequel la détermination des informations d’application pour chaque flux de données d’application comprend la détermination d’un paramètre de l’importance du flux de données pour le flux de données d’application et l’inclusion du paramètre de l’importance du flux de données dans les informations d’application pour le flux de données d’application.
25. Nœud terminal (255, 455) selon la revendication 24, dans lequel le processeur est également configuré pour générer au moins un d’un ensemble de données des caractéristiques de l’application actuelle pour chacun de l’au moins un flux de données d’application basé sur les caractéristiques actuelles d’une application associée au flux de données d’application respectif, et d’un ensemble de données des caractéristiques du nœud terminal (255, 455) actuel basé sur les caractéristiques actuelles du nœud terminal (255, 455).
26. Nœud terminal (255, 455) de la revendication 25, dans lequel le paramètre de l’importance du flux de données est basé au moins en partie sur l’ensemble de données des caractéristiques de l’application actuelle et de l’ensemble de données des caractéristiques du nœud terminal actuel.
27. Nœud terminal (255, 455) de la revendication 25, dans lequel l’ensemble de données des caractéristiques de l’application actuelle comprend au moins une ou plusieurs d’une valeur de la classe d’application, une valeur du type d’initiation du flux, d’une valeur de la mise à jour en attente, d’une valeur de la position d’affichage, d’une valeur de la qualité de service du réseau (QoS) et d’une valeur de la marge de la mise en mémoire.
28. Nœud terminal (255, 455) selon la revendication 25, dans lequel l’ensemble de données des caractéristiques du nœud terminal actuel comprend au moins une ou plusieurs parmi une valeur de l’attention de l’utilisateur et une valeur du contrat du niveau de service (SLA) et un type de nœud terminal.
29. Nœud terminal (255, 455) de la revendication 24, dans lequel le paramètre de la qualité du flux de données est basé au moins en partie sur une indication de paquets de données manquants ou retardés associés au flux de données d’application.
30. Nœud terminal (255, 455) de la revendication 4, dans lequel le paramètre de qualité du flux de données est basé en partie au moins sur une valeur du paramètre de la qualité de l’application provenant de l’application fonctionnant dans le nœud terminal (255, 455) qui est associé au flux de données d’application correspondant.
31. Nœud terminal (255, 455) de la revendication 19, dans lequel les informations d’application pour chaque flux de données d’application comprend au moins un parmi un ensemble de données des caractéristiques d’application apparenté au flux de données et un ensemble de données des caractéristiques du nœud terminal.
32. Nœud terminal (255, 455) de la revendication 9, dans lequel les informations d’application sont envoyées du nœud terminal (255, 455) vers le nœud d’accès (275, 475) selon l’une d’une base périodique et apériodique.
33. Nœud terminal (255, 455) de la revendication 19, dans lequel les informations d’application comprennent également l’une ou plusieurs d’une identification du nœud terminal (255, 455) associée au nœud terminal, une identification de cellule associée au nœud d’accès (275, 475), et une valeur de paramètre de relais.
34. Nœud terminal (255, 455) de la revendication 19, dans lequel l’au moins une instruction d’atténuation comprend une ou plusieurs d’une instruction de retard d’un paquet de données, une instruction rejet de paquets de données, une instruction de retard d’accusé de réception, une instruction de rejet d’accusé de réception, une instruction de retard de la demande d’un nouveau flux de données, une instruction de rejet de la demande d’un nouveau flux de données et une instruction de terminaison d’une application.
35. Nœud terminal (255, 455) de la revendication 19, dans lequel l’implémentation de l’au moins une instruction d’atténuation est basée au moins en partie sur un paramètre de l’importance du flux de données pour chacun de l’au moins un flux de données d’application.
36. Nœud terminal (255, 455) de la revendication 35, dans lequel l’une de l’au moins une instruction d’atténuation respective est implémentée sur le flux de données d’application ayant le paramètre de l’importance du flux de données le plus bas, et elle est ensuite successivement implémentée pour au moins un autre flux de données d’application ayant le deuxième paramètre de l’importance du flux de données le plus bas.
37. Nœud terminal (255, 455) de la revendication 19, dans lequel l’au moins une instruction d’atténuation est implémentée sur un nombre croissant des flux de données d’application associés lorsqu’une durée de temps de l’implémentation augmente.
38. Nœud terminal (255, 455) d’application de la revendication 19, dans lequel l’au moins une option d’atténuation est implémentée en fonction d’une durée de temps pendant laquelle la valeur du paramètre de la qualité globale est en-dessous d’un seuil.
39. Nœud terminal (255, 455) de la revendication 19, dans lequel le niveau d’implémentation de l’au moins une instruction d’atténuation est basée sur la valeur du paramètre de qualité.
40. Procédé pour la gestion d’une qualité d’application dans un réseau de communication, le procédé comprenant : la réception, à partir d’au moins un nœud terminal (275, 475), des informations d’application apparentées à au moins un flux de données d’application associé à au moins une application fonctionnant dans l’au moins un nœud terminal (275, 475), la mise à jour, en fonction des informations d’application, d’une carte de relation (1310) qui comprend une relation entre chacun de l’au moins un flux de données d’application et un nœud d’accès (275, 475), la détermination d’une valeur globale de la qualité du paramètre basé au moins en partie sur les informations d’application provenant d’un ou de plusieurs de l’au moins un nœud terminal (275, 475); et la sélection, en fonction de la valeur globale du paramètre de qualité, d’au moins une option d’atténuation pour l’un ou plusieurs de l’au moins un flux de données d’application, caractérisé en ce que la valeur du paramètre de la qualité globale est une valeur de la qualité du paramètre dans toute la cellule qui est déterminée en fonction du paramètre de la qualité du flux de données pour un ou plusieurs de l’au moins un flux de données d’application qui est associé à une cellule du nœud d’accès (275, 475), et la détermination de la valeur du paramètre de la qualité globale est basée sur une valeur moyenne du paramètre de la qualité du flux de données pour un ou plusieurs de l’au moins un flux de données d’application.
41. Procédé selon la revendication 40, dans lequel la carte de relations comprend une relation entre chacun de l’au moins un flux de données d’application et l’un de l’au moins un nœud terminal (275, 475) qui a envoyé les informations d’application pour le flux de données d’application respectif vers le nœud de gestionnaire d’application.
42. Procédé selon la revendication 40, dans lequel la valeur du paramètre de la qualité globale est basée au moins en partie sur les informations d’application provenant de l’un ou de plusieurs de l’au moins un nœud terminal (255, 455) qui est associé au nœud d’accès (275, 475).
43. Procédé selon la revendication 40, comprenant également l’étape d’initiation de l’au moins une option d’atténuation.
44. Procédé selon la revendication 40, dans lequel la valeur du paramètre de la qualité globale est comparée à un seuil et le choix de l’atténuation est réalisé si la valeur du paramètre de la qualité globale dépasse le seuil.
45. Procédé selon la revendication 40, dans lequel une liaison de communication à travers laquelle le nœud d’accès (275, 475) et le nœud terminal (255, 455) communiquent est l’un d’un réseau sans fil ou d’un réseau sur fil.
46. Procédé selon la revendication 40, dans lequel les informations d’application est l’un d’un rapport périodique et d’un rapport apériodique provenant de l’au moins un nœud terminal (255, 455).
47. Procédé selon la revendication 40, dans lequel les informations d’application comprennent des informations d’application et des informations sur le nœud terminal et la valeur du paramètre de la qualité globale est déterminée en fonction des informations d’application et des informations du nœud terminal.
48. Procédé selon la revendication 40, dans lequel les informations d’application comprennent au moins l’un d’un paramètre de la qualité du flux de données et d’un paramètre de l’importance du flux de données apparentés à un ou plusieurs de l’au moins un flux de données associé à une application correspondante.
49. Procédé de la revendication 40, dans lequel une pondération est appliquée à chaque paramètre de qualité du flux de données lors de la détermination de la valeur globale du paramètre de qualité, et dans lequel chaque pondération est basée sur au moins une valeur de contrat de niveau de service (SLA), une valeur de la qualité du service (QoS) et d’un paramètre de l’importance du flux de données.
50. Procédé de la revendication 40, dans lequel la valeur du paramètre de la qualité globale est basée sur un paramètre de qualité du flux de données pour chacun d’un sous-ensemble de l’au moins un flux de données d’application associé au nœud d’accès (275, 475).
51. Procédé de la revendication 44, dans lequel le choix de l’au moins une option d’atténuation est réalisé si la valeur globale du paramètre de qualité reste en dessous du seuil pour une durée de temps minimale.
52. Procédé de la revendication 43, dans lequel l’initiation de l’au moins une option d’atténuation comprend l’envoi d’un message d’instruction d’atténuation à l’un de l’au moins un nœud terminal (255, 455) qui est associé au flux de données d’application sur lequel l’option d’atténuation doit être implémentée.
53. Procédé de la revendication 52, dans lequel le message d’instruction de l’atténuation comprend au moins une de la valeur du paramètre de la qualité globale et une durée de temps pendant laquelle la valeur du paramètre de la qualité globale est restée en dessous du seuil.
54. Procédé de la revendication 40, dans lequel l’au moins une option d’atténuation comprend un ou plusieurs parmi l’étape de retarder les paquets de données, rejeter les paquets de données, retarder les accusés de réception, rejeter les accusés de réception, retarder les demandes d’initiation de nouveaux flux de données, rejeter les demandes d’initiation de nouveaux flux de données, mettre fin à une application, et ne prendre aucune action.
55. Procédé de la revendication 40, dans lequel le choix d’au moins une option d’atténuation associée à un ou plusieurs de l’au moins un flux de données d’application est basé en partie sur le paramètre de l’importance du flux de données pour chacun de l’au moins un flux de données d’application.
56. Procédé de la revendication 43, dans lequel l’au moins une option d’atténuation choisie est implémentée en fonction de la durée de temps pendant laquelle la valeur du paramètre de la qualité globale est en-dessous d’un seuil.
57. Procédé de la revendication 43, dans lequel l’au moins une option d’atténuation choisie est implémentée en fonction de la valeur du paramètre de la qualité globale.
58. Procédé pour la gestion de la qualité de l’application dans un nœud terminal (255, 455) à l’intérieur d’un réseau de communication, le procédé comprenant : la détection de l’au moins un flux de données d’application en surveillant les paquets de données envoyées vers, et provenant de, un nœud d’accès (275, 475) via un réseau de communication ; la détermination, pour chacun de l’au moins un flux de données d’application détecté, des informations d’application apparentée à une application fonctionnant dans le nœud terminal (255, 455) qui est associé au flux de données d’application respectif, les informations d’application comprenant un paramètre de la qualité du flux de données pour chaque flux de données d’application respectif ; l’envoi, via le réseau de communication, des informations d’application pour chacun de l’au moins un flux de données d’application détecté ; la réception, via le réseau de communication, d’au moins une instruction d’atténuation associée à un ou plusieurs de l’au moins un flux de données d’application ; l’implémentation de l’au moins une instruction d’atténuation pour l’un ou les plusieurs de l’au moins un flux de données d’application associé caractérisé en ce que l’au moins une instruction d’atténuation comprend au moins l’une d’une valeur du paramètre de la qualité globale et d’une durée de temps pendant laquelle la valeur du paramètre de la qualité globale et en dessous d’un seuil, et dans lequel l’implémentation de l’au moins une instruction d’atténuation comprend la détermination d’une action d’atténuation basée sur l’au moins une valeur du paramètre de la qualité globale et de la durée de temps.
59. Procédé de la revendication 58, dans lequel le réseau de communication est un parmi un réseau de communication sans fil est un réseau de communication câblé.
60. Procédé selon la revendication 58, dans lequel les informations d’application pour chacun de l’au moins un flux de données d’application détecté sont déterminés au moins en partie en fonction de un ensemble de données des caractéristiques du nœud terminal actuel.
61. Procédé de la revendication 58, dans lequel les informations d’application sont envoyées vers le nœud d’accès (275, 475) pour le transfert à partir du nœud d’accès (275, 475) vers un nœud de gestionnaire d’application.
62. Procédé de la revendication 58, comprenant également l’étape de classification d’un ou plusieurs de l’au moins un flux de données d’application détecté en inspectant un ou plusieurs paquets de données associés au flux de données d’application respectif et en attribuant une valeur de classe d’application au flux de données d’application en fonction de l’inspection de l’un ou plusieurs paquets de données, et incluant la valeur de la classe d’application dans les informations d’application pour le flux de données d’application respectif.
63. Procédé de la revendication 58, dans lequel la détermination des informations d’application pour chaque flux de données d’application comprend la détermination d’un paramètre de l’importance du flux de données pour le flux de données d’application et l’inclusion du paramètre de l’importance du flux de données dans les informations d’application pour le flux de données d’application.
64. Procédé de la revendication 63, comprenant également l’étape de génération d’au moins un d’un ensemble de données des caractéristiques de l’application actuelle pour chacun de l’au moins un flux de données d’application basé sur les caractéristiques actuelles d’une application associée au flux de données d’application respectif, et un ensemble de données des caractéristiques du nœud terminal actuel basé sur les caractéristiques actuelles du nœud terminal (255, 455).
65. Procédé de la revendication 64, dans lequel le paramètre de l’importance du flux de données est basé au moins en partie sur l’ensemble de données des caractéristiques de l’application actuelle et de l’ensemble de données des caractéristiques du nœud terminal actuel.
66. Procédé de la revendication 64, dans lequel l’ensemble de données des caractéristiques de l’application actuelle comprend au moins une ou plusieurs d’une valeur de la classe d’application, une valeur du type d’initiation du flux, d’une valeur de la mise à jour en attente, d’une valeur de la position d’affichage, d’une valeur de la qualité de service du réseau (QoS) et d’une valeur de la marge de la mise en mémoire.
67. Procédé selon la revendication 64, dans lequel l’ensemble de données des caractéristiques du nœud terminal actuel comprend au moins une ou plusieurs parmi une valeur de l’attention de l’utilisateur et une valeur du contrat du niveau de service (SLA) et un type de nœud terminal.
68. Procédé de la revendication 63, dans lequel le paramètre de la qualité du flux de données est basé au moins en partie sur une indication de paquets de données manquants ou retardés associés au flux de données d’application.
69. Procédé de la revendication 63, dans lequel le paramètre de qualité du flux de données est basé en partie au moins sur une valeur du paramètre de la qualité de l’application provenant de l’application fonctionnant dans le nœud terminal (255, 455) qui est associé au flux de données d’application correspondant.
70. Procédé de la revendication 58, dans lequel les informations d’application pour chaque flux de données d’application comprend au moins l’un d’un ensemble de données des caractéristiques d’application apparenté au flux de données et d’un ensemble de données des caractéristiques du nœud terminal.
71. Procédé de la revendication 58, dans lequel les informations d’application sont envoyées du nœud terminal (255, 455) vers le nœud d’accès (275, 475) selon l’une d’une base périodique et apériodique.
72. Procédé de la revendication 58, dans lequel les informations d’application comprennent également l’une ou plusieurs d’une identification du nœud terminal associée au nœud terminal (255, 455), une identification de cellule associée au nœud d’accès (275, 475), et une valeur de paramètre de relais.
73. Procédé de la revendication 58, dans lequel l’au moins une instruction d’atténuation comprend une ou plusieurs d’une instruction de retard d’un paquet de données, une instruction rejet de paquets de données, une instruction de retard d’accusé de réception, une instruction de rejet d’accusé de réception, une instruction de retard de la demande d’un nouveau flux de données, une instruction de rejet de la demande d’un nouveau flux de données et une instruction de terminaison d’une application.
74. Procédé de la revendication 58, dans lequel l’implémentation de l’au moins une instruction d’atténuation est basée au moins en partie sur un paramètre de l’importance du flux de données pour chacun de l’au moins un flux de données d’application.
75. Procédé de la revendication 74, dans lequel l’au moins une instruction d’atténuation est implémentée sur le flux de données d’application ayant le paramètre de l’importance du flux de données le plus bas, et elle est ensuite successivement implémentée pour au moins un autre flux de données d’application ayant le deuxième paramètre de l’importance du flux de données le plus bas.
76. Procédé de la revendication 58, dans lequel l’au moins une instruction d’atténuation est implémentée sur un nombre croissant des flux de données d’application associés lorsqu’une durée de temps de l’implémentation augmente.
77. Procédé de la revendication 58, dans lequel l’au moins une option d’atténuation est implémentée en fonction d’une durée de temps pendant laquelle la valeur du paramètre de la qualité globale est en-dessous d’un seuil.
78. Procédé de la revendication 58, dans lequel le niveau d’implémentation de l’au moins une instruction d’atténuation est basée sur la valeur du paramètre de qualité.