Tal como indica su nombre, el bloque o módulo SCLC es el encargado de conseguir establecer conexiones entre los niveles SCCP de dos puntos de
se-ñalización distantes. Al finalizar el motivo que ha llevado al establecimiento de la conexión, este bloque también es el encargado de terminarla. Según el estándar, las conexiones SCCP pueden ser de dos tipos en función de la du-ración: conexiones temporales o conexiones permanentes. Habitualmente las conexiones permanentes son establecidas por el operador y tienen el objetivo de transportar datos de gestión. En este subapartado nos centraremos en las conexiones temporales, que son aquellas que una pareja de SCCP establecen para transferir datos.
En cualquiera de los dos casos, el SCCP de los dos puntos de señalización involucrados establecen y finalizan una conexión virtual antes y después de intercambiarse datos, respectivamente.
El proceso de conexión comienza cuando un usuario SCCP (es decir, un sub-sistema como la ISUP o la TCAP) envían hacia el SCCP una petición para establecer una conexión. Hay tres parámetros fundamentales que la SCCP uti-liza para identificar una conexión: el identificador de conexión (Connection
Identifier, CID), la referencia local de origen (Source Local Reference, SLR) y la
re-ferencia local de destino (Destination Local Reference, DLR). El objetivo de estos tres parámetros es conseguir identificar la conexión en modo local. Así, como veremos a continuación, el CID para una misma conexión puede ser diferente para cada uno de los SCCP que intervienen, aunque sea la misma conexión.
Imaginemos la conexión SCCP de la figura 28. Inicialmente, el usuario SCCP debe designar la conexión (aunque no establecida) con un CID único local-mente. La SCCP dispone localmente de un conjunto de identificadores, tanto CID como SLR, que gestiona de manera autónoma. Así, en el momento de es-tablecer una conexión, el SCCP elige un CID del conjunto local de CID y SLR de los que dispone para designar la conexión y el usuario SLR que ha inicia-do la conexión. A partir de este momento, ni el SLR ni el CID seleccionainicia-dos podrán ser utilizados para futuras conexiones hasta que la actual conexión finalice. Se pueden establecer conexiones simultáneas, pero en ningún caso pueden utilizar el mismo CID o SLR. Una vez elegidos el CID y el SLR (en la figura 28 CID = a y SLR = x), se envía una petición de conexión al SCCP destino (en inglés connection request, CR) con el valor de la SLR. Es importante darse cuenta de que el DLR será decidido, al recibir la petición, por el SCCP de destino.
Al recibir la petición, el SCCP de destino selecciona localmente un CID para la conexión (en el caso de la figura, CID = b) y un SLR para el usuario SCCP al que va dirigida la petición. En este caso le asigna un SLR igual a y. Hecho esto, y en caso de encontrarse en condiciones de poder aceptar la conexión, el SCCP de destino envía la confirmación de conexión mediante un paquete CC (la sigla de la denominación inglesa Connection Confirm). En caso de que la conexión no pueda ser aceptada por la falta de recursos en el SCCP de destino, éste enviará un mensaje de rechazo de la conexión (Connection Refused, CREF).
Figura 28. Establecimiento y finalización de una conexión SCCP Mensaje RLC con DLR = x y SLR = y SCCP1 SCCP2 CID = a SLR = x CID = b SLR = y Mensaje CR con SLR = x Mensaje CC con DLR = x y SLR = y Mensaje DT1 con DLR = y Mensaje DT1 con DLR = y Mensaje DT1 con DLR = y Mensaje DT1 con DLR = x Mensaje RLSD con DLR = y y SLR = x
Una vez establecida la conexión, los datos se pueden transferir en un único sentido o en ambos, como muestra la figura. En el caso de la transferencia de información que SCCP hace orientada a conexión, los mensajes de infor-mación que se emplean para la clase 2 son llamados Data Form 1 (DT1). En cuanto a la clase 3, los mensajes son llamados Data Form 2 (DT2). Estos men-sajes de datos presentan tres parámetros obligatorios de longitud fija: el tipo de mensaje (1 byte), el DLR (3 bytes) y el parámetro de fragmentación. Tal como hemos señalado con anterioridad, el SCCP tiene la opción de fragmen-tar las primitivas provenientes de los usuarios SCCP si tienen una longitud excesivamente larga para ser transportadas en un único DT1. Por tanto, este parámetro permite la reconstrucción de las primitivas fragmentadas una vez recibidas en el destino. En cuanto a los datos, formalmente se considera un parámetro obligatorio de longitud variable. La longitud de los datos tiene un mínimo de 2 bytes y un máximo de 256 bytes.
Una vez finalizada la transferencia de información, se envía un mensaje de liberación de la conexión (en inglés Released, RLSD) y se responde con una confirmación de finalización (Release Complete, RLC).
El proceso que sigue el SCCP para establecer una conexión para el servicio de la clase 3 es exactamente igual, pero la información se transmite en mensajes
Data Form 2 (DT2). A pesar de las semejanzas, la clase 3 se caracteriza por
implementar un control de flujo de la conexión y, por tanto, hay que tener en cuenta algunos procesos adicionales:
• Establecimiento de una ventana de control de flujo.
• Confirmación de recepción de los mensajes de datos.
El establecimiento del tamaño de la ventana de conexión se lleva a cabo
durante el proceso de creación de la conexión, mediante los mensajes CR y CC. En particular, la SCCP de origen propone un valor para el tamaño de la ventana en el campo de créditos del mensaje CR, y el SCCP confirma o rectifica el valor mediante el mismo parámetro del mensaje CC. Este valor es, como máximo, igual a 127. Es decir, no puede haber más de 127 mensajes enviados por el SCCP de origen y no confirmados por el SCCP de destino.
Los mensajes de datos DT2 son muy similares a los DT1 pero incorporan un campo de secuencia. Este campo toma valores entre 0 y 127, y cada vez que se transmite un DT2 incrementa en una unidad (módulo 128). La confirmación de recepción se realiza mediante los mensajes de data acknowledgement, que incluyen el campo de secuencia de recepción para indicar en el origen cuál es el último DT2 recibido correctamente. De esta manera se asegura la correcta recepción de la información. La confirmación de la recepción se puede ha-cer de varias maneras, tales como confirmando la recepción de cada uno de los mensajes o bien confirmando el último mensaje recibido antes de que se alcance el límite de la ventana de recepción.