WO2005107224A1

WO2005107224A1 - Process for compiling a protocol during a push-to-talk session with multiple participating communication units, communication units authorised to transmit, communication units authorised to receive and a protocol unit

Info

Publication number: WO2005107224A1
Application number: PCT/EP2005/050677
Authority: WO
Inventors: Andreas Schmidt; Norbert Schwagmann
Original assignee: Siemens Aktiengesellschaft
Priority date: 2004-04-27
Filing date: 2005-02-16
Publication date: 2005-11-10
Also published as: DE102004020533A1

Abstract

A process is disclosed for compiling a protocol during a push-to-talk session with multiple participating communication units. An exclusive transmission right for transmitting at least one useful message is allocated to only one of the communication units at a time for a duration of authorisation. During the duration of authorisation, only a reception right for receiving at least one useful message is allocated to the other communication units. Moreover, at least one useful message of the session is received by a protocol unit and stored in a protocol file on a storage module. The invention also relates to a communication unit authorised to transmit, a communication unit authorised to receive and a protocol unit for carrying out the claimed process.

Description

description

Method for creating a protocol for a push-to-talk session with several participating communication units, as well as for sending authorized communication units, for receiving authorized communication units and a protocol unit

Commercially available walkie-talkies, known for example under the name alkie-Talkie, enable voice messages to be sent to one or more call participants in real time. The speaker presses a special talk button while speaking. This blocks other participants from speaking. The transmission therefore takes place according to a half-duplex method. Communication services in the manner of the half-duplex method are also referred to as PTT services (PTT "push-to-talk"). Today's PTT services only allow the transmission of voice messages.

The object of the invention is to create a log of a PTT session with several participating communication units automatically and in a simple manner. This object is achieved by the following method according to the invention:

Method for creating a protocol for a push-to-talk session with several participating communication units, in that only one of these communication units is assigned an exclusive transmission right for the transmission of at least one user message for an authorization period, during which the other communication units only have a reception right of at least one User message is assigned, and in that a protocol unit at least receives a user message of the session and stores it in a log file on a memory module. The method according to the invention enables the protocol to be created in a push-to-talk session (PTT "push-to-talk") with a number of participating communication units. The number of participating communication units is not limited to a maximum number Communication devices that are already in use take part in a PTT session with the creation of a protocol, since no modifications to a communication device are necessary to participate.

Since the PTT session to be logged is automatically recorded by the logging unit, it is not necessary to select a secretary. The ProtokoUeinheit stores one or more user messages, e.g. Voice messages, in a log file. This log file comprises one or more characteristic features of the log, e.g. the date and time when the creation of the log was started or the duration of the log recording. On the basis of these characteristic features, it is possible at a later point in time to easily follow the course of a PTT session with several participating communication units.

Furthermore, the invention also relates to a communication unit authorized to send to participate in a push-to-talk session with the creation of a protocol, with a sending unit for transmitting at least one user message during an authorization period in which an exclusive right to send is assigned, during which the other communication units are only assigned a right to receive at least one useful message.

Furthermore, the invention also relates to a communication unit authorized to receive to participate in a push-to-talk session with the creation of a protocol, with a

Receiver unit for receiving at least one payload rests during an authorization period in which only one right of reception is assigned.

Furthermore, the invention also relates to a protocol unit for participating in a push-to-talk session with several participating communication units and for creating a protocol, with a receiving unit for receiving at least one user message, with a processing unit for storing at least one user message of the session in a log file on a storage medium, and with a storage module on which the log file can be stored.

Other further developments of the invention are reproduced in the subordinate sayings.

The invention and its developments are explained in more detail below with reference to drawings.

Show it:

1 shows a schematic representation of a section of a possible device for carrying out the method according to the invention with a plurality of communication units and a PTT server, which comprises a protocol unit, and with a plurality of communication messages which are transmitted between the communication units and the PTT server or the protocol unit as well as possible extensions,

Figures 2a-2b in a schematic representation of a possible structure of a log file and several associated elements and possible extensions and

FIGS. 3a-3n different SIP messages in XML syntax for controlling the protocol unit as well as for transmitting protocol information to the communication unit as well as possible extensions.

Elements with the same function and mode of operation are given the same reference numerals in FIGS. 1, 2a, 2b and 3a with 3n.

1. Overview of a PTT system

A section of a possible PTT system (PTT - "push-to-talk") can be seen in FIG. A service of a PTT system is called a PTT service. The PTT service is characterized in that a communication unit, e.g.

KE3, a group of communication units, e.g. KEl, KE2, KE3, for an authorization period, such as BT, an exclusive right to send user messages, such as NN1, NN2 is assigned. During this authorization period BT the other communication units, e.g. KE1, KE2, this group is only assigned a right to receive user messages NN1, NN2. The transmission takes place according to a half-duplex method. During a PTT session with several participating communication units KE1, KE2, KΞ3, they exchange at least one user message

NN1, NN2 off. The PTT service is carried out with the help of the PTT service. Further tasks of a PTT system are specified in the specification "Push-to-Talk Over Cellular" (POC), Architecture, Version 1.1.0, POC Release 1.0, at www.ericsson.com/multiservicenetworks/distr/ poc_specifications.zip.

The PTT system of Figure 1 consists of several communication units KE1, KE2, KE3 and a PTT server PS. This PTT system is organized in a star shape. The PTT server PS controls the PTT service and distributes one or more relevant communication messages to the communication unit. ten KEl, KE2, KE3. A communication message comprises either a control message or a user message NN1, NN2. A control message is to be understood as a message that contains information about the status of the PTT service or for controlling the PTT service. One or more control messages can be sent and received by one or more communication units and / or a PTT server at any time. In the following, a control message that is used to control a protocol unit PE is referred to as a control message SN1, SN2. In addition, a control message which contains protocol information from the protocol unit PE for the communication unit KE1, KE2, KE3 participating in the PTT session and is sent to it is referred to as a protocol message PN1, PN2. In contrast, the useful message NN1, NN2 is to be understood as a communication message which comprises useful data which the communication unit KE3 authorized to send sends to the other communication units KE1, KE3 participating in the PTT session and authorized to receive. These useful data include, for example, voice data and or image data.

The PTT server PS according to FIG. 1 comprises a transmission unit SEEP for sending at least one communication message and a reception unit EMEP for receiving at least one communication message. Furthermore, this has a processing unit VAEP for controlling the communication flow of the PTT service. The PTT server PS also contains the protocol unit PE for creating a protocol for the PTT session with several participants

Communication units KE1, KE2, KE3. In addition, it also includes a memory module SM for storing at least one user message NN1, NN2 in a log file PD. The PTT server PS also has a connection network VXP, which is used to exchange information between the receiving unit EMEP, the transmitting unit SEEP, the processing unit VAEP, the protocol unit PE and the memory module SM. According to FIG. 1, the protocol unit PE is integrated in the PTT server PS. Alternatively, the protocol unit PE can be implemented as an independent network unit, which is possibly connected to the PTT server PS via a communication link. Alternatively, the protocol unit KE, as an independent network unit, can have a receiving and transmitting device for receiving or transmitting communication messages. Alternatively, the protocol unit PE can also be accommodated in a communication unit, for example communication unit KE1. In FIG. 1, the memory module SM is integrated in the PTT server PS. Alternatively, the memory module SM can be connected externally to the protocol unit PE via a communication link.

The communication unit KE3 authorized to send comprises a sending unit SEE3 for sending at least one communication message and a receiving unit EME3 for receiving at least one communication message. Furthermore, it has a processing unit VAE3 for evaluating received communication messages and for creating at least one communication message to be sent. The transmission unit SEE3, the reception unit EME3 and the processing unit VAE3 are connected to one another via a connection network VX3, which is used to exchange information.

The communication unit KE1, KE2 authorized to receive comprises a sending unit SEE1 or SEE2 for sending at least one communication message and a receiving unit EME1 or EME2 for receiving at least one communication message. Furthermore, it has a processing unit VAE1 or VAE2 for evaluating at least one received communication message as well as for creating at least one communication message to be sent. The communication unit KE1, KE3 authorized to receive each comprises a connection network VX1 or VX2, which is used to exchange information between the receiving unit EME1 or EME2, the transmitting unit SEE1 or SEE2 and the processing unit VAE1 or VAE2 within the respective communication unit KE1, KE2 authorized to receive.

One or more of the communication units KE1, KE2, KE3 can be integrated in a mobile radio device according to the GSM standard (GSM - Global System for Mobile) or the UMTS standard (UMTS - Universal Mobile Telecommunications System). Alternatively, they can be implemented in a fixed network device according to the ISDN standard (ISDN - Integrated Subscriber Digital Network) or also in a computer unit which is connected, for example, to a public Internet and / or to an intranet.

The PTT service is preferably implemented using a packet-oriented system, such as the 3GPP-IMS (3GPP - "Third Generation Partnership Pro ect", IMS - "IP Multimedia Subsystem", IP - "Internet Protocol"). One or more communication messages can be transmitted here, in particular using the UDP / RTP protocol (UDP - "Unified Data Protocol", RTP - "Real-time Transport Protocol").

2. First execution example

1, a first exemplary embodiment for creating the protocol by the protocol unit PE during a PTT session with a number of participating communication units KE1, KE2, KE3 is explained in more detail below.

The communication unit KE2 initiates the establishment of a PTT session, with the two communication units KE1 and KE3 also taking part in this PTT session in addition to the communication unit KE2. To do this, it first sends a first invitation message TEN1 to the PTT server PS. As a result, the latter directs the invitation to participate in the PTT Session with the help of a second invitation message TEN2 to the communication unit KE3. The communication unit KE3 confirms its participation in the PTT session by transmitting a first invitation confirmation message TBN1. In a next step, the PTT server PS transmits a third invitation message TEN3 with the request to participate in the PTT session to the communication unit KE1. This confirms your participation by means of a second invitation confirmation message TBN2. After at least one of the communication units KE1, KE3 has participated in the

Has confirmed the PTT session, the PTT server PS notifies the communication unit KE2 of the establishment of the PTT session by a first confirmation message BN1.

After the first confirmation message BN1 has been transmitted, the protocol unit PE is initialized. Here, for example, the protocol unit PE is informed that the communication units KE1, KE2, KΞ3 participate in the PTT session to be logged.

2.1 The log file

According to FIG. 2a, the log file PD comprises a description part PDK and a message part PDN. The description part PDK comprises one or more descriptive features of the PTT session to be logged. At least one of the following descriptive features is used:

PTT session identity: a unique identifier for the PTT session, such as "Session_30.01.04".

Name for the group of communication units participating in the PTT session, e.g. "Group of department heads".

- Topic of the PTT session, such as "Budget planning for the coming fiscal year". Relationship information to another PTT session: this specifies the relationship between the PTT session currently being logged and another, for example earlier, PTT session, such as "Follow-up meeting of the PTT session with the PTT session identity <Sit- zung_21.01.04>".

Start and end time of the PTT session: Here, the date and / or time for the start and end time of the PTT session is given, such as "PTT session: Start: 1/30/2004 8:00 AM; End: 1/30/2004 9:25 AM".

Start and end time of logging: the start and end time of logging of the PTT session are communicated, which "may differ from the start and / or end time of the PTT session, such as" Logging: Start: January 30, 2004 8:05 a.m., end: 1/30/2004 9:05 a.m.

- List of participants: at least one communication unit participating in the PTT session, e.g. Communication unit KE1, KE2, KE3, registered. In addition, you can specify the time at which the respective communication unit participated in and / or left the PTT session. Here, for example, the time and date are specified. Alternatively, the time in relation to the start time of the PTT session can be specified, e.g. "Participation of KE2: start: 00:17; end 00:35". Thus, taking into account the start and end times of the PTT session, the communication unit KE2 has "PTT session: start: 1/30/2004 8:00; end: 1/30/2004 9:25" from 8:17 to 8:35 attended the PTT meeting.

The log file PD also includes the message part PDN. According to FIG. 2b, the message part PDN consists of at least one section. A section includes an el Spelling, for example NEBl, NEB2, and an associated message element, for example NEl, NE2. Thus, for example, a first section consists of the first element description NEBl and the associated first message element NEl. A message element comprises either the user message NN1, NN2 or a message link, for example VK1, VK2, to the associated user message NN1 or NN2. Instead of the user message NN1, NN2, the user data contained in the user message NN1, NN2 can also be stored in the associated message element NE1, NE2. The message link VK1, VK2 is preferably specified in the form of a URI (URI - "Uniform Resource Identifier"). Alternatively, the message link VKl, VK2 can also point to a memory address within the memory module SM at which the associated stored user message NN1 or

NN2 can be found. The element description NEB1, NEB2 includes further information on the associated message element NE1 and NE2. One or more of the following information is preferably contained in the element description NEB1, NΞB2:

- Identification feature of the subscriber or the communication unit: The useful message NNl, NN2 or the message element NEl, NE2 is a specific communication unit, e.g. KEl, c.-i assignable. This identification feature can be used to identify the participant's name, e.g. "John Smith", or the name of the communication unit, such as "KEl" included. In practice, it is also advantageous to assign a unique identification number for the associated element description in addition to the name, such as, for example, "John Smith - User Message 5".

- Start time and duration of the message element: This shows the time at which the useful message contained in this message element was recorded. The duration of this user message is also displayed. give. For example, the start time of this user message is displayed in the form of a relative time relative to the start time of the logging, such as "12 minutes and 23 seconds. The duration of this user message is, for example," 1 minute and 12 seconds ". Alternatively, it can be used instead of the duration User message the end time of this user message can be specified.

- Identification feature of the message element: This is a unique identification feature with which this message element or the useful message contained therein can be uniquely identified at a later point in time. For example, a consecutive number is assigned, e.g. "Message Element 217".

- Categorizing identifiers: Here, the protocol unit PE or another external network element may generate one or more identifiers that assign this message element or the useful message contained therein to a category. The first message element NE1 may be assigned to the category "proposal for budget reduction".

- Individual marking point: Here, at least one individual marking point MK1, MK2 is created for a communication unit, which is assigned to a specific message element. This enables the respective communication unit KE1, KE2, KE3 to quickly find one or more message elements NE1, NE2 on the basis of its individual marking points MK1, MK2.

2.2 Requesting broadcasting rights

After the push-to-talk session with several participating communication units KE1, KE2, KE3 has been established, In a next step, the communication unit KE3 requests an exclusive transmission right for the transmission of at least one user message NN1, NN2. For this purpose, according to FIG. 1, it transmits an inquiry message FS to the PTT server PS. Since the transmission right is currently not assigned to any communication unit KE1, KE2, KE3, the PTT server grants the communication unit KE3 the exclusive transmission right. This is communicated to the communication unit KΞ3 by means of a positive confirmation message PBN. The communication unit KE3 can now send one or more user messages NN1, NN2 for the authorization period BT.

2.3 The useful message

The user message NN1, NN2 comprises user data which the communication unit KE3 authorized to send wants to send to the other communication units KE1, KE2 participating in the PTT session. The useful data include, for example, a voice message or image data to be sent. The transmission of useful data is explained in more detail below using voice data as an example. In practice, it is useful to compress voice data before transmission. Voice data can be compressed using the AMR compression method (AMR - Adaptive Multi Rate Codec), see 3GPP TS 26.071, Version 5.0.0. For this purpose, the speech signal recorded by the microphone, for example, is divided into one or more speech frames with a length of 20 ms (ms-milliseconds). Each speech frame is then compressed separately. In a next step, one or more compressed speech frames are converted into an RTP packet (RTP - Real Time Transport Protocol), see IETF RFC 3550

"RTP - A Transport Protocol for Real-Time Applications" and IETF RFC 3551 "RTP Profile for Audio and Video Conferences" added. In practice it is useful to convert an RTP packet into a UDP packet (UDP - Unified Data Protocol). and use this UDP packet using an IP protocol (IP - Internet

Protocol). More detailed explanations on the UDP and IP standards can be found under K. Washburn et al., "TCP / IP - running a successful net ork", Addison-Wesley, 1995.

For the present exemplary embodiment, it is assumed that a user message, such as e.g. the useful message NNl comprises at least one IP packet. For example, a voice message from the communication unit KE3, which is several seconds long, can be represented by the useful message NN1. This user message NN1 can consist of several individually transmitted IP packets.

The communication unit KE3 transmits its voice message to the PTT server PS using the user message NN1. This forwards this useful message NN1 to the other communication units KE1 participating in the PTT session in real time.

KE2 continue. In addition, the PTT server PS also forwards this useful message NN1 to the protocol unit PE. The protocol unit PE stores this useful message NN1 in a first message element NE1 together with an associated first element description NEBL in the protocol file PD. The first element description NEBL comprises a unique identification feature of the communication unit KE3, for example "KE3 - contribution 5". In addition, the first element description NEBl includes the start and end times for the associated first message element NEl, for example "Start: 08:17 End: 08:19". In addition, an identification feature is also present in the message element NE1, for example "contribution 15" and a categorizing indicator "proposal for budget reduction".

2.4 Surrender of the transmission right and termination of the PTT session In the following, the communication unit KE3, which is authorized to transmit, gives up its exclusive transmission right. For this purpose, it transmits an end message ES to the PTT server PS. This then deprives you of the exclusive broadcasting right. In a further step, the communication unit KE3 ends the PTT session. For this purpose, it transmits a session end message SE to the PTT server PS. The PTT then ends the PTT session. Furthermore, the PTT server also informs the protocol unit PE of the termination of the PTT session.

The log unit PE then closes the log file PD. For this purpose, the description part PDK of the log file PD is updated. For example, the end time of the PTT session and the end time of the logging are entered. The protocol unit PE then sends a first protocol message PN1 to the communication units KE1, KE2, KE3 with the aid of the transmission unit SEEP of the PTT server PS. This first log message PN1 contains the log file P. Alternatively, the first log message PN1 can contain a link PVK to the log file PD instead of the log file PD. The link PVK is expediently specified in the form of a URI (URI - Uniform Resource Identifier). The log unit PE can also store the log file PD on a memory module outside the PTT server PS, for example in a data server in another network NET. An archive with log files of PTT sessions that have already ended is preferably present on this data server. The first protocol message PN1 can be transmitted to one or more communication units which did not take part in the respective PTT session.

Finally, the PTT server PS uses a further session end message SE to notify the communication units KE1, KE2 that the PTT session has ended.

2.5 Syntax and transmission protocol for a protocol message and a control message

In practice, it is useful to write the protocol message PN1, PN2 and / or the control message SN1, SN2 in XML format (XML - Extensible Markup Language), see "http // www.w3. Org / XML /", or in SDP format (SDP - Session Description Protocol), see IETF RFC 2327. These messages are preferably sent using the SIP protocol (SIP - Session Initiation Protocol), see IETF RFC 2616, and / or the HTTP

Protocol (HTTP - Hyper Text Transfer Protocol), see IETF RFC 2616. Thus, a SIP message denotes a message such as the first control message SN1, which is transmitted using the SIP protocol. In addition, at least one protocol message PN1, PN2 and / or at least one control message SN1, SN2 can be integrated in at least one SIP header of a SIP message and transmitted by means of this SIP message, see IETF RFC 3261.

3. Extensions and variants

Several extensions and variants of the method according to the invention are explained in more detail below. In addition, a possible implementation using the syntax of the XML format is presented. The messages created with the XML format can preferably be transmitted as a SIP message. These implementation variants are explained in more detail with the aid of FIGS. 3a to 3n.

3.1 The SIP message A SIP message is shown in FIG. 3a. A SIP message consists of a rßlP header SIK and a SIP message part SIN. For better differentiation, the SIP message part SIN is shown in bold in FIGS. 3a-3n. The SIP head SIK includes the following entries:

- A first command B1 includes the type of this SIP message, such as a name "INVITE". In this example, this type indicates that a PTT session should be established. The transmission protocol used is also specified, such as the SlP protocol with version 2.0 in the form of "SIP / 2.0". - A second command B2 describes a group address, such as "Projekt-Team@ptt.siemens.com". This group address contains a list of communication units that are to participate in this PTT session. A SIP address for the respective communication unit, under which this can be reached, is preferably entered there. In the present example, this group address comprises the following SIP addresses: - Kl@siemenens.com - K2@siemenens.com - K3@siemenens.com

- A third command B3 includes an identifier for the communication unit that initiates this PTT session. In the exemplary embodiment, the communication unit KE2 initiates this PTT session. So your SIP address can be used as an identifier for this communication unit KΞ2, e.g. "KE2 @ siemens. Com".

- A fourth command B4 with a name "Content-Type" contains a clear indication of the data type according to which the SIP message part SIN was created. In the example according to FIG. 3a, a data type with a name "application / features + XML" is used. This data type indicates that the associated SlP message part SIN contains one or more information for this PTT session.

The SIP message part SIN can include one or more information. The type of information is described with a keyword SW. It may be appropriate to add further parameters to the keyword SW, which complete the description of the information to be specified. Since information can span several lines, the keyword SW is reproduced at the start and end of the information according to XML syntax. In Figure 3a, several parameters for a PTT session within the SIP message part SIN are to be specified as information. This will the keyword SW with a name "features" used at the beginning and at the end of the information to be specified. At the beginning, an angle bracket is placed around the keyword SW, such as "<features>". To mark the end of the information to be given, the keyword SW is enclosed in an angle bracket and an oblique line is placed in front of the keyword SW, such as "</features>". If the information to be provided can be placed on one line, an abbreviated notation is introduced. The beginning of the information to be specified is marked with an angle bracket, with the point to the left, followed by the keyword SW, such as "<features". This is followed by the information to be provided. The end is only marked with an oblique line followed by an angle bracket, with the point to the right, such as "/>".

3.2 Activation of protocol creation

In the first exemplary embodiment, the creation of the protocol was activated automatically, ie without an explicit request or request, after the first invitation message TEN1 was received by the PTT server PS. Alternatively, the creation of the protocol can be activated by the communication unit that initiates the PTT session. For this purpose, the communication unit KE2, for example, inserts at least one control parameter in a control message, such as in the first control message SN1. Alternatively, at least one control parameter can also be inserted in the first invitation message TEN1. A possible implementation of the first invitation message TEN1 is shown in FIG. 3a. For this purpose, the first invitation message TEN1 contains a first control parameter SP1, which instructs the protocol unit PE to activate the creation of the protocol for this PTT session. The first control parameter SP1 uses a name "minutes" as the keyword SW and a name "activation =" on "" as the parameter. The protocol unit PE expediently confirms the activation of the creation of the protocol with the aid of a protocol message, for example in the first confirmation message BN1. This confirmation message BN1 can contain a SIP message part according to FIG. 3b. This first confirmation message BN1 contains a first protocol information PI1, which indicates the activation of the creation of the protocol.

Alternatively, the activation of the creation of the protocol of the PTT session can also be activated by one of the communication units KE1, KE3 invited to the PTT session. For this purpose, for example, the first confirmation of participation message TBN1 comprises the SIP message part SIN from FIG. 3a. This SIP message part SIN comprises at least the first control parameter SP1, which activates the creation of the protocol by the protocol unit PE.

3.3 Consent to logging According to an extension of the method according to the invention, it may be expedient in practice that one or more user messages of a communication unit should not be logged.

In the exemplary embodiment according to FIG. 1, the communication unit KE3 is invited to the PTT session using a protocol message, for example by means of the second invitation message TEN2. This second invitation message TEN2 comprises a first protocol information PI1, which indicates that the creation of a protocol has been activated for this PTT session. An advantageous realization of this first protocol information PI1 can be seen in FIG. 3b. In the exemplary embodiment according to FIG. 1, the communication unit KE3 confirms its participation in this PTT session by means of the first invitation confirmation message TBN1. An advantageous SIP message part of this first invitation confirmation message TBN1 is shown in FIG. 3d. With the help of a second Control parameter SP2, the communication unit KE3 can indicate their consent to the recording of their sent useful messages in the protocol. Alternatively, the communication unit KE3 can object to their consent to the logging of their sent useful messages. For this purpose, the first invitation confirmation message TBN1 contains a third control parameter SP3 in its SIP message part. This third control parameter SP3 can be implemented according to FIG. 3e.

In addition to the variant of allowing or contradicting the creation of one or more user messages from a communication unit during the establishment of the PTT session, this can also be done individually during the PTT session. For this purpose, the respective communication unit sends a control message to the protocol unit PE. This control message either contains the consent to the logging, which is indicated by means of the second control parameter SP2 according to FIG. 3d, or the rejection of the logging, which is indicated by means of the third control parameter according to FIG. 3e.

In an extension, it can be expedient that for at least one communication unit participating in the PTT session, their consent or their refusal to record their sent useful messages is predefined in the protocol. For example, the communication unit KE1 is preset so that its user messages are not to be recorded in the protocol. A control message also enables the respective communication unit to individually inform the protocol unit PE of its consent or rejection.

In addition, it is expedient in practice that a communication unit can query its current setting, whether its user messages to be sent are recorded in the protocol or not, by the protocol unit PE. For this a corresponding request is made to the protocol unit PE by means of a control message. FIG. 3f shows a possible SIP message part SIN which contains a fourth control parameter SP4. This fourth control parameter SP4 requests the protocol unit PE to transmit the current status for the respective communication unit. After receipt of this control message, the protocol unit PE will communicate the current status by means of a protocol message. If the consent to the logging of one or more user messages to be sent is present, the log message can transmit a thirteenth log information PI13 in its SIP message part SIN according to FIG. 3d. Otherwise, fourteenth log information PI14 is inserted into this log message.

3.3 Interrupting the Recording of the Protocol In an extension of the method according to the invention, at least one communication unit can stop the generation of the protocol for the PTT session and / or reactivate it at a later time. While creating the

Protocol is stopped, no useful messages are recorded by the protocol unit PE. To stop the creation of the protocol, a communication unit, for example the communication unit KE3, sends a first control message SN1 to the protocol unit PE. This first control message SN1 comprises a fifth control parameter SP5, which indicates that the creation of the protocol is to be stopped. FIG. 3g shows an advantageous implementation of the fifth control parameter SP5. After the protocol unit PE has received this first control message SN1, it stops the creation of the protocol of the PTT session. It may inform one or more communication units involved in the PTT session by means of a third protocol message PN3 that the creation of the protocol has been stopped. For this purpose, it expediently inserts third protocol information PI3 into this third protocol collision message PN3 on. A possible implementation of the third protocol information PI3 can be seen in FIG. 3g.

At a later point in time, one of the communication units can continue to create the protocol. For this purpose, this communication unit sends a first control message SN1 to the protocol unit PE, which comprises a sixth control parameter SP6. This sixth control parameter SP6 indicates to the protocol unit PE that the creation of the protocol is to be continued. An advantageous implementation of the sixth control parameter SP6 can be seen in FIG. 3h. After the protocol unit PE has continued to create the protocol, this can be done with the help of another protocol message, e.g. a third protocol is followed by PN3, which inform the communication units participating in the PTT session about the continuation of the creation of the protocol. For this purpose, the latter inserts fourth protocol information PI4 into the third protocol message PN3, which informs the respective communication unit of the continuation of the protocol. A possible realization of the fourth protocol information PI4 can be seen in FIG. 3h.

The stopping or resuming of the creation of the protocol during a PTT session is expediently only possible for a specific communication unit. Pausing and resuming the creation of the protocol may only be permitted for the communication unit that initiated the PTT session, e.g. Communication unit KE2. During the initialization of the PTT session, one or more participating communication units may be determined by means of protocol information, which may stop or continue the creation of the protocol.

3.4 Premature termination of the creation of the protocol In an advantageous extension of the method according to the invention, the creation of the protocol of the PTT session is terminated before the termination of the PTT session. With the help of a second control message SN2, at least one communication unit can request the protocol unit PE to end the creation of the protocol. This second control message SN2 comprises a seventh control parameter SP7, which causes the protocol unit PE to end the creation of the protocol. FIG. 3i shows an advantageous implementation of the seventh control parameter SP7. After receipt of this second control message SN2, the protocol unit PE will end the creation of the protocol. In practice, it is expedient for the protocol unit PE to inform the communication units participating in the PTT session of the end of the creation of the protocol after the creation of the protocol has ended. For this purpose, this transmits a second protocol message PN2 with a fifth protocol information PI5. This fifth protocol information PI5 shows the respective communication unit that the creation of the protocol has ended. An advantageous implementation of this fifth protocol information is shown in FIG. 3i. It may not be possible for every communication unit to finish creating the protocol. For example, termination can only be initiated by the communication unit that initiated this PTT session, such as communication unit KE2.

3.5 Media type of the log file

In a further variant of the method according to the invention, one or more media types are specified when the protocol is created. A media type corresponds, for example, to a form of presentation of the user data in a user message or log file that is standardized according to the MIME standard (MIME - "Multipurpose Internet Mail Extensions"). Detailed information can be found in particular in the document IETF RFC 2045 "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies". For example, the media type "audio / AMR" means that all user data to which this media type refers have been compressed according to the AMR process and are processed in accordance with the AMR process. were saved. A detailed description for the media type "audio / AMR" can be found, for example, in the document IETF RFC 3267 "Real-Time Transport Protocol (RTP) Payload Format and File Storage, Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi -Rate Wideband (AMR-WB) Audio Codecs "are taken.

Thus, according to the present invention, it is possible to specify one media type or a number of permissible media types which are to be taken into account for the storage of user data in the log file PD. In the event that user data has not been compressed according to any of the permitted media types specified, transcoding will be carried out if possible. A transcoding is understood to mean that user data u are converted from one media type to another media type. For example, user data that have been compressed using the AMR method are transformed into text using transcoding. This is done by a device called a "speech-to-text". This device may be integrated in the PE protocol unit.

One or more media types can be predefined in the protocol unit PE. Alternatively, one of the communication units can specify one or more permitted media types when the PTT session is initialized. One or more types of media can be transmitted to the protocol unit PE by means of a control message, for example the first control message SN1 or the first invitation message TEN1 or participation confirmation message TBN2, TBN1. For this purpose, an eighth control parameter SP8 is inserted into the respective control message. FIG. 3a shows an advantageous implementation of an eighth control parameter SP8. In FIG. 3a, the media type is set by the eighth control parameter SP8 in such a way that the user data are stored in the log file PD in a compressed manner using the AMR method.

3.6 The log file In an expedient extension of the method according to the invention, one or more parameters of the log file PD can be determined individually when the log file PD is created. The name of the PTT session can be defined by one of the communication units participating in the PTT session. For example, the name of the PTT session is transmitted with a control message, such as through the first invitation message TEN1. Thus, in the first invitation message TEN1 according to FIG. 3a, a ninth control parameter SP9 is inserted, which contains the name of the PTT session, such as "immediate measures to meet the project dates". After receipt of the first invitation message TEN1 by the protocol unit PE, this takes over this new name of the PTT session and enters it in the protocol file PD.

Furthermore, both the name of the log file PD and the address at which the log file PD to be created is stored can be individually defined. For this purpose, a fourteenth control parameter SP14 is inserted in a control message, such as in the first invitation message TEN1. This fourteenth control parameter SP14 includes the address and the file name of the log file, such as, for example, according to FIG. 3b "siemens.com/Projekt/ID123.prl". "Sie- mens.com/Pro ekt /" shows the address and "IDl23.prl" the file name. Alternatively, instead of specifying the address and the file name, only the address can be specified. As in the implementation example according to FIG. 3a, a ninth control parameter SP9 only includes the address at which this log file PD can be found, such as "siemens.com/Projekt/". After receipt of this control message, the log unit PE uses the fifteenth control parameter SP15 to assign a file name for the log file PD. It can then use a fifth protocol information PI5 to transmit this file name together with the address in a second protocol message PN2 to at least one communication unit. A possible implementation of the fifth protocol information PI5 is shown in FIG. 3b. 3.7 Publication of the log file

In a further, expedient variant of the method according to the invention, it is possible for at least one communication unit to individually set the list of communication units which receive the log file PD or the link PVK to the log file PD. For this purpose, a control message, e.g. inserted one or more control parameters in the first invitation message TENl. For example, a tenth and eleventh control parameter SP10 or ΞP11 is inserted in the first invitation message TEN1 according to FIG. 3a. These indicate those communication units that are authorized to receive the log file PD or the link PVK to the log file PS. The tenth control parameter SP10 denotes the group address, ie a list of the addresses of all participating communication units. In addition, the eleventh control parameter SP11 includes an additional address of a communication unit that is not participating in the session, but is also to receive the protocol file PD. The communication unit KE2 sends this first invitation message TEN1 with the tenth and eleventh control parameters SP10 and SP11 to the protocol unit PE. After completion of the creation of the protocol, this will send the communication file PD or a link PVK to the protocol file PD to all communication units, which are listed in the tenth and eleventh control parameters SP10 and SP11. It is thus possible to individually define those communication units which receive the log file PD or the link PVK to the log file PD after the creation of the log unit PE.

According to an advantageous extension of the invention, at least one of the participating communication units receives a list of those communication units that receive the log file PD or a link PVK to the log file PD. Thus, according to FIG. ner protocol message, such as in the third invitation message TEN3, an eighth and ninth protocol information PI8 or PI9 are inserted. The eighth protocol information PI8 comprises the addresses of all participating communication units. This corresponds to the list of addresses of the group address "Projekt-Team@ptt.siemens.com". The ninth protocol information PI9 includes an additional communication unit that does not participate in the PTT session, such as with an address "P.Mueller@siemens.com", but nevertheless sends the protocol file PD or a link PVK to the protocol file PD gets. This enables at least one communication unit participating in the PTT session to get an overview of those communication units that have access to the log file PD.

3.8 marking points

In a further expedient variant of the invention

One or more marking points, such as marking point MK1, MK2, can be set individually in the method. The marking point MK1, MK2 points to a location in the log file PD. The marking point MK1, MK2 preferably points to the beginning of a useful message. In addition, the marking point MK1, MK2 can point to a location in the log file PD that corresponds to a specific point in time. For example, c-aurde started creating the log at 9:00 a.m. The first marking point MK1 can point to the time 9:11 a.m. This point in time expediently lies within a useful message and the marking point thus points to a location within this useful message. The marking point MK1, MK2 can be set individually by the communication unit KE1, KE2, KE3. With the aid of the marking point MK1, MK2, the communication unit KE1, KE2, KE3 can quickly find a specific location within the log file PD, such as the start of a user message. In addition to the possibility of setting a marking point MK1, MK2 at a specific position in the log file PD, two marking points MKl, MK2 can be used to mark the beginning and the end of a section within the log file PD. For this purpose, as described, a first marking point, such as the first marking point MK1, is first set to indicate the start of the section to be marked. Then a second marking point, such as the second marking point MK2, is defined, which indicates the end of the section to be marked.

To set a marking point MK1, MK2, a communication unit KE1, KE2, KE3 sends a first control message SN1 with a twelfth control parameter SP12 to the protocol unit PE, which then has a new marking point, such as e.g. sets the first marking point MK1 in the log file PD. An advantageous implementation of this twelfth control parameter SP12 is shown in FIG. 3j. This twelfth control parameter SP12 preferably comprises several individual elements:

A first element SPEI identifies this twelfth control parameter SP12 as a control parameter with which a marking within the log file PD is to be made. This first element SPEI thus corresponds to a keyword SW.

A second element SPE2 specifies a unique identifier for the marking point to be added, such as "MKl".

A third element SPE3 indicates whether this first marking point MK1 describes the beginning or the end of the section to be marked. In the present example, this third element SPE3 indicates that the marking point describes the beginning of the section to be marked. A fourth element SPE4 contains a descriptive name for this first marking point MK1, such as "particularly important".

- A fifth element SPE5 defines the resolution of a marking point. The resolution can either be set to a user message or to a point in time in the log file PD. In the present example of the twelfth control parameter SP12, the fifth element SPE5 indicates that the first marking point MK1 should point to a useful message, e.g. at the start of a user message.

A sixth element SPE6 indicates whether the first marking point MK1 should point to the user message that is currently being logged or to a user message from the past or future. The sixth element SPE6 in Figure 3j shows the value "-1". This value indicates that the first marking point MK1 should not be set to the currently logged user message, but to the last logged user message.

After receiving this first control message SN1 with the twelfth control parameter SP12, the protocol unit PE enters the first marking point MK1 in the element description NEBL of the last logged useful message as an individual identifier. The first marking point MK1 is symbolically indicated in FIG. 2b with a dashed arrow. Alternatively, the log unit PE can store all the set marking points MK1, MK2 and the associated location within the log file PD in a separate list in the description part PDK of the log file PD.

In a next step, the protocol unit PE can communicate to the communication unit KE3 by means of a third protocol message PN3 that the first marking point MK1 has been successfully entered in the protocol file PD. Here- For this third protocol message PN3 contains a tenth protocol information PI10, which contains both the name of the first marking point MKl "MKl" and a status. A possible realization of the tenth protocol information PI10 is printed in FIG. 3k. In the event that the first control message SN1 could not be successfully implemented with the twelfth control parameter SP12, the protocol unit PE can transmit a negative status "error" instead of a positive status ^, ok "using the third protocol message PN3.

In a further step, the end of the section to be marked should be marked. For this purpose, the communication unit KE3 transmits a second control message SN2 to the protocol unit PE, which instructs the protocol unit PE to end the section to be marked. For this purpose, this control message SN2 contains a thirteenth control parameter SP13. A possible implementation of this thirteenth control parameter SP13 is shown in FIG. 31. First of all, this thirteenth control parameter SP13 contains a twelfth element SPE12, which describes a unique identification feature for the second marking point MK2 to be added, such as "MK2". In addition, this thirteenth control parameter SP13 comprises a thirteenth element SPE13. This thirteenth element SPE13 indicates that the second marking point MK2 to be set describes the end of the section to be marked. Furthermore, a fourteenth element SPE14 is specified, which provides information about the marking point which marks the beginning of the section to be marked. In the present example, the fourteenth element SPE14 contains an entry "MKl" and thus points to the first marking point MKl. Finally, this thirteenth control parameter SP13 comprises a fifteenth element SPE15. This fifteenth element SPE15 indicates the resolution. In the present example, the second marking point MK2 is to be placed at the end of a useful message. After receipt of the second control message SN2 and the thirteenth control parameter contained therein ters SP13, the protocol unit PE places this second marking point MK2 at the end of the currently logged useful message. According to FIG. 2b, the marking point MK2 marks the end of the section to be marked, which is described by the marking points MK1 and MK2. The marked section comprises the useful message of the message element NE1 and NE2. The second marking point MK2 is entered as an individual identification for the communication unit KE3 in the message description NEB2.

After the end of the marking by the marking point MK2 has been entered by the protocol unit PE, the protocol unit PE can communicate this to the communication unit KE3 by means of a second protocol message PN2. This second protocol message PN2 comprises an eleventh protocol information PI11, which is shown as an example in FIG. 3m. This first protocol information PIll includes the specification of the marking point MK2 and the status. The status indicates whether the entry of the marking point MK2 by the PE was successful or not. In the present example according to FIG. 3m, a positive status is communicated in the eleventh protocol information.

With the help of one or more individual marking points MK1, MK2 it is possible for a communication unit at a later time to access the useful messages important for this communication unit within the protocol file PD in a simple and quick manner.

3.9 Notification of the possibility of creating the protocol When initiating a PTT session, the participating communication units KE1, KE2, KE3 do not know in advance whether there is an option to create the protocol of this PTT session. Therefore, _'ann through an appropriate expansion out the method according to the invention can be determined whether there is a possibility for the creation of a protocol. For this purpose, the protocol unit PE adds the PTT Session in one or more protocol messages, such as in the second invitation message TEN2, a twelfth protocol information PI12. An advantageous implementation of this twelfth protocol information PI12 is shown in FIG. 3n. This shows the respective receiving communication unit, such as the communication unit KΞ3, that there is the possibility of creating the protocol of the PTT session. In the following, at least one of the communication units KE1, KE2, KE3 can activate the creation of the protocol.

3.10 Querying and changing parameters when creating the protocol

According to an advantageous extension of the method according to the invention, at the beginning or during the creation of the

Protocol of a PTT session can be queried by one or more communication units KE1, KE2, KE3 at least one parameter regarding the creation of the protocol. For example, the name of the PTT session or the name of the log file PD is queried by the communication unit KE1. In addition, one or more parameters for creating the log can be changed not only at the beginning, but also during logging. For example, a communication unit changes the name of the PTT session after the creation of the protocol has already started.

3.11 Evaluation of the log file

In an advantageous extension of the method according to the invention, it is possible to carry out an evaluation using the created log file PD. Possibly unique identification features for one or more user messages were entered into the log file PD during the creation of the log. For example, a special identification feature identifies useful messages which are to be combined into a task list for later processing. Using this special identification feature, you can manually or automatically, for example by Protocol unit PE, a further protocol file can be created, which only includes the user messages marked with this special identification feature. The display format can be changed when this additional log file is created. This further log file is expediently stored in a textual representation.

Claims

claims

1. Method for creating a protocol for a push-to-talk session with several participating communication units (KE1, KE2, KE3), in that only one of these communication units (KE3) has an exclusive right to send for the transmission of at least one user message (NN1, NN2) is assigned for an authorization period (BT) during which the other communication units (KE1, KE2) are only assigned a right to receive at least one useful message (NN1, NN2), and by means of a protocol unit (PE) at least one useful message ( NN1, NN2) of the session is received and stored in a log file (PD) on a memory module (SM).

2. The method according to claim 1, characterized in that the useful message (NN1, NN2) is transmitted in one or more packets in a packet-oriented network.

3. The method according to any one of the preceding claims, characterized in that at least one control message (SNl, SN2) is transmitted to the protocol unit (PE), the control message (SNly.ι SN2) at least one control parameter for controlling the protocol unit (PE ). includes.

4. The method according to claim 3, characterized in that a control parameter is inserted in at least one control message (SN1, SN2) which determines a start time and / or an end time of the creation of the protocol.

5. The method according to claim 3 or 4, characterized in that a control parameter is inserted in at least one control message (SN1, SN2), with the aid of which the creation of the protocol is stopped or continued during the push-to-talk session.

6. The method according to any one of claims 3 to 5, characterized in that a control parameter is inserted in at least one control message (SNl, SN2) that starts or ends the creation of the protocol.

7. The method according to any one of claims 3 to 6, characterized in that a control parameter is inserted in at least one control message (SNl, SN2), which a communication unit (KEl, KE2, KE3) participating in the push-to-talk session. makes it possible to exclude or allow at least one user message (NN1, NN2) and / or at least one user message (NN1, NN2) from one of the other communication units (KE1, KE2, KE3) from being recorded in the protocol.

8. The method according to any one of claims 3 to 7, characterized in that parameters for the creation of the log file (PD) are set by at least one control parameter of at least one control message (SN1, SN2).

9. The method according to any one of claims 3 to 8, characterized in that at least one control message (SNl, SN2) generated by at least one communication unit (KEl, KE2, KE3) and transmitted to the protocol unit (PE).

10. The method one of claims .3 with 9, characterized in

that at least one control message (SN1, SN2) is created in XML format or in SDP format and transmitted using the SIP protocol and / or the HTTP protocol.

11. The method according to any one of claims 3 to 10, characterized in that at least one control message (SNl, SN2) is integrated in at least one SIP header of a SIP message and is transmitted by means of this SIP message.

12. The method according to any one of the preceding claims, characterized in that at least one protocol message (PN1, PN2, PN3) is transmitted by the protocol unit (PE) to at least one participating communication unit (KE1, KE2, KE3), the protocol message (PN1, PN2, PN3) comprises at least one piece of protocol information.

13. The method according to claim 12, characterized in that the possibility of creating the protocol at the push-to-talk session is communicated to at least one participating communication unit (KE1, KE2, KE3) using the protocol message (PN1, PN2, PN3).

14. The method of any one of claims 12 or

characterized in that the log file (PD) or a link (PVK) to the log file (PD) to at least one participating and / or non-participating communication unit (KE1, KE2, KE3) with the help of the protocol message (PN1 , PN2, PN3) is sent.

15. The method one of claims 12 to 14, characterized in

that at least one protocol message (PN1, PN2, PN3) is created in XML format or in SDP format and transmitted using the SIP protocol and / or the HTTP protocol.

16. The method according to any one of claims 12 to 15, characterized in that at least one protocol message (PNl, PN2, PN3) is integrated in at least one SIP header field of a SIP message and is transmitted by means of this SIP message.

17. The method according to any one of the preceding claims, characterized in that a link (PVK) to the log file (PD) by the log unit (PE) or with the help of a control message (SNl, SN2) by one of the participating communication units ( KEl, KE2, KE3) is set.

18. The method according to any one of the preceding claims, characterized in that at least one useful message (NNl, NN2) is transcoded into another form of representation by the protocol unit (PE) before being stored.

19. The method according to any one of the preceding claims, characterized in that the protocol unit (PE) as the message element (NEl, NΞ2) in each case the useful message (NNl, NN2) or a message link (VKl, VK2) to the associated useful message (NNl, NN2) is used and that the log file (PD) is composed of the following parts:

- A description part (PDK), which comprises one or more descriptions of the session to be logged.

- A message part (PDN), which comprises at least one message element (NE1, NE2) and an associated element description (NEBL, NEB2).

20. The method according to any one of the preceding claims, characterized in that the protocol file (PD) is created by the protocol unit (PE) using the XML standard.

21. The method according to any one of the preceding claims, characterized in that at least one marking point (MK1, MK2) is generated by the protocol unit (PE), the marking point (MKl, MK2) relating to an event and / or a point in time within the Log file (PD) shows.

22. The method according to one of the preceding claims, characterized in that the respective communication unit (KE1, KE2, KE3) is used in a mobile radio device, in a fixed network device or in a computer unit.

23. Communication unit (KE3) authorized to send to participate in a push-to-talk session with the creation of a protocol, in particular according to at least one of claims 1 to 22, with a transmission unit (SEE3) for the transmission of at least one user message (NN1, NN2) ) during an authorization period (BT) in which an exclusive transmission right is assigned, during which: the other communication units (KE1, KE2) are only assigned a right to receive at least one user message (NN1, NN2).

24. Communication unit authorized to send (KE3) to

Claim 23, characterized in that the communication unit (KE3) authorized to send is used in a mobile radio device, in a fixed network device or in a computer unit.

25. A communication unit (KE3) authorized to send according to one of claims 23 or 24, characterized in that a receiving unit (EME3) for receiving at least one protocol message (PN1, PN2, PN3) from the protocol unit (PE) is available.

26. The communication unit (KE3) authorized to send according to one of claims 23 to 25, characterized in that a transmission unit (SEE3) for sending at least one control message (SN1, SN2), the at least one control parameter for controlling the protocol unit (PE ) is available.

27. Authorized to send communication unit (KE3) according to one of claims 23 to 26, characterized in that a processing unit (VAE3) for evaluating received protocol messages (PNl, PN2, PN3) and for creating control messages to be sent (SNl, SN2) is available.

28. Communication unit (KE1, KE2) authorized to receive to participate in a push-to-talk session with the creation of a protocol, in particular according to at least one of claims 1 to 22, with a receiving unit (EME1, EME2) for receiving at least one user message (NNl, NN2) during an authorization period (BT) in which only one reception right is assigned.

29. A communication unit (KE1, KE2) authorized to receive according to claim 28, characterized in that that the communication unit (KE1, KE2) authorized to receive is used in a mobile radio device, in a fixed network device or in a computer unit.

30. Communication unit (KE1, KE2) authorized to receive according to one of claims 28 or 29, characterized in that a receiving unit (EME1, EME2) for receiving at least one protocol message (PN1, PN2, PN3) from the protocol unit (PE) is available.

31. Communication unit (KE1, KE2) authorized to receive according to one of claims 28 to 30, characterized in that a transmission unit (SEE1, SEE2) for sending at least one control message (SN1, SN2, SN3), the at least one control parameter for control of the protocol unit (PE) is available.

32. Communication unit authorized to receive (KEl,

KE2) according to one of claims 28 to 31, characterized in that a processing unit (VAEl, VAE2) for evaluating received protocol messages (PNl, PN2, PN3) and for creating control messages (SNl, SN2) is available.

33. Protocol unit (PE) for participating in a push-to-talk session with several participating communication units (KE1, KE2, KE3) and for creating a protocol, in particular according to one of claims 1 to 22, with a receiving unit (EMEP) for receiving at least one user message (NN1, NN2), with a processing unit (VAEP) for storing at least one user message (NN1, NN2) of the session in a log file (PD) on a storage medium (SM), and with a memory module (SM) on which the log file (PD) can be stored.

34. Protocol unit (PE) according to claim 33, characterized in that a receiving unit (EMEP) for receiving at least one control message (SNl, SN2) is available.

35. Protocol unit (PE) according to one of claims 33 or 34, characterized in that a transmission unit (SEEP) is available for sending at least one protocol message (PN1, PN2, PN3).

36. Protocol unit (PE) according to any one of claims 33 to 35, characterized in that a processing unit (VAEP) for evaluating received control messages (SN), for creating protocol messages to be sent (PN1, PN2) and for controlling the creation of the protocol the session is available.

37. Protocol unit (PE) according to one of claims 33 to 36, characterized in that the memory module (SM) for storing at least one useful message (NN1, NN2) of the session and the protocol file (PD) externally to the protocol unit ". (* PE ) is connected.