Brevet FR2997812A1 — publié le 20140509

PROCEDE D'INITIALISATION D'APPEL RAPIDE D'APPLICATION DE TYPE PTT SUR UN RESEAUX CELLULAIRE IP-WAN Domaine de l'invention La présente invention se rapporte au domaine des systèmes numérique privés de radiocommunication mobile. Elle trouve des applications particulièrement avantageuses dans les systèmes privés de radiocommunication professionnelle (ou système KIR, pour Professional Mobile Radio en anglais). Ce système de radiocommunication selon l'invention a pour but de donner à des applications PTT (pour Push To Talk, en anglais), utilisant une infrastructure d'accès à un réseau de type radioélectrique, basé sur une technologie IP-WAN (pour IP Wide Area Network, en anglais) unicast, tel que la 3G-F, la 4G, et d'autres, la possibilité d'initialiser rapidement une communication. Etat de la techni ue et roblèmes techni - ues rencontrés Dans le domaine des systèmes numériques privés de radiocommunication mobile appelé par la suite système PrVIR, il existe une catégorie de terminaux mobiles utilisant une méthode de communication dite PTT (pour Push To Talk, ou Press To Transmit). Cette méthode de communication s'effectue sur une liaison half-duplex, et repose sur l'appui d'un bouton pour commuter le terminal PMR d'un état récepteur à un état émetteur de données, telles que la phonie, notamment, mais plus généralement de données de toute nature. On entend par liaison half-duplex un canal de communication permettant le transport de données delà les deux sens, mais pas simultanément, autrement dit, soit en lien montant (ou UpLink, en anglais) pour un canal de communication émis à partir du terminal, ou soit en lien descendant (ou Down-Link, en anglais), pour un canal de communication reçu par le terminal. La méthode de communication Push To Talk est un service vocal temps réel, implémenté sur un réseau de données par paquets. Ainsi, un terminal PTT assure une communication directe par appui d'une touche et permet d'établir une liaison avec un autre terminal ou avec un ensemble de terminaux Dans le cadre d'une utilisation pour des appels de groupe pouvant aller jusqu'à plusieurs centaines d'utilisateurs, une des principales contraintes d'un système PTT est de pouvoir être capable de supporter un temps de latence de 300ms entre un premier utilisateur effectuant un appel vocal en appuyant sur le bouton PTT et tous les autres utilisateurs recevant cet appel. Pour effectuer cet appel, il y a en premier lieu une première étape de signalisation, puis une deuxième étape de connexion des médias et enfin une troisième étape permettant à tous les utilisateurs habilités à être à l'écoute du média émetteur de l'appel, de recevoir le flux de ce dit appel correctement. Cette valeur de latence est indépendante de l'état de l'appel, et 10 toujours inférieure à la valeur maximale de 300ms. Cette valeur de latence peut même atteindre 500ms en cas de système multiple. En ce qui concerne, le principe actuel des PTT à bande étroite (ou Narrowband en anglais), tels que les technologies PTT P25, TETRA, ou TETRAPOL, cette valeur de 300ms est atteinte au moyen : 15 - d'une structure d'application qui manage la structure radio physique de la couche de liaison ; - de ressources physiques dédiées allouées par canal (TCHs ou Trunked CFlannels en anglais) ; - d'une ressource physique allouées pour la signalisation PTT, 20 notamment le CCH (Control Channel en anglais) en lien montant et en lien descendant ; - d'une bande de signalisation à l'intérieur des TCHs pour définir la rapidité du temps de signalisation pour de multiples utilisateurs ; - d'un lien montant dédié à chaque canal TCHs/CCH en mode 25 litigieux. Par conséquent, chaque canal alloué aux couches de liaison physique, permet d'atteindre les 300ms. En ce qui concerne, le principe actuel des PTT sur téléphone cellulaire ou PoC (pour PTT over Cellular en anglais) fonctionnant sur des 30 technologies à large bande ou BB (pour Broad Band en anglais), celui-ci ne répond pas aux contraintes de 300ms de temps réel. En effet, dans le cas d'un Poe fonctionnant sur un protocole OIVIA PoC, celui-ci est dépendant du temps de transport du flux. A l'heure actuelle, seules les technologies 3G+ et 4G offrent un temps de transport du flux 35 correct, mais pas suffisant pour atteindre tous les utilisateurs d'un groupe en respectant les 300ms. En effet, aucunes ressources du réseau IP-WAN et radio ne sont pré-affectées à une session OMA POC, puisque cela conduit à devoir rechercher le terminal mobile dans une zone connue par Pintermédiaire de l'envoi d'un message de paging sur le canal Paging Channel (PCH)), et de ce fait la valeur de latence de 300ms n'est pas atteinte pour tous les utilisateurs à leur activation. Il existe donc un besoin de fournir une solution technique permettant de garantir un temps de latence de 300ms pour rinitialisation d'un appel de groupe pour les PoC. EXPOSé de l'invention La présente invention vise à résoudre l'ensemble des inconvénients de l'état de la technique. Pour cela, l'invention propose un procédé d'initialisation d'appel rapide d'application de type PTT sur un réseau cellulaire IP-VVAN, selon l'une quelconque des caractéristiques de la revendication 1 et des revendications suivantes. L'invention est mise en oeuvre aux moyens d'attribution de ressources au niveau des applications tels que; - une session individuelle de signalisation pour la mono diffusion (Unicast en anglais) du lien montant UL et du lien descendant DL. Cette signalisation pouvant être basée sur n'importe quel protocole SIR (Session Initiation Protocol en anglais), permettant d'établir, modifier et terminer une session ; ou encore n'importe quel protocole basé ou non sur de l'IP (Internet Protocol en anglais) ; - une session individuelle Unicast d'un média en lien montant pour chaque utilisateur émetteur vocal (Talker en anglais) dans le groupe d'utilisateur, Dans le reste de la description, le terme média signifie que celui- ci contient une données à transmettre comme par exemple des paquets IP de voix, de vidéos, ou d'autres données ; - une session individuelle Unicast du média en lien descendant pour tous les utilisateurs récepteurs vocal (Listemers en anglais) dans le groupe 30 d'utilisateur. Les médias peuvent être supportés pour n'importe quel codec (Abréviation qui, dans le cadre de cette description, correspond à un logiciel apte à COder et à DECoder une (ou un ensemble de) donnée(s)) de voix, et transportés comme une donnée. En général, le média est supporté sur le 35 protocole IP/RTP (pour Real Time Protocol en anglais) ou tout autre protocole apte à supporter la voie en temps réel, pour la même qualité de service ou QoS (pour Quality of Service, en anglais). L'invention comporte également des moyens d'attribution de ressources au niveau du réseau étendu de transport ou WAN (pour Wide 5 Ares Network en anglais), tels que : - une signalisation Unicast UL/DL pour le canal de données ; - un média UL porteur de données pour l'utilisateur émetteur vocal (ou talker en anglais) ; - un média DL porteur de données pour chaque utilisateur récepteur 10 vocal (listener, en anglais). C'est le principe du multi-unicast, où chaque utilisateur d'un groupe d'appel est atteint par une méthode unicast, un serveur étant en charge pour le multi-unicast du flux à tous les utilisateurs récepteur du groupe d'appel. L'invention permet ainsi à chaque utilisateur de pouvoir se connecter à 15 un réseau de transport, de pouvoir s'enregistrer au service PTT et à d'autre type de services comme la vidéo si besoin. L'invention permet également à chaque utilisateur de pouvoir s'enregistrer à un ou plusieurs groupe(s) d'appel. Au moyen de l'invention, il est possible d'écouter un appel de groupe ainsi que ses activités radio. 20 L'utilisateur peut être le premier requérant de l'appel, par l'intermédiaire d'une procédure de signalisation PTT si l'appel n'a pas encore été initialisé. L'invention permet à l'utilisateur de recevoir le média ainsi que la signalisation. Elle permet également le changement du droit à la parole accordé à un utilisateur, sur requête des autres utilisateurs enregistrés dans 25 le groupe et d'un arbitrage au niveau du serveur PTT. L'invention a donc pour objet un procédé d'initialisation d'appel pour un terminal mobile comportant des applications de type PTT sur un réseau cellulaire IP-WAN, ledit procédé comportant les étapes suivantes, pour chaque utilisateur dudit terminal mobile connecté à un modem IP-WAN 30 destiné à s'enregistrer pour un appel de groupe : - une étape, s'enclenchant au démarrage du modem IP-WAN, durant laquelle s'effectue une procédure de connexion au réseau IP-WAN, - une étape, où lorsque le client PTT est actif, et qu'il a obtenu l'adresse IP du serveur PTT, le client PTT est apte à déclencher une 36 procédure d'enregistrement du SIP avec le serveur PTT sur la porteuse IPWAN par défaut, - une étape, où le client PTT procède à une procédure d'affiliation à un groupe d'appel avec le serveur PTT sur la porteuse IP-WAN par défaut, caractérisé en ce que, à - une étape, où dès que la procédure d'affiliation au groupe d'appel est effectuée, une procédure SIP « INVITE» est exécutée pour réserver des ressources RTP au niveau applicatif du côté du serveur PTT et du côté client PTT, de sorte à permettre la montée de la session RTP immédiatement après la procédure d'affiliation du client PTT au groupe. L'invention comporte également l'une quelconque des caractéristiques suivantes : - pour effectuer cette procédure SIP, le client PTT envoie un message d'invitation « SIP INVITE » pour son serveur PTT afin de requérir finitialisation d'une session RTP pour le média voix ; - l'étape, durant laquelle s'effectue une procédure de connexion au 15 réseau IP-WAN, comporte une phase d'authentification, permettant au modem IP-WAN d'être enregistré dans le réseau IP-WAN; - la procédure de connexion au réseau IP-WAN prévue à l'étape durant laquelle s'effectue une procédure de connexion au réseau IP-WAN permet au modem IP-WAN d'être accessible au moyen d'adresses IP 20 allouées et associées à une porteuse par défaut, avec un QCI définie dans le HSS ; - avant d'envoyer une inscription SIP au serveur PTT, le client PTT a la possibilité d'obtenir l'adresse IP du serveur PTT à partir du serveur MS ; - avant d'envoyer une inscription SIP au serveur PTT, le client PTT, à 25 la possibilité d'obtenir l'adresse IF du serveur PTT à partir d'une configuration manuelle ; - une fois que la session RTP et que le port RTP sont alloués au serveur PU, un message indiquant que le protocole SIP 200 est actif « SIP 200 OK » est envoyé au client PTT en incluant l'adresse IF et le port du 30 serveur PTT pour la session RTP; - un message de battement de coeur est échangé entre le serveur PTT et le client PTT pour maintenir la connexion active au niveau radio RRC IPWAN, pour maintenir la session applicative RTP active et pour effectuer une supervision entre le client PTT et le serveur ; 35 - la session RTP reste active entre le serveur PTT et le client PTT jusqu'au désenregistrement du client PTT, ou de la destruction du groupe. - si aucune activité n'est détectée durant une période configurable, typiquement 30 secondes, alors, le serveur PTT relâche les ressources du réseau LTE, mais pas les ressources de la session RTP applicative, qui elle reste active. Brève description des figures L'invention sera mieux comprise à la lecture de la description qui suit et à l'examen des figures qui l'accompagnent. Celles-ci ne sont présentées qu'à titre illustratif, mais nullement limitatif de l'invention. Les figures montrent : - Figure 1: une représentation schématique du flux d'appel lors d'une phase d'initialisation des ressources du PTT pour chaque utilisateur s'enregistrant pour un appel de groupe auprès d'un serveur PTT, selon un mode de réalisation de l'invention ; - Figure 2 : une représentation schématique du flux d'appel lors d'une 15 requête primaire de clients PTT, selon un mode de réalisation de l'invention ; Description de l'invention On note dès à présent que les figures ne sont pas à l'échelle. Les réalisations suivantes sont des exemples. Bien que la description se réfère à un ou plusieurs modes de réalisation, ce d ne signifie pas 20 nécessairement que chaque référence concerne le même mode de réalisation, ou que les caractéristiques s'appliquent seulement à un seul mode de réalisation. De simples caractéristiques de différents modes de réalisation peuvent également être combinées pour fournir d'autres réalisations. 25 Afin d'accéder à un serveur 3 d'applications PTT (Push to Talk en anglais) via un terminai (non représenté) de type téléphone cellulaire, le terminal comporte un client PTT 1, la, lb. Ce type de téléphone cellulaire étant destiné à un fonctionnement sur un ou plusieurs réseaux 4 IP-WAN, tel que le LTE (pour Long Term Evolution), et/ou la 3G (pour ene Génération), 30 et/ou du WIMAX (pour ...), et/ou du W1FI, et/ou tout autre technologie large bande, il dispose pour chaque type de réseau 4 IP-WAN, d'une connexion à un modem 2, 2a, 2b. Dans un mode de réalisation préférentiel, ce modem 2, 2a, 2b est intégré directement au terminal. Ainsi, le téléphone cellulaire, doté respectivement à la fois d'un client PTT 1, la, lb et d'un modem IP 2, 2a, 2b, 35 forme un ensemble appelé généralement PoC (pour PTT over Cellular en anglais). Le fonctionnement de ce terminal PoC va maintenant être décrit de manière très générale. Un exemple de mode de réalisation avec un réseau IP-WAN de type LTE sera pris par la suite pour illustré le séquençage des étapes aux figures 1 et 2. Dans un premier temps, le terminal Poe est connecté à un réseau 4 de transport radioélectrique de type IP-WAN. Ce terminal PoC est alors est alors authentifié et enregistré, lors de son initialisation par un utilisateur, à la fois au niveau d'un registre utilisateurs de l'application ou client PTT 1, la, lb, mais également au niveau du registre utilisateurs du groupe d'appel applicatif. Cet enregistrement du terminal PoC est très utile, notamment, notamment afin de pouvoir joindre le terminal par la suite. Lorsque le terminal PoC est connecté au réseau 4 IP-WAN et qu'il se trouve enregistré au niveau des différents registres précédemment cités, alors le réseau 4 alloue des ressources média en lien montant et descendant entre le client PTT 1 et le serveur 3, via par exemple une procédure SIP (pour Session lnitialization Protocol, en anglais), avec un message d'invitation « INVITE ». Lorsque la procédure SIP a déjà été exécutée, il n'est plus nécessaire de l'exécuter de nouveau, puisque le signal et le média pour l'appel de 20 groupe seront utilisés uniquement par la session média RTP.. Il est alors nécessaire de s'assurer que ces ressources applicatives et de transports associés restent toujours installées et prêtes pour supporter le trafic, que ce soit un signal ou un média, de manière efficace. Au niveau de l'application, les ressources ont besoin d'être gardés 25 actives jusqu'à n'importe quelle désinscription d'un utilisateur du groupe. Au niveau du transport et plus particulièrement au niveau radio, les ressources radio doivent être gardées activées le plus longtemps possible. Autrement dit, en ce concerne la technologie LTE (pour Long Term Evolution, en anglais), la couche RRC reste toujours active, et ne retourne 30 pas à l'état de veille (ou idle en anglais), même si il n'y a pas ou peu de trafic supporté par la connexion. En effet, si la couche RRC se trouve à l'état idle, alors il va falloir envoyer un paging au terminal mobile pour remonter la connexion radio et cela ne permettra pas de garantir les 300ms. Cela peut être effectué par n'importe quelle activité périodique entre un utilisateur et 36 n'importe quel serveur d'application, comme par exemple, Via un message de battement de coeur pour maintenir la connexion active et maintenir la session RTP active, par exemple, jusqu'au désenregistrenient d'un client PTT ou de la destruction du groupe. Cela peut être appliqué pour des appels de groupe multiples en parallèle, à l'intérieur d'application voix PTT. Il peut y avoir également une application pour PTT sur d'autre média transféré sous forme de flux continus, tels que la vidéo, la voix, la vidéo et la voix combinées, etc.. La figure 1 est une représentation schématique du flux d'appel lors d'une phase d'initialisation des ressources PTT pour chaque utilisateur 10 s'enregistrant pour un appel de groupe auprès d'un serveur PTT, via un réseau LTE, selon un mode de réalisation de l'invention. Ainsi, à une étape 10 préliminaire, au démarrage du modem 2 LTE, la procédure de connexion de la technologie radioélectrique LTE est déclenchée, incluant du même coup la phase d'authentification, permettant 15 au modem 2 LTE d'être enregistré dans le réseau 4 LTE. Le résultat de cette procédure de connexion LTE est que le modem 2 est accessible au moyen d'adresses IP allouées et associées à une porteuse, avec un QCI (pour QoS Class Indicator en anglais) de signalisation qui n'est pas forcément un canal par défaut. Ce QCI est défini dans le HSS, qui n'est autre que la base de 20 données des utilisateurs pour le 3GPP, incluant notamment la technologie LTE. En effet, la porteuse est dite par défaut, parce qu'un nom du point d'accès IP pour un ensemble de services dans le réseau ou APN (pour Access Point Name, en anglais) est dédié au PTT. Il est attendu qu'un APN pour les services voix, et la QCI par défaut peut être par exemple QCI5 (qui 25 servira pour la signalisation SIP) et dC11 pour le média. A une étape 11, avant d'envoyer l'inscription SIP au serveur 3 PTT, le client PTT 1 à la possibilité d'obtenir l'adresse IP du serveur 3 PTT à partir du serveur 6 DNS. A une étape 12, une fois que le client PTT 1 est actif, qu'il a obtenu 30 l'adresse IP du serveur 3 PTT, via le serveur DNS ou par configuration manuelle, afin de contrôler la connectivité, le client PTT est apte à déclencher une procédure d'enregistrement du SIP avec le serveur 3 PTT sur la porteuse LTE par défaut. A une étape 13, le client PTT procède à une procédure d'affiliation du 35 groupe avec le serveur 3 PTT sur la porteuse LTE par défaut. A une étape 14, dès que la procédure d'affiliation au groupe est effectuée, une procédure SIP « INVITE » est exécutée pour réserver des ressources RTP au niveau applicatif du côté du serveur 3 PTT et du côté client 1 PTT. Pour effectuer cette procédure SIP, le client PTT 1 envoie un message d'invitation « SlP INVITE » pour son serveur 3 PTT afin de requérir l'initialisation d'une session RTP pour le média voix. Il est à noter que la session RTP est initialisée, mais que la porteuse LTE dédiée n'est pas initialisé à cette étape, afin d'éviter la consommation non nécessaire des ressources LTE GR (pour Guaranteed Sit Rate, en anglais). Cette étape 14 a pour avantage de permettre la montée de la session RTP immédiatement après la procédure d'affiliation du client PTT 1 au groupe. Ainsi, lorsqu'une d'une requête du client PTT 1 survient, parce que ce dernier est prêt à dialoguer sur la session RTP, cela lui est possible sans avoir besoin de passer par une étape exécutant la procédure « SIP INVITE » comme dans l'état de la technique. En effet, cette procédure « SIP INVITE » est plus ou moins longue et nécessite d'être faite simultanément pour chaque terminal du groupe. Dans l'état de la technique, une séquence d'envoie de requête « SIP INVITE » avec accusé réception « ACK » de la dite requête devait être effectuée pour 20 tous les terminaux mobiles du groupe, alors qu'avec l'invention il faut uniquement un message « RTP - PTT Start » pour montée la session RTP. En revanche, le fait d'avoir monté la session RTP au plus tôt, nécessite toutefois de maintenir la connexion active pour un maximum de réactivité parce que sinon la couche RRC radio peut repasser en mode idle, 25 ce qui va nécessiter un paging au moment d'avoir besoin de joindre le terminal mobile. Quelque que soit le temps écoulé entre deux requêtes PTT, la session RTP reste active tout le temps, jusqu'au désengeristrement du groupe du client PTT 1, et n'est pas relâchée au niveau applicatif au bout de 30s, 30 comme cela est effectué de manière classique dans l'état de la technique empêchant ainsi de garantir les 300ms de temps de latence. A une étape 15, une fois que la session RTP et que le port RTP sont alloués au serveur 3 PTT, un message indiquant que le protocole SIP 200 est actif « SIP 200 OK » est envoyé au client PTT en incluant l'adresse IP et 35 le port du serveur 3 PTT pour la session RTP. A une étape 16, une fois que la session RTP est montée, alors un message de battement de coeur est périodiquement échangé sur la porteuse par défaut, afin de maintenir la couche radio RRC active et également effectuer une supervision entre le client PTT et serveur. Le battement de coeur est une des possibilités utilisées pour tenir la connexion montée, mais elle est d'autant plus utilisée si une supervision est imposée. Il est à noter tout de même, que tout trafic régulier peut également tenir la connexion active sans repasser en mode veille (ou idle, en anglais), comme par exemple, la remontée périodique d'une position GPS, ou tout autre trafic tel que, de la présence ou de la supervision applicative, ou etc. La figure 2 est une représentation schématique du flux d'appel lors d'une phase de requête primaire de clients PTT respectivement référencé la et lb, via un réseau LTE, selon un mode de réalisation de l'invention ; Ainsi, à une étape 21, les étapes 10 à 16 d'initialisations 16 précédemment décrites sont exécutées pour chaque client PTT la, lb, cherchant à envoyer une première requête PTT sur le protocole RTP. A une étape 22, le client PTT la initie une requête PTT, laquelle est délivrée au serveur 3 PTT. tin compteur de temps présent au niveau du client PTT la détermine le délai d'attente de la délivrance de la requête au 20 serveur 3 PTT. A une étape 23, exécutée uniquement pour une utilisation avec un réseau LTE, le serveur 3 PTT émet des requêtes vers le réseau 4 LTE pour initialiser les ressources LTE, qui seront dédiées à la porteuse QCI 1. La porteuse QCI 1 est apte, selon les caractéristiques du standard 3GPP LTE, à 25 supporter le service voix pour la communication PTT. Il est à noté qu'une fois que la requête est prise en compte par le réseau 4 LTE, cela ne signifie pas que le réseau 4 LTE réussira à établir l'ensemble des ressources LTE appropriées nécessaire à cette étape. Cette étape 23 est exécutée obligatoirement pour la première itération. 30 A une étape 24, le réseau 4 LTE initialise la porteuse LTE dédiée. Pour l'initialisation de la porteuse LTE, il peut s'agir d'une création ou d'une mise à jour dans le cas où celle-ci existe. La porteuse LTE est apte à supporter la qualité de service ou QoS (pour Quality of Service, en anglais) pour le service voix pour les services PU, au sens de la porteuse LTE QC1. 35 La connexion IP du lien descendant et du lien montant est effectuée dans le réseau 4 LTE et dans le modem 2a, 2b LTE, afin de router les paquets du lien descendant et du lien montant vers la porteuse LTE dédiée. Il est à noter que si aucune activité n'est détectée durant une periode configurable, typiquement 30 secondes, alors le serveur 3 PTT relâche les ressources du réseau LTE, mais pas les ressources de la session RTP applicative, qui elle reste active. Par conséquent, à la prochaine requête PTT délivrée au serveur 3 PTT, les étapes 23 et 24 sont réitérées. A une étape 25, tous les clients PTT la, lb, qui se trouvent dans le groupe d'appel sont informés qu'un des clients PTT la, ou lb, veut o communiquer avec les autres clients PTT du groupe d'appel, et reçoivent un message de début de communication PTT « PTT Start » sur la porteuse LTE par défaut. A une étape 26, pour tous les clients PTT se trouvant dans le groupe, les requêtes du serveur 3 PU au réseau 4 LTE initialisent une porteuse 15 dédiée au support du service voix comme définie précédemment à l'étape 23. Les étapes 25 et 26 pouvant être réalisées en parallèles. A une étape 27, pour tous les clients PTT se trouvant dans le groupe, le réseau 4 LTE initialise la porteuse LTE dédiée capable de supporter la 20 qualité de service ou QoS pour le service voix pour les communications PTT. En LTE cela se traduit par une porteuse ayant un Ce ayant la valeur 1 ou Oeil. La connexion IP du lien descendant et du lien montant est effectuée dans le réseau 4 LTE et dans le modem 2e, 2b, LTE afin de router les paquets du lien descendant et du lien montant vers la porteuse LTE dédiée, 25 A une étape 28, des trames de voix sont envoyées et distribuées pour tous les clients PTT la, lb dans le groupe d'appel sur la porteuse LTE dédiée- Il est à noter que la procédure de battement de coeur n'est pas activée tant que les trames de voix sont échangées. REVENDICATIONS1. Procédé d'initialisation d'appel pour un terminal mobile comportant des applications (1, la, lb) de type PTT sur un réseau (4) cellulaire IP-WAN, ledit procédé comportant les étapes suivantes, pour chaque utilisateur dudit terminal mobile connecté à un modem (2) IP-WAN destiné à s'enregistrer pour un appel de groupe : - une étape (10), s'enclenchant au démarrage du modem (2) IP-WAN, durant laquelle s'effectue une procédure de connection au réseau (4) IP- WAN, - une étape (12), lorsque le client PTT (1, la, lb) est actif, et qu'il a obtenu l'adresse IP du serveur (3) PTT, le client PTT (1, la, lb) est apte à déclencher une procédure d'enregistrement du SIP avec le serveur (3) PTT sur la porteuse IP-WAN par défaut, - une étape (13), le client PTT (1, la, lb) procède à une procédure d'affiliation à un groupe d'appel avec le serveur (3) PTT sur la porteuse IPWAN par défaut, caractérisé en ce que, à - une étape (14), dès que la procédure d'affiliation au groupe d'appel est effectuée, une procédure SIP « INVITE » est exécutée pour réserver des ressources RTP au niveau applicatif du côté du serveur (3) PTT et du côté client (1, la, lb) PTT, de sorte à permettre la montée de la session RTP immédiatement après la procédure d'affiliation du client PTT (1, la, lb) au groupe. 2. Procédé selon la revendication 1, caractérisé en ce que pour effectuer cette procédure SIP, le client PTT (1, la, lb) envoie un message d'invitation « SIP INVITE» pour son serveur (3) PTT afin de requérir l'initialisation d'une session RTP pour le média voix, 3. Procédé selon les revendications précédentes, caractérisé en ce 30 que l'étape (10) comporte une phase d'authentification, permettant au modem (2) IP-WAN d'être enregistré dans le réseau (4) IP-WAN. 4. Procédé selon les revendications précédentes, caractérisé en ce que la procédure de connexion au réseau (4) IP-WAN prévue à l'étape (10) permet au modem (2) d'être accessible au moyen d'adresses IP allouées et 35 associées à une porteuse par défaut, avec un OC' définie dans le F-ISS. 5. Procédé selon les revendications précédentes, caractérisé en ce que à une étape (11), avant d'envoyer une inscription SIP au serveur (3) PTT, le client PTT (1, la, lb), à la possibilité d'obtenir l'adresse IP du serveur (3) PTT à partir du serveur (6) DNS. 6. Procédé selon la revendication 1 à 4, caractérisé en ce que à une étape (11), avant d'envoyer une inscription SIP au serveur (3) PTT, le client PTT (1, la, lb), à la possibilité d'obtenir l'adresse IF du serveur (3) PTT à partir d'une configuration manuelle. 7 - Procédé selon les revendications précédentes, caractérisé en ce 10 que à une étape (15), une fois que la session RTP et que le port RTP sont alloués au serveur (3) PTT, un message indiquant que le protocole SIP 200 est actif « SIP 200 OK » est envoyé au client PTT (1, la, 1 b) en incluant l'adresse IP et le port du serveur (3) PTT pour la session RTP. 8 - Procédé selon les revendications précédentes, caractérisé en ce 15 que à une étape (16), un message de battement de coeur est échangé entre le serveur (3) PTT et le client PTT (1, la, lb) pour maintenir la connexion active au niveau radio RRC IP-WAN, pour maintenir la session applicative RTP active et pour effectuer une supervision entre le client PTT (1, la, lb) et le serveur (3)- 20 9 - Procédé selon les revendications précédentes, caractérisé en ce que la session RTP reste active entre le serveur (3) PTT et le client (1, la, lb) jusqu'au désenregistrement du client PTT (1, 1 a, lb), ou de la destruction du groupe. 10 - Procédé selon les revendications précédentes, caractérisé en ce que à une étape (23) et (24), si aucune activité n'est détectée durant une période oonfigurable, typiquement 30 secondes, alors, le serveur (3) PTT relâche les ressources du réseau LTE, mais pas les ressources de la session RTP applicative, qui elle reste active, entraînant de ce fait, qu'à la prochaine requête PTT délivrée au serveur (3) PTT, les étapes (23) et (24) sont réitérées.