认证的增强的制作方法

1.本公开涉及用于增强认证、尤其是用于增强摘要认证和密钥协商（aka）的方法、通信装置和通信设备。


背景技术：

2.摘要认证和密钥协商（aka）是一种用于通过结合摘要方案和如3gpp ts 33.102（v15.1.0）所规定的3gpp aka认证机制两者来认证用户设备（ue）订户的过程。摘要aka不仅由超文本传输协议（http）使用，而且由会话发起协议（sip）和受约束应用协议（coap）使用。摘要aka被广泛用于ip多媒体子系统（ims）中和通用引导架构（gba）中。现有的摘要aka与3g和4g网络配合得很好，但是当在5g网络中部署当前的摘要aka时则存在挑战，因为5g aka过程与3g/4g网络中所使用的aka过程不同。


技术实现要素：

3.本文中的一些实施例有利地使得使用摘要aka的现有应用（例如，ims或gba中的应用）能够与5g aka配合。
4.更具体来说，一些实施例包括一种由通信装置（例如，用户设备或ue）执行的方法。该方法可包括向通信设备发送第一请求，其中，第一请求包括通信装置的通信装置标识符。该方法可进一步包括从通信设备接收第一响应，其中，第一响应包括一个或多个参数。该方法可进一步包括基于所接收的第一响应生成第一密钥和第二密钥。该方法可进一步包括向通信设备发送第二请求，其中，第二请求包括第一密钥和基于第二密钥的消息。在一些实施例中，第二密钥是通信装置和通信设备之间的共享密钥。在一些实施例中，第一密钥可至少部分基于所述一个或多个参数。在一些实施例中，基于第二密钥的消息是摘要认证和密钥协商（aka）消息。在一些实施例中，该方法可进一步包括验证从通信设备接收的第一响应。
5.实施例还包括一种通信装置。该通信装置包括处理电路和存储器。存储器包含处理电路可执行的指令，由此该通信装置配置成向通信设备发送第一请求，其中，第一请求包括通信装置的标识符。该通信装置可进一步配置成从通信设备接收第一响应，其中，第一响应包括一个或多个参数。该通信装置可进一步配置成基于所接收的第一响应生成第一密钥和第二密钥。该通信装置可进一步配置成向通信设备发送第二请求，其中，第二请求包括第一密钥和基于第二密钥的消息。在一些实施例中，第二密钥是通信装置和通信设备之间的共享密钥。在一些实施例中，第一密钥可至少部分基于所述一个或多个参数。在一些实施例中，基于第二密钥的消息是摘要认证和密钥协商（aka）消息。在一些实施例中，该通信装置可进一步配置成验证从通信设备接收的第一响应。
6.一些实施例包括计算机程序产品。该计算机程序产品包括存储在计算机程序产品的非暂时性计算机可读存储介质中的计算机可读指令。当这些指令由通信装置的处理电路（例如，至少一个处理器）执行时，它们使通信装置能够执行所描述的通信装置功能性中的一个或多个功能性。
7.一些实施例包括一种由通信设备执行的方法。该方法可包括从通信装置接收第一请求，其中，第一请求包括通信装置的标识符。该方法可进一步包括向通信装置发送第一响应，其中，第一响应包括一个或多个参数。该方法可进一步包括从通信装置接收第二请求，其中，第二请求包括第一密钥和基于第二密钥的消息。该方法可进一步包括向通信装置发送第二响应，其中，第二响应指示第二请求的验证结果。在一些实施例中，第二密钥是通信装置和通信设备之间的共享密钥。在一些实施例中，第一密钥可至少部分基于所述一个或多个参数。在一些实施例中，基于第二密钥的消息是摘要认证和密钥协商（aka）消息。在一些实施例中，该方法可进一步包括验证第一密钥，并且验证基于第二密钥的消息。
8.一些实施例包括一种通信设备。该通信设备包括处理电路和存储器。存储器包含处理电路可执行的指令，由此该通信装置配置成从通信装置接收第一请求，其中，第一请求包括通信装置的标识符。该通信设备可进一步配置成向通信装置发送第一响应，其中，第一响应包括一个或多个参数。该通信设备可进一步配置成从通信装置接收第二请求，其中，第二请求包括第一密钥和基于第二密钥的消息。该通信设备可进一步配置成向通信装置发送第二响应，其中，第二响应指示第二请求的验证结果。在一些实施例中，第二密钥是通信装置和通信设备之间的共享密钥。在一些实施例中，第一密钥可至少部分基于所述一个或多个参数。在一些实施例中，基于第二密钥的消息是摘要认证和密钥协商（aka）消息。在一些实施例中，该通信设备可进一步配置成验证第一密钥，并且验证基于第二密钥的消息。
9.一些实施例包括计算机程序产品。该计算机程序产品包含存储在计算机程序产品的非暂时性计算机可读存储介质中的计算机可读指令。当这些指令由通信设备的处理电路（例如，至少一个处理器）执行时，它们使通信设备能够执行所描述的通信装置功能性中的一个或多个功能性。
10.实施例还包括对应的计算机程序和载体。计算机程序包含指令，指令在通信装置或通信设备的至少一个处理器上执行时，致使通信装置或通信设备实行上文所描述的实施例中的任一个。实施例进一步包括包含此类计算机程序的载体。这个载体可包括电子信号、光信号、无线电信号或计算机可读存储介质之一。
11.对于以上实施例中的一些实施例，在ue侧和在认证应用程序接口（api）中，可能只需要少量更改。在核心网侧，对于依赖摘要aka过程或5g aka过程的现有应用，可能不需要更改。对于以上实施例中的一些实施例，它们可用于除5g之外的其它网络，诸如未来的6g或更后代的3gpp网络。
附图说明
12.将参照附图通过举例来描述示例性实施例，附图中：图1是http摘要aka过程的信令图。
13.图2是5g aka认证过程的信令图。
14.图3是根据一些实施例的增强aka的架构。
15.图4是根据一些实施例的增强aka摘要过程的信令图。
16.图5是根据一些其它实施例的另一增强aka摘要过程的信令图。
17.图6是根据一些实施例由通信装置执行的方法的逻辑流程图。
18.图7是根据一些实施例由通信设备执行的方法的逻辑流程图。
19.图8是根据一些实施例的通信装置的框图。
20.图9是根据一些实施例的通信设备的框图。
具体实施方式
21.图1示出现有的http摘要aka过程。如rfc3310中所定义，http摘要aka是一种用于通过结合rfc2617中所定义的http摘要认证方案和3gpp ts 33.102（v15.1.0）中所规定的3gpp aka认证机制两者来认证ue订户的过程。http摘要aka的基本思想是将aka参数映射到http摘要质询-响应认证过程上。如图1中所示：1）ue向认证服务器（在图1中称为auth服务器）发送初始请求（例如，http get消息），该初始请求包括订户的标识符，例如，移动台国际订户号码簿号码（msisdn）或者国际移动订户身份（imsi）。
22.2）当auth服务器接收到初始请求时，它向认证中心（auc）发起带有订户标识符的认证请求，所述auth服务器可以是ip多媒体子系统（ims）中使用的代理呼叫会话控制功能（p-cscf）或者通用引导架构（gba）中使用的引导服务器功能（bsf）。
23.3）auc用认证向量答复auth服务器，该认证向量包括认证令牌（autn）、随机质询（rand）和预期认证响应（xres）。
24.4）在获得认证向量之后，auth服务器将rand和autn填充到401未授权响应中，并将该响应发送给ue。
25.5）ue将所接收的rand和autn传递给它的通用集成电路卡（uicc）。uicc运行订户身份模块（usim）中预共享的密钥和算法以核验autn。如果成功，则ue可以认证网络侧。uicc还导出认证响应（res）和密钥资料。ue从uicc接收res，并且基于res的哈希和其它参数生成摘要。
26.6）ue在另一个请求中将所生成的摘要发送给auth服务器。
27.7）auth服务器使用相同的哈希算法基于从auc接收的xres计算哈希。将这个哈希与从ue接收的摘要进行比较。如果它们相等，则网络也可以认证ue。
28.8）为了相互认证和消息完整性，服务器基于xres和其它参数（诸如所接收的请求消息的内容）计算哈希。将该哈希填充到200 ok响应中。ue还可以对照本地计算的哈希核验所接收的哈希。
29.这种摘要aka过程不仅由http使用，而且由会话发起协议（sip）和受约束应用协议（coap）使用。对于在sip上使用摘要aka的示例，请参阅rfc 3310。对于在coap上使用摘要aka的示例，请参阅rfc 7252。摘要aka已经被广泛用于ims（参见3gpp ts 29.228（v15.2.0））和gba（参见3gpp ts 33.220（v15.4.0））中。
30.图2示出5g aka认证过程，该过程用于取代3g和4g网络中使用的现有aka机制。如图2中所示：1）ue通过向安全锚功能（seaf）发送认证请求来发起认证过程，认证请求带有订户标识符，诸如订户永久身份（supi）或者订户隐藏身份（suci），suci是加密的supi。
31.2）然后，seaf通过发送包括所接收的订户标识符和服务网络名称的nausf_ueauthentication请求，来调用认证服务器功能（ausf）。
32.3）然后，ausf向统一数据管理（udm）发送包括所接收的订户标识符和服务网络名
称的nudm_ueauthentication请求。
33.4）udm向ausf发回认证向量，认证向量包括认证令牌（autn）、随机质询（rand）和预期认证响应（xres*）。
34.5）ausf存储xres*，并且从所接收的xres*计算预期认证响应的哈希值（hxres*）。
35.6）然后，ausf向seaf发送包括autn、rand和hxres*的认证向量。
36.7）seaf向ue发送包括autn和rand的认证请求。
37.8）ue接收认证请求，并且验证所接收的autn。ue还使用rand和预共享的密钥计算res*。
38.9）然后，ue将包含在认证响应中的所计算的res*发送给seaf。
39.10-11）seaf通过对从ue接收的res*求哈希并且将其哈希与从ausf接收的hxres*进行比较，来验证从ue接收的res*。如果它们匹配，则在服务网络中成功认证了ue。但是，seaf继续用归属网络认证ue。因此，seaf将从ue接收的res*发送给ausf。
40.12-13）ausf将从ue接收的res*与在步骤4中从udm接收的xres*进行比较。如果它们匹配，则在归属网络中成功认证了ue。然后，ausf将包括k
seaf
和supi的认证成功响应发送给seaf。
41.14）seaf向ue发送认证成功响应。
42.对于有关5g aka的更多细节，请参阅3gpp ts 33.501（v15.5.0）。与3g或4g aka相比，在5g aka中，区别主要在网络侧上。在如图1中所示的当前的摘要aka过程中，因为假设ue知道res并且假设auth服务器知道xres，所以从不通过网络发送由ue计算的res。因此，ue仅通过对res和其它参数求哈希来计算摘要。auth服务器侧使用xres和ue已知的相同参数来计算哈希值，并且将它与所接收的摘要进行比较。然而，在上文所描述并且图2中所示的5g aka过程中，seaf在认证过程期间并不知道xres*。因此，ue需要将res*发送给seaf，并且seaf必须对它求哈希而得到hres*，并且将它与从ausf接收的hxres*进行比较。因此，当前的摘要aka认证无法与5g配合。
43.图3示出可以与5g aka一起使用增强的摘要aka的架构的示例。采用增强的摘要aka，ue可以安全地将res*传送给服务器。同时，增强的摘要aka过程仍然与现有的摘要aka认证机制和5g aka认证机制兼容。如图3中所示，auth服务器可以是部署在5g核心网（5gc）中或连接到5g核心网（5gc）的应用功能（af）之一。auth服务器14a包括两个接口。面向ue的第一接口支持基于http、sip或coap的摘要aka过程。面向5gc网络中的ausf 16的第二接口支持5g aka过程。因此，auth服务器14a可以使用由ausf 16提供的nausf_ueauthentication服务。在实施例之一中，第二接口可由seaf 14b支持。seaf 14b可被嵌入auth服务器14a中（如图3中所示），或者独立于auth服务器14a，但是连接到auth服务器14a（图中未示出）。在另一实施例中，第二接口可由代理呼叫会话控制功能（p-cscf）14b、由引导服务器功能（bsf）14b或由另一网络功能支持。这些网络功能中的任何一项都可被嵌入auth服务器14a中，或者独立于auth服务器14a，但是连接到auth服务器14a。
44.此外，在一些实施例中，可使用安全协议（例如，传输层安全（tls）、安全套接字层（ssl）协议等）来保护ue和auth服务器之间的接口。在ue例如对于一些受约束物联网（iot）装置不支持或不能支持任何安全协议（例如，tls或ssl）的实施例中，将在稍后的实施例中提供允许以安全的方式传输res*的备选方法。
45.图4示出与5gc结合的增强的摘要aka过程的实施例之一，其中，使用tls来保护ue 12和auth服务器/seaf 14之间的接口的安全。在一些其它实施例中，可能用另一安全协议（例如，ssl协议）来取代tls以保护ue和auth服务器之间的接口。在图4中，使用http作为示例。在一些其它实施例中，可以用另一传输协议（例如，sip或coap）来取代http以传输数据。auth服务器14a和seaf 14b可共置一处，或者彼此分开、但可以彼此通信。可以由代理呼叫会话控制功能（p-cscf）14b、由引导服务器功能（bsf）14b或由另一网络功能来取代seaf 14b。
46.1）ue与auth服务器14a建立tls连接，以便通过安全连接来保护随后的通信。
47.2）ue发送带有ue的订户标识符的http get请求。订户标识符可以是ue 12的订户永久身份（supi）、订户隐藏身份（suci）、移动台国际订户号码簿号码（msisdn）、国际移动订户身份（imsi）、外部id或任何其它订户标识符中的一个或多个。
48.http get消息的示例如下所示：3）当auth服务器/seaf 14接收到请求（如果seaf 14b与auth服务器分开，则将订户标识符传递给seaf 14b）时，seaf 14b将包含订户标识符和服务网络名称的nausf_ueauthentication消息发送给ausf 16。
49.4）ausf 16将nudm_ueauthentication消息发送给udm 18，该nudm_ueauthentication消息包含所接收的订户标识符和服务网络名称。
50.5）udm 18用包括rand、xres*和autn的认证向量来响应ausf 16。
51.6）ausf 16存储xres*，并且从所接收的xres*计算xres*的哈希值（hxres*）。
52.7）ausf 16将包括所接收的rand、autn和所计算的hxres*的认证向量发送到auth服务器/seaf 14。
53.8）auth服务器/seaf 14将rand和autn填充到http 401未授权响应中，并将它发送到ue 12。
54.http 401未授权响应消息的示例如下所示：9）ue 12将autn和rand传递给它的通用集成电路卡（uicc）。在uicc成功验证所接收的autn之后，它生成res，并且从res导出res*。ue 12继续导出锚密钥k
seaf
。
55.10）ue 12在用base64对res*编码之后，在指令“cnonce”中将res*发送到auth服务
器/seaf 14。使用锚密钥k
seaf
作为“密码”参数（共享密钥）以用于计算摘要响应，如rfc3310和rfc2617所描述。
56.包含res*和摘要的第二http get消息的示例如下所示：get消息的示例如下所示：与图2中所示的当前的摘要aka过程相比，在图4中所示的增强的aka过程中，因为auth服务器/seaf在认证过程期间不知道xres*，所以ue需要将res*发送给auth服务器/seaf。因此，res*不能用作ue和auth服务器/seaf之间的共享密钥，就像在当前的摘要aka中所做的那样。因此，需要使用新的密钥作为ue和auth服务器/seaf之间的共享密钥。在一些实施例中，使用锚密钥k
seaf
作为共享密钥，因为ue和auth服务器/seaf都可以在不改变现有的5g aka过程的情况下获得k
seaf
。此外，当使用锚密钥k
seaf
作为共享密钥时，只需要改变ue侧和面向ue侧的认证应用程序接口（api）。在网络侧上，对于当前的5g aka过程无需改变。即使用p-cscf或bsf来取代seaf，当p-cscf或bsf与5g网络配合时，它们也可以在不改变现有的5g aka过程的情况下获得相同的密钥。
57.11-12）auth服务器/seaf 14从cnonce指令中取回res*。seaf 14b（它可被嵌入auth服务器14a中）对res*求哈希而得到hres*，如3gpp ts 33.501（v15.5.0）的附件a.5所规定。将hres*与从ausf接收的认证向量中包含的hxres*进行比较。如果它们匹配，则auth服务器/seaf 14在nausf_ueauth_confirm消息中将res*发送到ausf。
58.13）ausf 16检查从seaf 14b接收的res*是否与ausf 16在步骤5中从udm 18接收的所存储的xres*匹配。如果是，则ausf 16用锚密钥k
seaf
确认该认证，并且在如ts 33.501（v15.5.0）所规定的nausf_ueauthetication_authetication响应消息中将它发回到seaf 14b，seaf 14b可被嵌入auth服务器14a中。
59.14）auth服务器14a从seaf 14b获得锚密钥k
seaf
，在（如rfc 3310所规定）为了服务器认证而生成服务器侧摘要时，使用它作为“密码”参数（共享密钥）。
60.15）如果摘要验证成功，则auth服务器将200 ok响应返回到ue 12，如rfc3310和rfc2617中所描述。
61.发送http 200 ok响应的示例如下所示：图5示出增强的aka摘要过程的实施例，其中没有安全协议（例如，tls或ssl）可用于ue 12和auth服务器14a之间的接口。例如，ue 12可以是不能支持tls/ssl的受约束iot装置，或者tls/ssl可能由于例如缺乏硬件随机数发生器而不够强。图5中也使用http作为示例。然而，在一些其它实施例中，可使用另一传输协议（例如，会话发起协议（sip）或受约束应用协议（coap））来传输数据。auth服务器14a和seaf 14b可共置一处，或者彼此分开、但可以彼此通信。在一些实施例中，可以由代理呼叫会话控制功能（p-cscf）14b、由引导服务器功能（bsf）14b或由另一网络功能来取代seaf 14b。
62.与图4中所示的增强的aka摘要过程相比，图5中所示的aka摘要过程的主要区别是，使用包括公钥和私钥的密钥对来保护由ue 12计算的res*。详细区别如下所列：
‑ꢀ
在步骤1中，没有安全协议用于保护ue 12与auth服务器14a之间的接口。
63.‑ꢀ
在步骤7中，auth服务器/seaf 14包括密钥对的公钥，密钥对的私钥（k
private
）被存储在auth服务器/seaf 14本身中。如rfc 3310那样，将公钥（k
public
）填充到“nonce”的指令中，nonce指令包括rand、autn和由服务器侧附加的服务器数据。在服务器数据的部分中填充公钥。
64.‑ꢀ
在步骤9中，ue 12使用公钥来加密res*。在ue用base64对res*编码之后，将加密的res*填充在“cnonce”指令中，并将它发送到auth服务器/seaf 14。
65.‑ꢀ
在步骤10中，auth服务器14a使用与公钥对应的私钥来解密res*，并将res*传递给seaf 14b，seaf 14b可被嵌入auth服务器或者连接到auth服务器。
66.图6描绘根据特定实施例由通信装置（例如，无线装置，诸如用户设备ue）执行的方法600。虚线框是可选的。在一些实施例中，该方法可包括向通信设备发送第一请求（例如，http get、sip register或coap get），该请求包括通信装置的标识符（例如，supi、suci、imsi、msisdn、外部id等）（框602）。在一些实施例中，通信设备可包括认证服务器。在一些实施例中，通信设备实现代理呼叫会话控制功能（p-cscf）、引导服务器功能（bsf）或安全锚功能（seaf）。在一些实施例中，该方法还可包括从通信设备接收第一响应，第一响应包括一个或多个参数（例如，rand、autn等）（框603）。在一些实施例中，该方法可进一步包括基于所接收的第一响应生成第一密钥和第二密钥（框605）。在一些实施例中，第一密钥是至少部分基于所述一个或多个参数。在一些实施例中，第一密钥是认证响应的值（res*）。在一些实施例中，第二密钥是通信装置和通信设备之间的共享密钥（例如，k
seaf
）。在一些实施例中，该方法还可包括向通信设备发送第二请求，第二请求包含第一密钥和基于第二密钥的消息（框
606）。在一些实施例中，基于第二密钥的消息是摘要认证和密钥协商（aka）消息。
67.在一些实施例中，该方法还包括验证从通信设备接收的第一响应（框604）。在一些实施例中，该方法还可包括接收指示第二请求消息的验证成功的第二响应（例如，http、sip或coap成功响应）（框607）。
68.在一些实施例中，该方法还可包括在发送第一请求（框602）之前，与通信设备建立加密或以其它方式安全的连接（框601）。在一些实施例中，加密连接是基于传输层安全（tls）协议或者安全套接字层（ssl）协议。在一些实施例中，该方法可包括：在发送包括第一密钥的第二请求（框606）时，使用第四密钥（k
public
）（图6中未示出）来加密第一密钥。
69.图7描绘根据特定实施例由通信设备（例如，seaf、p-cscf、bsf等）执行的方法700。虚线框是可选的。在一些实施例中，该方法可包括从通信装置（例如，无线装置，诸如用户设备ue）接收第一请求，第一请求包括通信装置的身份（例如，supi、suci、imsi、msisdn、外部id等）（框702）。在一些实施例中，通信设备包括认证服务器。在一些实施例中，第一请求是http get、sip register或coap get消息。在一些实施例中，该方法还可包括向通信装置发送第一响应，第一响应包括一个或多个参数（例如，rand、autn等）（框705）。在一些实施例中，该方法还可包括从通信装置接收第二请求，第二请求包括第一密钥和基于第二密钥的消息（框706）。在一些实施例中，第一密钥是至少部分基于所述一个或多个参数。在一些实施例中，第一密钥是认证响应的值（res*）。在一些实施例中，第二密钥是通信装置和通信设备之间的共享密钥（例如，k
seaf
）。在一些实施例中，基于第二密钥的消息是摘要认证和密钥协商（aka）消息。在一些实施例中，该方法可进一步包括向通信装置发送第二响应（例如，http、sip或coap成功响应），第二响应指示第二请求的验证结果（框711）。
70.在一些实施例中，该方法还可包括验证第一密钥（框707）。在一些实施例中，验证第一密钥包括：计算第一密钥的哈希，并且将所计算的第一密钥的哈希与第一密钥的预期哈希进行比较。在一些实施例中，第一密钥是认证响应的值（res*），第一密钥的哈希是认证响应的哈希值（hres*），而第一密钥的预期哈希是认证响应的预期哈希值（hxres*）。在一些实施例中，该方法还可包括验证基于第二密钥的消息（框710）。在一些实施例中，验证基于第二密钥的消息包括使用从网络节点（例如，ausf）接收的第三密钥来验证该消息。在一些实施例中，第三密钥是通信装置和通信设备之间的共享密钥（例如，k
seaf
）。
71.在一些实施例中，该方法还可包括将从通信装置接收的通信装置标识符发送到网络节点（例如，ausf）（框703）。在一些实施例中，该方法还可包括从网络节点（例如，ausf）接收第一密钥的预期哈希（框704）。在一些实施例中，该方法还可包括将经过验证的第一密钥发送到网络节点（例如，ausf）（框708）。在一些实施例中，该方法还可包括从网络节点（例如，ausf）接收第三密钥（框709）。
72.在一些实施例中，该方法可包括在接收第一请求（框702）之前，与通信设备建立加密或以其它方式安全的连接（框701）。在一些实施例中，加密连接是基于传输层安全（tls）协议或者安全套接字层（ssl）协议。在其它实施例中，该方法可包括：当接收到第一密钥（框706）时，由通信装置使用第四密钥（例如，k
public
，图7中未示出）来加密第一密钥；以及当验证了第一密钥（框707）时，使用第五密钥（例如，k
private
，图7中未示出）来解密第一密钥。
73.图8示出如根据一个或多个实施例实现的通信装置800（例如，无线装置、ue）。如所示，通信装置800包括处理电路810和通信电路820。通信电路820（例如，无线电电路）配置成
例如经由任何通信技术向一个或多个其它节点传送信息和/或从一个或多个其它节点接收信息。此类通信可经由通信装置800内部或外部的一个或多个天线840来进行。处理电路810配置成诸如通过执行存储在存储器830中的指令来执行上文所描述（例如，图6中）的处理。在这方面，处理电路810可实现某些功能部件、单元或模块。
74.图9示出如根据一个或多个实施例实现的、配置用于与通信装置通信的通信设备900。如所示，通信设备900包括处理电路910和通信电路920。通信电路920配置成例如经由任何通信技术向一个或多个其它节点传送信息和/或从一个或多个其它节点接收信息。处理电路910配置成诸如通过执行存储在存储器930中的指令来执行上文所描述（例如，图7中）的处理。在这方面，处理电路910可实现某些功能部件、单元或模块。
75.计算机程序包含指令，指令在通信装置或通信设备的至少一个处理器上执行时，致使通信装置或通信设备实行上文所描述的相应处理中的任何处理。在这方面，计算机程序可包括配置成执行上文所描述的处理的一个或多个步骤的一个或多个代码模块。
76.实施例进一步包括包含此类计算机程序的载体。此载体可包括电子信号、光信号、无线电信号或计算机可读存储介质之一。
77.在这方面，本文中的实施例还包括存储在非暂时性计算机可读（存储或记录）介质上并且包含指令的计算机程序产品，所述指令在由通信装置或通信设备的处理器执行时，致使通信装置或通信设备如上文所描述地执行。
78.实施例进一步包括包含程序代码部分的计算机程序产品，当计算装置执行计算机程序产品时，程序代码部分用于执行本文中的实施例中的任何实施例的步骤。这种计算机程序产品可被存储在计算机可读记录介质上。
79.现在将描述附加实施例。出于说明的目的，可将这些实施例中的至少一些实施例描述为可适用于某些上下文和/或无线网络类型，但是这些实施例同样可适用于未明确描述的其它上下文和/或无线网络类型。