WO2025156232A1

WO2025156232A1 - A method for a new type of data transmission in wireless network

Info

Publication number: WO2025156232A1
Application number: PCT/CN2024/074127
Authority: WO
Inventors: Fei DONG; He Huang; Jing Liu; Nan Zhang
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2024-01-25
Filing date: 2024-01-25
Publication date: 2025-07-31
Anticipated expiration: 2026-07-25

Abstract

This disclosure is directed generally to wireless communication networks and particularly to network architectures for effectuating a new type data transmission or communication for information with transmission error-tolerance, such as semantic communication. Specifically, several aspects in wireless network architecture and signaling are disclosed for realizing the new type data transmission between a wireless terminal and a wireless network. Modification to legacy wireless systems are implemented in order to accommodate source encoder/decoder models, their management, and their activation/deactivation based on model performances and network channel conditions. Data within such a new type data communication may be bifurcated into error-free data and error-tolerant data which may be processed distinctively by the modified wireless network.

Description

A METHOD FOR A NEW TYPE OF DATA TRANSMISSION IN WIRELESS NETWORK

TECHNICAL FIELD

This disclosure is directed generally to wireless communication networks and particularly to network architectures for effectuating a new type data transmission or communication in the wireless communication networks.

BACKGROUND

Legacy wireless communication systems are suitable for faithfully transmitting source information in forms of a collection of physical bits or symbols through various network protocol levels, error correction mechanisms, and transmission and retransmission schemes. For some source information, its faithful transmission may not be necessary. A new type data transmission or communication methodology may be adopted for transmitting such error-tolerant information. For example, such a new type data transmission may be implemented to communicate such source information semantically.

SUMMARY

In some example implementations, a method performed by a wireless terminal in communication with a network node in a wireless network is disclosed. The method may include receiving a configuration from the network node for managing a set of semantic models, the set of semantic models comprising at least one terminal side encoding model and at least one network side decoding model; receiving a first control signaling from the network node for activating the set of semantic models for a semantic communication between the wireless terminal and the wireless network; receiving reference data from the network node; monitoring a performance of the semantic communication and generating a set of performance metrics for the semantic communication based on the monitored performance and the reference data; transmitting the set of performance metrics to the network node; and receiving a second control signaling from the network node generated by the network node in response to the set of performance metrics to effectuate a modification of an operation of the at least one terminal side encoding model or a provisioning of a transmission channel for the semantic communication.

In some other example implementations, a method performed by a wireless terminal in communication with a network node in a wireless network is disclosed. The method may include receiving a configuration from the network node for managing a set of semantic models, the set of semantic models comprising at least one terminal side encoding model and at least one network side decoding model; receiving a first control signaling from the network node for activating the set of semantic models for a semantic communication between the wireless terminal and the wireless network; transmitting reference data to the network node; receiving a second control signaling from the network node generated by the network node in response to a set of performance metrics for the semantic communication calculated by the network node based on comparing a set of monitored performance of the semantic communication to the reference data; and effectuate a modification of an operation of the at least one terminal side encoding model or a provisioning of a transmission channel for the semantic communication based on the second control signaling.

In some other example implementations, a method performed by a network node in communication with a wireless terminal in a wireless network is disclosed. The method may include transmitting a configuration to the wireless terminal for managing a set of semantic models, the set of semantic models comprising at least one terminal side encoding model and at least one network side decoding model; transmitting a first control signaling to the wireless terminal for activating the set of semantic models for a semantic communication between the wireless terminal and the wireless network; transmitting reference data to the wireless terminal; receiving a set of performance metrics of the semantic communication from the wireless terminal, the set of performance metrics of the semantic communication being generated by the wireless terminal based on a performance of the semantic communication monitored by the wireless terminal and the reference data; generating a second control signaling in response to the set of performance metrics; and transmitting a second control signaling to the wireless terminal to effectuate a modification of an operation of the at least one terminal side encoding model or a provisioning of a transmission channel for the semantic communication.

In some other example implementations, a method performed by a network node in communication with a wireless terminal in a wireless network is disclosed. The method may include transmitting a configuration from the network node for managing a set of semantic models, the set of semantic models comprising at least one terminal side encoding model and at least one network side decoding model; transmitting a first control signaling from the network node for activating the set of semantic models for a semantic communication between the wireless terminal and the wireless network; receiving reference data from the wireless terminal; monitoring a performance of the semantic communication and generating a set of performance metrics for the semantic communication based on the monitored performance and the reference data; generating a second control signaling in response to the set of performance metrics; and transmitting the second control signaling to the wireless terminal to effectuate a modification of an operation of the at least one terminal side encoding model or a provisioning of a transmission channel for the semantic communication based on the second control signaling.

In any one of the example implementations above, the network node comprises a core network node.

In any one of the example implementations above, the configuration is sent via a protocol tunnel between the core network node and a non-access stratum layer of the wireless terminal.

In any one of the example implementations above, the protocol tunnel is transparent to a radio access network that connects the wireless terminal to the core network node.

In any one of the example implementations above, the core network node comprises a semantic communication manage function (SCMF) of the core network.

In any one of the example implementations above, the SCMF is configured to perform at least one of:a model management for the semantic communication; decoding and/or encoding of user-plane (UP) data for the semantic communication from a User Plane Function (UPF) of the core network or the wireless terminal; regulation of Quality of Service (QoS) flows of the semantic communication; regulation of PDU sessions associated with the semantic communication; transmission and/or reception of data units for the semantic communication; or. subheader attachment/detachment to data units for the semantic communication.

In any one of the example implementations above, the first control signaling and/or the second control signaling are sent by an Access Management Function (AMF) of the core network.

In any one of the example implementations above, the network node is base station.

In any one of the example implementations above, the configuration is transmitted via a Radio Resource Control (RRC) message.

In any one of the example implementations above, the first control signaling and second control signaling are transmitted via one of an RRC message, a Package Data Convergence Protocol (PDCP) control Protocol Data Unit (PDU) , a Radio Link Control (RLC) control PDU, a Media Access Control (MAC) Control Element (MAC CE) , or a physical layer control signaling.

In any one of the example implementations above, the set of performance metrics are transmitted via one of an RRC message, a PDCP control PDU, an RLC control PDU, a MAC CE, or a physical layer control signaling.

In any one of the example implementations above, the reference data are transmitted via one of an RRC message, a PDCP control PDU, an RLC control PDU, a MAC CE, or a physical layer control signaling.

In any one of the example implementations above, the reference data comprises a set of benchmark data or a set of benchmark data pairs for accessing the performance of the semantic communication.

In any one of the example implementations above, the reference data is signaled via a protocol tunnel.

In any one of the example implementations above, the reference data originates from a pre-stored database or generated from a real transmission.

In any one of the example implementations above, the first control signaling comprises at least one of:a model identity for the at least one terminal side encoding model; a model description information item for the at least one terminal side encoding model; a PDU session ID for the semantic communication; a Quality of Service (QoS) flow ID for the semantic communication; a logic channel (LCH) ID for the semantic communication; or a Data Radio Bearer ID for the semantic communication.

The wireless terminal or network node of any one of the methods above is disclosed. 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 the network node to perform the method of any one of the methods above.

A non-transitory computer-readable program medium with computer code stored thereupon is further disclosed. The computer code, when executed by a processor of the wireless terminal or network node of any one of the methods above, is configured to cause the processor to implement any one of the methods above.

The above embodiments and other aspects and alternatives of their implementations are described in greater detail in the drawings, the descriptions, and the claims below.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example wireless communication network including a wireless access network, a core network, and data networks.

FIG. 2 illustrates an example wireless access network including a plurality of mobile stations/terminals or User Equipments (UEs) and a wireless access network node in communication with one another via an over-the-air radio communication interface.

FIG. 3 shows an example radio access network (RAN) architecture.

FIG. 4 shows an example communication protocol stack in a wireless access network node or wireless terminal device including various network layers.

FIG. 5 illustrates an example architecture for wireless semantic communication.

FIG. 6 illustrates another example architecture for wireless semantic communication.

FIG. 7 illustrates an example procedure for configuring and managing semantic models for wireless semantic communication.

FIG. 8 illustrates another example procedure for configuring and managing semantic models for wireless semantic communication.

FIG. 9 illustrates another example architecture for wireless semantic communication.

FIG. 10 illustrates another example procedure for configuring and managing semantic models for wireless semantic communication.

FIG. 11 illustrates another example procedure for configuring and managing semantic models for wireless semantic communication.

FIG. 12 illustrates an example procedure for data flow control for semantic communication.

FIG. 13 illustrates another example procedure for data flow control for semantic communication.

FIG. 14 illustrates an example procedure for uplink and downlink semantic transmission.

FIG. 15 illustrates an example protocol header configuration.

FIG. 16 illustrates an example Media Access Control (MAC) Protocol Date Unit (PDU) for semantic configuration.

FIG. 17 illustrates an example switching between semantic communication and legacy communication as controlled by the network side.

FIG. 18 illustrates an example switching between semantic communication and legacy communication as controlled by the terminal side.

DETAILED DESCRIPTION

The present disclosure will now be described in detail hereinafter with reference to the accompanied drawings, which form a part of the present disclosure, and which show, by way of illustration, specific examples of embodiments. The present disclosure may, however, be embodied 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 embodiments to be set forth below.

Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in one embodiment” or “in some embodiments” as used herein does not necessarily refer to the same embodiment and the phrase “in another embodiment” or “in other embodiments” as used herein does not necessarily refer to a different embodiment. The phrase “in one implementation” or “in some implementations” as used herein does not necessarily refer to the same implementation and the phrase “in another implementation” or “in other implementations” as used herein does not necessarily refer to a different implementation. It is intended, for example, that claimed subject matter includes combinations of exemplary embodiments or implementations in whole or in part.

In general, terminology may be understood at least in part from usage in context. For example, terms, such as “and” , “or” , or “and/or, ” as used herein may include a variety of meanings that may depend at least in part upon the context in which such terms are used. Typically, “or” if used to associate a list, such as A, B or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B or C, here used in the exclusive sense. In addition, the term “one or more” or “at least one” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as “a” , “an” , or “the” , again, may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” or “determined by” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for existence of additional factors not necessarily expressly described, again, depending at least in part on context.

Legacy Wireless Network Overview

An example wireless communication network, shown as 100 in FIG. 1, may include wireless terminal devices or user equipment (UE) 110, 111, and 112, a carrier network 102, various service applications 140, and other data networks 150. The wireless terminal devices or UEs, may be alternatively referred to as wireless terminals. The carrier network 102, for example, may include access network nodes 120 and 121, and a core network 130. The carrier network 110 may be configured to transmit voice, data, and other information (collectively referred to as data traffic) among UEs 110, 111, and 112, between the UEs and the service applications 140, or between the UEs and the other data networks 150. The access network nodes 120 and 121 may be configured as various wireless access network nodes (WANNs, alternatively referred to as wireless base stations) to interact with the UEs on one side of a communication session and the core network 130 on the other. The term “access network” may be used more broadly to refer a combination of the wireless terminal devices 110, 111, and 112 and the access network nodes 120 and 121. A wireless access network may be alternatively referred to as Radio Access Network (RAN) . The core network 130 may include various network nodes configured to control communication sessions and perform network access management and traffic routing. The service applications 140 may be hosted by various application servers deployed outside of but connected to the core network 130. Likewise, the other data networks 150 may also be connected to the core network 130.

In the example wireless communication network of 100 of FIG. 1, the UEs may communicate with one another via the wireless access network. For example, UE 110 and 112 may be connected to and communicate via the same access network node 120. The UEs may communicate with one another via both the access networks and the core network. For example, UE 110 may be connected to the access network node 120 whereas UE 111 may be connected to the access network node 121, and as such, the UE 110 and UE 111 may communicate to one another via the access network nodes 120 and 121, and the core network 130. The UEs may further communicate with the service applications 140 and the data networks 150 via the core network 130. Further, the UEs may communicate to one another directly via side link communications, as shown by 113.

FIG. 2 further shows an example system diagram of the wireless access network 120 including a WANN 202 serving UEs 110 and 112 via the over-the-air interface 204. The wireless transmission resources for the over-the-air interface 204 include a combination of frequency, time, and/or spatial resource. Each of the UEs 110 and 112 may be a mobile or fixed terminal device installed with mobile access units such as SIM/USIM modules for accessing the wireless communication network 100. The UEs 110 and 112 may each be implemented as a terminal device including but not limited to a mobile phone, a smartphone, a tablet, a laptop computer, a vehicle on-board communication equipment, a roadside communication equipment, a sensor device, a smart appliance (such as a television, a refrigerator, and an oven) , or other devices that are capable of communicating wirelessly over a network. As shown in FIG. 2, each of the UEs such as UE 112 may include transceiver circuitry 206 coupled to one or more antennas 208 to effectuate wireless communication with the WANN 120 or with another UE such as UE 110. The transceiver circuitry 206 may also be coupled to a processor 210, which may also be coupled to a memory 212 or other storage devices. The memory 212 may be transitory or non-transitory and may store therein computer instructions or code which, when read and executed by the processor 210, cause the processor 210 to implement various ones of the methods described herein.

Similarly, the WANN 120 may include a wireless base station or other wireless network access point capable of communicating wirelessly via the over-the-air interface 204 with one or more UEs and communicating with the core network 130. For example, the WANN 120 may be implemented, without being limited, in the form of a 2G base station, a 3G nodeB, an LTE eNB, a 4G LTE base station, a 5G NR base station of a 5G gNB, a 5G central-unit base station, a 5G distributed-unit base station, a 6G base station, another type of secular base station, or cell-free access points. Each type of these WANNs may be configured to perform a corresponding set of wireless network functions. The WANN 202 may include transceiver circuitry 214 coupled to one or more antennas 216, which may include an antenna tower 218 in various forms, to effectuate wireless communications with the UEs 110 and 112. The transceiver circuitry 214 may be coupled to one or more processors 220, which may further be coupled to a memory 222 or other storage devices. The memory 222 may be transitory or non-transitory and may store therein instructions or code that, when read and executed by the one or more processors 220, cause the one or more processors 220 to implement various functions of the WANN 120 described herein.

Data packets in a wireless access network such as the example described in FIG. 2 may be transmitted as protocol data units (PDUs) . The data included therein may be packaged as PDUs at various network layers wrapped with nested and/or hierarchical protocol headers. The PDUs may be communicated between a transmitting device or transmitting end (these two terms are used interchangeably) and a receiving device or receiving end (these two terms are also used interchangeably) once a connection (e.g., a radio link control (RRC) connection) is established between the transmitting and receiving ends. Any of the transmitting device or receiving device may be either a wireless terminal device such as device 110 and 120 of FIG. 2 or a wireless access network node such as node 202 of FIG. 2. Each device may both be a transmitting device and receiving device for bi-directional communications.

The core network 130 of FIG. 1 may include various network nodes geographically distributed and interconnected to provide network coverage of a service region of the carrier 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 as software entities. These network nodes may each be configured with one or more types of network functions which collectively provide the provisioning and routing functionalities of the core network 130.

Returning to wireless radio access network (RAN) , FIG. 3 illustrates an example RAN 340 in communication with a core network 310 and wireless terminals UE1 to UE7. The RAN 340 may include one or more various types of wireless base station or WANNs 320 and 321 which may include but are not limited to gNB, eNodeB, NodeB, or other type of base stations. The RAN 340 may be backhauled to the core network 310. The WANNs 320, for example, may further include multiple separate access network nodes in the form of a Central Unit (CU) 322 and one or more Distributed Unit (DU) 324 and 326. The CU 322 is connected with DU1 324 and DU2 326 via various interfaces, for example, an F1 interface. The F1 interface, for example, may further include an F1-C interface and an F1-U interface, which may be used to carry control plane information and user plane data, respectively. In some embodiments, the CU may be a gNB Central Unit (gNB-CU) , and the DU may be a gNB Distributed Unit (gNB-DU) . While the various implementations described below are provided in the context of a 5G cellular wireless network, the underlying principles described herein are applicable to other types of radio access networks including but not limited to other generations of cellular network, as well as Wi-Fi, Bluetooth, ZigBee, and WiMax networks.

The UEs may be connected to the network via the WANNs 320 over an air interface. The UEs may be served by at least one cell. Each cell is associated with a coverage area. These cells may be alternatively referred to as serving cells. The coverage areas between cells may partially overlap. Each UE may be actively communicating with at least one cell while may be potentially connected or connectable to more than one cell. In the example of FIG. 1, UE1, UE2, and UE3 may be served by cell1 330 of the DU1, whereas UE4 and UE5 may be served by cell2 332 of the DU1, and UE6 and UE7 may be served by cell3 associated with DU2. In some implementations, a UE may be served simultaneously by two or more cells. Each of the UE may be mobile and the signal strength and quality from the various cells at the UE may depend on the UE location and mobility.

In some example implementations, the cells shown in FIG. 3 may be alternatively referred to as serving cells. The serving cells may be grouped into serving cell groups (CGs) . A serving cell group may be either a Master CG (MCG) or Secondary CG (SCG) . Within each type of cell groups, there may be one primary cell and one or more secondary cells. A primary cell in a MSG, for example, may be referred to as a PCell, whereas a primary cell in a SCG may be referred to as PScell. Secondary cells in either an MCG or an SCG may be all referred to as SCell. The primary cells including PCell and PScell may be collectively referred to as spCell (special Cell) . All these cells may be referred to as serving cells or cells. The term “cell” and “serving cell” may be used interchangeably in a general manner unless specifically differentiated. The term “serving cell” may refer to a cell that is serving, will serve, or may serve the UE. In other words, a “serving cell” may not be currently serving the UE. While the various embodiment described below may at times be referred to one of the types of serving cells above, the underlying principles apply to all types of serving cells in both types of serving cell groups.

FIG. 4 further illustrates a simplified view of the various network layers involved in transmitting user-plane PDUs from a transmitting device 402 to a receiving device 404 in the example wireless access network of FIGs. 1-3. FIG. 4 is not intended to be inclusive of all essential device components or network layers for handling the transmission of the PDUs. FIG. 4 illustrates that the data packaged by upper network layers 420 at the transmitting device 402 may be transmitted to corresponding upper layer 430 (such as radio resource control or RRC layer) at the receiving device 304 via Packet Data Convergence Protocol layer (PDCP layer, not shown in FIG. 4) and radio link control (RLC) layer 422 and of the transmitting device, the physical (PHY) layers of the transmitting and receiving devices and the radio interface, as shown as 406, and the media access control (MAC) layer 434 and RLC layer 432 of the receiving device. Various network entities in each of these layers may be configured to handle the transmission and retransmission of the PDUs.

In FIG. 4, the upper layers 420 may be referred as layer-3 or L3, whereas the intermediate layers such as the RLC layer and/or the MAC layer and/or the PDCP layer (not shown in FIG. 4) may be collectively referred to as layer-2, or L2, and the term layer-1 is used to refer to layers such as the physical layer and the radio interface-associated layers. In some instances, the term “low layer” may be used to refer to a collection of L1 and L2, whereas the term “high layer” may be used to refer to layer-3. In some situations, the term “lower layer” may be used to refer to a layer among L1, L2, and L3 that are lower than a current reference layer. Control signaling may be initiated and triggered at each of L1 through L3 and within the various network layers therein. These signaling messages may be encapsulated and cascaded into lower layer packages and transmitted via allocated control or data over-the-air radio resources and interfaces. The term “layer” generally includes various corresponding entities thereof. For example, a MAC layer encompasses corresponding MAC entities that may be created. The layer-1, for example, encompasses PHY entities. The layer-2, for another example encompasses MAC layers/entities, RLC layers/entities, service data adaptation protocol (SDAP) layers and/or PDCP layers/entities.

The various system components above for the various wireless communication networks may be, for example, adopted, enhanced, or modified to realize the example communication system for a new type data transmission, such as semantic communication, as detailed below.

New Type Data Transmission such as Semantic Communications

The wireless communication systems described above are suitable for transmitting source information in form of a collection of physical bits or symbols through the various network protocol levels, error detection/correction mechanisms, and transmission/retransmission schemes from an origin network node to a destination network node. Such a communication system may be referred to as a level 1 transmission system.

Specifically, according to basic information theory, information processing and communications systems may be characterized as solving problems that may be categorized into the following three levels:

● Level 1: solutions to physical information transport for handling transmission of source bits or symbols with a certain level of accuracy;

● Level 2: solutions to semantic information transport for transmission of source semantics with a certain level of accuracy.

● Level 3: Solutions related to transport efficiency issue (e.g., how efficiently does the received meaning affect conduct in the desired way) .

In such context, the current wireless communication protocol described above is aiming to handle the Level 1 issues or problems, namely, bit/symbol level transmission with certainly level of accuracy (e.g., error-free) . As the channel limit for bit/symbol level transmission is reached by current physical technologies, higher transmission throughput may only be achievable by expanding the available spectral and time transmission resources or channels for network evolution based on level-1 solutions. Level-2 error-tolerant transmission, for example, semantic communications, on the other hand, may help achieve improved overall information transmission via semantic encoding of the source information at a transmitting end and semantic decoding of received semantic information at the receiving end. The semantic encoding and decoding, for example, may be closely related to the evolving artificial intelligence (AI) and/or machine learning (ML) technologies related to, merely as an example, natural language processing (e.g., NLP) for encoding textual information. As such, there may be another direction to improve effective capacity of the NW with the same level-1 channel transmission throughput, that is, to transfer the semantic meaning instead of the whole information symbols.

In some example implementations, for transferring the semantic meaning/information, a two-sided AI/ML model architecture may be considered, one side for encoding/compressing the original information into semantic information, and the other side for decoding /decompressing semantic information into original information. Such AI/ML based encoding/decoding may be referred to as source/destination encoding/decoding, or semantic encoding/decoding. While the semantic encoding/decoding mainly aims to generate fewer bits and less symbol information to transfer, whereas the channel encoding/decoding technology is aimed at improving the robustness of the information transfer by adding redundant information to the original, a joint semantic and channel encoding/decoding may be designed to provide more benefits from the overall semantic communication.

While the current NW protocol for wireless communications as described above has been designed for handling the level 1 problems, the disclosure below is aiming at describing how to embed the functionality of supporting a new type data transmission, such as error-tolerant data transmission (e.g., semantic communication) into the current NW protocol, and how to evolve the current NW protocol to adapt to such a new type data communication.

While the disclosure uses semantic communication as an example, the disclosed underlying principles applies generally to error-tolerant data communication and other manners of the new type data communication.

In some example implementations, for realizing a joint semantic source coding and channel coding, one or more of the following options regarding locations of source coding/decoding module in the wireless communication network may be considered:

● In one example implementation for DL transmission/reception, the semantic source encoder may be located at the NW side, and the semantic source decoder may be located at the UE side.

● In one example implementation for UL transmission/reception, the semantic source encoder may be located at the UE side, and the semantic source decoder is located at the NW side.

● In one example implementation, the semantic source encoder may function as an AI/ML model for processing the source data, the input of the AI/ML model may be the original data, and the output of the AI/ML model may be the encoded or compressed data of the original data.

● In one example implementation, the semantic source decoder may function as an AI/ML model for processing input data comprising data as comprised by an AI/ML encoder and as transmitted by the wireless network, and an output of the AI/ML model may represent data decompressed from the compressed input data.

As one of the advantages of semantic communication described above, the source data can be drastically compressed by semantic encoder, thereby reducing the channel resources consumption for user plane (UP) data. For another example, there may be no need to perform the guaranteed error-free transmission for semantic communication since the semantically compressed data can be resumed at the receiving point even though some compressed data may be lost or incorrectly transmitted due to a poor channel state, as a result of a potential error recovery capability of AI/ML based semantic decoders. The various embodiments below for semantic communication implementations particular concern aspects for enhancing the current wireless communication protocols (e.g., the 3GPP protocols) including but not limited to (1) mechanisms for AI/ML model management, and (2) switching mechanism between a new type of communications and legacy communications, in order to maximally leverage the advantage of new type of communication. The new type of communications, for example, may refer to semantic communications.

AI/ML Model Management-General

In some example implementations, AL/ML models may be data specific (e.g., textual data, image data, speech data, etc. ) , in terms of either or both of model architecture and trained model parameters. These AI/ML models may be trained for coding/compression and decoding/decompression of the source data of deferent types. The AI/ML models as trained may be deployed at different locations or network nodes or network levels in the wireless network for effectuating semantic communications. Examples for architecture and deployment of AI/ML models in the communication network are shown in FIGs. 5, 6 and 9.

In the example implementation of FIG. 5, the AI/ML models for semantic source encoding may be deployed at application layer 502 on the UE side 501 and correspondingly in an application server 504 on the network side 503. Management of the models may be performed between the application layer 502 and application server 504. Such management may be implementation dependent and may thus be transparent to the other lower network layers, including the NAS layer 510 and the AS layer 512 on the UE side, the wireless access network 522 and core network 520 on the network side, and the transmission physical channels 530.

In the example implementation of FIG. 6, the AI/ML models for semantic source coding may be deployed at the NAS layer 610 on the UE side 601 and the core network (CN) 620 on the network side 603. Management of the models may be performed between the NAS layer 610 and the core network 620 via NAS signaling exchanges. Such management may be implemented by network service providers via the wireless network rather than user devices and application server (and thus can be centralized and shared by different application providers) and may thus be transparent to the lower network layers, including the AS layer 612 on the UE side, the wireless access network 620 on the network side, and the transmission physical channels 630.

An example implementation for managing the AI/ML models between the NAS layer 610 and the CN 920 in the architecture of FIG. 6 is shown in FIG. 7, including the following example steps:

● STEP 1: The CN may send a configuration for model management to the UE.

● STEP 2: The CN may send to the UE a control signaling to activate an AI/ML model for the new transmission type.

● STEP 3: The CN may send to the UE a reference data and/or a request for performance monitoring of the new transmission type.

● STEP 4: The UE may perform the performance monitoring and calculate the performance metrics according to the configuration and received reference data.

● STEP 5: The UE may send the calculated performance metrics and/or model control request (s) to the CN.

● STEP 6: The CN may make a model management determination according to the received performance metrics and/or control request (s) .

● STEP 7: The CN may send to the UE the model control signaling to adjust the model status.

Another example implementation alternative to FIG. 7 for managing the AI/ML models between the NAS layer 610 and the CN 620 in the architecture of FIG. 6 is shown in FIG. 8, including the following example steps:

● STEP 1: The CN may send the configuration for model management to the UE.

● STEP 2: the CN may send a control signaling to activate the AI/ML model for the new transmission type (e.g., semantic communication) .

● STEP 3: The UE may send CN the reference data and/or request for performance monitoring of the new transmission type.

● STEP 4: The CN may calculate the performance metrics and make a model management decision according to the calculated metrics, if needed.

● STEP 5: The CN may send to the UE the model control signaling to adjust the model status.

The difference between the example implementations of FIG. 7 and FIG. 8 mainly concerns which network entity (the UE or the CN) provides reference data for performance monitoring and which entity performs the performance monitoring for the new transmission type.

With respect to the signaling of the configuration for model management for above two embodiments in FIGs. 7 and 8, in some example implementations, the signaling may be sent via a protocol tunnel (e.g., NTTP, representing New Type Transmission Protocol) between a logical function (e.g., Semantic Communication Management Function, or SCMF) residing at the CN and the NAS layer of UE. In some example implementations, the above protocol tunnel may be transparent to the base station of the wireless communication network (e.g., 622 of FIG. 6) . In some example implementations, the SCMF above may have an interface connecting to an SMF and/or UPF and/or AMF described above with respect to the example core network of various generations. In some further example implementations, the function of SCMF above may contain at least one of the following:

● The model management for the new type transmission (e.g., semantic transmission) .

● Decode/Encode the UP data for new type data transmission from the UPF or the UE.

● Regulation of QoS flow of the new type data transmission.

● Regulation of PDU session of the new type data transmission.

● Transmission/Reception of data unit for the new type data transmission.

● Subheader attachment/detachment to the data unit for the new type data transmission.

In some other example implementations, control signaling may be sent by the AMF from CN. In such example implementations, the AMF may be provided with an interface to the SCMF, and the AMF may be configured to support at least one of the following functions for new type data transmission:

● The model management for the new type data transmission (e.g., semantic transmission) .

● Regulation of QoS flow of the new type data transmission.

● Regulation of PDU session of the new type data transmission.

With respect to the signaling of reference data for performance monitoring, as described above for FIG. 7 and FIG. 8, in some example implementations, the reference data signaling may be an NTTP protocol signaling. In some example implementations, the reference data may be retrieved from a database for test or from a real transmission for determining a prediction validity or accuracy of the deployed AI/ML model. In some example implementations, the reference data may contain a set of benchmark data or benchmark data pairs (e.g., benchmark input data and benchmark output data) . Such benchmark data may be from a database for the model evaluation/test and/or performance monitoring. If reference data is a benchmark data, the reference data may be the input of the compressed part of the two-sided models. If reference data is a data pair, one of the data pair may be an input of either the UE part of two-sided model or the NW part of two-sided model that needs to be tested for validity or prediction accuracy. The other one of the data pair may be an output of either the UE part of two-sided model or the NW part of two-sided model that needs to be tested for validity or prediction accuracy. In some example implementations, the reference data may include data from real transmissions. In other words, the source/resumed data would be sent to the UE/CN by CN/UE for the performance monitoring.

With respect to the performance metrics calculation method, in some example implementations, the performance metrics can be obtained from a comparison between the benchmark reference output data and the output of either the UE part of two-side model or the NW part of the two-side model. The output of either the UE part of two-side model or the NW part of two-side model may be obtained from the reference input data along with the AI/ML model that needs performance monitoring. In some example implementations, the performance metrics can be obtained from a comparison between the reference data and the output of the decompressing/decoding part of AI/ML model. In this example implementation, the UE may be assumed to have compressing/encoding part of the two-side model for DL transmission. UE may be assumed that it possesses decompressing/decoding portion of two-side model for UL transmission, and the CN may be assumed to have decompressing/decoding portion of two-side model for DL transmission. The CN may be assumed to have compressing/encoding part of two-side model for UL transmission.

With respect to the performance monitoring request, in some example implementation, one peer (e.g., CN and/or UE) may send one NTTP protocol signaling to request the other peer (e.g., UE and/or CN) to trigger a performance metrics calculation, the NTTP protocol signaling may indicate at least one of the following information: 1) the reference data (pair) which is used for the performance metric calculation, 2) an indication to acquire the feedback of the decompressed/resumed and/or source data, 3) an indication to acquire the feedback of the performance metrics, 4) a threshold value to determine the model control behavior. In some example implementations, format of the NTTP protocol signaling, it may be a NTTP protocol control element. In some other example implementation of format of the NTTP protocol signaling, it may be a subheader to a NTTP protocol data unit.

With respect to the performance metrics above, in some example implementations, it may include a quantification semantic difference. In some example implementations, it may include a Euclidean Distance.

With respect to the model control request and model control signaling, the control signaling may be an NTTP protocol signaling which is described as above. The model control signaling may include a model activation/deactivation/switch/fallback.

In the example implementation of model management architecture in FIG. 9, the AI/ML models for semantic source encoding may be deployed at the AS layer 912 on the UE side 901 and the access network (base station, e.g., NodeB) 922 on the network side 903. Management of the model may be performed between the AS layer 912 and the access network 922 via AS signaling exchanges. Such management may be implemented by network service providers via the wireless network rather than user devices and application server (and thus can be centralized and shared by different application providers) and because it is the closest to the physical channel 930, it provides model management with smallest delays.

An example implementation for managing the AI/ML models between the AS layer 912 and the access network (e.g., NodeB) 922 in the architecture of FIG. 9 is shown in FIG. 10, including the following example steps:

● STEP 1: The NodeB may send the configuration for model management to the UE.

● STEP 2: The NodeB may send the control signaling to activate an AI/ML model for new type data transmission.

● STEP 3: The NodeB may send UE the reference data and/or request for performance monitoring of the new type data transmission.

● STEP 4: The UE may implement the performance monitoring and calculate the performance metrics based on configuration and received reference data.

● STEP 5: The UE may send the calculated performance metrics and/or model management request to the NodeB.

● STEP 6: The NodeB may determine a model management, if needed.

● STEP 7: The NodeB may send to the UE the model control signaling to adjust the model status.

Another example implementation alternative to FIG. 10 for managing the AI/ML models between the AS layer 912 and the base station (nodeB) 922 in the architecture of FIG. 9 is shown in FIG. 11, including the following example steps:

● STEP 1: The NodeB may send the configuration for model monitoring to the UE.

● STEP 2: The NodeB may send the control signaling to activate an AI/ML model for new type data transmission (e.g., semantic communication) .

● STEP 3: The UE may send to the NodeB the reference data and/or request for performance monitoring for new type data transmission.

● STEP 4: The NodeB may calculate the performance metrics and make a model management decision according to the calculated metrics.

● STEP 5: The NodeB may send to the UE the model control signaling to adjust the model status.

The difference between the example implementations of FIG. 10 and FIG. 11 mainly with respect which network entity (the UE or the NodeB) provides reference data for performance monitoring and which entity performs the performance monitoring for the new type data transmission.

With respect to the signaling of the configuration for model management for above two embodiments in FIGs. 10 and 11, in one implementation, an RRC signaling may be used. In some example implementations, the RRC signaling may indicate the timing point or event to trigger UE and/or NW to report the calculated performance metrics and/or the reference data for calculating performance metrics. Such triggering time point or event may include but is not limited to at least one of: applying a timer may be applied; applying a COUNTER with a predefined maximum value; upon a reception of a control PDU; or by a threshold value for triggering the performance metrics report as indicated by the RRC signaling.

With respect to the control signaling of FIG. 10 and FIG. 11, in some example implementations, it may be an RRC signaling, a PDCP control PDU, an RLC Control PDU, a MAC CE, or a PHY Control Signaling (e.g., PUCCH and/or PDCCH) , or one logical layer control PDU the logical layer is an access stratum layer. In some example implementations, the control signaling may contain/indicate at least one of the following information: a model identity; a model description Information; a service type; a knowledge base identity (for the knowledge base indicated in FIG. 9) ; a PDU session ID; a QoS (Quality of Service) flow ID; a Logical Channel (LCH) ID; or a Data Radio Bearer (DRB) ID; an indication of model control (e.g., activation/deactivation/switch/fallback) .

With respect to the performance metrics signaling in FIG. 10 and FIG. 11, in some example implementations, it may be an RRC signaling, a PDCP control PDU, an RLC Control PDU, a MAC CE, or PHY Control Signaling (e.g., PUCCH and/or PDCCH) . In some example implementations, the performance metrics may be a quantification of semantic difference between the input of the encoder and output of the decoder. In some example implementations, the performance metrics may be a quantification semantic difference between the output of the model and the received reference data. In some example implementations, the performance metrics may be a Euclidean Distance between the output of the model and the received reference data. In some example implementation, the performance metrics may be a Euclidean Distance between the input of the encoder and output of the decoder.

With respect to the reference data signaling for performance monitoring for both above embodiments in FIG. 10 and FIG. 11, in some example implementations, the reference data signaling may be a PDCP Control PDU, an RLC Control PDU, a MAC CE, a PUCCH/PDCCH, and the like. In some example implementations, the reference data may be retrieved from a database for test or from a real transmission for determining a prediction validity or accuracy of the deployed AI/ML model. In some example implementations, the reference data may contain one benchmark data or a benchmark data pair (e.g., benchmark input data and benchmark output data) . The benchmark data may be from a database for the model evaluation/test and/or performance monitoring. If reference data is a benchmark data, the reference data may be the input of the compressed part of two-sided model. If reference data is a data pair, one of the data pair may be an input of either UE part of the two-sided model or NW part of the two-sided model that needs to be tested for validity or prediction accuracy. The other one of the data pair may be an output of either UE part of the two-sided model or NW part of the two-sided model that needs to be tested for validity or prediction accuracy. In some example implementations, the reference data may include data from real transmission. In other words, the source/resumed data would be sent to the UE/NodeB by NodeB/UE for the performance monitoring.

With respect to the performance metrics calculation method, in some example implementations, the performance metrics can be obtained from a comparison between the benchmark reference output data and the output of either UE part of the two-side model or NW part of the two-side model. An output of either UE part of the two-side model or NW part of the two-side model is obtained from the reference input data with the AI/ML model that needs performance monitoring. In some example implementations, the performance metrics can be obtained from a comparison between the reference data and the output of the decompressing/decoding part of the AI/ML model. In this example implementation, the UE may be assumed to have compressing/encoding part of two two-side model for UL transmission. The UE may be further assumed to have decompressing/decoding part of the two-side model for DL transmission. The CN may be assumed to have decompressing/decoding part of the two-side model for UL transmission, CN may be assumed to have compressing/encoding part of the two-side model for DL transmission.

With respect to the request signaling for performance monitoring for both above embodiments in FIG. 10 and FIG. 11, in some example implementations, the request signaling may be a PDCP Control PDU, an RLC Control PDU, a MAC CE, a PUCCH/PDCCH, and one logical layer protocol control PDU. The Request signaling may indicate at least one of the following information: 1) an indication of reference data (pair) which is used for performance metric calculation, 2) an indication to acquire the feedback of the decompressed/resumed and/or the source data, 3) an indication to acquire the feedback of the performance metrics, 4) a threshold value to determine the model control behavior.

AI/ML Model Management-Higher Layer Reaction to Transmission Type Switch

In some example implementations, the new type data transmission (e.g., semantic communications) and legacy source symbol-based communications may co-exist. For example, when needed. the new type data transmission for a communication session may be activated or deactivated. The network thus may need to be designed, configured, and adapted to handle such activation and deactivation of the new type data transmission, and such activation and deactivation may impact the data transmission requirement and process on the various inter-node interfaces. The various network nodes involved in the communication procedure may need to be informed of various configuration related to semantic communication. For example, in the model management architecture of FIGs. 5 and 6, the semantic communication may be transparent to the RAN (gNB, or NodeB) . Yet, they may need to be notified of the activation and deactivation of the new type data transmission that may require resource changes.

In some example implementations for effectuating a switching between the new transmission type (e.g., semantic transmission) and symbol-based transmission, data flows for both the new type transmission and symbol-based (e.g., legacy) transmission may be established when establishing the PDU sessions for a service. Then activation/deactivation may of the new type transmission may be requested from either the UE or the data network service provider. Each of the data flow may be established for handling either the new type transmission or the legacy transmission. Only the handling of the new type transmission would involve the AI/ML encoding/compression and decoding/decompression models.

In some example implementations, one or more, or multiple service flows may be associated with a service. One of the multiple service flows may be mapped to the new type data transmission while another service flow for the same service may be mapped the legacy symbol-based transmission. In such example implementations, the service flow associated with the new type data transmission may be activated or deactivated by request, or may be switched between a service flow for new type data transmission and a service flow for legacy symbol-based transmission. In such example implementations, the deactivation of one service flow means that the service flow is suspended rather than released, and the activation of one service flow means a resumption of the service flow from a suspended state. In one example implementation, a switch of service flows for one service between the new type data transmission and symbol-based transmission may be applied. For such a service flow switch, for example, at least one service flow is deactivated and at least one other service flow is activated simultaneously for the service. In some example implementations, a service flow may be PDU session, or a QoS flow. For example, the NW or the UE may effectuate such a switch, activation or deactivation by the following example steps for the example case where the AI/ML models for the new type data transmission are located in the CN/NAS as shown in FIG. 6 or in the application server/App layer as shown in FIG. 5:

● STEP 1: The UE may send a request message A to the CN for requesting the PDU session activation/deactivation.

● STEP 2: The CN may send a message B to the NodeB regarding a service flow activation/deactivation.

● STEP 3: The NodeB may send a message C to the UE according to the received signaling regarding the service flow activation/deactivation.

● STEP 4: The UE may execute the related operation according to the message C, and may send a response to message C to the NodeB.

● STEP 5: NodeB may send the CN the response to the message B regarding the service flow activation/deactivation.

In some example implementations above, the message A may be a NAS signaling terminated between NAS layer of the UE and the CN. In some example implementations, the message A may include/indicate at lease one of the following information: 1) a PDU session Id to indicate the PDU session which need to be activated/deactivated, 2) activation/deactivation indication to indicate the behavior for the indicated PDU session (e.g., activate or deactivate) , 3) the deactivation/activation request of the AI/ML model/functionality/feature regarding the new type data transmission, 4) an AI/ML model/functionality indication to indicate the AI/ML model/functionalities that are requested to be activated/deactivated.

In some example implementations, Message B above may be a signaling terminated between the CN and the NodeB. In some example implementations, Message B may include/indicate at least one of the following information: 1) a PDU session Id to indicate the PDU sessions which need to be activated/deactivated, 2) an activation/deactivation indication to indicate the behavior for the indicated PDU session (e.g., activate or deactivate) , 3) an indication of deactivation/activation of the AI/ML model/functionality/feature regarding the new type data transmission, 4) an AI/ML model/functionality indication to indicate the AI/ML model/functionalities that are activated/deactivated.

In some example implementations, message C above may be a resource control signaling (e.g., RRCReconfiguration) , or an AS logical 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 information: 1) a PDU session Id to indicate the PDU sessions which need to be activated/deactivated, 2) an activation/deactivation indication to indicate the behavior for the indicated PDU session (e.g., activate or deactivate) , 3) an indication of deactivation/activation of the AI/ML model/functionality/feature regarding new type data transmission, 4) an AI/ML model/functionality indication to indicate the AI/ML model/functionalities that are activated/deactivated.

In some example of UE operation in step 4 above, at least one of the following operation may be executed when the signaling indicates a deactivation of a PDU session: 1) for UL transmission, the logical layer (s) associated with the related data radio bearer (s) for the indicated PDU session may transfer all the data units in its buffer to a lower layer, and the data units may be ACKed data units or non-ACKed units; and/or 2) Reset all timers and counters in each AS logical layer associated with the related data radio bearer; and/or 3) for UL transmission, the logical layer associated with the indicated PDU session generates an end mark data unit if there is no more data unit left in the buffer or if an indication of deactivation of related PDU session is received, and/or; 4) for DL transmission, the logical layer (s) associated with the related data radio bearer (s) may transfer all the data units in the buffer to an upper layer, and these data units may be considered ACKed, and/or 5) for DL transmission, the logical layer associated with the indicated PDU session may consider that all data units for the indicated PDU session have been received when receiving the end mark control data, and may notify each lower layer associated with the related radio bearers for the indicated PDU session to be suspended; and/or 6) each logical layer associated with the radio bearer (s) for the indicated PDU session may discard all the data units stored in the buffer, if any; and/or 7) the radio bearer associated with the indicated PDU session may be considered as suspended after the end mark control PDU has been received or the deactivation of the associated PDU session signaling is received or the end mark control PDU has been successfully transmitted; and/or 8) the logical layer associated with the indicated PDU session may stop receiving the data units from upper layer when receiving the PDU session deactivation signaling (in such implementation, one or more radio bearer of air-interface (e.g., the interface between UE and nodeB) may be configured for transferring the data for one or more specific PDU session) .

In some other example of UE operation in step 4 above, at least one of the following operations may be executed when the signaling indicates an activation of a PDU session: 1) the radio bearer (s) associated with the indicated PDU session is considered as resumed; 2) reset all the timers/counters of each AS logical layer that is associated with the PDU session and/or all the related radio bearers. In such implementations, one or more radio bearer of the air-interface (e.g., the interface between UE and nodeB) may be configured for transferring the data for one or more specific PDU sessions.

In some example implementations of step 4 above, the response message may be an RRC signaling (e.g., RRCReconfigurationComplete Message) , or an AS logical layer control data unit. The AS logical layer may be a SDAP layer, a PDCP layer, an RLC layer, a MAC layer, a PHY layer, and the like, or the AS logical layer may be a logical layer associated with the indicated PDU session. In some other example implementations of step 4 above, the response message may be an end mark control PDU generated by an AS logical layer associated with the indicated PDU session.

In some example implementations of step 5 above, the response message may be a signaling terminated between NodeB and CN, and may indicate/include the following information: 1) an indication for successfully activated PDU sessions; 2) an indication for a failure of activation of PDU session and associated failure causes; 3) an indication for successfully deactivated PDU sessions; 4) an indication for a failure of deactivation of PDU session and associated failure causes.

In some other example implementations, one or more or multiple service flows for air-interface (e.g., data radio bearer) may be associated with one or more PDU sessions or one or more QoS flows for new type data transmission. In such example implementations, one service flow associated with the new type data transmission may be activated or deactivated by request, or service flow may be switched between a service flow for the new type data transmission and a service flow for legacy symbol-based transmission. In such example implementation, the deactivation of a service flow means that the service flow is suspended rather than released. An activation of one service flow means a resumption of the suspended service flow. In one example implementations, the switching of service flows between the service flows for new type data transmission and those for symbol-based transmission may be applied. A service flow switch means at least one service flow is deactivated and at least one another service flow is activated simultaneously. For example, the NW or the UE may effectuate such switch, activation or deactivation of the service flow associated with the new type data transmission or the symbol-based transmission by the following example steps:

● STEP 1: The UE may send a request message A to the RAN Node.

● STEP 2: The RAN Node may send a message B to UE regarding the activation/deactivation of a service flow.

● STEP 3: The UE may execute some operations regarding the activation/deactivation of a service flow.

In STEP 1, in one example implementation, the request message A may be a UL RRC signaling, an SDAP control data unit, a PDCP control data unit, an RLC control data unit, a MAC control element, a PHY control signaling (e.g., PUCCH/PDCCH) . In one example implementation, the signaling may indicate/include at least one of the following information:

1) An AI/ML model/functionality index: the AI/ML models/functionalities for new type data transmission which is requested to be deactivated/activated or switched.

2) An activation/deactivation/switch of AI/ML models/functionalities flag: to indicate the activation/deactivation/switch the indicated AI/ML model/functionality.

3) A Radio bearer Index or Logical Channel Index: to indicate the service flows for new type data transmission that are requested to be activated/deactivated/switched.

4) An activation/deactivation/switch of service flow flag: to indicate the activation/deactivation/switch the above indicated service flows.

5) A performance metrics indication: to indicate the performance metrics from performance monitoring at UE side.

In one example implementations, the service flow may be the radio bearer which is terminated between UE and RAN Node.

In STEP 2, in one example implementation of message B, the message B may be a response message to the message A. In another example implementation of message B, the message B may be the activation/deactivation control signaling for AI/ML models/functionalities of the new type data transmission. In one example implementation, the message B may indicate/include at least one of the following information:

1) An AI/ML model/functionality index: the AI/ML models/functionalities for new type data transmission which is deactivated/activated.

2) An activation/deactivation/switch of AI/ML models/functionalities flag: to indicate the activation/deactivation of the indicated AI/ML model/functionality.

3) A Radio bearer Index or Logical Channel Index: to indicate the service flows for new type data transmission those are requested to be activated/deactivated/switched.

4) An activation/deactivation/switch of service flows flag: to indicate the activation/deactivation of the indicated service flows.

5) A performance metrics indication: to indicate the performance metrics from performance monitoring at NW side.

In STEP 3, the UE operation for deactivating a service flow may contain at least one of the following:

1) The logical layer where the control signaling message B is received may indicate to a logical layer (e.g., the SDAP layer) to stop mapping a PDU session and/or QoS flow to one service flow (e.g., radio bearer) .

2) The logical layer (e.g., SDAP layer) may generate an end mark control data unit for the deactivated service flow and send it to a lower layer. The end mark control PDU may indicate that this control data unit is the last data unit for such service flow which is deactivated.

3) The logical layers (e.g., PDCP layer, RLC layer) associated with the deactivated service flow may be considered as reestablished after receiving the end mark control PDU or successfully transmitting the end mark control PDU. For example, each logical layer may send all stored PDUs and/or SDUs that are not ACKed by lower/upper layers to the lower/upper layers, and each logical layer may then discard all stored PDUs and/or SDUs, and reset all timers, variables, counters.

4) The logical layers (e.g., PDCP layer, RLC layer) associated with the deactivated service flows may be considered as suspended after receiving the end mark control PDU or successfully transmitting the end mark control PDU. In one example implementations, suspension of one logical layer may contain: 1) discarding all stored data units in the buffer; 2) initializing all the timers, counters, and/or variables.

In STEP 3 above, the UE operation for activating a service flow may contain at least one of the following:

1) One logical layer (e.g., the SDAP) may map the PDU session and/or QoS flows to the activated service flow.

2) Each logical layer (e.g., the PDCP layer or RLC layer) associated with the activated service flow may be reset. In one example implementation, resetting of one logical layer may contain 1) discarding all stored data units in the buffer; 2) initializing all the timers, counters, variables.

AI/ML Model Management - Control Plane Procedure/Signaling for New Transmission Type

For supporting the RAN and UE in handling and in being aware of the data transmission type, some control plane (CP) procedure in CN and/or RAN may be needed and implemented as described below.

One example CP procedure is shown in FIG. 12, and may include:

● STEP 1: UE/Database/Application server may request the NW for an establishment and/or modification of a service data flow.

● STEP 2: The NW may send a response to the request for establishment and/or modification of a service data flow.

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

In some example implementations of STEP 1 above, the request may include and/or may indicate at least one of the following information items:

● A data flow type indicator: to indicate the type for which the data flow is request to be established or modified among, for example, an error-free data flow, an error-tolerance data flow, and the like.

● A quantification indicator: to indicate the scenario where such request data flow may be allowed/applied, for instance, range of the value of SINR, the value of RSRQ, the value of RSRP, the transmission failure ratio (e.g., including the PDU transmission failure of each layer) .

● A data flow quality of service indicator: to indicate the data flow QoS requirement, for example, level 5QI.

In some example implementations of STEP 2 above, the response may be a NAS signaling terminated between the UE and the CN, or may be a radio resource control signaling, or may be a message combing the RRC message and/or NAS signaling which may indicate at least one of the following information items:

● Acknowledgement/NACK to the request of data flow establishment in STEP 1.

● Data flow ID: to indicate the data flow identifier which is configured to UE.

● A quantification configuration: to indicate the scenario where the error-tolerance transmission (new type data transmission) for such data flow can be allowed, enabled, and the like, e.g., the value of SINR, the value of RSRQ, the value of RSRP, the transmission failure ratio (e.g., including the PDU transmission failure of each layer) . For example, in some example implementations, the new type transmission may be allowed/enabled if channel state’s SINR is greater than one certain SINR value in a quantification configuration. For another example, the new type transmission may be allowed/enabled if the channel state’s RSRP is greater than one certain RSRP value in the quantification configuration. For another example, the new type transmission may be allowed and/or enabled if the channel state’s RSRQ is greater than one certain RSRQ value in the quantification configuration. For yet another example, the new type transmission may be disallowed and/or disabled if the new type transmission failure ratio is greater than one certain threshold value in the quantification configuration.

Another example CP procedure is shown in FIG. 13 (where a base station is split into different function units) , and may include:

● STEP 1: A first unit of the base station may request the data flow establishment and/or modification for new type transmission.

● STEP 2: A second unit may generate the response message to the request.

For STEP 1 above, in some example implementations, the first unit may include a centric unit of a 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, a communication interface between the first unit and the second unit of the base station (e.g., CU and DU) may be an F1 interface. In some example implementations, STEP 1 may be associated with the UE context modification/establishment procedure.

In some example implementation, the request in STEP 1 above may include and/or indicate at least one of the following information items:

● An air-interface data flow (e.g., DRB) to be set up for the request data flow for new type transmission.

● An SCell (Secondary Cell) to be set up for the request data flow for new type transmission.

● A quantification indicator for the request data flow for new type transmission, e.g., one SINR value, one RSRP value, one RSRQ value, or transmission failure ratio, and the like.

● A quality indication of the data flow, for example, level 5QI.

For STEP 2 above, in some example implementations, the response may include and/or indicate at least one of the following information items:

● An air-interface data flow (list) (e.g., DRB (list) ) which is request to be set up for the data flow of new type transmission.

● An SCell (list) which is request to be set up for the data flow of new type transmission.

● A quantification indicator for each DRB/SCell to be setup.

Error-Free Transmission and Error-Tolerance Transmission-General

As described above, the new type transmission such as the semantic communication does not need an error-free transmission. In particular, when there is a transmission error, the AI/ML based semantic communication have an ability of recovering the semantics of the data through the AI/ML models even some of them may be lost or incorrectly transferred due to the poor channel quality. In order to leverage the advantages from the semantic communication, a UP data transmission may adopt a non-guarantee transmission in order to reduce delays and save resources consumption caused by the potential re-transmission.

However, PDU based transmission in the 3GPP system need non-error transmission of header information for each protocol layer and/or control signaling. Otherwise, the PDU would be discarded due to the error detection of the header information, and the CP related procedure would be considered as failed due to the control signaling error. For at least this reason, the PDU based solution in the current symbol based communication systems would need to be modified when being used for the new type transmission.

As such, in some example implementations, CP date may be undergone error-free transmission, whereas semantic UP (User Plane) data with protocol headers may be undergo a mix of error free transmission and error tolerant transmission, where the protocol headers may undergo error free transmission and the payload may under go error tolerance transmission. The protocol headers for downlink (DL) data, for example, may include SDAP header, PDCP header, RLC header, and MAC header, and the like. The protocol headers for uplink (UL) data, for example, may include the SDAP header, the PDCP header, the RLC header, the MAC header, and the like.

In addition, the error tolerance level of the non-header UP data payload may depend on the capability of the AI/ML models and the error levels at the same time may depend on the quality of the underlying physical transmission channels and may be adaptively adjusted by including a controllable level of, for example, Cyclic Redundancy Check (CRC) , HARQ operation, etc.

A modified protocol system for the PDU would preferably achieve one or more of the follow targets:

● Target 1: to support both the data flow for error-free transmission and the data flow for error-tolerance transmission.

● Target 2: to support both error-free transmission of header information and error-tolerant transmission of the UP data.

● Target 3: the CRC operation for the new type transmission may need be controllable in order to adapt to the various change of the channel state. Which can be considered as the target 3 in this disclosure.

Error-Free Transmission and Error-Tolerance Transmission – Separation of the Data Flow with Guaranteed Transmission from Data Flow with Data Tolerance

In some example implementations, the separation of the data flow with guaranteed transmission from data flow with data tolerance may be implemented using UL grant or DL assignment. An example is shown in FIG. 14, including the following example steps:

● STEP 1: an RRC configuration signaling for new type transmission operation may be received from by the UE from the NW.

● STEP 2: a UL grant and/or DL assignment may be received by the UE from NW.

● STEP 3a: the UE perform UL grant processing if the UL grant is received in STEP 2.

● STEP 3b alternative to STEP 3a: the UE performs DL assignment processing if the DL assignment is received in STEP 2.

● STEP 4a: the UE generates the UL transmission to the NW according to the UL grant.

● STEP 4b alternative to STEP 4a: the UE performs DL reception operation according the DL assignment.

● STEP 5b: UE may send the ACK/NACK to the NW according to the DL operation in step 4b.

For STEP 1 above, in some example implementations, the RRC configuration may indicate or include at least one the following information items regarding the transmission operation:

● An indication configured for e.g., logical channel, or radio bearer, or QoS flow. Such an indication may indicate the transmission type for the data from such logical channel, radio bearer, QoS flow. In one example implementation of such indication, the transmission type for a logical channel, or radio bearer, or QoS flow may depend on transmission type for the HARQ processes that are associated with the LCH, or the radio bearer, or the QoS flow. For example, if one HARQ process with a HARQ process Id is indicated for TYPE 1 transmission, the associated LCH and/or radio bearer and/or QoS flow may be for TYPE 1 transmission as well. Otherwise, the associated LCH and/or radio bearer and/or QoS flow may be for TYPE 2 transmission.

● An indication configured for a serving cell/BWP. Such an indication may indicate the transmission type (e.g., TYPE 1 transmission/TYPE 2 transmission) of the transmission on the serving cell/BWP.

● An indication configured for a PDCCH timing location (e.g., search space) . Such an indication may indicate the transmission type of a transmission scheduled by a UL grant/DL assignment received from such PDCCH timing location.

● An indication configured for a PDCCH frequency location (e.g., CORESET) . Such an indication may indicate the transmission type of a transmission scheduled by a UL grant/DL assignment received from such PDCCH frequency location.

● A specific cell radio network temporary identifier. The UL grant/DL assignment addressed by the specific cell radio network temporary identifier may indicate type 1 transmission. Comparatively, the UL grant/DL assignment addressed by a cell radio network temporary identifier other than the specific cell radio network temporary identifier may indicate type 2 transmission.

● An indication configured for a HARQ process. Such an indication in the HARQ process configuration may indicate the transmission type for the transmission corresponding to the HARQ process. In one example implementation of such indication, the HARQ process configurationmay include/indicate at least one of the following information:

○ One parameter to indicate the HARQ process Id.

○ One parameter to indicate the transmission type for the HARQ process.

In some example implementations of the STEP 1 above, a transmission type may include but is not limited to:

● TYPE 1 transmission: the transmission may be an error-tolerant transmission, or the transmission may contain both the for error-tolerant transmission and error-free transmission. For example, a part of the data for the transmission may require error-tolerant transmission which does not require HARQ related operations. A part of the data for transmission may require error-free transmission which needs HARQ related operation.

● TYPE 2 transmission: the transmission type may be an error-free transmission. For example, all the data for transmission may need HARQ related operation. The TYPE 2 transmission may be asymbol-based transmission which is broadly used in LTE and NR.

In the example implementations above, all TYPE 1 transmission and TYPE 2 transmission appeared in this specification may have the same definition. The terms of ‘HARQ operation’ or ‘HARQ related operation’ appeared in this specification may include a couple of operation for implementing the error-free transmission. For example, a transmitting side may encode a data block with some redundant/checking bits (e.g., encoding the data block with a certain redundancy check method, for example, using CRC, LDPC, Pola, or Turbo code) , and may perform a re-transmission if NACK is received, whereas a receiving side may check whether the data block is correctly received with the redundant/checking bits added by a transmitting side (e.g., decoding the data block with a certain redundancy check method, for example, using CRC, LDPC, Polar, or Turbo code) , and may generate ACK/NACK regarding the received data block after checking.

In some example implementations of STEP 3a and 3b above in FIG. 14 for processing the received UL grant and/or DL assignment, the UE may decide the transmission type for a UL grant/DL assignment in the following example manners:

● The UL grant/DL assignment addressed by a specific cell defined UE identity (e.g., CRNTI) may be considered by the UE as the corresponding scheduling transmission type (e.g., TYPE 1, or TYPE 2) .

● The UL grant/DL assignment received in a PDCCH with a specific timing location (e.g., search space) may be considered by the UE as the corresponding scheduling transmission type.

● The UL grant/DL assignment received in a PDCCH with a specific frequency location (e.g., CORESET) may be considered by the UE as the corresponding scheduling transmission type.

● The UL grant/DL assignment may contain one indication to indicate the scheduling transmission type and the UE may decide the transmission type according to such indication.

● The UL grant and DL assignment for a HARQ process which may implicitly indicate a transmission type that the UL grant/DL assignment is for through the transmission type configured for the HARQ process. For example, the UL grant /DL assignment may be for Type 1 transmission if the scheduling HARQ process is configured for Type 1 transmission. Otherwise, the UL grant/DL assignment may be for Type 2 transmission.

In some example implementations of STEP 4a in FIG. 14 for generating UL transmission according to the received UL grant, the MAC package data unit and/or TB should be generated. In one example implementation of generating the MAC data unit and/or TB, a LCH restriction factor may be introduced, the LCH restriction factor may be used for MAC entity to determine the LCH where the data can be multiplexed into MAC package data unit/TB for the UL transmission scheduled by UL grant. In some example implementations, the LCH restriction factor above may be an allowed serving cell (list) and/or BWP (list) which means that the data from the LCH can be multiplexed and assembled for such UL transmission on those serving cells/UL BWPs. In another example implementations, the LCH restriction factor above may be an allowed HARQ process Id (list) which means that the data from the corresponding LCH can be multiplexed and assembled only for the UL grant for the allowed HARQ process Ids.

Some example implementation of step 4a, the MAC PDU generation for TYPE 1 transmission, are further described in the below embodiments (e.g., the embodiments described in the section entitled: Separation of the Header/Control Information from the Source Data Block/Padding) .

In some example implementations of STEPs 4b and 5b in FIG. 14 for performing the DL reception according to the received DL assignment, the received Transport Block (TB) or the part of the received TB may not need the HARQ related operation and/or generate the HARQ feedback (e.g., ACK/NACK) according to the received DL assignment if the received DL assignment indicates the scheduling transmission is a TYPE 1 transmission. In some example implementations, the received TB may need the HARQ related operation and/or generate the corresponding HARQ feedback (e.g., ACK/NACK) according to the received DL assignment if the received DL assignment indicates the scheduling transmission is TYPE 2 transmission.

In some example implementation of step 4b and 5b, the DL reception for TYPE 1 transmission is further described in the disclosure below (e.g., Separation of the Header/Control Information from the Source Data Block/Padding) .

In some implementations, the HARQ related operations may be handled by higher layers, e.g., one or more MAC entities for UL and DL transmissions. For UL grant, one example implementations for HARQ operation handling may include the following steps:

● STEP 0: a UL grant may be received from NW.

● STEP 1: the UE may determine the transmission type for the UL grant (e.g., new transmission or retransmission) .

● STEP 2: if the UL grant is for new transmission. The UE perform a multiplexing of the MAC SDU and MAC CE into a MAC PDU for the UL grant, and indicate the lower layer to perform a UL transmission.

● STEP 3: if the UL grant is for the re-transmission to a HARQ process ID and/or a NACK to the HARQ process ID of a UL transmission has been received, then the MAC entity may generate a re-transmission for the MAC PDU.

In some example implementations of STEP 2 above, the MAC entity may be responsible for composing a MAC PDU, and the MAC PDU may comprise of one or more MAC subPDUs.

In some example implementations of multiplexing of the MAC SDU and/or MAC CE into a MAC PDU, the MAC entity may attach the HARQ related information to one or more MAC subPDUs. In some example implementation of MAC subPDU, the MAC subPDU may contain a MAC SDU or MAC Control element and a corresponding subHeader information. In some example implementations, at least one of the following MAC subPDU may need to be attached with the HARQ related information:

● a MAC subPDU corresponding to a MAC Control Element.

● a MAC subPDU corresponding to a MAC SDU from an LCH being associated with a service flow (e.g., radio bearer) for which TYPE 2 transmission is required or configured.

● a MAC subPDU corresponding to a MAC SDU being a Control signaling from upper layers (e.g., SDAP/PDCP/RLC) .

● a MAC subPDU corresponding to a MAC SDU that contains one or more header information of upper layers (e.g., the logical layers above the MAC layer) for one payload data unit.

In some example implementations for attaching the HARQ related information to each MAC subPDU which needs HARQ operation, at least one of the following operations may be performed by the MAC entity:

● Using one bit in the MAC subheader of an SDU or MAC Control Element to indicate whether the HARQ related information is attached to the end of the SDU (s) or MAC CE (s) .

● Including the HARQ related information in the MAC sub-header to the SDU (s) and/or MAC CE (s) .

In some example implementation for attaching the HARQ related information to more than one MAC subPDUs, for saving the HARQ related information consumption, one or more MAC subPDUs can be grouped together for HARQ related operation, and hence at least one of the following operations may be performed by MAC entity:

● Grouping MAC subPDUs into multiple groups in one MAC PDU. In one example implementation of this grouping/apart mechanism, the MAC subPDUs needing the HARQ operation are allocated into one or more groups, whereas the MAC subPDUs that do not need the HARQ operation are allocated into other group (s) .

● Attaching a HARQ header to a group of MAC subPDUs that needs the HARQ information, and the HARQ header may include the HARQ related information which may include the bit length indication for the group that corresponds to the HARQ related information.

● Not attaching any HARQ header to a group of MAC subPDUs that do not need the HARQ information.

In some example implementations of STEP 3 above, the NACK indication to a UL transmission may be of at least one of the below formats:

● Indicating the HARQ ACK/NACK in PDCCH which is for scheduling retransmission. For example, the PDCCH may be used to indicate UL grant for scheduling re-transmission to the HARQ process ID for which the UL transmission is associated. In one example implementation, the PDCCH may include at least one of the following information:

○ A HARQ process ID: to indicate the HARQ process the re-transmission is scheduled for.

○ A group Indication: to indicate the groups of MAC subPDUs the retransmission is scheduled for.

○ A MAC sub-PDU indication: to indicate the MAC sub-PDUs the retransmission is scheduled for.

● Indicating the HARQ ACK/NACK in PDSCH. For example, one DL MAC CE may be used for indicating the NACK. In one example implementation, The DL MAC CE may include/indicate the at least one of the following information:

○ A HARQ Process ID: to indicate the HARQ process that the MAC PDU is associated with.

○ A MAC Sub-PDU indication: to indicate the MAC sub-PDU of the MAC PDU that are ACKed or NACKed.

○ A group Indication: to indicate the groups of MAC subPDUs those are ACKed or NACKed.

○ An ACK/NACK indication: to indicate the ACK/NACK for each indicated MAC PDU/MAC SubPDU/MAC subPDU group.

In some example implementations of STEP 3 above, for re-transmission of the MAC PDU, the MAC SDUs/MAC CEs or MAC sub-PDU (group) where the HARQ related information is attached may be retransmitted when receiving the NACK. In this implementation, the MAC entity may push the MAC PDU into multiplexing and assembly entity to re-generate a MAC PDU for retransmission where the MAC sub-PDU without HARQ information attached is eliminated.

In some other example implementations of retransmission of the MAC PDU, the MAC SDUs/MAC CEs or MAC subPDU (group) indicated by NACK may be retransmitted when receiving the NACK. For example, the MAC entity may push the MAC PDU into multiplexing and assembly entity to re-generate the MAC PDU for retransmission where the MAC sub-PDU with ACK indication is eliminated.

In some other example implementations of retransmission of the MAC PDU, the whole MAC PDU may be retransmitted when receiving the NACK.

In some implementations for DL assignment, one example HARQ operation handling by higher layers, e.g., one or more MAC entities, may include the following steps:

● STEP 1: a DL assignment may be received for a HARQ process by the UE.

● STEP 2: a MAC entity may process the DL assignment and determine whether the DL reception is a new transmission or a re-transmission and send the information to the HARQ entity.

● STEP 3: the MAC entity may allocate a TB received from lower layer and associate a HARQ process ID to the HARQ process.

● STEP 4: the MAC entity may decode the TB to MAC PDU and parse the MAC PDU into the MAC sub-PDUs for the HARQ process.

● STEP 5: the MAC entity may forward each MAC subPDU to the upper layer by removing the subheader/header that is added in MAC layer.

● STEP 6: the MAC entity may generate the NACK/ACK information to the HARQ process and indicate it to lower layer for transmission of the NACK/ACK indication.

In some example implementation of STEP 2 above for the DL assignment to indicate a retransmission to the HARQ process ID, the PDCCH for DL assignment may include/indicate at least one of the following information:

● HARQ Process ID: to indicate the HARQ Process the retransmission is for. In one example implementation, it indicates all MAC subPDUs and/or MAC subPDU groups that have been indicated as NACK for which HARQ process ID are transmitted by such DL assignment.

● Transmission type indication: to indicate the transmission type (e.g., Retransmission/New Transmission) . In one example implementation, it may be an indication of NDI value which is used for comparing the previous NDI value for the same HARQ process Id.

● MAC sub-PDU indication: to indicate the MAC Sub-PDUs that are associated with the indicated HARQ process ID and are re-transmitted by such DL assignment.

● MAC subPDU group indication: to indicate the MAC sub-PDU group that are associated with the indicated HARQ process Id and are re-transmitted by such DL assignment.

In some example implementation of decoding and parsing TB/MAC PDU in STEP 4, the MAC entity may consider the MAC subPDU as failed to be received if the HARQ related information is attached and the HARQ is failed. In some other example implementation of decoding and parsing TB/MAC PDU in STEP 4, the MAC entity may consider all MAC subPDUs with HARQ related information attached to be failed if at least one MAC subPDU is not successful with respect to HARQ operation. In some other example of decoding and parsing of TB/MAC PDU in STEP 4, the MAC entity may consider all MAC subPDUs in one group as failed to be received if at lease one or more than N MAC subPDUs in the group is not successful with respect to HARQ operation. In this implementation, value of N can be configurable in RRC configuration or hard coded in the specification. In yet some other example implementations of decoding and parsing TB/MAC PDU in STEP 4, the MAC entity may consider the MAC PDU as failed to be received if at least one or more than N MAC subPDUs are not successful with respect to HARQ operation. In this implementation, value of N can be configurable in RRC configuration or hard coded in the specification.

In some example implementation of STEP 5 above, at least one of the following MAC subPDU may be forwarded to the upper layer:

● a MAC subPDU to which there is no HARQ related information attached;

● MAC subPDUs (Group) those are considered as successful reception upon the HARQ related operation in the MAC entity.

In some example implementation of STEP 6 above, the NACK/ACK indication to a received MAC PDU can be either UL MAC CE or PUCCH signaling, which may contain or indicate at least one of the following information:

● A HARQ Process ID: to indicate HARQ Process ID the ACK/NACK information is for. MAC subPDU indication: to indicate the MAC subPDUs those have failed and/or Succeeded in HARQ operation.

● A MAC subPDU group indication: to indicate the MAC subPDU (group) those have failed and/or succeeded in the HARQ operation.

● A NACK/ACK indication: to indicate the reception failure/success for each indicated HARQ process Id, MAC subPDU, MAC subPDU group.

Error-Free Transmission and Error-Tolerance Transmission – Separation of the Header/Control Information from the Source Data Block/Padding

As described above for new type transmission, because the protocol header/control information may need to be transmitted error-free while the payload information may be recovered during decompression/decoding process described above even in presence of certain level of transmission errors, they may be separately transmitted. In one example implementation for separating handling of header information from payload information, as shown in FIG. 15, each higher layer in the communication protocol stack (e.g., SDAP, PDCP, RLC) for the new type transmission (e.g., semantic transmission) may generate one header which may not be attach to the source data block. In some example implementations, the MAC layer may be responsible to compose those headers from upper layer and itself with corresponding source data block in a MAC PDU.

For example, a MAC entity may have two example ways to multiplex and assemble the headers and payload into a MAC PDU. In order to facilitate the HARQ operation on a continuous data stream, the MAC PDU may be separated into two part. The first part may contain the headers and/or control information, whereas the second part may contain source data block or payload data block, as shown in FIG. 16. In some implementations, the source data block in such a MAC PDU may follow the header/control information part, as shown in the upper panel of FIG. 16. In some other implementations, the source data block in such a MAC PDU may proceed the header/control information part, as shown in the lower panel of FIG. 16.

In the first way for the MAC entity to multiplex and assemble the headers and payload into the MAC PDU, the MAC entity may generate one MAC PDU and/or TB that comprises both headers information and source data block received from upper layer. In such implementations, header part of MAC PDU may need the HARQ operation, whereas the source data part of MAC PDU may not need the HARQ operation.

In the second way for the MAC entity to multiplex and assemble the headers and payload into the MAC PDU, the MAC entity may generate two separate MAC PDUs and/or TBs to respectively include the header information and payload received from upper layer. In such implementations, the MAC PDU of header information generated by each upper layer may need HARQ operation, but the MAC PDU of source data may not need HARQ operation.

In the example implementations above, the HARQ operations may be located at one logical layer which hosts a function for re-transmission. For example, the HARQ operations may be located at the PHY layer. For another example, the HARQ operation may be located at MAC layer.

In some example implementations, each higher layer (e.g., SDAP, PDCP, RLC, MAC layer) may perform the HARQ operation for the corresponding header and/or control signaling. For such implementations, the HARQ operations may be located at each higher layer for the corresponding header information and/or control information. In such implementations, the HARQ operations for source data block may be located at lower layer (e.g., PHY layer) , or may be located at a higher layer, for example, the SDAP layer.

In some example implementations, the handling of a PDU or subPDU received for the data transmission may follow the following example steps:

● STEP 1: an AS logical layer of a UE may perform the HARQ operation on a subPDU or PDU when receiving the subPDU or PDU from a lower layer or from the NW.

● STEP 2a: The AS logical layer may transfer the subPDU or PDU by removing the header information to the upper layer when the HARQ operation is considered as successful.

● STEP 2b alternative to STEP 2a: the AS logical layer may perform an operation on the subPDU or PDU when HARQ operation is considered as failed.

In some example implementations of STEP 1 above, the AS logical layer may be one of PHY layer, MAC layer, RLC layer, PDCP layer, SDAP layer, or may be a layer mixed with multiple layers of PHY layer, MAC layer, RLC layer, PDCP layer, SDAP layer.

In some example implementations of STEP 1 above the subPDU or PDU may be a block of data, one subPDU or PDU may contain the header part and/or payload part.

In some example implementations of STEP 1 above the UE may perform the HARQ operation on only header part of the subPDU or PDU. In some example implementations, the UE may consider the subPDU or PDU (e.g., including both header and payload part) as being received successfully if the HARQ operation of header part is successful.

In some example implementations of STEP 1 above, the UE may perform the HARQ operation on both header part and the payload part. For example, the UE may consider the subPDU or PDU as being successfully received if the header part of the subPDU or PDU is successfully decoded, although the transmission of the payload may be considered as failed. For another example, a number of retransmissions of the header part of a subPDU or PDU reaching a predefined maximum number may be considered as indicating a transmission failure of payload part of the subPDU or PDU.

In some example implementations of STEP 2b above, the operation performed on the subPDU or PDU may include at least one of the following:

● discarding the entire subPDU or PDU including both its header part and its payload part.

● discarding only header part of the subPDU or PDU.

● generating a HARQ feedback for the subPDU or PDU, and/or indicating the lower layer to send theHARQ feedback indication to a peer.

● generating the ARQ feedback for the subPDU or PDU, and/or indicating the lower layer to send the ARQ feedback to a peer.

In some example implementations, the HARQ operation, if needed, may be performed at the PHY layer. A UL transmission may be implemented in the following example steps:

● STEP 1: the MAC entity of a UE may determine whether the UL grant is for TYPE 1 transmission upon receiving a UL grant from lower layer. If the UL grant is for TYPE 1 transmission, go to STEP 2 below. Otherwise, end the procedure.

● STEP 2: the MAC entity of the UE may determine the transmission is new transmission or re-transmission for the TYPE 1 transmission.

● STEP 3a: if the MAC entity of the UE determines that the UL transmission is a new transmission, it may perform a multiplexing and assembling of a MAC PDU, and generate and deliver the TB to the HARQ process (es) .

● STEP 3b: If MAC entity of the UE determines that the UL transmission is a re-transmission, it may deliver the UL grant and HARQ information for the TB to the HARQ process for retransmission.

● STEP 4: the MAC entity may instruct the lower layer to initiate a UL transmission (e.g., new transmission or retransmission) .

In some example implementations of STEP 1 above, the UL grant may be identified as UL grant for TYPE 1 transmission by the MAC entity by at least one of the following:

● The serving cell and/or BWP that the UL grant is for. In one example implementation, the serving cell/BWP may be configured with an indication to indicate such serving cell/BWP to be for TYPE 1 transmission.

● The PDCCH timing position where the UL grant is received (e.g., the PDCCH search space) . For example, the PDCCH timing position may be configured for scheduling TYPE 1 transmission where the UL grant is received.

● The PDCCH frequency position where the UL grant is received (e.g., the PDCCH CORESET) . The PDCCH frequency position may be configured for scheduling TYPE 1 transmission where the UL grant is received.

● The HARQ Process Id which is indicated in the UL grant., For example, the HARQ process indicated by such HARQ process Id is configured for TYPE 1 transmission.

● An indication in the PDCCH to which the UL grant is addressed to indicate that the UL grant is for TYPE 1 transmission.

● An indication configured in a Logical channel or radio bearer to indicate the logical channel or radio bearer where the data is for TYPE 1 transmission. For example, UL grant can be determined implicitly as the UL grant for the TYPE 1 transmission by at least one of the following methods:

○ There may be an LCH/RB factor mapping relationship between LCH/RB and serving cells/BWPs. The UL grant for the mapped serving cells/BWPs may be determined as UL grant for TYPE 1 transmission.

○ There may be an LCH/RB factor mapping relationship between LCH/RB and HARQ Processes. The UL grant for the mapped HARQ processes may be determined as UL grant for TYPE 1 transmission.

In some example implementations of STEP 3a above for the MAC entity to deliver the TB to the HARQ process, the MAC PDU may be separated into at least two sub-TBs for one TB in for PHY layer transmission. At least one of the two sub-TBs may be generated for header and/or control information part of the MAC PDU, whereas another one of the two sub-TBs may be generated for the source data block part of the MAC PDU. For example, two or more sub-TBs may be delivered by the MAC entity to a HARQ process. A buffer of the HARQ process may be split into at least two parts. One of the at least two parts may be configured for storing the header and/or control information, whereas another part of the at least two parts may be configured for storing the source data block. For another example, the two or more sub-TBs may be delivered to different HARQ processes. The HARQ process for sub-TBs associated with the header/control information may support HARQ operations, whereas the HARQ process for sub-TBs associated with the source data block may not support HARQ operation. In one example implementation of HARQ process, one HARQ process supporting HARQ operation maybe from a HARQ entity, whereas one HARQ process not supporting HARQ operation may be from another HARQ entity. In this example implementation, a serving cell or cell group may be configured with at least two HARQ entities. Further in this example implementation, two sub-TBs from one MAC entity may be sent to two HARQ processes with the same HARQ process Id in different HARQ entities. In one example of HARQ process, 2N HARQ processes may be operated in one HARQ entity, among which the first/second half HARQ process Ids may be used for the transmission that needs HARQ operation, whereas the second/first half HARQ process Ids may be used for the transmission that does not needs HARQ operation. In this example implementation, one sub-TB may be sent to a HARQ process with HARQ process Id= x, whereas the other sub-TB may be sent to the HARQ process with HARQ process Id= x+n. In one example of HARQ process, N HARQ processes may be allocated to at least two groups for one HARQ entity, where the first group of HARQ processes in one HARQ entity may support the HARQ operation, whereas the second group of HARQ processes in one HARQ entity may not support the HARQ operation.

In some example implementations of STEP 3a above for new transmission, the MAC layer may instruct lower layer which sub-TB in the HARQ process buffer needs the HARQ Operation. In some other example implementations of STEP 3a above for new transmission, the MAC layer may deliver different sub-TBs for source data block to different HARQ processes, and among such HARQ processes, the HARQ process for the sub-TBs associated with the control and/or header information may need HARQ operations, whereas the HARQ process for the sub-TBs associated with the source data block may not need HARQ operations.

In addition, for the NW to successfully split the TB received from the UE, the UE may need to notify the NW of the size of each sub-TB in one TB. In some example implementations, the sub-TB size information may be indicated in a PUSCH. For example, the sub-TB size of the first Part of a MAC PDU may be indicated in the front of the corresponding MAC PDU.

In some example implementations of STEP 3b above for re-transmission, the MAC layer may indicate to a lower layer which sub-TB shall be re-transmitted and needs HARQ operation for a HARQ process. For example, a bitmap with at least two bits for a HARQ process ID in the UL grant to indicate which sub-TB is for retransmission (e.g., header, control information, or source data block) . In some other implementations, the sub-TB for retransmission may be indicated by HARQ ID in the UL grant for retransmission.

In some example implementations, the HARQ operation, if needed, may be performed at the PHY layer. A DL transmission may be implemented in the following example steps:

● STEP 1: it is determined by the UE whether a DL assignment for TYPE 1 transmission. If the DL assignment for TYPE 1 transmission is received, continue with STEP 2. Otherwise, end the procedure.

● STEP 2: the MAC entity of the UE may process the DL assignment, and try to receive the TB or sub-TBs from lower layer.

● STEP 3: the MAC entity of the UE may allocate TB (s) or sub-TB (s) received from lower layer to the HARQ processes.

● STEP 4: the MAC entity of the UE attempt to decode the received TB (s) or sub-TB (s) .

● STEP 5a: if the received TB (s) or sub-TB (s) is not decodable, the MAC layer of the UE may instruct lower layer to generate a NACK signaling for the received TB or sub-TB (s) .

● STEP 5b: if the received TB (s) or sub-TB (s) is successfully decoded, the MAC entity of the UE may deliver the decoded MAC PDU to a disassembly and de-multiplexing entity and instruct the lower layer to generate an ACK signaling.

In some example implementations of STEP 1 above the DL assignment may be identified as for TYPE 1 transmission via at least one of the below manners:

● The serving cell and/or BWP that the DL assignment is for. In one example implementation, the serving cell/BWP may be configured with an indication to indicate such serving cell/BWP to be for TYPE 1 transmission.

● The PDCCH timing position where the DL assignment is received (e.g., the PDCCH search space) . For example, the PDCCH timing position may be configured for scheduling TYPE 1 transmission where the DL assignment is received.

● The PDCCH frequency position where the DL assignment is received (e.g., the PDCCH CORESET) . For example, the PDCCH frequency position is configured for scheduling TYPE 1 transmission where the DL assignment is received.

● The HARQ Process Id which is indicated in the DL assignment. For example, the HARQ process indicated by such HARQ process Id may be configured for TYPE 1 transmission.

● An indication in the PDCCH to which the DL assignment is addressed to indicate that the UL grant is for TYPE 1 transmission.

● An indication configured in a Logical channel or radio bearer to indicate the logical channel or radio bearer where the data is for TYPE 1 transmission. For example, DL assignment can be determined implicitly as the UL grant for the TYPE 1 transmission by at least one of the following methods:

○ There may be an LCH/RB factor mapping relationship between LCH/RB and serving cells/BWPs. The UL grant for the mapped serving cells/BWPs may be s determined as UL grant for TYPE 1 transmission.

In some example implementations of STEP 2 above for the DL assignment, only HARQ process ID may be indicated for both header/control information and source data block. In some example implementations for the new transmission, more than 1 HARQ process IDs may be indicated for header/control information and source data block respectively.

In some example implementation of STEP 3 above for TB or sub- (TB) , the TB may be split into at least two sub-TBs, where at least one sub-TB may need the HARQ related operation, whereas at least one sub-TB may not need the HARQ related operation.

In some other example implementation of STEP 3 of allocating sub-TBs to the HARQ processes, the MAC entity may allocate all sub-TBs of one TB to one HARQ process. In this example, one HARQ process may have at least two independent HARQ buffers to accommodate every sub-TB received from lower layer. In some other example implementation of STEP 3 for allocating sub-TBs to the HARQ processes, the MAC entity may allocate each sub-TBs of one TB to a diverse HARQ process.

In some other example implementations of STEP 3 above for the HARQ processes, HARQ process grouping may be introduced, where one HARQ entity may have more than one HARQ process groups, and at least one HARQ process group have the HARQ related operation, whereas at least one HARQ process group do not have the HARQ related operation. In another example implementations of step 3 above for the HARQ processes, one HARQ process having HARQ related operation may be from a HARQ entity, whereas one HARQ process not having HARQ related operation may be from another HARQ entity. In this example implementation, a serving cell or cell group may be configured with at least two HARQ entities, where two sub-TBs received by MAC entity may be sent to two HARQ processes with a same HARQ process Id in different HARQ entities. In one example, 2N HARQ processes may be operated in one HARQ entity, among which the first/second half HARQ process Ids may be used for the transmission that needs HARQ related operation, whereas the second/first half HARQ process Ids may be used for the transmission that does not need HARQ related operation. In this example implementation, one sub-TB may be sent to a HARQ process with HARQ process Id= x, whereas the other sub-TB may be sent to the HARQ process with HARQ process Id= x+n.

In some example implementations for splitting the TB associated with one HARQ process into multiple sub-TBs, the size each sub-TB may be indicated in the PDCCH. In some other example implementations, the size of first sub-TB in a TB may be indicated in the front of the MAC PDU associated with the TB.

In some other example implementations of STEP 5 above, a TB containing multiple sub-TBs may be considered as successfully decoded if and only if all sub-TBs and/or HARQ processes related to the TB are successfully decoded.

In some other example implementations of STEP 5 above, a TB containing multiple sub-TBs may be considered as successful decoded if the sub-TBs that need HARQ related operation are decoded successfully.

In some other example implementations of STEP 5 above, the TB are considered as not successfully decoded if retransmission times of one sub-TB of the TB has reached a pre-defined or pre-configured maximum number.

In some example implementations, the ACK/NACK signaling above may include or indicate one or more of the following information items:

● a sub-TB indication to indicate which sub-TB is ACKed or NACKed.

● a HARQ Process ID to indicate which HARQ process is ACKed and NACKed.

● a Code Block Group (CBG) indication to indicate which CBG (s) of the indicated sub-TB is ACKed or NACKed.

In some example implementations, the HARQ related operation, if needed, may be performed at the MAC layer. A UL transmission may be implemented in the following example steps:

● STEP 1: the MAC entity of a UE may determine whether the UL grant is for TYPE 1 transmission upon the UL grant being received from lower layer. If it is determined that the UL grant is for TYPE 1 transmission, continue to STEP 2. Otherwise, the procedure ends.

● STEP 2: the MAC entity of the UE may determine the transmission is an initial transmission or a re-transmission) .

● STEP 3a: if the transmission type is a new transmission, the MAC entity of the UE may perform a multiplexing and assembling of a MAC PDU, and then generate and deliver the TB for the MAC PDU to the HARQ process indicated in UL grant.

● STEP 3b: if the transmission type is a re-transmission, the MAC entity of the UE may deliver the UL grant and HARQ information for the TB to the HARQ process for retransmission.

● STEP 4: the MAC entity may instruct a lower layer to initiate a UL transmission (e.g., initial transmission or retransmission) .

In some example implementations of STEP 1 above, the UL grant may be identified as UL grant for TYPE 1 transmission by at least one of the below solutions:

● The PDCCH frequency position where the UL grant is received (e.g., the PDCCH CORESET) . For example, the PDCCH frequency position may be configured for scheduling TYPE 1 transmission where the UL grant is received.

● The HARQ Process Id which is indicated in the UL grant. For example, the HARQ process indicated by such HARQ process Id may be configured for TYPE 1 transmission.

In some example implementations of STEP 2 for the case of re-transmission, the PDCCH to which the UL grant is addressed to may contain the indications to indicate a retransmission, the indication may be at least one of the following information:

● A HARQ process Indication: to indicate which HARQ process to be scheduled as retransmission.

● A Retransmission granularity level indication: to indicate the retransmission granularity level. For example, the retransmission may be for the part of the MAC PDU that needs HARQ operation, or the retransmission may be for the part of the MAC PDU that does not need HARQ related operation, or the retransmission may be for the whole MAC PDU.

● A HARQ group indication: to indicate which HARQ Group of the part of MAC PDU that needs HARQ operation to be scheduled as retransmission.

● A Retransmission indication: to indicate such UL grant is for retransmission associated the indicated HARQ process Id and/or HARQ group. In one example implementation, the retransmission indication may be a toggled NDI value compare to the NDI value received from the previous UL grant for the indicated HARQ process Id.

In some example implementations of STEP 3a for generating MAC PDU for initial transmission above, the HARQ related information (e.g., HARQ header) for a MAC PDU may be attached to the front of header or control information part of a MAC PDU.

In some example implementation, the HARQ related information above (e.g., HARQ header) for the MAC PDU may include the at least one of the following information items:

● The size of the part of a MAC PDU that needs HARQ related information (e.g., the header or control information part) .

● The redundant/checking bits for the HARQ related operation on the part of MAC PDU that needs HARQ related operation.

In some example implementation of STE 3a for generating MAC PDU for initial transmission above, the header or control information part of a MAC PDU may be grouped/split into multiple groups (e.g., HARQ groups) . The HARQ related information (e.g., HARQ header) may be attached to the front of each HARQ group or attached to the front of the header or control information part of a MAC PDU.

In above example implementations, the HARQ related information above (e.g., HARQ header) for the HARQ groups of one MAC PDU may include/indicate the at least one of the following information items:

● The number of HARQ groups for the HARQ operation on the part of MAC PDU that needs HARQ related operation.

● The size of each HARQ group for the HARQ operation on the part of MAC PDU that needs HARQ related operation.

● The redundant/checking bits for the HARQ related operation on each HARQ group.

In some example implementations of STEP 3b above, the re-transmission may be for the part of the MAC PDU (e.g., the header or control signaling part) that needs HARQ related operation, or for the part of the MAC PDU (e.g., the payload or source data block) that does not need HARQ related operation, or the whole MAC PDU upon the indication from the UL grant.

In some example implementations of STEP 3b above for generating the MAC PDU for the re-transmission, the MAC PDU stored in the HARQ process buffer may be pushed into multiplexed and assembly entity and may regenerate a MAC PDU by eliminating the part that does not need HARQ related operation and/or the part that has been ACKed.

In some example implementations, the HARQ related operation, if needed, may be performed at the MAC layer. A DL transmission may be implemented in the following example steps:

● STEP 1: The UE may determine whether the received DL assignment is for TYPE 1 transmission or not. If it is determined that the DL assignment is for TYPE 1 transmission, continue to STEP 2. Otherwise, the procedure ends.

● STEP 2: The MAC entity of the UE may process the DL assignment, and determine the transmission type (e.g., initial transmission or re-transmission) .

● STEP 3: The MAC entity of the UE may allocate the TB (s) received from a lower layer to the HARQ processes.

● STEP 4: The MAC entity of the UE may attempt to decode the received TB (s) , and check the MAC PDU with the attached HARQ related information.

● STEP 5a: If the received TB (s) is not decodable and/or the HARQ operation for the MAC PDU fails, the MAC layer of the UE may instruct the lower layer to generate a NACK signaling for the received TB.

● STEP 5b: If the received TB (s) is successfully decoded, and the MAC PDU has successfully passed the HARQ operation, the MAC entity of the UE may deliver the decoded MAC PDU to a disassembling and de-multiplexing entity and instruct the lower layer to generate an ACK signaling.

In some example implementations of STEP 1, the identification of the DL assignment for TYPE 1 transmission may be implemented in at least one of the below manners:

● The serving cell and/or BWP that the DL assignment is for, in one example implementation, the serving cell/BWP may be configured with an indication to indicate such serving cell/BWP to be for TYPE 1 transmission.

● The PDCCH timing position where the DL assignment is received (e.g., the PDCCH search space) , the PDCCH timing position is configured for scheduling TYPE 1 transmission where the DL assignment is received.

● The PDCCH frequency position where the DL assignment is received (e.g., the PDCCH CORESET) , the PDCCH frequency position is configured for scheduling TYPE 1 transmission where the DL assignment is received.

● The HARQ Process Id which is indicated in the DL assignment, the HARQ process indicated by such HARQ process Id is configured for TYPE 1 transmission.

In some example implementations of STEP 2, the retransmission may be either a retransmission of the part of the MAC PDU that needs the HARQ related operation (e.g., the header information and/or control information) , or a retransmission of the part of the MAC PDU that does not need the HARQ related operation (e.g., the source data block or payload) , or a retransmission of the whole MAC PDU (e.g., both the part with HARQ related operation and the part without HARQ related operation) .

In some example implementations of STEP 2 for the case of re-transmission, the PDCCH to which the DL assignment may be addressed to may contain the indications to indicate a retransmission, the indication may be at least one of the following information:

● A CBG indication: to indicate that the CBGs of the part of MAC PDU that needs HARQ operation to be scheduled as retransmission. In one implementation, the CBG indication is optionally present in PDCCH, it may be only present in PDCCH when the retransmission is for the part of the MAC PDU that needs HARQ operation.

● A Retransmission indication: to indicate such DL assignment is for retransmission associated with the indicated HARQ process Id. In one example implementation, the retransmission indication may be a toggled NDI value compare to the NDI value received from the previous UL grant for the indicated HARQ process Id.

In some example implementations of STEP 5a, the NACK signaling format may be implemented as one of:

● a PUCCH signaling format.

● a PUSCH signaling format.

● a UL MAC CE.

Such signaling format may contain at least one of the following information items:

● The HARQ Process ID.

● The part of MAC PDU indication to indicate which part of MAC PDU has failed to be received, e.g., the part with HARQ related operation, or the part without HARQ related operation, or both.

● The HARQ Group indication for the part of MAC PDU that needs HARQ related operation.

Error-Free Transmission and Error-Tolerance Transmission –Switch Between the New Transmission Type and Legacy Transmission Type

In some example implementations, a switch between the new transmission type (e.g., semantic transmission) and the legacy transmission type (e.g., symbol based transmission) may be implemented on the network side including the following example steps, as shown in FIG. 17:

● STEP 1: The control signaling to activate/deactivate the HARQ operation for the new type transmission may be received from the NW side.

● STEP 2: The UE may perform an activation/deactivation of the HARQ operation for the new type transmission according to the received control signaling.

In STEP 1, in one implementation, the control signaling may be implemented as a lower layer signaling, e.g., a PDCCH signaling containing an indication to indicate whether the HARQ operation is activated for the scheduled HARQ process Id by such PDCCH. In one implementation of the indication, one bit in the PDCCH may be used, the value ‘1’ of such bit means the HARQ operation may be activated for this transmission schedule by the PDCCH, while the value ‘0’ of such bit means the HARQ operation may be deactivated for this transmission schedule by the PDCCH.

In some other example implementations of STEP 2 above, the control signaling may be a high layer signaling, e.g., a MAC CE, an SDAP/PDCP/RLC control PDU. Such control signaling may indicate or include at least one of the following information items:

● A logical path indication to indicate one or more logical paths from which the new type data transmission is activated or deactivated. In one implementation, the logical path may be a radio bearer. In another implementation, the logical path may be logical channel. In another implementation, the logical path may be an RLC entity, PDCP entity, or SDAP entity, or mix of any of them.

● an activation/deactivate indication to indicate an activation/deactivation of the HARQ operation for the indicated logical paths in the same control signaling.

● A serving cell/BWP indication to indicate one or more serving cells where the new type transmission is activated or deactivated.

In some example implementations of STEP 2 above for the activation/deactivation HARQ related operation, a lower layer may deactivate HARQ related operation for the data block or TB corresponding to a HARQ process if the received PDCCH indicating that the new type transmission is deactivated for the indicated HARQ process. Otherwise, the lower layer may activate the HARQ related operation for the data block or TB corresponding to the indicated HARQ process.

In some other example implementations of STEP 2 above for the activation/deactivation of HARQ operation a higher layer may deactivate the HARQ related operation for the data transmission for which the data from the indicated logical path if a received control signaling indicating that the new type transmission is deactivated for the indicated logical path. Otherwise, the higher layer may activate the HARQ related operation for the data block or TB from the indicated logical path.

In some other example implementation of STEP 2 above for the activation/deactivation of HARQ operation, the activation/deactivation of HARQ operation may be performed by switching of the transmission type (e.g., switch from TYPE 1 transmission to TYPE 2 transmission, or switch from TYPE 2 transmission to TYPE 1 transmission) . The activation of HARQ operation may be associated with a switch from TYPE 1 transmission to TYPE 2 transmission, whereas the deactivation of HARQ operation may be associated with a switch from TYPE 2 transmission to TYPE 1 transmission. The TYPE 1 transmission and TYPE 2 transmission have been defined above.

In some example implementations, a switch between the new transmission type (e.g., semantic transmission) and the legacy transmission type (e.g., symbol based transmission) may be implemented on the UE side including the following example steps, as shown in FIG. 18:

● STEP 1: A configuration (e.g., an RRC configuration) may be received for the new type transmission by the UE from the NW.

● STEP 2: The UE may start performing the measurement (s) with respect to the new type transmission and calculate transmission metrics.

● STEP 3a: The UE may send a request of activation/deactivation of the new type transmission to the NW.

● STEP 3b (alternative to STEP 3a) : The UE may send a notification of activation/deactivation of the new type transmission to the NW.

● STEP 4: The UE may receive a response to the notification/request in STEP 3 from the NW.

In some example implementations of STEP 1 above, the RRC configuration for the new type transmission may indicate or include at least one of the following information items:

● A benchmark for the UE to determine the activation/deactivation of the new type transmission, which may include one of a threshold/benchmark value of SINR, a threshold/benchmark value of RSRP, a threshold/benchmark value of RSRQ, or a threshold/benchmark value of transmission failure ratio/transmission failure times.

● A period for the UE to perform the measurement to determine the activation/deactivation of the new type transmission, which may include at least one of a COUNTER with a maximum number value or a time period for a measurement.

● The reference signaling (or signaling set) (e.g., CSI-RS, SSB, and the like) used for the measurement (s) .

In some example implementations of STEP 2 above, the UE may perform the measurement (s) on reference signals for the new type transmission. In case that the new transmission type is activated, if the measurement result is lower than a threshold in a certain period, the UE may determine that the new type transmission for the HARQ process/logical path needs to be deactivated.

In some example implementations of STEP 2 above, the UE may perform the calculation of the transmission failure times/ratios in a period of time to determine the activation/deactivation of the NW type transmission for a HARQ process and/or logical path. For example, the transmission failure times/ratios may be calculated based on the header information/control information. For another example, in case that the new transmission type for a HARQ process or logical path is activated, if a number of failure transmission reaches a pre-defined a maximum value in a certain time period, the UE may determine to deactivate the new type transmission for the HARQ process or the logical path. In such implementations, a counter to track the number of transmission failures may be included, and the timer period described above may be predetermined and defined.

In some example implementations of STEP 2 above, in case that the new transmission type for a HARQ process or logical path is activated, if the failure transmission ratios reaches a pre-defined a maximum value in a certain time period, the UE may determine to deactivate the new type transmission for the HARQ process or the logical path. In such implementations, two counters to count the number of transmission failures may be included. One of the counters, for example, may be configured for the total number of transmission times, whereas the other one of the counters may be configured for tracking the total number of transmission failure times. The timer period above may be predetermined and defined.

In some example implementations of STEP 2 above, the UE may perform the measurement (s) on reference signals for the new type transmission. In case that the new transmission type has been deactivated, if the measurement result is higher than a threshold in a certain period, the UE may determine that the new type transmission for the HARQ process/logical path can be activated.

In some example implementations of STEP 3 above, the request/notification message may be of at least one of the following formats:

● Higher layer signaling, including a UL RRC signaling for, e.g., the UE assistance information, or a UL MAC CE, an SDAP/PDCP/RLC Control PDU.

● Lower layer signaling, include a PUCCH signaling, a PUSCH signaling, or the like.

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:

● An indication of logical path to indicate the logical path where the new type transmission may need to be activated/deactivated.

● An indication of HARQ process to indicate the HARQ process where the new type transmission may need to be activated/deactivated.

● An activation/deactivation indication to indicate the activation/deactivation of the new type transmission for the indicated HARQ process and/or logical path.

In some example implementations of STEP 4 above, the response message from the NW may be a control signaling to activate/deactivate the new type transmission to the HARQ process and/or logical path.

The description and accompanying drawings above provide specific example embodiments and implementations. The described subject matter may, however, be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any example embodiments set forth herein. A reasonably broad scope for claimed or covered subject matter is intended. Among other things, for example, subject matter may be embodied as methods, devices, components, systems, or non-transitory computer-readable media for storing computer codes. Accordingly, embodiments may, for example, take the form of hardware, software, firmware, storage media or any combination thereof. For example, the method embodiments described above may be implemented by components, devices, or systems including memory and processors by executing computer codes stored in the memory.

Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, 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 a different embodiment. It is intended, for example, that claimed subject matter includes combinations of example embodiments in whole or in part.

In general, terminology may be understood at least in part from usage in context. For example, terms, such as “and” , “or” , or “and/or, ” as used herein may include a variety of meanings that may depend at least in part on the context in which such terms are used. Typically, “or” if used to associate a list, such as A, B or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B or C, here used in the exclusive sense. In addition, the term “one or more” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as “a, ” “an, ” or “the, ” may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for existence of additional factors not necessarily expressly described, again, depending at least in part on context.

Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present solution should be or are included in any single implementation thereof. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present solution. Thus, discussions of the features and advantages, and similar language, throughout the specification may, but do not necessarily, refer to the same embodiment.

Furthermore, the described features, advantages and characteristics of the present solution may be combined in any suitable manner in one or more embodiments. One of ordinary skill in the relevant art will recognize, in light of the description herein, that the present 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 may be recognized in certain embodiments that may not be present in all embodiments of the present solution.

Claims

A method performed by a wireless terminal in communication with a network node in a wireless network, the method comprising:

receiving a configuration from the network node for managing a set of semantic models, the set of semantic models comprising at least one terminal side encoding model and at least one network side decoding model;

receiving a first control signaling from the network node for activating the set of semantic models for a semantic communication between the wireless terminal and the wireless network;

receiving reference data from the network node;

monitoring a performance of the semantic communication and generating a set of performance metrics for the semantic communication based on the monitored performance and the reference data;

transmitting the set of performance metrics to the network node; and

receiving a second control signaling from the network node generated by the network node in response to the set of performance metrics to effectuate a modification of an operation of the at least one terminal side encoding model or a provisioning of a transmission channel for the semantic communication.
The method of claim 1, wherein the network node comprises a core network node.
The method of claim 2, wherein the configuration is sent via a protocol tunnel between the core network node and a non-access stratum layer of the wireless terminal.
The method of claim 3, wherein the protocol tunnel is transparent to a radio access network that connects the wireless terminal to the core network node.
The method of claim 3, wherein the core network node comprises a semantic communication manage function (SCMF) of the core network.
The method of claim 5, wherein the SCMF is configured to perform at least one of:

a model management for the semantic communication;

decoding and/or encoding of user-plane (UP) data for the semantic communication from a User Plane Function (UPF) of the core network or the wireless terminal;

regulation of Quality of Service (QoS) flows of the semantic communication;

regulation of PDU sessions associated with the semantic communication;

transmission and/or reception of data units for the semantic communication; or

subheader attachment/detachment to data units for the semantic communication.
The method of claim 2, wherein the first control signaling and/or the second control signaling are sent by an Access Management Function (AMF) of the core network.
The method of claim 1, wherein the network node is base station.
The method of claim 8, wherein the configuration is transmitted via a Radio Resource Control (RRC) message.
The method of claim 1, wherein the first control signaling and second control signaling are transmitted via one of an RRC message, a Package Data Convergence Protocol (PDCP) control Protocol Data Unit (PDU) , a Radio Link Control (RLC) control PDU, a Media Access Control (MAC) Control Element (MAC CE) , or a physical layer control signaling.
The method of claim 1, wherein the set of performance metrics are transmitted via one of an RRC message, a PDCP control PDU, an RLC control PDU, a MAC CE, or a physical layer control signaling.
The method of claim 1, wherein the reference data are transmitted via one of an RRC message, a PDCP control PDU, an RLC control PDU, a MAC CE, or a physical layer control signaling.
The method of claim 1, wherein the reference data comprises a set of benchmark data or a set of benchmark data pairs for accessing the performance of the semantic communication.
The method of claim 13, wherein the reference data is signaled via a protocol tunnel.
The method of claim 13, wherein the reference data originates from a pre-stored database or generated from a real transmission.
The method of claim 1, wherein the first control signaling comprises at least one of:

a model identity for the at least one terminal side encoding model;

a model description information item for the at least one terminal side encoding model;

a PDU session ID for the semantic communication;

a Quality of Service (QoS) flow ID for the semantic communication;

a logic channel (LCH) ID for the semantic communication; or

a Data Radio Bearer ID for the semantic communication.
A method performed by a wireless terminal in communication with a network node in a wireless network, the method comprising:

receiving a configuration from the network node for managing a set of semantic models, the set of semantic models comprising at least one terminal side encoding model and at least one network side decoding model;

receiving a first control signaling from the network node for activating the set of semantic models for a semantic communication between the wireless terminal and the wireless network;

transmitting reference data to the network node;

receiving a second control signaling from the network node generated by the network node in response to a set of performance metrics for the semantic communication calculated by the network node based on comparing a set of monitored performance of the semantic communication to the reference data; and

effectuate a modification of an operation of the at least one terminal side encoding model or a provisioning of a transmission channel for the semantic communication based on the second control signaling.
The method of claim 17, wherein the network node comprises a core network node.
The method of claim 18, wherein the configuration is received via a protocol tunnel between the core network node and a non-access stratum layer of the wireless terminal.
The method of claim 19, wherein the protocol tunnel is transparent to a radio access network that connects the wireless terminal to the core network node.
The method of claim 19, wherein the core network node comprises a semantic communication manage function (SCMF) of the core network.
The method of claim 21, wherein the SCMF is configured to perform at least one of:

a model management for the semantic communication;

decoding and/or encoding of user-plane (UP) data for the semantic communication from a User Plane Function (UPF) of the core network or the wireless terminal;

regulation of Quality of Service (QoS) flows of the semantic communication;

regulation of PDU sessions associated with the semantic communication;

transmission and/or reception of data units for the semantic communication; or

subheader attachment/detachment to data units for the semantic communication.
The method of claim 18, wherein the first control signaling and/or the second control signaling are received from an Access Management Function (AMF) of the core network.
The method of claim 17, wherein the network node is base station.
The method of claim 24, wherein the configuration is received via a Radio Resource Control (RRC) message.
The method of claim 17, wherein the first control signaling and second control signaling are received via one of an RRC message, a Package Data Convergence Protocol (PDCP) control Protocol Data Unit (PDU) , a Radio Link Control (RLC) control PDU, a Media Access Control (MAC) Control Element (MAC CE) , or a physical layer control signaling.
The method of claim 17, wherein the set of performance metrics are received via one of an RRC message, a PDCP control PDU, an RLC control PDU, a MAC CE, or a physical layer control signaling.
The method of claim 17, wherein the reference data are transmitted via one of an RRC message, a PDCP control PDU, an RLC control PDU, a MAC CE, or a physical layer control signaling.
The method of claim 17, wherein the reference data comprises a set of benchmark data or a set of benchmark data pairs for accessing the performance of the semantic communication.
The method of claim 29, wherein the reference data is signaled vial a protocol tunnel.
The method of claim 29, wherein the reference data originates from a pre-stored database or generated from a real transmission.
The method of claim 17, wherein the first control signaling comprises at least one of:

a model identity for the at least one terminal side encoding model;

a model description information item for the at least one terminal side encoding model;

a PDU session ID for the semantic communication;

a Quality of Service (QoS) flow ID for the semantic communication;

a logic channel (LCH) ID for the semantic communication; or

a Data Radio Bearer ID for the semantic communication.
A method performed by a network node in communication with a wireless terminal in a wireless network, the method comprising:

transmitting a configuration to the wireless terminal for managing a set of semantic models, the set of semantic models comprising at least one terminal side encoding model and at least one network side decoding model;

transmitting a first control signaling to the wireless terminal for activating the set of semantic models for a semantic communication between the wireless terminal and the wireless network;

transmitting reference data to the wireless terminal;

receiving a set of performance metrics of the semantic communication from the wireless terminal, the set of performance metrics of the semantic communication being generated by the wireless terminal based on a performance of the semantic communication monitored by the wireless terminal and the reference data;

generating a second control signaling in response to the set of performance metrics; and

transmitting a second control signaling to the wireless terminal to effectuate a modification of an operation of the at least one terminal side encoding model or a provisioning of a transmission channel for the semantic communication.
The method of claim 33, wherein the network node comprises a core network node.
The method of claim 34, wherein the configuration is transmitted via a protocol tunnel between the core network node and a non-access stratum layer of the wireless terminal.
The method of claim 35, wherein the protocol tunnel is transparent to a radio access network that connects the wireless terminal to the core network node.
The method of claim 35, wherein the core network node comprises a semantic communication manage function (SCMF) of the core network.
The method of claim 37, wherein the SCMF is configured to perform at least one of:

a model management for the semantic communication;

decoding and/or encoding of user-plane (UP) data for the semantic communication from a User Plane Function (UPF) of the core network or the wireless terminal;

regulation of Quality of Service (QoS) flows of the semantic communication;

regulation of PDU sessions associated with the semantic communication;

transmission and/or reception of data units for the semantic communication; or

subheader attachment/detachment to data units for the semantic communication.
The method of claim 34, wherein the first control signaling and/or the second control signaling are sent by an Access Management Function (AMF) of the core network.
The method of claim 33, wherein the network node is base station.
The method of claim 40, wherein the configuration is transmitted via a Radio Resource Control (RRC) message.
The method of claim 33, wherein the first control signaling and second control signaling are transmitted via one of an RRC message, a Package Data Convergence Protocol (PDCP) control Protocol Data Unit (PDU) , a Radio Link Control (RLC) control PDU, a Media Access Control (MAC) Control Element (MAC CE) , or a physical layer control signaling.
The method of claim 33, wherein the set of performance metrics are transmitted via one of an RRC message, a PDCP control PDU, an RLC control PDU, a MAC CE, or a physical layer control signaling.
The method of claim 33, wherein the reference data are transmitted via one of an RRC message, a PDCP control PDU, an RLC control PDU, a MAC CE, or a physical layer control signaling.
The method of claim 33, wherein the reference data comprises a set of benchmark data or a set of benchmark data pairs for accessing the performance of the semantic communication.
The method of claim 45, wherein the reference data is signaled vial a protocol tunnel.
The method of claim 45, wherein the reference data originates from a pre-stored database or generated from a real transmission.
The method of claim 33, wherein the first control signaling comprises at least one of:

a model identity for the at least one terminal side encoding model;

a model description information item for the at least one terminal side encoding model;

a PDU session ID for the semantic communication;

a Quality of Service (QoS) flow ID for the semantic communication;

a logic channel (LCH) ID for the semantic communication; or

a Data Radio Bearer ID for the semantic communication.
A method performed by a network node in communication with a wireless terminal in a wireless network, the method comprising:

transmitting a configuration from the network node for managing a set of semantic models, the set of semantic models comprising at least one terminal side encoding model and at least one network side decoding model;

transmitting a first control signaling from the network node for activating the set of semantic models for a semantic communication between the wireless terminal and the wireless network;

receiving reference data from the wireless terminal;

monitoring a performance of the semantic communication and generating a set of performance metrics for the semantic communication based on the monitored performance and the reference data;

generating a second control signaling in response to the set of performance metrics; and

transmitting the second control signaling to the wireless terminal to effectuate a modification of an operation of the at least one terminal side encoding model or a provisioning of a transmission channel for the semantic communication based on the second control signaling.
The method of claim 49, wherein the network node comprises a core network node.
The method of claim 50, wherein the configuration is transmitted via a protocol tunnel between the core network node and a non-access stratum layer of the wireless terminal.
The method of claim 51, wherein the protocol tunnel is transparent to a radio access network that connects the wireless terminal to the core network node.
The method of claim 51, wherein the core network node comprises a semantic communication manage function (SCMF) of the core network.
The method of claim 53, wherein the SCMF is configured to perform at least one of:

a model management for the semantic communication;

decoding and/or encoding of user-plane (UP) data for the semantic communication from a User Plane Function (UPF) of the core network or the wireless terminal;

regulation of Quality of Service (QoS) flows of the semantic communication;

regulation of PDU sessions associated with the semantic communication;

transmission and/or reception of data units for the semantic communication; or

subheader attachment/detachment to data units for the semantic communication.
The method of claim 50, wherein the first control signaling and/or the second control signaling are received from an Access Management Function (AMF) of the core network.
The method of claim 49, wherein the network node is base station.
The method of claim 56, wherein the configuration is transmitted via a Radio Resource Control (RRC) message.
The method of claim 49, wherein the first control signaling and second control signaling are transmitted via one of an RRC message, a Package Data Convergence Protocol (PDCP) control Protocol Data Unit (PDU) , a Radio Link Control (RLC) control PDU, a Media Access Control (MAC) Control Element (MAC CE) , or a physical layer control signaling.
The method of claim 49, wherein the reference data are received via one of an RRC message, a PDCP control PDU, an RLC control PDU, a MAC CE, or a physical layer control signaling.
The method of claim 49, wherein the reference data comprises a set of benchmark data or a set of benchmark data pairs for accessing the performance of the semantic communication.
The method of claim 60, wherein the reference data is signaled vial a protocol tunnel.
The method of claim 60, wherein the reference data originates from a pre-stored database or generated from a real transmission.
The method of claim 49, wherein the first control signaling comprises at least one of:

a model identity for the at least one terminal side encoding model;

a model description information item for the at least one terminal side encoding model;

a PDU session ID for the semantic communication;

a Quality of Service (QoS) flow ID for the semantic communication;

a logic channel (LCH) ID for the semantic communication; or

a Data Radio Bearer ID for the semantic communication.
The wireless terminal or network node of any one of claims 1-63, the wireless terminal or the network node comprising a processor and a memory, wherein the processor is configured to read computer code from the memory to cause the wireless terminal or the network node to perform the method of any one of claims 1-63.
A computer program product comprising a non-transitory computer-readable program medium with computer code stored thereupon, the computer code, when executed by a processor of the wireless terminal or the network node of any one of claims 1-63, causing the processor to implement the method of any one of claims 1-63.