locationList provided in

PDSCH-ConfigCommon

P-RNTI
Type2 common
1
No
—
Default A

2
No
—
Default B

3
No
—
Default C

1, 2, 3
Yes
—
pdsch-TimeDomainAl-

locationList provided in

PDSCH-ConfigCommon

G-RNTI,
Type X common
1
No
—
Default A

GS-RNTI

2
No
—
Default B

(Option-1)

3
No
—
Default C

1, 2, 3
?
=
pdsch-TimeDomainAl-

locationList provided in

?????

C-RNTI,
Any common
1, 2, 3
No
—
Default A

MCS-C-
search space
1, 2, 3
Yes
—
pdsch-TimeDomainAl-

RNTI,
associated with

locationList provided in

CS-RNTI
CORESET 0

PDSCH-ConfigCommon

C-RNTI,
Any common
1, 2, 3
No
No
Default A

MCS-C-
search space not
1, 2, 3
Yes
No
pdsch-TimeDomainAl-

RNTI,
associated with

locationList provided in

CS-RNTI,
CORESET 0

PDSCH-ConfigCommon

G-RNTI,
UE specific

(Note 1)

G-CS-
search space
1, 2, 3
No/Yes
Yes
pdsch-TimeDomainAl-

RNTI

locationList provided in

(Option-2)

PDSCH-Config

(Note 1):

For G-RNTI and G-CS-RNTI PDSCH time domain resource allocation should be applied using the parameters provided in PDSCH-Config-Multicast, if configured

Currently, Type-X CSS is a new common search space defined for broadcast and multicast. For multicast, it is agreed that for CSS of group-common PDCCH of point-to-multipoint (PTM) scheme 1—whereby a group-common PDCCH is used to schedule group-common PDSCH for multicast in a RRC_CONNECTED state, a Type-X CSS is supported. The monitoring priority of Type-X CSS is determined based on the search space set indexes of the Type-x CSS set and UE-specific search space (USS) sets, regardless of which DCI format of group-common PDCCH is configured in the Type-X CSS.

As shown in Table 1 for Type-X CSS, the issue to be addressed is how to identify an appropriate TDRA list to be utilized for interpreting a TDRA field in DCI while simultaneously receiving multicast and broadcast traffic, using G-RNTI. Currently, the UE can either use option-1 or option-2 shown in the table. Based on the currently proposed specification update, in case PDSCH-Config-Multicast is not configured, a terminal device in a connected state receiving multicast/unicast and broadcast traffic might utilize a TDRA list provided in PDSCH-Config, but a terminal device receiving only broadcast traffic would utilize a TDRA list provided in PDSCH-ConfigCommon, leading to two different TDRA tables being used which in turn leads to misinterpretation of the TDRA field received within the DCI.

In view of this, embodiments of the present disclosure provide an improved solution for communication. In the solution, a TDRA list is determined from a set of configurations for TDRA based on an identifier for scrambling DCI, a RRC state of a terminal device and a type of traffic configured for the terminal device. Then, a TDRA field in the DCI the TDRA list is applied in the TDRA list to determine a time domain resource for transmission or reception of the traffic. In this way, a terminal device in a connected state receiving multicast/unicast and broadcast traffic and a terminal device receiving only broadcast traffic may be enabled to interpret a common TDRA list to be used. Accordingly, a significant flexibility to schedule MBS may be provided with optimal functioning of the time domain resource allocation, and a significant complexity reduction to a terminal device may be provided.

Principles and implementations of the present disclosure will be described in detail below with reference to the figures.

FIG. 1 illustrates an example communication network 100 in which embodiments of the present disclosure can be implemented. As shown in FIG. 1, the network 100 includes a first device 110 and a second device 120 serving the first device 110. It is to be understood that the number of the first and second devices as shown in FIG. 1 are only for the purpose of illustration without suggesting any limitations. The network 100 may include any suitable number of first and second devices adapted for implementing embodiments of the present disclosure. In some embodiments, the first device 110 may be a terminal device, and the second device 120 may be a network device.

Merely for illustration purposes and without suggesting any limitations as to the scope of the present disclosure, some embodiments will be described in the context where the first device 110 is a terminal device and the second device 120 is a network device. It is to be understood that, in other embodiments, the first device 110 may be a network device and the second device 120 may be a terminal device. In other words, the principles and spirit of the present disclosure may be applied to both uplink and downlink transmissions.

As shown in FIG. 1, the first device 110 and the second device 120 may communicate with each other via a wireless communication channel. The communications within the network 100 may conform to any suitable standard including, but not limited to, LTE, LTE-evolution, LTE-advanced (LTE-A), wideband code division multiple access (WCDMA), code division multiple access (CDMA) and global system for mobile communications (GSM) and the like. Furthermore, the communications may be performed according to any generation communication protocols either currently known or to be developed in the future. Examples of the communication protocols include, but not limited to, the first generation (1G), the second generation (2G), 2.5G, 2.75G, the third generation (3G), the fourth generation (4G), 4.5G, the fifth generation (5G) or the sixth generation (6G) communication protocols.

In some scenarios, the second device 120 may transmit any of multicast traffic, unicast traffic and broadcast traffic to the first device 110. For example, the second device 120 may transmit broadcast and multicast traffic to the first device 110. In some scenarios, the second device 120 may transmit DCI to the first device 110 to schedule the traffic. The DCI may comprise a TDRA field. The first device 110 may interpret the TDRA field to determine a time domain resource, and receive the traffic based on the time domain resource.

Embodiments of the present disclosure provide a mechanism for applying or interpreting the TDRA field in an appropriate TDRA list so that terminal devices receiving different types of traffic have a common understanding of the TDRA field. This mechanism of the present disclosure is illustrated in a high-level flowchart as shown in FIG. 2.

FIG. 2 illustrates a flowchart illustrating a process 200 of communication according to some embodiments of the present disclosure. For convenience, FIG. 2 will be described in connection with the example of FIG. 1.

As shown in FIG. 2, the second device 120 may transmit 210 a set of configurations for TDRA to the first device 110. In some embodiments, the set of configurations may be a set of higher layer configurations such as a set of RRC configurations. Of course, any other suitable forms are also feasible. In some embodiments, the set of configurations may comprise at least one of the following: a PDSCH-Config-Multicast configuration, a PDSCH-ConfigCommon configuration, a PDSCH-Config configuration, default A, B or C tables. It is to be understood that any other suitable configurations existing or to be developed in future are also feasible.

Each of the configurations comprises a predetermined TDRA list. For example, PDSCH-Config-Multicast configuration comprises pdsch-TimeDomainAllocationList-Multicast. PDSCH-Config-Broadcast configuration comprises pdsch-TimeDomainAllocationList-Broadcast. PDSCH-Config configuration comprises pdsch-TimeDomainAllocationList. Of course, any other suitable forms are also feasible.

When traffic is to be transmitted, the second device 120 transmits 220 DCI comprising a TDRA field to the first device 110. It is to be understood that the DCI may comprise any suitable additional fields, and the present disclosure does not limit this aspect.

Upon reception of the DCI, the first device 110 determines 230 a TDRA list from the set of configurations for TDRA based on at least one of the following: an identifier for scrambling the DCI, a RRC state of the first device 110, or a type of traffic configured for the first device. In this way, different devices configured with the reception of different types of traffic have a common understanding of the TDRA field for multicast and broadcast.

In some embodiments, a search space set type may configure the resources where the DCI may be sent along with the identifiers used for scrambling the DCI.

In some embodiments, the identifier for scrambling the DCI may be an identifier used to scramble CRC of the DCI. For example, the identifier may be a radio network temporary identity (RNTI) such as cell-RNTI (C-RNTI), group-RNTI (G-RNTI), group-common configured scheduling-RNTI (G-CS-RNTI), or single-cell-RNTI (SC-RNTI). It is to be understood that these are merely examples, and any other suitable identifiers are also feasible.

In some embodiments, the RRC state of the first device 110 may be a connected state such as a RRC_CONNECTED state or mode. In some embodiments, the RRC state of the first device 110 may be an idle state such as a RRC_IDLE state or mode. In some embodiments, the RRC state of the first device 110 may be an inactive state such as a RRC_INACTIVE state or mode.

In some embodiments, the type of traffic may be at least one of multicast traffic, broadcast traffic or unicast traffic.

Upon determination of the TDRA list, the first device 110 applies 240 the TDRA field based on the TDRA list to determine a time domain resource for reception of the traffic. The applying of the TDRA field may be implemented in any suitable ways and the present disclosure does not limit this aspect.

As shown in FIG. 2, after the transmission of the DCI, the second device 120 also determines 250 the TDRA list from the set of configurations based on at least one of the identifier for scrambling the DCI, the RRC state of the first device 110, or the type of traffic configured for the first device 110. The operations of the determining 250 are similar as that of the determining 230.

Upon determination of the TDRA list, the second device 120 also applies 260 the TDRA field based on the TDRA list to determine the time domain resource for transmission of the traffic. The operations of the applying 260 are similar as that of the applying 240. The applying of the TDRA field may be implemented in any suitable ways and the present disclosure does not limit this aspect.

For illustration, some example embodiments for the determination of the TDRA list will be described in connection with Embodiments 1 to 3.

Embodiment 1

In this embodiment, the TDRA list is determined based on the identifier for scrambling the DCI, the radio resource control state of the first device 110 or the type of traffic configured for the first device 110. This will be described with reference to FIG. 3A.

FIG. 3A illustrates a flowchart illustrating a method 300A of determining a TDRA list according to example embodiments of the present disclosure. The method 300A can be implemented at the first device 110 or the second device 120 shown in FIG. 1. For the purpose of discussion, the method 300A will be described in connection with the first device 110 in FIG. 1. It is to be understood that the method 300A may also be implemented at the second device 120. It is also to be understood that the method 300A may further include additional blocks not shown and/or omit some shown blocks, and the scope of the present disclosure is not limited in this regard.

As shown in FIG. 3A, at block 301, the first device 110 may determine whether the first device 110 is in a connected state. If the first device 110 is in the connected state, the process proceeds to block 302.

At block 302, the first device 110 may determine whether the type of traffic is at least broadcast and multicast traffic. For example, the first device 110 may determine whether the first device 110 is configured to receive broadcast and multicast traffic. In another example, the first device 110 may determine whether the first device 110 is configured to receive broadcast, multicast and unicast traffic. If the type of traffic is broadcast and multicast traffic, or if the type of traffic is broadcast, multicast and unicast traffic, the process 300A proceeds to block 303.

At block 303, the first device 110 may determine whether a PDSCH-Config-Multicast configuration (for convenience, also referred to as a first configuration herein) is configured for the first device 110. If the PDSCH-Config-Multicast configuration is configured, the process 300A proceeds to block 304.

At block 304, the first device 110 may determine whether the identifier is a predetermined identifier. In other words, the first device 110 may determine whether the DCI is scrambled by the predetermined identifier. For example, the first device 110 may determine whether CRC of the DCI is scrambled by the predetermined identifier. In some embodiments, the predetermined identifier may be a G-RNTI. In some embodiments, the predetermined identifier may be a G-CS-RNTI. Of course, the predetermined identifier may adopt any other suitable forms.

If the identifier is a predetermined identifier, the process 300A proceeds to block 305. At block 305, the first device 110 may determine the TDRA list from the PDSCH-Config-Multicast configuration. For example, the first device 110 may determine, as the TDRA list, a TDRA list such as pdsch-TimeDomainAllocationList-Multicast provided in the PDSCH-Config-Multicast configuration.

Return to block 303, if determining that the PDSCH-Config-Multicast configuration is not configured, the process 300A proceeds to block 306. At block 306, the first device 110 may determine whether a PDSCH-Config-Common configuration (for convenience, also referred to as a second configuration herein) is configured for the first device 110. If the PDSCH-Config-Common configuration is configured, the process 300A proceeds to block 307.

At block 307, the first device 110 may determine whether the identifier is a predetermined identifier. In other words, the first device 110 may determine whether the DCI is scrambled by the predetermined identifier. For example, the first device 110 may determine whether CRC of the DCI is scrambled by the predetermined identifier. In some embodiments, the predetermined identifier may be a G-RNTI. In some embodiments, the predetermined identifier may be a G-CS-RNTI. Of course, the predetermined identifier may adopt any other suitable forms.

If the identifier is a predetermined identifier, the process 300A proceeds to block 308. At block 308, the first device 110 may determine the TDRA list from the PDSCH-Config-Common configuration.

Return to block 306, if determining that the PDSCH-Config-Common configuration is not configured, the process 300A proceeds to block 309. At block 309, the first device 110 may determine whether the identifier is a predetermined identifier. In other words, the first device 110 may determine whether the DCI is scrambled by the predetermined identifier. For example, the first device 110 may determine whether CRC of the DCI is scrambled by the predetermined identifier. In some embodiments, the predetermined identifier may be a G-RNTI. In some embodiments, the predetermined identifier may be a G-CS-RNTI. Of course, the predetermined identifier may adopt any other suitable forms.

If the identifier is a predetermined identifier, the process 300A proceeds to block 310. At block 310, the first device 110 may determine whether the predetermined identifier is associated with multicast traffic or broadcast traffic.

If the predetermined identifier is associated with multicast traffic, the process 300A proceeds to block 311. At block 311, the first device 110 may determine the TDRA list from a default A table (for convenience, also referred to as a third configuration herein).

If the predetermined identifier is associated with broadcast traffic, the process 300A proceeds to block 312. At block 312, the first device 110 may determine the TDRA list from a set of default A, B and C tables (for convenience, also referred to as a fourth configuration herein) based on a synchronization signal (SS)/physical broadcast channel (PBCH) block and control resource set (CORESET) multiplexing pattern. For example, the first device 110 may determine the TDRA list from the default A, B or C table based on a SS/PBCH block and CORESET multiplexing pattern.

Embodiment 2

This embodiment is a modification of Embodiment 1. This embodiment provides an alternative for blocks 306 to 312 of FIG. 3A. In this embodiment, the first device 110 may receive, from the second device 120, an indication indicating whether a PDSCH-Config-Common configuration (i.e., the second configuration) or a PDSCH-Config configuration (for convenience, also referred to as a fifth configuration herein) is used for the determination of the TDRA list. The indication may be carried in any suitable forms.

The details of this embodiment will be described with reference to FIG. 3B. FIG. 3B illustrates a flowchart illustrating another method 300B of determining a TDRA list according to example embodiments of the present disclosure. The method 300B can be implemented at the first device 110 or the second device 120 shown in FIG. 1. For the purpose of discussion, the method 300B will be described in connection with the first device 110 in FIG. 1. It is to be understood that the method 300B may also be implemented at the second device 120. It is also to be understood that the method 300B may further include additional blocks not shown and/or omit some shown blocks, and the scope of the present disclosure is not limited in this regard.

If determining at block 303 in FIG. 3A that the PDSCH-Config-Multicast configuration (i.e., the first configuration) is not configured, the process 300B may start.

As shown in FIG. 3B, at block 320, the first device 110 may determine whether the PDSCH-Config-Common configuration or PDSCH-Config configuration is used based on the indication. If the PDSCH-Config-Common configuration is used, the process 300B proceeds to block 321.

At block 321, the first device 110 may determine whether the identifier is a predetermined identifier. In other words, the first device 110 may determine whether the DCI is scrambled by the predetermined identifier. For example, the first device 110 may determine whether CRC of the DCI is scrambled by the predetermined identifier. In some embodiments, the predetermined identifier may be a G-RNTI. In some embodiments, the predetermined identifier may be a G-CS-RNTI. Of course, the predetermined identifier may adopt any other suitable forms. In some embodiments, the predetermined identifier may be associated with multicast traffic. In some embodiments, the predetermined identifier may be associated with broadcast traffic.

If the identifier is the predetermined identifier, the process 300B proceeds to block 322. At block 322, the first device 110 may determine the TDRA list from the PDSCH-Config-Common configuration. In other words, if the first device 110 is not configured with PDSCH-Config-Multicast configuration, the first device 110 may apply a TDRA list provided in PDSCH-Config-Common configuration and apply it for only those DCIs with CRC scrambled using G-RNTI or G-CS-RNTI for multicast and broadcast.

Return to block 320, if determining that the PDSCH-Config configuration is used, the process 300B proceeds to block 323. At block 323, the first device 110 may determine whether the identifier is a predetermined identifier. In other words, the first device 110 may determine whether the DCI is scrambled by the predetermined identifier. For example, the first device 110 may determine whether CRC of the DCI is scrambled by the predetermined identifier. In some embodiments, the predetermined identifier may be a G-RNTI. In some embodiments, the predetermined identifier may be a G-CS-RNTI. Of course, the predetermined identifier may adopt any other suitable forms.

If the identifier is the predetermined identifier, the process 300B proceeds to block 324. At block 324, the first device 110 may determine the TDRA list from the PDSCH-Config configuration. In other words, if the first device 110 is not configured with PDSCH-Config-Multicast configuration, the first device 110 may apply a TDRA list provided in PDSCH-Config configuration and apply it for only those DCIs with CRC scrambled using G-RNTI or G-CS-RNTI for multicast and broadcast. In some embodiments, the predetermined identifier may be associated with multicast traffic. In some embodiments, the predetermined identifier may be associated with broadcast traffic.

In this way, the TDRA list to be used may be determined in an optimal manner, with all the UEs receiving the multicast and broadcast traffic determining common values for the time domain resources where the data traffic would be scheduled.

Embodiment 3

This embodiment is another modification of Embodiment 1. This embodiment provides an alternative for blocks 304 to 305 of FIG. 3A. The details of this embodiment will be described with reference to FIG. 3C.

FIG. 3C illustrates a flowchart illustrating still another method 300C of determining a TDRA list according to example embodiments of the present disclosure. The method 300C can be implemented at the first device 110 or the second device 120 shown in FIG. 1. For the purpose of discussion, the method 300C will be described in connection with the first device 110 in FIG. 1. It is to be understood that the method 300C may also be implemented at the second device 120. It is also to be understood that the method 300C may further include additional blocks not shown and/or omit some shown blocks, and the scope of the present disclosure is not limited in this regard.

If determining at block 303 in FIG. 3A that the PDSCH-Config-Multicast configuration (i.e., the first configuration) is configured, the process 300C may start.

As shown in FIG. 3C, at block 330, the first device 110 may determine whether the identifier is a predetermined identifier. In other words, the first device 110 may determine whether the DCI is scrambled by the predetermined identifier. For example, the first device 110 may determine whether CRC of the DCI is scrambled by the predetermined identifier.

In some embodiments, the predetermined identifier may be a G-RNTI. In some embodiments, the predetermined identifier may be a G-CS-RNTI. Of course, the predetermined identifier may adopt any other suitable forms.

If the identifier is the predetermined identifier, the process 300C proceeds to block 331. At block 331, the first device 110 may determine whether the predetermined identifier is associated with multicast traffic or broadcast traffic.

If the predetermined identifier is associated with multicast traffic, the process 300C proceeds to block 332. At block 332, the first device 110 may determine the TDRA list from the PDSCH-Config-Multicast configuration.

Return to block 331, if the predetermined identifier is associated with broadcast traffic, the process 300C proceeds to block 333. At block 333, the first device 110 may determine whether a PDSCH-Config-Broadcast configuration (for convenience, also referred to as a sixth configuration herein) is configured.

If the PDSCH-Config-Broadcast configuration is configured, the process 300C proceeds to block 334. At block 334, the first device 110 may determine the TDRA list from the PDSCH-Config-Broadcast configuration.

Return to block 333, if determining that the PDSCH-Config-Broadcast configuration is not configured, the process 300C proceeds to block 335. At block 335, the first device 110 may determine whether a PDSCH-Config-Common configuration (i.e., the second configuration) is configured.

If the PDSCH-Config-Common configuration is configured, the process 300C proceeds to block 336. At block 336, the first device 110 may determine the TDRA list from the PDSCH-Config-Common configuration.

If determining at block 335 that the PDSCH-Config-Common configuration is not configured, the process 300C proceeds to block 337. At block 337, the first device 110 may determine the TDRA list from a set of default A, B and C tables (i.e., the fourth configuration) based on a SS/PBCH block and CORESET multiplexing pattern. For example, the first device 110 may determine the TDRA list from the default A, B or C table based on a SS/PBCH block and CORESET multiplexing pattern.

According to embodiments of the present disclosure, Table 1 may be updated as Table 2 below.

TABLE 2

An example of applicable PDSCH time domain resource allocation for DCI formats 1_0 and 1_1

SS/PBCH
PDSCH-

block and
ConfigCommon
PDSCH-Config

CORESET
includes pdsch-
includes pdsch-
PDSCH time

PDCCH
multiplexing
TimeDomainAl-
TimeDomainAl-
domain resource

RNTI
search space
pattern
locationList
locationList
allocation to apply

SI-RNTI
Type0 common
1
—
—
Default A for normal

CP

2
—
—
Default B

3
—
—
Default C

SI-RNTI
Type0A common
1
No
—
Default A

2
No
—
Default B

3
No
—
Default C

1, 2, 3
Yes
—
pdsch-TimeDomainAl-

locationList provided in

PDSCH-

ConfigCommon

RA-RNTI,
Type1 common
1, 2, 3
No
—
Default A

MSGB-RNTI,

1, 2, 3
Yes
—
pdsch-TimeDomainAl-

TC-RNTI

locationList provided in

PDSCH-ConfigCommon

P-RNTI
Type2 common
1
No
—
Default A

2
No
—
Default B

3
No
—
Default C

1, 2, 3
Yes
—
pdsch-TimeDomainAl-

locationList provided in

PDSCH-ConfigCommon

G-RNTI,
Type X common
1
No
—
Default A

GS-RNTI
for broadcast
2
No
—
Default B

3
No
—
Default C

1, 2, 3
No/Yes
Yes (PDSCH-
pdsch-TimeDomainAl-

Config-
locationList provided in

Broadcast)
PDSCH-Config-Broadcast

1, 2, 3
No/Yes
No
pdsch-TimeDomainAl-

locationList provided in

PDSCH-ConfigCommon

C-RNTI,
Any common
1, 2, 3
No
—
Default A

MCS-C-
search space
1, 2, 3
Yes
—
pdsch-TimeDomainAl-

RNTI,
associated with

locationList provided in

CS-RNTI
CORESET 0

PDSCH-ConfigCommon

C-RNTI,
Any common
1, 2, 3
No
No
Default A

MCS-C-
search space not
1, 2, 3
Yes
No
pdsch-TimeDomainAl-

RNTI,
associated with

locationList provided in

CS-RNTI
CORESET 0

PDSCH-ConfigCommon

UE specific
1, 2, 3
No/Yes
Yes
pdsch-TimeDomainAl-

search space

locationList provided in

PDSCH-Config

G-RNTI,
Type-X common
1, 2, 3
No
No
pdsch-TimeDomainAl-

G-CS-
search space

locationList provided in

RNTI
for multicast

PDSCH-Config-Multicast

or if not configured

Default A

1, 2, 3
Yes
No
pdsch-TimeDomainAl-

locationList provided in

PDSCH-ConfigCommon

1, 2, 3
No/Yes
Yes
pdsch-TimeDomainAl-

locationList provided in

PDSCH-Config

1, 2, 3
No/Yes
No/Yes
pdsch-TimeDomainAl-

locationList provided in

PDSCH-Config-Multicast

Corresponding to the above process described in FIGS. 2 to 3C, embodiments of the present disclosure provide methods of communication implemented at a first device and at a second device. These methods will be described below with reference to FIGS. 4 to 5. However, those skilled in the art would readily appreciate that the detailed description given herein with respect to these figures is for explanatory purpose as the present disclosure extends beyond theses limited embodiments.

FIG. 4 illustrates a flowchart of a method 400 of communication implemented at a first device according to example embodiments of the present disclosure. The method 400 can be implemented at the first device 110 shown in FIG. 1. For the purpose of discussion, the method 400 will be described with reference to FIG. 1. It is to be understood that method 400 may further include additional blocks not shown and/or omit some shown blocks, and the scope of the present disclosure is not limited in this regard.

As shown in FIG. 4, at block 410, the first device 110 receives, from the second device 120, DCI comprising a TDRA field.

At block 420, the first device 110 determines, based on at least one of an identifier for scrambling the DCI, a RRC of the first device 110 or a type of traffic configured for the first device 110, a TDRA list from a set of configurations for TDRA.

In some embodiments, the RRC state of the first device 110 may be one of a connected state, idle state and inactive sate. In some embodiments, the type of traffic is at least one of broadcast traffic, multicast traffic or unicast traffic.

In some embodiments, if the first configuration is not configured for the first device 110, the first device 110 may determine whether a second configuration (for example, PDSCH-Config-Common configuration) is not configured for the first device 110. If the second configuration is configured for the first device 110, the first device 110 may determine whether the identifier is a predetermined identifier. If the identifier is the predetermined identifier, the first device 110 may determine the TDRA list from the second configuration.

In some embodiments, if the second configuration is not configured for the first device 110, the first device 110 may determine whether the identifier is a predetermined identifier. If the identifier is the predetermined identifier, the first device 110 may determine whether the predetermined identifier is associated with multicast traffic or broadcast traffic. If the predetermined identifier is associated with multicast traffic, the first device 110 may determine the TDRA list from a third configuration (for example, default A table). If the predetermined identifier is associated with broadcast traffic, the first device 110 may determine the TDRA list from a fourth configuration (for example, a set of default A, B and C tables) based on a SS/PBCH block and CORESET multiplexing pattern.

In some embodiments, the first device 110 may receive, from the second device 120, an indication indicating whether a second configuration (for example, PDSCH-Config-Common configuration) or a fifth configuration (for example, PDSCH-Config configuration) is used for the determination of the TDRA list.

In these embodiments, if the first configuration is not configured for the first device 110, the first device 110 may determine, based on the indication, whether the second configuration or the fourth configuration is used. If the second configuration is used, the first device 110 may determine whether the identifier is a predetermined identifier. If the identifier is the predetermined identifier, the first device 120 may determine the TDRA list from the second configuration. In some embodiments, if the fifth configuration is used, the first device 110 may determine whether the identifier is a predetermined identifier. If the identifier is the predetermined identifier, the first device 110 may determine the TDRA list from the fifth configuration.

In some embodiments, if the first device 110 is in a connected state and the type of traffic is at least broadcast and multicast traffic, the first device 110 may determine whether a first configuration (for example, PDSCH-Config-Multicast configuration) is configured for the first device 110. If the first configuration is configured for the first device 110, the first deice 110 may determine whether the identifier is a predetermined identifier. If the identifier is the predetermined identifier, the first device 110 may determine whether the predetermined identifier is associated with multicast traffic or broadcast traffic. If the predetermined identifier is associated with multicast traffic, the first device 110 may determine the TDRA list from the first configuration. If the predetermined identifier is associated with broadcast traffic, the first device 110 may determine whether a sixth configuration (for example, PDSCH-Config-Broadcast configuration) is configured for the first device 110. If the sixth configuration is configured for the first device 110, the first device 110 may determine the TDRA list from the sixth configuration.

In some embodiments, if the sixth configuration is not configured for the first device 110, the first device 120 may determine whether a second configuration is configured for the first device 110. If the second configuration is configured for the first device 110, the first device 110 may determine the TDRA list from the second configuration. If the second configuration is not configured for the first device 110, the first device 110 may determine the TDRA list from a fourth configuration (for example, a set of default A, B and C tables) based on a SS/PBCH block and CORESET multiplexing pattern.

Upon determination of the TDRA list, at block 430, the first device 110 applies, based on the TDRA list, the TDRA field for reception of the traffic from the second device 120.

With the method 400, a terminal device in a connected state receiving multicast/unicast and broadcast traffic and a terminal device receiving only broadcast traffic may be enabled to interpret a common TDRA list to be used. Accordingly, a significant complexity reduction to a terminal device may be provided.

Correspondingly, embodiments of the present disclosure also provide a method of communication implemented at a second device. FIG. 5 illustrates a flowchart of a method 500 of communication implemented at a second device according to example embodiments of the present disclosure. The method 500 can be implemented at the second device 120 shown in FIG. 1. For the purpose of discussion, the method 500 will be described with reference to FIG. 1. It is to be understood that method 500 may further include additional blocks not shown and/or omit some shown blocks, and the scope of the present disclosure is not limited in this regard.

As shown in FIG. 5, at block 510, the second device 120 transmits, to the first device 110, DCI comprising a TDRA field.

At block 520, the second device 120 determines, based on at least one of an identifier for scrambling the DCI, a RRC of the first device 110 or a type of traffic configured for the first device 110, a TDRA list from a set of configurations for TDRA.

In some embodiments, if the first configuration is not configured for the first device 110, the second device 120 may determine whether a second configuration (for example, PDSCH-Config-Common configuration) is not configured for the first device 110. If the second configuration is configured for the first device 110, the second device 120 may determine whether the identifier is a predetermined identifier. If the identifier is the predetermined identifier, the second device 120 may determine the TDRA list from the second configuration.

In some embodiments, if the second configuration is not configured for the first device 110, the second device 120 may determine whether the identifier is a predetermined identifier. If the identifier is the predetermined identifier, the second device 120 may determine whether the predetermined identifier is associated with multicast traffic or broadcast traffic. If the predetermined identifier is associated with multicast traffic, the second device 120 may determine the TDRA list from a third configuration (for example, default A table). If the predetermined identifier is associated with broadcast traffic, the second device 120 may determine the TDRA list from a fourth configuration (for example, a set of default A, B and C tables) based on a SS/PBCH block and CORESET multiplexing pattern.

In some embodiments, the second device 120 may transmit, to the first device 110, an indication indicating whether a second configuration (for example, PDSCH-Config-Common configuration) or a fifth configuration (for example, PDSCH-Config configuration) is used for the determination of the TDRA list.

In these embodiments, if the first configuration is not configured for the first device 110, the second device 120 may determine, based on the indication, whether the second configuration or the fourth configuration is used. If the second configuration is used, the second device 120 may determine whether the identifier is a predetermined identifier. If the identifier is the predetermined identifier, the second device 120 may determine the TDRA list from the second configuration. In some embodiments, if the fifth configuration is used, the second device 120 may determine whether the identifier is a predetermined identifier. If the identifier is the predetermined identifier, the second device 120 may determine the TDRA list from the fifth configuration.

In some embodiments, if the first device 110 is in a connected state and the type of traffic is at least broadcast and multicast traffic, the second device 120 may determine whether a first configuration (for example, PDSCH-Config-Multicast configuration) is configured for the first device 110. If the first configuration is configured for the first device 110, the second device 120 may determine whether the identifier is a predetermined identifier. If the identifier is the predetermined identifier, the second device 120 may determine whether the predetermined identifier is associated with multicast traffic or broadcast traffic. If the predetermined identifier is associated with multicast traffic, the second device 120 may determine the TDRA list from the first configuration. If the predetermined identifier is associated with broadcast traffic, the second device 120 may determine whether a sixth configuration (for example, PDSCH-Config-Broadcast configuration) is configured for the first device 110. If the sixth configuration is configured for the first device 110, the second device 120 may determine the TDRA list from the sixth configuration.

In some embodiments, if the sixth configuration is not configured for the first device 110, the second device 120 may determine whether a second configuration is configured for the first device 110. If the second configuration is configured for the first device 110, the second device 120 may determine the TDRA list from the second configuration. If the second configuration is not configured for the first device 110, the second device 120 may determine the TDRA list from a fourth configuration (for example, a set of default A, B and C tables) based on a SS/PBCH block and CORESET multiplexing pattern.

Upon determination of the TDRA list, at block 530, the second device 120 applies, based on the TDRA list, the TDRA field for transmission of the traffic to the first device 110.

With the method 500, a terminal device in a connected state receiving multicast/unicast and broadcast traffic and a terminal device receiving only broadcast traffic may be enabled to interpret a common TDRA list to be used. Accordingly, a significant flexibility to schedule MBS may be provided.

The operations in the methods of FIGS. 4 and 5 correspond to that in the process described in FIG. 2, and thus other details are omitted here.

In some embodiments, an apparatus (for example, the first device 110) capable of performing the method 400 may comprise means for performing the respective steps of the method 400. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

In some embodiments, the apparatus may comprise: means for receiving, at a first device and from a second device, downlink control information comprising a time domain resource allocation field; means for determining, based on at least one of an identifier for scrambling the downlink control information, a radio resource control state of the first device or a type of traffic configured for the first device, a time domain resource allocation list from a set of configurations for time domain resource allocation; and means for applying, based on the time domain resource allocation list, the time domain resource allocation field for reception of the traffic from the second device.

In some embodiments, the radio resource control state of the first device is one of a connected state, idle state and inactive sate, and the type of traffic is at least one of broadcast traffic, multicast traffic or unicast traffic.

In some embodiments, the means for determining the time domain resource allocation list comprises means for: in accordance with a determination that the first device is in a connected state and the type of traffic is at least broadcast and multicast traffic, determining whether a first configuration is configured for the first device; in accordance with a determination that the first configuration is configured for the first device, determining whether the identifier is a predetermined identifier; and in accordance with a determination that the identifier is the predetermined identifier, determining the time domain resource allocation list from the first configuration.

In some embodiments, the means for determining the time domain resource allocation list further comprises means for: in accordance with a determination that the first configuration is not configured for the first device, determining whether a second configuration is not configured for the first device; in accordance with a determination that the second configuration is configured for the first device, determining whether the identifier is a predetermined identifier; and in accordance with a determination that the identifier is the predetermined identifier, determining the time domain resource allocation list from the second configuration.

In some embodiments, the means for determining the time domain resource allocation list further comprises means for: in accordance with a determination that the second configuration is not configured for the first device, determining whether the identifier is a predetermined identifier; in accordance with a determination that the identifier is the predetermined identifier, determining whether the predetermined identifier is associated with multicast traffic or broadcast traffic; in accordance with a determination that the predetermined identifier is associated with multicast traffic, determining the time domain resource allocation list from a third configuration; and in accordance with a determination that the predetermined identifier is associated with broadcast traffic, determining the time domain resource allocation list from a fourth configuration based on a synchronization signal/physical broadcast channel block and control resource set multiplexing pattern.

In some embodiments, the apparatus may further comprise means for receiving, from the second device, an indication indicating whether a second configuration or a fifth configuration is used for the determination of the time domain resource allocation list.

In these embodiments, the means for determining the time domain resource allocation list may further comprise means for: in accordance with a determination that the first configuration is not configured for the first device, determining, based on the indication, whether the second configuration or the fourth configuration is used; in accordance with a determination that the second configuration is used, determining whether the identifier is a predetermined identifier; and in accordance with a determination that the identifier is the predetermined identifier, determining the time domain resource allocation list from the second configuration.

In some embodiments, the means for determining the time domain resource allocation list may further comprise means for: in accordance with a determination that the fifth configuration is used, determining whether the identifier is a predetermined identifier; and in accordance with a determination that the identifier is the predetermined identifier, determining the time domain resource allocation list from the fifth configuration.

In some embodiments, the means for determining the time domain resource allocation list may comprise means for: in accordance with a determination that the first device is in a connected state and the type of traffic is at least broadcast and multicast traffic, determining whether a first configuration is configured for the first device; in accordance with a determination that the first configuration is configured for the first device, determining whether the identifier is a predetermined identifier; in accordance with a determination that the identifier is the predetermined identifier, determining whether the predetermined identifier is associated with multicast traffic or broadcast traffic; in accordance with a determination that the predetermined identifier is associated with multicast traffic, determining the time domain resource allocation list from the first configuration; in accordance with a determination that the predetermined identifier is associated with broadcast traffic, determining whether a sixth configuration is configured for the first device; and in accordance with a determination that the sixth configuration is configured for the first device, determining the time domain resource allocation list from the sixth configuration.

In some embodiments, the means for determining the time domain resource allocation list may further comprise means for: in accordance with a determination that the sixth configuration is not configured for the first device, determining whether a second configuration is configured for the first device; in accordance with a determination that the second configuration is configured for the first device, determining the time domain resource allocation list from the second configuration; and in accordance with a determination that the second configuration is not configured for the first device, determining the time domain resource allocation list from a fourth configuration based on a synchronization signal/physical broadcast channel block and control resource set multiplexing pattern.

In some embodiments, the first device is a terminal device, and the second device is a network device. In some embodiments, the first configuration is a PDSCH-Config-Multicast configuration, the second configuration is a PDSCH-ConfigCommon configuration, the third configuration is a default A table, the fourth configuration is a set of default A, B and C tables, the fifth configuration is a PDSCH-Config configuration, and the sixth configuration is a PDSCH-Config-Broadcast configuration.

In some embodiments, an apparatus (for example, the second device 120) capable of performing the method 500 may comprise means for performing the respective steps of the method 500. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

In some embodiments, the apparatus may comprise: means for transmitting, at a second device and to a first device, downlink control information comprising a time domain resource allocation field; means for determining, based on at least one of an identifier for scrambling the downlink control information, a radio resource control state of the first device or a type of traffic configured for the first device, a time domain resource allocation list from a set of configurations for time domain resource allocation; and means for applying, based on the time domain resource allocation list, the time domain resource allocation field for transmission of the traffic to the first device.