EP1609287A1

EP1609287A1 - Method for mapping the signaling of the wireless village standard into the ip multimedia subsystem standard, and associated device

Info

Publication number: EP1609287A1
Application number: EP04719988A
Authority: EP
Inventors: Mark Beckmann; Michael Eckert; Martin Hans
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2003-04-02
Filing date: 2004-03-12
Publication date: 2005-12-28
Also published as: WO2004088948A1; DE10314927A1

Abstract

The invention relates to a method and a device for the interoperability of signaling procedures according to the wireless village standard and the IP multimedia subsystem standard, wherein at least one signaling procedure according to the wireless village standard is mapped into at least one signaling procedure according to the IP multimedia subsystem standard in a mobile communication network. An indicator in a signaling procedure signals the mapping regulation to be used, and at least one signaling procedure is mapped by a mapping function (2) according to said mapping regulation.

Description

description

METHOD FOR IMAGING THE SIGNALING FROM THE "WIRELESS VILLAGE STANDARD" TO THE "IP MULTIMEDIA SUBSYSTEM STANDARD", AND DEVICE THEREFOR

The invention relates to a method and an apparatus for mapping at least one signaling procedure according to the wireless village standard in at least one signaling procedure according to the iP multimedia subsystem standard in a mobile communication network.

In a mobile communication network there are several standards regarding the signaling of presence information of a terminal device and its user. A terminal can be a mobile radio terminal, a handheld device, a computer or

Be similar. This means that a separate presence service is implemented for each standard in a communication network. The ireless Village (V) standard and the 3GPP IP Multimedia Subsystem (IMS) standard are currently used. So far it has not been possible for a mobile terminal that only supports the WV standard to be managed by a presence service in the IMS. The 3GPP specification 23.141 (Presence Service; Architecture and Functional description) contains a note that a network may contain a network unit that performs the mapping from one standard to another. The design of this network unit is intended for future investigations.

The object of the present invention is to improve the interoperability of the presence services in accordance with the Wireless Village Standards and the 3GPP IP Multimedia Subsystem Standard. The object is achieved by the subject matter of the independent claims. Developments of the invention are specified in the subclaims. The essence of the invention is that a signaling procedure contains an indicator which is the one to be used

Illustration specification specifies. The advantage of this invention is that only a presence service can manage both the signaling according to the WV standard and the signaling according to the IMS standard, which leads to a considerable amount

Cost reduction leads. It is also possible that end devices that use different standards can still exchange presence information from another end device or its user.

The invention is explained in more detail using an exemplary embodiment shown in the figures. Show in detail

FIG. 1 shows a simplified network architecture for signaling,

2 shows a login procedure, FIG. 3 shows a logout procedure,

4 shows a service request, FIG. 5 shows a client capability request,

FIG. 6 shows a participation-presence transaction (subscribe

Presence Transaction), Figure 7 is a non-attendance-presence transaction

(Unsubscribe Presence Transaction), Figure 8 is a presence notification transaction

(Presence Notification Transaction), FIG. 9, a get observer list transaction (Get

Watcher list transaction), FIG. 10 shows a Get Presence Transaction,

Figure 11 shows an update presence transaction

(Update Presence Transaction), Figure 12 is a flowchart for a login / logout

Transaction,

FIG. 13 shows a flow chart for a login / logout.

Transaction with the possibility to save user identities and the associated passwords,

FIG. 14 the message exchange that is necessary to map this procedure to IMS signaling,

FIG. 15 shows the mapping of the WV signaling to the IMS signaling,

FIG. 16 shows a flowchart for a presence transaction for a non-participation,

FIG. 17 shows a flowchart for a Bekomrαe observer list transaction, FIG. 18 shows a flowchart for an update-presence transaction - part 1,

FIG. 19 shows a flowchart for an update presence transaction - part 2,

Figure 20 is a schematic representation of a mapping function.

Figure 1 shows a simplified network architecture for signaling. A WV client of a mobile communication terminal 1 is connected to an imaging function (A) 2 via a connection VI. The mapping function 2 is in turn connected to an S-CSCF 3 in the IMS. The S-CSCF 3 acts as an archivist in the IMS in accordance with the SIP protocol (RFC 3261 Session Initiation Protcol) with which a user logs on. The S-CSCF 3 also acts as a proxy that forwards SIP messages to the corresponding endpoints. For presence, these are in particular the presence server (PS) 5 and the presence list server (PLS) 6, which communicate with the S-CSCF 3 via the connection V3 or V4. In addition, the S-CSCF 3 is connected to the user database HSS 4 via a connection V5. So that a user of a mobile radio terminal can be managed by the presence (presence) server 5 in the IMS, the

Known users in the IMS and an IMS identity must be assigned to them. According to the WV standard, users use a WV-specific address in URI (Uniform Resource Identifier) format (e.g. firstname.lastname@company.com), which is preceded by the abbreviation (string) "wv:". This indicates that it is a wireless village address.

In the IMS, users are also identified via addresses in URI format. The addresses are preceded by the string "sip:" to indicate that it is a SIP address. The invention provides that the users who use the presence service (presence service) according to the WV standard are identified in the IMS at the same address as is used for WV. The mapping function 2 uses according to the invention

Connections VI and V2 have the same URI for a user. For messages that are sent to the mobile radio station, the mapping function 2 places the abbreviation "wv:" in front of the URI address. For messages that are sent to the Presence Server (Presence Server) 5 in the IMS, the

Mapping function 2 in front of the URI address the abbreviation "sip:". In the WV standard there is a note that the domain does not have to be included in the address if it is a Local address is. In this case, the mapping function 2 is also to add the domain to the address according to the invention.

Figure 2 shows the login procedure. The WV transactions are described in the Client Server protocol version 1.1 (The Wireless Village initiative: Client-Server Protocol from left). The WV standard requires that a user of a mobile communication device must register with the WV service before he can use the services (e.g. presence). This

The procedure serves to authenticate and authorize the user of a mobile communication device. According to this invention, the login request message is mapped to a SIP REGISTER message. The authentication can take place either between WV Client 1 and the mapping function 2 or between WV Client 1 and S-CSCF 3 in the IMS.

In the first case, the mapping function 2 has stored all passwords for the WV users and requests them from the WV client in a mobile communication terminal or its user in accordance with the WV standard. After authentication and authorization, the user is registered in the IMS using a "3rd party register" registration as described in 3GPP TS 24.229 (IP Multimedia Call Control Protocol based on SIP and SDP). This solution has the advantage that no changes in the IMS are necessary. In the second case, initiated by the login request message, a REGISTER message is sent to the S-CSCF 3, which then requests the user data from a user database. If a user uses a WV Client 1, this should also be recorded in the user database or another storage element. In this case, the user database also gives the password which the Users for the WV service used to the S-CSCF 3. The S-CSCF 3 then sends a challenge in a "Unauthorized (401 Unauthorized)" message to the mapping function 2, which the challenge in a login response (login response ) Message according to the WV

Forward standards to WV Client 1. The WV client 1 then generates the response in accordance with the WV standard and sends it again in a login request message to the mapping function 2, which forwards it to the S-CSCF 3 in a further SIP REGISTER message. The latter then checks the correctness of the answer and notifies the mapping function 2 of a positive result in a reply message (200_OK), which in turn maps this to the login response message. In addition, according to the invention, the information contained in the login request message in the information element lifetime (TimeToLive) and specifying how long the registration is to be valid is mapped to the information in the header Expiry Time (Expires), which has the same function in the REGISTER message takes over. Furthermore, according to the invention, the information in the expiry time (Expires) header in the response message (200_OK) is mapped to the REGISTER message, to the information element “keep alive” (keep alive) in the login response message.

Figure 3 shows a logout procedure. According to this invention, the logout request message according to the WV standard is mapped to a SIP REGISTER message according to the IMS standard, the REGISTER message containing an expiration header with the value "0", which corresponds to a de-registration. Figure 4 shows a service request. According to this invention, the mapping function 2 should always respond to service request messages according to the WV standard with a WV service response message (WV service response) message in which no restrictions are signaled by the network. This makes sense, since the presence service in accordance with the IMS standard fundamentally supports all functions that are described in the WV standard and are optional there. With the help of this transaction, a WV client 1 can tell the server 5, 6 which functions and WV services it supports. In addition, the server 5, 6 can tell the WV client 1 which services and functions it offers. WV services are understood to mean, for example, "presence", "instant messaging" or "group management". This invention is concerned with the presence service and therefore with the negotiation of the functions required for this service. With regard to each service, the WV client 1 can tell the server 5, 6 which functions it supports. In relation to the presence service, these are, for example, the functions of querying presence information from other users, updating one's own presence information on the server 5, 6, updating contact lists (buddy lists), etc. The IMS contains all the functionalities required for WV are supported. There is no way to negotiate these functionalities. Instead, all of these functionalities must be supported by the IMS network. It is therefore proposed in this invention that the mapping function 2 always respond to service requests with a service response message that does not indicate any restrictions through the network. This means that the service set in the service response message is empty. FIG. 5 shows a client capability request. According to this invention, the client capability request message according to the WV standard is mapped to a SIP REGISTER message according to the IMS standard. The only information relevant for the presence service in the client capability request message is contained in the information element syntax analyzer size (parser size), which specifies the maximum size of the message so that the WV client can still read it. According to the invention, the REGISTER message therefore contains an accept header (Accept), which indicates that the presence information formats are supported. In addition, the accept header is expanded in accordance with the invention in such a way that it contains information about the maximum permitted size of the presence information.

According to the invention, the response to the REGISTER message, the "200_OK" response message, is to be mapped to the client capability response message. An alternative to the solution described is that the mapping function 2 stores the "parser size" parameter and reduces the presence information that it receives from the presence server 5 in the IMS to the corresponding maximum size. Which presence information is omitted can be configured on the mapping function 2. With the help of this procedure, a WV client 1 can communicate its capabilities to the server 5, 6. This is, for example, information regarding the content supported in instant messaging (text, images, etc.). The only parameter relevant for the presence service is the "parser size" parameter, which specifies the maximum size of a message so that the WV Client 1 can still process it. After receiving a client capability request message from the mapping function 2, the latter generates one according to the invention REGISTER message. This contains an authorization header including the response that was created during the login procedure. The REGISTER message also contains an accept header, which indicates that presence information. Of the data type CPIM-PIDF + XML and CPIM-PLIDF + XML (see draft-ietf-impp-cpim-pidf http: //www.ietf .org / internet-drafts / draft-ietf-impp-cpi - pidf-06.txt Presence Information data for at) and draft-simple-presencelist-package (A SIP Event Package for List Presence)) are accepted and added a parameter according to the invention which indicates how large this data may be. The expiry time header contains the remaining duration of the registration. The S-CSCF 3 then sends a "200_OK" response message back to the mapping function 2. The mapping function 2 then sends a client capability response message back to the WV client 1.

FIGS. 6 and 8 show a participation and an emergency infection presence transaction (Subscribe Presence Transaction). According to this invention, the subscription presence request message is mapped according to the WV standard to a SIP PARTICIPATION message according to the IMS standard. According to the invention, a separate participation message (SUBSCRIBE) is generated for each user that is contained in the information element user identity list (user ID list) of the subscribe subscriber presence request message, the event header (Event) is set to the value "Presence". Furthermore, according to the invention, one is provided for each user group that is contained in the contact list identity list (Contact List ID list) of the subscription presence request message generates own participation message, whereby the event header is set to the value "Presence List *".

In the event that the IMS network only supports registrations for all presence information, but not for parts of the presence information, the mapping function 2 stores the list of attributes contained in the participation presence request message (Subscribe Presence Request) at which the User is interested. If the mapping function 2 later receives the presence information, then according to the invention it uses the stored information only to pass on the information to the WV client 1 in which the latter is also interested. If the IMS network also allows the registration of parts of the presence information, forms the

Mapping functions 2 list the attributes contained in the Subscribe Presence Request message based on the filters as used for the participation messages. Since, according to the WV standard, a registration is valid until it is revoked by an unsubscribe presence message (Unsubscribe Presence Request), according to the IMS standard, however, a registration is always valid for a certain time and must be renewed after this time , the mapping function 2 renews the enrollment itself until it receives a non-attendance presence message (Unsubscribe Presence Request) from the WV Client 1. The notification messages (NOTIFY) according to the IMS standard, with which a user is informed about the presence information to which he has registered, are mapped to the notification presence request message according to this invention. FIG. 7 shows an unsubscribe presence transaction. The Unsubscribe Presence Request message according to the WV standard is mapped according to this invention to a SIP PARTICIPATION message according to the IMS standard. According to the invention, a separate participation message is generated for each user that is contained in the information element “user ID list” (user ID list) in the participation presence request message (Subscribe Presence Request), where the event header is set to the value "presence".

Furthermore, according to the invention, a separate participation message is provided for each user group that is contained in the information element “Contact List ID List * (Contact List ID List) of the attendance presence request message (Subscribe Presence Request) generated, whereby the event header is set to the value "Presence list".

Furthermore, the expiry time header of the participation message is set to the value "0", which corresponds to a termination of the registration. Since, according to RFC 3265 (Event Notification Framework), however, each participation message must also be followed by a notification message (NOTIFY), it is determined according to this invention that this SIP notification message (SIP NOTIFY) is terminated at the mapping function 2, but no further messages are sent to the WV Client 1 are forwarded.

FIG. 9 shows a Get Watcher List Transaction. The Get Watcher List Request message according to the WV standard is mapped according to this invention to a SIP PARTICIPATION message as used in the IMS standard. The event header is set to the value "Presence .winfo". The expiry time header is set to the value "0", since the Get Watcher List transaction according to the WV standard is a one-time transaction and not a registration. The SIP notification message (SIP NOTIFY) which the mapping function 2 receives from the presence server 5 is mapped to the Get Watcher List Response message according to this invention.

FIG. 10 shows a hole presence transaction (Get Presence Transaction). The hole presence request message (Get

Presence request) according to the WV standard is mapped according to this invention to a SIP PARTICIPATION message according to the IMS standard. According to the invention, a separate SUBSCRIBE message is generated for each user that is contained in the information element “user ID list (user ID list) of the attendance presence request message (subscribe presence request), the event Header is set to the value "presence". Furthermore, according to the invention, a separate participation message is generated for each user group that is contained in the information element “Contact List ID List (Contact List ID List) of the attendance presence request message (Subscribe Presence Request), whereby the event header is set to the value "Presence list". The expiry time header is set to the value "0" because the get presence transaction (Get Presence Transaction) is a one-time transaction in accordance with the WV standard and not a registration. In the event that the IMS network Only supports requests for all presence information, but not for parts of the presence information, the mapping function 2 stores the list of subscriber presence request messages (Subscribe Presence Request) Attributes in which the user is interested. If the mapping function 2 later receives the presence information, then according to the invention it uses the stored information only to pass on the information to the WV client 1 in which the latter is also interested. If the IMS network also permits the request for parts of the presence information, the mapping functions 2 map the list of attributes which are contained in the attendance presence request message (Subscribe Presence Request) to the filters, such as those for the attendance - Messages are used.

FIG. 11 shows an update presence transaction. Basically, the update presence request message is mapped in accordance with the WV standard to a SIP publication message in accordance with the IMS standard. It is currently not possible in the IMS to update only parts of presence information. However, this may change in the future. In this case, the mapping function 2 could map the update presence request message directly to a SIP publication message. If this is not the case, when the presence information is updated on the presence server 5 in the IMS, all of the user's presence information must always be included in the publication message, and therefore the mapping function 2 must always be up to date with regard to the presence information of the Users. Assuming that all presence information is present in the first, initial update presence request message (update presence request), the mapping function 2 can display the presence information of the update presence request message (update presence Request) before the presence information is forwarded to the Presence Server 5 in a SIP publication message. Only the presence information to be updated is contained in the update presence request messages in this exemplary embodiment. According to the invention, these are used by the mapping function 2 in order to update the information stored on the mapping function 2. In addition, the mapping function 2 fills up the presence information according to the invention, so that all presence information is contained, and then forwards it to the presence server 5 with a publication message (PUBLISH). If the above assumption does not apply, the first, initial update presence request message (Update Presence Request) may only contain parts of the presence information - for example, because standard values are known on the WV Client 1 and on the Presence Server 5 - The mapping function 2 must check the presence information before receiving the first update presence requests.

Obtain a message (update presence request), or before forwarding the presence information in a publication message. According to the invention, this is done in that the mapping function 2 writes information about the presence directly after the WV client 1 (or its user) logs on, and thus receives and stores the presence stored on the presence server 5. If the mapping function 2 then receives an update presence request message, it can fill in the missing presence information with the aid of the stored information before forwarding the presence information to the presence server 5 in a publication message. Figure 12 shows a flow chart for a login / logout transaction. According to the WV standard, the login transaction serves to authenticate and authorize the user. The user or his client 1 (hereinafter referred to simply as the client) can differentiate whether the authentication should take place in a 2-step or a 4-step process. If the authentication takes place in a 2-step process, the client 1 inserts a password in the "LoginRequest" message (see FIG. 2). If the password is correct, the server 5, 6 considers the client 1 as authorized. Alternatively, the server 5, 6 can request further authentication by sending a "login response" message to the client 1, indicating that the authorization has failed and one

Challenge. The ^' client 1 then again sends a "login request" message containing the response to the challenge, to which the server 5, 6 replies with a "login response" message and indicates whether the authentication was successful or not.

The 4-step procedure corresponds approximately to the further authentication of the 2-step procedure. For this authentication, the server 5, 6 must know the identity of the client 1 and have assigned a password to it. This information must be stored on the server 5,6. In the IMS, a user is logged on to the IMS using the registration procedure. For this purpose, the IMS client sends a SIP registration message (SIP REGISTER) to the S-CSCF 3. This then sends back a "401 Unauthorized" response. This message contains a challenge that can only be answered with the key stored on the SIM (Subscriber Identity Module). The IMS client then sends the response in a further REGISTER message to S-CSCF 3. If the answer is correct, S-CSCF then sends a "200_OK" response message back to the IMS client. In a first embodiment, the login procedure can be mapped to IMS signaling as follows. The WV Client 1 first sends the LoginRequest (Nl) to the mapping function A 2. This then generates a SIP REGISTER message N2. The "From:" header contains the address of the mapping function 2. The request URI "Request URI" contains the domains

(Domain) Name of the user's home network. In addition, an "authorization" header is included, which contains the address of the user. The REGISTER message is then sent to the S-CSCF 3 (N2). This asks the user database HSS 4 (Home Subscriber Service) with a message N3. In the user database, the user is also known as a WV user. Therefore, the user database also sends the password in response N4 that the user uses for authentication in accordance with the WV standard. The S-CSCF 3 now generates a challenge and sends it back to the mapping function 2 in a "401 Unauthorized" (N5) message. According to RFC 2617 (HTTP Authentication: Basic and Digest Access Authentication), the challenge can be transported in the "nonce" parameter. The challenge is contained in the "WWW-Authenticate" header. The mapping function 2 sends the challenge in a login response message (N6) to the WV client 1. The challenge is transported in the information element "nonce". The WV Client 1 relates the challenge and the password it uses and runs an algorithm over it. The WV Client 1 sends the data generated in this way in a further login request message (N7) to the mapping function 2. This then generates a SIP REGISTER message (N8), similar to N2, which this time contains the answer to the challenge in the "Authorization" header. The S-CSCF 3 now uses an algorithm to check whether the correct challenge and the correct password were used to generate the answer. If this is the case, the S-CSCF 3 regards the user as authorized and sends a message "200_OK" (N9) back to the mapping function 2 in order to signal the correct registration. The mapping function 2 then sends a login response message (login response) (N10) to the WV client 1 in which the successful registration is signaled. According to the invention, the mapping function 2 also stores the response if the authentication is correct in order to reuse it for later re-REGISTER messages. This version is particularly advantageous because the

Mapping function 2 no user-specific data such as identities or passwords need to be stored here. This solution is particularly advantageous since no user data need to be maintained in the mapping function 2, and the authentication and authorization can take place centrally in the IMS network.

FIG. 13 shows a flow chart for a login / logout transaction with the exchange of character strings. In a second embodiment, the mapping function 2 itself can store the user identities and the associated passwords. The WV client again sends a login request (Nl) to the mapping function 2. The mapping function 2 responds with a login response message (N2), which contains a challenge. The WV Client 1 in turn calculates the response and sends it with a further login request message (N3) to the mapping function 2. This (2) checks whether the response correct is. If this is the case, it (2) sends a SIP REGISTER message to the S-CSCF 3. The "front:" header contains the address of the mapping function 2. The request URI contains the domain name of the user's home network. The address of the user is included in the "To:" header. This has taken the mapping function 2 from the login request message and replaced the "v:" abbreviation by the "sip:" abbreviation. This registration procedure is a so-called "3rd party registration" as described in 3GPP TS 24.229 (IP Multimedia Call Control Protocol based on SIP and SDP). This means that the registration is not carried out directly by the IMS client, but by another network unit - in this case the mapping function 2. The advantage of this solution is that no changes in the IMS are necessary.

The login request message (Nl and N6 in FIG. 12 and Nl and N3 in FIG. 13) contains a lifetime information element (TimeToLive) which specifies how long the registration should be valid. A corresponding one is for SIP

Expiry time header defines which has the same meaning in connection with the REGISTER message. The mapping function 2 can thus copy the value in the lifetime field (TimeToLive) into the expiry time field. In the login response message, in the event that the registration was successful, there is a "keep alive information element that indicates when the registration expires. For SIP, this is again implemented using the expiry time header, which is contained in the "200_OK" response message. The mapping function 2 can therefore again determine the value of the expiry time header from the 200 OK message (N9 in FIG. 12 or N5 in FIG. 13). Copy to the "keep alive" field of the login response message (N10 in Figure 12 or N6 in Figure 13).

FIG. 14 shows the message exchange that is necessary to map a logout transaction on IMS signaling.

For this purpose, the WV client 1 sends a logout request message N1 to the mapping function 2. The mapping function 2 then generates a SIP REGISTER message (N2). The only difference to the SIP REGISTER messages as they were used for the login transaction is that the expiry time header is set to the value "0". After de-registration, the S-CSCF 3 sends a "200_OK" message N3 to the mapping function 2. The mapping function 2 again takes the address of the client 1 from this message and replaces the "sip:" abbreviation with the "wv:" abbreviation and sends a "Disconnect * (Disconnect) message to WV Client 1, which contains the result of the deregistration (successful / unsuccessful).

FIG. 15 shows the mapping of the WV signaling onto the IMS signaling. A WV client can use this procedure to register information about the presence of another user or a user group. To do this, he specifies the address of one or more users and / or user groups. This is shown in URI format (eg firstname.lastname@company.com) which is also preceded by a "wv:" abbreviation. It is also possible to specify the type of presence information the WV Client 1 is interested in. Only these will then be sent to him. The presence information is sent using the notification procedure. It contains the presence information of one or more users and / or User groups included. In IMS, presence information is only registered for a single user or a single user group. The WV Client 1 sends a participation presence request message (Subscribe Presence Request) (Nl) to the mapping function 2. If this message explicitly states what type of presence information is desired, it saves the

Mapping function 2 this information. This is necessary because it is not possible in the IMS to only register information about parts of presence. This can change in the future. In this case, the filters specified in the WV message would also have to be mapped from mapping function 2 to the filters used in the IMS. In the following it is assumed that no filters are defined for IMS and that a user therefore always inserts information about all presence. The mapping function 2 also takes from the message the list of users and user groups to which the WV Client 1 wants to register. For each of the users or the user groups, the mapping function 2 generates a SIP PARTICIPATION message. The address of the user or user group is contained in the request URI of the respective message. According to the invention, a separate participation message is generated for each user that is contained in the information element User ID list of the attendance presence request message (Subscribe Presence Request), the event header being set to the value “presence”. Furthermore, according to the invention, a separate participation message is generated for each user group that is contained in the information element “contact list ID list” of the attendance presence request message (Subscribe Presence Request), the event header pointing to the value “presence list "is set. This example is meant for simplicity for the sake of being assumed that only two addresses are contained in the information element "user ID list". Therefore two participation messages (N2 and N3) are generated whose event header is set to the value "presence". With the help of the event header, the S-CSCF 3 can later decide whether the attendance messages should be forwarded to the Presence Server (PS) 5 (for a single user) or to the Presence List Server (PLS) 6 (for user groups). All other fields are set as described in RFC 3265 (Event Notification Framework). The identity of the WV Client 1 (or the user) is contained in the "From:" header. The "Contact" header bears the IP address of the mapping function 2. A participation message also contains an expiry time header that specifies how long an enrollment should be valid. An equivalent piece of information is not included in the WV Client 1 attendance presence request message (Subscribe Presence Request). According to the WV standard, registration is valid until the WV Client 1 sends a Presence Unsubscribe Request message. According to this invention, the mapping function 2 sets the expiry time header to a certain value. If the time runs out and the mapping function 2 has not received a non-participation presence request message (Unsubscribe Presence Request) from the WV Client 1, it sends a participation message again, with which the registration is extended.

The messages N2 and N3 are then forwarded via the S-CSCF 3 to the presence server 5 or the presence list server 6, which is responsible for the user or the user group. In this example, for the sake of simplicity, it is assumed that the same presence server 5 is responsible for the two users. The news N2 and N3 are therefore forwarded to the same presence server 5. If the WV client (or its user) is authorized to enter the presence information of the specified users, the presence server 5 (or in the case of user groups the presence list server) sends a message

"200_OK" back to mapping function 2 (messages N4 and N5).

The mapping function 2 then sends a message N6 to the WV client 1 to inform the client that the enrollment was successful. In addition, the presence server 5 (or, presence list server) sends a notification to the mapping function 2 after the registration, in which the presence information of the corresponding user (or in the case of a user group, all users of this group) is contained. In this embodiment, the

Presence Server 5 thus two SIP notification messages (NOTIFY) N7 and Nil to the mapping function 2. In this example it is assumed that it is not possible in IMS to only register information about parts of the presence. Therefore, as described above, the mapping function 2 has stored the information about what type of presence information the WV client 1 wants to register. In the event that all the presence is contained in the notification message received from the presence server 5, the mapping function 2 now only directs the presence

Presence Information to the WV Client 1, for which the latter has also registered. The messages N8 and N12 thus only contain the attributes of the presence information. The WV Client 1 confirms the receipt of the notification messages with a status message (N9 and N13). These are mapped by the mapping function 2 to a SIP "200 OK" message (N10 and N14). FIG. 16 shows a flow chart for a presence transaction for a non-participation. This procedure can be used by a WV Client 1 to end a registration for the presence information of one or more users or user groups. For every user or everyone

User group, which is included in the non-attendance presence request message (Unsubscribe Presence Request), a SIP PARTICIPATION message is generated by the mapping function 2. The procedure up to and including message N6 corresponds to that for the registration to attendance

Information. The only difference is that message N1 is now an unsubscribe presence request message and that mapping function 2 sets the expiry time header in the participation messages (N2 and N3) to the value "0" becomes. The presence server 5 or presence list server 6 is thus informed that the registration should be ended. According to RFC 3265 (Event Notification Framework), every participation message is followed by a notification. This means that the presence server 5 or the presence list server 6 sends a SIP notification message (NOTIFY) for each user or user group to the mapping function 2, although the mapping function 2 only wanted to end the enrollment. According to this invention, these notification messages (N7 and N9) are to be terminated in the mapping function 2. The mapping function 2 confirms receipt of the NOTIFY messages with the messages N8 and N10 (200_OK), but does not send any further messages to the WV client 1.

FIG. 17 shows a flow chart for a hole observer list transaction or hole presence transaction. With the help of this procedure, a WV Client 1 can find out which one Users have currently registered information about their presence. The WV Client 1 sends a Get Watcher List Request (Nl) to the mapping function 2. This generates a SIP PARTICIPATION message (N2), similar to the registration for presence information. Since the WV procedure involves a "fetching" of the information once, the mapping function 2 sets the expiry time header of the participation message to the value "0". This will end the enrollment immediately after the notification is sent. The event header is like in draft-ietf- simple-winfo-package-02. txt http: // www. ietf .org / internet- drafts / draft-ietf-simple-winfo-package-02. txt "Session Initiation Protocol (SIP) Event Template Package for Watcher Information" described, set to the value "presence .winfo". This information informs the Presence Server 5 in the IMS that the list of registered users is desired. The address of the WV client 1 (or its user) is also contained in the request URI. The address of the mapping function 2 is contained in the "Contact" header. The presence server 5 confirms receipt with the aid of a "200_OK" message (N3). The presence server 5 then sends a SIP notification message (NOTIFY) (N4) to the mapping function 2. This contains the list of users who have registered information about the presence of the WV client 1 (or its user). The mapping function 2 then sends this using the Get Watcher List Response message N5 to the WV Client 1. The Get Presence transaction (Get Presence) can be used to provide a one-time presence information or multiple users or user groups. The mapping of the WV signaling to the IMS signaling is similar the one for the Get Watcher List transaction. In this case, the message N1 is merely a Get Presence Request message. The mapping function 2 then in turn generates a SIP PARTICIPATION message for each user or user group address contained in the get watcher list request message (Get Watcher List Request). For the sake of simplicity, it is assumed for this example that only one user address was included and therefore only one participation message is generated. Since this WV procedure is once again a "fetching" of the information, the mapping function 2 sets the expiry time header of the participation message to the value "0". This will end the enrollment immediately after the notification is sent. The event header is as in draft-ietf-simple-presence-06. txt http: // www. ietf.org/internet- drafts / draft-ietf-simple-presence-07. txt "Session Initiation Protocol (SIP) Extensions for Presence" described, set to the value "Presence". The request URI contains the address of the user whose presence the WV client (or his user) would like to request. The address of the mapping function 2 is contained in the "Contact" header. In the WV message Get Presence Request (Get Presence

Request), you can also specify the type of presence information that WV Client 1 or its users are interested in. If this message explicitly states what type of presence information is desired, the mapping function 2 stores this information. This is necessary, it is not possible in the IMS to only register information about parts of presence. This can change in the future. In this case the filters specified in the WV message are also mapped by mapping function 2 to the filters used in the IMS. In the following it is assumed that no filters are defined for IMS and that a user therefore always inserts information about all presence. The presence server 5 confirms receipt with the aid of a "200_OK" message (N3). ^• The presence server 5 then sends a SIP notification message (NOTIFY) • (N4) to the mapping function 2. This contains the presence information of the corresponding user. In this example it is assumed that it is not possible in IMS to only register information about parts of the presence. Therefore, the mapping function 2, as described above, has stored the information about what type of presence information the WV Client 1 wants to register. In the event that all the presence information is contained in the notification message received from the presence server 5, the mapping function 2 now forwards the presence information to the WV client 1 in the get presence response (Get Presence .Response) (N5), for which he has also registered.

Figure 18 shows a flowchart for an update presence transaction. With the help of the update presence transaction, a WV client 1 can update the presence information of its user on the presence server 5. For this purpose, the list of the presence information to be updated is contained in the message. The WV Client 1 sends an update presence request message to the mapping function 2. This contains only the presence information to be updated. If this is the first transaction after logging on to the Presence service, it can be assumed that all of them are initially Presence information is included. However, this is not necessarily the case. It is currently not possible in the IMS to update only parts of presence information. This can change in the future. In this case, the mapping function 2 could

Map update presence request message directly to a SIP publication message. In the following it is assumed that this is not possible in the IMS and therefore all presence information of the user must always be contained in the publication message. In order to achieve this, a distinction is made between two versions below. In the first case, it is assumed that after the registration at the presence service, a first update presence transaction is always carried out, in which all presence

Information is communicated to the Presence Server 5. The update presence request message N1 is this first initial update of the presence information and contains all presence information. According to the invention, these are stored by the mapping function 2. The mapping function 2 then generates a SIP publication message (N2) in accordance with draft-olson-si ple-publish (http: // www. Ietf. Org / internet-drafts / draft-olson-simple-publish-01.txt "SIMPLE Presence Publication Mechanis "), which also contains all presence information. The request URI is set to the address of the WV client 1 or its user. The event header is set to the "Presence" value. The "Contact" header is set to the address of the mapping function 2. The presence server confirms receipt with a "200_OK" message

(N3). The mapping function 2 confirms the WV client 1 the correct update with a status message. The user of the WV Client 1 now changes parts of his presence Information, the WV Client 1 in turn sends an update presence request message (N5) to the mapping function 2. This now only contains the presence information to be updated. The mapping function 2 replaces the updated presence information and stores all presence information. Then it generates a SIP publication message (PUBLISH) (N6) again. However, she now inserts all presence information into this. This is possible because the mapping function 2 shows the latest status of the presence

Has stored information and thus knows the current status of all presence information. The values of the headers are set as in the first initial publication message. The presence server 5 confirms the receipt of the message N6 with a "200_OK" message N7. The mapping function 2 in turn confirms the WV client 1 the correct update with a status message (N8).

FIG. 19 shows a flowchart with an alternative for an update presence transaction. In a second case, it is assumed that each update presence request message can only contain parts of the presence information. This also applies to the first, initial update presence request message. This would be the case, for example, if a default setting for presence information is stored on the Presence Server 5, which is also known in the WV Client 1. In order to update the presence information of the WV client 1 (or the user), the mapping function 2 inserts information about the presence of the WV client 1 (or the user) about its presence. For this, the mapping function 2 generates a SIP PARTICIPATION Message which bears the address of the user of the WV client 1 as the request URI. The event header is set to the "Presence" value. The "From:" and "Contact" headers have the addresses of the mapping function 2. The expiry time header can be set to a value greater than zero. In this case, the mapping function 2 is notified every time the presence information has changed. The advantage of this solution is that the mapping function 2 does not have to keep the presence information up to date. Alternatively, the expiry time header can also be set to the value "0". Then the mapping function 2 is only notified once. The mapping function 2 must then independently keep the presence information up to date, that is to say the updated information contained in the update presence request message (update presence request) must be transferred to the stored data record. The participation message (Nl) is then sent to the presence server 5, which confirms the successful registration with a 200_OK message (N2). The presence server 5 then sends a SIP notification message (NOTIFY) (N3) to the mapping function 2, which contains all currently valid presence information. This information is provided by the. Mapping function 2 saved. The mapping function 2 confirms receipt with a "200_OK" message (N4). If the WV client 1 now sends an update presence request message (N5) to the mapping function 2, the mapping function 2 generates a SIP publication -Message. This contains all presence information for the user. The presence information that was not contained in the update presence request message is thereby from the mapping function 2 with the help of the stored information.

Has the mapping function 2 got the presence information of the user with a participation message in which the expiry time header was set to "0", or is the mapping of the mapping function 2 for the presence information of the user. expired, 2 handles the mapping function is also the ^'in the presence Aktüalisierungs- requests message (Update Presence Request) information contained in order by the

Mapping function 2 stored presence information to keep up to date.

The mapping function 2 then sends the publication message to the presence server 5 (N6). The request URI was set to the address of the WV client 1 or its user. The event header was set to the value "Presence" and the "Contact" header to the address of the mapping function 2. The Presence Server 5 confirms receipt and successful update using a "200_OK"

Message (N7). The mapping function 2 in turn confirms the successful update to the WV client 1 with the aid of a status message (N8). If the mapping function 2 is still registered with the presence information of the user of the WV client 1, the presence server 5 also notifies the mapping function 2 with the aid of a SIP notification message (NOTIFY) (N9) which contains all currently valid presence information. The mapping function 2 replaces the stored presence information and is thus up to date. It then confirms receipt of the notification message with a "200_OK" message (N10). FIG. 20 shows a schematic illustration of a mapping function 2 with a receiving unit 7 for receiving a signaling procedure according to the WV standard from a WV client 1, a processing unit for recognizing an indicator which specifies the mapping rule to be used and for mapping with the mapping rule using a signaling procedure according to the IMS standard in the signaling procedure (transaction) and with a transmitting unit 9 for sending the signaling procedure to a presence server 5.

Claims

Patent claims

1. Method for mapping at least one signaling procedure according to the Wireless Village standard into at least one signaling procedure according to the IP multimedia subsystem standard in a mobile communications network,

characterized

that an indicator in a signaling procedure signals the mapping rule to be used and that a mapping function (2) carries out a mapping of at least one signaling procedure in accordance with this mapping rule.

2. Method according to claim 1,

characterized thereby,

that at least one SIP protocol message is used for a signaling procedure in accordance with the IP multimedia subsystem standard.

3. Method according to one of the preceding claims,

characterized,

that a mapping function (2) inserts at least one character string into at least one signaling procedure that specifies the presence service signaling standard to be used.

4. Method according to one of the preceding claims,

characterized thereby,

that a mapping function (2) responds to a service request with a service response message.

5. Method according to claim 4,

characterized,

that the mapping function (2) inserts a character string as a mapping rule, depending on the recipient of the signaling procedure, which specifies the presence service signaling standard to be used.

6. Method according to one of the preceding claims,

/ characterized,

that the indicator and/or the character string consists of alphanumeric characters.

7. Method according to one of the preceding claims,

characterized,

that a character string is preceded by the identification of a user of a mobile device.

8. Method according to one of the preceding claims, characterized,

that an address in URI format is used to identify a user of a mobile device.

9. Method according to one of the preceding claims,

characterized,

that the same address is used for signaling both in the direction of a mobile terminal and in the direction of a presence server (5).

10.The method according to claim 9,

characterized,

that a mapping function (2) adds the domain of the mobile terminal to the address.

11. Method according to one of the preceding claims,

characterized,

that the mapping function (2) according to one

Mapping rule maps information in the expiration time header in the response message to the register message and/or to the “keep alive*” information element in the login response message.

12. Method according to one of the preceding claims, characterized,

that, as a mapping rule, a header line in a message is expanded with a parameter that specifies the maximum size of the message to be sent to the WV client (1).

13. Method according to one of the preceding claims,

characterized,

that the message is a request and/or response message in accordance with the WV standard and/or IMS standard.

14. Method according to one of the preceding claims,

characterized,

that an authorization header with the result regarding the authorization, an accept header regarding the acceptance of presence information of at least one data type and / or a parameter regarding the maximum size of the presence information to be sent is added as a mapping rule to a SIP register message.

15. Method according to one of the preceding claims,

characterized,

that a mapping function (2) stores presence information attributes received from a WV client (1) in a message in accordance with the WV standard in a storage element.

16. Method according to claim 15,

characterized thereby,

that only the presence information that is stored in the storage element is forwarded to the WV client (1) and/or presence server (5).

17. Method according to one of the preceding claims,

characterized,

that to map a non-participation presence request message, according to the WV standard, to a SIP participation message according to the IMS standard for each user included in the information element “User ID list* of the participation presence request message is, a separate participation message is generated.

18. Method according to claim 17,

characterized,

that the event header in the participation message is set to the value “Presence*”.

19. Method according to one of the preceding claims,

characterized,

that in order to map a hole watcher list request message according to the WV standard to a SIP participation message according to the IMS standard, by the Event header in the SIP participation message is set to the value “Presence.winfo* and/or the expiry time header in the SIP participation message is set to the value “0*”.

20. Method according to one of the preceding claims,

characterized,

that as a mapping rule, presence information from a login request message is written into a SIP register message.

21. Method according to one of the preceding claims,

characterized,

that information relating ^to the use of a WV client (1) is stored by a user of a terminal in a storage element provided for this purpose.

22.Procedure according to. one of the preceding claims,

characterized,

that as a mapping rule when mapping a logout request message to a SIP register message, the expiration time header receives the value “0*.

23. Method according to one of the preceding claims,

characterized, that a received service request message is answered by a mapping function (2) with a service response message.

2. Method according to one of the preceding claims,

characterized,

that a separate subscriber message is generated for each user of a terminal that is contained in an information element “User ID list*” of the subscriber presence request message.

25. Method according to claim 24,

characterized,

that the event header in the participant message is set to the value “Presence*”.

26. Method according to one of the preceding claims,

characterized,

that the SIP notification message is terminated at the mapping function (2).

27.Device for imaging at least one

Signaling procedure according to the Wireless Village standard in at least one signaling procedure according to the IP Multimedia Subsystem standard in a mobile communications network, - with an reception unit (7) in a mapping function

(2) for receiving at least one signaling procedure according to the Wireless Village standard from a mobile radio terminal, - with a processing unit (8) for recognizing a

Indicator that indicates the mapping rule to be used and for mapping with the mapping rule to be used a signaling procedure according to the Wireless Village standard into a signaling procedure according to the IP Multimedia Subsystem standard

- with a sending unit (9) for sending the signaling procedure to a presence server (5).