Windows Reboots Triggered Skype Glitch

By MATT MOORE
AP Business Writer
Technology Video
Buy AP Photo Reprints

FRANKFURT, Germany (AP) -- A two-day outage that left millions of Skype users unable to use the popular Internet phone service was caused by an abnormally high number of restarts after people had downloaded a Windows security update, the company said Monday.

The worldwide outage, which began on Thursday and ended on Saturday, left millions of Skype users unable to log on to make phone calls or send instant messages.

Luxembourg-based Skype Ltd., part of online auction giant eBay Inc., has more than 220 million users in total but typically has 5 million to 6 million users online at any given time. In January, Skype reported that it had counted 9 million users online at one time.

In an update to users on Skype's Heartbeat blog, employee Villu Arak said the disruption was not because of hackers or any other malicious activity.

Instead, he said that the disruption "was triggered by a massive restart of our users' computers across the globe within a very short timeframe as they re-booted after receiving a routine set of patches through Windows Update," Arak wrote.

Microsoft Corp. released its monthly patches last Tuesday, and many computers are set to automatically download and install them. Installation requires a computer restart.

"The high number of restarts affected Skype's network resources. This caused a flood of log-in requests, which, combined with the lack of peer-to-peer network resources, prompted a chain reaction that had a critical impact," Arak wrote.

Arak did not blame Microsoft for the troubles and said the outage ultimately rested with Skype. Arak said Skype's network normally has an ability to heal itself in such cases, but a previously unknown glitch in Skype's software prevented that from occurring quickly enough.

In a statement, Microsoft described its patch as routine and reiterated that the disruption resulted from a bug in Skype software.

Users from Vietnam to Brazil to Germany to the United States had complained they could not log on and make phone calls or send instant messages.

The outage was a critical moment for the company, founded in 2003 by Niklas Zennstrom and Janus Friis, and was the first major outage since October 2005 when its service was down only for a few hours.

"This disruption was unprecedented in terms of its impact and scope," Arak wrote. "We would like to point out that very few technologies or communications networks today are guaranteed to operate without interruptions."

TCP window scaling and broken routers

Every TCP packet includes, in the header, a "window" field which specifies how much data the system which sent the packet is willing and able to receive from the other end. The window is the flow control mechanism used by TCP; it controls the maximum amount of data which can be "in flight" between two communicating systems and keeps one side from overwhelming the other with data.

In the early days of TCP, windows tended to be relatively small. The computers of that age did not have huge amounts of memory to dedicate toward buffering network data, and the available networking technology was not fast enough to make use of a larger window in any case. Modern network interfaces can handle larger packets and keep more of them in flight at any given time; they will perform better with a larger window. Some kinds of high-speed long-haul links can have very high bandwidth, but also high latency. Keeping that sort of pipe filled can require a very large window; if a sending system cannot have a large number of packets in transit at any given time, it will not be able to make use of the bandwidth available. For these reasons, good performance can often require very large windows.

The TCP window field, however, is only 16 bits wide, allowing for a maximum window size of 64KB. The TCP designers must have thought that nobody would ever need a larger window than that. But 64KB is not even close to what is needed in many situations today. The solution to this problem is called "window scaling." It is not new; window scaling was codified in RFC 1323 back in 1992. It is also not complicated: a system wanting to use window scaling sets a TCP option containing an eight-bit scale factor. All window values used by that system thereafter should be left-shifted by that scale factor; a window scale of zero, thus, implies no scaling at all, while a scale factor of five implies that window sizes should be shifted five bits, or multiplied by 32. With this scheme, a 128KB window could be expressed by setting the scale factor to five and putting 4096 in the window field.

To keep from breaking TCP on systems which do not understand window scaling, the TCP option can only be provided in the initial SYN packet which initiates the connection, and scaling can only be used if the SYN+ACK packet sent in response also contains that option. The scale factor is thus set as part of the setup handshake, and cannot be changed thereafter.

The details are still being figured out, but it would appear that some routers on the net are rewriting the window scale TCP option on SYN packets as they pass through. In particular, they seem to be setting the scale factor to zero, but leaving the option in place. The receiving side sees the option, and responds with a window scale factor of its own. At this point, the initiating system believes that its scale factor has been accepted, and scales its windows accordingly. The other end, however, believes that the scale factor is zero. The result is a misunderstanding over the real size of the receive window, with the system behind the firewall believing it to be much smaller than it really is. If the expected scale factor (and thus the discrepancy) is large, the result is, at best, very slow communication. In many cases, the small window can cause no packets to be transmitted at all, breaking TCP between the two affected systems entirely.

In the 2.6.7 kernel, the default scale factor is zero; in Linus's BitKeeper tree and the 2.6.7-mm kernels, instead, it has been increased to seven. This change has brought the broken router behavior to light; suddenly people running current kernels are finding that they cannot talk to a number of systems out there. One of the higher-profile affected sites is packages.gentoo.org. Gentoo users are, unsurprisingly, not pleased.

As a way of making things work, Stephen Hemminger has proposed a patch which adds a calculation to select the smallest scale factor which covers the largest possible window size. The result on most systems is that the scale factor gets set to two. This factor will still be corrupted by broken routers, but the resulting window size (¼ of what it should be) is still large enough to allow communication to happen.

The patch makes networking with systems behind broken routers work again, but it has been rejected anyway. The networking maintainers (and David Miller in particular) believe that the patch simply papers over a problem, and that adding hacks to the Linux network stack to accommodate broken routers is a mistake. If, instead, the situation is left as it is, pressure on the router manufacturers should get the problem fixed relatively quickly. It has been a few years, now, that Linux has a strong enough presence in the networking world that it can get away with taking this sort of position.

In the mean time, anybody running a current kernel who is having trouble connecting to a needed site can work around the problem with a command like:

    echo 0 > /proc/sys/net/ipv4/tcp_default_win_scale

or by adding a line like:

    net.ipv4.tcp_default_win_scale = 0

to /etc/sysctl.conf.

NAT Classification Test Results
.  Descriptions of Tests

2.1.  UDP Mapping

  This test sends STUN[1] packets from the same port on three different
  internal IP addresses to the same destination.  The source port on
  the outside of the NAT is observed.  The test records whether the
  port is preserved or not and whether all the mapping get different
  ports.

  A second set of tests checks out how the NAT maps ports above and
  below 1024.

  Tests are run with a group of several consecutive ports to see if the
  NAT preserves port parity.

2.2.  UDP Filtering

  This test sends STUN packets from the same port on three different
  internal IP addresses to the same destination.  It then tests whether
  places on the outside with 1) a different port but the same IP
  address and then 2) a different port and a different IP address can
  successfully send a packet back to the sender.  The test is based on
  technique described in [2].

2.3.  UDP Hairpin   This test sends a STUN packet from the inside to the outside to
  create a mapping and discover the external source address called A.
  It does the same thing from a different internal IP address to get a
  second external mapping called B. It then sends a packet from A to B
  and B to A and notes if these packets are successfully delivered from
  one internal IP address to the other.
2.4.  ICMP

  A device on the inside sends a packet to an external address that
  causes an ICMP Destination Unreachable packet to be returned.  The
  test records whether this packet makes it back through the NAT
  correctly.

2.5.  Fragmentation

  The MTU on the outside of the NAT is set to under 1000; on the inside
  it is set to 1500 or over.  Then a 1200 byte packet is sent to the
  NAT.  The test records whether the NAT correctly fragments this when
  sending it.  Another test is done with DF=1.  An additional test is
  done with DF=1 in which the adjacent MTU on the NAT is large enough
  the NAT does not need to fragment the packet but further on, a link
  has an MTU small enough that an ICMP packet gets generated.  The test
  records whether the NAT correctly forwards the ICMP packet.

  In the next test a fragmented packet with the packets in order is
  sent to the outside of the NAT, and the test records whether the
  packets are dropped, reassembled and forwarded, or forwarded
  individually.  A similar test is done with the fragments out of
  order.

2.6.  UDP Refresh

  A test is done that involves sending out a STUN packet and then
  waiting a variable number of minutes before the server sends the
  response.  The client sends different requests with different times
  on several different ports at the start of the test and then watches
  the responses to find out how long the NAT keeps the binding alive.

  A second test is done with a request that is delayed more than the
  binding time but every minute an outbound packet is sent to keep the
  binding alive.  This test checks that outbound traffic will update
  the timer.

  A third test is done in which several requests are sent with the
  delay less than the binding time and one request with the delay
  greater.  The early test responses will result in inbound traffic
  that may or may not update the binding timer.  This test detects
  whether the packet with the time greater than the binding time will
  traverse the NAT which provide the information about whether the
  inbound packets have updated the binding timers.

  An additional test is done to multiple different external IP
  addresses from the same source, to see if outbound traffic to one
  destination updates the timers on each session in that mapping.

2.7.  Multicast and IGMP

  Multicast traffic is sent to the outside of the NAT, and the test
  records whether the NAT forwards it to the inside.  Next an IGMP
  Membership Report is sent from inside.  The test records whether the
  NAT correctly forwards it to the outside and whether it allows
  incoming multicast traffic.  More detail on NATs and IGMP is provided
  in [3].

2.8.  Multicast Timers

  The test records how long the NAT will forward multicast traffic
  without receiving any IGMP Membership Reports and whether receiving
  Reports refreshes this timer.

2.9.  TCP Timers

  TBD: Measure time before ACK, after ACK, and after FIN and RST.

2.10.  TCP Port Mapping

  Multiple SYN packets are sent from the same inside address to
  different outside IP addresses, and the source port used on the
  outside of the NAT is recorded.

2.11.  SYN Filtering

  Test that a SYN packet received on the outside interfaces that does
  not match anything gets discarded with no reply being sent.  Test
  whether an outbound SYN packet will create a binding that allows an
  incoming SYN packet.

2.12.  DNS

  Does the DNS proxy in them successfully pass through SRV requests.

2.13.  DHCP

  Do any DHCP options received on the WAN side get put into DHCP
  answers sent on LAN side?



2.14.  Ping

  Do ping request sent from LAN side work?



To help organize the NATs by what types of applications they can
  support, the following groups are defined.  The application of using
  a SIP phone with a TLS connection for signaling and using STUN for
  media ports is considered.  It is assumed the RTP/RTCP media is on
  random port pairs as recommended for RTP.

     Group A: NATs that are deterministic, not symmetric, and support
     hairpin media.  These NATs would work with many phones behind
     them.
     Group B: NATs that are not symmetric on the primary mapping.  This
     group would work with many IP phones as long as the media ports
     did not conflict.  This is unlikely to happen often but will
     occasionally.  Because they may not support hairpin media, a call
     from one phone behind a NAT to another phone behind the same NAT
     may not work.
     Group D: NATs of the type Bad. These have the same limitations of
     group B but when the ports conflict, media gets delivered to a
     random phone behind the NAT.


     Group F: These NATs are symmetric and phones will not work.

NAT Traversal

This is the original STUN algorithm.
One situation where it fails is the following:

               STUN
             server
               |
              NAT
               |
       ------------------
       |                |
      UA1              UA2

If the NAT does not support hairpinning, then your algorithm will not
work.

[http://tools.ietf.org/html/draft-jennings-behave-test-results-04
shows that most NATs today do not support UDP hairpinning, and
http://www.guha.cc/saikat/pub/imc05-tcpnat.pdf reports that most do not
support TCP hairpinning.]

This situation can occur when the two UAs belong to the same company,
or both are in the same hotel, or both use the same service provider
and the service provider has a NAT in front of its entire network, etc.

ICE does to things to solve this problem. First of all, UA1 and UA2 exchange
their local addresses and ports as well as their STUN-learned addresses.
They then test to see which path works. Second, they also exchange
TURN addresses, which serve as a backup in case everything else fails.

David Barrett's algorithm, if I understand it correctly, would work in
this situation. (As far as I can tell, David's is a simplified version
of ICE).

What's wrong with DNS?

What's wrong with DNS?

DNS was designed in the days when long-term store was scarce and so
was bandwidth. Technology was difficult and obtuse, with the number of
human implementors measured in the hundreds, and the number of users
in the thousands. I remember that because I was there. There was no
other way to pass this data. Something had to be first and that was
DNS, which reflected the times and the organizations that invented it
in the first place.

Those days are long gone now in the days of the $20 grocery-store 2G
flash RAM, millions of implementors, and billions of users.

Today's Internet is a consumer-driven multi-modal world which has no
patience for that.
To cripple bootstrap by leashing it to creaky DNS is a disservice to
the future.

Bootstrap should have some criteria requirements for some obvious
things such as satisfying the security AD but the actual
implementation should allow for individual implementations that
reflect a rapidly changing modern world.

Hardcoding is a quaint way of solving the problem, and it is far too
easy for protocol engineers to design in a vacuum. When a single
handheld device can receive inputs by SMS, email, walled and unwalled
IP,  and HTTP the number of sources for a bootstrap is openended and
impossible to mandate without creating limitations on functionality
and usefulness in a hybridized multi-modal world..

A mime message, encrypted by a private key known to that device, could
contain a myriad number of bootstraps, be they DNS, hardcoded IP (IPV4
or IPV6? Which?), local names,  peer names, SMS addresses,sip uris,
whathaveyou.  A list based on operating criteria, that can evolve over
time.

This message, more 'carrier pigeon'  than boostrap, can be delivered
via a variety of means, including via C/S SIP or stored from a
previous DHT. A primitive form of unencrypted messaging is called
'paper'.

In this environment a 'friend' network, of names associated with keys,
could be seeded entirely by SMS messages and never ever need DNS,, and
it works when zeroconf fails, which is often.  It could later use
broadcasts or multicasts to find other 'friends', using one of a
variety of techniques, zeroconf being one.

Create the requirements for the bootstrap that guarantee security,
functionality and interopability.  Create the list of appropriate
beacons, allowing room for more in the future.
//////////////////////////////////////////////////////////////////////////////////

That's certainly my thinking in bringing this up. Just do what's easy and knock off the biggest win -- a low-cost SIP infrastructure.

As I see it, this approach has the following advantages:

1) Zero changes to proxy servers and registrars.
- Non-firewalled peers become proxies and registrars just like before. They should be able to literally use the same code as the open source proxies and registrars out there, though, because nothing changes in the lookup.

2) Eliminating the most complicated part of the current architecture -- the DHT. It's also the thorniest to standardize.

3) Lower latency for completing calls. No more waiting around for the DHT to respond. Call completion happens just like it does with any other SIP call (if the DNS is up-to-date -- more below).


Then there are the disadvantages:

1) Delay of DNS propagation when registrars go down or clients move. I think this is the toughest to get a good read on because I don't know how it would play out in the field.

2) You'd need to run a dynamic DNS *client* on every node (at least that seems like the best approach to me).

3) You'd be relying on some servers out there to do the dynamic DNS. Possibly existing dynamic DNS providers?

4) Doesn't work in completely disconnected scenarios.

Keep in mind I'm not necessarily advocating this shift, but it certainly resonated with me once I realized the full implications of Paul's question to me the other day.

///////////////////////////////////////////////////////////////////////////////////

I don't want to beat a dead horse, but:
1. Most of the dynamic DNS implementations I'm familiar with have update
times measured in a couple of minutes.  It's not "real time", but it's
pretty short.  This is reflected in the TTL of the answer.

2. Any form of DNS requires a set of caching resolvers and authoritative
servers.  If you call that "centralized", then you are correct.  I always
think of DNS as being very decentralized except for the roots, and most
implementations I know work if connection to the root is lost, but the
answer is in the cache.

3. If you combine a short TTL with a disconnected server, then caching
doesn't work; resolvers need access to the authoritative servers (plural)
that provide the data.  It is servers plural, not singular.  I think this is
the reason dynamic DNS is not the best choice, although we may have been
hasty in coming to that conclusion.

4. I think identifiers in these systems are in the form of user@domain,
where domain is the "Overlay Id".  Humans may never see that, but it's
there.  Resolving "domain" to at least a starter set of peers has to happen
somehow.  We have only a few tricks in our bag for that:
 a. Configuration
 b. Multicast
 c. DNS
Are there other mechanisms?  There are multiple configuration mechanisms,
but they all depend on static information, not dynamic, learned data.

Agree that we explicitly declared dynamic DNS and multicast out of scope.
That leaves basic DNS and Configuration.

When networks become disconnected, local caching resolvers work.  If you are
within a domain, and you want a DNS answer from that domain, it works. 


Many existing systems work by configuration.  I'd rather not do that.

/////////////////////////////////////////////////////////////////////////////////

However if a kindler, gentler and 1000 points of light - better/faster/cheaper DNS is to be implemented

please look into steroid performance of CoDnS

http://www.cs.cornell.edu/people/egs/beehive/codons-sigcomm04/codons.html

IMS改写电信未来

IMS改写电信未来
无论固网运营商还是移动运营商，如今都有些“如在汤中”的感觉。面对传统电信服务收入的下降、行业竞争压力的加大，以及资费下调政策的挤压，运营商正在拼命压缩运营成本、寻求新的业务增长点，以达到股东“保持高增长”的要求。

彻底改变

大略地分析一下IMS可以带来的好处，就能明显发现，IMS是带来通信业务格局巨变的潜在因素。一个关键的特征就在于，IMS结构属于所有IP网络之上的 一个“统一服务层”（unified service layer），换句话说，同样的业务，可以采用任何一种网络技术，通过任何不同设备（有线的和无线的）来获取。

在传统电话网中，电信服务是基于交换的，增加新业务不仅困难而且投资巨大。而使用IMS，业务和网络是分开的体系，这使得拓展新业务时可以节约大量的投 资。通过IMS，电信运营商可以获得同一张网络上提供多种业务的能力，例如呈现业务（Presence）、计费（Billing）、会议系统 （Conferencing）等等，并且可以将这些业务集成为新的业务模式，通过移动网络或者固定网络传输。和单个业务单独开发、单独建立系统的传统“垂 直”模式相比，利用IMS是相当节时、高性价比的创新服务模式。

“统一整个服务层是电信业的‘圣杯’（Holy Grail）。” 提供系统集成和管理咨询服务的艾森哲公司无线IMS经理Kyriacos Sabatakis博士说。

同时，借助于SIP（会话初始协议），基于IMS的相关业务可以进行优先级排序，并且可以通过网络进行管理，以便获得更好的用户体验，也使IP网络应用效 能增加。同时，IMS也可以帮助运营商对付VoIP领域的“暴发户”们，例如Skype，因为VoIP并不能提供任何的QoS保障。

“IMS即如何将正确的数据传递给正确的人，并在这个过程中提高语音业务收入。” IBM 公司的Sandy Aitken说。

北电公司运营语音方案部副总裁Brian Day对于IMS将会带来的巨大影响也异常坚信。“IMS将促使运营商对自己在市场中的定位进行重新审视，因为IMS将会给运营商带来更多的业务开展途径 ——通过不同的接入技术——甚至它们不需要在网络上做太大的整体性的投入。”他说，“鉴于IMS的优势，运营商甚至可以考虑通过自己的网络服务平台，直接 租用其他运营商的网络。IMS同样使新业务的市场推广变得容易，支持范围扩大到固定和无线两大领域，更能够贴近客户，而不需要依赖复杂昂贵的网络基础架 构。”

随着网络接口的开放性和标准化程度进一步提高，IMS同样也能够激励更多的第三方应用开发商参与进来。进一步，IMS将影响到传统电信业的“生态模式”，改变电信运营商既是开发商、又是提供商的双重角色。

商业基础软件提供商BEA Systems公司的通信市场主管Neil Sholay也认为，IMS是值得期待的趋势。IMS将使得运营商能够更加集中精力在提高竞争力方面下功夫，管理好自己的网络，而不是去开发业务。 “IMS最大的好处是，使得跟踪和处理网络中的每个业务成为可能。具有前瞻思维的运营商将会改造网络，以成为网络业务提供者，而不是现在的网络业务开发 商。”Sholay在2005年12月召开的一个通信业大会上这样说。

何时上马？

抛开“IMS有望帮助电信运营商复兴”的观点不谈，IMS的发展很大程度上将取决于消费者的热衷程度，以及IMS到底能够对哪些“多种业务”提供支撑。

Mark Heath是一家总部设在英国的咨询机构Sound Partners的研究主管，他同时也是Analysys出版的IMS报告的撰写者。他认为，IMS是运营商未来的能力中必须具有的一个部分，但是运营商 现在更应该考虑的是：通过IMS拓展的哪些业务能够带来发展？运营商可能需要更多的时间来寻求IMS的具体走向。 “IMS这一技术的具体应用在何处？2006年，IMS的主要工作可能还是在实验方面，或者做一些小规模的推广，而不可能在全球范围内得到大面积的商业推 广。”他说。

根据Mark Heath分析，早期运营商推动IMS的方式，很可能是用来强化基础语音服务，诸如push-to-talk、即时消息和影视交流等。“首期的IMS应用 应该力求简单。”他说，“如果当前就试图利用IMS在固定网和移动网两个平台上都推出服务，显然是复杂和困难的。”

对此观点也不乏持反对意见者。IBM商业咨询服务的合伙人Sandy Aitken就认为，IMS并不见得需要依靠移动运营商来推动，他表示，对IBM的IMS解决方案有兴趣的固定运营商和移动运营商各占到了50%，而这两 类运营商对IMS的兴趣确实也和Heath所言一样，在于“如何提高语音收入”。但和Heath的观点不同，Aitken认为，一旦移动运营商能够把握 IMS的潜能在何处，IMS的发展速度将迅速加快，而不需要等待更长的时间。

“一个有关IMS的神话是它将引发一场数据革命，而我认为应当表述为‘服务联合’革命。IMS应当能够支持‘合适用户使用合适数据’，以提升语音收入。”Aitken说。

他以运行于3G平台之上、具有后台会议系统功能的多方游戏为例做了说明。他表示，当用户“正常”地玩游戏的时候，也就是说，如果没有附加语音沟通功能的支 持，通常一般会玩3~4分钟，而如果有这一功能，使得用户之间能够“更紧密地联系”，那么玩游戏的时间将持续30~40分钟。

Aitken也详细描述了另一些并非由移动运营商自己推出、而仅仅依赖其网络通道的服务。例如，房地产厂商可能希望能够以更便利、更快捷、更容易的方式， 和潜在购房客户取得接触，而购房者希望能够通过电话（在“呈现功能”的帮助下）和 房产代理商、法律顾问进行沟通，IMS可以帮助房地产厂商将这些服务功能集成起来推向市场，便于业务开展，而移动运营商则可以由此收取网络使用费。

尽管如此，简单的文本信息和语音服务仍然是电信运营商收入中占据压倒性地位的主要部分，而且上述创新服务的实现听上去仍然很遥远，还要寄希望于用户能够改 变旧有使用习惯去使用这些先进服务。Aitken表示，他如此举例，更多地是为了指出移动运营商和固定运营商都可以提供IMS服务，而这些服务开展不起 来，一个很大的原因是运营商太过于计较所谓投入产出的成本效益。“服务种类越多，越有可能获得机会和用户‘忠诚度’。”Aitken说。

“在现有的垂直性网络环境下，一般开发和推动一个新的服务，通常需要两年以上的时间，因无用成本投入是个很大的问题，”Aitken说，“然而，如果你能 够迅速推出服务、改变服务，以及关闭服务，因为不理想甚至失败服务而投入的无用成本问题将大大减弱。我们已经在为一个3G运营商搞一个服务重组的项目，最 终要获得在4分钟内重新组合服务的能力。从根本上说，是IMS改变了运营商思考的方式。”

谁对IMS有兴趣？

在大多数宣布实施IMS的运营商中，真正应用业务的案例并不多。在欧洲，最值得注意的IMS服务，可能属意大利移动电信（Telecom Italia Mobile）所推出的视频共享业务了，该业务中使用了诺基亚工具套件（Nokia kit）；而另一家运营商西班牙Telefónica，则使用了爱立信提供的IMS解决方案，该方案可以为固网用户提供各种各样的服务，包括针对商务用户 的IP Centrex业务。


IMS方案提供商们表示，固定运营商和移动运营商们都对IMS有着极大的兴趣，而且使用IMS，无论是固定运营商还是移动运营商，都可以提供综合服务，之所以没有宣布很多的实际部署消息，是因为它们和运营商签署了保密协议，不能公布这些客户到底是谁。

“运营商对IMS感兴趣，这在2005年就已经是一个热潮了，”北电的Day说，“12个月前，我们就从移动运营商那里获得了很多的RFO，它们的主要目 的是看一看IMS架构是否真的能够使用；六个月前，我们发现，固定运营商开始对IMS表示出极大兴趣，无论是独立的固定运营商，还是处在大型电信集团之 中、但是独立运作的固定运营商，它们渴望能够实现固定、移动融合的业务；现在，我们看到，移动运营商开始寻求如何借助IMS深入到固定领域，以获得该领域 的商业客户。”

在Heath看来，业界正在关注英国电信的融合服务（the BT Fusion service）。“如果这个品牌服务能够顺利推广，IMS应用将会迅速地被更多的独立固定运营商采用，并且更多的是用于增强UMA （Unlicensed Mobile Access非授权移动接入）服务的竞争力。”Heath说。“但是如果UMA无法奏效，那么IMS将在很大程度上依靠移动运营商来驱动发展。”UMA技 术可使GSM/GPRS手持终端在蜂窝网络和一些非授权频谱网络（例如蓝牙或Wi-Fi）之间进行无缝切换。

寻求固定移动融合只是英国电信融合服务业务的发展方向之一。更重要的是，如果一个固定运营商本身就是电信大集团的一部分，而大集团又同时拥有固定和移动网络的话，那么两网络的业务融合就成为了战略问题。当然，英国电信因为不运营移动网络而无需面对这样的问题。

“如果你是一个综合服务提供商，而且你想要在移动通信市场的竞争中保留一席之地的话，那么你就必须跟随潮流，并且保持移动业务具有竞争活力。而固定运营商则至少需要力争保持住宽带接入用户的数量。”Heath说。

Heath认为，运营商对不同网络之间协同工作能力的顾虑，以及对IMS方案价格透明度的担忧，有可能成为影响IMS部署进度的潜在因素。“目前IMS方 案提供商的出价，往往是根据服务涉及的网络容量、节点数量，以及用户量等几个方面，”他说，“如果用户量小的话，10万用户量的支出可能不是什么大问题； 但是如果业务真的迅速扩张的话，上千万的用户就会使购买成本变得相当重要了。”对于一些运营商而言，如果它们部署IMS的主要目的并不是用于增加收入、而 是用于降低支出成本——因为消费者可能会对由于电信业务种类增加而支付更多费用对运营商进行抵制——如此一来，按照以上方式购买IMS带来的问题将相当棘 手。

可是Aitken对于IMS的商业模式显然相当乐观。“我们有独立而精确的IMS的商业模式工具，可以肯定的是，IMS能使总成本降低。”他说，“很多运 营商对于方案提供商所允诺的‘新业务增长点’能够实现与否通常会抱以怀疑态度，这也是可以理解的，所以，运营商通常的第一诉求并非新的增长，而是降低成 本。但是一旦成本节约能够获得满足，运营商们便又开始要求盈利了。

事实上，电信运营商们对于IMS方案提供商们最大的希望， 从本质上来说，就是不要“吹牛说大话”。

直击IMS的NGN网络架构的移动核心网演进细节

移动通信网在经历了两代发展之后，目前3G标准已经成熟，并在一些国家商用。3G的目标是为用户提供质量更佳的移动话音、宽带移动数据和移动多媒体业务，提供更大的系统容量和更高的频谱利用率，满足人们对通信个性化的需求。
　　作为主要3G网络技术之一，WCDMA是对GSM/GPRS网的演进和升级，WCDMA的标准由3GPP制定，目前已有R99、R4、R5、R6版本完成定稿。
　　R99在无线接口引入了新的频率、新的无线技术，但在核心网络方面则保持了2.5G的GPRS引入后的网络架构，仅需升级支持3G的功能和2G、3G协同工作。
　　 WCDMAR4版本与R99相比，在分组域方面基本没有变化，主要在电路域实现了承载和控制分离，以及支持承载多元化：1)控制和承载相分离：原来的 R99MSC拆分为MSCServer和MGW，控制面MSCServer可以大容量、集中设置，承载面MGW则适于分散设置、靠近用户，这种架构具有很 好的可扩展性。
　　2)承载多元化：支持多种灵活的组网方式(IP/TDM/ATM)，特别是MGW的媒体流支持IP承载可实现全网MGW扁平化。另外通过TrFO(免编解码协商)等技术的应用，大大节省了对传输资源的需求。
　　随着R4网络和技术、设备的逐渐成熟，R4网络在很多国家已成功商用。3G牌照发放之后，我国的WCDMA3G技术应用将基于R4版本。
　　从全球移动业务需求发展来看，移动业务的需求除在语音通信外，更加倾向于数据类业务，可预见未来移动数据业务仍有着巨大的发展空间，数据业务需求的满足是未来移动核心网演进发展的动力所在。
　　与固定宽带网络相比，现有移动核心网在业务实现方面主要有以下差别：
　　1)接入带宽：2.5G的GPRS网络实际接入速率不到100kbps，与目前普遍应用的固网宽带接入方式ADSL、至少512kbps的接入带宽相差甚远，接入带宽限制了媒体流下载、视频交互等一些宽带型数据业务在移动网中的发展。
　　2)业务提供模式：现有宽带网络不仅可以提供端到服务器的数据业务(如网络浏览、资源下载等)，近年来一些端到端类的业务(QQ、MSN、网络互动游戏等)也得到快速发展，现有移动网络数据业务提供基本上是端到服务器的方式。
　　根 据以上分析，接入带宽的提高和业务实现模式的改进将是未来移动网络的演进目标。随着无线侧一些新技术(如HSDPA)的应用，WCDMA网络的接入带宽瓶 颈问题将会得到解决。而IMS在核心网的引入，会增强运营商对数据业务的控制能力、为用户端到端业务类型提供完整的Qos保障，对现有移动网络的业务提供 模式来说将是一次巨大的变革。
　　IMS最初由国际移动标准化研究组织3GPP在R5规范中提出，继R4实现了3G核心网的全IP承载实现后，IMS的提出为移动网络中IP多媒体业务的实现提供了一套完整的解决方案。
　　从移动核心网演进来看，以R5IMS框架结构为基础、支持多种固定、无线接入方式是其长远演进的趋势：3GPP在WCDMAR6阶段增加了WLAN的接入方式，并预计在R7版本中增加对xDSL接入方式的支持。
　　固 网方面，NGN是未来网络发展的目标。国际标准组织ETSITISPAN重用了3GPP定义的相关规范，采用IMS作为核心控制，提出了基于IMS的 NGN网络框架结构，包括除IMS外的资源和接纳控制子系统(RACS)、网络附着子系统(NASS)、PSTN/ISDN仿真子系统(PES)等。
　　随着用户业务需求及技术的发展，未来网络发展趋势将是基于固网和移动的融合网络。IMS将成为基于SIP会话的通用平台，同时支持固定和移动的多种接入方式，实现固网和移动网的融合。