IMS中的IPv4和IPv6的互连

3.14传统电路交换用户与IMS用户之间的连接

目前，大多用户使用传统的电路交换(CS)UE,即固定电话和各种蜂窝网终端。因此，应该进行IMS与传统的CS网络之间的互连，以支持IMS用户和CS网络用户之间的基础语音呼叫。这就要求在用户平面和控制平面上都要进行互连,因为在两个平面上所使用的协议不同。控制平面的互连由MGCF负责，MGCF进行从SIP信令到与承载无关的呼叫控制(BICC)或CS传统网络中的ISUP的映射,或相反。相应地,IMS-MGW在用户平面进行协议转换。它从CS(PSTN/ISDN/GSM)网络终结承载信道，同时终结基于IP或ATM的PS网络中的媒体流，并提供这两种终结之间的转换。另外IMS-MGW还提供其他功能，如编码方案的配合、回声抑制和连续性检查等。上述终结是由MGCF控制的。下面将对处理IMS发起的呼叫以及CS发起的呼叫的网络配置进行解释。

3.14.1 由IMS向CS核心网用户发起的会话

当IMS用户发起一次会话时，他不必关心被叫用户是一个IMS用户还是一个CS用户。他仅需要进行呼叫即可，由IMS负责找到被叫方。基于在IMS注册期间学习到的路由，来自主叫用户的会话请求总能够到达为主叫用户服务的S-CSCF。当S-CSCF收到一个使用telURL类型用户身份（电话：+358501234567）的会话请求时，它必须进行ENUM查询来将telURL转换成SIPURI,因为IMS路由原则不允许用telURL来进行路由。若S-CSCF能够将身份转换成SIPURI的格式，它就进一步将会话路由到目标IMS网络；当这种转换失败时，S-CSCF将尝试去到达CS网络内的用户。为了进入CS网络，S-CSCF进一步将会话请求路由到与其位于同一网络中的BGCF。所选的BGCF有两个选择：或者选择在同一个网络中的出口点，或者选择另一个网络，以进入CS网络。在前一种情况下，BGCF选择同一网络中的MGCF来将SIP信令转换成ISUP/BICC信令并控制IMS-MGW。在后一种情况下，BGCF选择不同IMS网络中的另一个BGCF来在其网络中选择MGCF以实现出口。MGCF充当了SIP信令的一个终结点，因此，它与IMSUE一起对媒体参数进行协商，并类似地与CS实体（如与MSC服务器）一起协商媒体参数。图3-23描绘了IMS发起的一个会话终结在CS网络中的情况下的互连概念。图中的箭头显示了第一条信令消息是如何穿过S-CSCF到达CS网络的。

图3-23IMS用户呼叫CS用户时的IMS-CS互连配置

3.14.2  由CS向IMS用户发起的会话

当一个CS用户拨打属于一个IMS用户的E.164号码时，该号码将像任何其他E.164号码一样在CS网络中得到处理。然而，在经过路由分析后，它将被送往IMS用户的归属网络中的MGCF。在收到该ISUP/BICC信令消息后，MGCF与IMS-MGW交互，以创建一条用户平面的连接。MGCF将ISUP/BICC信令转换成SIP信令，并向I-CSCF发送一条SIPINVITE消息。I-CSCF在HSS的帮助下（如2.3.4.1中所述）找到被叫用户的S-CSCF。接着，S-CSCF采取必要的动作，将SIPINVITE传递给UE。此后，MGCF继续与UE以及CS网络通信，来建立呼叫连接。图3-24显示了当一个CS发起的呼叫终结于IMS网络时，这些功能是如何相互作用的。图中的箭头显示了第一条信令消息是如何经过CS到达IMS用户的。

图3-24   CS用户呼叫 IMS用户时的IMS-CS互连配置

3.15固定与移动融合

由于无线网络和有线网络可能使用IMS体系进行融合，IMS就成为固定与移动融合（FMC）的一个并不昂贵的方法。FMC（即无线/有线融合）是将移动电话和固定电话基础网络连接起来的方法。目前，它是电信产业中至关紧要的策略问题之一。

这个融合的最终目标是实现在多个位置、设备和业务之间的无缝的终端用户体验。通过固定网络和移动网络的融合，无论用户的位置、接入技术或者用户使用的设备类型如何，电信运营商都可以为用户提供服务。

融合可以从三个独立的角度来看：

• 业务的融合；

• 网络的融合；

• 设备的融合。

无线/有线融合形成了新的电信服务模式，其中系统采用用户驱动的模式，而不是网络驱动或者设备驱动的模式。这个融合还通过为用户提供既具有移动业务的方便性和可用性，又具有固定业务的可靠性和质量的服务，从而为用户呈现了固定和移动两个网络的最佳部分。

1.运营商获得的好处

FMC为各种类型的运营商提供了商业机会。生活方式的改变、有效的定价模型和业务的个人化都将鼓励用户选择具有FMC解决方案的运营商。

现在，普通消费者和商业用户都将移动性作为一个重要的特征加以考虑。固定运营商可以通过扩大其业务覆盖范围来提高收入，覆盖范围的扩大可以包括那些移动运营商能够提供服务的范围。

由于移动市场目前基本饱和，新的用户数量的增加不再是移动运营商希望的增长类型。无线运营商需要在它们现有用户基础上搜寻新的和创新性的方法提高使用率。这可以通过为其用户提供新的服务来实现。无线运营商可以为其用户提供一个可实现的新方法：一个号码，一部手机，永远在线。

2.个人移动性

个人移动性不仅为终端用户提供了现在就可以支持的移动性，还提供了更多选择、更多方便、更高的生产率和更低廉的费用开销。它还使得载频提供商和业务提供商重新焕发活力。

现在很多用户有多个电话（移动电话、办公电话和家庭电话），每个都有不同的号码并且使用独立的接入网。

个人移动性将允许用户只有一部电话，他可以在WiFi上使用这个电话，并且在他位于WiFi覆盖范围之外的时候可以将他的通话无缝地切换到蜂窝网络中，反之亦然。它还允许用户将服务，例如话音邮件统一成为一个，并且使它容易接入,进而推进用户生产率的提高。它还导致更多像组管理（参见第8章）之类的高级业务变得更加有效。

个人移动性通过融合成为可能，特别是固定、无线和IP数据网络的融合。它使得用户可以利用这些网络提供的合并所带来的巨大潜在优势。用户可以选择接入固定和移动电话，并且能够根据费用开销和方便性决定使用哪个网络。如果用户在工作场所或者家里，他们可以在一个通话期间决定使用固定或者移动电话，而且这两者都是可以的。

对于用户而言具有最小和不可见性的WiFi网络和蜂窝网络之间的无缝切换，以及利用这样的无缝切换的应用融合集合，使得业务提供商实现个人移动性以及给用户提供更多价值。

3.16  SIP压缩

IMS使用SIP呼叫控制机制来支持多媒体服务。SIP是一种客户端/服务器的、基于文本的信令协议，用来创建和控制有两人或多人参与的多媒体会话。消息中还含有大量的消息头和消息头参数，包括扩展以及与安全相关的信息。建立一个SIP会话是一个冗长的过程，涉及到编码方案和扩展的协商，以及服务质量(QoS)交互通知。总体上，这将提供一个灵活的框架，从而使得具有各种不同要求的会话可以建立起来。然而，其缺点在于大量的字节和众多消息在无线接口上被交换。增加的消息长度意味着：

• 与使用现有的蜂窝网专用信令相比,SIP的呼叫建立过程将要花费的时间会多出很多，这就意味着终端用户在呼叫建立中将经历时延，该时延将是不希望看到的，并且极可能是不能接受的。

• 呼叫进行中的信令将在一定程度上给语音质量/系统性能带来不利的影响。

因此，当使用SIP呼叫控制时，对实时多媒体应用的支持要求进行特别的注意。为了加速会话的建立，3GPP已要求UE和P-CSCF均必须支持SIP压缩［3GPPTS23.221］。虽然对压缩的支持是必选的，3GPP并不强制必须使用它，因为将来WLAN终端可能根本不需要使用SIP压缩。在写本书的时候，UE和P-CSCF被要求按照［RFC3320］,［RFC3485］、［RFC3486］和［3GPPTS24.229］中定义的那样实现压缩功能。这里提到的第一个RFC给出了如何在两个实体间进行SIP消息压缩的总体解决方案；第二个RFC定义了一个SIP/SDP专有的静态词典，可用来让信令压缩方案获得更高效率;第三个RFC解释了UE如何用信令来告知一条或多条SIP消息需要压缩。(了解更多细节，请参考12.13.15节和第23章)

3.17IMS中的IPv4和IPv6的互连

3.17.1概述

对于因特网整体而言，当IMS概念刚刚出现时，IPv6的部署并没有像希望或期望的有那么快的进展。很多因素都对此造成影响，并且还将持续这些影响，但是最重要的因素是，通常因特网的核心路由基础结构的任何变化要比网络边缘出现的改变花费更多时间。

网络地址翻译器（NAT）就使用了属于后一类变化的改变。NAT被广泛认为对新业务和现有业务（例如，基于SIP的V6IP）都是有害的，但是就投资而言，它们提供了非常便宜和非常容易部署的可选方法来扩展很快就会用完的IPv4地址空间。因而减缓了以IPv6的形式进行中长期解决方案的部署速度。

在很多情况下，因特网中普遍发生的事情也会在移动网络中发生。尽管IPv6对IMS而言看起来比IPv4技术更先进，不过强制支持IPv6对任何系统的部署都意味着很大的障碍。除此以外，使用IPv6还需要漫游合作伙伴以及业务提供商迁移到IPv6。这就是为什么很多早期部署选择与现有的GPRS接入网以及安全基础结构（在3.8.6节中有更多关于这方面的内容）进行合作的原因，并且这个现有网络基础结构通常也不支持IPv6。另外，3GPP2IP多媒体系统，即所谓多媒体域（MMD）,在IPv4和IPv6上运营。这就意味着IMS和MMD之间的任何互连都自然而然地也包括了IPv4-IPv6互连。

因此，很明显地，尽管初始定义是只支持IPv6,但是基于IPv4的IMS的部分部署是不可避免的。通常，这些基于IPv4的IMS部署被称为“IMS早期实现”,并且UE、IMS核心网或者二者全部使用IPv4。

有两个主要的推论：

• IPv4的实现需要处理必须使用私有地址空间的问题，因为并不是所有移动设备都可以从公共地址空间中获得一个地址；

• 一旦支持IPv6的实现方案伴随IPv4实现而被引入的时候，它们需要能够无缝地相互合作。

本章举例说明了这个问题，以及用于IMS中IPv4和IPv6互连的解决方案。在版本6中，3GPP已经以技术报告［TR23.981］的形式提供了早期IMS系统的实现者的指导原则。这意味着尽管早期IMS实现仍然没有被认可，但至少原则的部分内容已经用于处理一些最迫切关注的问题。

地址翻译

进行地址翻译的基本单元就是所谓的网络地址翻译器（NAT）。NAT允许单个公共IP地址被大量主机共享。NAT设备之后的主机配置在私有地址空间内的IP地址（也就是说，在192.168.0.0/16或者10.0.0.0/24）,并且不可在因特网中寻址,然后NAT设备在公共和私有地址空间之间创建基于每个连接的临时绑定（temporarybinding）。绑定就是一个在公共IP地址与端口和私有地址与端口之间简单的映射，其中私有地址与端口是与特定传输（UDP或者TCP）相关的。绑定只持续会话持续的长度，或者直到绑定时间超时。通常，这些超时是非常迅速的,以便节省资源。

NAT的另外一个类型是特别为不同协议版本之间的翻译进行设计的。网络地址翻译器——协议翻译器（NAT-PT）负责在IPv4和IPv6之间进行翻译。它有效地将IP数据报提取出来，并且用IPv6头替换IPv4头，反之亦然。

在IMS中，这种翻译设备的单独存在并不足够。SIP和SDP都包含简单的IP地址，例如在SIP联系头域（contactheaderfield）中或者在SDP媒体线（medialine）中。对于使用错误IP版本的终端，这些地址既无法理解，也无法获得。因此，就需要应用层网关（ALG）设备来检查SIP消息，并且将任何存在的原始IP地址用翻译出的IP地址替换。通常NAT不允许输入业务，除非生成了输出业务（也就是绑定被创建），这意味着ALG还必须基于包含在SDP中的媒体信息来主动创建绑定。

ALG设备经常与NAT设备共站址,简单的原因就是它需要知道翻译绑定并且安装它们。会话边界控制器（SBC）就是这种翻译器的一种类型，尽管SBC通常还执行很多其他功能。

正如期望的那样，地址翻译器有下面几个缺点：

• 它们是失败的惟一原因。如果翻译绑定丢失，那么整个会话都将不可用。

• ALG停止安全功能，或者在端到端安全机制前不正确地运营。传输中消息的有效修改是传输中人为（MITM）的主动攻击。

• ALG功能并不透明。SDP的新版本或者另外一个包含IP地址的头域将无法被正确地辨认或者翻译。

• 可量测性问题。ALG功能是资源密集型的，NAT需要用于存储绑定以及带宽的资源。

因此IMS中的IPv4-IPv6互连试图尽可能地避免使用NAT和ALG也就毫不奇怪了。不过，建议它们用于特定的互连场景，这个问题将在3.1.7.3节进行深入地讨论。

3.17.2 只有IPv6 与双协议栈比较

对于主机（和路由器）而言，一个成功的迁移到IPv6的重要方法就是支持双IP层方法，也就是所谓的“双协议栈操作”。双栈是用于提供两个IP版本的技术——也就是IPv6以及IPv4。双栈主机可以发送和接收两个IP版本，并且因此可以与两种类型的节点进行通信。双栈节点也能够用两个地址版本进行配置，尽管配置机制可能不同。例如，IPv4地址可能配置使用DHCP,而IPv6地址使用无状态（stateless）地址自动配置。

双栈节点还需要支持其他功能。例如，无论这些结果是基于哪个版本的IP数据报接收的，它需要支持IPv4“A”和IPv6"AAAA”的DNS记录。例如，在IPv4上进行的对于域的DNS查询可能返回A和AAAA记录，甚至只有AAAA记录。那么，所使用IP地址的顺序依赖于应用，但是还可能受到DNS服务器返回相关记录的顺序的影响。

一个节点还可以废弃来自它的协议栈中的协议版本。不过，在实践中，很多IMS节点需要保持IPv4功能发挥作用，因为有其他应用——例如WWW业务——需要完全使用IPv4。

就移动而言,双栈的UE和IMS核心网提供了比只有IPv4的实现更多的选项。即使是协议栈中废弃的特定IP版本，等到以后IPv6变得更普遍的时候，它还可以被激活。双栈主机中的主要好处就是它们最小化了网络中NAT设备的需求。看起来在未来只有IPv6的主机也并不可行，因为大部分业务仍将在很长时间内使用只有IPv4的主机。

3.17.3互连场景

IPv4-IPv6互连的主要问题当然是不同的IP版本。只支持一个版本的节点的存在使得一些形式的翻译非常必要，这应用于信令业务以及用户平面或者媒体业务。根据IMS核心网是否支持IPv6,还有多种方式导致翻译的发生。

我们将本节的讨论分为域内和域间两个场景。域内场景处理了UE和单个IMS提供商的IMS核心网之间的互连，而域间场景处理不同IMS提供商的网络之间的互连，以及对属于不同IMS运营商的网络的UE之间端到端的考虑。

3.17.4域内场景

域内场景是非常简单的。假设在UE和P-CSCF之间IP版本保持恒定：

• 如果IMS核心网只支持IPv4——那么只支持双栈和IPv4客户端；

• 如果IMS核心网支持双栈——那么支持各种类型的客户端；

• 如果IMS核心网只支持IPv6——那么只支持双栈和IPv6客户端。

3.17.5域间场景

域间场景相对更加复杂。复杂度主要是由于有更多变量要考虑。除了发射端和接收端（即UE和IMS核心网），这两个域之间还有传输网络，它还展示了IPv4、双栈或者IPv6动作之一的支持。另外，IMS核心网也可能使用来自私有地址空间的IPv4地址，这在网络边缘就需要NAT,以便与其他域互连。

双栈IMS核心网可能需要额外的与S-CSCF相关的NAT设备，原因在于互连可能使用I-CSCF和S-CSCF支持但是UE不支持的IPv4。在这种情况下，NAT-PT设备需要对该IP版本进行翻译。如图3-25所示，给出了不同NAT设备的可能位置。

图3-25  端到端和互连场景

3.17.6 配置和引导

通常，在建立了L2连接之后，UE接收了一个使用标准配置的IP地址，例如DHCP或者其他机制。

UE的下一步是找到它与IMS的联系点——也就是P-CSCF的地址。在IMS中，现有用于P-CSCF地址的发现机制可以是IPv6特定的，也可以使用基于GPRS的版本5（或者之后版本）的方法。为了基于IPv4的IMS部署，可能还需要其他机制。发现P-CSCF地址的方法有一些可选项：

• 使用GPRS的发现可以改变，因此它可以在PDP上下文建立基础上返回IPv4和IPv6地址。

• 使用DHCP选项用于配置P-CSCF地址。

• 带外提供机制，例如使用短信业务（SMS）、基于空口（OTA）或者开发移动联盟（OMA）设备管理框架。

• 预先配置。

使用带外机制需要对现有网络结构不产生任何变化，并且因此它可能是大多数早期IMS实现者的最佳选择。预先配置地址也是一个可选项，但是在后期命名或者拓扑改变的时候它不是很灵活。

除了配置数据输出代理（也就是P-CSCF）地址，在SIP头中还承载了附加地址信息，这也需要进行互连的考虑。例如，任何路由入口或者计费实体的地址都需要在IPv4和IPv6中被表示出来。

3.17.7只有IPv4的接入网

由于GPRS中的功能，虽然IMS实现问题并不那么严格，但是接入网是IPv4-IPv6互连中要重点考虑的内容。其原因在于网络中的承载依赖于IP版本，不支持IPv6的SGSN/GGSN不允许建立IPv6的PDP上下文，现有的老版本接入网可能根本就不支持IPv6。因此，互连的首要问题就是与GPRS接入网的互连，包括漫游和非漫游场景。如果GPRSSGSN或者GGSN不支持IPv6,那么无论其他任何IMS元素是否支持IPv6,UE都无法使用纯粹的IPv6。在这些场景中使用IPv6的惟一可能的方法就是UE和IMS核心网使用隧道机制，其中每个IPv6分组都封装到IPv4分组中，并且在出口或者路由器进行拆封——实际上就是将IPv4连接作为L2层传输。如图3-26所示。

图3-26   IPV6向IPV4转换的隧道机制

封装需要应用在主机和基于网络的节点之间，以便能够与只支持IPv6的主机进行透明的通信。因此，隧道终结点要在分组拆封之后将这些分组有效地传送给网络中正确的主机。隧道使用隧道机制来寻址和设置，例如站内自动隧道寻址协议（ISATAP）[Draft.ietf-ngtrans-isatap]。

在ISATAP中，接口地址的创建是使用从IPv4链路地址（也就是接口地址的最后32bit）的静态映射。它们同时还伴随着路由表，因此分组就可以传送给正确的接口。不过，对于隧道方法有下面几个不利的地方：

• 它通过使用Go接口破坏了SBLP；

• 归属网络需要安装隧道服务器，以便作为隧道终结点使用；

• 该服务器也需要被UE配置以及能够被UE发现；

• 隧道终结点是失败的惟一原因；

• 在漫游场景下使用隧道似乎效率不高，因为所有业务都要通过归属网络进行传送——这会导致三次路由而增大系统延时；

• 在任何情况下，它都需要双栈主机，因此使用纯粹的IPv4可能是一个更好的方法。

3.18CS与IMS业务的合并——合并型业务

3.18.1概述

在IMS被设计为一个独立系统来为其用户提供多媒体业务的同时，它还可以用于为现有电话网络提供附加功能。在IMS部署的初始阶段，移动网络用户将主要使用移动网络的CS域来进行音频业务。在这样的CS呼叫中，基本业务及其QoS的提供并不需要IMS——也就是两个用户之间的信令和媒体连接。

但是这样的CS呼叫也可以从IMS的灵活性和宽带业务的提供能力获得好处。最近3GPP已经开始了新的工作，目的是使得所谓的“合并型业务”成为可能。由于这项工作在本书编写的时候还正在进行，因此本节只给出一些基本原理。

为了使得这样的业务合并成为可能，两个UE首先需要了解对方所支持的能力。3.18.2节给出了在两个用户间的CS呼叫建立之后，IMS相关的能力信息如何进行交换。在3.18.3节给出了基于这种能力信息的交换，IMS业务如何被激活来增强正在进行的CS呼叫。

3.18.2能力信息交换

在下面的例子中，我们假设两个用户在CS域上进行连接——即二者之间存在CS连接。在这个例子中，Tobias使用他妹妹Theresa的国际电话号码进行呼叫。为了允许合并型业务正常工作，必须满足下列条件：

• 在CS信令中，呼叫方网络需要提供完全国际格式的Tobias的电话号码(MSISDN)给Theresa的UE——例如，+44123456789；

• Tobias的MSISDN还需要在Tobias归属IMS网络中注册为电话URL——例如，tel:+44123456789；

• 同样，Theresa的MSISDN必须通过CS信令发送给Tobias的UE0Theresa的MSISDN必须以国际电话号码格式指出，并且必须在Theresa的归属IMS网络中注册为电话URL——例如，tel:+36987654321；

• 同时，Theresa和Tobias都需要用他们的电话URL进行注册，他们的UE基本相同，这样可以用来建立与对方的CS呼叫。

为了简化这个例子，我们假设两个用户——Theresa和Tobias,都是用一个UE注册的。这是为了避免多种可能的情况(forkingcases)(见3.7节)。Theresa和Tobias都有安装在他们的UE上的基于IMS的应用，从而允许他们在已有的话音呼叫之外实时共享视频流，这个点对点应用只能工作在两个终端都有该应用的情况下。如果Theresa和Tobias的UE已经确认对方可以支持视频共享应用，那么为了提供一致的用户体验，用于“视频共享"的菜单项将只显示给Theresa和Tobias。

SIP OPTIONS请求(见12.4.1节)被用于查询对方终端的能力。在建立了CS呼叫之后，两个终端都会发送OPTIONS请求给远端用户的电话URL,电话URL将从CS呼叫远端用户的MSISDN中被提取出来。在我们的例子中，Tobias的UE发送了一个OPTIONS请求给下面的地址：

OPTIONS tel:+36987654321SIP/2.0

Theresa的UE将发送200(OK)响应给这个OPTIONS请求，它指出了UE的能力。这些能力之一就用于说明对视频共享应用的支持。相同的OPTIONS/200(OK)交换在另外一个方向也在进行。在这些交换结束之后，Theresa和Tobias都能够实现与CS呼叫中的另外一方共享视频流。

正如上面所述，此处给出的例子是非常基本的，并且只是从原理的角度给出了UE之间的能力如何进行交换，如图3-27所示。

图3-27   正在进行的CS呼叫期间的能力信息交换

3.18.3  并行的CS和IMS业务

在能力信息交换之后，其中一个用户现在就可以开始共享视频直播。在我们的例子中，Theresa希望发送视频给Tobias□两个用户之间的会话建立过程参见11.10节的描述(可选择的会话建立)。在这个会话己经建立之后，Theresa可以通过GPRS发送视频流给Tobiaso图3-28给出了并行存在的连接。

图3-28  合并IMS和Cs业务时的并行连接的例子

两个用户之间基于SIP的连接可以在释放的同时CS呼叫仍然继续，也可以在CS呼叫结束的时候视频共享应用自动释放。这纯粹是应用层特定的行为。