CN119299433A - Information processing method, device and storage medium - Google Patents

Abstract

The present application discloses an information processing method, device and storage medium, which are applied to electronic devices deployed with an Internet Multimedia Subsystem (IMS) of an Internet Protocol, and relate to the field of communication technology. The method comprises: in response to receiving a write request sent by a user terminal, determining the priority of the write request; based on the priority of the write request, placing the write request into a preset token queue; based on the position of the write request in the preset token queue and the token associated with the preset token queue, synchronously writing the context information of the user terminal into a first hash table in a first database corresponding to the IMS, and a second hash table in a second database corresponding to the electronic device.

Description

Information processing method, device and storage medium

Technical Field

The present application relates to the field of communication technology, and in particular to an information processing method, device and storage medium.

Background Art

In order to enable the lightweight 5G Core Network (5GC) to support traditional voice functions such as voice calls and video calls, it is necessary to integrate the Internet Protocol (IP) Multimedia Subsystem (IMS) into electronic devices that support 5GC.

However, since typical lightweight 5GC and IMS use different databases for data storage and management, when integrating IMS into electronic devices that support 5GC, how to ensure that the data in the corresponding database of IMS is synchronized with the data in the corresponding database of electronic devices that support 5GC is a technical problem that the industry urgently needs to solve.

Summary of the invention

In response to the above technical problems, embodiments of the present application provide an information processing method, device, and storage medium.

The technical solution of the embodiment of the present application is implemented as follows:

In a first aspect, an embodiment of the present application provides an information processing method, which is applied to an electronic device deployed with an Internet Protocol IP Multimedia Subsystem IMS, and the method includes:

In response to receiving a write request sent by a user terminal, determining a priority of the write request;

Based on the priority of the write request, placing the write request into a preset token queue;

Based on the position of the write request in the preset token queue and the token associated with the preset token queue, the context information of the user terminal is synchronously written into a first hash table in a first database corresponding to the IMS and a second hash table in a second database corresponding to the electronic device.

In some embodiments, in response to receiving a write request sent by a user terminal, determining the priority of the write request includes:

In response to receiving the write request, obtaining a message type and an expiration time corresponding to the write request;

The priority is determined based on the message type and the expiration time.

In some embodiments, determining the priority based on the message type and the expiration time includes:

Fuzzifying the message type and the expiration time to obtain a first value corresponding to the message type and a second value corresponding to the expiration time;

The center average method is used to calculate the first value, the first weight corresponding to the message type, the second value, and the second weight corresponding to the expiration time to obtain the priority.

In some embodiments, placing the write request into a preset token queue based on the priority of the write request includes:

When the preset token queue is empty, placing the write request at any position in the preset token queue;

When the preset token queue is not empty, the write request is placed in the preset token queue based on the priority of the write request and the priority of the requests already placed in the preset token queue.

In some embodiments, the preset token queue includes at least one of the placed requests, and placing the write request into the preset token queue based on the priority of the write request and the priority of the placed requests in the preset token queue includes one of the following:

In the case where the priority of at least one of the placed requests is higher than the priority of the write request, placing the write request in the preset token queue at a position after at least one of the placed requests;

In the case where the priority of at least one of the placed requests is lower than the priority of the write request, placing the write request in the preset token queue at a position before at least one of the placed requests;

When the priority of the first request is higher than the priority of the write request and the priority of the second request is lower than the priority of the write request, placing the write request in the preset token queue after the first request and before the second request;

The at least one placed request includes: the first request and the second request.

In some embodiments, based on the position of the write request in the preset token queue and the token associated with the preset token queue, synchronously writing the context information of the user terminal into a first hash table in the first database corresponding to the IMS and a second hash table in the second database corresponding to the electronic device includes:

In response to the information at the front position before the position in the preset token queue being empty, identifying the state of the token;

In response to the state of the token being an unused state, allocating the calling permission of the token to the write request to change the write request to a current request in an execution state;

Based on the current request, the context information is synchronously written into a first hash table in a first database corresponding to the IMS and a second hash table in a second database corresponding to the electronic device.

In some embodiments, the information processing method further includes:

In response to the context information, completing synchronous writing into the first hash table and the second hash table, and determining that the execution of the current request is completed;

In response to the current request execution being completed, the token is released, and the state of the token is updated from the used state to the unused state.

In some embodiments, the information processing method further includes:

In response to the completion of initialization of the first hash table, the information in the first hash table is exported to the initial second database to obtain the second database having the second hash table.

In a second aspect, an embodiment of the present application provides an information processing device, which is applied to an electronic device deployed with an Internet Protocol IP Multimedia Subsystem IMS, and the device includes:

a determining unit, configured to, in response to receiving a write request sent by a user terminal, determine a priority of the write request;

a placing unit configured to place the write request into a preset token queue based on the priority of the write request;

The writing unit is configured to synchronously write the context information of the user terminal into a first hash table in a first database corresponding to the IMS and a second hash table in a second database corresponding to the electronic device based on the position of the write request in the preset token queue and the token associated with the preset token queue.

In a third aspect, an embodiment of the present application provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the information processing method described in the first aspect is implemented.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the technical solutions of the embodiments of the present application, a brief introduction will be given below to the drawings required for use in the embodiments. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

FIG1 is a flow chart of an information processing method according to an embodiment of the present application;

FIG2 is a second flow chart of an information processing method provided in an embodiment of the present application;

FIG3 is a schematic diagram of a structure for calculating the priority of a write request provided by an embodiment of the present application;

FIG4 is a schematic diagram of calculating the priority of a write request using a center average method according to an embodiment of the present application;

FIG5 is a third flow chart of an information processing method provided in an embodiment of the present application;

FIG6 is a fourth flow chart of an information processing method provided in an embodiment of the present application;

FIG7 is a fifth flow chart of an information processing method provided in an embodiment of the present application;

FIG8 is a sixth flow chart of an information processing method provided in an embodiment of the present application;

FIG9 is a schematic diagram of mapping some parameters of r_contact in P-CSCF to a Redis memory database provided by an embodiment of the present application;

FIG10 is a schematic diagram of a distributed system architecture provided in an embodiment of the present application;

FIG11 is a schematic diagram of the structure of an information processing device provided in an embodiment of the present application;

FIG. 12 is a schematic diagram of the physical structure of an electronic device deployed with an Internet Multimedia Subsystem IMS of the Internet Protocol IP provided in an embodiment of the present application.

DETAILED DESCRIPTION

In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the embodiments of the present application.

It should be noted that in the description of the embodiments of the present application, the terms "first", "second", etc. are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable under appropriate circumstances, so that the embodiments of the present application can be implemented in an order other than those illustrated or described here, and the objects distinguished by "first", "second", etc. are generally of the same type, and the number of objects is not limited. For example, the first object can be one or more.

In order to facilitate a clearer understanding of the embodiments of the present application, some relevant background knowledge is first introduced as follows.

In response to the needs of the private network market for the fifth generation of mobile communications (5G), lightweight 5GC needs to support traditional voice functions such as voice calls and video calls. In order to achieve voice and video call functions, electronic devices that support lightweight 5GC usually integrate IMS. IMS is an architecture framework for providing IP multimedia services. It supports multiple network access methods and multimedia services. By integrating IMS into electronic devices that support lightweight 5GC, support for traditional voice functions can be achieved while maintaining compatibility with existing networks and business systems.

However, since IMS and 5GC are defined and specified by different standardization organizations and are designed and developed by different teams, there are significant differences between the two in the choice of technology stack and the application of technology middle platform.

Typical lightweight 5GCs usually use the in-memory database Redis for data storage and management, while IMS based on the OpenIMSCore open source framework usually uses the relational database Mariadb for data storage and management. Therefore, when integrating IMS into electronic devices corresponding to lightweight 5GCs using the in-memory database Redis, it is necessary to ensure that the data in the IMS in-memory HASH table items is synchronized with the key-value data in the 5GC's Redis.

The embodiments of the present application provide an information processing method, device, and storage medium, which can effectively ensure the consistency and synchronization of data in an IMS memory hash table entry and data in a memory database of an electronic device supporting 5GC.

The following is an illustrative introduction to the information processing method, device and storage medium provided in the embodiments of the present application in conjunction with the drawings in the embodiments of the present application.

FIG. 1 is one of the flow diagrams of an information processing method provided in an embodiment of the present application. The method is applied to an electronic device deployed with an Internet Protocol IP Multimedia Subsystem IMS. As shown in FIG. 1 , the method includes:

S101. In response to receiving a write request sent by a user terminal, determine a priority of the write request.

It should be noted that the user terminal in the embodiment of the present application is a device that can access the IMS network and communicate with it, for example, it may include a smart phone, a tablet computer, a desktop computer, and a dedicated IMS fixed-line terminal.

It should be noted that the write request sent by the user terminal is a request sent by the user terminal to the IMS network, which is used to perform a specific write operation in the IMS network. For example, a user sends a message (such as a text message, picture, audio, video and other multimedia messages) to an electronic device deployed with IMS through a user terminal. These messages will be sent to the IMS network as a write request and processed and forwarded by the corresponding functional entities in the IMS network. For another example, when a user wants to have a voice call, video call or instant messaging session with other users, the user terminal will send a session establishment request to the IMS network. These requests contain the parameters and configuration information required for the session so that the IMS network can correctly establish and maintain the session.

It should be noted that in the IMS network, the write request sent by the user terminal will be passed to the functional entity responsible for processing such requests, such as the Call Session Control Function (CSCF). CSCF is the core control node of the IMS network, responsible for processing signaling messages (Session Initiation Protocol, SIP), providing user access control, network authentication, session control, service triggering and quality of service (QoS) control functions.

In an embodiment of the present application, upon receiving a write request sent by a user terminal, the priority of the write request can be determined in response to the write request. It should be noted that different write requests may correspond to different user needs and service quality requirements. By determining the priority of the write request, it can be ensured that the needs of key businesses or emergency services are met, thereby improving user satisfaction. In addition, the processing power, bandwidth, storage and other resources of electronic devices are limited. By determining the priority of the write request, it can be ensured that high-priority requests can be processed first, thereby optimizing the efficiency of resource use.

In some embodiments, different service types may be assigned different QoS Class Identifier (QCI) values based on user or business requirements. The QCI value defines QoS parameters such as transmission priority, packet delay budget, and packet error rate, thereby indirectly determining the priority of the write request.

In some embodiments, the priority of the write request may be determined based on the current system load conditions.

S102: Based on the priority of the write request, put the write request into a preset token queue.

It should be noted that a token queue is a collection of write requests that need to be executed, which has the following two functions: (1) maintaining the execution order of write requests; (2) ensuring mutual exclusion between write requests. Both of these are achieved through tokens. The rule is: only write requests that obtain tokens can be executed, and the tokens are returned after execution. Since there is only one token in the token queue, only one write request is in execution at any time.

In an embodiment of the present application, the write request sent by the user terminal can be placed in a corresponding position in a preset token queue based on the priority of the write request.

In some embodiments, the position where the write request should be placed in the preset token queue can be determined based on the priority of the write request sent by the user terminal and the priority of the requests already placed in the preset token queue.

S103: Based on the position of the write request in the preset token queue and the token associated with the preset token queue, synchronously write the context information of the user terminal into a first hash table in a first database corresponding to the IMS and a second hash table in a second database corresponding to the electronic device.

It should be noted that the preset token queue is associated with only one token, and only write requests that obtain the token can be executed.

It should be noted that the context information of the user terminal refers to a data set related to the current state, operation or session of the user terminal, and the data set may include at least the following information:

1. User identity information, including user ID (an identifier that uniquely identifies a user), user name or nickname (the user's display name in the system);

2. Terminal information, including terminal ID (an identifier that uniquely identifies the user terminal), terminal type (such as mobile phone, tablet computer, etc.), operating system and version (the operating system and version number running on the user terminal);

3. Network status information, including IP address (IP address of the user terminal, which may be used for geographic location or network access control) and network type (such as Wi-Fi, 4G/5G, etc., which may affect the speed and stability of data transmission);

4. Session information, including session ID (an identifier that uniquely identifies the user's current session), session start time (the time when the session was created), and session duration (how long the session has lasted or how long it is expected to last).

It should be noted that the first database corresponding to the IMS and the second database corresponding to the electronic device are different databases, and the first database and the second database can be any existing databases, which is not specifically limited in the embodiment of the present application.

In some embodiments, based on the position of the write request sent by the user terminal in the preset token queue and the usage status of the token associated with the preset token queue, the context information of the user terminal can be synchronously written into the first hash table in the first database corresponding to the IMS and the second hash table in the second database corresponding to the electronic device, so as to achieve consistency and synchronization of the data in the first database corresponding to the IMS and the data in the second database corresponding to the electronic device.

In some embodiments, the key and value of the first hash table in the first database corresponding to the IMS can be constructed based on the context information of the user terminal. The key can be a user ID, a session ID, or a combination thereof, and the value is a hash table containing the specific context information of the user terminal. Furthermore, the context information of the user terminal can be written into the first hash table in the first database using the hash table operation command of the first database.

In some embodiments, the electronic device deployed with IMS may be an electronic device supporting lightweight 5GC, and the second database corresponding to the electronic device may be an in-memory database Redis.

It should be noted that Redis is a high-performance key-value database that supports multiple types of data structures, such as strings, lists, sets, sorted sets, and hash tables, etc. Among these data structures, hash tables are an important data structure used by Redis to store key-value pairs.

In some embodiments, when the second database is a memory database Redis, the key (Key) and value (Value) of the hash table item in Redis can be constructed based on the context information of the user terminal. The key can be a user ID, a session ID, or a combination thereof, and the value is a hash table containing the specific context information of the user terminal. Furthermore, the hash table operation command of Redis can be used to write the context information of the user terminal into the second hash table in the Redis memory database.

It can be understood that the information processing method provided in the embodiment of the present application, in response to receiving a write request sent by a user terminal, first determines the priority of the write request, and then, based on the priority, puts the write request into a preset token queue, and then, based on the position of the write request in the preset token queue and the token associated with the preset token queue, synchronously writes the context information of the user terminal into the first hash table in the first database corresponding to the IMS and the second hash table in the second database corresponding to the electronic device. In this way, by introducing priority processing and token queue mechanism, not only the controllability and efficiency of the data writing process are improved, but also the consistency and synchronization of the data in the first database corresponding to the IMS and the data in the second database corresponding to the electronic device can be effectively ensured.

In some embodiments, in response to receiving a write request sent by a user terminal, determining the priority of the write request includes:

In response to receiving the write request, obtaining a message type and an expiration time corresponding to the write request;

The priority is determined based on the message type and the expiration time.

It should be noted that the message type refers to the category or type to which the user message for sending the write request belongs, and is used to identify the operation that the user terminal wants the electronic device to perform or the resource type requested. The message type is usually a string or an enumeration value.

It should be noted that the expiration time refers to the expiration time of the authentication token. When a user terminal interacts with an electronic device, in order to verify the identity and authority of the user terminal, the electronic device requires the user terminal to include a valid authentication token in the write request.

It should be noted that both the message type and the expiration time can be obtained from the user message corresponding to the write request.

In some embodiments, the user message corresponding to the write request sent by the user terminal may be parsed to obtain the message type and expiration time.

It should be noted that different message types may have different impacts on the system. For example, some types of requests may involve the modification of critical data, while other types of requests may only query data. Therefore, different priority weights can be assigned to different types of messages according to predefined rules or policies.

In some embodiments, if the expiration time of a write request is very close to the current time (for example, the time difference between the expiration time and the current time is less than a set value), it can be determined that the request needs to be processed first, and a higher priority weight is assigned to the request; if the expiration time of the request is still a long time away from the current time, it can be determined that the request does not need to be processed immediately, and a lower priority weight is assigned to the request.

In some embodiments, the priority weight of the message type may be combined with the priority weight corresponding to the urgency of the expiration time, and the priority of the write request may be comprehensively determined through a certain algorithm (such as weighted summation).

For example, FIG2 is a second flow chart of an information processing method provided in an embodiment of the present application. As shown in FIG2 , the method includes:

S201. In response to receiving a write request sent by a user terminal, obtain a message type and an expiration time corresponding to the write request.

S202: Determine the priority of the write request based on the message type and the expiration time.

S203: Based on the priority of the write request, put the write request into a preset token queue.

S204: Based on the position of the write request in the preset token queue and the token associated with the preset token queue, synchronously write the context information of the user terminal into a first hash table in a first database corresponding to the IMS and a second hash table in a second database corresponding to the electronic device.

It should be noted that, for the description of the same steps and the same contents in this embodiment as those in other embodiments, reference can be made to the description in other embodiments and will not be repeated here.

It can be understood that the embodiments of the present application determine the priority of the write request based on the message type and expiration time corresponding to the write request, so that the execution order of the write request can be intelligently sorted based on the urgency and importance of the write request, thereby ensuring that critical or urgent write requests can be processed first, thereby reducing the waiting time for the execution of the write request and improving processing efficiency.

In some embodiments, determining the priority based on the message type and the expiration time includes:

Fuzzifying the message type and the expiration time to obtain a first value corresponding to the message type and a second value corresponding to the expiration time;

The center average method is used to calculate the first value, the first weight corresponding to the message type, the second value, and the second weight corresponding to the expiration time to obtain the priority.

It should be noted that fuzzy algorithm (also called fuzzy logic or fuzzy reasoning) is a mathematical method based on fuzzy set theory, which is used to process fuzzy or uncertain information. The core of this algorithm is to convert human fuzzy concepts and language into mathematical expressions, so as to better deal with problems that are difficult to accurately describe in traditional binary logic. Among them, fuzzy sets are the basis of fuzzy algorithms, which allow elements in a set to belong to the set with a certain degree of membership, rather than simply "belonging" or "not belonging". The degree of membership is usually a value between 0 and 1, indicating the degree to which an element belongs to the set.

It should be noted that the first weight corresponding to the message type and the second weight corresponding to the expiration time can respectively represent the height of their respective fuzzy sets, and can be adaptively set based on actual applications. The embodiments of the present application do not make specific limitations on this.

In an embodiment of the present application, the message type and expiration time corresponding to the write request can be fuzzified respectively to obtain a first value corresponding to the message type and a second value corresponding to the expiration time, and then the central average method is used to calculate the first value corresponding to the message type, the first weight corresponding to the message type, the second value corresponding to the expiration time, and the second weight corresponding to the expiration time to obtain the priority of the write request.

Exemplarily, Figure 3 is a structural diagram of a method for calculating the priority of a write request provided in an embodiment of the present application. As shown in Figure 3, two information in the user message corresponding to the write request are used as input parameters of the fuzzy algorithm, namely: the message type corresponding to the write request (represented by T) and the expiration time corresponding to the write request (represented by TE); the output parameter is P, and the larger the P value, the higher the priority.

In some embodiments, if the message type is a REQUES type, the first weight corresponding to the message type can be set to 1; if the message type is an INVITE type, the first weight corresponding to the message type can be set to 0.75; if the message type is an OTHERS type, the first weight corresponding to the message type can be set to 0.5.

In some embodiments, if the expiration time is greater than or equal to 3600 milliseconds, the second weight corresponding to the expiration time can be set to 0.5; if the expiration time is greater than 1200 milliseconds and less than 3600 milliseconds, the second weight corresponding to the expiration time can be set to 0.75; if the expiration time is less than or equal to 1200 milliseconds, the second weight corresponding to the expiration time can be set to 1.

In some embodiments, the center average method can be used to fuzzify the message type and expiration time. By taking a weighted average of the centers of multiple fuzzy sets, setting the weight to the height of the corresponding fuzzy set, calculating the fuzzy output, and using the fuzzy output as the priority of the write request. The specific calculation is shown in formula (1):

Among them, ^yi is the center of the i-th fuzzy set, _wi is the height (i.e., weight) of the i-th fuzzy set, and y ^* represents the fuzzy output, which is the required priority P.

Exemplarily, Figure 4 is a schematic diagram of a method for calculating the priority of a write request using the central average method provided in an embodiment of the present application, as shown in Figure 4, wherein ^y1 represents the center of the fuzzy set corresponding to the message type, _w1 represents the height of the fuzzy set corresponding to the message type, ^y2 represents the center of the fuzzy set corresponding to the expiration time, and _w2 represents the height of the fuzzy set corresponding to the expiration time.

For example, FIG5 is a flowchart of a third information processing method provided in an embodiment of the present application. As shown in FIG5 , the method includes:

S501. In response to receiving a write request sent by a user terminal, obtain a message type and an expiration time corresponding to the write request.

S502: Fuzzify the message type and the expiration time to obtain a first value corresponding to the message type and a second value corresponding to the expiration time.

S503: Using the center average method, calculate the first value, the first weight corresponding to the message type, the second value, and the second weight corresponding to the expiration time to obtain the priority of the write request.

S504: Based on the priority of the write request, put the write request into a preset token queue.

S505: Based on the position of the write request in the preset token queue and the token associated with the preset token queue, synchronously write the context information of the user terminal into a first hash table in a first database corresponding to the IMS and a second hash table in a second database corresponding to the electronic device.

It should be noted that, for the description of the same steps and the same contents in this embodiment as those in other embodiments, reference can be made to the description in other embodiments and will not be repeated here.

It can be understood that the embodiment of the present application fuzzifies the message type and expiration time corresponding to the write request respectively, obtains the first value corresponding to the message type and the second value corresponding to the expiration time, and then adopts the central average method to calculate the first value corresponding to the message type, the first weight corresponding to the message type, the second value corresponding to the expiration time, and the second weight corresponding to the expiration time, so as to effectively obtain the priority of the write request, and realize intelligent sorting of the execution order of the write request based on the urgency and importance of the write request, ensuring that critical or urgent write requests can be processed first, thereby reducing the waiting time for the execution of the write request and improving the processing efficiency.

In some embodiments, placing the write request into a preset token queue based on the priority of the write request includes:

When the preset token queue is empty, placing the write request at any position in the preset token queue;

When the preset token queue is not empty, the write request is placed in the preset token queue based on the priority of the write request and the priority of the requests already placed in the preset token queue.

It should be noted that when placing a write request into the preset token queue, the current state of the preset token queue (i.e., whether it is empty) and the relationship between the priority of the write request and the priority of the request already placed in the preset token queue can be considered. Specifically, first check whether the preset token queue is empty. If the preset token queue is empty, it means that there is no request in the preset token queue. Then the write request can be directly placed in any position in the preset token queue (since the preset token queue is empty, the correctness of subsequent operations will not be affected by placing the write request in any position); if the preset token queue is not empty, how to place the write request can be determined based on the priority of the write request and the priority of the request already placed in the preset token queue. Specifically, the priority of the write request can be compared with the priority of the request already placed in the preset token queue. If the priority of the write request is higher than the priority of the request already placed, then the write request can be placed in front of the preset token queue (head) to ensure that it can be processed faster; if the priority of the write request is lower than or equal to the priority of the request already placed, then the write request should be added to the back of the request already placed to maintain the order of the queue. That is, according to the priority comparison result, the write request is inserted into the appropriate position of the preset token queue.

For example, FIG6 is a fourth flowchart of an information processing method provided in an embodiment of the present application. As shown in FIG6 , the method includes:

S601: In response to receiving a write request sent by a user terminal, obtain a message type and an expiration time corresponding to the write request.

S602: Fuzzify the message type and the expiration time to obtain a first value corresponding to the message type and a second value corresponding to the expiration time.

S603: Use the center average method to calculate the first value, the first weight corresponding to the message type, the second value, and the second weight corresponding to the expiration time to obtain the priority of the write request.

S604: When the preset token queue is empty, place the write request at any position in the preset token queue.

S605: When the preset token queue is not empty, based on the priority of the write request and the priority of the requests already put into the preset token queue, put the write request into the preset token queue.

S606: Based on the position of the write request in the preset token queue and the token associated with the preset token queue, synchronously write the context information of the user terminal into a first hash table in a first database corresponding to the IMS and a second hash table in a second database corresponding to the electronic device.

It should be noted that, for the description of the same steps and the same contents in this embodiment as those in other embodiments, reference can be made to the description in other embodiments and will not be repeated here.

It can be understood that the embodiment of the present application determines the position where the write request should be placed in the preset token queue based on the current state of the preset token queue (i.e., whether it is empty) and the relationship between the priority of the write request and the priority of the requests already placed in the preset token queue, thereby ensuring that requests with higher priority can be processed more quickly, especially when system resources are limited or overloaded, and ensuring that critical business or emergency tasks are processed in a timely manner.

In some embodiments, the preset token queue includes at least one of the placed requests, and placing the write request into the preset token queue based on the priority of the write request and the priority of the placed requests in the preset token queue includes one of the following:

In the case where the priority of at least one of the placed requests is higher than the priority of the write request, placing the write request in the preset token queue at a position after at least one of the placed requests;

In the case where the priority of at least one of the placed requests is lower than the priority of the write request, placing the write request in the preset token queue at a position before at least one of the placed requests;

When the priority of the first request is higher than the priority of the write request and the priority of the second request is lower than the priority of the write request, placing the write request in the preset token queue after the first request and before the second request;

The at least one placed request includes: the first request and the second request.

For example, if the preset token queue includes placed request A, placed request B and placed request C, and the priorities of placed request A, placed request B and placed request C are all higher than the priority of write request D, then the write request D can be placed in the preset token queue after placed request A, placed request B and placed request C to ensure that the high-priority placed request A, placed request B and placed request C can be processed first.

For example, if the preset token queue includes request A, request B and request C, and the priorities of request A, request B and request C are all lower than the priority of write request D, then the write request D can be placed in the preset token queue before request A, request B and request C to ensure that the high-priority write request D can be processed first.

For example, if the preset token queue includes placed request A and placed request B, and the priority of placed request A is higher than the priority of write request D, and the priority of placed request B is lower than the priority of write request D, then write request D can be placed in the preset token queue after placed request A and before placed request B to ensure that placed request A, write request D and placed request B are processed in order of priority.

It can be understood that the embodiment of the present application determines the position where the write request should be placed in the preset token queue based on the relationship between the priority of the write request and the priority of the requests already placed in the preset token queue, thereby ensuring that requests with higher priority can be processed more quickly, especially when system resources are limited or overloaded, and can ensure that critical business or emergency tasks are processed in a timely manner.

In some embodiments, based on the position of the write request in the preset token queue and the token associated with the preset token queue, synchronously writing the context information of the user terminal into a first hash table in the first database corresponding to the IMS and a second hash table in the second database corresponding to the electronic device includes:

In response to the information at the front position before the position in the preset token queue being empty, identifying the state of the token;

In response to the state of the token being an unused state, allocating the calling permission of the token to the write request to change the write request to a current request in an execution state;

Based on the current request, the context information is synchronously written into a first hash table in a first database corresponding to the IMS and a second hash table in a second database corresponding to the electronic device.

It should be noted that if the information at the front position before the write request position in the preset token queue is empty, it indicates that the request before the write request position in the preset token queue has been processed. At this time, the status of the token associated with the preset token queue can be identified. If the status of the token is unused, the calling authority of the token can be assigned to the write request to change the write request to a current request in the execution state, and then based on the current request, the context information of the user terminal is synchronously written into the first hash table in the first database corresponding to the IMS, and the second hash table in the second database corresponding to the electronic device.

In some embodiments, if the token is identified as being in use, indicating that the token may currently be used to process requests sent by other user terminals, after the token's state is changed from being in use to being unused, the token's calling permission can be assigned to a write request to change the write request to a current request in execution, and then based on the current request, the user terminal's context information is synchronously written into the first hash table in the first database corresponding to the IMS, and the second hash table in the second database corresponding to the electronic device.

For example, FIG. 7 is a flowchart of a fifth information processing method provided in an embodiment of the present application. As shown in FIG. 7 , the method includes:

S701: In response to receiving a write request sent by a user terminal, determine a priority of the write request.

S702: Based on the priority of the write request, put the write request into a preset token queue.

S703: In response to the information at the front position of the preset token queue before the position of the write request in the preset token queue being empty, identify the status of the token.

S704: In response to the token being in an unused state, assigning the calling permission of the token to the write request to change the write request to a current request in an execution state.

S705: Based on the current request, synchronously write the context information into a first hash table in a first database corresponding to the IMS and a second hash table in a second database corresponding to the electronic device.

It should be noted that, for the description of the same steps and the same contents in this embodiment as those in other embodiments, reference can be made to the description in other embodiments and will not be repeated here.

It can be understood that the embodiment of the present application adopts a token-preemptive synchronization mechanism, which uses tokens to ensure the orderly writing of requests, thereby ensuring that higher priority requests can be processed more quickly, especially when system resources are limited or overloaded, to ensure that critical business or emergency tasks are processed in a timely manner.

In some embodiments, the method further comprises:

In response to the context information, completing synchronous writing into the first hash table and the second hash table, and determining that the execution of the current request is completed;

In response to the current request execution being completed, the token is released, and the state of the token is updated from the used state to the unused state.

It should be noted that when a process or thread completes the task that requires a token to execute, it needs to return the token to the system, which usually happens when the task is completed, the system has an error, or resources need to be released. The process of returning the token can be implemented by calling a specific system function or method. This function or method is responsible for transferring the token from the current process or thread to the system or token pool. After the token is returned, the system needs to update the status of the token, which may include marking the token as available, updating the number of tokens, or modifying other status information related to the token.

In an embodiment of the present application, based on the current request, after the context information of the user terminal is synchronously written into the first hash table in the first database corresponding to the IMS and the second hash table in the second database corresponding to the electronic device, the synchronous writing of the first hash table and the second hash table can be completed in response to the context information, and the execution of the current request is determined to be completed. Then, in response to the execution of the current request, the token associated with the preset token queue is released, and the status of the token is updated from a used state to an unused state.

For example, FIG8 is a sixth flowchart of an information processing method provided in an embodiment of the present application. As shown in FIG8 , the method includes:

S801: In response to receiving a write request sent by a user terminal, determine a priority of the write request.

S802: Based on the priority of the write request, put the write request into a preset token queue.

S803: In response to the information at the front position of the preset token queue before the position of the write request in the preset token queue being empty, identify the status of the token.

S804: In response to the token being in an unused state, assigning the calling permission of the token to the write request to change the write request to a current request in an execution state.

S805: Based on the current request, synchronously write the context information into a first hash table in a first database corresponding to the IMS and a second hash table in a second database corresponding to the electronic device.

S806: In response to the context information, complete synchronous writing into the first hash table and the second hash table, and determine that the execution of the current request is completed.

S807: In response to the completion of the execution of the current request, release the token, and update the status of the token from the used status to the unused status.

It should be noted that, for the description of the same steps and the same contents in this embodiment as those in other embodiments, reference can be made to the description in other embodiments and will not be repeated here.

It can be understood that the embodiment of the present application uses and releases the token so that other waiting requests can obtain the token and execute it, thereby improving the throughput and response speed of the system.

In some embodiments, the method further comprises:

In response to the completion of initialization of the first hash table, the information in the first hash table is exported to the initial second database to obtain the second database having the second hash table.

In an embodiment of the present application, after the first hash table is initialized, the information in the first hash table can be exported to an initial second database, thereby obtaining a second database with a second hash table, so that the data in the first database is consistent with the data in the second database.

In some embodiments, when there are multiple first hash tables in the first database, the first identifiers corresponding to each first hash table can be determined, and the first identifiers corresponding to each first hash table can be used as keys (Key) in the second hash table, and the contents of each first hash table can be used as values (Value) corresponding to the keys (Key) in the second hash table.

It should be noted that there are 7 first hash tables involving user context information in the IMS system, namely: Proxy Call Session Control Function registrar (P-CSCF registrar), Proxy Call Session Control Function session subscription (P-CSCF subscription dialogs), Serving Call Session Control Function authentication (S-CSCF authentication), Serving Call Session Control Function registration (S-CSCF registrar), Serving Call Session Control Function session (S-CSCF dialogs), Interrogating Call Session Control Function lists (I-CSCF lists) I-CSCF lists. These 7 first hash tables store information about P-CSCF registration, session subscription, S-CSCF authentication, registration, session, and I-CSCF list, respectively. The information in these 7 first hash tables can be exported and written into the initial second database.

For example, FIG9 is a schematic diagram of mapping some parameters of r_contact in P-CSCF to Redis memory database provided by an embodiment of the present application. As shown in FIG9 , the key in the hash table written into the Redis memory database is obtained by disassembling each hash table variable in the IMS system. The data writing process may include:

1. The IMS system connects to the Redis database;

2. Determine whether there are any services that need to be processed, such as user registration and session update;

3. If it is determined that there are services that need to be processed, such as user registration and session update, each CSCF processes the service information, parses the parameters to be written, and passes the parsed data packets to the token queue. This token queue is used to temporarily store the data to be written to the Redis database so that it can be written in sequence later.

4. Loop through the data packets in the token queue, and for each data packet in the token queue, call the token preemption write mechanism to implement the IMS system writing to the Redis database;

5. End the loop and process: When all the data packets in the token queue have been processed (that is, all the data packets that need to be written to the Redis database have been written), the loop ends.

It is understandable that by writing the data in the IMS corresponding database into the Redis database, data hot backup can be achieved. Redis sentinel is a high availability solution for Redis, ensuring the stability and reliability of the Redis service.

Exemplarily, FIG10 is a schematic diagram of a distributed system architecture provided by an embodiment of the present application. As shown in FIG10, two resource nodes node1 and node2 are included, and on the basis of the original sentinel mode, a monitoring module monitor is added to the deployment unit pod in each resource node, which is responsible for monitoring the detection status of the cluster by the sentinel. If the peer node is found to be in subjective state or the customer is offline, the Redis instance of the current pod will be triggered to upgrade to the main database. The number of Redis instance groups of the two pods is consistent, one for caching (Redis-ha) and the other for persistence scenarios (Redis-ha-for-persist). Among them, NF is a network service for processing network requests and data transmission, and sideCar is a service container for enhancing or expanding the functions of the main service, such as log collection, monitoring, and security.

In some embodiments, the Append Only File (AOF) function can be enabled in the Redis configuration file (disabled by default), and the AOF file name for local storage can be specified, and the always configuration policy can be used to ensure that data is synchronized to the disk to avoid loss of business configuration. The configuration information may include:

appendonly: Redis persistence mode. To enable AOF, you need to change it to yes.

appendfilename: AOF file name; backupIMS.aof;

appendfsync: Configuration of AOF persistence strategy; fsync.

It should be noted that no means that fsync is not executed, and the operating system ensures that data is synchronized to the disk. It has the fastest speed, but low security. always means that fsync is executed every time a write is made to ensure that data is synchronized to the disk. It has high reliability but low efficiency. everysec means that fsync is executed once per second, which may result in the loss of 1 second of data. Everysec is usually selected to balance security and efficiency.

It is understandable that the Redis master (i.e., the Redis master database) in FIG10 can be used to process real-time data, while the Redis standby (i.e., the Redis standby database) is a backup of the master database and can be used to take over the service when the Redis master fails, effectively realizing data hot backup and ensuring data continuity and availability. In addition, the embodiments of the present application can at least bring the following beneficial effects: maximize the use of the existing 5GC high-availability framework, with minimal work; only involve the modification of IMS, with strong portability, suitable for cloud deployment and all-in-one deployment scenarios; fast fault recovery, which can achieve fault recovery in seconds.

The information processing device provided in the embodiment of the present application is described below. The information processing device described below and the information processing method described above can be referenced to each other.

FIG11 is a schematic diagram of the structure of an information processing device provided in an embodiment of the present application, and the device is applied to an electronic device deployed with an Internet Protocol IP Multimedia Subsystem IMS. As shown in FIG11 , the device includes: a determination unit 1110, a placing unit 1120, and a writing unit 1130; wherein:

The determining unit 1110 is configured to determine the priority of the write request in response to receiving the write request sent by the user terminal;

The placing unit 1120 is configured to place the write request into a preset token queue based on the priority of the write request;

The writing unit 1130 is configured to synchronously write the context information of the user terminal into a first hash table in the first database corresponding to the IMS and a second hash table in the second database corresponding to the electronic device based on the position of the write request in the preset token queue and the token associated with the preset token queue.

The information processing device provided in the embodiment of the present application, in response to receiving a write request sent by a user terminal, first determines the priority of the write request, and then, based on the priority, puts the write request into a preset token queue, and then, based on the position of the write request in the preset token queue and the token associated with the preset token queue, synchronously writes the context information of the user terminal into a first hash table in a first database corresponding to the IMS and a second hash table in a second database corresponding to the electronic device. In this way, by introducing priority processing and a token queue mechanism, not only the controllability and efficiency of the data writing process are improved, but also the consistency and synchronization of the data in the first database corresponding to the IMS and the data in the second database corresponding to the electronic device can be effectively ensured.

In some embodiments, the determination unit 1110 is further configured to: in response to receiving the write request, obtain a message type and an expiration time corresponding to the write request; and determine the priority based on the message type and the expiration time.

In some embodiments, the determination unit 1110 is further configured to: fuzzify the message type and the expiration time to obtain a first value corresponding to the message type and a second value corresponding to the expiration time; and use a central average method to calculate the first value, the first weight corresponding to the message type, the second value, and the second weight corresponding to the expiration time to obtain the priority.

In some embodiments, the placement unit 1120 is further configured to: when the preset token queue is empty, place the write request at any position in the preset token queue; when the preset token queue is not empty, place the write request into the preset token queue based on the priority of the write request and the priority of the requests already placed in the preset token queue.

In some embodiments, the preset token queue includes at least one of the placed requests, and the placement unit 1120 is further configured as one of the following: when the priority of at least one of the placed requests is higher than the priority of the write request, the write request is placed in the preset token queue at a position after at least one of the placed requests; when the priority of at least one of the placed requests is lower than the priority of the write request, the write request is placed in the preset token queue at a position before at least one of the placed requests; when the priority of a first request is higher than the priority of the write request and the priority of a second request is lower than the priority of the write request, the write request is placed in the preset token queue at a position after the first request and before the second request; wherein the at least one placed request includes: the first request and the second request.

In some embodiments, the write unit 1130 is further configured to: in response to the information at the front position before the position in the preset token queue being empty, identify the state of the token; in response to the state of the token being unused, assign the calling authority of the token to the write request to change the write request to a current request in an execution state; based on the current request, synchronously write the context information to the first hash table in the first database corresponding to the IMS, and to the second hash table in the second database corresponding to the electronic device.

In some embodiments, the apparatus further comprises:

The release unit is configured to complete the synchronous writing of the first hash table and the second hash table in response to the context information, determine that the current request execution is completed; in response to the completion of the current request execution, release the token and update the state of the token from the used state to the unused state.

In some embodiments, the apparatus further comprises:

The export unit is configured to export the information in the first hash table to an initial second database in response to the completion of initialization of the first hash table, so as to obtain the second database having the second hash table.

It should be noted here that the above-mentioned information processing device provided in the embodiment of the present application can implement all the method steps implemented in the above-mentioned information processing method embodiment, and can achieve the same technical effect. The parts and beneficial effects of this embodiment that are the same as those in the method embodiment will not be described in detail here.

FIG12 is a schematic diagram of the physical structure of an electronic device provided by an embodiment of the present application and equipped with an Internet Multimedia Subsystem (IMS) of an Internet Protocol (IP). As shown in FIG12 , the electronic device may include: a processor (processor) 1210, a communications interface (Communications Interface) 1220, a memory (memory) 1230, and a communication bus 1240, wherein the processor 1210, the communications interface 1220, and the memory 1230 communicate with each other through the communication bus 1240. The processor 1210 may call executable data instructions stored in the memory 1230 to execute some or all of the steps in the information processing methods provided by the above embodiments.

In addition, the executable data instructions stored in the above-mentioned memory 1230 can be implemented in the form of a software functional unit and can be stored in a computer-readable storage medium when it is sold or used as an independent product. Based on this understanding, the technical solution of the embodiment of the present application can be essentially or partly reflected in the form of a software product that contributes to the relevant technology. The software product is stored in a storage medium, including several instructions to enable a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc. Various media that can store program codes.

An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, part or all of the steps in the information processing method provided in the above embodiments are implemented.

An embodiment of the present application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium, and the computer program includes program instructions. When the program instructions are executed by a computer, the computer can execute some or all of the steps in the information processing method provided in the above embodiments.

The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Those of ordinary skill in the art may understand and implement it without creative work.

Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the embodiments of the present application may adopt the form of hardware embodiments, software embodiments, or embodiments in combination with software and hardware. Moreover, the embodiments of the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage and optical storage, etc.) that contain computer-usable program code.

The present application embodiment is described with reference to the flowchart and/or block diagram of the method, device (system) and computer program product according to the present application embodiment. It should be understood that each flow process and/or box in the flow chart and/or block diagram and the combination of the flow chart and/or box in the flow chart and/or block diagram can be realized by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processing machine or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for realizing the function specified in one flow chart or multiple flows and/or one box or multiple boxes of the block chart.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device that implements the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

These computer program instructions may also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

The above description is merely an optional embodiment of the present application and is not intended to limit the protection scope of the present application.

Claims (10)

1. An information processing method applied to an electronic device deployed with an internet protocol, IP, multimedia subsystem, IMS, the method comprising:

Determining the priority of a writing request sent by a user terminal in response to receiving the writing request;

Based on the priority of the writing request, placing the writing request into a preset token queue;

Based on the position of the writing request in the preset token queue and the token associated with the preset token queue, the context information of the user terminal is synchronously written into a first hash table in a first database corresponding to the IMS and a second hash table in a second database corresponding to the electronic equipment.

2. The method of claim 1, the determining the priority of the write request in response to receiving the write request sent by the user terminal, comprising:

Responding to the received writing request, and acquiring a message type and expiration time corresponding to the writing request;

And determining the priority based on the message type and the expiration time.

3. The method of claim 2, the determining the priority based on the message type and the expiration time, comprising:

Blurring the message type and the expiration time to obtain a first value corresponding to the message type and a second value corresponding to the expiration time;

And calculating the first value, the first weight corresponding to the message type, the second value and the second weight corresponding to the expiration time by adopting a center average method to obtain the priority.

4. A method according to any one of claims 1 to 3, said placing said write request into a preset token queue based on a priority of said write request, comprising:

under the condition that the preset token queue is empty, placing the writing request at any position in the preset token queue;

And under the condition that the preset token queue is not empty, placing the writing request into the preset token queue based on the priority of the writing request and the priority of the placed request in the preset token queue.

5. The method of claim 4, wherein the preset token queue includes at least one of the placed requests, and wherein the placing the write request into the preset token queue based on the priority of the write request and the priority of the placed request in the preset token queue includes one of:

Placing the write request in the preset token queue at a position after at least one placed request under the condition that the priority of at least one placed request is higher than the priority of the write request;

Placing the write request in the preset token queue at a position before at least one placed request under the condition that the priority of at least one placed request is lower than the priority of the write request;

Placing the write request in the preset token queue at a position after the first request and before the second request under the condition that the priority of the first request is higher than the priority of the write request and the priority of the second request is lower than the priority of the write request;

wherein said at least one said placed request comprises said first request and said second request.

6. The method of claim 1, the synchronously writing context information of the user terminal to a first hash table in the first database corresponding to the IMS and a second hash table in the second database corresponding to the electronic device based on a location of the write request in the preset token queue and a token associated with the preset token queue, comprising:

Identifying the state of the token in response to the information on the front end position, which is positioned in front of the position, in the preset token queue being empty;

Responsive to the state of the token being an unused state, assigning call rights of the token to the write request to change the write request to a current request in an executing state;

Based on the current request, the context information is synchronously written into a first hash table in a first database corresponding to the IMS and a second hash table in a second database corresponding to the electronic equipment.

7. The method of claim 6, the method further comprising:

Responsive to the context information, completing synchronous writing into the first hash table and the second hash table, and determining that the current request execution is finished;

And releasing the token and updating the state of the token from the used state to the unused state in response to the end of the execution of the current request.

8. The method of claim 6 or 7, the method further comprising:

And in response to the first hash table completing initialization, exporting information in the first hash table to an initial second database to obtain the second database with the second hash table.

9. An information processing apparatus for application to an electronic device deployed with an internet protocol, IP, multimedia subsystem, IMS, the apparatus comprising:

A determining unit configured to determine a priority of a write request sent by a user terminal in response to receiving the write request;

a placing unit configured to place the write request into a preset token queue based on a priority of the write request;

And the writing unit is configured to synchronously write the context information of the user terminal into a first hash table in the first database corresponding to the IMS and a second hash table in the second database corresponding to the electronic equipment based on the position of the writing request in the preset token queue and the token associated with the preset token queue.

10. A computer-readable storage medium having stored thereon computer-executable instructions that, when executed, are capable of implementing the information processing method of any of claims 1 to 8.