Cet article présente une évolution du standard R.15 pour une transmission de données montante (UPLINK) dans le cas d’une transmission de type machine MTC et pour un terminal IoT 4G.
La transmission PUR s’effectue sur une interface 4G entre deux entités qui supportent cette transmission, c’est-à-dire soit entre un UE et une eNB ou une ng-eNB.
Le cœur de réseau peut être un cœur de réseau 4 (EPC) ou un cœur de réseau 5G (5GS).
Sur un cœur de réseau 4G, l’état RRC du mobile est soit en veille (RRC_IDLE), soit en mode connecté (RRC_CONNECTED). Pour la procédure de transmission PUR, l’état du mobile est obligatoire en veille (RRC_IDLE).
En mode de veille, le terminal écoute les informations émises par la station de base. Pour transmettre des données sur des ressources tempo-fréquentielles dédiées, le smartphone doit passer en mode connecté.
La procédure d’accès aléatoire permet de passer de l’état de veille à l’état connecté, ce qui nécessite un échange de 4 messages (dont 2 messages RRC) entre le mobile et la station de base.
La transmission PUR permet de réaliser une transmission UPLINK lorsque le terminal est à l’état RRC_IDLE sans avoir besoin de réaliser de procédure d’accès aléatoire puisque le terminal est pré-configuré pour une transmission montante, c’est à dire que le terminal dispose déjà des informations sur les ressources tempo-fréquentielles UPLINK à utiliser pour transmettre ses données à la station de base.
La configuration PUR est transmise par la station de base au terminal UE lorsque celui-ci en fait la demande et à l’état RRC_CONNECTED. Cela ne peut s’appliquer que dans la cellule ou la demande a été faite. La configuration est transmise sous condition de disposer des droits (information d’inscription ou de politique local).
Figure 1 : Pré-configuration du terminal par la station de base
Le terminal UE indique à la station de base qu’il souhaite obtenir une préconfiguration PUR par la requête PURConfigurationRequest. Cette requête demande les informations suivantes :
- Nombre d’occurrences
- Périodicité (par fenêtre temporelle de 10,24 secondes)
- La taille du bloc de données TBS
- Time offset (TA)
La station de base transmet la configuration PUR au mobile lors de la libération de la connexion radioélectrique afin que le mobile soit à l’état RRC_IDLE.
Le terminal peut transmettre ses données lors d’une occurrence configurée, la station de base étant en écoute de l’éventuel message émis par le terminal. La pré-configuration revient donc à réserver une ressource tempo-fréquentielle pour permettre au terminal d’émettre ses données sur un canal radio dédiée. Afin d’éviter de conserver cette ressource sur une durée trop longue, un nombre d’occurrence et de périodicité définie la durée de validité de la transmission PUR
La transmission PUR est déclenchée quand les couches supérieures demande l’établissement ou la reprise de la connexion RRC. Une fois le paquet émis, la configuration PUR est supprimée. Le terminal ne pourra donc pas re-transmettre tant qu’il n’aura pas une autre pré-configuration.
En mode de veille, le terminal UE peut transmettre les données selon :
- L’optimisation du plan de contrôle CIoT EPS/5GS Optimization via la requête RRCEarlyDataRequest (Figure 2);
- La station de base peut à son tour transmettre des données via la requête RRCEarlyDataComplete sur les ressources tempo-fréquentielles proposées dans la configuration PUR. Par contre, si la taille des données est supérieure à la taille du TBS, le mobile enverra la requête RRCConnectionRequest à la place (fall back to the legacy RRC Connection establishment procedure, a new C-RNTI can be assigned)
- S’il n’y a pas de données, la station de base acquitte la requête PUR par une réponse HARQ et éventuellement des informations de commandes TA (message DCI).
- L’optimisation du plan de trafic CIoT EPS/5GS Optimization via la requête RRCConnectionResumeRequest (Figure 3)
Figure 2 : La transmission PUR avec l’optimisation du plan de contrôle
Figure 2 : La transmission PUR avec l’optimisation du plan de contrôle
Figure 3 : La transmission PUR avec l’optimisation du plan de trafic
Figure 4 : Les types de transmissions IoT sur les réseaux 4G et 5G