Presentation

Diameter est un protocole applicatif(fonctionne sur la couche application si nous

considérons le modèle en couches OSI) permettant de décrire des associations clefs-
valeurs, de manière extensible. L'essentiel de ces associations sont définies par
l'IANA(Internet Assigned Numbers Authority), même s'il existe des extensions
propriétaires.

À l'origine, il est conçu pour faire de l'authentification, et succéder au protocole

RADIUS(Remote Authentication Dial-In User Service). Ses objectifs, qui définissent
les pré-requis minimums nécessaires pour un protocole AAA(Authentication,
Authorization, Accounting/Auditing), sont initialement décrits par la RFC 3588.Il est
notamment utilisé dans le cœur des réseaux de téléphonie mobile 4G/LTE pour faire
communiquer les différents équipements du cœur de réseau, tel que le HSS, le MME
ou le PCRF. Diameter est un protocole AAA basé sur les messages, dans lequel les
nœuds AAA échangent des messages et reçoivent un accusé de réception positif ou
négatif pour chaque message échangé entre les nœuds. Pour l'échange de messages, il
utilise en interne TCP et SCTP, ce qui le rend fiable

Rôle
Le protocole de base Diameter fournit des services d'authentification, d'autorisation et
de comptabilité (AAA) sur les réseaux 3G, IMS(IP Multimedia Subsystem) et 4G
pour des applications telles que l'accès au réseau et la mobilité des données. Les
protocoles AAA constituent la base de l'administration des services dans le secteur
des télécommunications. Ils permettent notamment de déterminer les services
auxquels un utilisateur peut accéder, à quelle qualité de service (QoS) et à quel coût.

Depuis l'introduction de la technologie IP dans un réseau de télécommunication, le

protocole Diameter a été choisi comme protocole AAA pour tous les réseaux fixes et
mobiles. Diameter jouit d'un avantage concurrentiel sur les solutions AAA existantes
et constitue le fondement du système EPS (Evolved Packet System), le nouveau
réseau principal prenant en charge la technologie LTE(Long Term Evolution)

Fonctionnement
Le protocole Diameter assure l’échange de message. Diameter est conçu comme une
architecture peer-to-peer, et chaque hôte qui implémente le protocole Diameter peut
agir en tant que client ou serveur ou agent en fonction du déploiement du réseau. Le
nœud Diameter qui reçoit la demande de connexion de l'utilisateur agira en tant que
client Diameter. Dans la plupart des cas, un client Diameter sera un serveur d'accès au
réseau. Après avoir collecté les informations d'identification de l'utilisateur, telles que
le nom d'utilisateur et le mot de passe, il enverra un message Diameter (unité de base
utilisée pour envoyer des commandes ou envoyer des notifications à d'autres nœuds )
de demande d'accès à un nœud Diameter(serveur Diameter) servant la demande. Le
serveur Diameter authentifie l'utilisateur en fonction des informations fournies. Si le
processus d'authentification réussit, les privilèges d'accès de l'utilisateur sont inclus
dans le message de réponse et renvoyés au client Diameter correspondant. Sinon, un
message de rejet d'accès est envoyé. La découverte dynamique des voisins permet à
un client Diameter de découvrir le premier saut avec lequel communiquer et à un
agent de découvrir le prochain agent auquel transférer un message donné. Elle peut se
faire via les protocoles SERVLOC ou DNS.

Chaque noeud Diameter maintient deux tables : une table des peers et une table de
routage. La première contient l'ensemble des voisins et fournit diverses informations
sur ceux-ci. En particulier, le statut de la communication. En effet, Diameter offre la
possibilité d'établir des sessions entre deux nœuds. Dans ce cadre, la table des peers
indique l'état de la connexion avec les voisins.

Bien que l’architecture qui vient d’être décrite ressemble à une architecture client-
serveur traditionnelle, un nœud faisant office de serveur Diameter pour certaines
demandes peut en réalité jouer le rôle de client Diameter dans certaines situations

Diameter gère l'authentification et l'autorisation par voie de passage de messages

généralisée qui est personnalisé par l'application utilisée . De cette façon , Diameter
permet aux applications individuelles l’exécution des fonctions applicables à leur
utilisation . Une caractéristique importante est l'application de la non-duplication des
documents comptables à l'aide de session et ID de message .

Messages Diameter
Un message Diameter est l'unité de base pour envoyer une commande ou envoyer
une notification aux autres nœuds Diameter. À des fins différentes, le protocole
Diameter a défini plusieurs types de messages Diameter, qui sont identifiés par leur
code de commande. Par exemple, un message Accounting-Request reconnaît que le
message contient des informations relatives à la comptabilité, tandis qu'un message
Capability-Exchange-Request reconnaît que le message contient des informations sur
les capacités du nœud Diameter qui envoie le message.

Comme le style d'échange de messages de Diameter est synchrone, chaque message a

sa contrepartie correspondante, qui partage le même code de commande. Dans les
deux exemples précédents, le destinataire d'un message Accounting-Request prépare
un message Account-Answer et l'envoie à l'expéditeur d'origine.

Le code de commande est utilisé pour identifier l'intention d'un message, mais les
données réelles sont acheminées par un ensemble de paires AVP (Attribute-Value-
Pairs). Le protocole Diameter a prédéfini un ensemble d'attributs communs et impose
à chaque attribut une sémantique correspondante. Ces AVP contiennent les
informations relatives à AAA ainsi que des informations de routage, de sécurité et de
capacité entre deux nœuds Diameter. De plus, chaque AVP est associé à un format de
données AVP, défini dans le protocole Diameter (OctetString, Integer32, par
exemple). Par conséquent, la valeur de chaque attribut doit suivre le format de
données suivant:
Format du paquet de diamètre

Legende
Length :
Contient la taille du message (entete + payload)
Flags :
Permet d’identifier le type de message
Command Code :
Code pour identifier chaque type de requête de manière unique. La réponse à la
requête possède le même code. Cependant, son bit 'R' permet de la différencer de la
requête.
Application-ID :
Chaque Application Diameter possède un identifiant unique. Ce champ permet donc
d'identifier l'application concernée par le message. S'il s'agit d'un message défini dans
Diameter Base alors cet ID est '0'.
Hop-by-Hop identifier :
Une architecture Diameter peut être composée d'un client, d'un serveur et de plusieurs
noeuds Diameter intermédiaires (cf. Diameter Agents). Chaque message possède
donc un identifiant de saut-par-saut, autrement dit, modifié par chaque noeud traversé
par le message.

End-to-End identifier :
Identifiant de bout en bout d'un message. La réponse à une requête possède le même
identifiant que cette requête. Ainsi, un client peut détecter la réponse à une requête
qu'il a émis.

La payload est constituée d'un ensemble de paires attributs-valeur (AVP). .

 Avantages
Diameter a été développé à mesure que AAA évoluait pour répondre à des besoins
supplémentaires, tels que le contrôle des politiques, les règles dynamiques, la qualité
de service, l'allocation de bande passante et les nouveaux systèmes de facturation. Il
est également possible que le protocole de base Diameter soit étendu à de nouvelles
applications, via l’ajout de nouvelles commandes D'autres mises à niveau de la 4G,
telles que la fonctionnalité temps réel pour les transactions, ne peuvent être gérées
qu'avec le protocole Diameter.

Parmi les avantages du protocole Diameter par rapport à son prédécesseur RADIUS,
citons:

● Evolutivité illimitée pour permettre la croissance

● Tolérance aux pannes pour garantir la livraison du message
● Prise en charge des agents pour définir clairement les agents de proxy, de
redirection, de relais ou de traduction
● Transmission sécurisée des paquets de messages Diameter
● Transmission fiable sur TCP ou SCTP

Types d’agent DIAMETER

Une architecture Diameter est composée de différents noeuds dits "Diameter agents".
Chaque agent a un rôle bien défini dans les spécifications du protocole. Tous les
agents peuvent initiés des requêtes. Dans ce sens, ils forment un réseau de peer-to-
peer. Les quatres types d'agents existants sont :
• L'agent relais
• L'agent Proxy
• L'agent de redirection
• L'agent de translation

L'agent relais
Le rôle de cet agent est de router les messages vers la bonne destination en fonction
des informations contenues dans celui-ci telles que l'id de l'application ou l'AVP
"Destination-Realm". Typiquement, le Proxy est placé entre le client Diameter et
plusieurs serveurs de différentes applications. Ainsi, en fonction de l'application cible
d'une requête émise par le client, le proxy pourra transmettre celle-ci vers le bon
serveur. On évite ainsi de configurer le client pour qu'il prenne en compte chaque
serveur. De plus, le proxy peut modifier les messages en ajoutant des AVPs. Dans ce
cadre, il peut par exemple modifier le contrôle d'accès à certaines ressources pour un
domaine donné.

L'agent Proxy
Un agent proxy peut également être utilisé pour transférer des messages, mais
contrairement à un agent de relais, un agent proxy peut modifier le contenu du
message et, par conséquent, fournir des services à valeur ajoutée, appliquer des règles
sur différents messages ou effectuer des tâches administratives pour un domaine
spécifique,

L'agent de redirection
L'agent de redirection centralise les informations de routages. Il peut être interrogé
par n'importe quel noeud ne sachant pas où transmettre un message. L'agent de
redirection répond alors avec les informations de redirection. L'utilisation de cet
agent permet d'alléger les configurations locales aux noeuds qui n'ont plus besoin de
conserver les informations de routage localement.

L'agent de translation
L'agent de translation permet l'interopérabilité de Diameter avec d'autres protocoles
AAA. Prenons l'exemple de RADIUS. L'agent de translation change les messages
RADIUS en leur equivalent Diameter (s'il existe). L'intérêt peut être d'assurer une
migration en douceur vers Diameter, en conservant des clients et serveurs RADIUS
pendant la phase de transition.
H248
Presentaion de H,248
Le protocole H.248 spécifié par l’IETF (Internet Engineering Task Force) dans le
RFC 3525 présente de nombreuses similarités avec son prédécesseur, le protocole
MGCP (Media Gateway Control Protocol) aussi défini par l'IETF dans le RFC 2705.
Il s’agit d’un protocole de contrôle entre les entités MGC (Media Gateway
Controller) et MGW (Media Gateway) de l'architecture NGN (Next Generation
Network). Le MGC contrôle les activités des MGWs. Le MGC prend en charge le
contrôle et la signalisation de l’appel alors que les MGWs reçoivent des instructions
des MGCs leur indiquant les actions qu’ils doivent entreprendre. Également appelé
MEGACO (Media Gateway Control Protocol) ,le protocole H.248 permet d’établir,
de maintenir et de terminer les appels entre plusieurs points d’extrémité.En d’autres
termes, c’est un standard permettant la communication entre les Media Gateway
Controller (MGC) et les Media Gateway (MG).Il permet en outre :
• Support de services multimédia et de vidéoconférence
• Possibilité d’utiliser UDP ou TCP
• Utilise le codage en mode texte ou binaire

Composition de MEGACO
Le modèle de connexion du protocole MEGACO est un modèle orienté objet. Il
décrit lesentités logiques ou objets au sein du MGW qui peuvent être contrôlés par le
MGC. Les principales abstractions utilisées dans ce modèle de connexion sont les
terminaisons et les contextes.
• Les terminaisons représentent des flux entrant ou sortant de la MG (par
exemple, des lignes téléphoniques analogiques, des flux RTP ou des flux MP3).
Les terminaisons ont des propriétés, telles que la taille maximale d'un tampon
de gigue pouvant être inspecté et modifié par le contrôleur MGC.Les
terminaisons peuvent être placées dans des contextes définis comme se
produisant lorsque deux ou plusieurs flux de terminaison sont mélangés et
connectés ensemble.
• Les contextes sont créés et libérés par la MG sous commandement du MGC.
Un contexte est créé en ajoutant la première terminaison, et est libéré en
supprimant (soustrayant) la dernière terminaison. Une terminaison peut avoir
plusieurs flux et un contexte peut donc être un contexte multi-flux.

Fonctionnement du protocole
Le protocole H,248 contient un ensemble de commandes permettant de manipuler les
entités logiques décrites dans le modèle de connexion (à savoir les terminaisons et les
contextes). Plus précisément, les commandes proposées par MEGACO sont les
suivantes:

Add - ajoute une terminaison à un contexte. Il est également utilisé pour créer
implicitement un contexte (un contexte est créé dès que la première terminaison y est
ajoutée).
Modify - modifie les propriétés d'état d'une terminaison et les propriétés spécifiques
aux flux de média.

Subtract - supprime une terminaison d'un contexte. Il est également utilisé pour
supprimer implicitement un contexte. Semblable à la création d'un, soustraire la
dernière terminaison d'un contexte supprime le contexte.

Move - déplace une terminaison spécifique d'un contexte à un autre.

AuditValue - renvoie les propriétés de terminaison en cours ainsi que les événements,
signaux et statistiques d'une cessation d' emploi.

AuditCapabilities - renvoie toutes les valeurs possibles pour les propriétés de la

terminaison, ainsi que les signaux et événements autorisés par une passerelle
multimédia particulière.

Notify - utilisé par la passerelle multimédia pour signaler au contrôleur de la

passerelle multimédia certains événements.

ServiceChange - utilisé par la passerelle multimédia pour informer le contrôleur de

passerelle multimédia de modifications spécifiques du service

Transactions MEGACO
Le protocole MEGACO permet à ces deux entités MGC et MGW de s’échanger des
transactions. Chaque transaction s’exprime par l’envoi d’une transactionRequest par
l’une des entités et l’envoi d’une transactionReply par l’autre entité. Une transaction
consiste en une ou plusieurs actions. Une action est un ensemble de commandes
s’appliquant à un contexte donné. Chaque action spécifie donc un identificateur de
contexte (contextID) et des commandes à appliquer au contexte. Il existe des cas où
un contextID n’est pas spécifié.Par exemple, lorsque le MGC demande au MGW de
créer un contexte. C’est le MGW qui affectera alors un identificateur au contexte.
Une transaction est émise sous la forme d’une transactionRequest. La réponse est
encapsulée dans une transactionReply. Cette dernière peut être précédée par une ou
plusieurs transactionPending. Le récepteur indique à travers une transactionPending
que la transaction est en cours de traitement mais non complètement exécutée ; une
transactionReply suivra. Cela permet à l’émetteur de ne pas considérer que la
transactionRequest a été perdue.
Une transactionRequest consiste en une suite de commandes alors qu’une
transactionReply contient une suite de réponses correspondantes tandis qu’une
TransactionPending est une réponse intermédiaire permettant d’indiquer à l’émetteur
que sa transactionRequest a bien été reçue et qu’elle est en cours de traitement.
 Role H,248
La signalisation H.248 entre les softswitches et les passerelles de média (SG, TG,
MG) a plusieurs fonctions :
• Monter et démonter des connexions de transport.
• Notifier des événements analogiques (décrocher le combiné, ...).
• Notifier des signaux Inband (Tonalités DTMF).
• Appliquer les signaux Inband (tonalités, annonces, ajouter, supprimer.)

Comparaison avec MGCP

Le modèle H.248 / Megaco est plus complexe que le modèle MGCP (Media Gateway
Control Protocol) et offre plus de flexibilité lors de la définition du contrôle de média.
Par exemple, dans MGCP, un appel peut utiliser une conférence en mode terminal
pour gérer le mélange de flux, mais il ne peut pas atteindre le contrôle de grain fin de
H.248 / Megaco dans la gestion des flux de média.

Le modèle H.248 / Megaco simplifie la configuration de la connexion au sein de la

MG et aux entités extérieures à la MG. Il simplifie le mécanisme par lequel le
contrôleur de passerelle de média (MGC) peut spécifier les flux de média associés
ainsi que la direction du flux de média. H.248 / Megaco est donc en mesure de
fournir une prise en charge au niveau des applications supérieure à celle du MGCP.
Par exemple, la configuration d’une conférence multipartite avec H.248 implique
simplement l’ajout de plusieurs terminaisons à un contexte. Dans le cas du MGCP,
toutefois, le contrôleur MGC doit établir plusieurs connexions avec un type
d'extrémité spécial appelé pont de conférence.
SIGTRAN

SIGTRAN(SIGnaling TRANsport) est un groupe de travail de l’Internet Engineering

Task Force (IETF) qui a conçu une nouvelle collection de protocoles pour transporter
les messages de signalisation SS7 sur IP. Cette suite de protocoles normalisés en 2001
se compose d'un nouveau mode de transport et de divers protocoles d'adaptation.
L'utilisation des protocoles de SIGTRAN est la première étape pour fusionner les
réseaux de signalisation SS7 classiques avec les réseaux IP.
Les protocoles SIGTRAN sont une extension de la famille de protocoles SS7. Ils
prennent en charge les mêmes paradigmes d’application et de gestion des appels que
SS7, mais utilise un transport IP ( Internet Protocol ) appelé Stream Control
Transmission Protocol (SCTP) au lieu de TCP ou UDP. SCTP est un protocole TCP
de la nouvelle génération permettant de remédier aux problèmes liés à l’utilisation du
protocole TCP puisque ce dernier est un protocole orienté connexion et n’est pas
capable de fournir la vitesse et la fiabilité requises par la signalisation. En effet, SCTP
est un protocole orienté message permettant de définir des trames de données
structurées alors que TCP n’impose aucune structure des octets transmises.

Fonctionnement du protocole SCTP

Le nom Stream Control Transmission Protocol découle de la fonction multi-
streaming fournie par SCTP. Un stream (flot) est un canal logique unidirectionnel
permettant l’échange de messages entre terminaisons SCTP. Lors de l’établissement
d’une association SCTP, il est nécessaire de spécifier le nombre de streams que
comportera cette association. La fonction multi-streaming permet de partitionner les
données dans différents streams de telle sorte que la perte d’un message dans un des
streams n’ait d’impact sur le transport des données que sur ce stream. Une des
fonctionnalités principales du protocole SCTP est le multi-homing, c’est à dire la
capacité pour un endpoint SCTP de supporter plusieurs adresses IP. Ceci est un
avantage comparé à TCP. Une connexion TCP est définie par une paire d’adresses de
transport (Adresse IP + numéro de port TCP). Chaque endpoint d’une association
SCTP fournit à l’autre extrémité une liste d’adresses IP avec un unique numéro de
port SCTP. L’endpoint est donc l’extrémité logique du protocole de transport SCTP.

Objectifs de SIGTRAN
Les couches d’adaptation définies par SIGTRAN ont toutes des objectifs communs :
- Le transport des protocoles de signalisation des couches supérieures, basé sur un
transport IP fiable.
- La garantie d’une offre de services équivalente à celle proposée par les interfaces
des réseaux RTC.
- La transparence du transport de la signalisation sur un réseau IP : l’utilisateur final
ne se rend pas compte de la nature du réseau de transport.
Architecture SIGTRAN
L’architecture de SIGTRAN se présente comme suit:

Rôle de chaque couche

Le Stream Control Transmission Protocol fournit le protocole de transport pour les

messages de la couche d’adaptation utilisateur SIGTRAN sur un réseau IP.
IUA (ISDN User Adaptation) fournit une couche d'adaptation SCTP pour la
transparente backhaul de Q.921 messages utilisateur et interface de service à travers
un réseau IP. Certains utilisateurs pris en charge sont Q.931 et QSIG .
V5UA(V5.2 User Adaptation) fournit une couche d’adaptation SCTP pour la liaison
transparente des messages utilisateur V5.2 et de l’interface de service sur un réseau
IP.
M2PA(MTP 2 Peer to Peer Adaptation) fournit une couche d'adaptation SCTP
permettant de fournir un lien de signalisation SS7 MTP sur un réseau IP.
M2UA(MTP 2 User Adaptation) fournit une couche d’adaptation SCTP pour la
liaison transparente des messages utilisateur MTP de niveau 2 et de l’interface de
service sur un réseau IP.
M3UA(MTP 3 User Adaptation) fournit une couche d'adaptation SCTP pour le
backhaul ou l'homogénéisation homogène des messages utilisateur MTP de niveau 3
et de l'interface de service sur un réseau IP.
SUA (SCCP User Adaptation) fournit une couche d'adaptation SCTP pour le backhaul
ou le peering homogène des messages utilisateur et de l'interface de service du
composant de contrôle de la connexion de signalisation sur un réseau IP.

Explication de chaque composante de SIGTRAN

IUA
L'architecture définie pour le transport de signalisation SCN sur IP utilise plusieurs
composants, notamment un protocole de transport IP, un protocole de transport
commun de signalisation et un module d'adaptation permettant de prendre en charge
les services attendus par un protocole de signalisation SCN donné de la couche de
protocole sous-jacente. IUA définit un module d'adaptation adapté au transport des
messages RNIS Q.921-User Adaptation Layer (par exemple, Q.931).
La couche IUA implémente les fonctions suivantes

Mappage
La couche IUA maintient un mappage de l'identificateur d'interface sur une interface
physique de la passerelle de signalisation. Une interface physique peut être une ligne
T1, une ligne E1, etc., et peut inclure une plage de temps TDM. De plus, pour une
interface donnée, le SG est en mesure d'identifier le canal de signalisation associé.
Les couches IUA du SG et du MGC conservent le statut des TEI et des SAPI.

Etat des ASP

La couche IUA du SG conserve l’état des ASP qu’elle prend en charge. L'état d'un
ASP change en raison de la réception de messages d'égal à égal ou de la réception
d'indications provenant de l'association SCTP locale.

Gestion de flux
SCTP SCTP permet à un nombre de flux spécifié par l'utilisateur d'être ouvert lors de
l'initialisation. La couche IUA est responsable de la bonne gestion de ces flux. En
raison de la nature unidirectionnelle des flux, une couche IUA n'a pas connaissance
du numéro de flux mappé à l'identificateur d'interface de sa couche IUA homologue.
Au lieu de cela, l'identificateur d'interface se trouve dans l'en-tête du message IUA.

Interfonctionnement continu de la gestion du réseau

La couche IUA du SG transmet l'indication d'indisponibilité de l'utilisateur IUA
(Q.931) à la gestion de couche locale, si l'ASP actuellement actif quitte l'état
ACTIVE. La gestion de couche peut demander à Q.921 de prendre certaines mesures
si elle le juge approprié.

Gestion des encombrements

Si la couche IUA devient encombrée (dépend de la mise en œuvre), il est possible que
la lecture à partir de l'association SCTP cesse de lire pour contrôler le flux à partir de
l'IUA homologue.
M2PA (couche d'adaptation d' égal à égal entre utilisateurs MTP2)

Le protocole M2PA prend en charge le transport des messages de signalisation de

niveau de partie de transfert de message (SS7) de niveau 3 (SS7) via le protocole
Internet (IP) à l'aide des services du contrôle de flux Protocole de transmission
(SCTP). M2PA est également utilisé entre les points de signalisation SS7 à l'aide du
protocole MTP de niveau 3. Les points de signalisation SS7 peuvent également
utiliser des liaisons SS7 standard utilisant le SS7 MTP niveau 2 pour assurer le
transport des messages de signalisation MTP de niveau 3.
La fourniture du protocole de signalisation SCN (Switched Circuit Network) sur un
réseau IP est nécessaire. Cela inclut le transfert de message entre les éléments
suivants:
Une passerelle de signalisation (SG) et un contrôleur de passerelle multimédia
(MGC)
Un SG et un point de signalisation IP (IPSP)
Un IPSP et un IPSP
Cela pourrait permettre la convergence de certains réseaux de signalisation et de
données. Les nœuds de signalisation SCN auraient accès aux bases de données et
autres périphériques du domaine de réseau IP qui n'utilisent pas de liaisons de
signalisation SS7. De même, les applications de téléphonie IP auraient accès aux
services SS7. Le remplacement des liaisons de signalisation traditionnelles par des
"connexions" de réseau IP peut également présenter des avantages en termes de coût
d'exploitation et de performances.

Le mécanisme de livraison décrit ici permet une gestion complète des messages
MTP3 et des capacités de gestion de réseau entre deux nœuds SS7 quelconques,
communiquant sur un réseau IP. Un nœud SS7 équipé d’une connexion réseau IP est
appelé point de signalisation IP (IPSP). Les IPSP fonctionnent comme des noeuds
SS7 traditionnels utilisant le réseau IP au lieu de liens SS7.

Le mécanisme de livraison prend en charge:

• Fonctionnement transparent des homologues du protocole MTP3 via une

connexion réseau IP.
• Limite d'interface MTP niveau 2 / MTP niveau 3.
• Gestion des associations de transport SCTP et du trafic au lieu des liens MTP2.
• Rapport asynchrone des changements d'état à la direction.

M2UA

M2UA est utilisé pour le backhauling de messages de signalisation d'utilisateur SS7

MTP2 sur IP à l'aide du protocole SCTP (Stream Control Transmission Protocol). Ce
protocole est utilisé pour la communication entre une passerelle de signalisation (SG)
et un contrôleur de passerelle multimédia (MGC). Il est supposé que le SG reçoit la
signalisation SS7 sur une interface SS7 standard en utilisant le sous-système de
transfert de message (MTP) SS7 pour assurer le transport. Le SG agit comme un
terminal de liaison de signalisation.

M3UA

M3UA prend en charge le transport de toute signalisation utilisateur SS7 MTP3 (telle
que les messages ISUP et SCCP) sur IP, à l'aide des services du Protocole de
transmission de contrôle de flux (SCTP). Le protocole est utilisé pour la
communication entre une passerelle de signalisation (SG) et un contrôleur MGC
(Media Gateway Controller) ou une base de données résidente IP. Il est supposé que
le SG reçoit la signalisation SS7 sur une interface SS7 standard en utilisant le sous-
système de transfert de message (MTP) SS7 pour assurer le transport.
Le protocole consiste en un en-tête de message commun suivi de paramètres définis
par le type de message.

SCTP

Le protocole de transmission de contrôle de flux (SCTP) est conçu pour transporter

des messages de signalisation PSTN sur des réseaux IP, mais est capable
d'applications plus larges. SCTP est un protocole de transfert de datagramme au
niveau de l'application fonctionnant au dessus d'un service de datagramme non fiable
tel que UDP. Il offre les services suivants à ses utilisateurs:

Confirmation du transfert des données utilisateur sans duplication, sans erreur.

Segmentation au niveau de l'application pour se conformer à la taille de MTU
découverte.
Distribution séquencée des datagrammes utilisateur dans plusieurs flux, avec une
option pour la livraison à l'ordre d'arrivée des datagrammes individuels.
Multiplexage facultatif des datagrammes utilisateur en datagrammes SCTP, sous
réserve des restrictions de taille de MTU.
Fiabilité améliorée grâce à la prise en charge de la multi-hébergement à l'une des
extrémités de l'association, voire aux deux.
La conception du protocole SCTP inclut un comportement approprié permettant
d'éviter la congestion et une résistance aux attaques par inondation et mascarade. Le
datagramme SCTP est composé d'un en-tête commun et de morceaux. Les morceaux
contiennent des informations de contrôle ou des données utilisateur.