PT1527570E - Arquitectura de comutação de comunicações - Google Patents
Arquitectura de comutação de comunicações Download PDFInfo
- Publication number
- PT1527570E PT1527570E PT03747650T PT03747650T PT1527570E PT 1527570 E PT1527570 E PT 1527570E PT 03747650 T PT03747650 T PT 03747650T PT 03747650 T PT03747650 T PT 03747650T PT 1527570 E PT1527570 E PT 1527570E
- Authority
- PT
- Portugal
- Prior art keywords
- data
- fsdu
- data units
- packet
- port
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04J—MULTIPLEX COMMUNICATION
- H04J3/00—Time-division multiplex systems
- H04J3/16—Time-division multiplex systems in which the time allocation to individual channels within a transmission cycle is variable, e.g. to accommodate varying complexity of signals, to vary number of channels transmitted
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/64—Hybrid switching systems
- H04L12/6418—Hybrid transport
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/0003—Interconnection between telephone networks and data networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
- H04M7/0075—Details of addressing, directories or routing tables
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
- H04M7/0078—Security; Fraud detection; Fraud prevention
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
- H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
- H04M7/121—Details of network access arrangements or protocols
- H04M7/1215—Details of network access arrangements or protocols where a cable TV network is used as an access to the PSTN/ISDN
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
- H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
- H04M7/128—Details of addressing, directories or routing tables
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/64—Hybrid switching systems
- H04L12/6418—Hybrid transport
- H04L2012/6445—Admission control
- H04L2012/6459—Multiplexing, e.g. TDMA, CDMA
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/64—Hybrid switching systems
- H04L12/6418—Hybrid transport
- H04L2012/6475—N-ISDN, Public Switched Telephone Network [PSTN]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/64—Hybrid switching systems
- H04L12/6418—Hybrid transport
- H04L2012/6489—Buffer Management, Threshold setting, Scheduling, Shaping
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
- Packages (AREA)
- Use Of Switch Circuits For Exchanges And Methods Of Control Of Multiplex Exchanges (AREA)
- Time-Division Multiplex Systems (AREA)
- Optical Communication System (AREA)
Description
DESCRIÇÃO
ARQUITECTURA DA COMUTAÇÃO DE COMUNICAÇÕES
REFERÊNCIAS CRUZADAS COM APLICAÇÕES RELACIONADAS
Este pedido reivindica prioridade relativamente ao Pedido Provisório Série N°60/377,680 entregue em 3 de Maio de 2002.
ANTECEDENTES DA INVENÇÃO
Campo da Invenção A invenção refere-se a comunicações de dados e em particular a arquitecturas e características de comutação de comunicações.
Descrição da Tecnologia Relacionada
Os operadores de televisão por cabo têm sido normalmente postos em contacto com soluções e arquitecturas de serviço de telecomunicações que foram desenvolvidas para outras indústrias, classes de prestadores, escalas, e instalações físicas. Até agora, dois processos de proporcionar serviços de voz na indústria de cabo multimédia-rich têm sido propostos e estão a ser testados: comutação de circuitos e sistemas de telefonia distribuídos. Nenhum se adapta bem à necessidade de transportar uma larga faixa de tráfego multimédia (vídeo, áudio, texto, gráfico, banda larga, e banda estreita) numa escala geográfica limitada das instalações exteriores da 1 televisão por cabo vulgares, incluindo mas não limitada a tipos de instalações híbridas de cabo fibra/coaxial (HFC) existentes neste momento.
Os sistemas de comutação de circuitos têm sido os meios de comutação básicos para qualidade de confiança de voz principal nas redes públicas de telefone durante vários anos. Num sistema como este o tráfego de circuitos é definido como tendo uma largura de banda reservada ao longo da rede, e mais especificamente, intervalos de tempo ao longo da rede reservados para transportar o tráfego para este circuito quer haja ou não tráfego válido para ser enviado. Certos formatos de circuitos TDM normalizados foram definidos como DSO, DS1 e El. Processos tradicionais para ligação de circuitos TDM para completar uma ligação empregam a utilização de uma comutação com base TDM. Existem várias arquitecturas e modos para construção de um comutador como este conhecido na técnica, mas uma caracteristica geral de um comutador como este é que uma vez uma comunicação estabelecida, deixa de haver competição para recursos de comutação, de maneira que uma latência através do comutador fica garantida. Estes comutadores não servem para tráfego de pacotes.
Num sistema de telefonia distribuído, como o proposto por Cable Labs e outros na iniciativa de «Pacote de Cabos™» (ver a seguir), os dados de telefonia são convertidos em pacotes e comutados com um protocolo interno (PI) utilizando uma variedade de PI e protocolos de rede. O comutador utilizado nestes tipos de sistemas, e de uma maneira geral para o tráfego PI é normalmente referido como comutação por pacotes.
Um comutador por pacotes é concebido para lidar com o tráfego por pacotes, que tem características diferentes do 2 tráfego de circuitos. Em particular, a maior parte dos sistemas por pacotes é concebida como sem ligação, significando que não há uma provisão prévia de uma ligação através da rede, nem reserva de largura de banda para transportar o tráfego. Alguns sistemas de pacotes (por exemplo, modo de transferência assíncrona (ATM)) devem utilizar protocolos de ligação orientada e alguns protocolos PI (por exemplo, Comutação por Multi-protocolo de Pacotes com Etiqueta |MPLS|) também proporcionam um certo nível de reserva de banda larga. Contudo, estes sistemas acrescentam problemas de complexidade extra e problemas de compatibilidade potencial.
Numa comutação por pacotes, são fixados a cada pacote individual cabeçalhos para indicar o destino do pacote. Os pacotes são comutados em tempo real para a saída correcta em cada comutação por pacotes ao longo do percurso. Como resultado, o tráfego que chega a uma comutação por pacotes não é determinante e tem de lutar por recursos de comutação quando experimenta passar no sistema. 0 efeito resultante é que os pacotes são sujeitos a uma latência não determinante através da comutação.
Uma característica adicional da comunicação por pacotes é que a referida comutação deve ser concebida para lidar com pacotes de diferentes dimensões. Isto é um resultado de vários protocolos que são utilizados nas redes por pacotes.
Normalmente, os pacotes que são maiores que as unidades de dados fixadas (FSDU) são divididos em peças mais pequenas (i.e., fragmentadas ou segmentadas). Os pacotes que são mais pequenos que o FSDU são aumentados para constituir um FSDU completo. A dimensão do FSDU é arbitrária, ainda que de uma maneira geral optimizada para ser eficiente para a faixa de dimensões de pacotes 3 esperadas na aplicação para a qual é concebida. Um FSDU para uma situação por pacotes típica está entre 64 e 256 byte.
Como as redes se integram nos sistemas mundiais de telecomunicações correntes, os sistemas foram concebidos para acomodar simultaneamente tanto o tráfego de circuito TDM como o tráfego de pacotes. A implementação com melhor custo/eficiência deste sistema utiliza uma estrutura de comutação simples para acomodar quer dados de pacotes puros quer tráfego de voz em pacotes (e.g., VolP). Um sistema como este necessita de considerar várias exigências destes dois tipos de tráfego inerentemente diferentes.
Voz em redes de protocolo da Internet 100 utiliza o conjunto de elementos e suas interligações mostrados na Figura 1 para encaminhar conversações de voz em pacotes através do Protocolo em Tempo Real (RTP) descrito no Pedido de Comentários (RFC) entre pontos extremos de Adaptadores de Terminais Multimédia (MTAs) 101. MTAs converte a voz em pacotes RTP 105 numa direcção e pacotes RTP em voz na outra direcção. Uma Porta de Entrada 110 numa Rede Pública Telefónica Comutada (RPTC) 150 é utilizada quando o destino da chamada é um telefone 911 (115 em Portugal) localizado na RTPC. Um Servidor de Gestão de Chamadas (SGC) 120 utiliza um protocolo de sinalização normal na indústria 125 tal como H.323,SIP,MGCP, ou MEGACO para estabelecer a circulação RTP entre estes pontos extremos. Esta estrutura da arquitectura da rede VolP tradicional optimiza a utilização da largura de banda da rede mas é inadequada para o transporte de classes de telefonia em que a privacidade do utilizador, a verificação da linha e a interrupção, e o Acto de Assistência às Comunicações para Reforço da Lei (CALEA) são exigidos. 4 MTAs têm funções telefónicas nelas introduzidas ou proporcionam um Rj-11 ou outro interface indústria-normal com uma ligação 130 a um telefone normal. Em ambos os casos, MTAs são providas de um Equipamento em Casa do Assinante (CPE) localizado na residência ou local de trabalho de um assinante. Um mta pode portanto ser falsificado ou substituído por um equipamento não normalizado capaz de controlar o tráfego IP, a rede e providenciar informação sobre o proprietário a um utilizador não autorizado. Com esta informação um utilizador com más intenções poderia originar uma sinalização da rede e/ou pacotes de controlo que poderiam interromper ou negar o serviço a outros utilizadores da rede. Estas interrupções (às vezes requeridas nos dados de comunicações como uma «Negação de Serviço» ou DoS Ataque) são inaceitáveis quando é utilizada uma rede VoIP para serviço telefónico de primeira linha. Além disso, uma vez que o endereço IP de um MTA de assinante é o encaminhamento equivalente no seu número de telefone, regulações que exigem a capacidade do assinante de bloquear o serviço/função bem conhecido poderiam ser interpretadas como também exigindo o bloqueio do seu endereço IP num desenvolvimento VoIP. 0 roubo de serviços é também um risco reconhecido a ser evitado. A protecção de CPE e da funcionalidade baseada em CPE deve também ter em conta a necessidade de segurança do conteúdo e do serviço.
Além disso, o Acto de Assistência às Comunicações em Reforço da Lei (CALEA) exige que um prestador de serviço suporte a vigilância legal do tráfego na rede sem obstrução do fornecimento da informação de identificação da chamada e/ou o seu conteúdo. Com a estrutura da arquitectura VoIP tradicional acima descrita, a CALEA é muito complexa e pode exigir a coordenação de elementos de redes múltiplas. (Esta alternativa vem descrita em, por exemplo, PacketCable 5
Electronic Surveillance SpecificationPKT-SP-iO 1-991229. Outras características e exigências da arquitectura e normas industriais relacionadas com o fornecimento VoIP e outros serviços de media codificados na infra-estrutura podem ser encontrados em várias referências e especificações de Packet Cable que se encontram em http://www.packetcable.com/specifications.htrnl.
Os nomes e os números destas especificações estão reproduzidos nas tabelas a seguir.
Note-se que Engineering Change Notices (ECNs) foram aprovadas por várias das especificações temporárias e estas ECNs são consideradas como parte das especificações de Packetcable. ECNs foram transmitidas para o sitio Packet Cable LiveLink (ver a hiperligação atrás referida). .Packetcable 1.0
As onze especificações e as seis referências técnicas na tabela seguinte definem Packetcable 1.0. Em conjunto estes documentos definem a sinalização da chamada, a Qualidade de Serviço (QoS), CODEC, fornecimento ao cliente, facturação da colecção de mensagens eventuais, interligação RTPC (Rede Telefónica Pública Comutada), e interfaces de segurança necessária para implementar uma solução de zona única de Packetcable para serviços de voz para protocolo interno residencial. «Zona única» refere-se aqui a um sistema que serve a instalação ou região de um cabo HFC. 6
PacketCablel.0 Especificações e Referências Técnicas Numero de Especificação PacketCable™ Especificação CODEC Audio/Video PKT-SP-CODEC-103-011221 TM PacketCable Especificação da Qualidade Dinâmica do Serviço PKT-SP-DQOS-103-020116 TM PacketCable Especificação do Protocolo de Sinalização de chamada com Base na Rede PKT-SP-EC-MGCP-104-011221 TM PacketCable Especificação de Mensagem Eventual PKT-EM-103-011221 PacketCable™ Especificação do Protocolo de Transporte de Sinalização da Internet(ISTP) PKT-SP-ISTP-102-011221 PacketCable™ Especificação de Estrutura MIBs PKT-SP-MIBS-103-020116 PacketCable™ Especificação MIB de sinalização PKT-SP-MIB-SIG-103-011221 PacketCable™ Especificação do Dispositivo MTA de Aprovisionamento PKT-SP-PROV-103-011221 TM PacketCable Especificação de Segurança PKT-SP-SEC-105-020116 PacketCable™ Especificação do Protocolo da Sinalização de Chamadas através da Porta de Conversão da Rede Telefónica Pública Comutada PKT-SP-TGCP-102-011221 TM PacketCable Referencia Técnica de Conjunto de Programas Básicos NCS PKT-TR-MGCP-PKG-V01-020315 PacketCable™ Referência Técnica à Arquitectura de Circulação de Chamadas-Em-Rede MTA para Rede MTA PKT-TR-CF-ON-ON-VOl-991201 7
PacketCable™ Referência Técnica à Arquitectura de Circulação de Chamadas da Rede On MTA para RPTC PKT-TR-CF-ON-RPTC-VO1-991201 TM PacketCable Referencia Técnica à Arquitectura de Circulação de Chamadas de RPTC para a Rede MTA PKT-TR-CF-RPTC-ON V01-991201 TM PacketCable Referencia Técnica à Arquitectura da Estrutura 1.0 PKT-TR-ARQ.-V01-991201 TM λ PacketCable Referencia Técnica da Vista Geral OSS PKT-TR-OSS-VO2-991201
PacketCable 1.1
As cinco especificações e as quatro referências técnicas da tabela seguinte definem exigências para oferecer um serviço de linha primária capaz utilizando a arquitectura do PacketCable. A designação de um serviço de comunicações como «primário» significa que o serviço é suficientemente de confiança para satisfazer uma expectativa de um consumidor assumido da disponibilidade essencialmente constante. Isto também inclui, especificamente, a disponibilidade durante uma falha de energia nas instalações do cliente e (a assunção do serviço é utilizada para ligação à RTPC) acesso aos serviços (911, etc.) de emergência.
PacketCablel.1 Especificações e Referências Técnicas Numero da Especificação TM PacketCable Especificação para Gestão de Eventos mib PKT-SP-EVEMIB-I01-020315 PacketCable™ Especificação para Suporte da Linha Primária MTA Incorporada PKT-SP-EMTA-Primária-101- 001128 PacketCable™ Mecanismo de Gestão de Evento PKT-SP-MEM-I01-0011128 PacketCable Especificação da Vigilância Electrónica PKT-SP-ESP-I01-991229 PacketCable™ Especificação do Protocolo do Servidor Áudio PKT-SP-ASP-I02-010620 PacketCable™ Referência Técnica à Arquitectura do Sistema de Sinalização e Controlo da Linha PKT-TR-ARCH-LCS-V01-010730 PacketCable™ Referência Técnica à Gestão de Identificadores de Eventos PKT-TR-MEMEVENTOS-ID-VOl- 001128 Referência Técnica sobre a Disponibilidade e Fiabilidade da Arquitectura do Modelo Volp para o PacketCable™ PKT-TR-VOIPAR-V01-001128 PacketCable™ Referência Técnica sobre a Vigilância Electrónica da Circulação de Chamadas PKT-TR-ESCF-V01-991229
PacketCable 1.2
As duas especificações e uma referência técnica na próxima tabela definem os componentes funcionais e os interfaces necessários para permitirem comunicação entre redes PacketCable 1.0 utilizando uma rede de transporte IP ou Base. Estas especificações descrevem a sinalização da 9 chamada e a Qualidade de Serviço (QoS) das extensões para a arquitectura do PacketCable 1.0 para permitir aos operadores de cabo mudar directamente o tráfego da sessão. Isto permitirá a um assinante da rede PacketCable estabelecer extremo a extremo IP ou sessões «on-net» com assinantes em outras redes PacketCable. Por PacketCable «on-net» significa que a chamada é estabelecida extremo a extremo na rede IP sem atravessar RPTC em qualquer altura.
PacketCablel.2 Especificações e Referências Técnicas Número das Especificações TM PacketCable Especificação da Sinalização do Servidor de Gestão da Chamada PKT-SP-CMSS-101-001128 TM PacketCable Especificação da Qualidade de Serviço Interdomínio PKT-SP-IQOS-101-001128 TM λ PacketCable Referencia Técnica da Estrutura da Arquitectura PKT-TR-ARCH 1.2-V01-001229 EP 1,202,599 divulga um processo de comunicação de dados de media que compreende os passos de recepção de uma multiplicidade de unidades de dados de media numa porta de ingresso, determinando uma porta de egresso para cada saida da referida multiplicidade de unidades de dados de media com base no tipo de cada unidade de dados, dirigindo cada uma da referida multiplicidade de unidades de dados de media na direcção da referida porta de egresso correspondente, e em cada das referidas portas de egresso, recebendo uma segunda multiplicidade de unidades de dados de media; e transmitindo a referida segunda multiplicidade de unidades de dados de media para completar a referida comutação de dados de media. O que é necessário é um processamento de media seguro e que seja compatível com as 10 especificações do PacketCable (de maneira que possa servir sistemas de cabo) e que resista a ataques para roubo e Negação do Serviço enquanto suporta CALEA, E911, e exigências da qualidade de serviço interurbano. 0 sistema deve fazer interface com sistemas existentes, encabeçados por cabo e com equipamento HFC. Além disso, um sistema como este deve estar integrado numa EMS, resistente a avarias, robusto, que se possa escalonar e por último uma boa relação custo eficácia para ultrapassar as conhecidas dificuldades do estado presente da técnica. A invenção proporciona um processo de comutação de dados de media de acordo com a porção caracterizante da reivindicação 1. A presente divulgação pode ser melhor entendida e as suas numerosas características e vantagens mais evidentes para os especialistas da técnica com referência aos desenhos anexos. A Figura 1 é um diagrama de blocos de alto nivel da arquitectura de um servidor de comunicação VolP da técnica anterior. A Figura 2 é um diagrama de blocos de alto nivel da arquitectura VolP de acordo com uma forma de realização da invenção. A Figura 3 é um diagrama de blocos funcional de acordo com uma forma de realização da presente invenção. A Figura 4 é um organograma do processo de colocar em cápsula o pacote de acordo com uma forma de realização da presente invenção. 11 A Figura 5 é um diagrama de blocos de alto nível de uma arquitectura da estrutura de um comutador de uma forma de realização da presente invenção dada a título de exemplo. A Figura 6 é uma representação esquemática do formato de dados TDM empregado em algumas formas de realização da presente invenção. A utilização dos mesmos símbolos de referência dos diferentes desenhos indicam itens semelhantes ou idênticos. Estrutura de arquitectura de processamento de meios seguros I0021| actualmente divulgada é uma nova categoria de comutação de voz, integrada com multimedia (vídeo, áudio, gráfico e conteúdo de texto) que proporciona um sistema de comutação de media versátil e seguro para utilização no cabo encabeçado ou qualquer outro centro ou nodo de comutação de dados. O sistema de processamento de media seguro (SMP) proporciona serviços telefónicos para assinantes de cabo, além da televisão por cabo normal e distribuição e serviços de multimedia (e.g., vídeo, áudio, etc.). O sistema SMP integra num sistema o Servidor de Gestão de Chamadas, o Comutador de Pacotes, a Porta de Conversão de Media, a Porta de Condução de Sinalização, Controlo da Porta de Conversão de Media e Funções de interface que dizem respeito ao tráfego do modelo de referência do Packet Cable acima descrito. A arquitectura SMP dá uma nova atenção às funções especificadas no modelo de referência do Packet Cable e apresenta um interface lógico simples resistente a avarias para serviços de telefonia por cabo, por exemplo, um esquema para Voz sobre IP (VoIP) de confiança de serviços telefónicos.
Na técnica anterior, os sistemas de telefones distribuídos, tais como os divulgados na Figura 1, um 12 servidor 120 de gestão de chamadas responde aos MTAs 101 que serão envolvidos na chamada proporcionando a cada MTA os outros endereços de MTAs IP. A rede IP pode assim encaminhar as chamadas entre MTAs com base em processos de encaminhamento tradicionais, disponibilidade de percursos, custos, niveis de congestão, números ocupados, e outros aspectos de engenharia e encaminhamento do tráfego. Esta abordagem, ainda que efectiva para comunicações de dados, prova ser não causal e não determinante para serviços sensíveis ao tempo como a voz, em que a latência de percurso, a qualidade, a privacidade e a segurança necessitam de ser fortemente controladas. Também, por o endereço IP dos MTAs envolvidos na chamada ser ligado a todos os pacotes que são transmitidos, privacidade e segurança para todos os participantes nos serviços fornecidos pela rede não são asseguradas.
Em contraste, a arquitectura SMP, em algumas formas de realização, está em condições de proporcionar que cada MTA envie o seu tráfego directamente para o interface de comutação de pacotes e não para outros MTAs. Isto evita que o MTA obtenha qualquer endereço de outros MTAs IP. Tem também a vantagem de apresentar um único interface lógico tolerante a avarias a todos os MTAs. E, porque o caminho é determinante, leva ao controlo da latência e da qualidade do percurso para o comutador. Com muita importância, a arquitectura SMP dá protecção à privacidade dos indivíduos envolvidos na chamada. A arquitectura SMP também proporciona benefícios particulares nas áreas da privacidade do utilizador, do Suporte para Assistência das Comunicações no Acto de Reforço da Lei CALEA, derivação legal em circuitos, emergência 911 e interrupção por operador de chamada em progresso. Além disso, tem impacto de forma positiva nas 13 necessidades e exigências da rede fundamental, tal como escalonamento, segurança e privacidade, disponibilidade, operações, simplificação da rede, e custo.
Nos serviços «Linha Principal», os destinados a serem a ligação de voz única principal do utilizador, as especificações reguladoras, obrigam à implementação das características como CALEA, E911, e Interrupção por Operador. 0 desafio em criar sistemas telefónicos distribuídos para utilização de linhas principais reside na concordância com CALEA, E911 e Interrupção por Operador, bem como em assegurar a disponibilidade e segurança dos dados que os utilizadores esperam. Nos sistemas de distribuição da técnica anterior, qualquer elemento envolvido no processamento, comutação e sinalização da chamada é obrigado a suportar estas características. Isto cria duplicação de funções, por exemplo, pontos de descodificação e de derivação para CALEA e interrupção por operador, bem como, a necessidade de coordenar estas características entre os vários elementos da rede. Como o número de componentes aumenta na rede, também aumenta o número de pontos de falha possíveis, daí reduzindo os valores de disponibilidade geral da rede. Isto aumenta a complexidade e duplicação da funcionalidade, a qual aumenta o custo total da rede. Para chamadas para o 911, a complexidade da arquitectura distribuída exige também que todos os elementos (e os seus Sistemas de Gestão de Elementos) actuem em conjunto para suportar a gestão da largura de banda e as exigências de QoS (Qualidade de Serviço) que permitem que estas chamadas circulem sempre que haja utilização elevada da rede.
Além disso, reunindo os problemas das abordagens da comutação distribuída, quando as funções da rede são separadas umas das outras, a rede necessita de se apoiar em 14 protocolos de sinalização para ligar ou integrar logicamente os vários elementos em conjunto, para funcionar como um segmento da rede integrada. Esta separação incentiva a proliferação de protocolos de sinalização, de ligações de percursos de dados, controlo misto e tráfego de utilizador, e de Sistemas de Gestão de Elementos Múltiplos. E para cada ligação, protocolo e EMS acrescentados ao conjunto de elementos, outro ponto potencial de falha vem à superfície. Dado que a disponibilidade e fiabilidade totais da rede são produtos da fiabilidade e disponibilidade de cada um dos seus elementos, esta proliferação aumenta drasticamente as exigências de resiliência, fiabilidade e disponibilidade de cada elemento da rede. Torna-se assim muito difícil, senão impossível, atingir o nível de disponibilidade desejado pela indústria utilizando a abordagem «servidor de comunicação», como estes sistemas são muitas vezes descritos na técnica. A arquitectura SMP enfrenta estes inconvenientes da técnica anterior proporcionando um único ponto de entrega altamente integrado, seguro e de confiança para serviços/dados multimédia em elementos de uma única rede com um único EMS. 0 tráfego de controlo de dados é imediatamente separado do tráfego de dados do utilizador para aumentar a integridade do controlo de rede independente das condições de tráfego do utilizador. Reduzindo o número de elementos na rede, são reduzidas ligações, são reduzidos pontos de falha, e a fiabilidade de toda a rede é aumentada. Além disso, o nível de integração proporcionada pela arquitectura SMP conduz à implementação eficiente de disponibilidade elevada, processos de controlo de chamadas sem resiliência, restauração de percurso, e fornecimento de serviços que seria impossível aplicar nas múltiplas plataformas utilizadas nas abordagens distribuídas da técnica anterior. 0 elevado nível de 15 integração da arquitectura SMP também conduz a uma função de controlo natural, com a implementação de um único processador para todas as funções necessárias ao serviço de uma chamada desde o inicio até ao fim da chamada, incluindo a restauração, comutação e encaminhamento, protegendo assim de processos errantes que poderiam diminuir a disponibilidade do sistema ou rede.
Para assegurar ainda mais as exigências de disponibilidade e de escalonamento, a arquitectura SMP permite processos de gestão de largura de banda sofisticados para os vários tipos de dados e serviços de média que proporciona. Estes processos de gestão de largura de banda proporcionam funções de controlo determinantes da aceitação de chamadas pelo sistema, permitindo que as exigências individuais da chamada sejam aceites ou rejeitadas com base na carga de chamadas tipo e política de subscrição.
As possibilidades de gestão de largura de banda das arquitecturas SMP abarcam quatro dos elementos de recurso funcional tradicional: Acesso à Rede, Comutação, Portas de Conversão de Média, e Estabelecimento de Circuitos Principais. Em sistemas distribuídos típicos da técnica anterior, cada elemento funcional seria controlado e monitorizado por um EMS separado, e frequentemente incompatível e/ou patenteado. A arquitectura SMP, por contraste, proporciona a gestão de recursos unificados necessária para providenciar uma solução de processamento de telefonia e média em geral que seja consistente com o escalonamento, a disponibilidade e resiliência das RTPC actuais, ainda disponível para utilização com todos os tipos de dados multimédia em vez de apenas voz ou dados de vídeo. 16 A arquitectura SMP elimina a complexidade de sistemas múltiplos da técnica anterior patenteados de gestão de elementos com uma solução integrada utilizando um único EMS para funcionamento e controlo. O aumento na confiança e disponibilidade obtido por este nível de integração leva a plataforma a oferecer E911, CALEA e serviços de Interrupção de Operador consistentes com PacketCable e outras especificações relevantes. SMP proporciona um ponto único para descodificação e derivação para suporte de CALEA e para interrupção de chamada do operador. SMP permite também a implementação de processos de gestão de largura de banda para facilitar as chamadas E911.
Forma de Realização a Título de Exemplo A Figura 2 ilustra uma forma de realização dada a título de exemplo de uma estrutura 200 de arquitectura SMP. Como acima referido, a arquitectura proporciona privacidade da rede para assinantes VolP (Voz em Protocolo de Internet) embora conduzindo o prestador do serviço a um processo mais caro para satisfazer as exigências estabelecidas por CALEA e outros serviços telefónicos/media. A arquitectura SMP utiliza uma função de encaminhamento de confiança e é, numa implementação, englobada em «Cedar Point
Communications'SAFARI™ Cable Media Switch». A função de encaminhamento SMP de confiança elimina todos os escoamentos RTP MTA-para-MTA na rede IP e proporciona as funções de uma Porta de Conversão RTPC, de um Agente de Chamada (ou «servidor de comunicação»), e de Classe 5 (i.e., um gabinete local, não em tandem) de comutação integrando o Sistema 7 de sinalização (SS7) de sinalização telefónica e chamadas de voz com dados da rede de pacotes. 17
Numa forma de realização dada a título de exemplo, a implementação Safari proporciona um chassi de montagem normal pequeno de uma só prateleira, tendo assim apenas uma impressão de base na cabeça da extremidade do cabo ou ponto central. Todo o hardware e software estão completamente integrados no chassi (e na sua estação de trabalho ems associada) proporcionando operações altamente eficientes em espaço e potência.
Na arquitectura SMP, MTAs 101 são apenas providas de endereço IP do comutador 210 SMP de maneira que os endereços IP de todos os outros MTAs são mantidos privados. Dando instruções aos MTAs 101 para encaminhar todas as unidades de dados RTP (ou correntes) para o comutador 210, a Interrupção do Operador, acordo CALEA e Qualidade de Serviço (QoS) e o aprovisionamento ficam também simplificados. O comutador SMP 210 inclui também inclui interfaces com IP 170 e RTPC 150, Protecção de Ataque contra Negação de Serviço (DoS), codificação e descodificação, encaminhamento e derivação, e funções de Codificação/Descodificação TDM (funções CODEC), como se mostra na Figura 3.
Unidades de dados RTP, referidas convencionalmente como «Pacotes» originados de qualquer MTA na rede IP são em primeiro lugar recebidos numa porta de ingresso (não representada), processados pelo interface 310 de pacote, e enviados para o bloco 320 de Protecção de Negação de Serviço (DoS) . O bloco de protecção DoS evita que os ataques à Negação de Serviço atinjam e degradem o processamento de pacotes subsequente. Os pacotes são então descodificados para corresponderem às exigências de segurança da rede IP e enviados para o bloco 330 Encaminhamentos e Derivação. 18
Note-se que o «processamento» acima referido inclui a reformatação das correntes de unidades de dados RTP em correntes de pacotes com cápsula para utilização interna no comutador 210. Estes pacotes com cápsula (mais tarde discutidos) são optimizados para recepção e transporte eficientes nas portas de egresso (saida). O bloco 330 «Encaminhamento e Derivação» aplica a função encaminhamento e/ou derivação com base nos destinos e serviços especificados para a chamada para determinar qual a porta de saída para enviar para ela as unidades de dados. Os pacotes podem ser reencaminhados (dirigidos) de volta para a rede 170 IP, caso em que deverão ser codificados e processados pelo interface 310 de pacote ou enviados para o bloco 340 CODEC. O referido bloco executa as funções normais de codificação e descodificação tal como descritas nas especificações ITU G.711, G.729, G.168, e/ou derivação tipo N-Way. O interface 350 proporciona um circuito interface DSO normalizado para o RTPC; da mesma maneira, o Call Management and Media Gateway Controller 370 desempenham funções tipicamente definidas para telefonia VolP e normalmente praticadas na técnica. Dispondo estas funções como representado protege os utilizadores e serviços da rede IP de ataques maliciosos e proporciona uma solução única para proporcionar telefonia de grau portadora e a monotorização CALEA de serviços numa rede VolP.
Numa forma de realização, as funções de comunicações internas e de comutação num comutador SAFARI são implementadas utilizando ligações directas em fibra óptica através de um plano de base de fibra óptica equipado com conectores de um plano de apoio óptico patenteado por Cedar 19
Point Inc. 0 conector amovível do plano de base é também descrito no Pedido de Patente US Série N°09/938,228 entregue em 23 de Agosto de 2001. A maior parte dos blocos funcionais na arquitectura SMP é descrita com maior pormenor a seguir.
Privacidade de Assinante de Telefonia VolP
Quando um assinante inicia uma chamada telefónica para outro assinante dentro de uma rede VolP tradicional, os endereços IP dos MTAs originais e terminais são trocados no protocolo de descrição da sessão (SDP) (Ver IETF RFC 2327). O SDP é colocado em cápsula num protocolo de sinalização bem conhecido, por exemplo, os descritos nas normas H.323, SIP, MGCP, ou MEGACO da UIT (dependendo da normas e equipamento utilizados pelo prestador de serviços). O cabo proporciona, por exemplo, a normalização num perfil MGCP referido como protocolo de Sinalização de Chamada com base na rede (NCS) . Veja-se, por exemplo, a Especificação PacketCable PKT-SP-EC-MGCP-102-991201 para uma descrição completa deste protocolo.
Na arquitectura SMP, a função de gestão da chamada insere o seu próprio endereço IP no perfil SDP trocado entre MTAs em vez de endereços IP de outro MTA. Isto mantém local de informação de endereço MTAIP patenteada no comutador SMP, o qual é necessariamente um elemento de confiança da rede, em vez de o enviar para cada MTA envolvido numa chamada telefónica. Para criar o percurso de voz, cada MTA estabelece um pacote de circulação RTP para o comutador SMP; o SMP encaminha então o pacote de circulação apropriadamente, i.e., para outro MTA para uma chamada 20 dentro da rede VolP ou (após conversão para o apropriado e bem conhecido formato para encaminhamento) para RTPC.
Caracteristicas de Conformidade da Interrupção pelo Operador e CALEA
As caracteristicas telefónicas, tais como verificação de linha ocupada, interrupção pelo operador (break-in), e CALEA têm exigências semelhantes para o controlo ou derivação de uma chamada de voz. Na arquitectura tradicional VolP, MTAs, a porta de condução de RTPC, e outros equipamentos de encaminhamento exigem todos funcionalidade extra e interacção para estar conforme com estas caracteristicas. Na estrutura da arquitectura SMP, a funcionalidade requerida é isolada para a função, Encaminhamento e Derivação dentro do próprio comutador. Esta função proporciona a capacidade de ouvir ou conferenciar sem obstrução uma chamada telefónica transportada num pacote RTP codificado e ligado a um circuito de Verificação de Linha Ocupada Sem Teste (para interrupção pelo operador) ou um Canal Contendo uma Chamada (para controlo CALEA).
Colocar um Pacote em Cápsula A arquitectura SMP, em algumas formas de realização, pode também utilizar um processo de baixa latência, de baixa suspensão, de eficiente largura de banda para colocação em cápsula de circuito DSO designado para transportar tráfego de circuito como tráfego de pacotes de modo eficiente. Este processo de colocação em cápsula de circuito DSO pode ser configurado facilmente para acomodar qualquer mistura de unidades de dados de pacotes e de 21 tráfego VoIP. Em particular, proporciona um processo para colocar em cápsula tráfego de circuitos (i.e., unidades de dados RTP) para unidades de dados de pacote de baixa suspensão comutando através de uma estrutura de maneira que as exigências de atraso especificas de voz e outro tráfego de circuito não tolerante na latência são conseguidos. 0 processo de colocação em cápsula é ilustrado na Figura 4. Neste caso, o fluxo de ingresso (cujo processamento é apresentado na figura 4A) é uma corrente de dados vinda para o comutador a partir da rede de circuitos, i.e., RTPC. 0 fluxo de egresso (mostrado na Figura 4B) é uma corrente de dados deixando o comutador e entrando na RTPC num intervalo de tempo TDM.
Para um fluxo de ingresso mostrado na Figura 4A, o processamento começa quando a unidade de dados de circuito é recebida (lida) durante o intervalo de tempo TDM escolhido, passo 405. O processo verifica então a memória para determinar a informação de encaminhamento correspondente à unidade de dados recebida, passo 410. A unidade de dados é dirigida a uma fila de espera determinada com base no número da porta de saída derivado, pelo menos, em parte, da informação de encaminhamento, passo 415. O passo 420 continua o processo dos passos 405 a 415 até que um número suficiente de unidades de dados seja recolhido para encher o FSDU, testando para uma estrutura de limite, 425, após cada adição à fila de espera. Uma vez cheio o FSDU, é acrescentado um cabeçalho criando um pacote numa cápsula. O referido pacote de dados é então enviado para a estrutura de comutação e dirigido à fila de espera de egresso apropriada, no passo 430. O processo repete no passo 405 enquanto há dados presentes à porta de ingresso. 22 0 processo do fluxo de egresso, divulgado numa forma de realização, na Figura 4B, é semelhante. No passo 450, o pacote de dados colocado em cápsula é recebido da estrutura de comutação e colocado num local transitório FIFO. O cabeçalho é lido, passo 455, e a porta da fonte é determinada a partir da informação guardada no cabeçalho. O identificador da referida porta é utilizado para leitura da localização da memória correspondente a este FSDU para determinar o intervalo de tempo correcto para cada unidade de dados no FSDU no passo 460. As unidades de dados no FSDU são então desempacotadas (i.e., reformatadas) e colocadas em locais transitórios correspondentes ao intervalo de tempo de destino de cada unidade de dados, passo 465.
Quando o intervalo de tempo chega, as unidades de dados são lidas fora de cada local transitório e transmitidas à corrente TDM.
Uma forma de realização dada a titulo de exemplo da arquitectura SMP (exemplificada por, mas não limitada à comutação de média SAFARI do Cedar Point) é utilizada para comutar tanto tráfego de pacotes como tráfego DSO com base TDM utilizando simultaneamente a mesma estrutura. Uma comutação de pacotes (por definição) é destinada a lidar com as exigências especificas do tráfego de pacotes, no presente sistema pode providenciar funcionalidade de comutação de pacotes convencional como vem descrito em alguns pontos desta divulgação.
Uma estrutura de comutação de pacotes 500 tem um número finito de portas 510 de velocidade elevada (8, por exemplo) como se mostra na Figura 5, ainda que na prática possa ser utilizado qualquer número. Isto implica que pode haver oito portas de ingresso (entrada) e oito portas de egresso (saida) para a estrutura de comunicação. Em cada ciclo de 23 tempo, um e apenas um FSDU pode ser passado em cada ligação. Dependendo do comportamento do tráfego, nem todas as entradas podem estar em condições para serem ligadas à saída exigida para o FSDU. Se todas as entradas desejam enviar o seu FSDU para a mesma saida, demorarão oito ciclos de tempo para que todas as entradas enviem um FSDU. Se todos os inputs desejam enviar o seu FSDU para a mesma saída, demorará oito ciclos de tempo para que todos os FSDU sejam enviados.
Tráfego comutado pode consistir em qualquer mistura arbitrária de tráfego de pacotes e tráfego de DSO nas diferentes portas. Algumas portas podem ser dedicadas ao tráfego de pacotes (e.g., porta 1 na Figura 5), algumas portas podem ser dedicadas ao tráfego DSO (e.g., porta 3) e algumas portas podem suportar uma combinação de tipos de tráfego (e.g., porta 5). A arquitectura SMP permite qualquer combinação de tipos de tráfego sem afectar as características de desempenho exigidas pelas aplicações. Além disso, o sistema é transparente para a informação real representada pelos fluxos de dados de pacotes ou TDM (DSO). Sinais de voz, dados, FAX ou sinais modernos, vídeo, gráficos ou qualquer outra informação podem ser transportados e comutados com comodidade e facilidade pela e dentro da arquitectura SMP aqui descrita.
Um circuito TDM DSO transporta um único byte de dados cada 125 μ3βρ. Este intervalo de tempo é de forma mais comum referido como uma estrutura nas técnicas de telecomunicações. Desde que a estrutura de pacotes tenha um FSDU de entre 64 e 256 byte, um único circuito TDM não fica perto do enchimento de um FSDU. 0 restante espaço no FSDU seria desperdiçado pelo enchimento com compensador se um circuito DSO individual fosse dedicado a um único FSDU. 24
Assim, seria muito ineficiente considerar um único byte de dados num tão grande FSDU.
Uma opção é esperar um período de tempo mais longo para acumular um maior número de byte para o circuito DSO.
Para preencher um FSDU de 64 byte, deveria esperar-se 8 mseg, ou 32 mseg para um FSDU de 256 byte. Com chamadas de voz, isto representa uma demora significativa para o circuito, e não atinge os requisitos da Qualidade de Serviço «interurbano». Também exige uma maior quantidade de memória para lidar com o armazenamento temporário destes dados. Nenhuma desta opções é ideal.
De acordo com algumas formas de realização da presente divulgação, circuitos múltiplos DSO TDM são combinados em cada estrutura de tempo para mais completamente preencher um FSDU 610. Esta combinação é ilustrada na Figura 6. Uma vez que existe um número fixo e fácil de gerir de portas da estrutura de comutação, é razoável preencher FSDUs 610 com circuitos DSO múltiplos destinados à mesma porta de saída da estrutura de comutação.
Este é um processo dinâmico: como circuitos DSO destinados a uma estrutura de comutação particular vêm e vão, o processo liga e desliga circuitos DSO para preencher com eficiência o FSDU 610 destinado a cada porta. Se um circuito é desligado, todos os circuitos ainda activos deslizarão para preencher o espaço deixado pelos circuitos desligados.
Para cada uma das oito portas da estrutura de comutação (em algumas formas de realização), um circuito 520 separado (referência à Figura 5) é utilizado para gerar FSDUs para o tráfego encabeçado para esta porta. Um cabeçalho 620 no princípio de cada FSDU identifica a porta da estrutura de 25 comutação ao mesmo tempo da informação prioritária para guiar apropriadamente o FSDU através da estrutura de comutação. A parte restante do FSDU é preenchida com dados TDM. Por exemplo, se um FSDU de 64 byte contém dois byte em excesso, a parte restante de FSDU pode ser preenchida com canais 62 DSO TDM. No interior de cada estrutura, por exemplo, um único byte de dados de cada circuito é recebido no dispositivo, é acrescentado ao FSDU para a porta de destino particular para a qual deve ser enviado. Quando o FSDU fica cheio, é enviado para a comutação de pacotes e outro FSDU é iniciado para essa porta. Todos os FSDUs devem ser enviados pela extremidade da estrutura mesmo se não estiverem completamente cheios, para manter a espera do processo em 125 μεβς. Utilizando este esquema, os dados são eficientemente introduzidos nos FSDUs com 62/64 ou 96,9% de eficiência por cada FSDU excepto para no máximo 16 FSDUs que pode ser apenas cheio parcialmente. Com um FSDU de 256 byte, esta eficiência sobe para 254/256 ou 99,2% por FSDU. Se o comutador lida com 16.000 circuitos, o FSDU de 64 byte tem uma eficiência no todo de 91,2% e o FSDU de 256 byte tem uma eficiência no todo de 93,4%. Em comparação, utilizando um único canal DSO TDM num FSDU obtém-se uma eficiência de apenas 1,6%.
No lado de saida (egresso) da estrutura de comutação, os FSDUs são processados (reformatados) para remover os cabeçalhos e destacar os canais DSO individuais. A informação de encaminhamento para cada canal pode ficar disponível para o dispositivo de processamento à saída da estrutura de comunicação por processos diferentes que são bem conhecidos nas tecnologias de comunicação e de encaminhamento. Os DSOs são então repostos de novo num formato TDM para transição através das portas de egresso e para a rede. 26
Em conjunto com o processo de colocar em pacotes os FSDUs como acima foi descrito, uma vez que os dados DSO são muitas vezes sensíveis, devem ser passados através da estrutura de comunicação com uma latência máxima garantida. Como atrás mencionado, a estrutura de comunicação é partilhada com o tráfego de pacotes que pode exibir um comportamento de chegada com intermitência. Para evitar que o tráfego de pacotes venha a competir com o tráfego TDM de alta prioridade, aos FSDUs com base TDM é atribuído um nível de prioridade que é mais elevado que o do tráfego de pacotes. Desde que a largura de banda atribuída ao nível de prioridade particular do tráfego TDM não seja excedida, a quantidade de tráfego TDM é determinante, e a latência para o tráfego TDM através da estrutura de comunicação pode ser garantida independentemente da quantidade do tráfego de pacotes. 0 efeito deste processo é tal que o tráfego de circuito e de pacotes podem ser misturados em qualquer combinação na estrutura de comunicação sem que nenhum tipo de tráfego exerça impacto no desempenho do outro.
Uma vez que a latência pode ser limitada, é então possível reconstruir a corrente TDM no lado de saída da estrutura de comutação e enviar as correntes de dados individuais no intervalo de tempo correcto que lhe foi atribuído. Para se conseguir isto, é necessário nivelar as demoras variadas encontradas ao longo da comutação de pacotes. Uma vez que a baixa latência é importante, torna-se necessário que a dimensão do amortecedor instável seja tão pequena quanto possível; contudo, o amortecedor deve ser dimensionado suficientemente grande para contar com mínima e máxima latência através da estrutura de comutação.
Utilizando as estruturas de comutação de pacotes comercialmente disponíveis, é razoável constranger o amortecedor para introduzir uma demora adicional de não mais que um intervalo de tempo de 125 microssegundos. 27 A implementação da estrutura de comutação da arquitectura SMP produz assim uma única estrutura de comutação com o desempenho da latência e da produção equivalente à existência de comutadores TDM dedicados separados e comutadores de pacotes. Consegue-se isto sem o gasto de estruturas múltiplas ou da complexidade da sua interligação.
Sobrevivência a ataque à negação do serviço (DOS)
Segurança física, segurança contra incêndios, filtros específicos, ou sessões do nível de autenticação ou codificação pelo utilizador (separadamente ou em conjunto) representam as ferramentas principais para se conseguir a segurança da rede como é conhecida nos dias de hoje. Os dois primeiros mecanismos, segurança física e segurança contra incêndios proporcionam limites que tentam a divisão da Internet global em domínios com acesso limitado do utilizador ou do serviço. 0 terceiro e quarto processos também fornecem uma divisão lógica mas numa base finamente granular (ou seja, com base em haver um utilizador validado). Há tanto vantagens como desvantagens neste tipo de estratégias de divisão ou limitação. Uma vantagem poderia ser que uma corporação apenas necessita de ter um ponto de acesso a toda a Internet e portanto apenas existe a necessidade de estabelecer e administrar uma única segurança contra incêndios, (isto está a tornar-se cada vez menos comum uma vez que o pedido de recursos e serviços encontrados na Internet tem conduzido a uma procura aumentada em largura de banda e disponibilidade de acesso à Internet). Uma desvantagem que é partilhada por todos estes processos de divisão, contudo, é que uma vez os limites 28 envolvidos ou penetrados, o atacante aparece agora como um utilizador válido no interior da rede penetrada. É nestas circunstâncias que é iniciada a maior parte de ataques de negação do serviço (DOS): um utilizador não autorizado que tenha penetrado ou envolvido os processos de segurança de uma circulação ou fornecedor de serviços aparece como um utilizador válido na rede. A rede interna por trás da protecção contra incêndios fica normalmente sem defesa uma vez que não tem processos para detectar ou limitar um ataque de negação de serviços uma vez que tenha sido iniciada.
De uma maneira geral, ataques de Negação de Serviços são dirigidos contra funções de controlo e gestão (i.e., o «plano de controlo», como é conhecido na técnica) de encaminhadores e anfitriões na rede «contaminada». Ataques DoS ou geram pacotes a taxas muito elevadas, que quando dirigidas a anfitriões e encaminhadores virão a gerar igualmente respostas altamente erradas, ou geram pacotes que têm respostas a mensagens com erro exponencial. O efeito de ataque procura tanto saturar as próprias redes com muitos pacotes inúteis como saturar a potência de computação da aplicação dos encaminhadores ou anfitriões tornando-os sem condições para levar a cabo as suas actividades normais. Em ambos os casos, quem ataca negou o serviço ou outros utilizadores legítimos do sistema.
Um objectivo importante da funcionalidade da segurança da rede de arquitectura SMP é a sua capacidade para suportar ataques de Negação do Serviço (DoS) a partir da utilização maliciosa do Equipamento de Instalações de Assinante (CPE). A interferência com CPE pode permitir que um utilizador não autorizado (e.g., perito ou pirata informático) a interromper, retirar ou negar o serviço a 29 utilizadores autorizados da rede e potencialmente tornar a rede indisponível. A protecção contra estes ataques é essencial em qualquer rede e mesmo mais crítico quando a rede está a fornecer serviços telefónicos de linha principal. Na técnica anterior, este problema foi mostrado como sendo ainda mais riqoroso na abordagem do servidor de comunicação, em que a informação de controlo atravessa a rede em conjunto com os dados de carga útil. Esta situação, conhecida como sinalização na banda permite aos piratas sofisticados a habilidade de simular ou controlar informação, tornando potencialmente a rede ou os seus elementos chave inúteis. A fim de contrariar a ameaça à DoS, a arquitectura SMP integrada proporciona um ambiente fisicamente fechado entre os dados de pagamento e planos de controlo, i.e., separação completa entre os sinais de controlo e os dados de pagamento. Além disso, a arquitectura SMP encaminha todas as chamadas de MTAs através do seu interface pacote-processamento, onde são conduzidos através dos algoritmos de protecção da Negação de Serviços antes de novo processamento.
Os algoritmos de protecção DoS e os procedimentos detectam e limitam o efeito de vários ataques de negação de serviço em tempo real enquanto que também avisam o evento aos agentes de monitorização da rede para acção futura, isto pode ser implementado tanto numa forma centralizada (e.g., no comutador de média SAFARI) como com uma abordagem distribuída; o efeito da aplicação destes algoritmos a alguns dos elementos (como opostos a todos) terá ainda um efeito significativamente positivo na redução dos prejuízos impostos por um determinado ataque de Negação de Serviço. 30
Os algoritmos de protecção de DoS servem como primeira linha na defesa de ataques de negação do serviço bloqueando os ataques de uma propagação mais profunda na rede. Os algoritmos de «preprocessamento» de protecção DoS podem incluir a detecção, o isolamento, o traçado e a referência ao ataque para permitir aos operadores gerir o ataque. A gestão do ataque é utilizada para permitir o funcionamento da rede como for entendido e assim continuar a dar origem a lucros. Com este sistema integrado, métodos e sistemas especiais a seguir descritos podem ser implementados para detecção, alarme, e protecção de ataques piratas, que entrem na rede. A sobrevivência e a protecção de DoS podem ser providenciadas, em algumas formas de realização da invenção, classificando fluxos de pacotes para todas as aplicações válidas com um esquema de isolamento classificado do fluxo hospedeiro. 0 amortecimento e a lista de espera são primeiro executados ao nivel do interface. A seguir, um programador de fila de espera ponderada com base na classe aplica limites de dimensão a cada e a todas as listas de espera, com base no tipo de aplicação que serve cada lista de espera. Um gestor de sessão administra o fluxo de pacotes das listas de espera à camada de aplicação e mantém o percurso do estado de cada aplicação.
Quando em presença de um ataque, os erros serão referidos pela camada de aplicação ao gestor de sessão. Este então faz retroceder a lista de espera, dando alarme da condição ao EMS quando o nivel de patamar programável tenha sido atingido, e desencadeia uma função de traçado e gravação dos pacotes irregulares. Adicionalmente, a arquitectura SMP permite ao utilizador instalar filtros de assinante ou para fins especiais concebidos para evitar ataques novos e diferentes. 31 A operação específica dos algoritmos de protecção DOS é como segue. Em primeiro lugar, são consideradas classificações de fluxos altamente granulares para todas as aplicações válidas de Internet no sistema. Associadas com cada fluxo estão uma fila de espera e um conjunto de amortecedores dedicados. Estas filas e conjuntos de amortecedores são depois subdivididos por interface de maneira que o efeito é haver uma fila e um conjunto de amortecedores dedicados numa base de por aplicação e por interface. Um programador ponderado de filas de espera com base em classes (CBQ) escoa cada fila de espera com uma dimensão de serviço fixa (mas programável) com base no tipo de aplicação. Assim, quando é lançado um ataque de Negação de Serviço contra o SMP, o efeito será limitado a um tipo de aplicação simples e interface contra o qual o ataque de Negação de Serviço foi dirigido.
Acima do programador da fila de espera está (funcionalmente) um gestor de sessão que interage em cada aplicação. 0 gestor da sessão passa pacotes em conjunto com a aplicação, mantendo um equilíbrio de um conjunto de amortecedores à medida que os pacotes são consumidos e mantendo o percurso do estado da aplicação em cada pacote transmitido. Uma vez que os ataques de Negação de Serviço são concebidos para gerar pedidos de aplicação mal formada ou incompleta do serviço, geram alguma forma de erro. À medida que a frequência destes erros aumenta, o ciclo devido (i.e., a dimensão de serviço da fila de espera) na fila da aplicação será diminuído. Em determinado patamar, a dimensão de serviço reduzida da fila gera um alarme (preprogramado) para o operador da rede através de EMS. 0 EMS ou operador pode então efectuar contra medidas ou o tipo bem conhecido na técnica. Este mecanismo de retorno tem o efeito de atenuar a severidade dos ataques DoS. 32
Quando o alarme dispara, é invocado um mecanismo de registo que grava um número fixo de pacotes de transgressão para análise futura. Além disso, o operador da rede tem a opção de instalar um filtro (através de EMS) no interface de entrada que filtrará todos os pacotes da fonte deste ataque à Negação de Serviço.
Considerados em conjunto, estes mecanismos proporcionam em tempo real uma resposta potente e flexivel aos ataques da Negação do Serviço, assegurando que o seu efeito é minimizado e o operador da rede prontamente notificado.
Formas de Realização Alternativas A ordem pela qual os passos do presente processo são executados é puramente ilustrativa na sua natureza. De facto, os passos podem ser executados por qualquer ordem ou em paralelo, a menos que seja indicada outra ordem pela presente divulgação. 0 processo da presente invenção pode ser levado a cabo em hardware, software ou qualquer sua combinação, uma vez que estes termos são normalmente conhecidos na técnica. Em particular, este processo pode ser executado por software, firmware ou operação de microcódigo num computador ou computadores de qualquer tipo. Além disso, o software que incorpora a presente invenção pode compreender instruções para computador em qualquer forma (e.g., código de fonte, código de objecto, microcódigo, código interpretado, etc.) guardados em qualquer meio de computador legível (e.g., memória ROM, RAM, memória Flash, média magnética, fita perfurada ou cartão; disco compacto (CD) em qualquer forma, DVD, etc.). Além disso, este software poderá apresentar-se também na forma de um sinal de dados de computador incluído 33 numa onda portadora, tal como encontrado nas bem conhecidas páginas da Web transferidas entre dispositivos ligados à Internet. De acordo com isto, a presente invenção não fica limitada a qualquer plataforma particular, a menos que seja especificado de outra maneira nesta divulgação.
Embora formas de realização particulares da presente invenção tenham sido apresentadas e descritas, será evidente para os especialistas da técnica que podem ser introduzidas alterações e modificações sem se sair desta invenção no seu aspecto mais alargado.
Lisboa, 4 de Outubro de 2010. 34
Claims (17)
- REIVINDICAÇÕES 1. Processo de comutação de dados de média, compreendendo as etapas seguintes: recepção (405) de uma multiplicidade de unidades de dados de média ao nível de uma porta de entrada de um comutador (500) de pacotes; determinação (410) de uma porta de saída correspondente do comutador (500) de pacotes para cada uma da referida multiplicidade de unidades de dados de média em função das informações de encaminhamento que correspondem a cada uma da referida multiplicidade de unidades de dados de média; orientação de cada uma da referida multiplicidade de unidades de dados de média para a referida porta de saída correspondente do comutador (500) de pacotes; ao nível de cada referida porta de saída do comutador (500) de pacotes, recepção de uma segunda multiplicidade de unidades de dados de média; e transmissão da referida segunda multiplicidade de unidades de dados de média para completar a referida comutação de dados de média; caracterizado por: a referida porta de entrada do comutador (500) de pacotes ser capaz de suportar uma combinação de 1 tipos de tráfego compreendendo tráfego do tipo por pacotes e o tráfego do tipo tdm, e ao nivel da porta de entrada, a referida orientação da referida multiplicidade de unidades de dados de média compreender reformatação (415, 420) de unidades de dados de média de múltiplos circuitos TDM destinados à mesma porta de saida do comutador de pacotes numa unidade de dados de tamanho fixo (FSDU), acréscimo de um cabeçalho ao FSDU para criar um pacote em colocar em cápsula, e orientação (430) do referido pacote em cápsula para a porta de saida correspondente; e ao nível de cada porta de saída do comutador (500) de pacotes, a referida recepção (450) da referida segunda multiplicidade de unidades de dados de média compreender a recepção e reformatação (455, 460, 465) dos referidos pacotes em cápsula na referida segunda multiplicidade de unidades de dados de média.
- 2. Processo de acordo com a reivindicação 1, caracterizado por ao nível da referida porta de saída do comutador (500) de pacotes, a referida reformatação compreender: a remoção do referido cabeçalho do referido pacote em cápsula; e a extracção da referida segunda multiplicidade de unidades de dados de média. 2
- 3. Processo de acordo com qualquer das reivindicações anteriores, caracterizado por a referida orientação de cada um dos referidos pacotes em cápsula para a referida porta de saída correspondente se produzir antes do fim da estrutura de tempo.
- 4. Processo de acordo com a reivindicação 3, caracterizado por a referida orientação de cada pacote em cápsula para a referida porta de saída correspondente ocorrer quando cada um dos referidos pacotes em cápsula está cheio.
- 5. Processo de acordo com a reivindicação 1, caracterizado por as referidas unidades de dados de média compreenderem dados entre: i dados de áudio; ii dados de video; ou iii sinais de televisão sob a forma digital
- 6. Processo de acordo com a reivindicação 1, caracterizado por a referida determinação compreender também o tratamento codificado das referidas unidades de dados de média.
- 7. Processo de acordo com a reivindicação 6, caracterizado por o referido tratamento codificado compreender também a ocultação dos endereços IP da parte emissora à parte receptora e a ocultação dos endereços IP da parte receptora à parte emissora.
- 8. Processo de acordo com a reivindicação 6, caracterizado por o referido tratamento codificado compreender também a prestação de serviços CALEA 3 não detectáveis por uma ou por outra das partes emissora e receptora.
- 9. Processo de acordo com a reivindicação 1, caracterizado por a referida determinação compreender a solicitação de informações de encaminhamento correspondentes a cada uma das referidas multiplicidades de unidades de dados de média.
- 10. Processo de acordo com a reivindicação 1, caracterizado por a referida determinação compreender também a colocação em fila de espera das referidas unidades de dados de média utilizando as filas de espera de elevada granularidade à base de classes para assegurar uma protecção contra os ataques de Negação de Serviços.
- 11. Processo de acordo com a reivindicação 10, caracterizado por a colocação em fila de espera empregar uma multiplicidade de filas de espera por cada classe de serviço.
- 12. Processo de acordo com a reivindicação 1, caracterizado por a referida orientação se produzir em tempo real.
- 13. Processo de acordo com a reivindicação 1, caracterizado por compreender também o comando da referida comutação de dados de média através de um sistema único de gestão de elementos.
- 14. Aparelho (500) de comunicação de média integrada, compreendendo: 4 uma multiplicidade de portas (510) de entrada recebendo, cada uma, uma multiplicidade de unidades de dados de média; um processador ligado, que compreende meios para: determinar uma porta de saída correspondente a cada uma das referidas multiplicidades de unidades de média em função das informações de encaminhamento, correspondendo a cada uma das referidas multiplicidades de unidades de dados de média; uma multiplicidade de portas (510) de saída compreendendo meios para receber uma segunda multiplicidade de dados de média; e meios para transmissão da referida segunda multiplicidade de unidades de dados de média para terminar a referida comutação de média; caracterizado por: pelo menos, uma das referidas portas de entrada do comutador (500) de pacotes ser capaz de suportar uma combinação de tipos de tráfego incluindo o tráfego do tipo por pacotes e o tráfego do tipo TDM; o referido processador compreender também meios para reformatar unidades de dados de média de múltiplos circuitos TDM destinados à mesma porta de saída do comutador (500) de pacotes numa unidade de dados de dimensão fixa (FSDU) compreender meios para acrescentar um cabeçalho à FSDU para criar um pacote em cápsula, 5 compreender meios para orientar o referido pacote em cápsula para a referida porta de saída correspondente; e os referidos meios de recepção da referida segunda multiplicidade de unidades de média compreender meios para receber e reformatar os referidos pacotes em cápsula na referida segunda multiplicidade de unidades de dados de média.
- 15. Aparelho de acordo com a reivindicação 14, caracterizado por as referidas portas de entrada, o referido processador e as referidas portas de saída serem fornecidas no mesmo chassis.
- 16. Aparelho de acordo com a reivindicação 14, caracterizado por o referido processador compreender também filas de espera de elevada granularidade à base de classes das referidas unidades de dados de média formadas para assegurar uma protecção contra os ataques de Negação de Serviço.
- 17. Aparelho de acordo com a reivindicação 14, caracterizado por as referidas portas de entrada, o referido processador e as referidas portas de saída serem controlados por um sistema de gestão de um só elemento. Lisboa, 4 de Outubro de 2010. 6telefone 2/4 Fig. 3Fig. 4A Fig. 4B Fluxo de entrada Fluxo de saída 405 410 recebe dados de circuito de intrvalo de tempo Leitura de memória para determinar informação de encaminhamento de circuitos 415 420 Dados directos para a lista baseada no número da porta na informação de encaminhamento 425 REcolha de dados suficientes | para preenchimento de FSDU e depois acrescentar cabeçalho estrutura Enviar FSDU para a estrutura de pacotes Recebido FSDU da estrutura de pacotes e sua comunicação em FIFO Leitura de c de FSDU e determinar fonte abeçalho π FIFO para < aportada Leitura da memória utilizando a porta da fonte para ajustar os dados de FSDU ao intervalo de tempo correcto Colocar dados nos amortecedores dos intervalos de tempo correctos Leitura dos dados fora dos amortecedores durante o tempo correcto 450 455 460 465 470 430 3/4 Fig.5 5004/4 ◄- To Port 1 -4- Το Port Β Fig. 6 cabeçalho DSOfttl. DS0#m+1,... cabeçalho DSOfti, DS0#n+1,... (-620 (-610 (-620 (-610 • • • (~620 ^—610 p620 Ç—610 cabeçalho DS0#u, DS0#J+1t... cabeçalho DSO*v, DSO#v+1,...
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US37768002P | 2002-05-03 | 2002-05-03 |
Publications (1)
Publication Number | Publication Date |
---|---|
PT1527570E true PT1527570E (pt) | 2010-10-12 |
Family
ID=29401549
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PT03747650T PT1527570E (pt) | 2002-05-03 | 2003-05-02 | Arquitectura de comutação de comunicações |
Country Status (10)
Country | Link |
---|---|
US (8) | US7035289B2 (pt) |
EP (2) | EP1527570B1 (pt) |
JP (2) | JP2005525024A (pt) |
AT (2) | ATE473574T1 (pt) |
AU (2) | AU2003264756A1 (pt) |
CA (2) | CA2484722C (pt) |
DE (2) | DE60333297D1 (pt) |
ES (1) | ES2349122T3 (pt) |
PT (1) | PT1527570E (pt) |
WO (2) | WO2003094453A1 (pt) |
Families Citing this family (147)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7304985B2 (en) * | 2001-09-24 | 2007-12-04 | Marvin L Sojka | Multimedia communication management system with line status notification for key switch emulation |
US6658091B1 (en) | 2002-02-01 | 2003-12-02 | @Security Broadband Corp. | LIfestyle multimedia security system |
CN100346295C (zh) * | 2002-03-28 | 2007-10-31 | 艾利森电话股份有限公司 | 用于支持进程/应用程序控制的装置和方法 |
ES2349122T3 (es) * | 2002-05-03 | 2010-12-28 | Cedar Point Communications, Inc. | Arquitectura de conmutacion de comunicaciones. |
US7420988B1 (en) * | 2002-08-14 | 2008-09-02 | Juniper Networks, Inc. | Network relay protocol having timed packet aggregation |
US7447201B2 (en) * | 2003-02-07 | 2008-11-04 | Fujitsu Limited | Multicasting in a high-speed switching environment |
US7283517B2 (en) * | 2003-07-22 | 2007-10-16 | Innomedia Pte | Stand alone multi-media terminal adapter with network address translation and port partitioning |
JP4432388B2 (ja) * | 2003-08-12 | 2010-03-17 | 株式会社日立製作所 | 入出力制御装置 |
US7417981B2 (en) * | 2003-10-15 | 2008-08-26 | Vonage Holdings Corp. | Method and apparatus for enhanced Internet Telephony |
US20050094773A1 (en) * | 2003-10-31 | 2005-05-05 | Lucent Technologies Inc. | CALEA application server complex |
US7631225B2 (en) * | 2004-10-01 | 2009-12-08 | Cisco Technology, Inc. | Approach for characterizing the dynamic availability behavior of network elements |
US7620714B1 (en) | 2003-11-14 | 2009-11-17 | Cisco Technology, Inc. | Method and apparatus for measuring the availability of a network element or service |
CA2544033C (en) * | 2003-11-21 | 2013-07-23 | Nimcat Networks Inc. | Back up of network devices |
US20050141523A1 (en) * | 2003-12-29 | 2005-06-30 | Chiang Yeh | Traffic engineering scheme using distributed feedback |
US10200504B2 (en) | 2007-06-12 | 2019-02-05 | Icontrol Networks, Inc. | Communication protocols over internet protocol (IP) networks |
US11677577B2 (en) | 2004-03-16 | 2023-06-13 | Icontrol Networks, Inc. | Premises system management using status signal |
US8635350B2 (en) | 2006-06-12 | 2014-01-21 | Icontrol Networks, Inc. | IP device discovery systems and methods |
US10444964B2 (en) | 2007-06-12 | 2019-10-15 | Icontrol Networks, Inc. | Control system user interface |
US7711796B2 (en) | 2006-06-12 | 2010-05-04 | Icontrol Networks, Inc. | Gateway registry methods and systems |
US10313303B2 (en) | 2007-06-12 | 2019-06-04 | Icontrol Networks, Inc. | Forming a security network including integrated security system components and network devices |
US11368429B2 (en) | 2004-03-16 | 2022-06-21 | Icontrol Networks, Inc. | Premises management configuration and control |
US9729342B2 (en) | 2010-12-20 | 2017-08-08 | Icontrol Networks, Inc. | Defining and implementing sensor triggered response rules |
US11159484B2 (en) | 2004-03-16 | 2021-10-26 | Icontrol Networks, Inc. | Forming a security network including integrated security system components and network devices |
US9141276B2 (en) | 2005-03-16 | 2015-09-22 | Icontrol Networks, Inc. | Integrated interface for mobile device |
US9609003B1 (en) | 2007-06-12 | 2017-03-28 | Icontrol Networks, Inc. | Generating risk profile using data of home monitoring and security system |
US20170118037A1 (en) | 2008-08-11 | 2017-04-27 | Icontrol Networks, Inc. | Integrated cloud system for premises automation |
US10721087B2 (en) | 2005-03-16 | 2020-07-21 | Icontrol Networks, Inc. | Method for networked touchscreen with integrated interfaces |
US20090077623A1 (en) | 2005-03-16 | 2009-03-19 | Marc Baum | Security Network Integrating Security System and Network Devices |
AU2005223267B2 (en) | 2004-03-16 | 2010-12-09 | Icontrol Networks, Inc. | Premises management system |
US11811845B2 (en) | 2004-03-16 | 2023-11-07 | Icontrol Networks, Inc. | Communication protocols over internet protocol (IP) networks |
US11316958B2 (en) | 2008-08-11 | 2022-04-26 | Icontrol Networks, Inc. | Virtual device systems and methods |
US10375253B2 (en) | 2008-08-25 | 2019-08-06 | Icontrol Networks, Inc. | Security system with networked touchscreen and gateway |
US11244545B2 (en) | 2004-03-16 | 2022-02-08 | Icontrol Networks, Inc. | Cross-client sensor user interface in an integrated security network |
US11277465B2 (en) | 2004-03-16 | 2022-03-15 | Icontrol Networks, Inc. | Generating risk profile using data of home monitoring and security system |
US11343380B2 (en) | 2004-03-16 | 2022-05-24 | Icontrol Networks, Inc. | Premises system automation |
US10339791B2 (en) | 2007-06-12 | 2019-07-02 | Icontrol Networks, Inc. | Security network integrated with premise security system |
US10237237B2 (en) | 2007-06-12 | 2019-03-19 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US9191228B2 (en) | 2005-03-16 | 2015-11-17 | Icontrol Networks, Inc. | Cross-client sensor user interface in an integrated security network |
US11113950B2 (en) | 2005-03-16 | 2021-09-07 | Icontrol Networks, Inc. | Gateway integrated with premises security system |
US8988221B2 (en) | 2005-03-16 | 2015-03-24 | Icontrol Networks, Inc. | Integrated security system with parallel processing architecture |
US8963713B2 (en) | 2005-03-16 | 2015-02-24 | Icontrol Networks, Inc. | Integrated security network with security alarm signaling system |
US10522026B2 (en) | 2008-08-11 | 2019-12-31 | Icontrol Networks, Inc. | Automation system user interface with three-dimensional display |
US11489812B2 (en) | 2004-03-16 | 2022-11-01 | Icontrol Networks, Inc. | Forming a security network including integrated security system components and network devices |
US11582065B2 (en) | 2007-06-12 | 2023-02-14 | Icontrol Networks, Inc. | Systems and methods for device communication |
US10348575B2 (en) | 2013-06-27 | 2019-07-09 | Icontrol Networks, Inc. | Control system user interface |
US10382452B1 (en) | 2007-06-12 | 2019-08-13 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US10127802B2 (en) | 2010-09-28 | 2018-11-13 | Icontrol Networks, Inc. | Integrated security system with parallel processing architecture |
US10142392B2 (en) | 2007-01-24 | 2018-11-27 | Icontrol Networks, Inc. | Methods and systems for improved system performance |
US10156959B2 (en) | 2005-03-16 | 2018-12-18 | Icontrol Networks, Inc. | Cross-client sensor user interface in an integrated security network |
US9531593B2 (en) | 2007-06-12 | 2016-12-27 | Icontrol Networks, Inc. | Takeover processes in security network integrated with premise security system |
US11201755B2 (en) | 2004-03-16 | 2021-12-14 | Icontrol Networks, Inc. | Premises system management using status signal |
US11916870B2 (en) | 2004-03-16 | 2024-02-27 | Icontrol Networks, Inc. | Gateway registry methods and systems |
US7783769B2 (en) | 2004-03-31 | 2010-08-24 | Intel Corporation | Accelerated TCP (Transport Control Protocol) stack processing |
US7606235B1 (en) * | 2004-06-03 | 2009-10-20 | Juniper Networks, Inc. | Constraint-based label switched path selection within a computer network |
US7653068B2 (en) * | 2004-06-09 | 2010-01-26 | Alcatel-Lucent Usa Inc. | Method and apparatus for providing call admission control in packet networks |
US7730519B2 (en) * | 2004-09-17 | 2010-06-01 | At&T Intellectual Property I, L.P. | Detection of encrypted packet streams using feedback probing |
US8332938B2 (en) | 2004-09-17 | 2012-12-11 | At&T Intellectual Property I, L.P. | Detection of encrypted packet streams using a timer |
US7451309B2 (en) | 2004-09-17 | 2008-11-11 | At&T Intellectual Property L.P. | Signature specification for encrypted packet streams |
US7761705B2 (en) * | 2004-09-17 | 2010-07-20 | At&T Intellectual Property I, L.P. | Detection of encrypted packet streams |
US7558199B1 (en) | 2004-10-26 | 2009-07-07 | Juniper Networks, Inc. | RSVP-passive interfaces for traffic engineering peering links in MPLS networks |
US7974216B2 (en) * | 2004-11-22 | 2011-07-05 | Cisco Technology, Inc. | Approach for determining the real time availability of a group of network elements |
US20060126664A1 (en) * | 2004-12-01 | 2006-06-15 | David Horton | Systems and methods for dynamic modification of a stream of data packets |
US7852831B2 (en) * | 2005-02-22 | 2010-12-14 | Akbar Imran M | Method and system for providing private virtual secure Voice over Internet Protocol communications |
ATE373399T1 (de) * | 2005-03-04 | 2007-09-15 | Alcatel Lucent | Vermittlung für integrierte telekommunikationssnetzwerke |
US11615697B2 (en) | 2005-03-16 | 2023-03-28 | Icontrol Networks, Inc. | Premise management systems and methods |
US9306809B2 (en) | 2007-06-12 | 2016-04-05 | Icontrol Networks, Inc. | Security system with networked touchscreen |
US11700142B2 (en) | 2005-03-16 | 2023-07-11 | Icontrol Networks, Inc. | Security network integrating security system and network devices |
US20120324566A1 (en) | 2005-03-16 | 2012-12-20 | Marc Baum | Takeover Processes In Security Network Integrated With Premise Security System |
US10999254B2 (en) | 2005-03-16 | 2021-05-04 | Icontrol Networks, Inc. | System for data routing in networks |
US20170180198A1 (en) | 2008-08-11 | 2017-06-22 | Marc Baum | Forming a security network including integrated security system components |
US11496568B2 (en) | 2005-03-16 | 2022-11-08 | Icontrol Networks, Inc. | Security system with networked touchscreen |
US20110128378A1 (en) | 2005-03-16 | 2011-06-02 | Reza Raji | Modular Electronic Display Platform |
CN100563146C (zh) * | 2005-04-30 | 2009-11-25 | 华为技术有限公司 | 一种基于分组交换的时分复用数据传输方法 |
BRPI0520275B1 (pt) * | 2005-05-24 | 2019-03-06 | Telecom Italia S.P.A. | Método para dimensionar um aparelho manipulador de pacotes de dados em uma rede de comunicações móvel, meio legível por computador, e, aparelho manipulador de pacotes de dados |
WO2006130000A1 (en) * | 2005-05-31 | 2006-12-07 | Snap-On Incorporated | Integrated interface circuit for communication between a micro-controller and data networks using different network protocols |
US7983176B2 (en) * | 2005-09-16 | 2011-07-19 | At&T Intellectual Property I, Lp | Method and system for monitoring communications of an individual in a packet network |
US8347341B2 (en) * | 2006-03-16 | 2013-01-01 | Time Warner Cable Inc. | Methods and apparatus for centralized content and data delivery |
US7995612B2 (en) | 2006-03-31 | 2011-08-09 | Verint Americas, Inc. | Systems and methods for capturing communication signals [32-bit or 128-bit addresses] |
US7633930B2 (en) * | 2006-03-31 | 2009-12-15 | Verint Americas Inc. | Systems and methods for capturing multimedia communication signals |
US10079839B1 (en) | 2007-06-12 | 2018-09-18 | Icontrol Networks, Inc. | Activation of gateway device |
US8363805B2 (en) * | 2006-06-22 | 2013-01-29 | Burns Jr James M | Media terminal adapter (MTA) initialization process display by use of an embedded caller name and caller identification |
US7468973B2 (en) * | 2006-07-07 | 2008-12-23 | Alcatel-Lucent Usa Inc. | Switch data transform to IMS process |
US8675856B2 (en) * | 2006-08-01 | 2014-03-18 | Cisco Technology, Inc. | Media terminal adapter (MTA) routing of telephone calls based on caller identification information |
US8233491B2 (en) * | 2006-09-28 | 2012-07-31 | Burns Jr James M | Embedded media terminal adapter (EMTA) endpoint redirect mode |
US8526583B2 (en) * | 2006-09-29 | 2013-09-03 | James M. Burns, JR. | Media terminal adapter (MTA) local ringback option |
US8280011B2 (en) * | 2006-12-08 | 2012-10-02 | Verint Americas, Inc. | Recording in a distributed environment |
US8010079B2 (en) * | 2006-12-28 | 2011-08-30 | Trueposition, Inc. | Emergency wireless location system including a wireless transceiver |
US7848733B2 (en) * | 2006-12-28 | 2010-12-07 | Trueposition, Inc. | Emergency wireless location system including a location determining receiver |
US11706279B2 (en) | 2007-01-24 | 2023-07-18 | Icontrol Networks, Inc. | Methods and systems for data communication |
US7633385B2 (en) | 2007-02-28 | 2009-12-15 | Ucontrol, Inc. | Method and system for communicating with and controlling an alarm system from a remote server |
US8451986B2 (en) | 2007-04-23 | 2013-05-28 | Icontrol Networks, Inc. | Method and system for automatically providing alternate network access for telecommunications |
US20080276294A1 (en) * | 2007-05-02 | 2008-11-06 | Brady Charles J | Legal intercept of communication traffic particularly useful in a mobile environment |
US11212192B2 (en) | 2007-06-12 | 2021-12-28 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US10498830B2 (en) | 2007-06-12 | 2019-12-03 | Icontrol Networks, Inc. | Wi-Fi-to-serial encapsulation in systems |
US11218878B2 (en) | 2007-06-12 | 2022-01-04 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US11316753B2 (en) | 2007-06-12 | 2022-04-26 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US10423309B2 (en) | 2007-06-12 | 2019-09-24 | Icontrol Networks, Inc. | Device integration framework |
US11423756B2 (en) | 2007-06-12 | 2022-08-23 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US10616075B2 (en) | 2007-06-12 | 2020-04-07 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US10389736B2 (en) | 2007-06-12 | 2019-08-20 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US11237714B2 (en) | 2007-06-12 | 2022-02-01 | Control Networks, Inc. | Control system user interface |
US11646907B2 (en) | 2007-06-12 | 2023-05-09 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US12003387B2 (en) | 2012-06-27 | 2024-06-04 | Comcast Cable Communications, Llc | Control system user interface |
US11089122B2 (en) | 2007-06-12 | 2021-08-10 | Icontrol Networks, Inc. | Controlling data routing among networks |
US10666523B2 (en) | 2007-06-12 | 2020-05-26 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US10051078B2 (en) | 2007-06-12 | 2018-08-14 | Icontrol Networks, Inc. | WiFi-to-serial encapsulation in systems |
US11601810B2 (en) | 2007-06-12 | 2023-03-07 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US10523689B2 (en) | 2007-06-12 | 2019-12-31 | Icontrol Networks, Inc. | Communication protocols over internet protocol (IP) networks |
US11831462B2 (en) | 2007-08-24 | 2023-11-28 | Icontrol Networks, Inc. | Controlling data routing in premises management systems |
CN101159751B (zh) * | 2007-11-14 | 2011-10-26 | 中兴通讯股份有限公司 | 一种通过ip交换网传送时分复用业务的方法和装置 |
US11916928B2 (en) | 2008-01-24 | 2024-02-27 | Icontrol Networks, Inc. | Communication protocols over internet protocol (IP) networks |
JP5213474B2 (ja) * | 2008-02-12 | 2013-06-19 | キヤノン株式会社 | ネットワーク機器、その制御方法、およびプログラム |
US8155520B1 (en) * | 2008-04-16 | 2012-04-10 | Cyan, Inc. | Multi-fabric shelf for a transport network |
US20170185278A1 (en) | 2008-08-11 | 2017-06-29 | Icontrol Networks, Inc. | Automation system user interface |
US11729255B2 (en) | 2008-08-11 | 2023-08-15 | Icontrol Networks, Inc. | Integrated cloud system with lightweight gateway for premises automation |
US11792036B2 (en) | 2008-08-11 | 2023-10-17 | Icontrol Networks, Inc. | Mobile premises automation platform |
US11758026B2 (en) | 2008-08-11 | 2023-09-12 | Icontrol Networks, Inc. | Virtual device systems and methods |
US10530839B2 (en) | 2008-08-11 | 2020-01-07 | Icontrol Networks, Inc. | Integrated cloud system with lightweight gateway for premises automation |
US11258625B2 (en) | 2008-08-11 | 2022-02-22 | Icontrol Networks, Inc. | Mobile premises automation platform |
US8542581B2 (en) * | 2008-09-18 | 2013-09-24 | Alcatel Lucent | System and method for exposing malicious clients in wireless access networks |
EP2200200B1 (en) * | 2008-12-19 | 2011-04-13 | Alcatel Lucent | Scalable network element with Segmentation and Reassembly (SAR) functionality for switching time division multiplex signals |
CN101867669B (zh) * | 2009-04-20 | 2013-02-13 | 鸿富锦精密工业(深圳)有限公司 | 多媒体终端适配器及其自动转移呼叫的方法 |
US8638211B2 (en) | 2009-04-30 | 2014-01-28 | Icontrol Networks, Inc. | Configurable controller and interface for home SMA, phone and multimedia |
EP2259508B1 (en) * | 2009-06-04 | 2013-02-13 | Alcatel Lucent | Network element for switching time division multiplex signals using cell switch matrix having reduced cell loss probability |
US8331244B1 (en) * | 2009-08-21 | 2012-12-11 | Adtran, Inc. | System and method for propagating TDM fault information through a packet network |
US8570855B2 (en) * | 2009-09-15 | 2013-10-29 | Genband Us Llc | Access gateway management system |
US20110078274A1 (en) * | 2009-09-29 | 2011-03-31 | Sonus Networks, Inc. | Method and System for Implementing Redundancy at Signaling Gateway Using Dynamic SIGTRAN Architecture |
US20110075654A1 (en) * | 2009-09-29 | 2011-03-31 | Sonus Networks, Inc. | Method and System for Implementing Redundancy at Signaling Gateway Using Dynamic SIGTRAN Architecture |
CN102143140A (zh) * | 2010-01-28 | 2011-08-03 | 国基电子(上海)有限公司 | 调制解调器及其支持多种通信协议的方法 |
US9787827B2 (en) | 2010-03-31 | 2017-10-10 | Genband Us Llc | Systems and methods for fused services including an integrated management system |
EP2569712B1 (en) | 2010-05-10 | 2021-10-13 | Icontrol Networks, Inc. | Control system user interface |
US8836467B1 (en) | 2010-09-28 | 2014-09-16 | Icontrol Networks, Inc. | Method, system and apparatus for automated reporting of account and sensor zone information to a central station |
US11750414B2 (en) | 2010-12-16 | 2023-09-05 | Icontrol Networks, Inc. | Bidirectional security sensor communication for a premises security system |
US9147337B2 (en) | 2010-12-17 | 2015-09-29 | Icontrol Networks, Inc. | Method and system for logging security event data |
US9729408B2 (en) * | 2012-02-15 | 2017-08-08 | Vss Monitoring, Inc. | Encapsulating data packets |
US8793766B2 (en) | 2012-03-13 | 2014-07-29 | International Business Machines Corporation | Method and apparatus for security-aware elasticity of application and services |
US9270827B2 (en) | 2012-09-07 | 2016-02-23 | Genesys Telecommunications Laboratories, Inc. | Dynamic management and redistribution of contact center media traffic |
US9525562B2 (en) * | 2013-05-23 | 2016-12-20 | Cahon Systems, Inc. | Modular deterministic communication terminal for remote systems |
JP6176058B2 (ja) * | 2013-10-29 | 2017-08-09 | 株式会社ソシオネクスト | ダイレクトメモリアクセス制御装置、その制御方法、及び情報処理システム |
EP2882120B1 (en) * | 2013-12-06 | 2016-03-09 | ADVA Optical Networking SE | A method and apparatus for mitigation of packet delay variation |
US11146637B2 (en) | 2014-03-03 | 2021-10-12 | Icontrol Networks, Inc. | Media content management |
US11405463B2 (en) | 2014-03-03 | 2022-08-02 | Icontrol Networks, Inc. | Media content management |
US10516905B2 (en) * | 2015-04-01 | 2019-12-24 | Nokia Of America Corporation | Dynamic service flow creation for packet cable quality of service guarantee in a distributed cable management system |
US9813945B2 (en) * | 2015-12-16 | 2017-11-07 | Time Warner Cable Enterprises Llc | System and method for end-to-end quality of service control for a remote service gateway |
US11700530B2 (en) | 2020-09-21 | 2023-07-11 | Cogitari, Inc. | Radio frequency threat detection |
US11653294B2 (en) * | 2021-02-05 | 2023-05-16 | Charter Communications Operating, Llc | System and method to detect and manage wireless tethering |
US11962515B2 (en) | 2022-02-28 | 2024-04-16 | Nokia Solutions And Networks Oy | Deterministic communications via packet-switched networks |
Family Cites Families (43)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US3967264A (en) * | 1975-01-31 | 1976-06-29 | Westinghouse Electric Corporation | Distribution network power line communication system including addressable interrogation and response repeater |
FR2538976A1 (fr) * | 1982-12-29 | 1984-07-06 | Servel Michel | Systeme de commutation de paquets synchrones de longueur fixe |
EP0312628B1 (en) | 1987-10-20 | 1993-12-29 | International Business Machines Corporation | High-speed modular switching apparatus for circuit and packet switched traffic |
US4893306A (en) * | 1987-11-10 | 1990-01-09 | Bell Communications Research, Inc. | Method and apparatus for multiplexing circuit and packet traffic |
US4962497A (en) * | 1989-09-21 | 1990-10-09 | At&T Bell Laboratories | Building-block architecture of a multi-node circuit-and packet-switching system |
DE59109144D1 (de) | 1991-08-19 | 1999-09-09 | Siemens Ag | Verfahren und Anordnung zur Übermittlung von STM-vermittelten Nachrichten über ATM-Vermittlungsstellen |
JPH05199258A (ja) | 1992-01-21 | 1993-08-06 | Nippon Telegr & Teleph Corp <Ntt> | ディジタル通信装置 |
US5278828A (en) * | 1992-06-04 | 1994-01-11 | Bell Communications Research, Inc. | Method and system for managing queued cells |
EP0702473A1 (en) * | 1994-09-19 | 1996-03-20 | International Business Machines Corporation | A method and an apparatus for shaping the output traffic in a fixed length cell switching network node |
US6091725A (en) | 1995-12-29 | 2000-07-18 | Cisco Systems, Inc. | Method for traffic management, traffic prioritization, access control, and packet forwarding in a datagram computer network |
US6069890A (en) * | 1996-06-26 | 2000-05-30 | Bell Atlantic Network Services, Inc. | Internet telephone service |
US5889773A (en) * | 1996-11-27 | 1999-03-30 | Alcatel Usa Sourcing, L.P. | Method and apparatus for placing time division multiplexed telephony traffic into an asynchronous transfer mode format |
WO1998024267A1 (en) * | 1996-11-27 | 1998-06-04 | Alcatel Usa Sourcing, L.P. | Telecommunications switch for providing telephony traffic integrated with video information services |
JP3525656B2 (ja) * | 1996-12-06 | 2004-05-10 | 株式会社日立製作所 | パケット交換機、および輻輳通知方式 |
US5896386A (en) * | 1997-01-31 | 1999-04-20 | Nec Usa, Inc. | Queue management method for wireless asynchronous transfer mode network interface card |
US6034960A (en) * | 1997-12-04 | 2000-03-07 | Nortel Networks Corporation | ATM service scheduler using reverse-binary scattering and time-space mapping |
US6577631B1 (en) * | 1998-06-10 | 2003-06-10 | Merlot Communications, Inc. | Communication switching module for the transmission and control of audio, video, and computer data over a single network fabric |
US6452915B1 (en) * | 1998-07-10 | 2002-09-17 | Malibu Networks, Inc. | IP-flow classification in a wireless point to multi-point (PTMP) transmission system |
AU2353500A (en) * | 1998-12-08 | 2000-06-26 | Tellabs Operations, Inc. | Signal processing system and hybrid switching |
US6931002B1 (en) * | 1998-12-08 | 2005-08-16 | Daniel S. Simpkins | Hybrid switching |
CA2290304C (en) | 1998-12-23 | 2009-03-17 | Nortel Networks Corporation | Direct end-office atm trunking |
US6219161B1 (en) * | 1999-01-25 | 2001-04-17 | Telcordia Technologies, Inc. | Optical layer survivability and security system |
US6493346B1 (en) | 1999-03-31 | 2002-12-10 | Alcatel Usa Sourcing, L.P. | System for providing conversion of TDM-based frame relay data in a cross-connect matrix to and from ATM data |
US7933295B2 (en) * | 1999-04-13 | 2011-04-26 | Broadcom Corporation | Cable modem with voice processing capability |
EP1059754A1 (en) * | 1999-06-09 | 2000-12-13 | Lucent Technologies Inc. | Common header encoding for packet switched networks |
TW580813B (en) | 1999-11-23 | 2004-03-21 | Ibm | Method and system for controlling transmission of packets in computer networks |
ATE388542T1 (de) * | 1999-12-13 | 2008-03-15 | Broadcom Corp | Sprach-durchgangsvorrichtung mit sprachsynchronisierung in abwärtsrichtung |
US6577718B1 (en) * | 1999-12-22 | 2003-06-10 | At&T Corp. | Method for call forwarding without hairpinning and with split billing |
US6751238B1 (en) * | 2000-04-20 | 2004-06-15 | Aztech Partners, Inc. | Phase re-alignment of SONET/SDH network switch without pointer manipulation |
US6647428B1 (en) * | 2000-05-05 | 2003-11-11 | Luminous Networks, Inc. | Architecture for transport of multiple services in connectionless packet-based communication networks |
ES2220661T3 (es) * | 2000-07-05 | 2004-12-16 | Roke Manor Research Limited | Metodo de operacion de una memoria temporal de reensamblado de paquetes. |
US7209473B1 (en) * | 2000-08-18 | 2007-04-24 | Juniper Networks, Inc. | Method and apparatus for monitoring and processing voice over internet protocol packets |
US6870841B1 (en) * | 2000-09-18 | 2005-03-22 | At&T Corp. | Controlled transmission across packet network |
JP3678640B2 (ja) * | 2000-09-27 | 2005-08-03 | 日本電気株式会社 | VoIPゲートウエイ装置およびディジタル1リンク中継交換方法 |
EP1202599A3 (en) * | 2000-10-31 | 2004-03-24 | Chiaro Networks Ltd. | System and method for routing IP packets using an optical core |
WO2002069073A2 (en) * | 2000-11-13 | 2002-09-06 | Starguide Digital Networks, Inc. | Ethernet digital storage (eds) card and satellite transmission system including faxing capability |
US7061935B1 (en) * | 2000-11-21 | 2006-06-13 | Transwitch Corporation | Method and apparatus for arbitrating bandwidth in a communications switch |
US6959008B2 (en) * | 2001-03-31 | 2005-10-25 | Redback Networks Inc. | Alignment of TDM-based signals for packet transmission using framed and unframed operations |
US7283519B2 (en) * | 2001-04-13 | 2007-10-16 | Esn, Llc | Distributed edge switching system for voice-over-packet multiservice network |
US7010002B2 (en) * | 2001-06-14 | 2006-03-07 | At&T Corp. | Broadband network with enterprise wireless communication method for residential and business environment |
US8126722B2 (en) * | 2001-12-20 | 2012-02-28 | Verizon Business Global Llc | Application infrastructure platform (AIP) |
ES2349122T3 (es) * | 2002-05-03 | 2010-12-28 | Cedar Point Communications, Inc. | Arquitectura de conmutacion de comunicaciones. |
US7369491B1 (en) * | 2003-05-14 | 2008-05-06 | Nortel Networks Limited | Regulating data-burst transfer |
-
2003
- 2003-05-02 ES ES03747650T patent/ES2349122T3/es not_active Expired - Lifetime
- 2003-05-02 CA CA2484722A patent/CA2484722C/en not_active Expired - Lifetime
- 2003-05-02 WO PCT/US2003/013788 patent/WO2003094453A1/en active Application Filing
- 2003-05-02 DE DE60333297T patent/DE60333297D1/de not_active Expired - Lifetime
- 2003-05-02 US US10/428,593 patent/US7035289B2/en active Active
- 2003-05-02 PT PT03747650T patent/PT1527570E/pt unknown
- 2003-05-02 AT AT03747650T patent/ATE473574T1/de not_active IP Right Cessation
- 2003-05-02 JP JP2004502564A patent/JP2005525024A/ja active Pending
- 2003-05-02 EP EP03747650A patent/EP1527570B1/en not_active Expired - Lifetime
- 2003-05-02 AU AU2003264756A patent/AU2003264756A1/en not_active Abandoned
- 2003-05-05 AU AU2003231294A patent/AU2003231294A1/en not_active Abandoned
- 2003-05-05 AT AT03724433T patent/ATE438993T1/de not_active IP Right Cessation
- 2003-05-05 WO PCT/US2003/013920 patent/WO2003094459A1/en active Application Filing
- 2003-05-05 DE DE60328689T patent/DE60328689D1/de not_active Expired - Lifetime
- 2003-05-05 EP EP03724433A patent/EP1525725B1/en not_active Expired - Lifetime
- 2003-05-05 US US10/430,200 patent/US7505456B2/en active Active
- 2003-05-05 CA CA002484751A patent/CA2484751A1/en not_active Abandoned
- 2003-05-05 JP JP2004502570A patent/JP2005525025A/ja active Pending
-
2006
- 2006-04-24 US US11/410,848 patent/US7450614B2/en not_active Expired - Lifetime
-
2008
- 2008-11-10 US US12/267,743 patent/US20090238180A1/en not_active Abandoned
-
2009
- 2009-02-06 US US12/367,253 patent/US8773996B2/en not_active Expired - Lifetime
- 2009-06-03 US US12/477,507 patent/US8223801B2/en not_active Expired - Lifetime
-
2012
- 2012-07-16 US US13/550,268 patent/US8619578B2/en not_active Expired - Lifetime
-
2014
- 2014-06-20 US US14/310,743 patent/US9544080B2/en not_active Expired - Lifetime
Also Published As
Similar Documents
Publication | Publication Date | Title |
---|---|---|
PT1527570E (pt) | Arquitectura de comutação de comunicações | |
Arango et al. | Media gateway control protocol (MGCP) version 1.0 | |
US6574335B1 (en) | Method for simulating a ring back for a call between parties in different communication networks | |
US7151772B1 (en) | Method for performing lawfully-authorized electronic surveillance | |
US7742467B1 (en) | Method for performing segmented resource reservation | |
US8284911B1 (en) | Method for call forwarding without hairpinning and with split billing | |
US7274684B2 (en) | Method and system for implementing and managing a multimedia access network device | |
US20060077963A1 (en) | Methods and systems for per-session traffic rate policing in a media gateway | |
JP2006311628A (ja) | ネットワークリソースの割当て方法、装置およびデバイス | |
US6870845B1 (en) | Method for providing privacy by network address translation | |
Ayokunle | Integrating Voice over Internet Protocol (VoIP) technology as a communication tool on a converged network in Nigeria | |
US7545801B2 (en) | In-band control mechanism for switching architecture | |
Cisco | Call Admission Control for H.323 VoIP Gateways | |
Sherr et al. | Can they hear me now? A security analysis of law enforcement wiretaps | |
GB2496850A (en) | Modification of session establishment messages to redirect associated media messages. | |
Khan et al. | Information systems audit and control association | |
WO2004051497A1 (en) | Control mechanisms for switching devices | |
Ramadani | Analyzing Implementation of IP Telephony solutions |