用于分布应用服务器上的负载的方法和设备的制作方法

专利名称：用于分布应用服务器上的负载的方法和设备的制作方法
技术领域：
本发明一般涉及用于在应用服务器中的多个等业务模块之间分 布数据和处理负载的方法和设备。
背景技术：
随着3G移动技术的出现，已经开发了许多新通信技术，这些新 技术提供更大的网络容量和更高的传输速率。例如，使用GPRS(通 用分组无线电服务)和WCDMA (宽带码分多址)技术来支持需要 范围广泛的数据速率和不同协议的无线多媒体电话服务。今天趋势 也是朝分组交换传输发展的，这提供更大的灵活性和可用通信资源 的更高利用率。而且，在用户市场上快速出现新的成熟终端，它们具有高分辨 率彩色显示屏和用于以不同格式传送音频和可^/[言息的多种编解码 器(编码器/解码器)。多i某体服务可以包括以多种不同格式和组合来 传送表示语音、图像、文本、文档、动画、音频文件、视频文件等 的数据。以电信领域中流行的目标或期望是将所有服务会聚到单个基于 分组的传输机制因特网协议(IP),而不管服务的类型、接入网和 技术。因此，最近第三代通用伙伴项目(3GPP)开发了称为"IP多 i某体子系统，，(IMS)的服务网络体系结构来作为一个开放标准，以 向接入网的运营商提供在分组域中提供多々某体服务的能力。基本上，只要接入网在带宽、QoS (服务质量)等方面满足服务 需求，包括多种不同网元的IMS服务网络可以与任何类型的接入网 集成，并且独立于所使用的接入技术。因此，IMS是允许基于IP传 输来启用服务的平台，而基本不限于任何一组受限的特定服务。正TF (因特网工程任务组)已定义了称为SIP (会话发起协议) 的通信协议来作为用于处理范闺广泛的基于IP的服务的通用会话管 理协议。SIP是用于创建、修改和终止与一个或多个参与方的通信会 话的信令协议。SIP也是运行于多个不同传输协议之上的应用层协 议。可以使用UDP (用户数据报协议)、TCP (传输控制协议)或SCTP (流控制传输协议)作为SIP消息的传输机制。当发送SIP消息时， 使用称为"SIPURI"(统一资源定位符)的定址元素来分别指示所传 送的SIP消息的源和目的地。图1 一般性地图示用于通过IMS服务网络提供多媒体服务的基 本网络结构。应该注意该附图被大大地简化而仅示出理解本发明内 容所必需的网络节点的选择。在包括一 个或多个多媒体服务的通信 会话S中，主叫移动终端A连接到第一无线电接入网100,并与连 接到第二无线电接入网102的被叫移动终端B通信。或者，终端A 可以与固定终端或计算机或内容服务器通信，其中该固定终端或计 算机或内容服务器向该终端交付某种多媒体内容，例如音乐、电影 或游戏。IMS网络104连接到第一无线电接入网100并处理有关终端A 由其用户发起的该会话。实际上，IMS网络104接收并处理任何终 端A的用户所发出的任何服务请求。在此示例中，对应IMS网络106 代终端B处理该会话，并且两个IMS网络104和106 ^皮不同的运营 商来控制。相似地，IMS网络106接收和处理终端B的用户所发出 的任何服务请求。在下文描述中，将考虑主叫方终端A的IMS网络 104，但是描述的功能和过程也可以净交好在IMS网络106中工作。或 者，终端A和B当然可以连4秦到相同4妄入网和/或属于相同的IMS归 属地网络。一般来说，多媒体服务始终由订户的归属地IMS网络来处理，
并且在所示的情况中，终端A和B连接到它们各自的归属地IMS网 络。在其他方面，如果终端A和B属于相同的归属地网络，则仅一 个IMS网络将处理从终端A和B的所有服务请求。由在IMS网络104中指定给终端A的称为S-CSCF (服务呼叫 会话控制功能)的节点108使用S1P信令来管理图示的会话S，并且 由SIP应用服务器IIO来启用和执行所使用的多媒体服务。基本上， S-CSCF节点108用作SIP应用服务器110对终端A的代理，并从终 端A向终端B的IMS网络106发送SIP消息，如图虚线箭头所示。 而且，主数据库单元HSS (归宿地订户服务器)112其中存储SIP应 用服务器110可以提取来用于为订户执行服务的订户和认证数据以及 服务信息。S-CSCF节点108还可以从HHS 112提取信息以便按HSS 112中的"触发器"确定的来确定哪个应用服务器110来处理终端A 请求的服务。称为I-CSCF的节点(询问呼叫会话控制功能)114连接到其他 IMS网络(在本例中为网络106),并且作为来自其他IMS网络的SIP 消息的网关。I-CSCF 114从终端B的IMS网络106接收SIP消息， 如图另一个虚线箭头所示。称为P-CSCF (代理呼叫会话控制功能) 的另一个节点116作为从任何接入网(例如网络100 )至IMS网络104 的入口点，并且用户与IMS网络104之间的所有信令流经由P-CSCF 116来路由。对于理解本发明内容，无需对I-CSCF节点114和P-CSCF 节点116的多种功能做进一步的描述。当然，IMS网络104包括许 多不同节点和功能，例如其他S-CSCF节点和SIP应用服务器，本文 出于简明的目的而未将其示出。基本上，IMS网络106包括与网络104 类型相同的节点。所示的SIP应用服务器110可以配置成向订户提供一个或多个 特定多媒体服务。某个SIP应用服务器上的工作负载可能是繁重的， 并且可能快速增长，由此个别服务器至少在有限时间期间变得超负 载。因此常常将SIP应用服务器构建成具有多个相似服务器单元的 群，下文将这些相似服务器单元称为"业务才莫块"，每个业务才莫块能 够基本执行应用服务器所需的功能。为了克服应用服务器中的瞬时 超负载问题，可以在应用服务器中添加更多业务^=莫块以满足更高的 负栽。因此，具体应用服务器通常包括多个此类业务模块和用于将工作负载分布到业务模块之间的"负栽平衡"功能。以此方式，提 供一种具有业务^^莫块群的可伸缩服务器，它是透明的由此仅单个"虚 拟"服务器被看到。因此通过添加或移除群中的业务模块来实现可 伸缩性。图2以示意图形式更详细地图示图1中的适于处理来自订户的 服务请求的SIP应用服务器110。服务器110的前端是具有负载平衡 功能LB的接收单元200，它配置为将输入的服务请求R调度到不同 的业务对莫块202a、 202b、 202c、 202d、...。这些业务模块的每个才莫块 都能够根据服务器110中实现的服务处理请求。可以采用不同方式来 实施将输入的服务请求调度到不同业务模块。基本上，任何业务模 块都可以例如随机地或根据"轮叫"调度等来选择，或者可以使用 总是提供相同结果的散列算法来对特定用户重复选择相同的业务才莫 块，例如使用与该用户或会话关联的常数值作为对算法的输入。在WO 03/069473和WO 03/069474中，描述了使用负载平衡功 能在服务器中进行负载平衡和数据分布的一些解决方案。在这些已 知的解决方案中，使用用户标识作为对散列算法的输入来针对来自 特定用户的不同请求提供相同的服务器。当SIP应用服务器激活订户的服务时，使用创建的会话标识"呼 叫ID"作为对正在进行的会话的引用。而且，还确定会话期间使用 的多个不同会话细节，例如订户数据、服务参数、编解码器(编码 器/解码器)、协议、复用方案等。因此从HSS 112提取必需的会话数 据/信息，并且也可以在传送的SIP消息中读取一些。然后在整个会 话过程中将该数据临时存储在应用服务器中。如果应用服务器包含业务模块群，则可以将会话信息存储在服 务器中的公共数据库，该公共数据库对于所有业务模块可用或将其 在本地存储在为该会话指定的特定业务模块中。在前一种情况中， 任何业务模块可以通过从公共数据库提取必需的会话信息来处理正 在进行的会话，但是这^皮视为导致时延增加的 一种相对复杂的情况。 在后一种情况中，必须将需要存储的会话信息的任何后续请求定向 到该具体业务;^莫块，有时称为会话"亲合性，，或"粘着性"。在基于HTTP的消息的情况中，负载平衡功能正常情况下负责总是在会话期 间选择相同的业务模块。负载平衡功能则可以使用适合的散列算法， 如上所述，使用会话专用值作为输入以提供相同的业务才莫块。当执行基于SIP的"IP语音"服务时，可以使用应用层负载平 衡功能(公知为"无状态负载平衡SIP代理")，其一个示例是称为 "Vovida负载平衡器"的实现。Vovida负栽平衡器将输入的请求分 布到不同的同性质服务器，由此所有用户可以将它们的请求定向到 相同的SIPURI地址，并且负载平衡器将动态地指定服务器来处理每 个请求。将每个请求转发到预定的关联的服务器列表上出现的下一 个可用服务器，即根据"轮叫"调度。负载平衡器则接收响应，然 后将它们转发回请求方。Vovida负载平衡器在输入的SIP请求分组的寺艮头中的"Via"地 址字段中添加它自己的SIPURI地址，然后将该分组传输到指定的服 务器，由此从该服务器接收后面响应，然后将该响应转发到请求方。 在基于TCP的传输的情况中，使用"滑动窗口"机制来用于可靠地 在IP端点之间流传输应用数据。在TCP层中，端点不知道数据流中 的定界符，这实质上意味着无法分辨SIP消息。因此，Vovida负载 平衡器在应用层中工作，它据此接收TCP流并同样地处理SIP消息。因此可以使用由"Call ID"、 "To"、 "From"标记出得到的值作 为对算法的输入值来应用散列算法来获得"粘着性"。该值称为"对 话标识符"。但是，问题是必须每次应用散列算法以便到达相同的业 务模块，因为该过程中占用大量处理资源。这种解决方案要求群前 务相关的数据(作为散列表)。但是，因为Vovida加载平衡器不存储事务之间的数据，所以甚 至无法确保SIP对话内的请求一直被定向到相同的业务模块。因此， 所有业务才莫块必须使用共享的数据库等来用于存储任何给定SIP对话 的状态。因为群前端以此方式来处理SIP业务，所以带来了增加的很 大复杂性，随着时间推移，这可能导致软件失败和软件产品的维护 成本增加。因此，在此上下文中，如上解释的，使用散列算法和/或公共数 据库一般将不提供用于获取负载平衡和会话亲合性的满意解决方 案。US 2003/0074467 Al公开与负载平衡器304通信的多个接收月艮 务器308a-d,其中每个接收服务器与指定该接收服务器的不同的唯 一性服务端口号相关联。客户服务器302传输的第一数据分组包含 目的地端口号，并首先在负载平衡器被接收到。如果目的地端口号 与唯一性服务端口号的其中之一 匹配，则负载平衡器将数据分組发送到对应的接收服务器。如果目的地端口号与公共重定向端口号的 其中之一匹配，则负载平衡器选择对应的接收服务器组中的接收服 务器并向其发送数据分组。所选的接收服务器然后向客户服务器发送响应，该响应包含设 为与该接收服务器关联且客户服务器必须向其发送后续数据分组的 服务端口号的重定向标志。因此在US 2003/0074467 Al中提出的解 决方案中，根据第一接收的数据分组中给定的目的地端口号标识并 选择接收服务器。发明内容本发明的一个目的是要解决上文概述的问题，并且对输入的多 々某体服务请求的处理和存储负载进行有效率地分布。本发明的目的 还在于普遍性地在可伸缩应用服务器群中指定业务模块时降低时延 和复杂性，并使每个服务请求的指定过程简单而仍旧可靠。
可以通过提供分别如所附独立权利要求所述的方法和设备来达 到这些和其他目的。根据一个方面，提供一种在应用服务器中处理 输入的服务请求的方法，该应用服务器包括一组相等业务模块，每 个相等业务模块能够处理对应用服务器中实现的一个或多个多j!某体服务的请求。在本发明方法中，确定接收的服务请求是初始服务请 求还是相同会话中在先前服务请求之后的后续服务请求。在初始服务请求的情况中，应用基本能够选择该组业务^^莫块中 的任何业务模块的负载平衡功能来指定用于处理接收的服务请求的 业务才莫块。然后，发送对初始服务请求的响应，该响应包含与所选 并指定的业务模块关联的端口号。在后续服务请求的情况中，应用端口映射功能以确定与接收的 后续服务请求中给出的端口号关联的该组业务模块中的特定业务模 块用于处理接收的服务请求。接收的后续服务请求中的端口号在对 先前服务的请求的早前响应中提供给请求者。本发明方法可以在属于IMS服务网络的应用服务器中实现，然 后通常根据SIP协议传送服务请求。在该情况中，优选地通过在如下 现有SIP报头"record-route"、 "via"、 "route"和"contact"的其中 之一中将指定的业务模块的端口号添加到应用服务器的地址来提供该端口号。通常可以在应用服务器处不同的输入端口上接收输入的服务请 求。然后应用服务器可以优选地基于在应用服务器哪个端口号上接 收到请求来应用负载平衡功能或端口映射功能。在一个实施例中， 当在应用服务器处至少一个预定的端口号上接收到初始请求时，应 用服务器应用负载平衡功能。例如，可以在第一预定端口号上接收 根据发起请求的第 一 业务情况的初始请求，可以在第二预定端口号 上接收根据终止请求的笫二业务情况的初始请求，以及可以在笫三 预定端口号上接收根据终止请求/未注册的第三业务情况的初始请 求。而且，当在第四预定端口号或更高预定端口号上接收到根据第四业务情况的后续请求时，应用服务器可以应用端口映射功能。在另 一个实施例中，可以基于应用服务器在哪个端口号上接收 请求而在指定的业务模块的不同输入端口上提供输入的服务请求， 以便区分不同的业务情况。例如，可以在指定的业务模块的第一输入端口上提供应用服务器的第一预定端？号上接收的初始请求；可 以在指定的业务模块的笫二输入端口上提供应用服务器的第二预定 端口号上接收的初始请求；可以在指定的业务模块的笫三输入端口 上提供应用服务器的第三预定端口号上接收的初始请求；以及可以 在指定的业务模块的第四输入端口上提供应用服务器的第四预定端 口号或更高预定端口号上接收的初始请求。根椐另一个方面，提供一种处理输入的服务请求的应用服务器， 该应用服务器包括一组相等业务模块，每个相等业务模块能够处理 对应用服务器中实现的一个或多个多媒体服务的请求。该应用服务 器还包括用于确定接收的服务请求是初始服务请求还是相同会话中 的先前服务请求之后会话中的后续服务请求的部件。本发明的应用服务器还包括负载平衡单元，该负载平衡单元适 于应用基本能够在一组业务模块中选择任何业务模块的负载平衡功 能来指定业务模块用于处理接收的初始服务请求。该应用服务器包 括用于发送对初始服务请求的响应的部件，该响应包含与指定的业 务模块关联的端口号。该应用服务器还包括端口映射单元，该端口 映射单元适于应用端口映射功能以确定该组业务模块中与接收的后 续服务请求中给出的端口号关联的特定业务模块，用于处理接收的 服务请求。该应用服务器可以属于IMS服务网络，然后通常根据SIP协议 来传送服务请求。在该情况中，发送部件优选地适于通过在如下现 有SIP才艮头"record-route"、 "via"、 "route"和"contact"的其中之 一中将指定的业务模块的端口号添加到应用服务器的地址来提供该 端口号。 该应用服务器可以适于在不同输入端口上接收输入的服务请 求。在该情况中，应用服务器还可以适于基于在哪个端口号上接收 请求来应用负载平衡功能或端口映射功能。在一个实施例中，该应 用服务器适于当在至少一个预定的端口号上接收到初始请求时，应 用负载平衡功能。例如，该应用服务器可以适于在第一预定端口号 上接收根据发起请求的第一业务情况的初始请求，在第二预定端口 号上接收根据终止请求的第二业务情况的初始请求，以及可以在第 三预定端口号上接收根据终止请求/未注册的第三业务情况的初始请 求。然后应用服务器还可以适于当在第四预定端口号或更高预定端 口号上接收到根据第四业务情况的后续请求时应用端口映射功能。在另一个实施例中，应用服务器可以适于基于在哪个端口号上 接收请求而在指定的业务^t块处的不同输入端口上提供输入的服务 请求，以便区分不同的业务情况。例如，应用服务器可以适于在指 定的业务模块的第 一输入端口上提供第 一预定端口号上接收的初始请求；在指定的业务模块的第二输入端口上提供第二预定端口号上 接收的初始请求；在指定的业务模块的第三输入端口上提供第三预 定端口号上接收的初始请求；以及在指定的业务模块的第四输入端 口上提供第四预定端口号或更高预定端口号上接收的后续请求。 从下文的详细描述将显见到本发明的其他特征和优点。


现在将参考附图更详细地描述本发明，其中 图1是可以使用本发明的基本通信方案的示意图概况。 图2是根据现有技术的应用服务器群的框图。 图3 ^部图示根据本发明解决方案的多i某体服务网络的框图， 该多媒体服务网络包括用于处理输入的服务请求的应用服务器。 图4是当接收到初始服务请求时图3中的应用服务器的框图。 图5是当接收到后续服务请求时图3、中的应用服务器的框图。
图6是局部图示根据一个实施例的应用服务器的详细框图。 图7是局部图示根据另一个实施例的应用服务器的详细框图。 图8是图示根据本发明解决方案用于处理服务请求的基本过程 的流程图。
具体实施方式
作为开始，现在将参考图3简要描述本发明的解决方案，图3 局部地图示了一个多媒体服务网络，其中S-CSCF节点300连接到配 置成执行一个或多个预定多媒体服务的应用服务器302。 S-CSCF节 点300可以连接到配置用于不同多媒体服务的多个此类应用服务器。 在本示例中，节点300、 302都包括在IMS服务网络中，如上文结合 图l描述的，但是本发明的优选实施例的下文描述基本不局限于IMS 概念。首先在S-CSCF节点300中接收来自订户的输入的服务请求R, 然后将其转发到应用服务器302。根据下文描述，S-CSCF节点300 适于将输入的请求转发到应用服务器302中特定的TCP或UDP端 口 。应用服务器302包括负载平衡功能单元304、端口映射单元306 和一组相等业务冲莫块308 (表示为TM1、 TM2、 TM3、 TM4、...)， 每个业务模块能够处理对应用服务器中实现的一个或多个多媒体服 务的请求。此处，术语"相等业务模块"意味着每个业务模块具有 用于处理服务请求和执行服务的基本相同能力，但是这些业务模块 并不一定在其他方面恰好具有相同的配置。因此，基本可以由该业 务牙莫块组中的任何业务才莫块来处理输入的服务请求。如上文解释的， 期望将处理负载均匀地分布在业务模块上，但是也期望提供一种简 单而仍旧可靠的机制以使具体会话中的所有请求由相同的业务模块 来处理。输入的请求是具体会话中的"初始"或"后续"请求，即第一 请求或该第一请求之后的另一个请求。因此可以通过向应用服务器 发送初始请求来调用其中的一个或多个服务而开始会话。根据本解决方案，将所有初始请求R:转发到负载平衡单元304，并将所有后 续请求Rs转发到端口映射单元306。负载平衡单元304适于指定业 务^^莫块308的任何一个业务;f莫块用于处理输入的初始请求，而端口 映射单元306适于指定特定的业务;^莫块308用于处理输入的后续请 求。负载平衡功能可以基于例如轮叫调度或随机选择，并且本发明 不局限于此。在接收到初始请求之后，指定的业务模块通常将某种类型的响 应发送回请求订户或请求方(下文称为"请求者，，)。常^L方式下， 将所有服务请求定向到对应的应用服务器的网络地址，例如 (sip:userA⑥asl.叩eratorX.net )。但是本发明解决方案提供一种就指 定的业务模块的身份通知请求者以使该会话内的任何后续请求可以 直接被定址到指定的业务才莫块的方式。在应用服务器302以及还有S-CSCF节点300的输入端处，提 供特定输入端口 (在这些输入端口上接收请求)，每个输入端口具有 特定端口号或身^f分。在端口映射单元306中，每个业务才莫块与对应 于该业务模块的内部专用网络地址的特定端口号相关联，这些特定端口号在附图中表示为对于TM1为(-001),对于TM2为(-002) 并以此类推。在接收并处理内部初始请求之后，在响应中将与指定 的业务模块关联的端口号提供给请求者。在使用SIP信令的优选实施例中，指定的业务模块可以通过常 规情况下在对服务请求的此类响应中出现的现有称为"record-route"、 "via"、 "route"和"contact"报头的任何一个报头中将其端口号添 加到应用服务器的地址中来在响应中提供它的端口号。由此，可以 容易地利用现有的SIP报头来用于将端口号信息传回给请求者。如果请求者后来在相同的会话期间发出后续请求，则在发送后 续请求时，将指定的业务^f莫块的接收端口号添加到目的地地址，例 如(sip: userA@asl.operatorX.net:4004 )，以^f更再次到达相同的业务才莫 块，4004是添加的端口号。在S-CSCF节点300处所指示的端口上 接收后续请求意味着，这实际是定向到与给定的端口号关联的业务 模块的后续请求。因此，S-CSCF节点300将在应用服务器302处指 示的TCP/UDP端口上转发请求至端口映射单元306。端口映射单元 306然后将端口号映射到对应业务^^莫块的内部专用网络地址，例如端 口号4004可以映射到业务^^莫块TM1 (-001)，并向此传输请求。图4图示在请求者(未示出)发出对即将来临的多媒体会话的 第一服务请求时的业务情况示例，该请求可以是IMS上下文中的SIP INVITE或SIP SUBSCRIBE消息。在第一步400中，由S-CSCF节 点300接收该请求。如杲该请求的目的地地址字段中未包含与任何 特定业务^f莫块关联的端口号，则该请求是初始请求，由此在步骤402 将其传输到应用服务器302中的负载平!軒单元304。接下来，负载平衡单元304应用负载平衡功能来基本指定该序 列的业务模块308中的任何业务模块来处理该请求。所应用的负载 平衡功能可以配置成在选择适合的业务模块时将各个业务模块上的 当前工作负载纳入考虑，但是这属于本发明范围之外。在该示例中， 负载平衡功能为指定而选择业务才莫块TM3,并在下一步404将请求 转发到此处。业务才莫块TM3然后处理请求，其中涉及会话数据的建立，其中 一些会话数据可以从本地存储在业务^t块TM3中的中央订户数据库 (例如图1中的HSS 112)中提取。如上文背景技术部分中解释的， 此会话数据或信息在后续请求时使用是必需的。此后，在最后一步406中，使业务才莫块TM3向请求者发送回适 合的响应，通常以适合的方式将该响应路由通过S-CSCF节点300， 本文无需对此进行进一步的描述。在该响应中，业务冲臭块TM3添加 它自己的关联的端口号，而接收请求者将保存该端口号以供后来使 用。如上所述，可以在常规情况下对服务请求的此类响应中出现的 现有称为"record-route" 、 "via" 、 "route"和"contact"净艮头的任何 一个报头中将该端口号添加到应用服务器的地址。图5图示在图4的业务情况示例之后请求者在相同的多々某体会 话期间发起后续服务请求时的另 一个业务情况示例。在先前业务情 况中，已指定业务才莫块TM3来处理该特定会话中来自该特定请求者 的初始请求，并且应该容易地使用本地存储的会话数据/信息继续对 后续请求进行如此操作。因此在第一步500中，在S-CSCF节点300 处从请求者接收后续请求。此时，将请求定向到与指定的业务模块 TM3关联的端口号并在该端口号上接收请求，该端口号是上文在步 骤406中请求者已在对初始请求的响应中接收到的端口号。因此， 在与特定业务模块关联的端口号上接收当前请求意味着，该请求是 后续请求，因此在步骤502中，在导向到端口映射单元306的所述 端口上传输该请求。在步骤504中，接收端口映射单元306然后将该端口号映射到 对应业务才莫块的内部专用网络地址，在本例中为TM3 (-003 )，并向 此传输请求。业务^f莫块TM3然后使用已经建立且本地存储的会话数 据来处理该请求。最后，与上文图4的业务情况中一样，业务;^莫块TM3 在步骤506中向请求者发送回响应，该响应同样优选地将关联的端 口号包含在record-route报头中。或者，可以在步骤506的响应中省 略端口号，因为仅在步骤406中的笫一响应消息中包含该端口号就 足以确保请求者将所有后续请求发送到该具体业务一莫块。图6图示应用服务器302的优选实施例，该应用服务器302包 括多个TCP/UDP输入端口 Pl 、 P2、 P3、 P4、 P5、 P6、…，其中前三 个端口 Pl-P3连接到负载平衡单元600，余下端口P4、 P5、 P6…连接 到端口映射单元602。如上文解释的，S-CSCF节点300确定要将输 入的请求传输到应用服务器302的哪个输入端口。如果检测到该请 求是初始请求RP则将其传输到三个端口 Pl-P3的其中之一。在另 一方面，如果该请求是后续请求Rs，则基于该请求的目的地地址字 段中包含的端口号将其传输到其他端口 P4、 P5、 P6、...的其中之一。
当根据3GPP实现当前SIP协议时，根据三个不同主业务情况， 使发送请求者将它的服务定址到应用服务器302中以及S-CSCF节点 中的不同TCP/UDP输入端口，三个不同主业务即l)定址笫一端 口用于发起请求，即当请求终端是主叫终端时，2)定址第二端口用 于终止请求，即当请求终端是^R叫终端时，以及3)定址笫三端口用 于终止请求，并且当被叫移动终端是已知的但是未作为IMS网络中 的活动客户注册时。在后一个业务情况中，仍可以通过呼叫转发等 来接收传送的多媒体。在该上下文中，将包含按上文描述的可以应 用端口映射功能的端口号的任何后续请求视为第四业务情况。就此给定的SIP调度而言，可以采用如下方式配置应用服务器 302。前三个端口 Pl-P3都不与任何具体业务一莫块关联，因此将这些 端口连接到负载平衡功能以用于基本指定业务模块的的任何一个业 务才莫块，因为所有初始请求都将被定向到那些端口号P1-P3的其中之 一。另一方面，余下端口 P4、 P5、 P6、…的每一个端口与特定业务 模块关联，并因此连接到端口映射单元602,因为在请求者接收到与 最初指定的业务模块关联的端口号(主要在第一请求响应中接收到) 之后，后续请求将^f皮定向到那些端口号P4、 P5、 P6.,.的其中之一。 在所示的示例中，端口号P4与业务;f莫块TM1关联，端口号P5与业 务模块TM2关联，端口号P6与业务模块TM3关联，并以此类推。如本领域中公知的，如果由于某种原因未在接收者处接收到对 初始请求的响应，则必须重发该请求。因此，如果应用服务器接收 到接收最初请求的第 一 次指定的业务模块未应答而重发的初始请 求，并且为重发的请求指定另一个业务模块，则可能出现最终两个 不同的业务模块无协调地响应请求的情况。通过本发明的解决方案 安全地处理这种冲突，因为请求者的行为将通过将后续请求仅定址 到业务模块中与给定端口号关联的业务模块来确定哪个业务模块将 处理相关会话的后续请求。后来不参与该会话中的被忽略的业务模 块将不知道这一点，但是将只会永不接收该会话内的任何后续请求。 存储在被忽略的业务模块中用于该会话的会话数据将最终通过常规 操作过程来清除，例如基于超时功能最终将其清除。图7图示应用服务器302的另一个实施例，其中示出前三个端 口 Pl、 P2、 P3连接的负载平衡单元500和余下端口 P4、 P5…连接的 端口映射单元602。在该附图中，仅示出一个业务模块，它本身基本 具有四个输入端口 p:A、 P:B、 P:C和P:D以便按如下方式区分不同 的业务情况。应该理解可以采用相似的方式配置应用服务器302中 的其他业务^t块。在该实施例中，业务4莫块700中的端口 P:A配置 成根据结合图6描述的第一业务情况(即在端口 Pl上发起请求)接 收初始请求，端口 P:B配置成根据第二业务情况(即在端口 P2上终 止请求)接收初始请求，以及端口 P:C配置成根据第三业务情况(即 在端口 P3上终止请求/未注册)接收初始请求。根据第四业务情况，保留业务^f莫块700中的第四端口 P:D用于 端口映射单元602在与该具体业务^t块700关联的端口号(在本例 中为端口 P4)上接收的后续请求。因此，端口 P:A-P:C任一个上接 收到的请求经过负载平衡功能进行处理，而在端口 P:D上接收到的 请求直接被映射到业务模块700。应该容易地理解在本发明的范围内可以修改负载平衡单元600、 端口映射单元602和业务才莫块700、 308的任何一个。例如，可以将 负载平衡单元600仅连接到业务4莫块700中的一个输入端口，该输 入端口配置成4妻收任何初始请求而不考虑业务情况。而且，端口映 射单元602可以配置成将一个端口号映射到多于一个业务一莫块，或 将多于一个端口号映射到同 一个业务模块等。因此本发明并不局限 于参与方的任何特定端口配置。最后，现在将参考图8的流程图普遍性描述本发明用于处理服 务请求的过程。本文示出的该过程步骤基本由多媒体服务网络中的 应用服务器来执行，该应用服务器(例如结合图3-7描述的应用服务 器302)包括多个业务模块。在第一步800中，通常从请求者接收服务请求。通常，根据上文描述的IMS配置在应用服务器中的特定端口上接收请求，但是本发明不专有地局限于此。在下一步802中，基本确定该请求是初始请求还是后续请求， 这优选地通过将该请求定址到的端口号来给出。例如，如上所述， 参考上文图6和图7描述的配置，端口号1-3可以指示初始请求，而 端口号4和更高端口号可以指示后续请求。如果请求是初始请求， 则在步骤804中应用能够基本选择任何业务模块的负载平衡功能， 以指定用于处理初始请求的业务模块。然后，在步骤806中由指定 的业务模块处理该请求。但是如果在步骤802中发现该请求是后续 请求，则在步骤808应用能够确定与请求中给定的端口号关联的特 定已指定的业务模块的端口映射功能，以用于处理后续请求。然后， 在步骤810中，相应地由确定的业务才莫块处理该请求。然后，在接 下来步骤812中，可以确定请求是否需要响应。如果不需要，则过 程可能按指示的结束。在步骤806中处理初始请求之后，并且在步骤812之后，如果 确定需要对接收的后续请求的响应，则在步骤814中创建响应，该 响应包括与指定/确定的业务模块关联的特定端口号指示。该端口号 优选地在根据SIP协议的现有报头中给出，例如在"record-route"、"via"、 "route"和"contact"中给出。最后在步骤816中将响应发 送到请求者。或者，如果请求是后续请求(即在步骤812之后)，则可以在步 骤814从响应中省略端口指示，因为请求者大概已经从会话的第一 初始请求之后给出的响应中知道要使用哪个端口号。在一些情况中 步骤810中处理的后续请求可能完全不需要响应，如"结束"框中 指示的。自然地，在步骤812或步骤816之后，通过返回到第一步 骤800接收另一个请求时重复该过程。通过上述解决方案，为输入的多媒体服务请求提供有效率地将 处理负载分布在应用服务器内的业务模块群上。当在可伸缩群中指
定业务模块时还将时延和复杂性降至最小，并使传输过程筒单且仍 旧可靠。具体来说，如果服务请求中出现与具体业务模块关联的端 口号，则该请求是后续请求，可以容易地将其传送到该业务才莫块来作进一步处理。当使用SIP时，具体优点是负载平衡功能和端口映射功能对于SIP应用层实际是不可见的，这使该解决方案可应用于TCP和DDP传输。 "via"、 "route"和"record-route"报头是强制报头字段，但是任何 应用均不将其用作调用任何服务逻辑的基础。因此， 一旦建立了这 些报头字段，则从不操作它们，使它们对于SIP应用是不可见的。而且，该应用服务器可以配置成使给定端口号明确地指向特定 业务才莫块的内部专用网络IP地址，这使该机制不受任何正在进行的 对应用服务器的重新配置的影响，例如添加或移除业务模块等的情 况时不受影响。而且，安全地避免了重发请求的情况中涉及多于一 个响应业务模块的沖突。例如，该应用服务器可以将对话转移到新 业务模块，然后重新自行配置，以使端口映射将指向不同于旧业务 模块的新业务^^莫块。事实上，端口映射功能涉及对话状态实例，而 非涉及应用逻辑或甚至物理服务器。虽然本发明是参考特定示范实施例来描述的，但是该描述仅意 在说明本发明的概念，并且不应视为限制本发明的范围。在不背离 所附权利要求定义的本发明精神的前提下可以使用多种替代、修改 和等效物。
权利要求
1.一种在应用服务器中处理输入的服务请求的方法，所述应用服务器包括一组相等的业务模块，每个业务模块能够处理对所述应用服务器中实现的一个或多个多媒体服务的请求，所述方法包括如下步骤-接收会话的服务请求，-确定所接收的服务请求是初始服务请求还是所述会话中在先前服务请求之后的后续服务请求，以及在初始服务请求的情况中-应用基本能够选择所述一组业务模块中的任何业务模块的负载平衡功能，以指定业务模块用于处理所接收的服务请求，以及-发送对所述初始服务请求的响应，所述响应包含与所选并指定的业务模块关联的端口号，或在后续服务请求的情况中-应用端口映射功能来确定所述一组业务模块中与接收的后续服务请求中给出的端口号关联的特定业务模块，用于处理所接收的服务请求。
2. 如权利要求1所述的方法，其特征在于，所接收的后续力良务 请求指示中给出的端口号已经包含在对先前服务请求的较早响应 中。
3. 如权利要求1或2所述的方法，其特征在于，所述应用服务 器属于IMS服务网络，以及根据SIP协议来传送所述服务请求。
4. 如权利要求3所述的方法，其特征在于，通过在如下现有SIP 报头"record-route" 、 "via"、 "route"和"contact"的其中之一中将 所述端口号添加到所述应用服务器的地址中，在对所述初始服务请 求的所述响应中提供所指定的业务才莫块的所述端口号。
5. 如权利要求1-4中任一权利要求所述的方法，其特征在于， 在所述应用服务器处不同的输入端口上接收输入的服务请求。
6. 如权利要求5所述的方法，其特征在于，所述应用服务器基 于在所述应用服务器处哪个端口号上接收到请求来应用负载平衡功 能或端口映射功能。
7. 如权利要求6所述的方法，其特征在于，当在所述应用服务 器处至少一个预定的端口号上接收到初始请求时，所述应用服务器 应用负载平衡功能。
8. 如权利要求7所述的方法，其特征在于，在第一预定端口号 (1)上接收根据发起请求的第一业务情况的初始请求，在第二预定端口号(2)上接收根据终止请求的第二业务情况的初始请求，以及 在第三预定端口号(3)上接收根据终止请求/未注册的笫三业务情况 的初始请求。
9. 如权利要求8所述的方法，其特征在于，当在第四预定端口 号(4)或更高预定端口号上接收到根据第四业务情况的后续请求时， 所述应用服务器应用端口映射功能。
10. 如权利要求5-9中任一权利要求所述的方法，其特征在于， 基于所述应用服务器在哪个端口号上接收请求而在所指定的业务才莫 块的不同输入端口上提供输入的服务请求，以便区分不同的业务情 况。
11. 如权利要求8-10所述的方法，其特征在于，-在所指定的业务模块的笫一输入端口 (P:A)上提供所述应用 服务器的所述第一预定端口号上接收的初始请求，-在所指定的业务模块的第二输入端口 (P:B)上提供所述应用 服务器的所述第二预定端口号(2)上接收的初始请求，國在所指定的业务it块的第三输入端口 (P:C)上提供所述应用 服务器的所述第三预定端口号(3)上接收的初始请求，以及-在所指定的业务模块的笫四输入端口 (P:D)上提供所述应用 服务器的所述第四预定端口号(4)或更高端口号上接收的初始请求。
12. —种用于处理输入的服务请求的应用服务器，包括- 一组相等业务;f莫块，每个业务模块能够处理对所述应用服务 器中实现的一个或多个多i某体服务的请求'，-用于确定接收的服务请求是初始服务请求还是相同会话中的 先前服务请求之后会话中的后续服务请求的部件，-负载平衡单元，所述负载平衡单元适于应用基本能够在所述 一组业务模块中选择任何业务模块的负载平衡功能来指定业务模块 用于处理接收的初始服务请求，-用于发送对所述初始服务请求的响应的部件，所述响应包含 与所指定的业务模块关联的端口号，以及-端口映射单元，所述端口映射单元适于应用端口映射功能来 确定所述一组业务模块中与接收的后续服务请求中给出的端口号关 联的特定业务才莫块，用于处理所述接收的服务请求。
13. 如权利要求12所述的应用服务器，其特征在于，所述应用 服务器属于IMS服务网络，以及根据SIP协议来传送所述服务请求。
14. 如权利要求13所述的应用服务器，其特征在于，所迷发送 部件适于通过在如下现有SIP报头"record-route" 、 "via"、 "route" 和"contact"的其中之一中将所指定的业务^t块的端口号添加到所述 应用服务器的地址来提供所述端口号。
15. 如权利要求12-14中任一权利要求所述的应用服务器，其特 征在于，所述应用服务器适于在不同输入端口上接收输入的服务请 求。
16. 如权利要求15所述的应用服务器，其特征在于，所述应用 服务器基于在哪个端口号上接收到请求来应用负载平衡功能或端口 映射功能。
17. 如权利要求16所述的应用服务器，其特征在于，所述应用 服务器适于当在至少一个预定的端口号上接收到初始请求时应用负 载平衡功能。
18. 如权利要求17所述的应用服务器，其特征在于，所迷应用 服务器适于在第一预定端口号(1)上接收根据发起请求的第一业务 情况的初始请求，在第二预定端口号(2)上接收根据终止请求的第 二业务情况的初始请求，以及在第三预定端口号(3)上接收根据终 止请求/未注册的第三业务情况的初始请求。
19. 如权利要求18所述的应用服务器，其特征在于，所述应用 服务器适于当在第四预定端口号(4)或更高预定端口号上接收到根 据第四业务情况的后续请求时应用端口映射功能。
20. 如权利要求15-19中任一权利要求所述的应用服务器，其特 征在于，所述应用服务器适于基于在哪个端口号上接收所述请求而 在所指定的业务模块的不同输入端口上提供输入的服务请求，以便 区分不同的业务情况。
21. 如权利要求18-20所述的应用服务器，其特征在于，所述应 用服务器适于-在所指定的业务模块的第一输入端口 (P:A)上提供所述第一 预定端口号(1)上接收的初始请求，-在'所指定的业务模块的第二输入端口 (P:B)上提供所述第二 预定端口号(2)上接收的初始请求，-在所指定的业务^t块的第三输入端口 (P:C)上提供所述第三 预定端口号(3)上接收的初始请求，以及-在所指定的业务模块的第四输入端口 (P:D)上提供所述第四 预定端口号(4)上接收的初始请求。
全文摘要
一种用于处理输入的服务请求的方法和设备，其中应用服务器(302)包括一组业务模块(308)，每个业务模块(308)能够处理至少一个预定多媒体服务。当从请求者接收初始服务请求时，应用能够在该业务模块组中基本选择任何业务模块的负载平衡功能(304)，以指定该业务模块组中的业务模块来用于处理接收的服务请求。在处理请求之后，向请求者发送响应，该响应包含与所指定的业务模块关联的端口号。当接收到包含端口号指示的后续服务请求时，应用端口映射功能以确定与给定的端口号指示关联的早期指定的业务模块以用于处理所述后续服务请求。
文档编号H04L29/06GK101156409SQ200680011186
公开日2008年4月2日 申请日期2006年3月22日 优先权日2005年4月4日
发明者A·丹尼, M·帕尔梅特 申请人:艾利森电话股份有限公司