Downlink Size Estimation for Multicast Services

Abstract

Embodiments of the present disclosure relate to estimating the downlink size of a multicast service. According to embodiments of the present disclosure, a first device receives downlink control information (DCI) of a multicast service. The first device determines the (multiple) field sizes in the DCI based on one or more parameters associated with the field size estimation of the multicast service. The first device decodes the DCI based on the determined (multiple) field sizes. In this way, the DCI can be correctly decoded blindly.

Description

Technical Field

[0001] Embodiments of the present disclosure generally relate to the field of telecommunications, and more particularly to methods, devices, apparatuses, and computer-readable storage media for estimating the downlink size of multicast services. Background Art

[0002] With the development of communication technologies, several solutions have been proposed to provide efficient and reliable solutions for communication. For example, multicast and broadcast services (MBS) have been proposed to efficiently use radio and network resources while transmitting audio and video content to a large number of end users. The MBS used herein refers to a point-to-multipoint communication scheme in which data packets are simultaneously transmitted from a single source to multiple destinations. The term "broadcast" refers to the ability to deliver content to all users. The term "multicast" refers to the distribution of content among a specific group of users who have subscribed to these services. Summary of the Invention

[0003] Generally, example embodiments of the present disclosure provide a solution for estimating the downlink size of multicast services.

[0004] In a first aspect, a first device is provided. The first device includes at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processor, cause the first device to: receive downlink control information of a multicast service from a second device; determine one or more field sizes in the downlink control information based on a set of parameters associated with the field size estimation of the multicast service; and decode the downlink control information based on the determined one or more field sizes.

[0005] In a second aspect, a second device is provided. The second device includes at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processor, cause the second device to: transmit a radio resource control configuration for a multicast service to the first device, the second radio resource control configuration including a set of parameters associated with the field size estimation of the multicast service; and transmit downlink control information of the multicast service to the first device.

[0006] In a third aspect, a method is provided. The method includes receiving, at a first device, downlink control information of a multicast service from a second device; determining, at the first device, one or more field sizes in the downlink control information based on a set of parameters associated with the field size estimation of the multicast service; and decoding the downlink control information based on the determined one or more field sizes.

[0007] In a fourth aspect, a method is provided. The method includes transmitting, at a second device, radio resource control configuration for a multicast service to a first device, the second radio resource control configuration including a parameter set associated with an estimated field size of the multicast service; and transmitting, to the first device, downlink control information for the multicast service.

[0008] In a fifth aspect, an apparatus is provided. The apparatus includes means for receiving, at a first device, downlink control information for a multicast service from a second device; means for determining, at the first device, one or more field sizes in the downlink control information based on a parameter set associated with an estimated field size of the multicast service; and means for decoding the downlink control information based on the determined one or more field sizes.

[0009] In a sixth aspect, an apparatus is provided. The apparatus includes means for transmitting, at a second device, radio resource control configuration for a multicast service to a first device, the second radio resource control configuration including a parameter set associated with an estimated field size of the multicast service; and means for transmitting, to the first device, downlink control information for the multicast service.

[0010] In a seventh aspect, a computer-readable medium is provided. The computer-readable medium includes program instructions for causing an apparatus to perform at least a method according to any one of the above third aspect or fourth aspect.

[0011] It should be understood that the Summary of the Invention section is not intended to identify key or essential features of the embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become readily apparent through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Some example embodiments will now be described with reference to the accompanying drawings, in which:

[0013] Figure 1 An example communication environment in which example embodiments of the present disclosure can be implemented is shown;

[0014] Figure 2 A signaling flow for delivering beam information according to some example embodiments of the present disclosure is shown;

[0015] Figure 3 A flowchart of a method implemented at a first device according to some example embodiments of the present disclosure is shown;

[0016] Figure 4 A flowchart of a method implemented at a first device according to some other example embodiments of the present disclosure is shown;

[0017] Figure 5A flowchart of a method implemented at a first device according to some other example embodiments of the present disclosure is shown;

[0018] Figure 6 A flowchart of a method implemented at a second device according to some other example embodiments of the present disclosure is shown;

[0019] Figure 7 A simplified block diagram of a device suitable for implementing example embodiments of the present disclosure is shown; and

[0020] Figure 8 A block diagram of an example computer-readable medium according to some example embodiments of the present disclosure is shown.

[0021] Throughout the drawings, the same or similar reference numerals denote the same or similar elements. Detailed Description

[0022] The principles of the present disclosure will now be described with reference to some example embodiments. It should be understood that the description of the example embodiments is only for the purpose of illustration and to assist those skilled in the art in understanding and implementing the present disclosure, and does not represent any limitation on the scope of the present disclosure. The embodiments described herein can be implemented in various other ways than those described below.

[0023] In the following description, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present disclosure pertains.

[0024] References in the present disclosure to "one embodiment", "an embodiment", "example embodiment", etc. indicate that the described embodiment may include a particular feature, structure, or characteristic, but not necessarily every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is considered within the knowledge of those skilled in the art to combine such feature, structure, or characteristic with other embodiments (whether or not explicitly described).

[0025] It should be understood that although the terms "first" and "second" etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element, without departing from the scope of the example embodiments. As used herein, the term "and / or" includes any and all combinations of one or more of the listed terms.

[0026] The terms used herein are for the purpose of describing particular embodiments only and are not intended to limit the example embodiments. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises", "comprising", "has", "having", "includes" and / or "including", when used herein, specify the presence of the stated features, elements and / or components, etc., but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof.

[0027] As used in this application, the term "circuitry" may refer to one or more or all of the following:

[0028] (a) A pure hardware circuit implementation (such as an implementation using only analog and / or digital circuitry), and

[0029] (b) A combination of hardware circuitry and software, such as, where applicable:

[0030] (i) A combination of (one or more) analog and / or digital hardware circuitry and software / firmware, and

[0031] (ii) Any portion of (one or more) hardware processors (including (one or more) digital signal processors), software, and (one or more) memories with software that work together to cause a device (such as a mobile phone or a server) to perform various functions, and

[0032] (c) (One or more) hardware circuitry and / or (one or more) processors, such as (one or more) microprocessors or a portion of (one or more) microprocessors, which require software (e.g., firmware) to operate, but the software may not be present when not needed for operation.

[0033] This definition of circuitry is suitable for all uses of the term in this application. As another example, as used in this application, the term circuitry also encompasses implementations of only hardware circuitry or a processor (or processors) or a portion of a hardware circuitry or a processor and its (or their) accompanying software and / or firmware. For example, if applicable to a particular example embodiment, the term circuitry also encompasses a baseband integrated circuit or a processor integrated circuit for a mobile device, or a similar integrated circuit in a server, a cellular network device, or other computing or network devices.

[0034] As used herein, the term "communication network" refers to a network that follows any suitable communication standard, such as New Radio (NR), Advanced New Radio (NR-A), Long Term Evolution (LTE), Advanced LTE (LTE-A), Wideband Code Division Multiple Access (WCDMA), High Speed Packet Access (HSPA), Narrowband Internet of Things (NB-IoT), etc. Additionally, the communication between the terminal device and the network device in the communication network can be performed according to any suitable generation of communication protocol, including but not limited to the first generation (1G), second generation (2G), 2.5G, 2.75G, third generation (3G), fourth generation (4G), 4.5G, fifth generation (5G) communication protocols, and / or any other protocol currently known or developed in the future. Embodiments of the present disclosure can be applied to various communication systems. Given the rapid development of communication, there will of course also be future types of communication technologies and systems in which the present disclosure can be embodied. The scope of the present disclosure should not be regarded as being limited to the above systems only.

[0035] As used herein, the term "network device" refers to a node in a communication network through which a terminal device accesses the network and receives services therefrom. The network device can refer to a base station (BS) or an access point (AP), such as Node B (NodeB or NB), evolved Node B (eNodeB or eNB), NR NB (also known as gNB), Remote Radio Unit (RRU), Radio Head (RH), Remote Radio Headend (RRH), relay, Integrated and Access Backhaul (IAB) node, low power node (such as femto, pico), Non-Terrestrial Network (NTN) or non-terrestrial network device (such as satellite network device, Low Earth Orbit (LEO) satellite and Geostationary Earth Orbit (GEO) satellite, aircraft network device), etc., depending on the terms and technologies applied. The term "terminal device" refers to any terminal device capable of wireless communication. In the following description, the terms "terminal device", "terminal", "user equipment", and "UE" may be used interchangeably.

[0036] As described above, MBS has been proposed. The UE should register for the MBS service. The term "MBS Radio Bearer (MRB)" as used herein can be defined as being used to transmit multicast and broadcast services in a point-to-point (PTP) or point-to-multipoint (PTM) mode. Multiple Multimedia Broadcast Multicast Service (MBMS) Control Channels (MCCH) can be supported. Considering that the 5G network needs to provide more diverse service types with different latency requirements, the multi-MCCH scenario can also be discussed.

[0037] As part of the work item on 5G / NR multicast, 3GPP is currently defining mechanisms to enable the delivery of multicast / broadcast services to a large number of UEs. One of its main objectives is to define a group scheduling mechanism that enables the scheduling of multicast / broadcast services using common data channel resources while maintaining maximum commonality with the currently defined unicast scheduling and operation mechanisms. One of the objectives is to support idle and inactive mode UEs.

[0038] In addition, broadcasting for all RRC states should be supported. In 4G systems, the group scheduling mechanism can be enabled using semi-static or dynamic broadcast signaling of control information pointing to semi-static or dynamic shared data channel resources - for evolved multimedia broadcast multicast service (eMBMS) and single cell point-to-multipoint (SC-PTM). For eMBMS and SC-PTM, due to the support of receive-only mode UEs, there are many restrictions on the system design, such as the support for devices not registered with the network, the support for idle mode devices, etc. This has a significant impact on how to send multicast data / traffic channel (MTCH) and multicast control channel (MCCH) information using the physical channel - using the physical downlink shared channel (PDSCH) or the physical multicast channel (PMCH). It should be noted that LTE does not have various physical layer scheduling concepts such as bandwidth parts, and 5G / NR does not define logical channels such as SCMCCH / MTCH, which makes it impossible to redefine the LTE-based multicast broadcast characteristics for 5G. The PDCCH scheduling in 5G / NR is also significantly different from LTE, which makes it challenging to adjust the parameters defined for LTE for 5G.

[0039] The gNB uses downlink control information (DCI) formats 1_0, 1_1, and 1_2 to notify UEs of the PDSCH resources on which downlink data will be scheduled. Currently, these formats have been defined for unicast services, which means the gNB will use any of these DCI formats to notify UEs of the PDSCH resources using UE-specific PDCCH. So far, it has been agreed that DCI formats 1_0 and 1_1 can be used as the baseline for scheduling multicast service PDSCH resources. Table 1 below shows some variable-size fields in DCI format 1_1.

[0040] Table 1

[0041] DCI field Size in bits Carrier indicator 0、3 Bandwidth part indicator 0、1、2 Frequency domain resource allocation Variable VRB-to-PRB mapping 0、1 PRB bundle size indicator 0、1 Rate matching indicator 0、1、2 ZP CSI-RS trigger 0、1、2 Downlink allocation index 0、2、4 PDSCH-to-HARQ_feedback timing indicator 0、1、2、3 (Multiple) antenna ports and layers 4、5、6 Transmission configuration indication 0、3 CBG transmission information (CBGTI) 0、2、4、6、8 CBG refresh information (CBGFI) 0、1 Downlink allocation index 0、2、4 PDSCH-to-HARQ_feedback timing indicator 0、1、2、3

[0042] For a cell, the total number of different DCI sizes configured to be monitored is up to four, and for a cell, the total number of different DCI sizes configured to be monitored for C-RNTI is up to three. Among these three DCI sizes, one size is used for scheduling downlink allocations in non-fallback format (DCI format 1_1), one size is used for fallback DCI formats (DCI formats 0_0 and 1_0), and the third size is used for uplink scheduling in non-fallback format (DCI format 0_1). DCI format 0_0 is used for uplink resource allocation (scheduling grant) of PUSCH. As mentioned before, this is a fallback DCI format. DCI format 0_1 is used for uplink resource allocation (scheduling grant) of PUSCH. As mentioned before, this is a non-fallback DCI format. Its CRC can be scrambled by C-RNTI or CS-RNTI or MCS-C-RNTI or SP-CSI-RNTI. DCI format 1_0 is used for allocating downlink resources for PDSCH. As mentioned before, this is a fallback DCI format. The presence and value of specific fields within DCI format 1_0 depend on the type of RNTI used to scramble DCI format 1_0. DCI format 1_1 is used for allocating downlink resources for PDSCH. As mentioned before, this is a non-fallback DCI format. Different from DCI format 1_0, this DCI format can only be addressed to C-RNTI, CS-RNTI or MCS-C-RNTI. The gNB can use latency-critical transmissions to another UE to preempt an ongoing PDSCH transmission to a UE. The gNB can configure the UE to monitor interruption transmission indications using INT-RNTI on the PDCCH. If the UE receives an interruption transmission indication, the UE can assume that the resource elements included in the indication do not carry useful information for the UE, even if some of these resource elements have been scheduled for the UE. DCI format 2_1 is used to notify (multiple) PRBs and (multiple) OFDM symbols in which the UE can assume there is no transmission for the UE. DCI format 2_2 is used for the transmission of TPC commands for PUCCH and PUSCH. DCI format 2_3 is used for the transmission of a set of TPC commands for SRS transmissions by one or more UEs. Together with the TPC commands, SRS requests can also be transmitted within the DCI.

[0043] If the high-layer configuration parameters for multicast services are not aligned, it may cause different UEs receiving the same multicast DCI to assume different DCI sizes. This will result in the failure of blind decoding attempts. In addition, there is an existing limit on the DCI size budget for blind decoding that has been agreed upon - this means that if it is counted as the cell RNTI (C-RNTI), the gNB can use at most three different sizes for the DCI with CRC scrambled using the group radio network temporary identifier (G-RNTI), or one size if it is counted as other RNTIs. This imposes a significant limitation on the DCI sizes that can be allocated to G-RNTI-based DCI.

[0044] As previously mentioned, due to the possible lack of alignment in high-layer configuration, different UEs receiving the same MBS service may have different assumptions related to the sizes of various DCI fields. This may also be necessary, for example, assuming different requirements for the number of configured BWPs, priority indication, etc. for the UEs. Therefore, a mechanism is needed to overcome this challenge so that all UEs receiving the same multicast service can align their DCI size estimates.

[0045] A new solution for estimating the downlink size of multicast services is needed. According to an embodiment of the present disclosure, a first device receives a DCI for a multicast service. The first device determines the (multiple) field sizes in the DCI based on one or more parameters associated with the field size estimation of the multicast service. The first device decodes the DCI based on the determined (multiple) field sizes. In this way, the DCI can be correctly blindly decoded.

[0046] Figure 1 A schematic diagram of a communication environment 100 in which embodiments of the present disclosure can be implemented is shown. The communication environment 100, which is part of a communication network, also includes devices 110-1, 110-2, ……, 110-N (which can be collectively referred to as “(multiple) first devices 110”). The communication environment 100 includes a second device 120. The number N can be any suitable integer.

[0047] The communication environment 100 can include any suitable number of devices and cells. In the communication environment 100, the first device 110 and the second device 120 can transmit data and control information to each other. In the case where the first device 110 is a terminal device and the second device 120 is a network device, the link from the second device 120 to the first device 110 is referred to as the downlink (DL), and the link from the first device 110 to the second device 120 is referred to as the uplink (UL). The first device 110 can be configured with more than one cell.

[0048] It should be understood that Figure 1The number of the first devices and cells shown and their connections are given for illustrative purposes and do not imply any limitation. The communication environment 100 may include any suitable number of devices and networks suitable for implementing embodiments of the present disclosure.

[0049] Communications in the communication environment 100 may be implemented according to any suitable communication protocol(s), including but not limited to cellular communication protocols such as first generation (1G), second generation (2G), third generation (3G), fourth generation (4G), and fifth generation (5G), wireless local area network communication protocols such as Institute of Electrical and Electronics Engineers (IEEE) 802.11, and / or any other protocol known currently or developed in the future. Additionally, the communications may utilize any suitable wireless communication technology, including but not limited to: code division multiple access (CDMA), frequency division multiple access (FDMA), time division multiple access (TDMA), frequency division duplexer (FDD), time division duplexer (TDD), multiple input multiple output (MIMO), orthogonal frequency division multiplexing (OFDM), discrete Fourier transform spread OFDM (DFT-s-OFDM), and / or any other technology known currently or to be developed in the future.

[0050] Example embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings. Now refer to Figure 2 , Figure 2 FIG. 200 shows a signaling flow for determining the field size in DCI according to an example embodiment of the present disclosure. For the purpose of discussion, the signaling flow 200 will be described with reference to Figure 1 . For illustrative purposes only, the signaling flow 200 may involve a first device 110-1 and a second device 120.

[0051] In some example embodiments, the second device 120 may transmit 2010 a first RRC configuration to the first device 110-1. The first RRC configuration may be used to determine the DCI field size for (a) unicast service(s). For example, the second device 120 may use DCI formats 1_0, 1_1, and 1_2 to notify the first device 110-1 of the PDSCH resources in which downlink data will be scheduled.

[0052] The second device 120 may transmit 2020 a second RRC configuration for multicast service to the first device 110-1. The multicast service may be any suitable type of multicast service - which is received by a group of users, or may be a broadcast service that can be received by all users connected to the network.

[0053] The second RRC configuration may include a set of parameters associated with the field size estimation of the multicast service. For example, the set of parameters may include a carrier indicator field parameter indicating the size of the carrier indicator field in the DCI for the multicast service. In other words, the carrier indicator field parameter may notify the first device 110-1 of the field size of the carrier indicator to be assumed for the DCI.

[0054] Alternatively or additionally, the set of parameters may include a bandwidth part indicator field parameter indicating the size of the bandwidth part indicator field in the downlink control information. This parameter may enable the first device 110-1 to determine the field size to be assumed for the bandwidth part indicator field.

[0055] In some example embodiments, the set of parameters may include a feedback timing indicator field parameter indicating the size of the feedback timing indicator field in the downlink control information. For example, the feedback timing indicator may be a PDSCH-to-HARQ_feedback timing indicator. When HARQ ACK / NACK or only NACK is enabled, the size of the feedback timing indicator field is the same for the terminal device receiving the multicast service as that indicated by the feedback timing indicator field parameter. However, the terminal device may need to interpret the feedback timing indicator differently, that is, the same value of the feedback timing indicator may correspond to different timings. For example, if HARQ ACK / NACK is enabled, the first device 110-1 may need to interpret the signaling value in the PDSCH-to-HARQ_feedback timing indicator field differently from another first device (e.g., device 110-2). In this case, the first device 110-1 needs to receive a configuration indicating how the device interprets the value of the PDSCH-to-HARQ_feedback timing indicator in, for example, the first RRC configuration 2010. The first device 110-1 may combine the configuration received using the first RRC configuration and the common configuration received using the second RRC configuration to derive a unique HARQ ACK / NACK feedback resource.

[0056] In some embodiments, the second device 120 may configure an offset to be applied by the first device 110-1 for the G-RNTI scrambled DCI. The first device 110-1 may determine the feedback timing based on this offset. For example, the first device 110-1 may then determine the index I = (PDSCH-to-HARQ_feedback timing indicator + offset) mod 2^(length of the PDSCH-to-HARQ_feedback timing indicator field). Alternatively, the second device 120 may configure the PUCCH configuration table in the required order.

[0057] In other example embodiments, the parameter set may include a priority indicator field parameter indicating the size of a priority indicator field in downlink control information.

[0058] In addition, the parameter set may include parameters for optional configurations. The parameter may indicate the size of an optional configuration in downlink control information. The optional configuration may include virtual resource block (VRB) to physical resource block (PRB) mapping. The optional configuration may also include a PRB bundling size indicator. In other embodiments, the optional configuration may include a rate matching indicator. Alternatively or additionally, the optional configuration may include a zero-power channel state information reference signal (ZP CSI-RS) trigger. The optional configuration may also include a downlink allocation index. In some example embodiments, the optional configuration may include antenna ports and number of layers. In other example embodiments, the optional configuration may include a physical downlink shared channel (PDSCH) group index. The optional configuration may include a new feedback indicator. Additionally, the optional configuration may include the number of requested PDSCH groups. As an example embodiment, the optional configuration may include a sounding reference signal request. Code block group (CBG) transmission information may be included in the optional configuration. The optional configuration may also include CBG flush information (CBGFI). Alternatively or additionally, the optional configuration may include a minimum applicable scheduling offset indicator. In some example embodiments, the optional configuration may include secondary cell dormancy indication. The optional configuration may include other configurations with no explicit requirement for multicast services.

[0059] The parameter set may include any one or any combination of the above parameters. The parameter set may also include (one or more) other parameters that are also related to estimating the field sizes in DCI.

[0060] In some embodiments, the parameter set may be signaled as part of the PDCCH configuration, e.g., pdcch-config-mbs based on pdcch-config, where pdcch-config provides the UE's control resource set parameters and additional parameters required to obtain the PDCCH, as defined in TS 38.331, and provides a set of common DCI field size parameters that need to be applied to DCI with a CRC scrambled using a G-RNTI. Alternatively, the parameter set may be signaled as part of the PDSCH configuration, e.g., pdsch-config-mbs based on pdsch-config, where pdsch-config contains high-layer parameters used by the UE to estimate some variable-size DCI fields, as defined in TS 38.331. The PDCCH configuration / PDSCH configuration may be transmitted as part of a second RRC configuration. The second RRC configuration may be a group common RRC message. For example, the second RRC configuration may be signaled using a group common RNTI. The second RRC configuration may also be a UE-specific RRC message, and the first device 110-1 may apply the second RRC configuration to determine the DCI size only for DCI scrambled using a group common RNTI. In an exemplary embodiment, the second RRC configuration may be transmitted together with the first RRC configuration in a single UE-specific RRC message.

[0061] Alternatively, default values for some or all of the parameters in the parameter set may be pre-determined or configured at the first device 110-1. If multicast scheduling parameters such as G-RNTI, associated search space, and DCI format are configured, and if the second device 120 does not transmit some or all of the parameters in the parameter set to the first device, the first device 110-1 may apply these default values to estimate the DCI size for blind decoding. The default values may be specified in a standard specification, hard-coded in the first device, or configured by the second device via some configuration message (e.g., the first RRC configuration).

[0062] The second device 120 transmits 2030 multicast DCI to the first device 110-1. For example, the format of the DCI can be DCI format 1_0 or DCI format 1_1. If the format of the DCI is DCI format 1_0, the DCI has only a limited variable-size field. In some embodiments, the first device 110-1 may determine the DCI format of the above DCI. If the DCI format is not a pre-configured format (merely as an example, DCI format 1_0), the first device 110-1 may determine whether a common frequency resource (CFR) is configured. In this case, if the CFR is not configured, the first device 110-1 may determine the frequency-domain resource allocation (FDRA) field size based on the active bandwidth part size. Alternatively, if the CFR is configured, the first device 110-1 may determine the FDRA field size based on the CFR size.

[0063] The first device 110-1 determines 2040 one or more field sizes in the DCI based on a parameter set. Merely as an example embodiment, the parameter set may indicate the following: the carrier indicator field has 3 bits, the bandwidth part indicator field has 1 bit, the VRB-to-PRB mapping field has 1 bit, the PRB bundling size indicator field has 0 bits, the rate matching indicator field has 2 bits, the ZP CSI-RS trigger field has 2 bits, the downlink allocation index has 4 bits, the PDSCH-to-HARQ_feedback timing indicator field has 0 bits, the (multiple) antenna port and layer number field has 4 bits, the transmission configuration indicator field has 3 bits, the CBGTI field has 6 bits, and the CBGFI field has 1 bit. In this way, the field sizes in the DCI can be correctly determined, and DCI decoding failures can be avoided.

[0064] In some embodiments, if the first device 110-1 does not receive a second RRC configuration for multicast service from the second device 120, the first device 110-1 may determine whether the parameter set is pre-determined and configured at the first device 110-1. If the parameter set is pre-determined and configured at the first device 110-1, the first device 110-1 may determine one or more field sizes based on the pre-determined and configured parameter set.

[0065] Alternatively, the second RRC configuration for the multicast service may include a subset of the parameter set. The remaining parameters in the parameter set may have default values at the first device 110-1. In other words, the remaining parameters may be predefined, and the second RRC configuration does not need to carry the remaining parameters with default values. In this case, the first device 110-1 may determine one or more field sizes based on the subset of the parameters and the default values of the remaining parameters. In this way, signaling can be reduced. Only by way of example, the second RRC configuration for the multicast service may indicate that the carrier indicator field has 3 bits, the bandwidth part indicator field has 1 bit, the VRB-to-PRB mapping field has 1 bit, and the PRB bundling size indicator field has 0 bits. The remaining parameters are default values. For example, the rate matching indicator field is set to 0 bits, the ZP CSI-RS triggering field is set to 0 bits, the downlink allocation index is set to 0 bits, the PDSCH-to-HARQ_feedback timing indicator field is set to 0 bits, the (multiple) antenna port and layer number field has 4 bits, the transmission configuration indicator field is set to 0 bits, the CBGTI field is set to 0 bits, and the CBGFI field is set to 0 bits. Therefore, the first device 110-1 may determine the field sizes of the carrier indicator field, the bandwidth part indicator field, the VRB-to-PRB mapping field, and the bandwidth part indicator field based on the first subset of parameters in the second RRC configuration, and determine the field sizes of other fields based on the second subset of parameters with default values. The default values of some or all of the parameters may be sent via an RRC configuration common to all UEs receiving the multicast or broadcast service. This may be achieved by defining a specific radio network temporary identifier for signaling the default values from the second device to the first device. The default values of some or all of the parameters may also be sent individually to each UE, e.g., via the first RRC configuration, to indicate that these parameters are only used for receiving the multicast or broadcast service, where the CRC of the DCI is scrambled using the G-RNTI.

[0066] The first device 110-1 decodes the DCI 2050 based on the determined one or more field sizes. For example, as described above, the first device 110-1 may determine the sizes of the fields in the DCI based on the parameter set. The first device 110-1 can correctly decode the DCI because it knows the field sizes. If multicast scheduling parameters such as the G-RNTI, the associated search space, and the DCI format are configured, the first device 110-1 may apply the parameter set received from the second device 120 or configured at the first device 110-1 for blind decoding. In this way, the efficiency of blind decoding is improved.

[0067] Figure 3FIG. 300 is a flow chart of an example method according to some example embodiments of the present disclosure. For the purpose of discussion, method 300 will be described from the perspective of a first device. For illustrative purposes only, method 300 is described with reference to first device 110-1.

[0068] In some example embodiments, the first device 110-1 may receive a first RRC configuration from the second device 120. The first RRC configuration may be used to determine the DCI field size for (a) unicast service(s). For example, DCI formats 1_0, 1_1, and 1_2 may be used by the second device 120 to notify the first device 110-1 of the PDSCH resources on which downlink data will be scheduled.

[0069] Alternatively or additionally, the first device 110-1 may receive a second RRC configuration for a multicast service from the second device 120. The multicast service may be any suitable type of multicast service - which is received by a group of users, or may be a broadcast service that can be received by all users connected to the network.

[0070] The second RRC configuration may include a set of parameters associated with the field size estimation of the multicast service. For example, the set of parameters may include a carrier indicator field parameter indicating the size of the carrier indicator field in the DCI for the multicast service. In other words, the carrier indicator field parameter may notify the first device 110-1 of the field size of the carrier indicator to be assumed for the DCI.

[0071] Alternatively or additionally, the set of parameters may include a bandwidth part indicator field parameter indicating the size of the bandwidth part indicator field in the downlink control information. This parameter may enable the first device 110-1 to determine the field size to be assumed for the bandwidth part indicator field.

[0072] In some example embodiments, the parameter set may include a feedback timing indicator parameter indicating the size of a feedback timing indicator field in downlink control information. For example, the feedback timing indicator may be a PDSCH-to-HARQ_feedback timing indicator. When HARQ ACK / NACK or NACK only is enabled, the size of the feedback timing indicator field is the same for a terminal device receiving multicast traffic as indicated by the feedback timing indicator field parameter. However, the terminal device may need to interpret the feedback timing indicator differently, i.e., the same value of the feedback timing indicator may correspond to different timings. For example, if HARQ ACK / NACK is enabled, a first device 110-1 may need to interpret the signaling value in the PDSCH-to-HARQ_feedback timing indicator field differently from another first device (e.g., device 110-2). In such a case, the first device 110-1 needs to receive a configuration indicating how the device interprets the value of the PDSCH-to-HARQ_feedback timing indicator, e.g., in a first RRC configuration 2010. The first device 110-1 may combine the configuration received using the first RRC configuration and a common configuration received using a second RRC configuration to derive a unique HARQ ACK / NACK feedback resource.

[0073] In some embodiments, a second device 120 may configure an offset to be applied by a first device 110-1 for G-RNTI scrambled DCI. The first device 110-1 may determine the feedback timing based on the offset. For example, the first device 110-1 may then determine an index I = (PDSCH-to-HARQ_feedback timing indicator + offset) mod 2^(length of the PDSCH-to-HARQ_feedback timing indicator field). Alternatively, the second device 120 may configure a PUCCH configuration table in a desired order.

[0074] In other example embodiments, the parameter set may include a priority indicator field parameter indicating the size of a priority indicator field in downlink control information.

[0075] In addition, the parameter set may include parameters for optional configurations. The parameter may indicate the size of the optional configuration in the downlink control information. The optional configuration may include a virtual resource block (VRB) to physical resource block (PRB) mapping. The optional configuration may also include a PRB bundling size indicator. In other embodiments, the optional configuration may include a rate matching indicator. Alternatively or additionally, the optional configuration may include a zero-power channel state information reference signal (ZP CSI-RS) trigger. The optional configuration may also include a downlink allocation index. In some example embodiments, the optional configuration may include an antenna port and number of layers. In other example embodiments, the optional configuration may include a physical downlink shared channel (PDSCH) group index. The optional configuration may include a new feedback indicator. Additionally, the optional configuration may include the number of requested PDSCH groups. As an example embodiment, the optional configuration may include a sounding reference signal request. Code block group (CBG) transmission information may be included in the optional configuration. The optional configuration may also include CBG flush information (CBGFI). Alternatively or additionally, the optional configuration may include a minimum applicable scheduling offset indicator. In some example embodiments, the optional configuration may include a secondary cell dormancy indication. The optional configuration may include other configurations that have no explicit requirement for multicast services.

[0076] The parameter set may include any one or any combination of the above parameters. The parameter set may also include (one or more) other parameters that are also related to the field size in the estimated DCI.

[0077] In some embodiments, the parameter set may be signaled as part of the PDCCH configuration. For example, pdcch-config-mbs based on pdcch-config, where pdcch-config provides the UE's control resource set parameters and additional parameters required to obtain the PDCCH, as defined in TS 38.331, and provides a set of common DCI field size parameters that need to be applied to DCI with CRC scrambled using G-RNTI. Alternatively, the parameter set may be signaled as part of the PDSCH configuration. For example, pdsch-config-mbs based on pdsch-config, where pdsch-config contains the higher layer parameters used by the UE to estimate some variable size DCI fields, as defined in TS 38.331. The PDCCH configuration / PDSCH configuration may be transmitted as part of a second RRC configuration. The second RRC configuration may be a group common RRC message. For example, the second RRC configuration may be signaled using a group common RNTI. The second RRC configuration may also be a UE specific RRC message, and the first device 110-1 may apply the second RRC configuration to determine the DCI size only for DCI scrambled using the group common RNTI. In an example embodiment, the second RRC configuration may be transmitted together with the first RRC configuration in a single UE specific RRC message.

[0078] Alternatively, default values for some or all of the parameters of the parameter set may be predetermined or configured at the first device 110-1. If multicast scheduling parameters such as G-RNTI, associated search space, and DCI format are configured, and if the second device 120 does not transmit some or all of the parameters of the parameter set to the first device, the first device 110-1 may apply these default values to estimate the DCI size for blind decoding. The default values may be specified in a standard specification, hard-coded in the first device, or configured by the second device via some configuration message (e.g., the first RRC configuration).

[0079] At block 310, a first device 110-1 receives a multicast DCI from a second device 120. For example, the format of the DCI may be DCI format 1_0 or DCI format 1_1. If the format of the DCI is DCI format 1_0, the DCI has only a limited variable-size field. In some embodiments, the first device 110-1 may determine the DCI format of the above DCI. If the DCI format is not a preconfigured format (by way of example only, DCI format 1_0), the first device 110-1 may determine whether a common frequency resource (CFR) is configured. In this case, if the CFR is not configured, the first device 110-1 may determine a frequency-domain resource allocation (FDRA) field size based on the active bandwidth part size. Alternatively, if the CFR is configured, the first device 110-1 may determine the FDRA field size based on the CFR size.

[0080] At block 320, the first device 110-1 determines one or more field sizes in the DCI based on a parameter set. By way of example only, the parameter set may indicate the following: the carrier indicator field has 3 bits, the bandwidth part indicator field has 1 bit, the VRB-to-PRB mapping field has 1 bit, the PRB bundling size indicator field has 0 bits, the rate matching indicator field has 2 bits, the ZP CSI-RS trigger field has 2 bits, the downlink allocation index has 4 bits, the PDSCH-to-HARQ_feedback timing indicator field has 0 bits, the (multiple) antenna port and layer number field has 4 bits, the transmission configuration indicator field has 3 bits, the CBGTI field has 6 bits, and the CBGFI field has 1 bit. In this way, the field sizes in the DCI can be correctly determined, and DCI decoding failures can be avoided.

[0081] In some embodiments, if the first device 110-1 does not receive a second RRC configuration for multicast service from the second device 120, the first device 110-1 may determine whether the parameter set is pre-determined and configured at the first device 110-1. If the parameter set is pre-determined and configured at the first device 110-1, the first device 110-1 may determine one or more field sizes based on the pre-determined and configured parameter set.

[0082] Alternatively, the second RRC configuration for the multicast service may include a subset of the parameter set. The remaining parameters in the parameter set may have default values at the first device 110-1. In other words, the remaining parameters may be predefined, and the second RRC configuration does not need to carry the remaining parameters with default values. In this case, the first device 110-1 may determine one or more field sizes based on the subset of the parameters and the default values of the remaining parameters. In this way, signaling can be reduced. Merely by way of example, the second RRC configuration for the multicast service may indicate that the carrier indicator field has 3 bits, the bandwidth part indicator field has 1 bit, the VRB-to-PRB mapping field has 1 bit, and the PRB bundling size indicator field has 0 bits. The remaining parameters are default values. For example, the rate matching indicator field is set to 0 bits, the ZP CSI-RS triggering field is set to 0 bits, the downlink allocation index is set to 0 bits, the PDSCH-to-HARQ_feedback timing indicator field is set to 0 bits, the (multiple) antenna port and layer number field has 4 bits, the transmission configuration indicator field is set to 0 bits, the CBGTI field is set to 0 bits, and the CBGFI field is set to 0 bits. Therefore, the first device 110-1 may determine the field sizes of the carrier indicator field, the bandwidth part indicator field, the VRB-to-PRB mapping field, and the bandwidth part indicator field based on the first subset of parameters in the second RRC configuration, and determine the field sizes of other fields based on the second subset of parameters with default values. The default values of some or all of the parameters may be sent via an RRC configuration that is common to all UEs receiving the multicast or broadcast service. This may be achieved by defining a specific radio network temporary identifier for signaling the default values from the second device to the first device. The default values of some or all of the parameters may also be sent individually to each UE, e.g., via the first RRC configuration, to indicate that these parameters are only for receiving the multicast or broadcast service, where the CRC of the DCI is scrambled using the G-RNTI.

[0083] In block 330, the first device 110-1 decodes the DCI based on the determined one or more field sizes. For example, as described above, the first device 110-1 may determine the sizes of the fields in the DCI based on the parameter set. The first device 110-1 may correctly decode the DCI because it knows the field sizes. If multicast scheduling parameters such as the G-RNTI, the associated search space, and the DCI format are configured, the first device 110-1 may apply the parameter set received from the second device 120 or configured at the first device 110-1 for blind decoding. In this way, the efficiency of blind decoding is improved.

[0084] Reference Figure 4 and Figure 5 describes example embodiments for estimating the field sizes in the DCI.Figure 4 FIG. 400 is a flowchart showing an example method 400 according to some example embodiments of the present disclosure. For purposes of discussion, method 400 will be described from the perspective of a first device. For illustrative purposes only, method 400 is described with reference to the first device 110-1.

[0085] At block 410, the first device 110-1 may receive DCI for a multicast service from the second device 120. For example, the format of the DCI may be DCI format 1_0 or DCI format 1_1.

[0086] At block 420, the first device 110-1 may determine whether the DCI format is different from DCI format 1_0. If the DCI format is DCI format 1_0, the DCI has only a limited variable-size field and method 400 may stop.

[0087] If the DCI format is not DCI format 1_0, the first device 110-1 may determine at block 430 whether CFR is configured. CFR affects the determination of the FDRA field size. If CFR is configured, at block 440, the first device 110-1 may determine the FDRA field size based on the CFR size.

[0088] If CFR is not configured, at block 450, the first device 110-1 may determine the FDRA field size based on the BWP size. At block 460, the first device may determine whether the parameter set is configured. In other words, the first device may determine whether the high-layer parameters of the variable-size DCI field are configured - for example, using pdcch / pdsch-config-mbs.

[0089] If the parameter set is configured, at block 470, the first device 110-1 may determine one or more field sizes based on the parameter set. The first device 110-1 may perform blind coding on an appropriate search space or control channel element based on the one or more field sizes. The first device 110-1 may apply the determined one or more field sizes to blind decoding on the search space / control channel element related to the multicast service. If the parameter set is not configured, at block 480, the first device 110-1 may be based on the currently used RRC parameters (e.g., Figure 2To determine one or more field sizes according to the first RRC configuration mentioned in [reference]. The term "control channel element (CCE)" used in this document may refer to a resource element group (REG), where the resource element group is equal to one resource block during one OFDM symbol. The term "search space" used in this document may refer to the area in the downlink resource grid where the PDCCH can be carried. The search space can be indicated by a set of consecutive control channel elements (CCE), and the UE should monitor this set of CCEs for scheduling assignments / authorizations related to a certain component carrier. For example, two search spaces are used in NR-PDCCH to control each component carrier, such as the common search space (CSS) and the UE-specific search space (USS). For the CSS, the DCI cyclic redundancy check (CRC) can be scrambled using the following: system information RNTI (SI-RNTI), random access RNTI (RA RNTI), temporary cell RNTI (TC-RNTI), paging RNTI (P-RNTI), interruption RNTI (INT-RNTI), slot format indication RNTI (SFI-RNTI), transmission power control (TPC)-PUCCH-RNTI, TPC-PUSCH-RNTI, TPC-SRS-RNTI, cell RNTI (C-RNTI), configured scheduling RNTI (CS-RNTI). For the USS, the DCI CRC can be scrambled with C-RNTI and CS-RNTI, which are specific to individual UEs. The CSS is shared among all UEs, and the USS is used on a per-UE basis (indicating that the SS is UE-specific).

[0090] Figure 5 FIG. [reference] shows a flowchart of an example method 500 according to some example embodiments of the present disclosure. For the purpose of discussion, method 500 will be described from the perspective of the first device. For illustrative purposes only, method 500 is described with reference to the first device 110-1.

[0091] At block 510, the first device 110-1 may receive DCI for multicast services from the second device 120. For example, the format of the DCI may be DCI format 1_0 or DCI format 1_1.

[0092] At block 520, the first device 110-1 may determine whether the DCI format is different from DCI format 1_0. If the DCI format is DCI format 1_0, the DCI has only a limited number of variable-size fields and method 500 may stop.

[0093] If the DCI format is not DCI format 1_0, the first device 110-1 may determine in block 530 whether CFR is configured. CFR affects the determination of the FDRA field size. If CFR is configured, then in block 540, the first device 110-1 may determine the FDRA field size based on the CFR size.

[0094] If CFR is not configured, then in block 550, the first device 110-1 may determine the FDRA field size based on the BWP size. In block 560, the first device may determine whether the parameter set is configured. In other words, the first device may determine whether the high-layer parameters of the variable-size DCI field are configured - for example, using pdcch / pdsch-config-mbs.

[0095] If the parameter set is configured, then in block 570, the first device 110-1 may determine one or more field sizes based on the parameter set. The first device 110-1 may perform blind coding on an appropriate search space based on the one or more field sizes.

[0096] If the parameter set is not configured, then in block 580, the first device 110-1 may determine whether a default value of the parameter for field size estimation is defined. In other words, the first device 110-1 may determine whether the default value of the parameter set is configured at the first device 110-1. If the default value is not defined, then in block 585, the first device 110-1 may determine one or more field sizes based on the currently used RRC parameters (e.g., Figure 2 the first RRC configuration mentioned in

[0097] If the default value is defined, then in block 590, the first device 110-1 may determine one or more field sizes based on the default value. In some embodiments, the default value may be predetermined. The second RRC configuration needs to be sent only when the field size is different from the default value. The configuration signaling of pdcch / pdsch-config-mbs may include an indicator - it may be the name of the variable-size DCI field, which indicates a different set of field sizes to be applied to the DCI size estimation. In this way, it enables reduction of signaling from the network because these values need to be sent to the first device 110-1 only when they are different from the default value.

[0098] Figure 6 A flowchart of an example method 600 according to some example embodiments of the present disclosure is shown. For the purpose of discussion, method 600 will be described from the perspective of the second device. For illustrative purposes only, the second device may be the second device 120.

[0099] At block 610, the second device 120 transmits the RRC configuration of the multicast service to the first device 110-1. The multicast service can be any suitable type of multicast service - which is received by a group of users, or can be a broadcast service that can be received by all users connected to the network.

[0100] The RRC configuration can include a set of parameters associated with the field size estimation of the multicast service. For example, the set of parameters can include a carrier indicator field parameter indicating the size of the carrier indicator field in the DCI for the multicast service. In other words, the carrier indicator field parameter can notify the first device 110-1 of the field size of the carrier indicator to be assumed for the DCI.

[0101] Alternatively or additionally, the set of parameters can include a bandwidth part indicator field parameter indicating the size of the bandwidth part indicator field in the downlink control information. This parameter can enable the first device 110-1 to determine the field size to be assumed for the bandwidth part indicator field.

[0102] In some example embodiments, the set of parameters can include a feedback timing indicator parameter indicating the size of the feedback timing indicator field in the downlink control information. For example, the feedback timing indicator can be a PDSCH-to-HARQ_feedback timing indicator. When HARQ ACK / NACK or only NACK is enabled, the size of the feedback timing indicator field is the same for the terminal device receiving the multicast service as that indicated by the feedback timing indicator field parameter. However, the terminal device may need to interpret the feedback timing indicator differently, that is, the same value of the feedback timing indicator can correspond to different timings. For example, if HARQ ACK / NACK is enabled, the first device 110-1 may need to interpret the signaling value in the PDSCH-to-HARQ_feedback timing indicator field differently from another first device (e.g., device 110-2). In this case, the first device 110-1 needs to receive a configuration indicating how the device interprets the value of the PDSCH-to-HARQ_feedback timing indicator in, for example, the first RRC configuration 2010. The first device 110-1 can combine the configuration received using the first RRC configuration and the common configuration received using the second RRC configuration to derive a unique HARQ ACK / NACK feedback resource.

[0103] In some embodiments, the second device 120 can configure the offset to be applied by the first device 110-1 for the G-RNTI scrambled DCI. Alternatively, the second device 120 can configure the PUCCH configuration table in the required order.

[0104] In other example embodiments, the parameter set may include a priority indicator field parameter indicating the size of a priority indicator field in downlink control information.

[0105] In addition, the parameter set may include parameters for optional configurations. The parameter may indicate the size of an optional configuration in downlink control information. The optional configuration may include virtual resource block (VRB) to physical resource block (PRB) mapping. The optional configuration may also include a PRB bundling size indicator. In other embodiments, the optional configuration may include a rate matching indicator. Alternatively or additionally, the optional configuration may include a zero-power channel state information reference signal (ZP CSI-RS) trigger. The optional configuration may also include a downlink allocation index. In some example embodiments, the optional configuration may include antenna ports and number of layers. In other example embodiments, the optional configuration may include a physical downlink shared channel (PDSCH) group index. The optional configuration may include a new feedback indicator. Additionally, the optional configuration may include the number of requested PDSCH groups. As an example embodiment, the optional configuration may include a sounding reference signal request. Code block group (CBG) transmission information may be included in the optional configuration. The optional configuration may also include CBG flush information (CBGFI). Alternatively or additionally, the optional configuration may include a minimum applicable scheduling offset indicator. In some example embodiments, the optional configuration may include secondary cell dormancy indication. The optional configuration may include other configurations with no explicit requirements for multicast services.

[0106] The parameter set may include any one or any combination of the above parameters. The parameter set may also include (one or more) other parameters that are also related to estimating the field sizes in DCI.

[0107] In some embodiments, the parameter set may be signaled as part of the PDCCH configuration. For example, pdcch-config-mbs based on pdcch-config, where pdcch-config provides the UE's control resource set parameters and additional parameters required to obtain the PDCCH, as defined in TS 38.331, and provides a set of common DCI field size parameters that need to be applied to DCI with a CRC scrambled using a G-RNTI. Alternatively, the parameter set may be signaled as part of the PDSCH configuration. For example, pdsch-config-mbs based on pdsch-config, where pdsch-config contains high-layer parameters used by the UE to estimate some variable-size DCI fields, as defined in TS 38.331. The PDCCH configuration / PDSCH configuration may be transmitted as part of a second RRC configuration. The second RRC configuration may be a group common RRC message. For example, the second RRC configuration may be signaled using a group common RNTI. The second RRC configuration may also be a UE-specific RRC message, and the first device 110-1 may apply the second RRC configuration to determine the DCI size only for DCI scrambled using a group common RNTI. In an exemplary embodiment, the second RRC configuration may be transmitted together with the first RRC configuration in a single UE-specific RRC message.

[0108] Alternatively, default values for some or all of the parameters of the parameter set may be pre-determined or configured at the first device 110-1. If multicast scheduling parameters such as G-RNTI, associated search space, and DCI format are configured, and if the second device 120 does not transmit some or all of the parameters of the parameter set to the first device, the first device 110-1 may apply these default values to estimate the DCI size for blind decoding. The default values may be specified in a standard specification, hard-coded in the first device, or configured by the second device via a certain configuration message (e.g., the first RRC configuration).

[0109] Alternatively, the second RRC configuration for the multicast service may include a subset of the parameter set. The remaining parameters in the parameter set may have default values at the first device 110-1. In other words, the remaining parameters may be predefined, and the second RRC configuration does not need to carry the remaining parameters with default values. In this case, the first device 110-1 may determine one or more field sizes based on the subset of the parameters and the default values of the remaining parameters. In this way, signaling can be reduced. Only by way of example, the second RRC configuration for the multicast service may indicate that the carrier indicator field has 3 bits, the bandwidth part indicator field has 1 bit, the VRB-to-PRB mapping field has 1 bit, and the PRB bundling size indicator field has 0 bits. The remaining parameters are default values. For example, the rate matching indicator field is set to 0 bits, the ZP CSI-RS triggering field is set to 0 bits, the downlink allocation index is set to 0 bits, the PDSCH-to-HARQ_feedback timing indicator field is set to 0 bits, the (multiple) antenna port and layer number field has 4 bits, the transmission configuration indicator field is set to 0 bits, the CBGTI field is set to 0 bits, and the CBGFI field is set to 0 bits. The default values of some or all of the parameters may be sent via an RRC configuration that is common to all UEs receiving the multicast or broadcast service. This may be achieved by defining a specific radio network temporary identifier for signaling the default values from the second device to the first device. The default values of some or all of the parameters may also be sent individually to each UE, for example, via the first RRC configuration, to indicate that these parameters are only used for receiving the multicast or broadcast service, where the CRC of the DCI is scrambled using the G-RNTI.

[0110] In block 620, the second device 120 transmits the multicast DCI to the first device 110-1. For example, the format of the DCI may be DCI format 1_0 or DCI format 1_1. If the format of the DCI is DCI format 1_0, the DCI has only a limited number of variable-size fields. In some embodiments, the first device 110-1 may determine the DCI format of the above DCI. If the DCI format is not a preconfigured format (only by way of example, DCI format 1_0), the first device 110-1 may determine whether a common frequency resource (CFR) is configured. In this case, if the CFR is not configured, the first device 110-1 may determine the frequency domain resource allocation (FDRA) field size based on the active bandwidth part size. Alternatively, if the CFR is configured, the first device 110-1 may determine the FDRA field size based on the CFR size.

[0111] In some example embodiments, an apparatus (e.g., the first device 110) capable of performing method 300 may include components for performing the corresponding operations of method 300. The components may be implemented in any suitable form. For example, the components may be implemented by circuitry or software modules. The apparatus may be implemented as the first device 110 or included in the first device 110. In some example embodiments, the components may include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code are configured to cause the operation of the apparatus with the at least one processor.

[0112] In some example embodiments, the apparatus includes components for receiving, at a first device, downlink control information for multicast traffic from a second device; for determining, at the first device, one or more field sizes in the downlink control information based on a parameter set associated with the field size estimation of the multicast traffic; and for decoding the downlink control information based on the determined one or more field sizes.

[0113] In some example embodiments, the parameter set includes at least one of the following: a carrier indicator field parameter indicating the size of a carrier indicator field in the downlink control information, a bandwidth part indicator parameter indicating the size of a bandwidth part indicator field in the downlink control information, a feedback timing indicator parameter indicating the size of a feedback timing indicator field in the downlink control information, a priority indicator field parameter indicating the size of a priority indicator field in the downlink control information, or a parameter of an optional configuration indicating the size of an optional configuration field in the downlink control information.

[0114] In some example embodiments, the optional configuration includes at least one of the following: virtual resource block to physical resource block mapping, physical resource block bundling size indicator, rate matching indicator, zero-power channel state information reference signal, downlink allocation index, antenna port and number of layers, physical downlink shared channel (PDSCH) group index, new feedback indicator, number of requested PDSCH groups, sounding reference signal request, code block group transmission information, code block group refresh information, minimum applicable scheduling offset indicator, or secondary cell dormancy indication.

[0115] In some example embodiments, the apparatus further includes components for receiving, from the second device, radio resource control configuration for the multicast traffic. In some example embodiments, the components for determining one or more field sizes include: components for determining, according to determining that the radio resource control configuration includes the parameter set, one or more field sizes based on the parameter set in the radio resource control configuration.

[0116] In some example embodiments, the apparatus further includes components for determining whether the parameter set is pre-determined and configured at the first device based on determining that there is no radio resource control configuration for the multicast service. In some example embodiments, the components for determining one or more field sizes include: components for determining one or more field sizes based on the pre-determined and configured parameter set according to determining that the parameter set is pre-determined and configured at the first device.

[0117] In some example embodiments, the apparatus further includes components for receiving, from a second device, a radio resource control configuration for the multicast service including a first subset of parameters. In some example embodiments, the components for determining one or more field sizes include: components for determining one or more field sizes based on the first subset of parameters and a second subset of parameters that are default values at the first device.

[0118] In some example embodiments, the apparatus further includes components for determining the format of downlink control information; components for determining whether a common frequency resource is configured according to determining that the format is not a pre-configured format; components for determining the field size of the frequency domain resource allocation based on the active bandwidth part size according to determining that the common frequency resource is not configured; or components for determining the field size of the frequency domain resource allocation based on the common frequency resource size according to determining that the common frequency resource is configured.

[0119] In some example embodiments, the apparatus further includes components for applying the determined one or more field sizes to blind decoding on a search space related to the multicast service.

[0120] In some example embodiments, an apparatus (e.g., the second device 120) capable of performing method 600 may include components for performing the corresponding operations of method 600. The components may be implemented in any suitable form. For example, the components may be implemented by circuitry or software modules. The apparatus may be implemented as the second device 120 or included in the second device 120. In some example embodiments, the components may include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code are configured to cause the operation of the apparatus in conjunction with the at least one processor.

[0121] In some example embodiments, the apparatus includes components for transmitting, at a second device, a radio resource control configuration for the multicast service to a first device, the radio resource control configuration including a parameter set associated with the field size estimation of the multicast service; and components for transmitting downlink control information of the multicast service to the first device.

[0122] In some example embodiments, the parameter set includes at least one of the following: a carrier indicator field parameter indicating the size of a carrier indicator field in downlink control information, a bandwidth part indicator parameter indicating the size of a bandwidth part indicator field in downlink control information, a feedback timing indicator parameter indicating the size of a feedback timing indicator field in downlink control information, a priority indicator field parameter indicating the size of a priority indicator field in downlink control information, or a parameter for optional configuration indicating the size of an optional configuration field in downlink control information.

[0123] In some example embodiments, the optional configuration includes at least one of the following: virtual resource block to physical resource block mapping, physical resource block bundling size indicator, rate matching indicator, zero-power channel state information reference signal, downlink allocation index, antenna port and number of layers, physical downlink shared channel (PDSCH) group index, new feedback indicator, number of requested PDSCH groups, sounding reference signal request, code block group transmission information, code block group refresh information, minimum applicable scheduling offset indicator, or secondary cell dormancy indication.

[0124] Figure 7 is a simplified block diagram of a device 700 suitable for implementing example embodiments of the present disclosure. The device 700 may be provided to implement a communication device, such as Figure 1 the first device 110 or the second device 120 as shown. As shown, the device 700 includes one or more processors 710, one or more memories 720 coupled to the processors 710, and one or more communication modules 740 coupled to the processors 710.

[0125] The communication module 740 is used for two-way communication. The communication module 740 has one or more communication interfaces to facilitate communication with one or more other modules or devices. The communication interface may represent any interface necessary for communicating with other network elements. In some example embodiments, the communication module 740 may include at least one antenna.

[0126] The processor 710 may be of any type suitable for a local technical network and, by way of non-limiting example, may include one or more of the following: a general-purpose computer, a special-purpose computer, a microprocessor, a digital signal processor (DSP), and a processor based on a multi-core processor architecture. The device 700 may have multiple processors, such as an application-specific integrated circuit chip that is subordinate in time to a clock synchronized with a main processor.

[0127] The memory 720 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memories include, but are not limited to, read-only memory (ROM) 724, electrically programmable read-only memory (EPROM), flash memory, hard disk, compact disk (CD), digital video disk (DVD), optical disk, laser disk, and other magnetic storage and / or optical storage. Examples of volatile memories include, but are not limited to, random access memory (RAM) 722 and other volatile memories that do not persist during a power outage.

[0128] The computer program 730 includes computer-executable instructions that are executed by the associated processor 710. The program 730 may be stored in a memory (e.g., ROM 724). The processor 710 may execute any suitable actions and processes by loading the program 730 into the RAM 722.

[0129] Example embodiments of the present disclosure may be implemented by the program 730 such that the device 700 may perform any process of the present disclosure as discussed with reference to Figures 2 to 6 Example embodiments of the present disclosure may also be implemented by hardware or a combination of software and hardware.

[0130] In some example embodiments, the program 730 may be tangibly embodied in a computer-readable medium, which may be included in the device 700 (such as the memory 720) or other storage devices accessible to the device 700. The device 700 may load the program 730 from the computer-readable medium into the RAM 722 for execution. The computer-readable medium may include any type of tangible non-volatile memory, such as ROM, EPROM, flash memory, hard disk, CD, DVD, and other magnetic storage and / or optical storage. Figure 8 An example of a computer-readable medium 800 in the form of an optical storage disk is shown. The program 730 is stored on the computer-readable medium.

[0131] Generally, the various embodiments of the present disclosure may be implemented using hardware or a dedicated circuit, software, logic, or any combination thereof. Some aspects may be implemented using hardware, while other aspects may be implemented using firmware or software that may be executed by a controller, microprocessor, or other computing device. Although the various aspects of the embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other graphical representation, it should be understood that, by way of non-limiting example, the blocks, devices, systems, techniques, or methods described herein may be implemented using hardware, software, firmware, a dedicated circuit or logic, general hardware or a controller or other computing device, or some combination thereof.

[0132] The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions, such as instructions included in program modules, which are executed in a device on a target real or virtual processor to perform any of the methods described above with reference to Figures 2 to 6 any of the methods described above. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. In various embodiments, the functions of program modules may be combined or split among program modules as needed. The machine-executable instructions of program modules may be executed within local or distributed devices. In a distributed device, program modules may be located in both local and remote storage media.

[0133] The program code for performing the methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that the program codes, when executed by the processor or controller, cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0134] In the context of the present disclosure, the computer program code or related data may be carried by any suitable carrier such that a device, apparatus, or processor can perform the various processes and operations described above. Examples of carriers include signals, computer-readable media, etc.

[0135] The computer-readable media may be a computer-readable signal medium or a computer-readable storage medium. The computer-readable media may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of the computer-readable storage medium will include an electrical connection having one or more wires, a portable computer floppy disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0136] Moreover, although the operations are described in a particular order, this should not be construed as requiring that the operations be performed in the particular order shown or in sequential order, or that all of the illustrated operations be performed to obtain the desired result. In some cases, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the foregoing discussion, these should not be construed as limitations on the scope of the disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented separately or in any suitable sub-combination in multiple embodiments.

[0137] Although the present disclosure has been described in language specific to structural features and / or methodological acts, it is to be understood that the disclosure is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the disclosure.

Claims

1. A first device for communication, comprising: at least one processor; and at least one memory, including computer program code; wherein the at least one memory and the computer program code are configured to, together with the at least one processor, cause the first device to: receive, from a second device, a radio resource control configuration for a multicast service, wherein the radio resource control configuration includes a parameter set associated with a field size estimation of downlink control information of the multicast service; receive the downlink control information of the multicast service from the second device; at the first device, determine one or more field sizes of fields in the downlink control information based on the parameter set; and decode the downlink control information based on the determined one or more field sizes, wherein the parameter set includes at least one of the following: a carrier indicator field parameter indicating the size of a carrier indicator field in the downlink control information, a feedback timing indicator parameter indicating the size of a feedback timing indicator field in the downlink control information, a priority indicator field parameter indicating the size of a priority indicator field in the downlink control information, or a parameter of an optional configuration indicating the size of an optional configuration field in the downlink control information.

2. The first device according to claim 1, wherein the optional configuration includes at least one of the following: virtual resource block to physical resource block mapping, physical resource block bundling size indicator, rate matching indicator, zero power channel state information reference signal, downlink allocation index, antenna port and number of layers, physical downlink shared channel (PDSCH) group index, new feedback indicator, number of requested PDSCH groups, sounding reference signal request, code block group transmission information, code block group refresh information, minimum applicable scheduling offset indicator, or secondary cell dormancy indication.

3. The first device according to claim 1, wherein the at least one memory and the computer program code are configured to, together with the at least one processor, further cause the first device to determine the one or more field sizes by: according to determining that the radio resource control configuration includes the parameter set, determine the one or more field sizes based on the parameter set in the radio resource control configuration.

4. The first device according to claim 1, wherein the at least one memory and the computer program code are configured to, together with the at least one processor, further cause the first device to: according to determining that there is no radio resource control configuration for the multicast service, determine whether the parameter set is pre-determined and configured at the first device; and wherein the at least one memory and the computer program code are configured to, together with the at least one processor, further cause the first device to determine the one or more field sizes by: Based on determining that the parameter set is predetermined and configured at the first device, determine the one or more field sizes based on the predetermined and configured parameter set.

5. The first device according to claim 1, wherein the at least one memory and the computer program code are configured to, together with the at least one processor, further cause the first device to: Receive, from the second device, a radio resource control configuration for the multicast service including a first subset of the parameters; and wherein the at least one memory and the computer program code are configured to, together with the at least one processor, further cause the first device to determine the one or more field sizes by: Determine the one or more field sizes based on the first subset of the parameters and a second subset of the parameters that are default values at the first device.

6. The first device according to claim 1, wherein the at least one memory and the computer program code are configured to, together with the at least one processor, further cause the first device to: Determine the format of the downlink control information; Based on determining that the format is not a preconfigured format, determine whether a common frequency resource is configured; Based on determining that the common frequency resource is not configured, determine a frequency domain resource allocation field size based on the active bandwidth part size; or Based on determining that the common frequency resource is configured, determine a frequency domain resource allocation field size based on the common frequency resource size.

7. The first device according to claim 1, wherein the at least one memory and the computer program code are configured to, together with the at least one processor, further cause the first device to: Apply the determined one or more field sizes to blind decoding of a search space related to the multicast service.

8. A second device for communication, comprising: At least one processor; And At least one memory including computer program code; wherein the at least one memory and the computer program code are configured to, together with the at least one processor, cause the second device to: Transmit to a first device a radio resource control configuration for a multicast service, the radio resource control configuration including a parameter set associated with an estimation of a field size of the multicast service; and Transmit to the first device the downlink control information of the multicast service, wherein the parameter set enables the first device to determine one or more field sizes of fields in the downlink control information and decode the downlink control information based on the determined one or more field sizes, and wherein the parameter set includes at least one of the following: A carrier indicator field parameter indicating the size of a carrier indicator field in the downlink control information, A feedback timing indicator parameter indicating the size of a feedback timing indicator field in the downlink control information, A priority indicator field parameter indicating the size of a priority indicator field in the downlink control information, or A parameter of an optional configuration, which indicates the size of an optional configuration field in the downlink control information.

9. The second device according to claim 8, wherein the optional configuration includes at least one of the following: Virtual resource block to physical resource block mapping, Physical resource block bundling size indicator, Rate matching indicator, Zero-power channel state information reference signal, Downlink allocation index, Antenna port and number of layers, Physical downlink shared channel (PDSCH) group index, New feedback indicator, Number of requested PDSCH groups, Sounding reference signal request, Code block group transmission information, Code block group refresh information, Minimum applicable scheduling offset indicator, or Secondary cell dormancy indication.

10. A communication method, comprising: At a first device, receiving, from a second device, a radio resource control configuration for a multicast service, wherein the radio resource control configuration includes a parameter set associated with an estimation of a field size of downlink control information for the multicast service; At the first device, receiving the downlink control information for the multicast service from the second device; At the first device, determining, based on the parameter set, one or more field sizes of fields in the downlink control information; And Decoding the downlink control information based on the determined one or more field sizes, wherein the parameter set includes at least one of the following: A carrier indicator field parameter, which indicates the size of a carrier indicator field in the downlink control information, A feedback timing indicator parameter, which indicates the size of a feedback timing indicator field in the downlink control information, A priority indicator field parameter, which indicates the size of a priority indicator field in the downlink control information, or A parameter of an optional configuration, which indicates the size of an optional configuration field in the downlink control information.

11. The method according to claim 10, wherein the optional configuration includes at least one of the following: Virtual resource block to physical resource block mapping, Physical resource block bundling size indicator, Rate matching indicator, Zero-power channel state information reference signal, Downlink allocation index, Antenna port and number of layers, Physical downlink shared channel (PDSCH) group index, New feedback indicator, Number of requested PDSCH groups, Sounding reference signal request, Code block group transmission information, Code block group refresh information, Minimum applicable scheduling offset indicator, or Secondary cell dormancy indication.

12. The method according to claim 10, wherein determining the one or more field sizes includes: Based on determining that the radio resource control configuration includes the parameter set, determining the one or more field sizes based on the parameter set in the radio resource control configuration.

13. The method according to claim 10, further comprising: Based on determining that there is no radio resource control configuration for the multicast service, determining whether the parameter set is pre-determined and configured at the first device; And wherein determining the one or more field sizes includes: Based on the determination that the parameter set is predetermined and configured at the first device, determine the one or more field sizes based on the predetermined and configured parameter set.

14. The method according to claim 10, further comprising: Receiving, from the second device, a radio resource control configuration for the multicast service including a first subset of the parameters; And Wherein determining the one or more field sizes includes: Determining the one or more field sizes based on the first subset of the parameters and a second subset of the parameters that are default values at the first device.

15. The method according to claim 10, further comprising: Determining the format of the downlink control information; Based on the determination that the format is not a preconfigured format, determining whether a common frequency resource is configured; Based on the determination that the common frequency resource is not configured, determining the frequency domain resource allocation field size based on the active bandwidth part size; Or Based on the determination that the common frequency resource is configured, determining the frequency domain resource allocation field size based on the common frequency resource size.

16. The method according to claim 10, further comprising: Applying the determined one or more field sizes to blind decoding of a search space related to the multicast service.

17. A method of communication, comprising: At a second device, transmitting to a first device a radio resource control configuration for a multicast service, the radio resource control configuration including a parameter set associated with field size estimation of the multicast service; And Transmitting to the first device the downlink control information of the multicast service, wherein the parameter set enables the first device to determine one or more field sizes of fields in the downlink control information and decode the downlink control information based on the determined one or more field sizes, and wherein the parameter set includes at least one of the following: A carrier indicator field parameter indicating the size of a carrier indicator field in the downlink control information, A feedback timing indicator parameter indicating the size of a feedback timing indicator field in the downlink control information, A priority indicator field parameter indicating the size of a priority indicator field in the downlink control information, or An optionally configured parameter indicating the size of an optional configuration field in the downlink control information.

18. The method according to claim 17, wherein the optional configuration includes at least one of the following: Virtual resource block to physical resource block mapping, Physical resource block bundling size indicator, Rate matching indicator, Zero-power channel state information reference signal, Downlink allocation index, Antenna port and number of layers, Physical downlink shared channel (PDSCH) group index, New feedback indicator, Number of requested PDSCH groups, Sounding reference signal request, Code block group transmission information, Code block group refresh information, Minimum applicable scheduling offset indicator, or Secondary cell sleep indication.

19. A computer-readable medium for communication, comprising program instructions that, when executed by a device, cause the device to perform: At a first device, receive a radio resource control configuration for a multicast service from a second device, where the radio resource control configuration includes a parameter set associated with a field size estimation of downlink control information for the multicast service; At the first device, receive the downlink control information for the multicast service from the second device; At the first device, determine one or more field sizes of fields in the downlink control information based on the parameter set; And Decode the downlink control information based on the determined one or more field sizes, where the parameter set includes at least one of the following: A carrier indicator field parameter that indicates a size of a carrier indicator field in the downlink control information, A feedback timing indicator parameter that indicates a size of a feedback timing indicator field in the downlink control information, A priority indicator field parameter that indicates a size of a priority indicator field in the downlink control information, or An optionally configured parameter that indicates a size of an optionally configured field in the downlink control information.

20. A computer-readable medium for communication, including program instructions that, when executed by a device, cause the device to perform: At a second device, transmit a radio resource control configuration for a multicast service to a first device, the radio resource control configuration including a parameter set associated with a field size estimation for the multicast service; and Transmit the downlink control information for the multicast service to the first device, where the parameter set enables the first device to determine one or more field sizes of fields in the downlink control information and to decode the downlink control information based on the determined one or more field sizes, and where the parameter set includes at least one of the following: A carrier indicator field parameter that indicates a size of a carrier indicator field in the downlink control information, A feedback timing indicator parameter that indicates a size of a feedback timing indicator field in the downlink control information, A priority indicator field parameter that indicates a size of a priority indicator field in the downlink control information, or An optionally configured parameter that indicates a size of an optionally configured field in the downlink control information.

Images