WO2022019816A1

WO2022019816A1 - Procedure for transferring an active group communication session between group communication servers

Info

Publication number: WO2022019816A1
Application number: PCT/SE2020/050749
Authority: WO
Inventors: Magnus TRÄNK; Katarina PALM; Jan Lidin
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2020-07-23
Filing date: 2020-07-23
Publication date: 2022-01-27

Abstract

A method for transferring an active Group Communication (GC) session between GC servers is provided. In examples discussed herein, a GC server currently hosting an active GC session for a group of GC clients can detect a trigger for transferring the active GC session to an alternative GC server. To help minimize interruption to the active GC session, the GC server determines an inactivity period (e.g., communication silence) of the active GC session and transfers the active GC session to the alternative GC server during the detected inactivity period. By detecting the trigger and the inactivity period for transferring the active GC session, it is possible to transfer the active GC session in a timely manner and minimize interruption to GC clients involved in the active GC session, thus helping to improve availability and usage of multiple GC servers in a high-availability GC system.

Description

PROCEDURE FOR TRANSFERRING AN ACTIVE GROUP COMMUNICATION SESSION BETWEEN

GROUP COMMUNICATION SERVERS

Technical Field

The technology of the disclosure relates generally to transferring an active Group Communication (GC) session between GC servers.

Background

Group Communication (GC) (e.g., Push-to-Talk) requires the same information to be delivered to multiple GC users in a GC group. A size of the GC group in terms of number of GC users can be an important parameter to efficiently set up and distribute data in a GC session associated with the GC group.

In a conventional GC system, such as Open Mobile Alliances Push-to-Talk over cellular (OMA PoC) or Third-Generation Partnership Project (3GPP) Mission Critical Push-to-Talk systems, different methods have been defined to establish, manage, and terminate GC sessions. Two often used methods (a.k.a. call models) for establishing, managing, and terminating GC sessions include the chat call model and the pre-arranged call model. The chat call model and the pre-arranged call model differ primarily in how and when the GC sessions are set up and terminated. More specifically, the signaling procedures between GC clients and GC servers are different between the chat call model and the pre-arranged call model.

In most cases, a GC group can include a predefined list of group members (a.k.a., GC clients), a set of policies for the GC group, and a selected call model to be used for all GC communication within the GC group. The choice of call model may impact part of group communication characteristics (e.g., call setup time or the usage of network and computing resources).

The chat model provides a client centric communication session establishment method.

Specifically, each GC client involved in a GC group will establish a GC session needed for the call prior to starting a media transmission. This includes negotiation of media and network parameters, encryption key material, and keeping port open in networks. The GC session may be setup for a long period of time and maintained between media transmissions.

In contrast, the pre-arranged call model provides a more server centric approach. Specifically, one GC client in a GC group sends a group call setup request to a GC server and the GC server, in turn, establishes GC sessions with all other GC clients in the GC group, including negotiation of media and network parameters, encryption key material, and so on. The pre-arranged call model does not consume as many resources between the calls, but requires more processing resources during call setup, specifically in large groups since all communication sessions for all group members must be established prior to the start of media transmission. One important performance indicator in a GC system is the call setup time. The call setup time is defined as a duration between a time at which a user presses a button to request to transmit media and a time at which the user receives a grant for the request and starts to transmit the media. The call setup time depends on various parameters, including selected call model, number of GC clients in the GC group, performance of access network, and available computing resources.

In a Mission Critical system with high-availability requirements, it is important to have an efficient backup procedure implemented such that an active GC session can continue in case a primary GC server has failed. Likewise, it is equally important to have a restoration procedure in place to allow a secondary GC server to take over the active GC session without impacting the active GC session.

A high-availability system is typically designed according to an active-standby architecture or an active-active architecture. In the active-standby architecture, one of the GC servers (e.g., a primary GC server) processes the traffic while another one of the GC servers (e.g., a secondary GC server) is on standby and ready to take over in case the primary GC server stops working. In the active-active architecture, both primary and secondary servers are partitioned to share the load of the GC traffic. For example, if the GC traffic is split equally between the primary and the secondary GC servers, each of the primary and secondary GC servers will operate with 50% of capacity. In this regard, the restoration procedure only needs to restore 50% of the GC traffic.

However, many GC clients may be involved in concurrent GC sessions, which make it difficult to perform a restoration for part of the GC clients without impacting other GC clients in the ongoing GC session. This problem is especially acute with the chat call model, since the GC session is established for a long period of time, even when no media is being transmitted. Moreover, the restoration is normally initiated only when there is no active GC session on a GC server. However, the active GC session may not end until all the GC clients have logged out. In fact, certain types of GC clients (e.g., a dispatcher at a command and control center) may never log out. As a result, the active GC session may never be terminated. Hence, it may be desirable to improve the restoration procedure in a GC system.

Summary

Embodiments disclosed herein include a method for transferring an active Group Communication (GC) session between GC servers. In examples discussed herein, a GC server currently hosting an active GC session for a group of GC clients can detect a trigger for transferring the active GC session to an alternative GC server. To help minimize interruption to the active GC session, the GC server determines an inactivity period (e.g., communication silence) of the active GC session and transfers the active GC session to the alternative GC server during the detected inactivity period. In a non-limiting example, the GC server is a backup GC server temporarily hosting an active GC session when a primary GC server originally hosting the active GC session undergoes a restoration procedure and transfers the active GC session back to the primary GC server upon completion of the restoration procedure. By detecting the trigger and the inactivity period for transferring the active GC session, it is possible to transfer the active GC session in a timely manner and minimize interruption to GC clients involved in the active GC session, thus helping to improve availability and usage of multiple GC servers in a high- availability GC system.

In one embodiment, a method performed by a GC server for transferring an active GC session is provided. The method includes detecting a trigger for transferring an active GC session associated with a GC group including a plurality of GC clients to an alternative GC server. The method also includes determining an inactivity period of the active GC session. The method also includes transferring the active GC session to the alternative GC server in the detected inactivity period.

In another embodiment, the method also includes determining that the alternative GC server is available before transferring the active GC session to the alternative GC server.

In another embodiment, wherein detecting the trigger comprises detecting one or more of: an indication that the alternative GC server is restored to service, an indication that the GC server is to be gracefully shutdown, an indication that the active GC session is not a high-priority GC session, an indication that indicates an off-peak period of a day, and an indication of a lower processing load at the GC server and/or the alternative GC server.

In another embodiment, wherein transferring the active GC session to the alternative GC server includes one or more of: updating a GC server database to indicate a release of the plurality of GC clients in the GC group, sending a request comprising an identity of the GC group to the alternative GC server, sending a reestablishing message to the plurality of GC clients, wherein the reestablishing message indicates at least one of: the active GC session has been released by the GC server and the plurality of GC clients in the GC group needs to reestablish the active GC session with the alternative GC server, and sending a reestablishing message to the alternative GC server, wherein the reestablishing message indicates at least one of: the active GC session has been released by the GC server and the alternative GC server needs to reestablish the active GC session with the plurality of GC clients in the GC group.

In another embodiment, the method also includes, at the alternative GC server, retrieving from the GC server database an identity of each of the plurality of GC clients based on the identity of the GC group, sending a request to each of the plurality of GC clients to reestablish the active GC session, and updating the GC server database to indicate that the alternative GC server is hosting the active GC session for the GC group. In another embodiment, the method also includes sending, from the alternative GC server, a reestablishing message to each of the plurality of GC clients, the reestablishing message indicating that the plurality of GC clients in the GC group needs to reestablish the active GC session with the alternative GC server.

In another embodiment, the GC server corresponds to a backup GC server and the alternative GC server corresponds to a primary GC server on which the GC group is initially established. The GC server is configured to host the GC group when the alternative GC server is taken offline to undergo a restoration procedure, detect the trigger for transferring the active GC session in response to the alternative being brought online after completing the restoration procedure, and transfer the active GC session to the alternative GC server in response to detecting the trigger for transferring the GC session.

In one embodiment, a method performed by a GC client for switching between GC servers is provided. The method includes detecting a trigger for reestablishing an active GC session associated with a GC group including the GC client with an alternative GC server. The method also includes reestablishing the active GC session with the alternative GC server in response to detecting the trigger for reestablishing the active GC session.

In another embodiment, wherein detecting the trigger for reestablishing the active GC session comprises receiving a reestablishing message from a GC server. The message indicates at least one of: the active GC session has been released by the GC server and the GC client in the GC group needs to reestablish the active GC session with the alternative GC server.

In another embodiment, wherein detecting the trigger for reestablishing the active GC session comprises receiving a reestablishing message from the alternative GC server. The reestablishing message indicates at least one of: the active GC session has been released by the GC server and the GC client in the GC group needs to reestablish the active GC session with the alternative GC server.

In another embodiment, wherein detecting the trigger for transferring the GC session comprises detecting a release of the active GC session by the GC server.

In one embodiment, a service network node is provided. The service network node includes a control system (e.g. a GC server) configured to detect a trigger for transferring an active GC session associated with a GC group including a plurality of GC clients to an alternative GC server, determine an inactivity period of the active GC session, and transfer the active GC session to the alternative GC server in the detected inactivity period.

In another embodiment, the control system is also configured to determine that the alternative GC server is available before transferring the active GC session to the alternative GC server.

In another embodiment, the control system is also configured to detect one or more of the following: an indication that the alternative GC server is restored to service, an indication that the GC server is to be gracefully shutdown, an indication that the active GC session is not a high-priority GC session, an indication that indicates an off-peak period of a day, and an indication of a lower processing load at the GC server and/or the alternative GC server.

In another embodiment, the control system is also configured to perform one or more of: updating a GC server database to indicate a release of the plurality of GC clients in the GC group, determining an identity of the alternative GC server from the GC server database, sending a request comprising an identity of the GC group to the alternative GC server, sending a reestablishing message to the plurality of GC clients, the reestablishing message indicating at least one of: the active GC session has been released by the GC server and the plurality of GC clients in the GC group needs to reestablish the active GC session with the alternative GC server, and sending a reestablishing message to the alternative GC server, the reestablishing message indicating at least one of: the active GC session has been released by the GC server and the alternative GC server needs to reestablish the active GC session with the plurality of GC clients in the GC group.

In one embodiment, a wireless device is provided. The wireless device includes a processor configured to detect a trigger for reestablishing an active GC session associated with a GC group including the GC client with an alternative GC server. The wireless device also includes a transceiver configured to reestablish the active GC session with the alternative GC server in response to detecting the trigger for reestablishing the active GC session.

In another embodiment, the transceiver is further configured to receive a reestablishing message from a GC server. The message indicates at least one of: the active GC session has been released by the GC server and the GC client in the GC group needs to reestablish the active GC session with the alternative GC server.

In another embodiment, the transceiver is further configured to receive a reestablishing message from the alternative GC server. The reestablishing message indicates at least one of: the active GC session has been released by the GC server and the GC client in the GC group needs to reestablish the active GC session with the alternative GC server.

In another embodiment, the transceiver is further configured to detect a release of the active GC session by the GC server.

Brief Description of the Drawings

The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure. Figure 1 A illustrates one example of a cellular communications system according to some embodiments of the present disclosure;

Figure 1 B is a schematic block diagram of a service network node according to some embodiments of the present disclosure;

Figure 2 is a flowchart of an exemplary process, which can be employed by the cellular communications system of Figure 1A, for transferring an active Group Communication (GC) session between multiple GC servers;

Figure 3 is a block diagram providing an exemplary illustration of an inactivity period of the active GC session during which the active GC session can be transferred from a GC server to an alternative GC server;

Figure 4 is a flowchart of an exemplary process that may be employed by a GC client involved in the active GC session for switching between GC servers;

Figure 5 is a block diagram providing an exemplary illustration of an existing GC system supporting an existing GC server restoration procedure;

Figure 6 is a block diagram providing an exemplary illustration of an improved GC system supporting an improved GC server restoration procedure according to the processes of Figures 2 and 4;

Figure 7 is a schematic block diagram of a radio access node according to some embodiments of the present disclosure;

Figure 8 is a schematic block diagram that illustrates a virtualized embodiment of the radio access node of Figure 7 according to some embodiments of the present disclosure;

Figure 9 is a schematic block diagram of the radio access node of Figure 7 according to some other embodiments of the present disclosure;

Figure 10 is a schematic block diagram of a User Equipment device (UE) according to some embodiments of the present disclosure; and

Figure 11 is a schematic block diagram of the UE of Figure 10 according to some other embodiments of the present disclosure.

Detailed Description

The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure. Radio Node: As used herein, a “radio node” is either a radio access node or a wireless communication device.

Radio Access Node: As used herein, a “radio access node” or “radio network node” or “radio access network node” is any node in a Radio Access Network (RAN) of a cellular communications network that operates to wirelessly transmit and/or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), a relay node, a network node that implements part of the functionality of a base station or a network node that implements a gNB Distributed Unit (gNB-DU)), or Wi-Fi access point based on the IEEE 802.11 or a network node that implements part of the functionality of some other type of radio access node.

Core Network Node: As used herein, a “core network node” is any type of node in a core network or any node that implements a core network function. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like. Some other examples of a core network node include a node implementing a Access and Mobility Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.

Communication Device: As used herein, a “communication device” is any type of device that has access to an access network. Some examples of a communication device include, but are not limited to: mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or Personal Computer (PC). The communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data via a wireless or wireline connection.

Wireless Communication Device: One type of communication device is a wireless communication device, which may be any type of wireless device that has access to (i.e., is served by) a wireless network (e.g., a cellular network). Some examples of a wireless communication device include, but are not limited to: a User Equipment device (UE) in a 3GPP network, Wi-Fi wireless adapter, a Machine Type Communication (MTC) device, and an Internet of Things (loT) device. Such wireless communication devices may be, or may be integrated into, a mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or PC. The wireless communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data via a wireless connection.

Network Node: As used herein, a “network node” is any node that is either part of the RAN or the core network of a cellular communications network/system.

Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.

Note that, in the description herein, reference may be made to the term “cell”; however, particularly with respect to 5G NR concepts, beams may be used instead of cells and, as such, it is important to note that the concepts described herein are equally applicable to both cells and beams.

There currently exist certain challenge(s). Specifically, in a currently available Group Communication (GC) system operating based on the active-active architecture, GC clients may be distributed over several GC servers. However, the GC clients may be involved in a GC session(s) that is associated with a GC group(s) hosted by one or more GC servers.

When a GC server fails, all GC traffic is moved from the failed GC server to a working GC server. When the failed GC server is restored and becomes available again, the GC clients may be moved back to the restored GC server. With the current GC systems, it may be difficult to determine when to perform such restoration procedures to minimize impact on ongoing media transmissions.

If the restoration procedure is delayed in an active-active architecture, a new failure on the active GC server could have a large impact on all GC clients since the GC clients are currently served by only one server. Furthermore, if the restoration procedure is delayed, a newly registered GC client in the GC group may end up being on the GC server that has just been restored. As a result, the GC session may be distributed across multiple GC servers, thus causing inefficient media distribution across multiple GC servers.

In addition to the restoration procedure, it may also be necessary to transfer an active GC session from one GC server to an alternative GC server under some other circumstances. For example, a GC server currently hosting an active GC session may need to be taken offline for upgrade and/or maintenance, thus requiring the active GC session to be transferred to an alternative GC server. As such, it may be desired to have an efficient method for transferring an active GC session between GC servers in a timely manner and with minimum impact on GC clients involved in the active GC session.

In this regard, a method for transferring an active GC session between GC servers is provided.

In examples discussed herein, a GC server currently hosting an active GC session for a group of GC clients can detect a trigger for transferring the active GC session to an alternative GC server. To help minimize interruption to the active GC session, the GC server determines an inactivity period (e.g., communication silence, no active group call) of the active GC session and transfers the active GC session to the alternative GC server during the detected inactivity period. By detecting the trigger and the inactivity period for transferring the active GC session, it is possible to transfer the active GC session in a timely manner and minimize interruption to GC clients involved in the active GC session, thus helping to improve availability and usage of multiple GC servers in a high-availability GC system.

Figure 1A illustrates one example of a cellular communications system 100 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications system 100 can be a 5G system (5GS) including a Next Generation RAN (NG-RAN) and a 5G Core (5GC) or an Evolved Packet System (EPS) including an Evolved Universal Terrestrial RAN (E- UTRAN) and an Evolved Packet Core (EPC). In this example, the RAN includes base stations 102-1 and 102-2, which in the 5GS include NR base stations (gNBs) and optionally next generation eNBs (ng-eNBs) (e.g., LTE RAN nodes connected to the 5GC) and in the EPS include eNBs, controlling corresponding (macro) cells 104-1 and 104-2. The base stations 102-1 and 102-2 are generally referred to herein collectively as base stations 102 and individually as base station 102. Likewise, the (macro) cells 104-1 and 104-2 are generally referred to herein collectively as (macro) cells 104 and individually as (macro) cell 104. The RAN may also include a number of low power nodes 106-1 through 106-4 controlling corresponding small cells 108-1 through 108-4. The low power nodes 106-1 through 106-4 can be small base stations (such as pico or femto base stations) or Remote Radio Heads (RRHs), or the like. Notably, while not illustrated, one or more of the small cells 108-1 through 108-4 may alternatively be provided by the base stations 102. The low power nodes 106-1 through 106-4 are generally referred to herein collectively as low power nodes 106 and individually as low power node 106. Likewise, the small cells 108- 1 through 108-4 are generally referred to herein collectively as small cells 108 and individually as small cell 108. The cellular communications system 100 also includes a core network 110, which in the 5G System (5GS) is referred to as the 5GC. The base stations 102 (and optionally the low power nodes 106) are connected to the core network 110.

The base stations 102 and the low power nodes 106 provide service to wireless communication devices 112-1 through 112-5 in the corresponding cells 104 and 108. The wireless communication devices 112-1 through 112-5 are generally referred to herein collectively as wireless communication devices 112 and individually as wireless communication device 112. In the following description, the wireless communication devices 112 are oftentimes UEs, but the present disclosure is not limited thereto.

The cellular communications system 100 may be configured to operate as a GC system. In this regard, the cellular communications system 100 may further include a service network 114 communicatively coupled to the core network 110. In a non-limiting example, the service network 114 includes GC servers 116, 118 and a GC server database 120.

In embodiments disclosed hereinafter, the any one or more of the communication devices 112 can be a GC client associated with a GC group and involved in an active GC session. Likewise, any of the base stations 102-1 and 102-2 and the low power nodes 106-1 through 106-4 can function as a GC server or be coupled with a GC server to host the active GC session and facilitate media communication between the GC clients. In this regard, any of the base stations 102-1 and 102-2 and the low power nodes 106-1 through 106-4 can be treated as a representation of the GC server 116 in the service network 114, which is able to transfer the active GC session to an alternative GC server 118 in the service network 114 based on the method disclosed herein.

Figure 1 B is a schematic block diagram of a service network node 122 according to some embodiments of the present disclosure. The service network node 122 may be, for example, the GC servers 116, 118 in Figure 1A or a network node that implements all or part of the functionality of the GC servers 116, 118 described herein. As illustrated, the service network node 122 includes a control system 124 that includes one or more processors 126 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory 128, and a network interface 130, which may be communicatively coupled to the core network 110 in Figure 1A. The one or more processors 126 are also referred to herein as processing circuitry.

Figure 2 is a flowchart of an exemplary process 200, which can be employed by the cellular communications system 100 of Figure 1, for transferring an active GC session between multiple GC servers. According to the process 200, a GC server 116 first detects a trigger for transferring an active GC session, which is associated with a GC group having a number of GC clients, to an alternative GC server 118 (block 202). In a non-limiting example, the trigger can include an indication that the alternative GC server 118 is restored to service, an indication that the GC server 116 is to be gracefully shutdown, an indication that the active GC session is not a high-priority GC session, an indication that indicates an off- peak period of a day, an indication of lower processing load at the GC server 116 and/or the alternative GC server 118, or any combination thereof.

In response to detecting the trigger, the GC server 116 determines an inactivity period of the active GC session (step 204). In this regard, Figure 3 is a block diagram providing an exemplary illustration of the inactivity period of the active GC session during which the active GC session can be transferred from the GC server to the alternative GC server.

With reference to Figure 3, a GC session can include a number of Talks Bursts (TBs), as shown as TB1 , TB2, TB3, and TB4 in Figure 3. As shown in Figure 3, the active GC session can have a period of silence in between group calls during which none of the GC clients in the active GC session is communicating. Herein, the periods of silence in between the group calls represent the inactivity period of the active GC session. Notably, if the period of silence lasts for an extended duration, a GC call among the GC clients may be considered as being ended. The period between TBs within on group calls are typically too short to trigger a transferring of an active GC session.

With reference back to Figure 2, upon determining the inactivity period, the GC server 116 may determine that the alternative GC server 118 is available for taking over the active GC session (block 206). Accordingly, the GC server 116 can transfer the active GC session to the alternative GC server 118 in the detected inactivity period (block 208).

In a non-limiting example, to transfer the active GC session to the alternative GC server 118, the GC server 116 can update a GC server database 120 to indicate a release of the GC clients in the GC group (block 210), send a request comprising an identity of the GC group to the alternative GC server 118 (block 212), send a reestablishing message to the GC clients (block 214), or send a reestablishing message to the alternative GC server 118 (block 216). The reestablishing message sent to the GC clients may indicate that the active GC session has been released by the GC server 116 and/or the GC clients need to reestablish the active GC session with the alternative GC server 118. The reestablishing message sent to the alternative GC server 118 may indicate that the active GC session has been released by the GC server 116 and/or the alternative GC server 118 needs to reestablish the active GC session with the GC clients in the GC group.

Figure 4 is a flowchart of an exemplary process 400 that may be employed by each of the GC clients involved in the active GC session for switching between GC servers. Specifically, any of the GC clients involved in the active GC session can detect a trigger for reestablishing the active GC session associated with a GC group including the GC client with the alternative GC server 118 (block 402). In a non-limiting example, the GC client can detect the trigger for reestablishing the active GC session by receiving the reestablishing message from the GC server 116 (block 404), receiving the reestablishing message from the alternative GC server 118 (block 406), and/or detecting a release of the active GC session by the GC server 116 (block 408). In response to detecting the trigger for reestablishing the active GC session, the GC client can reestablish the active GC session with the alternative GC server 118 in response to detecting the trigger for reestablishing the active GC session (block 410).

The reestablishing message received from the GC server 116 may indicate the active GC session has been released by the GC server 116 and the GC client in the GC group needs to reestablish the active GC session with the alternative GC server 118. The reestablishing message received from the alternative GC server 118 may indicate the active GC session has been released by the GC server 116 and the GC client in the GC group needs to reestablish the active GC session with the alternative GC server 118. In a non-limiting example, the process 200 of Figure 2 and the process 400 of Figure 4 can be employed to support an improved GC server restoration procedure. Before discussing an example of employing the process 200 of Figure 2 and the process 400 of Figure 4 to support a GC server restoration procedure, starting at Figure 6, an overview of an existing service restoration procedure is provided with reference to Figure 5.

In this regard, Figure 5 is a block diagram providing an exemplary illustration of an existing GC system supporting an existing GC server restoration procedure. An active GC session can involve multiple GC clients (e.g., GC clients 1, 2, and 3), which may also be Mission Critical (MC) clients or MC Push-to- Talk (MCPTT) clients as defined in 3GPP TS 23.379. The existing GC system includes one or more GC servers (e.g., GC servers A, B, and C), which may be MCPTT servers as defined in 3GPP TS 23.379. In addition, the existing GC system may also contain a GC server database (denoted as “GC server DB”), which may contain user and service data. An example of the GC server DB may be an MCPTT user database as defined in 3GPP TS 23.379.

In the existing GC system, an active GC session can be handled by one or more of the GC servers. Each GC client involved in the active GC session is registered to one and only one of the GC servers, known as a Participating Function (PF). Each GC session is also controlled by one and only of the GC servers, known as a Controlling Function (CF). The GC server database contains information about which GC server is controlling the active GC session.

To prevent a loss of the active GC session in the event one of the GC servers becomes unavailable, a failover procedure is executed, and a new GC server will take over the active GC session. The new GC server also updates the GC server database to publish information related to the new GC server.

Figure 6 is a block diagram providing an exemplary illustration of an improved GC system supporting an improved GC server restoration procedure according to the process 200 of Figure 2 and the process 400 of Figure 4. In a non-limiting example, the improved GC system includes multiple GC servers 600-A, 600-B, 600-C, multiple GC clients 602-1, 602-2, 602-3, and a GC server database 604. It should be appreciated that the GC system can be configured to include additional GC servers, GC clients, and/or GC server databases without affecting the operational principles discussed herein. The improved GC server restoration procedure includes one or more of the following steps.

1. A primary GC server 600-B is recovered and ready for service.

2. When a backup GC server 600-C detects that the primary GC server 600-B is ready to host the active GC session that the backup GC server 600-C has taken over, the backup GC server 600-C initiates the improved GC server restoration procedure. 3. The backup GC server 600-C starts monitoring communication activity in the active GC session to detect a certain period of silence (e.g., absence of group calls). Notably, other criteria for initiating the GC server restoration procedure may be applicable, such as no high priority GC sessions active, not during busy daytime hours, and low processing load on the GC server.

4. When such criteria are fulfilled, the backup GC Server 600-C will update the GC server database 604 to indicate that the backup GC server 600-C is no longer managing the active GC session for that particular GC group.

5. The backup GC Server 600-C subsequently releases the active GC session to each of the GC clients 600-1, 600-2, and 600-3 involved in the active GC session.

6. For any of the GC clients 600-1 , 600-2, and 600-3 having the capability to detect that the active GC session is released by the backup GC server 600-C as a result of the GC server restoration procedure, the GC client will automatically make an attempt to reestablish the active GC session with a new GC session request. The GC session request will be routed to the primary GC server 600-B. Accordingly, the active GC session will resume with the GC clients 600-1, 600-2, and 600-3 on the primary GC Server 600-B.

7. Alternatively, or additionally, the backup GC Server 600-C may use information obtained from the GC server database 604 to learn an identity of the primary GC server 600-B. Accordingly, the backup GC server 600-C can send a request to the primary GC server 600-B. The request includes an identity of the GC group the backup GC server 600-C has released.

8. The primary GC Server 600-B retrieves the identities of the GC clients 600-1 , 600-2, and 600-3 involved in the active GC session (e.g., based on the identity of the GC group) from the GC server database 604.

9. The primary GC Server 600-B sends a request to each of the GC clients 600-1 , 600-2, and 600-3 to re-establish the active GC session to the GC group. Each GC client will automatically accept the session request, if not already connected, and the active GC session will resume on the primary GC Server 600-B.

10.The primary GC Server 600-B subsequently updates the GC server database 604 with information indicating that the primary GC server 600-B is now hosting the active GC session for the GC group.

Figure 7 is a schematic block diagram of a radio access node 700 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The radio access node 700 may be, for example, a base station 102 or 106 or a network node that implements all or part of the functionality of the base station 102 or gNB described herein. As illustrated, the radio access node 700 includes a control system 702 that includes one or more processors 704 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory 706, and a network interface 708. The one or more processors 704 are also referred to herein as processing circuitry. In addition, the radio access node 700 may include one or more radio units 710 that each includes one or more transmitters 712 and one or more receivers 714 coupled to one or more antennas 716. The radio units 710 may be referred to or be part of radio interface circuitry. In some embodiments, the radio unit(s) 710 is external to the control system 702 and connected to the control system 702 via, e.g., a wired connection (e.g., an optical cable). Flowever, in some other embodiments, the radio unit(s) 710 and potentially the antenna(s) 716 are integrated together with the control system 702.

The one or more processors 704 operate to provide one or more functions of a radio access node 700 as described herein. In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 706 and executed by the one or more processors 704.

Figure 8 is a schematic block diagram that illustrates a virtualized embodiment of the radio access node 700 according to some embodiments of the present disclosure. This discussion is equally applicable to other types of network nodes. Further, other types of network nodes may have similar virtualized architectures. Again, optional features are represented by dashed boxes.

As used herein, a “virtualized” radio access node is an implementation of the radio access node 700 in which at least a portion of the functionality of the radio access node 700 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)).

As illustrated, in this example, the radio access node 700 may include the control system 702 and/or the one or more radio units 710, as described above. The control system 702 may be connected to the radio unit(s) 710 via, for example, an optical cable or the like. The radio access node 700 includes one or more processing nodes 800 coupled to or included as part of a network(s) 802. If present, the control system 702 or the radio unit(s) is connected to the processing node(s) 800 via the network 802. Each processing node 800 includes one or more processors 804 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 806, and a network interface 808.

In this example, functions 810 of the radio access node 700 described herein are implemented at the one or more processing nodes 800 or distributed across the one or more processing nodes 800 and the control system 702 and/or the radio unit(s) 710 in any desired manner. In some particular embodiments, some or all of the functions 810 of the radio access node 700 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 800. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) 800 and the control system 702 is used in order to carry out at least some of the desired functions 810. Notably, in some embodiments, the control system 702 may not be included, in which case the radio unit(s) 710 communicates directly with the processing node(s) 800 via an appropriate network interface(s).

In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of radio access node 700 or a node (e.g., a processing node 800) implementing one or more of the functions 810 of the radio access node 700 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

Figure 9 is a schematic block diagram of the radio access node 700 according to some other embodiments of the present disclosure. The radio access node 700 includes one or more modules 900, each of which is implemented in software. The module(s) 900 provides the functionality of the radio access node 700 described herein. This discussion is equally applicable to the processing node 800 of Figure 8 where the modules 900 may be implemented atone of the processing nodes 800 or distributed across multiple processing nodes 800 and/or distributed across the processing node(s) 800 and the control system 702.

Figure 10 is a schematic block diagram of a wireless communication device 1000 according to some embodiments of the present disclosure. As illustrated, the wireless communication device 1000 includes one or more processors 1002 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 1004, and one or more transceivers 1006 each including one or more transmitters 1008 and one or more receivers 1010 coupled to one or more antennas 1012. The transceiver(s) 1006 includes radio-front end circuitry connected to the antenna(s) 1012 that is configured to condition signals communicated between the antenna(s) 1012 and the processor(s) 1002, as will be appreciated by on of ordinary skill in the art. The processors 1002 are also referred to herein as processing circuitry. The transceivers 1006 are also referred to herein as radio circuitry. In some embodiments, the functionality of the wireless communication device 1000 described above may be fully or partially implemented in software that is, e.g., stored in the memory 1004 and executed by the processor(s) 1002. Note that the wireless communication device 1000 may include additional components not illustrated in Figure 10 such as, e.g., one or more user interface components (e.g., an input/output interface including a display, buttons, a touch screen, a microphone, a speaker(s), and/or the like and/or any other components for allowing input of information into the wireless communication device 1000 and/or allowing output of information from the wireless communication device 1000), a power supply (e.g., a battery and associated power circuitry), etc.

In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the wireless communication device 1000 according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

Figure 11 is a schematic block diagram of the wireless communication device 1000 according to some other embodiments of the present disclosure. The wireless communication device 1000 includes one or more modules 1100, each of which is implemented in software. The module(s) 1100 provide the functionality of the wireless communication device 1000 described herein.

Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

At least some of the following abbreviations may be used in this disclosure. If there is an inconsistency between abbreviations, preference should be given to how it is used above. If listed multiple times below, the first listing should be preferred over any subsequent listing(s).

3GPP Third Generation Partnership Project

5G Fifth Generation

5GC Fifth Generation Core

5GS Fifth Generation System

AMF Access and Mobility Function

ASIC Application Specific Integrated Circuit

AUSF Authentication Server Function CF Controlling Function

CPU Central Processing Unit eNB Enhanced or Evolved Node B

EPC Evolved Packet Core

EPS Evolved Packet System

E-UTRA Evolved Universal Terrestrial Radio Access

FPGA Field Programmable Gate Array

GC Group Communication gNB New Radio Base Station gNB-DU New Radio Base Station Distributed Unit

HSS Home Subscriber Server loT Internet of Things

LTE Long Term Evolution

MC Mission Critical

MCPTT Mission Critical Push to Talk

MME Mobility Management Entity

MTC Machine Type Communication

NEF Network Exposure Function

NF Network Function

NG-RAN Next Generation RAN

NR New Radio

NRF Network Function Repository Function

NSSF Network Slice Selection Function

OMA PoC Open Mobile Alliances Push-to-Talk over cellular

PC Personal Computer

PCF Policy Control Function

PF Participating Function

P-GW Packet Data Network Gateway

RAM Random Access Memory

RAN Radio Access Network

ROM Read Only Memory

RRH Remote Radio Head

SCEF Service Capability Exposure Function • SMF Session Management Function

• TB Talk Burst

• UDM Unified Data Management

• UE User Equipment

• UPF User Plane Function

Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.

Claims

Claims What is claimed is:

1. A method performed by a Group Communication, GC, server (116, 600-C) for transferring an active GC session, comprising: detecting (202) a trigger for transferring an active GC session associated with a GC group including a plurality of GC clients (602-1, 602-1, 602-3) to an alternative GC server (118, 600-B); determining (204) an inactivity period of the active GC session; and transferring (208) the active GC session to the alternative GC server (118) in the detected inactivity period.

2. The method of claim 1 , further comprising determining (206) that the alternative GC server (118) is available before transferring (208) the active GC session to the alternative GC server (118).

3. The method of any one of claim 1 and 2, wherein detecting the trigger comprises detecting one or more of the following: an indication that the alternative GC server (118) is restored to service; an indication that the GC server (116) is to be gracefully shutdown; an indication that the active GC session is not a high-priority GC session; an indication that indicates an off-peak period of a day; and an indication of a lower processing load at the GC server (116) and/or the alternative GC server (118).

4. The method of any one of claims 1 to 3, wherein transferring the active GC session to the alternative GC server (118) comprises one or more of: updating (210) a GC server database (120, 604) to indicate a release of the plurality of GC clients in the GC group; sending (212) a request comprising an identity of the GC group to the alternative GC server (118); sending (214) a reestablishing message to the plurality of GC clients, the reestablishing message indicating at least one of: the active GC session has been released by the GC server (116); and the plurality of GC clients in the GC group needs to reestablish the active GC session with the alternative GC server (118); and sending (216) a reestablishing message to the alternative GC server (118), the reestablishing message indicating at least one of: the active GC session has been released by the GC server (116); and the alternative GC server (118) needs to reestablish the active GC session with the plurality of GC clients in the GC group.

5. The method of claim 4, further comprising, at the alternative GC server (118): retrieving from the GC server database an identity of each of the plurality of GC clients based on the identity of the GC group; sending a request to each of the plurality of GC clients to reestablish the active GC session; and updating the GC server database to indicate that the alternative GC server (118) is hosting the active GC session for the GC group.

6. The method of claim 5, further comprising sending, from the alternative GC server (118), a reestablishing message to each of the plurality of GC clients, the reestablishing message indicating that the plurality of GC clients in the GC group needs to reestablish the active GC session with the alternative GC server (118).

7. The method of any one of claims 1 to 6, wherein: the GC server (116) corresponds to a backup GC server and the alternative GC server (118) corresponds to a primary GC server on which the GC group is initially established; and the GC server (116) is configured to: host the GC group when the alternative GC server (118) is taken offline to undergo a restoration procedure; detect the trigger for transferring the active GC session in response to the alternative being brought online after completing the restoration procedure; and transfer the active GC session to the alternative GC server (118) in response to detecting the trigger for transferring the GC session.

8. A method performed by a Group Communication, GC, client (602-1/602-2/602-3) for switching between GC servers, comprising: detecting (402) a trigger for reestablishing an active GC session associated with a GC group including the GC client with an alternative GC server (118, 600-B); and reestablishing (410) the active GC session with the alternative GC server (118) in response to detecting the trigger for reestablishing the active GC session.

9. The method of claim 8, wherein detecting (402) the trigger for reestablishing the active GC session comprises receiving (404) a reestablishing message from a GC server (116, 600-C), the message indicating at least one of: the active GC session has been released by the GC server (116); and the GC client in the GC group needs to reestablish the active GC session with the alternative GC server (118).

10. The method of any one of claims 8 and 9, wherein detecting (402) the trigger for reestablishing the active GC session comprises receiving (406) a reestablishing message from the alternative GC server (118), the reestablishing message indicating at least one of: the active GC session has been released by the GC server (116); and the GC client in the GC group needs to reestablish the active GC session with the alternative GC server (118).

11. The method of any one of claims 8 to 10, wherein detecting (402) the trigger for transferring the GC session comprises detecting (408) a release of the active GC session by the GC server (116).

12. A service network node (122), comprising: a control system (124) configured to: detect (202) a trigger for transferring an active GC session associated with a GC group including a plurality of GC clients (602-1, 602-1, 602-3) to an alternative GC server (118, 600-B); determine (204) an inactivity period of the active GC session; and transfer (208) the active GC session to the alternative GC server (118) in the detected inactivity period.

13. The service network node of claim 12, wherein the control system (124) is further configured to determine (206) that the alternative GC server (118) is available before transferring (208) the active GC session to the alternative GC server (118).

14. The service network node of any one of claims 12 and 13, wherein the control system (124) is further configured to detect one or more of the following: an indication that the alternative GC server (118) is restored to service; an indication that the GC server (116) is to be gracefully shutdown; an indication that the active GC session is not a high-priority GC session; an indication that indicates an off-peak period of a day; and an indication of a lower processing load at the GC server (116) and/or the alternative GC server (118).

15. The service network node of any one of claims 12 to 14, wherein the control system (124) is further configured to perform one or more of: updating (210) a GC server database (120, 604) to indicate a release of the plurality of GC clients in the GC group; sending (212) a request comprising an identity of the GC group to the alternative GC server (118) ; sending (214) a reestablishing message to the plurality of GC clients, the reestablishing message indicating at least one of: the active GC session has been released by the GC server (116); and the plurality of GC clients in the GC group needs to reestablish the active GC session with the alternative GC server (118); and sending (216) a reestablishing message to the alternative GC server (118), the reestablishing message indicating at least one of: the active GC session has been released by the GC server (116); and the alternative GC server (118) needs to reestablish the active GC session with the plurality of GC clients in the GC group.

16. A wireless device, comprising: a processor (1002) configured to detect (402) a trigger for reestablishing an active GC session associated with a GC group including the GC client with an alternative GC server (600-B); and a transceiver (1006) configured to reestablish (410) the active GC session with the alternative GC server (600-B) in response to detecting the trigger for reestablishing the active GC session.

17. The wireless device of claim 16, wherein the transceiver (1006) is further configured to receive (404) a reestablishing message from a GC server (600-C), the message indicating at least one of: the active GC session has been released by the GC server (600-C); and the GC client in the GC group needs to reestablish the active GC session with the alternative GC server (600-B).

18. The wireless device of any one of claims 16 and 17, wherein the transceiver (1006) is further configured to receive (406) a reestablishing message from the alternative GC server (600-B), the reestablishing message indicating at least one of: the active GC session has been released by the GC server (600-C); and the GC client in the GC group needs to reestablish the active GC session with the alternative GC server (600-B).

19. The wireless device of any one of claims 16 to 18, wherein the transceiver (1006) is further configured to detect (408) a release of the active GC session by the GC server (600-C).