TITRE : Procédé d'enregistrement d'un terminal utilisateur auprès d'un réseau de communications organisé en tranches de réseau

Domaine technique

L’invention se situe dans les réseaux de communications, et notamment dans les réseaux dans lesquels sont instanciées des tranches de réseaux (en anglais network slice), permettant de dédier des équipements/fonctions/configurations réseau de communications pour des services spécifiques et/ou des clients spécifiques et/ou des terminaux spécifiques.

Art antérieur

Certaines architectures de réseau aujourd'hui spécifiées et déployées sont structurées en tranches de réseau permettant à un terminal utilisateur, selon la souscription du client (le terminal peut être utilisé par un autre utilisateur que le client ayant souscrit un abonnement ; le terme utilisateur ou client sera utilisé de façon indifférente par la suite par simplification), de bénéficier de fonctions spécifiques (d'acheminement, de traitement, d'administration ...) adaptées à un ou plusieurs critères parmi le type de client, le type de terminal, le type d'application, le type d'accès, etc... Ainsi, chaque tranche permet d'offrir un niveau de qualité de service et de sécurité conformément à un ou plusieurs critères cités ci-dessus. Il est en outre à noter que les clients et les terminaux sont d'une part de plus en plus diversifiés (terminaux loT (en anglais Internet of Things), smartphones, robots, passerelles résidentielles, variété d'équipements dits communicants...) et d'autre part disposent de capacités et de besoins assez différents. Cette évolution s'accompagne en outre d'une capacité d'au moins une partie de ces terminaux à pouvoir accéder simultanément ou pas à une pluralité d'applications dont les données sont possiblement acheminées sur des tranches de réseau distinctes. Il est à noter que ces évolutions visent aussi bien les réseaux fixes que les réseaux mobiles et que les spécifications des réseaux dits de cinquième génération (5G) intègrent cette structuration en tranches de réseaux.

Selon les spécifications des réseaux 5G auxquelles il sera particulièrement fait référence dans la suite de cette description, un terminal utilisateur doit mettre en oeuvre une procédure d'enregistrement pour pouvoir accéder aux tranches souscrites par l'utilisateur (par exemple dans sa souscription 5G). Les identifiants de tranches S-NSSAI (en anglais Single-Network Slice Sélection Assistance Information) souscrites sont stockées localement par le terminal (dans une donnée notée, en anglais, Configured NSSAI) et dans le réseau (dans une donnée notée, en anglais, Subscribed NSSAI). La procédure d'enregistrement commence donc par une étape mise en oeuvre par le terminal consistant à demander l'enregistrement en général pour une ou plusieurs slices, par exemple en indiquant le ou les identifiants de tranches S-NSSAI dans le paramètre Requested NSSAI de sa requête d'enregistrement. Cette requête est mise en oeuvre sur la base des informations stockées par le terminal utilisateur, et notamment relatives aux tranches configurées (Configured NSSAI) et éventuellement autorisées (Allowed NSSAI) lors d'un enregistrement précédent.

Ainsi, le terminal utilisateur stocke également les identifiants de tranches pour lesquelles le terminal est autorisé à activer une ou des sessions de données paquet, par le réseau et notamment via une entité notée AMF (en anglais Access and Mobility Function), dans une donnée notée, en anglais, Allowed NSSAI, contenant tout ou partie des S-NSSAI souscrites. Le terminal utilisateur stocke également les identifiants de tranches qui lui sont interdites (par le réseau) dans une donnée notée, en anglais, Rejected NSSAI. Ces identifiants de tranches autorisées/rejetées sont reçus par le terminal dans la réponse d'acceptation du réseau lors de sa procédure d'enregistrement auprès du réseau.

La procédure d'enregistrement comprend alors une étape de détermination, par le réseau, des tranches autorisées, respectivement rejetées à communiquer au terminal utilisateur. Le réseau (notamment via l'entité AMF) accepte la demande d'enregistrement sur la base des tranches demandées, pour le type d'accès et la zone d'enregistrement en cours d'utilisation par le terminal utilisateur et une mise à jour pourra être faite en cas de changement par exemple dans la souscription ou la localisation du terminal utilisateur. La réponse d'acceptation en provenance du réseau contient une information pour rendre compte d'un statut d'enregistrement (état autorisé/rejeté/en cours) pour chaque tranche demandée, par exemple au moins un paramètre parmi :

- Allowed NSSAI : correspond aux identifiants de tranches S-NSSAI autorisées ;

- Rejected NSSAI : correspond aux identifiants de tranches S-NSSAI rejetées, avec la cause de rejet (par exemple « pas d'autorisation dans le réseau mobile terrestre public (PLMN, en anglais Public Land Mobile Network) ou le réseau non public autonome (SNPN, en anglais Stand-alone Non- Public Network) en cours » ou « pas d'autorisation dans la zone d'enregistrement en cours ») ;

- Configured NSSAI : correspond au cas particulier où le paramètre Requested NSSAI de la requête d'enregistrement est absent ou au cas particulier où un changement de valeur du paramètre Configured NSSAI est intervenu ;

- Pending NSSAI : correspond au cas où il est nécessaire et indiqué dans la souscription que la tranche soit authentifiée avant qu'elle puisse être considérée comme autorisée, cette authentification étant en cours ou à venir. Une réponse de rejet de la demande d'enregistrement est émise pour le cas où aucune tranche ne pourrait être autorisée ou soumise à une authentification en cours ou à venir.

Cette procédure d'enregistrement standard présente certains inconvénients relatifs au choix des tranches demandées par le terminal utilisateur, i.e. des identifiants de tranches S-NSSAI du paramètre Requested NSSAI de la requête d'enregistrement, ce choix pouvant dépendre de l'implémentation du constructeur du terminal utilisateur, des politiques ou encore des applications définies au sein du terminal utilisateur, et ayant des impacts tant au niveau de l'utilisateur qu'au niveau de l'opérateur ou du réseau lui-même.

Par exemple, si un utilisateur souhaite accéder à une ou des tranches qu'il n'a pas demandées lors de l'enregistrement, il lui faut initier une autre procédure d'enregistrement pour ces tranches, ce qui allonge son temps d'accès au service, le temps d'exécuter la procédure d'enregistrement. Selon un autre exemple, si un terminal utilisateur demande d'abord l'enregistrement pour les tranches d'identifiants S-NSSAI#1, S-NSSAI#2 puis souhaite utiliser la tranche d'identifiant S- NSSAI#3, il doit refaire une demande d'enregistrement pour la tranche d'identifiant S-NSSAI#3. S'il ne demande pas en même temps l'enregistrement pour les tranches précédemment enregistrées (ici S-NSSAI#1 et S-NSSAI#2), il perd les tranches précédemment enregistrées et il lui faut refaire soit un enregistrement pour chaque tranche d'identifiant S-NSSAI#1 puis S-NSSAI#2, soit un enregistrement pour les deux « anciennes » tranches lorsqu'il voudra les utiliser. Sans compter que, dans ce cas, si une session de données était active sur le terminal utilisateur pour l'une et ou l'autre des tranches d'identifiants S-NSSAI#1/S-NSSAI#2, cette session est interrompue au moment de l'acceptation de l'enregistrement de la tranche d'identifiant S-NSSAI#3.

Un autre inconvénient réside dans le fait que le standard actuel impose que, dans la requête d'enregistrement du terminal utilisateur, le paramètre Requested NSSAI contienne les identifiants de tranches S-NSSAI du paramètre Allowed NSSAI (obtenu lors d'un enregistrement précédent) pour lesquelles il existe une ou des sessions de données actives. Si le terminal utilisateur ne le fait pas, par exemple suite à une mauvaise configuration du terminal utilisateur, alors les sessions de données actives sont interrompues puisque, selon le standard, un terminal utilisateur ne peut établir des sessions de données que pour des tranches autorisées lors de l'enregistrement.

Ces situations sont préjudiciables pour un opérateur qui commercialise des services 5G par exemple, car une coupure brutale des sessions de données en cours s'avère très négative pour l'expérience utilisateur.

Pour l'opérateur, cela induit de la signalisation supplémentaire dans le réseau pour chaque enregistrement supplémentaire et son intérêt serait de limiter le nombre d'enregistrements réalisés par un terminal utilisateur tout en permettant un meilleur accès aux services pour l'utilisateur. Enfin, le nombre d'identifiants de tranches S-NSSAI du paramètre Requested NSSAI par requête d'enregistrement est aussi une préoccupation en termes de charge dans le réseau, notamment pour l'internet des objets, et le standard actuel recommande de réduire ce nombre d'identifiants de tranches S-NSSAI du paramètre Requested NSSAI par requête d'enregistrement.

Il existe donc un besoin pour une technique permettant une procédure optimisée de l'enregistrement de tranches de réseau par un terminal utilisateur et une meilleure détermination des tranches de réseau autorisées à la fois au niveau du terminal utilisateur et au niveau du réseau, tout en permettant une applicabilité en 5G ainsi que toute future génération de réseaux utilisant une architecture structurée en tranches de réseau.

Exposé de l'invention

L'invention répond à ce besoin en proposant un procédé d'enregistrement d'un terminal utilisateur auprès d'un réseau de communications organisé en tranches de réseau, le terminal utilisateur étant apte à émettre et recevoir des données sur le réseau, le terminal utilisateur comprenant des données de souscription d'un utilisateur pour au moins une des tranches du réseau, le procédé étant mis en oeuvre au moins par un équipement réseau apte à communiquer avec le terminal utilisateur par l'intermédiaire du réseau et comprenant

- une étape de réception d'une requête d'enregistrement émise par le terminal utilisateur pour s'enregistrer auprès du réseau ;

- une étape d'obtention, dans une information de contexte associée au terminal utilisateur, d'une autorisation ou d'un rejet d'au moins une des tranches du réseau préalablement autorisée ou rejetée lors d'au moins un précédent enregistrement du terminal utilisateur pour un même type d'accès et une même zone d'enregistrement, délivrant une décision d'enregistrement, ou

- une étape de détermination autonome d'un statut d'enregistrement pour chacune des tranches du réseau souscrites par l'utilisateur et identifiées par l'équipement réseau dans un paramètre de réseau comprenant les identifiants de toutes les tranches du réseau souscrites par l'utilisateur, délivrant une décision d'enregistrement.

Ainsi, la présente technique repose sur une approche tout à fait nouvelle et inventive de la procédure d'enregistrement d'un terminal auprès d'un réseau, consistant à tenir compte d'un ou plusieurs enregistrements préalablement effectués par le terminal dans les mêmes conditions d'accès et de localisation ou à déterminer, de manière autonome pour le réseau (c'est-à-dire sans tenir compte d'informations transmises ou non par le terminal utilisateur concernant les tranches à enregistrer), le statut d'enregistrement (i.e. l'état autorisé/rejeté/en cours) de toutes les tranches souscrites identifiées dans un paramètre de réseau listant toutes les tranches souscrites. Cette approche permet notamment de limiter fortement le nombre d'enregistrements successifs pouvant être demandés par un terminal utilisateur, puisqu'un enregistrement courant tient compte d'un historique d'enregistrements (en admettant ici que l'historique puisse éventuellement contenir les tranches rejetées), selon un premier mode de réalisation, ou détermine le statut de toutes les tranches souscrites en un seul enregistrement, selon un deuxième mode de réalisation.

Cette approche permet donc également de limiter la charge de signalisation dans le réseau.

Par ailleurs, cette approche permet en outre d'éviter les coupures de sessions de données non souhaitées par un utilisateur, en conservant dans la liste des tranches autorisées toutes celles ayant été autorisées préalablement lors d'enregistrements précédents selon un premier mode de réalisation ou en rendant inutile un enregistrement supplémentaire dans un deuxième mode de réalisation.

Selon un premier mode de réalisation, relatif à un mode d'enregistrement cumulatif, la décision d'enregistrement comprend au moins un paramètre de tranches autorisées comprenant au moins un identifiant d'une des tranches du réseau préalablement autorisée lors d'au moins un précédent enregistrement du terminal utilisateur pour un même type d'accès et une même zone d'enregistrement et/ou au moins un paramètre de tranches rejetées comprenant au moins un identifiant d'une des tranches du réseau préalablement rejetée lors d'au moins un précédent enregistrement du terminal utilisateur pour un même type d'accès et une même zone d'enregistrement.

Ainsi, selon ce premier mode de réalisation, toute requête d'enregistrement reçue par un équipement du réseau, en provenance d'un terminal utilisateur, est traitée de sorte à tenir compte du statut autorisé et/ou rejeté, connu dans une information de contexte associée au terminal utilisateur, pour une ou des tranches préalablement demandées lors d'un ou plusieurs enregistrements précédents, de sorte à délivrer une liste des tranches autorisées et/ou une liste des tranches rejetées, par exemple sous la forme de paramètres standardisés tels que Allowed NSSAI et Rejected NSSAI.

Ceci permet de répondre au terminal utilisateur avec une liste des tranches autorisées et/ou une liste des tranches rejetées tenant compte de l'historique des enregistrements, sans que le terminal utilisateur ne l'ait spécifié, donc sans nécessiter de modifications côté terminal utilisateur concernant la requête d'enregistrement. C'est le réseau qui prend l'initiative d'effectuer un enregistrement « cumulatif ».

De plus, cela permet au terminal utilisateur de ne pas avoir à inclure dans la requête, comme c'est actuellement le cas dans le standard, les identifiants des tranches préalablement autorisées, et sur lesquelles il a potentiellement une session de données paquet en cours, sous peine que cette session soit coupée. Selon ce mode de réalisation, toute tranche préalablement autorisée garde ce statut, même si le terminal utilisateur ne l'a pas incluse dans sa requête d'enregistrement courante.

Selon un aspect particulier, où la requête d'enregistrement comprend au moins un identifiant d'une tranche souscrite par l'utilisateur, l'étape d'obtention comprend une sous-étape de détermination d'un statut d'enregistrement pour ladite au moins une tranche identifiée dans la requête.

Ainsi, selon ce premier mode de réalisation, si la requête d'enregistrement comprend un ou plusieurs identifiants d'une ou plusieurs tranches souscrites (par exemple via le paramètre S- NSSAI dans le paramètre Requested NSSAI), l'équipement réseau en détermine le statut autorisé/rejeté/en cours (i.e. nécessitant une authentification de tranche). Cette sous-étape de détermination peut être mise en oeuvre avant, après ou simultanément à l'étape d'obtention du statut des tranches préalablement demandées lors d'un ou plusieurs enregistrements précédents. Ainsi, si le statut de la ou les tranches identifiées dans la requête n'est pas déjà connu d'un enregistrement précédent, leur statut est déterminé lors de cet enregistrement courant.

Selon une caractéristique particulière, l'identifiant de la tranche identifiée dans la requête est compris, dans la décision d'enregistrement, dans le paramètre de tranches autorisées ou le paramètre de tranches rejetées ou un paramètre de tranches en attente d'authentification, en fonction de la sous-étape de détermination.

Ainsi, selon ce premier mode de réalisation, lorsque l'équipement réseau a déterminé le statut autorisé/rejeté de la ou des tranches identifiées dans la requête, il inclut le ou les identifiants de la ou des tranches identifiées dans la requête dans l'un ou l'autre des paramètres précités, listant les tranches autorisées respectivement les tranches rejetées. Il se peut également que la ou les tranches ou l'une des tranches identifiées dans la requête ne soi(en)t autorisée(s) qu'après une authentification réussie. Dans ce cas, un autre paramètre listant les tranches « en attente d'authentification » est délivré par le réseau, par exemple sous la forme du paramètre standardisé Pending NSSAI.

Ceci permet de répondre au terminal utilisateur avec une liste des tranches autorisées et/ou une liste des tranches rejetées tenant compte de l'historique des enregistrements et de la ou des tranches comprises dans la requête d'enregistrement, donc également sans nécessiter de modifications côté terminal utilisateur concernant la requête d'enregistrement.

Selon un aspect particulier, où la requête d'enregistrement comprend au moins un indicateur de cumul de tranches, l'étape d'obtention comprend une sous-étape de décodage dudit au moins un indicateur de cumul de tranches reçu délivrant une indication de cumul positive ou négative.

Ainsi, selon cette variante du premier mode de réalisation, il est prévu que la requête d'enregistrement comprenne un paramètre spécifique, par exemple noté AdditionaIRegistration, indiquant si un enregistrement « cumulatif » est requis ou non. Ce paramètre doit donc être décodé par l'équipement réseau afin de déterminer la suite de la procédure, selon qu'un enregistrement cumulatif est requis ou non. Cette variante permet donc au terminal utilisateur de signaler spécifiquement à l'équipement réseau s'il souhaite ou non un enregistrement cumulatif, par exemple sous la forme d'un paramètre spécifique ajouté dans la requête, ou sous la forme d'un paramètre modifiant le format de NSSAI du standard actuel. Ce paramètre correspond par exemple à un booléen pouvant prendre la valeur 1 si un enregistrement cumulatif est requis et la valeur nulle sinon.

Cette approche permet notamment de signaler à l'équipement réseau qu'un enregistrement cumulatif est souhaité et donc de mettre en oeuvre un tel enregistrement cumulatif, l'enregistrement cumulatif n'étant pas mis en oeuvre par défaut (l'absence de paramètre ou l'absence de valeur pour le paramètre n'entrainant pas un enregistrement cumulatif).

Selon une caractéristique particulière, si ladite indication de cumul est positive, la décision d'enregistrement comprend au moins un paramètre de tranches autorisées comprenant au moins un identifiant d'une des tranches du réseau préalablement autorisée lors d'au moins un précédent enregistrement du terminal utilisateur pour un même type d'accès et une même zone d'enregistrement et/ou au moins un paramètre de tranches rejetées comprenant au moins un identifiant d'une des tranches du réseau préalablement rejetée lors d'au moins un précédent enregistrement du terminal utilisateur pour un même type d'accès et une même zone d'enregistrement.

Par ailleurs, l'identifiant de la tranche identifiée dans la requête est compris, dans la décision d'enregistrement, dans le paramètre de tranches autorisées ou le paramètre de tranches rejetées ou un paramètre de tranches en attente d'authentification en fonction de la sous-étape de détermination.

Selon une caractéristique particulière, dans le paramètre de tranches autorisées compris dans la décision d'enregistrement, ledit au moins un identifiant d'une des tranches du réseau préalablement autorisée lors d'au moins un précédent enregistrement du terminal utilisateur pour un même type d'accès et une même zone d'enregistrement correspond à une tranche pour laquelle le terminal utilisateur a une session de données paquet active.

Ainsi, selon cette autre variante du premier mode de réalisation, l'équipement réseau n'effectue un enregistrement cumulatif qu'avec des tranches préalablement autorisées pour lesquelles le terminal utilisateur a une session de données active. Cela permet de limiter encore la signalisation réseau en listant potentiellement moins de tranches en réponse à une requête d'enregistrement, tout en assurant que des sessions de données actives ne sont pas coupées même si le terminal utilisateur a omis de les redemander. Selon un deuxième mode de réalisation, relatif à un mode d'enregistrement global, toute requête d'enregistrement reçue par un équipement du réseau, en provenance d'un terminal utilisateur, est traitée de sorte à tenir compte de chaque tranche souscrite par l'utilisateur/client de la demande d'enregistrement. L'étape de détermination autonome ne tient pas compte d'un ou des identifiants de tranche compris ou non dans la requête, i.e. la détermination autonome est déclenchée sans même s'interroger de la présence ou non d'information de tranche(s) (i.e. de la présence d'un paramètre Requested NSSAI, a fortiori de la valeur de ce paramètre lorsqu'il est présent).

Ainsi, selon ce deuxième mode de réalisation, l'équipement réseau identifie de manière autonome l'ensemble des tranches souscrites, c'est-à-dire sans tenir compte d'éventuels identifiants de tranche présents dans la requête d'enregistrement, afin d'en déterminer ensuite le statut autorisé/rejeté/en cours. Cette autonomie permet au réseau de ne pas dépendre de la requête d'enregistrement pour identifier les tranches à enregistrer, limitant ainsi les étapes à mettre en oeuvre.

Selon un aspect particulier, la décision d'enregistrement comprend au moins un paramètre de tranches autorisées comprenant les identifiants de toutes les tranches souscrites autorisées et/ou au moins un paramètre de tranches rejetées comprenant les identifiants de toutes les tranches souscrites rejetées et/ou au moins un paramètre de tranches en attente/en cours d'authentification comprenant les identifiants de toutes les tranches souscrites en attente/en cours d'authentification.

Ainsi, selon ce deuxième mode de réalisation, l'équipement réseau détermine systématiquement le statut autorisé/rejeté/en cours pour toutes les tranches souscrites à réception d'une requête d'enregistrement et délivre une liste des tranches autorisées et/ou une liste des tranches rejetées, par exemple sous la forme de paramètres standardisés tels que Allowed NSSAI et Rejected NSSAI. Il se peut également qu'une ou plusieurs des tranches souscrites ne soi(en)t autorisée(s) qu'après une authentification réussie. Dans ce cas, un autre paramètre listant les tranches en attente/en cours d'authentification est délivré par le réseau, par exemple sous la forme du paramètre standardisé Pending NSSAI.

Cette approche permet de limiter le nombre d'enregistrements car le terminal utilisateur reçoit le statut de toutes les tranches souscrites, donc peut en tenir compte pour toute activation ultérieure de session de données paquet. La signalisation réseau est donc également fortement limitée.

Selon une caractéristique particulière, la requête d'enregistrement comprend au moins un indicateur d'enregistrement global déclenchant une étape de décodage dudit au moins un indicateur d'enregistrement global reçu délivrant une indication d'enregistrement global positive ou négative.

Ainsi, selon cette variante du deuxième mode de réalisation, il est prévu que la requête d'enregistrement comprenne un paramètre spécifique, par exemple noté alISnssaiRegistration, indiquant si un enregistrement global est requis ou non. Ce paramètre transmis par le terminal utilisateur doit donc être décodé par l'équipement réseau afin de déterminer la suite de la procédure, selon qu'un enregistrement global est requis ou non. Cette variante permet donc au terminal utilisateur de signaler spécifiquement à l'équipement réseau s'il souhaite ou non un enregistrement global, par exemple sous la forme d'un paramètre spécifique ajouté dans la requête, ou sous la forme d'un paramètre modifiant le format de NSSAI du standard actuel. Ce paramètre correspond par exemple à un booléen pouvant prendre la valeur 1 si un enregistrement global est requis et la valeur nulle sinon, l'enregistrement global n'étant pas mis en oeuvre par défaut (l'absence de paramètre ou l'absence de valeur pour le paramètre n'entrainant pas un enregistrement global).

Par exemple, si ladite indication d'enregistrement global est positive, l'étape de détermination est déclenchée et la décision d'enregistrement comprend au moins un paramètre de tranches autorisées comprenant les identifiants de toutes les tranches souscrites autorisées et/ou au moins un paramètre de tranches rejetées comprenant les identifiants de toutes les tranches souscrites rejetées et/ou au moins un paramètre de tranches en attente d'authentification comprenant les identifiants de toutes les tranches souscrites en attente d'authentification.

En revanche, si ladite indication d'enregistrement global est négative et si la requête d'enregistrement comprend au moins un identifiant d'une tranche souscrite par l'utilisateur, l'étape de détermination est déclenchée uniquement pour la ou les tranches identifiées dans la requête et la décision d'enregistrement comprend au moins un paramètre de tranches autorisées comprenant au moins un identifiant d'une tranche identifiée dans la requête et autorisée et/ou au moins un paramètre de tranches rejetées comprenant au moins un identifiant d'une tranche identifiée dans la requête et rejetée et/ou au moins un paramètre de tranches en attente d'authentification comprenant au moins un identifiant d'une tranche identifiée dans la requête et en attente d'authentification.

Ainsi, selon une mise en oeuvre de cette variante du deuxième mode de réalisation, si le terminal utilisateur n'a pas demandé d'enregistrement global mais s'il a identifié une ou plusieurs tranches dans la requête d'enregistrement, alors le réseau détermine le statut autorisé/rejeté/en attente d'authentification pour la ou les tranches identifiées dans la requête et n'effectue donc pas d'enregistrement global.

De plus, si ladite indication d'enregistrement global est négative et si la requête d'enregistrement ne comprend pas d'identifiant d'une tranche souscrite par l'utilisateur, l'étape de détermination est déclenchée et la décision d'enregistrement comprend au moins un paramètre de tranches autorisées comprenant les identifiants de toutes les tranches souscrites autorisées et/ou au moins un paramètre de tranches rejetées comprenant les identifiants de toutes les tranches souscrites rejetées et/ou au moins un paramètre de tranches en attente d'authentification comprenant les identifiants de toutes les tranches souscrites en attente d'authentification.

En revanche, selon une autre mise en oeuvre de cette variante du deuxième mode de réalisation, si le terminal utilisateur n'a pas demandé d'enregistrement global et n'a pas identifié de tranches dans la requête d'enregistrement, alors le réseau effectue par défaut un enregistrement global. Selon un aspect particulier, la décision d'enregistrement comprend un indicateur d'enregistrement global réussi lorsque toutes les tranches souscrites sont autorisées.

Ainsi, selon cette mise en oeuvre, l'équipement réseau délivre également un indicateur d'enregistrement global (par exemple noté alISnssaiRegistration) lorsque toutes les tranches souscrites ont été enregistrées, permettant de limiter la signalisation de la réponse, qui ne comprend pas les paramètres listant les tranches souscrites autorisées mais simplement un indicateur de réussite de l'enregistrement global.

La présente technique concerne également un procédé de demande d'activation d'une session de données paquet pour un terminal utilisateur apte à émettre et recevoir des données sur un réseau de communications organisé en tranches de réseau, le procédé étant mis en oeuvre dans ledit terminal et comprenant une demande d'activation d'une session de données paquet sur au moins une tranche du réseau, la demande d'activation tenant compte d'une décision d'enregistrement, en provenance d'au moins par un équipement réseau apte à communiquer avec le terminal utilisateur par l'intermédiaire du réseau, à une requête d'enregistrement émise par le terminal, la décision d'enregistrement comprenant un indicateur d'enregistrement global réussi indiquant que toutes les tranches souscrites par un utilisateur sont autorisées.

Ainsi, selon cette mise en oeuvre, le terminal utilisateur tient compte, au moment de demander l'activation d'une session de données paquet, d'un paramètre spécifique transmis en réponse à un requête d'enregistrement. Selon une variante, à la réception du paramètre indiquant que toutes les tranches souscrites ont été enregistrées (alISnssaiRegistration), le terminal utilisateur met à jour son paramètre local Allowed NSSAI avec la valeur de Configured NSSAI qui contient toutes les tranches souscrites.

Selon une caractéristique particulière du procédé d'enregistrement, où la requête d'enregistrement comprend un indicateur de changement de tranche, le procédé comprend une étape préalable de vérification si au moins une tranche souscrite a été préalablement autorisée ou rejetée lors d'au moins un précédent enregistrement du terminal utilisateur pour un même type d'accès et une même zone d'enregistrement. Ainsi, selon cette approche, le terminal utilisateur ou l'équipement réseau effectue au préalable une étape de vérification du statut autorisé/rejeté d'une ou plusieurs tranches souscrites, dans le but d'alléger la requête d'enregistrement (lorsque c'est le terminal utilisateur qui met en oeuvre cette vérification) ou de rejeter directement cette requête (lorsque c'est l'équipement réseau qui met en oeuvre cette vérification et que l'état d'enregistrement est déjà connu pour toutes les tranches demandées), lorsque cette requête d'enregistrement a pour but un changement de tranche (et non lorsque la requête correspond à une requête de mise à jour périodique ou de la durée d'enregistrement, à un premier enregistrement, à un changement de zone d'enregistrement ou une urgence...).

Par exemple, l'étape préalable de vérification est mise en oeuvre par le terminal utilisateur et si la vérification est positive, la requête d'enregistrement ne contient pas l'identifiant de la tranche préalablement autorisée ou rejetée.

Selon un autre exemple, l'étape préalable de vérification est mise en oeuvre par l'équipement réseau pour les identifiants de tranche compris dans la requête d'enregistrement et, si la vérification est positive pour tous les identifiants de tranches compris dans la requête d'enregistrement, l'étape d'obtention n'est pas mise en oeuvre et la requête d'enregistrement est rejetée.

Ainsi, selon cette approche, et dans le cadre d'un enregistrement cumulatif, l'équipement réseau vérifie si toutes les tranches identifiées dans la requête ont déjà fait l'objet d'un enregistrement précédent, auquel cas la requête est rejetée car inutile : le terminal utilisateur a déjà connaissance du statut des tranches identifiées dans sa requête.

Selon un aspect particulier, où la requête d'enregistrement comprend un indicateur de changement de tranche et où le procédé comprend une étape préalable de vérification, mise en oeuvre par l'équipement réseau, si toutes les tranches souscrites ont été préalablement autorisées ou rejetées lors d'au moins un précédent enregistrement du terminal utilisateur pour un même type d'accès et une même zone d'enregistrement et, si la vérification est positive, l'étape d'obtention ou de détermination n'est pas mise en oeuvre et la requête d'enregistrement est rejetée.

Ainsi, selon cette approche, et dans le cadre d'un enregistrement cumulatif ou global, l'équipement réseau vérifie si toutes les tranches souscrites ont déjà fait l'objet d'un enregistrement précédent, auquel cas la requête est rejetée car inutile : le terminal utilisateur a déjà connaissance du statut de toutes les tranches souscrites.

L'invention concerne encore un produit programme d’ordinateur comprenant des instructions de code de programme pour la mise en oeuvre d'un procédé tel que décrit précédemment, lorsqu'il est exécuté par un processeur. L'invention vise également un support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé selon l'invention tel que décrit ci-dessus.

Un tel support d’enregistrement peut être n’importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu’une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d’enregistrement magnétique, par exemple une clé USB ou un disque dur.

D’autre part, un tel support d’enregistrement peut être un support transmissible tel qu’un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d’autres moyens, de sorte que le programme d'ordinateur qu'il contient est exécutable à distance. Le programme selon l’invention peut être en particulier téléchargé sur un réseau par exemple le réseau Internet.

Alternativement, le support d’enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l’exécution du procédé de contrôle d'affichage précité.

L’invention concerne encore un dispositif d'enregistrement d'un terminal utilisateur auprès d'un réseau de communications organisé en tranches de réseau, ledit terminal utilisateur étant apte à émettre et recevoir des données sur le réseau, le terminal utilisateur comprenant des données de souscription d'un utilisateur pour au moins une des tranches du réseau, le dispositif étant mis en oeuvre au moins par un équipement réseau apte à communiquer avec le terminal utilisateur par l'intermédiaire du réseau et comprenant un récepteur, un émetteur, un processeur et une mémoire couplée au processeur avec des instructions destinées à être exécutées par le processeur pour :

- recevoir une requête d'enregistrement émise par le terminal utilisateur pour s'enregistrer auprès du réseau ;

- obtenir, dans une information de contexte associée au terminal utilisateur, une autorisation ou un rejet d'au moins une des tranches du réseau préalablement autorisée ou rejetée lors d'au moins un précédent enregistrement du terminal utilisateur pour un même type d'accès et une même zone d'enregistrement, délivrant une décision d'enregistrement, ou

- déterminer de manière autonome un statut d'enregistrement pour chacune des tranches du réseau souscrites par l'utilisateur et identifiées par l'équipement réseau dans un paramètre de réseau comprenant les identifiants de toutes les tranches du réseau souscrites par l'utilisateur, délivrant une décision d'enregistrement.

Ce dispositif, apte à mettre en oeuvre dans tous ses modes de réalisation le procédé d'enregistrement qui vient d’être décrit, est destiné à être mis en oeuvre dans une entité réseau. Ce dispositif et le programme d'ordinateur correspondants précités présentent au moins les mêmes avantages que ceux conférés par le procédé d'enregistrement selon la présente technique.

Les entités réseau décrites dans la présente demande peuvent correspondre à des entités virtuelles, encore appelées fonctions.

L'invention concerne également un terminal utilisateur apte à émettre et recevoir des données sur un réseau de communications organisé en tranches de réseau auprès duquel il s'enregistre, le terminal utilisateur comprenant des données de souscription d'un utilisateur pour au moins une des tranches du réseau, et comprenant un récepteur, un émetteur, un processeur et une mémoire couplée au processeur avec des instructions destinées à être exécutées par le processeur pour :

- vérifier si au moins une tranche souscrite a été préalablement autorisée ou rejetée lors d'au moins un précédent enregistrement du terminal utilisateur pour un même type d'accès et une même zone d'enregistrement et, si la vérification est positive, la requête d'enregistrement émise par le terminal utilisateur pour s'enregistrer auprès du réseau ne contient pas l'identifiant de la tranche préalablement autorisée ou rejetée.

Ce terminal utilisateur est apte à mettre en oeuvre dans tous ses modes de réalisation le procédé d'enregistrement, englobe le terminal utilisateur (« user equipment » spécifié par le 3GPP) et peut correspondre par exemple à un terminal loT (en anglais Internet of Things), un smartphone, un robot, un équipement dit communicant, une passerelle résidentielle, accédant au réseau via tout type d'accès fixe ou mobile spécifié par le 3GPP ou non, le réseau pouvant correspondre à un réseau public dit PLMN ou non-public dit NPN (en anglais Non-Public Network notamment un réseau non public autonome dit SNPN, en anglais Stand-alone Non-Public Network).

Présentation des figures

D’autres buts, caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles :

[Fig 1] présente un exemple d'une architecture simplifiée d'un réseau de communications dans lequel est mis en oeuvre le procédé d'enregistrement selon un mode de réalisation de l'invention ; [Fig 2] illustre sous forme de schéma bloc le procédé d'enregistrement selon un mode de réalisation de l'invention ;

[Fig 3] illustre sous forme de schéma bloc un exemple de mise en oeuvre du procédé d'enregistrement selon un premier mode de réalisation de l'invention ;

[Fig 4] illustre sous forme de schéma bloc un exemple de mise en oeuvre du procédé d'enregistrement selon un deuxième mode de réalisation de l'invention. Description détaillée de modes de réalisation de l'invention

La présente technique propose une détermination optimisée des tranches autorisées/rejetées pour un terminal utilisateur, en fonction des tranches souscrites par l'utilisateur, permettant de limiter la signalisation et la charge du réseau et d'éviter des coupures non souhaitées de session de données paquet, tout en simplifiant la procédure d'enregistrement.

Pour ce faire, la présente technique propose une procédure d'enregistrement reposant sur un concept inventif basé sur un aspect cumulatif de la détermination des tranches autorisées/rejetées et non plus sur la détermination d'autorisation ou du rejet des tranches spécifiquement identifiées dans la requête d'enregistrement comme c'est le cas selon les techniques actuelles.

Selon un premier mode de réalisation, l'aspect cumulatif réside dans le fait de tenir compte d'un ou plusieurs enregistrements préalablement effectués par le terminal, pour un même type d'accès et une même zone d'enregistrement, et de cumuler, le cas échéant, les résultats de ce ou ces enregistrements effectués préalablement avec une demande d'enregistrement pour une ou plusieurs tranches non encore autorisées ou rejetées.

Selon un deuxième mode de réalisation, l'aspect cumulatif réside dans le fait de tenir compte de toutes les tranches souscrites, c'est-à-dire d'effectuer un enregistrement global pour toutes les tranches souscrites, sans tenir compte d'informations transmises ou non par le terminal utilisateur dans la requête d'enregistrement concernant les tranches à enregistrer.

Enfin, selon une autre caractéristique, compatible avec les deux modes de réalisation précités, la technique proposée permet de contrôler au préalable le statut autorisé ou rejeté d'une ou de toutes les tranches susceptibles de faire l'objet d'une demande d'enregistrement de la part d'un terminal utilisateur.

Un exemple d'architecture réseau, dans lequel la technique proposée peut être mise en oeuvre, est tout d'abord illustré, de manière simplifiée, en figure 1. Un ou plusieurs terminaux utilisateurs, notés UE1, UE2, accèdent, via un réseau d'accès AN, à un ou plusieurs réseaux de données DN1, DN2 ou DN3, via une ou plusieurs tranches SU, SI2 et SI3.

On s'intéresse ensuite à un terminal utilisateur UE1 qui souhaite recevoir des données sur une ou plusieurs tranches d'un réseau tel qu'illustré en figure 1.

Pour ce faire, un utilisateur Ul, par exemple l'utilisateur principal du terminal utilisateur UE1, souscrit, auprès de son opérateur de télécommunications, à une ou plusieurs des tranches du réseau, par exemple selon ses habitudes ou ses souhaits de consommation de contenus, les performances de son terminal utilisateur UE1... Suite à sa souscription, des données de souscription DSub (comprenant notamment, dans un paramètre noté Subscribed NSSAI, les identifiants des tranches auxquelles l'utilisateur Ul a souscrit) sont créées et stockées dans une base de données de souscription. De plus, un identifiant de souscription IdSub, par exemple la variable SUPI (ou en anglais Subscription Permanent Identifier) permet d'accéder à ces données de souscription DSub, par exemple lorsqu'elles sont stockées dans un équipement réseau de gestion de données de souscription. Cet identifiant de souscription est notamment stocké dans la carte SIM du terminal utilisateur UE1 et est représentatif de la souscription, contenant une ou des tranches souscrites, sans être exclusivement associé ni à l'utilisateur U1 ni au terminal utilisateur UE1. En effet, un autre utilisateur U2 peut avoir obtenu l'autorisation de l'utilisateur U1 de se servir de sa souscription, ou la carte SIM stockant l'identifiant de souscription peut être transférée du terminal utilisateur UE1 vers un autre terminal utilisateur UE2 par exemple.

La présente technique concerne plus particulièrement la procédure d'enregistrement d'un terminal utilisateur UE1 auprès du réseau, en vue d'activer ensuite une session de données paquet sur une ou plusieurs tranches du réseau souscrites.

La figure 2 illustre les principales étapes d'un procédé d'enregistrement selon la présente technique, mis en oeuvre par un équipement du réseau NE1.

Ainsi, un équipement du réseau NE1 met en oeuvre une étape de réception 200 d'une requête d'enregistrement émise par le terminal utilisateur UE1 pour s'enregistrer auprès du réseau, et selon le premier ou le deuxième mode de réalisation, décrits en détails ci-après, l'équipement du réseau NE1 met en oeuvre :

- une étape d'obtention 300, dans une information de contexte associée au terminal utilisateur, d'une autorisation ou d'un rejet d'au moins une des tranches du réseau préalablement autorisée ou rejetée lors d'au moins un précédent enregistrement du terminal utilisateur pour un même type d'accès et une même zone d'enregistrement, délivrant une décision d'enregistrement R, ou

- une étape de détermination autonome 400 d'un statut d'enregistrement pour chacune des tranches du réseau souscrites par l'utilisateur et identifiées par l'équipement réseau dans un paramètre de réseau comprenant les identifiants de toutes les tranches du réseau souscrites par l'utilisateur, délivrant une décision d'enregistrement R.

Description du premier mode de réalisation

Comme indiqué ci-dessus, ce premier mode de réalisation permet de tenir compte, au moment d'une demande courante d'enregistrement émise par un terminal utilisateur UE1, d'un ou plusieurs enregistrements préalablement effectués par ce terminal utilisateur UE1, pour un même type d'accès et une même zone d'enregistrement. Le traitement de la requête d'enregistrement par le réseau dans ce premier mode de réalisation est différent du standard car il concerne un enregistrement cumulatif au lieu d'un enregistrement supplétif. Il est à noter également, comme décrit par la suite, que la requête émise par le terminal utilisateur peut, en outre, prendre des caractéristiques supplémentaires par rapport au standard, comme décrit ci-après dans une deuxième solution.

Quelle que soit la solution, l'équipement réseau, qui reçoit une requête d'enregistrement de la part d'un terminal utilisateur, vérifie s'il a accès à une information de contexte associée au terminal utilisateur, afin d'obtenir notamment une information relative à une autorisation ou un rejet d'au moins une des tranches du réseau préalablement autorisée ou rejetée lors d'au moins un précédent enregistrement du terminal utilisateur pour un même type d'accès et une même zone d'enregistrement. Par exemple, cette information de contexte correspond à la variable UE context, issue de l'enregistrement précédent et pouvant refléter une accumulation de plusieurs enregistrements précédents selon la présente technique, et comprend notamment une valeur de Allowed NSSAI (identifiants de tranches préalablement autorisées) respectivement Rejected NSSAI (identifiants de tranches préalablement rejetées), que l'on peut noter Allowed NSSAI (UE context) respectivement Rejected NSSAI (UE context). L'obtention des informations de tranche(s) autorisée(s)/rejetée(s) résultant du cumul d'enregistrement précédent avec une ou des tranches possiblement demandées dans la requête d'enregistrement, peut être mise en oeuvre selon différentes variantes, décrites ci-après.

Ensuite, selon que la requête d'enregistrement comprend ou non un ou plusieurs identifiants de tranche à enregistrer, le réseau met en oeuvre des étapes différentes décrites ci-après pour effectuer un enregistrement cumulatif, c'est-à-dire pour ajouter au résultat de l'obtention des informations relatives à un enregistrement précédent, via l'information de contexte, le résultat d'une détermination d'autorisation ou de rejet pour la ou les tranches identifiées dans la requête d'enregistrement, lorsque c'est le cas. Cette détermination délivre par exemple une valeur de Allowed NSSAI (subscription), avec les identifiants de tranches autorisées au regard de la souscription pour le terminal utilisateur, parmi les tranches identifiées dans la requête d'enregistrement, et/ou une valeur de Rejected NSSAI (subscription) avec les identifiants de tranches rejetées au regard de la souscription pour le terminal utilisateur, parmi les tranches identifiées dans la requête d'enregistrement.

L'équipement réseau ayant reçu la requête d'enregistrement dispose donc, potentiellement, des données suivantes :

- Allowed NSSAI (subscription) pour décrire, lorsque la requête (Requested NSSAI) comprend un ou des identifiants de tranches (S-NSSAI), les identifiants de tranches autorisées au regard de la souscription pour le terminal utilisateur ;

- Rejected NSSAI (subscription) pour décrire, lorsque la requête (Requested NSSAI) comprend un ou des identifiants de tranches (S-NSSAI), les identifiants de tranches rejetées au regard de la souscription pour le terminal utilisateur ; - Allowed NSSAI (UE context) pour décrire les identifiants de tranches (S-NSSAI) autorisées déjà contenues dans l'information de contexte associée au terminal utilisateur et accessibles par l'équipement réseau du fait de l'enregistrement précédent ;

- Rejected NSSAI (UE context) pour décrire les identifiants de tranches (S-NSSAI) rejetées déjà contenues dans l'information de contexte associée au terminal utilisateur et accessibles par l'équipement réseau du fait de l'enregistrement précédent.

Ces trois variantes diffèrent entre elles selon la répartition des tâches entre différents équipements du réseau, et notamment entre un équipement de contrôle d'accès (par exemple l'entité réseau AMF, en anglais Access and Mobility Function) et un équipement de sélection d'instance de tranche (par exemple l'entité réseau NSSF en anglais Network Slice Sélection Function) pour déterminer les tranches autorisées/rejetées.

Selon une première variante, l'équipement de contrôle d'accès AMF vérifie s'il a accès à une information de contexte associée au terminal utilisateur, afin d'obtenir notamment une information relative à une autorisation ou un rejet d'au moins une des tranches du réseau préalablement autorisée ou rejetée lors d'au moins un précédent enregistrement du terminal utilisateur pour un même type d'accès et une même zone d'enregistrement. Si tel est le cas, l'équipement de contrôle d'accès AMF obtient donc les valeurs notées Allowed NSSAI (UE context) respectivement Rejected NSSAI (UE context).

Ensuite, l'équipement de contrôle d'accès AMF détermine lui-même quelles sont les tranches identifiées dans la requête qui sont autorisées ou rejetées, au regard de la souscription de l'utilisateur, ou interroge l'équipement de sélection d'instance de tranche NSSF, en lui fournissant le ou les identifiants compris dans la requête (Requested NSSAI) et le ou les identifiants des tranches souscrites (par exemple via le paramètre Subscribed NSSAI), pour obtenir Allowed NSSAI (subscription) et/ou Rejected NSSAI (subscription). Vu du NSSF, cela correspond au traitement tel que standardisé avec usage d'un paramètre Requested NSSAI et Subscribed NSSAI.

Enfin, l'équipement de contrôle d'accès AMF cumule, de préférence sans doublon, les valeurs non-vides précédemment obtenues pour délivrer Allowed NSSAI et/ou Rejected NSSAI telles que :

- Allowed NSSAI = Allowed NSSAI (UE context) + Allowed NSSAI (subscription);

- Rejected NSSAI = Rejected NSSAI (UE context) + Rejected NSSAI (subscription).

Selon cette première variante, c'est donc l'équipement de contrôle d'accès AMF qui cumule l'enregistrement des tranches identifiées dans la requête et les tranches préalablement autorisées/rejetées lors d'un ou des enregistrements précédents.

Selon une situation particulière, une tranche identifiée dans la requête d'enregistrement peut, au vu des données de souscription, nécessiter une étape préalable d'authentification avant d'être autorisée. Dans ce cas, elle n'apparaît ni dans la liste des tranches autorisées ni dans celles des tanches rejetées, mais dans une autre liste, notée par exemple Pending NSSAI.

Par ailleurs, les étapes de vérification de l'accès à une information de contexte associée au terminal utilisateur (afin d'obtenir notamment une information relative à une autorisation ou un rejet d'au moins une des tranches du réseau préalablement autorisée ou rejetée lors d'au moins un précédent enregistrement du terminal utilisateur pour un même type d'accès et une même zone d'enregistrement) et de détermination des valeurs Allowed NSSAI (subscription) et/ou Rejected NSSAI (subscription) peuvent être mises en oeuvre dans n'importe quel ordre et indépendamment, de sorte à ce que l'étape de cumul puisse être mise en oeuvre ensuite.

Selon une deuxième variante, l'équipement de contrôle d'accès AMF vérifie s'il a accès à une information de contexte associée au terminal utilisateur, afin d'obtenir notamment une information relative à une autorisation ou un rejet d'au moins une des tranches du réseau préalablement autorisée ou rejetée lors d'au moins un précédent enregistrement du terminal utilisateur pour un même type d'accès et une même zone d'enregistrement. Si tel est le cas, l'équipement de contrôle d'accès AMF obtient donc les valeurs Allowed NSSAI (UE context), respectivement Rejected NSSAI (UE context).

Ensuite, l'équipement de contrôle d'accès AMF calcule une valeur de « Requested NSSAI cumulé », comme résultant du cumul sans doublon :

- des valeurs de S-NSSAI du Requested NSSAI reçu dans la demande d'enregistrement du terminal utilisateur ;

- des valeurs obtenues Allowed NSSAI (UE context) et éventuellement Rejected NSSAI (UE context).

Enfin, l'équipement de contrôle d'accès AMF interroge l'équipement de sélection d'instance de tranche NSSF en lui fournissant le « Requested NSSAI cumulé » (tel que calculé ci-dessus) et le ou les identifiants des tranches souscrites (par exemple via le paramètre Subscribed NSSAI). L'équipement de sélection d'instance de tranche NSSF procède à la détermination des valeurs :

- Allowed NSSAI, comprenant les identifiants de tranches parmi les valeurs de « Requested NSSAI cumulé » qui sont autorisées au regard de la souscription pour le type d'accès et la zone d'enregistrement considérés ;

- Rejected NSSAI, comprenant les identifiants de tranches parmi les valeurs de « Requested NSSAI cumulé » qui sont rejetées au regard de la souscription pour le type d'accès et la zone d'enregistrement considérés.

Selon cette deuxième variante, c'est donc l'équipement de contrôle d'accès AMF qui cumule les tranches identifiées dans la requête et les tranches préalablement autorisées lors d'un ou des enregistrements précédents avant d'interroger l'équipement de sélection d'instance de tranche NSSF.

Selon une troisième variante, l'équipement de contrôle d'accès AMF interroge l'équipement de sélection d'instance de tranche NSSF pour déterminer quelles sont les tranches identifiées dans la requête qui sont autorisées ou rejetées, au regard de la souscription de l'utilisateur, en lui fournissant le ou les identifiants compris dans la requête (Requested NSSAI) et le ou les identifiants des tranches souscrites (par exemple via le paramètre Subscribed NSSAI), et en lui fournissant également les valeurs obtenues au regard de l'information de contexte Allowed NSSAI (UE context) et/ou Rejected NSSAI (UE context).

Ainsi, à partir de ces valeurs, l'équipement de sélection d'instance de tranche NSSF procède à la détermination des valeurs Allowed NSSAI (subscription) et/ou Rejected NSSAI (subscription) pour les identifiants reçus dans la requête et les cumule avec les valeurs Allowed NSSAI (UE context) et/ou Rejected NSSAI (UE context) pour délivrer Allowed NSSAI et/ou Rejected NSSAI telles que :

- Allowed NSSAI = Allowed NSSAI (UE context) + Allowed NSSAI (subscription);

- Rejected NSSAI = Rejected NSSAI (UE context) + Rejected NSSAI (subscription).

Alternativement, l'équipement NSSF peut calculer une valeur de « Requested NSSAI cumulé », i.e. traiter la demande de AMF comme si la valeur de Requested NSSAI était un « Requested NSSAI cumulé » résultant du cumul sans doublon :

- des valeurs de S-NSSAI du Requested NSSAI de la demande d'enregistrement du terminal utilisateur ;

- des valeurs Allowed NSSAI (UE context) et éventuellement Rejected NSSAI (UE context) et déterminer ainsi les valeurs de :

- Allowed NSSAI, comprenant les identifiants de tranches parmi les valeurs de « Requested NSSAI cumulé » qui sont autorisées au regard de la souscription pour le type d'accès et la zone d'enregistrement considérés ;

- Rejected NSSAI, comprenant les identifiants de tranches parmi les valeurs de « Requested NSSAI cumulé » qui sont rejetées au regard de la souscription pour le type d'accès et la zone d'enregistrement considérés.

Selon cette troisième variante, c'est donc l'équipement de sélection d'instance de tranche NSSF qui cumule l'enregistrement des tranches identifiées dans la requête et les tranches préalablement autorisées lors d'un ou des enregistrements précédents.

Selon une situation particulière, une tranche identifiée dans la requête d'enregistrement peut, au vu des données de souscription, nécessiter une étape préalable d'authentification avant d'être autorisée. Dans ce cas, elle n'apparaît ni dans la liste des tranches autorisées ni dans celles des tanches rejetées, mais dans une aute liste, notée par exemple Pending NSSAI.

Selon ces trois variantes, l'équipement de contrôle d'accès AMF connaît le paramètre Subscribed NSSAI par exemple en interrogeant un autre équipement de gestion de données de souscription (par exemple l'entité UDM selon le standard en vigueur, en anglais Unified Data Management, stockant lui-même ces données de souscription ou apte à les obtenir d'une ou plusieurs autres entités telles que UDR, en anglais Unified Data Repository assurant leur stockage).

Par ailleurs, selon le standard actuel, il est connu d'envoyer des informations vers l'équipement de sélection d'instance de tranche NSSF, comme par exemple les informations de Requested NSSAI et de Subscribed NSSAI. En revanche, la présente technique prévoit de créer un nouveau paramètre pour fournir à l'équipement de sélection d'instance de tranche NSSF les informations de Allowed NSSAI (UE context) et/ou Rejected NSSAI (UE context) pour la troisième variante.

On décrit maintenant la deuxième solution, en relation avec la figure 3, selon laquelle la requête d'enregistrement est différente par rapport au standard pour permettre au terminal utilisateur d'indiquer qu'un enregistrement cumulatif est requis.

Selon une première variante, un paramètre spécifique, indicateur de cumul de tranches, est ajouté dans la requête d'enregistrement et selon une deuxième variante, un paramètre déjà présent dans la requête d'enregistrement est modifié, par ajout d'un paramètre ou par modification d'un paramètre existant. Par exemple, le format du paramètre NSSAI (en anglais Network Slice Sélection Assistance Information, représentant un ensemble de tranches) est augmenté d'un paramètre optionnel, noté additionaIRegistration, de type booléen indiquant :

- quand il est égal à la valeur « 1 », que le terminal utilisateur souhaite effectuer un enregistrement cumulatif ;

- quand il est égal à la valeur « 0 » (ou qu'il n'est pas présent (deuxième solution décrite ci-après)), que le terminal utilisateur ne souhaite pas effectuer un enregistrement cumulatif.

L'équipement réseau interprète ou décode, lors d'une sous-étape de décodage, l'indicateur de cumul de tranches (par exemple le paramètre additionaIRegistration décrit ci-dessus) reçu dans la requête d'enregistrement en provenance du terminal utilisateur, de sorte à délivrer une indication de cumul positive ou négative selon la valeur de l'indicateur.

Ensuite, si l'indication de cumul est positive, i.e. le terminal utilisateur requiert un enregistrement cumulatif, alors l'équipement réseau met en oeuvre une étape d'obtention 300, dans une information de contexte associée au terminal utilisateur, d'une autorisation ou d'un rejet d'au moins une des tranches du réseau préalablement autorisée ou rejetée lors d'au moins un précédent enregistrement du terminal utilisateur pour un même type d'accès et une même zone d'enregistrement. Cette étape 300 est décrite en détails ci-après, en relation avec la deuxième solution.

En revanche, si l'indication de cumul est négative, alors l'équipement réseau met en oeuvre un enregistrement « classique » en tenant compte uniquement des identifiants de tranches spécifiées dans la requête d'enregistrement lorsque c'est le cas, ou délivre une décision d'enregistrement basée uniquement sur le ou les enregistrements précédents, comme décrit ci- après en relation avec la deuxième solution.

En substance, dans l'exemple illustré en figure 3, le terminal utilisateur UE1 demande à s'enregistrer, de manière cumulative, auprès du réseau pour les tranches identifiées par les identifiants S/2 et S/4, l'utilisateur ayant préalablement souscrit les tranches SU à SI 10. Par exemple, et comme décrit ci-après, la requête d'enregistrement comprend ces deux identifiants S/2 et S/4. L'équipement du réseau NE1, à réception 200 de cette requête d'enregistrement cumulatif, et après avoir décodé le paramètre « additionaIRegistration » présent dans la requête d'enregistrement, obtient, lors d'une étape 300, dans une information de contexte associée au terminal utilisateur, le statut des tranches préalablement autorisées ou rejetées lors d'au moins un précédent enregistrement du terminal utilisateur pour un même type d'accès et une même zone d'enregistrement, dans cet exemple, les tranches S/2, S/3, S/5, SI6 et S/7. En l'occurrence, dans cet exemple, les tranches S/3, SI6 et S/7 ont déjà été autorisées et la tranche S/5 a déjà été rejetée. Ensuite, l'équipement du réseau NE1 détermine le statut des tranches identifiées dans la requête, à savoir S/2, autorisée, et S/4, rejetée. Enfin, l'équipement du réseau NE1 délivre une décision d'enregistrement comprenant les tranches autorisées S/2, S/3, SI6 et S/7 et les tranches rejetées S/4 et S/5. Le terminal utilisateur UE1 reçoit donc, en réponse à sa demande d'enregistrement pour 2 tranches, une information plus complète que selon les techniques de l'art antérieur.

Ainsi, dans cet exemple, le cumul d'enregistrement est mis en oeuvre sur demande explicite de l'utilisateur et n'est pas mis en oeuvre par défaut par l'entité réseau.

Selon un autre exemple, l'entité réseau met en oeuvre systématiquement un enregistrement cumulatif dès lors qu'il reçoit une requête d'enregistrement : l'usage d'un paramètre émanant du terminal utilisateur dans sa requête d'enregistrement n'est alors pas nécessaire et quoiqu'il en soit ne serait pas analysé par l'équipement réseau. L'entité réseau met systématiquement en oeuvre l'enregistrement cumulatif en remplacement de l'enregistrement supplétif prévu dans le standard.

Selon un autre exemple, l'entité réseau met systématiquement en oeuvre l'enregistrement cumulatif par choix selon la politique de l'opérateur, ce qui signifie que l'équipement réseau serait apte à faire un enregistrement supplétif selon le standard et un enregistrement cumulatif selon l'invention, et l'opérateur pourrait le configurer pour appliquer l'un plutôt que l'autre selon sa propre politique (à noter que la configuration du type d'enregistrement n'est pas limitative et pourrait couvrir l'enregistrement supplétif, l'enregistrement cumulatif, l'enregistrement global comme dans le deuxième mode de réalisation décrit ci-après, voir d'autres).

Selon un dernier exemple, l'entité réseau met conditionnellement en oeuvre l'enregistrement cumulatif par choix selon la politique de l'opérateur, ce qui signifie que l'équipement réseau serait apte à faire un enregistrement supplétif selon le standard et un enregistrement cumulatif selon l'invention mais mettrait en oeuvre l'enregistrement cumulatif lorsqu'une ou plusieurs conditions sont réunies par exemple seulement pour un terminal loT et/ou un terminal accédant depuis un accès fixe.

Selon une troisième solution, le cumul des enregistrements des tranches éventuellement identifiées dans la requête est mis en oeuvre uniquement avec les tranches préalablement autorisées lors d'un ou plusieurs enregistrements précédents et pour lesquelles le terminal utilisateur a une session de données paquet active. Pour ce faire, l'équipement de contrôle d'accès AMF a accès, via l'information de contexte associée au terminal utilisateur, à des informations de chaque session de données paquets actives (par exemple via le paramètre PDU Session level context) lui permettant notamment de connaître les identifiants des tranches concernées par une session active.

Ce premier mode de réalisation permet donc de limiter le nombre d'enregistrements déclenchés par le terminal utilisateur, car, grâce à l'enregistrement cumulatif, les tranches enregistrées lors d'un enregistrement précédent restent enregistrées lors de l'enregistrement suivant. Cela permet donc de limiter la charge de signalisation dans le réseau. Enfin, cela permet d'éviter une coupure non souhaitée d'une session de données paquet active, même si, par erreur, le terminal utilisateur n'a pas identifié dans la requête d'enregistrement courant la ou les identifiants de tranches pour lesquelles une session de données paquet est en cours.

De plus, ce premier mode de réalisation offre une grande souplesse car l'enregistrement cumulatif peut être demandé par le terminal utilisateur ou être mis en oeuvre à l'initiative du réseau.

Dans le cas particulier où la requête d'enregistrement ne comprend aucun identifiant de tranche, l'équipement réseau délivre une décision d'enregistrement comprenant uniquement les paramètres de tranches autorisées ou rejetées relatifs à un enregistrement précédent. Cela permet notamment par exemple de ne pas interrompre une session de données paquet active sur une tranche que le terminal utilisateur aurait omis d'identifier à nouveau dans la requête d'enregistrement. Enfin, selon une autre variante de réalisation, la réponse de l'équipement réseau après un enregistrement cumulatif comprend un paramètre, par exemple de type booléen, indiquant que l'enregistrement cumulatif résulte dans l'enregistrement de toutes les tranches souscrites. Dans ce cas, au lieu de renvoyer dans la réponse d'enregistrement cumulatif la liste exhaustive des tranches autorisées correspondant à toutes les tranches souscrites, alors le réseau renvoie seulement un paramètre, par exemple noté alIRegistration, de manière à alléger la signalisation.

La présence d'un tel paramètre alIRegistration dans la réponse du réseau à une requête d'enregistrement cumulatif permet au terminal utilisateur de savoir que toutes les tranches souscrites sont autorisées et qu'il peut donc effectuer une demande d'activation de session de données paquet pour n'importe laquelle de ces tranches souscrites. Pour ce faire, le terminal utilisateur doit interpréter ou décoder ce paramètre reçu dans la réponse. Ensuite, selon une première mise en oeuvre, une demande d'activation d'une session de données paquet pour ce terminal utilisateur tient compte de cet indicateur d'enregistrement de toutes les tranches souscrites en utilisant un identifiant parmi les identifiants des tranches souscrites. Selon une deuxième mise en oeuvre, le terminal utilisateur peut, après avoir décodé le paramètre alIRegistration, modifier le contenu de la valeur Allowed NSSAI, stockée localement, en y mettant les identifiants de toutes les tranches souscrites. Ensuite, lors d'une demande d'activation de session de données paquet, le terminal utilisateur se sert de cette valeur pour savoir quelle tranche est autorisée.

Description du deuxième mode de réalisation

Comme indiqué précédemment, le deuxième mode de réalisation met en oeuvre un enregistrement global pour toutes les tranches souscrites en se basant, de manière autonome par l'équipement réseau mettant en oeuvre ce deuxième mode de réalisation, sur une information connue du réseau listant les tranches souscrites associées aux informations de souscription du terminal utilisateur à l'origine de la requête d'enregistrement, et sans tenir compte d'informations transmises ou non par le terminal utilisateur dans la requête d'enregistrement concernant les tranches à enregistrer.

Le traitement de la requête d'enregistrement par le réseau dans ce deuxième mode de réalisation est différent du standard car il concerne un enregistrement global au lieu d'un enregistrement supplétif. Il est à noter également que la requête émise par le terminal utilisateur peut prendre des caractéristiques supplémentaires par rapport au standard. Il sera fait référence à une première solution pour la suite quand la requête est spécifique et comprend donc une caractéristique selon l'invention, une deuxième solution sinon.

On décrit maintenant la première solution, en relation avec la figure 4, selon laquelle la requête d'enregistrement comprend une indication du terminal utilisateur demandant un enregistrement global. De cette manière, pour requérir un enregistrement de toutes les tranches souscrites, le terminal utilisateur n'est pas obligé de spécifier tous les identifiants des tranches souscrites dans la requête d'enregistrement, comme cela est le cas selon les techniques actuelles, ce qui allège fortement la taille de la requête d'enregistrement.

Selon une première variante, cette indication se présente sous la forme d'un paramètre spécifique nouveau par rapport au standard, indicateur d'enregistrement global, ajouté dans la requête d'enregistrement. Selon une deuxième variante, cette indication réutilise un paramètre déjà défini dans le standard, en modifiant un paramètre le composant ou en lui ajoutant un nouveau paramètre. Par exemple, le format du paramètre NSSAI (en anglais Network Slice Sélection Assistance Information, représentant un ensemble de tranches) est augmenté d'un paramètre optionnel, noté alISnssaiRegistration, de type booléen indiquant :

- quand il est égal à la valeur « 1 », que le terminal utilisateur souhaite effectuer un enregistrement global ;

- quand il est égal à la valeur « 0 », que le terminal utilisateur ne souhaite pas effectuer un enregistrement global.

L'équipement réseau interprète ou décode, lors d'une sous-étape de décodage, l'indicateur d'enregistrement global (par exemple le paramètre alISnssaiRegistration décrit ci-dessus) reçu dans la requête d'enregistrement en provenance du terminal utilisateur, de sorte à délivrer une indication d'enregistrement global positive ou négative selon la valeur de l'indicateur.

Ensuite, si l'indication d'enregistrement global est positive, i.e. le terminal utilisateur requiert un d'enregistrement global, alors l'équipement réseau met en oeuvre une étape de détermination autonome 400 d'un statut d'enregistrement (autorisation/rejet/en cours) pour chacune des tranches du réseau souscrites par l'utilisateur identifiées dans un paramètre de réseau comprenant les identifiants de toutes les tranches du réseau souscrites par l'utilisateur, délivrant une décision d'enregistrement. Cette étape de détermination autonome 400 est mise en oeuvre sans tenir compte d'un ou des éventuels identifiants de tranche compris dans la requête.

Par exemple, l'équipement réseau connaît les identifiants des tranches souscrites grâce aux données de souscription du terminal utilisateur obetenues en interrogeant un autre équipement de gestion de données de souscription (par exemple l'entité UDM selon le standard en vigueur, en anglais Unified Data Management, stockant lui-même ces données de souscription ou apte à les obtenir d'une ou plusieurs autres entités telles que UDR, en anglais Unified Data Repository assurant leur stockage). Cette étape 400 est décrite en détails ci-après, en relation avec la deuxième solution.

En revanche, si l'indication d'enregistrement global est négative, alors l'équipement réseau met en oeuvre un enregistrement global « forcé » dans le cas où la requête d'enregistrement ne comprend aucun identifiant de tranche. Sinon, i.e. si au moins une tranche est identifiée dans la requête d'enregistrement, l'équipement réseau ne met pas en oeuvre l'enregistrement selon l'invention et peut mettre en oeuvre les étapes d'un enregistrement classique, ou standard, basé uniquement sur la détermination d'un statut d'enregistrement de la ou les tranches identifiées dans la requête.

Selon cette première solution, la réponse d'enregistrement délivrée par le réseau au terminal utilisateur peut également comprendre un indicateur d'enregistrement global réussi, par exemple le même paramètre alISnssaiRegistration que celui contenu dans la requête. Ce paramètre de réponse est optionnel, de type booléen par exemple, et indique que toutes les tranches souscrites ont été enregistrées (i.e. que toutes les tranches souscrites ont été autorisées) quand il est égal à la valeur « 1 ». Il est égal à la valeur « 0 », dans le cas contraire, i.e. lorsqu'au moins une tranche souscrite a été rejetée, et la réponse de l'équipement réseau est celle décrite ci-après en relation avec la deuxième solution, i.e. elle comprend les identifiants de toutes les tranches souscrites « répartis » selon le statut autorisé/rejeté/en cours (i.e. en attente d'authentification), déterminé pour chaque tranche souscrite.

La présence du paramètre alISnssaiRegistration dans la réponse du réseau à une requête d'enregistrement global permet au terminal utilisateur de savoir que toutes les tranches souscrites sont autorisées et qu'il peut donc effectuer une demande d'activation de session de données paquet pour n'importe laquelle de ces tranches souscrites. Pour ce faire, le terminal utilisateur doit également interpréter ou décoder ce paramètre reçu dans la réponse.

Ensuite, selon une première mise en oeuvre, une demande d'activation d'une session de données paquet pour ce terminal utilisateur tient compte de cet indicateur d'enregistrement global reçu suite à une requête d'enregistrement global, en utilisant un identifiant parmi les identifiants des tranches souscrites.

Selon une deuxième mise en oeuvre, le terminal utilisateur peut, après avoir décodé le paramètre alISnssaiRegistration, modifier le contenu de la valeur Allowed NSSAI, stockée localement, en y mettant les identifiants de toutes les tranches souscrites contenues dans le paramètre Configured NSSAI. Ensuite, lors d'une demande d'activation de session de données paquet, le terminal utilisateur se sert de cette valeur pour savoir quelle tranche est autorisée.

En substance, dans l'exemple illustré en figure 4, le terminal utilisateur UE1 demande à s'enregistrer, de manière globale, auprès du réseau, l'utilisateur ayant préalablement souscrit les tranches SU à SI10. L'équipement du réseau NE1, à réception 200 de cette requête d'enregistrement global, et après avoir décodé le paramètre « alISnssaiRegistration » présent dans la requête d'enregistrement, obtient, lors d'une étape 300, de manière autonome et à partir d'un paramètre de réseau comprenant les identifiants de toutes les tranches du réseau souscrites par l'utilisateur, le statut d'enregistrement de toutes les tranches du réseau souscrites par l'utilisateur, i.e. les tranches SU à SI10. En l'occurrence, dans cet exemple, les tranches souscrites SU, SI2, SI3, SI6, SI7 et SI9 sont autorisées et les tranches souscrites S/4, S/5, SI8 et SI10 sont rejetées. Ensuite, l'équipement du réseau NE1 délivre une décision d'enregistrement comprenant les tranches autorisées SU, SI2, SI3, SI6, SI7 et SI9 et les tranches rejetées SI4, SI5, SI8 et SI10. Le terminal utilisateur UE1 reçoit donc, en réponse à sa demande d'enregistrement global, une information plus complète que selon les techniques de l'art antérieur.

Ainsi, dans cet exemple comme dans l'exemple précédent relatif à l'enregistrement cumulatif, le cumul d'enregistrement est mis en oeuvre sur demande explicite de l'utilisateur et n'est pas mis en oeuvre par défaut par l'entité réseau.

Selon un autre exemple, l'entité réseau met en oeuvre systématiquement un enregistrement global dès lors qu'il reçoit une requête d'enregistrement : l'usage d'un paramètre émanant du terminal utilisateur dans sa requête d'enregistrement n'est alors pas nécessaire et quoiqu'il en soit ne serait pas analysé par l'équipement réseau. L'entité réseau met systématiquement en oeuvre l'enregistrement global en remplacement de l'enregistrement supplétif prévu dans le standard.

Selon un autre exemple, l'entité réseau met systématiquement en oeuvre l'enregistrement global par choix selon la politique de l'opérateur, ce qui signifie que l'équipement réseau serait apte à faire un enregistrement supplétif selon le standard et un enregistrement global selon l'invention, et l'opérateur pourrait le configurer pour appliquer l'un plutôt que l'autre selon sa propre politique (à noter que la configuration du type d'enregistrement n'est pas limitative et pourrait couvrir l'enregistrement supplétif, l'enregistrement cumulatif, l'enregistrement global, voir d'autres).

Selon un dernier exemple, l'entité réseau met conditionnellement en oeuvre l'enregistrement global par choix selon la politique de l'opérateur, ce qui signifie que l'équipement réseau serait apte à faire un enregistrement supplétif selon le standard et un enregistrement global selon l'invention mais mettrait en oeuvre l'enregistrement cumulatif lorsqu'une ou plusieurs conditions sont réunies par exemple seulement pour un terminal loT et/ou un terminal accédant depuis un accès fixe.

On décrit maintenant la deuxième solution, c'est-à-dire les étapes d'enregistrement global mises en oeuvre par le réseau, différentes de celles mises en oeuvre par le standard en vigueur par exemple.

Pour ce faire, l'équipement de contrôle d'accès AMF détermine les tranches autorisées/rejetées pour l'ensemble des slices souscrites et enregistre l'ensemble des tranches souscrites autorisées, que cela soit à son initiative ou à celle du terminal utilisateur via un indicateur d'enregistrement global, mais toujours indépendamment des tranches éventuellement demandées par le terminal utilisateur dans sa requête d'enregistrement.

Cette détermination des tranches autorisées/rejetées est réalisée par l'entité réseau seule ou en coopération avec une autre entité réseau (typiquement AMF avec NSSF) pour toutes les tranches souscrites et non plus pour les tranches spécifiquement identifiées dans la requête d'enregistement.

Selon une situation particulière, une tranche souscrite identifiée dans les données de souscription peut nécessiter une étape préalable d'authentification avant d'être autorisée. Dans ce cas, elle n'apparaît ni dans la liste des tranches autorisées ni dans celles des tanches rejetées, mais dans une autre liste, notée par exemple Pending NSSAI.

La réponse de l'équipement réseau comprend donc le résultat de cet enregistrement global, à savoir une valeur de Allowed NSSAI comprenant les identifiants des tranches souscrites et autorisées, et/ou une valeur de Rejected NSSAI comprenant les identifiants des tranches souscrites et rejetées, et/ou une valeur de Pending NSSAI comprenant les identifiants des tranches en attente d'authentification avant autorisation, chacun des identifiants des tranches souscrites se trouvant dans l'un ou l'autre de ces trois paramètres.

Ce deuxième mode de réalisation permet donc de limiter le nombre d'enregistrements déclenchés par le terminal utilisateur, car, grâce à un seul enregistrement global, le statut autorisé/rejeté/en attente d'authentification est déterminé en un seul enregistrement pour toutes les tranches souscrites. Cela rend donc inutile des enregistrements multiples. Cela permet donc de limiter la charge de signalisation dans le réseau.

De plus, lorsque l'indicateur d'enregistrement global est utilisé dans la requête, la taille de cette requête s'en trouve fortement réduite, car il n'est plus nécessaire d'y indiquer un ou plusieurs identifiants de tranches.

De plus, ce deuxième mode de réalisation offre également une grande souplesse car l'enregistrement global peut être demandé par le terminal utilisateur ou être mis en oeuvre à l'initiative du réseau. Dans ce cas (deuxième solution du deuxième mode de réalisation), l'enregistrement pour toutes les tranches souscrites est garanti par défaut, sans ajout de paramètre spécifique si cela est paramétré par l'opérateur. Il est à noter que cela ne pénalise en aucun cas le terminal dans l'usage des services mais qu'au contraire cela lui donne un accès potentiel à plus de tranches enregistrées et donc plus de services qu'avec le standard.

Ce deuxième mode de réalisation permet d'enregistrer toutes les tranches en une seule procédure d'enregistrement, tout en limitant la taille des messages de requête et en corollaire la réponse du réseau dans le cas de la première solution. Enfin, comme pour le premier mode de réalisation, ce deuxième mode de réalisation permet de maintenir actives des sessions de données paquet, même si le terminal utilisateur n'identifie pas les tranches concernées dans une énième requête d'enregistrement, puisque l'enregistrement global ne peut pas retirer une tranche qui aurait été préalablement autorisée, pour un même type d'accès et une même zone d'enregistrement.

Description du contrôle de tranches préalable

La technique proposée permet de limiter encore la signalisation dans le réseau, quel que soit le mode de réalisation mis en oeuvre, en évitant des demandes d'enregistrement inutiles. Pour ce faire, une étape de vérification est mise en oeuvre, préalablement aux étapes détaillées ci-dessus en relation avec les premier et deuxième modes de réalisation. Cette étape de vérification peut être mise en oeuvre par le terminal utilisateur, selon une première variante, ou par un équipement réseau, selon une deuxième variante, et permet de ne transmettre/traiter une requête d'enregistrement que si au moins une tranche concernée par un enregistrement à venir n'a pas déjà été autorisée ou rejetée, pour un même type d'accès et une même zone d'enregistrement.

Cette étape de vérification n'est mise en oeuvre que lorsque l'enregistrement à venir n'est ni un premier enregistrement, ni un enregistrement suite à un changement de zone d'enregistrement du terminal utilisateur, ni un enregistrement dû à une expiration d'une durée d'un enregistrement précédent. En d'autres termes, la vérification n'est mise en oeuvre que pour une requête d'enregistrement dans le cadre d'un changement de tranche.

Selon une première variante, le terminal utilisateur vérifie que le ou les identifiants de tranche qu'il prévoit de signaler dans sa requête d'enregistrement à venir ne sont présents dans les paramètres stockés localement listant les tranches autorisées (Allowed NSSAI) et listant les tranches rejetées (Rejected NSSAI). Si cette vérification est négative, la requête d'enregistrement est transmise au réseau, sinon, elle est modifiée de manière à ne pas contenir d'identifiants de tranche préalablement autorisée ou rejetée. Cette mise en oeuvre se distingue des techniques actuelles basées sur le standard en vigueur, selon lesquelles le terminal utilisateur doit obligatoirement identifier dans toute requête d'enregistrement les identifiants des tranches pour lesquelles une session de données paquet est active, sous peine que cette session soit interrompue/désactivée. En effet, comme décrit précédemment, un enregistrement cumulatif ou un enregistrement global permet, selon toutes les variantes possibles, de ne pas interrompre une session de donnée en cours.

Selon une deuxième variante, c'est l'équipement réseau qui met en oeuvre cette étape de vérification, à réception d'une requête d'enregistrement. Ainsi, si l'équipement réseau reçoit une requête d'enregistrement comprenant une ou plusieurs tranches, chacune étant déjà connue du réseau en tant que tranche autorisée ou tranche rejetée, i.e. par exemple que l'équipement de contrôle d'accès AMF l'a déjà dans l'information de contexte associée au terminal utilisateur (UE context), alors il rejette la demande d'enregistrement. En effet, cette requête est inutile car le terminal utilisateur n'a identifié dans sa requête que des tranches pour lesquelles il a déjà connaissance du statut autorisé/rejeté.

Cette deuxième variante suppose donc que l'équipement réseau sait faire la différence entre ce type de requête d'enregistrement pour changement de tranche et une requête de réenregistrement pour mobilité par exemple. Ainsi, il convient que l'équipement réseau ne mette pas en oeuvre cette étape de vérification, lorsque la requête d'enregistrement contient un paramètre de type d'enregistrement qui peut être, selon les spécifications actuelles :

- un enregistrement initial ("initial registration") ;

- un enregistrement après un déplacement du terminal utilisateur ("mobility registration updating") ;

- un enregistrement périodique ("periodic registration updating") ;

- un enregistrement d'urgence ("emergency registration") mais que l'équipement réseau mette en oeuvre cette étape de vérification pour une demande d'enregistrement pour changement de tranche spécifique à la présente technique, cette demande étant distinguée des autres types de demandes d'enregistrement avec une valeur nouvelle pour le paramètre de type d'enregistrement, par exemple « registration updating for slice(s) change ».

La présente technique permet, selon ses différents modes de réalisation et variantes, d'optimiser la procédure d'enregistrement d'un équipement utilisateur (UE) dans un réseau de communications organisé en tranches de réseau, par exemple un réseau 5G et pourrait s'appliquer à toute future génération de réseaux utilisant l'organisation en tranches. Les différents modes de réalisation sont basés sur un concept inventif basé sur un aspect cumulatif de la détermination des tranches autorisées/rejetées et non plus sur la détermination d'autorisation ou du rejet des tranches spécifiquement identifiées dans la requête d'enregistrement comme c'est le cas selon les techniques actuelles.

Selon le premier mode de réalisation relatif à un enregistrement cumulatif, un cumul des statuts d'enregistrement de tranches est mis en oeuvre par rapport à un éventuel enregistrement précédent, limitant le nombre d'enregistrements déclenchés par le terminal utilisateur, et donc la charge de signalisation dans le réseau, et évitant une coupure non souhaitée d'une session de données paquet active, même si, par erreur, le terminal utilisateur n'a pas identifié dans la requête d'enregistrement courant la ou les identifiants de tranches pour lesquelles une session de données paquet est en cours. Selon le deuxième mode de réalisation relatif à un enregistrement global, toutes les tranches souscrites peuvent être enregistrées avec une seule procédure, donnant donc accès au terminal utilisateur à tous les services souscrits/toutes les tranches souscrites tout en limitant la signalisation dans le réseau (pas besoin de plusieurs procédures d'enregistrement pour le même type d'accès et la même localisation du terminal utilisateur).