5g new call adaptation method, system, device and medium compatible with multi-chip platform

Abstract

The application relates to the technical field of communication services, in particular to a 5G new call adaptation method, system and device compatible with a multi-chip platform and a medium. The method comprises the following steps: acquiring an IMS data channel request initiated by a user application layer through an AIDL interface; identifying a chip platform according to predefined IMS data channel information through a JNI reflection mechanism to obtain a chip platform type; loading a configuration file of the chip platform according to the chip platform type to obtain IMS data channel configuration parameters of whether to support native creation; obtaining an adaptation strategy according to the IMS data channel configuration parameters and the IMS data channel request; creating an IMS data channel according to the adaptation strategy; and feeding back data of the IMS data channel to the user application layer through the AIDL interface. The method can be flexibly connected to terminals of different manufacturers, models and chips.

Description

Technical Field

[0001] This application relates to the field of communication service technology, and in particular to a 5G new call adaptation method, system, device and medium compatible with multi-chip platforms. Background Technology

[0002] 5G New Voice refers to a series of services that enhance the user experience for individuals and businesses through system enhancements and business innovations based on the operator's IMS network. 5G New Voice upgrades the interactive information delivery and interaction experience for users during calls. The 5G New Voice network architecture adds newly introduced network elements to the IMS network architecture defined in 3GPP TS26.114 R18, while also requiring upgrades to existing IMS network elements to support new functions such as data channels and third-party ID access. This enables various new services in 5G New Voice and requires support from terminal and chip manufacturers. The chip provides IMSDC channel capabilities, and terminal manufacturers need to adapt these capabilities to manage and transmit data through the IMSDC channel. However, 5G New Voice is still in its development stage, and the IMSDC interfaces and implementation capabilities provided by different chip manufacturers vary, requiring terminal manufacturers to adapt them individually for each chip.

[0003] In summary, the technical problems existing in the relevant technologies need to be improved. Summary of the Invention

[0004] The main objective of this application is to propose a 5G new call adaptation method, system, device, and medium that is compatible with multiple chip platforms, and can flexibly connect to terminals from different manufacturers, models, and chips.

[0005] To achieve the above objectives, one aspect of this application proposes a 5G new call adaptation method compatible with multi-chip platforms, the method comprising:

[0006] Obtain the IMS data channel request initiated by the user application layer through the AIDL interface;

[0007] The chip platform type is obtained by identifying the chip platform based on predefined IMS data channel information using the JNI reflection mechanism.

[0008] Load the configuration file of the chip platform according to the chip platform type to obtain the configuration parameters for whether natively created IMS data channels are supported;

[0009] Based on the IMS data channel configuration parameters and the IMS data channel request, an adaptation strategy is obtained;

[0010] Create an IMS data channel according to the adaptation strategy;

[0011] The AIDL interface is used to feed back the data from the IMS data channel to the user application layer.

[0012] In some embodiments, the IMS data channel information includes the IMS data channel service name and the IMS data channel interface name;

[0013] The data in the IMS data channel includes the creation result of the IMS data channel, the status information of the IMS data channel, the data received by the IMS data channel, and the status of the data sent by the IMS data channel.

[0014] In some embodiments, identifying the chip platform type by means of JNI reflection mechanism based on predefined IMS data channel information includes the following steps:

[0015] The interface implementation classes are traversed using the JNI reflection mechanism.

[0016] Match the interface implementation method in the interface implementation class based on the IMS data channel information;

[0017] The chip platform type is determined by judging the call result or exception type of the interface implementation method.

[0018] In some embodiments, the configuration file includes hardware capability parameters and interface call specifications;

[0019] The interface call specification includes the underlying protocol type and supported identifiers;

[0020] The underlying protocol type is a combined protocol stack of SCTPoverDTLSoverUDP, where DTLS is a TLS encryption of UDP; the support identifiers include support identifiers for DTLS encryption mode or support identifiers for multi-stream transmission function.

[0021] In some embodiments, creating an IMS data channel according to the adaptation strategy includes:

[0022] When native creation is supported, the IMS data channel is created through a chip adaptation strategy;

[0023] When native creation is not supported, the IMS data channel is created through a software simulation strategy.

[0024] In some embodiments, when native creation is supported, creating the IMS data channel through a chip adaptation strategy includes the following steps:

[0025] A virtual IMS data channel is created as an interface proxy layer for the chip platform;

[0026] The native interface provided by the chip platform is invoked through the JNI reflection mechanism.

[0027] The virtual IMS data channel converts the chip platform's proprietary interface into a unified, standardized interface.

[0028] In some embodiments, when native creation is not supported, creating the IMS data channel through a software simulation strategy includes the following steps:

[0029] Dynamically load the protocol stack library in user space;

[0030] A logical channel is constructed based on the request type of the IMS data channel request to obtain the IMS data channel.

[0031] To achieve the above objectives, another aspect of this application proposes a 5G new call adaptation system compatible with multi-chip platforms, the system comprising:

[0032] The first module is used to obtain the IMS data channel request initiated by the user application layer through the AIDL interface;

[0033] The second module is used to identify the chip platform based on predefined IMS data channel information through the JNI reflection mechanism to obtain the chip platform type.

[0034] The third module is used to load the configuration file of the chip platform according to the chip platform type to obtain the configuration parameters of whether natively created IMS data channels are supported.

[0035] The fourth module is used to obtain an adaptation strategy based on the IMS data channel configuration parameters and the IMS data channel request.

[0036] The fifth module is used to create an IMS data channel according to the adaptation strategy;

[0037] The sixth module is used to feed back the data from the IMS data channel to the user application layer through the AIDL interface.

[0038] To achieve the above objectives, one aspect of this application provides a computer apparatus, comprising:

[0039] At least one processor;

[0040] At least one memory for storing at least one program;

[0041] When the at least one program is executed by the at least one processor, the at least one processor performs the method described above.

[0042] To achieve the above objectives, one aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned method.

[0043] The embodiments of this application include at least the following beneficial effects: This application provides a 5G new voice adaptation method, system, device, and medium compatible with multiple chip platforms. This solution achieves standardized cross-process communication between the user application layer and the backend service through the AIDL interface, ensuring efficient and stable data transmission. It dynamically identifies the chip platform type using the JNI reflection mechanism and loads corresponding parameters in the configuration file, achieving automatic adaptation to different chip platforms. Based on whether the chip platform supports native creation, it flexibly adopts software simulation strategies or chip platform adaptation strategies. When the chip platform does not support it, it simulates the channel function through the user space protocol stack; when the chip platform supports it, it calls the native interface through a virtual channel proxy, shielding the differences in chip platform interfaces. The entire process achieves fully automated processing from request initiation, chip platform identification, policy decision-making to channel creation, improving the compatibility and adaptation efficiency of the 5G new voice system to multiple chip platforms and reducing development and maintenance costs. Attached Figure Description

[0044] Figure 1 This is a flowchart of a 5G new call adaptation method compatible with multi-chip platforms provided in an embodiment of this application;

[0045] Figure 2 yes Figure 1 The flowchart of step S200 in the middle;

[0046] Figure 3 yes Figure 1 The flowchart of step S500 in the middle;

[0047] Figure 4 This is a schematic diagram of a 5G new call adaptation system compatible with multi-chip platforms provided in an embodiment of this application. Detailed Implementation

[0048] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application.

[0049] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various concepts, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words “if,” “when,” or “in response to a determination” as used herein may be interpreted as “when…” or “when…” or “in response to a determination.”

[0050] As used in this application, the terms "at least one", "multiple", "each", "any", etc., "at least one" includes one, two or more, "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the multiples.

[0051] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0052] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0053] SCTP: Stream Control Transport Protocol, which provides connection-oriented, multi-stream reliable transmission, is suitable for real-time communication, and supports multi-homing and message framing;

[0054] DTLS: Datagram Transport Layer Security, provides encryption and authentication for connectionless protocols such as UDP, ensuring secure data transmission.

[0055] UDP: User Datagram Protocol, connectionless, lightweight, high transmission efficiency but unreliable;

[0056] IMS network: A multimedia subsystem provided by operators that supports the integration of multimedia services such as voice and video;

[0057] JNI reflection mechanism: a reflection technology for native interfaces that allows code to dynamically call native code and resources at runtime;

[0058] IMS data channel: The logical channel for transmitting multimedia data in the IMS network;

[0059] AIDL Interface: Android Interface Definition Language, used to implement cross-process communication, allowing secure and efficient interaction between different application components;

[0060] TLS encryption: Transport Layer Security protocol encryption is used to encrypt data during network transmission to ensure the confidentiality, integrity, and authentication of data between communicating parties, and to prevent data from being stolen or tampered with.

[0061] Application type: It is based on WebRTC data channel technology and uses a channel with SCTP stream ID starting from 1000, which is used for data transmission for new 5G calling applications;

[0062] Bootstrap type: Based on WebRTC data channel technology, it uses reserved channels with SCTP stream ID less than 1000, and channels with IDs of 0 and 100 in 5G new calls, used to initialize 5G new call applications.

[0063] Figure 1 This is an optional flowchart of the 5G new call adaptation method compatible with multi-chip platforms provided in the embodiments of this application. Figure 1 The method may include, but is not limited to, steps S100 to S600.

[0064] Step S100: Obtain the IMS data channel request initiated by the user application layer through the AIDL interface;

[0065] Step S200: Identify the chip platform based on the predefined IMS data channel information using the JNI reflection mechanism to obtain the chip platform type;

[0066] Step S300: Load the chip platform's configuration file according to the chip platform type to obtain the configuration parameters for whether natively created IMS data channels are supported;

[0067] Step S400: Obtain the adaptation strategy based on the IMS data channel configuration parameters and the IMS data channel request;

[0068] Step S500: Create an IMS data channel according to the adaptation strategy;

[0069] Step S600: Feed back the data from the IMS data channel to the user application layer through the AIDL interface.

[0070] Specifically, the user application layer initiates an IMS data channel request to the backend service through the AIDL interface. The backend service, using JNI reflection, dynamically identifies the chip platform type of the current device based on predefined service and interface names. Based on this type, it loads the corresponding configuration file to obtain the configuration parameters for whether the chip platform supports native IMS data channel creation. Combining the configuration parameters and the user request, the data channel management unit determines the adaptation strategy: if native creation is supported, a virtual channel proxy layer is created, calling the chip platform's native interface to implement the function; if not, a protocol stack library is dynamically loaded in user space to simulate the channel function through software. Finally, the created channel feeds back its status information and data to the user application layer through the AIDL interface, forming a complete closed loop and achieving cross-chip platform 5G new call adaptation, effectively masking hardware differences.

[0071] In some embodiments, in step S100, the user application layer sends a request to the backend service to create an IMS data channel through the AIDL interface. The request includes the channel type, channel name, and channel transmission sub-protocol. The AIDL interface acts as a cross-process communication bridge, passing the request from the user application layer to the IMS data channel management module, ensuring standardized and efficient transmission of the request. The user application layer includes applications such as call captions, intelligent translation, multi-screen interaction, or intelligent customer service voice calls; the channel type includes application type and bootstrap type. The channel transmission sub-protocol refers to the data encapsulation protocol used for data transmission within the channel, such as HTTP, or a custom data encapsulation protocol.

[0072] In some embodiments, in step S200, such as Figure 2 As shown, Figure 2 yes Figure 1 The flowchart for step S200 is provided. The steps in step S200 include, but are not limited to, steps S210 to S230.

[0073] Step S210: Traverse the interface implementation classes using JNI reflection;

[0074] Step S220: Implement the interface method in the class based on the IMS data channel information matching interface;

[0075] Step S230: Determine the chip platform type based on the call result or exception type of the interface implementation method.

[0076] Specifically, in steps S210 to S230, when the chip platform type identification process is initiated via the JNI reflection mechanism, JNI technology is first used to break through the call boundary between the Java layer and the Native layer, dynamically traversing all loaded interface implementation classes in the process at runtime. These classes are typically provided by the chip platform manufacturer and encapsulate the implementation logic of specific hardware functions. During the traversal, based on predefined IMS data channel information, the interface implementation methods related to the IMS data channel are precisely matched in the interface implementation classes. Subsequently, these methods are attempted to be called via reflection, and the execution results or exception types are captured. Interface implementations differ across chip platforms; successful calls to specific methods may return manufacturer characteristic values, while exceptions thrown upon failure can indirectly reflect the chip platform type. Through a predefined set of matching rules, these call results or exception types are mapped to specific chip platform types, thereby completing the dynamic identification of the chip platform and providing a foundation for subsequent loading of adaptation configurations. The predefined IMS data channel information includes the IMS data channel service name and the IMS data channel interface name. The interface implementation method refers to the specific functional implementation code written by the chip platform manufacturer or developer in the interface implementation class for the IMS data channel function. These methods are based on the characteristics of the chip platform and encapsulate the underlying hardware operation logic, such as core functions like channel creation or data transmission and reception.

[0077] In some embodiments, in step S300, after determining the chip platform type, the configuration file of the corresponding vendor is loaded from a preset configuration directory. These configuration files are predefined by the chip platform vendor or device manufacturer and include hardware capability parameters and interface call specifications. The hardware capability parameters include the cipher suites supported by DTLS, the maximum number of media supported by the DC protocol stack, the maximum number of channels, the SCTP port range, and the SCTP transmission buffer size; the interface call specifications include the underlying protocol type and support identifiers. The underlying protocol type is a combined protocol stack of SCTP over DTLS over UDP. In SCTP over DTLS, DTLS is TLS encryption of UDP. The support identifiers include support identifiers for DTLS encryption modes or support identifiers for multi-stream transmission functions.

[0078] Specifically, after determining the chip platform type, the corresponding manufacturer's configuration file is loaded from the preset configuration directory. This file is predefined by the chip manufacturer or equipment manufacturer. The hardware capability parameters in the file are tailored to the actual needs of 5G new calls: DTLS supports encryption suites including empty encryption and standard encryption modes. Empty encryption is equivalent to no encryption, and encryption can be selected as needed; SCTP port range limits the port interval for channel communication to avoid port conflicts; SCTP transmission buffer size affects the buffer capacity for data transmission and reception, and is related to transmission efficiency and stability. These parameters, combined with the characteristics of the SCTPoverDTLSoverUDP combined protocol stack, provide key basis for the adaptation strategy, ensuring that chip capabilities match protocol requirements and achieving efficient compatibility across multiple chip platforms. In the SCTPoverDTLSoverUDP combined protocol stack, UDP serves as the basic transport protocol, providing lightweight datagram services; DTLS performs TLS encryption on UDP data to ensure data transmission security, and DTLS can achieve unencrypted transmission in scenarios with lower security requirements or special scenarios, improving transmission efficiency or facilitating debugging; SCTP is built on top of DTLS and is responsible for implementing multi-stream transmission and reliable connection functions. The support identifiers in the configuration file specify the chip's support for multi-stream transmission and DTLS encryption. This allows the system to select appropriate protocol configuration parameters based on the chip platform type and user requests, using either chip adaptation or software emulation strategies. This ensures efficient and secure 5G new-mode calling services across different chips, ultimately achieving multi-chip compatibility. In 5G new-mode calling, the IMS data channel, through a combined SCTPoverDTLSoverUDP protocol stack, achieves reliable data transmission and secure encryption, serving as the direct carrier of the transmission protocol. Simultaneously, by identifying chip capabilities through the configuration file, dynamically switching adaptation strategies, and standardizing chip-specific interfaces, compatibility with different chip platforms is achieved, acting as a bridge to mask hardware differences.

[0079] In some embodiments, in step S400, after obtaining the configuration parameters for whether the chip platform supports native IMS data channel creation, a multi-dimensional strategy decision is made based on the content of the user-initiated IMS data channel request, such as channel type, service quality requirements, or security level. If the configuration parameters indicate that the chip platform supports native creation and the requested functionalities are within the chip platform's capabilities, the "chip adaptation strategy" will be selected, achieving efficient channel creation by calling the chip platform's native interface. Conversely, if the chip platform does not support native creation or the requested functionality exceeds the chip platform's capabilities, such as requiring a DTLS version that the hardware does not support, the "software simulation strategy" will be activated, dynamically loading the protocol stack library in user space to simulate channel functionality in pure software. Performance optimization factors will also be considered during the decision-making process. For example, if the chip platform's native interface has known compatibility issues, even if native creation is supported, the software simulation strategy may be used as a fallback to ensure stability. The final generated adaptation strategy clarifies the technical path for channel creation, providing an execution basis for subsequent steps.

[0080] In some embodiments, such as Figure 3 As shown, Figure 3 yes Figure 1 Flowchart of step S500 in the middle section. Figure 1 Step S500 includes, but is not limited to, steps S510 to S520:

[0081] Step S510: When native creation is supported, an IMS data channel is created through a chip adaptation strategy;

[0082] Step S520: When native creation is not supported, an IMS data channel is created through a software simulation strategy.

[0083] Specifically, in steps S510 to S520, after determining the adaptation strategy, differentiated channel creation logic is executed based on whether the chip platform supports native creation of IMS data channels. If the chip platform supports native creation, the chip adaptation strategy is used. If the chip platform does not support native creation, the software simulation strategy is enabled.

[0084] When creating an IMS data channel using a chip-adaptive strategy, a virtual IMS data channel is first created in user space as a proxy layer for the chip platform interface, acting as an intermediate conversion layer. Through JNI reflection, the native interface library provided by the chip platform vendor is dynamically loaded, converting standardized channel creation requests into chip platform-specific instruction formats and calling the chip platform's native interface to initialize the physical channel. During data flow, the virtual channel continuously monitors the chip platform interface status, parsing the private status codes returned by the chip platform into a unified standardized status. Simultaneously, it maps general operation instructions from upper-layer applications to low-level calls recognizable by the chip platform. This achieves standardized encapsulation of private interfaces from different chip platforms, allowing upper-layer applications to manage channels and transmit data through a unified interface without needing to be aware of the specific chip platform model, effectively shielding the heterogeneity differences between chip platforms.

[0085] When creating an IMS data channel using a software simulation strategy, a pre-compiled protocol stack library is first dynamically loaded in user space. These libraries are independent of the chip platform's native interfaces and implement the protocol logic purely in software. After loading, based on the type of IMS data channel request initiated by the user, corresponding protocol components with the appropriate functions are instantiated from the protocol stack library, such as the SCTP flow controller and DTLS encryption module, and their behavior is configured according to the parameters in the request. Subsequently, a logical channel is built in memory using these components. This channel simulates the functions of a real hardware channel, including mechanisms for data segmentation, reliable transmission, and error recovery. For example, for file transfer requests with high reliability requirements, SCTP's multi-stream features and retransmission mechanisms are enabled. Ultimately, these protocol components work together to form a complete IMS data channel, implemented entirely in user space without relying on the chip platform's native capabilities, ensuring consistent 5G new voice services can still be provided even on chip platforms that do not support native creation.

[0086] In some embodiments, in step S600, after the creation and initialization of the IMS data channel are completed, the channel data is fed back to the user application layer through the AIDL interface. During this process, the IMS data channel data in the feedback includes: the creation result of the IMS data channel, presented as a Boolean value combined with a status code, such as "SUCCESS" or "ERROR_CHIP_INCOMPATIBLE," explicitly indicating whether the channel was successfully established; IMS data channel status information, including real-time connection status, such as "CONNECTED" or "DISCONNECTED"; transmission performance indicators, such as current bandwidth, packet loss rate, etc.; and quality of service parameters, including latency or jitter. In addition, the IMS data channel data also includes the status of data received and data sent by the IMS data channel. The AIDL interface encapsulates this data into a cross-process transmittable Parcelable object and transmits it to the user application layer through the Binder mechanism. After receiving the feedback, the user application layer updates the UI display based on this feedback, such as displaying a "channel interrupted" or "poor network quality" message, and triggers corresponding business logic, such as automatically re-establishing the channel or reducing the business data transmission rate. The entire feedback process is implemented through AIDL's asynchronous callback mechanism, ensuring that changes in state can be notified to the user in real time, forming a complete closed loop from request to response, and improving the interactive experience and reliability of 5G new calls.

[0087] In some embodiments, the 5G new call adaptation method compatible with multiple chip platforms includes a UI layer, an AIDL layer, a configuration unit, and a data channel management unit. The UI layer is a call application, modified from a traditional call application, supporting 5G new calls based on IMSDC. The AIDL layer provides AIDL-style interfaces to the UI layer for the 5G new call protocol stack. The UI module calls the AIDL interfaces of the 5G new call backend service, invoking interfaces for creating IMS data channels, monitoring the status of IMS data channels, and sending and receiving data through the IMS data channels. The configuration unit is used to obtain relevant configuration parameters of the chip platform, mainly including whether the chip platform supports the creation of IMS data channels.

[0088] For the data channel management unit, when the chip platform does not support IMS data channel creation, it is used to implement the IMS data channel protocol, enabling functions such as IMS data channel creation, management, sending user data, and receiving data from the server. Specifically, when the chip platform does not support IMS data channels, this solution implements the IMS data channel protocol. The protocol is based on a modified Google WebRTC library, generating relevant data channel parameters, including port and TLS-ID, and then interfacing with the chip platform. The chip platform implements SIP signaling negotiation, including port, IP, data channel type, name, and QoS, obtaining the other party's data channel parameters and sending its own. This solution obtains or sets these parameters through the chip platform's interface, and then performs data channel creation and management. When the chip platform supports IMS data channel creation, a virtual IMS data channel is created and interfacing with the chip platform. Functions such as IMS data channel creation, management, and data transmission / reception are implemented by calling the chip platform's interface, thus masking the differences between chip platforms.

[0089] In some embodiments, the 5G new call adaptation method compatible with multiple chip platforms includes: since the IMS data channel service names and interfaces of various chip platforms are different, different chip platforms are identified through JNI reflection mechanism based on the service name and interface name of the IMS data channel; the corresponding configuration file is loaded according to the chip platform to obtain the type of the IMS data channel, where the type indicates whether it is created by the chip platform, and an instance of the IMS data channel management layer for the corresponding chip platform is created; when the chip platform does not support IMS data channel creation, the protocol for implementing the IMS data channel is used to implement functions such as IMS data channel creation, management, sending user data, and receiving data sent from the server; when the chip platform supports IMS data channel creation, a virtual IMS data channel is created to interface with the chip platform, and the functions of IMS data channel creation, management, and data transmission and reception are implemented by calling the chip platform interface, thereby shielding the differences between chip platforms.

[0090] In some embodiments, such as Figure 4 As shown, Figure 4 This is a schematic diagram of a 5G new voice adaptation system compatible with multiple chip platforms. The system includes:

[0091] The first module is used to obtain IMS data channel requests initiated by the user application layer through the AIDL interface;

[0092] The second module is used to identify the chip platform based on predefined IMS data channel information through the JNI reflection mechanism, and obtain the chip platform type.

[0093] The third module is used to load the chip platform's configuration file according to the chip platform type to obtain whether the natively created IMS data channel configuration parameters are supported.

[0094] The fourth module is used to obtain the adaptation strategy based on the IMS data channel configuration parameters and IMS data channel requests.

[0095] The fifth module is used to create IMS data channels according to the adaptation strategy;

[0096] The sixth module is used to feed back data from the IMS data channel to the user application layer via the AIDL interface.

[0097] It is understood that the content of the above method embodiments is applicable to this system embodiment. The specific functions implemented in this system embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0098] This application also provides a computer processing device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described 5G new call adaptation method compatible with multiple chip platforms. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0099] It is understood that the content of the above method embodiments is applicable to the present device embodiments. The specific functions implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0100] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described 5G new call adaptation method compatible with multiple chip platforms.

[0101] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0102] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0103] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0104] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0105] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0106] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0107] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0108] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0109] The integrated unit can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0110] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A 5G new call adaptation method compatible with multiple chip platforms, characterized in that, The method includes: Obtain the IMS data channel request initiated by the user application layer through the AIDL interface; The chip platform type is obtained by identifying the chip platform based on predefined IMS data channel information using the JNI reflection mechanism. The configuration file of the chip platform is loaded according to the chip platform type to obtain the IMS data channel configuration parameters; the IMS data channel configuration parameters are used to characterize whether the chip platform supports native creation of IMS data channels; Based on the IMS data channel configuration parameters and the IMS data channel request, an adaptation strategy is obtained; Create an IMS data channel according to the adaptation strategy; The AIDL interface is used to feed back the data from the IMS data channel to the user application layer.

2. The method according to claim 1, characterized in that, The IMS data channel information includes the IMS data channel service name and the IMS data channel interface name; The data in the IMS data channel includes the creation result of the IMS data channel, the status information of the IMS data channel, the data received by the IMS data channel, and the status of the data sent by the IMS data channel.

3. The method according to claim 1, characterized in that, The process of identifying the chip platform type based on predefined IMS data channel information using the JNI reflection mechanism includes the following steps: The interface implementation classes are traversed using the JNI reflection mechanism. Match the interface implementation method in the interface implementation class based on the IMS data channel information; The chip platform type is determined by judging the call result or exception type of the interface implementation method.

4. The method according to claim 1, characterized in that, The configuration file includes hardware capability parameters and interface call specifications; The interface call specification includes the underlying protocol type and supported identifiers; The underlying protocol type is a combined protocol stack of SCTPoverDTLSoverUDP, where DTLS is a TLS encryption of UDP; the support identifiers include support identifiers for DTLS encryption mode or support identifiers for multi-stream transmission function.

5. The method according to claim 1, characterized in that, The step of creating an IMS data channel according to the adaptation strategy includes: When native creation is supported, the IMS data channel is created through a chip adaptation strategy; When native creation is not supported, the IMS data channel is created through a software simulation strategy.

6. The method according to claim 5, characterized in that, When native creation is supported, the IMS data channel is created through a chip adaptation strategy, including the following steps: A virtual IMS data channel is created as an interface proxy layer for the chip platform; The native interface provided by the chip platform is invoked through the JNI reflection mechanism. The virtual IMS data channel converts the chip platform's proprietary interface into a unified, standardized interface.

7. The method according to claim 5, characterized in that, When native creation is not supported, the IMS data channel is created through a software simulation strategy, including the following steps: Dynamically load the protocol stack library in user space; A logical channel is constructed based on the request type of the IMS data channel request to obtain the IMS data channel.

8. A 5G new voice adaptation system compatible with multiple chip platforms, characterized in that, The system includes: The first module is used to obtain the IMS data channel request initiated by the user application layer through the AIDL interface; The second module is used to identify the chip platform based on predefined IMS data channel information through the JNI reflection mechanism, and obtain the chip platform type. The third module is used to load the configuration file of the chip platform according to the chip platform type to obtain IMS data channel configuration parameters; the IMS data channel configuration parameters are used to characterize whether the chip platform supports native creation of IMS data channels; The fourth module is used to obtain an adaptation strategy based on the IMS data channel configuration parameters and the IMS data channel request. The fifth module is used to create an IMS data channel according to the adaptation strategy; The sixth module is used to feed back the data from the IMS data channel to the user application layer through the AIDL interface.

9. A computer device, characterized in that, include: At least one processor; At least one memory for storing at least one program; When the at least one program is executed by the at least one processor, the at least one processor implements the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

Images