Comment fonctionne le service de notification? C'est ce que nous allons voir dans cette vidéo. Le réseau est au courant d'un grand nombre d'évènements qui se produisent. Par exemple, sur les actions des utilisateurs, lorsque un UE change de zone de suivi, c'est à dire de tracking area, c'est un évènement de mobilité, il y a une mise à jour de localisation qui est gérée par l'AMF. Cet évènement est donc connu de l'AMF. Lorsqu'un utilisateur met en route ou éteint son terminal, il y a un enregistrement et un désenregistrement à la fin de l'UE, c'est géré par l'AMF, et donc connu de lui. De la même façon, le SMF gère l'établissement et la libération des sessions PDU. On a d'autres évènements possibles, par exemple, la modification du profil d'abonné dans l'UDM ou la modification d'un niveau de qualité de service QoS, d'une session PDU, ça c'est géré par le PCF. On a un grand nombre d'évènements qui sont gérés par les différentes NF, la notification d'évènements peut ouvrir le champ à une large panoplie de services à valeur ajoutée. C'est donc extrêmement intéressant. Il y a définition de service de notification et pour en disposer, il faut que la NF qui désire l'avoir, souscrive à un abonnement. On a donc une procédure de souscription et une procédure de désouscription. Voyons le principe général, nous l'avons déjà un peu évoqué, nous avons une NF consommatrice, qui veut être notifiée d'évènements se produisant dans une NF productrice. Pour ce faire, la NF consommatrice envoie une méthode POST, qui est acquittée positivement avec une réponse en 200, et lorsque l'évènement se produit dans la NF productrice, c'est elle qui va notifier et donc envoyer un POST avec une réponse, on l'espère, positive. Pendant cette phase, la NF productrice agit comme client HTTP et la NF consommatrice comme serveur HTTP, on a donc une inversion des rôles. La NF productrice devient NF consommatrice et vice versa de l'autre côté. Lorsque l'évènement se produit, nous l'avons dit, un POST est envoyé. Ce POST correspond à une URI. Cette URI est liée à une ressource du côté de la NF consommatrice, il faut donc que au moment de la souscription, il y ait création, dans la NF consommatrice, d'une URI de rappel. Cette URI de rappel est envoyée dans la demande, le POST initial, stocké par la NF productrice, et dès que l'évènement se produit, c'est cette URI de rappel qui est associée au POST qui est envoyé par la NF productrice. Il faut donner la possibilité pour une NF consommatrice d'arrêter la souscription si elle le désire. Pour ce faire, on va utiliser une méthode DELETE mais, même raisonnement, il faut une URI dans cette méthode DELETE. Il y a, éventuellement, plusieurs NF qui ont souscrit des notifications auprès de cette NF productrice, il faut donc que chaque souscription soit identifiée de manière unique. Pour ce faire, la NF productrice va choisir une identité de souscription et va l'utiliser pour créer une URI qui est envoyée dans la réponse à la souscription. Cette URI est stockée par la NF consommatrice et, si la NF consommatrice veut arrêter la souscription, elle va utiliser cette URI qui a été créée, dans la demande. Ainsi, la ressource qui correspond à la souscription est effacée. La souscription se fait, comme toute souscription d'abonnement, pour une durée limitée. On va donc rajouter une limite de temps qui est mise sous la forme d'une date d'expiration. Il y a une date qui est demandée par la NF consommatrice et la date choisie par la productrice qui doit être inférieure ou égale à la date proposée. Lorsque la date arrive, ça correspond à une durée maximale de souscription, la ressource est effacée. Voyons sur un exemple un petit plus précis un scénario de notification. Le SMF ici cherche à être notifié des modifications du profil utilisateur dans l'UDM. C'est un service qui est fourni par l'UDM dans l'API nudm-sdm pour subscriber data management. La souscription se fait pour un abonné donné, un UE donné, identifié par son SUPI, et ensuite le mot clé sdm-subscriptions correspond à ce service particulier. Nous avons l'URI de rappel que nous avons déjà évoquée, ainsi que les autres champs. Il y a stockage de l'URI de rappel, choix d'une identité de souscription par l'UDM, et c'est cette identité qui va permettre de créer l'URI correspondant à la souscription, on réutilise les champs précédents de la demande et on créé une ressource fille, en rajoutant l'identité de souscription. Si le SMF veut arrêter la souscription, il utilise cette URI, comme on le constate dans l'exemple. Lorsque l'évènement se produit, nous avons, comme précédemment, utilisation de l'URI de rappel. En résumé, les services de notifications commencent par une phase de souscription, la NF consommatrice place l'URI de rappel, ou callback URI, dans la demande de souscription, la NF productrice créé une nouvelle ressource avec une identité de souscription, ou subscription ID, et place l'URI ainsi formée dans la réponse à la souscription. Quand l'évènement à notifier se produit, on a changement des rôles. La NF productrice devient consommatrice et la NF consommatrice devient productrice. Il y a deux cas pour la fin de la souscription, soit c'est effacé par un DELETE par la NF consommatrice, soit c'est la limite de temps qui a été fixée. [MUSIQUE] [MUSIQUE]
