Transcrições
3G
HSPA - Dúvida (02)
----- Original Message -----
From: J. R. Smolka
To: wirelessbr@yahoogrupos.com.br
Sent: Wednesday, November 28, 2007 2:37 PM
Subject: Re: [wireless.br] 3G HSDPA - Dúvida
Luciano,
Ainda por partes...
Obrigado pelas respostas, a maioria eu tinha uma idéia mas queria
confirmação (pelo menos 2 com a mesma idéia deve ser mais próximo da
verdade).
De nada, mas sempre é bom lembrar de Nélson Rodrigues: "toda unanimidade
é burra" :-)
Quanto aos protocolos fiquei na dúvida pois li um white paper da Huawei
que diz que utiliza H.323 ( http://www.huawei.com/publications/view.do?id=228&cid=90&pid=61
). Pesquisando hoje achei um protocolo específico pra vídeo no 3g, o
3G-324M. Dois links interessantes sobre ele são a boa e velha wikipwdia
(é nova mas ficou tão íntima que já chamo de velha) http://en.wikipedia.org/wiki/3G-324M
e um tutorial muito interessante em http://www.commsdesign.com/design_corner/OEG20030121S0009
.
Este comentário tem de ser um pouco mais extenso. Segundo o artigo da
Huawey que vc citou, a solução deles foi lançada em 2003. Até esta época
o H.323 era a "bola de segurança" (pra quem nunca jogou vôlei, esta é a
bola que o levantador puxa quando as coisas não saem de acordo com os
planos - supondo que vc tem no time um atacente que resolva a parada
nestas horas). E isto está de acordo com o que falei antes. De lá pra
cá, o SIP ganhou força e o H.323 perdeu importância como principal opção
para a sinalização no estabelecimento de sessões de serviços multimedia.
O que está ocorrendo no Brasil agora é a implantação de redes UMTS 3GPP
release 6. Neste release o packet switching (PS) domain ainda não é
preponderante sobre o circuit-switching (CS) domain. E soluções baseadas
na especificação 3G-324M do 3GPP são voltadas para o CS domain.
Embora o IMS já faça parte do release 6 do 3GPP, a verdade é que
provavelmente não veremos (ainda) serviços primariamente voltados para o
PS domain. Mas, quando eles acontecerem, não tenho dúvidas que a melhor
opção de sinalização será o SIP.
O tutorial que vc citou é muito bom, mas é da mesma época, e ainda traz
um ranço a mais. A visão de que redes IPv4 não seriam capazes de
oferecer a QoS necessária para aplicações multimedia "carrier-class".
Meu comentário para esta postura (que persiste, embora diminuída, até
hoje) é: carrier-class my ass. :-)
Já publiquei alguns artigos (que estão disponíveis no site
www.wirelessbr.org) que mostram as ferramentas para o suporte de QoS por
uma rede IPv4. E, pelo menos por enquanto, ainda não é mandatória a
migração para IPv6 para conseguir uma rede all-IP que funcione. O
problema real é outro: o desejo que uma rede PS se comporte como se
fosse CS. Enquanto os fornecedores continuarem nesta visão de "circuitização
de pacotes" (que por tabela afeta também os órgãos de padronização,
afinal são os mesmos caras que comandam as áreas de R&D dos fornecedores
que vão representá-los nos comitês que escrevem as normas) as coisas não
vão mudar de verdade.
É interessante observar o grau de commitment de cada fornecedor com as
mudanças de paradigmas na transição CS-PS. O grau de reticência que cada
fornecedor mostra em público com relação a esta ou aquela tecnologia é
diretamente proporcional à provável perda de receita que ele pode ter se
o paradigma mudar. Quer um exemplo? Observe as diferenças de discurso
entre os principais fornecedores de equipamentos/serviços de telecom com
relação ao WiMAX. Só isso já dá para mais um novo post.
Tem alguém da Claro aqui na lista que pode simplesmente dizer se é esse
protocolo que é usado aqui no Brasil pras vídeo chamadas?
Como eu não trabalho nem na Claro nem na Telemig Celular, não posso
ajudar nisso. Mas também estou curioso. Se alguém aparecer para explicar
melhor as soluções que foram adotadas em cada caso, também estou
interessado em ouvir.
[ ]'s
J. R. Smolka
3G
HSPA - Dúvida (01)
----- Original Message -----
From: J. R. Smolka
To: wirelessbr@yahoogrupos.com.br
Sent: Tuesday, November 27, 2007 11:50 AM
Subject: Re: [wireless.br] 3G HSPA - Dúvida
Luciano,
Por partes...
A Telemig e a Claro lançaram comercialmente o 3G
no Brasil e ambas colocam como diferencial, além da alta taxa de
transmissão de dados, alguns serviços como TV e vídeo chamada. Só que
nas duas operadoras estes serviços são cobrados e bem cobrados. Eu
imaginava que a vídeo chamada por exemplo fosse uma aplicação P2P sobre
o link de dados, como de fosse um telefone VoIP, mas como as operadoras
tarifam a chamada com certeza tem um servidor controlando tudo. E aí
vieram minhas dúvidas:
Em geral as operadoras de telecom (fixas ou móveis) usam esta abordagem
de ofertar serviços do tipo "closed garden", onde os componentes client
e server da aplicação são fornecidos por elas, e a experiência do
usuário fica restrita ao grupo fechado de usuários assinantes do
serviço. Isto tem vantagens e desvantagens. No lado positivo, desta
forma dá para garantir melhor a qualidade do serviço prestado, mas do
lado negativo esta forma de operar restringe a liberdade do usuário
escolher a aplicação que atenda melhor às suas necessidades.
Talvez isto mude no futuro, mas não tenho muitas esperanças a médio
prazo (próximos 5 anos).
Alguém saberia me dizer que protocolo é usado (HS.323)?
Não sei detalhes, mas muito provavelmente não. O H.323 foi proposto
dentro do contexto B-ISDN, e foi muito usado até uns 5 anos atrás,
principalmente em aplicações de videoconferência. De lá para cá que tem
ganhado terreno é o SIP, que tenho 99% de certeza que é o que deve estar
sendo usado. Mas, porquê não 100%? Porque existe a possibilidade (burra,
se realmente estiver ocorrendo) de ser usado um protocolo de sinalização
proprietário.
A operadora só controla a sinalização ou os
pacotes saem de uma plataforma?
Não sei se entendi direito a sua dúvida. Mas aplicações do tipo que vc
descreveu, em ambiente padrão 3GPP, a sinalização (SIP/RTP/IP) é trocada
entre a parte cliente da aplicação e a plataforma IMS, que media a
autenticação do usuário e a abertura da sessão de transferência de dados
entre o cliente e o servidor. O stream de dados é transferido
diretamente entre a parte cliente e a parte servidor da aplicação (payload/RTP/IP).
Existe algo que evite um usuário utilizar um skype
ou voip para falar, pagando o tráfego de dados mas não o serviço?
Em princípio não. Já vi isto funcionando (especificamente, usando Skype)
em redes 1X e EV-DO. E redes UMTS? Também pode, desde que exista, pelo
menos, suporte a HSDPA. Porém a experiência de uso que o usuário vai ter
depende de vários fatores. A aplicação usada convive bem com a alta
latência imposta pela interface aérea UMTS? Existe banda suficiente para
a aplicação nos dois sentidos (Considerando que no HSDPA/HSUPA/HSPA
existe assimetria entre o downlink e o uplink)? A operadora dá suporte,
é neutra ou interfere negativamente no tratamento de QoS dos pacotes em
trânsito de aplicações que não sejam homologadas por ela?
O que, além de é claro a camera, o telefone tem
que ter para suportar esse serviço?
Um sistema operacional que suporte a aplicação que vc deseja usar, e dê
acesso para a aplicação usar o microfone o alto-falante e a câmera do
handset como dispositivos de entrada/saída. Se vc estiver usando um
laptop isto é simples. Para handsets celulares, depende do fabricante e
do modelo.
Perguntador eu...
Respondedor, eu :-)
J. R. Smolka
CDMA,
WCDMA, ... "to infinity, and beyond!!" (Buzz Lightyear)
----- Original Message -----
From: José de Ribamar Smolka Ramos
To: Celld-group@yahoogrupos.com.br
Sent: Thursday, August 16, 2007 10:36 AM
Subject: [Celld-group] CDMA, WCDMA, ... "to infinity, and beyond!!" (Buzz
Lightyear)
Marcelo e Latino,
Vi os posts que vcs colocaram no grupo, e gostaria de dar uma opinião,
dentro do espírito de fomentar a discussão técnica (que anda meio
devagar ultimamente).
Ponto 1: CDMA x GSM é assunto encerrado. O GSM conseguiu firmar-se como
tecnologia de acesso dominante para redes de comunicação celulares, e
fim de papo.
Ponto 2: CDMA 2000 x WCDMA também é assunto encerrado. A forma dominante
do UMTS que está implementada na Europa, EUA e Ásia é baseada em WCDMA,
com os "esteróides" HSDPA + HSUPA = HSPA para as conexões do packet
switching domain (3GPP releases 6 e 7). Isto é o que todas as operadoras
brasileiras implantarão nos próximos 12 meses.
Ponto 3: Onde existe enorme espaço aberto para discussão é na transição
3G/4G e na convergência de serviços fixos e móveis (fixed-mobile
convergence - FMC).
Se concordamos sobre estes pontos, então as questões que eu gostaria de
colocar em aberto para o grupo são:
1) Considerando que as principais tecnologias de acesso 4G que estão
competindo são baseadas em OFDM (WiMAX móvel versus LTE com HSOPA -
High-Speed OFDM Packet Access), e que a transição para qualquer uma
delas representa considerável investimento para as operadoras, qual
delas provavelmente oferecerá maiores vantagens para o negócio?
2) Já que as transições 2,5G/3G (atual) e 3G/4G (futura) não serão
instantâneas, teremos durante algum tempo a necessidade de compartilhar
várias tecnologias de acesso no mesmo site (BTSs GSM e/ou CDMA, node-Bs
WCDMA e seja-lá-que-sigla-inventem WiMAX e/ou HSOPA). Qual a melhor
opção para um backhaul eficiente? MPLS puro mais pseudo-wires PWE3?
Transmissão SDH? Ethernet? Ou outra coisa qualquer?
3) Um ambiente 4G pressupõe que o principal foco de desenvolvimento de
serviços será no packet switching domain (All-IP Network - AIPN + SIP
signaling + IMS + SDP + ...). Neste contexto, como deveria ser a
distribuição das funcionalidades lógicas do IMS entre os elementos
físicos do core? Para conseguirmos FMC será necessário evoluir o modelo
atual de mobilidade baseado em SGSN/GGSN para um modelo Mobile IP de
verdade? E, se isso for verdade, que características o user device deve
possuir?
Eu certamente tenho respostas tentativas para cada uma destas questões,
mas gostaria de ouvir o que o restante do grupo tem a dizer a respeito.
[ ]'s
J. R. Smolka
Qualidade x Faturamento
------ Original Message -----
From: José de Ribamar Smolka Ramos
To:
wirelessbr@yahoogrupos.com.br
Sent: Wednesday, June 13, 2007 5:03 PM
Subject: [wireless.br] Qualidade x Faturamento
Depois de tanto tempo sem aparecer, só posso
voltar cantando:
Se vocês pensam que nóis fumo embora
Nóis enganemo vocêis
Fingimo que fumo e vortemo
Ói nóis aqui travêis
Chega de distração... Há algum tempo atrás me
pediram para justificar economicamente a aquisição de ferramentas para o
controle da qualidade da rede IP. Admito que isto me fez pensar em
alguns expletivos fortes (que tive o bom senso de não pronunciar em
público), afinal, ninguém discute a necessidade de monitorar a qualidade
do serviço prestado, especialmente quando se trata de VoIP em ambiente
carrier-class.
Depois de quebrar um pouco a cabeça, acabei encontrando uma maneira de
quantificar os chamados custos da não-qualidade. Espero que o
raciocínio a seguir possa ajudar quem também tenha um problema
semelhante (BTW, a justificativa foi aceita
).
Como vamos ter algumas expressões algébricas no texto, vou usar a
simbologia padrão para representar operações aritméticas: + (soma), -
(subtração), * (multiplicação), / (divisão) e ^ (exponenciação).
Vamos assumir que, na ausência de qualquer problema de qualidade, a rede
é capaz de suprir uma demanda de M unidades de serviço tarifável (que
podem ser minutos de uso, quilobytes trafegados, etc.). M está
relacionado com o número de sessões estabelecidas pelos usuários -
designado como N, e com a duração média das sessões - designado como T,
pela relação:
M = N * T [1]
Se ocorrem problemas de qualidade (de qualquer espécie), vamos assumir
que:
a) Uma parte das sessões ocorre sem problemas, e o restante das
sessões sofre incidentes de qualidade que forçam a sua interrupção.
Chamando NOK ao número de sessões sem problemas e NKO ao número de
sessões com problemas temos:
N = NOK + NKO
Denominando a proporção das sessões que sofrem problemas como Q, temos:
Q = NKO / N
NKO = Q * N [2]
NOK = (1 - Q) * N [3]
b) Os usuários fazem retry de uma parte das sessões que
experimentam problemas, e a outra parte é abandonada pelos usuários.
Chamando NR ao número de sessões que sofreram retry e NA ao número de
sessões abandonadas temos:
NKO = NR + NA
Denominando a proporção das sessões que sofrem retry como R, temos:
R = NR / NKO
NR = R * NKO [4]
Substituindo [2] em [4] temos:
NR = R * Q * N [5]
c) A duração média das sessões sem problemas é assumida como
sendo igual a T. Vamos denominar TKO ao tempo médio de duração das
sessões que sofrem interrupção, e TR ao tempo médio das sessões
resultantes do retry dos usuários. Vamos supor que, em média, estes
tempos sejam:
TKO = T / 2 [6]
TR = T / 2 [7]
Pelas suposições feitas, vemos que a ocorrência de problemas de
qualidade altera o número de sessões e o tempo médio de duração das
sessões. Vamos denominar N' e T' a estes novos valores, e expressá-los
em função dos valores originais N e T.
O novo número de sessões será a soma do número de sessões sem problema,
mais a o número de sessões interrompidas, mais o número de sessões
originadas do retry dos usuários:
N' = NOK + NKO + NR [8]
Substituindo [2] [3] e [5] em [8] temos:
N' = (1 + R * Q) * N [9]
O novo tempo médio de duração será a média ponderada do tempo médio de
duração das sessões sem problema, do tempo médio de duração das sessões
com problema e do tempo médio de duração das sessões resultantes do
retry dos usuários:
T' = (NOK * TOK + NKO * TKO + NR * TR) / (NOK + NKO + NR) [10]
Substituindo [2] [3] [5] [6] e [7] em 10, e simplificando, temos:
T' =( (1 + Q * (R - 1) / 2) / (1 + R * Q)) * T [11]
Então podemos calcular o novo número total de unidades de serviço
tarifáveis, denominado M', como sendo:
M' = N' * T' [12]
Substituindo [10] e [11] em [12], e simplificando, temos:
M' = (1 + Q * (R - 1) /2) * M [13]
Definimos a variação proporcional de M em função de Q e R como sendo:
V = (M' - M) / M [14]
Então, substituindo [13] em [14] e simplificando, temos:
V = Q * (R - 1) / 2 [15]
Observando o comportamento típico dos usuários, temos uma forte suspeita
que R e Q estejam correlacionados, e que esta correlação possa ser
expressa, aproximadamente, por uma função na forma R = f(Q). Que
características gerais esta função deveria satisfazer? Pela observação,
temos:
- Quando Q é igual a zero (nenhum problema de
qualidade), então R é igual a zero (nenhum retry);
- Quando Q é diferente de zero, Q e R tem
correlação negativa. Isto é: Se Q é muito próximo de zero, então R é
muito próximo de um, e quando Q tende a um R tende a zero;
- A função f(Q) pode atingir o valor zero para
um valor de Q menor que um. Neste caso, para qualquer valor de Q maior
que este valor limite, R será igual a zero.
Para simplificar, vamos supor que f(Q) = 1 - Q
(correlação linear) para Q maior que zero e menor ou igual a um. Esta
suposição é otimista. Tenho forte suspeita que a função real (que
precisa ser determinada empiricamente) é pior que isto, mas deixa isto
pra lá. Substituindo a expressão R = 1 - Q em [15] temos:
V = - Q^2 / 2 [16]
A variação expressa por [16] é em relação à situacão hipotética (e
irreal) de nenhum problema de qualidade. Supondo que a rede está
operando em um nível de problemas de qualidade onde Q = q1 (q1 maior que
zero) e passa a operar em um nível de qualidade onde Q = q2 (q2 maior
que zero e maior que q1), a diferença entre as variações dadas por [16]
é que representa a perda esperada no número de unidades de serviço
tarifáveis (e, consequentemente, perda de receita bruta, que é
diretamente proporcional ao número de unidades de serviço tarifáveis
cursadas pela rede).
Então, vamos observar o que acontece quando temos Q igual a,
sucessivamente, 1%, 2%, 3%, 4%, 5%, 6%, 7%, 8%, 9% e 10%.
Q = 1% --> V(1%) = -0,005%
Q = 2% --> V(2%) = -0,02% --> diferença = -0,015%
Q = 3% --> V(3%) = -0,045% --> diferença = -0,025%
Q = 4% --> V(4%) = -0,08% --> diferença =
-0,035%
Q = 5% --> V(5%) = -0,125% --> diferença =
-0,045%
Q = 6% --> V(6%) = -0,18% --> diferença =
-0,055%
Q = 7% --> V(7%) = -0,245% --> diferença =
-0,065%
Q = 8% --> V(8%) = -0,32% --> diferença =
-0,075%
Q = 9% --> V(9%) = -0,405% --> diferença =
-0,085%
Q = 10% --> V(10%) = -0,5% --> diferença =
-0,095%
O que vemos aqui é que, nesta faixa, cada ponto percentual de aumento na
incidência de problemas de qualidade causa uma perda crescente da
receita bruta do serviço obtida no nível de qualidade anterior
(multiplicando a perda pelo valor médio da unidade de serviço
tarifável). E quanto maior o valor de Q, mais acelerada é a perda.
Considerando o valor da receita bruta de uma operadora, digamos, no
serviço de voz, estas perdas podem convencer o mais empedernido analista
financeiro da sensatez de não deixar a qualidade da rede ao acaso.
Inté a próxima oportunidade (que espero não estar muito distante)
[ ]'s a todos
J. R. Smolka
IMS,
SDP, NGNs...
----- Original Message -----
From: José de Ribamar Smolka Ramos
To: wirelessbr@yahoogrupos.com.br
Sent: Wednesday, April 25, 2007 9:01 AM
Subject: [wireless.br] IMS, SDP, NGNs... (publicado no Heavy Reading)
http://www.heavyreading.com/
IMS: Enough About the Rabbits Already!
Joe McGarvey, Senior Analyst, Heavy Reading
Though Steinbeck has fallen out of favor in the last few decades –
nobody likes to be reminded of dustbowls and depressions, go figure –
the short novel Of Mice and Men was still a staple of the English
curriculum way back when I was in junior high. And thanks to Hollywood
and Broadway churning out dozens of versions of the tale over the years,
the phrase "Tell me about the rabbits, George," remains familiar to a
large cross-section of the population today.
As a quick reminder, though, Of Mice and Men is mostly about (putting
aside the social commentary about life in the 1930s) the relationship
between two itinerant farm workers – Lenny and George – in pursuit of
owning their own place. The "rabbits" line comes from George's practice
of pacifying the dim-witted Lenny with rose-colored descriptions of
their future homestead, littered with gaggles of fuzzy bunnies for Lenny
to pet.
Appraising the current status of the adoption of next-generation
technology, it's almost impossible not to draw the analogy that network
equipment providers have been playing George to the service providers'
Lenny for the past couple of years.
Nearly all of the talk around next-generation networks (NGNs), IP
Multimedia Subsystem (IMS) and service delivery platforms (SDPs) has to
this point been about the destination. For the most part, 2005 and 2006
were one long, continuous "tell-me-about-the-rabbits" routine, as
carriers and large service providers sought assurances about the
Shangri-La that awaits them after their move to NGN. "Tell me about IMS,
Ericsson. Will there be lots of new services to sell, Alcatel-Lucent?
Can I save lots of money by moving to a horizontal architecture, Siemens?
Will there be plenty of fixed-mobile convergence, Nokia? Will we be able
to live offa the fatta the LAN?"
Network equipment providers, for their part, have been more than happy
to assume the George role. Of the hundreds of presentations and pitches
delivered on NGN or IMS over the past couple of years, nearly all have
focused on the destination rather than the journey. Descriptions of
finely tuned networks, capable of turning out new applications in a
matter of days and delivering customized services that eliminate the
boundaries between fixed and mobile or work and leisure, are as common
as a crooked politician, but it would take a microscope of considerable
power to find a honest evaluation of how service providers are actually
going to reach that land of milk and honey.
Nearly a quarter into 2007, it seems carriers and service providers have
finally grown weary of all this talk of rabbits. The noticeable
deflation of IMS hype in the latter portion of 2006 can be directly
attributed to service providers beginning to turn a skeptical ear to the
saccharine diatribes of their parts suppliers. Even children will lose
interest in bedtime stories if every fairy tale they hear ends and
begins with "…and they lived happily ever after."
Carriers, it appears, are finally waking up to the fact that they'll
never enter that service delivery Promised Land until equipment makers
stop skipping to the denouement and start fleshing out the early
chapters of their transition stories. Even a superficial inspection of
the situation reveals that the NGN roadmap has three major missing
pieces that, unless found, will prevent service providers from
transforming their networks into the subscriber-centric vessels that IMS
and SDPs promise.
Backward Compatibility: Although this is Telecom 101, the folks creating
the standards have spent nearly all of their efforts making sure that
the dozens of functional elements in the IMS specification can talk to
each other, without giving much more than a passing thought to making
sure these elements work with the existing service and application
environments. Without backward compatibility, IMS is just another
stovepipe in a carrier's vertically organized infrastructure, and its
adoption means a continuation of the status quo, rather than a reversal.
Service Orchestration: The irony about service orchestration is that the
name of the mechanism that has come to represent the functionality – the
Service Capabilities Interaction Manager (SCIM) – is almost as long as
the technical prose dedicated to the subject in the 3GPP specification.
It's not surprising that the standards bodies have left this utterly
critical IMS component out of the specification: The process of
coordinating the actions of multiple application servers, both in and
out of a Session Initiation Protocol (SIP) environment, is not a trivial
task, and is most likely best left to the efforts of individual
equipment suppliers – which unfortunately have been slow to seize on
anything resembling a definitive solution to this problem.
Non-IMS Traffic: To give proper credit where it's due, as early as 2005
some equipment makers were quick to recognize that a SIP-only service
delivery architecture suffered severely from the fact that SIP makes up
only a small percentage of the IP traffic that currently traverses
service provider networks. While most equipment vendors have now
addressed this issue by positioning IMS as a subset of a larger, more
encompassing service delivery environment, work still needs to be done
before carriers can fully integrate all of their services (voice, video,
IPTV, mobile) into a master delivery system that puts all traffic types
under one thumb.
Only an honest and realistic account of the current status of these
roadblocks will get the NGN movement back on track. The network
equipment providers that make the rabbits-to-reality transition and
start to tackle these problems head-on will be the ones that win the
long-term loyalty of carriers and service providers. Those that continue
to fast-forward past these glaring obstacles should prepare for an
eventual customer backlash by familiarizing themselves with another
Steinbeck novel: The Grapes of Wrath.
J. R. Smolka
