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

位置 / 状态感知系统的设计与分析

 

 

摘要：

本文主要是自适应业务系统项目中的一部分，文中设计了一个能够自动的感知用户位置和可用性状态的系统，通过这个系统，用户可以得知其他用户的在席性与可用性状态，以及和其他用户的最佳通信方式。文章给出了这种系统的实体架构，并举了一个将该业务用于企业中的实例，使得企业中的职员可以高效的联系自己的同事。

关键词：位置感知，状态感知，在席性与可用性管理，Parlay平台

 

Abstract: This paper is a part of the auto-adapt service system project, in which a system that can auto aware user’s location and availability state is designed. In the system, users can obtain the presence and availability state of the other users as well as the best way to contact the others. The entity architecture is presented in this paper, and an application instance is described which makes members of the company can contact their colleagues more efficiently.

Key words: Location-aware, State-aware, Presence and Availability Management, Parlay platform

 

1．    引言

现有的通信方式中，人们可以通过电话、电子邮件、SMS短消息和网络即时聊天软件（IM）等方式进行通信，这些通信方式实时性各不相同，且相互分离。电话有其一定的局限性，通常无法提供同事的状态信息，人们也不希望在对方忙碌或者开会的时候去打扰人。即时消息客户端一般都是仅通过PC机的活动状态来估计在席性，询问同事的可用性，但是这种估计对于准确判断同事是否可用还远不足。

当研究人们在办公室的行为时发现，人们会经常的离开桌上的电脑，走到办公室的其他地方或者离开办公室，在席和可用状态经常更改，这时某一联系方式就不一定能联系到该用户，于是我们提出了一个系统，能够自动的搜集和共享同事的可用性信息，并告诉用户哪些联系方式可以联系到其他用户。

这里我们设计一个由位置/状态感知搜集可用性信息的系统（SaPA），使得系统可以自动搜集用户的在席与可用性信息，对用户的当前位置和状态做出准确的判断。

2．  系统需求

状态/位置感知的系统要求系统能够自动的搜集用户的状态信息，并对用户的在席性与可用性做出准确的判断。将用户的在席与可用性状态通知其余的用户，并根据该用户的状态自动的选择出一种联系该用户的方式，比如，当用户在户外时，最佳的联系方式是通过手机等移动终端；又如当用户正在开会，周围没有PC和固定电话，而且用户又不希望接听电话，最佳的联系方式是手机短信。我们要求系统将这种最佳的联系方式通知和该用户处于同一域中的其他用户，即有其他用户的好友列表中存在该用户的话，该用户的最佳联系方式及那些通信方式可用都将通知其他用户。我们要求用户看到的并不是好友的直接的在席与可用性信息，而是系统通过判断做出的好友的可用联系方式和最佳联系方式。

2 ．1       状态的定义

状态（State）是指用户的在席性与可用性状态，包含在线/离线的状态，在线表明用户通过客户端软件登陆到了服务器上，离线表明用户没有登陆。在线的状态中还包括可用、离开、忙、外出就餐、接听电话等等。状态为可用表明该用户可以联系上，离开则表示虽然用户登陆了，但是用户的终端在地理位置上和用户分离，即用户离开了终端，此时用户的终端能够接受消息，但用户也许无法回复消息；状态为忙表示用户正在处理重要的事情，虽然终端就在用户身边，用户也可以立即收到消息，但用户也许没有时间进行通话或回复；外出就餐、接听电话则更具体的描述了用户的状态，表明了用户虽然此时无法回复消息，但几分钟或几十分钟之后用户也许状态会变为可用。

表1在席和可用与各状态之间的对应

用户状态		状态的描述
离线		用户没有登陆，服务停止
在线（在席）		用户通过客户端软件登陆到了服务器上，可以进行服务
在线 的几 种特 殊状 态	可用	该用户可以联系上，即可以通话，可以回复等
	离开	用户离开了终端，此时通信可以建立，但无法联系对方
	忙	用户正在处理重要的事情，也许没有时间进行通话或回复
	外出就餐	暂时不可用，但在一会儿之后会变的可用
	接听电话	暂时不可用，但几分钟后可以联系

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

2 ．2       感知状态的方法

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

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

如果终端在PC上，我们可以仿照现有的即时消息软件（如QQ、MSN）来通过PC的活动性搜集用户的在席与可用性信息。如当键盘和鼠标在一定时间内没有人按下或触摸的话，就自动将状态变为用户事先设定好的状态，如离开。

2 ．3       平台

       考虑到JAVA语言的跨平台优势，该平台使用JAVA语言，PAM的API采用JAIN PAM API的规范。该平台还要考虑到与位置/状态感知的结合，需要将通过位置/状态感知到的在席与可用性信息通过PAM API传递到业务层。考虑到Parlay的开放型和可扩展性，我们在该系统中选择Parlay/OSA的平台作为架构，利用Parlay/OSA的业务能力服务器提供PAM API与业务层进行交互，通过业务层的应用软件给出用户的可用的通信方式，并做出最佳联系方式的判断。

2 ．4       客户端

       系统的客户端要求实现以下几个功能：

       用户可以通过客户端添加自己的好友，管理自己的好友列表。

       对于每个好友，客户端必须显示出好友的头像、好友的通信方式（我们在这儿假设每个好友拥有4种通信方式，即电话、即时短消息、SMS、电子邮件）。

       客户端必须能够显示用户的好友哪些通信方式可用、哪种联系方式最佳，如果没有一种通信方式是可用的话，那就是好友为不在线。

图1        好友的可用性面板

       图1中，好友面板显示好友A的四种联系方式中，电话、IM、邮件为可用的，由于没有登记手机，SMS短消息是不可用的。系统根据好友A的当前状态（如正在电脑面前，登陆了IM的软件）判断出联系好友A的最佳状态为即时短消息IM。随着好友的位置/状态的改变，好友面板上的可用通信方式和最佳联系方式也会发生改变。

 

3.  系统中使用的 API

在席的概念已经在一些应用领域中使用了，最直接的是用在实时消息。从一个最简单的在线/离线状态的概念出发，在席所包含的信息是描述个体当前的在线状态以及个体接受各种通信方式的能力。比如，在席可以描述一个人在一特定时间是否可以接电话或者收发即时消息（IM）。在席的概念已经扩大为状态中包含其他上下文环境信息，如离开（外出就餐、离开电脑等等）和活动状态（通话中、发呆等）。另一方面，本地信息很大程度上与传统考虑的在席所包含的信息分离。PAM规范扩大了在席概念的范围，认为所有这样的信息，包括位置信息，描述了实体在席的不同的上下文环境。比如用户希望通过何种介质传送信息，以及用户当前的地理位置信息等等。其一致的特性就是在席信息不断的在变化，以及在业务和应用的不同时刻得知当前信息。

可用性是实体身份的性质，是反应特定上下文环境中用户进行通信的意愿，通常由被请求的通信类型以及发出请求的其他用户的身份所决定。例如，当一个即时消息（IM）的用户可以接受来自同样网络的其他用户的消息时，但是事实上他不想让其他人知道他在线，他不想收到其他人发给他的信息，那么这时该用户相对于这种网络的通信方式是不可用的。

在大多数应用中，在席是可用所必需的，但是在席并不意味着所有的都是可用的。可用性往往和上下文环境息息相关，PAM规范中，上下文环境是指一系列定义可用性状态的属性。如可用的通信方式、类型，请求者的身份等。

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

Parlay版本4.0、3GPP OSA Release 5以及ETSI ES 202 915定义了API的规范，包含呼叫控制、用户交互、策略管理、连接管理、在席性与可用性管理等API，这里我们主要用到了在席性与可用性管理API，即PAM API。

 

4 ． 系统的设计

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

图2  系统架构

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

业务能力服务器SCS向业务应用程序提供承载网的服务能力特征SCF，这些SCF是下层网络能力的抽象定义，如呼叫控制、用户定位、在席与可用性管理等都被抽象成SCF。相同的SCF有可能由不同的SCS提供，如呼叫控制SCF可以由CAMEL的SCS提供，也可以由MExE(Mobile Station Application Execation Environment)的SCS提供。SCS是逻辑的概念，可以分布在不同的物理节点上，如用户定位SCF、呼叫控制SCF、在席与可用性SCF等可以在一个物理节点实现，也可以分布在不同的物理节点中实现。SCS是连接物理层网络实体与上层业务层之间的接口。

框架与业务能力服务器属同一层，框架主要功能是鉴权、业务发现、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 ．业务实例

业务描述：我们将这种由位置/状态感知得出可用性的技术用于企业中，将公司中的固定电话、移动电话、PC等多种通信设备关联起来，便于公司中的员工和管理者更快更方便的知道自己公司人员的位置和状态信息，公司中的每一个人都可以通过SaPA的客户端得到公司其他人员的当前状态和位置，并可以知道通过何种方式联系到公司其他的人员。当用户注销了客户端后，业务层也就停止服务，这样在职员下班后也保护了其隐私。

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

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

表2        标准位置/状态信息对应表

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

 

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

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

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

1）用户打开客户端软件，登陆到应用服务器，通过业务层向框架进行注册，请求访问呼叫控制SCS和用户状态/位置SCS。

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

3）接下来提交用户的可用性状态信息：业务层向用户状态/位置SCS发出请求，要求提交用户的位置/状态信息。

4）用户状态/位置SCS向位置/状态管理器请求获得用户的标准状态/位置信息。

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

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

7）位置/状态管理器将所获得的用户的标准位置/状态信息提交用户位置/状态SCS。

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.