CN1183732C

CN1183732C - 网络中的业务系统

Info

Publication number: CN1183732C
Application number: CN99814630.7A
Authority: CN
Inventors: M·劳滕巴赫
Original assignee: Siemens AG
Current assignee: Nokia Solutions and Networks GmbH and Co KG
Priority date: 1998-12-16
Filing date: 1999-12-14
Publication date: 2005-01-05
Anticipated expiration: 2019-12-14
Also published as: CN1330829A; WO2000036803A1; EP1142262B1; ATE416550T1; DE69940027D1; EP1142262A1; ES2318907T3

Abstract

在网络中用于实现用户业务的系统必须能够为更快速发展的终端硬件而应付不断变化的用户业务。这个目的通过在实现业务中的功能分割得以实现。用户业务的提供通过在网络核心的服务器完成，而用户业务的执行通过在网络边缘的终端完成。

Description

网络中的业务系统

1、介绍

在基于IP的通信网络(用于电信和/或数据)中，网络设备厂商将通过提供分布式网络业务(例如，QoS、安全、可靠性、漫游、远程访问、...)来增强基本-IP的连通性，而使他们的产品增值。

独立的第三方公司将为客户机/服务器提供网络应用(例如，通信、协力完成工作、电子商务、联机游戏、远程教学、...)，这些客户机/服务器透明使用网络基础设施，使其仅仅作为基于开放标准和规程的传送设施。

前面提到的事实要求灵活的体系结构，用于在传送电信和数据(汇聚的网络)的基于IP的网络中提供和执行用户业务。

2、现有技术

在用于用户业务供给的现有解决方案中，例如在象GSTN(全球交换电话网)这样的电信网络中，用于用户业务供给和执行的智能在一些网络实体中被统一和集中起来：

·在本地交换机LX情况中(提供“基于交换的业务”)业务处理与正常的呼叫处理紧紧耦合在一起。

·在智能网(IN)情况中呼叫处理是分开的。业务交换功能(SSF)和业务控制功能(SCF)结合在一起，用于通过对一个呼叫中所有经过点的检测和通过呼叫状态的交换来处理业务。

在GSTN中，所述的用户业务被称为补充业务。一般地，当使用“基本”电话业务时，这些补充业务使需要人工完成的过程自动化。换句话说，补充业务是使基本电话呼叫更方便的特点。

3、本发明

下一代基于IP的网络将有两个重要特征：

·用户的移动性(具有或不具有他们的终端)

·多种智能终端(PC、PDA、膝上机、具有Java虚拟机(JVM)的移动电话、...)

这些特征驱动着用户和网络的利益需求：

用户需求：

·移动用户的漫游与他们虚拟家庭环境(VHE)的透明共同迁移组合在一起。VHE是用户已预订应用的个人集合，关于这些应用是如何配置和捆绑为用户业务包的其个人选项，以及关于他想如何对这些用户业务的使用进行付费的个人选择。

·智能通信终端，例如PC、PDA、膝上/掌上机、具有Java虚拟机(JVM)的移动电话等。

·一个用户不可以被限制为使用一个单一型号的智能终端，与此相反，一个用户将要求使用在某个地方最适当的或可用的任何智能终端。

·尽管终端随意愿改变，但用户总是想要具有同样的可用服务，而不论使用的具体终端装置如何。

网络需求：

由于基于IP的网络的灵活特性，所以运行在智能终端上的可能应用和用户业务的数目是很大的。编程人员基于便宜、现用的平台为智能终端(例如，PC)不断实现新的思想。

为了适应更快速发展的终端硬件，用于提供用户业务的体系结构必须能够应付不断变化的应用和用户业务。由于网络边缘变化如此之快，在网络的核心提供和执行用户业务将变得不可能。核心设备要经受比客户级的低成本边缘设备(终端)更严格的要求，并且因此更加昂贵。在核心设备上创建应用和对应的用户业务(如在因特网电话中的补充业务)在技术上和经济上都将不能跟上在低廉的边缘设备上新应用和用户业务的快速创建。

本发明的目的是解决所述的问题。

接下来，通过参考7个附图，并借助于实施例的几个例子，本发明得到说明。

图1：在下一代网络中用于供给用户业务的体系结构单元。

图2：在“空闲”状态用于供给用户业务的体系结构：当用户使用他的智能终端连接到一个网络接入点上时，准备允许用户用其特定的业务简档进行操作。

图3：分步业务递送：(用户认证(“用户标识到业务简档”映射(“业务简档到应用包”映射(用户特定应用包的递送。

图4：业务递送完成：用户准备使用他的用户业务个人简档。

图5：应用执行环境(AXE)的详细视图。

图6：因特网电话的最小体系结构。

图7：因特网电话中补充业务的体系结构。

本发明的主要思想是在实现业务时的功能分割：

用户业务的提供(例如，启动、归档、分布、管理和用户业务的计费)保留在网络的核心中，而用户业务的执行则委派给位于网络边缘的智能终端。

由于至今终端已经发展为强大的处理单元，所以将用户业务的执行委派给网络边缘的智能终端，在经济和技术上是合理的。然而用户业务的提供(例如，启动、归档、分布、管理和用户业务的计费)保留在网络的核心中。

技术上这是通过相应的具有至少一个中央应用服务器的客户机/服务器体系结构来实现的，该中央应用服务器保存可以按要求下载至用户终端的应用程序的拷贝。

这种在用于电信和/或数据的下一代基于IP的网络中提供用户业务的体系结构满足了所有上述的用户和网络要求。

本发明最佳地利用了存在于这样的网络中的两个智能源，：

·网络单元(例如路由器和交换机)中的分布智能，为基本的IP连通性增值。

·端系统(客户机、服务器)中的智能，允许多种先进的应用。

这是“网络智能”的新概念，它不同于用于GSTN的传统IN中的解释，在GSTN中智能只是存在于中心实体中。在那里终端仅仅是没有任何处理能力的低智能电话机。

随着终端由于技术进步而变成强大的处理单元，本发明的一个实施例包含一个相应的应用执行环境(应用执行部分)，该应用执行环境适用于很多种智能终端并且使得向多种不同的智能终端委派业务的执行能够在技术上很灵活。

专业术语

用户业务是为最终用户提供的业务，来自于网络了解的应用的交互作用，所述应用运行在网络边缘的智能终端的IP模型第3层以上(典型的甚至在IP模型第5层以上)。例如，电子邮件、WWW、伙伴列表、因特网电话、...

网络业务为“IP传输”的基本业务增值。这些业务由运行在网络中的网络单元在IP模型的第2层和第3层提供。例如：Qos、安全、VPN、...

本发明涉及为基于IP的智能终端提供用户业务的体系结构，而不涉及网络业务的提供。

为了解释本发明，把基于IP的网络看作仅仅提供IP连通性的实体便足够了。该网络被看作一个提供非具体网络业务的纯传输网络。

3.1通用结构

3.1.1结构单元

通用结构包含如图1所示的少数网络实体：

基于IP的智能终端：

这是一个拥有自己的IP地址、存储器和某种CPU的网络实体。在不久的将来，智能终端将是各种工作站、PC、膝上和掌上机、IP-(视频)电话机、电视机顶盒、移动通信装置，它们运行某种操作系统并遵循摩尔定律，即每18个月将装备更加强大的CPU。每个这样的终端理解几种Java变体。今天，Java虚拟机(JVM)已经是大多数操作系统的标准组成部分或者镶嵌在用于小装置的专用硅片中，这样的小装置象移动通信装置。

现在和将来会有许多种终端可被用户使用。每个这样的终端将有远超过今天电话机的更多“智能”。这里提出的体系结构将因此通过委派用户业务给这个“自由和空闲的智能”而利用它。

网络接入点

取决于所考虑的专门智能终端，网络接入点是一个LAN连接器、ISP的一个拨号POP点、一个膝上/掌上机的对接单元、用于移动通信的一个基站等。在提出的体系结构中网络接入点的唯一用途是提供IP网络的连通性。

考虑到用户从一个接入点漫游到另一个接入点的可能性，获得动态分配的IP地址而同时在PC、膝上机、移动通信装置、...之间交换的可能性，该接入点不处理高级的任务，象认证或任何其他用户特定的事情。

用户业务商

如果将用户业务的执行委派给智能终端，并且网络接入点仅仅提供纯的IP连通性，那么纯粹用户业务执行以外的智能必须保存在其他地方。这就是用户业务商。用户业务商作为用户特定信息的中心源，用户特定信息是指用户ID、认证数据、预订用户业务的简档、计费信息等。它也在专用库(详细解释见下一节)中保存可执行的应用的“主要拷贝”。用户业务商提供为用户供给业务所需的所有逻辑但不实际完成业务。

在GSTN的现有传统IN中，用于业务供给和执行的智能被统一和集中在几个网络实体中。这与这里提出的解决方案相反，在这里提出的解决方案中智能被分离和分散：用户业务的供给通过用户业务商集中处理，用户业务的实际执行被委派给分布的智能终端。

3.1.2用于供给和执行用户业务的分布式模型

3.1.2.1“空闲”状态

图2说明在“空闲”状态的体系结构。用户业务商连接到网络，用户的智能终端(PC、膝上机、移动通信装置、...)可能或不可能经由网络接入点连接到网络。在这一点上用户业务商把任一情况下的终端看作“离线”(在图2中用斜体字表示)状态。

用户业务商保存一份用户ID(UID)的列表。一个UID唯一标识一个用户并且间接把用户和某个预选择的应用包关联起来。将关于应用的确切选择的信息作为UID相关的业务简档，在用户业务商上为每个单个用户保存。

用户业务商也维护一个应用库，它基本上是存储在适合的数据库系统中的应用程序集。每个程序实现自主式的用户业务，或者实现这种业务的一些增值的补充特征(例如：自主式业务可以是用于移动通信请求者的“只有文本的网页浏览”，补充特征可以是对同一请求者的“网页浏览的可选图形支持”)。程序得到实现使得它们的一个实例能够从库中按要求下载到用户的智能终端中，用于执行。这可以通过Java这样的技术取得。

一个用户通过相应地改变与其UID相关的业务简档的配置，能够在库中预订(取消)任意的可用应用程序。当用户终止了他的会话或当用户使其智能终端离线时，会将这个业务简档的更新传播到用户业务商以便永久保存。不是将业务简档存储在用户智能终端上来允许在不同的智能终端之间轻松漫游或交换。通过把业务简档集中保存在用户业务商上，用户可以一直获得同样的业务简档，而无论他是从他的办公室PC、公用信息亭、移动通信装置还是家中来接入网络。从一个地点/终端生成的业务简档更改将在任意其他地点/终端自动可用。业务简档随着用户通过不同的地点和端系统透明迁移的概念被称为虚拟家庭环境(VHE)。

3.1.2.2业务递送

采用这种体系结构的业务递送如图3所示，所包含的步骤如下：

(1)用户认证

在用户能使用任何业务之前，他必须通过向业务商提供其UID(和相关的密码/PIN)来认证自己。在永久连接的PC的情况下，认证能够通过敲相应的按键来完成。在膝上机或移动通信装置的情况下，当所述装置连接到网络接入点时认证能够自动完成。

(2)“UID到业务简档”映射

在UID(深灰色三角形)通过验证之后，它被映射到相应的用户业务简档。业务简档(浅灰色圆圈)表示用户的个性化的应用包，从应用库中的可用应用全集(深灰色圆圈)中编辑而来。经由业务简档用户能够创建其非常个性化的VHE。简档不是静态的而是可由用户直接通过其智能终端进行定制和管理。

(3)“业务简档到应用包”映射

根据在用户业务简档中的信息，用户业务商确定了在应用库中可用应用的一个子集。已确定的子集(圈起来的深灰色圆圈)是个性化的用户业务包。

(4)用户特定的应用包的递送

最后一步是通过从网络下载已选择的应用包到用户智能终端中。Java软件技术的设计了恰恰考虑了这种程序下载能力。当通过网络传送代码时所涉及的问题象平台独立、效率和安全等是Java设计的完整组成部分。与其在智能终端上日益增加的可用性一起，这种能力使得Java成为主要侯选对象来支持这种体系结构，用于此文件中所讨论的用户业务的递送。

3.1.2.3“就绪”状态

图4说明在“就绪状态”的体系结构，它是业务供给过程的最后阶段。启动已预订的用户业务的这些程序已经下载到他的智能终端中并在那里等待着它们的调用和执行，

3.1.3优点

由于端系统变得装备有更加强大的处理器，所以通过使业务在端系统上执行而不是在一些中央的网络实体上执行来利用这种能力是非常合理的。限制自身于业务递送问题而不是执行问题，而使中央网络实体面临不那么紧迫的升级问题。

此外，采用这个方法，中央网络实体(如用户业务商)可以置于智能终端如PC、膝上机、移动通信装置等的快速技术变化循环之外。如果关于智能终端的业务具体细节变化，则仅仅要更新应用库的程序中受影响的模块。用户业务商与其用户管理、认证、应用库和递送功能作为一个整体根本不受影响。这种对用户业务供给的模块化方法通过动态装载Java中所需可用类得到很好的支持。甚至不必替换整个程序而仅仅替换受影响的类文件。

3.1.4应用执行环境(AXE)

随着以可下载应用程序的形式委派到智能终端的用户业务的执行，设计一个相应的、与许多种技术上不同的智能终端共同工作的应用执行环境变得越发重要，这个应用执行环境因此被实现作为虚拟机，例如Java虚拟机。虚拟机必须被移植到每个被支持的终端仅仅一次。对应用而言，在所有被支持的终端上虚拟机看起来是相同的。

在一个运行微软公司的windows操作系统的PC的情况中，图5说明了智能终端的相应详细视图。

实现特定用户业务的下载应用程序是Java小应用程序(深灰色圆圈)。这些程序在智能终端的应用执行环境(AXE)中执行。与用户的通信经由一个被所有的用户业务共享的图形用户接口(GUI)来完成。已下载的程序限制在AXE(被称作“沙箱”方法)中，并且除了通过特定的AXE API之外不与低层软件层通信。依赖平台的、与视窗DLL之间的连接通过Java/COM接口用AXE API命令作为输入得以实现。对于每个被支持的智能终端，这个接口必须只写入一次(例如，用C++)。该接口在采用Java实现的平台独立的用户业务和终端的实际操作系统及硬件之间形成特定的链接。

3.2因特网电话的补充业务的体系结构

在用于因特网电话的补充业务的情形中，它演进了第3.1节中的通用体系结构。

3.2.1前提条件

3.2.1.1状态Quo

当今，因特网电话仍一直缺少在全球交换电话网(GSTN)的智能网络(IN)方法中提供的精细补充业务集。因特网电话主要用于提供对GSTN上电话的模拟。

3.2.1.2因特网电话的最小体系结构

图5说明一个最小配置，通过该配置可以进行因特网电话(并且，特别是微软(MS)的Netmeeting)呼叫。

在其中，需要三个PC：因特网定位服务(ILS)服务器和发起及终接终端站。终端站积极参与通信会话，把音频流(以及，可选地，视频流或数据)转换为能在因特网中传送的格式的代码。

ILS(因特网定位服务)服务器作为配置中的目录服务器。该节点存储着关于“登录”的用户的信息。经由ILS，用户与因特网主机相关联，且因特网主机运行因特网电话应用，这样就作好了对进入的呼叫请求作出响应的准备。当用户请求发起一个因特网电话呼叫时，一个地址查询就随着其预定通信者的“别名”(通常是电子邮件标识)发送到目录服务器。ILS接着以用户当前相关联的IP地址作出反应。

3.2.1.3因特网补充业务的不同特征

采用因特网电话使补充业务的多种不同特征成为可能，而它们在GSTN情形中是不可用的：

因特网电话的补充业务是应用

在这里值得注意的重要一点是用户业务(在这种特定情形中是因特网电话的补充业务)与运行在智能终端上的应用相关联，而不是与一些中央的网络实体相关联。

简单业务用法

因特网的使用允许在补充业务供给中的许多复杂性得以避免。在GSTN中需要用户交互的许多业务都要求建立到专门资源(如通告单元和DTMF音调解码器)的临时连接，并且对于要被向上发送到业务处理器的获取的任何信息都采用独立的数据链路。由于在因特网上能够假定用户与一个终端站相关联，所有这些得以避免，该终端站允许字符和图形被显示出来，并且该终端站能够直接发送复杂的消息，而不是限制到一个简单的小键盘。

将业务处理委派到功能强大的端系统

当提供补充业务时因特网的使用有另一种含义。因特网主机是计算机，因此当然几乎都有功能强大的处理器。这就产生了在终端站进行大多数处理功能的可能性，而不是象GSTN中要求的那样由于在POTS电话中欠缺本地智能而依赖网络节点(如LX或IN)。

通过与标准IT应用组合而形成的高级补充业务

基本因特网电话与其他因特网应用如电子邮件的组合允许有另一个完全不同的真正高级补充业务集。

3.2.2体系结构

这里提出的体系结构在因特网电话的补充业务的情况下实现和扩展了第3.1节中的更通用的体系结构。

该体系结构涉及一种支持因特网电话的补充业务供给的体系结构。它与为基本因特网电话呼叫提供解决方案无关。这个功能取自一些现有的因特网电话应用包如微软(MS)的NetMeeting。

建议的体系结构包括一个基础设施，用于向终端站分发业务逻辑(以Java小应用程序的形式)，并用于允许业务逻辑和它的管理基础设施以分布式形式操作(既在终端站中又在分离的服务器中)。分布式业务逻辑支持前面提到的因特网电话应用包把并与该应用包交互作用。

图7说明提供因特网电话的系统的一般构架结构，该结构中的其中一个终端站(图的右侧所示)也增强了对因特网电话的补充业务的支持。该体系结构包含如下实体：

用户终端站

两个终端站运行现用的MS NetMeeting因特网电话应用包，其中至少一个应用由J/Direct接口和应用执行环境(AXE)加强。

ILS服务器

服务器提供目录服务，把象征性的用户别名(例如电子邮件地址)翻译为用户的当前IP地址。ILS被使用于允许方便的记住电话“号码”并因此支持用户方便地建立呼叫。

用户业务商

用户业务商作为一个用于因特网电话补充业务的库。所述业务作为预编译程序(以Java小应用程序的形式)存储，每个都实现特定业务逻辑。根据用户的要求，这些业务逻辑单元下载到用户的终端站中，在那里执行。用户业务商也跟踪哪个用户被授权使用哪种补充业务。

当用户请求一个具体的因特网电话补充业务时，Java小应用程序以及相应的业务逻辑从业务商下载到AXE，AXE位于用户的因特网电话应用包的上面。小应用程序运行在AXE中并根据该小应用程序的业务逻辑通过J/Direct接口驱动电话应用包。J/Direct接口允许业务逻辑接入基础应用包的因特网电话库。

3.2.3重要特征和优点

·提出的解决方案不涉及包含在进行呼叫(该功能由所使用的基础因特网电话包提供)时的基本过程。而该解决方案的一部分是标准接口的供给，该接口使得补充业务能够与所有的电话包以同样的方式交互作用，而在业务中不需要任何特定于包的代码并同时保持业务/包尽可能简单地交互作用。

·具有从中央服务器下载一个用户特定的小应用程序集到用户的端系统的能力。

·具有限制用户可接入的补充业务并对用户使用的业务进行收费的能力。

·具有执行已下载程序的能力，这些程序在一个安全的环境中在用户的机器上实现补充业务集，而不论机器平台如何。

·一种总体控制过程，它允许多个潜在冲突的补充业务同时执行而不出现问题。用户能够分配和改变业务集内业务的相对优先级并因此修改如何解决潜在冲突。

·由用户配置已下载业务集中的单个补充业务的能力。这个配置包括设置业务特定的参数，设置补充业务集中业务的相对优先级以及基于临时性而启动和禁止单个业务的能力。

3.2.4因特网电话的补充业务样本

在提出的体系结构中，能提供因特网电话的多种补充业务：因特网电话补充业务的样本集列在下面，目的是组合电子邮件和因特网电话。根据是主叫还是被叫使用业务，该业务能够被分群为“发起”和“终接”业务。

在被叫方占线时的电子邮件选择(发起)

当被叫者已经在通话中时，这个发起业务被触发。尽管用户可以明确拒绝所给出的呼叫，但结果(不能通信)是相同的，并且该业务在两种情况下都是足够的。主叫方被问到他是否想改为发送电子邮件。如果主叫方作出肯定回答，则业务的其他部分继续进行。由NetMeeting所建立的会议和呼叫对象保持着关于被叫用户别名的信息，并且这被用于建立一个模板，由主叫方填入电子邮件。该模板显示在用户接口上，并且在输入电子邮件内容后，它被提交出去以便传输。这暗含着业务逻辑必须包括一个小电子邮件客户机，向SMTP服务器发送电子邮件。

被叫方占线时的计时重试(发起)

在前面的情况下，当从远端被叫者接收到呼叫拒绝时，这个补充业务被触发。然而在这种情况下，将显示一个用户接口对话，询问主叫用户他们是否希望系统以规定的间隔重试被叫方的地址。如果返回答案是“是”，则业务继续。启动计时器，当时间到时，呼叫重新发起。在那以后，业务监测呼叫状态，如果呼叫成功，则用户得到通知。如果呼叫再次失败，则重启计时器，该过程重复。用户接口上的选择被给出以便一旦失败就允许取消该过程，该选择可以作为一个附加特征。

呼叫过滤(终接)

此终接补充业务被用于根据主叫方的身份来处理递送到终端站的呼叫。在这种情况下，它将被用于“自动拒绝”由不在姓名列表中的人们发起的呼叫，该列表被作为一个预业务过程生成。该列表能包括显式的主叫方ID或包含一个机制来拒绝某些呼叫，所述呼叫来自设置了他们的因特网电话客户机不传送他们身份的人们(在NetMeeting情形中，利用了在进行呼叫之前不在ILS服务器登记的便利)。

丢失呼叫的电子邮件通知(终接)

此终接补充业务允许一个用户(被叫方)在不能(或不愿)应答他的因特网电话程序时被通过电子邮件通知给已呼叫他的主叫方身份。该补充业务将从由NetMeeting提供(也标明当前时间)的呼叫数据中提取主叫方的姓名，并且接着制作一个描述此信息的电子邮件。一旦这个电子邮件准备好，它将连接到被叫方的SMTP服务器，把它创建的文本发送出去，并接着最终终止连接。该业务的增强功能能被用于发送其他种类的通知(例如，把一个基于Web的网关联系到GSM短消息业务(SMS)并发送一个带有主叫方身份的SMS消息)。

Claims

1.一种网络中的业务系统包含：

·至少一个存储应用程序的服务器，所述的应用程序实现可以由用户预订的用户业务，所述的服务器以每个用户为基础存储由用户预订的特定业务，

·至少一个可接入到网络的终端，按终端用户要求来请求下载对应于用户预订的业务的应用程序并执行所述的应用程序。

2.在权利要求1中定义的业务系统，其特征在于所述的业务是基本用户业务的补充业务。

3.在权利要求1中定义的业务系统，其特征在于所述的业务是“因特网电话”业务的补充业务。

4.在权利要求1-3任意一个中定义的业务系统，其特征在于可将特定的业务配置成能经由所述的终端由用户进行控制。

5.在权利要求1-3任意一个中定义的业务系统，其特征在于所述的服务器和所述的终端中的Java系统支持所述的应用程序的下载。

6.一种网络中的服务器包含：

·数据库系统，用于存储实现可以由用户预订的业务的应用程序集，并且所述的数据库系统以每个用户为基础将由用户预订的特定业务存储到一个简档中，

·传送部分，用于根据用户预订的业务按终端用户要求来传送应用程序到该终端上。

7.在权利要求6中所定义的服务器，其特征在于所述的业务是基本用户业务的补充业务。

8.在权利要求6中所定义的服务器，其特征在于所述的业务是因特网电话的补充业务。

9.一种网络的终端，

·客户机部分按用户要求来请求从服务器下载应用软件，所述的应用软件实现可以由用户预订的用户业务，

·应用执行部分执行下载的应用软件来执行用户业务和/或用户业务的补充业务。

10.在权利要求9中所定义的终端，其特征在于所述的应用执行部分被实现为虚拟机。

11.在权利要求9或10中所定义的终端，其特征在于配置由用户预订的特定业务能经由所述的客户机部分得以实现。