Práctica 2 - SDL (Protocolos T.125 y V76)

PRCTICA 2
Prctica de SDL con protocolos T.125 y V.76
1. Comparacin de la norma ITU con el cdigo SDL: A partir del estudio de la norma ITU-T
T.125 y el cdigo SDL proporcionado, se debe responder a las siguientes cuestiones:
a) En qu parte del cdigo SDL debera emplear la descripcin de mensajes ASN.1 que
incluye la norma? Aunque no estn implementados los mtodos de codificacin y
decodificacin, se deben localizar los puntos del cdigo donde deben invocarse.
La descripcin de mensajes ASN.1 deben emplearse en la parte del cdigo SDL que se
corresponde con el EndPoint, ya que en dicho bloque se encuentra el BER (Basic Encoding
Rules) o reglas de codificacin bsicas con las que se realiza la codificacin/decodificacin
usando ASN.1.
Estos mtodos de codificacin/decodificacin deben situarse tras el EndPoint, ya que es el
punto de entrada/salida de los datos MAPPDU y deben adaptarse antes/despus de
entrar/salir de la capa de transporte a travs del TSAP (Punto de acceso al servicio de
transporte).
A continuacin pueden verse los lugares donde aparece el BER dentro del bloque EndPoint:
b) En qu partes del cdigo SDL se gestiona que un rbol de conexiones para un dominio no
sobrepase una altura concreta?
En primer lugar puede verse que en el procedimiento Initialize_resources, situado en el

bloque Control, se inicializa el tamao de un rbol de conexiones para un dominio. Como se
puede observar en la siguiente imagen:
La altura lmite de un rbol de conexiones viene indicada por el PlumbDomainIndication, que
segn la notacin ASN.1 viene especificado en la norma de la siguiente forma:
En el cdigo SDL la definicin anterior se corresponde con lo que aparece en la siguiente

imagen:
El lugar en el que gestiona la altura mxima del rbol es en el procedimiento Apply_PDU,
situado en el proceso Domain. En l se comprueba dicho valor y dependiendo de ste puede
actuar de dos formas:
- Si altura > 0 se decrementa en 1 dicha altura.
- Si altura = 0 entonces se enva a Control una seal diciendo que se ha llegado al lmite
de la altura del rbol.
Esto se puede observar en la siguiente captura:
c) En qu parte del cdigo se examinan los mensajes entrantes de otros nodos MCS para
identificar su tipo?
Como ya se ha comentado anteriormente, el EndPoint es el bloque de entrada y salida que se

comunica con las capas inferiores, por tanto, es en l donde se deben examinar los mensajes
MCSPDU y decidir el camino posterior a seguir segn su tipo. Si observamos la definicin de
tipos de datos del apartado anterior, se puede apreciar que PDUKind es una especie de
enumerado que recoge todos los posibles tipos de seales entrantes al sistema. Y e n la
siguiente imagen puede verse que, dependiendo del tipo del mensaje, ste seguir un camino
u otro.
d) Indicar qu transiciones se ejecutan desde que se recibe una seal MCS.Connect.Request

hasta que se genera una seal Connect.Response. (Indicarlo con la notacin Proceso, Estado
Inicial-Estado final, Pgina de Cdigo)
Segn la norma, se tienen en cuenta las siguientes primitivas:
El primer paso sera el envo de la peticin de conexin (MCS.Connect.Provider.request) de un

usuario al otro a travs de un proveedor.
Dentro del citado procedimiento, se enva una seal de Connect Initial entre ambos
proveedores a travs de la red de transporte.
El usuario llamado, recibe la seal de conexin inicial (Connect Initial).

Dentro de este procedimiento, se le enva al usuario destino una indicacin de conexin del
otro usuario (MCS Connect Provider Indication) a travs de su proveedor.
El usuario destino enva una respuesta para aceptar la conexin del otro usuario (MCS Connect
Provider response)
Dentro del procedimiento comentado anteriormente, se encuentra el procedimiento
correspondiente al Connect Response, mediante el cual se enva una seal de respuesta de
conexin entre ambos proveedores en direccin al usuario inicial.
El usuario inicial, recibe la respuesta de conexin por parte del proveedor del otro usuario.
Por ltimo, el usuario inicial recibe la confirmacin de conexin (MCS Connect Provider
Confirm).
e) Explicar qu hace el procedimiento Drop_portal.

Este procedimiento se encuentra situado en el proceso Control.
Se utiliza para salir y cerrar una sesin. En la siguiente captura se observa el procedimiento
Quit Portal en el que aparece la seal MCS Disconnect Provider Inidication mediante la cual el
usuario final indica que quiere cerrar la sesin.
f) Simulacin de T.125: Emplear el simulador de Tau para generar un MSC que muestre el
mayor nmero de pasos posible con el script proporcionado en la pgina de la asignatura.
Explicar lo que muestra el MSC.
Los pasos a seguir para realizar la simulacin de T.125 son los que se muestran a continuacin:
1. Tras abrir el Telelogic y abrir T.125.msc hacemos los siguientes pasos:

MCS Generate Make Microsoft Simulation Full Make
Obtenindose lo que se muestra en la siguiente captura:
2. Posteriormente, realizamos los siguientes pasos:

Tools SDL Simulator
y obtenemos un archivo generado por el simulador (MCS_smc.exe), dndole

seguidamente a:
Go y MCS
3. Posteriormente se inicia la simulacin ejecutando el archivo arranca.com. Para ello

seguimos los siguientes pasos:
Execute Command Script arranca.com
y obtenemos lo siguiente:
4. En el simulador, le damos varias veces a la opcin de Transition hasta que nos diga que
ya no hay ms transiciones para hacer (terminar cuando salga el connecting).
5. Seguimos enviando seales para continuar la simulacin. Para ello nos vamos a Send
To y enviamos las siguientes seales:
- T.Connect.Confirm con valor = 0 al End Point. Para ello le damos a Transition varia
veces y terminar cuando sale connbusy.
- T.Data.indication con valor = 1 al End Point. Le damos una vez a Transition y se elige
Connect-Response.
6. Por ltimo obtenemos la imagen de la traza total que se ha generado, la cual aparece
en la siguientes capturas:
Al terminar la simulacin obtenemos el siguiente mensaje en la consola:

En las siguientes imgenes queda representada la traza obtenida una vez realizada la
simulacin:
1. Simplificacin de V76: El cdigo SDL para el protocolo V.76 es una versin simplificada de la
norma. Sin embargo, para realizar las primeras simulaciones, convine simplificarlo an ms.
Como primer ejercicio se propone modificar el modelo SDL en los siguientes aspectos:
- Eliminar la fragmentacin y ensamblado
- Eliminar la posibilidad de errores en el medio
Vamos a seguir los siguientes pasos para realizar lo que nos pide el enunciado del ejercicio:
1. En primer lugar abrimos el V76.
2. Posteriormente entramos en Stack Test. Aqu, quitamos los bloques framing y el medio
(layer2stub), y dejamos nicamente los bloques DLC V76.
Estos bloques los enlazamos entre s, y dicho enlace los establecemos de tipo
bidireccional. Tambin ponemos las seales [V76frame].
3. En las siguientes capturas se muestra el resultado de los pasos realizados
anteriormente:
En esta captura se puede observar el bloque stackTest sin modificar, tal y como lo
tena el V76.
Aqu se muestra la captura con los cambios realizados y los bloques que se han
eliminado.
En la siguiente imagen queda representado como quedara el sistema del V76 una vez
que se han eliminado los bloques anteriores:
2. Simulacin de V76: Emplear el simulador de Tau para generar un MSC que muestre las fases
de establecimiento de parmetros, establecimiento de conexin, intercambio de una trama de
datos y liberacin de conexin. Para ello, se debe estimular el sistema resultante del ejercicio 1
mediante las seales adecuadas desde el entorno. Los procesos en el MSC deben ordenarse
para mostrar la salida de forma legible.
Los pasos a seguir son los que se muestran a continuacin:

Generate->Make->Full Make
Tools->SDL->Simulator UI
Open->File->StackTest_smc.exe
MSC
GO
Introducir seales con SEND TO mirando los diagramas:
1) Establecimiento de parmetros:
L_SETparmReq -> DLCA dispatch
L_SETparamResp -> DLCB dispatch
2) Establecimiento de conexin:
L_EstabReq -> DLCA dispatch
L_EstabResp -> DLCB dispatch
3) Envio de datos:
L_DataReq Opcin 2 (IData) -> DLCA dispatch
4) Liberar conexin:
L_RealeaseReq -> DLCA dispatch
A travs de la siguiente captura observamos cmo se realiza el envo de las diversas seales.
En este ejemplo se puede ver como la seal a enviar es L_SetparmReq, la cual se enva al
dispatch del usuario A:
Y en el simulador se obtiene lo siguiente tras enviar de la forma anteriormente comentada la

seal L_SetparmResp:
Tras realizar la simulacin, podemos observar en las siguientes capturas la traza obtenida. En
esta primera captura se puede ver como se realiza el establecimiento de parmetros,
comenzando este con el envo de la seal L_SetparmReq, y finalizando con el envo de la seal
L_SetparmConf:
En esta captura se puede ver como se realiza el establecimiento de la conexin con el envo de
la seal L_EstabReq.
En la captura que se muestra a continuacin, se puede observar cmo se termina el proceso
del establecimiento de la conexin con el envo de la seal L_EstabConf y se inicia el envo de
los datos a partir de la seal L_DataReq:
En la presente captura, se observa cmo se termina el proceso de envo de datos con el envo
de la seal L_DataInd y se inicia la liberacin de la conexin con el envo de la seal
L_ReleaseReq:
En esta ltima captura observamos cmo termina el proceso de liberacin de la conexin con
el envo de la seal L_ReleaseInd, tal y como se muestra a continuacin:
3. Usuarios de V76: Extender la especificacin SDL de V76 para incluir los usuarios A y B que
realizan de forma automtica el intercambio de seales generado manualmente en el ejercicio
2.1. Para probar su funcionamiento, se debe generar un nuevo MSC de forma automtica.
Tras crear los usuarios A y B, el sistema del V76 queda de la forma que se muestra en la
siguiente captura:
Los usuarios creados hay que introducirlos en el paquete V76. Al pinchar sobre el StackTest
obtenemos lo que se muestra a continuacin:
Al pinchar sobre el bloque del usuario A o del usuario B se tiene lo que se muestra en la
siguiente captura:
Al pinchar de nuevo sobre el bloque A y el bloque B mostrados en la captura anterior,
obtenemos los bloques que estn representados en las siguientes capturas:
En las capturas siguientes, me muestra la traza obtenida tras realizar la simulacin:
Una vez analizada la traza anterior, cabe destacar que la nica diferencia de este apartado con
respecto al apartado 2 es que al crear ahora los usuarios no es necesario me terle las seales
de forma manual, sino que estos mismos las generan.
4. Anlisis del modelo completo: Repetir los ejercicios 2 y 3 incluyendo las funciones de
fragmentacin y ensamblado.
El sistema completo de V76 con los usuarios y las funciones de fragmentacin y ensamblado
eliminadas en el apartado 1, queda como se muestra en la siguiente captura:
Las trazas obtenidas tras la simulacin se muestran en las siguientes capturas:
5.Validacin del modelo completo:
Se procede a validar el ejercicio 4. Para ello, en la siguiente captura se muestran los

parmetros introducidos para proceder a realizar dicha validacin:
Una vez realizada la validacin obtenemos las siguientes capturas. En la primera aparece el
rbol de reports y en la segunda captura el rbol de estados:
Una vez terminada la validacin, obtenemos los siguientes datos en la consola:

Práctica 2 - SDL (Protocolos T.125 y V76)

Cargado por

Copyright:

Formatos disponibles

Práctica 2 - SDL (Protocolos T.125 y V76)

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Práctica 2 - SDL (Protocolos T.125 y V76)

Cargado por

Copyright:

Formatos disponibles

PRCTICA 2

Prctica de SDL con protocolos T.125 y V.76

En primer lugar puede verse que en el procedimiento Initialize_resources, situado en el

En el cdigo SDL la definicin anterior se corresponde con lo que aparece en la siguiente

Como ya se ha comentado anteriormente, el EndPoint es el bloque de entrada y salida que se

d) Indicar qu transiciones se ejecutan desde que se recibe una seal MCS.Connect.Request

El primer paso sera el envo de la peticin de conexin (MCS.Connect.Provider.request) de un

El usuario llamado, recibe la seal de conexin inicial (Connect Initial).

e) Explicar qu hace el procedimiento Drop_portal.

1. Tras abrir el Telelogic y abrir T.125.msc hacemos los siguientes pasos:

Obtenindose lo que se muestra en la siguiente captura:

2. Posteriormente, realizamos los siguientes pasos:

y obtenemos un archivo generado por el simulador (MCS_smc.exe), dndole

3. Posteriormente se inicia la simulacin ejecutando el archivo arranca.com. Para ello

Al terminar la simulacin obtenemos el siguiente mensaje en la consola:

Los pasos a seguir son los que se muestran a continuacin:

Y en el simulador se obtiene lo siguiente tras enviar de la forma anteriormente comentada la

Se procede a validar el ejercicio 4. Para ello, en la siguiente captura se muestran los

Una vez terminada la validacin, obtenemos los siguientes datos en la consola:

También podría gustarte