BRPI0614221A2 - method, apparatus and system for providing presence information in support of wireless communication services - Google Patents

Abstract

INDICATION OF DEPENDENCE OF ENCODING IN SCALING VIDEO ENCODING. A method of encoding and decoding a scalable stream of video data comprising a base layer and at least one optimization layer. A scalable data stream is encoded, where the data stream includes at least one image not required in a layered time slot where decoding images in a higher layer in and following the time slot in the decoding order does not require the image not required , and where information from at least one non-required image is signaled in the scalable video data stream. In the decoding phase, the signaled information is decoded and images in a layer above the image not required in and following the temporal location in the decoding order are decoded without decoding the unsolicited image.

Description

"METHOD, APPARATUS AND SYSTEM FOR PROVIDING DEPRESENTATION INFORMATION IN SUPPORT OF WIRELESS COMMUNICATION SERVICES".

Related Requests

This application claims the benefit of the most unclaimed filing date under USC Article 35 §119 (e) of Provisional Serial Number US 60 / 698.192, filed July 11, 2005, entitled "Method and Application for Providing Presence Information In Support Of Wireless CommunicationServices ", which is incorporated herein in its entirety by way of reference.

Field of the Invention

The invention relates to communications and, more particularly, the provision of presence information within a radio communication system.

Background of the Invention

Radio communication systems, such as cellular systems (for example, spread spectrum systems such as Code Division Multiple Access (CDMA) or Time Division Multiple Access (TDMA) networks) provide users with with the convenience of mobility along with a rich configuration of services and features. This convenience has generated significant approval through a continuously growing number of consumers as an accepted mode of communication for business and personal users. In order to foster greater adoption by suppliers over service providers, the telecommunications industry, with much effort and expense, agreed to develop standards for communication protocols that had priority over the various services and features. One service area has received significant attention, the Push-to-Talk Cellular (PoC). Traditional approaches have not provided adequate indication of a user's availability within the network.

The Push-to-Talk (PoC) service is a two-way form of communication that allows users to immediately communicate with one or more users. The (PoC) service is similar to the walkie-talkie application where pressing A button starts a conversation session with an individual or broadcast group user. Receiving participants hear the voice of the transmitter without any action on their part (automatic answer mode), or may be notified and have to accept the call (manual answer mode) before hearing the transmitter's voice. Prior to the "immediate" nature of this type of communication, determining the user's presence is impermissible.

Therefore, there is a need for an approach to more effectively determine the availability or presence information of a mobile or user station within a radio communication system.

Summary of the Invention

These and other needs are driven by the invention, where an approach is presented to more effectively determine the presence of users on a network.

According to one aspect of an embodiment of the present invention, one method is to determine an event that affects the availability of a terminal in a network. The method further comprises generating a message that includes no-event information, where the message is used to provide presence information regarding the terminal.

According to another aspect of an embodiment of the invention, an apparatus comprises a processor configured to determine an event affecting the availability of a terminal in a network, and to generate a message including information on the event. The message is used to provide the presence information referring to the terminal.

According to another aspect of one embodiment of the invention, a method is to register with a network to communicate over the network. An event associated with the registry is used to determine availability for a network-supported communication service. An application server generates a message that includes information on the event. The message is used to provide presence information regarding the communication service.

In accordance with yet another aspect of an embodiment of the invention, an apparatus comprises a processor configured to initiate registration with a network to communicate over the network. An event associated with registration is used to determine availability for a communication service supported by a network. An application server generates a message that includes information on the event. Message is used to provide presence information regarding the communication service.

Still other aspects, features, and advantages of the invention are readily apparent from the following detailed description, simply by illustrating a number of particular embodiments and applications, including the best mode for carrying out the invention. The invention is capable of still other and different modalities, and its numerous details can be modified in various obvious aspects, all without departing from the spirit and scope of the invention. As a consequence, the drawings and description should in fact be considered as illustrative rather than restrictive.

Brief Description of the Drawings

The invention is illustrative by way of example, and not limitation, in the figures of the accompanying drawings, in which the numerical references refer to the elementosimilar and in which:

Figure 1 is a diagram of a radio communication system for supporting extended presence information attributes according to an embodiment of the invention;

Figure 2 is a diagram of a registration procedure for osterminals in the system of Figure 1;

Figures 3A and 3B are process flow charts for providing extended presence information in accordance with one embodiment of the invention;

Figure 4 is a diagram of a Push-To-Talk (PoC) support presence service architecture according to one embodiment of the invention;

Figure 5 is a hardware diagram that can be used to perform numerous embodiments of the invention;

Figures 6A and 6B are diagrams of different mobile cellular telephone systems capable of supporting various embodiments of the invention;

Figure 7 is an exemplary component diagram of a mobile station capable of operating in the systems of Figures 6A and 6B according to an embodiment of the invention; and

Figure 8 is a diagram of a corporate network capable of supporting the process described herein according to one embodiment of the invention.

Description of Preferred Mode

An apparatus, method, and software is described in order to provide presence information attributes in a radio communication system. In the following description, by way of explanation, numerous specific details are set forth to provide a thorough understanding of the invention. It is clear, however, to one skilled in the art, that the invention may be practiced without such specific details or with an equivalent arrangement. In other examples, well known structures and devices are shown in block diagram form, in order not to unnecessarily conceal the invention.

Although the various embodiments of the invention are described with respect to the Push-to-Talk (PoC) service with a spread-spectrum cellular network, it is recognized and contemplated that the invention has applicability to other group communication services and radio networks. . Additionally, although the invention is discussed with respect to the IP Multimedia Subsystem Service (IMS) and Multimedia Domain (MMD) networks, one of ordinary skill in the art recognizes that the invention has applicability in any kind of IP-based core networks. use other communication protocols. Further, it is contemplated that any type of session establishment protocol, Internet Engineering Task Force (IETF), Session Initiation Protocol (SIP) or International Telecommunication Union (ITU) H.323 protocol may be used to practice the various modalities of the invention. (Also, it is contemplated that any type of session establishment protocol, Internet Engineering Task Force (IETF) Session Initiation Protocol (SIP) or International Telecommunication Union (ITU) H.323 protocol, can be utilized to practice the variousembodiments of the invention.)

In addition, the approach, according to various exemplary modalities, describes methods for disseminating presence information attributes in 3GPP (3rd Generation Partnership Project), IMS (IP Multimedia Subsystem) and 3GPP2 (3rd Generation Partnership Project) networks, MMD (Multimedia Domain). IMS provides Multimedia IP services, including (PoC), VoIP (Voice Over IP Protocol or Voice over IP) or packaged voice calls, instant messaging (IM), presence, group communications, and more. mobile devices. IMS uses, for example, the Session Initiation Protocol (SIP) as the signaling protocol, which is more fully described in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 3261 (which is incorporated, this document in its entirety by way of reference).

Figure 1 is a diagram of the radio communication system for supporting extended presence information attributes according to an embodiment of the invention. A wireless access network 101 provides access to parterminal access services 103, 105. In an exemplary embodiment, wireless access network 101 supports a group communication service - for example, Push to Talk (PoC) service; such as terminals 103, 105 are configured as PoC clients (ie PoC terminal). By way of illustration, the PoC 105 terminal is served by means of a PoC 107 network.

An important aspect of PoC service is the presence (then availability) determination of terminals 103, 105. Presence availability is supported through presence server 111, which is an entity that accepts, stores, and distributes presence information, Presence information, according to one embodiment, may be supplied by an application server 109 to a presence server 111 for publication to terminals 103, 105 (i.e. observers).

Each of the PoC 103, 105 terminals can support such hardware capabilities as a speakerphone and / or headset, as well as software that provides the ability for the user to configure the PoC 103, 105 terminal, to immediately accept bootstrap initiations. session and play the media as soon as it is received without requesting the intervention of the called user. This mode of operation is known as auto respond mode or auto mode. Alternatively, the user may configure the PoC 103, 105 terminal to first alert the user and request that the user manually accept the session invitation before accepting the media. This mode of operation is known as automatic response mode. The PoC 1033,105 terminal can support both or only one of these modes of operation. For example, the user may promptly change the Response Mode (AM) setting of the PoC 103 terminal, 105 based on current circumstances and preferences (for example, the user is currently busy or has moved to a public area so that it is not appropriate). the use of a speakerphone).

Each of the PoC terminals 103, 105 may further be configured as a Session Initiation Protocol (SIP) user agent (UA). As a SIP US, the PoC terminal 103, 105 may session to one or more SIP USs simultaneously; This communication can start through the user pressing a "talk" button. SIP 103, 105 PoC terminals can support various SIP-based communication services, as well as Push-to-Talk (eg, VoIP telephony, presence services, messaging services, etc.). The user may from time to time want to disable Accept Push-to-Talk sessions while keeping SIP registered for one or more other SIP-based services. When configuring the PoC terminal to not accept any Push-to sessions -Inbound Speak, refers to this setting as Inbound Session Lock (ISB).

Additionally, the user may wish to make contact with a user who has a PoC terminal with Input Session Lock enabled. In this context, the user may send an Instant Personal Alert to this other user to indicate that a PoC Session is requested. This Instant Personal Alert is received even when the target PoC terminal has enabled Inbound Session Lock.

If a user wishes to disable acceptance of Instant Personal Alerts, the user may configure the PoC terminal not to accept any Instant Personal Alerts received; This is known as an Instant Personal Alert Block (IAB).

In order to provide the user with a satisfactory communication experience, the delay in establishing the initial session should be reduced from the moment the user pushes the button until the user receives a paraphrase indication. A contributing factor to such a delay is the determination of the target user's presence.

The Open Mobile Alliance (OMA) has defined a collection of PoC service support requirements. In particular, the "OMA SIMPLE Presence Activator (Open Mobile Alliance)" defines the Presence Information Element called "Application Specific Availability". This element indicates whether it is possible to receive a communication input request that uses the specified device and services (if specified). For example, if a presence entity (for example terminal 3) is provided with the PoC service and meets one or more conditions (for example, that it is within network coverage 101 and is an appropriate handset, - in terms of hardware and / or software - etc.), the user would be "available" for the PoC service. However, if any of these conditions are not true, the user would be "unavailable".

The "OMA SIMPLE Presence Activator" also defines that "Application Specific Availability" must be mapped to a Presence Information Data Format (PIDF), and the data format uses the following scheme: ctuple> -> Cstatus> -> Cbasic> -> Open / Closed and Cservice-description>. However, such a scheme is known to be unduly restrictive. That is, by using the Cbasic> "open" and "closed" binary values for availability, the observer's understanding of what might be expected for the future value of availability is limited.

In the case of the OMA PoC service, user availability is set to "closed" when logging itself off, but it is also set to "closed" when the user triggers the Inbound Session Lock flag (or indicator) ( ISB). These two cases represent different user behaviors, but with the OMA model, there is no way to differentiate between these different cases. Until the user is registered, the observer may expect that the PoC user may not be available at any very short time (for example, the user may be on vacation and the device may be turned off). However, when the ISB flag is on configured, the observer may expect that the unavailability is only temporary. In other words, the user will be available relatively relatively soon (for example, the user may be in an important meeting, and therefore has turned on the ISB since the user does not want to be disturbed / interrupted by anyone).

The approach according to one embodiment of the invention extends a basic type, registered state availability binary, locked state, and session participation information indicating more details of the availability information. In an exemplary embodiment, this information may be derived from the Session Initiation Protocol (SIP) registered state event packet. As explained earlier, terminals 103, 105 may employ SIP to establish and interrupt communication sessions between them. An important function of SIP is the registration operation, which provides the link between a SIP Uniform Resource Identifier (URI) (that is, a registration address) and one or more URI contacts. The SIP REGISTER method allows a user agent to handle records; For example, contacts can be added or removed, and policies can be implemented to prevent unauthorized access. Under the SIP protocol, records expired after a certain time, and thus need to be updated to take effect.

Figure 2 is a diagram of a registration procedure for osterminals in the system of Figure 1. The registration state event package is detailed in IETF RFC 3680, entitled "A Session Initiation Protocol (SIP) Event Package", which is incorporated in the present in its entirety by way of reference. RFC3680 defines the following event states: Init state ("Initial") 201, an Active state203, and an Ended state 205. However, only the Active and Ended states are useful for determining presence availability. The finitestate machine 200 for the registration procedure is illustrated with the events that are pertinent to providing presence information. This finite state machine 200 represents a per-contact state machine, so that the machine is instantiated when the contact is registered, and erased when the contact is overflowing. When there are no contacts registered at the registration address, the state machine is in Init state. When a contact registers at the registration address, state machine 200 performs transitions from Init 201 state to Active state 203. That is, when a new contact and transactions are added to Active state 203, the finite state machine for that state. reason is instantiated and transactions remain in Active state 103). State machine 200 remains in Active state203 if there is at least one contact linked to the registration address. When the last contact expires or is removed, the record transitions to the Terminated 205 state.

According to one embodiment of the present invention, application server 109 (of Figure 1) may be a subscriber to the registration event packet.

A notification is generated to subscribers when any event occurs, either on contact state machines or registration address machines. Events of interest include: the registered, updated, expired, unregistered, and rejected. Certain registration states, for example Active state 203, and Terminated state 205, can be mapped to presence information.

In addition, for the OMA PoC service, additional availability information is defined to represent the following status information: Inbound Session Lock (ISB), Instant Personal Alert Lock (IAB), and the maximum allowable amount of concurrent PoC sessions has been reached. (or current).

Figures 3A and 3B are process flow charts for providing extended presence information in accordance with one embodiment of the invention. According to one embodiment of the invention, application server 109 may follow the IP Multimedia Subsystem (IMS) architecture. The interaction between application server 109 (for example, PoC server) and presence server 111 in providing presence information is explained as follows.

At step 301, the application server 109 can subscribe to a registration state event package, such as to receive event change updates (or updates). It is recognized that registration status could be viewed as a kind of presence information, but it is not directly usable for presence, as presence server 111 expects all publications to be provided in a rigid, prescribed format - for example, Presence Information Data Format (PIDF). The procedures for how an application server signs state event packets are detailed in 3GPP TS 34.229 and 3GPP2 X.SOO13-004-A, which are hereby incorporated by reference in their entirety.

According to one embodiment of the invention, the application server 109 uses the registration state (e.g. as defined in RFC 3680) as input for presence information. In other words, the registration state is mapped to presence availability (per step 303), thereby providing an additional value for availability. Presence information is then published according to the prescribed format, as in step 305.

Alternatively, the application server 109 itself may be aware of the state information (a context described in Figure 3B). For example, given that application server 109 is a PoC server, ISB or IAB indicators can be directly configured on PoC server 109 by using a PoC configuration event package. Under this context, the lock state (step 311), that is, the state of the ISB or IAB indicators, as configured by mobile terminal 103 is determined. On another occasion, considering that the application server 109 is a PoC server, The PoC Server determines whether the PoC User has reached the maximum allowable amount of concurrent PoC sessions (step 311).

When the application server 109 knows the state information, the application server 109 can directly map the attribute to the appropriate presence format and publish the attribute as presence information (as availability extension), by step 313.

According to one embodiment of the invention, the presence server 111 uses the Presence Information Data Format (PIDF) to collect presence information. The PIDF is defined in RFC 3863, entitled "Presence Information DataFormat (PIDF)" (which is incorporated herein by reference in its entirety). Then, the PIDF, in an exemplary embodiment, can be extended as registration state, block state, and session attendance information. The Extensible Markup Language (XML) scheme for this information can be defined as an extension to PIDF. In an exemplary embodiment, you can specify three extension values, <registration-state>, <barring-state>, and <session-participation>.

Table 1 describes an XML schema definition (Extensible Markup Language):

<? xml version = "l.0" encoding = "UTF-8"?> <xs: schema

targetNamespace = "urn: oma: params: xml: ns: pdif: oma-pres" xmlns: xs = ° http: //www.w3.org/2001/XMLSchema "xmlns =" urn: oma: params: xml: ns : pidf: oma-pres "elementFormDefault =" qualified "attributeFormDefault =" unqualified ">

<! - This import brings in the XML language attribute xml: Iang -> <xs: import namespace = http://www.w3.org/XML/1998/namespace"schemaLocation="http://www.w3 .org / 2001 / xml.xsd "/>

<xs: annotation>

<xs: documentation xml: lang = "en">

XML Schema Definition for OMA Extensions for PIDF and Presence Data Models

</ xs: documentation> </ xs: annotation>

<xs: element name = "registration-state"> <xs: simpleType>

<xs: restriction base = "xs: string"> <xs: enumeration value = "active" /> <xs: enumeration value = "terminated" /> </ xs: restriction> </ xs: simpleType> </ xs: element>

<xs: element name = "barring-state"> <xs: simpleType>

<xs: restriction base = "xs: string"> <xs: enumeration value = "active" /> <xs: enumeration value = "terminated" /> </ xs: restriction> </ xs: simpleType> </ xs: element>

<xs: element name = "session-participation"> <xs: complexType> <xs: sequence>

<xs: element name = "basic" type = "basicType" minOccurs = "0" />

<xs: element name = "max" type = "emptyType" /> <xs: any namespace = "## other" processContents = "lax" minOccurs = "0" maxOccurs = "unbounded" /> </ xs: sequence> </ xs: complexType> </ xs: element>

<xs: simpleType name = "basicType">

<xs: restriction base = "xs: strinq"> <xs: enumeration value = "open" /> <xs: enumeration value = "closed" /> </ xs: restriction * </ xs: simpleType>

<xs: complexType name = "emptyType" /> </ xs: schema> Table 1

In one example, the PoC user becomes unavailable due to non-registration: <registration-state> terminated </registration-state> is mapped from the PoC settings event package. Table 2 shows the associated XML:

<table> table see original document page 13 </column> </row> <table>

Table 2

In another example, PoC session service becomes unavailable due to the ISB flag setting: <registration-state> active </registration-state> is mapped from the record state event package, <barring-state> </barring-state> is mapped from the PoC configuration event package. Table 3 shows the associated XML:

<table> table see original document page 13 </column> </row> <table> <ορ: service-id> org.openmobilealliance: PoC-Session </ op: service-id>

<op: version> l.0 </ op: version>

_ <lr> p · toi-iri fo-Hogfript · i r> n ~> _

<contact> sip: my_name @ example. com <: / contact> <timestamp> 2005-02-22T20: 07: 07Z </timestamp> </tuple> </presence>

Table 3

In another example, PoC session service becomes unavailable due to the fact that the maximum number of concurrent PoC sessions has been reached: PoC server 109 publishes the <session-participation> element to indicate this. Table 4 shows the associated XML:

<? xml version = "l.0" encoding = "UTF-8"?> <presence xmlns = "urn: ietf. -parns: xml: ns: pidf"

xmlns: op = "urn: oma: params: xml: ns: pidf: oma-pres" entity = "sip: someone@example.com">

<tuple id = "al231"> <status><basic>closed</basic> </status>

<op: registration-state> active </ op: registration-state> <op: barring-state> terminated </ op: barring-state> <op: willingness>

<op: basic> closed </ op: basic> </ op: willingness> <op: session-participation>

<op: basic> open </ op: basic> <op: max /> </ op: session-participation> <op: service-description>

<op: service-id> org.openmobilealliance: PoC-Session </op: service-id>

<op: version> l.0 </ op: version> </ op: service-description>

<contact> sip: my_name @ example. com </contact> <timestamp> 2005-02-22T20: 07: 07Z </timestamp> </tuple> </presence>

Table 4

Still, in another context, the PoC Alert Service is unavailable because the IAB flag is set to "on": <registration-state> active </ registration-state> is mapped from the registration state event package, <barring -state> active </barring-state> is mapped from the PoC configuration event package. Table 5 shows the associated XML: <table> table see original document page 15 </column> </row> <table>

Table 5

Figure 4 is a diagram of an exemplary Push-to-Talk via Cellular (PoC) architecture capable of supporting presence service according to one embodiment of the invention. In order to support PoC service, a PoC 401 client and a PoC 403 server contact a presence model 405 to ensure recognition of presence information about the PoC client. Presence module 405 (which may be arranged as a presence server) is an entity that accepts, stores, and distributes presence information about PoC clients. Presence information can be published through the PoC 403 server in favor of the PoC 401 client.

This information may be signed by an observer, or by the PoC server 403, rather than the PoC 401 client. According to various embodiments of the invention, state information (such as registration state, lock state, session participation) is Factors (decomposed into factors) in determining the PoC 401 client presence availability. As shown, for example, the ISB 407a flag or the ISB 407b flag can be used to provide additional availability information.

The 405 presence module interacts with a 409 XML Document Management (XMD) module, which manages XML documents stored on the network (for example, PoC specific documents, URI contact list, etc.). Among other management functions, the XMD 409 module can subscribe to changes made to these XML documents, where notifications are received when document changes occur. The XDM 409 module can be implemented in a fixed terminal, or in a user equipment.

The capabilities of PoC client 401 and presence server 405 to support PoC service will be explained later. The PoC 401 client can access PoC service, and can be located within an access terminal (for example, mobile) as shown in Figure 1. The PoC 401 client is configured to provide PoC initiation and session release as well as for perform registration, for example, with a SIP / IP 411 core. The PoC 401 client can also perform user authentication for the SIP / IP 411 core. In addition, the PoC 401 client generates and speech triggers (that is, traffic PoC) when using protocols and associated procedures - for example, speech trigger control procedures; speech triggering protocol negotiation; ability to configure Response Mode Indication (Manual Answer, Auto Answer); Entry Session Lock, and Instant Entry Personal Alert Lock; support of concurrent PoC sessions; and level user adaptation procedures if initiated through the PoC 403 server.

The PoC 403 server provides two main functions for enabling PoC service: a control PoC function, and a participation PoC function. Private (control and attendance) functions for the PoC 403 server are determined during PoC Session setup and remain configured for session length. In a PoC session, there is a 403 PoC server that performs the control PoC function; however, there may be one or more PoC servers that perform the PoC function of participating in the PoC session.

As part of the responsibilities for performing the control function, the PoC 403 server can manage an N number of SIP sessions and speech trigger control media and communication paths in a PoC Session, where N is a number of participants in the PoC session. In these functions, the PoC server 403 can route media-related signaling media, such as speech trigger control messages, to the PoC client 401 via a PoC server that is performing attendance PoC operation to a PoC client. In this example, it is assumed that the 403 PoC server that is performing the control function, and another (not shown) PoC server considers the participation function. The PoC server running the participating PoC function can allow the PoC 403 server (which performs the control PoC function) to have a direct media communication path and media related signaling for each PoC 401 client. Note that the PoC server 403 does not have direct communication with PoC client 401 for PoC session signaling; however, the PoC server communicates with the PoC 401 client when it performs membership operation for the PoC 401 client.

In addition, as mentioned, the PoC 403 server may consider the functions of an observer. In this position, server 403 may request presence information from the presence server (e.g. presence module 405) in order to provide presence attribute mediation for execution of PoC session policy (e.g. PoC client situation " non-accessible ", enforce PoC client PoC presence settings, etc.). Note that the PoC 403 server may support policy enforcement to handle the PoC session based on general presence or PoC related information.

As shown, a 413 Discovery and Registration module performs SIP Core SIP / IP 411 registration, indicating PoC service support in the registration request. After successful registration of the PoC user, communication can be initiated. In addition, an authentication / authorization module 415 provides PoC client authentication 401 for PoC server access.

By way of illustration, elements of presence information and presence procedures are described in the context of the OMA PoC service. A Presence elements setting is specified to express the PoC user Presence situation. Table 6 lists the presence element mapping for the respective presence information elements.

ELEMENT

<table> ELEMENTS table see original document page 18 </column> </row> <table>

Table 6A "PoC Session Service Availability" can be mapped by the "Application Specific Availability" presence information element, which belongs to the "PoC session" service, by Table 7:

<table> table see original document page 19 </column> </row> <table>

Table 7

You can map the presence information element "Availability to PoC Session Service" to the following: a required <status> element with <basic> element with the value "open"; an optional <registration-state> element with the value "active"; and an optional <barring-state> element with the value "finished".

The above mapping occurs if the presence entity is available for inbound PoC sessions. This occurs when the PoC user is registered, ISB is not enabled, and the maximum number of concurrent PoC sessions is not reached.

In addition, the presence information element of "Availability for PoC Session Service" can be mapped to a required <status> common subelement <basic> element with the value "closed" and an optional <registration-state> element with a value "terminated" "; or an optional <barring-state> element with the value "active"; or an optional <registration-state> element with the value "active" and an optional element <barring-state> with the value "terminated". Through this scenario, the presence entity is unavailable for inbound PoC sessions. This occurs when the PoC user is not registered; ISB is enabled; or if you reach the maximum amount of simultaneous PoC sessions.

"PoC Alert Service Availability" can be mapped to the "Application Specific Availability" presence information element that belongs to a "PoC Alert" service by Table 8: <table> table see original document page 20 </ column> </row> <table>

If the presence entity is available for PoC Instant Alerts, you can map the "PoC Alert Service Availability" presence information element to one of the following: a <status> mandatory element with a <basic> subelement with the value "Open"; and an optional <registration-state> element with the value "active"; or an optionalCbarring-state> element with the value "terminated".

The above condition occurs when the PoC user is registered and Instant Personal Alerts (IAB) Blocking is not enabled.

However, if the presence entity is unavailable for PoC Instant Personal Alerts, the presence information element "Availability for PoC Alert Service" can be mapped to a required <status> element with a "terminated" value; or an optional <barring-state> element with the value "active". This scenario occurs when the PoC user is not registered or Instant Personal Alert Blocking (IAB) is enabled.

"PoC Session Attendance" can be mapped to the "Session Attendance" presence information element that belongs to a "PoCo session" service Table 9:

<table> table see original document page 20 </column> </row> <table>

Table 9

You can map the presence information element "PoC Session Participation" to a common <session-participation> sub-element <basic> with the value "open" if the presence entity is participating in at least one PoC Session but the maximum number of concurrent PoC sessions allowed has not been reached. The presence information element "PoC Session Participation" can be mapped to a <session-participation> element with a <basic> subelement with the value "open" and a <max> subelement if the presence entity has reached the maximum amount of concurrent PoC sessions allowed.

On the other hand, the presence information element "PoC Session Participation" can be mapped to a <session-participation> element with a <basic> element with the value "closed" if the presence entity is not participating in any PoC Session.

With respect to the PoC server procedure, if the PoC 403 server that performs the Participation PoC Function, for example, on the user's Home PoC NetworkPo supports publishing Presence Information for the benefit of the PoC 401 client, the PoC 403 server can publish the elements. presence information indicated on a 'PRES-SRV-CAP' which provides parameters sent to the PoC 401 client.

<table> table see original document page 21 </column> </row> <table> <table> table see original document page 22 </column> </row> <table> <table> table see original document page 23 < / column> </row> <table> <table> table see original document page 24 </column> </row> <table> <table> table see original document page 25 </column> </row> <table>

Table 10

As noted, the PoC 403 server can act as a source of presence and publish certain sets of presence information for the benefit of the PoC401 client. Examples include the following procedures: PoC registration and deletion, and Incoming Session Lock (ISB), Instant Incoming Personal Alert Lock (IAB), and PoC Session status. These procedures can apply when the PoC 403 server acts as a presence source and supports the publication of the presence information elements as specified in Table 10.

Note that at the time that the SIP / IP Core 411 corresponds to 3GPP / 3GPP2 IMS, the PoC 403 server may use the "AS queage as originating User Agent" procedures defined in 3GPP TS 24.229 / 3GPP2X.SOO13 -004-A (which is incorporated in the present in its entirety by way of reference) when acting as a source of presence.

By accepting a registration request from a PoC user, the PoC 403 server can act as a presence source, in which case the PoC403 server can perform presence information publishing and can configure the values of the following elements ( as specified in Table 10): "PoC Session Service Availability" presence information element; and presence information element of "PoC Alert Service Availability". In addition, the PoC server 403 can set the presence entity <entity> element to the PoC user authenticated identity value that has registered with the PoC service (for example, for the value of the P Affirmed Identity header fieldREGISTRAR) . In addition, PoC server 403 can set the presence information element "PoC session participation" to closed (as defined in Table 10). It has been noted that other Presence information elements may be published with the appropriate values at the same time.

By accepting a deletion request from a PoC user, the PoC server 403 can perform Presence information publishing, and can configure both the value of the "Availability for PoC Session Service" presence information element and the presence information element value "PoC Alert Service Availability" to unavailable. The PoC server 403 may further set the Presence Information <entity> element to the PoC user's authenticated identity value that has been registered from the PoC server (for example, to the value of the P-Affirmed Identity header field) request to REGISTER). In addition, PoC server 403 can set the presence information element "PoC Session Attendance" to "closed".

By accepting a PoC user request to enable Inbound Session Blocking (ISB), PoC user 403, which acts as a presence source, can configure the value of the presence information element "Availability for PoC Session Service" to unavailable. Additionally, the PoC server 403 can configure the <entity> element of the presence information to the authenticated identity value of the PoC user publishing the ISB (for example, to the value of the P-Affirmed Identity header field of the PUBLISH request).

Also, a request from a PoC user to disable Inbound Session Blocking (ISB) triggers the PoC 403 server to perform presence information publishing, the PoC 403 server can set the value of the presence information element "Availability to Service". PoC "to available, and the presence entity <entity> element to the authenticated identity value of the PoC user publishing the ISB (for example, to the value of the P-Affirmed Identity header field of the PUBLISH request).

By accepting a request from a PoC user to enable Incoming Instant Personal Alert Lock (IAB), the PoC 403 server can set the presence information element "Availability for PoC Alert Service" to unavailable. In addition, the PoC server may set the presence information <entity> element to the value of the PoC authenticated identity of the IAB publishing user (for example, to the value of the P-Affirmed Identity header field of the PUBLISH request).

In response to a request from the PoC user to disable Incoming Instant Personal Alerts (IAB) Blocking, the PoC user can set the presence of the "PoC Alert Service Availability" presence information element value to available. Other than that, the PoC server 403 can set the presence entity <entity> element to the value of the authenticated PoC user identity publishing the IAB (for example, to the value of the P-Affirmed Identity header field of the PUBLISH request).

Also, when establishing or terminating a PoC Session, the PoC403 server can act as a source of presence. In this case, the PoC server 403 can set the presence information "PoC Session Attendance" to the appropriate value. Typically, PoC Session attendance information is published when the PoC user is connecting to the first PoC session or interrupting the last Session. PoC By determining that the PoC user has reached its maximum number of Concurrent PoC Sessions or by determining that the PoC user is no longer busy with the maximum number of concurrent PoC Sessions it can support, the PoC 403 server can act as a presence source and perform the publication of the information. presence. PoC Server 403 can set the presence information element "Availability for PoC Session Service" to the appropriate value (as specified in Table 10).

The PoC 401 client can collaborate with the presence source and observing entities when present on the same equipment as the user. When the PoC 403 server is unable to publish presence information for the benefit of the PoC user, then the presence source that is present on the same user equipment as the PoC 401 client may publish the presence information elements specified in the provider parameter ' PRES-SRV-CAP '.

One of ordinary skill in the art would recognize that processes to support presence information can be performed by software, hardware (eg general processor, Digital Signal Processing (DSP) chip, an Application Specific Integrated Circuit (ASIC) ), Field Programmable Port Arrangements (FPGAs), etc.), firmware, or a combination of them. Such an exemplary hardware for performing the functions described is detailed below with respect to Figure 5.

Figure 5 illustrates exemplary hardware to which various embodiments of the invention may be applied. A computing system 500 includes a bus 501 or other communication mechanisms for communicating information and a processor 503 coupled to bus 501 for processing information. The computing system 500 further includes main memory 505, such as random access memory (RAM) or other dynamic storage devices coupled to bus 501 to store information and instructions to be executed by processor 503. Main memory 505 may also be used to store temporary variables or other immediate information while executing instructions by the 503 processor. The computing system 500 may additionally include a read-only memory (ROM) 507 or other static storage devices coupled to the bus 501 for storing static information and instructions for the processor 503. A storage device 509, such as a magnetic disk or optical disc, is coupled to the bus 501 for persistent storage of information and instructions.

The computing system 500 may be coupled via bus 501 to a display 511, such as a liquid crystal display, or active matrix display, for displaying information to a user. An input device 513, such as an alphanumeric keypad and other keys, may be coupled to bus 501 to communicate information and command selections to the 503 processor. Input device 513 may include a cursor control such as a mouse, trackball or cursor-direction keys to communicate direction information and command selections of processor 503 and to control cursor movement on display 511.

According to various embodiments of the invention, the described processes may be provided by a computing system 500 in response to processor 503 which executes a set of instructions contained in main memory 505. Such instructions may be read within main memory 505 from another computer-readable media, such as storage device 509. Performing the instruction set contained in main memory 505 causes processor 503 to perform the process steps described herein. One or more processors in a multiprocessing assembly may further be employed to execute the instructions contained in main memory 505. In alternative embodiments, wired circuitry may be used through hardware components in place or in combination with the instructions of the software to be in order to complete the embodiment of the invention.

In another example, reconfigurable hardware, such as Field Programmable Port Arrays (FPGAs) can be used, in which the functionality topology and connection of their logical ports are adaptable at runtime, typically through memory lookup tables. Programming Thus, the modalities of the invention are not limited to any specific combination of hardware and software circuits.

The computing system 500 further includes at least one communication interface 515 coupled to bus 501. Communication interface 515 provides a two-way data communication coupling for a network link (not shown). Communication interface 515 sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information. In addition, the 515 communication interface may include peripheral interface devices such as a Universal Serial Bus (USB) interface, a PCMCIA (International Personal Computer Memory Association) interface, etc.

Processor 503 may execute transmitted code as it is being received and / or store the code in storage device 509, or other non-volatile storage for later execution. In this way, the computation system 500 can obtain the application code in the form of a carrier wave.

The term "computer readable medium" as used herein refers to any medium that participates in providing instructions to the processor 503 for execution. Such medium can take many forms, including, but not limited to, nonvolatile media, volatile media, and broadcast media. Nonvolatile media includes, for example, optical or magnetic discs, such as the storage device509. Volatile media includes dynamic memory, such as 505 main memory. Transmission media includes coaxial cables, copper wire, and fiber optics, including wires consisting of the 501 bus. Transmission media can also take the form of acoustic probes, optical, or electromagnetic, such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer readable media include, for example, a floppy disk, a floppy disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, CDRW, DVD, any other optical medium, punched cards, paper tape, optical trademark sheets, any other physical media with orifice patterns or other optically recognizable evidence, the RAM, which is a PROM, and an EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave, or any other medium from which a computer can read.

Several forms of computer readable media may be involved in providing instructions to a processor for execution. For example, instructions for carrying at least part of the invention may initially appear on a magnetic disk of a remote computer. In such a context, the computer reloads the instructions into main memory and sends the instructions via a telephone line using a modem. A local system modem receives data on the telephone line and uses an infrared transmitter to convert the data to an infrared signal and transmits the infrared signal to a portable computing device, such as a personal digital assistant (PDA) or a laptop. An infrared detector on the portable computing device receives the information and instructions generated through the infrared signal and places the data on a bus. Bus drives data to main memory, from a processor retrieves and executes instructions. Instructions received through main memory can optionally be stored on the storage device both before and after execution by the processor.

Figures 6A and 6B are diagrams of different cellular mobile phone systems capable of supporting various embodiments of the invention. Figures 6A and 6B show exemplary cellular mobile phone systems, each with both a mobile station (e.g., headset) and a base station with an installed transceiver (as part of a Digital Signal Processor (DSP)). , hardware, software, an integrated circuit, and / or a semiconductor device at the base station and mobile station. By way of example, the radio network supports Second and Third Generation (2G and 3G) services as defined by the International Telecommunication Union (ITU) for International Mobile Telecommunications 2000 (IMT-2000). By way of explanation, the transport capacity and channel selection of the radio network is explained with respect to the cdma2000 architecture. Like the third generation version of IS-95, cdma2000 is being standardized on the Third Generation Partnership Project 2 (3GPP2).

Radio network 600 includes mobile stations601, (for example, handsets, terminals, stations, units, devices, or any type of user interface (such as "fit-for-use" circuits, etc.)) in communication with Base Station Subsystem (BSS) 603. According to one embodiment of the invention, the radio network supports Third Generation (3G) services as defined by the International Telecommunication Union (ITU) for International Mobile Telecommunication 2000 (IMT-2000).

In this example, BSS 603 includes a Base Transceiver Station (BTS) 605 and a Base Station Controller (BSC) 607. Although a single BTS is shown, it is recognized that multiple BTSs are typically connected to the BSC via, for example, peer-to-peer links. Each BSS 603 is connected to a Packet Data Service Node (PDSN) 609 via a transmission control entity, or a Packet Control Function (PCF) 611. Since the PDSN 609 serves as a gateway to external networks, For example, the Internet 613 or other private consumer networks 615, PDSN 609 may include an Access, Authorization, and Accounting (AAA) system 617 to securely determine a user's identity and privileges and to track each user's activities. The 615 network comprises a 631 Network Management System (NMS) connected to one or more 633 data banks that are accessed through the Home Agent (HA) 635 secured by a 637 Home AAA.

Although a single BSS 603 is shown, it is recognized that multiple BSSs 603 are typically connected to a Mobile Switching Center (MSC) 619.

The MSC 619 provides connectivity to a circuit switched telephone network, such as the Public Switched Telephone Network (PSTN) 621. Similarly, it is also recognized that the MSC 619 can be connected to other MSCs 619 on the same network 600 and / or. other radio networks. MSC 619 is generally powered by a Visitor Location Record (VLR) 623 database that holds temporary information about active subscribers to MSC 619. Data within the VLR623 database is, in the broadest sense. , a copied Local Subscriber Registration (HLR) 625 database, which stores detailed subscriber service subscription information. In some applications, the HLR 625 and VLR 623 are the same physical database; however, the HLR 625 may be arranged at a remote location accessed, for example, through a Number 7 Signaling System (SS7) network. An Authentication Center (AuC) 627 that contains specific subscriber authentication data, such as a secret authentication key, is associated with HLR 625 to authenticate users. In addition, the MSC 619 connects to a Short Message Service Center (SMSC) 629 which stores and forwards short messages to and from radio network 600.

During typical cellular telephone system operation, BTSs 605 receive and demodulate reverse link signal configurations from mobile units 601 conducting telephone calls or other communications. Reverse link signal received by a given BTS 605 is processed within this station. The resulting data is forwarded to BSC 607. BSC 607 provides call resource allocation and mobility management functionality, including orchestrating the lightweight transition procedures between BTSs605. BSC 607 further sends the received data to MSC 619, which in turn provides additional route and / or switching to the interface with PSTN 621. OMSC 619 is further responsible for call setup, call termination. , automatic change management of inter-MSC and complementary services, and by collecting, altering and accounting information. Similarly, the radio network 600 sends forward link messages. PSTN 621 interfaces with MSC619. The MSC 619 additionally interfaces with BSC 607, which in turn communicates with BTSs 605, which modulates and transmits directional signal configurations to the configurations of mobile units 601.

As shown in Figure 6B, the two key elements of the General Packet Radio Service (GPRS) infrastructure 650 are GPRS Support Service Node (SGSN) 632 and GPRS Gateway Support Node (GGSN) 634 In addition, the GPRS infrastructure includes a 636 Packet Control Unit (PCU) and a 638 charging gateway function (CGF) linked to the 639 Billing System. A 641 Mobile Station (MS) GPRS employs a Subscriber Identity Module (SIM) 643.

The PCU 636 is a logical network element responsible for GPRS-related functions such as air interface access control, air interface package scheduling, and packet assembly and reassembly. In general, PCU 636 is physically integrated with BSC 645; however, it can be arranged with a BTS 647 or SGSN 632. SGSN 632 provides functions equivalent to MSC 649, including mobility management, security, and access control functions but packet switched domain. In addition, SGSN 632 has connectivity to PCU636, for example via a Fame Relay based interface using the BSSGPRS protocol (BSSGP). Although only one SGSN is shown, it is recognized that multiple 631 SGSNs may employ and may divide the service area into routing areas (RAs). An SGSN / SGSN interface allows the package to pass from old SGSNs to new SGSNs when an RA update occurs during an ongoing Personal Development Planning (PDP) context. While a given SGSN can serve multiple BSCs 645, any given BSC 645 generally contacts common SGSN 632. Also, SGSN 632 is optionally connected to HLR 651 via an SS7-based interface, which uses Application Part. GPRS-enhanced Mobile Mapping (MAP) or MSC 649 through an SS7-based interface that uses Connection Signaling Control Part (SCCP). The SGSN / HLR interface allows SGSN 632 to provide location updates for HLR 651 and retrieve GPRS-related signature information within the SGSN service area. The SGSN / MSC interface enables coordination between circuit switched services and packet data services, such as establishing a subscriber radio communication for a voice call. Finally, SGSN 632 contacts a SMS 653 to enable short message functionality across the 650 network.

The GGSN 634 is a portal to external packet data networks, such as the Internet 613 or other private consumer networks 655. Network 655 comprises a Network Management System (NMS) 657 connected to one or more data banks 659 accessed through a PDSN 661. GGSN 634 designates Internet Protocol (IP) addresses and can also authenticate users acting as a Dial-Up Remote Authentication Service host. Jirewalls located on GGSN 634 can also perform a security barrier function to restrict unauthorized traffic. Although only a GGSN 634 is shown, it is recognized that a given SGSN 632 may contact one or more GGSNs 633 to allow user data to pass between the two entities as well as to and from the 650 network. External data networks initiate sessions through the GPRS 650 network, GGSN 634 requests HLR 651 for SGSN 632 which currently serves an MS 641.

The BTS 647 and BSC 645 manage the radio interface, including controlling which Mobile Station (MS) 641 has access to the radio channel at any given time. These elements mainly relay messages between MS 641 and SGSN632. The SGSN 632 manages communications with an MS 641, sending and receiving data and keeping track of this location. SGSN 632 still registers MS 641, authenticates MS 641, encrypts data sent to MS 641.

Figure 7 is an exemplary component diagram of a base station (e.g., handset) capable of operating in the systems of Figures 6A and 6B according to an embodiment of the invention. In general, a radio receiver is often defined in terms of the front end and rear end characteristics. The front end of the receiver covers all Radio Frequency (RF) circuits whereby the rear end covers all baseband processor circuits. Internal components pertinent to the phone include a 703 Main Control Unit (MCU), a 705 Digital Signal Processor (DSP), and a receiver / transmitter unit that includes a microphone gain control unit and a high gain control unit. -speaker. A 707 main display unit provides a display for the user to assist with various mobile station applications and functions. An audio function circuit 709 includes a microphone 711 and a microphone amplifier that amplifies the speech signal output from microphone 711. The speech signal output from microphone 711 is provided for a codec / decoder (CODEC) 713.

A radio station 715 amplifies power and converts frequency in order to communicate with a base station, which is included in a mobile communication system (e.g., systems of Figures 6A and 6B), by means of an antenna717. Power amplifier (PA) 719 and transmitter / modulation circuits are optionally related to MCU 703, with an output from PA 719 coupled to duplexer 721 or circulator or antenna switching as known in the art.

In use, a mobile station user 701 speaks into the 711 microphone and their voice, along with any noise detected from the background environment, is converted into a voltagemanalog. The analog voltage is then converted to a digital signal via Digital to Analog Converter (ADC) 723. Control unit 703 sends the digital signal into the DSP 705 for processing within it, such as speech coding, channel coding , encryption, and interleaving. In the exemplary embodiment, voice signals processed by means of units not shown separately using the Code Division Multiple Access (CDMA) cellular transmission protocol are coded as described in detail in the Base Station-Mobile Station Compatibility Standard. for TIA / EIA / IS-95-A Broadband Dual Mode Broadband Spectrum Cellular System of the Telecommunication Industry Association; which is incorporated in its entirety into the present by reference.

The coded signals are then routed to an equalizer 725 to compensate for any frequency dependent damage that occurs during transmission through air, such as phase and amplitude distortion. After equalizing a bit stream, the modulator 727 combines the signal with an RF signal generated at the RF interface 729. The modulator 727 generates a sine wave by frequency or phase modulation. In order to prepare the signal for transmission, an upconverter 731 combines where sine output from the modulator 727 with another sine wave generated by a synthesizer 733 to achieve the desired frequency of transmission.

The signal is then sent through a PA 719 to increase the signal to an appropriate power level. In practical systems, the PA 719 acts as a variable gain amplifier, the gain of which is controlled by the DSP 705 from information received from a network base station. The signal is then filtered into the duplexer 721 and optionally sent to an antenna coupler 735 to match impedances to provide maximum power transfer. Finally, the signal is transmitted by antenna 717 to a local base station. An automatic gain control (AGC) can be provided to control the gain of the receiving end stages. The signals may be forwarded thereafter to a remote telephone, which may be another mobile telephone, another mobile telephone or a fixed line connected to a Public Switched Telephone Network (PSTN), or other telephone networks.

The antenna 717 receives voice signals transmitted to mobile station 701 and immediately amplified by a low noise amplifier (LNA) 737. A downconverter 739 reduces the conductive frequency as the modulator 741 pulls out the RF leaving only a digital bit stream. Then, the equalizer footprint signal 725 and is processed by the DSP 1005. Utn Analog to Digital Converter (DAC) 743 converts the signal and the resulting output is transmitted to the user via speaker 745, all under the control of a Master Control Unit. (MCU) 703 - which can be implemented as a Central Processing Unit (CPU) (not shown).

The MCU 703 receives various signals, including input signals from the 747 keypad. The MCU 703 delivers a display command and a decoder command to the display 707 and the speech output switching controller, respectively. In addition, the MCU 703 exchanges information with the DSP 705 and can optionally access a built-in 749 SIM card and 751 memory. In addition, the MCU 703 performs various control functions required from the station. The DSP 705 may, depending on the application, perform any of a variety of conventional digital processing functions on voice signals. Additionally, the DSP 705 determines the background noise level of the local environment of the signals detected via home phone 711 and sets the microphone gain 711 to a selected level to compensate for the natural tendency of the mobile station 701 user.

CODEC 713 includes ADC 723 and DAC 743. Memory 751 stores various data, including incoming call tone data, and is capable of storing other data, including music data received, for example, via the Internetglobal. The software module is located in RAM, memónaflash, registers, or any other recordable storage medium known in the art. However, the 751 memory device may not be limited to a single memory, CD, DVD, ROM, RAM, EEPROM, optical storage, or any other non-volatile storage medium capable of storing digital data.

An optionally incorporated SIM card 749 carries, for example, important information such as cell phone number, driver service, subscription details, and security information. The SIM749 card is primarily for identifying mobile station701 in a radio network. The card 749 further contains a memory for storing a personal telephone number record, text messages, and user specific mobile station settings.

Figure 8 shows a corporate network, which can be any type of data communication network that uses packet based and / or cell based technologies (for example, Asynchronous Transfer Mode (ATM), Ethernet, IP based, etc.). . The corporate network 801 provides connectivity to 803 wired nodes, as well as 805 to 809 wireless nodes (fixed or mobile), which are configured to perform the above-described process. The corporate network 801 can communicate with a variety of other networks, such as a WLAN 811 network (eg, IEEE 802.11), a cdma2000 813 cellular network, a 815 telephone network (eg PSTN), or a public network. 817 (for example, Internet).

Although the invention has been described in connection with a number of embodiments and applications, the non-limiting invention, however, protects several obvious modifications and equivalent arrangements which are contained within the scope of the appended claims. Although features of the invention are expressed in certain combinations within the claims, it is contemplated that such features may be arranged in any combination and order.

Claims (48)

Method, characterized by the fact that it comprises: - determining an event that affects the availability of a terminal in a communication network; e- generating a message containing event information, wherein the message is used to provide reference presence information to the terminal. A method according to claim 1 further comprising: - transmitting the message to a configured presence server to distribute the presence information, - wherein the message is has a format that conforms to the Presence Information Data. A method according to claim 1 wherein: the terminal is configured to use a group communication service supported by the communication network, and - presence information is used to determine terminal availability for the service. of group communication. A method according to claim 3 further comprising: - verifying the configuration of an input session lock indicator corresponding to the terminal, - wherein the input session lock indicator specifies that the terminal is configured not to accept incoming group communication sessions and - generate presence information based on the setting of the Incoming Session Lock indicator. A method according to claim 3 further comprising: - verifying the configuration of an instantaneous Personal Alert lock indicator corresponding to the terminal and - generating presence information based on the configuration of the personal alert lock indicator instantaneous. A method according to claim 3 further comprising: - receiving an event attribute associated with the event according to a signature, - the event attribute specifies one of, a registered state, an updated state, a expired state, or a rejected state corresponding to the terminal register in the communication network, - wherein the registration is based on the Session Initiation Protocol (SIP), and - mapping the event attribute to the presence information. A method according to claim 3 further comprising: determining whether the terminal is available based on a criterion, which criterion includes configuring the terminal or being within a radio network coverage area. A method according to claim 3 wherein the information includes a number of current communication sessions allowed. A method according to claim 3 further comprising: - verifying the support configuration of the simultaneous group communication sessions and: - generating the presence information based on the support configuration of the simultaneous group communication sessions. A method according to claim 3, wherein the group communication service includes a Cellular Push-to-Talk (PoC) service. A method according to claim 1 further comprising: - directly generating an event attribute for the event and - publishing the event attribute as the presence information. 12. Apparatus, characterized in that it comprises: - a processor configured to determine an event affecting the availability of a terminal in a communication network, and - generating a message including event information, the message of which is used to provide presence information with relation to the terminal. Apparatus according to claim 12, characterized in that it further comprises: - a processor-coupled communication interface configured to transmit the message to a presence server that is configured to distribute presence information, - wherein the message has a format that conforms to the Presence Information Data Format. Apparatus according to claim 12, characterized in that: - the terminal is configured to use a group communication service supported by the communication network, and - presence information is used to determine terminal availability for the service. of group communication. Apparatus according to claim 14, characterized in that: the processor is also configured to verify the configuration of an input session lock indicator corresponding to the terminal, - and the input session lock indicator specifies that the terminal is configured not to accept incoming group communication service sessions, - and the processor further generates presence information based on the input session block indicator setting. 16. Apparatus according to claim 14, characterized in that the processor is also configured to: - verify the setting of the instantaneous personal alert lock indicator corresponding to the terminal, - and the processor further generates the information Presence settings based on the instant personal alert lock indicator setting. Apparatus according to claim 14, characterized in that the processor is also configured to: - receive an attribute of an event associated with the event according to a signature, - the event attribute specifies one of a state an updated state, an expired state, or a rejected state corresponding to the terminal register within the communication network, - where the registration is based on a Session Initiation Protocol (SIP), - the processor is still configured to map the doevento attribute to presence information. 18. Apparatus according to claim 14, characterized in that: - the processor is also configured to determine whether the terminal is available based on a criterion, the criterion of which includes the terminal configuration or network coverage area. radio Apparatus according to claim 14, characterized in that the information includes the amount of current communication sessions allowed. Apparatus according to claim 14, characterized in that the processor is also configured to verify the support configuration for simultaneous group communication sessions and, - generate presence information based on the configuration of the communication session support. simultaneous group Apparatus according to claim 14, characterized in that the group communication service includes a Push-to-Talk Cellular (PoC) service. Apparatus according to claim 12, characterized in that the processor is also configured to directly generate an event attribute for the event, the event attribute of which is disclosed as presence information. Apparatus according to claim 12, characterized in that it further comprises: - means for directly generating an event attribute for the event, - wherein the event attribute is disclosed as the presence information. System, characterized in that it comprises an apparatus according to claim 1 and the presence server. 25. Method, characterized in that it comprises: - registering with a communication network to communicate through the communication network, wherein: - an event associated with the registration is used to determine the availability for a communication service supported by the network. communication, - an application server that generates a message including event information, - wherein the message is used to provide presence information referring to the communication service. A method according to claim 25, wherein the message is transmitted to a configured presence server for distributing presence information, - wherein the message has a format that conforms to the Data Information Format. Presence. A method according to claim 25 wherein the communication service includes a group communication service and, the communication network includes a radio network. A method according to claim 27 further comprising: - configuring an inbound session lock indicator to indicate non-acceptance of group communication sessions, wherein the presence information is based on the configuration. inbound session lock indicator. A method according to claim 27, further comprising: - configuring an instant personal alert block indicator to specify an instant personal alert block, - wherein the presence information is based on the configuration of the indicator instant personal alert lock. A method according to claim 27, wherein: - the event is one of a registered state, an updated state, an expired state, or a rejected state from the registration, - the registration being based on the Protocol. of Session Initiation (SIP). A method according to claim 27 wherein the availability is based on a criterion that includes configuration information for operating within the radio network or within the coverage area of the radio network. Method according to claim 27, characterized by the fact that the information includes the amount of current communication sessions allowed. A method according to claim 27, further comprising: - configuring an indicator of simultaneous group communication sessions, wherein the presence information is based on the configuration of the indicator simultaneous group communication sessions. The method of claim 27 wherein the group communication service includes a Cellular Push-to-Talk (PoC) service. A method according to claim 25, wherein the application server is configured to directly generate an event attribute for the event and disclose the event attribute as presence information. 36. Apparatus, characterized in that it comprises: - a processor configured to initiate registration with a communication network via the communication network, - wherein an event associated with the registration is used to determine availability for a supported communication service. by the communication network, an application server that generates a message including information about the event, wherein the message is used to provide presence information relating to the communication service. Apparatus according to claim 36, characterized in that the message is transmitted to a configured presence server to distribute the presence information, - wherein the message has a format that conforms to Presence. Apparatus according to claim 36, characterized in that the communication service includes a group communication service. Apparatus according to claim 38, characterized in that: - the processor is also configured to determine an inbound session block indicator to indicate non-acceptance of inbound group communication sessions, - wherein Presence information is based on the incoming session lock indicator setting. Apparatus according to claim 38, characterized in that: - the processor is also configured to set an instant personal alert lock indicator to specify an instant personal alert block, - wherein the presence information is based on the instant personal alert lock indicator setting. 41. Apparatus according to claim 38, characterized in that the event corresponds to one of the registered state, an updated state, or a rejected state of the registration, - the registration being based on a Session Initiation Protocol ( SIP). Apparatus according to claim 38, characterized in that it further comprises: - a configured speaker releasing an audio signal corresponding to the traffic of the group communication service. 43. Apparatus according to claim 38, characterized in that: - availability is based on a criterion including configuration information to operate within the radio network or within the coverage area of the radio network. 44. Apparatus according to claim 38, characterized in that: - the information includes the number of current communications sessions allowed. 45. Apparatus according to claim 38, characterized in that: - the processor is also configured to verify the support configuration of the group communication sessions and, - generate the presence information based on the support configuration of the communication sessions. simultaneous group communication. 46. Apparatus according to claim 38, characterized by the fact that: - the group communication service includes a Cellular Push-to-Talk (PoC) service. Apparatus according to claim 36, characterized in that: - the application server is configured to directly generate an event attribute for the event and disclose the event attribute as the presence information. Apparatus according to claim 36, characterized in that it further comprises: means for directly generating an event attribute for the event, wherein the event attribute is disclosed as presence information.