if we build it, will they come

Consider the instant messaging landscape in 1999. ICQ had blazed a narrow trail through a small community, and AOL Instant Messenger was the dominant player (carrying over 430 million messages a day). Yahoo was making good headway, and even Microsoft was throwing their hat into the fray with MSN Messenger.[*] All four major systems used proprietary, non-interoperable, unpublished protocols. AOL was engaged in a war with what they considered "rogue" clients, vigorously blocking any attempts at interoperability.

The entrenched players had little interest in a standard protocol. Only Microsoft -- the upstart -- was promoting the concept of a standard protocol.

In the intervening 8 years, XMPP and SIMPLE have gained significant market and mind share, and it's not hard to imagine eventual interoperability between every viable instant messaging system within the next decade or so.

It's the same curve followed by just about all popular communication technologies: proprietary versions emerge first, and prove that the market exists. Eventually, a standardized protocol for the technology is defined, and the market slowly migrates to the standard. (To see how this plays out in a longer timeframe, consider the slow but complete migration of email from isolated, proprietary islands to fully-interconnected standards-based servers over the past 25 years).

That's what XCON is doing for conferencing. I understand that it's hard seeing the curve from this end, and it's difficult to imagine what impact we might have over the next 5, 10, 20 years. But it all needs to start somewhere, and we think this is as good a start as we can come up with right now.

/a

[*] Yes, there were important predecessors in spirit, like zephyr, talk, and their ilk. I'm trying to stick with the UI modality represented by currently popular instant messaging systems.

P2P占全球夜间95%网络带宽

据国外媒体报道，德国一家研究机构日前对全球互联网流量分布进行了研究。该机构发布的报告指出，Skype软件的流量占据了VOIP流量的95%，另外夜间带宽的95%被P2P应用所消耗。Mitbbs.com

这家机构名叫iPoque，据称他们研究了一百多万网民将近3TB的匿名数据流量，调查地区包括澳大利亚、东欧、德国、中东和南欧地区，时间是今年八月份和九月份。Mitbbs.com

调查发现，网络电话占据了互联网流量的1%，而在网络电话中，Skype软件一家就占据了95%。另外，虽然网络电话的流量并不大，但是全球三成的网民经常用网络电话软件和亲朋好友聊天。Mitbbs.com

这家研究机构指出，Skype的成功，主要是它能够穿越防火墙、网络地址转换设备以及其他障碍，普通的网络电话软件对于这些障碍无能为力。Skype具有内置的多种机制，能够自动绕过这些障碍。Mit

报告指出，目前网络带宽“消费大户”是P2P文件共享，在中东占据了49%，东欧地区占据了84%。从全球来看，晚上时段的网络带宽有95%被P2P占据。Mitbbs.com

在所有P2P工具中，BitTorrent最受欢迎，在南欧地区，电驴处于主导地位。在P2P内容方面并未和去年发生变化，主要还是视频，最受欢迎的是最新上映的电影、色情电影和音乐。其中在中东，电子书在P2P内容中比例较高，计算机游戏在南欧地区比例较高。Mitbbs.com

这家机构还说，20%的BitTorrent和电驴的数据流量进行了加密，以免遭到网络运营商的封杀。

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会话的通用平台，同时支持固定和移动的多种接入方式，实现固网和移动网的融合。

IMS与软交换网络（包括R4移动软交换和固定软交换网络）之间的关系

IMS与软交换网络（包括R4移动软交换和固定软交换网络）之间的关系：
1，IMS与R4移动软交换的关系
移动软交换网络在多媒体业务的体系架构支持、业务管理、业务触发等方面存在不足，因此R4软交换网络不可能成为固定移动融合网络的目标架构。相比之 下，IMS体系架构可以进一步推动网络向IP化、移动性、多媒体化和个性化方向发展，可以将固定和移动网络融合在一个统一的基于IMS的核心网络之上。
IMS定位于多媒体业务的提供，而移动软交换定位于传统的电路交换业务的提供。IMS的目的是为了引入更丰富的业务，扩大运营商的收入来源，而移动软交换的目的是为了节省网络的投资成本，灵活部署网络设备。
IMS是未来固定移动网络融合的目标架构和演进方向，而R4从长远来看将融合于这个基于IMS的目标网络架构。
IMS叠加在PS域之上，与移动软交换之间没有依赖关系，然而，由于短期内IMS还不能提供实时的语音/视频业务，还必须依赖R4移动软交换提供实 时业务。因此，IMS和R4移动软交换在未来的一段时间内还将长期共存。然而，当IMS能够提供实时业务以后，R4移动软交换将会逐渐地完全被IMS网络 所替代。
2，IMS与固定软交换的关系
固定软交换采取主从控制方式，是全网智能和控制中心，主要关注具体设备形态、功能、协议，全面提供PSTN相关业务和简单SIP业务，网络体系与接 入方式相关，固定和移动不同；IMS 结合了互联网和电信，终端和业务层是网络的两大智能中心，关注逻辑网结构和功能、控制层统一架构，尚不能支持所有的PSTN业务，主要提供基于SIP的宽 带多媒体业务，与接入无关。
尽管对业务层和控制层进行了一定程度的分离，但软交换设备和业务层之间并没有彻底分离，用户数据库没有完全独立，业务层和控制层之间的接口没有标准 化。这些都影响了固定软交换网络上多媒体业务的开展。因此，固定软交换网络只是对传统PSTN设备的替代，只能提供简单的传统的PSTN业务，固定软交换 也不能担当固定移动融合网络的重任。
IMS网络定位于创新的多媒体业务，同时也能提供大部分的传统的PSTN业务。而且， IMS网络是固定移动融合网络的理想架构，是未来网络演进的目标，而固定软交换网络只是这个演进过程中的一个阶段。但是固定软交换网络这个阶段并非 不可逾越，由于IMS网络不仅能够提供多媒体业务，也能提供大部分传统的PSTN业务，因此运营商也完全可以越过软交换网络而直接部署IMS网络。

IMS发展困扰与趋势篇

IMS发展困扰

　　固定、移动综合运营商希望通过统一的IMS核心网接入固定和移动用户，对WCDMA与WLAN的语音切换业务十分关注。但目前IMS的融合应用还处于实验阶段，具体的应用模式还不十分明朗，将IMS引入固网还有很多问题尚未解决。

　　(1)IMS距离完全继承PSTN网络能力提供PSTN业务还有相当的距离，IMS接入窄带用户提供PSTN仿真业务的能力还处于研究的初始阶 段，支持ISDN业务、V5接入等传统PSTN接入方式还没有开始研究，因此IMS距离完全继承PSTN网络能力提供PSTN业务还有相当的距离。

　　(2)用户接入问题。IMS并没有实现完全的与接入的无关性，由于有线与无线接入方式的不同而导致传输带宽的不同，无线接入方式由于带宽资源有 限所以要求P-CSCF支持SIP的压缩，而对于有线接入方式则没有这种要求。因此不同接入方式对于IMS的功能实体的要求有所差异。现有ADSL接入网 络离NGN对接入网的要求还有相当的距离。

　　(3)融合数据库，提供融合业务的重要技术条件是具有丰富的用户数据，应探索融合数据库的体系架构。

　　(4)SIP协议能力扩展后的兼容性。如果IMS同时支持固定和移动用户，需要支持固定和移动不同能力级的SIP协议，并且要求IMS网络能够识别终端的接入方式，根据不同的接入方式选用不同的协议参数。所以对于扩展的SIP协议要注意与原有SIP协议的兼容问题。

　　(5)业务平台的整合，需要理清IMS的业务平台与现有业务平台的关系。从长远来看，融合业务和基于SIP的多媒体业务应在IMS的业务平台来提供。

　　(6)业务定位，需要明确和定位什么多媒体业务需要在IMS架构上开放，什么业务在IP网上提供。

　　从技术角度看，IMS发展还面临五个方面的问题。

　　(1)网络融合必将会带来功能的复杂。技术上，IMS为网络融合提供了基础，但是由于移动接入方式和固定接入方式在终端、接入网络以及资源调度 方式上存在一些差别，这将导致IMS域功能实体的功能需要作相应的扩展，接口以及所采用的协议也需要相应的修改。新的接入方式的引入，必然要对核心网络 IMS提出新的要求，这也使得IMS网络的功能变得更加复杂。

　　(2)IMS技术还不够成熟稳定。由于基于IMS的网络融合的研究刚刚开始，技术上还不够成熟稳定。从标准上看，虽然ITU-TFGNGN、 3GPP、TISPAN都已经确定了IMS作为NGN的框架，但是如前所述，很多网元和接口的功能需要增强或修改，目前标准组织的活动还处于功能需求的研 究阶段，实现这些功能的流程、消息及参数还需要具体的规范定义。

　　(3)产品的开发还不能满足大规模建网的需求。从产品的开发看，虽然目前国内外主流厂商都在进行IMS产品的开发，受到标准进程的限制，目前的产品还只是针对IMS某些应用，还不是完整意义的IMS网络产品，还不能满足运营商大规模建网的需求。

　　(4)QoS还不能保证商用需求。此外，QoS也是IMS需要重点考虑的问题，它决定了网络是否可以满足商用需求。网络的QoS是端到端的服务 质量，由终端、接入网络和核心网络共同保证。在IMS的框架下，核心网络的信令和数据都基于IP承载，而IP网络的QoS问题一直是困扰业界的一个问题， 目前3G核心网也只能采用IP网络中通用的办法来改善QoS，例如DiffServ、MPLS等技术，所以3G核心网络的QoS有赖于IP网络QoS。

　　(5)安全机 制还有待完善。在网络安全方面，IMS已经定义了相应的安全机制，主要包括IMS鉴权和SIP消息的保护，分别通过AKA机制和逐段对SIP消息进行加密 和一致性保护实现。移动终端接入IMS之前已经进行了相应的鉴权，所以安全性更高一些。但是对于固定终端来说，接入网络没有任何防范，所以IMS的安全机 制显得尤其重要，关于IMS的接入安全的规范还在不断完善之中。

　　IMS发展趋势

　　IMS是未来网络的整体架构，其体系架构增强了对基于IP流的可控和可管理性，代表了网络的发展趋势。但目前IMS正处于技术发展的初级阶段， 并未规模商用，因此预计固网运营商将从2007～2008年引入IMS。IMS的引入与接入、承载、控制、业务、支撑等网络的各层面相关，同时也对终端改 造、宽带的发展策略、运营模式带来挑战，因此各运营商需因地制宜地根据需求加以选择。实现融合是一个长期的目标，涉及的因素很多。IMS只是在网络和业务 层面提供了融合技术的可能性，但还需要认真研究其可行性、经济性、复杂性和可管理性。

　　IMS的发展趋势要从网络、终端、应用等方面来看。网络向融合化、安全化、可靠化、易互通、易提供业务等方向发展，IMS系统需要进一步拓展， 如VCC、CSI、QoS以及IMS用于固网和宽带接入等，以适应一些新的应用场景。未来可能出现的IMS终端，将从接入方式，终端形态上看会有多种发展 方向。除了普通的移动终端，将来会出现智能PDA终端、无线数据卡以及SIPIAD型固定终端等，在接入方式上除了WCDMA、EV-DO之外，还会有加 入Wi-Fi的双模终端。应用方面开始从单一的传统继承类应用向融合的、多媒体应用发展。

全球IMS产业链发展分析篇

IMS在全球

　　尽管IMS技术规范的讨论和制订开始较早，但可运行的3GPPR6版本是在2004年底才发布，运营商完全意义的IMS测试也是在2005年才 开始。目前世界各地声称的众多的IMS案例，大多数是基于移动PS的PoC应用（这些PoC案例并不是完全遵循IMS/OMAv1.0，而是基于 SIP/Pre-IMS应用），或是些基于SIP的应用或体系，真正符合IMS架构的案例非常少。具体的，可以将这些IMS及应用的案例分为以下4种：端 到端IMS案例；带有部分IMS网元的案例；基于Pre-IMS上的应用（如PoC，IM等）；与SIP/IMS相关的（包括NGN）等。

　　基于对新业务开发快速推广、优化网络结构及资源建设的需求，全球许多运营商积极联合设备供应厂商，共同推动IMS的开发。

　　2004年以来，全球多个运营商都宣布基于IMS的策略。2004年日本NTT、日本电信、韩国电信、巴西电信等运营商成立FMC联盟，志在推 动、推广固定电话和移动通信的联合经营模式。目前IMS已经被一些运营商视为下一代网络的重要网元，它不仅出现在日本KDDI的“Ultra3G”、美国 Sprint的EV-DO等移动运营商的3G以及未来网络的架构中，而且开始在固定及全业务运营商的NGN中占据核心位置，如BT的21世纪网络、NTT 的下一代网络、KT的BcN宽带融合网络。

　　越来越多的运营商开始接受IMS，特别是最近的几个月以来，不断有运营商开始试验和部署IMS网络的新闻，除Sprint、Cingular等 移动运营商外，Verzion、AT&T、英国电信、法国电信等等固网运营商及全业务运营商也开始试验与部署IMS。据信产部电信研究院信息所统 计，截止到2006年3月，开始试验和部署IMS的运营商有英国电信、法国电信、英国MMO2、芬兰Saunalahti、美国Sprint、意大利 TIM、西班牙Telefonia、丹麦TDC、澳大利亚COMMANDER、北欧TeliaSonera、印尼Telkomel、葡萄牙TMN、美国 Cinglar、AT&T、Qwest、BellSouth、荷兰KPN、美国Verizon、日本NTTDoCoMo、 VodafoneGroup、芬兰Telenor、巴西电信（按时间顺序排列）等22家运营商。而据此前在2006年2月Lightreading公司对 来自全球60个网络运营商实施IMS的计划的调查来看：已有8％的运营商在部署IMS，超过60％的运营商将在2007年年底之前开始部署IMS，19％ 的运营商在2007年之后部署IMS。这表明，IMS的大规模部署将在2006～2007年，而真正意义上的固定融合（FMC）业务的大规模商用将在 2007年之后。事实上，全球大部分商用的IMS网络都处于初级阶段，由于市场中的诸多因素，IMS是被运营商强力推上了前台。

　　进入到2006年，设备制造商也都持续对IMS表示非常的热心，IMS一方面是运营商为提供下一代服务在基础设施方面的战略步骤，另一方面又为设备供应商带来新的创收机会。目前，推出了IMS商用解决方案的设备商有爱立信、诺基亚、西门子、北电网络、中兴、华为、朗讯、NEC、索尼爱立信等 多家公司。实力最强的是朗讯、爱立信、诺基亚和西门子。截止到2006年3月，爱立信、朗讯、西门子和诺基亚等多家设备厂商均已签署了多个商用和测试合 同，其中，爱立信52个，朗讯39个，诺基亚7个，西门子4个。范围遍及美洲、欧洲和亚洲，涵盖了GSM/GPRS、WCDMA、CDMA2000以及有 线网络，并涉及一系列丰富的应用，如一键通（pushtotalk）、组合服务（combinationalservice）、IP语音电话和IP Centrex。

　　此外,为了加速IMS的部署，一些组织和运营商开始筹划全球性IMS互操作试验,预计在2006年10月,将由多业务论坛(MSF) 组织一个跨越3大洲的IMS互操作测试,这个互操作试验被称为GMI2006,全球5家顶级的运营商BT、KT、NTT、Verizon、 Vodafone以及众多设备厂商将现场演示IMS融合的实施和解决互操作问题。GMI2006将使用来自BT、KT、NTT、Verizon、 Vodafone的试验设施，并把这些试验用有QoS保障的全球IP网络连接起来。在技术层面，GMI2006将集中在3个问题上:多级数VPN的配置 (站点之间)、VoIP/IMS增值业务的配置和故障管理。

　　尽管如此，IMS的部属将是一个复杂的、长期的过程。从目前的情况来看，移动业务提供商已成为提供基于IMS应用的先驱者，而第一个利用IMS 实现真正固定移动融合的将是固定线路运营商，这主要是由于固定线路运营商面临着较移动运营商更为严重的ARPU危机，业务创新的需求更加迫切。

　　IMS在中国

　　从设备的开发看，国内外主流厂商都在进行IMS产品的开发，也提出了明确的产品计划。这些计划能否按计划实施，很大程度上受到标准进程市场需求的限制，2006年应用于移动的IMS设备可以投入商用，应用于固网的IMS设备将会更晚些。

　　2004年以前,由于国内厂商一直在积极投入R4软交换的建设,对于IMS方面并没有过多关注。此外，由于3G牌照和重组等其他原因，国内运营 商对固定移动融合的需求也不是很强。因此IMS在我国的进展并不大。进入2004年，由于国际电信运营商纷纷调整其战略规划和IMS标准制定的快速发展， IMS才真正开始在我国获得广泛关注。目前，我国的设备厂商在IMS的商用产品上进展迅速，如华为和中兴都纷纷推出了基于IMS的解决方案和支持平滑演进 的Pre-IMS软交换解决方案。基本上都能支持移动CS和IMS融合业务以及PSTN与融合业务。但与国外厂商相比，我们还处在应用的初级阶段。此外， 目前一些国内厂商在发展IMS时，更多的是考虑运营商现阶段的业务需求，并没有考虑其长远发展的目标。加上此前对R4软交换的大量投入，使得目前的国内厂 商更多的是考虑平滑演进的方案，即先做R4软交换，然后把IMS作为下一步发展的重点。随着IMS研发进程的深入,预计到2006年下半年，会有更加完善 的IMS方案出台。此外，由于在IMS领域的先天不足，一些国内厂商也纷纷开始加强与国外厂商的合作，如大唐已与朗讯建立联盟关系，这在一定程度上能够帮 助加速国内厂商对IMS的研发进度，同时也能够改善国产标准TD-SCDMA在IMS上的不利位置。

　　总体来说，在基于3GPP的R5标准的IMS产品研发上，中国电信设备制造商的研发进度与国外先进厂商（爱立信、朗讯等）相比还是有较大差距。 此外,结合运营商试验情况来看，国外厂商在IMS的研发投入和市场切入方面也比国内厂商领先。如朗讯、爱立信等国外厂商都依靠国际市场上的成功商用经验和 技术领先优势,在国内运营商的试验中获得一致好评。同时，随着国外厂商大举进攻中国3G市场，不少厂商已经在国内建立研发中心并与国内设备厂商达成了联盟 合作关系，这将使得我国今后的IMS商用产品市场的竞争将日趋激烈。国内厂商也不是没有优势可言,虽然国外厂商在引领技术方面确实比国内厂商更胜一筹，在 满足国内运营商阶段性需求而言，国外厂商还是稍稍逊色，如软交换过渡到IMS的解决方案方面。

转型时期的NGN战略

转型时期的NGN战略

近日，2006全球NGN高峰论坛在京召开，本届论坛以“转型时期的NGN战略”为主题，围绕转型时期的NGN技术发展路线、技术标准动态、网络演进策 略、产业管制政策等内容，深入探讨转型时期全球电信运营商的NGN推进和实施策略、中国NGN产业的发展和管制政策、国际NGN技术标准最新进展和设备成 熟性等备受关注的主题。以下为参会专家的部分精彩发言。 娄勤俭：三网融合发展的必然趋势 　　娄勤俭副部长代表信息产业部对论坛的召开予以了热烈的祝贺。他在发言中提及到了通信网、互联网和广电网的三网融合问题。“十六届五中全会明确提出了，要加强宽带通信网、数字电视网和下一代互联网等基础设施建设，推动三网融合，健全信息安全保障体系。” 　　娄勤俭认为既要注重电信网、互联网、广电网三网原来独特的强势技术的进一步拓展，另一方面，还要注重三网融合发展的必然趋势。“这三种网络的发展使三 网融合从技术上来讲，是一种必然的趋势，因此，这三种强势集合如何能够集成起来发展，来保证淘汰掉自己本身的弱势，而把强势的技术融合起来，在这里能够出 现集成创新的成果。技术的发展，一方面要强调技术的独立性，也要考虑未来发展的融合性。”娄勤俭说。 　　在谈及对NGN的看法时，娄勤俭表示:“我们开发和研究NGN的目的，最终实现的是为用户提供满意的服务，因此，要注意到计算机、通讯、消费电子的集 合，满足用户的方便性。因此，在NGN研究的时候，必须考虑技术的相互融合，来提供用户的方便性。另一方面，要注意信息内容、网络和服务相互的结合、融合 的发展，来满足用户多样性的需求。” 　　“要通过机制、体制的创新，集合多种资源，充分、有效地利用NGN来促进经济的发展。因此，从技术到运营，到为经济的服务，满足用户的要求，是一个有机的整体。全面的考虑，研究未来下一代网络的发展，这是我们面临的一个根本的问题。”娄勤俭说。 侯自强：用颠覆性技术发展NGN 　　目前，NGN/IMS提出的主要业务是IM、语音和视频，不过，语音和视频业务都受到了来自颠覆性技术P2P的挑战。“P2P Skype在挑战VoIP，P2P Internet TV在挑战IPTV，那么P2P SIP能否挑战IMS。”侯自强说。 　　IP多媒体自系统IMS是目前业内实现下一代网络的一个基本共识。“P2P和SIP的结合，现在提出一个挑战，在IMS的结构下，我们可能还存在另一 条路，在公共的互联网上架构一个重叠网，提供一个P2P环境和P2P SIP的平台，就是提供一个分步管理系统。如果建成这个系统，同样也可以达到NGN今天所提供的目标，但完全是不同的结构。从客户机服务器模式转向P2P 是颠覆性的。”侯自强说。 　　SIP(Session Initiation Protocol)是由IETF定义，基于IP的一个应用层控制协议。由于SIP是基于纯文本的信令协议，可以管理不同接入网络上的会晤等。会晤可以是终 端设备之间任何类型的通信，如视频会晤、既时信息处理或协作会晤。该协议不会定义或限制可使用的业务，传输、服务质量、计费、安全性等问题都由基本核心网 络和其它协议处理。 　　侯自强指出，P2P用于 VoIP很有效，既可扩展又不需要配置，而P2P SIP基本运行容易。所以，他认为在IP网上架构重叠网P2P对实现NGN会更有效，“通过重叠网实现各种IP知识平面，将IP推到层3-，重叠网为3 +，可以灵活实现各种先进业务。这也是实现NGN最现实而且发展最快的。”侯自强说。 何宝宏：NGN与NGI理念差异将长期共存 　信息产业部电信研究院通信标准研究所IP与多媒体研究室主任何宝宏在发言中表示:“NGN与NGI理念存在差异，但是将长期共存。”这一观点不同于以往 “NGI是NGN重要组成部分”和“NGN是互联网的一部分”的观点。何宝宏表示:“NGN的关注点是IMS、FMC、QoS，而NGI则是安全、 IPv6、WEB2.0以及P2P等。这两种技术的理念是相碰撞的。” 　　何宝宏进而解释道，NGN和NGI碰撞的理念体现在业务与承载的分离是否面向用户，是否区分消费者和提供者等各个方面。“如果从商业角度看，NGN和NGI在开放接口、对外业务创新空间、收费的主要层次、收费理念都存在差异。” 　　不过，何宝宏在最后指出，鉴于NGN与NGI在安全性和多业务需求等各方面的共通性使得NGN和NGI将和平相处，进而将长期共存。 雷震洲于NGN峰会谈从GENI得到的启示 信息产业部电信研究院科技委副主任雷震洲谈到了从GENI得到的启示。GENI的全称是Global Environment for Network Investigation，是“全球网络调研环境”的行动计划，于2005年8月22日正式公布。GENI将在NSF下属的美国计算机与信息科学及工程 (CISE)理事会凑筹划，准备投入3亿美元，花5-7年的时间完成。 　　GENI包括两大部分。一个是研究计划research program，另一个是全球实验设施。这个设施就是为了确保计划的完成设置的平台，主要是用来有规模性的开发新的网络体系结构的平台。 　　据雷震洲的分析，随着全球ICT的复苏，互联网继续保持快速发展的势头以及互联网安全性、管理鲁棒性和经济持续性的弊病之间的不断冲突，使得美国人要 做GENI。“美国信息咨询委员会得到一个结论，认为互联网的情况正在变糟，美国目前的信息基础设施非常容易受到预谋的攻击，可能造成灾难性的后果。现在 在美国形成了一个主流意见，就是要创新思考互联网基本体系结构，要采用新的设计理念。”雷震洲说。 　　在谈及从GENI得到的启示时，雷震洲表示:“GENI是一项由政府主导的重大网络创新行动，不仅是技术创新，而且体系结构也要创新。实际上GENI 是一个专门定义互联网将变成什么的新的科研项目，美国的目标是研发新的体系结构，大大提高网络与分布式系统的体系结构所提供的能力，以应对21世纪重大而 紧迫的挑战，推动科学发展，刺激创新和经济发展。” 　　雷震洲认为，美国的行动计划，名称上既没有挂上NGI，也没有挂上NGN，但是它明确地指出了要解决的问题。只有这些问题解决之后，网络就可以健康持 续发展。作为一个政府主导的项目，应该集中力量对这些问题进行攻坚。这些问题攻下来以后，不管NGI也好，NGN也好，或者将来的融合网络也好，它的成果 都是可以应用的。 　　另外，GENI强调继承性。GENI的行动计划建立在过去20年NSF所支持的网络研究基础上，以及许多研究机构的广泛实验的基础上，它的研究将基于 多年的经验和知识。GENI设施也将利用现有的网络试验床中很好的概念和能力，要对这些进行进一步的扩充和提升，设施要达到的目的，所提供的环境中可以尽 量部署多种新的网络体系结构与服务，对设施所提供的能力尽可能没有限制。 　　“GEN既存在风险，又存在着成功的希望。这个项目是鼓励研究人员重新考察，重新发明，合成新的体系结构，构建新的服务应用，鼓励使用者广泛地参与。 换句话说，它是一种解放思想、放开手脚、创造未来的模式。网络具有很大的创新空间，也是我们增强自主创新能力，建设创新型国家必须要涉足与拼搏的一个领 域。但是另一方面，我们也要密切关注GENI，因为它是一个开放性的项目，如果有可能的话，我们就要参与其中，对我们的创新只有好处，没有坏处。”雷震洲 说 闻库:NGN受服务驱动要满足用户个性化多业务需求 信息产业部科技司司长闻库对下一代网络NGN的动因、目前的瓶颈、中国特色以及在中国下一代网络面临的问题、研究方面的重点等方面进行了简要的概述。 　　闻库在发言中表示，我们的用户是NGN最终需求的驱动力。特别是上网人数增加，用户需求的提高。技术进步给NGN的发展带来了可能。“NGN是受服务 驱动的，要满足用户所要的越来越多的不同的有个性化的各种业务和应用，NGN本身应该支持业务的多样化，包括语音、数据、多媒体。同时，也应当支持业务的 个性化和业务的移动性、开放性和灵活性。”闻库说。 　　除了从用户的角度分析NGN外，闻库还特意提及到了中国在NGN方面的机遇。“首先就是NGN国际标准的不确定性，所以这对中国是一个机会，也是一个挑战，为我们提供了跨越式发展创造条件。” “在NGN的研究当中，我们在国际上的标准组织中，有可能有一个崭露头角的机会，提供出我们自己拥有的原创性知识产权，一旦形成一些标准，就有可能使中国 在通信网技术上实现跨越式发展。“闻库说，“另外，我们还很高兴地看到在国际标准组织当中，我们中国人也为世界做了很多贡献，比如研究组副主席、报告人、 起草人，很多都是由中国的企业代表国家为全世界服务，为全世界的标准提供好的建议。” 龚双瑾：NGN要实现网间号码携带业务 信息产业部电信研究院首席专家龚双瑾在现场的演讲中指出，号码携带是国际上的发展趋势，消费者的角度来讲是非常需要的业务。而NGN也应该考虑号码携带业务，提供标识的携带。她表示，在下一代网络中不仅要实现网内的号码携带，而且要实现网间的号码携带。 续合元：我国FMC策略不是逐步演进 而应有计划实施 信息产业部电信研究院通信标准研究所总工续合元就我国NGN发展策略中的FMC思考进行了主题演讲。“在未来的NGN网络当中，可以实现固定和移动的融 合，在IMS的架构下。对于我们国家来讲，这种融合并不是把所有将来的窄带网用户、宽带用户都捆绑在一个IMS网络上。”续合元说。 FMC从广义范围讲是业务综合和网络融合。狭义的谈融合，实际就是指未来的网络融合。“对于我们国家FMC的研究重点，现在谈的综合概念或者业务综合的方 法，都是出于目前市场的需求，或者市场业务的需求提出来的。长远来讲，FMC应该考虑增强性的网络上融合类似移动和固定网的网络能力，向用户提供业务。” 续合元认为，FMC应该是一种长远的战略。目前固定、移动从业务驱动来讲，有很多种融合的方式和技术。但是，从国家的战略或者运营商长远的战略来讲，应该 考虑的是长远战略，“如果我们要考虑IMS架构上移动用户和固定用户的统一接入，这个方式就应该尽早地启动。一旦IMS网络部署之后，很难在网络上把固定 接入进去，实际操作的时候网络不可能不感知接入，IMS长远的战略，从标准的战略，从网络技术的研究来讲，都应该及早地实施。”续合元说。 同时，续合元还指出，FMC应该有计划的实施，而不是逐步地演进。“也可能有人认为软交换能够平滑地演进到未来的IMS，但是这种方式从产品的角度实现， 对一个厂家来讲，确实在一个产品平台上尽可能实现提供软交换的方式，在未来提供IMS的网络架构。但是从运营的角度来讲，不可能指望软交换网络能够平滑地 演进到未来的IMS。IMS应该有计划地在何种平台何种网络上考虑FMC。” 最后，FMC的管制问题也被提出。续合元指出既然固定网和移动网融合在一个网络上了，将来从管制的角度有没有移动业务和固定业务之分?将来如果不分移动业务、固定业务，是不是用户在有线的环境和无线的环境下，计费方式都是一样的?“这些都需要我们的研究。” 赵慧玲：运营商的思考 中国电信北京研究院副院长赵慧玲指出：现在运营商都在讨论电信网的转型，从传统电信的发展来看，是用信令控制承载、控制流量，现在新的业务增长方式，包括 呈现业务，像MSN上用户不在线，包括定位，在哪儿，跟各种各样行为相关的话音，不同业务的捆绑可能会承重新的形式，所以从传统单业务的提供变成多种业务 的协调，然后相互的交互，通过网络来保证这样的服务质量，这可能是业务发展重要的趋势。我们觉得是电信的技术和IP技术的交融，这是目前非常重要的，特别 是在电信转型领域的重点。 　　国外数据的统计，可以看到我们的时代，像美国，因为拥有一件移动设备的人口占美国总人数70%，网络的数量600B，宽带家庭占因特网用户比例大于 60%，每天增加Skype用户数155K，给我们的感觉，现在的时代是数字媒体的时代，面对这样的情况，传统运营商应该怎么来做?一些典型的例子，看国 外运营商在网络转型过程中是怎么做的，西班牙电信满足不同用户的需求，家庭用户、中小企业用户、大型用户，不同的客户群针对不同的需求提供相应的服务，比 如家庭用户进行宽带、话音固定的通信，和宽带数据的通信捆绑，中小企业专线、NPN，大企业会根据客户不一样的需求提供整体的解决方案。 　　德国电信，主题通过捆绑融合来实现业务的再造。同样也能够提供提供单一、融合的帐单，一个通讯录比较方便简捷。法国电信，把固网、移动、宽带，包括家 庭业务的融合，商业业务的融合，进行相应的捆绑。从整体的发展趋势来看，运营商业务的组合和融合的捆绑，成为提供业务运营商关注的主流趋势。这张图是提供 全业务的网络架构，比较类似于整个NGN的体系结构，NGN的体系架构有业务的子系统，把几大业务主流，话音网的仿真的，流媒体，外部业务，四大业务基本 上是分别提供的，未来的长远发展趋势把业务的相互组合、相互融合变成一些融合、创新性的业务。总体来看，国外运营商的例子来看，2001年，80%的家庭 希望提供捆绑业务，也证实了这一点。