A method, device and terminal device based on network slicing communication

Abstract

The present application relates to the field of communications and provides a method, apparatus, and terminal device based on network slicing communications. The terminal device determines a first S-NSSAI for indicating a first network slice based on a first service identifier, and determines a target processing module for a data channel processed by a coprocessor according to the first S-NSSAI. In this way, the coprocessor is used to perform physical layer processing on the data through the target processing module, which can significantly improve the processing speed and real-time performance. For the S-NSSAI of different network slices, different target processing modules can be determined based on different S-NSSAIs, which can prevent the waste of resources and power consumption caused by the indifferent scheduling of the computing resources of the coprocessor in different network slicing scenarios, and can meet the real-time requirements of different application scenarios and improve the flexibility of the processing process.

Description

Technical Field

[0001] The present application relates to the field of communications, and more specifically, to a method, apparatus, and terminal device based on network slicing communications in the field of communications. Background Art

[0002] Mobile communications are developing rapidly. The 5G era has seen the emergence of numerous new application scenarios, including enhanced mobile broadband (eMBB) (e.g., live streaming, cloud gaming, and ultra-high-definition video), ultra-reliable and low-latency communications (URLLC) (e.g., autonomous driving and automated factories), and the massive internet of things (mIoT) (e.g., massive sensors deployed in measurement, agriculture, construction, logistics, and smart cities). These different application scenarios place varying demands on the network. To meet the network needs of diverse application scenarios, network slicing technology has emerged. Network slicing can provide tailored network capabilities to different users, enabling the differentiated needs of different application scenarios to be met within the same network, enabling flexible resource scheduling and customized design.

[0003] It can be seen that different network slices have different requirements for the real-time performance (i.e., latency) of the network. How to better meet the real-time requirements of different network slicing scenarios is a technical problem that needs to be solved urgently. Summary of the Invention

[0004] The embodiments of the present application provide a method, apparatus, and terminal device based on network slicing communication, which can meet the real-time requirements of different network slicing scenarios without causing waste of resources and power consumption.

[0005] In a first aspect, a method for network slicing-based communication is provided, which is applied to a terminal device, and the method includes:

[0006] In response to a user operation, generating a first service identifier, where the first service identifier is used to identify a first service to be currently executed;

[0007] Determine, according to the first service identifier, first network slice selection assistance information S-NSSAI corresponding to the first service identifier, where the first S-NSSAI is used to indicate a first network slice corresponding to the first service;

[0008] determining, based on the first S-NSSAI, target processing modules for a data channel to be processed by a coprocessor, the target processing modules including at least some of all processing modules for the data channel;

[0009] The coprocessor is used to process first data related to the first service through the target processing module.

[0010] In the method for network slicing communication provided by the embodiment of the present application, the terminal device determines the first S-NSSAI for indicating the first network slice based on the first service identifier, and determines the target processing module of the data channel processed by the coprocessor according to the first S-NSSAI. In this way, the coprocessor is used to process the data at the physical layer through the target processing module. Compared with the use of the CPU to process the data at the physical layer, the use of the coprocessor to process the data can significantly improve the processing speed and improve the real-time performance. In addition, the target processing module of the data channel is determined according to the first S-NSSAI. For the S-NSSAI of different network slices, different target processing modules can be determined based on different S-NSSAIs, which can prevent the waste of resources and power consumption caused by the indifferent scheduling of the computing resources of the coprocessor in different network slicing scenarios. It can meet the real-time requirements of different application scenarios and improve the flexibility of the processing process. Therefore, the embodiment of the present application generally realizes adaptive acceleration based on network slicing without wasting resources and power consumption, and meets the real-time requirements of different application scenarios.

[0011] In combination with any implementation of the first aspect, the terminal device includes an application module, a user routing policy (URSP) module, and a protocol stack; and

[0012] The generating of the first service identifier in response to the user operation includes:

[0013] The application module generates the first service identifier in response to the user operation; and the method further includes:

[0014] The application module sends the first service identifier to the URSP module;

[0015] The determining, according to the first service identifier, a first S-NSSAI corresponding to the first service identifier includes:

[0016] The URSP module determines the first S-NSSAI according to the first service identifier; and the method further includes:

[0017] The URSP module sends the first S-NSSAI to the protocol stack;

[0018] The determining, according to the first S-NSSAI, a target processing module for the data channel to be processed by the coprocessor includes:

[0019] The protocol stack determines the target processing module according to the first S-NSSAI;

[0020] The using the coprocessor to process the first data related to the first service through the target processing module includes:

[0021] The protocol stack calls the coprocessor, and the coprocessor processes the first data through the target processing module.

[0022] The network slicing communication-based method provided in the embodiment of the present application completes the accelerated processing of the physical layer of the data through the interaction between various modules. Since the protocol stack includes a high-level protocol stack and a physical layer, the processing of the data needs to be performed through each layer of the protocol stack. Here, the target processing module is determined by the protocol stack, which facilitates the protocol stack to call the GPU to process the data at the physical layer, and the implementation process is relatively convenient.

[0023] In combination with any implementation of the first aspect, after the URSP module sends the first S-NSSAI to the protocol stack, the method further includes:

[0024] The protocol stack establishes a packet data unit (PDU) session with the network device according to the first S-NSSAI;

[0025] After the PDU session is established, the protocol stack generates a slice service interface corresponding to the first S-NSSAI;

[0026] The protocol stack sends service interface information indicating the slice service interface to the URSP module;

[0027] The URSP module determines, according to the slice service interface, a slice data interface corresponding to the slice service interface;

[0028] The URSP module sends data interface information indicating the slice data interface to the application module, so that the application module transmits service data through the slice data interface.

[0029] In the method for network slicing communication provided by the embodiment of the present application, the slice data interface is the interface of the application module, and the slice service interface is the interface of the slice channel. For uplink service data sent through the slice data interface, it is impossible to automatically go through the slice channel, or for downlink service data sent through the slice service interface, it is impossible to automatically send it to the application module through the slice data interface. In the embodiment of the present application, the URSP module determines the corresponding slice data interface according to the slice service interface, binds the two slice interfaces, and the service data can be normally transmitted through the slice service interface and the slice data interface, that is, the URSP module forwards the uplink service data received through the slice data interface to the protocol stack through the slice service interface corresponding to the slice data interface to transmit the uplink service data through the slice channel of the slice service interface, or the URSP module forwards the downlink service data received through the slice through the slice service interface to the application module through the slice data interface corresponding to the slice service interface, thereby realizing the normal transmission of service data (uplink service data and downlink service data) based on network slicing.

[0030] In combination with any implementation of the first aspect, the application module is configured in the application layer, the URSP module is configured in the application framework layer, and the protocol stack is configured in the modem.

[0031] The network slicing communication method provided in the embodiment of the present application, compared to the solution of configuring the URSP module in the modem of a device such as a mobile phone or tablet, configures the URSP module in the application framework layer to implement the URSP function. This does not involve modification of the content of the modem, can reduce the difficulty for developers to participate in the network slicing technology simulation of 5G terminals, and improves the flexibility of implementing the URSP function.

[0032] In combination with any implementation of the first aspect, the application module is configured in the application layer, and the URSP module and the protocol stack are both configured in the application layer.

[0033] Compared with the solution of configuring the URSP module in the operating system of a device such as a computer, the network slicing communication method provided in the embodiment of the present application configures the URSP module in the application layer to implement the URSP function. This does not involve the modification of the content of the operating system layer, can reduce the difficulty of developers participating in the network slicing technology simulation of 5G terminals, and improves the flexibility of implementing the URSP function.

[0034] In combination with any implementation of the first aspect, the protocol stack is configured in a software defined radio SDR, and the URSP module is configured in the SDR.

[0035] The network slicing communication method provided in the embodiment of the present application can better realize the integration of multiple functional modules, reduce memory usage, and facilitate system management by integrating the URSP module and protocol stack into the SDR.

[0036] In combination with any implementation of the first aspect, determining, based on the first S-NSSAI, a target processing module for a data channel to be processed by the coprocessor includes:

[0037] According to the first S-NSSAI, the target processing module corresponding to the first S-NSSAI is determined from a first correspondence relationship indicating multiple S-NSSAIs and multiple groups of processing modules, and one S-NSSAI corresponds to at least one group of processing modules.

[0038] The network slice communication-based method provided in an embodiment of the present application determines the target processing module corresponding to the first S-NSSAI by indicating a first correspondence between multiple S-NSSAIs and multiple groups of processing modules, which can simplify the design and facilitate implementation.

[0039] In combination with any implementation method of the first aspect, the first correspondence includes an uplink correspondence and a downlink correspondence, wherein the uplink correspondence is used to indicate a one-to-one correspondence between M S-NSSAIs and M groups of processing modules, and the downlink correspondence is used to indicate a one-to-one correspondence between N S-NSSAIs and N groups of processing modules, and M and N are both integers greater than or equal to 1.

[0040] The network slicing communication-based method provided in the embodiment of the present application has a first correspondence relationship including an uplink correspondence relationship and a downlink correspondence relationship, which fully considers uplink transmission and downlink transmission, and can provide accelerated processing of the physical layer of uplink transmission and downlink transmission for more network slices to the greatest extent, thereby better meeting the real-time requirements of different application scenarios.

[0041] In combination with any implementation of the first aspect, determining, according to the first service identifier, a first S-NSSAI corresponding to the first service identifier includes:

[0042] The first S-NSSAI is determined according to the first service identifier from a second correspondence relationship indicating multiple service identifiers and multiple S-NSSAIs, where at least one service identifier corresponds to one S-NSSAI.

[0043] In combination with any implementation of the first aspect, the target processing module includes a first target processing module, the first target processing module is a processing module of a physical uplink shared channel PUSCH, and the first data includes signaling or uplink service data transmitted through the PUSCH.

[0044] In combination with any implementation of the first aspect, the first service is a live broadcast service, a data backhaul service, or a real-time monitoring service.

[0045] In combination with any implementation of the first aspect, the target processing module includes a second target processing module, the second target processing module is a processing module of the physical downlink shared channel PDSCH, and the first data includes signaling or downlink service data transmitted through the PDSCH.

[0046] In combination with any implementation of the first aspect, the first service is a video service or an audio service.

[0047] In combination with any implementation method of the first aspect, the target processing module includes a first target processing module and a second target processing module, the first target processing module is a processing module for the physical uplink shared channel PUSCH, and the second target processing module is a processing module for the physical downlink shared channel PDSCH, the first data includes signaling or uplink service data transmitted through the PUSCH, and the first data includes signaling or downlink service data transmitted through the PDSCH.

[0048] In combination with any implementation of the first aspect, the first business is a cloud gaming business.

[0049] In combination with any implementation of the first aspect, the coprocessor is any one of the following processors: a graphics processor GPU, an image signal processor ISP, a digital signal processor DSP, a neural network processor NPU, and a field programmable gate array FPGA.

[0050] In a second aspect, a terminal device is provided, wherein the terminal device is configured to execute the method provided in the first aspect. Specifically, the terminal device may include a module configured to execute any possible implementation of the first aspect.

[0051] In a third aspect, a terminal device is provided, comprising a processor. The processor is coupled to a memory and configured to execute instructions in the memory to implement the method of any possible implementation of the first aspect. Optionally, the terminal device further comprises a memory. Optionally, the device further comprises a communication interface, the processor being coupled to the communication interface.

[0052] In a fourth aspect, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a device, the device implements the method in any possible implementation manner of the first aspect above.

[0053] In a fifth aspect, a computer program product comprising instructions is provided, wherein when the instructions are executed by a computer, the device implements the method in any possible implementation manner of the first aspect.

[0054] In the sixth aspect, a chip is provided, comprising: an input interface, an output interface, a processor and a memory, wherein the input interface, the output interface, the processor and the memory are connected through an internal connection path, and the processor is used to execute the code in the memory. When the code is executed, the processor is used to execute the method in any possible implementation of the above-mentioned first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] Figure 1 Schematic diagram of the architecture of a communication system applicable to an embodiment of the present application.

[0056] Figure 2 It is a schematic flowchart of the PDU session establishment process provided in an embodiment of the present application.

[0057] Figure 3 It is the protocol stack of the 5G user plane provided in the embodiment of the present application.

[0058] Figure 4a This is an exemplary block diagram of the physical layer processing process of the PDSCH at the transmitting end provided in an embodiment of the present application.

[0059] Figure 4b This is an exemplary block diagram of the physical layer processing process of PDSCH at the receiving end provided in an embodiment of the present application.

[0060] Figure 5a This is an exemplary block diagram of the physical layer processing process of the PUSCH at the transmitting end provided in an embodiment of the present application.

[0061] Figure 5b This is an exemplary block diagram of the physical layer processing process of the PUSCH at the receiving end provided in an embodiment of the present application.

[0062] Figure 6 This is a diagram of the software and hardware architecture of the terminal device provided in an embodiment of the present application.

[0063] Figure 7 This is another software and hardware architecture diagram of the terminal device provided in an embodiment of the present application.

[0064] Figure 8 This is an exemplary flowchart of the network slicing communication method provided in an embodiment of the present application.

[0065] Figure 9 This is another exemplary flowchart of the method based on network slicing communication provided in an embodiment of the present application.

[0066] Figure 10 This is another exemplary flowchart of the method based on network slicing communication provided in an embodiment of the present application.

[0067] Figure 11 This is another exemplary flowchart of the method based on network slicing communication provided in an embodiment of the present application.

[0068] Figure 12 This is another exemplary flowchart of the method based on network slicing communication provided in an embodiment of the present application.

[0069] Figure 13 This is an exemplary block diagram of the device provided in the embodiment of the present application.

[0070] Figure 14 It is a schematic structural diagram of the device provided in the embodiment of the present application. DETAILED DESCRIPTION

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

[0072] The technical solutions of the embodiments of the present application can be applied to various communication systems that can support network slicing, such as the fifth generation (5G) system or the future sixth generation (6G) system.

[0073] Figure 1 This is a schematic diagram of the architecture of a communication system applicable to the embodiment of the present application. Figure 1 As shown, the communication system includes a core network device 110, an access network device 120 and at least one terminal device (such as Figure 1 The terminal devices are connected to the access network devices wirelessly, and the access network devices are connected to the core network devices wirelessly or by wire. The core network devices and the access network devices can be independent and different physical devices, or the functions of the core network devices and the logical functions of the access network devices can be integrated into the same physical device, or some of the functions of the core network devices and some of the functions of the access network devices can be integrated into one physical device. The terminal devices can be fixed or mobile. Figure 1 This is just a schematic diagram. The communication system may also include other network devices, such as wireless relay devices and wireless backhaul devices. Figure 1 The embodiments of the present application do not limit the number of core network devices, access network devices, and terminal devices included in the mobile communication system.

[0074] It should be understood that the terminal devices, access network devices and core network devices in the embodiments of the present application are all devices that can support network slicing.

[0075] The access network device in the embodiment of the present application is an access device that a terminal device uses to access the communication system wirelessly, and can be a base station NodeB, an evolved NodeB (eNodeB), a transmission reception point (TRP), a next-generation NodeB (gNB) in a 5G mobile communication system, a base station in a future mobile communication system, or an access node in a WiFi system. It can also be a wireless controller in a cloud radio access network (CRAN) scenario, a relay station, an on-board device, a wearable device, and a network device in a future evolved PLMN network. The embodiments of the present application do not limit the specific technology and specific device form adopted by the access network device.

[0076] The terminal devices in the embodiments of the present application may also be referred to as terminals, user equipment (UE), mobile stations (MS), mobile terminals (MT), etc. The terminal devices may be mobile phones, tablet computers, computers with wireless transceiver functions, virtual reality (VR) terminal devices, augmented reality (AR) terminal devices, wireless terminals in industrial control, wireless terminals in self-driving, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, etc. The embodiments of the present application do not limit the specific technologies and specific device forms adopted by the terminal devices.

[0077] Below, the technical terms and related processing procedures involved in the embodiments of the present application are first explained.

[0078] Network slicing

[0079] Network slicing divides the 5G network into "slices," each tailored to meet specific user needs. Currently, 4G networks don't segment user needs; network capabilities are fixed regardless of the specific needs. In reality, different users have varying network requirements. For example, livestreamers have higher upload requirements, while gamers prioritize low latency. Network slicing technology can provide tailored network capabilities to different users, meeting the network demands of diverse business scenarios.

[0080] In network slicing technology, it is not necessary to build a network for each application scenario. Instead, a physical network is divided into multiple virtual logical networks, and each virtual network corresponds to a different application scenario. This is called network slicing.

[0081] 3GPP categorizes the main types of 5G network slicing into the following three categories: eMBB network slicing, mIoT network slicing, and URLLC network slicing. eMBB network slicing primarily requires high bandwidth and low latency. For example, mobile phones can access eMBB network slices for high-speed downloads, 4K HD video streaming, live streaming, and cloud gaming. URLLC network slicing is primarily targeted at terminals in the Internet of Vehicles (IoV), which have high latency and reliability requirements. mIoT network slicing is primarily targeted at terminals in the Internet of Things (IoT), which require large scale, low mobility, low power consumption, low speeds, and high data capacity. For example, sensor devices can access mMTC network slices for small data packets (e.g., data collection) and system configuration updates. Furthermore, each type of network slicing can have different network slices. For example, for eMBB type network slices, there can be network slices that are respectively applied to different scenarios such as high-definition video, live streaming, cloud gaming, etc., that is, the high-definition video scenario corresponds to one network slice in the eMBB type network slice (for example, network slice 11), the live streaming scenario corresponds to another network slice in the eMBB type network slice (for example, network slice 12), and the cloud gaming scenario corresponds to another network slice in the eMBB type network slice (for example, network slice 13).

[0082] Network function virtualization (NFV) is a prerequisite for network slicing. NFV involves offloading the hardware and software functions of dedicated network equipment (such as the mobility management entity (MME) in the core network and the distributed unit (DU) in the radio access network) to virtual machines (VMs). These virtual machines are based on industry-standard commercial servers. They are commercial off-the-shelf products that are low-cost and easy to install. Simply put, NFV replaces dedicated network elements with industry-standard servers, storage, and networking equipment.

[0083] After functional virtualization, the wireless access network is called the edge cloud, and the core network is called the core cloud. VMs in the edge cloud and the core cloud are interconnected through software-defined networking (SDN).

[0084] Currently, network slicing mainly includes two types of network slicing: standardized globally applicable network slicing and operator-customized network slicing.

[0085] User route selection policy (URSP) rules

[0086] Based on network slicing, URSP rules describe the correspondence between multiple services and multiple network slices. At least one service can correspond to one network slice. Electronic devices can select different network slices for different services based on the correspondence described by the URSP rules. For example, for high-definition video services in eMBB, network slice 11 can be selected; for live broadcast services in eMBB, network slice 12 can be selected; for data collection services in MIoT, network slice 21 can be selected; for unmanned driving services in URLLC, network slice 31 can be selected.

[0087] Different services can be identified by different service identifiers, with each service being identified by one service identifier. For example, the video service is identified by service identifier 1, the massive IoT service can be identified by service identifier 2, and the live broadcast service can be identified by service identifier 3.

[0088] Different network slices can use different single network slice selection assistance information (S-NSSAI) identifiers, that is, one network slice uses one S-NSSAI identifier.

[0089] The S-NSSAI includes SST information for indicating the type or service type (slice / service type, SST) of a single network slice. The SST information is 1 byte. Currently, when the value of the SST information is 1, it indicates that the type of the network slice or service type is the eMBB type. In this case, the SST information can also correspond to the 1-byte binary 00000001; when the value of the SST information is 2, it indicates that the type of the network slice or service type is the URLLC type. In this case, the SST information can also correspond to the 1-byte binary 00000010; when the value of the SST information is 3, it indicates that the type of the network slice or service type is the mloT type. In this case, the SST information can also correspond to the 1-byte binary 00000011.

[0090] Exemplarily, the S-NSSAI also includes SD information for identifying a slice differentiator (SD). The SD information includes 3 bytes. As a supplement to the SST information, the SD information is used to further distinguish multiple network slices of the same SST. For example, for eMBB type network slices, the SD information can further indicate network slices of types such as high-definition video, live streaming, and cloud gaming.

[0091] In the embodiment of the present application, the URSP rules may be obtained from the network or from a local universal platform, and there is no limitation on this.

[0092] Packet Data Unit (PDU) Session

[0093] Network slices are carried through PDU sessions, and one PDU session can only carry one network slice. After determining the network slice, the electronic device initiates a PDU session based on the network slice to the core network through the access network device to connect the electronic device to the network and perform uplink and downlink transmission.

[0094] Figure 2 This is a schematic flowchart of the PDU session establishment process provided in an embodiment of the present application. The PDU session establishment process is described using a UE as an example terminal device and a gNB as an example access network device.

[0095] It should be noted that Figure 2 The PDU session establishment process shown is a simplified process, which shows the important steps of the PDU session establishment process. For other related details, please refer to the relevant description of the existing standard protocol (for example, Section 4.3.2.2 of TS 23502 protocol) and will not be repeated here.

[0096] In step S201, the UE sends a PDU session establishment request to the access and mobility management function (AMF) through the gNB. The PDU session establishment request may include information such as the PDU Session ID, Requested PDU Session Type, S-NSSAI, and data network name (DNN).

[0097] In step S202, the AMF selects an appropriate session management function (SMF) according to the PDU session establishment request.

[0098] In step S2031, AMF sends NsmfPDU session create SM Context Request to SMF, including PDU Session Establishment Request, subscription permanent identifier (SUPI), DNN, AMF ID, User Location Information and other information.

[0099] In step S2032, the SMF responds to the Nsmf PDU session create SM Context Request and replies to the AMF with Nsmf PDU session create SM Context Response.

[0100] In step S204, the SMF selects a Policy Control Function (PCF) to obtain policy data.

[0101] In step S205, the SMF selects a user plane function (UPF) and allocates an IP address or prefix to the UE. If IPv6 is involved, the SMF allocates an Interface Identifier to the UE to form a link-local address.

[0102] In step S206, the signaling interaction of the N4 interface is completed between the SMF and the UPF.

[0103] In step S2071, the SMF sends a NamfCommunicationN1N2MessageTransfer message to the AMF. It is understood that through this message, the SMF sends information about the N1 and N2 interfaces to the AMF. This message includes the PDU Session Resource Setup Accept response (PDU Session Resource Setup Accept) sent by the AMF to the UE and the AN-specific resource setup request (AN-specific resource setup) initiated by the SMF to the gNB.

[0104] In step S2072, AMF sends a NamfCommunication N1 N2MessageTransfer Ack message to SMF.

[0105] In step S2081, the AMF sends an N2 PDU Session Request (i.e., PDU Session Resource Setup Request) message and an N1 NAS message to the gNB, where the N2 PDU Session Request is used to request the establishment of an N2 PDU session, and the N1 NAS message includes a PDU Session Establishment Accept message and an AN-specific resource setup message initiated by the SMF.

[0106] In step S2082, the AMF transparently transmits the PDU Session Establishment Accept message and the resource establishment request (AN-specific resource setup) message initiated by the SMF to the UE through the gNB.

[0107] In step S2083, a resource connection is established between the UE and the gNB according to the AN-specific resource setup message.

[0108] In step S2084, the gNB responds to the AMF with an N2 PDU Session Request Ack (i.e., PDU Session Resource Setup Response) message, which carries the gNB side downlink media plane tunnel endpoint information.

[0109] At this point, the transmission channel for uplink transmission has been completed and uplink transmission can be performed.

[0110] In step S2091, the AMF sends an NsmfPDUSessionUpdateSMContextRequest message to the SMF. This message carries the resource establishment response from the gNB to the SMF.

[0111] In step S2092, the SMF initiates N4 Session Modification signaling to the UPF to negotiate the downlink media plane tunnel information on the gNB side.

[0112] In step S2093, SMF replies NsmfPDUSessionUpdateSMContext Response message to AMF.

[0113] In step S2110, SMF sends an Nsmf PDU Session SM Context Status Notify (Nsmf PDU Session Notify SMContext Status) message to AMF.

[0114] At this point, the transmission channel for downlink transmission has been completed and downlink transmission can be performed.

[0115] Protocol stack, high-level protocol stack

[0116] Figure 3 It is the protocol stack of the 5G user plane provided in the embodiment of the present application.

[0117] For terminal devices (e.g., UE) and access network devices (e.g., gNB), illustratively, the user plane protocol stack includes a service data adaptation protocol (SDAP) layer, a packet data convergence protocol (PDCP) layer, a radio link control layer protocol (RLC) layer, a media access control control element (MAC) layer, and a physical layer (PHY). The terminal device and the access network device can interact through signaling at each layer.

[0118] The SDAP layer is a new sublayer added to the user plane of 5G / NR. One of its functions is to map Quality of Service (QoS) flows to Data Radio Bearers (DRBs). In 5G / NR, the interface between the gNB and the 5G core network is a new one, based on QoS flows, while the air interface is based on user-based DRBs. It can be said that DRBs are carried from the PDCP onwards. Therefore, a new adaptation sublayer, SDAP, is required in 5G / NR to map QoS to DRBs.

[0119] The PDCP layer is used for data transmission, SN number management, PDCP PDU duplication detection, encryption and decryption, and integrity protection.

[0120] The RLC layer is responsible for segmentation / concatenation, retransmission control, duplicate detection, and sequence transmission to upper layers.

[0121] The MAC layer controls logical channel multiplexing, hybrid ARQ retransmission, and uplink and downlink scheduling. MAC serves the RLC in the form of logical channels.

[0122] The PHY layer is used to implement data encoding / decoding, modulation / demodulation, multi-antenna mapping, and other types of physical layer functions (see the detailed description of the physical layer processing below). The physical layer provides services to the MAC layer in the form of a transmission channel.

[0123] In the embodiment of the present application, the high-level protocol stack includes various layers above the PHY layer in the protocol stack, for example, Figure 3 In the user plane, the high-level protocol stack includes the MAC layer, PLC layer, PDCP layer and SDAP layer.

[0124] It should be understood that the protocol stack can implement its functions purely through software, or it can implement its functions through a combination of software and hardware. In the case where the protocol stack functions are implemented purely through software, the protocol stack does not rely on dedicated hardware (dedicated chips, modules, etc.). The protocol stack can adopt open source protocol stacks (such as OAI and srsRAN) or commercial protocol stacks, without any limitation here.

[0125] Physical layer processing

[0126] The physical downlink shared channel (PDSCH) and the physical uplink shared channel (PUSCH) are both channels of the physical layer. PDSCH is used for downlink transmission, and PUSCH is used for uplink transmission. Both are used to transmit service data and signaling.

[0127] The PHY layer processing includes the physical layer processing of PDSCH and PUSCH. It should be understood that the physical layer processing of PDSCH or PUSCH in the embodiments of the present application refers to the physical layer processing of data (or service data or signaling or information) on PDSCH or PUSCH, wherein the data (or service data or signaling or information) is carried on PDSCH or PUSCH.

[0128] The following, combined Figure 4a and Figure 4b , briefly introduce the physical layer processing process of PDSCH and PUSCH respectively.

[0129] Figure 4a This is an exemplary block diagram of the physical layer processing process of the PDSCH at the transmitting end provided in an embodiment of the present application. Figure 4b This is an exemplary block diagram of the physical layer processing process of the PDSCH at the receiving end provided by the embodiment of the present application. In other words, Figure 4b The physical layer processing process of PDSCH at the receiving end is Figure 4a The reverse process of the physical layer processing of the PDSCH at the transmitting end.

[0130] exist Figure 4a In the physical layer processing of the PDSCH at the transmitting end, the process includes: cyclic redundancy check (CRC) insertion, code block segmentation, channel coding, rate matching, scrambling, modulation, layer mapping, antenna port mapping and resource block mapping. Figure 4bThe physical layer processing of the PDSCH at the receiving end includes: resource block demapping, antenna port demapping, layer demapping, demodulation, descrambling, rate matching, channel decoding, code block merging, and CRC removal.

[0131] CRC insertion, CRC removal

[0132] For the transmitting side, a CRC is added to each transport block to provide error detection.

[0133] At the receiving end, the added CRC is removed from the transport block to restore the original transport block.

[0134] Code block segmentation and code block merging

[0135] On the transmitter side, the internal interleaver defined in the encoder is only used for coded blocks of limited size. If the coded block size of a transport block (including the transport block CRC) exceeds the maximum code block size, the transport block must be segmented into smaller code blocks. Furthermore, after segmenting the transport block into multiple code blocks, a CRC is appended to each code block.

[0136] For the receiving end, the previously segmented code blocks can be merged and the decoded transport blocks can be restored according to the scheduling information.

[0137] Channel coding and channel decoding

[0138] At the transmitting end, each code block is channel-coded to improve the reliability of the transmission process. For ease of description, the data after channel coding is referred to as a coded bit block.

[0139] At the receiving end, the coded bit block is decoded using the same coding method to restore the code block before channel coding.

[0140] Rate matching and derate matching

[0141] For the transmitter, the purpose of rate matching is to parse the coded bit blocks sent by the signal encoder to determine the exact set of coded bits to be transmitted in a given transmission time interval (TTI) or subframe. It should be understood that rate matching operates on the set of all coded bit blocks corresponding to a transport block, rather than on the coded bits corresponding to a single code block separately.

[0142] At the receiving end, the rate-matched coded block transport block is de-rate matched to recover the un-rate-matched coded bit block.

[0143] Scrambling and descrambling

[0144] Without scrambling, the signal encoder at the receiving end would, at least in theory, match both the interfering signal and the desired signal, rendering interference suppression impossible. Therefore, to effectively suppress interference, the transmitting end scrambles the rate-matched transport blocks, using different scrambling code sequences in adjacent cells. This randomizes the interfering signal after scrambling, ensuring full utilization of the processing gain provided by channel coding. Furthermore, scrambling is also performed, illustratively, based on the receiving end's identifier. For ease of description, the scrambled data is referred to as a scrambled bit block.

[0145] At the receiving end, the scrambled bit block is descrambled to recover the rate-matched coded bit block.

[0146] Modulation and demodulation

[0147] At the transmitter, the scrambled bits are converted into corresponding complex-valued modulation symbol blocks, and modulation schemes such as QPSK, 16QAM, 64QAM, and 256QAM can be used. For ease of description, the modulated data is referred to as modulation symbols.

[0148] At the receiving end, the modulated symbols are demodulated to restore the scrambled bit blocks.

[0149] Layer mapping, de-layer mapping

[0150] At the transmitter, modulation symbols are mapped to multiple layers (for example, 4 or 8 layers) to split data into multiple transmission paths. 3GPP R10 allows up to 4 layers for uplink transmission and 8 layers for downlink transmission. Downlink diversity mode is also available.

[0151] At the receiving end, the data is de-layered and mapped.

[0152] Antenna port mapping, antenna demapping

[0153] For the transmitter, antenna port mapping jointly processes the modulation symbols and maps the result to a set of antenna ports for transmission. Depending on the multi-antenna transmission scheme, antenna port mapping can be configured in different ways, including transmit diversity, beamforming, and spatial division multiplexing.

[0154] At the receiving end, the data is de-antenna-port mapped.

[0155] Resource block mapping, resource block demapping

[0156] For the transmitter, the symbols to be transmitted on each antenna port are mapped to the available resource elements in a set of resource blocks, where each resource block can include 84 resource elements (7 orthogonal frequency division multiplexing (OFDM) symbols, each symbol has 12 subcarriers).

[0157] At the receiving end, the symbol carried by each resource element is mapped to each antenna port.

[0158] Figure 5a This is an exemplary block diagram of the physical layer processing process of the PUSCH at the transmitting end provided in an embodiment of the present application. Figure 5b This is an exemplary block diagram of the physical layer processing process of the PUSCH at the receiving end provided by the embodiment of the present application. That is, Figure 5b The physical layer processing process of the PUSCH at the receiving end is Figure 5a The reverse process of the physical layer processing of the PUSCH at the transmitting end.

[0159] exist Figure 5a In the PUSCH physical layer processing of the transmitter, the process includes: CRC insertion, code block segmentation, channel coding, rate matching, scrambling, modulation, layer mapping, precoding, antenna port mapping and resource block mapping. Figure 5b The physical layer processing of the PUSCH at the receiving end includes: resource block demapping, antenna port demapping, precoding demapping, layer demapping, demodulation, descrambling, rate matching demapping, channel decoding, code block merging, and CRC removal.

[0160] It can be seen that the physical layer processing process of PUSCH is roughly the same as that of PDSCH. The biggest difference is that the physical layer processing process of PUSCH adds precoding and de-precoding processes, which are optional and specific to UE implementation.

[0161] The above is only a brief introduction to the physical layer processing of PDSCH and PUSCH. For the specific description of each process, please refer to the relevant description of the prior art and will not be repeated here.

[0162] Since the embodiments of the present application are mainly applied to various terminal devices, the present application mainly involves the processing of the physical layer of the PDSCH and PUSCH by the terminal device. Figure 5a Execute each step in the direction of the arrow; in downlink transmission, the terminal device acts as the receiving end and follows Figure 4b Follow the steps in the direction of the arrows shown.

[0163] For ease of description, the following defines multiple processing modules with different functions for PDSCH or PUSCH. Each processing module is used to perform a step in the physical layer processing of the PDSCH or PUSCH. For example, a processing module for performing channel coding is defined as a channel coding module, and a processing module for performing channel decoding is defined as a channel decoding module.

[0164] coprocessor

[0165] A coprocessor is a processor developed and implemented to assist a central processing unit (CPU) in completing tasks that it cannot perform, or that it performs inefficiently or ineffectively. There are many tasks that a CPU cannot perform, such as signal transmission between devices and management of connected devices; while other tasks that a CPU cannot perform efficiently or effectively include graphics processing and audio processing. To perform these tasks, coprocessors were created.

[0166] Exemplarily, the coprocessor may include but is not limited to any of the following processors: a graphics processing unit (GPU), an image signal processor (ISP), a digital signal processor (DSP), a neural-network processing unit (NPU), and / or a field-programmable gate array (FPGA) and other various processors.

[0167] In an embodiment of the present application, based on the judgment of the protocol stack, the coprocessor can perform physical layer processing on the data to increase the processing speed.

[0168] The following is a schematic description of the software and hardware architecture applicable to the embodiments of the present application.

[0169] Mobile phone software system

[0170] Figure 6 This is a diagram of the hardware and software architecture of the terminal device provided in the embodiment of this application. It can be understood that Figure 6 This is a hardware and software architecture diagram using the Android system as an example, which is applicable to devices such as mobile phones, tablets, and smart watches. Figure 6 The layered architecture divides the software into several layers, each layer has a clear role and division of labor, and the layers communicate with each other through software interfaces. In some embodiments, the Android software system is divided into four layers, from top to bottom, namely the application layer, application framework layer, Android runtime (Android runtime) and system library and driver layer, and below the driver layer is the hardware layer.

[0171] The application layer may include a series of applications. For example, the application may include applications such as camera, call, short message, video, music, gallery, calendar, map, navigation, Bluetooth, etc.

[0172] The application framework layer provides an application programming interface (API) and programming framework for the application layer's applications. The application framework layer includes some predefined functions.

[0173] Exemplarily, the application framework layer may include a window manager, a content provider, a telephony manager, a resource manager, a connection manager, a URSP module, and the like.

[0174] The window manager is used to manage window programs. The window manager can obtain the display size, determine whether there is a status bar, lock the screen, take screenshots, etc.

[0175] Content providers are used to store and retrieve data and make it accessible to applications. The data may include videos, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

[0176] The phone manager is used to provide communication functions of the electronic device 100, such as management of call status (including answering, hanging up, etc.).

[0177] The resource manager provides various resources for applications, such as localized strings, icons, images, layout files, video files, and so on.

[0178] The connection manager is used to provide functions related to network changes. For example, the connection manager can be used to monitor network connections (Wi-Fi, GPRS, UMTS, etc.), send broadcast attempts when network connections change, attempt to switch to another network when a network connection fails, and provide an application interface that allows applications to query the coarse-grained or fine-grained status of available networks.

[0179] The URSP module is used to determine the network slice corresponding to the service based on the URSP rules, and is also used to receive, update, and delete URSP rules, and is used to map the data interface of the application layer to the corresponding service interface, forward uplink service data from the application layer to the protocol stack, and forward downlink service data from the protocol stack to the application layer. Exemplarily, the URSP module is also used to store URSP rules.

[0180] The Android runtime includes the core library and the virtual machine. The Android runtime is responsible for scheduling and management of the Android system.

[0181] The core library consists of two parts: one is the function that needs to be called by the Java language, and the other is the Android core library.

[0182] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files in the application layer and application framework layer as binary files. The virtual machine is responsible for performing functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0183] The system library can include multiple functional modules, such as a surface manager, media libraries, a 3D graphics processing library (such as OpenGL ES), and a 2D graphics engine (such as SGL).

[0184] The surface manager is used to manage the display subsystem and provide fusion of 2D and 3D layers for multiple applications.

[0185] The media library supports playback and recording of a variety of common audio and video formats, as well as static image files. The media library can support a variety of audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

[0186] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0187] A 2D graphics engine is a drawing engine for 2D drawings.

[0188] The driver layer is the layer between hardware and software. For example, the driver layer may include display drivers, camera drivers, audio drivers, sensor drivers, etc.

[0189] The hardware layer is the lowest level module in the device, including various types of processors, cameras, and other devices. Processors can include modems, GPUs, central processing units (CPUs), application processors (APs), ISPs, video codecs, DSPs, baseband processors, FPGAs, and / or NPUs.

[0190] The modem is configured with a protocol stack, which is used to initiate a PDU session based on the network slice, and determine whether to use a coprocessor (for example, a GPU) to perform physical layer processing on the data based on the network slice. When it is determined that a coprocessor is required to perform physical layer processing on the data, at least one processing module of the physical layer is selected based on the network slice, and the GPU is used to process the data through the at least one processing module to achieve acceleration of the physical layer and improve the processing speed.

[0191] In the embodiments of the present application, as previously described, the aforementioned processors such as a GPU, ISP, DSP, NPU, and / or FPGA may be collectively referred to as coprocessors. Based on the judgment of the protocol stack, the coprocessor may perform physical layer processing on the data to increase the processing speed.

[0192] It should be understood that Figure 6 The software and hardware architecture diagram shown is for illustrative purposes only and should not be construed as limiting the embodiments of the present application.

[0193] For example, in some embodiments, the URSP module can be configured in a modem to implement the URSP module's functions in the modem. In other words, the URSP module and protocol stack are both integrated in the modem. However, in embodiments where the URSP module is configured in the modem, due to the integration of software and hardware, implementing the URSP module's functions requires modifications to the relevant contents of the modem, thereby increasing the difficulty for developers to participate in the network slicing technology simulation of 5G terminals. In addition, implementing the URSP function based on the modem lacks flexibility.

[0194] As a preferred method, Figure 6 As shown, the URSP module is removed from the hardware modem and configured in the application framework layer to implement the URSP function. This does not involve modifying the content of the modem, which can reduce the difficulty for developers to participate in the network slicing technology simulation of 5G terminals and improve the flexibility of implementing the URSP function.

[0195] Figure 7 This is another hardware and software architecture diagram of the terminal device provided in the embodiment of this application. It can be understood that Figure 7 The software architecture above the hardware layer shown is more suitable for computer devices such as laptops and personal computers. Figure 7 ,The software architecture from top to bottom can include: application layer, operating system layer and driver layer, and below the driver layer is the hardware layer.

[0196] The application layer may include, for example, URSP modules, software defined radio (SDR) modules, video, office software, music, video and other applications.

[0197] SDR is a radio broadcast communications technology based on software-defined wireless communication protocols rather than hard-wired implementations. This means frequency bands, air interface protocols, and functionality can be upgraded through software downloads and updates, rather than requiring a complete hardware replacement. SDR offers an effective and secure solution to the challenges of building multi-mode, multi-frequency, and multi-function wireless communication devices.

[0198] Different from Figure 6 The modem is configured with a protocol stack. Figure 7 In the software architecture shown, a protocol stack is configured in the SDR. For a detailed description of the protocol stack, please refer to the relevant description above and will not be repeated here.

[0199] Different from Figure 6 The URSP module is configured in the application framework layer. Figure 7 In the software architecture shown, the URSP module is set in the application layer. For the specific description of the URSP module, please refer to the relevant description above and will not be repeated here.

[0200] Understandably, Figure 7 In the software architecture shown, the URSP module and SDR can be installed as applications on a device such as a computer, and the technical solution of the present application can be implemented by running the URSP module and SDR applications.

[0201] It should also be understood that the URSP module can be used as an independent instance process of the software framework (such as Figure 7 As shown), it can also be integrated into the SDR, so that the protocol stack and the URSP module are both integrated into the SDR.

[0202] The operating system layer serves as the bridge between hardware and software, consisting of both machine instructions and generalized instructions. Machine instructions are those that the CPU can directly recognize and execute, while generalized instructions are software instructions defined and interpreted by the system. For example, the operating system layer includes a content management module, a process management module, a file management module, a device management module, and a driver management module.

[0203] The memory management module is mainly used for the management of internal memory. Its main tasks are to allocate memory space, ensure that there is no conflict in the storage space occupied by each job, and prevent each job from interfering with each other in its own storage area.

[0204] The process management module essentially manages the central processing unit (CPU), often referred to as the processor management module. It manages several aspects, including process control, process synchronization, inter-process communication, and process scheduling. Process control primarily handles process creation, state transitions, process cancellation, and the allocation and recycling of related process resources. Process synchronization primarily addresses inheritance relationships, including process synchronization and mutual exclusion. Inter-process communication primarily handles information exchange between collaborating processes. Finally, process scheduling involves selecting a process from the ready queue according to a specific algorithm for actual execution on the processor.

[0205] The file management module is used to manage various hardware resources, such as USB flash drives, network drives, keyboards, etc.

[0206] The device management module is responsible for managing various peripheral devices (peripherals), including allocation, startup, and troubleshooting. Its primary task is to ensure that when a user requests an external device, they must request it, and the operating system must allocate it before use. When a user's program calls upon a peripheral, the operating system takes over the responsibility of driving it.

[0207] The driver management module is used to provide the connection between programs and hardware, and to provide various system services and interfaces.

[0208] The driver layer is the layer between hardware and software. For example, the driver layer may include a network card driver, a hard disk driver, a graphics card driver, and an audio driver.

[0209] The hardware layer is the lowest level module in the device. For example, it can include network cards, hard disks, graphics cards, and various types of processors. For example, processors can include GPUs, CPUs, APs, ISPs, video codecs, DSPs, NPUs, and other processors.

[0210] It should be understood that Figure 7 The software and hardware architecture diagram shown is for illustrative purposes only and should not be construed as limiting the embodiments of the present application.

[0211] For example, in some embodiments, the URSP module can be configured in the operating system layer to implement the functions of the URSP module in the operating system layer. However, in embodiments where the URSP module is configured in the operating system layer, implementing the functions of the URSP module involves modifying relevant content in the operating system layer, thereby increasing the difficulty for developers to participate in network slicing technology simulation for 5G terminals. In addition, implementing the URSP functions in the operating system layer lacks flexibility.

[0212] As a preferred method, Figure 7As shown, the URSP module is removed from the operating system layer and configured in the application layer to implement the URSP function. This does not involve modifying the content of the operating system layer, which can reduce the difficulty for developers to participate in the network slicing technology simulation of 5G terminals and improve the flexibility of implementing the URSP function.

[0213] It should be understood that Figure 6 and Figure 7 The hardware and software architecture diagram shown is for illustrative purposes only and should not be construed as limiting the embodiments of the present application. In other embodiments, the software architecture in the hardware and software architecture may also exist in other forms, including more or fewer modules, but at least including the functional modules of the application layer, URSP module, and protocol stack.

[0214] Based on the problem of how to better meet the real-time requirements in different network slicing scenarios in the prior art, an embodiment of the present application provides a method for network slicing communication. It determines whether a coprocessor is needed to process the data at the physical layer according to the network slice corresponding to the service. When it is determined that a coprocessor is needed to process the data at the physical layer, at least one processing module of the physical layer is determined according to the network slice, and the coprocessor is used to process the data through the at least one processing module. Compared with using a CPU to process data at the physical layer, using a coprocessor to process data can significantly increase the processing speed and improve real-time performance. In addition, the physical layer processing module to be processed by the coprocessor is determined according to the network slice, and different processing modules to be processed by the coprocessor can be determined according to different network slices. While preventing the indiscriminate scheduling of computing resources using the coprocessor in different network slicing scenarios, which causes waste of resources and power consumption, it can match the real-time requirements of different application scenarios and improve the flexibility of the processing process. The embodiment of the present application generally realizes adaptive acceleration based on network slicing to meet the real-time requirements of different application scenarios.

[0215] It should be noted that the "data" referred to in the embodiments of this application is data in a broad sense, representing any content transmitted via bits, including service data and signaling. Service data can also be understood as application data, such as video data, audio data, and other data associated with actual services. Signaling can be information used to transmit service data, such as the PDU session establishment request sent by a terminal during the establishment of a PDU session and the PDU session establishment response received.

[0216] The following, combined Figures 8 to 10The embodiments of the present application are described in detail through the interaction between various modules in the terminal device. Taking the GPU as an example of a coprocessor, through the mutual interaction between the application layer, the URSP module, the protocol stack, the GPU, and the CPU (not shown in the figure), the GPU is used to process the data at the physical layer to achieve physical layer acceleration, improve the processing speed, and meet the real-time requirements of the current network slicing scenario.

[0217] It should be understood that the URSP module and protocol stack can be applied to Figure 6 and Figure 7 And any other form of software architecture, the embodiments of this application do not impose any limitations.

[0218] Figure 8 This is an exemplary flow chart of a method 800 for network slicing communication provided in an embodiment of the present application. In method 800, the terminal device determines the target processing module for PUSCH processing using a GPU based on the S-NSSAI used to identify the network slice. The GPU processes data (service data and signaling) through the target processing module to achieve physical layer acceleration, improve processing speed, and meet the real-time requirements of the current network slicing scenario.

[0219] It should be understood that in method 800, for data (service data and signaling) transmitted via the PDSCH, the CPU is used to perform physical layer processing on the data in accordance with the prior art.

[0220] In step 801, application #1 detects a user operation on application #1.

[0221] For example, the user opens application #1, and application #1 can detect the user's operation of opening application #1.

[0222] Application #1 can be a client application or a browser application, without any limitation. For example, application #1 can be a live video broadcast that has a high real-time requirement for uplink transmission (e.g., ), real-time high-definition monitoring, high-definition industrial video backhaul and other applications require the transmission of a large amount of uplink data to the network. For another example, application #1 can also be, for example Browser applications such as .

[0223] In step 802, application #1 sends service identifier #1 to the URSP module.

[0224] Correspondingly, the URSP module receives the service identifier #1.

[0225] After detecting the user's operation, application #1 generates a service identifier #1 based on the service executed by application #1 and sends the service identifier #1 to the URSP module.

[0226] It can be understood that service identifier #1 is used to identify the service executed by application #1 (recorded as service #1). For example, service #1 is a live broadcast service, and service identifier #1 is used to identify the live broadcast service.

[0227] Exemplarily, the service identifier can be represented by at least one of an application identification (APP ID), an Internet protocol (IP) triplet information, a fully qualified domain name (FQDN), and a DNN. The IP triplet information includes: a source IP address, a target IP address, and an upper-layer protocol type. Specifically, the source IP address is the IP address of the PDU session corresponding to the UE, the target IP address is the IP address of the server storing the service data of the target service, and the upper-layer protocol type is the transmission control protocol (TCP) or the user datagram protocol (UDP). For example, for a client application, an APP ID or an FQDN can be used as a service identifier. For another example, for a browser application, an FQDN can be used as a service identifier.

[0228] In step 803, after receiving the service identifier #1, the URSP module determines the S-NSSAI #1 corresponding to the service identifier #1.

[0229] The URSP module stores a correspondence between multiple service identifiers and multiple S-NSSAIs (denoted as correspondence #1). At least one service identifier corresponds to one S-NSSAI. One S-NSSAI is used to uniquely identify one network slice, and one service identifier is used to uniquely identify one service. The URSP module receives service identifier #1 and determines the S-NSSAI corresponding to service identifier #1 (denoted as S-NSSAI #1) from the correspondence #1 between multiple service identifiers and multiple S-NSSAIs. S-NSSAI #1 is used to indicate network slice #1. That is, the URSP module determines network slice #1 corresponding to the service identified by service identifier #1.

[0230] In implementation, the URSP module may include a database unit, a URSP unit, and a routing unit. The database unit stores a correspondence relationship #1 between multiple service identifiers and multiple S-NSSAIs. The URSP unit is configured to determine the corresponding S-NSSAI from the correspondence relationship #1 stored in the database unit based on a service identifier. For service identifier #1, the URSP unit is configured to determine the S-NSSAI corresponding to service identifier #1 from the correspondence relationship #1 stored in the database unit based on service identifier #1. The routing unit is configured to map the data interface of the application layer to the service interface (see the description of step S809 for details).

[0231] In step S804, the URSP module sends S-NSSAI#1 to the protocol stack.

[0232] Correspondingly, the protocol stack receives S-NSSAI#1.

[0233] In step S805, the protocol stack determines the target processing module for PUSCH to be processed by GPU according to S-NSSAI#1.

[0234] After receiving S-NSSAI#1, the protocol stack determines, based on S-NSSAI#1, that the GPU is required to process the PUSCH. It then determines, from among the multiple PUSCH processing modules, a target processing module for GPU processing. This allows the GPU to process data (service data and signaling) transmitted via the PUSCH using the target processing module to improve processing speed. It should be understood that the multiple PUSCH processing modules refer to all PUSCH processing modules. This step can be performed by a higher-level protocol stack within the protocol stack.

[0235] As mentioned above, a PUSCH (or PDSCH) processing module is used to perform a step in the physical layer processing of the PUSCH (or PDSCH). Figure 5a The multiple processing modules of the PUSCH of the terminal device include: CRC insertion module, code block segmentation module, channel coding module, rate matching module, scrambling module, modulation module, layer mapping module, precoding module, antenna port mapping module and resource block mapping module.

[0236] The target module unit of PUSCH includes at least one processing module, which can be part of the multiple processing modules of PUSCH, or all the processing modules among the multiple processing modules, and is specifically related to the network slice #1 identified by S-NSSAI#1.

[0237] For example, if service #1 corresponding to network slice #1 is a high-definition real-time data backhaul service, a live broadcast service, or a high-definition real-time monitoring service, the target processing module determined based on S-NSSAI #1 used to identify network slice #1 may be all processing modules of the PUSCH. For another example, if service #1 corresponding to network slice #1 is a non-high-definition data backhaul service or a non-high-definition real-time monitoring service, the target processing module determined based on S-NSSAI #1 used to identify network slice #1 may be some processing modules of the PUSCH.

[0238] Exemplarily, a correspondence relationship (denoted as correspondence relationship #2) is stored in the protocol stack, and the correspondence relationship #2 includes an uplink correspondence relationship and a downlink correspondence relationship. The uplink correspondence relationship and the downlink correspondence relationship are both used to indicate the correspondence between multiple S-NSSAIs and multiple groups of processing modules. One S-NSSAI corresponds to a group of processing modules, each group of processing modules includes at least one processing module, and the processing modules in each group of processing modules are not exactly the same.

[0239] During implementation, the protocol stack matches S-NSSAI#1 with the above-mentioned correspondence #2 (uplink correspondence and downlink correspondence), and finally matches a group of processing modules corresponding to S-NSSAI#1 from the uplink correspondence. This group of processing modules is the target processing module for PUSCH using GPU processing corresponding to S-NSSAI#1.

[0240] Table 1 shows the uplink correspondence relationship shown in an embodiment of the present application. The first column represents the S-NSSAI, and the second column represents a group of processing modules corresponding to a specific S-NSSAI. For example, a group of processing modules corresponding to S-NSSAI#A includes: a channel coding module, a rate matching module, and an scrambling module; a group of processing modules corresponding to S-NSSAI#B includes a channel coding module; a group of processing modules corresponding to S-NSSAI#C is all processing modules for PUSCH; a group of processing modules corresponding to S-NSSAI#D includes: a channel coding module and a modulation module. S-NSSAI#1 can be any S-NSSAI in Table 1.

[0241] Table 2 is a downlink correspondence relationship shown in an embodiment of the present application. For specific descriptions, please refer to the description in Table 1 and will not be repeated here.

[0242] It should be noted that the same S-NSSAI can correspond to both a set of processing modules for PUSCH and a set of processing modules for PDSCH. In other words, the data under the network slice identified by the S-NSSAI requires the GPU to perform physical layer processing on PUSCH and PDSCH to achieve physical layer acceleration of PUSCH and PDSCH. As shown in Tables 1 and 2, S-NSSAI#A corresponds to the channel coding module, rate matching module, and scrambling module of PUSCH, as well as the channel decoding module and rate matching module of PDSCH.

[0243] Alternatively, an S-NSSAI can correspond only to a set of processing modules for the PUSCH. In other words, the data under the network slice identified by the S-NSSAI needs to use the GPU to perform physical layer processing only on the PUSCH. For example, S-NSSAI#B shown in Table 1 corresponds only to the channel coding module for the PUSCH.

[0244] Alternatively, an S-NSSAI may correspond only to a set of processing modules for PDSCH, that is, the data under the network slice identified by the S-NSSAI needs to use the GPU to perform physical layer processing only on PDSCH.

[0245] It should be understood that the upstream correspondence shown in Table 1 and the downstream correspondence shown in Table 2 are merely illustrative and should not constitute a limitation to the embodiments of the present application.

[0246] Table 1 Uplink correspondence

[0247]

[0248] Table 2 Downstream Correspondence

[0249]

[0250] In step S806, the protocol stack initiates a PDU session according to S-NSSAI#1 and performs a PDU session establishment process.

[0251] That is to say, the protocol stack initiates a PDU session based on network slice #1 identified by S-NSSAI #1, and completes the establishment of the PDU session through the interaction between the access network device and the core network device.

[0252] In the process of establishing a PDU session, combined with Figure 2In step S201, the protocol stack of the terminal device generates a PDU session establishment request. After the physical layer processes the PDU session establishment request, it is sent to the AMF through the transceiver in the terminal device through the access network device to start the establishment of the PDU session. Then, through the interaction between the terminal device, the access network device and the various network elements of the core network device, the establishment of the PDU session is completed. Among them, the PDU session establishment request includes the S-NSSAI#1 determined and sent by the URSP module received by the protocol stack. For a detailed description of the PDU session establishment process, please refer to Figure 2 The relevant description will not be repeated here.

[0253] During the PDU session establishment process, for signaling transmitted through PUSCH, the GPU can be used to process the signaling through the target processing module. For signaling transmitted through PDSCH, the CPU can be used to process the signaling through the PDSCH processing module. The following is a specific description of the process of processing signaling transmitted through PUSCH and PDSCH through steps S8061 and S8062.

[0254] In step S8061, the protocol stack calls the GPU, and the GPU processes the signaling transmitted through the PUSCH during the PDU session establishment process through the target processing module.

[0255] Combine Figure 2 For example, the signaling transmitted via PUSCH during the PDU session establishment process may include: the PDU session establishment request (PDU session establishment request) in step S201, and the relevant information on the establishment of a resource connection between the terminal device (e.g., UE) and the access network device (e.g., gNB) in step S2083. Of course, the signaling transmitted via PUSCH during the PDU session establishment process may also include other Figure 2 For the signaling shown, please refer to the more specific PDU session establishment process in the prior art.

[0256] For the signaling transmitted through the PUSCH during the PDU session establishment process, after the high-level protocol stack of the protocol stack processes the signaling (processing the signaling in sequence through the SDAP layer, PDCP layer, RLC layer, and MAC layer), the GPU can be called through the high-level protocol stack or the physical layer. This embodiment of the present application does not impose any restrictions. In addition, after the GPU (or, the GPU and the CPU) completes the physical layer processing of the signaling, the CPU obtains the final processing result (i.e., the signaling after the complete processing at the physical layer), and finally the CPU controls the transceiver to send the processed signaling.

[0257] When the target processing module includes all PUSCH processing modules, the protocol stack calls the GPU. After the GPU processes the signaling through the target processing module, it feeds the final processing result (the signaling after complete physical layer processing) back to the CPU, so that the CPU controls the transceiver to transmit the processed signaling. In this case, the GPU performs complete physical layer processing on the signaling, and the GPU obtains the signaling after the physical layer processing is completed, that is, the final processing result, and feeds this final processing result back to the CPU.

[0258] When the target processing module includes part of the PUSCH processing module, the protocol stack calls the GPU, which processes the signaling through the target processing module. For other processing modules in the PUSCH other than the target processing module, the protocol stack calls the CPU (not shown in the figure), which processes the signaling through these other processing modules. The CPU obtains the final processing result (the signaling after complete physical layer processing), and ultimately controls the transceiver to transmit the processed signaling. In this case, the GPU performs part of the physical layer processing on the signaling, and the CPU performs another part of the physical layer processing on the signaling. Therefore, the CPU and GPU jointly perform complete physical layer processing on the signaling.

[0259] If the processing flow of some of the PUSCH processing modules included in the target processing module is discontinuous, for example, the previous processing module is processed by the GPU, the next processing module is processed by the CPU, and the next processing module is processed by the GPU, the GPU and the CPU mutually feed back the processing results of the current processing module so that the GPU or CPU processes the next processing module based on the fed-back processing results. For example, if the target processing module processed by the GPU includes a channel coding module, a rate matching module, and a scrambling module, then the CPU processes the remaining processing modules. The CPU first processes the signaling through the CRC insertion module and the code block segmentation module, and feeds back the obtained processing result #1 to the GPU. Based on the processing result #1, the GPU continues to process the signaling through the channel coding module, the rate matching module, and the scrambling module, and feeds back the obtained processing result #2 to the CPU. Based on the processing result #2, the CPU continues to process the signaling through the remaining processing modules to obtain the final processing result.

[0260] In the implementation, for example, the GPU is configured with interfaces of various processing modules for PUSCH and PDSCH. After the protocol stack determines the target processing module for PUSCH, the interface of each processing module in the target processing module is called to enable the GPU to run. In this way, the GPU is called by calling the interfaces of various processing modules configured in the GPU, and the signaling transmitted through the PUSCH is processed by the target processing module.

[0261] In step S8062, the protocol stack calls the CPU, so that the CPU processes the signaling transmitted through the PDSCH through the PDSCH processing module.

[0262] Combine Figure 2 For example, the signaling transmitted via PDSCH during the PDU session establishment process may include: the PDU session establishment response (PDU Session Establishment Accept) and AN specific resource setup in step S2082, and the relevant information of the resource connection established between the terminal device (e.g., UE) and the access network device (e.g., gNB) in step S2083. Of course, the signaling transmitted via PDSCH during the PDU session establishment process may also include other Figure 2 For the signaling shown, please refer to the more specific PDU session establishment process in the prior art.

[0263] In the implementation, the protocol stack receives the signaling transmitted through the PDSCH through the transceiver, the protocol stack calls the CPU, the CPU performs physical layer processing on the signaling transmitted through the PDSCH through the PDSCH processing module, and performs processing on the high-level protocol stack (processed by the MAC layer, RLC layer, PDCP layer and SDAP layer in sequence) on the processed signaling.

[0264] It should be understood that when the CPU processes the signaling through the PDSCH processing module, Figure 4b The signaling is processed in sequence through the resource block mapping module, antenna port mapping module, layer mapping module, demodulation module, descrambling module, rate matching module, channel decoding module, code block merging module, and CRC removal module.

[0265] In step S807, after the PDU session is established, the protocol stack generates slice service interface #1.

[0266] It should be noted that during the PDU session establishment process, after the terminal device receives the PDU session establishment response (PDU Session Establishment Accep) in step S2082, although there are various signaling interactions between the network sides, for the terminal device, after receiving the PDU session establishment response, it can be considered that the PDU session establishment is completed. After that, the above-mentioned business data can actually be transmitted.

[0267] It should be understood that slice service interface #1 corresponds to S-NSSAI #1, or that slice service interface #1 corresponds to network slice #1 identified by S-NSSAI #1, or that slice service interface #1 is generated based on S-NSSAI #1. It should also be understood that after slice service interface #1 is generated, it means that the slice channel of the network slice is established, but the service data cannot be transmitted through the slice channel. It is necessary to associate slice service interface #1 with the slice data interface #1 of the application layer (refer to the description of step S809 for details) so that the service data transmitted through slice data interface #1 can be transmitted through the slice channel of the corresponding slice service interface #1.

[0268] In step S808, the protocol stack sends slice service interface #1 to the URSP module.

[0269] Correspondingly, the URSP module receives slice service interface #1.

[0270] In step S809, the URSP module determines the corresponding slice data interface #1 according to the slice service interface #1.

[0271] The URSP module stores the correspondence between multiple slice service interfaces and multiple slice data interfaces (recorded as correspondence #3). After the URSP module receives the slice service interface #1, it determines the slice data interface #1 corresponding to the slice service interface #1 based on the correspondence #3.

[0272] In implementation, for example, the routing unit of the URSP module may determine the slice data interface #1 corresponding to the slice service interface #1 based on the correspondence #3. The correspondence #3 may be stored in the database unit.

[0273] It should be understood that the slice data interface is an interface of the application layer.

[0274] In step S810, the URSP module sends interface information to application #1, where the interface information is used to indicate slice data interface #1.

[0275] Correspondingly, application #1 receives the interface information.

[0276] After that, application #1 starts to transmit service data, including uplink service data and downlink service data. Specifically, application #1 uses the slice data interface #1 indicated by the interface information to transmit service data.

[0277] It should be understood that uplink service data is service data transmitted through the PUSCH, and downlink service data is service data transmitted through the PDSCH.

[0278] In step S811, the protocol stack receives uplink service data from application layer #1, the protocol stack calls the GPU, the GPU processes the uplink service data through the target processing module, the CPU obtains the final processing result (i.e., the uplink service data after complete processing at the physical layer), and finally the CPU controls the transceiver to send the processed uplink service data.

[0279] In the implementation, after the protocol stack receives the uplink service data, the high-level protocol stack of the protocol stack processes the uplink service data (processed in sequence by the SDAP layer, PDCP layer, RLC layer, and MAC layer), and the GPU can be called through the high-level protocol stack or the physical layer to enable the GPU to perform physical layer processing on the processed uplink service data. The embodiment of the present application does not impose any restrictions. In addition, after the GPU (or, the GPU and the CPU) completes the physical layer processing of the uplink service data, the CPU obtains the final processing result (i.e., the uplink service data after complete processing at the physical layer), and finally the CPU controls the transceiver to send the processed uplink service data.

[0280] Since the protocol stack has determined the target processing module for PUSCH to be processed by GPU in step S805, the protocol stack can directly call the GPU for uplink service data, so that the GPU processes the uplink service data through the target processing module.

[0281] When the target processing module includes all PUSCH processing modules, the protocol stack calls the GPU. After the GPU processes the uplink service data through the target processing module, it feeds the final processing result (the uplink service data after complete physical layer processing) back to the CPU, so that the CPU controls the transceiver to transmit the processed uplink service data. In this case, the GPU performs complete physical layer processing on the uplink service data. The GPU obtains the uplink service data after the physical layer processing is completed, that is, the final processing result, and feeds this final processing result back to the CPU.

[0282] When the target processing module includes a partial processing module for the PUSCH, the protocol stack calls the GPU, which processes the uplink service data through the target processing module. For other processing modules in the PUSCH other than the target processing module, the protocol stack calls the CPU (not shown in the figure), which processes the uplink service data through these other processing modules. The CPU obtains the final processing result (uplink service data after complete physical layer processing), and ultimately controls the transceiver to send the processed uplink service data. In this case, the GPU performs part of the physical layer processing on the uplink service data, and the CPU performs another part of the physical layer processing on the uplink service data. Therefore, the CPU and GPU jointly perform complete physical layer processing on the uplink service data.

[0283] If the processing flow of some PUSCH processing modules included in the target processing module is discontinuous, the GPU and CPU will mutually feedback the processing results of the current processing module, so that the GPU or CPU can process the next processing module based on the feedback processing results. For example, if the target processing module processed by the GPU includes a channel coding module, a rate matching module, and a scrambling module, then the CPU will process the remaining processing modules. The CPU will first process the uplink service data through the CRC insertion module and the code block segmentation module, and feedback the obtained processing result #1 to the GPU. Based on this processing result #1, the GPU will continue to process the uplink service data through the channel coding module, the rate matching module, and the scrambling module, and feedback the obtained processing result #2 to the CPU. Based on this processing result #2, the CPU will continue to process the uplink service data through the remaining processing modules to obtain the final processing result.

[0284] It should be understood that application #1 sends the uplink service data to the URSP module through the slice data interface #1, and the URSP module forwards the uplink service data to the protocol stack through the slice service interface #1 corresponding to the slice data interface #1. Thus, the protocol stack transmits the uplink service data through the slice channel of the slice service interface #1.

[0285] In step S812, the protocol stack receives downlink service data through the transceiver, and the protocol stack calls the CPU so that the CPU processes the downlink service data through the PDSCH processing module. After the protocol stack completely processes the downlink service data, the protocol stack sends the processed downlink service data to application #1 through the URSP module.

[0286] In implementation, after the CPU completes physical layer processing of the downlink service data through the PDSCH processing module, it then performs processing on the processed downlink service data at the higher-level protocol stack (i.e., sequentially through the MAC layer, RLC layer, PDCP layer, and SDAP layer). It can be understood that after the higher-level protocol stack completes processing of the downlink service data, it can be considered that the protocol stack has completed complete processing of the downlink service data. After the protocol stack completes complete processing of the downlink service data, the protocol stack sends the processed downlink service data to application #1 via the URSP module.

[0287] In addition, when the protocol stack sends the processed downlink service data to application #1 through the URSP module, the protocol stack sends the downlink service data to the URSP module through the slice service interface #1, and the URSP module forwards the downlink service data to application #1 through the slice data interface #1 corresponding to the slice service interface #1.

[0288] For a detailed description of the process in which the CPU processes downlink service data through the PDSCH processing module, reference may be made to the above description of the process in which the CPU processes signaling through the PDSCH processing module, which will not be repeated here.

[0289] It should be understood that the order of step S811 and step S812 is not based on the size of the label, and the order of transmission of uplink service data and downlink service data is based on the specific service. For example, step S811 may also be after step S812.

[0290] In the above embodiment, the terminal device determines the network slice #1 corresponding to the service identifier #1 based on the service identifier #1, and determines the target processing module of the PUSCH processed by the GPU based on the network slice #1. In this way, the GPU can be used to perform physical layer processing on the data (service data and signaling) transmitted through the PUSCH through the target processing module. Compared with using the CPU to process the data at the physical layer, using the GPU to process the data at the physical layer can significantly improve the processing speed and improve the real-time performance of the scenario of the network slice #1 corresponding to the service identifier #1.

[0291] Figure 9 This is an exemplary flow chart of a method 900 for network slicing communication provided by an embodiment of the present application. In method 900, the terminal device determines the target processing module for processing PDSCH using a GPU based on the S-NSSAI used to identify the network slice. The GPU processes data (service data and signaling) through the target processing module to achieve physical layer acceleration, improve processing speed, and meet the real-time requirements of the current network slicing scenario.

[0292] It should be understood that in method 900, for data (service data and signaling) transmitted via the PUSCH, the CPU is used to perform physical layer processing on the data in accordance with the prior art.

[0293] For detailed descriptions of steps S901 and S904, please refer to the relevant descriptions of steps S801 and S804 in method 800 and will not be repeated here. The only difference is that the service identifier #1 and S-NSSAI #1 in method 900 are not exactly the same as the application #1, service identifier #1, and S-NSSAI #1 in method 800.

[0294] It can be understood that the service #1 identified by the service identifier #1 and the network slice #1 identified by the S-NSSAI #1 of the method 900 are suitable for scenarios with high real-time requirements for PDSCH. For example, application #1 can be a video application (e.g., apps that can watch long videos) or audio apps (e.g. ), service #1 is a video service or an audio service, the service identifier #1 used to identify service #1 is used to identify the video service or the audio service, and the corresponding network slice #1 is applicable to the video service or the audio service.

[0295] In step S905 , the protocol stack determines a target processing module for PDSCH to be processed by GPU according to S-NSSAI#1.

[0296] After receiving S-NSSAI#1, the protocol stack determines that the GPU needs to be used to process PDSCH according to S-NSSAI#1, and determines the target processing module to be processed by GPU from multiple processing modules of PDSCH, so that the GPU can process the data (service data and signaling) transmitted through PDSCH to improve the processing speed. It should be understood that the multiple processing modules of PDSCH are all processing modules of PDSCH. For terminal devices, refer to Figure 4b The processing module shown.

[0297] The target processing module unit of PDSCH includes at least one processing module, which can be part of the multiple processing modules of PDSCH, or all the processing modules among the multiple processing modules, and is specifically related to the network slice #1 identified by S-NSSAI#1.

[0298] For example, if service #1 corresponding to network slice #1 is a high-definition live video service, the target processing module determined based on S-NSSAI #1 used to identify network slice #1 may be all processing modules of PDSCH. For another example, if service #1 corresponding to network slice #1 is a non-high-definition live video service, the target processing module determined based on S-NSSAI #1 used to identify network slice #1 may be some processing modules of PDSCH.

[0299] During implementation, the protocol stack matches S-NSSAI#1 with the corresponding relationship #2 (uplink and downlink) described above. Ultimately, the downlink corresponding relationship matches a set of processing modules corresponding to S-NSSAI#1. This set of processing modules is the target processing module for PDSCH using GPU processing corresponding to S-NSSAI#1. For a detailed description of the uplink corresponding relationship, please refer to the description of Table 2 above and will not be repeated here.

[0300] In step S906, the protocol stack initiates a PDU session according to S-NSSAI#1 and performs a PDU session establishment process.

[0301] For a detailed description of this step, please refer to the relevant description of step S806 in method 800, which will not be repeated here.

[0302] During the PDU session establishment process, for signaling transmitted through PUSCH, the CPU can be used to process the signaling through the PUSCH processing module. For signaling transmitted through PDSCH, the GPU can be used to process the signaling through the target processing module. The following is a specific description of the process of processing signaling transmitted through PUSCH and PDSCH through steps S9061 and S9062.

[0303] In step S9061, the protocol stack calls the CPU, so that the CPU processes the signaling transmitted through the PUSCH through the PUSCH processing module.

[0304] Regarding the signaling transmitted through PUSCH during the PDU session establishment process, please refer to the relevant description of step S8061 above and will not be repeated here.

[0305] In the implementation, for example, for the signaling transmitted through the PUSCH, after the high-level protocol stack of the protocol stack is processed (that is, after being processed in sequence by the SDAP layer, PDCP layer, RLC layer and MAC layer), the CPU can be called through the high-level protocol stack or the physical layer, and the CPU processes the signaling transmitted through the PUSCH through the PUSCH processing module, and finally the CPU controls the transceiver to send the processed signaling.

[0306] In step S9062, the protocol stack calls the GPU, and the GPU processes the signaling transmitted through the PDSCH during the PDU session establishment process through the target processing module.

[0307] Regarding the signaling transmitted through the PDSCH during the PDU session establishment process, please refer to the relevant description of step S8062 above and will not be repeated here.

[0308] In implementation, the protocol stack receives signaling transmitted via the PDSCH through the transceiver, and the protocol stack calls the GPU through the higher-level protocol stack or the physical layer, so that the GPU performs physical layer processing on the signaling transmitted via the PDSCH through the target processing module of the PDSCH, without any limitation here. In addition, after the GPU (or, the GPU and the CPU) completely processes the signaling at the physical layer, the CPU obtains the final processing result (i.e., the signaling after complete physical layer processing), so that the CPU performs processing on the processed signaling at the higher-level protocol stack based on the final processing result (i.e., processing through the MAC layer, RLC layer, PDCP layer, and SDAP layer in sequence).

[0309] When the target processing module includes all PDSCH processing modules, the protocol stack calls the GPU. After the GPU processes the signaling transmitted via the PDSCH through the target processing module, it feeds the final processing result (i.e., the signaling after complete physical layer processing) back to the CPU. The CPU then performs higher-level protocol stack processing on the processed signaling based on the final processing result. In this case, the GPU performs complete physical layer processing on the signaling, obtaining the signaling after complete physical layer processing, i.e., the final processing result, and feeds this final processing result back to the CPU.

[0310] When the target processing module includes a partial PDSCH processing module, the protocol stack calls the GPU. The GPU processes the signaling through the target processing module, while the CPU processes the signaling through other PDSCH processing modules other than the target processing module. The CPU obtains the final processing result (the signaling after complete physical layer processing). Ultimately, the CPU performs processing on the processed signaling in the higher-level protocol stack based on the final processing result. In this case, the GPU performs part of the physical layer processing on the signaling, and the CPU performs another part of the physical layer processing on the signaling. Therefore, the CPU and GPU jointly perform complete physical layer processing on the signaling.

[0311] If the processing flow of some PDSCH processing modules included in the target processing module is non-continuous, for example, the previous processing module is processed by the GPU, the next processing module is processed by the CPU, and the next processing module is processed by the GPU, the GPU and the CPU mutually feedback the processing results of the current processing module so that the GPU or CPU processes the next processing module based on the feedback processing results. For example, if the target processing module processed by the GPU includes a channel decoding module, a rate matching module, and a descrambling module, then the CPU processes the remaining processing modules. The CPU sequentially processes the signaling through the resource mapping module, the antenna port demapping module, the layer mapping module, and the demodulation module, and feeds back the obtained processing result #1 to the GPU. Based on the processing result #1, the GPU continues to process the signaling through the descrambling module, the rate matching module, and the channel decoding module, and feeds back the obtained processing result #2 to the CPU. Based on the processing result #2, the CPU continues to process the signaling through the code block merging module and the CRC removal module to obtain the final processing result.

[0312] As described above, in the implementation, exemplarily, the GPU is configured with interfaces of various processing modules for PUSCH and PDSCH. After the protocol stack determines the target processing module for PDSCH, the interface of each processing module in the target processing module is called to enable the GPU to run. In this way, the GPU is called by calling the interfaces of various processing modules configured in the GPU, and the signaling transmitted through the PDSCH is processed by the target processing module.

[0313] After the PDU session is established, steps S907 to S910 are executed. For detailed descriptions of steps S907 to S910, reference may be made to the relevant descriptions of steps S807 to S810 of method 800, which will not be repeated here.

[0314] In step S911, the protocol stack receives uplink service data from application layer #1, and the protocol stack calls the CPU so that the CPU processes the uplink service data through the PUSCH processing module, and the CPU controls the transceiver to send the processed uplink service data.

[0315] In implementation, after the protocol stack receives uplink service data, the CPU processes the uplink service data at the upper layers of the protocol stack (processing it sequentially through the SDAP layer, PDCP layer, RLC layer, and MAC layer). The CPU then performs physical layer processing on the uplink service data through the PUSCH processing module. Furthermore, after completing the physical layer processing of the uplink service data, the CPU ultimately controls the transceiver to transmit the processed uplink service data.

[0316] As mentioned above, application #1 sends the uplink service data to the URSP module through the slice data interface #1, and the URSP module forwards the uplink service data to the protocol stack through the slice service interface #1 corresponding to the slice data interface #1. Thus, the protocol stack transmits the uplink service data through the slice channel of the slice service interface #1.

[0317] In step S912, the protocol stack receives downlink service data through the transceiver, and the protocol stack calls the GPU. The GPU processes the downlink service data through the target processing module of PDSCH. After the protocol stack completes the complete processing of the downlink service data, the protocol stack sends the processed downlink service data to application #1 through the URSP module.

[0318] In the implementation, after receiving the downlink service data, the protocol stack can call the GPU through the high-level protocol stack or the physical layer, so that the GPU performs physical layer processing on the downlink service data through the target processing module of PDSCH. No limitation is made here. After the GPU (or, GPU and CPU) performs complete physical layer processing on the downlink service data, the CPU obtains the final processing result (i.e., the downlink service data after complete processing at the physical layer), and performs processing on the processed downlink service data in the high-level protocol stack (i.e., processing through the MAC layer, RLC layer, PDCP layer and SDAP layer in sequence). It can be understood that after the high-level protocol stack has processed the downlink service data, it can be considered that the protocol stack has completed the complete processing of the downlink service data. After the protocol stack completes the complete processing of the downlink service data, the protocol stack sends the processed downlink service data to application #1 through the URSP module.

[0319] In addition, when the protocol stack sends the processed downlink service data to application #1 through the URSP module, the protocol stack sends the downlink service data to the URSP module through the slice service interface #1, and the URSP module forwards the downlink service data to application #1 through the slice data interface #1 corresponding to the slice service interface #1.

[0320] Since the protocol stack has determined the target processing module for PDSCH to be processed by the GPU in step S905, the protocol stack can directly call the GPU for downlink service data, so that the GPU processes the downlink service data through the target processing module.

[0321] When the target processing module includes all PDSCH processing modules, the protocol stack calls the GPU. After the GPU processes the downlink service data through the target processing module, it feeds the final processing result (i.e., the downlink service data after complete physical layer processing) back to the CPU, so that the CPU can perform high-level protocol stack processing on the processed downlink service data based on the final processing result. In this case, the GPU performs complete physical layer processing on the downlink service data, and the GPU obtains the downlink service data after complete physical layer processing, i.e., the final processing result, and feeds this final processing result back to the CPU.

[0322] When the target processing module includes a partial PDSCH processing module, the protocol stack calls the GPU, which processes the downlink service data through the target processing module. For processing modules other than the target processing module in the PDSCH, the protocol stack calls the CPU, which processes the downlink service data through other processing modules. The CPU obtains the final processing result (downlink service data after complete physical layer processing). Ultimately, the CPU performs processing on the processed downlink service data set in the high-level protocol stack based on the final processing result. In this case, the GPU performs a portion of the physical layer processing on the downlink service data, and the CPU performs another portion of the physical layer processing on the downlink service data. Therefore, the CPU and GPU jointly perform complete physical layer processing on the downlink service data.

[0323] If the processing flow of some of the PDSCH processing modules included in the target processing module is discontinuous, for example, the previous processing module is processed by the GPU, the next processing module is processed by the CPU, and the next processing module is processed by the GPU, the GPU and the CPU mutually feedback the processing results of the current processing module so that the GPU or CPU processes the next processing module based on the feedback processing results. For example, if the target processing module processed by the GPU includes a channel decoding module, a rate matching module, and a descrambling module, then the CPU processes the remaining processing modules. The CPU sequentially processes the downlink service data through the resource demapping module, the antenna port demapping module, the layer demapping module, and the demodulation module, and feeds back the obtained processing result #1 to the GPU. Based on the processing result #1, the GPU continues to process the downlink service data through the descrambling module, the rate matching module, and the channel decoding module, and feeds back the obtained processing result #2 to the CPU. Based on the processing result #2, the CPU continues to process the downlink service data through the code block merging module and the CRC removal module to obtain the final processing result.

[0324] It should be understood that the order of step S911 and step S912 is not represented by the size of the label, and the order of transmission of uplink service data and downlink service data depends on the specific service. For example, step S911 may also be after step S912.

[0325] In the above embodiment, the terminal device determines the network slice #1 corresponding to the service identifier #1 based on the service identifier #1, and determines the target processing module of the PDSCH processed by the GPU based on the network slice #1. In this way, the GPU can be used to perform physical layer processing on the data (service data and signaling) transmitted through the PDSCH through the target processing module. Compared with using the CPU to process the data at the physical layer, using the GPU to process the data at the physical layer can significantly improve the processing speed and improve the real-time performance of the scenario of the network slice #1 corresponding to the service identifier #1.

[0326] Figure 10 This is an exemplary flow chart of a method 1000 for network slicing communication provided by an embodiment of the present application. In method 1000, the terminal device determines the target processing module for PUSCH and the target processing module for PDSCH processed by the GPU based on the S-NSSAI used to identify the network slice. The GPU processes uplink data (service data and signaling) and downlink data through the target processing module for PUSCH and the target processing module for PDSCH, respectively, to achieve physical layer acceleration, improve processing speed, and meet the real-time requirements of the current network slicing scenario.

[0327] For detailed descriptions of steps S1001 and S1004, please refer to the relevant descriptions of steps S801 and S804 in method 800 and will not be repeated here. The only difference is that the service identifier #1 and S-NSSAI #1 in method 1000 are not exactly the same as the application #1, service identifier #1, and S-NSSAI #1 in method 800.

[0328] It can be understood that the service #1 identified by the service identifier #1 and the network slice #1 identified by the S-NSSAI #1 of method 1000 are applicable to scenarios with high real-time requirements for both PDSCH and PUSCH. For example, application #1 may be a cloud gaming application, service #1 is a gaming service, and the service identifier #1 used to identify service #1 is used to identify the gaming service, and the corresponding network slice #1 is applicable to the gaming service.

[0329] In step S1005, the protocol stack determines the target processing module #1 for PUSCH and the target processing module #2 for PDSCH to be processed by GPU according to S-NSSAI #1.

[0330] In step S1006, the protocol stack initiates a PDU session based on S-NSSAI#1 and performs the PDU session establishment process. During the PDU session establishment process, the protocol stack calls the GPU, which processes the signaling transmitted via the PUSCH and PDSCH during the PDU session establishment process through target processing module #1 and target processing module #2, respectively.

[0331] In this step, the GPU processes the signaling transmitted through the PUSCH during the PDU session establishment process through the target processing module #1, and processes the signaling transmitted through the PDSCH during the PDU session establishment process through the target processing module #2.

[0332] Regarding the specific description of the process in which the protocol stack calls the GPU and the GPU processes the signaling transmitted via the PUSCH during the PDU session establishment process through target processing module #1, please refer to the relevant description of step S8061, which will not be repeated here. Regarding the specific description of the process in which the protocol stack calls the GPU and the GPU processes the signaling transmitted via the PDSCH during the PDU session establishment process through target processing module #2, please refer to the relevant description of step S9062, which will not be repeated here.

[0333] After the PDU session is established, steps S1007 to S1010 are executed. For the detailed description of steps S1007 to S1010, please refer to the relevant description of steps S807 to S810 of method 800, which will not be repeated here.

[0334] In step S1011, the protocol stack receives uplink service data from application layer #1, the protocol stack calls the GPU, the GPU processes the uplink service data through target processing module #1, the CPU obtains the final processing result (i.e., the uplink service data after complete processing at the physical layer), and finally the CPU controls the transceiver to send the processed uplink service data.

[0335] Since the protocol stack has determined the target processing module #1 for PUSCH to be processed by the GPU in step S1005, the protocol stack can directly call the GPU for uplink service data, so that the GPU processes the uplink service data through the target processing module #1.

[0336] For the detailed description of this step, please refer to the relevant description of step S811, which will not be repeated here.

[0337] In step S1012, the protocol stack receives downlink service data through the transceiver, and the protocol stack calls the GPU. The GPU processes the downlink service data through the PDSCH target processing module #2. After the protocol stack completes the processing of the downlink service data, the protocol stack sends the processed downlink service data to application #1 through the URSP module.

[0338] Since the protocol stack has determined the target processing module #2 for PDSCH to be processed by the GPU in step S1005, the protocol stack can directly call the GPU for downlink service data, so that the GPU processes the downlink service data through the target processing module #2.

[0339] For the detailed description of this step, please refer to the relevant description of step S912, which will not be repeated here.

[0340] It should be understood that the order of step S1011 and step S1012 is not indicated by the size of the numbers, and the order of transmission of uplink service data and downlink service data is based on the specific services. For example, step S1011 may also be after step S1012.

[0341] In the above embodiment, the terminal device determines the network slice #1 corresponding to the service identifier #1 based on the service identifier #1, and determines the target processing module #1 for PUSCH and the target processing module #2 for PDSCH to be processed by the GPU based on the network slice #1. In this way, the GPU can be used to perform physical layer processing on the data (service data and signaling) transmitted through the PUSCH through the target processing module #1, and the GPU can be used to perform physical layer processing on the data (service data and signaling) transmitted through the PDSCH through the target processing module #2. Compared with using the CPU to process the data at the physical layer, using the GPU to process the data at the physical layer can significantly increase the processing speed and improve the real-time performance of the scenario of the network slice #1 corresponding to the service identifier #1.

[0342] exist Figures 8 to 10 In an embodiment, the terminal device determines the target processing module for PUSCH and / or PDSCH to be processed by a coprocessor such as a GPU according to the network slice, and uses the coprocessor to perform physical layer processing on the data through the target processing module. Compared with using the CPU to process the data at the physical layer, using the coprocessor to process the data can significantly improve the processing speed and improve the real-time performance. In addition, the target processing module for PUSCH and / or PDSCH is determined according to the network slice, and different target processing modules to be processed by the coprocessor can be determined according to different network slices. This can prevent the indifferent scheduling of the computing resources of the coprocessor in different network slicing scenarios to cause waste of resources and power consumption, and can match the real-time requirements of different application scenarios, and can also improve the flexibility of the processing process.

[0343] In other massive IoT scenarios, such as data collection from IoT devices (e.g., smart meters and various sensors), terminal devices can also determine based on network slicing that no coprocessor is required to perform any physical layer processing on the data, and use the CPU to process the data at the physical layer. In this way, resources and power consumption can be saved to the maximum extent based on the needs of the network slicing scenario.

[0344] The following, combined Figure 11 The process of determining that a terminal device does not need to use a coprocessor to perform physical layer processing on data is briefly described. Similarly, the GPU is used as an example of a coprocessor for the purpose of explanation.

[0345] Figure 11It is an exemplary flowchart of the network slicing communication-based method 1100 provided in an embodiment of the present application.

[0346] For detailed descriptions of steps S1101 and S1104, please refer to the relevant descriptions of steps S801 and S804 in method 800 and will not be repeated here. The only difference is that the service identifier #1 and S-NSSAI #1 in method 1000 are not exactly the same as the application #1, service identifier #1, and S-NSSAI #1 in method 800.

[0347] It can be understood that the service #1 identified by the service identifier #1 and the network slice #1 identified by the S-NSSAI #1 in method 1100 are applicable to scenarios where the real-time requirements for both the PDSCH and PUSCH are not too high. For example, application #1 can be an application such as a smart meter, service #1 is a data collection service, and the service identifier #1 used to identify service #1 is used to identify the data collection service. The corresponding network slice #1 is applicable to the data collection service. Taking the data collection of a smart meter as an example, the data collection service not only has a relatively low real-time requirement for the service, but also has low power consumption.

[0348] In step S1105 , the protocol stack determines, based on S-NSSAI#1, not to use the GPU to perform physical layer processing on the data.

[0349] Since the network slice #1 identified by S-NSSAI#1 does not have high real-time performance for data, there is no need to use GPU to process the data at the physical layer to prevent waste of GPU resources and power consumption. Therefore, it is determined not to use GPU to process the data at the physical layer.

[0350] In the implementation, for example, the protocol stack matches S-NSSAI#1 with the correspondence #2 (uplink correspondence and downlink correspondence) mentioned above. If a group of processing modules corresponding to S-NSSAI#1 is not matched in the correspondence, it is determined that the GPU will not be used to process the data at the physical layer.

[0351] In step S1106, the protocol stack initiates a PDU session according to S-NSSAI#1 and performs a PDU session establishment process. During the PDU session establishment process, the protocol stack calls the CPU so that the CPU processes the signaling transmitted during the PDU session establishment process through the PUSCH and PDSCH processing modules.

[0352] It should be understood that the signaling transmitted during the PDU session establishment process refers to the signaling transmitted between the terminal device and the access network device through PUSCH and PDSCH. For specific descriptions, please refer to the relevant descriptions above and will not be repeated here.

[0353] It should also be understood that the CPU processes the signaling transmitted via the PUSCH during the PDU session establishment process through the PUSCH processing module, and the CPU processes the signaling transmitted via the PDSCH during the PDU session establishment process through the PDSCH processing module.

[0354] After the PDU session is established, steps S1107 to S1110 are executed. For the detailed description of steps S1107 to S1110, please refer to the relevant description of steps S807 to S810 of method 800, which will not be repeated here.

[0355] After step S1110 , the terminal device starts transmitting service data.

[0356] In step S1111, the protocol stack receives uplink service data from application layer #1, and the protocol stack calls the CPU so that the CPU processes the uplink service data through the PUSCH processing module, and the CPU controls the transceiver to send the processed uplink service data.

[0357] For the detailed description of this step, please refer to the relevant description of step S911 and will not be repeated here.

[0358] In step S1112, the protocol stack receives downlink service data through the transceiver, and the protocol stack calls the CPU so that the CPU processes the downlink service data through the PDSCH processing module. After the protocol stack completely processes the downlink service data, the protocol stack sends the processed downlink service data to application #1 through the URSP module.

[0359] For the detailed description of this step, please refer to the relevant description of step S812 and will not be repeated here.

[0360] In this embodiment, the terminal device determines the network slice #1 corresponding to the service identifier #1 based on the service identifier #1, and determines that the GPU does not need to be used to perform any physical layer processing on the data based on the network slice #1. In this way, only the CPU needs to be used to process the data at the physical layer, which can maximize resource savings and power consumption based on the requirements of the network slicing scenario.

[0361] Figure 12 This is an exemplary flow chart of a method 1200 for network slicing communication provided by an embodiment of the present application. Method 1200 only describes an embodiment in which a terminal device determines to process data through a coprocessor. For embodiments in which a coprocessor is not required to process data, reference can be made to the relevant description of method 1100, which will not be repeated here. In addition, a terminal device is used as an example as the execution subject of method 1200 to illustrate method 1200.

[0362] In step S1210, the terminal device generates a first service identifier in response to a user operation, where the first service identifier is used to identify a first service to be currently executed.

[0363] In this step, the user performs an operation on the terminal device, the terminal device detects the user operation, and generates a first service identifier based on a first service related to the user operation.

[0364] For example, the user can input user operations through the application module. The application module can be a client application or a browser application. There is no limitation on this. For specific examples of the application module, please refer to the example description of application #1 in each method above. The above application #1 can correspond to the application module here.

[0365] Exemplarily, the first service may be any service, for example, the first service may be various types of services such as a live broadcast service, a data backhaul service, a real-time monitoring service, a video service, an audio service, and a cloud gaming service.

[0366] For example, the first service identifier can be represented by at least one of APP ID, IP triplet information, FQDN, and DNN. For a detailed description, please refer to the description of service identifier #1 (corresponding to the first service identifier here) in step S802, which will not be repeated here.

[0367] It should be understood that the first service and the first service identifier exemplified above are merely illustrative and should not limit the embodiments of the present application.

[0368] In step S1220, the terminal device determines a first S-NSSAI corresponding to the first service identifier based on the first service identifier, and the first S-NSSAI is used to indicate a first network slice corresponding to the first service.

[0369] In this step, in some embodiments, the terminal device determines the first S-NSSAI based on the first service identifier from a second correspondence relationship indicating multiple service identifiers and multiple S-NSSAIs, wherein at least one service identifier corresponds to one S-NSSAI, one S-NSSAI is used to uniquely identify a network slice, and one service identifier is used to uniquely identify a service.

[0370] Exemplarily, the second corresponding relationship may be obtained from a network, or may be obtained from a general platform of the terminal device itself, and there is no limitation on this.

[0371] Due to the diversity of service transmission and network changes, in an embodiment where the second correspondence is obtained from the network, the terminal device can periodically obtain the second correspondence from the network to obtain the updated second correspondence as much as possible, thereby obtaining an S-NSSAI that accurately matches the current service.

[0372] In other embodiments, the terminal device may also determine the first S-NSSAI corresponding to the first service identifier in other ways, which is not limited in the embodiments of the present application.

[0373] In step S1230, the terminal device determines, based on the first S-NSSAI, a target processing module for the data channel to be processed by the coprocessor, where the target processing module includes at least some of all processing modules of the data channel.

[0374] It should be understood that at least part of the processing modules herein include all or part of all processing modules.The target processing module includes one or more processing modules of the data channel.

[0375] When the target processing module includes some of the processing modules among all the processing modules, it means that using some of the processing modules to process the data can already meet the real-time requirements, and there is no need to waste additional resources and power consumption to use the coprocessor to process the data through the remaining processing modules except for some of the processing modules. When the target processing module includes all the processing modules, it means that the first network slicing scenario of the first S-NSSAI has a very high real-time requirement, so the coprocessor is used to process the data through all the processing modules.

[0376] As mentioned above, a coprocessor is a processor developed and applied to assist the central processing unit to complete processing tasks that the central processing unit cannot perform or performs inefficiently or ineffectively. For example, the coprocessor can be any of the following processors: GPU, ISP, DSP, NPU, FPGA. It should be understood that the types of coprocessors mentioned here are only for illustrative purposes. Any processor that can assist the CPU in completing some processing tasks that require high execution efficiency and performance can be used as an example of a coprocessor.

[0377] In this step, based on the first S-NSSAI, the target processing module corresponding to the first S-NSSAI is determined. When data processing is performed subsequently, a coprocessor can be used to process the data through the target processing module. In this way, the speed of data processing can be improved to meet the real-time performance of the first network slice corresponding to the first S-NSSAI.

[0378] The processing modules of the data channel are processing modules of the physical layer, and each processing module is used to execute a step of the physical layer.

[0379] As previously mentioned, data channels include PUSCH and PDSCH. The target processing module determined corresponding to the first S-NSSAI may include a PUSCH processing module, a PDSCH processing module, or a PUSCH and PDSCH processing module. The following describes each case separately.

[0380] Case 1

[0381] The target processing module includes a first target processing module, and the first target processing module is a PUSCH processing module.

[0382] Among them, all processing modules of PUSCH can refer to Figure 5a Each module shown in the figure processes the data according to Figure 5a The first target processing module is part or all of the processing modules in all the processing modules of the PUSCH.

[0383] It can be understood that in this scenario 1, the first service (or the first network slice) is a scenario with high real-time requirements for uplink transmission, and a large amount of uplink data needs to be transmitted to the network. For example, the first service can be a live broadcast service, a data backhaul service, a real-time monitoring service, or other types of services.

[0384] In the case where the first target processing module is a part of all processing modules of PUSCH, illustratively, the first service may be a non-HD live service, a non-HD data backhaul service, or a non-HD real-time monitoring service.

[0385] In the case where the first target processing module is all processing modules of the PUSCH, illustratively, the first service may be a service such as a high-definition live broadcast service, a high-definition data backhaul service, or a high-definition real-time monitoring service.

[0386] Case 2

[0387] The target processing module includes a second target processing module, and the second target processing module is a PDSCH processing module.

[0388] Among them, all processing modules of PDSCH can refer to Figure 4b Each module shown in the figure processes the data according to Figure 4b The second target processing module is a part or all of the processing modules in all the processing modules of the PDSCH.

[0389] It can be understood that in this case 2, the first service (or the first network slice) is a scenario with high real-time requirements for downlink transmission, and a large amount of downlink data needs to be transmitted to the terminal device. For example, the first service can be a service such as a video service, an audio service, etc.

[0390] In the case where the second target processing module is a part of all PDSCH processing modules, illustratively, the first service may be a non-HD video service, a non-super quality (SQ) audio service, or the like.

[0391] In the case where the second target processing module is all processing modules of the PDSCH, illustratively, the first service may be a service such as a high-definition video service, an SQ audio service, or the like.

[0392] Case 3

[0393] The target processing module includes a first target processing module and a second target processing module. The first target processing module is a PUSCH processing module, and the second target processing module is a PDSCH processing module.

[0394] It can be understood that in this scenario 3, the first service (or the first network slice) is a scenario with high real-time requirements for both uplink and downlink transmissions, requiring the transmission of a large amount of uplink data to the network and the downloading of a large amount of downlink data to the terminal device. For example, the first service can be a service such as a cloud gaming service.

[0395] It should be noted that, when the first target processing module includes all processing modules of the PUSCH and the second target processing module includes all processing modules of the PDSCH, it is considered that the target processing module includes all processing modules of the data channel.

[0396] In step S1240, the terminal device uses the coprocessor to process the first data related to the first service through the target processing module.

[0397] The following describes the first data and the processing of the first data in combination with the three situations in step 1230.

[0398] Combined with situation 1

[0399] In case 1 where the target processing module includes the first target processing module, the first data includes signaling or uplink service data transmitted via PUSCH. The signaling transmitted via PUSCH may be signaling of a PDU session establishment process. For a detailed description, please refer to the relevant description above and will not be repeated here.

[0400] In a case where the first target processing module includes all processing modules of the PUSCH, the coprocessor is used to perform all physical layer processing on the first data through the target processing module.

[0401] When the first target processing module includes some PUSCH processing modules, the first data is processed not only by the coprocessor but also by the CPU. That is, the first data is processed by the coprocessor through the first target processing module, and the first data is processed by the CPU through all the PUSCH processing modules except the first target processing module, so as to perform complete physical layer processing on the first data.

[0402] If the processing flow of some of the PUSCH processing modules included in the first target processing module is discontinuous, for example, the previous processing module is processed by the coprocessor, the next processing module is processed by the CPU, and the next processing module is processed by the coprocessor, then the coprocessor and the CPU mutually feedback the processing result of the current processing module, so that the coprocessor or the CPU processes the next processing module based on the feedback processing result, thereby ultimately completing the complete processing of the first data at the physical layer. For the detailed description here, please refer to the relevant description of step S8061 and will not be repeated here.

[0403] It should be understood that after performing complete physical layer processing on the first data transmitted via the PUSCH, the terminal device may send the processed first data via the transceiver.

[0404] Combined with situation 2

[0405] In case 2 where the target processing module includes the second target processing module, the first data includes signaling or downlink service data transmitted via the PDSCH. The signaling transmitted via the PDSCH may be signaling for a PDU session establishment process. For a detailed description, reference may be made to the above related description and will not be repeated here.

[0406] In a case where the second target processing module includes all processing modules of the PDSCH, the coprocessor is used to perform all physical layer processing on the first data through the second target processing module.

[0407] When the second target processing module includes some PDSCH processing modules, the first data is processed not only by the coprocessor but also by the CPU. That is, the first data is processed by the coprocessor through the second target processing module, and the first data is processed by the CPU through all the PDSCH processing modules except the second target processing module, so as to perform complete physical layer processing on the first data.

[0408] If the processing flow of the partial processing modules of the PDSCH included in the second target processing module is discontinuous, for example, the previous processing module is processed by the coprocessor, the next processing module is processed by the CPU, and the next processing module is processed by the coprocessor, then the coprocessor and the CPU mutually feedback the processing result of the current processing module, so that the coprocessor or the CPU processes the next processing module based on the feedback processing result, thereby ultimately completing the complete processing of the first data at the physical layer. For the specific description here, please refer to the relevant description of step S9061, which is not repeated here.

[0409] It should be understood that after the first data transmitted via the PDSCH is completely processed at the physical layer, the terminal device performs high-level protocol stack processing on the processed first data (i.e., processing through the MAC layer, RLC layer, PDCP layer, and SDAP layer in sequence) to obtain the final processed first data.

[0410] Combined with situation 3

[0411] In scenario 3, in which the target processing module includes a first target processing module and a second target processing module, the first data includes signaling or downlink service data transmitted via a PUSCH, and the first data includes signaling or downlink service data transmitted via a PDSCH. The signaling transmitted via the PDSCH or PUSCH may be signaling for a PDU session establishment process. For a detailed description, reference may be made to the relevant description above and will not be repeated here.

[0412] It should be understood that in case 3, the coprocessor is used to process the signaling or uplink service data transmitted through PUSCH through the first target processing module, and the coprocessor is used to process the signaling or downlink service data transmitted through PDSCH through the second target processing module.

[0413] When the first target processing module includes all PUSCH processing modules, the coprocessor performs all physical layer processing on the first data through the first target processing module. When the first target processing module includes some PUSCH processing modules, the first data may be processed not only by the coprocessor but also by the CPU. For a detailed description, please refer to the description of step S8061 and will not be repeated here.

[0414] When the second target processing module includes all PDSCH processing modules, the coprocessor performs all physical layer processing on the first data through the second target processing module. When the second target processing module includes some PDSCH processing modules, the first data is processed not only by the coprocessor but also by the CPU. For a detailed description, please refer to the description of step S9061 and will not be repeated here.

[0415] In the method for network slicing communication provided by the embodiment of the present application, the terminal device determines the first S-NSSAI for indicating the first network slice based on the first service identifier, and determines the target processing module of the data channel processed by the coprocessor according to the first S-NSSAI. In this way, the coprocessor is used to process the data at the physical layer through the target processing module. Compared with the physical layer processing of the data by the CPU, the coprocessor is used to process the data, which can significantly improve the processing speed and improve the real-time performance. In addition, the target processing module of the data channel is determined according to the first S-NSSAI, and different target processing modules can be determined according to the S-NSSAI of different network slices. It can prevent the indifferent scheduling of the computing resources of the coprocessor in different network slicing scenarios to cause waste of resources and power consumption, and can match the real-time requirements of different application scenarios, and can also improve the flexibility of the processing process. Therefore, the embodiment of the present application generally realizes adaptive acceleration based on network slicing without causing waste of resources and power consumption, so as to meet the real-time requirements of different application scenarios.

[0416] Regarding the terminal device determining the target processing module in step S1230, in some embodiments, the process may be as follows:

[0417] The terminal device determines, based on the first S-NSSAI, a target processing module corresponding to the first S-NSSAI from a first correspondence relationship indicating multiple S-NSSAIs and multiple groups of processing modules, where each S-NSSAI corresponds to at least one group of processing modules.

[0418] It should be understood that the target processing module corresponding to the first S-NSSAI is at least one group of processing modules among the multiple groups of processing modules. After the terminal device determines the at least one group of processing modules corresponding to the first S-NSSAI from the first correspondence, it determines the at least one group of processing modules as the target processing module.

[0419] The above-mentioned first corresponding relationship may be obtained by the terminal device from the network, or may be pre-stored in the terminal device, and no limitation is made here.

[0420] In this way, by indicating the first correspondence between multiple S-NSSAIs and multiple groups of processing modules, the target processing module corresponding to the first S-NSSAI is determined, which can simplify the design and facilitate implementation.

[0421] In some embodiments, the first correspondence includes an uplink correspondence and a downlink correspondence. The uplink correspondence is used to indicate a one-to-one correspondence between M S-NSSAIs and M groups of processing modules, and the downlink correspondence is used to indicate a one-to-one correspondence between N S-NSSAIs and N groups of processing modules. Both M and N are integers greater than or equal to 1.

[0422] Here, M and N can be the same or different, without limitation, and are subject to specific implementation.

[0423] In this embodiment, the terminal device may match the first S-NSSAI with the uplink correspondence and the downlink correspondence respectively, so as to finally determine the target processing module corresponding to the first S-NSSAI.

[0424] Since the same S-NSSAI exists in the uplink correspondence relationship and the downlink correspondence relationship, one S-NSSAI may correspond to one group of processing modules or two groups of processing modules.

[0425] In an embodiment where an S-NSSAI corresponds to two groups of processing modules, one group of processing modules is a PUSCH processing module, and the other group of processing modules is a PDSCH processing module. For example, referring to Tables 1 and 2 above, S-NSSAI#A can correspond to a group of processing modules for PUSCH (including a channel coding module, a rate matching module, and a scrambling module), and can also correspond to a group of processing modules for PDSCH (including a channel decoding module and a rate matching module). Therefore, S-NSSAI#A corresponds to two groups of processing modules.

[0426] In one embodiment where the S-NSSAI corresponds to a set of processing modules, the set of processing modules is a PUSCH processing module or a PDSCH processing module. For example, referring to Tables 1 and 2 above, S-NSSAI#B corresponds only to the PUSCH processing module (including the channel coding module).

[0427] It should be understood that in this embodiment, since the first correspondence includes an upstream correspondence and a downstream correspondence, the determined target processing module can be any one of the three cases mentioned above, that is, the target processing module includes the first target processing module, the target processing module includes the second target processing module, and the target processing module includes the first target processing module and the second target processing module.

[0428] In other embodiments, the first correspondence relationship only includes the above-mentioned upstream correspondence relationship.

[0429] In this embodiment, the terminal device may match the first S-NSSAI with the uplink correspondence to determine the target processing module. It can be understood that in this embodiment, the device only allows accelerated processing of data transmitted via the PUSCH.

[0430] It should be understood that in this embodiment, since the first corresponding relationship only includes the upstream corresponding relationship, the determined target processing module includes the first target processing module.

[0431] In other embodiments, the first correspondence relationship only includes the above-mentioned downlink correspondence relationship.

[0432] In this embodiment, the terminal device may match the first S-NSSAI with the downlink corresponding relationship to determine the target processing module. It can be understood that in this embodiment, the device only allows accelerated processing of data transmitted via the PDSCH.

[0433] It should be understood that in this embodiment, since the first corresponding relationship only includes the downlink corresponding relationship, the determined target processing module includes the second target processing module.

[0434] The following describes the implementation method 1200 through the interaction between various modules in the terminal device. The terminal device includes an application module, a URSP module, and a protocol stack, wherein the application module can be any application program in the application layer.

[0435] In some embodiments, the application module generates a first service identifier in response to a user operation;

[0436] The application module sends the first service identifier to the URSP module;

[0437] The URSP module determines a first S-NSSAI according to the first service identifier;

[0438] The URSP module sends the first S-NSSAI to the protocol stack;

[0439] The protocol stack determines a target processing module according to the first S-NSSAI;

[0440] The protocol stack calls the coprocessor, and the coprocessor processes the first data through the target processing module.

[0441] In some embodiments, after the URSP module transmits the first S-NSSAI to the protocol stack, the method 1200 further includes:

[0442] The protocol stack establishes a PDU session with the network device based on the first S-NSSAI;

[0443] After the PDU session is established, the protocol stack generates a slice service interface corresponding to the first S-NSSAI;

[0444] The protocol stack sends service interface information indicating the slice service interface to the URSP module;

[0445] The URSP module determines the slice data interface corresponding to the slice service interface according to the slice service interface;

[0446] The URSP module sends data interface information indicating the slice data interface to the application module, so that the application module transmits service data through the slice data interface.

[0447] For the detailed description of the steps executed by each module, please refer to the relevant description above and will not be repeated here.

[0448] In some embodiments, reference Figure 6 The application module is configured in the application layer, the URSP module is configured in the application framework layer, and the protocol stack is configured in the modem. In this way, configuring the URSP module in the application framework layer to implement the URSP function does not involve modifying the modem's content, compared to configuring the URSP module in the modem. This can reduce the difficulty for developers to participate in the network slicing technology simulation of 5G terminals and increase the flexibility of implementing the URSP function.

[0449] In other embodiments, reference Figure 7 The application module is configured in the application layer, and the URSP module and protocol stack are both configured in the application layer. Thus, configuring the URSP module in the application layer to implement the URSP function does not involve modifying the contents of the operating system layer, compared to configuring the URSP module in the operating system. This reduces the difficulty for developers to participate in the network slicing technology simulation of 5G terminals and increases the flexibility of implementing the URSP function.

[0450] For example, continue to refer to Figure 7 The protocol stack is configured in the software-defined radio (SDR), and the URSP module is configured in the SDR. In this way, by integrating both the URSP module and the protocol stack in the SDR, multiple functional modules can be better integrated, memory usage can be reduced, and system management is facilitated.

[0451] It should be noted that the size of the serial numbers of the steps in the above method embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0452] Above, combined Figures 1 to 12, describes in detail the method based on network slicing communication provided by the embodiment of the present application, and will be combined with Figures 13 and 14 , describes in detail the network slicing communication-based device provided according to an embodiment of the present application.

[0453] Figure 13 1300 is an exemplary block diagram of an apparatus 1300 provided in an embodiment of the present application. The apparatus 1300 is a terminal device, or a chip in the terminal device.

[0454] The apparatus 1300 is used to execute the various processes and steps corresponding to the terminal device in the above method 1200. The apparatus 1300 includes: a processing unit 1310, which is used to execute the following steps:

[0455] In response to a user operation, generating a first service identifier, where the first service identifier is used to identify a first service to be currently executed;

[0456] Determine, according to the first service identifier, first network slice selection assistance information S-NSSAI corresponding to the first service identifier, where the first S-NSSAI is used to indicate a first network slice corresponding to the first service;

[0457] determining, based on the first S-NSSAI, target processing modules for a data channel to be processed by a coprocessor, the target processing modules including at least some of all processing modules for the data channel;

[0458] The coprocessor is used to process first data related to the first service through the target processing module.

[0459] Optionally, the apparatus 1300 includes an application module, a user routing policy (URSP) module, and a protocol stack; and the processing unit 1310 is specifically configured to:

[0460] Control the application module to generate the first service identifier in response to the user operation; and the processing unit 1310 is further specifically configured to:

[0461] Controlling the application module to send the first service identifier to the URSP module;

[0462] The processing unit 1310 is specifically configured to:

[0463] controlling the URSP module to determine the first S-NSSAI according to the first service identifier; and the processing unit 1310 is further configured to:

[0464] Control the URSP module to send the first S-NSSAI to the protocol stack;

[0465] The processing unit 1310 is specifically configured to:

[0466] controlling the protocol stack to determine the target processing module according to the first S-NSSAI;

[0467] The control protocol stack calls the coprocessor, and the coprocessor processes the first data through the target processing module.

[0468] Optionally, the processing unit 1310 is further configured to:

[0469] Controlling the protocol stack to establish a packet data unit (PDU) session with a network device according to the first S-NSSAI;

[0470] After the PDU session is established, controlling the protocol stack to generate a slice service interface corresponding to the first S-NSSAI;

[0471] Controlling the protocol stack to send service interface information indicating the slice service interface to the URSP module;

[0472] Controlling the URSP module to determine a slice data interface corresponding to the slice service interface according to the slice service interface;

[0473] Control the URSP module to send data interface information indicating the slice data interface to the application module, so that the application module transmits service data through the slice data interface.

[0474] Optionally, the application module is configured in the application layer, the URSP module is configured in the application framework layer, and the protocol stack is configured in the modem.

[0475] Optionally, the application module is configured in an application layer, and the URSP module and the protocol stack are both configured in the application layer.

[0476] Optionally, the protocol stack is configured in a software defined radio (SDR), and the URSP module is configured in the SDR.

[0477] Optionally, the processing unit 1310 is specifically configured to:

[0478] According to the first S-NSSAI, the target processing module corresponding to the first S-NSSAI is determined from a first correspondence relationship indicating multiple S-NSSAIs and multiple groups of processing modules, and one S-NSSAI corresponds to at least one group of processing modules.

[0479] Optionally, the first correspondence includes an uplink correspondence and a downlink correspondence, wherein the uplink correspondence is used to indicate a one-to-one correspondence between M S-NSSAIs and M groups of processing modules, and the downlink correspondence is used to indicate a one-to-one correspondence between N S-NSSAIs and N groups of processing modules, and M and N are both integers greater than or equal to 1.

[0480] Optionally, the processing unit 1310 is specifically configured to:

[0481] The first S-NSSAI is determined according to the first service identifier from a second correspondence relationship indicating multiple service identifiers and multiple S-NSSAIs, where at least one service identifier corresponds to one S-NSSAI.

[0482] Optionally, the target processing module includes a first target processing module, the first target processing module is a processing module for a physical uplink shared channel PUSCH, and the first data includes signaling or uplink service data transmitted through the PUSCH.

[0483] Optionally, the target processing module includes a second target processing module, the second target processing module is a processing module for a physical downlink shared channel PDSCH, and the first data includes signaling or downlink service data transmitted through the PDSCH.

[0484] Optionally, the target processing module includes a first target processing module and a second target processing module, the first target processing module is a processing module for the physical uplink shared channel PUSCH, the second target processing module is a processing module for the physical downlink shared channel PDSCH, the first data includes signaling or uplink service data transmitted through the PUSCH, and the first data includes signaling or downlink service data transmitted through the PDSCH.

[0485] Optionally, the coprocessor is any one of the following processors: a graphics processing unit GPU, an image signal processor ISP, a digital signal processor DSP, a neural network processor NPU, or a field programmable gate array FPGA.

[0486] It should be understood that the processing unit 1310 can be used to execute each step performed by the terminal device in the method 1200. For specific descriptions, please refer to the relevant descriptions above and will not be repeated here.

[0487] In the embodiments of this application, Figure 13 The intermediate device may also be a chip or a chip system, such as a system on chip (SoC).

[0488] Figure 1414 is a schematic structural diagram of an apparatus 1400 provided in an embodiment of the present application. Apparatus 1400 is used to execute the corresponding steps and / or processes in the above method embodiments.

[0489] Device 1400 includes a processor 1410, a transceiver 1420, and a memory 1430. The processor 1410, transceiver 1420, and memory 1430 communicate with each other via internal connection paths, and the processor 1410 can implement the functions of the processor 1410 in various possible implementations of device 1400. The memory 1430 is used to store instructions, and the processor 1410 is used to execute the instructions stored in the memory 1430. In other words, the processor 1410 can call these stored instructions to implement the functions of the processor 1410 in device 1400.

[0490] Optionally, the memory 1430 may include a read-only memory and a random access memory, and provide instructions and data to the processor. A portion of the memory may also include a non-volatile random access memory. For example, the memory may also store device type information. The processor 1410 may be configured to execute instructions stored in the memory. When the processor 1410 executes the instructions stored in the memory, the processor 1410 is configured to perform the various steps and / or processes of the aforementioned method embodiments corresponding to the network device or terminal device.

[0491] The apparatus 1400 is configured to execute the processes and steps corresponding to the terminal device in the above method 1200. The processor 1410 is configured to execute the following steps:

[0492] In response to a user operation, generating a first service identifier, where the first service identifier is used to identify a first service to be currently executed;

[0493] Determine, according to the first service identifier, first network slice selection assistance information S-NSSAI corresponding to the first service identifier, where the first S-NSSAI is used to indicate a first network slice corresponding to the first service;

[0494] determining, based on the first S-NSSAI, target processing modules for a data channel to be processed by a coprocessor, the target processing modules including at least some of all processing modules for the data channel;

[0495] The coprocessor is used to process first data related to the first service through the target processing module.

[0496] Optionally, the apparatus 1400 includes an application module, a user routing policy (URSP) module, and a protocol stack; and the processor 1410 is specifically configured to:

[0497] controlling the application module to generate the first service identifier in response to the user operation; and the processor 1410 is further configured to:

[0498] Controlling the application module to send the first service identifier to the URSP module;

[0499] The processor 1410 is specifically configured to:

[0500] controlling the URSP module to determine the first S-NSSAI according to the first service identifier; and the processor 1410 is further configured to:

[0501] Control the URSP module to send the first S-NSSAI to the protocol stack;

[0502] The processor 1410 is specifically configured to:

[0503] controlling the protocol stack to determine the target processing module according to the first S-NSSAI;

[0504] The control protocol stack calls the coprocessor, and the coprocessor processes the first data through the target processing module.

[0505] Optionally, the processor 1410 is further configured to:

[0506] Controlling the protocol stack to establish a packet data unit (PDU) session with a network device according to the first S-NSSAI;

[0507] After the PDU session is established, controlling the protocol stack to generate a slice service interface corresponding to the first S-NSSAI;

[0508] Controlling the protocol stack to send service interface information indicating the slice service interface to the URSP module;

[0509] Controlling the URSP module to determine a slice data interface corresponding to the slice service interface according to the slice service interface;

[0510] Control the URSP module to send data interface information indicating the slice data interface to the application module, so that the application module transmits service data through the slice data interface.

[0511] Optionally, the application module is configured in the application layer, the URSP module is configured in the application framework layer, and the protocol stack is configured in the modem.

[0512] Optionally, the application module is configured in an application layer, and the URSP module and the protocol stack are both configured in the application layer.

[0513] Optionally, the protocol stack is configured in a software defined radio (SDR), and the URSP module is configured in the SDR.

[0514] Optionally, the processor 1410 is specifically configured to:

[0515] According to the first S-NSSAI, the target processing module corresponding to the first S-NSSAI is determined from a first correspondence relationship indicating multiple S-NSSAIs and multiple groups of processing modules, and one S-NSSAI corresponds to at least one group of processing modules.

[0516] Optionally, the first correspondence includes an uplink correspondence and a downlink correspondence, wherein the uplink correspondence is used to indicate a one-to-one correspondence between M S-NSSAIs and M groups of processing modules, and the downlink correspondence is used to indicate a one-to-one correspondence between N S-NSSAIs and N groups of processing modules, and M and N are both integers greater than or equal to 1.

[0517] Optionally, the processor 1410 is specifically configured to:

[0518] The first S-NSSAI is determined according to the first service identifier from a second correspondence relationship indicating multiple service identifiers and multiple S-NSSAIs, where at least one service identifier corresponds to one S-NSSAI.

[0519] Optionally, the target processing module includes a first target processing module, the first target processing module is a processing module for a physical uplink shared channel PUSCH, and the first data includes signaling or uplink service data transmitted through the PUSCH.

[0520] Optionally, the target processing module includes a second target processing module, the second target processing module is a processing module for a physical downlink shared channel PDSCH, and the first data includes signaling or downlink service data transmitted through the PDSCH.

[0521] Optionally, the target processing module includes a first target processing module and a second target processing module, the first target processing module is a processing module for the physical uplink shared channel PUSCH, the second target processing module is a processing module for the physical downlink shared channel PDSCH, the first data includes signaling or uplink service data transmitted through the PUSCH, and the first data includes signaling or downlink service data transmitted through the PDSCH.

[0522] Optionally, the coprocessor is any one of the following processors: a graphics processing unit GPU, an image signal processor ISP, a digital signal processor DSP, a neural network processor NPU, or a field programmable gate array FPGA.

[0523] It should be understood that the specific process of each device executing the corresponding steps in the above methods has been described in detail in the above method embodiments, and for the sake of brevity, it will not be repeated here.

[0524] It should be understood that in the embodiments of the present application, the processor of the above-mentioned device may be a central processing unit (CPU), and the processor may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0525] During implementation, each step of the above method can be completed by an integrated logic circuit of hardware in a processor or by instructions in the form of software. The steps of the method disclosed in conjunction with the embodiments of the present application can be directly embodied as being executed by a hardware processor, or can be executed by a combination of hardware and software units in the processor. The software unit can be located in a storage medium mature in the art, such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. The storage medium is located in a memory, and the processor executes the instructions in the memory, and in combination with its hardware, completes the steps of the above method. To avoid repetition, a detailed description is not given here.

[0526] The present application provides a computer program product that, when executed on a terminal device, enables the terminal device to execute the technical solution in the above embodiment. The implementation principle and technical effects are similar to those of the above method-related embodiments and will not be described in detail here.

[0527] The embodiment of the present application provides a readable storage medium, which contains instructions. When the instructions are executed on a terminal device, the terminal device executes the technical solution of the above embodiment. The implementation principle and technical effect are similar and will not be repeated here.

[0528] The present application provides a chip for executing instructions. When the chip is running, the technical solution of the above embodiment is executed. The implementation principle and technical effect are similar and will not be described here.

[0529] In the above embodiments, all or part of the embodiments may be implemented by software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments may be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may 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 may 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 may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated therein. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a high-density digital video disc (DVD)), or a semiconductor medium (eg, a solid state disk (SSD)).

[0530] It should be understood that the “embodiment” mentioned throughout the specification means that the specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, the various embodiments in the entire specification do not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It should be understood that in the various embodiments of the present application, the size of the sequence number of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application.

[0531] It should also be understood that in this application, "when", "if" and "if" all mean that the UE or base station will take corresponding measures under certain objective circumstances. It does not limit the time, and does not require the UE or base station to take judgment actions when implementing it, nor does it mean that there are other limitations.

[0532] Those skilled in the art will understand that the various numerical numbers such as first and second involved in this application are only for the convenience of description and are not used to limit the scope of the embodiments of this application, and also indicate the order of precedence.

[0533] In this application, elements expressed in the singular are intended to mean "one or more" rather than "one and only one" unless otherwise specified. In this application, unless otherwise specified, "at least one" is intended to mean "one or more" and "a plurality" is intended to mean "two or more."

[0534] The term "and / or" in this article is merely a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. A can be singular or plural, and B can be singular or plural.

[0535] In this document, the term "at least one of..." or "at least one of..." means all or any combination of the listed items. For example, "at least one of A, B and C" may mean: A exists alone, B exists alone, C exists alone, A and B exist at the same time, B and C exist at the same time, and A, B and C exist at the same time. A may be singular or plural, B may be singular or plural, and C may be singular or plural.

[0536] 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.

[0537] 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.

[0538] 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.

[0539] 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.

[0540] 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.

[0541] 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.

[0542] The same or similar parts between the various embodiments in this application can refer to each other. In the various embodiments in this application, and the various implementation methods / implementation methods / implementation methods in each embodiment, if there is no special explanation and logical conflict, the terms and / or descriptions between different embodiments and the various implementation methods / implementation methods / implementation methods in each embodiment are consistent and can be referenced to each other. The technical features in different embodiments and the various implementation methods / implementation methods / implementation methods in each embodiment can be combined to form new embodiments, implementation methods, implementation methods, or implementation methods according to their inherent logical relationships. The above-described implementation methods of this application do not constitute a limitation on the scope of protection of this application.

[0543] The above is only a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or replacements within the technical scope disclosed in the present application, which should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims. In short, the above is only a preferred embodiment of the technical solution of the present application, and is not used to limit the scope of protection of the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should be included in the scope of protection of the present application.

Claims

1. A method based on network slicing communication, applied to a terminal device, characterized in that: The method comprises: In response to a user operation, generating a first service identifier, where the first service identifier is used to identify a first service to be currently executed; Determine, according to the first service identifier, first network slice selection assistance information S-NSSAI corresponding to the first service identifier, where the first S-NSSAI is used to indicate a first network slice corresponding to the first service; determining, based on the first S-NSSAI, target processing modules for a data channel to be processed by a coprocessor, the target processing modules including at least some of all processing modules for the data channel; The coprocessor is used to process first data related to the first service through the target processing module.

2. The method according to claim 1, characterized in that The terminal device includes an application module, a user routing policy URSP module and a protocol stack; and, The generating of the first service identifier in response to the user operation includes: The application module generates the first service identifier in response to the user operation; and the method further includes: The application module sends the first service identifier to the URSP module; The determining, according to the first service identifier, a first S-NSSAI corresponding to the first service identifier includes: The URSP module determines the first S-NSSAI according to the first service identifier; and the method further includes: The URSP module sends the first S-NSSAI to the protocol stack; The determining, according to the first S-NSSAI, a target processing module for the data channel to be processed by the coprocessor includes: The protocol stack determines the target processing module according to the first S-NSSAI; The using the coprocessor to process the first data related to the first service through the target processing module includes: The protocol stack calls the coprocessor, and the coprocessor processes the first data through the target processing module.

3. The method according to claim 2, characterized in that After the URSP module sends the first S-NSSAI to the protocol stack, the method further includes: The protocol stack establishes a packet data unit (PDU) session with the network device according to the first S-NSSAI; After the PDU session is established, the protocol stack generates a slice service interface corresponding to the first S-NSSAI; The protocol stack sends service interface information indicating the slice service interface to the URSP module; The URSP module determines, according to the slice service interface, a slice data interface corresponding to the slice service interface; The URSP module sends data interface information indicating the slice data interface to the application module, so that the application module transmits service data through the slice data interface.

4. The method according to claim 2 or 3, characterized in that The application module is configured in the application layer, the URSP module is configured in the application framework layer, and the protocol stack is configured in the modem.

5. The method according to claim 2 or 3, characterized in that The application module is configured in the application layer, and the URSP module and the protocol stack are both configured in the application layer.

6. The method according to claim 5, characterized in that The protocol stack is configured in a software defined radio (SDR), and the URSP module is configured in the SDR.

7. The method according to any one of claims 1 to 6, characterized in that The determining, according to the first S-NSSAI, a target processing module for the data channel to be processed by the coprocessor includes: According to the first S-NSSAI, the target processing module corresponding to the first S-NSSAI is determined from a first correspondence relationship indicating multiple S-NSSAIs and multiple groups of processing modules, and one S-NSSAI corresponds to at least one group of processing modules.

8. The method according to claim 7, characterized in that The first correspondence includes an uplink correspondence and a downlink correspondence, wherein the uplink correspondence is used to indicate a one-to-one correspondence between M S-NSSAIs and M groups of processing modules, and the downlink correspondence is used to indicate a one-to-one correspondence between N S-NSSAIs and N groups of processing modules, where M and N are both integers greater than or equal to 1.

9. The method according to any one of claims 1 to 8, characterized in that The determining, according to the first service identifier, a first S-NSSAI corresponding to the first service identifier includes: The first S-NSSAI is determined according to the first service identifier from a second correspondence relationship indicating multiple service identifiers and multiple S-NSSAIs, where at least one service identifier corresponds to one S-NSSAI.

10. The method according to any one of claims 1 to 9, characterized in that The target processing module includes a first target processing module, which is a processing module for a physical uplink shared channel (PUSCH). The first data includes signaling or uplink service data transmitted through the PUSCH.

11. The method according to any one of claims 1 to 9, characterized in that The target processing module includes a second target processing module, the second target processing module is a processing module for a physical downlink shared channel PDSCH, and the first data includes signaling or downlink service data transmitted through the PDSCH.

12. The method according to any one of claims 1 to 9, characterized in that The target processing module includes a first target processing module and a second target processing module, the first target processing module is a processing module for the physical uplink shared channel PUSCH, the second target processing module is a processing module for the physical downlink shared channel PDSCH, the first data includes signaling or uplink service data transmitted through the PUSCH, and the first data includes signaling or downlink service data transmitted through the PDSCH.

13. The method according to any one of claims 1 to 12, characterized in that The coprocessor is any one of the following processors: a graphics processor GPU, an image signal processor ISP, a digital signal processor DSP, a neural network processor NPU, and a field programmable gate array FPGA.

14. A terminal device, characterized in that: include: Memory, for storing computer instructions; A processor, configured to call the computer instructions stored in the memory to execute the method according to any one of claims 1 to 13.

15. A computer-readable storage medium, characterized in that Used to store computer instructions, wherein the computer instructions are used to implement the method according to any one of claims 1 to 13.

16. A chip, characterized in that: The chip includes: Memory: used to store instructions; A processor is used to call and execute the instructions from the memory so that a terminal device equipped with the chip system executes the method as described in any one of claims 1 to 13.

Images