{"schema_version":"1.0","service":"Publicasta","type":"article","id":840,"slug":"ocudu_26_10_open_source_ran_satellite_5g","title":"OCUDU 26.10 incorpora 5G satelital y una prueba de interoperabilidad más exigente para Open RAN","excerpt":"OCUDU 26.10 amplía una pila RAN abierta con NTN de Release 17, antenas 8T8R, posicionamiento, seguridad y una primera implementación de Split 7.2b. El lanzamiento es útil, pero sus propias notas indican por qué debe probarse como infraestructura, no instalarse como red terminada.","language":"es","default_language":"en","canonical_url":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=es","image":{"url":"https://publicasta.com/storage/projects/10/pages/840/2026/10/3f4611c8-f80d-4020-abfe-d61d78e98a2f.webp","alt":"Laboratorio de telecomunicaciones con equipos de radio 5G y una configuración de prueba de enlace satelital que representa la interoperabilidad de Open RAN"},"publisher":{"id":10,"slug":"open_source_radar","name":"Open Source Radar","url":"https://publicasta.com/open_source_radar"},"author":{"name":"Anton R"},"published_at":"2026-10-09T06:42:07+00:00","updated_at":"2026-10-09T06:42:07+00:00","content_markdown":"OCUDU 26.10 es el tipo de lanzamiento de código abierto que se presta a una lectura equivocada. Sus funciones destacadas parecen responder, al mismo tiempo, a varios problemas difíciles de las telecomunicaciones: conectividad satelital, MIMO de mayor orden, gestión de haces, posicionamiento, fronthaul abierto y seguridad reforzada. Además, el proyecto pasa de una primera publicación pública hacia una cadencia previsible de abril y octubre bajo la gobernanza de la Linux Foundation.\n\n ![Laboratorio de telecomunicaciones con equipos de radio 5G y una configuración de prueba de enlace satelital que representa la interoperabilidad de Open RAN](https://publicasta.com/storage/projects/10/pages/840/2026/10/3f4611c8-f80d-4020-abfe-d61d78e98a2f.webp)\n\n Eso vuelve importante a esta versión. Pero no la convierte en un reemplazo listo para conectar de una red de acceso radio comercial. OCUDU 26.10 se entiende mejor como una implementación pública y seria de una pila 5G CU/DU, con suficiente capacidad nueva para justificar experimentos de investigadores de telecomunicaciones, constructores de redes privadas y desarrolladores de equipos. No demuestra que las partes difíciles de la interoperabilidad Open RAN hayan desaparecido.\n\n La pregunta útil, por tanto, es más concreta que saber si OCUDU está listo para producción. ¿Qué partes de la versión puede probar ya un equipo técnicamente preparado, qué supuestos de hardware y sincronización hay detrás y qué funciones todavía necesitan una validación independiente de extremo a extremo?\n\n ## Qué cambió en OCUDU 26.10\n\n Las [notas oficiales de la versión](https://docs.ocudu.org/releases/release_notes/) enumeran un conjunto amplio de incorporaciones. La más trascendente es la compatibilidad con Release 17 para redes no terrestres, o NTN. La misma versión añade compatibilidad base con O-RAN Split 7.2b en la implementación de Open Fronthaul, soporte para antenas 8T8R, gestión de haces de Release 15 y 16 para FR1 y FR2, posicionamiento basado en ángulos, señales de referencia de posicionamiento en el enlace descendente, acceso aleatorio en dos pasos, preprogramación del enlace ascendente, concesiones configuradas, agrupación de TTI, repetición de PUCCH y compatibilidad con DTLS.\n\n El [anuncio de la Linux Foundation](https://www.linuxfoundation.org/press/ocudu-ecosystem-foundation-announces-ocudu-26.10-and-invites-developers-to-the-ocudu-ecosystem-developer-summit-october-20-22-near-washington-dc-to-learn-m-1791460743158) agrupa esos cambios en tres temas prácticos: más opciones de despliegue; mejor rendimiento radio y menor latencia; y nuevas funciones de posicionamiento y seguridad. Es una descripción razonable, pero las notas detalladas importan más que el resumen porque dejan ver el grado de madurez de cada función.\n\n Varias entradas están marcadas expresamente como compatibilidad base o como funciones que todavía no se han probado con una O-RU. Esa redacción no es una nota al pie. En una RAN distribuida, una función puede compilar, superar pruebas unitarias y aun así fallar cuando se encuentra con una unidad radio concreta, una fuente de reloj determinada, un perfil de compresión, una red de transporte o una implementación de gestión. Cuando una nota de versión dice que una función no se ha probado de extremo a extremo, está indicando a quien evalúa por dónde empezar, no prometiendo que el trabajo haya terminado.\n\n OCUDU se describe como un proyecto completo de gNB 5G de código abierto que cubre el plano de control de la unidad central, el plano de usuario de la unidad central y la unidad distribuida. La [documentación oficial](https://docs.ocudu.org/) indica que apunta a despliegues comerciales y a investigación, que funciona sobre hardware x86 y ARM de propósito general, que sigue las especificaciones de 3GPP y O-RAN y que utiliza la licencia BSD de 3 cláusulas. El repositorio está alojado en GitHub como espejo, mientras que las contribuciones se realizan en el [repositorio GitLab del proyecto](https://gitlab.com/ocudu/ocudu).\n\n Esa estructura importa porque OCUDU no es únicamente un demostrador de protocolos. Su valor está en el límite entre estándares, sistemas de tiempo real, hardware de radio y herramientas de despliegue. Cuanto más de ese límite expone el proyecto en código público, más útil resulta para quienes necesitan inspeccionar, modificar o validar una RAN en lugar de consumirla como un dispositivo sellado.\n\n ## Por qué NTN de Release 17 concentra la atención\n\n Las redes no terrestres extienden los procedimientos 5G a enlaces que involucran satélites u otras plataformas aéreas. El enlace radio deja de ser un trayecto terrestre corto y relativamente estable entre un teléfono y una estación base cercana. El retardo de propagación, la temporización, los efectos Doppler, el movimiento del satélite, la geometría de cobertura y la ubicación de la pasarela pasan a formar parte del diseño del sistema. El software debe tener en cuenta esas condiciones sin fingir que una celda satelital se comporta como una macrocelda urbana ordinaria.\n\n OCUDU ya había documentado compatibilidad con NTN GEO en materiales anteriores. El hito 26.10 amplía el alcance declarado del proyecto a NTN de Release 17, y los tutoriales describen un modo NTN que utiliza efemérides SIB19 y soporte de temporización para escenarios GEO y LEO. Por eso, el [tutorial de NTN](https://docs.ocudu.org/tutorials/) resulta más útil para un posible evaluador que el titular por sí solo: indica que el proyecto espera un entorno de prueba con equipos UE adecuados y un entorno radio cuidadosamente controlado.\n\n Aquí es donde la versión adquiere relevancia más allá del interés por los satélites. Una implementación abierta ofrece a los investigadores un lugar donde inspeccionar cómo las hipótesis de NTN recorren la configuración, la información difundida, la temporización y la lógica de movilidad. Permite experimentos difíciles de realizar con un sistema de proveedor cuyos detalles de implementación no están disponibles. Un equipo que trabaje en conectividad resiliente, instalaciones industriales remotas, enlaces marítimos o redes híbridas terrestre-satelitales también puede usar una CU/DU abierta como punto de referencia para comparar arquitecturas.\n\n Pero el código abierto no elimina las restricciones físicas. Un desarrollador puede ejercitar parte del software mediante simulación o una ruta radio virtual, aunque una evaluación realista necesita un UE, un frontal radio o emulador, temporización adecuada, un núcleo 5G y una ruta de transporte que reproduzca las condiciones previstas. La documentación del proyecto menciona equipos de Amarisoft para algunos tutoriales NTN. Es un recordatorio de que la demostración más interesante puede seguir dependiendo de componentes especializados o propietarios alrededor del software abierto.\n\n También existe otro límite. La compatibilidad con una función estándar no significa compatibilidad con todas las órbitas satelitales, configuraciones de espectro, clases de terminal o patrones de movilidad cubiertos por ese estándar. NTN de Release 17 es un ámbito técnico extenso. La interpretación responsable de OCUDU 26.10 es que proporciona una superficie pública de implementación para trabajar con NTN, no que haya resuelto el 5G satelital como categoría de producto.\n\n ## Qué cambian 8T8R y la gestión de haces\n\n El trabajo de 8T8R es menos visible para el público general, pero puede resultar más inmediatamente relevante para experimentos radio terrestres. Una configuración 8T8R utiliza ocho rutas de transmisión y ocho de recepción. Más puertos de antena pueden ofrecer un control adicional sobre la precodificación y los patrones de haz, aunque el resultado depende de la unidad radio, la calibración, las condiciones del canal, los libros de códigos, la capacidad de procesamiento y el número de capas espaciales que realmente se utilicen. Ocho puertos no significan automáticamente ocho flujos de datos independientes.\n\n La solicitud pública de incorporación de esta función explica que la implementación permite ocho puertos, pero mantiene en cuatro el máximo de capas por palabra de código en la fase descrita. También señala la configuración de CSI, la precodificación del enlace descendente, la configuración de PDSCH, el dimensionamiento de los búferes HARQ y la gestión de la carga útil de PUCCH. Esos detalles son útiles porque muestran que una función relacionada con el número de antenas no se activa con un solo interruptor. Afecta a los supuestos del planificador, la realimentación, los búferes, la señalización de control y la interfaz radio.\n\n OCUDU 26.10 incluye además informes y realimentación CSI de libro de códigos Tipo II en fase base, así como gestión de haces de Release 15 y 16 para FR1 y FR2. La gestión de haces reúne los procedimientos para descubrir, medir, seleccionar y mantener haces adecuados. En un sistema real implica señalización de control, señales de referencia, mediciones, movilidad y coordinación entre la unidad distribuida y la unidad radio. Un camino de código que admite el procedimiento es necesario, pero su utilidad depende de que la cadena completa se comporte correctamente cuando cambian las condiciones del canal.\n\n Por eso conviene leer el hito del proyecto junto con las notas de versión. El [hito v26.10](https://gitlab.com/ocudu/ocudu/-/milestones/2) registra el trabajo de forma más orientada a ingeniería: Open Fronthaul Cat-B 7.2, CSI Tipo II, 8T8R, gestión de haces, posicionamiento basado en ángulos, señales de referencia de posicionamiento en el enlace descendente, acceso aleatorio en dos pasos, planificación del enlace ascendente, concesiones configuradas, agrupación de TTI, repetición de PUCCH, DTLS y NTN de Release 17. También ofrece un rastro visible de incidencias y solicitudes de incorporación, en vez de presentar la lista de funciones como una superficie de producto terminada.\n\n Para un laboratorio, esa es una razón sólida para probar la versión. El código y el historial de incidencias pueden ayudar a identificar qué subsistema es responsable de un fallo. Para un operador de red, también es una advertencia: el plan de integración debe mantenerse explícito. La prueba correcta no consiste solamente en comprobar si una celda se inicia. Hay que verificar si la RU prevista, el esquema de reloj, el ancho de banda del canal, la numerología, el conjunto de capacidades del UE y el perfil de tráfico producen un comportamiento estable bajo carga.\n\n ## Split 7.2b resulta útil precisamente porque todavía no es rutinario\n\n En las conversaciones sobre Open RAN, la interoperabilidad suele utilizarse como abreviatura de la promesa de que una unidad distribuida de un proveedor pueda funcionar con una unidad radio de otro. La interfaz de fronthaul abierto es central para esa promesa. En una división funcional 7.2x, parte del procesamiento de la capa física se separa entre la O-DU y la O-RU, mientras muestras radio e información de control atraviesan una red de fronthaul. Esto puede ampliar el ecosistema de proveedores, pero también convierte la temporización, el transporte de paquetes, la compresión, la sincronización y la compatibilidad de perfiles en asuntos operativos.\n\n La [O-RAN Alliance](https://www.o-ran.org/specifications) publica especificaciones para interfaces y funciones destinadas a facilitar redes de acceso radio abiertas, inteligentes e interoperables. La diferencia entre una especificación y una integración funcional de varios proveedores es importante. La especificación define el contrato. Las implementaciones todavía deben ponerse de acuerdo sobre perfiles, funciones opcionales, comportamiento de gestión, sincronización, límites de rendimiento y cobertura de pruebas.\n\n OCUDU 26.10 añade compatibilidad base con Split 7.2b. Las notas oficiales indican expresamente que todavía no se ha probado con una O-RU. Esa sola frase debería orientar la evaluación. La función es valiosa para desarrolladores que necesitan examinar o ampliar la interfaz. No es una razón para suponer que cualquier unidad radio 7.2b vaya a conectarse correctamente.\n\n La diferencia entre 7.2a y 7.2b también tiene consecuencias prácticas. La ubicación de funciones como la precodificación afecta a lo que deben conocer la O-DU y la O-RU, a la cantidad de información que cruza el fronthaul y a la participación de la unidad radio en la formación de haces. Los materiales técnicos públicos sobre 7.2x suelen distinguir las categorías A y B alrededor de esa ubicación de la precodificación. Un equipo que pase de una configuración 7.2a a 7.2b debería esperar algo más que editar un archivo de configuración. Necesita comprobar los perfiles admitidos, la compresión, los mensajes del plano de control, la temporización y el comportamiento de la unidad radio.\n\n La documentación pública existente del proyecto apunta en la misma dirección. El material actual de funciones de OCUDU enumera Split 7.2a mediante su biblioteca interna de Open Fronthaul, mientras que las notas de 26.10 describen 7.2b como una incorporación base. Esa transición convierte a 26.10 en una prueba de compatibilidad útil para el ecosistema, pero también significa que la versión debe evaluarse con hardware identificado y un plan de pruebas reproducible.\n\n Un primer experimento sensato utilizaría una O-RU conocida, una banda y un ancho de banda fijos, un esquema de reloj y sincronización documentado y una prueba de tráfico que pudiera repetirse entre compilaciones. Conviene capturar los paquetes de fronthaul y los mensajes de control, y registrar carga de CPU, pérdida de paquetes, errores de temporización, estabilidad del registro y rendimiento. Si el resultado es un fallo, el objetivo es localizar el contrato que falla, no declarar viable o rota toda la arquitectura.\n\n ## El posicionamiento es otra historia escondida en la versión\n\n OCUDU 26.10 añade posicionamiento basado en ángulos y generación de señales de referencia de posicionamiento en el enlace descendente. Estas capacidades apuntan hacia una RAN capaz de ofrecer algo más que conectividad. Las mediciones radio pueden contribuir a estimaciones de ubicación, seguimiento industrial, supervisión de activos, servicios de emergencia y aplicaciones conscientes de la red. En una red privada, el posicionamiento puede ser útil incluso cuando la navegación por satélite no está disponible o resulta poco fiable.\n\n Las notas de versión vuelven a emplear un lenguaje cuidadoso: las funciones de posicionamiento se describen como compatibilidad base y todavía no se han probado de extremo a extremo con una O-RU. La precisión de esa advertencia es especialmente importante porque el resultado depende de la geometría de las antenas, la calibración, la sincronización, la propagación multicamino, la calidad de las mediciones y los algoritmos que convierten observaciones radio en una estimación de ubicación.\n\n Una señal de referencia de posicionamiento puede existir en la pila sin producir una ubicación útil dentro de un almacén, un cañón urbano o una nave industrial. Por ello, el evaluador debería separar tres preguntas. ¿Puede la red configurar y transmitir las señales pertinentes? ¿Pueden el UE y la unidad radio medirlas de forma consistente? ¿Produce el sistema completo un nivel de precisión y disponibilidad adecuado para la aplicación prevista? OCUDU 26.10 parece abordar la primera pregunta y abrir trabajo sobre la segunda y la tercera.\n\n Eso sigue siendo significativo. Las implementaciones abiertas permiten inspeccionar las rutas de temporización y medición, comparar algoritmos y construir bancos de pruebas repetibles. También pueden facilitar la identificación del límite entre un problema de protocolo, una deficiencia de calibración radio y un supuesto de posicionamiento propio de la aplicación. Los sistemas cerrados pueden ofrecer un resultado pulido, pero hacen más difícil ese diagnóstico.\n\n ## El trabajo de seguridad va más allá de marcar una casilla\n\n La versión incorpora compatibilidad con DTLS para comunicaciones seguras, mejoras de seguridad y resiliencia, y afirmaciones en la documentación sobre pruebas de seguridad O-RAN. El anuncio de la Linux Foundation menciona además pruebas continuas de fuzzing, participación en OSS-Fuzz y validación independiente. Son señales positivas porque una pila de red que gestiona tráfico de control, tráfico de usuario e interfaces de administración tiene una superficie de ataque amplia.\n\n Aun así, la seguridad debe leerse como una cuestión de proceso y arquitectura, no como una insignia. DTLS puede proteger un canal de comunicación, pero no decide quién tiene permiso para establecerlo, cómo se aprovisionan y rotan las claves, qué extremos son confiables, qué ocurre cuando caducan los certificados ni cómo se aíslan el tráfico de gestión, control y plano de usuario. El fuzzing puede encontrar clases de defectos en analizadores y máquinas de estados, pero no demuestra que un despliegue esté configurado correctamente.\n\n La [documentación de seguridad y despliegue](https://docs.ocudu.org/tutorials/) debería leerse junto con el código fuente y los informes de pruebas antes de colocar el software en una red expuesta. Una evaluación seria debe inventariar todas las interfaces: conexiones con el núcleo de red, rutas F1 o internas entre CU y DU, conexiones E1 entre componentes de la CU, fronthaul O-RAN, API de administración, métricas, interfaces de contenedores y cualquier ruta de comandos remotos. Después debe probar autenticación, fallos de certificados, mensajes malformados, agotamiento de recursos, separación de privilegios y registros.\n\n La licencia permisiva BSD de 3 cláusulas resulta atractiva para usos comerciales y de investigación, pero una licencia no equivale a garantía operativa. El repositorio señala que algunas partes pueden implementar especificaciones 3GPP y estar sujetas a requisitos de licencia adicionales. Una empresa que planee distribuir un producto debe realizar su propia revisión legal, seguir los componentes de terceros y conservar los avisos del proyecto. También debe examinar el código exacto y el estado de las pruebas de las funciones que piensa distribuir, en vez de tratar la licencia principal del proyecto como una respuesta completa de cumplimiento.\n\n ## Quién debería probar OCUDU 26.10\n\n El público más adecuado es un equipo que ya sepa construir y operar un entorno de pruebas 5G basado en Linux. La [guía de instalación de OCUDU](https://docs.ocudu.org/user_manual/installation/) requiere un sistema operativo basado en Linux con soporte para un kernel de tiempo real. La compilación utiliza CMake y C++17, con dependencias que incluyen SCTP, yaml-cpp, mbedTLS y una biblioteca FFT. La guía enumera Ubuntu 22.04 o posterior, Fedora y Arch como rutas de instalación compatibles, aunque el rendimiento real de tiempo real depende del host, la CPU, la NIC, la configuración del kernel y el sistema radio.\n\n Los investigadores que trabajen en NTN, gestión de haces, posicionamiento o fronthaul abierto pueden usar la versión como base pública para sus experimentos. Los equipos de redes privadas pueden estudiar cómo encaja una pila CU/DU con un núcleo 5G, una O-RU y un sistema de gestión. Los desarrolladores de hardware pueden usar el código y el historial de incidencias para validar sus supuestos sobre las interfaces. Los estudiantes y los ingenieros que estén aprendiendo arquitectura 5G también pueden beneficiarse, siempre que traten el proyecto como un sistema que hay que entender y no como un binario que se instala y se olvida.\n\n Los tutoriales del proyecto cubren bastante más que una compilación sencilla. Incluyen una red completa con split 8 utilizando srsUE y Open5GS, pruebas de movilidad con UE comerciales, configuración NTN, integración con Near-RT RIC, DPDK, aceleración de hardware, imágenes de contenedor, despliegue en Kubernetes y ajuste de rendimiento. Ese alcance es útil porque conecta el software con el ecosistema que lo rodea. También muestra el coste de una evaluación realista: algunos tutoriales necesitan una USRP, una NIC compatible con DPDK, un acelerador, equipos de temporización, una O-RU compatible o un UE comercial.\n\n OCUDU es una opción menos adecuada para un equipo que busque un producto 5G privado listo para usar, con soporte de proveedor, combinaciones de hardware certificadas, un plano de gestión llave en mano y un objetivo de rendimiento contractual. Puede formar parte de un producto así, pero la carga de integración y verificación no desaparece porque el código sea abierto. De hecho, la posibilidad de modificarlo añade otra responsabilidad: mantener un conjunto de parches, seguir los cambios aguas arriba, reproducir las compilaciones y decidir qué resultados de prueba son suficientes para el perfil de riesgo del despliegue.\n\n ## Un plan práctico de evaluación\n\n Hay que empezar por una sola pregunta. Probar todo lo incluido en 26.10 al mismo tiempo producirá una cantidad impresionante de ruido. Un laboratorio interesado en enlaces satelitales debería comenzar por el tutorial NTN y por un escenario definido de temporización y efemérides. Un equipo que evalúe interoperabilidad con unidades radio debería empezar con una O-RU y Split 7.2b, no con una colección de dispositivos sin verificar. Un investigador de posicionamiento debería comprobar primero la generación y medición de las señales antes de prometer una precisión concreta a nivel de aplicación.\n\n Conviene fijar la revisión exacta del código y registrar el compilador, el kernel, la CPU, la NIC, la FPGA o el acelerador, el frontal RF, el UE, el núcleo de red y la configuración. Los registros de compilación y los archivos de configuración deben conservarse junto con el resultado de la prueba. Los sistemas de telecomunicaciones de código abierto son especialmente sensibles a los detalles del entorno; un resultado que no puede reproducirse es difícil de interpretar, aunque el código esté disponible.\n\n Después hay que dividir la evaluación en capas. Primero, ejecutar pruebas de software y comprobaciones estáticas. Segundo, establecer un registro estable y una sesión de plano de usuario con la configuración compatible más sencilla. Tercero, añadir la función elegida. Cuarto, introducir carga, movilidad, variación de temporización o un segundo componente de otro proveedor. Ese orden ayuda a distinguir un problema del sistema base de un problema de función y de un problema multin proveedor.\n\n Para Split 7.2b, hay que capturar mediciones funcionales y operativas. Confirma que la O-DU y la O-RU coincidan en perfiles y compresión. Comprueba la sincronización antes de interpretar el rendimiento. Mide tasas de paquetes, latencia, fluctuación, pérdidas y margen de CPU. Repite la prueba después de reiniciar y bajo una perturbación controlada. Una interfaz que funciona una vez sobre una mesa limpia todavía no es un despliegue interoperable.\n\n Para NTN, conviene probar por separado los supuestos de temporización y movilidad antes de añadir tráfico de aplicación. Compara el comportamiento esperado y el observado cuando cambian el retardo y la geometría. Documenta qué partes son simuladas, cuáles emuladas y cuáles atraviesan equipos RF o satelitales reales. La distinción será importante si más adelante alguien cita el resultado como evidencia de preparación para el campo.\n\n Para seguridad, hay que elaborar un modelo de amenazas antes de habilitar el acceso remoto. Utiliza segmentación de red, mínimo privilegio, credenciales protegidas y artefactos firmados o verificados cuando estén disponibles. Trata las imágenes de contenedor, las herramientas auxiliares, los extremos de administración y los sistemas de supervisión como parte de la base informática confiable. Revisa los informes de seguridad y el gestor de incidencias del proyecto, pero no delegues la evaluación final de riesgo en los mantenedores externos.\n\n ## Alternativas y puntos de comparación\n\n OCUDU no es la única vía de código abierto para experimentar con una RAN 5G. OpenAirInterface sigue siendo un proyecto de referencia importante para investigadores y operadores que exploran Open RAN y sistemas 5G. srsRAN Project ofrece otra pila abierta de CU/DU y acceso radio, con documentación extensa y material de integración de hardware. La elección entre ellos debería seguir la combinación de función y hardware que se quiera probar, no una clasificación general.\n\n La comparación útil suele ser específica. ¿Qué proyecto admite la banda y la división funcional previstas? ¿Cuál tiene una configuración probada para la O-RU elegida? ¿Qué planificador, implementación PHY o integración E2 encaja con el experimento? ¿Qué actividad presenta la cola de incidencias pertinente? ¿Puede el equipo reproducir una compilación y obtener ayuda cuando aparece un fallo específico del hardware? Una matriz de funciones vale menos que un camino probado con los equipos exactos del laboratorio.\n\n La particularidad de OCUDU es su intento actual de colocar en un mismo proyecto público una implementación amplia de CU/DU, gobernanza abierta, una versión de octubre y capacidades nuevas como NTN y 8T8R. Eso hace que merezca seguimiento incluso por parte de equipos que no lo adopten. Sus decisiones de implementación pueden servir como punto de comparación para otras pilas, y su trabajo público de integración puede mostrar dónde dejan margen de interpretación los estándares.\n\n La alternativa a probar una pila abierta no siempre es comprar un producto comercial. También puede ser una prueba más pequeña y controlada de un componente. Un equipo puede validar un perfil de Open Fronthaul, una ruta de señales de posicionamiento o un cambio en el planificador sin construir una red a escala de operador. OCUDU resulta útil en ese papel porque el código, la documentación y el historial de incidencias permiten mantener el experimento cerca de la implementación.\n\n ## La importancia real de esta versión\n\n OCUDU 26.10 importa porque lleva el código Open RAN a una fase más exigente. La primera versión pública estableció que el proyecto podía publicar una base CU/DU abierta y amplia. La versión de octubre plantea si esa base puede absorber la temporización satelital, configuraciones de antenas de mayor orden, procedimientos de haces, posicionamiento, pruebas de seguridad y perfiles adicionales de fronthaul sin perder un proceso de desarrollo transparente.\n\n Esa es una historia más valiosa que afirmar que el código abierto ha sustituido a la infraestructura de telecomunicaciones establecida. Open RAN todavía tiene que ganarse la confianza mediante pruebas de interoperabilidad, mediciones de rendimiento, revisión de seguridad, herramientas operativas y mantenimiento a largo plazo. Una licencia permisiva ayuda a que más personas inspeccionen y construyan sobre el software, pero no proporciona calibración radio, autorización de espectro, sincronización, contratos de soporte ni validación de producción.\n\n Para los desarrolladores, el consejo inmediato es elegir una función de 26.10 y reproducir el camino documentado por el proyecto antes de modificar nada. Para los investigadores, la versión ofrece una base más rica para experimentos en torno a NTN, posicionamiento y procesamiento radio desagregado. Para operadores y fabricantes de equipos, el siguiente paso correcto es una prueba de interoperabilidad con hardware identificado y evidencias capturadas, no una conclusión amplia de compra.\n\n OCUDU 26.10 está, por tanto, lista para probar y, en varios aspectos, lista para enseñar. Sus propias notas de versión dejan claro dónde todavía no está preparada para recibir confianza sin trabajo adicional. Esa combinación —capacidad pública sustancial y límites visibles— es exactamente lo que conviene buscar en un nuevo lanzamiento de infraestructura de código abierto.","available_translations":[{"language":"ar","title":"OCUDU 26.10 يجلب شبكات 5G عبر الأقمار الصناعية واختبار توافق أكثر صرامة إلى شبكات RAN المفتوحة","html_url":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=ar","markdown_url":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=ar","json_url":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/ocudu_26_10_open_source_ran_satellite_5g?lang=ar"},{"language":"de","title":"OCUDU 26.10 bringt Satelliten-5G und einen härteren Interoperabilitätstest für Open RAN","html_url":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=de","markdown_url":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=de","json_url":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/ocudu_26_10_open_source_ran_satellite_5g?lang=de"},{"language":"en","title":"OCUDU 26.10 brings satellite 5G and a tougher interoperability test to open RAN","html_url":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=en","markdown_url":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=en","json_url":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/ocudu_26_10_open_source_ran_satellite_5g?lang=en"},{"language":"es","title":"OCUDU 26.10 incorpora 5G satelital y una prueba de interoperabilidad más exigente para Open RAN","html_url":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=es","markdown_url":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=es","json_url":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/ocudu_26_10_open_source_ran_satellite_5g?lang=es"},{"language":"fr","title":"OCUDU 26.10 apporte la 5G par satellite et un test d’interopérabilité plus exigeant à l’Open RAN","html_url":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=fr","markdown_url":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=fr","json_url":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/ocudu_26_10_open_source_ran_satellite_5g?lang=fr"},{"language":"pl","title":"OCUDU 26.10 wnosi satelitarne 5G i trudniejszy test interoperacyjności do otwartego RAN","html_url":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=pl","markdown_url":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=pl","json_url":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/ocudu_26_10_open_source_ran_satellite_5g?lang=pl"},{"language":"ru","title":"OCUDU 26.10: спутниковый 5G и более жёсткая проверка совместимости для Open RAN","html_url":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=ru","markdown_url":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=ru","json_url":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/ocudu_26_10_open_source_ran_satellite_5g?lang=ru"},{"language":"zh","title":"OCUDU 26.10 带来卫星 5G，也把开放 RAN 的互操作性推向更严苛的测试","html_url":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=zh","markdown_url":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=zh","json_url":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/ocudu_26_10_open_source_ran_satellite_5g?lang=zh"}],"_links":{"self":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=es","api":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/ocudu_26_10_open_source_ran_satellite_5g?lang=es","html":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=es","canonical":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=es","markdown":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=es","json":"https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=es","channel":"https://publicasta.com/api/public/v1/channels/open_source_radar","channel_articles":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}