Method for new type of data transmission in wireless network

Abstract

The present disclosure relates generally to wireless communication networks, and more particularly to network architecture for implementing novel data transmission or communication (e.g., semantic communication) for information with transmission fault tolerance. Specifically, several aspects in wireless network architecture and signaling are disclosed to implement novel data transmission between a wireless terminal and a wireless network. Modifications to a conventional wireless system are implemented to accommodate a source encoder / decoder model and its management, as well as activation / deactivation of the source encoder / decoder model based on model performance and network channel conditions. Data within such novel data communication can be divided into error-free data and fault-tolerant data, which are processed by the modified wireless network, respectively.

Description

Technical Field

[0001] This disclosure generally relates to wireless communication networks, and more specifically to network architectures for implementing novel data transmission or communication in wireless communication networks. Background Technology

[0002] Traditional wireless communication systems are suited for faithfully transmitting source information in the form of a set of physical bits or symbols through various network protocol layers, error correction mechanisms, and transmission and retransmission schemes. For some source information, faithful transmission may not be necessary. A novel data transmission or communication method can be employed to transmit this fault-tolerant information. For example, such novel data transmission can be implemented to deliver this type of source information semantically. Summary of the Invention

[0003] This disclosure generally relates to wireless communication networks, and more particularly to network architectures for enabling novel data transmission or communication (e.g., semantic communication) for information with transmission fault tolerance. Specifically, several aspects of wireless network architecture and signaling are disclosed to enable novel data transmission between wireless terminals and the wireless network. Modifications to conventional wireless systems are implemented to accommodate source encoder / decoder models and their management, as well as the activation / deactivation of the source encoder / decoder model based on model performance and network channel conditions. Data within this type of novel data communication can be divided into error-free data and fault-tolerant data, which are processed separately by the modified wireless network.

[0004] In some example implementations, a method executed by a wireless terminal is disclosed for establishing and controlling a service data stream between the wireless terminal and a network node in a wireless network. The method may include: transmitting a request for the service data stream to the network node, the request including at least a service type indicator indicating whether the service data stream is error-free or fault-tolerant; receiving a response and service data stream configuration from the network node; and establishing the service data stream with the wireless network according to the service data stream configuration.

[0005] In some other example implementations, a method performed by a wireless network node is disclosed for establishing and controlling a service data stream between a wireless terminal and the wireless network node in a wireless network. The method may include: receiving a request for a service data stream from the wireless terminal, the request including at least a service type indicator indicating whether the service data stream is error-free or fault-tolerant; generating and sending a response and service data stream configuration to the wireless terminal in response to the request; and establishing a service data stream with the wireless terminal according to the service data stream configuration.

[0006] In the above example implementation, the method may further include: establishing a first sub-communication stream and a second sub-communication stream of the service data stream according to the service data stream configuration, wherein the first sub-communication stream and the second sub-communication stream correspond to error-free data transmission and fault-tolerant data transmission, respectively; receiving a data service stream through one of the first sub-communication stream and the second sub-communication stream; receiving a handover request from a network node for switching the data service stream to another sub-communication stream in the first sub-communication stream and the second sub-communication stream; transmitting confirmation information of the handover request to the wireless terminal; and enabling the wireless terminal to switch the data service stream to another sub-communication stream in the first sub-communication stream and the second sub-communication stream.

[0007] In any of the above example implementations, the request further includes at least one of the following: a quantization indicator for indicating a scenario in which a service data stream of the requested service type indicated by the service type indicator is permitted; or a quality of service (QoS) indicator for indicating the QoS requirements of the service data stream.

[0008] In any of the above example implementations, the quantization indicator includes at least one of the following: signal-to-noise ratio (SINR) value, reference signal received quality (RSRQ) value, reference signal received power (RSRP) value, or transmission failure rate value.

[0009] In any of the above example implementations, the response and service data flow configuration includes at least one of the following: an acknowledgment (ACK) or a negative acknowledgment (NACK) for a request for the service data flow; an identifier for the service data flow; or a quantization configuration for indicating scenarios in which fault-tolerant transmission of the service data flow is allowed or enabled.

[0010] In any of the above example implementations, the quantization configuration includes at least one of the SINR value, RSRQ value, RSRP value, or transmission failure rate value.

[0011] In any of the above example implementations, the network node includes the core network node of the wireless network, and the requests and responses are carried by NAS signaling that is transparent to the radio access network (RAN) connecting the wireless terminal and the core network node.

[0012] In any of the above example implementations, the network node includes a RAN node, and requests and responses are carried by RRC signaling, PDCP control PDU, RLC control PDU, MAC CE, or physical layer control signaling.

[0013] In any of the above example embodiments, the method may further include: establishing a first sub-communication stream and a second sub-communication stream of the service data stream according to the service data stream configuration, wherein the first sub-communication stream and the second sub-communication stream correspond to error-free data transmission and fault-tolerant data transmission, respectively; transmitting a data service stream through one of the first sub-communication stream and the second sub-communication stream; sending a handover request to a network node for switching the data service stream to another sub-communication stream in the first sub-communication stream and the second sub-communication stream; receiving confirmation of the handover request from the network node; and switching the data service stream to another sub-communication stream in the first sub-communication stream and the second sub-communication stream.

[0014] In any of the above example implementations, each of the first sub-communication stream and the second sub-communication stream includes a PDU session.

[0015] In any of the above example implementations, each of the first sub-communication flow and the second sub-communication flow includes a QoS flow.

[0016] In any of the above example implementations, each of the first sub-communication flow and the second sub-communication flow includes a QoS sub-flow.

[0017] A wireless terminal or wireless network node that discloses any of the methods described above. The wireless terminal or network node may include a processor and a memory, wherein the processor is configured to read computer code from the memory to cause the wireless terminal or wireless network node to execute any of the methods described above.

[0018] A non-transitory computer-readable program medium storing computer code is also disclosed. When the processor of a wireless terminal or wireless network node of any of the above methods executes the computer code, the computer code is configured to cause the processor to implement any of the methods described above.

[0019] The above embodiments and other aspects and alternatives to their implementation are described in more detail in the following drawings, description and claims. Attached Figure Description

[0020] Figure 1 An example wireless communication network is shown, including a wireless access network, a core network, and a data network.

[0021] Figure 2 An example radio access network is shown, comprising multiple mobile stations / terminals or user equipment (UE) communicating with each other via an over-the-air wireless communication interface, as well as radio access network nodes.

[0022] Figure 3 An example Radio Access Network (RAN) architecture is shown.

[0023] Figure 4 An example communication protocol stack is shown in a wireless access network node or wireless terminal device that includes various network layers.

[0024] Figure 5 An example architecture for wireless semantic communication is shown.

[0025] Figure 6 Another example architecture for wireless semantic communication is shown.

[0026] Figure 7 An example process for configuring and managing a semantic model for wireless semantic communication is shown.

[0027] Figure 8 Another example process for configuring and managing a semantic model for wireless semantic communication is shown.

[0028] Figure 9 Another example architecture for wireless semantic communication is shown.

[0029] Figure 10 Another example process for configuring and managing a semantic model for wireless semantic communication is shown.

[0030] Figure 11 Another example process for configuring and managing a semantic model for wireless semantic communication is shown.

[0031] Figure 12 An example procedure for data flow control for semantic communication is shown.

[0032] Figure 13 Another example process for data flow control used in semantic communication is shown.

[0033] Figure 14 An example process for uplink and downlink semantic transmission is shown.

[0034] Figure 15 An example protocol header configuration is shown.

[0035] Figure 16 An example Media Access Control (MAC) Protocol Data Unit (PDU) for semantic configuration is shown.

[0036] Figure 17 An example of switching between semantic communication and traditional communication controlled by the network side is shown.

[0037] Figure 18 An example of switching between semantic communication and traditional communication controlled by the terminal side is shown. Detailed Implementation

[0038] This disclosure will now be described in detail with reference to the accompanying drawings, which form a part of this disclosure and illustrate specific examples of embodiments by way of illustration. However, this disclosure may be implemented in a variety of different forms, and therefore, the subject matter covered or claimed is intended to be construed as not being limited to any of the embodiments set forth below.

[0039] Throughout the specification and claims, terms may have subtly different meanings in the context, beyond their expressly stated meanings. Similarly, the phrases “in one embodiment” or “in some embodiments” as used herein do not necessarily refer to the same embodiment, and the phrases “in another embodiment” or “in other embodiments” as used herein do not necessarily refer to different embodiments. For example, the claimed subject matter is intended to encompass, in whole or in part, exemplary embodiments or combinations of embodiments.

[0040] Generally, terms can be understood at least in part from their use in context. For example, terms used herein, such as “and,” “or,” or “and / or,” can include a variety of meanings that can depend at least in part on the context in which they are used. Typically, “or,” when used in a list of associations (such as A, B, or C), is intended to mean A, B, and C (used here in an inclusive sense) and A, B, or C (used here in an exclusive sense). Furthermore, the terms “one or more” or “at least one,” as used herein, can be used, at least in part on context, to describe any feature, structure, or characteristic in a singular sense, or to describe a combination of features, structures, or characteristics in a plural sense. Similarly, terms such as “a,” “an,” or “the,” at least in part on context, can be understood to convey either a singular or a plural usage. Furthermore, the terms “based on” or “determined by” can be understood as not necessarily intended to convey an exclusive set of factors, but rather, at least in part, depending on the context, may allow for additional factors that are not necessarily explicitly described.

[0041] This disclosure generally relates to wireless communication networks, and more particularly to network architectures for enabling novel data transmission or communication (e.g., semantic communication) for information with transmission fault tolerance. Specifically, several aspects of wireless network architecture and signaling are disclosed to enable novel data transmission between wireless terminals and the wireless network. Modifications to conventional wireless systems are implemented to accommodate source encoder / decoder models and their management, as well as the activation / deactivation of the source encoder / decoder model based on model performance and network channel conditions. Data within this type of novel data communication can be divided into error-free data and fault-tolerant data, which are processed separately by the modified wireless network.

[0042] Overview of Traditional Wireless Networks like Figure 1 As shown in 100, the example wireless communication network may include wireless terminal equipment or user equipment (UE) 110, UE 111 and UE 112, operator network 102, various service applications 140, and other data networks 150. The wireless terminal equipment or UE may also be referred to as a wireless terminal. Operator network 102 may include, for example, access network nodes 120 and 121 and a core network 130. Operator network 110 may be configured to transmit voice, data, and other information (collectively referred to as data traffic) between UE 110, UE 111, and UE 112, between a UE and service application 140, or between a UE and other data networks 150. Access network nodes 120 and 121 may be configured as various wireless access network nodes (WANNs, alternatively referred to as wireless base stations) that interact with a UE on one side of a communication session and the core network 130 on the other side. The term "access network" can be more broadly used to refer to the combination of wireless terminal devices 110, 111, and 112 and access network nodes 120 and 121. The radio access network can also be alternatively referred to as the RAN (Radio Access Network). The core network 130 may include various network nodes configured to control communication sessions and perform network access management and traffic routing. Service applications 140 may be hosted by various application servers deployed outside the core network 130 but connected to it. Similarly, other data networks 150 may also be connected to the core network 130.

[0043] exist Figure 1In the example wireless communication network shown in 100, UEs can communicate with each other via a radio access network. For example, UE 110 and UE 112 can connect to and communicate via the same access network node 120. UEs can communicate with each other via both the access network and the core network. For example, UE 110 can connect to access network node 120, and UE 111 can connect to access network node 121, and thus, UE 110 and UE 111 can communicate with each other via access network nodes 120 and 121 and the core network 130. UEs can also communicate with service applications 140 and data networks 150 via the core network 130. Furthermore, as shown in 113, UEs can communicate directly with each other via sidelink communication.

[0044] Figure 2 A sample system diagram of a radio access network 120, including a WANN 202 serving UEs 110 and 112 via air interface 204, is further illustrated. Radio transmission resources for air interface 204 include a combination of frequency, time, and / or spatial resources. Each of UEs 110 and 112 can be a mobile or fixed terminal device equipped with a mobile access unit such as a SIM / USIM module for accessing the wireless communication network 100. Each of UEs 110 and 112 can be implemented as a terminal device including, but not limited to, mobile phones, smartphones, tablets, laptops, vehicle communication devices, roadside communication devices, sensor devices, smart appliances (such as televisions, refrigerators, and ovens), or other devices capable of wireless communication over a network. Figure 2 As shown, each of the UEs (such as UE 112) may include transceiver circuitry 206 coupled to one or more antennas 208 to enable wireless communication with WANN 120 or with another UE (such as UE 110). Transceiver circuitry 206 may also be coupled to processor 210, which may also be coupled to memory 212 or other storage devices. Memory 212 may be transient or non-transient and may store computer instructions or code therein that, when read and executed by processor 210, cause processor 210 to implement the various methods described herein.

[0045] Similarly, WANN 120 may include a wireless base station or other wireless network access point capable of wirelessly communicating with one or more UEs and with the core network 130 via air interface 204. For example, WANN 120 may be implemented as, but is not limited to, 2G base stations, 3G nodeBs, LTE eNBs, 4G LTE base stations, 5G NR base stations of 5G gNBs, 5G centralized unit base stations or 5G distributed unit base stations, 6G base stations, another type of conventional base station, or cell-free access point. Each type of WANN can be configured to perform a corresponding set of wireless network functions. WANN 202 may include transceiver circuitry 214 coupled to one or more antennas 216 (antennas 216 may include various forms of antenna towers 218) to enable wireless communication with UEs 110 and UE 112. Transceiver circuitry 214 may be coupled to one or more processors 220, which may also be coupled to memory 222 or other storage devices. The memory 222 may be transient or non-transient and may store instructions or code therein that, when read and executed by the processor 220, cause the processor 220 to perform the various functions, methods and processes of the WANN 120 described herein.

[0046] Such as Figure 2 In the example wireless access network described, data packets can be transmitted as Protocol Data Units (PDUs). This includes data that can be grouped into PDUs with nested and / or layered protocol headers at different network layers. Once a connection is established between the transmitting and receiving ends (e.g., a Radio Link Control (RRC) connection), PDUs can communicate between the transmitting device or transmitting end (these terms are used interchangeably) and the receiving device or receiving end (these terms are used interchangeably). Either the transmitting device or the receiving device can be, for example, a... Figure 2 The wireless terminal devices of devices 110 and 120 or such Figure 2 Node 202 is a wireless access network node. Each device can function as both a transmitter and receiver for bidirectional communication.

[0047] Figure 1 The core network 130 may include various geographically distributed and interconnected network nodes to provide network coverage for the service area of ​​the operator network 102. These network nodes may be implemented as dedicated hardware network nodes. Alternatively, these network nodes may be virtualized and implemented as virtual machines or software entities. Each of these network nodes may be configured with one or more types of network functions, which together provide configuration and routing capabilities for the core network 130.

[0048] Returning to the Radio Access Network (RAN). Figure 3 An example RAN 340 communicating with core network 310 and radio terminals UE1 through UE7 is shown. RAN 340 may include one or more radio base stations of various types (including but not limited to gNB, eNodeB, NodeB, or other types of base stations) or WANNs 320 and 321. RAN 340 may transmit back to core network 310. For example, WANN 320 may also include multiple independent access network nodes in the form of Central Unit (CU) 322 and one or more Distributed Unit (DU) 324 and 326. CU 322 is connected to DU1 324 and DU2 326 via various interfaces such as the F1 interface. For example, the F1 interface may also include an F1-C interface and an F1-U interface for transmitting control plane information and user plane data, respectively. In some embodiments, CU may be a gNB Central Unit (gNB-CU), and DU may be a gNB Distributed Unit (gNB-DU). Although the various implementations described below are provided in the context of 5G cellular wireless networks, the basic principles described herein are applicable to other types of wireless access networks, including but not limited to other generations of cellular networks, as well as Wi-Fi, Bluetooth, ZigBee, and WiMax networks.

[0049] The UE can connect to the network via the WANN 320 over the air interface. The UE can be served by at least one cell. Each cell is associated with a coverage area. These cells can also be referred to as serving cells. The coverage areas between cells can partially overlap. Each UE can be communicating with at least one cell and can potentially connect to or be able to connect to more than one cell. Figure 1 In the example, UE1, UE2, and UE3 can be served by cell 1 330 of DU1, while UE4 and UE5 can be served by cell 2 332 of DU1, and UE6 and UE7 can be served by cell 3 associated with DU2. In some implementations, a UE can be served by two or more cells simultaneously. Each of the UEs can be mobile, and the signaling strength and quality at the UE from each cell can depend on the UE's location and mobility.

[0050] In some example implementations, such as Figure 3The cells shown can be alternatively referred to as serving cells. Serving cells can be grouped into serving cell groups (CGs). A serving cell group can be a master CG (MCG) or a secondary CG (SCG). Within each type of cell group, there can be one master cell and one or more secondary cells. For example, the master cell in an MSG can be called a PCell, while the master cell in an SCG can be called a PScell. The secondary cells in either an MCG or an SCG can be called SCells. Master cells that include both PCells and PScells can be collectively referred to as spCells (special cells). All of these cells can be referred to as serving cells or cells. Unless otherwise explicitly distinguished, the terms "cell" and "serving cell" are generally used interchangeably. The term "serving cell" can refer to a cell that is currently serving a UE, will serve a UE, or can serve a UE. In other words, a "serving cell" may not currently be serving a UE. Although the various embodiments described below may sometimes refer to one of the various types of serving cells mentioned above, the basic principles apply to all types of serving cells in both types of serving cell groups.

[0051] Figure 4 Further demonstrated in Figures 1-3 In the example wireless access network, a simplified view of the various network layers involved in transmitting the user plane PDU from the transmitting device 402 to the receiving device 404 is provided. Figure 4 It is not intended to cover all the necessary equipment components or network layers for handling PDU transmissions. Figure 4 This illustrates that at transmission device 402, data packets from the upper network layer 420 can be routed through the transmission device's Packet Data Convergence Protocol layer (PDCP layer). Figure 4 (Not shown) and Radio Link Control (RLC) layer 422, the physical layer (PHY layer) and radio interface of the transmitting and receiving devices (as shown in 406), and the Media Access Control (MAC) layer and RLC layer 432 of the receiving device, transmitting to the corresponding upper layer 430 (e.g., Radio Resource Control (RRC) layer) at the receiving device 304. Various network entities in each of these layers can be configured to handle the transmission and retransmission of PDUs.

[0052] exist Figure 4 In the middle, the upper layer 420 can be referred to as layer 3 or L3, while layers such as RLC layer and / or MAC layer and / or PDCP layer ( Figure 4The intermediate layers (not shown in the diagram) can be collectively referred to as Layer 2 or L2, while the term Layer 1 is used to refer to layers such as the physical layer and radio interface-related layers. In some cases, the term "lower layer" can be used to refer to the set of L1 and L2, while the term "higher layer" can be used to refer to Layer 3. In some cases, the term "lower layer" can be used to refer to the layer below the current reference layer among L1, L2, and L3. Control signaling can be initiated and triggered in each of the layers L1 to L3 and in the various network layers within them. These signaling messages can be encapsulated and concatenated into lower-layer packets and transmitted through allocated control or data air radio resources and interfaces. The term "layer" typically includes various corresponding entities. For example, the MAC layer contains corresponding MAC entities that can be created. For example, Layer 1 contains PHY entities. As another example, Layer 2 contains MAC layer / entities, RLC layer / entities, Service Data Adaptation Protocol (SDAP) layer, and / or PDCP layer / entities.

[0053] For example, various system components of the aforementioned wireless communication networks can be adopted, enhanced, or modified to implement example communication systems for novel data transmissions (such as semantic communication), as detailed below.

[0054] New types of data transmission such as semantic communication The aforementioned wireless communication system is suitable for transmitting source information, in the form of a set of physical bits or symbols, from the original network node to the target network node through various network protocol layers, error detection / correction mechanisms, and transmission / retransmission schemes. This type of communication system can be called a Level 1 transmission system.

[0055] Specifically, according to basic information theory, information processing and communication systems can be described as solving problems that can be categorized into the following three levels: • Level 1: Solutions for physical information transmission, used to process the transmission of source bits or symbols with a certain level of accuracy; • Level 2: Solutions for semantic information transmission, used to transmit source semantics with a certain level of accuracy; • Level 3: Solutions related to transmission efficiency issues (e.g., how efficiently the received meaning can influence behavior in the desired manner).

[0056] In this context, the current wireless communication protocols described above are designed to address Level 1 problems, namely bit / symbol-level transmission with a certain level of accuracy (e.g., error-free). Since current physical technologies have reached the channel limits for bit / symbol-level transmission, higher throughput may only be achieved by expanding available spectrum and time transmission resources, or by network evolution channels based on Level 1 solutions. On the other hand, Level 2 fault-tolerant transmission (e.g., semantic communication) can help achieve improved overall information transmission by semantically encoding the source information at the transmitting end and semantically decoding the received semantic information at the receiving end. For example, semantic encoding and decoding can be closely related to the evolving (as an example, related to Natural Language Processing (NLP) for encoding textual information) Artificial Intelligence (AI) and / or Machine Learning (ML) technologies. Therefore, while maintaining the throughput of Level 1 channels, there may also be another direction to improve the effective capacity of NW: transmitting semantic meaning rather than the entire information symbol.

[0057] In some example implementations, to convey semantic meaning / information, a two-sided AI / ML model architecture can be considered. One side encodes / compresses the raw information into semantic information, and the other side decodes / decompresses the semantic information back into the raw information. This AI / ML-based encoding / decoding can be called source / target encoding / decoding, or semantic encoding / decoding. The main purpose of semantic encoding / decoding is to generate fewer bits and less symbolic information for transmission, while channel coding / decoding aims to improve the robustness of information transmission by adding redundant information to the raw information. Therefore, a joint semantic and channel coding / decoding approach can be designed to gain more benefits from overall semantic communication.

[0058] While the current NW protocol for wireless communication is designed to handle Level 1 problems as stated above, the following disclosure is intended to describe how to embed features that support novel data transmissions, such as fault-tolerant data transmission (e.g., semantic communication), into the current NW protocol, and how to improve the current NW protocol to accommodate such novel data communication.

[0059] Although this disclosure uses semantic communication as an example, the basic principles disclosed are generally applicable to fault-tolerant data communication and other novel data communication methods.

[0060] In some example implementations, to achieve joint semantic source coding and channel coding, one or more of the following options regarding the location of the source coding / decoding module in the wireless communication network can be considered: • In one example implementation of DL transmission / reception, the semantic source encoder can be located on the NW side, and the semantic source decoder can be located on the UE side.

[0061] • In one example implementation of UL transmission / reception, the semantic source encoder can be located on the UE side, and the semantic source decoder can be located on the NW side.

[0062] • In one example implementation, the semantic source encoder can be used as an AI / ML model to process source data. The input to the AI / ML model can be the raw data, and the output of the AI / ML model can be the encoded or compressed data of the raw data.

[0063] • In one example implementation, the semantic source decoder can act as an AI / ML model to process input data, which includes data contained in the AI / ML encoder and transmitted via a wireless network. The output of the AI / ML model can represent data decompressed from the compressed input data.

[0064] As mentioned above, one of the advantages of semantic communication is that source data can be significantly compressed by a semantic encoder, thereby reducing the channel resource consumption of user plane (UP) data. For example, with semantic communication, error-free transmission is not required because even if some compressed data is lost or transmitted incorrectly due to poor channel conditions, the semantically compressed data can be recovered at the receiving point due to the potential error recovery capability of the AI / ML-based semantic decoder. The following various embodiments of semantic communication implementations focus particularly on enhancing various aspects of current wireless communication protocols (e.g., 3GPP protocols), including but not limited to (1) AI / ML model management mechanisms and (2) switching mechanisms between new and traditional communications, in order to maximize the advantages of new communications. For example, new communications may refer to semantic communication.

[0065] AI / ML Model Management - General In some example implementations, AI / ML models may be data-specific (e.g., text data, image data, speech data, etc.) in terms of model architecture and / or training model parameters. These AI / ML models can be trained for encoding / compressing and decoding / decompressing different types of source data. Trained AI / ML models can be deployed at different locations, different network nodes, or different network layers within a wireless network to enable semantic communication. Figure 5 , Figure 6 and Figure 9 An example of the architecture and deployment of AI / ML models in a communication network is shown.

[0066] exist Figure 5In an example implementation, the AI / ML model used for semantic source encoding can be deployed at the application layer 502 on the UE side 501, and correspondingly deployed at the application server 504 on the network side 503. Model management can be performed between the application layer 502 and the application server 504. This management can vary depending on the specific implementation and can therefore be transparent to other lower network layers, including the NAS layer 510 and AS layer 512 on the UE side, the radio access network 522 and core network 520 on the network side, and the transport physical channel 530.

[0067] exist Figure 6 In an example implementation, the AI / ML model used for semantic source coding can be deployed in the NAS layer 610 on the UE side 601 and the core network (CN) 620 on the network side 603. Model management can be performed between the NAS layer 610 and the core network 620 via NAS signaling exchange. This management can be implemented by the network service provider via the wireless network rather than user equipment and application servers (therefore it can be centralized and shared by different application providers), and is thus transparent to lower network layers (including the AS layer 612 on the UE side, the radio access network 620 on the network side, and the transport physical channel 630).

[0068] Figure 7 It shows management Figure 6 An example implementation of the AI / ML model between NAS layer 610 and CN 920 in the architecture includes the following example steps: • Step 1: The CN can send the model management configuration to the UE.

[0069] • Step 2: The CN can send control signaling to the UE to activate the AI / ML model for the new transmission type.

[0070] • Step 3: The CN may send reference data and / or requests to the UE for performance monitoring of the new transmission type.

[0071] • Step 4: The UE can perform performance monitoring and calculate performance metrics based on the configuration and received reference data.

[0072] • Step 5: The UE may send the calculated performance metrics and / or (one or more) model control requests to the CN.

[0073] • Step 6: The CN can make model management decisions based on the received performance metrics and / or (one or more) control requests.

[0074] • Step 7: The CN can send model control signaling to the UE to adjust the model state.

[0075] Figure 8 It shows in Figure 6 Another example implementation of the architecture for managing AI / ML models between NAS layer 610 and CN 620, as... Figure 7 Alternatives to the illustrated scheme include the following example steps: • Step 1: The CN can send configurations for model management to the UE.

[0076] • Step 2: The CN can send control signaling to activate the AI / ML model for new transport types (e.g., semantic communication).

[0077] • Step 3: The UE may send reference data and / or requests to the CN for performance monitoring of the new transmission type.

[0078] • Step 4: If needed, CN can calculate performance metrics and make model management decisions based on the calculated metrics.

[0079] • Step 5: The CN can send model control signaling to the UE to adjust the model state.

[0080] Figure 7 and Figure 8 The main differences between the example implementations involve which network entity (UE or CN) provides reference data for performance monitoring, and which entity performs performance monitoring for the new transmission type.

[0081] about Figure 7 and Figure 8 The signaling for model management configuration in the two embodiments shown above can, in some example implementations, be transmitted via a protocol tunnel (e.g., NTTP (New Type Transmission Protocol)) between a logical function residing in the CN (e.g., Semantic Communication Management Function or SCMF) and the NAS layer of the UE. In some example implementations, this protocol tunnel is used for wireless communication networks (e.g., Figure 6 The base station (622) in the example can be transparent. In some example implementations, the SCMF described above may have interfaces connected to the SMF and / or UPF and / or AMF for different generations of example core networks. In some further example implementations, the functionality of the SCMF described above may include at least one of the following: • Model management for novel transports (e.g., semantic transport).

[0082] • Decode / encode UP data for new data transmission from UPF or UE.

[0083] • Regulation of QoS flows for new data transmission.

[0084] • Regulation of PDU sessions for new data transmission.

[0085] • Transmission / reception of data units used for new data transmission.

[0086] • Subheader attachment / detachment for data units used for new data transmission.

[0087] In some other example implementations, control signaling can be sent from the CN by the AMF. In these example implementations, the AMF can provide an interface with the SCMF, and the AMF can be configured to support at least one of the following functions for novel data transmission: • Model management for novel data transmissions (e.g., semantic transmissions).

[0088] • Decode / encode UP data for new data transmission from UPF or UE.

[0089] • Regulation of QoS flows for new data transmission.

[0090] • Regulation of PDU sessions for new data transmission.

[0091] Regarding Figure 7 and Figure 8 In some example implementations, the signaling for reference data used for performance monitoring described above may be NTTP protocol signaling. In some example implementations, the reference data may be retrieved from a test database or obtained from real transmissions to determine the predictive validity or accuracy of the deployed AI / ML model. In some example implementations, the reference data may include a set of benchmark data or a set of benchmark data pairs (e.g., benchmark input data and benchmark output data). Such benchmark data may come from a database used for model evaluation / testing and / or performance monitoring. If the reference data is benchmark data, it may serve as input to the compressed portion of a two-sided model. If the reference data is a data pair, one of the data pairs may be an input to the UE portion or NW portion of the two-sided model, which requires testing for validity or predictive accuracy. The other data pair may be an output to the UE portion or NW portion of the two-sided model, which requires testing for validity or predictive accuracy. In some example implementations, the reference data may include data from real transmissions. In other words, source data / recovered data is sent from the CN / UE to the UE / CN for performance monitoring.

[0092] Regarding the performance metric calculation method, in some example implementations, the performance metric can be obtained by comparing the benchmark reference output data with the output of the UE portion or the NW portion of the dual-sided model. The output of the UE portion or the NW portion of the dual-sided model can be obtained from the reference input data and the AI / ML model for which performance monitoring is required. In some example implementations, the performance metric can be obtained by comparing the reference data with the output of the decompression / decoding portion of the AI / ML model. In this example implementation, it can be assumed that the UE has a compression / encoding portion of the dual-sided model for DL ​​transmission. It can be assumed that the UE has a decompression / decoding portion of the dual-sided model for UL transmission, and it can be assumed that the CN has a decompression / decoding portion of the dual-sided model for DL ​​transmission. It can be assumed that the CN has a compression / encoding portion of the dual-sided model for UL transmission.

[0093] Regarding performance monitoring requests, in some example implementations, a peer entity (e.g., CN and / or UE) may send an NTTP protocol signaling message to request another peer entity (e.g., UE and / or CN) to trigger performance metric calculations. The NTTP protocol signaling message may indicate at least one of the following: 1) reference data (pairs) for performance metric calculations; 2) an indication for obtaining feedback on decompression / recovery and / or source data; 3) an indication for obtaining feedback on performance metrics; and 4) a threshold for determining model control behavior. In some example implementations, the NTTP protocol signaling format may be an NTTP protocol control element. In some other example implementations of the NTTP protocol signaling format, the NTTP protocol signaling format may be a subheader of an NTTP protocol data unit.

[0094] Regarding the performance metrics mentioned above, in some example implementations, the performance metric may include quantifying semantic differences. In some example implementations, the performance metric may include Euclidean distance.

[0095] Regarding model control requests and model control signaling, the control signaling can be NTTP protocol signaling as described above. Model control signaling can include model activation / deactivation / switching / rollback.

[0096] exist Figure 9In the example implementation of the model management architecture shown, the AI / ML model used for semantic source encoding can be deployed at the AS layer 912 on the UE side 901 and the access network (base station, such as NodeB) 922 on the network side 903. Model management can be performed between the AS layer 912 and the access network 922 via AS signaling exchange. This management can be implemented by the network service provider via the wireless network rather than user equipment and application servers (therefore it can be centralized and shared by different application providers), and since the wireless network is closest to the physical channel 930, model management can be provided with minimal latency.

[0097] Figure 10 It shows management Figure 9 An example implementation of the AI / ML model between the NAS layer 912 and the access network (e.g., NodeB) 922 in the architecture includes the following example steps: • Step 1: The NodeB can send configurations for model management to the UE.

[0098] • Step 2: The NodeB can send control signaling to activate the AI / ML model for new data transmission.

[0099] • Step 3: The NodeB may send reference data and / or requests to the UE for performance monitoring of new data transmissions.

[0100] • Step 4: The UE can perform performance monitoring and calculate performance metrics based on the configuration and received reference data.

[0101] • Step 5: The UE can send the calculated performance metrics and / or model management requests to the NodeB.

[0102] • Step 6: If necessary, NodeB can determine model management.

[0103] • Step 7: The NodeB can send model control signaling to the UE to adjust the model state.

[0104] Figure 11 It shows management Figure 9 An example implementation of the AI / ML model between the NAS layer 912 and the base station (NodeB) 922 in the architecture, as a... Figure 10 Alternatives to the illustrated scheme include the following example steps: • Step 1: The NodeB can send configurations for model management to the UE.

[0105] • Step 2: NodeB can send control signaling to activate AI / ML models for new types of data transmission (e.g., semantic communication).

[0106] • Step 3: The UE may send reference data and / or requests to the NodeB for performance monitoring of new data transmission.

[0107] • Step 4: NodeB can calculate performance metrics and make model management decisions based on the calculated metrics.

[0108] • Step 5: The NodeB can send model control signaling to the UE to adjust the model state.

[0109] Figure 10 and Figure 11 The main differences between the example implementations involve which network entity (UE or NodeB) provides reference data for performance monitoring, and which entity performs performance monitoring for novel data transmissions.

[0110] about Figure 10 and Figure 11 In one implementation, the signaling for model management configuration in the two embodiments described above may use RRC signaling. In some example implementations, RRC signaling may indicate a timing point or event for triggering the UE and / or NW to report calculated performance metrics and / or reference data used to calculate performance metrics. Such triggering timing points or events may include, but are not limited to, at least one of the following: applying a timer; applying a counter with a predefined maximum value; receiving a control PDU; or a threshold for triggering performance metric reporting indicated by RRC signaling.

[0111] about Figure 10 and Figure 11 In some example implementations, the control signaling may be RRC signaling, PDCP control PDU, RLC control PDU, MAC CE, or PHY control signaling (e.g., PUCCH and / or PDCCH), or a logical layer control PDU, where the logical layer is the access layer. In some example implementations, the control signaling may include / indicate at least one of the following: model identifier; model description information; service type; knowledge base identifier (used for...). Figure 9 The knowledge base shown); PDU session ID; QoS (Quality of Service) flow ID; Logical Channel (LCH) ID; or Data Radio Bearer (DRB) ID; Model control indication (e.g., activation / deactivation / switching / fallback).

[0112] about Figure 10 and Figure 11In some example implementations, the performance metric signaling may be RRC signaling, PDCP control PDU, RLC control PDU, MAC CE, or PHY control signaling (e.g., PUCCH and / or PDCCH). In some example implementations, the performance metric may be the quantization of the semantic difference between the encoder input and the decoder output. In some example implementations, the performance metric may be the quantized semantic difference between the model output and the received reference data. In some example implementations, the performance metric may be the Euclidean distance between the model output and the received reference data. In some example implementations, the performance metric may be the Euclidean distance between the encoder input and the decoder output.

[0113] about Figure 10 and Figure 11 In some example implementations, the reference data signaling used for performance monitoring in the two embodiments described above may be a PDCP control PDU, RLC control PDU, MAC CE, PUCCH / PDCCH, etc. In some example implementations, the reference data may be retrieved from a test database or obtained from real transmissions to determine the predictive validity or accuracy of the deployed AI / ML model. In some example implementations, the reference data may include a baseline data or a baseline data pair (e.g., baseline input data and baseline output data). The baseline data may come from a database used for model evaluation / testing and / or performance monitoring. If the reference data is baseline data, it may serve as input to the compressed portion of a bilateral model. If the reference data is a data pair, one of the data pairs may be an input to the UE portion or NW portion of a bilateral model, which requires testing for validity or predictive accuracy. The other data pair may be an output to the UE portion or NW portion of a bilateral model, which requires testing for validity or predictive accuracy. In some example implementations, the reference data may include data from real transmissions. In other words, the source data / recovered data will be sent from the NodeB / UE to the UE / NodeB for performance monitoring.

[0114] Regarding the performance metric calculation method, in some example implementations, the performance metric can be obtained by comparing the benchmark reference output data with the output of the UE portion or the NW portion of the dual-sided model. The output of the UE portion or the NW portion of the dual-sided model is obtained from the reference input data and the AI / ML model for which performance monitoring is required. In some example implementations, the performance metric can be obtained by comparing the reference data with the output of the decompression / decoding portion of the AI / ML model. In this example implementation, it can be assumed that the UE has a compression / encoding portion of the dual-sided model for UL transmission. It can be further assumed that the UE has a decompression / decoding portion of the dual-sided model for DL ​​transmission. It can be assumed that the CN has a decompression / decoding portion of the dual-sided model for UL transmission. It can be assumed that the CN has a compression / encoding portion of the dual-sided model for DL ​​transmission.

[0115] about Figure 10 and Figure 11 In some example implementations, the request signaling for performance monitoring in the two embodiments described above may be a PDCP control PDU, an RLC control PDU, a MAC CE, a PUCCH / PDCCH, and a logical layer protocol control PDU. The request signaling may indicate at least one of the following: 1) an indication of reference data (pairs) for performance metric calculation; 2) an indication of obtaining feedback for decompression / recovery and / or source data; 3) an indication of obtaining feedback for performance metrics; and 4) a threshold for determining model control behavior.

[0116] Regarding the performance metrics mentioned above, in some example implementations, the performance metric may include quantifying semantic differences. In some example implementations, the performance metric may include Euclidean distance.

[0117] Regarding model control requests and model control signaling, the control signaling can be NTTP protocol signaling as described above. Model control signaling can include model activation / deactivation / switching / rollback.

[0118] AI / ML Model Management - Upper-layer Response to Transmission Type Switching In some example implementations, novel data transmission methods (e.g., semantic communication) and traditional source symbol-based communication can coexist. For instance, a novel data transmission method can be activated or deactivated during a communication session when needed. Therefore, the network needs to be designed, configured, and tuned to handle the activation and deactivation of this novel data transmission, which can affect data transmission requirements and processing at various inter-node interfaces. Each network node participating in the communication process needs to understand the various configurations associated with semantic communication. For example, in… Figure 5 and Figure 6In the model management architecture, semantic communication can be transparent to the RAN (gNB or NodeB). However, these network nodes may need to be aware of the activation and deactivation of new data transmissions, which may require resource changes.

[0119] In some example implementations for switching between new transport types (e.g., semantic transport) and symbol-based transport, when establishing a PDU session for a service, data streams for both the new transport and symbol-based (e.g., traditional) transports can be established simultaneously. The activation / deactivation of the new transport can then be requested from the UE or the data network service provider. Each data stream can be established to handle either the new or traditional transport. Only when handling the new transport will AI / ML encoding / compression and decoding / decompression models be involved.

[0120] In some example implementations, one or more service flows or multiple service flows may be associated with a service. One of the multiple service flows may be mapped to a novel data transmission, while another service flow of the same service may be mapped to a traditional symbol-based transmission. In these example implementations, the service flow associated with the novel data transmission can be activated or deactivated upon request, or can be switched between the service flow for novel data transmission and the service flow for traditional symbol-based transmission. In these example implementations, deactivating a service flow means that the service flow is paused rather than released, and activating a service flow means that the service flow resumes from a paused state. In one example implementation, service flow switching can be applied to a service between novel data transmission and symbol-based transmission. For example, for such service flow switching, at least one service flow is deactivated while at least one other service flow of the service is activated. In some example implementations, the service flow may be a PDU session or a QoS flow. For example, for an AI / ML model used for novel data transmission located in, Figure 6 In the CN / NAS shown or as Figure 5 In the example scenario shown in the application server / application layer, the NW or UE can achieve this switching, activation, or deactivation through the following example steps: • Step 1: The UE can send a request message A to the CN to request PDU session activation / deactivation.

[0121] • Step 2: The CN can send a message B to the NodeB regarding service flow activation / deactivation.

[0122] • Step 3: The NodeB can send message C to the UE based on the received signaling regarding service flow activation / deactivation.

[0123] • Step 4: The UE can perform relevant operations based on message C and can send a response to message C to the NodeB.

[0124] • Step 5: NodeB can send a response message B to CN regarding service flow activation / deactivation.

[0125] In some of the example implementations described above, message A may be NAS signaling terminating between the UE's NAS layer and the CN. In some example implementations, message A may include / indicate at least one of the following: 1) a PDU session ID, indicating a PDU session that needs to be activated / deactivated; 2) an activation / deactivation indication, indicating the behavior (e.g., activation or deactivation) of the indicated PDU session; 3) a deactivation / activation request for an AI / ML model / function / feature regarding novel data transmission; and 4) an AI / ML model / function indication, indicating an AI / ML model / function that requests activation / deactivation.

[0126] In some example implementations, message B may be a termination signaling between the CN and the NodeB. In some example implementations, message B may include / indicate at least one of the following: 1) a PDU session ID indicating a PDU session that needs to be activated / deactivated; 2) an activation / deactivation indication indicating the behavior (e.g., activation or deactivation) of the indicated PDU session; 3) an activation / deactivation indication regarding the AI / ML model / function / feature for novel data transmission; and 4) an AI / ML model / function indication indicating the activation / deactivation of the AI / ML model / function.

[0127] In some example implementations, the message C described above may be resource control signaling (e.g., RRCReconfiguration ), or AS logic layer control PDU (e.g., SDAP control PDU, PDCP control PDU, MAC control element). In some example implementations, message C may include / indicate at least one of the following: 1) PDU session ID, indicating a PDU session that needs to be activated / deactivated; 2) Activation / deactivation indication, indicating the behavior (e.g., activation or deactivation) of the indicated PDU session; 3) Deactivation / activation indication regarding AI / ML models / functions / features for novel data transmission; 4) AI / ML model / function indication, indicating the activated / deactivated AI / ML model / function.

[0128] In the UE operation example of step 4 above, when the signaling indicates the deactivation of the PDU session, at least one of the following operations can be performed: 1) For UL transmission, one or more logical layers associated with the relevant data radio bearer of the indicated PDU session can transmit all data units in their buffers to the lower layer, which can be ACKed data units or non-ACKed data units; and / or 2) Reset all timers and counters in each AS logical layer associated with the relevant data radio bearer; and / or 3) For UL transmission, if there are no remaining data units in the buffer, or if an indication to deactivate the relevant PDU session is received, the logical layer associated with the indicated PDU session generates an end-marker data unit; and / or 4) For DL ​​transmission, one or more logical layers associated with the relevant data radio bearer can transmit all data units in their buffers to the upper layer, and these data units can be considered as ACKed. And / or 5) For DL ​​transmissions, the logical layer associated with the indicated PDU session may consider all data units of the indicated PDU session to have been received upon receiving end-of-session control data, and may notify each lower layer associated with the relevant radio bearer of the indicated PDU session to pause; and / or 6) Each logical layer associated with one or more radio bearers of the indicated PDU session may discard all data units stored in the buffer (if any); and / or 7) Upon receiving an end-of-session control PDU, receiving a deactivation signaling for the associated PDU session, or successfully sending an end-of-session control PDU, the radio bearer associated with the indicated PDU session may be considered paused; and / or 8) Upon receiving a PDU session deactivation signaling, the logical layer associated with the indicated PDU session may stop receiving data units from the upper layer (in this implementation, one or more air interface radio bearers (e.g., the interface between the UE and the nodeB) may be configured to transmit data for one or more specific PDU sessions).

[0129] In some other examples of UE operation in step 4 above, when signaling indicates that a PDU session is active, at least one of the following operations may be performed: 1) treating one or more radio bearers associated with the indicated PDU session as recovered; 2) resetting all timers / counters for each AS logical layer associated with the PDU session and / or all related radio bearers. In this implementation, one or more air interface radio bearers (e.g., the interface between the UE and the nodeB) may be configured to transmit data for one or more specific PDU sessions.

[0130] In some example implementations of step 4 above, the response message may be RRC signaling (e.g., an RRCReconfigurationComplete message) or an AS logical layer control data unit. The AS logical layer may be an SDAP layer, PDCP layer, RLC layer, MAC layer, PHY layer, etc., or it may be a logical layer associated with the specified PDU session. In some other example implementations of step 4 above, the response message may be an end-marked control PDU generated by the AS logical layer associated with the indicated PDU session.

[0131] In some example implementations of step 5 above, the response message may be a termination signaling between the NodeB and the CN, and may indicate / include the following information: 1) an indication of successful PDU session activation; 2) an indication of PDU session activation failure and its associated failure reason; 3) an indication of successful PDU session deactivation; 4) an indication of PDU session deactivation failure and its associated failure reason.

[0132] In some other example implementations, one or more air interface service flows (e.g., data radio bearers) may be associated with one or more PDU sessions or one or more QoS flows for novel data transmission. In these example implementations, a service flow associated with the novel data transmission can be activated or deactivated upon request, or the service flow can be switched between a service flow for novel data transmission and a service flow for conventional symbol-based transmission. In such example implementations, deactivating a service flow means suspending the service flow rather than releasing it. Activating a service flow means resuming a suspended service flow. In one example implementation, service flow switching can be applied between novel data transmission and symbol-based transmission. Service flow switching means that at least one service flow is deactivated while at least one other service flow is activated. For example, the NW or UE can implement the switching, activation, or deactivation of service flows associated with novel data transmission or symbol-based transmission through the following example steps: • Step 1: The UE can send request message A to the RAN node.

[0133] • Step 2: The RAN node can send a message B to the UE regarding the activation / deactivation of the service flow.

[0134] • Step 3: The UE can perform some activation / deactivation operations related to the service flow.

[0135] In step 1, in one example implementation, request message A may be UL RRC signaling, SDAP control data unit, PDCP control data unit, RLC control data unit, MAC control element, or PHY control signaling (e.g., PUCCH / PDCCH). In one example implementation, the signaling may indicate / include at least one of the following information: 1) AI / ML Model / Function Index: AI / ML models / functions for new data transmission that are requested to be deactivated / activated or switched.

[0136] 2) AI / ML model / function activation / deactivation / toggle flags: used to indicate the activation / deactivation / toggle of the indicated AI / ML model / function.

[0137] 3) Radio bearer index or logical channel index: used to indicate the service flow of new data transmissions that are requested to be activated / deactivated / switched.

[0138] 4) Service flow activation / deactivation / switching flag: used to indicate the activation / deactivation / switching of the service flow indicated above.

[0139] 5) Performance metric indication: Indicates the performance metric from the performance monitoring on the UE side.

[0140] In one example implementation, the service flow may be a radio bearer that terminates between the UE and the RAN node.

[0141] In step 2, in one example implementation of message B, message B may be a response message to message A. In another example implementation of message B, message B may be activation / deactivation control signaling for novel data transmission of AI / ML models / functions. In one example implementation, message B may indicate / include at least one of the following: 1) AI / ML Model / Function Metrics: Deactivation / Activation of new data transmission AI / ML models / functions.

[0142] 2) AI / ML model / function activation / deactivation / toggle flags: used to indicate the activation / deactivation of the indicated AI / ML model / function.

[0143] 3) Radio bearer index or logical channel index: used to indicate the service flow of new data transmissions that are requested to be activated / deactivated / switched.

[0144] 4) Service flow activation / deactivation / switching flag: used to indicate the activation / deactivation of the indicated service flow.

[0145] 5) Performance metric indication: Performance metrics that indicate performance monitoring from the NW side.

[0146] In step 3, the UE operation used to deactivate the service flow may include at least one of the following: 1) The logic layer that receives control signaling message B can instruct the logic layer (e.g., SDAP layer) to stop mapping PDU sessions and / or QoS flows to a service flow (e.g., radio bearer).

[0147] 2) The logical layer (e.g., the SDAP layer) can generate an end-of-life control data unit (PDU) for deactivated service flows and send the PDU to the lower layer. The end-of-life control PDU can indicate that the control data unit is the last data unit of this type of deactivated service flow.

[0148] 3) After receiving or successfully transmitting an end-of-life control PDU, the logical layer associated with the deactivated service flow (e.g., PDCP layer, RLC layer) can be considered re-established. For example, each logical layer can send all stored PDUs and / or SDUs that have not been acknowledged by the lower / upper layer to the lower / upper layer, and then each logical layer can discard all stored PDUs and / or SDUs and reset all timers, variables, and counters.

[0149] 4) After receiving or successfully sending an end-of-life control PDU, the logical layer (e.g., PDCP layer, RLC layer) associated with the deactivated service flow can be considered paused. In one example implementation, pausing a logical layer may include: 1) discarding all stored data units in the buffer; 2) initializing all timers, counters, and / or variables.

[0150] In step 3 above, the UE operation for activating the service flow may include at least one of the following: 1) A logical layer (such as SDAP) can map PDU sessions and / or QoS flows to active service flows.

[0151] 2) Each logical layer (e.g., PDCP layer or RLC layer) associated with the active service flow can be reset. In one example implementation, resetting a logical layer may include: 1) discarding all stored data units in the buffer; 2) initializing all timers, counters, and variables.

[0152] AI / ML Model Management - Control Plane Procedures / Signaling for New Transport Types To support RAN and UE processing and awareness of data transmission types, some control plane (CP) procedures may be required in the core network and / or radio access network, and implemented as described below: Figure 12 An example CP process is shown, which may include: • Step 1: The UE / database / application server can request the NW to establish and / or modify the service data stream.

[0153] • Step 2: NW can send responses to requests to establish and / or modify service data streams.

[0154] For example, in step 1 of the above example implementation, the NW can be the core network. In another implementation, the NW can be a base station or a RAN (e.g., a NodeB). In some example implementations, the service data flow can be one or more PDU sessions, one or more QoS flows, one or more radio bearers, or any combination thereof. For example, a PDU session can be a tunnel connecting the UE and the CN. For example, a QoS flow can be a sub-tunnel to the PDU session. The sub-tunnel can be configured with the QoS configuration for the connection between the UE and the CN. For example, a data radio bearer can be a tunnel connecting the UE and the base station.

[0155] In some example implementations of step 1 above, the request may include and / or may indicate at least one of the following information items: • Data stream type indicator: Used to indicate the type of data stream that is requested to be established or modified, such as error-free data stream, fault-tolerant data stream, etc.

[0156] • Quantization indicator: Used to indicate the scenario in which such a request for data stream is allowed / applied, such as the range of SINR values, RSRQ values, RSRP values, and transmission failure rates (e.g., including PDU transmission failures at each layer).

[0157] • Data stream QoS indicator: Used to indicate the QoS requirements of a data stream, such as 5QI level.

[0158] In some example implementations of step 2 above, the response may be a NAS signaling termination between the UE and the CN, or a Radio Resource Control signaling, or a message combining an RRC message and / or NAS signaling, and the response may indicate at least one of the following information items: • Confirmation / negative confirmation of the data stream establishment request in step 1.

[0159] • Data Stream ID: Used to indicate the data stream identifier configured for the UE.

[0160] • Quantization Configuration: Used to indicate scenarios that allow or enable fault-tolerant transmission (novel data transmission) of such data streams, such as SINR values, RSRQ values, RSRP values, and transmission failure rates (e.g., including PDU transmission failures at each layer). For example, in some example implementations, novel transmission may be allowed / enabled if the SINR of the channel state is greater than a specific SINR value in the quantization configuration. Similarly, novel transmission may be allowed / enabled if the RSRP of the channel state is greater than a specific RSRP value in the quantization configuration. For example, novel transmission may be allowed and / or enabled if the RSRQ of the channel state is greater than a specific RSRQ value in the quantization configuration. Furthermore, novel transmission may not be allowed and / or enabled if the novel transmission failure rate is greater than a specific threshold in the quantization configuration.

[0161] Figure 13 Another example CP process is shown (where the base station is divided into different functional units), which may include: • Step 1: The first unit of the base station may request the establishment and / or modification of the new transmission data stream.

[0162] • Step 2: The second unit can generate a response message for the request.

[0163] For step 1 above, in some example implementations, the first unit may include a centralized unit of the base station. In some example implementations, the second unit of the base station may represent a distributed unit of the base station. In some example implementations, the communication interface between the first and second units of the base station (e.g., CU and DU) may be an F1 interface. In some example implementations, step 1 may be associated with a UE context modification / establishment procedure.

[0164] In some example implementations, the request in step 1 above may include and / or indicate at least one of the following information items: • An air interface data stream (e.g., DRB) established for a data stream requested for a new type of transmission. • A secondary cell (SCell) established for the data stream requested by a new type of transmission. • A quantization indicator for the data stream requested for a new type of transmission, such as a SINR value, an RSRP value, an RSRQ value, or a transmission failure rate; • Data stream quality indicators, such as 5QI level.

[0165] For step 2 above, in some example implementations, the response may include and / or indicate at least one of the following information items: • Request an air interface data stream (list) (e.g., DRB (list)) to be established for the new type of data stream transmission; • Request the creation of a list of SCells for the new type of data stream. • Quantization indicator for each DRB / SCell to be established.

[0166] Error-free transmission and fault-tolerant transmission - general As mentioned above, novel transmissions such as semantic communication do not require error-free transmission. In particular, when transmission errors occur, AI / ML-based semantic communication can recover the semantics of the data through AI / ML models, even if some data may be lost or transmitted incorrectly due to poor channel quality. To take advantage of the benefits of semantic communication, UP data transmission can employ non-guaranteed transmission to reduce latency caused by potential retransmissions and save resource consumption.

[0167] However, PDU-based transmissions in 3GPP systems require error-free transmission of header information for each protocol layer and / or control signaling. Otherwise, PDUs will be discarded due to header errors, and CP-related processes will be considered failed due to control signaling errors. For at least this reason, current PDU-based solutions in symbol-based communication systems need modification for use in new transmissions.

[0168] Therefore, in some example implementations, CP data can be transmitted error-free, while semantic UP (user plane) data with protocol headers can be transmitted using a hybrid method of error-free and fault-tolerant transmission, where the protocol header can be transmitted error-free and the payload can be transmitted fault-tolerantly. For example, the protocol header for downlink (DL) data may include SDAP, PDCP, RLC, and MAC headers, etc. For example, the protocol header for uplink (UL) data may include SDAP, PDCP, RLC, and MAC headers, etc.

[0169] Furthermore, the fault tolerance level of non-header UP data payloads can depend on the capabilities of the AI / ML model, while the error level can depend on the quality of the underlying physical transmission channel, and can be adaptively adjusted through controllable levels of Cyclic Redundancy Check (CRC) and HARQ operations.

[0170] The modified PDU protocol system will preferably achieve one or more of the following objectives: • Objective 1: To support both error-free data streams and fault-tolerant data streams.

[0171] • Objective 2: Support error-free transmission of header information and fault-tolerant transmission of UP data.

[0172] • Objective 3: The CRC operation of the novel transmission needs to be controllable to adapt to various changes in channel conditions. This can be considered as Objective 3 of this disclosure.

[0173] Error-free transmission and fault-tolerant transmission - separating data streams that guarantee transmission from those that are fault-tolerant. In some example implementations, using UL licensing or DL ​​allocation can achieve the separation of data streams with guaranteed transmission from data streams with data fault tolerance. Figure 14 An example is shown, which includes the following example steps: • Step 1: The UE can receive RRC configuration signaling for the new transmission operation from the NW.

[0174] • Step 2: The UE can receive UL authorization and / or DL ​​allocation from the NW.

[0175] • Step 3a: If UL authorization is received in step 2, the UE performs UL authorization processing.

[0176] • Step 3b is an alternative to step 3a: If a DL allocation is received in step 2, the UE performs the DL allocation process.

[0177] • Step 4a: The UE generates a UL transmission to the NW based on the UL authorization.

[0178] • Step 4b is an alternative to step 4a: The UE performs a DL reception operation according to the DL allocation.

[0179] • Step 5b: The UE can send ACK / NACK to the NW according to the DL operation in step 4b.

[0180] For step 1 above, in some example implementations, the RRC configuration may indicate or include at least one of the following information items regarding the transmission operation: • An indication configured for, for example, a logical channel, radio bearer, or QoS stream. This indication can specify the transmission type of data from that logical channel, radio bearer, or QoS stream. In an example implementation of this indication, the transmission type of the logical channel, radio bearer, or QoS stream can depend on the transmission type of the HARQ process associated with the LCH, radio bearer, or QoS stream. For example, if a HARQ process with a HARQ process ID is indicated as a TYPE 1 transmission, the associated LCH and / or radio bearer and / or QoS stream can also be a TYPE 1 transmission. Otherwise, the associated LCH and / or radio bearer and / or QoS stream can be a TYPE 2 transmission.

[0181] • Instructions configured for the serving cell / BWP. Such instructions can indicate the transmission type (e.g., TYPE 1 transmission / TYPE 2 transmission) on the serving cell / BWP.

[0182] • An indication configured for the PDCCH timing location (e.g., search space). Such an indication can indicate the transmission type of the transmission scheduled by the UL authorization / DL allocation received from that PDCCH timing location.

[0183] • An indication configured for a PDCCH frequency location (e.g., CORESET). Such an indication can indicate the transmission type of a UL-licensed / DL-assigned transmission received from that PDCCH frequency location.

[0184] • Cell-specific radio network temporary identifier. UL license / DL assignments addressed by a cell-specific radio network temporary identifier can indicate TYPE 1 transmissions. In contrast, UL license / DL assignments addressed by a cell radio network temporary identifier other than a cell-specific radio network temporary identifier can indicate TYPE 2 transmissions.

[0185] • Indications for HARQ processing configuration. Such indications in the HARQ processing configuration may indicate the transport type of the transport corresponding to the HARQ processing. For example, in one example implementation of such indications, the HARQ processing configuration may include / indicate at least one of the following: ○ A parameter used to indicate the HARQ processing ID.

[0186] ○ A parameter used to indicate the type of transport processed by HARQ.

[0187] In some example implementations of step 1 above, the transmission type may include, but is not limited to: • TYPE 1 Transport: A transport can be fault-tolerant, or it can include both fault-tolerant and error-free transport. For example, a portion of the data used for transport may require fault-tolerant transport, which does not require HARQ-related operations. A portion of the data used for transport may require error-free transport, which requires HARQ-related operations.

[0188] • TYPE 2 transmission: The transmission type can be error-free transmission. For example, the data used for transmission may require HARQ-related operations. TYPE 2 transmission can also be symbol-based transmission, widely used in LTE and NR.

[0189] In the above example embodiments, all TYPE 1 and TYPE 2 transmissions appearing in this specification can have the same definition. The terms "HARQ operation" or "HARQ-related operation" appearing in this specification can include several operations to achieve error-free transmission. For example, the sending side can encode the data block using redundancy / check bits (e.g., using a specific redundancy check method (e.g., CRC, Low-Density Parity-Check (LDPC), Polar code, or Turbo code) to encode the data block), and perform a retransmission if a NACK is received; while the receiving side can use the redundancy / check bits added by the sending side to check whether the data block has been correctly received (e.g., using a specific redundancy check method (e.g., CRC, LDPC, Polar code, or Turbo code) to decode the data block), and generate an ACK or NACK for the received data block after the check.

[0190] exist Figure 14 In some example implementations of steps 3a and 3b above, for processing received UL grants and / or DL ​​allocations, the UE can determine the transmission type of the UL grant / DL allocation through the following example methods: • The UE can regard the UL grant / DL allocation addressed by the UE identifier (e.g., CRNTI) defined by a specific cell as the corresponding scheduling transmission type (e.g., TYPE 1 or TYPE 2).

[0191] • The UE can regard the UL grant / DL allocation received in the PDCCH with a specific time location (e.g., search space) as the corresponding scheduling transmission type.

[0192] • The UE can regard the UL grant / DL allocation received in the PDCCH with a specific frequency location (e.g., CORESET) as the corresponding scheduling transmission type.

[0193] • UL authorization / DL allocation may include an indication of the scheduled transmission type, which the UE can use to determine the transmission type.

[0194] • For a given HARQ process, the UL authorization and DL allocation can be implicitly indicated by the transport type configured for that HARQ process. For example, if the scheduled HARQ process is configured for TYPE1 transport, then the UL authorization / DL allocation can be used for TYPE1 transport; otherwise, the UL authorization / DL allocation can be used for TYPE2 transport.

[0195] exist Figure 14In some example implementations of step 4a, for generating UL transports based on received UL grants, MAC packet data units and / or transport blocks (TBs) should be generated. In one example implementation of generating MAC data units and / or TBs, an LCH limiting factor may be introduced. This LCH limiting factor can be used by the MAC entity to determine the LCH, where data can be multiplexed into MAC packet data units / TBs for UL transports scheduled by the UL grant. In some example implementations, the aforementioned LCH limiting factor may be a list of allowed serving cells and / or BWPs, meaning that data from the LCH can be multiplexed and assembled for UL transports on these serving cells / UL BWPs. In another example implementation, the aforementioned LCH limiting factor may be a list of allowed HARQ processing IDs, meaning that data from the corresponding LCH can only be multiplexed and assembled for UL grants of allowed HARQ processing IDs.

[0196] Some example implementations of step 4a (i.e., the generation of the MAC PDU for TYPE 1 transmission) will be described in the following embodiments (e.g., titled " Separate header / control information from source data block / filler The embodiments described in the "" section are further described.

[0197] exist Figure 14 In some example implementations of steps 4b and 5b, for DL ​​reception performed according to the received DL allocation, if the received DL allocation indicates that the scheduled transmission is a TYPE 1 transmission, then the received transport block (TB) or a portion of the received TB may not require HARQ-related operations and / or the generation of HARQ feedback (e.g., ACK / NACK) based on the received DL allocation. In some example implementations, if the received DL allocation indicates that the scheduled transmission is a TYPE 2 transmission, then the received TB may require HARQ-related operations and / or the generation of corresponding HARQ feedback (e.g., ACK / NACK) based on the received DL allocation.

[0198] In some example implementations of steps 4b and 5b, the DL reception of TYPE 1 transmission is further described in the following disclosure (e.g., Separate header / control information from source data block / filler ).

[0199] In some implementations, HARQ-related operations can be handled by a higher layer (e.g., one or more MAC entities for UL and DL transmissions). An example implementation of HARQ operation handling for UL authorization may include the following steps: • Step 0: You can receive UL authorization from NW.

[0200] • Step 1: The UE can determine the type of transmission authorized by the UL (e.g., new transmission or retransmission).

[0201] • Step 2: If the UL authorization is for a new transmission, the UE multiplexes the MAC SDU and MAC CE into the UL-authorized MACPDU and instructs the lower layer to perform the UL transmission.

[0202] • Step 3: If the UL authorization is for retransmission of the HARQ processing ID, and / or a NACK for the HARQ processing ID transmitted to the UL has been received, the MAC entity may generate a retransmission of the MAC PDU.

[0203] In some example implementations of step 2 above, the MAC entity may be responsible for the composition of the MAC PDU, and the MAC PDU may include one or more MAC sub-PDUs.

[0204] In some example implementations that multiplex MAC SDUs and / or MAC CEs to MAC PDUs, the MAC entity may attach HARQ-related information to one or more MAC sub-PDUs. In some example implementations of MAC sub-PDUs, the MAC sub-PDU may include a MAC SDU or MAC control element and corresponding sub-header information. In some example implementations, at least one of the following MAC sub-PDUs may need to have HARQ-related information attached: • MAC sub-PDU corresponding to the MAC control element; • MAC subPDU corresponding to the MAC SDU of the LCH associated with a service flow that requires or is configured to transmit TYPE 2 (e.g., a radio bearer).

[0205] • A MAC sub-PDU corresponding to the MAC SDU of control signaling from the upper layer (e.g., SDAP / PDCP / RLC).

[0206] • A MAC sub-PDU that includes one or more header information for a payload data unit from an upper layer (e.g., a logical layer above the MAC layer).

[0207] In some example implementations that append HARQ-related information to each MAC sub-PDU requiring HARQ operation, the MAC entity may perform at least one of the following operations: • Use one bit in the MAC subheader of the SDU or MAC control element to indicate whether HARQ related information is appended to the end of (one or more) SDUs or (one or more) MAC CEs.

[0208] • Include HARQ-related information in the MAC subheader of (one or more) SDUs or (one or more) MAC CEs.

[0209] In some example implementations that attach HARQ-related information to more than one MAC sub-PDU, to conserve HARQ-related information, one or more MAC sub-PDUs may be grouped together for HARQ-related operations, so the MAC entity may perform at least one of the following operations: • Group MAC sub-PDUs into multiple groups within a single MAC PDU. In one example implementation of this grouping / separation mechanism, MAC sub-PDUs requiring HARQ operations are assigned to one or more groups, while MAC sub-PDUs not requiring HARQ operations are assigned to other groups.

[0210] • Append a HARQ header to a set of MAC sub-PDUs that require HARQ information. The HARQ header may include HARQ-related information, which may include a bit length indication of the group corresponding to the HARQ-related information.

[0211] • Do not append any HARQ headers to a set of MAC subPDUs that do not require HARQ information.

[0212] In some example implementations of step 3 above, the NACK indication for UL transmission can take at least one of the following formats: • Indicate HARQ ACK / NACK in the PDCCH used for scheduling retransmissions. For example, the PDCCH may be used to indicate a UL authorization for scheduling retransmissions to a HARQ processing ID associated with a UL transmission. In one example implementation, the PDCCH may include at least one of the following information: ○ HARQ Processing ID: Used to indicate the HARQ processing for which the retransmission is scheduled.

[0213] ○ Group Indicator: Used to indicate the MAC sub-PDU group to which retransmission is scheduled.

[0214] ○ MAC Sub-PDU Indicator: Used to indicate the MAC sub-PDU for which retransmission is scheduled.

[0215] • Indicate HARQ ACK / NACK in the PDSCH. For example, a DL MAC CE can be used to indicate NACK. In one example implementation, the DL MAC CE may include / indicate at least one of the following: ○ HARQ Processing ID: Used to indicate the HARQ processing associated with the MAC PDU.

[0216] ○ MAC Sub-PDU Indicator: A MAC sub-PDU used to indicate whether a MAC PDU has been acknowledged or denied.

[0217] ○ Group Indication: Used to indicate whether a MAC sub-PDU group has been confirmed or denied confirmation.

[0218] ○ ACK / NACK indication: Used to indicate the ACK / NACK of each indicated MAC PDU / MAC subPDU / MAC subPDU group.

[0219] In some example implementations of step 3 above, for the retransmission of MAC PDUs, upon receiving a NACK, a MAC SDU / MAC CE or MAC sub-PDU(group) with HARQ-related information appended can be retransmitted. In this implementation, the MAC entity can send the MAC PDU to the multiplexing and assembly entity to regenerate the MAC PDU for retransmission, wherein MAC sub-PDUs without appended HARQ information are eliminated.

[0220] In some other example implementations of MAC PDU retransmission, the MAC SDU / MAC CE or MAC subPDU(group) indicated by the NACK can be retransmitted upon receiving a NACK. For example, the MAC entity can send the MAC PDU to a multiplexing and reassembly entity to regenerate the MAC PDU for retransmission, where the MAC subPDU with the ACK indication is removed.

[0221] In some other example implementations of MAC PDU retransmission, the entire MAC PDU can be retransmitted when a NACK is received.

[0222] In some implementations of DL allocation, a typical HARQ operation processed by the upper layer (e.g., one or more MAC entities) may include the following steps: • Step 1: The UE can receive the DL allocation processed by HARQ.

[0223] • Step 2: The MAC entity can handle DL allocation, determine whether the DL reception is a new transmission or a retransmission, and send this information to the HARQ entity.

[0224] • Step 3: The MAC entity can assign the TB received from the lower layer and associate the HARQ processing ID with the HARQ processing.

[0225] • Step 4: The MAC entity can decode the TB into a MAC PDU and parse the MAC PDU into a MAC sub-PDU processed by HARQ.

[0226] • Step 5: The MAC entity can forward each MAC sub-PDU to the upper layer by deleting the sub-headers / headers added in the MAC layer.

[0227] • Step 6: The MAC entity can generate NACK / ACK information for HARQ processing and instruct the lower layer to transmit NACK / ACK indication.

[0228] In some example implementations of step 2 above, for the DL allocation used to indicate the retransmission of the HARQ processing ID, the PDCCH used for DL ​​allocation may include / indicate at least one of the following information: • HARQ Processing ID: Used to indicate the HARQ processing to which the retransmission is targeted. In one example implementation, the HARQ Processing ID indicates all MAC sub-PDUs and / or MAC sub-PDU groups that have been indicated as NACK, and these MAC sub-PDUs and / or MAC sub-PDU groups are transmitted via the DL-assigned HARQ Processing ID.

[0229] • Transmission type indicator: Used to indicate the transmission type (e.g., retransmission / new transmission). In one example implementation, the transmission type indicator may indicate an NDI value that is used to compare with a previous NDI value of the same HARQ processing ID.

[0230] • MAC Sub-PDU Indicator: Used to indicate the MAC sub-PDU associated with the indicated HARQ processing ID, and retransmitted by the DL.

[0231] • MAC Sub-PDU Group Indicator: Used to indicate the MAC sub-PDU group associated with the indicated HARQ processing ID, and retransmitted by the DL.

[0232] In some example implementations of decoding and parsing the TB / MAC PDU in step 4, if HARQ-related information is appended and HARQ fails, the MAC entity may consider the MAC sub-PDU as a reception failure. In some other example implementations of decoding and parsing the TB / MAC PDU in step 4, if at least one MAC sub-PDU fails with HARQ operation, the MAC entity may consider all MAC sub-PDUs with appended HARQ-related information as failures. In some other example implementations of decoding and parsing the TB / MAC PDU in step 4, if at least one or more than N MAC sub-PDUs in a group fail with HARQ operation, the MAC entity may consider all MAC sub-PDUs in that group as reception failures. In this implementation, the value of N can be configured in the RRC configuration or hardcoded in the specification. In some other example implementations of decoding and parsing the TB / MAC PDU in step 4, if at least one or more than N MAC sub-PDUs fail with HARQ operation, the MAC entity may consider the MAC PDU as a reception failure. In this implementation, the value of N can be configured in the RRC configuration or hardcoded in the specification.

[0233] In some example implementations of step 5 above, at least one of the following MAC sub-PDUs can be forwarded to the upper layer: • MAC sub-PDU without any HARQ-related information attached; • A MAC sub-PDU (group) is considered successfully received when HARQ-related operations are performed in a MAC entity.

[0234] In some example implementations of step 6 above, the NACK / ACK indication for the received MAC PDU can be UL MAC CE or PUCCH signaling, which may include or indicate at least one of the following information: • HARQ Processor ID: Indicates the HARQ process ID to which the ACK / NACK message is directed. • MAC Sub-PDU Indicator: Indicates the MAC sub-PDU that failed and / or succeeded in the HARQ operation.

[0235] • MAC Sub-PDU Group Indicator: Used to indicate MAC sub-PDUs (groups) that failed and / or succeeded in HARQ operations.

[0236] • NACK / ACK indication: Used to indicate reception failure / success for each HARQ processing ID, MAC sub-PDU, and MAC sub-PDU group.

[0237] Error-free and fault-tolerant transmission - Separate header / control information from source data blocks / padded headers As mentioned above, for new transmission methods, since the protocol header / control information may need to be transmitted error-free, while the payload information, even with a certain degree of transmission errors, can be recovered during the aforementioned decompression / decoding process, they can be transmitted separately. Figure 15 As shown, in an example implementation that separates header information processing from payload information processing, each upper layer in the communication protocol stack (e.g., SDAP, PDCP, RLC) can generate a header that is not attached to the source data block for a new type of transport (e.g., semantic transport). In some example implementations, the MAC layer can be responsible for assembling the headers from the upper layers and the MAC layer itself, along with the corresponding source data block, into the MAC PDU.

[0238] For example, a MAC entity can have two example methods to multiplex the header and payload and assemble them into a MAC PDU. To facilitate HARQ operations on continuous data streams, a MAC PDU can be divided into two parts. For example... Figure 16 As shown, the first part may include header and / or control information, while the second part may include source data blocks or payload data. In some implementations, such as Figure 16 As shown in the upper part, the source data block in this MAC PDU can be located after the header / control information section. In some other implementations, such as Figure 16 As shown in the lower half, the source data block in this MAC PDU can be located before the header / control information section.

[0239] In the first approach, where the MAC entity multiplexes and assembles the header and payload into a MAC PDU, the MAC entity can generate a MAC PDU and / or TB that includes header information received from the upper layer and a source data block. In this implementation, the header portion of the MAC PDU may require HARQ operations, while the source data portion of the MAC PDU may not require HARQ operations.

[0240] In the second approach, where the MAC entity multiplexes and assembles the header and payload into a MAC PDU, the MAC entity can generate two separate MAC PDUs and / or TBs, one including header information received from the upper layer and the other including the payload. In this implementation, each MAC PDU containing the upper layer's header information may require HARQ operations, but the MAC PDU containing the source data may not require HARQ operations.

[0241] In the above example implementation, the HARQ operation can reside in a logical layer that carries the retransmission function. For example, the HARQ operation can reside in the PHY layer. For example, the HARQ operation can reside in the MAC layer.

[0242] In some example implementations, each upper layer (e.g., SDAP layer, PDCP layer, RLC layer, MAC layer) can perform HARQ operations on the corresponding header and / or control signaling. In such implementations, the HARQ operation can reside at each upper layer for the corresponding header information and / or control information. In this implementation, the HARQ operation for the source data block can reside at a lower layer (e.g., PHY layer) or an upper layer (e.g., SDAP layer).

[0243] In some example implementations, the processing of received PDUs or sub-PDUs for data transmission can follow these example steps: • Step 1: When the UE's AS logic layer receives a sub-PDU or PDU from the lower layer or NW, it can perform a HARQ operation on the sub-PDU or PDU.

[0244] • Step 2a: When the HARQ operation is considered successful, the AS logic layer can transfer the sub-PDU or PDU to the upper layer by removing the header information.

[0245] • Step 2b is an alternative to step 2a: When the HARQ operation is deemed to have failed, the AS logic layer can execute the sub-PDU or the operation on the PDU.

[0246] In some example implementations of step 1 above, the AS logic layer can be one of the PHY layer, MAC layer, RLC layer, PDCP layer, and SDAP layer, or it can be a layer composed of multiple layers among the PHY layer, MAC layer, RLC layer, PDCP layer, and SDAP layer.

[0247] In some example implementations of step 1 above, a sub-PDU or PDU can be a data block, and a sub-PDU or PDU can include a header portion and / or a payload portion.

[0248] In some example implementations of step 1 above, the UE may perform HARQ operation only on the sub-PDU or the header portion of the PDU. In some example implementations, if the HARQ operation on the header portion is successful, the UE may consider that the sub-PDU or PDU (e.g., including the header and payload portions) has been successfully received.

[0249] In some example implementations of step 1 above, the UE can perform HARQ operations on the header and payload portions. For example, if the header portion of a sub-PDU or PDU is successfully decoded, the UE can consider the sub-PDU or PDU to have been successfully received even if the payload transmission is considered to have failed. As another example, if the number of retransmissions of the header portion of a sub-PDU or PDU reaches a predefined maximum, this can be considered an indication that the payload portion of the sub-PDU or PDU has failed to transmit.

[0250] In some example implementations of step 2b above, the operation performed on the sub-PDU or PDU may include at least one of the following: • Discard the entire sub-PDU or PDU, including both its head portion and payload portion.

[0251] • Discard only the sub-PDU or the header portion of the PDU.

[0252] • Generate HARQ feedback for sub-PDUs or PDUs, and / or instruct lower layers to send HARQ feedback instructions to peer layers.

[0253] • Generate ARQ feedback for sub-PDUs or PDUs, and / or instruct lower layers to send ARQ feedback to peer layers.

[0254] In some example implementations, HARQ operations can be performed at the physical layer if needed. UL transmission can be implemented using the following example steps: • Step 1: After receiving the UL authorization from the lower layer, the UE's MAC entity can determine whether the UL authorization is for TYPE 1 transmission. If the UL authorization is for TYPE 1 transmission, proceed to Step 2 below. Otherwise, terminate the process.

[0255] • Step 2: The UE's MAC entity can determine whether the transmission is a new transmission or a retransmission of TYPE 1.

[0256] • Step 3a: If the UE’s MAC entity determines that the UL transmission is a new transmission, it can perform multiplexing and assembly of the MAC PDU, generate a TB and pass it to (one or more) HARQ processes.

[0257] • Step 3b: If the UE's MAC entity determines that the UL transmission is a retransmission, the TB's UL authorization and HARQ information can be passed to the HARQ processing for retransmission.

[0258] • Step 4: The MAC entity can instruct the lower layer to initiate a UL transmission (e.g., a new transmission or a retransmission).

[0259] In some example implementations of step 1 above, the MAC entity can identify the UL authorization as a UL authorization transmitted in TYPE 1 by at least one of the following methods: • The serving cell and / or BWP for which UL authorization applies. In one example implementation, the serving cell / BWP may be configured with an indication that the serving cell / BWP is used for TYPE 1 transmission.

[0260] • A PDCCH timing location that receives UL authorization (e.g., a PDCCH search space). For example, a PDCCH timing location can be configured to schedule TYPE 1 transmissions that receive UL authorization.

[0261] • Receive UL-authorized PDCCH frequency positions (e.g., PDCCH CORESET). PDCCH frequency positions can be configured to schedule TYPE 1 transmissions, where UL authorization is received.

[0262] • The HARQ processing ID indicated in the UL authorization. For example, the HARQ processing indicated by this HARQ processing ID is configured for TYPE 1 transmission.

[0263] • An indication in the PDCCH of the UL authorization addressing, used to indicate that the UL authorization is for TYPE 1 transmission.

[0264] • An indication configured in a logical channel or radio bearer to indicate that the data therein is a logical channel or radio bearer for TYPE 1 transmission. For example, a UL license can be implicitly determined as a UL license for TYPE 1 transmission by at least one of the following methods: ○ An LCH / RB factor mapping relationship may exist between the LCH / RB and the serving cell / BWP. The UL authorization of the mapped serving cell / BWP can be determined as the UL authorization for TYPE 1 transmission.

[0265] ○ An LCH / RB factor mapping relationship may exist between LCH / RB and HARQ processing. The UL authorization of a mapped HARQ processing can be determined as the UL authorization for TYPE 1 transmission.

[0266] In some example implementations of step 3a above, when a MAC entity passes a TB to a HARQ process, the MACPDU can be divided into at least two sub-TBs for one TB in the PHY layer transmission. At least one of the two sub-TBs can be generated for the header and / or control information portion of the MAC PDU, while the other sub-TB can be generated for the source data block portion of the MAC PDU. For example, the MAC entity can pass two or more sub-TBs to the HARQ process. The HARQ process buffer can be divided into at least two parts. One of the at least two parts can be configured to store the header and / or control information, while the other part can be configured to store the source data block. Again, for example, two or more sub-TBs can be passed to different HARQ processes. The HARQ process for the sub-TB associated with the header / control information can support HARQ operations, while the HARQ process for the sub-TB associated with the source data block may not support HARQ operations. In one example implementation of the HARQ process, one HARQ process that supports HARQ operations can come from a HARQ entity, while a HARQ process that does not support HARQ operations can come from another HARQ entity. In this example implementation, the serving cell or cell group can be configured with at least two HARQ entities. Further in this example implementation, two sub-TBs from one MAC entity can be sent to two HARQ processes with the same HARQ process ID in different HARQ entities. In one example of HARQ processing, 2N HARQ processes can operate in one HARQ entity, where the first / second half of the HARQ process ID can be used for transmissions requiring HARQ operation, and the second / first half of the HARQ process ID can be used for transmissions not requiring HARQ operation. In this example implementation, one sub-TB can be sent to the HARQ process with HARQ process ID = x, and another sub-TB can be sent to the HARQ process with HARQ process ID = x + n. In one example of HARQ processing, N HARQ processes can be assigned to at least two groups of one HARQ entity, where the first group of HARQ processes in one HARQ entity can support HARQ operation, while the second group of HARQ processes in another HARQ entity may not support HARQ operation.

[0267] In some example implementations of step 3a above for a new transmission, the MAC layer may indicate which sub-TB in the lower-level HARQ processing buffer requires a HARQ operation. In other example implementations of step 3a above for a new transmission, the MAC layer may pass different sub-TBs of the source data block to different HARQ processes, where the HARQ processing of the sub-TB associated with control and / or header information may require a HARQ operation, while the HARQ processing of the sub-TB associated with the source data block may not require a HARQ operation.

[0268] Furthermore, in order for the NW to successfully segment the TB received from the UE, the UE may need to inform the NW of the size of each sub-TB within a TB. In some example implementations, the sub-TB size information can be indicated in the PUSCH. For example, the sub-TB size of the first part of the MAC PDU can be indicated in the front of the corresponding MAC PDU.

[0269] In some example implementations of step 3b above for retransmission, the MAC layer can indicate to the lower layers which sub-TB will be retransmitted and the HARQ operation required for HARQ processing. For example, a bitmap containing at least two bits for the HARQ processing ID in the UL authorization is used to indicate which sub-TB (e.g., header, control information, or source data block) is for retransmission. In some other implementations, the sub-TB for retransmission can be indicated by the HARQ ID in the UL authorization for retransmission.

[0270] In some example implementations, HARQ operations can be performed at the PHY layer if needed. DL transport can be implemented using the following example steps: • Step 1: The UE determines whether a DL allocation is available for TYPE 1 transmission. If a DL allocation for TYPE 1 transmission is received, proceed to Step 2. Otherwise, terminate the process.

[0271] • Step 2: The UE's MAC entity can handle DL allocation and attempt to receive TB or subTB from the lower layer.

[0272] • Step 3: The UE's MAC entity can assign one or more TBs or one or more sub-TBs received from the lower layer to HARQ processing.

[0273] • Step 4: The UE's MAC entity attempts to decode the received TB(one) or (one) subTB(one).

[0274] • Step 5a: If the received TB(one or more) or subTB(one or more) is undecodeable, the UE's MAC layer may instruct the lower layer to generate NACK signaling for the received TB(one or more) or subTB(one or more).

[0275] • Step 5b: If the received TB(one or more) or subTB(one or more) is successfully decoded, the UE's MAC entity can pass the decoded MAC PDU to the deassembly and demultiplexing entity and instruct the lower layer to generate ACK signaling.

[0276] In some example implementations of step 1 above, the DL allocation for TYPE 1 transmission can be identified in at least one of the following ways: • The DL assigns the serving cell and / or BWP to which it is targeted. In one example implementation, the serving cell / BWP may be configured with an indication that the serving cell / BWP is for TYPE 1 transport.

[0277] • Receive the PDCCH timing position assigned by the DL (e.g., the PDCCH search space). For example, the PDCCH timing position can be configured to schedule TYPE 1 transmissions, where the DL assignment is received.

[0278] • Receive the PDCCH frequency position (e.g., PDCCH CORESET) assigned by the DL. For example, the PDCCH frequency position is configured to schedule TYPE 1 transmissions, where the DL assignment is received.

[0279] • The HARQ processing ID indicated in the DL allocation. For example, the HARQ processing indicated by this HARQ processing ID can be configured for TYPE 1 transport.

[0280] • An indication in the PDCCH of the DL allocation addressing, used to indicate that the UL authorization is for TYPE 1 transmission.

[0281] • An indication configured in a logical channel or radio bearer to indicate that the data therein is a logical channel or radio bearer for TYPE 1 transmission. For example, a DL allocation can be implicitly determined as a UL license for TYPE 1 transmission by at least one of the following methods: ○ An LCH / RB factor mapping relationship may exist between the LCH / RB and the serving cell / BWP. The UL authorization of the mapped serving cell / BWP can be determined as the UL authorization for TYPE 1 transmission.

[0282] ○ An LCH / RB factor mapping relationship may exist between LCH / RB and HARQ processing. The UL authorization of a mapped HARQ processing can be determined as the UL authorization for TYPE 1 transmission.

[0283] In some example implementations of step 2 above regarding DL allocation, it may be indicated that only HARQ processing IDs are used for the header / control information and the source data block. In some example implementations for new transmissions, it may be indicated that more than one HARQ processing ID is used for the header / control information and the source data block, respectively.

[0284] In some example implementations of step 3 above for a TB or sub-TB, the TB can be divided into at least two sub-TBs, where at least one sub-TB may require HARQ-related operations, while at least one sub-TB may not require HARQ-related operations.

[0285] In some other example implementations of step 3 regarding the allocation of sub-TBs to HARQ processes, the MAC entity may allocate all sub-TBs of a TB to a single HARQ process. In this example, a HARQ process may have at least two independent HARQ buffers to hold each sub-TB received from the lower layer. In some other example implementations of step 3 regarding the allocation of sub-TBs to HARQ processes, the MAC entity may allocate the individual sub-TBs of a TB to different HARQ processes.

[0286] In some other example implementations of step 3 above regarding HARQ processing, HARQ processing groups can be introduced, wherein a HARQ entity can have more than one HARQ processing group, and at least one HARQ processing group has HARQ-related operations, while at least one HARQ processing group does not have HARQ-related operations. In another example implementation of step 3 above regarding HARQ processing, a HARQ processing with HARQ-related operations can come from a HARQ entity, while a HARQ processing without HARQ-related operations can come from another HARQ entity. In this example implementation, the serving cell or cell group can be configured with at least two HARQ entities, wherein two sub-TBs received by the MAC entity can be sent to two HARQ processes with the same HARQ processing ID in different HARQ entities. In one example, 2N HARQ processes can run in a single HARQ entity, wherein the HARQ processing IDs of the first / second half can be used for transmissions requiring HARQ-related operations, while the HARQ processing IDs of the second / first half can be used for transmissions not requiring HARQ-related operations. In this example implementation, one sub-TB can be sent to the HARQ process with HARQ process ID=x, while another sub-TB can be sent to the HARQ process with HARQ process ID=x+n.

[0287] In some example implementations that divide a TB associated with a HARQ process into multiple sub-TBs, the size of each sub-TB can be indicated in the PDCCH. In some other example implementations, the size of the first sub-TB in a TB can be indicated in the front of the MAC PDU associated with the TB.

[0288] In some other example implementations of step 5 above, a TB including multiple subTBs can be considered successfully decoded if and only if all subTBs and / or HARQ processing associated with the TB has been successfully decoded.

[0289] In some other example implementations of step 5 above, if a sub-TB requiring HARQ-related operations is successfully decoded, a TB including multiple sub-TBs can be considered successfully decoded.

[0290] In some other example implementations of step 5 above, if the number of retransmissions of a sub-TB of a TB reaches the predefined or preconfigured maximum number, then the TB is considered to have failed to decode.

[0291] In some example implementations, the ACK / NACK signaling described above may include or indicate one or more of the following information items: • SubTB indication, used to indicate which subTB is acknowledged or denied.

[0292] • HARQ process ID, used to indicate which HARQ process was acknowledged or denied.

[0293] • Code Block Group (CBG) indicator, used to indicate which(s) of the indicated subTB are acknowledged or denied.

[0294] In some example implementations, HARQ-related operations can be performed at the MAC layer if needed. UL transmission can be implemented using the following example steps: • Step 1: After receiving the UL authorization from the lower layer, the UE's MAC entity can determine whether the UL authorization is for TYPE 1 transmission. If it is determined that the UL authorization is for TYPE 1 transmission, proceed to Step 2. Otherwise, the process ends.

[0295] • Step 2: The UE's MAC entity can determine whether the transmission is an initial transmission or a retransmission.

[0296] • Step 3a: If the transmission type is a new transmission, the UE's MAC entity can perform multiplexing and assembly of the MAC PDU, then generate the TB of the MAC PDU and pass it to the HARQ processing indicated in the UL authorization.

[0297] • Step 3b: If the transmission type is retransmission, the UE's MAC entity can pass the TB's UL authorization and HARQ information to the HARQ processing for retransmission.

[0298] • Step 4: The MAC entity can instruct the lower layer to initiate a UL transmission (e.g., initial transmission or retransmission).

[0299] In some example implementations of step 1 above, UL authorization can be identified as UL authorization for TYPE 1 transmission through at least one of the following solutions: • The serving cell and / or BWP for which UL authorization applies. In one example implementation, the serving cell / BWP may be configured with an indication that the serving cell / BWP is used for TYPE 1 transmission.

[0300] • A PDCCH timing location that receives UL authorization (e.g., a PDCCH search space). For example, a PDCCH timing location can be configured to schedule TYPE 1 transmissions that receive UL authorization.

[0301] • Receive UL-authorized PDCCH frequency positions (e.g., PDCCH CORESET). PDCCH frequency positions can be configured to schedule TYPE 1 transmissions, where UL authorization is received.

[0302] • The HARQ processing ID indicated in the UL authorization. For example, the HARQ processing indicated by this HARQ processing ID is configured for TYPE 1 transmission.

[0303] • An indication in the PDCCH of the UL-authorized address, used to indicate that the UL authorization is for TYPE 1 transmission.

[0304] • An indication configured in a logical channel or radio bearer to indicate that the data therein is a logical channel or radio bearer for TYPE 1 transmission. For example, a UL license can be implicitly determined as a UL license for TYPE 1 transmission by at least one of the following methods: ○ An LCH / RB factor mapping relationship may exist between the LCH / RB and the serving cell / BWP. The UL authorization of the mapped serving cell / BWP can be determined as the UL authorization for TYPE 1 transmission.

[0305] ○ An LCH / RB factor mapping relationship may exist between LCH / RB and HARQ processing. The UL authorization of a mapped HARQ processing can be determined as the UL authorization for TYPE 1 transmission.

[0306] In some example implementations of step 2 for retransmission scenarios, the UL-authorized addressed PDCCH may include an indication to retransmit, which may be at least one of the following: • HARQ processing indication: Used to indicate which HARQ processing is scheduled as a retransmission.

[0307] • Retransmission granularity level indicator: Used to indicate the retransmission granularity level. For example, a retransmission can be for the part of the MAC PDU that requires HARQ operation, for the part of the MAC PDU that does not require HARQ operation, or for the entire MAC PDU.

[0308] • HARQ group indication: Used to indicate which HARQ group in the MAC PDU that requires HARQ operation is scheduled for retransmission.

[0309] • Retransmission Indication: Used to indicate that such UL authorization is for a retransmission associated with the indicated HARQ processing ID and / or HARQ group. In one example implementation, the retransmission indication may be a switching NDI value compared with an NDI value received from a previous UL authorization of the indicated HARQ processing ID.

[0310] In some example implementations of step 3a above for generating the MAC PDU for initial transmission, the HARQ-related information of the MAC PDU (e.g., the HARQ header) can be appended to the header or the front of the control information section of the MAC PDU.

[0311] In some example implementations, the HARQ-related information (e.g., the HARQ header) of the MAC PDU may include at least one of the following information items: • The size of the portion of the MAC PDU that requires HARQ-related information (e.g., the header or control information section).

[0312] • Redundancy / check bits for HARQ-related operations on the parts of the MAC PDU that require HARQ-related operations.

[0313] In some example implementations of step 3a above for generating the MAC PDU for the initial transmission, the header or control information portion of the MAC PDU may be grouped / segmented into multiple groups (e.g., HARQ groups). HARQ-related information (e.g., HARQ headers) may be appended to the beginning of each HARQ group, or to the beginning of the header or control information portion of the MAC PDU.

[0314] In the above example implementation, the HARQ-related information (e.g., HARQ header) of a MAC PDU's HARQ group may include / indicate at least one of the following information items: • The number of HARQ groups for HARQ operations on the part of the MAC PDU that requires HARQ-related operations.

[0315] • The size of each HARQ group for HARQ operations on the part of the MAC PDU that requires HARQ-related operations.

[0316] • Redundancy / check bits for HARQ-related operations on each HARQ group.

[0317] In some example implementations of step 3b above, the retransmission may be for a portion of the MAC PDU that requires HARQ-related operations (e.g., the header or control signaling portion), or for a portion of the MAC PDU that does not require HARQ-related operations (e.g., the payload or source data block), or for the entire MAC PDU according to instructions from UL authorization.

[0318] In some example implementations of step 3b above, for generating a MAC PDU for retransmission, the MAC PDU stored in the HARQ processing buffer can be pushed into the multiplexing and assembly entity, and the MAC PDU can be regenerated by eliminating parts that do not require HARQ-related operations and / or parts that have been acknowledged.

[0319] In some example implementations, HARQ-related operations can be performed at the MAC layer if necessary. DL transfer can be implemented using the following example steps: • Step 1: The UE can determine whether the received DL allocation is for TYPE 1 transmission. If it is determined that the DL allocation is for TYPE 1 transmission, proceed to Step 2. Otherwise, the process ends.

[0320] • Step 2: The UE's MAC entity can handle DL allocation and determine the transmission type (e.g., initial transmission or retransmission).

[0321] • Step 3: The UE's MAC entity can assign one or more TBs received from the lower layer to HARQ processing.

[0322] • Step 4: The UE's MAC entity can attempt to decode the received TB(one) or more and check whether the MAC PDU includes additional HARQ-related information.

[0323] • Step 5a: If the received TB(one or more) cannot be decoded and / or the HARQ operation of the MAC PDU fails, the UE's MAC layer can instruct the lower layer to generate NACK signaling for the received TB.

[0324] • Step 5b: If the received (one or more) TBs are successfully decoded and the MAC PDU successfully passes the HARQ operation, the UE's MAC entity can pass the decoded MAC PDU to the deassembly and demultiplexing entity and instruct the lower layer to generate ACK signaling.

[0325] In some example implementations of step 1, the identifier for the DL allocation used for TYPE 1 transmission can be implemented in at least one of the following ways: • The DL allocates the serving cell and / or BWP to which it is targeted. In one example implementation, the serving cell / BWP may be configured with an indication that the serving cell / BWP is used for TYPE 1 transmission.

[0326] • Receive the PDCCH timing position assigned by the DL (e.g., the PDCCH search space). For example, the PDCCH timing position can be configured to schedule TYPE 1 transmissions, where the DL assignment is received.

[0327] • Receive the PDCCH frequency position (e.g., PDCCH CORESET) assigned by the DL. The PDCCH frequency position can be configured to schedule TYPE 1 transmissions, where the DL assignment is received.

[0328] • The HARQ processing ID indicated in the DL allocation. For example, the HARQ processing indicated by this HARQ processing ID is configured for TYPE 1 transport.

[0329] • An indication in the PDCCH of a DL allocation address, used to indicate that the DL allocation is for a TYPE 1 transfer.

[0330] • An indication configured in a logical channel or radio bearer to indicate that the data therein is a logical channel or radio bearer for TYPE 1 transmission. For example, a DL allocation can be implicitly determined as a UL license for TYPE 1 transmission by at least one of the following methods: ○ An LCH / RB factor mapping relationship may exist between the LCH / RB and the serving cell / BWP. The UL authorization of the mapped serving cell / BWP can be determined as the UL authorization for TYPE 1 transmission.

[0331] ○ An LCH / RB factor mapping relationship may exist between LCH / RB and HARQ processing. The UL authorization of a mapped HARQ processing can be determined as the UL authorization for TYPE 1 transmission.

[0332] In some example implementations of step 2, the retransmission may be a retransmission of the portion of the MAC PDU that requires HARQ-related operations (e.g., header information and / or control information), a retransmission of the portion of the MAC PDU that does not require HARQ-related operations (e.g., source data block or payload), or a retransmission of the entire MAC PDU (e.g., both the portion requiring HARQ-related operations and the portion that does not require HARQ-related operations).

[0333] In some example implementations of step 2 for retransmission scenarios, the PDCCH addressed by the DL allocation may include an indication to retransmit, which may be at least one of the following: • HARQ processing indication: Used to indicate which HARQ processing is scheduled as a retransmission.

[0334] • Retransmission granularity level indicator: Used to indicate the retransmission granularity level. For example, a retransmission can be for the part of the MAC PDU that requires HARQ operation, for the part of the MAC PDU that does not require HARQ operation, or for the entire MAC PDU.

[0335] • CBG Indicator: A CBG used to indicate a portion of a MAC PDU that requires HARQ operation and is scheduled for retransmission. In one implementation, the CBG indicator may optionally appear in the PDCCH, and may only appear in the PDCCH if the retransmission is for a portion of a MAC PDU that requires HARQ operation.

[0336] • Retransmission Indication: Used to indicate that such DL allocation is for retransmission associated with the indicated HARQ processing ID. In one example implementation, the retransmission indication may be a switching NDI value compared with an NDI value received from a previous UL authorization of the indicated HARQ processing ID.

[0337] In some example implementations of step 5a, the NACK signaling format can be implemented as one of the following: • PUCCH signaling format.

[0338] • PUSCH signaling format.

[0339] • UL MAC CE.

[0340] This signaling format may include at least one of the following information items: • HARQ handles IDs.

[0341] • Indication of MAC PDU section: Used to indicate which part of the MAC PDU failed to be received, such as the part that requires HARQ-related operation, or the part that does not require HARQ-related operation, or both.

[0342] • HARQ group indications for the portion of the MAC PDU that requires HARQ-related operations.

[0343] Error-free transmission and fault-tolerant transmission - switching between new and traditional transmission types In some example implementations, such as Figure 17 As shown, switching between new transport types (e.g., semantic transport) and traditional transport types (e.g., symbol-based transport) can be implemented on the network side, including the following example steps: • Step 1: Control signaling for activating / deactivating the new transmission HARQ operation can be received from the NW side.

[0344] • Step 2: The UE can activate / deactivate the HARQ operation of the new transmission according to the received control signaling.

[0345] In step 1, in one implementation, the control signaling can be implemented as lower-layer signaling (e.g., including an indicative PDCCH signaling used to indicate whether a HARQ operation is activated for a scheduled HARQ processing ID). In one implementation of this indication, a bit in the PDCCH can be used, where a value of "1" means that a HARQ operation can be activated for the transport schedule via the PDCCH, and a value of "0" means that a HARQ operation can be deactivated for the transport schedule via the PDCCH.

[0346] In some other example implementations of step 2 above, the control signaling can be upper-layer signaling, such as MACCE, SDAP / PDCP / RLC control PDU. Such control signaling can indicate or include at least one of the following information items: • Logical path indicator, used to indicate whether new data transmission from one or more logical paths is activated or deactivated. In one implementation, the logical path may be a radio bearer. In another implementation, the logical path may be a logical channel. In yet another implementation, the logical path may be an RLC entity, a PDCP entity, or an SDAP entity, or any combination thereof.

[0347] • Activation / deactivation indication, used to indicate the activation / deactivation of HARQ operations for the logical path indicated in the same control signaling.

[0348] • Serving Cell / BWP Indicator, used to indicate one or more serving cells in which new transmissions are activated or deactivated.

[0349] In some example implementations of step 2 above regarding the activation / deactivation of HARQ-related operations, if the received PDCCH indicates deactivation of a new type of transmission for the indicated HARQ processing, the lower layer can deactivate the HARQ-related operations for the data block or TB corresponding to the HARQ processing. Otherwise, the lower layer can activate the HARQ-related operations for the data block or TB corresponding to the indicated HARQ processing.

[0350] In some other example implementations of the activation / deactivation of HARQ operations in step 2 above, if the received control signaling indicates deactivation of a new type of transmission for the indicated logical path, the upper layer can deactivate HARQ-related operations for data transmission from the indicated logical path. Otherwise, the upper layer can activate HARQ-related operations for data blocks or TBs from the indicated logical path.

[0351] In some other example implementations of step 2 above regarding the activation / deactivation of HARQ operations, the activation / deactivation of HARQ operations can be performed by switching transport types (e.g., switching from TYPE 1 transport to TYPE 2 transport, or switching from TYPE 2 transport to TYPE 1 transport). The activation of a HARQ operation can be related to switching from TYPE 1 transport to TYPE 2 transport, while the deactivation of a HARQ operation can be related to switching from TYPE 2 transport to TYPE 1 transport. TYPE 1 transport and TYPE 2 transport have been defined above.

[0352] In some example implementations, such as Figure 18 As shown, switching between new transmission types (e.g., semantic transmission) and traditional transmission types (e.g., symbol-based transmission) can be implemented on the UE side, including the following example steps: • Step 1: The UE can receive the configuration for the new type of transmission (e.g., RRC configuration) from the NW.

[0353] • Step 2: The UE can begin performing one or more measurements for the new transmission and calculate transmission metrics.

[0354] • Step 3a: The UE can send a request to the NW to activate / deactivate the new transmission.

[0355] • Step 3b (an alternative to step 3a): The UE may send a notification to the NW to activate / deactivate the new transmission.

[0356] • Step 4: The UE can receive a response from the NW to the notification / request in step 3.

[0357] In some example implementations of step 1 above, the RRC configuration for the novel transmission may indicate or include at least one of the following information items: • A benchmark used by the UE to determine the activation / deactivation of new transmissions may include one of the following: SINR threshold / benchmark value, RSRP threshold / benchmark value, RSRQ threshold / benchmark value, or transmission failure rate / number of transmission failures threshold / benchmark value.

[0358] • The UE performs measurements to determine the activation / deactivation period of the new transmission, which may include at least one of a counter with a maximum value or a period of time used for measurement.

[0359] • Reference signaling (or signaling set) used for (one or more) measurements (e.g., CSI-RS, SSB, etc.).

[0360] In some example implementations of step 2 above, the UE can perform measurements on the reference signal of the new transmission. If the new transmission type is activated, and if the measurement result is below a threshold within a certain time period, the UE can determine that the new transmission of the HARQ processing / logic path needs to be deactivated.

[0361] In some example implementations of step 2 above, the UE can calculate the number / ratio of transmission failures over a period of time to determine the activation / deactivation of NW type transmissions in HARQ processing and / or logical paths. For example, the number / ratio of transmission failures can be calculated based on header information / control information. As another example, in the case of activating a new transmission type in HARQ processing or a logical path, if the number of transmission failures reaches a predefined maximum value within a certain time period, the UE can determine to deactivate the new transmission in HARQ processing or the logical path. In such implementations, a counter for tracking the number of transmission failures can be included, and the aforementioned timer period can be predetermined and defined.

[0362] In some example implementations of step 2 above, when activating HARQ processing or a new transmission of the logical path, if the failure transmission rate reaches a predefined maximum value within a certain time period, the UE can decide to deactivate HARQ processing or the new transmission of the logical path. In this implementation, two counters may be included to count the number of transmission failures. For example, one counter may be configured to count the total number of transmission failures, while the other counter may be configured to track the total number of transmission failures. The timer period can be predetermined and defined.

[0363] In some example implementations of step 2 above, the UE may perform one or more measurements on the reference signaling of the new transmission. If the measurement result is higher than a threshold within a certain time period after the new transmission type has been deactivated, the UE may determine the new transmission to activate the HARQ processing / logical path.

[0364] In some example implementations of step 3 above, the request / notification message may take at least one of the following formats: • Upper-layer signaling, including UL RRC signaling for, for example, UE auxiliary information, or UL MAC CE, SDAP / PDCP / RLC control PDU.

[0365] • Lower-layer signaling, including PUCCH signaling, PUSCH signaling, etc.

[0366] In some example implementations of step 3 above, the request / notification message may indicate and / or include at least one of the following information items: • A logical path indicator used to indicate the logical path in which a new type of transport needs to be activated / deactivated.

[0367] • HARQ processing instructions, used to indicate where HARQ processing for new types of transports needs to be activated / deactivated.

[0368] • Activation / deactivation indication, used to indicate the activation / deactivation of new transmissions in the indicated HARQ process and / or logical path.

[0369] In some example implementations of step 4 above, the response message from the NW may be control signaling for activating / deactivating HARQ processing and / or new transmissions of logical paths.

[0370] The above description and accompanying drawings provide specific example embodiments and implementations. However, the described subject matter can be implemented in a variety of different forms, and therefore, the covered or claimed subject matter is intended to be construed as not being limited to any of the example embodiments set forth herein. A reasonably broad scope is intended for the claimed or covered subject matter. In particular, for example, the subject matter can be implemented as a method, apparatus, component, system, or non-transitory computer-readable medium for storing computer code. Thus, embodiments can take the form, for example, hardware, software, firmware, storage medium, or any combination thereof. For example, the above-described method embodiments can be implemented by a component, apparatus, or system including a memory and a processor by executing computer code stored in the memory.

[0371] Throughout the specification and claims, terms may have subtly different suggested or implied meanings in the context, in addition to their expressly stated meanings. Similarly, the phrase "in one embodiment / implementation" as used herein does not necessarily refer to the same embodiment, and the phrase "in another embodiment / implementation" as used herein does not necessarily refer to different embodiments. For example, the claimed subject matter is intended to include, in whole or in part, combinations of exemplary embodiments.

[0372] Generally, terms can be understood at least in part from their use in context. For example, terms used herein, such as “and,” “or,” or “and / or,” can include a variety of meanings that can depend at least in part on the context in which they are used. Typically, “or,” when used in a list of associations (such as A, B, or C), is intended to mean A, B, and C (here used in an inclusive sense) and A, B, or C (here used in an exclusive sense). Furthermore, the term “one or more,” as used herein, depends at least in part on the context and can be used to describe any feature, structure, or characteristic in a singular sense, or can be used to describe a combination of features, structures, or characteristics in a plural sense. Similarly, terms such as “a,” “an,” or “the,” depending at least in part on the context, can be understood to convey either a singular or a plural usage. Moreover, the term “based on” can be understood not necessarily to convey an exclusive set of factors, but rather, also depending at least in part on the context, can allow for additional factors that are not necessarily explicitly described.

[0373] References to features, advantages, or similar language throughout this specification do not imply that all features and advantages achievable using this solution should be included in any single implementation thereof. Rather, references to such features and advantages are to be understood as meaning that a particular feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of this solution. Therefore, throughout this specification, discussions of features and advantages and similar language may, but do not necessarily, refer to the same embodiment.

[0374] Furthermore, in one or more embodiments, the described features, advantages, and characteristics of this solution can be combined in any suitable manner. Those skilled in the art will recognize that, based on the description herein, this solution can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages that may not be present in all embodiments of this solution may be recognized in certain embodiments.

Claims

1. A method executed by a wireless terminal for establishing and controlling a service data stream between the wireless terminal and a network node in a wireless network, comprising: A request to transmit a service data stream to the network node, the request including at least a service type indicator indicating whether the service data stream is transmitted without errors or with fault tolerance; Receive response and service data stream configuration from the network node; as well as According to the service data flow configuration, establish the service data flow with the wireless network.

2. The method according to claim 1, wherein, The request also includes at least one of the following: A quantization indicator is used to indicate the scenario in which the service data stream of the requested service type indicated by the service type indicator is allowed; or A Quality of Service (QoS) indicator is used to indicate the QoS requirements of the service data stream.

3. The method according to claim 2, wherein, The quantization indicator includes at least one of the following: signal-to-noise ratio (SINR) value, reference signal received quality (RSRQ) value, reference signal received power (RSRP) value, or transmission failure rate value.

4. The method according to claim 1, wherein, The response and the service data stream configuration include at least one of the following: Acknowledgment (ACK) or negative acknowledgment (NACK) of the request for the service data stream. The identifier of the service data stream; or Quantization configuration is used to indicate scenarios in which fault-tolerant transmission of the service data stream is allowed or enabled.

5. The method according to claim 4, wherein, The quantization configuration includes at least one of the following: SINR value, RSRQ value, RSRP value, or transmission failure rate value.

6. The method according to claim 1, wherein, The network node includes the core network node of the wireless network, and the request and the response are carried by NAS signaling that is transparent to the radio access network (RAN) connecting the wireless terminal and the core network node.

7. The method according to claim 1, wherein, The network nodes include RAN nodes, and the requests and responses are carried by RRC signaling, PDCP control PDUs, RLC control PDUs, MAC CEs, or physical layer control signaling.

8. The method according to claim 1 further includes: Based on the service data flow configuration, a first sub-communication flow and a second sub-communication flow of the service data flow are established, wherein the first sub-communication flow and the second sub-communication flow correspond to error-free data transmission and fault-tolerant data transmission, respectively; The data service stream is transmitted through one of the first sub-communication stream and the second sub-communication stream; Send a switching request to the network node to switch the data service stream to another sub-communication stream between the first sub-communication stream and the second sub-communication stream; Receive confirmation of the handover request from the network node; as well as Switch the data service stream to another sub-communication stream between the first sub-communication stream and the second sub-communication stream.

9. The method according to claim 8, wherein, Each of the first sub-communication stream and the second sub-communication stream includes a PDU session.

10. The method according to claim 9, wherein, Each of the first sub-communication stream and the second sub-communication stream includes a QoS stream.

11. The method according to claim 9, wherein, Each of the first sub-communication stream and the second sub-communication stream includes a QoS sub-stream.

12. A method executed by a wireless network node for establishing and controlling a service data stream between a wireless terminal in a wireless network and the wireless network node, comprising: Receive a request for a service data stream from the wireless terminal, the request including at least a service type indicator for indicating whether the service data stream is error-free or fault-tolerant transmission; In response to the request, generate and send a response and service data stream configuration to the wireless terminal; as well as According to the service data stream configuration, establish the service data stream with the wireless terminal.

13. The method according to claim 12, wherein, The request also includes at least one of the following: A quantization indicator is used to indicate the scenario in which the service data stream of the requested service type indicated by the service type indicator is allowed; or A Quality of Service (QoS) indicator is used to indicate the QoS requirements of the service data stream.

14. The method according to claim 13, wherein, The quantization indicator includes at least one of the following: signal-to-noise ratio (SINR) value, reference signal received quality (RSRQ) value, reference signal received power (RSRP) value, or transmission failure rate value.

15. The method according to claim 12, wherein, The response and the service data stream configuration include at least one of the following: Acknowledgment (ACK) or negative acknowledgment (NACK) of the request for the service data stream. The identifier of the service data stream; or Quantization configuration is used to indicate scenarios in which fault-tolerant transmission of the service data stream is allowed or enabled.

16. The method according to claim 15, wherein, The quantization configuration includes at least one of the following: SINR value, RSRQ value, RSRP value, or transmission failure rate value.

17. The method according to claim 12, wherein, The wireless network node includes the core network node of the wireless network, and the request and the response are carried by NAS signaling that is transparent to the radio access network (RAN) connecting the wireless terminal and the core network node.

18. The method according to claim 12, wherein, The wireless network node includes a RAN node, and the request and the response are carried by RRC signaling, PDCP control PDU, RLC control PDU, MAC CE, or physical layer control signaling.

19. The method of claim 12, further comprising: Based on the service data flow configuration, a first sub-communication flow and a second sub-communication flow of the service data flow are established, wherein the first sub-communication flow and the second sub-communication flow correspond to error-free data transmission and fault-tolerant data transmission, respectively; The data service stream is received through one of the first sub-communication stream and the second sub-communication stream; Receive a handover request from the wireless network node for switching the data service stream to another sub-communication stream between the first sub-communication stream and the second sub-communication stream; The confirmation information for the handover request is transmitted to the wireless terminal; This enables the wireless terminal to switch the data service stream to another sub-communication stream between the first sub-communication stream and the second sub-communication stream.

20. The method according to claim 19, wherein, Each of the first sub-communication stream and the second sub-communication stream includes a PDU session.

21. The method according to claim 20, wherein, Each of the first sub-communication stream and the second sub-communication stream includes a QoS stream.

22. The method according to claim 20, wherein, Each of the first sub-communication stream and the second sub-communication stream includes a QoS sub-stream.

23. The wireless terminal or the wireless network node according to any one of claims 1-22, wherein the wireless terminal or the wireless network node comprises a processor and a memory, wherein, The processor is configured to read computer code from the memory to cause the wireless terminal or the wireless network node to perform the method according to any one of claims 1-22.

24. A computer program product comprising a non-transitory computer-readable program medium having computer code stored thereon, the computer code causing the processor to implement the method according to any one of claims 1-22 when executed by a processor of the wireless terminal or the network node according to any one of claims 1-22.

Images