WO2008083954A2

WO2008083954A2 - System and method for context data management

Info

Publication number: WO2008083954A2
Application number: PCT/EP2008/000097
Authority: WO
Inventors: Ernoe Kovacs; Nils Richter; Martin Strohbach
Original assignee: Nec Europe Ltd.
Priority date: 2007-01-08
Filing date: 2008-01-08
Publication date: 2008-07-17
Also published as: WO2008083954A3

Abstract

A system and a method for context data management, comprising one or more context sources (1, 2, 10, 11) for providing context data, at least one context sink (3, 13, 14) for receiving context data from said one or more context sources (1, 2, 10, 11) via a context session data channel, and at least one context management entity (6, 7, 8) for context session control, are characterized in that independent communication channels are provided for context session control and context session data.

Description

SYSTEM AND METHOD FOR CONTEXT DATA MANAGEMENT

The present invention relates to a system for context data management, comprising one or more context sources for providing context data, at least one context sink for receiving context data from said one or more context sources via a context session data channel, and at least one context management entity for context session control.

Furthermore, the present invention relates to a method for context data management, wherein context data is provided by one or more context sources, wherein at least one context sink receives context data from said one or more context sources via a context session data channel, and wherein at least one context management entity performs context session control.

The advent of converged next generation communication networks (NGNs) leads to an ever increasing number of mobile services. Today NGNs enable users of network devices, like e.g. mobile terminals, to make use of a comprehensive service catalogue including, for example, infotainment applications like mobile TV, music downloads, e-news, games, etc. Furthermore, different types of communication are available, like SMS or VoIP (Voice over IP), to name just the most popular ones. Due to these extensive types of available services, in a specific case it might be very difficult for the average user to find and to employ the right service according to his current situation and needs. This is particular the case for state-of-the-art resource constrained devices with limited capabilities, e.g. limited screen real estate.

In order to facilitate the usability of dedicated and sophisticated mobile services, currently a technology trend is to be observed which aims at integrating all provisioning technologies and showing only relevant services. To this end user context is automatically acquired and gathered with the users mobile to adapt to changing situations and to available resources. Ideally, user context is applied in such a way that the user is enabled to find a specific service with one look and to use it with one click. According to a definition given by A. K. Dey in "Understanding and Using Context', context is any information that can be used to characterize the situation of an entity. An entity is a person, place or object that is considered relevant to the interaction between a user and an application, including the user and application themselves. Insofar, an important context source is the user himself (or the user equipment, respectively). Context may be regarded as small self-contained information units which have to be distinguished both from measurements and from content. Context can be classified in different categories as there is user context related to the user personalization, device context related to technical specifications and limitations of user equipment, environmental context related to location-based services, and group context related to knowledge sharing and completion.

In existing context management systems, access to context data often requires maintaining and controlling a (long term) communication link between a context source and a context sink. Generally, fine grained control over this communication link is required in order to deal with terminal mobility, frequently chancing context data, access permissions, access to context history, accounting and efficient communication. For example, the MobiLife project has developed solutions for gathering context from a mobile user terminal based on rather static communication links between a context source and a context sink. Further, within the EU-project SPICE the Knowledge Management Framework (KMF) has been proposed for managing context and knowledge information in mobile SDPs (Service Delivery Platforms). The KMF is based on static subscriptions and suffers from performance issues in large scale networks with mobile context sources.

A context-aware system that gathers, processes, and manages context data is described in WO 2005/015869 A1. Moreover, in US 7,076,562 B2 an application intermediation gateway is described which is used for adapting service delivery and in which context is addressed in terms of device characteristics, network capabilities and user profiles.

All existing context-aware systems is in common that context management issues are either not addressed, are performed in a rather static way, or are unsuitable for large numbers of context sources and sinks. Thus, a flexible selection of relevant services from the part of a context consumer is critical in order to increase overall usability and user acceptance of mobile service platforms.

It is an objective of the present invention to improve and further develop a system and a method of the initially described type for context data management in such a way that, by employing mechanisms that are readily to implement, an improvement in terms of higher flexibility and scalability of context provisioning is achieved.

In accordance with the invention, the aforementioned object is accomplished by a system comprising the features of claim 1. According to this claim, such a method is characterized in that independent communication channels are provided for context session control and context session data.

According to the invention it has been recognized that existing context management systems are too static and do therefore not meet the requirements of mobile users in evolving communication networks being highly dynamic and variable. Moreover, it has been recognised that improvements in terms of higher flexibility can be achieved by optimizing communication links between sessions using dedicated control channels. To this end the invention proposes the employment of independent communication channels for context session control on the one hand and for context session data on the other hand. Implementing such separation, communication links between context sources and context sinks can be easily manipulated as required for flexible context management system without affecting running applications. In other words, as context signalling is clearly separated from context data exchange the system and the method according to the invention provide flexible control for changing context data exchange channels without the current application being aware of such changes. Insofar, context processing applications, either residing in operator or third party networks, can be agnostic of concrete context sources.

The invention achieves best performance improvements in case of highly mobile user equipment, e.g. mobile terminals, laptops, PDAs. In this case context sessions can be adapted dynamically to (frequently) changing locations and/or conditions without affecting context-aware applications (context sinks). Consequently, subscriptions to context information provided by one or more context sources can be regarded as highly robust context pipelines realized with dynamically changing sessions between context sources and sinks.

In a preferred embodiment the context management entity includes a session manager which maintains existing sessions and keeps knowledge about processing trees. Moreover, the context management entities may be configured as to include a broker which maintains an index on available context.

According to a further preferred embodiment, the context management entity may be configured as to include a context component repository for storing context sources and sinks that can be instantiated and run. Furthermore, the context management entity or entities may be configured as to include context access control functionality, context source replacement control functionality and/or load balancing control functionality. On the basis of these functionalities each context management entity is enabled to maintain a list of currently registered context sources and to manage and modify sessions. The context source replacement control functionality may be used in case a communication node which functions as context source within a context pipeline disappears or becomes unavailable. The load balancing control functionality is important from a network point of view and is in charge of evenly distributing context loads within the network thereby taking into account the capacity and performance parameters of involved entities.

Advantageously, the context session data channel includes one or more intermediate processing elements located between the context sink and the context source involved in the session. These intermediate processing elements may provide additional functionality and may include access control, privacy filter, cache, context history components and/or context logging components. The context logging component may be implemented as part of a context history component. The context history component provides access to historic context, i.e. context information that is currently not available anymore at the time of a request. By employing the context logging component it may be provided that context sinks can trigger context logging in advance (e.g. location context information about a specific person for the next hours). As regards efficiency improvements, it may be provided that the system further comprises a location server for creating and maintaining a location index of context sources and/or sinks registered at the context management entities. By employment of such location index the context delivery can be restricted to context relevant for given location thereby reducing the overall data traffic drastically.

As regards a fine grained control of access policies, an access policy element may be provided which can be accessed by the context management entity and which includes a database comprising context access policies.

The problem mentioned above is furthermore solved by the method for context data management according to claim 10. According to this claim, the method is characterized in that independent communication channels are provided for context session control and context session data.

Advantageously, context sessions are dynamically manipulated depending on application and/or operator requirements. For instance, if a context sink requests a higher context update rate than the update rate the current context source is able to provide, the context session may be dynamically manipulated by exchanging the current context source with a new context source with the ability to provide context with the requested quality. As what concerns operator requirements, e.g., load balancing issues may be taken into account. Moreover, dynamic manipulations may be performed depending on the availability of context sources. That is if a context source disappear or shuts down its service, a change to another context source may be performed. Generally, it may be provided that context sessions are dynamically redirected to context sources that best satisfy specified application requirements.

According to a preferred embodiment context sources are permitted to roam freely between administrative domains. Due to the clear separation of context signalling from context data exchange, such roaming does not have any effect on running context applications which retrieve context data from said context source.

It may be provided that a context sink receives context from one or more context sources on the basis of a query/response communication. That is, a context sink sends a query, e.g. regarding an Italian restaurant close to its current location, which is processed by the context management entity. After having discovered a context source which can provide the requested context information, the response is forwarded to that context source, and the context source provides the context in form of a response to the context sink. However, it is preferred that a context sink receives context from one or more context sources on the basis of a subscription/notification process. In such cases, which require a repeated long term context data exchange, infrastructure changes occurring during the communication can be efficiently handled due to the employment of independent communication channels for context session control and context session data according to the invention. In case of a subscription, the application requirements of a context sink may be specified in the subscription and may be updated if needed.

Advantageously, processing elements are integrated in the context session data channel according to specific application requirements, in particular according to those application requirements specified in a subscription. As already mentioned above, processing elements may be employed e.g. for caching and/or logging purposes.

As regards proper functionality it may be provided that context sources register at the at least one context management entity. By this means it is assured that the context management entity is aware of context sources which can be instantiated and used, thereby providing highest performance quality to possible context sinks. In addition, it may be provided that context sources after going online and after registration publish context meta information at the context manager. Context meta information includes information about the kind of information the context source is able to provide.

As regards the signalling for context session control it may be provided that SIP (Session Initiation Protocol) is employed, as SIP is currently the most prevalent signalling protocol. However, other existing protocols, like e.g. Web Service Technology and appropriate extensions, may be employed as well. As regards context exchange established sessions, the signalling protocol may negotiate the concrete protocol and data format that is used for transmitting the data to the next element. Employed protocols may include, but are not limited to SIP, Message Session Relay Protocol (MSRP), Web Services. Employed context formats may include, but are not limited to various XML and Resource Description Framework (RDF) representations.

There are several ways how to design and further develop the teaching of the present invention in an advantageous way. To this end, it is to be referred to the patent claims subordinate to patent claims 1 and 10 on the one hand, and to the following explanation of preferred examples of embodiments of the invention illustrated by the drawings on the other hand. In connection with the explanation of the preferred example of an embodiment of the invention by the aid of the drawings, generally preferred embodiments and further developments of the teaching will be explained. In the drawings

Fig. 1 illustrates a system for context data management according to the state of the art,

Fig. 2 illustrates an embodiment of a system according to the present invention,

Fig. 3 is an illustration of another embodiment according to the present invention with a more sophisticated underlying architecture, and

Fig. 4 illustrates the signalling as well as the protocol stack employed in an embodiment of a system according to the present invention.

Fig. 1 illustrates an implementation of a context delivery network comprising two context sources 1 , 2 and a context sink which receives context information from both context sources. The solid line arrows indicate both context signalling and context data flow which, according to prior art, are delivered along the same network path.

In the system shown in Fig. 1 , two network elements are arranged between the context sources and the context sink which provide additional functionality for processing context data retrieved by the context sink. If an entity involved in the context session, i.e. either one of the context sources or one of the network elements, shuts down its service or becomes unavailable, the data flow to the context sink is interrupted and the running context application is aborted or at least disturbed. To continue with the application the context sink is required to perform signalling in order to establish a new context session. Consequently, the context data management system of Fig. 1 is suited for rather static environments only and fails to provide sufficient context distribution quality in dynamic architectures.

Fig. 2 illustrates a first embodiment of a system according to the invention. Essentially the same architecture as in Fig. 1 with two context sources 1 , 2 and a context sink 3 is depicted. Again, there are two network elements 4, 5 arranged between the context sources 1 , 2 and the context sink 3. In addition, the system comprises two context management entities 6, 7 for context session control. Context session control or, more precisely, the signalling performed for establishing a context session between context sources 1 , 2 and context sink 3 is indicated by the dotted line arrows. Context session data flow on the other hand is again indicated by the solid line arrows. As can be obtained from Fig. 2, context session control and context session data channels are clearly separated from each other and are completely independent from each other.

As regards the signalling, context sink 3 first contacts context management entity 7 requesting certain context. Management entity 7 is not aware of any context source that would be able to provide the requested context and thus forwards the request to management entity 6 which may reside in another network domain. Management entity 6 performs signalling with context sources 1 and 2 which then forward the requested context data via communication channels that are independent from context session control channels to context sink 3. By means of additional signalling the communication channel for context session data is established in such a way that it includes network element 4 which may be, e.g., a privacy filter, and via network element 5 which may provide for logging or caching functionality.

Fig. 3 illustrates another embodiment of a system according to the invention wherein a possible architecture of a context delivering network is depicted in some more detail. Again, a context management entity 8, which is responsible for context session control, constitutes the central part of the system.

According to the system illustrated in Fig. 3, the system comprises an access policy element 9 including a database which contains context access policies. Via a signalling path the access policy element 9 is accessed by the context management entity 8 to control access to context sources, shown at 10 and 11 , respectively.

Furthermore, the system comprises a location server 12 creating and maintaining during operation a location index which subscribes to location context of context sources 10, 11. By employing the location index it is possible to restrict specific requests to relevant sub-domains. Advantageously, the location index is constructed hierarchically.

The context management entity 8 manages context sessions and modifies the sessions according to users' and/ore operators' specifications or requirements. The context management entity 8 maintains a list of currently registered context sources. It signals changes, e.g. the availability of new context sources, changes in context metadata or the shutdown of network elements, to relevant system components. Furthermore, it processes queries and subscriptions of context sinks.

The system as illustrated in Fig. 3 includes two context sources, context source 10 and mobile context source 11. As soon as context sources 10, 11 go online, they access the context management entity 8 and register context metadata at the management entity 8. By registration of such metadata the context sources 10, 11 inform the context management entity 8 about the kind of context information they are able to provide, like e.g. update rates, uncertainty levels, etc. Furthermore, the system includes two context sinks, shown at 13 and 14, respectively. Context sink 13 has established a context session pipeline with context source 10. The context pipeline between context sink 13 and context source 10 includes a privacy filter 15 and a cache element 16. The privacy filter 15 processes context by e.g. obfuscating and/or anonymizing data. The cache element 16 caches context provided by the context source 10 upon a request or a subscription from the context sink 13. If another context sink directs the same request towards the context source 10, the requested context can be retrieved from the cache element 16 directly, thereby minimizing the communication from the context source 10.

Another communication channel for context session data is established between mobile context source 11 and context sink 14. The communication channel includes a context processing element 17 which processes exchanged context, e.g. by aggregation and/or reasoning. The context processing element 17 may combine context sink and context source functionality.

A still further communication channel for context session data is established between mobile context source 11 and context sink 13, on the one hand directly (as depicted in the upper part of Fig. 3) and on the other hand by including a context logging component 18 (as illustrated in the lower part of Fig. 3). Like privacy filters, the context logging component 18 operates on data plane and persistently stores context. Logging may be triggered by context sinks in advance.

The upper part of Fig. 4 illustrates the signalling for establishing a context session between a context sink and a context source in more detail. In the embodiment explained in connection with Fig. 4, SIP (Session Initiation Protocol) is employed as signalling protocol.

When the context source goes online and thus becomes available for instantiation, the context source registers at the context management entity (SIP REGISTER) and publishes context meta information (SIP PUBLISH). The context metadata include information regarding the kind of data provided by the context source and is employed by the context management entity for controlling access to context sources and managing context sessions.

In a next step the context sink sends a context query to the context management entity and receives a context reply from the context management entity. Alternatively, a context subscription/notification can be performed between the context sink and context management entity. The context management entity then performs further signalling with an appropriate context source. Subsequently, the context sink sends a message regarding the initialisation of a session to the context management entity (SIP INVITE). The context management entity then sends a SIP INVITE message together with the address of the requesting context sink to the context source. Upon receipt of the SIP INVITE message by the context source, a context session between the context source and the context sink is established. It is to be noted, that the context session data channel does not include the context management entity and is clearly separated from the communication channel employed for context session control. The end of a session is performed by means of a SIP BYE message.

The lower part of FIG. 4 illustrates the internal organisation of the three main components of the system, i.e. the context management entity, the context sink and the context source. As already mentioned above, the session initiation protocol (SIP) is employed as signalling protocol for context session control. The CSIP (Context Session Initiation Protocol) stack builds on the NIST (National Institute of Standards and Technology) JAIN (Java APIs for Integrated Networks) SIP stack and manages registered terminals.

All three components include a session manager which maintains a list of existing sessions. The context source and the context sink only know about their own sessions while the context management entity knows about all existing sessions. The context source and the context management entity further include a context broker which maintains a list of available context items. In the context source this includes only locally available context. In the context management entity on the other hand the list relates each available context item to a context source identifier. The broker sends events to the Dispatcher/Policy Layer that may manipulate sessions and may control access to context using the session manager and a query processor of the context management entity. The query processor processes complex queries/subscription and outputs an execution plan that is followed by the Dispatcher/Policy Layer to establish the necessary sessions or query the corresponding knowledge sources. The context source may be implemented in J2ME (Java 2 Platform, Micro Edition, for mobile equipment), whereas the context management entity and the context sink may be implemented in J2SE (Java 2 Platform, Standard Edition). Finally, it is to be noted that the present invention can be employed in a multitude of different application scenarios. In this regard it is particularly important that future mobile services will heavily rely on context data coming from various sources that will not be under uniform control. The present invention provides a flexible way to implement context management systems that can be deployed at mobile network operators and third party service providers. Similarly, large, medium and small enterprises may deploy a customized context management system to offer context services for their customers or employees. As in contrast to existing solutions similar concepts as in IMS are employed, the integration into existing (SIP based) IMS systems is facilitated. The invention enables distributed and flexible localization, gathering, processing, analyzing and delivery of context information for a variety of different uses cases as part of a context management platform and has particular potential to be used in medical care and workplace safety scenarios, to name just two possible application fields. More generally, the invention can be applied in most diversified scenarios with a variety of different context sources like for instance all kind of sensor technologies, environmental scanning, or network and service information. As context sinks one can envision a wide range of context management platform components, service providers and end-user devices.

Many modifications and other embodiments of the invention set forth herein will come to mind the one skilled in the art to which the invention pertains having the benefit of the teachings presented in the foregoing description and the associated drawing. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

C l a i m s

1. System for context data management, comprising one or more context sources (1 , 2, 10, 11 ) for providing context data, at least one context sink (3, 13, 14) for receiving context data from said one or more context sources (1 , 2, 10, 11 ) via a context session data channel, and at least one context management entity (6, 7, 8) for context session control, c h a r a c t e r i z e d i n that independent communication channels are provided for context session control and context session data.

2. System according to claim 1 , wherein said at least one context management entity (6, 7, 8) is configured as to include a session manager for maintaining existing sessions.

3. System according to claim 1 or 2, wherein said at least one context management entity (6, 7, 8) is configured as to include a broker which maintains an index on available context.

4. System according to any of claims 1 to 3, wherein said at least one context management entity (6, 7, 8) is configured as to include a context component repository for storing context sources (1 , 2, 10, 11 ) and/or sinks (3, 13, 14) that are available for instantiation.

5. System according to any of claims 1 to 4, wherein said at least one context management entity (6, 7, 8) is configured as to include context access control functionality, context source replacement control functionality and/or load balancing control functionality.

6. System according to any of claims 1 to 5, wherein said context session data channel includes one or more intermediate processing elements (4, 5, 15, 16, 17) located between said context sink (3, 13, 14) and said one or more context sources (1 , 2, 10, 11 ).

7. System according to claim 6, wherein said one or more processing elements (4, 5, 15, 16, 17) include access control, privacy filters (15), caching elements (16), context history components, and/or context logging components (18).

8. System according to any of claims 1 to 7, further comprising a location server for creating and maintaining a location index of context sources (1 , 2, 10, 11) and/or context sinks (3, 13, 14) registered at said at least one context management entity (6, 7, 8).

9. System according to any of claims 1 to 8, further comprising an access policy element to be accessed by said at least one context management entity (6, 7, 8), said access policy element including a database which contains context access policies.

10. Method for context data management, in particular for application in a system according to any of claims 1 to 9 wherein context data is provided by one or more context sources (1 , 2, 10, 11 ), wherein at least one context sink (3, 13, 14) receives context data from said one or more context sources (1 , 2, 10, 11) via a context session data channel, and wherein at least one context management entity (6, 7, 8) performs context session control, c h a r a c t e r i z e d i n that independent communication channels are provided for context session control and context session data.

11. Method according to claim 10, wherein context sessions are dynamically manipulated depending on application and/or operator requirements.

12. Method according to claim 10 or 11 , wherein context sessions are dynamically manipulated depending on the availability of context sources (1 , 2, 10, 11).

13. Method according to any of claims 10 to 12, wherein context sessions are redirected to context sources (1 , 2, 10, 11 ) that best satisfy specified application requirements.

14. Method according to any of claims 10 to 13, wherein said one or more context sources (1 , 2, 10, 11 ) roam between administrative domains.

15. Method according to any of claims 10 to 14, wherein said context sink (3, 13, 14) receives context from said one or more context sources (1 , 2, 10, 11) on the basis of a query/response communication.

16. Method according to any of claims 10 to 14, wherein said context sink (3, 13, 14) receives context from said one or more context sources (1 , 2, 10, 11 ) on the basis of a subscription/notification process.

17. Method according to claim 16, wherein the context sink's (3, 13, 14) application requirements are specified in said subscription.

18. Method according to any of claims 10 to 17, wherein processing elements (4, 5, 15, 16, 17) are integrated in the context session according to specified application requirements.

19. Method according to any of claims 10 to 18, wherein context sources (1 , 2, 10, 11 ) register at said at least one context management entity (6, 7, 8).

20. Method according to claim 19, wherein context sources (1 , 2, 10, 11 ), after said registration, publish context meta information.

21. Method according to any of claims 10 to 20, wherein the signalling employed for context session control is based on the SIP (Session Initiation Protocol).

22. Method according to any of claims 10 to 21 , wherein the signalling protocol negotiates the concrete protocol and/or data format employed between an element involved in the context session data channel and a subsequent element for transmitting the context data from said element to said subsequent element.