CN101151869A - 因特网协议多媒体子系统的鉴权方法 - Google Patents

因特网协议多媒体子系统的鉴权方法 Download PDF

Info

Publication number
CN101151869A
CN101151869A CN200680010294.XA CN200680010294A CN101151869A CN 101151869 A CN101151869 A CN 101151869A CN 200680010294 A CN200680010294 A CN 200680010294A CN 101151869 A CN101151869 A CN 101151869A
Authority
CN
China
Prior art keywords
cscf
authentication
message
hss
upsf
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.)
Granted
Application number
CN200680010294.XA
Other languages
English (en)
Other versions
CN101151869B (zh
Inventor
严军
王樱
何承东
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority claimed from CNB2005100932168A external-priority patent/CN100442926C/zh
Priority claimed from CNB200510109162XA external-priority patent/CN100395976C/zh
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN200680010294.XA priority Critical patent/CN101151869B/zh
Publication of CN101151869A publication Critical patent/CN101151869A/zh
Application granted granted Critical
Publication of CN101151869B publication Critical patent/CN101151869B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H04L63/205—Network architectures or network communication protocols for network security for managing network security; network security policies in general involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Communication Control (AREA)

Abstract

本发明公开了一种IP多媒体子系统的鉴权方法，包括：P－CSCF接收到UE发送来的注册报文后，向所确定的CLF查询UE在接入网中的附着信息得到查询结果，并将携带所述查询结果的注册报文发送给I－CSCF；I－CSCF将所述注册报文转发给UPSF/HSS告知的S－CSCF；S－CSCF根据从UPSF/HSS获取的鉴权方式，对UE进行鉴权得到鉴权结果，并将所述鉴权结果发送给UE。本发明由业务层的UPSF/HSS决定用户的鉴权方式，S－CSCF完成鉴权过程，更具合理性。本发明还进一步提供了IMS业务层鉴权和接入层鉴权绑定的鉴权方式和其他鉴权方式相组合的鉴权方法，确保用户在IMS业务层鉴权和接入层鉴权绑定的鉴权方式失败的情况下也能够正确地进行鉴权。

Description

因特网协议多媒体子系统的鉴权方法
技术领域
本发明涉及因特网协议 ( Internet Protocol, IP ) 多媒体业务子系统 ( IP Multimedia Core Network Subsystem, IMS )， 特别是 IP多媒体业务 子系统的鉴权方法。 发明背景
在固定下一代（NGN ) 网络以及移动网络中， 通常可以将网络分为 接入网络和业务网络。 用户通过接入网络运营商的接入网络接入到 IP 网络上， 然后再通过一个或多个业务网络运营商的业务网络享用不同的 业务， 例如语音、 视频、 流媒体等业务。
如果接入网络和业务网络不属于同一个运营商时， 接入网络对用户 的鉴权和业务网络对用户的鉴权是相互独立的。 在此种情况下， 一个用 户若要享用某种业务， 通常需要两次鉴权， 一次为接入层的鉴权， 在通 过接入层的鉴权后用户能够接入到 NGN网络； 另一次为业务层的鉴权， 在通过业务层鉴权后用户可以享用该业务网络提供的业务。
如果业务网络和接入网络属于同一个运营商时， 或者业务网络运营 商和接入网络运营商之间存在某种合作关系时， 在某些组网情况下， 业 务网络运营商可以将业务层的鉴权同接入层的鉴权绑定， 即在用户通过 接入层養权后， 就认为该用户是安全的， 不再需要进行业务层的鉴权。
在现有的 IP 多媒体业务子网络 （IP Multimedia Core Network Subsystem, IMS )接入层中 ,—般使用基于 IMS认证的密钥协商（ AKA ) 流程实现 IMS业务层对用户的鉴权。
参考图 1 , AKA流程包括以下步骤： 步骤 slOl , 用户终端 （User Equipment, UE ) 向代理呼叫会话控制 功能实体 ( Proxy-Call Session Control Function, P-CSCF )发送注册 4艮文 Register。
步骤 si 02, P-CSCF作为会话发起协议（ Session Initial Protocol, SIP ) 代理服务器， 将 UE的注册报文 Register转发给询问呼叫会话控制功能 实体 ( Interrogaing-Call Session Control Function, I-CSCF )„
步骤 sl03， I-CSCF跟归属用户服务器（ Home Subscribe Server, HSS ) 之间通过 Cx-Selection-Info消息选择相应的服务呼叫会话控制功能实体 ( Service-Call Session Control Function, S-CSCF ), 即 I-CSCF向 HSS发 出请求，查找 HSS中的用户属性来确定由哪个 S-CSCF处理该注册报文。
步骤 sl04， I-CSCF将 UE的注册报文 Register转发给步骤 sl03中所 确定 S-CSCF。
步骤 sl05， S-CSCF与 HSS之间通过 Cx-Put消息， 更新 HSS上的 S-CSCF指示信息， 告知 HSS该用户后续的处理在本 S-CSCF进行。
步骤 sl06, S-CSCF向 HSS发送 AV-Req消息， 请求该用户的鉴权 向量。
步骤 sl07， HSS向 S-CSCF发送 AV-Req-Resp消息， 将该用户的鉴 权向量， 发送给 S-CSCF。
步骤 sl08， S-CSCF根据在步骤 sl07中获得的鉴权向量以及 UE的 注册报文， 判断出该用户需要进行鉴权， 然后向 I-CSCF 发送 4xx Auth— Challenge挑战消息， 表示需要进行鉴权， 并携带有与鉴权相关的 信息。 其中 4xx表示一类错误， XX代表从 00-99的一个数字。
步骤 sl09， I-CSCF将所述 4xx Auth— Challenge消息发送给 P-CSCF。 步骤 sllO, P-CSCF将所述 4xx Auth— Challenge消息发送给 UE。 步骤 si ll , UE接收到所述 4xx Auth— Challenge 消息后， 重新向 P-CSCF发送新的注册报文 Register, 并且该 Register携带有认证参数。 步骤 sll2, P-CSCF将 UE的注册报文 Register发送给 I-CSCF。 步骤 si 13, I-CSCF接收到所述注册报文 Register后， 与 HSS之间 通过 Cx-Quer 确定该 UE注册报文给哪个 S-CSCF处理， 即 I-CSCF向 HSS查询用户注册报文给哪个 S-CSCF处理， HSS根据保存的 S-CSCF 指示信息告知 I-CSCF处理该用户注册报文的 S-CSCF。
步骤 sll4, I-CSCF将注册报文 Register转发给步骤 sll3 确定的 S-CSCFc
步骤 sll5, S-CSCF与 HSS之间通过 Cx-Put消息， 更新 HSS上的 S-CSCF指示信息， 告知 HSS该用户后续的处理在本 S-CSCF。
步驟 sll6, S-CSCF与 HSS通过 Cx-Pull消息获取用户的签约数据 信息。
步骤 sll7， S-CSCF根据所述用户的签约数据信息和 UE注册报文 Register中的认证参数， 进行鉴权。 如果鉴权成功， S-CSCF向 I-CSCF 发送 2xx Auth_OK消息，表示注册成功，其中 2xx表示成功相应的消息， XX为 00〜99的一个数字。 如果鉴权失败， 贝 "J S-CSCF向 I-CSCF发送表 示鉴权失败的消息。
步骤 sll8, 如果鉴权成功， I-CSCF将上述 2xx Auth—OK消息发送 给 P-CSCF。 如果鉴权失败， 则 I-CSCF将上述表示鉴权失败的消息发送 给 P-CSCF。
步驟 sll9， 如果鉴权成功， P-CSCF将上述 2xx Auth—OK消息发送 给 UE。 如果鉴权失败， 则 P-CSCF将上述表示鉴权失败的消息发送给 UE。
法国电信在电信和互联网融合业务以及高级网络协议六次会议中间 会议 ( TISPAN 6bis )上提出了一种实现 IMS业务层鉴权和接入层鉴权 绑定（NBA ) 的方案。 该方案在网络附着子系统（Network Attach Sub System, NASS )中的连接位置功能实体 ( Connection Location Function, CLF )上保存有 UE的 IP地址与接入用户标识（ subscription-id )的对应 关系、 以及该 UE业务层鉴权和接入层鉴权绑定的绑定标识， 其中用户 每个连接都有一个接入用户标识。
参考图 2， 该方案的大致流程如下：
步骤 s201 , UE向 P-CSCF发送注册报文 Register。
步骤 s202, P-CSCF根据注册报文的源 IP地址向 CLF查询 UE的附 着信息， 附着信息中有 UE的接入用户标识， 及业务层鉴权与接入层绑 定的指示。
步骤 s203 , P-CSCF比较 UE的接入用户标识和注册报文中鉴权头域 中的私有用户标识， 如果两者一致， 则说明 IMS业务层鉴权成功, 执行 步驟 s205及其后续步骤 s,否则鉴权失败执行步骤 s204向 UE发送鉴权 失败消息 403 Forbidden。
步骤 s205, P-CSCF继续将 UE的注册 4艮文 Register转发给 I-CSCF, 报文中携带鉴权是否成功指示。
步骤 s206, 1-CSCF跟 HSS之间通过 Cx-Selection-Info消息选择相应 的 S-CSCF, 即 I-CSCF向 HSS发出请求， 查找 HSS中的用户属性来确 定由哪个 S-CSCF处理该注册报文。
步骤 s207, I-CSCF将注册报文 Register发送给步骤 s206中所确定 S-CSCF。
步骤 s208， S-CSCF确认用户注册成功后， 没有再向 HSS请求用户 的鉴权向量， 而是直接和 HSS之间通过 Cx-Put消息， 更新 HSS上的 S-CSCF指示信息， 告知 HSS该用户后续的处理在本 S-CSCF进行， 以 及和 HSS之间通过 Cx-Pull消息下载用户的签约数据。 步骤 s209, S-CSCF向 I-CSCF回 2xx消息， 表示鉴权成功。
步骤 s210, I-CSCF将所迷 2xx鉴权成功消息发送给 P-CSCF。
步骤 s211 , P-CSCF将所述 2xx鉴权成功消息发送给 UE。
上述技术方案中， 要求注册消息 Register中携带的私有用户标识与 用户的接入用户标识一致， 即业务层的私有用户标识和接入层的用户标 识是同一个标识， 但是很多情况下， 业务网络运营商和接入网络运营商 并不是同一个运营商， 强制要求他们使用相同的标识会限制网络应用的 灵活性。 在网络接入层的附着子系统中指示业务层鉴权和接入层绑定， 也是不合理的， 应该由业务层中相关设备（如 HSS )来指示， 接入层网 络只负责提供相关信息。 由 P-CSCF来完成鉴权工作， 也是不合理的， 合理的方式应是归属地的 S-CSCF 来完成业务层的鉴权工作， P-CSCF 同样只需要负责提供鉴权相关的信息。
即便如此， 某些时候由于用户状态的变化， 例如在不同的位置采用 不同类型的终端，此时会导致采用缺省设置的 IP多媒体子系统和接入层 绑定的鉴权方式鉴权失败， 争低了服务的质量， 所以还需要根据 HSS中 预先设置的鉴权方式对用户采用第二种鉴权方式再次进行鉴权， 但是现 有技术没有提供相应的方案。 发明内容
有鉴于此， 本发明的目的在于提出一种由业务层决定用户鉴权方式 的 IMS的鉴权方法。 本发明进一步的目的是， 避免攻击者 UE通过不可 信任的 P-CSCF透传伪造的注册报文进行攻击， 并且保证鉴权方法的后 向兼容性和可维护性。
根据上述目的， 本发明提供了一种 IMS的鉴权方法， 该方法包括以 下步骤： A. P-CSCF接收到 UE发送来的注册报文后， 根据所述注册报文 中的信息以及预先设置的注册报文中的信息与 CLF 的对应关系确定 CLF;
B. P-CSCF向所述 CLF查询 UE在接入网中的附着信息得到查询结 杲， 并将携带所述查询结果的注册报文发送给 I-CSCF;
C. I-CSCF将所述注册报文转发给 UPSF/ HSS告知的 S-CSCF;
D. S-CSCF根据从 UPSF/HSS获取的鉴权方式， 对 UE进行鉴权得 到鉴权结果， 并将所述鉴权结果发送给 UE。
在上述技术方案中，步骤 D中所述鉴权方式为 IMS业务层鉴权和接 入层鉴权绑定（NBA )。
步骤 D之前进一步包括： S-CSCF向 UPSF/HSS请求所述 UE的鉴 权数据； UPSF/HSS根据预先设置的用户鉴权签约数据发现该用户的鉴 权方式是 NBA, 并向 S-CSCF发送包括所述鉴权数据的消息。
步骤 A中所述注册报文中的信息为接入运营商标识或所述注册报文 的源 IP地址。
所述注册报文包括接入用户标识；预先在 CLF中保存了与所述接入 用户标识对应的 UE在接入网中的附着信息。 步骤 B中所述 P-CSCF向 所述 CLF查询 UE在接入网中的附着信息得到查询结果的步驟包括： P-CSCF根据所述接入用户标识向所述 CLF查询 UE在接入网中的附着 信息； 在 CLF中存在与所述接入用户标识对应的 IP地址信息的附着信 息时， CLF向 P-CSCF返回包括所述 IP地址信息的查询结果， 否则向 P-CSCF返回查询失败的查询结果。
步骤 B进一步包括 P-CSCF将所收到的注册报文的源 IP地址发送给 I-CSCF的步骤。 步驟 C进一步包括 I-CSCF将所述注册报文源 IP地址 转发给所述 S-CSCF的步骤。 步骤 D中所述对 UE进行鉴权得到鉴权结 果的步骤包括： 在所述查询结果包括 IP地址信息时， S-CSCF比较所述 P-CSCF所收到的注册报文源 IP源地址与所述查询结果中的 IP地址信 息， 如果一致， 则得到鉴权成功的鉴权结果， 否则得到鉴权失败的鉴权 结果； 在所述查询结果为查询失败信息时， S-CSCF得到鉴权失败的鉴 权结果。
预先在 CLF中保存了与注册报文源 IP地址对应的 UE在接入网中的 接入用户关联信息。步骤 B中所述 P-CSCF向所述 CLF查询 UE在接入 网中的接入用户关联信息得到查询结果的步骤包括： P-CSCF根据所述 注册报文源 IP地址向所述 CLF查询 UE在接入网中的接入用户关联信 息； 在 CLF中存在与所述注册报文源 IP地址对应的接入用户关联信息 时， CLF向 P-CSCF返回包括所述接入用户关联信息的查询结果， 否则 向 P-CSCF返回查询失败的查询结果。
步骤 D中所述对 UE进行鉴权得到鉴权结果之前进一步包括 S-CSCF 从 UPSF/HSS获得预先保存在 UPSF/HSS的所述 UE的接入用户关联信 息的步骤。 步骤 D中所述对 UE进行鉴权得到鉴权结果的步骤包括： 在 所述查询结果包括接入用户关联信息时， S-CSCF比较所述从 UPSF/HSS 获得的所述 UE的接入用户关联信息与所述查询结果中的接入用户关联 信息， 如果一致， 则得到鉴权成功的鉴权结果， 否则得到鉴权失败的鉴 权结果； 在所述查询结果为查询失败信息时， S-CSCF得到鉴权失败的 鉴权结果。
所述接入用户关联信息为接入用户标识或位置信息。
在上述技术方案中， 所述步骤 D包括： S-CSCF保存从 UPSF/HSS 获取的 IMS 业务层鉴权和接入层鉴权绑定的鉴权方式以及相应的養权 数据， 以及第二鉴权方式以及相应的鉴权数据， S-CSCF首先采用 IMS 业务层鉴权和接入层鉴权绑定的方式， 对 UE进行鉴权得到鉴权结果， 在鉴权结果为成功时， 将该鉴权结果发送给 UE; 在鉴权结果为失败时， 再采用第二鉴权方式对 UE进行鉴权得到鉴权结果 , 并将该鉴权结果发 送给 UE。
步骤 D中所述从 UPSF/HSS获取的鉴权方式为：先采用 IMS业务层 鉴权和接入层鉴权绑定的鉴权方式，在 IMS业务层鉴权和接入层鉴权绑 定的鉴权方式进行鉴权失败之后再采用第二鉴权方式。
可选地， 所述第二鉴权方式为 HTTP DIGEST方式。
步骤 D中所述采用 HTTP DIGEST鉴权方式对 UE进行鉴权得到鉴 权结果并将该鉴权结果发送给 UE的步骤包括： Dll. S-CSCF向 UE发 送包括所述 HTTP DIGEST鉴权方式的挑战消息; D12. UE接收到所述 包括 HTTP DIGEST鉴权方式的挑战消息后， 向 S-CSCF发送包含认证 参数的注册消息； D13. S-CSCF执行 HTTP DIGEST的鉴权过程， 当鉴 权成功时， 向 UE发送表示鉴权成功的消息； 当鉴权失败时， 向 UE发 送表示鉴权失败的消息。
可选地， 所述第二鉴权方式为 IMS AKA方式。
步驟 D中所述采用 IMS AKA鉴权方式对 UE进行鉴权得到鉴权结 果并将该鉴权结果发送给 UE的步驟包括： D21. S-CSCF向 UE发送包 括所述 IMS AKA鉴权方式的挑战消息； D22. UE接收到所述包括 IMS AKA鉴权方式的挑战消息后，向 S-CSCF发送包括认证参数的注册消息； D23. S-CSCF执行 IMS AKA的鉴权过程， 当鉴权成功时， 向 UE发送 表示鉴权成功的消息； 当鉴权失败时， 向 UE发送表示鉴权失败的消息。
可选地， 步骤 A之前进一步包括： Al. UE向 S-CSCF发送注册报 文； A2. S-CSCF向 UPSF/HSS请求所述 UE的鉴权数据； A3. UPSF/HSS 根据预先设置的用户鉴权签约数据将鉴权方式发送给 S -C S CF； A4. S-CSCF向 UE发送包括所述鉴权方式的消息； A5. UE接收到所述 包括鉴权方式的消息后， 向 P-CSCF发送新的注册报文； 步骤 A、 步骤 B及步骤 C中所述的注册报文为所述新的注册报文。
从上述方案中可以看出， 本发明通过接入用户标识、 私有用户标识 或注册报文源 IP地址查询 CLF中的附着信息， 并且由 UPSF/HSS决定 用户的鉴权方式， 以及由 S-CSCF进行鉴权成功与否的判断。 与现有技 术不同， 本发明与现有技术相比， 由业务层的 UPSF/HSS决定用户的鉴 权方式， 由 S-CSCF完成鉴权过程， 更具有合理性。 并且， 本发明根据 接入运营商标识定位 CLF,并采用接入用户标识向 CLF查询用户附着信 息， 此时不要求业务层用户标识和接入用户标识一定相同。 同时考虑到 实际组网的情况， 简化方案， 本方案同样支持当业务运营商和接入运营 商为同一个运营商且 IP地址得到较好的规划、业务层私有用户标识和接 入用户标识为同一个时， 可以用注册艮文源 IP地址来定位 CLF, 用业 务层私有用户标识或注册^ ^艮文源 IP地址去 CLF查询用户在接入网络的 附着信息。 并且， 在 S-CSCF鉴权的时候， 通过比较从 CLF查询得到的 IP地址信息与 P-CSCF所接收的注册报文的源 IP地址、或者比较从 CLF 查询得到的接入用户关联信息与从 UPSF/HSS获得的绑定的接入用户关 联信息， 在两者一致的时候得到鉴权成功的结果， 在两者不一致的时候 得到鉴权失败的结果。 因此本方案与现有技术相比更具有通用性和灵活 性， 在方案上符合业务层鉴权的原则， 实现方式更合理、 更具有逻辑性， 另外本发明的技术方案对现有 IMS AKA流程的改动较小， 流程基本一 致， 只是认证参数的变化， 和现有 IMS AKA的流程更容易融合， 具有 容易实现的优点。
另外， 某些时候根据 UPSF HSS中预先配置的鉴权方式， 本发明在 上述 IMS业务层鉴权和接入层鉴权绑定的方式鉴权失败以后，还可能进 一步采用超文本传输协议摘要 ( HTTP DIGEST )方式或 IMS AKA方式 进行鉴权， 从而向用户提供多种组合的鉴权方式。 附图简要说明
图 1为 AKA答权机制的流程示意图；
图 2为现有技术的流程示意图；
图 3a和图 3b为本发明第一实施例的流程示意图；
图 4a和图 4b为本发明第二实施例的流程示意图；
图 5a和图 5b为本发明第三实施例的流程示意图；
图 6a和图 6b为本发明第四实施例的流程示意图；
图 7a和图 7b为本发明第五实施例的流程示意图；
图 8为 HTTP DIGEST鉴权机制的流程示意图；
图 9a和图 9b为本发明第六实施例的流程示意图；
图 10a和图 10b为本发明第七实施例的流程示意图；
图 11a和图 lib为本发明第八实施例的流程示意图；
图 12a和图 12b为本发明第九实施例的流程示意图。 实施本发明的方式
为使本发明的目的、 技术方案和优点更加清楚， 以下举实施例对本 发明进一步详细说明。
本发明的第一实施例以 AKA流程为基础， 给出了一种 IMS业务层 鉴权和接入层鉴权绑定的方法。 第一实施例中， 预先在用户签约服务功 能实体（UPSF ) /HSS保存用户的鉴权签约数据， 鉴权签约数据表明该 用户的鉴权方式是否为业务层鉴权与接入层鉴权绑定。
参考图 3a和图 3b， 第一实施例的流程如下：
步驟 101， UE向 P-CSCF发送注册报文 Register。 步骤 102 , P-CSCF将 UE的注册报文 Register转发给 I-CSCF。
步骤 103， I-CSCF跟 UPSF HSS之间通过 Cx-Sdection-Info消息选 择相应的 S-CSCF, 即 I-CSCF向 UPSF/HSS发出请求， 查找 UPSF/HSS 中的用户属性来确定由哪个 S-CSCF处理该注册报文。
步骤 104, I-CSCF将 UE的注册 4艮文 Register转发给步驟 103中所 确定 S-CSCF。
步骤 105 , S-CSCF 与 UPSF/HSS 之间通过 Cx-Put 消息， 更新 UPSF/HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后续的处理 在本 S-CSCF进行。
步骤 106， S-CSCF向 UPSF/HSS发送 AV-Req消息， 请求该用户的 鉴权数据。
步骤 107, UPSF/HSS检查用户的鉴权签约数据，发现该用户的鉴权 方式是 IMS业务层鉴权和业务层绑定。
步驟 108， UPSF/HSS向 S-CSCF发送 AV-Req-Resp消息， 与现有技 术中发送的鉴权数据不同， 本步骤里将该用户的鉴权方式信息和鉴权数 据发送给 S-CSCF。
步骤 109， S-CSCF根据在步驟 108中获得的鉴权方式信息， 得知该 用户的鉴权方式是业务层鉴权和接入层鉴权绑定, 然后向 I-CSCF发送 4xx Auth— Challenge消息， 并在消息的鉴权头域中表明鉴权方式是业务 层鉴权和接入层鉴权绑定， 即携带鉴权方式指示信息。
步骤 110 , I-CSCF 将所述携带鉴权方式指示信息的 4xx Auth— Challenge消息发送给 P-CSCF。
步驟 111 , P-CSCF接收到所述 4xxAuth_Challenge 消息后， 发现该 消息的 "WWW- Authenticate头中算法 Algorithm参数表示 IMS业务层和 接入层绑定鉴权方式， 因此不需要建立和 UE之间的安全联盟。 P-CSCF 将所述携带鉴权方式指示信息的 4xxAuth— Challenge消息发送给 UE,其 中不携带 Security-Server头。
步骤 112， UE接收到所述 4xx Auth_Challenge消息后， 发现该消息 的 WWW-Authenticate头中 Algorithm参数表示 IMS业务层和接入层绑 定鉴权方式， 因此也不需要建立和 P-CSCF之间的安全联盟。 UE重新向 P-CSCF发送注册报文 Register,该报文携带有接入运营商标识及接入用 户标识。
步骤 113， P-CSCF根据注册报文中的运营商标识以及预先设置的运 营商标识与 CLF之间的对应关系确定 CLF。
步骤 114, P-CSCF根据注册报文中的接入用户标识， 在上面确定的 CLF中查询用户在接入层的附着信息。 与现有技术不同的是， CLF中预 先保存了与接入用户标识对应的附着信息的数据记录， 所迷附着信息包 括 IP地址信息、位置信息等，但不包括现有技术的绑定标识。如果 CLF 中没有该接入用户标识的数据记录， CLF会返回查询失败。
步骤 115， P-CSCF将携带上一步骤中查询结果的注册报文 Register 以及 P-CSCF所接收的该 Register源 IP地址发送给 I-CSCF。如果前面的 查询成功， 则将查询得到的附着信息发送给 I-CSCF; 如果查询失败， 则 向 I-CSCF上 4艮查询失败信息。
步驟 116， I-CSCF与 UPSF/HSS之间通过 Cx-Query确定该 UE注册 报文给哪个 S-CSCF处理，即 I-CSCF向 UPSF/HSS查询该注册艮文给哪 个 S-CSCF处理， UPSF/HSS根据保存的 S-CSCF指示信息告知 I-CSCF 处理该注册报文的 S-CSCF。
步骤 117， I-CSCF将包含查询结果的注册报文 Register以及 P-CSCF 所接收的该 Register源 IP地址转发给步骤 116确定的 S-CSCF。 所述查 询结果， 在查询成功时为查询得到的附着信息， 在查询失败时为上 的 查询失败信息。
步骤 118， 在查询结果为查询得到的附着信息时， S-CSCF 判断 P-CSCF收到的注册报文 Register的源 IP地址与所述从 CLF查询得到的 附着信息中的 IP地址信息是否一致， 如果一致， 则说明鉴权成功， 执行 步骤 119及其后续流程， 即向 UE发送鉴权成功的消息； 如果不一致， 则说明鉴权失败， 执行步骤 131及其后续步骤， 即向 UE发送鉴权失败 的消息。
在查询结果为上报的查询失败信息时， 也说明婆权失败， 执行步骤 131及其后续步骤， 即向 UE发送鉴权失败的消息。
步驟 119， S-CSCF 与 UPSF/HSS 之间通过 Cx-Put 消息， 更新 UPSF/HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后续的处理 在本 S-CSCF进行。
步骤 120, S-CSCF与 UPSF/HSS通过 Cx-Pull消息获取用户的签约 数据信息。
步骤 121， S-CSCF向 I-CSCF发送 2xxAuth— OK消息， 表示鉴权成 功。
步骤 122, I-CSCF将上述 2xx Auth_OK消息发送给 P-CSCF。
步骤 123， P-CSCF将上述 2xx Auth— OK消息发送给 UE。
如图 3b所示的步驟 131 , S-CSCF与 UPSF/HSS之间通过 Cx-Put消 息， 更新 UPSF/HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后 续的处理在本 S-CSCF进行。
步骤 132， S-CSCF与 UPSF/HSS通过 Cx-Pull消息获取用户的签约 数据信息。
步骤 133 , S-CSCF向 I-CSCF发送鉴权失败的消息，表示鉴权失败。 步驟 134, I-CSCF将上述鉴权失败的消息发送给 P-CSCF。 步骤 135 , P-CSCF将上述鉴权失败的消息发送给 UE。 当接入网络运营商和业务网络运营商是同一个运营商时， 由于接入 用户标识和私有用户标识是相同的， NASS 中不会下发接入运营商标识 和接入用户标识给 UE, 可以采用如图 4a和图 4b所示的第二实施例的 方法， 第二实施例为第一实施例的简化方式， 在第二实施例中， 通过 Register的源 IP地址识別接入运营商及 CLF,并且根据 IMS业务层的私 有用户标识在 CLF查询 UE在接入层的附着信息。 与第一实施例一样， 预先在 UPSF/HSS保存用户的鉴权签约数据， 鉴权签约数据表明该用户 的鉴权方式是否为业务层鉴权与接入层鉴权绑定。
参照图 4a和图 4b, 第二实施例包括以下步骤：
其中， 步骤 201至步骤 211与第一实施例中的步驟 101至步骤 111 相同。
步骤 201 , UE向 P-CSCF发送注册报文 Register。
步驟 202, P-CSCF将 UE的注册报文 Register转发给 I-CSCF。
步骤 203, I-CSCF跟 UPSF HSS之间通过 Cx-Selection-Info消息选 择相应的 S-CSCF, 即 I-CSCF向 UPSF/HSS发出请求， 查找 UPSF/HSS 中的用户属性来确定由哪个 S-CSCF处理该注册 4艮文。
步骤 204, I-CSCF将 UE的注册报文 Register转发给步骤 203中所 确定 S-CSCF。
步骤 205 , S-CSCF 与 UPSF/HSS 之间通过 Cx-Put 消息， 更新 UPSF/HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后续的处理 在本 S-CSCF进行。
步骤 206， S-CSCF向 UPSF/HSS发送 AV-Req消息， 请求该用户的 鉴权数据。 步驟 207, UPSF/HSS检查用户的鉴权签约数据，发现该用户的鉴权 方式是 IMS业务层鉴权和业务层绑定。
步骤 208, UPSF/HSS向 S-CSCF发送 AV-Req-Resp消息， 与现有技 术中发送的鉴权数据不同， 本步驟里将该用户的鉴权方式信息和鉴权数 据发送给 S-CSCF。
步骤 209, S-CSCF根据在步骤 208中获得的鉴权方式信息， 得知该 用户的鉴权方式是业务层鉴权和接入层鉴权绑定， 然后向 I-CSCF发送 4xx Auth— Challenge消息， 并在消息的鉴权头域中表明鉴权方式是业务 层鉴权和接入层鉴权绑定， 即携带鉴权方式指示信息。
步骤 210， I-CSCF 将所述携带鉴权方式指示信息的 4xx Auth— Challenge消息发送给 P-CSCF。
步骤 211， P-CSCF接收到所述 4xx Auth— Challenge 消息后， 发现该 消息的 WWW- Authenticate头中发现该消息的 WWW- Authenticate头中 Algorithm 参数表示 IMS业务层和接入层绑定鉴权方式, 因此不需要建 立和 UE之间的安全联盟。 P-CSCF将所述携带鉴权方式指示信息的 4xx Auth— Challenge消息发送给 UE， 其中不携带 Security-Server头。
步骤 212, UE接收到所述 4xx Auth— Challenge消息后， 发现该消息 的 WWW-Authenticate头中 Algorithm参数表示 IMS业务层和接入层绑 定鉴权方式， 因此也不需要建立和 P-CSCF之间的安全联盟。 UE重新向 P-CSCF发送注册报文 Register, 与第一实施例不同的是， 该报文不需要 携带接入运营商标识及接入用户标识， 而是采用鉴权头域中携带现有技 术中所述的私有用户标识 , 该标识在现有的 IMS AKA流程中已有。
步骤 213 , P-CSCF根据注册拫文的源 IP地址以及预先设置的源 IP 地址与 CLF之间的对应关系确定 CLF。
步骤 214, P-CSCF根据注册拫文鉴权头域中的私有用户标识， 在上 面确定的 CLF中查询用户在接入层的附着信息。 CLF中预先保存了与私 有用户标识对应的附着信息的数据记录， 所述附着信息包括 IP地址信 息、位置信息等， 但不包括现有技术中的绑定标识。 如果 CLF中没有该 私有用户标识的数据记录， CLF会返回查询失败。
以下的步骤 215至步骤 223与第一实施例中的步骤 115至步骤 123 相同。
步骤 215， P-CSCF将携带上一步骤中查询结果的注册报文 Register 以及 P-CSCF所接收的该 Register源 IP地址发送给 I-CSCF。如果前面的 查询成功， 则将查询得到的附着信息发送给 I-CSCF; 如果查询失败， 则 向 I-CSCF上报查询失败信息。
步驟 216, 1-CSCF与 UPSF/HSS之间通过 Cx-Query确定该 UE注册 艮文给哪个 S-CSCF处理，即 I-CSCF向 UPSF/HSS查询该注册报文给哪 个 S-CSCF处理， UPSF/HSS根据保存的 S-CSCF指示信息告知 I-CSCF 处理该注册报文的 S-CSCF。
步骤 217, 1-CSCF将包含查询结果的注册报文 Register以及 P-CSCF 所接收的 Register源 IP地址转发给步驟 216确定的 S-CSCF。 所述查询 结果， 在查询成功时为查询得到的附着信息， 在查询失败时为上报的查 询失败信息。
步骤 218 , 在查询结果为查询得到的附着信息时， S-CSCF 判断 P-CSCF收到的注册报文 Register的源 IP地址与所述从 CLF查询得到的 附着信息中的 IP地址信息是否一致， 如果一致， 则说明鉴权成功， 执行 步骤 219及其后续流程， 即向 ΌΈ发送鉴权成功的消息； 如果不一致， 则说明鉴权失败， 执行步骤 231及其后续步骤， 即向 UE发送鉴权失败 的消息。
在查询结果为上报的查询失败信息时， 也说明鉴权失败， 执行步骤 231及其后续步骤， 即向 UE发送鉴权失败的消息。
步骤 219 , S-CSCF 与 UPSF/HSS 之间通过 Cx-Put 消息， 更新 UPSF/HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后续的处理 在本 S-CSCF进行。
步骤 220， S-CSCF与 UPSF/HSS通过 Cx-Pull消息获取用户的签约 数据信息。
步骤 221 , S-CSCF向 I-CSCF发送 2xxAuth— OK消息， 表示鉴权成 功。
步驟 222， I-CSCF将上述 2xx Auth— OK消息发送给 P-CSCF。
步驟 223， P-CSCF将上述 2xx Auth—OK消息发送给 UE。
如图 4b所示的步骤 231 , S-CSCF与 UPSF/HSS之间通过 Cx-Put消 息， 更新 UPSF/HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后 续的处理在本 S-CSCF进行。
步骤 232, S-CSCF与 UPSF/HSS通过 Cx-Pull消息获取用户的签约 数据信息。
步骤 233， S-CSCF向 I-CSCF发送鉴权失败的消息，表示鉴权失败。 步骤 234 , I-CSCF将上述鉴权失败的消息发送给 P-CSCF。
步骤 235 , P-CSCF将上述鉴权失败的消息发送给 UEo 在第一实施例和第二实施例的方法中， UE在得到鉴权方式为业务层 鉴权与接入层鉴权绑定后， 才发送携带运营商标识和接入用户标识的注 册报文。 在本发明的第三实施例中， UE—开始就发送携带运营商标识 和接入用户标识的注册报文。 与第一实施例、 第二实施例一样， 第三实 施例中预先在 UPSF/HSS保存用户的鉴权签约数据， 鉴权签约数据表明 该用户的鉴权方式是否为业务层鉴权与接入层鉴权绑定。 参考图 5a和图 5b, 第三实施例的流程如下：
步骤 301 , UE向 P-CSCF发送注册报文 Register, 该 文携带有接 入运营商标识及接入用户标识。
步骤 302, P-CSCF根据注册报文中的接入运营商标识以及预先设置 的接入运营商标识与 CLF之间的对应关系确定 CLF。
步骤 303 , P-CSCF根据注册报文中的接入用户标识， 在上面确定的 CLF中查询用户在接入层的附着信息。 CLF中预先保存了与私有用户标 识对应的附着信息的数据记录，所述附着信息包括 IP地址信息、位置信 息等，但不包括现有技术中的绑定标识。如果 CLF中没有该接入用户标 识的数据记录， CLF会返回查询失败。
步骤 304, P-CSCF将携带上一步骤中查询结果的注册 Register 以及 P-CSCF所接收的该注册报文源 IP地址发送给 I-CSCF。 如果前面 的查询成功， 则将查询得到的附着信息发送给 I-CSCF; 如果查询失败， 则向 I-CSCF上艮查询失败信息。
步骤 305, I-CSCF跟 UPSF/HSS之间通过 Cx-Selection-Info消息选 择相应的 S-CSCF, 即 I-CSCF向 UPSF/HSS发出请求， 查找 UPSF/HSS 中的用户属性来确定由哪个 S-CSCF处理该注册^ :艮文。
步骤 306, I-CSCF 将包括上述查询结果的注册报文 Register 以及 P-CSCF所接收的注册报文源 IP地址转发给步骤 305确定的 S-CSCF。 所述查询结果， 在查询成功时为查询得到的附着信息， 在查询失败时为 上报的查询失败信息。
步骤 307 , S-CSCF 与 UPSF/HSS 之间通过 Cx-Put 消息， 更新 UPSF/HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后续的处理 在本 S-CSCF进行。
步骤 308, S-CSCF向 UPSF/HSS发送 AV-Req消息， 请求该用户的 鉴权数据。
步骤 309， UPSF/HSS检查用户的鉴权签约数据，发现该用户的鉴权 方式是 IMS业务层鉴权和业务层绑定。
步骤 310, UPSF/HSS向 S-CSCF发送 AV-Req-Resp消息， 与现有技 术中发送的鉴权数据不同， 本步驟里将该用户的鉴权方式信息和鉴权数 据发送给 S-CSCF。
步骤 311 , 在查询结果为查询得到的附着信息时， S-CSCF 判断 P-CSCF收到的注册艮文 Register的源 IP地址与所述从 CLF查询得到的 附着信息中的 IP地址信息是否一致， 如果一致， 则说明鉴权成功， 执行 步骤 312及其后续流程， 即向 UE发送鉴权成功的消息； 如果不一致， 则说明鉴权失败， 执行步骤 321及其后续步骤， 即向 UE发送鉴权失败 的消息。
在查询结果为上报的查询失败信息时， 也说明鉴权失败， 执行步骤 321及其后续步骤， 即向 UE发送鉴权失败的消息。
步骤 312 , S-CSCF 与 UPSF/HSS 之间通过 Cx-Put 消息， 更新 UPSF/HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后续的处理 在本 S-CSCF进行。
步骤 313, S-CSCF与 UPSF/HSS通过 Cx-Pull消息获取用户的签约 数据信息。
步骤 314, S-CSCF向 I-CSCF发送 2xxAuth— OK消息， 表示鉴权成 功。
步骤 315， I-CSCF将上述 2xx Auth— OK消息发送给 P-CSCF。
步骤 316, P-CSCF接收到上述 2xx Auth— OK消息后，发现以前没有 接收到挑战消息 4xx Auth— Challenge，因此不需要建立和 UE之间的安全 联盟。 P-CSCF将上述 2xxAuth_OK消息发送给 UE。 UE接收到上述 2xx Auth一 OK消息后， 发现以前没有接收到挑战消息 4xx Auth— Challenge, 因此也不需要建立和 P-CSCF之间的安全联盟。
如图 5b所示的步骤 321 , S-CSCF与 UPSF/HSS之间通过 Cx-Put消 息， 更新 UPSF/HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后 续的处理在本 S-CSCF进行。
步骤 322， S-CSCF与 UPSF/HSS通过 Cx-Pull消息获取用户的签约 数据信息。
步骤 323， S-CSCF向 I-CSCF发送鉴权失败的消息，表示鉴权失败。 步骤 324， I-CSCF将上述鉴权失败的消息发送给 P-CSCF。
步骤 325 , P-CSCF将上述鉴权失败的消息发送给 UE。 与第二实施例一样， 当接入网络运营商和业务网络运营商是同一个 运营商时， 由于接入用户标识和私有用户标识是相同的， NASS 中不会 下发接入运营商标识和接入用户标识给 UE, 可以采用如图 6a和图 6b 所示的第四实施例的方法， 第四实施例为第三实施例的简化方式， 在第 四实施例中， 通过 Register的源 IP地址识别接入运营商及 CLF , 并且根 据 IMS业务层的私有用户标识在 CLF查询 UE在接入层的附着信息。与 第一实施例一样， 预先在 UPSF/HSS保存用户的鉴权签约数据， 鉴权签 约数据表明该用户的鉴权方式是否为业务层鉴权与接入层鉴权绑定。
参考图 6a和图 6b, 第四实施例包括以下步骤：
步骤 401， UE向 P-CSCF发送注册报文 Register, 与第三实施例不 同的是， 该报文不需要携带接入运营商标识及接入用户标识， 而是在鉴 权头域中携带现有技术中所述的私有用户标识。
步骤 402, P-CSCF根据注册报文的源 IP地址以及预先设置的源 IP 地址与 CLF之间的对应关系确定 CLF。 步骤 403， P-CSCF根据注册报文鉴权头域中的私有用户标识， 在上 面确定的 CLF中查询用户在接入层的附着信息。 CLF中预先保存了与私 有用户标识对应的附着信息的数据记录， 所述附着信息包括 IP地址信 息、位置信息等， 但不包括现有技术中的绑定标识。 如果 CLF中没有该 私有用户标识的数据记录， CLF会返回查询失败。
以下的步骤 404至步骤 425与第三实施例中的步骤 304至步骤 325 相同。
步骤 404， P-CSCF将携带上一步骤中查询结果的注册报文 Register 以及 P-CSCF所接收的该注册报文源 IP地址发送给 I-CSCF。 如果前面 的查询成功， 则将查询得到的附着信息发送给 I-CSCF; 如果查询失败， 则向 I-CSCF上 4艮查询失败信息。
步骤 405, I-CSCF跟 UPSF/HSS之间通过 Cx-Selection-Info消息选 择相应的 S-CSCF, 即 I-CSCF向 UPSF/HSS发出请求， 查找 UPSF/HSS 中的用户属性来确定由哪个 S-CSCF处理该注册^ =艮文。
步骤 406, I-CSCF将包括上述查询结果的注册报文 Register以及所 述 P-CSCF 所接收的该注册报文源 IP 地址转发给步骤 405 确定的 S-CSCF。 所述查询结果， 在查询成功时为查询得到的附着信息， 在查询 失败时为上^ =艮的查询失败信息。
步驟 407 , S-CSCF 与 UPSF/HSS 之间通过 Cx-Put 消息， 更新 UPSF/HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后续的处理 在本 S-CSCF进行。
步骤 408, S-CSCF向 UPSF/HSS发送 AV-Req消息， 请求该用户的 鉴权数据》 ' · 步骤 409， UPSF/HSS检查用户的鉴权签约数据，发现该用户的鉴权 方式是 IMS业务层鉴权和业务层绑定。 步骤 410, UPSF/HSS向 S-CSCF发送 AV-Req-Resp消息， 与现有技 术中发送的鉴权数据不同， 本步骤里将该用户的鉴权方式信息和鉴权数 据发送给 S-CSCF。
步骤 411 , 在查询结果为查询得到的附着信息时， S-CSCF 判断 P-CSCF收到的注册报文 Register的源 IP地址与所述从 CLF查询得到的 附着信息中的 IP地址信息是否一致， 如果一致， 则说明鉴权成功， 执行 步骤 412及其后续流程， 即向 UE发送鉴权成功的消息； 如果不一致， 则说明鉴权失败， 执行步骤 421及其后续步骤， 即向 UE发送鉴权失败 的消息。
在查询结果为上报的查询失败信息时， 也说明婆权失败， 执行步骤 421及其后续步骤， 即向 UE发送鉴权失败的消息。
步骤 412 , S-CSCF 与 UPSF/HSS 之间通过 Cx-Put 消息， 更新 UPSF/HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后续的处理 在本 S-CSCF进行。
步骤 413 , S-CSCF与 UPSF/HSS通过 Cx-Pull消息获取用户的签约 数据信息。
步骤 414, S-CSCF向 I-CSCF发送 2xxAuth— OK消息， 表示鉴权成 功。
步骤 415, I-CSCF将上述 2xx Auth— OK消息发送给 P-CSCF。
步骤 416, P-CSCF接收到上述 2xxAuth—OK消息后，发现以前没有 接收到挑战消息 4xx Auth— Challenge,因此不需要建立和 UE之间的安全 联盟。 P-CSCF将上述 2xx Auth— OK消息发送给 UE。 UE接收到上述 2xx Auth— OK消息后， 发现以前没有接收到挑战消息 4xx Auth_Challenge, 因此也不需要建立和 P-CSCF之间的安全联盟。
如图 6b所示的步骤 421 , S-CSCF与 UPSF/HSS之间通过 Cx-Put消 息， 更新 HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后续的处 理在本 S-CSCF进行。
步骤 422, S-CSCF与 UPSF/HSS通过 Cx-Pull消息获取用户的签约 数据信息。
步骤 423 , S-CSCF向 I-CSCF发送鉴权失败的消息，表示鉴权失败。 步骤 424, I-CSCF将上述鉴权失败的消息发送给 P-CSCF。
步骤 425 , P-CSCF将上述鉴权失败的消息发送给 UE。 在第一实施例至第四实施例的方法中， S-CSCF通过比较 P-CSCF所 收到的注册报文 Register的源 IP地址与从 CLF查询得到的 IP地址信息 是否一致来进行鉴权， 在本发明的第五实施例中， S-CSCF 通过比较预 先保存在 UPSF/HSS的绑定的接入用户关联信息和从 CLF查询得到的接 入用户关联信息来进行鉴权， 其中所述接入用户关联信息可以是接入用 户标识 ( access user identity )、 位置信息 ( location information )、 IP地址 信息等， 这里以接入用户标识为例说明实现过程。 第五实施例中， 以注 册报文源 IP地址为例说明确定 CLF以及从 CLF查询用户关联信息的过 程， 但是从前面的实施例能够看出， 可以使用其他参数实现这一过程， 这里不再赘述。
参考图 7a和图 7b, 第五实施例的流程如下：
步骤 501 , UE向 P-CSCF发送注册报文 Register,
步骤 502, P-CSCF根据注册报文的源 Π>地址以及预先设置的 IP地 址与 CLF之间的对应关系确定 CLF。
步骤 503 , P-CSCF根据注册报文的源 IP地址， 在上面确定的 CLF 中查询用户的接入用户标识。 CLF中预先保存了与源 IP地址对应的 UE 的附着信息的数据记录。 所述附着信息至少包括接入用户关联信息， 这 里接入用户关联信息为接入用户标识。 如果 CLF中没有该源 IP地址的 数据记录， CLF会返回查询失败。
步骤 504， P-CSCF将携带上一步骤中查询结果的注册 文 Register 发送给 I-CSCF。如果前面的查询成功， 则将查询得到的接入用户标识作 为查询结果发送给 I-CSCF; 如果查询失败， 则将查询失败信息作为查询 结果上报给 I-CSCF。
步骤 505， I-CSCF跟 UPSF/HSS之间通过 Cx-Selection-Info消息选 择相应的 S-CSCF , 即 I-CSCF向 UPSF/HSS发出请求， 查找 UPSF/HSS 中的该 UE的用户属性来确定由哪个 S-CSCF处理该注册报文。
. 步骤 506, I-CSCF将包括上述查询结果的注册报文 Register转发给 步骤 505确定的 S-CSCF。 所述查询结果， 在查询成功时为查询得到的 接入用户标识， 在查询失败时为上报的查询失败信息。
步骤 507 , S-CSCF 与 UPSF/HSS 之间通过 Cx-Put 消息， 更新 UPSF/HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后续的处理 在本 S-CSCF进行。
步骤 508, S-CSCF向 UPSF/HSS发送 AV-Req消息， 请求该用户的 鉴权数据。
步骤 509, UPSF/HSS检查用户的鉴权签约数据，发现该用户的鉴权 方式是 IMS业务层鉴权和业务层绑定。
步骤 510, UPSF/HSS向 S-CSCF发送 AV-Req-Resp消息， 与现有技 术中发送的鉴权数据不同， 本步骤里将该用户的鉴权方式信息以及接入 用户标识下发给 S-CSC
步骤 511 , 在查询结果为查询得到的接入用户标识时， S-CSCF判断 所述从 CLF查询得到的接入用户标识与 UPSF/HSS下发的接入用户标识 是否一致， 如果一致， 则说明鉴权成功， 执行步骤 512及其后续流程， 即向 UE发送鉴权成功的消息； 如果不一致， 则说明鉴权失败， 执行步 骤 521及其后续步骤， 即向 UE发送鉴权失败的消息。
在查询结果为上报的查询失败信息时， 也说明鉴权失败， 执行步骤 521及其后续步骤， 即向 UE发送鉴权失败的消息。
步骤 512 , S-CSCF 与 UPSF HSS 之间通过 Cx-Put 消息， 更新 UPSF/HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后续的处理 在本 S-CSCF进行。
步骤 513 , S-CSCF与 UPSF/HSS通过 Cx-Pull消息获取用户的签约 数据信息。
步骤 514, S-CSCF向 I-CSCF发送 2xxAuth— OK消息， 表示鉴权成 功。
步骤 515, I-CSCF将上述 2xx Auth— OK消息发送给 P-CSCF。
步骤 516, P-CSCF接收到上述 2xx Auth— OK消息后，发现以前没有 接收到挑战消息 4xx Auth__Challenge,因此不需要建立和 UE之间的安全 联盟。 P-CSCF将上述 2xx Auth— OK消息发送给 UE。 UE接收到上述 2xx Auth— OK消息后， 发现以前没有接收到挑战消息 4xx Auth— Challenge, 因此也不需要建立和 P-CSCF之间的安全联盟。
如图 7b所示的步骤 521， S-CSCF与 UPSF/HSS之间通过 Cx-Put消 息， 更新 UPSF/HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后 续的处理在本 S-CSCF进行。
步骤 522， S-CSCF与 UPSF/HSS通过 Cx-Pull消息获取用户的签约 数据信息。
步骤 523, S-CSCF向 I-CSCF发送鉴权失败的消息，表示鉴权失败。 步驟 524, I-CSCF将上述鉴权失败的消息发送给 P-CSCF。
步骤 525 , P-CSCF将上述鉴权失败的消息发送给 UE。 在以上的实施例中， UPSF/HSS仅为同一个用户保存一种鉴权方式， 即 IMS业务层鉴权与接入层鉴权绑定的方式， 在上述各种方案中， 如果 鉴权失败， 将会拒绝用户访问网络， 这将限制某些时候用户在游牧时的 鉴权以及使用网络业务。 上述游牧是指用户在移动时能改变其网络接入 点， 但正在进行的服务会话会完全停止， 需要重新启动。
例如， 用户可能希望在固定的位置使用传统的终端访问网络， 采用 "IMS业务层鉴权和接入层鉴权绑定" 方式来鉴权用户。 当游牧到外地 时， 希望使用其他终端来访问网络。 由于此时用户的位置信息发生了变 化， 如果仍然采用 "IMS业务层鉴权和接入层鉴权绑定" 方式， 则用户 鉴权会失败， 从而影响用户对网络的使用。 因此， 本发明进一步提出了 在采用 IMS业务层鉴权和接入层鉴权绑定的鉴权失败之后,再采用超文 本传输协议摘要（"HTTP DIGEST" )或者 "IMS AKA" 方式进行鉴权， 从而可以为用户提供灵活的鉴权支持。
参考图 8, "HTTP DIGEST" 鉴权机制的流程大致如下：
, 步骤 s301 , UE向 P-CSCF发送注册报文 Register。
步骤 s302， P-CSCF将 UE的注册报文 Register转发给 I-CSCF。 步骤 s303 , 1-CSCF跟 HSS之间通过 Cx- Selection-Info消息选择相应 的 S-CSCF, 即 I-CSCF向 HSS发出请求， 查找 HSS中的用户属性来确 定由哪个 S-CSCF处理该注册报文。
步骤 s304, I-CSCF将 UE的注册报文 Register转发给步骤 s303中所 确定 S-CSCF。
步骤 s305, S-CSCF与 HSS之间通过 Cx-Put消息， 更新 HSS上的 S-CSCF指示信息， 告知 HSS该用户后续的处理在本 S-CSCF进行。
步骤 s306, S-CSCF向 HSS发送 AV-Req消息， 请求该用户的鉴权 数据。
步骤 s307， HSS检查用户的鉴权签约数据， 根据鉴权签约数据得到 该用户的鉴权方式是 "HTTP DIGEST" , 并产生例如 nonce等鉴权数据 以及期望响应 （XRES )等等。
然后 HSS向 S-CSCF发送 AV-Req-Resp消息， 将该用户的鉴权方式 信息 "HTTP DIGEST" 以及鉴权数据 nonce, 期望响应 （XRES )等发 送给 S-CSCF。
步骤 s308， S-CSCF得到鉴权方式信息并保存 XRES,然后向 I-CSCF 发送 "4xxAuth__Challenge" 消息。
步骤 s309, I-CSCF将 "4xxAuth— Challenge" 消息发送给 P-CSCF。 步骤 s310， P-CSCF接收到 "4xx Auth— Challenge" 消息后， 发现该 消息的 WWW-Authenticate头中 Algorithm参数表示 HTTP DIGEST鉴权 方式， 因此不需要建立和 UE 之间的安全联盟。 P-CSCF 将 "4xx Auth— Challenge" 消息发送给 UE, 其中不携带 Security-Server头。
步骤 s311， UE接收到 "4xx Auth— Challenge"消息后， Algorithm参 数表示 HTTP DIGEST鉴权方式， 因此也不需要建立和 P-CSCF之间的 安全联盟。 UE重新向 P-CSCF发送注册报文 Register, 并携带用于鉴权 的响应 （RES )。
步骤 s312, P-CSCF将携带注册报文 Register发送给 I-CSCF。
步骤 S313 , I-CSCF与 HSS之间通过 Cx-Query确定该 UE注册报文 给哪个 S-CSCF处理，即 I-CSCF向 HSS查询该注册 4艮文给哪个 S-CSCF 处理， HSS根据保存的 S-CSCF指示信息告知 I-CSCF处理该注册^ =艮文 的 S-CSCF。 在以下步驟中， S-CSCF将鉴权成功或鉴权失败的消息发送 给 UE。
步骤 s314， I-CSCF将注册艮文 Register转发给步骤 s313 确定的 S-CSCF。
此后， S-CSCF比较从 HSS获得的 XRES和 UE发送过来的 RES， 当两者一致时， 说明鉴权成功， 当两者不一致时， 说明鉴权失败。
步骤 s315, S-CSCF与 HSS之间通过 Cx-Put消息， 更新 HSS上的 S-CSCF指示信息， 告知 HSS该用户后续的处理在本 S-CSCF进行。
步驟 s316, S-CSCF与 HSS通过 Cx-Pull消息获取用户的签约数据 信息。
步驟 s317， S-CSCF向 I-CSCF发送表示鉴权成功的 200消息， 或者 表示鉴权失败的 403 Forbidden消息。在图中仅以鉴权成功时的 200消息 表示。
步骤 s318, I-CSCF将上述消息发送给 P-CSCF。
步骤 s319, P-CSCF将上述消息发送给 UE。 针对前面的第一至第五实施例， 本发明进一步在 UPSF/HSS上预先 保存的用户鉴权数据为： IMS业务层鉴权和接入层鉴权绑定，以及' ΉΤΤΡ DIGEST" 或 "IMS AKA，，。
图 9a和 9b所示的第六实施例针对的是第三实施例， 采用 IMS业务 层鉴权和接入层鉴权绑定方式失败之后再采用 "HTTP DIGEST"鉴权方 式进行鉴权。
参考图 9a和图 9b, 本发明的第六实施例包括以下步骤：
步骤 601 , UE向 P-CSCF发送注册报文 Register, 该报文携带有接 入运营商标识及接入用户标识。
步骤 602， P-CSCF根据注册报文中的接入运营商标识以及预先设置 的接入运营商标识与 CLF之间的对应关系确定 CLF。
步骤 603, P-CSCF 居注册报文中的接入用户标识， 在上面确定的 CLF中查询用户在接入层的附着信息。 CLF中预先保存了与私有用户标 识对应的附着信息的数据记录， 所述附着信息包括 IP地址信息、位置信 息等，但不包括现有技术中的绑定标识。如果 CLF中没有该接入用户标 识的数据记录， CLF会返回查询失败。
步骤 604, P-CSCF将携带上一步骤中查询结果的注册报文 Register 以及 P-CSCF所接收的该注册报文源 IP地址发送给 I-CSCF。 如杲前面 的查询成功， 则将查询得到的附着信息发送给 I-CSCF; 如果查询失败， 则向 I-CSCF上报查询失败信息。
步驟 605, I-CSCF跟 UPSF/HSS之间通过 Cx-Selection-Info消息选 择相应的 S-CSCF, 即 I-CSCF向 UPSF HSS发出请求， 查找 UPSF/HSS 中的用户属性来确定由哪个 S-CSCF处理该注册 · ^艮文。
步骤 606, I-CSCF将包括上述查询结果的注册报文 Register 以及 P-CSCF所接收的注册报文源 IP地址转发给步驟 605确定的 S-CSCF。 所述查询结果， 在查询成功时为查询得到的附着信息， 在查询失败时为 上报的查询失败信息。
步骤 607 , S-CSCF 与 UPSF/HSS 之间通过 Cx-Put 消息， 更新 UPSF/HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后续的处理 在本 S-CSCF进行。
步骤 608， S-CSCF向 UPSF/HSS发送 AV-Req消息， 请求该用户的 鉴权数据。
步骤 609, UPSF/HSS检查发现该用户配置了 NBA和 HTTP DIGEST 鉴权方式的签约数据。
步骤 610, UPSF/HSS向 S-CSCF发送 AV-Req-Resp消息， 将该用户 的鉴权数据发送给 S-CSCF。
步驟 611， S-CSCF保存所有的鉴权方式以及相应的鉴权数据。 在查 询结果为查询得到的附着信息时， S-CSCF判断 P-CSCF收到的注册报文 Register的源 IP地址与所述从 CLF查询得到的附着信息中的 IP地址信 息是否一致， 如果一致， 则说明鉴权成功，执行步骤 612及其后续流程， 即向 UE发送鉴权成功的消息； 如果不一致， 则说明鉴权失败， 执行步 骤 621及其后续步骤， 即再釆用 "HTTP DIGEST" 鉴权方式进行鉴权。
在查询结果为上艮的查询失败信息时， 也说明鉴权失败， 执行步骤 621及其后续步骤， 即再采用 "HTTP DIGEST" 鉴权方式进行鉴权。
步骤 612 , S-CSCF 与 UPSF/HSS 之间通过 Cx-Put 消息， 更新 UPSF/HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后续的处理 在本 S-CSCF进行。
步骤 613， S-CSCF与 UPSF/HSS通过 Cx-Pull消息获取用户的签约 数据信息。
步骤 614, S-CSCF向 I-CSCF发送 2xxAuthjDK消息， 表示鉴权成 功。
步骤 615， I-CSCF将上述 2xx Auth— OK消息发送给 P-CSCF。
步骤 616, P-CSCF接收到上述 2x Auth_OK消息后，发现以前没有 接收到挑战消息 4xx Auth— Challenge,因此不需要建立和 UE之间的安全 联盟。 P-CSCF将上述 2xx Auth— OK消息发送给 UE。
UE接收到上述 2xx Auth— OK消息后， 发现以前没有接收到挑战消 息 4xx Auth— Challenge, 因此也不需要建立和 P-CSCF之间的安全联盟。
如图 9b 所示的步骤 621 , S-CSCF 在步骤 611 中已经保存了从
UPSF/HSS获取的 HTTP DIGEST鉴权数据。 S-CSCF向 I-CSCF发送包 括 HTTP DIGEST鉴权信息的 "4xx Auth— Challenge" 消息。
步骤 622, I-CSCF将 "4xx Auth_Challenge" 消息发送给 P-CSCF。 步骤 623 , P-CSCF接收到 "4xx Auth— Challenge" 消息后， 发现该消 息的 WW-Authenticate头中 Algorithm参数表示 HTTP DIGEST鉴权方 式， 因此不需要建立和 UE 之间的安全联盟。 P-CSCF 将 " 4xx Auth— Challenge" 消息发送给 UE， 其中不携带 Security-Server头。
步骤 624, UE接收到 "4xx Auth— Challenge" 消息后， Algorithm 参 数表示 HTTP DIGEST鉴权方式， 因此也不需要建立和 P-CSCF之间的 安全联盟。 "UE重新向 P-CSCF发送注册报文 Register, 并携带用于鉴权 的认证参数。
步骤 625， P-CSCF将携带认证参数 Register发送给 I-CSCF。
步骤 626， I-CSCF与 UPSF/HSS之间通过 Cx-Query确定该 UE注册
4艮文给哪个 S-CSCF处理，即 I-CSCF向 UPSF/HSS查询该注册^ :艮文给哪 个 S-CSCF处理， UPSF/HSS根据保存的 S-CSCF指示信息告知 I-CSCF 处理该注册报文的 S-CSCF。
步骤 627, I-CSCF 将注册报文 Register转发给步骤 626 确定的
S-CSCF。
此后， S-CSCF比较以前倮存的从 UPSF HSS获得的认证参数和 UE 发送过来的认证参数， 当两者一致时，说明鉴权成功， 当两者不一致时， 说明鉴权失败。
步骤 628 , S-CSCF 与 UPSF/HSS 之间通过 Cx-Put 消息， 更新 UPSF/HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后续的处理 在本 S-CSCF进行。
步骤 629， S-CSCF与 UPSF/HSS通过 Cx-Pull消息获取用户的签约 数据信息。
步骤 630, S-CSCF向 I-CSCF发送表示鉴权成功的 200消息， 或者 表示鉴权失败的消息。 在图中仅以鉴权成功时的 200消息表示。
步驟 631 , I-CSCF将上述消息发送给 P-CSCF。 步骤 632, P-CSCF将上述消息发送给 UE。
如果是针对第四实施例或第五实施例， 可以 居第四实施例或第五 实施例与第三实施例的不同之处对本实施例作相应的改动， 这里不再赘 述。 图 10a和 10b所示的第七实施例针对的是第三实施例， 采用 IMS业 务层鉴权和接入层鉴权绑定方式失败之后再采用 "IMS AKA"鉴权方式 进行鉴权。
参考图 .10a和图 10b, 本发明的第七实施例包括以下步骤： 步骤 701 , UE向 P-CSCF发送注册报文 Register, 该报文携带有接 入运营商标识及接入用户标识。
步骤 702， P-CSCF根据注册报文中的接入运营商标识以及预先设置 的接入运营商标识与 CLF之间的对应关系确定 CLF。
步骤 703 , P-CSCF #^据注册报文中的接入用户标识， 在上面确定的 CLF中查询用户在接入层的附着信息。 CLF中预先保存了与私有用户标 识对应的附着信息的数据记录，所迷附着信息包括 IP地址信息、位置信 息等，但不包括现有技术中的绑定标识。如果 CLF中没有该接入用户标 识的数据记录， CLF会返回查询失败。
步驟 704, P-CSCF将携带上一步骤中查询结果的注册报文 Register 以及 P-CSCF所接收的该注册报文源 IP地址发送给 I-CSCF。 如果前面 的查询成功， 则将查询得到的附着信息发送给 I-CSCF; 如果查询失败， 则向 I-CSCF上^ =艮查询失败信息。
步骤 705, I-CSCF跟 UPSF/HSS之间通过 Cx-Selection-Info消息选 择相应的 S-CSCF, 即 I-CSCF向 UPSF/HSS发出请求， 查找 UPSF/HSS 中的用户属性来确定由哪个 S-CSCF处理该注册^ =艮文。 步驟 706, I-CSCF将包括上述查询结果的注册报文 Register 以及 P-CSCF所接收的注册报文源 IP地址转发给步骤 705确定的 S-CSCF。 所述查询结果， 在查询成功时为查询得到的附着信息， 在查询失败时为 上报的查询失败信息。
步骤 707 , S-CSCF 与 UPSF/HSS 之间通过 Cx-Put 消息， 更新 UPSF/HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后续的处理 在本 S-CSCF进行。
步骤 708, S-CSCF向 UPSF/HSS发送 AV-Req消息， 请求该用户的 鉴权数据。
步骤 709, UPSF/HSS检查发现该用户配置了 NBA和 IMS AKA鉴 权方式的签约数据。
步骤 710, UPSF/HSS向 S-CSCF发送 AV-Req-Resp消息， 将该用户 的鉴权数据发送给 S-CSCF。
步骤 711 , S-CSCF保存所有的鉴权方式以及相应的鉴权数据。 在查 询结果为查询得到的附着信息时， S-CSCF判断 P-CSCF收到的注册^ ^文 Register的源 IP地址与所述从 CLF查询得到的附着信息中的 IP地址信 息是否一致， 如果一致， 则说明鉴权成功，执行步骤 712及其后续流程， 即向 UE发送鉴权成功的消息； 如果不一致， 则说明鉴权失败， 执行步 骤 721及其后续步骤， 即再采用 "IMS AKA" 鉴权方式进行鉴权。
在查询结果为上报的查询失败信息时， 也说明鉴权失败， 执行步骤 721及其后续步骤， 即再采用 "IMS AKA" 鉴权方式进行鉴权。
步骤 712 , S-CSCF 与 UPSF/HSS 之间通过 Cx-Put 消息， 更新 UPSF/HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后续的处理 在本 S-CSCF进行。
步骤 713 , S-CSCF与 UPSF/HSS通过 Cx-Pull消息获取用户的签约 数据信息。
步骤 714， S-CSCF向 I-CSCF发送 2xxAuth— OK消息， 表示鉴权成 功。
步骤 715， I-CSCF将上迷 2xx Auth— OK消息发送给 P-CSCF。
步骤 716, P-CSCF接收到上述 2xxAuth— OK消息后，发现以前没有 接收到挑战消息 4xx Auth— Challenge,因此不需要建立和 UE之间的安全 联盟。 P-CSCF将上述 2xxAuth— OK消息发送给 UE。
UE接收到上述 2xx Auth—OK消息后， 发现以前没有接收到挑战消 息 4xx Auth— Challenge, 因此也无需建立和 P-CSCF之间的安全联盟。
图 10b 所示的步骤 721， S-CSCF 在步骤 711 中已经保存了从
UPSF/HSS获取的 IMS AKA鉴权数据。 S-CSCF向 I-CSCF发送 4xx
Auth— Challenge消息， 并携带有 IMS AKA鉴权信息。
步骤 722, I-CSCF将所述 4xx Auth— Challenge消息发送给 P-CSCF。 步驟 723， P-CSCF接收到所述 4xx Auth— Challenge消息后， 发现
WWW-Authentication头中的 Algorithm参数表示 IMS AKA鉴权方式， 因此建立和 UE之间的安全联盟， 并将所述 4xx Auth_Challenge消息发 送给 UE。
步骤 724 , UE 接收到所述 4xx Auth__Challenge 消息后， 发现 WWW-Authentication头中的 Algorithm参数表示 IMS AKA鉴权方式， 因此建立和 P-CSCF之间的安全联盟， 重新向 P-CSCF发送新的注册报 文 Register, 并且该 Register携带有认证参数。
步骤 725 , P-CSCF将 UE的注册报文 Register发送给 I-CSCF。
步骤 726, I-CSCF接收到所述注册报文 Register后， 与 UPSF/HSS 之间通过 Cx-Query确定该 UE注册拫文给哪个 S-CSCF处理，即 I-CSCF 向 UPSF HSS查询用户注册报文给哪个 S-CSCF处理， UPSF/HSS根据 保存的 S-CSCF指示信息告知 I-CSCF处理该用户注册报文的 S-CSCF。 步骤 727, I-CSCF 将注册报文 Register转发给步骤 726 确定的 S-CSCF。
此后， S-CSCF比较以前保存的从 UPSF/HSS获得的认证参数和 UE 发送过来的认证参数， 当两者一致时，说明鉴权成功， 当两者不一致时， 说明鉴权失败。
步骤 728 , S-CSCF 与 UPSF/HSS 之间通过 Cx-Put 消息， 更新 UPSF/HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后续的处理 在本 S-CSCF。
步驟 729, S-CSCF与 UPSF/HSS通过 Cx-Pull消息获取用户的签约 数据信息。
步驟 730， 如果鉴权成功， S-CSCF向 I-CSCF发送 2xxAuth— OK消 息， 表示注册成功， 其中 2xx表示成功相应的消息， XX为 00~99的一个 数字。 如果鉴权失败， 则 S-CSCF向 I-CSCF发送表示鉴权失败的消息。
步骤 731， I-CSCF将上述消息转发给 P-CSCF。
步骤 732, P-CSCF将上述消息转发给 UE。
如果是针对第四实施例或第五实施例， 可以根据第四实施例或第五 实施例与第三实施例的不同之处对本实施例作相应的改动， 这里不再赘 述。 图 11a和 lib所示的第八实施例针对的是第一实施例， 采用 IMS业 务层鉴权和接入层鉴权绑定方式失败之后再采用 "HTTP DIGEST"鉴权 方式进行鉴权。
参考图 11a和图 lib, 本发明的第八实施例包括以下步骤： 步骤 801， UE向 P-CSCF发送注册报文 Register。 步骤 802， P-CSCF将 UE的注册报文 Register转发给 I-CSCF。
步骤 803, I-CSCF跟 UPSF/HSS之间通过 Cx-Selection-Info消息选 择相应的 S-CSCF, 即 I-CSCF向 UPSF/HSS发出请求， 查找 UPSF/HSS 中的用户属性来确定由哪个 S-CSCF处理该注册报文。
步骤 804, I-CSCF将 UE的注册报文 Register转发给步骤 803中所 确定 S-CSCF。
步骤 805 , S-CSCF 与 UPSF/HSS 之间通过 Cx-Put 消息， 更新 UPSF/HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后续的处理 在本 S-CSCF进行。 .
步骤 806, S-CSCF向 UPSF/HSS发送 AV-Req消息， 请求该用户的 鉴权数据。
步骤 807, UPSF/HSS检查发现该用户配置了 NBA和 HTTP DIGEST 鉴权方式的签约数据。
步骤 808, UPSF/HSS向 S-CSCF发送 AV-Req-Resp消息， 将该用户 的鉴权数据发送给 S-CSCF, 即至少包括 IMS业务层鉴权和接入层鉴权 绑定方式和鉴权数据以及 "HTTP DIGEST" 鉴权方式和鉴权数据。
步骤 809， S-CSCF 保存所有的鉴权方式以及相应的鉴权数据。 S-CSCF根据在步骤 808 中获得的鉴权方式信息， 该用户的鉴权方式默 认是业务层鉴权和接入层鉴权绑定， 失败后再采用 "HTTP DIGEST"。 然后向 I-CSCF发送 4xx Auth— Challenge消息，并在消息的鉴权头域中表 明鉴权方式是业务层鉴权和接入层鉴权绑定， 即携带鉴权方式指示信 步骤 810, I-CSCF将上述 4xx Auth_Challenge消息发送给 P-CSCF。 步骤 811 , P-CSCF接收到 "4xxAuth— Challenge" 消息后， 发现该消 息的 WWW-Authenticate头中 Algorithm参数表示 IMS业务层和接入层 绑定鉴权方式， 因此不需要建立和 UE之间的安全联盟。 P-CSCF将上述 4xx Auth— Challenge消息发送给 UE， 其中不携带 Security-Server头。
步骤 812, UE接收到所述 4xx Auth_Challenge消息后， Algorithm 参 数表示 IMS 业务层和接入层绑定鉴权方式， 因此也不需要建立和 P-CSCF之间的安全联盟。 UE重新向 P-CSCF发送注册 4艮文 Register, 该报文携带有接入运营商标识及接入用户标识。
步骤 813, P-CSCF根据注册报文中的运营商标识以及预先设置的运 营商标识与 CLF之间的对应关系确定 CLF。
步骤 814， P-CSCF根据注册报文中的接入用户标识， 在上面确定的 CLF中查询用户在接入层的附着信息。 CLF中预先保存了与接入用户标 识对应的附着信息的数据记录， 所述附着信息包括 IP地址信息、位置信 息等，但不包括现有技术的绑定标识。如果 CLF中没有该接入用户标识 的数据记录， CLF会返回查询失败。
步驟 815， P-CSCF将携带上一步骤中查询结果的注册报文 Register 以及 P-CSCF所接收的该 Register源 IP地址发送给 I-CSCF。如果前面的 查询成功， 则将查询得到的附着信息发送给 I-CSCF; 如果查询失败， 则 向 I-CSCF上报查询失败信息。
步骤 816， I-CSCF与 UPSF/HSS之间通过 Cx-Query确定该 UE注册 4艮文给哪个 S-CSCF处理，即 I-CSCF向 UPSF/HSS查询该注册艮文给哪 个 S-CSCF处理， UPSF/HSS根据保存的 S-CSCF指示信息告知 I-CSCF 处理该注册报文的 S-CSCF。
步骤 817， I-CSCF将包含查询结果的注册报文 Register以及 P-CSCF 所接收的该 Register源 IP地址转发给步骤 816确定的 S-CSCF。 所述查 询结果， 在查询成功时为查询得到的附着信息， 在查询失败时为上^ =艮的 查询失败信息。 步骤 818 , 在查询结果为查询得到的附着信息时， S-CSCF 判断 P-CSCF收到的注册艮文 Register的源 IP地址与所述从 CLF查询得到的 附着信息中的 IP地址信息是否一致， 如果一致， 则说明鉴权成功， 执行 步骤 819及其后续流程， 即向 UE发送鉴权成功的消息； 如果不一致， 则说明鉴权失败， 执行步骤 831 及其后续步骤， 即再采用 "HTTP DIGEST" 鉴权方式进行鉴权。
在查询结果为上报的查询失败信息时， 也说明鉴权失败， 执行步骤 831及其后续步骤， 即再采用 "HTTP DIGEST" 鉴权方式进行鉴权。
步骤 819， S-CSCF 与 UPSF/HSS 之间通过 Cx-Put 消息， 更新 UPSF/HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后续的处理 在本 S-CSCF进行。
步骤 820， S-CSCF与 UPSF/HSS通过 Cx-Pull消息获取用户的签约 数据信息。
步骤 821 , S-CSCF向 I-CSCF发送 2xx Auth—OK消息， 表示鉴权成 功。 '
步骤 822, I-CSCF将上述 2xx Auth—OK消息发送给 P-CSCF。
步骤 823， P-CSCF将上述 2xx Auth—OK消息发送给 UE。 ' 如图 lib 所示的步骤 831 , S-CSCF 在步骤 809 中已经保存了从 UPSF/HSS获取的 HTTP DIGEST鉴权数据。 S-CSCF向 I-CSCF发送" 4xx Auth— Challenge" 消息， 其中包含 HTTP DIGEST婆权信息参数。
步骤 832， I-CSCF将 "4xx Auth— Challenge" 消息发送给 P-CSCF。 步骤 833 , P-CSCF接收到 "4xx Auth— Challenge" 消息后， 发现该消 息的 WWW-Authenticate头中 Algorithm参数表示 HTTP DIGEST鉴权方 式， 因此不需要建立和 UE 之间的安全联盟。 P-CSCF 将 " 4xx Auth— Challenge" 消息发送给 UE, 其中不携带 Security-Server头。 步骤 834, UE接收到 "4xxAuth— Challenge" 消息后， Algorithm参 数表示 HTTP DIGEST鉴权方式， 因此也不需要建立和 P-CSCF之间的 安全联盟。 UE重新向 P-CSCF发送注册报文 Register, 并携带用于鉴权 的认证参数。
步骤 835 , P-CSCF将携带认证参数 Register发送给 I-CSCF。
步骤 836, 1-CSCF与 UPSF/HSS之间通过 Cx-Query确定该 UE注册 才艮文给哪个 S-CSCF处理，即 I-CSCF向 UPSF/HSS查询该注册报文给哪 个 S-CSCF处理， UPSF/HSS根据保存的 S-CSCF指示信息告知 I-CSCF 处理该注册报文的 S-CSCF。
步骤 837, I-CSCF 将注册报文 Register转发给步骤 836 确定的
S-CSCF。
此后， S-CSCF比较以前保存的从 UPSF/HSS获得的认证参数和 UE 发送过来的认证参数， 当两者一致时，说明鉴权成功， 当两者不一致时， 说明鉴权失败。
步骤 838， S-CSCF 与 UPSF/HSS 之间通过 Cx-Put 消息， 更新 UPSF/HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后续的处理 在本 S-CSCF进行。
步骤 839, S-CSCF与 UPSF/HSS通过 Cx-Pull消息获取用户的签约 数据信息。
步骤 840, S-CSCF向 I-CSCF发送表示鉴权成功的 200消息， 或者 表示鉴权失败的消息。 在图中仅以鉴权成功时的 200消息表示。
步骤 841， I-CSCF将上述消息发送给 P-CSCF。
、 步骤 842， P-CSCF将上述消息发送给 UE。
如果是针对第二实施例， 可以根据第二实施例与第一实施例的不同 之处对本实施例作相应的改动， 这里不再赘述。 图 12a和 12b所示的第九实施例针对的是第一实施例， 采用 IMS业 务层鉴权和接入层鉴权绑定方式失败之后再采用 "IMS AKA"鉴权方式 进行鉴权。
参考图 12a和图 12b, 本发明的第九实施例包括以下步骤： 步骤 901 , UE向 P-CSCF发送注册报文 Register。
步骤 902, P-CSCF将 UE的注册报文 Register转发给 I-CSCF。
步骤 903, I-CSCF跟 UPSF/HSS之间通过 Cx-Selection-Info消息选 择相应的 S-CSCF , 即 I-CSCF向 UPSF/HSS发出请求， 查找 UPSF HSS 中的用户属性来确定由哪个 S-CSCF处理该注册^ =艮文。
步骤 904, I-CSCF将 UE的注册报文 Register转发给步驟 903中所 确定 S-CSCF。
步骤 905 , S-CSCF 与 UPSF HSS 之间通过 Cx-Put 消息， 更新 UPSF HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后续的处理 在本 S-CSCF进行。
步骤 906, S-CSCF向 UPSF/HSS发送 AV-Req消息， 请求该用户的 鉴权数据。
步骤 907， UPSF/HSS检查发现该用户配置了 NBA和 IMS AKA鉴 权方式的签约数据。
步骤 908, UPSF/HSS向 S-CSCF发送 AV-Req-Resp消息， 将该用户 的鉴权数据发送给 S-CSCF, 即至少包括 IMS业务层鉴权和接入层鉴权 绑定方式和鉴权数据以及 "IMS AKA" 鉴权方式和鉴权数据。
步骤 909, S-CSCF 保存所有的鉴权方式以及相应的鉴权数据。 S-CSCF根据在步骤 908中获得的鉴权方式信息， 该用户的鉴权方式默 认是业务层鉴权和接入层鉴权绑定， 失败后再采用 "IMS AKA，，。 然后 向 I-CSCF发送 4xxAuth— Challenge消息，并在消息的鉴权头域中表明鉴 权方式是业务层鉴权和接入层鉴权绑定， 即携带鉴权方式指示信息。
步骤 910, I-CSCF将上述 4xxAuth— Challenge消息发送给 P-CSCF。 步骤 911 , P-CSCF接收到 "4xxAuth— Challenge"消息后， 发现该消 息的 WWW-Authenticate头中 Algorithm 参数表示 IMS业务层和接入层 绑定鉴权方式，因此不需要建立和 UE之间的安全联盟。 P-CSCF将 "4xx Auth— Challenge" 消息发送给 UE, 其中不携带 Security-Server头。
步骤 912， UE接收到所述 4xxAuth__Challenge消息后， Algorithm参 数表示 IMS 业务层和接入层绑定鉴权方式， 因此也不需要建立和 P-CSCF之间的安全联盟。 UE重新向 P-CSCF发送注册报文 Register, 该报文携带有接入运营商标识及接入用户标识。
步骤 913 , P-CSCF根据注册报文中的运营商标识以及预先设置的运 营商标识与 CLF之间的对应关系确定 CLF。
步骤 914， P-CSCF根据注册艮文中的接入用户标识， 在上面确定的 CLF中查询用户在接入层的附着信息。 CLF中预先保存了与接入用户标 识对应的附着信息的数据记录， 所述附着信息包括 IP地址信息、位置信 息等，但不包括现有技术的绑定标识。如果 CLF中没有该接入用户标识 的数据记录， CLF会返回查询失败。
步骤 915, P-CSCF将携带上一步骤中查询结果的注册报文 Register 以及 P-CSCF所接收的该 Register源 IP地址发送给 I-CSCF。如果前面的 查询成功， 则将查询得到的附着信息发送给 I-CSCF; 如果查询失败， 则 向 I-CSCF上报查询失败信息。
步骤 916, I-CSCF与 UPSF HSS之间通过 Cx-Query确定该 UE注册 报文给哪个 S-CSCF处理，即 I-CSCF向 UPSF/HSS查询该注册报文给哪 个 S-CSCF处理， UPSF/HSS才艮据保存的 S-CSCF指示信息告知 I-CSCF 处理该注册报文的 S-CSCF。
步骤 917, I-CSCF将包含查询结果的注册报文 Register以及 P-CSCF 所接收的该 Register源 IP地址转发给步骤 916确定的 S-CSCF。 所述查 询结果， 在查询成功时为查询得到的附着信息， 在查询失败时为上报的 查询失败信息。
步骤 918 , 在查询结果为查询得到的附着信息时， S-CSCF 判断 P-CSCF收到的注册 ^艮文 Register的源 IP地址与所述从 CLF查询得到的 附着信息中的 IP地址信息是否一致， 如果一致， 则说明鉴权成功，执行 步骤 919及其后续流程， 即向 UE发送鉴权成功的消息； 如果不一致， 则说明鉴权失败， 执行步骤 931及其后续步骤， 即再采用 "IMS AKA" 鉴权方式进行鉴权。
在查询结果为上报的查询失败信息时， 也说明鉴权失败， 执行步骤 931及其后续步骤， 即再采用 "IMS AKA" 鉴权方式进行鉴权。
步骤 919 , S-CSCF 与 UPSF/HSS 之间通过 Cx-Put 消息， 更新 UPSF/HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后续的处理 在本 S-CSCF进行。
步骤 920, S-CSCF与 UPSF/HSS通过 Cx-Pull消息获取用户的签约 数据信息。
步驟 921， S-CSCF向 I-CSCF发送 2xxAuth—OK消息, 表示鉴权成 功。
步骤 922 , I-CSCF将上述 2xx Auth— OK消息发送给 P-CSCF。
步骤 923， P-CSCF将上述 2xx Auth— OK消息发送给 UE。
如图 12b 所示的步骤 931 , S-CSCF在步驟 909 中已经保存了从 UPSF HSS获取的 IMS AKA鉴权数据。 S-CSCF向 I-CSCF发送 4xx Auth__Challenge消息， 并携带有与 IMS A A鉴权相关的信息。 步骤 932， I-CSCF将所述 4xx Auth— Challenge消息发送给 P-CSCF。 步骤 933 , P-CSCF 收到所述 4xx Auth— Challenge 消息后， 发现 WWW-Authentication头中的 Algorithm参数表示 IMS AKA鉴权方式， 建立和 UE之间的安全联盟， 并将所述 4xx Auth— Challenge消息发送给 ΌΈ。
步骤 934 , UE 接收到所述 4xx Auth— Challenge 消息后， 发现 WWW-Authentication头中的 Algorithm参数表示 IMS AKA鉴权方式， 建立和 P-CSCF之间的安全联盟， 重新向 P-CSCF发送新的注册报文 Register, 并且该 Register携带有认证参数。
步骤 935 , P-CSCF将 UE的注册报文 Register发送给 I-CSCF。
步骤 936， I-CSCF接收到所述注册报文 Register后， 与 UPSF/HSS 之间通过 Cx-Query确定该 UE注册报文给哪个 S-CSCF处理，即 I-CSCF 向 UPSF/HSS查询用户注册艮文给哪个 S-CSCF处理， UPSF/HSS根据 保存的 S-CSCF指示信息告知 I-CSCF处理该用户注册报文的 S-CSCF。
步骤 937, I-CSCF 将注册 4艮文 Register转发给步骤 936 确定的 S-CSCF。
此后， S-CSCF比较以前保存的从 UPSF/HSS获得的认证参数和 UE 发送过来的认证参数， 当两者一致时，说明鉴权成功， 当两者不一致时， 说明鉴权失败。
步驟 938 , S-CSCF 与 UPSF/HSS 之间通过 Cx-Put 消息， 更新 UPSF HSS上的 S-CSCF指示信息， 告知 UPSF/HSS该用户后续的处理 在本 S-CSCF。
步驟 939, S-CSCF与 UPSF/HSS通过 Cx-Pull消息获取用户的签约 数据信息。
步骤 940， 如果鉴权成功， S-CSCF向 I-CSCF.发送 2xxAuth— OK消 息， 表示注册成功， 其中 2xx表示成功相应的消息， XX为 00~99的一个 数字。 如果鉴权失败， 则 S-CSCF向 I-CSCF发送表示鉴权失败的消息。
步骤 941 , I-CSCF将上述消息转发给 P-CSCF。
步驟 942 , P-CSCF将上述消息转发给 UE。
如果是针对第二实施例， 可以根据第二实施例与第一实施例的不同 之处对本实施例作相应的改动， 这里不再赘述。
以上所 仅为本发明的较佳实施例而已， 并不用以限制本发明， 凡 在本发明的精神和原则之内， 所作的任何修改、 等同替换、 改进等， 均 应包含在本发明的保护范围之内。

Claims (1)

  1. 权利要求书
    1、 一种 IP多媒体子系统 IMS的鉴权方法， 其特征在于， 该方法包 括以下步骤：
    A.代理呼叫会话控制功能实体 P-CSCF接收到用户终端 UE发送来 的注册报文后， 根据所述注册报文中的信息以及预先设置的注册报文中 的信息与连接位置功能实体 CLF的对应关系确定 CLF;
    B. P-CSCF向所述 CLF查询 UE在接入网中的附着信息得到查询结 果， 并将携带所述查询结果的注册报文发送给询问呼叫会话控制功能实 体 I-CSCF;
    C. I-CSCF将所述注册报文转发给用户签约服务功能实体 UPSF/归 属用户服务器 HSS告知的服务呼叫会话控制功能实体 S-CSCF;
    D. S-CSCF根据从 UPSF/HSS获取的鉴权方式， 对 UE进行鉴权得 到婆权结果， 并将所述鉴权结果发送给 UE。
    2、 根据权利要求 1所述的方法， 其特征在于， 步骤 D中所述鉴权 方式为 IMS业务层鉴权和接入层鉴权绑定 NBA。
    3、 根据权利要求 2所述的方法， 其特征在于， 步骤 D之前进一步 包括：
    S-CSCF向 UPSF/HSS请求所述 UE的鉴权数据；
    UPSF/HSS根据预先设置的用户鉴权签约数据发现该用户的鉴权方 式是 NBA, 并向 S-CSCF发送包括所述鉴权数据的消息。
    4、 根据权利要求 2所述的方法， 其特征在于， 步骤 A中所述注册 报文中的信息为接入运营商标识或所迷注册报文的源 IP地址。
    5、根据权利要求 2所述的方法， 其特征在于， 所述注册报文包括接 入用户标识；预先在 CLF中保存了与所述接入用户标识对应的 UE在接 入网中的附着信息；
    步骤 B中所述 P-CSCF向所述 CLF查询 UE在接入网中的附着信息 得到查询结果的步骤包括：
    P-CSCF才艮据所述接入用户标识向所述 CLF查询 UE在接入网中的 附着信息； 在 CLF中存在与所述接入用户标识对应的 IP地址信息的附 着信息时， CLF向 P-CSCF返回包括所述 IP地址信息的查询结果， 否则 向 P-CSCF返回查询失败的查询结果。
    6、 根据权利要求 2或 5所述的方法， 其特征在于，
    步骤 B进一步包括 P-CSCF将所收到的注册报文的源 IP地址发送给 I-CSCF的步骤；
    步骤 C进一步包括 I-CSCF将所述注册^ =艮文源 IP地址转发给所述 S-CSCF的步驟；
    步骤 D中所述对 UE进行鉴权得到鉴权结果的步驟包括：
    在所述查询结果包括 IP地址信息时， S-CSCF比较所述 P-CSCF所 收到的注册报文源 IP源地址与所述查询结果中的 IP地址信息， 如果一 致， 则得到鉴权成功的鉴权结果， 否则得到鉴权失败的鉴权结果； 在所 述查询结果为查询失败信息时， S-CSCF得到鉴权失败的鉴权结果。
    7、 才艮据权利要求 2所述的方法， 其特征在于， 预先在 CLF中保存 了与注册报文源 IP地址对应的 UE在接入网中的接入用户关联信息； 步骤 B中所述 P-CSCF向所述 CLF查询 UE在接入网中的接入用户 关联信息得到查询结果的步驟包括：
    P-CSCF根据所述注册报文源 IP地址向所述 CLF查询 UE在接入网 中的接入用户关联信息； 在 CLF中存在与所述注册报文源 IP地址对应 的接入用户关联信息时， CLF向 P-CSCF返回包括所述接入用户关联信 息的查询结果， 否则向 P-CSCF返回查询失败的查询结果。 8、 根据权利要求 2或 7所述的方法， 其特征在于，
    步骤 D中所述对 UE进行鉴权得到婆权结果之前进一步包括 S-CSCF 从 UPSF/HSS获得预先保存在 UPSF/HSS的所述 UE的接入用户关联信 息的步骤；
    步骤 D中所述对 UE进行鉴权得到鉴权结果的步骤包括：
    在所述查询结果包括接入用户关联信息时， S-CSCF 比较所述从 UPSF/HSS获得的所述 UE的接入用户关联信息与所述查询结果中的接 入用户关联信息， 如果一致， 则得到鉴权成功的鉴权结果， 否则得到鉴 权失败的鉴权结果； 在所述查询结果为查询失败信息时， S-CSCF得到 鉴权失败的鉴权结果。
    9、根据权利要求 8所述的方法， 其特征在于， 所述接入用户关联信 息为接入用户标识或位置信息。
    10、 根据权利要求 1所迷的方法， 其特征在于，
    所述步骤 D包括： S-CSCF保存从 UPSF HSS获取的 IMS业务层鉴 权和接入层鉴权绑定的鉴权方式以及相应的鉴权数据， 以及第二鉴权方 式以及相应的鉴权数据, S-CSCF首先采用 IMS业务层鉴权和接入层鉴 权绑定的方式， 对 UE进行鉴权得到鉴权结果， 在鉴权结果为成功时， 将该鉴权结果发送给 UE; 在鉴权结果为失败时， 再采用第二鉴权方式 对 UE进行鉴权得到鉴权结果， 并将该鉴权结果发送给 UE。
    11、 根据权利要求 10所述的方法， 其特征在于， 步驟 D中所述从 UPSF/HSS获取的鉴权方式为： 先采用 IMS业务层鉴权和接入层鉴权绑 定的鉴权方式，在 IMS业务层鉴权和接入层鉴权绑定的鉴权方式进行鉴 权失败之后再采用第二鉴权方式。
    12、根据权利要求 10所述的方法， 其特征在于， 所述第二鉴权方式 为 HTTP DIGEST方式。 13、 根据权利要求 l2所述的方法， 其特征在于， 步骤 D中所述采 用 HTTP DIGEST鉴权方式对 UE进行鉴权得到鉴权结果并将该赛权结 果发送给 UE的步骤包括：
    Dl l. S-CSCF向 UE发送包括所述 HTTP DIGEST鉴权方式的挑战 消息；
    D12. UE接收到所述包括 HTTP DIGEST鉴权方式的挑战消息后， 向 S-CSCF发送包含认证参数的注册消息；
    D13. S-CSCF执行 HTTP DIGEST的鉴权过程， 当鉴权成功时， 向
    UE发送表示鉴权成功的消息； 当鉴权失败时，向 UE发送表示鉴权失败 的消息。
    14、根据权利要求 10所述的方法， 其特征在于， 所迷第二鉴权方式 为 IMS AKA方式。
    15、 居权利要求 14所述的方法， 其特征在于， 步骤 D中所述采 用 IMS AKA鉴权方式对 UE进行鉴权得到鉴权结果并将该鉴权结果发 送给 UE的步骤包括：
    D21. S-CSCF向 UE发送包括所述 IMS AKA鉴权方式的 4 战消息； D22. UE接收到所述包括 IMS AKA鉴权方式的 4 战消息后， 向
    S-CSCF发送包括认证参数的注册消息；
    D23. S-CSCF执行 IMS AKA的鉴权过程， 当鉴权成功时， 向 UE 发送表示鉴权成功的消息； 当鉴权失败时， 向 UE发送表示鉴权失败的 消息。
    16、 居权利要求 2或 10所述的方法， 其特征在于， 步骤 A之前 进一步包括：
    Al. UE向 S-CSCF发送注册^ =艮文；
    A2. S-CSCF向 UPSF/HSS请求所述 UE的鉴权数据； A3. UPSF/HSS根据预先设置的用户鉴权签约数据将鉴权方式发送 给 S-CSCF;
    A4. S-CSCF向 UE发送包括所述鉴权方式的消息；
    A5. UE接收到所述包括鉴权方式的消息后， 向 P-CSCF发送新的 注册艮文；
    步骤 A、 步骤 B及步骤 C中所述的注册报文为所述新的注册报文。
CN200680010294.XA 2005-07-05 2006-07-05 因特网协议多媒体子系统的鉴权方法 Active CN101151869B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN200680010294.XA CN101151869B (zh) 2005-07-05 2006-07-05 因特网协议多媒体子系统的鉴权方法

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
CN200510082907 2005-07-05
CN200510082907.8 2005-07-05
CNB2005100932168A CN100442926C (zh) 2005-07-05 2005-08-19 一种ip多媒体子系统鉴权和接入层鉴权绑定的方法
CN200510093216.8 2005-08-19
CN200510109162.X 2005-10-18
CNB200510109162XA CN100395976C (zh) 2005-07-05 2005-10-18 一种因特网协议多媒体子系统的鉴权方法
PCT/CN2006/001569 WO2007003140A1 (fr) 2005-07-05 2006-07-05 Procede d'authentification de sous-systeme multimedia sous protocole ip
CN200680010294.XA CN101151869B (zh) 2005-07-05 2006-07-05 因特网协议多媒体子系统的鉴权方法

Publications (2)

Publication Number Publication Date
CN101151869A true CN101151869A (zh) 2008-03-26
CN101151869B CN101151869B (zh) 2012-03-21

Family

ID=37604090

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200680010294.XA Active CN101151869B (zh) 2005-07-05 2006-07-05 因特网协议多媒体子系统的鉴权方法

Country Status (7)

Country Link
US (2) US7974604B2 (zh)
EP (1) EP1853032B1 (zh)
CN (1) CN101151869B (zh)
AT (1) ATE453282T1 (zh)
BR (1) BRPI0612687B1 (zh)
DE (1) DE602006011282D1 (zh)
WO (1) WO2007003140A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010069197A1 (zh) * 2008-12-17 2010-06-24 华为技术有限公司 多媒体子系统业务处理的方法、装置和多媒体子系统
CN108668274A (zh) * 2017-03-29 2018-10-16 中国移动通信集团北京有限公司 一种实现VoLTE IMS注册的方法及装置

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101151869B (zh) * 2005-07-05 2012-03-21 华为技术有限公司 因特网协议多媒体子系统的鉴权方法
KR100946900B1 (ko) * 2007-01-11 2010-03-09 삼성전자주식회사 Ｉｍｓ 재등록 방법 및 이를 위한 시스템
CN101374263A (zh) * 2007-08-21 2009-02-25 华为技术有限公司 一种业务配置的方法及业务配置保存实体
WO2009080106A1 (en) * 2007-12-20 2009-07-02 Telefonaktiebolaget Lm Ericsson (Publ) Selection of successive authentication methods
EP2250791B1 (en) * 2008-01-11 2016-08-10 Telefonaktiebolaget LM Ericsson (publ) Securing contact information
EP2245873B1 (en) * 2008-02-15 2020-01-22 Telefonaktiebolaget LM Ericsson (publ) System and method of user authentication in wireless communication networks
EP2297916B1 (en) * 2008-06-11 2017-03-29 Nokia Solutions and Networks Oy Method, apparatus, system and related computer program product for handover management
US8793306B2 (en) * 2008-10-03 2014-07-29 Infosys Limited System, wireless communication device and method for combining compatible services
WO2010051421A2 (en) * 2008-10-31 2010-05-06 Edwards Lifesciences Corporation Analyte sensor with non-working electrode layer
US8181030B2 (en) * 2008-12-02 2012-05-15 Electronics And Telecommunications Research Institute Bundle authentication system and method
US8787362B2 (en) * 2009-04-01 2014-07-22 Qualcomm Incorporated Fall back using mobile device assisted terminating access domain selection
US8693642B2 (en) * 2009-04-16 2014-04-08 Alcatel Lucent Emergency call handling in accordance with authentication procedure in communication network
US9019954B2 (en) * 2010-06-18 2015-04-28 Telefonaktiebolaget L M Ericsson (Publ) Methods and apparatuses for handling public identities in an internet protocol multimedia subsystem network
WO2015078528A1 (en) * 2013-11-29 2015-06-04 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for an i-cscf to assign to a user equipment a s-cscf server in an ims system
CN104754575B (zh) * 2013-12-31 2018-07-31 华为技术有限公司 一种终端认证的方法、装置及系统
CN106790055B (zh) * 2016-12-20 2020-04-17 国网天津市电力公司 一种ims系统的注册方法与装置
CA3126805A1 (en) 2019-01-15 2020-07-23 Optimvia, Llc Engineered aryl sulfate-dependent enzymes
BR112022000255A8 (pt) 2019-07-09 2022-03-22 Optimvia Llc Métodos para sintetizar polissacarídeos anticoagulantes
JP2022015655A (ja) * 2020-07-09 2022-01-21 株式会社Ｎｔｔドコモ 通信制御装置および通信システム
EP4182452A4 (en) 2020-07-14 2024-07-31 Optimvia Llc METHOD FOR THE SYNTHESIS OF NON-ANTICOAGULATING HEPARAN SULFATE
US12021905B2 (en) 2022-10-19 2024-06-25 T-Mobile Usa, Inc. Reducing IMS network congestion when a node in the IMS network becomes unavailable

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10116547A1 (de) 2001-04-03 2002-10-10 Nokia Corp Registrierung eines Endgeräts in einem Datennetz
US6954654B2 (en) * 2001-07-31 2005-10-11 Lucent Technologies Inc. Provision of services in a communication system including an interworking mobile switching center
US7574735B2 (en) * 2002-02-13 2009-08-11 Nokia Corporation Method and network element for providing secure access to a packet data network
US6859651B2 (en) 2002-03-28 2005-02-22 Nokia Corporation Method and system for re-authentication in IP multimedia core network system (IMS)
US6938090B2 (en) * 2002-04-26 2005-08-30 Nokia Corporation Authentication and protection for IP application protocols based on 3GPP IMS procedures
DE10223248A1 (de) 2002-05-22 2003-12-04 Siemens Ag Verfahren zum Registrieren eines Kommunikationsendgeräts
CA2501669A1 (en) 2002-10-17 2004-04-29 Enterasys Networks, Inc. System and method for ieee 802.1x user authentication in a network entry device
ATE306776T1 (de) * 2002-10-22 2005-10-15 Verfahren und system zur authentifizierung von benutzern in einem telekommunikationssystem
US7831247B2 (en) * 2002-11-12 2010-11-09 Nokia Corporation Method of communication and communication system
US20040184432A1 (en) 2003-03-19 2004-09-23 Ralitsa Gateva Method for controlling streaming services
US20050060411A1 (en) 2003-09-16 2005-03-17 Stephane Coulombe System and method for adaptation of peer-to-peer multimedia sessions
JP4384177B2 (ja) * 2003-10-14 2009-12-16 シーメンス アクチエンゲゼルシヤフト 移動無線網とｉｍｓネットワークとの間のデータトラフィックを保護する方法
GB0329857D0 (en) * 2003-12-23 2004-01-28 Nokia Corp User registration in a communication system
GB0417296D0 (en) * 2004-08-03 2004-09-08 Nokia Corp User registration in a communication system
CN1642083A (zh) * 2004-09-23 2005-07-20 华为技术有限公司 网络侧选择鉴权方式的方法
ATE553584T1 (de) * 2004-12-17 2012-04-15 Tekelec Us Verfahren, systeme und computerprogrammprodukte zum clustern und kommunizieren zwischen entitäten des internet-protokoll-multimediasubsystems (ims)
CN100428848C (zh) * 2005-05-31 2008-10-22 华为技术有限公司 一种对终端用户标识模块进行ip多媒体域鉴权的方法
US7672297B2 (en) * 2005-06-24 2010-03-02 Aylus Networks, Inc. Mediation system and method for hybrid network including an IMS network
US7561535B2 (en) * 2005-06-24 2009-07-14 Aylus Networks, Inc. System and method for providing dynamic call models for users as function of the user environment in an IMS network
CN100395976C (zh) 2005-07-05 2008-06-18 华为技术有限公司 一种因特网协议多媒体子系统的鉴权方法
CN100442926C (zh) 2005-07-05 2008-12-10 华为技术有限公司 一种ip多媒体子系统鉴权和接入层鉴权绑定的方法
CN101151869B (zh) * 2005-07-05 2012-03-21 华为技术有限公司 因特网协议多媒体子系统的鉴权方法
US20070143834A1 (en) * 2005-12-20 2007-06-21 Nokia Corporation User authentication in a communication system supporting multiple authentication schemes
US9419955B2 (en) * 2006-03-28 2016-08-16 Inventergy Inc. System and method for carrying trusted network provided access network information in session initiation protocol
CN101119250A (zh) * 2006-08-04 2008-02-06 朗迅科技公司 在ims或其它ip网络中将多媒体问候数据传给主叫方的方法
US20080155658A1 (en) * 2006-12-22 2008-06-26 Nokia Corporation Authentication type selection
US7856226B2 (en) * 2007-04-17 2010-12-21 Aylus Networks, Inc. Systems and methods for IMS user sessions with dynamic service selection
EP2163068B1 (en) * 2007-05-22 2016-02-03 Telefonaktiebolaget LM Ericsson (publ) Method, apparatuses and computer program for dynamically configuring a proxy call session control function of the ip multimedia subsystem from a policy control rules server
US7945241B2 (en) * 2007-09-27 2011-05-17 Alcatel-Lucent Usa Inc. Charging for roaming users in IMS networks

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010069197A1 (zh) * 2008-12-17 2010-06-24 华为技术有限公司 多媒体子系统业务处理的方法、装置和多媒体子系统
CN108668274A (zh) * 2017-03-29 2018-10-16 中国移动通信集团北京有限公司 一种实现VoLTE IMS注册的方法及装置

Also Published As

Publication number Publication date
US20080020789A1 (en) 2008-01-24
DE602006011282D1 (de) 2010-02-04
BRPI0612687A2 (pt) 2010-11-30
US8364121B2 (en) 2013-01-29
US20110201308A1 (en) 2011-08-18
EP1853032A1 (en) 2007-11-07
WO2007003140A1 (fr) 2007-01-11
US7974604B2 (en) 2011-07-05
EP1853032A4 (en) 2008-06-25
CN101151869B (zh) 2012-03-21
EP1853032B1 (en) 2009-12-23
BRPI0612687B1 (pt) 2019-05-14
ATE453282T1 (de) 2010-01-15

Similar Documents

Publication Publication Date Title
CN101151869A (zh) 因特网协议多媒体子系统的鉴权方法
CN101322428B (zh) 用于传递密钥信息的方法和设备
JP4567729B2 (ja) 加入者アイデンティティ
CN101401476B (zh) 通信网络中的接入控制
JP4549393B2 (ja) 通信システムにおけるユーザ登録
US9882943B2 (en) Method of access provision
US20030154400A1 (en) Method and network element for providing secure access to a packet data network
CN101156393B (zh) 在ims网络中根据初始过滤规则处理注册消息的方法
CN100403692C (zh) 在ims网络中处理注册初始过滤规则的方法
US20070192838A1 (en) Management of user data
US20130091546A1 (en) Transmitting Authentication Information
CN100395976C (zh) 一种因特网协议多媒体子系统的鉴权方法
CN101971592A (zh) 接入地会话控制器、ip多媒体子系统及其注册会话方法
US20110208863A1 (en) Remote Network Access via a Visited Network
US20110173687A1 (en) Methods and Arrangements for an Internet Multimedia Subsystem (IMS)
CN105429988A (zh) 基于多业务的ims注册方法和ims注册系统
CN105307144A (zh) 一种注册方法、呼叫方法、应用服务器及网络域设备
CN1610441A (zh) 通信系统中消息的验证
CN106101078B (zh) 一种ip多媒体子系统、终端及业务实现方法
CN102480487B (zh) 基于认证的多用户在线视频游戏方法及系统
CN101911651A (zh) 保护联系信息的安全
CN100442926C (zh) 一种ip多媒体子系统鉴权和接入层鉴权绑定的方法
US11490255B2 (en) RCS authentication
CN101232707B (zh) 一种ims网络中区分用户终端鉴权方式的方法及i-cscf
KR100888506B1 (ko) Ｉｍｓ 기반망에서의 서비스 시스템, 그의 서비스 방법 및단말기 등록 방법

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant