CN111294317A

CN111294317A - Method and device for RCS to support multi-protocol access and electronic equipment

Info

Publication number: CN111294317A
Application number: CN201811496627.5A
Authority: CN
Inventors: 吴浩
Original assignee: Beijing Feinno Communication Technology Co Ltd
Current assignee: Beijing Feinno Communication Technology Co Ltd
Priority date: 2018-12-07
Filing date: 2018-12-07
Publication date: 2020-06-16
Anticipated expiration: 2038-12-07
Also published as: CN111294317B

Abstract

The invention discloses a method, a device and electronic equipment for a Rich Communication Suite (RCS) to support multi-protocol access, wherein a protocol adaptation agent is deployed in the RCS, and the method comprises the following steps: the protocol adaptation agent receives an access request sent by user equipment through a first protocol, converts the access request into a Remote Procedure Call (RPC) registration message according to a preset protocol conversion rule, and the first protocol comprises the following steps: session initiation protocol SIP, protocol message queue telemetry transmission MQTT protocol, hypertext transmission protocol HTTP, and protocol adaptation agent sending RPC registration message to IMS through PRC protocol; and the IMS correspondingly allocates a message queue for storing the communication message to the user equipment according to the received RPC registration message to finish the access. The embodiment of the invention supports the terminal access of various protocols, reduces the flow and resource consumption and improves the system performance.

Description

Method and device for RCS to support multi-protocol access and electronic equipment

Technical Field

The invention relates to the technical field of communication, in particular to a method and a device for supporting multi-protocol access by an RCS (remote control system) and electronic equipment.

Background

The Rich Communication Suite (RCS) technology is a converged Communication integrating short message service, Multimedia service, video, chat, etc., and the RCS uses an IP (Internet Protocol) Multimedia Subsystem (IMS) of a general and standardized network architecture providing Multimedia services based on an IP network to transmit signaling and media streams to mobile and fixed user equipments. IMS includes session control, connection control and application service frameworks as well as user and service data. It enables operators to offer multimedia services based on and built upon internet applications, services and protocols.

At present, the standard RCS is transmitted based on a session Initiation protocol SIP (session Initiation protocol), but the SIP is a text-type protocol, the data carrier is complex, the data packet is too large, the processing power consumption at the service end is large, and the data interworking cost is too high when the corresponding standard SIP end performs service interworking with the internet terminal.

Disclosure of Invention

The invention provides a method, a device and electronic equipment for RCS to support multi-protocol access, which provide high-reliability, high-concurrency and multi-protocol access and service by serving a plurality of protocol adaptations for an outer access protocol adaptation agent, and solve the technical problems of large data packet and high communication cost caused by the transmission of a standard RCS based on an SIP protocol.

According to an aspect of the present application, there is provided a method for a rich communication suite, RCS, to support multi-protocol access, a protocol adaptation agent being deployed in the RCS, the method comprising:

the method comprises the following steps that a protocol adaptation agent receives an access request sent by user equipment through a first protocol, and converts the access request into a Remote Procedure Call (RPC) registration message according to a preset protocol conversion rule, wherein the first protocol comprises the following steps: session initiation protocol SIP, message queue telemetry transmission MQTT protocol and hypertext transfer protocol HTTP;

the protocol adaptation agent sends the RPC registration message to an IP multimedia subsystem SIMS of the RCS through a PRC protocol;

and the SIMS correspondingly allocates a message queue for storing the communication message to the user equipment according to the received RPC registration message to finish access.

According to another aspect of the present application, there is provided an apparatus for supporting multi-protocol access by a rich communication suite RCS, where a protocol adaptation agent is deployed in the RCS, the apparatus including:

the protocol conversion module is used for receiving an access request sent by user equipment through a first protocol by using a protocol adaptation agent, and converting the access request into a Remote Procedure Call (RPC) registration message according to a preset protocol conversion rule, wherein the first protocol comprises: session initiation protocol SIP, message queue telemetry transmission MQTT protocol and hypertext transfer protocol HTTP;

the sending module is used for sending the RPC registration message to an IP multimedia subsystem IMS of the RCS by utilizing a protocol adaptation agent through a PRC protocol;

and the implementation module is used for correspondingly allocating a message queue for storing the communication message to the user equipment by utilizing the IMS according to the received RPC registration message to finish the access.

According to yet another aspect of the present application, there is provided an electronic device including: the system comprises a memory and a processor, wherein the memory and the processor are connected through an internal bus in a communication mode, the memory stores program instructions capable of being executed by the processor, and the program instructions are capable of realizing the method in one aspect of the application when being executed by the processor.

The method and the device for supporting multi-protocol access by the rich communication suite RCS utilize a protocol adaptation agent to receive an access request sent by user equipment through a first protocol, convert the access request into a Remote Procedure Call (RPC) registration message according to a preset protocol conversion rule, send the RPC registration message to an IP Multimedia Subsystem (IMS) of the RCS through a PRC protocol by the protocol adaptation agent, and correspondingly allocate a message queue for storing the communication message for the user equipment according to the received RPC registration message by utilizing the IMS to finish access. Therefore, standard RCS service is modified, a protocol adaptation agent is added on the outer layer, RPC protocol is adopted inside the service, and protocol conversion is completed by the protocol adaptation agent, so that a protocol carrier of the RCS is changed into a light and convenient RPC protocol, and flow and resource consumption are reduced. And moreover, multiple protocols are supported for access, the flexible access capability of the RCS is enhanced, and the system performance is improved.

Drawings

Fig. 1 is a flowchart of a method for supporting multi-protocol access by an RCS according to an embodiment of the present invention;

FIG. 2 is an architecture diagram of an RCS system in accordance with one embodiment of the present invention;

fig. 3 is a block diagram of an apparatus for supporting multi-protocol access by an RCS according to an embodiment of the present invention;

fig. 4 is a schematic structural diagram of an electronic device according to an embodiment of the present invention.

Detailed Description

In order to make the aforementioned objects, features and advantages of the present invention comprehensible, embodiments accompanied with figures are described in further detail below. It is to be understood that the embodiments described are only a few embodiments of the present invention, and not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

The design concept of the invention is as follows: aiming at the technical problems that a standard RCS system is based on SIP protocol transmission, service and basic function coupling is too complex, a service data transmission protocol is too bulky and high-reliability and high-concurrency service is difficult to realize, the embodiment of the invention is realized by combining an Internet instant messaging system based on MQTT or a proprietary protocol, the protocol carrier is small, the protocol is transmitted by a binary protocol, and the invention has the advantage of safety.

Fig. 1 is a flowchart of a method for supporting multi-protocol access by an RCS according to an embodiment of the present invention, and referring to fig. 1, the method for supporting multi-protocol access by an RCS according to the embodiment deploys a protocol adaptation agent in the RCS, and the method includes the following steps:

step S101, a protocol adaptation agent receives an access request sent by user equipment through a first protocol, and converts the access request into a Remote Procedure Call (RPC) registration message according to a preset protocol conversion rule;

the first protocol here includes: session initiation protocol SIP, message queue telemetry transmission MQTT protocol and hypertext transfer protocol HTTP;

step S102, the protocol adaptation agent sends the RPC registration message to an IP multimedia subsystem IMS of the RCS through a PRC protocol;

and step S103, the IMS correspondingly allocates a message queue for storing the communication message to the user equipment according to the received RPC registration message to finish access.

As shown in fig. 1, in the method for supporting multi-protocol access by an RCS of this embodiment, a protocol adaptation proxy is deployed in an RCS system, the protocol adaptation proxy is used to receive an access request sent by a user equipment through a first protocol, the access request is converted into a Remote Procedure Call (RPC) registration message according to a preset protocol conversion rule, and the RPC registration message is sent to an IMS, and the IMS creates a corresponding message queue for the user equipment according to the received RPC registration message to implement access. Inside the RCS, the protocol adaptation agent and the IMS are realized by Remote Procedure Call (RPC) protocol, the RPC protocol is light and convenient, the flow and resource consumption are reduced, and the system performance is improved.

The method for the RCS supporting the multi-protocol access in this embodiment is implemented based on the RCS system, that is, in this embodiment, a local improvement is made on the basis of the RCS service in the prior art, and excellent service data of the RCS system architecture itself is retained, for example, CSCF (Call Session Control Function) performs dynamic routing logic, SBC (Session Border Controllers) is responsible for service access, and IM-AS (instant messaging-Application Server) implements message service processing, so that service routing processing capabilities of the RCS system in aspects of gray scale release, service load, flexible service access, and the like are retained.

Here, the CSCF network element is responsible for controlling functions such as registration and authentication, session control, route management, network management, and charging, which are related to user service information. AS (Application Server), which is an Application layer device located at the uppermost layer in the SIMS system. The AS network element and the CSCF interact through a standard SIP protocol, and then triggering and execution of various network services are realized.

One of the important points of the embodiments of the present invention is to construct a protocol adaptation agent at the outer layer of the standard RCS system, that is, ua (User agent) is used as an agent between a general message queue and User Equipment (UE) in the RCS system, and is responsible for protocol conversion processing to support access of external multiple protocols. Secondly, the internal communication of the RCS system is changed to use an RPC (Remote Procedure Call) protocol, and the RPC protocol is light and convenient, so that the high efficiency of message queue processing is realized by utilizing the high reliability and high concurrency of the RPC protocol.

In practical applications, in order to meet the requirements, a standard RCS system is modified, a cloud platform providing instant messaging capability and peripheral derivative capability is called URCS, and a standard IMS architecture is simplified to obtain an SIMS (Simple IP multimedia Subsystem), that is, a Simple or pure IMS is obtained as a universal message queue system for handling message processing in the URCS cloud platform.

Fig. 2 is an architecture diagram of an RCS system according to an embodiment of the present invention, and the system architecture according to an embodiment of the present invention is briefly described below with reference to fig. 2.

Referring to fig. 2, the URCS system architecture of the present embodiment includes: the protocol adaptation proxy serving as the external access stratum specifically comprises a plurality of SIMS routing gateways (2 shown in fig. 2) and an SIMS storage system (2 shown in fig. 2), wherein the SIMS routing gateways are connected with the SIMS storage system, and serve as an internal universal message queue system. The protocol adaptation agent is connected with the SIMS routing gateway through an RPC protocol, and the universal message queue system interacts with a universal storage module, namely a database. Fig. 2 illustrates four supported database types, which are Zookeeper, Redis, Mysql, and Hbase, however, in practical application, the database may be set as needed, and the database is not limited thereto.

The SIMS of the universal message queuing system of the URCS cloud platform of the present embodiment mainly provides the following functions: registering subscription: the access layer has message receiving and sending capability after registering subscription; message channel: the message channel supports store-forward and real-time delivery; offline pulling: supporting the pulling of offline message records; according to the requirements, offline storage of messages is supported, and offline storage is not supported for the messages which do not need offline storage.

Multi-protocol access: the access of various access layers is supported, and the access service of MQTT protocol, the access service of SIP protocol and the like are supported by adding a protocol adaptation agent; accessing multiple terminals: the access of terminals such as PAD (tablet device), APP (application program), PC (personal computer) and the like is supported;

multi-service access: support dynamic access of services to group services, public services and third-party services; here, it is mainly the support dimension of the message queue system, for example, the user level can support massive user access, the service level can support high concurrent transparent transmission, and the protocol level can implement multi-protocol access, where "service" can also be understood as a user for SIMS.

Compared with the traditional RCS system, the URCS internal network of the embodiment adopts RPC, reduces the flow and resource consumption, improves the system performance, improves the flexible access capability of the RCS system, has the dynamic access capability of the service, and realizes the effect of coexistence of performance and flexibility.

As can be seen from the system architecture shown in fig. 2, the URCS system of this embodiment includes a protocol adaptation agent, and the protocol adaptation agent is used for performing protocol conversion to implement multi-protocol access. As is clear to those skilled in the art, a standard RCS system uses the SIP protocol as a carrier, and such SIP-based communication is expensive and bandwidth waste is serious, and in order to solve this problem and implement multi-protocol access, in an embodiment of the present invention, a protocol conversion rule is configured in advance, for example, the protocol conversion rule includes: extracting common functions of interactive signaling in a plurality of first protocols and then defining a data flow interface according to the extracted common functions; the data flow interface includes: the protocol adaptation agent initiates a forward interface of communication to the IMS, and the IMS initiates a reverse interface of communication to the protocol adaptation agent.

The first protocol includes session Initiation protocol sip (session Initiation protocol), message queue Telemetry transmission mqtt (message Queuing Telemetry transport) protocol, and hypertext Transfer protocol http (hypertext Transfer protocol). The setting of the conversion rule is described here by taking the SIP protocol and MQTT protocol as an example, and the HTTP protocol is applicable as described below.

In addition, since the SIMS architecture is a simplified version of IMS, the scheme supporting multi-protocol access in this embodiment may be applied to a standard IMS architecture or a SIMS architecture, and is described below as being applied to the SIMS architecture for example, and the application in the IMS may refer to the description here and will not be described again.

Those skilled in the art understand that the SIP protocol mainly includes the following interactive signaling: MESSAGE, INVITE, REFER, REGISTER, SUBSCRIBE, NOTIFY, and OPTIONS.

Taking INVITE as an example, the INVITE message contains the session type and some parameters necessary for the call, and part of the content of the message is as follows:

INVITE sip:bob@biloxi.com SIP/2.0

Via:SIP/2.0/UDP pc33.atlanta.com；branch＝z9hG4bKnashds8

To:Bob<sip:bob@biloxi.com>

From:Anonymous<sip:anonymous@atlanta.com>；tag＝1928301774

Call-ID:a84b4c76e66710

CSeq:314159 INVITE

Max-Forwards:70

Date:Thu,21 Feb 2002 13:02:03 GMT

Contact:<sip:pc33.atlanta.com>

those skilled in the art understand that MQTT protocol mainly includes the following interactive signaling: CONNECT, CONNACK, PUBLISH, PUBACK, PUBREC, PUBREL, SUBSCRIBE, UNSUBSCRIBE, UNSUBSBACK, PINGRQ, PINRESP, and DISCONNECT.

Taking Publish and Subscribe as examples, the structure of the Publish message is shown in table 1 below:

TABLE 1

The structure of the Subscribe message is shown in the following table 2:

TABLE 2

The contents of the Publish message of the MQTT protocol and the INVITE signaling in the SIP protocol can indicate that the two protocols have similar functions, so that the common function of the interactive signaling of the two protocols is extracted in the embodiment, and a data flow interface is defined according to the extracted common function, and the data flow interface comprises: the protocol adaptation agent UA initiates a forward interface for communication to the SIMS, and the SIMS initiates a reverse interface for communication to the protocol adaptation agent. The forward interface is for example:

login, user registration;

logoff, user logout;

subscribe the message; SendMessage is to send a message;

GetMessages reads the message; MessageDelivered, notifying the SIMS that the message has been delivered;

MessageRead marks that the message has been read;

GetUserStatus, acquiring user information and terminal state; DeleteMessage delete a message.

The reverse interface is for example:

LoginNotify UA login notification;

LogoffNotify, UA logout notification;

incoming messages new message notifications;

incomingdials new session notification,

the new session notification is pushed in different manners according to the number of messages, for example, the new session notification is sent in a packet mode or in a single-message mode, and the packet sending is triggered when the number of messages is not greater than N, wherein N is a positive number.

In addition, there are some more specific forward interfaces, such as the roaming message interface: GetRoamingMessages, deleterroamingmessages, interfaces for the protocol adaptation agent UA to query the SIMS for the status of messages, etc.

After the preset interface is defined, the protocol adaptation agent UA can perform protocol conversion according to the interface. For example, the UA receives an access request sent by the user equipment UE through the SIP protocol, and converts the access request into a remote procedure call RPC registration message according to a preset protocol conversion rule (specifically, Login interface); or, the UA receives an access request sent by the user equipment UE through the MQTT protocol, and converts the access request into a Remote Procedure Call (RPC) registration message according to a preset protocol conversion rule (specifically, a Login interface).

It is known that the UA is responsible for access of the UE and completes transmission and reception of messages in cooperation with the SIMS. The design purpose of the SIMS is mainly to reduce the difficulty of terminal access using various protocols and ensure high availability and high concurrency of the instant messaging capability of a multi-protocol terminal through the abstraction of the layer UA, thereby realizing elegance and tidiness of a platform.

It should be noted that, the SIMS identifies the UA, which is a protocol adaptation agent, by using epid, where epid represents a user identifier, a data type is Long type, and the epid is globally unique and is a user ID in the system, and the format is as follows:

PC；version＝2.0.1.0430；uuid＝0a092ds99a012897db。

App:81273912387687213；version＝2.0.0.0630。

the user identification comprises equipment identification information and parameter information, and the equipment identification information and the parameter information are separated by taking a first-appearing semicolon as a boundary. That is, the epid is divided into a device identification (id) part for marking a unique one of the terminals and a parameter (parameters) part for recording information such as the version of the device, and the change of the parameter part does not affect the identification of the device. Taking the two user identifiers as an example, the first appearing semicolon in the first epid "; "the former PC is a device identifier, the APP before the first appearing semicolon in the second epid is also a device identifier, and the PC and the APP are two different device identifiers. That is, the device identifier of the present embodiment may be an (Application) APP.

And the SIMS allocates a message queue for each equipment identifier according to the equipment identifier in the user identifier of the RPC registration message sent by the received protocol adaptation agent so as to support multi-terminal access. That is, the SIMS allocates a message queue to each device identifier, and if the two reported device identifiers are of the same type, a cross relationship exists between the message queues corresponding to the two device identifiers, so that two devices of the same type can select whether to use the same device identifier according to different requirements for the integrity of the message queue.

For example, according to different subscription information of two similar devices identified by different devices, the SIMS completely sends the messages in the message queue of the similar device to the two devices; or, the SIMS divides the messages in the message queue of the same type of device and sends the divided messages to the two devices according to the same subscription information of the two devices of the same type with the same device identifier.

That is, if two devices of the same user (such as zhang san) select different device identities and set different subscription messages, the two devices may coexist on the SIMS system side, so that both devices may receive the complete message queue of the user without loss. If two devices select the same device identity, the two devices are mutually exclusive on the SIMS system side, only one device can be online, and cannot be online at the same time, so that the two devices each receive a part of the message queue, i.e., can only receive messages when the device is online. For example, the WeChat application includes a webpage version, a PC version, and a mobile version, and the mobile version can be subdivided into an iOS version and an Android version, and if two devices (the iOS version and the Android version) choose to use the same device identifier, such as a mobile app, the two devices will each receive a part of the message queue, that is, only a part of the message corresponding to the iOS version or the Android version login is received, and the message corresponding to the other terminal login is not received. In actual application, the RCS system can be set according to needs, and the flexibility of the RCS system is enhanced.

In one embodiment of the invention, the protocol adaptation agent sends a subscription request for subscribing the message topic to the SIMS through the subscription message interface;

the SIMS carries out corresponding processing on the subscribed message according to the message topic name in the subscription request, wherein the message topic comprises: store-and-forward messages/notifications, real-time messages/notifications, system broadcast messages/notifications, device-directed messages. That is, the user equipment UE may selectively subscribe to the topic, and different UEs may select to support different topics. topic is system-in, expressed using a string that uniquely identifies itself,

the topic format is as follows, "TopicName? Types & batch & N ",

for example, "SF? types 1v1, group, pubic & batch 1",

as another example, "RT? types is info, option & batch is 1 ".

Wherein TopicName represents the subject name of the message, types is the supported message type, and batch represents the number of messages in each batch for receiving new message notification.

The SIMS platform of this embodiment performs corresponding processing on the subscribed message according to the message topic name in the subscription request. I.e. there are different handling mechanisms for different topics.

For example: for "SF": storeForword, store forward message/notification. The SIMS platform stores the message in a message queue, and guarantees the delivery and the sequence of the message. And supports delivery reporting, read reporting, message revocation, and synchronization of read status on different terminals. Such as: 1v1 messages, group messages, public messages, etc.

For "RT": RealTime, real-time message/notification. The SIMS platform only sends messages to the terminals that are online and does not provide store-and-forward capability, and delivery and order are not guaranteed. In addition, real-time messages may also support delivery reports, and read reports. Real-time messages are as follows: ongoing input, system notifications, etc.

In addition, for "BC": Boradcast, the system broadcasts messages/notifications. The theme is that all terminals meeting the conditions can subscribe, and the conditions can be judged on the UA side or simply judged on the SIMS platform side, which is not limited. This subscription to message topics supports offline delivery, and does not support delivery reports, read reports, and message revocation.

As another example, for "DE" DedicatedEquipment, the device directs messages. The SIMS platform transmits the message to only a designated one of the terminals.

Considering that a communication mechanism based on an RPC message queue is used in the RCS, in order to avoid missing and missending of messages, in this embodiment, the protocol adaptation agent sends a message of the user equipment to the SIMS through the message sending interface, and the SIMS creates a unique message identifier for the received message and then stores the message into the message queue, where the message identifier is a natural number that is continuously incremented; and the SIMS updates the value of the preset parameter LastMsgId according to the message successful receiving notice returned by the user equipment or the protocol adaptation agent, and assigns the message identifier successfully received by the user equipment for the last time to the parameter LastMsgId. That is, on the RCS system side, the message sent by or to the user is stored in the corresponding message queue, and is identified by a unique message id (long type). The message id is generated globally by the SIMS platform, e.g., a natural number with continuously increasing id, always increases over time and is guaranteed to be globally unique.

Aiming at a message queue, the SIMS platform maintains a preset parameter lastMsgId and records the message id successfully received by the terminal for the last time, in the SIMS platform, the success marks of the messages in the message queue received by the terminal are sequential, that is, after the lastMsgId of the message queue of the terminal is updated to X, all the messages with the message identification less than or equal to X are considered to be successfully received by the terminal. The SIMS platform of this embodiment does not support the logic of partial successful reception, i.e., the reception of messages must be done from small to large according to the message id.

As shown in table 3 below: the PC in the first row of the table, APP indicates the device identifier (i.e. mobile application), and the corresponding number 23 below the PC indicates that messages with message identifiers below 23 (including the number) have been successfully received by the terminal, and similarly, the corresponding number 38 below the APP indicates that messages with message identifiers below 38 (including the number) have been successfully received by the terminal.

PC	APP
		23	38

TABLE 3

In addition, the SIMS platform allocates one message queue for each topic and maintains one lastMsgId for each different device identification.

In the embodiment of the invention, after the message reaches the user equipment of the receiving party, the protocol adaptation agent calls the SIMS to generate the delivery report, and the SIMS stores the generated delivery report as a message in a message queue of the sending party and sends the delivery report to the user equipment of the sending party; and the protocol adaptation agent calls an SIMS synchronous read report according to the read report sent by the user equipment of the receiving party after confirming that the user reads the message, and the SIMS stores the read report as a message in message queues of the receiving party and the sending party respectively after the SIMS read report is synchronous.

That is, in the SIMS platform, delivery reports are considered to be a message, as are read reports. The delivery report (DeliverReport) is generated by the UA calling the SIMS after the UA of the receiver confirms that the message is delivered to the receiver, the SIMS platform stores the delivery report as a message in an SIMS message queue, the delivery report comprises the original message id, and the SIMS returns the message report to the original sender of the message.

For the read report (ReadReport), after the receiver UE confirms that the user has read the message, the receiver UE sends the read report to the receiver UA, and the receiver UA calls the SIMS to synchronize the read report according to whether the service requires the read report, and after the SIMS receives the read report, the SIMS stores the read report as a message in the message queues of the receiver and the sender, respectively, that is, stores a read report for the receiver, and stores a read report message for the original sender of the message, as shown in table 4 below:

TABLE 4

The first column Msgid in table 4 is the message identification, where 1 represents the first message. The second column, Owerid, represents a user identification, such as 1001. The third column DialogUri represents a session identification, such as id: 1002. The fourth column Direction represents the MESSAGE Direction, such as UP for upstream MESSAGEs, the fifth column MsgType represents the MESSAGE type, such as MESSAGE or READ _ REPORT, the sixth column MsgContent represents the MESSAGE content, such as TEST or msgid:1 (READ REPORT for the first MESSAGE), and the last column Desc represents the description, corresponding to remarks and explanations.

It should be noted that the delivery report and the read report in this embodiment are optional items of the service, and should be configured according to the service type and the requirement, and are not limited thereto.

The method for supporting multi-protocol access by the RCS belongs to a technical concept, an embodiment of the present invention further provides a device for supporting multi-protocol access by the RCS, fig. 3 is a block diagram of the device for supporting multi-protocol access by the RCS according to an embodiment of the present invention, referring to fig. 3, a protocol adaptation agent is deployed in the RCS, and the device 300 for supporting multi-protocol access by the RCS includes:

a protocol conversion module 301, configured to receive an access request sent by a user equipment through a first protocol by using a protocol adaptation proxy, and convert the access request into a Remote Procedure Call (RPC) registration message according to a preset protocol conversion rule, where the first protocol includes: session initiation protocol SIP, message queue telemetry transmission MQTT protocol and hypertext transfer protocol HTTP;

a sending module 302, configured to send, by using a protocol adaptation proxy, an RPC registration message to an IP multimedia subsystem IMS of the RCS via a PRC protocol;

an implementation module 303, configured to allocate, by using the IMS, a message queue for storing the communication message to the user equipment according to the received RPC registration message, so as to complete access.

In an embodiment of the present invention, the protocol conversion module 301 includes a setting module, configured to extract a common function of the interactive signaling in the plurality of first protocols and then define a data flow interface according to the extracted common function; the data flow interface comprises: the protocol adaptation agent initiates a forward interface of communication to the IMS, and the IMS initiates a reverse interface of communication to the protocol adaptation agent.

In an embodiment of the present invention, the implementation module 303 is specifically configured to allocate, by using the IMS, a message queue to each device identifier according to the device identifier in the user identifier of the RPC registration message sent by the received protocol adaptation agent; the user identification comprises equipment identification information and parameter information, and the equipment identification information and the parameter information are separated by taking a first-appearing semicolon as a boundary.

In an embodiment of the present invention, the apparatus 300 further includes an interaction module, configured to send, by using the IMS, a message in a message queue of two similar devices identified by different devices to the two devices completely according to subscription information of the two similar devices; or, the IMS divides the messages in the message queue of the same device and sends the divided messages to the two devices according to the subscription information of the two devices of the same device identifier.

In an embodiment of the present invention, the apparatus 300 further includes a subscription module, configured to send a subscription request for subscribing to a message topic to the IMS through the subscription message interface by using the protocol adaptation proxy; the IMS carries out corresponding processing on the subscribed message according to the message topic name in the subscription request, wherein the message topic comprises: store-and-forward messages/notifications, real-time messages/notifications, system broadcast messages/notifications, device-directed messages.

In an embodiment of the present invention, the apparatus 300 further includes a recording module, configured to send a message of the user equipment to the IMS through a message sending interface by using a protocol adaptation agent, where the IMS creates a unique message identifier for the received message and stores the message in a message queue, where the message identifier is a natural number that is continuously incremented; and the IMS updates the value of the preset parameter LastMsgId according to the message successful receiving notice returned by the user equipment or the protocol adaptation agent, and assigns the message identifier successfully received by the user equipment for the last time to the parameter LastMsgId.

In an embodiment of the present invention, the apparatus 300 further includes a reporting module, configured to invoke the IMS to generate a delivery report after the message is delivered to the user equipment of the receiving party by using the protocol adaptation agent, where the IMS stores the generated delivery report as a message in a message queue of the sending party and sends the delivery report to the user equipment of the sending party; and the protocol adaptation agent calls an IMS synchronous read report according to the read report sent by the user equipment of the receiving party after confirming that the user reads the message, and the IMS stores the read report as a message in message queues of the receiving party and the sending party respectively after the IMS read report is synchronous.

The exemplary explanation of the functions performed by the modules in the apparatus shown in fig. 3 is consistent with the exemplary explanation of the foregoing method embodiment, and is not repeated here.

In summary, in the method and apparatus for supporting multi-protocol access by an RCS of a rich communication suite, a protocol adaptation proxy is deployed in the RCS, the protocol adaptation proxy receives an access request sent by a user equipment through a first protocol, converts the access request into a Remote Procedure Call (RPC) registration message according to a preset protocol conversion rule, and sends the RPC registration message to an IP Multimedia Subsystem (IMS) of the RCS through a PRC protocol; and the IMS correspondingly allocates a message queue for storing the communication message to the user equipment according to the received RPC registration message to finish the access. Therefore, the standard RCS framework transmission protocol is optimized, the access of the terminal using the standard MQTT protocol and other protocols is realized through the message queue, the protocol access capability is realized, the decoupling of core message logic is realized, the group distribution capability is realized, and the stability of the system is improved. Writing improves the flexibility of the service of the Internet architecture system.

Fig. 4 is a schematic structural diagram of an electronic device according to an embodiment of the present invention. As shown in fig. 4, the electronic device includes a memory 401 and a processor 402, the memory 401 and the processor 402 are communicatively connected through an internal bus 403, the memory 401 stores program instructions executable by the processor 402, and the program instructions, when executed by the processor 402, can implement the method for supporting multi-protocol access by the rich communication suite RCS described above.

In addition, the logic instructions in the memory 401 may be implemented in the form of software functional units and may be stored in a computer readable storage medium when the logic instructions are sold or used as independent products. Based on such understanding, the technical solution of the present invention or a part thereof, which essentially contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.

Another embodiment of the present invention provides a computer-readable storage medium storing computer instructions that cause the computer to perform the above-described method.

As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

It is to be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.

In the description of the present invention, numerous specific details are set forth. It is understood, however, that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description. Similarly, it should be appreciated that in the foregoing description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. However, the disclosed method should not be interpreted as reflecting an intention that: that the invention as claimed requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of this invention.

While the foregoing is directed to embodiments of the present invention, other modifications and variations of the present invention may be devised by those skilled in the art in light of the above teachings. It should be understood by those skilled in the art that the foregoing detailed description is for the purpose of illustrating the invention rather than the foregoing detailed description, and that the scope of the invention is defined by the claims.

Claims

1. A method for a rich communication suite, RCS, to support multi-protocol access, wherein a protocol adaptation agent is deployed in the RCS, the method comprising:

the protocol adaptation agent sends the RPC registration message to an IP multimedia subsystem IMS of the RCS through a PRC protocol;

and the IMS correspondingly allocates a message queue for storing the communication message to the user equipment according to the received RPC registration message to finish the access.

2. The method of claim 1, wherein the preset protocol conversion rule comprises: extracting a common function of the interactive signaling in the first protocol and then defining a data flow interface according to the extracted common function;

the data flow interface comprises: the protocol adaptation agent initiates a forward interface of communication to the IMS, and the IMS initiates a reverse interface of communication to the protocol adaptation agent.

3. The method of claim 1, wherein the IMS, according to the received RPC registration message, correspondingly allocating a message queue for storing communication messages to the ue comprises:

the IMS allocates a message queue for each equipment identifier according to the equipment identifier in the user identifier of the RPC registration message sent by the received protocol adaptation agent;

the user identification comprises equipment identification information and parameter information, and the equipment identification information and the parameter information are separated by taking a first-appearing semicolon as a boundary.

4. The method of claim 3, further comprising:

the IMS completely sends the messages in the message queue of the same type of equipment to the two pieces of equipment according to the different subscription information of the two pieces of equipment with different equipment identifications;

or, the IMS divides the messages in the message queue of the same device and sends the divided messages to the two devices according to the same subscription information of the two devices of the same device identifier.

5. The method of claim 3, further comprising: the protocol adaptation agent sends a subscription request of a subscription message theme to the IMS through a subscription message interface;

the IMS correspondingly processes the subscribed message according to the message topic name in the subscription request, wherein the message topic comprises: store-and-forward messages/notifications, real-time messages/notifications, system broadcast messages/notifications, device-directed messages.

6. The method of claim 1, further comprising:

the protocol adaptation agent sends the message of the user equipment to the IMS through a message sending interface, the IMS creates a unique message identifier for the received message and then stores the message into a message queue, and the message identifier is a natural number which is continuously increased;

and the IMS updates the value of the preset parameter LastMsgId according to the message successful receiving notice returned by the user equipment or the protocol adaptation agent, and assigns the message identifier successfully received by the user equipment for the last time to the parameter LastMsgId.

7. The method of claim 1, further comprising:

after the message reaches the user equipment of the receiving party, the protocol adaptation agent calls an IMS (IP multimedia subsystem) to generate a delivery report, the IMS stores the generated delivery report as a message in a message queue of the sending party and sends the delivery report to the user equipment of the sending party;

and the protocol adaptation agent calls an IMS synchronous read report according to the read report sent by the user equipment of the receiving party after confirming that the user reads the message, and the IMS stores the read report as a message in message queues of the receiving party and the sending party respectively after the IMS read report is synchronous.

8. An apparatus for supporting multi-protocol access by a Rich Communication Suite (RCS), wherein a protocol adaptation agent is deployed in the RCS, the apparatus comprising:

the protocol conversion module is used for receiving an access request sent by user equipment through a first protocol by using a protocol adaptation agent, and converting the access request into a Remote Procedure Call (RPC) registration message according to a preset protocol conversion rule; the first protocol includes: session initiation protocol SIP, message queue telemetry transport protocol MQTT and hypertext transport protocol HTTP;

9. The apparatus according to claim 8, wherein the protocol conversion module includes a setting module, configured to extract a common function of the interactive signaling in the first protocol and then define a data flow interface according to the extracted common function; the data flow interface comprises: the protocol adaptation agent initiates a forward interface of communication to the IMS, and the IMS initiates a reverse interface of communication to the protocol adaptation agent.

10. An electronic device, characterized in that the electronic device comprises: a memory and a processor communicatively coupled via an internal bus, the memory storing program instructions executable by the processor, the program instructions when executed by the processor implementing the method of any of claims 1-7.