WO2009021453A1

WO2009021453A1 - Processing method, system and device for realizing the service communication of different types of messages

Info

Publication number: WO2009021453A1
Application number: PCT/CN2008/071955
Authority: WO
Inventors: Fang Chen
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2007-08-13
Filing date: 2008-08-12
Publication date: 2009-02-19
Also published as: CN101370172A; CN101370172B

Abstract

A processing method realizing service communication based on Session Initiation Protocol SIP of different types of messages includes: receiving the SIP message based on the first type from the calling user terminal UE transmitted over the called side service calling control function S-CSCF by the interworking function entity in the called network side, converting the SIP message based on the first type to the SIP message based on the second type, transmitting the message based on the second type to the called UE. The invention also provides the system and the device for the service communication of different types of messages.

Description

Processing method, system and device for realizing business communication with different types of messages

This application claims priority to Chinese Patent Application No. 200710142001.X, filed on August 13, 2007, entitled "Processing, Systems and Equipment for Different Types of Message Service Communication", all of which are The content is incorporated herein by reference.

Technical field

The present invention relates to the field of communications technologies, and in particular, to a method, system, and device for implementing service communication based on different types of messages of a Session Initiation Protocol (SIP). Background technique

IP Multimedia Subsystem (IMS, IP Multimedia Subsystem) is a subsystem supporting IP multimedia services proposed by the 3rd Generation Partnership Project Standardization Organization (3GPP) in Phase 5 (Release 5). Its core feature is the use of SIP protocol and The independence of access, so IMS is a multimedia control/call control platform on the IP domain, supporting both session and non-session multimedia services, providing a common service enabling platform for future multimedia applications. An important step in the evolution of the IP network (All IP Network) service provision system. With the rise and development of IMS-based access technologies, how to transform the existing traditional mobile terminal's message service into the service that the IMS terminal can provide, and reuse the existing mobile network short message service function entity and protocol as much as possible. Based on the IMS framework-based SIP based messaging services, such as the instant messaging (Outlook Messaging) defined in 3GPP and session based messaging, and the Open Mobile Alliance (OMA) defined Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (SIMPLE), as well as traditional messaging services such as Short Message Service (SMS) and Enhanced Short Message Service (EMS) defined by 3GPP Inter-service interoperability is also a common concern of operators and a goal of the 3GPP standardization organization.

Since the EMS defined by 3GPP belongs to an enhanced type of SMS, for the sake of simplicity, the short message in the traditional circuit/packet (CS/PS) domain described herein includes both SMS and EMS message services.

FIG. 1 is a network framework for implementing a traditional short message service using an IP terminal, which is proposed by the 3GPP, wherein a short message entity (SME), a short message service center (SM-SC), a short message mobile switching center gateway/short message interworking mobile switching center ( SMS-GMSC/SMS-IWMSC), home subscriber service The Home/Home Location Register (HSS/HLR) is a functional entity for the existing mobile network to implement Short Message Service (SMS) services. The SM-SC is used to store short messages; the SMS-GMSC is used to query the HSS/HLR for routing information when the terminal receives the short message; and the SMS-IWMSC is used for authentication when the terminal sends the short message. At present, the short message centers applied in the network are all three devices integrating SM-SC, SMS-GMSC and SMS-IWMSC, and the three functional entities are not implemented as separate physical devices, so in the following, If there is no special description, the short message center or the traditional short message center represents the three integrated devices of SM-SC, SMS-GMSC and SMS-IWMSC. The HSS/HLR is used to store user data information, including subscriber subscription data and routing information. The network framework shown in Figure 1 also includes a charging gateway function/billing data function (CGF/CDF) and an online charging system (OCS). The CGF/CDF is used to collect and process the offline billing information of the user, and then deliver the bill information. To the billing center, the OCS collects and processes the bill information of the user's online billing, and then passes it to the billing center.

In Figure 1, the IP Messaging Gateway (IP-Message-GW, hereinafter also referred to as IP-SM-GW in the figure) is a function of the Short Message/IMS messaging interworking Application Server. To realize the communication between the IP client and the GMSC/SMS-IWMSC, the IP network message protocol (that is, the IP-based communication protocol based on the IP terminal and the IP-Message-GW) and the existing WCDMA/GSM network are required. The message protocol (that is, the MAP protocol used between the IP-Message-GW and the GMSC/SMS-IWMSC, similar to the current MAP protocol, the MAP protocol between the MSC and the SGSN and the GMSC/SMS-IWMSC) Interworking including transport layer and service layer. The interworking of the transport layer is the interworking of the SIP message service of the mobile application part protocol (MAP) short message and the traditional MAP short message service implemented by the original IP-SM-GW; the service level interworking is implemented by the SMI AS. The interworking of the OMA-based representation of the extended session initiation protocol (SIMPLE IM) service and the traditional MAP short message service based on the SIP protocol. When a user who supports IP access applies the short message service, it must first register with the IP-SM-GW. The IP-SM-GW notifies the HSS that the user has registered and the IP-SM-GW address. The HSS saves the user status as an IP connection. Status (IP Connected) and store the IP-SM-GW address of the corresponding user registration.

In the existing specification, it is proposed that the IMS message service and the traditional short message service are intercommunicated based on the message at the transport level and at the service level. The IP message gateway (IP-SM-GW) aggregates the functions of the SMI AS as Short message between IMS domain and traditional circuit domain and packet domain (CS/PS domain) The interworking gateway implements interworking between the SIP-based message and the traditional short message, such as decapsulating the SIP message encapsulating the MAP short message and encapsulating the MAP short message in the SIP message body. At the same time, the communication between the SIP-based message and the traditional short message service layer is realized, such as converting the message format of the SIP-based message and the MAP short message, and the processed message is correspondingly forwarded, and at the same time, the IP message For the received message, the gateway can also route the corresponding domain of the message according to the operator's policy and the user's preference setting.

The interworking of the SIP-based message and the traditional short message at the transport level is shown in the processing flow chart 2 of the IP client registering to the IP-Message-GW.

Figure 2 shows the existing registration process for the interworking between SIP messages and traditional short messages at the transport layer.

Step 1: The user equipment (UE), that is, the IP client establishes an IP connection.

Step 2: After the IP connection is established, the user registers with the Service Call Control Function (S-CSCF) entity through the IMS registration process.

Step 3: During the registration process, the S-CSCF checks the initial filtering rules downloaded from the HSS. The initial filtering rules are already specified in the existing protocol and will not be described in detail here.

Step 4: After successfully completing the IMS registration, the S-CSCF notifies the IP message gateway user of the registration status based on the initial filtering rule.

Step 5: The IP message gateway returns a successful response to the S-CSCF.

Step 6. The IP Messaging Gateway sends a third-party registration request to the HSS.

Step 7: The HSS stores the received information, and returns an IP-IWF (IP interworking function) registration response to the IP message gateway, including providing service-related subscription data.

So far, the UE has registered to the IP Messaging Gateway, and the IP Messaging Gateway has obtained service-related subscription data from the HSS.

According to the above registration process, the process of interworking between the traditional short message service and the SIP-based message service service level in the IMS-MO (message start of the IMS domain) is as shown in FIG. 3.

Step 1: According to the IMS registration procedure, the UE is registered in the S-CSCF. Here, for the sake of simplicity, other network entities in the IMS core, such as the I-CSCF and the P-CSCF, are not displayed in the figure; The registration process, the UE has registered to the IP message gateway.

Step 2: The UE sends the SIP-based message to the S-CSCF through the IMS domain, in the message body. A communication service identity (CSID) is used to identify whether the user has subscribed to the message interworking service.

Step 3: The S-CSCF performs an initial filtering rule check on the received SIP-based message, where the check includes that the feature tag of the SIP message is a pure IMS message "+g.oma.sip-im" , or the encapsulated IMS message "+g.3g p.smsip,,, or check whether the calling user has subscribed to the interworking service at the service level, or check whether the information identifier of the CSID carried in the SIP message is an interworking service at the service level. .

Step 4: When the feature tag carried by the SIP message is "+g.3gpp.smsip", that is, the encapsulated IMS message, the subsequent processing continues according to the processing of the IMS message encapsulated in the prior art; in other three cases, S- The CSCF4 BA SIP message is routed to the IP Messaging Gateway of the calling network.

Step 5: The IP message gateway of the calling network determines whether service level interworking is required according to the calling user preference and the operator policy. There are three possible situations: Interworking at the service level, processing by default, no service required. Interoperability at the level.

If interworking at the service level is required, the IP message gateway authenticates the interworking service. If the authentication succeeds, the IP message gateway of the calling network converts the SIP-based message into a traditional short message format, and forwards the message after the conversion format. To the traditional short message system, the subsequent forwarding process is completed by the traditional short message system.

If the IP address gateway of the calling network needs to be processed by default, the IP address gateway of the calling network selects the network of the called domain to be delivered according to the identifier of the called user. If the called user is in the form of a TEL-URI, the IP message gateway of the calling network can have the configured number segment information or ENUM (Telephone).

Number Mapping working group ) The result of the query is whether the message is sent through IMSi or through the CS/PS domain.

If the delivered domain is a CS/PS domain, the IP message gateway of the calling network authenticates the interworking service. If the authentication succeeds, the IP message gateway of the calling network converts the SIP-based message into a traditional short message format. Forwarding the converted format message to the traditional short message system, the traditional short message system completes the subsequent forwarding process. If the authentication is not successful, the IP message gateway of the calling network returns a failure report to the S-CSCF of the calling network; The delivered domain is selected as the IMS domain, and the message is forwarded to the called IMS network according to the existing IMS specification. If the service level interworking is not required, the IP message gateway selects the IMS domain according to the self-configured number segment information or the ENUM query result, and forwards the message to the called IMS network according to the existing IMS specification, if the IP message gateway cannot select the IMS. The domain returns a failure report to the S-CSCF of the calling network. That is to say, if the service level interworking is not required, the IP message gateway cannot select the CS/PS domain, and only the IMS domain can send the message. If the IMS domain selection is unsuccessful, the failure report is returned.

Step 6~7, the IP message gateway sends the converted SIP-based message to the UE via the IMS network, where the response message can be directly returned after the IP message gateway completes the interworking service, or can wait in the IP message gateway. The report sent by the called user returns (the delivery report) and returns. Summary of the invention

The embodiments of the present invention provide a method, a system, and a device for processing a service communication based on different types of messages, so as to implement interworking between different types of SIP messages.

The technical solution of the embodiment of the present invention includes:

A method for processing different types of message service communication based on Session Initiation Protocol SIP, the method comprising:

The interworking function entity in the called network side receives the first type of SIP message from the calling user terminal UE transmitted by the called side service call control function S-CSCF; converting the SIP message based on the first type into The second type of SIP message is transmitted to the called UE based on the second type of SIP message.

An interworking functional entity, including:

a receiving unit, configured to receive a first type of SIP message from the called side S-CSCF, and a message converting unit, configured to convert the first type of SIP message into a second type based SIP message;

And sending, by the second type, the SIP message to the called UE.

A SIP-based system for communicating different types of message services, including a primary called UE, an S-CSCF in a primary called network, where the called side S-CSCF is configured to receive a second from the calling user terminal UE A type of SIP message, the system further includes:

An interworking function entity located in the called network side, for receiving the base from the called side S-CSCF The first type of SIP message converts the first type of SIP message into a second type based SIP message, and transmits the second type based SIP message to the called UE.

By applying the present invention, the interworking function format is converted by the interworking function entity in the called network, so that communication between different types of messages based on SIP is realized. DRAWINGS

1 is a schematic diagram of a network framework for implementing a conventional short message service using an IP terminal proposed by the existing 3GPP;

2 is a schematic diagram of a registration process of an existing SIP-based message and a conventional short message interworking at a transport layer;

FIG. 3 is a schematic diagram of an existing IMS-MO process for interworking between a SIP message and a legacy short message at a service service level;

4 is a schematic flowchart of a SIP-based different type of message implementation service communication processing method according to Embodiment 1 of the present invention;

Figure 5 is a specific embodiment of the first embodiment;

Figure 6 is another embodiment of the first embodiment;

Figure 7 is a specific embodiment of the second embodiment.

detailed description

The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

Embodiment 1:

The SIP-based different type of message implementation processing method for the service communication includes: the called side S-CSCF receives the SIP message based on the first type from the calling user terminal UE, and the first type is based on the first type The SIP message is transmitted to the interworking function entity in the called network side; the interworking function entity in the called network side converts the SIP message based on the first type into a SIP message based on the second type, and the second message is based on the second A type of SIP message is transmitted to the called UE.

The interworking function entity located in the called network side can determine whether the service level interworking needs to be performed according to the obtained called user information (such as the called terminal capability/called user preference) or the operator policy, and the interworking service is checked. The function of the conversion of the message format, which may be located in an entity in the existing network, such as an IP message gateway, an SMI AS, or the like, or a newly added independent network. Body, or a new functional module on an existing network entity. It provides services to users through third-party registration of users.

After the first-type SIP message is sent to the interworking function entity in the network side of the called network, the S-CSCF of the called side may further include: Determining, according to an initial filtering rule, whether the SIP message based on the first type needs to be transmitted to an interworking function entity in the called network side, and if so, performing a transfer operation; otherwise, directly according to the prior art The SIP message is transmitted to the called UE.

Before the interworking function entity in the network side of the called network converts the SIP message based on the first type into the SIP message based on the second type, the method further includes: determining whether service level interworking is required, and if yes, performing the The UE is called to perform interworking service authentication. After the service authentication succeeds, the SIP message based on the first type is converted into a SIP message based on the second type.

After the second type of the SIP message is transmitted to the called UE, the method further includes: the called UE returns the response information to the calling UE.

FIG. 4 is a schematic flow chart showing a SIP-based different type of message implementation service communication processing method according to Embodiment 1 of the present invention. For the sake of simplicity, only the network entities related to the present embodiment are provided in the figure, and other network entities, such as the IMS core network entity S-CSCF, P-CSCF, etc., are associated with the prior art, and are not used again. Repeat the narrative.

Step 1: The calling IMS user constructs a message based on the first type of SIP, and sends a message to the interworking function (IWF) entity through the IMS Core, where the interworking function entity is located in the IMS network on the called side.

Step 2: The interworking function entity performs the interworking service processing, specifically: the interworking function entity has the obtained called user information, such as the capability of the called terminal and/or the called user preference, or the operator policy, etc., determining whether The service level interworking function is required. Therefore, the interworking function entity of the called side network can obtain related information through the capability information carried by the user when the third party is registered, or the information configured by the user through the Ut interface, to determine whether the service needs to be performed. Level of interoperability. If service level interworking is required, the interworking function entity also performs authentication of the interworking service. If the authentication succeeds, the interworking function entity can convert the message format, that is, the first type of SIP message is converted into the second type based. The SIP message, if the authentication is not successful, returns an error response to the IMS user on the calling side. Step 3: The interworking function entity forwards the formatted SIP message to the called IMS user based on the second type of SIP message through the IMS core.

Steps 4 ~ 5, the called IMS user receives the formatted SIP message and returns a response to the calling IMS user.

Referring to Figure 5, it is a specific embodiment based on Embodiment 1. In this embodiment, the main called

An interworking function entity is configured on the network side where the UE is located, and the interworking function entity is implemented by an IP message gateway. The calling UE is an IMS registered user supporting the MAP protocol stack, and sends a SIP message encapsulating the MAP short message to the called UE (such as the SIMPLE IM user) that does not support the MAP protocol stack. Here, the entity in the calling network is recorded as "entity name #1", and the entity in the called network is recorded as "entity name #2". For example, the calling UE is recorded as UE#1, and the called UE is recorded. For UE#2, the S-CSCF in the calling network is denoted as S-CSCF#1, the S-CSCF in the called network is denoted as S-CSCF#2, and so on.

Steps 1 to 7 are similar to steps 1 to 7 in FIG. 3, except that the IP-message gateway on the calling side, ie, IP-SM-GW#1, after receiving the SIP message from UE#1, confirms the The message is a SIP message encapsulating the MAP message, but the calling user does not subscribe to any interworking service, including the interworking of the transport layer and/or the service layer, and the called terminal identifier carried according to the message can be routed in the called IMS network, and thus the IP -SM-GW#1 returns the encapsulated SIP message to S-CSCF#1, and the SIP message of the encapsulated MAP message is routed by S-CSCF#1 to S-CSCF#2 through the IMS core.

Step 8 ~ 9, S-CSCF#2 checks the initial filtering rule of the received SIP message, including whether the SIP message carries the feature tag of "+g.3gpp.smsip,", etc. The result of the initial filtering rule is checked. If the 81? message carries "+8.3.811^^ 6 ^^ 1 8 , it identifies that the SIP message body carries the MAP short message, and the S-CSCF #2 routes the encapsulated SIP message to the called IP message gateway. IP-SM-GW#2.

Step 10: After receiving the SIP message encapsulating the MAP short message, the IP-SM-GW#2 determines whether the service level interworking needs to be performed according to the obtained called user information or the operator's policy. The called user information includes the ability of the called terminal, the service subscription of the called user, or the called user preference.

If service level interworking is required, IP-SM-GW#2 authenticates the interworking service of UE#2. After the authentication succeeds, the message format is converted, that is, the encapsulated SIP message is decapsulated to obtain the MAP short message. , then convert the MAP short message into a pure SIP message format, in the case of authentication failure Then, the error response is returned to the UE#1; if the service level interworking is not required, the message is sent to the called user terminal through the IMS core.

Steps 11 to 12, after IP-SM-GW#2 completes the processing of the interworking service, the translated pure SIP message is delivered to UE#2 through the IMS core.

Step 13-19, UE#2 returns a message successfully received by IP-SM-GW#2. 200 OK to

UE#1.

Another possibility is that no interworking function entities (such as IP-SM-GW and SMI AS) are configured in the calling network. At this time, according to the IMS message processing method of the prior art (TS 23.228), S-CSCF# 1 The SIP message encapsulating the MAP short message can be directly routed to the S-CSCF#2 through the IMS core. After the S-CSCF#2 receives the SIP message encapsulating the MAP message, the subsequent processing is the same as the steps 8 to 19 in FIG. 5, and details are not described herein.

So far, communication between the calling UE supporting the MAP protocol stack and the called UE (such as the SIMPLE IM user) that does not support the MAP protocol stack is implemented.

Referring to Figure 6, it is another embodiment based on Embodiment 1. In this embodiment, the interworking function entity is configured on the network side where the primary called UE is located, and the interworking function entity is implemented by the IP message gateway. The calling UE sends a SIMPLE IM to the called IMS network, and the called UE is not an IM user, and prefers to receive SIP messages in the form of MAP signaling. Here, the entity in the calling network is recorded as "Entity Name #1", and the entity in the called network is recorded as "Entity Name #2". For example, the calling UE is recorded as UE#1, and the called UE is recorded. For UE#2.

Steps 1 to 7 are similar to steps 1 to 7 in FIG. 3, except that the IP-message gateway on the calling side, that is, IP-SM-GW#1, after receiving the SIMPLE IM message from UE#1, confirms The user preference of UE#1 and the configuration of the operator policy are not inclined to communicate at the service level, and the called terminal identifier carried according to the message can be routed in the called IMS network, so IP-SM-GW#1 returns to SIMPLE IM. The message is sent to S-CSCF#1, which is routed by S-CSCF#1 through the IMS core to S-CSCF#2.

Steps 8-9, S-CSCF#2 checks the initial filtering rules of the received SIP message, including whether the SIP message carries the feature tag of "+g.oma.sip-im," or whether it carries the service layer. Interworking service identifier CSID, etc. Based on the result of the initial filtering rule, if the SIP message carries the feature tag of "+g.oma.sip-im," or carries the interworking service identifier indicating that the service level needs to be performed The CSID, S-CSCF#2 routes the received SIMPLE IM message to the called IP message gateway, IP-SM-GW#2.

Step 10: After receiving the SIMPLE IM message, the IP-SM-GW#2 determines whether the service level interworking needs to be performed according to the obtained called user information or the operator's policy. The called user information includes the capabilities of the called terminal, the service subscription of the called user, or the called user preference.

If service level interworking is required, IP-SM-GW#2 authenticates the interworking service of UE#2, and after the authentication succeeds, the message format is converted, that is, the SIMPLE IM message is converted into a MAP short message and encapsulated in the SIP message. In the case of the authentication failure, the error response is returned to the UE#1; if the service level interworking is not required, the message is delivered to the called user terminal through the IMS core.

Steps 11 to 12, after the IP-SM-GW#2 completes the processing of the interworking service, the SIP message encapsulating the MAP short message is delivered to the UE#2 through the IMS core.

In step 13-19, UE#2 returns a response 200 OK of the message successfully received by UE-to-UE#1 through IP-SM-GW#2.

Another possibility is that no interworking function entities (such as IP-SM-GW and SMI AS) are configured in the calling network. At this time, according to the IMS message processing method of the prior art (TS 23.228), S-CSCF# 1 The SIMPLE IM message can be directly routed to S-CSCF#2 through the IMS core. After the S-CSCF#2 receives the SIMPLE IM message, its subsequent processing is completely the same as steps 8 to 19 in Figure 6, and will not be described again.

So far, communication between the calling UE (such as SIMPLE IM user) that does not support the MAP protocol stack and the called UE supporting the MAP protocol stack is implemented.

It can be seen from the foregoing embodiment that, for the IMS registered user that supports the MAP protocol stack, the calling UE sends a SIP message encapsulating the MAP short message to an IMS user (such as a SIMPLE IM user) that does not support the MAP protocol stack. Alternatively, the calling UE sends a SIMPLE IM to the called IMS network, and the called UE is not an IM user, and prefers to receive the SIP message in the form of MAP signaling. If the calling UE is located on the calling network side, the interworking function is set. Entity; the interworking function entity in the calling network side receives the first type of SIP message from the autonomous calling side S-CSCF, and determines that the calling user does not subscribe to the interworking service or does not need to perform service level interworking, The first type of SIP message is transmitted to the calling side S-CSCF; at this time, the calling side S-CSCF transmits the first type based SIP message to the called side S-CSCF. If the calling party is located on the calling network side, the interworking function is not set. After receiving the SIP message based on the first type from the calling UE, the calling side S-CSCF may directly transmit the SIP message based on the first type to the called party according to an existing protocol. Side S-CSCF. The SIP message based on the first type is a SIP message encapsulating the MAP; the SIP message based on the second type is a pure SIP message; or the SIP message based on the first type is a pure SIP message, and the The second type of SIP message is a SIP message encapsulating the MAP; the pure SIP message includes a SIMPLE IM message. Based on the method of Embodiment 1, the embodiment of the present invention further provides a system for different types of message service communication based on SIP, including a primary called UE, an S-CSCF in a primary called network, where the called side The S-CSCF is configured to receive the first type of SIP message from the calling user terminal UE, where the system further includes:

An interworking function entity located in the called network side, configured to receive a first type of SIP message from the called side S-CSCF, and convert the first type of SIP message into a second type based

The SIP message transmits the SIP message based on the second type to the called UE.

And the interworking function entity in the called network side is further configured to determine whether service level interworking is required before converting the first type of SIP message to the second type of SIP message, and if yes, The called UE performs interworking service authentication, and after the service authentication succeeds, the SIP message based on the first type is converted into a SIP message based on the second type.

The system further includes: an interworking function entity in the calling network side, configured to receive the first type of SIP message from the calling side S-CSCF, and determine that the calling user does not subscribe to the interworking service or does not need to perform When the service level is interconnected, the first type of SIP message is transmitted to the calling side S-CSCF;

The calling side S-CSCF is configured to transmit the SIP message based on the first type to the called side S-CSCF.

After receiving the SIP message based on the second type, the called UE is further configured to return response information to the calling UE.

The interworking function entity in the called network side is an IP message gateway, or an entity SMI AS that communicates with the message, or a newly added network entity, or a newly added function module on the existing network entity. Based on the method of Embodiment 1, the embodiment of the present invention further provides an interworking function entity, including:

And sending, by the second type, the SIP message to the called UE.

The interworking function entity further includes: an interworking detecting unit and an interworking authorization unit. The interworking detection unit is configured to: after the interworking of the service layer is required, the notification that the service level is required to be communicated is sent; the interworking authorization unit is configured to perform the service level interworking notification according to the received requirement, and perform the interworking service check on the called UE. After the service authentication succeeds, the message conversion unit is notified to perform the conversion. Implementation 2:

The method for processing the service communication of the different types of messages based on the SIP provided by the embodiment includes: the calling UE sends a SIP message based on the first type to the network side; the SIP message includes the UE that needs to be supported by the UE. An identifier of a protocol stack required for a type of SIP message; after the calling UE receives response information from a protocol stack required by the called UE on the network side that does not support the first type of SIP message, reconstructing the called UE can The supported second type of SIP message is transmitted, and the reconstructed message is sent again.

The response information of the protocol stack required by the called UE that does not support the first type of SIP message is from the S-CSCF of the called network side; the S-CSCF of the called network side returns the The process of responding to the information includes: after the called network side S-CSCF receives a SIP message from the calling UE that includes an identifier of a protocol stack required for the called UE to support the first type of SIP message, acquiring the The capability information of the UE is determined, according to the capability information of the called UE, after determining that the called UE does not support the protocol stack required by the first type of SIP message, and returning the response information to the calling UE.

If the calling party on the network side of the calling UE is provided with an interworking function entity, the called side

The process of receiving, by the S-CSCF, the first type of SIP message from the calling user terminal UE includes: after the interworking function entity in the calling network side receives the first type of SIP message from the autonomous calling side S-CSCF, When it is determined that the calling user does not subscribe to the interworking service or does not need to perform service level interworking, Transmitting the SIP message based on the first type to the calling side S-CSCF; the calling side S-CSCF transmitting the SIP message based on the first type to the called side S-CSCF.

If the interworking function entity is not set on the calling network side where the calling UE is located, the process in which the called side S-CSCF receives the first type of SIP message from the calling user terminal UE includes: the calling side S- After receiving the SIP message based on the first type from the calling UE, the CSCF transmits the SIP message based on the first type to the called side S-CSCF.

The calling UE is a MAP-capable UE, and the called UE is a UE that supports only pure SIP. The calling UE that is required to be called by the calling UE to support the first type of SIP message is included in the first type of SIP message. The identifier of the required protocol stack is an identifier that requires the called UE to support the MAP protocol stack; the second type-based SIP message reconstructed by the calling UE is a pure SIP message.

With this embodiment, in the case that the called network does not support the message interworking entity or the function module, the SIP message and the pure SIP message (such as OMA SIMPLE IM) for encapsulating the MAP short message can be implemented without any modification to the existing IMS core. Communication. Specifically, the IMS core network entity (such as the S-CSCF) determines whether the called terminal has the capability according to the capability of the called terminal (such as the MAP protocol stack, etc.) required by the calling user carried in the SIP message body. If not, the network entity returns an error response to the calling user and carries the capability information of the called terminal, so that the calling user can send a SIP-based message adapted to the called terminal capability according to the information.

Referring to Figure 7, it is a specific embodiment based on Embodiment 2. In this embodiment, the calling UE is an IMS registered user supporting the MAP protocol stack, and sends a SIP message encapsulating the MAP short message to the called UE (such as the SIMPLE IM user) that does not support the MAP protocol stack. Here, the entity in the calling network is recorded as "entity name #1", and the entity in the called network is recorded as "entity name #2". For example, the calling UE is recorded as UE#1, and the called UE is recorded. For UE#2.

Steps 1-7 are similar to steps 1-7 in FIG. 3, except that: UE#1 encapsulates the MAP short message in the SIP message body, and carries the required UE in the SIP message header, such as "require". #2 supports the identifier of the MAP protocol stack, and forwards the SIP message to the calling IP message gateway, IP-SM-GW#1, through the IMS core. After receiving the SIP message from UE#1, IP-SM-GW#1 confirms that the message is a SIP message encapsulating the MAP short message, but the calling user does not sign any interworking service, including the transport layer and/or the service layer. Interworking, and the called terminal identifier carried according to the message can be in the called IMS The network routes, and IP-SM-GW#1 returns the encapsulated SIP message to S-CSCF#1, which routes the SIP message to S-CSCF#2 through the IMS core.

After receiving the encapsulated SIP message, the S-CSCF#2 detects that the message header of the message carries the identifier of the called party supporting the MAP protocol, and is obtained according to the third party registration. The called terminal capability information learns that the called terminal does not support the MAP protocol stack. Therefore, it decides to reject the encapsulated SIP message, and constructs an error response, which carries the failure reason and the capability information of the called terminal.

Steps 10 ~ 12, S-CSCF#2 returns an error response to UE#1.

Step 13: After receiving the error response, UE#1 constructs a SIP message that does not encapsulate the MAP short message and sends it to the called terminal according to the called terminal capability information carried in the response.

Another possibility is that no interworking function entities (such as IP-SM-GW and SMI AS) are configured in the calling network. At this time, according to the IMS message processing method of the prior art (TS 23.228), S-CSCF# 1 The SIP message encapsulating the MAP short message can be directly routed to the S-CSCF#2 through the IMS core. After the S-CSCF#2 receives the SIP message encapsulating the MAP message, the subsequent processing is the same as the steps 8 to 13 in FIG. 7, and details are not described herein.

The embodiment of the present invention further provides a UE, including: a sending unit, configured to send, according to a first type of SIP message, a network message to the network side; An identifier of a protocol stack required for the first type of SIP message; sending, according to the received notification, a SIP message based on the second type;

a receiving unit, configured to receive, from the network side, the response information of the protocol stack required by the called UE that does not support the first type of SIP message, to notify the constructing unit;

And a constructing unit, configured to reconstruct a second type-based SIP message that the called UE can support, and notify the sending unit to resend.

The method for processing different types of SIP message service communication provided by the second embodiment of the present invention can implement service interworking between different types of SIP messages, such as when the called network does not support the message interworking entity or the function module. Communication between SIP messages encapsulating MAP short messages and pure SIP messages.

The above description is only the preferred embodiment of the present invention and is not intended to limit the scope of the present invention. Any modifications, equivalents, improvements, etc. made within the spirit and scope of the invention are intended to be included within the scope of the invention.

Claims

Rights request

A method for processing a service communication based on different types of messages of a session initiation protocol SIP, wherein the method comprises:

The interworking function entity in the called network side receives the first type of SIP message from the calling user equipment UE transmitted by the called side service call control function S-CSCF; converting the SIP message based on the first type into The second type of SIP message is transmitted to the called UE based on the second type of SIP message.

The method according to claim 1, wherein the calling party is provided with an interworking function entity on the network side of the calling party;

The process in which the called side S-CSCF receives the first type of SIP message from the calling UE includes:

After the interworking function entity in the calling network side receives the first type of SIP message from the calling side S-CSCF, it is determined that the calling user does not have the subscription service or does not need to perform service level interworking. Transmitting, by the first type of SIP message, the calling side S-CSCF;

The calling side S-CSCF transmits the SIP message based on the first type to the called side

S-CSCF.

The method according to claim 1, wherein, after the called side S-CSCF receives the SIP message based on the first type from the calling UE, the SIP message based on the first type is sent to Before the interworking function entity in the called network side, the method further includes:

According to the initial filtering rule, the called side S-CSCF determines whether the SIP message based on the first type needs to be transmitted to the interworking function entity in the called network side, and if so, performs the transmitting operation; otherwise, according to the existing The technology directly transmits the SIP message based on the first type to the called UE.

The method according to claim 1, wherein before the interworking function entity in the called network side converts the SIP message based on the first type into the SIP message based on the second type, the method further includes:

Determining whether service level interworking is required, and if yes, performing interworking service authentication on the called UE, and after the service authentication succeeds, converting the first type of SIP message into a second type based SIP message .

5. A method according to any one of claims 1 to 4, characterized in that The SIP message based on the first type is a SIP message encapsulating a mobile application part protocol MAP; the SIP message based on the second type is a pure SIP message; or

The SIP message based on the first type is a pure SIP message, and the SIP message based on the second type is a SIP message encapsulating the MAP;

The pure SIP message includes an instant message SIMPLE IM representing an extended session initiation protocol.

The method according to claim 3, wherein, when the SIP message based on the first type is a SIP message encapsulating MAP, and the SIP message based on the second type is a pure SIP message, the The initial filtering rule determines whether the process of transmitting the first type of SIP message to the interworking function entity in the called network side is:

Determining whether the capability tag of the encapsulated IMS message carries the feature tag in the first type of SIP message, and if yes, determining that the SIP message based on the first type needs to be transmitted to the interworking function in the called network side Entity

When the SIP message based on the first type is a pure SIP message, and the SIP message based on the second type is a SIP message encapsulating the MAP, the determining, according to an initial filtering rule, whether the SIP based on the first type needs to be used The process of transmitting the message to the interworking function entity in the network side of the called network includes: determining whether the SIP message of the first type carries the feature tag of the pure IMS message capability feature, or carries the communication service indicating the service level interworking The CSID is identified, and if so, it is determined that the first type of SIP message needs to be transmitted to the interworking function entity in the called network side.

The method according to claim 4, wherein the determining whether the service level interworking needs to be performed comprises:

The interworking function entity in the called network side determines whether service level interworking needs to be performed according to the capability of the called UE, the service subscription of the called user, the preference of the called user, or the policy of the operator.

The method according to any one of claims 1 to 4, wherein the interworking function entity in the called network side is located in an IP message gateway, or in an entity SMI AS in which the message interworks, or is an independent network. An entity, or a functional module on an existing network entity.

9. An interworking functional entity, comprising:

a receiving unit, configured to receive a first type-based SIP message from the called side S-CSCF; and a message converting unit, configured to convert the first type-based SIP message to be based on the second type SIP message;

And sending, by the second type, the SIP message to the called UE.

The interworking function entity according to claim 9, wherein the interworking function entity further comprises:

The interworking detection unit is configured to send a port that needs to communicate at the service level after the interworking of the service level is required;

The interworking authorization unit is configured to perform the interworking service authentication on the called UE according to the received notification of the service level interworking, and after the service authentication succeeds, notify the message conversion unit to perform the conversion.

11. A SIP-based system for different types of messages to implement service communication, including a calling party

The UE, the S-CSCF in the primary and the called network, where the called side S-CSCF is configured to receive the first type of SIP message from the calling user terminal UE, wherein the system further includes:

An interworking function entity located in the called network side, configured to receive a SIP message based on the first type from the called side S-CSCF, and convert the SIP message based on the first type into a SIP message based on the second type, Transmitting the second type based SIP message to the called UE.

The system according to claim 11, wherein the interworking function entity in the called network side further converts the SIP message based on the first type into a SIP message based on the second type, After the service level interworking is determined, the called UE is authenticated for the interworking service, and after the service authentication is successful, the SIP message based on the first type is converted into the SIP message based on the second type.

The system according to claim 11 or 12, wherein the system further comprises: an interworking function entity located in the calling network side, configured to receive the first type based on the calling side S-CSCF After the SIP message is sent, the first type of SIP message is transmitted to the calling side S-CSCF when the calling user does not need to sign the interworking service or does not need to perform service level interworking;

The system according to claim 11, wherein the interworking function entity in the called network side is located in an IP message gateway, or in an entity SMI AS where the message is interworked, or is an independent network entity, or is present There are functional modules on the network entity.