A communication system

ES 2 269 830 T3

DESCRIPTION

Communication system.

Scope of the invention

The present invention refers to a communication system, especially for the provision of a presence service in a communication system.

Background of the invention

At present, various communication systems are used that allow communication between two or more entities such as user equipment and / or other nodes associated with the system.

Communication systems that provide wireless communications to user terminals or other nodes are well known. An example of a wireless system is a public land mobile network (PLMN). Typically a PLMN is a cellular network in which a base transmitting / receiving station (BTS) or similar access entity provides service to user equipment (UE) such as mobile stations (MS) through a wireless interface. The operation of the apparatus necessary for communication is usually controlled by one or more control entities which may, in turn, be interconnected. One or more gateway nodes allow the PLMN to connect to other networks. Examples of such other networks may be another cellular network, a public switched telephone network (PSTN) and packet switched data networks such as an IP (Internet Protocol) based network. The communication between the user equipment and the other elements of the communication system are based on a suitable communication protocol, which defines the "rules" by which the communications in the system are managed.

In the current third generation (3G) wireless system, various servers are defined to manage the different communication services for mobile users. These comprise servers that provide call state control functions known as CSCFs. Control functions can also be provided by entities such as a home subscriber server (HSS) and applications by various application servers. HSS is typically used to permanently store the user profile and is used during authentication. For example, in version 5 of the architecture for 3G, as specified in the "3rd Generation Partnership Project" (3GPP), these entities can be found in the IP Multimedia Subsystem (IMS).

The IMS network can be found at the core of the 3G architecture, supporting an IP-based network that manages both traditional voice telephony and multimedia services. 3GPP has selected Session Initiation Protocol (SIP) as the basic session signaling protocol for 3G networks. SIP has been developed by the Internet Engineering Task Force (IETF). Those interested can find the 3GPP 24.229 specification that describes the basic operation of the IMS network from a SIP perspective called "IP Multimedia Call Control Protocol based on SIP and SDP" at http : //www.3gpp.org/ftp/Specs/Latest-drafts/24229201.zip. SIP is a request / response protocol, in the sense that for each message sent from a source, there is an associated response from the destination confirming the receipt of the sent message. (The ACK acknowledgment message is a special case to which no response is sent.)

For example, in a 3G network, when a user first turns on his mobile terminal, he must register his user ID or address on the network before the terminal is allowed full connection. This is done by sending a SIP “REGISTER” message from the terminal to the IMS, which includes details about the user's address. The IMS receives and processes this information using a service call state control function (SCSCF) which in this context is called a "registrar". The REGISTER message is only used to establish a correspondence between the alias of a user and the contact address, such as the correspondence between the alias sip: mikko.lonnfors@sonera.com and the IP address of the terminal. The IMS acknowledges receipt of the registration by sending a suitable acknowledgment message, (eg a 200 OK message) in accordance with SIP. Subsequent registrations (re-REGISTER) are also produced whenever the previous registration expires or is about to expire, or when there is a change in user status. When a user wants to establish a session with another user, such as a voice call or messaging session (there is another way to send messages, that is, through a SIP MESSAGE and in this case it is not necessary to establish the session), the negotiation of the session will also take place under SIP.

Application servers (AS) can provide services through the IMS such as instant messaging, presence, local traffic reporting, and conferencing. An AS can reside in the IMS network or be located outside of it. Typically, the AS is external when the supported service is provided by a third party.

A specific example of status information is presence information. User or application servers that subscribe to a presence service can determine the ability and availability for another user, for example, to accept a call (depending on equipment and service provider) among other presence characteristics / attributes. However, in systems that support SIP, the presence can assume various indicators such as "in the office and available for all calls", "at home and available only for private calls" and

ES 2 269 830 T3 "line busy" (or at least appear this way). In this way the presence information allows a user to find out the availability of another user before trying to make a call. The presence service can provide more than just information such as availability / unavailability. It can include visual, animated or sound parts and can describe various topics related to a game session for example.

This presence service that is being standardized in OMA 8 (open mobile alliance (www.openmobilealliance.org)), 3GPP and IETF is attracting increasing attention. The number of presence alert applications is expected to increase in the future. As the number of applications increases, the amount of presence information will also increase. From the perspective of the receiving terminal, the information augmentation poses a challenge in how to handle the presence information, that is, which components of the presence information are important for which applications. A terminal can run one or more applications. For example, the terminal may run a dynamic phone book application and a games application.

Current IETF and 3GPP models use a tuple structure. The tuple contains a random TUPLE ID that lacks semantics, that is, it cannot be used to describe the purpose of the tuple. In each tuple there can be several attributes. Also, the different tuples can have attributes with the same name but that will be used / interpreted differently depending on the sending / receiving application. For example, the presence information can contain two tuples (one for games and one for a dynamic phone book (DBP)), and each of these tuples can contain a status field. The dynamic phone book may have been designed to understand status values: available, discreet, not available, while the game may be designed to understand status values: shooting, dead, paused, lost. As can be seen from this example, the status fields must be provided to the correct application for them to have the correct meaning. This is a problem when a terminal has two or more applications. This is also a problem even when the receiving terminal has only one application and the sending terminal or presentity has multiple applications. If the data provided in the example is sent to the terminal that only has, for example, the DPB, the receiving terminal needs to be able to determine which tuple is provided for the DPB application.

Currently, there is no mechanism to pass the information to the correct applications except that each application checks each tuple and determines if the state values ​​make any sense to the application. In other words, a trial and error approach is adopted. However, this creates uncertainty regarding the accuracy of the information. This is because in some cases, even though the value may be the same for an attribute, it can be misinterpreted by the wrong application. An example of this is the following: the sending terminal has a DPB application and an IM (instant messaging) application. Set the status values: DPB = Closed, IM = Open. In this example, both applications would use only the open and closed state values. But if the receiving terminal has only one IM application and simultaneously receives the DPB and IM states, if the receiving terminal tests the first DPB status value it understands it and presents it to the user through the IM application saying that the IM application of the terminal the presence entity was closed even though it was open.

It has been proposed that when a user wishes to obtain presence information about another user, the user may include filters to reduce the data from the presence server, ie the presence information. These filters can reduce the data coming from the presence server to include only those parts that are of interest to the user.

The method whereby the two tuple identities are used as filter criteria by observers (users requesting presence information) and where authorization is also based on tuple identities has many disadvantages. If, for example, a user who is being observed has 4 tuples (T1, T2, T3 and T4) and an observer is only interested in the tuples T2 and T3, the observer establishes some filters that allow only the tuples to be notified T2 and T3. The observed user can then decide for any reason to start showing different values ​​to the specific observer relative to all tuples. Therefore, the observed user creates new tuples T5, T6, T7 and T8 and creates a new access list that allows the observer to see the tuples T5 to T8 but not the tuples T1 to T4. But the observer has configured the filter based on the identity of the tuple, which means that no tuples have been provided. This is disadvantageous.

Another disadvantage of using tuple identities for filtering is that normally the presence entity does not want observers to know that a specific observer is not allowed to obtain as detailed information as another observer or that information provided to different groups of observers it is slightly or totally different from the information provided to other observers.

It is disadvantageous if the filtering settings change each time an observer's authorization information is modified because a different level of detail of information is provided to the observer. This would be the case if the filtering was based on the unique tuple identities.

WO02 43351 describes a method and apparatus for determining and maintaining user presence information.

ES 2 269 830 T3

Summary of the invention

Embodiments of the present invention are intended to overcome one or more of the foregoing problems.

According to one aspect of the present invention a communication system is provided comprising at least one user terminal to which presence information is associated, said presence information comprising a plurality of parts, at least one of said parts comprising information provided by the user terminal and that identifies the application to which at least said part is directed.

According to a second aspect of the present invention, a communication method is provided comprising the steps of providing presence information for an associated user terminal, said presence information comprising a plurality of parts and at least one of said parts information provided by the user terminal that identifies an application for which at least one part is intended; and at least one entity obtains at least one of said parties at least said entity having at least one entity application, at least one entity obtaining the parties that comprise information that identifies at least said entity application.

According to a third aspect of the present invention a user terminal for a communication system is provided, presence information being associated with said user terminal, said presence information comprising a plurality of parts, said user terminal being arranged to provide at least one of said parties with information that identifies an application for which at least that party is intended.

According to a fourth aspect of the present invention, an entity is provided in a communication system, said entity comprising, at least, means of obtaining applications to obtain at least one element of presence information associated with a user terminal , an application being identified by at least one part that comprises information provided by the user terminal, the means of obtaining being arranged to obtain at least the part comprising information that identifies at least said application.

The fairly static filter settings provided by embodiments of the invention are especially useful when filters are stored in advance on a particular server (eg, in the case of the presence list) or the like.

Embodiments of the invention may allow to conceal from observers the fact that there is a different level of information (or totally different information) available to different observers.

Embodiments of the invention may allow changes to authorization without affecting, for example, the configuration of filters or any other functionality that can be separated from authorization by providing greater semantics to the parts of the presence information.

Embodiments of the invention may provide the viewer with the ability to request semanticly understandable information rather than basing the request on "meaningless" identity information.

Brief description of the figures

To better understand the present invention and its implementation, reference will be made below, and only by way of example, to the attached figures, in which:

Figure 1 shows a communication system to which the present invention can be applied.

Figure 2 schematically shows an embodiment of the invention.

Figure 3 shows in more detail the embodiment of Figure 2.

Figure 4 shows the IMS component of the system of Figure 1 in greater detail.

Figure 5 schematically shows an embodiment of the invention.

Detailed description of the realizations

In the following, reference will first be made to Figure 1 which shows a typical 3-cell wireless telecommunication system.^to Generation (3G) that operates through the universal mobile telecommunications system (UMTS). At the core of this system is the IP Multimedia Subsystem (IMS) 100 network, which routes calls and all types of sessions between two or more users (or between a user and a network element, such as for example an application server) on the network and facilitates other network functions. Examples of users include the mobile terminal 111, the laptop computer 112, the personal organizer (PDA) 113, a telephone belonging to the public switched telephone network (PSTN) 131, a computer terminal 123 and an application server 121 and

ES 2 269 830 T3 an application server 122. The IMS uses an IP-based network to handle these calls which may include voice calls and multimedia calls.

The IMS network effectively acts as a gateway in a 3G system between users 111,112,113, and other networks such as a PSTN 130 and an external IP-based network 120. The signaling between the mobile terminal and the rest of the users of the IMS network, and within of the IMS network, it is carried out under the Session Initiation Protocol (SIP). All references to messages made hereafter refer to SIP messages unless otherwise indicated, and will be displayed in capital letters. It should be noted that although the preferred embodiments of the present invention have been described in the context of SIP, other embodiments of the invention can be carried out in non-SIP environments.

Reference will now be made to Figures 2 and 3 which schematically show an embodiment of the present invention. Figure 2 shows a transmitting terminal 10 and a receiving terminal 12. The transmitting terminal 10 is configured to provide presence information to the receiving terminal 12. A presence server is provided 14. The presence server 14 and the transmitting terminal are referred to as occasions as a presence entity. The presence server 14 provides the receiving terminal 12 with the necessary presence information. The presence server 14 will receive the presence information from the transmitting terminal. It should be noted that the connection between the transmitting terminal 10 and the presence server 14 as well as the connection between the presence server 14 and the receiving terminal will be made through network elements or entities not shown.

In embodiments of the present invention, a transmitting terminal 10 (which can be any of the users as mentioned above and can be called an observed user (or presence entity)) will mark presence tuples so that the receiving terminal 12 (which can be any of the users mentioned above and what may be referred to as an observer) and possibly the presence server 14 can identify different parts of the presence information and transfer them to the correct applications. Specifically, in embodiments of the present invention, a semantically meaningful application identity information field is provided in each tuple or at least some tuples. This field is called the application ID field. The information can be the identity itself or information relating to the identity. The transmitting application inserts an application-specific identifier into the application identity information field that can be recognized by the receiving end. The receiving terminal transfers the tuples to the applications located in the terminal identified in the application ID field.

This will be discussed in greater detail with reference to Figure 3. In step 1, applications 16a, 16b and 16c residing in the transmitting terminal register their application identities with a presence engine 18 located in the terminal. After this stage, the applications can begin to publish information, that is, send information to the presence server (and from this to the receiving terminal if the observer had made a presence subscription). In the example shown in Figure 3, the terminal is shown comprising three applications. This is done by way of example only and a terminal or other user may have more or less than three applications.

In step 2, each application 16 publishes presence information in a form that contains one or more tuples and the presence engine assigns the application ID to each tuple. The presence engine 18 then sends the information to the presence server 14. In alternative embodiments, the application may perform the assignment of the application ID.

In step 3, the presence engine 20 of the receiving terminal 12 obtains a NOTIFY message from the presence server 14 regarding the new presence information. According to the application ID (carried with each tuple), the tuples are routed to the corresponding applications 22 of the receiving terminal through the presence engine. Alternatively, each application can receive all tuples, but will ignore any tuple that has the wrong application identity.

In this way, each application would have its own application ID. For example game1, game2, SMS, IM-1, IM-2, e-MAIL. If two terminals (1 and 2) have the same application, for example IM-1, the application ID will be the same for that application. However, if terminal 3 has an application identified by IM-2 (manufactured for example by another vendor), the application will have a different application ID than the IM-1 application on terminals 1 and 2. In these cases, the attributes provided can be used by different applications, but care must be taken because the attributes or their values ​​may not be interpreted correctly. An example of this is the case where there are two different clients for IM. The basic functionality can be the same and thus the status attribute would be valid regardless of the application that interprets it, but the rest of the attributes may or may not be important.

Due to the fact that the tuples contain the application identification, it is possible to provide effective (application-specific) filtering capabilities as well as to find the appropriate application for which the tuples are designed.

Usually the tuples have a structure presented in draft-impp-cpim-pidf-05.txt (link: http: // www.ietf.org/internet-drafts/draft-ietf-impp-cpim-pidf-p5 .txt). Applications can then expand the "include additional information" options by defining new XML namespaces. XML is Extensible Markup Language (World Wide Web-a markup language based on SGML and designed to eliminate

ES 2 269 830 T3 limitation imposed by HTML. It allows a page to contain a definition and execution plan for its elements, as well as its content).

It can vary who or what defines the different tuples to be used with the different applications. This may be a function of the type of application. Some or all of the tuples can be defined to have a standard format (standard attributes can be defined, for example in the 3GPP standard). Additionally or alternatively application developers can define their own tuples.

In general, there are no limits to the number of tuples or tuple attributes that a presence entity can have.

The entity that will put the application ID in each tuple can be the presence engine or the application that publishes said information. The unique nature of the application ID may require its registration in some embodiments of the present invention. This may be the case when the unique character of the application ID is found in other applications as well as other collections of information that require semantic meaning.

The application ID can be used in multi-value filtering and support. For example, the application ID can be used to hide different levels of “precision” of the information. In this case, the application ID is not unique. For clarification purposes, the information about the application is unique in that different applications should not use the same application ID but the same application ID may be present multiple times on a presence server in the context of tuples different. The tuple ID is unique but the same application ID exists for example in two or three tuples of presence information of a presence entity. The application ID can later be used for filtering. In other words, the observer (receiving terminal) can set a filter so that it does not receive all the presence information available from the observed user (presence entity). This filter can be set in such a way that the observer receives only presence information related to certain applications, said filter filtering certain presence information or a combination of both.

For example, the following tuples are provided to the observer (if they have been provided by the presence entity to the presence server) in the case of selecting a filter and all the tuples relative to "user contributed location" are provided:

Presence entity = ABC

TUPLE 1

Tuple ID: xyz3226

Application ID = "user contributed location" User contributed location = TAMPERE

TUPLE 2

Tuple ID: xyb3293

Application ID = "user contributed location" User contributed location = HOME

TUPLE 3

Tuple ID: xya3288

App ID = "user contributed location"

User input location = x coordinates -y coordinates.

Reference is made to Figure 5 in which a first presence entity 30 provides tuples 1,2, 3,4 and 5. Each tuple contains an application ID whereby tuples 1 and 2 have an application ID "A ", Tuples 3 and 4 have an application ID of" B "and tuple 5 has an application ID of" C ". An observer 32 only wants the tuples with application "A". Therefore, a filter 34 filters the tuples and provides the user 32 with tuples 1 and 2. It should be noted that in practice, the filter can be part of the presence entity, part of an independent entity such as a server or part of the observer 32. Therefore the application ID is used to filter the tuples.

ES 2 269 830 T3

The tuples can be directed to different users. Thus, tuples 1, 3 and 5 can be directed to one observer and tuples 2 and 5 to a different observer. Therefore, the observer may be able to "see" only tuples 1, 3 and 5. Therefore, if the observer only wants the tuples corresponding to application "A", the observer would receive tuple 1. Filter 34 provides this additional filtering. In some embodiments of the invention, a separate filter or targeting means is provided to ensure that an observer only receives the tuples addressed to it.

It is also possible that different groups of observers have different presence information for the respective groups.

Embodiments of the present invention allow applications to easily recognize, from presence information, what information that specific application can interpret and understand.

It should be noted that in embodiments of the present invention, the application identity may be used by the presence server when executing the filtering operation. In some embodiments of the invention, an operator-specific application may be provided on the presence server that would also use the application IDs. The presence server could, for example, modify some attribute values ​​of a tuple that it understands and to which the user has granted access rights to the presence server.

Embodiments of the present invention can be used for filtering. For example, an observer may request only the part of the presence information that refers to one or more specific applications. Filtering can be done by the presence entity under observation - either by the user or by the presence server, the observer or any other entity. The filter information can be pre-stored so that when a specific presence entity provides presence information to a specific observer it will be filtered according to the necessary applications. Filtering can define required applications, non-required applications, or a combination of both techniques.

As mentioned above, an observer is normally a user as already mentioned. A "presence entity" can be considered to be a user and a presence server associated with that user. The presence server stores presence information for users associated with said presence server. It should be noted that in practice more than one user would be associated with each server. The presence server can be located on an end device (at the terminal).

Presence information, as currently defined in the 3GPP can include the following information: information, but not limited to these and the requirements of stage 1 (group of requirements) working on the standards, to develop a concept that allows the expansion of presence. Subscriber status; network status; media; contact address; location provided by the subscriber; location provided by the network; text; priority.

The presence can also include other information such as environment, favorite color, etc.

It should be noted that embodiments of the invention are not limited to information about the identity of the application invoked by the attribute, but can be applied to any attribute that provides a similar type of operability.

The embodiments of the present invention are not limited to the use of tuples. Not all systems use tuples to structure the presence document, for example the presence of the wireless environment manages the presence information at the attribute level and in this case the application ID is linked to each independent attribute.

Figure 4 shows a diagram of the IMS network 100. The IMS comprises several parts including the Call State Control Functions (CSCF). A CSCF is equivalent to a SIP server in the IETF architecture.

The querying CSCF (I-CSCF) 201 is the IMS basic node used to terminate calls in the IMS network, operating at the edge of the network. In this case, it is shown communicating with the external nodes of a mobile terminal 101, a PDA 113, and an application server (AS) 121. It should be noted that the connections between the mobile terminal, the PDA and the application server with the I-CSCF may not be direct but through a suitable intermediate network such as the mobile core network 110 for the mobile terminal, and the Internet 120 for the application server, as shown in Figure 1.

HSS 202 is a centralized user database that interfaces with I-CSCF and S-CSCF 204, storing information about all IMS users. The I-CSCF uses the HSS to perform functions such as authorization of new users and retrieval of route information in the S-CSCF to send messages from external parties to the S-CSCF.

The S-CSCF is the IMS node responsible for invoking services related to IMS users. In this example, the S-CSCF also performs registration functions for IMS users, processing user registrations. The presence server function is carried out as an application server.

ES 2 269 830 T3

It should be noted that the description in figure 4 is only a schematic representation and that in practice additional parts such as a proxy-CSCF (P-CSCF) are missing. It should also be noted that embodiments of the invention can be used in systems other than those shown in Figure 4.

A presence package can be used to subscribe to the presence information of any user. The semantics of the presence packet means that any user can send a subscription message of presence information to the presence server, but if no such presence packet has been defined, the presence server would not be able to recognize which event it is trying to subscribe to. the user. Therefore, the presence packet must be defined in the presence server which can then receive and acknowledge the subscription message for the event associated with changes in the presence information. The presence server creates a state linked to the presence information, and when there is any change to the presence information, it will initiate a response or notification.

It should be noted that although some embodiments of the present invention have been described within the 3G context using SIP, other interface systems and protocols could be used. In particular, embodiments of the present invention can be used in an application in accordance with the IETF specifications.

It should also be noted herein that although the foregoing describes examples of embodiments of the invention, there are various variations and modifications that can be made to the described solution without departing from the scope of the present invention as defined in the appended claims.