Hola, Tengo un móvil Xiaomi 11 Lite 5G NE, que es compatible con el 5G+ (5G SA). Como podéis ver en las pantallas que anexo, el modo SA esta activado. Vivo en la zona Sagrada Familia de Barce...
Haría falta alguien con otro dispositivo en las mismas inmediaciones igualmente capaz y comprobar simplemente si es A o es B. En caso de A, pues asunto tuyo (si entiendes lo que te quiero decir), y si es B, pues a esperar, sin más.
Sobre que antena cercana existe, es bastante sencillo saberlo, los datos son públicos, otra cosa diferente es que la antena en cuestión realmente esté o no esté emitiendo la señal correspondiente. Pero cual es la antena más cercana y en que frecuencias en teoría está preparada para emitir, son datos repito públicos, que puedes consultar tú mismo
Por ejemplo:
Nota:
Por curiosidad he ido dando aleatoriamente a algunas antenas por tu zona, fijándome en las de Movistar, y no he visto ninguna que esté preparada para 3500MHz, con independencia total de que esté o no operativa. En cambio la que más aparece es la banda de 900MHz
Se supone, según mapa, que por la calle Providencia, 10 debería de existir una antena preparada al menos para 3500MHz... pero de nuevo, tampoco puedes tener garantía de que esté emitiendo, que tenga todos los permisos y el estado la tenga identificada, no implica que emita obviamente.
En contra, y para que veas que es mucho cuestión de suerte, he realizado lo mismo en mi localidad, y en dos de ellas cualesquiera (de Movistar), están recogidas:
Los despliegues son progresivos. Cuanta mayor es la frecuencia a usar (y mayor velocidad y prestaciones) la cobertura es menor, lo que implica tener que inundar una ciudad con ella, lo que implica ingentes cantidades de dinero en inversiones. Sustituir/añadir todo o gran parte de todo el entramado existente es cuanto menos complicado a corto plazo. Repito, frecuencia alta = Cobertura muy baja. Una antena de 3500MHz en una zona densa puede tener una cobertura de unos 100-300 metro!! Con lo que haz tu mismos los cálculos.
Así que me temo que no te va a quedar otra que esperar
A ver... el tecnicismo que quiera al final aplicar cada uno, que de forma coloquial (yo el primero) lo llamemos "lista blanca" o "lista negra", o un despliegue progresivo debido a bla bla bla. Todo esto obviamente siempre desde el total desconocimiento al no estar invitado a las reuniones donde Movistar debatirá esas políticas, como usuario y experiencia, es lo que veo.
-----------------
Sobre que debería o no ser compatible dado que es un estándar... ni muchísimo menos. Te voy a poner un ejemplo extremadamente sencillo y simplificado de esto, que por cierto también está dentro de todo esto: Los codec de video/audio.
Pensemos en algo "sencillo", por ejemplo en el codec de vídeo AV1. El estándar como dices está totalmente definido (unas 680 páginas de documentación ). Ahora bien, una cosa es un estándar, y otra totalmente diferente es la implementación, así como la elección de funcionalidades que pueden o no añadirse, muchas variables a libre elección según la implementación que se realice, optimizaciones generales y/o específicas de cada plataforma/hardware... Uno podría codificar un vídeo con AV1 usando el profile main 10 y Level 3, habilitando los intra-block. Todo ello está dentro del estándar AV1, pero si intentamos decodificar el vídeo en un hardware cuyo decodificador no sea compatible con algunas de las características usadas, el vídeo puede desde verse mal, a no verse. El estándar es una base!! El estándar no obliga que un decodificador deba obligatoriamente de soportar el Profile Main HDR por ejemplo ni nada de eso. El estándar los define.
Bien, pues esto pasa tan solo en un "simple" codec de vídeo. Ahora imagina lo que pasa cuando un modem debe de gestionar diferentes codec de video/audio, protocolos, políticas, frecuencias diferentes, funcionalidades adicionales, regulaciones, QoS, gestión... y un larguísimo etc. No es que Movistar tenga su propio "perfil", es que cada ISP del mundo lo tiene, y generalmente diferente en función de su propia región!! Los fabricantes requieren de esos "perfiles", los ISP por ende mantienen comunicación con los fabricantes a quienes dan estos perfiles.
Y eso solo para que te hagas una idea... abajo a la derecha primero las regiones globales, arriba luego los ISP de esa región, y dentro de ella los diferentes países donde el ISP presta servicios. Casi nada!!
Dentro del perfil de la baseband, si se extrae, tienes ahora más de 200 archivos diferentes que definen el perfil!! Como he dicho, políticas, codec, configuraciones/ajustes, direcciones...
Así que de universal, poco. Como entenderás, todo eso no se lo saca de la manga el fabricante, lo proporciona el ISP obligatoriamente. Ojalá fuese tan sencillo para el fabricante como poner un perfil universal y listo. Nada de eso. Y por descontado, si el ISP hace un cambio de parámetros, por el motivo que sea, que sean determinantes, estos pueden dejar totalmente KO a los dispositivos hasta que el fabricante a través de actualización de firmware o del mecanismo que sea actualice los perfiles pertinentes para reflejar los cambios.
De ahí la suma importancia de la rapidez en los que los fabricantes incorporan dichos perfiles. Y no solo es incorporarlos, es incorporarlos en sus dispositivos y que el software/hardware de su dispositivo pueda funcionar correctamente con ellos, piensa ahora en el ejemplo del codec AV1 puesto anteriormente.
Esto es lo que ha provocado siempre que cuando un ISP empieza a usar un servicio GSM de primeras, tarda bastante tiempo en asentarse en el país. No porque los dispositivos no sean realmente compatibles con dicha tecnología, sino porque el parametraje requerido no están incluidos, y para dispositivos más nuevos es de suponer que el fabricante se tomará las molestias de incluirlos (tampoco siempre), pero los que tienen algo de más tiempo, el fabricante suele pasar de ellos. En este aspecto, repito, chapó por samsung (y no me caen excesivamente bien, pero en esto les doy un 10)
Es más, si uno tiene los conocimientos necesarios, es posible modificar incluso la baseband (modem) del propio terminal, aunque sea viejo, para añadirle el/los perfiles necesarios. Obviamente a riesgo ya de cada uno, pero es más que posible.
Saludos.
usuario_retirado
13-06-2024
Theliel no mezclemos ejemplos porque no es comparable. De códecs de video se lo justo para saber qué durante muchos años en los ripeos no se cumplía y el resultado fue un descontrol y se empezó a estandarizar. Otra cosa son los bloqueos o diferencias por regiones por los intereses que haya.
Bueno, al lío, estuve investigando el tema, gracias al mundo del software libre y ya lo comprendí más o menos.
Por lo visto la forma de comunicarse un terminal con el ISP es a través de Protocol Buffers con el componente Carrier. En este mundo el binario resultante tiene extensión MBN. Cada ISP desarrolla y distribuye su propio binario a Google, Samsung, Xiaomi, etc y después cada fabricante lo incluye en su compilación de Android. Hay un mbn genérico pero cada ISP crea el suyo propio con sus peculiaridades. Y por lo visto el componente Carrier que va en el terminal es propietario o está sujeto a licencias. La versión del mbn es lo que se ve en la imagen de mi anterior post.
Aquí un ejemplo que lleva un usuario con la recopilación de todos los mbn de todos los ISP que puede para incluirlos en la compilación de GrapheneOS para los terminales Pixel.
Aqui el extractor https://github.com/GrapheneOS-Archive/carriersettings-extractor para interpretar el mbn aunque al ser protocol Buffers doy por hecho que con cualquier visor se puede abrir para ver el descriptor. Entiendo que esto lo han desarrollado para después hacer un Carrier libre que intérprete el descriptor de los campos del protocol Buffers, serialización, llamadas, etc..
Cualquiera que haya trabajado con esta tecnología, que curiosamente desarrolló Google, ya sabe de que va el tema.
Lo que no entiendo es el jaleo que tienen para trabajar con esta tecnología, yo he diseñado (y programado) muchos sistemas apalancandome en ella y no teníamos problemas... Aunque viendo que por el camino hay componentes sujetos a licencias e intereses, me imagino que pasa.
En Apple que usa iOS y otros sistemas entiendo que se hará igual ya que la gracia de Protocol Buffers es que es agnóstico del sistema y lenguaje de programación.
Si tengo tiempo investigo más a fondo el tema y escribo aquí o si alguien sabe algo más que nos cuente.
Vemos que has sido asesorado e informado por el Theliel. Os agradecemos a los dos el intercambio de información y opiniones. Dejamos el hilo abierto por si quieres añadir algo mas sobre el tema.
Sé para que es SUCI compi, he puesto duplicidad de SIM y otros, por pura cuestión de nostalgia, ya que sustituye al IMSI, que se atacaba para poder clonarlas (junto al KI). Lo que ha llevado a su uso es en esencia por privacidad para ocultar el SUPI, usando SUCI en su lugar, que a fin de cuenta es una derivación de este, y por ende todas las ventajas que puede suponer no exponer el SUPI.
Respecto a lo de la SIM, en ningún momento he dicho que todos los técnicos de Movistar tengan la misma información o que estén igualmente al día en la materia :). Como te dijo se habló mucho en su día al respecto, incluso como te digo yo tenía mis propias dudas si era necesario o no una SIM con soporte nativo para SUCI o no. Piensa que al final lo que podemos saber o no de la infraestructura es lo que vamos viendo, y todo está aun muy fresco. Pero parece que al final imperó la lógica, porque de lo contrario tendrían que empezar a cambiar un sin fin de tarjetas. Es más, creo recordar que las tarjetas 5G con SUCI ya no llevan siquiera el SUPI en ellas para mayor seguridad.
En cualquier caso, y sin tener detalles exactos de toda la infraestructura 5G SA de Movistar, parece ser que no es necesario tarjetas con SUCI "nativo" (por suerte, obviamente)
-------
Ei, me encanta Google, pero yo jamás me caso con nadie, y si veo que claramente hay un "culpable" en una cuestión concreta, pues lo digo. Y en este caso particular... pues es culpa de Google (en lo que respecta a que ahora mismo puedas o no conectarte a la red 5G SA). Del mismo modo, es culpa de Xiaomi ahora mismo (al menos en mi terminal) que, conectado a 5G SA tenga, a veces no me vuelva a VoWIFI cuando me conecto a la red WIFI, cosa que no pasa si estoy por 5G NSA o cualquier otra. Pues eso, es culpa de Xiaomi. E igualmente es culpa del técnico pues liar aun más al personal de que es necesario una SIM con SUCI cuando, en principio no hace falta.
Ahora bien, si me dicen que depende ya de la región en la que te encuentres de España puede o no ser necesario una SIM con SUCI nativo, y que se dice eso para estar totalmente seguro de la compatibilidad... pues ya ahí no puedo decir nada, no lo sé, me extraña mas que nada porque le costaría una pasta importante a Movistar hacer el cambio de tarjetas, pero a saber. El caso es que mi P48 funciona bien, y eso es totalmente objetivo y demostrable.
Saludos.
usuario_retirado
14-06-2024
Theliel el campo SUCI de la SIM no es para lo que comentas, es para enviar un código cifrado con clave asimétrica, resumiendo para humanos, evitar el ataque de que el terminal se conecte a una "antena" falsa y te roben los datos, vamos el típico ataque man in the middle.
Pues si funciona con una SIM con perfil anterior a los que me han dicho en el servicio técnico oficial de Movistar, esto es preocupante, ni sus técnicos saben cómo funciona su servicio, como para echar la culpa a Google xD
A ver, que aquí angelitos no hay nadie, pero que Movistar no va a enviar parámetros diferentes a Google y a Apple, por ejemplo, y va a enviar los correctos a Samsung o a Xiaomi... y que Vodafone, Orange... les pase exactamente lo mismo, huele un poco raro, vamos, digo yo.
Respecto lo que dices de la SIM, difiero bastante. Es verdad que para el correcto funcionamiento se requiere por seguridad SUCI, para evitar en esencia la posibilidad de duplicaciones de SIM y otros... aun recuerdo lo sencillo que era duplicarlas antiguamente.
Debido a esto empezó a cundir el pánico sobre la obligatoriedad de usar SIMs nuevas. Movistar se pronunció de forma oficial ante esto, diciendo que cualquier SIM 4G a efectos generales, y por ende hasta la fecha sin problemas para conectarse a 5G NSA/DSS, podría conectarse a 5G SA. Es más, yo mismo tuve dudas al principio sobre esto, ya que si Movistar hace uso realmente de SUCI, se requiere implementar o a nivel de SIM o por software.
La conclusión te la digo ya: No, no es necesario. Mi SIM es bastante más vieja, es una P48, denominada "4G", y mientras escribo esto estoy conectado a 5G SA. Con lo que judga tu mismo...
usuario_retirado
14-06-2024
Thelielno tiene sentido seguir con la conversación, tú tienes claro que Movistar lo hace bien y en este caso, Google mal. No pasa nada, en los foros de los fabricantes pasa lo contrario.
Sigo al hilo y por si le sirve de algo a alguien, hoy en el servicio técnico de Movistar por WhatsApp me han comentado que para el correcto funcionamiento del 5G SA hay que asegurarse tener una SIM con perfil del P58 a P66.
No entiendo lo que quieres decir al principio... estoy espesito hoy.
A ver, claro que un ISP como Movistar es algo bastante complejo, pero a efectos prácticos no deja de ser un proveedor de servicios. Como cualquier servicio que contratas pues no tiene que asegurarse como es lógico que los servicios por los que paga le sean correctamente dados. Les exijo exactamente lo mismo que cualquier fabricante que me venda el producto que sea. Obviamente no es lo mismo un servio que tienes contratado con un dispositivo que compras y es tuyo. Diferencias hay, pero teniendo en cuenta eso cada uno me tendrá que responder adecuadamente.
Sí, si la cuestión es como dices así de simple. Y para mi como te digo, no hay ningún problema en la interacción ISP<->Fabricante, dado que de existir sucedería igualmente en el resto de fabricantes, no particularmente con unos u otros. Que por cierto, se dan también los mismos "problemas" con otros ISP también... generalmente los mismos fabricantes.
No se trata de falta de cooperación, se trata de que algunos fabricantes, sea por el motivo que sea, no hace bien los deberes. Al menos para lo que yo considero hacerlos bien. Que tendrán sus motivos? Por supuesto que los tienen, pero sean cuales sean, más o menos comprensibles u honrados, el caso es que fallan en comparación a otros fabricantes. No tiene nada que ver el ISP, el ISP (y repito que aplicable a Movistar o a cualquier otro) no es que les caiga mejor uno u otro.
En tu caso particular, el motivo real por el que Google no actualiza sus Pixel 7 para hacerlos totalmente compatibles y funcionando perfecto con Movistar España, pues tan solo podemos imaginarlo como he dicho antes, que puede ser otro motivo totalmente diferente ojo, a saber... pero que por supuesto existe una razón para ello, sea coherente o reprochable? Por supuesto.
Saludos.
usuario_retirado
14-06-2024
Theliel me vas a disculpar pero no entiendo nada tu razonamiento. Intercambia en todo tu argumento las palabras "ISP" y "fabricante terminal/terminal". Te queda el mismo argumento pero "echando la culpa" al contrario. ¿Entiendes lo que quiero decir?
Tratas al ISP como si fuera un producto cuando es una arquitectura muchísima más compleja con todo tipo de tecnologías sw y hw que un "simple" terminal..
Por mi parte vamos a centrar el problema. La cuestión es que para que un terminal y un ISP puedan negociar una conexión 5G SA estable es necesario una parametrización en el terminal que se despliega vía OTA en el terminal.
Aquí es donde realmente está el lío y la discusión que tendrán ambas compañías, está visto que la colaboración no funciona igual que con Samsung o Xiaomi que inmediatamente sus teléfonos funcionan desde el primer día.
Aquí no entró en quién tiene la culpa pero si Samsung o Xiaomi parece que colaboran más estréchame con Movistar, Google debería hacérselo mirar..
Que lastra o no lastra dichos retrasos, a pesar de que sea "imposible" conocer con certeza lo que se mueve detrás, sigo pensando lo mismo: Control férreo, SoC particulares y por ende muchísimo menos depurados y ajustados y por supuesto miedo a la mala prensa (prueba de ambas es mirar igualmente a Apple que le sucede lo mismo).
Cuando tienes fabricantes tan dispares de como "trabajan" como pueda ser Samsung o Xiaomi, y ves que ambos suelen estar más al día en estos aspectos, desechas por lógica que sea un problema del ISP, un problema de recursos, un problema de ciclos de actualización...
De todo ello, me da que les pesa más el que dirán por no hacer bien los deberes, acrecentado porque tan solo tienen en mercado... 2 modelos? (sin contar con generaciones anteriores).
Piensa lo siguiente... Xiaomi tiene en el parqué un número importante de dispositivos por año, con diferente Hardware mucho de ellos, lo que implica diferentes SoC/modems. Ahora lanza una actualización de cualquiera de ellos, por ejemplo un Poco X6 Pro y lo deja sin 5G por un mal ajuste o bug. ¿Crees que los medios se van a hacer eco? Pues muy probablemente no. Primero porque muchos piensan que si cuesta poco (en este caso) es más permisible que falle ya funcionará, otros que será culpa del ISP, otros que ni se dan cuenta... en una semana o dos como mucho, posiblemente Xiaomi ha corregido el problema y no trasciende. Y ojo, esto sucede parecido si es un terminal de 1000€ como el Xiaomi 14 Ultra. Tiene muchos modelos al año, diferentes hardware, ciclos rápidos de actualizaciones... y encima hardware bastante probado y que encontramos en todas las marcas.
Piensa ahora que le pasa a Google. Lanza una actualización y deja a los Pixel 7 u 8 sin 5G... que además comparten el mismo SoC/modem (entre la misma generación). La cosa cambia, porque Google se ve como una marca "Premium" y que se supone tiene que ser infalible!! Además usa su propio SoC con lo que es más sencillo aun de cometer fallos o bug... al rato de lanzar la actualización los medios y portales se hacen eco, las quejas aparecen en todos lados. En el caso de Google, suele trabajar rápido, posiblemente paralizaría la actualización y en pocos días daría una solución. Pero ya ha salido en todos los medios que se han quedado sin 5G durante X.
Piensa en Apple, mismo escenario, sería casi el mismo!! Al ratito en todos los medios y portales, que Apple deja sin 5G a sus iphone. Debacle. Y encima en el caso de la manzanita suelen tomarse las cosas con más calma y tardar más.
--------
También hay otro detalle que creo y pienso también pueden tener encima de la mesa. Publicidad. Aprovechar ciertos eventos/momentos para publicitar a bombo y platillo ciertas funcionalidades o mejoras. No importa si la competencia lleva años con ellas y perfectamente, porque de nuevo no es noticia para los medios. No es lo mismo que Xiaomi lance y habilite X, que muy posiblemente pase desapercibido (porque no vende), a que la noticia sea de otros.
Y prueba de todo esto la llevo viendo durante años. Hay fabricantes con muy buenos terminales en el mercado que rara vez o casi nunca verás en prensa... al menos en una sección a destacar. En cambio hay otros que sistemáticamente SIEMPRE salen en prensa, y en primera página. Por supuesto es publicidad/marketing de algunos fabricantes, obviamente, pero luego si las cosas van mal...
Al menos repito es lo que me parece más lógico de pensar... ellos sabrán :).
Saludos
usuario_retirado
13-06-2024
Theliel veo que compartimos las mismas inquietudes desde pequeños 🙂
Por lo que comentas más lo que leo, es algo propio de la versión android de los Pixel el apalancarse en Protobuf para su CarrierSettings y el AOSP sigue con XML. Con esta issue a mí me queda claro está peculiaridad de los pixels https://github.com/dan-v/rattlesnakeos-stack/issues/163 quizás sea está una razon más para que los pixel vayan por detrás en integración con los ISP, aunque no tiene mucho sentido, se puede automatizar igualmente.
Seguimos estudiando. Mi objetivo es entender que lastra a los Pixel ya que ni Google ni Movistar dan la explicación y se dan largas entre ellos.
Gran autodidacta siempre desde pequeño en el campo de la informática/tecnología, y con los años también estudios, trabajo, tiempo libre... siempre aprendiendo algo nuevo compañero, siempre. Por ejemplo, como nunca he tenido un Pixel, hasta ayer no tenía ni idea que hacía uso importante de la configuración CarrierSetting. Soy gran aficionado a la ingeniería inversa, seguridad, al cacharreo... así que siempre que tengo algo de tiempo no es raro verme "destripando" mis propios dispositivos de un modo u otro 🙂
Los mbn, que yo sepa, no tienen absolutamente nada que ver con protobuf, repito, hasta donde yo sé. Son "binarios" que pueden desempacarse/empacarse sin demasiados problemas, con su propia estructura de archivos internas
Saludos
usuario_retirado
13-06-2024
Theliel de donde sacas la info? Me gustaría seguir profundizando en el tema. Ya lo podías haber contado antes y me había ahorrado estudiarlo jeje.
El último párrafo que comentas me preocupa, en el protobuf (mbn) no debería haber funcionalidad específica del módem, eso desde mi punto de vista es guarrear el protocolo, que justamente protobuf es para abstraer la comunicación de dos sistemas, es una definición de un mensaje y las llamadas RPC. El programa Carrier que usa el mbn es el que tiene que tener la lógica para hablar con él modem, eso sí no existen más capas de abstracción que seguro que si.
Es exactamente lo mismo, no es un problema con no cumplir los estándares, es una cuestión de implementación, funcionalidades y otros. Si te vas a los tiempos de la década de oro del ripeo, efectivamente, solo tienes que ver las diferencias y compatibilidades (o no) de MPEG-4 Part 2, de lo que en su tiempo fue DivX (o xVid) o tantos otros. Pero en los tiempos actuales lo mismo, solo tienes que ver las enormes diferencias de un codificador como x264 o nvenc (para h264), no tienen absolutamente nada que ver ni enfoques diferentes, ni características, ni ratios de compresión... Y estoy hablando de tiempos totalmente modernos. Y esto es extrapolable a cualquier otro, como pueda ser AV1 o H265 (aun más actuales)
Los "binarios" mbn de la baseband son diferente a las configuraciones CarrierConfig de Android. El extractor que indicas es para interpretar específicamente los binarios que usa Google en sus pixel (o al menos en algunos de ellos), para extraer de ellos los apn y el CarrierConfig de estos. Repito que esto es específico y propio de los Pixel, no en general, y en cualquier caso no está ligado a los mbn. Por ejemplo, la mayoría de los fabricantes incluye directamente los apn (apns-conf.xml) para ser usados tal cual, sin estar "empaquetados" en protobuffer.
Dependiendo del fabricante, los CarrierConfig pueden ser desde ignorados y no se usan ni tienen en cuenta (la inmensa mayoría de ellos), a prevalecer sobre los mbn, a simplemente complementarlos. Es más, en unos de los enlaces que pones, aparece un módulo de Magisk que lo que hace es añadir diferentes perfiles mbn a la baseband, no modificar los CarrierConfig del terminal.
Lo mbn además no son universales, estos están muy estrechamente asociados al modem que usan. Es decir que un perfil de un terminal A es muy posible que no funcione en el terminal B si posee un modem diferente. A pesar de ello pueden ser "similares" lo suficiente como para poder modificar o crear uno propio hasta cierto punto
Saludos.
usuario_retirado
13-06-2024
llober toca esperar y tener paciencia. Viendo como funciona esto hasta que no tengas una actualización de android no te va a funcionar.
También es posible que cuando den de paso a tu terminal/línea te funcione ya que tú versión concreta de software no necesite ningún añadido.
Al menos esto es todo lo que he deducido estudiando un poco como funciona la tecnología.
