BRPI0707583B1 - obscurecimento de identidades temporárias de equipamento de usuário - Google Patents

obscurecimento de identidades temporárias de equipamento de usuário Download PDF

Info

Publication number
BRPI0707583B1
BRPI0707583B1 BRPI0707583A BRPI0707583A BRPI0707583B1 BR PI0707583 B1 BRPI0707583 B1 BR PI0707583B1 BR PI0707583 A BRPI0707583 A BR PI0707583A BR PI0707583 A BRPI0707583 A BR PI0707583A BR PI0707583 B1 BRPI0707583 B1 BR PI0707583B1
Authority
BR
Brazil
Prior art keywords
message
rnti
ues
received
assigned
Prior art date
Application number
BRPI0707583A
Other languages
English (en)
Inventor
Edward Tenny Nathan
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of BRPI0707583A2 publication Critical patent/BRPI0707583A2/pt
Publication of BRPI0707583A8 publication Critical patent/BRPI0707583A8/pt
Publication of BRPI0707583B1 publication Critical patent/BRPI0707583B1/pt

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5038—Address allocation for local use, e.g. in LAN or USB networks, or in a controller area network [CAN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0414—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden during transmission, i.e. party's identity is protected against eavesdropping, e.g. by using temporary identifiers, but is known to the other party or parties involved in the communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • H04W12/75—Temporary identity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Medicines That Contain Protein Lipid Enzymes And Other Medicines (AREA)

Abstract

obscurecimento de identidades tmporárias de equipamento de usuário. são descritas técnicas para ocultar identificadores temporários (ids) atribuidos a equipamentos de usuário (ues) por um sistema de comunicação sem fio. em uma entidade de rede, um primeiro id atribuído a um ue e possivelmente um valor salt são transformados, por exemplo, com base em uma função hash, para obter um segundo id para o ue. uma mensagem de saída dirigida ao ue é gerada com base em uma mensagem de entrada, o segundo id e o valor salt (caso presente). a mensagem de saída é enviada via um canal comum compartilhado pelo ue e outros ues. no ue, uma mensagem é recebida via o canal comum, e um valor salt (caso enviado) é obtida a partir da mensagem recebida. o primeiro id e o valor salt são transformados para obter o segundo id, que é utilizado para determinar se a mensagem recebida é destinada ao ue.

Description

CAMPO DA INVENÇÃO
A presente descrição refere-se, geralmente, à comunicação, e mais especificamente a técnicas para obscurecer identidades em comunicação sem fio.
DESCRIÇÃO DA TÉCNICA ANTERIOR
Redes de comunicação sem fio são amplamente aplicadas para prover vários serviços de comunicação como voz, video, dados em pacote, troca de mensagens, broadcast, etc. Uma rede de comunicação sem fio pode incluir muitos Nós Bs (ou estações base) que podem se comunicar com muitos equipamentos de usuário (UEs). Os UEs podem ser atribuídos a vários identificadores ou identidades (IDs) utilizados para identificar exclusivamente esses UEs para várias finalidades. Em certas ocorrências, os IDs de UE podem ser enviados pelo ar livre sem nenhuma cifragem. tornar possível para um espião (eavesdropper) (attacker) montar um ataque de capacidade ou de monitorar um canal de comunicação para
Isso pode adversário link por mensagens e determinar quais mensagens são dirigidas ao mesmo
UE com o passar do tempo. 0 ataque de capacidade de link pode ser capaz de ligar mensagens a
UEs específicos porém pode não ser capaz de determinar as verdadeiras identidades dos
UEs.
O ataque de capacidade de link pode ser utilizado para rastrear as localizações dos UEs e também pode ser a base de outros ataques de segurança mais severos. Por exemplo, o adversário pode ser capaz de determinar qual ID de UE é atribuído a um UE específico por iniciar uma chamada para aquele UE e observar quais IDs de UE são utilizados aproximadamente ao mesmo tempo.
Há, portanto, necessidade na área por técnicas
para combater ataques de capacidade de link sem impor cargas computacionais excessivas sobre os UEs e entidades de rede.
RESUMO DA INVENÇÃO
Técnicas para ocultar IDs temporários atribuídos aos UEs por uma rede de comunicação sem fio são descritas aqui. Essas técnicas podem ser utilizadas para vários tipos de mensagens endereçadas a UEs específicos e enviadas livre sem cifragem via canais comuns. Essas técnicas podem ser utilizadas para melhorar a segurança, por exemplo, para frustrar ataques de capacidade de link.
Em um aspecto, em uma entidade de rede (por exemplo, um Nó B) , um primeiro ID atribuído a um UE pode ser transformado para obter um segundo ID para o UE. O primeiro ID pode ser um Identificador Temporário de Rede Rádio (RNTI) atribuído ao UE no Sistema de Telecomunicação Móvel Universal (UMTS) ou algum outro tipo de ID em algum outro sistema de comunicação. O primeiro ID e possivelmente um valor salt (que é um valor não-estático) pode ser transformado com base em uma função hash para obter o segundo ID. Uma mensagem de saída dirigida ao UE pode ser gerada com base em uma mensagem de entrada, o segundo ID, e o valor salt (caso presente) . A mensagem de entrada pode ser uma mensagem de paging, uma mensagem de programação que contém informações de programação, uma mensagem de atribuição de recursos, etc. A mensagem de saída pode ser enviada via um canal comum compartilhado pelo UE e outros UEs.
Em outro aspecto, no UE, uma mensagem pode ser recebida via canal comum, e um valor salt (caso enviado) pode ser obtido a partir da mensagem recebida. O primeiro
ID e o valor salt (se enviado) podem ser transformados para
3/26 obter o segundo ID, que pode ser utilizado para determinar se a mensagem recebida é destinada ao UE.
Vários aspectos e características da descrição são descritos em detalhes adicionais abaixo.
BREVE DESCRIÇÃO DAS FIGURAS
A figura 1 mostra uma rede UMTS.
A figura 2 mostra transmissões para Acesso em Pacote Downlink com alta Velocidade (HSDPA).
As figuras 3A e 3B mostram dois desenhos para transformar um RNTI.
A figura 4A mostra um processador que envia um RNTI transformado livre.
A figura 4B mostra um processador que incorpora um RNTI transformado em uma mensagem.
A figura 5 mostra um processo para enviar
mensagens de sinalização para um UE.
A figura 6 mostra um aparelho para enviar
mensagens de sinalização para um UE.
A figura 7 mostra um processo para receber
mensagens de sinalização em um UE.
A figura 8 mostra um aparelho para receber
mensagens de sinalização em um UE.
A figura 9 mostra um diagrama de blocos de um UE, um Nó B e um RNC.
DESCRIÇÃO DETALHADA DA INVENÇÃO
As técnicas descritas aqui podem ser utilizadas
para várias redes de comunicação como redes de Acesso
Múltiplo por Divisão de Código (CDMA), redes de Acesso
Múltiplo por Divisão de Tempo (TDMA), redes de Acesso
Múltiplo por Divisão de Frequência (FDMA), redes FDMA
Ortogonais (OFDMA), redes FDMA de Portadora Única (SC4/26
FDMA), etc. Os termos redes e sistemas são frequentemente utilizados de forma intercambiável. Uma rede CDMA pode implementar uma tecnologia de rádio como Acesso de Rádio Universal Terrestre (UTRA), UTRA evoluído (EUTRA), cdma2000, etc. UTRA e E-UTRA fazem parte de UMTS. UTRA inclui CDMA-de banda larga (W-CDMA) e Taxa de Chip Baixa (LCR). Cdma2000 abrange padrões IS-2000, IS-95 e IS856. Uma rede TDMA pode implementar uma tecnologia de rádio como Sistema Global para Comunicação Móvel (GSM). Uma rede OFDMA pode implementar uma tecnologia de rádio como Evolução de Longa Duração (LTE), IEEE 802.20, Flash-OFDM®, etc. UTRA, E-UTRA, UMTS, GSM e LTE são descritos em documentos a partir de uma organização denominada 3rd Generation Partnership Project (3GPP). Cdma2000 é descrito nos documentos a partir de uma organização denominada 3rd Generation Partnership Project 2 (3GPP2). Essas várias tecnologias de rádio e padrões são conhecidas na técnica. Para clareza, certos aspectos das técnicas são descritas abaixo para UMTS, e terminologia 3GPP é utilizado em grande
parte da descrição abaixo. uma rede UMTS 100 que inclui
A figura 1 mostra
uma Rede de Acesso de Rádio Universal Terrestre (UTRAN) e
uma rede núcleo 140 . A UTRAN inclui múltiplos Nós Bs 110 e
um Controlador de Rede Rádio (RNC) 130. Um Nó B é
geralmente uma estação fixa que se comunica com os UEs e
também pode ser referido como um Nó B intensificado, uma estação base, um ponto de acesso, etc. Cada Nó B 110 provê cobertura de comunicação para uma área geográfica particular e suporta comunicação para os UEs localizados dentro da área de cobertura. O termo célula pode se referir a um Nó B e/ou sua área de cobertura dependendo do contexto no qual o termo é utilizado. RNC 130 acopla-se aos Nós Bs 110 e provê coordenação e controle para esses Nós
5/26
Bs. RNC 130 também origina e termina mensagens para certos protocolos e aplicativos. Rede núcleo 140 pode incluir várias entidades de rede que suportam várias funções como roteamento de pacote, registro de usuário, gerenciamento de mobilidade, etc.
UEs 120 podem ser dispersos por toda a rede UMTS, e cada UE pode ser estacionário ou móvel. Um UE pode ser também referido como uma estação móvel, um terminal, um terminal de acesso, uma unidade de assinante, uma estação, etc. Um
UE pode ser um telefone celular, um assistente digital um dispositivo sem fio, um dispositivo portátil, um modem sem fio, um computador laptop, etc.
Um UE pode se comunicar com um ou mais Nós Bs no downlink e/ou uplink em qualquer dado momento. O downlink (ou link direto) refere-se ao link de comunicação a partir dos Nós
Bs para os UEs, e o uplink (ou link reverso) refere-se a um link de comunicação a partir dos
UEs para os Nós Bs.
Em UMTS, dados e sinalização para os
UEs são processados como canais lógicos em uma camada de
Controle de Radioenlace (RLC). Os canais lógicos incluem um
Canal de
Tráfego Dedicado (DTCH), um Canal Compartilhado de
Downlink (DSCH), um Canal de Controle Dedicado (DCCH), um
Canal de
Controle Comum (CCCH), etc. Os canais lógicos são mapeados para transportar canais em uma camada de Controle de acesso ao Meio (MAC). Os canais de transporte carregam dados para vários serviços como voz, vídeo, dados em pacote, etc. Os canais de transporte são mapeados para canais físicos em uma camada física. Os canais físicos são canalizados com diferentes códigos de canalização e são ortogonais entre si no domínio de código.
Um UE em UMTS pode ser atribuído a uma variedade de IDs utilizados para identificar o UE para várias
6/26 finalidades. Esses IDs de UE podem ter diferentes contextos ou escopos (por exemplo, célula, área de paging, etc.) e/ou diferentes períodos de vida útil (por exemplo, temporário ou permanente) . Por exemplo, o UE pode ser atribuído a vários RNTIs que podem ser utilizados como IDs temporários. Ά tabela 1 lista alguns RNTIs que podem ser atribuídos ao UE e provê uma descrição curta de onde cada RNTI pode ser utilizado. Os C-RNTI e U-RNTI podem ser atribuídos ao UE por um RNC em serviço e pode ser estendido para uma conexão RRC em uma célula particular. O C-RNTI pode ser utilizado para mensagens enviadas no DTCH e DSCH. O U-RNTI pode ser utilizado para mensagens paging enviadas em um Canal de Paging (PCH) e para mensagens enviadas no DCCH. Os DSCHRNTI, H-RNTI e E-RNTI podem ser estendidos para uma célula particular e utilizados para sinalizar mensagens enviadas no DSCH, um Canal Compartilhado de Downlink com alta Velocidade (HS-DSCH) e um Canal de Concessão Absoluta E-DCH (E-AGCH), respectivamente. Esses vários RNTIs podem ser coletivamente referidos como X-RNTIs e podem ser utilizados como IDs temporários em contexto local para endereçar o UE para mensagens de sinalização enviadas por Controle de Recursos de Rádio (RRC) e protocolos MAC. Os XRNTIs podem ser atribuídos por diferentes entidades de rede dentro do UTRAN (ou simplesmente, o UTRAN). Cada X-RNTI pode ser utilizado para sinalizar mensagens permutadas entre a entidade de rede de atribuição e o UE receptor.
Tabela 1
Símbolo Nome Comprimento Uso
C-RNTI Célula RNTI 16 bits Usado para mensagens enviadas em DTCH e DSCH
U-RNTI UTRAN-RNTI 32 bits Usado para mensagens
7/26
paging enviadas em PCH e para mensagens enviadas em DCCH
DSCH-RNTI Identificador de Rede Rádio DSCH 16 bits Usado para sinalizar mensagens enviadas em DSCH
H-RNTI Identificador de Rede Rádio HS-DSCH 16 bits Usado para sinalizar mensagens enviadas em HS-DSCH
E-RNTI Identificador de Rede Rádio E-DCH 16 bits Usado para sinalizar mensagens enviadas em E-AGCH
Os X-RNTIs podem ser atribuídos a um UE em vários tempos pela UTRAN. As atribuições podem ocorrer via sinalização não cifrada devido à ausência de uma relação de segurança preexistente entre a UTRAN e UE no momento de atribuição. Entretanto, na atribuição de uma X-RNTI, a UTRAN endereça tipicamente o UE por uma Identidade de Assinante Móvel Temporário (TMSI) ou uma TMSI de Pacote (PTMSI), que é atribuída ao UE em sinalização cifrada em uma camada de Estrato de Não Acesso (NAS). Desse modo, um adversário pode observar qual X-RNTI foi atribuído por uma mensagem downlink, porém, na ausência de conhecimento adicional da TMSI ou P-TMSI, não seria capaz de determinar qual UE estava recebendo a atribuição.
Após um X-RNTI ser atribuído a um UE, o X-RNTI pode ser enviado livre sem cifragem em sinalização downlink e/ou uplink. Por exemplo, mensagens para UEs específicos podem ser enviadas no CCCH e endereçadas aos UEs receptores por seus U-RNTIs. Essas mensagens podem ser enviadas em radioportador de sinalização 0 (SRBO) e seriam não cifradas uma vez que SRBO pode conter mensagens para UEs que não têm
8/26 ainda uma relação de segurança com a UTRAN. Para mensagens enviadas não cifradas em um canal comum, um adversário pode ser capaz de determinar que uma mensagem foi dirigida para um X-RNTI ou UE específico. Embora o adversário possa não saber a identidade desse UE fora do contexto de rádio, as informações disponíveis podem tornar possível se agregar informações sobre mensagens dirigidas ao mesmo UE em um denominado ataque de capacidade de link. O adversário pode monitorar informações de programação não cifradas enviadas em um canal de controle e pode ser capaz de determinar transmissões de dados endereçadas ao mesmo UE. O adversário pode então rastrear potencialmente a mobilidade de UEs individuais entre células durante uma sessão de dados. Em qualquer caso, mensagens enviadas livres em um canal comum pode resultar em uma vulnerabilidade de segurança que pode levar a ameaças mais graves de segurança.
Técnicas para reduzir vulnerabilidade de segurança devido à transmissão de mensagens livres em um canal comum são descritas aqui. Essas técnicas podem ser utilizadas para várias mensagens de sinalização enviadas em várias camadas. As técnicas podem ser também utilizadas para downlink e uplink. Para clareza, as técnicas são descritas abaixo para transmissão de informações de programação e mensagens paging no downlink em UMTS.
3GPP Release 5 e posteriores suportam HSDPA, que é um conjunto de canais e procedimentos que permitem a transmissão de dados em pacote com alta velocidade no downlink. Para HSDPA, um Nó V envia dados no HS-DSCH, que é um canal de transporte downlink que é compartilhado por todos os UEs tanto em tempo como em código. O HS-DSCH pode conter dados para um ou mais UEs em cada intervalo de tempo de transmissão (TTI) . Para HSDPA, um quadro de 10
9/26 milissegundos (ms) é dividido em cinco subquadros de 2 ms, cada subquadro cobre três partições de tempo, e cada partição de tempo tem uma duração um TTI é igual a um subquadro e é de 0,667 ms. Para HSDPA, a menor unidade de tempo na qual um UE pode ser programado e servido. A partilha do
HS-DSCH é dinâmica e pode alterar de TTI para TTI. Dados para o
HS-DSCH são enviados em um Canal
Compartilhado de
Downlink Físico em Alta
Velocidade (HS-PDSCH), sinalização para o HS-PDSCH é enviada em um Canal de
Controle Compartilhado para HS-DSCH (HS-SCCH).
Para HSDPA, um Nó B pode utilizar até quinze códigos de canalização de 16 chips com fator de espalhamento de 16 para o HS-PDSCH. O nó B pode utilizar também qualquer número de códigos de canalização de 128 chips com fator de espalhamento de 128 para HS-SCCH. O número de códigos de canalização de 16 chips para o HSPDSCH e o número de códigos de canalização de 128 chips para o HS-SCCH são configuráveis. Os códigos de canalização para o HS-PDSCH e HS-SCCH são códigos de fator de espalhamento variável ortogonal (OVSF) que podem ser gerados em um modo estruturado. O fator de espalhamento (SF) é o comprimento de um código de canalização. Um símbolo é espalhado com um código de canalização de comprimento SF para gerar chips SF para o símbolo.
Na descrição a seguir, HSDPA é considerado como tendo (a) até quinze HS-PDSCHs, com cada HS-PDSCH correspondendo a um código de canalização de 16 chips diferentes, e (b) qualquer número de HS-SCCHs, com cada HSSCCH correspondendo a um código de canalização de 128 chips diferentes. Um UE pode ser atribuído até quatro HS-SCCHs na configuração da chamada e pode monitorar os HS-SCCHs atribuídos durante a chamada. O UE pode ser atribuído até quinze HS-PDSCHs em um dado TTI. Os HS-PDSCHs podem ser
10/26 dinamicamente atribuídos e transferidos para o UE via sinalização enviada em um dos HS-SCCHs atribuídos para o UE.
A figura 2 mostra transmissões de exemplo nos HSSCCHs e HS-PDSCHs para HSDPA. Um nó B pode servir um ou mais UEs em cada TTI. O Nó B envia uma mensagem de sinalização para cada UE programado nos HS-SCCHs e envia dados para o UE nos HS-PDSCHs duas partições depois. As mensagens de sinalização enviadas nos HS-SCCHs são endereçadas a UEs específicos com base nos H-RNTIs atribuídos a esses UEs. Cada UE que poderia receber dados nos HS-PDSCHs processa seus HS-SCCHs atribuídos em cada TTI para determinar se uma mensagem de sinalização foi enviada para aquele UE. Cada UE pode casar as mensagens de sinalização recebidas nos HS-SCCHs com seu H-RNTI para determinar se qualquer mensagem de sinalização é destinada àquele UE. Cada UE que é programado em um TTI dado pode processar os HS-PDSCHs para recuperar os dados enviados para aquele UE.
No exemplo mostrado na figura 2, um UE de interesse (UE #1) monitora quatro HS-SCCHs #1 até #4
atribuídos ao UE. UE #1 não é programado em TTI n, e
nenhuma mensagem de sinalização é enviada para UE #1 em
qualquer HS-SCCHs. UE #1 é programado em TTI n + 1 r e uma
mensagem de sinalização é enviada para o UE em HS-SCCH #1. A mensagem de sinalização pode transferir vários parâmetros para a transmissão enviada nesse TTI. UE #1 não é programado em TTI n + 2, é programado em TTI n + 3, e receber uma mensagem de sinalização em HS-SCCH #2, e não é programado em TTI n + 4.
Outros RNTIs podem ser utilizados para outras mensagens de sinalização enviadas para UEs específicos em canais comuns. Por exemplo, mensagens de atribuição
11/26 enviadas no E-AGCH são endereçadas a UEs específicos com base nas E-RNTIs atribuídas a esses UEs. Mensagens de paging são endereçadas a UEs específicos com base nos URNTIs atribuídas a esses UEs.
Em geral, um X-RNTI pode ser enviada em uma mensagem de sinalização transmitida no downlink e pode ser utilizada por cada UE para casar contra seu próprio X-RNTI para determinar se a mensagem de sinalização é destinada àquele UE, isto é, para determinar essa mensagem é para mim? Todas as informações no X-RNTI podem não ser necessárias para esse processo de casamento uma vez que o espaço possível de valores de X-RNTI não possa estar cheio. 0 X-RNTI pode ter 16 bits (ou 32 bits) de comprimento e pode prover identidades para muitos mais UEs do que um Nó B pode ser capaz de endereçar a qualquer momento. Por exemplo, o Nó B pode ter atribuído somente 1024 identidades na faixa de 0 a 1023. Nesse caso, somente 10 bits menos significativos (LSBs) do X-RNTI podem ser utilizados para identificar exclusivamente um dado UE. 0 Nó B pode enviar então valores aleatórios para os bits mais elevados e permitir que cada UE reconheça mensagens dirigidas àquele UE olhando somente os bits inferiores, que contêm a porção real da identidade. 0 envio de valores aleatórios para os bits mais elevados pode resultar em muitos valores de XRNTI diferentes sendo enviados para qualquer UE dado, o que pode mitigar ataque de capacidade de link. Entretanto, esse esquema de truncamento é essencialmente transparente. Um adversário que está ciente do esquema pode penetrar trivialmente no mesmo e examinar os bits inferiores para determinar quais mensagens são endereçadas aos mesmos UEs.
Em um aspecto, um X-RNTI pode ser transformado com base em uma função, e um RNTI transformado (em vez do
X-RNTI original) pode ser enviada em uma mensagem de
12/26 sinalização. Um UE que já conhece o X-RNTI pode ser capaz de determinar se a mensagem de sinalização é destinada ao UE com base no RNTI transformada. Entretanto, um adversário sem conhecimento prévio do X-RNTI pode ser incapaz de determinar a X-RNTI original com base no RNTI transformado enviado na mensagem. A transformação pode ser executada de várias maneiras.
A figura 3A mostra um projeto para transformar um X-RNTI. Uma unidade 310 recebe o X-RNTI, transforma ο XRNTI com base em uma função de transformar H, e provê um RNTI transformado que é indicado como H (X-RNTI). A função de transformar pode ser uma função irreversível que torna difícil determinar o X-RNTI original a partir do RNTI transformado. Por exemplo, a função de transformar pode ser uma função hash segura/criptográfica que mapeia uma mensagem (por exemplo, o X-RNTI) para uma compilação (por exemplo, o RNTI transformado) e tem propriedades criptográficas de modo que (i) a função entre a mensagem e sua compilação é irreversível e (ii) a probabilidade de duas mensagens mapeando para a mesma compilação é muito pequena. A saída da função hash pode ser mencionada como uma compilação, uma assinatura, um valor que sofreu hash, etc.
O RNTI transformado pode ser enviado em uma mensagem de sinalização e pode permitir casamento da mensagem pelas UEs. Cada UE pode aplicar a mesma função de transformar o seu X-RNTI para obter um RNTI transformado. Cada UE pode casar então o RNTI transformado em uma mensagem recebida com o RNTI transformado localmente gerado para determinar se a mensagem é destinada para aquele UE.
RNTI transformado pode evitar que um adversário infira o X-RNTI original. Entretanto, caso o mesmo RNTI transformado seja incluído em cada mensagem de sinalização
13/26 enviada para um dado UE, então o adversário pode realizar um ataque de correlação. Para evitar isso, o RNTI transformado pode ser mudado com cada mensagem.
A figura 3B mostra um projeto para transformar um X-RNTI para obter diferentes RNTIs transformados. Uma unidade 320 recebe o X-RNTI e um valor salt σ, transforma o X-RNTI e o valor salt com base em uma função de transformar Ησ, e provê um RNTI transformado que é indicado como Ησ (X-RNTI) . A função de transformar pode ser uma função irreversível, uma função hash criptográfica, etc. Um valor salt é um valor não estático que pode ser selecionado de qualquer modo. Valores salt diferentes podem ser utilizados para diferentes mensagens de sinalização de modo que um único X-RNTI possa originar RNTIs transformadas diferentes para diferentes mensagens.
Um RNTI transformado e um valor salt σ podem ser enviados em uma mensagem de sinalização e podem permitir casamento da mensagem pelos UEs. O valor salt σ pode ser enviado livre juntamente com o RNTI transformado. O valor salt σ e/ou o RNTI transformado pode ser também incorporado na mensagem de sinalização. Em qualquer caso, cada UE pode casar seu X-RNTI contra o RNTI transformado na mensagem de sinalização. Cada UE pode aplicar a função de transformar Ησ em seu X-RNTI e o valor salt σ extraído a partir da mensagem e pode então comparar o RNTI transformado geralmente localizada com o RNTI transformado recebido na mensagem de sinalização.
A figura 4A mostra um diagrama de blocos de um projeto de um processador de mensagem 410 que envia um RNTI transformado livre em uma mensagem de sinalização.
Processador de mensagem 410 recebe uma mensagem de entrada e um X-RNTI para um UE receptor e gera uma mensagem de
14/26 saída dirigida ao UE.
No processador de mensagem 410, uma unidade 420 recebe um X-RNTI e possivelmente um valor salt σ, aplica uma função de transformar no X-RNTI e possivelmente o valor salt σ, e provê um RNTI transformado. Um mult iplexador (Mux) 422 multiplexa o RNTI transformado, o valor salt σ (caso presente), e uma mensagem de entrada. Um encodificador 424 encodifica a saída de multiplexador 422 e provê uma mensagem de saída. Processador de mensagem 410 pode ser utilizado para mensagens de paging enviadas na PCH. Nesse caso, o ID de UE ou X-RNTI na figura 4A pode corresponder o U-RNTI.
A figura 4B mostra um diagrama de blocos de um projeto de um processador de mensagens 450 que incorpora um RNTI transformado em uma mensagem de sinalização. Processador de mensagens 450 recebe uma mensagem de entrada e um X-RNTI para um UE receptor e gera uma mensagem de saída dirigida ao UE. A mensagem de entrada pode compreender vários trechos de informações.
No processador de mensagens 450, uma unidade 460 recebe um X-RNTI e possivelmente um valor salt σ, aplica uma função transformar no X-RNTI e possivelmente o valor salt σ, recebe e provê um RNTI transformado. Um multiplexador 462 e multiplexa informações de sinalização Xa e Xb e o valor salt σ (caso presente) e provê informações multiplexadas
Xi. Um encodificador
464 encodifica as informações multiplexadas
Xi provê informações codificadas.
Uma unidade
66 mascara as informações codificadas com base no
RNTI transformado e provê informações mascaradas
Si.
Um multiplexador 472 recebe e multiplexa informações de sinalização Xc até Xf e provê informações multiplexadas X2. Uma unidade 474 gera um teste
15/26 de redundância cíclica (CRC) com base em informações Χχ e X2, a seguir mascara o CRC com o RNTI transformado para obter um CRC específico de UE, e anexa o CRC específico de UE às informações X2. Um encodificador 476 encodifica a saída da unidade 474 e provê informações codificadas R2. Um multiplexador 478 recebe e multiplexa as informações mascaradas Si e as informações codificadas R2 e provê as informações multiplexadas Si e R2 como uma mensagem de saída.
Processador de mensagens 450 pode ser utilizado para mensagens de sinalização enviadas no HS-SCCHs. Nesse caso, Xa pode compreender informações de conjunto de código de canalização, Xb pode compreender informações de esquema de modulação, Xc pode compreender informações de tamanho de bloco de transporte, Xd pode compreender informações de processo HARQ, Xe pode compreender informações de versão de constelação e redundância, Xf pode compreender informações de indicador de dados novos, e o X-RNTI pode corresponder ao H-RNTI. Informações Si podem ser enviadas na primeira partição de um TTI, e informações R2 podem ser enviadas nas duas últimas partições do TTI. Nesse caso, o valor salt σ pode ser multiplexado com informações Xa e Xb enviadas na primeira partição do TTI, como mostrado na figura 4B. Isso pode permitir detecção prematura da mensagem de sinalização pelos UEs, sem ter de esperar para que a mensagem inteira seja recebida.
A figura 4A mostra um projeto no qual um RNTI transformado é enviado livre em uma mensagem de sinalização. O RNTI transformado pode ser também enviado livre de outras maneiras. A figura 4B mostra um projeto no qual um RNTI transformado é incorporado em uma mensagem de sinalização. A incorporação do RNTI transformado pode ser também obtida de outras maneiras. Por exemplo, uma mensagem
16/26 de sinalização enviada no E-AGCH pode incluir um CRC específico de UE que pode ser gerado com base em um E-RNTI transformado. Em geral, um RNTI transformado pode ser enviado de várias maneiras (por exemplo, livre ou incorporado) em uma mensagem de sinalização de tal modo que um UE receptor possa identificar a mensagem como sendo dirigida àquele UE.
Como mostrado na figura 2, um UE pode receber múltiplas mensagens de sinalização (por exemplo, até quatro) em cada TTI e pode verificar cada mensagem recebida para determinar se a mensagem é destinada ao UE. A função de transformar deve ser simples de forma computacional de modo que o UE possa aplicar a função de transformar para cada mensagem recebida sem causar impacto adverso sobre o desempenho. De modo ideal, o casamento de mensagem com o RNTI transformado deve exigir somente algumas instruções adicionais além do que é normalmente feito para casar ο XRNTI.
Para o projeto mostrado na figura 3B, um UE pode armazenar uma tabela de consulta de RNTIs transformados obtidas por hashing seu X-RNTI com todos os valores salt possíveis. Os RNTIs transformados podem ser desse modo précomputados uma vez e armazenados para uso posterior, em vez de ser computada sempre que mensagens de sinalização forem recebidas. Para cada mensagem recebida, o UE pode extrair o valor salt a partir da mensagem recebida, recuperar o RNTI transformado para aquele valor salt a partir da tabela de consulta, e verificar a mensagem recebida com o RNTI transformado recuperado.
A UTRAN pode atribuir um novo X-RNTI para um UE via sinalização cifrada no início de uma chamada e possivelmente durante a chamada. Versões transformadas do novo X-RNTI podem ser enviadas através do ar livremente uma
17/26 vez que somente o
UE tem a versão que não sofreu hash. Um adversário pode não ter informações suficientes para executar casamento de mensagens de sinalização enviadas com os RNTIs transformados. O adversário pode monitorar todas as mensagens de sinalização em uma célula durante período de tempo e correlacionar essas mensagens um de sinalização por manter um banco de dados de todos os
XRNTIs possíveis e checar cada mensagem recebida contra todos os X-RNTIs.
Esse tipo de espionagem determinado pode ser combatido por atribuir periodicamente novos
X-RNTIs aos
Várias funções de transformar podem ser utilizadas para gerar RNTIs transformados.
Em geral, uma função de transformar deve ter as seguintes qualidades:
tabela de pequenos;
. Computação fácil e rápida (ou consulta no UE);
sensível a uma
RNTI transformado e valor salt devem ser . Difícil ou impossível de reverter; e . Fácil para o UTRAN proteger contra colisões.
Um equilíbrio pode ser feito entre as qualidades listadas acima para um dado aplicativo. Diferentes funções de transformar com diferentes características podem ser utilizadas para diferentes aplicativos. Por exemplo, sinalização na Camada 2 pode favorecer alta eficiência de bits e rápida decodificação e pode ser capaz de aceitar um nível de segurança mais baixo como resultado. Sinalização na Camada 3 pode favorecer segurança mais forte às custas de maior overhead.
importância de uma função altamente assumido por parte de um adversário.
Uma função de transformar pode simplesmente mascarar alguns bits em irreversível pode depender do nível de determinação
18/26 posições variáveis a partir do X-RNTI e pode utilizar o valor salt para selecionar os bits mascarados. Essa função de transformar pode ser suscetível a um ataque de força bruta no qual o adversário coleta mensagens de sinalização, experimenta todos os valores possíveis para os bits deletados, e observa para ver quais dos valores resultantes são repetidos. 0 adversário pode presumir que os valores repetidos são os X-RNTIs reais de vários UEs e pode armazenar esses valores para teste contra futuras mensagens de sinalização. Entretanto, isso pode representar um ataque significativamente mais laborioso do que a espionagem casual normalmente associado a ataques de capacidade de link.
Mesmo se uma função de transformar for de um certo modo fraca de modo criptográfico, o UTRAN pode atribuir novos X-RNTIs via sinalização cifrada. Nesse caso, um adversário pode não ter automaticamente um grupo de XRNTIs conhecidos para testar mensagens recebidas contra. À luz da capacidade de atribuir novos X-RNTIs, a intensidade criptográfica da função de transformar pode ser considerada menos importante do que a computação simples e conservação de bit através do ar.
Uma função de transformar pode ser definida com base em vários projetos. Por exemplo, uma função de transformar pode incorporar princípios de projeto utilizados em funções hash seguras/criptográficas como SHA1 (Algoritmo Hash seguro), SHA-2 (que inclui SHA-224, SHA256, SHA-384 e SHA-512), MD-4 (Compilação de mensagens), MD-5, ou outros algoritmos hash seguros conhecidos na técnica. Em um projeto, uma função de transformar única é utilizada e conhecida a priori tanto pela UTRAN como pelos UEs. Em outro projeto, um conjunto de funções de transformar é suportado, e uma função de transformar pode
19/26 ser selecionada a partir do conjunto, por exemplo, no início de uma chamada, e transferido para um UE.
O comprimento do valor salt σ pode ser selecionado com base em um equilíbrio entre overhead e segurança. Um valor salt mais longo pode resultar em mais RNTIs transformados para um dado X-RNTI, que pode melhorar a segurança às custas de overhead maior e possivelmente maior probabilidade de colisão. O inverso pode ser verdadeiro para um valor salt mais curto.
Em um projeto, um RNTI transformado tem o comprimento igual ou aproximadamente igual ao do X-RNTI original. Para esse projeto, o valor salt σ pode ser enviado utilizando bits adicionais. Em outro projeto, o RNTI transformado e o valor salt σ têm comprimento igual ou aproximadamente igual ao do X-RNTI original para manter overhead igual ou aproximadamente igual. Para esse projeto, alguns bits podem ser recuperados fazendo o RNTI transformado mais curto do que o X-RNTI original. Por exemplo, o X-RNTI pode ser 16 bits, o RNTI transformado pode ser 10 bits, e o valor salt pode ser 6 bits. O X-RNTI, RNTI transformado, e valor salt podem ter também outros comprimentos. A função de transformar pode ser projetada para obter as propriedades criptográficas desejadas com o RNTI transformado mais curto.
Uma colisão ocorre quando dois X-RNTIs para dois UEs são transformados no mesmo RNTI transformado, por exemplo, Ha(x)-Ha(y}, onde x e y são as dois X-RNTIs. Os dois UEs podem não ter modo para resolver a colisão entre seus RNTIs transformados. O RNTI transformado pode ser utilizado para enviar informações de programação para um dos dois UEs, por exemplo, como mostrado na figura 2. O UE receptor pode detectar adequadamente as informações de
20/26 programação como sendo para aquele UE e pode decodificar os dados enviados para o UE. O UE não-receptor pode detectar falsamente as informações de programação, decodificar os dados destinados para o UE receptor, e obter resultado sem sentido após descriptografia (considerando que os dados enviados no HS-DSCH foram criptografados). Nesse caso, colisões podem ou não causar impacto adverso sobre o desempenho, dependendo do comportamento da aplicação.
Em geral, o impacto devido a colisões de X-RNTIs pode ser dependente do tipo de sinalização sendo enviada com esses X-RNTIs. 0 UTRAN pode tentar evitar colisões para evitar possíveis efeitos adversos.
Em um projeto para evitar colisões, o UTRAN seleciona X-RNTIs e valores salt conhecidos como não tendo colisões. A UTRAN pode manter um conjunto de todos os XRNTIs atribuídos ou atribuíveis aos UEs. Para cada valor salt possível σ, o UTRAN pode gerar um conjunto de RNTIs transformados com base no conjunto de X-RNTIs e aquele valor salt. 0 UTRAN pode varrer o conjunto transformado para duplicatas e pode rejeitar esse valor salt caso duplicatas sejam detectadas. Em geral, um valor salt que causa uma colisão para certos X-RNTIs pode ser ainda utilizado para outros X-RNTIs. Entretanto, para simplificar implementação, a UTRAN pode manter uma lista de valores salt que resultam em nenhuma duplicata sobre todo o conjunto de X-RNTIs. Os valores salt nessa lista podem ser selecionados para uso. Colisões também podem ser evitadas de outras maneiras.
A figura 5 mostra um processo 500 realizado por uma entidade de rede em uma rede de comunicação sem fio para enviar mensagens de sinalização para os UEs. A entidade de rede pode ser um Nó B, um RNC, etc., dependendo das mensagens de sinalização sendo enviadas.
21/26
Um primeiro ID atribuído a um UE pode ser transformado para obter um segundo ID para o UE (bloco 512) . O primeiro ID pode ser um RNTI atribuído ao UE em UMTS ou algum outro tipo de ID em algum outro sistema de comunicação. O primeiro ID pode ser transformado com base em uma função irreversível, uma função hash, ou alguma outra função para obter o segundo ID. Uma mensagem de saída dirigida ao
UE pode ser gerada com base em uma mensagem de entrada e o segundo ID (bloco
514). A mensagem de entrada pode ser uma mensagem de paging, uma mensagem de programação carregando informações de programação, uma mensagem de atribuição de recursos, etc. A mensagem de saída pode ser enviada através de um canal comum compartilhado pelo UE e outros UEs (bloco
516) .
Em um projeto, o primeiro ID e um valor salt sofreram hash para obter o segundo ID.
valor salt pode ser enviado livre na mensagem de saída.
O valor salt pode ser alterado cada vez que o primeiro ID é transformado e pode ser selecionado para evitar colisões entre todos os primeiros IDs atribuídos aos UEs. 0 primeiro ID pode ter um comprimento que pode ser igual ao comprimento combinado do segundo ID e o valor salt.
Em um projeto, a mensagem de saída pode incluir a mensagem de entrada e o segundo ID livre, por exemplo, como mostrado na figura 4A. Em outro projeto, o segundo ID pode ser incorporado na mensagem de saída, por exemplo, como mostrado na figura 4B. Por exemplo, toda ou uma porção da mensagem de entrada pode ser mascarada com o segundo ID para gerar a mensagem de saída. Alternativamente, um CRC específico de UE pode ser gerado com base na mensagem de entrada e o segundo ID, e a mensagem de saída pode ser gerada com base na mensagem de entrada e o CRC específico de UE.
22/26
Ά figura β mostra um aparelho 600 para enviar mensagens de sinalização para os UEs. Aparelho 600 inclui elemento para transformar um primeiro ID atribuído a um UE para obter um segundo ID para o UE (módulo 612), elemento para gerar uma mensagem de saída dirigida ao UE com base em uma mensagem de entrada e o segundo ID (módulo 614), e elemento para enviar a mensagem de saída via um canal comum compartilhado pelo UE e outros UEs (módulo 616). Os módulos 612 a 616 podem compreender processadores, dispositivos eletrônicos, dispositivos de hardware, componentes eletrônicos, circuitos lógicos, memórias, etc., ou qualquer combinação dos mesmos.
A figura 7 mostra um processo 700 realizado por um UE para receber mensagens de sinalização a partir de uma rede de comunicação sem fio. Uma mensagem pode ser recebida via um canal comum compartilhado por uma pluralidade de UEs (bloco 712) . Um primeiro ID atribuído ao UE pode ser transformado para obter um segundo ID para o UE (bloco 714). A transformação pode ser alcançada com uma tabela de consulta, hardware, software, firmware, etc. Em um projeto, um valor salt pode ser obtido a partir da mensagem recebida, e o primeiro ID e o valor salt podem sofrer hash para obter o segundo ID. O fato de se a mensagem recebida é destinada para o UE pode ser determinado com base no segundo ID (bloco 716) . Em um projeto de bloco 716, um terceiro ID pode ser obtido a partir da mensagem recebida e comparado com o segundo ID para determinar se a mensagem recebida é destinada ao UE. Em outro projeto de bloco 716, um CRC pode ser gerado com base na mensagem recebida e o segundo ID, um CRC específico de UE pode ser obtido a partir da mensagem recebida, e o CRC gerado pode ser comparado com o CRC específico de UE para determinar se a mensagem recebida é destinada ao UE. A mensagem recebida
23/26 pode ser uma mensagem de paging, uma mensagem de programação, uma mensagem de atribuição de recursos, etc. Caso a mensagem recebida seja uma mensagem de programação, então informações de programação podem ser obtidas a partir da mensagem recebida e utilizadas para processar uma transmissão de dados enviada para o UE.
A figura 8 mostra um aparelho 800 para receber mensagens de sinalização. Aparelho 800 inclui elemento para receber uma mensagem via um canal comum compartilhado por uma pluralidade de UEs (módulo 812), elemento para transformar um primeiro ID atribuído a um UE para obter um segundo ID para o UE (módulo 814), e elemento para determinar se a mensagem recebida é destinada para o UE com base no segundo ID (módulo 816) . Módulos 812 a 816 podem compreender processadores, dispositivos eletrônicos, dispositivos de hardware, componentes eletrônicos, circuitos lógicos, memórias, etc., ou qualquer combinação dos mesmos.
A figura 9 mostra um diagrama de blocos de um projeto de UE 120, Nó B 110, e RNC 130 na figura 1. No uplink, dados e sinalização a serem enviados por UE 120 são processados (por exemplo, formatados, encodifiçados e por um encodificador 922 e adicionalmente processados (por exemplo, modulados, canalizados e embaralhados) por um modulador (MOD) 924 para gerar chips de saída. Um transmissor (TMTR) 932 então condiciona (por exemplo, converte em analógico, filtra, amplifica, e converte ascendentemente em frequência) os chips de saída e gera um sinal uplink, que é transmitido via uma antena 934. No downlink, a antena 934 recebe um sinal downlink transmitido por Nó B 110. Um receptor (RCVR) 936 condiciona (Por exemplo, filtra, amplifica, converte descendentemente em frequência e digitaliza) o sinal recebido a partir da
antena 934 e provê amostras. Um demodulador (DEMOD) 926 processa (por exemplo, desembaralha, canaliza e demodula) as amostras e provê estimativas de símbolos. Um decodificador
928 processa adicionalmente (por exemplo, desintercala decodifica) as estimativas de símbolos e provê dados decodificados.
Encodificador
922, modulador
924, demodulador 926, e decodificador
928 podem ser implementados por um processador de modem 920. Essas unidades podem realizar processamento de acordo com a tecnologia de rádio (por exemplo, UMTS) implementada pela rede de comunicação sem fio.
Um controlador/processador 940 orienta a operação no UE 120. Controlador/processador 940 pode realizar o processo 700 na figura 7 e/ou outros processos para as técnicas descritas aqui. Uma memória 942 armazena códigos de programa e dados para UE 120 e também pode armazenar IDs temporários atribuídos ao UE 120, ou IDs de UE.
A figura 9 também mostra um projeto de Nó B 110 e RNC 130. Nó B 110 inclui um controlador/processador 950 que realiza várias funções para comunicação com os UEs, uma memória 952 que armazena códigos de programa e dados para Nó B 110, e um transceptor 954 que suporta comunicação de rádio com os UEs. Controlador/processador 950 pode realizar o processo 500 na figura 5 e/ou outros processos para as técnicas descritas aqui. Memória 952 pode armazenar IDs temporários atribuídos aos UEs por Nó B 110, ou NB UE IDs. RNC 130 inclui um controlador/processador 960 que realiza várias funções para suportar comunicação para os UEs e uma atribuídos aos UEs servidos pelo RNC 130, ou RNC UE IDs.
memória 962 que armazena códigos de programa e dados para
RNC 130. Controlador/processador 960 pode realizar processo
500 na figura 5 e/ou outros processos para as técnicas descritas aqui. Memória 962 pode armazenar IDs temporários
25/26
As técnicas descritas aqui podem ser utilizadas para mensagens de sinalização enviadas no downlink bem como no uplink. As técnicas também podem ser utilizadas para mensagens enviadas via um plano de controle bem como um plano de usuário. Um plano de controle é um mecanismo para portar sinalização para aplicativos de camada mais alta tipicamente implementado com protocolos específicos de rede, interfaces e mensagens de sinalização. Um plano de usuário é um mecanismo que porta sinalização para aplicativos de camada mais alta tipicamente implementado com protocolos abertos como
Protocolo de
Datagrama de
Usuário (UDP),
Protocolo de
Controle de
Transmissão (TCP), e Protocolo de Internet (IP). Mensagens podem ser portadas como parte de sinalização em um plano de controle como parte de dados (a partir de uma perspectiva de rede) em um plano de usuário.
As técnicas descritas aqui podem ser implementadas por vários elementos. Por exemplo, essas técnicas podem ser implementadas em hardware, firmware, software ou uma combinação dos mesmos.
Para uma implementação de hardware, as unidades de processamento utilizadas para realizar as técnicas em uma dada entidade (por exemplo, um UE, um Nó B, um RNC, etc.) podem ser implementadas dentro de um ou mais circuitos integrados específicos de aplicação (ASICs), processadores de sinal digital (DSPs), dispositivos de processamento de sinal digital (DSPDs), dispositivos de lógica programável (PLDs), arranjos de porta programável em campo (FPGAs), processadores, controladores, microcontroladores, microprocessadores, dispositivos eletrônicos, outras unidades eletrônicas projetadas para realizar as funções descritas aqui, um computador, ou uma combinação dos mesmos.
26/26
Para uma implementação de firmware e/ou software, as técnicas podem ser implementadas com módulos (por exemplo, procedimentos, funções, etc.) que realizam as funções descritas aqui. Os códigos de firmware e/ou 5 software podem ser armazenados em uma memória (por exemplo, memória 942, 952 ou 962 na figura 9) e executados por um processador (por exemplo, processador 940, 950 ou 960). A memória pode ser implementada dentro do processador ou externamente ao processador.
A descrição anterior da revelação é provida para permitir que qualquer pessoa versada na técnica faça ou utilize a descrição. Várias modificações na descrição serão prontamente evidentes para aqueles versados na técnica, e os princípios gerais definidos acima podem ser aplicados a 15 outras variações sem se afastar do espírito ou escopo da descrição. Desse modo, a descrição não pretende ser limitada aos exemplos descritos aqui, porém deve estar de acordo com o escopo mais amplo compatível com os princípios e características novas aqui revelados.

Claims (11)

  1. REIVINDICAÇÕES
    1. Entidade de rede (110) para enviar mensagens de sinalização para equipamentos de usuário (120), caracterizada pelo fato de que compreende:
    meios para transformar um primeiro identificador, ID, atribuído a um equipamento de usuário (120), UE, para obter um segundo ID para o UE (120), em que os meios para transformar o primeiro ID compreendem meios para efetuar hash no primeiro ID e em um valor salt para obter o segundo id;
    meios para gerar uma mensagem de saída dirigida ao UE (120) com base em uma mensagem de entrada, no segundo ID, e no valor salt; e meios para enviar a mensagem de saída via um canal comum compartilhado pelo UE e outros UEs.
  2. 2. Entidade de rede (110), de acordo com a reivindicação 1, caracterizada pelo fato de que os meios para gerar a mensagem de saída compreendem meios para gerar a mensagem de saída para incluir a mensagem de entrada e o segundo ID livre.
  3. 3. Entidade de rede (110), de acordo com a reivindicação 1, caracterizada pelo fato de que os meios para gerar a mensagem de saída compreendem:
    meios para gerar um teste de redundância cíclica, CRC, específico de UE com base na mensagem de entrada e no segundo ID, e meios para gerar a mensagem de saída com base na mensagem de entrada e no CRC específico de UE.
  4. 4. Entidade de rede (110), de acordo com a reivindicação 1, caracterizada pelo fato de que os meios são incorporados como:
    um processador (950) configurado para transformar o primeiro identificador, ID, atribuído a um equipamento de
    Petição 870190048881, de 24/05/2019, pág. 6/10
    2/4 usuário (120), UE, para obter o segundo ID para o UE (120), gerar a mensagem de saída dirigida ao UE com base na mensagem de entrada e o segundo ID, e enviar a mensagem de
    saída via o canal comum compartilhado pelo UE (120) e 5 outros UEs; e uma memória (952) acoplada ao processador (950) . 5. Entidade de rede (110), de acordo com a reivindicação 4, caracterizada pelo fato de que o
    processador (950) é configurado para transformar o primeiro
    10 ID com base em uma função irreversível para obter o segundo
    ID.
    6. Método, caracterizado pelo fato de que compreende: transformar, na entidade de rede, um primeiro 15 identificador, ID, atribuído a um equipamento de usuário,
    UE, para obter um segundo ID para o UE, em que transformar o primeiro ID compreende meios para efetuar hash no primeiro ID e em um valor salt para obter o segundo ID;
    gerar, na entidade de rede, uma mensagem de saída
    20 dirigida para o UE com base em uma mensagem de entrada, no segundo ID, e no valor salt; e enviar, na entidade de rede, a mensagem de saída via um canal comum compartilhado pelo UE e outros UEs.
  5. 7. Meio legível por computador, caracterizado
    25 pelo fato de que compreende instruções armazenadas no mesmo, as instruções sendo executadas por um computador para realizar o método conforme definido na reivindicação 6.
  6. 8. Equipamento de usuário (1200 para receber
    30 mensagens de sinalização, caracterizado pelo fato de que compreende:
    meios para receber uma mensagem via um canal comum compartilhado por uma pluralidade de equipamentos de
    Petição 870190048881, de 24/05/2019, pág. 7/10
    3/4 usuário (120), UEs;
    meios para transformar um primeiro identificador, ID, atribuído a um UE (120) para obter um segundo ID para o UE (120), em que os meios para transformar o primeiro ID compreendem:
    meios para obter um valor salt a partir da mensagem recebida, e meios para efetuar hash no primeiro ID e no valor salt para obter o segundo ID; e meios para determinar se a mensagem recebida é destinada ao UE (120) com base no segundo ID.
  7. 9. Equipamento de usuário (120), de acordo com a reivindicação 8, caracterizado pelo fato de que os meios para determinação de se a mensagem recebida é destinada ao UE (120) compreendem:
    meios para obter um terceiro ID a partir da mensagem recebida, e meios para comparar o segundo ID com o terceiro ID para determinar se a mensagem recebida é destinada ao UE (120).
  8. 10. Equipamento de usuário (120), de acordo com a reivindicação 8, caracterizado pelo fato de que os meios para determinação de se a mensagem recebida é destinada ao UE (120) compreendem:
    meios para gerar um teste de redundância cíclica, CRC, com base na mensagem recebida e no segundo ID, meios para obter um CRC específico de UE a partir da mensagem recebida, e meios para comparar o CRC gerado com o CRC específico de UE (120) para determinar se a mensagem recebida é destinada ao UE.
  9. 11. Equipamento de usuário (120), de acordo com a reivindicação 8, caracterizado pelo fato de que os meios
    Petição 870190048881, de 24/05/2019, pág. 8/10
    4/4 são incorporados como:
    um processador (940) configurado para receber a mensagem via do canal comum compartilhado pela pluralidade de equipamentos de usuário (120), UEs, transformar o primeiro identificador, ID, atribuído ao UE (120) para obter o segundo ID para o UE (120), e determinar se a mensagem recebida é destinada ao UE (120) com base no segundo ID; e uma memória (942) acoplada ao processador (940).
  10. 12. Método, caracterizado pelo fato de que compreende:
    receber, em um equipamento de usuário (120), uma mensagem via um canal comum compartilhado por uma pluralidade de equipamentos de usuário (120), UEs;
    transformar, em um equipamento de usuário (120), um primeiro identificador, ID, atribuído a um UE para obter um segundo ID para o UE (120), em que transformar o primeiro ID compreende:
    meios para obter um valor salt a partir da mensagem recebida, e meios para efetuar hash no primeiro ID e no valor salt para obter o segundo ID; e determinar, em um equipamento de usuário (120), se a mensagem recebida é destinada ao UE (120) com base no segundo ID.
  11. 13. Meio legível por computador, caracterizado pelo fato de que compreende instruções armazenadas no mesmo, as instruções sendo executadas por um computador para realizar o método conforme definido na reivindicação 12.
BRPI0707583A 2006-02-10 2007-02-09 obscurecimento de identidades temporárias de equipamento de usuário BRPI0707583B1 (pt)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US77197406P 2006-02-10 2006-02-10
US60/771,974 2006-02-10
US78646306P 2006-03-27 2006-03-27
US60/786,463 2006-03-27
PCT/US2007/061939 WO2007095471A2 (en) 2006-02-10 2007-02-09 Obscuring temporary user equipment identities

Publications (3)

Publication Number Publication Date
BRPI0707583A2 BRPI0707583A2 (pt) 2011-05-10
BRPI0707583A8 BRPI0707583A8 (pt) 2019-01-08
BRPI0707583B1 true BRPI0707583B1 (pt) 2019-08-13

Family

ID=38197847

Family Applications (2)

Application Number Title Priority Date Filing Date
BRPI0707583A BRPI0707583B1 (pt) 2006-02-10 2007-02-09 obscurecimento de identidades temporárias de equipamento de usuário
BRPI0707581-2A BRPI0707581A2 (pt) 2006-02-10 2007-02-09 sinalizaÇço com identidades de equipamento de usuÁrio opacas

Family Applications After (1)

Application Number Title Priority Date Filing Date
BRPI0707581-2A BRPI0707581A2 (pt) 2006-02-10 2007-02-09 sinalizaÇço com identidades de equipamento de usuÁrio opacas

Country Status (13)

Country Link
US (2) US8195943B2 (pt)
EP (3) EP1992188B1 (pt)
JP (2) JP4927877B2 (pt)
KR (2) KR101041241B1 (pt)
CN (1) CN104768145A (pt)
AR (1) AR059568A1 (pt)
AT (1) ATE543318T1 (pt)
BR (2) BRPI0707583B1 (pt)
CA (2) CA2636309C (pt)
ES (1) ES2392854T3 (pt)
RU (2) RU2427103C2 (pt)
TW (2) TWI340582B (pt)
WO (2) WO2007095473A1 (pt)

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4892884B2 (ja) * 2005-08-01 2012-03-07 日本電気株式会社 無線ｌａｎ内蔵型携帯電話端末、携帯電話システムおよびその個人情報保護方法
BRPI0707583B1 (pt) * 2006-02-10 2019-08-13 Qualcomm Inc obscurecimento de identidades temporárias de equipamento de usuário
MY187397A (en) 2006-04-28 2021-09-22 Qualcomm Inc Method and apparatus for enhanced paging
US8682357B2 (en) 2006-05-02 2014-03-25 Intellectual Ventures Holding 81 Llc Paging in a wireless network
US8156332B2 (en) * 2007-05-29 2012-04-10 Apple Inc. Peer-to-peer security authentication protocol
JP4787792B2 (ja) * 2007-06-18 2011-10-05 株式会社エヌ・ティ・ティ・ドコモ 無線制御装置、無線通信システム、通信路設定方法
KR101548026B1 (ko) 2007-09-11 2015-08-27 와이-랜, 인코포레이티드 지속 자원 할당
CN101426253B (zh) 2007-10-31 2013-08-07 华为技术有限公司 一种实现信息传输的方法、装置及系统
CN101426254B (zh) 2007-10-31 2010-12-08 华为技术有限公司 一种实现信息传输的方法、装置及系统
AU2008341208B2 (en) 2007-12-21 2013-07-18 Telefonaktiebolaget L M Ericsson (Publ) Methods and arrangements in a mobile telecommunications network
EP2757846B1 (en) 2008-04-24 2016-03-09 Huawei Technologies Co., Ltd. Mobile station device, mobile communication system, and communication method
US8514818B2 (en) * 2008-04-25 2013-08-20 Nokia Corporation System and methods for generating masking sequences
CN102197664B (zh) * 2008-11-07 2014-07-16 艾利森电话股份有限公司 在用户设备中触发基于位置的事件的方法
US20100235689A1 (en) * 2009-03-16 2010-09-16 Qualcomm Incorporated Apparatus and method for employing codes for telecommunications
US8711751B2 (en) * 2009-09-25 2014-04-29 Apple Inc. Methods and apparatus for dynamic identification (ID) assignment in wireless networks
DE102009058446B4 (de) * 2009-12-16 2011-11-10 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Verfahren zur Anonymisierung von Verbindungsdaten in IP Paketen und Vorrichtung zur Durchführung des Verfahrens
WO2011134529A1 (en) * 2010-04-30 2011-11-03 Nokia Siemens Networks Oy Method of assigning a unique identifier to a mobile station in a communications network
US20120011229A1 (en) * 2010-06-04 2012-01-12 Peter Heller Enhanced network/domain name hashing techniques
US20120039185A1 (en) * 2010-08-12 2012-02-16 Futurewei Technologies, Inc. System and Method for Providing Security in a Wireless Communications System
WO2013102489A1 (en) * 2012-01-03 2013-07-11 Telefonaktiebolaget L M Ericsson (Publ) A radio communication system for assigning a short-lived c-rnti
US8885517B2 (en) * 2012-02-16 2014-11-11 Giri Prassad Deivasigamani Operational state mismatch identification for a mobile device
US20140036861A1 (en) * 2012-08-03 2014-02-06 Institute For Information Industry High-power base station and low-power base station for use in hererogeneous network and transmission methods thereof
US9386619B2 (en) 2013-02-22 2016-07-05 Htc Corporation Method of handling a cell addition for dual connectivity and related communication device
US9357438B2 (en) 2013-02-22 2016-05-31 Htc Corporation Method for simultaneous communications with multiple base stations and related communication device
US10390333B2 (en) * 2013-05-02 2019-08-20 Huawei Technologies Co., Ltd. System and method for transmission source identification
EP3193558B1 (en) 2013-08-09 2018-06-20 HTC Corporation Method, device and network for radio network temporary identifier allocation in dual connectivity
CN105850144B (zh) * 2013-11-04 2019-03-01 耐瑞唯信有限公司 用于标记数字音频或音频和/或视频内容的装置和方法
CN108476445B (zh) 2015-12-31 2021-10-15 华为技术有限公司 移动性管理的方法、用户设备和基站
US11659563B2 (en) * 2017-01-04 2023-05-23 Huawei Technologies Co., Ltd. System and method for user equipment identifier configuration
US10361839B2 (en) * 2017-01-06 2019-07-23 Blackberry Limited Encryption in wireless communication systems
US10277252B2 (en) 2017-01-09 2019-04-30 At&T Intellectual Property I, L.P. Encoding data with polar codes for control channels
JP7124679B2 (ja) 2018-12-07 2022-08-24 トヨタ自動車株式会社 監視装置
FI129763B (en) * 2020-03-04 2022-08-15 Wirepas Oy Addressing system for a wireless data communications network
US11381391B2 (en) * 2020-06-15 2022-07-05 Cisco Technology, Inc. Pre-shared secret key capabilities in secure MAC layer communication protocols

Family Cites Families (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06337153A (ja) 1993-05-28 1994-12-06 Toshiba Corp 空気調和機
TW243553B (en) 1994-03-21 1995-03-21 United Microelectronics Corp Coding method for mask read only memory
JP3271460B2 (ja) * 1995-01-12 2002-04-02 ケイディーディーアイ株式会社 無線通信における識別子秘匿方法
AU1732497A (en) 1996-02-21 1997-09-10 Card Call Service Co., Ltd. Communication method using common key
US6510461B1 (en) * 1997-06-30 2003-01-21 Sun Microsystems, Inc. System for managing and automatically deleting network address identified and stored during a network communication session when the network address is visited
CA2276872A1 (en) 1998-08-28 2000-02-28 Lucent Technologies Inc. Method for protecting mobile anonymity
US6463154B1 (en) 1998-08-28 2002-10-08 Lucent Technologies Inc. Method for determining temporary mobile identifiers and managing use thereof
US6256301B1 (en) * 1998-10-15 2001-07-03 Qualcomm Incorporated Reservation multiple access
EP1129594A1 (en) 1998-11-12 2001-09-05 Telefonaktiebolaget L M Ericsson (Publ) System and method for secured transference of temporary mobile subscriber information
FI114077B (fi) 1999-03-10 2004-07-30 Nokia Corp Tunnuksen varausmenetelmä
US6763112B1 (en) * 1999-09-28 2004-07-13 Nokia Networks Oy Security procedure in universal mobile telephone service
US7240202B1 (en) 2000-03-16 2007-07-03 Novell, Inc. Security context sharing
CN1392987A (zh) * 2000-09-14 2003-01-22 皇家菲利浦电子有限公司 用于存储数据项的方法和系统
WO2002041601A2 (en) 2000-11-16 2002-05-23 Telefonaktiebolaget Lm Ericsson (Publ) User authentication apparatus, controlling method thereof, and network system
US7046992B2 (en) 2001-05-11 2006-05-16 Telefonaktiebolaget Lm Ericsson (Publ) Authentication of termination messages in telecommunications system
US20030172114A1 (en) 2001-10-24 2003-09-11 Leung Nikolai K. N. Method and apparatus for data packet transport in a wireless communication system using an internet protocol
US7363494B2 (en) * 2001-12-04 2008-04-22 Rsa Security Inc. Method and apparatus for performing enhanced time-based authentication
US7515713B2 (en) * 2001-12-17 2009-04-07 Qualcomm Incorporated Secure generation of temporary mobile station identifiers
US6856604B2 (en) * 2001-12-19 2005-02-15 Qualcomm Incorporated Efficient multi-cast broadcasting for packet data systems
US20060034456A1 (en) 2002-02-01 2006-02-16 Secure Choice Llc Method and system for performing perfectly secure key exchange and authenticated messaging
KR100765123B1 (ko) 2002-02-16 2007-10-11 엘지전자 주식회사 Ｓｒｎｓ 재할당 방법
US7508804B2 (en) * 2002-04-05 2009-03-24 Alcatel-Lucent Usa Inc. Shared signaling for multiple user equipment
RU2292648C2 (ru) 2002-05-01 2007-01-27 Телефонактиеболагет Лм Эрикссон (Пабл) Система, устройство и способ, предназначенные для аутентификации на основе sim и для шифрования при доступе к беспроводной локальной сети
MXPA04011582A (es) 2002-05-22 2005-03-07 Interdigital Tech Corp Unidad movil que tiene funcionalidad de protocolo de internet.
KR100878764B1 (ko) * 2002-07-06 2009-01-14 삼성전자주식회사 사용자의 익명성보장을 위한 무선 랜 시스템 및 사용자의익명성 보장방법
US6757722B2 (en) 2002-07-16 2004-06-29 Nokia Corporation System and method for providing partial presence notifications
KR100893070B1 (ko) 2002-09-19 2009-04-17 엘지전자 주식회사 무선통신 시스템의 멀티캐스트 서비스 제공 및 수신 방법, 그리고 그 장치
EP1401226A1 (en) * 2002-09-20 2004-03-24 Lucent Technologies Inc. A method, and apparatus, for addressing a message to mobile user terminals
RU2253948C1 (ru) 2003-09-02 2005-06-10 Войсковая часть 45807 Способ передачи сообщений с обеспечением конфиденциальности идентификационных признаков взаимодействующих объектов в сети связи
US7424467B2 (en) 2004-01-26 2008-09-09 International Business Machines Corporation Architecture for an indexer with fixed width sort and variable width sort
JP3890398B2 (ja) 2004-02-19 2007-03-07 海 西田 ピアツーピア型匿名プロキシにおける安全性の高い匿名通信路の検証及び構築する方法
US20050243769A1 (en) 2004-04-28 2005-11-03 Walker Jesse R Apparatus and method capable of pre-keying associations in a wireless local area network
FI20040841A0 (fi) 2004-06-17 2004-06-17 Nokia Corp Menetelmä tietoliikenteen valvomiseksi käyttäen verkkonoodiryhmää kommunikaatiojärjestelmässä
JP2006011989A (ja) 2004-06-28 2006-01-12 Ntt Docomo Inc 認証方法、端末装置、中継装置及び認証サーバ
EP1792436A1 (en) 2004-09-10 2007-06-06 Koninklijke Philips Electronics N.V. Method of providing conditional access
JP4598494B2 (ja) 2004-11-26 2010-12-15 富士通株式会社 利用者仮識別子を用いるネットワークサービスシステム
GB2423220B (en) * 2005-02-11 2009-10-07 Ericsson Telefon Ab L M Method and apparatus for ensuring privacy in communications between parties
US20060248079A1 (en) 2005-04-28 2006-11-02 Freescale Semiconductor Incorporated Method and apparatus for finding a perfect hash function and making minimal hash table for a given set of keys
US20070047478A1 (en) * 2005-08-30 2007-03-01 Lucent Technologies Inc. Method for access assurance in a wireless communication system
US7827398B2 (en) 2005-10-27 2010-11-02 Hewlett-Packard Company Method for offloading encryption and decryption of a message received at a message server to remote end devices
US8848912B2 (en) 2005-12-19 2014-09-30 Nippon Telegraph And Telephone Corporation Terminal identification method, authentication method, authentication system, server, terminal, wireless base station, program, and recording medium
US8788807B2 (en) * 2006-01-13 2014-07-22 Qualcomm Incorporated Privacy protection in communication systems
BRPI0707583B1 (pt) 2006-02-10 2019-08-13 Qualcomm Inc obscurecimento de identidades temporárias de equipamento de usuário
US8295243B2 (en) 2006-08-21 2012-10-23 Qualcomm Incorporated Method and apparatus for random access in an orthogonal multiple-access communication system

Also Published As

Publication number Publication date
TW200746774A (en) 2007-12-16
EP1992188B1 (en) 2012-09-19
EP2437460B1 (en) 2013-10-23
KR101041241B1 (ko) 2011-06-14
CA2636270C (en) 2013-04-30
US9154464B2 (en) 2015-10-06
WO2007095471A2 (en) 2007-08-23
KR101038158B1 (ko) 2011-05-31
BRPI0707583A2 (pt) 2011-05-10
TWI340582B (en) 2011-04-11
BRPI0707583A8 (pt) 2019-01-08
AR059568A1 (es) 2008-04-16
CA2636309C (en) 2013-09-17
CA2636309A1 (en) 2007-08-23
JP4927877B2 (ja) 2012-05-09
BRPI0707581A2 (pt) 2011-05-10
CN104768145A (zh) 2015-07-08
JP4960389B2 (ja) 2012-06-27
US20070226502A1 (en) 2007-09-27
RU2404540C2 (ru) 2010-11-20
US20070218901A1 (en) 2007-09-20
JP2009526449A (ja) 2009-07-16
ES2392854T3 (es) 2012-12-14
RU2008136412A (ru) 2010-03-20
RU2427103C2 (ru) 2011-08-20
TW200803394A (en) 2008-01-01
EP2437460A1 (en) 2012-04-04
ATE543318T1 (de) 2012-02-15
KR20080102177A (ko) 2008-11-24
RU2008136410A (ru) 2010-03-20
WO2007095473A1 (en) 2007-08-23
TWI357270B (en) 2012-01-21
US8195943B2 (en) 2012-06-05
JP2009526334A (ja) 2009-07-16
EP1992189A1 (en) 2008-11-19
WO2007095471A3 (en) 2008-01-17
CA2636270A1 (en) 2007-08-23
EP1992188A2 (en) 2008-11-19
EP1992189B1 (en) 2012-01-25
KR20080092469A (ko) 2008-10-15

Similar Documents

Publication Publication Date Title
BRPI0707583B1 (pt) obscurecimento de identidades temporárias de equipamento de usuário
Lichtman et al. LTE/LTE-A jamming, spoofing, and sniffing: threat assessment and mitigation
ES2652314T3 (es) Cifrado de enlace ascendente durante acceso aleatorio
ES2911606T3 (es) Procedimiento y aparato para determinar un espacio de búsqueda de canal de control
CN113632517A (zh) 用于无线通信中的安全接入控制的方法和装置
US20190058731A1 (en) User-side detection and containment of arp spoofing attacks
ES2565813T3 (es) Parámetros de transmisión para transmisión de muy alta velocidad
JP2011501517A (ja) 無線通信システムにおける二次同期符号のためのスクランブル符号
BRPI0715661A2 (pt) mÉtodo e equipamento para acesso aleatàrio em um sistema de comunicaÇço de acesso méltiplo ortogonal
RU2008147264A (ru) Индивидуальные и групповые идентификаторы для абонентского оборудования в беспроводных системах с совместно используемым транспортным каналом
KR101625037B1 (ko) Lte 망 초기 접속 구간에서 ue 식별 파라미터의 암호화 방법
JP2022078325A (ja) 第１のネットワーク装置及び第１のネットワーク装置のための方法
Ludant et al. From 5g sniffing to harvesting leakages of privacy-preserving messengers
EP3391607A1 (en) Method of generating a pseudonym associated with a communication device, a network node, computer program and computer program product
Chen et al. Preventing DRDoS attacks in 5G networks: a new source IP address validation approach
Li et al. SDN-Ti: a general solution based on SDN to attacker traceback and identification in IPv6 networks
Byrd et al. CSAI: Open-source cellular radio access network security analysis instrument
WO2012031523A1 (en) System and method for providing security in a wireless communications system
KR101387528B1 (ko) 무선 통신 시스템에서의 데이터 송수신 방법
JP2023532016A (ja) 匿名識別情報のためのサブスクリプション取出し
US11589237B2 (en) Methods, systems, and computer readable media for mitigating unauthorized message relay attacks
Olimid et al. On LowCost Privacy Exposure Attacks in LTE Mobile Communication
Dunlop et al. IPv6: Now you see me, now you don’t
CN112688908A (zh) 安全通信的方法和装置
Oladayo et al. PA-AKA: Privacy-Aware and Lightweight Authentication Scheme for Long Term Evolution (LTE)

Legal Events

Date Code Title Description
B15K Others concerning applications: alteration of classification

Ipc: H04L 29/06 (2006.01), H04L 9/08 (2006.01), H04L 29

B06F Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]
B06T Formal requirements before examination [chapter 6.20 patent gazette]

Free format text: EXIGENCIA DE PRE-EXAME

B09A Decision: intention to grant [chapter 9.1 patent gazette]
B16A Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]

Free format text: PRAZO DE VALIDADE: 10 (DEZ) ANOS CONTADOS A PARTIR DE 13/08/2019, OBSERVADAS AS CONDICOES LEGAIS. (CO) 10 (DEZ) ANOS CONTADOS A PARTIR DE 13/08/2019, OBSERVADAS AS CONDICOES LEGAIS

B21F Lapse acc. art. 78, item iv - on non-payment of the annual fees in time

Free format text: REFERENTE A 15A ANUIDADE.

B24J Lapse because of non-payment of annual fees (definitively: art 78 iv lpi, resolution 113/2013 art. 12)

Free format text: EM VIRTUDE DA EXTINCAO PUBLICADA NA RPI 2656 DE 30-11-2021 E CONSIDERANDO AUSENCIA DE MANIFESTACAO DENTRO DOS PRAZOS LEGAIS, INFORMO QUE CABE SER MANTIDA A EXTINCAO DA PATENTE E SEUS CERTIFICADOS, CONFORME O DISPOSTO NO ARTIGO 12, DA RESOLUCAO 113/2013.