gráficas de usuario (GUIs) no estándar y requieren que el usuario humano siga una secuencia de pasos manuales para resolución de problemas. En adición, se necesita una cobertura de sistema de soporte de operaciones (OSS) de protocolo de gestión de red simple (S MP) para monitorear el desempeño de Ethernet. El diagnóstico de problemas con frecuencia requiere que un operador o técnico se conecte a ambos lados de un enlace Ethernet, lo que no solamente aumenta la complejidad de la resolución de problemas, sino que puede ser difícil o imposible si el extremo opuesto comprende equipo de un cliente. Como no es generalmente posible un diagnóstico extremo a extremo de conexiones Ethernet desde un solo extremo, el aislamiento de falla frecuentemente implica enviar a un técnica hacia abajo de una "cadena" de puntos designados en una red hasta que se aisla la ubicación de la falla. Esto tanto consume mucho tiempo como es costoso. En consecuencia, lo que se necesita es un sistema y un método para aprovisionamiento, monitoreo y prueba de servicios Ethernet de un solo extremo. En adición, es deseable proveer servicios de clase de empresa de comunicaciones por una pluralidad de tipos de medios . Compendio Se provee un avance técnico por medio de un método y un sistema para detectar y diagnosticar una falla en una interfaz de servicio Ethernet. La falla es detectada y diagnosticada desde un primer punto en un enlace de comunicaciones, donde el enlace de comunicaciones incluye una interfaz de servicio Ethernet y termina en un segundo punto. El método comprende monitorear el enlace desde el primer punto para detectar una ocurrencia de la falla, donde la falla ocurre entre los puntos primero y segundo.
Al menos un atributo de falla es identificado cuando se detecta la falla, donde el atributo de falla es identificado desde el primer punto, y se categorizan una o mas causas potenciales de la falla con base en el atributo de falla identificado. Breve Descripción de los Dibujos La figura 1 es un diagrama de flujo que ilustra un método para establecer, gestionar y aislar fallas desde un solo extremo de una conexión Ethernet . La figura 2 es una red ejemplar en la cual puede implementarse el método de la figura 1. Las figuras 3 y 4 son diagramas de flujo que ilustran otra forma de realización de un método par establecer, gestionar y aislar fallas desde un solo extremo de una conexión de Ethernet en la red de la figura 2. La figura 5 es otra red ejemplar en la cual puede implementarse el método de la figura 1. Las figuras 6 y 7 son diagramas de flujo que ilustran otra forma de realización de un método para establecer, gestionar y aislar fallas a partir de un solo extremo de una conexión Ethernet en la red de la figura 5.
La figura 8 ilustra una forma de realización de un sistema ejemplar para conmutar remotamente un estado de línea entre terminado y no terminado . Las figuras 9 y 10 ilustran otra forma de realización de un sistema ejemplar para conmutar remotamente un estado de linea entre terminado y no terminado. Descripción Detallada La presente divulgación se refiere generalmente a servicios de comunicaciones y, de manera mas especifica, a un sistema y un método para desplegar y gestionar servicios de
Ethernet. Sin embargo, se entiende que la siguiente divulgación provee muchas formas de realización diferentes, o ejemplos, para implementar características diferentes de la invención. Ejemplos específicos de componentes y arreglos son descritos mas adelante para simplificar la presente divulgación. Por supuesto, son meramente ejemplos y no están destinados a ser limitativos. En adición, la presente divulgación puede repetir números y/o letras de referencia en los diversos ejemplos. Esta repetición es para fines de simplicidad y claridad y no dicta por sí misma una relación entre las diversas formas de realización y/o configuraciones discutidas. Haciendo referencia a la figura 1, en una forma de realización, un método 10 es operable para proveer capacidades Ethernet pre-servicio, en servicio y fuera de servicio desde un solo extremo de una red. Como se describirá posteriormente en mayor detalle, esto permite a un proveedor de servicios provisio-nar y monitorear una interfaz de servicio de Ethernet, así como detectar y diagnosticar fallas en la interfaz de servicio de Ethernet en una manera efectiva en costos. Tal funcionalidad puede ser alcanzada, por ejemplo, usando equipo de prueba de cables para añadir capacidades de monitoreo y diagnóstico a equipo anterior para servicios de extremo a extremo . En el paso 12, se establece un estado inicial. Esto puede incluir, por ejemplo, establecer un enlace, verificar un estado del enlace, verificar el servicio, probar la longitud del cable, obtener parámetros de servicio, y acciones similares. En el paso 14, se realiza una determinación acerca de si el enlace satisface un cierto criterio pre-definido de desempeño. Si falla el estado del enlace, el método 10 pasa al paso 24, donde se realiza un intento por aislar la falla. El método 10 continúa entonces al paso 26, donde se corrige la falla. El tipo de corrección puede depender de la falla, y puede variar de la activación de procedimientos automáticos de corrección para iniciar un rol de servicio para enviar a un técnico a un lugar donde se diagnosticó la falla. El método 10 regresa entonces al paso 14. Si el estado del enlace pasa al paso 14, el método 10 continúa al paso 16 donde ocurre un proceso de auto-negociación. Si falla el proceso de auto-negociación, como se determina en el paso 18, el método 10 pasa a los pasos 24 y 26 para aislar y corregir la falla. Si es exitosa la auto-negociación, el método 10 continúa al paso 20, donde monitorea fallas en el enlace, degradación de servicio, y otros problemas. El monitoreo puede incluir comparar condiciones de servicio actuales (v.gr., pérdida de paquetes) con un conjunto pre-definido de parámetros. Si ocurre una falla, como se determina en el paso 22, el método 10 continúa a los pasos 24 y 26 para aislar y corregir la falla. En consecuencia, el método permite identificar y aislar un problema en una conexión Ethernet desde un solo extremo de la conexión Ethernet (v.gr., desde un extremo del proveedor de servicio) . Haciendo referencia ahora a la figura 2, una red 30 ejemplar provee un marco dentro del cual el método 10 de la figura 1 puede ejecutarse para proveer servicios de Ethernet a partir de un proveedor de servicios 32 a una pluralidad de dispositivos de suscriptor 34. El proveedor de servicios 32 puede estar ubicado en una oficina central o un punto de presencia similar que se conecta a la red 30 a través de un dispositivo 36, tal como un multiplexor de adición/caída (ADM) de una red óptica sincrónica (SONET) , que forma parte de una red SONET 37. El dispositivo 36 está conectado vía fibra óptica a otro dispositivo 38, que está ubicado relativamente cerca de los dispositivos de suscriptor 34 debido a las limitaciones de distancia impuestas por la conectividad Ethernet. El dispositivo 38, que incorpora tecnología SONET ADM, es operable para separar datos destinados para los dispositivos de suscriptor 34 de otros datos que están siendo transportados a través de la red SONET, así como para añadir datos de los dispositivos de suscriptor 34 antes de pasarlos al dispositivo 36. El dispositivo está conectado a los dispositivos de suscriptor 34 a través del cableado 40 apropiado para comunicaciones Ethernet (v.gr. , cable categoría 5 (CAT 5) ) . Cada cable puede estar conectado a un interruptor 42 de capa 2 (L2) que sirve para terminar los servicios de Ethernet en cada dispositivo suscriptor 34. En adición, pueden desplegarse reflectómetros de dominio de tiempo (TDRs) (no mostrados) ya sea entre el dispositivo 38 y el interruptor L2 42 o dentro del dispositivo 38 mismo. Los TDRs ayudan en el aislamiento de falla a lo largo de los cables 40 y los dispositivos 34, 38 asociados. En el presente ejemplo, el dispositivo 38 incluye una pluralidad de puertos Ethernet base T 10/100 (no mostrados) , que se proveen como un módulo. Estos puertos Ethernet permiten a los dispositivos de suscriptor 34 conectarse directamente al dispositivo 38 vía un cable Ethernet estándar (10 base X, 100 base TX) . En este modo de conexión directa, las capas físicas de Ethernet comúnmente disponibles (PHYs) asociadas con los puertos Ethernet del dispositivo 38 pueden proveer visibilidad acrecentada de las condiciones del enlace y monitoreo del desempeño en los puertos Ethernet . Los puertos Ethernet son modelados como puertos de cliente . Haciendo ahora referencia a las figuras 3 y 4, en otra forma de realización, un método 50 utiliza los pasos 52-78 para habilitar gestión desde un solo extremo del dispositivo 38 y sus componentes asociados por el proveedor de servicios 32 para inicializar, monitorear y diagnosticar problemas con una interfaz de servicio Ethernet, como sigue. En el presente ejemplo, el método 50 es implementado extendiendo las capacidades provistas por comandos de lenguaje de transacción 1 (TL1) en servicios de transporte de datos . Una descripción mas detallada de comandos específicos e información asociada se divulga en la solicitud de patente US provisional (expediente del abogado No. 31873.18), presentada el 9 de diciembre de 2002, e incorporada en la presente por referencia como si se reprodujera en su totalidad. Pueden también usarse otros protocolos e interfaces de gestión, tales como SNMP, CLI , CORBA, CMISE, y GUI. Iniciando en el paso 52, se establece un enlace y se determinan los parámetros del enlace . Esto puede incluir provisionar el módulo Ethernet (v.gr., usando un comando ENT-EQPT) y provisionar la interfaz de servicio Ethernet (v.gr., usando un comando ENT-E100) , con parámetros de puerto por defecto a valores predeterminados. Un servicio Ethernet es creado conectando una de las interfaces a una instalación de transporte (v.gr., el dispositivo 36) . Pueden definirse otras capacidades, tal como el control de la sobre-suscripción (v.gr. , donde el ancho de banda necesitado por los servicios/suscriptores excede la capacidad de la red) y parámetros de puerto (v.gr., un límite en la tasa de puerto) . Antes de que se ponga en servicio una interfaz Ethernet, el método 50 determina un estado actual del enlace (v.gr., bueno o malo) en el paso 54. Si el estado del enlace es malo, el método 50 entra a una etapa de aislamiento de falla, que se describirá posteriormente con respecto de la figura 4. Si el estado del enlace es bueno, el método 50 continúa al paso 56, donde se inicia un procedimiento de auto-negociación. Si no es exitosa la auto-negociación, como se determina en el paso 58, el método 50 continúa a la etapa de aislamiento de falla de la figura 4. Si la auto-negociación es exitosa, el método 50 continúa al paso 60, donde los parámetros de enlace (v.gr., estado del cable y longitud del cable) son capturados. Los parámetros capturados pueden ser usados para fines de aislamiento de fallas futuras. Por ejemplo, puede usarse la longitud de cable capturada en reportes de fallas futuras para determinar si reportar las fallas como "de extremo cercano" (v.gr., el extremo en el equipo del proveedor de servicio, dispositivo 38) , o "de extremo lejano" (v.gr., el extremo en los dispositivos de suscriptor 34) . Aunque no se muestra, antes de poner en servicio la interfaz Ethernet, pueden ejecutarse otros pasos. Por ejemplo, si la interfaz Ethernet soporta indicación de fallas remotas durante auto-negociación, entonces el método 50 puede revisar si está tal indicador. A mayor abundamiento, el presente método 50 incorpora en servicio automático (AINS) , que permite a un operador poner un puerto Ethernet en el estado en servicio antes de que se una un cable físico al puerto. Cualesquiera alarmas en el puerto serán desestimadas hasta que el método 50 haya detectado una señal válida en el puerto por algún periodo de tiempo pre-definido (v.gr., diez segundos) . Una vez que ha transcurrido el periodo de tiempo, el puerto revertirá al modo de operación normal y reportará alarmas . Una vez que se pone la interfaz Ethernet en servicio, el método 50 continúa a los pasos 62, 64 y lleva a cabo operaciones de monitoreo. El monitoreo puede verificar falla del enlace, pérdida de contacto con la empresa de comunicaciones y/o de señal, condiciones de baja luz (para interfaces de fibra óptica) , re-inicio de auto-negociación, indicación de falla remota, y fallas, tales como aquellas generadas por parámetros incorrectos del enlace (v.gr., estado y longitud del cable) . El monitoreo puede también verificar otras fallas y aspectos de degradación del servicio, así como estadísticas de recolección para análisis de tendencias. Si se detecta una falla en el paso 64, el método entre en un periodo de transición a un estado autónomo fuera de servicio (OOS-AU) y continúa al paso 66 de la figura 4 para intentar aislar la falla. Se entenderá que algunas pruebas pueden ocurrir mientras la interfaz Ethernet está en servicio, mientras que otras pruebas pueden requerir que la interfaz sea removida de servicio (v.gr., pruebas disruptivas) . Por ejemplo, en el presente ejemplo, pueden ocurrir pruebas en servicio para probar la longitud del cable durante operación regular en modos de 100 y 1,000 Mbps . Pruebas fuera de servicio pueden permitir la prueba del dispositivo 38 y sus puertos asociados, y los cables que llevan al dispositivo 38. A mayor abundamiento, las pruebas fuera de servicio pueden probar transmisores de salida y receptores de entrada del equipo vía un retorno de espira interno, así como llevar a cabo análisis de problemas de cables Ethernet terminado y no terminado. El análisis no terminado incluye, por ejemplo, aislamiento de falla a lo largo de un cable y, para cada cable conectado a un puerto, identificar circuitos abiertos, corto circuitos, y desequilibrios de impedancias . La estimación de la longitud de cable en un cable terminado de manera apropiada puede usarse para identificar el lugar de una falla subsecuente. Haciendo ahora referencia a la figura 4, y con referencia continuada a la figura 3, una o mas pruebas son corridas de manera automática para determinar si la falla detectada en el paso 64 es debida a una falla local de equipo, falla remota de equipo, o problema de un cable. En el paso 66, se conduce una prueba de retorno de espira en el equipo local . Si se determina en el paso 68 que ha fallado la prueba de retorno de espira local, entonces la falla es factible que se deba a una falla de equipo local, como se indica por el paso 70. Pueden tomarse medidas correctivas y el método 50 regresa al paso 56. Si pasa la prueba de retorno de espira local, entonces la falla no está en el equipo local y el método 50 continúa al paso 72, donde se realiza una verificación de estado de cable. El estado del cable puede ser determinado usando, por ejemplo, PHYs de Ethernet con capacidad TDR integrada o TDRs solos, como se describió con respecto de la figura 2 y puede ser ocasionado por varios problemas. Por ejemplo, una longitud de cable de Ethernet inválida puede ser ocasionada por una terminación inapropiada, mientras que un cambio en la longitud de cable desde un valor caracterizado inicialmente (obtenido en el paso 60) puede indicar un cambio al cable (v.gr., la adición de un segmento de cable malo) . Si se determina en el paso 74 que el estado del cable no es válido (v.gr., el cable está desconectado o roto) , entonces la falla es factible se deba a un problema de cable, como se indica en el paso 78. Si el estado del cable es válido, entonces la falla es factible se deba a una falla de equipo remoto. Pueden tomarse medidas correctivas en el paso 80 y el método 50 regresa al paso 52. Se entenderá que la figura 4 puede ser expandida para englobar una variedad de escenarios de falla, tales como falla de auto-negociación. En consecuencia, el método 50 de las figuras 3 y 4 utiliza componentes de la red 30 de la figura 2 para proveer y gestionar servicios de Ethernet. A mayor abundamiento, el método 50 permite la detección y el aislamiento de fallas para permitir al proveedor de servicio 32 identificar rápidamente y enfocarse a disrupciones y disrupciones potenciales en el servicio Ethernet. Después de que se detecta y aisla una falla, puede generarse un reporte detallado relativo a la falla, diversos atributos de falla (v.gr. , tipo, lugar), e información similar. Haciendo ahora referencia a la figura 5, en todavía otra forma de realización, una red 90 ejemplar provee un marco dentro del cual puede ejecutarse el método 10 de la figura 1 para proveer servicios de Ethernet a partir de un proveedor de servicio 92 a una pluralidad de dispositivos de suscriptor 94. El proveedor de servicio 92 está conectado a un dispositivo 96 a través de una conexión de fibra óptica a base de SONET 98. El dispositivo 96 es operable para conectar el proveedor de servicio 92 a un dispositivo 102 (v.gr., un convertidor de medios) a través de una red de cables de cobre 100 usando, por ejemplo, un servicio de extensión de medios de Ethernet (EMX) en el cual los cuadros de Ethernet son llevados por la red de cables de cobre 100. La red 100 en el presente ejemplo es la planta de espira local compuesta por pares de cobre trenzados, tal como se conoce en la materia. El dispositivo 102 incluye una interfaz (v.gr., un modem) para comunicarse via una línea de suscriptor digital (v.gr., DSL, SHDSL, VDSL; que en lo sucesivo se refieren colectivamente como DSL) con el dispositivo 96, y una interfaz Ethernet para proveer servicios Ethernet a los dispositivos suscriptores 94 vía cableado compatible con Ethernet 104. El dispositivo 102 presenta los dispositivos de suscriptor 94 con los puertos de interfaz base T 10/100 y puede usar tecnologías DSL en una interfaz de red de área amplia (WAN) para extender el alcance de un enlace Ethernet hasta varios miles de pies (metros) . Si se provee una interfaz WAN, el dispositivo 102 provee visibilidad acrecentada de las condiciones de espira y monitoreo de desempeño en los puertos Ethernet del dispositivo de suscriptor, así como gestión acrecentada del enlace WAN vía técnicas de gestión de espira DSL y canales de gestión adosados. De esta manera, los problemas asociados con la extensión WAN pueden ser diagnosticados y las características de gestión de un solo extremo pueden ser implementadas en la interfaz de cliente. En el presente ejemplo, las interfaces tanto Ethernet como DSL proveen sus respectivos puertos a través de módulos. Los puertos Ethernet son modelados como puertos de cliente y, para activar los puertos, el módulo Ethernet es primero aprovisionado (ya sea manual o automáticamente) . Los puertos Ethernet en el módulo pueden ser entonces provisionados . En el presente ejemplo, cada uno de los puertos Ethernet puede estar asociado con AINS , que permite al puerto Ethernet ser re-aprovisionado en un estado listo antes de que se una al puerto un dable físico. Cualesquiera alarmas en el puerto Ethernet serán desestimadas hasta que se haya detectado una señal válida en el puerto por un periodo de tiempo predeterminado (v.gr., diez segundos) . Una vez que ha transcurrido el periodo de tiempo, el puerto Ethernet revertirá al modo de operación normal y reportará alarmas. El dispositivo 102 puede también conducir aislamiento automático de falla de Ethernet al detectarse una falla usando características de diagnóstico de cable y equipo, que se describirán en mayor detalle en el siguiente texto. Por ejemplo, cuando se detecta una falla de enlace entre el equipo suscriptor y el dispositivo 102, diagnósticos automáticos de aislamiento pueden intentar un retorno de espira de puerto de equipo en el dispositivo 102 para verificar las funciones del transmisor y el receptor. Si no se detectan falla del transmisor o receptor, una falla de espira sería reportada. En adición, el dispositivo 102 puede extender los servicios de Ethernet a rangos del área de servicio de la empresa de comunicaciones y ocultar detalles de la gestión del enlace DSL de un operador. En consecuencia, debido a que el sistema aprovisiona automáticamente el enlace DSL, no existe necesidad de aprovisionar manualmente el enlace DSL cuando se crean puertos Ethernet "remotos" . Los puertos Ethernet pueden expedir alarmas al detectar condiciones o eventos pre-definidos . Por ejemplo, puede expedirse una alarma con base en una falla de enlace, una recepción de chirrido (v.gr., una condición donde una estación transmite por un periodo de tiempo mas largo que la longitud de paquete permisible) , o una falla remota. Estas alarmas son reportadas desde un dispositivo 102 al dispositivo 96 que las reporta al operador 92. Un enlace y puerto DSL implementado vía la interfaz DSL del dispositivo 102 (y módulo) puede también ser la fuente de fallas. Por ejemplo, el dispositivo 102 puede monitorear la interfaz DSL respecto de condiciones de alarma, tales como pérdida de señal, pérdida de sincronización, y defectos de atenuación de espira (v.gr., donde se excede un umbral de atenuación de espira) . Las fallas de puerto y equipo DSL pueden expedir alarmas asociadas con terminación de la red, pérdida de energía, falla de modem, remoción de módulo de puerto (v.gr., el módulo que termina el puerto es removido) , y aprovisionamiento desequilibrado (v.gr., hay un módulo que causa desequilibrio con el módulo físico presente en una ranura) . El monitoreo del desempeño puede ocurrir en dos puntos . Primero, el monitoreo del desempeño EtherStat puede ser conducido en los puertos Ethernet en el dispositivo 102 para permitir al proveedor de servicio monitorear las condiciones de tráfico entrante del dispositivo de suscriptor en un punto de demarcación pre-definido . En segundo lugar, el enlace DSL puede ser monitoreado tanto en el dispositivo 96 como en el dispositivo 102 para proveer información relacionada con la condición y el desempeño de la espira local digital entre el proveedor de servicio 96 y los dispositivos de suscriptor 102. Pueden recolectarse datos estadísticos, como se describió previamente.
Por ejemplo, pueden generarse reportes periódicos que detallen el estado de los enlaces tanto DSL como Ethernet en el tiempo. El desempeño del enlace DSL es monitoreado para las direcciones tanto corriente arriba como corriente abajo. En la dirección corriente abajo, el modem asociado con el dispositivo 102 recolecta conteos de desempeño que son remitidos al dispositivo 96. En la dirección corriente arriba, el enlace DSL es monitoreado en el punto de terminación en el módulo DSL. El monitoreo del desempeño puede recolectar una variedad de diferentes estadísticas, como se divulga en la solicitud de patente US provisional (expediente del abogado 31873.18), previamente incorporada en la presente. Cuando se entregan servicios Ethernet por medios DSL, la espira DSL puede ser no terminada (v.gr., el dispositivo 102 no está presente o no está físicamente conectado) , o el dispositivo 102 puede estar presente y físicamente conectado. La espira puede ser no terminada en casos donde un operador conecta una espira no terminada a un puerto para llevar a cabo diagnósticos de calificación de espira de un solo extremo. En este caso, un operador puede expedir un comando de diagnóstico contra el dispositivo 96, lo que permite al operador caracterizar/probar la espira DSL durante activación pre-servicio . Si el dispositivo 102 está conectado físicamente y aprovisionado (v.gr. , un servicio está o ha estado corriendo y se requiere un diagnóstico para aislar una condición de falla) , el operador expide el comando de diagnóstico contra el dispositivo 102 (para diagnosticar un problema del puerto Ethernet) o contra el servicio Ethernet conectado al dispositivo 102 (para diagnosticar un problema de la línea DSL) . Como se describió previamente, algunas pruebas de diagnóstico pueden ser ejecutadas mientras una conexión está en servicio, aunque otras requieren que la conexión sea puesta fuera de servicio. El diagnóstico en servicio en los puertos Ethernet del dispositivo 102 está restringido a probar la interfaz Ethernet. En el presente ejemplo, no hay diagnóstico en servicio disponible en la espira DSL salvo el monitoreo del desempeño. Las pruebas fuera de servicio (v.gr., pruebas disrupti-vas) pueden ser llevadas a cabo usando diagnósticos asociados con el dispositivo 102. El dispositivo 102 y el servicio Ethernet asociado con el dispositivo deben estar fuera de servicio en el momento de las pruebas . Estas pruebas permiten a un operador probar y aislar fallas en el puerto Ethernet y el cable asociado con un dispositivo de suscriptor 94, así como fallas asociadas con el puerto DSL y el enlace físico DSL. Si el dispositivo 102 está en servicio durante la prueba, solamente puede realizarse prueba de la longitud del cable (v.gr. , prueba no disruptiva) . Varias pruebas fuera de servicio pueden ser llevadas a cabo en el dispositivo 102. Estas incluyen una verificación de transmisor y receptor de puerto en los puertos Ethernet, que usan retorno de espira interna para permitir la detección de fallas de salida del transmisor y entrada del receptor. El análisis de problemas de cable de Ethernet puede llevarse a cabo para cables ya sea no terminados (pruebas TDR) o terminados. Puede ejecutarse diagnóstico de transmisor y receptor del puerto del equipo DSL usando retorno de espira interna para permitir la detección de fallas de salida del transmisor y de entrada del receptor. El diagnóstico del enlace DSL puede ser ejecutado desde el dispositivo 96 usando diagnóstico de espira de un solo extremo para determinar ciertas características de una espira local digital DSL no terminada (DLL) , tales como longitud de espira, terminación de espira (v.gr. , si la espira es un circuito abierto o en corto) , calibre de espira, capacidad corriente arriba y corriente abajo (en bps) , capacidad ideal corriente arriba y corriente abajo (en bps) (v.gr., capacidad sin considerar los efectos de la pérdida por implementación) , y pruebas de espira de extremos duales . Se entenderá que el método 10 de la figura 1 puede ser implementado en otras configuraciones de red, tales como usando el transporte de cuadros Ethernet sobre interfaces DS3 WAN y/o sobre interfaces de Ethernet por fibra. Haciendo ahora referencia a las figuras 6 y 7, en todavía otra forma de realización, un método 106 utiliza los pasos 108-156 para permitir gestión de un solo extremo del dispositivo 102 y los componentes asociados por el proveedor de servicio 92 para inicializar, monitorear y diagnosticar problemas con una interfaz Ethernet, como sigue. En el presente ejemplo, el método 106 es implementado extendiendo las capacidades provistas por comandos DSL en servicios de transporte de datos . Una descripción mas detallada de los comandos específicos y la información asociada es divulgada en la solicitud de patente US provisional (expediente del abogado 31873.18) previamente incorporada en la presente. Se entenderá que pueden tomarse medidas correctivas después de que se detecta y aisla una falla, pero tales medidas no son denotadas de manera explícita en las figuras 6 y 7. Comenzando en el paso 108, se establece un enlace y se determinan los parámetros de enlace. Antes de que la interfaz Ethernet se ponga en servicio, el método 106 determina un estado actual del enlace DSL (v.gr., bueno o malo) en el paso 110. Si el estado del enlace es malo, el método 106 entra a una etapa de aislamiento de falla, que se describirá posteriormente con respecto a la figura 7. Si el estado del enlace es bueno, el método 106 continúa al paso 112, donde se capturan los parámetros DSL. El método 106 continúa entonces al paso 114, donde determina el estado del enlace Ethernet. Si el estado del enlace Ethernet no es bueno, entonces el método 106 entra en la etapa de aislamiento de falla que se describirá posteriormente con respecto de la figura 7. Si el estado del enlace Ethernet es bueno, el método 106 continúa al paso 116, donde captura los parámetros del enlace Ethernet (v.gr., estado del cable y longitud de cable) . El método 106 continúa entonces a los pasos 118, 120 y lleva a cabo operaciones de monitoreo. El monitoreo puede verificar fallas de enlace, pérdida de comunicación con la empresa de comunicaciones y/o de señal, condiciones de baja luz
(para interfaces de fibra óptica) , re-inicio de auto-negociación, indicación de falla remota, y un cambio en los parámetros de enlace, tales como estado y longitud del cable. El monitoreo puede también verificar otras fallas y aspectos de degradación de servicio, así como recolectar estadísticas para análisis de tendencias. Si se detecta una falla en el paso 120, el método entra en una transición a un estado autónomo fuera de servicio
(OOS-AU) , y continúa al paso 122 de la figura 7 para . intentar aislar la falla. Haciendo ahora referencia a la figura 7, y con referencia continuada a la figura 6, una o mas pruebas son corridas de manera automática para determinar si la falla detectada en el paso 120 es debida a una falla de equipo local, falla de equipo remoto, o un problema de cable. En el paso 122, se determina el estado del enlace DSL. Si el estado del enlace es bueno, el método 106 continúa a los pasos 124, 126, donde conduce una prueba de retorno de espira local de Ethernet y determina si se pasa o no la prueba. Si se determina en el paso 126 que la prueba falló, entonces la falla es factible que se deba a una falla de equipo, como se indica en el paso 128. El método 106 regresa entonces al paso 110. Si se determina en el paso 126 que se pasó la prueba, entonces el método 106 conduce una prueba de cable y determina si la prueba pasó o falló en los pasos 130, 132. Si se determina en el paso 132 que la prueba falló, entonces la falla es factible que se deba a un problema de cable, como se indica en el paso 134. El método 106 entonces regresa al paso 114. Si se determina en el paso 132 que se pasó la prueba, entonces el método continúa al paso 136, donde inicia un procedimiento de auto-negociación . En el paso 138, se realiza una determinación de si el procedimiento de auto-negociación tuvo éxito o falló. Si falló el procedimiento de auto-negociación, la falla es factible que se deba a un problema de equipo remoto, como se indica en el paso 140. Sin embargo, si tuvo éxito el procedimiento de auto-negociación, el método regresa al paso 114 y verifica el estado del enlace Ethernet, como se describió previamente. Regresando al paso 122 de la figura 7, si se determina que el estado del enlace DSL es malo, el método 106 prosigue al paso 142, donde se conduce una prueba de retorno de espira de DSL. Si se determina en el paso 144 que la prueba falló, entonces la falla es factible que se deba a una falla de equipo, como se indica en el paso 128. El método 106 entonces regresa al paso 110. Si se determina en el paso 144 que pasó la prueba, entonces el método 106 conduce una prueba de cable y determina si pasó o falló la prueba en los pasos 146, 148. Si se determina en el paso 148 que la prueba falló, entonces la falla es factible que se deba a un problema de cable, como se indica en el paso 150. El método 106 entonces regresa al paso 114. Si se determina en el paso 148 que se pasó la prueba, entonces el método continúa al paso 152, donde inicia un apretón de manos del enlace DSL. En el paso 154, se realiza una determinación acerca de si el apretón de manos tuvo éxito o falló. Si falló el apretón de manos, la falla es factible que se deba a un problema de equipo remoto, como se indica en el paso 156. Sin embargo, si tuvo éxito el apretón de manos, el método regresa al paso 110 y verifica el estado del enlace DSL, como se describió previamente. En consecuencia, el método 106 de las figuras 6 y 7 utiliza componentes de la red 90 de la figura 5 para proveer y gestionar servicios Ethernet. ? mayor abundamiento, el método 106 permite la detección y el aislamiento de fallas para permitir al proveedor de servicio 92 identificar y atender rápidamente disrupciones y disrupciones potenciales en el servicio Ethernet . Después de que se detecta y aisla una falla, puede generarse un reporte detallado relativo a la falla, diversos atributos de falla (v.gr., tipo, lugar), e información similar. Haciendo ahora referencia a las figuras 8-10, en todavía otras formas de realización, el desempeño y la operación de TDRs (como se describió previamente) puede ser acrecentado en ambientes DSL y/o Ethernet como sigue. La tecnología TDR, que opera usando señales reflejadas, es generalmente inefectiva en lineas terminadas de manera apropiada. En consecuencia, para maximizar el beneficio de la tecnología TDR, una línea que va a ser caracterizada no debe ser terminada, lo que con frecuencia significa que un técnico necesita visitar un sitio y deshabilitar físicamente la conexión. Una vez que se remueve la conexión, pueden correrse pruebas en la línea. Sin embargo, el proceso de enviar un técnico a remover la conexión consume tiempo y es costoso, y puede hacerse mas difícil si la conexión está en las instalaciones del cliente o en el equipo del cliente. Haciendo referencia particularmente a la figura 8, un ambiente DSL ejemplar incluye el equipo lateral de la línea proveedora de servicio 160 y un modem DSL 164, que puede estar ubicado en las instalaciones de un suscriptor. El equipo 160 puede estar asociado con una unidad DSL 162, que permite que el equipo 160 y el modem 164 se comuniquen vía una línea 166. El modem 164 puede incluir un extremo frontal analógico 170, un procesador DSL/procesador de señal digital 172, una interfaz del lado de servicio (v.gr., Ethernet), y un micro-controlador o procesador 176, así como diversas conexiones e interfaces entre estos componentes . En el presente ejemplo, el modem 164 también incluye un circuito 168, que es accesible tanto al extremo frontal analógico 170 como al procesador 176. El circuito 168 incluye un relevador 178 que conecta dos interruptores 180, 182 y el procesador 176. En adición al tráfico DSL, la línea 166 puede incluir un canal de control fuera de banda (v.gr., un canal de operaciones adosado o EOC) que permite al equipo 160 monitorear y controlar el modem 164 vía mensajería EOC. En el presente ejemplo, la mensajería EOC puede ser usada con el circuito 168 para permitir al equipo 160 desconectar la terminación de línea DSL como sigue . Para desconectar la línea, el proveedor de servicio enviaría un comando vía el EOC de la línea 166 al modem 164, instruyendo al modem 164 a desconectarse él mismo por un tiempo "t". El tiempo t puede, por ejemplo, ser pre-definido o puede estar incluido como un parámetro en el comando. Al recibir el mensaje, el modem 164 inicia un temporizador y energiza el relevador 178 a abrir los interruptores 180, 182. Esto da como resultado una línea no terminada por un periodo de tiempo definido por el tiempo t. Durante este tiempo, el proveedor de servicio puede correr diagnósticos para caracterizar la línea. Cuando expira el temporizador, el procesador 176 desenergiza el relevador 178, que cierra los interruptores 180, 182 y restablece la línea. En consecuencia, la efectividad de un TDR asociado con una línea DSL puede ser acrecentada afectando remotamente la terminación de la línea. Haciendo referencia particularmente a las figuras 9 y 10, un ambiente Ethernet ejemplar incluye el equipo proveedor de servicio 184 y un dispositivo digital 188. Para fines de ilustración, el dispositivo digital 188 es un computador ubicado en las instalaciones de un suscriptor, pero se entenderá que el dispositivo 188 puede ser cualquier tipo de dispositivo digital aplicable a la presente divulgación. El equipo 184 está asociado con una unidad Ethernet 186 que permite al equipo 184 y el computador 188 comunicarse vía una línea 190. En adición a diversos componentes conocidos en la materia (v.gr., un procesador, una memoria, una barra conectora, un dispositivo 1/0 (entrada/salida) , una interfaz de red, etc., ninguno de los cuales es mostrado) , el computador 188 puede incluir un circuito 192 como se ilustra en la figura 10. En el presente ejemplo, el circuito 192 está incluido en una tarjeta de interfaz de red (NIC) dispuesta en el computador 188. La NIC está asociada con un número de control de acceso a medios (MAC) que identifica la NIC en una red. Se entenderá que el circuito puede estar asociado con otros componentes en el computador 188 o un dispositivo externo al computador 188. El circuito 192 incluye una unidad de control 194 que está conectada a una trayectoria de datos indicada por las líneas 196, 198. La unidad de control 194 también está conectada a un registro de control 200 y un registro de temporizador 202 vía una línea 204. Los registros 200, 202 se alimentan a una compuerta 206 que contiene un relevador 208. El relevador 208 es usado para desconectar la línea 196 de su circuitería de terminación normal por el registro 200 por la duración programada en el registro 202. Para desconectar la línea, el proveedor de servicio puede enviar un comando vía un mecanismo de señalización de banda interna a la NIC y el circuito asociado 192. El comando incluye una instrucción para que la NIC misma se salga de línea y un tiempo que la NIC debe permanecer fuera de línea. Al recibir el comando, la unidad de control 194 carga los registros de control y temporizador 200, 202 con valores apropiados para activar el relevador y poner la NIC fuera de línea. Esto puede ser logrado, por ejemplo, alterando la impedancia de línea para aparecer como terminada (impedancia) o no terminada (sin impedancia) . Cuando transcurre el periodo de tiempo asociado con el registro de temporizador 202, el circuito 192 desenergiza el relevador 208 y pone la NIC fuera de línea. En consecuencia, la efectividad de un TDR asociado con una conexión Ethernet puede ser acrecentada afectando remotamente la terminación de la línea. Aunque la invención ha sido particularmente mostrada y descrita con referencia a su forma de realización preferida, los técnicos en la materia comprenderán que pueden hacerse en ella diversos cambios de forma y de detalle, sin apartarse del espíritu y ámbito de la invención. Por ejemplo, si se desea funcionalidad de solicitud de retorno de espira en banda, tal funcionalidad puede ser obtenida combinando tecnología de prueba de cables con tecnologías de monitoreo de anomalías, para derivar si una pieza del equipo está trabajando de manera apropiada. Por tanto, las reivindicaciones deben ser interpretadas en una manera amplia, consistente con la presente invención.