TR-069 features and benefits on Made4Graph

As we saw in our articles about TR-069, the CWMP protocol has many features and benefits, and these can be found in the Made4Graph tool, where it has a specific module for TR-069. The image below shows the module, and what can be accessed in the tool. In the first option of the module, we have the Dashboard TR-069, this screen shows complete reports of the status of the equipment that have TR-069 enabled, as well as the total percentage of devices that have TR69 enabled or not. It is also possible to see the CPE models, the manufacturers and also the quantity of each one in the Provider base, which has the TR-069 enabled. The image below shows how the information is presented to the user. In the second option of the module, we have the CPE, in this tab are found several functionalities, used by the support, among them are: Change wifi password, name and channel, both 2.4Ghz and 5.8GHz Check status of LAN ports Check the time that the CPE is on Check the number of customers connected to the CPE, with the option of connecting customers’ history, to help support solve more difficult problems, without the need to go to the customer’s home. Check the PON signal from ONTs/ONUs Check if there is port forwarding on the CPE Image of the CPE, which helps the support team to better understand the equipment being supported The image below shows the tabs present inside the TR-069 CPE option This screen can also be found in the Realtime Graphic tab, when we select the PPPoE of the desired client, we go to Realtime Graphic. Then we go to the Equipment Management option, there the CPE settings can also be made via TR-069, this allows for greater agility when configuring the customer’s CPE Made4Graph has more than 20 templates from different Vendors/Manufacturers, for TR-069, with their respective parameters, specific configurations, in addition, in our approval base there are more than 40 models of CPEs from different manufacturers and equipment models that allow for flexibility when bringing your CPE base to the TR-069. The images below illustrate the available templates, as well as the equipment that was homologated within the TR-069. It is possible to restore CPE data after reset based on the template that was configured. There are still many other functionalities, at the end of this article I will leave a link where you can access the demo version of made4graph, and TR-069, for free. You can watch a tour of made4graph’s tr069 in this video here Any questions about how our tool works or a complete presentation of the tool, contact us and our team of specialists is available for you

¿Cómo solicitar un CDN de Google?

¡¡Hola gente!! Este es Luís Dias, consultor de Made4it y hoy vamos a hablar un poco de las CDN, más concretamente de Google Global Cache (GGC), un tema muy chulo e interesante que lleva mucho tiempo en nuestras vidas y que nos hace trabajar en escalabilidad mucho más fácil. Es un tema muy interesante y requiere un poco de atención, así que toma un café fuerte y ven conmigo. Primero, ¿qué es CDN? Una CDN, abreviatura de red de entrega de contenido, es un grupo de servidores distribuidos geográficamente que acelera la entrega de contenido web, acercándolo a donde se encuentran los usuarios finales. Este dispositivo utiliza el almacenamiento en caché, un proceso que almacena temporalmente copias de archivos para que pueda acceder al contenido de Internet desde un dispositivo más rápidamente a través de un servidor cercano. Los CDN almacenan en caché todo tipo de contenido, como páginas web, imágenes y videos. Esto le permite ver una película, descargar software, publicar en las redes sociales o comprar sin tener que esperar a que se cargue el contenido. GGC – Google Global Cache Los GGC o Google Global Cache, son Servidores de Google repartidos por ISPs en Brasil y en todo el mundo. Los GGC son servidores instalados dentro de las redes del ISP y del operador para mejorar la experiencia del usuario con el contenido de Google, brindando más velocidad, latencia y experiencia del usuario con los servicios de Google. El CDN de Google además de mejorar la experiencia de los usuarios con su plataforma, también se utiliza para reducir la congestión y reducir el tráfico, el PTT y el tráfico de Peering a Google. Reduciendo así costes para el ISP u Operador. Nada más que un muy buen intercambio, tanto para Google que sus usuarios están contentos con el rendimiento como para el ISP es muy bueno ya que ahorra en cantidad de Link o Tráfico. Cómo funciona GGC: Cuando un usuario solicita contenido, por ejemplo, un video, una página web o una imagen, el sistema de Google determina si el contenido se puede servir desde el nodo GGC. Si el nodo GGC tiene el contenido solicitado en su servidor de caché, entregará el contenido directamente al usuario final, mejorando la velocidad/latencia de navegación para el usuario y optimizando los recursos de ancho de banda del ISP. Si el contenido no se almacena en el servidor de caché, el nodo GGC recuperará ese contenido de los servidores de Google y lo almacenará para futuras solicitudes. Cómo se realiza la solicitud de GGC: Para poder realizar la solicitud de GGC, primero debemos saber cuánto tráfico tenemos para el contenido de Google. Porque como toda CDN, tenemos un requisito mínimo de ancho de banda para contenidos relacionados con Google, como Youtube, etc. Hoy, el ancho de banda mínimo es un tráfico superior a 3 Gbps, percentil 95 durante al menos 3 meses. Percentil 95*: es un cálculo matemático que se utiliza para evaluar el uso regular y sostenido de los enlaces de comunicación de la red. Pero te debes estar preguntando “Luís, ¿cómo voy a saber cuánto tráfico tengo para Google, para solicitar el GGC?” Para este procedimiento podemos usar una herramienta Netflow, en este caso estaré usando Made4Flow, la mejor herramienta y la herramienta Netflow más práctica del mercado. Entendamos cómo funciona esta magia: Al entrar nos encontramos frente al Dashboard de la herramienta, donde podemos especificar el tipo de tráfico que queremos que genere el informe de consumo, o podemos elegir el Dashboard que queremos, en este caso para ver el tráfico a Google, Netflix, Facebook , Akamai. Cuando entremos en la pestaña Google Dashboard, podremos ver cuánto tráfico total tenemos para Google y comprobar si podremos solicitar el CDN, ya que piden un percentil mínimo de tráfico. Después de analizarlo, pudimos continuar con la solicitud de GGC Para solicitar el GGC (Google Global Cache) es necesario ingresar al sitio web: https://isp.google.com/partner_request/?data.request_type=Peering Y rellenamos el formulario donde vamos a poner nuestros datos como ASN, nombre, dirección, etc. Después de que se apruebe la solicitud, recibiremos un correo electrónico informándonos si fuimos aprobados o no. Si se aprueba, Google nos indicará el paso a paso que debemos seguir y nos dará una estimación del tiempo que tardará el servidor en llegar a la dirección que le proporcionamos en el formulario. ¡Espero que hayas disfrutado y entendido el contenido! Si tienes alguna duda, ponte en contacto con nuestro equipo de expertos.

How to request a CDN from Google?

Hey guys!! This is Luís Dias, a consultant at Made4it and today we are going to talk a little about CDNs, more specifically Google Global Cache (GGC), a very cool and interesting topic that has been in our lives for a long time and that makes our work in scalability a lot easier. network. It’s a very interesting topic and requires a little attention, so grab a strong coffee and come with me. First what is CDN? A CDN short for Content delivery network is a geographically distributed group of servers that accelerates the delivery of web content, bringing it closer to where end users are. This device uses caching, a process that temporarily stores copies of files so that you can access Internet content from a device more quickly through a server near you. CDNs cache all kinds of content such as web pages, images and videos. This allows you to watch a movie, download software, post to social media or shop without having to wait for the content to load. GGC – Google Global Cache The GGC or Google Global Cache, are Google Servers spread across ISPs in Brazil and around the world. GGCs are servers installed within the ISP and Operator Networks to improve user experience with Google content, providing more speed, latency and user experience with Google Services. The Google CDN in addition to improving users’ experience with their platform, is also used to reduce congestion and reduce Traffic, PTT and Peering traffic to Google. Thus reducing costs for the ISP or Operator. Nothing more than a very good exchange, both for Google that its users are happy with the performance and for the ISP it is very good as it saves on the amount of Link or Traffic. How GGC works: When a user requests content – for example, a video, web page, or image, the Google System determines whether the content can be served from the GGC Node. If the GGC Node has the requested content in its Cache Server, it will serve the content directly to the end user, improving the navigation speed/latency for the user and optimizing the ISP’s bandwidth resources. If content is not stored in the Cache Server, the GGC Node will retrieve that content from Google’s servers and store it for future requests. How the GGC request is made: In order to be able to make the GGC request, we first need to know how much traffic we have for content from Google. Because like every CDN, we have a minimum bandwidth requirement for content related to Google, such as Youtube, etc. Today the minimum bandwidth is traffic greater than 3Gbps – 95th percentile for at least 3 months. 95 Percentile*– is a mathematical calculation used to evaluate regular and sustained use of network communication links. But you must be wondering “Luís, how will I know how much traffic I have for Google, to request the GGC?” For this procedure we can use a Netflow tool, in this case I will be using Made4Flow, the best tool and the most practical Netflow tool on the market. Let’s understand how this magic works: Upon entering, we are faced with the Dashboard of the tool, where we can specify the type of traffic we want to generate the consumption report, or we can choose the dashboard we want, in this case to see traffic to Google, Netflix, Facebook, Akamai. When we enter the Google Dashboard tab, we will be able to see how much total traffic we have for Google and check if we will be able to request the CDN, since they ask for a minimum percentile traffic. After analyzing it, we were able to proceed with the GGC request To request the GGC (Google Global Cache) it is necessary to enter the website: https://isp.google.com/partner_request/?data.request_type=Peering And we fill in the form where we are going to put our data such as ASN, name, address, etc. After the request is approved, we will receive an email, informing whether we were approved or not. If approved, Google will report to us the step by step that we must follow and will give us an estimate of how long it will take for the server to arrive at the address we provide in the form. I hope you enjoyed and understood the content! If you have any doubts, please contact our team of experts.

Como solicitar um CDN do Google?

Olá pessoal!! Aqui é o Luís Dias, consultor na Made4it e hoje iremos falar um pouco sobre CDNs, mais especificamente Google Global Cache (GGC), um tema muito bacana e interessante que já existe em nossas vidas a muito tempo e que facilita muito nosso trabalho em escalabilidade da rede. É um tema bem interessante e que requer um pouco de atenção, então pega um café bem forte e vem comigo.  Primeiro que é CDN? Um CDN abreviação de Content delivery network (Rede de Entrega de Conteúdo) é um grupo de servidores distribuídos geograficamente que acelera a entrega de conteúdo da Web, aproximando-o de onde os usuários finais estão. Esse equipamento utiliza o armazenamento em cache, um processo que armazena cópias de arquivos temporariamente, para que você possa acessar o conteúdo da Internet a partir de um dispositivo mais rapidamente por meio de um servidor próximo a você. Os CDNs armazenam todo tipo de conteúdo em cache, como página da Web, imagens e vídeos. Isso permite que você assista a um filme, faça downloads de software, publique nas redes sociais ou faça compras sem ter que esperar pelo carregamento do conteúdo. GGC – Google Global Cache O GGC ou Google Global Cache, são os Servidores do Google espalhados pelos ISP do Brasil e do mundo a fora. Os GGCs são servidores instalados dentro da Redes dos ISP e Operadoras para melhorar a experiência dos usuários com o conteúdo do google, provendo mais velocidade, latência e experiência destes usuários com os Serviços do Google. O CDN do Google além de melhorar a experiencia dos usuários com a plataforma deles, também é usado para reduzir o congestionamento e redução do trafego de Trânsito, PTT e Peering para o Google. Assim reduzindo custos para o ISP ou Operadora. Nada mais do uma troca muito boa, tanto para o Google que seus usuários ficam felizes com a performance e para o ISP fica muito bom pois economiza em quantidade de Link ou Trânsito. Como funciona o GGC: Quando um utilizador solicita um conteúdo – por exemplo, um vídeo, página web, ou uma imagem, o Sistema do Google determina se o conteúdo pode ser servido a partir do Nó GGC. Se o Nó GGC tiver o conteúdo solicitado no seu Servidor Cache, ele irá servir o conteúdo diretamente para o utilizador final, melhorando a rapidez/latência da navegação para o utilizador e otimizando os recursos de banda do ISP. Se o conteúdo não estiver armazenado no Servidor Cache, o Nó GGC vai recuperar esse conteúdo a partir dos servidores da Google e armazena para as futuras solicitações. Como é feita a solicitação do GGC: Para podermos fazer a solicitação do GGC, primeiro precisamos saber quanto temos de tráfego para conteúdo do Google. Pois como todo CDN, temos um requisito de mínimo de banda para conteúdos relacionados ao Google, como Youtube, etc. Hoje a banda mínima é um tráfego maior de 3Gbps – 95 percentil por pelo menos 3 meses. 95 Percentil* – é um cálculo matemático utilizado para avaliar o uso regular e sustentado de links de comunicação de rede. Mas você deve estar se perguntando “Luís, como eu vou saber quanto de tráfego eu tenho para o Google, para solicitar o GGC?” Para esse procedimento podemos utilizar uma ferramenta de Netflow, neste caso aqui estarei utilizando o Made4Flow, a melhor ferramenta e a mais pratica ferramenta de Netflow do mercado. Vamos entender como essa mágica funciona: Ao entrarmos nos deparamos com a Dashboard da ferramenta, onde conseguimos especificar o tipo de tráfego que queremos gerar o relatório de consumo, ou podemos escolher a dashboard que queremos, no caso para ver tráfego para o Google, Netflix, Facebook, Akamai. Ao entrarmos na aba Dashboard Google, iremos conseguir ver quanto temos de tráfego total para o Google e verificar se iremos conseguir solicitar o CDN, visto que eles pedem um tráfego percentil mínimo. Após analisarmos, conseguimos dar continuidade na solicitação do GGC Para fazermos a solicitação do GGC (Google Global Cache) é necessário entrarmos no site: https://isp.google.com/partner_request/?data.request_type=Peering E preenchermos o formulário onde vamos colocar os nossos dados como ASN, nome, endereço, etc. Após solicitação caso aprovado, iremos receber um e-mail, informando se fomos aprovados ou não. Caso aprovado, o Google ira nos reportar o passo a passo que devemos seguir e nos passará um prazo de estimativa de quanto tempo levará para o servidor chegar no endereço que fornecemos no formulário. Espero que tenham gostado e compreendido o conteúdo! Caso tenha alguma duvida entre em contato com nosso time de especialistas.

Controle de banda Seletivo no Roteador Huawei

Olá, meu nome é Gabriel Henrique, sou analista de redes aqui na Made4IT e hoje vou mostrar para vocês como configurar o controle de banda seletivo em usuários de camada de acesso nos roteadores da linha NE da Huawei. O controle de banda seletivo abre a possibilidade de novos produtos ou a melhora, incremento ou “charme” na entrega do serviço ao usuário final sendo um diferencial muito interessante, principalmente para ISPs que possuem CDN local. Mas, afinal, do que se trata o controle de banda seletivo ? Normalmente, nas implementações de BNGs/BRAS/PPPoE Server, temos como corriqueiro um controle de banda global (do ponto de vista do usuário) do qual todo e qualquer conteúdo é limitado pelo valor do plano contratado. No controle de banda seletivo, temos a possibilidade de atrelar diferentes bandas para diferentes serviços, aonde você pode por exemplo atrelar um controle de banda de valor “X” para o seu conteúdo local de CDN, “y” para o tráfego interno a sua rede e “z” quando a origem ou destino do tráfego é externo (links, transitos, Peering, IX/PTT, PNI, transportes…), podemos dizer que fazemos o QoS seletivo ou que controlamos especificamente quanto de banda por conteúdo ou também poderia ser dito que podemos tirar o controle de banda do CDN ou PBR seletivo. Enfim, chega de conversa, vamos para a parte mais legal 🙂 No nosso cenário de testes, temos: – Cliente com plano de 100Mbps – Necessidade de liberar até 500Mbps quando origem/destino for CDNs locais – Necessidade de manter 100Mbps quando origem/destino não forem CDNs Locais– CDNs locais endereçados com 192.0.2.0/24 e 2001:DB8::/64 Pré requisitos: – ERP/Radius com suporte ao AVP “Huawei-Policy-Name”– Domain de autenticação dos clientes com um “user-group” declarado (Se não sabe o que é user-group, fique ligado no blog da Made que logo logo tem um post sobre Firewall que vai explicar exatamente do que se trata 😉 Passo 1: Configurar, no system-view, os parâmetros de Radius necessários e ativar a função de “Value Added Service” no roteador. Passo 2: No Radius-group usado para autenticação, ativar o suporte a accounting do value-added-service Passo 3: Configurar as ACLs de acesso delimitando o tráfego de CDN e o tráfego geral Passo 4: Configurar os “classifiers” para classificar o tráfego das ACLs Passo 5: Configurar os “behaviors” que vamos usar para identificar cada um dos classifiers Passo 6: Configurar a traffic-policy que será atrelada globalmente, contendo o classifier e behavior configurados anteriormente, efetivando a classificação diferenciada dos fluxos Passo 7: Aplicar a traffic-policy globalmente. Passo 8: Configurar os qos-profiles que vão delimitar a banda dos respectivos conteúdos Passo 9: Configurar a policy que irá controlar a banda do cliente Pronto. Agora, basta o ERP/Radius entregar para o cliente o AVP Huawei-Policy-Name := 150m que, o cliente terá o controle de banda limitando até 500Mbps quando a origem/destino forem os CDNs locais, e até 100Mbps para as demais origens/destinos. Lembrando que se o ERP/Radius entregar o Huawei-Input-Average-Rate, o BRAS/BNG irá usa-lo preferencialmente e não ira aplicar o Policy name! A traffic-policy permite até 8 “tariff-levels” aonde você pode classificar seu tráfego em até 8 tipos de serviço e aplicar diferentes controles de banda para cada um deles. No caso de exemplo, caso queira configurar o controle de banda diferenciado para outros planos, basta criar novos “qos-profile” e “value-added-service policy” com os valores que deseja aplicar, pois o tráfego de CDN e geral já esta classificado em “tariff-levels” distintos. É isso aí, até a próxima! Qualquer duvida de como implantar essa configuração em sua rede entre em contato e converse com um dos nossos especialistas

Control selectivo de ancho de banda en el enrutador Huawei

Hola, mi nombre es Gabriel Henrique, soy analista de redes aquí en Made4IT y hoy les mostraré cómo configurar el control de ancho de banda selectivo en los usuarios de la capa de acceso en los enrutadores de la línea NE de Huawei. El control selectivo de ancho de banda abre la posibilidad de nuevos productos o la mejora, incremento o “encanto” en la entrega del servicio al usuario final, siendo un diferencial muy interesante, principalmente para los ISP que cuentan con un CDN local. Pero, después de todo, ¿qué es el control selectivo del ancho de banda? Normalmente, en implementaciones de BNGs/BRAS/PPPoE Server, tenemos como lugar común un control de ancho de banda global (desde el punto de vista del usuario) cuyo contenido está limitado por el valor del plan contratado. En el control selectivo de ancho de banda, tenemos la posibilidad de vincular diferentes bandas a diferentes servicios, donde puedes, por ejemplo, vincular un control de ancho de banda de valor “X” para el contenido de tu CDN local, “y” para el tráfico interno a tu red y ” z” cuando el origen o destino del tráfico es externo (enlaces, tránsitos, Peering, IX/PTT, PNI, transportes…), podemos decir que hacemos QoS selectiva o que controlamos específicamente cuánto ancho de banda por contenido o También se podría decir que podemos quitarle el control de ancho de banda a CDN o PBR selectivo. De todos modos, basta de hablar, vayamos a la parte divertida 🙂 En nuestro escenario de prueba, tenemos: – Cliente con plan 100Mbps – Necesidad de liberar hasta 500 Mbps cuando el origen/destino son CDN locales – Necesidad de mantener 100 Mbps cuando el origen/destino no son CDN locales– CDN locales direccionados con 192.0.2.0/24 y 2001:DB8::/64 Requisitos previos: – ERP/Radius con soporte AVP “Huawei-Policy-Name”– Dominio de autenticación de cliente con un “grupo de usuarios” declarado (si no sabe qué es un grupo de usuarios, permanezca atento al blog de Made, que pronto tendrá una publicación sobre Firewall que explicará exactamente de qué se trata;) Paso 1: Configure, en la vista del sistema, los parámetros Radius necesarios y active la función “Servicio de valor agregado” en el enrutador. Paso 2: en el grupo Radius utilizado para la autenticación, habilite el soporte de contabilidad de servicio de valor agregado Paso 3: Configure las ACL de acceso que delimitan el tráfico CDN y el tráfico general Paso 4: configurar “clasificadores” para clasificar el tráfico de las ACL Paso 5: Configurar los “comportamientos” que usaremos para identificar cada uno de los clasificadores Paso 6: Configure la política de tráfico que se vinculará globalmente, que contenga el clasificador y el comportamiento previamente configurados, efectuando la clasificación diferenciada de los flujos. Paso 7: Aplicar la política de tráfico globalmente. Paso 8: Configurar los qos-profiles que delimitarán el ancho de banda de los respectivos contenidos Paso 9: Configure la política que controlará el ancho de banda del cliente Listo. Ahora, el ERP/Radius solo necesita entregar el AVP Huawei-Policy-Name := 150m al cliente, y el cliente tendrá control de ancho de banda limitando hasta 500Mbps cuando el origen/destino son los CDN locales, y hasta 100Mbps para los otros orígenes/destinos. ¡Recordando que si el ERP/Radius entrega el Huawei-Input-Average-Rate, el BRAS/BNG lo usará preferencialmente y no aplicará el nombre de la Política! La política de tráfico permite hasta 8 “niveles de tarifas” donde puede clasificar su tráfico en hasta 8 tipos de servicio y aplicar diferentes controles de ancho de banda para cada uno de ellos. En el caso del ejemplo, si desea configurar el control de ancho de banda diferenciado para otros planes, simplemente cree nuevos “qos-profile” y “value-added-service policy” con los valores que desea aplicar, ya que el CDN y general el tráfico ya está clasificado en diferentes “niveles de tarifas”. Eso es todo, ¡hasta la próxima! Si tienes dudas sobre cómo implementar esta configuración en tu red, ponte en contacto y habla con uno de nuestros especialistas.

Selective Bandwidth Control in Huawei Router

Hello, my name is Gabriel Henrique, I am a network analyst here at Made4IT and today I will show you how to configure selective bandwidth control on access layer users on Huawei’s NE line routers. Selective bandwidth control opens up the possibility of new products or the improvement, increment or “charm” in the delivery of the service to the end user being a very interesting differential, especially for ISPs that have local CDN. But, after all, what is selective band control all about? Normally, in BNGs/BRAS/PPPoE Server implementations, it is commonplace to have a global bandwidth control (from the user’s point of view) of which any and all content is limited by the value of the contracted plan. In selective bandwidth control, we have the possibility of assigning different bands to different services, where you can for example assign a bandwidth control value of “X” for your local CDN content, “y” for internal traffic to your network and “z” when the source or destination of traffic is external (links, transits, Peering, IX/PTT, PNI, transports…), we can say that we do selective QoS or that we specifically control how much bandwidth per content or it could also be said that we can take bandwidth control away from selective CDN or PBR. Anyway, enough talk, let’s get to the cool part 🙂 In our test scenario, we have: – Customer with 100Mbps plan – Need to free up to 500Mbps when source/destination is local CDNs – Need to maintain 100Mbps when source/destination are not Local CDNs– Local CDNs addressed with 192.0.2.0/24 and 2001:DB8::/64 Pre-requisites: – ERP/Radius with AVP support “Huawei-Policy-Name– Domain of authenticating clients with a declared “user-group” (If you don’t know what user-group is, stay tuned to Made’s blog and soon there will be a post about Firewall that will explain exactly what it is about 😉 Step 1: Configure, in the system-view, the necessary Radius parameters and activate the “Value Added Service” function in the router. Step 2: In the Radius-group used for authentication, enable value-added-service accounting support Step 3: Configure access ACLs delimiting CDN traffic and general traffic Step 4: Configure “classifiers” to classify traffic from ACLs Step 5: Configure the behaviors we will use to identify each of the classifiers Step 6: Configure the traffic-policy that will be linked globally, containing the previously configured classifier and behavior, effecting the differentiated classification of the flows Step 7: Apply the traffic-policy globally. Step 8: Configure the qos-profiles that will delimit the bandwidth of the respective contents Step 9: Configure the policy that will control the client’s bandwidth Ready. Now, ERP/Radius just needs to deliver the AVP Huawei-Policy-Name := 150m to the customer, and the customer will have bandwidth control limiting up to 500Mbps when the origin/destination are the local CDNs, and up to 100Mbps for the other origins /destinations. Remember that if ERP/Radius delivers the Huawei-Input-Average-Rate, BRAS/BNG will use it preferentially and will not apply the Policy name! The traffic-policy allows up to 8 “tariff-levels” where you can classify your traffic into up to 8 service types and apply different bandwidth controls for each of them. In the example case, if you want to configure differentiated bandwidth control for other plans, just create a new “qos-profile” and “value-added-service policy” with the values you want to apply, since the CDN and general traffic is already classified in distinct “tariff-levels”. That’s it, until next time! If you have any doubts about how to implement this configuration in your network, get in touch and talk to one of our specialists.

Como Funciona o TR-069?

Já vimos um pouco das funcionalidades do TR069, para a acessar o conteúdo onde apresentamos o que é o TR069 leia o nosso primeiro artigo, agora veremos como essa “magica” funciona.  TR-069 é baseado em SOAP/HTTP, onde é feita a conexão entre a CPE e o ACS. A comunicação é feita através de chamadas de procedimento remoto (RPC), isso permite a CPE encaminhar os parâmetros, além do seu status atual, bem como gerência de firmware para o ACS. É muito importante lembrar que, quem inicia a conexão é a CPE, vai partir dela o primeiro contato, e também os informes periódicos ao ACS, pois a cada fração de tempo a CPE encaminha ao ACS um informa para que o ACS atualize seu status no servidor. O ACS somente vai iniciar o contato em momentos específicos, como: atualização de firmware, ou ainda uma interação iniciada pelo operador, mas que devem ser aceitas pela CPE para que seja concluído a ação. A imagem acima mostra a comunicação entre a CPE e o ACS, onde a CPE encaminha uma solicitação de conexão para o ACS, perceba que nesta foto, a CPE já é conhecida pelo ACS, do contrário a comunicação teria alguns campos a mais, como o GetParamenterNames request, onde esta solicitação parte do ACS para a CPE, com a intenção de conhecer os parâmetros que podem ser entregues ao ACS. Open connection: a CPE informa que quer falar com o ACS SSL initiation: é adicionado a comunicação um certificado para proteger a troca de mensagens inform request: a CPE diz ao ACS que vai informar seu status atual inform response: o ACS diz que a CPE pode encaminhar os parâmetros a ele HTTP post(empty): a CPE diz OK GetParameterValues request: requisição dos parâmetros da CPE GetParameterValues response: resposta da CPE com os parâmetros para o ACS SetParameterValues request: o ACS informa que agora conhece os parâmetros, e que precisa dos valores dos parâmetros da CPE SetParameterValues response: a CPE informa ao ACS os valores dos parâmetros, requisitados pelo ACS. HTTP response empty: o ACS informa que não existe mais informações para serem trocadas entre eles, e que pode ser finalizada a comunicação. Close connection: A CPE finaliza a conexão. É possível ter essa funcionalidade na sua rede de forma simples, que é através do módulo do TR069 no Made4graph, onde todas as informações necessárias ficam dentro da própria interface do software. Para você conhecer o Made4graph e os benefícios da ferramenta você pode acessar a demo ou então marcar uma demonstração com o time comercial 😁

¿Cómo funciona el TR-069?

Ya hemos visto algunas de las características del TR069, para acceder al contenido donde presentamos qué es el TR069, lee nuestro primer artículo, ahora veremos cómo funciona esta “magia”. TR-069 está basado en SOAP/HTTP, donde se realiza la conexión entre el CPE y el ACS. La comunicación se realiza a través de llamadas de procedimiento remoto (RPC), esto permite que el CPE envíe los parámetros, además de su estado actual, así como la gestión del firmware al ACS. Es muy importante recordar que es el CPE quien inicia la conexión, de él saldrá el primer contacto, y también los reportes periódicos al ACS, porque en cada fracción de tiempo el CPE envía un reporte al ACS para que el ACS actualiza su estado en el servidor. El ACS solo iniciará contacto en momentos específicos, tales como: actualización de firmware, o incluso una interacción iniciada por el operador, pero que debe ser aceptada por el CPE para que la acción se complete. La imagen de arriba muestra la comunicación entre el CPE y el ACS, donde el CPE envía una solicitud de conexión al ACS, observe que en esta imagen, el CPE ya es conocido por el ACS, de lo contrario, la comunicación tendría algunos campos más, como Solicitud GetParamenterNames, donde esta solicitud parte del ACS al CPE, con la intención de conocer los parámetros que se pueden entregar al ACS. Conexión abierta: la CPE informa que quiere hablar con la ACS Iniciación SSL: se añade un certificado a la comunicación para proteger el intercambio de mensajes solicitud de informe: el CPE le dice al ACS que informará su estado actual informar respuesta: el ACS dice que el CPE puede enviarle los parámetros Publicación HTTP (vacía): CPE dice OK Solicitud GetParameterValues: solicitud de parámetros CPE Respuesta GetParameterValues: respuesta CPE con parámetros para ACS Petición SetParameterValues: el ACS informa que ya conoce los parámetros, y que necesita los valores de los parámetros del CPE Respuesta SetParameterValues: el CPE informa al ACS de los valores de los parámetros solicitados por el ACS. Respuesta HTTP vacía: el ACS informa que no hay más información para intercambiar entre ellos y que la comunicación puede finalizar. Close connection: A CPE finaliza a conexão. Es posible tener esta funcionalidad en tu red de una manera sencilla, que es a través del módulo TR069 en Made4graph, donde toda la información necesaria se encuentra dentro de la propia interfaz del software. Para que lo sepas Made4graphy las ventajas de la herramienta puede acceder al demoo programa una demostración con el equipo comercial 😁.

How does the TR-069 work?

We’ve already seen some of the TR069’s features, to access the content where we present what the TR069 is, read our first article, now we’ll see how this “magic” works. TR-069 is based on SOAP/HTTP, where the connection between the CPE and the ACS is made. Communication is done through remote procedure calls (RPC), this allows the CPE to forward the parameters, in addition to their current status, as well as firmware management to the ACS. It is very important to remember that it is the CPE who initiates the connection, the first contact will come from it, and also the periodic reports to the ACS, because at each fraction of time the CPE sends a report to the ACS so that the ACS updates its status in the server. The ACS will only initiate contact at specific times, such as: firmware update, or even an interaction initiated by the operator, but which must be accepted by the CPE for the action to be completed. The image above shows the communication between the CPE and the ACS, where the CPE forwards a connection request to the ACS, notice that in this picture, the CPE is already known by the ACS, otherwise the communication would have some more fields, such as GetParamenterNames request, where this request departs from the ACS to the CPE, with the intention of knowing the parameters that can be delivered to the ACS. Open connection: the CPE informs that it wants to talk to the ACS SSL initiation: a certificate is added to the communication to protect the exchange of messages inform request: the CPE tells the ACS that it will inform its current status inform response: the ACS says that the CPE can forward the parameters to it HTTP post(empty): CPE says OK GetParameterValues ​​request: request for CPE parameters GetParameterValues ​​response: CPE response with parameters for ACS SetParameterValues ​​request: the ACS informs that it now knows the parameters, and that it needs the values ​​of the CPE parameters SetParameterValues ​​response: the CPE informs the ACS of the parameter values ​​requested by the ACS. HTTP response empty: the ACS informs that there is no more information to be exchanged between them, and that the communication can be ended. Close connection: The CPE closes the connection. It is possible to have this functionality in your network in a simple way, which is through the TR069 module in Made4graph, where all the necessary information is within the software interface itself. For you to know Made4graphand the benefits of the tool you can access the demoor schedule a demonstration with the commercial team 😁.