La figura describe la arquitectura de protocolo que soporta el servicio en modo bearer. Se deben considerar dos planos separados de operación: el plano de control (plano-C), que tiene que ver con el establecimiento y liberación de conexiones lógicas, y el plano de usuario (plano-U), responsable de la transferencia de los datos de usuario entre los suscriptores. En consecuencia, los protocolos del plano-C se aplican entre un suscriptor y la red, en tanto que los protocolos del plano-U proveen funcionalidad extremo-a-extremo.
Figura 1. Arquitectura del protocolo en la interfase Usuario-Red
Plano de Control
El plano-C para los servicios en modo bearer utiliza un canal lógico separado para la información de control. En la capa de enlace de datos se emplea LAPD (Q.921) para proporcionar un servicio de control de enlace de datos confiable (con control de flujo y control de errores) entre el usuario (TE) y la red (NT) sobre un canal D. Este servicio de enlace de datos es usado para el intercambio de mensajes de señalización de control Q.933.
Plano de Usuario
Para la transferencia de información entre usuarios finales se utiliza LAPF (Q.922), que es una versión mejorada de LAPD. En FR sólo se utilizan las funciones LAPF núcleo (LAPF core) para realizar las tareas de:
- Delimitación, alineación y transparencia de tramas
- Multiplexación y demultiplexación de tramas utilizando el campo Address
- Inspección de la trama para asegurar si la misma consta de un número entero de octetos antes de la inserción de zero bit o luego de la extracción de zero bit
- Detección de errores de transmisión
- Funciones de control de congestión
Las funciones LAPF núcleo en el plano-U conforman una subcapa de la capa de enlace de datos. Proveen el servicio de transferencia de tramas desde un suscriptor a otro, sin control de errores ni control de flujo. Además, el usuario puede optar por la inclusión de funciones adicionales de enlace de datos (equivalentes a funciones entremo-a-extremo de la capa de red) las cuales no son parte del servicio FR.
Empleando las funciones núcleo, la red ofrece un servicio de conmutación de tramas orientado a conexión que opera en la de capa de enlace con las siguientes propiedades:
- Preservación del orden de transferencia de tramas desde un extremo a otro de la red.
- Baja probabilidad de pérdida de tramas.
Transferencia de datos de usuario
La operación de FR para la transferencia de datos de usuario se explica mejor si tenemos en cuenta el formato de la trama (Figura 2). Este formato está el definido por el protocolo LAPF núcleo, y es similar a los de LAPD y LAPB con una omisión obvia: no hay campo de control. Este hecho tiene las siguientes implicancias:
- Hay un solo tipo de trama, el que es utilizado para transportar datos de usuario. No existen tramas de control.
- No es posible emplear señalización en-banda; una conexión lógica sólo puede transportar datos de usuario.
- No es posible realizar control de flujo ni control de errores, debido a que no existen los números de secuencia.
| EA | Address Field Extension bit |
| C/R | Command/Response bit |
| FECN | Forward Explicit Congestion Notification |
| BECN | Backward Explicit Congestion Notification |
| DLCI | Data Link Connection Identifier |
| D/C | DLCI o DLCI-CORE control indicator |
| DE | Discart Eligibility |
Figura 2. Formato de las tramas del protocolo LAPF núcleo.
Los campos Flag y Frame Check Sequence (FCS) funcionan igual que en LAPD y LAPB.
El campo Information transporta datos de la capa superior. Si el usuario selecciona la implementación de funciones de control de enlace de datos extremo-a-extremo adicionales, entonces este campo contendrá una trama de enlace de datos; una selección común será el uso del protocolo LAPF completo (conocido como protocolo de control LAPF), para realizar funciones por encima del protocolo LAPF núcleo. Debemos observar que el protocolo implementado de esta manera se aplica estrictamente entre los suscriptores finales y es transparente para la red FR.
El campo Address posee una longitud default de 2-octetos y se puede extender a 3 y 4-octetos.
El mismo transporta un identificador de conexión de enlace de datos (DLCI - data link control identifier) de 10, 17 o 24 bits, respectivamente. El DLCI cumple la misma función que el número de circuito virtual en X.25: permite que múltiples conexiones lógicas FR sean multiplexadas sobre un único canal. Como en X.25, el identificador de conexión sólo tiene significado local: cada extremo de la conexión lógica asigna su propio DLCI del pool de números local no utilizados, y la red se deberá encargar de asociar uno con otro. La alternativa de utilizar el mismo DLCI en ambos extremos podría requerir de algún tipo de administración global de los valores de DLCI.
Los bits EA (address field extension) determinan la longitud del campo Address y, en consecuencia, del DLCI.
El bit C/R es específico de la aplicación (el protocolo estándar FR no lo utiliza).
El resto de los bits de la cabecera tienen que ver con el control de congestión, que se analiza a continuación.