Patent Description:
<NUM> mobile communication technologies define broad frequency bands such that high transmission rates and new services are possible, and can be implemented not only in "Sub <NUM>" bands such as <NUM>, but also in "Above <NUM>" bands referred to as mmWave including <NUM> and <NUM>. In addition, it has been considered to implement <NUM> mobile communication technologies (referred to as Beyond <NUM> systems) in terahertz bands (for example, <NUM> to 3THz bands) in order to accomplish transmission rates fifty times faster than <NUM> mobile communication technologies and ultra-low latencies one-tenth of <NUM> mobile communication technologies.

At the beginning of the development of <NUM> mobile communication technologies, in order to support services and to satisfy performance requirements in connection with enhanced Mobile BroadBand (eMBB), Ultra Reliable Low Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), there has been ongoing standardization regarding beamforming and massive MIMO for mitigating radio-wave path loss and increasing radio-wave transmission distances in mmWave, supporting numerologies (for example, operating multiple subcarrier spacings) for efficiently utilizing mmWave resources and dynamic operation of slot formats, initial access technologies for supporting multibeam transmission and broadbands, definition and operation of BWP (Bandwidth Part), new channel coding methods such as a LDPC (Low Density Parity Check) code for large amount of data transmission and a polar code for highly reliable transmission of control information, L2 pre-processing, and network slicing for providing a dedicated network specialized to a specific service.

Currently, there are ongoing discussions regarding improvement and performance enhancement of initial <NUM> mobile communication technologies in view of services to be supported by <NUM> mobile communication technologies, and there has been physical layer standardization regarding technologies such as V2X (Vehicle-to-everything) for aiding driving determination by autonomous vehicles based on information regarding positions and states of vehicles transmitted by the vehicles and for enhancing user convenience, NR-U (New Radio Unlicensed) aimed at system operations conforming to various regulationrelated requirements in unlicensed bands, NR UE Power Saving, Non-Terrestrial Network (NTN) which is UE-satellite direct communication for providing coverage in an area in which communication with terrestrial networks is unavailable, and positioning.

Moreover, there has been ongoing standardization in air interface architecture/protocol regarding technologies such as Industrial Internet of Things (IIoT) for supporting new services through interworking and convergence with other industries, IAB (Integrated Access and Backhaul) for providing a node for network service area expansion by supporting a wireless backhaul link and an access link in an integrated manner, mobility enhancement including conditional handover and DAPS (Dual Active Protocol Stack) handover, and two-step random access for simplifying random access procedures (<NUM>-step RACH for NR). There also has been ongoing standardization in system architecture/service regarding a <NUM> baseline architecture (for example, service based architecture or service based interface) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) for receiving services based on UE positions.

As <NUM> mobile communication systems are commercialized, connected devices that have been exponentially increasing will be connected to communication networks, and it is accordingly expected that enhanced functions and performances of <NUM> mobile communication systems and integrated operations of connected devices will be necessary. To this end, new research is scheduled in connection with eXtended Reality (XR) for efficiently supporting AR (Augmented Reality), VR (Virtual Reality), MR (Mixed Reality) and the like, <NUM> performance improvement and complexity reduction by utilizing Artificial Intelligence (AI) and Machine Learning (ML), AI service support, metaverse service support, and drone communication.

Furthermore, such development of <NUM> mobile communication systems will serve as a basis for developing not only new waveforms for providing coverage in terahertz bands of <NUM> mobile communication technologies, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), array antennas and large-scale antennas, metamaterial-based lenses and antennas for improving coverage of terahertz band signals, high-dimensional space multiplexing technology using OAM (Orbital Angular Momentum), and RIS (Reconfigurable Intelligent Surface), but also full-duplex technology for increasing frequency efficiency of <NUM> mobile communication technologies and improving system networks, AI-based communication technology for implementing system optimization by utilizing satellites and AI (Artificial Intelligence) from the design stage and internalizing end-to-end AI support functions, and next-generation distributed computing technology for implementing services at levels of complexity exceeding the limit of UE operation capability by utilizing ultra-high-performance communication and computing resources.

Document "Nokia, Nokia Shanghai Bell: 'Further clarifying of the Functional architecture', 3GPP Draft; S6-<NUM>, vol. SA WG6, <NUM> May <NUM> (<NUM>-<NUM>-<NUM>), pages <NUM>-<NUM>", XP052012653, discloses the operation of an MC gateway.

With MBMS features, a network provider can broadcast group communications for mission critical services more efficiently than compared to a unicast technology. As per 3GPP TR <NUM>-<NUM>, the MC clients can reside on non-3GPP devices and access an MC system through an MC gateway UE. Basically, these devices would not be able to avail the MBMS services, since they do not have access to a 3GPP network. Since the MC gateway UE has access to a 3GPP network, the MC gateway UE shall receive the communications over an MBMS bearer and forward the same to the MC clients behind it.

Accordingly, an aspect of the disclosure is to provide systems and methods of supporting Multimedia Broadcast Multicast Services (MBMS) features for mission critical (MC) service (MCX) clients residing on non 3rd generation partnership project (3GPP) devices accessing an MC System through an MC Gateway user equipment (UE) as specified in 3GPP TR <NUM>-<NUM>. The proposed methods assist the MC clients residing on non-3GPP devices to receive an MC communication over MBMS bearer without wasting network resources, hence, the MC system can operate in an efficient way to improve MBMS services. The proposed methods require only minimal or no changes at an MC service server side in order to support MC communication over the MBMS bearer for the MC clients residing on non 3GPP devices.

In accordance with an aspect of the disclosure, methods for handling Multimedia Broadcast Multicast Services (MBMS) in a wireless network is provided. The method includes receiving, by a mission critical (MC) gateway (GW) user equipment (UE), an MC gateway MBMS bearer announcement from an MC client in response to receiving information associated with an MBMS bearer and a service description associated with the MBMS bearer from an MC service server. The MC GW MBMS bearer announcement comprises MBMS bearer related information. Further, the method includes storing, by the MC gateway UE, information associated with an identifier at the MC gateway UE in response to receiving the MC gateway MBMS bearer announcement from the MC client. The MC gateway UE uses the identifier and the information to activate for monitoring the MBMS bearer by the MC gateway UE. Further, the method includes sending, by the MC GW UE, an MBMS listening status report to the MC client based on the MC GW MBMS bearer announcement. Further, the method includes establishing, by the MC gateway UE, a communication channel with the MC client based on a parameter to receive an MC service data from the MC gateway UE, wherein the MC gateway UE forwards the MC service data to the MC client.

In an embodiment, further, the method includes sending, by the MC gateway UE, an MC GW MBMS bearer quality report to the MC client. Further, the method includes receiving, by the MC gateway UE, the MBMS listening status report from the MC client based on the MC GW MBMS bearer quality report to send or forward to the MC service server. The MBMS listening status report comprises at least one of an MC GW MBMS bearer quality report and information about neighboring MBMS bearer.

In an embodiment, further, the method includes receiving, by the MC gateway UE, an MC GW MapGroupToBearer request message from the MC client in response to receiving a MapGroupToBearer message, at the MC client, from an MC service server over a previously activated MBMS bearer, where the MC GW MapGroupToBearer request message comprises details comprised in the MapGroupToBearer message. Further, the method includes maintaining, by the MC gateway UE, an association between a GW MC service identity (ID) and corresponding MBMS sub channel based on the MC GW MapGroupToBearer request message. Further, the method includes sending, by the MC gateway UE, an MC GW MapGroupToBearer response message to the MC client based on the MC GW MapGroupToBearer request message, where the MC GW MapGroupToBearer response message comprises details of non 3rd generation partnership project (3GPP) transport communication related parameters. Further, the method includes establishing, by the MC client, the communication channel with the MC gateway UE based on the non 3GPP transport communication related parameters to receive an MC service group communication data from the MC gateway UE. Further, the method includes sending, by the MC gateway UE, a downlink media received over the MBMS bearer to the MC client.

In an embodiment, further, the method includes receiving, by the MC gateway UE, an MBMS suspension indication message from a network, where the MBMS suspension reporting instruction message is included in an MBMS bearer announcement message. Further, the method includes sending, by the MC gateway UE, an MC GW MBMS suspension indication to the MC client, where the MC client sends an MBMS suspension report to the MC service server via the MC gateway UE based on the MBMS suspension reporting instruction message and the MC GW MBMS suspension indication.

In an embodiment, the MC client resides on a non-3GPP device.

In an embodiment, the MapGroupToBearer message comprises association information between at least one event and the MBMS bearer, where the MapGroupToBearer message comprises an MC service group ID, information about a media stream identifier of the activated MBMS bearer, and an identifier of the MBMS bearer broadcasting the at least one event.

In an embodiment, the MC GW UE sends the MBMS listening status report to the MC client upon determining that the MC GW UE is entering or is in a service area of at least one announced Temporary Mobile Group Identity (TMGI) to indicate that the MC GW UE can receive the media or signaling or application data over the MBMS bearer.

In accordance with another aspect of the disclosure, method for handling MBMS in a wireless network is provided. The method includes sending, by an MC client, an MC GW MBMS bearer announcement to an MC gateway UE in response to receiving information associated with an MBMS bearer and a service description associated with the MBMS bearer from an MC service server. The MC GW MBMS bearer announcement comprises MBMS bearer related information. Further, the method includes receiving, by the MC client, an MBMS listening status report from the MC gateway UE based on the MC GW MBMS bearer announcement. Further, the method includes establishing, by the MC client, a communication channel with the MC gateway UE based on at least one parameter to receive MC service data from the MC gateway UE. The MC gateway UE forwards the MC service data to the MC client over the communication channel.

In an embodiment, further, the method includes sharing, by the MC client, the MBMS listening status report to the MC service server based on the MC GW MBMS listening status report, wherein the MBMS listening status report indicates that the MC service client receives the media over the MBMS bearer.

In an embodiment, further, the method includes receiving, by the MC client, an MC GW MBMS bearer quality report from the MC gateway UE. Further, the method includes sharing, by the MC client, the MBMS listening status report to the MC service server based on the MC GW MBMS bearer quality report, wherein the MBMS listening status report comprises at least one of an MC GW MBMS bearer quality report and information about neighboring MBMS bearer.

In an embodiment, further, the method includes receiving, by the MC client, a MapGroupToBearer message from the MC service server over a previously activated MBMS bearer. Further, the method includes sending, by the MC client, an MC GW MapGroupToBearer request message to the MC gateway UE, wherein the MC GW MapGroupToBearer request message comprises details comprised in the MapGroupToBearer message. Further, the method includes receiving, by the MC client, an MC GW MapGroupToBearer response message from the MC gateway UE based on the MC GW MapGroupToBearer request message, wherein the MC GW MapGroupToBearer response message comprises details of non 3GPP transport communication related parameters. Further, the method includes establishing, by the MC client, the communication channel with the MC gateway UE based on the non 3GPP transport communication related parameters to receive an MC service group communication data from the MC gateway UE. Further, the method includes receiving, by the MC client, a downlink media from the MC gateway UE.

In an embodiment, further, the method includes receiving, by the MC client, an MBMS suspension reporting instruction message from the MC service server, wherein the MBMS suspension reporting instruction message is included in an MBMS bearer announcement message. Further, the method includes receiving, by the MC client, an MC GW MBMS suspension indication from the MC gateway UE. Further, the method includes sending, by the MC client, an MBMS suspension report to the MC service server via the MC gateway UE based on the MBMS suspension reporting instruction message and the MC GW MBMS suspension indication.

Accordingly, the embodiments herein provide an MC GW UE for handling MBMS in a wireless network. The MC GW UE includes an MBMS controller coupled with a memory and a processor. The MBMS controller is configured to receive an MC gateway MBMS bearer announcement from an MC client in response to receiving information associated with an MBMS bearer and a service description associated with the MBMS bearer from an MC service server. The MC GW MBMS bearer announcement comprises MBMS bearer related information. Further, the MBMS controller is configured to store information associated with an identifier at the MC gateway UE in response to receiving the MC gateway MBMS bearer announcement from the MC client. The MC gateway UE uses the identifier and the information to activate monitoring of the MBMS bearer by the MC gateway UE. Further, the MBMS controller is configured to send an MBMS listening status report to the MC client based on the MC GW MBMS bearer announcement. Further, the MBMS controller is configured to establish a communication channel with the MC client based on a parameter to receive the MC service data from the MC gateway UE. The MC gateway UE forwards the MC service data to the MC client over the communication channel.

Accordingly, the embodiments herein provide an MC client for handling MBMS in a wireless network. The MC client includes an MBMS controller coupled with a memory and a processor. The MBMS controller is configured to send an MC GW MBMS bearer announcement to an MC gateway UE in response to receiving information associated with an MBMS bearer and a service description associated with the MBMS bearer from an MC service server, wherein the MC GW MBMS bearer announcement comprises MBMS bearer related information. Further, the MBMS controller is configured to receive an MBMS listening status report from the MC gateway UE based on the MC GW MBMS bearer announcement. Further, the MBMS controller is configured to establish a communication channel with the MC gateway UE based on at least one parameter to receive MC service data from the MC gateway UE. The MC gateway UE forwards the MC service data to the MC client over the communication channel.

Other aspects, advantages, and salient features of the disclosure will become apparent to those skilled in the art from the following detailed description, which, taken in conjunction with the annexed drawings discloses various embodiments of the disclosure.

Procedures covered in this patent aids the MC clients residing on non-3GPP devices to receive the MC communication over MBMS bearer. If these procedures were not supported in standards, then the MC system will always have to establish unicast communication with the MC clients residing on non-3GPP devices through MC gateway UE which leads to wastage of network resources and more over the air traffic. Also this invention proposed methods which requires only minimal or no changes at the MC service server side in order to support MC communication over MBMS bearer for the MC clients residing on non 3GPP devices. Changes required for supporting MBMS are confined between the MC clients and the MC gateway UE.

The embodiments herein achieve methods for handling Multimedia Broadcast Multicast Services (MBMS) in a wireless network. The method includes receiving, by a mission critical (MC) gateway (GW) user equipment (UE), an MC gateway MBMS bearer announcement from an MC client in response to receiving information associated with an MBMS bearer and a service description associated with the MBMS bearer from an MC service server. The MC GW MBMS bearer announcement comprises MBMS bearer related information. Further, the method includes storing, by the MC gateway UE, information associated with an identifier at the MC gateway UE in response to receiving the MC gateway MBMS bearer announcement from the MC client. The MC gateway UE uses the identifier and the information to activate for monitoring the MBMS bearer by the MC gateway UE. Further, the method includes sending, by the MC GW UE, an MBMS listening status report to the MC client based on the MC GW MBMS bearer announcement. Further, the method includes establishing, by the MC gateway UE, a communication channel with the MC client based on a parameter to receive an MC service data from the MC gateway UE, wherein the MC gateway UE forwards the MC service data to the MC client.

The proposed methods assist the MC clients residing on non-3GPP devices to receive an MC communication over MBMS bearer without wasting network resources, hence, the MC system can operate in an efficient way to improve MBMS services. Some of the proposed methods require only minimal or no changes at an MC service server side in order to support MC communication over the MBMS bearer for the MC clients residing on non 3rd generation partnership project (3GPP) devices.

Referring now to the drawings, and more particularly to <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, and <FIG>, where similar reference characters denote corresponding features consistently throughout the figures, there are shown at least one embodiment.

3GPP TR <NUM>-<NUM> studies about the key issues and solutions to enable MC clients (<NUM>) residing on the non 3GPP devices (<NUM>) to access an MC system through an MC gateway UE (<NUM>). The MC gateway UE (<NUM>) resides on the device, which has access a 3GPP network and it acts a bridge connecting the MC clients (<NUM>) on the non 3GPP devices (<NUM>) and the MC system. From hereafter, the term MC clients (<NUM>) when used herein, it always refers to the MC clients (<NUM>) residing on the non 3GPP devices (<NUM>). Embodiments herein disclose information flows and procedures for MBMS usage that applies to MC services and how the MC gateway UE (<NUM>) can be allowed to use the MBMS bearer for Mission critical services related communications and forward the data received over the MBMS bearer to the intended MC clients (<NUM>) it is serving. Embodiments herein discuss the following approaches and the related procedures for supporting MBMS usage for the MC clients (<NUM>) residing on the non 3GPP devices (<NUM>):.

With this approach, the MC servers intending to use the MBMS bearer for communication do not have to keep track of the MC clients (<NUM>) residing on the non 3GPP devices (<NUM>) and treat them specially during the MBMS bearer usage.

Use of pre-established bearers: 3GPP TS <NUM> Clause <NUM>. <NUM> specifies the procedures for using the pre-established MBMS bearers. In this case, the MC service server (<NUM>) pre-establishes MBMS bearer(s) in certain pre-configured areas before the initiation of the group communication session. When the user originates a request for a group communication session for one of these areas, the pre-established MBMS bearer(s) is used for the downlink (DL) media transmission. In Approach <NUM>, embodiments herein propose how the pre-established MBMS bearer can be used when there are MC clients (<NUM>) accessing the MC system via the MC gateway UE (<NUM>) and without any changes at the MC system side. The MC system will be totally transparent about the fact that there are MC clients (<NUM>) which are residing on the non 3GPP devices (<NUM>). The MC system pre-establishes the MBMS bearers and announces the same to the MC clients (<NUM>).

Whenever the MC clients (<NUM>) receives the MBMS bearer announcement for the pre-stablished MBMS bearer from the MC system, the MC clients (<NUM>) stores temporary mobile group identities (TMGIs), service area and other info about the MBMS bearer(s), the MC service UE starts to monitor the TMGI(s). Since the MC client (<NUM>) is residing on the non 3GPP devices (<NUM>), it sends the MC GW location reporting configuration to the MC gateway UE (<NUM>) in order to fetch the details of the location information related to a 3GPP access network (MBMS Service Area Identities (MBMS SAIs), MBMS single frequency network (MBSFN)) from the MC gateway UE (<NUM>). Based on the location report received from the MC gateway UE (<NUM>), the MC client can monitor whether they are entering into any of the MBMS SAIs received in the MBMS bearer announcement from the MC System. On detection of entering into the MBMS Service Area, the MC client (<NUM>) requests the MC gateway UE (<NUM>) to start listening on the MBMS bearer by sending the required details.

<FIG> illustrates the procedure of how an MC client requests an MC gateway UE to start listening on the MBMS bearer according to an embodiment of the disclosure. In this procedure, the MC client (<NUM>) starts monitoring the MBMS service areas based on the location information received from the MC gateway UE (<NUM>).

Below are the pre-conditions for the procedures explained in the <FIG>.

The MC client (<NUM>) has been configured with the necessary parameters needed for connectivity with the MC gateway UE (<NUM>).

The MC client (<NUM>) has been receiving the 3GPP access network related location information from the MC gateway UE (<NUM>).

Operation 1a, the MC service server (<NUM>) determines to activate the MBMS bearer. The activation of the MBMS bearer is done on the MB2-C reference point and according to 3GPP TS <NUM>. The bearer will be used for the MC communication media.

Operation 1b, optionally, the MC service server (<NUM>) may also activate an MBMS bearer dedicated for application level control signaling. The activation of the MBMS bearer is done on MB2-C reference point and according to 3GPP TS <NUM>.

Operation <NUM>, the MC service server (<NUM>) passes the MBMS bearer info for the service description associated with the pre-established MBMS bearer to the MC service client through the MC gateway UE (<NUM>). Optionally, the MC service server (<NUM>) may pass the MBMS bearer info for the service description associated with the pre-established floor control MBMS bearer to the MC service client. The MC service client obtains the TMGI, identifying the MBMS bearer, from the service description.

Operation <NUM>, the MC client (<NUM>) stores the MBMS bearer related information and starts monitoring whether it is entering into any of MBMS service areas received in the MBMS bearer announcement.

Operation <NUM>, the MC client (<NUM>) that enters or is in the service area of at least one announced TMGI MC client (<NUM>) requests the MC gateway UE (<NUM>) to start listening on the MBMS bearer by sending MC GW MBMS listening request containing the details of the MBMS bearer.

Operation <NUM>, the MC gateway UE (<NUM>) confirms the MC client (<NUM>) that it is able to listen on the MBMS bearer by sending the MC GW MBMS listening status report/notify. The MC GW MBMS listening status report also contains the details of the non 3GPP transport communication related parameters.

Operation <NUM>, the MC client (<NUM>) establishes the communication channel with the MC gateway UE (<NUM>) based on the parameters received in operation <NUM> to receive the MC service data from the MC gateway UE (<NUM>). The MC gateway UE (<NUM>) forwards the MC service data it received over the MBMS bearer from the MC service server (<NUM>) to the MC client (<NUM>) over the communication channel.

Operation <NUM>, the MC Client (<NUM>) sends the MBMS listening status report to the MC service server (<NUM>) indicating that it is able to receive the media over MBMS, whereby the MC service server (<NUM>) may decide to use the MBMS bearer instead of unicast bearer for MC communication sessions.

Operation <NUM>, the MC service group communication session is established.

Operation <NUM>, as the MC service server (<NUM>) transmits the media over the MBMS bearer, the media packets are detected and delivered to the MC service client.

Operation <NUM>, the MC gateway UE (<NUM>) forwards the received media to the MC client (<NUM>).

Between MC client (<NUM>) and MC gateway UE (<NUM>) the communication mechanism could be Unicast, multicast or broadcast.

<FIG> illustrates the procedure of how an MC client shares the details of MBMS service announcement to an MC gateway UE according to an embodiment of the disclosure. In this procedure, the MC client (<NUM>) do not have to monitor the location information to detect whether it is entering into the MBMS service area or not. The MC gateway UE (<NUM>) monitors and starts listening on the MBMS bearer.

Operation 1a, the MC service server (<NUM>) determines to activate MBMS bearer. The activation of the MBMS bearer is done on the MB2-C reference point and according to 3GPP TS <NUM>. The bearer will be used for the MC communication media.

Operation <NUM>, the MC service server (<NUM>) passes the MBMS bearer info for the service description associated with the pre-established MBMS bearer to the MC service client through the MC gateway UE (<NUM>). Optionally the MC service server (<NUM>) may pass the MBMS bearer info for the service description associated with the pre-established floor control MBMS bearer to the MC service client.

Operation <NUM>, the MC client (<NUM>) sends the MC GW MBMS Bearer announcement to the MC gateway UE (<NUM>) containing the MBMS bearer related information.

Operation <NUM>, the MC gateway UE (<NUM>) stores the information associated with the TMGI(s). The MC gateway UE (<NUM>) uses the TMGI and other MBMS bearer related information to activate the monitoring of the MBMS bearer by the MC gateway UE (<NUM>).

Operation <NUM>, the MC gateway UE (<NUM>) that enters or is in the service area of at least one announced TMGI notifies to the MC client (<NUM>) that it can receive media over MBMS by sending the MC GW MBMS listening status report/notify. The MC GW MBMS listening status report also contains the details of the non 3GPP transport communication related parameters.

Operation <NUM>, the MC Client (<NUM>) sends the MBMS listening status report to the MC Server indicating that it is able to receive the media over the MBMS, whereby the MC service server (<NUM>) may decide to use the MBMS bearer instead of unicast bearer for MC communication sessions.

Operation <NUM>, as the MC service server (<NUM>) transmits the media over the MBMS bearer, the media packets are detected and delivered to the MC gateway UE (<NUM>) over the MBMS bearer.

Between the MC client (<NUM>) and the MC gateway UE (<NUM>), the communication mechanism could be Unicast, multicast or broadcast.

Use of dynamic MBMS bearer establishment:
Dynamic MBMS bearer establishment procedure flows are same as the pre-established bearer announcement procedures but with the following difference: the MBMS bearer establishment is initiated before the start of the MC service communication set up or it is initiated after the MC service communication is set up. <FIG> and <FIG> illustrate the mechanism of dynamic MBMS bearer establishments.

<FIG> illustrates the procedure of how an MC client requests an MC gateway UE to start listening on the MBMS bearer according to an embodiment of the disclosure. In this procedure, the MC client (<NUM>) starts monitoring the MBMS service areas based on the location information received from MC gateway UE (<NUM>).

The MC client (<NUM>) has been receiving the 3GPP access network related location information from MC gateway UE (<NUM>).

Operation <NUM>, the downlink data is sent by unicast delivery.

Operation <NUM>, the MC gateway UE (<NUM>) forwards the MC service group communication data to the MC client (<NUM>).

Operation <NUM>, the MC service server (<NUM>) establishes the MBMS bearer(s) for the group communication session according to the procedures defined in 3GPP TS <NUM>. Service description associated with the MBMS bearer(s) is returned from the broadcast multimedia service center (BM-SC).

Operation <NUM>, the MC service server (<NUM>) provides service description information associated with the MBMS bearer to the MC client (<NUM>) residing on the non 3GPP devices (<NUM>) via the MC gateway UE (<NUM>). The MC client (<NUM>) obtains the TMGI from the announcement message. This message may be sent on an application level control signaling bearer.

Operation <NUM>, the MC client (<NUM>) that enters or is in the service area of at least one announced TMGI, requests the MC gateway UE (<NUM>) to start listening on the MBMS bearer by sending MC GW MBMS listening request containing the details of the MBMS bearer.

Operation <NUM>, the MC client (<NUM>) establishes the communication channel with the MC gateway UE (<NUM>) based on the parameters received in operation <NUM> to receive the MC service data from the MC gateway UE (<NUM>). The MC gateway UE (<NUM>) forwards the MC service data it received over the MBMS bearer from the MC service server (<NUM>) to the MC client over the communication channel.

Operation <NUM>, the MC client (<NUM>) sends the MBMS listening status report to the MC service server (<NUM>) indicating that it is able to receive the media over the MBMS, whereby the MC service server (<NUM>) may decide to use the MBMS bearer instead of unicast bearer for the MC communication sessions.

Operation <NUM>, the MC service group communication session via dynamic MBMS bearer(s) is established.

<FIG> illustrates the procedure of how an MC client shares the details of MBMS service announcement to an MC gateway UE according to an embodiment of the disclosure. In this procedure, the MC client (<NUM>) does not have to monitor the location information to detect whether it is entering into the MBMS service area or not. The MC gateway UE (<NUM>) monitors and starts listening on the MBMS bearer.

Operation <NUM>, the MC service server (<NUM>) establishes the MBMS bearer(s) for the group communication session according to the procedures defined in 3GPP TS <NUM>. Service description associated with the MBMS bearer(s) is returned from the BM-SC.

Operation <NUM>, the MC service server (<NUM>) provides the service description information associated with the MBMS bearer to the MC client (<NUM>) residing on the non 3GPP devices (<NUM>) via the MC gateway UE (<NUM>). The MC client (<NUM>) obtains the TMGI from the announcement message. This message may be sent on an application level control signaling bearer.

Operation <NUM>, the MC client (<NUM>) sends the MC GW MBMS bearer announcement to the MC gateway UE (<NUM>) containing the MBMS bearer related information.

Operation <NUM>, the MC gateway UE (<NUM>) that enters or is in the service area of at least one announced TMGI notifies to the MC client (<NUM>) that it can receive media over MBMS by sending the MC GW MBMS listening status report/notify. The MC GW MBMS Listening Status Report also contains the details of the non 3GPP transport communication related parameters.

Operation <NUM>, the MC Client (<NUM>) sends the MBMS listening status report to the MC server indicating that it is able to receive the media over MBMS, whereby the MC service server (<NUM>) may decide to use the MBMS bearer instead of unicast bearer for MC communication sessions.

The MC gateway UE (<NUM>) is the entity which has access to the 3GPP access network and can listen on the MBMS bearers on behalf of the MC clients (<NUM>) it is serving. These MC clients (<NUM>) can be either located in the MC gateway UE (<NUM>) or in the non 3GPP devices (<NUM>) connected to the MC gateway UE (<NUM>) via the non-3GPP access. When the MBMS bearer is used for MC communication, details of the MBMS bearer are sent to the MC clients (<NUM>). The MC gateway UE (<NUM>) is unaware of MBMS bearer details until it is shared by the MC Clients (<NUM>). The MC client (<NUM>) needs to share the MBMS bearer control messages to the MC gateway UE (<NUM>) to allow the MC gateway UE (<NUM>) to handle the MBMS transmission on behalf of MC clients (<NUM>). Following messages which are received from MC server by the MC clients' (<NUM>) needs to be shared with the MC gateway UE (<NUM>):.

Table <NUM> describes the information flow from the MC client (<NUM>) to the MC gateway UE (<NUM>) for the MC GW MBMS bearer announcement.

Table <NUM> describes the information flow from the MC gateway UE (<NUM>) to the MC Client (<NUM>) for the MC GW MBMS listening status report/notify.

Table <NUM> describes the information flow to associate an MC push to talk (MCPTT) group communication to an MBMS bearer. It is sent from the MC client (<NUM>) hosting MCPTT service to the MC gateway UE (<NUM>).

Table <NUM> describes the information flow to associate an MCVideo group communication to an MBMS bearer. It is sent from the MC client (<NUM>) hosting MCVideo service to the MC gateway UE (<NUM>).

In general, the MC GW MapGroupToBearer contains all the information needed for the MC gateway UE (<NUM>) to identify the different the different group communications over the same MBMS bearer. Generically, Table <NUM> describes the information to be sent from MC client (<NUM>) to the MC gateway UE (<NUM>).

Table <NUM> describes the information flow from the MC gateway UE (<NUM>) to the MC client (<NUM>) for the MC GW MBMS bearer suspension indication.

Table <NUM> describes the information flow from the MC gateway UE (<NUM>) to the MC client (<NUM>) for the MC GW MapGroupToBearer Response.

Table <NUM> describes the information flow from the MC client (<NUM>) to the MC gateway UE (<NUM>) for the MC GW MBMS bearer Listening Request.

Table <NUM> describes the information flow from the MC gateway UE (<NUM>) to the MC client (<NUM>) for the MC GW MBMS bearer quality report.

The MC service server (<NUM>) may use an MBMS bearer for application level control signaling, according to this subclause. An MBMS bearer for application level control signaling is typically used for the purposes beyond the benefit for using MBMS for resource efficiency, e.g., for improved MC service performance (KPIs), handling of high load scenarios.

The MBMS bearer for application level control signaling may be used to transmit the following messages:.

The MBMS bearer for application level control signaling is activated in a service area that is larger than the estimated service for media bearers. The service area for the media bearers mainly based on counting of group members in each defined service area. The MBMS bearer for application level control signaling is also activated with a quality of service (QoS) that is better than MBMS media bearers since the packet loss requirements are much stricter.

The MC client (<NUM>) shall not send responses to group-addressed application level control signaling unless instructed or configured to respond.

The procedure depicted in <FIG> shows only one of the receiving MC service clients using an MBMS bearer.

The MC client (<NUM>) successfully completed service authorization via MC gateway UE (<NUM>).

The MC client (<NUM>) shared the MBMS bearer details to the MC gateway UE (<NUM>) and the MC gateway UE (<NUM>) started listening on the MBMS bearer.

Operation <NUM>, the MC gateway UE (<NUM>) that enters or is in the service area of at least one announced TMGI and starts listening on the MBMS bearer.

Operation <NUM>, the MC gateway UE (<NUM>) notifies the MC client (<NUM>) that it can receive data over MBMS by sending the MC GW MBMS Listening Status Report/Notify. The MC GW MBMS Listening Status Report also contains the details of the non 3GPP transport communication related parameters.

Operation <NUM>, the MC client (<NUM>) sends the MBMS listening status report to the MC service server (<NUM>) indicating that it is able to receive the application level control messages over MBMS, whereby the MC service server (<NUM>) may decide to use the MBMS bearer instead of unicast bearer for MC communication sessions.

Operation <NUM>, the MC service server (<NUM>) transmit MC application control messages.

Operation <NUM>, the MC gateway forwards the MC application control messages to the MC client (<NUM>) over the communication channel as established in operation <NUM>.

The above procedures of updating the MC gateway UE (<NUM>) with the MBMS bearer related information by sending the MC GW MBMS bearer announcement applies whenever the MC clients (<NUM>) receive the MBMS bearer announcement either over the multicast channel or over the unicast channel from the MC system or MC service server (<NUM>).

Communication channel between MC client and MC gateway UE (<NUM>):
Between the MC client (<NUM>) and the MC gateway UE (<NUM>), the communication mechanism could be Unicast, multicast or broadcast. Embodiments herein propose that the MC client (<NUM>) should be conveyed whether the data traffic is received over unicast or multicast by the MC gateway UE (<NUM>). If the MC gateway UE (<NUM>) uses the multicast channel on the non 3GPP transport to forward the data traffic received over MBMS channel on the 3GPP transport, then it is implicitly known to the MC client (<NUM>) that this data traffic is received over MBMS channel and it can handle the data traffic accordingly. If there is no possibility of using multicast channel between the MC gateway UE (<NUM>) and the MC client (<NUM>), then there is a need to differentiate the data traffic, so that MC client (<NUM>) knows that it is received over the MBMS channel on the 3GPP transport and knows how to handle the data traffic. In case of where there is no multicast channel between the MC client (<NUM>) and the MC gateway UE (<NUM>). Embodiments herein propose that there should be a separate channel between MC client (<NUM>) and MC gateway UE (<NUM>) for delivering the data received by the MC gateway UE (<NUM>) over the unicast bearer and a different channel to deliver the data received by MC gateway over multicast bearer. The channel between the MC gateway UE (<NUM>) and MC client (<NUM>) for delivering the multicast data can either be unicast or multicast based on the non-3GPP transport being used for communication between MC client (<NUM>) and MC gateway UE (<NUM>). Since the MBMS traffic may be encrypted, having a different channel to send the MBMS traffic to the MC clients (<NUM>) will help in applying the appropriate encryption keys to decrypt the packets.

Embodiments herein foresee at least <NUM> channels (socket communication) to be established between MC client (<NUM>) and MC gateway UE (<NUM>) for handling the data traffic, which is depicted in <FIG> and details are as below:.

Handling of MapGroupToBearer messages:
When the MC client (<NUM>) detects that the data received from MC service server (<NUM>) is MapGroupToBearer message and if the MC client (<NUM>) participates in the group session or communication identified by the MapGroupToBearer message then it should inform the details contained in the MapGroupToBearer message to the MC gateway UE (<NUM>) by sending MC GW MapGroupToBearer. When the association of group call, the MBMS bearer and the MC GW service ID of the MC client (<NUM>) is known to the MC gateway UE (<NUM>), it can forward the data received over MBMS bearer accordingly. The MC gateway UE (<NUM>) shall maintain the list of the MC clients (<NUM>) that sent the MC GW MapGroupToBearer message and forward the data received over the MBMS subchannel identified by the MC GW MapGroupToBearer message only to those MC clients (<NUM>).

<FIG> describes this procedure and the detailed operations are as below according to an embodiment of the disclosure.

The MC client (<NUM>) shares the details of the MBMS bearer announcement with the MC gateway UE (<NUM>).

The MBMS bearer is activated and the MC gateway UE (<NUM>) starts listening the MBMS bearer.

The MC group communication is initiated and the MC service server (<NUM>) decides to use the MBMS bearer for call.

Operation <NUM>, the MC service server (<NUM>) will send a MapGroupToBearer message over a previously activated MBMS bearer to all users that will receive the call over an MBMS bearer. The MapGroupToBearer message includes association information between the group call and MBMS bearer. The MapGroupToBearer message includes MC service group ID and information about the media stream identifier of the activated MBMS bearer and may include the identifier (i.e., the TMGI) of the MBMS bearer broadcasting the call.

Operation <NUM>, if the MC client (<NUM>) is participating in the MC group communication identified by the MapGroupToBearer message, it sends the details contained in the MapGroupToBearer message to the MC gateway UE (<NUM>) through MC GW MapGroupToBearer request message.

Operation <NUM>, the MC gateway on receiving the MC GW MapGroupToBearer request message from the MC client (<NUM>), it maintains the association between the GW MC Service ID and the corresponding MBMS sub channel.

Operation <NUM>, the MC gateway UE (<NUM>) sends the MC GW MapGroupToBearer response message to the MC client (<NUM>), which contains the details of the non 3GPP transport communication related parameters.

Operation <NUM>, the MC client (<NUM>) establishes the communication channel with the MC gateway UE (<NUM>) based on the parameters received in operation <NUM> to receive the MC service group communication data from the MC gateway UE (<NUM>).

Operation <NUM>, the MC service server (<NUM>) sends the downlink media for the group communication session over the MBMS bearer.

Operation <NUM>, the MC gateway UE (<NUM>) checks which MC clients (<NUM>) should receive the media of the MC group communication based on Operation <NUM>.

Operation <NUM>, the MC gateway UE (<NUM>) forwards the downlink media to the intended MC clients (<NUM>) over the communication channel established as in operation <NUM>.

For operation <NUM>, the MC gateway UE (<NUM>) shall use the dedicated channel established between the MC client (<NUM>) and the MC gateway UE (<NUM>) for sending the multicast traffic. This channel could be either multicast or unicast and is left to the implementation technology of transport channel between the MC clients (<NUM>) and the MC gateway UE (<NUM>).

The MC service server (<NUM>) can choose to instruct some MC clients (<NUM>) to send the MBMS bearer suspension report when notified by the radio access network (RAN) (<NUM>). When the MC clients (<NUM>) are residing on the non 3GPP devices (<NUM>), the MC gateway UE (<NUM>) would be the one listening on the MBMS bearers. When the RAN (<NUM>) decides to suspend the MBMS bearer it indicates the MC gateway UE (<NUM>). The MC gateway UE (<NUM>) in turn has to notify the MC clients (<NUM>) it is serving, so that the MC clients (<NUM>) can report the same to the MC service server (<NUM>). This procedure is applicable only if the MC client (<NUM>) is instructed to report the MBMS bearer suspension. Irrespective of whether the MC clients (<NUM>) need to send the MBMS bearer suspension report to the MC service server (<NUM>), the MC gateway can choose to notify the MC clients (<NUM>) it is serving, whenever the RAN (<NUM>) suspends the MBMS bearer. The MC clients (<NUM>) can then decide to send the MBMS bearer suspension report to the MC service server (<NUM>) only, if they are instructed by the MC service server (<NUM>).

<FIG> describes the procedure for how MC clients report the MBMS bearer suspension to an MC service server according to an embodiment of the disclosure. In this procedure, the MC client (<NUM>) is requested by the MC service server (<NUM>) to send an MBMS suspension report. This request for MBMS suspension report can be included in the MBMS bearer announcement and the MC service server (<NUM>) may choose to only send this request for MBMS suspension report to a subset of MC clients (<NUM>).

It is assumed that there is at least one active MBMS bearer.

Operation <NUM>, the MC service server (<NUM>) sends an MBMS suspension reporting instruction to the MC client (<NUM>) residing on the non 3GPP device (<NUM>). This message may be included in the MBMS bearer announcement message and may be sent both on a unicast bearer and a multicast bearer.

Operation <NUM>, the RAN (<NUM>) decides to suspend the MBMS bearer, according to existing procedures in 3GPP TS <NUM>.

Operation <NUM>, an MBMS suspension indication is sent to the MC gateway UE (<NUM>) in the multicast channel (MCH) Scheduling Information (MSI), according to existing procedures in 3GPP TS <NUM>.

Operation <NUM>, the MC gateway UE (<NUM>) detect the MBMS suspension and sends an MC GW MBMS suspension indication to the MC client (<NUM>) residing on the non 3GPP device (<NUM>).

Operation <NUM>, the MC client MBMS suspension report to the MC Service server (<NUM>) via the MC gateway UE (<NUM>).

The MC service client that is not instructed to send an MBMS suspension report shall detect the MBMS suspension indication from the RAN (<NUM>) (operation <NUM>). An MC service client shall in this case not send other types of report (e.g., MBMS listening reports).

The same procedure can be applied at MBMS resumption or other MBMS events that may be detected by the MC gateway UE (<NUM>).

Since the MC gateway UE (<NUM>) is listening on the MBMS bearer on behalf of the MC clients (<NUM>), it has to report the MBMS bearer quality to the MC clients (<NUM>), so that the MC clients (<NUM>) can report the same to the MC service server (<NUM>). The MC gateway UE (<NUM>) monitors the MBMS bearer to receive MC service media. Based on the received quality (e.g., radio level quality, transport level quality), the MC gateway UE (<NUM>) needs to inform the MC clients (<NUM>) which asked the MC gateway UE (<NUM>) to listen on MBMS bearer, that the MC gateway UE (<NUM>) is able to receive the MC service media on the MBMS bearer with sufficient quality or not able to receive the MC service media on the MBMS bearer with sufficient quality so that the MC clients (<NUM>) can inform the MC Service server (<NUM>) accordingly. Furthermore, based on the received quality, the MC gateway UE (<NUM>) may notify the MC clients (<NUM>) at which MBMS reception quality level it has received the MC service media on the MBMS bearer.

The issue can be more complex since the MC gateway UE (<NUM>) needs to estimate the quality of the bearer even in the scenario when there are no data currently transmitted on the MBMS bearer (e.g., between MCPTT group call). The reason for this is that an MC gateway UE (<NUM>) that has entered an area with significantly degraded MBMS quality, might not even notice that an MC service communication is ongoing, meanwhile the MC server assumes that the MC service client can receive the media being broadcasted.

In order to estimate the MBMS bearer quality, for example as an equivalent BLER (Block Error Rate), when no data is sent is implementation specific. This estimation can be dependent on for example the modulation and coding scheme (MCS) and measurements from the reference signals from the eNB(s). Other metrics (e.g., real-time transport protocol (RTP) packet loss) may be used to estimate the MBMS bearer quality.

<FIG> depicts a procedure of detecting MBMS bearer quality, according to an embodiment of the disclosure.

Referring to <FIG>, embodiments herein propose that an MC gateway UE (<NUM>) follows the procedure as described in 3GPP TS <NUM> Section <NUM>. <NUM> to determine the MBMS bearer quality. MC gateway UE (<NUM>) informs the MC client (<NUM>) about the MBMS bearer quality and the MC client informs the same to the MC service server (<NUM>). <FIG> describes this procedure.

For the sake of brevity, only one MC client (<NUM>) is shown in the procedure but there could be more than one MC clients which has requested the MC gateway UE (<NUM>) to listen on a particular MBMS bearer.

There is an MBMS bearer activated and the MBMS bearer information is announced to the MC gateway UE (<NUM>).

The MC gateway UE (<NUM>) is located in the MBMS broadcasting area.

The MC gateway UE (<NUM>) monitors SIB-<NUM> (or SIB-<NUM>) and (SC-) MCCH to receive the modulation and coding scheme.

The MC gateway UE (<NUM>) monitors the cell specific reference signal and when MBSFN transmission is used, the MBSFN specific reference signals.

Operation <NUM>, here the MC gateway UE (<NUM>) follows the Operation <NUM> of the procedure as described in 3GPP TS <NUM> Section <NUM>. <NUM> for the MC service UE. Instead of reporting the bearer quality to the MC service server (<NUM>), it has to inform all the MC clients (<NUM>) which has asked the MC gateway UE (<NUM>) to listen on the particular MBMS bearer.

Operation <NUM>, if the MBMS bearer quality reaches a certain threshold, the MC gateway UE (<NUM>) sends the MC GW MBMS bearer quality report to the MC client (<NUM>). The threshold is used to define the MBMS listening status, which indicates if the MBMS bearer quality has been acceptable or not to receive a specific MC service media. If the MBMS bearer quality is mapped to a different MBMS reception quality level, the MC gateway UE (<NUM>) may send an MBMS Bearer Quality report including the MBMS reception quality level to the MC client (<NUM>).

Operation <NUM>, the MC client (<NUM>) sends the MBMS listening status report to the MC service server (<NUM>) via the MC gateway UE (<NUM>) containing the information received in the MC GW MBMS bearer quality report.

Operation <NUM>, the MC service server (<NUM>) may send additional proposal for measurements; e.g., information about neighboring MBMS bearers. This message may be an MBMS bearer announcement message.

The MC system sends the MBMS bearer announcements and updates to the MC gateway UE (<NUM>) directly. This approach requires that MC gateway UE (<NUM>) to be addressable by the MC system. For this approach, embodiments herein assume that MC gateway UE (<NUM>) is addressable by the MC service server (<NUM>) and the MC gateway UE (<NUM>) needs to support and handle the following information flows which are defined in TS <NUM>.

In order to support the usage of MBMS bearer for the MC clients (<NUM>) residing on the non 3GPP devices (<NUM>), the MC gateway UE (<NUM>) needs to support the procedures and information flows applicable for MC service UE as defined in clause <NUM> of TS <NUM> with the following clarifications:
The MC gateway UE (<NUM>) needs to be assigned with the MC service ID and configured with minimal information required for it to be authenticated and authorized with MC system for supporting MBMS bearer usage.

The MC service server (<NUM>) shall be able to address the MC gateway UE (<NUM>) using the MC service ID for exchanging the requests and responses related to the MBMS bearer usage.

The MC service server (<NUM>) shall maintain the list of MC gateway UEs (<NUM>) and per MC gateway UE (<NUM>), the list of MC clients (<NUM>) resides on the non 3GPP devices (<NUM>) and accesses the MC system via the MC gateway UE (<NUM>).

The MC service server (<NUM>) can choose to send the information related to MBMS bearer announcements, updates to the MBMS bearer announcements, suspension of MBMS bearer, mapping of MC service group communication with MBMS bearer etc. to the MC gateway UE (<NUM>) instead of sending to the individual MC clients (<NUM>) (residing on the non 3GPP devices (<NUM>)) which are accessing the MC system via this MC gateway UE (<NUM>). The MC service server (<NUM>) shall always send this information to the MC gateway UE (<NUM>) over the unicast channel, so that the MC gateway UE (<NUM>) need not process the data received over MBMS bearer. It just forwards the data received over the MBMS bearer to the MC clients (<NUM>) it is serving. Also, the MC gateway UE (<NUM>) does not have to configured with the security keys for decrypting the data received over MBMS bearer.

The MC service server (<NUM>) on receiving the MBMS bearer suspension report from the MC gateway UE (<NUM>), the MC service server (<NUM>) considers it as if it is received from all the MC clients (<NUM>) residing on the non 3GPP devices (<NUM>) and accessing the MC system through the MC gateway UE (<NUM>) for any decision making purpose.

The MC clients (<NUM>) shall ignore the MBMS bearer announcements, MBMS bearer updates, and MapGroupToBearer messages, which are received over the MBMS bearer since these messages are to be handled by the MC gateway UE (<NUM>).

The MBMS bearer announcement (as defined in <NUM>. <NUM> of TS <NUM>), which is currently being sent from the MC service server (<NUM>) to the MC service client (<NUM>) needs to be sent to the MC gateway UE (<NUM>).

The MBMS listening status report (as defined in <NUM>. <NUM> of TS <NUM>) has to be sent by the MC gateway UE (<NUM>) to the MC service server (<NUM>).

The MBMS suspension reporting instruction (as defined in <NUM>. <NUM> of TS <NUM>) has to be sent from MC service server (<NUM>) to the MC gateway UE (<NUM>) over unicast bearer.

The MapGroupToBearer message as defined in TS <NUM> for MCPTT and in TS <NUM> for MCVideo shall be sent from MC service server (<NUM>) to the MC gateway UE (<NUM>). This needs to be sent to the MC gateway UE (<NUM>) over the unicast bearer.

The MC Service server (<NUM>) shall maintain the mapping of MC gateway UE (<NUM>) and the list of the MC clients (<NUM>) being served by the MC gateway UE (<NUM>). Whenever MC service server (<NUM>) has to establish, update or suspend the MBMS bearer, it can send the corresponding messages to the MC gateway UE (<NUM>). When the MC gateway UE (<NUM>) sends the MBMS listening status report to the MC service server (<NUM>), the MC service server (<NUM>) shall consider this message as received from all the MC clients (<NUM>) that the MC gateway UE (<NUM>) is serving for any decision making purpose.

Whenever the MC service server (<NUM>) has to establish, update or suspend the MBMS bearer, it can choose to send that information only to the MC gateway UE (<NUM>) instead of sending it to the individual MC clients (<NUM>), which are residing on the non 3GPP devices (<NUM>) and accessing the MC system via this MC gateway UE (<NUM>).

In this scenario, the MC service server (<NUM>) pre-establishes MBMS bearer(s) in certain pre-configured areas before the initiation of the group communication session. When the user originates a request for a group communication session for one of these areas, the pre-established MBMS bearer(s) is used for the DL media transmission.

The following operations need to be performed prior the start of the MC group communication session over pre-established MBMS bearer involving the MC clients (<NUM>) residing on the non 3GPP devices (<NUM>) and accessing the MC services via the MC gateway UE (<NUM>):.

Announce the pre-established MBMS bearer to the MC service clients and MC gateway UE (<NUM>).

When these preparation operations have been done the MC group communication session using MBMS bearer can start. Both the media packets as well as the application level control signaling (e.g., floor control messages) to the receiving MC service clients are sent on the MBMS bearer. Optionally, a separate MBMS bearer could be used for the application level control messages, due to different bearer characteristic requirements.

<FIG> depicts a scenario wherein only one of a receiving MC client residing on non 3GPP device and MC gateway UE using an MBMS bearer, according to an embodiment of the disclosure.

Referring to <FIG>, the procedure, depicted in <FIG>, shows only one of a receiving MC client (<NUM>) residing on a non 3GPP device (<NUM>) and an MC gateway UE (<NUM>) using an MBMS bearer. There might also be MC service clients in the same MC group communication session that receive the communication on unicast bearers.

The MC Gateway completed the required authentication and authorization with the MC system so that it is addressable directly by the MC service server (<NUM>).

The MC service server (<NUM>) maintains the list of MC gateway UEs (<NUM>) and the list of MC clients (<NUM>) residing on the non 3GPP devices (<NUM>), which accesses the MC system via the MC gateway UE (<NUM>).

The participating users are already affiliated.

Operation 1a, the MC service server (<NUM>) determines to activate MBMS bearer. The activation of the MBMS bearer is done on the MB2-C reference point and according to 3GPP TS <NUM>. This bearer will be used for the MC communication media.

The procedure to determine the activation of MBMS bearers is implementation specific.

Operation 2a, the MC service server (<NUM>) passes the MBMS bearer info for the service description associated with the pre-established MBMS bearer to the MC gateway UE (<NUM>). The MC gateway UE (<NUM>) obtains the TMGI, identifying the MBMS bearer, from the service description.

Operation 2b, the MC service server (<NUM>) may pass the MBMS bearer info for the service description associated with the pre-established floor control MBMS bearer to the MC gateway UE (<NUM>). The MC gateway UE (<NUM>) obtains the TMGI, identifying the MBMS bearer, from the service description.

Operations 2a and 2b can be done in one MBMS bearer announcement message. The MC service server (<NUM>) can choose to send the MBMS bearer announcement only to the MC gateway UE (<NUM>) instead of sending to all the MC clients (<NUM>) it is serving or to both the MC gateway UE (<NUM>) and the MC clients (<NUM>) residing on the non 3GPP devices (<NUM>) and accessing the MC system through the MC gateway UE (<NUM>).

Operation <NUM>, the MC gateway UE (<NUM>) that enters or is in the service area of at least one announced TMGI indicates to the MC service server (<NUM>) that the MC gateway UE (<NUM>) is able to receive media over MBMS, whereby the MC service server (<NUM>) may decide to use the MBMS bearer instead of unicast bearer for MC communication sessions. MC service server (<NUM>) shall treat the MBMS listening status report received from the MC gateway UE (<NUM>) as if it is received from all the MC clients (<NUM>) residing on the non 3GPP devices (<NUM>) and accessing the MC system through this MC gateway UE (<NUM>).

Operation <NUM> is optional for the MC gateway UE (<NUM>) on subsequent MBMS bearer announcements.

Operation <NUM>, the MC gateway UE (<NUM>) confirms the MC client (<NUM>) that it is able to listen on the MBMS bearer by sending the MC GW MBMS Listening Status Report/Notify. The MC GW MBMS listening status report also contains the details of the non 3GPP transport communication related parameters.

Operation <NUM>, the MC client (<NUM>) establishes the communication channel with the MC gateway UE (<NUM>) based on the parameters received in operation <NUM> to receive the MC service data from the MC gateway UE (<NUM>). This allows MC gateway UE (<NUM>) to forward the MC service data it received over the MBMS bearer from the MC service server (<NUM>) to the MC client (<NUM>) over this communication channel.

Operation <NUM>, as the MC service server (<NUM>) transmits the media over the MBMS bearer, the media packets are detected and delivered to the MC gateway UE (<NUM>).

Operation <NUM>, the MC gateway UE (<NUM>) then forwards the received data to the MC clients (<NUM>) residing on the non 3GPP devices (<NUM>) over the communication channel established in Operation <NUM>.

<FIG> depicts a scenario in which the MC service server uses a unicast bearer for communication with the UE on a DL at a start of a group communication session, according to an embodiment of the disclosure.

Referring to <FIG>, in this scenario depicted in <FIG>, an MC service server (<NUM>) uses a unicast bearer for communication with a UE on a DL at a start of a group communication session. When the MC service server (<NUM>) decides to use an MBMS bearer for the DL media transmission, the MC service server (<NUM>) establishes an MBMS bearer using the procedures defined in 3GPP TS <NUM>. The MC service server (<NUM>) provides the MBMS service description information associated with MBMS bearer(s), obtained from the BM-SC, to the MC gateway UE (<NUM>). The MC gateway UE (<NUM>) starts using the MBMS bearer(s) to receive DL media.

The MC gateway completed the required authentication and authorization with the MC system so that it is addressable directly by the MC service server (<NUM>).

The MC service server (<NUM>) maintains the list of MC gateway UEs (<NUM>) and the list of MC clients (<NUM>) residing on the non 3GPP devices (<NUM>) which accesses the MC system via the MC gateway UE (<NUM>).

Operation <NUM>, the MC gateway UE (<NUM>) forwards the downlink data to the MC client (<NUM>).

Operation <NUM>, the MC service server (<NUM>) provides service description information associated with the MBMS bearer to the MC gateway UE (<NUM>). The MC gateway UE (<NUM>) obtains the TMGI from the announcement message. This message may be sent on an application level control signaling bearer. The MC service server (<NUM>) can choose to send the MBMS bearer announcement only to the MC gateway UE (<NUM>) instead of sending to all the MC clients (<NUM>) it is serving or to both the MC gateway UE (<NUM>) and the MC clients (<NUM>) residing on the non 3GPP devices (<NUM>) and accessing the MC system through this MC gateway UE (<NUM>).

Operation <NUM>, the MC gateway UE (<NUM>) starts monitoring data over MBMS associated with the TMGI, while in the service area associated with the TMGI.

Operation <NUM>, the MC gateway UE (<NUM>) detects that it is able to receive data over MBMS associated with the TMGI.

Operation <NUM>, the MC gateway notifies the MC service server (<NUM>) the MBMS listening status associated to the monitored TMGI, (e.g., that it is successfully receiving the TMGI). The MC gateway UE (<NUM>) may also notify the MBMS reception quality level of the TMGI. MC service server (<NUM>) shall treat the MBMS listening status report received from the MC gateway UE (<NUM>) as if it is received from all the MC clients (<NUM>) residing on the non 3GPP devices (<NUM>) and accessing the MC system through the MC gateway UE (<NUM>). The MC service server (<NUM>) stops sending media data over unicast way to the MC client (<NUM>).

The MBMS reception quality level may be used by the MC service server (<NUM>) to make an efficient decision to switch again to a unicast transmission or to take measures to prepare such a switch (e.g., when the quality level indicates that the reception quality of the MBMS bearer is decreasing or reaching an insufficient quality level for the reception of MC services).

Operation <NUM>, the MC gateway UE (<NUM>) confirms the MC client (<NUM>) that it is able to listen on the MBMS bearer by sending the MC GW MBMS Listening Status Report/Notify. The MC GW MBMS Listening Status Report also contains the details of the non 3GPP transport communication related parameters.

Operation <NUM>, the MC client (<NUM>) establishes the communication channel with the MC gateway UE (<NUM>) based on the parameters received in operation <NUM> to receive the MC service data from the MC gateway UE (<NUM>). This allows the MC gateway UE (<NUM>) to forward the MC service data it received over the MBMS bearer from the MC service server (<NUM>) to the MC client (<NUM>) over this communication channel.

Operation <NUM>, an MC service group communication session via dynamic MBMS bearer(s) is established.

Operation <NUM>, the MC service server (<NUM>) sends the downlink media for the group communication session over the MBMS.

Operation <NUM>, the MC gateway UE (<NUM>) then forwards the received data to the MC clients (<NUM>) residing on the non 3GPP devices (<NUM>) over the communication channel as established in operation <NUM>.

<FIG> depicts a scenario, in which a group session is setup before a group communication start, according to an embodiment of the disclosure.

The MBMS bearer can be used for MC service group communications. One MBMS bearer is not permanently associated to one specific group or group communication. Before sending media packets of the group communication over the MBMS bearer, the MC service server (<NUM>) shall send the association information between group communication and the MBMS bearer to the MC gateway UE (<NUM>). The group communication setup procedure indicates the media stream or media streams within one MBMS bearer that is used for the specific MC service group communication. When the group communication over the MBMS bearer is finished, this temporary association information of the MC service group call to specific resources on an MBMS bearer is undone.

Referring to <FIG>, the procedure in <FIG> requires that the group session is setup before the group communication start. This eliminates the need for the receiving clients to continuously use the unicast bearer. Prior to this the MBMS bearer is activated and announced to the MC gateway UE (<NUM>).

There needs to be the mapping between the 3GPP transport side MBMS bearer association with the MC service group communication and the non-3GPP transport side communication channel association with MC service group communication. On the non 3GPP transport side, the communication channel could be either multicast or unicast. Once this association between the 3GPP transport and the non 3GPP transport is made, the MC clients (<NUM>) receiving the multicast data from the MC gateway UE (<NUM>) would be able to associate the received data to a particular MC service group communication and process them accordingly. The MC GW MapgroupToBearer message is used to establish this association.

Table <NUM> describes the information flow from the MC gateway UE (<NUM>) to the MC client (<NUM>) for the MC GW MapGroupToBearer.

All users participating in the MCVideo group call are already affiliated to the group.

All participating users have joined the group session.

Operation <NUM>, activation and announcement of MBMS bearer availability.

Operation <NUM>, the MC service server (<NUM>) will send a MapGroupToBearer message over the previously activated MBMS bearer to all users that will receive the MC service group over the MBMS bearer. The MapGroupToBearer message includes association information between the MC service group communication and the MBMS bearer. The MapGroupToBearer message includes the MC service group ID and information about the media stream identifier or media stream identifiers of the activated MBMS bearer and may include the identifier (i.e., the TMGI) of the MBMS bearer broadcasting the MC service group communication.

Operation <NUM>, the MC gateway UE (<NUM>) sends the MC GW MBMS MapGroupToBearer to the MC client (<NUM>) containing the information received in MapGroupToBearer message and also the details of the communication channel association on non 3GPP transport side between the MC client (<NUM>) and the MC gateway UE (<NUM>).

Operation <NUM>, based on the information received in operation <NUM>, the MC client (<NUM>) establishes the communication channel with MC gateway UE (<NUM>) to receive the MC service group data sent over the MBMS channel on the 3GPP transport side. This communication channel could be unicast or multicast and is left to the implementation.

Operation <NUM>, the media corresponding to the MC service group communication is sent over the MBMS bearer by the MC service server (<NUM>).

Operation <NUM>, the MC gateway UE (<NUM>) forwards the received media over the MBMS bearer to the MC client (<NUM>) using the communication channel established as in operation <NUM>.

Since the MC gateway UE (<NUM>) is listening on the MBMS bearer, it has to report the MBMS bearer quality to the MC service server (<NUM>). The MC gateway UE (<NUM>) monitors an MBMS bearer to receive MC service media. Based on the received quality (e.g., radio level quality, transport level quality), the MC gateway UE (<NUM>) needs to inform the MC service server (<NUM>), that the MC gateway UE (<NUM>) is able to receive the MC service media on the MBMS bearer with sufficient quality or not. Furthermore, based on the received quality, the MC gateway UE (<NUM>) may notify the MC service server (<NUM>) at which the MBMS reception quality level it has received the MC service media on the MBMS bearer.

The issue can be more complex since the MC gateway UE (<NUM>) needs to estimate the quality of the bearer even in the scenario when there are no data currently transmitted on the MBMS bearer (e.g., between MCPTT group call). The reason for this is that an MC gateway UE (<NUM>) that has entered an area with significantly degraded MBMS quality, might not even notice that an MC service communication is ongoing, meanwhile the MC server assumes that the MC gateway UE (<NUM>) can receive the media being broadcasted.

In order to estimate the MBMS bearer quality, for example as an equivalent BLER (Block Error Rate), when no data is sent is implementation specific. This estimation can be dependent on for example the modulation and coding scheme (MCS) and measurements from the reference signals from the eNB(s). Other metrics (e.g., RTP packet loss) may be used to estimate the MBMS bearer quality.

The MC gateway UE (<NUM>) follows the procedure as described in <NUM>. <NUM> of TS <NUM> and it acts as the MC service UE. On receiving the MBMS listening status report from the MC gateway UE (<NUM>), the MC service server (<NUM>) considers as if it has received the MBMS listening status report from all the MC clients (<NUM>) which are accessing the MC system via this MC gateway UE (<NUM>) and to which the established MBMS bearer is applicable.

<FIG> depicts the process of detecting MBMS bearer quality, according to an embodiment of the disclosure.

Embodiments herein propose that the MC gateway UE (<NUM>) follows the procedure as described in 3GPP TS <NUM> Section <NUM>. <NUM> to determine the MBMS bearer quality. The MC gateway UE (<NUM>) informs the MC service server (<NUM>) about the MBMS bearer quality. <FIG> describes this procedure.

Referring to <FIG>, operation <NUM>, the MC gateway UE (<NUM>) determines the MBMS bearer quality. Operation <NUM>, the MC gateway UE (<NUM>) sends the MBMS listening status report including the MBMS reception quality level to the MC service server (<NUM>). At operation <NUM>, the MC service server (<NUM>) sends the MBMS bearer announcement to the MC gateway UE (<NUM>) based on the MBMS listening status report.

In another embodiment, the MC gateway UE (<NUM>) follows the Operation <NUM> of the procedure as described in 3GPP TS <NUM> Section <NUM>. <NUM> for the MC service UE. Instead of reporting the bearer quality to the MC service server (<NUM>) it has to inform all the MC clients (<NUM>) which has asked the MC gateway UE (<NUM>) to listen on the particular MBMS bearer.

If the MBMS bearer quality reaches a certain threshold, the MC gateway UE (<NUM>) sends an MC GW MBMS listening status report to the MC client (<NUM>). The threshold is used to define the MBMS listening status, which indicates if the MBMS bearer quality has been acceptable or not to receive a specific MC service media. If the MBMS bearer quality is mapped to a different MBMS reception quality level, the MC gateway UE (<NUM>) may send an MBMS listening status report including the MBMS reception quality level to the MC client (<NUM>).

The MC client (<NUM>) sends the MBMS Listening Status report to the MC Service server (<NUM>) via the MC gateway UE (<NUM>) containing the information received in the MC GW MBMS Listening status report.

The MC service server (<NUM>) may send additional proposal for measurements; e.g., information about neighboring MBMS bearers. This message may be an MBMS bearer announcement message.

The MC service server (<NUM>) can choose to instruct MC gateway UE (<NUM>) to send the MBMS bearer suspension report when notified by the RAN (<NUM>). When the RAN (<NUM>) decides to suspend the MBMS bearer it indicates the MC gateway UE (<NUM>). The MC gateway can then decide to send the MBMS bearer suspension report to the MC service server (<NUM>) only if they are instructed by the MC service server (<NUM>). On receiving the MBMS bearer suspension report from the MC gateway UE (<NUM>), the MC service server (<NUM>) considers it as if it is received from all the MC clients (<NUM>) residing on the non 3GPP devices (<NUM>) and accessing the MC system through this MC gateway UE (<NUM>) for any decision making purpose.

<FIG> describes the procedure for how an MC gateway UE reports the MBMS bearer suspension to the MC server when instructed according to an embodiment of the disclosure. In this procedure, the MC gateway UE (<NUM>) is requested by the MC service server (<NUM>) to send an MBMS suspension report. This request for MBMS suspension report can be included in the MBMS bearer announcement.

Referring to <FIG>, below are the pre-conditions for the procedures explained in the <FIG>.

Use of MBMS bearer for application level control signaling:
The MC service server (<NUM>) may use an MBMS bearer for application level control signaling, according to this subclause. An MBMS bearer for application level control signaling is typically used for the purposes beyond the benefit for using MBMS for resource efficiency, e.g., for improved MC service performance (KPIs), handling of high load scenarios.

The MBMS bearer for application level control signaling is activated in a service area that is larger than the estimated service for media bearers. The service area for the media bearers mainly based on counting of group members in each defined service area. The MBMS bearer for application level control signaling is also activated with a QoS that is better than MBMS media bearers since the packet loss requirements are much stricter.

<FIG> depicts a procedure, wherein only one of the receiving MC service clients uses an MBMS bearer, according to an embodiment of the disclosure.

Referring to <FIG>, the procedure in <FIG> shows only one of the receiving MC service clients using the MBMS bearer.

Operation <NUM>, the MC service server (<NUM>) determines to activate MBMS bearer for application level control signaling, The activation of the MBMS bearer is done on the MB2-C reference point and according to 3GPP TS <NUM>.

Operation <NUM>, the MC service server (<NUM>) passes the MBMS bearer info for the service description associated MBMS bearer to the MC gateway UE (<NUM>). The MC gateway UE (<NUM>) obtains the TMGI, identifying the MBMS bearer, from the service description.

Operation <NUM>, the MC gateway UE (<NUM>) stores the information associated with the TMGI. The MC gateway UE (<NUM>) uses the TMGI and other MBMS bearer related information to activate the monitoring of the MBMS bearer.

Operation <NUM>, the MC gateway UE (<NUM>) that enters or is in the service area of the announced TMGI indicates to the MC service server (<NUM>) that the MC gateway UE (<NUM>) is able to receive application level control messages over the MBMS bearer. The MC gateway UE (<NUM>) may also indicate at which MBMS reception quality level it has received the MC service media on the MBMS bearer. Hence, the MC service server (<NUM>) may decide to use the MBMS bearer for MC application control messages.

Operation <NUM>, the MC Gateway UE (<NUM>) informs the MC client (<NUM>) that it is able to listen on the MBMS bearer by sending the MC GW MBMS Listening Status Report/Notify. The MC GW MBMS listening status report also contains the details of the non 3GPP transport communication related parameters.

Operation <NUM>, the MC client (<NUM>) establishes the communication channel with the MC gateway UE (<NUM>) based on the parameters received in operation <NUM> to receive the MC service data from the MC gateway UE (<NUM>). This allows MC gateway UE (<NUM>) to forward the MC service data it received over the MBMS bearer from the MC service server (<NUM>) to the MC client (<NUM>) over the communication channel.

Operation <NUM>, the MC service server (<NUM>) transmit MC application control messages.

Embodiments herein enable the MC system to operate in an efficient way and harness the benefit of using MBMS services.

<FIG> illustrates various hardware components of the MC GW UE, according to embodiments as disclosed herein. In an embodiment, the MC GW UE (<NUM>) includes a processor (<NUM>), a communicator (<NUM>), a memory (<NUM>) and an MBMS controller (<NUM>). The processor (<NUM>) is coupled with the communicator (<NUM>), the memory (<NUM>) and the MBMS controller (<NUM>).

The MBMS controller (<NUM>) receives the MC gateway MBMS bearer announcement from the MC client (<NUM>) in response to receiving information associated with the MBMS bearer and the service description associated with the MBMS bearer from the MC service server (<NUM>). The MC GW MBMS bearer announcement includes the MBMS bearer related information.

Further, the MBMS controller (<NUM>) stores information associated with the identifier at the MC gateway UE (<NUM>) in response to receiving the MC gateway MBMS bearer announcement from the MC client (<NUM>). The MC gateway UE (<NUM>) uses the identifier and the information to activate for monitoring the MBMS bearer by the MC gateway UE (<NUM>).

Further, the MBMS controller (<NUM>) sends the MBMS listening status report to the MC client (<NUM>) based on the MC GW MBMS bearer announcement. Further, the MBMS controller (<NUM>) establishes the communication channel with the MC client (<NUM>) based on the parameter to receive the MC service data from the MC gateway UE (<NUM>). The MC gateway UE (<NUM>) forwards the MC service data to the MC client (<NUM>).

Further, the MBMS controller (<NUM>) sends the MC GW MBMS bearer quality report to the MC client (<NUM>). Further, the MBMS controller (<NUM>) receives the MBMS listening status report from the MC client (<NUM>) based on the MC GW MBMS bearer quality report to send or forward to the MC service server (<NUM>). The MBMS listening status report comprises the MC GW MBMS bearer quality report and the information about the neighboring MBMS bearer.

The MBMS controller (<NUM>) receives the MC GW MapGroupToBearer request message from the MC client (<NUM>) in response to receiving the MapGroupToBearer message, at the MC client (<NUM>), from the MC service server (<NUM>) over the previously activated MBMS bearer. The MC GW MapGroupToBearer request message comprises details comprises in the MapGroupToBearer message. The MBMS controller (<NUM>) maintains the association between the GW MC service ID and corresponding MBMS sub channel based on the MC GW MapGroupToBearer request message. The MBMS controller (<NUM>) sends the MC GW MapGroupToBearer response message to the MC client (<NUM>) based on the MC GW MapGroupToBearer request message. The MC GW MapGroupToBearer response message comprises details of non 3GPP transport communication related parameters. Further, the MBMS controller (<NUM>) establishes the communication channel with the MC client (<NUM>) based on the non 3GPP transport communication related parameters to receive an MC service group communication data from the MC gateway UE (<NUM>). Further, the MBMS controller (<NUM>) sends the downlink media received over the MBMS bearer to the MC client (<NUM>).

Further, the MBMS controller (<NUM>) receives the MBMS suspension indication message from the wireless network (<NUM>). The MBMS suspension reporting instruction message is included in the MBMS bearer announcement message. Further, the MBMS controller (<NUM>) sends the MC GW MBMS suspension indication to the MC client (<NUM>). The MC client (<NUM>) sends the MBMS suspension report to the MC service server (<NUM>) via the MC gateway UE (<NUM>) based on the MBMS suspension reporting instruction message and the MC GW MBMS suspension indication.

The MBMS controller (<NUM>) is physically implemented by analog or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, or the like, and may optionally be driven by firmware.

Further, the processor (<NUM>) is configured to execute instructions stored in the memory (<NUM>) and to perform various processes. The communicator (<NUM>) is configured for communicating internally between internal hardware components and with external devices via one or more networks. The memory (<NUM>) also stores instructions to be executed by the processor (<NUM>). The memory (<NUM>) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory (<NUM>) may, in some examples, be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term "non-transitory" should not be interpreted that the memory (<NUM>) is non-movable. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache).

Further, at least one of the pluralities of modules/controller may be implemented through the Artificial Intelligence (AI) model using a data driven controller (not shown). The data driven controller can be a Machine learning (ML) model based controller and AI model based controller. A function associated with the AI model may be performed through the non-volatile memory, the volatile memory, and the processor (<NUM>). The processor (<NUM>) may include one or a plurality of processors. At this time, one or a plurality of processors may be a general purpose processor, such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and/or an AI-dedicated processor such as a neural processing unit (NPU).

The one or a plurality of processors control the processing of the input data in accordance with a predefined operating rule or AI model stored in the non-volatile memory and the volatile memory. The predefined operating rule or artificial intelligence model is provided through training or learning.

Here, being provided through learning means that a predefined operating rule or AI model of a desired characteristic is made by applying a learning algorithm to a plurality of learning data. The learning may be performed in a device itself in which AI according to an embodiment is performed, and/o may be implemented through a separate server/system.

The AI model may comprise of a plurality of neural network layers. Each layer has a plurality of weight values, and performs a layer operation through calculation of a previous layer and an operation of a plurality of weights. Examples of neural networks include, but are not limited to, convolutional neural network (CNN), deep neural network (DNN), recurrent neural network (RNN), restricted Boltzmann Machine (RBM), deep belief network (DBN), bidirectional recurrent deep neural network (BRDNN), generative adversarial networks (GAN), and deep Q-networks.

The learning algorithm is a method for training a predetermined target device (for example, a robot) using a plurality of learning data to cause, allow, or control the target device to make a determination or prediction. Examples of learning algorithms include, but are not limited to, supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning.

Referring to <FIG> shows various hardware components of the MC GW UE (<NUM>) but it is to be understood that other embodiments are not limited thereon according to an embodiment of the disclosure. In other embodiments, the MC GW UE (<NUM>) may include less or more number of components. Further, the labels or names of the components are used only for illustrative purpose and does not limit the scope of the disclosure. One or more components can be combined together to perform same or substantially similar function in the MC GW UE (<NUM>).

<FIG> illustrates various hardware components of the MC client (<NUM>), according to an embodiment of the disclosure. In an embodiment, the MC client (<NUM>) includes a processor (<NUM>), a communicator (<NUM>), a memory (<NUM>) and an MBMS controller (<NUM>). The processor (<NUM>) is coupled with the communicator (<NUM>), the memory (<NUM>) and the MBMS controller (<NUM>).

The MBMS controller (<NUM>) sends the MC GW MBMS bearer announcement to the MC gateway UE (<NUM>) in response to receiving information associated with the MBMS bearer and the service description associated with the MBMS bearer from the MC service server (<NUM>). Based on the MC GW MBMS bearer announcement, the MBMS controller (<NUM>) receives the MBMS listening status report from the MC gateway UE (<NUM>). Further, the MBMS controller (<NUM>) establishes the communication channel with the MC gateway UE (<NUM>) based on at least one parameter to receive MC service data from the MC gateway UE (<NUM>).

Further, the MBMS controller (<NUM>) shares the MBMS listening status report to the MC service server (<NUM>) based on the MC GW MBMS listening status report. The MBMS listening status report indicates that the MC client (<NUM>) receives the media over the MBMS bearer.

Further, the MBMS controller (<NUM>) receives the MC GW MBMS bearer quality report from the MC gateway UE (<NUM>). Based on the MC GW MBMS bearer quality report, the MBMS controller (<NUM>) shares the MBMS listening status report to the MC service server (<NUM>). The MBMS listening status report includes at least one of the MC GW MBMS bearer quality report and information about neighboring MBMS bearer.

Further, the MBMS controller (<NUM>) receives the MapGroupToBearer message from the MC service server (<NUM>) over the previously activated MBMS bearer. Further, the MBMS controller (<NUM>) sends the MC GW MapGroupToBearer request message to the MC gateway UE (<NUM>). The MC GW MapGroupToBearer request message includes details comprised in the MapGroupToBearer message. Based on the MC GW MapGroupToBearer request message, the MBMS controller (<NUM>) receives the MC GW MapGroupToBearer response message from the MC gateway UE (<NUM>). The MC GW MapGroupToBearer response message comprises details of non 3GPP transport communication related parameters. Further, the MBMS controller (<NUM>) establishes the communication channel with the MC gateway UE (<NUM>) based on the non 3GPP transport communication related parameters to receive an MC service group communication data from the MC gateway UE (<NUM>). Further, the MBMS controller (<NUM>) receives the downlink media from the MC gateway UE (<NUM>).

Further, the MBMS controller (<NUM>) receives the MBMS suspension reporting instruction message from the MC service server (<NUM>). The MBMS suspension reporting instruction message is included in the MBMS bearer announcement message. Further, the MBMS controller (<NUM>) receives the MC GW MBMS suspension indication from the MC gateway UE (<NUM>). Further, the MBMS controller (<NUM>) sends the MBMS suspension report to the MC service server (<NUM>) via the MC gateway UE (<NUM>) based on the MBMS suspension reporting instruction message and the MC GW MBMS suspension indication.

Further, at least one of the pluralities of modules/controller may be implemented through the AI model using a data driven controller (not shown). The data driven controller can be a ML model based controller and AI model based controller. A function associated with the AI model may be performed through the non-volatile memory, the volatile memory, and the processor (<NUM>). The processor (<NUM>) may include one or a plurality of processors. At this time, one or a plurality of processors may be a general purpose processor, such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and/or an AI-dedicated processor such as a neural processing unit (NPU).

Referring to <FIG> shows various hardware components of the MC client (<NUM>) but it is to be understood that other embodiments are not limited thereon. In other embodiments, the MC client (<NUM>) may include less or more number of components. Further, the labels or names of the components are used only for illustrative purpose and does not limit the scope of the disclosure. One or more components can be combined together to perform same or substantially similar function in the MC client (<NUM>).

<FIG> is a flow chart illustrating a method, implemented by an MC GW UE, for handling an MBMS in a wireless network, according to an embodiment of the disclosure. The operations (<NUM>-<NUM>) are handled by the MBMS controller (<NUM>).

At operation <NUM> of the flow chart <NUM>, the method includes receiving the MC gateway MBMS bearer announcement from the MC client (<NUM>) in response to receiving information associated with the MBMS bearer and the service description associated with the MBMS bearer from the MC service server (<NUM>). The MC GW MBMS bearer announcement includes the MBMS bearer related information. At operation <NUM>, method includes storing the information associated with the identifier at the MC gateway UE (<NUM>) in response to receiving the MC gateway MBMS bearer announcement from the MC client (<NUM>), where the MC gateway UE (<NUM>) uses the identifier and the information to activate for monitoring the MBMS bearer by the MC gateway UE (<NUM>).

At operation <NUM>, method includes sending the MBMS listening status report to the MC client (<NUM>) based on the MC GW MBMS bearer announcement. At operation <NUM>, the method includes establishing the communication channel with the MC client (<NUM>) based on the parameter to receive the MC service data from the MC gateway UE (<NUM>). The MC gateway UE (<NUM>) forwards the MC service data to the MC client (<NUM>).

<FIG> is a flow chart illustrating a method, implemented by an MC client, for handling an MBMS in a wireless network, according to an embodiment of the disclosure. The operations (<NUM>-<NUM>) of flow chart <NUM> are handled by the MBMS controller (<NUM>).

At operation <NUM>, the method includes sending the MC GW MBMS bearer announcement to the MC gateway UE (<NUM>) in response to receiving information associated with the MBMS bearer and the service description associated with the MBMS bearer from the MC service server (<NUM>). The MC GW MBMS bearer announcement includes the MBMS bearer related information.

At operation <NUM>, the method includes receiving the MBMS listening status report from the MC gateway UE (<NUM>) based on the MC GW MBMS bearer announcement. At operation <NUM>, the method includes establishing the communication channel with the MC gateway UE (<NUM>) based on the at least one parameter to receive MC service data from the MC gateway UE (<NUM>). The MC gateway UE (<NUM>) forwards the MC service data to the MC client (<NUM>) over the communication channel.

The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the elements. The elements can be at least one of a hardware device, or a combination of hardware device and software module.

The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation.

Claim 1:
A method performed by a mission critical, MC, gateway, GW, user equipment, UE, supporting a multimedia broadcast multicast services, MBMS, in a wireless communication system, the method comprising:
receiving, from an MC client, an MC GW MBMS bearer announcement including MBMS bearer related information;
storing information associated with at least one temporary mobile group identity, TMGI;
activating a monitoring of an MBMS bearer based on the at least one TMGI and other MBMS bearer related information;
transmitting, to the MC client, an MC GW MBMS listening status report including non-3rd generation partnership project, 3GPP, transport resources related parameters, wherein transport resources are established between the MC client and the MC GW UE based on the non-3GPP transport resources related parameters;
receiving, from an MC service server, MC service data over the MBMS bearer; and
forwarding, to the MC client, the MC service data over the transport resources,
wherein the MC client resides on a non-3GPP device.