自适应业务提供的NGN业务体系结构项目调研论文（Draft4）

状态感知通信应用系统设计

 

 

摘要：

本文设计了一个能够自动感知用户可用性状态的应用系统。通过这个系统，用户可以获知其他用户的在席性与可用性状态，以及和其他用户的最佳通信方式。文章提出了系统的实体架构，并给出了一个企业业务实例。

关键词：状态感知，在席性与可用性管理，Parlay，OSA

 

 

1．    引言

现有的通信方式中，人们可以通过电话、电子邮件、SMS短消息和网络即时聊天软件（IM）等方式进行通信，这些通信方式都是从某一个侧面提供不同程度的用户信息交互，是相互独立的系统。电话虽然具有很好的实时性，但是只能提供相当有限的被叫方状态信息。即时消息客户端一般只是通过PC机的在线状态来判定对方的状态，但是这种判定往往不能准确确定对方的可用性。当研究人们在办公室的行为时发现，人们会时常离开桌上电脑，走到办公室的其他位置或是离开办公室，在席和可用状态经常更改，这时某一联系方式就不一定能联系到该用户，这就希望通信方式也能随着人的状态的改变而改变。从而需要考虑到两个概念——在席与可用，Parlay 4.0规范中定义了在席与可用性管理（PAM）的业务能力特征。根据Parlay 4.0的定义，在席最初是简单的在线与离线状态，而后又扩大到和状态相关的其他上下文信息（如外出就餐）以及活动状态（接听电话、发呆等），PAM规范扩大了在席的概念，指定所有的描述实体存在性的上下文信息都包含在在席信息中，包括位置信息。可用性是反应取决于一特定环境中用户进行通信的意愿，通常由被请求的通信类型以及发出请求的其他用户的身份所决定。在大多数情况下，在席是可用所必须的，而在席并不意味着可用。

在现有的即时通信软件中，搜集和判别用户的在席性与可用性状态的方法大都都是通过客户端的在线状态和PC机的活动状态，即用户是否通过客户端登陆到服务器，PC机的键盘是否被按下、鼠标是否被移动等，如ICQ、MSN等即时通信软件。这种方式比较单一，实时性差，有一定的局限性，不能准确判断用户的在席与可用的状态。

在现在的Parlay 4.0规范中对用户状态已经有了一定的定义和描述，当前的PAM规范也已经基本完善，OSA的Final draft ETSI ES 202 915-14 V1.2.1 (2005-01)中对在席与可用性管理的SCF(Parlay 4)已经有了明确的定义，API规范、类和函数的定义及数据类型也基本完善。

本文提出了使用状态感知的方式搜集和判别用户的在席与可用性状态，该方式融合了传统的在席与可用性状态感知的方法和新提出的上下文感知的状态感知方法，设计了运用该方式的通信应用，我们称其为状态感知在席可用性（SaPA）系统。该系统可以自动搜集用户的在席与可用性信息，对用户的当前状态做出准确的判断。

 

2．  系统需求

状态感知的系统要求系统能够自动的搜集用户的状态信息，并对用户的在席性与可用性做出准确的判断。

2 ．1       状态的定义

状态（State）包括用户两大类信息：在席信息和可用性信息。Parlay规范4.0中定义了用户的状态参数，如表1。包含联机/脱机（在线/离线）的状态，联机表明用户通过客户端软件登陆到了服务器上，脱机表明用户没有登陆。在线的状态中还包括忙和其他自定义的用户状态信息。

表1        Parlay 4.0规范中定义的用户状态参数

用户状态	状态的描述
Online	用户为联机
Offline	用户为脱机（移动终端调至关/其他终端没有连接到服务），或希望被显示为脱机
Busy	用户正忙
Other	自定义的用户状态信息可以由additionalUserStatusInformation得到

在席对应与联机，是由用户是否使用服务决定的，即用户登陆到提供服务的应用服务器上后状态就为在席。用户可以按照自己的意愿设定自己的状态，一般情况下用户的可用性是不断的变化的，即从Online－>Other－>Busy－>Other－>Offline，而用户并不可能每次在自己状态改变的时候记得手动地设定客户端上显示的可用性状态，这就需要我们设计出一种软件可以自动的探测到用户的状态，即状态感知，并对用户的状态进行搜集。

2 ．2       感知状态的方法

状态感知可以通过多种途径，以往都是通过在线与离线或PC机的活动状态来感知用户的状态，如前面提到的MSN、ICQ等即时通信软件，该感知方式比较单一，而且准确性和实时性差。SaPA系统是新的状态感知方法和传统的感知方法相结合的产物，主要分为3类感知方法：基于规则的状态感知方法、基于感应器的状态感知方法以及基于活动性的状态感知方法。

基于规则（rule-based）的状态感知方法可以通过用户终端上的日程表，即用户可以自行设定特定时间段内的可用性状态，将日程表上的时间和客户端软件的可用性状态关联，比如每天中午12:00-12:30为用户吃中饭的时间，那么可以通过一定的方式将此时间段与自定义的“外出就餐”这个状态关联起来，这样每到中午12:00用户终端就会自动将其可用状态设为“外出就餐”，等到12:30时又自动将状态变为联机或其他设定好的状态。

基于感应器（sensor-based）的状态感知方法可以通过一些特殊的感应设备，比如终端上可以安装摄像头来判断用户是否离开；终端上还可以安装麦克风，通过声音的识别来判断用户的状态，如是否有电话铃声响等。这些实体我们统称为感应器（Sensor）。

传统的基于活动性（activity-based）的状态感知方法已经相当的成熟，如果终端在PC上，则可以通过PC的活动性搜集用户的在席与可用性信息。如当键盘和鼠标在一定时间内没有人按下或触摸的话，就自动将状态变为用户事先自定义好的状态，如离开。

采用多种状态感知方法结合的SaPA系统可以更准确更实时的搜集到用户的状态信息，从而提供更灵活的自适应业务。

2 ．3       系统平台

       SaPA系统必须适应各种平台，即具有平台无关性。考虑到JAVA语言的跨平台优势，该系统平台采用JAVA语言开发， Final draft ETSI ES 202 915-14 V1.2.1 (2005-01)里定义了PAM的API规范。该平台还要考虑到与状态感知的结合，需要将状态感知得到的在席与可用性信息通过PAM API传递到业务层。考虑到Parlay的开放型和可扩展性，我们在该系统中选择Parlay/OSA的平台作为架构，利用Parlay/OSA的PAM业务能力服务器提供PAM API与业务层进行交互。

 

3.  开放式业务 API

在最新的Final draft ETSI ES 202 915-14 V1.2.1 (2005-01)中，PAM API规范得以完善。

PAM接口的目的是建立一个用来保存和发布信息的标准，发布的信息是关于数字身份，特征和代理在席状态（代表通信、内容传送等的实际能力），实体的状态和能力，各种通信方式以及使其可用的上下文环境的实体的在席性可用性。

PAM的主要目标是加快多种通信系统（如，即时短消息、email，传真、电话等）的一系列应用软件和服务的开发进程，并且使终端用户更加弹性机动地控制其通信方式。软件开发人员可以在一个标准化的平台上开发通信管理软件，使得这些软件独立于现在的技术和协议。

Parlay规范版本4.0中定义了API规范，包含呼叫控制、用户交互、策略管理、连接管理、在席性与可用性管理等API，这里我们主要用到了在席性与可用性管理API，即PAM API。

 

4 ． 系统的设计

根据以上的需求，我们利用Parlay平台对系统进行架构，系统的实体架构如图1所示。

图1  系统架构

图2中，业务层主要是提供业务的应用程序，可以是第三方开发的业务，也可以是网络运营者自己提供的业务，这些业务可以在一个或多个应用服务器上实现。

业务能力服务器SCS向业务应用程序提供承载网的服务能力特征SCF，这些SCF是下层网络能力的抽象定义，如呼叫控制、用户定位、在席与可用性管理等都被抽象成SCF。框架与业务能力服务器属同一层，框架主要功能是鉴权、业务发现、SCS注册、事件通知等。业务能力服务器SCS主要有三种，主要向业务层提供用户位置、呼叫控制及在席性可用性管理API。虽然一般每个API对应一个特定的SCS，如呼叫控制SCS，但 一个SCS可以实现多个API。SCS作为逻辑实体它不需要单独实现。例如基于内容计费API由计费服务器自己直接提供。PAM API中包含了在席与可用信息的更新通知等。

状态管理器通过解释器将感应器搜集的各种形式的信息映射为以上定义的状态信息，如果实时性较强的感应设备在解释后还需要加速器，最后将这些状态信息通过接收器送给状态管理器，且这些交互都是双向的。

感应器在我们设计的系统架构中主要是能够感知状态的设备或实体。日程表中必须含有用户在某一时刻的标准状态信息，所谓标准的状态信息是在状态管理器中预先定义好的信息，这些信息可直接提交给状态管理器。比如用户今天10:00-12:00在参加一个会议，那么通过日程表中的记录可直接获取该时段用户的状态信息。

PC的活动性是判断在席与可用性的传统方法，PC机可向状态管理器提交可用性信息，但中间必须通过解释器，将PC机提交的状态信息解释为标准的可用性状态，解释器的作用就是接受下层提供的状态信息，将搜集到的状态信息解释为标准状态信息。

装在通信设备上的感应器可以搜集用户的活动状态信息，并将这些信息送给解释器，解释器将这些状态信息映射为标准状态信息，送给聚合器。聚合器主要是搜集多个感应器送来的标准状态信息。最后标准状态信息通过聚合器送给状态管理器。

Parlay/OSA平台的业务能力服务器提供在席性与可用性管理的业务能力，并提供PAM的API，状态管理器通过这些API与业务层进行交互。业务层通过业务能力服务器获得用户的状态信息，向用户好友的客户端提交用户的标准状态信息，并通过分析这些信息，得出用户那通信方式可以联系的上，并给出最佳联系方式。

4 ．1       鉴权的使用

作为OSA业务之一，PAM使用OSA框架的鉴权功能来提供PAM接口的访问控制。另外，PAM提供了一个可选的机制用于业务级的鉴定和实体请求操作或被请求的行为的操作的鉴权。

举一个简单的实例，通过OSA框架鉴权而访问业务接口的实体请求操作。一般的，代理服务器或应用服务器（比如消息服务器或会议服务器）会通过OSA框架进行一次鉴权，而后检查不同的客户端的在席性与可用性（如即时短消息客户端）。PAM业务需要的鉴权证书可以由各接口方法的鉴权证书参数提供。

请求者数据的机制是通过TpPAMCredential类型的可选参数提供的。在每一个方法中提供整个请求者数据对于实现来说是非常的昂贵的，因为这必须每次都要对请求者所数据结构中提供的数据进行解析和验证。单个应用程序可以访问多个方法，且需要在每个实例中提供相关的请求者数据。为了更有效的考虑请求者的数据，在每个请求者的每次会话时，应用程序在SCF中的每个管理器中调用getAuthToken()方法，并得到可以在同一请求者的同一会话中重复使用多次的鉴权证书。

鉴权的顺序图如图2：

图2        鉴权顺序图

1：对任何请求操作的单个实体，通过鉴权的OSA PAM业务客户端在在席与可用性管理接口中调用getAuthToken()方法请求鉴权标记。

2：getAuthToken()方法返回的标记作为getIdentityPresence()请求的鉴权证书的参数使用。

3：相同的标记也作为getAvailability()请求的鉴权证书的参数。一个鉴权标记可以在OSA框架建立的同一对话中被使用多次。

4 ．2       事件的注册与通知

       OSA客户端能够在PAM业务中为其或其客户端注册特定的事件。通过时间管理服务，一个客户端可以注册一个或多个应用接口，并为每个已注册的接口激活一个或多个事件。

       顺序图如图3：

图3        事件注册与通知的顺序图

1：客户端运用registerAppInterface()方法来注册其通知事件接口。档客户端正在自行注册时，getAuthToken()可以为空。客户端取回一个唯一的客户端ID。

2：客户端使用getAuthToken()为其应用软件客户获得到鉴权证书。

3：客户端调用registerForEvent()方法来对其客户端事件可用性的改变进行注册。客户端取回唯一的事件ID。

4：身份的在席信息被其他的客户端应用程序通过调用setIdentityPresence()方法改变。

5：当在席性改变导致注册了可用性改变的客户端身份的可用性的改变，通知将通过使用先前注册的应用程序接口被发送出去。

4 ．3       状态感知与提交

       含有PAM SCF的SCS通过状态感知得到用户的在席与可用性状态。通过getIdentityPresence()和getAvailability()请求，通过解释器、聚合器、接收器和状态管理器一层层提交到PAM SCS，PAM SCS提供在席与可用性管理的业务能力特征，通过setIdentityPresence()和setAvailability()通知客户端状态信息。交互图如图4。

图4        状态感知交互

5 ．业务实例

业务描述：我们将这种由状态感知得出可用性的技术用于企业中，将公司中的固定电话、移动电话、PC等多种通信设备关联起来，便于公司中的员工和管理者更快更方便的知道自己公司人员的状态信息，公司中的每一个人都可以通过SaPA系统的客户端得到公司其他人员的当前状态，并可以知道通过何种方式联系到公司其他的人员。比如，当用户在户外时，最佳的联系方式是通过手机等移动终端；又如当用户正在开会，周围没有PC和固定电话，而且用户又不希望接听电话，最佳的联系方式是手机短信。我们要求系统将这种最佳的联系方式通知和该用户处于同一域中的其他用户，即有其他用户的好友列表中存在该用户的话，该用户的最佳联系方式及那些通信方式可用都将通知其他用户。我们要求用户得到的并不仅仅是好友直接的在席与可用性信息，而是系统通过PAM判断做出的好友的可用联系方式和最佳联系方式。当用户注销了客户端后，业务层也就停止服务，这样在职员下班后也保护了其隐私。

该业务的实现如图3，最上层的应用服务器提供应用层所需的程序，包括客户端应用程序。呼叫控制SCS提供电话呼叫的业务能力，在席与可用性管理SCS，提供在席性与可用性管理的业务能力，框架提供业务的发现与鉴权功能。手机、PDA等移动通信设备通过GSM/UMTS网与上层交互，电话通过PSTN网与上层交互，而PC则通过IP分组交换网与上层交互。固定电话上装有摄像头可以感知到是否有人正在使用电话，装上分辨率高的智能摄像头甚至可以分辨出谁在使用电话。

在该业务中，我们可以定义标准的状态信息，如表2。

表2        标准状态信息对应表

代号	标准状态信息	描述
AtDesk	办公中	表明用户在自己的办公桌前
Phoning	接听电话	用户正在接听电话
Out	外出	用户不在公司里
Meeting	会议中	用户正在会议室开会
Lunching	用餐	用户正在餐厅用餐
DepartmentX	在第X个部门/房间	用户当前的位置
Logout	离线	用户没有登陆客户端

 

业务的架构及信令流程如图4所示：

图4    结合不同的SCS实现业务

       我们用该架构实现一个公司人员状态自动感知的业务，该业务架构实体间交互的信令流程步骤为：

1）用户打开客户端软件，登陆到应用服务器，通过业务层向框架进行注册，请求访问呼叫控制SCS和用户在席性与可用性管理SCS。

2）框架通过鉴权，通过验证，允许业务层访问SCS，向SCS请求好友列表，并向业务层返回好友实例参数，用户客户端获得已添加的同事列表。

3）接下来提交用户的可用性状态信息：业务层向在席与可用性管理SCS发出请求，要求提交用户的状态信息。

4）在席与可用性管理SCS向状态管理器请求获得用户的标准状态信息。

5）状态管理器中的接收器向下层请求，有直接请求访问日程表，有通过解释器向PC发出请求，也有通过聚合器向解释器再向下层的感应器请求。

6）日程表向接收器提交标准状态信息；PC向解释器提交状态信息，解释器将其解释为标准状态信息后提交给接收器；感应器向解释器提交信息，经过解释器翻译后得到标准状态信息，提交接收器，这样状态管理器便获得用户的标准状态信息。

7）状态管理器将所获得的用户的标准状态信息提交用户状态SCS。通过调用IpPAMIdentityPresence中的getIdentityPresence()方法和IpPAMAvailability中的getAvailability()方法实现。

8）用户状态SCS向业务层发出通知，通知用户其状态信息已经提交服务器数据库，并将用户的好友列表中同事的状态信息提交给业务层，这样用户客户端上便可以显示其同事的标准状态信息。

9）当用户的一个同事的状态面板上显示其电话的通信方式可用的话，用户则可以向其同事拨打电话，则业务层向呼叫控制SCS发出请求。

10）呼叫控制SCS连接到PSTN网对目标电话号码进行呼叫。

 

5 ．结论

这一阶段主要对状态感知的架构模型做了一定的分析，设计了一个应用在企业中的状态感知的实例。下面我们的工作将要对业务的实现具体化，进行业务的仿真、API的调用等等。

在席性和可用性的管理可以使通信更加弹性化，用户可以有更大的空间选择自己的通信方式，是消息的收发可以按照用户自己的意愿进行，环境感知可以改变现有的许多通信方式的缺点，使现有的通信系统提供更多的自适应业务。

6．            参考资料

1）  JAIN Presence and Availability (PAM)，javadoc

2）An Example of Using Presence and Availability in an Enterprise for Spontaneous, Multiparty, Multimedia Communications—Hyong Sop Shim, Chit Chung, Michael Long, Gardner Patton and Siddhartha Dalal Applied Research, Telcordia Technologies New Jersey, USA

3）  rfc2778-A Model for Presence and Instance Messaging

4） Presence versus Availability： The Design and Evaluation of a Context-Aware Communication Client—James Fogarty，Jennifer Lai, Jim Christensen 2004

5）OPENING THE NETWORKS WITH PARLAY / OSA : STANDARDS AND ASPECTS BEHIND THE APIS Ard-Jan Moerdijk1 and Lucas Klostermann2，IEEE Network Magazine.