FR 3053202 A1 20171229 FR 1655908 A 20160624 PROCEDE DE GESTION DE L'ETAT DE VEILLE D'UN TERMINAL MOBILE L'invention se situe dans le domaine général des télécommunications, et concerne plus particulièrement les communications d'un terminal mobile avec un réseau de paquets de données (« Packet Data Network », ou PDN en anglais) via un réseau d'accès cellulaire. Dans le cadre de la présente invention, on désigne par « terminal mobile » tout objet portatif apte à participer à des communications sans-fil. Ce terminal mobile pourra, par exemple, être un téléphone mobile, ou un ordinateur portable, ou une tablette numérique. Ce terminal mobile peut être connecté et enregistré auprès d'un coeur de réseau IP (Internet Protocol) par le biais d'un type d'accès quelconque, tel qu'un réseau GSM (Global System for Mobile Communications), un réseau UMTS (Universal Mobile Telecommunications System), un ensemble de lignes DSL (Digital Subscriber Line), un réseau Ethernet (norme ISO/IEC 8802-3), un réseau WiFi (norme IEEE 802.11), ou un réseau LTE (Long Term Evolution). L'invention concerne, encore plus particulièrement, le passage du mode « veille » au mode « connecté » pour un terminal mobile. On rappelle que le « mode veille » consiste pour un terminal mobile à désactiver une partie de ses fonctionnalités, pour économiser son énergie et les ressources radio de la cellule dans laquelle il se situe, mais sans que le coeur de réseau ne libère la session de connectivité ; plus précisément, lorsqu'un terminal mobile est en veille, le coeur de réseau conserve le contexte de la session (adresse IP, informations de souscription, clés secrètes, et ainsi de suite), et connaît la localisation du terminal mobile avec un niveau de précision correspondant à une certaine zone appelée « TA-list » (voir détails ci-dessous). Lorsque le coeur de réseau reçoit un paquet de données destiné à un terminal mobile en veille, le réseau envoie un ou plusieurs messages dits de « paging » dans ladite zone TA-list ; or bien qu'étant en veille, le terminal mobile reste à l'écoute des messages de paging ; lorsqu'il reçoit un message de paging, il passe du mode « veille » au mode « connecté », et peut donc recevoir ledit paquet de données. L'invention peut notamment être mise en oeuvre dans une architecture de type EPC (Evolved Packet Core), telle que définie par le 3GPP (Third Generation 3053202 2 Partnership Project) à partir de la « Release 8 ». La figure 1 représente schématiquement cette architecture EPC, à laquelle on a connecté, à titre d'exemples, différents types de réseaux d'accès mobiles, tels que GERAN (GSM EDGE Radio Access Network) pour le GSM, UTRAN (Universal Terrestrial Radio 5 Access Network) pour l'UMTS, ou E-UTRAN pour la LTE. L'architecture EPC comprend trois principaux noeuds : un MME (initiales des mots anglais « Mobility Management Entity » signifiant « Entité de Gestion de Mobilité »), un S-GW (initiales des mots anglais « Serving Gateway » signifiant « Passerelle de Service »), et une passerelle P-GW (initiales des mots 10 anglais « Packet Data Network-Gateway » signifiant « Passerelle de Réseau de Paquets de Données »). Le rôle de ces noeuds est le suivant : - le MME est une entité du plan de contrôle (signalisation), dont le rôle principla est de gérer les procédures de mobilité (signalisation entre les noeuds du réseau coeur et avec les noeuds du réseau d'accès pour la mobilité) ; 15 - le S-GW assure notamment l'ancrage du média lorsque le mobile change de point d'accès radio en cours de session ; il assure également des fonctionnalités de comptage et la mise en mémoire tampon du média destiné à un utilisateur final lorsque la connectivité radio n'est pas encore établie ; - le P-GW fournit notamment la connectivité IP aux utilisateurs finals (par 20 exemple en attribuant des adresses IP), ainsi que des fonctionnalités de comptage, et d'application de politiques avancées de Qualité de Service (« Quality of Service », ou QoS, en anglais). Dans ce cadre, le document de spécification « TS 23.203 » du groupe de normalisation 3GPP, version 13.7.0, définit une architecture dite « architecture 25 PCC » (initiales des mots anglais « Policy and Charging Control ») visant à permettre un contrôle dynamique des ressources réseau en fonction d'informations collectées par une entité de contrôle dite « entité PCRF » (initiales des mots anglais « Policy and Charging Rules Function »). Ces informations peuvent être des informations associées au réseau (par exemple le type d'accès 30 radio, des adresses de passerelles, ou la localisation du client), associées à un abonné (par exemple, des informations de souscription), ou encore associées à une application (par exemple, le type d'application, ou le type de média). L'entité PCRF adapte et contrôle ainsi l'usage des ressources réseau en fonction 3053202 3 notamment de services requis par l'abonné et de son profil d'abonné. Pour cela l'entité PCRF fournit à une entité d'application de règles de contrôle, dite « entité PCEF » (initiales des mots anglais « Policy and Charging Enforcement Function »), des règles de contrôle d'une session de communication entre un 5 terminal mobile et un réseau de communication. Ces règles de contrôle sont communément appelées « règles PCC ». L'entité PCEF est souvent constituée par un module de la passerelle P-GW (mentionnée ci-dessus), qui est alors contrôlée par le PCRF. Lors de l'ouverture d'une session de connectivité IP (« IP CAN 10 session »), le PCEF (P-GW) ouvre une session de commande associée vers le PCRF, et lui communique les caractéristiques demandées pour cette session de connectivité. En fonction de ces caractéristiques et d'autres informations provenant de plusieurs autres sources, le PCRF détermine la politique (qualité de service, tarification à mettre en place, autorisation d'accès, et ainsi de suite) à 15 appliquer pour les différents services disponibles via la session en cours. Cette politique peut être modifiée en cours de session si certains événements, paramétrés par l'opérateur, se produisent durant la session. En fonction des règles de tarification envoyées par le PCRF, le PCEF décide ou non d'ouvrir une session avec une entité, dite entité OCS (initiales des mots anglais « Online 20 Charging System »), en charge de contrôler en temps réel le crédit de l'abonné. Selon la dernière « Release » des spécifications publiées par le 3GPP, en particulier la spécification TS 23.203, il est possible d'activer un évènement déclencheur au niveau du PCEF (P-GW) reposant sur la modification des données de localisation de l'utilisateur. Lorsque cet élément déclencheur est 25 armé, les messages de signalisation échangés entre le MME, le S-GW et le P- GW pour la gestion de la session de connectivité (création, modification, fermeture) doivent indiquer la localisation de l'utilisateur, et le MME doit générer une modification de « l'IP-CAN session » dès que la localisation de l'utilisateur change. Ainsi, le PCEF (PGW) peut informer le PCRF en temps réel du 30 changement de localisation de l'utilisateur via la session de contrôle associée à la session de connectivité. Le PCRF peut alors, en fonction de sa configuration, décider par exemple d'une modification de QoS (par exemple, de bande 3053202 4 passante) ou de tarification en fonction de la localisation de l'utilisateur, et cela en temps réel. Les spécifications 3GPP prévoient plusieurs niveaux de granularité de localisation : 5 - niveau cellule (identifiée par un identifiant « cell id ») : c'est la granularité de localisation la plus fine ; - niveau zone géographique (identifiée par une « tracking area », notée « TA ») : une TA couvre une ou plusieurs cellules (selon la densité de la zone) ; et 10 - niveau liste de zones géographiques (« tracking area list », notée « TA- list »). Chaque point d'accès d'un réseau mobile diffuse régulièrement un signal d'identification TAI (Tracking Area Identity) de la TA desservie par ce point d'accès, et chaque terminal mobile prend en compte l'identité de la TA dans 15 laquelle il se trouve, qu'il soit connecté ou en veille. Par ailleurs, lorsqu'un terminal mobile s'attache au réseau, le réseau l'enregistre dans une ou plusieurs TA comprenant la TA dans laquelle il se trouve, et lui fournit, au moyen d'un message « Attach Accept », la TA-list dans laquelle il est enregistré ; de même, lorsqu'un terminal mobile change de TA et que la nouvelle TA ne figure pas dans 20 la TA-list dans laquelle il est enregistré, le réseau l'enregistre dans une ou plusieurs TA comprenant la (nouvelle) TA dans laquelle il se trouve, et lui fournit, au moyen d'un message « TAU accept », la TA-list dans laquelle il est enregistré. Cette TA-list est prise en compte par le terminal mobile, qu'il soit connecté ou en veille. 25 Lorsqu'un terminal mobile en mode « veille » entre dans une TA ne faisant pas partie de la TA-list dans laquelle il est enregistré, il le notifie au réseau par l'envoi d'un message « Tracking Area Update », noté « TAU » ; pour ce faire, il repasse en mode « connecté », c'est-à-dire qu'il réactive ses ressources de communication radio. En revanche (toujours en mode « veille »), 30 dans le cas d'un changement de cellule ou de changement de TA au sein de la même TA-list, le terminal mobile n'émet pas cette notification (le réseau aurait été notifié du changement de localisation si le terminal mobile avait été en mode « connecté »). 3053202 5 Par ailleurs, la spécification TS 23.401 du 3GPP, version 13.1.0, définit une procédure de signalisation de présence dans une zone de signalisation de présence prédéfinie, dite zone PRA (initiales des mots anglais « Presence Reporting Area »), constituée d'une ou plusieurs zones géographiques TA. Cette 5 procédure, dite « procédure PRA », vise à réduire le trafic réseau dû à un changement de localisation d'un terminal mobile en évitant une notification systématique de ce changement vers différentes entités du réseau. Selon cette procédure, un changement de localisation est notifié seulement lorsque le terminal mobile entre ou sort de l'une desdites zones PRA. Cette procédure PRA 10 est susceptible d'être gérée par le PCRF ou par l'entité OCS (mentionnée ci- dessus). Lorsque cette procédure PRA est gérée par le PCRF, celui-ci détermine, à l'aide des informations de souscription de l'abonné, si la session de connectivité à établir nécessite l'activation de la signalisation de présence. Si tel 15 est le cas, l'entité de contrôle PCRF envoie à l'entité d'application de règles PCEF un identifiant de zone de signalisation de présence associé à l'abonné, lors de l'envoi des règles de contrôle à cette même entité. L'identifiant indique ainsi à l'entité d'application de règles PCEF que la signalisation de présence doit être activée, c'est-à-dire que l'entité de contrôle PCRF souhaite être notifiée 20 lorsque le terminal mobile entre ou sort de la zone de signalisation de présence associée à l'abonné. L'entité de gestion de crédits OCS peut uniquement dans ce cas demander à l'entité d'application de règles PCEF à être notifiée d'un changement de zone de signalisation de présence pour la même zone que l'entité de contrôle PCRF ; cela permet notamment d'éviter un conflit de zone de 25 signalisation de présence, pouvant par exemple affecter la facturation des usages de l'abonné. Lorsque la procédure PRA n'est pas gérée par le PCRF, l'entité de gestion de crédits OCS peut la gérer elle-même en envoyant à l'entité d'application de règles PCEF un identifiant de zone de signalisation de présence 30 défini localement. L'entité de gestion de crédits OCS active ainsi elle-même la signalisation de présence, et indique son souhait d'être notifiée lorsque le terminal mobile entre ou sort de la zone de signalisation de présence identifiée par l'identifiant envoyé à l'entité d'application de règles PCEF. 3053202 6 De nos jours, les opérateurs réseau souhaitent mettre en place des services publicitaires consistant à envoyer un certain message publicitaire aux utilisateurs entrant dans une certaine zone marchande (exemple, un centre commercial) ; naturellement, les commanditaires d'un tel service publicitaire 5 souhaitent que le message publicitaire soit envoyé à tous les terminaux entrant dans cette zone marchande. Conformément à la procédure PRA décrite ci-dessus, lorsqu'une entité PCRF détermine qu'un terminal mobile est concerné par une offre nécessitant une notification de localisation vers l'amont, le PCRF demande au PCEF (P-GW) 10 de lui notifier les changements de localisation pour ce terminal mobile lorsque ce dernier entre ou sort de l'ensemble de zones concernées par l'offre. Cette demande est ensuite transmise à l'entité S-GW puis à l'entité MME selon les procédures de création de session de connectivité IP (comprenant les messages « create session request » et « create session response ») décrites dans les 15 spécifications TS 23.401 et TS 29.274 du 3GPP. Cependant, comme expliqué ci-dessus, un terminal mobile en mode « veille » ne repasse en mode « connecté » que si le déplacement du terminal mobile entraîne une sortie du terminal mobile de la TA-list dans laquelle il est enregistré ; si la PRA concernée par l'offre est entièrement incluse dans la TA- 20 list, un terminal mobile en veille pourrait entrer ou sortir de cette PRA tout en restant dans la même TA-list, de sorte qu'il restera en veille et ne recevra pas le message publicitaire. La présente invention concerne donc, selon un premier aspect, un procédé de gestion de l'état de veille d'un terminal mobile dans un réseau de 25 paquets de données, comprenant les étapes suivantes : - lors de l'ouverture d'une session de connectivité pour un terminal mobile, une entité de gestion de mobilité dudit réseau reçoit une liste de zones, dite « PRA-list », configurée en fonction d'un service donné et de la localisation dudit terminal mobile, 30 - lorsque le terminal mobile passe du mode « connecté » au mode « veille », le terminal mobile reçoit ladite liste de zones « PRA-list » de la part de ladite entité de gestion de mobilité via un point d'accès du réseau, et 3053202 7 - lorsque le terminal mobile entre ou sort de l'une des zones formant la liste de zones « PRA-list », il passe du mode « veille » au mode « connecté », et envoie une notification à ladite entité de gestion de mobilité via un point d'accès du réseau. 5 Grâce à ces dispositions, on améliore la mise en oeuvre de services de diffusion de messages (par exemple publicitaires), en permettant aux terminaux en veille d'y accéder. Cela étant, le procédé selon l'invention évite de généraliser l'émission d'une notification vers l'amont de manière systématique : cette émission n'a lieu que pour des usages bien précis, tels qu'un service publicitaire 10 dans un centre commercial ; on protège ainsi le réseau d'une signalisation excessive. Selon un deuxième aspect, l'invention concerne divers dispositifs. Elle concerne ainsi, premièrement un terminal mobile. Ledit terminal mobile est remarquable en ce qu'il possède des moyens pour : 15 - recevoir, lorsqu'il passe du mode « connecté » au mode « veille », une liste de zones, dite « PRA-list », de la part d'une entité de gestion de mobilité via un point d'accès du réseau, et - lorsqu'il entre ou sort de l'une des zones formant ladite liste de zones « PRA-list », passer du mode « veille » au mode « connecté », et envoyer une 20 notification à ladite entité de gestion de mobilité via un point d'accès du réseau. L'invention concerne aussi, deuxièmement, une entité de gestion de mobilité d'un réseau de paquets de données. Ladite entité de gestion est remarquable en ce qu'elle possède des moyens pour envoyer à un point d'accès du réseau auquel est connecté un terminal mobile donné, lorsque ledit terminal 25 mobile passe du mode « connecté » au mode « veille », une liste de zones, dite « PRA-list », configurée en fonction d'un service donné et de la localisation du terminal mobile. L'invention concerne aussi, troisièmement, un noeud d'accès d'un réseau de paquets de données. Ledit noeud d'accès est remarquable en ce qu'il 30 possède des moyens pour envoyer à un terminal mobile, lorsque ledit terminal mobile passe du mode « connecté » au mode « veille », une liste de zones, dite « PRA-list », configurée en fonction d'un service donné et de la localisation du terminal mobile. 3053202 8 Les avantages offerts par ces dispositifs sont essentiellement les mêmes que ceux offerts par le procédé corrélatifs succinctement exposé ci-dessus. L'invention vise également un réseau de paquets de données, comprenant : 5 - au moins un terminal mobile tel que décrit succinctement ci-dessus, - au moins une entité de gestion tel que décrite succinctement ci-dessus, et - au moins un noeud d'accès tel que décrit succinctement ci-dessus. On notera qu'il est possible de réaliser ces dispositifs dans le contexte d'instructions logicielles et/ou dans le contexte de circuits électroniques. 10 L'invention vise également un programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur. Ce programme d'ordinateur est remarquable en ce qu'il comprend des instructions pour l'exécution des étapes du procédé de gestion de l'état de veille succinctement exposé ci-dessus, 15 lorsqu'il est exécuté sur un ordinateur. Les avantages offerts par ce programme d'ordinateur sont essentiellement les mêmes que ceux offerts par ledit procédé. D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée ci-dessous de modes de réalisation particuliers, donnés à 20 titre d'exemples non limitatifs. La description se réfère aux figures qui l'accompagnent, dans lesquelles : - la figure 1 représente une architecture de réseau classique de type EPC, - la figure 2 représente schématiquement la procédure classique dite de « S1 release », et 25 - la figure 3 représente une procédure de mise en veille d'un terminal mobile selon un mode de réalisation de l'invention. On va décrire à présent un mode de réalisation de l'invention qui utilise une procédure de mise en veille d'un terminal mobile représentant une évolution d'une procédure classique dite « S1 release ». 30 Cette procédure « S1 release » est décrite dans la Section 5.3.5 de la spécification TS 23.401, v10.2.1, du 3GPP. Elle peut être par exemple initiée par un eNodeB (point d'accès du réseau E-UTRAN, connecté au S-GW via l'interface S1-U et au MME via l'interface S1-MME), ou par un MME. La procédure « S1 3053202 9 release » permet de relâcher tous les canaux virtuels (« bearers » en anglais) d'un terminal mobile sur l'interface S1-U, quel que soit le nombre de sessions IP et de canaux virtuels IP-CAN existants, qui sont néanmoins maintenus dans le coeur de réseau. 5 Comme illustré sur la figure 2, la procédure « Si release » classique comprend les étapes suivantes. Lors d'une étape E1, un MME reçoit (par exemple, de la part d'un eNodeB) une requête de mise en veille relative à un terminal mobile (noté UE pour « User Equipement », c'est-à-dire « dispositif-utilisateur », sur la figure 2) 10 situé dans la cellule desservie par cet eNodeB. Lors d'une étape E2, le MME envoie au S-GW une requête de libération des canaux virtuels (bearers) utilisés par ce terminal mobile. Lors d'une étape E3, le S-GW envoie un accusé de réception au MME. Lors d'une étape E4, le MME envoie un accusé de réception à l'eNodeB. 15 Lors d'une étape E5, l'eNodeB envoie au terminal mobile une notification de libération de leur connexion radio mutuelle, par exemple en utilisant le protocole de signalisation « Radio Resource Control » (RRC). Enfin, lors d'une étape E6, l'eNodeB envoie au MME une confirmation d'exécution de ladite libération de connexion. 20 On va décrire à présent, en référence à la figure 3, un mode de réalisation de l'invention. Selon une première phase, lors de l'ouverture d'une session de connectivité (IP CAN session) pour un terminal mobile, le PCRF transmet au MME (via le P-GW et le S-GW) une liste de zones, que l'on appellera « PRA- 25 list », configurée en fonction d'un service particulier de diffusion de messages (par exemple de messages publicitaires) visant un ensemble de terminaux mobiles. Le PCRF doit préciser aussi les zones PRA pour lesquelles il souhaite être notifié, que le terminal mobile soit en mode « veille » ou en mode « connecté ». 30 Cette liste de zones peut par exemple être commodément construite en fonction de la localisation du terminal mobile. De préférence, l'ensemble de zones figurant dans cet « PRA-list » est strictement inclus dans la TA-list où le terminal mobile est enregistré. Il peut s'agir d'un nombre réduit de zones de cette 3053202 10 TA-list proches de la position du terminal mobile, la probabilité que le terminal mobile entre dans une zone plus éloignée sans être entre-temps repassé en mode « connecté » étant jugée faible. Lors d'une deuxième phase, le terminal mobile passe du mode 5 « connecté » au mode « veille ». Cette deuxième phase comprend les étapes suivantes. Les étapes El à E'3 sont identiques aux étapes El à E3 décrites ci-dessus en référence à la figure 2. Lors d'une étape E'4, le MME envoie un accusé de réception à l'eNodeB 10 comme dans la procédure classique, mais en y incluant une liste de zones, que l'on appellera « PRA-list ». Lors d'une étape E'5, l'eNodeB envoie au terminal mobile une notification de libération de leur connexion radio mutuelle comme dans la procédure classique, mais en y incluant ladite liste de zones « PRA-list », qui est alors 15 enregistrée par le terminal mobile. A cet égard, il importe de noter que, dans la procédure « Si release » classique, aucune liste de zones (pas même la TA-list) n'est transmise au terminal mobile. Enfin, lors d'une étape E'6, l'eNodeB envoie au MME une confirmation d'exécution de ladite libération de connexion, comme dans la procédure 20 classique. Lors d'une troisième phase, lorsque le terminal mobile entre ou sort de l'une des zones formant la « PRA-list », il passe du mode « veille » au mode « connecté », et notifie le MME (par exemple au moyen d'un message TAU classique, via l'eNodeB). Le MME notifie alors le PCRF selon la procédure 25 classique. L'invention peut être mise en oeuvre au sein des noeuds de réseaux de communication, par exemple des terminaux mobiles, des entités de gestion de mobilité ou des points d'accès réseau, au moyen de composants logiciels et/ou matériels. 30 Les composants logiciels pourront être intégrés à un programme d'ordinateur classique de gestion de noeud de réseau. C'est pourquoi, comme indiqué ci-dessus, la présente invention concerne également un système informatique. Ce système informatique comporte de manière classique une unité 3053202 11 centrale de traitement commandant par des signaux une mémoire, ainsi qu'une unité d'entrée et une unité de sortie. De plus, ce système informatique peut être utilisé pour exécuter un programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé de gestion de l'état de veille selon l'invention. 5 En effet, l'invention vise aussi un programme d'ordinateur téléchargeable depuis un réseau de communication comprenant des instructions pour l'exécution des étapes d'un procédé de gestion de l'état de veille selon l'invention, lorsqu'il est exécuté sur un ordinateur. Ce programme d'ordinateur peut être stocké sur un support lisible par ordinateur et peut être exécutable par 10 un microprocesseur. Ce programme peut utiliser n'importe quel langage de programmation, et se présenter sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. 15 L'invention vise aussi un support d'informations, inamovible, ou partiellement ou totalement amovible, lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comprendre un 20 moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou un moyen d'enregistrement magnétique, tel qu'un disque dur, ou encore une clé USB (« USB flash drive » en anglais). D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble 25 électrique ou optique, par radio ou par d'autres moyens. Le programme d'ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. En variante, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour 30 être utilisé dans l'exécution du procédé de gestion de l'état de veille selon l'invention. REVENDICATIONS1. Procédé de gestion de l'état de veille d'un terminal mobile dans un réseau de paquets de données, comprenant les étapes suivantes : - lors de l'ouverture d'une session de connectivité pour un terminal mobile, une entité de gestion de mobilité (MME) dudit réseau reçoit une liste de zones, dite « PRA-list », configurée en fonction d'un service donné et de la localisation dudit terminal mobile, - lorsque le terminal mobile passe du mode « connecté » au mode « veille », le terminal mobile reçoit ladite liste de zones « PRA-list » de la part de ladite entité de gestion de mobilité (MME) via un point d'accès du réseau, et - lorsque le terminal mobile entre ou sort de l'une des zones formant la liste de zones « PRA-list », il passe du mode « veille » au mode « connecté », et envoie une notification à ladite entité de gestion de mobilité (MME) via un point d'accès du réseau. 2. Terminal mobile, caractérisé en ce qu'il possède des moyens pour : - recevoir, lorsqu'il passe du mode « connecté » au mode « veille », une liste de zones, dite « PRA-list », de la part d'une entité de gestion de mobilité (MME) via un point d'accès du réseau, et - lorsqu'il entre ou sort de l'une des zones formant ladite liste de zones « PRA-list », passer du mode « veille » au mode « connecté », et envoyer une notification à ladite entité de gestion de mobilité (MME) via un point d'accès du réseau. 3. Entité de gestion de mobilité (MME) d'un réseau de paquets de données, caractérisée en ce qu'elle possède des moyens pour envoyer à un point d'accès du réseau auquel est connecté un terminal mobile donné, lorsque ledit terminal mobile passe du mode « connecté » au mode « veille », une liste de zones, dite « PRA-list », configurée en fonction d'un service donné et de la localisation du terminal mobile. 4. Noeud d'accès d'un réseau de paquets de données, caractérisé en ce qu'il possède des moyens pour envoyer à un terminal mobile, lorsque ledit 3053202 13 terminal mobile passe du mode « connecté » au mode « veille », une liste de zones, dite « PRA-list », configurée en fonction d'un service donné et de la localisation du terminal mobile. 5 5. Réseau de paquets de données, caractérisé en ce qu'il comprend : - au moins un terminal mobile selon la revendication 2, - au moins une entité de gestion de mobilité selon la revendication 3, et - au moins un noeud d'accès selon la revendication 4. 10 6. Moyen de stockage de données inamovible, ou partiellement ou totalement amovible, comportant des instructions de code de programme informatique pour l'exécution des étapes d'un procédé de gestion de l'état de veille selon la revendication 1. 15 7. Programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions pour l'exécution des étapes d'un procédé de gestion de l'état de veille selon la revendication 1, lorsqu'il est exécuté sur un ordinateur. 20