Vous êtes sur la page 1sur 13

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 +

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

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:

SIGTRAN L’architecture de SIGTRAN se présente comme suit: Rôle de chaque couche Le Stream Control Transmission

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.