TW202316860A - Method and apparatus for code block groups and slices mapping in mobile communications - Google Patents

Abstract

Various solutions for code block groups and slices mapping in a frame of stream with respect to user equipment and network apparatus in mobile communications are proposed. An apparatus obtains an intra slice and a plurality of predictive slices. The apparatus determines a number of code blocks in the code block group and a number of code block groups in the transport block. The apparatus maps the intra slice and the predictive slices to each of the code block groups respectively. The apparatus transmits the code block groups. The apparatus receives a plurality of hybrid automatic repeat request (HARQ) feedbacks corresponding to the code block groups. The apparatus determines whether to retransmit any of the intra slice and the predictive slices according to the HARQ feedbacks.

Description

Method and device for code block group and slice mapping in mobile communication

The present invention relates generally to stream processing, and more particularly to sets of blocks mapped to slices in frames of streams associated with user equipment and network devices in mobile communications.

Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims listed below and are not admitted to be prior art by inclusion in this section.

A video image encoded with the High Efficiency Video Coding (HEVC) standard may be divided into one or a plurality of slices, wherein each slice is composed of non-overlapping macroblocks as minimum coding units. Each slice can be encoded as an intra slice (I-slice), a predictive slice (P-slice) or a bi-directional slice (B-slice), and the compressed data is packaged into slice data . Because slices are processed independently, errors or missing data from one slice cannot propagate to any other slice in the graph.

For 30Mbps cloud gaming (cloud gaming, CG), the average packet size is 62500 bytes, and the maximum packet size is 93750 bytes. For augmented reality (AR) or virtual reality (VR) at 45Mbps, the average packet size is 93750 bytes and the maximum packet size is 140625 bytes. The largest transport block (TB) size in new radio (NR) is 157709 bytes. Therefore, one video frame can fit in one TB. When a slice of a video frame is sent in a TB, if the user equipment (UE) cannot correctly decode the TB, it needs to retransmit the entire TB. This will result in a waste of resources.

In NR Release 15, the code block group (code block group, CBG) transmission is specified by packing the code block (code block, CB) of the transport block (transport block, TB) into a code block group. The purpose is to reduce retransmission resources, thereby improving spectral efficiency and system capacity by retransmitting only CBGs with erroneous code blocks. In general, CBG is not widely used today due to its complexity, but it is worth considering enhancements for applications beyond 5th Generation (B5G) and 6th Generation (6G) onwards Useful, such as AR, VR, extended reality (XR) and holographic communications that require very high data rates and high reliability/low latency.

The following summary is illustrative only and not intended to be limiting in any way. That is, the following summary is provided to introduce the concepts, highlights, benefits and advantages of the novel and non-obvious technologies described in this disclosure. Selected embodiments are further described below in the detailed description. Accordingly, the following summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.

The purpose of the present invention is to propose a solution or solution to the above mentioned problems. More specifically, the various schemes proposed in the present invention are considered to solve the problems related to the block groups mapped to intra-slices and predictive slices of frames in a stream for UE and network devices in mobile communications.

In one aspect, a method may include an apparatus obtaining a plurality of slices consisting of an inner slice and a plurality of predicted slices of a frame of a stream. The method may also include the means determining the number of code blocks in the transport block and the number of groups of code blocks in the transport block. The method may further comprise means for respectively mapping the inner slice and the predicted slice to each code block group. The method may also include the device transmitting the set of code blocks. The method may further include the apparatus receiving a plurality of hybrid automatic repeat request (HARQ) feedbacks corresponding to the code block groups. The method may further include the apparatus determining whether to retransmit any one of the inner slice and the predicted slice according to the HARQ feedback.

In another aspect, a method may include an apparatus obtaining a plurality of slices consisting of an inner slice and a plurality of predicted slices of a frame of a stream. The method may further include the apparatus sending the intra chip on a first physical downlink shared channel (physical downlink share channel, PDSCH). The method may also include the apparatus transmitting at least one of the predicted slices on a second PDSCH. The method may also include the apparatus receiving HARQ feedback. The method may further include the apparatus determining whether to retransmit any one of the inner slice and the predicted slice according to the HARQ feedback.

In another aspect, a method may include an apparatus obtaining a plurality of slices consisting of an inner slice and a plurality of predicted slices of a frame of a stream. The method may further include the device sending a physical downlink control channel (PDCCH) to schedule the plurality of PDSCHs. The method may also include the device sending the inner slice and the predicted slice on the PDSCH. The method may also include the apparatus receiving HARQ feedback. The method may further include the apparatus determining whether to retransmit any one of the inner slice and the predicted slice according to the HARQ feedback.

According to the method and device for code block group and slice mapping in mobile communication provided by the present invention, the efficiency of stream transmission can be improved to reduce delay.

Detailed examples and implementations of the claimed subject matter are disclosed herein. It is to be understood, however, that the disclosed examples and implementations are merely illustrations of the claimed subject matter that can be embodied in various forms. However, this invention may be embodied in many different forms and should not be construed as limited to the exemplary embodiments and implementations set forth herein. Rather, these exemplary embodiments and implementations are provided so that the description of the present invention will be thorough and complete, and will fully convey the scope of the present invention to those skilled in the art. In the following description, well-known features and technical details may be omitted to avoid unnecessarily obscuring the presented embodiments and implementations. overview

Embodiments in accordance with the present invention relate to various techniques, methods, schemes and/or solutions related to block group and slice mapping in frames of a stream. According to the invention, several possible solutions can be implemented individually or in combination. That is, although these possible solutions may be described individually below, two or more of these possible solutions may be implemented in one combination or another.

In NR release 15, CBG transmission is specified by packing the code blocks of a TB into code block groups. The goal is to reduce retransmission resources, thereby improving spectral efficiency and system capacity by retransmitting only CBGs with erroneous code blocks. In general, CBG is not widely used today due to its complexity, but it is worth considering enhancements for use in B5G and 6G such as Augmented Reality AR, Virtual Reality VR, Extended Reality XR and very high profile Applications for high-speed, high-reliability, and low-latency holographic communications.

In view of the above situation, the present invention proposes various schemes related to CBG and slice mapping in frames of streams related to UE, base station and core network. According to the scheme of the present invention, CBG encapsulation and mapping to slices are supported. A sending device (eg, a network node or UE) may map each slice of the stream to one of the CBGs, and then send the CBGs to a receiving device (eg, UE or network node). The receiving device can send multiple HARQ feedbacks corresponding to the CBGs to the sending device, so that the sending device can know which CBG needs to be retransmitted according to the HARQ feedback. Therefore, by applying the solution of the present invention, the performance of streaming transmission can be improved to reduce delay. Applications with streaming requirements can benefit from the enhancements achieved by embodiments of the present invention.

The first embodiment of the present invention is shown in Fig. 1 to Fig. 5 . Figure 1 illustrates an example scenario 100 under a scenario according to an embodiment of the invention. Scene 100 illustrates an example of slice and CBG mapping and transfer. Scenario 100 includes UE 110, base station 120, and core network 130, which are part of a wireless communication network (eg, NR network). The base station 120 can obtain a plurality of slices S1-S8 of the frame of the stream. The stream can be a video stream or an audio stream. An Application Data Unit (ADU) can be used for the nuances of video frame transmission and processing. ADU can be a set of Internet Protocol (IP) packets.

Fig. 2 shows an example scene 200 under a scenario according to an embodiment of the present invention, and Fig. 3 illustrates an example scene 300 under a scenario according to an implementation of the present invention. Scene 200 and Scene 300 illustrate different ways to divide a frame into slices. A slice consists of an inner slice (hereinafter referred to as I-slice, also referred to as I-frame) and a plurality of predictive slices (hereinafter referred to as P-slice, also referred to as P-frame). Intra-slices may be encoded or decoded based on the information of the intra-slices. Each predictive slice can be encoded or decoded based on its own and other slices' data. It should be noted that the number of slices shown in Figure 2 and Figure 3 is for illustration and not for limiting the present invention.

。TBS表示可以由核心網路130根據調製和編碼方案(modulation and coding scheme，MCS)、每次傳輸中可以發送的最大位元以及將在緩衝器中發送的位元中的至少一個確定的傳輸塊大小。

表示1TB中CB的最大位元數，。

為8424位元。由於根據本發明，片將被一一映射到CBG，因此TB中的CBG的數量可以被配置為等於片的數量。 Base station 120 may determine the number of CBs in a TB and the number of CBGs in a transport block. When determining the number of CBs and the number of CBGs, the base station 120 may calculate the number of code blocks and the number of code block groups according to the transport block size of the transport block and the largest code block size in the transport block. Then, the base station 120 can map the inner slice and the predicted slice to each code block group respectively. Specifically, the number of CBs can be calculated as

. TBS denotes a transport block that can be determined by the core network 130 according to at least one of a modulation and coding scheme (MCS), a maximum number of bits that can be sent in each transmission, and bits to be sent in a buffer size.

Indicates the maximum number of bits of a CB in 1TB.

is 8424 bits. Since slices will be one-to-one mapped to CBGs according to the present invention, the number of CBGs in a TB can be configured equal to the number of slices.

In addition, base station 120 needs to determine the size of each CBG. Since the size of the intra-slice is usually larger than the size of each prediction slice, the size of the CBG corresponding to the inner slice may also be larger than the size of the CBG corresponding to each prediction slice. In detail, the base station 120 may determine the scale factor value according to the number of code blocks, the number of code block groups and the value of the scale factor and calculate the size of the code block group corresponding to the inner slice and the size of the code block group corresponding to each prediction slice. size.

。

表示內部片的大小，

表示預測片的大小，

表示比例因數值。由於內片和預測片的大小可以根據片（film）運動因數逐訊框變化，因此比例因數值可能隨時間變化。可以通過核心網路130(例如，XR伺服器、電腦圖形(computer graphic，CG)應用程式伺服器或轉碼器)或通過應用程式層向基地台120發送可能的比例因數值組。可以為上行鏈路（uplink，UL）業務和下行鏈路（downlink，DL）業務配置不同組的比例因數值。 The scale factor value is a multiple of the inner and predicted slices and can be expressed as

.

Indicates the size of the internal slice,

Indicates the size of the predicted slice,

Indicates the scaling factor value. Since the size of the inner and predicted slices can vary from frame to frame according to the film motion factor, the scale factor value may change over time. The set of possible scale factor values may be sent to the base station 120 via the core network 130 (eg, XR server, computer graphic (CG) application server, or transcoder) or via the application layer. Different groups of scale factor values can be configured for uplink (uplink, UL) services and downlink (downlink, DL) services.

。C表示TB中CB的數量，N表示傳輸塊中CBG的數量。基地台120可以將剩餘的CB分配給預測片。前幾個 CBG 的大小可能大於其餘 CBG。前幾個CBG的數量可以計算為

，前幾個CBG的大小可以計算為

。剩餘CBG的數量可以計算為

，剩餘CBG的大小可以計算為

。

表示前幾個 CBG的數量。 CBGs in a TB may have different sizes. When the CB is packaged as a CBG, the size of the CBG corresponding to the inner slice can be calculated as

. C represents the number of CBs in the TB, and N represents the number of CBGs in the transport block. Base station 120 may allocate the remaining CBs to prediction slices. The first few CBGs may be larger in size than the remaining CBGs. The number of the first few CBGs can be calculated as

, the size of the first few CBGs can be calculated as

. The amount of remaining CBG can be calculated as

, the size of the remaining CBG can be calculated as

.

Indicates the number of the first few CBGs.

）的數量為3，前三個CBG的每個大小為3  CB。剩餘 CBG 的數量等於 4 ，剩餘CBG 的每個大小等於 2 CB。因此，片(例如，S1-S8)可以被一對一地映射到CBG(例如，CBG 431-438)以用於傳輸。因此，可以基於一個片或一個CBG而不是整個視頻訊框或TB來執行重傳。 For example, refer to Figure 4, which is a diagram of an example CBG packet in accordance with an embodiment of the present invention. Scene 400 illustrates an example of a CBG packet and slice map. Assuming that the number of CB 4201-4223 in TB 410 is 23, the number of CBG 431-438 is 8, and the scale factor value is 2 (that is, N=8, C=23, α=2), according to the above formula, the corresponding The size of the CBG is 6 CB, and the first few CBGs (i.e.

) is 3, and the size of each of the first three CBGs is 3 CB. The number of remaining CBGs is equal to 4, and each size of remaining CBGs is equal to 2 CB. Accordingly, slices (eg, S1-S8) may be mapped one-to-one to CBGs (eg, CBGs 431-438) for transmission. Therefore, retransmission can be performed based on one slice or one CBG instead of an entire video frame or TB.

In some embodiments, the CBG size can be derived by the 5GS based on some other information (eg, content of the content). For example, background slices may have a lower priority, so the CBG hosting the background slices may have a smaller size, while motion slices may have higher priority, so the CBG hosting the motion slices may have a larger size.

In some embodiments, each slice has a priority order, and the size of each CBG is determined according to the priority order of the slices or ADUs. More specifically, slices and application data units are assigned different priorities. ADU unit can be a frame or any unit. The priority of each slice or application data unit is signaled to the base station 120 by the XR server or the transcoder on the network side (ie, the core network 130 ) or the application layer. The application layer can use the ADU as a granularity of its processing and can define the ADU in terms of the number of IP packets.

The size of the ADU may be signaled to the base station 120 by the XR server or a transcoder on the network side (eg, the core network 130 ), or by the application layer at the device (eg, the UE 110 ). In UL transmissions, the size of the ADU may be signaled by the UE application layer to lower layers (eg, physical layer). The size of an ADU defined for a video frame or slice may be different from other video frames or slices (for example, the ADU size of an I-frame is different from the ADU size of a P-frame). The IP packet size of the ADU can be fixed or variable. The size of the ADU can be adjusted dynamically (eg, via downlink control information (DCI)) or semi-statically (eg, via radio resource control (RRC) signaling) based on feedback from the device.

Additionally, different priorities can be assigned to CBGs. For example, a CBG carrying one of the static motion films has a lower priority, while a CBG carrying one of the dynamic motion films has a higher priority.

Priorities may also be defined per ADU and signaled by the core network 130 to the base stations 120 or by the application layer to lower layers. In addition, ADUs related to certain types of business may have different requirements than ADUs related to other types of business. For example, an ADU associated with an I-frame may require lower latency and higher reliability than an ADU associated with a P-frame. The base station 120 is notified of the start and end or start and duration of each ADU. In some embodiments, the base station 120 is notified of the priority of each ADU.

In some embodiments, a set of parameters may be sent from a transcoder or XR server or application layer to base station 120 and/or UE 110 . This set of parameters contains information about the ADU (eg duration, start, offset, etc.). This set of parameters is updated when information about the ADU changes. The set of parameters may be defined for each media stream (eg, video stream, audio stream, etc.).

The UE 110 may be signaled or informed about the start and last ADU in a burst/video frame. In some embodiments, the DCI bit field indicates the last ADU in the burst. In another embodiment, the last PDSCH of the burst carries information about ADUs and/or triggers UE 110 to enter sleep mode. In another embodiment, the sleep mode is triggered by the reception of the last ADU in the burst.

In some embodiments, ADU segmentation may be enabled or disabled dynamically (eg, via DCI) or semi-statically (eg, via RRC). In some implementations, an ADU header may be specified. 5GS can access ADU header. The ADU header sends information about the ADU (one or more of start, length, priority, latency and reliability requirements, associated flows, dependencies, etc.). In some embodiments, information about the ADU may be signaled within the burst header (one or more of start, length, priority, delay and reliability requirements, associated flows, dependencies, etc.). The burst header can signal information about the ADUs in the burst as well as information about the burst (number of ADUs, priority order, latency and reliability requirements, associated flows, dependencies, etc.). In some embodiments, the base station can send ACK/NACK feedback to the transcoder/XR server or application layer for ADU transmission.

Under the solution proposed by the present invention, after mapping the inner slice and the predicted slice to each CGB, the base station 120 can schedule the PDSCH by sending the PDCCH, and then the base station 120 can send the CBG to the UE 110 on the same PDSCH. As shown in Fig. 5, which is a schematic diagram of an example CBG/slice transmission according to an embodiment of the present invention. Scene 500 illustrates an example of a CBG transmission. In this embodiment, the base station 120 sends DCI on the PDCCH 510 to schedule the PDSCH 520 . Then, the base station 120 sends all the CBGs (ie, transmits the inner slice and the predictive slice) to the UE 110 on the PDSCH 520 .

To further protect the CGBs to ensure reliability, each CGB has a cyclic redundancy check (CRC). The length of each CRC is determined according to the size of each CGB. For example, X CBs are used as thresholds. If the number of CBs in the CBG is greater than X, the length of the CRC is 24 bits. If the number of CBs in the CBG is equal to or less than X, the length of the CRC is 16 bits.

In some embodiments, for further protection, each of the CBGs may be associated with a modulation and coding scheme (MCS), and the MCSs are different. In some implementations, a TB-specific number of MCSs may be allowed for all CBGs (eg, 2), and the MCS-to-CBG mapping is signaled in the DCI. In some implementations, each CBG may also be associated with a coding rate, and the coding rates may be different. In some implementations, a new DCI bit field may be introduced to signal the MCS of each CBG.

After sending the CBG, the base station 120 may receive a plurality of HARQ feedbacks corresponding to the CBG from the UE 110, and determine whether to retransmit any one of the inner slice and the predicted slice according to the HARQ feedback. For example, if the frame includes 8 slices, after sending the CGBs to the UE 110, the UE 110 sends an 8-bit HARQ feedback corresponding to each CBG to the base station 120, reporting whether each CBG can be decoded correctly. HARQ The feedback may include at least one of automatic repeat request acknowledgment (HARQ-ACK) and automatic repeat request negative acknowledgment (HARQ-NACK). If the HARQ feedback is HARQ-ACK, the base station 120 determines that the corresponding CBG does not need to be retransmitted. If the HARQ feeds back a HARQ-NACK, the base station 120 retransmits the corresponding CBG.

In some implementations, UE 110 may send UE capabilities to base station 120 . The base station 120 may receive from the UE 110 the UE capability reporting whether the UE 110 supports the CBG packet before sending the CGB. Then, the base station 120 may send a CBG packet indication indicating that the CBG packet is enabled or disabled to the UE 110 via the RRC signal or the DCI. In case the UE capability reports that the UE 110 supports CBG packets, the base station 120 may dynamically (eg, via DCI) enable or disable the CBG packets. In case the base station 120 enables CBG packing, the UE 110 can send a plurality of HARQ feedbacks for CBG. With the base station 120 disabling the CBG packet, the UE 110 may send the unitary HARQ feedback for the TB. For large packets that have the potential to be enhanced using CBG packing, the base station 120 may decide to enable CBG packing for that particular TB transmission, so that the transmission may have better protection and better retransmission resource efficiency.

In some embodiments, the DCI may include an additional bit field, and the base station 120 may send the CBG packet indication in the additional bit field. In some embodiments, base station 120 may configure UE 110 semi-statically (eg, via RRC signaling) with dynamic CBG.

CBG packing is useful for some flows (e.g., DL VR, UL AR, etc.) The size of determines whether to enable CBG packets. In some embodiments, CBG packets may be enabled or disabled per data flow. In some implementations, CBG packets may be enabled or disabled for certain types of video frames, IP packets, or data units (eg, I/P frames).

In some embodiments, at least one of the slices is partitioned into a plurality of video blocks, and at least one of the video blocks is mapped to one of the code block groups or one of the code blocks.

In some implementations, UE 110 may send UE capabilities to base station 120 . The base station 120 may receive UE capabilities from the UE 110, reporting whether the UE 110 supports mapping intra-slices and predictive-slices to CBGs. Then, the base station 120 may send an enabling indication to the UE 110 via an RRC signal or DCI, the enabling indication enabling the mapping of the inner slice and the predicted slice to the code block group.

The second embodiment of the present invention is shown in FIG. 6 . The second embodiment is an extension of the first embodiment. Fig. 6 is an example of CBG transmission under the scheme according to the embodiment of the present invention. Scenario 600 illustrates an example of PDSCH scheduling for sending CBG/slice. The base station 120 can obtain a plurality of slices of frames of the stream. The stream can be a video stream or an audio stream. A slice consists of an inner slice (hereinafter referred to as I-slice, also referred to as I-frame) and a plurality of predictive slices (hereinafter referred to as P-slice, also referred to as P-frame). Intra-slices may be encoded or decoded based on the information of the intra-slices. Each predictive slice can be encoded or decoded based on its own and other slices' material.

The base station 120 may determine the number of CBs in a TB and the number of CBGs in a transport block, and map the inner slices and predicted slices to each code block group, respectively. The base station 120 may then transmit the inner slice on the first PDSCH and at least one predictive slice on the second PDSCH. The base station 120 can receive the HARQ feedback and determine whether to retransmit any one of the inner slice and the predicted slice according to the HARQ feedback.

The difference between the first embodiment and the second embodiment is that in the first embodiment, the inner slice and the predicted slice are sent on the same PDSCH, while in the second embodiment, the inner slice and the predicted slice on different PDSCHs are sent on different PDSCHs. to send. More specifically, after mapping slices to CBGs, base station 120 may send DCI on a PDCCH to schedule the first PDSCH for sending an inner slice, then base station 120 will send another DCI on another PDCCH to schedule The second PDSCH is used to send the prediction slice.

For example, referring to FIG. 6 , the base station 120 transmits DCI on the PDCCH 610 to schedule the PDSCH 620 and transmits the CBG corresponding to the inner chip on the PDSCH 620 . The base station 120 further transmits another DCI on the PDCCH 630 to schedule the PDSCH 640 and transmits the CBG corresponding to the predicted slice on the PDSCH 640 .

Therefore, the base station 120 can receive at least two HARQ feedbacks. One of the HARQ feedbacks is 1-bit signaling indicating whether the inner slice can be correctly decoded, while the other HARQ feedback includes a plurality of bits (for example, 7 bits) corresponding to the predicted slices, indicating whether each predicted slice can is correctly decoded. In this way, the latency of on-chip transmission is lower and the reliability is higher.

In some implementations, if a video slice is segmented into video blocks, each video block may be mapped to a PDSCH. In some implementations, the base station 120 can obtain group of pictures (group of pictures, GOP) information of the stream, determine the number of code blocks in the code block group and the number of code block groups in the transport block, and map the group of pictures according to the GOP information slices and predict slices to each code block group. If the core network 130 (such as XR server or transcoder) has a fixed GOP period, and the GOP always starts from the inner slice/I-frame, the GOP information can include offset, start slice/frame, cycle etc.

In some embodiments, core network 130 flags the intra-chip request to be recognized at base station 120 and sends the flag to base station 120 if the intra-chip is sent on request. Therefore, after the base station 120 receives the label indicating the start slice, the base station 120 can determine the inner slice according to the label.

In some embodiments, UE 110 may send UE capability reporting whether it supports mapping of intra-slice and predicted-slice to CBG, first PDSCH or second PDSCH. If the UE 110 supports mapping the inner slice and the predicted slice to the CBG, the first PDSCH or the second PDSCH, the base station 120 will send an enable indication to the UE 110 via an RRC signal or DCI, enabling the mapping of the inner slice and the predicted slice to CBG, first PDSCH or second PDSCH.

In some embodiments, UE 110 may send UE capabilities reporting whether it supports mapping of video blocks to CBs or CBGs. If the UE 110 supports mapping video blocks to CB or CBG, the base station 120 will send an enable indication to UE 110 via RRC signal or DCI to enable mapping video blocks to CB or CBG.

The third embodiment of the present invention is shown in Figure 7. The third embodiment is an extension of the first and second embodiments. Figure 7 is an example CBG transmission under a scheme according to an embodiment of the invention. Scenario 700 illustrates an example of PDSCH scheduling for sending CBG/slice. The base station 120 can obtain a plurality of slices of frames of the stream. The stream can be a video stream or an audio stream. A slice consists of an inner slice (hereinafter referred to as I-slice, also referred to as I-frame) and a plurality of predictive slices (hereinafter referred to as P-slice, also referred to as P-frame). Intra-slices may be encoded or decoded based on the information of the intra-slices. Each predictive slice can be encoded or decoded based on its own and other slices' data.

The base station 120 may determine the number of CBs in a TB and the number of CBGs in a transport block, and map the inner slices and predicted slices to each code block group, respectively. Then, the base station 120 can send a PDCCH to schedule a plurality of PDSCHs and send the intra slice and the predicted slice on the PDSCH. The base station 120 may receive one or more HARQ feedbacks and determine whether to retransmit any one of the inner slice and the predicted slice according to the one or more HARQ feedbacks.

Specifically, if one PDSCH is used to transmit one slice, the base station 120 needs to keep scheduling the PDSCH and transmit DCI every time a slice is to be transmitted. If the base station 120 uses semi-persistent scheduling (SPS) to schedule all PDSCHs for the transmission slices, and notifies the UE 110 to perform SPS scheduling through RRC signaling, resource allocation is not flexible enough. In this embodiment, the base station 120 can use SPS scheduling to schedule multiple PDSCHs, and send DCI to notify the UE of the scheduled PDSCHs. Therefore, base station 120 does not need to send DCI before sending each chip on PDSCH. In other words, after sending the SPS schedule to the UE 110 on the DCI, the base station 120 only sends the slices on the corresponding PDSCH until all the slices are sent or until the period of the SPS ends.

For example, referring to FIG. 7, the base station 120 schedules PDSCHs 720, 730, 740, 750 within the period for transmitting slices. The base station 120 can send DCI on the PDCCH 710 to inform the UE 110 about the scheduled PDSCH 720 , 730 , 740 , 750 so that the UE 110 can continue to receive slices sent on the PDSCH 720 , 730 , 740 , 750 .

In some embodiments, in order to reduce control overhead while ensuring good flexibility, the same PDCCH can be used to schedule multiple PDSCHs. For example, the base station 120 can use one PDCCH to schedule multiple PDSCHs in one time slot, or use one PDCCH to schedule multiple PDSCHs in multiple time slots. In some embodiments, the base station 120 can use the multiple PDCCHs to simultaneously schedule the multiple PDSCHs.

In some implementations, it is necessary to perform cross-layer marking of the intra-slice and predictive-slice information from the application server to the base station 120 . In some implementations, cross-layer marking of intra-slice and predictive-slice information is required from the UE application layer to the physical layer. In some embodiments, the marking mechanism can be used for different QoS flows or different DRBs, or follow the mechanism of remaining delay budget marking. Illustrative implementation

Figure 8 illustrates an example communication system 800 having an example communication device 810, an example network device 820, a core network 830, and a server 840 in accordance with an embodiment of the present invention. Each of the communication device 810 and the network device 820 can perform various functions to implement the schemes, techniques, processes and methods described in the present invention related to the code block group and slice mapping in the frame of the stream, including the above-mentioned scenarios/solutions And processes 800, 900 and 1000 are described below.

The communication device 810 may be a part of an electronic device, which may be a UE, such as a portable or mobile device, a wearable device, a wireless communication device or a computing device. For example, communication device 810 may be implemented in a smartphone, smart watch, personal digital assistant, digital camera, or computing device such as a tablet, laptop, or notebook computer. The communication device 810 may also be part of a machine type device, which may be an IoT, NB-IoT, IIoT or NTN device, such as a fixed or stationary device, a home device, a wired communication device or a computing device. For example, the communication device 810 can be implemented in a smart thermostat, a smart refrigerator, a smart door lock, a wireless speaker, or a home control center.

Optionally, the communication device 810 may be implemented in the form of one or a plurality of integrated-circuit (integrated-circuit, IC) chips, such as but not limited to one or a plurality of single-core processors, one or a plurality of multi-core processors, a or a plurality of reduced-instruction set computing (RISC) processors, or one or a plurality of complex-instruction-set-computing (complex-instruction-set-computing, CISC) processors. The communication device 810 may include at least some of those elements shown in FIG. 8 . For example, processor 812 as shown in FIG. 8 . The communication device 810 may also include one or a plurality of other components not related to the solution proposed by the present invention (for example, an internal power supply, a display device and/or user peripheral equipment), therefore, such one or a plurality of components of the communication device 810 None are shown in Figure 8, nor are they described below for the sake of simplicity and brevity.

The network device 820 may be part of an electronic device/station, which may be a network node such as a base station, small cell, router, gateway, or satellite. For example, the network device 820 may be implemented in an eNodeB in LTE, in 5G, NR, 6G, IoT, NB-IoT, IIoT or in a satellite in an NTN network. Alternatively, the network device 820 may be implemented in the form of one or more IC chips, such as but not limited to one or more single-core processors, one or more multi-core processors, or one or more RISC or CISC processors. Network device 820 may include at least some of those elements shown in FIG. 8 , such as processor 822 . The network device 820 may also include one or a plurality of other components (for example, internal power supply, display device and/or user peripheral equipment) that are not related to the solution proposed by the present invention. Therefore, these components of the network device 820 are described in Section 8. It is not shown in the figure, and for the sake of simplicity and brevity, it is not described below either.

In one aspect, each of processor 812 and processor 822 may be implemented in the form of one or more single-core processors, one or more multi-core processors, or one or more CISC processors. That is, even though the singular term "processor" is used herein to refer to processor 812 and processor 822, each of processor 812 and processor 822 may, in some embodiments, include plural processors and may include a single processor in other implementations. In another aspect, each of processor 812 and processor 822 may be implemented in the form of hardware (and, optionally, firmware) having electronic components including, for example but not limited to, one or more transistors , one or a plurality of diodes, one or a plurality of capacitors, one or a plurality of resistors, one or a plurality of inductors, one or a plurality of memristors and/or one or a plurality of varactor diodes, which configured and arranged to achieve specific purposes in accordance with the present invention. In other words, in at least some embodiments, each of processor 812 and processor 822 is specially designed, arranged and configured to perform various embodiments in accordance with the present invention including reducing devices (eg, as represented by communication device 810) and Task-specific dedicated machines that consume power in a network (eg, represented by network device 820 ).

In some embodiments, the communication device 810 may also include a transceiver 816 coupled to the processor 812 and capable of sending and receiving data wirelessly. In some implementations, the communication device 810 may further include a memory 814, which includes a volatile computer-readable storage medium and a non-volatile computer-readable storage medium, coupled to the processor 812 and capable of being accessed by the processor 812 and Store data in it. In some implementations, the network device 820 may also include a transceiver 826 coupled to the processor 822 and capable of transmitting and receiving data wirelessly. In some implementations, the network device 820 may further include a memory 824, which includes a volatile computer-readable storage medium and a non-volatile computer-readable storage medium, coupled to the processor 822 and capable of being accessed by the processor 822 and store data in it. Therefore, the communication device 810 and the network device 820 can communicate with each other wirelessly through the transceiver 816 and the transceiver 826, respectively.

Each of the communication device 810 and the network device 820 may be a communication entity capable of communicating with each other using various proposed schemes according to the present invention. For purposes of illustration and better understanding, the following descriptions of the operations, functions, and capabilities of each of the communication device 810 and the network device 820 are made when the communication device 810 is implemented in a communication device or UE (eg, UE 110 ) or as a A communication device or UE (eg, UE 110). The UE (eg, UE 110) and the network device 820 are implemented in or as part of a network node or base station (eg, gNB 120) of the communication network provided in the context of a mobile communications environment. It is also worth noting that while the example implementations described below are provided in the context of streaming, they can be implemented in other types of networks as well.

Core network 830 may include at least some of those functions shown in FIG. 8 . As shown in FIG. 8, for example, access and mobility management function (access and mobility management function, AMF) 832, a plurality of session management functions (session management function, SMF) 834 and a plurality of user plane functions (user plane function, UPF) 836. The network device 820 may further include one or more other components not related to the solution proposed by the present invention (for example, authentication server function, policy control function, network exposure function, etc.), these functions of the core network 830 are in None are shown in Fig. 8, and for the sake of simplicity and brevity, no descriptive diagrams are given below. The core network 830 may be implemented in or as a core network of a telecom operator or a server of a third party (for example, an XR server of a game provider, but not limited thereto). server.

The processor 822 of the network device 820 in or implemented as the base station 120 can obtain a plurality of Slices, including: stream intra-frame slices and multiple predictive slices. Processor 822 may determine the number of code blocks in a transport block and the number of groups of code blocks in a transport block. The processor 822 may map the intra slice and the predicted slice to each code block group respectively. Processor 822 may transmit the set of code blocks. Processor 822 may receive, via transceiver 826, a plurality of HARQ feedbacks corresponding to groups of code blocks. Then, the processor 822 may determine whether to retransmit any one of the inner slice and the predicted slice according to the HARQ feedback.

When determining the number of code blocks and the number of code block groups, the processor 822 may calculate the number of code blocks and the number of code block groups according to the transport block size of the transport block and the maximum code block size in the transport block.

In some embodiments, each slice has a priority order, and the size of each code block group is determined according to the priority order. In some embodiments, the group of code blocks carrying one of the slices with static motion has a lower priority and the group of code blocks carrying one of the slices with dynamic motion has a higher priority.

In some implementations, each code block group has a cyclic redundancy check (CRC), and the length of each CRC is determined according to the size of each code block group.

In some embodiments, each code block group is associated with a modulation and coding scheme (MCS), and wherein the MCS is different.

In some implementations, the processor 822 can determine the scale factor value, and calculate the size of the code block group corresponding to the inner slice and the size of the code block group corresponding to each prediction slice according to the number of code blocks, the number of code block groups and the scale factor value The size of the code block group. The scale factor value is a multiple of the inner slice and the predicted slice, and the scale factor value can change over time.

In some implementations, the processor 822 may receive from the UE the UE capability to report whether the UE supports CBG packets via the transceiver 826, and send a CBG packet indication to the UE through the transceiver 826 through the RRC signal or DCI, indicating whether to enable or disable CBG packets.

In some implementations, the processor 822 may determine whether to enable CBG encapsulation according to the type of flow or determine whether to enable CBG encapsulation according to the size of the transport block.

In some embodiments, at least one of the slices is partitioned into a plurality of video blocks, and at least one of the video blocks is mapped to one of the code block groups or one of the code blocks.

In some implementations, the processor 822 may receive a report from the UE via the transceiver 826 whether the UE supports the UE capability of mapping the inner slice and the predicted slice to a code block group, and send the request to the UE through the RRC signal or DCI via the transceiver 826. Enable indicates that mapping of intra-slices and predicted slices to code block groups is enabled.

Under various proposed schemes according to the present invention, it involves code block groups and slices consisting of an inner slice and a plurality of predictive slices mapped into frames of streams and sharing channels in different physical downlinks (physical downlink share channel, PDSCH) to send the inner slice and the predicted slice, and the processor 822 of the network device 820 implemented in the base station 120 or as the base station 120 can obtain the inner slice and a plurality of predicted slices of the frame of the stream. plural slices of . Processor 822 may transmit the inner slice via transceiver 826 on the first PDSCH and at least one predicted slice on the second PDSCH. The processor 822 may receive hybrid automatic repeat request (HARQ) feedback through the transceiver 826 . Then, the processor 822 may determine whether to retransmit any one of the inner slice and the predicted slice according to the HARQ feedback.

In some implementations, the processor 822 may obtain group of pictures (GOP) information of the stream. Processor 822 may determine the number of code blocks in a code block group and the number of code block groups in a transport block. The processor 822 can map the inner slice and the predictive slice to each code block group respectively according to the GOP information.

In some implementations, the processor 822 may receive a tag to indicate the starting slice and determine the inner slice from the tag.

In some embodiments, the processor 822 may receive from the UE via the transceiver 826 a UE capability reporting whether the UE supports mapping intra-slices and predicted slices to code block groups, the first PDSCH or the second PDSCH. The processor 822 may send an enable indication to the UE through the transceiver 826 through the RRC signal or the DCI, enabling the inner slice and the predicted slice to be mapped to the code block group, the first PDSCH or the second PDSCH.

Under various schemes involving code block groups and slices proposed according to the present invention, code block groups and slices are composed of inner slices and a plurality of prediction segments, mapped into stream frames and using physical downlink control channel (physical downlink control channel) The control channel (PDCCH) schedules a plurality of physical downlink shared channels (physical downlink share channel, PDSCH) to send internal slices and predictive slices, implemented in the base station 120 or as the processing of the network device 820 implemented by the base station 120 The unit 822 can obtain a plurality of slices composed of an inner slice of a stream frame and a plurality of predictive slices. The processor 822 can send a PDCCH via the transceiver 826 to schedule a plurality of PDSCHs. Processor 822 may send the intra-slices and predicted slices on PDSCH via transceiver 826 . The processor 822 can also receive hybrid automatic repeat request (HARQ) feedback via the transceiver 826 . Then, the processor 822 may determine whether to retransmit any one of the inner slice and the predicted slice according to the HARQ feedback.

In some embodiments, PDSCH is scheduled within one slot.

In some embodiments, PDSCH is scheduled in a plurality of time slots. illustrative process

Figure 9 illustrates an example process 900 according to an embodiment of the invention. Process 900 may be an example implementation of the scheme described above, whether partially or fully, with respect to block group and slice mapping in frames of a stream of the present invention. Process 900 may represent an aspect of an implementation of a feature of network device 820 . Process 900 may include one or more operations, actions or functions as indicated by one or more of blocks 910 , 920 , 930 , 940 , 950 and 960 .

Although shown as discrete blocks, the various blocks of process 900 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Additionally, the blocks of process 900 may be executed in the order shown in FIG. 9, or in a different order. Process 900 may be implemented by communication device 810 or any suitable gNB or machine type device. Process 900 is described below in the context of network device 820 for illustrative purposes only and not limitation.

Process 900 may begin at block 910 . At block 910, the process 900 may include the processor 822 of the network device 820 obtaining a plurality of slices consisting of an inner slice of a frame of the stream and a plurality of predicted slices. From block 910 , process 900 may proceed to block 920 .

At block 920, process 900 may include processor 822 determining the number of code blocks in the transport block and the number of code block groups in the transport block. From block 920 , process 900 may proceed to block 930 .

At block 930, the process 900 may include the processor 822 mapping the inner slice and the predicted slice to each code block group respectively. From block 930 , process 900 may proceed to block 940 .

At block 940, process 900 may include processor 822 sending the set of code blocks. From block 940 , process 900 may proceed to block 950 .

At block 950, process 900 can include processor 822 receiving a plurality of HARQ feedbacks corresponding to groups of code blocks. From block 950 , process 900 may proceed to block 960 .

At block 960, process 900 may include processor 822 determining whether to retransmit any of the inner slice and the predicted slice based on the HARQ feedback.

In some embodiments, when determining the number of code blocks and the number of code block groups, the process 900 may include the processor 822 calculating the number of code blocks and the code block size according to the transport block size of the transport block and the largest code block size in the transport block. The number of block groups.

In some implementations, the process 900 may include the processor 822 determining the scale factor value based on the number of code blocks, the number of code block groups and the scale factor value and calculating the size of the code block group corresponding to the inner slice and corresponding to each prediction The size of the code block group for the slice.

In some implementations, the scale factor value is a multiple of the inner slice and the predictive slice. In some embodiments, the scale factor value varies over time.

In some embodiments, each slice has a priority order, and the size of each code block group is determined according to the priority order.

In some embodiments, the group of code blocks carrying one of the slices with static motion has a lower priority and the group of code blocks carrying one of the slices with dynamic motion has a higher priority.

In some embodiments, each code block group has a CRC, and the length of each CRC is determined according to the size of each code block group.

In some embodiments, each code block group is associated with an MCS, and wherein the MCS is different.

In some embodiments, the process 900 may include the processor 822 receiving from the UE the UE capability to report whether the UE supports the CBG packet and sending a CBG packet indication to the UE through RRC signal or DCI, indicating to enable or disable the CBG packet.

In some implementations, the process 900 may include the processor 822 determining whether to enable CBG encapsulation according to the type of flow or whether to enable CBG encapsulation according to the size of the transport block.

In some embodiments, at least one slice is partitioned into a plurality of video blocks, and at least one video block is mapped to one of the code block groups or one of the code blocks.

In some implementations, the process 900 may include that the processor 822 receives a report from the UE whether the UE supports the UE capability of mapping inner slices and predicted slices to code block groups, and sends an enabling indication to the UE through an RRC signal or DCI, enabling Maps intra-slices and predictive slices to codeblock groups.

Figure 10 illustrates an example process 1000 according to an embodiment of the invention. The process 1000 may be an example implementation of the above scheme, whether partially or completely, with regard to the present invention, the code block groups and slices consisting of an inner slice and a plurality of predicted slices are mapped into frames of a stream and the inner slices are transmitted on different PDSCHs. slices and predictive slices. Process 1000 may represent an aspect of an implementation of a feature of network device 820 . Process 1000 may include one or more operations, actions or functions as indicated by one or more of blocks 1010 , 1020 , 1030 , 1040 and 1050 .

Although shown as discrete blocks, the various blocks of process 1000 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Additionally, the blocks of process 1000 may be executed in the order shown in Figure 10, or in a different order. Process 1000 may be implemented by network device 820 or any suitable base station or machine type device. Process 1000 is described below in the context of network device 820 for illustrative purposes only and not limitation.

Process 1000 may begin at block 1010 . At block 1010, the process 1000 may include the processor 822 of the network device 820 obtaining a plurality of slices consisting of an inner slice of a frame of the stream and a plurality of predicted slices. Process 1000 may proceed from block 1010 to block 1020 .

At block 1020, process 1000 can include processor 822 transmitting the chip on the first PDSCH. Process 1000 may proceed from block 1020 to block 1030 .

At block 1030, process 1000 may include processor 822 transmitting at least one of the predicted slices on the second PDSCH. Process 1000 may proceed from block 1030 to block 1040 .

At block 1040, process 1000 can include processor 822 receiving HARQ feedback. Process 1000 may proceed from block 1040 to block 1050 .

At block 1050, process 1000 can include processor 822 determining whether to retransmit any of the inner slice and the predicted slice based on the HARQ feedback.

In some implementations, the process 1000 may include the processor 822 obtaining GOP information of the stream, determining the number of code blocks in a code block group and the number of code block groups in a transport block, and dividing the inner slices and predicted slices according to the GOP information. are mapped to each codeblock group separately.

In some implementations, process 1000 may include processor 822 receiving a tag indicating a starting slice and determining an inner slice based on the tag.

In some embodiments, the process 1000 may include the processor 822 receiving a report from the UE whether the UE supports UE capability to map intra-slices and predicted slices to code block groups, the first PDSCH or the second PDSCH. The process 1000 may also include that the processor 822 sends an enabling indication to the UE via an RRC signal or DCI, enabling mapping the inner slice and the predicted slice to the code block group, the first PDSCH or the second PDSCH.

Figure 11 illustrates an example process 1100 according to an implementation of the present invention. Process 1100 may be an example implementation of the scheme described above, whether partially or fully, with respect to the present invention where groups of blocks and slices consisting of intra-slices and plural predictive slices are mapped into frames of a stream and scheduled using the PDCCH PDSCH to send inner slices and predictive slices. Process 1100 may represent an aspect of an implementation of a feature of network device 820 . Process 1100 may include one or more operations, actions or functions as indicated by one or more of blocks 1110 , 1120 , 1130 , 1140 and 1150 .

Although shown as discrete blocks, the various blocks of process 1100 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Additionally, the blocks of process 1100 may be executed in the order shown in FIG. 11, or in a different order. Process 1100 may be implemented by network device 820 or any suitable base station (eg, gNB) or machine type device. Process 1100 is described below in the context of network device 820 for illustrative purposes only and not limitation.

Process 1100 may begin at block 1110 . At block 1110, the process 1100 may include the processor 822 of the network device 820 obtaining a plurality of slices consisting of an inner slice and a plurality of predicted slices of a frame of the stream. Process 1100 may proceed from block 1110 to block 1120 .

At block 1120, process 1100 can include processor 822 sending a PDCCH to schedule a plurality of PDSCHs. From block 1120 , process 1100 may proceed to block 1130 .

At block 1130, process 1100 may include processor 822 transmitting the inner slice and the predicted slice on the PDSCH. From block 1130 , process 1100 may proceed to block 1140 .

At block 1140, process 1100 can include processor 822 receiving HARQ feedback. Process 1100 may proceed from block 1140 to block 1150 .

At block 1150, process 1100 may include processor 822 determining whether to retransmit any of the inner slice and the predicted slice based on the HARQ feedback.

In some embodiments, PDSCH is scheduled within one slot.

In some embodiments, PDSCH is scheduled in a plurality of time slots. Additional information

The disclosed subject matter sometimes illustrates different components contained within, or connected with, various other components. It is to be understood that this depicted architecture is merely an example, and that in fact many other architectures can be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality is achieved. Therefore, any two components of the present invention combined to achieve a particular function can be seen as "associated with" each other such that the desired function is achieved, regardless of architectures or intermediate components. Likewise, any two parts so related may also be considered to be "operably connected" or "operatively coupled" to each other so as to achieve the desired function, and any two parts capable of being so related may also be considered as They are "workably coupled" to each other to achieve desired functions. Specific examples of operationally coupleable include, but are not limited to: physically matable and/or physically interacting components and/or wirelessly interactable and/or wirelessly interactable components and/or logically interactable and/or Or logically interactable parts.

Further, regarding the numerous usages of any plural and/or singular terms in the present invention, those skilled in the art can convert from the plural to the singular and/or from the singular to the plural as appropriate for the context and/or application. For the sake of clarity, the present invention may expressly set forth various singular/plural reciprocities.

Moreover, those of ordinary skill in the art will understand that terms used herein, and especially in the appended claims (e.g., the body of the appended claims), generally mean "open" terms. (For example, the term "comprising" should be interpreted as "including but not limited to", the term "having" should be interpreted as "having at least", the term "comprising" should be interpreted as "including but not limited to", etc.). Those of ordinary skill in the art will also understand that if a specific number of a claim recitation is intentionally introduced, such intent will be explicitly recited in the claim claim, and no such intent exists in the absence of such recitation . For example, as an aid to understanding, the appended claims of the present invention may contain the use of the introductory phrases "at least one" and "one or more" to introduce the enumerated claims. However, use of this phrase should not be construed to imply that the introduction of a claim listing by the indefinite article "a" or "an" limits any particular claim encompassing such introduced claim list to Only one such enumerated embodiment is included, even when the same claim includes the introductory phrase "one or more" or "at least one" and an indefinite article (such as "a" or "an") (eg, "a " and/or "a" shall be construed as meaning "at least one" or "one or a plurality"); the same applies to the use of definite articles used to introduce a claim enumeration. In addition, even if a specific number of an incorporated patent scope recitation is expressly recited, one of ordinary skill in the art will recognize that such a recitation should be construed to mean at least that recited number (e.g., without other modifications In the case of the term, an unqualified list of "two lists" means at least two lists, or two or a plurality of lists). Furthermore, in those cases where a convention similar to "at least one of A, B, and C, etc." is used, generally, such interpretations will be understood by those of ordinary skill in the art to mean, for example: "has A system of at least one of A, B, and C" will include, but is not limited to, A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A system with A, B, and C, etc. In those cases where a convention similar to "at least one of A, B, or C, etc." is used, such interpretation will generally be understood by those of ordinary skill in the art to mean, for example: "having A, A system of at least one of B or C" will include but is not limited to having A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A together, Systems of B and C, etc. Those of ordinary skill in the art will also understand that any transitional words and/or phrases, whether in the specification, claims, or drawings, that actually present two or more alternatives should be understood to include such The likelihood of one of the items, either of these items, or both. For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B."

From the foregoing, it will be appreciated that various embodiments of the invention have been described for purposes of illustration and that various modifications may be made without departing from the scope and spirit of the invention. Accordingly, it is not intended to be limiting by the various embodiments disclosed herein, with the true scope and spirit being indicated by the appended claims.

100: scene 110:UE 120: base station 130: core network 200: scene 300: scene 400: scene 410:TB 4201, 4202, ... 4223: CB 431, 432, ... 438: CBG 500: scene 510: PDCCH 520:PDSCH 600: scene 610,630:PDCCH 620,640:PDSCH 700: scene 710: PDCCH 720,730,740,750:PDSCH 800: Communication system 810:Communication device 820: network device 812,822: Processor 814,824: memory 816,826: Transceivers 830: core network 832: Access and mobility management functions 834: session management function 836: user plane function 900: process 910,920,930,940,950,960: blocks 1000: process 1010,1020,1030,1040,1050: blocks 1100: process 1110,1120,1130,1140,1150: blocks

The accompanying drawings are included to provide a further understanding of the invention and are incorporated in and constitute a part of this invention. The drawings illustrate embodiments of the invention and, together with the description, serve to explain principles of the invention. It is to be noted that the drawings are not necessarily drawn to scale, as in actual practice some elements may be shown out of scale in order to clearly illustrate the inventive concepts. Figure 1 is a diagram of an example network environment in which various proposed solutions according to the present invention can be implemented. Figure 2 is a diagram of an example slice according to an embodiment of the present invention. Figure 3 is a diagram of an example slice according to an embodiment of the present invention. Figure 4 is a diagram of an example CBG packet according to an embodiment of the invention. Figure 5 is a diagram of an example CBG/slice transmission according to an embodiment of the invention. Figure 6 is a diagram of an example CBG/slice transmission according to an embodiment of the invention. Figure 7 is a diagram of an example CBG/slice transmission according to an embodiment of the invention. Figure 8 is a block diagram of an example communication system in accordance with an embodiment of the present invention. Figure 9 is a flowchart of an example process according to an embodiment of the invention. Figure 10 is a flowchart of an example process according to an embodiment of the invention. Figure 11 is a flowchart of an example process according to an embodiment of the invention.

900: process

910, 920, 930, 940, 950, 960: steps

Claims (20)

A method for code block group and slice mapping in mobile communication, comprising: the processor of the device obtains a plurality of slices consisting of an inner slice of a frame of the stream and a plurality of predicted slices; the processor determines a number of code blocks in a transport block and a number of groups of code blocks in a transport block; mapping the inner slice and the predicted slice to each code block group, respectively, by the processor; the processor sends the set of code blocks; receiving, by the processor, hybrid automatic repeat request (HARQ) feedback corresponding to the set of code blocks; and Whether to retransmit any one of the inner slice and the predicted slice is determined by the processor according to the HARQ feedback. The method as claimed in claim 1, wherein, when determining the number of the code blocks and the number of the code block groups, the method further includes: The processor calculates the number of code blocks and the number of code block groups based on a transport block size of the transport block and a maximum code block size in the transport block. The method as described in claim 1, further comprising: determining, by the processor, a scaling factor value; and The processor calculates the size of the code block group corresponding to the inner slice and the size of the code block group corresponding to each of the predicted slices according to the number of the code blocks, the number of the code block groups and the value of the scale factor. The size of the set of code blocks. The method of claim 3, wherein the scale factor value is a multiple of the intra-slice and the predictive slice. The method of claim 3, wherein the scale factor value varies with time. The method of claim 3, wherein each of said slices has a priority order, and said size of each of said code block groups is determined according to said priority order. The method of claim 1, wherein said group of code blocks carrying one of said slices with static motion has a lower priority, and wherein said code block group carrying one of said slices with dynamic motion Block groups have higher priority. The method of claim 1, wherein each of the set of code blocks includes a circular redundancy check (CRC), and wherein the length of each of the CRCs is determined according to the length of each of the set of code blocks The size of each one is determined. The method of claim 1, wherein each of said sets of code blocks is associated with a modulation and coding scheme (MCS), and wherein said MCS are different. The method as described in claim 1, further comprising: receiving, by the processor, a UE capability reporting whether the UE supports code block group (CBG) packets from the UE; and The processor sends a CBG packet indication indicating to enable or disable a code block group (CBG) packet to the UE through a radio resource control (RRC) signal or a downlink control information (DCI). The method as described in claim 10, further comprising: The processor determines whether to enable the CBG packet according to the type of the flow; or The processor determines whether to enable the CBG packet according to the size of the transport block. The method of claim 1, wherein at least one of the slices is partitioned into a plurality of video blocks, and wherein at least one of the video blocks is mapped to one of the code block groups or the One of the code blocks. The method as described in claim 12, further comprising: receiving, by the processor, a report from a user device whether the user device supports a user device capability to map the inner slice and the predictive slice to the code block set; and The processor sends an enable indication to the UE via a radio resource control (RRC) signal or a downlink control information (DCI), enabling the mapping of the inner slice and the predicted slice to the code block Group. A method for code block group and slice mapping in mobile communication, comprising: the processor of the device obtains a plurality of slices consisting of an inner slice of a frame of the stream and a plurality of predicted slices; the processor transmits the internal slice on a first physical downlink shared channel (PDSCH); the processor sends at least one of the predicted slices on a second PDSCH; the processor receives hybrid automatic repeat request (HARQ) feedback; and The processor determines whether to retransmit any one of the inner slice and the predicted slice according to the HARQ feedback. The method as described in claim item 14, the method also includes: the processor obtains group of pictures (GOP) information for the stream; the processor determines the number of code blocks in the code block group and the number of code block groups in the transport block; and The processor maps the inner slice and the predictive slice to each of the code block groups respectively according to the GOP information. The method as described in claim item 14, the method also includes: the processor receives a tag indicating a starting slice; and The processor determines the inner slice based on the label. The method as described in claim 14, further comprising: receiving, by the processor, a user equipment reporting whether the user equipment supports mapping the inner slice and the predictive slice to the code block set, the first PDSCH or the second PDSCH ability; and The processor sends an enable indication to the user equipment through a radio resource control (RRC) signal or a downlink control information (DCI), enabling intra-slice and predicted slices to be mapped to the code block group, the The first PDSCH or the second PDSCH. A method for code block group and slice mapping in mobile communication, comprising: the processor of the device obtains a plurality of slices consisting of an intra-frame slice and a plurality of predicted slices of a frame of the stream; The processor sends a physical downlink control channel (PDCCH) to schedule a plurality of physical downlink shared channels (PDSCH); The processor sends the inner slice and the predictive slice on the plurality of PDSCHs; the processor receives hybrid automatic repeat request (HARQ) feedback; and The processor determines whether to retransmit any one of the inner slice and the predicted slice according to the HARQ feedback. The method of claim 18, wherein the PDSCH is scheduled within a time slot. The method of claim 18, wherein the PDSCH is scheduled in a plurality of time slots.

Images