Downlink Size Estimation of Multicast Traffic

Abstract

The embodiments of the present disclosure relate to estimating downlink size of multicast traffic. According to the embodiments of the present disclosure, a first device receives downlink control information (DCI) of multicast traffic. The first device determines field size(s) in the DCI based on one or more parameters related to field size estimation of the multicast traffic. The first device decodes the DCI based on the determined field size(s). In this manner, the DCI can be correctly blind decoded.

Description

[Technical Field]

[0001] FIELD Embodiments of the present disclosure generally relate to the field of telecommunications, and more particularly, to a method, device, apparatus, and computer-readable storage medium for estimating downlink size of multicast traffic. [Background technology]

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

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

[0004] In a first aspect, a first device is provided, the first device comprising at least one processor and at least one memory containing computer program code configured, by the at least one processor, to cause the first device to receive downlink control information for multicast traffic from a second device, determine, at the first device, one or more field sizes in the downlink control information based on a set of parameters related to field size estimation for the multicast traffic, 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 comprising at least one processor and at least one memory including computer program code configured, by the at least one processor, to cause the second device to: transmit, to the first device, a radio resource control configuration for multicast traffic, the second radio resource control configuration including a set of parameters related to field size estimation for the multicast traffic; and transmit, to the first device, downlink control information for the multicast traffic.

[0006] In a third aspect, a method is provided that includes receiving, at a first device, downlink control information for multicast traffic 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 related to field size estimation for the multicast traffic, 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 including: transmitting, at a second device, a radio resource control configuration for multicast traffic to a first device, the second radio resource control configuration including a set of parameters related to field size estimation for the multicast traffic; and transmitting downlink control information of the multicast traffic to the first device.

[0008] In a fifth aspect, an apparatus is provided, comprising: means, at a first device, for receiving downlink control information for multicast traffic from a second device; means, at the first device, for determining one or more field sizes in the downlink control information based on a set of parameters related to field size estimation for the multicast traffic; 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, comprising: means, at a second device, for transmitting a radio resource control configuration for multicast traffic to a first device, the second radio resource control configuration including a set of parameters related to field size estimation for the multicast traffic; and means for transmitting downlink control information of the multicast traffic to the first device.

[0010] In a seventh aspect, there is provided a computer readable medium comprising program instructions for causing an apparatus to carry out at least a method according to any one of the third or fourth aspects above.

[0011] It should be understood that the Abstract is not intended to identify key features or essential features of the embodiments of the present disclosure, nor is it intended to limit the scope of the present disclosure. Other features of the present disclosure will become readily apparent through the following description. [Brief explanation of the drawings]

[0012] Some exemplary embodiments will now be described with reference to the accompanying drawings. [Figure 1] FIG. 1 illustrates an exemplary communications environment in which exemplary embodiments of the present disclosure may be implemented. [Figure 2] FIG. 2 illustrates a signaling flow for distributing beam information according to some exemplary embodiments of the present disclosure. [Figure 3] FIG. 3 illustrates a flowchart of a method implemented in a first device according to some exemplary embodiments of the present disclosure. [Figure 4] FIG. 4 shows a flowchart of a method implemented in a first device according to some other exemplary embodiments of the present disclosure. [Figure 5] FIG. 5 shows a flowchart of a method performed in a first device according to some other exemplary embodiments of the present disclosure. [Figure 6] FIG. 6 shows a flowchart of a method performed in a second device according to some other exemplary embodiments of the present disclosure. [Figure 7] FIG. 7 shows a simplified block diagram of an apparatus suitable for practicing exemplary embodiments of the present disclosure. [Figure 8] 8 illustrates a block diagram of an exemplary computer-readable medium according to some exemplary embodiments of the present disclosure. Throughout the drawings, the same or similar reference numerals represent the same or similar elements. DETAILED DESCRIPTION OF THE INVENTION

[0013] The principles of the present disclosure will now be described with reference to some exemplary embodiments. It should be understood that these embodiments are provided for illustrative purposes to help those skilled in the art understand and practice the present disclosure, and are not intended to imply any limitations on the scope of the present disclosure. The embodiments described herein can be implemented in various ways other than those described below.

[0014] In the following description and claims, 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 this disclosure belongs.

[0015] References in this disclosure to "one embodiment," "an embodiment," "an exemplary embodiment," etc., indicate that the described embodiment may include a particular feature, structure, or characteristic, but not all embodiments need include the particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is understood by those skilled in the art that such feature, structure, or characteristic may be affected in connection with other embodiments, whether or not explicitly stated.

[0016] Although terms such as "first" and "second" may be used herein to describe various elements, it should be understood that these elements are not limited by these terms. These terms are merely used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of the exemplary embodiments. As used herein, the term "and / or" includes any and all combinations of one or more of the listed terms.

[0017] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit 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 should be further understood that as used herein, the terms "comprises," "comprising," "has," "having," "includes," and / or "including" specify the presence of stated features, elements, and / or components, etc., but do not exclude the presence or addition of one or more other features, elements, components, and / or combinations thereof.

[0018] As used herein, the term "circuitry" may refer to one or more or all of the following: (a) hardware-only circuit implementations (e.g., analog and / or digital-only implementations); and (b) a combination of hardware circuitry and software, e.g., (where applicable); (i) a combination of analog and / or digital hardware circuitry and software / firmware; and (ii) software (including digital signal processors), software, and hardware processors with memory that operate to cause devices such as mobile phones and servers to perform various functions; and (c) Hardware circuits and processors, such as microprocessors or portions of microprocessors, that require software (e.g., firmware) to operate, but the software may be absent when not necessary for operation.

[0019] This definition of circuit applies to all uses of the term in this application, including any claims. As a further example, as used herein, the term circuit also covers simply a hardware circuit or processor (or processors) or portion of a hardware circuit or processor, and its (or their) accompanying software and / or firmware implementations. The term circuit also covers, for example, a baseband or processor integrated circuit for a mobile device, or a similar integrated circuit in a server, cellular network device, or other computing or network device, if applicable to a particular claim element.

[0020] As used herein, the term "communication network" refers to a network conforming to any appropriate communication standard, such as New Radio (NR), New Radio-Advanced (NR-A), Long Term Evolution (LTE), LTE-Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), High-Speed ​​Packet Access (HSPA), or Narrowband Internet of Things (NB-IoT). Furthermore, communications between terminal equipment and network devices in a communication network may be performed according to any appropriate generation of communication protocols, including, but not limited to, 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 protocols currently known or developed in the future. Embodiments of the present disclosure may be applied to various communication systems. Given the rapid development of communications, there will, of course, be future communication technologies and systems in which the present disclosure may be embodied. The scope of the present disclosure should not be considered limited to only the aforementioned systems.

[0021] As used herein, the term "network device" refers to a node in a communication network through which terminal equipment accesses the network and receives services therefrom. A network device may refer to a base station (BS) or access point (AP), such as a Node B (NodeB or NB), evolved Node B (eNodeB or eNB), NR NB (also known as gNB), remote radio unit (RRU), radio header (RH), remote radio head (RRH), relay, integrated and access backhaul (IAB) node, low-power node such as femto or pico, non-terrestrial network (NTN) or non-terrestrial network device such as satellite network device, low earth orbit (LEO) satellite, geostationary earth orbit (GEO) satellite, airborne network device, etc., depending on the terminology and technology applied. The term "terminal equipment" refers to any terminal equipment capable of wireless communication. In the following description, the terms "terminal equipment," "terminal," "user equipment," and "UE" may be used interchangeably.

[0022] As mentioned above, MBS is proposed. UEs are required to register for the MBS service. As used herein, the term "MBS Radio Bearer (MRB)" can be defined as a radio bearer for carrying multicast and broadcast traffic in point-to-point (PTP) or point-to-multipoint (PTM) modes. Multiple Multimedia Broadcast Multicast Service (MBMS) Control Channels (MCCHs) may be supported. Because 5G networks are expected to provide more diverse types of services with different latency requirements, multiple MCCHs are also considered.

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

[0024] Furthermore, broadcasting should be supported for all RRC states. In 4G systems, group scheduling mechanisms can be enabled for evolved multicast / broadcast multimedia services (eMBMS) and single-cell point-to-multipoint (SC-PTM) using semi-static or dynamic broadcast signaling of control information pointing to semi-static or dynamic shared data channel resources. eMBMS and SC-PTM impose many restrictions on system design, such as support for receive-only UEs, support for devices not registered with the network, and support for devices in idle mode. These restrictions significantly impact how physical channels (using the physical downlink shared channel (PDSCH) or physical multicast channel (PMCH)) are used to transmit multicast data / traffic channel (MTCH) and multicast control channel (MCCH) information. It is important to note that various physical layer scheduling concepts, such as bandwidth portioning, do not exist in LTE, and logical channels such as SCMCCH / MTCH are not defined in 5G / NR, making it impossible to redefine LTE-based multicast broadcast functionality for 5G. In addition, PDCCH scheduling in 5G / NR is also significantly different from that in LTE, making it difficult to use parameters defined in LTE in 5G.

[0025] Downlink Control Information (DCI) formats 1_0, 1_1, and 1_2 are used by the gNB to inform the UE about the PDSCH resources on which downlink data is scheduled. Currently, these formats are defined for unicast traffic, so the gNB will use one of these DCI formats to inform the UE about the PDSCH resources using a UE-specific PDCCH. Until now, it has been agreed that DCI formats 1_0 and 1_1 will be used as the baseline for scheduling PDSCH resources for multicast traffic. Table 1 below shows the variable-sized fields of DCI format 1_1.

[0026] [Table 1]

[0027] The total number of different DCI sizes configured to be monitored is up to four for a cell, and the total number of different DCI sizes with C-RNTIs configured to be monitored is up to three for a cell. Of these three DCI sizes, one size is for downlink allocation scheduling for the non-fallback format (DCI format 1_1), one size is for fallback DCI formats (DCI formats 0_0 and 1_0), and the third size is for uplink scheduling for the non-fallback format (DCI format 0_1). DCI format 0_0 is used for uplink resource allocation (scheduling grant) for the PUSCH. As mentioned above, this is the fallback DCI format. DCI format 0_1 ​​is used for uplink resource allocation (scheduling grant) for the PUSCH. As mentioned above, this is the non-fallback DCI format. The CRC is scrambled by the C-RNTI, CS-RNTI, MCS-C-RNTI, or SP-CSI-RNTI. DCI format 1_0 is used for downlink resource allocation for the PDSCH. As mentioned above, this is a fallback DCI format. The presence and values ​​of specific fields in DCI format 1_0 depend on the type of RNTI with which DCI format 1_0 is scrambled. DCI format 1_1 is used for allocating downlink resources for PDSCH. As mentioned above, this is a non-fallback DCI format. Unlike DCI format 1_0, this DCI format can only address C-RNTI, CS-RNTI, or MCS-C-RNTI. The gNB can preempt an ongoing PDSCH transmission to one UE with a latency-critical transmission to another UE. The gNB can configure UEs to monitor for aborted transmission indications using the INT-RNTI on the PDCCH.When a UE receives a transmission suspension instruction, it can determine that the resource elements included in the instruction do not carry any useful information for the UE, even if some of the resource elements have already been scheduled for this UE. DCI format 2_1 is used to indicate PRBs and OFDM symbols that the UE can determine are not intended for transmission to the UE. DCI format 2_2 is used to transmit TPC commands for PUCCH and PUSCH. DCI format 2_3 is used to transmit TPC command groups for SRS transmission by one or more UEs. Along with TPC commands, SRS requests may also be transmitted within the DCI.

[0028] If higher layer configuration parameters are not adjusted for multicast traffic, this could lead to different UEs receiving the same multicast DCI assuming different DCI sizes. This could result in blind decoding failures. Furthermore, it has been agreed to maintain the existing limits on the DCI size budget for blind decoding. This means that there are a maximum of three different sizes that a gNB can use for CRC-scrambled DCI using the Group Radio Network Temporary Identifier (G-RNTI) if the G-RNTI is counted as a Cell RNTI (C-RNTI), or one size if it is counted as any other RNTI. This imposes a significant restriction on the DCI size that can be allocated to G-RNTI-based DCI.

[0029] As mentioned above, due to the possibility of no coordination of higher layer configuration, different UEs receiving the same MBS service may make different assumptions related to the sizes of various DCI fields. This may be necessary, for example, because UEs may assume different requirements for the number of configured BWPs, priority indication, etc. Therefore, a mechanism is needed to overcome this challenge so that all UEs receiving the same multicast traffic can align their DCI size estimation.

[0030] A new solution for estimating downlink size of multicast traffic is needed. According to an embodiment of the present disclosure, a first device receives DCI for multicast traffic. The first device determines field sizes in the DCI based on one or more parameters related to field size estimation for the multicast traffic. The first device decodes the DCI based on the determined field sizes. In this way, the DCI can be correctly blind decoded.

[0031] 1 is a schematic diagram of a communication environment 100 in which embodiments of the present disclosure may be implemented. Communication environment 100, which is part of a communication network, includes device 110-1, device 110-2, ..., device 110-N, which may be collectively referred to as "first device 110." Communication environment 100 includes second device 120. The number N may be any suitable integer.

[0032] The communication environment 100 may include any suitable number of devices and cells. In the communication environment 100, the first device 110 and the second device 120 may communicate data and control information with each other. If 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 a downlink (DL), and the link from the first device 110 to the second device 120 is referred to as an uplink (UL). The first device 110 may consist of two or more cells.

[0033] It should be understood that the number of first devices and cells and their connections shown in Figure 1 are given for illustrative purposes without implying any limitation, and communication environment 100 may include any suitable number of devices and networks adapted to implement embodiments of the present disclosure.

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

[0035] Exemplary embodiments of the present disclosure are described in detail below with reference to the accompanying drawings. Reference is now made to FIG. 2, which illustrates a signaling flow 200 for determining a field size in a DCI in accordance with an exemplary embodiment of the present disclosure. For illustrative purposes only, signaling flow 200 may include first device 110-1 and second device 120.

[0036] In some demonstrative embodiments, the second device 120 may transmit a first RRC configuration to the first device 110-1 (2010). The first RRC configuration may be used to determine a DCI field size for unicast traffic. For example, DCI formats 1_0, 1_1, and 1_2 may be used by the second device 120 to inform the first device 110-1 about PDSCH resources on which downlink data is scheduled.

[0037] The second device 120 may send 2020 a second RRC configuration for multicast traffic to the first device 110-1. The multicast traffic may be any suitable type of multicast traffic received by a group of users or broadcast traffic that may be received by all users connected to the network.

[0038] The second RRC configuration may include a set of parameters related to field size estimation for multicast traffic. For example, the set of parameters may include a parameter indicating a size of a carrier indicator field in the DCI for multicast traffic. In other words, the carrier indicator field parameter may inform the first device 110-1 about an expected carrier indicator field size for the DCI.

[0039] Alternatively, or in addition, the set of parameters may include a bandwidth fraction indicator field parameter indicating a size of a bandwidth fraction indicator field in the downlink control information, which allows first device 110-1 to determine an expected field size for the bandwidth fraction indicator field.

[0040] In some exemplary embodiments, the set of parameters may include a feedback timing indicator field parameter that indicates the size of a feedback timing indicator field in the downlink control information. For example, the feedback timing indicator may be a PDSCH-to-HARQ_feedback timing indicator. If HARQ ACK / NACK or NACK only is enabled, the size of the feedback timing indicator field, as indicated by the feedback timing indicator field parameter, is the same for terminal devices receiving multicast traffic. However, the terminal devices may need to interpret the feedback timing indicator differently, i.e., the same value of the feedback timing indicator may correspond to different timing. For example, if HARQ ACK / NACK is enabled, the first device 110-1 may need to interpret the signal value of 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 instructing the device on how to interpret the value of the PDSCH-to-HARQ_feedback timing indicator, for example, in a 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.

[0041] In some embodiments, the second device 120 may configure an offset to be applied by the first device 110-1 to the 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 table of PUCCH configurations in the required order.

[0042] In another exemplary embodiment, the set of parameters may include a priority indicator field parameter that indicates the size of the priority indicator field in the downlink control information.

[0043] Further, the set of parameters may include a parameter of an optional setting. The parameter may indicate a size of the optional setting in the downlink control information. The optional setting may include a virtual resource block (VRB) to physical resource block (PRB) mapping. The optional setting may also include a PRB bundle size indicator. In other embodiments, the optional setting may include a rate matching indicator. Alternatively or additionally, the optional setting may include a zero-power channel state information reference signal (ZP CSI-RS) trigger. The optional setting may also include a downlink allocation index. In some exemplary embodiments, the optional setting may include an antenna port and a layer number. In other exemplary embodiments, the optional setting may include a physical downlink shared channel (PDSCH) group index. The optional setting may include a new feedback indicator. Further, the optional setting may include a number of requested PDSCH groups. As an exemplary embodiment, the optional setting may include a sounding reference signal request. Code block group (CBG) transmission information may be included in the optional setting. The optional setting may also include CBG emission information (CBGFI). Alternatively or additionally, the optional setting may include a minimum scheduling offset indicator. In some exemplary embodiments, the optional settings may include a secondary cell dormancy indication. The optional settings may include other settings that are not explicitly required for multicast traffic.

[0044] The set of parameters may include any one or any combination of the parameters described above. The set of parameters may also include other parameters related to estimating the field size in the DCI.

[0045] In some embodiments, the set of parameters may be signaled as part of a PDCCH configuration, e.g., pdcch-config-mbs is based on pdcch-config, which provides UE control resource set parameters and additional parameters required for PDCCH acquisition, as defined in TS 38.331, and provides a common set of DCI field size parameters that need to be applied for DCI CRC-scrambled using G-RNTI. Alternatively, the set of parameters may be signaled as part of a PDSCH configuration, e.g., pdsch-config-mbs is based on pdsch-config, which includes higher layer parameters that the UE uses to estimate portions of 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 for determining the DCI size only for DCI that is scrambled using the 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.

[0046] Alternatively, default values ​​for some or all of the parameters in the set of parameters may be predetermined or configured in the first device 110-1. The first device 110-1 can apply these default values ​​to estimate the DCI size for blind decoding when multicast scheduling parameters such as the G-RNTI, associated search spaces, and DCI formats are configured and the second device 120 does not transmit some or all of the parameters in the set of parameters to the first device. The default values ​​may be specified in a standard specification, hard-coded in the first device, or configured by the second device via a specific configuration message, e.g., a first RRC configuration.

[0047] The second device 120 transmits a DCI for multicasting to the first device 110-1 (2030). 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 DCI. If the DCI format is not a preset format (for example, DCI format 1_0), the first device 110-1 may determine whether a common frequency resource (CFR) is configured. In this case, if a CFR is not configured, the first device 110-1 may determine a frequency domain resource allocation (FDRA) field size based on the active bandwidth portion size. Alternatively, if a CFR is configured, the first device 110-1 may determine the FDRA field size based on the CFR size.

[0048] The first device 110-1 determines one or more field sizes in the DCI based on the set of parameters (2040). As an example embodiment only, the set of parameters may be shown as follows: the carrier indicator field is 3 bits, the bandwidth portion indicator field is 1 bit, the VRB to PRB mapping field is 1 bit, the PRB bundle size indicator field is 0 bit, the rate matching indicator field is 2 bits, the ZP CSI-RS trigger field is 2 bits, the downlink allocation index is 4 bits, the PDSCH-to-HARQ_feedback timing indicator field is 0 bit, the number of antenna ports and layers field is 4 bits, the transmission configuration indication field is 3 bits, the CBGTI field is 6 bits, and the CBGFI field is 1 bit. In this manner, the field sizes of the DCI can be correctly determined, and failures in decoding the DCI can be avoided.

[0049] In some embodiments, if the first device 110-1 does not receive a second RRC configuration for multicast traffic from the second device 120, the first device 110-1 may determine whether a set of parameters is predetermined and configured in the first device 110-1. If a set of parameters is predetermined and configured in the first device 110-1, the first device 110-1 may determine one or more field sizes based on the set of predetermined and configured parameters.

[0050] Alternatively, the second RRC configuration for multicast traffic may include a subset of the set of parameters. The remaining parameters of the set of parameters may have default values ​​in the first device 110-1. In other words, the remaining parameters may be predefined, and the second RRC configuration need not retain 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 parameters and the default values ​​of the remaining parameters. In this manner, signaling can be reduced. By way of example only, the second RRC configuration for multicast traffic may indicate that the carrier indicator field is 3 bits, the bandwidth fraction indicator field is 1 bit, the VRB to PRB mapping field is 1 bit, and the PRB bundle size indicator field is 0 bit. The remaining parameters are default values, e.g., the rate matching indicator field is set to 0 bits, the ZP CSI-RS trigger 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 antenna port(s) and layer number field is set to 4 bits, the transmission configuration indication field is set to 0 bits, the CBGTI field is set to 0 bits, and the CBGFI field is set to 0 bits. Thus, the first device 110-1 can determine the field sizes of the carrier indicator field, the bandwidth fraction indicator field, the VRB to PRB mapping field, and the bandwidth fraction indicator field based on a first subset of parameters in the second RRC configuration, and can determine the field sizes of the other fields based on a second subset of parameters having default values. Default values ​​for some or all of the parameters can be sent in an RRC configuration common to all UEs receiving the multicast or broadcast service.This can be achieved by defining a specific Radio Network Temporary Identifier for signaling default values ​​from the second device to the first device. Alternatively, default values ​​for some or all parameters can be sent individually to each UE, e.g., via a first RRC configuration, along with an indication that the parameters only apply to reception of multicast or broadcast traffic where the CRC of the DCI is scrambled using the G-RNTI.

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

[0052] 3 shows a flowchart of an example method 300 according to some example embodiments of the present disclosure. For purposes of explanation, the method 300 will be described from the perspective of a first device. For purposes of illustration only, the method 300 will be described with reference to the first device 110-1.

[0053] In some demonstrative embodiments, first device 110-1 may receive a first RRC configuration from second device 120. The first RRC configuration may be used to determine a DCI field size for unicast traffic. For example, DCI formats 1_0, 1_1, and 1_2 may be used by second device 120 to inform first device 110-1 about PDSCH resources on which downlink data is scheduled.

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

[0055] The second RRC configuration may include a set of parameters related to field size estimation for multicast traffic. For example, the set of parameters may include a carrier indicator field parameter indicating a size of a carrier indicator field in the DCI for the multicast traffic. In other words, the carrier indicator field parameter may inform the first device 110-1 about an expected carrier indicator field size for the DCI.

[0056] Alternatively, or in addition, the set of parameters may include a bandwidth fraction indicator field parameter indicating a size of a bandwidth fraction indicator field in the downlink control information, which allows first device 110-1 to determine an expected field size for the bandwidth fraction indicator field.

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

[0058] 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 the offset. For example, the first device 110-1 would 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 table of PUCCH configurations in the required order.

[0059] In another exemplary embodiment, the set of parameters may include a priority indicator field parameter that indicates the size of the priority indicator field in the downlink control information.

[0060] Further, the set of parameters may include a parameter of an optional setting. The parameter may indicate the size of the optional setting in the downlink control information. The optional setting may include a virtual resource block (VRB) to physical resource block (PRB) mapping. The optional setting may also include a PRB bundle size indicator. In other embodiments, the optional setting may include a rate matching indicator. Alternatively or additionally, the optional setting may include a zero-power channel state information reference signal (ZP CSI-RS) trigger. The optional setting may also include a downlink allocation index. In some exemplary embodiments, the optional setting may include an antenna port and layer number. In other exemplary embodiments, the optional setting may include a physical downlink shared channel (PDSCH) group index. The optional setting may include a new feedback indicator. Further, the optional setting may include the number of requested PDSCH groups. As an exemplary embodiment, the optional setting may include a sounding reference signal request. Code block group (CBG) transmission information may be included in the optional setting. The optional setting may also include CBG emission information (CBGFI). Alternatively or additionally, the optional setting may include a minimum scheduling offset indicator. In some exemplary embodiments, the optional settings may include secondary cell dormancy notification. The optional settings may include other settings that are not explicitly required for multicast traffic.

[0061] The set of parameters may include any one or any combination of the parameters described above. The set of parameters may also include other parameters related to estimating the field size in the DCI.

[0062] In some embodiments, the set of parameters may be signaled as part of a PDCCH configuration, e.g., pdcch-config-mbs is based on pdcch-config, which provides UE control resource set parameters and additional parameters required for PDCCH acquisition, as defined in TS 38.331, and provides a common set of DCI field size parameters that need to be applied for DCI CRC-scrambled using G-RNTI. Alternatively, the set of parameters may be signaled as part of a PDSCH configuration, e.g., pdsch-config-mbs is based on pdsch-config, which includes higher layer parameters that a UE uses to estimate portions of 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 for determining the DCI size only for DCI that is scrambled using the 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.

[0063] Alternatively, default values ​​for some or all of the parameters in the set of parameters may be predetermined or configured in the first device 110-1. The first device 110-1 can apply these default values ​​to estimate the DCI size for blind decoding when multicast scheduling parameters such as the G-RNTI, associated search spaces, and DCI formats are configured and the second device 120 does not transmit some or all of the parameters in the set of parameters to the first device. The default values ​​may be specified in a standard specification, hard-coded in the first device, or configured by the second device via a specific configuration message, e.g., a first RRC configuration.

[0064] In block 310, the first device 110-1 receives a DCI for multicasting from the 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 DCI. If the DCI format is not a preset format (for example, DCI format 1_0), the first device 110-1 may determine whether a common frequency resource (CFR) is configured. In this case, if a CFR is not configured, the first device 110-1 may determine a frequency domain resource allocation (FDRA) field size based on the active bandwidth portion size. Alternatively, if a CFR is configured, the first device 110-1 may determine the FDRA field size based on the CFR size.

[0065] In block 320, the first device 110-1 determines the size of one or more fields in the DCI based on the set of parameters. By way of example only, the set of parameters may indicate the following: a carrier indicator field of 3 bits, a bandwidth fraction indicator field of 1 bit, a VRB to PRB mapping field of 1 bit, a PRB bundle size indicator field of 0 bit, a rate matching indicator field of 2 bits, a ZP CSI-RS trigger field of 2 bits, a downlink allocation index of 4 bits, a PDSCH-to-HARQ_feedback timing indicator field of 0 bit, a number of antenna ports and layers field of 4 bits, a transmission configuration indication field of 3 bits, a CBGTI field of 6 bits, and a CBGFI field of 1 bit. In this manner, the field sizes of the DCI can be correctly determined, and failures in decoding the DCI can be avoided.

[0066] In some embodiments, if the first device 110-1 does not receive a second RRC configuration for multicast traffic from the second device 120, the first device 110-1 may determine whether a set of parameters is predetermined and configured in the first device 110-1. If a set of parameters is predetermined and configured in the first device 110-1, the first device 110-1 may determine one or more field sizes based on the set of predetermined and configured parameters.

[0067] Alternatively, the second RRC configuration for multicast traffic may include a subset of the set of parameters. The remaining parameters of the set of parameters may have default values ​​in the first device 110-1. In other words, the remaining parameters may be predefined, and the second RRC configuration need not retain 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 parameters and the default values ​​of the remaining parameters. In this manner, signaling can be reduced. By way of example only, a second RRC configuration for multicast traffic may be represented as follows, where the carrier indicator field is 3 bits, the bandwidth fraction indicator field is 1 bit, the VRB to PRB mapping field is 1 bit, the PRB bundle size indicator field is 0 bit, and the remaining parameters are default values, e.g., the rate matching indicator field is set to 0 bit, the ZP CSI-RS trigger field is set to 0 bit, the downlink allocation index is set to 0 bit, the PDSCH-to-HARQ_feedback timing indicator field is set to 0 bit, the number of antenna ports and layers field is 4 bits, the transmission configuration indication field is set to 0 bit, the CBGTI field is set to 0 bit, and the CBGFI field is set to 0 bit. Thus, the first device 110-1 may determine the field sizes of the carrier indicator field, the bandwidth fraction indicator field, the VRB to PRB mapping field, and the bandwidth fraction indicator field based on a first subset of parameters of the second RRC configuration, and may determine the field sizes of the other fields based on a second subset of parameters having default values. Default values ​​for some or all parameters may be sent in an RRC configuration that is common to all UEs receiving the multicast or broadcast service.This can be achieved by defining a specific Radio Network Temporary Identifier for signaling default values ​​from the second device to the first device. Alternatively, default values ​​for some or all parameters can be sent individually to each UE, e.g., via a first RRC configuration, along with an indication that the parameters only apply to reception of multicast or broadcast traffic where the CRC of the DCI is scrambled using the G-RNTI.

[0068] 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 can determine the size of a field in the DCI based on a set of parameters. The first device 110-1 knows the field size and can therefore correctly decode the DCI. If multicast scheduling parameters, such as a G-RNTI, an associated search space, and a DCI format, are configured, the first device 110-1 can apply a set of parameters received from the second device 120 or configured by the first device 110-1 for blind decoding. In this way, the efficiency of blind decoding is improved.

[0069] Exemplary embodiments for estimating field sizes in DCI are described with reference to Figures 4 and 5. Figure 4 shows a flowchart of an exemplary method 400 according to some exemplary embodiments of the present disclosure. For illustrative purposes, method 400 is described from the perspective of a first device. For illustrative purposes only, method 400 is described with reference to first device 110-1.

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

[0071] In block 420, first device 110-1 may determine whether the DCI format is other than DCI format 1_0. If the DCI format is DCI format 1_0, the DCI has only limited variable-size fields and method 400 may be stopped.

[0072] If the DCI format is not DCI format 1_0, the first device 110-1 may determine whether the CFR is set in block 430. The CFR may affect the FDRA field size determination. If the CFR is set, the first device 110-1 may determine the FDRA field size based on the CFR size in block 440.

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

[0074] If the set of parameters is configured, in block 470, the first device 110-1 may determine one or more field sizes based on the set of parameters. The first device 110-1 may perform blind encoding 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 for blind decoding on the search space / control channel element related to multicast traffic. If the set of parameters is not configured, in block 480, the first device 110-1 may determine one or more field sizes based on currently used RRC parameters (e.g., the first RRC configuration mentioned in FIG. 2). As used herein, the term “control channel element (CCE)” may refer to a resource element group (REG), where a resource element group is equal to one resource block in one OFDM symbol. As used herein, the term “search space” may refer to an area in a downlink resource grid in which the PDCCH may be carried. A search space can be denoted by a set of contiguous control channel elements (CCEs) that a UE is to monitor for scheduling assignments / grant related to a particular component carrier. For example, there are two types of search spaces used to control each component carrier in the NR-PDCCH: Common Search Space (CSS) and UE-Specific Search Space (USS).For CSS, the DCI cyclic redundancy check (CRC) may be scrambled with the System Information RNTI (SI-RNTI), Random Access RNTI (RA-RNTI), Temp Cell RNTI (TC-RNTI), Paging RNTI (P-RNTI), Interrupt RNTI (INT-RNTI), Slot Format Indicator RNTI (SFI-RNTI), Transmit Power Control (TPC)-PUCCH-RNTI, TPC-PUSCH-RNTI, TPC-SRS-RNTI, Cell RNTI (C-RNTI), and Configured Scheduling RNTI (CS-RNTI). For USS, the DCI CRC may be scrambled with the C-RNTI and CS-RNTI, which are specifically targeted to an individual UE. The CSS is shared by all UEs, while the USS is per UE (i.e., this SS is specific to the UE).

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

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

[0077] In block 520, first device 110-1 may determine whether the DCI format is other than DCI format 1_0. If the DCI format is DCI format 1_0, the DCI has only limited variable-size fields and method 500 is stopped.

[0078] If the DCI format is not DCI format 1_0, the first device 110-1 may determine whether the CFR is set in block 530. The CFR may affect the determination of the FDRA field size. If the CFR is set, the first device 110-1 may determine the FDRA field size based on the CFR size in block 540.

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

[0080] If the set of parameters is set, first device 110-1 may determine one or more field sizes based on the set of parameters in block 570. First device 110-1 may perform blind coding for an appropriate search space based on the one or more field sizes.

[0081] If the set of parameters is not configured, the first device 110-1 may determine whether default values ​​of the parameters for field size estimation are defined in block 580. In other words, the first device 110-1 may determine whether default values ​​of the set of parameters are configured in the first device 110-1. If default values ​​are not defined, the first device 110-1 may determine one or more field sizes based on currently used RRC parameters (e.g., the first RRC configuration referred to in FIG. 2) in block 585.

[0082] If default values ​​are defined, then in block 590, the first device 110-1 may determine one or more field sizes based on the default values. In some embodiments, the default values ​​may be predetermined. The second RRC configuration needs to be transmitted only if the field sizes differ from the default values. The pdcch / pdsch-config-mbs configuration signaling may include an indicator (which may be the name of a variable-size DCI field) indicating a different set of field sizes that should be applied to the DCI size estimation. In this way, signaling from the network can be reduced because these values ​​only need to be transmitted to the first device 110-1 if they differ from the default values.

[0083] 6 illustrates a flowchart of an example method 600 according to some example embodiments of the present disclosure. For purposes of explanation, the method 600 is described from the perspective of a second device. For purposes of illustration only, the second device may be the second device 120.

[0084] In block 610, the second device 120 sends the RRC configuration for multicast traffic to the first device 110-1. The multicast traffic may be any suitable type of multicast traffic received by a group of users or broadcast traffic that may be received by all users connected to the network.

[0085] The RRC configuration may include a set of parameters related to field size estimation for multicast traffic. For example, the set of parameters may include a carrier indicator field parameter indicating a size of a carrier indicator field in the DCI for multicast traffic. In other words, the carrier indicator field parameter may inform the first device 110-1 about an expected carrier indicator field size for the DCI.

[0086] Alternatively, or in addition, the set of parameters may include a bandwidth fraction indicator field parameter indicating a size of a bandwidth fraction indicator field in the downlink control information, which allows first device 110-1 to determine an expected field size for the bandwidth fraction indicator field.

[0087] In some exemplary embodiments, the set of parameters may include a feedback timing indicator parameter that indicates the size of a feedback timing indicator field in the downlink control information. For example, the feedback timing indicator may be a PDSCH-to-HARQ_feedback timing indicator. If HARQ ACK / NACK or NACK only is enabled, the size of the feedback timing indicator field, as indicated by the feedback timing indicator field parameter, is the same for terminal devices receiving multicast traffic. However, the terminal devices may need to interpret the feedback timing indicator differently, i.e., the same value of the feedback timing indicator may correspond to different timing. For example, if HARQ ACK / NACK is enabled, the first device 110-1 may need to interpret the signal value of the PDSCH-to-HARQ_feedback timing indicator field differently from other first devices (e.g., device 110-2). In this case, the first device 110-1 needs to receive a configuration, e.g., in the first RRC configuration 2010, that instructs the device on how to interpret the value of the PDSCH-to-HARQ_feedback timing indicator. The first device 110-1 may combine the configuration received using the first RRC configuration with the common configuration received using the second RRC configuration to derive a unique HARQ ACK / NACK feedback resource.

[0088] In some embodiments, the second device 120 may configure the offset applied by the first device 110-1 to the G-RNTI scrambling DCI. Alternatively, the second device 120 may configure a table of PUCCH configurations in the required order.

[0089] In another exemplary embodiment, the set of parameters may include a priority indicator field parameter that indicates the size of the priority indicator field in the downlink control information.

[0090] Further, the set of parameters may include a parameter of an optional setting. The parameter may indicate the size of the optional setting in the downlink control information. The optional setting may include a virtual resource block (VRB) to physical resource block (PRB) mapping. The optional setting may also include a PRB bundle size indicator. In other embodiments, the optional setting may include a rate matching indicator. Alternatively or additionally, the optional setting may include a zero-power channel state information reference signal (ZP CSI-RS) trigger. The optional setting may also include a downlink allocation index. In some exemplary embodiments, the optional setting may include an antenna port and layer number. In other exemplary embodiments, the optional setting may include a physical downlink shared channel (PDSCH) group index. The optional setting may include a new feedback indicator. Further, the optional setting may include the number of requested PDSCH groups. As an exemplary embodiment, the optional setting may include a sounding reference signal request. Code block group (CBG) transmission information may be included in the optional setting. The optional setting may also include CBG emission information (CBGFI). Alternatively or additionally, the optional setting may include a minimum scheduling offset indicator. In some exemplary embodiments, the optional settings may include secondary cell dormancy notification. The optional settings may include other settings that are not explicitly required for multicast traffic.

[0091] The set of parameters may include any one or any combination of the parameters described above. The set of parameters may also include other parameters related to estimating the field size in the DCI.

[0092] In some embodiments, the set of parameters can be signaled as part of a PDCCH configuration, e.g., pdcch-config-mbs is based on pdcch-config, which provides UE control resource set parameters and additional parameters required for acquiring the PDCCH, as defined in TS 38.331, and provides a common set of DCI field size parameters that need to be applied to CRC-scrambled DCI using the G-RNTI. Alternatively, the set of parameters can be signaled as part of a PDSCH configuration, e.g., pdsch-config-mbs is based on pdsch-config, which includes higher layer parameters that the UE uses to estimate portions of variable-size DCI fields, as defined in TS 38.331. The PDCCH configuration / PDSCH configuration can be transmitted as part of a second RRC configuration. The second RRC configuration can be a group-common RRC message. For example, the second RRC configuration can be signaled using a group-common RNTI. Alternatively, the second RRC configuration may be a UE-specific RRC message, and the first device 110-1 may apply the second RRC configuration for determining the DCI size only for DCI that is scrambled using the 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.

[0093] Alternatively, default values ​​for some or all of the parameters in the set of parameters may be predetermined or configured in the first device 110-1. The first device 110-1 can apply these default values ​​to estimate the DCI size for blind decoding when multicast scheduling parameters such as the G-RNTI, associated search spaces, and DCI formats are configured and the second device 120 does not transmit some or all of the parameters in the set of parameters to the first device. The default values ​​may be specified in a standard specification, hard-coded in the first device, or configured by the second device via a specific configuration message, e.g., a first RRC configuration.

[0094] Alternatively, the second RRC configuration for multicast traffic may include a subset of the set of parameters. The remaining parameters of the set of parameters may have default values ​​in the first device 110-1. In other words, the remaining parameters may be predefined, and the second RRC configuration need not retain 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 parameters and the default values ​​of the remaining parameters. In this manner, signaling can be reduced. By way of example only, the second RRC configuration for multicast traffic may indicate that the carrier indicator field is 3 bits, the bandwidth fraction indicator field is 1 bit, the VRB to PRB mapping field is 1 bit, and the PRB bundle size indicator field is 0 bit. The remaining parameters are default values, e.g., the Rate Matching Indicator field is set to 0, the ZP CSI-RS Trigger field is set to 0, the Downlink Allocation Index is set to 0, the PDSCH-to-HARQ_Feedback Timing Indicator field is set to 0, the Number of Antenna Ports and Layers field is set to 4, the Transmission Configuration Indicator field is set to 0, the CBGTI field is set to 0, and the CBGFI field is set to 0. The default values ​​for some or all of the parameters may be transmitted in a common RRC configuration for all UEs receiving the multicast or broadcast service. This can be achieved by defining a specific Radio Network Temporary Identifier for signaling the default values ​​from the second device to the first device. Alternatively, the default values ​​for some or all of the parameters may be transmitted individually to each UE via, e.g., the first RRC configuration, along with an indication that the parameters apply only to receiving multicast or broadcast traffic in which the CRC of the DCI is scrambled using the G-RNTI.

[0095] In block 620, the second device 120 transmits a DCI for multicasting 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 variable-size field. In some embodiments, the first device 110-1 may determine the DCI format of the DCI. If the DCI format is not a preset format (for example, DCI format 1_0), the first device 110-1 may determine whether a common frequency resource (CFR) is configured. In this case, if a CFR is not configured, the first device 110-1 may determine a frequency domain resource allocation (FDRA) field size based on the active bandwidth portion size. Alternatively, if a CFR is configured, the first device 110-1 may determine the FDRA field size based on the CFR size.

[0096] In some exemplary embodiments, an apparatus (e.g., first device 110) capable of performing method 300 may comprise means for performing each operation of method 300. The means may be implemented in any suitable form. For example, the means may be implemented in a circuit or a software module. The apparatus may be implemented as or included in first device 110. In some exemplary embodiments, the means may comprise at least one processor and at least one memory containing computer program code. The at least one memory and the computer program code, in conjunction with the at least one processor, are configured to perform the performance of the apparatus.

[0097] In some demonstrative embodiments, the apparatus comprises means for receiving, at a first device and from a second device, downlink control information for multicast traffic; means for determining, at the first device, one or more field sizes in the downlink control information based on a set of parameters related to field size estimation for the multicast traffic; and means for decoding the downlink control information based on the determined one or more field sizes.

[0098] In some exemplary embodiments, the set of parameters includes at least one of a carrier indicator field parameter indicating a size of a carrier indicator field in the downlink control information, a bandwidth portion indicator parameter indicating a size of a bandwidth portion indicator field in the downlink control information, a feedback timing indicator parameter indicating a size of a feedback timing indication field in the downlink control information, a priority indicator field parameter indicating a size of a priority indicator field in the downlink control information, or an option settings parameter indicating a size of an option settings field in the downlink control information.

[0099] In some exemplary embodiments, the option settings include at least one of a virtual resource block to physical resource block mapping, a physical resource block bundle size indicator, a rate matching indicator, a zero power channel state information reference signal, a downlink allocation index, an antenna port and layer number, a physical downlink shared channel (PDSCH) group index, a new feedback indicator, a requested number of PDSCH groups, a sounding reference signal request, code block group transmission information, code block group emission information, a minimum scheduling offset indicator, or a secondary cell dormancy notification.

[0100] In some exemplary embodiments, the apparatus further comprises means for receiving, from the second device, a radio resource control configuration for multicast traffic. In some exemplary embodiments, the means for determining one or more field sizes comprises means for determining, based on the set of parameters in the radio resource control configuration, in accordance with a determination that the radio resource control configuration includes the set of parameters.

[0101] In some exemplary embodiments, the apparatus further comprises means for determining, in accordance with a determination that a radio resource control configuration for multicast traffic does not exist, whether a set of parameters is predetermined and configured at the first device. In some exemplary embodiments, the means for determining one or more field sizes includes, in accordance with a determination that the set of parameters is predetermined and configured at the first device, determining the one or more field sizes based on the set of predetermined and configured parameters.

[0102] In some exemplary embodiments, the apparatus further comprises means for receiving, from the second device, a radio resource control configuration for multicast traffic including a first subset of parameters. In some exemplary embodiments, the means for determining one or more field sizes includes determining the 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.

[0103] In some demonstrative embodiments, the apparatus further comprises means for determining a format of the downlink control information; means for determining whether common frequency resources are configured in accordance with a determination that the format is not a preset format; means for determining a frequency domain resource allocation field size based on an active bandwidth portion size in accordance with a determination that the common frequency resources are not configured; and means for determining a frequency domain resource allocation field size based on a common frequency resource size in accordance with a determination that the common frequency resources are configured.

[0104] In some exemplary embodiments, the apparatus further comprises means for applying the determined one or more field sizes for blind decoding on a search space associated with multicast traffic.

[0105] In some exemplary embodiments, an apparatus capable of performing method 600 (e.g., second device 120) may comprise means for performing each operation of method 600. The means may be implemented in any suitable form. For example, the means may be implemented in a circuit or a software module. The apparatus may be implemented as or included in second device 120. In some exemplary embodiments, the means may comprise at least one processor and at least one memory containing computer program code. The at least one memory and the computer program code are configured to cause the at least one processor to perform the performance of the apparatus.

[0106] In some exemplary embodiments, the apparatus comprises: means, at the second device, for transmitting a radio resource control configuration for multicast traffic to the first device, the radio resource control configuration including a set of parameters related to field size estimation for the multicast traffic; and means for transmitting downlink control information for the multicast traffic to the first device.

[0107] In some example embodiments, the set of parameters includes at least one of: a carrier indicator field parameter indicating a size of a carrier indicator field in the downlink control information; a bandwidth portion indicator parameter indicating a size of a bandwidth portion indicator field in the downlink control information; a feedback timing indicator parameter indicating a size of a feedback timing indicator field in the downlink control information; a priority indicator field parameter indicating a size of a priority indicator field in the downlink control information; or an option settings parameter indicating a size of an option settings field in the downlink control information.

[0108] In some exemplary embodiments, the option settings include at least one of a virtual resource block to physical resource block mapping, a physical resource block bundle size indicator, a rate matching indicator, a zero power channel state information reference signal, a downlink allocation index, an antenna port and layer number, a physical downlink shared channel (PDSCH) group index, a new feedback indicator, a requested number of PDSCH groups, a sounding reference signal request, code block group transmission information, code block group emission information, a minimum scheduling offset indicator, or a secondary cell dormancy notification.

[0109] 7 is a simplified block diagram of a device 700 suitable for practicing an exemplary embodiment of the present disclosure. Device 700 may be provided to implement a communications device such as first device 110 or second device 120 as shown in FIG. 1. As shown, device 700 includes one or more processors 710, one or more memories 720 coupled to processors 710, and one or more communications modules 740 coupled to processors 710.

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

[0111] The processor 710 may be of any type suitable for a local technology network and may comprise, by way of non-limiting example, one or more of 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 comprise multiple processors, such as application-specific integrated circuit chips that are time-slaved to a clock that synchronizes a main processor.

[0112] The memory 720 may include one or more nonvolatile memories and one or more volatile memories. Examples of nonvolatile memory include, but are not limited to, read-only memory (ROM) 724, electrically programmable read-only memory (EPROM), flash memory, hard disks, compact disks (CDs), digital video disks (DVDs), optical disks, laser disks, and other magnetic and / or optical storage devices. Examples of volatile memory include, but are not limited to, random access memory (RAM) 722 and other volatile memories that do not stay up to date during power-down periods.

[0113] 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, for example, the ROM 724. The processor 710 can load the program 730 into the RAM 722 to perform any suitable operations and processes.

[0114] An exemplary embodiment of the present disclosure may be implemented by a program 730 such that the device 700 may execute any process of the present disclosure, as described with reference to Figures 2 to 6. An exemplary embodiment of the present disclosure may also be implemented by hardware or a combination of software and hardware.

[0115] In some exemplary embodiments, the program 730 may be tangibly contained in a computer-readable medium, which may be included in the device 700 (such as in memory 720) or other storage device accessible by the device 700. The device 700 may load the program 730 from the computer-readable medium into RAM 722 for execution. The computer-readable medium may include any type of tangible non-volatile storage device, such as ROM, EPROM, flash memory, hard disks, CDs, DVDs, and other magnetic and / or optical storage devices. Figure 8 shows an example of a computer-readable medium 800 in the form of an optical storage disk. The computer-readable medium has the program 730 stored thereon.

[0116] In general, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic, or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software that may be executed by a controller, microprocessor, or other computing device. While various aspects of embodiments of the present disclosure are illustrated and described using block diagrams, flowcharts, or some other graphical representations, it should be understood that the blocks, apparatus, systems, techniques, or methods described herein may be implemented in, by way of non-limiting example, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller, or other computing device, or some combination thereof.

[0117] 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 those included in program modules, that execute on a target physical or virtual processor device to perform any of the methods described above with reference to FIGS. 2 through 6. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split among program modules as desired in various embodiments. The machine-executable instructions of the program modules may be executed in local or distributed devices. In distributed devices, the program modules may be located in both local and remote storage media.

[0118] Program code for implementing 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 apparatus, such that when the program code is executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are performed. The program code may run 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.

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

[0120] The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. The computer-readable medium includes, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer-readable storage medium include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), 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.

[0121] Furthermore, while operations are depicted in a particular order, this should not be understood as requiring such operations to be performed in the particular order shown, or sequentially, or that all of the operations depicted be performed, to achieve desirable results. In certain situations, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above description, these should not be construed as limiting 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 can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination.

[0122] Although the present disclosure has been described in language specific to structural features and / or methodological acts, it is to be understood that the present disclosure, as defined by the appended claims, 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 claims.

Claims

1. A first device for communication, at least one processor; at least one memory containing computer program code; The at least one memory and the computer program code are transmitted by the at least one processor to the first device: receiving a radio resource control configuration for multicast traffic from a second device, the radio resource control configuration including a set of parameters related to a field size estimation of downlink control information for the multicast traffic; receiving the downlink control information for multicast traffic from the second device; determining, at the first device, a field size of one or more fields in the downlink control information based on the set of parameters; decoding the downlink control information based on the determined one or more field sizes; configured to cause the The set of parameters is: a carrier indicator field parameter indicating a size of a carrier indicator field in the downlink control information; a feedback timing indicator parameter indicating a 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 option setting parameter indicating the size of an option setting field in the downlink control information; at least one of: First device.

2. The option settings are: a mapping of virtual resource blocks to physical resource blocks; Physical resource block bundle size indicator, rate matching indicator, Zero power channel state information reference signal; Downlink allocation index, Number of antenna ports and layers, Physical downlink shared channel PDSCH group index, New feedback indicators, the number of requested PDSCH groups, Sounding reference signal request, Code block group transmission information, Code block group emission information, a minimum scheduling offset indicator, or Secondary cell dormancy notification, The first device of claim 1 , comprising at least one of:

3. The at least one memory and the computer program code are transmitted by the at least one processor to the first device, further comprising: and configured to cause, in accordance with a determination that a radio resource control configuration for the multicast traffic does not exist, determining whether the set of parameters is predetermined and configured in the first device; The at least one memory and the computer program code are transmitted by the at least one processor to the first device, further comprising: determining the one or more field sizes based on the predetermined and configured set of parameters in accordance with a determination that the set of parameters is predetermined and configured at the first device; configured to cause the one or more field sizes to be determined; The first device of claim 1 .

4. The at least one memory and the computer program code are transmitted by the at least one processor to the first device, further comprising: receiving, from the second device, a radio resource control configuration for the multicast traffic, the radio resource control configuration comprising the first subset of parameters; The at least one memory and the computer program code are transmitted by the at least one processor to the first device, further comprising: determining the 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; configured to cause the one or more field sizes to be determined; The first device of claim 1 .

5. The at least one memory and the computer program code are transmitted by the at least one processor to the first device, further comprising: determining a format of the downlink control information; determining whether a common frequency resource is configured according to a determination that the format is not a preset format; determining a frequency domain resource allocation field size based on an active bandwidth portion size in accordance with determining that the common frequency resource is not configured; or and determining a frequency domain resource allocation field size based on a common frequency resource size in accordance with the determination that the common frequency resource is configured. The first device of claim 1 configured to:

6. The at least one memory and the computer program code are transmitted by the at least one processor to the first device, further comprising: applying the determined one or more field sizes to blind decoding on a search space associated with the multicast traffic. The first device of claim 1 configured to:

7. A second device for communication, at least one processor; at least one memory containing computer program code; The at least one memory and the computer program code are configured to be executed by the at least one processor to: transmitting, to a first device, a radio resource control configuration for multicast traffic, the radio resource control configuration including a set of parameters related to field size estimation in downlink control information of the multicast traffic; transmitting the downlink control information for the multicast traffic to the first device; and causing the second device to execute The set of parameters is: a carrier indicator field parameter indicating a size of a carrier indicator field in the downlink control information; a feedback timing indicator parameter indicating a 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 option setting parameter indicating the size of an option setting field in the downlink control information; at least one of: Secondary device.

8. The option settings are: a mapping of virtual resource blocks to physical resource blocks; Physical resource block bundle size indicator, rate matching indicator, Zero power channel state information reference signal; Downlink allocation index, Number of antenna ports and layers, Physical downlink shared channel PDSCH group index, New feedback indicators, the number of requested PDSCH groups, Sounding reference signal request, Code block group transmission information, Code block group emission information, a minimum scheduling offset indicator, or Secondary cell dormancy notification, The second device of claim 7 , comprising at least one of:

9. A method for receiving, from a second device, a radio resource control configuration for multicast traffic, the radio resource control configuration including a set of parameters related to field size estimation of downlink control information for the multicast traffic; receiving, at a first device, the downlink control information for multicast traffic from the second device; determining, at the first device, a field size of one or more fields in the downlink control information based on the set of parameters; decoding the downlink control information based on the determined one or more field sizes; This includes: The set of parameters is: a carrier indicator field parameter indicating a size of a carrier indicator field in the downlink control information; a feedback timing indicator parameter indicating a 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 option setting parameter indicating a size of an option setting field in the downlink control information; at least one of: method.

10. The option settings are: a mapping of virtual resource blocks to physical resource blocks; Physical resource block bundle size indicator, rate matching indicator, Zero power channel state information reference signal; Downlink allocation index, Number of antenna ports and layers, Physical downlink shared channel PDSCH group index, New feedback indicators, the number of requested PDSCH groups, Sounding reference signal request, Code block group transmission information, Code block group emission information, a minimum scheduling offset indicator, or Secondary cell dormancy notification, The method of claim 9 , comprising at least one of:

11. and determining whether the set of parameters is predetermined and configured in the first device according to a determination that no radio resource control configuration for the multicast traffic exists; determining the one or more field sizes determining the one or more field sizes based on the predetermined and configured set of parameters in accordance with a determination that the set of parameters is predetermined and configured at the first device; 10. The method of claim 9, comprising:

12. receiving, from the second device, a radio resource control configuration for the multicast traffic, the radio resource control configuration including the first subset of parameters; determining the one or more field sizes determining the 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; 10. The method of claim 9, comprising:

13. determining a format of the downlink control information; determining whether a common frequency resource is configured according to a determination that the format is not a preset format; determining a frequency domain resource allocation field size based on an active bandwidth portion size in accordance with determining that the common frequency resource is not configured; or and determining a frequency domain resource allocation field size based on a common frequency resource size in accordance with the determination that the common frequency resource is configured. The method of claim 9 further comprising:

14. applying the determined one or more field sizes to blind decoding on a search space associated with the multicast traffic; 10. The method of claim 9, further comprising:

15. transmitting, at a second device, a radio resource control configuration for multicast traffic to a first device, the radio resource control configuration including a set of parameters related to field size estimation in downlink control information of the multicast traffic; transmitting the downlink control information for the multicast traffic to the first device; Including, The set of parameters is: a carrier indicator field parameter indicating a size of a carrier indicator field in the downlink control information; a feedback timing indicator parameter indicating a 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 option setting parameter indicating the size of an option setting field in the downlink control information; at least one of: method.

16. The option settings are: a mapping of virtual resource blocks to physical resource blocks; Physical resource block bundle size indicator, rate matching indicator, Zero power channel state information reference signal; Downlink allocation index, Number of antenna ports and layers, Physical downlink shared channel PDSCH group index, New feedback indicators, the number of requested PDSCH groups, Sounding reference signal request, Code block group transmission information, Code block group emission information, a minimum scheduling offset indicator, or Secondary cell dormancy notification, The method of claim 15 , comprising at least one of:

17. When executed by a first device, the first device receiving a radio resource control configuration for multicast traffic from a second device, the radio resource control configuration including a set of parameters related to a field size estimation of downlink control information for the multicast traffic; receiving, at the first device, the downlink control information for multicast traffic from the second device; determining, at the first device, a field size of one or more fields in the downlink control information based on the set of parameters; decoding the downlink control information based on the determined one or more field sizes; and program instructions for causing the The set of parameters is: a carrier indicator field parameter indicating a size of a carrier indicator field in the downlink control information; a feedback timing indicator parameter indicating a 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 option setting parameter indicating the size of an option setting field in the downlink control information; at least one of: Computer-readable medium.

18. When executed by a second device, the second device: transmitting, at the second device, to a first device, a radio resource control configuration for multicast traffic, the radio resource control configuration including a set of parameters related to field size estimation in downlink control information of the multicast traffic; transmitting the downlink control information for the multicast traffic to the first device; comprising program instructions for causing the The set of parameters is: a carrier indicator field parameter indicating a size of a carrier indicator field in the downlink control information; a feedback timing indicator parameter indicating a 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 option setting parameter indicating the size of an option setting field in the downlink control information; at least one of: Computer-readable medium.

Images