Communication system

Technical Field of the Communication System The present invention relates to a communication system, and specifically relates to the provision of a presence service in the communication system.

BACKGROUND Various communication systems can now be used to communicate between two or more entities such as user equipment and/or other nodes associated with the system.

Some communication systems are known to provide wireless communication for user terminals or other nodes. An example of a wireless system is the public land mobile network (PLMN). The PLMN is typically a cellular network. A base transceiver station (BTS) or similar access entity serves as a user equipment such as a mobile station (MS) through a wireless interface ( UE) service. The operations required for these devices to communicate are usually controlled by one or more control entities that can be interconnected together. One or more gateway nodes are set up to connect the PLMN with other networks. Examples of such other networks are other cellular networks, public switched telephone networks (PSTN), and packet-switched data networks such as IF (Internet#)-based networks. Communication between user equipment and other units of the communication system is based on Appropriate communication protocol, which stipulates the "rules" for handling communication within the system.

In the current third-generation (3G) wireless system, various servers are defined to handle different communication services for mobile users. These servers include a server called CSCF that provides a call state control function. The control function can also be provided by entities such as home subscriber server (HSS) and applications of various application servers. HSS usually stores user profiles for a long time and is used during authentication. For example, in the version 5 3G architecture as formulated by the Third Generation Partnership Project (3GPP), these entities can be found to be set in the IP Multimedia Subsystem (IMS).

The IMS network can be at the center of the 3G system, supporting IP-based networks that handle traditional audio telephony and multimedia services. 3GPP chooses Session Initiation Protocol (SIP) as the 3G network

02829741.5 The core session signaling protocol, SIP, was developed by the Internet Engineering Task Force (IETF). Those interested can be found at http://www.3gpp.org/ftp/Specs/Latest-drafts/24229-201.zip from the title "IP Multimedia Call Control Protocol based on SIP and SDP (IP Multimedia Call Control Protocol based on SIP and SDP) "SIP vision" see the 3GPP specification 24.229 which explains the basic operation of the IMS network. SIF is a request/response type protocol. For each message sent from the source, there is an associated response from the sink. To the message sent. (Acknowledgement ACK message is a special case of not sending a response.) For example, in a 3G network, when user Nie Chu turns on his mobile terminal, he must use his user ID or address to register with the network, and then his terminal will be approved Fully connected. This is by sending a SIP including details of the user's address from the terminal to the IMS^MREGISTER (registration) message. IMS uses the service call status control function (S-CSCF) called "registrar to receive and process this information. The REGISTER message is only used to provide the users alias and contact address. For example, the alias sip:mikko.lonnfors@sonera.com is mapped to the IP address of the terminal. IMS confirms the registration by sending an appropriate confirmation message (such as a 200 OK message) according to SIP. Whenever the last registration expires or is due When full or when the user's status changes, also register (re-"REGISTER"). When a user wants to establish a session with another user, such as a voice call or a message session (there is another SIP MESS AGE The way of sending messages, in this case, session establishment is not required), and session negotiation will also be performed under SIP.

The application server (AS) can provide services such as instant messaging>presence, local traffic report and conferencing facility through the IMS. The AS may reside in the IMS network or outside the IMS network. Generally, when the supported service is provided by a third party, the AS is external. A specific example of status information is presence information. Subscribe-a presence service user or application server can determine another user, such as the ability and availability to accept calls, and other presence characteristics/attributes (depending on the device and service provider). However, In a system that supports SIF, there are conceivable things such as "In the office, all calls are available", "At home, only private calls are available" and "Call

02829741.5 "Busy" (or at least display this way). So there is a user can determine the availability of another user before making a call. The presence business can provide more than information such as available/unavailable .It can also contain visual, animation or sound components, and can describe, for example, various problems related to game sessions. This standard exists in OMA 8 (www.openmoMlealliance.org)> 3GPP and IETF Business is getting more and more attention. It can be expected that there will be more applications to be aware of in the future. With the increase of applications, the amount of existing information will increase. From the perspective of reception, the increase in information leads to the problem of how to deal with existing information , That is, which parts of the existing information are related to which applications. The terminal can run one or more applications. For example, the terminal can run dynamic phonebook applications and game applications.

In the current IETF and 3GPP models, a tuple structure is adopted. The tuple contains a "random" TUPLE ID, which does not have any semantics, that is, it cannot be used to describe the tuple The purpose of · There can be several attributes in each byte group. In addition, different byte groups can have attributes that have the same name but need to be used/interpreted according to the sending/receiving application. For example, the presence information can contain two byte groups (one for games and one for dynamic phone book (DPB)), and these two byte groups can each contain a status segment. The dynamic phone book can be designed to understand some state values such as available, used with caution, and unavailable, while the game can be designed to understand some state values such as shooting, dead, pause, and failure. It can be seen from this example that if the status segment has the correct meaning, it must be sent to the correct application. This is a problem when one terminal has two or more applications. This is a problem even if the receiving terminal has only one application and the transmitting terminal or presentity has multiple applications. If the data provided in this example is sent to a terminal that only has DPB, the receiving terminal must be able to determine which byte group is to be applied to DPB.

Currently, in addition to each application checking each byte group and checking whether these status values have any childish meaning for this application, there is no mechanism to transmit information to the correct application. That is to say, it is a method of repeated trial and error. However, this causes uncertainty and even correctness of the information. This is because sometimes even if the value can be the same for an attribute, it can be

02829741.5 The first can be incorrectly interpreted by the wrong application. An example of this is as follows: a sending terminal has a DPB and an IM (instant messaging) application. It sets the status value as: DPB = Closed (closed), IM = Open (open). In this example, two Applications only use the status values open and closed. Now if the receiving terminal has only one IM application, and it receives the status of DPB and IM. If the receiving terminal tries the status value of the first DPB, it will provide it through the IM application after understanding To the user, it is said that the IM application in the terminal of the existing entity is closed, even if it is actually open.

It has been proposed that when a user wants to get information about the presence of another user, the user can use some filters to reduce the data from the presence server, that is, presence information. These filters can reduce the presence of the server. Data so that only the part that the user cares about is included.

There are many disadvantages to adopting the byte group flag to be used by the observer (the user requesting the presence information) as a filtering criterion and to authorize the byte group-based flag. For example, if an observed user has 4 byte sets (ΊΊ, T2, T3, and T4) and an observer is only interested in the byte sets T2 and T3, the observer will set the filter to only allow words Section T2 and T3 notify him. The observed user may start to show different values for all byte groups to the observer for some reason in the future. Therefore, the observed user creates new byte groups T5, T6, T7, and T8, thereby creating a new access table, so that the observer sees the byte group T5·T8 instead of the word group T1-Τ4 . However, the observer has set the filter according to the byte group flag, which means that no byte group is provided to him. This is a disadvantage.

Another disadvantage of using byte group flags in filtering is that there are usually entities that do not want the observer to know that a particular observer is not allowed to get as detailed information as another observer, or to give a little bit of information to a different observer group. Or completely different from the information given to other observers.

This is a disadvantage. Every time the filter setting is changed, the observer's authorization information must be changed, because information with different levels of detail is provided to the observer. This is the case if the filtering is based on the independent byte group flags · Summary of the Invention

02829741.5 The embodiment of the present invention aims to overcome one or more of the above problems.

According to one aspect of the present invention, a communication system is provided, including at least one user terminal, presence information is associated with the at least one user terminal, the presence information includes a plurality of parts, and at least one of the plurality of parts includes Identifies the identification information of the entity application module to which the at least one part of the presence information is to be sent; and at least one entity, the presence information associated with the at least one user terminal is provided to the at least one entity, so The at least one entity has at least one entity application module, and the at least one entity is configured to use the identification information to obtain the at least one part of the existence information of the at least one entity application module to be sent to the at least one entity · According to the second aspect of the present invention, a communication method is provided, which includes the following steps: providing presence information for an associated user terminal, the presence information including a plurality of parts, and the plurality of presence information At least one of the parts includes identification information identifying the entity application module to which the at least one part of the presence information is to be sent; and at least one part of the plurality of parts from which at least one entity obtains the presence information The at least one entity has at least one entity application module, and the presence information obtained by the at least one entity includes a part of identification information that identifies the at least one entity application module.

According to a third aspect of the present invention, there is provided a user terminal in a communication system, the user terminal has associated presence information, the presence information includes a plurality of parts, and the user terminal is configured to: At least one part of the plurality of parts of the presence information provides identification information that identifies the entity application module to which the at least one part of the presence information is to be sent.

According to the fourth aspect of the present invention, there is provided an entity in a communication system, the entity includes: at least one entity application module; at least one application obtaining device for obtaining at least the presence information associated with the user terminal In one part, at least one part of the presence information includes identification information that identifies at least one of the at least one entity application module, and the obtaining device is configured to obtain the presence information including the identification information that identifies the at least one entity. At least one part of the identification information of the entity application module. A fairly fixed process setting that can cooperate with the embodiment of the present invention is useful, especially in the past.

02829741.5 When the first filter is pre-stored in a certain server (for example, when there is a table) or the like, the embodiment of the present invention can hide from the observer. Different observers can obtain different degrees of information (or completely differentInformation) The embodiment of the present invention can allow authorization to be more dare without affecting, for example, filter settings or other functions that can be independent of authorization by giving more semantic information to the existing information element. The embodiment of the present invention can be requested by the observer Information that is semantically understandable rather than base the request on "meaningless" sign information·

02829741.5 Description of the Figures In order to better understand the present invention and understand how the present invention can be implemented, the following will take the drawings as an example for description, in these drawings: Figure 1 illustrates a communication system to which the present invention can be applied; Figure 2 An embodiment of the present invention is schematically illustrated; Fig. 3 illustrates the embodiment of Fig. 1 in more detail; Fig. 4 illustrates the IMS part of the system of Fig. 1 in more detail; Fig. 5 schematically illustrates the present invention An embodiment of the invention.

DETAILED DESCRIPTION OF THE EMBODIMENTS The following first describes FIG. 1, which illustrates a typical third-generation (3G) wireless communication system operating under the Universal Mobile Telecommunication System (UMTS). At the core of this system is the IP Multimedia Subsystem (IMS) IOO network, which transfers calls and various conversations between two or more users of the network (or between a user and a network element such as an application server) . Examples of users are mobile terminal 111, laptop Π2, personal desktop assistant (PDA) 113, public switched telephone network (PSTN) telephone 131, computer terminal 123, and application servers 121 and 122. IMS uses an IP-based network for processing These calls include voice calls and multimedia calls.

In a 3G system, the IMS network actually functions as a gateway between users 111, 112, 113 and such as PSTN 130 and external IP-based networks 120. Under the Session Initiation Protocol (SIP), the mobile terminal and INS Signals are transmitted between other users of the network and within the IMS network. All the messages quoted below are SIP messages (unless otherwise specified), shown in capital letters. It should be noted that although these preferred embodiments of the present invention are described in the context of SIP, some other embodiments of the present invention can be implemented in a non-SIP environment.

Next, look at Figures 2 and 3, which schematically show an embodiment of the present invention. FIG. 2 shows a transmitting terminal 10 and a receiving terminal 12. The sending terminal 10 is configured to provide presence information to the receiving terminal 12. A presence server 14 is configured. The presence server 14 and the sending terminal are sometimes referred to as presently. The presence server 14 provides the receiving terminal 12 with required presence information. The presence server 14 will receive presence information from the sending terminal. should

02829741.5 It should be noted that the connection between the sending terminal 10 and the presence server 14 and the connection between the presence server 14 and the receiving terminal will be realized by some network elements or entities not shown.

In some embodiments of the present invention, the sending terminal 10 (which can be any user as described above, also known as an observed (or existing entity) user) should mark some presence tuples so that The receiving terminal 12 (which can be any of the users described above, also referred to as the observer) may also have the presence server 14 that can identify different parts of the presence information and transmit them to the correct application. Specifically, in some embodiments of the present invention, a semantically meaningful application flag information segment is configured in each or at least some byte groups. This field is called the application ID field. The information can be the logo itself or information related to the logo. The sending application inserts an application-specific identifier into the application flag information segment that can be recognized by the receiving terminal. The receiving terminal transmits these byte groups to the application identified by the application ID segment in the terminal.

This will be explained in more detail in conjunction with FIG. 3. In step 1, the applications 16a, 16b, and 16c residing in the sending terminal register their application flags with a presence engine 18 in the terminal. After this step, some applications can start publishing the information to be sent to the presence server (if the user is observing that the presence reservation has been made, the presence server will send the information to the receiving terminal). In the example shown in Figure 3, the terminal Shown as having three applications. This is just an example, one terminal or other users may have more or less applications than three.

In step 2, each application 16 publishes presence information in the form of one or more byte groups, and the presence engine attaches the application HX to each byte group. Then, the presence engine 18 forwards the information to the presence server 14. In other embodiments, the application ID may be appended by the application.

In step 3, the presence trigger 20 of the receiving terminal 12 obtains a NOTIFY (notification) message with new presence information from the presence server 14. The presence engine transfers these bytes according to the application ID (carried in each byte group). The group is transmitted to the corresponding application 22 of the receiving terminal. Or, it is also possible that each application receives all the byte groups, and then omits any byte group with the wrong application flag.

Therefore, each application will have its own application ID, such as game (play) 1, game2. SMS, IM-1. IM2, e-MAIL. If two terminals (1 and 2) have the same

02829741.5 The first application, such as IM-1, then the application ID is the same for this application. However, if terminal 3 has an application identified by IM 2 (for example, made by another supplier), then this application has an application ID that is different from the IMJ application in terminals 1 and 2. In this case Below, the provided attributes can be used by this different application, but you should be careful, because it is possible that these attributes or their values may not be correctly interpreted. An example is the situation where there are two different clients for IM. The basic functions can be the same, so no matter which application interpretation, the state attributes will be correct, but the other attributes may be completely inappropriate.

Since the byte group contains the application identifier, it can provide effective (application-specific) filtering performance, so as to find the correct application to be sent to the byte group. For example, the byte group is in draft-impp-cpim-pidf-05.txt ( Link: http: www.ietf.org/internet-drafts/draft~ietf-impp-cpim-pidt-05.txt) has a general structure as it appears. Applications can therefore extend the "include additional information" option by defining a new XML domain name space. XML is an extensible markup language (SGML-based markup language for the World Wide Web that is designed to relieve the restrictions imposed by HTML. Allows one page to contain one for these The definition and implementation of the elements and their contents).

Who or what defines the different tuples that need to be coordinated with different applications can be changed. This can depend on the type of application. Some or all of the tuples can be specified to have a standard format (standard attributes can be based on, for example, 3GPP Standard definition). In addition or alternatively, application developers can define their own tuples.

Generally, there is no limit to the number of tuples or attributes that an existing entity can have in a tuple.

The entity that wants to put the application ID into each byte group can be the presence engine or the application that publishes this information. The uniqueness of the application ID can be required to be registered in some embodiments of the present invention. This situation can be The uniqueness of the application ID is in the scope of other applications and other collections that require semantic meaning.

Application ID can be used for support and filtering. For example, the application Π) can be used to hide different information "accuracy" levels. In that case, the application ID is not unique. For clarity, application information is unique in the sense that different applications should not use the same application ID

02829741.5 The first, but the same application ID can appear multiple times in the context of different tuples stored in the server. The tuple id (tuple-id) is unique, but in the presence information of an entity For example, two or three byte groups have the same application id. So the application id can be used in filtering. In other words, the observer (receiving terminal) can set the filter to not accept all presence information available from the observed user (existence entity). This sea passer can be set so that the observer can only receive the existence information of certain applications, the filter can filter out certain existence information, or a combination of the two.

For example, if the filter is selected to provide all tuples related to "user-provided location", the following tuples are provided to the observer (if provided by the existing entity to the presence server):

Existing entity = ABC

TUPLE (byte group) 1 byte group id: xyz3226 application id="user-provided location" user-provided location=TAMPERE

TUPLE2 byte group id: xyb3293 application id="user-provided location" user-provided location=HOME

TUPLE3 byte group id: xya3288 application id="user-supplied location" user-supplied bit JL=xcoord, y-coord Below, for the first existence entity 30 to capture and supply the bytes 1, 2, 3, 4 and 5 Figure 5 illustrates each byte group contains an application ID, so byte groups 1 and 2 have application ID "A",

02829741.5 The byte groups 2 and 4 have the application ID "B", and the byte group 5 has the application "C". The observer 32 only wants the tuple with application "A". The filter 34 therefore filters these byte groups, thereby providing the user 32 with byte groups 1 and 2. It should be noted that, in fact, the filter can be a part of the existence entity, a part of an independent unit such as a server, or a part of the observer 32. In this way, the byte group is filtered by the application ID.

These tuples can be planned for different users. Tuples 1, 3, and 5 can be planned for one observer, while tuples 2 and 5 are planned for another observer. Therefore, the observer can only "see" byte groups 1, 3, and 5. Therefore, if the observer only wants the byte group for application "A", the observer will get byte group 1. Filter 34 provides this additional filtering. In some embodiments of the present invention, a separate filter or a guiding device is provided to ensure that an observer only gets the byte group to be given to it.

It may also be that different groups of observers have different presence information available in the group.

The embodiments of the present invention make it easy for applications to understand information that can be interpreted and understood by specific applications based on existing information.

It should be noted that in some embodiments of the present invention, the presence server can use the application flag when performing filtering operations. In some embodiments of the present invention, an operator-specific application can be provided in the presence server, which also uses the application ID. The presence server can, for example, modify some attribute values in a byte group that it understands and the user has the right to access the presence server. The embodiment of the present invention can be used for filters. For example, an observer can only request the presence information The part related to one or more specific applications. The filtering can be performed by the presence entity, the observer, or any other entity observed by the user or the presence server. The filter information can be stored in advance, so that whenever a specific presence entity provides presence information to a specific observer, it can be filtered according to the required application. Filtering can define required applications, undesired applications or by these The combination of technologies is defined.

As mentioned above, an observer is typically a user as described above. An "existing entity" can be considered as a user and an existence server associated with the user. The existence server stores the information associated with it. The user's presence information. It should be noted that, in fact, each server can have multiple users associated with it. Existing server can be set

02829741.5 is placed in a terminal device (terminal).

Existence information as currently defined in 3GPP can include (but is not limited to) the following information, and the requirements from Phase 1 (requirement group) working on these standards are to develop a concept that makes existence expandable: user status; network status ;Communication method; contact address; user provides location; network provides housing; Zhengzhang; priority. Presence can also include other information, such as mood, favorite color, etc.

It should be noted that the embodiments of the present invention are not limited to the attribute called application flag information, but can be applied to any attribute that provides similar types of operating capabilities.

Embodiments of the invention are not limited to the use of tuples. Not all systems use byte groups to form existence files. For example, the existence of a wireless cell handles the existence information of an attribute level. In this case, the application ID is linked to each independent attribute.

FIG. 4 shows a schematic diagram of the IMS network 100. IMS includes various network elements including several call state control (CSCF). A CSCF is equivalent to a SIP server in the IETF architecture.

The query CSCF (I-CSCF) 201 is a basic IMS node, used to terminate calls within the IMS and work at the edge of the network. Here, communication with external nodes such as the mobile terminal 101, the PDA 113, and the application server (AS) 121 is shown. It should be noted that the connection between the sending terminal, PDA and application server and the I-CSCF may not be direct but through an appropriate intermediate network such as the mobile core network 119 of the mobile terminal and the Internet 120 of the application server, such as As shown in Figure 1.

HSS202 is a centralized user database, which interfaces with I-CSCF and S-CSCF204, and is used to store all user information of the IMS. Ι-CSCF uses HSS to perform functions such as authorizing new users and retrieving S-CSCF routing information to transfer messages from the outside world to S-CSCF.

S-CSCF is an IMS node, responsible for invoking services related to IMS users. In this example, S-CSCF also performs the registrar function for registering IMS users. The existing server function is implemented as an application server.

It should be understood that the description of Figure 4 is only rational for prostitution, and in fact it is not mentioned in the narrative.

02829741.5 to additional network elements such as proxy CSCF (p-CSCF). It should also be understood that the embodiment of the present invention can be used in systems other than those shown in FIG. 4. A presence data package can be used to subscribe presence information to any user. The semantics of the presence data package means that any user can send a subscription message for presence information to the presence server. If there is no such specified presence data package, the presence server will not be able to identify what event the user is trying to subscribe to. Therefore, the presence data package needs to be defined in the presence server, so the presence server can receive and recognize the subscription message of the associated review document for the change in the presence information. The presence server creates a state linked to the presence information, and any occurrence in the presence information When it changes, it will trigger a response or notification.

It should be understood that although the embodiments of the present invention are described in the context of 3G using SIP, other appropriate systems and interface protocols may also be used. In particular, the embodiments of the present invention can be used for applications that comply with IETF specifications.

It should be noted here that although the embodiments of the present invention are illustrated above, the disclosed solutions can be combined without leaving the scope of patent protection of the present invention as set forth in the appended claims. Several evolutions and modifications have been made.

02829741.5