Information transmission method and communication apparatus

Abstract

An information transmission method and a communication apparatus, which can reestablish an uplink RDS link in a timely manner, so as to resume service transmission as soon as possible. The method comprises: when a network exposure network element serving a terminal is reselected as a first network exposure network element, a session management network element and the first network exposure network element establishing context of a protocol data unit (PDU) session, wherein the PDU session is a session between the terminal and the first network exposure network element; and when the context of the PDU session is successfully established, the session management network element sending indication information to the terminal, wherein the indication information is configured to indicate the negotiation for reestablishing an uplink reliable data service (RDS) link, and the uplink RDS link is borne on the PDU session.

Description

Information transmission method and communication device

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on March 25, 2024, with application number 202410360429.5 and application name “Information Transmission Method and Communication Device”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of communications, and in particular to an information transmission method and a communication device. Background Art

[0003] Non-Internet Protocol (IP) data delivery (NIDD) can be used to handle mobile originated (MO) and mobile terminated (MT) services for unstructured data (also known as non-IP data). NIDD can be handled using an unstructured protocol data unit (PDU) session between a terminal and a network exposure function (NEF). When using an unstructured PDU session, a reliable data service (RDS) can be enabled between the terminal and the NEF. The RDS can be used by the NEF to determine whether downlink data (e.g., MT data) has been successfully sent to the terminal, and by the terminal to determine whether uplink data (e.g., MO data) has been successfully sent to the NEF.

[0004] Currently, when a network-side NEF fails over due to a failure, the new NEF must reestablish an uplink RDS link with the terminal to resume service transmission. However, the RDS protocol stipulates that the uplink RDS link re-establishment process is triggered only when the data transmission timer has timed out for a maximum of preset times. This can result in the uplink RDS link not being re-established in a timely manner, impacting service transmission. Summary of the Invention

[0005] The information transmission method and communication device provided in the embodiments of the present application can promptly reestablish the uplink RDS link and resume service transmission as soon as possible.

[0006] To achieve the above objectives, the embodiments of the present application adopt the following technical solutions:

[0007] In a first aspect, an information transmission method is provided, which includes: when a network open network element serving a terminal is reselected as a first network open network element, a session management network element establishes a context of a protocol data unit PDU session with the first network open network element, where the PDU session is a session between the terminal and the first network open network element; when the context of the PDU session is successfully established, the session management network element sends indication information to the terminal, where the indication information is used to instruct negotiation to re-establish an uplink reliable data service RDS link, where the uplink RDS link is carried by the PDU session.

[0008] Because in the embodiment of the present application, the session management network element can instruct the terminal to negotiate and rebuild the uplink RDS link associated with the PDU session when the context of the PDU session is successfully established, and thus the uplink RDS link can be rebuilt in a timely manner to resume service transmission as soon as possible.

[0009] In a possible implementation, reselecting the network open network element serving the terminal as the first network open network element includes:

[0010] The session management network element determines, based on the subscription change information provided by the data management network element, that the open network element serving the terminal should be reselected from the second open network element to the first open network element. The subscription change information indicates that the Non-Internet Interconnection Protocol Data Transfer (NIDD) information associated with the second open network element should be changed to be associated with the first open network element. In other words, the session management network element can determine, based on the subscription change information provided by the data management network element, that the open network element serving the terminal should be reselected from the second open network element to the first open network element. The session management network element then initiates a context for establishing a PDU session between the session management network element and the first open network element, thereby completing the connection establishment process between the session management network element and the first open network element in the PDU session.

[0011] In one possible implementation, the reselection of the open network element serving the terminal as the first open network element includes: when the session management network element fails to send uplink data to the open network element serving the terminal, the session management network element reselects the first open network element from the second open network element serving the terminal. In other words, when the session management network element fails to send uplink data to the second open network element serving the terminal, the session management network element may reselect the first open network element from the second open network element serving the terminal, thereby initiating a context for establishing a PDU session between the session management network element and the first open network element, thereby completing a connection establishment process between the session management network element and the first open network element in the PDU session. In one possible implementation, the session management network element receives subscription change information from the data management network element, where the subscription change information indicates that NIDD information associated with the second open network element is changed to be associated with the first open network element. That is to say, after sending a session context request message to the first network open network element, the session management network element can receive contract change information from the data management network element. Then, the session management network element can further determine, based on the contract change information, which NIDD information among the multiple NIDD information associated with the second network open network element before reselection has actually been authenticated and changed by the data management network element to the corresponding network open network element. Therefore, based on the application network element identifier included in the actually changed NIDD information, it can be determined which uplink RDS links corresponding to the application network element identifiers among the multiple uplink RDS links associated with the PDU session need to be negotiated and rebuilt.

[0012] In one possible implementation, the NIDD information associated with the second network open network element is a plurality of NIDD information, and the contract change information is specifically used to indicate that the second network open network element associated with the first NIDD information is changed to be associated with the first network open network element, and the first NIDD information is NIDD information including the first application network element identifier in the plurality of NIDD information. In other words, the contract change information can be specifically used to indicate that the second network open network element associated with the first NIDD information including the first application network element identifier is changed to be associated with the first network open network element. The session management network element can then determine, based on the contract change information, that the NIDD information of the changed network development network element is the first NIDD information corresponding to the first application network element identifier, and can determine that the downlink data of the first application network element cannot be transmitted through the second network open network element, thereby determining that the RDS link corresponding to the first application network element identifier among the multiple RDS links associated with the PDU session should be negotiated and rebuilt to transmit the downlink data of the first application network element.

[0013] In one possible implementation, the indication information is specifically used to instruct negotiation to reestablish the uplink RDS link corresponding to the first application network element identifier. That is, when a PDU session is associated with multiple uplink RDS links, the session management network element may instruct negotiation to reestablish the uplink RDS link corresponding to the first application network element that failed to send data to the first network open network element.

[0014] According to a second aspect, an information transmission method is provided, which includes: a terminal receives first information, the first information being used to indicate negotiation to reconstruct an uplink reliable data service RDS link carried by a protocol data unit PDU session, or to request negotiation to reconstruct a downlink RDS link carried by a PDU session, where the PDU session is a session between the terminal and an open network element of a network serving the terminal; and the terminal initiates a negotiation reconstruction process of the uplink RDS link based on the first information.

[0015] In the embodiment of the present application, the terminal does not need to initiate the negotiation and reconstruction process of the uplink RDS link when the number of retransmissions exceeds the preset maximum number of retransmissions. Instead, upon receiving the downlink RDS link negotiation and reconstruction request associated with the PDU session, the terminal actively initiates the uplink RDS link negotiation associated with the PDU session, thereby being able to promptly reconstruct the uplink RDS link and resume service transmission as soon as possible.

[0016] It is understood that the information transmission method described in the second aspect can be performed by a communication device, which can be a terminal, a device including a terminal, or a chip within a terminal. For ease of description, the following description uses the information transmission method described in the second aspect performed by a terminal as an example.

[0017] In one possible implementation, the uplink RDS link is a plurality of uplink RDS links, and the plurality of uplink RDS links include an uplink RDS link corresponding to each application network element identifier among a plurality of application network element identifiers associated with the PDU session, and the indication information is specifically used to indicate the negotiation to reconstruct the uplink RDS link corresponding to the first application network element identifier among the plurality of application network element identifiers; the terminal initiates the negotiation and reconstruction process of the uplink RDS link according to the first information, specifically including: the terminal initiates the negotiation and reconstruction process of the uplink RDS link corresponding to the first application network element identifier according to the first information. That is to say, in the case where the PDU session is associated with a plurality of uplink RDS links, the terminal side stores the application IDs corresponding to the plurality of uplink RDS links, and based on the fact that the application ID is the same as the application network element identifier, the terminal can initiate the negotiation and reconstruction process of the uplink RDS link corresponding to the first application network element identifier according to the first application network element identifier indicated by the indication information.

[0018] In one possible implementation, the first information is specifically used to request negotiation to reestablish a first downlink RDS link among multiple downlink RDS links associated with a PDU session; the terminal initiates a negotiation and reestablishment process for an uplink RDS link based on the first information, specifically including: the terminal initiates a negotiation and reestablishment process for a first uplink RDS link corresponding to the first downlink RDS link based on the first information. In other words, when the negotiation request message specifically requests negotiation and reestablishment of the first downlink RDS link among multiple downlink RDS links associated with a PDU session, the terminal can initiate a negotiation and reestablishment process for the first uplink RDS link corresponding to the first downlink RDS link, thereby enabling connectivity between the uplink and downlink RDS links between the terminal and the application network element corresponding to the first uplink RDS link, thereby restoring uplink and downlink service transmission.

[0019] According to a third aspect, an information transmission method is provided, which includes: a first network open network element and a session management network element establish a context of a protocol data unit (PDU) session, where the PDU session is a session between a terminal and a network open network element serving the terminal; when the context of the PDU session is successfully established, the first network open network element sends first information to the terminal, where the first information is used to request negotiation to establish a downlink reliable data service (RDS) link, and the downlink RDS link is carried by the PDU session.

[0020] Since in the embodiment of the present application, the second network open network element can actively initiate the negotiation and reconstruction process of the downlink RDS link after generating the context of the PDU session, the downlink RDS link can be rebuilt in time and downlink data transmission can be restored as soon as possible.

[0021] In one possible implementation, the context includes an NIDD configuration associated with a first application network element identifier; the first information is specifically used to request negotiation to establish a downlink RDS link corresponding to the first application network element identifier among multiple downlink RDS links carried by the PDU session. That is, when the PDU session is associated with multiple downlink RDS links, the first network open network element may indicate to the terminal which downlink RDS link to negotiate to establish among the multiple downlink RDS links based on the first application network element identifier associated with the NIDD configuration included in the session context, or a pair of port numbers corresponding to the first application network element identifier.

[0022] In a fourth aspect, an information transmission method is provided, which includes: an application network element obtains relevant information of a network open network element set, the network open network element set includes multiple network open network elements that support reliable data service RDS information synchronization between network open network elements, and the RDS information includes a non-Internet interconnection protocol data transmission NIDD configuration for carrying the RDS link; in the NIDD configuration process corresponding to the terminal, the application network element sends relevant information to the network where the terminal is located, and the network where the terminal is located is used to provide services for the RDS link corresponding to the terminal.

[0023] Since in the embodiment of the present application, the application network element can transmit relevant information of the network open network element set through the NIDD configuration process at the session level, the network where the terminal is located can obtain relevant information, and thus support reselection of the network open network element within the network open network element set when the network open network element serving the terminal fails to facilitate smooth switching of the RDS link, thereby making little change to the system, having good compatibility, and reducing implementation complexity.

[0024] In one possible implementation, an application network element sends relevant information to the network where the terminal resides, including: the application network element sends a first request message to an open network element serving the terminal, the first request message including parameters for generating a NIDD configuration corresponding to the terminal, the parameters including relevant information; in response to the first request message, the open network element serving the terminal sends a second request message to a data management network element, the second request message requesting authentication of the first request message. If the first request message is authenticated, the data management network element associates the relevant information with the NIDD information corresponding to the open network element serving the terminal. In other words, the data management network element associates the relevant information with the terminal's subscription information, thereby enabling a network-side session management network element to obtain the relevant information when subscribing to the terminal's subscription information or change notification information. Furthermore, upon detecting a failure of the first open network element, the session management network element can reselect a second open network element from a set of open network elements.

[0025] In a possible implementation, the method provided in the fourth aspect further includes: in the process of establishing a protocol data unit (PDU) session, the data management network sends relevant information to the session management network element in response to a subscription request message from the session management network element associated with the PDU session, where the PDU session is a PDU session between the terminal and the network open network element serving the terminal. In other words, the session management network element can obtain relevant information from the data management network element when the context of the terminal is established, and then the session management network element can select a second network open network element from multiple network open network elements based on the relevant information when data fails to be sent to the first network open network element, thereby achieving smooth switching of the first network open network element in the PDU session to the second network open network element, so that the RDS link does not need to be re-established through negotiation.

[0026] In one possible implementation, the method provided in the fourth aspect further includes: a session management network element receiving first uplink data from a terminal according to a PDU session; in the event that the session management network element fails to send the first uplink data to the network open network element serving the terminal, the session management network element reselects the network open network element serving the terminal from the first network open network element to a second network open network element based on relevant information; the session management network element sends the first uplink data to the second network open network element; the second network open network element processes the first uplink data according to the NIDD configuration associated with the first network open network element to obtain second uplink data; and the second network open network element sends the second uplink data to the application network element. In other words, after the session management obtains the relevant information, it can reselect the second network open network element based on the relevant information when a failure of the first network open network element is detected, so as to achieve smooth switching from the first network open network element to the second network open network element in the PDU session, thereby eliminating the need to reestablish the RDS link.

[0027] In one possible implementation, the method provided in the fourth aspect further includes: when the application network element fails to send the first downlink data corresponding to the terminal to the network open network element serving the terminal, the application network element reselects the network open network element serving the terminal from the first network open network element to the second network open network element based on the relevant information; the application network element sends the first downlink data to the second network open network element; the second network open network element processes the first downlink data according to the NIDD configuration associated with the first network open network element to obtain the second downlink data; the second network open network element sends the second downlink data to the session management network element, which is the session management network element associated with the PDU session between the terminal and the second network open network element; the session management network element sends the second downlink data to the terminal. In other words, after obtaining the relevant information, the application management network element can reselect the second network open network element based on the relevant information when a failure of the first network open network element is discovered, so as to achieve smooth switching from the first network open network element to the second network open network element in the PDU session, thereby eliminating the need to rebuild the RDS link.

[0028] In one possible implementation, the second downlink data also includes: relevant information, and a second network open network element identifier for identifying the second network open network element; the method provided in the fourth aspect further includes: the session management network element determines, based on the relevant information and the second network open network element identifier, that the first network open network element associated with the PDU session is changed to an associated second network open network element. In other words, the second network open network element can determine, based on the relevant information and the second network open network element identifier, that the first network open network element in the PDU session is reselected as the second network open network element, and then, when sending the uplink data corresponding to the PDU session, can send the uplink data to the second network open network element. In addition, in the case where the session management network element does not obtain the relevant information, it can also obtain the relevant information by receiving the relevant information from the second network open network element in the downlink data sending process.

[0029] In a fifth aspect, an information transmission method is provided, which includes: in the non-Internet interconnection protocol data transmission NIDD configuration process corresponding to the terminal, the network open network element serving the terminal receives a first request message from the application network element, the first request message includes parameters for generating the NIDD configuration corresponding to the terminal, the parameters include relevant information of a set of network open network elements, the set of network open network elements includes multiple network open network elements that support reliable data service RDS information synchronization between network open network elements, and the RDS information includes the NIDD configuration for carrying the RDS link; the network open network element serving the terminal sends a second request message to the data management network element, and the second request message is used to request authentication of the first request message.

[0030] Among them, the beneficial effects of the fifth aspect can be found in the fourth aspect and will not be repeated here.

[0031] In a sixth aspect, an information transmission method is provided, which includes: in the non-Internet interconnection protocol data transmission NIDD configuration process corresponding to the terminal, the data management network element receives a second request message from the network open network element serving the terminal, the second request message is used to request authentication of the first request message, the first request message includes parameters for generating the NIDD configuration corresponding to the terminal, the parameters include relevant information of a set of network open network elements, the set of network open network elements includes multiple network open network elements that support reliable data service RDS information synchronization between network open network elements, and the RDS information includes the NIDD configuration for carrying the RDS link; if the parameter authentication is passed, the data management network element associates the relevant information with the NIDD information corresponding to the network open network element serving the terminal.

[0032] Among them, the beneficial effects of the sixth aspect can be specifically referred to the fourth aspect and will not be repeated here.

[0033] In the seventh aspect, a communication device is provided for implementing the various methods mentioned above. The communication device can be the session management network element in any of the above aspects or any of its implementations, or a device including the above session management network element, or a device included in the above session management network element, such as a chip; or the communication device can be the terminal in any of the above aspects or any of its implementations, or a device including the above terminal, or a device included in the above terminal, such as a chip; or the communication device can be the second network open network element in any of the above aspects or any of its implementations, or a device including the second network open network element, or a device included in the second network open network element, such as a chip; or the communication device can be the application in any of the above aspects. The communication device may be a first network open network element in any of the above aspects, or a device including the above-mentioned first network open network element, or a device included in the above-mentioned first network open network element; or the communication device may be a data management network element in any of the above aspects, or a device including the above-mentioned data management, or a device included in the above-mentioned data management; the communication device includes a module, unit, or means corresponding to the implementation of the above-mentioned method, which may be implemented by hardware, software, or by hardware executing the corresponding software implementation. The hardware or software includes one or more modules or units corresponding to the above-mentioned functions.

[0034] In some possible designs, the communication device may include a processing module and a transceiver module. The transceiver module, also referred to as a transceiver unit, is configured to implement the transmitting and / or receiving functions described in any of the above aspects and any possible implementations thereof. The transceiver module may be comprised of a transceiver circuit, a transceiver, a transceiver, or a communication interface. The processing module may be configured to implement the processing functions described in any of the above aspects and any possible implementations thereof.

[0035] In some possible designs, the transceiver module includes a sending module and a receiving module, which are respectively used to implement the sending and receiving functions in any of the above aspects and any possible implementation methods.

[0036] In an eighth aspect, a communication device is provided, comprising: at least one processor; the processor is configured to execute a computer program or instruction so that the communication device executes the method described in any one of the above aspects.

[0037] In one possible implementation, the communication device further includes the memory. Optionally, the memory is coupled to the processor, the memory may be integrated with the processor, or the memory may be independent of the processor. Optionally, the processor is configured to execute computer programs or instructions stored in the memory.

[0038] In a possible implementation, the memory is independent of the communication device.

[0039] In a possible implementation, the communication device further includes a communication interface, which is used to communicate with a module outside the communication device.

[0040] The communication device may be the session management network element in any of the aforementioned aspects or any of its implementations, or a device including the session management network element, or a device included in the session management network element, such as a chip; or the communication device may be the terminal in any of the aforementioned aspects or any of its implementations, or a device including the terminal, or a device included in the terminal, such as a chip; or the communication device may be the application network element in any of the aforementioned aspects or any of its implementations, or a device including the application network element, or a device included in the application network element, such as a chip; or the communication device may be the first network open network element in any of the aforementioned aspects or any of its implementations, or a device including the first network open network element, or a device included in the first network open network element, such as a chip; or the communication device may be the data management network element in any of the aforementioned aspects or any of its implementations, or a device including the data management network element, or a device included in the data management network element, such as a chip;

[0041] In a ninth aspect, a computer-readable storage medium is provided, which stores a computer program or instruction. When the computer-readable storage medium is run on a communication device, the communication device can execute the method described in any one of the above aspects or any one of its implementation methods.

[0042] In a tenth aspect, a computer program product comprising instructions is provided, which, when executed on a communication device, enables the communication device to execute the method described in any one of the above aspects or any one of its implementations.

[0043] In the eleventh aspect, a communication device is provided (for example, the communication device may be a chip or a chip system), which includes a processor for implementing the functions involved in any of the above aspects or any of its implementation methods.

[0044] In some possible designs, the communication device includes a memory for storing necessary program instructions and data.

[0045] In some possible designs, when the device is a chip system, it can be composed of a chip or include a chip and other discrete devices.

[0046] It can be understood that when the communication device provided in any one of the seventh to eleventh aspects is a chip, the above-mentioned sending action / function can be understood as output, and the above-mentioned receiving action / function can be understood as input.

[0047] Among them, the technical effects brought about by any design method in the seventh to eleventh aspects can refer to the technical effects brought about by the different design methods in the third aspect mentioned above, and will not be repeated here.

[0048] In the twelfth aspect, a communication system is provided, which includes: the session management network element of the above-mentioned first aspect or any implementation thereof, and the terminal of the above-mentioned second aspect or any implementation thereof; or, the communication system includes: the terminal of the above-mentioned second aspect or any implementation thereof, and the second network session open network element of the above-mentioned third aspect or any implementation thereof; or, the communication system includes: the application network element of the above-mentioned fourth to sixth aspects or any implementation thereof, the first network open network element of the above-mentioned fourth to sixth aspects or any implementation thereof, and the data management network element of the above-mentioned fourth to sixth aspects or any implementation thereof.

[0049] In a possible implementation, the communication system further includes the data management network element in the fourth aspect or any implementation thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] FIG1 is a schematic diagram of a 5GS service-oriented architecture provided in an embodiment of the present application;

[0051] FIG2 is a schematic diagram of a SMF-NEF connection establishment process provided in an embodiment of the present application;

[0052] FIG3 is a schematic diagram of a NIDD configuration process provided in an embodiment of the present application;

[0053] FIG4 is a schematic diagram of an RDS protocol stack structure between a terminal and an NEF provided in an embodiment of the present application;

[0054] FIG5 is a schematic diagram of an RDS-based MO data transmission process according to an embodiment of the present application;

[0055] FIG6 is a schematic diagram of an RDS-based MT data transmission process according to an embodiment of the present application;

[0056] FIG7 is a schematic diagram of a communication system architecture provided in an embodiment of the present application;

[0057] 8 to 14 are flowcharts of an information transmission method according to an embodiment of the present application;

[0058] 15 and 16 are schematic diagrams of the structure of a communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0059] The technical solutions of the embodiments of the present application can be applied to various communication systems, such as wireless network (Wi-Fi) systems, vehicle to everything (V2X) communication systems, device-to-device (D2D) communication systems, Internet of Vehicles communication systems, fourth-generation (4G) mobile communication systems, such as long-term evolution (LTE) systems, world-wide interoperability for microwave access (WiMAX) communication systems, fifth-generation (5G) mobile communication systems, such as new radio (NR) systems, and future communication systems, such as 5.5G and sixth-generation (6G) mobile communication systems.

[0060] To facilitate understanding of the technical solutions provided by the embodiments of this application, a brief introduction to the relevant technical terms of this application is first given. The brief introduction is as follows:

[0061] First, 5G system (5G system, 5GS):

[0062] 5GS may include: access network (AN) and core network (CN), and may also include: terminals.

[0063] The terminal may be a terminal with transceiver functions, or a chip or chip system that can be provided in the terminal. The terminal may also be referred to as user equipment (UE), access terminal, subscriber unit, user station, mobile station (MS), mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication device, user agent, or user device. The terminal in the embodiments of the present application can be a mobile phone, a cellular phone, a smart phone, a tablet computer, a wireless data card, a personal digital assistant (PDA), a wireless modem, a handset, a laptop computer, a machine type communication (MTC) terminal, a computer with wireless transceiver function, a virtual reality (VR) terminal, an augmented reality (AR) terminal, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical, a wireless terminal in smart grid, a wireless terminal in transportation safety, a wireless terminal in smart city, a wireless terminal in smart home, a vehicle-mounted terminal, a road side unit (RSU) with terminal function, etc. The terminal of the present application may also be an on-board module, on-board module, on-board component, on-board chip or on-board unit built into the vehicle as one or more components or units.

[0064] The AN implements access-related functions, providing network access for authorized users and determining transmission links of varying quality for user data based on user level and service requirements. The AN forwards control signals and user data between terminals and the CN. The AN may include access network equipment, also known as radio access network (RAN) equipment.

[0065] The CN is primarily responsible for maintaining mobile network subscription data and providing terminal functions such as session management, mobility management, policy management, and security authentication. The CN primarily includes all or part of the following functions: user plane function (UPF), authentication server function (AUSF), access and mobility management function (AMF), session management function (SMF), network slice selection function (NSSF), network exposure function (NEF), network repository function (NRF), policy control function (PCF), unified data management (UDM), unified data repository (UDR), and application function (AF).

[0066] Figure 1 is a schematic diagram of a 5GS service-oriented architecture provided by an embodiment of the present application. As shown in Figure 1, the UE accesses the 5G network through the RAN, and the UE communicates with the AMF through the N1 interface (referred to as N1); the RAN communicates with the AMF through the N2 interface (referred to as N2); the RAN communicates with the UPF through the N3 interface (referred to as N3); the SMF communicates with the UPF through the N4 interface (referred to as N4), and the UPF accesses the data network (DN) through the N6 interface (referred to as N6). In addition, the control plane functions such as the AUSF, AMF, SMF, NSSF, NEF, NRF, PCF, UDM, UDR, or AF shown in Figure 1 interact using service-oriented interfaces. For example, the service interface provided by AUSF to the outside world is Nausf; the service interface provided by AMF to the outside world is Namf; the service interface provided by SMF to the outside world is Nsmf; the service interface provided by NSSF to the outside world is Nnssf; the service interface provided by NEF to the outside world is Nnef; the service interface provided by NRF to the outside world is Nnrf; the service interface provided by PCF to the outside world is Npcf; the service interface provided by UDM to the outside world is Nudm; the service interface provided by UDR to the outside world is Nudr; and the service interface provided by AF to the outside world is Naf.

[0067] RAN can be a device or logical entity that provides access to the terminal. For example, RAN may include: a next-generation mobile communication system, such as a 6G access network device, or a 6G base station; or in the next-generation mobile communication system, the RAN may also have other naming methods, which are all included in the protection scope of the embodiments of this application, and this application does not impose any restrictions on this. Alternatively, RAN may also include 5G, such as a gNB in ​​a new radio (NR) system, or one or a group of (including multiple antenna panels) antenna panels of a base station in 5G, or it may also be a network node constituting a gNB, a transmission point (TRP or transmission point, TP) or a transmission measurement function (TMF), such as a baseband unit (BBU), or a centralized unit (CU) or a distributed unit (DU), an RSU with base station function, or a wired access gateway, or a 5G core network. Alternatively, RAN may also include access points (APs) in wireless fidelity (Wi-Fi) systems, wireless relay nodes, wireless backhaul nodes, various forms of macro base stations, micro base stations (also known as small stations), relay stations, access points, wearable devices, or vehicle-mounted devices, etc.

[0068] UPF is mainly responsible for user data processing (forwarding, receiving, billing, etc.). For example, UPF can receive user data from the data network (DN) and forward the user data to the terminal through the access network equipment. UPF can also receive user data from the terminal through the access network equipment and forward the user data to the DN. DN refers to the operator network that provides data transmission services to users. For example, the Internet Protocol (IP) Multimedia Service (IMS), the Internet, etc. DN can be an operator's external network or a network controlled by the operator, used to provide business services to the terminal. In the protocol data unit (PDU) session, the UPF directly connected to the DN through N6 is also called the protocol data unit session anchor (PSA).

[0069] AUSF is mainly used to perform terminal security authentication.

[0070] AMF is mainly used for mobility management in mobile networks, such as user location update, user network registration, and user handover.

[0071] The SMF is primarily used for session management in mobile networks, such as session establishment, modification, and release. Specific functions include assigning IP addresses to users and selecting the UPF that provides packet forwarding capabilities.

[0072] PCF primarily supports providing a unified policy framework to control network behavior, providing policy rules to the control layer network functions, and is responsible for obtaining user subscription information related to policy decisions. PCF can provide policies to AMF and SMF, such as quality of service (QoS) policies and slice selection policies.

[0073] NSSF is mainly used to select network slices for terminals.

[0074] NEF is mainly used to support the opening of capabilities and events.

[0075] UDM is mainly used to store user data, such as contract data, authentication / authorization data, etc.

[0076] UDR is mainly used to store structured data, including contract data and policy data, externally exposed structured data, and application-related data.

[0077] AF mainly supports interaction with CN to provide services, such as influencing data routing decisions, policy control functions, or providing some third-party services to the network side.

[0078] It can be understood that the functions mentioned in the embodiments of the present application can also be expressed as functional network elements or functional entities. For example, NEF can be expressed as NEF network element, AMF can be expressed as AMF network element, SMF can be expressed as SMF network element, AF can be expressed as AF network element, and so on, without limitation.

[0079] In addition, in the following text, function and functional network element are used interchangeably, for example, NEF and NEF network element are used interchangeably. The two have the same meaning and are explained here uniformly without further explanation.

[0080] Second, non-IP data delivery (NIDD):

[0081] NIDD is a method of transmitting data through an "unstructured" type of protocol data unit (PDU) session. When a terminal performs an "unstructured" type of PDU session establishment and the subscription information corresponding to the data network name (DNN) requested by the terminal includes the "NEF identity for NIDD (NEF ID)", the SMF initiates the SMF-NEF connection establishment procedure to the NEF corresponding to the NEF ID of the DNN and / or single network slice selection assistance information (S-NSSAI).

[0082] It can be understood that the SMF-NEF connection establishment process can be used to establish a NEF PDU session from the terminal to the NEF for the terminal. The NEF PDU session can enable a reliable data service (RDS), and then transmit mobile originated (MO) data and mobile terminated (MT) data through RDS. Among them, the context of the NEF PDU session can be established through NIDD information in the SMF-NEF connection establishment process, and the NIDD information is generated through the NIDD configuration process.

[0083] The following describes the SMF-NEF connection establishment process and the NIDD configuration process respectively in conjunction with Figures 2 and 3.

[0084] 2.1、SMF-NEF connection establishment process:

[0085] Figure 2 is a schematic diagram of an SMF-NEF connection establishment process provided by an embodiment of the present application. As shown in Figure 2, the process is exemplified by the interaction between a UE (i.e., a terminal), an SMF, and a NEF, and includes steps S201 to S204.

[0086] S201. Complete session management policy association in the PDU session establishment process.

[0087] It should be understood that the 3rd Generation Partnership Project (3GPP) defines a PDU session establishment process. If the session management (SM) policy association process is completed in the PDU session process, the SMF can receive the user ID (e.g., user permanent identifier (SUPI)), DNN, and SM subscription information corresponding to the S-NSSAI of the PDU session, and then the SMF can request the NEF to generate a session management context (i.e., step S202). The SM subscription information includes NIDD information and the NFE ID used for NIDD. The above-mentioned SUPI, DNN, and S-NSSAI are associated with the NEF ID used for NIDD, NIDD information, etc. The NIDD information may include, for example, a generic public subscription identifier (GPSI), an external group identifier (external group identifier), or an AF identifier (AF ID).

[0088] It can be understood that in the SM policy association process, after SMF receives the PDU session management context request for generating UE from AMF, SMF can request UDM to obtain the UE's subscription information according to the request. The UE's subscription information may include the above-mentioned NEF ID associated with SUPI, DNN, and S-NSSAI.

[0089] In addition, the completion of the SM policy association in the above step S201 may refer to: completing the SM policy association establishment process or the SM policy association modification process initiated by the SMF, which is not specifically limited in the embodiment of the present application.

[0090] In addition, the above step S201 can be a PDU session establishment process in a non-roaming scenario, or a PDU session establishment process in a roaming scenario, and the embodiment of the present application does not specifically limit this.

[0091] It can be understood that in the roaming scenario, the SMF in Figure 2 is the H-SMF in the home public land mobile network (HPLMN), which is uniformly explained here and will not be repeated below.

[0092] S202: The SMF sends a session management context generation request message to the NEF. Correspondingly, the NEF receives the session management context generation request message from the SMF.

[0093] It should be understood that if the subscription information corresponding to the DNN and S-NSSAI contains the NEF ID, then the SMF should create a NEF PDU session with the NEF, that is, the SMF sends a session management context generation request message to the NEF. For example, the SMF can call the SM context generation request (i.e., Nnef_SMContext_Create Request) service operation provided by the NEF to send a session management context generation request message to the NEF.

[0094] In addition, the session management context generation request message may include, for example, a user ID, a PDU session ID, an SMF ID, NIDD information, an S-NSSAI, a DNN, or an RDS support indication, etc. For example, if the protocol configuration option (PCO) carried in the PDU session establishment request message indicates that the UE's capabilities support RDS, then the session management context request message may carry the RDS support indication to indicate that the UE's capabilities support RDS.

[0095] In addition, the NEF can also associate and maintain the GPSI or external group identifier, user ID, and PDU session ID included in the NIDD information. This allows the NEF to determine the association between the GPSI or external group identifier, user ID, and PDU session ID when data is transmitted through the PDU session. For example, during the MT NIDD process, the NEF can use the GPSI or external group identifier to determine the user ID and PDU session ID of the PDU session used to transmit unstructured data; during the MO NIDD process, the NEF can use the user ID and PDU session ID to determine the GPSI.

[0096] It should be understood that if, before step S202, the NIDD configuration process corresponding to the user ID in step S202 is not executed between the NEF and the AF, then the UDM or UDR on the network side does not store the NIDD information corresponding to the user ID, and the NEF should initiate the NIDD configuration process before step S203. The specific NIDD configuration process can be found in the process in Figure 3 below and will not be repeated here.

[0097] S203: NEF sends a session management context generation response message to SMF. Correspondingly, SMF receives the session management context generation response message from NEF.

[0098] It can be understood that when the NEF receives a session management context generation request message from the SMF and the NEF does not have a NEF PDU session context corresponding to the user ID carried in the request message, the NEF establishes a NEF PDU session context corresponding to the user ID and PDU session ID. The NEF PDU session context is mainly used to implement the transfer of non-IP data. For example, based on the PDU session ID, user ID, etc., the NEF can determine to which AF to transfer non-IP data, and determine to which SMF to send non-IP data from the AF.

[0099] It should be understood that the session management context creation response message is used to confirm the establishment of the NEF PDU session from the UE to the NEF. For example, the NEF can call the SM context creation response (i.e., Nnef_SMContext_Create Response) service operation provided by the NEF to send the session management context creation response message to the NEF.

[0100] In addition, the session management context generation response message may include: the RDS support indication of the NEF. For example, if the NEF supports and allows the use of RDS, the session management context generation response message includes the RDS support indication of the NEF.

[0101] In addition, the session association context generation response message may further include: an NIDD parameter, and the NIDD parameter may include, for example, a maximum packet size.

[0102] S204. SMF forwards the RDS support indication of NEF to UE.

[0103] It is understood that the SMF can encapsulate the RDS support indication of the NEF in the PCO and forward it to the UE, and then the UE can determine whether the NEF and the UE can be transmitted through the RDS link based on the RDS support indication of the NEF. Among them, RDS can be divided into an uplink RDS link and a downlink RDS link. The downlink RDS link can be used by the NEF to determine whether the downlink data (such as MT data) is successfully sent to the UE, and the uplink RDS link can be used by the UE to determine whether the uplink data (such as MO data) is successfully sent to the NEF.

[0104] In addition, when the management context generation response message also includes the NIDD parameter, the SMF may forward the NIDD parameter to the UE, and the UE may determine the maximum packet size of the data packets transmitted between the UE and the NEF based on the NIDD parameter. For example, the SMF may encapsulate the NEF's RDS support indication and the NIDD parameter in a PCO and forward the PCO to the UE.

[0105] It can be understood that the SMF forwards the RDS support indication and NIDD of the NEF to the UE, and specifically can send the PCO carrying the RDS support indication and NIDD parameters of the NEF to the UE through the AMF and 5G-AN (i.e., the RAN in Figure 1). For example, the SMF can reuse the relevant steps of the SMF transmitting the PDU session establishment information to the UE in the PDU session establishment process in step S201. For example, the SMF can call the communication N1N2 message transmission (e.g., Namf_Communication_N1N2Message Transfer) service operation of the AMF to send the above-mentioned PCO carrying the RDS support indication and NIDD parameters to the AMF, and the AMF can send an N2 PDU session request message to the UE through a downlink non-access stratum (NAS) message. The N2 PDU session request message carries the above-mentioned PCO. Among them, the AMF sends the PCO carrying the RDS support indication and NIDD parameters to the RAN, and the RAN can transparently transmit the PCO to the UE.

[0106] 2.2, NIDD configuration process:

[0107] It should be understood that the NIDD configuration process involved in the above step S202 can be initiated by the NEF (initiated) or triggered by the AF (triggered), which is specifically described below with reference to FIG. 3 .

[0108] FIG3 is a schematic diagram of a NIDD configuration process provided by an embodiment of the present application. As shown in FIG3 , the NIDD configuration process includes the following steps:

[0109] S301: NEF sends a NIDD configuration trigger notification message to AF. Correspondingly, AF receives the NIDD configuration trigger notification message from NEF.

[0110] It should be understood that step S301 is optional, and for example, may be applied to the above-mentioned step S202, "if before step S202, the NIDD configuration process corresponding to the user ID in step S202 has not been performed between the NEF and the AF." It is understood that if the NEF needs to use a given AF for NIDD configuration (for example, the NEF receives a call management context generation request message, and no NIDD information exists in the NEF), then the NEF may send a NIDD configuration trigger notification message to the given AF. The NIDD configuration trigger notification message is used by the given AF to request the NEF to generate the NIDD configuration of the UE corresponding to the GPSI. The NIDD configuration trigger notification message includes: GPSI, AF ID (i.e., the identifier of the given AF), and NEF ID.

[0111] In addition, the NEF may send the NIDD configuration trigger notification message by calling the NIDD configuration trigger notification (eg, Nnef_NIDDCongfiguration_TriggerNotify) service operation provided by the NEF.

[0112] S302: The AF sends a NIDD configuration generation request message to the NEF. Correspondingly, the NEF receives the NIDD configuration generation request message from the AF.

[0113] It can be understood that the NIDD configuration generation request message includes: GPSI or external group identifier, AF ID, NIDD duration, RDS configuration, or request action (request action), which are respectively explained below.

[0114] (a) GPSI is used to identify a single UE, and external group identifier is used to identify a group of UEs.

[0115] (b) The AF ID is used to identify the AF that sends the NIDD configuration generation request message to the NEF, so that the NEF can generate the NIDD configuration corresponding to the AF ID.

[0116] (c) The duration of NIDD can be determined by AF.

[0117] (d) RDS configuration is optional and is used to configure RDS. Specifically, it may include a pair of port numbers corresponding to the initiator application and the receiver application. For an uplink RDS link, the initiator may be a UE and the receiver may be an NEF. For a downlink RDS link, the initiator may be an NEF and the receiver may be a UE.

[0118] It should be understood that before step S302, if the UE and the NEF have completed the uplink RDS link negotiation and / or the downlink RDS link negotiation, the AF can save the negotiation results (for example, the port number, RDS parameters, or transmission mode negotiated for the uplink RDS link or downlink RDS link), so that the NIDD configuration generation request message can include the RDS configuration. It should be understood that the uplink RDS link negotiation and / or the downlink RDS link negotiation can also be performed after the NIDD configuration process, which is not specifically limited in this embodiment of the present application.

[0119] In addition, regarding the uplink RDS link negotiation and / or downlink RDS link negotiation process, as well as the negotiation results, please refer to the relevant description in "RDS" below, which will not be repeated here.

[0120] In addition, RDS link negotiation may also be referred to as RDS negotiation, such as uplink RDS negotiation or downlink RDS negotiation, etc., which is not specifically limited in the embodiments of the present application.

[0121] For ease of understanding, the following description uses uplink RDS link negotiation and downlink RDS link negotiation, which are explained here uniformly and will not be repeated below.

[0122] (e) The request action may include: requesting a new NIDD configuration, and updating. If the request action is updating, the purpose of the NIDD configuration generation request message is to update parameters related to the RDS configuration.

[0123] Exemplarily, the AF may send the NIDD configuration generation request message by calling a NIDD configuration generation request (eg, Nnef_NIDDCongfiguration_CreateRequest) service operation provided by the NEF.

[0124] S303: NEF handing.

[0125] It can be understood that if the NIDD configuration generation request message in step S302 is a request for a new NIDD configuration, the NEF stores the GPSI or external group identifier, AF ID, or NIDD duration, etc. carried by the NIDD configuration generation request message, and generates a NIDD configuration (for example, it may include the RDS support indication (or called RDS indication) of the NEF in step S203 and NIDD parameters).

[0126] In addition, after receiving the NIDD configuration generation request message, the NEF may authenticate with the UDM, that is, send a NIDD authentication query request message to the UDM.

[0127] S304: NEF sends a NIDD authentication query request message to UDM. Correspondingly, UDM receives the NIDD authentication query request message from NEF.

[0128] It is understood that the NIDD authentication query request message is used to authenticate the NIDD configuration request of the GPSI or external group identifier carried in the NIDD query request message. The NIDD query request message may include the content included in the NIDD configuration generation request message in step S302, which will not be repeated here.

[0129] Exemplarily, the NEF may send the NIDD authentication query request message by calling the NIDD authentication query request (eg, Nudm_NIDDAuthorization_Get Request) service operation provided by the UDM.

[0130] S305: UDM processing (UDM handing).

[0131] It can be understood that the UDM authenticates the NIDD authentication query request message, and if the authentication is successful, the UDM may feedback to the NEF an NIDD configuration request for accepting the GPSI or external group identifier carried in the NIDD authentication query request message.

[0132] S306: The UDM sends a NIDD authentication query response message to the NEF. Correspondingly, the NEF receives the NIDD authentication query response message from the UDM.

[0133] For example, the UDM may send the NIDD authentication query response message by calling a NIDD authentication query response (eg, Nudm_NIDDAuthorization_Get Response) service operation provided by the UDM.

[0134] S307: The NEF sends a NIDD configuration generation response message to the AF. Correspondingly, the AF receives the NIDD configuration generation response message from the NEF.

[0135] It can be understood that the NIDD configuration generation response message is used to indicate confirmation of receipt of the NIDD configuration generation request message in step S302. The NIDD configuration generation response message includes an RDS indication, which is used to indicate whether RDS is enabled in the NIDD configuration.

[0136] It can be understood that after the NIDD configuration process described in FIG3 is completed, the SMF-NEF connection establishment process shown in FIG2 can be completed, and then a NEF PDU session can be established, and the NEF PDU session can enable RDS. For example, the session management context request message in step S202 of FIG2 carries an RDS support indication (used to indicate that the UE's capabilities support RDS), and the SMF forwards the NEF's RDS support indication to the UE in step S204. In this way, both the UE and the NEF support RDS, and then the NEF PDU session between the UE and the NEF can enable RDS.

[0137] Third, RDS:

[0138] RDS is mainly used for acknowledged mode data transmission between the terminal and the network side, and also supports unacknowledged mode data transmission. Among them, the functions provided by RDS can be implemented by deploying the corresponding RDS protocol layer on the terminal and network side. For example, in 5GS, the RDS protocol layer is used for NEF PDU session transmission between the terminal and NEF. For another example, in the evolved packet system (EPS) or LTE, the RDS protocol layer is used for packet data network (PDN) connection transmission between the terminal and the service capability exposure function (SCEF).

[0139] In addition, the RDS protocol layer supports the following functions:

[0140] a) Multiple applications on the terminal transmit data with multiple entities on the network side (such as AF in 5GS or application server (AS) in EPS) through one PDU session or PDN connection;

[0141] b) RDS supports acknowledged mode and unacknowledged mode. Acknowledged mode means that after receiving data, the receiver will feedback confirmation information to the originator to indicate whether the data is successfully received. Unacknowledged mode means that the receiver does not need to feedback confirmation information after receiving data.

[0142] It can be understood that in 5GS, RDS data packets are transmitted through NEF PDU sessions. The transmission nodes in NEF PDU sessions include terminals, RAN, AMF, SMF, and NEF, and the RDS protocol stack is deployed in terminals and NEF.

[0143] The following uses 5GS as an example to illustrate the RDS protocol layer structure between the terminal and the network side.

[0144] Figure 4 is a schematic diagram of the RDS protocol stack structure between a terminal and an NEF according to an embodiment of the present application. As shown in Figure 4, the RDS protocol layer is deployed on the terminal and NEF respectively, that is, the RAN, AMF, and SMF are not deployed with the RDS protocol layer, that is, the RAN, AMF, and SMF transparently forward RDS data packets.

[0145] As shown in Figure 4, the protocol stack structure of the terminal is logically arranged from bottom to top, including: layer 1 (L1), media access control (MAC) layer, radio link control (RLC) layer, packet data convergence protocol (PDCP) layer, radio resource control (RRC) layer, NAS-mobility management (NAS-MM) layer, NAS session management (NAS-SM) layer, RDS layer, and application layer.

[0146] The RAN's protocol stack structure relative to the terminal differs from the terminal's protocol stack structure in that it does not include the NAS-MM layer to the application layer. The RAN's protocol stack structure relative to the AMF includes Layer 1, Layer 2 (L2), IP layer, Stream Control Transmission Protocol (SCTP), and Next Generation Application Protocol (NGAP).

[0147] The difference between the protocol stack structure of the AMF relative to the RAN side and the protocol stack structure of the RAN relative to the AMF side is that they also include the NAS-MM layer. The protocol stack structure of the AMF relative to the SMF side includes the L1, L2, IP layer, transmission control protocol (TCP) layer, and hypertext transfer protocol / 2 (HTTP / 2) layer.

[0148] The difference between the protocol stack structure of SMF relative to AMF and the protocol stack structure of AMF relative to SMF is that they also include the NAS-SM layer. The protocol stack structure of SMF relative to NEF is the same as the protocol stack structure of AMF relative to SMF.

[0149] The difference between the protocol stack structure of NEF and the protocol stack structure of SMF relative to the NEF side is that it also includes the RDS protocol layer and the application layer.

[0150] It can be understood that in EPS, the RDS protocol stack structure between the terminal and the SCEF is similar to Figure 6, with the following differences: RAN is replaced by eNB or eNodeB (evolutional NodeB) in LTE, and AMF and SMF are replaced by the mobility management entity in LTE.

[0151] The following further describes the RDS protocol layer functions with reference to FIG4 .

[0152] As shown in Figure 4, RDS can establish a peer-to-peer logical link, or RDS link, between the terminal and the NEF. The RDS link can be divided into an uplink RDS link and a downlink RDS link. Both the uplink and downlink RDS links can be identified by a pair of port numbers and a PDU session ID. The PDU session ID is used to identify the destination of the RDS packet. For example, for an uplink RDS link, the destination of the RDS packet is the NEF. For another example, for a downlink RDS link, the destination of the packet is the terminal.

[0153] It should be understood that the RDS data packet does not include the PDU session ID, and the PDU session ID may be carried by the header of the NAS message.

[0154] A pair of port numbers is used to identify the initiator's application and the receiver's application. A pair of port numbers includes a source port number and a destination port number. The source port number is used to identify the initiator's application, and the destination port number is used to identify the receiver's application. For example, for an uplink RDS link, the initiator is a terminal and the receiver is an NEF. The source port number is used to identify the terminal's application, and the destination port number is used to identify the NEF's application. For another example, for a downlink RDS link, the initiator is an NEF and the receiver is a terminal. The source port number is used to identify the NEF's application, and the destination port number is used to identify the terminal's application.

[0155] In addition, the RDS protocol layer supports negotiation to reserve a pair of port numbers for use in transmitting data for a specific application. Specifically, the initiator can initiate a reserved port number process to associate a pair of port numbers with a specific application ID (i.e., application ID). When transmitting data for that application, the initiator can use the RDS link identified by the pair of port numbers associated with the application ID.

[0156] It is understood that the initiator and the receiver can initiate an uplink RDS link or downlink RDS link negotiation process to establish the uplink RDS link or downlink RDS link. The initiator and the receiver can negotiate a pair of port numbers, a transmission mode (e.g., confirmation mode or non-confirmation mode), or RDS parameters. RDS parameters may include, for example, the size of the receive window, the length of the RDS frame, or the RDS version, etc., which are not specifically limited in the embodiments of the present application.

[0157] For example, for the confirmation mode, after the initiator and the receiver have negotiated a pair of port numbers, the initiator may initiate a confirmation transmission establishment process, which may be used to negotiate a transmission mode between the initiator and the receiver.

[0158] Fourth, the data transmission process based on RDS:

[0159] Based on the difference between the upper and lower RDS links, the RDS data transmission process can be divided into: an uplink data transmission process based on the uplink RDS link, and a downlink data transmission process based on the downlink RDS link.

[0160] The following takes a non-roaming scenario, where the uplink data is MO data, and the downlink data is MT data as an example, and combines Figures 4 and 5 to illustrate the RDS-based MO data transmission process and MT data transmission process respectively.

[0161] 4.1、MO data transmission process:

[0162] FIG5 is a schematic diagram of an RDS-based MO data transmission process according to an embodiment of the present application. As shown in FIG5 , the process includes the following steps:

[0163] S501. UE sends MO data according to steps 1-4 of the MO data transmission process anchored by UPF in the control plane (CP) cellular Internet of things (CIoT) 5GS optimization.

[0164] It can be understood that steps 1-4 in step S501 (not shown in FIG5 ) specifically include:

[0165] Step 1: The UE sends a NAS message to the RAN. Correspondingly, the RAN receives the NAS message from the UE.

[0166] The NAS message includes MO data, PDU session ID, and RDS header. The RDS header may include a pair of port numbers negotiated for the uplink RDS link.

[0167] Optionally, the RDS packet header may further include an application ID corresponding to a pair of port numbers negotiated for the uplink RDS link.

[0168] Step 2: RAN sends a NAS message to AMF. Correspondingly, AMF receives the NAS message from RAN.

[0169] It can be understood that in the data transmission between the UE and the AMF, the RAN transparently forwards the UE's NAS message.

[0170] Step 3: AMF performs complete verification and decryption on the NAS message to obtain the PDU session ID and uplink data.

[0171] It is understood that the AMF protocol stack includes the NAS-MM protocol layer, and the NAS-MM entity can perform integrity verification and decryption on NAS messages. In addition, when RDS is enabled in the NIDD configuration, the uplink data in step 3 includes an RDS data packet, which includes an RDS header and an RDS payload, and the RDS payload includes MO data.

[0172] It should be understood that since the AMF protocol stack does not include the RDS protocol layer, AMF actually transparently transmits RDS data packets.

[0173] Step 4: AMF sends the PDU session ID and uplink data to SMF. Correspondingly, SMF receives the PDU session ID and uplink data from AMF.

[0174] It can be understood that AMF can send the PDU session ID and uplink data in step 4 by calling the PDU session send MO data (e.g., Namf_PDUSession_SendMOData) service operation provided by SMF.

[0175] In addition, the parameters transmitted in the above steps 1 to 4 may also include the UE identifier (for example, the SUPI of the UE), and then the SMF can find the SM contract information based on the PDU session ID and the UE identifier, and determine to send uplink data to the NEF corresponding to the NEF ID based on the NEF ID in the contract information.

[0176] S502: The SMF sends a session management context transfer request message to the NEF. Correspondingly, the NEF receives the session management context transfer request message from the SMF.

[0177] The session management context transfer request message includes a user ID, a PDU session ID, and uplink data. The NEF can then determine the GPSI based on the user ID and PDU session ID. The NEF can then find the NEF PDU session context corresponding to the GPSI and parse the RDS data packet included in the uplink data. It should be understood that the NEF PDU session context corresponding to the GPSI may be the NEF PDU session context generated by the NEF in step S203 of FIG. 2 .

[0178] For example, the SMF may send the session management context delivery request message in step S502 by calling a session management context delivery request (eg, Nnef_SMContext_DeliveryRequest) service operation provided by the NEF.

[0179] S503: The NEF sends a NIDD transmission notification request message to the AF. Correspondingly, the AF receives the NIDD transmission notification request message from the NEF.

[0180] It can be understood that NEF can parse the RDS data packet included in the uplink data, and obtain a pair of port numbers corresponding to the MO data and the uplink RDS link, and then NEF can determine the AF ID based on the pair of port numbers, so that NEF can send MO data to the AF corresponding to the AF ID.

[0181] For example, the NEF may send the NIDD delivery notification request message in step S503 by calling a NIDD delivery notification request service operation (eg, Nnef_DeliveryNotificationRequest) provided by the NEF.

[0182] S504: The AF sends a NIDD transmission notification response message to the NEF. Correspondingly, the NEF receives the NIDD transmission notification response message from the AF.

[0183] It is understood that the NIDD delivery notification response message indicates confirmation of receipt of the MO data. For example, the AF can send the NIDD delivery notification request message in step S503 by calling the NIDD delivery notification request service operation (eg, Nnef_DeliveryNotificationRequest) provided by the NEF.

[0184] S505: NEF sends a session management context transfer response message to SMF. Correspondingly, SMF receives the session management context transfer response message from NEF.

[0185] It is understood that the session management context delivery response message is used to indicate confirmation of successful delivery of the MO data. For example, the NEF can send the session management context delivery response message in step S505 by calling a session management context delivery response service operation provided by the NEF (eg, Nnef_SMContext_DeliveryResponse).

[0186] It is understood that when the transmission mode of the uplink RDS link is confirmed mode, after receiving the MO data, the NEF should feedback confirmation information to the UE to indicate whether the MO data is successfully received. The NEF can use the downlink RDS link corresponding to the uplink RDS link to send confirmation information to the UE to indicate whether the MO data is successfully received.

[0187] It should be understood that the correspondence between the uplink RDS link and the downlink RDS link can mean that the application of the initiator of the uplink RDS link is the same as the application of the receiver of the downlink RDS link, and that the application of the receiver of the uplink RDS link is the same as the application of the initiator of both downlink RDS links. In other words, the application ID corresponding to the pair of port numbers of the uplink RDS link is the same as the application ID corresponding to the pair of ports of the two downlink RDS links.

[0188] The following describes the MT data transmission process using the downlink RDS link.

[0189] 4.2、MT data transmission process based on RDS:

[0190] FIG6 is a schematic diagram of an RDS-based MT data transmission process provided by an embodiment of the present application. As shown in FIG6 , the process includes the following steps:

[0191] S601: The AF sends a first NIDD transmission request message to the NEF. Correspondingly, the NEF receives the first NIDD transmission request message from the AF.

[0192] It is understood that when the AF activates the NIDD service corresponding to the UE and has MT data to be sent to the UE, the AF may send a first NIDD transmission request message to the NEF to request that the MT data be sent to the UE. The first NIDD transmission notification request message may include GPSI, RDS configuration (optional), and MT data.

[0193] For example, the AF may send the first NIDD delivery request message in step S601 by calling a NIDD delivery request (eg, Nnef_DeliveryRequest) service operation provided by the NEF.

[0194] In addition, for details on GPSI and RDS configuration, please refer to the relevant description on GPSI and RDS configuration in step S302 of FIG. 3 , which will not be repeated here.

[0195] In another possible implementation, the AMF sends indication information to the NEF, where the indication information is used to indicate that the UE is reachable, and the NEF may resume sending the cached MT data to the UE according to the indication information.

[0196] S602: NEF authentication.

[0197] It can be understood that NEF can determine the user ID and PDU session ID of the NEF PDU session based on the GPSI in the first NIDD transmission request message, and then determine the 5GS QoS flow context based on the DNN managed by the user ID. If NEF finds the 5GS QoS flow context, then NEF performs authentication, that is, NEF checks whether AF is authorized to send MT data.

[0198] S603: The NEF sends a second NIDD transmission request message to the SMF. Correspondingly, the SMF receives the second NIDD transmission request message from the NEF.

[0199] It is understood that if NEF authentication is successful, NEF can send the second NIDD transmission request message in step S603 by calling the NIDD transmission request service operation (e.g., Nsmf_DeliveryRequest) provided by the SMF. The second NIDD transmission request message is used to request the transmission of MT data, and the second NIDD transmission request message may include the MT data or the PDU session ID carried in the first NIDD transmission request message in step S601.

[0200] For example, when RDS is enabled in the NEF PDU session, the NEF can use the RDS protocol to encapsulate the MT data to obtain an RDS data packet, which includes an RDS header and an RDS payload. The RDS header may include a pair of port numbers negotiated for the downlink RDS link, and the RDS payload may include the MT data.

[0201] In addition, since the SMF protocol stack does not include RDS, SMF can transparently transmit RDS data packets.

[0202] S604: SMF sends the PDU session ID and downlink data to AMF. Correspondingly, AMF receives the PDU session and downlink data from SMF.

[0203] It can be understood that the SMF can parse the data carried in the second NIDD transmission request message to obtain the PDU session ID and downlink data, and the downlink data can include the RDS data packet in the above step S603.

[0204] For example, SMF can send the PDU session ID and downlink data to AMF by calling the Namf_Communication_N1N2MessageTransfer service operation.

[0205] S605: The AMF sends a downlink NAS message to the RAN. Correspondingly, the RAN receives the downlink NAS message from the AMF.

[0206] It can be understood that the downlink NAS message may include the PDU session ID in step S604 and the downlink data.

[0207] S606: The RAN sends a downlink NAS message to the UE. Correspondingly, the UE receives the downlink NAS message from the RAN.

[0208] It is understood that the RAN can transparently forward downlink NAS messages. In addition, the UE's protocol stack includes the RDS protocol layer, and the UE can parse the data packet carried by the downlink NAS message to obtain the port number and MT data included in the RDS data packet.

[0209] Currently, when a NEF is switched due to a failure of the original NEF on the network side, the RDS link connectivity between the switched NEF and the terminal should be guaranteed to avoid affecting service transmission. However, the current 3GPP protocol cannot guarantee that the RDS link between the switched NEF and the terminal can be connected in a timely manner. Specifically, there are two problems:

[0210] Issue 1: The NEF after handover can proactively initiate the downlink RDS link negotiation and reestablishment process to reestablish the downlink RDS link. However, the current RDS protocol's negotiation and reestablishment mechanism for the uplink RDS link does not enable timely negotiation and reestablishment of the uplink RDS link from the terminal to the NEF after handover, which in turn affects service transmission.

[0211] For example, for the non-confirmation mode, the RDS protocol does not define a related error recovery mechanism. That is, the current RDS protocol does not clearly define the negotiation and reconstruction process of the uplink RDS link triggered by the non-confirmation mode. How to implement the negotiation and reconstruction process of the uplink RDS link triggered in the non-confirmation mode remains to be studied.

[0212] For another example, in confirmation mode, the RDS protocol stipulates that when the initiator does not receive confirmation information from the receiver for a period exceeding the retransmission timer (specified as 250 seconds by the RDS protocol), the initiator will be triggered to retransmit. When the number of retransmissions by the initiator exceeds the preset maximum number of retransmissions (specified as 3 times by the RDS protocol), the initiator will be triggered to initiate the RDS link negotiation and reestablishment process. In other words, in confirmation mode, the uplink RDS link negotiation and reestablishment requires at least 3×250s, or approximately 12 minutes, and cannot be reestablished in time.

[0213] In addition, when the transmission mode of the negotiated re-established uplink RDS link is confirmation mode, after the downlink data reaches the terminal, the terminal should send confirmation information to the NEF through the uplink RDS link. At this time, the NEF of the uplink RDS link is the original NEF that failed, and the switched NEF cannot receive the confirmation information from the terminal, so the downlink service transmission cannot be restored.

[0214] Problem 2: In scenarios where NEFs have hot standby capabilities, multiple NEFs can seamlessly synchronize the NIDD configuration (Figure 3) and the RDS link negotiation results, enabling smooth RDS link failover without requiring a rebuild. However, how to achieve this is a pressing issue.

[0215] Based on this, the embodiments of the present application provide the following technical solutions.

[0216] The technical solution in this application will be described below with reference to the accompanying drawings.

[0217] In the embodiment of the present application, "indication" may include direct indication and indirect indication, and may also include explicit indication and implicit indication. The information indicated by a certain information is called information to be indicated. In the specific implementation process, there are many ways to indicate the information to be indicated, such as but not limited to, the information to be indicated can be directly indicated, such as the information to be indicated itself or the index of the information to be indicated. The information to be indicated can also be indirectly indicated by indicating other information, wherein there is an association relationship between the other information and the information to be indicated. It is also possible to indicate only a part of the information to be indicated, while the other parts of the information to be indicated are known or agreed in advance. For example, the indication of specific information can also be achieved by means of the arrangement order of each piece of information agreed in advance (such as specified in the protocol), thereby reducing the indication overhead to a certain extent. At the same time, the common parts of each piece of information can also be identified and indicated uniformly to reduce the indication overhead caused by indicating the same information separately.

[0218] In addition, the specific indication method can also be various existing indication methods, such as but not limited to the above-mentioned indication methods and various combinations thereof. The specific details of the various indication methods can be referred to the prior art and will not be repeated herein. As can be seen from the above, for example, when it is necessary to indicate multiple information of the same type, there may be a situation where the indication methods for different information are different. In the specific implementation process, the required indication method can be selected according to specific needs. The embodiment of the present application does not limit the selected indication method. In this way, the indication method involved in the embodiment of the present application should be understood to cover various methods that can enable the party to be indicated to obtain the information to be indicated.

[0219] It should be understood that the information to be indicated can be sent as a whole or divided into multiple sub-information and sent separately, and the sending period and / or sending time of these sub-information can be the same or different. The specific sending method is not limited in the embodiments of this application. The sending period and / or sending time of these sub-information can be predefined, for example, predefined according to a protocol, or can be configured by the transmitting device by sending configuration information to the receiving device.

[0220] In this application, "sending information" can be understood as one device (or communication entity) sending information to another device (or communication entity), or it can also be understood as one logical module within a device sending information to another logical module. For example, "NEF sending information" can be understood as the NEF sending information to another device (such as a terminal, SMF, or AF), or it can be understood as logical module 1 in the NEF sending information to logical module 2 in another device.

[0221] In this application, "receiving information" can be understood as a device (or communication entity) receiving information from another device (or communication entity), or it can also be understood as a logic module within a device receiving information from another logic module. For example, "a terminal receiving information" can be understood as the terminal receiving information from another device (such as an SMF or NEF), or it can be understood as logic module 1 in the terminal receiving information from logic module 2 in another device.

[0222] In this application, "sending information to... (e.g., a terminal)" or the related illustrations in the accompanying drawings can be understood as the destination end of the information being the terminal. This can include sending information to the terminal directly or indirectly. "Receiving information from... (e.g., a terminal)" or "receiving information from... (e.g., a terminal)" or "receiving information sent by (e.g., a terminal)", or the related illustrations in the accompanying drawings can be understood as the source end of the information being the terminal, which can include receiving information from the terminal directly or indirectly. The information may be processed as necessary between the source end and the destination end of the information transmission, such as format changes, etc., but the destination end can understand the valid information from the source end. Similar expressions in this application can be understood similarly and will not be repeated here.

[0223] "Pre-definition" or "pre-configuration" can be implemented by pre-saving corresponding codes, tables or other methods that can be used to indicate relevant information in the device, and the embodiments of the present application do not limit the specific implementation method. Among them, "saving" can mean saving in one or more memories. The one or more memories can be set separately or integrated in an encoder or decoder, a processor, or a communication device. The one or more memories can also be partially set separately and partially integrated in a decoder, a processor, or a communication device. The type of memory can be any form of storage medium, and the embodiments of the present application do not limit this.

[0224] The "protocol" involved in the embodiments of the present application may refer to a protocol family in the communication field, a standard protocol with a similar protocol family frame structure, or a related protocol used in future communication systems. The embodiments of the present application do not make specific limitations on this.

[0225] In the embodiments of the present application, descriptions such as "when...", "in the case of...", "if" and "if" all mean that the device will perform corresponding processing under certain objective circumstances. It does not limit the time, nor does it require the device to perform judgment actions when implemented, nor does it mean that there are other limitations.

[0226] In the description of the embodiments of the present application, unless otherwise specified, " / " indicates that the objects associated with each other are in an "or" relationship. For example, A / B can represent A or B. "And / or" in the embodiments of the present application is only a description of the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. A and B can be singular or plural. In addition, in the description of the embodiments of the present application, unless otherwise specified, "multiple" refers to two or more than two. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple. In addition, in order to facilitate the clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" are used to distinguish between identical or similar items with basically the same functions and effects. Those skilled in the art will understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit differences. At the same time, in the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or design. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a concrete way for easy understanding.

[0227] The network architecture and business scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Ordinary technicians in this field will know that with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0228] To facilitate understanding of the embodiments of the present application, a communication system applicable to the embodiments of the present application is first described in detail using a communication system as an example.

[0229] Figure 7 is a schematic diagram of a communication system architecture provided by an embodiment of the present application. As shown in Figure 7, the communication system includes: a terminal and an open network element. The open network element includes a first open network element, which is an open network element serving the terminal after being reselected from a second open network element.

[0230] Optionally, the communication system may further include a session management network element, an application network element, or a data management network element.

[0231] It should be understood that the device form of the terminal can refer to the relevant introduction of the above-mentioned 5GS, which will not be repeated here. The network open network element can be the NEF in the above-mentioned 5GS, or a network element with RDS function in the future communication system, without limitation. The session management network element can be the SMF in the above-mentioned 5GS, or a network element in the future communication system used to implement PDU session management between the terminal and the network open network element, without limitation. The application network element can be the AF in the above-mentioned 5GS, or a network element in the future communication system used to implement NIDD configuration, without limitation. The data management network element can be the UDM or UDR in the above-mentioned 5GS, or a network element in the future communication system used to maintain and manage the contract information of the terminal, without limitation.

[0232] For problem 1, the communication system provides two solutions:

[0233] Solution 1: When the network open network element serving the terminal is reselected as the first network open network element, the session management network element establishes a PDU session context with the first network open network element, and the PDU session is a session between the terminal and the first network open network element; when the PDU session context is successfully established, the session management network element sends an indication message to the terminal, and the indication message is used to instruct the negotiation to re-establish the uplink reliable data service RDS link, and the uplink RDS link is carried by the PDU session.

[0234] That is to say, when the network open network element serving the terminal is reselected as the first network open network element, and the context of the PDU session is successfully established between the first network open network element and the session management network element, the session management network element instructs the terminal to negotiate and rebuild the uplink RDS link associated with the PDU session, so that the uplink RDS link can be rebuilt in time and service transmission can be restored as soon as possible.

[0235] Solution 2: When the terminal receives a negotiation re-establishment request for a downlink RDS link associated with a PDU session, the terminal may initiate a negotiation re-establishment process for an uplink RDS link associated with the PDU session.

[0236] That is to say, the terminal does not need to initiate the negotiation and reconstruction process of the uplink RDS link when the number of retransmissions exceeds the preset maximum number of retransmissions. Instead, when receiving the downlink RDS link negotiation and reconstruction request associated with the PDU session, it actively initiates the uplink RDS link negotiation associated with the PDU session, thereby timely reconstructing the uplink RDS link and resuming service transmission as soon as possible.

[0237] For problem 2, the communication system provides the following solutions:

[0238] The application network element obtains relevant information of a set of network open network elements, where the set of network open network elements includes multiple network open network elements that support RDS information synchronization between the network open network elements, and the RDS information includes the NIDD configuration for carrying the RDS link; in the NIDD configuration process corresponding to the terminal, the application network element sends relevant information to the network where the terminal is located, and the network where the terminal is located is used to provide services for the RDS link corresponding to the terminal.

[0239] That is to say, the application network element can send relevant information of the network open network element set to the network where the terminal is located through the session-level NIDD configuration process, so that the functional network elements on the network side (such as the session management network element) can obtain the relevant information, and then support the reselection of the network open network element within the network open network element set when the session management network element discovers that the session management network element serving the terminal has failed, so as to achieve smooth switching of the RDS link, thereby making small changes to the system, having good compatibility, and reducing implementation complexity.

[0240] It should be understood that as the network evolves, the communication system shown in FIG7 may also support or include other network functions, such as AI or perception-related functions. In addition, the network element names shown in FIG7 may also change in future evolving networks, and this embodiment of the present application does not specifically limit this.

[0241] The following method embodiments will specifically introduce the interaction process between the network elements / devices in the above communication system. The communication method provided in the embodiment of the present application can be applied to the above communication system and specifically applied to various scenarios mentioned in the above communication system, which will be described in detail below.

[0242] For ease of understanding, the following is a unified introduction to the technical terms involved in the embodiments of this application:

[0243] 1) A PDU session refers to a PDU session (also known as an NEF PDU session) between a terminal and the network open element serving the terminal. Alternatively, a PDU session can also be a session used for NIDD in other network standards, such as future 6G networks. For ease of understanding, the following description uses a 5G network as an example.

[0244] 2) The network open network element serving the terminal is reselected as the first network open network element, which may mean that when the application network element or the session management network element finds that the interaction with the network open network element serving the terminal fails, the application network element may select a new network open network element (i.e., the first network open network element) to replace the network open network element serving the terminal for RDS data transmission based on the locally configured policy or the operator configured policy or the instruction of the application server.

[0245] 3) NIDD information can be included in the subscription information of the PDU session. NIDD information can include, for example, the GPSI and an application network element identifier used to identify the application network element. NIDD information is also associated with the user ID (i.e., terminal ID) and the network open network element identifier used to identify the network open network element. For details, see step S201 in Figure 2 and will not be repeated here.

[0246] 4) The NIDD configuration is information generated by the network open element based on the NIDD configuration generation request message sent by the application element. Specifically, during the NIDD configuration process for the terminal, the network open element can generate the NIDD configuration based on the NIDD configuration generation request message from the application element. The NIDD configuration may include an RDS indication and NIDD parameters. Optionally, the NIDD configuration may also include the NIDD duration. For details on the NIDD configuration, see step S302 in Figure 3 and will not be further described.

[0247] 5) The uplink RDS link or downlink RDS link associated with the PDU session specifically means that the PDU session identifier used to identify the uplink RDS link or downlink RDS link is the same as the session identifier of the PDU session.

[0248] It is understood that a PDU session can be associated with multiple uplink RDS links or downlink RDS links. For example, a PDU session can be associated with a first uplink RDS link and a second uplink RDS link. This means that the PDU session identifiers for the first and second uplink RDS links are the same, but the port numbers are different. Furthermore, the port numbers correspond to an application ID, meaning that the application IDs for the first and second uplink RDS links are different.

[0249] 6) The application ID is used to associate a pair of port numbers when interacting between the terminal and the network open network element. The application ID is the same as the application network element identifier, that is, multiple RDS links associated with the PDU session correspond one-to-one with multiple application network element identifiers.

[0250] 7) The hot standby capability of the network open network element may specifically mean that the following information can be synchronized in real time and without loss of information between multiple network open network elements: the context of the above-mentioned PDU session, the information carried by the NIDD configuration generation request message, and the negotiation results of the RDS link between the network open network element and the terminal.

[0251] The following method embodiments are used to specifically describe the interaction process between network elements / devices in the communication system shown in Figure 7, in conjunction with Figures 8 to 14. The information transmission method provided in the embodiments of the present application can be applied to the above communication system and specifically applied to the various scenarios / processes mentioned in the above communication system.

[0252] It is understood that this application uses a session management network element, a first network open network element, a data management network element, an application network element, or a terminal as an example of an execution subject of the interaction diagram, but this application does not limit the execution subject of the interaction diagram. For example, the method executed by the session management network element in this application can also be executed by a module (such as a chip, a chip system, or a processor) of a network device applied to the session management network element, and can also be implemented by a logical node, logical module, or software that can implement all or part of the functions of the session management network element.

[0253] It can be understood that based on the relevant explanations of the above-mentioned questions 1 and 2, the embodiments of the present application can be divided into scenarios where the network open network element does not have hot standby capability and scenarios where the network open network element has hot standby capability, based on whether the network open network element has hot standby capability, and explained separately.

[0254] Scenario 1: The network open network element does not have hot standby capability.

[0255] FIG8 is a flow chart of an information transmission method provided in an embodiment of the present application. The information transmission method is applicable to Solution 1 of the above-mentioned communication system, and is mainly applicable to the interaction between the session management network element, the first network open network element, and the terminal. As shown in FIG8, the method includes:

[0256] S801: When the open network element serving the terminal is reselected as the first open network element, the session management element establishes a PDU session context with the first open network element. The PDU session is a session between the terminal and the first open network element.

[0257] S802: If the PDU session context is successfully established, the session management network element sends an indication message to the terminal. Accordingly, the terminal receives the indication message from the session management network element. The indication message is used to instruct negotiation to reestablish an uplink RDS link, which is carried by the PDU session.

[0258] S803: The terminal initiates a negotiation and reestablishment process of the uplink RDS link according to the instruction information.

[0259] Steps S801 to S803 are described below respectively.

[0260] For step S801:

[0261] It can be understood that in the 5G network, the PDU session can specifically be a NEF PDU session between the terminal and the network open network element serving the terminal. The specific details of the NEF PDU session can be found in the relevant description of "NIDD" in the previous part, which will not be repeated here.

[0262] In addition, the contract information of the PDU session may refer to the contract information corresponding to the terminal in the PDU session. The contract information is used to generate a context. The contract information may include a network open network element identifier for identifying the network open network element serving the terminal, NIDD information corresponding to the network open network element identifier, S-NSSAI, DNN, or RDS support indication, etc. NIDD information includes GPSI and an application network element identifier for identifying an application network element. The session management network element can be obtained from the data management network element in the SM policy association process corresponding to the PDU session of the terminal. For details, please refer to the relevant description in step S201 of Figure 2, which will not be repeated here.

[0263] It is understood that the application network element corresponding to the application network element identifier included in the NIDD information may be the application network element that completes the NIDD configuration process for the terminal, or the application network element that should complete the NIDD configuration process for the terminal. Furthermore, a terminal may correspond to multiple NIDD configurations, and the NIDD configuration processes corresponding to these multiple NIDD configurations may be completed by multiple application network elements and the network open network element serving the terminal.

[0264] Assume that the first application network element can be any one of the multiple different application network elements, and the first application network element can achieve service transmission between the first application network element and the terminal through interaction with the network open network element serving the terminal. For example, when RDS is enabled for the PDU session, the PDU session can be associated with multiple uplink RDS links, and the multiple uplink RDS links can provide transmission services for multiple applications of the terminal and multiple applications of the network open network element serving the terminal. The multiple applications of the terminal have a one-to-one correspondence with the multiple applications of the network open network element serving the terminal, and the multiple applications have a one-to-one correspondence with the multiple application network elements that complete multiple NIDD configuration processes with the network open network element.

[0265] That is to say, for the session management network element, the contract information of the terminal in the PDU session may include multiple NIDD information, and the multiple NIDD information is associated with the network open network element serving the terminal. The application network element identifier contained in each NIDD information in the multiple NIDD information may be different, that is, the multiple NIDD information in the contract information corresponds one-to-one to the multiple application network elements.

[0266] It should be understood that in the embodiments of the present application, the NIDD configuration process corresponding to the terminal is completed between the network open network element serving the terminal and the terminal, that is, the network open network element identifier used to identify the network open network element is written to the data management network element. The session management network element can subscribe to contract information changes from the data management network element and thereby obtain the contract change information of the terminal in the PDU session. RDS is enabled for the PDU session, and the multiple RDS links associated with the PDU session have completed the negotiation and establishment process.

[0267] In addition, according to the relevant description of step S201 in Figure 2, the session management network element can obtain the terminal's contract information and contract change information by sending a contract subscription request to the data management network element in the terminal's session management policy association process, which will not be repeated in detail.

[0268] The following specifically introduces how the network open network element serving the terminal is reselected as the first network open network element.

[0269] It can be understood that the reselection of the network open network element serving the terminal as the first network open network element means that the network open network element serving the terminal fails at this time. In addition, as shown in Figures 5 and 6, in the uplink direction, the session management network element receives the uplink data from the terminal, and determines to send the uplink data to the network open network element serving the terminal based on the PDU session identifier. For another example, in the downlink direction, the application network element among the multiple application network elements corresponding to the multiple NIDD information sends downlink data (such as MT data) to the network open network element serving the terminal. In other words, the session management network element and the application network element on the network side can discover that the network open network element serving the terminal has failed through the failure to send data (for example, the network open network element serving the terminal times out and does not respond, or the HTTP link is unreachable), and then reselect the network open network element serving the terminal as the first network open network element, which are introduced below.

[0270] Method 1: The first application network element discovers that the open network element serving the terminal fails, and reselects the first open network element from the second open network element serving the terminal.

[0271] It is understood that the first application network element can select the first open network element from multiple candidate open network elements and complete the NIDD configuration process for the terminal with the first open network element. During this NIDD configuration process, the data management network element is triggered to authenticate the NIDD configuration generation request message (see step S304 in Figure 3). If the authentication is successful, the data management network element is triggered to update the second open network element associated with the NIDD information in the terminal's contract information to the first open network element.

[0272] In addition, the specific implementation of the first application network element selecting the first network open network element from multiple candidate network open network elements can be: the application network element can select the first network open network element according to the policy on the network side (such as local policy or operator policy), or select the first network open network element according to the policy on the application server side. It actually depends on the specific implementation, and the embodiments of the present application do not make specific limitations on this.

[0273] In one possible implementation, reselecting the open network element serving the terminal as the first open network element includes: the session management network element determining, based on subscription change information provided by the data management network element, that the open network element serving the terminal be reselected from the second open network element to the first open network element. The subscription change information indicates that NIDD information associated with the second open network element is changed to that associated with the first open network element.

[0274] That is to say, the session management network element can determine the network open network element serving the terminal based on the contract change information of the data management network element, reselect the first network open network element from the second network open network element, and then start the context of establishing a PDU session between the session management network element and the first network open network element to complete the connection establishment process between the session management network element and the first network open network element in the PDU session.

[0275] It is understood that, as described in the aforementioned step S801 regarding NIDD information, before the network open network element serving the terminal is reselected, the network open network element serving the terminal is the second network open network element. At this time, the NIDD information included in the terminal's contract information is the NIDD information associated with the second network open network element, and the NIDD information may be one or more. Specifically, if there is one NIDD information associated with the second network open network element, the NIDD information indicated by the contract change information is the one NIDD information. If there are multiple NIDD information associated with the second network open network element, the NIDD information indicated by the contract change information may be the multiple NIDD information or some of the multiple NIDD information, and this is not limited in the present application.

[0276] In one possible implementation, the NIDD information associated with the second network open network element is multiple NIDD information, and the contract change information is specifically used to indicate that the second network open network element associated with the first NIDD information is changed to be associated with the first network open network element, and the first NIDD information is the NIDD information in the multiple NIDD information that includes the first application network element identifier.

[0277] That is to say, the contract change information can be specifically used to indicate that the second network open network element associated with the first NIDD information including the first application network element identifier is changed to the associated first network open network element, and then the session management network element can determine through the contract change information that the NIDD information of the changed network development network element is the first NIDD information corresponding to the first application network element identifier, and can determine that the downlink data of the first application network element cannot be transmitted through the second network open network element, thereby determining that the RDS link corresponding to the first application network element identifier among the multiple RDS links associated with the PDU session should be negotiated and rebuilt to transmit the downlink data of the first application network element.

[0278] Method 2: The session management network element discovers that the network open network element serving the terminal fails, and reselects the network open network element serving the terminal from the second network open network element to the first network open network element.

[0279] In one possible implementation, the network open network element serving the terminal is reselected as the first network open network element, including: when the session management network element fails to send uplink data to the network open network element serving the terminal, the session management network element reselects the network open network element serving the terminal from the second network open network element to the first network open network element.

[0280] It can be understood that the session management network element can select the first network open network element from multiple candidate network open network elements based on local policy or operator policy, or the session management network element can also use other methods to determine the first network open network element. This embodiment of the present application does not specifically limit this.

[0281] That is to say, when the session management network element fails to send uplink data to the second network open network element serving the terminal, it can reselect the network open network element serving the terminal from the second network open network element to the first network open network element, and then start the context of establishing a PDU session between the session management network element and the first network open network element to complete the connection establishment process between the session management network element and the first network open network element in the PDU session.

[0282] For step S802:

[0283] It can be understood that the PDU session in step S802 is a session between the terminal and the first open network element after the open network element serving the terminal is reselected from the second open network element to the first open network element. If the context of the PDU session is successfully established, the connection establishment process shown in Figure 2 is completed between the session management network element and the first open network element. This means that the PDU session can connect the terminal and the first open network element to carry the RDS link, and that the first open network element has gone through the process of establishing the context of the PDU session from scratch.

[0284] The above-mentioned process of generating the context of the PDU session may include: S802-1 to S802-3.

[0285] S802-1: The session management network element sends a session context request message to the first network open network element according to the subscription information. Correspondingly, the first network open network element receives the session context request message from the session management network element.

[0286] The session context request message is used to request the establishment of a PDU session context. The session context request message may include the NIDD information corresponding to the terminal. The session context request message may also include other content included in the subscription information, such as a terminal ID (i.e., user ID) for identifying the terminal, a PDU session identifier, or a session management network element identifier for identifying a session management network element. For details, please refer to the relevant description in step S202 of Figure 2, which will not be repeated here.

[0287] It should be understood that the session management network element sends the session context request message in step S802-1 based on the contract information corresponding to the PDU session before the network development network element serving the terminal is reselected (that is, the PDU session between the terminal and the second network open network element), that is, the PDU session identifier does not change before and after the network open network element serving the terminal is reselected.

[0288] S802-2. The first network open network element generates a session context of the PDU session.

[0289] The specific implementation of step S802-2 can refer to step S203 in FIG. 2 , which will not be described again here.

[0290] S802-3: The first network open network element sends a session context response message to the session management network element. Correspondingly, the session management network element receives the session context response message from the first network open network element.

[0291] Among them, the session context response message is used to confirm that the first network open network element has successfully established the context. The session context response message may include the RDS support indication of the first network open network element, or NIDD parameters, etc. For details, please refer to the relevant description of step S203 in Figure 2, which will not be repeated here.

[0292] It should be understood that according to the relevant description of the above step S801, the way of reselecting the network open network element serving the terminal as the first network open network element includes way 1 and way 2, and thus under different ways, the context generation process of the above PDU session may be different.

[0293] The above generation process is further explained below in combination with the above method 1 and method 2.

[0294] It can be understood that, as described in the above-mentioned method 1, when the first application network element finds that the data transmission to the second network open network element serving the terminal fails, the first application network element reselects the network open network element serving the terminal from the second network open network element to the first network open network element, and executes the NIDD configuration process between the first network open network element and the first network open network element, triggering the change of contract information. The contract change information is specifically used to indicate that the second network open network element associated with the first NIDD information is changed to the first network open network element, and then the NIDD information included in the session context request message in step S802-1 is the first NIDD information. The first network open network element can determine, based on the first application network element identifier, PDU session identifier, and user ID included in the first NIDD information, that the NIDD configuration corresponding to the first NIDD information is the NIDD configuration process corresponding to the user ID completed between the first network open network element and the first application network, so that the second network open network element can generate a session context based on the NIDD configuration corresponding to the first NIDD information and the session context request message in step S802-1.

[0295] It can also be understood that in the NIDD configuration process (the process shown in Figure 3) completed by the first network open network element, the first network open network element can obtain configuration information for identifying the RDS link, and the generated context can include the configuration information, and the configuration information can be associated with the first application network element identifier. Among them, the configuration information is associated with the first application network element identifier, which allows the first network open network element to determine that the RDS link associated with the PDU session is the RDS link corresponding to the first application network element identifier. In addition, the configuration information can also include the RDS configuration sent by the first application network element to the first network open network element in the NIDD configuration process corresponding to the terminal, and the RDS configuration includes a pair of port numbers, which are used to identify the RDS link, and the pair of ports corresponds to the first application network element identifier.

[0296] It should be understood that according to the relevant instructions on identifying the RDS link in the preamble "RDS" of the specific implementation method, the pair of port numbers corresponding to the RDS link is associated with the application ID. The application network element identifier and the application ID in the embodiment of the present application are the same, that is, the session management network element can determine the corresponding RDS link through the application network element identifier included in the changed NIDD information. The first network open network element can determine the corresponding RDS link based on the pair of port numbers or application ID (that is, the application network element identifier) ​​obtained according to the NIDD configuration process to further determine the negotiation information of the RDS link and establish the RDS link based on the negotiation.

[0297] In addition, after establishing the context of the PDU session between the terminal and the first open network element, the session management network element may not release the connection between the session management network element and the second open network element before the re-establishment, and thus downlink data (e.g., MT data) of other application network elements (i.e., application network elements that can interact with the second open network element) transmitted by the PDU session can be transmitted through the PDU session established between the second open network element and the session management network element. In other words, the second open network element can provide data transmission services for multiple application network elements. If the first application network element fails to send data to the second open network element, it may be that the connection between the first application network element and the second open network element fails. However, other application network elements other than the first application network element in the multiple application network elements can normally interact with the second open network element, and thus the PDU session between the session management network element and the second open network element can continue to be used to transmit data.

[0298] It should be understood that the above is only an example. For the data corresponding to multiple application network elements transmitted on the PDU session, the PDU session between the terminal and the first network open network element can also be used for transmission. The embodiment of the present application does not make specific limitations on this.

[0299] It can be understood that, as described in the aforementioned method 2, the session management network element discovers that the second network open network element has failed, and thus the uplink data (such as MO data) of the session management network element cannot reach the second network open network element. The NIDD information included in the session context request message in step S802-1 can be multiple NIDD information corresponding to the terminal identifier and the PDU session identifier. The first network open network element can determine the multiple NIDD configurations corresponding to the multiple application network element identifiers based on the application network element identifier included in each NIDD information in the multiple NIDD information, and then generate a session context.

[0300] In addition, the above is only an example. The session management network element may select at least one NIDD information from multiple NIDD information to execute step S802-1 according to local policy or operator policy. This embodiment of the present application does not specifically limit this.

[0301] It should be understood that in method 2, since the reselection of the second network open network element as the first network open network element is implemented by the session management network element, the application network element associated with the second network open network element on the network side may not perceive that the second network open network element is reselected as the first network open network element. Furthermore, combined with the description of NIDD configuration in the aforementioned step S202, the first network open network element should complete the NIDD configuration process corresponding to the terminal with the application network element included in the NIDD information before generating the context.

[0302] In a possible implementation, the method shown in FIG8 further includes:

[0303] S804: The first network open network element completes the NIDD configuration process corresponding to the terminal between the application network element corresponding to the application network element identifier included in the NIDD information and the data management network element according to the session context request message.

[0304] It is understood that, as described in relation to step S802-1, the session context request message includes the user ID, NIDD information, and the like. The first open network element can then initiate the NIDD configuration process corresponding to the terminal through the process illustrated in FIG3 . For example, during the NIDD configuration process corresponding to the terminal, the first open network element sends a NIDD configuration trigger notification message to the application network element corresponding to the application network element identifier included in the NIDD information. This message may include: the GPSI corresponding to the terminal, the application network element identifier included in the NIDD information, and the first open network element identifier used to identify the first open network element, i.e., replacing the second open network element identifier with the first open network element identifier. Furthermore, if there are multiple NIDD information messages, the first open network element can complete the NIDD configuration process corresponding to the terminal with the application network element corresponding to the application network element identifier included in each of the multiple NIDD information messages. Alternatively, the first open network element can determine the first application network element identifier from the multiple application network element identifiers based on local policies or operator policies and send the NIDD configuration trigger notification message to the first application network element. This embodiment of the present application is not specifically limited in this regard.

[0305] It is understandable that in the NIDD configuration process corresponding to the terminal, after the data management network element completes the authentication, it can update the network open network element associated with the NIDD information, that is, update the second network open network element associated with the NIDD information to the first network open network element.

[0306] S805: The data management network element sends data contract change information to the session management network element. Correspondingly, the session management network element receives the contract change information from the data management network element. The contract change information indicates that the NIDD information associated with the second network open network element is changed to be associated with the first network open network element.

[0307] It will be appreciated that, as described above with respect to the NIDD configuration process in FIG3 , the first open network element can generate NIDD information included in the request message based on the session context from the session management element, and complete the NIDD configuration process corresponding to the terminal with the application element included in the NIDD information, thereby generating the context. Furthermore, as described in FIG3 , the NIDD configuration process requires authentication by the data management element, which allows the data management element to update the NIDD information corresponding to the second open network element and send corresponding contract change information to the session management element.

[0308] That is to say, after sending a session context request message to the first network open network element, the session management network element can receive contract change information from the data management network element. Then, the session management network element can further determine, based on the contract change information, which NIDD information among the multiple NIDD information associated with the second network open network element before reselection has actually been authenticated and changed by the data management network element to the corresponding network open network element. Therefore, based on the application network element identifier included in the actually changed NIDD information, it can be determined which uplink RDS links corresponding to the application network element identifiers among the multiple uplink RDS links associated with the PDU session need to be negotiated and rebuilt.

[0309] In a possible implementation of the indication information, the indication information is specifically used to instruct negotiation to reestablish the uplink RDS link corresponding to the first application network element identifier.

[0310] That is, in the case where a PDU session is associated with multiple uplink RDS links, the session management network element may instruct negotiation to re-establish the uplink RDS link corresponding to the first application network element that failed to send data to the first network open network element.

[0311] It is understood that, when the PDU session is associated with a single uplink RDS link, the indication information may indicate negotiation to reestablish the uplink RDS link. Furthermore, when the PDU session is associated with multiple uplink RDS links, the indication information may also indicate negotiation to reestablish the multiple uplink RDS links, which is not specifically limited in the embodiments of the present application.

[0312] It should be understood that the session management network element sends the indication information to the terminal, specifically by encapsulating the indication information in PCO and sending it by calling the Namf_Communication_N1N2Message Transfer service operation. For details, please refer to the relevant description of step S204 in Figure 2, which will not be repeated here.

[0313] In addition, the session management network element may also send indication information to the terminal through other messages or methods, which is not specifically limited in the embodiment of the present application.

[0314] For step S803:

[0315] It is understood that the terminal can initiate a negotiation and reestablishment process for the uplink RDS link associated with the PDU session based on the indication information. In addition, according to the relevant description of step S802, the terminal can initiate a negotiation and reestablishment process for each of the multiple uplink RDS links associated with the PDU session based on the indication information, or can initiate a negotiation and reestablishment process for the uplink RDS link corresponding to the application network element identifier indicated in the indication information. This embodiment of the present application does not specifically limit this.

[0316] In one possible implementation, the uplink RDS link is a plurality of uplink RDS links, and the plurality of uplink RDS links include an uplink RDS link corresponding to each application network element identifier among a plurality of application network element identifiers associated with the PDU session, and the indication information is specifically used to indicate the negotiation to reconstruct the uplink RDS link corresponding to the first application network element identifier among the plurality of application network element identifiers; the terminal initiates a negotiation reconstruction process of the uplink RDS link according to the indication information, specifically including: the terminal initiates a negotiation reconstruction process of the uplink RDS link corresponding to the first application network element identifier according to the indication information.

[0317] That is to say, when the PDU session is associated with multiple uplink RDS links, the terminal side stores the application IDs corresponding to the multiple uplink RDS links. Based on the fact that the application ID is the same as the application network element identifier, the terminal can initiate the negotiation reconstruction process of the uplink RDS link corresponding to the first application network element identifier according to the first application network element identifier indicated by the indication information.

[0318] It should be understood that the negotiation and reconstruction process of the uplink RDS link initiated by the terminal may, for example, include the terminal sending a negotiation request message to the recipient (i.e., the first network open network element), and receiving a negotiation response message from the first network open network element. Among them, the negotiation request can be used to request negotiation of a pair of port numbers corresponding to the first application network element identifier, and the negotiation request can also be used to request negotiation of whether the transmission mode is a confirmation mode or a non-confirmation mode, and / or, to request negotiation of RDS parameters. In addition, the negotiation response message is used to indicate agreement or disagreement with the above-mentioned negotiation request message. In addition, the above-mentioned negotiation and reconstruction process can be specifically referred to the relevant description of the RDS protocol, which will not be repeated here.

[0319] Because in the embodiment of the present application, the session management network element can instruct the terminal to negotiate and rebuild the uplink RDS link associated with the PDU session when the context of the PDU session is successfully established, and thus the uplink RDS link can be rebuilt in a timely manner to resume service transmission as soon as possible.

[0320] The overall process of the information transmission method of Solution 1 of the communication system shown in FIG7 is introduced above in conjunction with FIG8 . The information transmission method is described in detail below.

[0321] Figure 9 is a second flow chart of an information transmission method provided by an embodiment of the present application. The flow chart shown in Figure 9 is an example of an exemplary description using method 1 in step S802 of Figure 8, and mainly involves the interaction between the terminal, the session management network element, the first network open network element, the second network open network element, the first application network element, and the data management network element. Among them, the first application network element is the application network element that discovers the fault of the second network open network element in the above-mentioned method 1. The following is a specific description using the example of the terminal being UE, the session management network element being SMF, the first network open network element being NEF2, the second network open network element being NEF1, the first application network element being AF, and the data management network element being UDM.

[0322] As shown in FIG9 , the information transmission method includes the following steps: S901 to S918 .

[0323] The pre-process is completed between S901, UE, SMF, UDM, NEF2, and AF.

[0324] Among them, the pre-process may refer to: the NIDD configuration process corresponding to the UE is completed between NEF2 and AF (NEF1 is authenticated by UDM, and the NEF1 identifier (ie, NEF1 ID) is written into the UE's contract information), the PDU session establishment process is completed between UE, SMF, UDM, and NEF1, and the RDS negotiation is completed between UE and NEF1.

[0325] In addition, SMF can subscribe to UE's subscription change notifications from UDM to notify SMF when the UE's subscription data changes.

[0326] It can be understood that the above-mentioned processes can be specifically referred to the process shown in Figure 2, the process shown in Figure 3, and the relevant description of RDS negotiation in the preamble "RDS", which will not be repeated here.

[0327] S902: AF sends data to NEF1.

[0328] It can be understood that the specific implementation of S902 can refer to step S601 in Figure 6, which will not be repeated here.

[0329] S903: When AF fails to send data to NEF1, NEF2 is reselected.

[0330] It can be understood that the failure of AF to send data to NEF1 in S903 may be due to NEF1 timing out and not responding, or the HTTP link being unreachable, which is not specifically limited in this embodiment of the present application.

[0331] In addition, the specific implementation of the AF reselecting NEF2 can refer to the relevant description of the method 1 in step S802, which will not be repeated here.

[0332] It should be understood that after the AF reselects NEF2, the NIDD configuration process corresponding to the UE may be triggered.

[0333] S904: AF sends a NIDD configuration generation request message to NEF2. Correspondingly, NEF2 receives the NIDD configuration generation request message from AF.

[0334] It can be understood that the specific implementation of step S904 can be found in step S302 of FIG. 3 , and will not be described in detail.

[0335] S905: NEF2 sends a NIDD authentication query request message to UDM. Correspondingly, UDM receives the NIDD authentication query request message from NEF2.

[0336] It can be understood that the specific implementation of step S905 can refer to step S304 and will not be repeated here.

[0337] S906. UDM updates the NEF1 ID corresponding to the first NIDD information including the AF ID in the subscription information of the UE to NEF2ID.

[0338] It can be understood that the AF ID is used to identify the AF, and the first NIDD information includes the GPSI and the AF ID. Then, the UDM can determine which of the multiple NIDD information included in the subscription information of the UE is the first NIDD information according to the AF ID.

[0339] S907: UDM sends a NIDD authentication query response message to NEF2. Correspondingly, NEF2 receives the NIDD authentication query response message from UDM.

[0340] It is understood that the specific implementation of step S907 can refer to step S306 and will not be described in detail. In addition, step S907 can be performed before or after step S906, or simultaneously, and this embodiment of the application does not specifically limit this.

[0341] S908: NEF2 sends a NIDD configuration generation response message to AF. Correspondingly, AF receives the NIDD configuration generation response message from NEF2.

[0342] It can be understood that the specific implementation of step S908 can refer to step S307 and will not be repeated here.

[0343] S909: UDM sends a contract change notification message to SMF. Correspondingly, SMF receives the contract change notification from UDM.

[0344] It can be understood that the subscription change notification message is used to indicate that the NEF1 ID in the first NIDD information in the UE's subscription information is changed to the NEF2 ID. In addition, the specific implementation of S909 can refer to the relevant description in step S201, which will not be repeated here.

[0345] S910. SMF determines that NEF1 is reselected as NEF2.

[0346] S911: SMF sends a session management context generation request message to NEF2. Correspondingly, NEF2 receives the session management context generation request message from SMF.

[0347] It can be understood that the specific implementation of step S911 can refer to the relevant description of S802-1 corresponding to method 1 in step S802, and will not be repeated here.

[0348] S912. NEF2 generates a session context.

[0349] It can be understood that the session context is the context of the PDU session, and the session context may include configuration information for identifying the RDS link. The specific implementation of S912 can refer to step S802-2 and the relevant description of step S203, which will not be repeated here.

[0350] S913: NEF2 sends a session management context generation response message to SMF. Correspondingly, SMF receives the session management context generation response message from NEF2.

[0351] It is understood that the session management context generation response message may include the RDS support indication of NEF2. Since RDS is enabled for the PDU session, the AF sends MT data to the UE via NEF1. Therefore, the NIDD configuration associated with NEF1 may include the RDS configuration, and the NEF2 reselected by the AF should also support RDS.

[0352] In addition, the specific implementation of step S913 can refer to step S203 and will not be repeated here.

[0353] S914. The SMF generates a response message according to the session management context, and determines that RDS is enabled for the PDU session.

[0354] It can be understood that since RDS is enabled for the PDU session, the UE side can store the application ID corresponding to the uplink RDS link associated with the PDU session, and the application ID corresponds to the uplink RDS link one-to-one. In addition, considering that the application ID is the same as the AF ID used to identify the AF, the SMF can determine through the first NIDD information that the uplink RDS link corresponding to the AF ID needs to be reestablished, and thus send an indication message to the UE to instruct it to negotiate the reestablishment of the uplink RDS link corresponding to the AF ID.

[0355] It should be understood that the SMF can send indication information to the UE through the AMF and gNB. For details, please refer to the following steps S915 to S917.

[0356] S915. The SMF sends an N1N2 message to the AMF. Correspondingly, the AMF receives the N1N2 message.

[0357] It can be understood that the SMF can encapsulate the indication information in the PCO. For example, the PCO can include the AF ID and indication information for instructing negotiation to re-establish the uplink RDS link corresponding to the AF ID.

[0358] In addition, the PCO may also include an RDS support indication of the NEF2, which is not specifically limited in the embodiment of the present application.

[0359] It should be understood that the specific implementation of SMF sending the N1N2 message to AMF can refer to the relevant instructions in step S204 and will not be repeated here.

[0360] S916. The AMF sends a NAS message to the gNB. Accordingly, the gNB receives the NAS message from the AMF.

[0361] It can be understood that the AMF processes the N1N2 message into a NAS message, which may include the PCO corresponding to the UE.

[0362] S917: The gNB sends a NAS message to the UE. Accordingly, the UE receives the NAS message from the gNB.

[0363] It is understood that the gNB protocol stack does not include the NAS protocol layer, and thus the gNB transparently forwards NAS messages between the UE and the AMF.

[0364] S918. The UE initiates a negotiation and reestablishment process of the uplink RDS link corresponding to the first application network element identifier according to the instruction information.

[0365] It can be understood that the negotiation and reestablishment process of the RDS link may be specifically referred to in step S803 and will not be described in detail here.

[0366] Optionally, in step S918, after the UE and NEF2 complete the negotiation and reestablishment process of the uplink RDS link corresponding to the first application network element identifier, the method shown in FIG9 may further include:

[0367] S919. The UE sends response information of the MO data or the MT data to the NEF2.

[0368] It can be understood that after the uplink RDS link corresponding to the first application network element identifier completes the negotiation and re-establishment, the uplink RDS link is connected, and the UE can normally send uplink data, such as MO data. In addition, after the UE receives MT data through the downlink RDS link corresponding to the first application network element identifier, the UE can also send MT data response information through the uplink RDS link. This allows NEF2 to determine that the UE has received the MT data, thereby avoiding the inability of NEF2 to resume downlink services due to the failure to receive the MT data response information due to the disconnection of the uplink RDS link.

[0369] It should be understood that the specific implementation of the UE sending the application information of the MO data or MT data to the NEF2 can refer to the process shown in Figure 5, which will not be repeated here.

[0370] Because in the embodiment of the present application, AF can discover the failure of NEF1 through interaction with NEF1 to reselect NEF2, and trigger the NIDD configuration process corresponding to the terminal in the PDU session, so that UDM changes the NEF1 corresponding to the NIDD information including the AF ID in the contract information of the terminal to NEF2, and then can send a contract change notification message to SMF. SMF can trigger the context establishment process between SMF and NEF2 according to the contract change notification message to establish a PDU session connection between SMF and NEF2, so that SMF can send indication information to UE in a timely manner when the context of the PDU session is successfully established, so as to realize timely reconstruction of the uplink RDS link and resume service transmission as soon as possible.

[0371] It can be understood that the method flow shown in FIG9 is illustrative of the method 1 in step S802 of FIG8 as an example. The specific implementation of method 2 in step S802 of FIG8 (i.e., the session management network element reselects the first network open network element) is similar to the method flow shown in FIG9, with the difference that: since the first network open network element may not complete the NIDD configuration process corresponding to the terminal before generating the session context, after step S802-1 in the session context generation process, the first network open network element should execute the NIDD configuration process corresponding to the terminal. For details, please refer to step S805 in FIG8, which will not be repeated here. In addition, in the NIDD configuration process corresponding to the terminal, a change in the contract information will be triggered (i.e., step S805 in FIG8), and the session management network element can further determine the application network element identifier corresponding to the uplink RDS link that needs to be negotiated and reestablished based on the contract change information, and indicate it to the terminal.

[0372] Figure 10 is a flow chart of a method for information transmission according to an embodiment of the present application. This method is applicable to solution 2 of the above-mentioned communication system, and is mainly applicable to the interaction between the session management network element, the first network open network element, and the terminal. As shown in Figure 10, the method includes:

[0373] S1001. A first network open network element establishes a PDU session context with a session management network element. The PDU session is a session between a terminal and a network open network element serving the terminal.

[0374] S1002: When the context of the PDU session is successfully established, the first network open network element sends a first message to the terminal. Accordingly, the terminal receives the first message from the first network open network element. The first message is used to request negotiation to establish a downlink RDS link, which is carried by the PDU session.

[0375] S1003. The terminal initiates a negotiation and reestablishment process of the uplink RDS link associated with the PDU session according to the first information.

[0376] Steps S1001 to S1003 are described below respectively.

[0377] For steps S1001 and S1002:

[0378] It can be understood that according to the relevant instructions in the preamble on the triggering negotiation to rebuild the RDS link supported by the RDS protocol, when the number of retransmissions initiated on the downlink RDS link exceeds the preset maximum number of retransmissions, the network open network element can initiate a negotiation process for the downlink RDS link, and then in step S1001, the first network open network element sends a negotiation establishment request message to the terminal for negotiating the reconstruction of the downlink RDS link.

[0379] It should be understood that, for the first open network element, when the context of the PDU session is successfully established, the first open network element establishes the context of the PDU session from scratch, and the first information sent by the first open network element to the terminal is used to request negotiation to establish a downlink RDS link associated with the PDU session. For the terminal, the terminal is unaware that the second open network element has been reselected as the first open network element, and the downlink RDS link associated with the PDU session has already been established at the terminal. At this time, the first information received is equivalent to requesting negotiation to reestablish the downlink RDS link. This is explained here uniformly and will not be repeated below.

[0380] In addition, the first information in step S1001 can be used to request negotiation to establish a port number, transmission mode, or RDS parameters for an RDS link. For details, please refer to the relevant description of step S803 in FIG. 8 , which will not be repeated here.

[0381] It can be understood that the context process of establishing a PDU session between the session management network element and the first network open network element can also be divided into method 1 and method 2 in step S802 of Figure 8 above. For details, please refer to the relevant description of step S802, which will not be repeated here.

[0382] It can be understood that, referring to the relevant instructions on generating context in method 1 or method 2 in step S802 of Figure 8, the first network open network element should complete the NIDD configuration process corresponding to the terminal in the PDU session before generating the session context, and then generate the NIDD configuration and obtain the configuration information for identifying the RDS link. In this way, the first network open network element can generate a request message and the above-mentioned configuration information based on the session context to generate a context.

[0383] In addition, the configuration information used to identify the RDS link may include configuration information for identifying the downlink RDS link associated with the PDU session. The configuration information may specifically be a pair of port numbers in the RDS configuration, and / or an application network element identifier (e.g., AF ID) carried in the NIDD configuration generation request message sent by the application network element side.

[0384] In addition, the above configuration information may also include NIDD parameters, NIDD duration, or terminal identification (such as GPSI), etc., which is not specifically limited in the embodiment of the present application.

[0385] It should be understood that according to the relevant description of method 1 in step S802 of Figure 8, when the first application network element reselects the second network open network element due to failure to send data, the first application network element will trigger the NIDD configuration process corresponding to the terminal, and then the first network open network element can generate the NIDD configuration corresponding to the first application network element, and trigger the data management network element authentication, and change the network open network element associated with the first NIDD information including the first application network element identifier in the contract information, and then the session management network element executes the above step S1001. In the context generation process in step S1001, the NIDD information in the session context generation request message sent by the session management network element is the first NIDD information, and the first NIDD information includes the first application network element identifier.

[0386] In addition, according to the relevant description of method 2 in step S802 of Figure 8, when the session management network element fails to send data, the session management network element executes the above step S1001. The main difference from the above method 1 is that the NIDD information in the session context request message sent by the session management network element may include one or more NIDD information, for example, the above-mentioned first NIDD information, as well as NIDD information corresponding to other application network elements.

[0387] In addition, the first network open network element may send a NIDD configuration trigger notification message to the application network element corresponding to the application network element identifier included in the NIDD information according to the NIDD information carried in the session context request message, thereby completing the NIDD configuration process.

[0388] In one possible implementation, the context includes a first NIDD configuration associated with a first application network element identifier; the first information is specifically used to request negotiation to establish a downlink RDS link corresponding to the first application network element identifier among multiple downlink RDS links associated with the PDU session.

[0389] It can be understood that the downlink RDS link corresponding to the first application network element identifier may also refer to: a downlink RDS link associated with a pair of port numbers corresponding to the first application network element identifier.

[0390] That is to say, when a PDU session is associated with multiple downlink RDS links, the first network open network element can indicate to the terminal which downlink RDS link to establish through negotiation among multiple downlink RDS links based on the first application network element identifier associated with the NIDD configuration included in the session context, or a pair of port numbers corresponding to the first application network element identifier.

[0391] It should be understood that the first information used to request negotiation to establish a downlink RDS link corresponding to the first application network element identifier is only one possible implementation method. When the session context includes multiple NIDD configurations corresponding to multiple application network element identifiers, the first network open network element can request negotiation to rebuild multiple downlink RDS links corresponding to the multiple application network element identifiers. The embodiments of the present application do not make specific limitations on this.

[0392] For step S1003:

[0393] In one possible implementation, the first information is specifically used to request negotiation to reestablish a first downlink RDS link among multiple downlink RDS links associated with the PDU session; the terminal initiates a negotiation reestablishment process of the uplink RDS link according to the negotiation request message (ie, step S1003), specifically including: the terminal initiates a negotiation reestablishment process of the first uplink RDS link corresponding to the first downlink RDS link according to the negotiation request message.

[0394] It can be understood that the first uplink RDS link corresponding to the first downlink RDS link may be, for example, the same as the application ID (ie, application network element identifier) ​​corresponding to the first downlink RDS link and the first uplink RDS link.

[0395] That is to say, when the negotiation request message specifically requests negotiation to reconstruct the first downlink RDS link among multiple downlink RDS links associated with the PDU session, the terminal can initiate a negotiation reconstruction process for the first uplink RDS link corresponding to the first downlink RDS link, thereby enabling the uplink and downlink RDS links between the terminal and the application network element corresponding to the first uplink RDS link to be connected, thereby restoring uplink and downlink service transmission.

[0396] It can be understood that when the RDS transmission mode is confirmation mode, even if the first downlink RDS link is connected, but the first uplink RDS link corresponding to the first downlink RDS link is not connected, the first network open network element cannot receive the confirmation information, and thus believes that the terminal has not correctly received the downlink data, so the first network open network element will retransmit and trigger the reconstruction of the first downlink RDS link again when the number of retransmissions exceeds the maximum preset number. The embodiment of the present application promptly initiates the reconstruction of the first uplink RDS link after receiving the negotiation reconstruction request of the first RDS link, thereby enabling the terminal to send the response information of the downlink data in a timely manner, thereby realizing the restoration of uplink and downlink service transmission as soon as possible.

[0397] In addition, the terminal may trigger the negotiation reestablishment process of the uplink RDS link after receiving the negotiation reestablishment request message or sending the negotiation reestablishment response message corresponding to the negotiation reestablishment request message, which is not specifically limited in the embodiment of the present application.

[0398] In addition, the negotiation reconstruction process of the uplink RDS link can negotiate the port number, transmission mode, or RDS parameters, etc. The specific process includes the terminal sending a negotiation reconstruction request message to the first network open network element, and the first network open network element sending a negotiation reconstruction response message to the terminal based on the negotiation reconstruction request message. For details, please refer to the relevant instructions of the aforementioned step S803, which will not be repeated here.

[0399] It should be understood that when the terminal receives the negotiation reconstruction request of the first downlink RDS link, in addition to triggering the negotiation reconstruction process of the first uplink RDS link, the terminal can also trigger the negotiation reconstruction process of other uplink RDS links. This embodiment of the present application does not specifically limit this.

[0400] In the embodiment of the present application, the terminal does not need to initiate the negotiation and reconstruction process of the uplink RDS link when the number of retransmissions exceeds the preset maximum number of retransmissions. Instead, upon receiving the downlink RDS link negotiation and reconstruction request associated with the PDU session, the terminal actively initiates the uplink RDS link negotiation associated with the PDU session, thereby being able to promptly reconstruct the uplink RDS link and resume service transmission as soon as possible.

[0401] The overall process of the information transmission method of solution 2 of the communication system shown in FIG7 is introduced above in conjunction with FIG10 . The information transmission method is described in detail below.

[0402] Figure 11 is a flowchart diagram of a method for information transmission provided by an embodiment of the present application. The flowchart diagram shown in Figure 11 is illustrative in accordance with mode 1 in Figure 10 (i.e., the application network element reselects the first network open network element) and mainly involves the interaction between the terminal, the session management network element, the first network open network element, the second network open network element, the first application network element, and the data management network element. Among them, the first application network element is the application network element that discovers the failure of the second network open network element in the above-mentioned mode 1. The following is a specific explanation using the example of the terminal being UE, the session management network element being SMF, the first network open network element being NEF2, the second network open network element being NEF1, the first application network element being AF, and the data management network element being UDM.

[0403] As shown in FIG11 , the information transmission method includes the following steps: S1101 to S1117 . Steps S1101 to S1113 are the same as steps S901 to S913 in FIG9 . S1114 to S1117 are described in detail below.

[0404] S1114: NEF2 sends a downlink RDS link negotiation establishment request message to the UE. Correspondingly, the UE receives the downlink RDS link negotiation establishment request message from NEF2.

[0405] It can be understood that the downlink RDS link negotiation establishment request message is specifically used to request the downlink RDS link negotiation and reconstruction corresponding to the AF ID, or the downlink RDS link negotiation and reconstruction identified by a pair of port numbers corresponding to the AF ID. The specific implementation of step S1114 can be found in the relevant description of step S1001 in Figure 10, which will not be repeated here.

[0406] It should be understood that step S1114 can be performed before or at the same time as step S1113, and this embodiment of the present application does not specifically limit this.

[0407] S1115: The UE sends a downlink RDS link negotiation establishment response message to NEF2. Correspondingly, NEF2 receives a downlink RDS link negotiation re-establishment response message from the UE.

[0408] It is understood that the downlink RDS link negotiation establishment response message can provide feedback on whether the downlink RDS link negotiation establishment request message is approved. For example, if the downlink RDS link negotiation establishment request message is used to negotiate a pair of port numbers, the downlink RDS link negotiation establishment request message can include the port number and the first application ID (i.e., AF ID) on the NEF2 side, and the downlink RDS link negotiation establishment response message can include the port number and AF ID of the UE, indicating that the UE agrees to the downlink RDS link negotiation re-establishment request. In addition, both the UE and the NEF2 side can retain the aforementioned pair of port numbers.

[0409] In addition, the negotiation process for confirming the mode and RDS parameters is similar to the negotiation process for negotiating a pair of port numbers described above, and will not be repeated here.

[0410] S1116: The UE sends an uplink RDS link negotiation re-establishment request message to NEF2. Correspondingly, NEF2 receives the uplink RDS link negotiation re-establishment request message from the UE.

[0411] It can be understood that the uplink RDS link negotiation reestablishment request message can be specifically referred to step S1002 of FIG. 10 , which will not be described in detail here.

[0412] In addition, step S1116 can be executed before or at the same time as step S1115, and this embodiment of the present application does not specifically limit this.

[0413] S1117: NEF2 sends an uplink RDS link negotiation reestablishment response message to the UE. Correspondingly, the UE receives the uplink RDS link negotiation reestablishment response message from NEF2.

[0414] It can be understood that the details of step S1117 can be found in step S1002 and will not be repeated here.

[0415] It should be understood that through the above steps S1101 to S1117, the uplink and downlink RDS links corresponding to the AF are reestablished between the UE and the NEF2, and then uplink and downlink data can be sent.

[0416] Optionally, the process shown in FIG11 may further include:

[0417] S1118: AF sends MT data to NEF2. Correspondingly, NEF2 receives MT data from AF.

[0418] It is understandable that the AF may send MT data before the downlink RDS link between NEF2 and the UE is reestablished. If NEF2 has a buffering capability, NEF2 can buffer the data and send a confirmation response back to the AF, and then send the data after the downlink RDS link is reestablished. If NEF2 does not have a buffering capability, NEF2 sends a negative response back to the AF.

[0419] S1119. NEF2 sends MT data to UE.

[0420] S1120. The UE sends response information of the MT data to the NEF2.

[0421] It can be understood that since the uplink RDS link has been reestablished, the UE can send response information of the MT data through the uplink RDS link, thereby avoiding NEF2 triggering the reestablishment of the downlink RDS link due to failure to receive response information, thereby resuming uplink and downlink service transmission as soon as possible.

[0422] In addition, the specific implementation of step S1120 can be found in the flowchart shown in FIG5 , which will not be described in detail here.

[0423] In the embodiment of the present application, the AF can discover the failure of NEF1 through interaction with NEF1 to reselect NEF2, and trigger the NIDD configuration process corresponding to the terminal in the PDU session, so that the UDM changes the NEF1 corresponding to the NIDD information including the AF ID in the subscription information of the terminal to NEF2, and then can send a subscription change notification message to the SMF. The SMF can trigger the session context establishment process between the SMF and NEF2 based on the subscription change notification message to establish a PDU session connection between the SMF and NEF2. After generating the session context, NEF2 can initiate the negotiation and reestablishment process of the downlink RDS link corresponding to the AF ID to the UE, so that NEF2 can promptly initiate the negotiation and reestablishment process of the downlink RDS link. Furthermore, after receiving the downlink RDS link negotiation and reestablishment request message from NEF2, the terminal can initiate the negotiation and reestablishment request of the uplink RDS link corresponding to the downlink RDS link, and then promptly initiate the negotiation and reestablishment of the uplink RDS link, so that both the uplink and downlink RDS links between the UE and NEF2 are connected, and uplink and downlink service transmission can be restored as soon as possible.

[0424] Figure 12 is a flowchart diagram 5 of an information transmission method provided in an embodiment of the present application. The flowchart diagram shown in Figure 12 is illustrative in manner 2 (i.e., the application network element reselects the first network open network element) in Figure 10 as an example, and mainly involves the interaction between the terminal, the session management network element, the first network open network element, the second network open network element, the first application network element, and the data management network element. The following is a specific explanation using the terminal as UE, the session management network element as SMF, the second network open network element as NEF1, the first network open network element as NEF2, the first application network element as AF, and the data management network element as UDM as an example.

[0425] As shown in Figure 12, the information transmission method includes the following steps: S1201 to S1219, step S1201 is the same as step S901 in Figure 9, steps S1208 to S1213 are the same as steps S904 to S909, S1214 to S1215 are the same as steps S912 to S913, and steps S1216 to S1219 are the same as steps S1114 to S1117 in Figure 11. Steps S1202 to S1207 are specifically introduced below.

[0426] S1202: The UE sends a NAS message to the AMF. The AMF receives the NAS message from the UE. The NAS message includes MO data, a PDU session ID, and an RDS header. The RDS header may include a pair of port numbers negotiated for the uplink RDS link. The PDU session ID is the PDU session between the UE and NEF1.

[0427] It can be understood that the gNB only transparently forwards NAS messages between the UE and the AMF. The specific implementation of step S1202 can refer to steps 1 to 3 in step S501 of Figure 5, which will not be repeated here.

[0428] S1203: AMF sends uplink data to SMF. Correspondingly, SMF receives uplink data from AMF.

[0429] It can be understood that the uplink data may include the PDU session ID, MO data, RDS packet header, and UE user ID carried by the NAS message. For details, please refer to step 4 in step S501, which will not be repeated here.

[0430] S1204. SMF sends a session management context transfer request message to NEF.

[0431] It can be understood that the session management context transmission request message includes the user ID, PDU session ID, and MO data, etc. For details, please refer to step S502, which will not be repeated here.

[0432] S1205: When SMF fails to send data to NEF1, reselect NEF2.

[0433] It can be understood that the failure of the SMF in S1205 to send data to NEF1 may be due to NEF1 timing out and not responding, or the HTTP link is unreachable, which is not specifically limited in this embodiment of the present application.

[0434] In addition, SMF can reselect NEF2 according to local policy or operator policy, which is not specifically limited in the embodiment of the present application.

[0435] S1206: SMF sends a session management context generation request message to NEF2. Correspondingly, NEF2 receives the session management context generation request message from SMF.

[0436] It is understood that the session context generation request message includes the first NIDD information, which includes the AF ID. Since NEF2 has not performed the NIDD configuration process corresponding to the UE with the AF corresponding to the AF ID, NEF2 can initiate the NIDD configuration process according to the session context request message.

[0437] In addition, the specific implementation of step S1206 can refer to the relevant description of S802-1 corresponding to method 2 in step S802, which will not be repeated here.

[0438] S1207: NEF2 sends a NIDD configuration trigger notification message to AF. Correspondingly, AF receives the NIDD configuration trigger notification message from NEF.

[0439] It can be understood that the specific implementation of step S1207 can be found in step S301 of FIG. 3 , which will not be described in detail here.

[0440] It should be understood that steps S1208-S1213 are the same as steps S904-S909 in FIG. 9 , and steps S1214-S1215 are the same as steps S912-S913. In the method flow shown in FIG. 12 , step S1214 can be performed after step S1211, i.e., after the NIDD configuration generation request message is authenticated, NEF2 can generate a session context (i.e., step S1214). Of course, NEF2 can also perform step S1214 after step S1212. Furthermore, after generating the session context, NEF2 can perform step S1216, i.e., perform step S1216 before step S1215, or NEF2 can perform step S1216 after step S1215. This is not specifically limited in this embodiment of the present application.

[0441] Optionally, the method shown in FIG12 may further include steps S1220 to S1222. Steps S1220 to S1222 are the same as steps S1118 to S1120 in FIG11 and are not described again here.

[0442] In this embodiment of the present application, the SMF can detect NEF1 failures through interaction with NEF1 and reselect NEF2. The SMF then sends a session context generation request message to NEF2, triggering the NIDD configuration process corresponding to the terminal between NEF2 and the AF indicated by the AF ID in the session context generation request message, allowing NEF2 to obtain the NIDD configuration and RDS link configuration information. Based on the NIDD configuration, RDS link configuration information, and the session context generation request message, NEF2 can generate a session context to establish a connection between the SMF and NEF2. Furthermore, after generating the session context, NEF2 can initiate a negotiation and reestablishment process for the downlink RDS link corresponding to the AF ID to the UE, thereby enabling NEF2 to promptly initiate negotiation and reestablishment of the downlink RDS link. Furthermore, after receiving the downlink RDS link negotiation and reestablishment request message from NEF2, the terminal can initiate a negotiation and reestablishment request for the uplink RDS link corresponding to the downlink RDS link, thereby promptly initiating negotiation and reestablishment of the uplink RDS link. This ensures that both the uplink and downlink RDS links between the UE and NEF2 are connected, allowing uplink and downlink service transmission to be restored as quickly as possible.

[0443] It should be understood that the process shown in Figure 12 can also be combined with Solution 1 in Figure 9 in which the SMF sends indication information to the UE. For example, after reselecting NEF2, the SMF can initiate a process of generating a session context to NEF2. After the process is completed (i.e., step S1215), the SMF can execute steps S914 to S918.

[0444] Scenario 2: The network open network element has hot standby capability.

[0445] FIG13 is a flow chart of an information transmission method provided in an embodiment of the present application. This information transmission method is applicable to the solution of the above-mentioned communication system for problem 2, and is mainly applicable to scenarios in which multiple network open network elements support real-time and lossless synchronization of session management context, NIDD configuration, and RDS link negotiation results, involving interaction between an application network element, a second network open network element, and a data management network element. As shown in FIG13 , the method includes:

[0446] S1301. An application network element obtains relevant information for identifying a network open network element set, where the network open network element set includes multiple network open network elements that support RDS information synchronization between the network open network elements, wherein the RDS information includes NIDD configuration for carrying an RDS link.

[0447] It should be understood that the following information is also supported for synchronization between multiple network open network elements: the session context of the PDU session for NIDD, and the negotiation information of the RDS link. The negotiation information may include a pair of negotiated port numbers, the application ID (or application network element identifier) ​​corresponding to the pair of port numbers, the transmission mode of the RDS link (for example, confirmation mode or non-confirmation mode), the RDS parameters of the RDS link, etc. The embodiments of the present application do not specifically limit this.

[0448] In addition, the application network element can determine the set of network open network elements and obtain relevant information through the policy on the application server side; or, the relevant information can be pre-configured, or negotiated in advance between the application network element and multiple network open network elements, or indicated by the network side. The embodiments of the present application do not specifically limit this.

[0449] It is understood that the relevant information includes a first identifier for identifying the above-mentioned network open network element set. Optionally, the relevant information also includes an identifier corresponding to each network open network element in the above-mentioned network open network element set. For example, the network open network element set includes multiple network open network elements NEF1, NEF2, and NEF3. The relevant information includes: a first identifier (or NEF set ID), a NEF1 ID for identifying NEF1, a NEF2 ID for identifying NEF2, and a NEF3 ID for identifying NEF3.

[0450] S1302: In the NIDD configuration process corresponding to the terminal, the application network element sends relevant information to the network where the terminal is located, wherein the network where the terminal is located is used to provide services for the RDS link corresponding to the terminal.

[0451] The following describes step S1302 in detail.

[0452] For example, step S1302 may include:

[0453] S1302-1. The application network element (i.e., the first network open network element in Figure 13 ) serving the terminal sends a first request message. Accordingly, the first network open network element receives the first request message from the application network element. The first request message is used to request generation of a NIDD configuration corresponding to the terminal. The first request message includes relevant information.

[0454] It can be understood that according to the relevant instructions of step S301 or S302 in Figure 3, the application network element sends the first request message to the first network open network element, which can be initiated by the first network open network element (see step S301 for details) or triggered by the application network element (see step S302 for details). The embodiment of the present application does not make specific limitations on this.

[0455] In addition, the first request message may be, for example, a NIDD configuration generation request message, which may include the relevant information in the above step S1301 in addition to the GPSI, AF ID, or RDS configuration described in step S302.

[0456] It should be understood that each of the multiple open network elements included in the above-mentioned open network element set can be pre-configured with relevant information. Alternatively, after obtaining the relevant information through the first request message, the first open network element can synchronize the relevant information with other open network elements in the open network element set. This embodiment of the present application does not specifically limit this.

[0457] S1302-2: The first network open network element sends a second request message to the data management network element. In response, the data management network element receives the second request message from the first network open network element. The second request message is used to request authentication of the first request message. The second request message includes relevant information.

[0458] It can be understood that the second request message is similar to the NIDD authentication query request message in step S304, except that the second request message includes relevant information.

[0459] In addition, the first network open network element can pass the relevant information to the data management network element through the second request message, and then, if the first request message is authenticated, the data management network element can associate the relevant information with the relevant information of the terminal, thereby supporting other network elements on the network side (such as the session management network element associated with the PDU session corresponding to the terminal) to obtain relevant information, and then, when a failure of the first network open network element is discovered, reselection can be performed within the network open network element set, so that the first network open network element can reselect other network open network elements from the network open network element set when a failure occurs. Furthermore, since NIDD configuration synchronization is supported between multiple network open network elements in the network open network element set, when RDS is enabled for the PDU session, the RDS link can be rebuilt without negotiation, thereby achieving smooth switching of the RDS link.

[0460] S1302-3. When the first request message passes authentication, the data management network element associates the relevant information with the contract information of the terminal.

[0461] It should be understood that the data management network element associates relevant information with the terminal's contract information, which may also refer to: the terminal's contract information package NIDD information, the NIDD information including the application network element identifier for identifying the application network element in step S1301, the NIDD information is associated with relevant information, or the NIDD information also includes relevant information.

[0462] In addition, the subscription information of the terminal may also be associated with the first network open network element identifier used to identify the first network open network element identifier. For details, please refer to the relevant description of step S201 in Figure 2, which will not be repeated here.

[0463] That is to say, the data management network element associates the relevant information with the contract information of the terminal, and thus can support the session management network element on the network side to obtain the relevant information when subscribing to the contract information or change notification information of the terminal, and thus can support the session management network element to reselect the second network open network element from the network open network element set when a failure of the first network open network element is discovered.

[0464] The following describes the process of data management network elements obtaining relevant information.

[0465] In a possible implementation, the method shown in FIG13 further includes:

[0466] S1303. During the process of establishing a PDU session for a terminal, the data management network sends relevant information to the session management network element in response to a subscription request message from the session management network element associated with the PDU session. In response, the session management network element receives the relevant information from the data management network element. The PDU session is a PDU session between the terminal and the network open network element serving the terminal.

[0467] It can be understood that, specifically in the SM policy association process in the terminal's PDU establishment process, the session management network element can receive the PDU session management context request for the generated terminal from the AMF, and then the session management network element can request the data management network element to obtain the terminal's contract information based on the request.

[0468] In addition, when the NIDD configuration process of the terminal is updated, the data management network element authentication will also be triggered, and the data management network element may change the relevant information to the second identifier (that is, the identifier corresponding to other network open network element sets except the network open network element set corresponding to the relevant information). When the data management network element updates the relevant information, the data management network element can send contract change information to the session management network element to indicate the second identifier.

[0469] It can be understood that the specific implementation of the above session management network element obtaining relevant information is only an example. Relevant information can also be transmitted through interaction between the session management network element and the data management network element in other processes. The embodiments of the present application do not specifically limit this.

[0470] That is to say, when the context of the terminal is established, the session management network element can obtain relevant information from the data management network element. Then, when the session management network element fails to send data to the first network open network element, it can select a second network open network element from multiple network open network elements based on the relevant information, so as to realize smooth switching of the first network open network element in the PDU session to the second network open network element, so that the RDS link does not need to be rebuilt through negotiation.

[0471] The following describes in detail the process of the session management network element reselecting the second network open network element.

[0472] In one possible implementation, the PDU session is a PDU session for NIDD between the terminal and the first network open network element; the method shown in FIG13 further includes:

[0473] S1304. In the process of the terminal sending the first uplink data through the PDU session, the session management network element obtains the first uplink data.

[0474] It can be understood that the specific implementation of step S1307 can be found in step S501 of FIG5 , which will not be described in detail here.

[0475] S1305: When the session management network element determines that sending the first uplink data to the first network open network element fails, the session management network element sends the first uplink data to a second network open network element in the network open network element set.

[0476] It can be understood that the session management network element determines that sending the first uplink data to the first network open network element fails. For details, please refer to step S802, which will not be repeated here.

[0477] In addition, the session management network element may select the second network open network element from the plurality of network open network elements based on the relevant information.

[0478] It can be understood that the specific implementation of the session management network element sending the first data to the second network open network element can be found in step S502, which will not be repeated here.

[0479] S1306: The second network open network element processes the first uplink data according to the NIDD configuration associated with the first network open network element to obtain second uplink data.

[0480] It can be understood that the second network open network element and the first network open network element can also synchronize the session context of the PDU session and the RDS link negotiation results, etc., and then the second network open network element can process the first uplink data to obtain second uplink data, which includes the RDS data packet.

[0481] In addition, the specific implementation of step S1306 can refer to the relevant description in step S503 and will not be repeated here.

[0482] S1307. The second network open network element sends second uplink data to the application network element.

[0483] It can be understood that the specific implementation of step S1307 can refer to step S503 and will not be repeated here.

[0484] That is to say, after the session management obtains relevant information, when a failure of the first network open network element is discovered, the second network open network element can be reselected according to the relevant information to achieve smooth switching from the first network open network element to the second network open network element in the PDU session, thereby eliminating the need to rebuild the RDS link.

[0485] The following describes in detail the process of the application network element reselecting the second network open network element.

[0486] In a possible implementation, the method shown in FIG13 further includes:

[0487] S1308: When the application network element determines that sending the first downlink data corresponding to the terminal to the first network open network element fails, the application network element sends the first downlink data to a second network open network element in the network open network element set.

[0488] It can be understood that the application network element in step S1311 determines that sending the first downlink data fails. For details, please refer to step S802 and will not be repeated here.

[0489] In addition, the application network element may reselect the second network open network element according to the relevant information.

[0490] In addition, for the specific implementation of the application network element sending the first downlink data to the second network open network element, reference may be made to step S601 in FIG6 , which will not be described again here.

[0491] S1309: The second network open network element processes the first downlink data according to the NIDD configuration associated with the first network open network element to obtain second downlink data.

[0492] It can be understood that the implementation principle of step S1309 is similar to that of step S1306. The second network open network element and the first network open network element can also synchronize the session context of the PDU session and the RDS link negotiation results, etc., and then the second network open network element can process the first downlink data to obtain second downlink data, which includes the RDS data packet.

[0493] In addition, the specific implementation of the second network open network element processing the first downlink data can be found in step S602, which will not be repeated here.

[0494] S1310. The second network open network element sends second downlink data to the session management network element associated with the PDU session between the terminal and the first network open network element.

[0495] It can be understood that the specific implementation of step S1310 can be found in step S603 and will not be repeated here.

[0496] That is to say, after obtaining relevant information, the application management network element can reselect the second network open network element based on the relevant information when a failure of the first network open network element is discovered, so as to achieve smooth switching from the first network open network element to the second network open network element in the PDU session, thereby eliminating the need to rebuild the RDS link.

[0497] In a possible implementation, the second downlink data further includes: relevant information and a second network open network element identifier for identifying the second network open network element; and the method shown in FIG13 further includes:

[0498] S1311: The session management network element determines, based on the relevant information and the second network open network element identifier, that the first network open network element in the PDU session is reselected as the second network open network element.

[0499] It can be understood that the second network open network element can also transmit the above-mentioned relevant information and the second network open network element identifier through the 3GPP-Sbi-Blinding interface, or process the above-mentioned relevant information and the second network open network element identifier into data corresponding to the protocol layer supported by the session management network element, such as the L1 layer, L2 layer, IP layer, TCP layer, or HTTP / 2 layer in Figure 4.

[0500] That is, the second open network element can determine, based on the relevant information and the second open network element identifier, that the first open network element in the PDU session is reselected as the second open network element, and then, when sending the uplink data corresponding to the PDU session, can send the uplink data to the second open network element. In addition, if the session management element does not obtain the relevant information, it can also obtain the relevant information by receiving the relevant information from the second open network element during the downlink data sending process.

[0501] It should be understood that the second open network element reselected by the session management network element in step S1305 and the second open network element reselected by the application network element in step S1318 may actually be different. The reselected open network elements may be aligned or indicated to achieve consistency between the reselected open network elements of the application network element and the session management network element. For example, the network-side data management network element may indicate the reselected open network element of the AMF network element, or the reselected open network element of the AMF network element or the reselected open network element of the session management network element may be transmitted via the 3GPP-Sbi-Blinding interface, or the application network element and the session management network element may be reselected based on the same policy to ensure that the reselected open network elements of the two are consistent.

[0502] Since in the embodiment of the present application, the application network element can transmit relevant information of the network open network element set through the NIDD configuration process at the session level, the network where the terminal is located can obtain relevant information, and thus support reselection of the network open network element within the network open network element set when the network open network element serving the terminal fails to facilitate smooth switching of the RDS link, thereby making little change to the system, having good compatibility, and reducing implementation complexity.

[0503] The above describes the overall process of the information transmission method for problem 2 of the communication system shown in FIG7 in combination with FIG13 . The following describes the information transmission method in detail.

[0504] Figure 14 is a seventh flow diagram of an information transmission method provided in an embodiment of the present application. The flow diagram shown in Figure 14 primarily involves interactions between a terminal, a session management network element, a first open network network element, a second open network network element, a first application network element, and a data management network element. The following uses the example of a terminal being a UE, a session management network element being an SMF, a first open network network element being NEF1, a second open network network element being NEF2, an application network element being an AF, and a data management network element being a UDM as an example for detailed description.

[0505] As shown in FIG14 , the information transmission method includes the following steps: S1401 to S1416 .

[0506] S1401: The AF determines to trigger the NIDD configuration process corresponding to the UE.

[0507] It is understandable that the AF may determine to trigger the NIDD configuration process corresponding to the terminal according to a local policy or an operator policy, and this embodiment of the present application does not specifically limit this.

[0508] S1402: AF sends a NIDD configuration generation request message to NEF 1. Correspondingly, NEF 1 receives the NIDD configuration generation request message from AF.

[0509] It can be understood that AF stores the relevant information in Figure 13 above, namely, the identifier NEFset ID of the network open network element set, which includes NEF1 and NEF2. NEF1 and NEF2 can synchronize NIDD configuration, session context of the PDU session between UE and NEF, and RDS negotiation results in real time and losslessly.

[0510] It should be understood that for the sake of convenience, NEFset ID is used below to represent relevant information.

[0511] In addition, the NIDD configuration generation request message includes the NEFset ID in addition to the GPSI, AF ID, and NEF1 ID.

[0512] In addition, the specific implementation of step S1402 can refer to step S302 and will not be repeated here.

[0513] S1403: NEF1 sends a NIDD authentication query request message to UDM. Correspondingly, UDM receives the NIDD authentication query request message from NEF1.

[0514] It is understood that the authentication query request message may include the content contained in the NIDD configuration generation request message. In addition, the specific implementation of step S1403 can refer to step S304.

[0515] S1404: If the NIDD configuration generation request message authentication is successful, associate the NEFset ID with the UE's subscription information for UDM processing.

[0516] It can be understood that the specific implementation of step S1404 can be found in step S1304 in Figure 13, and will not be repeated here.

[0517] In addition, when the context of the UE's PDU session is established, the SMF will subscribe to the UE's subscription information from the UDM, and then obtain the NEFset ID.

[0518] S1405: UDM sends a NIDD authentication query response message to NEF 1. Correspondingly, NEF 1 receives the NIDD authentication query response message from UDM.

[0519] It can be understood that the specific implementation of step S1405 can be found in step S306 and will not be repeated here.

[0520] S1406: NEF1 sends a NIDD configuration generation response message to AF. Correspondingly, AF receives the NIDD configuration generation response message from NEF1.

[0521] It can be understood that the specific implementation of step S1406 can be found in step S307 and will not be repeated here.

[0522] S1407. AF sends MT data to NEF1.

[0523] S1408: When the AF fails to send MT data to NEF1, the AF reselects NEF2 according to the NEFset ID.

[0524] It can be understood that the AF can send MT data after reselecting NEF2.

[0525] S1409: AF sends a first NIDD transmission request message to NEF2. Correspondingly, NEF2 receives the first NIDD transmission request message from AF.

[0526] It can be understood that the specific implementation of step S1409 can refer to step S601 and will not be repeated here.

[0527] S1410: NEF2 sends a second NIDD transmission request message to SMF. Correspondingly, SMF receives the second NIDD transmission request message from NEF2.

[0528] The second NIDD transmission request message includes MT data, NEF2 ID, and NEFset ID.

[0529] S1411. SMF sends MT data to UE.

[0530] It can be understood that the specific implementation of step S1411 can refer to steps S604 to S606, which will not be repeated here.

[0531] S1412. UE sends MO data to SMF.

[0532] It can be understood that the specific implementation of step S1412 can be found in step S501 in FIG5 , which will not be described in detail here.

[0533] S1413. SMF sends MO data to NEF1.

[0534] S1414: When SMF fails to send data to NEF1, SMF reselects NEF2 according to NEFset ID.

[0535] S1415. SMF sends MO data to NEF2.

[0536] S1416. NEF2 sends MO data to AF.

[0537] In the embodiment of the present application, the NEFset ID can be transmitted between AF, NEF1, NEF2, UDM, and SMF in the NIDD configuration process corresponding to the UE. Then, when the AF finds that the MT data transmission fails, it can reselect NEF2 according to the NEFset ID, or when the SMF finds that the MO data transmission fails, it can reselect NEF2 according to the NEFset ID, thereby realizing smooth switching between NEF1 and NEF2, so as to realize smooth switching of the RDS link, thereby making little change to the system, having good compatibility, and reducing the implementation complexity.

[0538] The above description primarily describes the solutions provided by the embodiments of the present application from the perspective of interaction between various network elements. Accordingly, the embodiments of the present application also provide a communication device for implementing the various methods described above. The communication device may be the policy network element in the method embodiments described above, or a device including the policy network element, or a component that can be used in the policy network element device; or the communication device may be the data management network element in the method embodiments described above, or a device including the data management network element, or a component that can be used in the data management network element. Alternatively, the communication device may be the first device in the method embodiments described above, or a device including the first device, or a component that can be used in the first device. It will be understood that, to implement the aforementioned functions, the communication device includes hardware structures and / or software modules corresponding to the respective functions. Those skilled in the art will readily appreciate that, in conjunction with the various exemplary units and algorithm steps described in the embodiments disclosed herein, the present application can be implemented in hardware or a combination of hardware and computer software. Whether a function is implemented in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Professionals may use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of the present application.

[0539] The embodiment of the present application can divide the functional modules of the communication device according to the above method embodiment. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The above integrated modules can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical functional division. In actual implementation, there may be other division methods.

[0540] Taking the communication device as the session management network element, or terminal, or second network open network element, or application network element, or first network open network element, or data management network element in the above method embodiment as an example, Figure 15 is a structural schematic diagram of a communication device provided in an embodiment of the present application. As shown in Figure 15, the communication device 1500 includes: a processing module 1501 and a transceiver module 1502. Among them, the processing module 1501 is used to perform the processing functions of the session management network element, or terminal, or second network open network element, or application network element, or first network open network element, or data management network element in the above method embodiment. The transceiver module 1502 is used to perform the transceiver functions of the session management network element, or terminal, or second network open network element, or application network element, or first network open network element, or data management network element in the above method embodiment.

[0541] Among them, all relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional module and will not be repeated here.

[0542] Since the communication device 1500 provided in this embodiment can execute the above communication method, the technical effects that can be obtained can refer to the above method embodiments and will not be repeated here.

[0543] In one possible design solution, the transceiver module 1502 may include a receiving module and a sending module (not shown in FIG15 ). The transceiver module is used to implement the sending function and the receiving function of the communication device 1500 .

[0544] In one possible design, communication device 1500 may further include a storage module (not shown in FIG. 15 ) storing a program or instruction. When processing module 1501 executes the program or instruction, communication device 1500 may perform the functions of a session management network element, a terminal, a second network open network element, an application network element, a first network open network element, or a data management network element in any of the methods shown in FIG. 8 to FIG. 14 .

[0545] It should be understood that the processing module 1501 involved in the communication device 1500 can be implemented by a processor or a processor-related circuit component, which can be a processor or a processing unit; the transceiver module 1502 can be implemented by a transceiver or a transceiver-related circuit component, which can be a transceiver or a transceiver unit.

[0546] For example, Figure 16 is a schematic diagram of the structure of another communication device provided in an embodiment of the present application. The communication device can be a session management network element, or a terminal, or a second network open network element, or an application network element, or a first network open network element, or a data management network element, or a chip (system) or other parts or components that can be set in a session management network element, or a terminal, or a second network open network element, or an application network element, or a first network open network element, or a data management network element. As shown in Figure 16, the communication device 1600 may include a processor 1601. In one possible design scheme, the communication device 1600 may further include a memory 1602 and / or a transceiver 1603. The processor 1601 is coupled to the memory 1602 and the transceiver 1603, such as by being connected via a communication bus.

[0547] The following is a detailed introduction to the various components of the communication device 1600 with reference to FIG16 :

[0548] The processor 1601 is the control center of the communication device 1600 and can be a single processor or a collective term for multiple processing elements. For example, the processor 1601 can be one or more central processing units (CPUs), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application, such as one or more digital signal processors (DSPs) or one or more field programmable gate arrays (FPGAs).

[0549] In one possible design, the processor 1601 may execute various functions of the communication device 1600 by running or executing software programs stored in the memory 1602 and calling data stored in the memory 1602 .

[0550] In a specific implementation, as an embodiment, the processor 1601 may include one or more CPUs, such as CPU0 and CPU1 shown in FIG16 .

[0551] In a specific implementation, as an embodiment, the communication device 1600 may also include multiple processors, such as the processor 1601 and the processor 1604 shown in FIG16 . Each of these processors may be a single-core processor (single-CPU) or a multi-core processor (multi-CPU). The processor herein may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0552] Among them, the memory 1602 is used to store the software program for executing the solution of this application, and the execution is controlled by the processor 1601. The specific implementation method can refer to the above method embodiment and will not be repeated here.

[0553] In one possible design, the memory 1602 may be a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage device that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compact disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 1602 may be integrated with the processor 1601, or may exist independently and be coupled to the processor 1601, and this embodiment of the present application does not specifically limit this.

[0554] Transceiver 1603 is used for communication with other communication devices. For example, if communication device 1600 is a session management network element, transceiver 1603 can be used to communicate with a second network open network element or a data management network element. For another example, if communication device 1600 is a terminal, transceiver 1603 can be used to communicate with a RAN.

[0555] In one possible design, transceiver 1603 may include a receiver and a transmitter (not shown separately in FIG16 ), wherein the receiver is configured to implement a receiving function, and the transmitter is configured to implement a transmitting function.

[0556] In one possible design, transceiver 1603 may be an input / output interface or an interface circuit for inputting and / or outputting signals.

[0557] In one possible design scheme, the transceiver 1603 can be integrated with the processor 1601, or it can exist independently and be coupled to the processor 1601. This embodiment of the present application does not specifically limit this.

[0558] It should be noted that the structure of the communication device 1600 shown in FIG16 does not constitute a limitation on the communication device. An actual communication device may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0559] In addition, the communication device 1600 can execute the above-mentioned communication method, so the technical effects that can be obtained can refer to the above-mentioned method embodiments and will not be repeated here.

[0560] In one possible implementation, an embodiment of the present application further provides a computer-readable storage medium having a computer program or instructions stored thereon, which implements the functions of the above-mentioned method embodiment when the computer program or instructions are executed by a computer.

[0561] In a possible implementation, an embodiment of the present application further provides a computer program product, which implements the functions of the above method embodiment when executed by a computer.

[0562] In a possible implementation, an embodiment of the present application further provides a communication system, which includes the session management network element and terminal described in the above method embodiment.

[0563] In a possible implementation, the communication system further includes the second network open network element described in the above method embodiment.

[0564] In a possible implementation, an embodiment of the present application further provides a communication system, which includes the terminal described in the above method embodiment and a second network open network element.

[0565] In a possible implementation, the communication system further includes the session management network element described in the above method embodiment.

[0566] In a possible implementation, an embodiment of the present application further provides a communication system, which includes the application network element, the first network open network element, and the data management network element described in the above method embodiment.

[0567] In a possible implementation, the communication system further includes the session management network element described in the above method embodiment.

[0568] In a possible implementation, an embodiment of the present application further provides a communication method, which includes the method described in any of the above method embodiments or any of its implementations.

[0569] In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware, or any combination thereof. When implemented using a software program, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions according to the embodiments of the present application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more available media. The available media can be magnetic media (e.g., floppy disk, hard disk, tape), optical media, or semiconductor media (e.g., solid state drive (SSD)).

[0570] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel 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 application.

[0571] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0572] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0573] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0574] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0575] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0576] Although the present application is described herein in conjunction with various embodiments, in the process of implementing the claimed application, those skilled in the art may understand and implement other variations of the disclosed embodiments by reviewing the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple situations. A single processor or other unit may implement several functions listed in the claims. Certain measures are recorded in different dependent claims, but this does not mean that these measures cannot be combined to produce good results.

[0577] Although the present application has been described with reference to specific features and embodiments thereof, it is apparent that various modifications and combinations may be made thereto without departing from the scope of the present application. Accordingly, this specification and the drawings are merely illustrative of the present application as defined by the appended claims and are deemed to cover any and all modifications, variations, combinations or equivalents within the scope of the present application. Obviously, those skilled in the art may make various modifications and variations to the present application without departing from the scope of the present application. Thus, the present application is intended to encompass such modifications and variations as fall within the scope of the claims of the present application and their equivalents.

Claims

1. An information transmission method, characterized in that: The method comprises: When the open network element serving the terminal is reselected as the first open network element, the session management element establishes a context of a protocol data unit (PDU) session with the first open network element, where the PDU session is a session between the terminal and the first open network element. In the case where the context of the PDU session is successfully established, the session management network element sends indication information to the terminal, where the indication information is used to instruct negotiation to reestablish an uplink reliable data service RDS link, where the uplink RDS link is carried by the PDU session.

2. The method according to claim 1, characterized in that The network open network element serving the terminal is reselected as the first network open network element, including: The session management network element determines, based on the subscription change information provided by the data management network element, that the network open network element serving the terminal is reselected from the second network open network element to the first network open network element, wherein the subscription change information indicates that Non-Internet Interconnection Protocol Data Transmission (NIDD) information associated with the second network open network element is changed to be associated with the first network open network element.

3. The method according to claim 1, characterized in that The network open network element serving the terminal is reselected as the first network open network element, including: In a case where the session management network element fails to send uplink data to the open network element serving the terminal, the session management network element reselects the first open network element from the second open network element as the open network element serving the terminal.

4. The method according to claim 3, characterized in that The method further comprises: The session management network element receives subscription change information from the data management network element, where the subscription change information indicates that the NIDD information associated with the second network open network element is changed to be associated with the first network open network element.

5. The method according to claim 2 or 4, characterized in that The NIDD information associated with the second network open network element is multiple NIDD information, and the contract change information is specifically used to indicate that the second network open network element associated with the first NIDD information is changed to be associated with the first network open network element, and the first NIDD information is the NIDD information containing the first application network element identifier among the multiple NIDD information.

6. The method according to claim 5, characterized in that The indication information is specifically used to instruct negotiation to reestablish the uplink RDS link corresponding to the first application network element identifier.

7. An information transmission method, characterized in that: The method comprises: The terminal receives first information, where the first information is used to instruct negotiation to reestablish an uplink reliable data service RDS link carried by a protocol data unit PDU session, or to request negotiation to reestablish a downlink RDS link carried by the PDU session, where the PDU session is a session between the terminal and a network open network element serving the terminal; The terminal initiates a negotiation and reestablishment process of the uplink RDS link according to the first information.

8. The method according to claim 7, characterized in that The uplink RDS link is a plurality of uplink RDS links, and the plurality of uplink RDS links include an uplink RDS link corresponding to each application network element identifier among the plurality of application network element identifiers associated with the PDU session, and the indication information is specifically used to indicate the negotiation to reconstruct the uplink RDS link corresponding to the first application network element identifier among the plurality of application network element identifiers; the terminal initiating the negotiation reconstruction process of the uplink RDS link according to the first information specifically includes: the terminal initiating the negotiation reconstruction process of the uplink RDS link corresponding to the first application network element identifier according to the first information.

9. The method according to claim 7, characterized in that The first information is specifically used to request negotiation to reconstruct a first downlink RDS link among multiple downlink RDS links associated with the PDU session; the terminal initiates a negotiation reconstruction process of the uplink RDS link according to the first information, specifically including: the terminal initiating a negotiation reconstruction process of the first uplink RDS link corresponding to the first downlink RDS link according to the first information.

10. An information transmission method, characterized in that: The method comprises: The first network open network element establishes a context of a protocol data unit (PDU) session with the session management network element, where the PDU session is a session between the terminal and the network open network element serving the terminal; When the context of the PDU session is successfully established, the first network open network element sends first information to the terminal, where the first information is used to request negotiation to establish a downlink reliable data service RDS link, and the downlink RDS link is carried by the PDU session.

11. The method according to claim 10, characterized in that The context includes a non-Internet interconnection protocol data transmission NIDD configuration associated with a first application network element identifier; the first information is specifically used to request negotiation to establish a downlink RDS link corresponding to the first application network element identifier among multiple downlink RDS links carried by the PDU session.

12. An information transmission method, characterized in that: The method comprises: The application network element obtains relevant information of a set of network open network elements, the set of network open network elements including a plurality of network open network elements supporting synchronization of reliable data service (RDS) information between the network open network elements, the RDS information including a non-Internet interconnection protocol (NIDD) data transmission configuration for carrying an RDS link; In the NIDD configuration process corresponding to the terminal, the application network element sends the relevant information to the network where the terminal is located, and the network where the terminal is located is used to provide services for the RDS link corresponding to the terminal.

13. The method according to claim 12, characterized in that The application network element sending the relevant information to the network where the terminal is located includes: The application network element sends a first request message to the network open network element serving the terminal, where the first request message includes parameters for generating a NIDD configuration corresponding to the terminal, and the parameters include the relevant information; In response to the first request message, the network open network element serving the terminal sends a second request message to the data management network element, where the second request message is used to request authentication of the first request message; In a case where the first request message is authenticated successfully, the data management network element associates the relevant information with the NIDD information corresponding to the network open network element serving the terminal.

14. The method according to claim 13, characterized in that The method further comprises: In the process of establishing a protocol data unit PDU session, the data management network responds to the subscription request message of the session management network element associated with the PDU session and sends the relevant information to the session management network element. The PDU session is a PDU session between the terminal and the network open network element serving the terminal.

15. The method according to claim 13, characterized in that The method further comprises: The session management network element receives first uplink data from the terminal according to the PDU session; In a case where the session management network element fails to send the first uplink data to the open network element serving the terminal, the session management network element reselects the open network element serving the terminal from the first open network element to the second open network element based on the relevant information; The session management network element sends the first uplink data to the second network open network element; The second network open network element processes the first uplink data according to the NIDD configuration associated with the first network open network element to obtain second uplink data; The second network open network element sends the second uplink data to the application network element.

16. The method according to any one of claims 12 to 15, characterized in that The method further comprises: When the application network element fails to send the first downlink data corresponding to the terminal to the open network element serving the terminal, the application network element reselects the second open network element from the first open network element as the open network element serving the terminal based on the relevant information; The application network element sends the first downlink data to the second network open network element; The second network open network element processes the first downlink data according to the NIDD configuration associated with the first network open network element to obtain second downlink data; The second network open network element sends the second downlink data to a session management network element, where the session management network element is a session management network element associated with a PDU session between the terminal and the second network open network element; The session management network element sends the second downlink data to the terminal.

17. The method according to claim 16, characterized in that The second downlink data further includes: the relevant information and a second network open network element identifier for identifying the second network open network element; and the method further includes: The session management network element determines, based on the relevant information and the second network open network element identifier, that the first network open network element associated with the PDU session is changed to being associated with the second network open network element.

18. An information transmission method, characterized in that: The method comprises: In a Non-Internet Protocol Data Transmission (NIDD) configuration process corresponding to a terminal, an open network element serving the terminal receives a first request message from an application network element, where the first request message includes parameters for generating an NIDD configuration corresponding to the terminal, the parameters including relevant information of a set of open network elements, the set of open network elements including a plurality of open network elements supporting synchronization of reliable data service (RDS) information between the open network elements, and the RDS information including an NIDD configuration for carrying an RDS link; The network open network element serving the terminal sends a second request message to the data management network element, where the second request message is used to request authentication of the first request message.

19. An information transmission method, characterized in that: The method comprises: In a Non-Internet Protocol Data Transmission (NIDD) configuration process corresponding to a terminal, a data management network element receives a second request message from an open network element serving the terminal, the second request message being used to request authentication of a first request message, the first request message including parameters for generating the NIDD configuration corresponding to the terminal, the parameters including relevant information of a set of open network elements, the set of open network elements including a plurality of open network elements supporting synchronization of reliable data service (RDS) information between the open network elements, the RDS information including a NIDD configuration for carrying an RDS link; In the case that the parameter authentication passes, the data management network element associates the relevant information with the NIDD information corresponding to the network open network element serving the terminal.

20. A communication device, characterized in that: The communication device includes a module or unit for executing the method according to any one of claims 1-19.

21. A communication device, characterized in that: The communication device includes at least one processor, and the at least one processor is configured to enable the communication device to perform the method according to any one of claims 1 to 19 through logic circuits and / or execution instructions.

22. A computer-readable storage medium, characterized in that The computer-readable storage medium includes instructions, and when the instructions are executed, the method of any one of claims 1 to 19 is implemented.

23. A computer program product, characterized in that The computer program product comprises instructions, and when the instructions are executed, the method according to any one of claims 1 to 19 is implemented.

Images