ns-3-model-library: en línea en la nube

PROGRAMA:

NOMBRE

ns-3-model-library - biblioteca de modelos ns-3

Este es el ns-3 Modelo Biblioteca documentación. Documentación principal para el proyecto ns-3
está disponible en cinco formas:

· ns-3 Doxygen: Documentación de las API públicas del simulador

· Tutorial, manual y biblioteca de modelos (esta documento) para más reciente , y
Desarrollo tree

· ns-3 wiki

Este documento está escrito en reStructuredText para Esfinge y se mantiene en el
doc / modelos directorio del código fuente de ns-3.

ORGANIZACIÓN

Este manual compila documentación para ns-3 modelos y software de apoyo que permiten
usuarios para construir simulaciones de red. Es importante distinguir entre módulos
y modelos:

· ns-3 el software está organizado en diferentes módulos que están construidos cada uno como un
biblioteca de software. Los programas ns-3 individuales pueden vincular los módulos (bibliotecas) que necesitan
para realizar su simulación.

· ns-3 modelos son representaciones abstractas de objetos, protocolos, dispositivos, etc. del mundo real

An ns-3 módulo puede constar de más de un modelo (por ejemplo, el Internet módulo
contiene modelos para TCP y UDP). En general, los modelos ns-3 no abarcan múltiples
módulos de software, sin embargo.

Este manual proporciona documentación sobre los modelos de ns-3. Complementa a otros dos
fuentes de documentación sobre modelos:

· Las API del modelo están documentadas, desde una perspectiva de programación, utilizando Doxygen. Doxígeno
para los modelos ns-3 está disponible on los Antecedentes web servidor.

· los ns-3 core está documentado en el manual del desarrollador. ns-3 modelos hacen uso de la
instalaciones del núcleo, como atributos, valores predeterminados, números aleatorios, prueba
frameworks, etc. Consultar el principal web site para encontrar copias del manual.

Finalmente, documentación adicional sobre varios aspectos de ns-3 puede existir en el Antecedentes
wiki.

Puede encontrar un esquema de muestra de cómo escribir la documentación de la biblioteca modelo ejecutando el
crear-modulo.py programa y mirando la plantilla creada en el archivo
nuevo-módulo / doc / nuevo-módulo.rst.

$ cd origen
$ ./create-module.py nuevo módulo

El resto de este documento está organizado alfabéticamente por nombre de módulo.

Si usted es nuevo en ns-3, es posible que primero desee leer a continuación sobre el módulo de red, que
contiene algunos modelos fundamentales para el simulador. El modelo de paquete, modelos para
diferentes formatos de dirección y clases base abstractas para objetos como nodos, red
Los dispositivos, canales, enchufes y aplicaciones se tratan allí.

ANIMACIÓN

La animación es una herramienta importante para la simulación de redes. Tiempo ns-3 no contiene un
herramienta de animación gráfica predeterminada, actualmente tenemos dos formas de proporcionar animación, a saber
utilizando el método PyViz o el método NetAnim. El método PyViz se describe en
http://www.nsnam.org/wiki/PyViz.

Describiremos brevemente el método NetAnim aquí.

NetAnim
NetAnim es un software ejecutable independiente basado en Qt4 que utiliza un archivo de seguimiento generado
Durante un ns-3 simulación para mostrar la topología y animar el flujo de paquetes entre
nodos
[imagen] Un ejemplo de animación de paquetes en enlaces cableados.

Además, NetAnim también proporciona funciones útiles, como tablas para mostrar metadatos.
de paquetes como la imagen de abajo
[imagen] Un ejemplo de tablas para paquetes de metadatos con filtros de protocolo.

Una forma de visualizar la trayectoria de un nodo móvil
[imagen] Un ejemplo de la trayectoria de un nodo móvil.

Una forma de mostrar las tablas de enrutamiento de múltiples nodos en varios puntos en el tiempo
[imagen]

Una forma de mostrar contadores asociados con varios nodos como un gráfico o una tabla
[imagen]
[imagen]

Una forma de ver la línea de tiempo de los eventos de transmisión y recepción de paquetes
[imagen]

Metodología
La clase ns3 :: AnimationInterface es responsable de la creación del archivo XML de seguimiento.
AnimationInterface utiliza la infraestructura de seguimiento para rastrear los flujos de paquetes entre los nodos.
AnimationInterface se registra como un gancho de seguimiento para eventos tx y rx antes de la
comienza la simulación. Cuando se programa la transmisión o recepción de un paquete, el
Se llaman los correspondientes enlaces de rastreo tx y rx en AnimationInterface. Cuando el rx engancha
se llaman, AnimationInterface conocerá los dos puntos finales entre los cuales un paquete
ha fluido, y agrega esta información al archivo de seguimiento, en formato XML junto con el
correspondientes marcas de tiempo tx y rx. El formato XML se discutirá en una sección posterior.
Es importante tener en cuenta que AnimationInterface registra un paquete solo si el rastreo rx
se llaman ganchos. Cada evento tx debe coincidir con un evento rx.

Descarga de NetAnim
Si NetAnim aún no está disponible en el ns-3 paquete que descargó, puede hacer el
siguientes:

Asegúrese de haber instalado Mercurial. La última versión de NetAnim puede ser
descargado usando mercurial con el siguiente comando:

$ hg clon http://code.nsnam.org/netanim

Contruyendo NetAnim
Requisitos previos
Se requiere Qt4 (4.7 y superior) para construir NetAnim. Esto se puede obtener usando lo siguiente
formas:

Para distribuciones de Debian / Ubuntu Linux:

$ apt-get install qt4-dev-herramientas

Para la distribución basada en Red Hat / Fedora:

$ yum instalar qt4
$ yum instalar qt4-devel

Para Mac / OSX, consulte http://qt.nokia.com/downloads/

Build pasos
Para construir NetAnim use los siguientes comandos:

$ cd netanim
$ hacer limpio
$ qmake NetAnim.pro (para usuarios de MAC: qmake -spec macx-g ++ NetAnim.pro)
$ make

Nota: qmake podría ser "qmake-qt4" en algunos sistemas

Esto debería crear un ejecutable llamado "NetAnim" en el mismo directorio:

$ ls -l NetAnim
-rwxr-xr-x 1 juan juan 390395 2012-05-22 08:32 NetAnim

Uso
Usar NetAnim es un proceso de dos pasos

Paso 1: Genere el archivo de seguimiento XML de animación durante la simulación utilizando
"ns3 :: AnimationInterface" en el ns-3 base de código.

Paso 2: Cargue el archivo de seguimiento XML generado en el Paso 1 con el animador basado en Qt4 sin conexión
llamado NetAnim.

Paso 1: Generar XML animación rastrear presentar
La clase "AnimationInterface" en "src / netanim" utiliza subyacentes ns-3 rastrear fuentes a
construir un archivo ASCII con marca de tiempo en formato XML.

Los ejemplos se encuentran en src / netanim / examples Ejemplo:

$ ./waf -d configuración de depuración --enable-examples
$ ./waf --run "animación con mancuernas"

Lo anterior creará un archivo XML dumbbell-animation.xml

Obligatorio
1. Asegúrese de que el wscript de su programa incluya el módulo "netanim". Un ejemplo de tal
wscript está en src / netanim / examples / wscript.

2. Incluya el encabezado [#include "ns3 / netanim-module.h"] en su programa de prueba

3. Agregue la declaración

AnimationInterface anim ("animation.xml"); // donde "animation.xml" es cualquier nombre de archivo arbitrario

[para versiones anteriores a ns-3.13 también debe usar la línea "anim.SetXMLOutput () para configurar el
Modo XML y también use anim.StartAnimation ();]

Complementos
Los siguientes son pasos opcionales pero útiles:

// Paso 1
anim.SetMobilityPollInterval (Segundos (1));

AnimationInterface registra la posición de todos los nodos cada 250 ms por defecto. los
declaración anterior establece el intervalo periódico en el que AnimationInterface registra el
posición de todos los nodos. Si se espera que los nodos se muevan muy poco, es útil configurar
un intervalo de sondeo de alta movilidad para evitar archivos XML grandes.

// Paso 2
anim.SetConstantPosition (Ptr <Nodo> n, doble x, doble y);

AnimationInterface requiere que se establezca la posición de todos los nodos. En ns-3 esto es hecho por
establecer un MobilityModel asociado. "SetConstantPosition" es una forma rápida de configurar xy
coordenadas de un nodo que está estacionario.

// Paso 3
anim.SetStartTime (Segundos(150)); y anim.SetStopTime (Segundos(150));

AnimationInterface puede generar archivos XML de gran tamaño. Las declaraciones anteriores restringen la ventana
entre los cuales AnimationInterface realiza el seguimiento. Restringir la ventana sirve solo para enfocar
en partes relevantes de la simulación y creando archivos XML manejablemente pequeños

// Paso 4
AnimationInterface anim ("animation.xml", 50000);

El uso del constructor anterior garantiza que cada archivo de seguimiento XML de animación tenga solo 50000
paquetes. Por ejemplo, si AnimationInterface captura 150000 paquetes, usando el anterior
constructor divide la captura en 3 archivos

· Animation.xml - que contiene el rango de paquetes 1-50000

· Animation.xml-1 - que contiene el rango de paquetes 50001-100000

· Animation.xml-2 - que contiene el rango de paquetes 100001-150000

// Paso 5
anim.EnablePacketMetadata (verdadero);

Con la declaración anterior, AnimationInterface registra los metadatos de cada paquete en el
archivo de seguimiento xml. NetAnim puede utilizar metadatos para proporcionar mejores estadísticas y filtros,
además de proporcionar información breve sobre el paquete, como el número de secuencia de TCP
o dirección IP de origen y destino durante la animación del paquete.

PRECAUCIÓN: Habilitar esta función resultará en archivos de rastreo XML más grandes. Por favor no
habilite esta función cuando utilice enlaces Wimax.

// Paso 6
anim.UpdateNodeDescription (5, "Punto de acceso");

Con la declaración anterior, AnimationInterface asigna el texto "Punto de acceso" al nodo 5.

// Paso 7
anim.UpdateNodeSize (6, 1.5, 1.5);

Con la declaración anterior, AnimationInterface establece el tamaño del nodo para escalar en 1.5. NetAnim
escala automáticamente la vista de gráficos para que se ajuste a los límites de la topología. Esto significa
que NetAnim, puede escalar anormalmente el tamaño de un nodo demasiado alto o demasiado bajo. Utilizando
AnimationInterface :: UpdateNodeSize le permite sobrescribir la escala predeterminada en NetAnim
y use su propia escala personalizada.

// Paso 8
anim.UpdateNodeCounter (89, 7, 3.4);

Con la declaración anterior, AnimationInterface establece el contador con Id == 89, asociado
con el Nodo 7 con el valor 3.4. El contador con Id 89 se obtiene utilizando
AnimationInterface :: AddNodeCounter. Un ejemplo de uso para esto está en
src / netanim / examples / resources_demo.cc.

Paso 2: carga los XML in NetAnim
1. Suponiendo que se creó NetAnim, use el comando "./NetAnim" para iniciar NetAnim. Por favor
revise la sección "Creación de NetAnim" si NetAnim no está disponible.

2. Cuando se abra NetAnim, haga clic en el botón Abrir archivo en la esquina superior izquierda, seleccione
el archivo XML generado durante el Paso 1.

3. Presione el botón de reproducción verde para comenzar la animación.

Aquí hay un video que ilustra esto. http://www.youtube.com/watch? v = tz_hUuNwFDs

Wiki
Para obtener instrucciones detalladas sobre la instalación de "NetAnim", las preguntas frecuentes y la carga del archivo de seguimiento XML
(mencionado anteriormente) usando NetAnim, consulte: http://www.nsnam.org/wiki/NetAnim

ANTENA MÓDULO

Design documentación
Descripción General
El módulo de antena proporciona:

1. una nueva clase base (AntennaModel) que proporciona una interfaz para el modelado del
patrón de radiación de una antena;

2. un conjunto de clases derivadas de esta clase base, cada una de las cuales modela el patrón de radiación
de diferentes tipos de antenas.

AntenaModelo
El modelo AntennaModel utiliza el sistema de coordenadas adoptado en [Balanis] y representado en la Figura
Coordenadas te of los AntenaModelo. Este sistema se obtiene traduciendo el cartesiano
sistema de coordenadas utilizado por ns-3 MobilityModel en el nuevo origen o que es el
ubicación de la antena, y luego transformar las coordenadas de cada punto genérico p de
el espacio de las coordenadas cartesianas (x, y, z) a las coordenadas esféricas (r, heta, hi).
El modelo de antena ignora la componente radial r, y solo considera las componentes angulares
(heta, hola).
Entonces, un patrón de radiación de antena se expresa como una función matemática g (heta, hi)
grightarrow thcal {R} que devuelve la ganancia (en dB) para cada posible dirección de
transmisión / recepción. Todos los ángulos se expresan en radianes.
[imagen] Sistema de coordenadas del AntennaModel.UNINDENT

Previsto modelos
En esta sección describimos los modelos de patrones de radiación de antena que se incluyen en
el módulo de antena.

IsotrópicoAntenaModelo
Este modelo de diagrama de radiación de antena proporciona una ganancia unitaria (0 dB) para todas las direcciones.

CosenoAntenaModelo
Este es el modelo de coseno descrito en [Chunjian]: la ganancia de la antena se determina como:

donde hola_ {0}
es la orientación azimutal de la antena (es decir, su dirección de máxima ganancia) y la
exponencial

determina el ancho de haz de 3dB deseado hi_ {3dB}.
Tenga en cuenta que este patrón de radiación es independiente del ángulo de inclinación heta.

Una gran diferencia entre el modelo de [Chunjian] y el implementado en la clase
CosineAntennaModel es que solo el factor de elemento (es decir, lo que se describe en
fórmulas). De hecho, [Chunjian] también consideró una matriz de antenas adicional
factor. El motivo por el que se excluye este último es que esperamos que el usuario medio
desearía especificar exactamente un ancho de haz dado, sin agregar un factor de matriz en un
última etapa que en la práctica alteraría el ancho de haz efectivo de la resultante
patrón de radiación.

ParabólicoAntenaModelo
Este modelo se basa en la aproximación parabólica del patrón de radiación del lóbulo principal. Eso
se utiliza a menudo en el contexto del sistema celular para modelar el patrón de radiación de una célula
sector, ver por ejemplo [R4-092042a] y [Calcev]. Se determina la ganancia de antena en dB
como:

donde hola_ {0}
es la orientación azimutal de la antena (es decir, su dirección de máxima ganancia),
hola_ {3dB}
es su ancho de haz de 3 dB, y A_ {max} es la atenuación máxima en dB de la antena. Nota
que este patrón de radiación es independiente del ángulo de inclinación heta.

[Balanís]
CA Balanis, "Teoría de la antena: análisis y diseño", Wiley, 2ª ed.

[Chunjian]
Li Chunjian, "Patrones de antenas eficientes para sistemas WCDMA de tres sectores", Maestría en
Tesis de ciencias, Universidad Tecnológica de Chalmers, Göteborg, Suecia, 2003

[Calcev]
George Calcev y Matt Dillon, "Control de inclinación de antena en redes CDMA", en Proc. de
la 2da Conferencia Anual Internacional de Internet Inalámbrico (WICON), 2006

[R4-092042a]
3GPP TSG RAN WG4 (Radio) Reunión # 51, R4-092042, Supuestos de simulación y
parámetros para los requisitos de RF FDD HeNB.

User Documentación
La antena modulada se puede utilizar con todas las tecnologías inalámbricas y la capa física.
modelos que lo soportan. Actualmente, esto incluye los modelos de capa física basados ​​en el
SpectrumPhy. Consulte la documentación de cada uno de estos modelos para obtener más detalles.

Pruebas Documentación
En esta sección describimos las suites de prueba incluidas con el módulo de antena que verifican
su correcta funcionalidad.

Angles
La suite de pruebas unitarias ángulos verifica que la clase Angles esté construida correctamente por
conversión correcta de coordenadas cartesianas 3D de acuerdo con los métodos disponibles
(construcción a partir de un solo vector y de un par de vectores). Para cada método, varios
Se proporcionan casos de prueba que comparan los valores (hi,
heta) determinado por el constructor a valores de referencia conocidos. La prueba pasa si para cada
caso de que los valores sean iguales a la referencia hasta una tolerancia de 10 ^ {- 10} que cuentas
para errores numéricos.

GradosToRadianos
La suite de pruebas unitarias grados-radianes verifica que los métodos GradosToRadianos y
Radianes a grados funcionan correctamente comparando con valores de referencia conocidos en una serie de
Casos de prueba. Cada caso de prueba pasa si la comparación es igual hasta una tolerancia de 10 ^ {- 10}
que explica los errores numéricos.

IsotrópicoAntenaModelo
La suite de pruebas unitarias modelo-de-antena-isotrópica comprueba que el IsotrópicoAntenaModelo clase
funciona correctamente, es decir, devuelve siempre una ganancia de 0dB independientemente de la dirección.

CosenoAntenaModelo
La suite de pruebas unitarias modelo-antena-coseno comprueba que el CosenoAntenaModelo trabajos de clase
adecuadamente. Se proporcionan varios casos de prueba que verifican el valor de ganancia de antena calculado
en diferentes direcciones y para diferentes valores de la orientación, la ganancia de referencia
y el ancho del haz. La ganancia de referencia se calcula a mano. Cada caso de prueba pasa si el
la ganancia de referencia en dB es igual al valor devuelto por CosenoAntenaModelo dentro de un
tolerancia de 0.001, que da cuenta de la aproximación realizada para el cálculo de la
Valores de referencia.

ParabólicoAntenaModelo
La suite de pruebas unitarias modelo-antena-parabólica comprueba que el ParabólicoAntenaModelo clase
trabaja apropiadamente. Se proporcionan varios casos de prueba que verifican el valor de ganancia de la antena
calculado en diferentes direcciones y para diferentes valores de la orientación, el
atenuación máxima y el ancho del haz. La ganancia de referencia se calcula a mano. Cada prueba
caso pasa si la ganancia de referencia en dB es igual al valor devuelto por
ParabólicoAntenaModelo dentro de una tolerancia de 0.001, que representa la aproximación
realizado para el cálculo de los valores de referencia.

AD HOC BAJO DEMANDA DISTANCIA VECTOR (AODV)

Este modelo implementa la especificación básica del vector de distancia ad hoc bajo demanda
(AODV) protocolo. La implementación se basa en RFC 3561.

El modelo fue escrito por Elena Buchatskaia y Pavel Boyko de ITTP RAS, y se basa en
el modelo ns-2 AODV desarrollado por el grupo CMU / MONARCH y optimizado y ajustado por Samir
Das y Mahesh Marina, Universidad de Cincinnati, y también sobre la implementación de AODV-UU por
Erik Nordström de la Universidad de Uppsala.

Modelo Descripción
El código fuente del modelo AODV vive en el directorio src / aodv.

Design
Clase ns3 :: aodv :: RoutingProtocol implementa toda la funcionalidad del intercambio de paquetes de servicio
y hereda de ns3 :: Ipv4RoutingProtocol. La clase base define dos funciones virtuales
para enrutamiento y reenvío de paquetes. El primero, ns3 :: aodv :: RouteOutput, se utiliza para
paquetes de origen local, y el segundo, ns3 :: aodv :: RouteInput, se utiliza para
reenviar y / o entregar paquetes recibidos.

El funcionamiento del protocolo depende de muchos parámetros ajustables. Parámetros para esto
la funcionalidad son atributos de ns3 :: aodv :: RoutingProtocol. Los valores predeterminados de los parámetros son
extraídos del RFC y permiten las funciones de protocolo de habilitación / deshabilitación, como
difundir mensajes de HOLA, difundir paquetes de datos, etc.

AODV descubre rutas bajo demanda. Por lo tanto, el modelo AODV almacena en búfer todos los paquetes mientras
Se difunde el paquete de solicitud de ruta (RREQ). Se implementa una cola de paquetes en
aodv-rqueue.cc. Un puntero inteligente al paquete, ns3 :: Ipv4RoutingProtocol :: ErrorCallback,
ns3 :: Ipv4RoutingProtocol :: UnicastForwardCallback, y el encabezado IP se almacenan en este
cola. La cola de paquetes implementa la recolección de basura de paquetes antiguos y un tamaño de cola
límite.

La implementación de la tabla de enrutamiento admite la recolección de basura de entradas antiguas y estados
máquina, definida en la norma. Se implementa como un contenedor de mapas STL. La clave es un
Dirección IP de destino.

Algunos elementos de la operación del protocolo no se describen en el RFC. Estos elementos generalmente
se refieren a la cooperación de diferentes capas del modelo OSI. El modelo utiliza lo siguiente
heurísticas:

· Esta implementación AODV puede detectar la presencia de enlaces unidireccionales y evitarlos
si necesario. Si el nodo para el que el modelo recibe un RREQ es un vecino, la causa puede
ser un enlace unidireccional. Esta heurística se toma de la implementación de AODV-UU y puede
estar discapacitado.

· El funcionamiento del protocolo depende en gran medida del mecanismo de detección de enlaces rotos. El modelo
implementa dos de tales heurísticas. Primero, esta implementación soporta los mensajes HOLA.
Sin embargo, los mensajes HOLA no son una buena forma de realizar la detección de vecinos en un
entorno (al menos no sobre 802.11). Por lo tanto, uno puede experimentar un mal desempeño.
cuando se ejecuta de forma inalámbrica. Hay varias razones para esto: 1) Los mensajes de HOLA son
emitido. En 802.11, la transmisión se realiza a menudo a una tasa de bits más baja que la unidifusión,
por lo tanto, los mensajes HELLO pueden viajar más lejos que los datos de unidifusión. 2) Los mensajes de HOLA son pequeños,
por lo tanto, menos propenso a errores de bits que las transmisiones de datos, y 3) transmisiones de difusión
no se garantiza que sean bidireccionales, a diferencia de las transmisiones unicast. En segundo lugar, usamos
retroalimentación de la capa 2 cuando sea posible. Se considera que el enlace está roto si la transmisión de la trama
da como resultado una falla de transmisión para todos los reintentos. Este mecanismo está destinado a
enlaces y funciona más rápido que el primer método.

La implementación de la retroalimentación de capa 2 se basa en TxErrEncabezado fuente de rastreo, actualmente
compatible solo con AdhocWifiMac.

<b></b><b></b> y Limitaciones
El modelo es solo para IPv4. Las siguientes optimizaciones de protocolo opcionales no son
implementado:

1. Ampliación de la búsqueda de anillos.

2. Reparación de enlace local.

3. Extensiones de mensajes RREP, RREQ y HELLO.

Estas técnicas requieren acceso directo al encabezado IP, lo que contradice la afirmación de
el AODV RFC que AODV trabaja sobre UDP. Este modelo usa UDP por simplicidad, lo que dificulta la
capacidad para implementar ciertas optimizaciones de protocolo. El modelo no usa raw de capa baja
enchufes porque no son portátiles.

Futuro Trabaja
No hay planes anunciados.

Referencias
Uso
Ejemplos
Ayudantes
Atributos
Rastreo
Inicio de sesión
Advertencias
Validación
Unidad pruebas
Escala más grande Rendimiento pruebas

APLICACIONES

marcador de posición capítulo

PUENTE DISPOSITIVO DE RED

marcador de posición capítulo

Algunos ejemplos del uso de Bridge NetDevice se pueden encontrar en ejemplos / csma / directorio.

BRITO INTEGRACIÓN

Este modelo implementa una interfaz para BRITE, el Representante de Internet de la Universidad de Boston.
Generador de topología [1]. BRITE es una herramienta estándar para generar Internet realista
topologías. El modelo ns-3, descrito en este documento, proporciona una clase auxiliar para facilitar
generando topologías específicas de ns-3 usando archivos de configuración BRITE. BRITE construye el
gráfico original que se almacena como nodos y bordes en la clase ns-3 BriteTopolgyHelper. En
la integración ns-3 de BRITE, el generador genera una topología y luego proporciona acceso
a los nodos de hoja para cada AS generado. Los usuarios de ns-3 pueden adjuntar topologías personalizadas a
estos nodos hoja, ya sea creándolos manualmente o utilizando generadores de topología proporcionados en
ns-3.

Hay tres tipos principales de topologías disponibles en BRITE: Router, AS y
Jerárquico, que es una combinación de AS y enrutador. Para los propósitos de ns-3
simulación, es probable que los más útiles sean Router y Hierarchical. Nivel de enrutador
Las topologías se generarán utilizando el modelo de Waxman o el modelo de Barabasi-Albert. Cada
modelo tiene diferentes parámetros que afectan la creación de topología. Para topologías de enrutador plano,
se considera que todos los nodos están en el mismo AS.

Las topologías jerárquicas BRITE contienen dos niveles. El primero es el nivel AS. Este nivel
también se puede crear utilizando el modelo Waxman o el modelo Barabasi-Albert.
Luego, para cada nodo en la topología AS, se construye una topología a nivel de enrutador. Estas
Las topologías de nivel de enrutador pueden volver a utilizar el modelo Waxman o el modelo Barbasi-Albert.
BRITE interconecta estas topologías de enrutador separadas según lo especificado por el nivel de AS
topología. Una vez que se construye la topología jerárquica, se aplana en una gran
topología a nivel de enrutador.

Puede encontrar más información en el manual de usuario de BRITE:
http://www.cs.bu.edu/brite/publications/usermanual.pdf

Modelo Descripción
El modelo se basa en la construcción de una biblioteca BRITE externa y luego en la construcción de algunos ns-3
ayudantes que llaman a la biblioteca. El código fuente de los ayudantes ns-3 vive en el
directorio src / brite / helper.

Design
Para generar la topología BRITE, los ayudantes ns-3 llaman a la biblioteca BRITE externa y
utilizando un archivo de configuración estándar de BRITE, el código BRITE construye un gráfico con nodos y
bordes de acuerdo con este archivo de configuración. Consulte la documentación de BRITE o el
archivos de configuración de ejemplo en src / brite / examples / conf_files para comprender mejor
Opciones de configuración BRITE. El gráfico construido por BRITE se devuelve a ns-3, y un ns-3
Se construye la implementación del gráfico. Los nodos hoja para cada AS están disponibles para el usuario
para adjuntar topologías personalizadas o instalar aplicaciones ns-3 directamente.

Referencias
[1] Alberto Medina, Anukool Lakhina, Ibrahim Matta y John Byers. BRITE: una aproximación a
Generación de topología universal. En Actas del Taller Internacional sobre
Modelado, Análisis y Simulación de Sistemas de Computación y Telecomunicaciones - MASCOTS
'01, Cincinnati, Ohio, agosto de 2001.

Uso
Se puede hacer referencia a brite-generic-example para ver el uso básico de la interfaz BRITE. En
En resumen, BriteTopologyHelper se utiliza como punto de interfaz pasando un BRITE
archivo de configuración. Junto con el archivo de configuración, un archivo semilla aleatorio con formato BRITE
también se puede pasar. Si no se pasa un archivo semilla, el asistente creará una semilla
archivo usando UniformRandomVariable de ns-3. Una vez que BRITE haya generado la topología,
Se llama a BuildBriteTopology () para crear la representación ns-3. La siguiente dirección IP puede ser
asignado a la topología usando AssignIpv4Addresses () o AssignIpv6Addresses (). Eso
Cabe señalar que cada enlace punto a punto en la topología se tratará como un nuevo
Por lo tanto, para IPV4 se debe usar una subred / 30 para evitar desperdiciar una gran cantidad de
el espacio de direcciones disponible.

Se pueden encontrar archivos de configuración BRITE de ejemplo en / src / brite / examples / conf_files /.
ASBarbasi y ASWaxman son ejemplos de topologías de solo AS. El RTBarabasi y RTWaxman
Los archivos son ejemplos de topologías de solo enrutador. Finalmente el TD_ASBarabasi_RTWaxman
archivo de configuración es un ejemplo de una topología jerárquica que utiliza el Barabasi-Albert
modelo para el nivel AS y el modelo Waxman para cada una de las topologías de nivel de enrutador.
La información sobre los parámetros de BRITE utilizados en estos archivos se puede encontrar en el usuario de BRITE
manual.

Contruyendo BRITO Integración:
El primer paso es descargar y construir el repositorio BRITE específico de ns-3:

$ hg clon http://code.nsnam.org/BRITE
$ cd BRITE
$ make

Esto construirá BRITE y creará una biblioteca, libbrite.so, dentro del directorio BRITE.

Una vez que BRITE se ha construido con éxito, procedemos a configurar ns-3 con soporte BRITE.
Cambie a su directorio ns-3:

$ ./waf configure --with-brite = / su / ruta / a / brite / source --enable-examples

Asegúrese de que diga "habilitado" junto a "Integración BRITE". Si no es así, entonces algo tiene
fué mal. O ha olvidado construir BRITE primero siguiendo los pasos anteriores, o
ns-3 no pudo encontrar su directorio BRITE.

A continuación, compile ns-3:

$ ./waf

Ejemplos
Para ver un ejemplo que demuestra la ejecución de la integración BRITE:

$ ./waf --run 'brite-generic-example'

Al habilitar el parámetro detallado, el ejemplo imprimirá el nodo y el borde
información en un formato similar a la salida BRITE estándar. Hay muchos otros
parámetros de la línea de comandos, incluidos confFile, tracing y nix, que se describen a continuación:

confArchivo
Un archivo de configuración BRITE. Muchos ejemplos de archivos de configuración BRITE diferentes
existen en el directorio src / brite / examples / conf_files, por ejemplo,
RTBarabasi20.conf y RTWaxman.conf. Consulte el directorio conf_files
para mas ejemplos

rastreo
Habilita el rastreo ascii.

nix Habilita el enrutamiento nix-vector. El enrutamiento global se utiliza de forma predeterminada.

El ejemplo genérico de BRITE también admite la visualización usando pyviz, asumiendo enlaces de Python
en ns-3 están habilitados:

$ ./waf --ejecutar brite-generic-example --vis

Las simulaciones que involucran a BRITE también se pueden usar con MPI. El número total de instancias de MPI
se pasa al ayudante de topología BRITE donde se usa una división de módulo para asignar los nodos
para cada AS a una instancia de MPI. Se puede encontrar un ejemplo en src / brite / examples:

$ mpirun -np 2 ./waf --run brite-MPI-ejemplo

Consulte la documentación de ns-3 MPI para obtener información sobre cómo configurar MPI con ns-3.

EDIFICIOS MÓDULO

cd .. incluir :: reemplazar.txt

Design documentación
Descripción General
El módulo Edificios proporciona:

1. una nueva clase (Contruyendo) que modela la presencia de un edificio en una simulación
guión;

2. una nueva clase (MovilidadEdificioInfo) que permite especificar la ubicación, tamaño y
características de los edificios presentes en el área simulada, y permite la colocación
de nodos dentro de esos edificios;

3. una clase de contenedor con la definición de los modelos de pérdida de trayectoria más útiles y la
variables correspondientes llamadas EdificiosPropagaciónPérdidaModelo.

4. un nuevo modelo de propagación (HíbridoEdificiosPropagaciónPérdidaModelo) trabajando con el
modelo de movilidad recién introducido, que permite modelar el fenómeno de
propagación interior / exterior en presencia de edificios.

5. un modelo simplificado que funciona solo con Okumura Hata (OhEdificiosPropagaciónPérdidaModelo)
teniendo en cuenta el fenómeno de la propagación interior / exterior en presencia de
edificios

Los modelos se han diseñado pensando en LTE, aunque su implementación es de hecho
independiente de cualquier código específico de LTE y se puede utilizar con otros dispositivos inalámbricos ns-3
tecnologías también (por ejemplo, wifi, wimax).

La HíbridoEdificiosPropagaciónPérdidaModelo El modelo de pérdida de trayectoria incluido se obtiene mediante un
combinación de varios modelos de pérdida de trayectoria bien conocidos para imitar diferentes
escenarios ambientales como áreas urbanas, suburbanas y abiertas. Además, el modelo
considera que se debe incluir comunicación tanto en el exterior como en el interior, tanto en el interior como en el exterior
ya que HeNB se puede instalar tanto dentro como fuera del edificio. En caso de interior
comunicación, el modelo debe considerar también el tipo de edificio en exterior <-> interior
comunicación de acuerdo con algunos criterios generales como las pérdidas de penetración de la pared de
los materiales comunes; además incluye alguna configuración general para el interno
paredes en comunicaciones interiores.

La OhEdificiosPropagaciónPérdidaModelo El modelo de pathloss se ha creado para simplificar la
anterior eliminando los umbrales para cambiar de un modelo a otro. Por hacer esto
Se ha utilizado solo un modelo de propagación del disponible (es decir, el Okumura
Hata). La presencia de edificio todavía se considera en el modelo; por lo tanto todo el
Las consideraciones anteriores con respecto al tipo de edificio siguen siendo válidas. Lo mismo
Se puede considerar lo que concierne al escenario ambiental y la frecuencia, ya que
ambos son parámetros del modelo considerado.

La Contruyendo clase
El modelo incluye una clase específica llamada Contruyendo que contiene un ns3 Caja clase para
definiendo la dimensión del edificio. Para implementar las características del
modelos de pathloss incluidos, el Contruyendo La clase admite los siguientes atributos:

· tipo de construcción:

· Residencial (valor predeterminado)

· Oficina

· Comercial

· Tipo de paredes externas

· Madera

· ConcreteWithWindows (valor predeterminado)

· Hormigón sin ventanas

· Bloques de piedra

· Número de pisos (valor predeterminado 1, que significa solo planta baja)

· Número de habitaciones en el eje x (valor predeterminado 1)

· Número de habitaciones en el eje y (valor predeterminado 1)

La clase Building se basa en los siguientes supuestos:

· Un edificio se representa como un paralelepípedo rectangular (es decir, una caja)

· Las paredes son paralelas a los ejes x, y, z

· Un edificio se divide en una cuadrícula de habitaciones, identificadas por los siguientes parámetros:

· numero de pisos

· Número de habitaciones a lo largo del eje x

· Número de habitaciones a lo largo del eje y

· El eje z es el eje vertical, es decir, los números de piso aumentan al aumentar el eje z
valores

· Los índices de habitación xey comienzan desde 1 y aumentan a lo largo del eje xey
respectivamente

· Todas las habitaciones de un edificio tienen el mismo tamaño

La MovilidadEdificioInfo clase
La MovilidadEdificioInfo clase, que hereda de la clase ns3 Objeto, esta a cargo de
mantener información sobre la posición de un nodo con respecto al edificio. los
información gestionada por MovilidadEdificioInfo :

· Si el nodo es interior o exterior

· Si es interior:

· En qué edificio se encuentra el nodo

· En qué habitación está posicionado el nodo (índices de habitación de piso x, y)

La clase MovilidadEdificioInfo es utilizado por EdificiosPropagaciónPérdidaModelo clase, que
hereda de la clase ns3 PropagaciónPérdidaModelo y gestiona el cálculo de la pérdida de trayectoria de
los componentes individuales y su composición de acuerdo con las posiciones de los nodos. Es más,
También implementa el sombreado, que es la pérdida por obstáculos en el camino principal.
(es decir, vegetación, edificios, etc.).

Cabe señalar que, MovilidadEdificioInfo puede ser utilizado por cualquier otro modelo de propagación.
Sin embargo, según la información en el momento de escribir este artículo, solo los definidos en
El módulo de construcción está diseñado para considerar las limitaciones introducidas por el
edificios
g
ItuR1238PropagaciónPérdidaModelo
Esta clase implementa un modelo de pérdida de propagación en interiores dependiente del edificio basado en la UIT
P.1238 modeg {que incluye pérdidas debidas al tipo de edificio (es decir, residencial, de oficinas y
comercial) ia La expresión analítica se da a continuación.
nr
{r
aa
donde: ry ight. : pérdida de potencia
N = tr} sidential \ 30 & office \ 22 & commercial \ nd {array}
coeficiente [dB]
y luz.
L_f = t} lateral \ 15 + 4 (n-1) y oficina \ 6 + 3 (n-1) y comercial \ nd {matriz}
{l
n: número de pisos entre la estación base y el móvil (n 1)
l2
f: frecuencia [MHz]
}&
d: distancia (donde d> 1) [m]
n
EdificiosPropag&aciónPérdidaModelo
BuildingsPropagationLossModel proporciona un conjunto adicional de
elementos del modelo de pathloss que se utilizan para implementar diferentes lógicas de pathloss. Estas
Los elementos del modelo de pathloss se describen en las siguientes subsecciones.

Externo Pared Loss (LEP)
Este componente modela la pérdida de penetración a través de las paredes para interiores y exteriores.
comunicaciones y viceversa. Los valores se toman del modelo [cost231].

· Madera ~ 4 dB

· Hormigón con ventanas (no metalizado) ~ 7 dB

· Hormigón sin ventanas ~ 15 dB (se extiende entre 10 y 20 en COST231)

· Bloques de piedra ~ 12 dB

Interno Paredes Loss (LO HARÉ)
Este componente modela la pérdida de penetración que se produce en las comunicaciones de interior a interior.
dentro del mismo edificio. La pérdida total se calcula asumiendo que cada uno de los
pared tiene una pérdida de penetración constante L_ {siw}, y se aproxima al número de paredes que
se penetran con la distancia de Manhattan (en número de habitaciones) entre el transmisor
y el receptor. En detalle, supongamos que x_1, y_1, x_2, y_2 denotan el número de habitación a lo largo de x y
eje y respectivamente para el usuario 1 y 2; la pérdida total L_ {IWL} se calcula como

ALTO Obten Modelo (HG)
Este componente modela la ganancia debido al hecho de que el dispositivo transmisor está en un piso
por encima del suelo. En la literatura [turkmani] esta ganancia se ha evaluado en aproximadamente 2 dB
por piso. Esta ganancia se puede aplicar a todas las comunicaciones de interior a exterior y
viceversa.

Sombra Modelo
El sombreado se modela de acuerdo con una distribución logarítmica normal con estándar variable
desviación en función de la posición relativa (interior o exterior) del MobilityModel
instancias involucradas. Se extrae un valor aleatorio para cada par de MobilityModels, y permanece
constante para ese par durante toda la simulación. Por tanto, el modelo es apropiado para
solo nodos estáticos.

El modelo considera que la media de la pérdida de sombreado en dB es siempre 0. Para el
varianza, el modelo considera tres posibles valores de desviación estándar, en detalle:
ightarrow X_thrm {O}
· exterior (m_shadowingSigmaAl aire libre, valor predeterminado de 7 dB)
N (_thrm {O}, ma_thrm {O} ^ 2).
ightarrow X_thrm {I}
· Interior (m_shadowingSigmaInterior, valor predeterminado de 10 dB)
N (_thrm {I}, ma_thrm {I} ^ 2).
flecha
· Penetración de paredes externas (m_shadowingSigmaExtWalls, valor predeterminado 5 dB)
X_thrm {W} N (_thrm {W}, ma_thrm {W} ^ 2)

El simulador genera un valor de sombreado por cada enlace activo según los nodos '
posición la primera vez que se utiliza el enlace para transmitir. En caso de transmisiones desde
nodos exteriores a interiores, y viceversa, la desviación estándar (ma_thrm {IO}) tiene que
calcularse como la raíz cuadrada de la suma de los valores cuadráticos del estándar
desviación en caso de nudos exteriores y la de penetración de paredes exteriores. Este es
debido al hecho de que los componentes que producen el sombreado son independientes de cada
otro; por lo tanto, la varianza de una distribución resultante de la suma de dos
los normales es la suma de las variaciones.

Camino perdido lógicas
A continuación, describimos las diferentes lógicas de pérdida de ruta que implementan
heredando de BuildingsPropagationLossModel.

HíbridoEdificiosPropagaciónPérdidaModelo
La HíbridoEdificiosPropagaciónPérdidaModelo El modelo de pérdida de trayectoria incluido se obtiene mediante un
combinación de varios modelos de pathloss bien conocidos para imitar diferentes
escenarios de interior, así como escenarios de interior a exterior y de exterior a interior. En detalle,
la clase HíbridoEdificiosPropagaciónPérdidaModelo integra los siguientes modelos de pérdida de trayectoria:

· OkumuraHataPropagationLossModel (OH) (a frecuencias> 2.3 GHz sustituido por
Modelo de pérdida de propagación Kun2600Mhz)

· ItuR1411LosPropagationLossModel y ItuR1411NlosOverRooftopPropagationLossModel
(E1411)

· Modelo de pérdida de propagación ItuR1238 (I1238)

· Los elementos pathloss del BuildingsPropagationLossModel (EWL, HG, IWL)

El siguiente pseudocódigo ilustra cómo se describen los diferentes elementos del modelo de pérdida de ruta
arriba están integrados en HíbridoEdificiosPropagaciónPérdidaModelo:

si (txNode está al aire libre)
después
si (rxNode está al aire libre)
después
si (distancia> 1 km)
después
si (rxNode o txNode está debajo de la azotea)
después
L=I1411
más
L = OH
más
L=I1411
else (rxNode es interior)
si (distancia> 1 km)
después
si (rxNode o txNode está debajo de la azotea)
L = I1411 + EWL + HG
más
L = OH + EWL + HG
más
L = I1411 + EWL + HG
else (txNode es interior)
si (rxNode es interior)
después
si (mismo edificio)
después
L = I1238 + LIT
más
L = I1411 + 2 * EWL
else (rxNode está al aire libre)
si (distancia> 1 km)
después
si (rxNode o txNode está debajo de la azotea)
después
L = I1411 + EWL + HG
más
L = OH + EWL + HG
más
L = I1411 + PLE

Observamos que, para el caso de la comunicación entre dos nodos por debajo del nivel de la azotea con
distancia es mayor que 1 km, todavía consideramos el modelo I1411, ya que OH es específicamente
diseñado para macrocélulas y, por lo tanto, para antenas por encima del nivel de la azotea.

Para el modelo ITU-R P.1411 consideramos las versiones LOS y NLoS. En particular, nosotros
considera la propagación de LoS para distancias que son más cortas que un umbral sintonizable
(m_itu1411NlosUmbral). En caso de propagación NLoS, el modelo sobre el techo es
tomado en consideración para el modelado tanto macro BS como SC. En caso de que en NLoS varios
Se han incluido parámetros dependientes del escenario, como el ancho medio de la calle,
orientación, etc. Los valores de dichos parámetros deben configurarse correctamente de acuerdo con la
escenario implementado, el modelo no calcula de forma nativa sus valores. En caso de que
Se proporcionan valores, se utilizan los estándar, aparte de la altura del móvil y BS,
que, en cambio, su integridad se prueba directamente en el código (es decir, tienen que ser
mayor que cero). A continuación damos las expresiones de los componentes de la
modelo.

También observamos que el uso de diferentes modelos de propagación (OH, I1411, I1238 con sus
variantes) en HybridBuildingsPropagationLossModel puede resultar en discontinuidades del
Pérdida de trayectoria con respecto a la distancia. Un ajuste adecuado de los atributos (especialmente el
atributos de umbral de distancia) pueden evitar estas discontinuidades. Sin embargo, dado que el
El comportamiento de cada modelo depende de varios otros parámetros (frecuencia, altura del nodo, etc.),
No existe un valor predeterminado de estos umbrales que pueda evitar las discontinuidades en todos
posibles configuraciones. Por lo tanto, el ajuste apropiado de estos parámetros se deja al
.

OhEdificiosPropagaciónPérdidaModelo
La OhEdificiosPropagaciónPérdidaModelo ha sido creada como un medio simple para resolver el
problemas de discontinuidad de HíbridoEdificiosPropagaciónPérdidaModelo sin hacer
ajuste de parámetros específicos del escenario. La solución es usar solo una pérdida de propagación
modelo (es decir, Okumura Hata), manteniendo la estructura de la lógica de pérdida de trayectoria para el
cálculo de otros componentes de pérdida de trayectoria (como pérdidas por penetración de muros). El resultado es
un modelo que está libre de discontinuidades (excepto las debidas a las paredes), pero que es menos
realista en general para un escenario genérico con edificios y usuarios exteriores / interiores, por ejemplo,
porque Okumura Hata no es adecuado ni para comunicaciones en interiores ni para exteriores
comunicaciones por debajo del nivel de la azotea.

En detalle, la clase OhEdificiosPropagaciónPérdidaModelo integra el siguiente pathloss
modelos:

· Modelo de pérdida de propagación de OkumuraHata (OH)

· Los elementos pathloss del BuildingsPropagationLossModel (EWL, HG, IWL)

El siguiente pseudocódigo ilustra cómo se describen los diferentes elementos del modelo de pérdida de ruta
arriba están integrados en OhEdificiosPropagaciónPérdidaModelo:

si (txNode está al aire libre)
después
si (rxNode está al aire libre)
después
L = OH
else (rxNode es interior)
L = OH + EWL
else (txNode es interior)
si (rxNode es interior)
después
si (mismo edificio)
después
L = OH + LIT
más
L = OH + 2 * EWL
else (rxNode está al aire libre)
L = OH + EWL

Observamos que OhBuildingsPropagationLossModel es una simplificación significativa con respecto
a HybridBuildingsPropagationLossModel, debido al hecho de que OH se usa siempre. Mientras esto
da un modelo menos preciso en algunos escenarios (especialmente debajo de la azotea y en interiores),
evita eficazmente el problema de las discontinuidades de la pérdida de trayectoria que afecta
Modelo de pérdida de propagación de edificios híbridos.

User Documentación
Cómo a use edificios in a simulación
En esta sección explicamos el uso básico del modelo de edificios dentro de una simulación.
.

Incluir los cabeceras
Agregue esto al comienzo de su programa de simulación:

#incluir

Crear a edificio
Como ejemplo, creemos un edificio residencial de 10 x 20 x 10:

doble x_min = 0.0;
doble x_max = 10.0;
doble y_min = 0.0;
doble y_max = 20.0;
doble z_min = 0.0;
doble z_max = 10.0;
Ptr b = CreateObject ();
b-> Establecer límites (Box (x_min, x_max, y_min, y_max, z_min, z_max));
b-> SetBuildingType (Edificio :: Residencial);
b-> SetExtWallsType (Edificio :: ConcreteWithWindows);
b-> SetNFloors (3);
b-> SetNRoomsX (3);
b-> SetNRoomsY (2);

Este edificio tiene tres pisos y una cuadrícula interna de 3 x 2 habitaciones de igual tamaño.

La clase auxiliar GridBuildingAllocator también está disponible para crear fácilmente un conjunto de
Edificios de idénticas características colocados sobre una cuadrícula rectangular. Aquí hay un ejemplo
de cómo usarlo:

Ptr gridBuildingAllocator;
gridBuildingAllocator = CreateObject ();
gridBuildingAllocator-> SetAttribute ("GridWidth", UintegerValue (3));
gridBuildingAllocator-> SetAttribute ("LongitudX", DoubleValue (7));
gridBuildingAllocator-> SetAttribute ("LongitudY", DoubleValue (13));
gridBuildingAllocator-> SetAttribute ("DeltaX", DoubleValue (3));
gridBuildingAllocator-> SetAttribute ("DeltaY", DoubleValue (3));
gridBuildingAllocator-> SetAttribute ("Altura", DoubleValue (6));
gridBuildingAllocator-> SetBuildingAttribute ("NRoomsX", UintegerValue (2));
gridBuildingAllocator-> SetBuildingAttribute ("NRoomsY", UintegerValue (4));
gridBuildingAllocator-> SetBuildingAttribute ("NFloors", UintegerValue (2));
gridBuildingAllocator-> SetAttribute ("MinX", DoubleValue (0));
gridBuildingAllocator-> SetAttribute ("MinY", DoubleValue (0));
gridBuildingAllocator-> Create (6);

Esto creará una cuadrícula de 3x2 de 6 edificios, cada uno de 7 x 13 x 6 m con 2 x 4 habitaciones en el interior y
2 pisos; los edificios están espaciados por 3 m tanto en el eje x como en el eje y.

Preparar nodos y movilidad modelos
Los nodos y modelos de movilidad se configuran como de costumbre, sin embargo para poder utilizarlos con el
modelo de edificios para el que necesita una llamada adicional BuildingsHelper :: Install (), para dejar
el modelo de movilidad incluye la información sobre su posición en los edificios. Aquí está
un ejemplo:

MobilityHelper movilidad;
movilidad.SetMobilityModel ("ns3 :: ConstantPositionMobilityModel");
ueNodes.Crear (2);
movilidad.Instalar (ueNodes);
BuildingsHelper :: Install (ueNodes);

Cabe señalar que se puede utilizar cualquier modelo de movilidad. Sin embargo, se aconseja al usuario que
asegurarse de que el comportamiento del modelo de movilidad que se utiliza sea coherente con el
presencia de Edificios. Por ejemplo, usando una simple movilidad aleatoria sobre el conjunto
El área de simulación en presencia de edificios puede fácilmente dar como resultado que el nodo se mueva dentro y fuera de
edificios, independientemente de la presencia de muros.

Especial some nodos
Puede colocar nodos en su simulación utilizando varios métodos, que se describen en la
siguiente.

Legado posicionamiento métodos
Se puede utilizar cualquier método de posicionamiento ns-3 heredado para colocar el nodo en la simulación. los
Un paso adicional importante es Por ejemplo, puede colocar nodos manualmente de esta manera:

Ptr mm0 = enbNodes.Get (0) -> GetObject ();
Ptr mm1 = enbNodes.Get (1) -> GetObject ();
mm0-> SetPosition (Vector (5.0, 5.0, 1.5));
mm1-> SetPosition (Vector (30.0, 40.0, 1.5));

MobilityHelper movilidad;
movilidad.SetMobilityModel ("ns3 :: ConstantPositionMobilityModel");
ueNodes.Crear (2);
movilidad.Instalar (ueNodes);
BuildingsHelper :: Install (ueNodes);
mm0-> SetPosition (Vector (5.0, 5.0, 1.5));
mm1-> SetPosition (Vector (30.0, 40.0, 1.5));

Alternativamente, puede usar cualquier clase PositionAllocator existente. Las coordenadas del
El nodo determinará si se coloca al aire libre o en el interior y, si es interior, en qué
Edificio y habitacion donde se ubica.

Específico del edificio posicionamiento métodos
Las siguientes clases de asignador de posición están disponibles para colocar el nodo en posiciones especiales
con respecto a los edificios:

· Asignador de posición de edificio aleatorio: Asignar cada posición eligiendo al azar un
edificio de la lista de todos los edificios, y luego elegir al azar una posición dentro
el edificio.

· Asignador de posición de habitación aleatoria: Asigne cada posición eligiendo aleatoriamente una habitación de
la lista de habitaciones en todos los edificios, y luego elegir al azar una posición dentro del
habitación.

· Asignador de posición de la misma habitación: Recorre un NodeContainer determinado secuencialmente, y para cada
nodo asigna una nueva posición al azar en la misma habitación de ese nodo.

· Asignador de posición de habitación fija: Genera una posición aleatoria distribuida uniformemente en el
volumen de una habitación elegida dentro de un edificio elegido.

Haz los Movilidad Modelo Consistente
Importante:: siempre que use edificios, debe emitir el siguiente comando después de que
han colocado todos los nodos y edificios en la simulación:

BuildingsHelper :: MakeMobilityModelConsistent ();

Este comando recorrerá las listas de todos los nodos y de todos los edificios, determinará
cada usuario si es interior o exterior, y si es interior, también determinará el edificio en
donde se encuentra el usuario y el piso y número correspondiente en el interior del edificio.

Consciente de la construcción Camino perdido modelo
Después de colocar edificios y nodos en una simulación, puede utilizar una
modelo de pérdida de ruta en una simulación exactamente de la misma manera que usaría cualquier pérdida de ruta regular
modelo. Cómo hacer esto es específico para el módulo inalámbrico que está considerando (lte,
wifi, wimax, etc.), así que consulte la documentación de ese modelo para obtener información específica.
instrucciones.

Main configurable atributos
La Contruyendo La clase tiene los siguientes parámetros configurables:

· Tipo de edificio: Residencial, Oficinas y Comercial.

· Tipo de muros externos: Madera, Hormigón con Ventanas, Hormigón Sin Ventanas y Bloques de Piedra.

· Límites del edificio: a Caja clase con los límites del edificio.

· numero de pisos.

· Número de habitaciones en el eje xy el eje y (las habitaciones solo se pueden colocar en forma de cuadrícula).

La EdificioMovilidadPérdidaModelo parámetro configurable con el sistema de atributos ns3 es
representado por el límite (cadena Límites) del área de simulación proporcionando un Caja clase
con los límites del área. Además, por medio de sus métodos, los siguientes parámetros pueden ser
configurado:

· El número de piso en el que se coloca el nodo (predeterminado 0).

· La posición en la cuadrícula de habitaciones.

La EdificioPropagaciónPérdidaModelo la clase tiene los siguientes parámetros configurables
configurable con el sistema de atributos:

· Frecuencia: frecuencia de referencia (por defecto 2160 MHz), tenga en cuenta que al configurar la frecuencia
la longitud de onda se ajusta en consecuencia automáticamente y viceversa).

· lambda: la longitud de onda (0.139 metros, considerando la frecuencia anterior).

· SombraSigmaAl Aire Libre: la desviación estándar del sombreado para nodos exteriores (predeterminado
7.0).

· SombraSigmaInterior: la desviación estándar del sombreado para nodos interiores (predeterminado
8.0).

· SombraSigmaExtMuros: la desviación estándar del sombreado debido a las paredes externas
penetración para comunicaciones de exterior a interior (por defecto 5.0).

· AzoteaNivel: el nivel de la azotea del edificio en metros (por defecto 20 metros).

· Los2NlosThr: el valor de la distancia del punto de conmutación entre la línea de sigth y
modelo de propagación sin línea de visión en metros (por defecto 200 metros).

· ITU1411DistanciaThr: el valor de la distancia del punto de conmutación entre corto alcance
(ITU 1211) comunicaciones y largo alcance (Okumura Hata) en metros (por defecto 200 metros).

· Distancia mínima: la distancia mínima en metros entre dos nodos para evaluar la
Pérdida de trayectoria (considerada insignificante antes de este umbral) (por defecto 0.5 metros).

· Medio Ambiente: el escenario de entorno entre Urban, SubUrban y OpenAreas (predeterminado
Urbano).

· Tamaño de la ciudad: la dimensión de la ciudad entre Pequeño, Mediano, Grande (por defecto Grande).

Para utilizar el modo híbrido, la clase a utilizar es la
HíbridoEdificioMovilidadPérdidaModelo, que permite la selección del modelo de pérdida de trayectoria adecuado
de acuerdo con la lógica de pérdida de trayectoria presentada en el capítulo de diseño. Sin embargo, esta solución
tiene el problema de que los puntos de conmutación del modelo pathloss pueden presentar discontinuidades debido a
a las diferentes características del modelo. Esto implica que de acuerdo con el
escenario, el umbral utilizado para la conmutación debe ajustarse correctamente. Lo simple
OhEdificioMovilidadPérdidaModelo superar este problema utilizando solo el modelo Okumura Hata y
las pérdidas de penetración de la pared.

Pruebas Documentación
Descripción General
Para probar y validar el módulo ns-3 Building Pathloss, se proporcionan algunos conjuntos de pruebas que
están integrados con el marco de prueba ns-3. Para ejecutarlos, debe haber configurado el
construir el simulador de esta manera:

$ ./waf configure --enable-tests --enable-modules = edificios
$ ./prueba.py

Lo anterior ejecutará no solo las suites de prueba que pertenecen al módulo de edificios, sino también
los pertenecientes a todos los demás módulos ns-3 de los que depende el módulo de edificios. Ver
el manual ns-3 para obtener información genérica sobre el marco de prueba.

Puede obtener un informe más detallado en formato HTML de esta manera:

$ ./prueba.py -w resultados.html

Una vez que se haya ejecutado el comando anterior, puede ver el resultado detallado de cada prueba abriendo
el archivo resultados.html con un navegador web.

Puede ejecutar cada conjunto de pruebas por separado con este comando:

$ ./test.py -s nombre-del-conjunto-de-pruebas

Para más detalles sobre prueba.py y el marco de prueba ns-3, consulte el ns-3
manual.

Descripción of los testea suites
EdificiosAyudante testea
La suite de pruebas ayudante de edificios comprueba que el método
BuildingsHelper :: MakeAllInstancesConsistent () funciona correctamente, es decir, que el
BuildingsHelper tiene éxito en localizar si los nodos están al aire libre o en interiores, y si son interiores
que estén ubicados en el edificio, la habitación y el piso correctos. Varios casos de prueba son
provistas de diferentes edificios (que tienen diferentes tamaños, posiciones, habitaciones y pisos) y
diferentes posiciones de los nodos. La prueba pasa si cada uno de los nodos está ubicado correctamente.

Asignador de posición de edificio testea
La suite de pruebas asignador-de-puestos-de-edificio cuentan con dos casos de prueba que comprueban que
respectivamente, RandomRoomPositionAllocator y SameRoomPositionAllocator funcionan correctamente. Cada
Los casos de prueba involucran un solo edificio de sala 2x3x2 (total 12 habitaciones) en coordenadas conocidas y
respectivamente 24 y 48 nodos. Ambas pruebas comprueban que el número de nodos asignados en cada
habitación es la esperada y que la posición de los nodos también es correcta.

Edificios Camino perdido pruebas
La suite de pruebas edificios-pathloss-modelo proporciona diferentes pruebas unitarias que comparan
resultados esperados del módulo de pérdida de ruta de edificios en escenarios específicos con
valores calculados obtenidos fuera de línea con un script de octava
(prueba / referencia / edificios-pathloss.m). Las pruebas se consideran aprobadas si los dos valores
son iguales hasta una tolerancia de 0.1, que se considera apropiada para el uso típico de
valores de pérdida de trayectoria (que están en dB).

A continuación detallamos los escenarios considerados, su selección se ha realizado para
cubriendo el amplio conjunto de posibles combinaciones lógicas de pérdida de trayectoria. Los resultados de la lógica de pérdida de trayectoria
por lo tanto probado implícitamente.

Prueba #1 Okumura Hata
En esta prueba probamos el modelo estándar Okumura Hata; por lo tanto, tanto eNB como UE se colocan
exterior a una distancia de 2000 m. La frecuencia utilizada es la banda # 5 de E-UTRA, que
corresponden a 869 MHz (ver tabla 5.5-1 de 36.101). La prueba incluye también la validación
de las extensiones de áreas (es decir, urbanas, suburbanas y áreas abiertas) y del tamaño de la ciudad
(pequeño, mediano y grande).

Prueba #2 COSTE231 Modelo
Esta prueba tiene como objetivo validar el modelo COST231. La prueba es similar a la Okumura
Hata uno, excepto que la frecuencia utilizada es la banda EUTRA # 1 (2140 MHz) y que la prueba
solo se puede realizar para ciudades grandes y pequeñas en escenarios urbanos debido al modelo
limitaciones.

Prueba #3 2.6 GHz. modelo
Esta prueba valida el modelo Kun de 2.6 GHz. La prueba es similar a Okumura Hata, excepto que
que la frecuencia es la banda EUTRA # 7 (2620 MHz) y la prueba se puede realizar solo en
escenario urbano.

Prueba #4 ITU1411 LoS modelo
Esta prueba tiene como objetivo validar el modelo ITU1411 en caso de línea de visión dentro de la calle
transmisiones de cañones. En este caso el UE se sitúa a 100 metros del eNB, ya que
el umbral para cambiar entre LoS y NLoS se deja en uno predeterminado (es decir, 200 m.).

Prueba #5 ITU1411 NLoS modelo
Esta prueba tiene como objetivo validar el modelo ITU1411 en caso de falta de línea de visión sobre el
transmisiones en la azotea. En este caso la UE se sitúa a 900 metros del eNB, en
El orden para estar por encima del umbral para cambiar entre LoS y NLoS se deja en el valor predeterminado.
(es decir, 200 m.).

Prueba #6 ITUP1238 modelo
Esta prueba tiene como objetivo validar el modelo ITUP1238 en caso de transmisiones interiores. En
En este caso, tanto el UE como el eNB se colocan en un edificio residencial con paredes de
HORMIGON CON VENTANAS. Ue se ubica en el segundo piso y dista 30 metros de
el eNB, que se ubica en el primer piso.

Prueba #7 Exterior -> ¿Interior con Okumura Hata modelo
Esta prueba valida las transmisiones de exterior a interior para grandes distancias. En este caso
la UE está ubicada en un edificio residencial con muro de hormigón con ventanas y
distancias 2000 metros del eNB exterior.

Prueba #8 Exterior -> ¿Interior con ITU1411 modelo
Esta prueba valida las transmisiones de exterior a interior para distancias cortas. En este caso
la UE está ubicada en un edificio residencial con paredes de hormigón con ventanas y
distancias 100 metros del eNB exterior.

Prueba #9 ¿Interior -> Exterior con ITU1411 modelo
Esta prueba valida las transmisiones de exterior a interior para distancias muy cortas. En esto
caso de que el eNB se coloque en el segundo piso de un edificio residencial con paredes hechas de
hormigón con ventanas y distancias de 100 metros del UE exterior (es decir, LoS
comunicación). Por lo tanto, la ganancia de altura debe incluirse en la evaluación de la pérdida de trayectoria.

Prueba #10 ¿Interior -> Exterior con ITU1411 modelo
Esta prueba valida las transmisiones de exterior a interior para distancias cortas. En este caso
el eNB se coloca en el segundo piso de un edificio residencial con paredes hechas de
hormigón con ventanas y distancias de 500 metros de la UE exterior (es decir, NLoS
comunicación). Por lo tanto, la ganancia de altura debe incluirse en la evaluación de la pérdida de trayectoria.

Edificios Sombra Prueba
La suite de pruebas prueba-de-sombra-de-edificios es una prueba unitaria destinada a verificar la estadística
distribución del modelo de sombreado implementado por EdificiosPathlossModelo. La sombra
se modela de acuerdo con una distribución normal con media = 0 y estándar variable
desviación ma, según modelos comúnmente utilizados en la literatura. Tres casos de prueba son
proporcionados, que cubren los casos de comunicaciones de interior, exterior y de interior a exterior.
Cada caso de prueba genera 1000 muestras diferentes de sombreado para diferentes pares de
Instancias de MobilityModel en un escenario determinado. Los valores de sombreado se obtienen restando
del valor total de pérdida devuelto por HíbridoEdificiosPathlossModelo el componente de pérdida de ruta
que es constante y predeterminado para cada caso de prueba. La prueba verifica que la muestra
la varianza media y muestral de los valores de sombreado se encuentra dentro del intervalo de confianza del 99%
de la media muestral y la varianza muestral. La prueba también verifica que los valores de sombreado
devuelto en momentos sucesivos para el mismo par de instancias de MobilityModel es constante.

Referencias
[turkmaní]
Turkmani AMD, JD Parson y DG Lewis, "Radio propagación en edificios en
441, 900 y 1400 MHz ", en Proc. De la IV Conferencia Internacional sobre Radio Móvil Terrestre, 4.

HAZ CLICK MODULAR FRESADORA INTEGRACIÓN

Click es una arquitectura de software para construir enrutadores configurables. Utilizando diferentes
combinaciones de unidades de procesamiento de paquetes llamadas elementos, se puede hacer un enrutador Click para
realizar un tipo específico de funcionalidad. Esta flexibilidad proporciona una buena plataforma para
probando y experimentando con diferentes protocolos.

Modelo Descripción
El código fuente del modelo Click reside en el directorio src / clic.

Design
El diseño de ns-3 es adecuado para una integración con Click debido a las siguientes razones:

· Los paquetes en ns-3 se serializan / deserializan a medida que se mueven hacia arriba o hacia abajo en la pila. Esto permite
ns-3 paquetes para pasar ay desde Click como están.

· Esto también significa que cualquier tipo de transporte y generador de tráfico ns-3 debería funcionar fácilmente
encima de Click.

· Al esforzarnos por implementar click como una instancia de Ipv4RoutingProtocol, podemos evitar
cambios significativos en la capa LL y MAC del código ns-3.

El objetivo del diseño era hacer que la API pública ns-3-click sea lo suficientemente simple como para que el usuario
simplemente necesita agregar una instancia Ipv4ClickRouting al nodo e informar a cada nodo Click
del archivo de configuración Click (archivo .click) que se va a utilizar.

Este modelo implementa la interfaz para el enrutador modular Click y proporciona la
Clase Ipv4ClickRouting para permitir que un nodo use Click para enrutamiento externo. A diferencia de lo normal
Subtipos Ipv4RoutingProtocol, Ipv4ClickRouting no usa un método RouteInput (), pero
en su lugar, recibe un paquete en la interfaz adecuada y lo procesa en consecuencia. Nota
que necesita tener un elemento de tipo de tabla de enrutamiento en su gráfico Click para usar Click for
enrutamiento externo. Esto es necesario para la función RouteOutput () heredada de
Ipv4RoutingProtocol. Además, un nodo basado en Click usa un tipo diferente de L3 en el
forma de Ipv4L3ClickProtocol, que es una versión reducida de Ipv4L3Protocol.
Ipv4L3ClickProtocol pasa los paquetes que pasan a través de la pila a Ipv4ClickRouting para
procesar.

Desarrollo a Simulador API a permitir ns-3 a interactuar con Hagan clic
Gran parte de la API ya está bien definida, lo que permite a Click buscar información de
el simulador (como una ID de nodo, una ID de interfaz, etc.). Al retener la mayor parte de
métodos, debería ser posible escribir nuevas implementaciones específicas de ns-3 para el mismo
funcionalidad

Por lo tanto, para la integración de Click con ns-3, una clase llamada Ipv4ClickRouting manejará el
interacción con Click. El código para el mismo se puede encontrar en
src / click / model / ipv4-click-routing. {cc, h}.

Paquete mano off entre ns-3 y Hagan clic
Hay cuatro tipos de transferencias de paquetes que pueden ocurrir entre ns-3 y Click.

· L4 a L3

· L3 a L4

· L3 a L2

· L2 a L3

Para superar esto, implementamos Ipv4L3ClickProtocol, una versión simplificada de
Ipv4L3Protocol. Ipv4L3ClickProtocol pasa paquetes hacia y desde Ipv4ClickRouting
apropiadamente para realizar el enrutamiento.

<b></b><b></b> y Limitaciones
· En su estado actual, la Integración de clic NS-3 está limitada para usar solo con L3, dejando
NS-3 para manejar L2. Actualmente también estamos trabajando para agregar compatibilidad con Click MAC. Ver el
sección de uso para asegurarse de diseñar sus gráficos de clics en consecuencia.

· Además, ns-3-click funcionará solo con elementos de nivel de usuario. La lista completa de
los elementos están disponibles en http://read.cs.ucla.edu/click/elements. Elementos que tienen
Se pueden usar 'all', 'userlevel' o 'ns' mencionados al lado de ellos.

· A partir de ahora, la interfaz ns-3 para Click es solo Ipv4. Agregaremos soporte Ipv6 en
el futuro.

Referencias
· Eddie Kohler, Robert Morris, Benjie Chen, John Jannotti y M. Frans Kaashoek. los
haga clic en enrutador modular. Transacciones ACM en sistemas informáticos 18(3), agosto de 2000, páginas
263-297.

· Lalith Suresh P. y Ruben Merz. Ns-3-click: haga clic en integración de enrutador modular para ns-3.
En Proc. del 3er Taller Internacional ICST sobre NS-3 (WNS3), Barcelona, ​​España. Marcha,
2011.

· Michael Neufeld, Ashish Jain y Dirk Grunwald. Nsclick: simulación de red puente
y despliegue. MSWiM '02: Actas del quinto taller internacional de ACM sobre modelado
análisis y simulación de sistemas inalámbricos y móviles, 2002, Atlanta, Georgia, EE. UU.
http://doi.acm.org/10.1145/570758.570772

Uso
Contruyendo Hagan clic
El primer paso es clonar Click del repositorio de github y compilarlo:

$ git clon https://github.com/kohler/click
$ cd haga clic en /
$ ./configure --disable-linuxmodule --enable-nsclick --enable-wifi
$ make

La marca --enable-wifi se puede omitir si no tiene la intención de usar Click con Wifi. *
Nota: No es necesario realizar una instalación automática.

Una vez que Click se haya construido correctamente, cambie al directorio ns-3 y configure ns-3
con soporte Click Integration:

$ ./waf configure --enable-examples --enable-tests --with-nsclick = / ruta / a / clic / fuente

Sugerencia: si ha hecho clic en instalar un directorio por encima de ns-3 (como en el ns-3-allinone
directorio), y el nombre del directorio es 'clic' (o un enlace simbólico al directorio
se llama 'clic'), entonces el especificador --with-nsclick no es necesario; la construcción ns-3
el sistema encontrará correctamente el directorio.

Si dice 'habilitado' al lado de 'Soporte de integración de NS-3 Click', entonces está listo para comenzar.
Nota: Si ejecuta modular ns-3, el conjunto mínimo de módulos necesarios para ejecutar todos los ns-3-click
ejemplos son wifi, csma y config-store.

A continuación, intente ejecutar uno de los ejemplos:

$ ./waf --ejecutar nsclick-simple-lan

A continuación, puede ver las trazas .pcap resultantes, que se denominan nsclick-simple-lan-0-0.pcap
y nsclick-simple-lan-0-1.pcap.

Hagan clic Gráfico Instrucciones
Se debe tener en cuenta lo siguiente al hacer su gráfico de clics:

· Solo se pueden utilizar elementos de nivel de usuario.

· Deberá reemplazar los elementos FromDevice y ToDevice con FromSimDevice y
Elementos ToSimDevice.

· Los paquetes al kernel se envían usando ToSimDevice (tap0, IP).

· Para cualquier nodo, el dispositivo que envía / recibe paquetes hacia / desde el kernel, se llama
'tap0'. Las interfaces restantes deben llamarse eth0, eth1 y así sucesivamente (incluso si está
usando wifi). Tenga en cuenta que la numeración del dispositivo debe comenzar desde 0. En el futuro, este
será flexible para que los usuarios puedan nombrar los dispositivos en su archivo Click como deseen.

· Un elemento de la tabla de enrutamiento es obligatorio. Los puertos OUT del elemento de la tabla de enrutamiento deben
corresponder al nmero de interfaz del dispositivo a travs del cual el paquete
finalmente ser enviado. La violación de esta regla dará lugar a rastreos de paquetes realmente extraños.
El nombre de este elemento de la tabla de enrutamiento debe pasarse al protocolo Ipv4ClickRouting
objeto como parámetro de simulación. Consulte los ejemplos de Click para obtener más detalles.

· La implementación actual deja a Click con funcionalidad principalmente L3, con manejo ns-3
L2. Pronto comenzaremos a trabajar para admitir el uso de protocolos MAC en Click también.
Esto significa que a partir de ahora, los elementos específicos de Wifi de Click no se pueden usar con ns-3.

Depuración Paquete Flujos Desde Hagan clic
Desde cualquier punto dentro de un gráfico de clic, puede utilizar Imprimir (-
http://read.cs.ucla.edu/click/elements/print) elemento y sus variantes para una impresión bonita
del contenido del paquete. Además, puede generar trazas pcap de paquetes que fluyen a través de un
Haga clic en el gráfico utilizando ToDump (http://read.cs.ucla.edu/click/elements/todump) elemento como
bien. Por ejemplo:

miarpquerier
-> Imprimir (fromarpquery, 64)
-> ToDump (out_arpquery, PER_NODE 1)
-> ethout;

y ... imprimirá el contenido de los paquetes que fluyen fuera del ArpQuerier, luego generará un
archivo de seguimiento pcap que tendrá un sufijo 'out_arpquery', para cada nodo usando el clic
file, antes de enviar los paquetes a 'ethout'.

Ayudante
Para que un nodo ejecute Click, la forma más sencilla sería utilizar ClickInternetStackHelper
class en su guión de simulación. Por ejemplo:

ClickInternetStackHelper clic;
click.SetClickFile (myNodeContainer, "nsclick-simple-lan.click");
click.SetRoutingTableElement (myNodeContainer, "u / rt");
haga clic.Instalar (myNodeContainer);

Los scripts de ejemplo dentro src / click / examples / demostrar el uso de nodos basados ​​en Click en
diferentes escenarios. La fuente de ayuda se puede encontrar dentro
src / click / helper / click-internet-stack-helper. {h, cc}

Ejemplos
Se han escrito los siguientes ejemplos, que se pueden encontrar en src / click / examples /:

· Nsclick-simple-lan.cc y nsclick-raw-wlan.cc: un nodo basado en clic que se comunica con un
Nodo ns-3 normal sin Click, usando Csma y Wifi respectivamente. También demuestra
el uso de TCP en la parte superior de Click, algo que la implementación original de nsclick para
NS-2 no pudo lograrlo.

· Nsclick-udp-client-server-csma.cc y nsclick-udp-client-server-wifi.cc: Una LAN de 3 nodos
(Csma y Wifi respectivamente) donde los nodos basados ​​en 2 clics ejecutan un cliente UDP, que envía
paquetes a un tercer nodo basado en Click que ejecuta un servidor UDP.

· Nsclick-routing.cc: el nodo basado en un clic se comunica con otro a través de un tercer nodo que
actúa como un enrutador de IP (utilizando la configuración de clic de enrutador de IP). Esto demuestra
enrutamiento mediante Click.

Los scripts están disponibles en / conf / que le permiten generar archivos Click para
algunos escenarios comunes. El enrutador IP utilizado en nsclick-enrutamiento.cc fue generado a partir de la
make-ip-conf.pl y ligeramente adaptado para trabajar con ns-3-click.

Validación
Este modelo ha sido probado de la siguiente manera:

· Se han escrito pruebas unitarias para verificar el funcionamiento interno de Ipv4ClickRouting. Esto puede ser
encontrado en src / click / ipv4-click-routing-test.cc. Estas pruebas verifican si los métodos
dentro de Ipv4ClickRouting que se ocupa del nombre del dispositivo a la identificación, la dirección IP del nombre del dispositivo
y la dirección Mac de los enlaces de nombre de dispositivo funcionan como se esperaba.

· Los ejemplos se han utilizado para probar Click con escenarios de simulación reales. Estos pueden ser
encontrado en src / click / examples /. Estas pruebas cubren lo siguiente: el uso de diferentes
tipos de transportes en la parte superior de Click, TCP / UDP, si los nodos Click pueden comunicarse con
nodos no basados ​​en Click, si los nodos Click pueden comunicarse entre sí, usando Click
para enrutar paquetes usando enrutamiento estático.

· Click ha sido probado con dispositivos Csma, Wifi y Point-to-Point. Las instrucciones de uso son
disponible en la sección anterior.

CSMA DISPOSITIVO DE RED

Esta es la introducción al capítulo CSMA NetDevice, para complementar el modelo Csma doxygen.

Descripción General of los CSMA modelo
La ns-3 El dispositivo CSMA modela una red de bus simple en el espíritu de Ethernet. A pesar de esto
no modela ninguna red física real que pueda construir o comprar, proporciona algunos
funcionalidad muy útil.

Normalmente, cuando uno piensa en una red de bus, viene a la mente Ethernet o IEEE 802.3. Ethernet
utiliza CSMA / CD (Carrier Sense Multiple Access con Collision Detection con exponencial
aumento del retroceso para competir por el medio de transmisión compartido. El ns-3 Dispositivo CSMA
modela solo una parte de este proceso, utilizando la naturaleza del canal disponible globalmente
para proporcionar un sentido de portador instantáneo (más rápido que la luz) y una colisión basada en prioridades
"evitación." Las colisiones en el sentido de Ethernet nunca ocurren, por lo que ns-3 Dispositivo CSMA
no modela la detección de colisiones, ni ninguna transmisión en curso será "bloqueada".

CSMA Capa Modelo
Hay una serie de convenciones en uso para describir las comunicaciones en capas.
arquitecturas en la literatura y en los libros de texto. El modelo de capas más común es el
Modelo de referencia ISO de siete capas. En esta vista, el par CsmaNetDevice y CsmaChannel
ocupa las dos capas más bajas: en la física (capa uno) y en el enlace de datos (capa dos)
posiciones. Otro modelo de referencia importante es el especificado por RFC 1122, "Requisitos
para hosts de Internet: capas de comunicación ". En esta vista, el dispositivo CsmaNet y
El par CsmaChannel ocupa la capa más baja: la capa de enlace. También hay una aparentemente
interminable letanía de descripciones alternativas que se encuentran en los libros de texto y en la literatura. Nosotros
adoptar las convenciones de nomenclatura utilizadas en los estándares IEEE 802 que hablan de LLC, MAC, MII
y estratificación PHY. Estos acrónimos se definen como:

· LLC: Control de enlace lógico;

· MAC: Control de acceso a medios;

· MII: Interfaz independiente de medios;

· PHY: Capa física.

En este caso el S.A (LLC) y dirección MAC son subcapas de la capa de enlace de datos OSI y la MII y PHY
son subcapas de la capa física OSI.

La "parte superior" del dispositivo CSMA define la transición de la capa de red a los datos
capa de enlace. Esta transición es realizada por capas superiores llamando a
CsmaNetDevice :: Send o CsmaNetDevice :: SendFrom.

A diferencia de los estándares IEEE 802.3, no hay una PHY especificada con precisión en el CSMA
modelo en el sentido de tipos de cables, señales o pines. La interfaz "inferior" del
CsmaNetDevice se puede considerar como una especie de interfaz independiente de medios (MII) como se ve
en las especificaciones "Fast Ethernet" (IEEE 802.3u). Esta interfaz MII encaja en un
correspondiente interfaz independiente de medios en el CsmaChannel. No encontraras el
equivalente a 10BASE-T o 1000BASE-LX PHY.

El CsmaNetDevice llama al CsmaChannel a través de una interfaz independiente de los medios. Hay un
método definido para decirle al canal cuándo comenzar a "mover los cables" usando el método
CsmaChannel :: TransmitStart, y un método para decirle al canal cuando el proceso de transmisión
está hecho y el canal debería comenzar a propagar el último bit a través del "cable":
CsmaChannel :: TransmitEnd.

Cuando se ejecuta el método TransmitEnd, el canal modelará una única señal uniforme
retardo de propagación en el medio y entregar copes del paquete a cada uno de los dispositivos
adjunto al paquete a través del método CsmaNetDevice :: Receive.

Hay un "pin" en la interfaz independiente del medio del dispositivo correspondiente a "COL"
(colisión). El estado del canal se puede detectar llamando a CsmaChannel :: GetState. Cada
El dispositivo mirará este "pin" antes de iniciar un envío y realizará una retirada adecuada.
operaciones si es necesario.

Los paquetes recibidos correctamente se reenvían a niveles más altos desde el CsmaNetDevice a través de un
mecanismo de devolución de llamada. La función de devolución de llamada es inicializada por la capa superior (cuando la red
dispositivo está conectado) usando CsmaNetDevice :: SetReceiveCallback y se invoca en "apropiado"
recepción de un paquete por el dispositivo de red para reenviar el paquete por el protocolo
asociación.

CSMA Channel Modelo
La clase CsmaChannel modela el medio de transmisión real. No hay un límite fijo para
el número de dispositivos conectados al canal. El CsmaChannel modela una velocidad de datos y un
retardo de la velocidad de la luz al que se puede acceder a través de los atributos "DataRate" y "Delay"
respectivamente. La velocidad de datos proporcionada al canal se utiliza para establecer las velocidades de datos utilizadas por
las secciones del transmisor de los dispositivos CSMA conectados al canal. No hay manera de
establecer de forma independiente las velocidades de datos en los dispositivos. Dado que la velocidad de datos solo se usa para calcular
un tiempo de retardo, no hay limitación (excepto por el tipo de datos que contiene el valor) en
la velocidad a la que pueden operar los canales y dispositivos CSMA; y sin restricciones basadas en ningún
tipo de características PHY.

El CsmaChannel tiene tres estados, OCIOSO, TRANSMISIÓN y PROPAGADOR. Estos tres estados
son "vistos" instantáneamente por todos los dispositivos del canal. Con esto queremos decir que si uno
dispositivo comienza o finaliza una transmisión simulada, todos los dispositivos en el canal son inmediatamente
consciente del cambio de estado. No hay tiempo durante el cual un dispositivo pueda ver un OCIOSO
canal mientras que otro dispositivo físicamente más alejado en el dominio de colisión puede tener
comenzó a transmitir con las señales asociadas no propagadas por el canal a otros
dispositivos. Por lo tanto, no hay necesidad de detección de colisiones en el modelo CsmaChannel y es
no implementado de ninguna manera.

Como su nombre indica, tenemos un aspecto Carrier Sense en el modelo. Desde el
El simulador es de un solo subproceso, el acceso al canal común será serializado por el
simulador. Esto proporciona un mecanismo determinista para competir por el canal. El
el canal está asignado (en transición del estado OCIOSO a estado TRANSMISIÓN) por orden de llegada
primero servido. El canal siempre pasa por un proceso de tres estados:

INACTIVO -> TRANSMITIENDO -> PROPAGANDO -> INACTIVO

La TRANSMISIÓN modelos de estado el tiempo durante el cual el dispositivo de red de origen está realmente
moviendo las señales en el cable. El PROPAGADOR modelos de estado el tiempo después del último bit
se envió, cuando la señal se propaga por el cable hasta el "extremo lejano".

La transición al TRANSMISIÓN El estado es impulsado por una llamada a
CsmaChannel :: TransmitStart que es llamado por el dispositivo de red que transmite el paquete. Eso
Es responsabilidad de ese dispositivo finalizar la transmisión con una llamada a
CsmaChannel :: TransmitEnd en el tiempo de simulación apropiado que refleja el tiempo transcurrido
para poner todos los bits del paquete en el cable. Cuando se llama a TransmitEnd, el canal
programa un evento correspondiente a un solo retraso de la velocidad de la luz. Este retraso se aplica a
todos los dispositivos de red en el canal de forma idéntica. Puede pensar en un eje simétrico en el que
los bits del paquete se propagan a una ubicación central y luego retroceden cables de igual longitud para
los otros dispositivos del canal. El único retraso de la "velocidad de la luz" corresponde a
el tiempo que tarda: 1) una señal en propagarse desde un CsmaNetDevice a través de su cable
al centro; más 2) el tiempo que tarda el concentrador en reenviar el paquete a un puerto; más
3) el tiempo que tarda la señal en cuestión en propagarse a la red de destino
.

El CsmaChannel modela un medio de transmisión para que el paquete se entregue a todos los dispositivos.
en el canal (incluida la fuente) al final del tiempo de propagación. Es el
responsabilidad del dispositivo emisor de determinar si recibe o no un paquete
transmitido por el canal.

El CsmaChannel proporciona los siguientes atributos:

· DataRate: la tasa de bits para la transmisión de paquetes en los dispositivos conectados;

· Retraso: la velocidad del retraso de transmisión de la luz para el canal.

CSMA Red Device Modelo
El dispositivo de red CSMA parece algo así como un dispositivo Ethernet. El CsmaNetDevice
proporciona los siguientes atributos:

· Dirección: Mac48Address del dispositivo;

· SendEnable: habilita la transmisión de paquetes si es verdadero;

· ReceiveEnable: habilita la recepción de paquetes si es verdadero;

· EncapsulationMode: tipo de encapsulación de la capa de enlace que se utilizará;

· RxErrorModel: el modelo de error de recepción;

· TxQueue: la cola de transmisión utilizada por el dispositivo;

· InterframeGap: el tiempo opcional de espera entre "fotogramas";

· Rx: una fuente de rastreo para los paquetes recibidos;

· Descartar: una fuente de rastreo para paquetes descartados.

El CsmaNetDevice admite la asignación de un "modelo de error de recepción". Esto es un
Objeto ErrorModel que se utiliza para simular la corrupción de datos en el enlace.

Los paquetes enviados a través de CsmaNetDevice siempre se enrutan a través de la cola de transmisión a
proporcionar un enlace de seguimiento para los paquetes enviados a través de la red. Esta cola de transmisión se puede configurar
(a través de atributo) para modelar diferentes estrategias de cola.

También se puede configurar por atributo el método de encapsulación utilizado por el dispositivo. Cada
El paquete obtiene un EthernetHeader que incluye las direcciones MAC de origen y destino, y
un campo de longitud / tipo. Cada paquete también recibe un EthernetTrailer que incluye el FCS.
Los datos del paquete pueden encapsularse de diferentes formas.

De forma predeterminada, o estableciendo el atributo "EncapsulationMode" en "Dix", la encapsulación es
según el estándar DEC, Intel, Xerox. Esto a veces se denomina entramado EthernetII.
y es el conocido formato MAC de destino, MAC de origen, EtherType, Datos, CRC.

Si el atributo "EncapsulationMode" se establece en "Llc", la encapsulación se realiza mediante LLC SNAP. En
En este caso, se agrega un encabezado SNAP que contiene el EtherType (IP o ARP).

Los otros modos de encapsulación implementados son IP_ARP (establezca "EncapsulationMode" en "IpArp")
en el que el tipo de longitud del encabezado Ethernet recibe el número de protocolo del
paquete; o ETHERNET_V1 (establezca "EncapsulationMode" en "EthernetV1") en el que el tipo de longitud
del encabezado Ethernet recibe la longitud del paquete. Un modo de encapsulación "Raw" es
definido pero no implementado: el uso del modo RAW da como resultado una afirmación.

Tenga en cuenta que todos los dispositivos de red en un canal deben configurarse en el mismo modo de encapsulación para
resultados correctos. El modo de encapsulación no se detecta en el receptor.

El CsmaNetDevice implementa un algoritmo de retroceso exponencial aleatorio que se ejecuta si
se determina que el canal está ocupado (TRANSMISIÓN or PPROPAGANDO) cuando el dispositivo quiere
para comenzar a propagarse. Esto da como resultado un retraso aleatorio de hasta pow (2, reintentos) - 1
microsegundos antes de intentar un reintento. El número máximo predeterminado de reintentos es 1000.

Usando los Dispositivo CsmaNet
Los canales y dispositivos de la red CSMA se crean y configuran normalmente mediante el
asociado CsmaHelper objeto. Los diversos ns-3 los ayudantes de dispositivo generalmente funcionan de manera similar
manera, y su uso se ve en muchos de nuestros programas de ejemplo.

El modelo conceptual de interés es el de una "cáscara" de computadora desnuda en la que se conecta una red
dispositivos. Las computadoras desnudas se crean usando un Contenedor de nodo ayudante. Solo pregunta esto
ayudante para crear tantas computadoras (las llamamos Nodes) según lo necesite en su red:

NodoContenedor csmaNodes;
csmaNodes.Crear (nCsmaNodes);

Una vez que tenga sus nodos, debe crear una instancia CsmaHelper y establezca los atributos que desee
puede querer cambiar .:

CsmaHelper csma;
csma.SetChannelAttribute ("DataRate", StringValue ("100Mbps"));
csma.SetChannelAttribute ("Retraso", TimeValue (NanoSeconds (6560)));

csma.SetDeviceAttribute ("EncapsulationMode", StringValue ("Dix"));
csma.SetDeviceAttribute ("Tamaño de marco", UintegerValue (2000));

Una vez que se establecen los atributos, todo lo que queda es crear los dispositivos e instalarlos en
los nodos necesarios y para conectar los dispositivos entre sí mediante un canal CSMA. Cuando nosotros
creamos los dispositivos de red, los agregamos a un contenedor para que pueda usarlos en el futuro.
Todo esto toma solo una línea de código:

NetDeviceContainer csmaDevices = csma.Install (csmaNodes);

Recomendamos pensar detenidamente sobre cambiar estos Atributos, ya que puede resultar en
comportamiento que sorprende a los usuarios. Permitimos esto porque creemos que la flexibilidad es importante.
Como ejemplo de un efecto posiblemente sorprendente de cambiar Atributos, considérese el
siguientes:

El atributo Mtu indica la unidad de transmisión máxima al dispositivo. Este es el tamaño
de la unidad de datos de protocolo (PDU) más grande que el dispositivo puede enviar. Este atributo está predeterminado
a 1500 bytes y corresponde a un número que se encuentra en RFC 894, "Un estándar para el
Transmisión de datagramas IP a través de redes Ethernet. "El número en realidad se deriva de
el tamaño máximo de paquete para redes 10Base5 (Ethernet de especificación completa): 1518 bytes. Si tu
reste la sobrecarga de encapsulación DIX para los paquetes Ethernet (18 bytes), terminará con una
tamaño de datos máximo posible (MTU) de 1500 bytes. También se puede encontrar que el MTU para IEEE
Las redes 802.3 son 1492 bytes. Esto se debe a que la encapsulación LLC / SNAP agrega ocho
bytes de sobrecarga al paquete. En ambos casos, el hardware de red subyacente es
limitado a 1518 bytes, pero la MTU es diferente porque la encapsulación es diferente.

Si uno deja el atributo Mtu en 1500 bytes y cambia el atributo del modo de encapsulación
a Llc, el resultado será una red que encapsula PDU de 1500 bytes con LLC / SNAP
trama que da como resultado paquetes de 1526 bytes. Esto sería ilegal en muchas redes, pero
le permitimos hacer esto. Esto da como resultado una simulación que sutilmente no refleja
lo que podría esperar, ya que un dispositivo real se resistiría a enviar un paquete de 1526 bytes.

También existen tramas jumbo (1500 <MTU <= 9000 bytes) y super-jumbo (MTU> 9000
bytes) tramas que no están aprobadas oficialmente por IEEE pero que están disponibles en algunos
NIC y redes de alta velocidad (Gigabit). En el modelo CSMA, uno podría dejar el
modo de encapsulación establecido en Dix, y establezca el Mtu en 64000 bytes, aunque un asociado
CsmaChannel DataRate se dejó en 10 megabits por segundo (ciertamente no Gigabit Ethernet).
Básicamente, esto modelaría un conmutador Ethernet hecho de estilo de la década de 1980 con toma de vampiros
Redes 10Base5 que admiten datagramas superjumbo, que ciertamente no es algo que
nunca se hizo, ni es probable que se haga; sin embargo, es bastante fácil para ti
configurar.

Tenga cuidado con las suposiciones sobre lo que CSMA está realmente modelando y cómo
La configuración (Atributos) puede permitirle desviarse considerablemente de la realidad.

CSMA Rastreo
Al igual que todos ns-3 dispositivos, el modelo CSMA proporciona una serie de fuentes de seguimiento. Estos rastros
las fuentes se pueden enganchar usando su propio código de seguimiento personalizado, o puede usar nuestro ayudante
funciones para organizar la habilitación del rastreo en los dispositivos que especifique.

Nivel superior (MAC) Manos
Desde el punto de vista del rastreo en el dispositivo de red, hay varios puntos interesantes
para insertar ganchos de rastreo. Una convención heredada de otros simuladores es que los paquetes
destinados a la transmisión en redes adjuntas pasan a través de una única "cola de transmisión" en
el dispositivo de red. Proporcionamos enlaces de seguimiento en este punto del flujo de paquetes, que corresponde
(en abstracto) solo a una transición de la red a la capa de enlace de datos, y llámelos
colectivamente, el dispositivo MAC se engancha.

Cuando se envía un paquete al dispositivo de red CSMA para su transmisión, siempre pasa a través del
cola de transmisión. La cola de transmisión en CsmaNetDevice hereda de Queue y, por lo tanto,
hereda tres orígenes de seguimiento:

· Una fuente de operación Enqueue (ver Queue :: m_traceEnqueue);

· Una fuente de operación Dequeue (ver Queue :: m_traceDequeue);

· Una fuente de operación Drop (ver Queue :: m_traceDrop).

Los ganchos de seguimiento de nivel superior (MAC) para CsmaNetDevice son, de hecho, exactamente estos tres
rastrear fuentes en la única cola de transmisión del dispositivo.

El evento m_traceEnqueue se activa cuando un paquete se coloca en la cola de transmisión. Esta
ocurre en el momento en que CsmaNetDevice :: Send o CsmaNetDevice :: SendFrom es llamado por un
capa superior para poner en cola un paquete para su transmisión.

El evento m_traceDequeue se activa cuando se elimina un paquete de la cola de transmisión.
Las retiradas de la cola de transmisión pueden ocurrir en tres situaciones: 1) Si el
el canal está inactivo cuando se llama a CsmaNetDevice :: Send o CsmaNetDevice :: SendFrom, un
el paquete se quita de la cola de transmisión y se transmite inmediatamente; 2) Si el
El canal subyacente está inactivo, un paquete puede retirarse de la cola y transmitirse inmediatamente en un
TransmitCompleteEvent interno que funciona como una interrupción completa de transmisión
rutina de servicio; o 3) del controlador de retroceso exponencial aleatorio si se agota el tiempo de espera
detectado.

El caso (3) implica que un paquete se quita de la cola de transmisión si no puede ser
transmitido de acuerdo con las reglas de retroceso. Es importante comprender que esto
aparecen como un paquete retirado de la cola y es fácil suponer incorrectamente que el paquete fue
transmitido desde que pasó por la cola de transmisión. De hecho, un paquete es en realidad
dejado caer por el dispositivo de red en este caso. La razón de este comportamiento se debe a la
definición del evento Queue Drop. El evento m_traceDrop es, por definición, disparado cuando un
el paquete no se puede poner en cola en la cola de transmisión porque está lleno. Este evento solo dispara
si la cola está llena y no sobrecargamos este evento para indicar que el CsmaChannel está
"completo."

Nivel inferior (FÍSICO) Manos
Similar a los ganchos de rastreo de nivel superior, hay ganchos de rastreo disponibles en la parte inferior.
niveles del dispositivo de red. A estos los llamamos los ganchos PHY. Estos eventos se disparan desde el dispositivo
métodos que se comunican directamente con CsmaChannel.

Se llama al origen de seguimiento m_dropTrace para indicar un paquete que se descarta por el dispositivo.
Esto sucede en dos casos: primero, si el lado de recepción del dispositivo de red no está habilitado
(consulte CsmaNetDevice :: m_receiveEnable y el atributo asociado "ReceiveEnable").

M_dropTrace también se utiliza para indicar que un paquete se descartó como corrupto si
Se utiliza el modelo de error de recepción (consulte CsmaNetDevice :: m_receiveErrorModel y el modelo asociado
atributo "ReceiveErrorModel").

La otra fuente de rastreo de bajo nivel se activa al recibir un paquete aceptado (consulte
CsmaNetDevice :: m_rxTrace). Se acepta un paquete si está destinado a la transmisión
dirección, una dirección de multidifusión o la dirección MAC asignada al dispositivo de red.

Resumen
El modelo CSMA ns3 es un modelo simplista de una red similar a Ethernet. Es compatible con un
Función Carrier-Sense y permite el acceso múltiple a un medio compartido. No lo es
físico en el sentido de que el estado del medio se comparte instantáneamente entre todos
dispositivos. Esto significa que no se requiere detección de colisiones en este modelo y ninguna
está implementado. Nunca habrá un "atasco" de un paquete que ya esté en el medio. El acceso a los
el canal compartido se asigna por orden de llegada según lo determine el simulador
planificador. Si se determina que el canal está ocupado al observar el estado global, un
Se realiza un retroceso exponencial aleatorio y se intenta un reintento.

Los atributos Ns-3 proporcionan un mecanismo para configurar varios parámetros en el dispositivo y
canal como direcciones, modos de encapsulación y selección del modelo de error. Los ganchos de seguimiento son
provisto de la manera habitual con un conjunto de ganchos de nivel superior correspondientes a un transmisor
cola y utilizado en rastreo ASCII; y también un conjunto de ganchos de nivel inferior utilizados en el rastreo de pcap.

Aunque el ns-3 CsmaChannel y CsmaNetDevice no modelan ningún tipo de red,
podría construir o comprar, nos proporciona algunas funciones útiles. Debería,
sin embargo, comprenda que explícitamente no es Ethernet o cualquier tipo de IEEE 802.3, sino un
subconjunto interesante.

DATOS COLLECTION

Este capítulo describe el marco de recopilación de datos ns-3 (DCF), que proporciona
capacidades para obtener datos generados por modelos en el simulador, para realizar en línea
reducción y procesamiento de datos, y para ordenar datos sin procesar o transformados en varios resultados
formatos.

El marco actualmente admite ejecuciones independientes de ns-3 que no dependen de ningún
control de ejecución del programa. Los objetos proporcionados por el DCF pueden engancharse a ns-3 rastrear
fuentes para permitir el procesamiento de datos.

El código fuente de las clases vive en el directorio. src / stats.

Este capítulo está organizado de la siguiente forma. Primero, se ofrece una descripción general de la arquitectura.
presentado. A continuación, se presentan los ayudantes para estas clases; este tratamiento inicial
debería permitir el uso básico del marco de recopilación de datos para muchos casos de uso. Usuarios que
desean producir resultados fuera del alcance de los ayudantes actuales, o que desean crear
sus propios objetos de recopilación de datos, debe leer el resto del capítulo, que va
en detalle sobre todos los tipos de objetos DCF básicos y proporciona codificación de bajo nivel
ejemplos.

Design
El DCF consta de tres clases básicas:

· Muestra es un mecanismo para instrumentar y controlar la salida de datos de simulación que se
utilizado para monitorear eventos interesantes. Produce resultados en forma de uno o más ns-3
rastrear fuentes. Los objetos de la sonda están conectados a una o más trazas sumideros (Llamado
Colectores), que procesan muestras en línea y las preparan para su salida.

· Coleccionista consume los datos generados por uno o más objetos Probe. Realiza
transformaciones en los datos, como la normalización, la reducción y el cálculo de
estadísticas básicas. Los objetos recopiladores no producen datos directamente
ejecución ns-3; en su lugar, generan datos en sentido descendente a otro tipo de objeto, llamado
Aggregator, que realiza esa función. Normalmente, los recopiladores generan sus datos en
también en forma de fuentes de trazas, lo que permite encadenar a los recolectores en serie.

· Aggregator es el punto final de los datos recopilados por una red de sondas y recopiladores.
La principal responsabilidad del Agregador es reunir los datos y sus correspondientes
metadatos, en diferentes formatos de salida, como archivos de texto sin formato, archivos de hoja de cálculo o
bases de datos.

Las tres clases proporcionan la capacidad de activarse o desactivarse dinámicamente.
a lo largo de una simulación.

Cualquiera independiente ns-3 La ejecución de simulación que utiliza el DCF normalmente creará al menos una
instancia de cada una de las tres clases anteriores.
[imagen] Descripción general del marco de recopilación de datos.

El flujo general del procesamiento de datos se describe en Data Colecciones Marco conceptual visión de conjunto.
En el lado izquierdo, una carrera ns-3 Se representa la simulación. En el curso de la ejecución del
simulación, los datos se ponen a disposición mediante modelos a través de fuentes de seguimiento o por otros medios.
El diagrama muestra que las sondas se pueden conectar a estas fuentes de rastreo para recibir datos
asincrónicamente, o las sondas pueden sondear datos. Luego, los datos se pasan a un objeto recopilador
que transforma los datos. Finalmente, se puede conectar un agregador a las salidas del
colector, para generar parcelas, archivos o bases de datos.
[imagen] Agregación del marco de recopilación de datos.UNINDENT

Se proporciona una variación de la figura anterior en Data Colecciones Marco conceptual agregación.
Esta segunda figura ilustra que los objetos DCF se pueden encadenar juntos de una manera
que los objetos aguas abajo toman entradas de múltiples objetos aguas arriba. La figura
muestra conceptualmente que múltiples sondas pueden generar una salida que se alimenta a un solo
coleccionista; como ejemplo, un colector que genera una relación de dos contadores
normalmente adquieren los datos de cada contador de sondas independientes. Múltiples recolectores también pueden
alimentar a un solo agregador, que (como su nombre lo indica) puede recopilar una serie de datos
corrientes para su inclusión en una única parcela, archivo o base de datos.

Data Colecciones Ayudantes
La plena flexibilidad del marco de recopilación de datos es proporcionada por la interconexión
de sondas, colectores y agregadores. Realizar todas estas interconexiones conduce a
muchas declaraciones de configuración en programas de usuario. Para facilitar su uso, algunos de los más comunes
las operaciones se pueden combinar y encapsular en funciones auxiliares. Además, algunos
declaraciones que involucran ns-3 las fuentes de seguimiento no tienen enlaces de Python, debido a limitaciones en
las fijaciones.

Data Colecciones Ayudantes Descripción General
En esta sección, proporcionamos una descripción general de algunas clases auxiliares que se han creado para
Facilitar la configuración del marco de recopilación de datos para algunos casos de uso comunes. El
Los ayudantes permiten a los usuarios formar operaciones comunes con solo unas pocas declaraciones en su C ++ o
Programas de Python. Pero esta facilidad de uso tiene el costo de una cantidad significativamente menor
flexibilidad que la configuración de bajo nivel puede proporcionar, y la necesidad de codificar explícitamente
compatibilidad con nuevos tipos de sonda en los ayudantes (para solucionar un problema que se describe a continuación).

El énfasis en los ayudantes actuales es reunir datos de ns-3 rastrear fuentes en
gráficos de gnuplot o archivos de texto, sin un alto grado de personalización de salida o estadísticos
procesamiento (inicialmente). Además, el uso está restringido a los tipos de sonda disponibles en
ns-3. Las secciones posteriores de esta documentación entrarán en más detalles sobre la creación de nuevos
Tipos de sondas, así como detalles sobre cómo conectar sondas, recopiladores y agregadores
en arreglos personalizados.

Hasta la fecha, se han implementado dos ayudantes de recopilación de datos:

· Ayudante de Gnuplot

· Ayudante de archivos

Ayudante de Gnuplot
GnuplotHelper es una clase auxiliar para producir archivos de salida que se utilizan para hacer gnuplots. El
El objetivo general es proporcionar a los usuarios la capacidad de realizar rápidamente gráficos a partir de los datos exportados.
in ns-3 rastrear fuentes. De forma predeterminada, se realiza una cantidad mínima de transformación de datos;
El objetivo es generar gráficos con tan pocas declaraciones de configuración (predeterminadas) como
posible.

Ayudante de Gnuplot Descripción General
GnuplotHelper creará 3 archivos diferentes al final de la simulación:

· Un archivo de datos gnuplot separado por espacios

· Un archivo de control de gnuplot

· Un script de shell para generar el gnuplot

Hay dos declaraciones de configuración que se necesitan para producir gráficos. La primera
declaración configura la trama (nombre de archivo, título, leyendas y tipo de salida, donde la salida
el tipo predeterminado es PNG si no se especifica):

ConfigurePlot vacío (const std :: string & outputFileNameWithoutExtension,
const std :: cadena y título,
const std :: string & xLegend,
const std :: string & yLegend,
const std :: string & terminalType = ".png");

La segunda declaración engancha la fuente de seguimiento de interés:

vacío PlotProbe (const std :: string & typeId,
const std :: cadena y ruta,
const std :: string & probeTraceSource,
const std :: string & title);

Los argumentos son los siguientes:

· TypeId: El ns-3 TypeId de la sonda

· Camino: El camino en el ns-3 espacio de nombres de configuración a una o más fuentes de seguimiento

· ProbeTraceSource: qué salida de la sonda (en sí misma una fuente de rastreo) debe trazarse

· Título: el título que se asociará con el (los) conjunto (s) de datos (en la leyenda de gnuplot)

Una variante del PlotProbe anterior es especificar un quinto argumento opcional que controla
donde en la trama se coloca la clave (leyenda).

Un ejemplo completamente elaborado (de séptimo.cc) se muestra a continuación:

// Crea el asistente de gnuplot.
GnuplotHelper plotHelper;

// Configura la trama.
// Configura la trama. El primer argumento es el prefijo del nombre del archivo.
// para los archivos de salida generados. El segundo, tercero y cuarto
// los argumentos son, respectivamente, el título de la trama, el eje xy las etiquetas del eje y
plotHelper.ConfigurePlot ("recuento de bytes del séptimo paquete",
"Recuento de bytes de paquetes frente a tiempo",
"Tiempo (segundos)",
"Recuento de bytes de paquetes",
"png");

// Especifique el tipo de sonda, la ruta de origen del rastreo (en el espacio de nombres de configuración) y
// sondear la fuente de rastreo de salida ("OutputBytes") para trazar. El cuarto argumento
// especifica el nombre de la etiqueta de la serie de datos en el gráfico. El último
// El argumento formatea el gráfico especificando dónde debe colocarse la clave.
plotHelper.PlotProbe (tipo de sonda,
ruta de seguimiento,
"OutputBytes",
"Recuento de bytes de paquetes",
GnuplotAggregator :: KEY_BELOW);

En este ejemplo, el tipo de sonda y ruta de seguimiento son los siguientes (para IPv4):

probeType = "ns3 :: Ipv4PacketProbe";
tracePath = "/ NodeList / * / $ ns3 :: Ipv4L3Protocol / Tx";

ProbeType es un parámetro clave para que este ayudante funcione. Este TypeId debe estar registrado
en el sistema, y ​​la firma en el receptor de seguimiento de la sonda debe coincidir con la del seguimiento
fuente a la que se está conectando. Los tipos de sonda están predefinidos para varios tipos de datos
correspondiente a ns-3 valores de seguimiento, y para algunas otras firmas de origen de seguimiento, como
la fuente de rastreo 'Tx' de ns3 :: Ipv4L3Protocol clase.

Tenga en cuenta que la ruta de origen de seguimiento especificada puede contener comodines. En este caso, varios
los conjuntos de datos se grafican en una parcela; uno para cada ruta coincidente.

La salida principal producida serán tres archivos:

séptimo-paquete-byte-count.dat
séptimo-paquete-byte-count.plt
séptimo-paquete-byte-count.sh

En este punto, los usuarios pueden editar manualmente el archivo .plt para realizar más personalizaciones, o
simplemente ejecútelo a través de gnuplot. Corriendo sh séptimo-paquete-byte-count.sh simplemente corre la trama
a través de gnuplot, como se muestra a continuación.
[imagen] Gnuplot 2-D Creado por séptimo.cc Ejemplo..UNINDENT

Se puede ver que los elementos clave (leyenda, título, ubicación de la leyenda, xlabel, ylabel,
y la ruta de los datos) se colocan en la trama. Dado que hubo dos partidos para el
ruta de configuración proporcionada, se muestran las dos series de datos:

· Packet Byte Count-0 corresponde a / NodeList / 0 / $ ns3 :: Ipv4L3Protocol / Tx

· Packet Byte Count-1 corresponde a / NodeList / 1 / $ ns3 :: Ipv4L3Protocol / Tx

Ayudante de Gnuplot ConfigurarPlot
El GnuplotHelper's ConfigurePlot () La función se puede utilizar para configurar gráficos.

Tiene el siguiente prototipo:

ConfigurePlot vacío (const std :: string & outputFileNameWithoutExtension,
const std :: cadena y título,
const std :: string & xLegend,
const std :: string & yLegend,
const std :: string & terminalType = ".png");

Tiene los siguientes argumentos:

┌───────────────────────────────┬───────────────── ─────────────────┐
│Argumento │ Descripción │
├───────────────────────────────┼───────────────── ─────────────────┤
│outputFileNameWithoutExtension │ Nombre de los archivos relacionados con gnuplot a │
│ │ escribir sin extensión. │
├───────────────────────────────┼───────────────── ─────────────────┤
│title │ Trace la cadena de título que se utilizará para │
│ │ esta trama. │
└──────────────────────────────┴───────────────── ─────────────────┘

│xLegend │ La leyenda de la x horizontal │
Eje │ │. │
├───────────────────────────────┼───────────────── ─────────────────┤
│yLegend │ La leyenda de la vertical y │
Eje │ │. │
├───────────────────────────────┼───────────────── ─────────────────┤
│terminalType │ Cadena de configuración de tipo de terminal para │
│ │ salida. El terminal predeterminado │
│ │ tipo es "png". │
└──────────────────────────────┴───────────────── ─────────────────┘

El GnuplotHelper's ConfigurePlot () La función configura los parámetros relacionados con la gráfica para este
ayudante de gnuplot para que cree un archivo de datos gnuplot separado por espacios llamado
outputFileNameWithoutExtension + ".dat", un archivo de control gnuplot llamado
outputFileNameWithoutExtension + ".plt", y un script de shell para generar el gnuplot llamado
outputFileNameWithoutExtension + ".sh".

Un ejemplo de cómo utilizar esta función se puede ver en la séptimo.cc código descrito arriba
donde se usó de la siguiente manera:

plotHelper.ConfigurePlot ("recuento de bytes del séptimo paquete",
"Recuento de bytes de paquetes frente a tiempo",
"Tiempo (segundos)",
"Recuento de bytes de paquetes",
"png");

Ayudante de Gnuplot Trazar sonda
El GnuplotHelper's PlotProbe () La función se puede utilizar para trazar los valores generados por las sondas.

Tiene el siguiente prototipo:

vacío PlotProbe (const std :: string & typeId,
const std :: cadena y ruta,
const std :: string & probeTraceSource,
const std :: cadena y título,
enumeración GnuplotAggregator :: KeyLocation keyLocation = GnuplotAggregator :: KEY_INSIDE);

Tiene los siguientes argumentos:

┌─────────────────┬─────────────────────────────── ───┐
│Argumento │ Descripción │
├────────────────┼─────────────────────────────── ───┤
│typeId │ El ID de tipo de la sonda │
│ │ creado por este ayudante. │
├────────────────┼─────────────────────────────── ───┤
│ruta │ Ruta de configuración para acceder a la traza │
│ │ fuente. │
├────────────────┼─────────────────────────────── ───┤
│probeTraceSource │ La fuente de rastreo de la sonda a │
│ │ acceso. │
├────────────────┼─────────────────────────────── ───┤
│title │ El título que se asociará a │
│ │ este conjunto de datos │
├────────────────┼─────────────────────────────── ───┤
│keyLocation │ La ubicación de la clave en el │
│ │ trama. La ubicación predeterminada es │
│ │ adentro. │
└─────────────────┴─────────────────────────────── ───┘

El GnuplotHelper's PlotProbe () La función traza un conjunto de datos generado al conectar el ns-3
rastrear la fuente con una sonda creada por el ayudante, y luego trazar los valores de la
probeTraceSource. El conjunto de datos tendrá el título proporcionado y constará de la
'newValue' en cada marca de tiempo.

Si la ruta de configuración tiene más de una coincidencia en el sistema porque hay un comodín, entonces
se trazará un conjunto de datos para cada coincidencia. Los títulos del conjunto de datos tendrán el sufijo
caracteres coincidentes para cada uno de los comodines en la ruta de configuración, separados por espacios. Para
ejemplo, si el título del conjunto de datos propuesto es la cadena "bytes" y hay dos comodines
en la ruta, los títulos de conjuntos de datos como "bytes-0 0" o "bytes-12 9" serán posibles como
etiquetas para los conjuntos de datos que se trazan.

Un ejemplo de cómo utilizar esta función se puede ver en la séptimo.cc código descrito arriba
donde se usó (con sustitución de variable) de la siguiente manera:

plotHelper.PlotProbe ("ns3 :: Ipv4PacketProbe",
"/ NodeList / * / $ ns3 :: Ipv4L3Protocol / Tx",
"OutputBytes",
"Recuento de bytes de paquetes",
GnuplotAggregator :: KEY_BELOW);

Otro Ejemplos
parcela Ayudante Ejemplo
Un ejemplo un poco más simple que el séptimo.cc se puede encontrar un ejemplo en
src / stats / examples / gnuplot-helper-example.cc. El siguiente gnuplot 2-D se creó utilizando
el ejemplo.
[imagen] Gnuplot 2-D Creado por gnuplot-helper-example.cc Ejemplo..UNINDENT

En este ejemplo, hay un objeto Emisor que incrementa su contador de acuerdo con un
Poisson procesa y luego emite el valor del contador como fuente de rastreo.

Ptr emisor = CreateObject ();
Nombres :: Agregar ("/ Nombres / Emisor", emisor);

Tenga en cuenta que debido a que no hay comodines en la ruta utilizada a continuación, solo se
dibujado en la trama. Este único flujo de datos en el gráfico simplemente se etiqueta "Contador de emisores",
sin sufijos adicionales como uno vería si hubiera comodines en la ruta.

// Crea el asistente de gnuplot.
GnuplotHelper plotHelper;

// Configura la trama.
plotHelper.ConfigurePlot ("gnuplot-helper-example",
"Recuentos de emisores frente a tiempo",
"Tiempo (segundos)",
"Contador de emisores",
"png");

// Trace los valores generados por la sonda. El camino que proporcionamos
// ayuda a eliminar la ambigüedad de la fuente del rastro.
plotHelper.PlotProbe ("ns3 :: Uinteger32Probe",
"/ Nombres / Emisor / Contador",
"Producción",
"Contador de emisores",
GnuplotAggregator :: KEY_INSIDE);

Ayudante de archivo
FileHelper es una clase auxiliar que se utiliza para colocar valores de datos en un archivo. El objetivo general es
para proporcionar a los usuarios la capacidad de crear rápidamente archivos de texto formateados a partir de datos exportados
in ns-3 rastrear fuentes. De forma predeterminada, se realiza una cantidad mínima de transformación de datos;
el objetivo es generar archivos con tan pocas declaraciones de configuración (predeterminadas) como
posible.

Ayudante de archivo Descripción General
FileHelper creará 1 o más archivos de texto al final de la simulación.

FileHelper puede crear 4 tipos diferentes de archivos de texto:

· Formateado

· Separado por espacios (predeterminado)

· Separado por comas

· Separado por tabuladores

Los archivos formateados utilizan cadenas de formato de estilo C y la función sprintf () para imprimir su
valores en el archivo que se está escribiendo.

El siguiente archivo de texto con 2 columnas de valores formateados llamados
séptimo-paquete-byte-count-0.txt fue creado usando más código nuevo que se agregó al
mas originales ns-3 Código del ejemplo del tutorial. Solo se muestran las primeras 10 líneas de este archivo
aquí por brevedad.

Tiempo (segundos) = 1.000e + 00 Recuento de bytes del paquete = 40
Tiempo (segundos) = 1.004e + 00 Recuento de bytes del paquete = 40
Tiempo (segundos) = 1.004e + 00 Recuento de bytes del paquete = 576
Tiempo (segundos) = 1.009e + 00 Recuento de bytes del paquete = 576
Tiempo (segundos) = 1.009e + 00 Recuento de bytes del paquete = 576
Tiempo (segundos) = 1.015e + 00 Recuento de bytes del paquete = 512
Tiempo (segundos) = 1.017e + 00 Recuento de bytes del paquete = 576
Tiempo (segundos) = 1.017e + 00 Recuento de bytes del paquete = 544
Tiempo (segundos) = 1.025e + 00 Recuento de bytes del paquete = 576
Tiempo (segundos) = 1.025e + 00 Recuento de bytes del paquete = 544

...

El siguiente archivo de texto diferente con 2 columnas de valores formateados llamados
séptimo-paquete-byte-count-1.txt también se creó utilizando el mismo código nuevo que se agregó a
el original ns-3 Código del ejemplo del tutorial. Solo se muestran las primeras 10 líneas de este archivo
aquí por brevedad.

Tiempo (segundos) = 1.002e + 00 Recuento de bytes del paquete = 40
Tiempo (segundos) = 1.007e + 00 Recuento de bytes del paquete = 40
Tiempo (segundos) = 1.013e + 00 Recuento de bytes del paquete = 40
Tiempo (segundos) = 1.020e + 00 Recuento de bytes del paquete = 40
Tiempo (segundos) = 1.028e + 00 Recuento de bytes del paquete = 40
Tiempo (segundos) = 1.036e + 00 Recuento de bytes del paquete = 40
Tiempo (segundos) = 1.045e + 00 Recuento de bytes del paquete = 40
Tiempo (segundos) = 1.053e + 00 Recuento de bytes del paquete = 40
Tiempo (segundos) = 1.061e + 00 Recuento de bytes del paquete = 40
Tiempo (segundos) = 1.069e + 00 Recuento de bytes del paquete = 40

...

El nuevo código que se agregó para producir los dos archivos de texto se encuentra a continuación. Más detalles sobre
esta API se tratará en una sección posterior.

Tenga en cuenta que debido a que hubo 2 coincidencias para el comodín en la ruta, 2 archivos de texto separados
fueron creados. El primer archivo de texto, que se llama "séptimo-paquete-byte-recuento-0.txt",
corresponde a la coincidencia de comodines con el "*" reemplazado por "0". El segundo archivo de texto,
que se llama "séptimo-paquete-byte-count-1.txt", corresponde a la coincidencia del comodín con
el "*" reemplazado por "1". Además, tenga en cuenta que la función llamada a WriteProbe () dará un
mensaje de error si no hay coincidencias para una ruta que contiene comodines.

// Crea el asistente de archivos.
Ayudante de archivos Ayudante de archivos;

// Configure el archivo a escribir.
fileHelper.ConfigureFile ("séptimo-paquete-byte-recuento",
FileAggregator :: FORMATTED);

// Establezca las etiquetas para este archivo de salida formateado.
fileHelper.Set2dFormat ("Tiempo (segundos) =% .3e \ tRecuento de bytes del paquete =% .0f");

// Escribe los valores generados por la sonda.
fileHelper.WriteProbe ("ns3 :: Ipv4PacketProbe",
"/ NodeList / * / $ ns3 :: Ipv4L3Protocol / Tx",
"OutputBytes");

Ayudante de archivo Configurar archivo
El FileHelper ConfigureFile () La función se puede utilizar para configurar archivos de texto.

Tiene el siguiente prototipo:

Void ConfigureFile (const std :: string & outputFileNameWithoutExtension,
enumeración FileAggregator :: FileType fileType = FileAggregator :: SPACE_SEPARATED);

Tiene los siguientes argumentos:

┌───────────────────────────────┬───────────────── ─────────────────┐
│Argumento │ Descripción │
├───────────────────────────────┼───────────────── ─────────────────┤
│outputFileNameWithoutExtension │ Nombre del archivo de salida para escribir │
│ │ sin extensión. │
├───────────────────────────────┼───────────────── ─────────────────┤
│fileType │ Tipo de archivo a escribir. El │
│ │ el tipo de archivo predeterminado es el espacio │
│ │ separados. │
└──────────────────────────────┴───────────────── ─────────────────┘

El FileHelper ConfigureFile () La función configura los parámetros relacionados con el archivo de texto para el
ayudante de archivos para que cree un archivo llamado outputFileNameWithoutExtension plus
posible información adicional de coincidencias de comodines más ".txt" con valores impresos como
especificado por fileType. El tipo de archivo predeterminado está separado por espacios.

Un ejemplo de cómo utilizar esta función se puede ver en la séptimo.cc código descrito arriba
donde se usó de la siguiente manera:

fileHelper.ConfigureFile ("séptimo-paquete-byte-recuento",
FileAggregator :: FORMATTED);

Ayudante de archivo Sonda de escritura
El FileHelper WriteProbe () La función se puede utilizar para escribir valores generados por sondas para
archivos de texto.

Tiene el siguiente prototipo:

vacío WriteProbe (const std :: string & typeId,
const std :: cadena y ruta,
const std :: string & probeTraceSource);

Tiene los siguientes argumentos:

┌─────────────────┬─────────────────────────────── ───┐
│Argumento │ Descripción │
├────────────────┼─────────────────────────────── ───┤
│typeId │ El ID de tipo de la sonda │
│ │ creado. │
├────────────────┼─────────────────────────────── ───┤
│ruta │ Ruta de configuración para acceder a la traza │
│ │ fuente. │
├────────────────┼─────────────────────────────── ───┤
│probeTraceSource │ La fuente de rastreo de la sonda a │
│ │ acceso. │
└─────────────────┴─────────────────────────────── ───┘

El FileHelper WriteProbe () La función crea archivos de texto de salida generados al conectar el
fuente de rastreo ns-3 con una sonda creada por el ayudante, y luego escribiendo los valores del
probeTraceSource. Los nombres de los archivos de salida tendrán el texto almacenado en la variable miembro
m_outputFileNameWithoutExtension más ".txt", y consistirá en el 'newValue' en cada
marca de tiempo.

Si la ruta de configuración tiene más de una coincidencia en el sistema porque hay un comodín, entonces
Se creará un archivo de salida para cada partido. Los nombres de los archivos de salida contendrán el
texto en m_outputFileNameWithoutExtension más los caracteres coincidentes para cada uno de los
comodines en la ruta de configuración, separados por guiones, más ".txt". Por ejemplo, si el valor
en m_outputFileNameWithoutExtension es la cadena "packet-byte-count", y hay dos
comodines en la ruta, luego nombres de archivos de salida como "packet-byte-count-0-0.txt" o
"packet-byte-count-12-9.txt" será posible como nombres para los archivos que se crearán.

Un ejemplo de cómo utilizar esta función se puede ver en la séptimo.cc código descrito arriba
donde se usó de la siguiente manera:

fileHelper.WriteProbe ("ns3 :: Ipv4PacketProbe",
"/ NodeList / * / $ ns3 :: Ipv4L3Protocol / Tx",
"OutputBytes");

Otro Ejemplos
Archive Ayudante Ejemplo
Un ejemplo un poco más simple que el séptimo.cc se puede encontrar un ejemplo en
src / stats / examples / file-helper-example.cc. Este ejemplo solo usa FileHelper.

El siguiente archivo de texto con 2 columnas de valores formateados llamados archivo-ayudante-ejemplo.txt
fue creado usando el ejemplo. Aquí solo se muestran las primeras 10 líneas de este archivo para
brevedad.

Tiempo (segundos) = 0.203 Cuenta = 1
Tiempo (segundos) = 0.702 Cuenta = 2
Tiempo (segundos) = 1.404 Cuenta = 3
Tiempo (segundos) = 2.368 Cuenta = 4
Tiempo (segundos) = 3.364 Cuenta = 5
Tiempo (segundos) = 3.579 Cuenta = 6
Tiempo (segundos) = 5.873 Cuenta = 7
Tiempo (segundos) = 6.410 Cuenta = 8
Tiempo (segundos) = 6.472 Cuenta = 9
...

En este ejemplo, hay un objeto Emisor que incrementa su contador de acuerdo con un
Poisson procesa y luego emite el valor del contador como fuente de rastreo.

Ptr emisor = CreateObject ();
Nombres :: Agregar ("/ Nombres / Emisor", emisor);

Tenga en cuenta que debido a que no hay comodines en la ruta utilizada a continuación, solo se
creado. Este único archivo de texto se llama simplemente "file-helper-example.txt", sin extra
sufijos como vería si hubiera comodines en la ruta.

// Crea el asistente de archivos.
Ayudante de archivos Ayudante de archivos;

// Configure el archivo a escribir.
fileHelper.ConfigureFile ("file-helper-example",
FileAggregator :: FORMATTED);

// Establezca las etiquetas para este archivo de salida formateado.
fileHelper.Set2dFormat ("Tiempo (segundos) =% .3e \ tCount =% .0f");

// Escribe los valores generados por la sonda. El camino que nosotros
// proporciona ayuda para eliminar la ambigüedad de la fuente del rastro.
fileHelper.WriteProbe ("ns3 :: Uinteger32Probe",
"/ Nombres / Emisor / Contador",
"Producción");

<b></b><b></b> y Limitaciones
Actualmente, solo estas sondas se han implementado y conectado a GnuplotHelper y
al FileHelper:

· Sonda booleana

· Doble sonda

· Uinteger8Probe

· Uinteger16Probe

· Uinteger32Probe

· Sonda de tiempo

· Sonda de paquetes

· Sonda de paquete de aplicación

· Sonda de paquetes Ipv4

Estas sondas, por lo tanto, son los únicos TypeIds disponibles para usarse en PlotProbe () y
WriteProbe ().

En las siguientes secciones, cubrimos cada uno de los tipos de objetos fundamentales (sonda, colector,
y agregador) con más detalle, y mostrar cómo se pueden conectar entre sí utilizando
API de nivel inferior.

Sondas
Esta sección detalla las funcionalidades proporcionadas por la clase Probe a un ns-3
simulación, y da ejemplos sobre cómo codificarlos en un programa. Esta sección está destinada a
usuarios interesados ​​en desarrollar simulaciones con el ns-3 herramientas y uso de los datos
Collection Framework, del cual la clase Probe es parte, para generar salida de datos con
los resultados de su simulación.

Muestra Descripción General
Se supone que un objeto Probe está conectado a una variable de la simulación cuyos valores
a lo largo del experimento son relevantes para el usuario. La sonda registrará lo que fueron
valores asumidos por la variable a lo largo de la simulación y pasar dichos datos a otra
miembro del marco de recopilación de datos. Si bien está fuera del alcance de esta sección
discutir lo que sucede después de que la sonda produce su salida, es suficiente decir que, por
Al final de la simulación, el usuario tendrá información detallada sobre qué valores fueron
almacenados dentro de la variable que se está probando durante la simulación.

Normalmente, una sonda se conecta a un ns-3 fuente de rastreo. De esta manera, siempre que el
la fuente de rastreo exporta un nuevo valor, la sonda consume el valor (y lo exporta en sentido descendente
a otro objeto a través de su propia fuente de seguimiento).

La sonda se puede considerar como una especie de filtro en las fuentes de rastreo. Las principales razones de
posiblemente engancharse a una sonda en lugar de directamente a una fuente de rastreo son los siguientes:

· Las sondas se pueden encender y apagar dinámicamente durante la simulación con llamadas a Permitir()
y Desactivar(). Por ejemplo, la salida de datos puede desactivarse durante la
fase de calentamiento de simulación.

· Las sondas pueden realizar operaciones en los datos para extraer valores de más complicados
estructuras; por ejemplo, generar el valor del tamaño del paquete desde un ns3 :: Packet recibido.

· Las sondas registran un nombre en el espacio de nombres ns3 :: Config (usando Nombres :: Agregar ()) para que otro
los objetos pueden referirse a ellos.

· Las sondas proporcionan un método estático que permite manipular una sonda por su nombre, como
lo que se hace en ns2measure [Cic06]

Stat :: put ("my_metric", ID, muestra);

El equivalente ns-3 del código de medida ns2 anterior es, por ejemplo

DoubleProbe :: SetValueByPath ("/ ruta / a / sonda", muestra);

contenido SEO
Tenga en cuenta que no se puede crear un objeto de clase base Probe porque es una base abstracta
class, es decir, tiene funciones virtuales puras que no han sido implementadas. Un objeto de
tipo DoubleProbe, que es una subclase de la clase Probe, se creará aquí para mostrar
lo que hay que hacer.

Uno declara un DoubleProbe en la memoria dinámica utilizando la clase de puntero inteligente (Ptr ). A
crear un DoubleProbe en memoria dinámica con punteros inteligentes, solo es necesario llamar al
ns-3 Método Crear objeto():

Ptr myprobe = CreateObject ();

La declaración anterior crea DoubleProbes utilizando los valores predeterminados para sus atributos.
Hay cuatro atributos en la clase DoubleProbe; dos en el objeto de clase base
DataCollectionObject y dos en la clase base Probe:

· "Nombre" (DataCollectionObject), un StringValue

· "Habilitado" (DataCollectionObject), un valor booleano

· "Inicio" (sonda), un valor de tiempo

· "Detener" (sonda), un valor de tiempo

Se pueden establecer dichos atributos en la creación del objeto utilizando el siguiente método:

Ptr myprobe = CreateObjectWithAttributes (
"Nombre", StringValue ("myprobe"),
"Habilitado", BooleanValue (falso),
"Inicio", TimeValue (Segundos (100.0)),
"Detener", TimeValue (Segundos (1000.0)));

Start y Stop son variables de tiempo que determinan el intervalo de acción de la sonda. El
La sonda solo generará datos si el tiempo actual de la simulación está dentro de ese
intervalo. El valor de tiempo especial de 0 segundos para la parada deshabilitará este atributo (es decir,
mantenga la sonda encendida durante toda la simulación). Habilitado es una bandera que enciende o enciende la sonda.
off, y debe establecerse en true para que Probe exporte datos. El nombre es el nombre del objeto.
en el marco DCF.

Importador y exportar datos
ns-3 Las fuentes de rastreo están fuertemente tipadas, por lo que los mecanismos para conectar Probes a un rastreo
fuente y para exportar datos pertenecen a sus subclases. Por ejemplo, el valor predeterminado
distribución de ns-3 proporciona una clase DoubleProbe que está diseñada para conectarse a una traza
fuente exportando un valor doble. A continuación, detallaremos el funcionamiento de DoubleProbe, y
luego discuta cómo el usuario puede definir otras clases de Probe.

Sonda doble Descripción General
El DoubleProbe se conecta a un doble valor ns-3 fuente de rastreo, y exporta un
diferente de doble valor ns-3 fuente de rastreo.

El siguiente código, extraído de src / stats / examples / double-probe-example.cc, muestra el básico
operaciones de conectar el DoubleProbe a una simulación, donde está probando un contador
exportado por un objeto emisor (clase Emitter).

Ptr emisor = CreateObject ();
Nombres :: Agregar ("/ Nombres / Emisor", emisor);
...

Ptr probe1 = CreateObject ();

// Conecta la sonda al Contador del emisor
bool conectado = sonda1-> ConnectByObject ("Contador", emisor);

El siguiente código está probando el mismo contador exportado por el mismo objeto emisor. Esta
DoubleProbe, sin embargo, está utilizando una ruta en el espacio de nombres de configuración para hacer
conexión. Tenga en cuenta que el emisor se registró en el espacio de nombres de configuración después
fue creado; de lo contrario, ConnectByPath no funcionaría.

Ptr probe2 = CreateObject ();

// Tenga en cuenta que aquí no se comprueba ningún valor de retorno
probe2-> ConnectByPath ("/ Nombres / Emisor / Contador");

El siguiente DoubleProbe que se muestra a continuación tendrá su valor establecido usando su ruta en
el espacio de nombres de la configuración. Tenga en cuenta que esta vez DoubleProbe se registró en el
espacio de nombres de configuración después de su creación.

Ptr probe3 = CreateObject ();
probe3-> SetName ("StaticallyAccessedProbe");

// Debemos agregarlo a la base de datos de configuración
Nombres :: Agregar ("/ Nombres / Sondas", probe3-> GetName (), probe3);

La función Count () del emisor ahora puede establecer el valor de este DoubleProbe como
manera:

vacío
Emisor :: Recuento (vacío)
{
...
m_contador + = 1.0;
DoubleProbe :: SetValueByPath ("/ Nombres / StaticallyAccessedProbe", m_counter);
...
}

El ejemplo anterior muestra cómo el código que llama a Probe no tiene que tener un código explícito.
referencia a la sonda, pero puede dirigir la configuración del valor a través del espacio de nombres Config.
Esto es similar en funcionalidad a la Estadísticas :: Poner método introducido por ns2measure paper
[Cic06], y permite a los usuarios insertar temporalmente declaraciones Probe como Printf declaraciones
dentro de lo existente ns-3 modelos. Tenga en cuenta que para poder utilizar DoubleProbe en este
ejemplo como este, eran necesarias 2 cosas:

1. el archivo de encabezado del módulo de estadísticas se incluyó en el archivo .cc de ejemplo

2. el ejemplo se hizo dependiente del módulo de estadísticas en su archivo wscript.

Es necesario hacer cosas análogas para agregar otras sondas en otros lugares del ns-3
base de código.

Los valores para DoubleProbe también se pueden configurar usando la función DoubleProbe :: SetValue (),
mientras que los valores para DoubleProbe se pueden obtener usando la función
DoubleProbe :: GetValue ().

DoubleProbe exporta valores dobles en su origen de seguimiento "Salida"; un objeto corriente abajo
puede conectar un receptor de seguimiento (NotifyViaProbe) a esto de la siguiente manera:

conectado = sonda1-> TraceConnect ("Salida", sonda1-> GetName (), MakeCallback (& ​​NotifyViaProbe));

Otro sondas
Además de DoubleProbe, también están disponibles las siguientes sondas:

· Uinteger8Probe se conecta a un ns-3 fuente de seguimiento exportando un archivo uint8_t.

· Uinteger16Probe se conecta a un ns-3 fuente de seguimiento exportando un archivo uint16_t.

· Uinteger32Probe se conecta a un ns-3 fuente de seguimiento exportando un archivo uint32_t.

· PacketProbe se conecta a un ns-3 fuente de rastreo exportando un paquete.

· ApplicationPacketProbe se conecta a un ns-3 rastrear la fuente exportando un paquete y un socket
dirección.

· Ipv4PacketProbe se conecta a un ns-3 fuente de seguimiento exportando un paquete, un objeto IPv4 y
una interfaz.

Creamos new Muestra tipos
Para crear un nuevo tipo de sonda, debe realizar los siguientes pasos:

· Asegúrese de que su nueva clase Probe se derive de la clase base Probe.

· Asegúrese de que las funciones virtuales puras que su nueva clase Probe hereda de la
Se implementan las clases base de la sonda.

· Busque una clase Probe existente que utilice una fuente de seguimiento que sea más parecida en tipo a la
tipo de fuente de rastreo que utilizará su sonda.

· Copie el archivo de encabezado (.h) y el archivo de implementación (.cc) de la clase Probe existente en dos
nuevos archivos con nombres que coincidan con su nueva sonda.

· Reemplazar los tipos, argumentos y variables en los archivos copiados con el apropiado
escriba para su sonda.

· Realice las modificaciones necesarias para que el código se compile y se comporte como lo haría
gusta.

Ejemplos
Aquí se comentarán en detalle dos ejemplos:

· Ejemplo de sonda doble

· Ejemplo de diagrama de paquetes IPv4

Doble Muestra Ejemplo
El ejemplo de la sonda doble se ha comentado anteriormente. El programa de ejemplo se puede encontrar
in src / stats / examples / double-probe-example.cc. Para resumir lo que ocurre en este programa,
hay un emisor que exporta un contador que se incrementa según un proceso de Poisson.
En particular, se muestran dos formas de emitir datos:

1. a través de una variable rastreada conectada a una sonda:

TracedValue m_counter; // normalmente este sería de tipo entero

2. a través de un contador cuyo valor se contabiliza en una segunda sonda, referenciada por su nombre en
el sistema de configuración:

vacío
Emisor :: Recuento (vacío)
{
NS_LOG_FUNCTION (esto);
NS_LOG_DEBUG ("Contando en" << Simulator :: Now () .GetSeconds ());
m_contador + = 1.0;
DoubleProbe :: SetValueByPath ("/ Nombres / StaticallyAccessedProbe", m_counter);
Simulator :: Schedule (Seconds (m_var-> GetValue ()), & Emitter :: Count, this);
}

Echemos un vistazo a la sonda con más atención. Las sondas pueden recibir sus valores en múltiples
formas:

1. mediante el acceso de la sonda a la fuente de seguimiento directamente y la conexión de un receptor de seguimiento

2. por la sonda accediendo a la fuente de seguimiento a través del espacio de nombres de configuración y conectando un
rastro del sumidero hasta él

3. por el código de llamada que llama explícitamente a la sonda Valor ajustado() Método

4. por el código de llamada que llama explícitamente EstablecerValorPorRuta
("/ ruta / a / Config / espacio de nombres", ...)

Se espera que las dos primeras técnicas sean las más comunes. También en el ejemplo, el
Se muestra el enganche de una función de devolución de llamada normal, como se hace normalmente en ns-3. Esto
La función de devolución de llamada no está asociada con un objeto Probe. A este caso lo llamaremos 0) a continuación.

// Esta es una función para probar el enganche de una función sin formato a la fuente de seguimiento
vacío
NotifyViaTraceSource (std :: contexto de cadena, doble oldVal, doble newVal)
{
NS_LOG_DEBUG ("contexto:" << contexto << "antiguo" << antiguoVal << "nuevo" << nuevoValor);
}

Primero, el emisor debe configurarse:

Ptr emisor = CreateObject ();
Nombres :: Agregar ("/ Nombres / Emisor", emisor);

// El objeto Emitter no está asociado con un nodo ns-3, por lo que
// no se iniciará automáticamente, por lo que debemos hacerlo nosotros mismos
Simulador :: Programación (Segundos (0.0), & Emisor :: Inicio, emisor);

Los distintos DoubleProbes interactúan con el emisor en el ejemplo, como se muestra a continuación.

Caso 0):

// A continuación se muestra la funcionalidad típica sin sonda
// (conecta una función de sumidero a una fuente de rastreo)
//
conectado = emisor-> TraceConnect ("Contador", "contexto de muestra", MakeCallback (& ​​NotifyViaTraceSource));
NS_ASSERT_MSG (conectado, "Fuente de seguimiento no conectada");

caso 1):

//
// Probe1 se conectará directamente al objeto de origen de seguimiento del emisor
//

// probe1 se conectará a la fuente de seguimiento del emisor
Ptr probe1 = CreateObject ();
// el nombre de la sonda puede servir como contexto en el rastreo
probe1-> SetName ("ObjectProbe");

// Conecta la sonda al Contador del emisor
conectado = sonda1-> ConnectByObject ("Contador", emisor);
NS_ASSERT_MSG (conectado, "Fuente de rastreo no conectada a probe1");

caso 2):

//
// Probe2 se conectará al objeto de origen de seguimiento del emisor mediante
// acceder a él por el nombre de la ruta en la base de datos de configuración
//

// Crea otra sonda similar; esto se conectará a través de una ruta de configuración
Ptr probe2 = CreateObject ();
probe2-> SetName ("PathProbe");

// Tenga en cuenta que aquí no se comprueba ningún valor de retorno
probe2-> ConnectByPath ("/ Nombres / Emisor / Contador");

caso 4) (el caso 3 no se muestra en este ejemplo):

//
// Probe3 será llamado por el emisor directamente a través del
// método estático SetValueByPath ().
//
Ptr probe3 = CreateObject ();
probe3-> SetName ("StaticallyAccessedProbe");
// Debemos agregarlo a la base de datos de configuración
Nombres :: Agregar ("/ Nombres / Sondas", probe3-> GetName (), probe3);

Y finalmente, el ejemplo muestra cómo se pueden conectar las sondas para generar resultados:

// La propia sonda debería generar una salida. El contexto que brindamos
// a esta sonda (en este caso, el nombre de la sonda) ayudará a eliminar la ambigüedad
// la fuente del rastro
conectado = sonda3-> TraceConnect ("Salida",
"/ Nombres / Sondas / Sonda de acceso estático / Salida",
MakeCallback (& ​​NotifyViaProbe));
NS_ASSERT_MSG (conectado, "Fuente de seguimiento no ... conectada a la salida probe3");

La siguiente devolución de llamada está conectada a Probe en este ejemplo con fines ilustrativos;
normalmente, la sonda se conectaría a un objeto recopilador.

// Esta es una función para probar y conectarla a la salida de la sonda
vacío
NotifyViaProbe (std :: contexto de cadena, doble oldVal, doble newVal)
{
NS_LOG_DEBUG ("contexto:" << contexto << "antiguo" << antiguoVal << "nuevo" << nuevoValor);
}

IPv4 Paquete Parcela Ejemplo
El ejemplo del diagrama de paquetes IPv4 se basa en el quinto ejemplo .cc del ns-3 Tutorial. Eso
puede encontrarse en src / stats / examples / ipv4-packet-plot-example.cc.

nodo 0 nodo 1
+ ---------------- + + ---------------- +
| TCP ns-3 | | TCP ns-3 |
+ ---------------- + + ---------------- +
| 10.1.1.1 | | 10.1.1.2 |
+ ---------------- + + ---------------- +
| punto a punto | | punto a punto |
+ ---------------- + + ---------------- +
| |
+ --------------------- +

Solo veremos la sonda, ya que ilustra que las sondas también pueden descomprimir valores de
estructuras (en este caso, paquetes) e informan esos valores como salidas de origen de seguimiento, en lugar de
que simplemente pasar por el mismo tipo de datos.

Hay otros aspectos de este ejemplo que se explicarán más adelante en la documentación.
Los dos tipos de datos que se exportan son el paquete en sí (Salida) y un recuento de los
número de bytes en el paquete (bytes de salida).

ID de tipo
Ipv4PacketProbe :: GetTypeId ()
{
estático TypeId tid = TypeId ("ns3 :: Ipv4PacketProbe")
.SetParent ()
.AddConstructor ()
.AddTraceSource ("Salida",
"El paquete más su objeto IPv4 y la interfaz que sirven como salida para esta sonda",
MakeTraceSourceAccessor (& Ipv4PacketProbe :: m_output))
.AddTraceSource ("OutputBytes",
"El número de bytes en el paquete",
MakeTraceSourceAccessor (& Ipv4PacketProbe :: m_outputBytes))
;
volver tid;
}

Cuando el receptor de seguimiento de la sonda recibe un paquete, si la sonda está habilitada, generará
el paquete en su Salida fuente de seguimiento, pero también generará el número de bytes en el
bytes de salida fuente de rastreo.

vacío
Ipv4PacketProbe :: TraceSink (Ptr paquete, Ptr ipv4, interfaz uint4_t)
{
NS_LOG_FUNCTION (esta interfaz << paquete << ipv4 <<);
si (IsEnabled ())
{
m_packet = paquete;
m_ipv4 = ipv4;
m_interface = interfaz;
m_output (paquete, ipv4, interfaz);

uint32_t packetSizeNew = paquete-> GetSize ();
m_outputBytes (m_packetSizeOld, paqueteSizeNew);
m_packetSizeOld = paqueteTamañoNuevo;
}
}

Referencias
[Cic06]
Claudio Cicconetti, Enzo Mingozzi, Giovanni Stea, "Un marco integrado para
Habilitación de la recopilación de datos y el análisis estadístico efectivos con ns2, Taller sobre
ns-2 (WNS2), Pisa, Italia, octubre de 2006.

Colectores
Esta sección es un marcador de posición para detallar las funcionalidades proporcionadas por el recopilador.
clase a un ns-3 simulación, y da ejemplos sobre cómo codificarlos en un programa.

Nota: A partir de ns-3.18, los recopiladores aún están en desarrollo y aún no se proporcionan como parte
del marco.

Agregadores
Esta sección detalla las funcionalidades proporcionadas por la clase Aggregator a un ns-3
simulación. Esta sección está dirigida a usuarios interesados ​​en desarrollar simulaciones con el
ns-3 herramientas y utilizando el marco de recopilación de datos, de los cuales la clase Aggregator es una
parte, para generar salida de datos con los resultados de su simulación.

Aggregator Descripción General
Se supone que un objeto Aggregator está conectado a una o más fuentes de seguimiento para
recibir entrada. Los agregadores son el punto final de los datos recopilados por la red de
Sondas y colectores durante la simulación. Es el trabajo del agregador tomar estos
valores y transformarlos en su formato de salida final, como archivos de texto sin formato,
archivos de hoja de cálculo, gráficos o bases de datos.

Normalmente, un agregador está conectado a uno o más recopiladores. De esta manera, siempre que
Las fuentes de seguimiento de los recopiladores exportan nuevos valores, el agregador puede procesar el valor para
que se puede utilizar en el formato de salida final donde los valores de datos residirán después de la
simulación.

Tenga en cuenta lo siguiente acerca de los agregadores:

· Los agregadores pueden activarse y desactivarse dinámicamente durante la simulación con llamadas a
Permitir() y Desactivar(). Por ejemplo, la agregación de datos puede desactivarse durante
la fase de calentamiento de la simulación, lo que significa que esos valores no se incluirán en la
medio de salida.

· Los agregadores reciben datos de los recopiladores a través de devoluciones de llamada. Cuando un coleccionista está asociado
a un agregador, se realiza una llamada a TraceConnect para establecer el seguimiento del agregador
método de sumidero como devolución de llamada.

Hasta la fecha, se han implementado dos agregadores:

· Agregador Gnuplot

· Agregador de archivos

Agregador de Gnuplot
GnuplotAggregator produce archivos de salida que se utilizan para hacer gnuplots.

El GnuplotAggregator creará 3 archivos diferentes al final de la simulación:

· Un archivo de datos gnuplot separado por espacios

· Un archivo de control de gnuplot

· Un script de shell para generar el gnuplot

contenido SEO
Aquí se creará un objeto de tipo GnuplotAggregator para mostrar lo que se debe hacer.

Uno declara un GnuplotAggregator en memoria dinámica usando la clase de puntero inteligente
(Ptr ). Para crear un GnuplotAggregator en memoria dinámica con punteros inteligentes, uno solo
necesita llamar al ns-3 Método Crear objeto(). El siguiente código de
src / stats / examples / gnuplot-aggregator-example.cc muestra cómo hacer esto:

string fileNameWithoutExtension = "gnuplot-aggregator";

// Crea un agregador.
Ptr agregador =
Crear objeto (fileNameWithoutExtension);

El primer argumento del constructor, fileNameWithoutExtension, es el nombre del
gnuplot para escribir archivos sin extensión. Este GnuplotAggregator creará un
archivo de datos gnuplot separado por espacios llamado "gnuplot-aggregator.dat", un archivo de control gnuplot
llamado "gnuplot-aggregator.plt", y un script de shell para generar el gnuplot llamado +
"gnuplot-aggregator.sh".

El gnuplot que se crea puede tener su clave en 4 ubicaciones diferentes:

· No hay llave

· Clave dentro de la trama (por defecto)

· Clave sobre la trama

· Clave debajo de la trama

Los siguientes valores de enumeración de ubicación de clave de gnuplot pueden especificar la posición de la clave:

enumerar ubicación clave {
NO HAY LLAVE,
CLAVE_INTERIOR,
CLAVE_ARRIBA,
CLAVE_ABAJO
};

Si se deseaba tener la clave debajo en lugar de la posición predeterminada del interior, entonces
podría hacer lo siguiente.

agregador-> SetKeyLocation (GnuplotAggregator :: KEY_BELOW);

Ejemplos
Un ejemplo se discutirá en detalle aquí:

· Ejemplo de agregador de Gnuplot

parcela Aggregator Ejemplo
Un ejemplo que ejercita el GnuplotAggregator se puede encontrar en
src / stats / examples / gnuplot-aggregator-example.cc.

El siguiente gnuplot 2-D se creó utilizando el ejemplo.
[imagen] Gnuplot 2-D Creado por gnuplot-aggregator-example.cc Ejemplo..UNINDENT

Este código del ejemplo muestra cómo construir el GnuplotAggregator como se discutió
anterior.

vacío Create2dPlot ()
{
Using namespace std;

string fileNameWithoutExtension = "gnuplot-aggregator";
string plotTitle = "Gráfica del agregador de Gnuplot";
string plotXAxisHeading = "Tiempo (segundos)";
string plotYAxisHeading = "Valores dobles";
string plotDatasetLabel = "Valores de datos";
string datasetContext = "Conjunto de datos / Contexto / Cadena";

// Crea un agregador.
Ptr agregador =
Crear objeto (fileNameWithoutExtension);

Se establecen varios atributos de GnuplotAggregator, incluido el conjunto de datos 2-D que se
trazado.

// Establecer las propiedades del agregador.
agregador-> SetTerminal ("png");
agregador-> SetTitle (plotTitle);
agregador-> SetLegend (plotXAxisHeading, plotYAxisHeading);

// Agrega un conjunto de datos al agregador.
agregador-> Add2dDataset (datasetContext, plotDatasetLabel);

// el agregador debe estar encendido
agregador-> Habilitar ();

A continuación, se calculan los valores 2-D y cada uno se escribe individualmente en el
GnuplotAggregator usando el Write2d () función.

doble tiempo;
valor doble;

// Crea el conjunto de datos 2-D.
para (tiempo = -5.0; tiempo <= +5.0; tiempo + = 1.0)
{
// Calcula la curva 2-D
//
/ / 2
// valor = tiempo.
//
valor = tiempo * tiempo;

// Agrega este punto a la trama.
agregador-> Write2d (datasetContext, tiempo, valor);
}

// Deshabilitar el registro de datos para el agregador.
agregador-> Desactivar ();
}

Agregador de archivos
FileAggregator envía los valores que recibe a un archivo.

FileAggregator puede crear 4 tipos diferentes de archivos:

· Formateado

· Separado por espacios (predeterminado)

· Separado por comas

· Separado por tabuladores

Los archivos formateados utilizan cadenas de formato de estilo C y la función sprintf () para imprimir su
valores en el archivo que se está escribiendo.

contenido SEO
Aquí se creará un objeto de tipo FileAggregator para mostrar lo que se debe hacer.

Uno declara un FileAggregator en memoria dinámica usando la clase de puntero inteligente (Ptr ).
Para crear un FileAggregator en memoria dinámica con punteros inteligentes, solo necesita llamar
los ns-3 método CreateObject. El siguiente código de
src / stats / examples / file-aggregator-example.cc muestra cómo hacer esto:

string fileName = "file-aggregator-formatted-values.txt";

// Cree un agregador que tendrá valores formateados.
Ptr agregador =
Crear objeto (fileName, FileAggregator :: FORMATTED);

El primer argumento del constructor, nombre de archivo, es el nombre del archivo a escribir; el
El segundo argumento, fileType, es el tipo de archivo que se va a escribir. Este FileAggregator creará un
archivo llamado "file-aggregator-formatted-values.txt" con sus valores impresos según lo especificado por
fileType, es decir, formateado en este caso.

Se permiten los siguientes valores de enumeración de tipo de archivo:

enumerar tipo de archivo {
FORMATEADO,
ESPACIO_SEPARADO,
SEPARADO POR COMAS,
TAB_SEPARADO
};

Ejemplos
Un ejemplo se discutirá en detalle aquí:

· Ejemplo de agregador de archivos

Archive Aggregator Ejemplo
Un ejemplo que ejercita el FileAggregator se puede encontrar en
src / stats / examples / file-aggregator-example.cc.

El siguiente archivo de texto con 2 columnas de valores separados por comas fue creado usando el
ejemplo.

-5,25
-4,16
-3,9
-2,4
-1,1
0,0
1,1
2,4
3,9
4,16
5,25

Este código del ejemplo muestra cómo construir FileAggregator como se discutió
anterior.

vacío CreateCommaSeparatedFile ()
{
Using namespace std;

string fileName = "agregador-de-archivos-separado por comas.txt";
string datasetContext = "Conjunto de datos / Contexto / Cadena";

// Crea un agregador.
Ptr agregador =
Crear objeto (nombre de archivo, agregador de archivos :: COMMA_SEPARATED);

Se establecen los atributos de FileAggregator.

// el agregador debe estar encendido
agregador-> Habilitar ();

A continuación, se calculan los valores 2-D y cada uno se escribe individualmente en el
FileAggregator usando el Write2d () función.

doble tiempo;
valor doble;

// Crea el conjunto de datos 2-D.
para (tiempo = -5.0; tiempo <= +5.0; tiempo + = 1.0)
{
// Calcula la curva 2-D
//
/ / 2
// valor = tiempo.
//
valor = tiempo * tiempo;

// Agrega este punto a la trama.
agregador-> Write2d (datasetContext, tiempo, valor);
}

// Deshabilitar el registro de datos para el agregador.
agregador-> Desactivar ();
}

El siguiente archivo de texto con 2 columnas de valores formateados también se creó utilizando el
ejemplo.

Tiempo = -5.000e + 00 Valor = 25
Tiempo = -4.000e + 00 Valor = 16
Tiempo = -3.000e + 00 Valor = 9
Tiempo = -2.000e + 00 Valor = 4
Tiempo = -1.000e + 00 Valor = 1
Tiempo = 0.000e + 00 Valor = 0
Tiempo = 1.000e + 00 Valor = 1
Tiempo = 2.000e + 00 Valor = 4
Tiempo = 3.000e + 00 Valor = 9
Tiempo = 4.000e + 00 Valor = 16
Tiempo = 5.000e + 00 Valor = 25

Este código del ejemplo muestra cómo construir FileAggregator como se discutió
anterior.

vacío CreateFormattedFile ()
{
Using namespace std;

string fileName = "file-aggregator-formatted-values.txt";
string datasetContext = "Conjunto de datos / Contexto / Cadena";

// Cree un agregador que tendrá valores formateados.
Ptr agregador =
Crear objeto (fileName, FileAggregator :: FORMATTED);

Se establecen los atributos de FileAggregator, incluida la cadena de formato de estilo C que se utilizará.

// Establece el formato de los valores.
agregador-> Set2dFormat ("Tiempo =% .3e \ tValue =% .0f");

// el agregador debe estar encendido
agregador-> Habilitar ();

A continuación, se calculan los valores 2-D y cada uno se escribe individualmente en el
FileAggregator usando el Write2d () función.

doble tiempo;
valor doble;

// Crea el conjunto de datos 2-D.
para (tiempo = -5.0; tiempo <= +5.0; tiempo + = 1.0)
{
// Calcula la curva 2-D
//
/ / 2
// valor = tiempo.
//
valor = tiempo * tiempo;

// Agrega este punto a la trama.
agregador-> Write2d (datasetContext, tiempo, valor);
}

// Deshabilitar el registro de datos para el agregador.
agregador-> Desactivar ();
}

Adaptadores
Esta sección detalla las funcionalidades proporcionadas por la clase Adapter a un ns-3
simulación. Esta sección está dirigida a usuarios interesados ​​en desarrollar simulaciones con el
ns-3 herramientas y utilizando el marco de recopilación de datos, del cual la clase Adaptador es parte,
para generar salida de datos con los resultados de su simulación.

Nota: el término 'adaptador' también puede escribirse 'adaptador'; elegimos la ortografía alineada
con el estándar C ++.

Adaptador Descripción General
Se utiliza un adaptador para realizar conexiones entre diferentes tipos de objetos DCF.

Hasta la fecha, se ha implementado un adaptador:

· Adaptador TimeSeries

Hora de grado comercial Adaptador
TimeSeriesAdaptor permite que las sondas se conecten directamente a los agregadores sin necesidad de
Coleccionista en el medio.

Ambos ayudantes DCF implementados utilizan TimeSeriesAdaptors para tomar
valores de diferentes tipos y la salida de la hora actual más el valor con ambos convertidos
a dobles.

El papel de la clase TimeSeriesAdaptor es el de un adaptador, que toma valores sin procesar
sondear datos de diferentes tipos y generar una tupla de dos valores dobles. El primero es un
marca de tiempo, que puede establecerse en diferentes resoluciones (por ejemplo, segundos, milisegundos, etc.) en
el futuro, pero que actualmente está codificado en Segundos. El segundo es la conversión de un
valor no doble a un valor doble (posiblemente con pérdida de precisión).

Alcance / Limitaciones
Esta sección analiza el alcance y las limitaciones del marco de recopilación de datos.

Actualmente, solo estas sondas se han implementado en DCF:

· Sonda booleana

· Doble sonda

· Uinteger8Probe

· Uinteger16Probe

· Uinteger32Probe

· Sonda de tiempo

· Sonda de paquetes

· Sonda de paquete de aplicación

· Sonda de paquetes Ipv4

Actualmente, no hay recopiladores disponibles en el DCF, aunque hay un BasicStatsCollector bajo
el desarrollo sostenible.

Actualmente, solo estos agregadores se han implementado en DCF:

· Agregador Gnuplot

· Agregador de archivos

Actualmente, solo este Adaptador se ha implementado en DCF:

Adaptador de serie temporal.

Futuro Trabaja
En esta sección se analiza el trabajo futuro que se realizará en el marco de recopilación de datos.

Aquí hay algunas cosas que aún deben hacerse:

· Conecta más fuentes de rastreo en ns-3 código para obtener más valores del simulador.

· Implementar más tipos de sondas de las que existen actualmente.

· Implemente más que el único recopilador 2-D actual, BasicStatsCollector.

· Implementar más agregadores.

· Implementar algo más que adaptadores.

DSDV ENRUTAMIENTO

El protocolo de enrutamiento de vector de distancia secuenciado por destino (DSDV) es un
Protocolo de enrutamiento controlado por tablas para MANET desarrollado por Charles E. Perkins y Pravin
Bhagwat en 1994. Utiliza el recuento de saltos como métrica en la selección de rutas.

Este modelo fue desarrollado por los ResiliNets Segun una investigacion grupo de XNUMX en la Universidad de Kansas. A
existe un artículo sobre este modelo en este vídeo URL.

DSDV enrutamiento Descripción General
Tabla de enrutamiento DSDV: cada nodo mantendrá una tabla que enumera todos los demás nodos que tiene
conocido ya sea directamente o a través de algunos vecinos. Cada nodo tiene una sola entrada en el
tabla de ruteo. La entrada tendrá información sobre la dirección IP del nodo, la última conocida
número de secuencia y el recuento de saltos para llegar a ese nodo. Junto con estos detalles la tabla
también realiza un seguimiento del vecino nexthop para llegar al nodo de destino, la marca de tiempo de
la última actualización recibida para ese nodo.

El mensaje de actualización de DSDV consta de tres campos, Dirección de destino, Número de secuencia y
Número de saltos.

Cada nodo utiliza 2 mecanismos para enviar las actualizaciones de DSDV. Ellos son,

1.

Periódico Novedades
Las actualizaciones periódicas se envían después de cada m_periodicUpdateInterval (predeterminado: 15 s).
En esta actualización, el nodo difunde toda su tabla de enrutamiento.

2.

Desencadenar Novedades
Las actualizaciones de activación son pequeñas actualizaciones entre las actualizaciones periódicas. Estas actualizaciones
se envían cada vez que un nodo recibe un paquete DSDV que provocó un cambio en su
tabla de ruteo. El artículo original no mencionaba claramente cuándo y qué cambio.
en la tabla en caso de que se envíe una actualización DSDV. La implementación actual envía
realizar una actualización independientemente del cambio en la tabla de enrutamiento.

Las actualizaciones se aceptan según la métrica de un nodo en particular. El primer factor
lo que determina la aceptación de una actualización es el número de secuencia. Tiene que aceptar la actualización
si el número de secuencia del mensaje de actualización es mayor independientemente de la métrica. Si el
se recibe la actualización con el mismo número de secuencia, luego la actualización con la menor métrica (hopCount)
se le da prioridad.

En escenarios de gran movilidad, existe una alta probabilidad de fluctuaciones de ruta, por lo que tenemos la
concepto de tiempo de establecimiento ponderado donde una actualización con cambio en la métrica no será
ANUNCIADO A VECINOS. El nodo espera el tiempo de asentamiento para asegurarse de que no
recibir la actualización de su antiguo vecino antes de enviar esa actualización.

La implementación actual cubre todas las características anteriores de DSDV. La corriente
La implementación también tiene una cola de solicitudes para almacenar en búfer los paquetes que no tienen rutas para
destino. El valor predeterminado está configurado para almacenar en búfer hasta 5 paquetes por destino.

Referencias
Enlace al artículo: http://portal.acm.org/citation.cfm? doid = 190314.190336

DSR ENRUTAMIENTO

El protocolo Dynamic Source Routing (DSR) es un protocolo de enrutamiento reactivo diseñado específicamente
para uso en redes ad hoc inalámbricas de múltiples saltos de nodos móviles.

Este modelo fue desarrollado por los ResiliNets Segun una investigacion grupo de XNUMX en la Universidad de Kansas.

DSR enrutamiento Descripción General
Este modelo implementa la especificación básica del protocolo Dynamic Source Routing (DSR).
La implementación se basa en RFC 4728, con algunas extensiones y modificaciones al RFC
especificaciones.

DSR opera bajo demanda. Por lo tanto, nuestro modelo DSR almacena en búfer todos los paquetes mientras
Se difunde el paquete de solicitud de ruta (RREQ). Implementamos un búfer de paquetes en
dsr-rsendbuff.cc. La cola de paquetes implementa la recolección de basura de paquetes antiguos y un
límite de tamaño de la cola. Cuando el paquete se envía desde el búfer de envío, se pondrá en cola en
búfer de mantenimiento para el reconocimiento del siguiente salto.

El búfer de mantenimiento almacena los paquetes ya enviados y espera la
notificación de entrega de paquetes. El funcionamiento del protocolo depende en gran medida de un enlace roto
mecanismo de detección. Implementamos las tres heurísticas recomendadas basándonos en el RFC como
manera:

Primero, usamos la retroalimentación de la capa de enlace cuando es posible, que también es el mecanismo más rápido de
estos tres para detectar errores de enlace. Se considera que un enlace está roto si la transmisión de tramas
da como resultado una falla de transmisión para todos los reintentos. Este mecanismo está destinado a
enlaces y funciona mucho más rápido que en su ausencia. DSR puede detectar la capa de enlace
falla de transmisión y notifique que está rota. Se activará el nuevo cálculo de rutas
cuando sea necesario. Si el usuario no desea utilizar el reconocimiento de la capa de enlace, se puede ajustar mediante
establecer el atributo "LinkAcknowledgment" en falso en "dsr-routing.cc".

En segundo lugar, se debe utilizar el reconocimiento pasivo siempre que sea posible. El nodo se enciende
modo de recepción "promiscuo", en el que puede recibir paquetes no destinados a sí mismo, y
cuando el nodo asegura la entrega de ese paquete de datos a su destino, cancela la
temporizador de reconocimiento pasivo.

Por último, utilizamos un esquema de reconocimiento de capa de red para notificar la recepción de un paquete. Ruta
el paquete de solicitud no será reconocido ni retransmitido.

La implementación de Route Cache admite la recolección de elementos no utilizados de entradas antiguas y estados
máquina, según se define en la norma. Se implementa como contenedor de mapas STL. La clave es la
Dirección IP de destino.

DSR opera con acceso directo al encabezado IP y opera entre la red y el transporte
capa. Cuando el paquete se envía desde la capa de transporte, se pasa a sí mismo a DSR y DSR
se adjunta el encabezado.

Tenemos dos mecanismos de almacenamiento en caché: caché de ruta y caché de enlaces. La caché de ruta guarda todo
ruta en el caché. Las rutas se ordenan según el recuento de saltos, y siempre que una ruta es
no se puede utilizar, cambiamos a la siguiente ruta. La caché de enlaces es un poco mejor
diseño en el sentido de que utiliza diferentes subrutas y utiliza la caché de enlace implementada utilizando
Algoritmo Dijsktra, y esta parte es implementada por Song Luan[email protected]>.

Las siguientes optimizaciones de protocolo opcionales no se implementan:

· Estado de flujo

· Banderas de primer salto externo (F), último salto externo (L)

· Manejo de opciones DSR desconocidas

·

Two tipos of error encabezados:

1. opción de estado de flujo no admitido

2. opción no admitida (no sucederá en la simulación)

DSR actualización in ns-3.17
Originalmente usamos "TxErrHeader" en Ptr para indicar el error de transmisión de un
paquete específico en la capa de enlace, sin embargo, no estaba funcionando correctamente ya que incluso cuando
el paquete se descartó, este encabezado no se registró en el archivo de seguimiento. Solíamos un
ruta diferente en la implementación del mecanismo de notificación de la capa de enlace. Miramos en el
rastrear el archivo al encontrar el evento de recepción de paquetes. Si encontramos un evento de recepción para los datos
paquete, lo contamos como el indicador de una entrega de datos exitosa.

Conveniente parámetros
+ ------------------------- + ----------------------- ------------- + ------------- +
| Parámetro | Descripción | Por defecto |
+ ========================== + ====================== ============== + ============= +
| MaxSendBuffLen | Número máximo de paquetes que pueden | 64 |
| | almacenarse en el búfer de envío | |
+ ------------------------- + ----------------------- ------------- + ------------- +
| MaxSendBuffTime | Los paquetes de tiempo máximo se pueden poner en cola | Segundos(30) |
| | en el búfer de envío | |
+ ------------------------- + ----------------------- ------------- + ------------- +
| MaxMaintLen | Número máximo de paquetes que pueden | 50 |
| | almacenarse en búfer de mantenimiento | |
+ ------------------------- + ----------------------- ------------- + ------------- +
| MaxMaintTime | Los paquetes de tiempo máximo se pueden poner en cola | Segundos(30) |
| | en búfer de mantenimiento | |
+ ------------------------- + ----------------------- ------------- + ------------- +
| MaxCacheLen | Número máximo de entradas de ruta | 64 |
| | que se puede almacenar en la memoria caché de la ruta | |
+ ------------------------- + ----------------------- ------------- + ------------- +
| RouteCacheTimeout | Tiempo máximo que puede la caché de ruta | Segundos(300) |
| | estar en cola en la memoria caché de la ruta | |
+ ------------------------- + ----------------------- ------------- + ------------- +
| RreqRetries | Número máximo de retransmisiones | 16 |
| | para solicitar el descubrimiento de una ruta | |
+ ------------------------- + ----------------------- ------------- + ------------- +
| CacheType | Use Link Cache o use Path Cache | "LinkCache" |
| | | |
+ ------------------------- + ----------------------- ------------- + ------------- +
| Reconocimiento de enlace | Habilitar reconocimiento de capa de enlace | Verdadero |
| | mecanismo | |
+ ------------------------- + ----------------------- ------------- + ------------- +

Implementación modificación
·

La DsrFsEncabezado tiene adicional 3 campos: mensaje tipo, fuente carné de identidad, destino carné de identidad, y these
cambios only para Postprocesamiento

1. El tipo de mensaje se utiliza para identificar el paquete de datos del paquete de control.

2. source id se utiliza para identificar la fuente real del paquete de datos, ya que tenemos
para entregar el paquete salto a salto y el encabezado ipv4 no lleva el
dirección IP de origen y destino según sea necesario

3. La identificación de destino es por la misma razón de arriba

· El encabezado de respuesta de ruta no está alineado con la palabra en DSR RFC, cámbielo a alineado con la palabra en
implementación

· DSR funciona como un encabezado de compensación entre el transporte y el protocolo de red, necesita su propio
mecanismo de reenvío, estamos cambiando la transmisión de paquetes a la entrega salto por salto, por lo que
agregamos dos campos en el encabezado fijo dsr para notificar la entrega del paquete

Current Ruta Cache implementación
Esta implementación utilizó "caché de ruta", que es fácil de implementar y garantiza que no haya bucles
caminos:

· La caché de ruta tiene una política de expiración automática

· La caché guarda varias entradas de ruta para un destino determinado y ordena las entradas
basado en recuentos de lúpulos

· MaxEntriesEachDst se puede ajustar para cambiar el máximo de entradas guardadas para una sola
destino

· Al agregar varias rutas para un destino, la ruta se compara en función de
tiempo de recuento de saltos y expiración, el que tiene menos recuento de saltos o una ruta relativamente nueva es
favorecido

· La implementación futura puede incluir "caché de enlaces" como otra posibilidad

DSR Instrucciones
Se debe tener en cuenta lo siguiente al ejecutar DSR como protocolo de enrutamiento:

· NodeTraversalTime es el tiempo que lleva atravesar dos nodos vecinos y debe ser
elegido para adaptarse al rango de transmisión

· PassiveAckTimeout es el tiempo que un paquete en el búfer de mantenimiento espera a pasivo
reconocimiento, normalmente establecido como dos tiempos de NodeTraversalTime

· RouteCacheTimeout debe establecerse en un valor menor cuando la velocidad de los nodos aumenta.
El valor predeterminado es 300 s.

Ayudante
Para que un nodo ejecute DSR, la forma más sencilla sería utilizar DsrHelper y DsrMainHelpers
en su guión de simulación. Por ejemplo:

DsrHelper dsr;
DsrMainHelper dsrMain;
dsrMain.Install (dsr, adhocNodes);

Los scripts de ejemplo dentro src / dsr / examples / demostrar el uso de nodos basados ​​en DSR en
diferentes escenarios. La fuente de ayuda se puede encontrar dentro
src / dsr / helper / dsr-main-helper. {h, cc} y src / dsr / helper / dsr-helper. {h, cc}

Ejemplos
El ejemplo se puede encontrar en src / dsr / examples /:

· Dsr.cc utiliza DSR como protocolo de enrutamiento dentro de un entorno MANETs tradicional [3].

DSR también está integrado en el caso de comparación de enrutamiento en ejemplos / enrutamiento /:

· manet-enrutamiento-compare.cc es un caso de comparación con protocolos de enrutamiento MANET integrados y
puede generar sus propios resultados.

Validación
Este modelo ha sido probado de la siguiente manera:

· Se han escrito pruebas unitarias para verificar los aspectos internos de DSR. Esto se puede encontrar en
src / dsr / test / dsr-test-suite.cc. Estas pruebas verifican si los métodos dentro del módulo DSR
que se ocupan del búfer de paquetes, los encabezados funcionan correctamente.

· Se han probado casos de simulación similares a [3] y tienen resultados comparables.

· Manet-routing-compare.cc se ha utilizado para comparar DSR con tres de otros enrutamiento
Protocolos.

Se presentó un documento sobre estos resultados en el Taller sobre ns-3 en 2011.

Limitaciones
El modelo no es totalmente compatible con RFC 4728. Como ejemplo, el encabezado de tamaño fijo Dsr tiene
se ha ampliado y es cuatro octectos más largo que la especificación RFC. Como consecuencia,
Wireshark no puede decodificar correctamente los encabezados DSR.

El modelo de plena conformidad con la RFC está previsto para el futuro.

Referencias
[1] Papel original: http://www.monarch.cs.rice.edu/monarch-papers/dsr-chapter00.pdf

[2] RFC 4728 http://www6.ietf.org/rfc/rfc4728.txt

[3] Documento de comparación de Broch: http://www.monarch.cs.rice.edu/monarch-papers/mobicom98.ps

EMULACIÓN Descripción

ns-3 ha sido diseñado para su integración en entornos de pruebas y máquinas virtuales. Nosotros
han abordado esta necesidad proporcionando dos tipos de dispositivos de red. El primer tipo de dispositivo
es un dispositivo de red descriptor de archivos (DispositivoFdNet), que es un tipo de dispositivo genérico que puede
leer y escribir desde un descriptor de archivo. Al asociar este descriptor de archivo con diferentes
elementos en el sistema host, se pueden proporcionar diferentes capacidades. Por ejemplo, el
FdNetDevice se puede asociar con un socket de paquete subyacente para proporcionar emulación
capacidades. Esto permite ns-3 simulaciones para enviar datos en una red "real". El segundo
amable, llamado Pulsa para buscar dispositivo de red permite que un anfitrión "real" participe en un ns-3 simulación como
si fuera uno de los nodos simulados. Un ns-3 La simulación se puede construir con cualquier
combinación de dispositivos simulados o emulados.

Nota: Antes de ns-3.17, la capacidad de emulación era proporcionada por un dispositivo especial llamado
an emú NetDevice; el emú NetDevice ha sido reemplazado por el DispositivoFdNet.

Uno de los casos de uso que queremos admitir es el de un banco de pruebas. Un ejemplo concreto de
entorno de este tipo es el banco de pruebas ORBIT. ORBIT es un emulador de laboratorio / prueba de campo
red organizada como una cuadrícula bidimensional de 400 nodos de radio 802.11. Nos integramos con
ORBITA utilizando su proceso de "creación de imágenes" para cargar y ejecutar ns-3 simulaciones en ORBIT
formación. Podemos usar nuestro DispositivoEmuFdNet para conducir el hardware en el banco de pruebas y podemos
acumular resultados utilizando el ns-3 funciones de rastreo y registro, o el nativo
Técnicas de recopilación de datos ORBIT. Ver http://www.orbit-lab.org/ para obtener detalles sobre ORBIT
testbed.

Una simulación de este tipo se muestra en la siguiente figura:
[imagen] Ejemplo de implementación de la emulación del banco de pruebas ... UNINDENT

Puede ver que hay hosts separados, cada uno de los cuales ejecuta un subconjunto de un "global"
simulación. En lugar de un ns-3 canal que conecta los hosts, utilizamos hardware real
proporcionado por el banco de pruebas. Esto permite ns-3 aplicaciones y pilas de protocolos adjuntas a un
nodo de simulación para comunicarse a través de hardware real.

Esperamos que el uso principal de esta configuración sea generar
resultados experimentales en un entorno de red del mundo real que incluye todos los ns-3
herramientas de rastreo, registro, visualización y recopilación de estadísticas.

En lo que puede verse como una configuración esencialmente inversa, permitimos máquinas "reales"
ejecutar aplicaciones nativas y pilas de protocolos para integrarse con un ns-3 simulación.
Esto permite la simulación de grandes redes conectadas a una máquina real, y también
habilita la virtualización. Una simulación de este tipo se muestra en la siguiente figura:
[imagen] Descripción general de la implementación del canal emulado ... UNINDENT

Aquí, verá que hay un solo host con varias máquinas virtuales en ejecución
en eso. Un ns-3 La simulación se muestra ejecutándose en la máquina virtual que se muestra en el centro de
la figura. Esta simulación tiene varios nodos con asociados ns-3 aplicaciones y
pilas de protocolos que están hablando con un ns-3 canal a través de simulación nativa ns-3 red
dispositivos.

También hay dos máquinas virtuales que se muestran en el extremo izquierdo y en el extremo derecho de la figura.
Estas máquinas virtuales ejecutan pilas de protocolos y aplicaciones nativas (Linux). La VM es
conectado a la simulación mediante un dispositivo de red Tap de Linux. El controlador de modo de usuario para el
El dispositivo Tap se crea una instancia en la simulación y se adjunta a un nodo proxy que
representa la VM nativa en la simulación. Estos controladores permiten que los dispositivos Tap en el
VM nativas para comportarse como si fueran ns-3 net en la simulación VM. Esta en
a su vez, permite que el software nativo y los conjuntos de protocolos en las VM nativas crean que
están conectados al simulado ns-3 canal.

Esperamos que el caso de uso típico de este entorno sea analizar el comportamiento de
aplicaciones nativas y conjuntos de protocolos en presencia de grandes ns-3
redes.

Archive Descriptor dispositivo de red
La src / fd-net-device módulo proporciona el DispositivoFdNet clase, que es capaz de leer y
escribir tráfico utilizando un descriptor de archivo proporcionado por el usuario. Este descriptor de archivo puede ser
asociado a un dispositivo TAP, a un socket sin procesar, a un proceso de espacio de usuario que genera / consume
tráfico, etc. El usuario tiene total libertad para definir cómo se genera el tráfico externo y
ns-3 el tráfico se consume.

Se pueden proporcionar diferentes mecanismos para asociar una simulación al tráfico externo a través de
clases de ayuda. Se proporcionan tres ayudantes específicos:

· EmuFdNetDeviceHelper (para asociar el ns-3 dispositivo con un dispositivo físico en el host
máquina)

· TapFdNetDeviceHelper (para asociar el dispositivo ns-3 con el descriptor de archivo de un toque
dispositivo en la máquina host)

· PlanteLabFdNetDeviceHelper (para automatizar la creación de dispositivos tap en los nodos PlanetLab,
permitiendo ns-3 simulaciones que pueden enviar y recibir tráfico a través de Internet utilizando
Recurso PlanetLab.

Modelo Descripción
El código fuente de este módulo reside en el directorio src / fd-net-device.

El FdNetDevice es un tipo especial de ns-3 NetDevice que lee el tráfico hacia y desde un archivo
descriptor. Es decir, a diferencia de los objetos NetDevice de simulación pura que escriben marcos en y
desde un canal simulado, este FdNetDevice dirige los fotogramas fuera de la simulación a un archivo
descriptor. El descriptor de archivo puede estar asociado a un dispositivo Linux TUN / TAP, a un socket,
oa un proceso de espacio de usuario.

Depende del usuario de este dispositivo proporcionar un descriptor de archivo. El tipo de archivo
El descriptor que se proporciona determina lo que se está modelando. Por ejemplo, si el archivo
El descriptor proporciona un enchufe sin procesar a una tarjeta WiFi en la máquina host, siendo el dispositivo
modelado es un dispositivo WiFi.

Desde la "parte superior" conceptual del dispositivo mirando hacia abajo, se ve al nodo simulado como
un dispositivo que admite una dirección MAC IEEE de 48 bits que se puede puentear, admite transmisión y
utiliza IPv4 ARP o IPv6 Neighbor Discovery, aunque estos atributos se pueden ajustar en un
por caso de uso.

Design
La implementación de FdNetDevice hace uso de un objeto lector, extendido desde el Lector de Fd
clase en el ns-3 src / core módulo, que gestiona un hilo separado del principal ns-3
hilo de ejecución, para leer el tráfico del descriptor de archivo.

Tras la invocación del Dispositivo de inicio método, el objeto lector se inicializa e inicia el
hilo de lectura. Antes del inicio del dispositivo, se debe asociar previamente un descriptor de archivo a
el FdNetDevice con el EstablecerDescriptorDeArchivo invocación.

La creación y configuración del descriptor de archivo se puede dejar a varios ayudantes,
descrito con más detalle a continuación. Cuando se hace esto, la invocación de EstablecerDescriptorDeArchivo is
responsabilidad del ayudante y no debe ser invocado directamente por el usuario.

Al leer un marco entrante del descriptor de archivo, el lector pasará el marco a
los Recibir devolución de llamada método, cuya tarea es programar la recepción de la trama por el
dispositivo como ns-3 evento de simulación. Dado que el nuevo marco se pasa del hilo del lector a
la principal ns-3 hilo de simulación, los problemas de seguridad del hilo se evitan utilizando el
HorarioConContexto llamar en lugar del regular Programa llamada.

Para evitar abrumar al programador cuando la velocidad de datos entrantes es demasiado alta,
El contador se mantiene con el número de fotogramas que están programados actualmente para ser recibidos por
el dispositivo. Si este contador alcanza el valor dado por el RxQueueSize Atributo en el
dispositivo, la nueva trama se eliminará silenciosamente.

La recepción real de la nueva trama por parte del dispositivo ocurre cuando el programado FordwarUp
el método es invocado por el simulador. Este método actúa como si hubiera llegado un nuevo marco de un
canal adjunto al dispositivo. Luego, el dispositivo desencapsula el marco, eliminando cualquier capa
2 encabezados y lo reenvía a las capas superiores de la pila de red del nodo. El Adelante
El método eliminará los encabezados del marco, de acuerdo con el tipo de encapsulación del marco definido por
los Modo de encapsulación atributo, e invocar la devolución de llamada de recepción pasando un paquete IP.

Un encabezado adicional, el encabezado PI, puede estar presente cuando el descriptor de archivo está asociado a un
Dispositivo TAP que se creó sin configurar el indicador IFF_NO_PI. Este encabezado adicional es
eliminado si Modo de encapsulación se establece en el valor DIXPI.

En la dirección opuesta, los paquetes generados dentro de la simulación que se envían
a través del dispositivo, se pasará al ENVIAR método, que a su vez invocará el
Enviado desde método. El último método agregará los encabezados de capa 2 necesarios, y simplemente
escriba el marco recién creado en el descriptor de archivo.

<b></b><b></b> y Limitaciones
Se advierte a los usuarios de este dispositivo que no hay control de flujo en el archivo
límite del descriptor, cuando se utiliza en modo de emulación. Es decir, en un sistema Linux, si el
La velocidad de escritura de paquetes de red excede la capacidad del dispositivo físico subyacente para
almacenar los paquetes en búfer, se aplicará una contrapresión hasta la aplicación de escritura para evitar
pérdida de paquetes locales. No se proporciona tal control de flujo a través de la interfaz del descriptor de archivos,
por lo que los usuarios deben ser conscientes de esta limitación.

Como se explicó antes, el atributo RxQueueSize limita el número de paquetes que se pueden
pendiente de ser recibido por el dispositivo. Los fotogramas se leen del descriptor de archivo mientras
el número máximo de paquetes pendientes se eliminará silenciosamente.

El mtu del dispositivo tiene como valor predeterminado el valor MTU de Ethernet II. Sin embargo, se supone que los ayudantes
para establecer el mtu en el valor correcto para reflejar las características de la interfaz de red
asociado al descriptor de archivo. Si no se utiliza ningún ayudante, entonces la responsabilidad de
la configuración del valor de mtu correcto para el dispositivo recae en el usuario. El tamaño de la lectura
búfer en el lector de descriptor de archivo se establece en el valor mtu en el Dispositivo de inicio método.

La clase FdNetDevice actualmente admite tres modos de encapsulación, DIX para Ethernet II
tramas, LLC para tramas 802.2 LLC / SNAP y DIXPI para tramas Ethernet II con un
Cabecera TAP PI. Esto significa que se espera que el tráfico que atraviesa el descriptor de archivo sea
Compatible con Ethernet II. Adjuntar un FdNetDevice a una interfaz inalámbrica es posible como
siempre que el controlador proporcione tramas Ethernet II a la API de socket. Tenga en cuenta que para asociar
un FdNetDevice a una tarjeta inalámbrica en modo ad-hoc, se debe configurar la dirección MAC del dispositivo
a la dirección MAC de la tarjeta real; de lo contrario, cualquier tráfico entrante será una dirección MAC falsa.
descartado por el conductor.

Como se mencionó anteriormente, se proporcionan tres ayudantes con el módulo fd-net-device. Cada
El asistente individual (tipo de descriptor de archivo) puede tener limitaciones de plataforma. Por ejemplo,
roscado, modo de simulación en tiempo real y la capacidad de crear dispositivos TUN / TAP son
requisitos previos para utilizar los ayudantes proporcionados. El soporte para estos modos se puede encontrar en el
salida de la waf configurar paso, por ejemplo:

Primitivas de subprocesamiento: habilitado
Simulador en tiempo real: habilitado
Dispositivo de red emulado: habilitado
Tap Bridge: habilitado

Es importante mencionar que al probar el DispositivoFdNet hemos encontrado un límite superior
límite de rendimiento de TCP cuando se utilizan enlaces Ethernet de 1 Gb de 60 Mbps. Este límite es más
probablemente debido a la potencia de procesamiento de las computadoras involucradas en las pruebas.

Uso
El patrón de uso de este tipo de dispositivo es similar al de otros dispositivos de red con ayudantes.
que se instalan en punteros de nodo o contenedores de nodo. Al usar la base Ayudante de dispositivo FdNet
el usuario es responsable de crear y configurar el descriptor de archivo por sí mismo.

FdNetDeviceHelperfd;
Dispositivos NetDeviceContainer = fd.Install (nodos);

// generación de descriptor de archivo
...

dispositivo-> SetFileDescriptor (fd);

Por lo general, se utilizará un FdNetDevice para interactuar con el sistema host. En estos casos
es casi seguro que el usuario querrá ejecutar en modo de emulación en tiempo real y
habilitar cálculos de suma de comprobación. Las declaraciones típicas del programa son las siguientes:

GlobalValue :: Bind ("SimulatorImplementationType", StringValue ("ns3 :: RealtimeSimulatorImpl"));
GlobalValue :: Bind ("ChecksumEnabled", BooleanValue (verdadero));

La forma más sencilla de configurar un experimento que interactúe con un sistema host Linux es que el usuario
los emú y Pulsa para buscar ayudantes. Quizás la parte más inusual de estas implementaciones de ayuda
se relaciona con el requisito de ejecutar parte del código con permisos de superusuario.
En lugar de obligar al usuario a ejecutar toda la simulación como root, proporcionamos una pequeña
programa "creador" que se ejecuta como root y hace que funcionen los sockets de alto permiso necesarios.
La forma más sencilla de establecer los privilegios adecuados para los programas "creadores" es habilitando el
--habilitar-sudo bandera al realizar waf configurar.

Hacemos algo similar tanto para el emú así como el Pulsa para buscar dispositivos. La opinión de alto nivel es que
los CreateFileDescriptorCreateFileDescriptor El método crea un socket, bifurcaciones y un interproceso local (Unix)
ejecuta el programa de creación pequeña. El pequeño programa, que se ejecuta como suid root, crea un
raw socket y devuelve el descriptor de archivo de socket raw a través del socket Unix que es
se le pasa como parámetro. El socket sin formato se pasa como un mensaje de control (a veces
llamados datos auxiliares) de tipo SCM_RIGHTS.

Ayudantes
EmuFdNetDeviceHelper
EmuFdNetDeviceHelper crea un socket sin procesar a un dispositivo físico subyacente y
proporciona el descriptor de socket al FdNetDevice. Esto permite ns-3 simulación para
leer fotogramas y escribir fotogramas en un dispositivo de red en el host.

El ayudante de emulación permite integrar de forma transparente un ns-3 nodo en un
red compuesta por nodos reales.

+ ---------------------- + + ----------------------- +
| anfitrión 1 | | anfitrión 2 |
+ ---------------------- + + ----------------------- +
| simulación ns-3 | | |
+ ---------------------- + | Linux |
| Nodo ns-3 | | Pila de red |
| + ---------------- + | | + ---------------- + |
| | TCP ns-3 | | | | TCP | |
| + ---------------- + | | + ---------------- + |
| | IP ns-3 | | | | PI | |
| + ---------------- + | | + ---------------- + |
| | DispositivoFdNet | | | | | |
| | 10.1.1.1 | | | | | |
| + ---------------- + | | + ETHERNET + |
| | toma cruda | | | | | |
| - + ---------------- + - | | + ---------------- + |
| | eth0 | | | | eth0 | |
+ ------- + ------ + ------- + + -------- + ------ + ------- +

10.1.1.11 10.1.1.12

| |
+ ---------------------------- +

Este ayudante reemplaza la funcionalidad del Dispositivo EmuNet encontrado en ns-3 antes de ns-3.17,
al llevar este tipo de dispositivo al marco común de FdNetDevice. El
Dispositivo EmuNet fue desaprobado a favor de este nuevo ayudante.

El dispositivo está configurado para realizar suplantación de MAC para separar el tráfico de la red de simulación
de otro tráfico de red que pueda fluir hacia y desde el host.

Se puede utilizar este ayudante en una situación de banco de pruebas donde el host en el que se realiza la simulación
La ejecución tiene una interfaz de interés específica que impulsa el hardware del banco de pruebas. Lo harías
También es necesario configurar esta interfaz específica en modo promiscuo y proporcionar un
nombre del dispositivo al ns-3 simulación. Además, la descarga de hardware de la segmentación y
Las sumas de comprobación deben estar deshabilitadas.

El asistente solo funciona si la interfaz subyacente está activa y en modo promiscuo. Paquetes
se enviará a través del dispositivo, pero usamos la suplantación de MAC. Las direcciones MAC serán
generado (de forma predeterminada) utilizando el identificador único organizacional (OUI) 00:00:00 como un
base. Este código de proveedor no está asignado a ninguna organización y, por lo tanto, no debe entrar en conflicto con
cualquier hardware real.

Siempre depende del usuario determinar si el uso de estas direcciones MAC está bien en su
red y no entrará en conflicto con nada más (incluida otra simulación que utilice
dispositivos) en su red. Si está utilizando la configuración de FdNetDevice emulada en
simulaciones por separado, debe considerar los problemas de asignación de direcciones MAC globales y asegurarse
que las direcciones MAC son únicas en todas las simulaciones. El dispositivo de red emulado respeta el
Dirección MAC proporcionada en el Dirección atributo para que pueda hacer esto manualmente. Para mayor
simulaciones, es posible que desee configurar el OUI en la función de asignación de dirección MAC.

Antes de invocar el Instalar método, el nombre correcto del dispositivo debe configurarse en el
ayudante usando el EstablecerNombreDeDispositivo método. El nombre del dispositivo es necesario para identificar qué
Se debe utilizar un dispositivo físico para abrir el enchufe sin procesar.

EmuFdNetDeviceHelper emu;
emu.SetDeviceName (nombre de dispositivo);
Dispositivos NetDeviceContainer = emu.Install (nodo);
Ptr dispositivo = dispositivos.Get (0);
dispositivo-> SetAttribute ("Dirección", Mac48AddressValue (Mac48Address :: Allocate ()));

TapFdNetDeviceHelper
Un dispositivo Tap es un tipo especial de dispositivo Linux para el cual un extremo del dispositivo parece
el kernel como un net_device virtual, y el otro extremo se proporciona como un descriptor de archivo para
espacio de usuario. Este descriptor de archivo se puede pasar a FdNetDevice. Paquetes reenviados a
el dispositivo TAP por el kernel se mostrará en el FdNetDevice en ns-3.

Los usuarios deben tener en cuenta que este uso de dispositivos TAP es diferente al proporcionado por el
TapBridge NetDevice encontrado en src / tap-bridge. El modelo de este ayudante es el siguiente:

+ ------------------------------------- +
| anfitrión |
+ ------------------------------------- +
| simulación ns-3 | |
+ ---------------------- + |
| Nodo ns-3 | |
| + ---------------- + | |
| | TCP ns-3 | | |
| + ---------------- + | |
| | IP ns-3 | | |
| + ---------------- + | |
| | DispositivoFdNet | | |
| - + ---------------- + - + + ------ + |
| | toque | | eth0 | |
| + ------ + + ------ + |
| 192.168.0.1 | |
+ ------------------------------- | ----- +
|
|
------------ (Internet) -----

En lo anterior, la configuración requiere que el host pueda reenviar el tráfico
generado por la simulación a Internet.

El modelo en TapBridge (en otro módulo) es el siguiente:

+ -------- +
| linux |
| anfitrión | + ---------- +
| ------ | | fantasma |
| aplicaciones | | nodo |
| ------ | | -------- |
| pila | | IP | + ---------- +
| ------ | | pila | | nodo |
| TAP | | ========== | | -------- |
| dispositivo | <----- IPC ------> | toque | | IP |
+ -------- + | puente | | pila |
| -------- | | -------- |
| ns-3 | | ns-3 |
| neto | | neto |
| dispositivo | | dispositivo |
+ ---------- + + ---------- +
|| ||
+ --------------------------- +
| canal ns-3 |
+ --------------------------- +

En lo anterior, los paquetes en cambio atraviesan ns-3 NetDevices y Canales.

El patrón de uso de este ejemplo es que el usuario establece la dirección MAC y (o
ambas) las direcciones y máscaras IPv4 e IPv6 en el dispositivo, y el encabezado PI si es necesario.
Por ejemplo:

Asistente de TapFdNetDeviceHelper;
ayudante.SetDeviceName (nombreDeDispositivo);
ayudante.SetModePi (modoPi);
ayudante.SetTapIpv4Address (tapIp);
ayudante.SetTapIpv4Mask (tapMask);
...
helper.Install (nodo);

PlanetLabFdNetDeviceHelper
PlanetLab es un banco de pruebas de red distribuida mundialmente compuesto por nodos conectados al
Internet. Ejecución de simulaciones ns-3 en nodos PlanetLab utilizando el
PlanetLabFdNetDeviceHelper permite enviar tráfico simulado generado por ns-3 directamente a
La Internet. Esta configuración puede resultar útil para validar los protocolos de Internet ns-3 u otros
protocolos implementados en ns-3.

Para ejecutar experimentos utilizando los nodos de PlanetLab, es necesario tener una cuenta de PlanetLab. Solo
Los miembros de las instituciones asociadas de PlanetLab pueden obtener dichas cuentas (para obtener más información
visite http://www.planet-lab.org/ or http://www.planet-lab.eu ). Una vez que la cuenta es
obtenido, un PlanetLab rebanada debe solicitarse para realizar experimentos. Una rebanada
representa una unidad de experimento relacionada con un grupo de usuarios de PlanetLab y se puede asociar
a máquinas virtuales en diferentes nodos PlanetLab. Las rebanadas también se pueden personalizar agregando
etiquetas de configuración (esto lo hacen los administradores de PlanetLab).

PlanetLabFdNetDeviceHelper crea dispositivos TAP en nodos PlanetLab utilizando
PlanetLab (es decir, el sistema vsys) y asocia el dispositivo TAP a un
FdNetDevice en ns-3. La funcionalidad proporcionada por este ayudante es similar a la
proporcionado por FdTapNetDeviceHelper, excepto que los mecanismos subyacentes para crear el
Los dispositivos TAP son diferentes.

+ ------------------------------------- +
| Anfitrión de PlanetLab |
+ ------------------------------------- +
| simulación ns-3 | |
+ ---------------------- + |
| Nodo ns-3 | |
| + ---------------- + | |
| | TCP ns-3 | | |
| + ---------------- + | |
| | IP ns-3 | | |
| + ---------------- + | |
| | DispositivoFdNet | | |
| - + ---------------- + - + + ------ + |
| | toque | | eth0 | |
| + ------ + + ------ + |
| 192.168.0.1 | |
+ ------------------------------- | ----- +
|
|
------------ (Internet) -----

Para poder asignar direcciones IPv4 privadas a los dispositivos TAP, los titulares de cuentas
debe solicitar el vsys_vnet que los administradores de PlanetLab agreguen a su segmento.
La etiqueta vsys_vnet está asociada al segmento de red privada y solo las direcciones de este
El segmento se puede utilizar en experimentos.

La sintaxis utilizada para crear un dispositivo TAP con este ayudante es similar a la utilizada para el
ayudantes descritos anteriormente:

Ayudante PlanetLabFdNetDeviceHelper;
ayudante.SetTapIpAddress (tapIp);
ayudante.SetTapMask (tapMask);
...
helper.Install (nodo);

Los nodos PlanetLab tienen una distribución basada en Fedora, por lo que ns-3 se puede instalar siguiendo las
instrucciones para la instalación de ns-3 Linux.

Atributos
La DispositivoFdNet proporciona una serie de atributos:

· Dirección: La dirección MAC del dispositivo

· Empiece a promover la campaña: La hora de inicio de la simulación para hacer girar el hilo del dispositivo

· Parada: La hora de inicio de la simulación para detener el subproceso del dispositivo.

· Modo de encapsulación: Formato de encapsulación de capa de enlace

·

RxQueueTamaño: La buffer tamaño of los read cola on los presentar descriptor
hilo (predeterminado de 1000 paquetes)

Empiece a promover la campaña y Parada normalmente no es necesario especificarlo a menos que el usuario desee limitar el
tiempo durante el cual este dispositivo está activo. Dirección debe configurarse en algún tipo de
Dirección MAC si la simulación interactuará con otros dispositivos reales usando de alguna manera
direcciones MAC reales. Código típico:

dispositivo-> SetAttribute ("Dirección", Mac48AddressValue (Mac48Address :: Allocate ()));

Salida
El rastreo Ascii y PCAP se proporciona de manera similar al otro ns-3 Tipos de NetDevice, a través del
ayudantes, como (p. ej.):

:: EmuFdNetDeviceHelper emu; Dispositivos NetDeviceContainer = emu.Install (nodo);
emu.EnablePcap ("emu-ping", dispositivo, verdadero);

Se proporciona el conjunto estándar de orígenes de seguimiento de NetDevice a nivel de Mac.

· MaxTx: Fuente de seguimiento activada cuando ns-3 proporciona al dispositivo un nuevo marco para enviar

· MaxTxDrop: Rastrear la fuente si falla la escritura en el descriptor de archivo

· MaxPromiscRx: Siempre que se reciba un marco Mac válido

· MaxRx: Siempre que se reciba un marco Mac válido para este dispositivo

· Sniffer: Rastreador de paquetes no promiscuo

· PromiscSniffer: Rastreador de paquetes promiscuo (para rastros tipo tcpdump)

Ejemplos
Se proporcionan varios ejemplos:

· red-dummy.cc: Este ejemplo simple crea dos nodos y los interconecta con un
Canalización Unix pasando los descriptores de archivo del par de conectores al FdNetDevice
objetos de los respectivos nodos.

· red-ficticia-en-tiempo-real.cc: Igual que dummy-network.cc pero usa el simulador en tiempo real
implementnation en lugar del predeterminado.

· fd2fd-onoff.cc: Este ejemplo tiene como objetivo medir el rendimiento de FdNetDevice en
una pura simulación. Para este propósito, dos FdNetDevices, conectados a diferentes nodos pero en
una misma simulación, se conectan mediante un par de conectores. El tráfico TCP se envía a
saturación de velocidad de datos.

· fd-emu-onoff.cc: Este ejemplo tiene como objetivo medir el rendimiento de FdNetDevice
al usar EmuFdNetDeviceHelper para conectar el dispositivo simulado a un dispositivo real en
la máquina anfitriona. Esto se logra saturando el canal con tráfico TCP.

· fd-emu-ping.cc: Este ejemplo utiliza EmuFdNetDeviceHelper para enviar tráfico ICMP a través de un
canal real.

· fd-emu-udp-echo.cc: Este ejemplo utiliza EmuFdNetDeviceHelper para enviar tráfico UDP a través de
un canal real.

· fd-planetlab-ping.cc: Este ejemplo muestra cómo configurar un experimento para enviar ICMP
tráfico desde un nodo PlanetLab a Internet.

· fd-tap-ping.cc: Este ejemplo utiliza TapFdNetDeviceHelper para enviar tráfico ICMP a través de un
canal real.

Pulsa para buscar dispositivo de red
Tap NetDevice se puede utilizar para permitir que un sistema host o máquinas virtuales interactúen con
una simulación.

ToquePuente Modelo Descripción General
Tap Bridge está diseñado para integrar hosts de Internet "reales" (o más precisamente, hosts
que admiten dispositivos Tun / Tap) en simulaciones ns-3. El objetivo es hacer que parezca
nodo de host "real" en el sentido de que tiene un dispositivo de red ns-3 como dispositivo local. El concepto de
"host real" es un poco resbaladizo ya que el "host real" puede virtualizarse usando
tecnologías fácilmente disponibles como VMware, VirtualBox u OpenVZ.

Dado que, en esencia, estamos conectando las entradas y salidas de un dispositivo de red ns-3 al
entradas y salidas de un dispositivo Linux Tap net, llamamos a esta disposición un Tap Bridge.

Hay tres modos de funcionamiento básicos de este dispositivo disponibles para los usuarios. Básico
La funcionalidad es esencialmente idéntica, pero los modos son diferentes en detalles con respecto
cómo se crea y configura el arreglo; y qué dispositivos pueden vivir en qué lado de
el puente.

A estos tres modos los llamamos modos ConfigureLocal, UseLocal y UseBridge. La primera
"palabra" en el identificador de modo de caso camel indica quién tiene la responsabilidad de crear
y configurar los grifos. Por ejemplo, "Configurar" en el modo ConfigureLocal indica
que es el TapBridge el que tiene la responsabilidad de configurar el grifo. En usoLocal
modo y modos UseBridge, el prefijo "Usar" indica que se le pide al TapBridge que "Use"
una configuración existente.

En otras palabras, en el modo ConfigureLocal, TapBridge tiene la responsabilidad de crear
y configurar los dispositivos TAP. En los modos UseBridge o UseLocal, el usuario proporciona un
configuración y el TapBridge se adapta a esa configuración.

ToquePuente Configurar local Moda
En el modo ConfigureLocal, la configuración del dispositivo tap es ns-3
centrado en la configuración. La información de configuración se toma de un dispositivo en el ns-3
Se crea automáticamente una simulación y un dispositivo de derivación que coincide con los atributos ns-3. En
En este caso, se hace que una computadora Linux parezca como si estuviera conectada directamente a un
Red ns-3 simulada.

Esto se ilustra a continuación:

+ -------- +
| linux |
| anfitrión | + ---------- +
| ------ | | fantasma |
| aplicaciones | | nodo |
| ------ | | -------- |
| pila | | IP | + ---------- +
| ------ | | pila | | nodo |
| TAP | | ========== | | -------- |
| dispositivo | <----- IPC ------> | toque | | IP |
+ -------- + | puente | | pila |
| -------- | | -------- |
| ns-3 | | ns-3 |
| neto | | neto |
| dispositivo | | dispositivo |
+ ---------- + + ---------- +
|| ||
+ --------------------------- +
| canal ns-3 |
+ --------------------------- +

En este caso, el "dispositivo de red ns-3" en el "nodo fantasma" aparece como si realmente fuera
reemplazando el dispositivo TAP en el host Linux. La simulación ns-3 crea el dispositivo TAP en
el sistema operativo Linux subyacente y configura las direcciones IP y MAC del dispositivo TAP para que coincidan
los valores asignados al dispositivo de red ns-3 simulado. El enlace "IPC" que se muestra arriba es el
mecanismo de toque de red en el sistema operativo subyacente. Todo el arreglo actúa como un convencional
puente; sino un puente entre dispositivos que tienen la misma MAC e IP compartidas
Direcciones.

Aquí, el usuario no está obligado a proporcionar ninguna información de configuración específica para el
grifo. Ns-3 creará y configurará un dispositivo tap de acuerdo con sus valores predeterminados, y
el dispositivo tap tendrá su nombre asignado por el sistema operativo subyacente de acuerdo con
sus valores predeterminados.

Si el usuario tiene un requisito para acceder al dispositivo de grifo creado, opcionalmente puede
proporcione un atributo "DeviceName". En este caso, el dispositivo OS tap creado se denominará
en consecuencia.

El modo ConfigureLocal es el modo de funcionamiento predeterminado del Tap Bridge.

ToquePuente Usar local Moda
El modo UseLocal es bastante similar al modo ConfigureLocal. La diferencia significativa
es, como lo indica el nombre del modo, el TapBridge va a "Usar" un dispositivo de tap existente
previamente creado y configurado por el usuario. Este modo es particularmente útil cuando un
esquema de virtualización crea automáticamente dispositivos tap y ns-3 se utiliza para proporcionar
redes simuladas para esos dispositivos.

+ -------- +
| linux |
| anfitrión | + ---------- +
| ------ | | fantasma |
| aplicaciones | | nodo |
| ------ | | -------- |
| pila | | IP | + ---------- +
| ------ | | pila | | nodo |
| TAP | | ========== | | -------- |
| dispositivo | <----- IPC ------> | toque | | IP |
| MAC X | | puente | | pila |
+ -------- + | -------- | | -------- |
| ns-3 | | ns-3 |
| neto | | neto |
| dispositivo | | dispositivo |
| MAC Y | | MAC Z |
+ ---------- + + ---------- +
|| ||
+ --------------------------- +
| canal ns-3 |
+ --------------------------- +

En este caso, la dirección MAC preconfigurada del "dispositivo Tap" (MAC X) no será la
igual que el del "dispositivo de red ns-3" (MAC Y) puenteado que se muestra en la ilustración anterior. En
para hacer un puente a dispositivos de red ns-3 que no son compatibles con SendFrom () (especialmente inalámbricos
Nodos STA) imponemos el requisito de que solo un dispositivo Linux (con una dirección MAC única
- aquí X) genera tráfico que fluye a través del enlace IPC. Esto se debe a que el MAC
Las direcciones de tráfico a través del enlace de IPC serán "falsificadas" o cambiadas para que parezca
Linux y ns-3 que tienen la misma dirección. Es decir, el tráfico que se mueve desde Linux
host al nodo fantasma ns-3 tendrá su dirección MAC cambiada de X a Y y el tráfico de
el nodo fantasma del host Linux tendrá su dirección MAC cambiada de Y a X. Dado que
existe una correspondencia uno a uno entre dispositivos, puede que solo haya una fuente MAC
que fluye desde el lado de Linux. Esto significa que Linux tiene puentes con más de un dispositivo de red.
agregados son incompatibles con el modo UseLocal.

En el modo UseLocal, se espera que el usuario cree y configure un dispositivo de grifo completamente
fuera del alcance de la simulación ns-3 usando algo como:

$ sudo tunctl -t tap0
$ sudo ifconfig tap0 hw ether 08: 00: 2e: 00: 00: 01
$ sudo ifconfig tap0 10.1.1.1 máscara de red 255.255.255.0 hasta

Para decirle al TapBridge lo que está sucediendo, el usuario establecerá directamente en el
TapBridge o mediante TapBridgeHelper, el atributo "DeviceName". En el caso de
configuración anterior, el atributo "DeviceName" se establecería en "tap0" y el "Modo"
El atributo se establecería en "UseLocal".

Un caso de uso particular para este modo es el entorno OpenVZ. Ahí es posible
para crear un dispositivo Tap en el "Nodo de hardware" y moverlo a un Servidor privado virtual.
Si TapBridge puede usar un dispositivo de grifo existente, entonces es posible evitar el
sobrecarga de un puente de SO en ese entorno.

ToquePuente UsarPuente Moda
El modo más simple para aquellos familiarizados con las redes Linux es el modo UseBridge. De nuevo,
el prefijo "Usar" indica que TapBridge usará una configuración existente.
En este caso, TapBridge lógicamente extenderá un puente de Linux a ns-3.

Esto se ilustra a continuación:

+ --------- +
| Linux | + ---------- +
| ------- | | fantasma |
| aplicaciones | | nodo |
| ------- | | -------- |
| pila | | IP | + ---------- +
| ------- | + -------- + | pila | | nodo |
| Virtual | | TAP | | ========== | | -------- |
| Dispositivo | | Dispositivo | <---- IPC -----> | toque | | IP |
+ --------- + + -------- + | puente | | pila |
|| || | -------- | | -------- |
+ -------------------- + | ns-3 | | ns-3 |
| Puente OS (brctl) | | neto | | neto |
+ -------------------- + | dispositivo | | dispositivo |
+ ---------- + + ---------- +
|| ||
+ --------------------------- +
| canal ns-3 |
+ --------------------------- +

En este caso, una computadora que ejecuta aplicaciones, protocolos, etc. de Linux está conectada a un
ns-3 simuló la red de tal manera que le parezca al host Linux que el TAP
dispositivo es un dispositivo de red real que participa en el puente de Linux.

En la simulación ns-3, se crea un TapBridge para que coincida con cada dispositivo TAP. El nombre de
El dispositivo TAP se asigna a Tap Bridge mediante el atributo "DeviceName". El TapBridge
luego extiende lógicamente el puente del sistema operativo para abarcar el dispositivo de red ns-3.

Dado que este modo extiende lógicamente un puente de sistema operativo, puede haber muchos dispositivos de red Linux en el
lado no ns-3 del puente. Por lo tanto, como un dispositivo de red en cualquier puente, el ns-3 net
el dispositivo debe lidiar con la posibilidad de muchas direcciones de origen. Por tanto, los dispositivos ns-3 deben
support SendFrom () (NetDevice :: SupportsSendFrom () debe devolver verdadero) para ser
configurado para su uso en el modo UseBridge.

Se espera que el usuario haga algo como lo siguiente para configurar el puente
y toque completamente fuera de ns-3:

$ sudo brctl addbr mipuente
$ sudo tunctl -t mytap
$ sudo ifconfig mytap hw ether 00: 00: 00: 00: 00: 01
$ sudo ifconfig mytap 0.0.0.0 arriba
$ sudo brctl addif mybridge mytap
$ sudo brctl addif mybridge...
$ sudo ifconfig mybridge 10.1.1.1 máscara de red 255.255.255.0 hasta

Para decirle al TapBridge lo que está sucediendo, el usuario establecerá directamente en el
TapBridge o mediante TapBridgeHelper, el atributo "DeviceName". En el caso de
configuración anterior, el atributo "DeviceName" se establecería en "mytap" y el "Modo"
El atributo se establecería en "UseBridge".

Este modo es especialmente útil en el caso de virtualización donde la configuración de
los hosts virtuales pueden ser dictados por otro sistema y no se pueden cambiar para adaptarse a ns-3.
Por ejemplo, un esquema de VM particular puede crear dispositivos virtuales "vethx" o "vmnetx" que
parecen locales para los hosts virtuales. Para conectarse a tales sistemas, uno necesitaría
Cree manualmente dispositivos TAP en el sistema host y conecte estos dispositivos TAP al
dispositivos virtuales existentes (VM). El trabajo del Tap Bridge en este caso es extender el
puente para unirse a un dispositivo de red ns-3.

ToquePuente Configurar local Operación
En el modo ConfigureLocal, el TapBridge y, por lo tanto, su dispositivo de red ns-3 asociado aparece
a la computadora host Linux como un dispositivo de red al igual que cualquier "eth0" o "ath0" arbitrario
podría aparecer. La creación y configuración del dispositivo TAP la realiza el ns-3
El usuario no requiere simulación y ninguna configuración manual. Las direcciones IP, MAC
direcciones, pasarelas, etc., para los dispositivos TAP creados se extraen de la simulación
sí mismo consultando la configuración del dispositivo ns-3 y los atributos TapBridge.

Dado que las direcciones MAC son idénticas en el lado de Linux y en el lado ns-3, podemos usar
Enviar () en el dispositivo ns-3 que está disponible en todos los dispositivos de red ns-3. Desde el MAC
direcciones son idénticas, no es necesario conectar la devolución de llamada promiscua en el
recibir lado. Por lo tanto, no existen restricciones sobre los tipos de dispositivos de red que
utilizable en modo ConfigureLocal.

TapBridge aparece en una simulación ns-3 como un dispositivo de red sin canales. Este dispositivo
no debe tener una dirección IP asociada, pero el dispositivo de red puenteado (ns-3) debe
tener una dirección IP. Tenga en cuenta que esto es lo contrario de un BridgeNetDevice ns-3 (o un
puente convencional en general) que exige que sus puertos de puente no tengan direcciones IP,
pero permite que el dispositivo puente tenga una dirección IP.

La computadora host aparecerá en una simulación como un nodo "fantasma" que contiene una
TapBridge para cada NetDevice que se está puenteando. Desde la perspectiva de una simulación,
la única diferencia entre un nodo fantasma y cualquier otro nodo será la presencia del
Dispositivos TapBridge. Sin embargo, tenga en cuenta que la presencia de TapBridge afecta la
Conectividad del dispositivo de red a la pila de IP del nodo fantasma.

La configuración de la información de dirección y los dispositivos ns-3 no cambia de ninguna manera si un
TapBridge está presente. Un TapBridge recogerá la información de direccionamiento del ns-3
dispositivo de red al que está conectado (su dispositivo de red "puenteado") y utilizar esa información para
Cree y configure el dispositivo TAP en el host real.

El resultado final de esto es una situación en la que uno puede, por ejemplo, usar el ping estándar
utilidad en un host real para hacer ping a un nodo ns-3 simulado. Si se agregan rutas correctas al
host de Internet (se espera que esto se haga automáticamente en futuras versiones de ns-3), el
Los sistemas de enrutamiento en ns-3 permitirán el enrutamiento correcto de los paquetes a través de ns-3 simulado
redes. Para ver un ejemplo de esto, vea el programa de ejemplo, tap-wifi-dumbbell.cc en el
Distribución ns-3.

Tap Bridge vive en una especie de mundo gris en algún lugar entre un host Linux y un ns-3
dispositivo puente. Desde la perspectiva de Linux, este código aparece como el controlador de modo de usuario para
un dispositivo de red TAP. En el modo ConfigureLocal, este dispositivo Tap es creado automáticamente por el
simulación ns-3. Cuando el host Linux escribe en uno de estos creados automáticamente
/ dev / tap, la escritura se redirige al TapBridge que vive en el mundo ns-3;
y desde esta perspectiva, el paquete escrito en Linux se convierte en un paquete leído en el Tap
Puente. En otras palabras, un proceso de Linux escribe un paquete en un dispositivo tap y este paquete
es redirigido por el mecanismo de derivación de red a un proceso ns-3 donde es recibido por el
TapBridge como resultado de una operación de lectura allí. TapBridge luego escribe el paquete en
el dispositivo de red ns-3 al que está conectado; y por lo tanto parece como si el host Linux
envió un paquete directamente a través de un dispositivo de red ns-3 a una red ns-3.

En la otra dirección, un paquete recibido por el dispositivo ns-3 net conectado al Tap
El puente se envía a través de una devolución de llamada de recepción al TapBridge. El TapBridge luego toma eso
paquete y lo escribe de nuevo en el host utilizando el mecanismo de derivación de red. Esto escribe al
el dispositivo le aparecerá al host de Linux como si un paquete hubiera llegado a un dispositivo de red; y
por lo tanto, como si hubiera aparecido un paquete recibido por el dispositivo ns-3 net durante una simulación
en un dispositivo de red Linux real.

El resultado es que Tap Bridge parece conectar un dispositivo tap en un host Linux en el
"mundo real" a un dispositivo de red ns-3 en la simulación. Porque el dispositivo TAP y el
El dispositivo de red ns-3 con puente tiene la misma dirección MAC y el enlace IPC de la toma de red no es
externalizado, este tipo particular de puente hace que parezca que un dispositivo de red ns-3 es
realmente instalado en el host Linux.

Para implementar esto en el lado ns-3, necesitamos un "nodo fantasma" en la simulación para
Sostenga el dispositivo de red ns-3 con puente y el TapBridge. Este nodo en realidad no debería hacer
cualquier otra cosa en la simulación, ya que su trabajo es simplemente hacer que el dispositivo de red aparezca en
Linux. Esta no es solo una política arbitraria, se debe a que:

· Los bits enviados al TapBridge desde capas superiores en el nodo fantasma (usando el TapBridge
Método de envío) se ignoran por completo. TapBridge no está, en sí mismo, conectado a ningún
red, ni en Linux ni en ns-3. Nunca puede enviar ni recibir datos a través de
TapBridge desde el nodo fantasma.

· El dispositivo de red ns-3 con puente tiene su devolución de llamada de recepción desconectada del nodo ns-3 y
reconectado al Tap Bridge. Todos los datos recibidos por un dispositivo puenteado se enviarán
al host Linux y no será recibido por el nodo. Desde la perspectiva del
nodo fantasma, puede enviar a través de este dispositivo pero nunca podrá recibir.

Por supuesto, si comprende todos los problemas, puede tomar el control de su propio destino.
y haz lo que quieras; no impedimos activamente que uses el nodo fantasma para
cualquier cosa que decidas. Podrá realizar operaciones típicas ns-3 en el fantasma
nodo si así lo desea. La pila de Internet, por ejemplo, debe estar ahí y funcional en
ese nodo para participar en la asignación de direcciones IP y el enrutamiento global. Sin embargo,
como se mencionó anteriormente, las interfaces que hablan con cualquier TapBridge o dispositivos de red puenteados asociados
no funcionará completamente. Si comprende exactamente lo que está haciendo, puede configurar
otras interfaces y dispositivos en el nodo fantasma y utilizarlos; o aprovecha la
lado de envío operativo de los dispositivos puenteados para crear generadores de tráfico. Nosotros generalmente
recomiendo que trate este nodo como un fantasma del host Linux y lo deje solo,
sin embargo.

ToquePuente Usar local Moda Operación
Como se describió anteriormente, TapBridge actúa como un puente entre el mundo "real" y el
mundo ns-3 simulado. En el caso del modo ConfigureLocal, la vida es fácil ya que la IP
La dirección del dispositivo Tap coincide con la dirección IP del dispositivo ns-3 y la dirección MAC de
el dispositivo Tap coincide con la dirección MAC del dispositivo ns-3; y hay un uno a uno
relación entre los dispositivos.

Las cosas se complican un poco cuando un dispositivo Tap se configura externamente con un
dirección MAC diferente a la del dispositivo ns-3 net. La forma convencional de lidiar con esto
tipo de diferencia es utilizar el modo promiscuo en el dispositivo puenteado para recibir paquetes
destinados a las diferentes direcciones MAC y reenviarlos a Linux. Para moverse
paquetes de otra manera, la solución convencional es SendFrom () que permite a una persona que llama
"falsificar" o cambiar la dirección MAC de origen para que coincida con las diferentes direcciones MAC de Linux.

Tenemos un requisito específico para poder unir máquinas virtuales Linux en
nodos STA inalámbricos. Desafortunadamente, la especificación 802.11 no proporciona una buena manera de
implementar SendFrom (), por lo que tenemos que solucionar ese problema.

Con este fin, proporcionamos el modo UseLocal del Tap Bridge. Este modo te permite
Aborde el problema como si estuviera creando un puente con un solo dispositivo de red. Un solo
La dirección permitida en el lado de Linux se recuerda en TapBridge, y todos los paquetes que vienen
desde el lado de Linux se repiten en el lado ns-3 usando la fuente MAC del dispositivo ns-3
habla a. Todos los paquetes que llegan desde el lado ns-3 se repiten desde el lado de Linux usando
la dirección MAC recordada. Esto nos permite usar Send () en el lado del dispositivo ns-3 que es
disponible en todos los dispositivos de red ns-3.

El modo UseLocal es idéntico al modo ConfigureLocal excepto por la creación y
configuración del dispositivo tap y la suplantación de la dirección MAC.

ToquePuente UsarPuente Operación
Como se describe en la sección del modo ConfigureLocal, cuando el host Linux escribe en uno de los
/ dev / tap, la escritura se redirige al TapBridge que vive en el mundo ns-3.
En el caso del modo UseBridge, estos paquetes deberán enviarse en el ns-3
red como si fueran enviados en un dispositivo que participa en el puente de Linux. Esto significa
llamar al método SendFrom () en el dispositivo puenteado y proporcionar la dirección MAC de origen
encontrado en el paquete.

En la otra dirección, un paquete recibido por un dispositivo de red ns-3 se conecta mediante devolución de llamada a
el TapBridge. Esto debe hacerse en modo promiscuo ya que el objetivo es unir el ns-3
net en el puente OS (brctl) del que forma parte el dispositivo TAP.

Por estas razones, solo los dispositivos ns-3 net que admiten SendFrom () y tienen un
promiscuos recibir devolución de llamada pueden participar en el modo UseBridge TapBridge
configuraciones.

Pulsa para buscar Puente Channel Modelo
No hay ningún modelo de canal asociado con Tap Bridge. De hecho, la intencin es hacer
parece que el host de Internet real está conectado al canal de la red puenteada
.

Pulsa para buscar Puente Rastreo Modelo
A diferencia de la mayoría de los dispositivos ns-3, TapBridge no proporciona ninguna fuente de rastreo estándar. Esta
se debe a que el puente es un intermediario que está esencialmente a una llamada de función de
el dispositivo puenteado. Esperamos que los ganchos de rastreo en el dispositivo puenteado sean
suficiente para la mayoría de los usuarios,

Usando los ToquePuente
Esperamos que la mayoría de los usuarios interactúen con el dispositivo TapBridge a través del
TapBridgeHelper. Los usuarios de otras clases auxiliares, como CSMA o Wifi, deben
cómodo con los modismos que se utilizan allí.

ENERGIA MARCO DE REFERENCIA

El consumo de energía es un tema clave para los dispositivos inalámbricos y los investigadores de redes inalámbricas
a menudo es necesario investigar el consumo de energía en un nodo o en la red general mientras
ejecutar simulaciones de red en ns-3. Esto requiere ns-3 para soportar el consumo de energía.
modelado. Además, a medida que conceptos como las pilas de combustible y la captación de energía se están volviendo
viable para dispositivos inalámbricos de baja potencia, incorporando el efecto de estos emergentes
tecnologías en simulaciones requiere soporte para modelar diversas fuentes de energía en
ns-3. El Marco de Energía ns-3 proporciona la base para el consumo de energía, la fuente de energía
y modelado de recolección de energía.

Modelo Descripción
El código fuente del Energy Framework se encuentra actualmente en: src / energía.

Design
El marco energético ns-3 se compone de 3 partes: fuente de energía, modelo energético del dispositivo y
Cosechadora de energía. El marco se implementa en el src / energía / modelos carpeta.

Valor energético Fuente
La fuente de energía representa la fuente de alimentación en cada nodo. Un nodo puede tener uno o más
fuentes de energía, y cada fuente de energía se puede conectar a varios modelos de energía de dispositivos.
Conectar una fuente de energía a un modelo energético de dispositivo implica que el dispositivo correspondiente
extrae energía de la fuente. La funcionalidad básica de la fuente de energía es proporcionar
energía para dispositivos en el nodo. Cuando la energía se agota por completo de la fuente de energía,
notifica a los dispositivos en el nodo de modo que cada dispositivo pueda reaccionar a este evento. Más,
Cada nodo puede acceder a los Objetos de fuente de energía para obtener información como la energía restante o
Fracción de energía (nivel de batería). Esto permite la implementación de protocolos conscientes de la energía.
en ns-3.

Para modelar una amplia gama de fuentes de alimentación, como baterías, la fuente de energía debe
poder capturar las características de estos suministros. Hay 2 importantes
características o efectos relacionados con las baterías prácticas:

Rate de Carga Efecto
Disminución de la vida útil de la batería cuando el consumo de corriente es superior al valor nominal
de la batería.

Recuperación Efecto
Aumento de la vida útil de la batería cuando la batería alterna entre descarga y
estados inactivos.

Para incorporar el efecto de capacidad de tarifa, la fuente de energía utiliza el consumo de corriente de
todos los dispositivos en el mismo nodo para calcular el consumo de energía. Además, múltiples
Los recolectores de energía se pueden conectar a la fuente de energía para reponer su energía.
La fuente de energía sondea periódicamente todos los dispositivos y recolectores de energía en el mismo
nodo para calcular el consumo de corriente total y, por tanto, el consumo de energía. Cuando un dispositivo
cambia de estado, su Modelo de Energía de Dispositivo correspondiente notificará a la Fuente de Energía de este
cambiará y se calculará el nuevo consumo total de corriente. Del mismo modo, todos los recolectores de energía
actualización activa una actualización de la fuente de energía conectada.

La clase base Energy Source mantiene una lista de dispositivos (objetos Device Energy Model) y
recolectores de energía (objetos recolectores de energía) que utilizan la fuente de energía particular
como fuente de alimentación. Cuando la energía se agota por completo, la fuente de energía notificará a todos
dispositivos en esta lista. Cada dispositivo puede manejar este evento de forma independiente, según el
comportamiento deseado que se debe seguir en caso de corte de energía.

Device Valor energético Modelo
El modelo energético del dispositivo es el modelo de consumo de energía de un dispositivo instalado en el nodo.
Está diseñado para ser un modelo basado en estados en el que se supone que cada dispositivo tiene una serie de
estados, y cada estado está asociado con un valor de consumo de energía. Siempre que el estado de
el dispositivo cambia, el modelo energético del dispositivo correspondiente notificará a la fuente de energía de
el nuevo consumo de corriente del dispositivo. La fuente de energía calculará el nuevo total
consumir corriente y actualizar la energía restante.

El modelo de energía del dispositivo también se puede utilizar para dispositivos que no tienen un número finito de
estados. Por ejemplo, en un vehículo eléctrico, el consumo de corriente del motor se determina
por su velocidad. Dado que la velocidad del vehículo puede tomar valores continuos dentro de un cierto rango,
no es factible definir un conjunto de estados de operación discretos. Sin embargo, al convertir
el valor de la velocidad en la corriente directamente, el mismo conjunto de API del modelo energético del dispositivo todavía puede
ser usado.

Valor energético Harvester
El recolector de energía representa los elementos que recolectan energía del medio ambiente y
recargar la Fuente de Energía a la que está conectado. El recolector de energía incluye el
Implementación completa del dispositivo de recolección de energía real (por ejemplo, un panel solar) y
el medio ambiente (por ejemplo, la radiación solar). Esto significa que al implementar una energía
cosechadora, la contribución energética del medio ambiente y la energía adicional
requisitos del dispositivo de recolección de energía, como la eficiencia de conversión y la
El consumo de energía interno del dispositivo debe modelarse de manera conjunta.

WiFi Radio Valor energético Modelo
El modelo de energía de radio WiFi es el modelo de consumo de energía de un dispositivo de red Wifi. Eso
proporciona un estado para cada uno de los estados disponibles de la capa PHY: Inactivo, CcaBusy, Tx, Rx,
ChannelSwitch, dormir. Cada uno de estos estados está asociado con un valor (en amperios) del
consumo actual (consulte a continuación los nombres de los atributos correspondientes). Un modelo de energía de radio wifi
PHY Listener está registrado en Wifi PHY para ser notificado de cada estado de Wifi PHY
transición. En cada transición, la energía consumida en el estado anterior se calcula y
se notifica a la fuente de energía para actualizar su energía restante.

El modelo actual de Wifi Tx ofrece la posibilidad de calcular el consumo de corriente en el
estado de transmisión en función de la potencia tx nominal (en dBm), como se observa en varios
mediciones experimentales. Para este propósito, el oyente Wifi Radio Energy Model PHY es
notificado de la potencia tx nominal utilizada para transmitir la trama actual y pasa tal
valor al modelo actual de Wifi Tx que se encarga de actualizar el consumo de corriente en el Tx
Expresar. Por lo tanto, el consumo de energía se calcula correctamente incluso si la estación remota Wifi
El administrador realiza el control de potencia por cuadro. Actualmente, un modelo de corriente Linear Wifi Tx es
implementado que calcula la corriente tx como una función lineal (de acuerdo con los parámetros
que puede especificar el usuario) de la potencia tx nominal en dBm.

El modelo de energía de radio Wifi ofrece la posibilidad de especificar una devolución de llamada que se invoca
cuando la fuente de energía se agota. Si tal devolución de llamada no se especifica cuando el Wifi
Radio Energy Model Helper se utiliza para instalar el modelo en un dispositivo, una devolución de llamada es
hecho implícitamente para que el Wifi PHY se ponga en el modo SLEEP (por lo tanto, no se
transmitido ni recibido posteriormente) cuando la fuente de energía se agota. Asimismo, es
posible especificar una devolución de llamada que se invoca cuando se recarga la fuente de energía (que
podría ocurrir en caso de que un recolector de energía esté conectado a la fuente de energía). Si tal
La devolución de llamada no se especifica cuando se utiliza Wifi Radio Energy Model Helper para instalar el
modelo en un dispositivo, se realiza implícitamente una devolución de llamada para que el Wifi PHY se reanude desde el
Modo SUEÑO cuando se recarga la fuente de energía.

Futuro Trabaja
Para los modelos de energía de dispositivos, planeamos incluir soporte para otros modelos de capa PHY
proporcionado en ns-3 como WiMAX, y para modelar los consumos de energía de otros
dispositivos de comunicación, como un sensor genérico y una CPU. Para las fuentes de energía, estamos
planeando incluir nuevos tipos de fuentes de energía como supercondensador y níquel-metal
Pila de hidruro (Ni-MH). Para los recolectores de energía, estamos planeando implementar un
cosechadora que recarga las fuentes de energía de acuerdo con los niveles de potencia definidos en un
conjunto de datos personalizable por el usuario de mediciones reales.

Referencias
[1] Modelo energético ns-2:
http://www.cubinlab.ee.unimelb.edu.au/~jrid/Docs/Manuel-NS2/node204.html

[2] H. Wu, S. Nabar y R. Poovendran. Un marco energético para el simulador de red 3
(ns-3).

[3] M. Handy y D. Timmermann. Simulación de redes inalámbricas móviles con precisión
Modelado de efectos de batería no lineales. En Proc. de simulación y modelado aplicados
(MAE), 2003.

[4] DN Rakhmatov y SB Vrudhula. Un modelo analítico de batería de alto nivel para su uso en
gestión energética de sistemas electrónicos portátiles. En Proc. de IEEE / ACM International
Conferencia sobre diseño asistido por computadora (ICCAD'01), páginas 488-493, noviembre de 2001.

[5] DN Rakhmatov, SB Vrudhula y DA Wallach. Predicción de la vida útil de la batería para
Computación consciente de la energía. En Proc. del Simposio Internacional de Baja Potencia de 2002
Electrónica y diseño (ISLPED'02), páginas 154-159, 2002.

[6] C. Tapparello, H. Ayatollahi y W. Heinzelman. Ampliación del marco energético para
Simulador de red 3 (ns-3). Taller sobre ns-3 (WNS3), Sesión de pósteres, Atlanta, GA,
EE.UU. Mayo de 2014.

Uso
La principal forma en que los usuarios de ns-3 interactuarán normalmente con el marco energético es a través de
la API auxiliar y a través de los atributos públicamente visibles del marco. El ayudante
API se define en src / energía / ayudante / *. h.

Para utilizar el marco energético, el usuario debe instalar una fuente de energía para el nodo
de interés, el Modelo de Energía de Dispositivo correspondiente para los dispositivos de red y, si
necesario, uno o más recolectores de energía. Las fuentes de energía (objetos) se agregan a
cada nodo por el Asistente de fuente de energía. Para permitir múltiples fuentes de energía por nodo,
agregamos un contenedor de fuente de energía en lugar de agregar directamente un objeto fuente.

El objeto Fuente de energía mantiene una lista de los objetos Modelo energético del dispositivo y Recolector de energía
utilizando la fuente como fuente de alimentación. Los objetos Device Energy Model se instalan en el
Fuente de energía por el Asistente de modelo de energía del dispositivo, mientras que el objeto Recolector de energía es
instalado por Energy Harvester Helper. El usuario puede acceder a los objetos del modelo energético del dispositivo
a través del objeto Fuente de energía para obtener información sobre el consumo de energía de
dispositivos. Además, el usuario puede acceder a los objetos Energy Harvester para recolectar
información sobre la potencia actual recolectada y la energía total recolectada por el
segador.

Ejemplos
Los directorios de ejemplo, src / examples / energía y ejemplos/energia, contiene algún código básico
que muestra cómo configurar el marco.

Ayudantes
Valor energético Fuente Ayudante
Clase auxiliar base para objetos de fuente de energía, este objeto auxiliar agrega fuente de energía
en un nodo. La implementación secundaria de esta clase crea el objeto Fuente de energía real.

Device Valor energético Modelo Ayudante
Clase de ayudante base para objetos de modelo de energía de dispositivo, este ayudante adjunta energía de dispositivo
Modele objetos en objetos de fuente de energía. La implementación secundaria de esta clase crea el
objeto de modelo de energía de dispositivo real.

Valor energético Cosecha Ayudante
Clase de ayudante base para objetos Energy Harvester, este ayudante adjunta Energy Harvester
objetos en objetos de fuente de energía. La implementación secundaria de esta clase crea el verdadero
Objeto Cosechador de energía.

Atributos
Los atributos difieren entre fuentes de energía, modelos de energía de dispositivos y recolectores de energía
implementaciones, consulte la clase secundaria específica para obtener más detalles.

Básico Valor energético Fuente
· Fuente de energía básica Energía inicial J: Energía inicial almacenada en la fuente de energía básica.

· Voltaje de suministro de energía básico V: Tensión de alimentación inicial para la fuente de energía básica.

· Intervalo de actualización de energía periódica: Tiempo entre dos actualizaciones de energía periódicas consecutivas.

RV Batería Modelo
· RvBateríaModeloPeriódicoEnergíaActualizaciónIntervalo: Intervalo de muestreo del modelo de batería de RV.

· RvBateríaModeloAbiertoCircuitoVoltaje: Tensión de circuito abierto del modelo de batería de RV.

· RvBateríaModeloCorteVoltaje: Tensión de corte del modelo de batería de RV.

· RvBateríaModeloAlfaValor: Valor alfa del modelo de batería de RV.

· RvBateríaModeloBetaValor: Valor beta del modelo de batería de RV.

· RvBatteryModelNumOfTerms: El número de términos de la suma infinita para estimar la batería
.

WiFi Radio Valor energético Modelo
· Corriente inactivaA: La corriente inactiva de radio predeterminada en amperios.

· CcaOcupadoActualA: La corriente de estado ocupado CCA de radio predeterminada en amperios.

· TxActualA: La corriente de radio Tx en amperios.

· RxActualA: La corriente Rx de la radio en Amperios.

· ConmutaciónActualA: La corriente predeterminada del interruptor de canal de radio en amperios.

· DormirActualA: La corriente de reposo de la radio en amperios.

· TxModeloActual: Un puntero al modelo actual tx adjunto.

Básico Valor energético Harvester
· Intervalo de actualización de energía cosechada periódica: Tiempo entre dos actualizaciones periódicas consecutivas de
el poder cosechado.

· CosechablePoder: Variables aleatorias que representan la cantidad de energía que se proporciona
por el recolector de energía.

Rastreo
Los valores trazados difieren entre las fuentes de energía, los modelos de energía de los dispositivos y los recolectores de energía
implementaciones, consulte la clase secundaria específica para obtener más detalles.

Básico Valor energético Fuente
· Energía restante: Energía restante en BasicEnergySource.

RV Batería Modelo
· RvBateríaModeloNivel De Batería: nivel de batería del modelo de batería de RV.

· RVBateríaModeloBateríaVida útil: Vida útil de la batería del modelo de batería de RV.

WiFi Radio Valor energético Modelo
· Consumo total de energía: Consumo total de energía del dispositivo de radio.

Básico Valor energético Harvester
· Poder cosechado: Potencia actual proporcionada por BasicEnergyHarvester.

· Energía Total Cosechada: Energía total recolectada por BasicEnergyHarvester.

Validación
No se ha realizado una comparación de Energy Framework con los dispositivos reales. Actual
la implementación del Marco Energético se verifica numéricamente en busca de errores de cálculo. El
El modelo de batería de RV se valida comparando los resultados con lo que se presentó en el original
Papel modelo de batería de RV.

FLOW MONITOR

Modelo Descripción
El código fuente del nuevo módulo vive en el directorio. src/flujo-monitor.

El objetivo del módulo Flow Monitor es proporcionar un sistema flexible para medir el rendimiento de
protocolos de red. El módulo utiliza sondas, instaladas en los nodos de la red, para rastrear la
paquetes intercambiados por los nodos, y medirá una serie de parámetros. Los paquetes son
divididos según el flujo al que pertenecen, donde cada flujo se define según el
características de la sonda (por ejemplo, para IP, un flujo se define como los paquetes con el mismo
{protocolo, origen (IP, puerto), destino (IP, puerto)} tupla.

Las estadísticas que se recopilan para cada flujo se pueden exportar en formato XML. Además, el
el usuario puede acceder a las sondas directamente para solicitar estadísticas específicas sobre cada flujo.

Design
El módulo Flow Monitor está diseñado de forma modular. Se puede extender subclasificando
ns3::Sonda de flujo y ns3::Clasificador de flujo.

El diseño completo del módulo se describe en [FlowMonitor]

<b></b><b></b> y Limitaciones
Por el momento, las sondas y los clasificadores están disponibles para IPv4 e IPv6.

Cada sonda clasificará los paquetes en cuatro puntos:

· Cuando se envía un paquete (rastros SendOutgoing IPv[4,6])

· Cuando se reenvía un paquete (trazas UnicastForward IPv[4,6])

· Cuando se recibe un paquete (trazas de LocalDeliver IPv[4,6])

· Cuando se descarta un paquete (Drop IPv[4,6] traces)

Dado que los paquetes se rastrean a nivel de IP, cualquier retransmisión causada por los protocolos L4
(p. ej., TCP) será visto por la sonda como un nuevo paquete.

Se agregará una etiqueta al paquete (ns3::Ipv[4,6]Etiqueta de sonda de flujo). La etiqueta llevará básica
datos del paquete, útil para la clasificación del paquete.

Debe subrayarse que, hasta el momento, solo los paquetes L4 (TCP, UDP) están clasificados. Es más,
solo se clasificarán los paquetes de unidifusión. Estas limitaciones pueden eliminarse en el futuro.

Los datos recopilados para cada flujo son:

· timeFirstTxPacket: cuándo se transmitió el primer paquete del flujo;

· timeLastTxPacket: cuándo se transmitió el último paquete del flujo;

· timeFirstRxPacket: cuando un nodo final recibió el primer paquete en el flujo;

· timeLastRxPacket: cuándo se recibió el último paquete del flujo;

· delaySum: la suma de todos los retrasos de extremo a extremo para todos los paquetes recibidos del flujo;

· jitterSum: la suma de todos los valores de fluctuación de fase de retardo de extremo a extremo (variación de retardo) para todos
paquetes recibidos del flujo, como se define en RFC 3393;

· txBytes, txPackets: número total de bytes/paquetes transmitidos para el flujo;

· rxBytes, rxPackets: número total de bytes/paquetes recibidos para el flujo;

· LostPackets: número total de paquetes que se suponen perdidos (no informados más de 10
segundos);

· timesForwarded: el número de veces que un paquete ha sido supuestamente reenviado;

· delayHistogram, jitterHistogram, paqueteSizeHistogram: versiones del histograma para el retraso,
jitter y tamaños de paquete, respectivamente;

· packagesDropped, bytesDropped: el número de paquetes y bytes perdidos, dividido según
el código de motivo de pérdida (definido en la sonda).

Vale la pena señalar que las sondas miden los bytes del paquete, incluidos los encabezados de IP.
Los encabezados L2 no están incluidos en la medida.

Estas estadísticas se escribirán en formato XML a pedido (consulte la sección Uso).

Referencias
[Monitor de flujo]

G. Carneiro, P. Fortuna y M. Ricardo. 2009. FlowMonitor: un marco de monitoreo de red
para el simulador de red 3 (NS-3). En Actas de la Cuarta Internacional ICST
Jornada sobre Metodologías y Herramientas de Evaluación del Desempeño (VALUETOOLS '09).
http://dx.doi.org/10.4108/ICST.VALUETOOLS2009.7493

Uso
El uso del módulo es extremadamente simple. El ayudante se encargará de todo.

El uso típico es:

// monitor de flujo
ptr monitor de flujo;
FlowMonitorHelperflowHelper;
flowMonitor = flowHelper.InstallAll();

Simulador::Detener (Segundos(stop_time));
Simulador::Ejecutar ();

flowMonitor->SerializeToXmlFile("NombreDeArchivo.xml", verdadero, verdadero);

los SerializarAXmlFile () Los parámetros 2 y 3 de la función se utilizan respectivamente para
activar/desactivar los histogramas y las estadísticas detalladas por sonda.

Otras alternativas posibles se pueden encontrar en la documentación de Doxygen.

Ayudantes
La API auxiliar sigue el patrón de uso de los auxiliares normales. A través del ayudante puedes
instale el monitor en los nodos, configure los atributos del monitor e imprima las estadísticas.

Una cosa importante es: la ns3::FlowMonitorHelper debe ser instanciado una sola vez en el
principal.

Atributos
El módulo proporciona los siguientes atributos en ns3::Monitor de flujo:

· MaxPerHopDelay (Tiempo, 10 s por defecto): El retraso máximo por salto que se debe considerar;

· StartTime (Tiempo, por defecto 0s): La hora en que comienza el monitoreo;

· DelayBinWidth (doble, predeterminado 0.001): el ancho utilizado en el histograma de retraso;

· JitterBinWidth (doble, predeterminado 0.001): el ancho utilizado en el histograma de fluctuación;

· PacketSizeBinWidth (doble, predeterminado 20.0): el ancho utilizado en el histograma de tamaño de paquete;

· FlowInterruptionsBinWidth (doble, predeterminado 0.25): el ancho utilizado en el
histograma de interrupciones de flujo;

· FlowInterruptionsMinTime (doble, por defecto 0.5): El tiempo mínimo entre llegadas que es
considerado una interrupción del flujo.

Salida
El resultado principal del modelo es un informe en formato XML sobre estadísticas de flujo. Un ejemplo es:




























La salida fue generada por un flujo TCP de 10.1.3.1 a 10.1.2.2.

Vale la pena notar que la sonda de índice 2 informa más paquetes y más bytes que
los otros problemas. Ese es un comportamiento perfectamente normal, ya que los paquetes están fragmentados en IP
nivel en ese nodo.

También se debe observar que la sonda del nodo receptor (índice 4) no cuenta el
fragmentos, ya que el reensamblaje se realiza antes del punto de sondaje.

Ejemplos
Los ejemplos se encuentran en src/flow-monitor/ejemplos.

Además, los siguientes ejemplos usan el módulo de monitoreo de flujo:

· ejemplos/matrix-topology/matrix-topology.cc

· ejemplos/enrutamiento/manet-routing-compare.cc

· ejemplos/enrutamiento/simple-global-routing.cc

· ejemplos/tcp/tcp-variantes-comparación.cc

· ejemplos/inalámbrico/multirate.cc

· ejemplos/inalámbrico/wifi-hidden-terminal.cc

Diagnóstico
No defina más de uno ns3::FlowMonitorHelper en la simulación.

Validación
El documento en las referencias contiene una descripción completa de la validación del módulo contra un
red de prueba.

Se proporcionan pruebas para garantizar el correcto funcionamiento del histograma.

INTERNET MODELOS

Internet Apilar
Internet montón agregación
Una clase desnuda Nodo no es muy útil tal como está; otros objetos deben agregarse a él para
proporcionar una funcionalidad de nodo útil.

La ns-3 directorio de código fuente origen/internet proporciona implementación de TCP/IPv4- y
Componentes relacionados con IPv6. Estos incluyen IPv4, ARP, UDP, TCP, IPv6, descubrimiento de vecinos y
otros protocolos relacionados.

Los Nodos de Internet no son subclases de la clase Nodo; son simplemente Nodos que han tenido un
montón de objetos relacionados con IP agregados a ellos. Se pueden armar a mano o a través de un
función auxiliar InternetStackHelper::Instalar () que hace lo siguiente a todos los nodos
pasado como argumentos:

vacío
InternetStackHelper::Instalar (Ptr nodo) constante
{
si (m_ipv4Enabled)
{
/* pila IPv4 */
if (nodo->GetObject () != 4)
{
NS_FATAL_ERROR ("InternetStackHelper::Install (): agregando"
"un InternetStack a un nodo con un objeto Ipv4 existente");
volver;
}

CreateAndAggregateObjectFromTypeId (nodo, "ns3::ArpL3Protocol");
CreateAndAggregateObjectFromTypeId (nodo, "ns3::Ipv4L3Protocol");
CreateAndAggregateObjectFromTypeId (nodo, "ns3::Icmpv4L4Protocol");
// Establecer enrutamiento
ptr ipv4 = nodo->ObtenerObjeto ();
ptr ipv4Routing = m_routing->Crear (nodo);
ipv4->Establecer protocolo de enrutamiento (enrutamiento ipv4);
}

si (m_ipv6Enabled)
{
/* pila IPv6 */
if (nodo->GetObject () != 6)
{
NS_FATAL_ERROR ("InternetStackHelper::Install (): agregando"
"un InternetStack a un nodo con un objeto Ipv6 existente");
volver;
}

CreateAndAggregateObjectFromTypeId (nodo, "ns3::Ipv6L3Protocol");
CreateAndAggregateObjectFromTypeId (nodo, "ns3::Icmpv6L4Protocol");
// Establecer enrutamiento
ptr ipv6 = nodo->ObtenerObjeto ();
ptr ipv6Routing = m_routingv6->Crear (nodo);
ipv6->Establecer protocolo de enrutamiento (enrutamiento ipv6);

/* registrar extensiones y opciones de IPv6 */
ipv6->ExtensionesRegistrar ();
ipv6->OpcionesRegistrar ();
}

si (m_ipv4Enabled || m_ipv6Enabled)
{
/* Pilas UDP y TCP */
CreateAndAggregateObjectFromTypeId (nodo, "ns3::UdpL4Protocol");
nodo->AgregateObject (m_tcpFactory.Create ());
ptr fábrica = CreateObject ();
nodo->AgregateObject (fábrica);
}
}

Cuando existen múltiples implementaciones en ns-3 (TCP, enrutamiento IP), estos objetos son agregados por
un objeto de fábrica (TCP) o por un ayudante de enrutamiento (m_routing).

Tenga en cuenta que el protocolo de enrutamiento está configurado y establecido fuera de esta función. Por defecto,
se añaden los siguientes protocolos:

vacío InternetStackHelper::Inicializar ()
{
SetTcp ("ns3::TcpL4Protocol");
Ipv4StaticRoutingHelper staticRouting;
Ipv4GlobalRoutingHelper globalRouting;
Ipv4ListRoutingLista de ayudaEnrutamiento;
Ipv6ListRoutingLista de ayudaRoutingv6;
Ipv6StaticRoutingHelper staticRoutingv6;
listRouting.Add (ruta estática, 0);
listaRouting.Add (globalRouting, -10);
listRoutingv6.Add (staticRoutingv6, 0);
SetRoutingHelper (listaRouting);
SetRoutingHelper (listaRoutingv6);
}

De forma predeterminada, IPv4 e IPv6 están habilitados.

Internet Nodo estructura
Un nodo con capacidad IP (un ns-3 Nodo aumentado por agregación para tener una o más pilas de IP)
tiene la siguiente estructura interna.

Layer-3 protocolos
En la capa más baja, por encima de los NetDevices, se encuentran los protocolos de "capa 3", que incluyen
IPv4, IPv6, ARP, etc. La clase Protocolo Ipv4L3 es una clase de implementación cuya
la interfaz pública suele ser de clase Ipv4, pero también se utiliza la API pública Ipv4L3Protocol
internamente en la actualidad.

En la clase Ipv4L3Protocol, un método descrito a continuación es Recibir ():

/ **
* La capa inferior llama a este método después de llamar a L3Demux::Lookup
* La subclase ARP necesita saber de qué dispositivo de red se trata.
* el paquete está llegando a:
* - implementar un caché ARP por NetDevice
* - enviar respuestas arp en el dispositivo correcto
*/
void Recibir (Ptr dispositivo p, protocolo uint16_t,
const Dirección &de, const Dirección &a, NetDevice::PacketType paqueteTipo);

Primero, tenga en cuenta que el Recibir () la función tiene una firma coincidente con el ReceiveCallback
en la clase Nodo. Este puntero de función se inserta en el controlador de protocolo del nodo cuando
Agregar interfaz () se llama. El registro real se realiza con una declaración como
manera:

RegisterProtocolHandler (MakeCallback (&Ipv4Protocol::Receive, ipv4),
Protocolo Ipv4L3::PROT_NUMBER, 0);

El objeto Ipv4L3Protocol se agrega al Nodo; solo hay uno de esos Ipv4L3Protocol
objeto. Protocolos de capa superior que tienen un paquete para enviar al Ipv4L3Protocol
el objeto puede llamar ObtenerObjeto () para obtener un puntero, de la siguiente manera:

ptr ipv4 = m_node->GetObject ();
si (ipv4 != 0)
{
ipv4->Enviar (paquete, saddr, daddr, PROT_NUMBER);
}

Esta clase demuestra muy bien dos técnicas que explotamos en ns-3 para unir objetos:
devoluciones de llamadas y agregación de objetos.

Una vez que el enrutamiento IPv4 ha determinado que un paquete es para el nodo local, lo reenvía
la pila. Esto se hace con la siguiente función:

vacío
Ipv4L3Protocol::LocalDeliver (Ptr paquete, Ipv4Header const&ip, uint32_t iif)

El primer paso es encontrar el objeto Ipv4L4Protocol correcto, según el número de protocolo IP.
Por ejemplo, TCP se registra en el demux como número de protocolo 6. Finalmente, el Recibir()
función en el Ipv4L4Protocol (como Protocolo TcpL4::Recibir se llama.

Todavía no hemos introducido la clase Ipv4Interface. Básicamente, cada NetDevice está emparejado
con una representación IPv4 de dicho dispositivo. En Linux, esta clase Interfaz Ipv4 aproximadamente
corresponde a la struct en_dispositivo; el objetivo principal es proporcionar dirección-familia
información específica (direcciones) sobre una interfaz.

Todas las clases tienen rastros apropiados para rastrear paquetes enviados, recibidos y perdidos.
Se alienta a los usuarios a utilizarlos para averiguar si (y dónde) se descarta un paquete. A
error común es olvidar los efectos de las colas locales al enviar paquetes, por ejemplo, el
cola ARP. Esto puede ser particularmente desconcertante cuando se envían paquetes gigantes o ráfagas de paquetes.
utilizando UDP. La cola pendiente de caché ARP es limitada (3 datagramas) y los paquetes IP pueden ser
fragmentado, llenando fácilmente el tamaño de la cola de caché ARP. En esos casos es útil
aumente el tamaño pendiente de caché ARP a un valor adecuado, por ejemplo:

Config::SetDefault ("ns3::ArpCache::PendingQueueSize", UintegerValue (MAX_BURST_SIZE/L2MTU*3));

La implementación de IPv6 sigue una arquitectura similar. Nodos de doble pila (uno con
compatibilidad con IPv4 e IPv6) permitirá que un socket IPv6 reciba conexiones IPv4 como un
el sistema estándar de doble apilamiento sí lo hace. Un socket enlazado y escuchando un punto final IPv6 puede
recibirá una conexión IPv4 y devolverá la dirección remota como una dirección asignada a IPv4.
La compatibilidad con la opción de socket IPV6_V6ONLY no existe actualmente.

Layer-4 protocolos y tomas
A continuación, describimos cómo se unen los protocolos de transporte, los sockets y las aplicaciones. En
En resumen, cada implementación de protocolo de transporte es una fábrica de sockets. Una aplicación que
necesita un enchufe nuevo

Por ejemplo, para crear un socket UDP, una aplicación usaría un fragmento de código como el
siguientes:

ptr udpSocketFactory = ObtenerNodo ()->ObtenerObjeto ();
ptr m_socket = socketFactory->CreateSocket ();
m_socket->Enlazar (m_dirección_local);
...

Lo anterior consultará el nodo para obtener un puntero a su fábrica de sockets UDP, creará uno
dicho socket, y utilizará el socket con una API similar a la API de sockets basada en C, como
as Conéctate () y ENVIAR (). La dirección pasó a la aglutinante (), Conéctate ()o ENVIAR ()
funciones pueden ser una Dirección Ipv4, Dirección Ipv6o Dirección. Si un Dirección se pasa y
contiene algo más que un Dirección Ipv4 or Dirección Ipv6, estas funciones devolverán un
error. El aglutinante (vacío) y Enlazar6 (vacío) las funciones se unen a "0.0.0.0" y "::"
respectivamente.

El socket también se puede vincular a un NetDevice específico a través del BindToNetDevice
(Patrón dispositivo de red) función. BindToNetDevice (Patrón dispositivo de red) se unirá
el socket a "0.0.0.0" y "::" (equivalente a llamar aglutinante () y Enlazar6 (), a menos que el
socket ya se ha vinculado a una dirección específica. Resumiendo, la secuencia correcta
:

ptr udpSocketFactory = ObtenerNodo ()->ObtenerObjeto ();
ptr m_socket = socketFactory->CreateSocket ();
m_socket->BindToNetDevice (n_netDevice);
...

o bien:

ptr udpSocketFactory = ObtenerNodo ()->ObtenerObjeto ();
ptr m_socket = socketFactory->CreateSocket ();
m_socket->Enlazar (m_dirección_local);
m_socket->BindToNetDevice (n_netDevice);
...

Lo siguiente genera un error:

ptr udpSocketFactory = ObtenerNodo ()->ObtenerObjeto ();
ptr m_socket = socketFactory->CreateSocket ();
m_socket->BindToNetDevice (n_netDevice);
m_socket->Enlazar (m_dirección_local);
...

Consulte el capítulo sobre ns-3 enchufes para más información.

Hemos descrito hasta ahora una fábrica de enchufes (por ejemplo, clase udp) y un enchufe, que puede ser
especializado (por ejemplo, clase UdpSocket). Hay algunos objetos clave más que se relacionan con el
tarea especializada de demultiplexar un paquete a uno o más conectores de recepción. La clave
objeto en esta tarea es clase Ipv4EndPointDemux. Este demultiplexor almacena objetos de
clase Punto final IPv4. Esta clase contiene la tupla de direccionamiento/puerto (puerto local,
dirección, puerto de destino, dirección de destino) asociado con el socket, y una recepción
llamar de vuelta. Esta devolución de llamada de recepción tiene una función de recepción registrada por el socket. El
Buscar () función a Ipv4EndPointDemux devuelve una lista de objetos Ipv4EndPoint (puede haber
ser una lista ya que más de un socket puede coincidir con el paquete). El protocolo de capa 4 copia
el paquete a cada Ipv4EndPoint y llama a su Adelante () método, que luego llama al
Recibir () función registrada por el socket.

Un problema que surge cuando se trabaja con la API de sockets en sistemas reales es la necesidad de
administrar la lectura desde un socket, usando algún tipo de E/S (por ejemplo, bloqueante, no bloqueante,
asíncrono, ...). ns-3 implementa un modelo asíncrono para socket I/O; la aplicación
establece una devolución de llamada para ser notificado de los datos recibidos listos para ser leídos, y la devolución de llamada es
invocado por el protocolo de transporte cuando los datos están disponibles. Esta devolución de llamada se especifica como
manera:

void Socket::SetRecvCallback (Devolución de llamada ,
ptr ,
const Dirección&> datos recibidos);

Los datos que se reciben se transportan en el búfer de datos del paquete. Un ejemplo de uso está en
clase Disipador de paquetes:

m_socket->SetRecvCallback (MakeCallback(&PacketSink::HandleRead, this));

Para resumir, internamente, la implementación de UDP está organizada de la siguiente manera:

· un UdpImpl clase que implementa la funcionalidad de fábrica de sockets UDP

· un Protocolo UdpL4 clase que implementa la lógica del protocolo que es independiente del socket

· un UdpSocketImpl clase que implementa aspectos específicos de socket de UDP

· una clase llamada Punto final IPv4 que almacena la tupla de direccionamiento (puerto local, dirección local,
puerto de destino, dirección de destino) asociado con el socket, y un receptor
devolución de llamada para el socket.

compatible con IP nodo las interfaces
Muchos de los detalles de implementación, u objetos internos mismos, de Nodo con capacidad IP
los objetos no se exponen en la API pública del simulador. Esto permite diferentes
implementaciones; por ejemplo, reemplazando al nativo ns-3 modelos con pila TCP/IP portada
código.

Las API públicas de C++ de todos estos objetos se encuentran en el origen/red directorio,
incluyendo principalmente:

· dirección.h

· enchufe.h

· nodo.h

· paquete.h

Suelen ser objetos de clase base que implementan los valores predeterminados utilizados en el
implementación, implementar métodos de acceso para obtener/establecer variables de estado, atributos de host y
implementar métodos disponibles públicamente expuestos a clientes como CrearSocket.

Ejemplo camino of a paquete
Estas dos figuras muestran un seguimiento de pila de ejemplo de cómo fluyen los paquetes a través de Internet.
Objetos de nodo.
[imagen] Ruta de envío de un paquete... UNINDENT
[imagen] Recibe la ruta de un paquete... UNINDENT

IPv4
marcador de posición capítulo

IPv6
Este capítulo describe el ns-3 Capacidades y limitaciones del modelo IPv6 junto con su
uso y ejemplos.

IPv6 modelo descripción
El modelo de IPv6 está vagamente modelado después de la implementación de Linux; la implementación es
no está completo ya que algunas características de IPv6 no son de mucho interés para los estudios de simulación, y
algunas características de IPv6 simplemente no están modeladas todavía en ns-3.

La clase base Ipv6 define una API genérica, mientras que la clase Protocolo Ipv6L3 es el actual
clase que implementa el protocolo. Las clases reales utilizadas por la pila de IPv6 se encuentran
principalmente en el directorio origen/internet.

La implementación de IPv6 está contenida en los siguientes archivos:

src/internet/modelo/icmpv6-header.{cc,h}
src/internet/modelo/icmpv6-l4-protocolo.{cc,h}
src/internet/modelo/ipv6.{cc,h}
src/internet/model/ipv6-address-generator.{cc,h}
src/internet/model/ipv6-autoconfigurado-prefijo.{cc,h}
src/internet/model/ipv6-punto-final.{cc,h}
src/internet/model/ipv6-punto-final-demux.{cc,h}
src/internet/modelo/ipv6-extensión.{cc,h}
src/internet/modelo/ipv6-extensión-demux.{cc,h}
src/internet/model/ipv6-extension-header.{cc,h}
src/internet/modelo/encabezado ipv6.{cc,h}
src/internet/modelo/ipv6-interfaz.{cc,h}
src/internet/model/dirección-interfaz-ipv6.{cc,h}
src/internet/modelo/ipv6-l3-protocolo.{cc,h}
src/internet/modelo/ipv6-lista-enrutamiento.{cc,h}
src/internet/modelo/opción-ipv6.{cc,h}
src/internet/modelo/ipv6-opción-demux.{cc,h}
src/internet/model/ipv6-option-header.{cc,h}
src/internet/model/ipv6-packet-info-tag.{cc,h}
src/internet/model/ipv6-pmtu-caché.{cc,h}
src/internet/model/ipv6-raw-socket-factory.{cc,h}
src/internet/model/ipv6-raw-socket-factory-impl.{cc,h}
src/internet/model/ipv6-raw-socket-impl.{cc,h}
src/internet/modelo/ruta-ipv6.{cc,h}
src/internet/model/ipv6-routing-protocol.{cc,h}
src/internet/model/ipv6-routing-table-entry.{cc,h}
src/internet/model/ipv6-static-routing.{cc,h}
src/internet/modelo/ndisc-caché.{cc,h}
src/network/utils/inet6-socket-address.{cc,h}
src/network/utils/dirección-ipv6.{cc,h}

También algunos ayudantes están involucrados con IPv6:

src/internet/helper/internet-stack-helper.{cc,h}
src/internet/helper/dirección-ipv6-helper.{cc,h}
src/internet/helper/ipv6-interfaz-contenedor.{cc,h}
src/internet/helper/ipv6-list-routing-helper.{cc,h}
src/internet/helper/ipv6-routing-helper.{cc,h}
src/internet/helper/ipv6-static-routing-helper.{cc,h}

Los archivos del modelo se pueden dividir aproximadamente en:

· modelos de protocolo (por ejemplo, ipv6, ipv6-l3-protocol, icmpv6-l4-protocol, etc.)

· modelos de enrutamiento (es decir, cualquier cosa con 'enrutamiento' en su nombre)

· sockets e interfaces (por ejemplo, ipv6-raw-socket, ipv6-interface, ipv6-end-point, etc.)

· cosas relacionadas con la dirección

· encabezados, encabezados de opción, encabezados de extensión, etc.

· clases de accesorios (por ejemplo, ndisc-cache)

Uso
La siguiente descripción se basa en el uso de los ayudantes típicos que se encuentran en el código de ejemplo.

No es necesario activar IPv6 en un nodo. se añade automáticamente a los disponibles
protocolos una vez que se instala Internet Stack.

Llene la No instalar IPv6 junto con IPv4, es posible utilizar
ns3::InternetStackHelper Método EstablecerIpv6StackInstall (bool permitir) antes de instalar el
InternetStack en los nodos.

Tenga en cuenta que para tener una red solo IPv6 (es decir, para no instalar la pila IPv4 en un nodo) uno
debe usar ns3::InternetStackHelper Método EstablecerIpv4StackInstall (bool permitir) antes de
instalación de pila.

Como ejemplo, en el siguiente código, el nodo 0 tendrá tanto IPv4 como IPv6, el nodo 1 solo tendrá
IPv6 y nodo 2 solo IPv4:

Contenedor de nodo n;
n.Crear (3);

InternetStackHelperinternet;
InternetStackHelper solo internetV4;
InternetStackHelper solo internetV6;

internetV4only.SetIpv6StackInstall (falso);
internetV6only.SetIpv4StackInstall (falso);

internet.Instalar (n.Obtener (0));
internetV6only.Install (n.Get (1));
internetV4only.Install (n.Get (2));

IPv6 direcciones asignación
Para usar IPv6 en una red, lo primero que debe hacer es asignar direcciones IPv6.

Cualquier habilitado para IPv6 ns-3 nodo tendrá al menos un NetDevice: el ns3::LoopbackNetDevice.
La dirección del dispositivo de loopback es :: 1. Todos los demás NetDevices tendrán uno o más IPv6
direcciones:

· Una dirección de enlace local: fe80::interfaz ID, donde el interfaz. ID se deriva de la
Dirección MAC de NetDevice.

· Cero o más direcciones globales, por ejemplo, 2001: db8 :: 1.

Por lo general, la primera dirección en una interfaz será la de enlace local, con la global
dirección(es) siendo las siguientes.

Las direcciones globales IPv6 pueden ser:

· asignado manualmente

· auto generado

ns-3 puede utilizar ambos métodos, y es muy importante comprender las implicaciones de
ambos.

A mano asigna IPv6 direcciones
Este es probablemente el método más fácil y más utilizado. Como ejemplo:

ptr n0 = CrearObjeto ();
ptr n1 = CrearObjeto ();
Red NodeContainer (n0, n1);
CsmaHelper csma;
NetDeviceContainer ndc = csma.Install (red);

NS_LOG_INFO ("Asignar direcciones IPv6");
Ayudante de dirección ipv6 ipv6;
ipv6.SetBase (Ipv6Address ("2001:db8::"), Ipv6Prefix (64));
Ipv6InterfaceContainer ic = ipv6.Assign (ndc);

Este método agregará dos direcciones IPv6 globales a los nodos. Tenga en cuenta que, como es habitual en IPv6,
todos los nodos también tendrán una dirección local de enlace. Por lo general, la primera dirección en un
la interfaz será la de enlace local, con la(s) dirección(es) global(es) como sigue
queridos.

Tenga en cuenta que las direcciones globales se derivarán de la dirección MAC. Como consecuencia,
esperar tener direcciones similares a 2001:db8::200:ff:fe00:1.

Es posible repetir lo anterior para asignar más de una dirección global a un nodo.
Sin embargo, debido a la Ayudante de direcciones Ipv6 naturaleza singleton, uno debe primero asignar todos los
direcciones de una red, luego cambie la red base (EstablecerBase), luego haga una nueva asignación.

Alternativamente, es posible asignar una dirección específica a un nodo:

ptr n0 = CrearObjeto ();
NodoContenedor net (n0);
CsmaHelper csma;
NetDeviceContainer ndc = csma.Install (red);

NS_LOG_INFO ("Asigne específicamente una dirección IPv6");
Ayudante de dirección ipv6 ipv6;
ptr dispositivo = ndc.Obtener (0);
ptr nodo = dispositivo->ObtenerNodo();
ptr ipv6proto = nodo->GetObject ();
int32_t siIndice = 0;
ifIndex = ipv6proto->GetInterfaceForDevice (dispositivo);
Ipv6InterfaceAddress ipv6Addr = Ipv6InterfaceAddress (Ipv6Address ("2001:db8:f00d:cafe::42"), Ipv6Prefix (64));
ipv6proto->AddAddress (ifIndex, ipv6Addr);

Auto generado IPv6 direcciones
Esto se logra confiando en el protocolo RADVD, implementado por la clase radvd. En
el tiempo no hay ayudante para esta aplicación, y el uso es bastante difícil (ver
ejemplos/ipv6/radvd.cc).

Al usar este método, los nodos adquirirán dinámicamente (es decir, durante la simulación)
una (o más) direcciones globales según la configuración de RADVD. estas direcciones
se basará en el prefijo RADVD anunciado y el EUI-64 del nodo.

Generado aleatoriamente IPv6 direcciones
Si bien los nodos reales de IPv6 utilizarán direcciones generadas aleatoriamente para proteger la privacidad, ns-3 sí
NO tiene esta capacidad. Esta característica no ha sido considerada hasta ahora como interesante para
simulación.

Duplicar Dirección Detección (DAD)
Los nodos realizarán DAD (se puede deshabilitar usando un Protocolo ICmpv6L4 atributo). Al
Sin embargo, al recibir un DAD, los nodos no reaccionarán. Como está: la reacción de DAD está incompleta, así que
lejos. La razón principal se basa en la falta de capacidad de direcciones generadas aleatoriamente. Es más,
desde ns-3 los nodos generalmente se comportarán bien, no debería haber ninguna dirección duplicada.
Esto podría cambiarse en el futuro, para evitar problemas con el mundo real integrado.
simulaciones.

Host y Router comportamiento in IPv6 y ns-3
En IPv6 hay una clara distinción entre routers y anfitriones. Como cabría esperar,
los enrutadores pueden reenviar paquetes de una interfaz a otra interfaz, mientras que los anfitriones
paquetes no dirigidos a ellos.

Desafortunadamente, el reenvío no es lo único afectado por esta distinción, y
el reenvío en sí puede ajustarse, por ejemplo, para reenviar paquetes entrantes desde una interfaz
y soltar paquetes desde otra interfaz.

In ns-3 un nodo está configurado para ser un host por defecto. Hay dos formas principales de cambiar
este comportamiento:

· Utilizando ns3::Ipv6Contenedor de interfaz Establecer reenvío (uint32_t i, bool enrutador) donde i son los
índice de interfaz en el contenedor.

· Cambiando el ns3::ipv6 atributo IpReenviar.

Cualquiera de los dos puede usarse durante la simulación.

Se puede lograr una configuración detallada usando ns3::Interfaz IPv6 EstablecerReenvío (bool
adelante); que permite cambiar el comportamiento por interfaz.

Tenga en cuenta que la configuración de todo el nodo solo sirve como un método conveniente para habilitar/deshabilitar
los ns3::Interfaz IPv6 configuración específica. Una interfaz Ipv6 agregada a un nodo con reenvío
activado se configurará para que también se reenvíe. Esto es realmente importante cuando un nodo tiene
interfaces añadidas durante la simulación.

Según la normativa ns3::Interfaz IPv6 estado de reenvío, ocurre lo siguiente:

· Reenvío APAGADO

· El nodo NO responderá a la solicitud de enrutador

· El nodo reaccionará al anuncio del enrutador

· El nodo enviará periódicamente Solicitud de enrutador

· Los protocolos de enrutamiento DEBEN DEJAR paquetes no dirigidos al nodo

· Reenvío activado

· El nodo responderá a la solicitud de enrutador

· El nodo NO reaccionará al anuncio del enrutador

· El nodo NO enviará solicitud de enrutador

· Los protocolos de enrutamiento DEBEN reenviar paquetes

El comportamiento coincide con ip-sysctl.txt (‐
http://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt) con la diferencia de que
no es posible anular el comportamiento usando configuraciones esotéricas (por ejemplo, reenviar pero
acepte anuncios de enrutador, accept_ra=2 o reenvío, pero envíe solicitudes de enrutador
reenvío=2).

Considere cuidadosamente las implicaciones del reenvío de paquetes. Como ejemplo, un nodo NO
enviar mensajes ICMPv6 PACKET_TOO_BIG desde una interfaz con reenvío desactivado. Esto es
completamente normal, ya que el protocolo de enrutamiento descartará el paquete antes de intentar
reenvíelo.

Ayudantes
Normalmente, los ayudantes que se utilizan en la configuración de IPv6 son:

· ns3::InternetStackHelper

· ns3::Ipv6AddressHelper

· ns3::Ipv6Contenedor de interfaz

El uso es casi idéntico al correspondiente caso de IPv4, por ejemplo:

Contenedor de nodo n;
n.Crear (4);

NS_LOG_INFO ("Crear pila de Internet IPv6");
InternetStackHelperinternetv6;
internetv6.Instalar (n);

NS_LOG_INFO ("Crear canales.");
CsmaHelper csma;
NetDeviceContainer d = csma.Install (n);

NS_LOG_INFO ("Crear redes y asignar direcciones IPv6.");
Ayudante de dirección ipv6 ipv6;
ipv6.SetBase (Ipv6Address ("2001:db8::"), Ipv6Prefix (64));
Ipv6InterfaceContainer iic = ipv6.Assign (d);

Además, una tarea común es habilitar el reenvío en uno de los nodos y configurar un
ruta predeterminada hacia él en los otros nodos, por ejemplo:

iic.SetForwarding (0, verdadero);
iic.SetDefaultRouteInAllNodes (0);

Esto habilitará el reenvío en el nodo. 0 y configurará una ruta predeterminada en
ns3::Ipv6Enrutamiento estático en todos los demás nodos. Tenga en cuenta que esto requiere que
Ipv6StaticRouting está presente en los nodos.

Los ayudantes de enrutamiento IPv6 permiten al usuario realizar tareas específicas en el
algoritmo de enrutamiento e imprimir las tablas de enrutamiento.

Atributos
Muchas clases en el ns-3 La implementación de IPv6 contiene atributos. Los más útiles son:

· ns3::ipv6

· IpReenviar, booleano, predeterminado falso. Habilite o deshabilite globalmente el reenvío de IP para todos
dispositivos IPv6 actuales y futuros.

· MtuDescubrir, booleano, predeterminado verdadero. Si está deshabilitado, cada interfaz tendrá su MTU
establecido en 1280 bytes.

· ns3 :: Ipv6L3Protocol

· PredeterminadoTtl, uint8_t, predeterminado 64. El valor TTL establecido de forma predeterminada en todos los paquetes salientes
generado en este nodo.

· EnviarIcmpv6Redireccionar, booleano, predeterminado verdadero. Envíe la redirección ICMPv6 cuando corresponda.

· ns3::Icmpv6L4Protocolo

· PAPÁ, booleano, predeterminado verdadero. Realice siempre una comprobación de DAD (detección de direcciones duplicadas).

· ns3::NdiscCache

· Tamaño de cola sin resolver, uint32_t, por defecto 3. Tamaño de la cola de paquetes pendientes de NA
que respondan.

Salida
La pila de IPv6 proporciona algunas fuentes de seguimiento útiles:

· ns3 :: Ipv6L3Protocol

· Tx, Envía el paquete IPv6 a la interfaz de salida.

· Rx, Reciba el paquete IPv6 de la interfaz entrante.

· Necesario, Descartar paquete IPv6.

· ns3::Extensión IPv6

· Necesario, Descartar paquete IPv6.

La última fuente de seguimiento se genera cuando un paquete contiene una opción desconocida que bloquea su
procesar.

Cuidado con eso ns3::NdiscCache podría descartar paquetes también, y no se registran en un seguimiento
fuente (todavía). Esto podría generar cierta confusión en los contadores de paquetes enviados/recibidos.

Uso
IPv6 máximas transmisión unidad (UTM) y fragmentación
ns-3 NetDevices define la MTU de acuerdo con el dispositivo simulado L2. IPv6 requiere que
la MTU mínima es de 1280 bytes, por lo que se requiere que todos los NetDevices admitan al menos esto
MTU. Este es el enlace-MTU.

Para admitir diferentes MTU en una ruta de origen-destino, ns-3 El modelo IPv6 puede
realizar la fragmentación. Esto puede activarse al recibir un paquete más grande que el
link-MTU de los protocolos L4 (UDP, TCP, etc.), o recibiendo un ICMPv6 PACKET_TOO_BIG
mensaje. El modelo imita RFC 1981, con las siguientes excepciones notables:

· Los protocolos L4 no son informados del cambio de Path MTU

· TCP no puede cambiar su tamaño de segmento según la ruta-MTU.

Ambas limitaciones se eliminarán a su debido tiempo.

La memoria caché Path-MTU se basa actualmente en las direcciones IPv6 de origen y destino. Más
las clasificaciones (p. ej., etiqueta de flujo) son posibles pero aún no se han implementado.

El tiempo de validez predeterminado de Path-MTU es de 10 minutos. Después de la expiración de la entrada de caché, el
La información de Path-MTU se elimina y el próximo paquete (eventualmente) activará un nuevo ICMPv6
mensaje PACKET_TOO_BIG. Tenga en cuenta que 1) esto es consistente con la especificación RFC y 2)
Los protocolos L4 son los encargados de retransmitir los paquetes.

Ejemplos
Los ejemplos para IPv6 están en el directorio ejemplos/ipv6. Estos ejemplos se centran en los aspectos más
peculiaridades interesantes de IPv6, como la fragmentación, la redirección, etc.

Además, la mayoría de los ejemplos de TCP y UDP ubicados en ejemplos/udp, ejemplos/tcp, etc tienen un
opción de línea de comandos para usar IPv6 en lugar de IPv4.

Diagnóstico
Solo hay algunas trampas que se deben evitar al usar ns-3 IPv6.

enrutamiento bucles
Dado que el único (hasta ahora) esquema de enrutamiento disponible para IPv6 es ns3::Ipv6Enrutamiento estático,
El enrutador predeterminado debe configurarse manualmente. Cuando hay dos o más enrutadores en una red
(por ejemplo, nodo A y nodo B), evite usar la función auxiliar Establecer ruta predeterminada en todos los nodos para
más de un enrutador.

La consecuencia sería instalar una ruta por defecto a B en A y una ruta por defecto apuntando
a A en B, generando un bucle.

Global de facturación fuga
Recuerde que las direcciones en IPv6 son global por definición. Al utilizar IPv6 con un
emulación ns-3 capacidad, evitar a toda costa la fuga de direcciones hacia la Internet global.
Es recomendable configurar un firewall externo para evitar fugas.

2001:DB8::/32 direcciones
El estándar IPv6 (RFC 3849) define el 2001:DB8::/32 clase de dirección para el documentación.
Este manual utiliza esta convención. Sin embargo, las direcciones de esta clase sólo se pueden utilizar en
un documento, y los enrutadores deben descartarlos.

Validación
Los protocolos IPv6 aún no han sido ampliamente validados contra implementaciones reales.
Las pruebas reales implican principalmente la realización de comprobaciones de los archivos de seguimiento .pcap con Wireshark,
y los resultados son positivos.

enrutamiento visión de conjunto
ns-3 está destinado a admitir enfoques y protocolos de enrutamiento tradicionales, admitir puertos de
implementaciones de enrutamiento de código abierto y facilitar la investigación sobre enrutamiento no ortodoxo
tecnicas La arquitectura general de enrutamiento se describe a continuación en enrutamiento .
Los usuarios que deseen leer acerca de cómo configurar el enrutamiento global para topologías cableadas pueden
read Global centralizado enrutamiento. Los protocolos de enrutamiento de unidifusión se describen en Unidifusión
enrutamiento. El enrutamiento de multidifusión se documenta en Multicast enrutamiento.

enrutamiento
[imagen] Resumen de enrutamiento.UNINDENT

Descripción General of enrutamiento muestra la arquitectura de enrutamiento general para IPv4. Los objetos clave son
Ipv4L3Protocol, Ipv4RoutingProtocol(s) (una clase a la que todo el enrutamiento/reenvío ha sido
delegado de Ipv4L3Protocol) e Ipv4Route(s).

Ipv4L3Protocol debe tener al menos un Ipv4RoutingProtocol agregado en la simulación
tiempo de configuración. Esto se hace explícitamente llamando a Ipv4::SetRoutingProtocol().

La clase base abstracta Ipv4RoutingProtocol () declara una interfaz mínima, que consiste
de dos métodos: RouteOutput() y RouteInput(). Para los paquetes que viajan desde
un host, el protocolo de transporte consultará Ipv4 para el objeto Ipv4RoutingProtocol
interfaz, y solicitará una ruta a través de Ipv4RoutingProtocol::RouteOutput (). un punto a
Se devuelve el objeto Ipv4Route. Esto es análogo a una entrada dst_cache en Linux. El
Ipv4Route se lleva al Ipv4L3Protocol para evitar una segunda búsqueda allí. Sin embargo,
algunos casos (por ejemplo, sockets crudos Ipv4) requerirán una llamada a RouteOutput() directamente desde
Protocolo Ipv4L3.

Para los paquetes entrantes recibidos para reenvío o entrega, se realizan los siguientes pasos.
Ipv4L3Protocol::Receive() llama a Ipv4RoutingProtocol::RouteInput(). Esto pasa el
propiedad del paquete al objeto Ipv4RoutingProtocol. Hay cuatro devoluciones de llamadas asociadas
con esta llamada:

· Entrega Local

· UnicastAdelante

· Multidifusión Adelante

· Error

El Ipv4RoutingProtocol eventualmente debe llamar a una de estas devoluciones de llamada para cada paquete que
se responsabiliza. Básicamente, así es como funciona el proceso de enrutamiento de entrada en
Linux.
[imagen] Especialización Ipv4Routing..UNINDENT

Esta arquitectura general está diseñada para admitir diferentes enfoques de enrutamiento, incluidos
(en el futuro) una implementación de enrutamiento basada en políticas similar a Linux, proactiva y
protocolos de enrutamiento bajo demanda y protocolos de enrutamiento simples para cuando el usuario de la simulación
realmente no le importa el enrutamiento.

Enrutamiento Ipv4 especialización. ilustra cómo varios protocolos de enrutamiento se derivan de esto
clase básica. Una clase Ipv4ListRouting (clase de implementación Ipv4ListRoutingImpl) proporciona
el enfoque de enrutamiento de lista existente en ns-3. Su API es la misma que la clase base.
Ipv4Routing excepto por la capacidad de agregar múltiples protocolos de enrutamiento priorizados
(Ipv4ListRouting::AddRoutingProtocol(), Ipv4ListRouting::GetRoutingProtocol()).

Los detalles de estos protocolos de enrutamiento se describen a continuación en Unidifusión enrutamiento. Por ahora,
primero comenzaremos con una capacidad básica de enrutamiento de unidifusión que está destinada a globalmente
construir tablas de enrutamiento en el tiempo de simulación t=0 para usuarios de simulación que no se preocupan por
enrutamiento dinámico.

Global centralizado enrutamiento
El enrutamiento centralizado global a veces se denomina enrutamiento "Dios"; es un especial
implementación que recorre la topología de simulación y ejecuta un algoritmo de ruta más corta, y
llena las tablas de enrutamiento de cada nodo. Sin sobrecarga de protocolo real (en los enlaces simulados)
se incurre con este enfoque. Tiene algunas limitaciones:

· Con conexión de cable sólo: No está diseñado para su uso en redes inalámbricas.

· Unidifusión sólo: No hace multidifusión.

· Escalabilidad: Algunos usuarios de esto en topologías grandes (por ejemplo, 1000 nodos) han notado que
la implementación actual no es muy escalable. El enrutamiento centralizado global será
modificado en el futuro para reducir los cálculos y el rendimiento del tiempo de ejecución.

En la actualidad, el enrutamiento de unidifusión IPv4 centralizado global tanto punto a punto como compartido
Se admiten enlaces (CSMA).

Por defecto, cuando se utiliza el ns-3 API auxiliar y el InternetStackHelper predeterminado, global
la capacidad de enrutamiento se agregará al nodo y el enrutamiento global se insertará como un
protocolo de enrutamiento con menor prioridad que las rutas estáticas (es decir, los usuarios pueden insertar rutas
a través de Ipv4StaticRouting API y tendrán prioridad sobre las rutas encontradas por global
enrutamiento).

Global Unidifusión enrutamiento API
La API pública es muy mínima. Los scripts de usuario incluyen lo siguiente:

#include "ns3 / internet-module.h"

Si se utiliza el InternetStackHelper predeterminado, se creará una instancia de enrutamiento global.
agregado a cada nodo. Después de configurar las direcciones IP, la siguiente llamada de función
hará que todos los nodos que tienen una interfaz Ipv4 reciban tablas de reenvío
introducido automáticamente por el GlobalRouteManager:

Ipv4GlobalRoutingHelper::PopulateRoutingTables ();

Nota: Un recordatorio de que el wifi NetDevice funcionará pero no tiene ningún efecto inalámbrico.
en cuenta. Para la conexión inalámbrica, recomendamos el enrutamiento dinámico OLSR que se describe a continuación.

Es posible volver a llamar a esta función en medio de una simulación usando el
siguiente función pública adicional:

Ipv4GlobalRoutingHelper::RecomputeRoutingTables ();

que vacía las tablas antiguas, consulta los nodos en busca de nueva información de interfaz y
reconstruye las rutas.

Por ejemplo, esta llamada de programación hará que las tablas se reconstruyan en un tiempo de 5 segundos:

Simulador::Horario (Segundos (5),
&Ipv4GlobalRoutingHelper::RecomputeRoutingTables);

Hay dos atributos que gobiernan el comportamiento. El primero es
Ipv4GlobalRouting::RandomEcmpRouting. Si se establece en verdadero, los paquetes se enrutan aleatoriamente a través de
rutas multitrayecto de igual costo. Si se establece en falso (predeterminado), solo una ruta es consistente
usado. El segundo es Ipv4GlobalRouting::RespondToInterfaceEvents. Si se establece en verdadero,
recalcular dinámicamente las rutas globales sobre los eventos de notificación de la interfaz (arriba/abajo, o
añadir/eliminar dirección). Si se establece en falso (predeterminado), el enrutamiento puede interrumpirse a menos que el usuario manualmente
llama a RecomputeRoutingTables() después de tales eventos. El valor predeterminado se establece en falso para preservar
legado ns-3 comportamiento del programa.

Global enrutamiento Implementación
Esta sección es para aquellos lectores que se preocupan por cómo se implementa esto. un soltero
El objeto (GlobalRouteManager) es responsable de llenar las rutas estáticas en cada nodo,
utilizando la API Ipv4 pública de ese nodo. Consulta cada nodo en la topología para un
interfaz "globalRouter". Si lo encuentra, utiliza la API de esa interfaz para obtener un "enlace
anuncio de estado (LSA)" para el enrutador. Los anuncios de estado de enlace se utilizan en OSPF
enrutamiento, y seguimos su formato.

Es importante tener en cuenta que todos estos cálculos se realizan antes de que fluyan los paquetes.
en la red. En particular, no se intercambian paquetes de sobrecarga o de control.
al usar esta implementación. En cambio, este administrador de rutas global simplemente recorre la lista de
nodos para construir la información necesaria y configurar la tabla de enrutamiento de cada nodo.

El GlobalRouteManager llena una base de datos de estado de enlace con LSA recopilados de todo el
topología Luego, para cada enrutador en la topología, GlobalRouteManager ejecuta el OSPF
primero el camino más corto (SPF) en la base de datos y llena las tablas de enrutamiento en
cada nodo.

el quagga (http://www.quagga.net) La implementación de OSPF se utilizó como base para la
lógica de cálculo de enrutamiento. Un beneficio de seguir una implementación OSPF SPF existente es
que OSPF ya ha definido anuncios de estado de enlace para todos los tipos comunes de red
la izquierda:

· punto a punto (enlaces seriales)

· punto a multipunto (Frame Relay, inalámbrico ad hoc)

· acceso múltiple sin difusión (ATM)

· difusión (Ethernet)

Por lo tanto, creemos que habilitar estos otros tipos de enlaces será más sencillo ahora.
que el marco OSPF SPF subyacente está en su lugar.

Actualmente, podemos manejar enlaces IPv4 punto a punto, numerados, así como transmisiones compartidas.
(CSMA) enlaces. También se admiten rutas múltiples de igual costo. Aunque los tipos de enlaces inalámbricos son
compatible con la implementación, tenga en cuenta que, debido a la naturaleza de esta implementación, cualquier
no se considerarán los efectos del canal y las tablas de enrutamiento supondrán que todos los nodos
en el mismo canal compartido es accesible desde cualquier otro nodo (es decir, será tratado
como un enlace CSMA de difusión).

El GlobalRouteManager primero recorre la lista de nodos y agrega un GlobalRouter
interfaz a cada uno de la siguiente manera:

typedef estándar::vector < Ptr >::iterador Iterador;
for (Iterador i = NodeList::Begin (); i != NodeList::End (); i++)
{
ptr nodo = *i;
ptr globalRouter = CrearObjeto (nodo);
nodo->AgregateObject (globalRouter);
}

Esta interfaz se consulta más tarde y se utiliza para generar un anuncio de estado de enlace para cada
enrutador, y esta base de datos de estado de enlace se alimenta a la lógica de cálculo de la ruta más corta OSPF.
La API Ipv4 finalmente se usa para completar las rutas.

Unidifusión enrutamiento
Actualmente hay siete protocolos de enrutamiento de unidifusión definidos para IPv4 y tres para IPv6:

· clase Ipv4StaticRouting (que cubre tanto unidifusión como multidifusión)

· IPv4 Optimized Link State Routing (OLSR) (un protocolo MANET definido en RFC 3626)

· IPv4 Ad Hoc On Demand Distance Vector (AODV) (un protocolo MANET definido en RFC 3561)

· Vector de distancia secuenciada de destino IPv4 (DSDV) (un protocolo MANET)

· IPv4 Dynamic Source Routing (DSR) (un protocolo MANET)

· clase Ipv4ListRouting (usada para almacenar una lista priorizada de protocolos de enrutamiento)

· clase Ipv4GlobalRouting (utilizada para almacenar rutas calculadas por el administrador de rutas global, si
que se usa)

· clase Ipv4NixVectorRouting (una versión más eficiente de enrutamiento global que almacena
rutas de origen en un campo de encabezado de paquete)

· clase Ipv6ListRouting (usada para almacenar una lista priorizada de protocolos de enrutamiento)

· clase Ipv6StaticRouting

· clase RipNg - el protocolo IPv6 RIPng (RFC 2080)

En el futuro, esta arquitectura también debería permitir que alguien implemente un sistema similar a Linux.
implementación con caché de enrutamiento o un enrutador modular Click, pero están fuera del alcance
por ahora.

Ipv[4,6]Enrutamiento de lista
Esta sección describe el valor predeterminado actual ns-3 Ipv[4,6]Protocolo de enrutamiento. Típicamente,
Se admiten varios protocolos de enrutamiento en el espacio del usuario y se coordinan para escribir uno solo.
tabla de reenvío en el kernel. actualmente en ns-3, la implementación en cambio permite
múltiples protocolos de enrutamiento para construir/mantener su propio estado de enrutamiento, y la IP
La implementación consultará cada uno de estos protocolos de enrutamiento (en algún orden determinado por
el autor de la simulación) hasta que se encuentre una ruta.

Elegimos este enfoque porque puede facilitar mejor la integración de diferentes
enfoques de enrutamiento que pueden ser difíciles de coordinar la escritura en una sola tabla,
enfoques en los que se necesita más información que la dirección IP de destino (p. ej., enrutamiento de origen).
se utiliza para determinar el próximo salto y los enfoques de enrutamiento bajo demanda donde los paquetes deben ser
en caché.

Ipv[4,6]4ListRouting::Agregar protocolo de enrutamiento
Las clases Ipv4ListRouting e Ipv6ListRouting proporcionan una declaración de función virtual pura
para el método que permite agregar un protocolo de enrutamiento:

void AddRoutingProtocol (Ptr protocolo de enrutamiento,
prioridad int16_t);

void AddRoutingProtocol (Ptr protocolo de enrutamiento,
prioridad int16_t);

Estos métodos son implementados respectivamente por la clase Ipv4ListRoutingImpl y por la clase
Ipv6ListRoutingImpl en el módulo de internet.

La variable de prioridad anterior gobierna la prioridad en la que los protocolos de enrutamiento son
insertado. Tenga en cuenta que es un int firmado. Por defecto en ns-3, las clases auxiliares
crear una instancia de un objeto Ipv[4,6]ListRoutingImpl y agregarle un Ipv[4,6]StaticRoutingImpl
objeto con prioridad cero. Internamente, se almacena una lista de Ipv[4,6]RoutingProtocols, y
y los protocolos de enrutamiento se consultan en orden decreciente de prioridad para ver
si se encuentra una coincidencia. Por lo tanto, si desea que su Ipv4RoutingProtocol tenga prioridad
más bajo que el enrutamiento estático, insértelo con prioridad menor que 0; p.ej:

ptr myRoutingProto = CreateObject ();
listRoutingPtr->AddRoutingProtocol (myRoutingProto, -10);

Tras las llamadas a RouteOutput() o RouteInput(), el objeto de enrutamiento de la lista buscará en la lista
de protocolos de enrutamiento, en orden de prioridad, hasta que se encuentre una ruta. Tal protocolo de enrutamiento
invocará la devolución de llamada adecuada y no se buscarán más protocolos de enrutamiento.

Optimizado Enlace Estado enrutamiento (OLSR)
Este protocolo de enrutamiento IPv4 se transfirió originalmente de la implementación OLSR-UM para ns-2.
La implementación se encuentra en el directorio src/olsr, y un script de ejemplo está en
ejemplos/simple-punto-a-punto-olsr.cc.

Por lo general, OLSR se habilita en un programa principal mediante el uso de una clase OlsrHelper que instala
OLSR en un objeto Ipv4ListRoutingProtocol. Los siguientes comandos de muestra habilitarán
OLSR en una simulación usando esta clase auxiliar junto con algunos otros objetos auxiliares de enrutamiento.
La configuración del valor de prioridad 10, por delante de la prioridad staticRouting de 0, significa que
Se consultará OLSR para una ruta antes de la tabla de enrutamiento estático del nodo.:

Contenedor de nodo c:
...
// Habilitar OLSR
NS_LOG_INFO ("Habilitación del enrutamiento OLSR");
OlsrHelper olsr;

Ipv4StaticRoutingHelper staticRouting;

lista Ipv4ListRoutingHelper;
list.Add (enrutamiento estático, 0);
lista.Añadir (olsr, 10);

InternetStackHelperinternet;
internet.SetRoutingHelper (lista);
internet.Instalar (c);

Una vez instalada, la "interfaz principal" de OLSR se puede configurar con el comando SetMainInterface().
Si el usuario no especifica una dirección principal, el protocolo seleccionará la primera IP primaria
dirección que encuentra, comenzando primero la interfaz loopback y luego la siguiente
interfaz sin loopback encontrada, en orden de índice de interfaz Ipv4. La dirección de bucle invertido de
127.0.0.1 no está seleccionado. Además, una serie de constantes de protocolo se definen en
olsr-enrutamiento-protocol.cc.

Olsr se inicia en el momento cero de la simulación, en función de una llamada a Object::Start() que
eventualmente llama a OlsrRoutingProtocol::DoStart(). Nota: un parche para permitir que el usuario comience
y detener el protocolo en otros momentos sería bienvenido.

Actualmente, OLSR se limita a su uso con un objeto Ipv4ListRouting y no responde a
cambios dinámicos en la dirección IP de un dispositivo o notificaciones de conexión/desconexión; es decir, la topología
los cambios se deben a la pérdida/ganancia de conectividad a través de un canal inalámbrico.

RIPng
Este protocolo de enrutamiento IPv6 (RFC 2080) es la evolución de los conocidos RIPv1 y RIPv2
(consulta: RFC 1058 y RFC 1723) protocolos de enrutamiento para IPv4.

El protocolo es muy simple y normalmente es adecuado para redes planas y simples.
topologías.

RIPng se basa fuertemente en RIPv1 y RIPv2, y tiene los mismos objetivos y
limitaciones. En particular, RIP considera cualquier ruta con una métrica igual o mayor a 16
como inalcanzable. Como consecuencia, el número máximo de saltos de la red debe ser menor
de 15 (el número de enrutadores no está configurado). Se anima a los usuarios a leer RFC 2080 y RFC
1058 para comprender completamente el comportamiento y las limitaciones de RIPng.

enrutamiento convergencia
RIPng utiliza un algoritmo de vector de distancia y las rutas se actualizan de acuerdo con el
Algoritmo de Bellman-Ford (a veces conocido como algoritmo de Ford-Fulkerson). El algoritmo tiene un
tiempo de convergencia de O(|V|*|E|) donde |V| y |E| son el número de vértices (enrutadores) y
bordes (enlaces) respectivamente. Cabe destacar que el tiempo de convergencia es el número
de pasos en el algoritmo, y cada paso es desencadenado por un mensaje. Desde activado
Las actualizaciones (es decir, cuando se cambia una ruta) tienen un tiempo de reutilización de 1 a 5 segundos, la topología puede
necesitan un tiempo para estabilizarse.

Los usuarios deben tener en cuenta que, durante la construcción de las tablas de enrutamiento, los enrutadores pueden dejar de funcionar.
paquetes El tráfico de datos debe enviarse solo después de un tiempo lo suficientemente largo como para permitir que se genere RIPng.
la topología de la red. Por lo general, 80 segundos deberían ser suficientes para tener un resultado subóptimo (pero
trabajando) configuración de enrutamiento. Esto incluye el tiempo necesario para propagar las rutas a los más
enrutador distante (16 saltos) con actualizaciones activadas.

Si se cambia la topología de la red (por ejemplo, se rompe un enlace), el tiempo de recuperación puede ser
bastante alto, y podría ser incluso mayor que el tiempo de configuración inicial. Es más, la red
la recuperación de la topología se ve afectada por la estrategia Split Horizoning.

El ejemplo ejemplos/enrutamiento/ripng-simple-network.cc muestra tanto la configuración de la red como
Fases de recuperación de la red.

Dividida Horizonte
Split Horizon es una estrategia para evitar la inestabilidad del enrutamiento. Tres opciones son posibles:

· Sin horizonte dividido

· Horizonte dividido

· Veneno al revés

En el primer caso, las rutas se anuncian en todas las interfaces del enrutador. En el segundo
En este caso, los enrutadores no anunciarán una ruta en la interfaz de la que se aprendió.
Poison Reverse anunciará la ruta en la interfaz desde la que se aprendió, pero
con una métrica de 16 (infinito). Para un análisis completo de las tres técnicas, véase RFC
1058, sección 2.2.

El ejemplo ripng-simple-network.cc se basa en la topología de red descrita en el RFC,
pero no muestra el efecto allí descrito.

La razón son las actualizaciones desencadenadas, junto con el hecho de que cuando un enrutador
invalida una ruta, inmediatamente propagará la inaccesibilidad de la ruta, por lo tanto
previniendo la mayoría de los problemas descritos en el RFC.

Sin embargo, con topologías complejas, todavía es posible tener fenómenos de inestabilidad de rutas.
similar al descrito en el RFC después de una falla en el enlace. Como consecuencia, todos los
consideraciones sobre Split Horizon sigue siendo válida.

"Predeterminado" rutas
Se debe instalar el protocolo RIPng only en enrutadores. Como consecuencia, los nodos no sabrán
¿Cuál es el enrutador predeterminado?

Para superar esta limitación, los usuarios deben instalar la ruta predeterminada manualmente (por ejemplo,
recurriendo a Ipv6StaticRouting), o utilizando RADVd. RADVd está disponible en ns-3 en la categoría Industrial.
Módulo de aplicaciones, y es muy recomendable.

Protocolo parámetros y opciones
El RIPng ns-3 la implementación permite cambiar todos los temporizadores asociados con la ruta
actualizaciones y rutas de por vida.

Además, los usuarios pueden cambiar las métricas de la interfaz por nodo.

El tipo de Split Horizoning (para evitar rutas de propagación hacia atrás) se puede seleccionar en un
por nodo, con las opciones "sin horizonte dividido", "horizonte dividido" y "poison
inversa". Ver RFC 2080 para más detalles, y RFC 1058 para una discusión completa sobre el
estrategias de horizonte dividido.

Limitaciones
No hay soporte para la opción Siguiente salto (RFC 2080, Sección 2.1.1). El próximo salto
La opción es útil cuando RIPng no se ejecuta en todos los enrutadores de una red. Apoyo
ya que esta opción puede ser considerada en el futuro.

No hay soporte para la agregación de prefijos CIDR. Como resultado, tanto las tablas de enrutamiento como
los anuncios de ruta pueden ser más grandes de lo necesario. La agregación de prefijos se puede agregar en el
futuro.

Multicast enrutamiento
La siguiente función se utiliza para agregar una ruta de multidifusión estática a un nodo:

vacío
Ipv4StaticRouting::AddMulticastRoute (origen de IPv4Address,
grupo de direcciones Ipv4,
interfaz de entrada uint32_t,
estándar::vector interfaces de salida);

Una ruta de multidifusión debe especificar una dirección IP de origen, un grupo de multidifusión y una entrada
índice de interfaz de red como condiciones y proporciona un vector de interfaz de red de salida
índices sobre los que se envían los paquetes que cumplen las condiciones.

Por lo general, hay dos tipos principales de rutas de multidifusión: se utilizan rutas del primer tipo
durante el reenvío. Todas las condiciones deben ser proporcionadas explícitamente. El segundo tipo de
Las rutas se utilizan para sacar paquetes de un nodo local. La diferencia está en la entrada.
interfaz. Las rutas para el reenvío siempre tendrán una interfaz de entrada explícita especificada.
Las rutas fuera de un nodo siempre establecerán la interfaz de entrada en un comodín especificado por el
índice Ipv4RoutingProtocol::IF_INDEX_ANY.

Para rutas fuera de un nodo local, se pueden usar comodines en el grupo de origen y multidifusión
direcciones. El comodín utilizado para Ipv4Adresses es la dirección devuelta por
Ipv4Address::GetAny () -- típicamente "0.0.0.0". El uso de un comodín permite especificar
comportamiento predeterminado en diversos grados.

Por ejemplo, convertir la dirección de origen en un comodín, pero dejar el grupo de multidifusión
específico permite (en el caso de un nodo con múltiples interfaces) crear diferentes
enruta utilizando diferentes interfaces de salida para cada grupo de multidifusión.

Si las direcciones de origen y multidifusión se convierten en comodines, ha creado esencialmente un
dirección de multidifusión predeterminada que puede reenviar a múltiples interfaces. Compara esto con el
dirección de multidifusión predeterminada real que se limita a especificar una sola interfaz de salida
para la compatibilidad con la funcionalidad existente en otros sistemas.

Otro comando establece la ruta de multidifusión predeterminada:

vacío
Ipv4StaticRouting::SetDefaultMulticastRoute (uint32_t interfaz de salida);

Este es el equivalente de multidifusión de la versión de unidifusión SetDefaultRoute. Le decimos al
sistema de enrutamiento qué hacer en el caso de que una ruta específica a un destino de multidifusión
no se encuentra el grupo. El sistema reenvía paquetes a través de la interfaz especificada con la esperanza
ese "algo ahí fuera" sabe mejor cómo enrutar el paquete. Este método solo se utiliza
en el envío inicial de paquetes fuera de un host. No se consulta la ruta multicast por defecto
durante el reenvío: las rutas exactas deben especificarse utilizando AddMulticastRoute para ese caso.

Dado que básicamente estamos enviando paquetes a alguna entidad que creemos que puede saber mejor qué hacer,
no prestamos atención a "sutilezas" como la dirección de origen, ni nos preocupamos por
reenviar múltiples interfaces. Si se establece la ruta de multidifusión predeterminada, se devuelve
como la ruta seleccionada de LookupStatic independientemente del origen o grupo de multidifusión si
no se encuentra otra ruta específica.

Finalmente, se proporcionan una serie de funciones adicionales para obtener y eliminar multicast.
rutas:

uint32_t GetNMulticastRoutes (void) const;

Ipv4MulticastRoute *GetMulticastRoute (uint32_ti) const;

Ipv4MulticastRoute *GetDefaultMulticastRoute (void) const;

bool RemoveMulticastRoute (origen de la dirección Ipv4,
grupo de direcciones Ipv4,
interfaz de entrada uint32_t);

void RemoveMulticastRoute (índice uint32_t);

TCP modelos in ns-3
Este capítulo describe los modelos TCP disponibles en ns-3.

Generic Apoyar para TCP
ns-3 fue escrito para admitir múltiples implementaciones de TCP. Las implementaciones heredan de
algunas clases de encabezado comunes en el origen/red directorio, para que el código de usuario pueda intercambiar
implementaciones con cambios mínimos en los scripts.

Hay dos clases base abstractas importantes:

· clase TcpSocket: Esto se define en src/internet/modelo/tcp-socket.{cc,h}. Esta clase
existe para alojar atributos TcpSocket que se pueden reutilizar en diferentes
implementaciones. Por ejemplo, el atributo Cwnd inicial puede usarse para cualquiera de los
implementaciones que se derivan de la clase TcpSocket.

· clase TcpSocketFábrica: Esto es utilizado por la instancia del protocolo de capa 4 para crear TCP
enchufes del tipo correcto.

Actualmente hay tres implementaciones de TCP disponibles para ns-3.

· un TCP implementado de forma nativa para ns-3

· apoyo a la Nuestra Red Simulación Soporte (NSC)

· apoyo para Directo Código ejecución (EDC)

También se debe mencionar que varias formas de combinar máquinas virtuales con ns-3
pone a disposición también algunas implementaciones de TCP adicionales, pero están fuera del alcance de
Este capítulo.

ns-3 TCP
Hasta el lanzamiento de ns-3.10, ns-3 contenía un puerto del modelo TCP de GTNetS. Esto
Adriam Tam reescribió sustancialmente la implementación para ns-3.10. El modelo es completo
TCP, en el sentido de que es bidireccional e intenta modelar la configuración y el cierre de la conexión
lógica.

La implementación de TCP está contenida en los siguientes archivos:

src/internet/modelo/tcp-header.{cc,h}
src/internet/modelo/tcp-l4-protocolo.{cc,h}
src/internet/model/tcp-socket-factory-impl.{cc,h}
src/internet/modelo/tcp-socket-base.{cc,h}
src/internet/modelo/tcp-tx-buffer.{cc,h}
src/internet/modelo/tcp-rx-buffer.{cc,h}
src/internet/modelo/tcp-rfc793.{cc,h}
src/internet/modelo/tcp-tahoe.{cc,h}
src/internet/modelo/tcp-reno.{cc,h}
src/internet/modelo/tcp-westwood.{cc,h}
src/internet/modelo/tcp-newreno.{cc,h}
src/internet/modelo/rtt-estimador.{cc,h}
src/red/modelo/número-de-secuencia.{cc,h}

Se admiten diferentes variantes de control de congestión de TCP subclasificando la base común
clase TCPSocketBase. Se admiten varias variantes, incluidas RFC 793 (sin congestión
control), Tahoe, Reno, Westwood, Westwood+ y NewReno. NewReno se utiliza de forma predeterminada. Ver
la sección Uso de este documento para saber cómo cambiar la variante de TCP predeterminada utilizada en
simulación.

Uso
En muchos casos, el uso de TCP se establece en la capa de aplicación diciéndole al ns-3
aplicación qué tipo de fábrica de enchufes usar.

Usando las funciones auxiliares definidas en src/aplicaciones/ayudante y src/red/ayudante, aquí
es cómo se crearía un receptor TCP:

// Crear un sumidero de paquetes en la estrella "hub" para recibir estos paquetes
puerto uint16_t = 50000;
Dirección sumideroLocalAddress(InetSocketAddress (Ipv4Address::GetAny()), puerto));
PacketSinkHelper sinkHelper ("ns3::TcpSocketFactory", sinkLocalAddress);
Contenedor de aplicación SinkApp = SinkHelper.Install (ServerNode);
SinkApp.Start (Segundos (1.0));
SinkApp.Stop (Segundos (10.0));

De manera similar, el siguiente fragmento configura la fuente de tráfico OnOffApplication para usar TCP:

// Crear las aplicaciones OnOff para enviar TCP al servidor
OnOffHelper clientHelper ("ns3::TcpSocketFactory", Dirección ());

El lector cuidadoso notará arriba que hemos especificado el TypeId de una base abstracta
clase TcpSocketFábrica. ¿Cómo dice el guión? ns-3 que quiere al nativo ns-3 TCP
contra algún otro? Bueno, cuando se agregan pilas de Internet al nodo, el TCP predeterminado
implementación que se agrega al nodo es el ns-3 TCP. Esto se puede anular como
mostramos a continuación cuando usamos Network Simulation Cradle. Entonces, por defecto, al usar el ns-3
API auxiliar, el TCP que se agrega a los nodos con una pila de Internet es el nativo ns-3
TCP

Para configurar el comportamiento de TCP, se exportan una serie de parámetros a través del ns-3
sistema de atributos. Estos están documentados en el Doxygen
<http://www.nsnam.org/doxygen/classns3_1_1_tcp_socket.html> para clase TcpSocket. For
ejemplo, el tamaño máximo del segmento es un atributo configurable.

Para establecer el tipo de socket predeterminado antes de que se cree cualquier objeto relacionado con la pila de Internet, uno
puede poner la siguiente declaración en la parte superior del programa de simulación:

Config::SetDefault ("ns3::TcpL4Protocol::SocketType", StringValue ("ns3::TcpTahoe"));

Para los usuarios que deseen tener un puntero al socket real (para que las operaciones de socket como
Bind(), la configuración de las opciones de socket, etc. se puede hacer por socket), los sockets Tcp pueden
ser creado usando el Zócalo::CrearSocket() método. El TypeId pasado a
CreateSocket() debe ser del tipo ns3::Fábrica de sockets, por lo que configurar el socket subyacente
El tipo debe hacerse girando el atributo asociado con el TcpL4Protocol subyacente
objeto. La forma más fácil de llegar a esto sería a través de la configuración de atributos
sistema. En el siguiente ejemplo, se accede al contenedor de nodo "n0n1" para obtener el cero
y se crea un socket en este nodo:

// Crear y enlazar el socket...
TypeId tid = TypeId::LookupByName ("ns3::TcpTahoe");
Config::Set ("/NodeList/*/$ns3::TcpL4Protocol/SocketType", TypeIdValue (tid));
ptr enchufe local =
Socket::CreateSocket (n0n1.Get (0), TcpSocketFactory::GetTypeId ());

Arriba, el comodín "*" para el número de nodo se pasa al sistema de configuración de atributos,
para que todos los sockets futuros en todos los nodos se establezcan en Tahoe, no solo en el nodo 'n0n1.Get (0)'.
Si uno quiere limitarlo solo al nodo especificado, tendría que hacer algo como:

// Crear y enlazar el socket...
TypeId tid = TypeId::LookupByName ("ns3::TcpTahoe");
std::stringstream nodoId;
nodeId << n0n1.Get (0)->GetId ();
std::string specificNode = "/NodeList/" + nodeId.str () + "/$ns3::TcpL4Protocol/SocketType";
Config::Set (nodo específico, TypeIdValue (tid));
ptr enchufe local =
Socket::CreateSocket (n0n1.Get (0), TcpSocketFactory::GetTypeId ());

Una vez que se crea un socket TCP, uno querrá seguir la lógica de socket convencional y
connect() y send() (para un cliente TCP) o bind(), listen() y accept() (para un cliente TCP)
servidor). Consulte Sockets-API para obtener una revisión de cómo se utilizan los sockets en ns-3.

Validación
Varios resultados de la prueba de validación de TCP se pueden encontrar en el wiki página describiendo esto
puesta en práctica.

Current limitaciones
· SACK no es compatible

Nuestra Red Simulación Soporte
La Nuestra Red Simulación Soporte (NSC) es un marco para envolver código de red del mundo real
en simuladores, lo que permite la simulación del comportamiento del mundo real a un costo adicional mínimo. Esta
trabajo ha sido validado mediante la comparación de situaciones utilizando una red de prueba con el mismo
situaciones en el simulador. Hasta la fecha, se ha demostrado que el NSC es capaz de producir
resultados extremadamente precisos. NSC admite cuatro pilas del mundo real: FreeBSD, OpenBSD, lwIP
y Linux. Se ha puesto énfasis en no cambiar ninguna de las pilas de red a mano. No
se ha cambiado una sola línea de código en las implementaciones del protocolo de red de cualquiera de
las cuatro pilas anteriores. Sin embargo, se creó un analizador C personalizado para cambiar mediante programación
código fuente.

NSC ha sido previamente portado a ns-2 y OMNeT++, y se agregó a ns-3 en septiembre
2008 (versión ns-3.2). Esta sección describe el ns-3 puerto de NSC y cómo usarlo.

Hasta cierto punto, NSC ha sido reemplazado por el soporte del kernel de Linux dentro de Directo Código
Ejecución (EDC). Sin embargo, NSC todavía está disponible a través del sistema de compilación de horneado. NSC
es compatible con los kernels de Linux 2.6.18 y 2.6.26, pero no se han publicado versiones más recientes del kernel.
portado.

Requisitos previos
Actualmente, NSC ha sido probado y se ha demostrado que funciona en estas plataformas: Linux i386 y Linux
x86-64. NSC no admite powerpc. El uso en FreeBSD o OS X no es compatible (aunque
puede ser capaz de trabajar).

Construir NSC requiere los paquetes flex y bison.

Configurando y Descarga de
A partir de ns-3.17 o posterior, NSC debe descargarse por separado de su propio repositorio,
o descargar cuando se utiliza el cocción construimos te of ns-3.

Para versiones ns-3.17 o posteriores, cuando se usa hornear, se debe configurar NSC como parte de un
configuración "allinona", como:

$ cd hornear
$ python hornear.py configure -e ns-allinone-3.19
$ python bake.py descargar
$ python hornear.py construir

En lugar de una versión lanzada, se puede usar la versión de desarrollo ns-3 especificando
"ns-3-allinone" al paso de configuración anterior.

NSC también se puede descargar desde Debido descargar site utilizando Mercurial:

$hg clon https://secure.wand.net.nz/mercurial/nsc

Antes del lanzamiento de ns-3.17, NSC estaba incluido en el tarball allinone y el lanzamiento
La versión no necesitaba ser descargada por separado.

Contruyendo y validando
NSC puede construirse como parte del proceso de construcción de horneado; alternativamente, uno puede construir NSC por
mismo usando su sistema de compilación; p.ej:

$ cd nsc-dev
$ python scons.py

Una vez que NSC se haya construido manualmente o a través del sistema de horneado, cambie al ns-3
directorio de origen e intente ejecutar la siguiente configuración:

$ ./waf configurar

Si waf creó y encontró NSC previamente, verá:

Cuna de simulación de red: habilitada

Si no se ha encontrado NSC, verá:

Base de simulación de red: no habilitado (NSC no encontrado (consulte la opción --con-nsc))

En este caso, debe pasar la ruta relativa o absoluta a las bibliotecas NSC con el
opción de configuración "--with-nsc"; p.ej

$ ./waf configure --with-nsc=/ruta/a/mi/nsc/directorio

Para transferencias ns-3 versiones anteriores a la versión ns-3.17, utilizando el construir.py script en ns-3-allinone
directorio, NSC se compilará de manera predeterminada a menos que la plataforma no lo admita. Para
desactivarlo explícitamente al construir ns-3, tipo:

$ ./waf configurar --enable-examples --enable-tests --disable-nsc

Si waf detecta NSC, entonces la construcción ns-3 con NSC se realiza de la misma manera con waf que
sin ello. Una vez ns-3 está construido, intente ejecutar el siguiente conjunto de pruebas:

$ ./test.py -s ns3-tcp-interoperabilidad

Si NSC se ha creado con éxito, la siguiente prueba debería aparecer en los resultados:

PASS TestSuite ns3-tcp-interoperabilidad

Esto confirma que NSC está listo para usar.

Uso
Hay algunos archivos de ejemplo. Tratar:

$ ./waf --ejecutar tcp-nsc-zoo
$ ./waf --ejecutar tcp-nsc-lfn

Estos ejemplos depositarán algunos .pcap archivos en su directorio, que pueden ser examinados por
tcpdump o wireshark.

Echemos un vistazo al ejemplos/tcp/tcp-nsc-zoo.cc archivo para algunos usos típicos. Cómo lo hace
difieren del uso nativo ns-3 TCP? Hay una línea de configuración principal, cuando se usa NSC
así como el ns-3 API de ayuda, que debe configurarse:

InternetStackHelper InternetStack;

internetStack.SetNscStack ("liblinux2.6.26.so");
// esto cambia los nodos 0 y 1 a la pila NSC de Linux 2.6.26.
internetStack.Instalar (n.Obtener(0));
internetStack.Instalar (n.Obtener(1));

La línea clave es la EstablecerNscPila. Esto le dice al ayudante de InternetStack que agregue
instancias de NSC TCP en lugar de nativo ns-3 TCP a los nodos restantes. Es importante
que esta función se llame antes llamando al Instalar en pc() función, como se muestra arriba.

¿Qué pilas están disponibles para usar? Actualmente, la atención se ha centrado en Linux 2.6.18 y Linux
2.6.26 acumulaciones para ns-3. Para ver qué pilas se construyeron, se puede ejecutar la siguiente búsqueda
comando en el ns-3 directorio de nivel superior:

$ buscar nsc -nombre "*.so" -tipo f
nsc/linux-2.6.18/liblinux2.6.18.so
nsc/linux-2.6.26/liblinux2.6.26.so

Esto nos dice que podemos pasar el nombre de la biblioteca liblinux2.6.18.so o
liblinux2.6.26.so al paso de configuración anterior.

Apilar configuración
NSC TCP comparte los mismos atributos de configuración que son comunes en los sockets TCP, como
descrito anteriormente y documentado en Doxygen

Además, NSC TCP exporta muchas variables de configuración al ns-3 atributos
sistema, a través de un sysctl-interfaz similar. En el ejemplos/tcp/tcp-nsc-zoo ejemplo, puedes ver
la siguiente configuración:

// esto deshabilita TCP SACK, wscale y timestamps en el nodo 1 (los atributos
representan valores sysctl).
Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_sack",
valor de cadena ("0"));
Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_timestamps",
valor de cadena ("0"));
Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_window_scaling",
valor de cadena ("0"));

Estas variables de configuración adicionales no están disponibles para usuarios nativos. ns-3 TCP

También tenga en cuenta que los valores predeterminados para los atributos TCP en ns-3 TCP puede diferir del nsc TCP
implementación. Específicamente en ns-3:

1. El MSS predeterminado de TCP es 536

2. El recuento de acuse de recibo retardado de TCP es 2

Por lo tanto, al hacer comparaciones entre los resultados obtenidos usando nsc y ns-3 TCP, cuidado
deben tomarse medidas para garantizar que estos valores se establezcan correctamente. Ver
/examples/tcp/tcp-nsc-comparision.cc para ver un ejemplo.

NSC API
Esta subsección describe la API que NSC presenta a ns-3 o cualquier otro simulador. NSC
proporciona su API en forma de una serie de clases que se definen en
sim/interfaz_sim.h en el directorio nsc.

· INetStack INetStack contiene las operaciones de "bajo nivel" para la red del sistema operativo
pila, por ejemplo, funciones de entrada y salida desde y hacia la pila de red (piense en esto como la
'interfaz de controlador de red'. También hay funciones para crear nuevos sockets TCP o UDP.

· ISendCallback Esto es llamado por NSC cuando se debe enviar un paquete a la red.
Este simulador debe usar esta devolución de llamada para volver a inyectar el paquete en el simulador para que
los datos reales pueden ser entregados/enrutados a su destino, donde eventualmente serán
entregado en Receive () (y eventualmente de vuelta a la instancia NSC del receptor a través de
INetStack->if_receive() ).

· INetStreamSocket Esta es la estructura que define un punto final de conexión particular (archivo
descriptor). Contiene métodos para operar en este punto final, por ejemplo, conectar, desconectar,
aceptar, escuchar, enviar_datos/leer_datos, ...

· IInterrupciónDevolución de llamada Contiene la devolución de llamada de activación, a la que llama NSC cada vez que
ocurre algo de interés. Piense en wakeup() como un reemplazo de la operación
función de activación de sistemas: cada vez que el sistema operativo activa un proceso que ha
estado esperando que se complete una operación (por ejemplo, el protocolo de enlace TCP durante
connect()), NSC invoca la devolución de llamada wakeup() para permitir que el simulador verifique el estado
cambios en sus puntos finales de conexión.

ns-3 implementación
La ns-3 La implementación hace uso de la API NSC anterior y se implementa de la siguiente manera.

Las tres partes principales son:

· ns3::NscTcpL4Protocolo: una subclase de Ipv4L4Protocol (y dos clases nsc: ISendCallback
y IInterruptCallback)

· ns3::NscTcpSocketImpl: una subclase de TcpSocket

· ns3::NscTcpSocketFactoryImpl: una fábrica para crear nuevos sockets NSC

src/internet/modelo/nsc-tcp-l4-protocolo es la clase principal. Tras la inicialización, carga un
pila de red nsc para usar (a través de dlopen()). Cada instancia de esta clase puede usar un diferente
apilar. La pila (=biblioteca compartida) a usar se configura usando el método SetNscLibrary() (en este
vez que se llama indirectamente a través del asistente de pila de Internet). Luego se configura la pila nsc
en consecuencia (temporizadores, etc.). La función NscTcpL4Protocol::Receive() entrega el paquete
recibe (debe ser un paquete tcp/ip completo) a la pila nsc para su posterior procesamiento. Para
poder enviar paquetes, esta clase implementa el método nsc send_callback. Este método
es llamado por nsc cada vez que la pila nsc desea enviar un paquete a la red. Su
Los argumentos son un búfer sin procesar que contiene un paquete TCP/IP completo y un valor de longitud. Esta
por lo tanto, el método tiene que convertir los datos sin procesar a un Ptr utilizable por ns-3. A fin de que
evite varios problemas de encabezado ipv4, el encabezado ip nsc no está incluido. En cambio, el tcp
el encabezado y la carga útil real se colocan en el Ptr , después de esto el paquete es
pasa a la capa 3 para enviar el paquete (no se necesita ningún tratamiento especial adicional)
en la ruta del código de envío).

Esta clase llama ns3::NscTcpSocketImpl tanto desde la devolución de llamada de nsc wakeup() como desde el
Ruta de recepción (para asegurarse de que los datos posiblemente en cola estén programados para enviarse).

src/internet/modelo/nsc-tcp-socket-impl implementa la interfaz de socket nsc. cada instancia
tiene su propio nscTcpSocket. Los datos que se envían () se entregarán a la pila nsc a través de
m_nscTcpSocket->send_data(). (y no a nsc-tcp-l4, esta es la principal diferencia en comparación
a ns-3 TCP). La clase también pone en cola los datos que son Send() antes que los subyacentes.
el descriptor ha entrado en un estado ESTABLECIDO. Esta clase se llama desde el nsc-tcp-l4
class, cuando nsc invoca la devolución de llamada nsc-tcp-l4 wakeup(). nsc-tcp-socket-impl luego
comprueba el estado actual de la conexión (SYN_SENT, ESTABLISHED, LISTEN...) y programa
devoluciones de llamada apropiadas según sea necesario, por ejemplo, un socket LISTEN programará Aceptar para ver si un nuevo
debe aceptarse la conexión, un socket ESTABLECIDO programa cualquier dato pendiente para escritura,
programar una devolución de llamada de lectura, etc.

Tenga en cuenta que ns3::NscTcpSocketImpl no interactúa con nsc-tcp directamente: en cambio, los datos son
redirigido a nsc. nsc-tcp llama a los nsc-tcp-sockets de un nodo cuando su devolución de llamada de activación es
invocado por nsc.

Limitaciones
· NSC solo funciona en nodos de interfaz única; intentando ejecutarlo en un nodo multi-interfaz
provocará un error de programa.

· Cygwin y OS X PPC no son compatibles; OS X Intel no es compatible pero puede funcionar

· Las pilas de NSC que no son de Linux no se admiten en ns-3

· No se admiten todas las devoluciones de llamada API de socket

Para más información, consulte la este vídeo wiki página.

Código cola implementación in ns-3
Este capítulo describe la implementación de la cola CoDel ([Nic12], [Nic14]) en ns-3.

Desarrollado por Kathleen Nichols y Van Jacobson como una solución al bufferbloat [Buf14]
problema, CoDel (Controlled Delay Management) es una disciplina de cola que utiliza un paquete
tiempo de permanencia (tiempo en cola) para tomar decisiones sobre caídas de paquetes.

Modelo Descripción
El código fuente del modelo CoDel se encuentra en el directorio src/internet/modelo y
consta de 2 archivos cola-codel.h y codel-cola.cc definiendo una clase CoDelQueue y una
clase auxiliar CoDelTimestampTag. El código fue portado a ns-3 de Andrew McGregor basado en
Código del kernel de Linux implementado por Dave Täht y Eric Dumazet.

· clase CoDelQueue: Esta clase implementa el algoritmo CoDel principal:

· CoDelQueue::DoEnqueue (): Esta rutina etiqueta un paquete con la hora actual antes
empujándolo a la cola. La etiqueta de marca de tiempo es utilizada por CoDelQueue::DoDequeue() a
calcular el tiempo de permanencia del paquete. Si la cola está llena a la llegada del paquete, esto
la rutina eliminará el paquete y registrará el número de caídas debido al desbordamiento de la cola,
que se almacena en m_dropOverLimit.

· CoDelQueue::DeberíaDrop (): Esta rutina es CoDelQueue::DoDequeue()la rutina del ayudante
eso determina si un paquete debe descartarse o no en función de su tiempo de permanencia.
Si el tiempo de permanencia supera m_objetivo y permanece encima continuamente durante al menos
intervalo_m, vuelve la rutina su verdadero indicando que está bien descartar el paquete.
De lo contrario, vuelve false.

· CoDelQueue::DoDequeue (): Esta rutina realiza la caída real del paquete en función de
CoDelQueue::DeberíaDrop ()El valor de retorno de y programa la próxima caída.

· clase CoDelTimestampTag: esta clase implementa el etiquetado de marca de tiempo para un paquete. Esta
La etiqueta se utiliza para calcular el tiempo de permanencia del paquete (la diferencia entre el tiempo que
el paquete se elimina de la cola y el tiempo en que se inserta en la cola).

Hay 2 sucursales para CoDelQueue::DoDequeue ():

1. Si la cola se encuentra actualmente en el estado de abandono, lo que significa que el tiempo de permanencia ha
permaneció por encima m_objetivo Por más de intervalo_m, la rutina determina si está bien
deja el estado de caída o es hora de la próxima caída. Cuándo CoDelQueue::DeberíaDrop ()
devoluciones false, la cola puede salir del estado de eliminación (establecer m_droping a false).
De lo contrario, la cola descarta paquetes continuamente y actualiza la hora para el próximo lanzamiento.
(m_dropSiguiente) hasta que se cumpla una de las siguientes condiciones:

1. La cola está vacía, por lo que la cola deja el estado de eliminación y sale
CoDelQueue::DeberíaDrop () rutina;

2. CoDelQueue::DeberíaDrop () devoluciones false (lo que significa que el tiempo de permanencia va por debajo
m_objetivo) en el que la cola abandona el estado de eliminación;

3. Todavía no es hora de la próxima gota (m_dropSiguiente es menor que la hora actual) al
el cual la cola espera a que el siguiente paquete salga de la cola para verificar la condición nuevamente.

2. Si la cola no está en el estado de eliminación, la rutina entra en el estado de eliminación y
soltar el primer paquete si CoDelQueue::DeberíaDrop () devoluciones su verdadero (que significa la estancia
el tiempo ha pasado por encima m_objetivo por al menos intervalo_m por primera vez o se ha ido
arriba de nuevo después de que la cola abandone el estado de eliminación).

Referencias
[Nic12]

K. Nichols y V. Jacobson, Controlling Queue Delay, ACM Queue, vol. 10 No. 5, mayo de 2012.
Disponible en línea en http://queue.acm.org/detail.cfm? id = 2209336.

[Nic14]

K. Nichols y V. Jacobson, Internet-Draft: Controlled Delay Active Queue Management,
Marzo de 2014. Disponible en línea en
http://tools.ietf.org/html/draft-nichols-tsvwg-codel-02.

[Buf14]
Bufferbloat.net. Disponible en línea en http://www.bufferbloat.net/.

Atributos
Los atributos clave que contiene la clase CoDelQueue incluyen los siguientes:

· Modo: Modo de funcionamiento CoDel (BYTES, PACKETS o ILEGAL). El modo predeterminado es BYTES.

· Paquetes máximos: El número máximo de paquetes que puede contener la cola. El valor predeterminado es
DEFAULT_CODEL_LIMIT, que son 1000 paquetes.

· MáximoBytes: El número máximo de bytes que puede contener la cola. El valor predeterminado es 1500 *
DEFAULT_CODEL_LIMIT, que es 1500 * 1000 bytes.

· MinBytes: El parámetro minbytes del algoritmo CoDel. El valor predeterminado es 1500 bytes.

· Intervalo: La ventana deslizante mínima. El valor predeterminado es 100ms.

· Target: El retraso de la cola de destino del algoritmo CoDel. El valor predeterminado es 5ms.

Ejemplos
El primer ejemplo es codel-vs-droptail-basic-test.cc localizado en src/internet/ejemplos. Para
ejecute el archivo (la primera invocación a continuación muestra las opciones de línea de comandos disponibles):

$ ./waf --ejecutar "codel-vs-droptail-basic-test --PrintHelp"
$ ./waf --ejecutar "codel-vs-droptail-basic-test --queueType=CoDel --pcapFileName=codel.pcap --cwndTrFileName=cwndCodel.tr"

El resultado esperado de los comandos anteriores son dos archivos: codel.pcap archivo y
cwndCoDel.tr (seguimiento ASCII) El archivo .pcap se puede analizar usando wireshark o
seguimiento de tcp:

$ tcptrace -l -r -n -W codel.pcap

El segundo ejemplo es codel-vs-droptail-asimétrico.cc localizado en src/internet/ejemplos.
Este ejemplo pretende modelar un escenario típico de implementación de módem por cable. para ejecutar el
archivo:

$ ./waf --ejecutar "codel-vs-droptail-asimétrico --PrintHelp"
$ ./waf --ejecutar codel-vs-droptail-asimétrico

El resultado esperado de los comandos anteriores son seis archivos pcap:

· codel-vs-droptail-asimétrico-CoDel-server-lan.pcap

· codel-vs-droptail-asimétrico-CoDel-router-wan.pcap

· codel-vs-droptail-asimétrico-CoDel-router-lan.pcap

· codel-vs-droptail-asimétrico-CoDel-cmts-wan.pcap

· codel-vs-droptail-asimétrico-CoDel-cmts-lan.pcap

· codel-vs-droptail-asimétrico-CoDel-host-lan.pcap

Un archivo de atributos:

· codel-vs-droptail-asimétrico-CoDel.attr

Cinco archivos de rastreo ASCII:

· codel-vs-droptail-asimétrico-CoDel-drop.tr

· codel-vs-droptail-asimétrico-CoDel-drop-state.tr

· codel-vs-droptail-asimétrico-CoDel-sojourn.tr

· codel-vs-droptail-asimétrico-CoDel-length.tr

· codel-vs-droptail-asimétrico-CoDel-cwnd.tr

Validación
El modelo CoDel se prueba usando CoDelQueueTestSuite clase definida en
src/internet/test/code-queue-prueba-suite.cc. La suite incluye 5 casos de prueba:

· Prueba 1: La primera prueba verifica el enqueue/dequeue sin caídas y se asegura de que
Los atributos de CoDel se pueden configurar correctamente.

· Prueba 2: La segunda prueba comprueba la puesta en cola con caídas por desbordamiento de la cola.

· Prueba 3: La tercera prueba verifica la aritmética de NewtonStep() contra el puerto explícito de Linux
implementación

· Prueba 4: La cuarta prueba verifica ControlLaw() contra el puerto explícito de Linux
implementación

· Prueba 5: La quinta prueba comprueba el enqueue/dequeue con gotas según CoDel
algoritmo

El conjunto de pruebas se puede ejecutar con los siguientes comandos:

$ ./waf configurar --enable-examples --enable-tests
$ ./waf compilación
$ ./test.py -s cola-codel

or

$ NS_LOG="CoDelQueue" ./waf --run "test-runner --suite=codel-queue"
Salto de página

BAJA TASA INALÁMBRICO PERSONAS Reservada RED (LR-WPAN)

En este capítulo se describe la implementación de modelos ns-3 para el servicio inalámbrico de baja velocidad.
red de área personal (LR-WPAN) según lo especificado por el estándar IEEE 802.15.4 (2006).

Modelo Descripción
El código fuente del módulo lr-wpan vive en el directorio src/lr-wpan.

Design
El diseño del modelo sigue de cerca el estándar desde un punto de vista arquitectónico.
[imagen] Arquitectura y alcance de los modelos lr-wpan.UNINDENT

Las áreas grises en la figura (adaptado de la Fig. 3. de IEEE Std. 802.15.4-2006) muestran el
alcance del modelo.

El Spectrum NetDevice de Nicola Baldo es la base para la implementación.

La implementación también planea tomar prestado de los modelos ns-2 desarrollados por Zheng y Lee
en el futuro.

API
Las API siguen de cerca el estándar, adaptado para convenciones de nomenclatura y modismos ns-3. los
Las API se organizan en torno al concepto de primitivas de servicio, como se muestra a continuación.
figura adaptada de la figura 14 de IEEE Std. 802.15.4-2006.
[imagen] Primitivas de servicio.UNINDENT

Las API se organizan en torno a cuatro servicios conceptuales y puntos de acceso al servicio (SAP):

· Servicio de datos MAC (MCPS)

· Servicio de gestión MAC (MLME)

· Servicio de datos PHY (PD)

· Servicio de gestión de PHY (PLME)

En general, las primitivas están estandarizadas de la siguiente manera (p. ej., Sec. 7.1.1.1.1 de IEEE
802.15.4-2006)::

MCPS-DATOS.solicitud (
ModoSrcAddr,
DstAddrModo,
DstPANID,
DstDir,
msduLongitud,
msdu,
msduhandle,
TxOpciones,
Nivel de seguridad,
modo de ID de clave,
fuente clave,
Índice de Clave
)

Esto se asigna a clases y métodos ns-3 como:

estructura McpsDataRequestParameters
{
uint8_t m_srcAddrMode;
uint8_t m_dstAddrMode;
...
};

vacío
LrWpanMac::McpsDataRequest (parámetros McpsDataRequestParameters)
{
...
}

dirección MAC
El MAC actualmente implementa la variante CSMA/CA sin ranuras, sin balizamiento. Actualmente
no hay soporte para coordinadores y las API correspondientes.

El MAC implementado es similar al NullMAC de Contiki, es decir, un MAC sin funciones de suspensión.
Se supone que la radio está siempre activa (recibiendo o transmitiendo), de completamente cerrada
abajo. La recepción de tramas no se deshabilita mientras se realiza el CCA.

La principal API admitida es la API de transferencia de datos (McpsDataRequest/Indication/Confirm).
Se admite CSMA/CA según Stc 802.15.4-2006, sección 7.5.1.4. Recepción de cuadros y
se admite el rechazo de acuerdo con Std 802.15.4-2006, sección 7.5.6.2, que incluye
Agradecimientos. Solo direccionamiento corto completamente implementado. Varias fuentes de rastreo son
compatible, y las fuentes de seguimiento se pueden conectar a los sumideros.

PHY
Los componentes de la capa física consisten en un modelo Phy, un modelo de tasa de error y un modelo de pérdida.
modelo. El modelo de tasa de error actualmente modela la tasa de error para IEEE 802.15.4 2.4 GHz
canal AWGN para OQPSK; la descripción del modelo se puede encontrar en IEEE Std 802.15.4-2006,
apartado E.4.1.7. El modelo Phy se basa en SpectrumPhy y sigue las especificaciones
descrito en la sección 6 de IEEE Std 802.15.4-2006. Modela las especificaciones del servicio PHY,
Formatos PPDU, constantes PHY y atributos PIB. Actualmente solo es compatible con la transmisión.
máscara de densidad espectral de potencia especificada en 2.4 GHz según la sección 6.5.3.1. El poder del ruido
la densidad asume un ruido térmico uniformemente distribuido a través de las bandas de frecuencia. La pérdida
El modelo puede utilizar completamente todos los modelos de pérdida simples existentes (sin espectro físico). El modelo fi
utiliza el modelo de canal de espectro único existente. La capa física está modelada en paquetes.
nivel, es decir, no se realiza ninguna detección de preámbulo/SFD. La recepción de paquetes se iniciará con
el primer bit del preámbulo (que no está modelado), si la SNR es superior a -5 dB, consulte
IEEE Std 802.15.4-2006, apéndice E, Figura E.2. La recepción del paquete terminará después de
el paquete fue completamente transmitido. Otros paquetes que lleguen durante la recepción se sumarán
a la interferencia/ruido.

Actualmente, la sensibilidad del receptor está configurada en un valor fijo de -106.58 dBm. Esta
corresponde a una tasa de error de paquete del 1% para paquetes de referencia de 20 bytes para esta señal
potencia, según IEEE Std 802.15.4-2006, sección 6.1.7. En el futuro proporcionaremos
soporte para cambiar la sensibilidad a diferentes valores.
[imagen] Tasa de errores de paquetes frente a la potencia de la señal.UNINDENT

dispositivo de red
Aunque se espera que otros perfiles tecnológicos (como 6LoWPAN y ZigBee)
escriben sus propias clases de NetDevice, se proporciona un LrWpanNetDevice básico, que encapsula
las operaciones comunes de crear un dispositivo LrWpan genérico y unir cosas.

<b></b><b></b> y Limitaciones
Las versiones futuras de este documento contendrán un formulario PICS similar al Apéndice D de
IEEE 802.15.4-2006. El énfasis actual está en el modo no ranurado de operación 802.15.4
para usar en Zigbee, y el alcance se limita a habilitar un solo modo (CSMA/CA) con
capacidades de transferencia de datos. Aún no se admite la asociación con coordinadores panistas, ni
el uso de direccionamiento extendido. La interferencia se modela como AWGN, pero actualmente no lo es.
Probado a fondo.

La cola de NetDevice Tx no está limitada, es decir, los paquetes nunca se descartan debido a la cola.
volviéndose lleno. Es posible que se eliminen debido a reintentos de transmisión excesivos o acceso al canal
fracaso.

Referencias
· Especificaciones de control de acceso al medio inalámbrico (MAC) y capa física (PHY) para
Redes de área personal inalámbricas de baja velocidad (WPAN), IEEE Computer Society, IEEE Std
802.15.4-2006, 8 de septiembre de 2006.

·

J. Zheng y Myung J. Lee, "Un estudio de rendimiento integral de IEEE 802.15.4", Sensor
Operaciones de red, IEEE Press, Wiley Interscience, Capítulo 4, págs. 218-237, 2006.

Uso
Habilitación lr-wpan
Agregar lr-wpan a la lista de módulos construidos con ns-3.

Ayudante
El ayudante sigue el patrón de otros ayudantes de dispositivos. En particular, el rastreo (ascii y
pcap) se habilita de manera similar, y se realiza la habilitación de todos los componentes de registro lr-wpan
similar. El uso del ayudante se ejemplifica en ejemplos/lr-wpan-data.cc. para ascii
seguimiento, los seguimientos de transmisión y recepción están enganchados en la capa Mac.

El modelo de pérdida de propagación predeterminado agregado al canal, cuando se usa este ayudante, es el
LogDistancePropagationLossModel con parámetros predeterminados.

Ejemplos
Se han escrito los siguientes ejemplos, que se pueden encontrar en src/lr-wpan/ejemplos/:

· lr-wpan-data.cc: Un ejemplo simple que muestra la transferencia de datos de extremo a extremo.

· lr-wpan-error-distancia-plot.cc: Un ejemplo para trazar variaciones del éxito del paquete
relación en función de la distancia.

· lr-wpan-error-model-plot.cc: Un ejemplo para probar el phy.

· lr-wpan-paquete-print.cc: Un ejemplo para imprimir los campos del encabezado MAC.

· lr-wpan-phy-test.cc: Un ejemplo para probar el phy.

En particular, el módulo permite un escenario de transferencia de datos de extremo a extremo muy simplificado,
implementado en lr-wpan-data.cc. La figura muestra una secuencia de eventos que se activan
cuando el MAC recibe un DataRequest de la capa superior. Invoca un Canal Claro
Evaluación (CCA) del PHY y, si tiene éxito, envía el marco al PHY donde
se transmite por el canal y da como resultado una indicación de datos en el nodo par.
[imagen] Ejemplo de datos para transferencia de datos LR-WPAN simple de extremo a extremo.UNINDENT

El ejemplo lr-wpan-error-distancia-plot.cc traza la tasa de éxito de paquetes (PSR) como un
función de la distancia, utilizando el modelo de pérdida de propagación LogDistance predeterminado y el
Modelo de error 802.15.4. El canal (predeterminado 11), el tamaño del paquete (predeterminado 20 bytes) y
La potencia de transmisión (0 dBm por defecto) se puede variar mediante argumentos de la línea de comandos. El programa
genera un archivo llamado 802.15.4-psr-distancia.plt. Cargar este archivo en gnuplot produce un
presentar 802.15.4-psr-distancia.eps, que se puede convertir a pdf u otros formatos. los
la salida predeterminada se muestra a continuación.
[imagen] Salida por defecto del programa lr-wpan-error-distancia-plot.cc.SIN SANGRÍA

Examenes
Se han escrito las siguientes pruebas, que se pueden encontrar en src/lr-wpan/pruebas/:

· lr-wpan-ack-test.cc: Verifique que los acuses de recibo se estén utilizando y emitiendo en el
orden correcto.

· lr-wpan-colisión-test.cc: Prueba la correcta recepción de paquetes con interferencia y
colisiones.

· lr-wpan-error-modelo-test.cc: Comprobar que el modelo de error da valores predecibles.

· lr-wpan-paquete-prueba.cc: Probar las clases de encabezado/remolque MAC 802.15.4

· lr-wpan-pd-plme-sap-test.cc: Pruebe PLME y PD SAP según IEEE 802.15.4

· lr-wpan-espectro-valor-ayudante-prueba.cc: Pruebe que la conversión entre potencia
(expresado como una cantidad escalar) y la potencia espectral, y viceversa, cae dentro de un 25%
tolerancia en toda la gama de posibles canales y potencias de entrada.

Validación
El modelo no ha sido validado contra hardware real. El modelo de error ha sido
validado contra los datos en IEEE Std 802.15.4-2006, sección E.4.1.7 (Figura E.2). los
El comportamiento de MAC (retroceso de CSMA) ha sido validado a mano contra el comportamiento esperado. los
la siguiente gráfica es un ejemplo de la validación del modelo de error y se puede reproducir ejecutando
lr-wpan-error-model-plot.cc:
[imagen] Salida por defecto del programa lr-wpan-error-model-plot.cc.SIN SANGRÍA

LTE MÓDULO

Design Documentación
Descripción General
En la figura se muestra una descripción general del modelo de simulación LTE-EPC. Descripción General of los
LTE-EPC simulación modelo. Hay dos componentes principales:

· el Modelo LTE. Este modelo incluye la pila de protocolo de radio LTE (RRC, PDCP, RLC, MAC,
PHY). Estas entidades residen completamente dentro del UE y los nodos eNB.

· el Modelo EPC. Este modelo incluye interfaces de red central, protocolos y entidades.
Estas entidades y protocolos residen dentro de los nodos SGW, PGW y MME, y parcialmente
dentro de los nodos eNB.
[imagen] Resumen del modelo de simulación LTE-EPC.UNINDENT

Design Criterios
LTE Modelo
El modelo LTE ha sido diseñado para apoyar la evaluación de los siguientes aspectos de LTE
sistemas:

· Gestión de Recursos Radiofónicos

· Programación de paquetes consciente de QoS

· Coordinación de interferencia intercelular

· Acceso al Espectro Dinámico

Para modelar sistemas LTE a un nivel de detalle que sea suficiente para permitir una correcta
evaluación de los aspectos antes mencionados, se han establecido los siguientes requisitos
considerado:

1. A nivel de radio, la granularidad del modelo debe ser al menos la del
Bloque de recursos (RB). De hecho, esta es la unidad fundamental que se utiliza para los recursos.
asignación. Sin este nivel mínimo de granularidad, no es posible modelar
Programación de paquetes precisa e interferencia entre celdas. La razón es que, desde
la programación de paquetes se realiza por RB, un eNB puede transmitir solo en un subconjunto
de todos los RB disponibles, por lo que interfiere con otros eNB solo en aquellos RB donde
está transmitiendo. Nótese que este requisito descarta la adopción de un sistema
enfoque de simulación de nivel, que evalúa la asignación de recursos sólo en el
granularidad del establecimiento de llamada/portador.

2. El simulador debe escalar hasta decenas de eNB y cientos de equipos de usuario (UE).
Esto descarta el uso de un simulador de nivel de enlace, es decir, un simulador cuya radio
La interfaz se modela con una granularidad hasta el nivel del símbolo. Esto es porque a
tener un modelo de nivel de símbolo es necesario implementar toda la señal de la capa PHY
procesamiento, cuya enorme complejidad computacional limita severamente la simulación. De hecho,
Los simuladores de nivel de enlace normalmente se limitan a un solo eNB y uno o unos pocos UE.

3. Debe ser posible dentro de la simulación configurar diferentes celdas para que
utilizan diferentes frecuencias portadoras y anchos de banda del sistema. El ancho de banda utilizado por
se debe permitir que diferentes celdas se superpongan, para admitir espectro dinámico
soluciones de licencia como las descritas en [Ofcom2600MHz] y [RealWireless].
El cálculo de la interferencia debe manejar adecuadamente este caso.

4. Ser más representativo del estándar LTE, así como estar lo más cerca posible
a las implementaciones del mundo real, el simulador debe ser compatible con la API del programador de MAC
publicado por el FemtoForum [FFAPI]. Se espera que esta interfaz sea utilizada por
fabricantes de femtoceldas para la implementación de programación y recursos de radio
Algoritmos de gestión (RRM). Al introducir soporte para esta interfaz en el
simulador, hacemos posible que los proveedores y operadores de equipos LTE prueben en un
entorno simulado exactamente los mismos algoritmos que se implementarían en un entorno real
.

5. El modelo de simulación LTE debe contener su propia implementación de la API definida en
[FFAPI]. Ni la compatibilidad binaria ni de la estructura de datos con las específicas del proveedor.
se esperan implementaciones de la misma interfaz; por lo tanto, una capa de compatibilidad
debe interponerse cada vez que se vaya a utilizar un programador MAC específico del proveedor con el
simulador. Este requisito es necesario para permitir que el simulador sea independiente
de implementaciones específicas del proveedor de esta especificación de interfaz. Notamos eso
[FFAPI] es solo una especificación lógica, y su implementación (p. ej., traducción
a algún lenguaje de programación específico) se deja a los proveedores.

6. El modelo se utilizará para simular la transmisión de paquetes IP por la parte superior
capas. Al respecto, se considerará que en LTE la Programación y
La gestión de recursos de radio no funciona con paquetes IP directamente, sino con RLC
PDUs, que se obtienen por segmentación y concatenación de paquetes IP realizada por el
entidades RLC. Por lo tanto, estas funcionalidades de la capa RLC deben modelarse
con precisión.

EPC Modelo
El objetivo principal del modelo EPC es proporcionar medios para la simulación de extremo a extremo
Conectividad IP sobre el modelo LTE. Para ello, apoya la interconexión de
múltiples UE a Internet, a través de una red de acceso de radio de múltiples eNB conectados a un
único nodo SGW/PGW, como se muestra en la Figura Descripción General of los LTE-EPC simulación modelo.

Se han realizado las siguientes elecciones de diseño para el modelo EPC:

1. El único tipo de red de paquetes de datos (PDN) admitido es IPv4.

2. Las entidades funcionales SGW y PGW se implementan dentro de un solo nodo, que es
por lo tanto, se denomina nodo SGW/PGW.

3. Los escenarios con movilidad inter-SGW no son de interés. Por lo tanto, un solo SGW/PGW
el nodo estará presente en todos los escenarios de simulación

4. Un requisito para el modelo EPC es que se pueda utilizar para simular el extremo a extremo
rendimiento de aplicaciones realistas. Por lo tanto, debería ser posible utilizarlo con el
EPC modela cualquier aplicación ns-3 normal que funcione sobre TCP o UDP.

5. Otro requisito es la posibilidad de simular topologías de red con el
presencia de múltiples eNB, algunos de los cuales pueden estar equipados con un backhaul
conexión con capacidades limitadas. Para simular tales escenarios, el usuario
Se deben modelar los protocolos de plano de datos que se utilizan entre los eNB y el SGW/PGW.
con precisión.

6. Debería ser posible que un solo UE use diferentes aplicaciones con diferentes
Perfiles de QoS. Por lo tanto, se deben admitir múltiples portadores de EPS para cada UE. Esta
incluye la clasificación necesaria del tráfico TCP/UDP sobre IP realizada en el UE en
el enlace ascendente y en el PGW en el enlace descendente.

7. El modelo EPC se centra principalmente en el plano de datos EPC. El modelado preciso de
el plano de control EPC no es, por el momento, un requisito; por lo tanto, la
Las interacciones necesarias del plano de control se pueden modelar de manera simplificada mediante
aprovechando la interacción directa entre los diferentes objetos de simulación a través de la
objetos auxiliares proporcionados.

8. El modelo EPC se centra en las simulaciones de usuarios activos en modo conectado a ECM.
Por lo tanto, toda la funcionalidad que solo es relevante para el modo inactivo de ECM (en particular,
actualización del área de seguimiento y paginación) no se modelan en absoluto.

9. El modelo debe permitir la posibilidad de realizar un traspaso basado en X2 entre dos
eNB.

Arquitectura
LTE Modelo
UE
La arquitectura del modelo de pila de protocolos de radio LTE del UE se representa en el
cifras LTE radio protocolo montón para los UE on los datos avión y LTE radio
protocolo montón para los UE on los control avión que destacan respectivamente
el plano de datos y el plano de control.
[imagen] Arquitectura de pila de protocolo de radio LTE para el UE en el plano de datos.UNINDENT
[imagen] Arquitectura de pila de protocolo de radio LTE para el UE en el plano de control.UNINDENT

La arquitectura del modelo PHY/canal del UE se representa en la figura PHY y
canal modelo para los UE.
[imagen] PHY y arquitectura del modelo de canal para la UE.UNINDENT

eNB
La arquitectura del modelo de pila de protocolo de radio LTE del eNB se representa en el
cifras LTE radio protocolo montón para los eNB on los datos avión y LTE radio
protocolo montón para los eNB on los control avión que destacan respectivamente
el plano de datos y el plano de control.
[imagen] Arquitectura de pila de protocolo de radio LTE para el eNB en el plano de datos.UNINDENT
[imagen] Arquitectura de pila de protocolo de radio LTE para el eNB en el plano de control.UNINDENT

La arquitectura del modelo PHY/canal del eNB se representa en la figura PHY y
canal modelo para los eNB.
[imagen] PHY y arquitectura de modelo de canal para eNB.UNINDENT

EPC Modelo
EPC datos avión
En figura LTE-EPC datos avión protocolo montón, representamos los datos LTE-EPC de extremo a extremo
pila de protocolos de plano tal como se modela en el simulador. De la figura, es evidente
que la mayor simplificación introducida en el modelo del plano de datos es la inclusión del
Funcionalidad SGW y PGW dentro de un solo nodo SGW/PGW, lo que elimina la necesidad del S5
o interfaces S8 especificadas por 3GPP. Por otro lado, tanto para la pila de protocolos S1-U
y la pila de protocolos de radio LTE están presentes todas las capas de protocolo especificadas por 3GPP.
[imagen] Pila de protocolo de plano de datos LTE-EPC.UNINDENT

EPC control avión
La arquitectura de la implementación del modelo del plano de control se muestra en la figura EPC
control modelo. Las interfaces de control que se modelan explícitamente son el S1-AP, el X2-AP
y las interfaces S11.

Notamos que las interfaces S1-AP y S11 están modeladas de manera simplificada, por
usando solo un par de clases de interfaz para modelar la interacción entre entidades que
residen en diferentes nodos (el eNB y el MME para la interfaz S1-AP, y el MME y
la SGW para la interfaz S11). En la práctica, esto significa que las primitivas de estos
las interfaces se asignan a una llamada de función directa entre los dos objetos. En el otro
Por otro lado, la interfaz X2-AP se modela utilizando unidades de datos de protocolo enviadas a través de un enlace X2.
(modelado como un enlace punto a punto); por esta razón, el modelo de interfaz X2-AP es más
realista.
[imagen] Modelo de control EPC.UNINDENT

Channel y Propagación
Para fines de modelado de canales, el módulo LTE utiliza el Canal de espectro interfaz proporcionada
por el módulo de espectro. En el momento de escribir este artículo, dos implementaciones de dicha interfaz
están disponibles: Canal de espectro de modelo único y multimodeloespectrocanal, y el LTE
módulo requiere el uso de la multimodeloespectrocanal para que funcione correctamente. Esta
se debe a la necesidad de admitir diferentes configuraciones de frecuencia y ancho de banda. Todos
los modelos de propagación soportados por multimodeloespectrocanal se puede utilizar dentro de la
Módulo LTE.

Use of los Edificios modelo con LTE
El modelo de propagación recomendado para ser utilizado con el módulo LTE es el proporcionado por
el módulo Buildings, que de hecho fue diseñado específicamente con LTE (aunque puede ser
utilizado con otras tecnologías inalámbricas también). Consulte la documentación del
Módulo de edificios para información genérica sobre el modelo de propagación que proporciona.

En esta sección destacaremos algunas consideraciones que se aplican específicamente cuando el
El módulo de edificios se utiliza junto con el módulo LTE.

La convención de nomenclatura utilizada en lo siguiente será:

· Equipo de usuario: UE

· Estación Base Macro: MBS

· Estación base de celda pequeña (p. ej., pico/femtocelda): SC

El módulo LTE solo considera FDD e implementa la propagación de enlace descendente y ascendente
por separado. Como consecuencia, se realizan los siguientes cálculos de pérdida de trayectoria

· MBS <-> UE (interior y exterior)

· SC (interior y exterior) <-> UE (interior y exterior)

El modelo LTE no proporciona los siguientes cálculos de pérdida de trayecto:

· UE <-> UE

· MBS <-> MBS

· MBS <-> SC

· SC <-> SC

El modelo de Edificios no conoce el tipo real del nodo; es decir, no es consciente de
si un nodo transmisor es un UE, un MBS o un SC. Más bien, al modelo Buildings solo le importa
sobre la posición del nodo: si es interior y exterior, y cuál es su eje z
respecto al nivel de la azotea. Como consecuencia, para un nodo eNB que se coloca al aire libre y
en una coordenada z por encima del nivel de la azotea, los modelos de propagación típicos de MBS serán
utilizado por el módulo Edificios. Por el contrario, para un eNB que se coloca al aire libre pero por debajo del
azotea, o interior, se utilizarán los modelos de propagación típicos de pico y femtoceldas.

Para comunicaciones que involucren al menos un nodo interior, la penetración de la pared correspondiente
las pérdidas serán calculadas por el modelo de Edificios. Esto cubre los siguientes casos de uso:

· MBS <-> UE interior

· exterior SC <-> interior UE

· interior SC <-> interior UE

· interior SC <-> exterior UE

Consulte la documentación del módulo Edificios para obtener detalles sobre los modelos reales.
utilizado en cada caso.

Desvanecimiento Modelo
El módulo LTE incluye un modelo de desvanecimiento basado en trazas derivado del desarrollado durante
el GSoC 2010 [Piro2011]. La característica principal de este modelo es el hecho de que el
la evaluación del desvanecimiento durante el tiempo de ejecución de la simulación se basa en las trazas calculadas. Esto es
hecho para limitar la complejidad computacional del simulador. Por otro lado, necesita
enormes estructuras para almacenar las huellas; por lo tanto, un equilibrio entre el número de
Se deben encontrar los posibles parámetros y la ocupación de la memoria. Los más importantes son:

· velocidad de usuarios: velocidad relativa entre usuarios (afecta a la frecuencia Doppler, que en
los giros afectan la propiedad de variación de tiempo del desvanecimiento)

· número de tomas (y potencia relativa): número de caminos múltiples considerados, que
afecta la propiedad de frecuencia del desvanecimiento.

· granularidad temporal de la traza: tiempo de muestreo de la traza.

· granularidad de frecuencia de la traza: número de valores en frecuencia a evaluar.

· longitud de la traza: idealmente grande como el tiempo de simulación, podría reducirse mediante ventanas
mecanismo.

· número de usuarios: número de trazas independientes a utilizar (idealmente una traza por
usuario).

Con respecto al modelo matemático de propagación del canal, sugerimos el proporcionado por
los rayleigh-chan función de Matlab, ya que proporciona un canal bien aceptado
modelización tanto en el dominio del tiempo como en el de la frecuencia. Para más información, el lector está
referido a [mathworks].

El simulador proporciona un script matlab.
(src/lte/model/fading-traces/fading-trace-generator.m) para generar trazas basadas en la
formato utilizado por el simulador. En detalle, el objeto de canal creado con el rayleighchan
La función se utiliza para filtrar una señal de impulso en tiempo discreto con el fin de obtener la
respuesta de impulso del canal. El filtrado se repite para diferentes TTI, dando así
subsiguientes respuestas de canal correlacionadas con el tiempo (una por TTI). La respuesta del canal es entonces
procesado con el pwelch función para obtener sus valores de densidad espectral de potencia, que
luego se guardan en un archivo con el formato adecuado compatible con el modelo del simulador.

Dado que el número de variables es bastante alto, genere trazas considerando todas ellas
podría producir una gran cantidad de huellas de gran tamaño. Al respecto, consideramos la
siguientes supuestos de los parámetros basados ​​en las condiciones de propagación de desvanecimiento 3GPP
(ver Anexo B.2 de [TS36104]):

· la velocidad de los usuarios: por lo general, solo se consideran unos pocos valores discretos, es decir:

· 0 y 3 kmph para escenarios peatonales

· 30 y 60 kmph para escenarios vehiculares

· 0, 3, 30 y 60 para escenarios urbanos

· derivaciones de canal: normalmente solo se considera un número limitado de conjuntos de derivaciones de canal,
por ejemplo, se mencionan tres modelos en el Anexo B.2 de [TS36104].

· granularidad de tiempo: necesitamos un valor de desvanecimiento por TTI, es decir, cada 1 ms (ya que este es el
granularidad en el tiempo del modelo ns-3 LTE PHY).

· granularidad de frecuencia: necesitamos un valor de desvanecimiento por RB (que es la frecuencia
granularidad del modelo de espectro utilizado por el modelo ns-3 LTE).

· longitud de la traza: el simulador incluye el mecanismo de ventana implementado
durante el GSoC 2011, que consiste en coger una ventana de la traza cada ventana
longitud de forma aleatoria.

· proceso de desvanecimiento por usuario: los usuarios comparten el mismo rastro de desvanecimiento, pero para cada usuario un
Se selecciona aleatoriamente un punto de partida diferente en la traza. Esta elección se hizo para
evitar la necesidad de proporcionar un rastro de desvanecimiento por usuario.

De acuerdo con los parámetros que consideramos, la siguiente fórmula expresa en detalle la
tamaño total S_{trazas} de las huellas que se desvanecen:

donde S_{muestra} es el tamaño en bytes de la muestra (por ejemplo, 8 en caso de doble precisión,
4 en caso de precisión flotante), N_{RB} es el número de RB o conjunto de RB a considerar,
T_{trace} es la longitud total de la traza, T_{sample} es la resolución temporal de la traza
(1 ms), y N_{escenarios} es el número de escenarios de desvanecimiento que se desean (es decir,
combinaciones de diferentes conjuntos de toques de canal y valores de velocidad del usuario). Proporcionamos rastros
para 3 escenarios diferentes uno para cada configuración de tomas definida en el Anexo B.2 de
[TS36104]:

· Peatonal: con velocidad de nudos de 3 kmph.

· Vehicular: con velocidad de nudos de 60 kmph.

· Urbano: con velocidad de nudos de 3 kmph.

por lo tanto, N_{escenarios} = 3. Todas las trazas tienen T_{traza} = 10 s y RB_{NUM} = 100. Esto da como resultado
en un total de 24 MB bytes de trazas.

antenas
Estando basado en el EspectroPhy, el modelo LTE PHY admite el modelado de antena a través del ns-3
AntenaModelo clase. Por lo tanto, cualquier modelo basado en esta clase se puede asociar con cualquier eNB o
instancia de UE. Por ejemplo, el uso de la CosenoAntenaModelo asociado con un dispositivo eNB
permite modelar un sector de una macro estación base. Por defecto, el IsotrópicoAntenaModelo
se utiliza tanto para eNB como para UE.

PHY
Descripción General
El modelo de capa física proporcionado en este simulador LTE se basa en el descrito en
[Piro2011], con las siguientes modificaciones. El modelo ahora incluye la inter celda
cálculo de interferencias y la simulación de tráfico de enlace ascendente, incluidos tanto paquetes
transmisión y generación de CQI.

Subframe Estructura
La subtrama se divide en parte de control y de datos como se describe en la Figura LTE subestructura
división..
[imagen] División de subtrama LTE..UNINDENT

Considerando la granularidad del simulador basado en RB, el control y la referencia
la señalización debe modelarse teniendo en cuenta esta restricción. De acuerdo con la
estándar [TS36211], el marco de control de enlace descendente comienza al comienzo de cada subtrama
y dura hasta tres símbolos en todo el ancho de banda del sistema, donde el real
la duración es proporcionada por el canal indicador de formato de control físico (PCFICH). los
la información sobre la asignación se mapea en el recurso restante hasta el
duración definida por el PCFICH, en el llamado Canal de Control de Enlace Descendente Físico
(PDCCH). Un PDCCH transporta un solo mensaje llamado Información de control de enlace descendente (DCI)
provenientes de la capa MAC, donde el programador indica la asignación de recursos para un
usuario específico. El PCFICH y el PDCCH se modelan con la transmisión del control
fotograma de una duración fija de 3/14 de milisegundos que se extiende en el conjunto disponible
ancho de banda, ya que el programador no estima el tamaño de la región de control. Esta
implica que un solo bloque de transmisión modela todo el marco de control con un
potencia (es decir, la utilizada para el PDSCH) en todos los RB disponibles. De acuerdo a esto
característica, esta transmisión representa también un valioso apoyo para la señal de referencia
(RS). Esto permite tener en cada TTI una evaluación del escenario de interferencia ya que
todos los eNB están transmitiendo (simultáneamente) el marco de control sobre el respectivo
anchos de banda disponibles. Notamos que, el modelo no incluye el refuerzo de potencia ya que
no refleja ninguna mejora en el modelo implementado de estimación de canales.

La señal de referencia de sondeo (SRS) se modela de manera similar al marco de control de enlace descendente.
El SRS se coloca periódicamente en el último símbolo del bastidor auxiliar en todo el sistema
banda ancha. El módulo RRC ya incluye un algoritmo para asignar dinámicamente el
periodicidad en función del número real de UE adjuntos a un eNB según el
Procedimiento específico de UE (consulte la Sección 8.2 de [TS36213]).

dirección MAC a Channel retrasar
Para modelar la latencia de implementaciones MAC y PHY reales, el modelo PHY simula un
Demora de MAC a canal en múltiplos de TTI (1 ms). La transmisión de datos y control
los paquetes se retrasan por esta cantidad.

CQI dejan comentarios,
La generación de retroalimentación CQI se realiza de acuerdo a lo especificado en [FFAPI]. En
En detalle, consideramos la generación de CQI de banda ancha periódica (es decir, un valor único de
estado del canal que se considera representativo de todos los RB en uso) y CQI en banda (es decir, un
conjunto de valores que representan el estado del canal para cada RB).

El índice CQI a informar se obtiene obteniendo primero una medición SINR y luego
pasando esta medida SINR a la Modulación Adaptativa y Codificación que la asignará a la
índice CQI.

En el enlace descendente, el SINR utilizado para generar retroalimentación CQI se puede calcular en dos diferentes
formas:

1. Ctrl método: SINR se calcula combinando la potencia de la señal de la referencia
(que en la simulación es equivalente al PDCCH) y la interferencia
energía del PDCCH. Este enfoque da como resultado considerar cualquier eNB vecino como un
fuente de interferencia, independientemente de si este eNB está realizando realmente algún PDSCH
transmisión, e independientemente de la potencia y los RB utilizados para la eventual interferencia
transmisiones PDSCH.

2. Mixto método: SINR se calcula combinando la potencia de la señal de la referencia
(que en la simulación es equivalente al PDCCH) y la interferencia
energía del PDSCH. Este enfoque da como resultado que se consideren interferentes sólo aquellos
eNB vecinos que están transmitiendo activamente datos en el PDSCH, y permite
generar CQI dentro de la banda que representan diferentes cantidades de interferencia en diferentes
RBs de acuerdo con el nivel de interferencia real. En el caso de que no haya PDSCH
la transmisión es realizada por cualquier eNB, este método considera que la interferencia es
cero, es decir, la SINR se calculará únicamente como la relación entre la señal y el ruido.

Para cambiar entre estos dos enfoques de generación de CQI, LteHelper::UsePdschForCqiGeneration
debe configurarse: falso para el primer enfoque y verdadero para el segundo enfoque (verdadero es
valor por defecto):

Config::SetDefault ("ns3::LteHelper::UsePdschForCqiGeneration", BooleanValue (verdadero));

En el enlace ascendente, se implementan dos tipos de CQI:

· Basado en SRS, enviado periódicamente por los UEs.

· Basado en PUSCH, calculado a partir de los datos reales transmitidos.

La interfaz del planificador incluye un sistema de atributos llamado UlCqiFiltro para la gestión de la
filtrado de los CQIs según su naturaleza, en detalle:

· SRS_UL_CQI para almacenar solo CQI basados ​​en SRS.

· PUSCH_UL_CQI para almacenar solo CQI basados ​​en PUSCH.

· ALL_UL_CQI para almacenar todos los CQI recibidos.

Hay que señalar que, la FfMacProgramador proporciona solo la interfaz y es cuestión
de la implementación real del programador para incluir el código para administrar estos atributos
(Consulte la sección relacionada con el programador para obtener más información sobre este asunto).

Interferencia Modelo
El modelo PHY se basa en los conocidos modelos de interferencia gaussiana, según los cuales
las potencias de las señales de interferencia (en unidades lineales) se suman para determinar
la potencia de interferencia total.

El diagrama de secuencia de la figura Secuencia diagrama of los PHY interferencia cálculo
procedimientos muestra cómo se procesan las señales de interferencia para calcular la SINR y cómo la SINR
luego se usa para la generación de retroalimentación de CQI.
[imagen] Diagrama de secuencia del procedimiento de cálculo de interferencia PHY.UNINDENT

LTE Spectrum Modelo
El uso del espectro de radio por eNB y UE en LTE se describe en [TS36101]. En el
simulador, el uso del espectro de radio se modela de la siguiente manera. Deje que f_c denote el LTE Absoluto
Número de canal de radiofrecuencia, que identifica la frecuencia portadora en 100 kHz
trama; además, sea B la configuración del ancho de banda de transmisión en número de
Bloques de recursos. Para cada par (f_c,B) usado en la simulación definimos un correspondiente
SpectrumModel utilizando la funcionalidad proporcionada por sec-spectrum-module. modelo usando
el marco Spectrum descrito en [Baldo2009]. f_c y B se pueden configurar para cada
eNB instanciado en la simulación; por lo tanto, cada eNB puede usar un modelo de espectro diferente.
Cada UE utilizará automáticamente el modelo de espectro del eNB al que está conectado. Utilizando el
MultiModelSpectrumChannel descrito en [Baldo2009], la interferencia entre eNBs que utilizan
diferentes modelos de espectro se tiene en cuenta adecuadamente. Esto permite simular dinámicas
políticas de acceso al espectro, como por ejemplo las políticas de licencias de espectro que son
discutido en [Ofcom2600MHz].

Data PHY Error Modelo
El simulador incluye un modelo de error del plano de datos (es decir, PDSCH y PUSCH) según
a las técnicas estándar de mapeo de enlace a sistema (LSM). La elección está alineada con la
Metodología estándar de simulación de sistemas de tecnología de transmisión de radio OFDMA. Gracias a
LSM somos capaces de mantener un buen nivel de precisión y al mismo tiempo limitar el
aumento de la complejidad computacional. Se basa en el mapeo de una sola capa de enlace.
rendimiento obtenido mediante simuladores de nivel de enlace a sistema (en nuestro caso red)
simuladores En particular, se utiliza el simulador de capa link para generar el rendimiento.
de un solo enlace desde una perspectiva de capa PHY, generalmente en términos de tasa de error de bloque de código
(BLER), bajo condiciones estáticas específicas. LSM permite el uso de estos parámetros en más
escenarios complejos, propios de los simuladores de sistemas/redes, donde tenemos más enlaces,
interferencia y fenómenos de propagación de canales "coloreados" (p. ej., frecuencia selectiva
desvanecimiento).

Para ello se ha utilizado el Simulador de LTE de Viena [ViennaLteSim] por lo que respecta a la
extracción del rendimiento de la capa de enlace y la SINR efectiva basada en información mutua
(MIESM) como función de mapeo LSM utilizando parte del trabajo publicado recientemente por Signet
Grupo de la Universidad de Padua [PaduaPEM].

MIESMO
El método LSM específico adoptado es el que se basa en el uso de una información mutua
métrica, comúnmente conocida como la información mutua por bit codificado (MIB o MMIB cuando
se trata de una media de múltiples MIB). Otra opción estaría representada por la
ESM exponencial (EESM); sin embargo, estudios recientes demuestran que MIESM supera a EESM en
términos de precisión [LozanoCost].
[imagen] Diagrama del procedimiento computacional del MIESM.UNINDENT

La información mutua (MI) depende del mapeo de la constelación y puede ser
calculado por bloque de transporte (TB), evaluando el MI sobre los símbolos y el
subportadora Sin embargo, esto sería demasiado complejo para un simulador de red. Por lo tanto, en nuestro
se ha considerado la implementación de una respuesta de canal plano dentro de la RB; Por lo tanto, los
El MI general de un TB se calcula promediando el MI evaluado por cada RB utilizado en el TB.
En detalle, el esquema implementado se muestra en la Figura MIESMO computational procedimientos
diagrama, donde vemos que el modelo comienza evaluando el valor de MI para cada RB,
representado en la figura por las muestras SINR. Luego se evalúa el MI equivalente por
TB base promediando los valores de MI. Finalmente, hay que dar un paso más ya que la
el simulador de nivel de enlace devuelve el rendimiento del enlace en términos de tasa de error de bloque
(BLER) en un canal de ruido guasiano blanco aditivo (AWGN), donde los bloques son el código
bloques (CB) codificados/descodificados de forma independiente por el codificador turbo. Sobre este asunto el
Se ha utilizado el esquema de segmentación 3GPP estándar para estimar el tamaño real de CB
(descrito en la sección 5.1.2 de [TS36212]). Este esquema divide el TB en N_{K_-}
bloques de tamaño K_- y N_{K+} bloques de tamaño K_+. Por lo tanto, la TB BLER general (TBLER)
puede expresarse como

donde el CBLER_i es el BLER del CB i obtenido según el simulador de nivel de enlace
Curvas CB BLER. Para la estimación del CBLER_i se ha implementado la evaluación MI
según su aproximación numérica definida en [wimaxEmd]. Además, para reducir
la complejidad del cálculo, la aproximación se ha convertido en búsqueda
mesas. En detalle, se ha utilizado el modelo acumulativo gaussiano para aproximar el AWGN
Curvas BLER con tres parámetros que proporcionan un ajuste cercano al AWGN estándar
actuaciones, en fórmula:

donde x es el MI de la TB, b_{ECR} representa el "centro de transición" y c_{ECR} es
relacionado con el "ancho de transición" de la distribución acumulativa gaussiana para cada
Tasa de código efectiva (ECR), que es la tasa de transmisión real según el canal
codificación y MCS. Para limitar la complejidad computacional del modelo consideramos
solo un subconjunto de las ECR posibles; de hecho, tendríamos potencialmente 5076 ECR posibles
(es decir, 27 MCS y 188 tamaños CB). A este respecto, limitaremos los tamaños de CB a algunos
valores representativos (es decir, 40, 140, 160, 256, 512, 1024, 2048, 4032, 6144), mientras que para
los demás se utilizará el que peor se aproxime al real (es decir, el CB más pequeño
valor de tamaño disponible respecto al real). Esta elección está alineada con la típica
rendimiento de los códigos turbo, donde el tamaño de CB no tiene un gran impacto en el BLER.
Sin embargo, se debe tener en cuenta que para tamaños de CB inferiores a 1000 bits, el efecto podría ser
relevante (es decir, hasta 2 dB); por lo tanto, adoptamos este intervalo de muestreo desequilibrado para
teniendo más precisión donde es necesario. Este comportamiento es confirmado por las cifras
presentado en la Sección Annes.

BLER curvas
En este sentido, reutilizamos parte de las curvas obtenidas dentro de [PaduaPEM]. En detalle, nosotros
introdujo la dependencia del tamaño de CB a las curvas CB BLER con el apoyo de los desarrolladores
de [PaduaPEM] y del LTE Vienna Simulator. De hecho, el módulo lanzado proporciona la
calidad de funcionamiento de la capa de enlace sólo para lo que concierne a los MCS (es decir, con un ECR fijo determinado). En
detalle las nuevas curvas de tasa de error para cada uno ha sido evaluado con una campaña de simulación
con el simulador de capa de enlace para un solo enlace con ruido AWGN y para un tamaño de CB de 104,
140, 256, 512, 1024, 2048, 4032 y 6144. Estas curvas se han mapeado con Gaussian
fórmula del modelo acumulativo presentada anteriormente para obtener los correspondientes b_{ECR} y
c_{ECR} parámetros.

El rendimiento BLER de todos los MCS obtenidos con el simulador de nivel de enlace se trazan en el
siguientes figuras (líneas azules) junto con su correspondencia correspondiente a la gaussiana
distribución acumulativa (líneas discontinuas rojas).
[imagen] BLER para MCS 1, 2, 3 y 4..UNINDENT
[imagen] BLER para MCS 5, 6, 7 y 8..UNINDENT
[imagen] BLER para MCS 9, 10, 11 y 12..UNINDENT
[imagen] BLER para MCS 13, 14, 15 y 16..UNINDENT
[imagen] BLER para MCS 17, 17, 19 y 20..UNINDENT
[imagen] BLER para MCS 21, 22, 23 y 24..UNINDENT
[imagen] BLER para MCS 25, 26, 27 y 28..UNINDENT
[imagen] BLER para MCS 29..UNINDENT

Integración: of los BLER curvas in los ns-3 LTE módulo
El modelo implementado utiliza las curvas para el LSM del recientemente LTE PHY Error Model
lanzado en la comunidad ns3 por el Grupo Signet [PaduaPEM] y los nuevos generados
para diferentes tamaños de CB. los LteSpectrumPhy la clase se encarga de evaluar el TB BLER
gracias a los métodos proporcionados por el LteMiErrorModelo clase, que está a cargo de
evaluando el TB BLER según el vector de la SINR percibida por RB, el MCS y
el tamaño para modelar adecuadamente la segmentación de la TB en CBs. Para obtener
el vector de la SINR percibida dos instancias de LtePemSinrChunkProcesador (niño de
LteChunkProcesador dedicado a evaluar la SINR para obtener rendimiento de error físico)
se han conectado al enlace descendente UE y al enlace ascendente eNB LteSpectrumPhy Módulos para evaluar la
distribución del modelo de error respectivamente de PDSCH (lado UE) y ULSCH (lado eNB).

El modelo se puede deshabilitar para trabajar con un canal de cero pérdidas configurando el PemEnabled
atributo de la LteSpectrumPhy class (por defecto está activo). Esto se puede hacer de acuerdo
al procedimiento estándar del sistema de atributos ns3, es decir:

Config::SetDefault ("ns3::LteSpectrumPhy::DataErrorModelEnabled", BooleanValue (falso));

Control: Canales PHY Error Modelo
El simulador incluye el modelo de error para los canales de control de enlace descendente (PCFICH y PDCCH),
mientras que en el enlace ascendente se supone que es un canal ideal sin errores. El modelo se basa en el
El enfoque MIESM presentado anteriormente para considerar los efectos de la frecuencia selectiva
ya que la mayoría de los canales de control abarcan todo el ancho de banda disponible.

PCFICH + PDCCH Error Modelo
El modelo adoptado para la distribución de errores de estos canales se basa en una evaluación
estudio realizado en el RAN4 de 3GPP, donde diferentes proveedores investigaron la
rendimiento de demodulación del PCFICH junto con el PDCCH. Esto se debe al hecho de que
el PCFICH es el canal encargado de comunicar a los UEs la dimensión real de
el PDCCH (que abarca entre 1 y 3 símbolos); por lo tanto la correcta decodificación de
los ICD depende de la interpretación correcta de ambos. En 3GPP este problema tiene
sido evaluado para mejorar el rendimiento del borde de la celda [FujitsuWhitePaper], donde el
la interferencia entre celdas vecinas puede ser relativamente alta debido a la degradación de la señal. A
Se han notificado problemas similares en el escenario de femtoceldas y, más en general, en HetNet.
escenarios el cuello de botella se ha detectado principalmente como el canal PCFICH [Bharucha2011],
donde en caso de que se implementen muchos eNB en la misma área de servicio, este canal puede colisionar
en frecuencia, imposibilitando también la correcta detección del canal PDCCH.

En el simulador se ha estimado la SINR percibida durante la recepción según
el modelo MIESM presentado anteriormente para evaluar la distribución de errores de PCFICH y
PDCCH. En detalle, las muestras SINR de todos los RB se incluyen en la evaluación del MI
asociado al marco de control y, de acuerdo con estos valores, el SINR efectivo (eSINR)
se obtiene invirtiendo el proceso de evaluación de MI. Hay que tener en cuenta que, en caso de
Transmisión MIMO, tanto PCFICH como PDCCH utilizan siempre el modo de diversidad de transmisión como
definida por la norma. Según el eSINR percibió el error de decodificación
la probabilidad se puede estimar en función de los resultados presentados en [R4-081920]. En caso
ocurre un error, los DCI se descartan y, por lo tanto, el UE no podrá recibir el
Tbs correspondientes, resultando por tanto perdidos.

MIMO Modelo
El uso de múltiples antenas tanto en el lado del transmisor como en el del receptor, conocido como
entrada múltiple y salida múltiple (MIMO), es un problema bien estudiado en la literatura durante
los años pasados La mayor parte del trabajo se concentra en evaluar analíticamente la ganancia que el
diferentes esquemas MIMO pueden tener en términos de capacidad; sin embargo, alguien también proporciona
información de la ganancia en términos de potencia recibida [CatreuxMIMO].

De acuerdo con las consideraciones anteriores, se puede obtener un modelo más flexible considerando
la ganancia que los esquemas MIMO aportan al sistema desde un punto de vista estadístico. Como
destacado anteriormente, [CatreuxMIMO] presenta la ganancia estadística de varias soluciones MIMO
respecto al SISO en caso de no correlación entre las antenas. en la obra la
la ganancia se presenta como la función de distribución acumulada (CDF) de la SINR de salida para
lo que concierne a los esquemas SISO, MIMO-Alamouti, MIMO-MMSE, MIMO-OSIC-MMSE y MIMO-ZF.
Elaborando los resultados, la distribución SINR de salida se puede aproximar con una
log-normal con diferente media y varianza en función del esquema considerado.
Sin embargo, las varianzas no son tan diferentes y son aproximadamente iguales a la
del modo SISO ya incluido en el componente de sombreado del
EdificiosPropagaciónPérdidaModelo, en detalle:

· SISO: = 13.5 y ma = 20 [dB].

· MIMO-Alamouti: = 17.7 y ma = 11.1 [dB].

· MIMO-MMSE: = 10.7 y ma = 16.6 [dB].

· MIMO-OSIC-MMSE: = 12.6 y ma = 15.5 [dB].

· MIMO-ZF: = 10.3 y ma = 12.6 [dB].

Por lo tanto, la capa PHY implementa el modelo MIMO como la ganancia percibida por el receptor
al usar un esquema MIMO respecto al obtenido usando uno SISO. Notemos que, estos
ganancias referidas a un caso donde no hay correlación entre las antenas en MIMO
esquema; por lo tanto, no modele la degradación debido a la correlación de rutas.

UE PHY Medidas Modelo
De acuerdo con [TS36214], el UE debe informar un conjunto de mediciones de los eNB que el
dispositivo es capaz de percibir: la potencia recibida de la señal de referencia (RSRP) y la
calidad de la señal de referencia recibida (RSRQ). El primero es una medida del poder recibido de
un eNB específico, mientras que este último incluye también interferencia de canal y ruido térmico.
El UE debe informar las mediciones junto con la identidad de celda física (PCI) del
célula. Tanto las mediciones RSRP como RSRQ se realizan durante la recepción de la RS,
mientras que la PCI se obtiene con la Señal de Sincronización Primaria (PSS). Se envía el PSS
por el eNB cada 5 subtramas y en detalle en las subtramas 1 y 6. En sistemas reales, sólo
504 PCI distintos están disponibles y, por lo tanto, podría ocurrir que dos eNB cercanos utilicen el
mismo PCI; sin embargo, en el simulador modelamos PCI usando metadatos de simulación, y permitimos
hasta 65535 PCI distintos, evitando colisiones de PCI siempre que menos de 65535
Los eNB se simulan en el mismo escenario.

De acuerdo con las secciones 36133 y 9.1.4 de [TS9.1.7], la capa PHY informa de RSRP en dBm
mientras que RSRQ en dB. Los valores de RSRP y RSRQ se proporcionan a las capas superiores a través del
C-PHY SAP (mediante UeMedidasParámetros struct) cada 200 ms como se define en
[TS36331]. El filtrado de la capa 1 se realiza promediando todas las mediciones recopiladas
durante la última ranura de la ventana. La periodicidad de los informes se puede ajustar para la investigación.
fines por medio de la LteUePhy::UeMeasurementsFilterPeriod atributo.

Las fórmulas de RSRP y RSRQ se pueden simplificar considerando el supuesto de PHY
capa que el canal es plano dentro de la RB, el mejor nivel de precisión. De hecho, esto
implica que todos los RE dentro de un RB tienen la misma potencia, por lo tanto:

donde P(k,m) representa la potencia de la señal del RE m dentro del RB k, que, como se observa
antes, es constante dentro de la misma RB e igual a P(k), M es el número de RE que llevan
el RS en un RB y K es el número de RB. Cabe señalar que P(k), y en general todos
las potencias definidas en este apartado, se obtiene en el simulador a partir del PSD de la RB
(que es proporcionado por el LteInterferencePowerChunkProcesador), en detalle:

donde PSD_{RB}(k) es la densidad espectral de potencia del RB k, 180000 es el ancho de banda en Hz
de la RB y 12 es el número de RE por RB en un símbolo OFDM. De manera similar, para RSSI
have

donde S es el número de símbolos OFDM que llevan RS en un RB y R es el número de RE
llevando un RS en un símbolo OFDM (que está fijado en 2) mientras que P(k,s,r), I(k,s,r) y N(k,s,r)
representan respectivamente la potencia percibida de la celda de servicio, la potencia de interferencia y
la potencia de ruido del RE r en símbolo s. En cuanto a RSRP, las medidas dentro de un RB son
siempre iguales entre sí según el modelo PHY; por lo tanto P(k,s,r) = P(k),
I(k,s,r) = I(k) y N(k,s,r) = N(k), lo que implica que el RSSI se puede calcular como:

Teniendo en cuenta las limitaciones de la implementación de la cadena de recepción PHY, y con el fin de
mantener el nivel de complejidad computacional bajo, solo RSRP se puede obtener directamente para
todas las celdas Esto se debe al hecho de que LteSpectrumPhy está diseñado para evaluar la
interferencia solo con respecto a la señal del eNB servidor. Esto implica que el PHY
La capa está optimizada para administrar la información de señales de potencia con el eNB de servicio como un
referencia. Sin embargo, RSRP y RSRQ de la celda vecina i pueden ser extraídos por el actual
información disponible de la celda servidora j como se detalla a continuación:

donde RSRP_i es el RSRP de la celda vecina i, P_i(k) es la potencia percibida en cualquier RE
dentro del RB k, K es el número total de RB, RSSI_i es el RSSI de la celda vecina i
cuando el UE está unido a la celda j (que, al ser la suma de todas las potencias recibidas,
coincide con RSSI_j), I_j(k) es la interferencia total percibida por UE en cualquier RE de RB k
cuando se une a la celda i (obtenido por el LteInterferencePowerChunkProcesador), P_j(k) es
la potencia percibida de la celda j en cualquier RE de la RB k y N es la potencia espectral del ruido
densidad en cualquier RE. La muestra se considera válida en caso de que el RSRQ evaluado sea
por encima de la LteUePhy::RsrqUeMeasThreshold atributo.

HARQ
El esquema HARQ implementado se basa en soluciones de redundancia incremental (IR) combinadas
con múltiples procesos de parada y espera para permitir un flujo de datos continuo. En detalle, el
solución adoptada es la suave combinar camiones híbridos IR Full incrementales redundancia (también llamado
IR Tipo II), lo que implica que las retransmisiones contienen sólo información nueva respecto
a los anteriores. Se ha implementado el algoritmo de asignación de recursos del HARQ
dentro de las respectivas clases del planificador (es decir, RrFfMacProgramador y PfFfMacProgramador,
consulte sus secciones correspondientes para obtener más información), mientras que la parte de decodificación de la
HARQ ha sido implementado en el LteSpectrumPhy y LteHarqPhy clases que serán
detallada en esta sección.

De acuerdo con el estándar, las retransmisiones UL son síncronas y por lo tanto son
asignado 7 ms después de la transmisión original. En cambio, para el DL, son
asíncrono y por lo tanto se puede asignar de una manera más flexible a partir de 7 ms y
es una cuestión de la implementación específica del programador. El comportamiento de los procesos HARQ es
representado en la Figura:ref:esquema-de-procesos-fig-harq.

En la capa MAC, la entidad HARQ que reside en el planificador está a cargo de controlar
los 8 procesos HARQ para generar nuevos paquetes y gestionar las retransmisiones tanto para
el DL y el UL. El planificador recopila la retroalimentación HARQ de las capas eNB y UE PHY
(respectivamente para conexión UL y DL) mediante las primitivas API FF
SchedUlTriggerReq y SchedUlTriggerReq. De acuerdo con la retroalimentación HARQ y el RLC
estado de los búferes, el programador genera un conjunto de DCI que incluyen tanto las retransmisiones de
Los bloques HARQ recibieron transmisiones erróneas y nuevas, en general, dando prioridad a las
anterior. En este asunto, el programador debe tener en cuenta una restricción cuando
asignar el recurso para las retransmisiones HARQ, debe utilizar el mismo orden de modulación de
el primer intento de transmisión (es decir, QPSK para MCS en [0..9], 16QAM para MCS en [10..16]
y 64QAM para MCS en [17..28]). Esta restricción proviene de la especificación de la tarifa
matcher en el estándar 3GPP [TS36212], donde el algoritmo fija el orden de modulación para
generando los diferentes bloques de las versiones de redundancia.

El modelo de modelo de error PHY (es decir, el LteMiErrorModelo clase ya presentada anteriormente) tiene
se ha ampliado para considerar IR HARQ según [wimaxEmd], donde los parámetros para
el mapeo de las curvas AWGN para el mapeo MIESM en caso de retransmisiones viene dado por:

donde X es el número de bits de información original, C_i son el número de bits codificados, M_i son
las informaciones mutuas por bloque HARQ recibidas sobre el número total de q retransmisiones.
Por lo tanto, para poder devolver la probabilidad de error con el modelo de error
implementado en el simulador evalúa el R_{eff} y el MI_{I eff} y devuelve el valor
de probabilidad de error de la ECR de la misma modulación con la tasa más baja más cercana con respecto a
el R_{eff}. Para considerar el efecto de las retransmisiones HARQ, un nuevo conjunto de curvas
han sido integrados respecto al estándar utilizado para el MCS original. Las nuevas curvas
están destinados a cubrir los casos en los que se utiliza el MCS más conservador de una modulación
lo que implica la generación de R_{eff} menor respecto a la de los MCS estándar. En este
materia las curvas para 1, 2 y 3 retransmisiones han sido evaluadas para 10 y 17. Para
MCS 0 consideramos solo la primera retransmisión ya que la tasa de código producido ya es
muy conservador (es decir, 0.04) y devuelve una tasa de error lo suficientemente robusta para la recepción
(es decir, la caída del BLER se centra alrededor de -18 dB). Cabe señalar que, la
Se ha asumido que el tamaño de la transmisión del primer TB contiene todos los bits de información para
ser codificado; por lo tanto, X es igual al tamaño del primer TB enviado de un proceso HARQ. los
El modelo asume que la eventual presencia de bits de paridad en las palabras de código ya está
considerado en las curvas de nivel de enlace. Esto implica que tan pronto como el mínimo R_{eff} es
alcanzado, el modelo no incluye la ganancia debida a la transmisión de paridad adicional
Bits.
[imagen] Comportamiento de los procesos HARQ en LTE.UNINDENT

La parte de HARQ dedicada a gestionar la decodificación de los bloques HARQ ha sido
implementado en el LteHarqPhy y LteSpectrumPhy clases El primero está a cargo de
manteniendo la información HARQ para cada proceso activo. Este último interactúa con
LteMiErrorModelo clase para evaluar la corrección de los bloques recibidos e incluye
el algoritmo de mensajería a cargo de comunicarse con la entidad HARQ en el programador
el resultado de las decodificaciones. Estos mensajes están encapsulados en el
dlInfoListElement para DL y ulInfoListElemento para UL y enviado a través de la PUCCH y el
PHICH respectivamente con un modelo ideal libre de errores de acuerdo a los supuestos en sus
implementación. Un boceto de la iteración entre la pila de protocolos HARQ y LTE en
representado en la Figura:ref:arquitectura fig-harq.

Finalmente, el motor HARQ siempre está activo tanto en la capa MAC como en la PHY; sin embargo, en caso de
el planificador no es compatible con HARQ, el sistema seguirá funcionando con HARQ
funciones inhibidas (es decir, los búferes se llenan pero no se usan). Esta implementación
la característica brinda compatibilidad con versiones anteriores con programadores implementados antes de HARQ
integración.
[imagen] Interacción entre la pila de protocolos HARQ y LTE.UNINDENT

dirección MAC
Soporte Envolvente Asignación Modelo
Ahora describimos brevemente cómo se maneja la asignación de recursos en LTE, aclarando cómo es
modelado en el simulador. El planificador se encarga de generar estructuras específicas
, que son Data Control: Indicación (DCI) que luego son transmitidos por el PHY del eNB a
los UE conectados, con el fin de informarles de la asignación de recursos por subtrama
base. Al hacer esto en la dirección del enlace descendente, el programador tiene que llenar algunos
campos de la estructura DCI con toda la información, tales como: la Modulación y Codificación
Esquema (MCS) que se utilizará, el tamaño del bloque de transporte (TB) MAC y el mapa de bits de asignación
que identifica qué RBs contendrán los datos transmitidos por el eNB a cada usuario.

Para el mapeo de recursos a RB físicos, adoptamos un localizada cartografía enfoque (ver
[Sesia2009], Sección 9.2.2.1); por lo tanto, en una subtrama dada, cada RB siempre se asigna a
el mismo usuario en ambas ranuras. El mapa de bits de asignación se puede codificar en diferentes formatos; en
esta implementación, consideramos la Asignación Tipo 0 definido en [TS36213], según
a las que se agrupan las RBs en Resource Block Groups (RBG) de diferente tamaño determinado
en función de la Configuración de Ancho de Banda de Transmisión en uso.

Para ciertos valores de ancho de banda, no todos los RB son utilizables, ya que el tamaño del grupo no es un
divisor común del grupo. Este es el caso, por ejemplo, cuando el ancho de banda es igual a
25 RB, lo que da como resultado un tamaño de RBG de 2 RB y, por lo tanto, 1 RB no dará como resultado
direccionable En enlace ascendente, el formato de los DCI es diferente, ya que solo los RB adyacentes pueden
ser utilizado debido a la modulación SC-FDMA. Como consecuencia, todos los RB pueden ser asignados por
el eNB independientemente de la configuración del ancho de banda.

Adaptado De Sabor y Codificación
El simulador proporciona dos modelos de codificación y modulación adaptativa (AMC): uno basado en el
modelo GSoC [Piro2011] y uno basado en el modelo de error físico (descrito en el
apartados siguientes).

El modelo anterior es una versión modificada del modelo descrito en [Piro2011], que a su vez
está inspirado en [Seo2004]. Nuestra versión se describe a continuación. Deja que denote el
usuario genérico, y deje que mma_i sea su SINR. Obtenemos la eficiencia espectral \ta_i del usuario i
usando las siguientes ecuaciones:

Se utiliza el procedimiento descrito en [R1-081483] para obtener el esquema MCS correspondiente. los
la eficiencia espectral se cuantifica en función del indicador de calidad del canal (CQI), redondeando a
el valor más bajo, y se asigna al esquema MCS correspondiente.

Finalmente, notamos que existen algunas discrepancias entre el índice MCS en [R1-081483]
y lo indicado por la norma: [TS36213] La Tabla 7.1.7.1-1 dice que el índice MCS
va de 0 a 31, y 0 parece ser un esquema MCS válido (el tamaño de TB no es 0) pero en
[R1-081483] el primer índice MCS útil es 1. Por lo tanto, para obtener el valor previsto por el
estándar necesitamos restar 1 del índice informado en [R1-081483].

El modelo alternativo se basa en el modelo de error físico desarrollado para este simulador.
y se explica en las siguientes subsecciones. Este esquema es capaz de adaptar la selección MCS
al rendimiento real de la capa PHY según el informe CQI específico. De acuerdo a
su definición, se asigna un índice CQI cuando un solo TB PDSCH con la modulación
esquema de codificación y tasa de código correspondiente a ese índice CQI en la tabla 7.2.3-1 de [TS36213]
se puede recibir con una probabilidad de error inferior a 0.1. En el caso de CQI de banda ancha, el
El TB de referencia incluye todas las RBG disponibles para tener una referencia basada en el
todos los recursos disponibles; mientras que, para los CQI de subbanda, el TB de referencia se dimensiona como los RBG.

Transporte Bloquear modelo
El modelo de los MAC Transport Blocks (TBs) proporcionados por el simulador se simplifica con
con respecto a las especificaciones 3GPP. En particular, una clase específica del simulador
(PacketBurst) se usa para agregar MAC SDU a fin de lograr el equivalente del simulador
de un TB, sin la correspondiente complejidad de implementación. La multiplexación de
diferentes canales lógicos hacia y desde la capa RLC se realiza utilizando un paquete dedicado
etiqueta (LteRadioBearerTag), que realiza una funcionalidad que es parcialmente equivalente a
el de los encabezados MAC especificados por 3GPP.

La FemtoForo dirección MAC Scheduler Fácil de usar
Esta sección describe la versión específica de ns-3 de la interfaz del programador LTE MAC
Especificación publicada por el FemtoForum [FFAPI].

Implementamos la versión específica ns-3 de la interfaz del planificador MAC de FemtoForum [FFAPI]
como un conjunto de clases abstractas de C++; en particular, cada primitivo se traduce a un C++
método de una clase dada. El termino implementado aquí se usa con el mismo significado adoptado
en [FFAPI], y por lo tanto se refiere al proceso de traducir la interfaz lógica
especificación a un lenguaje de programación particular. Las primitivas en [FFAPI] se agrupan
en dos grupos: las primitivas CSCHED, que se ocupan de la configuración del planificador, y las
Primitivas SCHED, que se ocupan de la ejecución del programador. Además, [FFAPI]
define primitivas de dos tipos diferentes: las de tipo REQ van del MAC al
Scheduler, y los de tipo IND/CNF van desde el Scheduler al MAC. Para traducir estos
características en C++, definimos las siguientes clases abstractas que implementan Service
Puntos de Acceso (SAPs) a utilizar para emitir las primitivas:

· los FfMacSchedSapProvider la clase define todos los métodos de C++ que corresponden a SCHED
primitivas de tipo REQ;

· los FfMacSchedSapUsuario la clase define todos los métodos de C++ que corresponden a SCHED
primitivas de tipo CNF/IND;

· los FfMacCschedSapProvider clase define todos los métodos de C++ que corresponden a
primitivas CSCHED de tipo REQ;

· los FfMacCschedSapUsuario la clase define todos los métodos de C++ que corresponden a CSCHED
primitivas de tipo CNF/IND;

Hay 3 bloques involucrados en la interfaz MAC Scheduler: bloque de control, bloque de subtrama
y el bloque del Programador. Cada uno de estos bloques proporciona una parte de la interfaz MAC Scheduler.
La siguiente figura muestra la relación entre los bloques y los SAPs definidos en nuestro
implementación de la interfaz MAC Scheduler.
[imagen]

Además de los principios anteriores, se han tomado las siguientes opciones de diseño:

· La definición de las clases de interfaz MAC Scheduler sigue las convenciones de nomenclatura
del ns-3 Estilo de codificación. En particular, seguimos la convención CamelCase para el
nombres primitivos. Por ejemplo, el primitivo CSCHED_CELL_CONFIG_REQ se traduce a
CschedCellConfigReq en la categoría Industrial. ns-3 código.

· Se siguen las mismas convenciones de nomenclatura para los parámetros primitivos. como el
Los parámetros primitivos son variables miembro de clases, también tienen el prefijo
m_.

· con respecto al uso de vectores y listas en estructuras de datos, notamos que [FFAPI] es un
bastante API orientada a C. Sin embargo, consideró que C++ se usa en ns-3, y que
se desaconseja el uso de matrices C, usamos vectores STL (std :: vector) Para el
implementación de la interfaz MAC Scheduler, en lugar de usar arreglos C como
implícitamente sugerido por la forma en que [FFAPI] está escrito.

· En C++, los miembros con constructores y destructores no están permitidos en los sindicatos. Por lo tanto, todo
aquellas estructuras de datos que se dice que son los sindicatos en [FFAPI] se han definido como
estructuras en nuestro código.

La siguiente figura muestra cómo se usa la interfaz MAC Scheduler dentro del eNB.
[imagen]

El lado del usuario de CSCHED SAP y SCHED SAP se implementan dentro del eNB MAC,
es decir, en el archivo lte-enb-mac.cc. El eNB MAC se puede utilizar con diferentes planificadores
implementaciones sin modificaciones. La misma figura también muestra, a modo de ejemplo, cómo el
Se implementa el Round Robin Scheduler: para interactuar con el MAC del eNB, el Round Robin
El planificador implementa el lado del proveedor de las interfaces SCHED SAP y CSCHED SAP. A
Se puede usar un enfoque similar para implementar otros programadores también. Una descripción de cada
de las implementaciones del programador que proporcionamos como parte de nuestro módulo de simulación LTE es
dispuesto en los siguientes incisos.

Redondas petirrojo (RR) Scheduler
El programador Round Robin (RR) es probablemente el programador más simple que se encuentra en la literatura.
Funciona dividiendo los recursos disponibles entre los flujos activos, es decir, aquellos lógicos
canales que tienen una cola RLC no vacía. Si el número de RBG es mayor que el
número de flujos activos, todos los flujos se pueden asignar en la misma subtrama. De lo contrario, si
el número de flujos activos es mayor que el número de RBG, no todos los flujos pueden ser
programado en una subtrama determinada; luego, en la siguiente subtrama, la asignación comenzará desde
el último flujo que no fue asignado. Se realiza el MCS a adoptar para cada usuario.
de acuerdo con los CQI de banda ancha recibidos.

En cuanto al HARQ, RR implementa la versión no adaptativa, lo que implica que en
asignar los intentos de retransmisión RR utiliza la misma configuración de asignación del
bloque original, lo que significa mantener los mismos RBG y MCS. UE que se asignan para
Las retransmisiones HARQ no se consideran para la transmisión de nuevos datos en caso de que hayan
una oportunidad de transmisión disponible en el mismo TTI. Finalmente, HARQ se puede deshabilitar con
sistema de atributos ns3 para mantener la compatibilidad con versiones anteriores con códigos y casos de prueba antiguos,
en detalle:

Config::SetDefault ("ns3::RrFfMacScheduler::HarqEnabled", BooleanValue (falso));

El planificador implementa el filtrado de los CQI de enlace ascendente según su naturaleza con
UlCqiFiltro atribuir, en detalle:

· SRS_UL_CQI: solo los CQI basados ​​en SRS se almacenan en los atributos internos.

· PUSCH_UL_CQI: solo los CQI basados ​​en PUSCH se almacenan en los atributos internos.

· ALL_UL_CQI: todos los CQI se almacenan en el mismo atributo interno (es decir, el último CQI
recibido se almacena independientemente de su naturaleza).

Proporcional Suficientemente bueno (FP) Scheduler
El programador de Feria Proporcional (PF) [Sesia2009] funciona al programar un usuario cuando su
la calidad del canal instantáneo es alta en relación con su propia condición de canal promedio durante
hora. Sean i,j los usuarios genéricos; sea ​​t el índice de subtrama y k el recurso
índice de bloque; sea ​​M_{i,k}(t) MCS utilizable por el usuario i en el bloque de recursos k de acuerdo con lo que
reportado por el modelo AMC (ver Adaptado De Sabor y Codificación); finalmente, sea S(M, B)
el tamaño de TB en bits como se define en [TS36213] para el caso en que un número B de recurso
Se utilizan bloques. La tasa alcanzable R_{i}(k,t) en bit/s para el usuario i en el grupo de bloques de recursos
k en el subtrama t se define como

donde au es la duración del TTI. Al comienzo de cada subtrama t, cada RBG se asigna a una
determinado usuario. En detalle, el índice 144}_{k}(t) al que se asigna RBG k en el momento t es
determinado como

donde T_{j}(t) es el rendimiento pasado percibido por el usuario j. De acuerdo a
el algoritmo de programación anterior, un usuario puede asignarse a diferentes RBG, que pueden ser
ya sea adyacente o no, dependiendo de la condición actual del canal y el pasado
rendimiento de rendimiento T_{j}(t). Este último se determina al final del bastidor auxiliar t
usando el siguiente enfoque de promedio móvil exponencial:

donde lpha es la constante de tiempo (en número de subtramas) del movimiento exponencial
promedio, y 384s el rendimiento real logrado por el usuario i en la subtrama t. 360 es
medida de acuerdo con el siguiente procedimiento. Primero determinamos el MCS 840 j:

entonces determinamos el número total 936 j:

donde |

En cuanto al HARQ, PF implementa la versión no adaptativa, lo que implica que en
al asignar los intentos de retransmisión, el programador utiliza la misma asignación
configuración del bloque original, lo que significa mantener los mismos RBG y MCS. UE
que se asignan para retransmisiones HARQ no se consideran para la transmisión de nuevos
datos en caso de que tengan una oportunidad de transmisión disponible en el mismo TTI. Finalmente, HARQ
se puede deshabilitar con el sistema de atributos ns3 para mantener la compatibilidad con versiones anteriores
casos de prueba y código, en detalle:

Config::SetDefault ("ns3::PfFfMacScheduler::HarqEnabled", BooleanValue (falso));

Máxima Throughput (MT) Scheduler
El planificador de rendimiento máximo (MT) [FCapo2012] tiene como objetivo maximizar el rendimiento general
de eNB. Asigna cada RB al usuario que puede lograr la tasa máxima alcanzable en
el ITT actual. Actualmente, el programador de MT en NS-3 tiene dos versiones: dominio de frecuencia
(FDMT) y dominio del tiempo (TDMT). En FDMT, cada TTI, programador MAC asigna RBG al UE
quién tiene la tasa más alta alcanzable calculada por la subbanda CQI. En TDMT, cada TTI, MAC
el programador selecciona un UE que tiene la tasa más alta alcanzable calculada por CQI de banda ancha.
Luego, el programador MAC asigna todos los RBG a este UE en el TTI actual. el calculo de
tasa alcanzable en FDMT y TDMT es la misma que la de PF. Sean i,j genéricos
usuarios; sea ​​t el índice de subtrama yk el índice de bloque de recursos; sea ​​M_{i,k}(t)
MCS utilizable por el usuario i en el bloque de recursos k según lo informado por el modelo AMC (ver
Adaptado De Sabor y Codificación); finalmente, sea S(M, B) el tamaño de TB en bits como se define en
[TS36213] para el caso en que se utilice un número B de bloques de recursos. La tasa alcanzable
R_{i}(k,t) en bit/s para el usuario i en el bloque de recursos k en la subtrama t se define como

donde au es la duración del TTI. Al comienzo de cada subtrama t, cada RB se asigna a una
determinado usuario. En detalle, el índice 144}_{k}(t) al que se asigna RB k en el momento t es
determinado como

Cuando hay varios UE que tienen la misma tasa alcanzable, la implementación actual siempre
selecciona el primer UE creado en script. Aunque MT puede maximizar el rendimiento celular,
no puede proporcionar equidad a los UE en malas condiciones del canal.

Throughput a Normal (ATT) Scheduler
El programador de rendimiento a promedio (TTA) [FCapo2012] se puede considerar como un intermediario
entre MT y PF. La métrica utilizada en TTA se calcula de la siguiente manera:

Aquí, R_{i}(k,t) en bit/s representa la tasa alcanzable para el usuario i en el bloque de recursos k en
bastidor auxiliar t. El método de cálculo ya se muestra en MT y PF. Mientras tanto, R_{i}(t) en
bit/s representa la velocidad alcanzable para i en la subtrama t. La diferencia entre esos dos
tasas alcanzables es cómo obtener MCS. Para R_{i}(k,t), MCS se calcula mediante la subbanda CQI mientras
R_{i}(t) se calcula mediante CQI de banda ancha. El programador TTA solo se puede implementar en frecuencia
dominio (FD) porque la tasa alcanzable de RBG particular solo está relacionada con FD
Planificación.

Ciego Normal Throughput Scheduler
El programador Blind Average Throughput [FCapo2012] tiene como objetivo proporcionar el mismo rendimiento a todos
UE bajo eNB. La métrica utilizada en TTA se calcula de la siguiente manera:

donde T_{j}(t) es el rendimiento pasado percibido por el usuario j y puede ser
calculado por el mismo método en el programador de PF. En el dominio del tiempo, rendimiento medio ciego
(TD-BET), el programador selecciona el UE con la métrica de mayor prioridad y asigna todos los RBG
a esta UE. Por otro lado, en el dominio de la frecuencia rendimiento promedio ciego (FD-BET),
cada TTI, el programador primero selecciona un UE con el rendimiento promedio pasado más bajo (mayor
métrica de prioridad). Luego, el programador asigna un RBG a este UE, calcula el esperado
rendimiento de este UE y lo usa para compararlo con el rendimiento promedio pasado T_{j}(t) de
otros UE. El programador continúa asignando RBG a este UE hasta que se espera
el rendimiento no es el más pequeño entre el rendimiento medio anterior T_{j}(t) de todos los UE. Luego
el programador usará la misma manera para asignar RBG para un nuevo UE que tenga el pasado más bajo
rendimiento promedio T_{j}(t) hasta que todos los RBG se asignan a los UE. El principio detrás de esto
es que, en cada TTI, el programador hace todo lo posible para lograr el mismo rendimiento entre
todos los UE.

Token Bank Suficientemente bueno Cola Scheduler
Token Bank Fair Queue (TBFQ) es un programador consciente de QoS que se deriva del depósito con fugas
mecanismo. En TBFQ, un flujo de tráfico del usuario i se caracteriza por los siguientes parámetros:

· t_{i}: tasa de llegada de paquetes (byte/seg)

· r_{i}: tasa de generación de tokens (byte/seg)

· p_{i}: tamaño del conjunto de fichas (byte)

· E_{i}: contador que registra el número de tokens prestados o entregados al token
banco por flujo i ; E_{i} puede ser menor que cero

Cada dato de K bytes consume k tokens. Además, TBFQ mantiene un banco de fichas compartido (B) para
equilibrar el tráfico entre diferentes flujos. Si la tasa de generación de tokens r_{i} es mayor que
tasa de llegada de paquetes t_{i}, luego los tokens que se desbordan del conjunto de tokens se agregan al token
banco, y E_{i} se incrementa en la misma cantidad. De lo contrario, el flujo necesito retirarme.
tokens del banco de tokens en función de una métrica de prioridad frac{E_{i}}{r_{i}}, y E_{i} es
disminuido Obviamente, el usuario contribuye más en el banco de fichas tiene mayor prioridad para
pedir prestadas fichas; por otro lado, el usuario toma prestados más tokens del banco tiene menos
prioridad para continuar retirando tokens. Por lo tanto, en caso de que varios usuarios tengan la
misma tasa de generación de tokens, tasa de tráfico y tamaño del conjunto de tokens, el usuario sufre una mayor
la interferencia tiene más oportunidades de tomar prestados tokens del banco. Además, TBFQ puede vigilar
el tráfico estableciendo la tasa de generación de tokens para limitar el rendimiento. Adicionalmente,
TBFQ también mantiene los siguientes tres parámetros para cada flujo:

· Límite de deuda d_{i}: si E_{i} está por debajo de este umbral, el usuario no puede pedir más tokens prestados
del banco Esto es para evitar que UE malicioso tome prestados demasiados tokens.

· Límite de crédito c_{i}: el número máximo de tokens UE que puedo pedir prestado del banco en uno
en las transacciones.

· Umbral de crédito C: una vez que E_{i} alcanza el límite de deuda, UE i debe almacenar tokens C en el banco
con el fin de pedir más prestado el token del banco.

LTE en NS-3 tiene dos versiones del programador TBFQ: dominio de frecuencia TBFQ (FD-TBFQ) y tiempo
dominio TBFQ (TD-TBFQ). En FD-TBFQ, el programador siempre selecciona UE con la métrica más alta y
asigna RBG con el CQI de subbanda más alto hasta que no haya paquetes dentro del búfer RLC de UE
o se asignan todas las RBG [FABokhari2009]. En TD-TBFQ, después de seleccionar UE con máximo
métrica, asigna todos los RBG a este UE mediante el uso de CQI de banda ancha [WKWong2004].

Prioridad Set Scheduler
El programador de conjuntos de prioridades (PSS) es un programador consciente de QoS que combina el dominio del tiempo (TD) y
operaciones de programación de paquetes de dominio de frecuencia (FD) en un solo programador [GMonghal2008]. Eso
controla la equidad entre los UE mediante una tasa de bits objetivo (TBR) especificada.

En la parte del programador de TD, PSS primero selecciona los UE con un búfer RLC no vacío y luego los divide
en dos conjuntos basados ​​en el TBR:

· conjunto 1: UE cuyo rendimiento promedio anterior es menor que TBR; El programador de TD calcula
su métrica de prioridad en estilo Blind Equal Throughput (BET):

· conjunto 2: UE cuyo rendimiento promedio pasado es mayor (o igual) que TBR; programador de TD
calcula su métrica de prioridad en estilo Proporcional Justo (PF):

Los UE pertenecientes al conjunto 1 tienen mayor prioridad que los del conjunto 2. Luego, PSS seleccionará
N_{mux} UE con la métrica más alta en dos conjuntos y reenvía esos UE al programador de FD. en PSS,
El programador de FD asigna RBG k a UE n que maximiza la métrica elegida. Dos programadores PF
se utilizan en el programador de PF:

· Feria Proporcional Programada (PFsch)

· Portadora sobre Interferencia a la Media (CoIta)

donde Tsch_{j}(t) es un rendimiento de rendimiento pasado similar percibido por el usuario j, con el
diferencia de que se actualiza solo cuando el i-ésimo usuario es realmente atendido. CoI[j,k] es un
estimación de la SINR sobre la RBG k del UE j. Tanto PFsch como CoIta son para desacoplar FD
Métrica del programador de TD. Además, el programador PSS FD también proporciona una métrica de peso W[n]
para ayudar a controlar la equidad en caso de un bajo número de UE.

donde T_{j}(t) es el rendimiento pasado percibido por el usuario j. Por lo tanto, en
RBG k, el programador FD selecciona el UE j que maximiza el producto de la frecuencia
métrica de dominio (Msch, MCoI) por peso W[n]. Esta estrategia garantizará el rendimiento de
Los UE de menor calidad tienden hacia la TBR.

Config::SetDefault ("ns3::PfFfMacScheduler::HarqEnabled", BooleanValue (falso));

El planificador implementa el filtrado de los CQI de enlace ascendente según su naturaleza con
UlCqiFiltro atribuir, en detalle:

· SRS_UL_CQI: solo los CQI basados ​​en SRS se almacenan en los atributos internos.

· PUSCH_UL_CQI: solo los CQI basados ​​en PUSCH se almacenan en los atributos internos.

· ALL_UL_CQI: todos los CQI se almacenan en el mismo atributo interno (es decir, el último CQI
recibido se almacena independientemente de su naturaleza).

Channel y QoS Consciente Scheduler
El programador Channel and QoS Aware (CQA) [Bbojovic2014] es una programación de enlace descendente LTE MAC
algoritmo que considera el retraso de cabeza de línea (HOL), los parámetros GBR y el canal
calidad en diferentes subbandas. El programador CQA se basa en la programación conjunta de TD y FD.

En el TD (en cada TTI) el programador CQA agrupa a los usuarios por prioridad. El propósito de
La agrupación es hacer cumplir la programación FD para considerar primero los flujos con mayor HOL
demora. La métrica de agrupación m_{td} para el usuario j=1,...,N se define de la siguiente manera:

donde d_{hol}^{j}(t) es el valor actual del retraso HOL del flujo j, y g es una agrupación
parámetro que determina la granularidad de los grupos, es decir, el número de flujos que
será considerado en la iteración de programación de FD.

Los grupos de flujos seleccionados en la iteración de TD se envían a la programación de FD
a partir de los flujos con el valor más alto de la métrica m_{td} hasta que todos los RBG estén
asignado en el TTI correspondiente. En el FD, para cada RBG k=1,...,K, el programador CQA
asigna el RBG actual al usuario j que tiene el valor máximo de la métrica FD que
definir de la siguiente manera:

donde m_{GBR}^j(t) se calcula de la siguiente manera:

donde GBR^j es la tasa de bits especificada en EPS portador del flujo j, rie R j ( ) shps rendimiento aerado que
se calcula con un promedio móvil, r^{j}(t) es el rendimiento logrado en el momento t,
y lpha es un coeficiente tal que 0 lpha ..sp Para m_{ca}^{(k,j)}(t) consideramos dos
diferentes métricas: m_{pf}^{(k,j)}(t) y m_{ff}^{(k,j)}(t). m_{pf} es el proporcional
Métrica justa que se define de la siguiente manera:

donde R_e^{(k,j)}(t) es el rendimiento alcanzable estimado del usuario j sobre RBG k
calculado por el esquema de Codificación y Modulación Adaptativa (AMC) que mapea el canal
valor del indicador de calidad (CQI) al tamaño del bloque de transporte en bits.

La otra métrica de conocimiento del canal que consideramos es m_{ff}, que se propone en
[GMonghal2008] y representa las ganancias de desvanecimiento selectivo de frecuencia sobre RBG k para el usuario
j y se calcula de la siguiente manera:

donde CQI^{(k,j)}(t) es el último valor de CQI informado por el usuario j para el k-ésimo RBG.

El usuario puede seleccionar si se usa m_{pf} o m_{ff} configurando el atributo
ns3::CqaFfMacScheduler::CqaMetric respectivamente a "CqaPf" or "CqaFF".

Aleatorio Acceso
El modelo LTE incluye un modelo del procedimiento de Acceso Aleatorio basado en algunas simplificaciones
supuestos, que se detallan a continuación para cada uno de los mensajes y señales
descrito en las especificaciones [TS36321].

· Aleatorio Acceso (REAL ACADEMIA DE BELLAS ARTES) preámbulo: en sistemas LTE reales esto corresponde a un Zadoff-Chu
(ZC) secuencia utilizando uno de varios formatos disponibles y enviado en las ranuras PRACH
que en principio podría solaparse con PUSCH. El índice de configuración PRACH 14 es
supuesto, es decir, los preámbulos pueden enviarse en cualquier número de trama y número de subtrama del sistema.
El preámbulo RA se modela utilizando la clase LteControlMessage, es decir, como un ideal
mensaje que no consume ningún recurso de radio. La colisión del preámbulo
la transmisión por múltiples UE en la misma celda se modela usando un protocolo
modelo de interferencia, es decir, siempre que dos o más preámbulos idénticos se transmiten en
misma celda en el mismo TTI, ninguno de estos preámbulos idénticos será recibido por
el eNB. Aparte de este modelo de colisión, ningún modelo de error está asociado con el
recepción de un preámbulo de RA.

· Aleatorio Acceso Respuesta (rar): en sistemas LTE reales, esta es una PDU MAC especial enviada en
el DL-SCH. Dado que los elementos de control MAC no se modelan con precisión en el simulador
(solo RLC y PDU superiores lo son), el RAR se modela como un LteControlMessage que no
no consume ningún recurso de radio. Aún así, durante el procedimiento de RA, el LteEnbMac
solicitar al programador la asignación de recursos para el RAR utilizando el FF MAC
Programador primitivo SCHED_DL_RACH_INFO_REQ. Por lo tanto, un planificador mejorado
implementación (no disponible en este momento) podría asignar recursos de radio para la
RAR, modelando así el consumo de Recursos Radio para la transmisión de los
rar

· Tu Mensaje 3: en sistemas LTE reales, esta es una SDU RLC TM enviada a través de recursos especificados
en la UL Grant en el RAR. En el simulador, esto se modela como un RLC TM RLC real
PDU cuyos recursos UL son asignados por el programador al llamar a
SCHED_DL_RACH_INFO_REQ.

· Contención Resolución (CR): en el sistema LTE real, la fase CR es necesaria para abordar el
caso en el que dos o más UE enviaron el mismo preámbulo RA en el mismo TTI, y el eNB fue
capaz de detectar este preámbulo a pesar de la colisión. Dado que este evento no
ocurrir debido al modelo de interferencia de protocolo utilizado para la recepción de preámbulos RA,
la fase CR no está modelada en el simulador, es decir, el CR MAC CE nunca es enviado por
el eNB y los UE consideran que el RA ha tenido éxito al recibir el RAR. Como un
consecuencia, los recursos de radio consumidos para la transmisión del CR MAC CE son
no modelado.

Figura Secuencia diagrama of los Basado en contención dirección MAC Aleatorio Acceso procedimientos y Secuencia
diagrama of los No basado en contiendas dirección MAC Aleatorio Acceso procedimientos muestra la secuencia
diagramas de acceso aleatorio MAC basado en contención y no basado en contención, respectivamente
procedimiento, destacando las interacciones entre el MAC y las otras entidades.
[imagen] Diagrama de secuencia del procedimiento MAC Random Access basado en Contención.UNINDENT
[imagen] Diagrama de secuencia del acceso aleatorio MAC no basado en contención
procedimiento.UNINDENT

RLC
Descripción General
La entidad RLC se especifica en la especificación técnica 3GPP [TS36322] y comprende
tres tipos diferentes de RLC: Modo transparente (TM), Modo sin acuse de recibo (UM) y
Modo reconocido (AM). El simulador incluye un modelo para cada una de estas entidades

Las entidades RLC proporcionan la interfaz de servicio RLC a la capa superior de PDCP y al MAC
interfaz de servicio a la capa MAC inferior. Las entidades RLC utilizan la interfaz de servicio PDCP
desde la capa PDCP superior y la interfaz de servicio MAC desde la capa MAC inferior.

Figura Implementación Modelo of PDCP, RLC y dirección MAC entidades y SAP muestra el
modelo de implantación de las entidades RLC y su relación con el resto de entidades
y servicios en la pila de protocolos.
[imagen] Modelo de Implementación de entidades PDCP, RLC y MAC y SAPs.UNINDENT

Servicio Interfaces
RLC Servicio Fácil de usar
La interfaz de servicio RLC se divide en dos partes:

· los Proveedor RlcSap parte es proporcionada por la capa RLC y utilizada por la capa superior PDCP
y

· los UsuarioRlcSap parte es proporcionada por la capa PDCP superior y utilizada por la capa RLC.

Tanto las entidades RLC de UM como las de AM proporcionan la misma interfaz de servicio de RLC a la parte superior.
capa PDCP.

RLC Servicio Primitivas
La siguiente lista especifica qué primitivas de servicio proporciona el servicio RLC
interfaces:

· RlcSapProvider::TransmitirPdcpPdu

· La entidad PDCP utiliza esta primitiva para enviar una PDU PDCP a la entidad RLC inferior
en el transmisor peer

· RlcSapUser::RecibirPdcpPdu

· La entidad RLC utiliza esta primitiva para enviar una PDU PDCP a la entidad PDCP superior
en el compañero receptor

dirección MAC Servicio Fácil de usar
La interfaz de servicio MAC se divide en dos partes:

· los Proveedor MacSap parte es proporcionada por la capa MAC y utilizada por la capa RLC superior
y

· los Usuario de MacSap parte es proporcionada por la capa RLC superior y utilizada por la capa MAC.

dirección MAC Servicio Primitivas
La siguiente lista especifica qué primitivas de servicio proporciona el servicio MAC
interfaces:

· MacSapProvider::TransmitirPdu

· La entidad RLC utiliza esta primitiva para enviar una PDU RLC a la entidad MAC inferior en
el compañero transmisor

· MacSapProvider::ReportBufferStatus

· La entidad RLC usa esta primitiva para informar a la entidad MAC el tamaño de los pendientes
búferes en el par transmisor

· MacSapUser::NotifyTxOportunidad

· La entidad MAC utiliza esta primitiva para noficar a la entidad RLC una transmisión
oportunidad

· MacSapUser::RecibirPdu

· La entidad MAC utiliza esta primitiva para enviar una PDU RLC a la entidad RLC superior
en el compañero receptor

AM RLC
Se explica el procesamiento de la transferencia de datos en la entidad RLC del modo de reconocimiento (AM)
en la sección 5.1.3 de [TS36322]. En esta sección describimos algunos detalles de la
implantación de la entidad RLC.

Amortiguadores para los transmitir optimizar las operaciones
Nuestra implementación de la entidad AM RLC mantiene 3 búferes para las operaciones de transmisión:

· Transmisión Buffer: es la cola de SDU de RLC. Cuando la entidad AM RLC recibe una SDU
en la primitiva de servicio TransmitPdcpPdu de la entidad PDCP superior, lo pone en cola
en el búfer de transmisión. Ponemos un límite en el tamaño del búfer RLC y simplemente en silencio
descarte las SDU cuando el búfer esté lleno.

· transmitido PDUs Buffer: es la cola de PDU RLC transmitidas para las cuales
Aún no se ha recibido ACK/NACK. Cuando la entidad AM RLC envía una PDU al MAC
entidad, también coloca una copia de la PDU transmitida en el búfer de PDU transmitidas.

· retransmisión Buffer: es la cola de RLC PDU que se consideran para
retransmisión (es decir, han sido NACKed). La entidad AM RLC mueve esta PDU a la
Búfer de retransmisión, cuando retransmite una PDU desde el Búfer de transmisión.

Transmitir optimizar las operaciones in enlace descendente
El siguiente diagrama de secuencia muestra las interacciones entre las diferentes entidades (RRC,
PDCP, AM RLC, MAC y programador MAC) del eNB en el enlace descendente para realizar datos
comunicaciones

Figura Secuencia diagrama of datos PDU transmisión in enlace descendente muestra cómo las capas superiores
enviar PDU de datos y cómo el flujo de datos es procesado por las diferentes entidades/servicios de
la pila de protocolos LTE.
[imagen] Diagrama de secuencia de transmisión de PDU de datos en enlace descendente.UNINDENT

La entidad del PDCP llama al Transmitir_PDCP_PDU Service primitivo para enviar un dato
PDU. La entidad RLC de AM procesa esta primitiva de servicio de acuerdo con los datos de AM
procedimientos de transferencia definidos en la sección 5.1.3 de [TS36322].

Cuando el Transmitir_PDCP_PDU se llama a la primitiva de servicio, la entidad AM RLC realiza el
siguientes operaciones:

· Coloque la SDU de datos en el búfer de transmisión.

· Calcular el tamaño de los búferes (cómo se calcula el tamaño de los búferes será
explicado después).

· Llama a Estado_de_búfer_de_informe primitiva de servicio de la entidad eNB MAC para
notificar a la entidad eNB MAC los tamaños de las memorias intermedias de la entidad AM RLC. Entonces el
La entidad eNB MAC actualiza el estado del búfer en el planificador MAC utilizando el
Primitivo de servicio SchedDlRlcBufferReq de la API del programador FF MAC.

Posteriormente, cuando el programador MAC decide que se pueden enviar algunos datos, la entidad MAC
lo notifica a la entidad RLC, es decir, llama al Notificar_Tx_Oportunidad servicio primitivo,
entonces la entidad AM RLC hace lo siguiente:

· Crear una sola PDU de datos segmentando y/o concatenando las SDU en el
Amortiguador de transmisión.

· Mover la PDU de datos del búfer de transmisión al búfer de PDU transmitidas.

· Actualizar las variables de estado según la sección 5.1.3.1.1 de [TS36322].

· Llama a Transmitir_PDU primitiva para enviar la PDU de datos a la entidad MAC.

retransmisión in enlace descendente
El diagrama de secuencia de la figura Secuencia diagrama of datos PDU retransmisión in enlace descendente
muestra las interacciones entre las diferentes entidades (AM RLC, MAC y planificador MAC) de
el eNB en el enlace descendente cuando las PDU de datos deben ser retransmitidas por la entidad AM RLC.
[imagen] Diagrama de secuencia de retransmisión de PDU de datos en enlace descendente.UNINDENT

La entidad AM RLC transmisora ​​puede recibir STATUS PDU de la entidad AM RLC par.
Las PDU de ESTADO se envían de acuerdo con la sección 5.3.2 de [TS36322] y el procesamiento de
la recepción se realiza de acuerdo con la sección 5.2.1 de [TS36322].

Cuando una PDU de datos se retransmite desde el búfer de PDU transmitidas, también se mueve a
el búfer de retransmisión.

Transmitir optimizar las operaciones in enlace ascendente
El diagrama de secuencia de la figura Secuencia diagrama of datos PDU transmisión in enlace ascendente enseñe
las interacciones entre las diferentes entidades de la UE (RRC, PDCP, RLC y MAC) y la
eNB (MAC y Scheduler) en enlace ascendente cuando las capas superiores envían PDU de datos.
[imagen] Diagrama de secuencia de transmisión de PDU de datos en uplink.UNINDENT

Es similar al diagrama de secuencia en el enlace descendente; la principal diferencia es que en este
caso de que Report_Buffer_Status se envíe desde el UE MAC al MAC Scheduler en el eNB
por el aire utilizando el canal de control.

retransmisión in enlace ascendente
El diagrama de secuencia de la figura Secuencia diagrama of datos PDU retransmisión in enlace ascendente enseñe
las interacciones entre las diferentes entidades del UE (AM RLC y MAC) y el eNB
(MAC) en enlace ascendente cuando las PDU de datos deben ser retransmitidas por la entidad RLC de AM.
[imagen] Diagrama de secuencia de retransmisión de PDU de datos en uplink.UNINDENT

Cálculo of los buffer tamaño
El búfer de transmisión contiene SDU de RLC. Una PDU RLC es uno o más segmentos SDU más un
Encabezado RLC. El tamaño del encabezado RLC de una PDU RLC depende del número de SDU
segmentos que contiene la PDU.

El estándar 3GPP (sección 6.1.3.1 de [TS36321]) dice claramente que, para el enlace ascendente, el
Los encabezados RLC y MAC no se consideran en el tamaño del búfer que se debe informar como parte de
el informe de estado del búfer. Para el enlace descendente, no se especifica el comportamiento. Ninguno de los dos
[FFAPI] especifica cómo hacerlo. Nuestro modelo RLC funciona suponiendo que el cálculo de
el tamaño del búfer en el enlace descendente se realiza exactamente como en el enlace ascendente, es decir, sin considerar
el tamaño del encabezado RLC y MAC.

Notamos que esta elección afecta la interoperación con el programador MAC, ya que, en
respuesta a la Notificar_Tx_Oportunidad primitiva de servicio, se espera que el RLC cree un
PDU de no más del tamaño solicitado por el MAC, incluida la sobrecarga de RLC. Por lo tanto, innecesario
la fragmentación puede ocurrir si (por ejemplo) el MAC notifica una transmisión exactamente igual a
el tamaño del búfer informado previamente por el RLC. Suponemos que se deja al Programador
implementar estrategias inteligentes para la selección del tamaño de la transmisión
oportunidad, a fin de evitar eventualmente la ineficiencia de la fragmentación innecesaria.

Concatenación y Segmentación
La entidad AM RLC genera y envía exactamente una RLC PDU para cada transmisión
oportunidad incluso si es más pequeño que el tamaño informado por la oportunidad de transmisión.
Entonces, por ejemplo, si se va a enviar una PDU DE ESTADO, solo se enviará esta PDU en ese
oportunidad de transmisión.

La segmentación y concatenación para la cola SDU de la entidad AM RLC sigue el mismo
filosofía como los mismos procedimientos de la entidad UM RLC pero hay nuevas variables de estado
(ver [TS36322] sección 7.1) solo presente en la entidad AM RLC.

Se observa que, de acuerdo con las especificaciones 3GPP, no hay concatenación para el
Búfer de retransmisión.

Re-segmentación
El modelo actual de la entidad AM RLC no admite la re-segmentación de la
búfer de retransmisión. Más bien, la entidad AM RLC solo espera recibir una cantidad lo suficientemente grande
oportunidad de transmisión.

No compatible Características
No admitimos los siguientes procedimientos de [TS36322]:

· “Enviar indicación de entrega exitosa de RLC SDU” (Ver apartado 5.1.3.1.1)

· “Indicar a capas superiores que se ha alcanzado el máximo de retransmisión” (Ver apartado
5.2.1).

· “Procedimientos de descarte de SDU” (Ver apartado 5.3)

· “Procedimiento de restablecimiento” (Ver apartado 5.4)

No admitimos ninguna de las primitivas adicionales de RLC SAP para la entidad AM RLC. En
especial:

· ningún descarte de SDU notificado por PDCP

· ninguna notificación de entrega exitosa/fallida por parte de la entidad AM RLC a la entidad PDCP

UM RLC
En esta sección, describimos la implementación de la entidad RLC del modo sin reconocimiento (UM).

Transmitir optimizar las operaciones in enlace descendente
Las operaciones de transmisión del UM RLC son similares a las del AM RLC anteriormente
descrito en la Sección Transmitir optimizar las operaciones in enlace descendente, con la diferencia de que, siguiendo
las especificaciones de [TS36322], la retransmisión no se realiza y no hay ESTADO
PDU.

Transmitir optimizar las operaciones in enlace ascendente
Las operaciones de transmisión en el enlace ascendente son similares a las del enlace descendente, con la principal
diferencia de que Report_Buffer_Status se envía desde el UE MAC al MAC Scheduler en
el eNB por el aire utilizando el canal de control.

Cálculo of los buffer tamaño
El cálculo del tamaño del búfer para el UM RLC se realiza utilizando el mismo enfoque del
AM RLC, consulte la sección Cálculo of los buffer tamaño para el correspondiente
descripción.

TM RLC
En esta sección describimos la implementación de la entidad RLC de modo transparente (TM).

Transmitir optimizar las operaciones in enlace descendente
En el simulador, el TM RLC aún proporciona a las capas superiores la misma interfaz de servicio
proporcionada por las entidades RLC AM y UM a la capa PDCP; en la práctica, esta interfaz es
utilizado por una entidad RRC (no una entidad PDCP) para la transmisión de RLC SDU. Esta elección es
motivado por el hecho de que los servicios proporcionados por el TM RLC a las capas superiores,
según [TS36322], es un subconjunto de los proporcionados por las entidades UM y AM RLC al
capa PDCP; por lo tanto, reutilizamos la misma interfaz por simplicidad.

Las operaciones de transmisión en el enlace descendente se realizan de la siguiente manera. Cuando el
Transmitir_PDCP_PDU Service primitivo es llamado por las capas superiores, el TM RLC hace el
siguientes:

· poner la SDU en el búfer de transmisión

· calcular el tamaño del búfer de transmisión

· llama a Estado_de_búfer_de_informe primitiva de servicio de la entidad eNB MAC

Posteriormente, cuando el programador MAC decide que algunos datos pueden ser enviados por el lógico
canal al que pertenece la entidad TM RLC, la entidad MAC lo notifica al TM RLC
entidad llamando al Notificar_Tx_Oportunidad primitiva de servicio. Al recibir este
primitiva, la entidad TM RLC hace lo siguiente:

· si la oportunidad de TX tiene un tamaño mayor o igual al tamaño de la
SDU de cabeza de línea en el búfer de transmisión

· eliminar la SDU de cabeza de línea del búfer de transmisión

· crear una PDU de RLC que contenga completamente esa SDU, sin ningún encabezado de RLC

· Llama a Transmitir_PDU primitiva para enviar la RLC PDU a la entidad MAC.

Transmitir optimizar las operaciones in enlace ascendente
Las operaciones de transmisión en el enlace ascendente son similares a las del enlace descendente, con la principal
diferencia de que una oportunidad de transmisión también puede surgir de la asignación de la UL
GRANT como parte del procedimiento de acceso aleatorio, sin un informe de estado de búfer explícito
emitido por la entidad TM RLC.

Cálculo of los buffer tamaño
Según las especificaciones [TS36322], el TM RLC no agrega ningún encabezado RLC a las PDU
siendo transmitido. Debido a esto, el tamaño del búfer informado a la capa MAC es
calcula simplemente sumando el tamaño de todos los paquetes en el búfer de transmisión, por lo tanto
notificando al MAC el tamaño exacto del búfer.

SM RLC
Además de las implementaciones de AM, UM y TM que siguen el modelo de 3GPP
especificaciones, se proporciona un modelo RLC simplificado, que se denomina modo de saturación (SM)
RLC. Este modelo de RLC no acepta PDU de ninguna capa superior (como PDCP); más bien, el
SM RLC se encarga de la generación de RLC PDUs en respuesta a la notificación de
oportunidades de transmisión notificadas por el MAC. En otras palabras, el SM RLC simula
condiciones de saturación, es decir, asume que el búfer RLC siempre está lleno y puede
generar una nueva PDU siempre que lo notifique el programador.

El SM RLC se usa para escenarios de simulación simplificados en los que solo el modelo LTE Radio
se utiliza, sin el EPC y, por lo tanto, sin ningún soporte de red IP. Notamos eso,
aunque el SM RLC es un modelo de tráfico poco realista, todavía permite el correcto
simulación de escenarios con múltiples flujos pertenecientes a diferentes QoS (no en tiempo real)
clases, con el fin de probar el rendimiento de QoS obtenido por diferentes programadores. Esto puede
hacerse ya que es tarea del Programador asignar recursos de transmisión basados ​​en
las características (por ejemplo, tasa de bits garantizada) de cada portador de radio, que se especifican
de la definición de cada Portador dentro del programa de simulación.

En cuanto a los programadores diseñados para trabajar con tráfico QoS en tiempo real que tiene restricciones de retraso,
el SM RLC probablemente no sea una opción apropiada. Esto se debe a que la ausencia de
Las SDU de RLC (reemplazadas por la generación artificial de informes de estado del búfer) hacen que no sea
posible proporcionar al programador información significativa sobre el retraso de la cabecera de la línea, que es
a menudo la métrica de elección para la implementación de políticas de programación para tiempo real
flujos de tráfico. Para la simulación y prueba de dichos programadores, es recomendable utilizar
en su lugar, los modelos UM o AM RLC.

PDCP
PDCP Modelo Descripción General
El documento de referencia para la especificación de la entidad PDCP es [TS36323]. Con Respeto
Según esta especificación, el modelo PDCP implementado en el simulador solo admite la
siguientes características:

· transferencia de datos (plano de usuario o plano de control);

· mantenimiento de los SN del PDCP;

· transferencia del estatus de SN (para uso en el traspaso);

Las siguientes características no son compatibles actualmente:

· compresión y descompresión de encabezados de flujos de datos IP utilizando el protocolo ROHC;

· entrega en secuencia de PDU de capa superior en el restablecimiento de las capas inferiores;

· eliminación duplicada de SDU de capa inferior en el restablecimiento de capas inferiores para
portadores de radio mapeados en RLC AM;

· cifrado y descifrado de datos del plano de usuario y datos del plano de control;

· protección de la integridad y verificación de la integridad de los datos del plano de control;

· descarte basado en temporizador;

· descarte de duplicados.

PDCP Servicio Fácil de usar
La interfaz de servicio PDCP se divide en dos partes:

· los Proveedor PdcpSap parte es proporcionada por la capa PDCP y utilizada por la capa superior
y

· los PdcpSapUsuario parte es proporcionada por la capa superior y utilizada por la capa PDCP.

PDCP Servicio Primitivas
La siguiente lista especifica qué primitivas de servicio proporciona el servicio PDCP
interfaces:

· PdcpSapProvider::TransmitirPdcpSdu

· La entidad RRC utiliza esta primitiva para enviar una PDU RRC a la entidad PDCP inferior
en el transmisor peer

· PdcpSapUser::RecibirPdcpSdu

· La entidad PDCP utiliza esta primitiva para enviar una PDU RRC a la entidad RRC superior
en el compañero receptor

RRC
Caracteristicas
El modelo RRC implementado en el simulador proporciona la siguiente funcionalidad:

· generación (en el eNB) e interpretación (en el UE) de Información del Sistema (en
en particular, el Bloque de información maestro y, en el momento de redactar este documento, solo el Sistema
Bloque de información tipo 1 y 2)

· selección de celda inicial

· Procedimiento de establecimiento de conexión RRC

· Procedimiento de reconfiguración de RRC, soportando los siguientes casos de uso: + reconfiguración
del índice de configuración SRS + reconfiguración del modo PHY TX (MIMO) +
reconfiguración de medidas de UE + configuración de portador de radio de datos + traspaso

· Restablecimiento de conexión RRC, soportando los siguientes casos de uso: + handover

Arquitectura
El modelo RRC se divide en los siguientes componentes:

· las entidades de RRC LteUeRrc y LteEnbRrc, que implementan las máquinas de estado del
entidades RRC respectivamente en el UE y el eNB;

· los RRC SAP LteUeRrcSapProviderLteUeRrcSapProvider, LteUeRrcSapUsuario, Proveedor LteEnbRrcSap,
LteEnbRrcSapUsuario, que permiten a las entidades RRC enviar y recibir mensajes RRC y
elementos de información;

· las clases de protocolo RRC Protocolo LteUeRrcIdeal, Protocolo LteEnbRrcIdeal,
LteUeRrcProtocoloReal, LteEnbRrcProtocoloReal, que implementan dos modelos diferentes para
la transmisión de mensajes RRC.

Además, los componentes de RRC utilizan varios otros SAP para interactuar con el resto
de la pila de protocolos. Se proporciona una representación de todos los SAP que se utilizan en el
cifras LTE radio protocolo montón para los UE on los datos avión, LTE radio
protocolo montón para los UE on los control avión, LTE radio protocolo montón
para los eNB on los datos avión y LTE radio protocolo montón para
los eNB on los control avión.

UE RRC Estado Máquina
En figura UE RRC Estado Máquina representamos la máquina de estado implementada en el RRC UE
entidad.
[imagen] UE RRC State Machine.UNINDENT

Cabe señalar que la mayoría de los estados son transitorios, es decir, una vez que el UE entra en uno
de los estados CONECTADO, nunca volverá a cambiar a ninguno de los estados INACTIVO. esta elección
se hace por las siguientes razones:

· como se discutió en la sección Design Criterios, el foco de la simulación LTE-EPC
el modelo está en modo CONECTADO

· la falla del enlace de radio no se modela actualmente, como se analiza en la sección Radio Enlace
Fracaso, por lo que un UE no puede pasar a IDLE debido a una falla en el enlace de radio

· Actualmente, la liberación de la conexión RRC nunca se activa ni por el EPC ni por el NAS

Aún así, elegimos modelar explícitamente los estados IDLE, porque:

· se necesita una configuración realista de UE RRC para el traspaso, que es una característica requerida,
y para tener una implementación más limpia, tiene sentido usar el mismo UE RRC
configuración también para el establecimiento de la conexión inicial

· facilita la implementación de la selección de celdas en modo inactivo en el futuro, lo cual es un
característica muy deseable

ENB RRC Estado Máquina
El eNB RRC mantiene el estado de cada UE que está conectado a la celda. Desde un
desde el punto de vista de la implementación, el estado de cada UE está contenido en una instancia del
Clase UeManager. La máquina de estados se representa en la figura ENB RRC Estado Máquina para cada una
UE.
[imagen] Máquina de estado ENB RRC para cada UE.UNINDENT

Inicial Celular Selección
La selección de celda inicial es un procedimiento de modo IDLE, realizado por UE cuando aún no ha
acampado o conectado a un eNodeB. El objetivo del procedimiento es encontrar una celda adecuada
y adjúntelo para obtener acceso a la red celular.

Por lo general, se realiza al comienzo de la simulación, como se muestra en la Figura Muestra corre of
inicial (SCD por sus siglas en inglés), selección in UE y sincronización of relacionado eventos abajo. El diagrama de tiempo en el
el lado izquierdo ilustra el caso en el que la selección inicial de celdas tuvo éxito en el primer intento,
mientras que el diagrama del lado derecho es para el caso en que falla en el primer intento y
tener éxito en el segundo intento. El tiempo asume el uso del modelo de protocolo RRC real (ver RRC
protocolo modelos) y sin error de transmisión.
[imagen] Ejecuciones de muestra de selección de celda inicial en UE y sincronización de
eventos.UNINDENT

La funcionalidad se basa en las especificaciones del modo IDLE 3GPP, como en [TS36300],
[TS36304] y [TS36331]. Sin embargo, todavía falta una implementación adecuada del modo IDLE
en el simulador, por lo que nos reservamos varios supuestos simplificadores:

· no se admite la frecuencia de múltiples portadoras;

· múltiples identidades de Red Móvil Terrestre Pública (PLMN) (es decir, múltiples redes
operadores) no es compatible;

· No se utilizan medidas RSRQ;

· no se admite la selección de celdas de información almacenada;

· No se admite el estado "Cualquier selección de celda" ni acampar en una celda aceptable;

· No se admite marcar una celda como bloqueada o reservada;

· no se admite la reselección de celda, por lo tanto, no es posible que UE acampe en un
celda diferente después de haber colocado el campamento inicial; y

· La lista blanca del grupo cerrado de suscriptores (CSG) de UE contiene solo una identidad CSG.

Tenga en cuenta también que la selección de celda inicial solo está disponible para simulaciones habilitadas para EPC.
Las simulaciones solo de LTE deben usar el método de conexión manual. Mira la sección
sec-network-attachment de la Documentación del Usuario para más información sobre sus diferencias
en uso.

Las siguientes subsecciones cubren diferentes partes de la selección inicial de celdas, a saber (SCD por sus siglas en inglés), Buscar,
transmisión of te información y (SCD por sus siglas en inglés), selección evaluación.

Celular Buscar
La búsqueda de celdas tiene como objetivo detectar las celdas circundantes y medir la fuerza de la señal recibida
de cada una de estas celdas. Una de estas celdas se convertirá en el punto de entrada de la UE para unirse a la
red celular.

Las mediciones se basan en el RSRP del PSS recibido, promediado por el filtrado de Capa 1,
y realizado por la capa PHY, como se describió previamente con más detalle en la sección UE PHY
Medidas Modelo. PSS es transmitido por eNodeB sobre las 72 subportadoras centrales del
canal DL (Sección 5.1.7.3 [TS36300]), por lo tanto, modelamos la búsqueda de celdas para operar usando un DL
ancho de banda de 6 RBs. Tenga en cuenta que las mediciones de RSRQ no están disponibles en este momento
en simulación. Como consecuencia, el LteUePhy::RsrqUeMeasThreshold el atributo no
aplicar durante la búsqueda de celdas.

Al usar el RSRP medido, la entidad PHY puede generar una lista de celdas detectadas,
cada uno con su ID de celda correspondiente y RSRP promediado. Esta lista se envía periódicamente
vía CPHY SAP a la entidad RRC como informe de medición.

La entidad RRC inspecciona el informe y simplemente elige la celda con el RSRP más fuerte, como
también indicado en la Sección 5.2.3.1 de [TS36304]. Luego instruye a la entidad PHY para que
sincronizar con esta celda en particular. El ancho de banda operativo real de la celda sigue siendo
desconocido en este momento, por lo que la entidad PHY solo escucha el ancho de banda mínimo de 6 RB.
Sin embargo, la entidad PHY podrá recibir mensajes de difusión del sistema desde este
eNodeB particular, que es el tema de la siguiente subsección.

Radio of System Información
Los bloques de información del sistema son transmitidos por eNodeB a los UE en intervalos de tiempo predefinidos,
adaptado de la Sección 5.2.1.2 de [TS36331]. Los bloques de información del sistema admitidos son:

·

Domina el Información Bloquear (MIB)
Contiene parámetros relacionados con la capa PHY, generados durante la celda
configuración y se transmite cada 10 ms al comienzo de la trama de radio como un
mensaje de control.

·

System Información Bloquear Tipo 1 (SIB1)
Contiene información sobre el acceso a la red, transmitida cada 20 ms en el
medio del cuadro de radio como un mensaje de control. No se utiliza en el accesorio manual
método. UE debe haber decodificado MIB antes de que pueda recibir SIB1.

·

System Información Bloquear Tipo 2 (SIB2)
Contiene configuraciones relacionadas con UL y RACH, programadas para transmitir a través del protocolo RRC
a los 16 ms después de la configuración de la celda, y luego se repite cada 80 ms (configurable
atravesar LteEnbRrc::Periodicidad de información del sistema atributo. UE debe estar acampado
a una celda para poder recibir su SIB2.

La recepción de la información del sistema es fundamental para que la UE avance en su ciclo de vida. MIB
permite que el UE aumente el ancho de banda inicial de DL de 6 RB al funcionamiento real
ancho de banda de la red. SIB1 proporciona información necesaria para la selección de celda
evaluación (explicado en la siguiente sección). Y finalmente se requiere SIB2 antes de que el UE sea
permitido cambiar al estado CONECTADO.

Celular Selección Evaluación
UE RRC revisa el informe de medición elaborado en Celular Buscar y el acceso a la celda
información proporcionada por SIB1. Una vez que ambas informaciones están disponibles para una celda específica, el
UE desencadena el proceso de evaluación. El propósito de este proceso es determinar si
la celda es una celda adecuada para acampar.

El proceso de evaluación es una versión ligeramente simplificada de la Sección 5.2.3.2 de [TS36304].
Consta de los siguientes criterios:

· Criterio de nivel de prescripción; y

· criterio de grupo cerrado de suscriptores (CSG).

El primer criterio, el nivel Rx, se basa en el RSRP Q_{rxlevmeas} medido de la celda, que
tiene que ser más alto que un Q_{rxlevmin} mínimo requerido para pasar el criterio:

donde Q_{rxlevmin} está determinado por cada eNodeB y el UE puede obtenerlo de SIB1.

El último criterio, CSG, es una combinación de un parámetro de verdadero o falso llamado CSG
indicación y un numero sencillo CSG identidad. La regla básica es que UE no acampará para
eNodeB con una identidad CSG diferente. Pero esta regla solo se aplica cuando la indicación CSG
se valora como verdadero. Se proporcionan más detalles en la Sección sec-network-attachment del Usuario
Documentación.

Cuando la celda pasa todos los criterios anteriores, la celda se considera como adecuado. Entonces UE
campamentos a ella (IDLE_CAMPED_NORMALMENTE estado).

Después de esto, la capa superior puede solicitar al UE que ingrese al modo CONECTADO. Consulte la sección
RRC conexión establecimiento para obtener detalles sobre esto.

Por otro lado, cuando la celda no pasa el criterio CSG, entonces la celda se etiqueta
as aceptable (Sección 10.1.1.1 [TS36300]). En este caso, la entidad RRC le indicará al PHY
entidad para sincronizar con la segunda celda más fuerte y repetir la selección de celda inicial
procedimiento usando esa celda. Siempre que no se encuentre una celda adecuada, el UE repetirá estos
pasos evitando celdas que han sido identificadas como aceptables.

Radio Generales Control:
El control de admisión de radio se admite al hacer que el eNB RRC responda a una CONEXIÓN RRC
Mensaje de SOLICITUD enviado por el UE con un mensaje de ESTABLECIMIENTO DE CONEXIÓN RRC o un mensaje RRC
Mensaje de RECHAZO DE CONEXIÓN, según se admita o no el nuevo UE. En
la implementación actual, el comportamiento está determinado por el atributo booleano
ns3::LteEnbRrc::AdmitRrcConnectionRequest. Actualmente no hay Control de Acceso a Radio
algoritmo que decide dinámicamente si se admite o no una nueva conexión.

Radio Portador Configuration
Se han realizado algunas opciones de implementación en el RRC con respecto a la configuración de la radio
portadores:

· tres grupos de canales lógicos (de los cuatro disponibles) están configurados para el búfer de enlace ascendente
fines de informe de estado, de acuerdo con la siguiente política:

· LCG 0 es para señalizar portadores de radio

· LCG 1 es para portadores de radio de datos GBR

· LCG 2 es para portadores de radio de datos no GBR

Radio Enlace Fracaso
Dado que en esta etapa el RRC solo admite el modo CONECTADO, la falla del enlace de radio (RLF) es
no manejado La razón es que uno de los posibles resultados de RLF (cuando RRC
el restablecimiento es fallido) es dejar el RRC CONECTADO notificando al NAS del RRC
falla de conexión Para modelar RLF correctamente, se debe admitir el modo RRC IDLE,
incluyendo en particular la (re)selección de celda en modo inactivo.

Con el modelo actual, un UE que experimenta una mala calidad de enlace y que no funciona
traspaso (debido, por ejemplo, a que no hay celdas vecinas, traspaso deshabilitado, umbrales de traspaso
mal configurado) simplemente permanecerá asociado con el mismo eNB, y el programador se detendrá
asignándole recursos para las comunicaciones.

UE RRC Medidas Modelo
UE RRC medidas Apoyar
La entidad UE RRC proporciona soporte para mediciones de UE; en particular, implementa la
procedimientos descritos en la Sección 5.5 de [TS36331], con la siguiente simplificación
supuestos:

· solo se admiten medidas intrafrecuencia E-UTRA, lo que implica:

· solo se utiliza un objeto de medición durante la simulación;

· no se necesitan espacios de medición para realizar las mediciones;

· Los eventos B1 y B2 no están implementados;

· solamente informar de las células más fuertes se apoya el propósito, mientras que informeCGI y
informarCélulas más fuertes para SON los propósitos no son compatibles;

· Medida s no es apoyado;

· dado que la agregación de portadores no es compatible con el módulo LTE, lo siguiente
Las suposiciones en las mediciones de UE son ciertas:

· sin noción de celda secundaria (Scélula);

· celda primaria (Célula PC) simplemente significa celda de servicio;

· El evento A6 no está implementado;

· la escala dependiente de la velocidad del tiempo hasta el disparo (Sección 5.5.6.2 de [TS36331]) no es
soportado.

En general design
El modelo se basa en el concepto de UE medidas consumidor, que es una entidad que puede
Solicitar una entidad RRC eNodeB para proporcionar informes de medición de UE. Los consumidores son, por
ejemplo, Entregar algoritmo, que calculan la decisión de traspaso en función de la medición del UE
informes. Los casos de prueba y los programas de usuario también pueden convertirse en consumidores. Figura Relación familiar
entre UE medidas y Debido CONSUMIDORES describe la relación entre estas entidades.
[imagen] Relación entre las medidas de la UE y sus consumidores.UNINDENT

Toda la función de mediciones de UE a nivel de RRC se divide en 4 partes principales:

1. Configuración de la medición (gestionada por LteUeRrc::AplicarMeasConfig)

2. Realización de mediciones (a cargo de LteUeRrc::DoReportUeMedidas)

3. Activación del informe de medición (gestionado por LteUeRrc::Disparo del informe de medición)

4. Informes de medición (manejados por LteUeRrc::Enviar informe de medición)

Las siguientes secciones describirán cada una de las partes anteriores.

Measurement configuración
Una entidad eNodeB RRC configura las mediciones del UE enviando los parámetros de configuración a
la entidad UE RRC. Este conjunto de parámetros se definen dentro del Configuración de medidas Información
Elemento (IE) del mensaje de reconfiguración de conexión RRC (RRC conexión
reconfiguración).

La entidad eNodeB RRC implementa los parámetros de configuración y los procedimientos descritos en
Sección 5.5.2 de [TS36331], con la siguiente suposición simplificada:

· la configuración (es decir, adición, modificación y eliminación) solo se puede realizar antes de que
comienza la simulación;

· todos los UE conectados al eNodeB se configurarán de la misma manera, es decir, no hay
soporte para configurar medidas específicas para UE específicos; y

· se supone que existe un mapeo uno a uno entre la PCI y la E-UTRAN
Identificador de celda global (EGCI). Esto es consistente con los supuestos del modelo PCI
descrita en UE PHY Medidas Modelo.

La instancia de eNodeB RRC aquí actúa como un intermediario entre los consumidores y el
UE adjuntos. Al comienzo de la simulación, cada consumidor proporciona el eNodeB RRC
instancia con la configuración de medidas del UE que requiere. Después de eso, el eNodeB
RRC distribuye la configuración a los UE adjuntos.

Los usuarios pueden personalizar la configuración de medición utilizando varios métodos. Por favor refiérase a
Sección sec-configure-ue-measurements de la Documentación del usuario para la descripción de
estos métodos.

Realización medidas
UE RRC recibe mediciones RSRP y RSRQ periódicamente desde UE PHY, como
descrita en UE PHY Medidas Modelo. Capa 3 filtración se aplicará a estos
medidas recibidas. La implementación del filtrado sigue la Sección 5.5.3.2 de
[TS36331]:

dónde:

· M_n es el último resultado de medición recibido de la capa física;

· F_n es el resultado de medición filtrado actualizado;

· F_{n-1} es el antiguo resultado de medición filtrado, donde F_0 = M_1 (es decir, el primer
la medición no se filtra); y

· a = (ac{1}{2})^{ac{k}{4}}, donde k es el valor configurable filtroCoeficiente proporcionada por
los CantidadConfig;

k = 4 es el valor predeterminado, pero se puede configurar configurando el Coeficiente de filtro Rsrp y
Coeficiente de filtro Rsrq atributos en LteEnbRrc.

Por lo tanto, k = 0 deshabilitará el filtrado de Capa 3. Por otro lado, las mediciones pasadas pueden
se le otorgará más influencia en los resultados del filtrado usando un valor mayor de k.

Measurement la presentación de informes desencadenando
En esta parte, UE RRC revisará la lista de configuración de medición activa y
verificar si la condición de activación se cumple de acuerdo con la Sección 5.5.4 de
[TS36331]. Cuando al menos una condición de activación de todas las mediciones activas
se completa la configuración, el procedimiento de informe de medición (descrito en la siguiente
subsección) se iniciará.

3GPP define dos tipos de tipo de disparador: periódico y basado en eventos. Por el momento, solo
Se admite el criterio basado en eventos. Hay varios eventos que se pueden seleccionar, que
se describen brevemente en la siguiente tabla:

Lista of apoyadas basado en eventos desencadenando criterios
-
│Nombre │ Descripción │
┛
│Evento A1 │ La celda de servicio se vuelve mejor que │
│ │ umbral │
┛
│Evento A2 │ La celda de servicio se vuelve peor que │
│ │ umbral │
┛
│Evento A3 │ Vecino se convierte compensar dB │
│ │ mejor que servir celular │
┛
│Evento A4 │ Vecino se vuelve mejor que │
│ │ umbral │
-

│Evento A5 │ El servicio se vuelve peor que │
│ │ umbral1 Y vecino se convierte en │
│ │ mejor que umbral2 │
-

Dos condiciones principales que deben verificarse en un disparador basado en eventos son la que entran a los condición y
los dejarlo condición. Se pueden encontrar más detalles sobre estos dos en la Sección 5.5.4 de
[TS36331].

Un disparador basado en eventos se puede configurar aún más introduciendo histéresis y
tiempo de activación. Histéresis (Hys) define la distancia entre la entrada y la salida
condiciones en dB. Similarmente, tiempo de disparo introduce retraso tanto para entrar como para salir
condiciones, sino como una unidad de tiempo.

La periódico El tipo de disparador de informes no es compatible, pero su comportamiento puede ser fácilmente
obtenido mediante el uso de un activador basado en eventos. Esto se puede hacer configurando la medición
de tal manera que la condición de entrada se cumpla siempre, por ejemplo, poniendo el
umbral del Evento A1 a cero (el nivel mínimo). Como resultado, los informes de medición
siempre se activará en cada cierto intervalo, según lo determine el informeIntervalo
campo dentro LteRrcSap::ReportConfigEutra, por lo que produce el mismo comportamiento que
informes periódicos.

Como limitación con respecto a las especificaciones 3GPP, el modelo actual no soporta
cualquier configuración específica de celda. Estos parámetros de configuración se definen en la medición
objeto. Como consecuencia, incorporar una lista de celdas negras en el proceso de activación
no es apoyado. Además, el desplazamiento específico de celda (es decir, O_{cn} y O_{cp} en el evento A3, A4,
y A5) tampoco son compatibles. El valor igual a cero siempre se asume en lugar de
.

Measurement la presentación de informes
Esta parte maneja el envío del informe de medición de la entidad UE RRC al
sirviendo a la entidad eNodeB a través del protocolo RRC. Se han adoptado varios supuestos simplificadores:

· informeCantidad is No aplicable (es decir, siempre se supone que es infinito);

· en los informes de medición, el informeCantidad siempre se supone que es ¡AMBAS, es decir, ambos
RSRP y RSRQ siempre se informan, independientemente de la desencadenanteCantidad.

Entregar
El modelo RRC admite la movilidad de UE en modo CONECTADO al invocar el traspaso basado en X2
procedimiento. El modelo es intra-EUTRAN e intra-frecuencia, según lo establecido en la Sección 10.1.2.1 de
[TS36300].

Esta sección se centra en el proceso de activación de un traspaso. La ejecución del traspaso
El procedimiento en sí está cubierto en la Sección X2.

Hay dos formas de activar el procedimiento de traspaso:

· explícitamente (o manualmente) activado por el programa de simulación mediante la programación de un
ejecucion del metodo LteEnbRrc::EnviarSolicitud de transferencia, o

· automáticamente desencadenado por la entidad eNodeB RRC en función de las mediciones del UE y
según el algoritmo de traspaso seleccionado.

La sección sec-x2-based-handover de la documentación del usuario proporciona algunos ejemplos sobre el uso
activadores de traspaso explícitos y automáticos en simulación. La siguiente subsección será
echar un vistazo más de cerca al método automático, describiendo los aspectos de diseño del
interfaz de algoritmo de traspaso y los algoritmos de traspaso disponibles.

Entregar algoritmo
El traspaso en 3GPP LTE tiene las siguientes propiedades:

·

asistido por UE
El UE proporciona información a la red en forma de informes de medición. Este
es manejado por el UE RRC Medidas Modelo.

·

controlado por red
La red (es decir, el eNodoB de origen y el eNodoB de destino) decide cuándo
activa el traspaso y supervisa su ejecución.

La entregar algoritmo opera en el eNodoB de origen y es responsable de realizar el traspaso
decisiones de manera "automática". Interactúa con una instancia de eNodeB RRC a través de la
Entregar Gestionamiento SAP interfaz. Estas relaciones se ilustran en la Figura
Relación familiar entre UE medidas y Debido CONSUMIDORES de la sección anterior.

La interfaz del algoritmo de traspaso consta de los siguientes métodos:

·

AgregarUeMeasReportConfigForHandover
(Algoritmo de traspaso -> eNodeB RRC) Utilizado por el algoritmo de traspaso para solicitar
informes de medición de la entidad eNodeB RRC, pasando el deseado
configuración de informes. La configuración se aplicará a todos los futuros
UE adjuntos.

·

InformeUeMeas
(eNodeB RRC -> Algoritmo de traspaso) Basado en las medidas de UE configuradas
antes en AgregarUeMeasReportConfigForHandover, la UE puede presentar informes de medición
al eNodoB. La entidad eNodeB RRC utiliza el InformeUeMeas interfaz a
reenvía estos informes de medición al algoritmo de traspaso.

·

DisparadorEntrega
(Algoritmo de transferencia -> eNodeB RRC) Después de examinar los informes de medición
(pero no necesariamente), el algoritmo de traspaso puede declarar un traspaso. Este
se utiliza para notificar a la entidad eNodeB RRC sobre esta decisión, que
luego proceda a iniciar el procedimiento de entrega.

Una nota para el AgregarUeMeasReportConfigForHandover. El método devolverá el IdMedido
(identidad de medición) de la configuración de medición recién creada. Típicamente un
el algoritmo de traspaso almacenaría este número único. Puede ser útil en el InformeUeMeas
método, por ejemplo, cuando se ha solicitado más de una configuración y el traspaso
algoritmo necesita diferenciar los informes entrantes en función de la configuración que
los desencadenó.

Un algoritmo de traspaso se implementa escribiendo una subclase del Algoritmo de transferencia Lte
superclase abstracta e implementando cada uno de los métodos de interfaz SAP mencionados anteriormente.
Los usuarios pueden desarrollar su propio algoritmo de traspaso de esta manera y luego usarlo en cualquier simulación.
siguiendo los pasos descritos en la Sección sec-x2-based-handover of the User
Documentación.

Alternativamente, los usuarios pueden optar por utilizar uno de los 3 algoritmos de transferencia integrados proporcionados
por el módulo LTE: no-op, A2-A4-RSRQ y algoritmo de traspaso de celda más fuerte. Están
listo para ser utilizado en simulaciones o puede tomarse como un ejemplo de implementación de un traspaso
algoritmo. Cada uno de estos algoritmos incorporados se cubre en cada uno de los siguientes
subsecciones

sin operación entregar algoritmo
La sin operación entregar algoritmo (Algoritmo de transferencia NoOp clase) es lo más simple posible
implementación del algoritmo de traspaso. Básicamente no hace nada, es decir, no llama a ningún
de los métodos de interfaz SAP Handover Management. Los usuarios pueden elegir este algoritmo de traspaso
si desean deshabilitar el activador de traspaso automático en su simulación.

A2-A4-RSRQ entregar algoritmo
La A2-A4-RSRQ entregar algoritmo proporciona la funcionalidad del traspaso predeterminado
algoritmo originalmente incluido en LENA M6 (ns-3.18), portado a Handover Management SAP
interfaz como el Algoritmo de traspaso A2A4Rsrq clase.

Como su nombre lo indica, el algoritmo utiliza la calidad de señal recibida de referencia (RSRQ)
mediciones adquiridas del Evento A2 y del Evento A4. Por lo tanto, el algoritmo sumará 2
configuración de medición a la instancia de RRC de eNodeB correspondiente. Su uso previsto son
descrito de la siguiente manera:

· Eventos A2 (el RSRQ de la celda de servicio se vuelve peor que umbral) se aprovecha para indicar
que el UE está experimentando una mala calidad de señal y puede beneficiarse de un traspaso.

· Eventos A4 (El RSRQ de la celda vecina se vuelve mejor que umbral) se utiliza para detectar
celdas vecinas y adquirir su RSRQ correspondiente de cada UE adjunto, que
luego son almacenados internamente por el algoritmo. Por defecto, el algoritmo configura
Evento A4 con un umbral muy bajo, por lo que los criterios de activación siempre son verdaderos.

Figura A2-A4-RSRQ entregar algoritmo a continuación se resume este procedimiento.
[imagen] Algoritmo de traspaso A2-A4-RSRQ.UNINDENT

Se pueden establecer dos atributos para ajustar el comportamiento del algoritmo:

·

Umbral de celda de servicio
La umbral para el Evento A2, es decir, un UE debe tener un RSRQ inferior a este
umbral a considerar para un traspaso.

·

Compensación de celda vecina
La compensar que tiene como objetivo garantizar que la UE recibiría una mejor calidad de señal
después de la entrega. Una celda vecina se considera una celda objetivo para el
traspaso solo si su RSRQ es mayor que el RSRQ de la celda de servicio por la cantidad
de este compensar.

El valor de ambos atributos se expresa como rango RSRQ (Sección 9.1.7 de [TS36133]),
que es un número entero entre 0 y 34, siendo 0 el RSRQ más bajo.

Más fuerte (SCD por sus siglas en inglés), entregar algoritmo
La más fuerte (SCD por sus siglas en inglés), entregar algoritmo, o también conocido a veces como el tradicional industria
presupuesto (PBGT) algoritmo, se desarrolla utilizando [Dimou2009] como referencia. la idea es
proporcionar a cada UE la mejor potencia recibida de la señal de referencia (RSRP) posible. Esto es
hecho mediante la realización de un traspaso tan pronto como una mejor celda (es decir, con RSRP más fuerte) es
detectado.

Eventos A3 (el RSRP de la celda vecina se vuelve mejor que el RSRP de la celda de servicio) se elige para
darse cuenta de este concepto. El A3RsrpAlgoritmo de traspaso clase es el resultado de la
implementación. El traspaso se activa para el UE a la mejor celda en la medición
.

Una simulación que utiliza este algoritmo suele ser más vulnerable al traspaso de ping-pong.
(traspaso consecutivo a la fuente anterior eNodeB dentro de un corto período de tiempo),
especialmente cuando el Desvanecimiento Modelo está habilitado. Este problema es típicamente abordado por
introduciendo un cierto retraso en el traspaso. El algoritmo hace esto al incluir
parámetros de histéresis y tiempo de disparo (Sección 6.3.5 de [TS36331]) al UE
configuración de medidas.

Histéresis (también conocido como margen de transferencia) retrasa la transferencia con respecto a RSRP. el valor es
expresado en dB, oscila entre 0 y 15 dB, y tiene una precisión de 0.5 dB, por ejemplo, una entrada
el valor de 2.7 dB se redondea a 2.5 dB.

Por otra parte, tiempo de disparo retrasa el traspaso en cuanto al tiempo. 3GPP define 16
valores válidos para el tiempo de disparo (todo en milisegundos): 0, 40, 64, 80, 100, 128, 160, 256,
320, 480, 512, 640, 1024, 1280, 2560 y 5120.

La diferencia entre la histéresis y el tiempo hasta el disparo se ilustra en la Figura Efecto of
histéresis y tiempo de disparo in más fuerte (SCD por sus siglas en inglés), entregar algoritmo a continuación, que se toma
de la lena-x2-entrega-medidas ejemplo. Representa el RSRP percibido de la celda de servicio
y una celda vecina por un UE que pasa el borde de las celdas.
[imagen] Efecto de la histéresis y el tiempo de activación en el traspaso de celda más fuerte
algoritmo.UNINDENT

De forma predeterminada, el algoritmo utiliza una histéresis de 3.0 dB y un tiempo de disparo de 256 ms.
Estos valores se pueden ajustar a través del Histéresis y Tiempo para activar atributos de la
A3RsrpAlgoritmo de traspaso clase.

vecino Relación
El módulo LTE admite un simplificado Automático vecino Relación (ANR) función. Esto es
manejado por el LteAnr class, que interactúa con una instancia de eNodeB RRC a través de ANR
interfaz SAP.

vecino Relación Tabla
La ANR tiene una vecino Relación Tabla (NRT), similar a la descripción en la Sección
22.3.2a de [TS36300]. Cada entrada en la tabla se llama vecino Relación (NR) y
representa una celda vecina detectada, que contiene los siguientes campos booleanos:

·

No Eliminar
Indica que el NR deberá No ser eliminado de la NRT. Esto es su verdadero by
predeterminado para NR proporcionado por el usuario y false de otra manera.

·

No X2 Indica que el NR deberá No usar una interfaz X2 para iniciar
procedimientos hacia el eNodoB parental de la célula objetivo. Esto es false by
predeterminado para el NR proporcionado por el usuario, y su verdadero de otra manera.

·

No HO Indica que el NR deberá No ser utilizado por el eNodeB por motivos de traspaso.
Es su verdadero en la mayoría de los casos, excepto cuando el NR es proporcionado por el usuario y
detectado por la red.

Cada entrada de NR puede tener al menos una de las siguientes propiedades:

·

Proporcionado por el usuario
Este tipo de NR se crea según las instrucciones del usuario de la simulación. Por ejemplo,
un NR se crea automáticamente tras un establecimiento iniciado por el usuario de X2
conexión entre 2 eNodeBs, por ejemplo, como se describe en la Sección
traspaso basado en seg-x2. Otra forma de crear un NR proporcionado por el usuario es llamar al
AgregarRelaciónVecina función explícitamente.

·

Detectado en la red
Este tipo de NR se crea automáticamente durante la simulación como resultado de
el descubrimiento de una celda cercana.

Para crear automáticamente NR detectado por la red, ANR utiliza mediciones de UE. En
En otras palabras, ANR es un consumidor de mediciones de UE, como se muestra en la Figura Relación familiar
entre UE medidas y Debido CONSUMIDORES. RSRQ y Event A4 (el vecino se vuelve mejor)
than umbral) se utilizan para la configuración de informes. El evento predeterminado A4 umbral
se establece en el valor más bajo posible, es decir, la máxima capacidad de detección, pero se puede cambiar
configurando el Límite atributo de LteAnr clase. Tenga en cuenta que el traspaso A2-A4-RSRQ
El algoritmo también utiliza una configuración de informes similar. A pesar de la similitud, cuando
tanto ANR como este algoritmo de traspaso están activos en el eNodoB, usan informes separados
configuración.

También tenga en cuenta que no se admite la configuración automática de la interfaz X2. Esta es la razón porque
los No X2 y No HO los campos son verdaderos en un NR detectado por la red pero no detectado por el usuario.

Rol of ANR in Simulación
La interfaz ANR SAP proporciona los medios de comunicación entre ANR y eNodeB RRC. Alguno
Las funciones de interfaz son utilizadas por eNodeB RRC para interactuar con el NRT, como se muestra a continuación:

·

AgregarRelaciónVecina
(eNodeB RRC -> ANR) Agregue una nueva entrada de NR proporcionada por el usuario en la NRT.

·

ObtenerNoQuitar
(eNodeB RRC -> ANR) Obtenga el valor de No Eliminar campo de una entrada NR del
identificador de celda dado.

·

ObtenerNoHo
(eNodeB RRC -> ANR) Obtenga el valor de No HO campo de una entrada NR del dado
identificador de celda

·

ObtenerNoX2
(eNodeB RRC -> ANR) Obtenga el valor de No X2 campo de una entrada NR del dado
identificador de celda

Existen otras funciones de interfaz para respaldar el papel de ANR como consumidor de mediciones de UE,
como se indica a continuación:

·

AgregarUeMeasReportConfigForAnr
(ANR -> eNodeB RRC) Utilizado por el ANR para solicitar informes de medición del
Entidad eNodeB RRC, pasando la configuración de informes deseada. El
la configuración se aplicará a todos los UE conectados en el futuro.

·

InformeUeMeas
(eNodeB RRC -> ANR) Basado en las medidas de UE configuradas anteriormente en
AgregarUeMeasReportConfigForAnr, el UE puede enviar informes de medición al eNodoB.
La entidad eNodeB RRC utiliza el InformeUeMeas interfaz para reenviar estos
informes de medición a la ANR.

Consulte la documentación de la API correspondiente para LteAnrSap clase para más detalles
sobre el uso y los parámetros requeridos.

El ANR es utilizado por la instancia eNodeB RRC como una estructura de datos para realizar un seguimiento de la
situación de las celdas vecinas cercanas. El ANR también ayuda a la instancia de eNodeB RRC a
determinar si es posible ejecutar un procedimiento de traspaso a una celda vecina.
Esto se debe al hecho de que eNodeB RRC solo permitirá un procedimiento de traspaso a
suceder si la entrada NR de la celda objetivo tiene ambos No HO y No X2 campos establecidos en false.

ANR está habilitado de forma predeterminada en cada instancia de eNodeB en la simulación. Se puede deshabilitar
estableciendo el AnrHabilitado atributo en LteHelper clase de false.

RRC secuencia diagramas
En esta sección proporcionamos algunos diagramas de secuencia que explican los RRC más importantes
procedimientos que se modelan.

RRC conexión establecimiento
Figura Secuencia diagrama of los RRC Conexión Establishment procedimientos muestra cómo el RRC
Se modela el procedimiento de establecimiento de conexión, destacando el papel de la capa RRC en
tanto el UE como el eNB, así como la interacción con las demás capas.
[imagen] Diagrama de secuencia del procedimiento de Establecimiento de Conexión RRC.UNINDENT

Hay varios tiempos de espera relacionados con este procedimiento, que se enumeran a continuación
Tabla Temporizadores in RRC conexión establecimiento procedimientos. Si alguno de estos temporizadores expira,
el procedimiento de establecimiento de la conexión RRC finaliza con un fallo. En este caso, el
la capa superior (UE NAS) intentará inmediatamente volver a intentar el procedimiento hasta que se complete
con éxito garantizado.

Temporizadores in RRC conexión establecimiento procedimientos
- ─── ─────────────┬──────────┬──────────── ───
│Nombre │ Ubicación │ El temporizador comienza │ El temporizador se detiene │ Predeterminado │ Cuando el temporizador │
│ │ │ │ │ duración │ vencido │
┛ ─── ─────────────┼──────────┼───────────── ─
│Conexión │ eNodeB RRC │ Nuevo contexto de UE │ Recibir RRC │ 15 ms │ Eliminar UE │
│solicitud │ │ añadido │ CONEXIÓN │ │ contexto │
│tiempo de espera │ │ │ SOLICITUD │ │ │
┛ ─── ─────────────┼──────────┼───────────── ─
│Conexión │ UE RRC │ Enviar RRC │ Recibir RRC │ 100 ms │ Restablecer UE MAC │
│tiempo de espera (T300 │ │ CONEXIÓN │ CONEXIÓN │ │ │
│temporizador) │ │ SOLICITUD │ CONFIGURACIÓN o │ │ │
│ │ │ │ RECHAZAR │ │ │
┛ ─── ─────────────┼──────────┼───────────── ─
│Conexión │ eNodeB RRC │ Enviar RRC │ Recibir RRC │ 100 ms │ Eliminar UE │
│tiempo de espera de configuración │ │ CONEXIÓN │ CONEXIÓN │ │ contexto │
│ │ │ CONFIGURACIÓN │ CONFIGURACIÓN COMPLETA │ │ │
┛ ─── ─────────────┼──────────┼───────────── ─
│Conexión │ eNodeB RRC │ Enviar RRC │ Nunca │ 30 ms │ Eliminar UE │
│rechazado │ │ CONEXIÓN │ │ │ contexto │
│tiempo de espera │ │ RECHAZAR │ │ │ │
- ─── ─────────────┴──────────┴──────────── ────

RRC conexión reconfiguración
Figura Secuencia diagrama of los RRC Conexión Reconfiguracion procedimientos muestra cómo el RRC
El procedimiento de reconfiguración de la conexión se modela para el caso en que MobilityControlInfo es
no proporcionado, es decir, no se realiza el traspaso.
[imagen] Diagrama de secuencia del procedimiento de Reconfiguración de Conexión RRC.UNINDENT

Figura Secuencia diagrama of los RRC Conexión Reconfiguracion procedimientos para los entregar
case muestra cómo se modela el procedimiento de reconfiguración de la conexión RRC para el caso
donde se proporciona MobilityControlInfo, es decir, se va a realizar el traspaso. Como se especificó
en [TS36331], Después aprovecha los entregar mensaje, los UE Los intentos a de la máquina los dirigidos
(SCD por sus siglas en inglés), at los first Estar Disponible Rachel ocasión conforme a Aleatorio Acceso Recurso selección
se define in [TS36321]_, es decir, los entregar is asincrónico. En consecuencia, when asignando
a a dedicados preámbulo para los azar de la máquina in los dirigidos célula, E-UTRA deberá garantizar it is
Estar Disponible Desde los first Rachel ocasión los UE pueden utilizar. Sobre exitosos terminación of los
Entregar, los UE envía a mensaje usado a confirme los Entregar. Tenga en cuenta que el azar
El procedimiento de acceso en este caso no está basado en contiendas, por lo que en un sistema LTE real
difiere ligeramente de la utilizada en la conexión RRC establecida. También tenga en cuenta que la RA
El ID de preámbulo se señala a través del comando de traspaso incluido en la solicitud de traspaso de X2
mensaje ACK enviado desde el eNB de destino al eNB de origen; en particular, el preámbulo es
incluido en RACH-ConfigDedicated IE que forma parte de MobilityControlInfo.
[imagen] Diagrama de secuencia del procedimiento de Reconfiguración de Conexión RRC para el
caso de traspaso.UNINDENT

RRC protocolo modelos
Como se anticipó anteriormente, ofrecemos dos modelos diferentes para la transmisión y
recepción de mensajes RRC: Ideal y Historias de. Cada uno de ellos se describe en uno de los
subsecciones siguientes.

Ideal RRC protocolo modelo
Según este modelo, implementado en las clases y Protocolo LteUeRrcIdeal y
Protocolo LteEnbRrcIdeal, todos los mensajes RRC y los elementos de información se transmiten entre
el eNB y el UE de manera ideal, sin consumir recursos de radio y sin
errores Desde el punto de vista de la implementación, esto se logra pasando los datos RRC
estructura directamente entre las entidades UE y eNB RRC, sin involucrar a las capas inferiores
(PDCP, RLC, MAC, programador).

Historias de RRC protocolo modelo
Este modelo se implementa en las clases. LteUeRrcProtocoloReal y LteEnbRrcProtocoloReal
y tiene como objetivo modelar la transmisión de RRC PDU como se realiza comúnmente en LTE real
sistemas En particular:

· por cada mensaje RRC que se envía, se crea una PDU RRC real siguiendo el ASN.1
codificación de RRC PDU y elementos de información (IE) especificados en [TS36331]. Alguno
se realizan simplificaciones con respecto a los IE incluidos en la PDU, es decir, sólo aquellos
Se incluyen los IE que son útiles para fines de simulación. Para obtener una lista detallada, por favor
ver los IE definidos en lte-rrc-sap.h y compare con [TS36331].

· las PDU RRC codificadas se envían en portadores de radio de señalización y están sujetas a las mismas
modelado de transmisión utilizado para comunicaciones de datos, incluida la programación, radio
consumo de recursos, errores de canal, retrasos, retransmisiones, etc.

Señalización Radio Portador modelo
Ahora describimos el modelo de portador de radio de señalización que se utiliza para el Historias de protocolo RRC
modelo.

· SRB0 mensajes (a través de CCCH):

· Solicitud de conexión Rrc: en sistemas LTE reales, esta es una SDU RLC TM enviada
recursos especificados en UL Grant en el RAR (no en UL DCI); la razón es que
C-RNTI aún no se conoce en esta etapa. En el simulador, esto se modela como un verdadero
RLC TM RLC PDU cuyos recursos UL son asignados por la llamada programada para
SCHED_DL_RACH_INFO_REQ.

· Configuración de conexión Rrc: en el simulador esto se implementa como en los sistemas LTE reales,
es decir, con una SDU RLC TM enviada a través de los recursos indicados por una DCI UL regular,
asignado con SCHED_DL_RLC_BUFFER_REQ desencadenado por la instancia RLC TM que es
asignado a LCID 0 (el CCCH).

· SRB1 mensajes (a través de DCCH):

· Todos los mensajes SRB1 modelados en el simulador (por ejemplo, RrcConnectionCompletado) son
implementado como en los sistemas LTE reales, es decir, con una SDU de RLC real enviada a través de AM de RLC
utilizando los recursos de DL asignados a través de los informes de estado del búfer. Ver el modelo RLC
documentación para más detalles.

· SRB2 mensajes (a través de DCCH):

· Según [TS36331], "SRB1 is para RRC la vida (cual pueden incluir a
a cuestas NAS mensaje) as well as para NAS la vida antes a los establecimiento
of SRB2, todos usando DCCH lógico canal", mientras "SRB2 is para NAS mensajes,
usando DCCH lógico canal"Y"SRB2 tiene a menor prioridad than SRB1 y is
configurado by E-UTRAN después de seguridad activación". Modelado
los aspectos relacionados con la seguridad no son un requisito del modelo de simulación LTE,
por lo tanto, siempre usamos SRB1 y nunca activamos SRB2.

ASN.1 codificación of RRC IE's
Los mensajes definidos en RRC SAP, comunes a todos los Usuarios/Proveedores Ue/Enb SAP, son transportados
en un contenedor transparente hacia/desde un Ue/Enb. El formato de codificación para los diferentes
Los elementos de información se especifican en [TS36331], utilizando las reglas ASN.1 en el formato no alineado.
variante. La implementación en Ns3/Lte se ha dividido en las siguientes clases:

· Asn1Header: contiene la codificación/descodificación de tipos básicos de ASN

· RrcAsn1Header: Hereda Asn1Header y contiene la codificación/descodificación de común
IE definidos en [TS36331]

· Mensajes específicos de Rrc/clases de IE: una clase para cada uno de los mensajes definidos en RRC
Encabezado SAP

Asn1Encabezado clase - Implementación of bases ASN.1 tipos
Esta clase implementa los métodos para serializar/deserializar los tipos ASN.1 que se utilizan en
[TS36331], de acuerdo con las reglas de codificación empaquetada en ITU-T X.691. Los tipos considerados
son:

· Booleano: un valor booleano utiliza un solo bit (1=verdadero, 0=falso).

· Entero: un entero restringido (con valores mínimos y máximos definidos) utiliza el mínimo
cantidad de bits para codificar su rango (max-min+1).

· Bitstring: un bistring se copiará bit a bit en el búfer de serialización.

· Cadena de octetos: no se utiliza actualmente.

· Secuencia: la secuencia genera un preámbulo que indica la presencia de opcionales y
campos predeterminados. También agrega un bit que indica la presencia del marcador de extensión.

· Secuencia...De: la secuencia...de tipo codifica el número de elementos de la secuencia
como un número entero (los elementos posteriores deberán codificarse después).

· Elección: indica qué elemento de entre los del conjunto de elección se está codificando.

· Enumeración: se serializa como un número entero indicando qué valor se utiliza, entre los
unos en la enumeración, con el número de elementos en la enumeración como superior
Unido.

· Nulo: no se codifica el valor nulo, aunque se define su función de serialización
para proporcionar un mapa más claro entre la especificación y la implementación.

La clase hereda del encabezado ns-3, pero la función Deserialize() se declara puramente virtual,
por lo tanto, las clases heredadas tienen que implementarlo. La razón es que la deserialización
recuperar los elementos en los mensajes RRC, cada uno de ellos contiene información diferente
elementos.

Además, debe tenerse en cuenta que la longitud de bytes resultante de un tipo/mensaje específico
puede variar, según la presencia de campos opcionales, y debido a la codificación optimizada.
Por lo tanto, los bits serializados se procesarán utilizando la función PreSerialize(), guardando el
resultado en m_serializationResult Buffer. Como los métodos para leer/escribir en un búfer ns3 son
definido en bytes, los bits de serialización se almacenan en m_serializationPendingBits
atributo, hasta que se establezcan los 8 bits y se puedan escribir en el iterador de búfer. Finalmente, cuando
al invocar a Serialize(), se copiará el contenido del atributo m_serializationResult
al parámetro Buffer::Iterator

RrcAsn1Encabezado : Sus Preguntas IE
Como algunos elementos de información se utilizan para varios mensajes RRC, esta clase
implementa los siguientes IE comunes:

· SrbToAddModList

· DrbToAddModList

· Configuración del canal lógico

· RadioResourceConfigDedicado

· Configuración física dedicada

· Tipo de bloque de información del sistema 1

· Tipo de bloque de información del sistema 2

· RadioResourceConfigCommonSIB

rrc soluciones y mensajes/IE privadas
Se han implementado los siguientes RRC SAP:

· Solicitud de conexión Rrc

· Configuración de conexión Rrc

· RrcConnectionSetupCompletado

· Reconfiguración de Conexión Rrc

· RrcConnectionReconfigurationCompletada

· Información sobre la preparación de la entrega

· Solicitud de restablecimiento de conexión Rrc

· RrcConexiónRestablecimiento

· RrcConexiónReestablecimientoCompletado

· RrcConexiónReestablecimientoRechazo

· Lanzamiento de conexión Rrc

NAS
El enfoque del modelo LTE-EPC está en el estado NAS activo, que corresponde a EMM
Registrado, ECM conectado y RRC conectado. Debido a esto, el siguiente
se hacen simplificaciones:

· EMM y ECM no se modelan explícitamente; en su lugar, la entidad NAS en el UE
interactuar directamente con el MME para realizar acciones equivalentes (con
simplificaciones) hasta llevar el UE a los estados EMM Conectado y ECM Conectado;

· el NAS también se encarga de multiplexar los paquetes de datos de enlace ascendente provenientes de la parte superior
capas en el portador EPS adecuado utilizando el clasificador de plantilla de flujo de tráfico
(Clasificador Tft).

· el NAS no es compatible con la selección de PLMN y CSG

· el NAS no admite ningún procedimiento de localización/actualización de ubicación en modo inactivo

Figura Secuencia diagrama of los adjuntar procedimientos muestra cómo el modelo NAS simplificado
implementa el procedimiento de conexión. Tenga en cuenta que tanto el EPS dedicado predeterminado como el eventual
los portadores se activan como parte de este procedimiento.
[imagen] Diagrama de secuencia del procedimiento de adjuntar.UNINDENT

S1
S1-T
La interfaz S1-U se modela de manera realista al encapsular paquetes de datos a través de
GTP/UDP/IP, como se hace en sistemas LTE-EPC reales. La pila de protocolo correspondiente se muestra en
Figura LTE-EPC datos avión protocolo montón. Como se muestra en la figura, hay dos diferentes
capas de redes IP. La primera es la capa de extremo a extremo, que proporciona de extremo a extremo
conectividad a los usuarios; esta capa involucra a los UE, el PGW y el host remoto
(incluidos eventuales enrutadores de Internet y hosts intermedios), pero no involucra al eNB.
De manera predeterminada, a los UE se les asigna una dirección IPv4 pública en la red 7.0.0.0/8 y el PGW
obtiene la dirección 7.0.0.1, que todos los UE utilizan como puerta de enlace para acceder a Internet.

La segunda capa de redes IP es la red de área local EPC. Esto involucra a todos los eNB
nodos y el nodo SGW/PGW. Esta red se implementa como un conjunto de enlaces punto a punto
que conectan cada eNB con el nodo SGW/PGW; por lo tanto, el SGW/PGW tiene un conjunto de
dispositivos punto a punto, cada uno proporcionando conectividad a un eNB diferente. Por defecto, un
La subred 10.xyz/30 se asigna a cada enlace punto a punto (una subred /30 es la más pequeña
subred que permite dos direcciones de host distintas).

Según lo especificado por 3GPP, las comunicaciones IP de extremo a extremo se canalizan a través de la IP EPC local.
red usando GTP/UDP/IP. A continuación, explicamos cómo se implementa este túnel.
en el modelo EPC. La explicación se realiza discutiendo el flujo de datos de extremo a extremo.
paquetes.
[imagen] Flujo de datos en el enlace descendente entre internet y la UE.UNINDENT

Para empezar, consideramos el caso del enlace descendente, que se muestra en la Figura Data
de tus señales in los enlace descendente entre los Internet y los UE. Los paquetes Ipv4 de enlace descendente son
generado desde un host remoto genérico y dirigido a uno de los dispositivos UE. Internet
el enrutamiento se encargará de reenviar el paquete al NetDevice genérico del SGW/PGW
nodo que está conectado a Internet (esta es la interfaz Gi según 3GPP
terminología). El SGW/PGW tiene un VirtualNetDevice al que se le asigna la IP de la puerta de enlace
dirección de la subred del UE; por lo tanto, las reglas de enrutamiento estático harán que el paquete entrante
desde Internet para ser enrutado a través de este VirtualNetDevice. Dicho dispositivo inicia el
Procedimiento de tunelización GTP/UDP/IP, reenviando el paquete a una aplicación dedicada en
el nodo SGW/PGW que se llama EpcSgwPgwApplication. Esta aplicación hace el
siguientes operaciones:

1. determina el nodo eNB al que está conectado el UE, mirando la IP
dirección de destino (que es la dirección del UE);

2. clasifica el paquete utilizando Plantillas de flujo de tráfico (TFT) para identificar a qué
EPS Portador al que pertenece. Los portadores EPS tienen un mapeo uno a uno con los portadores S1-U, por lo que
esta operación devuelve el identificador de punto final de túnel GTP-U (TEID) al que
pertenece el paquete;

3. agrega el encabezado del protocolo GTP-U correspondiente al paquete;

4. finalmente, envía el paquete a través de un socket UDP al S1-U punto a punto
NetDevice, dirigido al eNB al que está conectado el UE.

Como consecuencia, el paquete IP de extremo a extremo con encabezados IP, UDP y GTP recién agregados es
enviado a través de uno de los enlaces S1 al eNB, donde se recibe y entrega localmente
(ya que la dirección de destino del encabezado IP más externo coincide con la dirección IP del eNB). El
proceso de entrega local reenviará el paquete, a través de un socket UDP, a un dedicado
aplicación llamada EpcEnbApplication. Esta aplicación luego realiza lo siguiente
operaciones:

1. elimina el encabezado GTP y recupera el TEID que contiene;

2. aprovechando el mapeo uno a uno entre los portadores S1-U y los portadores de radio (que
es un requisito de 3GPP), determina el ID de portador (BID) al que se envía el paquete.
pertenece;

3. registra el BID en una etiqueta dedicada llamada EpsBearerTag, que se agrega al
paquete;

4. reenvía el paquete al LteEnbNetDevice del nodo eNB a través de un paquete sin formato
enchufe

Tenga en cuenta que, en este punto, el encabezado más externo del paquete es el encabezado IP de extremo a extremo,
ya que los encabezados IP/UDP/GTP de la pila de protocolos S1 ya se han eliminado. Al
recepción del paquete de EpcEnbApplication, LteEnbNetDevice recuperará el
BID de EpsBearerTag, y en función del BID determinará la instancia de portador de radio
(y las instancias de protocolo PDCP y RLC correspondientes) que luego se utilizan para reenviar el
paquete al UE a través de la interfaz de radio LTE. Finalmente, el LteUeNetDevice del UE
recibir el paquete y entregarlo localmente a la pila de protocolo IP, que a su vez
entregarlo a la aplicación del UE, que es el punto final del enlace descendente
comunicación.
[imagen] Flujo de datos en el enlace ascendente entre la UE e internet.UNINDENT

El caso del enlace ascendente se muestra en la Figura Data de tus señales in los enlace ascendente entre los UE y
los Internet. Los paquetes IP de enlace ascendente son generados por una aplicación genérica dentro del UE,
y reenviado por la pila TCP/IP local al LteUeNetDevice del UE. El
LteUeNetDevice luego realiza las siguientes operaciones:

1. clasifica el paquete usando TFTs y determina la Radio Bearer a la cual el
pertenece el paquete (y el RBID correspondiente);

2. identifica la instancia del protocolo PDCP correspondiente, que es el punto de entrada de
la pila de protocolo de radio LTE para este paquete;

3. envía el paquete al eNB a través de la pila de protocolo de radio LTE.

El eNB recibe el paquete a través de su LteEnbNetDevice. Dado que hay un solo PDCP y RLC
instancia de protocolo para cada portador de radio, el LteEnbNetDevice puede determinar el BID
del paquete Este BID luego se registra en un EpsBearerTag, que se agrega al
paquete. LteEnbNetDevice luego reenvía el paquete a EpcEnbApplication a través de un raw
zócalo del paquete.

Al recibir el paquete, EpcEnbApplication realiza las siguientes operaciones:

1. recupera el BID del EpsBearerTag en el paquete;

2. determina la instancia de portador de EPS correspondiente y GTP-U TEID aprovechando
el mapeo uno a uno entre portadores S1-U y portadores de radio;

3. agrega un encabezado GTP-U en el paquete, incluyendo el TEID determinado previamente;

4. envía el paquete al nodo SGW/PGW a través del socket UDP conectado al S1-U
Dispositivo de red punto a punto.

En este punto, el paquete contiene los encabezados S1-U IP, UDP y GTP además del
Encabezado IP de extremo a extremo original. Cuando el paquete es recibido por el S1-U correspondiente
NetDevice punto a punto del nodo SGW/PGW, se entrega localmente (como destino
dirección del encabezado IP más externo coincide con la dirección del dispositivo de red punto a punto).
El proceso de entrega local reenviará el paquete a EpcSgwPgwApplication a través del
socket UDP correspondiente. EpcSgwPgwApplication luego elimina el encabezado GTP y reenvía
el paquete al VirtualNetDevice. En este punto, el encabezado más externo del paquete es el
Encabezado IP de extremo a extremo. Por lo tanto, si la dirección de destino dentro de este encabezado es un remoto
host en Internet, el paquete se envía a Internet a través del NetDevice correspondiente
de la SGW/PGW. En el caso de que el paquete se dirija a otro UE, la pila IP de
el SGW/PGW redirigirá el paquete nuevamente al VirtualNetDevice, y el paquete irá
a través del proceso de entrega de enlace descendente para llegar a su UE de destino.

Tenga en cuenta que EPS Bearer QoS no se aplica en los enlaces S1-U, se supone que el
el sobreaprovisionamiento del ancho de banda del enlace es suficiente para cumplir con los requisitos de QoS de todos
portadores

S1AP
La interfaz S1-AP proporciona una interacción del plano de control entre el eNB y el MME. En el
simulador, esta interfaz está modelada de manera ideal, con interacción directa entre
los objetos eNB y MME, sin implementar realmente la codificación de los mensajes S1AP
y elementos de información especificados en [TS36413] y sin transmitir realmente ninguna PDU
en cualquier enlace.

Las primitivas S1-AP que se modelan son:

· MENSAJE UE INICIAL

· SOLICITUD DE CONFIGURACIÓN DE CONTEXTO INICIAL

· RESPUESTA DE CONFIGURACIÓN DEL CONTEXTO INICIAL

· SOLICITUD DE CAMBIO DE RUTA

· RECONOCIMIENTO DE SOLICITUD DE CAMBIO DE RUTA

X2
La interfaz X2 interconecta dos eNB [TS36420]. Desde un punto de vista lógico, el X2
La interfaz es una interfaz punto a punto entre los dos eNB. En una E-UTRAN real, el
La interfaz lógica punto a punto debe ser factible incluso en ausencia de una interfaz física.
conexión directa entre los dos eNB. En el modelo X2 implementado en el simulador, la
La interfaz X2 es un enlace punto a punto entre los dos eNB. Un dispositivo punto a punto es
creados en ambos eNB y los dos dispositivos punto a punto están conectados al punto a punto
.

Para una representación de cómo encaja la interfaz X2 en la arquitectura general de LENA
modelo de simulación, se remite al lector a la figura Descripción General of los LTE-EPC simulación
modelo.

La interfaz X2 implementada en el simulador proporciona una implementación detallada de la
siguientes procedimientos elementales de la funcionalidad de gestión de movilidad [TS36423]:

· Procedimiento de solicitud de traspaso

· Procedimiento de acuse de recibo de solicitud de traspaso

· Procedimiento de transferencia de estado de SN

· Procedimiento de Liberación de Contexto UE

Estos procedimientos están involucrados en el traspaso basado en X2. Puedes encontrar el detallado
descripción del traspaso en la sección 10.1.2.1 de [TS36300]. Notemos que el simulador
Actualmente, el modelo solo admite el sin costura entregar como se define en la Sección 2.6.3.1 de
[Sesia2009]; En particular, sin pérdidas entregar como se describe en la Sección 2.6.3.2 de
[Sesia2009] no es compatible en el momento de escribir este artículo.

Figura Secuencia diagrama of los basado en X2 entregar A continuación se muestra la interacción de los
entidades del modelo X2 en el simulador. Las etiquetas sombreadas indican los momentos en que el
Transición de UE o eNodeB a otro estado RRC.
[imagen] Diagrama de secuencia del traspaso basado en X2.UNINDENT

La figura también muestra dos temporizadores dentro del procedimiento de traspaso: el entregar dejarlo
minutero es mantenido por el eNodoB de origen, mientras que el entregar unión minutero por el objetivo
eNodoB. La duración de los temporizadores se puede configurar en el
EntregaSalirTiempo de esperaDuración y EntregaUnirseTiempo de esperaDuración atributos de la
aquellos LteEnbRrc instancias. Cuando uno de estos temporizadores expira, el procedimiento de traspaso
se considera fallida.

Sin embargo, no hay un manejo adecuado de la falla de traspaso en la versión actual de LTE
módulo. Los usuarios deben ajustar la simulación correctamente para evitar fallas en el traspaso,
de lo contrario, puede ocurrir un comportamiento inesperado. Consulte la Sección
sec-tuning-handover-simulation de la documentación del usuario para obtener algunos consejos al respecto
cuestión.

El modelo X2 es una entidad que utiliza servicios de:

· las interfaces X2,

· Se implementan como Sockets encima de los dispositivos punto a punto.

· Se utilizan para enviar/recibir mensajes X2 a través de las interfaces X2-C y X2-U
(es decir, el dispositivo punto a punto adjunto al enlace punto a punto) hacia el
eNB de pares.

· la aplicación S1.

· Actualmente, es EpcEnbApplication.

· Se utiliza para obtener alguna información necesaria para los Procedimientos Elementales del X2
mensajes.

y presta servicios a:

· la entidad RRC (X2 SAP)

· para enviar/recibir mensajes RRC. La entidad X2 envía el mensaje RRC como un mensaje transparente
contenedor en el mensaje X2. Este mensaje RRC se envía al UE.

Figura Implementación Modelo of X2 entidad y SAP muestra el modelo de implementación del X2
entidad y su relación con todas las demás entidades y servicios en el protocolo
asociación.
[imagen] Modelo de Implementación de entidad X2 y SAPs.UNINDENT

La entidad RRC gestiona el inicio del procedimiento de traspaso. Esto se hace en el
Submódulo Handover Management de la entidad eNB RRC. El eNB de destino puede realizar algunas
Procedimientos de Control de Admisión. Esto se hace en el submódulo de Control de Admisión.
Inicialmente, este submódulo aceptará cualquier solicitud de traspaso.

X2 las interfaces
El modelo X2 contiene dos interfaces:

· la interfaz X2-C. Es la interfaz de control y se utiliza para enviar las PDU X2-AP
(es decir, los procedimientos elementales).

· la interfaz X2-U. Se utiliza para enviar los datos del portador cuando hay DL transmisión de.

Figura X2 interfaz. protocolo pilas muestra las pilas de protocolos de la interfaz X2-U y
Interfaz X2-C modelada en el simulador.
[imagen] Pilas de protocolo de interfaz X2.UNINDENT

X2-C
La interfaz X2-C es la parte de control de la interfaz X2 y se utiliza para enviar el
PDU X2-AP (es decir, los procedimientos elementales).

En la pila de protocolos del plano de control de la interfaz X2 original, SCTP se usa como el transporte
protocolo pero actualmente, el protocolo SCTP no está modelado en el simulador ns-3 y su
La implementación está fuera del alcance del proyecto. El protocolo UDP se utiliza como datagrama.
protocolo orientado en lugar del protocolo SCTP.

X2-T
La interfaz X2-U se utiliza para enviar los datos del portador cuando hay DL transmisión de durante el
ejecución del procedimiento de traspaso basado en X2. De manera similar a lo que se hizo para el S1-U
interfaz, los paquetes de datos se encapsulan a través de GTP/UDP/IP cuando se envían a través de este
interfaz. Tenga en cuenta que EPS Bearer QoS no se aplica en los enlaces X2-U, se supone
que el sobreaprovisionamiento del ancho de banda del enlace es suficiente para cumplir con los requisitos de QoS
de todos los portadores.

X2 Servicio Fácil de usar
La interfaz de servicio X2 es utilizada por la entidad RRC para enviar y recibir mensajes del X2
procedimientos. Se divide en dos partes:

· los Proveedor EpcX2Sap parte es proporcionada por la entidad X2 y utilizada por la entidad RRC y

· los UsuarioEpcX2Sap parte es proporcionada por la entidad RRC y utilizada por la entidad RRC.

Las primitivas que son compatibles con nuestro modelo X2-C se describen a continuación
subsecciones

X2-C primitivas para entregar ejecución
Las siguientes primitivas se utilizan para el traspaso basado en X2:

· SOLICITUD DE ENTREGA

· ACUSE DE SOLICITUD DE ENTREGA

· FALLA EN LA PREPARACIÓN DEL TRASPASO

· TRANSFERENCIA DE ESTADO DE SN

· LIBERACIÓN DE CONTEXTO UE

todas las primitivas anteriores son utilizadas por el modelo RRC implementado actualmente durante el
preparación y ejecución del procedimiento de traspaso. Su uso interactúa con el RRC
máquina estatal; por lo tanto, no están destinados a ser utilizados para la personalización del código, al menos
a menos que se desee modificar la máquina de estados RRC.

X2-C HIJO primitivas
Las siguientes primitivas se pueden usar para implementar una red autoorganizada (SON)
funcionalidades:

· CARGAR INFORMACIÓN

· ACTUALIZACIÓN DEL ESTADO DE LOS RECURSOS

tenga en cuenta que el modelo RRC actual en realidad no usa estas primitivas, están incluidas
en el modelo solo para hacer posible el desarrollo de algoritmos SON incluidos en la lógica RRC
que hacen uso de ellos.

Como primer ejemplo, mostramos aquí cómo se puede usar la primitiva de información de carga. Asumimos
que el LteEnbRrc se ha modificado para incluir las siguientes variables miembro nuevas:

estándar::vector
m_currentUlInterferenceOverloadIndicationList;
estándar::vector
m_currentUlHighInterferenceInformationList;
EpcX2Sap::RelativeNarrowbandTxBand m_currentRelativeNarrowbandTxBand;

para una descripción detallada del tipo de estas variables, sugerimos consultar el archivo
epc-x2-sap.h, la correspondiente documentación de doxygen, y las referencias que contiene al
secciones relevantes de 3GPP TS 36.423. Ahora, suponga que en tiempo de ejecución estas variables tienen
sido ajustado a valores significativos siguiendo las especificaciones que se acaban de mencionar. Entonces tú puedes
agregue el siguiente código en la implementación de la clase LteEnbRrc para enviar una carga
información primitiva:

EpcX2Sap::CellInformationItem cii;
cii.sourceCellId = m_cellId;
cii.ulInterferenceOverloadIndicationList = m_currentUlInterferenceOverloadIndicationList;
cii.ulHighInterferenceInformationList = m_currentUlHighInterferenceInformationList;
cii.relativeNarrowbandTxBand = m_currentRelativeNarrowbandTxBand;

EpcX2Sap::LoadInformationParams parámetros;
params.targetCellId = cellId;
params.cellInformationList.push_back (cii);
m_x2SapProvider->SendLoadInformation (parámetros);

El código anterior permite que el eNB de origen envíe el mensaje. El método
LteEnbRrc::DoRecvLoadInformación se llamará cuando el eNB de destino reciba el mensaje.
Por lo tanto, el procesamiento deseado de la información de carga debe implementarse dentro de ese
método.

En el siguiente segundo ejemplo, mostramos cómo se utiliza la primitiva de actualización de estado de recursos.
Suponemos que LteEnbRrc se ha modificado para incluir el siguiente miembro nuevo
variable:

EpcX2Sap::CellMeasurementResultItem m_cmri;

Al igual que antes, nos referimos a epc-x2-sap.h y las referencias que contiene para obtener información detallada.
información sobre este tipo de variable. Nuevamente, asumimos que la variable ya ha sido
establecido en un valor significativo. Luego, puede agregar el siguiente código para enviar un
actualización de estado de recursos:

EpcX2Sap::ResourceStatusUpdateParams parámetros;
params.targetCellId = cellId;
params.cellMeasurementResultList.push_back (m_cmri);
m_x2SapProvider->SendResourceStatusUpdate (parámetros);

El método eEnbRrc::DoRecvResourceStatusUpdate se llamará cuando el eNB de destino reciba
el mensaje de actualización del estado del recurso. El procesamiento deseado de este mensaje debe
por lo tanto, implementarse dentro de ese método.

Finalmente, notamos que la fijación y procesamiento de los valores apropiados para la
la variable pasada a las primitivas descritas anteriormente se considera específica del SON
algoritmo que se está implementando y, por lo tanto, no está cubierto por esta documentación.

No compatible primitivas
Primitivas de optimización de robustez de movilidad, como indicación de falla de enlace de radio y
El informe de traspaso no se admite en esta etapa.

S11
La interfaz S11 proporciona una interacción del plano de control entre el SGW y el MME utilizando el
Protocolo GTPv2-C especificado en [TS29274]. En el simulador, esta interfaz se modela en un
moda ideal, con interacción directa entre el SGW y los objetos MME, sin
implementando realmente la codificación de los mensajes y sin transmitir realmente ningún
PDU en cualquier enlace.

Las primitivas S11 que se modelan son:

· CREAR SOLICITUD DE SESIÓN

· CREAR RESPUESTA DE SESIÓN

· SOLICITUD DE MODIFICACIÓN DE PORTADOR

· MODIFICAR LA RESPUESTA DEL PORTADOR

De estas primitivas, las dos primeras se utilizan en la conexión inicial del UE para el
establecimiento de los portadores S1-U; los otros dos se utilizan durante el traspaso para cambiar el
portadores S1-U del eNB de origen al eNB de destino como consecuencia de la recepción por
el MME de un mensaje SOLICITUD DE CAMBIO DE RUTA S1-AP.

Potencia Control:
Esta sección describe la implementación de ns-3 del control de potencia de enlace descendente y enlace ascendente.

Enlace descendente Potencia Control:
Dado que algunos algoritmos de reutilización de frecuencia requieren control de potencia de enlace descendente, esta característica fue
también implementado en ns-3.
[imagen] Diagrama de secuencia de Downlink Power Control.UNINDENT

Figura Secuencia diagrama of Enlace descendente Potencia Control: muestra el diagrama de secuencia del ajuste
valor P_A de enlace descendente para UE, destacando las interacciones entre el RRC y el otro
entidades. El algoritmo FR activa RRC para cambiar los valores de P_A para UE. Entonces comienza RRC
Función RrcConnectionReconfiguration para informar al UE sobre la nueva configuración. Después
RrcConnectionReconfiguration exitosa, RRC puede establecer el valor P_A para UE llamando
función SetPa de CphySap, el valor se guarda en el nuevo mapa m_paMap que contiene valores P_A
para cada UE atendido por eNb.

Cuando LteEnbPhy inicia una nueva subtrama, los mensajes de control DCI se procesan para obtener el vector de
RB usados. Ahora también se incluye la función GeneratePowerAllocationMap(uint16_t rnti, int rbId)
llamado. Esta función verifica el valor P_A para UE, genera energía para cada RB y la almacena en
m_dlPowerAllocationMap. Entonces este mapa es usado por
Función CreateTxPowerSpectralDensityWithPowerAllocation para crear Ptr
txPsd.

PdschConfigDedicated (TS 36.331, 6.3.2 PDSCH-Config) se agregó en
Estructura LteRrcSap::PhysicalConfigDedicated, que se utiliza en RrcConnectionReconfiguration
.

Uplink Potencia Control:
El control de potencia del enlace ascendente controla la potencia de transmisión de los diferentes enlaces físicos del enlace ascendente.
canales Esta funcionalidad se describe en 3GPP TS 36.213 sección 5.

Uplink Power Control está habilitado de forma predeterminada y se puede deshabilitar mediante un sistema de atributos:

Config::SetDefault ("ns3::LteUePhy::EnableUplinkPowerControl", BooleanValue (falso));

Se implementan dos mecanismos de control de potencia de enlace ascendente:

· Control de potencia de enlace ascendente de bucle abierto: la potencia de transmisión del UE depende de la estimación de
la pérdida de ruta del enlace descendente y la configuración del canal

· Control de potencia de enlace ascendente de bucle cerrado: como en bucle abierto, además eNB puede controlar el UE
potencia de transmisión por medio de comandos TPC de control de potencia de transmisión explícitos
transmitido en el enlace descendente.

Para cambiar entre estos dos tipos de mecanismos, se debe cambiar el parámetro:

Config::SetDefault ("ns3::LteUePowerControl::ClosedLoop", BooleanValue (verdadero));

De forma predeterminada, el control de potencia de bucle cerrado está habilitado.

Two los modos of Cerrado Red ISTE Loop Uplink Potencia Control: están tamaños:

· Modo absoluto: TxPower se calcula con valores absolutos de TPC

· Modo acumulativo: TxPower se calcula con valores TPC acumulados

Para cambiar entre estos dos modos, uno debe cambiar el parámetro:

Config::SetDefault ("ns3::LteUePowerControl::AccumulationEnabled", BooleanValue (verdadero));

De manera predeterminada, el modo de acumulación está habilitado y los comandos TPC en DL-DCI son configurados por todos.
programadores a 1, lo que se asigna al valor de 0 en el modo de acumulación.

Uplink Potencia Control: para EMPUJAR
La configuración de la potencia de transmisión del UE para un canal compartido de enlace ascendente físico (PUSCH)
transmisión se define de la siguiente manera:

· Si el UE transmite PUSCH sin un PUCCH simultáneo para la celda servidora c, entonces
la potencia de transmisión del UE P_{PUSCH,c}(i) para la transmisión PUSCH en la subtrama i para el
sirviendo a la celda c viene dada por:

· Si el UE transmite PUSCH simultáneamente con PUCCH para la celda de servicio c, entonces el UE
potencia de transmisión P_{PUSCH,c}(i) para la transmisión PUSCH en la subtrama i para la
sirviendo a la celda c viene dada por:

Dado que Uplink Power Control para PUCCH no está implementado, este caso no está implementado
.

· Si el UE no está transmitiendo PUSCH para la celda servidora c, para la acumulación de
Comando TPC recibido con formato DCI 3/3A para PUSCH, el UE asumirá que el UE
potencia de transmisión P_{PUSCH,c}(i) para la transmisión PUSCH en la subtrama i para la
la celda de servicio c se calcula mediante

dónde:

· P_{CMAX,c}(i) es la potencia de transmisión del UE configurada definida en 3GPP 36.101. Mesa
6.2.2-1 en la subtrama i para dar servicio a la celda c y {P}_{CMAX,c}(i) es el valor lineal
de P_{CMAX,c}(i). El valor predeterminado para P_{CMAX,c}(i) es 23 dBm

· M_{PUSCH,c}(i) es el ancho de banda de la asignación del recurso PUSCH expresado en
número de bloques de recursos válidos para la subtrama i y la celda de servicio c.

· P_{O_PUSCH,c}(j) es un parámetro compuesto por la suma de un componente
P_{O_NOMINAL_PUSCH,c}(j) proporcionado desde capas superiores para j={0,1} y un componente
P_{O_UE_PUSCH,c}(j) proporcionado por capas superiores para j={0,1} para servir a la celda c.
El mensaje SIB2 debe ampliarse para llevar estos dos componentes, pero actualmente
se pueden configurar a través del sistema de atributos:

Config::SetDefault ("ns3::LteUePowerControl::PoNominalPusch", IntegerValue (-90));
Config::SetDefault ("ns3::LteUePowerControl::PoUePusch", IntegerValue (7));

· lpha_{c} (j) es un parámetro de 3 bits proporcionado por capas superiores para ightinForelj=2,
Para j=0,1, lpha_c en t 0, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1
lpha_{c} (j) = 1. Este parámetro es configurable por sistema de atributos:

Config::SetDefault ("ns3::LteUePowerControl::Alpha", DoubleValue (0.8));

· PL_{c} es la estimación de pérdida de ruta de enlace descendente calculada en el UE para dar servicio a la celda c
en dB y PL_{c} = referenceSignalPower – RSRP filtrado de capa superior, donde
referenceSignalPower es proporcionado por capas superiores y RSRP. referenciaSeñalPotencia
se proporciona en el mensaje SIB2

· y se implementa el segundo caso.

· f_{c}(i) es un componente del control de potencia de circuito cerrado. Es la potencia PUSCH actual
estado de ajuste de control para la celda de servicio c.

Si el modo de acumulación está habilitado, f_{c}(i) viene dado por:

donde: elta_{PUSCH,c} es un valor de corrección, también conocido como comando TPC
y está incluido en PDCCH con DCI; elta_{PUSCH,c}(i - K_{PUSCH}) fue señalado el
PDCCH/EPDCCH con DCI para dar servicio a la celda c en la subtrama (i - K_{PUSCH}); K_{PUSCH} =
4 para FDD.

Si UE ha alcanzado P_{CMAX,c}(i) para dar servicio a la celda c, los comandos TPC positivos para
sirviendo a la celda c no se pueden acumular. Si UE ha alcanzado la potencia mínima, negativo
Los comandos TPC no se acumulan. La potencia mínima del UE se define en TS36.101
apartado 6.2.3. El valor predeterminado es -40 dBm.

Si el modo de acumulación no está habilitado, f_{c}(i) viene dado por:

donde: elta_{PUSCH,c} es un valor de corrección, también conocido como comando TPC
y está incluido en PDCCH con DCI; elta_{PUSCH,c}(i - K_{PUSCH}) fue señalado el
PDCCH/EPDCCH con DCI para dar servicio a la celda c en la subtrama (i - K_{PUSCH}); K_{PUSCH} =
4 para FDD.

Mapeo del campo de comando TPC en formato DCI 0/3/4 a absoluto y acumulado
los valores elta_{PUSCH,c} se definen en TS36.231 sección 5.1.1.1 Tabla 5.1.1.1-2

Uplink Potencia Control: para PUCCH
Dado que todos los mensajes de control de enlace ascendente son mensajes ideales y no consumen ninguna radio
recursos, Uplink Power Control para PUCCH no es necesario y no está implementado.

Uplink Potencia Control: para SRS
El ajuste de la potencia de transmisión del UE P_{SRS} para el SRS transmitido en la subtrama i para
la celda de servicio c está definida por

dónde:

· P_{CMAX,c}(i) es la potencia de transmisión del UE configurada definida en 3GPP 36.101. Mesa
6.2.2-1. El valor predeterminado para P_{CMAX,c}(i) es 23 dBm

· P_{SRS_OFFSET,c}(m) está semiestáticamente configurado por capas superiores para m=0,1 para
celda de servicio c. Para transmisión SRS dado el tipo de disparador 0 entonces m=0,1 y para SRS
transmisión dado tipo de disparador 1 entonces m=1. Para K_{s} = 0 P_Srs_Offset_Value es
calculado con la ecuación:

Este parámetro es configurable por sistema de atributos:

Config::SetDefault ("ns3::LteUePowerControl::PsrsOffset", IntegerValue (7));

· M_{SRS,c} es el ancho de banda de la transmisión SRS en la subtrama i para la celda de servicio
c expresado en número de bloques de recursos. En la implementación actual se envía SRS
en todo el ancho de banda de UL.

· f_{c}(i) es el estado actual de ajuste del control de potencia PUSCH para la celda de servicio c,
como se define en Uplink Potencia Control: para EMPUJAR

· P_{O_PUSCH,c}(j) y lpha_{c}(j) son parámetros definidos en Uplink Potencia
Control: para EMPUJAR, donde j = 1 .

Fraccionario Frecuencia Reutilizar
Descripción General
En esta sección, se describe la compatibilidad de ns-3 con los algoritmos de reutilización de frecuencia fraccional. Todo
los algoritmos implementados se describen en [ASHamza2013]. Actualmente hay 7 algoritmos FR
implementado:

· ns3::LteFrNoOpAlgoritmo

· ns3::LteFrHardAlgoritmo

· ns3::LteFrStrictAlgoritmo

· ns3::LteFrSoftAlgoritmo

· ns3::LteFfrSoftAlgoritmo

· ns3::LteFfrAlgoritmo mejorado

· ns3::LteFfrDistributedAlgoritmo

Se creó la nueva clase LteFfrAlgorithm y es una clase abstracta para la reutilización de frecuencia
implementación de algoritmos. Además, se agregaron dos nuevos SAP entre FR-Scheduler y FR-RRC.
[imagen] Diagrama de secuencia de Scheduling con algoritmo FR.UNINDENT

Figura Secuencia diagrama of Programación con FR algoritmo muestra el diagrama de secuencia de
proceso de programación con algoritmo FR. Al comienzo del proceso de programación, el programador
pregunta a la entidad FR por los RBG disponibles. Según la implementación, FR devuelve todos los RBG.
disponibles en la celda o filtrarlos según su política. Luego, al tratar de asignar algunos
RBG a UE, el planificador pregunta a la entidad FR si este RBG está permitido para este UE. Cuando FR vuelve
cierto, el programador puede asignar este RBG a este UE, si no, el programador está verificando otro RBG
para este UE. Nuevamente, la respuesta de FR depende de la implementación y la política aplicada a UE.

Soportado FR algoritmos
No Frecuencia Reutilizar
El algoritmo NoOp FR (clase LteFrNoOpAlgorithm) es una implementación de Full Frequency Reuse
esquema, eso significa que no se realiza partición de frecuencia entre eNB de la misma red
(factor de reutilización de frecuencia, FRF es igual a 1). Los eNB utilizan todo el ancho de banda del sistema y transmiten
con poder uniforme sobre todos los RBG. Es el esquema más simple y es la forma básica de
operar una red LTE. Este esquema permite lograr la tasa de datos máxima alta. Pero
por otro lado, debido a los fuertes niveles de interferencia de las celdas vecinas, el borde de la celda
el rendimiento de los usuarios es muy limitado.

Figura Full Frecuencia Reutilizar esquema a continuación se presenta el plan de frecuencia y energía para Full
Esquema de reutilización de frecuencias.
[imagen] Esquema de reutilización de frecuencia completa.UNINDENT

En ns-3, el algoritmo NoOp FR siempre permite que el programador use el ancho de banda completo y permite
todos los UE para usar cualquier RBG. Simplemente no hace nada nuevo (es decir, no limita eNB
ancho de banda, el algoritmo FR está deshabilitado), es la implementación más simple de FrAlgorithm
class y está instalado en eNb por defecto.

Difícil Frecuencia Reutilizar
El algoritmo Hard Frequency Reuse proporciona el esquema más simple que permite reducir
nivel de interferencia entre celdas. En este esquema, todo el ancho de banda de frecuencia se divide en
pocas (típicamente 3, 4 o 7) subbandas separadas. Los eNB adyacentes se asignan con diferentes
sub-banda. El factor de reutilización de frecuencia es igual al número de subbandas. Este esquema permite
reduce significativamente el ICI en el borde de la celda, por lo que se mejora el rendimiento de los usuarios de la celda.
Pero debido al hecho de que cada eNB usa solo una parte del ancho de banda total, la velocidad máxima de datos
el nivel también se reduce por el factor igual al factor de reutilización.

Figura Difícil Frecuencia Reutilizar esquema a continuación se presenta la frecuencia y el plan de energía para Hard
Esquema de reutilización de frecuencias.
[imagen] Esquema de reutilización de frecuencia dura.UNINDENT

En nuestra implementación, el algoritmo Hard FR solo tiene un vector de RBG disponible para eNB
y páselo al Programador MAC durante las funciones de programación. Cuando el programador pregunta, si RBG es
permitido para UE específico, siempre devuelve verdadero.

Estricto Frecuencia Reutilizar
El esquema de reutilización estricta de frecuencia es una combinación de esquemas de reutilización de frecuencia completa y estricta. Él
consiste en dividir el ancho de banda del sistema en dos partes las cuales tendrán diferentes
reutilización de frecuencias. En el interior de cada celda se utiliza una subbanda común del ancho de banda del sistema.
(reutilización de frecuencia-1), mientras que la otra parte del ancho de banda se divide entre los
eNB vecinos como en la reutilización de frecuencia dura (reutilización de frecuencia-N, N>1), para crear
una subbanda con un bajo nivel de interferencia entre células en cada sector. Los UE centrales serán
concedidos con fragmentos de frecuencia totalmente reutilizados, mientras que los UE de borde de celda con fragmentos ortogonales.
Significa que los UE interiores de una celda no comparten ningún espectro con los UE de borde de
segunda celda, lo que reduce la interferencia para ambas. Como se puede observar, Strict FR requiere una
total de N+1 subbandas, y permite conseguir RFR en el medio entre 1 y 3.

Figura Estricto Frecuencia Reutilizar esquema A continuación se presenta el plan de frecuencia y energía para Strict.
Esquema de reutilización de frecuencia con un factor de reutilización del borde de la celda de N = 3.
[imagen] Esquema estricto de reutilización de frecuencia.UNINDENT

En nuestra implementación, el algoritmo Strict FR tiene dos mapas, uno para cada subbanda. Si UE
se puede servir dentro de la subbanda privada, su RNTI se agrega al mapa m_privateSubBandUe. Si
El UE puede recibir servicio dentro de una subbanda común; su RNTI se agrega al mapa m_commonSubBandUe.
Un algoritmo FR estricto debe decidir dentro de qué subbanda UE debe servirse. Usa
mediciones UE proporcionadas por RRB y compararlas con el umbral de calidad de la señal (este
El parámetro se puede ajustar fácilmente mediante un mecanismo de atributo). El umbral influye en
Relación entre el radio interior y el radio de la celda.

Soft Frecuencia Reutilizar
En el esquema de reutilización de frecuencia suave (SFR), cada eNb transmite a través de todo el ancho de banda del sistema,
pero hay dos subbandas, dentro de los UE se sirven con diferentes niveles de potencia. Desde
Los UE del centro de celda comparten el ancho de banda con celdas vecinas, generalmente transmiten a velocidades más bajas.
nivel de potencia que los UE de borde de celda. SFR es más eficiente en ancho de banda que Strict FR,
porque utiliza todo el ancho de banda del sistema, pero también genera más interferencias para ambos
usuarios del interior y del borde de la celda.

Hay dos versiones posibles del esquema SFR:

· En la primera versión, la subbanda dedicada a los UE de borde celular también puede ser utilizada por
los UE del centro celular pero con un nivel de potencia reducido y solo si no está ocupado por
los UE de borde de celda. La subbanda del centro celular está disponible únicamente para los UE centrales. Cifra
Soft Frecuencia Reutilizar esquema versión 1 A continuación se presenta el plan de frecuencia y energía para
esta versión del esquema de reutilización de frecuencia suave.
[imagen] Esquema de reutilización de frecuencia suave versión 1.UNINDENT

· En la segunda versión, los UE del centro celular no tienen acceso a la subbanda del borde celular. En
De esta manera, cada celda puede utilizar todo el ancho de banda del sistema y al mismo tiempo reducir el
Interferencias con las celdas vecinas. Por otro lado, un nivel más bajo de ICI en el
El borde de la celda se logra a expensas de una menor utilización del espectro. Cifra Soft
Frecuencia Reutilizar esquema versión 2 A continuación se presenta el plan de frecuencia y energía para este
versión del esquema de reutilización de frecuencia suave.
[imagen] Esquema de reutilización de frecuencia suave versión 2.UNINDENT

El algoritmo SFR mantiene dos mapas. Si el UE debe ser servido con un nivel de potencia más bajo, su
RNTI se agrega al mapa m_lowPowerSubBandUe. Si la UE debería servirse con mayor potencia
nivel, su RNTI se agrega al mapa m_highPowerSubBandUe. Para decidir con qué nivel de potencia
Se debe servir al UE. El algoritmo SFR utiliza mediciones del UE y las compara con
límite. Umbral de calidad de señal y PdschConfigDedicated (es decir, valor P_A) para interior
y el área exterior se puede configurar mediante el sistema de atributos. SFR utiliza energía de enlace descendente
Control descrito aquí.

Soft Fraccionario Frecuencia Reutilizar
La reutilización de frecuencia fraccional suave (SFFR) es una combinación de frecuencia estricta y suave.
Esquemas de reutilización. Si bien Strict FR no utiliza las subbandas asignadas para la región exterior en el
celdas adyacentes, la FFR suave utiliza estas subbandas para los UE internos con baja potencia de transmisión. Como
Como resultado, el SFFR, al igual que el SFR, utiliza la subbanda con un alto nivel de potencia de transmisión y con baja
transmitir el nivel de potencia. A diferencia del Soft FR y del Strict FR, el Soft FFR utiliza el estándar
subbanda que puede mejorar el rendimiento de los usuarios internos.

Figura Soft Fraccionario Fraccionario Frecuencia Reutilizar esquema A continuación se presenta la frecuencia y
plan de energía para la reutilización suave de frecuencia fraccionaria.
[imagen] Esquema de reutilización de frecuencia fraccional fraccional suave.UNINDENT

Modernizado Fraccionario Frecuencia Reutilizar
La reutilización de frecuencia fraccional mejorada (EFFR) descrita en [ZXie2009] define 3 tipos de células
para células directamente vecinas en un sistema celular, y reserva para cada tipo de célula una
parte de toda la banda de frecuencia denominada Primaria Segmento, que entre diferentes tipos de células
debe ser ortogonal. Los subcanales restantes constituyen el el folleto de Secundaria Segmento.
Primaria Segmento de un tipo celular es al mismo tiempo parte del el folleto de Secundaria Segmentos
pertenecientes a los otros dos tipos de células. Cada célula puede ocupar todos los subcanales de su Primaria
Segmento a voluntad, mientras que sólo una parte de los subcanales en el el folleto de Secundaria Segmento utilizar
por esta célula de manera consciente de la interferencia. Primaria Segmento de cada celda se divide
en una parte de reutilización-3 y una parte de reutilización-1. La parte reuse-1 puede ser reutilizada por todo tipo de células.
en el sistema, mientras que la parte reuse-3 solo puede ser reutilizada exclusivamente por otros del mismo tipo
células (es decir, los subcanales de reutilización-3 no pueden ser reutilizados por células directamente vecinas). En
los el folleto de Secundaria Segmento La célula actúa como invitada y ocupar subcanales secundarios es
en realidad reutilizar los subcanales primarios que pertenecen a las células directamente vecinas, por lo tanto
reutilizar en el el folleto de Secundaria Segmento por cada celda debe ajustarse a dos reglas:

· monitorear antes de usar

· reutilización de recursos basada en la estimación SINR

Cada celda escucha en cada subcanal secundario todo el tiempo. Y antes de la ocupación,
realiza una evaluación SINR de acuerdo con la información de calidad del canal (CQI) recopilada y
elige los recursos con los mejores valores de estimación para su reutilización. Si el valor de CQI para RBG es superior
umbral configurado para algún usuario, la transmisión para este usuario se puede realizar usando este
RBG.

En [ZXie2009] se describe el proceso de programación, que consta de tres pasos y dos
políticas de programación. Dado que ninguno de los programadores implementados actualmente permite esto
comportamiento, se aplicó cierta simplificación. En nuestra implementación, los subcanales reuse-1 pueden
ser utilizado únicamente por usuarios del centro celular. Los usuarios perimetrales pueden utilizar los subcanales Reuse-3, y solo
si no hay ningún usuario de borde, la transmisión para los usuarios del centro celular se puede realizar en reutilización-3
subcanales.

Figura Modernizado Fraccionario Fraccionario Frecuencia Reutilizar esquema A continuación se presenta la frecuencia y
plan de energía para la reutilización mejorada de frecuencia fraccionaria.
[imagen] Esquema de reutilización de frecuencia fraccional mejorada.UNINDENT

Distributed Fraccionario Frecuencia Reutilizar
Este algoritmo de reutilización de frecuencia fraccional distribuida se presentó en [DKimura2012]. Él
optimiza automáticamente las subbandas del borde de la celda centrándose en la distribución de usuarios (en
en particular, distribución de potencia de recepción). Este algoritmo selecciona adaptativamente RB para
subbanda del borde de la celda sobre la base de la información de coordinación de las celdas adyacentes y notifica
las estaciones base de las celdas adyacentes, qué RB seleccionó para usar en la subbanda de borde.
La estación base de cada celda utiliza la información recibida y la siguiente ecuación para
calcular la métrica de banda de borde de celda A_k para cada RB.

donde J es un conjunto de celdas vecinas, X_{j,k}=0,1 es el RNTP de la j-ésima celda vecina.
Toma un valor de 1 cuando el k-ésimo RB en la j-ésima celda vecina se usa como borde de celda
subbanda y 0 en caso contrario. El símbolo w_{j} denota peso con respecto a la celda adyacente j,
es decir, el número de usuarios para los cuales la diferencia entre la potencia de la señal
recibida de la celda de servicio i y la potencia de la señal recibida de la celda adyacente
La celda j es menor que un valor umbral (es decir, el número de usuarios cerca del borde de la celda en el
celular de servicio). Una gran diferencia de potencia recibida significa que los usuarios del borde celular en el i-ésimo
La célula sufre una fuerte interferencia de la j-ésima célula.

El RB para el cual la métrica A_{k} es más pequeña se considera el menos afectado por
interferencia de otra célula. La celda de servicio selecciona un número configurado de RB como
subbanda del borde de la celda en orden ascendente de A_{k}. Como resultado, los OR en los que una pequeña
El número de usuarios del borde celular recibe alta interferencia de estaciones base adyacentes.
seleccionado.

Luego, el RNTP actualizado se envía a todas las celdas vecinas. Para evitar lo sin sentido
oscilación de la selección de banda de borde de celda, una estación base ignora un RNTP de otra base
estación que tiene un ID de celda mayor que la estación base.

Repetir este proceso en todas las celdas permite la asignación de RB a las áreas del borde de la celda
optimizarse en el sistema y ajustarse con los cambios en la distribución de usuarios.

Figura Secuencia diagrama of Distributed Frecuencia Reutilizar Esquema a continuación se presenta la secuencia
diagrama del esquema de reutilización de frecuencia fraccionada distribuida.
[imagen] Diagrama de secuencia del esquema de reutilización de frecuencia distribuida.UNINDENT

Ayudantes
Se utilizan dos objetos auxiliares para configurar simulaciones y configurar los distintos componentes.
Estos objetos son:

· LteHelper, que se encarga de la configuración de la red de acceso radio LTE, así como
así como de coordinar la constitución y liberación de los portadores de EPS. El LteHelper clase
proporciona tanto la definición de API como su implementación.

· EpcHelper, que se encarga de la configuración del Evolved Packet Core. El
EpcHelper class es una clase base abstracta que solo proporciona la definición de API; el
La implementación se delega a clases secundarias para permitir diferentes EPC.
modelos de red.

Es posible crear simulaciones simples de solo LTE utilizando LteHelper solo o para
cree simulaciones LTE-EPC completas utilizando ambos LteHelper y EpcHelper. Cuando ambos
Se utilizan ayudantes, estos interactúan en forma amo-esclavo, con LteHelper siendo el maestro
que interactúa directamente con el programa de usuario, y EpcHelper trabajando "bajo el capó" para
configurar el EPC mediante métodos explícitos llamados por LteHelper. Las interacciones exactas son
mostrado en la figura Secuencia diagrama of los interacción entre LteHelper y
EpcHelper.
[imagen] Diagrama de secuencia de la interacción entre LteHelper y EpcHelper.UNINDENT

User Documentación
Antecedentes
Suponemos que el lector ya está familiarizado con cómo utilizar el simulador ns-3 para ejecutar programas genéricos.
programas de simulación. Si este no es el caso, recomendamos encarecidamente al lector que consulte
[ns3tutorial].

Uso Descripción General
El modelo ns-3 LTE es una biblioteca de software que permite la simulación de redes LTE,
incluyendo opcionalmente el Evolved Packet Core (EPC). El proceso de realizar tales
Las simulaciones normalmente implican los siguientes pasos:

1. Definición los guión ser simulado

2. Escribe. a simulación programa que recrea el escenario deseado
topología/arquitectura. Esto se hace accediendo a la biblioteca de modelos ns-3 LTE usando el
ns3::LteHelper API definida en src/lte/helper/lte-helper.h.

3. Especificar configuración parámetros de los objetos que se utilizan para el
simulación. Esto se puede hacer usando archivos de entrada (a través del ns3::ConfigStore) o
directamente dentro del programa de simulación.

4. Configurar los deseado salida a ser producido por el simulador

5. Ejecutar la simulación.

Todos estos aspectos se explicarán en los siguientes apartados mediante prácticas
ejemplos.

Básico simulación programa
Aquí está el programa de simulación mínimo que se necesita para realizar una simulación solo LTE
(sin EPC).

1. Texto estándar inicial:

#incluir
#incluir
#incluir
#incluir

usando el espacio de nombres ns3;

int principal (int argc, char *argv[])
{
// el resto del programa de simulación sigue

2. Crear un LteHelper :

Ptr lteHelper = CrearObjeto ();

Esto creará una instancia de algunos objetos comunes (por ejemplo, el objeto Canal) y proporcionará la
Métodos para agregar eNB y UE y configurarlos.

3. Crear Nodo Objetos para los eNB y los UE:

NodoContenedor enbNodes;
enbNodes.Create (1);
NodoContenedor ueNodes;
ueNodes.Crear (2);

Tenga en cuenta que las instancias de Nodo anteriores en este momento todavía no tienen un protocolo LTE
pila instalada; son sólo nodos vacíos.

4. Configure el modelo de Movilidad para todos los nodos:

MobilityHelper movilidad;
movilidad.SetMobilityModel ("ns3 :: ConstantPositionMobilityModel");
movilidad.Instalar (enbNodes);
movilidad.SetMobilityModel ("ns3 :: ConstantPositionMobilityModel");
movilidad.Instalar (ueNodes);

Lo anterior colocará todos los nodos en las coordenadas (0,0,0). por favor refiérase a
documentación del modelo de movilidad ns-3 sobre cómo establecer su propia posición o configurar
movimiento de nodos.

5. Instale una pila de protocolo LTE en los eNB:

NetDeviceContainer enbDevs;
enbDevs = lteHelper->InstallEnbDevice (enbNodes);

6. Instale una pila de protocolo LTE en los UE:

NetDeviceContainer ueDevs;
ueDevs = lteHelper->InstallUeDevice (ueNodes);

7. Conecte los UE a un eNB. Esto configurará cada UE según el eNB
configuración y crear una conexión RRC entre ellos:

lteHelper->Adjuntar (ueDevs, enbDevs.Get (0));

8. Activar un portador de radio de datos entre cada UE y el eNB al que está conectado:

enum EpsBearer::Qci q = EpsBearer::GBR_CONV_VOICE;
portador EpsBearer (q);
lteHelper->ActivateDataRadioBearer (ueDevs, portador);

Este método también activará dos generadores de tráfico de saturación para ese portador, uno
en enlace ascendente y otro en enlace descendente.

9. Configure la hora de parada:

Simulador::Detener (Segundos (0.005));

Esto es necesario, de lo contrario la simulación durará para siempre, porque (entre otras cosas) el
El evento de inicio de subtrama se programa repetidamente y el programador del simulador ns-3
por lo tanto, nunca te quedes sin eventos.

10. Ejecute la simulación:

Simulador::Ejecutar ();

11. Limpieza y salida:

Simulador::Destruir ();
0 regresar;
}

Para saber cómo compilar y ejecutar programas de simulación, consulte [ns3tutorial].

Configuration of LTE modelo parámetros
Todos los parámetros relevantes del modelo LTE se gestionan a través del sistema de atributos ns-3.
Consulte el [ns3tutorial] y el [ns3manual] para obtener información detallada sobre todos los
posibles métodos para hacerlo (variables ambientales, API C++, GtkConfigStore...).

A continuación, resumimos brevemente cómo hacerlo usando archivos de entrada junto con
el ConfigStore de ns-3. En primer lugar, debes poner lo siguiente en tu simulación.
programa, justo después principal () empieza:

Línea de comando cmd;
cmd. Parse (argc, argv);
ConfigStore inputConfig;
inputConfig.ConfigureDefaults();
// analiza nuevamente para poder anular los valores predeterminados desde la línea de comando
cmd. Parse (argc, argv);

Para que lo anterior funcione, asegúrese de también #incluir "ns3/config-store.h". Ahora crea un
archivo de texto llamado (por ejemplo) valores predeterminados de entrada.txt especificando los nuevos valores predeterminados que
desea utilizar para algunos atributos:

predeterminado ns3::LteHelper::Scheduler "ns3::PfFfMacScheduler"
predeterminado ns3::LteHelper::PathlossModel "ns3::FriisSpectrumPropagationLossModel"
predeterminado ns3::LteEnbNetDevice::UlBandwidth "25"
predeterminado ns3::LteEnbNetDevice::DlBandwidth "25"
predeterminado ns3::LteEnbNetDevice::DlEarfcn "100"
ns3 predeterminado::LteEnbNetDevice::UlEarfcn "18100"
predeterminado ns3::LteUePhy::TxPower "10"
predeterminado ns3::LteUePhy::NoiseFigure "9"
ns3 predeterminado::LteEnbPhy::TxPower "30"
predeterminado ns3::LteEnbPhy::NoiseFigure "5"

Suponiendo que su programa de simulación se llame src/lte/examples/lte-sim-con-entrada, puede
Ahora pase estos ajustes al programa de simulación de la siguiente manera:

./waf --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Load --ns3::ConfigStore::FileFormat=RawText" --ejecute src/lte/examples/lte-sim-with-input

Además, puede generar un archivo de entrada de plantilla con el siguiente comando:

./waf --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Guardar --ns3::ConfigStore::FileFormat=RawText" --ejecute src/lte/examples/lte-sim-with-input

tenga en cuenta que lo anterior se colocará en el archivo valores predeterminados de entrada.txt todos los valores predeterminados que
están registrados en su versión particular del simulador, incluidos muchos no LTE
los atributos.

Configurar LTE dirección MAC Scheduler
Hay varios tipos de programador LTE MAC que el usuario puede elegir aquí. El usuario puede utilizar lo siguiente
códigos para definir el tipo de planificador:

Ptr lteHelper = CrearObjeto ();
lteHelper->SetSchedulerType ("ns3::FdMtFfMacScheduler"); // programador FD-MT
lteHelper->SetSchedulerType ("ns3::TdMtFfMacScheduler"); // programador TD-MT
lteHelper->SetSchedulerType ("ns3::TtaFfMacScheduler"); // programador TTA
lteHelper->SetSchedulerType ("ns3::FdBetFfMacScheduler"); // programador FD-BET
lteHelper->SetSchedulerType ("ns3::TdBetFfMacScheduler"); // Programador TD-BET
lteHelper->SetSchedulerType ("ns3::FdTbfqFfMacScheduler"); // programador FD-TBFQ
lteHelper->SetSchedulerType ("ns3::TdTbfqFfMacScheduler"); // programador TD-TBFQ
lteHelper->SetSchedulerType ("ns3::PssFfMacScheduler"); //Programador PSS

TBFQ y PSS tienen más parámetros que otros programadores. Los usuarios pueden definir esos parámetros.
de la siguiente manera:

* Programador TBFQ::

Ptr lteHelper = CrearObjeto ();
lteHelper->SetSchedulerAttribute("DebtLimit", IntegerValue(suvalor)); // valor predeterminado -625000 bytes (-5Mb)
lteHelper->SetSchedulerAttribute("CreditLimit", UintegerValue(suvalor)); // valor predeterminado 625000 bytes (5Mb)
lteHelper->SetSchedulerAttribute("TokenPoolSize", UintegerValue(suvalor)); // valor predeterminado 1 byte
lteHelper->SetSchedulerAttribute("CreditableThreshold", UintegerValue(suvalor)); // valor predeterminado 0

* Programador PSS::

Ptr lteHelper = CrearObjeto ();
lteHelper->SetSchedulerAttribute("nMux", UIntegerValue(suvalor)); // el número máximo de UE seleccionados por el planificador TD
lteHelper->SetSchedulerAttribute("PssFdSchedulerType", StringValue("CoItA")); // tipo de programador PF en PSS

En TBFQ, los valores predeterminados de límite de deuda y límite de crédito se establecen en -5 Mb y 5 Mb.
respectivamente basado en el artículo [FABokhari2009]. La implementación actual no considera
umbral de crédito (C = 0). En PSS, si el usuario no define nMux, PSS establecerá este valor en
la mitad del total de la UE. El programador FD predeterminado es PFsch.

Además, la tasa de generación de tokens en TBFQ y la tasa de bits objetivo en PSS deben ser
configurado por la tasa de bits garantizada (GBR) o la tasa de bits máxima (MBR) en la QoS del portador epc
parámetros. Los usuarios pueden utilizar los siguientes códigos para definir GBR y MBR tanto en enlace descendente como
enlace ascendente:

Ptr lteHelper = CrearObjeto ();
enum EpsBearer::Qci q = EpsBearer::tuvalor; // define el tipo de Qci
GbrQosInformación qos;
qos.gbrDl = su valor; // enlace descendente GBR
qos.gbrUl = su valor; // enlace ascendente GBR
qos.mbrDl = su valor; // MBR de enlace descendente
qos.mbrUl = su valor; // MBR de enlace ascendente
portador EpsBearer (q, qos);
lteHelper->ActivateDedicatedEpsBearer (ueDevs, portador, EpcTft::Default ());

En PSS, TBR se obtiene de GBR en parámetros QoS a nivel de portador. En TBFQ, generación de tokens
La velocidad se obtiene de la configuración del MBR en los parámetros QoS a nivel de portador, lo que por lo tanto
debe configurarse de forma coherente. Para tráfico de velocidad de bits constante (CBR), se sugiere
para configurar MBR en GBR. Para el tráfico de velocidad de bits de variación (VBR), se sugiere configurar MBR k veces
mayor que GBR para cubrir la tasa de tráfico pico. En la implementación actual, k es
establecido en tres según el papel [FABokhari2009]. Además, la versión actual de TBFQ no
considere la longitud del encabezado RLC y del encabezado PDCP en MBR y GBR. Otro parámetro en TBFQ es
tasa de llegada de paquetes. Este parámetro se calcula dentro del planificador y es igual al pasado.
rendimiento promedio que se utiliza en el programador PF.

Muchos atributos útiles del modelo LTE-EPC se describirán a continuación.
subsecciones. Aún así, hay muchos atributos que no se mencionan explícitamente en el
diseño o documentación de usuario, pero que están claramente documentados utilizando el atributo ns-3
sistema. Puede imprimir fácilmente una lista de los atributos de un objeto determinado junto con
su descripción y valor predeterminado pasando --ImprimirAtributos= a un programa de simulación,
Me gusta esto:

./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteHelper"

Puedes probar también con otros objetos LTE y EPC, como este:

./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteEnbNetDevice"
./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteEnbMac"
./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteEnbPhy"
./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteUePhy"
./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::PointToPointEpcHelper"

Simulación Salida
El modelo ns-3 LTE actualmente admite la salida a archivos de nivel PHY, MAC, RLC y PDCP.
Indicadores clave de rendimiento (KPI). Puedes habilitarlo de la siguiente manera:

Ptr lteHelper = CrearObjeto ();

// configura todo el escenario de simulación aquí...

lteHelper->EnablePhyTraces ();
lteHelper->EnableMacTraces ();
lteHelper->EnableRlcTraces ();
lteHelper->EnablePdcpTraces ();

Simulador::Ejecutar ();

Los KPI de RLC y PDCP se calculan durante un intervalo de tiempo y se almacenan en archivos ASCII, dos para
KPI de RLC y dos para KPI de PDCP, en cada caso uno para enlace ascendente y otro para enlace descendente. El tiempo
La duración del intervalo se puede controlar utilizando el atributo.
ns3::RadioBearerStatsCalculator::EpochDuration.

Las columnas de los archivos RLC KPI son las siguientes (las mismas para el enlace ascendente y el enlace descendente):

1. hora de inicio del intervalo de medición en segundos desde el inicio de la simulación

2. hora de finalización del intervalo de medición en segundos desde el inicio de la simulación

3. Identificación de celda

4. ID de UE única (IMSI)

5. ID de UE específico de la celda (RNTI)

6. ID de canal lógico

7. Número de PDU RLC transmitidas

8. Total de bytes transmitidos.

9. Número de PDU RLC recibidas

10. Total de bytes recibidos

11. Retraso promedio de la PDU RLC en segundos

12. Desviación estándar del retardo de la PDU del RLC

13. Valor mínimo del retardo de la PDU del RLC

14. Valor máximo del retardo de la PDU del RLC

15. Tamaño promedio de PDU RLC, en bytes

16. Desviación estándar del tamaño de la PDU RLC

17. Tamaño mínimo de PDU RLC

18. Tamaño máximo de PDU RLC

De manera similar, las columnas de los archivos PDCP KPI son las siguientes (nuevamente, lo mismo para el enlace ascendente
y enlace descendente):

1. hora de inicio del intervalo de medición en segundos desde el inicio de la simulación

2. hora de finalización del intervalo de medición en segundos desde el inicio de la simulación

3. Identificación de celda

4. ID de UE única (IMSI)

5. ID de UE específico de la celda (RNTI)

6. ID de canal lógico

7. Número de PDU PDCP transmitidas

8. Total de bytes transmitidos.

9. Número de PDU PDCP recibidas

10. Total de bytes recibidos

11. Retraso promedio de PDCP PDU en segundos

12. Desviación estándar del retraso de PDCP PDU

13. Valor mínimo del retardo de PDCP PDU

14. Valor máximo del retraso de PDCP PDU

15. Tamaño promedio de PDU PDCP, en bytes

16. Desviación estándar del tamaño de la PDU PDCP

17. Tamaño mínimo de PDU PDCP

18. Tamaño máximo de PDU PDCP

Los KPI MAC son básicamente un rastro de la asignación de recursos reportada por el planificador al
el inicio de cada subtrama. Se almacenan en archivos ASCII. Para los KPI MAC de enlace descendente, el
el formato es el siguiente:

1. Tiempo de simulación en segundos en el que el planificador indica la asignación

2. Identificación de celda

3. ID de UE única (IMSI)

4. Número de cuadro

5. Número de subtrama

6. ID de UE específico de la celda (RNTI)

7. SQM de TB 1

8. tamaño de la tuberculosis 1

9. MCS de TB 2 (0 si no está presente)

10. tamaño de TB 2 (0 si no está presente)

mientras que para los KPI MAC de enlace ascendente el formato es:

1. Tiempo de simulación en segundos en el que el planificador indica la asignación

2. Identificación de celda

3. ID de UE única (IMSI)

4. Número de cuadro

5. Número de subtrama

6. ID de UE específico de la celda (RNTI)

7. SQM de la tuberculosis

8. tamaño de la tuberculosis

Los nombres de los archivos utilizados para la salida MAC KPI se pueden personalizar mediante los atributos ns-3
ns3::MacStatsCalculator::DlOutputFilename y ns3::MacStatsCalculator::UlOutputFilename.

Los KPI de PHY se distribuyen en siete archivos diferentes, configurables a través de los atributos

1. ns3::PhyStatsCalculator::DlRsrpSinrNombre de archivo

2. ns3::PhyStatsCalculator::UeSinrFilename

3. ns3::PhyStatsCalculator::InterferenciaNombre de archivo

4. ns3::PhyStatsCalculator::DlTxOutputFilename

5. ns3::PhyStatsCalculator::UlTxOutputFilename

6. ns3::PhyStatsCalculator::DlRxOutputFilename

7. ns3::PhyStatsCalculator::UlRxOutputFilename

En el archivo RSRP/SINR, está disponible el siguiente contenido:

1. Tiempo de simulación en segundos en el que el planificador indica la asignación

2. Identificación de celda

3. ID de UE única (IMSI)

4. RSRP

5. Promedio lineal de todos los RB del SINR de enlace descendente en unidades lineales

El contenido del archivo UE SINR es:

1. Tiempo de simulación en segundos en el que el planificador indica la asignación

2. Identificación de celda

3. ID de UE única (IMSI)

4. SINR de enlace ascendente en unidades lineales para el UE

En el nombre del archivo de interferencia el contenido es:

1. Tiempo de simulación en segundos en el que el planificador indica la asignación

2. Identificación de celda

3. Lista de valores de interferencia por RB

En los archivos de transmisión UL y DL los parámetros incluidos son:

1. Tiempo de simulación en milisegundos

2. Identificación de celda

3. ID de UE única (IMSI)

4. RNTI

5. Capa de transmisión

6. SCM

7. tamaño de la tuberculosis

8. Versión de redundancia

9. Nueva bandera de indicador de datos

Y por último, en ficheros de recepción UL y DL los parámetros incluidos son:

1. Tiempo de simulación en milisegundos

2. Identificación de celda

3. ID de UE única (IMSI)

4. RNTI

5. Modo de transmisión

6. Capa de transmisión

7. SCM

8. tamaño de la tuberculosis

9. Versión de redundancia

10. Nueva bandera de indicador de datos

11. Corrección en la recepción del TB.

Desvanecimiento Trace Uso
En esta sección describiremos cómo utilizar trazas de desvanecimiento dentro de simulaciones LTE.

Desvanecimiento Las huellas Generation
Es posible generar rastros de desvanecimiento utilizando un script de Matlab dedicado proporcionado con
el código (/lte/model/fading-traces/fading-trace-generator.m). Este script ya incluye
las configuraciones típicas de grifos para tres escenarios 3GPP (es decir, peatones, vehiculares y
urbano tal como se define en el Anexo B.2 de [TS36104]); sin embargo los usuarios también pueden introducir sus
configuraciones específicas. La lista de parámetros configurables se proporciona en la
siguientes:

· fc : la frecuencia en uso (afecta el cálculo de la velocidad Doppler).

· v_km_h : la velocidad de los usuarios

· trazaDuración : la duración en segundos de la longitud total del seguimiento.

· númeroRB : el número del bloque de recursos a evaluar.

· etiqueta : la etiqueta que se aplicará al archivo generado.

El archivo generado contiene valores reales en formato ASCII organizados en forma matricial:
cada fila corresponde a un RB diferente, y cada columna corresponde a un RB diferente
muestra de rastro de desvanecimiento temporal.

Cabe señalar que el módulo ns-3 LTE puede funcionar con cualquier archivo de seguimiento que se desvanezca.
que cumpla con el formato ASCII descrito anteriormente. Por lo tanto, se pueden utilizar otras herramientas externas.
Se utiliza para generar trazas de desvanecimiento personalizadas, como por ejemplo otros simuladores o
dispositivos experimentales.

Desvanecimiento Las huellas Uso
Cuando se utiliza una traza de desvanecimiento, es de suma importancia especificar correctamente la traza.
parámetros en la simulación, para que el modelo de desvanecimiento pueda cargarlo y usarlo correctamente. El
Los parámetros a configurar son:

· Nombre de archivo de seguimiento : el nombre de la traza que se va a cargar (ruta absoluta o ruta relativa)
escriba la ruta desde donde se ejecuta el programa de simulación);

· Longitud de seguimiento : la duración del seguimiento en segundos;

· Número de muestras : el número de muestras;

· Tamaño de ventana : el tamaño de la ventana de muestreo de desvanecimiento en segundos;

Es importante resaltar que el intervalo de muestreo de la traza de desvanecimiento debe ser de 1 ms.
o mayor, y en el último caso tiene que ser un múltiplo entero de 1 ms para poder ser
procesado correctamente por el módulo de desvanecimiento.

La configuración predeterminada del script matlab proporciona un seguimiento de 10 segundos de duración, hecho de
10,000 muestras (es decir, 1 muestra por TTI = 1 ms) y se utiliza con un tamaño de ventana de 0.5 segundos
amplitud. Estos también son los valores predeterminados de los parámetros anteriores utilizados en el
simulador; por lo tanto se puede evitar su colocación en caso de que la huella de desvanecimiento los respete.

Para activar el módulo de desvanecimiento (que no está activo por defecto) el siguiente código
Debe incluirse en el programa de simulación:

Ptr lteHelper = CrearObjeto ();
lteHelper->SetFadingModel("ns3::TraceFadingLossModel");

Y para configurar los parámetros:

lteHelper->SetFadingModelAttribute ("TraceFilename", StringValue ("src/lte/model/fading-traces/fading_trace_EPA_3kmph.fad"));
lteHelper->SetFadingModelAttribute ("TraceLength", TimeValue (Segundos (10.0)));
lteHelper->SetFadingModelAttribute ("SamplesNum", UintegerValue (10000));
lteHelper->SetFadingModelAttribute ("Tamaño de ventana", Valor de tiempo (segundos (0.5)));
lteHelper->SetFadingModelAttribute ("RbNum", UintegerValue (100));

Cabe señalar que, Nombre de archivo de seguimiento no tiene un valor predeterminado, por lo tanto tiene que
siempre debe establecerse explícitamente.

El simulador proporciona de forma nativa tres trazas de desvanecimiento generadas según el
configuraciones definidas en el Anexo B.2 de [TS36104]. Estos rastros están disponibles en el
carpeta src/lte/model/fading-traces/). Un extracto de estas huellas está representado en el
siguientes figuras.
[imagen: rastro de desvanecimiento 3 kmph] [imagen] Extracto del rastro de desvanecimiento incluido en el
simulador para un escenario peatonal (velocidad de 3 kmph)..UNINDENT
[imagen: rastro de desvanecimiento 60 kmph] [imagen] Extracto del rastro de desvanecimiento incluido en el
simulador para un escenario vehicular (velocidad de 60 kmph)..UNINDENT
[imagen: rastro de desvanecimiento 3 kmph] [imagen] Extracto del rastro de desvanecimiento incluido en el
simulador para un escenario urbano (velocidad de 3 kmph)..UNINDENT

Movilidad Modelo con Edificios
Ahora explicamos con ejemplos cómo utilizar el modelo de edificios (en particular, el
MovilidadEdificioInfo así como el EdificioPropagaciónModelo clases) en una simulación ns-3
programa para configurar un escenario de simulación LTE que incluye edificios y nodos interiores.

1. Archivos de cabecera a incluir:

#incluir
#incluir
#incluir

2. Selección del modelo Pathloss:

Ptr lteHelper = CrearObjeto ();

lteHelper->SetAttribute ("PathlossModel", StringValue ("ns3::BuildingsPropagationLossModel"));

3. Selección de banda EUTRA

La selección de la frecuencia de trabajo del modelo de propagación se debe realizar con el
sistema de atributos estándar ns-3 como se describe en la sección correspondiente ("Configuración de
Parámetros del modelo LTE") mediante los parámetros DlEarfcn y UlEarfcn, por ejemplo:

lteHelper->SetEnbDeviceAttribute ("DlEarfcn", UintegerValue (100));
lteHelper->SetEnbDeviceAttribute ("UlEarfcn", UintegerValue (18100));

Cabe señalar que utilizar otros medios para configurar la frecuencia utilizada por el
modelo de propagación (es decir, configurar el correspondiente BuildingsPropagationLossModel
atributos directamente) podría generar conflictos en la definición de frecuencias en el
módulos durante la simulación y, por lo tanto, no se recomienda.

1. Selección del modelo de movilidad:

MobilityHelper movilidad;
movilidad.SetMobilityModel ("ns3 :: ConstantPositionMobilityModel");

Cabe señalar que se puede utilizar cualquier modelo de movilidad.

2. Creación de edificios:

doble x_min = 0.0;
doble x_max = 10.0;
doble y_min = 0.0;
doble y_max = 20.0;
doble z_min = 0.0;
doble z_max = 10.0;
Ptr b = CreateObject ();
b-> Establecer límites (Box (x_min, x_max, y_min, y_max, z_min, z_max));
b-> SetBuildingType (Edificio :: Residencial);
b-> SetExtWallsType (Edificio :: ConcreteWithWindows);
b-> SetNFloors (3);
b-> SetNRoomsX (3);
b-> SetNRoomsY (2);

Esto instanciará un edificio residencial con base de 10 x 20 metros y altura de
10 metros cuyos muros exteriores son de hormigón con ventanas; el edificio tiene tres
pisos y tiene una grilla interna de 3 x 2 de habitaciones de igual tamaño.

3. Creación y posicionamiento de nodos:

ueNodes.Crear (2);
movilidad.Instalar (ueNodes);
BuildingsHelper :: Install (ueNodes);
NetDeviceContainer ueDevs;
ueDevs = lteHelper->InstallUeDevice (ueNodes);
Ptr mm0 = enbNodes.Get (0) -> GetObject ();
Ptr mm1 = enbNodes.Get (1) -> GetObject ();
mm0-> SetPosition (Vector (5.0, 5.0, 1.5));
mm1-> SetPosition (Vector (30.0, 40.0, 1.5));

4. Finalizar la configuración del modelo de construcción y movilidad:

BuildingsHelper :: MakeMobilityModelConsistent ();

Ver la documentación del edificios módulo para obtener información más detallada.

PHY Error Modelo
El modelo de error físico consta del modelo de error de datos y el modelo de error de control del enlace descendente.
modelo, ambos activos por defecto. Es posible desactivarlos con el ns3
sistema de atributos, en detalle:

Config::SetDefault ("ns3::LteSpectrumPhy::CtrlErrorModelEnabled", BooleanValue (false));
Config::SetDefault ("ns3::LteSpectrumPhy::DataErrorModelEnabled", BooleanValue (falso));

MIMO Modelo
En esta subsección ilustramos cómo configurar los parámetros MIMO. LTE define 7 tipos
de modos de transmisión:

· Modo de transmisión 1: SISO.

· Modo de transmisión 2: MIMO Tx Diversity.

· Modo de transmisión 3: Lazo abierto de multiplexión espacial MIMO.

· Modo de Transmisión 4: Lazo Cerrado de Multiplexidad Espacial MIMO.

· Modo de transmisión 5: MIMO Multiusuario.

· Modo de transmisión 6: Precodificación de una sola capa de bucle más cercano.

· Modo de transmisión 7: Puerto de antena única 5.

Según modelo implementado, el simulador incluye los tres primeros modos de transmisión.
tipos. El predeterminado es el Modo de transmisión 1 (SISO). Para cambiar el valor predeterminado
Modo de transmisión a utilizar, el atributo Modo de transmisión predeterminado del LteEnbRrc can
ser utilizado, como se muestra a continuación:

Config::SetDefault ("ns3::LteEnbRrc::DefaultTransmissionMode", UintegerValue (0)); // SISO
Config::SetDefault ("ns3::LteEnbRrc::DefaultTransmissionMode", UintegerValue (1)); // Diversidad MIMO Tx (1 ​​capa)
Config::SetDefault ("ns3::LteEnbRrc::DefaultTransmissionMode", UintegerValue (2)); // Multiplexidad espacial MIMO (2 capas)

Para cambiar el modo de transmisión de un determinado usuario durante la simulación, se requiere un
La interfaz se ha implementado en ambos programadores estándar:

anular TransmissionModeConfigurationUpdate (uint16_t rnti, uint8_t txMode);

Este método se puede utilizar tanto para desarrollar un motor de decisión del modo de transmisión (es decir, para
Optimización del modo de transmisión según la condición del canal y/o las necesidades del usuario.
requisitos) y para el cambio manual desde el script de simulación. En este último caso, el
El cambio se puede realizar como se muestra a continuación:

Ptr lteEnbDev = enbDevs.Get (0)->GetObject ();
Valor del puntero ptrval;
enbNetDev->GetAttribute ("FfMacScheduler", ptrval);
Ptr rrsched = ptrval.Obtener ();
Simulador::Programación (Segundos (0.2), &RrFfMacScheduler::TransmissionModeConfigurationUpdate, rrsched, rnti, 1);

Finalmente, el modelo implementado se puede reconfigurar según diferentes modelos MIMO mediante
actualizar los valores de ganancia (la única restricción es que la ganancia debe ser constante durante
tiempo de ejecución de la simulación y común para las capas). La ganancia de cada Modo de Transmisión puede ser
cambiado de acuerdo con el sistema de atributos estándar ns3, donde los atributos son:
Ganancia TxMode1, Ganancia TxMode2, Ganancia TxMode3, Ganancia TxMode4, Ganancia TxMode5, Ganancia TxMode6 y
Ganancia TxMode7. Solo por defecto Ganancia TxMode1, Ganancia TxMode2 y Ganancia TxMode3 tener un significado
valor, que son los derivados de _[CatreuxMIMO] (es decir, respectivamente 0.0, 4.2 y -2.8
dB).

Use of AntenaModelo
Ahora mostramos cómo asociar un modelo de antena particular con un dispositivo eNB para modelar un
sector de un macro eNB. Para ello es conveniente utilizar el CosenoAntenaModelo
proporcionado por el módulo de antena ns-3. La configuración del eNB se realizará a través del
LteHelper instancia justo antes de la creación de la Dispositivo EnbNet, como se muestra en el
siguientes:

lteHelper->SetEnbAntennaModelType ("ns3::CosineAntennaModel");
lteHelper->SetEnbAntennaModelAttribute ("Orientación", DoubleValue (0));
lteHelper->SetEnbAntennaModelAttribute ("Ancho de haz", DoubleValue (60);
lteHelper->SetEnbAntennaModelAttribute ("MaxGain", DoubleValue (0.0));

El código anterior generará un modelo de antena con un ancho de haz de 60 grados apuntando a lo largo
el eje X. La orientación se mide en grados desde el eje X, por ejemplo, una orientación
de 90 apuntaría a lo largo del eje Y, y una orientación de -90 apuntaría en sentido negativo.
dirección a lo largo del eje Y. El ancho del haz es el ancho del haz de -3 dB, por ejemplo, para un ángulo de 60 grados.
ancho del haz la ganancia de la antena en un ángulo de m
30 grados desde la dirección de orientación es -3 dB.

Para crear un sitio multisectorial, necesita crear diferentes nodos ns-3 colocados en el mismo
posición y para configurar Dispositivo EnbNet con diferentes orientaciones de antena para ser
instalado en cada nodo.

Radio Medio Ambiente Mapas
Usando la clase RadioMedio AmbienteMapaAyuda es posible generar en un archivo una radio
Mapa de entorno (REM), es decir, una cuadrícula 2D uniforme de valores que representan el
Relación señal-ruido en el enlace descendente respecto al eNB que tiene la mayor potencia
señal en cada punto. Es posible especificar si se debe generar REM para datos o
canal de control. También el usuario puede configurar el RbId, para el cual se generará REM. IdRb predeterminado
es -1, lo que significa que REM se generará con una relación señal-ruido promediada de todos
RB.

Para hacer esto, solo necesita agregar el siguiente código a su programa de simulación hacia el
final, justo antes de la llamada a Simulator::Run ():

Ptr remHelper = CrearObjeto ();
remHelper->SetAttribute ("ChannelPath", StringValue ("/ChannelList/0"));
remHelper->SetAttribute ("OutputFile", StringValue ("rem.out"));
remHelper->SetAttribute ("XMin", DoubleValue (-400.0));
remHelper->SetAttribute ("XMax", DoubleValue (400.0));
remHelper->SetAttribute ("XRes", UintegerValue (100));
remHelper->SetAttribute ("YMin", DoubleValue (-300.0));
remHelper->SetAttribute ("YMax", DoubleValue (300.0));
remHelper->SetAttribute ("YRes", UintegerValue (75));
remHelper->SetAttribute ("Z", DoubleValue (0.0));
remHelper->SetAttribute ("UseDataChannel", BooleanValue (verdadero));
remHelper->SetAttribute ("RbId", IntegerValue (10));
remHelper->Instalar ();

Al configurar los atributos del RadioMedio AmbienteMapaAyuda objeto como se muestra arriba, usted
Puede sintonizar los parámetros del REM que se generará. Tenga en cuenta que cada
RadioMedio AmbienteMapaAyuda la instancia puede generar solo un REM; si quieres generar mas
REM, debe crear una instancia separada para cada REM.

Tenga en cuenta que la generación REM es muy exigente, en particular:

· el consumo de memoria en tiempo de ejecución es de aproximadamente 5 KB por píxel. Por ejemplo, un REM
con una resolución de 500x500 necesitaría alrededor de 1.25 GB de memoria y una resolución de
1000x1000 necesitaría alrededor de 5 GB (demasiado para una PC normal en el momento de este
escribiendo). Para superar este problema, el REM se genera en pasos sucesivos, con cada
paso que evalúa como máximo un número de píxeles determinado por el valor de la
atributo RadioEnvironmentMapHelper::MaxPointsPerIteration.

· si generas un REM al comienzo de una simulación, ralentizará el
ejecución del resto de la simulación. Si desea generar un REM para un programa
y también usar el mismo programa para obtener el resultado de la simulación, se recomienda agregar un
interruptor de línea de comando que permite generar el REM o ejecutar el proceso completo
simulación. Para ello, tenga en cuenta que existe un atributo
RadioEnvironmentMapHelper::Detener cuando termine (predeterminado: verdadero) que forzará el
La simulación se detiene inmediatamente después de que se haya generado el REM.

El REM se almacena en un archivo ASCII en el siguiente formato:

· la columna 1 es la coordenada x

· la columna 2 es la coordenada y

· la columna 3 es la coordenada z

· la columna 4 es el SINR en unidades lineales

A continuación se proporciona un script gnuplot mínimo que le permite trazar el REM:

establecer ver mapa;
establecer etiqueta x "X"
establecer la etiqueta "Y"
establezca la etiqueta "SINR (dB)"
clave de desarmado
trazar "rem.out" usando ($1):($2):(10*log10($4)) con imagen

A modo de ejemplo, aquí tenéis el REM que se puede obtener con el programa de ejemplo.
lena-dual-stripe, que muestra una macrocélula LTE de tres sectores en un despliegue cocanal con
Algunas femtocélulas residenciales se desplegaron aleatoriamente en dos bloques de apartamentos.
[imagen] REM obtenido del ejemplo de lena-dual-stripe.UNINDENT

Tenga en cuenta que el programa de ejemplo lena-dual-stripe también genera resultados compatibles con gnuplot
archivos que contienen información sobre las posiciones de los nodos UE y eNB, así como de
los edificios, respectivamente en los archivos ues.txt, enbs.txt y edificios.txt. Estos pueden
incluirse fácilmente al usar gnuplot. Por ejemplo, suponiendo que su script gnuplot
(por ejemplo, el script gnuplot mínimo descrito anteriormente) se guarda en un archivo llamado
mi_trama_script, ejecutar el siguiente comando trazaría la ubicación de UE, eNB y
edificios encima del REM:

gnuplot -p enbs.txt ues.txt edificios.txt my_plot_script

AMC Modelo y CQI Cálculo
El simulador proporciona dos posibles esquemas en lo que respecta a la selección de los MCS.
y en consecuencia la generación de los CQI. El primero está basado en el módulo GSoC.
[Piro2011] y funciona por RB. Este modelo se puede activar con el atributo ns3.
sistema, como se presenta a continuación:

Config::SetDefault ("ns3::LteAmc::AmcModel", EnumValue (LteAmc::PiroEW2010));

Mientras, la solución basada en el modelo de error físico se puede controlar con:

Config::SetDefault ("ns3::LteAmc::AmcModel", EnumValue (LteAmc::MiErrorModel));

Finalmente, la eficiencia requerida del PiroEW2010 El módulo AMC se puede sintonizar gracias al
Ber atributo (), por ejemplo:

Config::SetDefault ("ns3::LteAmc::Ber", DoubleValue (0.00005));

Evolucionado Paquete Core (EPC)
Ahora explicamos cómo escribir un programa de simulación que permita simular el EPC en
además de la red de acceso radio LTE. El uso de EPC permite utilizar redes IPv4
con dispositivos LTE. En otras palabras, podrá utilizar las aplicaciones ns-3 habituales.
y sockets sobre IPv4 sobre LTE, y también para conectar una red LTE a cualquier otro IPv4
red que pueda tener en su simulación.

En primer lugar, además de LteHelper que ya introdujimos en Básico simulación
programa, necesitas usar un adicional EpcHelper clase, que se encargará de crear
las entidades EPC y la topología de la red. Tenga en cuenta que no puede utilizar EpcHelper directamente, ya que
es una clase base abstracta; en su lugar, necesita usar una de sus clases hijas, que
Proporcionar diferentes implementaciones de topología EPC. En este ejemplo consideraremos
Ayudante PointToPointEpc, que implementa un EPC basado en enlaces punto a punto. Para usarlo,
Primero debe insertar este código en su programa de simulación:

Ptr lteHelper = CrearObjeto ();
Ptr epcHelper = CrearObjeto ();

Luego, debe decirle al asistente LTE que se utilizará el EPC:

lteHelper->SetEpcHelper (epcHelper);

El paso anterior es necesario para que el asistente LTE active el EPC apropiado.
configuración en correspondencia con alguna configuración importante, como cuando se instala un nuevo eNB.
o se añade UE a la simulación, o se crea un portador de EPS. El ayudante de EPC
encargarse automáticamente de la configuración necesaria, como la creación del enlace S1 y el portador S1
configuración. Todo ello se hará sin la intervención del usuario.

llamar lteHelper->SetEpcHelper (epcAyudante) permite el uso de EPC, y tiene el lado
efecto que cualquier nuevo LteEnbRrc que se cree tendrá la EpsBearerToRlcMapping
atributo establecido en RLC_UM_ALWAYS en lugar de RLC_SM_ALWAYS si este último fuera el predeterminado;
de lo contrario, el atributo no se cambiará (por ejemplo, si cambió el valor predeterminado a
RLC_AM_ALWAYS, no se tocará).

Cabe señalar que el EpcHelper También creará automáticamente el nodo PGW y
configúrelo para que pueda manejar adecuadamente el tráfico desde/hacia la red de acceso de radio LTE.
Aún así, debe agregar algún código explícito para conectar el PGW a otras redes IPv4 (por ejemplo,
La Internet). A continuación se muestra un ejemplo muy sencillo sobre cómo conectar un único host remoto a
el PGW a través de un enlace punto a punto:

Ptr pgw = epcHelper->GetPgwNode ();

// Crea un único RemoteHost
NodeContainer remotoHostContainer;
remotoHostContainer.Create (1);
Ptr RemoteHost = RemoteHostContainer.Get (0);
InternetStackHelperinternet;
internet.Instalar (remoteHostContainer);

// Crea Internet
Ayudante PuntoAPunto p2ph;
p2ph.SetDeviceAttribute ("DataRate", DataRateValue (DataRate ("100Gb/s")));
p2ph.SetDeviceAttribute ("Mtu", UintegerValue (1500));
p2ph.SetChannelAttribute ("Retraso", TimeValue (Segundos (0.010)));
NetDeviceContainer internetDevices = p2ph.Install (pgw, host remoto);
Ayudante de dirección ipv4 ipv4h;
ipv4h.SetBase ("1.0.0.0", "255.0.0.0");
Ipv4InterfaceContainer internetIpIfaces = ipv4h.Assign (internetDevices);
// la interfaz 0 es localhost, 1 es el dispositivo p2p
Ipv4Address remotoHostAddr = internetIpIfaces.GetAddress (1);

Es importante especificar rutas para que el host remoto pueda llegar a los UE LTE. una forma de
Hacer esto es explotar el hecho de que el Ayudante PointToPointEpc asignará por defecto
a los UE LTE una dirección IP en la red 7.0.0.0. Teniendo esto en cuenta, basta con hacer:

Ayudante de enrutamiento estático de Ipv4 Ayudante de enrutamiento de ipv4;
Ptr remoteHostStaticRouting = ipv4RoutingHelper.GetStaticRouting (remoteHost->GetObject ());
remoteHostStaticRouting->AddNetworkRouteTo (Ipv4Address ("7.0.0.0"), Ipv4Mask ("255.0.0.0"), 1);

Ahora, debe continuar y crear eNB y UE LTE como se explica en las secciones anteriores.
Por supuesto, puede configurar otros aspectos de LTE, como modelos de pérdida de ruta y desvanecimiento. Bien
Después de crear los UE, también debe configurarlos para redes IP. Esto esta hecho
como sigue. Suponemos que tiene un contenedor para nodos UE y eNodeB como este:

NodoContenedor ueNodes;
NodoContenedor enbNodes;

Para configurar una simulación solo LTE, normalmente haría algo como esto:

NetDeviceContainer ueLteDevs = lteHelper->InstallUeDevice (ueNodes);
lteHelper->Adjuntar (ueLteDevs, enbLteDevs.Get (0));

Para configurar los UE para redes IP, solo necesita hacer adicionalmente me gusta
modo:

// instalamos la pila de IP en los UE
InternetStackHelperinternet;
internet.Instalar (ueNodes);

// asignar dirección IP a los UE
para (uint32_t u = 0; u < ueNodes.GetN (); ++u)
{
Ptr ue = ueNodes.Get (u);
Ptr ueLteDevice = ueLteDevs.Get (u);
Ipv4InterfaceContainer ueIpIface = epcHelper->AssignUeIpv4Address (NetDeviceContainer (ueLteDevice));
// establece la puerta de enlace predeterminada para el UE
Ptr ueStaticRouting = ipv4RoutingHelper.GetStaticRouting (ue->GetObject ());
ueStaticRouting->SetDefaultRoute (epcHelper->GetUeDefaultGatewayAddress (), 1);
}

La activación de portadores se realiza de forma ligeramente diferente respecto a lo que se hace
para una simulación solo LTE. En primer lugar, no se debe utilizar el método ActivateDataRadioBearer.
cuando se utiliza el EPC. En segundo lugar, cuando se utiliza EPC, se activará el portador EPS predeterminado.
automáticamente cuando llamas a LteHelper::Attach (). En tercer lugar, si desea configurar una cuenta dedicada
Portador de EPS, puede hacerlo utilizando el método LteHelper::ActivateDedicatedEpsBearer (). Este
El método toma como parámetro la plantilla de flujo de tráfico (TFT), que es una estructura que
identifica el tipo de tráfico que se asignará al portador EPS dedicado. Aquí hay un
ejemplo de cómo configurar un portador dedicado para una aplicación en el UE que se comunica en
puerto 1234:

Ptr tft = crear ();
EpcTft::PacketFilter pf;
pf.localPortStart = 1234;
pf.localPortEnd = 1234;
tft->Agregar (pf);
lteHelper->ActivateDedicatedEpsBearer (ueLteDevs, EpsBearer (EpsBearer::NGBR_VIDEO_TCP_DEFAULT), tft);

Por supuesto, puede utilizar configuraciones personalizadas de EpsBearer y EpcTft; consulte la
documentación de doxygen sobre cómo hacerlo.

Finalmente, puede instalar aplicaciones en los nodos LTE UE que se comunican con dispositivos remotos.
aplicaciones a través de Internet. Esto se hace siguiendo los procedimientos habituales del ns-3.
Siguiendo nuestro sencillo ejemplo con un único host remoto, aquí se explica cómo configurar el enlace descendente
comunicación, con una aplicación UdpClient en el host remoto y un PacketSink en el
LTE UE (usando los mismos nombres de variables de los fragmentos de código anteriores)

uint16_t dlPort = 1234;
PacketSinkHelper paqueteSinkHelper ("ns3::UdpSocketFactory",
InetSocketAddress (Ipv4Address::GetAny (), dlPort));
ApplicationContainer serverApps = paqueteSinkHelper.Install (ue);
serverApps.Start (Segundos (0.01));
Cliente UdpClientHelper (ueIpIface.GetAddress (0), dlPort);
ApplicationContainer clientApps = client.Install (remoteHost);
clientApps.Start (Segundos (0.01));

¡Eso es todo! Ahora puedes comenzar tu simulación como de costumbre:

Simulador::Detener (Segundos (10.0));
Simulador::Ejecutar ();

Usando los EPC con emulación modo
En la sección anterior utilizamos enlaces PointToPoint para la conexión entre los eNB y
el SGW (interfaz S1-U) y entre los eNB (interfaces X2-U y X2-C). El módulo LTE
admite el uso de enlaces emulados en lugar de enlaces punto a punto. Esto se logra con sólo
reemplazando la creación de LteHelper y EpcHelper con el siguiente código:

Ptr lteHelper = CrearObjeto ();
Ptr epcHelper = CrearObjeto ();
lteHelper->SetEpcHelper (epcHelper);
epcHelper->Inicializar ();

Los atributos ns3::EmuEpcHelper::sgwNombreDeDispositivo y ns3::EmuEpcHelper::enbNombreDeDispositivo están
Se utiliza para establecer el nombre de los dispositivos utilizados para transportar el S1-U, X2-U y X2-C.
interfaces en el SGW y el eNB, respectivamente. Ahora mostraremos cómo se hace esto en un
ejemplo donde ejecutamos el programa de ejemplo lena-simple-epc-emu usando dos virtuales
interfaces ethernet.

Primero que nada construimos ns-3 apropiadamente:

# configurar
./waf configure --enable-sudo --enable-modules=lte,fd-net-device --enable-examples

# construir
./waf

Luego configuramos dos interfaces Ethernet virtuales e iniciamos Wirehark para observar el tráfico.
ir a través:

# nota: necesitas ser root

# crear dos dispositivos veth emparejados
enlace IP agregar nombre veth0 tipo veth nombre de par veth1
mostrar enlace ip

# habilitar el modo promiscuo
enlace IP configurado veth0 promisc activado
enlace IP configurado veth1 promisc activado

# abrir interfaces
enlace ip configurado veth0
enlace ip configurado veth1

# iniciamos Wirehark y capturamos en veth0
tiburón de alambre y

Ahora podemos ejecutar el programa de ejemplo con el reloj simulado:

./waf --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0 --ns3::EmuEpcHelper::enbDeviceName=veth1"

Al utilizar Wireshark, primero debería ver la resolución ARP y luego algunos paquetes GTP intercambiados.
en enlace ascendente y descendente.

La configuración predeterminada del programa de ejemplo es 1 eNB y 1UE. Puedes cambiar esto a través de
parámetros de línea de comando, por ejemplo:

./waf --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0 --ns3::EmuEpcHelper::enbDeviceName=veth1 --nEnbs=2 --nUesPerEnb =2"

Para obtener una lista de los parámetros disponibles:

./waf --run lena-simple-epc-emu --command="%s --PrintHelp"

Para ejecutar con el reloj en tiempo real: resulta que la compilación de depuración predeterminada es demasiado lenta para
tiempo real. Suavizar las limitaciones de tiempo real con el modo BestEffort no es una buena idea:
algo puede salir mal (por ejemplo, ARP puede fallar) y, de ser así, no recibirá ningún paquete de datos
afuera. Por lo tanto, necesita un hardware decente y una construcción optimizada con enlaces estáticos.
módulos:

./waf configure -d optimizado --enable-static --enable-modules=lte --enable-examples --enable-sudo

Luego ejecute el programa de ejemplo así:

./waf --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0 --ns3::EmuEpcHelper::enbDeviceName=veth1 --simulatorImplementationType=ns3::RealtimeSimulatorImpl --ns3::RealtimeSimulatorImpl::SynchronizationMode=HardLimit"

tenga en cuenta la configuración HardLimit, que hará que el programa finalice si no puede mantener el ritmo
con tiempo real.

El enfoque descrito en esta sección se puede utilizar con cualquier tipo de dispositivo de red. Para
Por ejemplo, [Baldo2014] describe cómo se utilizó para ejecutar una red LTE-EPC emulada a través de un
Red de transporte óptica de paquetes multicapa real.

Nuestra Red Adjuntar archivo
Como se muestra en el ejemplo básico de la sección Básico simulación programa, conectar un UE a un
eNodeB se realiza llamando LteHelper::Adjuntar función.

Hay 2 formas posibles de conexión a la red. El primer método es el "manual" uno,
mientras que el segundo tiene un más "automático" sentido en ello. Cada uno de ellos estará cubierto de
esta sección.

Manual accesorio
Este método utiliza el LteHelper::Adjuntar función mencionada anteriormente. ha sido el unico
Método de conexión de red disponible en versiones anteriores del módulo LTE. es típicamente
invocado antes de que comience la simulación:

lteHelper->Adjuntar (ueDevs, enbDev); // adjuntar uno o más UE a un único eNodoB

LteHelper::InstallEnbDevice y LteHelper::InstallUeDevice las funciones deben haber sido llamadas
antes de adjuntar. En una simulación habilitada para EPC, también se requiere tener IPv4 correctamente
preinstalado en la UE.

Este método es muy simple, pero requiere que sepas exactamente qué UE pertenece a qué
eNodeB antes de que comience la simulación. Esto puede resultar difícil cuando la posición inicial del UE es
determinado aleatoriamente por el guión de simulación.

Se puede elegir la distancia entre el UE y el eNodoB como criterio para seleccionar el
celda apropiada. Es bastante simple (al menos desde el punto de vista del simulador) y
a veces práctico. Pero es importante señalar que a veces la distancia no marca la diferencia.
único criterio correcto. Por ejemplo, la directividad de la antena del eNodeB debe ser
considerado también. Además de eso, también se debe tener en cuenta la condición del canal,
que podría fluctuar si hay efecto de desvanecimiento o sombra. En este tipo de
En muchos casos, la conexión a la red no debe basarse únicamente en la distancia.

En la vida real, UE evaluará automáticamente ciertos criterios y seleccionará la mejor celda para
adjuntar, sin intervención manual del usuario. Obviamente este no es el caso en
este vídeo LteHelper::Adjuntar función. El otro método de conexión a la red utiliza más "automático"
enfoque para la conexión a la red, como se describirá a continuación.

Automático accesorio usando Idle modo (SCD por sus siglas en inglés), selección procedimientos
La intensidad de la señal recibida es el criterio estándar utilizado para seleccionar la mejor
celda para adjuntar. El uso de este criterio se implementa en el inicial (SCD por sus siglas en inglés), selección
proceso, que se puede invocar llamando a otra versión del LteHelper::Adjuntar
función, como se muestra a continuación:

lteHelper->Adjuntar (ueDevs); // adjuntar uno o más UE a una celda más fuerte

La diferencia con el método manual es que no se especifica el eNodoB de destino. El
El procedimiento encontrará la mejor celda para los UE, basándose en varios criterios, incluido el
intensidad de la señal recibida (RSRP).

Después de llamar al método, el UE dedicará algún tiempo a medir las celdas vecinas,
y luego intente adjuntar al mejor. Más detalles se pueden encontrar en la sección
sec-selección-celda-inicial de la Documentación de Diseño.

Es importante señalar que este método sólo funciona en simulaciones habilitadas para EPC. Solo LTE
Las simulaciones deben recurrir al método de fijación manual.

Cerrado Suscriptor Grupo procesos
Un caso de uso interesante del proceso de selección de celda inicial es configurar una simulación
entorno con Grupo Cerrado de Suscriptores (CSG).

Por ejemplo, un determinado eNodoB, normalmente una versión más pequeña como una femtocelda, podría pertenecer
a un propietario privado (por ejemplo, un hogar o una empresa), permitiendo el acceso sólo a algunos UE que
haber sido registrados previamente por el propietario. El eNodeB y los UE registrados en conjunto
formar un CSG.

La restricción de acceso se puede simular "etiquetando" a los miembros del CSG con el mismo CSG.
IDENTIFICACIÓN. Esto se hace a través de los atributos tanto en eNodeB como en UE, por ejemplo usando el
siguiendo LteHelper funciones:

// etiquetar los siguientes eNodeB con identidad CSG de 1 e indicación CSG habilitada
lteHelper->SetEnbDeviceAttribute ("CsgId", UintegerValue (1));
lteHelper->SetEnbDeviceAttribute ("CsgIndication", BooleanValue (verdadero));

// etiqueta uno o más UE con identidad CSG de 1
lteHelper->SetUeDeviceAttribute ("CsgId", UintegerValue (1));

// instalar los eNodeB y UE
NetDeviceContainer csgEnbDevs = lteHelper->InstallEnbDevice (csgEnbNodes);
NetDeviceContainer csgUeDevs = lteHelper->InstallUeDevice (csgUeNodes);

Luego habilite el procedimiento de selección de celda inicial en los UE:

lteHelper->Adjuntar (csgUeDevs);

Esto es necesario porque la restricción CSG sólo funciona con el método automático de red.
adjunto, pero no en el método manual.

Tenga en cuenta que configurar la indicación CSG de un eNodoB como falsa (el valor predeterminado)
deshabilitar la restricción, es decir, cualquier UE puede conectarse a este eNodoB.

Configurar UE medidas
La configuración de medición de UE activa en una simulación está dictada por el modo seleccionado.
llamados "consumidores", como el algoritmo de traspaso. Los usuarios pueden agregar su propia configuración a
acción, y hay varias maneras de hacerlo:

1. configuración directa en la entidad RRC del eNodoB;

2. configurar el algoritmo de traspaso existente; y

3. desarrollar un nuevo algoritmo de traspaso.

Esta sección cubrirá únicamente el primer método. El segundo método está cubierto en Automático
entregar detonante, mientras que el tercer método se explica detalladamente en la Sección
algoritmo de segunda entrega de la documentación de diseño.

La configuración directa en eNodeB RRC funciona de la siguiente manera. El usuario comienza creando un nuevo
LteRrcSap::ReportConfigEutra instancia y pasarla al LteEnbRrc::AddUeMeasReportConfig
función. La función devolverá el IdMedido (identidad de medición) que es única
referencia de la configuración en la instancia del eNodeB. Esta función debe ser llamada antes
comienza la simulación. La configuración de medición estará activa en todos los UE conectados a
el eNodoB durante toda la simulación. Durante la simulación, el usuario puede
capturar los informes de medición producidos por los UE escuchando los informes existentes
LteEnbRrc::RecvMeasurementReport fuente de rastreo.

La estructura ReportConfigEutra está de acuerdo con la especificación 3GPP. Definición de la
La estructura y cada campo miembro se pueden encontrar en la Sección 6.3.5 de [TS36331].

El siguiente ejemplo de código configura la medición RSRP del Evento A1 para cada eNodoB dentro del
envase desarrolladores:

LteRrcSap::ReportConfigEutra configuración;
config.eventId = LteRrcSap::ReportConfigEutra::EVENT_A1;
config.threshold1.choice = LteRrcSap::UmbralEutra::THRESHOLD_RSRP;
config.threshold1.range = 41;
config.triggerQuantity = LteRrcSap::ReportConfigEutra::RSRP;
config.reportInterval = LteRrcSap::ReportConfigEutra::MS480;

estándar::vector listaIdMeas;

NetDeviceContainer::Iterador;
para (it = devs.Begin (); it != devs.End (); it++)
{
Ptr dev = *eso;
Ptr enbDev = dev->GetObject ();
Ptr enbRrc = enbDev->GetRrc ();

uint8_t measId = enbRrc->AddUeMeasReportConfig (config);
measIdList.push_back (medirId); // recuerda el measId creado

enbRrc->TraceConnect ("RecvMeasurementReport",
"contexto",
MakeCallback (&RecvMeasurementReportCallback));
}

Tenga en cuenta que los umbrales se expresan como rango. En el ejemplo anterior, el rango 41 para RSRP
corresponde a -100 dBm. La conversión desde y hacia el formato de rango se debe a la Sección
9.1.4 y 9.1.7 de [TS36133]. El EutranMediciónMapeo la clase tiene varios estáticos
funciones que se pueden utilizar para este propósito.

La función de devolución de llamada correspondiente tendría una definición similar a la siguiente:

vacío
RecvMeasurementReportCallback (std::contexto de cadena,
uint64_t imsi,
uint16_t ID de celda,
uint16_t rnti,
LteRrcSap::Reporte de Medición measReport);

Este método registrará la función de devolución de llamada como consumidor de mediciones de UE. En el
caso en el que hay más de un consumidor en la simulación (por ejemplo, algoritmo de traspaso),
Las medidas destinadas a otros consumidores también serán capturadas por esta devolución de llamada.
función. Los usuarios pueden utilizar el IdMedido campo, contenido dentro del
LteRrcSap::Reporte de Medición argumento de la función de devolución de llamada, para indicar qué medida
La configuración ha activado el informe.

En general, este mecanismo impide que un consumidor intervenga sin saberlo en otro.
configuración de informes del consumidor.

Tenga en cuenta que sólo la parte de configuración de informes (es decir, LteRrcSap::ReportConfigEutra de
El parámetro de mediciones UE está abierto para que los consumidores lo configuren, mientras que las otras partes
se mantienen ocultos. La limitación intrafrecuencia es la principal motivación detrás de esta API
decisión de implementación:

· sólo hay uno, inequívoco y definitivo multiplataforma objeto, entonces no hay
necesidad de configurarlo;

· multiplataforma identidades se mantienen ocultos debido al hecho de que hay uno a uno
mapeo entre la configuración de informes y la identidad de medición, por lo tanto, un nuevo
La identidad de medición se configura automáticamente cuando se crea una nueva configuración de informes.
creado;

· la cantidad configuración está configurado en otro lugar, consulte mediciones de rendimiento de segundos; y

· multiplataforma lagunas no son compatibles, porque solo es aplicable para interfrecuencia
ajustes;

basado en X2 entregar
Según lo definido por 3GPP, el traspaso es un procedimiento para cambiar la celda de servicio de un UE en
Modo CONECTADO. Los dos eNodosB involucrados en el proceso generalmente se denominan fuente
eNodoB así como el dirigidos eNodoB.

Para permitir la ejecución del traspaso basado en X2 en simulación, hay dos
requisitos que deben cumplirse. En primer lugar, EPC debe estar habilitado en la simulación (ver Evolucionado
Paquete Core (EPC)).

En segundo lugar, se debe configurar una interfaz X2 entre los dos eNodeB, que debe ser
hecho explícitamente dentro del programa de simulación:

lteHelper->AddX2Interface (enbNodes);

donde enbNodos es un Contenedor de nodo que contiene los dos eNodosB entre los cuales se encuentra el X2.
se va a configurar la interfaz. Si el contenedor tiene más de dos eNodeB, la función
creará una interfaz X2 entre cada par de eNodeB en el contenedor.

Por último, el eNodoB objetivo debe configurarse como "abierto" para la SOLICITUD DE ENTREGA X2. Cada
eNodeB está abierto de forma predeterminada, por lo que en la mayoría de los casos no se necesitan instrucciones adicionales. Sin embargo, los usuarios
puede configurar el eNodoB como "cerrado" configurando el atributo booleano
LteEnbRrc::AdmitHandoverRequest a false. Como ejemplo, puede ejecutar el lena-x2-entrega
programa y configurando el atributo de esta manera:

NS_LOG=EpcX2:LteEnbRrc ./waf --run lena-x2-handover --command="%s --ns3::LteEnbRrc::AdmitHandoverRequest=false"

Una vez que se cumplan los tres requisitos anteriores, se puede iniciar el procedimiento de entrega.
manual o automáticamente. Cada uno se presentará en las siguientes subsecciones.

Manual entregar detonante
El evento de traspaso se puede activar "manualmente" dentro del programa de simulación programando una
evento de entrega explícito. El LteHelper objeto proporciona un método conveniente para
programación de un evento de entrega. Como ejemplo, supongamos que ueLteDevs es un
NetDeviceContainerNetDeviceContainer que contiene el UE que se va a entregar, y que enbLteDevs is
una alternativa, NetDeviceContainerNetDeviceContainer que contiene el eNB de origen y de destino. Luego, una entrega
a 0.1 s se puede programar así:

lteHelper->HandoverRequest (Segundos (0.100),
ueLteDevs.Get (0),
enbLteDevs.Get (0),
enbLteDevs.Get (1));

Tenga en cuenta que el UE debe estar ya conectado al eNB de origen; de lo contrario, la simulación
terminará con un mensaje de error.

Para ver un ejemplo con el código fuente completo, consulte el lena-x2-entrega (aqui)
.

Automático entregar detonante
El procedimiento de traspaso también puede ser activado "automáticamente" por el eNodoB de servicio del UE.
La lógica detrás del disparador depende del algoritmo de traspaso actualmente activo en el
Entidad RRC del eNodoB. Los usuarios pueden seleccionar y configurar el algoritmo de transferencia que se utilizará.
en la simulación, que se explicará en breve en esta sección. Los usuarios también pueden optar por
escribir su propia implementación del algoritmo de traspaso, como se describe en la Sección
algoritmo de segunda entrega de la documentación de diseño.

La selección de un algoritmo de traspaso se realiza mediante el LteHelper objeto y su
Establecer tipo de algoritmo de entrega método como se muestra a continuación:

Ptr lteHelper = CrearObjeto ();
lteHelper->SetHandoverAlgorithmType ("ns3::A2A4RsrqHandoverAlgorithm");

El algoritmo de traspaso seleccionado también puede proporcionar varios atributos configurables, que
se puede configurar de la siguiente manera:

lteHelper->SetHandoverAlgorithmAttribute ("ServingCellThreshold",
UvalorEntero (30));
lteHelper->SetHandoverAlgorithmAttribute ("NeighbourCellOffset",
UvalorEntero (1));

Se incluyen tres opciones de algoritmo de transferencia en el módulo LTE. El A2-A4-RSRQ
algoritmo de traspaso (llamado como ns3::A2A4RsrqAlgoritmo de transferencia) es la opción predeterminada, y
el uso ya se ha mostrado arriba.

Otra opción es la más fuerte (SCD por sus siglas en inglés), algoritmo de traspaso (llamado como
ns3::A3RsrpAlgoritmo de transferencia), que se puede seleccionar y configurar mediante el siguiente código:

lteHelper->SetHandoverAlgorithmType ("ns3::A3RsrpHandoverAlgorithm");
lteHelper->SetHandoverAlgorithmAttribute ("Histéresis",
DobleValor (3.0));
lteHelper->SetHandoverAlgorithmAttribute ("TimeToTrigger",
ValorTiempo (MilliSeconds (256)));

La última opción es especial, llamada sin operación algoritmo de traspaso, que básicamente
desactiva el activador de transferencia automática. Esto es útil, por ejemplo, en casos en los que se realiza manualmente
El activador de traspaso necesita un control exclusivo de todas las decisiones de traspaso. No tiene ninguna
atributos configurables. El uso es el siguiente:

lteHelper->SetHandoverAlgorithmType ("ns3::NoOpHandoverAlgorithm");

Para obtener más información sobre la política de decisión de cada algoritmo de traspaso y sus atributos,
consulte sus respectivas subsecciones en la Sección segunda-algoritmo de entrega del
Documentación de diseño.

Finalmente, la InstalarEnbDevice función de LteHelper creará una instancia de la
algoritmo de transferencia seleccionado para cada dispositivo eNodeB. En otras palabras, asegúrese de seleccionar
el algoritmo de entrega correcto antes de finalizarlo en la siguiente línea de código:

NetDeviceContainer enbLteDevs = lteHelper->InstallEnbDevice (enbNodes);

Se puede encontrar un ejemplo con el código fuente completo sobre el uso del activador de transferencia automática en el
lena-x2-entrega-medidas programa de ejemplo.

Tuning simulación con entregar
Como se menciona en la Documentación de Diseño, la implementación actual del modelo de traspaso puede
producir un comportamiento impredecible cuando ocurre una falla en la transferencia. Esta subsección se centrará en
los pasos que deben tener en cuenta los usuarios si planean utilizar el traspaso en su
simulaciones.

La principal causa de fallo de traspaso que abordaremos es el error en la transmisión.
mensajes de señalización relacionados con el traspaso durante la ejecución de un procedimiento de traspaso. Como
evidente en la Figura fig-x2-based-handover-seq-diagram de la Documentación de Diseño,
Hay muchos de ellos y utilizan diferentes interfaces y protocolos. Por el bien de
simplicidad, podemos asumir con seguridad que la interfaz X2 (entre el eNodoB de origen y el
eNodoB objetivo) y la interfaz S1 (entre el eNodoB objetivo y el SGW/PGW) son bastante
estable. Por lo tanto centraremos nuestra atención en el protocolo RRC (entre la UE y la
eNodeBs) y el procedimiento de Acceso Aleatorio, que normalmente se transmiten por el aire
y susceptible a la degradación de la condición del canal.

Un consejo general para reducir el error de transmisión es garantizar high suficientes SINR nivel en cada
UE. Esto se puede hacer mediante una planificación adecuada de la topología de la red que minimiza del sistema,
cobertura agujero. Si la topología tiene un agujero de cobertura conocido, entonces el UE debe configurarse
no aventurarse a esa zona.

Otro enfoque a tener en cuenta es evitar Demasiado tarde traspasos. En otras palabras, entrega
Esto debe suceder antes de que el SINR del UE sea demasiado bajo; de lo contrario, el UE puede no recibir
el comando de transferencia desde el eNodoB de origen. Los algoritmos de traspaso tienen los medios para controlar
cuán temprano o tarde se toma una decisión de traspaso. Por ejemplo, algoritmo de traspaso A2-A4-RSRQ
Se puede configurar con un umbral más alto para que decida un traspaso antes. Similarmente,
histéresis más pequeña y/o tiempo de activación más corto en el algoritmo de traspaso de celda más fuerte
normalmente resulta en entregas más tempranas. Para encontrar los valores correctos para estos
parámetros, uno de los factores que se debe considerar es la velocidad de movimiento del UE.
Generalmente, un UE que se mueve más rápido requiere que el traspaso se ejecute antes. Alguna investigación
El trabajo ha sugerido valores recomendados, como en [Lee2010].

Los consejos anteriores deberían ser suficientes en usos normales de simulación, pero en el caso de que se
Si surgen necesidades, se puede tomar en consideración una medida extrema. Por ejemplo, los usuarios
puede considerar deshabilitar los canal error modelos. Esto asegurará que todos
Los mensajes de señalización relacionados con el traspaso se transmitirán con éxito, independientemente de
distancia y condición del canal. No obstante, afectará también a todos los demás datos o controles
paquetes no relacionados con la transferencia, lo que puede ser un efecto secundario no deseado. De lo contrario, puede
hacerse de la siguiente manera:

Config::SetDefault ("ns3::LteSpectrumPhy::CtrlErrorModelEnabled", BooleanValue (false));
Config::SetDefault ("ns3::LteSpectrumPhy::DataErrorModelEnabled", BooleanValue (falso));

Al utilizar el código anterior, deshabilitamos el modelo de error tanto en el canal de control como en el de datos y
en ambas direcciones (enlace descendente y ascendente). Esto es necesario porque los relacionados con el traspaso
Los mensajes de señalización se transmiten utilizando estos canales. Una excepción es cuando el
La simulación utiliza el protocolo RRC ideal. En este caso, sólo se aplica el procedimiento de acceso aleatorio.
quedan por considerar. El procedimiento consta de mensajes de control, por lo tanto sólo necesitamos
para desactivar el modelo de error del canal de control.

Entregar huellas
El modelo RRC, en particular el LteEnbRrc y LteUeRrc objetos, proporcione algunos útiles
seguimientos que se pueden conectar a algunas funciones personalizadas para que se invoquen al iniciar
y el final de la fase de ejecución del traspaso tanto en el lado UE como en el eNB. Como ejemplo, en
En su programa de simulación puede declarar los siguientes métodos:

vacío
NotifyHandoverStartUe (std::contexto de cadena,
uint64_t imsi,
uint16_t ID de celda,
uint16_t rnti,
uint16_t targetCellId)
{
std::cout << Simulador::Now ().GetSeconds () << " " << contexto
<< " UE IMSI " << imsi
<< ": previamente conectado a CellId " << cellId
<< " con RNTI " << rnti
<< ", realizando la transferencia a CellId " << targetCellId
<< std::endl;
}

vacío
NotifyHandoverEndOkUe (std::contexto de cadena,
uint64_t imsi,
uint16_t ID de celda,
uint16_trnti)
{
std::cout << Simulador::Now ().GetSeconds () << " " << contexto
<< " UE IMSI " << imsi
<< ": entrega exitosa a CellId " << cellId
<< " con RNTI " << rnti
<< std::endl;
}

vacío
NotifyHandoverStartEnb (std::contexto de cadena,
uint64_t imsi,
uint16_t ID de celda,
uint16_t rnti,
uint16_t targetCellId)
{
std::cout << Simulador::Now ().GetSeconds () << " " << contexto
<< " eNB CellId " << cellId
<< ": iniciar la transferencia de UE con IMSI " << imsi
<< " RNTI " << rnti
<< " a CellId " << targetCellId
<< std::endl;
}

vacío
NotifyHandoverEndOkEnb (std::contexto de cadena,
uint64_t imsi,
uint16_t ID de celda,
uint16_trnti)
{
std::cout << Simulador::Now ().GetSeconds () << " " << contexto
<< " eNB CellId " << cellId
<< ": entrega completa de UE con IMSI " << imsi
<< " RNTI " << rnti
<< std::endl;
}

Luego, puede conectar estos métodos a las fuentes de seguimiento correspondientes de esta manera:

Config::Connect ("/NodeList/*/DeviceList/*/LteEnbRrc/HandoverStart",
MakeCallback (&NotifyHandoverStartEnb));
Config::Connect ("/NodeList/*/DeviceList/*/LteUeRrc/HandoverStart",
MakeCallback (&NotifyHandoverStartUe));
Config::Connect ("/NodeList/*/DeviceList/*/LteEnbRrc/HandoverEndOk",
MakeCallback (&NotifyHandoverEndOkEnb));
Config::Connect ("/NodeList/*/DeviceList/*/LteUeRrc/HandoverEndOk",
MakeCallback (&NotifyHandoverEndOkUe));

El programa de ejemplo src/lte/examples/lena-x2-handover.cc ilustra cómo todo lo anterior
Las instrucciones se pueden integrar en un programa de simulación. Puedes ejecutar el programa así:

./waf --ejecutar lena-x2-handover

y generará los mensajes impresos por los ganchos de seguimiento de transferencia personalizados. En orden
Además de visualizar información de registro significativa, puede ejecutar el programa como
modo:

NS_LOG=LteEnbRrc:LteUeRrc:EpcX2 ./waf --ejecutar lena-x2-handover

Frecuencia Reutilizar Algoritmos
En esta sección describiremos cómo utilizar algoritmos de reutilización de frecuencia en eNb dentro de LTE.
simulaciones. Hay dos formas posibles de configuración. El primer enfoque es el
"manual", requiere que se configuren más parámetros, pero permite al usuario configurar FR
algoritmo que él/ella necesite. El segundo enfoque es más "automático". Es muy conveniente,
porque es el mismo para cada algoritmo FR, por lo que el usuario puede cambiar el algoritmo FR muy rápidamente
cambiando solo el tipo de algoritmo FR. Un inconveniente es que el enfoque "automático" utiliza sólo
conjunto limitado de configuraciones para cada algoritmo, lo que lo hace menos flexible, pero es
suficiente para la mayoría de los casos.

Estos dos enfoques se describirán con más detalle en la siguiente subsección.

Si el usuario no configura el algoritmo de reutilización de frecuencia, utilice uno predeterminado (es decir, LteFrNoOpAlgorithm)
Está instalado en eNb. Actúa como si el algoritmo FR estuviera deshabilitado.

Una cosa que debe mencionarse es que la mayoría de los algoritmos FR implementados funcionan con
ancho de banda celular mayor o igual a 15 RB. Esta limitación se debe al requisito de que
al menos tres RB continuos deben asignarse al UE para su transmisión.

Manual configuración
El algoritmo de reutilización de frecuencia se puede configurar "manualmente" dentro del programa de simulación mediante
configuración del tipo de algoritmo FR y todos sus atributos. Actualmente, siete algoritmos FR son
implementado:

· ns3::LteFrNoOpAlgoritmo

· ns3::LteFrHardAlgoritmo

· ns3::LteFrStrictAlgoritmo

· ns3::LteFrSoftAlgoritmo

· ns3::LteFfrSoftAlgoritmo

· ns3::LteFfrAlgoritmo mejorado

· ns3::LteFfrDistributedAlgoritmo

La selección de un algoritmo FR se realiza a través del LteHelper objeto y su Establecer tipo de algoritmo Ffr
método como se muestra a continuación:

Ptr lteHelper = CrearObjeto ();
lteHelper->SetFfrAlgorithmType ("ns3::LteFrHardAlgorithm");

Cada algoritmo FR implementado proporciona varios atributos configurables. Los usuarios no tienen
preocuparse por la configuración del ancho de banda UL y DL, porque se realiza automáticamente durante
configuración celular. Para cambiar el ancho de banda para el algoritmo FR, configure los valores requeridos para
Dispositivo LteEnbNet:

uint8_t ancho de banda = 100;
lteHelper->SetEnbDeviceAttribute ("DlBandwidth", UintegerValue (ancho de banda));
lteHelper->SetEnbDeviceAttribute ("UlBandwidth", UintegerValue (ancho de banda));

Ahora, se describirá cada configuración de algoritmos FR.

Difícil Frecuencia Reutilizar Algoritmo
Como se describe en la Sección sec-fr-hard-algoritmo de la Documentación de Diseño
ns3::LteFrHardAlgoritmo utiliza una subbanda. Para configurar esta subbanda el usuario debe especificar
desplazamiento y ancho de banda para DL y UL en número de RB.

El algoritmo de reutilización de frecuencia dura proporciona los siguientes atributos:

· DlSubBandOffset: Desplazamiento del enlace descendente en número de grupos de bloques de recursos

· DlSubancho de banda: Configuración del subancho de banda de transmisión de enlace descendente en número de
Grupos de bloques de recursos

· Desplazamiento de subbanda Ul: Compensación de enlace ascendente en número de grupos de bloques de recursos

· Ancho de banda UlSub: Configuración del subancho de banda de transmisión de enlace ascendente en número de recursos
Grupos de bloques

La configuración de ejemplo de LteFrHardAlgorithm se puede realizar de la siguiente manera:

lteHelper->SetFfrAlgorithmType ("ns3::LteFrHardAlgorithm");
lteHelper->SetFfrAlgorithmAttribute ("DlSubBandOffset", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute ("DlSubBandwidth", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute ("UlSubBandOffset", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute ("UlSubBandwidth", UintegerValue (8));
NetDeviceContainer enbDevs = lteHelper->InstallEnbDevice (enbNodes.Get(0));

El ejemplo anterior permite que eNB use solo RB de 8 a 16 en DL y UL, mientras que toda la celda
el ancho de banda es 25.

Estricto Frecuencia Reutilizar Algoritmo
El algoritmo estricto de reutilización de frecuencia utiliza dos subbandas: una común para cada celda y otra
privado. También existe un umbral RSRQ, que es necesario para decidir dentro de qué subbanda UE
debe ser servido. Además, la transmisión de energía en estas subbandas puede ser diferente.

El algoritmo estricto de reutilización de frecuencia proporciona los siguientes atributos:

· UlCommonSubAncho de banda: Configuración de subancho de banda común de enlace ascendente en número de recursos
Grupos de bloques

· UlEdgeSubBandOffset: Compensación de subbanda de borde de enlace ascendente en número de grupos de bloques de recursos

· UlEdgeSubAncho de banda: Configuración del subancho de banda del borde del enlace ascendente en número de recursos
Grupos de bloques

· DlCommonSubAncho de banda: Configuración de subancho de banda común de enlace descendente en número de
Grupos de bloques de recursos

· DlEdgeSubBandOffset: Desplazamiento de subbanda de borde de enlace descendente en número de grupos de bloques de recursos

· DlEdgeSubAncho de banda: Configuración del subancho de banda del borde del enlace descendente en número de recursos
Grupos de bloques

· Umbral Rsrq: Si el RSRQ de es peor que este umbral, UE debe recibir servicio en
subbanda de borde

· CenterPowerOffset: PdschConfigDedicated::Valor Pa para la subbanda central, valor predeterminado
dB0. XNUMX. XNUMX

· EdgePowerOffset: PdschConfigDedicated::Valor Pa para la subbanda de borde, valor predeterminado dB0

· ÁreaCentroTpc: Valor de TPC que se establecerá en DL-DCI para UE en el área central, Absoluto
Se utiliza el modo, el valor predeterminado 1 se asigna a -1 según TS36.213 Tabla 5.1.1.1-2

· BordeÁreaTpc: Valor de TPC que se establecerá en DL-DCI para UE en el área del borde, Absoluto
Se utiliza el modo, el valor predeterminado 1 se asigna a -1 según TS36.213 Tabla 5.1.1.1-2

El siguiente ejemplo permite que eNB utilice RB de 0 a 6 como subbanda común y de 12 a 18 como
subbanda privada en DL y UL, el umbral RSRQ es de 20 dB, la potencia en el área central es igual
LteEnbPhy::TxPower - 3dB, la potencia en el área del borde es igual LteEnbPhy::TxPower + 3dB:

lteHelper->SetFfrAlgorithmType ("ns3::LteFrStrictAlgorithm");
lteHelper->SetFfrAlgorithmAttribute ("DlCommonSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("UlCommonSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("DlEdgeSubBandOffset", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("DlEdgeSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("UlEdgeSubBandOffset", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("UlEdgeSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("RsrqThreshold", UintegerValue (20));
lteHelper->SetFfrAlgorithmAttribute ("CenterPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB_3));
lteHelper->SetFfrAlgorithmAttribute ("EdgePowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB3));
lteHelper->SetFfrAlgorithmAttribute ("CenterAreaTpc", UintegerValue (1));
lteHelper->SetFfrAlgorithmAttribute ("EdgeAreaTpc", UintegerValue (2));
NetDeviceContainer enbDevs = lteHelper->InstallEnbDevice (enbNodes.Get(0));

Soft Frecuencia Reutilizar Algoritmo
Con el algoritmo de reutilización de frecuencia suave, eNb utiliza todo el ancho de banda de la celda, pero hay dos
Las subbandas, dentro de los UE, se sirven con diferentes niveles de potencia.

El algoritmo de reutilización de frecuencia suave proporciona los siguientes atributos:

· UlEdgeSubBandOffset: Compensación de subbanda de borde de enlace ascendente en número de grupos de bloques de recursos

· UlEdgeSubAncho de banda: Configuración del subancho de banda del borde del enlace ascendente en número de recursos
Grupos de bloques

· DlEdgeSubBandOffset: Desplazamiento de subbanda de borde de enlace descendente en número de grupos de bloques de recursos

· DlEdgeSubAncho de banda: Configuración del subancho de banda del borde del enlace descendente en número de recursos
Grupos de bloques

· AllowCenterUeUseEdgeSubBand: Si los verdaderos UE centrales pueden recibir RBG de subbanda de borde,
de lo contrario, la subbanda de borde solo se permite para UE de borde; el valor predeterminado es verdadero

· Umbral Rsrq: Si el RSRQ de es peor que este umbral, UE debe recibir servicio en
subbanda de borde

· CenterPowerOffset: PdschConfigDedicated::Valor Pa para la subbanda central, valor predeterminado
dB0. XNUMX. XNUMX

· EdgePowerOffset: PdschConfigDedicated::Valor Pa para la subbanda de borde, valor predeterminado dB0

· ÁreaCentroTpc: Valor de TPC que se establecerá en DL-DCI para UE en el área central, Absoluto
Se utiliza el modo, el valor predeterminado 1 se asigna a -1 según TS36.213 Tabla 5.1.1.1-2

· BordeÁreaTpc: Valor de TPC que se establecerá en DL-DCI para UE en el área del borde, Absoluto
Se utiliza el modo, el valor predeterminado 1 se asigna a -1 según TS36.213 Tabla 5.1.1.1-2

El siguiente ejemplo configura los RB del 8 al 16 para ser utilizados por los UE de borde de celda y esta subbanda es
no disponible para usuarios del centro celular. El umbral RSRQ es de 20 dB, la potencia en el área central es igual
LteEnbPhy::TxPower, la potencia en el área del borde es igual LteEnbPhy::TxPower + 3dB:

lteHelper->SetFfrAlgorithmType ("ns3::LteFrSoftAlgorithm");
lteHelper->SetFfrAlgorithmAttribute ("DlEdgeSubBandOffset", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute ("DlEdgeSubBandwidth", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute ("UlEdgeSubBandOffset", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute ("UlEdgeSubBandwidth", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute ("AllowCenterUeUseEdgeSubBand", BooleanValue (falso));
lteHelper->SetFfrAlgorithmAttribute ("RsrqThreshold", UintegerValue (20));
lteHelper->SetFfrAlgorithmAttribute ("CenterPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB0));
lteHelper->SetFfrAlgorithmAttribute ("EdgePowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB3));
NetDeviceContainer enbDevs = lteHelper->InstallEnbDevice (enbNodes.Get(0));

Soft Fraccionario Frecuencia Reutilizar Algoritmo
La reutilización de frecuencia fraccional suave (SFFR) utiliza tres subbandas: central, media (común) y
borde. El usuario debe configurar sólo dos de ellos: común y de borde. La subbanda central será
compuesto del ancho de banda restante. Cada subbanda puede ser atendida con diferentes
poder de transmision. Dado que hay tres subbandas, es necesario establecer dos umbrales RSRQ.
configurado.

El algoritmo de reutilización de frecuencia fraccional suave proporciona los siguientes atributos:

· UlCommonSubAncho de banda: Configuración de subancho de banda común de enlace ascendente en número de recursos
Grupos de bloques

· UlEdgeSubBandOffset: Compensación de subbanda de borde de enlace ascendente en número de grupos de bloques de recursos

· UlEdgeSubAncho de banda: Configuración del subancho de banda del borde del enlace ascendente en número de recursos
Grupos de bloques

· DlCommonSubAncho de banda: Configuración de subancho de banda común de enlace descendente en número de
Grupos de bloques de recursos

· DlEdgeSubBandOffset: Desplazamiento de subbanda de borde de enlace descendente en número de grupos de bloques de recursos

· DlEdgeSubAncho de banda: Configuración del subancho de banda del borde del enlace descendente en número de recursos
Grupos de bloques

· CentroRsrqUmbral: Si el RSRQ de es peor que este umbral, se debe atender a UE
en subbanda media

· BordeRsrqUmbral: Si el RSRQ de es peor que este umbral, se debe atender a UE
en la subbanda de borde

· CenterAreaPowerOffset: PdschConfigDedicated::Valor Pa para la subbanda central, predeterminado
valor dB0

· Compensación de potencia de área media: PdschConfigDedicated::Valor Pa para subbanda media, predeterminado
valor dB0

· EdgeAreaPowerOffset: PdschConfigDedicated::Valor Pa para la subbanda de borde, valor predeterminado
dB0. XNUMX. XNUMX

· ÁreaCentroTpc: Valor de TPC que se establecerá en DL-DCI para UE en el área central, Absoluto
Se utiliza el modo, el valor predeterminado 1 se asigna a -1 según TS36.213 Tabla 5.1.1.1-2

· Tpc de área media: Valor de TPC que se establecerá en DL-DCI para UE en área media, Absoluto
Se utiliza el modo, el valor predeterminado 1 se asigna a -1 según TS36.213 Tabla 5.1.1.1-2

· BordeÁreaTpc: Valor de TPC que se establecerá en DL-DCI para UE en el área del borde, Absoluto
Se utiliza el modo, el valor predeterminado 1 se asigna a -1 según TS36.213 Tabla 5.1.1.1-2

En el ejemplo siguiente, los RB de 0 a 6 se utilizarán como subbanda común (media), los RB de 6 a
12 se utilizará como subbanda de borde y los RB del 12 al 24 se utilizarán como subbanda central (no
está compuesto por los RB restantes). El umbral RSRQ entre el área central y media es de 28 dB,
El umbral RSRQ entre el área media y el borde es de 18 dB. La potencia en el área central es igual
LteEnbPhy::TxPower - 3dB, la potencia en área media es igual LteEnbPhy::TxPower + 3dB, poder en
área del borde es igual LteEnbPhy::TxPower + 3dB:

lteHelper->SetFfrAlgorithmType ("ns3::LteFfrSoftAlgorithm");
lteHelper->SetFfrAlgorithmAttribute ("UlCommonSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("DlCommonSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("DlEdgeSubBandOffset", UintegerValue (0));
lteHelper->SetFfrAlgorithmAttribute ("DlEdgeSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("UlEdgeSubBandOffset", UintegerValue (0));
lteHelper->SetFfrAlgorithmAttribute ("UlEdgeSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("CenterRsrqThreshold", UintegerValue (28));
lteHelper->SetFfrAlgorithmAttribute ("EdgeRsrqThreshold", UintegerValue (18));
lteHelper->SetFfrAlgorithmAttribute ("CenterAreaPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB_3));
lteHelper->SetFfrAlgorithmAttribute ("MediumAreaPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB0));
lteHelper->SetFfrAlgorithmAttribute ("EdgeAreaPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB3));
NetDeviceContainer enbDevs = lteHelper->InstallEnbDevice (enbNodes.Get(0));

Modernizado Fraccionario Frecuencia Reutilizar Algoritmo
La reutilización fraccional de frecuencia mejorada (EFFR) reserva parte del ancho de banda del sistema para cada celda
(normalmente hay 3 tipos de células y cada una obtiene 1/3 del ancho de banda del sistema). Entonces parte de
este subancho de banda lo usó como Primaria Segmento con factor de reutilización 3 y como el folleto de Secundaria Segmento
con factor de reutilización 1. El usuario debe configurar (para DL y UL) el desplazamiento del subancho de banda de la celda
en número de RB, número de RB que se utilizará como Primaria Segmento y número de RB que
será utilizado como el folleto de Secundaria Segmento. Primaria Segmento es utilizado por la célula a voluntad, pero los RB de
el folleto de Secundaria Segmento se puede asignar a UE solo si la retroalimentación CQI de este UE tiene mayor
valor que el umbral CQI configurado. UE se considera UE de borde cuando su RSRQ es menor
than Umbral Rsrq.

Dado que cada eNb necesita saber dónde están los primarios y secundarios de otros tipos de células,
calcularlos asumiendo que la configuración es la misma para cada celda y solo el ancho de subbanda
las compensaciones son diferentes. Por lo tanto, es importante dividir el ancho de banda disponible del sistema en partes iguales
cada celda y aplicarles la misma configuración de Segmentos Primarios y Secundarios.

El algoritmo de reutilización de frecuencia fraccional mejorado proporciona los siguientes atributos:

· Desplazamiento de subbanda Ul: Desplazamiento de subbanda de enlace ascendente para esta celda en número de bloque de recursos
Grupos

· UlReuse3SubAncho de banda: Configuración de subancho de banda de reutilización de enlace ascendente 3 en número de recursos
Grupos de bloques

· UlReuse1SubAncho de banda: Configuración de subancho de banda de reutilización de enlace ascendente 1 en número de recursos
Grupos de bloques

· DlSubBandOffset: Desplazamiento de subbanda de enlace descendente para esta celda en número de bloque de recursos
Grupos

· DlReuse3SubAncho de banda: Configuración de subancho de banda de reutilización de enlace descendente 3 en número de
Grupos de bloques de recursos

· DlReuse1SubAncho de banda: Configuración de subancho de banda de reutilización de enlace descendente 1 en número de
Grupos de bloques de recursos

· Umbral Rsrq: Si el RSRQ de es peor que este umbral, UE debe recibir servicio en
subbanda de borde

· CenterAreaPowerOffset: PdschConfigDedicated::Valor Pa para la subbanda central, predeterminado
valor dB0

· EdgeAreaPowerOffset: PdschConfigDedicated::Valor Pa para la subbanda de borde, valor predeterminado
dB0. XNUMX. XNUMX

· Umbral DlCqi: Si el DL-CQI para RBG es superior a este umbral, la transmisión
en RBG es posible

· Umbral UlCqi: Si el UL-CQI para RBG es superior a este umbral, la transmisión
en RBG es posible

· ÁreaCentroTpc: Valor de TPC que se establecerá en DL-DCI para UE en el área central, Absoluto
Se utiliza el modo, el valor predeterminado 1 se asigna a -1 según TS36.213 Tabla 5.1.1.1-2

· BordeÁreaTpc: Valor de TPC que se establecerá en DL-DCI para UE en el área del borde, Absoluto
Se utiliza el modo, el valor predeterminado 1 se asigna a -1 según TS36.213 Tabla 5.1.1.1-2

En el siguiente ejemplo, el desplazamiento en DL y UL es 0 RB, se utilizará 4 RB en Primaria Segmento y
el folleto de Secundaria Segmento. El umbral RSRQ entre el centro y el borde es de 25 dB. DL y UL CQI
Los umbrales se establecen en un valor de 10. La potencia en el área central es igual LteEnbPhy::TxPower - 6dB,
potencia en el área del borde es igual LteEnbPhy::TxPower + 0dB:

lteHelper->SetFfrAlgorithmType("ns3::LteFfrEnhancedAlgorithm");
lteHelper->SetFfrAlgorithmAttribute("RsrqThreshold", UintegerValue (25));
lteHelper->SetFfrAlgorithmAttribute("DlCqiThreshold", UintegerValue (10));
lteHelper->SetFfrAlgorithmAttribute("UlCqiThreshold", UintegerValue (10));
lteHelper->SetFfrAlgorithmAttribute("CenterAreaPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB_6));
lteHelper->SetFfrAlgorithmAttribute("EdgeAreaPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB0));
lteHelper->SetFfrAlgorithmAttribute("UlSubBandOffset", UintegerValue (0));
lteHelper->SetFfrAlgorithmAttribute("UlReuse3SubBandwidth", UintegerValue (4));
lteHelper->SetFfrAlgorithmAttribute("UlReuse1SubBandwidth", UintegerValue (4));
lteHelper->SetFfrAlgorithmAttribute("DlSubBandOffset", UintegerValue (0));
lteHelper->SetFfrAlgorithmAttribute("DlReuse3SubBandwidth", UintegerValue (4));
lteHelper->SetFfrAlgorithmAttribute("DlReuse1SubBandwidth", UintegerValue (4));

Distributed Fraccionario Frecuencia Reutilizar Algoritmo
La reutilización de frecuencia fraccionaria distribuida requiere que la interfaz X2 entre todos los eNB sea
instalado. Las interfaces X2 solo se pueden instalar cuando se configura EPC, por lo que este esquema FFR
sólo se puede utilizar con escenarios EPC.

Con el algoritmo de reutilización de frecuencia fraccional distribuida, eNb utiliza todo el ancho de banda de la celda y
puede haber dos subbandas: subbanda central y subbanda de borde. Dentro de estas subbandas UE
Se puede servir con diferentes niveles de potencia. El algoritmo selecciona de forma adaptativa los RB para el borde de la celda
subbanda sobre la base de la información de coordinación (es decir, RNTP) de las células adyacentes y notifica
las estaciones base de las celdas adyacentes, qué RB seleccionó para usar en la subbanda de borde. Si
Si no hay ningún UE clasificado como UE de borde en la celda, el eNB no utilizará ningún RB como subbanda de borde.

El algoritmo de reutilización de frecuencia fraccionaria distribuida proporciona los siguientes atributos:

· Intervalo de cálculo: Intervalo de tiempo entre el cálculo de la subbanda Edge, predeterminado
valor 1 segundo

· Umbral Rsrq: Si el RSRQ de es peor que este umbral, UE debe recibir servicio en
subbanda de borde

· RsrpDiferenciaUmbral: Si la diferencia entre la potencia de la señal recibida
por UE desde la celda de servicio y la potencia de la señal recibida desde la celda adyacente
La celda es menor que un valor de RsrpDifferenceThreshold, el peso de la celda se incrementa.

· CenterPowerOffset: PdschConfigDedicated::Valor Pa para la subbanda de borde, valor predeterminado
dB0. XNUMX. XNUMX

· EdgePowerOffset: PdschConfigDedicated::Valor Pa para la subbanda de borde, valor predeterminado dB0

· BordeRbNum: Número de RB que se pueden utilizar en la subbanda de borde

· ÁreaCentroTpc: Valor de TPC que se establecerá en DL-DCI para UE en el área central, Absoluto
Se utiliza el modo, el valor predeterminado 1 se asigna a -1 según TS36.213 Tabla 5.1.1.1-2

· BordeÁreaTpc: Valor de TPC que se establecerá en DL-DCI para UE en el área del borde, Absoluto
Se utiliza el modo, el valor predeterminado 1 se asigna a -1 según TS36.213 Tabla 5.1.1.1-2

En el ejemplo siguiente, el intervalo de cálculo es de 500 ms. Umbral RSRQ entre el centro y el borde
El área es 25. El umbral de diferencia RSRP se establece en 5. En DL y UL 6, RB será utilizado por
cada celda en la subbanda de borde. La potencia en el área central es igual LteEnbPhy::TxPower - 0dB, poder
en el área del borde es igual LteEnbPhy::TxPower + 3dB:

lteHelper->SetFfrAlgorithmType("ns3::LteFfrDistributedAlgorithm");
lteHelper->SetFfrAlgorithmAttribute("CalculationInterval", TimeValue(Milisegundos(500)));
lteHelper->SetFfrAlgorithmAttribute ("RsrqThreshold", UintegerValue (25));
lteHelper->SetFfrAlgorithmAttribute ("RsrpDifferenceThreshold", UintegerValue (5));
lteHelper->SetFfrAlgorithmAttribute ("EdgeRbNum", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("CenterPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB0));
lteHelper->SetFfrAlgorithmAttribute ("EdgePowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB3));

Automático configuración
Los algoritmos de reutilización de frecuencia también se pueden configurar de manera más "automática" configurando solo
el ancho de banda y FrCellTypeId. Durante la inicialización de la instancia FR, la configuración para
establezca el ancho de banda y FrCellTypeId se tomará de la tabla de configuración. Es importante
que solo se configurarán subbandas, los umbrales y la potencia de transmisión se establecerán en
valores predeterminados. Si uno quiere, puede cambiar los umbrales y la potencia de transmisión como se muestra.
en el apartado anterior.

Hay tres FrCellTypeId: 1, 2, 3, que corresponden a tres configuraciones diferentes
para cada ancho de banda. Tres configuraciones permiten tener diferentes configuraciones en
celdas vecinas en diseño eNB hexagonal. Si el usuario necesita tener más diferentes
configuración para celdas vecinas, él/ella necesita usar la configuración manual.

El siguiente ejemplo muestra la configuración automática del algoritmo FR:

lteHelper->SetFfrAlgorithmType("ns3::LteFfrSoftAlgorithm");
lteHelper->SetFfrAlgorithmAttribute("FrCellTypeId", UintegerValue (1));
NetDeviceContainer enbDevs = lteHelper->InstallEnbDevice (enbNodes.Get(0));

Uplink Potencia Control:
La funcionalidad de control de energía del enlace ascendente está habilitada de forma predeterminada. El usuario puede desactivarlo configurando
el atributo booleano ns3::LteUePhy::EnableUplinkPowerControl a la verdad

El usuario puede cambiar entre los mecanismos de control de potencia de circuito abierto y control de potencia de circuito cerrado.
estableciendo el atributo booleano ns3::LteUePowerControl::ClosedLoop. Cerrado por defecto
El control de potencia de bucle con modo de acumulación está habilitado.

La pérdida de ruta es un componente clave del control de energía del enlace ascendente. Se calcula como la diferencia entre
RSRP filtrado y parámetro ReferenceSignalPower. ReferenceSignalPower se envía con SIB2.

Atributos disponibles en Uplink Power Control:

· Bucle cerrado: si el modo de control de potencia de enlace ascendente de bucle cerrado verdadero está habilitado y el modo de bucle abierto
Control de energía de lo contrario, el valor predeterminado es falso

· Acumulación habilitada: si el Modo Acumulación verdadero está habilitado y el modo Absoluto
de lo contrario, el valor predeterminado es falso

· Alpha: el factor de compensación de pérdida de ruta, el valor predeterminado es 1.0

· Pcmín: UE TxPower mínima, el valor predeterminado es -40 dBm

· pcmax: UE TxPower máxima, el valor predeterminado es 23 dBm

· PoNominalPusch: este parámetro debería ser establecido por capas superiores, pero actualmente necesita
para ser configurado por sistema de atributos, los valores posibles son números enteros en el rango (-126...
24), el valor predeterminado es -80

· PoUePusch: este parámetro debe ser establecido por capas superiores, pero actualmente es necesario
ser configurado por sistema de atributos, los valores posibles son números enteros en el rango (-8 ... 7),
El valor predeterminado es 0

· PsrsCompensación: este parámetro debe ser establecido por capas superiores, pero actualmente es necesario
ser configurado por sistema de atributos, los valores posibles son números enteros en el rango (0 ... 15),
El valor predeterminado es 7, lo que da P_Srs_Offset_Value = 0

trazada valores in Uplink Potencia Controlar:

· InformePuschTxPower: UE TxPower actual para PUSCH

· InformePucchTxPower: UE TxPower actual para PUCCH

· InformeSrsTxPower: UE TxPower actual para SRS

A continuación se presenta un ejemplo de configuración:

Config::SetDefault ("ns3::LteUePhy::EnableUplinkPowerControl", BooleanValue (verdadero));
Config::SetDefault ("ns3::LteEnbPhy::TxPower", DoubleValue (30));
Config::SetDefault ("ns3::LteUePowerControl::ClosedLoop", BooleanValue (verdadero));
Config::SetDefault ("ns3::LteUePowerControl::AccumulationEnabled", BooleanValue (verdadero));

Como ejemplo, el usuario puede echar un vistazo y ejecutar el programa lena-uplink-power-control.

Ejemplos Programas
El directorio src/lte/ejemplos/ contiene algunos programas de simulación de ejemplo que muestran cómo
simular diferentes escenarios LTE.

Referencias escenarios
Existe una gran cantidad de escenarios de simulación LTE de referencia que se pueden encontrar en la
literatura. A continuación te enumeramos algunos de ellos:

· Los escenarios de simulación del sistema mencionados en el apartado A.2 de [TR36814].

· El modelo de doble banda [R4-092042], que se implementa parcialmente en el ejemplo
programa src/lte/examples/lena-dual-stripe.cc. Este programa de ejemplo presenta una gran cantidad de
Parámetros configurables que se pueden personalizar cambiando el parámetro global correspondiente.
variables. Para obtener una lista de todas estas variables globales, puede ejecutar este comando:

./waf --run lena-dual-stripe --command-template="%s --PrintGlobals"

La siguiente subsección presenta un ejemplo de ejecución de una campaña de simulación utilizando
este programa de ejemplo.

Entregar simulación campaña
En esta subsección, demostraremos un ejemplo de cómo ejecutar una campaña de simulación utilizando
el módulo LTE de ns-3. El objetivo de la campaña es comparar el efecto de cada
Algoritmo de transferencia incorporado del módulo LTE.

La campaña utilizará el lena-doble-raya programa de ejemplo. Primero, tenemos que modificar el
programa de ejemplo para producir el resultado que necesitamos. En esta ocasión queremos producir
el número de traspasos, el rendimiento promedio del usuario y el SINR promedio.

El número de traspasos se puede obtener contando el número de veces que EntregaEndOk
Entregar huellas Está despedido. Luego, el rendimiento promedio del usuario se puede obtener habilitando el
RLC Simulación Salida. Finalmente, SINR se puede obtener habilitando la simulación PHY.
producción. El siguiente fragmento de código de muestra muestra una forma posible de obtener lo anterior:

vacío
NotifyHandoverEndOkUe (std::string context, uint64_t imsi,
uint16_t cellId, uint16_t rnti)
{
std::cout << "Transferencia IMSI " << imsi << std::endl;
}

int
principal (int argc, char * argv [])
{
/*** CORTE ***/

Config::Connect ("/NodeList/*/DeviceList/*/LteUeRrc/HandoverEndOk",
MakeCallback (&NotifyHandoverEndOkUe));

lteHelper->EnablePhyTraces ();
lteHelper->EnableRlcTraces ();
Ptr rlcStats = lteHelper->GetRlcStats ();
rlcStats->SetAttribute ("StartTime", TimeValue (Segundos (0)));
rlcStats->SetAttribute ("EpochDuration", TimeValue (Segundos (simTime)));

Simulador::Ejecutar ();
Simulador::Destruir ();
0 regresar;
}

Luego tenemos que configurar los parámetros del programa para que se adapte a nuestras necesidades de simulación. Nosotros
Estamos buscando las siguientes suposiciones en nuestra simulación:

· 7 sitios de macro eNodeB trisectoriales (es decir, 21 macrocélulas) desplegados en forma hexagonal
Distribución con 500 m de distancia entre sitios.

· A pesar de lena-doble-raya está originalmente destinado a dos niveles (macrocélula y
femtocelda), simplificaremos nuestra simulación a un nivel (macrocelda)
Sólo simulación.

· Los UE se distribuyen aleatoriamente entre los sitios y se conectan a la red automáticamente
utilizando la selección de celdas en modo inactivo. Después de eso, UE recorrerá el entorno de simulación.
con una velocidad de movimiento de 60 kmph.

· Duración de la simulación de 50 segundos, por lo que los UE habrían viajado lo suficientemente lejos como para activar algunos
traspasos

· Potencia Tx de macrocelda de 46 dBm y potencia de Tx UE de 10 dBm.

· Se utilizará el modo EPC porque el procedimiento de transferencia X2 requiere que esté habilitado.

· Tráfico de enlace descendente y ascendente con búfer completo, ambos en ancho de banda de 5 MHz, utilizando el protocolo TCP
y programador de Feria Proporcional.

· Protocolo ideal RRC.

Tabla lena-doble-raya parámetro configuración para entregar campaña A continuación se muestra cómo
configurar los parámetros de lena-doble-raya para lograr los supuestos anteriores.

lena-doble-raya parámetro configuración para entregar campaña
┌───────────────────┬─────────┬───────── ────────── ───────┐
│Nombre del parámetro │ Valor │ Descripción │
├───────────────────┼─────────┼───────── ────────── ───────┤
│simTime │ 50 │ Simulación de 50 segundos │
│ │ │ duración │
├───────────────────┼─────────┼───────── ────────── ───────┤
│nBloques │ 0 │ Inhabilitar apartamento │
│ │ │ edificios y femtoceldas │
├───────────────────┼─────────┼───────── ────────── ───────┤
│nMacroEnbSites │ 7 │ Número de macrocelda │
│ │ │ sitios (cada sitio tiene 3 │
│ │ │ celdas) │
├───────────────────┼─────────┼───────── ────────── ───────┤
│nMacroEnbSitesX │ 2 │ Los sitios de macrocélula │
│ │ │ posicionarse en un 2-3-2 │
│ │ │ formación │
├───────────────────┼─────────┼───────── ────────── ───────┤
│interSiteDistance │ 500 │ 500 m de distancia entre │
│ │ │ sitios de macrocélulas adyacentes │
├───────────────────┼─────────┼───────── ────────── ───────┤
│macroEnbTxPowerDbm │ 46 │ 46 dBm de potencia de transmisión para cada │
│ │ │ macrocélula │
├───────────────────┼─────────┼───────── ────────── ───────┤
│epc │ 1 │ Habilitar modo EPC │
└───────────────────┴─────────┴───────── ────────── ───────┘

│epcDl │ 1 │ Habilitar DL de búfer completo │
│ │ │ tráfico │
├───────────────────┼─────────┼───────── ────────── ───────┤
│epcUl │ 1 │ Habilitar UL de búfer completo │
│ │ │ tráfico │
├───────────────────┼─────────┼───────── ────────── ───────┤
│useUdp │ 0 │ Deshabilitar el tráfico UDP y │
│ │ │ habilite TCP en su lugar │
├───────────────────┼─────────┼───────── ────────── ───────┤
│macroUeDensity │ 0.00002 │ Determina el número de UE │
│ │ │ (se traduce en 48 UE en │
│ │ │ nuestra simulación) │
├───────────────────┼─────────┼───────── ────────── ───────┤
│outdoorUeMinSpeed ​​│ 16.6667 │ Movimiento mínimo de UE │
│ │ │ velocidad en m/s (60 kmph) │
├───────────────────┼─────────┼───────── ────────── ───────┤
│outdoorUeMaxSpeed ​​│ 16.6667 │ Movimiento UE máximo │
│ │ │ velocidad en m/s (60 kmph) │
├───────────────────┼─────────┼───────── ────────── ───────┤
│macroEnbAncho de banda │ 25 │ 5 MHz DL y UL │
│ │ │ ancho de banda │
├───────────────────┼─────────┼───────── ────────── ───────┤
│generateRem │ 1 │ (Opcional) Para trazar │
│ │ │ el entorno radiofónico │
│ │ │ Mapa │
└───────────────────┴─────────┴───────── ────────── ───────┘

Algunos de los supuestos requeridos no están disponibles como parámetros de lena-doble-raya. En
En este caso, anulamos los atributos predeterminados, como se muestra en la Tabla Primordial tu préstamo estudiantil
atributos para entregar campaña abajo.

Primordial tu préstamo estudiantil atributos para entregar campaña
┌─────────────────────────────────────── ────────── ────┬────────────────────────────────┬── ────────── ──────────────┐
├─────────────────────────────────────── ────────── ────┼────────────────────────────────┼── ────────── ──────────────┤
│ns3::LteHelper::Algoritmo de transferencia │ ns3::Algoritmo NoOpHandover, │ Elección de la entrega │
│ │ ns3::A3RsrpAlgoritmo de transferencia, │ algoritmo │
│ │ ns3::A2A4RsrqAlgoritmo de transferencia │ │
├─────────────────────────────────────── ────────── ────┼────────────────────────────────┼── ────────── ──────────────┤
│ns3::LteHelper::Programador │ ns3::PfFfMacScheduler │ Justo Proporcional │
├─────────────────────────────────────── ────────── ────┼────────────────────────────────┼── ────────── ──────────────┤
├─────────────────────────────────────── ────────── ────┼────────────────────────────────┼── ────────── ──────────────┤
│ns3::RadioBearerStatsCalculator::DlRlcOutputFilename │ -DlRlcStats.txt │ Nombre de archivo para DL RLC │
├─────────────────────────────────────── ────────── ────┼────────────────────────────────┼── ────────── ──────────────┤
│ns3::RadioBearerStatsCalculator::UlRlcOutputFilename │ -UlRlcStats.txt │ Nombre de archivo para UL RLC │
├─────────────────────────────────────── ────────── ────┼────────────────────────────────┼── ────────── ──────────────┤
│ns3::PhyStatsCalculator::DlRsrpSinrFilename │ -DlRsrpSinrStats.txt │ Nombre de archivo para DL PHY │
├─────────────────────────────────────── ────────── ────┼────────────────────────────────┼── ────────── ──────────────┤
│ns3::PhyStatsCalculator::UlSinrFilename │ -UlSinrStats.txt │ Nombre de archivo para UL PHY │
└─────────────────────────────────────── ────────── ────┴────────────────────────────────┴── ────────── ──────────────┘

ns-3 proporciona muchas formas de pasar valores de configuración a una simulación. En esto
Por ejemplo, usaremos los argumentos de la línea de comando. Básicamente se hace añadiendo el
parámetros y sus valores al waf llamar al iniciar cada simulación individual. Entonces
los waf Las llamadas para invocar nuestras 3 simulaciones se verían como se muestra a continuación:

$ ./waf --run="lena-doble-banda
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::HandoverAlgorithm=ns3::NoOpHandoverAlgorithm
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=no-op-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=no-op-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrFilename=no-op-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=no-op-UlSinrStats.txt
--RngRun=1" > no-op.txt

$ ./waf --run="lena-doble-banda
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::HandoverAlgorithm=ns3::A3RsrpHandoverAlgorithm
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=a3-rsrp-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=a3-rsrp-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrFilename=a3-rsrp-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=a3-rsrp-UlSinrStats.txt
--RngRun=1" > a3-rsrp.txt

$ ./waf --run="lena-doble-banda
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::Algoritmo de entrega=ns3::A2A4RsrqAlgoritmo de entrega
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=a2-a4-rsrq-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=a2-a4-rsrq-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrFilename=a2-a4-rsrq-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=a2-a4-rsrq-UlSinrStats.txt
--RngRun=1" > a2-a4-rsrq.txt

Algunas notas sobre la ejecución:

· Observe que algunos argumentos no se especifican porque ya son los mismos que el
valores predeterminados. También mantenemos los algoritmos de transferencia en la configuración predeterminada de cada uno.

· Tenga en cuenta los nombres de los archivos de salida de la simulación, por ejemplo, trazas RLC y trazas PHY, porque
debe asegurarse de que no se sobrescriban en la siguiente ejecución de simulación. En esto
Por ejemplo, especificamos los nombres uno por uno usando los argumentos de la línea de comando.

· Los --RngRun=1 El argumento al final se utiliza para establecer el número de ejecución utilizado por el
Generador de números aleatorios utilizado en la simulación. Volvemos a ejecutar las mismas simulaciones con
una experiencia diferente RngRun valores, creando así varias réplicas independientes del mismo
simulaciones. Luego promediamos los resultados obtenidos de estas replicaciones para lograr
cierta confianza estadística.

· Podemos agregar un --generarRem=1 argumento para generar los archivos necesarios para generar
el Mapa de Entorno Radioeléctrico (REM) de la simulación. El resultado es la figura REM obtenido
Desde a simulación in entregar campaña a continuación, que se puede producir siguiendo las
pasos descritos en la Sección Radio Medio Ambiente Mapas. Esta figura también muestra la
Posición de los eNodeB y UE al comienzo de una simulación utilizando RngRun = 1. Otro
valores de RngRun puede producir una posición diferente del UE.
[imagen] REM obtenido de una simulación en campaña de traspaso.UNINDENT

Después de horas de ejecución, la campaña de simulación finalmente terminará. A continuación lo haremos
realizar algún posprocesamiento en la salida de simulación producida para obtener información significativa
información fuera de ella.

En este ejemplo, utilizamos GNU Octave para ayudar en el procesamiento de datos SINR y de rendimiento.
como se demuestra en un script de muestra de GNU Octave a continuación:

% RxBytes es la décima columna
DlRxBytes = cargar ("no-op-DlRlcStats.txt") (:,10);
DlAverageThroughputKbps = suma (DlRxBytes) * 8/1000/50

% RxBytes es la décima columna
UlRxBytes = cargar ("no-op-UlRlcStats.txt") (:,10);
UlAverageThroughputKbps = suma (UlRxBytes) * 8/1000/50

% Sinr es la sexta columna
DlSinr = cargar ("no-op-DlRsrpSinrStats.txt") (:,6);
% eliminar valores de NaN
idx = isnan (DlSinr);
DlSinr (idx) = 0;
DlAverageSinrDb = 10 * log10 (media (DlSinr)) % convertido a dB

% Sinr es la sexta columna
UlSinr = cargar ("no-op-UlSinrStats.txt") (:,5);
% eliminar valores de NaN
idx = isnan (UlSinr);
UlSinr (idx) = 0;
UlAverageSinrDb = 10 * log10 (media (UlSinr)) % convertido a dB

En cuanto al número de traspasos, podemos utilizar scripts de shell simples para contar el número de
apariciones de la cadena "Handover" en el archivo de registro:

$ grep "Entrega" no-op.txt | baño -l

Tabla Resultados of entregar campaña A continuación se muestran las estadísticas completas una vez que hayamos terminado.
con posprocesamiento en cada ejecución de simulación individual. Los valores mostrados son el promedio.
de los resultados obtenidos de RngRun de 1, 2, 3 y 4.

Resultados of entregar campaña
┌────────────────────┬────────────┬───── ────────┬─ ───────────────┐
│Estadísticas │ No-op │ A2-A4-RSRQ │ Célula más fuerte │
├────────────────────┼────────────┼───── ────────┼─ ───────────────┤
│Sistema DL promedio │ 6 615 kbps │ 20 509 kbps │ 19 709 kbps │
│rendimiento │ │ │ │
├────────────────────┼────────────┼───── ────────┼─ ───────────────┤
│Sistema UL promedio │ 4 095 kbps │ 5 705 kbps │ 6 627 kbps │
│rendimiento │ │ │ │
├────────────────────┼────────────┼───── ────────┼─ ───────────────┤
│SINR DL promedio │ -0.10 dB │ 5.19 dB │ 5.24 dB │
├────────────────────┼────────────┼───── ────────┼─ ───────────────┤
│SINR UL promedio │ 9.54 dB │ 81.57 dB │ 79.65 dB │
├────────────────────┼────────────┼───── ────────┼─ ───────────────┤
│Número de traspasos │ 0 │ 0.05694 │ 0.04771 │
│por UE por segundo │ │ │ │
└────────────────────┴────────────┴───── ────────┴─ ───────────────┘

Los resultados muestran que tener un algoritmo de traspaso en una simulación de movilidad mejora tanto
el rendimiento del usuario y SINR significativamente. Hay poca diferencia entre los dos.
Algoritmos de traspaso en este escenario de campaña. Sería interesante ver sus
rendimiento en diferentes escenarios, como escenarios con implementación de eNodeB domésticos.

Frecuencia Reutilizar ejemplos
Hay dos ejemplos que muestran la funcionalidad de algoritmos de reutilización de frecuencia.

reutilización-de-frecuencia-lena Es un ejemplo sencillo con 3 eNB en disposición triangular. Hay 3 celdas
UE de borde, que están ubicados en el centro de este triángulo y 3 UE de centro de celda (uno cerca
cada eNB). El usuario también puede especificar el número de UE ubicados aleatoriamente. El algoritmo FR es
instalado en los eNB y cada eNB tiene un FrCellTypeId diferente, lo que significa que cada eNB utiliza
configuración FR diferente. El usuario puede ejecutar reutilización-de-frecuencia-lena con 6 FR diferentes
algoritmos: NoOp, Hard FR, Strict FR, Soft FR, Soft FFR y Enhanced FFR. Para ejecutar el escenario
con el algoritmo FFR distribuido, el usuario debe utilizar lena-distribuida-ffr. Estos dos ejemplos
son muy similares, pero se dividieron porque el FFR distribuido requiere el uso de EPC,
y otros algoritmos no.

Correr reutilización-de-frecuencia-lena con diferentes algoritmos de reutilización de frecuencia, el usuario debe
especificar el algoritmo FR anulando el atributo predeterminado ns3::LteHelper::FfrAlgoritmo.
Comando de ejemplo para ejecutar reutilización-de-frecuencia-lena con el algoritmo Soft FR se presenta a continuación:

$ ./waf --run "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFrSoftAlgorithm"

En estos ejemplos se agregó la funcionalidad para generar REM y traza del analizador de espectro.
El usuario puede habilitar la generación del mismo configurando generarRem y generarSpectrumTrace
los atributos.

Comando para generar REM para RB 1 en el canal de datos desde reutilización-de-frecuencia-lena escenario con
El algoritmo Soft FR se presenta a continuación:

$ ./waf --run "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFrSoftAlgorithm
--generateRem=true --remRbId=1"

El mapa del entorno de radio para Soft FR se presenta en la figura REM para RB 1 obtenido Desde
reutilización-de-frecuencia-lena (aqui) con Soft FR algoritmo facilita.
[imagen] REM para RB 1 obtenido de reutilización-de-frecuencia-lena ejemplo con algoritmo Soft FR
habilitado.UNINDENT

Comando para generar traza de espectro desde reutilización-de-frecuencia-lena escenario con FFR suave
El algoritmo se presenta a continuación (la posición del analizador de espectro debe configurarse dentro
texto):

$ ./waf --run "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFfrSoftAlgorithm
--generateSpectrumTrace=verdadero"

En la figura se presenta un ejemplo de traza del analizador de espectro. Spectrum Analyzer rastrear obtenido
Desde reutilización-de-frecuencia-lena (aqui) con Soft FFR algoritmo habilitada. Spectrum Analyzer iba
situados necesite eNB con FrCellTypeId 2.. Como puede verse, diferentes subbandas de canales de datos
se envían con distinto nivel de potencia (según configuración), mientras que el canal de control
transmitido con potencia uniforme a lo largo de todo el ancho de banda del sistema.
[imagen] Traza del analizador de espectro obtenida de reutilización-de-frecuencia-lena ejemplo con FFR suave
algoritmo habilitado. Se ubicó el analizador de espectro y se necesita eNB con FrCellTypeId 2..UNINDENT

lena-doble-raya También se puede ejecutar con algoritmos de reutilización de frecuencia instalados en todas las macros.
eNB. El usuario debe especificar el algoritmo FR anulando el atributo predeterminado
ns3::LteHelper::FfrAlgoritmo. Comando de ejemplo para ejecutar lena-doble-raya con FR duro
El algoritmo se presenta a continuación:

$ ./waf --run="lena-doble-banda
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::HandoverAlgorithm=ns3::NoOpHandoverAlgorithm
--ns3::LteHelper::FfrAlgorithm=ns3::LteFrHardAlgoritmo
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=no-op-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=no-op-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrFilename=no-op-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=no-op-UlSinrStats.txt
--RngRun=1" > no-op.txt

Comando de ejemplo para generar REM para RB 1 en el canal de datos desde lena-doble-raya guión
con el algoritmo Hard FR se presenta a continuación:

$ ./waf --run="lena-doble-banda
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=0 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::HandoverAlgorithm=ns3::NoOpHandoverAlgorithm
--ns3::LteHelper::FfrAlgorithm=ns3::LteFrHardAlgoritmo
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=no-op-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=no-op-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrFilename=no-op-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=no-op-UlSinrStats.txt
--RngRun=1 --generateRem=true --remRbId=1" > no-op.txt

Mapas de entorno de radio para RB 1, 10 y 20 generados a partir de lena-doble-raya escenario con
El algoritmo de reutilización de frecuencias estrictas se presenta en las figuras siguientes. Estos RB fueron seleccionados
porque cada uno es utilizado por diferentes tipos de células FR.
[imagen] REM para RB 1 obtenido de lena-doble-raya simulación con algoritmo Hard FR
habilitado.UNINDENT
[imagen] REM para RB 10 obtenido de lena-doble-raya simulación con algoritmo Hard FR
habilitado.UNINDENT
[imagen] REM para RB 20 obtenido de lena-doble-raya simulación con algoritmo Hard FR
habilitado.UNINDENT

Diagnóstico y depuración recomendaciones
Muchos usuarios publican en la lista de correo de ns-3-users preguntando, por ejemplo, por qué no reciben ningún
tráfico en su simulación, o tal vez solo enlace ascendente pero no tráfico de enlace descendente, etc. En la mayoría de los casos,
En los casos, es un error en el programa de simulación del usuario. A continuación se ofrecen algunos consejos para depurar el
programa y descubra la causa del problema.

El enfoque general es permitir de forma selectiva e incremental el registro de datos relevantes.
Componentes del módulo LTE, verificando en cada activación que la salida sea la esperada. En
detalle:

· comprobar primero el plano de control, en particular el establecimiento de la conexión RRC
procedimiento, habilitando los componentes de registro LteUeRrc y LteEnbRrc

· luego verifique las transmisiones de paquetes en el plano de datos, comenzando por habilitar el registro
componentes LteUeNetDevice y EpcSgwPgwApplication, luego EpcEnbApplication, luego
bajando por la pila de radio LTE (PDCP, RLC, MAC y finalmente PHY). Todo esto hasta que tu
encuentre dónde dejan de procesarse/reenviarse los paquetes.

Pruebas Documentación
Descripción General
Para probar y validar el módulo ns-3 LTE, se proporcionan varios conjuntos de pruebas que son
Integrado con el marco de prueba ns-3. Para ejecutarlos es necesario tener configurado el
construir el simulador de esta manera:

$ ./waf configurar --enable-tests --enable-modules=lte --enable-examples
$ ./prueba.py

Lo anterior ejecutará no sólo los conjuntos de pruebas pertenecientes al módulo LTE, sino también aquellos
perteneciente a todos los demás módulos ns-3 de los que depende el módulo LTE. Ver el ns-3
manual para obtener información genérica sobre el marco de pruebas.

Puede obtener un informe más detallado en formato HTML de esta manera:

$ ./prueba.py -w resultados.html

Una vez que se haya ejecutado el comando anterior, puede ver el resultado detallado de cada prueba abriendo
el archivo resultados.html con un navegador web.

Puede ejecutar cada conjunto de pruebas por separado con este comando:

$ ./test.py -s nombre-del-conjunto-de-pruebas

Para más detalles sobre prueba.py y el marco de prueba ns-3, consulte el ns-3
manual.

Descripción of los testea suites
Unidad Examenes
SINR cálculo in los Enlace descendente
La suite de pruebas lte-enlace-descendente-sinr comprueba que se realiza el cálculo SINR en el enlace descendente
correctamente. El SINR en el enlace descendente se calcula para cada RB asignado a datos
transmisiones dividiendo la potencia de la señal deseada del eNB considerado por el
suma de la potencia de ruido más todas las transmisiones en el mismo RB provenientes de otros eNB
(las señales de interferencia):

En general, diferentes señales pueden estar activas durante diferentes periodos de tiempo. Definimos un
pedazo como el intervalo de tiempo entre dos eventos cualesquiera de tipo inicio o final de un
forma de onda. En otras palabras, un fragmento identifica un intervalo de tiempo durante el cual el conjunto de
Las formas de onda activas no cambian. Sea i el fragmento genérico, T_i su duración y
thrm{SINR_i} su SINR, calculado con la ecuación anterior. El cálculo del promedio
SINR rieme
El conjunto de pruebas comprueba que el cálculo anterior se realiza correctamente en el simulador.
Los vectores de prueba se obtienen fuera de línea mediante un script Octave que implementa lo anterior
ecuación, y que recrea una serie de señales transmitidas aleatoriamente e interferencias
señales que imitan un escenario en el que un UE intenta decodificar una señal de un eNB mientras
frente a interferencias de otros eNB. La prueba pasa si los valores calculados son iguales a
el vector de prueba dentro de una tolerancia de 10^{-7}. La tolerancia tiene por objeto tener en cuenta la
Errores de aproximación típicos de la aritmética de punto flotante.

SINR cálculo in los Uplink
La suite de pruebas lte-uplink-sinr comprueba que se realiza el cálculo SINR en el enlace ascendente
correctamente. Este conjunto de pruebas es idéntico a lte-enlace-descendente-sinr descrito en el anterior
sección, con la diferencia de que tanto la señal como la interferencia ahora se refieren a
las transmisiones por los UE y la recepción la realiza el eNB. Este conjunto de pruebas
recrea una serie de señales transmitidas aleatoriamente y señales de interferencia para imitar un
escenario en el que un eNB intenta decodificar la señal de varios UE simultáneamente (el
los de la celda del eNB) mientras se enfrentan a interferencias de otros UE (los que pertenecen
a otras células).

Los vectores de prueba se obtienen mediante un script Octave dedicado. La prueba pasa si el
Los valores calculados son iguales al vector de prueba dentro de una tolerancia de 10^{-7} que, como para
la prueba SINR de enlace descendente trata cuestiones de aproximación aritmética de punto flotante.

E-UTRA Absoluta Radio Frecuencia Channel Número (EARFCN)
La suite de pruebas lte-earfcn comprueba que la frecuencia portadora utilizada por el
La clase LteSpectrumValueHelper (que implementa el modelo de espectro LTE) se realiza en
cumplimiento con [TS36101], donde el número absoluto de canal de radiofrecuencia E-UTRA
(EARFCN) está definido. El vector de prueba para este conjunto de pruebas comprende un conjunto de valores EARFCN
y la frecuencia portadora correspondiente calculada manualmente siguiendo la especificación de
[TS36101]. La prueba pasa si la frecuencia portadora devuelta por LteSpectrumValueHelper es
igual que el valor conocido para cada elemento en el vector de prueba.

System Examenes
Dedicado Portador Desactivación Examenes
El conjunto de pruebas 'lte-test-deactivate-bearer' crea un caso de prueba con un solo EnodeB y Three
UE. Cada UE consta de un portador EPS predeterminado y uno dedicado con el mismo portador
especificación pero con diferente ARP. El flujo del caso de prueba es el siguiente: Adjuntar UE -> Crear
Predeterminado+Portador dedicado -> Desactivar uno de los portadores dedicados

El caso de prueba desactiva aún más el portador dedicado que tiene el ID de portador 2 (LCID=BearerId+2) de
Primer UE (UE_ID=1) El usuario puede programar la desactivación del portador después de un retraso de tiempo específico usando
Simulador::Método Schedule ().

Una vez que finalice la ejecución del caso de prueba, se crearán DlRlcStats.txt y UlRlcStats.txt. Llave
Los campos que deben verificarse en las estadísticas son:

|
Inicio | fin | ID de celular | IMSI | RNTI | LCID | TxBytes | RxBytes |

El caso de prueba se ejecuta en tres épocas. 1) En la primera época (0.04 s-1.04 s) Todos los UE y
se adjuntan los portadores correspondientes
y se activa el flujo de paquetes sobre los portadores dedicados.

2. En la segunda época (1.04s-2.04s), se crea una instancia de desactivación del portador, por lo que el usuario puede ver
Número relativamente menor de TxBytes en UE_ID=1 y LCID=4 en comparación con otros portadores.

3. En la tercera Época (2.04s-3.04s) desde la desactivación del portador de UE_ID=1 y LCID=4 es
completado, el usuario no verá ningún registro relacionado con LCID=4.

El caso de prueba pasa si y solo si 1) IMSI=1 y LCID=4 se eliminaron por completo en la tercera época 2)
No se ven paquetes en TxBytes y RxBytes correspondientes a IMSI=1 y LCID=4 Si es anterior
El criterio no coincide con el caso de prueba considerado fallido.

Adaptado De Sabor y Codificación Examenes
La suite de pruebas adaptación-enlace-lte proporciona pruebas del sistema que recrean un escenario con un
un solo eNB y un solo UE. Se crean diferentes casos de prueba correspondientes a diferentes
Valores SNR percibidos por la UE. El objetivo de la prueba es comprobar que en cada caso de prueba el
El MCS elegido corresponde a algunos valores de referencia conocidos. Estos valores de referencia se obtienen
reimplementando en Octave (ver src/lte/test/reference/lte_amc.m) el modelo descrito en
Sección sec-lte-amc para el cálculo de la eficiencia espectral, y determinación de la
índice MCS correspondiente buscando manualmente las tablas en [R1-081483]. La resultante
El vector de prueba se representa en la figura. Prueba vector para Adaptado De Sabor y Codificación.

El MCS que utiliza el simulador se mide obteniendo la salida de seguimiento
producido por el programador después de 4 ms (esto es necesario para tener en cuenta el retraso inicial en
informes CQI). La SINR que calcula el simulador también se obtiene utilizando el
LteChunkProcesador interfaz. La prueba pasa si se cumplen las dos condiciones siguientes.
satisfecho:

1. la SINR calculada por el simulador corresponde a la SNR del vector de prueba dentro
una tolerancia absoluta de 10^{-7};

2. el índice MCS utilizado por el simulador corresponde exactamente al de la prueba
vector.
[imagen] Vector de prueba para codificación y modulación adaptativa.UNINDENT

Intercelular Interferencia Examenes
La suite de pruebas interferencia lte proporciona pruebas del sistema que recrean una intercelda
escenario de interferencia con dos eNB, cada uno con un único UE conectado y empleando
Modulación y Codificación Adaptativa tanto en el enlace descendente como en el enlace ascendente. La topología de la
El escenario se muestra en la figura. topología para los entre celdas interferencia testea. el d_1
El parámetro representa la distancia de cada UE al eNB al que está conectado, mientras que el d_2
El parámetro representa la distancia de la interferencia. Observamos que la topología del escenario es tal
que la distancia de la fuente de interferencia es la misma para el enlace ascendente y descendente; aún así, el real
La potencia de interferencia percibida será diferente debido a las diferentes pérdidas de propagación.
en las bandas de enlace ascendente y descendente. Se obtienen diferentes casos de prueba variando d_1 y
parámetros d_2.
[imagen] Topología para la prueba de interferencia entre celdas.UNINDENT

Los vectores de prueba se obtienen mediante el uso de un script de octava dedicado (disponible en
src/lte/test/reference/lte_link_budget_interference.m), que hace el presupuesto del enlace
cálculos (incluida la interferencia) correspondientes a la topología de cada caso de prueba,
y genera la SINR resultante y la eficiencia espectral. Este último luego se utiliza para
determinar (usando el mismo procedimiento adoptado para Adaptado De Sabor y Codificación Examenes. Nosotros
tenga en cuenta que el vector de prueba contiene valores separados para el enlace ascendente y el enlace descendente.

UE Medidas Examenes
La suite de pruebas medidas-lte-ue proporciona pruebas del sistema que recrean una intercelda
escenario de interferencia idéntico al definido para interferencia lte Banco de pruebas.
Sin embargo, en esta prueba las cantidades a probar están representadas por RSRP y RSRQ.
mediciones realizadas por el UE en dos puntos diferentes de la pila: la fuente, que
es la capa UE PHY y el destino, es decir, el eNB RRC.

Los vectores de prueba se obtienen mediante el uso de un script de octava dedicado (disponible en
src/lte/test/reference/lte-ue-measurements.m), que realiza los cálculos del presupuesto del enlace.
(incluida la interferencia) correspondiente a la topología de cada caso de prueba, y genera la
RSRP y RSRQ resultantes. Los valores obtenidos se utilizan luego para comprobar la exactitud de
las mediciones de UE en la capa PHY. Después de eso, deben convertirse según 3GPP.
formateo con el fin de comprobar su corrección a nivel eNB RRC.

UE multiplataforma configuración pruebas
Además del conjunto de pruebas mencionado anteriormente, existen otros 3 conjuntos de pruebas para probar UE
mediciones: lte-ue-mediciones-por partes-1, lte-ue-mediciones-por partes-2 y
lte-ue-mediciones-traspaso. Estos conjuntos de pruebas se centran más en el desencadenante de informes.
procedimiento, es decir, la corrección de la implementación de la activación basada en eventos
Los criterios se verifican aquí.

Más concretamente, las pruebas verifican la sincronización así como el contenido de cada informe de medición
recibido por el eNodoB. Cada caso de prueba es una simulación LTE independiente y el caso de prueba
Pasa si los informes de medición solo se producen en el momento prescrito y muestran la información correcta.
nivel de RSRP (RSRQ no está verificado en este momento).

por partes configuración
La configuración por partes tiene como objetivo probar una configuración de mediciones de UE particular. El
El script de simulación configurará la configuración de mediciones correspondiente al UE, que
estará activo durante toda la simulación.

Dado que los valores de referencia se calculan previamente a mano, se hacen varias suposiciones para
simplificar la simulación. En primer lugar, el canal sólo se ve afectado por el modelo de pérdida de ruta (en este caso
caso se utiliza el modelo Friis). En segundo lugar, se utiliza el protocolo RRC ideal y la capa 3
el filtrado está deshabilitado. Finalmente, el UE se mueve en un patrón de movimiento predefinido entre 4
puntos distintos, como se muestra en la Figura UE movimiento rastrear a lo largo de los simulación in
por partes configuración abajo. Por lo tanto, la fluctuación del RSRP medido puede ser
determinarse más fácilmente.
[imagen] Traza del movimiento UE a lo largo de la simulación en configuración por partes.UNINDENT

La motivación detrás de la "teletransportarse" entre los puntos predefinidos es introducir
cambio drástico del nivel de RSRP, que garantizará la activación de entrada o salida
condición del evento probado. Al realizar cambios drásticos, la prueba se puede ejecutar dentro de
menor cantidad de tiempo.

Figura Mesurado RSRP rastrear of an (aqui) Eventos A1 testea case in por partes configuración
A continuación se muestra el RSRP medido después del filtrado de la capa 1 por la capa PHY durante el
Simulación con una configuración por partes. Debido a que el filtrado de capa 3 está deshabilitado, estos
son los valores exactos utilizados por la instancia UE RRC para evaluar el activador de informes
procedimiento. Observe que los valores se actualizan cada 200 ms, que es el valor predeterminado
Período de filtrado del informe de mediciones de la capa PHY. La figura también muestra el momento en que
condiciones de entrada y salida de una instancia de ejemplo del Evento A1 (la celda de servicio se convierte en
mejor que el umbral) ocurren durante la simulación.
[imagen] Traza RSRP medida de un caso de prueba de ejemplo del Evento A1 por partes
configuración.UNINDENT

Cada criterio de informe se prueba varias veces con diferentes umbrales/compensaciones.
parámetros. Algunos escenarios de prueba también tienen en cuenta la histéresis y el tiempo de activación.
Figura Mesurado RSRP rastrear of an (aqui) Eventos A1 con histéresis testea case in por partes
configuración Representa el efecto de la histéresis en otro ejemplo de prueba del Evento A1.
[imagen] Traza RSRP medida de un ejemplo de evento A1 con caso de prueba de histéresis en
configuración por partes.UNINDENT

La configuración por partes se utiliza en dos conjuntos de pruebas de mediciones de UE. El primero es
lte-ue-mediciones-por partes-1, en adelante Prueba por partes #1, que simula 1 UE y
1 eNodoB. El otro es lte-ue-mediciones-por partes-2, que tiene 1 UE y 2 eNodeB
en la simulación.

La prueba #1 por partes tiene como objetivo probar los criterios basados ​​en eventos que no son dependientes
sobre la existencia de una célula vecina. Estos criterios incluyen el Evento A1 y A2. El
Otros eventos también se prueban brevemente para verificar que todavía funcionan correctamente.
(aunque no informa nada) al no haber ninguna celda vecina. Mesa UE
medidas testea escenarios usando por partes configuración #1 A continuación se enumeran los escenarios.
probado en la prueba #1 por partes.

UE medidas testea escenarios usando por partes configuración #1
┌───────┬───────────┬──────────────────┬ ────────── ──┬─────────────────┐
│Prueba # │ Informes │ Umbral/Compensación │ Histéresis │ Tiempo de disparo │
│ │ Criterios │ │ │ │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│1 │ Evento A1 │ Bajo │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│2 │ Evento A1 │ Normal │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│3 │ Evento A1 │ Normal │ No │ Corto │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│4 │ Evento A1 │ Normal │ No │ Largo │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│5 │ Evento A1 │ Normal │ No │ Súper │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│6 │ Evento A1 │ Normal │ Sí │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│7 │ Evento A1 │ Alto │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│8 │ Evento A2 │ Bajo │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│9 │ Evento A2 │ Normal │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│10 │ Evento A2 │ Normal │ No │ Corto │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│11 │ Evento A2 │ Normal │ No │ Largo │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│12 │ Evento A2 │ Normal │ No │ Súper │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│13 │ Evento A2 │ Normal │ Sí │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│14 │ Evento A2 │ Alto │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│15 │ Evento A3 │ Cero │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│16 │ Evento A4 │ Normal │ No │ No │
└───────┴───────────┴──────────────────ⴔ ────────── ──┴─────────────────┘

│17 │ Evento A5 │ Normal-Normal │ No │ No │
└───────┴───────────┴──────────────────ⴔ ────────── ──┴─────────────────┘

Otros eventos, como el evento A3, A4 y A5, dependen de las mediciones de la celda vecina, por lo que
se prueban más exhaustivamente en la prueba n.° 2 por partes. La simulación coloca los nodos en un
línea recta e instruir a la UE a "saltar" de manera similar a la prueba #1 por partes.
El traspaso está deshabilitado en la simulación, por lo que la función de las celdas de servicio y vecinas no
no cambia durante la simulación. Mesa UE medidas testea escenarios usando por partes
configuración #2 A continuación se enumeran los escenarios probados en la prueba #2 por partes.

UE medidas testea escenarios usando por partes configuración #2
┌───────┬───────────┬──────────────────┬ ────────── ──┬─────────────────┐
│Prueba # │ Informes │ Umbral/Compensación │ Histéresis │ Tiempo de disparo │
│ │ Criterios │ │ │ │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│1 │ Evento A1 │ Bajo │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│2 │ Evento A1 │ Normal │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│3 │ Evento A1 │ Normal │ Sí │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│4 │ Evento A1 │ Alto │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│5 │ Evento A2 │ Bajo │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│6 │ Evento A2 │ Normal │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│7 │ Evento A2 │ Normal │ Sí │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│8 │ Evento A2 │ Alto │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│9 │ Evento A3 │ Positivo │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│10 │ Evento A3 │ Cero │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│11 │ Evento A3 │ Cero │ No │ Corto │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│12 │ Evento A3 │ Cero │ No │ Súper │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│13 │ Evento A3 │ Cero │ Sí │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│14 │ Evento A3 │ Negativo │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│15 │ Evento A4 │ Bajo │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│16 │ Evento A4 │ Normal │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│17 │ Evento A4 │ Normal │ No │ Corto │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│18 │ Evento A4 │ Normal │ No │ Súper │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│19 │ Evento A4 │ Normal │ Sí │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│20 │ Evento A4 │ Alto │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│21 │ Evento A5 │ Bajo-Bajo │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│22 │ Evento A5 │ Normal bajo │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│23 │ Evento A5 │ Bajo-Alto │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│24 │ Evento A5 │ Normal-Bajo │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│25 │ Evento A5 │ Normal-Normal │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│26 │ Evento A5 │ Normal-Normal │ No │ Corto │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│27 │ Evento A5 │ Normal-Normal │ No │ Súper │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│28 │ Evento A5 │ Normal-Normal │ Sí │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│29 │ Evento A5 │ Normal-Alto │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│30 │ Evento A5 │ Alto-Bajo │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│31 │ Evento A5 │ Normal alto │ No │ No │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│32 │ Evento A5 │ Alto-Alto │ No │ No │
└───────┴───────────┴──────────────────ⴔ ────────── ──┴─────────────────┘

Una nota sobre las pruebas con tiempo de disparo, se prueban usando 3 valores diferentes de
tiempo de activación: short (más corto que el intervalo del informe), long (más corto que el filtro
período de medición de 200 ms), y súper (más de 200 ms). Los dos primeros aseguran que
La evaluación del tiempo de activación siempre utiliza los últimos informes de medición recibidos de PHY.
capa. Mientras que el último es responsable de verificar el tiempo de activación de la cancelación, por
ejemplo, cuando un informe de medición de PHY muestra que la condición de entrada/salida no es
ya no es cierto antes de que se active el primer disparador.

Entregar configuración
El propósito de la configuración de traspaso es verificar si la medición del UE
La configuración se actualiza correctamente después de que se realiza una transferencia exitosa. Para esto
Para este propósito, la simulación construirá 2 eNodeB con diferentes medidas de UE
configuración, y el UE realizará el traspaso de una celda a otra. La UE será
ubicado en una línea recta entre los 2 eNodeB, y se invocará el traspaso
a mano. La duración de cada simulación es de 2 segundos (excepto el último caso de prueba) y el
El traspaso se activa exactamente en la mitad de la simulación.

La lte-ue-mediciones-traspaso El conjunto de pruebas cubre varios tipos de configuración.
diferencias. El primero es la diferencia en el intervalo de informe, por ejemplo, el primer eNodoB es
configurado con un intervalo de informe de 480 ms, mientras que el segundo eNodeB está configurado con 240 ms
intervalo de informe. Por lo tanto, cuando el UE realizó el traspaso a la segunda celda, la nueva
El intervalo de informe debe surtir efecto. Como en la configuración por partes, la sincronización y el
Se verificará el contenido de cada informe de medición recibido por el eNodeB.

Otros tipos de diferencias cubiertas por el conjunto de pruebas son diferencias en eventos y
diferencias en umbral/compensación. Mesa UE medidas testea escenarios usando entregar
configuración A continuación se enumeran los escenarios probados.

UE medidas testea escenarios usando entregar configuración
────────────────────────────────────────────────── ──────────────────────
N.° de prueba Sujeto de prueba inicial posterior a la entrega
Configuración Configuración
────────────────────────────────────────────────── ──────────────────────
1 Intervalo de informe 480 ms 240 ms
────────────────────────────────────────────────── ──────────────────────
2 Intervalo de informe 120 ms 640 ms
────────────────────────────────────────────────── ──────────────────────
3 Evento Evento A1 Evento A2
────────────────────────────────────────────────── ──────────────────────
4 Evento Evento A2 Evento A1
────────────────────────────────────────────────── ──────────────────────
5 Evento Evento A3 Evento A4
────────────────────────────────────────────────── ──────────────────────
6 Evento Evento A4 Evento A3
────────────────────────────────────────────────── ──────────────────────
7 Evento Evento A2 Evento A3
────────────────────────────────────────────────── ──────────────────────
8 Evento Evento A3 Evento A2
────────────────────────────────────────────────── ──────────────────────
9 Evento Evento A4 Evento A5
────────────────────────────────────────────────── ──────────────────────
10 Evento Evento A5 Evento A4
────────────────────────────────────────────────── ──────────────────────
11 Umbral/compensación rango RSRP 52 rango RSRP 56
(Evento A1) (Evento A1)
────────────────────────────────────────────────── ──────────────────────
12 Umbral/compensación rango RSRP 52 rango RSRP 56
(Evento A2) (Evento A2)
────────────────────────────────────────────────── ──────────────────────
13 Umbral/compensación Compensación A3 -30 Compensación A3 +30
(Evento A3) (Evento A3)
────────────────────────────────────────────────── ──────────────────────
14 Umbral/compensación rango RSRP 52 rango RSRP 56
(Evento A4) (Evento A4)
────────────────────────────────────────────────── ──────────────────────
15 Umbral/compensación rango RSRP 52-52 rango RSRP 56-56
(Evento A5) (Evento A5)
────────────────────────────────────────────────── ──────────────────────
16 Tiempo de disparo 1024 ms 100 ms
────────────────────────────────────────────────── ──────────────────────
17 Tiempo de disparo 1024 ms 640 ms
┌───────┬──────────────────┬──────────── ─────────┬ ─────────────────────┐
│ │ │ │ │
Coincidencias de archivo binario (entrada estándar)

Utilice ns-3-model-library en línea utilizando los servicios de onworks.net