CN1509577A - Ip多媒体中的存在服务器 - Google Patents
Ip多媒体中的存在服务器 Download PDFInfo
- Publication number
- CN1509577A CN1509577A CNA028098102A CN02809810A CN1509577A CN 1509577 A CN1509577 A CN 1509577A CN A028098102 A CNA028098102 A CN A028098102A CN 02809810 A CN02809810 A CN 02809810A CN 1509577 A CN1509577 A CN 1509577A
- Authority
- CN
- China
- Prior art keywords
- network
- message
- reservation
- user
- service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
- H04L67/30—Profiles
- H04L67/306—User profiles
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/54—Presence management, e.g. monitoring or registration for receipt of user log-on information, or the connection status of the users
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
- H04W8/08—Mobility data transfer
- H04W8/10—Mobility data transfer between location register and external networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/08—Upper layer protocols
- H04W80/10—Upper layer protocols adapted for application session management, e.g. SIP [Session Initiation Protocol]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W92/00—Interfaces specially adapted for wireless communication networks
- H04W92/02—Inter-networking arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W92/00—Interfaces specially adapted for wireless communication networks
- H04W92/16—Interfaces between hierarchically similar devices
- H04W92/24—Interfaces between hierarchically similar devices between backbone network devices
Abstract
这篇文档提出了用于预订和通知用户存在的SIP扩展。用户存在被定义为用户与网络上的其他用户通信的意愿和能力。存在在历史上一直被限制为“在线”和“离线”指示器；存在的概念在此更为宽泛。用户存在的预订和通知是通过在通用SIP事件通知结构内定义事件包而得以支持的。这个协议还遵守通用存在和即时消息传递(CPIM)结构。
Description
技术领域
本发明涉及在分组交换环境中提供系统体系结构，本发明尤其涉及在用于提供有关用户存在的信息的装置中这种体系结构中的实现。
背景技术
在第三代(3G)移动网络中，服务是在IP网络上提供的，这导致话音和数据应用的结合。对于新出现的基于IP的服务，其中一个主要选择是提供有关用户存在的信息。存在被定义为预订和通知用户通信状态的变化。这种通信状态由以下集合构成：通信装置；通信地址；以及该用户的状态。
在第三代网络中，呼叫控制和业务生成环境是基于会话启动协议(SIP)的，这在第三代合作项目，技术规范组业务和系统方面，IP多媒体分系统--阶段2，3G TS 23.228，版本1.7.0，2001年2月，中描述。
Rosenberg等人于2001年3月2日发表的因特网工程任务组，因特网草案，draft-rosenberg-impp-presence-01.txt提出了用于预订和通知用户存在的SIP扩展，其内容在此结合作为参考附件A。用户存在被定义为用户与网络上的其他用户通信的意愿和能力。存在在历史上一直被局限为“在线”和“离线”指示器；在Rosenberg等人的论述中存在的概念更为宽泛。用户存在的预订和通知是通过在通用SIP事件通知结构内定义事件包得到支持的。这个协议还遵守通用存在和即时消息传递(CPIM)结构。然而，这个协议并不包含任何对多媒体环境的考虑。
在Rosenberg等人定义的SIP扩展基于存在代理(PA)的概念，PA是一个新的逻辑实体，能接受预订(通过“预约”消息)，存储预订状态，以及在用户存在有变时生成通知(通过“通知”消息)。
本发明的目的是在网际协议多媒体分系统中提供一种用于会话启动协议注册、预订和通知过程的技术。
发明内容
本发明的目的是通过在所述体系结构中提供存在服务器实现的。优选提供存在服务器作为应用和服务‘云’或环境的一部分。通过在这种体系结构中提供存在服务器，用户能接收有关其他用户的存在的信息。
本发明涉及3GPP(第三代合作项目)5/6版标准。
根据本发明提供分组交换环境，包括应用和服务环境中的存在服务器的功能。
所述分组交换环境优选为网际协议多媒体环境，并且优选为全IP电信网的分系统。
在第一个实施例中，询问呼叫状态控制功能(I-CSCF)通过分叉输入的“注册”消息修改存在服务器中的存在信息。
在第二个实施例中，服务呼叫状态控制功能(S-CSCF)充当存在代理，而且存在服务器提供存储有关用户的信息的任务。
在第三个实施例中，网际协议多媒体(IM)分系统中的存在服务器充当存在代理，而且服务呼叫状态控制功能(S-CSCF)利用独立的“注册”事务处理修改存在服务器中的存在信息。
本发明由此解决了在网际协议多媒体(IM)分系统中路由“注册”、“预约”和“通知”消息的问题。
附图说明
现在通过参考附图描述本发明，其中：
图1表示体现本发明的3GPP版本5的体系结构；
图2表示在本发明的第一个实施例中的“注册”消息的流程；
图3表示在本发明的第一个实施例中的“预约”消息的流程；
图4表示在本发明的第一个实施例中的“通知”消息的流程；
图5表示在本发明的第二个实施例中的“预约”消息的流程；
图6表示在本发明的第二个实施例中的“通知”消息的流程；
图7表示在本发明的第三个实施例中的“注册”消息的流程；
图8表示在本发明的第三个实施例中的“预约”消息的流程；以及
图9表示在本发明的第三个实施例中的“通知”消息的流程。
具体实施方式
本发明在3GPP版本5体系结构的因特网多媒体分系统中放置存在服务器作为‘应用和服务云’的一部分。网际协议多媒体分系统是指使用3GPP版本5体系结构的分组交换域提供的服务以提供多媒体服务的核心网络实体的集合。网际协议多媒体分系统的实体有CSCF、MGCF、MRF和一些适配实体。图1示意了这种扩展体系结构的表示。
图1基于根据在第三代合作项目；技术规范组服务和系统方面；全IP网络体系结构；3G TR 23.922版本1.0.0；1999年10月，定义的体系结构的基本3GPP体系结构，其内容在此结合作为参考附件B。然而，如图1所示，修改在此公开的体系结构，以包含根据本发明的存在服务器。
本发明尤其关心在3GPP网络中“注册”、“预约”和“通知”消息的流动。
现在参考“注册”、“预约”和“通知”消息流的三个示例性实施例详细描述本发明。应指出，在下面的例子中只描述了操作本发明所需的网络和消息流的必要部分。
所有这些描述的实施例的一个普遍要求是用户的简表信息必须包含与该用户相关的存在服务器的名称。
下面参考图2-4描述第一个实施例的“注册”/“预约”/“通知”消息的路由选择。
在第一个实施例中，询问呼叫状态控制功能(I-CSCF)通过分叉输入的“注册”消息修改存在服务器中的存在信息。
第一个网络对应存在用户代理(PUA)的受访网络，其包含用户设备(UE)200和代理呼叫状态控制功能(P-CSCF)202。第一个网络也是存在代理的网络。
第二个网络对应存在用户代理(PUA)的归属网络，其包含询问呼叫状态控制功能(I-CSCF)204、(HSS)206、服务呼叫状态控制功能(S-CSCF)208以及存在服务器(PS)210。
第三个网络对应用户的归属网络，其包含UE用户212、第一代理呼叫状态控制功能(P-CSCF#1)214、第一服务呼叫状态控制功能(S-CSCF#1)216、询问呼叫状态控制功能(I-CSCF)218、(HSS)220、第二服务呼叫状态控制功能(S-CSCF#2)222、以及第二代理呼叫状态控制功能(P-CSCF#2)224。
参考图2，示意根据本发明第一个实施例的扩展注册消息流。
如步骤230表示，由用户设备200发起的“注册”消息的路由选择发生在UE 200、第一个网络P-CSCF 202和第二个网络I-CSCF 204之间。存在服务器210的名称是用户简表的一部分，它是在步骤232通过I-CSCF 204从HSS 206检索到的。在步骤234，I-CSCF 204选择一个用于会话启动的S-CSCF，在本例中它为S-CSCF208。
如消息236和238表示，I-CSCF 204分叉输入的“注册”消息，以便根据此实施例，该“注册”消息被转发到S-CSCF 208和PS 210。之后沿相反路由将200 OK”消息发送回UE 200。
参考图3，示意根据本发明第一个实施例的“预约”消息流的路由选择。
如消息240、242和244表示，“预约”消息经由P-CSCF#1214和S-CSCF#1 216从UE用户212被路由到I-CSCF 204。
如消息246表示，I-CSCF 204直接将接收到的“预约”消息路由到PS 210。之后“202 Accepted”消息沿相反路由被路由回UE用户。
参考图4，示意根据本发明第一个实施例来自存在服务器210的“通知”消息流的路由选择。
如消息248表示，PS 210将“通知”消息转发到I-CSCF218。在步骤249的本地查询HSS 220之后，如消息250、252和254表示，I-CSCF经由S-CSCF#2 222和P-CSCF#2 224转发“通知”消息到UE用户226。由此PS 210直接发送“通知”消息到另一网络I-CSCF 218。“200 OK”消息被再一次沿相反路由路由回PS210。
总之，第一个实施例对该体系结构中设置的网络单元提出了以下新需求：
1.I-CSCF从HSS下载(部分)用户简表以便找到用户的存在服务器；
2.I-CSCF分叉PUA的输入“注册”到S-CSCF和存在服务器；
3.I-CSCF直接路由输入的“预约”请求到存在服务器；以及
4.存在服务器直接发送输出的“通知”到其他网络的I-CSCF。
下面参考图5和6描述根据本发明第二个实施例的“预约”/“通知”消息的路由选择。
由于S-CSCF存储了用户简表和在“注册”消息中提供的联系信息，通常的解决方案是S-CSCF充当存在代理。这种解决方案存在的一个可能问题是，S-CSCF将必须存储有关所有用户的信息并为所有用户生成“通知”消息。
因此，在第二个所述实施例中，存储有关每个用户的信息的任务是由新引入的存在服务器提供的。对于S-CSCF，只接收用于presentity的第一个“预约”消息就足够了，因为它将为一个预订生成“通知”消息，而且这个“通知”消息将被拥有关于用户的信息的代理服务器分叉到用户。
在这个解决方案中注册流对应在上面的介绍中讨论的，由2001年2月的3G TS 23.228版本1.7.0定义的常规注册。
下面参考图5和6描述根据本发明第二个实施例的“预约”/“通知”消息的路由选择。在图5和6中利用相同的附图标记给对应图2-4所示的单元的第一、第二和第三个网络的单元加上附图标记。
除了图2-4所示的单元，为描述第二个实施例，对应用户的归属网络的第三个网络包括两个用户设备用户，即UE subs#1 302和UEsub#2 304。此外，对应PUA的归属网络的第二个网络，包括第二服务呼叫状态控制功能S-CSCF#2 306。
参考图5，示意根据本发明第二个实施例的“预约”消息流的路由选择。
来自第一个用户设备用户302的“预约”消息被转发到P-CSCF#1 214，如消息308a所示。这个消息又被转发到S-CSCF#1216和I-CSCF 204，如消息310a和312a所示。在步骤313a的本地查询之后，“预约”消息被转发到PS 210，如消息314a所示。之后“预约”消息从PS 210被转发到S-CSCF#2 306，如消息316所示。
为响应来自存在服务器210，对应第三个网络的第一个用户设备用户302的“预约”消息，S-CSCF#2通过应答信号返回确认消息，如箭头318所示。
类似地，来自第二个用户设备用户304的“预约”消息被转发到P-CSCF#1 214，如消息308b所示。这个消息又被转发到S-CSCF#1 216和I-CSCF 204，如消息310b和312b所示。在步骤313b的本地查询后，“预约”消息被转发到PS 210，如消息314b所示。
存在服务器210不必从第三个网络的用户设备转发任何后续的“预约”消息，因为S-CSCF#2 306已经提供了成功的确认。
为响应接收到消息318和适当的“预约”消息314，每个用户的应答信号被沿相反路径返回相应的用户
参考图6，示意根据本发明的这个实施例来自存在服务器210的“通知”消息流的路由选择。
如消息320表示，单个“通知”消息被从S-CSCF#1转发到存在服务器210。
如消息322a表示，存在服务器接着转发第一个“通知”消息到I-CSCF 218。在第一个本地查询324a之后，第一个“通知”消息又经S-CSCF#2 222和P-CSCF#2 224被转发到第一个用户设备用户302，如消息326a、328a和330a所示。
如消息322b表示，存在服务器也转发第二个“通知”消息到I-CSCF 218。在第二个本地查询324b之后，第二个“通知”消息又经S-CSCF#2 222和P-CSCF#2 224被转发到第一个用户设备用户302，如消息326b、328b和330b所示。
“200 OK”消息经相反路径被返回到存在服务器210，而单个“OK”消息被转发到S-CSCF#1。
下面参考图7-9描述根据本发明第三个实施例的“注册”/“预约”/“通知”消息的路由选择。
在第三个实施例中描述的解决方案可以归纳为：网际协议多媒体分系统中的存在服务器充当存在代理，而且S-CSCF利用独立的“注册”事物处理来更新存在服务器中的存在信息。
下面参考图7-9描述“注册”/“预约”/“通知”方法的路由选择。在附图7-9中利用相同的附图标记给对应图2-6中所示的单元的第一、第二和第三个网络的单元加上附图标记。
参考图7，示意根据本发明第三个实施例的扩展注册消息流。
如步骤230表示，“注册”消息的路由选择发生在UE 200、第一个网络P-CSCF 202和第二个网络I-CSCF 204之间。
之后，在步骤702，I-CSCF 204选择一个用于会话启动的S-CSCF 208，其在本例中为S-CSCF 208。
如消息704表示，“注册”消息接着被转发到S-CSCF 208。
存在服务器210的名称是用户简表的一部分，而且它是在步骤708通过I-CSCF 204从HSS 206检索到的。
在S-CSCF 208成功启动后，“200 OK”消息被沿相反路径发送到UE 200。之后，如消息710表示，“注册”消息被转发到存在服务器210。消息710构成独立的“注册”事物处理，S-CSCF利用这个消息更新PS中的存在信息。
如果在存在服务器存在更新失败，则S-CSCF向UE 200产生一个通知，指示存在更新失败事件。对于这个通知可以使用SIP“通知”消息，例如，包含具有新存在失败原因代码的事件头。在图7这个例子被标记为711。接着“通知”被UE 200利用“200OK”消息向S-CSCF 208进行确认。
参考图8，示意根据本发明第三个实施例的“预约”消息流的路由选择。
来自用户设备用户212的“预约”消息被转发到P-CSCF#1214，如消息712所示。这个消息又被转发到S-CSCF#1 216和I-CSCF 204，如消息714和716所示。在步骤718的本地查询之后，“预约”消息被转发到S-CSCF#2 306，如消息720表示。随后“预约”消息从S-CSCF#2被转发到PS 210，如消息720表示。之后“202 Accepted”消息被沿相反路径发送。
参考图9，示意根据本发明第三个实施例，来自存在服务器210的“通知”消息流的路由选择。
如消息722表示，“通知”消息被从存在服务器210转发到S-CSCF#1 306。如消息724表示，S-CSCF#1 306接着转发“通知”消息到I-CSCF 218。在步骤726的本地查询之后，“通知”消息又经S-CSCF#2 222和P-CSCF#2 224被转发到用户设备用户226，如消息728、730和732表示。
之后“200 OK”消息被沿相反路径发送。
因第三个实施例，对在所述体系结构中放置的网络单元提出的新需求可归纳如下：
1.S-CSCF利用独立的“注册”事物处理更新PS中的存在信息。
2.如果在PS存在更新失败，则S-CSCF向UE产生通知消息(即，利用具有新存在失败原因代码的事件头的SIP“通知”)以指示存在更新事件失败。
3.用户生成的“预约”必须象常规INVITE一样被网络路由，只有PUA的S-CSCF路由“预约”到与presentity相关的PS。
4.用户生成的“预约”必须象常规INVITE一样被网络路由。
尽管参考了三个示例性实施例描述本发明，但本发明更为概括地介绍了借助3GPP提出的体系结构实现Rosenberg等人提出的观点的方式。
附件A
因特网工程任务组 SIMPLE WG
因特网草案 Rosenberg等人
draft-rosenberg-impp-presence-01.txt 各个地方
2001.3.2
期限：2001年9月
SIP扩展用于存在
这篇文档的状态
这篇文档是一个因特网草案，遵守RFC2026中第10节的所有规定。
因特网草案是因特网工程任务组(IETF)，及其分部和工作组的工作文档。注意：其他组也可以将其工作文档作为因特网草案分发。
因特网草案属于草案文档，有效期最长为6个月，可以随时被其它文档更新、替换或者废弃。使用因特网草案作为参考资料或不是作为正在进行中的工作引用它们的做法是不妥当的。
可以在http：//www.ietf.org/ietf/1id-abstracts.txt处访问当前因特网草案的列表。
可以在http：//www.ietf.org/shadow.html处访问因特网草案影象目录(Internet-Draft Shadow Directories)的列表。
1.介绍
在RFC2778[1]存在被(间接)定义为预订和通知用户通信状态的变化。
这种通信状态由通信装置、通信地址以及该用户的状态的集合组成。存在协议是用于在因特网或任何IP网络上提供这种业务的协议。
这篇文档提出会话启动协议(SIP)[2]扩展用于存在。这种扩展是为SIP[3]定义的通用事件通知结构的具体例化，并且照此利用在此定义的“预约”和“通知”方法。用户存在特别适合于SIP。SIP注册和位置服务已经保存了用户存在信息；这个信息通过“注册”消息被上载到这些设备，并被用于路由呼叫到那些用户。此外，SIP网络已经路由来自网络上任何用户的INVITE消息到为用户保存注册状态的代理。由于这个状态是用户存在，这些SIP网络也能允许“预约”请求被路由到相同代理。这意味着SIP网络可被再用来为存在预订和通知建立全球连接。
这种扩展基于存在代理的概念，存在代理是一种新的逻辑实体，能接受预订、存储预订状态以及在用户存在有变时产生通知。该实体被定义为一个逻辑实体，这是因为它一般与另一实体共驻留，而且在预订的使用期限内甚至能到处移动。
这种扩展也遵守在[4]定义的通用存在和即时消息传递(CPIM)结构。这使得用于存在的SIP很容易与遵守CPIM的其他存在系统交互工作。
2.定义
这篇文档采用在[1]定义的术语。另外，定义和/或补充解释以下术语：
存在用户代理(PUA)：存在用户代理为presentity处理存在信息。在SIP术语中，这意味着PUA产生“注册”请求，传送有关该presentity的某种信息。我们明确允许每个presentity有多个PUA。这意味着一个用户可以拥有许多设备(如蜂窝电话和PDA)，每个设备为presentity独立产生总体存在信息的一个部分。PUA将数据推入存在系统，但PUA位于存在系统的外部，因为PUA不接收“预约”消息，或发送“通知”。
存在代理(PA)：存在代理是能接收“预约”请求，响应这些请求，并产生存在状态的变化的通知的SIP用户代理。存在代理必须完全了解presentity的存在状态。通常这是通过使PA与代理/注册，或与presentity的存在用户代理共址实现的。PA总是用SIPURL来寻址。
存在服务器：存在服务器是能充当用于“预约”请求的存在代理或代理服务器的逻辑实体。当充当PA时，其通过某些协议方式知道presentity的存在信息。这个协议方式可以是SIP“注册”请求，但其他方式也是允许的。当充当代理时，“预约”请求被代理到可充当PA的另一实体。
存在客户：存在客户是与PUA共址的存在代理。由于其与处理这些存在信息的实体共址，因此知道presentity的存在信息。
3.操作概述
在这一节中，我们介绍这种扩展操作的概述。
当一个实体，即用户，希望从某个用户了解存在信息时，其创建 “预约”请求。这个请求利用存在URL或SIP URL识别在请求URI中期望的presentity。象任何其他INVITE那样沿SIP代理传输这个预订。这个预订最终到达存在服务器，存在服务器或终止该预订(在此情况下，其对presentity充当存在代理)，或将其代理直达存在客户。如果存在客户处理该预订，则其对presentity有效地充当存在代理。关于是代理还是终止“预约”的决定是本地事物；然而，我们描述利用“注册”实现这种配置的一种方式。
存在代理(不管是位于存在服务器还是存在客户)首先鉴权该预订，接着授权。用于授权的方法不在本协议的范围之内，而且我们期望能使用许多方法。一旦被授权，存在代理就发送202 Accepted响应。其还发送包含presentity的状态的即时“通知”消息。由于presentity的状态改变，PA为所有用户生成“通知”。
“预约”消息与存在代理有效建立会话。因此，“预约”能被记录-路由。而且用于标记处理和联系处理的规则为INVITE镜像它们。类似地，以处理呼叫路径内的re-INVITE的基本上相同的方式处理“通知”消息。
4.命名
presentity最一般的方式是通过存在URI[4]识别的，其形式为：pres：user@domain。这些URI是独立于协议的。可通过各种手段分解这些URL以确定可用于访问该presentity的特定协议。一旦出现这种分解，可利用几乎相同形式的sip URL编址presentity：sip：user@domain.这种独立于协议的形式(pres：URL)可被认为是抽象名称，类似URN，用于识别存在系统中的单元。这些URI被分解为可用于直接定位网络上的那些实体的具体URL。
当预订presentity时，可利用独立于协议的形式或sip URL形式编址所述预订。在SIP语境中，“编址的”是指请求URI。推荐如果发送“预约”的实体能分解协议独立的形式为SIP形式，则在发送该请求前执行这种分解。然而，如果该实体不能执行这种转换，则在该请求URL中使用该协议独立的形式。尽可能早地执行这种转换意味着这些请求可被不知道存在名称空间的SIP代理路由。
这种命名方案的结果是以编址INVITE请求完全相同的方式编址“预约”请求到用户。这意味着SIP网络将沿传输INVITE的相同路径路由这些消息。沿该路径的这些实体中有一个可充当用于该预订的PA。通常，这个实体或者是存在服务器(这是用户被注册的代理/注册服务器)，或者是存在客户(这是与该presentity相关的其中一个用户代理)。
“预约”消息还包含定义该预订的发信方和收信方的逻辑标识符(To和From信头字段)。由于这些标识符是逻辑标识符，因此推荐在可能时使用协议独立的格式。这也使得与识别这些形式的其他系统交互作用更为容易。
联系，记录-路由和路由字段不识别逻辑实体，而是用于SIP传信的具体实体。因此，它们在“预约”和“通知”中必须使用SIP URL形式。
5.存在事件包
SIP事件结构[3]定义用于预订事件和接收事件通知的抽象SIP扩展。其将这些事件的许多其他方面的定义留给具体扩展，也称为事件包。这种扩展被当作事件包。这一节提供[3]所要求的信息。
5.1 包名
这个包的名称为“存在”。这个名称必须出现在“预约”请求和“通知”请求的事件信头内。这一节还可用于事件包“存在”的IANA注册。
TODO：在子通知定义IANA模板并为其提供信息。
例：
事件：存在
5.2 “预约”主体
“预约”请求的主体可包含一个主体。该主体的目的取决于其类型。一般来说，预订通常不包含主体。识别presentity的请求URI，加上事件包名足以用于用户存在。
我们期望文档格式可被定义为充当预订的过滤器。这些过滤器将指示某些用户存在事件会产生通知或限制在“通知”请求中返回的数据集合。例如，存在过滤器可指定，只有在用户即时消息收信信箱的状态改变时才应产生通知。还可以说，这些通知的内容只应包含IM相关信息。
5.3 期限
用户存在因以下事件结果而改变：
○蜂窝电话的开机和关机
○从softphone修改注册
○改变即时传信工具的状态
这些事件通常由人为干预触发，而且以大约几分钟或几小时的频率发生。因此，预订的期限应在这个范围之内，大约一个小时。因此，在这个事件包内预订的缺省期限为3600秒。按照[3]，用户可包含一个可选期限。不管所指示的期限是多少，服务器可减小它，但不能增大它。
5.4 “通知”主体
通知的主体包含存在文档。这篇文档描述预订的presentity的用户存在。所有用户必须支持在[以IMPP文档TBD填充]中描述的存在数据格式，而且必须列出其MIME类型，在“预约”请求中存在的接受信头[以MIME类型填充]。
将来可以定义其他存在数据格式。在此情况下，预订可指示支持其他存在格式。然而，它们必须总是支持和列出[以MIME类型的IMPP存在文档填充]作为许可格式。
当然，由存在代理产生的通知必须是在“预约”请求的接受信头中指定的其中一种格式。
5.5 在PA的处理需求
用户存在是极为敏感的信息。由于泄漏存在信息的暗示是严重的，因此对PA就预订处理施加强硬要求，特别是关于鉴权和授权。
存在代理必须鉴权所有预订请求。这个鉴权可利用为SIP定义的任何机制执行。不认为鉴权可传递就足够了；也就是说，鉴权应使用端到端机制。不能使用SIP基本鉴权机制。
推荐未被鉴权的任何预订不会引起在PA建立状态。这可通过响应该“预约”生成401，接着丢弃用于该事物处理的所有状态实现。“预约”的重发产生相同响应，保证甚至通过UDP的可靠性。
此外，除非已经由presentity提供授权PA不能接受预订。提供授权的方式不在这篇文档的范围之内。通过可能在网页中指定的访问列表可提前提供授权。可能已经通过上载某种标准化访问控制列表文档提供授权。也可使用后端授权服务器，如DIAMETER[5]，RADIUS [6]或COPS[7]。在接收到不存在授权信息的预订请求后能查询用户是否被授权也很有用。附件A提供了对于这种情况的一种可能的解决方案。
服务器的授权判决结果将为拒绝、接受或未决。未决发生在服务器此刻无法获得授权，而在presentity变为可用的稍后时间能获得授权时。
遗憾的是，如果服务器通知用户该预订未决，这将泄漏有关该presentity的信息——即，他们没有给予授权而且此刻也无法给予。因此，PA应对未决和接受预订产生相同响应。这个响应应为202Accepted响应。
如果服务器通知用户该预订被拒绝，这也泄漏了有关该presentity的信息——即，他们之前已经明确阻止该预订，或他们此刻能选择拒绝该预订。如果服务器的策略是不透露这个信息，那么PA可以以202 Accepted响应回应，即使该预订被拒绝。或者，如果该presentity或PA的策略是通知用户该拒绝是可接受的，则应使用603 Decline。
应指出，由于对预订的响应不包含有关该presentity的任何有用信息，因此不认为“预约”响应的保密和完整性很重要。
5.6 产生通知
PA一接受预订，就应产生具有该presentity的当前存在状态的即时“通知”。
如果接收到预订，并且该预订被标上未决或被拒绝，则PA应产生即时“通知”。这个“通知”应包含对于该presentity的有效状态，而不是不提供有关presentity的有用信息的“通知”。这样的例子是提供与存在URL具有相同形式的IM URL，并且标记IM地址为“不可用”。这种“说谎”处理的原因是，如果没有它，用户可基于即时“通知”的存在和内容告知未决预订和接受预订之间的区别。在此定义的方案保证在由未决或拒绝预订产生的“通知”中传送的存在也是可能已经在由接受预订产生的“通知”中传送的有效存在。
如果存在服务器或presentity的策略是可接受泄漏有关该预订是否成功的信息，则不需要为未决或拒绝预订发送即时“通知”。
当然，一旦接受预订，在PA确定presentity的存在状态改变时PA应对该预订产生“通知”。第6节描述了PA如何作出这种确定。
由于保密原因，经常必须加密通知的内容。这可利用标准SIP加密机制实现。应利用在“预约”的From字段识别的用户的密钥来执行加密。类似地，通知的完整性对用户也很重要。因此，应利用其中一种标准化SIP机制鉴权通知的内容。由于“通知”是由存在服务器生成的，存在服务器可能无法得到由presentity表示的用户的密钥，因此经常存在这样一种情况，即，“通知”由第三方签名。推荐该签名通过该presentity域的权威签署。换言之，对于用户pres：user@example.com，“通知”的签名人应为example.com的权威。
5.7 “通知”的速率限制
由于拥塞控制的原因，通知的速率不过高很重要。因此，推荐在高于每5秒一次的速率下PA不为单个presentity产生通知。
5.8 更新行为
由于在其他方法中“预约”被代理路由，有可能预订可分叉。其结果是对于同一presentity预订可能到达配置用来充当PA的多个设备。每个这些设备将以202响应对该“预约”响应。基于SIP中的分叉规则，这些响应中只有一个被传递到用户。然而，用户将接收到来自接受该预订的每个这些PA的通知。SIP事件结构允许每个包定义对此情况的处理。
在此情况下的处理与处理INVITE的方式相同。对该“预约”的202 Accepted将导致设置用户的预订状态。该预订与To和From(均具有标记)以及来自202的Call-ID相关。当通知到达时，那些来自PA，且202在分叉的代理被丢弃的通知将不会匹配在该用户存储的预订ID(From标记将不同)。这些应以481进行响应。这将使来自这些PA的预订无效。此外，当更新该预订时，该更新应利用来自202的标记并利用任何联系或记录-路由信头，以便将该“预约”传送回发送202的同一PA。
其结果是presentity可具有多个有效的PA，但这些PA应是同类的，这样每个PA都能为该presentity生成相同的通知集合。为存在数据的子集生成通知的支持的不同类PA很复杂且难于管理。如果需要这种功能，则可借助B2BUA而不是通过分叉代理实现。
6.公布
可通过多种不同方式获得对于presentity的用户存在。基线SIP定义了一种可以被所有SIP客户使用的方法-“注册”方法。这个方法允许UA通知SIP网络其当前通信地址(即，联系地址)。此外，多个UA可独立地为同一SIP URL注册联系地址。这些联系地址可以是SIP URL，或它们可以是任何其他有效的URL。
使用注册信息用于存在是直截了当的。在“注册”中的记录地址(To字段)识别该presentity。联系信头定义描述该presentity的状态的通信地址。推荐使用SIP主叫优先扩展[8]以与对存在感兴趣的UA一起使用。其提供有关可用于构成更丰富的存在文档的联系地址的附加信息。联系信头的“描述”属性在此被明确定义以用作允许用户定义在该通信地址presentity的状态的free-from字段。
我们还允许“注册”请求包含存在文档，这样PUA可公布更多复杂信息。
应指出，我们不提供锁定机制，这种锁定将允许客户锁定存在状态，取出它，并自动修改它。我们认为，对于大部分用户情况不需要这种机制，而且它将带来大的复杂度。大部分存在操作不需要在设置前获取(get-before-set)，因为SIP注册机制工作于不用获取就能更新数据的方式。
注册联系到存在的应用增加了对可靠性的需求。因此，应利用SIP鉴权机制或通过跳跃(hop by hop)机制鉴权存在用户代理使用的“注册”请求。
为指示即时传信的存在，UA可借助设置用来指示方法MESSAGE的“方法”参数注册作为SIP URL的联系地址，或可注册IM URL。
TODO：这一节需要研究。只要IMPP生成文档格式，就需要定义映射注册到存在文档的具体例子。
6.1 转移PA功能
实现PA功能与若干单元共址很重要：
○ PA功能可与为该presentity处理注册的代理服务器共址。通过这种方式，PA通过注册知道用户的存在。
○ PA功能可与用于该presentity的PUA共址。在每个presentity有单个PUA的情况下，PUA通过其共址的真实特征了解该presentity的状态。
○ PA功能可在沿该呼叫建立路径的任何代理共址。该代理可通过生成其自己的SUBSCRBIE了解presentity的存在状态以便确定它。在此情况下，PA是有效的B2BUA。
由于预订的软状态特征，在预订的使用期限内PA功能可转移。最切实可行的情况是PA功能从存在服务器转移到PUA，然后返回。
考虑在存在服务器安装的预订。假设存在服务器能确定下行流UA能对该presentity充当PA的时刻。当预订更新到达时，PA破坏其预订，接着充当该预订的代理。接着该预订被路由到UA，在此该预订被接受。结果是该预订变成在PUA内安装。
为使这种转移能运作，PUA必须准备接受在To字段已经包含标记的“预约”请求。此外，PUA必须插入联系信头到202中，而且这个信头必须被用户用来为该预订更新联系地址。
TODO：这起作用吗？在PUA的适当位置获取记录-路由如何。这可能只用于不使用路由或标记的更新。
存在服务器通过“注册”消息确定PUA能支持PA功能。具体来说，如果PUA希望指示支持PA功能，在其注册中应包括联系地址，其中具有列出“预约”的主叫优先“方法”参数。
7.映射到CPIM
这一节定义对于存在消息SIP如何被转换为CPIM，以及CPIM消息如何被转换为SIP用于存在。SIP到CPIM的转换发生在SIP系统发送的“预约”请求包含，对应运行不同存在协议的域中的用户的pres URL或SIP URL。CPIM到SIP涉及不同协议域中的用户生成指定用于SIP域中的用户的预订的情况。
应指出，下面定义的过程要求网关存储预订状态。这种不利结果是因为需要记录Call-ID，Cseq，以及来自SIP一侧的预订的路由信头，以便它们能被插入到在CPIM通知到达时生成的SIP“通知”中。
7.1 SIP到CPIM
通过图1描绘的SIP到CPIM的抽象网关服务，用于存在的SIP被转换为CPIM。
图1：SIP到CPIM变换
第一个步骤是“预约”请求在网关被接收。网关生成CPIM预订请求，其参数填充如下：
○从“预约”的From字段拷贝CPIM消息中的看守人身份。如果From字段包含SIP URL，则通过删去所有SIP URL参数，并改变其模式为pres，将SIP URL变换为等效的pres URL。
这种变换可能不起作用——如果SIP URL没有用户名怎么办。加上，以这种方式从URL变换回URN可能不能正确执行。
○从“预约”的Request-URI字段拷贝CPIM消息中的目标身份。这也可能需要变换为pres URL。
○从“预约”的期限信头拷贝CPIM消息中的持续时间参数。如果期限信头指定的是绝对时间，则其被网关转换为增量时间。如果不存在期限信头，则假设为一个小时。
○通过附加Call-ID、To字段中的URI、From字段中的URI、From字段中的Cseq和标记，以及请求URI，并计算所产生的字符串散列，构成CPIM消息中的transID参数。这个散列被用作transID。应指出，请求URI被包含在该散列中。这将区分可到达同一网关的SIP网络内的分叉请求。
CPIM服务接着以成功或失败响应。若成功，SIP到 CPIM网关服务生成对该“预约”的202响应。其添加一个标记到该响应中的To字段，这个标记与成功响应中的transID字段相同。202响应还包含联系信头，这是来自“预约”请求的目标的值。联系信头被设置为该目标很重要，因为这确保在请求URI中预订更新具有与原预订相同的值。来自CPIM成功响应中的持续时间值被置于202的期限信头中。网关存储为该预订设置的Call-ID和路由信头。
如果CPIM服务以失败响应，则SIP到CPIM网关生成603响应。其添加一个标记到该响应中的To字段，这个标记与失败响应中的transID字段相同。
当CPIM系统产生通知请求时，SIP到CPIM网关创建SIP“通知”请求。该请求是利用用于在呼叫路径内构建请求的标准RFC2543[2]程序构成的。这将导致To字段包含来自CPIM的看守人字段，以及From字段包含来自CPIM通知的目标字段。From字段中的标记将包含transID。存在信息被拷贝到通知的主体。Call-ID和路由信头是从网关中存储的预订状态构成的。如果尚未为这个预订生成通知，则选择并存储一个初始Cseq值。
与上述的初始预订一样处理“预约”更新。
如果接收预订的期限为0，则SIP到CPIM网关生成未预订消息到CPIM系统中。从“预约”的From字段拷贝看守人参数。从“预约”的请求URI字段拷贝目标函数。从“预约”请求的To字段中的标记拷贝TransID。
对未预订的响应不是成功就是失败。若成功，则以与上述对CPIM用户的成功响应的相同方式构成202响应。清除所有预订状态。若失败，则以上述的相同方式构成603响应，接着清除预订状态，如果存在的话。
7.2 CPIM到SIP
CPIM到SIP变换发生在CPIM预订请求到达网关的CPIM一侧时。图2示意了这种情况。
图2：CPIM到SIP变换
CPIM预订请求被变换为SIP“预约”请求。为此，第一个步骤是确定该预订是否针对现有预订。这是通过取出CPIM预订请求中的目标，并将其与现有预订的目标进行比较执行的。如果不匹配，则其为新预订，否则是更新。
如果是新预订，则网关以下述方式生成SIP“预约”请求：
○该请求中的From字段被设置为CPIM预订请求中的看守人字段。
○该请求中的To字段被设置为CPIM预订请求中的目标字段。
○“预约”请求中的期限信头被设置为CPIM预订请求中的持续时间字段。
○ From字段中的标记被设置为CPIM预订请求中的transID。
接着发送这个“预约”消息。
如果该预订是更新，则以相同方式生成“预约”请求。然而，还有To字段中的一个标记，它是从网关的预订状态拷贝的，以及一个从网关的预订状态获得的路由信头。
当接收到对该“预约”的响应时，发送一个响应到CPIM系统。从该“预约”响应的期限信头拷贝这个响应的持续时间参数(可能需要从绝对时间到增量时间的变换)。从该响应的From字段中的标记拷贝该响应的transID。如果该响应是202，则状态被设置为不确定。如果该响应是任何其他200类响应，则状态被设置为成功。对于任何其他最终响应，状态被设置为失败。
如果该响应是200类响应，则建立预订状态。这个状态包含来自“预约”响应中的To字段的标记，以及从200类响应中的记录-路由和联系信头计算的路由信头集合。该预订由presentity识别(生成的“预约”的To字段)索引。
如果从CPIM侧接收到未预订请求，则网关检查该预订是否存在。如果存在，则如上所述生成“预约”。然而，期限信头被设置为0。如果预订不存在，则网关生成失败响应并将其发送到CPIM系统。当对该“预约”请求的响应到达时，其如同上面对初始“预约”响应描述的那样被转换为CPIM响应。就一切情况而论，网关中的任何预订状态都被破坏。
当从SIP系统接收到“通知”时，发送CPIM通知请求。这个通知如下构成：
○ CPIM看守人被设置为“通知”的To字段中的URI。
○ CPIM目标被设置为“通知”的From字段中的URI。
○利用如同对第7.1节的“预约”相同的机制计算transID。
○从SIP“通知”请求的主体中提取通知的存在成分。
网关对SIP“通知”产生200响应并发送。
TODO：具有所述参数的一些呼叫流程图。
8 防火墙和NAT遍历
希望存在服务将被连接位于防火墙和NAT另一侧的代理服务器的客户和presentity使用。幸好，由于SIP存在消息并不像INVITE那样建立独立的媒体流，因此防火墙和NAT遍历比在[9]和[10]中描述的简单得多。
一般来说，当通过由防火墙/NAT内部的设备建立的TCP或TLS连接发送数据到外部的设备时，数据遍历NAT和防火墙。因此，推荐用于存在实体的SIP保持持久的TCP或TLS连接到它们下一跳的同位体。这包括被开放用来发送“预约”，“通知”，以及最重要的“注册”的连接。通过保持后一连接开放，其可被SIP代理用来从防火墙/NAT外部发送消息返回客户。还推荐客户在它们的注册中包括如在[10]描述的联系cookie，以便代理可映射presentity URI到该连接。
此外，在防火墙或NAT任何一侧的实体应记录-路由，以便保证为该预订建立的初始连接也用于这些通知。
9.安全考虑
对于存在有多种安全考虑。上面概述了许多安全考虑事项；这一节逐个进行解释。
9.1 保密
保密包括存在系统的许多方面：
○用户可能不想透露他们已经预订某些用户的事实。
○用户可能不想透露他们已经接受来自某些用户的预订。
○通知(以及取出结果)可能包含不应被透露给除该用户之外的任何人的敏感数据。
通过逐段加密和端对端加密的组合提供保密。逐段机制提供可升级的保密服务，禁止涉及业务分析的攻击，并隐藏存在消息的所有方面。然而，他们基于信任的传递性工作，而且他们使消息内容被泄漏给代理。端到端机制不需要信任的传递性，并只透露消息给所想要的收信方。然而，端对端加密无法隐藏所有信息，而且容易进行业务分析。牢固的端对端鉴权和加密还需要参与双方都有公共密钥，而通常做不到。因此为了得到完整的保密服务需要这两种机制组合。
SIP允许任何逐段加密方案。推荐在网络服务器之间(代理到代理，代理到重定向服务器)，传输模式ESP[11]用于加密整个消息。在UAC和其本地代理之间，推荐TLS[12]。类似地，应在存在服务器和PUA之间使用TLS。
存在服务器可基于其注册的联系信头中的传输参数确定TLS是否被接收的客户支持。如果该注册包含作为传输的“tls”标记，则隐含PUA支持TLS。
此外，我们考虑到“预约”请求中的联系信头包含作为传输的TLS。联系信头用于在一对实体之间路由后续消息。其定义用于与用户代理通信的地址和传输。即使可能在用户和其本地代理之间使用TLS，但将这个参数置于联系信头意味着TLS也可被端到端使用，以在成功路由了初始“预约”消息后生成通知。这将提供具有低代理总开销的端到端保密和鉴权服务。
SIP加密可被端到端使用以发送“预约”和“通知”请求。SIP支持基于PGP的加密，这种加密不需要为加密给定预订内的消息建立会话密钥(基本上，为每个消息建立一个新会话密钥作为PGP加密的一部分)。最近开始研究对SIP使用S/MIME[13]。
9.2 消息完整性和可靠性
消息收信方保证这些消息内容确实是发信方发送的消息，以及消息的收信方能确定真正的发信方是谁很重要。这对“预约”和“通知”的请求和响应同样适用。这在SIP是通过端对端鉴权和消息完整性支持的。SIP提供基于PGP的鉴权和完整性(查询-响应和公共密钥签名)，以及http基本和分类鉴权。不推荐HTTP基本鉴权。
9.3 输出鉴权
当本地代理用于传输输出消息时，推荐代理鉴权。这对于检验发信方的身份，以及防止发送网络欺骗和兜售信息很有用。
9.4 重放预防
为防止重放旧的预订和通知，所有签名的“预约”和“通知”请求和响应必须包含该消息签名涉及的数据信头。日期早过去几分钟或在将来几分钟的任何消息应被丢弃。
此外，所有签名的“预约”和“通知”请求必须包含该消息签名涉及的Call-ID和CSeq信头。用户代理或存在服务器可存储一个Call-ID值列表，以及对每个Call-ID值，在该Call-ID内看到的最高CSeq。对于存在的Call-ID，，CSeq低于迄今看到的最高值的到达的任何消息应被丢弃。
最后，查询-响应鉴权(http分类或PGP)可用于防止重放攻击。
9.5 拒绝服务攻击
拒绝服务攻击是开放的、域间存在协议的关键问题。在此我们讨论几种可能的攻击，以及我们采取的预防措施。
9.5.1 通过假接触的smurf攻击
遗憾的是，由于存在的放大特性，其是smurfing攻击的好对象。只要能找到适当的存在数据动态源，单个“预约”消息可生成几乎无尽的通知流。因此，发起攻击的简单方式是发送预订给大量用户，并在联系信头(这是发送通知的地方)放置该目标的地址。
防止这些攻击的唯一一种可靠方式是通过鉴权和授权。端用户希望不接受来自随机的未被识别的用户的预订。而且可编程存在客户软件以在“预约”中的联系信头来自不匹配From字段(其识别用户)的域时提示用户。
而且注意，如同[3]中描述的，如果“通知”未被确认或不被需要，则清除生成的预订。这就消除了提供假联系地址的放大特性。
10.消息流实例
下面的小节示意消息流实例，以进一步阐明该协议的工作情况。
10.1 presentity状态改变的客户到客户预订
这个呼叫流程示意了不涉及存在服务器的预订和通知。
看守人预订该presentity，该预订被接受，导致202 Accepted响应。该presentity随后改变状态(在电话上)，导致产生新通知。该流程以看守人取消该预订结束。
|<---------------------------------------|
消息详细资料
F1 “预约”看守人->presentity
“预约”sip：presentity@pres.example.com SIP/2.0
Via：SIP/2.0/UDP watcherhost.example.com：5060
From：User<pres：user@example.com>
To：Resource<pres：presentity@example.com>
Call-ID：3248543@watcherhost.example.com
CSeq：1“预约”
Expires：600
Accept：application/xpidf+xml
Event：presence
Contact：sip：user@watcherhost.example.com
F2 202 Accepted presentity->看守人
SIP/2.0 202 Accepted
Via：SIP/2.0/UDP watcherhost.example.com：5060
From：User<pres：user@example.com>
To： Resource
<pres：presentity@example.com>；tag＝88a7s
Call-ID：3248543@watcherhost.example.com
Cseq：1“预约”
Event：presence
Expires：600
Contact：sip：presentity@pres.example.com
F3 “通知”Presentity->看守人
“通知”sip：user@watcherhost.example.com
SIP/2.0
Via：SIP/2.0/UDP pres.example.com：5060
From： Resource
<pres：presentity@example.com>；tag＝88a7s
To：User<pres：user@example.com>
Call-ID：3248543@watcherhost.example.com
CSeq：1“通知”
Event：presence
Content-Type：application/xpidf+xml
Content-Length：120
<？xml version＝＂1.0＂？>
<presence
entityInfo＝＂pres：presentity@example.com＂>
<tuple destination＝＂sip：presentity@example.com＂
status＝＂open＂/>
</presence>
F4 200 OK看守人->presentity
SIP/2.0 200 OK
Via：SIP/2.0/UDP pres.example.com：5060
From：Resource<pres：presentity@example.com>
To：User<pres：user@example.com>
Call-ID：3248543@watcherhost.example.com
CSeq：1 “通知”
F5“通知”Presentity->看守人
“通知”sip：user@watcherhost.example.com
SIP/2.0
Via：SIP/2.0/UDP pres.example.com：5060
From：Resource<pres：presentity@example.com>
To：User<pres：user@example.com>
Call-ID：3248543@watcherhost.example.com
CSeq：2“通知”
Event：presence
Content-Type：application/xpidf+xml
Content-Length：120
<？xml version＝＂1.0＂？>
<presence
entityInfo＝＂pres：presentity@example.com＂>
<tuple destination＝＂sip：presentity@example.com＂
status＝＂closed＂/>
</presence>
F6 200 OK看守人->presentity
SIP/2.0 200 OK
Via：SIP/2.0/UDP pres.example.com：5060
From：Resource<pres：presentity@example.com>
To：User<pres：user@example.com>
Call-ID：3248543@watcherhost.example.com
CSeq：2“通知”
F7“预约”看守人->presentity
“预约”sip：presentity@pres.example.com SIP/2.0
Via：SIP/2.0/UDP watcherhost.example.com：5060
From：User<pres：user@example.com>
To：Resource<pres：presentity@example.com>
Call-ID：3248543@watcherhost.example.com
Event：presence
CSeq：2“预约”
Expires：0
Accept：application/xpidf+xml
Contact：sip：user@watcherhost.example.com
F8 202 Accepted presentity->看守人
SIP/2.0 2 02 Accepted
Via：SIP/2.0/UDP watcherhost.example.com：5060
From：User<pres：user@example.com>
To：Resource<pres：presentity@example.com>
Call-ID：3248543@watcherhost.example.com
Event：presence
Cseq：2“预约”
Expires：0
10.2 具有客户通知的存在服务器
这个呼叫流程示意了在处理预订时涉及存在服务器。在此情况下，客户已经指示其将处理预订，由此处理通知。该消息流示意了客户改变存在状态以及看守人取消预订。
消息详细资料
F1“注册”PUA->服务器
“注册”sip：example.com SIP/2.0
Via：SIP/2.0/UDP pua.example.com：5060
To：<sip：resource@example.com>
From：<sip：resource@example.com>
Call-ID：2818@pua.example.com
CSeq：1“注册”
Contact：<sip：id@pua.example.com>；methods＝＂MESSAGE＂
；description＝＂open＂
Contact：<sip：id@pua.example.com>；methods＝＂“预约”＂
Expires：600
F2 200 OK 服务器->PUA
SIP/2.0 200 OK
Via：SIP/2.0/UDP pua.example.com：5060
To：<sip：resource@example.com>
From：<sip：resource@example.com>
Call-ID：2818@pua.example.com
CSeq：1“注册”
Contact：
<sip：id@pua.example.com>；methods＝＂MESSAGE＂
；description＝＂open＂
Contact：<sip：id@pua.example.com>；methods＝＂“预约”＂
Expires：600
F3“预约”看守人->服务器
“预约”sip：resource@example.com SIP/2.0
Via：SIP/2.0/UDP watcherhost.example.com：5060
From：User<pres：user@example.com>
To：Resource<pres：resource@example.com>
Call-ID：32485@watcherhost.example.com
CSeq：1“预约”
Expires：600
Event：presence
Accept：application/xpidf+xml
Contact：sip：user@watcherhost.example.com
F4“预约”服务器->PUA
“预约”sip：id@pua.example.com SIP/2.0
Via：SIP/2.0/UDP server.example.com：5060
Via：SIP/2.0/UDP watcherhost.example.com：5060
From：User<pres：user@example.com>
To：Resource<pres：resource@example.com>
Call-ID：32485@watcherhost.example.com
CSeq：1“预约”
Event：presence
Expires：600
Accept：application/xpidf+xml
Contact：sip：user@watcherhost.example.com
F5 202 Accepted PUA->服务器
SIP/2.0 202 Accepted
Via：SIP/2.0/UDP server.example.com：5060
Via：SIP/2.0/UDP watcherhost.example.com：5060
From：User<pres：user@example.com>
To：Resource<pres：resource@example.com>；tag＝ffd2
Call-ID：32485@watcherhost.example.com
CSeq：1“预约”
Event：preSence
Expires：600
F6 200 OK 服务器->看守人
SIP/2.0 202 Aceepted
Via：SIP/2.0/UDP watcherhost.example.com：5060
From：User<pres：user@example.com>
To：Resource<pres：resource@example.com>；tag＝ffd2
Call-ID：32485@watcherhost.example.com
CSeq：1“预约”
Event：presence
Expires：600
F7“通知” PUA->看守人
“通知” sip：user@watcherhost.example.com
SIP/2.0
Via：SIP/2.0/UDP pua.example.com：5060
To：User<pres：user@example.com>
From： Resource
<pres：resource@example.com>；tag＝ffd2
Call-ID：32485@watcherhost.example.com
CSeq：1“通知”
Event：presence
Content-Type：application/xpidf+xml
Content-Length：120
<？xml version＝＂1.0＂？>
<presence entityInfo＝＂pres：resource@example.com＂>
<tuple destination＝＂im：resource@example.com＂
status＝＂open＂/>
</presence>
F8 200 OK 看守人->PUA
SIP/2.0 200 OK
Via：SIP/2.0/UDP pua.example.com：5060
To：User<pres：user@example.com>
From： Resource
<pres：resource@example.com>；tag＝ffd2
Call-ID：32485@watcherhost.example.com
CSeq：1“通知”
F9“注册”PUA->服务器
“注册”sip：example.com SIP/2.0
Via：SIP/2.0/UDP pua.example.com：5060
To：<sip：resource@example.com>
From：<sip：resource@example.com>
Call-ID：2818@pua.example.com
CSeq：2“注册”
Contact：
<sip：id@pua.example.com>；methods＝＂MESSAGE＂
；description＝＂busy＂
Contact：<sip：id@pua.example.com>；methods＝＂“预约”＂
Expires：600
F10 200 OK 服务器->PUA
SIP/2.0 200 OK
Via：SIP/2.0/UDP pua.example.com：5060
To：<sip：resource@example.com>
From：<sip：resource@example.com>
Call-ID：2818@pua.example.com
CSeq：2“注册”
Contact：
<sip：id@pua.example.com>；methods＝＂MESSAGE＂
；description＝＂busy＂
Contact：<sip：id@pua.example.com>；methods＝＂“预约”＂
Expires：600
F11“通知”PUA->看守人
“通知”sip：user@watcherhost.example.com
SIP/2.0
Via：SIP/2.0/UDP pua.example.com：5060
To：User<pres：user@example.com>
From： Resource
<pres：resource@example.com>；tag＝ffd2
Call-ID：32485@watcherhost.example.com
CSeq：2“通知”
Event：presence
Content-Type：application/xpidf+xml
Content-Length：120
<？xml version＝＂1.0＂？>
<presence entityInfo＝＂pres：resource@example.com＂>
<tuple destination＝＂im：resource@example.com＂
status＝＂busy＂/>
</presence>
F12 200 OK 看守人->PUA
SIP/2.0 200 OK
Via：SIP/2.0/UDP pua.example.com：5060
To：User<pres：user@example.com>
From： Resource
<pres：resource@example.com>；tag＝ffd2
Call-ID：32485@watcherhost.example.com
CSeq：2“通知”
10.3 存在服务器通知
这个消息流示意了存在服务器如何负责为presentity发送通知。如果presentity尚未发送指示有兴趣处理预订的注册，则存在服务器将做这个工作。这个消息流假设看守人之前已经被授权预订位于服务器的这个资源。
消息详细资料
F1“预约”看守人->服务器
“预约”sip：resource@example.com SIP/2.0
Via：SIP/2.0/UDP watcherhost.example.com：5060
To：<pres：resource@example.com>
From：<pres：user@example.com>
Call-ID：2010@watcherhost.example.com
CSeq：1“预约”
Event：presence
Accept：application/xpidf+xml
Contact：<sip：user@watcherhost.example.com>
Expires：600
F2 202 OK 服务器->看守人
SIP/2.0 202 Accepted
Via：SIP/2.0/UDP watcherhost.example.com：5060
To：<pres：resource@example.com>；tag＝ffd2
From：<pres：user@example.com>
Call-ID：2010@watcherhost.example.com
CSeq：1“预约”
Event：presence
Expires：600
Contact：sip：example.com
F3“通知” 服务器->看守人
“通知”sip：user@watcherhost.example.com SIP/2.0
Via：SIP/2.0/UDP server.example.com：5060
From：<pres：resource@example.com>；tag＝ffd2
To：<pres：user@example.com>
Call-ID：2010@watcherhost.example.com
Event：presence
CSeq：1“通知”
Content-Type：application/xpidf+xml
Content-Length：120
<？xml version＝＂1.0＂？>
<presence entityInfo＝＂pres：resource@example.com＂>
<tuple destination＝＂im：resource@example.com＂
status＝＂open＂/>
</presence>
F4 200 OK
SIP/2.0 200 OK
Via：SIP/2.0/UDP server.example.com：5060
From：<pres：resource@example.com>；tag＝ffd2
To：<pres：user@example.com>
Call-ID：2010@watcherhost.example.com
CSeq：1“通知”
F5 “注册”
“注册”sip：example.com SIP/2.0
Via：SIP/2.0/UDP pua.example.com：5060
To：<sip：resource@example.com>
From：<sip：resource@example.com>
Call-ID：11 0@pua.example.com
CSeq：2“注册”
Contact：
<sip：id@pua.example.com>；methods＝＂MESSAGE＂
；description＝＂Away from keyboard＂
Expires：600
F6 200 OK
Via：SIP/2.0/UDP pua.example.com：5060
To：<sip：resource@example.com>
From：<sip：resource@example.com>
Call-ID：110@pua.example.com
CSeq：2“注册”
Contact：
<sip：id@pua.example.com>；methods＝＂MESSAGE＂
；description＝＂Away from keyboard＂
；expires＝600
F7“通知”
“通知”sip：user@watcherhost.example.com SIP/2.0
Via：SIP/2.0/UDP server.example.com：5060
From：<pres：resource@example.com>；tag＝ffd2
To：<pres：user@example.com>
Call-ID：2010@watcherhost.example.com
CSeq：2“通知”
Event：presence
Content-Type：application/xpidf+xml
Content-Length：120
<？xml version＝＂1.0＂？>
<presence entityInfo＝＂pres：resource@example.com＂>
<tuple destination＝＂im：resource@example.com＂status＝＂Away from keyboard＂/>
</presence>
F8 200 OK
SIP/2.0 200 OK
Via：SIP/2.0/UDP server.example.com：5060
From：<sip：resource@example.com>；tag＝ffd2
To：<pres：user@example.com>
Call-ID：2010@watcherhost.example.com
CSeq：2“通知”
11.公开问题
以下列出了已知的公开问题：
○这个草案推荐To和From字段填充存在URL而不是sipURL。这合理吗？这会导致代理不兼容吗？如果使用SIP URL格式CPIM会有问题吗？这取决于在CPIM中为消息的什么部分签名。
○对“通知”的速率限制：我们想要这样吗？我们如何取值？5秒是任选的。
○取消从多个PA合并存在数据。这样对吗？
○将IM URL置于“注册”的联系信头：这样对吗？这意味着什么？
○从存在服务器转移预订到PUA的过程不可能在预订更新使用标记和路由信头的情况下工作。因此我们有选择权。或者禁止转移，我们保存面向路径的预订，或允许转移，没有标记或路由与预订相关。
○将SIP URL转换回pres URL。
○ SIP到CPIM以及CPIM到SIP不是无状态的，因为需要保存Route，Call-ID，CSeq和其他参数。我们可要求CPIM定义在CPIM请求中发送并在CPIM响应中返回的标记值。这有帮助吗？
○需要指定如何从“注册”取出联系(Contact)以及建立存在文档。一件显然的事情是联系地址并不直接进入；你可能想放置记录地址，否则呼叫可能不会通过该代理。
12.从-00的变化
该文档已经被完全改写以反映从“路边摊”到更正式的协议规范的变化。其也变得匹配SIP事件体系结构和CPIM。从这个改写产生的特定协议变化有：
○事件信头现在必须被用在“预约”和“通知”请求。
○“预约”消息只能有一个联系信头。-00允许有一个以上联系信头。
○ From和To信头可包含存在URI。
○请求-URI可包含存在URI。
○如果预订未决或被接受则以202响应预订。
○在“预约”响应的主体中不返回存在文档。而是在独立的“通知”中发送它们。这将更干净地分隔预订和通知，而且与CPIM匹配。
○目前在PA鉴权是强制的。在PA授权也是强制的。
○为未决或拒绝的预订发送分叉“通知”。
○引入对通知的速率限制。
○已经取消合并存在数据。
○用户拒绝接收其标记不匹配对“预约”的202响应中的标记的通知。这意味着只有一个PA将对特定presentity为特定用户保持预订状态。
○在注册中在Contact允许IM URL。
○定义CPIM映射。
○为防火墙遍历推荐持久连接。
获得授权
当预订到达PA时，预订需要由presentity授权。在一些情况下，presentity可能已经提前提供授权。然而在许多情况下，用户未被预先授权。在此情况下，PA需要询问presentity是否授权。
为此，我们在PA定义隐含预订。这个预订是针对虚拟presentity的，这是“对presentity X的预订集合”，而且对该虚拟presentity的用户是X本身。每当为X接收到预订时，虚拟presentity改变状态以反映X的新预订。对于被认可的预订以及未决的预订这个状态改变。结果，当需要授权的预订到达时，虚拟presentity的状态改变以指示未决预订。虚拟presentity的整个状态接着被发送到用户(presentity本身)。通过这种方式，在该presentity后的用户可看到存在未决预订。其可接着使用一些非SIP手段在涉及该新用户的服务器建立策略。这个策略接着用于接受或拒绝该预订。
图3示意了用于此的呼叫流程。
在presentity不在线的情况下，问题还是直截了当的。当用户登陆它们的存在客户时，其可取出对X的虚拟presentity的状态，检查是否为未决预订，并对每个预订上载指示采取的适当动作的新策略。
在[14]可找到表示这些虚拟presentity的状态的数据格式。
图3：在线授权的序列图
A.致谢
我们很想感谢以下人员对这个草案的支持和意见：
Rick Workman Nortel
Adam Roach Ericsson
Sean Olson Ericsson
Billy Biggs University of Waterloo
Stuart Barkley UUNet
Mauricio Arango SUN
Richard Shockey Shockey Consulting LLC
Jorgen Bjorkner Hotsip
Henry Sinnreich MCI Worldcom
Ronald Akers Motorola
B.作者地址
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover，NJ 07936
email：jdrosen@dynamicsoft.com
Dean Willis
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano，Texas 75024
email：dwillis@dynamicsoft.com
Robert Sparks
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano，Texas 75024
email：rsparks@dynamicsoft.com
Ben Campbell
5100 Tennyson Parkway
Suite 1200
Plano，Texas 75024
email：bcampbell@dynamicsoft.com
Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York，NY 10027-7003
email：schulzrinne@cs.columbia.edu
Jonathan Lennox
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York，NY 10027-7003
email：lennox@cs.columbia.edu
Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond，WA 98052-6399
email：huitema@microsoft.com
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond，W A 98052-6399
email：bernarda@microsoft.com
David Gurle
Microsoft Corporation
One Microsoft Way
Redmond，WA 98052-6399
email：dgurle@microsoft.com
David Oran
Cisco Systems
170 West Tasman Dr.
San Jose，CA 95134
email：oran@cisco.com
C.参考文献
[1]M.Day，J.Rosenberg，and H.Sugano，＂A model forpresence and instant messaging，＂Request for Comments 2778，Internet Engineering Task Force，Feb.2000.
[2]M.Handley，H.Schulzrinne，E.Schooler，and J.Rosenberg，＂SIP：session initiation protocol，＂Request for Comments2543，Internet Engineering Task Force，Mar.1999.
[3]A.Roach，＂Event notification in SIP，＂Internet Draft，Internet Engineering Task Force，Oct.2000.Work in progress.
[4]D.Crocker et al.，＂A common profile for instantmessaging(CPIM)，＂Internet Draft，Internet Engineering Task Force，Nov.2000.Work in progress.
[5]P.Calhoun，A.Rubens，H.Akhtar，and E.Guttman，＂DIAMETER base protocol，＂Internet Draft，Internet EngineeringTask Force，Sept.2000.Work in progress.
[6] C.Rigney，S.Willens，A.Rubens，and W.Simpson，＂Remote authentication dial in user service(RADIUS)，＂Request forComments 2865，Internet Engineering Task Force，June 2000.
[7] J.Boyle，R.Cohen，D.Durham，S.Herzog，R.Raj an，andA.Sastry，＂The COPS(common open policy service)protocol，＂Request for Comments 2748，Internet Engineering Task Force，Jan.2000.
[8]H.Schulzrinne and J.Rosenberg，＂SIP caller preferencesand callee capabilities，＂Internet Draft，Internet Engineering TaskForce，July 2000.Work in progress.
[9]J.Rosenberg，D.Drew，and H.Schulzrinne，＂Getting SIPthrough firewalls and NATs，＂Internet Draft，Internet EngineeringTask Force，Feb.2000.Work in progress.
[10]J.Rosenberg and H.Schulzrinne，＂SIP traversalthrongh enterprise and residential NATs and firewalls，＂InternetDraft，Internet Engineering Task Force，Nov.2000.Work in progress.
[11] S.Kent and R.Atkinson，＂IP encapsulating securitypayload(ESP)，＂Request for Comments 2406，Internet EngineeringTask Force，Nov.1998.
[12]T.Dierks and C.Allen，＂The TLS protocol version 1.0，＂Request for Comments 2246，Internet Engineering Task Force，Jan.1999.
[13]B.Ramsdell and Ed，＂S/MIME version 3 messagespecification，＂Request for Comments 2633，Internet EngineeringTask Force，June 1999.
[14]J.Rosenberg et al.，＂An XML based format for watcherinformation，＂Internet Draft，Internet Engineering Task Force，June2000.Work in progress.
目录
1 介绍
2 定义
3 操作概述
4 命名
5 存在事件包
5.1 包名
5.2 预订主体
5.3 期限
5.4 通知主体
5.5 在PA的处理需求
5.6 产生通知
5.7 对“通知”的速率限制
5.8 更新行为
6 公布
6.1 转移PA功能
7 映射到CPIM
7.1 SIP到CPIM
7.2 CPIM到SIP
8 防火墙和NAT遍历
9 安全考虑
9.1 保密
9.2 消息完整性和可靠性
9.3 输出鉴权
9.4 重放预防
9.5 拒绝服务攻击
9.5.1 通过假接触的Smurf攻击
10 消息流实例
10.1 Presentity状态改变的客户到客户预订
10.2 具有客户通知的存在服务器
10.3 存在服务器通知
11 公开问题
12 从-00的变化
A 致谢
B 作者地址
C 参考文献
附件B
3GPP TR 23.922 V1.0.0(1999-10)
技术报告书
第三代合作项目；
技术规范组业务和系统部分；
应用于全IP网络的体系结构；
(3G TR 23.922 版本1.0.0)
该文献已经在第三代合作项目(3GPPTM)的范围内展开，也可能对3GPP的目的作进一步的阐述。
该文献还没有获得3GPP组织的合作者的任何正式批准，不应被实施。
该技术规范仅供3GPP的未来研究工作。该组织的合作者对此规范的任何使用不承担责任。
参考书目
DTR/TSGS-0223922U
关键字
<UTMS，2000版，全IP网络>
3GPP
邮政地址
3GPP支持机构地址
650 Route des Lucioles-Sophia Antipolis
Valbonne-FRANCE
电话：+33 4 92 94 42 00传真：+33 4 93 65 47 16
网址：
http：//www.3gpp.org
目录
前言
1 范围
2 参考书目
3 定义和缩写
3.1 定义
3.2 缩写
4 要求
4.1 概述
4.1.1 一般要求
4.2 服务能力
4.2.1 概述
4.2.2 对服务和应用平台的基本要求
4.3 编号方案
4.4 99版终端
4.5 无线电方面
4.6 相互作用
4.7 移动性管理
4.8 漫游
4.9 切换
4.9.1 切换类别
4.9.2 一般定义
4.9.3 一般要求
4.9.4 MS要求
4.9.5 RAN要求
4.10 呼叫控制和漫游
4.11 安全性
5 全IP PLMN的结构
5.1 参考结构
5.1.1 参考结构-选项1
5.1.2 参考结构-选项2
5.1.3 什么是网络的边界
5.2 新功能单元
5.2.1 呼叫状态控制功能(CSCF)
5.2.2 本地用户服务器(HSS)
5.2.3 传输信令网关功能(T-SWG)
5.2.4 漫游信令网关功能(R-SGW)
5.2.5 复合网关
5.2.6 媒体网关控制功能(MGCF)
5.2.7 媒体网关功能(MGW)
5.2.8 多媒体资源功能(MRF)
5.2.9 MSC服务器
5.2.10 网关MSC服务器
5.3参考点的描述
5.3.1 Cx参考点(HSS-CSCF)
5.3.2 Gm参考点(CSCF-UE)
5.3.3 Mc参考点(MGCF-MGW)
5.3.4 Mh参考点(HSS-R-SGW)
5.3.5 Mm参考点(CSCF-多媒体全IP网络)
5.3.6 Mr参考点(CSCF-MRF)
5.3.7 Ms参考点(CSCF-R-SGW)
5.3.8 Mw参考点(CSCF-CSCF)
5.3.9 Nc参考点(MSC服务器-GMSC服务器)
5.3.10 Nb参考点(MGW-MGW)
5.3.11 SGSN到应用和业务
5.4 MAP/CAP的使用-MAP/CAP下的协议栈-全面考虑
6 服务质量QoS
7 切换
7.1 在UMTS 00版IP网络内的SRNC重定位
7.1.1 ERAN内要求的支持
7.1.2 全IP UTRAN到全IP ERAN的切换
7.2 SRNC在全IP和CS域/GSM之间的重定位/切换
7.2.1 要求
7.2.2 用支持MAP E的CSCF的解决方案
7.2.3 使用ISHF的系统间切换
7.3 需进一步研究的领域
8 无线领域
8.1 概述
8.2 对实时IP业务的空中链路优化
8.2.1 介绍
8.2.2 用户平面适应
8.2.3 全IP网络的应用
8.2.4 结论
9 呼叫控制
9.1 呼叫控制的术语
9.2 设想
9.3 全IP网络内的漫游
9.3.1 呼叫模式
9.3.2 场景1，传统模式
9.3.3 场景2
9.3.4 场景1：确保有效的信息流
9.3.5 场景2：确保有效的信息流
9.4 漫游到其他网络
9.4.1 对00版网络的漫游过程
9.4.2 对漫游的覆盖解决方案
9.5 公开问题
10 服务平台的影响
10.1 3GPP 2000版服务结构
10.2 基于IN的业务
10.2.1 遗留SCP和00版网络实体之间的基于“INAP”的接口
10.2.2 遗留SCP和00版网络实体之间的新的开放接口
10.3 要求进一步研究的问题
11 安全性
12 工作计划
12.1 00版大事记
12.1.1 00版大事记
12.1.1 详细的活动计划
历史
(此页无内容)
前言
该技术报告由3GPP制定。
该文献的内容应在该TSG内持续有效，如要改变需经TSG正式批准。假如TSG要修改此TS的内容，TSG必须以明确的出版日期变更和如下的版本号增加重新颁布：
版本x.y.z
在这里：
x第一个数字：
1表示为TSG提供信息；
2表示为TSG正式批准；
3表示为在变更控制下TSG正式批准的文本。
y第二个数字，对所有实质改变加1，例如：技术提高，修正和升级等。
z第三个数字，当该规范只包含编辑上的变化时加1。
1.范围
该技术报告将为00版提出一种提供全IP结构选项的结构。其目的是：
- 明确关键问题和需要解决的受到影响的进行中的3GPP工作，以及
- 为完成全IP 00版UMTS标准，提出高水准的工作计划，
以便在2000版内提供该结构选项。
2.参考
下面的文献包含一些规定，这些规定通过本文的参考资料组成了当前文本的规定。
●参考资料或者明确(有明确的出版日期，编号，版本号等)，或者不明确。
●对于明确的参考资料，后续的修订本不适用。
●对于不够明确的参考资料，最新版本适用。
●对一个ETS而言，不明确的参考资料也可拿去查阅具有相同号码的以EN形式出版的近期版本。
[1]TS22.101 3.6.0版：服务原则
[2]TS23.121：99版的结构要求。
[3]TS22.121：虚拟本地环境
[4]TS23.002：网络结构
[5]“适合于低速率序列链路的TCP/IP标题压缩”，IETF RFC1144，V.Jacobson
3.定义和缩写
3.1 定义
为了本文献更清晰，提供以下短语和定义：
现有服务：99版以及GSM和UMTS早期版本所提供的服务。
全IP核心网络：2000版的核心网络，该网络使用IP技术传输所有用户数据和信令。
ERAN被定义为发展的GSM BSS，它支持以200Khz为基础的EDEG调制方案和实时分组业务。
3.2 缩写
以下缩写适用于当前文本：
(首字母缩略词) (解释)
2G 第二代
3G 第三代
AMR 自适应多速率
AS 应用服务器
BSC 基站控制器
BTS 基站
CAMEL 移动网络增强型逻辑的用户定制应用
CAP CAMEL的应用部分
CC 呼叫控制
CCF 呼叫控制功能
CN 核心网络
CS 电路交换
CSCF 呼叫状态控制功能
CSE CAMEL的服务环境
DN 目录号
DNS 目录名服务器
EDGE GSM增强型数据
EGPRS 增强型GPRS
FFS 为了进一步研究
GGSN 网关GPRS支持节点
GMSC 网关MSC
GPRS 通用无线电分组业务
GSN GPRS支持节点
GTP GPRS隧道协议
H-CSCF 本地CSCF
HN 本地网
HSS 本地用户服务器
ICGW 来话呼叫网关
IN 智能网
INAP IN的应用部分
IP 网际协议
ISDN 综合业务数字网
ISP 因特网服务提供商
ISUP ISDN用户部分
LAN 局域网
LN 逻辑名
MAHO 移动台辅助切换
MAP 移动应用部分
MCU 媒体控制单元
MExE 移动执行环境
MGCF 媒体网关控制功能
MGW 媒体网关
MM 移动性管理
MO 移动台始发
MRF 媒体资源功能
MSC 移动交换中心
MT 移动终接/终端
NPA 编号方案区
O&M 操作与维护
ODB 操作者决定的禁止
OSA 开放的服务体系结构
PCU 分组控制单元
PDP 分组数据协议
PDU 分组数据单元
PS 分组交换
PSTN 公共交换电话网
QoS 服务质量
R00 2000版
R99 1999版
RA 路由选择区域
RAN 无线接入网
RLC/MAC 无线链路控制/媒体接入控制
RNC 无线网络控制器
R-SGW 漫游信令网关
RTP 实时协议
SAT SIM应用工具包
SCF 业务控制功能和业务能力特性
SCP 业务控制点
S-CSCF 正服务CSCF
SGSN 正服务GPRS支持节点
SIP 会话启动协议
SLA 服务级别协议
SN 正服务网络
SRNC 正服务无线网络控制器
SSF 业务交换功能
TCP 传输控制协议
TE 终端设备
T-SGW 传输信令网关
UDP 用户数据报协议
UE 用户设备
UMS 用户移动服务器
UTRAN 通用移动通信系统地面无线接入网
VHE 虚拟本地环境
VLR 来访位置寄存器
VoIP IP电话
VPN 虚拟专用网
WAP 无线应用协议
WIN 无线IN(ANSI-41)
4.要求
为了对TSG-SA2在UMTS内引进全IP结构有关的结构问题做一研究，对此结构的要求进行设想。作为2000版要求的工作包的一部分，TSG-SA1也被邀用来验证和扩展这些要求。
4.1 概述
全IP结构的目标是允许运营商配置IP技术以提供第3代业务，这是一种基于分组技术和IP电话的结构，以便实现实时业务和非实时业务的同步传输。此结构也应以99版本规范的演变为基础，并与IMT-2000相兼容，以提供全球终端移动性(漫游)[1]。
IP网络应该提供基于具有公共核心网的ERAN和UTRAN的无线移动性接入，ERAN和UTRAN均基于GPRS的演变。就此而论，E-GPRS无线接入网就是一个支持EDGE并被发展支持实时分组业务的以200KHz GSM为基础的网络，虽然EDGE不在3GPP的范畴内，但对全IP结构的核心网而言，对这两种接入技术具有共同的要求。
该网络具有如下特点：
●基于GPRS的演变
●对于包括UTRAN和ERAN在内的多址类型具有共同网络单元
●采用IP协议的分组传输
●IP客户机激活的终端
●支持语音、数据、实时多媒体，以及具有相同网络单元的业务。
该报告还包括对采用IP技术的CS业务的支持。
这种方案的好处包括：
●无论采用何种接入方式(例如，用户无论是通过传统陆地电话、电缆、无线还是HIPERLAN2等接入，都使用共同的特色服务)，通过采用IP技术，都能提供无缝服务；
●与一般的IP发展配合，进而降低服务成本；
●有效解决多媒体业务的同步传输，包括语音、数据和高级实时业务；
●更高的业务控制水平；
●通过采用IP技术实现综合的、成本降低的OA&M；
●通过支持IP客户终端来充分利用Internet的应用；
●通过分组传输降低成本。
4.1.1 一般要求
1.全IP网络的总的目标是支持与99版GSM的同样业务以及一些新开发的业务，并且这些新开发业务应该与现存GSM业务相互作用；
2.另外，它还能够支持现有(99版及其以前版本)业务/能力(通话、数据、多媒体、SMS、辅助性业务、VHE等)，并且对使用这些业务的用户而言支持方式是透明的[1]。即就是，网络必须按照支持这些业务相互作用的要求提供服务能力，这些业务的相互作用是指在00版网络选项和其他类网络两个域结构选项之间展开的(前99版GSM，99版UMTS)
3.这种标准应该能使全IP核心网络支持99版的CS终端，它是以允许操作者自己决定他们是否希望支持99版CS终端来实现标准化的。
4.通过应用全IP结构，在支持现有业务的同时，不应排除服务能力的扩大。
5.当全IP网络展开时，就会有为非IP网提供的服务和数据库，例如，本地号码的可携带性，免费电话号码，专门的团体业务，全IP结构必须能够接入这些业务。
6. 00版的全IP网络应该允许拥有一个CS域和一个PS域，这两个域的隔离方式和在99版的隔离方式类似。在执行过程中允许这两个域独立演变，例如，使一个全IP00版PS域和一个基于99版CS域的STM结合。而且，也可能一个CS域使用全IP结构，而在同一网络的另一个服务区域里的一个CS域使用ATM/STM。这就允许一个向全IP核心网络的平滑过渡。
00版全IP结构将支持所有的业务共享承载层传输和承载控制。
00版结构将允许运营商将一个99版网络过渡到00版网络，而不需要改变传输网络技术和节点编号方案等。00版网络还将允许通过Iucs连接99版UTRAN，以便给运营商提供灵活的网络实现方案。
注意：在一般00版结构内，除了IP也可使用其他的传输技术。
4.2 服务能力
4.2.1 概述
确定具有以下一般服务能力：
1. 00版全IP网络必须允许合法侦听
2. 00版全IP网络应该支持紧急呼叫。
4.2.2 对服务和应用平台的基本要求
对“应用和服务”块的要求如下：
1.通过服务能力特征，使服务能力可用于应用当中；
2.服务能力特征可由一个或多个服务能力提供(可能直接由网络功能提供，例如，HSS，CSCF等)，如图4-1所示；
图4-1：服务能力特征(SCFs)和服务能力之间的关系
3.运营商为了明确服务能力，可增加对服务能力特征的介绍；
4.一种叫做应用接口的标准接口被应用引入来访问服务能力特征，这个接口必须在应用和服务能力特征之间提供一个可控制的、安全的和负责任的关系；
5.应用接口必须基于用户预订简表提供服务能力特征的访问；
6.应用可被安装在服务器上和/或(移动)终端上；
7.应用只能通过服务能力特征访问服务能力；
8.通过服务能力特征，应用可使用由移动网络功能提供的功能和由IT系统提供的能力。
4.3 编号方案
该标准允许移动终结的通信通过一个专门的标识符，例如MSISDN，传送到用户终端，这也不排除多种地址被用于不同的业务和能力(例如数据、传真、短信服务)。网络将在可用的资源上传送呼叫给终端，可用的资源取决于，例如终端的能力、业务装载和覆盖。正在向全IP结构过渡的网络将被要求具备用一个专门的标识符规划路由的能力，以确保服务的透明性。
4.4 99版终端
参见上面的4.1.1节：下面对支持99版终端的要求是一个运营商特定的选项：
1.该标准应能使全IP核心网络支持UMTS99版终端；
2.全IP网络应能提供包括紧急呼叫在内的语音业务给任何支持此类业务的UMTS99版终端；
3.为确保UMTS 99版终端非IP电话业务的漫游，包括紧急呼叫在内的语音业务应能以这些终端的CS能力为基础。
4.5 无线电方面
1.对于业务与信令支持，此结构内的无线电资源的使用被被优化。
2.在核心网络和无线接入网之间分离与无线电有关的功能和与无线电无关的功能。
3.在无线接入网分离用户平面协议栈和控制平面协议栈。
4.在同一条无线电链路上的不同类型业务的复用方面，上行链路和下行链路都有快速上行接入和快速资源分配过程。
5.某些实时应用的端到端的IP传输实现最佳化(如标题压缩和标题剥离)。
6.有短暂中断的网络控制切换过程用以支持实时应用(见切换条件，4.9节)。
7.接入网的协议栈用以支持一系列有不同服务质量要求的业务。
8.为无线接入网发展的QoS服务机制和应用在分组核心网络的QoS机制可以交互作用/共同作用。
9.接入网的承载区分能力实现无线传输多路复用，获得了最大的频谱利用。
10.对一些应用如语音业务采用了最佳的编码和交织技术。
11.每一IP地址支持有不同QoS要求的多种数据流。(其定义如99版的QoS框架)
12.最大的频谱利用率(如统计复用)
13.对2000版以前的终端，ERAN应支持GPRS和EGPRS业务。
4.6交互作用
1.全IP核心网络将支持外部IP网与非IP网络的交互作用(如电路交换网，PSTN，ISDN，GSM，PLMN，UMTS PLMN，…)。
4.7 移动性管理
1.全IP网络应能为UMTS提供流水线和CN操作的切换过程。
4.8 漫游
1.该标准应能使全IP核心网络支持与2G GSM/GPRS网络和99版UMTS网络的漫游。
4.9 切换
支持98版、99版和2000版网络技术之间的切换是维持足够大的网络覆盖的基本方式。表4-1说明了必要的切换场景和机制发展状况。
表4-1：对UMTS全IP网络的切换要求
| 之间 | 2G-GSM cs | 2G-GPRS | UMTScs(99版) | UMTSps(99版) | UMTSIP(PS业务) | UMTSIP(CS业务) |
| UMTS(PS业务) | ReqR00* | ReqR00 | ReqR00* | ReqR00 | OK | 不要求 |
| UMTS(CS业务) | ReqR00 | 不要求 | ReqR00 | 不要求 | 不要求 | OK |
关键词：
OK 相同技术
Req R00 要求00版
*暗示在00版对要求PS和CS之间切换还有争议，到底选择支持切换还是提供服务覆盖尚需进一步研究。
4.9.1 切换类别
1.网络内部切换
在一个全IP网络内部进行切换
1a RAN内部切换
1b RAN之间切换
2.网络间切换
在两个全IP网络之间切换
3.系统间切换
全IP网络和其他系统之间切换。
4.9.2 一般定义
重选和切换是支持正在进行的通信过程实现移动的两种方法，重选就是由移动台自主决定重新选择哪一个蜂窝地区为其提供服务的过程，切换就是由网络决定移动台可以在哪一个蜂窝地区接收服务的过程。
4.9.3 一般要求
对实时业务而言，切换过程是必须的，它将由网络控制实现。
在一个有不同服务质量要求的多方通话过程中，如果有一方或多方都申请了切换，切换将是移动通信择的方式。
在通话中断(即“哑”阶段)时，要求的执行情况应等同于或者优于GSM或ANSI-136电话业务的切换。对其他业务的TBD由全IP网络提供。
在切换过程中维持信息分组丢失的最大极限(即小于TBD)和最大的延时极限(即小于TBD)。
非实时业务将要么使用切换，要么使用蜂窝地区重选，重选依赖于要求的服务质量参数和网络参数的结合情况。
在穿过切换边界时，应该保持预先确定的服务质量标准，服务质量的协商(如果需要)可以在切换前，切换期间和切换后进行(应用也许拒绝所提供的服务质量标准)。
切换过程应该有效的使用无线电资源。
切换将不危及提供新无线电资源的网络、提供原始无线电资源的网络(可能不同)和用户设备终端的安全。
多承载将会得到有效的处理，例如，语音和邮件将要同时传输。
基本的IP/UDP/RTP标题信息(对全IP网络内部或之间的切换而制定的)，正如被IP终点看到的，在穿过切换边界时应得到保存，所要求的基本标题信息依赖于承载。
4.9.4 移动台要求
移动台应能够支持重选和切换。
移动台应该通过提供射频环境信息(例如从正在服务的小区和相邻小区接收到的信号强度)来帮助RAN作出切换的决定。
4.9.5 RAN要求
切换的决定应以RAN为基础。
在穿过切换边界时，与移动台联合起来维持RAN的服务质量参数。注意，RAN对移动台的服务质量参数以协商所制定的服务质量参数为基础。
灵活的接入控制使无线电资源得到最优化。
选择切换目标有一定的标准，如射频环境信息，相邻小区的无线电资源，通话过程的服务质量要求等等。
4.10 呼叫控制和漫游
在一个全IP网络里要支持呼叫控制和漫游，就需考虑以下要求：
1.为了实现呼叫控制和网络间的漫游，就必须使信令和传输的路由规划实现最优化。
2.当用户漫游在本地环境之外时，无论何时，只要有可能就不应该通过把用户的语音和数据通信过程拉回到他们的本地环境的方式为用户提供服务。
3. 2000版全IP网络必须遵守为紧急呼叫制定的要求。
4. 2000版全IP网络必须遵守为号码可移动性制定的要求。
5. 2000版全IP网络必须支持多方语音和数据通信过程，包括让用户或逻辑服务有从正在进行通信当中添加或删除用户的能力。
6. 2000版全IP网络必须能够在国家号码重新编排(例如，NPA在北美的分裂)期间，接受用户的语音或数据通信呼入请求，并为其重新安排路由，这些用户在目录号中都有自己的地址。
7.业务(语音，数据，视频)的码形变换应当最小化，例如，如果主被叫的终端设备具有相同的语音编码器，那么在网络内语音业务就不会出现码形变换。
8. 2000版全IP网络必须为遗留2G网络和99版网络的业务提供连接。
9. 2000版全IP网络为漫游者支持VHE。
10.服务网络必须为漫游者其提供最小设置的服务，这些服务仍在定义当中。然而，下面的服务被预测在这些最小设置的服务当中：
a.语音呼叫和数据会话启动；
b.语音呼叫和数据会话终止；
c.在单媒体会话情况下，为语音呼叫提供呼叫等待；
d.为语音呼叫提供呼叫转移业务；
e.主叫方的鉴别信息
f.短信服务；
11.若2000版全IP网络的运营商在展开全IP网络的市场上不拥有一个遗留网络，并且与其他遗留网络运营商没有任何商业联系，结果，2000版全IP网络的设计就不能设想，对委托的业务或运营商明确的业务制定的要求能够满足转移2000版全IP呼叫到其他遗留网络。下面就是运营商业务的例子，这些业务也许需要由2000版全IP网络自己直接处理：
a.目录帮助
b.第三方付费
c.被叫用户付费电话
d.呼叫卡电话
12.当一个2000版全IP网络用户从一个2000版全IP网络漫游到另一个时，并与两者的传输业务(如GPRS)和应用级业务(如多媒体呼叫)都有连接，这些业务可能由服务网络中的一个CSCF或者本地网的一个CSCF提供。服务网络将包含有与用户本地网联系的信息，以便获得用户的文档信息。服务网络的CSCF应能获得必要的信息，以调用和控制用户在其本地网的高级/补充业务。
13.用户应能获得进入它们的ISP或共同的LAN应用层业务的连接。
14.应提供动态的和专门的IP地址。
15. 2000版全IP网络应能提供VPN功能，VPN指的是GSMVPN和企业内部互连网，VPN支持的属性需要进一步的研究和分析。
16.当UE使用CSCF/MSC服务器的服务时，CSCF/MSC服务器需要鉴别UE的身份，当UE使用被访问网络的CSCF时，这种鉴别方式需要进一步的研究和分析。
4.11安全性
对全IP网络的安全性执行的基本原则就是，无论在那里只要有可能就重新使用为3GPP 99版发展的相同的安全机制。
5.IP PLMN的结构
5.1 参考结构
有以下两个参考结构选项：
选项1：该结构已经被发展，其目标是允许运营商配置全IP结构来传递第3代无线/移动业务，这种结构为了实现实时和非实时业务的同步传输，是一种基于分组技术和IP电话的结构。
选项2：该选项的一个目标也是允许支持99版CS域终端，另外它还支持选项1中的基于IP技术的业务。
5.1.1 参考结构-选项1
正如前面4.1节中要求部分所述，图5-1所示出的结构已经被发展，其目标就是允许运营商采用全IP结构传递第3代无线/移动业务。这种结构为了实现实时和非实时业务的同步传输，是一种基于分组技术和IP电话的结构。
所展示出的结构及下面章节所描述的该结构的组成部分要求有灵活的和可缩放的机制，以支持全球漫游和与其他外部网络的合作如PLMN、第2代遗留网络、PDS以及其他的多媒体IP电话网络。
端到端的结构结构包括以下关键部分：
a)无线电网络
b)GPRS网络
c)呼叫控制
d)对外部网络的网关
e)服务结构
无线网络部分由移动用户终端、无线空间链路和无线接入网组成。RAN支持UTRAN和EDGE技术。
第4节表明全IP结构的核心网络部分的目的就是它应当被设计成允许操作者使用其他的接入网络，例如ERAN和HIPERLAN2。在图5-1中，ERAN被明确示意，在此其他接入网被用泡状标记“可选接入网”表示，为了制作此报告，
ERAN被定义为发展的GSM BSS，支持基于200KHz的
EDEG调制方案和实时分组业务。
对可选接入网的支持，和全IP结构对ERAN的影响在此次讨论范围之外，然而，为了避免丢失信息，此报告说明了在哪里要求应用那些接入网络。
在这份报告里，ERAN和核心网络之间的参考点被指定为Iu_ps’，即就是，参考点是Iu，其执行情况被认为和Iu_ps的执行情况一样。
注意：参考标记Iu_ps’的应用容易令人迷惑，在标准化过程中应选择一个更合适的标记。
GPRS网络部分有许多GSN，这些GSN和99版GPRS PS域网络中的GSN一样，为移动终端提供移动管理和PDP语境激活业务。GPRS网络的HLR功能由本地用户服务器提供。
该结构中的呼叫控制部分是最关键的功能部分，CSCF、MGCF、R-SGW、MGW、T-SGW和MRF组成呼叫控制和信令功能，以传输实时的移动/无线业务。CSCF等同于H.323中的网闸或者一个SIP服务器。该结构没有采用象H.323或者SIP的特殊呼叫控制机制，而有意采用普通的，这样的选择是为了做进一步研究。
用户简表被保存在HSS中，信令信息单独通过CSCF进入多媒体IP网络，然而承载则直接与GGSN相连，MRF为了承载媒体与各种承载相连，为了信令传输与CSCF相连。MRF提供媒体混合、多路复用以及其他的处理和产生功能。
GGSN、MGCF、MGW、R-SGW和T-SGW的功能单元支持与外部网络的连接，如PLMN、其他PDN、其他多媒体IP电话网络和遗留的第二代网络(GSM或者TDMA)。所有的PLMN都通过承载和信令各自的GPRS组成部分，为承载和信令提供接口。CSCF是一个新的组成部分，也参与到信令传输中，信令通过R-SGW接入到的遗留移动网络、CSCF、MGCF、T-SGW和HSS，而承载通过MGW与遗留下的PSTN网络连接。遗留下来的陆地传输电路交换信令通过CSCF、MGCF和T-SGW提供接口，而信道通过MGW与遗留的PSTN网络连接。
网络的服务结构部分目前作为一个外部实体在第10节有详细的描述。非标准化的业务通过应用业务层的接口提供。HSS、SGSN和CSCF都与应用和业务泡泡相连。
关于此结构的每一个功能单元的细节都提供在这个文件下面的小节当中。
图5-1：选项1的参考结构
UE和CSCF之间的Gm接口由用户到网络的多媒体信令组成，它通过无线、Iu、Gn和Gi接口实现。
就象在23.002[4]为UMTS 99版制定的一样，SGSN和GGSN是相同的功能单元。
在2000版全IP网络里，对其移动台的移动管理主要基于路由区域标识符，对可进行CS的移动台的移动管理主要基于路由区域标识符和位置区域标识符。在在2000版全IP网络和第二代网络之间漫游的情况下，就需要建立转换移动台身份表格的机制(即就是从2000版全IP网络漫游到第二代网络的移动台只了解旧的路由区域知识，但位置区域标识符也需要给2G-MSC)。当从3G-R00漫游到2G(没有组合更新的可能)时，2G-MSC怎样才能从全IP核心网络那里重新恢复IMSI，这是一个公开讨论的问题。
MS身份(IMSI)的保护是在无线接口通过采用一个专门的临时身份号(P-TMSI)实现的，这个临时身份号是SGSN在MS注册过程中分配的，它可在接下来的每一个注册过程或路由区域更新时被重新分配。[与2000版全IP网络和遗留的蜂窝网络之间漫游情况相关]。
接入网节点(GSN、RNC)并不知道UE和CSCF之间的多媒体信令协议，它们甚至不知道一个给定的UE发没发信令给CSCF。
注意1：这不排除使无线电资源最优化，RNC也许对多媒体用户平面的个人信息流支持确定的RAB，UE在PDP语境激活时需要这些RAB。
注意2：SGSN也许在UE选择CSCF时起一定的作用，这个问题还需要进一步研究。但即使SGSN参与了CSCF地址决定，它也不代表UE实现其多媒体注册。
用不同的PDP语境携带多媒体信令和用户信息流，主要归因于QoS对这些PDP语境的不同要求，因此接入网络节点(GSN(s)，RNC)不知道一个确定的PDP语境是否携带多媒体信令。
工作结构方案
1.全IP核心网络被设计的主要目的是用一个共有的技术(IP)去支持所有的业务，包括被H.323/SIP或ISUP控制的多媒体和语音业务。
2.网络结构基于IP分组技术，以实现实时和非实时业务的同时传输。
3.网络结构以发展了的GPRS为基础。
4.为了支持99版CS域业务，也许会重新使用99版CS域CC机制。(注意：这也不禁止使用其它机制如H.323，SIP或者被运营商用来传递99版CS域业务的发展后的99版CS域CC机制)
5.对00版终端的支持基于IP技术，业务的集中也是通过IP技术获得。
6.网络结构应该支持个人移动通信，以及对移动和固定网络对语音和数据业务共同作用的支持。
7.与现在的网络相比，应该维持或提高服务质量。
8.与现在的网络相比，应该维持或提高网络的可靠性。
9.全IP网络接口和有关网络的接口应该被提高以支持实时多媒体业务。
10.网络结构将把服务控制从呼叫/连接控制中分离出来。
11.网络结构将取代使用IP技术的SS7传输。
12.网络结构将独立于L1和L2网络传输层。
13.不考虑业务类型无论是基于ISUP还是IP，对所有的信令和数据传输而言，IP传输将成为可能。
5.1.2 参考结构-选项2
正如前面4.1.1节要求中的第3条和第6条所述，图5-2所示结构允许运营商将一个99版UMTS网络移植成00版全IP网络。选项2的一个目的就是允许支持99版CS终端。选项2还允许99版的两个域独立发展。
就选项1来说，选项2允许所有选项2支持的业务分享承载层传输和承载控制。各种低层的传输机制都将被允许(例如RTP/UDP/IP，AAL2/ATM或者STM)。
参考结构选项2包括以参考结构选项1业务为基础的SGSN/GGSN/CSCF。因此，在章节5.1.1中所描述的定义和工作结构方案也适用选项2中的SGSN/GGSN/CSCF部分。
[注意：在4.3节中对单独MSISDN的路由规划支持的要求，或者允许运营商在不改变MSISDN情况下将用户从CS业务移到全IP业务，将作为99版的一部分得到解决。]
与99版CS域结构有关的两个控制元素被加进了选项2，它们是MSC服务器和GMSC服务器。
选项2得益于99版的Iu结构，支持用户数据的传输与控制分离，允许UTRAN通过与MSC服务器分离的MGW接入核心网络。在UTRAN和MSC服务器之间使用了Iu的控制部分，即RANAP。
[注意：1]需要定义关于GSM/语音电信号的ERAN的确切定义和ERAN与MSC服务器/MGW的关系。2)GSM/BSS接入到MGW和MSC服务器的可能性需要进一步研究。]
通过允许服务器中断MAP和用户网络间的信令(04.08+CC+MM)，可以满足与业务和99版UMTS CS域业务的网络移植以及网络移植有关的要求。依据选项2这些对网络结构的要求是：
章节 要求号
4.1.1 2(为满足00版的时间表)
4.1.1 3
4.1.1 6
4.4 全部
4.8 1(选项2要满足这些要求将依赖于所选择的漫游解决方案)
图5-2：参考结构选项2
Iu是UTRAN和全IP核心网络之间的参考点，UTRAN和SGSN之间Iu是基于IP技术的，UTRAN和MGW之间的-Iucs(RTP，AAL2)-Iu也许基于不同的传输技术。
MAP分别工作在HSS和MSC服务器以及GMSC服务器之间。
5.1.3 什么是网络的边界
公开问题：什么是网络的边界
在GGSN被看作IP网的网络边界或GGSN+MGW被看作PSTN/遗留网络的网络边界的情况下，就需要对下面的问题进行澄清：怎样确定MGW以及怎样对此MGW保证最佳的路由规划。在呼叫建立时，CSCF需为呼叫确定合适的MGW，例如，它需要确定这个呼叫是否是去PSTN网的(如果是还要确定是去哪个PSTN)或者是去一个基于IP技术的语音网络，这样的确定只有当呼叫建立信令被CSCF，也有可能被SCF分析之后才能确保得出，分析过程也有可能改变被叫用户号码(例如把一个被叫用户地址从IP终端的地址改为外来的PSTN终端的地址)，只有在这时最好的MGW才被确定下来。在此之前这样的决定不能由SGSN来做。MGW的地址被送回(通过H.225信令)给UE，UE然后对合适的网络(即最能允许达到呼叫将要使用的MGW的网络)激活一个PDP语境(为支持用户平台通信)。
注意[需要进一步研究]，当加上一个MRF时，直到对什么是网络的边界达成一致时，才能确定路由最优化问题。
5.2 新功能单元
5.2.1 呼叫状态控制功能(CSCF)
在下面一节里，CSCF被分成几个逻辑单元。
目前，这些逻辑单元属于CSCFF的内部逻辑单元，是否需要能直接与这些逻辑单元之一直接对话的外部单元有待进一步研究。
每个作为服务CSCF(见9节)的CSCF都有CCF功能。
ICGW(来话呼叫网关)
●作为第一个入口节点并为来话呼叫分配路由；
●为了达到最佳效果，需要设置来话呼叫服务触发(如呼叫筛选/无条件的呼叫转移)；
●地址询问处理(意味着与其他实体管理的相关性)
●与HSS通信。
CCF(呼叫控制功能)
●呼叫建立/终止和状态/事件管理；
●为了支持多方通信和其他业务与MRF相互作用；
●对记帐、审计、拦截或其他目的呼叫事件报告；
●接收和处理应用层注册；
●地址询问处理(意味着管理的相关性)；
●可提供对应用和业务网络(VHE/OSA)的服务启动装置(服务能力特征)；
●可调用与服务网络有关的基于业务的定位；
●可检查是否允许为出局呼叫申请提供当前所要求的通信过程。
SPD(服务简表数据库)
●在本地域与HSS相互作用以接收为00版全IP网络用户提供的文档信息，并按照与本地域的SLA存储这些文档信息。
●通知最初用户接入的本地域(包括如CSCF信令传输地址、用户身份等。需进一步研究)
●可隐藏接入相关信息(例如用户可能到达的终端IP地址等)
AH(地址处理)
●分析、翻译、如要求还可对地址进行修改，地址的可移动性以及别名地址的变换。
●可为网络间路由规划提供临时地址。
其他功能如接入控制、在一个CSCF内对多个对话过程的了解、多个CSCF为一个终端服务以提供多种业务、在为同一个网络服务时每个CSCF扮演什么角色等等需要再做深入的调查研究。
接口也需要进一步研究和定义。
5.2.2 本地用户服务器
本地用户服务器(HSS)对给定用户而言是一个主要数据库，它负责保存与用户有关的特点和业务列表(直接或通过服务器)，负责位置跟踪和为它的用户确定接入方法。它可直接或通过服务器提供用户简表信息。它是本地位置寄存器功能的扩展，例如，虽然和GSM MAP中的定义相同，但它的传输是通过基于新IP技术的接口。HSS应支持给定用户的预约文档，例如：
●用户身份
●预约的业务和简表
●明确的服务信息
●移动性管理信息
●授权信息
和HLR一样，HSS包含或能访问鉴权中心/服务器(如AUC，AAA)。
图5-3普通HSS结构和基本接口举例
图5-4：带UMS确定功能的HSS结构举例
如图3所示，HSS包括以下几个单元：
1)用户移动服务器(UMS)：它保存着2000版全IP网络的服务简表(见9.1节)，为用户保存移动业务或服务CSCF的相关信息。UMS也可产生、存储或管理数据的安全性和策略(例如IETF特性)，为了回答DNS的询问，UMS应为传输地址翻译提供逻辑名。UMS角色和功能分解需要进一步研究。
2)第三代HLR：一个GPRS HLR被提高用以支持全IP网络GPRS明确信息。
Gr和Gc使用MAP，这可利用在IP传输MAP实现，然而，到支持基于SS7的MAP的网络的漫游问题需要考虑。Cx接口需要进一步研究：它可通过IETF协议如DNS或MAP过程来执行。
下面的功能也许需要HSS支持，并需要做进一步研究：
●它保存着00版全IP网络服务简表和提供给用户的位置信息。
●它也可产生、存储和管理数据的安全性和各种策略(如IETF特性)。
●也许需要为传输地址翻译提供逻辑名。
●为了和VLR及其它没有使用IP技术的管理器进行交流，HSS与R-SGW相互作用。HSS与CSCF之间的接口是Cx，此接口还需进一步研究。
●其它的00版全IP网络的功能如AAA、DNS等，以及它们与HSS之间的相互作用还需做进一步的研究。
●UMS和第三代HLR之间的接口问题需进一步研究。
注意：如果用户简表通过不同的数据库被分裂开来，那么就要么没有信息元素的副本，要么维持数据的连贯性。
5.2.3 传输信令网关功能(T-SGW)
这是00版全IP网络的组成部分，是对一个已定义网络的PSTN/PLMN终止接点。T-SGW的功能应与现有的或正在起作用的工业协议/接口相一致，这些协议和接口将能满足要求。
●变换与信令相关，来自/去PSTN/PLMN的呼叫到一个IP承载上，并把该呼叫发送到/从MGCF；
●需要提供PSTN/PLMN与IP传输层之间的地址变换。
接口需进一步研究和定义。
5.2.4 漫游信令网关功能(R-SGW)
下面描述的R-SGW的作用只与2G/R99 CS和GPRS域到R00CS和GPRS域之间的漫游有关，并且不涉及多媒体和IP电话域。
-为了确保正确的漫游，R-SGW在传输层执行信令转换(转换：SigtrnSCTP/IP对SS7 MTP)，这种转换是基于SS7的传输信令和基于IP的传输信令之间的转换。R-SGW对MAP/CAP信息不做说明，但也许必须对下面的SCCP层做出说明，以确保正确的信令路由规划。
-(为了支持第二代和99版终端)：R-SGW的业务被用来确保SS7和IP之间相互作用的传输，以及MAP-E和MAP-G信令与第二代/99版MSC/VLR的接口传输。
对于多媒体/IP电话域，MAP在R-SGW的交互作用需进一步研究。
5.2.5 复合网关
复合网关：是一个逻辑实体，由一个单独的MGC和一个或多个MG组成，可被安装在不同的机器上。总的来说，复合网关保持了在H.323和H.246定义的网关的特点。(包括2000版的SIP服务器和MSC服务器)。
5.2.6 媒体网关控制功能(MGCF)
对一个已定义的网络来说，MGCF在全IP网络中是PSTN/PLMN末端节点。MGCF内定义的功能应与现有的或正在起作用的工业协议/接口相一致，这些协议和接口将能满足要求。
●为MGW中的媒体链路提供呼叫状态中的连接控制部分的控制。
●与CSCF通信
●MGCF为来自遗留网络的来话呼叫选择CSCF，选择依据是其路由号码。
●在遗留网络(如ISUP，R1/R2等)和00版全IP网络呼叫控制协议之间执行协议转换(在工业上这还在进一步研究之中)
●频带外信息设想能被MGCF接收并可能发送给CSCF/MGW。
此类接口需进一步研究和定义。
5.2.7 媒体网关功能(MGW)
对一个已定义的网络来说，MGW在全IP网络中是PSTN/PLMN传输末端节点。对结构选项2来说，MGW被通过Iu用做连接UTRAN和全IP网络。
MGW内定义的功能应与现有的或正在起作用的工业协议/接口相一致，这些协议和接口将能满足要求。
MGW可从一个电路交换网络终止承载信道(即，DSO)，也可从分组网络上终止媒体流(如IP网中的RTP流)，通过Iu，MGW可支持媒体转换，承载控制和有效载荷处理(如，编解码器，消回波器，会议桥)，为CS业务提供不同Iu选项的支持：基于AAL2/ATM和基于RTP/UDP/IP。[注意：在普通的00版结构中，可能采用不同的核心网络传输技术，例如：ATM、STM或者IP。]
●与MGCF、MSC服务器和GMSC服务器相互作用以实现资源控制。
●拥有和处理资源，如消回波器等。
●也许需要拥有编解码器。
带内信令对MGW和00版全IP网络的影响需进一步研究。
传送铃音到PSTN/PLMN的功能需进一步研究。
为支持UMTS/GSM传输媒体，需要为MGW提供必要的资源。H.248的进一步信息分组可能会被要求用来支持附加编解码器和帧协议等。
对结构选项2而言，MGW承载控制和有效负荷处理能力也被要求用来支持移动具体功能，例如SRNS位置重选/切换和锚(注意：这些功能在结构选项1由SGSN/GGSN提供并且MGW不要求具备)，据预测，当前的H.248标准机制能被用来支持移动具体功能。怎样对移动具体功能使用H.248普通承载控制机制问题需进一步研究。
此类接口需进一步研究和定义。
5.2.8 多媒体资源功能(MRF)
●MRF执行多方通话和多媒体会议功能。在H.323网络MRF将具有和MCU一样的功能。
●在多方/多媒体会议过程中负责承载控制(和3G-GGSN及MGW一起)。
●在多方/多媒体会话过程中，为了确认服务可能与CSCF进行通信。
资源处理如两级拨号、声明等需要进一步研究。
此类接口需进一步研究和定义。
5.2.9 MSC服务器
MSC服务器主要包括99版GSM/UMTS MSC的呼叫控制和移动控制部分。
MSC服务器负责控制移动主叫和移动被叫04.08CC CS域呼叫，它截止用户网络间的信令(04.08+CC+MM)，并把此信令翻译成相应的网络与网络之间的信令。MSC服务器还含有一个VLR以保存移动用户的业务数据和与数据有关的CAMEL。
MSC服务器控制呼叫状态中对MGW媒体信道的连接控制部分。
5.2.10 MSC网关服务器
GMSC服务器主要包括99版GSM/UMTS的GMSC的呼叫控制和移动控制部分。
5.3 参考点描述
5.3.1 Cx参考点(HSS-CSCF)
此参考点支持HSS和CSCF之间的数据转移。
当UE已经向CSCF注册过，CSCF就能向HSS更新其位置，这将允许HSS决定引导来话呼叫到那一个CSCF。根据这次向HSS的位置更新，HSS就把用户数据(与应用相关的部分)传给CSCF。
对MT呼叫，CSCF询问HSS呼叫路由规划信息。
5.3.2 Gm参考点(CSCF-UE)
该接口将允许UE与CSCF通信，例如：
●向CSCF注册
●呼叫发起和终止
●辅助业务控制
5.3.3 MC参考点(MGCF-MGW)
MC参考点描写MGCF和MGW之间、MSC服务器和MGW之间、GMSC服务器和MGW之间的接口，它具有以下属性：
●完全遵从H.248标准，该标准的基准工作目前被ITU-T第16研究组联合IETF MEGACO WG贯彻执行。
●灵活的连接处置，允许支持不同的呼叫模型和不同的媒体处理目的，不受H.323用法限制。
●开放式结构，关于接口的扩展名/分组定义工作在这里执行。
●MGW物理节点资源的动态分享，一个物理的MGW可被分割成许多逻辑上独立的虚拟MGW/域，组成一系列静态分派终点。
●当MGW根据H.248协议控制承载和管理资源时，动态的分享域与域之间的传输资源。
对结构选项2来说，MC参考点的功能性必须支持移动具体功能，例如SRNS位置重选/切换以及锚制作。据预测，当前的H.248/IETF Megaco标准机制能被用来支持移动具体功能。怎样对移动具体功能使用H.248普通承载控制机制问题需进一步研究。
5.3.4 Mh参考点(HSS-R-SGW)
此接口支持HSS与99版/遗留移动网络之间移动管理和订阅数据信息的交换，这被要求用来支持漫游在第二代网络中的全IP网络用户。
5.3.5 Mm参考点(CSCF-多媒体IP网络)
这是一个CSCF与IP网络之间的IP接口，例如，此接口被用来接收来自另一个呼叫控制服务器或终端的IP电话。
5.3.6 Mr参考点(CSCF-MRF)
允许CSCF控制MRF内的资源。
5.3.7 Ms参考点(CSCF-R-SGW)
此接口允许CSCF为了位置管理(位置更新和用户数据下载)和呼叫控制(例如2G HLR为2G漫游用户询问路由号码)去联系遗留网络元素，例如2G HLR。
5.3.8 Mw参考点(CSCF-CSCF)
此接口允许一个CSCF(如本地CSCF)传递呼叫请求给另一个CSCF(如服务CSCF)。
5.3.9 Nc参考点(MSC服务器-GMSC服务器)
通过Nc参考点执行网络间的呼叫控制，其实例就是对独立呼叫控制承载的ISUP或者发展了的ISUP。在全IP网络Nc参考点使用IP信令传输。[注意：在普通00版结构可以对信令在Nc的传输有不同的选项。]
5.3.10 Nb参考点(MGW-MGW)
通过Nb参考点执行承载控制和传输，用户数据的传输可能通过RTP/UDP/IP或者AAL2实现。在Nb上的承载控制需进一步研究，它也许基于RTP、H.245或与之相关的协议。[注意：在普通的00版结构中对Nb上的用户数据和承载控制可能有不同选项，例如：AAL2/Q.AAL2，STM/none，RTP/H.245.]
5.3.11 SGSN到应用和业务
从SGSN到应用和业务域的SCP的接口是一种为GPRS定义的，用来支持计费应用交互作用的接口。
5.4 MAP/CAP的使用-MAP/CAP下的协议栈-一般考虑事项
在MAP和CAP下，全IP CN内的协议栈如图5-5所示：
- SCCP和TCAP被用在CAP和MAP之下，实际上CAP和MAP都依靠这些下面的协议所提供的业务(例如，事务处理能力，全球标题翻译)，到底选择哪个去提供SCCP的业务有待进一步研究。
- 较低的传输层顺应IETF Sigtran协议组，该协议组被用来在IP骨干网上携带电信信令。
图5-5：用于MAP/CAP的00版全IP网协议栈
此协议栈被用来携带MAP/CAP流：
●该协议栈用在全IP CN内部，终结MAP/CAP的节点之间：例如HSS或SCP与全IP CN功能实体之间，这些功能实体处理呼叫/通话过程并且需要与HSS或SCP对话以实现用户移动管理/用户数据恢复，其实例如Gr、Gc接口。
也许也应该正视(虽然需要进一步研究)应用MAP在Cx接口，以实现用户移动性管理/用户数据恢复。
●在与不支持此MAP/CAP于IP栈之上的节点(如2G或99版UMTS网络节点)交互作用但又需要一个MAP/CAP与一个支持此MAP/CAP于IP堆栈之上的节点对话的情况下，应用该协议栈。该协议栈被用于终结MAP/CAP的节点和R-SGW之间。Mh接口将使用MAP于IP之上，为了实现涉及00版CS域和GPRS的漫游场景(不包括IP电话和多媒体)，也不排除使用其他的协议。MAP在Ms接口上的使用还需进一步研究。
6.服务质量QoS
目前在S2 QoS内正在做的工作得自于TR23.907及TR22.105的QoS章节。这些规范的99版本将支持分组交换网络中的实时应用，包括UMTS透明地支持使用H.323协议的多媒体应用的能力。正如在此文本中所描述的，全IP结构定义了呼叫控制功能的实现，此功能在PLMN内基于SIP或H.323，因此，为了支持在PLMN内基于H.323或SIP的多媒体，00版QoS的工作将包括任何被要求支持必要的QoS能力所做的任何变化.做这些工作不要求在UMTS承载层引入任何新的QoS要求。
另外，请注意，也存在使全IP结构支持使用SIP协议的多媒体应用的渴望，然而，当3GPP本身承担支持SIP协议的工作时，与SIP协议有关的QoS工作将只在3GPP内被执行，但我们确实期望集中于H.323的QoS工作直接适用于SIP。
除此之外，既然全IP网的工作包括被ERAN结构鉴定了的EDEG支持，那么ERAN内的QoS工作就必须与UMTS内的QoS支持相一致。
对TR23.907当前版本的初步回顾会使我们相信它完全能够达到全IP网络的目标，回顾包括以下观察资料：
-TR 23.907包括一个包含语音服务的QoS会话层的规范，TR23.907明确这个会话层的基本特点为：
-保存信息流的信息实体之间的时间关系(变更)
-会话模式(迫切的和低延时的)
-无论语音是以电路传输还是以分组传输，这些特点都适用，因此没有必要修改目前定义好了的QoS等级
-不希望在PLMN内H.323呼叫摸式的执行会影响99版TR23.907所确定的QoS技术要求、整个结构以及其内所定义的功能。然而，将需要一个简短的研究去证实这些。
-根据全IP网络的要求，目前所定义的无线接入承载业务的属性需重新回顾一下，但对UMTS来说，在此领域不需再增加什么。然而，对EDEG来说，要预测所要做的工作。显然从承载到无线承载的变换也受到影响。
-能使GPRS与其他网络语音分组交互作用的问题需要研究，至少是在可接受的语音延迟预算之内时。
7.切换
在这一节中，已经明确了在PS域为支持实时业务切换所要研究和标准化的主题。在这一节中已经研究了各种各样的切换场景，但是场景被研究并不意味着就要求支持此场景。作为00版服务要求规范工作的一部分，对在UMTS内与00版全IP结构有关的切换要求将由S1决定。
7.1 在UMTS 00版IP网络内的SRNC重定位
在UMTS内，已经承担了实时PS域业务的切换。UTRAN不区分电路业务和分组业务，只简单提供实时和非实时业务，因此在RAN内实时业务的切换是可能的。
7.1.1 ERAN内要求的支持
全IP结构的目标是为UTRAN和ERAN提供一个公共的核心网络，这项工作的规范超出了此次研究的范围。然而，值得注意的是ERAN必须支持以下过程：
●SRNC重定位
●移动辅助网络控制实时分组业务的切换
7.1.2 全IP UTRAN到全IP ERAN的切换
支持这类漫游场景的必要性还需进一步研究。
在此类场景中，一个CSCF将同时支持ERAN和UTRAN内的终端。终端将从两个RAN接入同一个媒体网关，因此在网络内也使用同一个媒体编解码器。
7.2 全IP和CS域/GSM之间的SRNC重定位/切换
7.2.1 要求
支持这些切换场景的必要性需进一步研究。
预期的场景有：
●系统间的切换，目标系统不对其分组域支持必要的RT要求(如到97版的系统间切换)，
为满足这个潜在的要求，目前已建议了两种解决方案(也许也在研究其他的)，任何解决方案将面对以下问题：
1.MS对信令和业务量有一种或多种PDP语境，当切换后的MS受CS域处理时，这些PDP语境需要置换出来吗？怎样通知MS其业务现在由CS域处理？在那里没有H.323可用来实现这个目的吗？
2.多媒体CC信息的规模也许要比CS域支持的规模大。在GSM CS无线信令之上和A接口连接以及MAPE接口上传输多媒体协议信息的可能性需要研究。
3.SGSN怎样确定通话过程涉及到了CSCF？
7.2.2 支持MAP E的CSCF解决方案
下面的文章考虑的是当UE至少有一个正在进行的通话使用CSCF时的场景。
一接到一个请求SRNC重定位的信息，SGSN就决定SRNC的重定位会把SGSN变为一个不支持全IP业务的SGSN，。一种选择就是强迫正在服务的RNS保持此过程直到那些使用CSCF的通话被拆掉，另一种选择就是SGSN必须把不使用CSCF的通话转移到SGSN，而把使用CSCF的通话转移到一个第三代MSC。
下面描述的信令在23.121内是基于SRNC重定位过程的信令，它展示了锚MSC概念可用来维持多媒体CC信令，直到用隧道将该信令传回到用做“锚MSC”的MSC。
然而，关于怎样在网络内移开PDP语境，仍有许多问题出现：
1.接到“SGSN重定位请求信息”时，SGSN核对：
●有通信过程使用CSCF吗？如果有
●目标SGSN是一个E-GSN吗？
2.SGSN通知CSCF有一个切换到MSC的请求，即发送“转发SRNC重定位”信息
3.CSCF发信令“准备SRNC重定位”给不是锚的MSC，这个MSC包括从源RNC接收到的信息。
4.非锚的MSC启动重定位过程，把CSCF当作锚MSC，这样就允许多媒体客户CC信息通过非锚MSC用隧道传输给CSCF。
5.CSCF指示GW准备在PSTN和非锚的MSC之间传输业务，即把GGSN排除到通道外。
6.承载在RNC的成功交换，把SGSN和GGSN排除到通道之外，然后释放GTP隧道。
公开问题：
1.SGSN怎样确定哪一个通话过程使用CSCF？
2.SGSN怎样通过一个MAP-E接口通知CSCF去申请一个来自MSC的连接？在CSCF处在一个外部网络的情况下，SGSN也许不可能知道CSCF的地址。
3.对一个移动到PSTN的呼叫，CSCF将必须发信令给GW，以发送PSTN业务给3G-MSC。
7.2.3 使用ISHF的系统间切换
这一节中所描述的机制明确了一个新的功能单元，即ISHF，它使MAP/E从CSCF中隔离出来。下一步要做的工作就是确认采用这种方法还是采用在CSCF支持MAP/E的方法。(见7.2.2节)
7.2.3.1 概述
基于表4-1所给出的切换要求，下面的系统间切换场景应被容纳在全IP结构中。
●UMTS 00版IP网去/自第二代GSM网络的切换
这些列举的过程不要求更换终端。
图7-1系统间切换的支持
为了支持系统间的切换，建议把一种新功能加到结构当中，此功能称做系统间切换功能(ISHF)，见图7-1。
图7-1所给出的对基本结构的变化/增加包括：
1.ISHF是一种系统间的切换功能，用来实现UMTS 00版和UMTS(PS，CS)网络之间、UMTS 00版IP网和遗留网络之间的切换。ISHF除负责在源网和目的网之间建立承载外，它还负责到另一个网络的越区切换信令过程。
2.Mx是ISHF和R-SGW之间的接口，这个接口是MAP/E，用来在网络间传输越区切换信息。
3.My是ISHF和GGSN之间的接口，这个接口在UTRAN和ISHF之间转接与Iu信令有关的切换。注意这是用隧道贯穿SGSN的接口。
4.Mz是ISHF和CSCF之间的接口，为实现系统间切换，此接口被用在源网和目标网之间建立承载资源。
假设R-SGW功能将使UMTS 00版IP切换过程与源网或目标网的切换过程相互作用，那么ISHF就位于R-SGW内。也许值得建立一个独立的功能去执行核心网络协议间的相互作用，这还需要进一步研究。
7.2.3.2 UMTS 00版IP网往返2G网的切换
这个例子展示了怎样执行从UMTS 00版网络到一个遗留GSM网络的切换(硬切换)，说明了网络间所要求的信令，并设想在网络之间连接一条中继电路承载。也有可能采用其他承载连接计划，但在这个例子中不做说明。(注意：为了使图清晰的缘故，就没有标出所有的空间接口信息，另外，MGCF和T-SGW是作为一个复合节点展示出来的，并且这些功能之间的信息传递也被省略了。)
图7-2：：UMTS 00版IP到GSM的切换
图7-3：UMTS 00版IP到GSM的切换(续)
UMTS 00版IP GSM切换
1.当检测到一个SRNC触发器发送RANAP信息重定位请求给ISHF。
2.ISHF就发送MAP/E准备切换给R-SGW。
3.R-SGW将准备切换与合适的网络协议(这个例子当中的GSM MAP)相互作用在一起(如果被要求)并把信息传送给其他网络。
注意：步骤4和5跟在正常的GSM过程之后并只是为了清楚才展示出来。
6.一旦在GSM MSC/BSS内的初始过程结束了，就给R-SGW返回MAP信息准备切换响应。
7.R-SGW将此信息转换(如果要求)为MAP/E协议，并将产生的准备切换响应信息传送给ISHF。
8.ISHF启动在网络间建立承载资源的过程，这样就建立一条中继电路。ISHF发送一个连接信息给CSCF以启动一个建立承载的呼叫。
9.CSCF发送一个连接命令给电路网关(为简单起见MGCF、T-SGW被合在一起)，以建立一个去MSC的呼出呼叫。
10.电路网关发送ISUP IAM信息给MSC。
11.MSC用ACM信息作出响应。
12.ISHF通过发送RANAP信息重定位命令给SRNC，对来自SNC的启动要求做出响应。
13.通过现有的RRC连接，SRNC发送RRC信息切换命令(硬切换)给UE。
参数：切换型
注意：对GSM BSS与同步等相关的过程没有展示出来。
注意：步骤14-16遵循正常GSM过程，只是为了清晰才展示出来。
17.在GSM覆盖范围内对UE的检测导致MSC发MAP信息发结束信令请求给UMTS 00版IP网络(R-SGW)。
18.R-SGW转发发结束信令请求给ISHF。
19.ISHF启动资源释放，这些资源由前面的SRNC分配(Iu释放命令)。
20.ISUP回答从MSC发到电路网关。
21.返回连接命令给CSCF功能。
22.连接命令通过中继发回ISHF。
23.先前分配的承载资源在UMTS内释放(例如使用RANAP和ALCAP协议[ALCAP没有展示出来])(Iu释放结束)。
24.整个过程的结束依据UMTS得到ISHF发送的MAP/E信息发送结束信令响应(这个信息直到通话结束才发送)。
25.R-SGW将发送MAP发送结束信令响应给MSC。
7.3 需要进一步研究的领域
下面领域也许需要进一步研究。
-切换期间网络间的承载建立/控制
-在UMTS 00版IP网络内建立承载锚
-支持MAHO
-RAN间的软切换
-拥有同一类型流水线的RAN与RAN之间
-拥有不同类型流水线的RAN与RAN之间
8.无线电方面
注意：这一节内容要求得到RAN组的支持。
8.1 概述
1)CN-RAN接口定义
(a)在CN和称做EGPRS无线接入网(ERAN)之间功能上的分割已经被考虑，ERAN是新RAN无线接入网，无线网络间如ERAN或UTRAN和CN之间的接口需要定义/扩展，并应该允许不同的空中接口技术应用到CN。CN与RAN之间的功能分割需要进一步研究。
(b)对现存GPRS/EGPRS/UTRAN的执行和展开的影响
(c)移植场景-从第二代到99版(BSS是非IP技术的)再到2000版(全IP网络)
(d)协议栈的评估(包括从CN到RAN和MS的控制和用户平面的评估)
2)ERAN结构(参考SMG2)
(a)ERAN参考模型-网络实体、协议栈以及逻辑的或功能的元素
(b)元素之间的功能分割
(c)元素之间相互作用的定义
(d)对现存GPRS/EGPRS展开(BSC、PCU和BTS)和缓和策略的影响
3)UTRAN结构扩展
(a)明确所要求的扩展
4)对分组域的实时切换
(a)ERAN问题(参考SMG2)
(b)UTRAN的问题
5)QoS支持
(a)S2 QoS Ad Hoc对实时数据支持的评估
(b)信令机制
(c)CN问题
(d)GPRS QoS与UMTS QoS结盟
(e)无线链路的QoS的实现
6)(E)GPRS无线问题(参考SMG2)
(a)包括切换和QoS的实时支持
(b)频谱效率/性能(例如统计复用和资源/信道编码)
(c)RLC/MAC的提高
(d)应该考虑各种使用场景(如频谱可用性)和业务混合(如数据和语音的混合)对频谱效律的影响。
7)UTRAN无线问题
(a)实时分组数据的支持，包括切换和对QoS的有效而可行的提高
(b)无线电资源利用率/性能(如统计复用和资源/信道编码)
(c)RLC/MAC在需要的情况下的提高
(d)应该考虑各种使用场景(如频谱可用性)和业务混合(如数据和语音的混合)对频谱效律的影响。
| 注意：关于6(c)和7(c)的RLC/MAC线路项可能包括：●无线电资源分配的提高●无线接入承载定义(即对不同业务等级的定义，对通过协议栈的路径及所要用到的承载的定义)●流量划分(如把用户业务变换到合适的无线接入承载 |
| 上)●EGPRS协议的提高，用以支持实时业务和QoS管理(如快速信道分配方案) |
8.2 对实时IP业务的空间链路优化
8.2.1 介绍
在全IP结构中，当达到一定的频谱利用率和误差健壮性的情况下，基本的目标是为移动终端提供实时和非实时业务的支持。就实时语音业务而言，频谱利用率和误码率都有一个来自当前蜂窝系统的执行底线，还有一个语音质量底线。很自然希望全IP结构对语音业务能够达到这个底线，那时的问题就是当把全IP模式应用于蜂窝系统时，怎样才能达到频谱利用率、误码率和实时语音业务现存底线的目标。
对基于IP技术的实时多媒体业务而言，RTP协议已被用于UDP/IP之上，并占有支配地位。IP/UDP/RTP的复合标题的长度对IPV4来说至少40字节，对IPV6来说至少60字节，而语音有效载荷比较短，尤其比IP/UDP/RTP标题短。显而易见，如果在空间接口上传送“as is”以符合纯IP模式，就不可能达到甚至接近现存电路语音的频谱利用率的底线，这就要求使用一些标题改编技术，因此有一种标题转换技术，当标题在空间接口上传输时减小IP/UDP/RTP标题的大小，当通过空间接口后，就又执行反转换，以恢复原标题的大小和价值。标题尺寸的缩小是通过去掉原编码标题信息的冗余部分或去掉标题域信息来实现的，标题并因此失去了它本身的功能。为了设计合适的改编技术就必须充分考虑到对误差透明性和健壮性的影响(对给定标题的透明性传输就是指经过传输/反传输后应该能得到与原标题一样的标题)。
在这一节中，探讨了改编技术的范围并建议了两种改编技术：标题剥离和标题压缩，当考虑到误码率、语音质量和IP透明传输时，这两种技术都必须进一步研究。
8.2.2 用户平面改编
下面提到的功能为用户平面改编(UPA)执行变换/反变换，并从正反两方面探讨了可行的改编技术的范围。
8.2.2.1 全不透明(无改编)
UPA不了解标题或有效载荷的内部结构，并且当全部IP/UDP/RTP标题通过空中接口时，对标题不做任何改编。容错能力被平均用于标题中所有的比特，也平均用于有效载荷的所有字节。标题部分可能比有效载荷要求具有更强的容错能力，因为丢失一个标题，就必须丢弃与标题有关的信息分组，而且没有可用于标题的错误隐藏或错误缓和。这项技术达到全透明性，它允许支持如基于端到端基础的IPSEC协议。这项技术的一个明显的缺点就是由标题造成的高损耗，这将会导致很低的频谱利用率。
8.2.2.2 有效载荷的不透明性(只对标题改编)
在这种情况下，UPA只需了解IP/UDP/RTP的内部结构，而不需了解有效载荷的。只对标题进行改编，改编时要么采用标题压缩技术要么采用标题剥离技术。
8.2.2.2.1 标题压缩/解压缩
IP/UDP/RTP标题在在空中接口传输之前进行压缩而在接收端进行解压缩。跟以前一样，标题要求具有比有效载荷强的容错能力。最著名的标题压缩算法是Van Jacobson算法(RFC1144，为低速率系列链路压缩TCP/IP标题)。一般说来，压缩后的标题比没压缩的标题更容易出错，因此目前的标准化算法被证明对有损耗链路如无线接口不是很有效。
压缩IP/UDP/RTP标题的益处在当它能够减少每分组所需消耗时，仍然是很明显。一个有效的标题压缩方案可压缩IP/UDP/RTP标题至2个字节。
在将来要发展适应蜂窝无线链路可靠性特点的新的标题压缩方案，这种适合无线环境的方案能压缩IP/UDP/RTP标题到2个字节。其他方案的一个例子如目前为IETF的发展所建议的方案，在此方案中被压缩的标题在压缩前就携带一个计算出的检查总和，这就为检查和修复错误提供了一个可靠的方法，同时增加了误差的健壮性。
多数标题压缩方案存在的普遍缺陷就是与端到端安全协议(IPSEC)以及宽带管理不兼容，原因是压缩过的标题有不同的长度。对应用于无线接口的标题压缩方案的要求和评价标准总结如表8-1。
图8-1展示了标题压缩的概念性图表，主要用在蜂窝系统与低层连接当中，语音被用来做一个例子，低层可执行插分和信道编码。为了简明起见，插分和信道编码对信息比特流在空间接口传输的影响没有展示出来，链路层与其他业务流复用所造成的影响也没展示出来。图中有一个基于MS的UPA节点和一个基于网络的UPA节点，基于MS的UPA节点对上行和下行链路而言，分别用做标题压缩器和标题解压缩器，而基于网络的UPA对上行和下行链路而言，分别用做标题解压缩器和标题压缩器。
对标题压缩技术的要求如下表所述，针对每一项，也提供了做这种要求的理由。
| # | 集中的领域 | 要求 | 理由 |
| 1 | 性能/频谱效率 | 在期望的操作环境下必须提供相对低的消耗 | 总的说来，一个基本目标就是提高频谱利用率，消耗的减少对实现这个目标有直接影响 |
| 2 | IPV6或IPV4 | 必须包括对IPV6和IPV4的支持 | 期望IPV6和IPV4的终端能够同时并存在一段时间 |
| 3 | 同时并存 | 不必要求修改现存IP(v4或v6)、UDP或RTP协议栈的执行 | 能够使用普通IP/UDP/RTP堆栈的当前设备/业务 |
| 4 | 蜂窝HO | 必须以一种有效的方式支持蜂窝越区切换行为，所有的领域必须对HO过程是透明的，即能够在接下来的越区切换时准确地再生 | 应用目标是为了在蜂窝空间接口对用户平面进行改编，因此必须支持这种切换。有效性的要求归因于如果越区切换没有正确处理就会对频谱利用率和语音质量存在潜在的影响 |
| 5 | 完整性 | 标题压缩过程必须是无丢失的 | 能够保持IP端到端的完整性 |
| 6 | 错误传播 | 由标题压缩引起的错误蔓延应该保持绝对最小或尽可能的避免，错误蔓延就是分组的丢失延续到下一个错误发生的地方，即使下面的分组没有错误发生。 | 错误蔓延将导致低频谱利用率和低语音质量，这种现象对现存方案如[5]是一个严重的问题 |
| 7 | 延时 | 必须在所有预期的延时环境下起作用，标题压缩过程不必特意对延时预算系统做出什么贡献 | 用户也许处于不同类型的具有不同特点的环境当中，额外的延时将对通话语音产生负面影响 |
| 8 | 分组丢失 | 必须在所有预测的分组丢失环境下起作用；应该选择让标题压缩率与分组丢失率尽可能的相对独立 | 用户可能处于不同类型的具有不同特点的环境 |
| 9 | 支持的媒体 | 必须在发挥作用时不考虑RTP有效载荷上的媒体类型(一般来说不要求了解有效载荷) | 算法可用于任何类型的RTP/UDP/IP数据流，注意这里不排除对一定媒体类型的优化选择 |
| 10 | 关于呼叫类 | 必须对移动网-移动网和 | 两种类型的呼叫都将在全IP蜂窝系统 |
| 型的独立性 | 移动网-陆地线路之间的呼叫起作用，在每一种情况下的执行情况应该与现存蜂窝网具有可比性(在质量和频谱利用率两个方面) | 发生。每一种都同等重要 |
表8-1对标题压缩的要求
图8-1标题压缩
8.2.2.2.2 标题剥离/再生
IP/UDP/RTP在通过空中接口传输之前被剥离，在接收端再生。基本上只传输有效载荷，但一些额外的与标题有关的信息也必须传送，以确保标题的再生。能得到的标题透明性程度是可变的，主要依赖于所要传输的与标题有关的信息量的大小。当所有的标题信息被完全移开时，就不需要对标题容错，但这时至少对一些分组来说，就需要有一个标题来携带标题再生所需要的信息。当有效载荷的大小固定时，就不存在带宽管理问题，因为有效载荷可以由具有固定比特速率的信道来传输，固定比特速率的信道不存在服务质量(延时和抖动)问题。和前面的一样，端到端的安全性就不能保证。
图8-2展示了标题剥离在蜂窝系统用于与较低层联系时的概念性图表。以语音为例，较低层执行插分和信道编码，为了简明起见，插分和信道编码对信息比特流在空间接口传输的影响没有展示出来，链路层与其他业务流复用所造成的影响也没展示出来。图中有一个基于MS的UPA节点和一个基于网络的UPA节点，基于MS的UPA节点对上行和下行链路而言，分别用做标题剥离器和标题再生器，而基于网络的UPA对上行和下行链路而言，分别用做标题再生器和标题
剥离器。
图8-2标题剥离
8.2.2.3 透明(全改编)
UPA了解标题和有效载荷的结构，标题可被压缩和剥离。另外有效载荷传输可被优化载荷结构的技术优化，如非对称比特保护、信道和错误编码等。
8.2.3 全IP网络的应用
全IP网络被期望提供实时承载业务，用来携带：
●基本通话语音业务(和目前蜂窝网的语音业务相同)
●实时多媒体(包括语音业务，它是多媒体的一种组成部分)
8.2.3.1 基本语音业务
对基本语音业务来说，其重点就是达到，如果可能的话甚至超过传统蜂窝网的低线，如在频谱利用率、误码率和话音质量方面。传统的蜂窝网通过使用众所周知的技术达到了那个低线，如非对称比特保护，为有效载荷优化的信道和错误编码技术等。另外，话音帧不会带来任何的标题损耗(从IP意义上讲)。在全IP系统内，我们建议定义一种“基本语音业务”承载，专门用于表示传统的语音业务和其他可能具有相同特点的媒体。
基本语音将使用有效载荷优化和同传统蜂窝网一样的载荷非对称比特保护。把许多话音帧打包放在一个分组里将改善相对损耗，但会附加上时延，时延会对话音质量产生负面影响。与标题相关的信息和/或压缩标题的传输将要求很强的容错能力。
有两个选项能够达到基本语音所要求的特性：
标题剥离：从最低限度来说，基本语音的标题剥离必须对静态IP/UDP/RTP领域(在整个通话期间不做改变)和RTP时间标志以及RTP序列号达到透明传输。这种承载将与上面的标题剥离全改变情况相符。
适合无线电特点的标题压缩：通过使用高效的标题压缩方案，每组的消耗将减至2个字节，这种情况也将与上面所提的标题压缩全改编技术相符。
计划采用附加的优化技术进一步提高频谱利用率。
应根据8.1.2章节表8-1的标准评估这两个选项和具体的算法。
8.2.3.2 实时多媒体
实时多媒体是一种传统第二代蜂窝系统所没有的新业务。在此建议了一种新承载，对这种承载来说，关键的是对IP/UDP/RTP领域的全透明性。在透明性约束下，我们想要优化频谱利用率和降低误码率，但与语音业务不同的是，没有一个低线可以用做发展目标。透明性的目的自然导致选择标题压缩作为用户平台改编技术。有效载荷将具有一定的容错能力，而压缩标题将具有更强的容错能力。对此业务提供有效载荷的非对称比特的能力还需要进行研究。这种承载与上面提到的标题改编技术-标题压缩相符。应用在实时多媒体业务的具体算法还需要根据8.1.2章节的表8-1的标准进行评估。
8.2.3.3 纯IP
提供纯P业务是为了容纳端到端的协议如IPSEC。为了实现这种容纳，承载不做任何改编，并与上面的“无改编”情况相符。标题改编也可申请纯IP技术。根据8.1.2章节的表8-1的标准，对标题改编的具体算法需要进行评估。
8.2.4 结论
IP/UDP/RTP分组要求对无线链路做出改编，以达到蜂窝系统要求的频谱利用率和误码率。将要研究一种方案可同时而且完全满足以上要求和IP全透明性。针对这种方案可供选择的就是适应某些特殊应用类型要求而采用的方案的某个等级。应用软件就可采用不同类型的优化过的承载，这些承载优化的目的是为了适应他们目前的特殊需要。
从标题压缩观点来看，实时承载可被分类为基本语音(BV)和实时多媒体(RTMM)。BV承载用来携带语音，一种与传统蜂窝系统的语音业务类似的业务。RTMM承载将用来携带普通多媒体业务，其中也包括语音。另外，打算用纯IP业务支持各种应用，这些应用要求全透明性。
●BV将使用标题剥离或标题压缩与有效载荷的非对称比特保护技术
●RTMM将使用标题压缩和有效载荷的对称比特保护技术。在支持有效载荷的非对称比特保护方面还要进行研究。
●纯IP技术将支持在不改变标题的情况下对数据的传输。对纯IP技术而言标题压缩也是可能的。纯IP技术应用对称比特保护于有效载荷。
在各种情况下，标题(如果提供的话)要求有较强的容错能力。
9.呼叫控制
9.1 呼叫控制的术语
本节中的术语是些新的或与99版中定义相比已经改变了的术语。它们不是已经经过真正讨论过术语，所以也不能认为是大家认可的。这些术语也必须与99版的术语一致，除非有新的或改变了的概念出现，否则就用99版的术语。对S1定义的术语的改变要经S1同意。
这一节定义了本文件所要用到的一套公用短语。下面所列的短语是为定义一些术语所做的第一次尝试。
这里定义的术语还不能与现存3GPP术语相匹配，这种匹配工作将必须完成。而且，3GPP尚未定义全IP网络所需的全部短语。
1.接入简表：包含有与某一具体承载有关的预先定制的简表信息，例如，E-GPRS文档把无线承载特性(如QoS)加给用户接入的设置，就形成接入简表。接入到/出遗留网络的具体接入漫游信息就是接入简表的一部分，对CS终端举一个例子，其接入简表包含有关于允许的LA的信息以及关于需要鉴定的安全数据的信息。
2.2000版全IP网络的服务简表：包含有与用户定制的2000版全IP网络服务有关的服务预定数据，例如，服务简表包括用户身份、用户化名、用户临时位置信息(目前所使用网络的指示器)、用户所定制的多媒体业务和容量指示、业务触发器以及附加业务等级等。
3.用户简表：是一个或多个接入简表和零个、一个或多个2000版全IP网络以及漫游服务简表的组合，用户简表放在HSS内。(需进一步研究)
4.PDP流：它是不受不同IP地址需要分配不同PDP语境要求限制的PDP语境。PDP流之间的不同之处在于协议类型(如TCP、UDP)等和端口号的不同。(需进一步研究)
5.承载网络：是一套网络元素，为用户提供接入到服务/本地域的方法，以享用用户漫游网络、用户本地域或其他服务网络所提供的业务和设备。承载网络的举例：
●加上一个或多个不同RAN的E-GPRS；
●有线接入网络等。
6.域：域是网络元素的逻辑联合体，一个域包含有任意数量的HSS、CSCF和MRF。一个域对一些用户来说是本地域(这些用户的定制文档存在指定域的HSS内)，对另外一些用户来说是服务域(这些用户的定制文档存在另一个不同的HSS里)。一个域可以接入到大多数承载网络。(需进一步研究)在2000版引入域概念的目的是为了加强在核心网络的接入独立性、NAI地址的支持、伸缩性、附加的业务和所期望的服务器(如Email/CSCF交互作用)，允许使用DNS和用于翻译的目录。域已经提供了许多有用的业务和功能的结合。一个域是一个系统或区域的逻辑领域。为了翻译的目的，域被用做把业务和服务器联系起来的一个公共标识符，对与域相关的各种业务而言，域是进入存放节点网络地址的数据库的钥匙，支持这些业务的节点的实际位置并不受域的限制。这里的短语域参考了域的DNS定义。
公开问题：短语、域、本地域和服务域的用法要求进一步阐明和分析。
7.本地域：这是一个包含HSS的域，具体的说，用户的本地域就是包含有用户简表的HSS的域，本地域可能包含有，也可能不包含本地CSCF、MRF或服务逻辑。本地域：
●为属于该域的用户提供和维持用户及用户在HSS内的预定数据；
●也支持接入独立的用户及用户简表，例如浏览器书签和电话清单；
●用户通过用户简表提供和更新目前所访问的服务域；
●保存路由和移动信息，确保无论用户在或不在本地网，都能把服务传递给用户；
●维持与其他网络的漫游约定和业务层约定；
●当本地域包含有本地CSCF时，被看作是从源网开始的第一个终结节点；
●可收集和合并收费数据。
其他功能有待进一步研究。
8.服务域：
●存储从本地域接收到的漫游文档；
●尽可能的以同样标准“看、接触和感觉”，为用户提供在本地域的业务或业务接入。(例如，如果是不同的运营商域，每一终端的性能和服务层约定)；
●保存路由和移动信息，确保能把服务传递给漫游在服务域的用户；
●为了计费和统计，有选择的收集数据；
●能提供本地业务，例如基于位置的业务和信息(如广告、操作者对本地事件发表的声明等)；
●提供可选择的资源，如会议设备、多媒体呼叫控制等(资源可由本地网提供)；
●当用户在本地域内注册时，本地域就可作为服务域。(需进一步研究)
9. 2000版全IP网络：一个2000版全IP网络包括以下逻辑元素：
●一个或多个域；
●任意数目的承载网络；
●与一个或多个MGCF和MGW的连接；
●没有或拥有一个或多个MSC/GMSC服务器。
10.本地网(HN)：从一个指定用户角度考虑，本地网的组成包括：零个，一个或多个服务域、任意数量的承载网、零个，一个或多个MGCF/MGW以及这个指定用户的本地域。(需进一步研究)
11.服务网(SN)：从一个指定用户角度考虑，服务网的组成包括：零个，一个或多个服务域、一个或多个承载网、零个，一个或多个MGCF/MGW，不包括这个指定用户的本地域。(需进一步研究)
12.服务逻辑域：包括以下功能：
●包含现存电信服务能力(即对IN的SCO)；
●包含对基于Web业务的Wap类型能力；
●允许用户很容易接入业务(新业务的通报、网络中业务的激活/解除、新业务的支付和升级能力等)；
●在有变更的情况下，由用户或逻辑域操作者的提供者在本地域更新文档数据；
●提供接入或到达其他服务逻辑域的能力；
●一些业务可放在服务逻辑域之外。
服务逻辑域和本地网有着紧密的连接，以便管理/收费/提供统一为用户设置的应用服务能力，特别是如果CSCF启动服务触发器，则服务逻辑域和本地域以平等/透明方式为CSCF提供用户的用户简表和预定文档服务。逻辑域还可以单独使用，即不受网络位置限制(需进一步研究)。需进一步研究CSCF是否能在逻辑上与服务逻辑域联系在一起。
13.本地用户：在本地域有预定文档的本地网用户。当一个用户位于其本地网的一个服务域内时就被认为是本地用户，用户可能在也可能不在他们的本地域内。
14.漫游用户：一个漫游在本地网之外，并接受一个服务网络服务的用户就是漫游用户。
15.遗留网络：遗留网络就是：
●基于SST的网络(如PLMN、PSTN和ISDN)，以及基于CAS的网络；
●GPRS网络(需进一步研究)。
16.多媒体IP网络：它是一个支持实时多媒体业务的外部IP网(使用H.323和/或SIP协议)，包括SIP/H.323网络元素和终端，也可能通过网关与2000版全IP网络连接。
17.服务CSCF(S-CSCF)：是服务域内的一个CSCF，通过它用户可以注册进去，并通过从用户本地域获得的服务简表为用户提供服务。
18.本地CSCF(H-CSCF)：它是一个本地域和专用域内的CSCF。本地CSCF在预定的时间与用户联系，并且如果用户是通过别名被识别，这种别名要求被翻译成IP地址(例如逻辑名由DNS来翻译)，而本地CSCF的传输地址是由别名的翻译来提供的。(需进一步研究)
图9-1域内的网络模型
9.2 设想
在当前版本的文本中所描述的漫游模式发展过程中考虑了以下设想：
1.地址规划的要求和机制是建立在被3GPP在3G TR22.975和3G TS 33.003内所确认的要求和机制。
2.将考虑呼叫许可/否认和呼叫重选路由，呼叫许可的细节(如鉴定和服务质量)将不在此讨论。
3.向用户目录号提出的来话呼叫路由重选或数据通信请求将在国家号码计划重新制定期间被考虑，可能的话，将提供一个解决方案(如基于数据库的呼叫重新定向)，这个解决方案不是最后的解决方案。
4.一个区别与携带媒体PDU的PDP流的具体的PDP流(称为信令PDP流)，被选中在UE和CSCF之间携带信令(例如呼叫建立，如闪断请求的呼叫内信令)。这种信令流和媒体信令流的不同之处在于它不需要拥有一个IP地址。
5.用户简表被长久地存入本地域内的一个数据库/服务器。
6.在漫游情况下，服务网络至少在用户登记时询问在本地网内的用户简表，并且部分用户简表会被暂时存入服务网内。
7.在动态分配IP地址的设想中，漫游结构也将被优化。
8.关于遗留网络(如PSTN，2GPLMN)和多媒体IP网与2000版全IP网络之间互连的问题，没有做出新的要求，2000版全IP网络之间必须确保与现存遗留网络和多媒体IP网之间的互动性。当2G HLR(例如GPRS HLR)被重新用于为2000版全IP网络用户保持数据时，2G HLR将被升级用以支持全IP网络用户，其接口也可能被升级。
9.
10.MS的注册过程从逻辑上讲包括承载层注册(如GPRS连接)和应用层注册，应用层的注册要经过MS定制文档明确/允许。作为一个例子，MS注册过程是在MS功率升高时执行。
11.根据来自于GPRS的注册过程，承载层注册承担起到GPRS节点的注册。
12.应用层注册过程承担起到一个服务CSCF/MSC服务器的注册，目的是通知CSCF/MSC服务器MS的存在，并允许CSCF/MSC服务器恢复来自于HSS的用户信息。
13.承载层注册和应用层注册被认为是两个分开的过程。承载层注册过程的完成也许会在UE引起一个PDP信令流的启动，这可作为一种支持应用层注册过程的方式。
14.在GPRS层用GPRS移动管理来跟踪MS的位置。用户移动状态的跟踪是在应用层通过一个明确的过程来实现的，这个过程的目的是更新保存在CSCF/MSC服务器的用户信息，如果可能的话，也更新保存在HSS的用户位置信息。
15.HSS通过当前CSCF/MSC服务器和服务域保持对用户状态的跟踪
16.在该文件的当前版本里，没有考虑对多方语音和数据通信过程的支持(包括为用户和逻辑服务提供的在通信进行当中动态地增加和删除用户的能力)。
17.在共同合作的运营商之间应该具有漫游协仪(统计的或动态的)。
18.网络运营商之间的服务等级协议的制定(动态地或统计地)是为了确保业务层的连贯性(例如，端到端服务质量，安全性等)。
19.所有要求地址分析和地址翻译的网络元素都可以终止呼叫的路由规划(如CSCF、MSC服务器、MGCF)或者有接口接入相容的翻译数据库或HSS，以解决路由规划/呼叫终止问题。
20.O&M功能的存在是为了使2000版全IP网络不同的组成部分能够相互连接，并使每个组成元素在网络域内知道如何访问/进入其他的组成元素。
21.O&M功能能使每一个域无论什么时候都能使用网络提供的文档(如800触发器，音频信息)。
22.为了获得用户平面最优化，服务GGSN将有选择的被放置在服务网络中。
23.服务简表(预定或激活状态)和服务触发器或者由HSS维持，或者由HSS升级到CSCF/MSC服务器。
24.规划了的CSCF呼叫信令是为实时业务而设定。
25.每一个CSCF都与一个或多个MRF联系，每一个MRF可由不止一个CSCF控制，清楚地说就是如果用H.323术语描述MRF，MCU就是MRF的一部分。MRF可被放置在本地网(当本地CSCF控制当前的呼叫过程)或者服务网络(当服务CSCF控制当前的呼叫过程)。
26.在所有漫游场景中需要一个本地CSCF的部分功能是为了支持：
●来话呼叫用最优化的路由规划登记地址到一个DN，这个DN属于其他2000版全IP网络或多媒体IP网络(即呼叫不通过PSTN分配路由)；
●来自其他2000版全IP网络或多媒体IP网的来话呼叫用一个LN发起(逻辑名)；
●辅助业务的实现和来话呼叫筛选这类为终结呼叫设置的功能(例如无条件呼叫转移)。
9.3 全IP网内的漫游
下面将描述一系列漫游场景：
编者提醒：请注意从6-4到6-7的表格中所列出的网络接口和名字并不一定正确。
9.3.1 呼叫模式
下面所陈述的呼叫模式都被当前文本采纳：
●来自/通过PSTN的呼叫被连接到一个MGCF，这个MGCF与所拨DN所在的本地网相连；
●用DN发起从一个2000版全IP网络到另一个不同的2000版全IP网络的呼叫能被最优化(即不被接入PSTN)的条件是：发起呼叫的2000版全IP网络了解呼叫目的2000版全IP网络的编号计划，并能不离开IP域把呼叫通过路由送到目的网中，如果呼叫发源网络有接口接入呼叫目的网的HSS，并且与被拨DN相匹配，则可进行进一步优化。这些也同样适用于用DN发起的从多媒体IP网到2000版全IP网络的呼叫。
●设想场景1，对来话呼叫(即移动终结电话)来说，呼叫建立请求总是到达IGGW，IGGW询问HSS，实现来话呼叫筛选并转接(不执行任何呼叫控制功能)请求到服务CSCF/MSC服务器。如果呼叫发起的2000版全IP网络具备询问目的网络的HSS的能力，它就可直接将呼叫建立请求登记到提供服务的CSCF。
●关于发起的呼叫，呼叫请求由服务CSCF/MSC的服务器(当提供时)受理，或当没有提供一个服务CSCF时由本地CSCF受理。
这一节只涉及PS业务。
9.3.2 场景1，传统模式
下面的图片分别展示了漫游场景1适用于一个单个网络内部漫游的情况，和适用于网络之间的漫游情况。
图9-2：场景1应用于单个网络内部的漫游
图9-3：场景1应用于网络之间的漫游
场景1具有以下特点：
●同时提供本地CSCF和服务CSCF，并且两者都能使用；
●MT呼叫通过本地CSCF被传送到服务CSCF；
●MO呼叫所调用的非基本业务(例如辅助业务等)和明确表达给本地网络运营商的与服务逻辑相互作用的请求，可通过两种方式提供。
●服务CSCF有一个接口直接接到服务逻辑(例如在IN情况下，有直接接口到一个SCP)，如上面图片的情形1；
●只有本地CSCF有接口接入服务逻辑，而且这两个CSCF会协同工作，以提供用户所需业务，如上面图片的情形2；
●到达服务CSCF的MT呼叫由服务CSCF来受理其基本语音业务；
●调用非基本业务的MT呼叫的处理方法和上面描述的MO呼叫的处理方法一样；
●为MT呼叫而设的用户平面通过本地网从源网被接入到服务网(即从PSTN到MGW，再到服务网的GGSN)；
●为非优化2000版全IP网络的MO呼叫而设的用户平面(和为从非优化2000版全IP网络到2000版全IP网络的呼叫设的用户平面)通过服务网的一个MGW从服务网接入到PSTN，这样就优化了用户平面的路由规划。当在同一网络内部漫游的情况下，MGW可对承载网络再一次选择“关闭”，以实现对用户平面的路由优化。
●本地CSCF启动来话呼叫筛选触发器(如为来话呼叫提供辅助业务和IN业务的触发器)并转接呼叫控制信令到服务CSCF地址，服务CSCF的地址是在HSS询问期间得到的。
9.3.3 场景2
下面的图片分别展示了漫游场景2应用于一个单个网络内部漫游的情况，和应用于网络之间的漫游情况。
图9-4：场景2应用于单个网络内部的漫游
图9-5：场景2应用于网络间的漫游
场景2具有以下特点：
●只提供一个服务CSCF；
●MT呼叫通过本地域/网内的ICGW发送到CSCF；
●在MT和MO呼叫期间所调用的所有业务(基本的和非基本的)全都由服务CSCF提供；
●如果“非基本”就意味着“非标准化”，那么这些业务将涉及服务CSCF和本地域内的元素以及服务逻辑域。
●为MT呼叫而设的用户平面通过本地网从源网被接入到服务网(即从PSTN到MGW，再到服务网的GGSN)；
●为非优化2000版全IP网络的MO呼叫而设的用户平面(和为从非优化2000版全IP网络到2000版全IP网络的呼叫设的用户平面)通过服务网的一个MGW从服务网接入到PSTN，这样就优化了用户平面的路由规划。在在同一网络内部漫游的情况下，MGW可对承载网络再一次选择“关闭”，以实现对用户平面的路由优化。
9.3.4 场景1：以确保场景1有效的信息流
为确保上面所提议的场景1有效，在这一节提供了为注册、位置管理以及呼叫传递/发起而设置的信息流。
对在呼叫控制和漫游建议过程中的信息流没有提供太多的细节。已经为信令信息选择了普通的名字，与现存信令名字的任何相似之处只是为了让所建议的信息流得到快速的充分的了解。在本文本中只包括了有限的信息流分支。
9.3.4.1 注册和位置管理
●在这个版本的技术报告中，只考虑了一个基本的登记过程；
●基本的登记过程包括三大步骤；
●GPRS附接：是一个普通的GPRS附接过程；
●PDP语境激活：一个PDP语境的建立是为了支持应用层信令；
●应用层向CSCF的登记。
后者在下面报告的注册流中被考虑。
这里展示了两种基本的登记情况，目的是给大家提供应用层登记过程的初始画面。
图9-6：2000版全IP网络用户在2000版全IP网络服务域的注册过程
步骤4和步骤5是可选的，只对下面两种情况发生作用：
●如果用户被提前注册到不同的服务CSCF内；
●如果用户没有被提前注册，但是在一个MT呼叫期间，HSS确定在本地CSCF内需要有一个服务简表去处理来话呼叫所触发的补充业务(例如，由MT呼叫触发的向多媒体电话的转移)。
其他的注册和位置管理场景需进一步研究。
9.3.4.2 MT/MO呼叫
在此版技术报告中提供了两种呼叫的信息流，呼叫信息流是基于下面的呼叫传递模式：
●一个从PSTN到与用户相对应的DN的呼叫被本地网的一个MGCF、ISP或IP多媒体网络的共同LAN域接收的；
●MGCF到达翻译DN的本地CSCF；
●本地CSCF询问HSS以获得与DN相匹配的用户的信息；
●本地CSCF接收到如何为呼叫分配路由的信息：在这里展示的流量中，HSS返回一个服务CSCF的信令地址，但在通常情况下，如果没有一个服务CSCF将返回的是MS的传输地址或呼叫转移号码。同时，在用户地址没有被登记的情况下，HSS将返回服务简表信息。
●本地CSCF将呼叫信令发送到所获得的地址所在地。
关于用户平面，分组信息从公共LAN域或本地网的MGW被发送到用户目前所处的承载网的GGSN。
对MO呼叫的用户平面没有考虑优化方案，在需要优化时，可用不同的标准去选择MGCF，MGCF通常为呼叫分配去PSTN的路由。
9.3.4.2.1 从PSTN到2000版全IP网络的来话呼叫
下面的流程图描述了一个MT呼叫从PSTN到2000版全IP网络用户的呼叫传递过程，该用户的地址通过DN获得。
图9-7：从PSTN到2000版全IP网络的来话呼叫
有些问题如服务质量的谈判，策略管理等还需要进一步研究。
9.3.4.2.2 从基于3GPP IP的网络/多媒体IP网络到3GPP IP网络的呼叫
下面的流程图假设一个2000版全IP网络用户已经漫游到被访问网络。该流程图描述的呼叫发自不同的全IP网络，终止于被叫用户的本地域的呼叫，它假设呼叫发出的2000版全IP网络了解地址规划方案信息(基于IP的地址规划)，这种信息允许呼叫直接终止于H-CSCF(否则，呼叫也许会通过PSTN传送，并终止于MGCF)。
具体细节还需要研究。
图9-8：从2000版全IP网到2000版全IP网的呼叫
9.3.5 场景2：确保有效的信息流
没有流程图展示给该版文本。
9.4 漫游到其他网络
为了确保2G GSM/GPRS、UMTS 99版和UMTS 00版CS以及GPRS域(不包括IP电话/多媒体域)之间的兼容性和易漫游性，在这3种网络内部和网络之间采用了相同的移动过程(在HSS中存储当前位置，使用MAP更新HSS中用户当前位置，并且在被访问节点下载/升级用户数据)。
关于目前的移动过程，显然需要做一些改进：
-00版终端在2G/99版网络的某个MSC/SGSN内漫游的情况下：
-R-SGW在HSS/SCP和2G/99版CN处理呼叫/会话过程的功能部件(MSC，SGSN等)之间转接所有的MAP/CAP信息。
-00版HSS发送给MSC/SGSN用户数据的MAP-99版翻译，这些用户数据与99版MSC/SGSN所能够处理的数据一致。这应该是对MAP应用关联处理的典型。
-在00版终端在99版网络内漫游，并且申请多媒体业务的情况下：如同99版网络一样，没有一个标准方式去拥有一个被访问的GK，
-要么，为了获得用户定制的业务，00版终端可以从自己所在的00版网络里自己的本地CSCF那里申请服务，在这种情况下R-SGW不受影响。
-要么，使用被访问PLMN内的一个GK的服务，并且这种业务不能定制，在这种情况下R-SGW不受影响。
-在99版终端在00版网络的MSC/SGSN漫游的情况下：
-R-SGW在2G/99版HLR/SCP和全IP00版CN处理呼叫/会话的功能部件之间转接所有的MAP/CAP信息。00版VLR(在SGSN和/或CS域)或者呼叫/会话处理功能部件能够解释从99版HLR/SCP处接收来的99版MAP/99版CAP。
-在99版终端漫游在00版网络内，并申请多媒体业务的情况下：如同99版网络一样，没有一个标准方式去拥有一个被访问的GK。
-要么，为了得到用户定制的业务，99版终端从它自己所在的99版网络内的本地CSCF处申请业务，在这种情况下R-SGW不受影响。
-要么，使用被访问的PLMN内的一个GK的服务，并且这种服务不能被用户定制，在这种情况下R-SGW不受影响。
目前对漫游建议了两种解决方案，这两种方案之间不完全相互矛盾，却确实存在一些好的共同之处。然而，在辨认这些共同特点和巩固这些建议方面需要做进一步工作。在这一节里通过更多的详细描述总结了这两个建议。应该进一步考虑所列出的漫游案例和所提出的关键问题，并把它们定义为进一步研究00版网络的漫游模型的基线。关于漫游的其他选择方案还需进一步研究。
9.4.1 00版网络的漫游程序
在00版网络内漫游的一种可能解决方案在Tdoc S2k99117内做了描述，其解决范围覆盖了00版网络之间的漫游和去移动遗留网络的漫游，在00版UMTS此解决方案只覆盖PS结构。在本文考虑的源自99版UMTS的漫游就是就UISM漫游而说的。此解决方案在移动管理和网络身份方面做了一定的设想，网络身份作为将来工作的一部分必须考虑。介绍一个基本的注册过程的目的是允许讨论漫游。
描述的漫游场景是：
●00版PS域网络内的漫游；
●从00版PS域网络到2G/UMTS99版网络的漫游；
●从2G/UMTS 99版网络到00版PS域网络的漫游。
9.4.2 对漫游的覆盖解决方案
这种漫游解决方案就是将介绍一种覆盖个人号码的服务，这种服务将跟踪用户注册(附接到2G/3G CS和/或PS多媒体)和呼叫接收选择过程。这就实现了对电话业务的除了网间还有业务间的漫游，电话业务在2G/3G网络中被当作典型的语音电信业务，在多媒体业务中被当作语音组成部分。
所建议的漫游解决方案在Tdoc S2K-99070内做了进一步细化，Tdoc详细描述了覆盖漫游的驱动力量，并包括了用户注册的例子和呼叫接收案例。
9.5 公开问题
下列问题需要通过与其他2000版全IP网络工作组相互交流来讨论和解决，并有可能要求在全体会议上讨论。
●支持多方语音和数据通信过程(包括为用户或服务逻辑提供动态地从正在进行的通信过程中增加或删除用户的能力)，对控制平面(如CSCF)和用户平面(如MRF的应用对IP多址广播)的影响必须做进一步研究。
●UMS的结构和功能必须定义。UMS可能有一个额外的接口(如GRIC CSP)接到H.225定义的干净房子，GRIC通信公司发展了一个全球智能交易平台(GRIC CSP)，这个平台允许不同的网络相互作用，也允许ISP、Telco以及显现的承载提供多种基于IP的业务(如，IP电话，电子商务，Internet漫游和Internet传真)。GRIC平衡其网络联盟，在全世界超过140个国家里拥有450多个主ISP和Telco，聚集了一个基于3千万拨号上网用户的可寻址用户群和一个估计有4千万企业的用户群。要了解GRIC的更多信息请上网查
http：//www.gric.org/。对发自一个全IP网络的MS的呼叫路由规划，以及为绕开PSTN使用DN分配地址都必须进行讨论。
●去LN的MT呼叫的路由规划也必须明确；
●必须讨论CSCF发现的问题，并在下次会议时提出解决方案；
●关于与第二代网络(如RAN、终端、呼叫控制和漫游，业务)兼容的要求的影响需要说明；
●与信令和传输路径的优化问题相比，位置机密问题也必须考虑到；
●2000版全IP网络必须为服务逻辑提供否决或重新分配路由给语音和/或数据通信请求的能力，这种能力必须用于来话请求和用户发起的通信请求；
●信令泛滥问题和对网络的恶意攻击都必须考虑；
●就在哪里将必须使用更多的防火墙功能来说，这个问题会影响网络结构，；
●通过使用同一IP地址为多种PDP流分配地址作为一个问题必须得到解决，前提是对GPRS来说，这个问题仍未被标准化。
●关于设置全IP网络支持的声码器的问题的细节，以及声码器谈判机制需要调查研究；
●当MS附接到/注册到网络时，信令PDP流被激活，并在整个附接/注册过程(隐藏的信令PDP流)中保持激活状态，或者它也可根据要求被激活。就寻呼问题而言，必须讨论在这两种选项之间的选择，原因是即使在MS空闲时也要为潜在的PDP语境装载MM，以及对MS造成的影响。
●T.120被认为实时应用吗？即T.120多媒体呼叫的组成部分必须由一个CSCF来控制吗？
●必须讨论和定义HSS内的数据库出现的问题以及其他的网络数据库；
●网络实体的地址分配和地址翻译需要定义(例如，假设MGCF具有根据DN恢复CSCF/MSC服务器的能力，那么MGCF怎样才能做到，还需进一步研究)
●为了支持到第二代遗留网络的漫游，必须讨论在2000版全IP网络存储第二代文档，特别是，需要讨论在HSS内提供一个第二代HLR以及对选择对象的评估。
●应该考虑长远问题和设想，即不只和00版有关，以便为将来的解决方案提供依据，例如，关于地址分配机制(如动态对静态，IPv4对Ipv6)的长远要求也应该考虑到；
●能够在一个服务域内为用户捕捉到服务简表的“VLR”类型的功能需要做出定义，此功能不应该与位置管理有关，而只集中在服务简表上；
●在此文本中并没有给出词汇“位置”在蜂窝/无线社区内的定义和在IETF社区内的定义的不同之处，这还需要进行协调。
●需要考虑到基于位置的业务的提供(例如基于地理位置信息的业务)和对结构的影响；
●对服务质量和安全性问题仍未做出陈述。
10.服务平台的影响
10.1 3GPP2000版服务结构
这一节描述了怎样通过扩展VHE/OSA概念到多媒体核心网络，使3GPP 99版服务结构能够应用于3GPP 2000版网络中，这可以通过从CSCF起提供一个应用接口(如VHE规范[3]内所描述的)来实现，见图10-1。当VHE希望服务会落在端接用户(本地环境)的本地域里，其他网络元素除CSCF外，都可被要求提供一个漫游结构，这个漫游结构允许服务域传送控制权到本地域，服务逻辑就位于本地域。
注意：图10-1和图10-2中的结构展示了CAMEL服务环境(CSE)，这个服务环境没有在第5节参考结构中展示出来。
图10-1 3GPP2000版服务结构
开放式服务结构包括三部分，如图10-1所示(注意此图并没有完全展示所有的相互关系)：
在当前的3GPP规范内，这是通过CAMEL获得的，CAMEL为服务网络和本地网络提供CAP接口。
-应用，例如VPN、会议系统、位置应用软件。这些应用软件都是在一个或多个应用服务器里执行。
-框架，提供给应用软件基本业务，以确保应用软件能够利用网络的服务能力，框架业务的例子如鉴权、注册和发现。
-服务能力，为应用软件提供从基本网络功能中提取出来的业务，如呼叫控制、信息转移和位置。这些业务可能由不止一个服务能力服务器提供，例如，呼叫控制可能由CAMEL和MexE提供。99版UMTS考虑的服务能力服务器有CAMEL、MexE、SAT和HLR。
图10-2：开放服务结构的一览
注意：这可能不完全符合VHE/OSA第二阶段的最新版本
10.2 基于IN的业务
基于IN的业务是遗留业务的一个例子，基于IN的服务逻辑是如何介绍遗留业务到3GPP2000版网络的例子。这个基于IN的服务逻辑在3GPP 2000版网络中，当被要求完全支持多媒体时，需要进行改进，使其以所建议的结构为基础。
当只必须支持语音/视频时存在几个选项：
1.为去遗留网络的呼叫重新分配路由，这只适用于非常具体的业务，如800和900业务。
2.在3GPP2000版网络功能块(如CSCF)和遗留的SCP之间提供“INAP”类接口，这些接口将用于网络之间和网络内部的连接，要完成这些必须基于合适的INAP协议(如CAP)。
3.允许AS接入遗留SCP的应用部分，在遗留IN和3GPP2000版网络功能块之间提供新的接口。
需要注意的是，为符合QoS要求的GPRS网络定义的运营商明确的业务仍然是可能得到的，并且能够向MM核心网络申请接入承载。举个例来说，这将使GPRS承载的预付费成为可能。
如下面章节所示，选项2(10.2.1节)将允许升级现存业务，以提供给3G用户大家熟悉的2G业务的无缝处理，尤其是在漫游时。选项3(10.2.2节)不具有这样的优势，但得益于将来的试验。允许这两种选项共存看来是合适的，对遗留CAMEL业务的支持可通过选项2实现，而提高的/将来的业务可通过选项3勾勒的OSA原则来提供或者通过两种选项的组合来提供。
10.2.1 遗留SCP和00版网络实体之间的基于“INAP”的接口
在此选项中，经典的IN模型被扩展包括CSCF，把CSCF作为一个节点，提供业务交换功能(基于gsmSSF的23.078规范)和使用CAP的基于协议(TCAP)的事物处理。从概念上讲，在CSCF和CSE之间引入一个新的功能实体，这个功能实体叫做softSSF，能潜在的以修改过的99版GMSC、VMSC和VLR功能性为基础，在那里保持了或者提高了呼叫控制排序和数据库功能。SoftSSF通过CAP与CSE相互作用，通过一个内部接口(如果它与CSCF一起存在)或者通过一个基于OSA概念(如果softSSF被展开作为一个服务能力服务器)的开放式接口与CSCF相互作用。在考虑IP呼叫控制的潜在影响时，希望对CAP做一些改变。CSE能够通过定义好的基于OSA原理的开放式接口提供它的业务，这些业务由CSE通过CAP接口传到SGSN和CSCF来实现。(注意CSCF也可能通过定义好的基于OSA原理的开放式接口来提供)。
这个选项有益于标准化过程(gsmSSF)、协议(CAP)和已经拓展了的业务的广泛再利用。
图10-2支持选项2的功能结构
10.2.1.1 优点
●最大限度的再利用现有的功能实体、协议和业务，这种再利用允许从早期阶段就将现有的、人们熟悉的2G业务提供给3G用户，从而降低了发展和所有权的成本。
●为了支持遗留业务，对CSE做最小的改动。已经有一些IN/CAMEL业务已经展开了预付费、虚拟专用网、移动号码可携带性等服务，这些服务都可用于IP网的语音业务。
●从潜在意义上讲，CAP/TAP可做基于IP的载体(这还需要进一步研究/贡献)
●这种方法是与在ETSI SPAN 3(业务和协议)正在进行的工作是相平齐的，尤其是一个H.323结构中讲述IN支持IP语音业务的工作条款和与TIPHON相关的有关协议。该研究将要调查H.323网闸怎样能被用做虚拟业务交换节点(SSP)。值得注意的是，ETSI计划协调固定线路IN协议(ETSI核心INAP CS3.1)和移动等效(CAP阶段3)到针对ETSI核心INAP CS4的公共协议中。
10.2.1.2 缺点
●介绍的新功能实体‘softSSF’提供了CSCF和CSE之间必要的映射，但是这个功能实体是以VMSC/GMSC已经提供的功能为基础，在那里标准化过程如gsmSSF可被重新利用。CSCF和softSSF之间的接口需要进一步研究。
10.2.2 遗留SCP和00版网络实体间的新的开放式接口
此选项采用了OSA原则，在这个原则里，服务能力服务器如CSCF和遗留SCF已经定义了API，API允许应用软件在各自的应用服务器里使用这些SCS提供的特性。这种方法允许SCS提供的服务特性使应用软件设计者不用太了解具体的协议。目前，SCS反映了UMTS内的服务能力，CAMEL就是一个例子。摘自TS 22.121-“一个应用能力服务器包括一个或几个服务器元素，以CAMEL业务为例，服务器元素是呼叫控制、位置/定位、PLMN信息和通告，这些服务器元素都通过定义的开放式接口提供各自的业务，并通过应用GSM/UMTS协议来执行这些业务”
问题是在全IP网络内，上面提到的服务器元素并不都可能通过CSE，因为在CSE和网络之间没有为呼叫控制设置潜在协议(除去CSE/SGSN接口)。为了提供现存遗留业务的相同功能，就必须创建新的应用，它可使由CSE(例如数据库查询)提供的功能的一些有限使用加上在CSCF提供的服务功能。
支持客户-服务器模式的API仍将存在，这些API能使用户通过UE和专家服务器(如MexE)进入服务逻辑，这些专家服务器和CSCF之间的接口需要进一步研究。
图10-3选项3的功能结构
10.2.2.1 优点
●基于OSA概念的开放式接口，希望API，连接CSCF和CSE的接口，能够允许具体的协议对服务/应用设计者隐蔽起来。
●能够容易对多媒体应用展开新的/增强的业务。
10.2.2.2 缺点
●当考虑到现存基于CSE业务时，几乎没有重新利用已经标准化了的协议、业务和过程，更重要的是，必须重新定义新的过程和协议，并且对已经存在的业务必须重新执行这些新的协议和过程，这就增加了发展和所有权的成本。
●为了支持遗留业务，要求给应用服务器创建新的应用软件。
●应该考虑的对遗留CSE和业务的影响比选项2的大。
10.3 要求进一步研究的问题
下面的问题需要进一步研究：
●应用软件不但可以装在应用服务器上(AS)，也可装在终端上。
●可选择在AS和终端之间共享全部或部分应用软件。
●除CSCF外，有哪些元素将为应用设计(与VHE/OSA一起)提供API。
●终端也将为应用设计提供API(与MexE一起)。
●3GPP 2000版需要哪些新的服务能力/服务能力特性(例如WIN)。
●应该提供所建议的结构的具体执行情况。
●2G终端通过2G网络是否能够和怎样使用2000版的特色业务
●3GPP 2000版特色业务是否和怎样通过2G网络使2G/3G终端接入。
11.安全性
对工作在全IP模式的终端将有一个基于SIM/USIM的公共鉴权方案，要求全IP终端在与3GPP SIM/USIM一起使用时，能够注册和提供基本业务。
12.工作计划
12.1 00版大事记
3GPP的目标是截止2000年底为UMTS制定出其规范的第二版本，这项工作的项目管理将需要包括工作包定义的元素、这些工作的相关性以及它们的时间安排。当这些工作在3GPP不同的TSG和WG内执行时，要做全面计划就需要有协议贯穿这些组。随后的在这些组之间关于时间表变化和要求的通信是最基本的通信过程，通信的一项额外任务就是回顾文本的要求，以鉴别在早期执行阶段出现的技术问题。99版的完成对资源的可用性具有潜在的影响，并因此影响了00版的时间安排。
注意：下面的文章是比文本的其余部分更全面的本质内容，这已经被包括进去用来为2000版展示框架，在这个框架里，全IP结构可能就是一项工作。展示的日期是假定的日期，需要由TSG-S2来修改。
12.1.1 00版大事记
3GPP还没有同意为00版制定的全部重要事件。为了制定一个高水平的工作计划，建议了以下关键的重要事件。
99年7月 3GPP全IP网络可行性研究开始
99年9月 TSG-S2 R00 Ad Hoc将递交TSG-S2的结果，以获得正式批准
99年10月 TSG-S2获得批准后，TSG-S2 R00 Ad Hoc组的结果将递交给TSG-S，以获得正式批准
99年10月 获得TSG-S批准后，对00版(包括全IP选项)的项目编排工作将要在TSG-S2项目编排ad hoc组(这些组已经从所有相应TSG/WG开始充分参与进去)开始。
99年12月 获得TSG-S2批准后，00版(包括全IP网络选项)的具体工作计划将递交给TSG-S以获得正式批准。
99年12月 得到可用的00版业务要求
00年1月 TSG-SA2首次完成了全IP网络的结构草案
00年1月-00年12月 根据TSG-S批准的00版项目计划，工作在3GPP TSG和WG内部继续进行
00年12月 完成了包括全IP选项的00版规范
在下页给出了一幅高水平的PERT表，构成99版以后版本的计划编排的基础。讨论过的业务的第一份草案和结构规范应该在99年之前可被利用上。
12.1.2 详细的活动计划
| 日期 | 会议组 | 建议的活动 |
| 8月23-27 | S2 | 进行结构研究 |
| 9月13-17 | S2 | 关于00版的S1-S2共同活动-最后定下来对结构研究的要求并明确了关键问题。最后定下来TSG-S2 R00 ad hoc组建议的00版结构。 |
| 9月末/10月初 | S2 R00 Ad Hoc组会议(临时的) | 尽可能精练ad hoc组的成果 |
| 9月29日-10月1日 | S1 | 评论关于对00版业务要求的输入 |
| 10月11-13 | SA全体会议 | 通过TSG-S2 R00 Ad Hoc组的结果 |
| 10月25-29 | S2 | 开始制定结构规范和详细的工作计划。开始S2项目协调adhoc组工作，这项工作是基于TSG-SA全体会议的结果和其他团体通过的结果，例如，移动IP ad-hoc组 |
| 11月29日-12月3日 | S1 | 评论业务要求和结构 |
| 11月29日-12月3日 | S2 | 制定结构规范 |
| 12月15日-12月17日 | SA全体会议 | 批准TSG-S2项目协调adhoc组的详细工作计划 |
图14-1：3GPP在99版之后的标准化
历史
| V0.0,0 | 1999.07 | 创建文本 |
| V0.01 | 1999.08.11 | |
| 8月10日至11日，按照 |
| 2000版Ad Hoc Swindon更新文本。阐明范围并增加新的条文给关于支持99版终端的要求、业务平台区域和新的结构子区域。结构变化：新的CSCF-CSCF间的接口、MGW分裂为MGW和传输信令网关、标示为漫游网关的SGW。 | ||
| V0.0.2 | 1999.09.01 | 随着00版Ad Hoc升级，升级以tdoess2k99030，s2k99031，s2k99032，s2k99035，s2k99045，s2k99049为基础。 |
| V0.0.3 | 1999.09.06 | 用通过e-mail方式评论的新的部分升级，包含有与V0.0.2相比明显的变化 |
| V0.1.0 | 1999.09.22 | 根据从9月13日开始的周会(Bonn)升级。关于切换和IP标题压缩/剥离的新文章、MC参考点的定义以及媒体网关功能块的定义。 |
| V0.1.1 | 1999.09.28 | 对Ad Hoc Hdlsinki的草案，所做的变更包括在第5节增加了HSS、通过了支持CS终端的解决方案。 |
| V0.1.2 | 1999.9.29 | 对Ad Hoc Hdlsinki的d第二份草案，所做的变更包 |
| 括：在第9节陈述了编者的注意事项，增加了关于服务质量、安全性和新的业务平台子区域的文章 | ||
| V0.1.3 | 1999.09.30 | 00版Ad Hoc，Helsinki的临时草案 |
| V0.1.4 | 1999.10.01 | 为正式批准准备的最后草案 |
| V1.0.0 | 1999.10.07 | 准备在SA#5的陈述，与v.0.1.4具有相同的技术内容 |
Claims (36)
1.一种分组交换环境，包含在应用和服务环境中的存在服务器的功能。
2.根据权利要求1的分组交换环境，其中所述存在服务器根据同一网络内的询问呼叫状态控制功能接收“注册”消息。
3.根据权利要求2的分组交换环境，其中所述存在服务器网络的服务呼叫状态控制功能也接收所述“注册”消息。
4.根据权利要求2或3的分组交换环境，其中所述存在服务器根据同一网络内的询问呼叫状态控制功能接收“预约”消息。
5.根据权利要求4的分组交换环境，其中所述询问呼叫状态控制功能从用户归属网络内的服务呼叫状态控制功能接收所述“预约”消息。
6.根据权利要求5的分组交换环境，其中所述服务呼叫状态功能从用户归属网络内的代理呼叫状态控制功能接收所述“预约”消息。
7.根据权利要求6的分组交换环境，其中所述代理呼叫状态控制功能从所述用户接收所述“预约”消息。
8.根据权利要求2-7任何一项的分组交换环境，其中所述存在服务器为所述用户网络的所述询问呼叫状态控制功能提供“通知”消息。
9.根据权利要求8的分组交换环境，其中所述询问呼叫状态控制功能为所述用户网络的代理呼叫状态控制功能提供所述“通知”消息。
10.根据权利要求9的分组交换环境，其中所述代理呼叫状态控制功能为所述用户提供所述“通知”消息。
11.根据权利要求1的分组交换环境，其中所述存在服务器从用户网络内的相应多个用户接收多个“预约”信号。
12.根据权利要求11的分组交换环境，其中每个用户为所述用户网络的代理呼叫状态控制功能提供“预约”消息。
13.根据权利要求12的分组交换环境，其中所述用户网络的所述代理呼叫状态控制功能将所述相应的“预约”消息转发到所述用户网络的服务呼叫状态控制功能。
14.根据权利要求13的分组交换环境，其中所述归属网络的所述服务呼叫状态控制功能为所述存在服务器网络的询问呼叫状态控制功能提供所述相应的“预约”消息。
15.根据权利要求14的分组交换环境，其中所述询问呼叫状态控制功能为所述存在服务器提供所述相应的“预约”消息。
16.根据权利要求11-15任何一项的分组交换环境，其中所述存在服务器为所述存在服务器网络的服务呼叫状态控制功能提供单个“预约”消息。
17.根据权利要求16的分组交换环境，其中所述存在服务器从所述服务呼叫状态控制功能接收单个“通知”消息。
18.根据权利要求17的分组交换环境，其中所述存在服务器为每个相应的用户生成“通知”消息。
19.根据权利要求18的分组交换环境，其中所述多个“通知”消息由所述用户网络的所述询问呼叫状态控制功能接收。
20.根据权利要求19的分组交换环境，其中所述询问呼叫状态控制功能将所述“通知”消息转发到所述用户网络的服务呼叫状态控制功能。
21.根据权利要求20的分组交换环境，其中所述服务呼叫状态控制功能将所述“通知”消息转发到所述用户网络的代理呼叫状态控制功能。
22.根据权利要求21的分组交换环境，其中所述代理呼叫状态控制功能将所述“通知”消息转发到所述相应用户。
23.根据权利要求2的分组交换环境，其中所述存在服务器从所述存在服务器网络内的服务呼叫状态控制功能接收“注册”消息。
24.根据权利要求23的分组交换环境，其中所述服务呼叫状态控制功能从所述存在服务器网络的询问呼叫状态功能接收所述“注册”消息。
25.根据权利要求24的分组交换环境，其中用户为所述用户网络的代理呼叫状态控制功能提供“预约”消息。
26.根据权利要求25的分组交换环境，其中所述用户网络的所述代理呼叫状态控制功能将所述“预约”消息转发到所述用户网络的服务呼叫状态控制功能。
27.根据权利要求13的分组交换环境，其中所述用户网络的服务呼叫状态控制功能为所述存在服务器网络的询问呼叫状态控制功能提供所述“预约”消息。
28.根据权利要求14的分组交换环境，其中所述询问呼叫状态控制功能为服务呼叫状态控制功能提供所述相应的“预约”消息。
29.根据权利要求28的分组交换环境，其中所述服务呼叫状态控制功能为存在服务器提供所述“预约”消息。
30.根据权利要求29的分组交换环境，其中所述存在服务器为所述服务呼叫状态控制功能提供“通知”消息。
31.根据权利要求30的分组交换环境，其中所述“通知”消息由所述用户网络的所述询问呼叫状态控制功能接收。
32.根据权利要求31的分组交换环境，其中所述询问呼叫状态控制功能将所述“通知”消息转发到所述用户网络的服务呼叫状态控制功能。
33.根据权利要求32的分组交换环境，其中所述服务呼叫状态控制功能将所述“通知”消息转发到所述用户网络的代理呼叫状态控制功能。
34.根据权利要求33的分组交换环境，其中所述代理呼叫状态控制功能将所述“通知”消息转发到所述用户。
35.前述任何一项权利要求的分组交换环境，其中所述环境为网际协议多媒体环境。
36.根据权利要求35的分组交换网络，其中所述网际协议多媒体环境为全IP电信网的分系统。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB0108041.5 | 2001-03-30 | ||
| GBGB0108041.5A GB0108041D0 (en) | 2001-03-30 | 2001-03-30 | Presence service in IP multimedia |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN1509577A true CN1509577A (zh) | 2004-06-30 |
Family
ID=9911938
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNA028098102A Pending CN1509577A (zh) | 2001-03-30 | 2002-04-02 | Ip多媒体中的存在服务器 |
Country Status (11)
| Country | Link |
|---|---|
| US (2) | US20040109439A1 (zh) |
| EP (1) | EP1389396A1 (zh) |
| JP (1) | JP2004533173A (zh) |
| CN (1) | CN1509577A (zh) |
| AU (1) | AU2002311574A1 (zh) |
| BR (1) | BR0208543A (zh) |
| CA (1) | CA2442568A1 (zh) |
| GB (2) | GB0108041D0 (zh) |
| RU (1) | RU2315436C2 (zh) |
| WO (1) | WO2002096128A2 (zh) |
| ZA (1) | ZA200307561B (zh) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN100435533C (zh) * | 2004-07-01 | 2008-11-19 | 国际商业机器公司 | 用于即时消息收发的方法和设备 |
| CN100450210C (zh) * | 2005-12-23 | 2009-01-07 | 华为技术有限公司 | 一种r4网络系统及提供媒体资源的方法 |
| CN100461774C (zh) * | 2005-06-20 | 2009-02-11 | 华为技术有限公司 | 一种订阅存在信息的方法 |
| CN101180619B (zh) * | 2005-02-28 | 2012-05-23 | 雅虎公司 | 媒体管理系统和方法 |
| US8819151B2 (en) | 2005-10-11 | 2014-08-26 | Huawei Technologies Co., Ltd. | Method for processing deferred message |
Families Citing this family (51)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2004034718A1 (en) | 2002-10-09 | 2004-04-22 | Nokia Corporation | A communication system |
| WO2004034719A1 (en) * | 2002-10-09 | 2004-04-22 | Nokia Corporation | A communication system |
| DE10255920A1 (de) * | 2002-11-29 | 2004-06-17 | Siemens Ag | Verfahren zum Bereitstellen von Präsenzinformationen mindestens einer Kommunikationsheinheit auf mindestens einem Präsenzserver, zugehörige Kommunikationseinheit, Präsenzserver sowie Kommunikationsnetz |
| US7523165B2 (en) * | 2002-12-24 | 2009-04-21 | Telefonaktiebolaget L M Ericsson (Publ) | Transmission of application information and commands using presence technology |
| US20040128391A1 (en) * | 2002-12-31 | 2004-07-01 | Robert Patzer | Method and system for managing a validity period in association with a presence attribute |
| CN101834869A (zh) * | 2003-02-19 | 2010-09-15 | 诺基亚公司 | 通过ims系统路由消息 |
| EP1597896A2 (en) * | 2003-02-19 | 2005-11-23 | Nokia Corporation | Routing messages via an ims system |
| GB0306830D0 (en) * | 2003-03-25 | 2003-04-30 | Nokia Corp | Routing messages |
| EP1458161A1 (de) * | 2003-03-14 | 2004-09-15 | Siemens Aktiengesellschaft | Verfahren und Vorrichtung für die Interoperabilität zwischen den Präsenz-Services gemäss dem Wireless Village Standard und dem IP Multimedia Subsystem Standard |
| US8001233B2 (en) | 2003-03-25 | 2011-08-16 | Nokia Corporation | Communication system, network element, and method for configuring a network element using routing subscription information |
| US20040205212A1 (en) * | 2003-03-31 | 2004-10-14 | Nokia Corporation | Method and system for forwarding a service-related information to a network user |
| DE10314927A1 (de) * | 2003-04-02 | 2004-10-21 | Siemens Ag | Abbildung der Signalisierung vom WV-Standard in den IMS-Standard |
| GB2400273A (en) * | 2003-04-05 | 2004-10-06 | Hewlett Packard Development Co | Managing use of services in wireless networks |
| US7283506B2 (en) * | 2003-10-13 | 2007-10-16 | Nokia Corporation | System and method for releasing sessions at network entities associated with the sessions |
| US7701974B2 (en) * | 2003-10-21 | 2010-04-20 | Nokia Corporation | Routing information processing for network hiding scheme |
| CN100466648C (zh) * | 2003-12-31 | 2009-03-04 | 华为技术有限公司 | 一种会话建立协议组网方式及实现群组消息的方法 |
| JP4317061B2 (ja) * | 2004-03-16 | 2009-08-19 | 株式会社日立製作所 | プレゼンス情報の共有方法およびシステム |
| KR100823128B1 (ko) * | 2004-06-30 | 2008-04-21 | 삼성전자주식회사 | 통합 서비스 제공 시스템의 정보 관리 방법 및 장치 |
| DE102004038646A1 (de) * | 2004-08-09 | 2006-02-23 | Siemens Ag | Bereitstellung zumindest einer Adresse eines Applikationsservers |
| US7676577B2 (en) | 2004-12-21 | 2010-03-09 | Alcatel Lucent | Scalable presence distribution system and method |
| CN100461782C (zh) * | 2005-09-01 | 2009-02-11 | 华为技术有限公司 | 一种ip多媒体子系统中实现桥接的系统和方法 |
| US8819181B2 (en) * | 2006-03-17 | 2014-08-26 | Apple Inc. | Adaptable network service access through dynamic request routing |
| DE602006016658D1 (de) * | 2006-12-11 | 2010-10-14 | Ericsson Telefon Ab L M | Dienstanpassung in einem IP-Multimedia-Subsystem-Netz |
| JP5066608B2 (ja) | 2007-07-10 | 2012-11-07 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | Ｉｍｓを用いたオペレータ提供ネットワークサービスの発見方法 |
| RU2447601C2 (ru) * | 2007-10-31 | 2012-04-10 | Телефонактиеболагет Лм Эрикссон (Пабл) | Сжатие полезной нагрузки сообщения протокола инициирования сеанса |
| US8218459B1 (en) * | 2007-12-20 | 2012-07-10 | Genbrand US LLC | Topology hiding of a network for an administrative interface between networks |
| CN102098652B (zh) * | 2008-01-18 | 2012-12-12 | 华为技术有限公司 | 一种为用户提供业务的方法、系统和装置 |
| US8787249B2 (en) * | 2008-02-06 | 2014-07-22 | Qualcomm Incorporated | Mobile IP multiple registrations and PCC interactions |
| GB0804274D0 (en) * | 2008-03-07 | 2008-04-16 | Virtually Live Ltd | A media sysyem and method |
| US8724486B2 (en) * | 2008-05-02 | 2014-05-13 | Pine Valley Investments, Inc. | System and method for heartbeat signal generation |
| US9131425B2 (en) * | 2008-06-09 | 2015-09-08 | Qualcomm Incorporated | Method and apparatus for PCC enhancement for flow based mobility |
| US8228848B2 (en) * | 2008-11-17 | 2012-07-24 | Sierra Wireless, Inc. | Method and apparatus for facilitating push communication across a network boundary |
| US8924486B2 (en) | 2009-02-12 | 2014-12-30 | Sierra Wireless, Inc. | Method and system for aggregating communications |
| EP2290906A1 (en) * | 2009-08-28 | 2011-03-02 | TeliaSonera AB | Mobile service advertiser |
| US9204415B2 (en) | 2009-10-30 | 2015-12-01 | Panasonic Intellectual Property Corporation Of America | Communication system and apparatus for status dependent mobile services |
| JP5795848B2 (ja) * | 2010-09-22 | 2015-10-14 | キヤノン株式会社 | 情報処理装置、その制御方法、及びプログラム |
| US9276972B2 (en) | 2010-12-14 | 2016-03-01 | Microsoft Technology Licensing, Llc | Real-time media optimization over remoted sessions |
| CN102612141B (zh) * | 2011-01-19 | 2017-06-13 | 中兴通讯股份有限公司 | 移动交换中心获取ims控制点信息的方法及系统 |
| WO2012106820A1 (en) | 2011-02-08 | 2012-08-16 | Sierra Wireless, Inc. | Method and system for forwarding data between network devices |
| RU2464727C1 (ru) * | 2011-03-25 | 2012-10-20 | Общество С Ограниченной Ответственностью "Аилайн Кэмьюникейшнс Снг" | Способ предоставления информации при проведении распределенных транзакций и комплекс для его осуществления |
| RU2453916C1 (ru) * | 2011-05-05 | 2012-06-20 | Игорь Викторович Лебедев | Способ поиска информационных ресурсов с использованием переадресаций |
| CN104254998B (zh) * | 2012-03-14 | 2017-10-20 | 瑞典爱立信有限公司 | 用于在多点传输中通知节点的方法 |
| RU2557451C2 (ru) * | 2012-06-08 | 2015-07-20 | Ольга Игоревна Галицына | Способ динамической адресации корреспондентов мобильной радиосети и устройство для его реализации |
| RU2533310C2 (ru) * | 2012-11-08 | 2014-11-20 | Корпорация "САМСУНГ ЭЛЕКТРОНИКС Ко., Лтд." | Вспомогательный способ и система для обнаружения беспроводных сигналов мобильными устройствами |
| RU2535172C2 (ru) * | 2013-02-26 | 2014-12-10 | Открытое Акционерное Общество "Информационные Технологии И Коммуникационные Системы" | Способ предотвращения повторного использования пакетов цифровых данных в сетевой системе передачи данных |
| BR112019006929A2 (pt) | 2016-10-09 | 2019-07-02 | Huawei Tech Co Ltd | método, aparelho, e dispositivo de controle de acesso à rede |
| CN108989242B (zh) * | 2017-02-03 | 2020-01-03 | 华为技术有限公司 | 一种改变数据无线承载映射的QoS流处理方法和设备 |
| US10193840B1 (en) * | 2017-07-31 | 2019-01-29 | T-Mobile U.S.A., Inc. | Message blocking and network queuing, for example while recipient is driving |
| US10819805B2 (en) | 2017-12-05 | 2020-10-27 | At&T Intellectual Property I, L.P. | Systems and methods for providing ENUM service activations |
| US10855647B2 (en) | 2017-12-05 | 2020-12-01 | At&T Intellectual Property I, L.P. | Systems and methods for providing ENUM service activations |
| CN113647077B (zh) * | 2019-03-29 | 2023-07-04 | 瑞典爱立信有限公司 | 启用基于服务的接口的归属订户服务选择 |
Family Cites Families (33)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5313653A (en) * | 1992-01-30 | 1994-05-17 | Motorola, Inc. | Method for a communication unit to maintain a data base of system services |
| US5600704A (en) * | 1994-08-30 | 1997-02-04 | Ericsson Inc. | Systems and methods for prioritized routing of telephone calls to a subscriber |
| WO1996017306A2 (en) * | 1994-11-21 | 1996-06-06 | Oracle Corporation | Media server |
| US5812670A (en) * | 1995-12-28 | 1998-09-22 | Micali; Silvio | Traceable anonymous transactions |
| GB2310110B (en) * | 1996-02-09 | 2000-05-10 | Nokia Mobile Phones Ltd | Transferring information |
| US5901352A (en) * | 1997-02-20 | 1999-05-04 | St-Pierre; Sylvain | System for controlling multiple networks and associated services |
| FI105986B (fi) * | 1997-11-26 | 2000-10-31 | Nokia Networks Oy | Tilaajan palveluprofiilit tietoliikennejärjestelmässä |
| US6330610B1 (en) * | 1997-12-04 | 2001-12-11 | Eric E. Docter | Multi-stage data filtering system employing multiple filtering criteria |
| FI105966B (fi) * | 1998-07-07 | 2000-10-31 | Nokia Networks Oy | Autentikointi tietoliikenneverkossa |
| US6327267B1 (en) * | 1998-12-21 | 2001-12-04 | Ericssoninc | Systems and methods for routing a message through a signaling network associated with a public switched telephone network (PSTN), including a method for performing global title routing on an internet protocol (IP) address |
| US6625141B1 (en) | 1999-06-18 | 2003-09-23 | Telefonaktiebolaget L M Ericsson (Publ) | System and method for providing value-added services (VAS) in an integrated telecommunications network using session initiation protocol (SIP) |
| US7093286B1 (en) * | 1999-07-23 | 2006-08-15 | Openwave Systems Inc. | Method and system for exchanging sensitive information in a wireless communication system |
| US6615236B2 (en) * | 1999-11-08 | 2003-09-02 | Worldcom, Inc. | SIP-based feature control |
| US7007080B2 (en) * | 1999-12-23 | 2006-02-28 | Solution Inc Limited | System for reconfiguring and registering a new IP address for a computer to access a different network without user intervention |
| US6763233B2 (en) * | 2000-01-05 | 2004-07-13 | Nortel Networks Limited | Terminal roaming operations between intergenerational wireless networks |
| US20020035605A1 (en) * | 2000-01-26 | 2002-03-21 | Mcdowell Mark | Use of presence and location information concerning wireless subscribers for instant messaging and mobile commerce |
| US6662014B1 (en) * | 2000-02-04 | 2003-12-09 | Sbc Properties, L.P. | Location privacy manager for a wireless communication device and method therefor |
| US6707813B1 (en) * | 2000-02-21 | 2004-03-16 | Telefonaktiebolaget L M Ericsson (Publ) | Method of call control to minimize delays in launching multimedia or voice calls in a packet-switched radio telecommunications network |
| EP1262055B1 (en) * | 2000-02-22 | 2008-01-16 | Nortel Networks Limited | System and method for controlling a wireless packet switched voice call |
| US7076255B2 (en) * | 2000-04-05 | 2006-07-11 | Microsoft Corporation | Context-aware and location-aware cellular phones and methods |
| US7110773B1 (en) * | 2000-04-11 | 2006-09-19 | Telecommunication Systems, Inc. | Mobile activity status tracker |
| US20020037723A1 (en) * | 2000-06-08 | 2002-03-28 | Adam Roach | Refreshing service profile information using third-party SIP register messages |
| US7126939B2 (en) * | 2000-07-24 | 2006-10-24 | Nortel Networks Limited | Packet-based calls in a wireless network |
| US20020026473A1 (en) * | 2000-08-31 | 2002-02-28 | Telefonaktiebolaget Lm Ericsson (Publ) | Application-programming-interface-based method and system including triggers |
| AU2000275137A1 (en) | 2000-09-01 | 2002-03-13 | Nokia Corporation | Extending sip for uploading subscriber's service profile from hss to cscf |
| US6654606B1 (en) * | 2000-09-29 | 2003-11-25 | Telefonaktiebolaget L M Ericsson (Publ) | Call state control function (CSCF) call processing |
| AU2001294093A1 (en) * | 2000-10-10 | 2002-04-22 | Nokia Corporation | Techniques for hiding network element names and addresses |
| US7870196B2 (en) * | 2000-11-08 | 2011-01-11 | Nokia Corporation | System and methods for using an application layer control protocol transporting spatial location information pertaining to devices connected to wired and wireless internet protocol networks |
| US6944679B2 (en) * | 2000-12-22 | 2005-09-13 | Microsoft Corp. | Context-aware systems and methods, location-aware systems and methods, context-aware vehicles and methods of operating the same, and location-aware vehicles and methods of operating the same |
| CA2428329C (en) | 2000-12-22 | 2007-05-29 | Nokia Corporation | Method and system enabling prepaid service in an all-ip network |
| US20020110104A1 (en) * | 2001-02-13 | 2002-08-15 | Telefonaktiebolaget Lm Ericsson (Publ). | Hybrid media gateway control function providing circuit-switched access to a packet-switched radio telecommunications network |
| US20020147845A1 (en) * | 2001-03-06 | 2002-10-10 | Juan-Antonio Sanchez-Herrero | Flexible user distribution between user's serving entities |
| US7054648B2 (en) * | 2001-10-22 | 2006-05-30 | Telefonaktiebolaget Lm Ericsson (Publ) | Location privacy proxy server and method in a telecommunication network |
-
2001
- 2001-03-30 GB GBGB0108041.5A patent/GB0108041D0/en not_active Ceased
-
2002
- 2002-01-14 GB GBGB0200714.4A patent/GB0200714D0/en not_active Ceased
- 2002-04-02 JP JP2002592654A patent/JP2004533173A/ja active Pending
- 2002-04-02 BR BR0208543-7A patent/BR0208543A/pt not_active IP Right Cessation
- 2002-04-02 AU AU2002311574A patent/AU2002311574A1/en not_active Abandoned
- 2002-04-02 RU RU2003131893/09A patent/RU2315436C2/ru active
- 2002-04-02 WO PCT/IB2002/002212 patent/WO2002096128A2/en active Application Filing
- 2002-04-02 CA CA002442568A patent/CA2442568A1/en not_active Abandoned
- 2002-04-02 CN CNA028098102A patent/CN1509577A/zh active Pending
- 2002-04-02 US US10/473,671 patent/US20040109439A1/en not_active Abandoned
- 2002-04-02 US US10/473,300 patent/US8516115B2/en active Active
- 2002-04-02 EP EP02735815A patent/EP1389396A1/en not_active Withdrawn
-
2003
- 2003-09-29 ZA ZA200307561A patent/ZA200307561B/en unknown
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN100435533C (zh) * | 2004-07-01 | 2008-11-19 | 国际商业机器公司 | 用于即时消息收发的方法和设备 |
| CN101180619B (zh) * | 2005-02-28 | 2012-05-23 | 雅虎公司 | 媒体管理系统和方法 |
| CN100461774C (zh) * | 2005-06-20 | 2009-02-11 | 华为技术有限公司 | 一种订阅存在信息的方法 |
| US8819151B2 (en) | 2005-10-11 | 2014-08-26 | Huawei Technologies Co., Ltd. | Method for processing deferred message |
| US9397968B2 (en) | 2005-10-11 | 2016-07-19 | Huawei Technologies Co., Ltd. | Method for processing deferred message |
| CN100450210C (zh) * | 2005-12-23 | 2009-01-07 | 华为技术有限公司 | 一种r4网络系统及提供媒体资源的方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| GB0200714D0 (en) | 2002-02-27 |
| BR0208543A (pt) | 2004-03-23 |
| WO2002096128A2 (en) | 2002-11-28 |
| GB0108041D0 (en) | 2001-05-23 |
| RU2315436C2 (ru) | 2008-01-20 |
| ZA200307561B (en) | 2005-08-10 |
| US20040109439A1 (en) | 2004-06-10 |
| JP2004533173A (ja) | 2004-10-28 |
| RU2003131893A (ru) | 2005-05-10 |
| CA2442568A1 (en) | 2002-11-28 |
| US20040088419A1 (en) | 2004-05-06 |
| AU2002311574A1 (en) | 2002-11-05 |
| EP1389396A1 (en) | 2004-02-18 |
| US8516115B2 (en) | 2013-08-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN1509577A (zh) | Ip多媒体中的存在服务器 | |
| CN1228942C (zh) | 用于提供小组通信服务的系统和方法 | |
| Camarillo et al. | The 3G IP multimedia subsystem (IMS): merging the Internet and the cellular worlds | |
| CN1242596C (zh) | 瞬时消息接发 | |
| CN1625907A (zh) | 分组模式语音通信 | |
| CN1231028C (zh) | 在不同网络的匿名用户之间智能建立会话的分布式系统 | |
| CN1247036C (zh) | 在现有的通信系统中参与小组通信服务的方法和设备 | |
| US7920529B1 (en) | Intermediary query manager for 2G and 3G services | |
| CN1557088A (zh) | 定制呼叫提示的系统和方法 | |
| US11621933B2 (en) | Systems and methods for editing, recalling, and deleting messages | |
| CN1801810A (zh) | 一种会话初始化协议消息体内容处理方法及网络 | |
| CN101053231A (zh) | 负载控制信息的基于消息的传递 | |
| CN101043701A (zh) | 一种ip多媒体子系统为移动电路域用户提供注册和呼叫接续的方法及其系统 | |
| CN1852431A (zh) | 实现实时视频信息共享的系统及方法 | |
| CN100343835C (zh) | 信息处理方法和设备 | |
| CN1623308A (zh) | 用于强制实施旨在为多流和多媒体应用提供QoS支持的端到端协商协议的不同阶段的模型 | |
| CN1504059A (zh) | 在现有的通信系统中参与小组通信服务的方法和设备 | |
| CN1579072A (zh) | 一种多媒体通信的数据结构、方法和系统 | |
| CN1262836A (zh) | 一种通信系统体系结构 | |
| CN101053233A (zh) | 用于控制通信网络中移动性的方法和系统，及其相关网络和计算机程序产品 | |
| CN1599376A (zh) | 网络媒体话机终端的应用和通信方法 | |
| CN1893427A (zh) | 一种进行业务支持能力协商的方法 | |
| CN1801231A (zh) | 紧急通报系统和紧急通报方法 | |
| CN1889771A (zh) | 一种hlr以及将传统移动终端接入ims域的方法及系统 | |
| CN101076198A (zh) | 多媒体彩像业务实现方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
| WD01 | Invention patent application deemed withdrawn after publication |