Communication methods and apparatuses, and storage medium and program product

Abstract

Communication methods and apparatuses, and a storage medium and a program product, which relate to the technical field of communications. A communication method is applied to a base station, and comprises: sending a first message to a core network element, the first message being used for requesting that the base station is granted authorization to directly forward data between a first terminal and a second terminal; and receiving a second message sent by the core network element, the second message being used as a response to the first message.

Description

Communication methods, devices, storage media and software products

[0001] This disclosure claims priority to Chinese patent application No. 202510045531.0, filed on January 10, 2025, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This disclosure relates to the field of communication technology, and in particular to a communication method, apparatus, storage medium, and program product. Background Technology

[0003] In modern wireless communication systems, end-to-end data transmission is one of the core mechanisms for data transmission between user equipment (UEs). During end-to-end data transmission, the data transmitted between two UEs must pass through multiple network element nodes. Summary of the Invention

[0004] On the one hand, a communication method is provided, which is applied to a base station, including: sending a first message to a core network element, the first message being used to request permission for the base station to directly forward data between a first terminal and a second terminal; and receiving a second message sent by the core network element, the second message being used to respond to the first message.

[0005] On the other hand, a communication method is provided, which is applied to a core network element, comprising: receiving a first message sent by a base station, the first message being used to request permission for the base station to directly forward data between a first terminal and a second terminal; and sending a second message to the base station, the second message being used to respond to the first message.

[0006] On another front, a communication device is provided for use in a base station. The device includes a transmitting module and a receiving module. The transmitting module is used to send a first message to a core network element, the first message requesting permission for the base station to directly forward data between a first terminal and a second terminal. The receiving module is used to receive a second message sent by the core network element, the second message being a response to the first message.

[0007] On another front, a communication device is provided, applied to a core network element. This device includes a receiving module and a transmitting module. The receiving module is used to receive a first message sent by a base station, the first message requesting permission for the base station to directly forward data between a first terminal and a second terminal. The transmitting module is used to send a second message to the base station, the second message being a response to the first message.

[0008] In another aspect, a communication device is provided, comprising: a memory and a processor. The memory and the processor are coupled. The memory is used to store a computer program. When the processor executes the computer program, it implements the aforementioned communication method.

[0009] In another aspect, a computer-readable storage medium is provided, on which computer program instructions are stored, which, when executed by a processor, implement the above-described communication method.

[0010] On the other hand, a computer program product is provided, which includes computer program instructions that, when executed, implement the above-described communication method. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in this disclosure, the accompanying drawings used in some embodiments of this disclosure will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings.

[0012] Figure 1 is a schematic diagram of a communication system according to some embodiments of the present disclosure.

[0013] Figure 2 is a flowchart illustrating a communication method according to some embodiments of the present disclosure.

[0014] Figure 3 is a flowchart illustrating another communication method according to some embodiments of the present disclosure.

[0015] Figure 4 is a flowchart illustrating another communication method according to some embodiments of the present disclosure.

[0016] Figure 5 is a flowchart illustrating another communication method according to some embodiments of the present disclosure.

[0017] Figure 6 is a flowchart illustrating another communication method according to some embodiments of the present disclosure.

[0018] Figure 7 is a flowchart illustrating another communication method according to some embodiments of the present disclosure.

[0019] Figure 8 is a flowchart illustrating another communication method according to some embodiments of the present disclosure.

[0020] Figure 9 is a flowchart illustrating another communication method according to some embodiments of the present disclosure.

[0021] Figure 10 is a flowchart illustrating another communication method according to some embodiments of the present disclosure.

[0022] Figure 11 is a flowchart illustrating another communication method according to some embodiments of the present disclosure.

[0023] Figure 12 is a flowchart illustrating another communication method according to some embodiments of the present disclosure.

[0024] Figure 13 is a flowchart illustrating another communication method according to some embodiments of the present disclosure.

[0025] Figure 14 is a flowchart illustrating another communication method according to some embodiments of the present disclosure.

[0026] Figure 15 is a flowchart illustrating another communication method according to some embodiments of the present disclosure.

[0027] Figure 16 is a flowchart illustrating another communication method according to some embodiments of the present disclosure.

[0028] Figure 17 is a flowchart illustrating another communication method according to some embodiments of the present disclosure.

[0029] Figure 18 is a flowchart illustrating another communication method according to some embodiments of the present disclosure.

[0030] Figure 19 is a flowchart illustrating another communication method according to some embodiments of the present disclosure.

[0031] Figure 20 is a flowchart illustrating another communication method according to some embodiments of the present disclosure.

[0032] Figure 21 is a flowchart illustrating another communication method according to some embodiments of the present disclosure.

[0033] Figure 22 is a flowchart illustrating another communication method according to some embodiments of the present disclosure.

[0034] Figure 23 is a flowchart of a terminal directly forwarding data based on user-level permission authorization according to some embodiments of the present disclosure.

[0035] Figure 24 is a flowchart of a terminal directly forwarding data based on task-level permission authorization according to some embodiments of the present disclosure.

[0036] Figure 25 is a flowchart of a terminal directly forwarding data based on session-level permission authorization according to some embodiments of the present disclosure.

[0037] Figure 26 is a schematic diagram of a source-destination terminal pairing identification report and feedback according to some embodiments of the present disclosure.

[0038] Figure 27 is a block diagram of a communication device according to some embodiments of the present disclosure.

[0039] Figure 28 is a block diagram of another communication device according to some embodiments of the present disclosure.

[0040] Figure 29 is a block diagram of another communication device according to some embodiments of the present disclosure. Detailed Implementation

[0041] The technical solutions of this disclosure will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0042] It should be noted that, in this disclosure, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in this disclosure should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0043] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0044] In the description of this disclosure, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Furthermore, "at least one" means one or more items, and "multiple" means two or more items.

[0045] In modern wireless mobile communication systems, end-to-end data transmission is one of the core mechanisms connecting various terminals. It begins with data packet encapsulation at the source terminal (also known as the originating terminal) and ends with data reception at the destination terminal (also known as the target terminal or end point terminal). This process involves multiple protocol stacks and the collaboration of network elements such as base stations and core networks. Specifically, after passing through the application layer of the source terminal, the data is passed to the transport layer for segmentation and the addition of transport layer header information. Subsequently, it is encapsulated into IP packets at the Internet Protocol (IP) layer, with key metadata such as the destination address attached. Further, the data link layer (also known as Layer 2) encapsulates the IP packets into Media Access Control (MAC) frames (or 3rd Generation Partnership Project (3GPP) air interface protocol packets). Finally, it is converted into a signal form suitable for wireless propagation (i.e., a wireless signal) through modulation techniques at the physical layer (also known as Layer 1 (L1)) (or the 3GPP air interface physical layer standard).

[0046] As the access node for end-to-end data transmission, the base station is responsible for demodulation, packet header identification, and unpacking after receiving wireless signals. On the network side, data may need to be further routed and forwarded through the core network. Equipment within the core network performs packet classification and policy application, including the implementation of Quality of Service (QoS) and security policies, and ultimately routes and forwards data packets to the network element node where the destination terminal is located.

[0047] The data reception process at the destination terminal encompasses the entire process from signal reception at the physical layer to data processing at the application layer. The physical layer demodulates the received wireless signal and transmits it to the data link layer. The data link layer performs deframing and removes the MAC header to pass IP packets to the upper layers. The IP layer checks the IP header information and passes it to the transport layer. The transport layer reassembles the segmented data and submits the original data to the application layer for processing to complete end-to-end data transmission.

[0048] While end-to-end data transmission mechanisms excel in ensuring data integrity and security, they exhibit inefficiencies and increased data transmission latency in complex network environments and with high-density terminals. Specifically, data transmitted between two terminals (source and destination) must traverse multiple network element nodes and components, leading to higher end-to-end transmission latency and increased network resource consumption.

[0049] Besides end-to-end data transmission mechanisms, related technologies can also provide an optimized data transmission path under specific conditions through direct device-to-device (D2D) communication (also known as point-to-point data transmission). In D2D mode, two terminals connected to the same base station can directly exchange data using the radio resources allocated by the base station. This mechanism eliminates the relay forwarding process of network elements such as user plane functions (UPFs) in the core network, thereby significantly reducing end-to-end transmission latency and improving transmission efficiency. D2D provides a low-latency, high-bandwidth data exchange path, demonstrating advantages in environments with dense terminal concentrations or specific geographical constraints.

[0050] However, D2D mode also faces multiple challenges and limitations. First, there's the issue of resource allocation. In densely populated areas, efficiently managing limited spectrum resources to avoid interference becomes a major challenge. Furthermore, security and privacy protection are also crucial issues. Because D2D communication bypasses traditional core network security mechanisms, it may be more vulnerable to external attacks and data breaches. Finally, the effectiveness of D2D mode largely depends on the physical location of the terminals and environmental conditions; physical layer factors such as signal obstruction and multipath effects can significantly impact communication quality.

[0051] Furthermore, with the development of artificial intelligence (AI) technology, it is possible to embed intrinsic intelligence into base stations, enabling them to autonomously analyze network conditions, match user traffic patterns, and make optimal forwarding path selections locally.

[0052] In summary, the current end-to-end data transmission process between two terminals requires routing and relaying through the core network's UPF elements, potentially leading to high end-to-end transmission latency and wasted bandwidth resources. There is an urgent need to design a more intelligent and flexible data transmission mechanism between the two terminals using AI technology to reduce transmission latency and network resource consumption in end-to-end data transmission.

[0053] This disclosure provides a communication method that introduces intelligent capabilities into a base station. The base station can establish an artificial intelligence (AI) mapping model by analyzing the correlation between the traffic characteristics of past data packets from a specific source terminal and their destination IP address (i.e., the IP address of the destination terminal). This AI mapping model can learn from historical communication patterns and predict the destination IP address of future data packets. Based on this predictive capability, the base station can accurately identify and pair terminal pairs (i.e., source and destination terminals) that can directly forward service data, and flexibly decide whether to enable base station local routing forwarding of data paths without core network processing based on real-time network conditions. Thus, under the authorization of the core network, the base station is allowed to establish a data service session based on a new data plane to enable the base station direct routing forwarding mode. In the base station direct routing forwarding mode, the base station becomes a direct bridge between the source and destination terminals, responsible for the routing and direct forwarding of service data transmitted between them, without passing through UPF network elements in the core network. This allows the base station to significantly reduce end-to-end transmission latency between the two terminals and improve network availability and interference resistance.

[0054] For example, as shown in FIG1, a communication system according to an embodiment of the present disclosure may include: a first terminal 101, a base station 102, a core network element 103, and a second terminal 104. The first terminal 101, the base station 102, the core network element 103, and the second terminal 104 may be one or more, and the number is not limited.

[0055] In this configuration, the first terminal 101 and the second terminal 104 are connected to the base station 102. The base station 102 is connected to the core network element 103. The base station 102 can send a message to the core network element 103 requesting permission to directly forward data between the first terminal 101 and the second terminal 104. Furthermore, the core network element 103 can return a second message responding to the first message to the base station 102. In this way, the base station 102 can establish a data service session for directly forwarding data between the first terminal 101 and the second terminal 104, thereby enabling the base station 102 to directly forward data between the first terminal 101 and the second terminal 104.

[0056] It should be noted that, in the embodiments of this disclosure, the terminal can be a device with wireless transceiver capabilities. The terminal can be a mobile phone, tablet computer, computer with wireless transceiver capabilities, virtual reality (VR) terminal, augmented reality (AR) terminal, wireless terminal in industrial control, wireless terminal in self-driving, wireless terminal in remote medical care, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, wireless terminal in smart home, etc. The embodiments of this disclosure do not limit the application scenarios. The terminal may also be referred to as a user, user equipment, A-IoT device, access terminal, UE unit, UE station, mobile station, mobile station, remote station, transmitter, remote terminal, mobile device, UE terminal, wireless communication device, UE agent, or UE device, etc., and the embodiments of this disclosure do not limit this.

[0057] Base stations can be base stations in Long Term Evolution (LTE), Long Term Evolution Advanced (LTEA), or Evolutionary Node Bs (eNBs or eNodeBs), base station equipment (gNBs) in 5G networks, or base stations in future communication systems. Base stations can include various macro base stations, micro base stations, femtocell base stations, wireless remote extensions, reconfigurable intelligent surfaces (RISS), routers, relay stations, transmission and reception points (TRPs), receivers, access points, wireless fidelity (WIFI) devices, and other network-side equipment. Base stations can sometimes be referred to as readers / writers used for communication with terminals; however, this disclosure does not limit this terminology.

[0058] Core network elements can be network functions (NFs) in the core network. For example, core network elements such as access and mobility management function (AMF), session management function (SMF), policy control function (PCF), and UPF are not limited to these in this disclosure.

[0059] It should be noted that Figure 1 is only an exemplary framework diagram, and the number of devices included in Figure 1 and the names of each device are not limited.

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

[0061] Figure 2 shows a flowchart of a communication method. As shown in Figure 2, this communication method is applied to a base station and includes S201-S202:

[0062] S201, Send the first message to the core network element.

[0063] The first message is used to request permission for the base station to directly forward data between the first terminal and the second terminal.

[0064] In some embodiments, direct forwarding of data between the first terminal and the second terminal by the base station means that when the base station receives data sent by the first terminal, it can directly forward the data to the second terminal without going through the core network. The data sent by the first terminal can be service data. For example, if the first terminal and the second terminal are connected to the same base station, the base station can directly forward the data to the second terminal without going through the core network when it receives the data sent by the first terminal. If the first terminal and the second terminal are connected to different base stations, assuming the first terminal is connected to the first base station and the second terminal is connected to the second base station, then when the first base station receives data sent by the first terminal, the first base station can forward the data to the second base station without going through the core network. The second base station then forwards the data to the second terminal.

[0065] For base stations involved in data service sessions, intelligent agent logic functions (also known as intelligent capabilities) capable of directly forwarding data between terminal pairs can be introduced into the base stations. Terminal pairs can also be referred to as source-destination terminal pairings, i.e., two terminals communicating with each other, such as the first terminal and the second terminal in this disclosure. The first terminal in this disclosure can also be referred to as a source node or source terminal, etc. The second terminal in this disclosure can also be referred to as a target node or target terminal, etc. This intelligent agent logic function can be carried by an AI mapping model (i.e., the pairing model in this disclosure).

[0066] The intelligent agent logic function of the base station can predict frequently communicating terminal pairs in real time based on the data packet characteristics (also known as traffic characteristics) of the messages sent by the first terminal, that is, determine the address of the second terminal that has a frequent communication need with the first terminal. The messages sent by the first terminal can be messages requesting a session with the second terminal, or, after an existing connection, messages requesting authorization to change the data transmission method.

[0067] Furthermore, the base station can send a direct data forwarding permission request (i.e., the first message in this disclosure) to the core network element for frequently communicating terminal pairs, requesting permission for direct data routing and forwarding between the frequently communicating terminal pairs. The core network element then evaluates and decides whether to authorize direct communication. In other words, the base station can predict frequently communicating terminal pairs and request the core network element to grant permission for direct data forwarding between those terminal pairs. This allows the base station to directly forward data transmitted between the terminal pairs without the core network element processing and forwarding, thereby reducing data transmission latency and network resource consumption between frequently communicating terminal pairs.

[0068] In this embodiment of the disclosure, the base station can predict multiple terminal pairs formed by one or more terminals and initiate direct data forwarding permission requests for the corresponding terminal pairs. The base station can initiate direct data forwarding permission requests for multiple terminal pairs in parallel. The base station can initiate multiple direct data forwarding permission requests in parallel for the same terminal pair, for example, task-level requests or session-level requests.

[0069] In some embodiments, the first message includes at least one of the following: request type, message identifier of the first message, identifier of the sender of the first message (usually a base station), identifier of the first terminal, identifier of the second terminal, identifier of the base station through which the data between the first terminal and the second terminal is forwarded, required quality of service parameters, identifier of the terminal pair consisting of the first terminal and the second terminal, authorization reason description, and estimated performance impact description.

[0070] In some embodiments, the identifier can be a unique code (identifier, ID).

[0071] The identifier of the base station through which data is forwarded between the first terminal and the second terminal can be the ID of all base stations involved in the data forwarding. For example, if the base station accessed by the first terminal is the first base station, and the base station accessed by the second terminal is the first base station, then all base stations involved in the data forwarding include both the first and second base stations.

[0072] The authorization reason description (also known as the communication request reason) can be traffic pattern data that indicates frequent interaction between the first terminal and the second terminal and is suitable for direct communication.

[0073] The estimated performance impact description outlines the performance improvements that may be achieved through direct communication. For example, reduced latency.

[0074] The required quality of service parameters can be QoS parameters or the minimum acceptable service level, etc.

[0075] In some embodiments, if the first terminal and the second terminal access different base stations, the first message may further include cross-base station link quality assessment metrics. Cross-base station link quality assessment metrics may include metrics such as signal strength, latency, and expected packet loss rate. These metrics can be used to assess the communication quality between the base station accessed by the first terminal and the base station accessed by the second terminal.

[0076] In other words, based on the information included in the first message sent by the base station, the core network elements can assess and decide whether to authorize direct communication.

[0077] In some embodiments, the request type includes at least one of the following: user-level request, session-level request, and task-level request.

[0078] In some embodiments, a user-level request can request direct communication between two users (i.e., two terminals). A task-level request can request direct communication between two users while performing a specific task (e.g., video conferencing, live video streaming, online courses, etc.). A session-level request can request direct communication between two users while engaging in a specific session (e.g., video calls, voice calls, etc.). This approach can meet the direct communication needs in different application scenarios, enhancing the flexibility of direct communication.

[0079] In the embodiments of this disclosure, the request type of the first message differs in different application scenarios. The application scenarios corresponding to user-level requests can be referred to the descriptions in the following embodiments, and will not be repeated here. The application scenarios corresponding to session-level requests can be referred to the descriptions in the following embodiments, and will not be repeated here. The application scenarios corresponding to task-level requests can be referred to the descriptions in the following embodiments, and will not be repeated here.

[0080] In some embodiments, depending on the request type, the following parameters may also be extended to the first message described above:

[0081] When the request type is a user-level request, the first message also includes at least one of the following: the scope of application of the permission, the validity period of the permission (also known as the validity period), and the restriction conditions of the permission.

[0082] Alternatively, if the request type is a session-level request, the first message may also include at least one of the following: the identifier of the session to be authorized, the communication type of the session, the estimated duration of the session, the estimated amount of data exchanged in the session, and the triggering condition for the end of the session.

[0083] Alternatively, if the request type is a task-level request, the first message may also include at least one of the following: the identifier of the task corresponding to the first message, the type of the task, the priority of the task, the estimated data transmission volume of the task, and the security configuration requirements of the task.

[0084] In some embodiments, the identifier of the session to be authorized can be an ID assigned to the session by the network management system. The communication type of the session can be a description of the communication types involved in the session. The communication type can be a video call, voice call, or other types.

[0085] The trigger for ending a session can be either a session end condition or a trigger point. For example, the session can end at a certain point in time, or when the session end button is pressed.

[0086] The task type can be video conferencing, live video streaming, open courses, etc. This means that the information included in the first message sent by the base station will differ depending on the request type.

[0087] In this way, core network elements can evaluate and decide whether to authorize direct communication based on the first message corresponding to different request types, thereby enhancing the flexibility and accuracy of base station evaluation of data direct forwarding permission requests.

[0088] S202, Receive the second message sent by the core network element.

[0089] The second message is used in response to the first message.

[0090] In some embodiments, the second message (also known as a direct forwarding permission response message) is used to indicate whether to grant the base station permission to directly forward data between the first terminal and the second terminal, i.e., whether to agree to the base station directly forwarding data between the first terminal and the second terminal. In this way, the base station can decide whether to establish a data service session for directly forwarding data between the first terminal and the second terminal based on the second message, thereby enabling direct communication between the terminal pairs and reducing data transmission latency and network resource consumption between the terminal pairs.

[0091] In some embodiments, the second message includes at least one of the following: the request type responded to by the second message, the message identifier of the second message, the identifier of the recipient of the second message (typically a base station), and indication information indicating whether permission is granted.

[0092] In some embodiments, the indication information for whether to grant permissions can be a status indication of whether the application is authorized. For example, an indication of 1 indicates that permissions are granted, while an indication of 0 indicates that permissions are not granted. Thus, the base station can determine, based on the information included in the second message, whether the core network element agrees to the base station directly forwarding data between the first and second terminals.

[0093] In some embodiments, the authorization details parameters can vary depending on the request type (user-level, task-level, or session-level) responded to by the second message, for example:

[0094] When the request type is a user-level request, the second message may also include at least one of the following: the scope of application of the permission, the validity period of the permission, the restriction conditions of the permission, and the authorization service quality parameters.

[0095] Alternatively, if the request type is a session-level request, the second message may also include at least one of the following: network resources allocated for the authorized session, authorized quality of service parameters, performance metrics to be reported by the session, time interval for reporting performance metrics, notification process for the end of the session, and session identifier.

[0096] Alternatively, if the request type is a task-level request, the second message may also include at least one of the following: authorized service quality parameters, security policy, and permission restrictions.

[0097] In some embodiments, the scope of permission can be all sessions or sessions under specific conditions. The restrictions on permissions can be termination conditions, such as permission termination conditions. Permission termination conditions can include terminating permission when traffic reaches a certain threshold or when the terminal's geographical location changes. The authorized quality of service parameters can be the specific QoS parameters that the authorized direct forwarding will follow. For example, QoS parameters can include transmission bandwidth, transmission latency, and data packet loss rate. Performance indicators include packet loss rate, latency, and throughput. In this way, the base station can follow corresponding rules during direct forwarding based on the authorization details parameters corresponding to different request types, adapting to the authorization requirements of different application scenarios.

[0098] Figure 3 shows a flowchart of another communication method. As shown in Figure 3, after step S202 above, the method further includes S301:

[0099] S301. If the second message indicates agreement to allow the base station to directly forward data between the first terminal and the second terminal, a data service session for directly forwarding data between the first terminal and the second terminal is established with the first terminal and the second terminal.

[0100] In some embodiments, after the base station receives a direct forwarding permission response message from a core network element, it can configure resources according to the information in the message and establish a direct forwarding data service session with the first terminal and the second terminal based on actual communication needs. This data service session is used to directly forward data between the first terminal and the second terminal. In this way, the base station can receive data sent by the first terminal through the data service session and directly forward the data to the second terminal, reducing transmission latency and network resource consumption when the data passes through core network elements.

[0101] Figure 4 shows a flowchart of another communication method. As shown in Figure 4, after step S301 above, the method further includes S401-S402:

[0102] S401, Send a third message to the core network element.

[0103] The third message is used to request changes to permission-related parameters.

[0104] In some embodiments, when a base station detects that the QoS of the currently directly forwarded data service session no longer meets the required quality of service parameters when requesting authorization, or when the current network conditions change, the base station will initiate a session change request (i.e., the third message in this disclosure) to the core network element.

[0105] In other words, if the QoS of the current data service session no longer meets the required service quality parameters when requesting authorization, it will lead to a deterioration in service quality, thus affecting the user experience. Alternatively, if network conditions deteriorate, resulting in a more dangerous network environment, the security of data transmission cannot be guaranteed. Therefore, it is necessary to request changes to the permission-related parameters to ensure either a better user experience or secure data transmission.

[0106] In some embodiments, permission-related parameters include at least one of the following: authorized service quality parameters and allocated network resources.

[0107] In other words, core network elements can change authorized quality of service parameters, allocated network resources, and other information to ensure user experience or guarantee the security of data transmission.

[0108] In some embodiments, the third message includes at least one of the following: the identifier of the session to be changed, the reason for the change, the content of the change, the parameters to be changed, and the performance metrics of the data service session (i.e., the performance metrics of the current link).

[0109] In some embodiments, the third message may also include an identifier for the data service session. The reason for the change may be network congestion or changes in terminal mobility (e.g., the terminal moving out of the service area). The content of the change may be new QoS requirements or bandwidth demand adjustments. The parameters to be changed may be proposed QoS parameter updates or additional bandwidth requirements. In this way, core network elements can decide whether to change the corresponding parameters based on the information in the session change request, ensuring the rationality of the change.

[0110] S402, Receive the fourth message sent by the core network element.

[0111] The fourth message is used in response to the third message.

[0112] In some embodiments, the session change response message (i.e., the fourth message in this disclosure) may indicate whether or not the session change request is accepted. Thus, the base station can decide whether to make the corresponding changes based on the session change response message.

[0113] In some embodiments, the fourth message includes: updated permission-related parameters.

[0114] In some embodiments, when the session change response message indicates agreement to the session change request, the session change response message also includes updated permission-related parameters. This allows the base station to update the permission-related parameters based on the information in the session change response message, ensuring user experience or protecting data transmission security.

[0115] Figure 5 shows a flowchart of another communication method. As shown in Figure 5, the method in step S401 above specifically includes S501 or S502:

[0116] S501. If the request type of the first message is a session-level request and the authorized quality of service parameters included in the second message do not meet the required quality of service parameters, and / or the allocated network resources do not meet the required quality of service parameters, a third message is sent to the core network element.

[0117] In some embodiments, for session-level authorization, when the required Quality of Service (QoS) parameters change (e.g., a terminal (first terminal and / or second terminal) begins high-bandwidth activity), causing the authorized QoS parameters to no longer meet the required QoS parameters, or when the currently allocated network resources no longer meet the required QoS, the base station may send a session change request to the core network elements. That is, the authorized QoS parameters not meeting the required QoS parameters will lead to a deterioration in service quality. In this case, it is necessary to request the authorization of new QoS parameters to ensure that the new authorized QoS parameters can meet the required QoS parameters. The currently allocated network resources no longer meeting the required QoS will lead to a deterioration in service quality. In this case, it is necessary to request the allocation of new network resources to ensure that the newly allocated network resources can meet the required QoS parameters. Thus, service quality is guaranteed.

[0118] In this embodiment, session-level authorization has a limited scope, as it applies to a single session. When service quality parameters are not met, directly requesting the core network to change permission-related parameters ensures the quality of the current session.

[0119] S502. When the request type is a user-level request or a task-level request, and the difference between the required quality of service parameters and the authorized quality of service parameters is greater than the preset difference, a third message is sent to the core network element.

[0120] In some embodiments, if the user-level authorization or task-level authorization explicitly includes a certain degree of self-management rights (e.g., automatic adjustment of bandwidth allocation or QoS parameters) during the initial authorization, the base station can make some changes within a predefined range (i.e., the difference between the required QoS parameters and the authorized QoS parameters needs to be less than a preset difference). However, for major change events that significantly affect network conditions (e.g., potential congestion caused by a substantial increase in bandwidth demand), the difference between the required QoS parameters and the authorized QoS parameters is large. In this case, the base station can send a session change request to the core network elements. That is, if the authorized QoS parameters are much smaller than the required QoS parameters, the service quality will become very poor. In this case, it is necessary to request authorization of new QoS parameters to ensure that the new authorized QoS parameters can meet the required QoS parameters.

[0121] In this embodiment, the scope of user-level or task-level authorization is relatively large, and multiple sessions may occur during the authorization period. Therefore, the base station can automatically change the permission-related parameters within a certain range. When the range is exceeded, the base station requests the core network to change the permission-related parameters, which reduces the frequency of requesting changes to permission-related parameters and thus reduces the network resources consumed.

[0122] For different authorization types—user-level, task-level, and session-level—the core network will engage in a series of interactions with the base station when a data service session ends or a direct forwarding authorization terminates, to ensure the effective release of resources and policy updates. The following examples illustrate the series of interactions between the core network and the base station.

[0123] Figure 6 shows a flowchart of another communication method. As shown in Figure 6, after step 301 above, the method further includes S601:

[0124] S601, Send the fifth message to the core network element.

[0125] The fifth message is used to request or notify the termination of permissions.

[0126] In some embodiments, when a data service session ends or a direct forwarding authorization is terminated, the base station may send a direct forwarding authorization termination request message (i.e., the fifth message in this disclosure) to the core network element to request or notify the core network element to terminate the authorization, thereby ensuring the effective release of resources. For example, when the base station detects an increase in network load or a decrease in data traffic, the base station may send a direct forwarding authorization termination request message to the core network element.

[0127] In some embodiments, when the request type of the first message is a user-level request, the fifth message includes at least one of the following: an identifier of the first terminal, an identifier of the second terminal, a termination reason description, and evidence supporting termination. Alternatively, when the request type is a session-level request, the fifth message includes at least one of the following: an identifier of the session to be terminated, a termination trigger condition, and resource usage at the end of the session. Alternatively, when the request type is a task-level request, the fifth message includes at least one of the following: an identifier of the task to be terminated, status information of the task to be terminated, and resource usage of the task to be terminated.

[0128] In some embodiments, the user-level permission termination process is as follows: When the base station detects a specific event (such as a forwarding anomaly) and needs to terminate the user-level direct forwarding permission, the base station can send a direct forwarding permission termination request message to the core network element to request the termination of the direct forwarding permission for a specific terminal pair. The reason for termination can be a forwarding anomaly. Evidence supporting the termination can be log information.

[0129] Session-level permission termination procedure: For each individual direct forwarding session, when predetermined termination conditions are met (e.g., session duration, data volume reaching a threshold, or terminal moving out of the service area), the base station can send a direct forwarding permission termination request message to the core network element to release the data service session and terminate the direct forwarding authorization for that specific session. The triggering conditions for terminating the session can be that the session duration reaches the valid duration of the permission, or the data volume reaches the authorized data volume threshold, etc.

[0130] Task-level permission termination procedure: When a base station detects that an authorized direct forwarding task has been completed, or that the conditions are no longer met (e.g., data transmission interruption or emergency resolution), the base station can send a direct forwarding permission termination request message to the core network elements. The status information of the task to be terminated can be completed or no longer applicable, etc. The resource usage of the task to be terminated can be the amount of resources used during the execution of the task, to assist the core network in resource reclamation.

[0131] In other words, base stations can decide whether to send a direct forwarding permission termination request message based on different application scenarios, in order to adapt to the permission termination requirements under different application scenarios.

[0132] Figure 7 shows a flowchart of another communication method. As shown in Figure 7, after step S301 above, the method further includes S701:

[0133] S701, Receive the sixth message sent by the core network element.

[0134] The sixth message is used to notify whether to terminate permissions.

[0135] In some embodiments, a direct forwarding permission termination message (i.e., the sixth message in this disclosure) is used to indicate whether or not the direct forwarding permission is terminated. After receiving the direct forwarding permission termination message from the core network element, if the message indicates agreement to terminate the direct forwarding permission, the base station can update the corresponding configuration parameters based on the decision in the message. This may include QoS parameter updates, resource allocation changes, etc. Thus, the base station can decide whether to release the data service session and terminate the direct forwarding authorization for a specific session based on whether the core network element agrees to terminate the direct forwarding permission.

[0136] In some embodiments, the sixth message includes at least one of the following: an instruction to terminate permissions, updated quality of service parameters, and updated resource allocation information.

[0137] For example, a value of 1 indicates that permission will be terminated. A value of 0 indicates that permission will not be terminated.

[0138] In this embodiment of the disclosure, if permissions are terminated, it may be necessary to update service quality parameters or resource allocation information. Therefore, directly forwarding the permission termination message may include the updated service quality parameters and the updated resource allocation information.

[0139] In other words, the base station can know whether the core network agrees to terminate the direct forwarding permission based on the direct forwarding permission termination message, and can update the corresponding configuration parameters based on the decision in the direct forwarding permission termination message.

[0140] Figure 8 shows a flowchart of a communication method. As shown in Figure 8, after step S202 above, the method further includes S801:

[0141] S801, Send session status information to core network elements.

[0142] Among them, session state information is used to characterize the state information of data forwarding based on data service sessions.

[0143] In some embodiments, the base station may periodically upload data service reports (i.e., session state information in this disclosure) according to the requirements in the direct forwarding permission response message, to ensure that the core network can understand the network status, resource usage, and current quality of service (QoS) in real time. This allows the core network to easily change or terminate direct forwarding permissions in a timely manner.

[0144] In some embodiments, when the request type of the first message is a user-level request, the session state information includes at least one of the following: the data transmission rate of the first terminal, the traffic consumption of the first terminal, the active time percentage of the first terminal, the data transmission rate of the second terminal, the traffic consumption of the second terminal, and the active time percentage of the second terminal. Alternatively, when the request type is a session-level request, the session state information includes at least one of the following: session quality monitoring data and session event records. Alternatively, when the request type is a task-level request, the session state information includes at least one of the following: the progress of task execution, the current status of the task, and a resource utilization efficiency analysis.

[0145] In some embodiments, session quality monitoring data may include performance metrics such as latency, packet loss rate, and bit error rate. Session event records may include session start time, end time, and any abnormal interruptions.

[0146] In other words, base stations can report session state information corresponding to different authorization types, which facilitates the core network to analyze the session state information corresponding to different authorization types in order to adapt to the needs of changing or terminating direct forwarding permissions under different application scenarios.

[0147] Figure 9 shows a flowchart of another communication method. As shown in Figure 9, before step S201 above, the method further includes step S901:

[0148] S901, Send terminal pairing information to core network elements.

[0149] The terminal pairing information includes at least one of the following: the correspondence between the first terminal and the second terminal, the predicted data traffic characteristics, and the potential demand information.

[0150] In some embodiments, the example of step S201 described above introduces a method where the base station can predict frequently communicating terminal pairs, i.e., obtain terminal pairing information. The base station can send a report containing potential source-destination paired terminals (i.e., terminal pairing information in this disclosure) to the core network elements. The report of potential source-destination paired terminals includes a list of terminal pairs identified based on the prediction results, including but not limited to the identifier of the first terminal, the predicted data traffic characteristics, potential demands, etc. In this way, the core network can analyze whether the terminal pairs predicted by the base station are accurate.

[0151] For an explanation of how the core network analyzes the accuracy of the terminal pair predictions made by the base station, please refer to the description in S2001 below, which will not be repeated here.

[0152] Figure 10 shows a flowchart of another communication method. As shown in Figure 10, after step S901 above, the method further includes S1001:

[0153] S1001, Receive terminal pairing feedback information sent by the core network element.

[0154] The terminal pairing feedback information includes at least one of the following: indication information on whether the correspondence is correct, indication information on whether the pairing model needs to be adjusted, and adjustment strategy of the pairing model; the pairing model is used to predict the second terminal corresponding to the first terminal based on the first terminal.

[0155] In other words, the base station can determine the accuracy of the terminal pair predictions made by the pairing model based on terminal pairing feedback information, and whether the pairing model needs adjustment. Furthermore, it can determine how to adjust the pairing model when the predicted terminal pairs are inaccurate. This improves the accuracy of the pairing model's terminal pair predictions.

[0156] Figure 11 shows a flowchart of another communication method. As shown in Figure 11, before step S901 above, the method further includes S1101:

[0157] S1101. Based on the data packet characteristics of the seventh message sent by the first terminal, determine the terminal pairing information.

[0158] The seventh message is used to request a session with the second terminal or to transmit data.

[0159] In some embodiments, the intelligent agent logic function of the base station can predict frequently communicating terminal pairs in real time based on the messages sent by the first terminal (i.e., the seventh message in this disclosure) to obtain terminal pairing information.

[0160] This disclosure also provides a communication method applied to a core network element, as shown in FIG12. The communication method may include S1201-S1202:

[0161] S1201, Receive the first message sent by the base station.

[0162] The first message is used to request permission for the base station to directly forward data between the first terminal and the second terminal.

[0163] In some embodiments, after receiving the first message from the base station, the core network element can review the request (which may require negotiation with AMF, SMF, PCF, etc.) and decide whether to authorize direct forwarding based on network policies and available resources. In other words, the core network element can comprehensively assess the feasibility of authorization to ensure that it will not adversely affect the entire network and to guarantee service quality.

[0164] In some embodiments, the first message includes at least one of the following: request type, message identifier of the first message, identifier of the sender of the first message, identifier of the first terminal, identifier of the second terminal, identifier of the base station through which the data between the first terminal and the second terminal is forwarded, required quality of service parameters, identifier of the terminal pair consisting of the first terminal and the second terminal, authorization reason description, and estimated performance impact description.

[0165] For a description of the information included in the first message, please refer to the relevant descriptions in the above embodiments, which will not be repeated here.

[0166] In some embodiments, the request type includes at least one of the following: user-level request, session-level request, and task-level request.

[0167] For descriptions of different request types, please refer to the relevant introductions in the above embodiments, which will not be repeated here.

[0168] In some embodiments, when the request type is a user-level request, the first message further includes at least one of the following: the scope of application of the permission, the effective duration of the permission, and the restriction conditions of the permission. Alternatively, when the request type is a session-level request, the first message further includes at least one of the following: the identifier of the session to be authorized, the communication type of the session, the estimated duration of the session, the estimated data exchange volume of the session, and the triggering condition for the end of the session. Alternatively, when the request type is a task-level request, the first message further includes at least one of the following: the identifier of the task corresponding to the first message, the type of the task, the priority of the task, the estimated data transmission volume of the task, and the security configuration requirements of the task.

[0169] In some embodiments, the description of the information included in the first message corresponding to different request types can be referred to the relevant descriptions in the above embodiments, and will not be repeated here.

[0170] S1202, Send the second message to the base station.

[0171] The second message is used in response to the first message.

[0172] In some embodiments, core network elements can send direct forwarding permission response messages to all relevant base stations. Core network elements can respond to multiple direct forwarding permission requests initiated by base stations in parallel.

[0173] For a description of the function of the second message, please refer to the relevant descriptions in the above embodiments, which will not be repeated here.

[0174] In some embodiments, the second message includes at least one of the following: the request type responded to by the second message, the message identifier of the second message, the identifier of the recipient of the second message, and indication information indicating whether permission is granted.

[0175] For a description of the information included in the second message, please refer to the relevant descriptions in the above embodiments, which will not be repeated here.

[0176] In some embodiments, when the request type is a user-level request, the second message further includes at least one of the following: the scope of application of the permission, the validity period of the permission, the restriction conditions of the permission, and the authorization service quality parameters. Alternatively, when the request type is a session-level request, the second message further includes at least one of the following: network resources allocated for the authorized session, authorization service quality parameters, performance metrics to be reported by the session, the time interval for reporting performance metrics, and the notification process for the end of the session. Alternatively, when the request type is a task-level request, the second message further includes at least one of the following: authorization service quality parameters, security policy, restriction conditions of the permission, and session identifier.

[0177] For a description of the information included in the second message corresponding to different request types, please refer to the relevant descriptions in the above embodiments, which will not be repeated here.

[0178] Figure 13 shows a flowchart of another communication method. As shown in Figure 13, the method in step S1201 above specifically includes S1301:

[0179] S1301. If the network policy allows for granting permissions, and / or the available resources can satisfy the required quality of service parameters included in the first message, send a second message to the base station.

[0180] In other words, if the network policy allows granting permissions, it means that granting permissions at this time will not adversely affect the network. Therefore, a second message indicating consent to authorization can be sent to the base station. If available resources can satisfy the required quality of service parameters included in the first message, it means that granting permissions at this time can ensure quality of service. Therefore, a second message indicating consent to authorization can be sent to the base station.

[0181] Figure 14 shows a flowchart of another communication method. As shown in Figure 14, after step S1202 above, the method further includes S1401-S1402:

[0182] S1401, Receive the third message sent by the base station.

[0183] The third message is used to request changes to permission-related parameters.

[0184] In some embodiments, after a core network element receives a data session change request, it can assess the rationality and feasibility of the request.

[0185] For a description of the function of the third message, please refer to the relevant descriptions in the above embodiments, which will not be repeated here.

[0186] In some embodiments, the third message includes at least one of the following: the identifier of the session to be changed, the reason for the change, the content of the change, the parameters to be changed, and the performance indicators of the data service session.

[0187] For a description of the information included in the third message, please refer to the relevant descriptions in the above embodiments, which will not be repeated here.

[0188] In some embodiments, permission-related parameters include at least one of the following: authorized service quality parameters and allocated network resources.

[0189] For a description of the information included in the permission-related parameters, please refer to the relevant descriptions in the above embodiments, which will not be repeated here.

[0190] S1402, Send the fourth message to the base station.

[0191] The fourth message is used in response to the third message.

[0192] In some embodiments, core network elements can send session change response messages to all relevant base stations.

[0193] For a description of the function of the fourth message, please refer to the relevant descriptions in the above embodiments, which will not be repeated here.

[0194] In some embodiments, the fourth message includes: updated permission-related parameters.

[0195] For a description of the information included in the fourth message, please refer to the relevant descriptions in the above embodiments, which will not be repeated here.

[0196] Figure 15 shows a flowchart of another communication method. As shown in Figure 15, the method in step S1402 above specifically includes S1501:

[0197] S1501. If the available resources can satisfy the updated permission-related parameters, send a fourth message to the base station.

[0198] In other words, if the available resources can satisfy the updated permission-related parameters, it means that changing the permission-related parameters at this time can ensure service quality. Therefore, a fourth message indicating agreement to the data session change can be sent to the base station.

[0199] Figure 16 shows a flowchart of another communication method. As shown in Figure 16, after step S1202 above, the method further includes S1601:

[0200] S1601, Receive the fifth message sent by the base station.

[0201] The fifth message is used to request or notify the termination of permissions.

[0202] In some embodiments, core network elements may decide whether to agree to terminate permissions based on the information in the direct forwarding permission termination request message.

[0203] For a description of the function of the fifth message, please refer to the relevant descriptions in the above embodiments, which will not be repeated here.

[0204] In some embodiments, when the request type of the first message is a user-level request, the fifth message includes at least one of the following: an identifier of the first terminal, an identifier of the second terminal, a termination reason description, and evidence supporting termination. Alternatively, when the request type is a session-level request, the fifth message includes at least one of the following: an identifier of the session to be terminated, a termination trigger condition, and resource usage at the end of the session. Alternatively, when the request type is a task-level request, the fifth message includes at least one of the following: an identifier of the task to be terminated, status information of the task to be terminated, and resource usage of the task to be terminated.

[0205] For a description of the information included in the fifth message corresponding to different request types, please refer to the relevant descriptions in the above embodiments, which will not be repeated here.

[0206] Figure 17 shows a flowchart of another communication method. As shown in Figure 17, after step S1202 above, the method further includes S1701:

[0207] S1701. Upon receiving the fifth message or if the permission termination condition is met, send the sixth message to the base station.

[0208] The sixth message is used to notify whether to terminate permissions.

[0209] In some embodiments, a core network element decides whether to terminate the authorization after detecting that the conditions for terminating the authorization have been met (i.e., the authorization termination conditions in this disclosure) (e.g., user subscription expiration), determining that the conditions for terminating the authorization have been met based on session state information, or receiving a direct forwarding authorization termination request message from a base station. If the decision is made to terminate the authorization, a direct forwarding authorization termination message is sent to all base stations involved in the authorization.

[0210] In some embodiments, the sixth message includes at least one of the following: an instruction to terminate permissions, updated quality of service parameters, and updated resource allocation information.

[0211] For a description of the information included in the sixth message, please refer to the relevant descriptions in the above embodiments, which will not be repeated here.

[0212] Figure 18 shows a flowchart of another communication method. As shown in Figure 18, after step S1202 above, the method further includes S1801:

[0213] S1801, Receive session status information sent by the base station.

[0214] Among them, session state information is used to characterize the state information of data forwarding based on data service sessions.

[0215] In some embodiments, core network elements can receive session status information sent by base stations to understand network status, resource usage, and current service quality in real time.

[0216] In some embodiments, when the request type of the first message is a user-level request, the session state information includes at least one of the following: the data transmission rate of the first terminal, the traffic consumption of the first terminal, the active time percentage of the first terminal, the data transmission rate of the second terminal, the traffic consumption of the second terminal, and the active time percentage of the second terminal. Alternatively, when the request type is a session-level request, the session state information includes at least one of the following: session quality monitoring data and session event records. Alternatively, when the request type is a task-level request, the session state information includes at least one of the following: the progress of task execution, the current status of the task, and a resource utilization efficiency analysis.

[0217] For a description of the information included in the session state information corresponding to different request types, please refer to the relevant descriptions in the above embodiments, which will not be repeated here.

[0218] Figure 19 shows a flowchart of another communication method. As shown in Figure 19, after step S1801 above, the method further includes S1901:

[0219] S1901. Based on the session state information, determine whether to send the eighth message to the base station.

[0220] The eighth message is used to notify whether permissions have been terminated or changed.

[0221] In some embodiments, core network elements can understand network status, resource usage, and current service quality based on session state information, and decide to change or terminate direct forwarding permissions. This ensures timely maintenance of good network status and service quality.

[0222] Figure 20 shows a flowchart of another communication method. As shown in Figure 20, before step S1801 above, the method further includes step S2001:

[0223] S2001, Receive terminal pairing information sent by the base station.

[0224] The terminal pairing information includes at least one of the following: the correspondence between the first terminal and the second terminal, the predicted data traffic characteristics, and the potential demand information.

[0225] In some embodiments, the core network element can acquire and parse the data packet characteristics of the seventh message sent by the first terminal to determine the correct terminal pair. Then, it compares the correct terminal pair with the predicted terminal pair in the terminal pairing information to determine whether the terminal pairing information is accurate.

[0226] Figure 21 shows a flowchart of another communication method. As shown in Figure 21, after step S2001 above, the method further includes S2101:

[0227] S2101, Send terminal pairing feedback information to the base station.

[0228] The terminal pairing feedback information includes at least one of the following: indication information on whether the correspondence is correct, indication information on whether the pairing model needs to be adjusted, and adjustment strategy of the pairing model; the pairing model is used to predict the second terminal corresponding to the first terminal based on the first terminal.

[0229] In some embodiments, core network elements send terminal pairing feedback information to the base station.

[0230] For a description of the role of terminal pairing feedback information, please refer to the relevant introduction in the above embodiments, which will not be repeated here.

[0231] The following describes the communication method provided in the above embodiment, taking the interaction between the base station and the core network element as an example, as shown in Figure 22, including:

[0232] S2201. The base station sends terminal pairing information to the core network elements. Correspondingly, the core network elements receive the terminal pairing information sent by the base station.

[0233] S2202. The core network element sends terminal pairing feedback information to the base station. Correspondingly, the base station receives the terminal pairing feedback information sent by the core network element.

[0234] S2203, The base station sends the first message to the core network element. Correspondingly, the core network element receives the first message sent by the base station.

[0235] S2204. The core network element sends a second message to the base station. Correspondingly, the base station receives the second message sent by the core network element.

[0236] S2205. The base station sends a third message to the core network element. Correspondingly, the core network element receives the third message sent by the base station.

[0237] S2206. The core network element sends a fourth message to the base station. Correspondingly, the base station receives the fourth message sent by the core network element.

[0238] S2207. The base station sends the fifth message to the core network element. Correspondingly, the core network element receives the fifth message sent by the base station.

[0239] S2208. When the core network element receives the fifth message or the authorization termination condition is met, the core network element sends a sixth message to the base station. Correspondingly, the base station receives the sixth message sent by the core network element.

[0240] S2209. The base station sends session state information to the core network elements. Correspondingly, the core network elements receive the session state information sent by the base station.

[0241] In other words, based on the interaction between the above-mentioned base station and the core network element, the embodiments of this disclosure enable the core network element to authorize the base station to directly forward data between terminal pairs, and the core network to control the authorization status accordingly.

[0242] The communication method provided in this disclosure will be described below with reference to specific embodiments.

[0243] Example: A terminal based on user-level permission authorization directly forwards data.

[0244] The application scenario corresponding to user-level requests is as follows: When a natural disaster or emergency occurs, on-site emergency personnel may need to rapidly transmit large amounts of high-resolution video, sensor data, and other critical information to other nearby emergency vehicles and equipment (i.e., the second terminal in this disclosure) via terminal equipment (i.e., the first terminal in this disclosure). Typically, in traditional network architectures, this data transmission requires routing through base stations and multiple network elements (including UPFs) in the core network. However, in emergency situations, the core network may malfunction due to high load, faults, or physical damage, leading to increased latency and reduced reliability.

[0245] Based on the above issues, this disclosure introduces intelligent capabilities into the base station to identify direct communication requests between terminals and intelligently and dynamically determine whether to establish a data service session directly forwarded by the base station. This enables efficient data exchange between terminals within the same base station coverage area. The specific implementation steps are shown in Figure 23:

[0246] Step 1: The base station generates a direct data forwarding permission request between specific terminal pairs (i.e., the first message in this disclosure). This message may include: request type (user-level request), message identifier, base station identifier, terminal pair identifier, reason for communication request (i.e., there is a frequent and urgent need for interaction between the first terminal and the second terminal), permission description (including the application scope, validity period, and restrictions of the requested direct forwarding permission), QoS preferences, etc.

[0247] Step 2: After receiving a direct forwarding permission request from a base station, the NF in the core network determines whether to authorize direct forwarding based on network policies and available resources, and sends a direct forwarding permission response message (i.e., the second message in this disclosure) to the base station. This message may contain: request type (user-level request), message identifier, identifier of the target entity responding (i.e., the base station), indication information on whether permission is granted, authorization policy (including a description of the authorization scope (e.g., all sessions) (i.e., the scope of application of the permission in this disclosure), validity period of the permission, other restrictions and termination conditions of the permission (e.g., changes in the terminal's geographical location)), and QoS policy.

[0248] Step 3: After receiving the direct forwarding permission response message sent by the core network, the base station can configure resources and establish a data service session with direct forwarding routing according to the direct forwarding permission response message and actual communication needs.

[0249] Step 4: The base station periodically reports data service reports (including terminal communication volume and resource usage) to the core network (i.e., the base station sends session status information to the core network elements in this disclosure).

[0250] Step 5: When the base station detects that a specific condition (e.g., increased network load or decreased data traffic) requires termination of user-level direct forwarding privileges, the base station sends a direct forwarding privilege termination request message to the core network (i.e., the fifth message in this disclosure). This message may contain: the identifier of the terminal pair, a description of the termination reason, and any evidence or log information supporting the termination decision.

[0251] Step 6: After the core network receives the direct forwarding permission termination request message from the base station, it decides whether to terminate the authorization. If it decides to terminate the permission, the core network sends a direct forwarding permission termination message to the base station (i.e., message six in this disclosure). This message may contain: permission status (i.e., indication information for termination of permission), updated QoS parameters, updated resource allocation information, etc.

[0252] Step 7: After the base station receives the direct forwarding permission termination message sent by the core network, it can update the corresponding radio access network (RAN) configuration parameters according to the core network's decision. This may include QoS parameter updates and resource allocation changes.

[0253] Example: Terminals authorized by task-level permissions directly forward data.

[0254] Application scenarios corresponding to task-level requests: Interactive teaching projects are becoming an important means to improve learning efficiency and participation. Especially in video discussions involving multiple instructors and student groups simultaneously, higher demands are placed on network stability and response speed. In traditional network architectures, all data packets must undergo routing decisions and forwarding through the core network. However, this process is prone to latency and transmission bottlenecks when handling large-scale concurrent communication. For example, during frequent video interactions within a group, complex decision-making processes can lead to video stuttering or disconnections, severely impacting the teaching experience.

[0255] Based on the above issues, this disclosure introduces a direct forwarding mechanism from the base station as an effective strategy for optimizing network response. Specifically, before each interactive teaching project starts, the base station requests direct forwarding authorization from the core network for a specific time period. This means that for high-priority tasks such as video streaming and interactive Q&A within the group, data packets no longer need to undergo multi-layer processing by the core network, but are directly forwarded and routed by the base station. This significantly reduces latency and improves data transmission efficiency. The specific implementation steps are shown in Figure 24:

[0256] Step 1: In response to the aforementioned task requirements, the base station sends a direct data forwarding permission request (task-level) to the core network. This message may include: request type (task-level request), message identifier, base station identifier, terminal pair identifier, reason for communication request, task identifier, and task-related information description (e.g., task type (e.g., live video streaming), task priority, QoS standards required for task execution, estimated data transmission volume, security configuration requirements, etc.). The base station can initiate multiple requests to the core network in parallel for direct forwarding routing requirements between multiple terminal pairs.

[0257] Step 2: The core network receives the data direct forwarding permission request sent by the base station, assesses the demand and decides on the resource allocation strategy, and sends a direct forwarding permission response message to the base station. This message may contain: request type, message identifier, identifier of the target entity (i.e., the base station) responding to the message, status indication of whether the authorization request is granted (e.g., authorization is granted), task identifier, authorized QoS; and other task configurations.

[0258] Step 3: The base station directly forwards the permission request based on the data sent by the core network, configures radio resource blocks and dedicated QoS parameters to ensure the stability and smoothness of video content transmission.

[0259] Step 4: After the task is completed, the base station sends a direct forwarding permission termination message and a data service report to the core network. This message may include the task identifier, task status information (i.e., indication that the task has been completed), task resource report (including the amount of resources used during the execution of the task, to assist the core network in resource reclamation), and the base station's resumption of normal data processing procedures.

[0260] Example: Terminals based on session-level permission authorization directly forward data.

[0261] Application scenarios corresponding to session-level requests: In scenarios similar to those described in the embodiments, the base station may also request session-level direct forwarding permissions from the core network based on specific session requirements. The specific implementation steps are shown in Figure 25:

[0262] Step 1: In response to the session requirement, the base station sends a direct data forwarding permission request (session level) to the core network. This message may contain: request type (session level request), message identifier, base station identifier, terminal pair identifier, reason for communication request, session identifier, and session-related information description (including communication type description, estimated session duration, expected data exchange volume, QoS parameters, session termination conditions or trigger points), etc.

[0263] Step 2: The core network receives a direct forwarding permission request from the base station, assesses the demand, decides on a resource allocation strategy, and sends a direct forwarding permission response message to the base station. This message may contain: request type (session level), message identifier, identifier of the target entity (i.e., the base station) responding to the message, status indication of whether the request is authorized (e.g., authorization granted), session identifier, allocated resources, QoS parameters (i.e., the actual applicable QoS parameters), session monitoring strategy, etc.

[0264] Step 3: The base station can configure radio resource blocks and dedicated QoS parameters according to the instructions of the core network and monitor the session. When the current resource allocation no longer meets the required quality of service, the base station sends a session change request to the core network (i.e., the third message in this disclosure). This message may include: a session identifier, a description of the reason for the change (e.g., network congestion or changes in terminal mobility), a description of the change content (e.g., new QoS requirements), parameters to be changed (e.g., proposed QoS parameter updates), and current link performance metrics, etc.

[0265] Step 4: After receiving the session change request (i.e., the fourth message in this disclosure), the core network sends a session change response message to the base station, which contains the updated session parameters (i.e., the permission-related parameters in this disclosure).

[0266] Step 5: After the session ends, the base station sends a direct forwarding permission termination message and a data service report to the core network. This message may contain the session identifier, the conditions that triggered the session termination (e.g., session duration), and all key performance data during the session (e.g., packet latency and throughput). This allows the base station to release all relevant resources based on the information in the message.

[0267] Example, source and destination terminal pairing identification report and feedback.

[0268] After the core network receives the source-destination pairing identification report (i.e., the terminal pairing information in this disclosure) collected by the base station, it can achieve bottom-up and top-down data complementarity by fusing the local optimization perspective at the base station level with the core network's own global dataset. The core network can adjust resource allocation and traffic management strategies in a more refined manner to ensure priority for data transmission on critical paths. Simultaneously, it optimizes resource allocation on non-critical paths to maximize overall network efficiency. For the base station, continuous monitoring and analysis of potential direct connection opportunities between source and destination terminals not only helps the base station predict future network load and traffic patterns but also provides a basis for dynamic resource management and strategy adjustments. The specific implementation steps are shown in Figure 26.

[0269] Step 1: Based on the predicted terminal pairs, the base station generates a source-sink pairing identification report containing potential source-sink paired terminals and uploads it to the core network. This report details the terminal matching list identified based on the prediction results, including but not limited to the identifier of the first terminal, the identifier of the second terminal, and the predicted data traffic characteristics and potential needs.

[0270] Step 2: After receiving the report, the core network parses the terminal pairing information and assesses the accuracy of the predicted pairing. Based on the assessment results, the core network can send a source-destination terminal pairing feedback message (the terminal pairing feedback information in this disclosure) to the base station. This message may contain confirmation of the accuracy of the source-destination paired terminals (e.g., whether the pairing is accurate) or adjustment suggestions (e.g., whether the pairing model needs to be adjusted or the pairing strategy changed).

[0271] It is understood that, in order to achieve the above-mentioned functions, the communication device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the algorithmic steps of the examples described in conjunction with the embodiments of this disclosure, this disclosure can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.

[0272] This disclosure embodiment can divide the communication device into functional modules according to the above method embodiment. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into one functional module. The integrated module can be implemented in hardware or software. It should be noted that the module division in this disclosure embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods. The following description uses the example of dividing each functional module according to each function.

[0273] Figure 27 is a block diagram of a communication device according to some embodiments of the present disclosure. The communication device can be applied to a base station and execute the communication method shown in Figure 2 above. As shown in Figure 27, the communication device 2700 includes: a transmitting module 2701 and a receiving module 2702.

[0274] The sending module 2701 is used to send a first message to the core network element. The first message is used to request the base station to directly forward data between the first terminal and the second terminal.

[0275] The receiving module 2702 is used to receive a second message sent by a core network element. The second message is used to respond to the first message.

[0276] In some embodiments, the communication device 2700 further includes: a processing module 2703; the processing module 2703 is configured to establish a data service session with the first terminal and the second terminal for directly forwarding data between the first terminal and the second terminal when the second message indicates that the base station agrees to directly forward data between the first terminal and the second terminal.

[0277] In some embodiments, the sending module 2701 is further configured to send a third message to the core network element, the third message being used to request changes to permission-related parameters. The receiving module 2702 is further configured to receive a fourth message sent by the core network element, the fourth message being used to respond to the third message.

[0278] In some embodiments, the sending module 2701 is further configured to send a third message to the core network element when the request type of the first message is a session-level request and the authorized quality of service parameters included in the second message do not meet the required quality of service parameters, and / or the allocated network resources do not meet the required quality of service parameters. The sending module 2701 is also configured to send a third message to the core network element when the request type is a user-level request or a task-level request and the difference between the required quality of service parameters and the authorized quality of service parameters is greater than a preset difference.

[0279] In some embodiments, the sending module 2701 is further configured to send a fifth message to the core network element, the fifth message being used to request or notify termination of permissions.

[0280] In some embodiments, the receiving module 2702 is further configured to receive a sixth message sent by a core network element, the sixth message being used to notify whether to terminate the permission.

[0281] In some embodiments, the sending module 2701 is further configured to send session status information to the core network element; the session status information is used to characterize the status information of data forwarding based on the data service session.

[0282] In some embodiments, the sending module 2701 is further configured to send terminal pairing information to the core network element; the terminal pairing information includes at least one of the following: the correspondence between the first terminal and the second terminal, the predicted data traffic characteristics, and the potential demand information.

[0283] In some embodiments, the receiving module 2702 is further configured to receive terminal pairing feedback information sent by a core network element; the terminal pairing feedback information includes at least one of the following: indication information on whether the correspondence is correct, indication information on whether the pairing model needs to be adjusted, and adjustment strategy of the pairing model; the pairing model is used to predict the second terminal corresponding to the first terminal based on the first terminal.

[0284] In some embodiments, the processing module 2703 is further configured to determine terminal pairing information based on the data packet characteristics of the seventh message sent by the first terminal; the seventh message is used to request a session or data transmission with the second terminal.

[0285] Figure 28 is a block diagram of another communication device according to some embodiments of the present disclosure. The communication device 2800 can be applied to core network elements and execute the communication method shown in Figure 18 above. As shown in Figure 28, the communication device 2800 includes: a receiving module 2801 and a transmitting module 2802.

[0286] The receiving module 2801 is used to receive a first message sent by the base station. The first message is used to request the base station to grant permission to directly forward data between the first terminal and the second terminal.

[0287] The sending module 2802 is used to send a second message to the base station, and the second message is used to respond to the first message.

[0288] In some embodiments, the sending module 2802 is further configured to send a second message to the base station if the network policy allows for granting permissions and / or if available resources can satisfy the required quality of service parameters included in the first message.

[0289] In some embodiments, the receiving module 2801 is further configured to receive a third message sent by the base station, the third message being used to request changes to permission-related parameters; the sending module 2802 is further configured to send a fourth message to the base station, the fourth message being used to respond to the third message.

[0290] In some embodiments, the sending module 2802 is further configured to send a fourth message to the base station if available resources can satisfy the updated permission-related parameters.

[0291] In some embodiments, the receiving module 2801 is further configured to receive a fifth message sent by the base station, the fifth message being used to request or notify termination of permissions.

[0292] In some embodiments, the sending module 2802 is further configured to send a sixth message to the base station, the sixth message being used to notify whether the permission is terminated.

[0293] In some embodiments, the receiving module 2801 is further configured to receive session state information sent by the base station; the session state information is used to characterize the state information of data forwarding based on the data service session.

[0294] In some embodiments, the communication device 2800 further includes: a determination module 2803; the determination module 2803 is configured to determine, based on session state information, whether to send an eighth message to the base station, the eighth message being used to notify whether to terminate or change permissions.

[0295] In some embodiments, the receiving module 2801 is further configured to receive terminal pairing information sent by the base station; the terminal pairing information includes at least one of the following: the correspondence between the first terminal and the second terminal, the predicted data traffic characteristics, and the potential demand information.

[0296] In some embodiments, the sending module 2802 is further configured to send terminal pairing feedback information to the base station; the terminal pairing feedback information includes at least one of the following: indication information on whether the correspondence is correct, indication information on whether the pairing model needs to be adjusted, and adjustment strategy of the pairing model; the pairing model is used to predict the second terminal corresponding to the first terminal based on the first terminal.

[0297] In implementing the functions of the integrated modules described above in hardware, this disclosure provides another structure for the communication device involved in the above embodiments. As shown in FIG29, the communication device 2900 includes a processor 2902 and a bus 2904. In some embodiments, the communication device may further include a memory 2901. In some embodiments, the communication device may further include a communication interface 2903.

[0298] Processor 2902 may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with embodiments of this disclosure. Processor 2902 may be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with embodiments of this disclosure. Processor 2902 may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a digital signal processor (DSP), and a microprocessor, etc.

[0299] The communication interface 2903 is used to connect to other devices via a communication network. This communication network can be Ethernet, wireless access network, wireless local area network (WLAN), etc.

[0300] The memory 2901 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), disk storage medium or other magnetic storage device, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0301] In some embodiments, the memory 2901 may exist independently of the processor 2902. The memory 2901 may be connected to the processor 2902 via a bus 2904 and may be used to store instructions or program code. When the processor 2902 calls and executes the instructions or program code stored in the memory 2901, it can implement the communication method provided in the embodiments of this disclosure.

[0302] In other embodiments, the memory 2901 may also be integrated with the processor 2902.

[0303] Bus 2904 can be an extended industry standard architecture (EISA) bus, etc. Bus 2904 can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in Figure 29, but this does not mean that there is only one bus or one type of bus.

[0304] Some embodiments of this disclosure provide a computer-readable storage medium (e.g., a non-transitory computer-readable storage medium) storing computer program instructions that, when executed on a computer, cause the computer to perform a communication method as described in any of the above embodiments.

[0305] Exemplary examples show that the aforementioned computer-readable storage media may include, but are not limited to: magnetic storage devices (e.g., hard disks, floppy disks, or magnetic tapes), optical discs (e.g., compact disks, digital versatile disks, DVDs), smart cards, and flash memory devices (e.g., erasable programmable read-only memory, EPROMs), cards, sticks, or key drives, etc.). The various computer-readable storage media described in this disclosure may represent one or more devices and / or other machine-readable storage media for storing information. The term "machine-readable storage medium" may include, but is not limited to, wireless channels and various other media capable of storing, containing, and / or carrying instructions and / or data.

[0306] This disclosure provides a computer program product containing instructions that, when run on a computer, cause the computer to perform the communication method described in any of the above embodiments.

[0307] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any changes or substitutions within the technical scope disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A communication method, wherein, Applied to base stations, including: Send a first message to the core network element, the first message being used to request the base station to grant the base station permission to directly forward data between the first terminal and the second terminal; The system receives a second message sent by the core network element, the second message being used in response to the first message.

2. The method according to claim 1, wherein, The first message includes at least one of the following: request type, message identifier of the first message, identifier of the sender of the first message, identifier of the first terminal, identifier of the second terminal, identifier of the base station through which the data between the first terminal and the second terminal is forwarded, required quality of service parameters, identifier of the terminal pair consisting of the first terminal and the second terminal, explanation of authorization reason, and explanation of estimated performance impact.

3. The method according to claim 2, wherein, The request type includes at least one of the following: user-level request, session-level request, and task-level request.

4. The method according to claim 2, wherein, When the request type includes a user-level request, the first message further includes at least one of the following: the scope of application of the permission, the validity period of the permission, and the restrictions on the permission; or, When the request type includes a session-level request, the first message further includes at least one of the following: the identifier of the session to be authorized, the communication type of the session, the estimated duration of the session, the estimated data exchange volume of the session, and the triggering condition for the end of the session. or, When the request type includes a task-level request, the first message further includes at least one of the following: the identifier of the task corresponding to the first message, the type of the task, the priority of the task, the estimated data transmission volume of the task, and the security configuration requirements of the task.

5. The method according to claim 1, wherein, The second message includes at least one of the following: the request type responded to by the second message, the message identifier of the second message, the identifier of the recipient of the second message, and indication information indicating whether the permission is granted.

6. The method according to claim 5, wherein, When the request type includes a user-level request, the second message further includes at least one of the following: the scope of application of the permission, the validity period of the permission, the restrictions on the permission, and authorization service quality parameters; or, When the request type includes a session-level request, the second message further includes at least one of the following: network resources allocated for the authorized session, authorized quality of service parameters, performance metrics to be reported by the session, time interval for reporting the performance metrics, notification procedure for the end of the session, and identifier of the session; or, If the request type includes a task-level request, the second message also includes at least one of the following: authorized service quality parameters, security policy, and restrictions on the permission.

7. The method according to claim 1, wherein, The method further includes: If the second message indicates agreement to allow the base station to directly forward data between the first terminal and the second terminal, a data service session for directly forwarding data between the first terminal and the second terminal is established with the first terminal and the second terminal.

8. The method according to claim 1, wherein, The method further includes: Send a third message to the core network element, the third message being used to request changes to the permission-related parameters of the permission; The system receives a fourth message sent by the core network element, which is used to respond to the third message.

9. The method according to claim 8, wherein, The third message includes at least one of the following: the identifier of the session to be changed, the reason for the change, the content of the change, the parameters to be changed, and the performance indicators of the session.

10. The method according to claim 8, wherein, The fourth message includes: the updated permission-related parameters.

11. The method according to claim 8, wherein, Sending the third message to the core network element includes: If the request type of the first message includes a session-level request and the authorized quality of service parameters included in the second message do not meet the required quality of service parameters, and / or if the request type of the first message includes a session-level request and the allocated network resources do not meet the required quality of service parameters, the third message is sent to the core network element; or, When the request type includes a user-level request or a task-level request, and the difference between the required quality of service parameter and the authorized quality of service parameter is greater than a preset difference, the third message is sent to the core network element.

12. The method according to claim 8, wherein, The permission-related parameters include at least one of the following: authorized service quality parameters and allocated network resources.

13. The method according to claim 1, wherein, The method further includes: A fifth message is sent to the core network element, the fifth message being used to request the termination of the permission or to notify the termination of the permission.

14. The method according to claim 13, wherein, If the request type of the first message includes a user-level request, the fifth message includes at least one of the following: the identifier of the first terminal, the identifier of the second terminal, a statement of the reason for termination, and evidence supporting the termination; or, When the request type includes a session-level request, the fifth message includes at least one of the following: an identifier of the session to be terminated, a triggering condition for terminating the session, and the resource usage status when the session ends; or, When the request type includes a task-level request, the fifth message includes at least one of the following: the identifier of the task to be terminated, the status information of the task to be terminated, and the resource usage of the task to be terminated.

15. The method according to claim 1, wherein, The method further includes: The system receives a sixth message from the core network element, which is used to notify whether to terminate the permission.

16. The method according to claim 15, wherein, The sixth message includes at least one of the following: an instruction on whether to terminate the permission, updated service quality parameters, and updated resource allocation information.

17. The method according to claim 1, wherein, After receiving the second message sent by the core network element, the method further includes: Send session status information to the core network element; the session status information is used to characterize the status information of data forwarding based on data service sessions.

18. The method according to claim 17, wherein, When the request type of the first message includes a user-level request, the session state information includes at least one of the following: the data transmission rate of the first terminal, the traffic consumption of the first terminal, the active time percentage of the first terminal, the data transmission rate of the second terminal, the traffic consumption of the second terminal, and the active time percentage of the second terminal. or, When the request type includes a session-level request, the session state information includes at least one of the following: session quality monitoring data, session event logs; or, When the request type includes a task-level request, the session state information includes at least one of the following: the progress of task execution, the current status of the task, and a resource utilization efficiency analysis.

19. The method according to claim 1, wherein, Before sending the first message to the core network element, the method further includes: Send terminal pairing information to the core network element; the terminal pairing information includes at least one of the following: the correspondence between the first terminal and the second terminal, the predicted data traffic characteristics, and the potential demand information.

20. The method according to claim 19, wherein, The method further includes: The system receives terminal pairing feedback information sent by the core network element; the terminal pairing feedback information includes at least one of the following: indication information on whether the correspondence is correct, indication information on whether the pairing model needs to be adjusted, and adjustment strategy of the pairing model; the pairing model is used to predict the second terminal corresponding to the first terminal based on the first terminal.

21. The method according to claim 19, wherein, The method further includes: Based on the data packet characteristics of the seventh message sent by the first terminal, the terminal pairing information is determined; the seventh message is used to request a session or data transmission with the second terminal.

22. A communication method, wherein, Applied to core network elements, the method includes: The system receives a first message sent by the base station, the first message being used to request the base station to grant the base station permission to directly forward data between the first terminal and the second terminal. A second message is sent to the base station, the second message being a response to the first message.

23. The method according to claim 22, wherein, The first message includes at least one of the following: request type, message identifier of the first message, identifier of the sender of the first message, identifier of the first terminal, identifier of the second terminal, identifier of the base station through which the data between the first terminal and the second terminal is forwarded, required quality of service parameters, identifier of the terminal pair consisting of the first terminal and the second terminal, explanation of authorization reason, and explanation of estimated performance impact.

24. The method according to claim 23, wherein, The request type includes at least one of the following: user-level request, session-level request, and task-level request.

25. The method according to claim 23, wherein, When the request type includes a user-level request, the first message further includes at least one of the following: the scope of application of the permission, the validity period of the permission, and the restrictions on the permission; or, When the request type includes a session-level request, the first message further includes at least one of the following: the identifier of the session to be authorized, the communication type of the session, the estimated duration of the session, the estimated data exchange volume of the session, and the triggering condition for the end of the session. or, When the request type includes a task-level request, the first message further includes at least one of the following: the identifier of the task corresponding to the first message, the type of the task, the priority of the task, the estimated data transmission volume of the task, and the security configuration requirements of the task.

26. The method according to claim 22, wherein, The second message includes at least one of the following: the request type responded to by the second message, the message identifier of the second message, the identifier of the recipient of the second message, and indication information indicating whether the permission is granted.

27. The method according to claim 26, wherein, When the request type includes a user-level request, the second message further includes at least one of the following: the scope of application of the permission, the validity period of the permission, the restrictions on the permission, and authorization service quality parameters; or, When the request type includes a session-level request, the second message further includes at least one of the following: network resources allocated for the authorized session, authorized quality of service parameters, performance metrics to be reported by the session, time interval for reporting the performance metrics, notification procedure for the end of the session, and identifier of the session; or, If the request type includes a task-level request, the second message also includes at least one of the following: authorized service quality parameters, security policy, and restrictions on the permission.

28. The method according to claim 22, wherein, Sending the second message to the base station includes: The second message is sent to the base station if the network policy allows the granting of the permission, and / or if the available resources can satisfy the required quality of service parameters included in the first message.

29. The method according to claim 22, wherein, The method further includes: Receive a third message sent by the base station, the third message being used to request changes to the permission-related parameters of the permission; A fourth message is sent to the base station, the fourth message being used in response to the third message.

30. The method according to claim 29, wherein, Sending the fourth message to the base station includes: If available resources can satisfy the updated permission-related parameters, the fourth message is sent to the base station.

31. The method according to claim 29, wherein, The third message includes at least one of the following: the identifier of the session to be changed, the reason for the change, the content of the change, the parameters to be changed, and the performance indicators of the session.

32. The method according to claim 29, wherein, The fourth message includes: the updated permission-related parameters.

33. The method according to claim 29, wherein, The permission-related parameters include at least one of the following: authorized service quality parameters and allocated network resources.

34. The method according to claim 22, wherein, The method further includes: The system receives a fifth message sent by the base station, which is used to request the termination of the permission or to notify the termination of the permission.

35. The method according to claim 34, wherein, If the request type of the first message includes a user-level request, the fifth message includes at least one of the following: the identifier of the first terminal, the identifier of the second terminal, a statement of the reason for termination, and evidence supporting the termination; or, When the request type includes a session-level request, the fifth message includes at least one of the following: an identifier of the session to be terminated, a triggering condition for terminating the session, and the resource usage status when the session ends; or, When the request type includes a task-level request, the fifth message includes at least one of the following: the identifier of the task to be terminated, the status information of the task to be terminated, and the resource usage of the task to be terminated.

36. The method according to claim 22, wherein, The method further includes: A sixth message is sent to the base station, the sixth message being used to notify whether the permission is terminated.

37. The method according to claim 36, wherein, The sixth message includes at least one of the following: an instruction on whether to terminate the permission, updated service quality parameters, and updated resource allocation information.

38. The method according to claim 22, wherein, After sending the second message to the base station, the method further includes: The system receives session state information sent by the base station; the session state information is used to characterize the state information of data forwarding based on the data service session.

39. The method according to claim 38, wherein, When the request type of the first message includes a user-level request, the session state information includes at least one of the following: the data transmission rate of the first terminal, the traffic consumption of the first terminal, the active time percentage of the first terminal, the data transmission rate of the second terminal, the traffic consumption of the second terminal, and the active time percentage of the second terminal. or, When the request type includes a session-level request, the session state information includes at least one of the following: session quality monitoring data, session event logs; or, When the request type includes a task-level request, the session state information includes at least one of the following: the progress of task execution, the current status of the task, and a resource utilization efficiency analysis.

40. The method of claim 38, wherein, The method further includes: Based on the session state information, it is determined whether to send an eighth message to the base station. The eighth message is used to notify whether to terminate or change the permissions.

41. The method according to claim 22, wherein, Before receiving the first message sent by the base station, the method further includes: The terminal pairing information sent by the base station is received; the terminal pairing information includes at least one of the following: the correspondence between the first terminal and the second terminal, the predicted data traffic characteristics, and the potential demand information.

42. The method according to claim 41, wherein, The method further includes: The terminal pairing feedback information is sent to the base station; the terminal pairing feedback information includes at least one of the following: an indication of whether the correspondence is correct, an indication of whether the pairing model needs to be adjusted, and an adjustment strategy for the pairing model; the pairing model is used to predict the second terminal corresponding to the first terminal based on the first terminal.

43. A communication device, wherein, include: Memory and processor; The memory and the processor are coupled; The memory is used to store instructions that can be executed by the processor; When the processor executes the instructions, it performs the method as described in any one of claims 1-42.

44. A computer-readable storage medium, wherein, The computer-readable storage medium includes a non-transitory computer-readable storage medium on which computer instructions are stored, which, when executed on a computer, cause the computer to perform the method as described in any one of claims 1-42.

45. A computer program product, wherein, The computer program product includes computer program instructions that, when executed, implement the method as described in any one of claims 1-42.

Images