一个新的状态感知系统分析与设计
南京邮电学院
通信与信息系统专业
张磊
摘要：
本文主要是自适应业务系统项目中的一部分，开始先介绍了在席性和可用性管理，将在席与可用性管理应用在状态感知的业务中，给出了体系架构，并设计出运用在席性和可用性管理进行状态感知通信的业务实例，做了适当的信令业务流程，并罗列了一些业务中可能使用到的API，此业务使用户在通信时更加清楚对方的状态并自由地管理自己的状态及用户之间的通信方式。
Abstract:
1．
概述
现有的通信方式中，人们可以通过电话、电子邮件、SMS短消息和网络即时聊天软件（IM）等方式进行通信，这些通信方式实时性各不相同，且相互分离。电话有其一定的局限性，通常无法提供同事的状态信息，人们也不希望在对方忙碌或者开会的时候去打扰人。即时消息客户端一般都是仅通过PC机的活动状态来估计在席性，询问同事的可用性，但是这种估计对于准确判断同事是否可用还远不足。
当研究人们在办公室的行为时发现，人们会经常的离开桌上的电脑，走到办公室的其他地方或者离开办公室，在席和可用状态经常更改，于是我们提出了一个系统，能够自动的搜集和共享同事的可用性信息，是人们可以使用该信息来决定是否可以启动对话。
这里我们设计一个自适应业务系统，使得系统可以自动搜集用户的在席与可用性信息，即可用状态感知。设计的系统包括状态感知客户端SAC（State-aware Client），业务能力服务器SCS（Service Capability Server）、PAM（在席与可用性管理）API，框架等，该业务是建立在Parlay/OSA平台上，通过Parlay的API中的PAM API以及一些功能实体实现。
2．
系统的功能实体
2．1
Parlay/OSA
的接口
Parlay 版本 4.0、3GPP OSA Release 5 以及 ETSI ES 202 915定义了API的规范，如表1：
表1 Parlay/OSA API
|
Part #
|
API
|
描述
|
|
1
|
通用
|
包含简介、方法论及设计范例
|
|
2
|
公共数据
|
这部分包含了公共数据的定义，如不同API使用的通用数据的类型
|
|
3
|
框架
|
包含API的基础架构，两个域之间的鉴权，所支持的非框架API的发现、注册以及故障管理等。框架的作用将在2.3部分详细说明
|
|
4
|
呼叫控制
|
呼叫控制API族：通用呼叫控制，多方呼叫控制，多媒体呼叫/会话控制及会议呼叫控制API。
|
|
5
|
用户交互
|
用户交互API规范允许业务层从终端用户那儿获取信息、广播和发送短消息等
|
|
6
|
移动性
|
这部分包含的API允许应用软件获得个人身份和位置信息
|
|
7
|
终端能力
|
该API支持获得终端用户的能力
|
|
8
|
数据会话控制
|
该部分的API允许业务层影响由移动终端初始化的数据会话
|
|
9
|
通用消息
|
该部分的API允许访问邮箱和收发消息
|
|
10
|
连接管理
|
该部分定义的API允许业务层控制和改变网络结点之间的服务质量(QoS)
|
|
11
|
帐户管理
|
该部分的API允许业务层询问帐目余额并查找事件的历史记录
|
|
12
|
基于内容的计费
|
该部分包含的API允许业务层对业务提供方收费，如（内容传递）
|
|
13
|
策略管理
|
该API允许设定策略及相关事件策略的注册
|
|
14
|
在席和可用性管理
|
该API允许业务层获得和设定用户的在席和可用性信息
|
2．2
业务能力服务器（
SCS
）
SCS向业务应用程序提供承载网的服务能力特征SCF，这些SCF是下层网络能力的抽象定义，如呼叫控制、用户定位等都被抽象成SCF。相同的SCF有可能由不同的SCS提供，如呼叫控制SCF可以由CAMEL的SCS提供，也可以由MExE(Mobile Station Application Execation Environment)的SCS提供。SCS是逻辑的概念，可以分布在不同的物理节点上，如用户定位SCF、呼叫控制SCF等可以在一个物理节点实现，也可以分布在不同的物理节点中实现。SCS是连接物理层网络实体与上层业务层之间的接口。
2．3
框架
框架是Parlay/OSA平台的一部分，为业务层提供一些基本运作机制，使业务应用程序可以利用承载网络的业务能力。框架部分典型的运作机制为鉴权和发现机制。业务应用程序使用下层承载网络前，必须与框架部分进行鉴权，之后才可以由框架部分提供的发现机制帮助业务应用程序找到适合SCS中的业务能力特征SCF的业务服务器。OSA的业务能力特征SCF及框架提供的运行机制都是用接口API定义的。
2．4
在席与可用管理
API
PAM的主要目标是加快多种通信系统（如，即时短消息、email，传真、电话等）的一系列应用软件和服务的开发进程，并且使终端用户更加弹性机动地控制其通信方式。软件开发人员可以在一个标准化的平台上开发通信管理软件，使得这些软件独立于现在的技术和协议。
在席的概念已经在一些应用领域中使用了，最直接的是用在实时消息。从一个最简单的在线/离线状态的概念出发，在席所包含的信息是描述个体当前的在线状态以及个体接受各种通信方式的能力。比如，在席可以描述一个人在一特定时间是否可以接电话或者收发即时消息（IM）。在席的概念已经扩大为状态中包含其他上下文环境信息，如离开（外出就餐、离开电脑等等）和活动状态（通话中、发呆等）。另一方面，本地信息很大程度上与传统考虑的在席所包含的信息分离。PAM规范扩大了在席概念的范围，认为所有这样的信息，包括位置信息，描述了实体在席的不同的上下文环境。比如用户希望通过何种介质传送信息，以及用户当前的地理位置信息等等。其一致的特性就是在席信息不断的在变化，以及在业务和应用的不同时刻得知当前信息。
可用性是实体身份的性质，是反应特定上下文环境中用户进行通信的意愿，通常由被请求的通信类型以及发出请求的其他用户的身份所决定。例如，当一个即时消息（IM）的用户可以接受来自同样网络的其他用户的消息时，但是事实上他不想让其他人知道他在线，他不想收到其他人发给他的信息，那么这时该用户相对于这种网络的通信方式是不可用的。
在大多数应用中，在席是可用所必需的，但是在席并不意味着所有的都是可用的。可用性往往和上下文环境息息相关，PAM规范中，上下文环境是指一系列定义可用性状态的属性。如可用的通信方式、类型，请求者的身份等。
2．
State-aware
系统的设计
状态（State）是指用户的状态，包含在线/离线的状态，在线表明用户通过客户端软件登陆到了服务器上，离线表明用户没有登陆。在线的状态中还包括可用、离开、忙、外出就餐、接听电话等等。状态为可用表明该用户可以联系上，离开则表示虽然用户登陆了，但是用户的终端在地理位置上和用户分离，即用户离开了终端，此时用户的终端能够接受消息，但用户也许无法回复消息；状态为忙表示用户正在处理重要的事情，虽然终端就在用户身边，用户也可以立即收到消息，但用户也许没有时间进行通话或回复；外出就餐、接听电话则更具体的描述了用户的状态，表明了用户虽然此时无法回复消息，但几分钟或几十分钟之后用户也许状态会变为可用。
表1 在席和可用与各状态之间的对应
|
用户状态
|
状态的描述
| |
|
离线
|
用户没有登陆，服务停止
| |
|
在线（在席）
|
用户通过客户端软件登陆到了服务器上，可以进行服务
| |
|
在线
的几
种特
殊状
态
|
可用
|
该用户可以联系上，即可以通话，可以回复等
|
|
离开
|
用户离开了终端，此时通信可以建立，但无法联系对方
| |
|
忙
|
用户正在处理重要的事情，也许没有时间进行通话或回复
| |
|
外出就餐
|
暂时不可用，但在一会儿之后会变的可用
| |
|
接听电话
|
暂时不可用，但几分钟后可以联系
| |
在席对应与在线，是由用户是否使用服务决定的，即用户登陆到提供服务的应用服务器上后状态就为在席。可用是用户按照自己的意愿设定自己的状态，但是一般情况下用户的可用性是不断的变化的，即从可用－>忙－>离开－>外出就餐－>可用，而用户并不可能每次在自己状态改变的时候记得手动地设定客户端上显示的可用性状态，这就需要我们设计出一种软件可以自动的探测到用户的状态，即状态感知。
终端状态感知的模型如图1所示
|
日程表
|
|
用户终端
|
|
某时间段内用户的状态信息
|
|
感应设备感应到的信息
|
感应设备
图1 状态感知模型
状态感知可以通过多种途径，可以通过用户终端上的日程表，即用户可以自行设定特定时间段内的可用性状态，将日程表上的时间和客户端软件的可用性状态关联，比如每天中午12:00-12:30为用户吃中饭的时间，那么可以通过一定的方式将此时间段与“外出就餐”这个状态关联起来，这样每到中午12:00用户终端就会自动将其可用状态设为“外出就餐”，等到12:30时又自动将状态变为其他。
状态感知也可以通过一些特殊的感应设备，比如终端上可以安装摄像头来判断用户是否离开；终端上还可以安装麦克风，通过声音的识别来判断用户的状态，如是否有电话铃声响等。如果终端在PC上，键盘和鼠标也可以作为感应设备，如当键盘和鼠标在一定时间内没有人按下或触摸的话，就自动将状态变为离开。
我们采用客户端－服务器这种模式建立一个含有在席性和可用性管理的系统，如图2所示：
|
Server
|
|
PAL管理注册
|
|
HTTP代理
|
|
PSTN网关代理
|
|
HTTP代理
|
|
|
|
手机
|
|
PDA
|
|
PSTN网关
|
|
MTCU
|
用户A 用户B 用户C 用户A 用户B 用户C
客户端 通信设备
图2 PAM系统的体系结构
服务器组件中包括PAL管理/注册、HTTP代理服务器、PSTN网关代理。PAL管理注册和HTTP代理服务器形成客户端到服务器的主要接口，而右边的PSTN网关代理服务器、MTCU（多点文本控制单元）、HTTP代理服务器主要负责通信客户端之间的媒体流的控制。
PAL管理注册在系统中保存PAL（在席和可用性列表），跟踪谁提交了在席与可用性信息以及谁参与通信等。PAL管理也作为系统的注册器，客户端登陆到服务器是通过PAL管理/注册器的。MTCU主要负责为文本消息选择路由到适当客户端。PSTN网关代理服务器主要是为了多方会议，提供多个PSTN电话同时通话。如果没有PSTN网关代理服务器的话，则只能允许2方通话。HTTP代理服务器允许用户通过网页浏览器访问业务，HTTP代理服务器以HTTP形式接受用户的命令，然后将其转换成适合该业务服务器的操作。同样，HTTP代理服务器也能接受该业务服务器的操作，将其转换成HTTP格式的命令送到用户那儿。HTTP代理服务器是为支持运行网页浏览器的联网的PDA移动用户设计的。
服务器与客户端使用各种各样的英特网协议进行相互间的通信，如PAL的管理、会议控制、媒体传送。会话初始协议（SIP）用来注册用户、管理PAL、创建会议以及传送文本消息等，使用SIP主要是在于其简单和便于使用。实时传送协议（RTP）是用来在通信设备间传送语音包的，PSTN网关使用H.323，支持PSTN电话。
4
．业务实例
我们在此设计一个PAM状态感知应用的业务：该业务提供的功能是自动的感知本地用户的状态，并向远端用户发送本地用户的状态信息。并告诉远端用户此时何种通信方式可以联系上用户。同时远端用户也向本地用户发送同样的信息。
其架构即图2所示，当图中左边用户A希望和右边用户B通信的时候，用户A在服务器中查找用户B并将其加入到它的PAL中，如果用户B没有登陆到服务器的话，那么PAL管理器向用户A的客户端发送一个200 Ok的回复，表明用户B为离线。如果用户B在线，则PAL管理器创建一个新的SUBSCRIBE消息，发送到用户B，这个SUBSCRIBE消息是用来提醒用户B有一个PA（在席与可用）监视者，此例中即用户A。如图3：
图3 在席与可用管理
当用户B的可用性状态发生改变的时候，用户B向服务器的PAL管理发出通知，如发出离线通知，PAL管理将用户B的状态更新，再通知用户A，用户A将其PAL中的用户B所登记的状态修改。如图4：
图5 PA状态的改变
业务需要用到的API可能有：CsapiInterface接口，这是PAM所有接口的根；用来管理在席与可用性的接口有： IdentityPresence接口，用来保存用户的动态在席性信息；Availability接口，管理实体的可用性。另外跟context有关的还有Context、ContextData、ContextName、CommunicationContext等接口。鉴权时要用到的接口有Credential、AccessManager接口，用来进行业务的访问控制和鉴权。
5
．后续工作与总结
这一阶段主要对PAM的概念以及在State-aware中的架构模型和业务实例做了一定的分析，罗列了一些可能使用到的API，下面的工作将要对业务的具体实现，进行业务的仿真、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
1467
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
