CN115668992A

CN115668992A - Transmission method and device of MBS (multicast broadcast multicast service), network equipment and terminal equipment

Info

Publication number: CN115668992A
Application number: CN202080101106.4A
Authority: CN
Inventors: 王淑坤; 石聪
Original assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Current assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Priority date: 2020-07-10
Filing date: 2020-07-10
Publication date: 2023-01-31
Also published as: CN116471552A; WO2022006882A1

Abstract

The embodiment of the application provides a transmission method and a device of MBS service, network equipment and terminal equipment, wherein the method comprises the following steps: the network equipment adopts the first protocol stack to send the MBS service according to the multicast mode and adopts the second protocol stack to send the MBS service according to the unicast mode.

Description

Transmission method and device of MBS (multicast broadcast multicast service), network equipment and terminal equipment

Technical Field

The embodiment of the present application relates to the field of mobile communication technologies, and in particular, to a method and an apparatus for transmitting a Multimedia Broadcast Service (MBS) Service, a network device, and a terminal device.

Background

In a cell, a base station issues MBS service according to a multicast mode, and also issues MBS service for a certain specific user according to a unicast mode. How to design a protocol stack to realize that the MBS service is simultaneously issued according to a multicast mode and a unicast mode needs to be solved. On the other hand, when receiving the MBS service, the terminal device may also receive the non-MBS service, and how to design the protocol stack to achieve simultaneous reception of the MBS service and the non-MBS service needs to be solved.

Disclosure of Invention

The embodiment of the application provides a transmission method and device of MBS service, network equipment and terminal equipment.

The transmission method of the MBS service provided by the embodiment of the application comprises the following steps:

the network equipment adopts the first protocol stack to send the MBS service according to the multicast mode and adopts the second protocol stack to send the MBS service according to the unicast mode.

the terminal equipment receives MBS service by adopting a first protocol stack according to a multicast mode or a unicast mode, and receives first type service by adopting a second protocol stack according to a unicast mode, wherein the first type service is different from the MBS service.

The transmission device for MBS service provided in the embodiment of the present application includes:

and the sending unit is used for sending the MBS service by adopting a first protocol stack according to a multicast mode and sending the MBS service by adopting a second protocol stack according to a unicast mode.

a receiving unit, configured to receive, by using a first protocol stack, an MBS service in a multicast manner or a unicast manner, and receive, by using a second protocol stack, a first type of service in a unicast manner, where the first type of service is different from the MBS service.

The network equipment provided by the embodiment of the application comprises a processor and a memory. The memory is used for storing computer programs, and the processor is used for calling and running the computer programs stored in the memory to execute the transmission method of the MBS service.

The terminal device provided by the embodiment of the application comprises a processor and a memory. The memory is used for storing computer programs, and the processor is used for calling and running the computer programs stored in the memory and executing the MBS service transmission method.

The chip provided by the embodiment of the application is used for realizing the transmission method of the MBS service.

Specifically, the chip includes: and the processor is used for calling and running the computer program from the memory so that the equipment provided with the chip executes the transmission method of the MBS service.

The computer-readable storage medium provided in the embodiments of the present application is used for storing a computer program, where the computer program enables a computer to execute the MBS service transmission method described above.

The computer program product provided in the embodiment of the present application includes computer program instructions, and the computer program instructions enable a computer to execute the MBS service transmission method.

The computer program provided in the embodiment of the present application, when running on a computer, enables the computer to execute the MBS service transmission method.

Through the technical scheme, the base station adopts the first protocol stack to realize the sending of the MBS service according to the multicast mode and adopts the second protocol stack to realize the sending of the MBS service according to the unicast mode, thereby realizing that one cell simultaneously supports the sending of the MBS service in the multicast mode and the unicast mode. On the other hand, the terminal equipment adopts the first protocol stack to realize receiving the MBS service in a multicast mode or a unicast mode, and adopts the second protocol stack to realize receiving the first type of service (namely, the non-MBS service) in a unicast mode, thereby realizing that the terminal equipment simultaneously receives the MBS service and the non-MBS service.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:

fig. 1 is a schematic diagram of an architecture of a communication system provided in an embodiment of the present application;

fig. 2 is a schematic diagram illustrating that MBS services provided in an embodiment of the present application are transmitted in a multicast manner and a unicast manner;

fig. 3 is a first flowchart illustrating a transmission method of an MBS service according to an embodiment of the present application;

fig. 4-1 is a first schematic structural diagram of a protocol stack on a network device side according to an embodiment of the present application;

fig. 4-2 is a schematic structural diagram of a protocol stack on a network device side according to an embodiment of the present application;

fig. 4-3 is a third schematic structural diagram of a protocol stack on a network device side according to an embodiment of the present application;

fig. 4-4 is a schematic structural diagram of a protocol stack on the network device side according to an embodiment of the present application;

fig. 4-5 are schematic structural diagrams of a protocol stack on a network device side according to an embodiment of the present disclosure;

fig. 5 is a flowchart illustrating a second method for transmitting MBS services according to an embodiment of the present application;

fig. 6-1 is a first schematic structural diagram of a protocol stack on a terminal device side according to an embodiment of the present application;

fig. 6-2 is a schematic structural diagram of a protocol stack on the terminal device side according to an embodiment of the present application;

fig. 6-3 is a schematic structural diagram three of a protocol stack on the terminal device side according to the embodiment of the present application;

fig. 6-4 is a schematic structural diagram of a protocol stack on the terminal device side according to an embodiment of the present application;

fig. 7 is a first schematic structural diagram of a transmission apparatus for MBS service provided in an embodiment of the present application;

fig. 8 is a schematic structural diagram of a transmission apparatus for MBS service according to an embodiment of the present application;

fig. 9 is a schematic structural diagram of a communication device provided in an embodiment of the present application;

FIG. 10 is a schematic block diagram of a chip of an embodiment of the present application;

fig. 11 is a schematic block diagram of a communication system according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments of the present application, but not all embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments in the present application without making any creative effort belong to the protection scope of the present application.

The technical scheme of the embodiment of the application can be applied to various communication systems, for example: a Long Term Evolution (LTE) system, an LTE Frequency Division Duplex (FDD) system, an LTE Time Division Duplex (TDD) system, a 5G communication system, a future communication system, or the like.

For example, a communication system 100 applied in the embodiment of the present application is shown in fig. 1. The communication system 100 may include a network device 110, and the network device 110 may be a device that communicates with a terminal 120 (or referred to as a communication terminal, a terminal). Network device 110 may provide communication coverage for a particular geographic area and may communicate with terminals located within the coverage area. Alternatively, the Network device 110 may be an evolved Node B (eNB or eNodeB) in an LTE system, or a wireless controller in a Cloud Radio Access Network (CRAN), or the Network device may be a mobile switching center, a relay station, an Access point, an in-vehicle device, a wearable device, a hub, a switch, a bridge, a router, a Network-side device in a 5G Network, or a Network device in a future communication system, and the like.

The communication system 100 further comprises at least one terminal 120 located within the coverage area of the network device 110. As used herein, "terminal" includes, but is not limited to, connection via a wireline, such as via a Public Switched Telephone Network (PSTN), a Digital Subscriber Line (DSL), a Digital cable, a direct cable connection; and/or another data connection/network; and/or via a Wireless interface, e.g., for a cellular Network, a Wireless Local Area Network (WLAN), a digital television Network such as a DVB-H Network, a satellite Network, an AM-FM broadcast transmitter; and/or means of another terminal arranged to receive/transmit communication signals; and/or Internet of Things (IoT) devices. A terminal that is arranged to communicate over a wireless interface may be referred to as a "wireless communication terminal", "wireless terminal", or "mobile terminal". Examples of mobile terminals include, but are not limited to, satellite or cellular telephones; personal Communications System (PCS) terminals that may combine a cellular radiotelephone with data processing, facsimile and data Communications capabilities; PDAs that may include radiotelephones, pagers, internet/intranet access, web browsers, notepads, calendars, and/or Global Positioning System (GPS) receivers; and conventional laptop and/or palmtop receivers or other electronic devices that include a radiotelephone transceiver. A terminal can refer to an access terminal, user Equipment (UE), a subscriber unit, a subscriber station, mobile, remote station, remote terminal, mobile device, user terminal, wireless communication device, user agent, or User Equipment. An access terminal may be a cellular phone, a cordless phone, a Session Initiation Protocol (SIP) phone, a Wireless Local Loop (WLL) station, a Personal Digital Assistant (PDA), a handheld device with Wireless communication capabilities, a computing device or other processing device connected to a Wireless modem, a vehicle mounted device, a wearable device, a terminal in a 5G network, or a terminal in a future evolved PLMN, etc.

Optionally, the terminals 120 may perform direct-to-Device (D2D) communication therebetween.

Alternatively, the 5G communication system or the 5G network may also be referred to as a New Radio (NR) system or an NR network.

Fig. 1 exemplarily shows one network device and two terminals, alternatively, the communication system 100 may include a plurality of network devices and may include other numbers of terminals in the coverage area of each network device, which is not limited in this embodiment of the present application.

Optionally, the communication system 100 may further include other network entities such as a network controller, a mobility management entity, and the like, which is not limited in this embodiment.

It should be understood that, in the embodiments of the present application, a device having a communication function in a network/system may be referred to as a communication device. Taking the communication system 100 shown in fig. 1 as an example, the communication device may include a network device 110 and a terminal 120 having a communication function, and the network device 110 and the terminal 120 may be the specific devices described above and are not described again here; the communication device may also include other devices in the communication system 100, such as other network entities, for example, a network controller, a mobility management entity, and the like, which is not limited in this embodiment.

It should be understood that the terms "system" and "network" are often used interchangeably herein. The term "and/or" herein is merely an association relationship describing an associated object, and means that there may be three relationships, for example, a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, the character "/" herein generally indicates that the former and latter related objects are in an "or" relationship.

In order to facilitate understanding of the technical solutions of the embodiments of the present application, the technical solutions related to the embodiments of the present application are described below.

With the pursuit of speed, latency, high-speed mobility, energy efficiency and the diversity and complexity of the services in future life, the third generation partnership project (3) ^rd Generation Partnership Project,3 GPP) the international organization for standardization began developing 5G. The main application scenarios of 5G are: enhanced Mobile Ultra wide band (eMBB), low-Latency high-reliability Communications (URLLC), and massive Machine-Type Communications (mMTC).

On the one hand, the eMBB still targets users for multimedia content, services and data, and its demand is growing very rapidly. On the other hand, because the eMBB may be deployed in different scenarios, such as indoor, urban, rural, etc., and the difference between the capabilities and the requirements is relatively large, it cannot be said that it must be analyzed in detail in conjunction with a specific deployment scenario. Typical applications of URLLC include: industrial automation, electric power automation, remote medical operation (surgery), traffic safety, and the like. Typical characteristics of mtc include: high connection density, small data volume, insensitive time delay service, low cost and long service life of the module, etc.

In early NR deployment, complete NR coverage is difficult to obtain, so typical network coverage is wide-area LTE coverage and isolated island coverage pattern of NR. Moreover, a large amount of LTE is deployed below 6GHz, and the spectrum below 6GHz available for 5G is rare. NR must therefore be studied for spectrum applications above 6GHz, with limited high band coverage and fast signal fading. Meanwhile, in order to protect the early LTE investment of a mobile operator, a light interworking (TIGHT) working mode between LTE and NR is provided.

RRC state

5G defines a new Radio Resource Control (RRC) state, that is, an RRC INACTIVE (RRC _ INACTIVE) state, for the purpose of reducing air interface signaling, quickly recovering Radio connection, and quickly recovering data service. This state is distinguished from the RRC IDLE (RRC IDLE) state and the RRC ACTIVE (RRC ACTIVE) state. Wherein the content of the first and second substances,

1) RRC _ IDLE state (IDLE state for short): the mobility is cell selection and reselection based on terminal equipment, paging is initiated by a Core Network (CN), and a paging area is configured by the CN. The base station side has no terminal equipment context and no RRC connection.

2) RRC _ CONNECTED state (CONNECTED state for short): the RRC connection exists, and the base station side and the terminal device side have a terminal device context. The network side knows that the location of the terminal device is at a particular cell level. Mobility is network side controlled mobility. Unicast data may be communicated between the terminal device and the base station.

3) RRC _ INACTIVE state (INACTIVE state for short): mobility is based on cell selection reselection of terminal equipment, connection between CN-NR exists, context of the terminal equipment exists on a certain base station, paging is triggered by RAN, a paging area based on the RAN is managed by the RAN, and the network side knows that the position of the terminal equipment is based on the paging area level of the RAN.

MBMS

MBMS is a technology for transmitting data from one data source to a plurality of UEs by sharing network resources, which enables broadcasting and multicasting of a multimedia service at a higher rate (e.g., 256 kbps) by effectively using network resources while providing the multimedia service.

Because the MBMS spectrum efficiency is low, it is not enough to effectively carry and support the operation of the mobile tv type service. Therefore, in LTE, 3GPP explicitly proposes to enhance the support capability for downlink high-speed MBMS service, and determines the design requirements for the physical layer and air interface.

The 3GPP R9 introduces evolved MBMS (eMBMS) into LTE. eMBMS proposes a Single Frequency Network (SFN) concept, that is, a Multimedia Broadcast multicast service Single Frequency Network (MBSFN), which uses a uniform Frequency to simultaneously transmit service data in all cells, but needs to ensure synchronization between cells. The method can greatly improve the distribution of the overall signal-to-noise ratio of the cell, and the frequency spectrum efficiency can be correspondingly and greatly improved. eMBMS implements broadcast and multicast of services based on IP multicast protocol.

In LTE or LTE-Advanced (LTE-a), MBMS has only a broadcast bearer mode and no multicast bearer mode. In addition, the reception of the MBMS service is applicable to the UE in an idle state or a connected state.

A Single Cell Point To multipoint (SC-PTM) concept is introduced into a 3GPP R13, and the SC-PTM is based on an MBMS network architecture.

MBMS introduces new logical channels including a Single Cell-Multicast Control Channel (SC-MCCH) and a Single Cell-Multicast Transport Channel (SC-MTCH). The SC-MCCH and SC-MTCH are mapped to a Downlink-Shared Channel (DL-SCH), and the DL-SCH is further mapped to a Physical Downlink Shared Channel (PDSCH), wherein the SC-MCCH and SC-MTCH belong to a logical Channel, the DL-SCH belongs to a transport Channel, and the PDSCH belongs to a Physical Channel. The SC-MCCH and SC-MTCH do not support Hybrid Automatic Repeat reQuest (HARQ) operation.

MBMS introduces a new System Information Block (SIB) type, SIB20. Specifically, configuration information of the SC-MCCH is transmitted through the SIB20, and one cell has only one SC-MCCH. The configuration information of the SC-MCCH comprises: the modification period of the SC-MCCH, the repetition period of the SC-MCCH, and the scheduling of the wireless frame and the subframe of the SC-MCCH. Further, 1) the boundary of the modification period of the SC-MCCH satisfies SFN mod m =0, where SFN represents the system frame number of the boundary, and m is the modification period of the SC-MCCH configured in SIB20 (i.e., SC-MCCH-modification period). 2) And the wireless frame for scheduling the SC-MCCH meets the following requirements: SFN mod MCCH-RepetitionPeriod = MCCH-Offset, where SFN represents a system frame number of a radio frame, MCCH-RepetitionPeriod represents a repetition period of an SC-MCCH, and MCCH-Offset represents an Offset of the SC-MCCH. 3) The sub-frame of the SC-MCCH is scheduled and indicated by SC-MCCH-Subframe.

The SC-MCCH is scheduled through a Physical Downlink Control Channel (PDCCH). On one hand, a new Radio Network Temporary Identity (RNTI), that is, a Single Cell RNTI (SC-RNTI) is introduced to identify a PDCCH (e.g., SC-MCCH PDCCH) for scheduling an SC-MCCH, and optionally, the SC-RNTI is fixedly valued as FFFC. On the other hand, a new RNTI, that is, a Single Cell Notification RNTI (SC-N-RNTI) is introduced to identify a PDCCH (e.g., notification PDCCH) for indicating a change Notification of the SC-MCCH, and optionally, the SC-N-RNTI is fixedly set to FFFB; further, the change notification may be indicated with one bit of 8 bits (bits) of DCI 1C. In LTE, the configuration information of SC-PTM is based on SC-MCCH configured by SIB20, and then SC-MCCH configures SC-MTCH for transmitting service data.

Specifically, the SC-MCCH transmits only one message (i.e., SCPTMConfiguration) for configuring configuration information of the SC-PTM. The configuration information of SC-PTM includes: temporary Mobile Group Identity (TMGI), session Identity (session id), group RNTI (G-RNTI), discontinuous Reception (DRX) configuration information, SC-PTM service information of the neighbor cell, and the like. It should be noted that SC-PTM in R13 does not support Robust Header Compression (ROHC) function.

The downlink discontinuous reception of SC-PTMs is controlled by the following parameters: ondurationtimerscmp, drx-inactivetiimerscmp, SC-MTCH-scheduling cycle, and SC-MTCH-scheduling offset.

When [ (SFN x 10) + subframe number ] module (SC-MTCH-scheduling cycle) = SC-MTCH-scheduling offset is satisfied, a timer onDurationTimerSCPTM is started;

when receiving downlink PDCCH dispatching, starting a timer drx-InactivetyTimerSCPTM;

the downlink SC-PTM service is received only when the timer onDurationTimerSCPTM or drx-inactivityttimerscptm is running.

SC-PTM service continuity adopts SIB 15-based MBMS service continuity concept, namely SIB15+ MBMSIntestrIndication mode. The traffic continuity of idle UEs is based on the concept of frequency priority.

In the technical solution of the embodiment of the present application, a new SIB (referred to as a first SIB) is defined, where the first SIB includes configuration information of a first MCCH, where the first MCCH is a control channel of an MBMS service, in other words, the first SIB is used to configure configuration information of a control channel of an NR MBMS, and optionally, the control channel of the NR MBMS may also be referred to as an NR MCCH (i.e., the first MCCH).

Further, the first MCCH is used to carry first signaling, and the embodiment of the present application does not limit the name of the first signaling, for example, the first signaling is signaling a, and the first signaling includes configuration information of at least one first MTCH, where the first MTCH is a traffic channel (also referred to as a data channel or a transport channel) of an MBMS service, and the first MTCH is used to transmit MBMS service data (e.g., service data of NR MBMS). In other words, the first MCCH is used to configure configuration information of a traffic channel of the NR MBMS, which may also be called NR MTCH (i.e., the first MTCH) optionally.

Specifically, the first signaling is used to configure a service channel of the NR MBMS, service information corresponding to the service channel, and scheduling information corresponding to the service channel. Further, optionally, the service information corresponding to the service channel, for example, the identification information for identifying the service, such as the TMGI, the session id, and the like. The scheduling information corresponding to the traffic channel, for example, the RNTI used when the MBMS service data corresponding to the traffic channel is scheduled, such as G-RNTI, DRX configuration information, and the like.

It should be noted that the transmission of the first MCCH and the first MTCH is scheduled based on the PDCCH. Wherein, the RNTI used by the PDCCH for scheduling the first MCCH uses a network-wide unique identifier, which is a fixed value. An RNTI used by a PDCCH for scheduling a first MTCH is configured by the first MCCH.

It should be noted that, in the embodiments of the present application, nomenclature of the first SIB, the first MCCH, and the first MTCH is not limited. For convenience of description, the first SIB may also be referred to as SIB, the first MCCH may also be referred to as MCCH, the first MTCH may also be referred to as MTCH, and a PDCCH for scheduling MCCH (i.e., MCCH PDCCH) and a notification PDCCH are configured through SIB, wherein DCI carried through the MCCH PDCCH schedules PDSCH for transmitting MCCH (i.e., MCCH PDSCH). Further, M PDCCHs (namely MTCH 1PDCCH, MTCH2PDCCH, 8230; MTCH M PDCCH) for scheduling MTCH are configured through the MCCH, wherein DCI carried by the MTCH n PDCCH schedules PDSCH (namely MTCH n PDSCH) for transmitting MTCH n, and n is an integer which is more than or equal to 1 and less than or equal to M. The MCCH and MTCH are mapped to DL-SCH, which belongs to a logical channel, and further mapped to PDSCH, which belongs to a physical channel.

It should be noted that the MBMS service in the above scheme includes, but is not limited to, a multicast service and a multicast service. In the embodiment of the present application, an MBS service is taken as an example for description, and the description of the "MBS service" may also be replaced by a "multicast service" or an "MBMS service".

In the NR MBS service, besides that the same cell needs to send the MBS service in multicast transmission, it may also transmit the MBS service in unicast for a specific user, for example, when the channel of the user is poor, the MBS service needs to be transmitted in unicast for the user. In a cell, there may also be several users receiving a certain MBS service at the same time, but the base station sends the MBS service to each user in a unicast manner, for example, the efficiency of service transmission can be effectively improved by sending the MBS service to each user in a unicast manner when there are fewer users receiving the MBS service in the cell.

Referring to fig. 2, for a Packet Data Unit (PDU) session of a certain MBS service, a Shared GTP tunnel (Shared GTP tunnel) may be used between a 5G Core network (5G Core network, 5gc) and a gNB to transmit the MBS service, that is, the GTP tunnel is Shared for both unicast service and MBS service. The gNB issues MBS services to a multicast group (multicast group) in a multicast (multicast) manner, and issues MBS services to a certain UE in a unicast (unicast) manner (fig. 2 takes UE3 as an example). Wherein, the multicast group includes one or more UEs (fig. 2 takes the example that the multicast group includes UE1 and UE 2). How to design the protocol stack for transmitting the MBS service according to the unicast mode and transmitting the MBS according to the multicast mode needs to be solved. Therefore, the following technical scheme of the embodiment of the application is provided.

Fig. 3 is a first flowchart of a MBS service transmission method provided in an embodiment of the present application, where as shown in fig. 3, the MBS service transmission method includes the following steps:

step 301: the network equipment adopts the first protocol stack to send the MBS service according to the multicast mode and adopts the second protocol stack to send the MBS service according to the unicast mode.

In this embodiment, the network device may be a base station, such as a gbb. The network equipment can realize that the MBS service is sent in the same cell according to a multicast mode, and simultaneously, the MBS service is sent according to a unicast method.

It should be noted that, for the case that the network device sends the MBS service in the unicast manner, if the channel ratio of a certain terminal device is poor, the network device may send the MBS service to the terminal device in the unicast manner. Of course, in order to improve the receiving efficiency of the MBS service, the network device may also send the MBS service to one or more terminal devices in a unicast manner.

In the embodiment of the application, scheduling information of MBS business sent in a multicast mode is scrambled through G-RNTI; and scrambling the scheduling information of the MBS service transmitted in a unicast mode through G-RNTI or C-RNTI.

In the embodiment of the present application, a network device sends an MBS service in a multicast manner by using a first protocol stack, and sends the MBS service in a unicast manner by using a second protocol stack, and the specific implementation of the protocol stack on the network device side is described below.

In an embodiment of the present application, the first protocol stack includes a first Physical (PHY) entity, and the second protocol stack includes a second PHY entity; and the network equipment adopts the first PHY entity to send the MBS service in a multicast mode and adopts the second PHY entity to send the MBS service in a unicast mode.

The first protocol stack includes other protocol stack entities in addition to the first PHY entity. The second protocol stack includes other protocol stack entities in addition to the second PHY entity. The following description will be divided into cases.

● Situation one

The first protocol stack and the second protocol stack have a common Media Access Control (MAC) entity; the public MAC entity is used for copying the MAC PDU of the MBS service, transmitting the MAC PDU to the first PHY entity and transmitting the copied MAC PDU to the second PHY entity.

Further, in an optional manner, the first protocol stack and the second protocol stack further have at least one protocol stack entity in common, which is: a Service Data Adaptation Protocol (SDAP) entity, a Packet Data Convergence Protocol (PDCP) entity, and a Radio Link Control (RLC) entity.

● Situation two

The first protocol stack and the second protocol stack have a common SDAP entity; the public SDAP entity is used for copying the SDAP PDU of the MBS service, transmitting the SDAP PDU to the PDCP entity or the RLC entity in the first protocol stack, and transmitting the copied SDAP PDU to the PDCP entity or the RLC entity in the second protocol stack.

Further, in an optional manner, the first protocol stack and the second protocol stack have independent PDCP entities and/or RLC entities.

● Situation three

The first protocol stack and the second protocol stack have a common PDCP entity; the public PDCP entity is used for copying the PDCP PDU of the MBS service, transmitting the PDCP PDU to the RLC entity in the first protocol stack and transmitting the copied PDCP PDU to the RLC entity in the second protocol stack.

Further, in an optional manner, the first protocol stack and the second protocol stack further have a common SDAP entity, and the first protocol stack and the second protocol stack have independent RLC entities.

● Situation four

The first protocol stack and the second protocol stack have a common RLC entity; the common RLC entity is used for copying the RLC PDU of the MBS service, transmitting the RLC PDU to the MAC entity in the first protocol stack and transmitting the copied RLC PDU to the MAC entity in the second protocol stack.

Further, in an optional manner, the first protocol stack and the second protocol stack further have a common SDAP entity and/or PDCP entity.

● Situation five

The first protocol stack and the second protocol stack are provided with an SDAP entity, a PDCP entity, an RLC entity and an MAC entity which are independent; or the first protocol stack and the second protocol stack have independent SDAP entity, RLC entity and MAC entity.

For any of the above two cases to the fourth case, the MAC entity on the network device side may have the following two implementation manners:

1) The first method is as follows:

the first protocol stack and the second protocol stack have a common MAC entity; the common MAC entity is used for mapping the RLC PDU corresponding to the multicast mode in the first MAC PDU and mapping the RLC PDU corresponding to the unicast mode in the second MAC PDU.

Here, the multicast mode and the unicast mode share one MAC entity, and the network device needs to ensure that, when assembling MAC PDUs, RLC PDUs corresponding to the multicast mode are mapped to one MAC PDU, and RLC PDUs corresponding to the unicast mode are mapped to another MAC PDU.

2) The second method comprises the following steps:

the first protocol stack and the second protocol stack have independent MAC entities; a first MAC entity in the first protocol stack is used for mapping RLC PDUs corresponding to a multicast mode in the first MAC PDUs; and the second MAC entity in the second protocol stack is used for mapping the RLC PDU corresponding to the multicast mode in the second MAC PDU.

Here, the multicast scheme and the unicast scheme configure their respective MAC entities independently. Each MAC entity may use a respective MAC layer function, such as a DRX function.

The foregoing various aspects of the embodiments of the present application are explained below with reference to specific examples.

Example one (corresponding to case one above)

Referring to fig. 4-1, fig. 4-1 is a schematic structural diagram of a protocol stack on the network device side, and a description of an "entity" is omitted in fig. 4-1, for example, "SDAP" in fig. 4-1 indicates an "SDAP entity".

The PDU session of the MBS service comprises one or more Qos flows, and the one or more Qos flows of the PDU session can be mapped to one or more DRBs through the SDAP entity, wherein the mapping relation between the Qos flows and the DRBs can be one-to-one or many-to-one. Each DRB corresponds to a logical channel, wherein different DRBs are transmitted through different PDCP entities and RLC entities, i.e. different logical channels correspond to different PDCP entities and RLC entities.

It should be noted that, in fig. 4-1, there may be no PDCP entity or SDAP entity for each DRB. That is, for each DRB, there may be a PDCP entity, or a PDCP entity + SDAP entity, or a SDAP entity.

The MAC entity copies each MAC PDU (i.e., a TB data) to the PHY2 entity (i.e., the second PHY entity), and the original MAC PDU is sent to the PHY1 entity (i.e., the first PHY entity), and the PHY1 entity sends the MBS service in a multicast manner and the PHY2 entity sends the MBS service in a unicast manner.

As can be seen from fig. 4-1, the first protocol stack (i.e., the protocol stack corresponding to the MBS service sent in multicast) and the second protocol stack (i.e., the protocol stack corresponding to the MBS service sent in unicast) have the following common protocol stack entities: the first protocol stack and the second protocol stack have independent PHY entities. It should be noted that, for a common protocol stack entity, one or more protocol stack entities may not exist.

In the above scheme, the network device does not need to implement the functions of the SDAP entity, the PDCP entity, the RLC entity and the MAC entity twice for the same MBS session, and the terminal device can improve the reliability of receiving the MBS service by simultaneously receiving the MBS service in the multicast mode and the MBS service in the unicast mode.

Example two (corresponding to case two above)

Referring to fig. 4-2, fig. 4-2 is a schematic diagram of a structure of a protocol stack on the network device side, and a description of an "entity" is omitted in fig. 4-2, for example, the "SDAP" in fig. 4-2 indicates an "SDAP entity".

It should be noted that, in fig. 4-2, there may be no PDCP entity or SDAP entity for each DRB. That is, for each DRB, there may be a PDCP entity, or a PDCP entity + SDAP entity, or a SDAP entity.

As shown in fig. 4-2 (a), the SDAP entity copies each SDAP PDU to the PDCP2 entity, and the original SDAP PDU to the PDCP1 entity. Then, the PDCP1 entity transmits the corresponding PDCP PDU to the RLC1 entity, the RLC1 entity transmits the corresponding RLC PDU to the MAC1 entity, the MAC1 entity transmits the corresponding MAC PDU to the PHY1 entity, and the MBS service is transmitted through the PHY1 entity according to a multicast mode; meanwhile, the PDCP2 entity transmits the corresponding PDCP PDU to the RLC2 entity, the RLC2 entity transmits the corresponding RLC PDU to the MAC2 entity, the MAC2 entity transmits the corresponding MAC PDU to the PHY2 entity, and the MBS service is transmitted through the PHY2 entity in a unicast mode.

As shown in (b) of fig. 4-2, the SDAP entity copies each SDAP PDU to the PDCP2 entity, and the original SDAP PDU to the PDCP1 entity. Then, the PDCP1 entity transmits the corresponding PDCP PDU to the RLC1 entity, the RLC1 entity transmits the corresponding RLC PDU to the MAC entity, the MAC entity transmits the corresponding MAC PDU to the PHY1 entity, and the MBS service is transmitted through the PHY1 entity according to a multicast mode; meanwhile, the PDCP2 entity transmits the corresponding PDCP PDU to the RLC2 entity, the RLC2 entity transmits the corresponding RLC PDU to the MAC entity, the MAC entity transmits the corresponding MAC PDU to the PHY2 entity, and the MBS service is transmitted through the PHY2 entity in a unicast mode.

It should be noted that the PDCP1 entity in fig. 4-2 includes a PDCP11 entity, a PDCP12 entity, \ 8230, and a PDCP1n entity, wherein different PDCP entities correspond to different DRBs (i.e., different logical channels). The PDCP2 entity in fig. 4-2 includes a PDCP21 entity, a PDCP22 entity, \8230, and a PDCP2n entity, wherein different PDCP entities correspond to different DRBs (i.e., to different logical channels). Similarly, the RLC1 entity in fig. 4-2 includes RLC11 entity, RLC12 entity, \ 8230;, and RLC1n entity, wherein different RLC entities correspond to different DRBs (i.e., different logical channels). The RLC2 entities in fig. 4-2 include RLC21 entity, RLC22 entity, \8230;, and RLC2n entity, wherein different RLC entities correspond to different DRBs (i.e., to different logical channels).

As can be seen from (a) in fig. 4-2, the first protocol stack (i.e., the protocol stack corresponding to the MBS service transmitted in multicast) and the second protocol stack (i.e., the protocol stack corresponding to the MBS service transmitted in unicast) have the following common protocol stack entities: the SDAP entity, the first protocol stack and the second protocol stack have independent PDCP entity, RLC entity, MAC entity and PHY entity. It should be noted that, for the independent protocol stack entities, one or more protocol stack entities may not exist.

As can be seen from (b) in fig. 4-2, the first protocol stack (i.e., the protocol stack corresponding to the MBS service sent in multicast) and the second protocol stack (i.e., the protocol stack corresponding to the MBS service sent in unicast) have the following common protocol stack entities: SDAP entity and MAC entity, the first protocol stack and the second protocol stack have independent PDCP entity, RLC entity and PHY entity. It should be noted that, for the independent protocol stack entities, one or more protocol stack entities may not exist.

In the above scheme, if the PDCP entity is shared by the multicast mode and the unicast mode, the network device does not need to implement the same MBS service, and the mapping from the Qos flow to the DRB is implemented twice. In addition, if the multicast mode and the unicast mode share the MAC entity, the network equipment does not need to realize the functions of the MAC entity twice for the same MBS session; if the multicast mode and the unicast mode are respectively configured with independent MAC entities, the realization complexity can be effectively reduced.

Example three (corresponding to case three above)

Referring to fig. 4-3, fig. 4-3 is a schematic structural diagram of a protocol stack on the network device side, and a description of an "entity" is omitted in fig. 4-3, for example, "SDAP" in fig. 4-3 indicates an "SDAP entity".

The PDU session of the MBS service includes one or more Qos flows, and the one or more Qos flows of the PDU session may be mapped to one or more DRBs through the SDAP entity, where the mapping relationship between the Qos flows and the DRBs may be one-to-one or many-to-one. Each DRB corresponds to a logical channel, wherein different DRBs are transmitted through different PDCP entities and RLC entities, i.e. different logical channels correspond to different PDCP entities and RLC entities.

It should be noted that, in fig. 4-3, there may be no PDCP entity or SDAP entity for each DRB. That is, for each DRB, there may be a PDCP entity, or a PDCP entity + SDAP entity, or a SDAP entity.

As shown in (a) of fig. 4-3, the PDCP entity copies each PDCP PDU to the RLC2 entity, and the original PDCP PDU is provided to the RLC1 entity. Then, the RLC1 entity transmits the corresponding RLC PDU to the MAC1 entity, the MAC1 entity transmits the corresponding MAC PDU to the PHY1 entity, and the MBS service is transmitted through the PHY1 entity according to a multicast mode; meanwhile, the RLC2 entity transmits the corresponding RLC PDU to the MAC2 entity, the MAC2 entity transmits the corresponding MAC PDU to the PHY2 entity, and the MBS service is transmitted through the PHY2 entity in a unicast mode.

As shown in (b) of fig. 4-3, the PDCP entity copies each PDCP PDU to the RLC2 entity, and the original PDCP PDU to the RLC1 entity. Then, the RLC1 entity transmits the corresponding RLC PDU to the MAC entity, the MAC entity transmits the corresponding MAC PDU to the PHY1 entity, and the MBS service is transmitted through the PHY1 entity in a multicast mode; meanwhile, the RLC2 entity transmits the corresponding RLC PDU to the MAC entity, the MAC entity transmits the corresponding MAC PDU to the PHY2 entity, and the MBS service is transmitted through the PHY2 entity in a unicast mode.

It should be noted that the RLC1 entity in fig. 4-3 includes an RLC11 entity, an RLC12 entity, \ 8230;, and an RLC1n entity, wherein different RLC entities correspond to different DRBs (i.e., different logical channels). The RLC2 entities in fig. 4-3 include RLC21 entity, RLC22 entity, \8230;, and RLC2n entity, where different RLC entities correspond to different DRBs (i.e., to different logical channels).

As can be seen from (a) in fig. 4-3, the first protocol stack (i.e., the protocol stack corresponding to the MBS service transmitted in multicast) and the second protocol stack (i.e., the protocol stack corresponding to the MBS service transmitted in unicast) have the following common protocol stack entities: the first protocol stack and the second protocol stack have independent RLC entity, MAC entity and PHY entity. It should be noted that, for a common protocol stack entity, one or more protocol stack entities may not exist.

As can be seen from (b) in fig. 4-3, the first protocol stack (i.e., the protocol stack corresponding to the MBS service sent in multicast) and the second protocol stack (i.e., the protocol stack corresponding to the MBS service sent in unicast) have the following common protocol stack entities: the first protocol stack and the second protocol stack have independent RLC entities and PHY entities. It should be noted that, for a common protocol stack entity, one or more protocol stack entities may not exist.

In the above solution, if the SDAP entity and the PDCP entity are shared in the multicast mode and the unicast mode, the terminal device may also improve the reliability of receiving the MBS service by receiving the MBS service in the multicast mode and the MBS service in the unicast mode simultaneously, except that the network device does not need to implement the functions of the SDAP entity and the PDCP entity twice for the same MBS session. In addition, if the multicast mode and the unicast mode share the MAC entity, the network equipment does not need to realize the functions of the MAC entity twice for the same MBS session; if the multicast mode and the unicast mode are respectively configured with independent MAC entities, the realization complexity can be effectively reduced.

Example four (corresponding to the case four above)

Referring to fig. 4-4, fig. 4-4 are schematic structural diagrams of a protocol stack on the network device side, and a description of an "entity" is omitted in fig. 4-4, for example, "SDAP" in fig. 4-4 indicates an "SDAP entity".

It should be noted that in fig. 4-4, there may be no PDCP entity or SDAP entity for each DRB. That is, for each DRB, there may be a PDCP entity, or a PDCP entity + SDAP entity, or a SDAP entity.

As shown in fig. 4-4 (a), the RLC entity copies each RLC PDU to the MAC2 entity, and the original RLC PDU to the MAC1 entity. Then, the MAC1 entity transmits the corresponding MAC PDU to the PHY1 entity, and the MBS service is transmitted by the PHY1 entity according to the multicast mode; meanwhile, the MAC2 entity transmits the corresponding MAC PDU to the PHY2 entity, and the MBS service is transmitted by the PHY2 entity in a unicast mode.

As shown in (b) of fig. 4-4, the RLC entity copies each RLC PDU to the MAC entity, and the original RLC PDU is delivered to the MAC entity. Then, the MAC entity transmits the corresponding MAC PDU to the PHY1 entity, and the MBS service is transmitted through the PHY1 entity in a multicast mode; meanwhile, the MAC entity transmits the corresponding MAC PDU to the PHY2 entity, and the MBS service is transmitted by the PHY2 entity in a unicast mode.

As can be seen from (a) in fig. 4-4, the first protocol stack (i.e., the protocol stack corresponding to the MBS service transmitted in multicast) and the second protocol stack (i.e., the protocol stack corresponding to the MBS service transmitted in unicast) have the following common protocol stack entities: the first protocol stack and the second protocol stack have independent MAC entity and PHY entity. It should be noted that, for a common protocol stack entity, one or more protocol stack entities may not exist.

As can be seen from (b) in fig. 4-4, the first protocol stack (i.e., the protocol stack corresponding to the MBS service sent in multicast) and the second protocol stack (i.e., the protocol stack corresponding to the MBS service sent in unicast) have the following common protocol stack entities: the system comprises an SDAP entity, a PDCP entity, an RLC entity and an MAC entity, wherein a first protocol stack and a second protocol stack are provided with independent PHY entities. It should be noted that, for a common protocol stack entity, one or more protocol stack entities may not exist.

In the above solution, if the multicast mode and the unicast mode share the SDAP entity, the PDCP entity, and the RLC entity, the network device does not need to implement the functions of the SDAP entity, the PDCP entity, and the RLC entity twice for the same MBS session, which needs to be described. In addition, if the multicast mode and the unicast mode share the MAC entity, the network equipment does not need to realize the functions of the MAC entity twice for the same MBS session; if the multicast mode and the unicast mode are respectively configured with independent MAC entities, the realization complexity can be effectively reduced.

Example five (corresponding to case five above)

Referring to fig. 4-5, fig. 4-5 are schematic structural diagrams of a protocol stack on the network device side, and a description of an "entity" is omitted in fig. 4-5, for example, "SDAP" in fig. 4-5 indicates an "SDAP entity".

It should be noted that in fig. 4-5, there may be no PDCP entity or SDAP entity for each DRB. That is, for each DRB, there may be a PDCP entity, or a PDCP entity + SDAP entity, or a SDAP entity.

The QoS flow of PDU conversation of MBS business is duplicated, the original QoS flow is transmitted to a first protocol stack, the duplicated QoS flow is transmitted to a second protocol stack, the first protocol stack and the second protocol stack are completely independent, and both have respective protocol stack entities.

In the above scheme, the multicast mode and the unicast mode are respectively configured with independent protocol stacks, so that the implementation is relatively simple.

Fig. 5 is a flowchart illustrating a second method for transmitting MBS services provided in an embodiment of the present application, where as shown in fig. 5, the method for transmitting MBS services includes the following steps:

step 501: the terminal equipment receives the MBS service by adopting a first protocol stack according to a multicast mode or a unicast mode, and receives a first type of service by adopting a second protocol stack according to a unicast mode, wherein the first type of service is different from the MBS service.

In this embodiment, from the perspective of the terminal device, the terminal device receives the MBS service and also receives a non-MBS service (hereinafter, referred to as a first type of service), where the first type of service is, for example, an eMBB service. The terminal equipment can receive the MBS service in a unicast mode or a multicast mode depending on the configuration of the network side.

In the embodiment of the present application, the terminal device receives the MBS service in a multicast mode or a unicast mode by using the first protocol stack, and receives the first type of service in a unicast mode by using the second protocol stack, and a specific implementation of the protocol stack on the terminal device side is described below.

In an embodiment of the present application, the first protocol stack includes a first PHY entity, and the second protocol stack includes a second PHY entity; and the terminal equipment receives the MBS service by adopting the first PHY entity in a multicast mode or a unicast mode, and receives the first type of service by adopting the second PHY entity in a unicast mode.

● Case A

The first protocol stack and the second protocol stack have a common MAC entity, and the logic channel identifier of the MBS service has uniqueness in a cell.

● Case B

The first protocol stack and the second protocol stack have independent MAC entities.

In this embodiment of the present application, when the terminal device receives the MBS service in a multicast manner, the terminal device decrypts the MBS service by using a first secret key configured by a network device, where the first secret key is a multicast secret key. Further, the first key has an association relationship with at least one of: a logical channel identifier, a Data Radio Bearer (DRB) identifier and a PDCP entity.

In this embodiment of the present application, when the terminal device receives the MBS service in a unicast manner, the terminal device decrypts the MBS service by using a second secret key configured by a network device, where the second secret key is a multicast secret key or a unicast secret key. Further, the second key has an association relationship with at least one of: logical channel identification, DRB identification, PDCP entity.

Example six (corresponding to case A above, with terminal device receiving MBS service in multicast mode)

Referring to fig. 6-1, fig. 6-1 is a schematic diagram of a structure of a protocol stack on the terminal device side, and a description of an "entity" is omitted in fig. 6-1, for example, an "SDAP" in fig. 6-1 indicates an "SDAP entity".

The terminal equipment receives MBS service through a multicast mode according to the network side configuration, and simultaneously receives eMBB service through a unicast mode. The MBS service and the eMBB service have independent PHY entities and have a common MAC entity. For this case, the protocol provides for reserving logical channel identifiers for MBS services, or the network side ensures that logical channel identifiers for MBS services are unique within a cell.

The scheduling information of the MBS service is scrambled through the G-RNTI, and the terminal equipment receives the scheduling information of the MBS service according to the G-RNTI configured at the network side, and further receives the MBS service through a broadcasting mode according to the scheduling information. The scheduling information of the eMBMS is scrambled through the C-RNTI, the terminal equipment receives the scheduling information of the eMBMS according to the C-RNTI configured on the network side, and then the eMBMS is received through a unicast mode according to the scheduling information.

Example seven (corresponding to case A above and with terminal device receiving MBS traffic in unicast)

Referring to fig. 6-2, fig. 6-2 is a schematic structural diagram of a protocol stack on the terminal device side, and a description of an "entity" is omitted in fig. 6-2, for example, "SDAP" in fig. 6-2 indicates an "SDAP entity".

The terminal equipment receives MBS service through a unicast mode according to the network side configuration, and simultaneously receives eMBB service through the unicast mode. The MBS service and the eMBB service have separate PHY entities and have a common MAC entity. For this case, the protocol provides for reserving logical channel identifiers for MBS services, or the network side ensures that logical channel identifiers for MBS services are unique within a cell.

The scheduling information of the MBS service is scrambled through G-RNTI or C-RNTI, and the terminal equipment receives the scheduling information of the MBS service according to the G-RNTI or C-RNTI configured at the network side, and further receives the MBS service through a unicast mode according to the scheduling information. The scheduling information of the eMBB service is scrambled through the C-RNTI, and the terminal equipment receives the scheduling information of the eMBB service according to the C-RNTI configured on the network side and further receives the eMBB service through a unicast mode according to the scheduling information.

Further, the network device may configure, for the terminal device, whether the key used when receiving the MBS service in the unicast manner is a multicast key or a unicast key. Each logical channel identifier or each DRB identifier or each PDCP entity is associated with a key, which may be a unicast key or a multicast key, and is used for the terminal device to decrypt the MBS service.

Example eight (corresponding to the above case B, and the terminal device receives MBS service in multicast mode)

Referring to fig. 6-3, fig. 6-3 is a schematic structural diagram of a protocol stack on the terminal device side, and a description of an "entity" is omitted in fig. 6-3, for example, "SDAP" in fig. 6-3 indicates an "SDAP entity".

The terminal equipment receives MBS service through a multicast mode according to the network side configuration, and simultaneously receives eMBB service through a unicast mode. The MBS service and the eMBB service have separate PHY and MAC entities. For this case, each MAC entity has a respective MAC function, e.g. a DRX function.

The scheduling information of the MBS service is scrambled through the G-RNTI, the terminal equipment receives the scheduling information of the MBS service according to the G-RNTI configured by the network side, and then receives the MBS service through a broadcasting mode according to the scheduling information. The scheduling information of the eMBB service is scrambled through the C-RNTI, and the terminal equipment receives the scheduling information of the eMBB service according to the C-RNTI configured on the network side and further receives the eMBB service through a unicast mode according to the scheduling information.

Example nine (corresponding to the above case B, and the terminal device receives MBS service in unicast)

Referring to fig. 6-4, fig. 6-4 is a schematic diagram of a structure of a protocol stack on the terminal device side, and a description of an "entity" is omitted in fig. 6-4, for example, the "SDAP" in fig. 6-4 indicates an "SDAP entity".

The terminal equipment receives MBS service through a unicast mode according to the network side configuration, and simultaneously receives eMBB service through the unicast mode. MBS services and eMBB services have separate PHY and MAC entities. For this case, each MAC entity has a respective MAC function, e.g. a DRX function.

Fig. 7 is a schematic structural diagram of a MBS service transmission apparatus provided in an embodiment of the present application, which is applied to a network device (e.g., a base station), and as shown in fig. 7, the MBS service transmission apparatus includes:

a sending unit 701, configured to send an MBS service in a multicast manner using a first protocol stack, and send the MBS service in a unicast manner using a second protocol stack.

In an alternative, the first protocol stack includes a first PHY entity, and the second protocol stack includes a second PHY entity;

the sending unit 701 is configured to send the MBS service in a multicast manner by using the first PHY entity, and send the MBS service in a unicast manner by using the second PHY entity.

In an optional manner, the first protocol stack and the second protocol stack have a common MAC entity;

the public MAC entity is used for copying the MAC PDU of the MBS service, transmitting the MAC PDU to the first PHY entity and transmitting the copied MAC PDU to the second PHY entity.

In an optional manner, the first protocol stack and the second protocol stack further have at least one of the following protocol stack entities in common: SDAP entity, PDCP entity, RLC entity.

In an optional manner, the first protocol stack and the second protocol stack have a common SDAP entity;

the public SDAP entity is used for copying the SDAP PDU of the MBS service, transmitting the SDAP PDU to the PDCP entity or the RLC entity in the first protocol stack, and transmitting the copied SDAP PDU to the PDCP entity or the RLC entity in the second protocol stack.

In an alternative, the first protocol stack and the second protocol stack have separate PDCP entities and/or RLC entities.

In an optional manner, the first protocol stack and the second protocol stack have a common PDCP entity;

the public PDCP entity is used for copying the PDCP PDUs of the MBS service, transmitting the PDCP PDUs to the RLC entity in the first protocol stack, and transmitting the copied PDCP PDUs to the RLC entity in the second protocol stack.

In an alternative, the first protocol stack and the second protocol stack further have a common SDAP entity, and the first protocol stack and the second protocol stack have separate RLC entities.

In an alternative, the first protocol stack and the second protocol stack have a common RLC entity;

the common RLC entity is used for copying the RLC PDU of the MBS service, transmitting the RLC PDU to the MAC entity in the first protocol stack and transmitting the copied RLC PDU to the MAC entity in the second protocol stack.

In an optional manner, the first protocol stack and the second protocol stack further have a common SDAP entity and/or PDCP entity.

the common MAC entity is used for mapping the RLC PDUs corresponding to the multicast mode in the first MAC PDU and mapping the RLC PDUs corresponding to the unicast mode in the second MAC PDU.

In an optional manner, the first protocol stack and the second protocol stack have independent MAC entities;

a first MAC entity in the first protocol stack is used for mapping RLC PDUs corresponding to a multicast mode in the first MAC PDUs;

and the second MAC entity in the second protocol stack is used for mapping the RLC PDU corresponding to the multicast mode in the second MAC PDU.

In an optional manner, the first protocol stack and the second protocol stack have independent SDAP entity, PDCP entity, RLC entity, and MAC entity; alternatively, the first and second electrodes may be,

the first protocol stack and the second protocol stack have independent SDAP entities, RLC entities and MAC entities.

In an optional mode, scrambling is carried out on scheduling information of MBS business sent according to a multicast mode through G-RNTI; and scrambling the scheduling information of the MBS service transmitted in a unicast mode through G-RNTI or C-RNTI.

Those skilled in the art should understand that the related description of the transmission apparatus of the MBS service in the embodiment of the present application may be understood by referring to the related description of the transmission method of the MBS service in the embodiment of the present application.

Fig. 8 is a schematic structural diagram of a transmission apparatus of an MBS service provided in an embodiment of the present application, which is applied to a terminal device, and as shown in fig. 8, the transmission apparatus of the MBS service includes:

a receiving unit 801, configured to receive an MBS service in a multicast manner or a unicast manner using a first protocol stack, and receive a first type of service in a unicast manner using a second protocol stack, where the first type of service is different from the MBS service.

In an optional manner, the first protocol stack includes a first PHY entity, and the second protocol stack includes a second PHY entity;

the receiving unit 801 is configured to receive the MBS service in a multicast manner or a unicast manner by using the first PHY entity, and receive the first type of service in a unicast manner by using the second PHY entity.

In an optional manner, the first protocol stack and the second protocol stack have a common MAC entity, and the logical channel identifier of the MBS service has uniqueness within a cell.

In an alternative, the first protocol stack and the second protocol stack have separate MAC entities.

In an optional manner, the apparatus further comprises: a decryption unit (not shown in the figure);

and when the receiving unit receives the MBS service in a multicast mode, the decryption unit decrypts the MBS service by adopting a first secret key configured by network equipment, wherein the first secret key is a multicast secret key.

In an alternative, the first key has an association relationship with at least one of: logical channel identification, DRB identification, PDCP entity.

In an optional manner, the apparatus further comprises: a decryption unit;

and when the receiving unit receives the MBS service in a unicast mode, the decryption unit decrypts the MBS service by adopting a second secret key configured by the network equipment, wherein the second secret key is a multicast secret key or a unicast secret key.

In an alternative, the second key has an association relationship with at least one of: logical channel identification, DRB identification, PDCP entity.

Fig. 9 is a schematic structural diagram of a communication device 900 according to an embodiment of the present application. The communication device may be a terminal device or a network device, and the communication device 900 shown in fig. 9 includes a processor 910, and the processor 910 may invoke and execute a computer program from a memory to implement the method in the embodiment of the present application.

Optionally, as shown in fig. 9, the communication device 900 may also include a memory 920. From the memory 920, the processor 910 can call and run a computer program to implement the method in the embodiment of the present application.

The memory 920 may be a separate device from the processor 910, or may be integrated in the processor 910.

Optionally, as shown in fig. 9, the communication device 900 may further include a transceiver 930, and the processor 910 may control the transceiver 930 to communicate with other devices, and specifically, may transmit information or data to the other devices or receive information or data transmitted by the other devices.

The transceiver 930 may include a transmitter and a receiver, among others. The transceiver 930 may further include one or more antennas.

Optionally, the communication device 900 may specifically be a network device in the embodiment of the present application, and the communication device 900 may implement a corresponding procedure implemented by the network device in each method in the embodiment of the present application, which is not described herein again for brevity.

Optionally, the communication device 900 may specifically be a mobile terminal/terminal device according to this embodiment, and the communication device 900 may implement a corresponding process implemented by the mobile terminal/terminal device in each method according to this embodiment, which is not described herein again for brevity.

Fig. 10 is a schematic structural diagram of a chip of an embodiment of the present application. The chip 1000 shown in fig. 10 includes a processor 1010, and the processor 1010 may call and run a computer program from a memory to implement the method in the embodiment of the present application.

Optionally, as shown in fig. 10, the chip 1000 may further include a memory 1020. From the memory 1020, the processor 1010 may call and execute a computer program to implement the method in the embodiment of the present application.

The memory 1020 may be a separate device from the processor 1010 or may be integrated into the processor 1010.

Optionally, the chip 1000 may further include an input interface 1030. The processor 1010 may control the input interface 1030 to communicate with other devices or chips, and specifically may obtain information or data transmitted by the other devices or chips.

Optionally, the chip 1000 may further include an output interface 1040. The processor 1010 may control the output interface 1040 to communicate with other devices or chips, and may particularly output information or data to the other devices or chips.

Optionally, the chip may be applied to the network device in the embodiment of the present application, and the chip may implement the corresponding process implemented by the network device in each method in the embodiment of the present application, and for brevity, details are not described here again.

Optionally, the chip may be applied to the mobile terminal/terminal device in the embodiment of the present application, and the chip may implement the corresponding process implemented by the mobile terminal/terminal device in each method in the embodiment of the present application, and for brevity, no further description is given here.

It should be understood that the chips mentioned in the embodiments of the present application may also be referred to as a system-on-chip, a system-on-chip or a system-on-chip.

Fig. 11 is a schematic block diagram of a communication system 1100 provided in an embodiment of the present application. As shown in fig. 11, the communication system 1100 includes a terminal device 1110 and a network device 1120.

The terminal device 1110 may be configured to implement the corresponding function implemented by the terminal device in the foregoing method, and the network device 1120 may be configured to implement the corresponding function implemented by the network device in the foregoing method, which is not described herein again for brevity.

It should be understood that the processor of the embodiments of the present application may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method embodiments may be performed by integrated logic circuits of hardware in a processor or by instructions in the form of software. The Processor may be a general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off the shelf Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic, discrete hardware components. The various methods, steps, and logic blocks disclosed in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in connection with the embodiments of the present application may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium is located in a memory, and a processor reads information in the memory and completes the steps of the method in combination with hardware of the processor.

It will be appreciated that the memory in the embodiments of the subject application can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. The non-volatile Memory may be a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically Erasable PROM (EEPROM), or a flash Memory. Volatile Memory can be Random Access Memory (RAM), which acts as external cache Memory. By way of example, but not limitation, many forms of RAM are available, such as Static random access memory (Static RAM, SRAM), dynamic Random Access Memory (DRAM), synchronous Dynamic random access memory (Synchronous DRAM, SDRAM), double Data Rate Synchronous Dynamic random access memory (DDR SDRAM), enhanced Synchronous SDRAM (ESDRAM), synchronous link SDRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory of the systems and methods described herein is intended to comprise, without being limited to, these and any other suitable types of memory.

It should be understood that the above memories are exemplary but not limiting illustrations, for example, the memories in the embodiments of the present application may also be Static Random Access Memory (SRAM), dynamic random access memory (dynamic RAM, DRAM), synchronous Dynamic Random Access Memory (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (enhanced SDRAM, ESDRAM), synchronous Link DRAM (SLDRAM), direct Rambus RAM (DR RAM), and the like. That is, the memory in the embodiments of the present application is intended to comprise, without being limited to, these and any other suitable types of memory.

The embodiment of the application also provides a computer readable storage medium for storing the computer program.

Optionally, the computer-readable storage medium may be applied to the network device in the embodiment of the present application, and the computer program enables the computer to execute the corresponding process implemented by the network device in each method in the embodiment of the present application, which is not described herein again for brevity.

Optionally, the computer-readable storage medium may be applied to the mobile terminal/terminal device in the embodiment of the present application, and the computer program enables the computer to execute the corresponding process implemented by the mobile terminal/terminal device in each method in the embodiment of the present application, which is not described herein again for brevity.

Embodiments of the present application also provide a computer program product, including computer program instructions.

Optionally, the computer program product may be applied to the network device in the embodiment of the present application, and the computer program instructions enable the computer to execute corresponding processes implemented by the network device in the methods in the embodiment of the present application, which are not described herein again for brevity.

Optionally, the computer program product may be applied to the mobile terminal/terminal device in the embodiment of the present application, and the computer program instructions enable the computer to execute the corresponding processes implemented by the mobile terminal/terminal device in the methods in the embodiment of the present application, which are not described herein again for brevity.

The embodiment of the application also provides a computer program.

Optionally, the computer program may be applied to the network device in the embodiment of the present application, and when the computer program runs on a computer, the computer is enabled to execute the corresponding process implemented by the network device in each method in the embodiment of the present application, and for brevity, details are not described here again.

Optionally, the computer program may be applied to the mobile terminal/terminal device in the embodiment of the present application, and when the computer program runs on a computer, the computer executes a corresponding process implemented by the mobile terminal/terminal device in each method in the embodiment of the present application, which is not described herein again for brevity.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

It can be clearly understood by those skilled in the art that, for convenience and simplicity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit.

The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily think of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

A transmission method of multimedia multicast service (MBS) service comprises the following steps:

the network equipment adopts the first protocol stack to send the MBS service according to the multicast mode and adopts the second protocol stack to send the MBS service according to the unicast mode.
The method of claim 1, wherein the first protocol stack comprises a first physical PHY entity and the second protocol stack comprises a second PHY entity;

the network equipment adopts a first protocol stack to send the MBS service according to a multicast mode and adopts a second protocol stack to send the MBS service according to a unicast mode, and the method comprises the following steps:

and the network equipment adopts the first PHY entity to send the MBS service in a multicast mode and adopts the second PHY entity to send the MBS service in a unicast mode.
The method of claim 2, wherein the first and second protocol stacks have a common medium access control, MAC, entity;

the public MAC entity is used for copying the MAC PDU of the MBS service, transmitting the MAC PDU to the first PHY entity and transmitting the copied MAC PDU to the second PHY entity.
The method of claim 3, wherein the first and second protocol stacks further have at least one protocol stack entity in common: a service data adaptation protocol SDAP entity, a packet data convergence protocol PDCP entity and a radio link control RLC entity.
The method of claim 2, wherein the first protocol stack and the second protocol stack have a common SDAP entity;

the public SDAP entity is used for copying the SDAP PDU of the MBS service, transmitting the SDAP PDU to the PDCP entity or the RLC entity in the first protocol stack, and transmitting the copied SDAP PDU to the PDCP entity or the RLC entity in the second protocol stack.
The method of claim 5, wherein the first and second protocol stacks have separate PDCP and/or RLC entities.
The method of claim 2, wherein the first protocol stack and the second protocol stack have a common PDCP entity;

the public PDCP entity is used for copying the PDCP PDU of the MBS service, transmitting the PDCP PDU to the RLC entity in the first protocol stack and transmitting the copied PDCP PDU to the RLC entity in the second protocol stack.
The method of claim 7, wherein the first and second protocol stacks further have a common SDAP entity, and the first and second protocol stacks have separate RLC entities.
The method of claim 2, wherein the first protocol stack and the second protocol stack have a common RLC entity;

the common RLC entity is used for copying the RLC PDU of the MBS service, transmitting the RLC PDU to the MAC entity in the first protocol stack and transmitting the copied RLC PDU to the MAC entity in the second protocol stack.
The method of claim 9, wherein the first and second protocol stacks further have a common SDAP entity and/or PDCP entity.
The method of any of claims 5 to 10, wherein the first and second protocol stacks have a common MAC entity;

the common MAC entity is used for mapping the RLC PDU corresponding to the multicast mode in the first MAC PDU and mapping the RLC PDU corresponding to the unicast mode in the second MAC PDU.
The method of any of claims 5 to 10, wherein the first and second protocol stacks have independent MAC entities;

the first MAC entity in the first protocol stack is used for mapping the RLC PDU corresponding to the multicast mode in the first MAC PDU;

and the second MAC entity in the second protocol stack is used for mapping the RLC PDU corresponding to the multicast mode in the second MAC PDU.
The method of claim 2, wherein,

the first protocol stack and the second protocol stack are provided with an SDAP entity, a PDCP entity, an RLC entity and an MAC entity which are independent; alternatively, the first and second electrodes may be,

the first protocol stack and the second protocol stack have independent SDAP entities, RLC entities and MAC entities.
The method according to any one of claims 1 to 13, wherein the scheduling information for MBS traffic transmitted in a multicast manner is scrambled by a group radio network temporary identity G-RNTI; and scrambling the scheduling information of the MBS service sent in a unicast mode through G-RNTI or cell radio network temporary identifier C-RNTI.
A transmission method of MBS service, the method includes:

the terminal equipment receives MBS service by adopting a first protocol stack according to a multicast mode or a unicast mode, and receives first type service by adopting a second protocol stack according to a unicast mode, wherein the first type service is different from the MBS service.
The method of claim 15, wherein the first protocol stack comprises a first PHY entity and the second protocol stack comprises a second PHY entity;

the terminal equipment receives MBS services by adopting a first protocol stack according to a multicast mode or a unicast mode, and receives first-class services by adopting a second protocol stack according to a unicast mode, and the method comprises the following steps:

and the terminal equipment receives the MBS service by adopting the first PHY entity according to a multicast mode or a unicast mode, and receives the first type of service by adopting the second PHY entity according to a unicast mode.
The method of claim 16, wherein the first protocol stack and the second protocol stack have a common MAC entity, and logical channel identities of the MBS service are unique within a cell.
The method of claim 16, wherein the first and second protocol stacks have independent MAC entities.
The method according to claim 17 or 18, wherein, in case that the terminal device receives the MBS service in multicast mode,

and the terminal equipment decrypts the MBS service by adopting a first secret key configured by the network equipment, wherein the first secret key is a multicast secret key.
The method of claim 19, wherein the first key has an association relationship with at least one of: a logical channel identifier, a Data Radio Bearer (DRB) identifier and a PDCP entity.
The method according to claim 17 or 18, wherein, in case the terminal device receives the MBS service in unicast,

and the terminal equipment decrypts the MBS service by adopting a second secret key configured by the network equipment, wherein the second secret key is a multicast secret key or a unicast secret key.
The method of claim 21, wherein the second key has an association relationship with at least one of: logical channel identification, DRB identification, PDCP entity.
A transmission apparatus for MBS service, the apparatus comprising:

and the sending unit is used for sending the MBS service by adopting a first protocol stack according to a multicast mode and sending the MBS service by adopting a second protocol stack according to a unicast mode.
The apparatus of claim 23, wherein the first protocol stack comprises a first PHY entity and the second protocol stack comprises a second PHY entity;

the sending unit is configured to send the MBS service in a multicast manner by using the first PHY entity, and send the MBS service in a unicast manner by using the second PHY entity.
The apparatus of claim 24, wherein the first and second protocol stacks have a common MAC entity;

the public MAC entity is used for copying the MAC PDU of the MBS service, transmitting the MAC PDU to the first PHY entity and transmitting the copied MAC PDU to the second PHY entity.
The apparatus of claim 25, wherein the first and second protocol stacks further have at least one protocol stack entity in common: SDAP entity, PDCP entity, RLC entity.
The apparatus of claim 24, wherein the first and second protocol stacks have a common SDAP entity;

the public SDAP entity is used for copying the SDAP PDU of the MBS service, transmitting the SDAP PDU to a PDCP entity or an RLC entity in the first protocol stack, and transmitting the copied SDAP PDU to the PDCP entity or the RLC entity in the second protocol stack.
The apparatus of claim 27, wherein the first and second protocol stacks have separate PDCP entities and/or RLC entities.
The apparatus of claim 24, wherein the first and second protocol stacks have a common PDCP entity;

the public PDCP entity is used for copying the PDCP PDU of the MBS service, transmitting the PDCP PDU to the RLC entity in the first protocol stack and transmitting the copied PDCP PDU to the RLC entity in the second protocol stack.
The apparatus of claim 29, wherein the first and second protocol stacks further have a common SDAP entity, and the first and second protocol stacks have separate RLC entities.
The apparatus of claim 24, wherein the first protocol stack and the second protocol stack have a common RLC entity;

the common RLC entity is used for copying the RLC PDU of the MBS service, transmitting the RLC PDU to the MAC entity in the first protocol stack and transmitting the copied RLC PDU to the MAC entity in the second protocol stack.
The apparatus of claim 31, wherein the first and second protocol stacks further have a common SDAP entity and/or PDCP entity.
The apparatus of any of claims 27-32, wherein the first and second protocol stacks have a common MAC entity;

the common MAC entity is used for mapping the RLC PDUs corresponding to the multicast mode in the first MAC PDU and mapping the RLC PDUs corresponding to the unicast mode in the second MAC PDU.
The apparatus of any of claims 27-32, wherein the first and second protocol stacks have independent MAC entities;

the first MAC entity in the first protocol stack is used for mapping the RLC PDU corresponding to the multicast mode in the first MAC PDU;

and the second MAC entity in the second protocol stack is used for mapping the RLC PDU corresponding to the multicast mode in the second MAC PDU.
The apparatus of claim 24, wherein,

the first protocol stack and the second protocol stack are provided with an SDAP entity, a PDCP entity, an RLC entity and an MAC entity which are independent; alternatively, the first and second electrodes may be,

the first protocol stack and the second protocol stack have independent SDAP entities, RLC entities and MAC entities.
The apparatus according to any of claims 23 to 35, wherein scheduling information for MBS services transmitted in a multicast manner is scrambled by G-RNTI; and scrambling the scheduling information of the MBS service transmitted in a unicast mode through G-RNTI or C-RNTI.
A transmission apparatus for MBS service, the apparatus comprising:

a receiving unit, configured to receive, by using a first protocol stack, an MBS service in a multicast mode or a unicast mode, and receive, by using a second protocol stack, a first type of service in a unicast mode, where the first type of service is different from the MBS service.
The apparatus of claim 37, wherein the first protocol stack comprises a first PHY entity and the second protocol stack comprises a second PHY entity;

the receiving unit is configured to receive the MBS service in a multicast manner or a unicast manner by using the first PHY entity, and receive the first type of service in a unicast manner by using the second PHY entity.
The apparatus of claim 38, wherein the first protocol stack and the second protocol stack have a common MAC entity, and wherein logical channel identifiers of the MBS services are unique within a cell.
The apparatus of claim 38, wherein the first and second protocol stacks have independent MAC entities.
The apparatus of claim 39 or 40, wherein the apparatus further comprises: a decryption unit;

and when the receiving unit receives the MBS service in a multicast mode, the decryption unit decrypts the MBS service by adopting a first secret key configured by the network equipment, wherein the first secret key is a multicast secret key.
The apparatus of claim 41, wherein the first key has an association with at least one of: logical channel identification, DRB identification, PDCP entity.
The apparatus of claim 39 or 40, wherein the apparatus further comprises: a decryption unit;

and when the receiving unit receives the MBS service in a unicast mode, the decryption unit decrypts the MBS service by adopting a second secret key configured by the network equipment, wherein the second secret key is a multicast secret key or a unicast secret key.
The apparatus of claim 43, wherein the second key has an association with at least one of: logical channel identification, DRB identification, PDCP entity.
A network device, comprising: a processor and a memory for storing a computer program, the processor being configured to invoke and execute the computer program stored in the memory to perform the method of any of claims 1 to 14.
A terminal device, comprising: a processor and a memory for storing a computer program, the processor being configured to invoke and execute the computer program stored in the memory to perform the method of any of claims 15 to 22.
A chip, comprising: a processor for calling and running a computer program from a memory so that a device on which the chip is installed performs the method of any one of claims 1 to 14.
A chip, comprising: a processor for calling and running a computer program from a memory so that a device on which the chip is installed performs the method of any one of claims 15 to 22.
A computer-readable storage medium storing a computer program for causing a computer to perform the method of any one of claims 1 to 14.
A computer-readable storage medium storing a computer program for causing a computer to perform the method of any one of claims 15 to 22.
A computer program product comprising computer program instructions to cause a computer to perform the method of any one of claims 1 to 14.
A computer program product comprising computer program instructions to cause a computer to perform the method of any of claims 15 to 22.
A computer program for causing a computer to perform the method of any one of claims 1 to 14.
A computer program for causing a computer to perform the method of any one of claims 15 to 22.