Brevet FR2999376A1 — publié le 20140613

Procédé de communication pour router des flux IP entre des terminaux mobiles et des entités destinataires distantes Domaine de l'invention L'invention se situe dans le domaine des télécommunications et plus particulièrement des réseaux mobiles. La présente invention concerne de manière générale les techniques d'identification de canaux logiques utilisés dans les réseaux mobiles et de transmission mises en jeu au niveau des couches transport d'un réseau de communication. L'invention trouve une application en particulier dans les réseaux mobiles LTE (dit 4G) puis LTE-adv qui se concrétisent par des normes élaborées par le 3GPP qui définissent en particulier l'accès radio connu sous les termes E-UTRAN. Les évolutions de l'accès radio se sont accompagnées d'évolutions de la partie non radio du système connue sous l'appellation SAE (System Architecture Evolution) ou réseau coeur EPC (Evolved Packet Core). L'EPS (Evolved Packet System) couvre les parties LTE (accès radio) et EPC. Parmi ces normes, la norme TS 23 401 spécifie les aspects liés à la connectivité IP d'un terminal connecté au réseau via un réseau d'accès mobile E-UTRAN. L'architecture de base de l'E-UTRAN est illustrée par la figure 1. Elle consiste en des points d'accès eNBs interconnectés entre eux et connectés au moyen d'une interface S1-MME à l'entité de gestion de la mobilité MME et à une passerelle serveuse S-GW au moyen d'une interface Si-U. La figure 2 est une illustration plus détaillée de l'architecture générale avec les différentes entités et les interfaces entre ces entités. On distingue le terminal UE, la passerelle serveuse S-GW, l'entité MME de gestion de la mobilité, l'entité P-GW qui est une passerelle vers le réseau de paquets PDN (Packet Data Network), l'entité PCRF qui gère les règles de taxation et de qualité de service, le serveur HSS de l'opérateur d'accès (Home Subscriber Server) qui centralise les références des clients et les services auxquels ils ont souscrits ainsi qu'éventuellement des informations de sécurité. L'EPS utilise des canaux logiques (EPS-Bearers) pour router du trafic IP depuis une passerelle P-GW connectée au réseau PDN de données paquets jusqu'à un terminal UE et depuis le terminal jusqu'à une telle passerelle qui correspondent à une connexion logique entre deux points de terminaison. Lors du transport des paquets d'un flux entre un terminal UE et une passerelle P-GW, le canal logique (EPS-Bearer) associé traverse plusieurs interfaces comme illustré par la figure 3 : l'interface radio ou interface Uu, l'interface S1 entre le point d'accès eNB et la passerelle serveuse S-GW et l'interface S5/S8 entre la passerelle serveuse S-GW et la passerelle P-GW. A chaque interface, l'entité de transmission effectue une association entre le canal logique (EPS bearer) et un canal logique (bearer) associé à une couche plus basse et conserve les identifiants des différents tunnels GTP (bearer IDs) sur ces deux interfaces. L'identifiant d'un canal logique est attribué par la MME. L'architecture au niveau protocole distingue entre le plan utilisateur (user plane) et le plan de contrôle (control plane). La figure 4 représente le plan de contrôle entre le terminal UE et l'entité MME. Les protocoles NAS sont utilisés pour les échanges dans le plan de contrôle concernant les fonctions de gestion de mobilité et pour l'activation, la desactivation et la modification des canaux logiques (bearer) utilisés dans le plan utilisateur. La figure 5 représente le plan utilisateur entre un terminal UE et une passerelle P- GW. La couche IP est ininterrompue et correspond à une connectivité IP entre l'UE et la P-GW. Un paquet IP est encapsulé lors du transport entre le terminal et la passerelle PGW selon un protocole qui peut varier en fonction des couches de transport disponibles sur l'entité traversée. Au niveau du terminal et du point d'accès, les trois couches PDCP, RLC et MAC sont connues comme formant la couche 2 ou couches de transport radio entre la couche IP et la couche physique. La couche PDCP qui se termine au point d'accès eNB a pour principales fonctions la compression d'entête, la sécurité (chiffrement et protection de l'intégrité) et le support pour la retransmission durant le handover. Au-delà du point d'accès, le protocole GTP-U est utilisé au-dessus du protocole UDP/IP pour transporter les données du plan utilisateur dans un tunnel entre le point d'accès eNB et la passerelle serveuse S-GW. L'entité MME contrôle l'établissement des tunnels utilisés dans le plan utilisateur supportant les canaux logiques (bearers) entre le point d'accès eNB et la passerelle S-GW et entre la S-GW et la P-GW. Chaque canal logique (bearer) est identifié par l'identifiant d'un tunnel GTP établit entre deux entités. Les protocoles UDP/IP sont les protocoles de base du réseau de transport utilisés pour router les données et les signaux de contrôle du réseau mobile. Un point d'accès eNB accueille plusieurs fonctions dont des fonctions de gestion des ressources radio et en particulier le contrôle des canaux radio (Radio-Bearer). Le montage d'un canal logique (EPS-Bearer) intervient lors de la mise en route du terminal via une requête « Network attach » ou lors d'une requête de service « Service request » émanant du terminal. Ces requêtes interviennent dans le plan de contrôle et font partie de la signalisation entre le terminal UE et l'entité de gestion de la mobilité MME (signalisation NAS). Un canal logique (EPS-Bearer) transporte un flux IP entre le terminal et la passerelle P-GW, flux auquel est associée une qualité de service (QoS). On peut distinguer différents types de canaux logiques (EPS Bearer) : les canaux logiques à débit garanti (GBR EPS Bearer) et les canaux logiques à débit non garanti (non GBR EPS Bearer). Par exemple, un type de canal logique (EPS-Bearer QCI 1) est défini avec des paramètres de QoS pour supporter un service de voix sur IP (VoIP). Le LTE distingue neuf profils différents de QoS identifiés par l'identifiant QCI. Chaque profil est caractérisé par une priorité, un budget de temps de transmission (packet delay budget) et un taux de perte de paquet acceptable. L' appartenance à un même profil garantie donc un même traitement par les points d'accès eNBs entre différents flux en termes de priorité, de délai et de perte de paquet. Un canal logique (EPS-Bearer) ne peut être associé qu' à un seul et unique identifiant QCI. L'opérateur du réseau mobile décide comment utiliser les canaux logiques (EPSBearer) de types différents en fonction des différents services supportés et de leurs contraintes de QoS associées (SLA : Service Level Agreement).. Selon la norme LTE, il existe un canal logique (EPS-Bearer) par défaut avec un profil de QoS par défaut sans garantie de débit qui est celui monté lorsque le terminal s'attache au réseau. Plusieurs canaux logiques (EPS-Bearer) peuvent être montés pour un même terminal UE pour supporter des flux de différents profils de QoS associés à un ou plusieurs services ou pour supporter des connectivités avec plusieurs passerelles P-GW. Les entités qui supportent ces différents canaux logiques (EPS-bearer) appliquent donc des règles de traitement différentes en fonction uniquement des identifiants QCI de ces canaux logiques (EPS bearer). Les réseaux dits 4G, en particulier le LTE et le LTE-Adv présentent une différence notable avec un réseau UMTS dit 3G au niveau de la continuité des couches entre le réseau d'accès et le réseau de communication et des points de terminaison des fonctions. Art antérieur En comparant l'architecture du réseau d'accès d'un réseau UMTS avec celle d'un réseau LTE, il s'avère qu'il n'y a plus à partir de la version 8 (Release 8) dans un réseau d'accès LTE d'entité qui corresponde à l'entité de contrôle RNC du réseau d'accès UMTS. Cette entité RNC gère le chiffrement des données avec le terminal via la couche PDCP dans un réseau 3G. Cette entité RNC permet d' assurer la sécurité du transport des données échangées avec un terminal mobile. Dans le réseau LTE ces fonctions de sécurité ont leur point terminal dans le point d'accès eNB lui-même du réseau d'accès E-UTRAN. Or ce point d'accès eNB est localisé en un point géographique dont l'accès n'est pas toujours très contrôlé et sécurisé contrairement à l'entité RNC du réseau d'accès UMTS qui est situé dans les locaux de l'opérateur de ce réseau. Il existe donc un risque potentiel d'un acte malveillant consistant à espionner les interfaces d'un point d'accès eNB et à récupérer les données qui circulent en claire sur ces interfaces. Une solution radicale consiste à disposer les points d'accès eNB en des lieux totalement contrôlés et sécurisés hors de tout accès public. Une telle solution se heurte bien entendu au coût associé compte tenu que ces points d'accès doivent être largement déployés sur un territoire. Une telle solution peut être envisageable dans une zone de faible densité avec l'acquisition du terrain d'installation du point d'accès eNB mais dans une zone de forte densité il est difficile d'envisager d'interdire l'accès aux toits d'immeubles privatifs. La solution actuellement proposée et compatible des standards du 3GPP consiste à sécuriser toute donnée accessible en claire aux interfaces des points d'accès eNB. Une telle solution entraîne des coûts importants en termes de CAPEX et en termes d'OPEX. Le CAPEX correspond au coût de la fonction IPSec et de la passerelle Security GW et l'OPEX correspond à l'augmentation de trafic induite par la fonction IPSec du fait de l'ajout d'un entête pour encapsuler les données. Exposé de l'invention L'invention propose un procédé de communication mis en oeuvre dans un système de télécommunication comprenant un point d'accès et des entités de routage vers un réseau paquet pour router des flux IP entre des terminaux mobiles et des entités destinataires distantes. Le procédé comprend : - une identification d' au moins deux communautés de canaux logiques dites respectivement sécurisée et non sécurisée, une utilisation de canaux logiques appartenant à la communauté sécurisée pour transporter des flux IP déterminés entre un terminal et une entité destinataire, un montage et une utilisation d'un tunnel IPSec entre le point d'accès et une passerelle sécurisée en coupure dans le chemin de routage vers les entités de routage pour transporter le flux IP d'un canal logique uniquement si ce canal logique appartient à la communauté sécurisée. Selon un mode de réalisation particulier, un même tunnel IPSec est utilisé pour transporter des flux IP déterminés de différents terminaux vers une ou plusieurs entités destinataires. Selon un mode de réalisation particulier, le procédé comprend en outre : une identification de deux autres communautés de canaux logiques dites respectivement IPv4 et IPv6. Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels : la figure 1, déjà commentée en relation avec l'art antérieur, est une illustration de l'architecture de base de l'E-UTRAN et d'une partie de l'EPC, la figure 2 déjà commentée en relation avec l'art antérieur, est une illustration plus détaillée de l'architecture de base de l'E-UTRAN et de l'EPC, la figure 3 déjà commentée en relation avec l'art antérieur, est une illustration des interfaces traversées par un canal logique (EPS-Bearer), - la figure 4 déjà commentée en relation avec l'art antérieur, est une illustration du plan de contrôle entre le terminal UE et l'entité MME, la figure 5 déjà commentée en relation avec l'art antérieur, est une illustration du plan utilisateur entre un terminal UE et une passerelle P-GW, la figure 6 est un schéma du déroulement de la procédure d' attachement «Attach procedure », la figure 7 est un schéma du déroulement de la procédure de demande d'un service «Service request procedure». Description d'un mode de réalisation de l'invention Le principe général de l'invention repose sur la distinction de différentes communautés de canaux logiques (EPS bearer). Les canaux logiques sont mis en oeuvre dans le réseau mobile entre l'UE et la PGW pour transporter les données entre un utilisateur et un équipement distant mis en communication par un réseau d'accès et des entités de routage vers un réseau paquet. L'invention permet avantageusement de distinguer au moins deux communautés, une communauté de canaux logiques sécurisés et une communauté de canaux logiques non sécurisées. D' autres communautés peuvent être distinguées, par exemple une communauté de canaux logiques transportés sur le protocole IPv6 et une communauté de canaux logiques transportés sur IPv4. Dans ce cas une association entre les canaux logiques « IPv6 » et un plan de routage IPv6 est réalisée au niveau des équipements eNB, S-GW et P-GW. La communauté de canaux logiques sécurisés implique la mise en place d'un tunnel IPSec entre le point d'accès au réseau d'accès et une passerelle sécurisée SecurityGW (Security gateway). Ce type de tunnel est décrit en particulier dans le document IETF RFC2401. Il permet d'assurer un transport sécurisé entre deux entités distantes sur tout le chemin même si ce chemin passe par d'autres entités de routage. Un tel tunnel IPSec nécessite la mise en oeuvre d' algorithmes de cryptographie pour assurer l'authentification des entités, l'intégrité des données, le chiffrement des données. Ceci est très couteux particulièrement en bande passante et en ressources requises sur les deux entités. L'invention est extrêmement avantageuse car elle permet de limiter ces coûts (CAPEX et OPEX) au minimum en permettant de distinguer les canaux logiques qui nécessitent un transport sécurisé des données de ceux qui ne nécessitent pas une telle sécurité et ce, de façon très simple. L'invention permet ainsi de marquer les canaux logiques en fonction de leur appartenance à une des communautés et d'appliquer des règles de configuration spécifiques à ces communautés dans les noeuds du système de télécommunication LTE/EPC. L'invention permet en outre d'appliquer des règles de paiement spécifiques au traitement des canaux logiques appartenant à une communauté et donc de monétiser par client un service appliqué à ses canaux logiques établis entre le terminal UE et la passerelle P-GW. Par exemple, dans le cas de la sécurisation des données, l'utilisateur peut souscrire à un service payant qui permet de supporter l'investissement supplémentaire lié à l'utilisation d'une passerelle de sécurité Security GW. Le procédé de communication selon l'invention est mis en oeuvre dans un système de télécommunication comprenant un point d' accès et des entités de routage. Lorsque le système de télécommunication correspond à un système compatible des spécifications du 3GPP concernant l'E-UTRAN et l'EPC, le point d'accès est une entité eNB, et les entités de routage comprennent une passerelle serveuse S-GW et une passerelle P-GW vers un réseau paquet. Le système de télécommunication permet de router des flux IP entre des terminaux mobiles et des entités destinataires distantes. Le procédé comprend : une identification d'au moins deux communautés de canaux logiques (EPS bearer) dites respectivement sécurisée et non sécurisée, une utilisation de canaux logiques appartenant à la communauté sécurisée pour transporter des flux IP déterminés entre un terminal et une entité destinataire, un montage d'un tunnel IPSec entre le point d'accès et une passerelle sécurisée (Security GW) en coupure dans le chemin de routage vers les entités de routage pour transporter le flux IP d'un canal logique (EPS bearer) uniquement si ce canal logique appartient à la communauté sécurisée. L'appartenance à une communauté impacte deux procédures existantes spécifiées dans le standard TS 23 401, la procédure d'attachement «Attach procedure » spécifiée au paragraphe 5.3.2 et dont le déroulement est donnée à la figure 6 et la procédure de demande d'un service «Service request procedure» spécifiée au paragraphe 5.3.4 et dont le déroulement est donnée à la figure 7. Pour ces deux procédures, les règles locales appliquées par les noeuds du système de télécommunications sont détaillées ci-après. Les procédures « Network attach » et « Service request » sont initiées par le terminal UE et adressées vers l'entité de gestion de la mobilité MME. Lors du déroulement de ces procédures, l'entité des abonnées HSS (Home Subscriber Server) informe l'entité de gestion de la mobilité MME du fait que l'utilisateur a souscrit ou non à un service « communautaire » et si par conséquent le canal logique (EPS Bearer) à établir appartient à une communauté prédéfinie. Selon l'invention, un nouveau champ est défini dans les messages de dialogue entre l'entité de gestion de la mobilité MME et l'entité des abonnées HSS de la procédure «Network Attach». Plus particulièrement, en réponse à un message «Update Location Request» envoyé par la MME au HSS, le message «Update Location Ack » envoyé par le HSS à la MME comprend un champ Subscription data qui comprend au moins un contexte de souscription PDN (PDN subscription context) qui contient un profile de QoS (EPS subscribed QoS profile) avec en particulier le paramètre QCI du canal de transport (EPS Bearer) à établir. Selon l'invention ce dernier profil est modifié par l'ajout d'un champ relatif à la communauté à laquelle appartient le canal logique. En ce qui concerne la procédure «Service request», un échange de messages est réalisé également entre l'entité de gestion de la mobilité MME et l'entité de gestion de services des abonnées HSS. Cet échange est similaire à l'échange modifié « Update Location Request / Update Location Ack » de la procédure «network attach ». Dans le déroulement des procédures «Network Attach» et «Service request», l'entité de gestion de la mobilité MME informe le point d'accès eNB du fait que l'utilisateur a souscrit ou non à un ou des services de type communautaire, c'est-à-dire si le canal logique (EPS Bearer) à établir correspondant au service demandé appartient à une communauté prédéfinie. Selon l'invention, un nouveau champ est défini dans les messages de dialogue entre l'entité de gestion de la mobilité MME et l'eNB. Plus particulièrement, le message «Initial Context Setup Request » utilisé respectivement dans les procédures «Service request» et «Network Attach» est modifié pour comprendre outre un certain nombre de champs dont le champ « EPS Bearer QoS(s) » respectivement « EPS Bearer Identity », le champ relatif à la communauté à laquelle appartient le canal logique à établir. Ce champ sert à enrichir le profil utilisateur maintenu au niveau de l'eNB. Ce nouveau champ indiquant la communauté à laquelle appartient le canal logique est ajouté au message « Initial Context Setup Response » envoyé par l'eNB à la MME. Connaissant la communauté à laquelle appartient le canal logique, le point d'accès eNB peut alors monter un tunnel IPSec uniquement si cette communauté est la communauté sécurisée. L'utilisation du tunnel IPSec se fait avantageusement de manière dynamique à chaque demande de service se basant sur une communauté spécifique de canaux logiques par un terminal UE. Un tel procédé selon l'invention peut permettre de sécuriser des données de trafic Internet associé à une connexion à des services tels Facebook, Skype, Youtube pour lesquels les utilisateurs échangent des données personnelles en fonction des choix de l'utilisateur. Selon un mode de réalisation particulier, le procédé comprend en outre, lors de l'établissement d'un canal logique pour router un flux IP : un échange de messages entre une entité de gestion de la mobilité MME et une entité de gestion des services des abonnées HSS, l'entité de gestion de la mobilité MME et l'entité des abonnées HSS faisant partie du système de télécommunication, tel que : l'entité de gestion de la mobilité MME émet un message de requête de mise à jour de localisation «Update Location Request», l'entité de gestion des services des abonnées HSS répond avec un message de retour «Update Location Ack » qui comprend au moins un profil de QoS « EPS subscribed QoS profile » du canal logique EPS Bearer à établir, le profil comprenant un champ relatif à la communauté à laquelle appartient le canal logique à établir, et comprend en outre : un échange de messages entre l'entité de gestion de la mobilité MME et le point d'accès eNB au cours duquel l'entité de gestion de la mobilité MME informe le point d'accès eNB de la communauté à laquelle appartient le canal logique EPS Bearer à établir et de l'adresse IP de la passerelle sécurisée Security GW à utiliser dans le sens montant sur l'interface Si-U et au cours duquel le point d'accès eNB informe l'entité de gestion de la mobilité MME de la prise en compte de la communauté du canal logique avec l'adresse IP du tunnel entre le point d'accès eNB et une passerelle serveuse à utiliser dans le sens descendant sur l'interface Si-U. REVENDICATIONS1. Procédé de communication mis en oeuvre dans un système de télécommunication comprenant un point d'accès (eNB) et des entités de routage vers un réseau paquet pour router des flux IP entre des terminaux mobiles (UE) et des entités destinataires distantes, caractérisé en ce que le procédé comprend : une identification d' au moins deux communautés de canaux logiques (EPS bearer) dites respectivement sécurisée et non sécurisée, une utilisation de canaux logiques appartenant à la communauté sécurisée pour transporter des flux IP déterminés entre un terminal (UE) et une entité destinataire, un montage et une utilisation d'un tunnel IPSec entre le point d'accès et une passerelle sécurisée (Security GW) en coupure dans le chemin de routage vers les entités de routage pour transporter le flux IP d'un canal logique (EPS bearer) uniquement si ce canal logique appartient à la communauté sécurisée. 2. Procédé de communication selon la revendication 1 dans lequel un même tunnel IPSec est utilisé pour transporter des flux IP déterminés de différents terminaux (UE) vers une ou plusieurs entités destinataires. 3. Procédé de communication selon la revendication 1 comprenant en outre : une identification de deux autres communautés de canaux logiques dites respectivement IPv4 et IPv6. 4. Procédé de communication selon la revendication 1 comprenant en outre, lors de l'établissement d'un canal logique pour router un flux IP: un échange de messages entre une entité de gestion de la mobilité (MME) et une entité de gestion des services des abonnées (HSS), l'entité de gestion de la mobilité (MME) et l'entité des abonnées (HSS) faisant partie du système de télécommunication, tel que : l'entité de gestion de la mobilité (MME) émet un message de requête de mise à jour de localisation («Update Location Request»), l'entité de gestion des services des abonnées (HSS) répond avec un message de retour («Update Location Ack ») qui comprend au moins un profil de QoS (« EPS subscribed QoS profile ») du canal logique (EPS Bearer) à établir, le profil comprenant un champ relatif à la communauté à laquelle appartient le canal logique à établir, et comprenant en outre un échange de messages entre l'entité de gestion de lamobilité (MME) et le point d'accès (eNB) au cours duquel l'entité de gestion de la mobilité (MME) informe le point d'accès (eNB) de la communauté à laquelle appartient le canal logique (EPS Bearer) à établir et de l'adresse IP de la passerelle sécurisée (Security GW) à utiliser dans le sens montant sur l'interface si-U et au cours duquel le point d'accès (eNB) informe l'entité de gestion de la mobilité (MME) de la prise en compte de la communauté du canal logique avec l'adresse IP du tunnel entre le point d'accès (eNB) et une passerelle serveuse à utiliser dans le sens descendant sur l'interface Sl-U. 5. Procédé de communication selon la revendication 4 dans lequel l'échange de messages entre l'entité de gestion de la mobilité (MME) et le point d'accès (eNB) intervient lors d'une procédure d'attachement d'un terminal au point d'accès (eNB). 6. Procédé de communication selon la revendication 4 dans lequel l'échange de messages entre l'entité de gestion de la mobilité (MME) et le point d'accès (eNB) intervient lors d'une demande de service par un terminal (UE) ou par le réseau (MME). 7. Utilisation d'un procédé selon l'une des revendications 1 à 6 pour protéger des données liées à un service requis à partir d'un terminal mobile (UE), le service étant identifié dans l'entité de gestion des services des abonnées (HSS) comme appartenant à la communauté sécurisée pour un abonné associé au terminal (UE).20