RU2389148C2 - Method and device for identifying ims service - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: there is proposed method of indicating IP multimedia subsystem communication service(s) related to a session initiating protocol message. The method includes one or more communication service identifiers in the session initiating protocol message as a message feature tag.

EFFECT: improved rendering of communication services.

12 cl, 11 dwg

Description

FIELD OF THE INVENTION

The present invention relates to a method and apparatus for identifying an IP multimedia subsystem (IMS) service, and in particular, for identifying an IMS service to which an IMS communication or communication request relates.

State of the art

IP multimedia services provide a dynamic combination of voice, video, messaging, data, etc. in one session. Due to the increase in the number of basic applications and forms of multimedia information that can be combined, the number of services offered to end users is growing, and the experience of interpersonal communication is being enriched. This leads to a new generation of personalized multimedia services with rich capabilities, including the so-called “combined IP multimedia” services, which are discussed in more detail below.

The IP Multimedia Subsystem (IMS) is a technology defined by the Third Generation Partnership Project (3GPP) to provide IP multimedia services over mobile networks (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 revision 5 and revision 6). IMS provides key features to expand the interpersonal capabilities of end users through the use of standardized IMS service resolution tools that simplify new advanced interpersonal services (client-client), as well as user-content (client-server) services IP networks. The IMS uses Session Initiation Protocol (SIP) to establish and manage calls or sessions between subscriber terminals (or subscriber terminals and application servers). Session Description Protocol (SDP), transmitted through SIP service signals, is used to describe and negotiate the multimedia session components. Although SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to properly bill users.

1 schematically illustrates how an IMS integrates into a mobile network architecture in the case of a GPRS / PS access network. Call / Session Management Functions (CSCFs) act as SIP proxies for IMS. The 3GPP architecture defines three types of CSCF: proxy CSCF (P-CSCF), which is the first point of interaction in the IMS for the SIP terminal; Serving CSCF (S-CSCF), which provides services to the user to which the user is subscribed; and a CSCF Interrogator (I-CSCF), the role of which is to identify the correct S-CSCF and forward the request received from the SIP terminal via the P-CSCF to this S-CSCF.

The user registers with IMS using the specified SIP REGISTER method. It is a mechanism for attaching to IMS and messages in IMS addresses, at which SIP user credentials can be obtained. In 3GPP, when the SIP terminal performs registration, the IMS authenticates the user and assigns the S-CSCF to this user from the set of available S-CSCFs. Although S-CSCF assignment criteria are not specified by 3GPP, they may include sharing and maintenance requirements. It should be noted that the purpose of the S-CSCF is of great importance for managing (and billing) user access to IMS services. Operators can provide a mechanism to prevent direct SIP user-to-user sessions that otherwise bypass the S-CSCF.

During the registration process, the I-CSCF is responsible for selecting the S-CSCF if an S-CSCF has not yet been selected. The I-CSCF receives the desired S-CSCF characteristics from the home subscriber server (HSS) of the home network and selects the appropriate S-CSCF based on the received characteristics. (It should be noted that the assignment of the S-CSCF is also transmitted to the user via the I-CSCF if the user is called by the other party and the user is not currently assigned to the S-CSCF). When a registered user subsequently sends a session request to the IMS, the P-CSCF may redirect the request to the selected S-CSCF based on information received from the S-CSCF during the registration process.

Within an IMS service network, application servers (AS) are provided to implement the functionality of IMS services. Application servers provide services to end users in the IMS system and can either be connected as endpoints via a project-specific 3GPP Mr interface, or they can be “involved” through S-CSCF via a project-specific 3GPP ISC interface. In the second case, the initial filtering criteria (IFC) are used by the S-CSCF to determine which application servers should be “involved” during the establishment of the SIP session. IFCs are received through the S-CSCF from the HSS during the IMS registration procedure as part of the user profile.

2 illustrates an IMS Service Management Interface (ISC) between an AS and an S-CSCF, as well as other interfaces in an IMS. Although the AS in FIG. 2 is shown as having only one interface with S-CSCF, it should be taken into account that in practice the ISC interface is distributed over a communication network to which most (or all) CSCF servers of a given operator’s network are connected, allowing the AS to exchange data with all of these CSCF features. (Other objects illustrated in Fig. 1 should be well known to specialists in this field of technology).

An additional interface (Ut) is provided between the AS and the subscriber terminal (TS23.002), although it is not shown in the drawing. The Ut-interface allows the user to manage information related to his services, for example, creating and assigning public service keys, administering authorization policies, which are used, for example, through "presence" services, administering conference policies, etc.

Disclosure of invention

Since IMS services are required, various communication services probably require different processing through IMS and through user terminals. More specific:

- various services may require the "involvement" of various application servers via the ISC interface;

- sessions can be routed to the various end-user terminals that this user has registered with IMS, depending on the service to which the session belongs (a comparison of the characteristics of the terminal with the type of service can be used, for example, to avoid branching);

- various functional entities in the receiver terminal may be designed to handle various services (e.g., PoC and P2P multimedia);

- network operators may have different levels of authorization for various services;

- various correct multimedia authorization policies can be applied to various services. For example, speech (audio) in PoC does not require the same quality of service support on the network as P2P multimedia, and accordingly, the forms of multimedia information are assigned appropriately;

- the network operator may have different change rules depending on the IMS service;

- the interworking requirements for a service (for example, deferred IMS messaging, MMS) may depend on the IMS service.

Session Description Protocol (SDP) for SIP defines a so-called m-line field that defines the initial type of form of multimedia information that should be used for an IMS service. For example, an m-string may specify "audio 20,000 RTP / AVP 0" or "video 20,000 RTP / AVP 0". (The m-string format is described in IETF RFC (2327). 20,000 is the port number to be used, and RTP is the protocol. AVPs are set for different protocols, and the values assigned by AVP have different meanings depending on the protocols. A specific value, for example, may express which codec should be used). It was contemplated that m-string information could be used to identify the type of IMS communication service. However, the success of IMS has led to the fact that there are a number of different communication services using the same type of form of multimedia information. For example, both PoC and interpersonal multimedia can use the type of multimedia information "audio". The m-string information, as a result, cannot be used to uniquely identify the IMS communication service. This problem has been identified by the present inventors in a 3GPP article entitled "IMS Communication Service Identifier (ServID)".

According to a first aspect of the present invention, there is provided a method for indicating communication services (and) of an IP multimedia subsystem to which a session initiation protocol message relates, the method comprising including one or more communication service identifiers in a session initiation protocol message as a message attribute tag, wherein a communication service identifier identifies one of a plurality of communication services.

A SIP message may include one or more communication service identifiers as feature tags, for example, in the case of a SIP REGISTER message.

A tag tag can be included in the Contact header, Accept-Contact header, or Reject-Contact header during registration or as caller preferences when establishing a session or delivering messages for SIP messages that are not session-based, such as SIP messages MESSAGE.

According to a second aspect of the present invention, there is provided a method for identifying an application residing in a subscriber terminal to which a session initiation protocol message relates, the method comprising including a reference to the application in a session initiation protocol message.

A reference to the application can be included in the SIP message header as a tag tag, for example, in the Contact header in REGISTER messages and in the Accept-Contact or Reject-Contact headers in other SIP messages (for example, INVITE). Alternatively, a reference to the application may be included as an a-line supplementing the m-line in the SDP part of the SIP message. Links to applications can be included both as a tag of an attribute and as an a-line in one SIP message, for example, identifying the main application and the auxiliary application, respectively.

A preferred embodiment of the present invention combines the first and second aspects of the present invention. In the subscriber terminal or the IMS network node, the IMS stack identifies the corresponding communication service based on the communication service identifier contained in the received message of the session initiation protocol, and redirects the message to a functional (software) object that implements this service. This functional entity is referred to herein as a communication service. A communication service that receives message identifiers identifies the corresponding application based on the application link contained in the session initiation protocol message and redirects the message to this application.

According to a third aspect of the present invention, there is provided a method for allowing a plurality of communication services to be associated together within an IP multimedia subsystem or subscriber unit, the method comprising identifying each associated service as a feature tag in a session initiation protocol message.

For example, the invention may provide the ability to associatively associate multiple simultaneous IMS communication services, for example, P2P multimedia with IMS messaging, and / or interconnect IMS communication services with other simultaneous service sessions, for example, circuit-switched speech.

In a preferred embodiment of the invention, this third aspect is combined with one or both of the first and second aspects of the invention.

Other aspects of the invention include:

- subscriber terminals and network nodes containing means for inserting a communication service identifier of a communication service identifier as a message attribute tag into a message of a session initiation protocol;

- subscriber terminals and network nodes containing means for inserting a link to the application into the message of the protocol for initiating the session; and

- subscriber terminals and network nodes containing means for inserting a session initiation protocol into a message.

According to additional aspects of the invention, one or more new SIP information elements (parameters) can be standardized so as to transmit one or more of: a communication service identifier, an application link, and an MCS specifier (communication service associative identifier).

Brief Description of the Drawings

Figure 1 schematically illustrates the integration of the IP multimedia subsystem into 3G mobile communication systems;

Figure 2 schematically illustrates specific entities of the IP multimedia subsystem, including an application server and a serving call / mode management function;

Figure 3 illustrates an example SIP REGISTER message containing communication service identifiers;

Figure 4 illustrates an example SIP INVITE message containing communication service identifiers;

5 schematically illustrates a UE architecture that applies communication service identifiers and application references;

6 schematically illustrates a terminal architecture in which one application implements SIP-based communications that are commercial for the application;

7 illustrates an example SIP REGISTER message comprising communication service identifiers and application references;

FIG. 8 illustrates an example SIP INVITE message comprising communication service identifiers and application references;

FIG. 9 schematically illustrates a UE architecture that applies communication service identifiers, application references, and qualifiers of several communication services;

10 illustrates an example SIP INVITE message comprising communication service identifiers, application references, and qualifiers of several communication services; and

11 illustrates an example of a SIP message comprising communication service identifiers, application links, and qualifiers of several communication services.

The implementation of the invention

The ability to identify a specific IP Multimedia Subsystem (IMS) service to which a Session Initiation Protocol (SIP) message relates provides several advantages. They are already discussed above. In this case, it is intended to simplify this identification by including the “communication service identifier” in the SIP message, and, in particular, by including the communication service identifier as a feature tag.

The corresponding attribute tag is included in one of the Contact (REGISTER), Accept-Contact or Reject-Contact SIP message headers as one of the "caller preferences". Examples of service identifiers are as follows:

"+ g.communication service = + g.p2p.multimedia"

"+ g.communication service = + g.poc.talkburst"

"+ g.communication service = + g.instant.messaging"

"+ g.communication service = + g.deferred.multimedia.messaging",

where, for example, the suffix "multimedia" identifies the IMS communication service.

Figure 3 illustrates the structure (partially) of a SIP REGISTER message that identifies communication services that are supported by the message sender (subscriber unit) by including communication service identifiers in the Contact header. Tag tags in registration messages notify the network about the characteristics of the terminal. The network (for example, in the S-CSCF) can use this information to correlate the preferences of the caller, expressed through the initiator of the SIP session, with the set of registered terminals of the recipient that most closely matches the requested preferences of the caller. In the illustrated example, the supported services are as follows: multimedia; speech packet; and multimedia messaging. This REGISTER message is sent by the UE to the Call / Session Management Function (S-CSCF).

Figure 4 illustrates the structure (partial) of the SIP INVITE message, which is used to start a dedicated IMS communications service. The INVITE message identifies in the Accept-Contact header a form of multimedia information supported by the initiating UE, i.e. audio, video, data, as well as the service to which the message relates, i.e. interpersonal (P2P) multimedia. The M-line of the SDP part of the message indicates that the session is initially an audio-only session. Other forms of multimedia information, audio, and data identified in the Accept-Contact header are forms of multimedia information that can be used in a session, but are not used initially. The final recipient of this message is a peer UE identified by the example "SIP URI SIP-URI1@operator.com". However, it is likely that the S-CSCF serving the initiating UE will analyze the message and may decide whether or not to forward the message, depending on the service identified by the communication service identifier. If the subscriber is authorized to use the P2P multimedia service, INVITE is redirected to the receiving UE (selected if necessary based on the characteristics). Billing can also be initiated based on the service or SIP AS involved in the SIP message channel.

As an improvement to the described approach, the identifier of the communication services in the tag of the attribute may be supplemented with the version number of the corresponding service.

In a typical UE, specific (standardized) communication services are most likely handled by applications, which in most cases are provided by “specialized” terminal manufacturers. These applications may conform to certain agreed standards and are referred to herein as “default” applications for a standardized, communications-based IMS service. Examples include default applications for handling P2P multimedia and PoC sessions. Other applications hosted by the UE may not be standardized, such as gaming-related applications or specialized corporate office applications. 5 illustrates communications applications and services hosted in a UE over an IMS stack.

It is useful to be able to specify an application in a SIP message that must be used in order to process a particular communication service by means of an “application link”. This is useful when the IMS communication service allows applications to exchange data according to the rules, procedures, and associated forms of multimedia information specified for the communication service. An application that uses an IMS communication service does not implement part of the service for SIP communication, but uses (ie, "combines") a communication service for this purpose through an internal interface. The application link identifies the application on top of the communication service. Also note that the application can implement communication based on SIP, which is specialized for the application, in which case the application must be identified using the communication service identifier. This is illustrated in FIG. 6.

A link to the application can be implemented as a tag tag or as an a-line supplementing the m-line in the SDP part of the SIP message. Both options have their advantages and disadvantages.

Link to the application as a tag tag

The inclusion of an application link as a tag tag has the advantage that this mechanism can be used for all SIP messages (i.e., not only for transmitting SDPs). This mechanism also indicates to the recipient the endpoint for which the application should be used in relation to the communication service to be installed. This application is the "main" application of the session and controls the addition of types of multimedia information to it. However, such a mechanism can only be used when establishing a session and is not suitable for indicating “complementary functionality” during an established session, for example, to specify which transmission medium for RE-INVITE should be used for a specific functionality. For example, using the tag tag approach alone does not allow you to specify that the message session forwarding protocol (MSRP) should be used for Whiteboarding, not for PictureViewer.

Link to the application as an a-line, complementing the m-line in SDP

This mechanism has the advantage that it can be used to indicate “complementary functionality” in an established SIP session. The recipient application is expressed in an a-line that follows the m-line indicating the original type of multimedia information to be used. However, this mechanism can only be used for SIP messages that transmit an SDP body (for example, not for a SIP MESSAGE message).

By combining these two approaches, the disadvantages can be eliminated. Accordingly, it is proposed to provide the opportunity for the link to the application to be transmitted both as a tag of the attribute and in the SDP body. The tag tag is used to indicate the "main application" for the session. For standardized communication services, it is the “default application” and may be assigned the same value as the communication service identifier. For example:

"Communication Service Identifier = P2P Multimedia

Application References P2P Multimedia "

Of course, you can omit the link to the application when the application is the default application.

In applications specialized for the operator or manufacturer that use standardized communication services, a link to the application contains the name of this application. For example:

"Communication Service Identifier = P2P Multimedia

Application Reference = OperatorOfficeHelper "

The tag tag is always used to indicate the application of the recipient when the type of SIP message does not transmit an SDP body (for example, a SIP MESSAGE message).

The A-line in the SDP body is used to complement the m-line to clarify the context in which the m-line is used when the type of SIP message transmits the SDP body (for example, INVITE).

7 illustrates the structure of a SIP REGISTER message, where feature tags identifying communication services supported by the sending UE are identified in the Contact header. FIG. 8 illustrates the structure of a SIP INVITE message for initiating a session between a triggering UE and a UE identified by SIP URI SIP-URI1@operator.com. The communication service identifier (+ gp2p.multimedia) is included as a single tag tag, while the application link (+ gcommunication service) is included as a second tag tag to identify the main application. An A-line is included in order to identify an additional application (3gpp.VideoSharing) that may be involved in the same session through the main application.

There is a need for the ability to identify parallel communication services (IMS services and other services, for example, circuit switched speech (CS)) that are associated with an application within the IMS and UE. The identifier referred to as the MCS specifier in this document allows the application to correlate several parallel sessions of IMS communications services (for example, P2P multimedia and IMS messaging), as well as interconnect IMS communications services with other non-IMS sessions , for example, CS-speech.

The MCS specifier can be used, for example, to determine the tariff that should be applied to a session. In one example, CS speech can be combined with a P2P multimedia IMS service for video sharing implemented as a combination service (CSI). The presence of the MCS specifier allows the network to determine this and apply various billing rules and rates to the IMS part of the connection for video transmission, billing rules and rates that differ from those used when transmitting video over IMS in a "non-CSI context" , i.e. IMS in an autonomous context.

FIG. 9 illustrates an example in which a particular application, in this case a Network Operator-specific help application OperatorOfficeHelper, uses a P2P multimedia IMS communication service and a CS-speech service. To have meaningful communication, OperatorOfficeHelper must be installed in the terminals participating in the communication session. The application link is assigned the value OperatorOfficeHelper, and it is encoded with a tag tag. The communication service identifier is assigned the value of P2P multimedia, and the MCS specifier is assigned the value of IMS P2P multimedia and CS-speech. An example of this SIP INVITE structure containing an identifier of several communication services is shown in FIG. 10.

11 illustrates an example of the structure of a SIP MESSAGE message that can be sent in combination with CS-speech and P2P multimedia services. This example assumes that the SIP MESSAGE message is sent with the IMS messaging communication service. The SIP MESSAGE message passes the following parameters:

Communication Service Id = IMS Messaging

Application Reference = OperatorOfficeHelper

MCS-Qualifiers, CS-Speech, P2P Multimedia, IMS Messaging.

Specialists in the art should take into account that various modifications of the above described embodiments can be made without departing from the scope of the present invention. For example, other mechanisms may be used to express communication service identifiers, application references, and MCS specifiers in SIP messages. In particular, new SIP information elements (headers / parameters) can be defined for this purpose.

Claims (12)

1. A method for indicating communication services (and) of an IP multimedia subsystem to which a session initiation protocol message relates, the method comprising the steps of including one or more communication service identifiers in a session initiation protocol message, wherein the communication service identifier identifies one of multiple communication services, and include a link to the application in the message, the link to the application identifies the terminal application that should be used to process the identified communication services (and); wherein said one or more communication service identifiers are included in the session initiation protocol message as an attribute tag. 2. The method of claim 1, wherein said tag tag is included in one of the Contact, Accept-Contact or Reject-Contact headers of the session initiation protocol message. 3. The method according to any one of the preceding paragraphs, wherein said application link is included in the header of the session initiation protocol message as a tag of the attribute. 4. The method of claim 3, wherein said tag tag is included in one of the Contact, Accept-Contact or Reject-Contact headers of the session initiation protocol message. 5. The method of claim 1, wherein the plurality of application references are included in the initiation protocol message both as a tag of the attribute and as an a-line. 6. The method according to claim 5, in which the link to the application included as a tag tag identifies the main application, and the link to the application included in the a-line identifies the auxiliary application. 7. A method for controlling a subscriber terminal or an IMS network node, comprising the steps of identifying a corresponding communication service in the IMS stack based on the communication service identifier contained in the received session initiation protocol message and redirecting the message to this service, receiving the message in the identified a communication service and identify the corresponding application in the subscriber terminal or in the network IMS node based on the link to the application contained in the message of the session initiation protocol and redirect Post a message to this application. 8. A method for indicating communication services (and) of an IP multimedia subsystem to which a session initiation protocol message relates, the method comprising the steps of including one or more communication service identifiers in a session initiation protocol message, wherein the communication service identifier identifies one of multiple communication services, and include a link to the application in the message, the link to the application identifies the terminal application that should be used to process the identified communication services (and); wherein said reference to the application is included as an a-line, supplementing the m-line as part of the session description of the session initiation protocol message. 9. The method of claim 8, wherein said application link is included in the message header of the session initiation protocol as a feature tag. 10. The method of claim 9, wherein said tag tag is included in one of the Contact, Accept-Contact or Reject-Contact headers of the session initiation protocol message. 11. The method of claim 8, wherein a plurality of application references are included in the initiation protocol message both as an attribute tag and as an a-line. 12. The method according to claim 11, in which the link to the application included in the tag tag identifies the main application, and the link to the application included in the a-line identifies the supporting application.

Images