System and method for elastic scaling in a push to talk (ptt) platform using user affinity groups.

DIVISIONAL SUB-DIRECTOR OF PATENT FUND EXAMINATION OF MECHANICAL, ELECTRICAL AND INDUSTRIAL DESIGNS AND USEFUL MODELS

<img file="MX367276B_D0001.tif" />

PEDRO DAVID FRAGOSO LÓPEZ

Original string:

PEDRO DAVID FRAGOSO LOPEZ | 00001000000405457619 [Administration Service

Tax | 1052 || MX / 2019/67128 | MX / a / 2017/009074 | PCT patent title | 1488 | IAR | Page (s) 2 | PIF8AUTJGN83qnHZheZW6fUkMc8 =

Digital stamp:

F + zY / 9W1yo2DDdP15NfgPYG14081qARo / gpWCPy6KF6YqFcryGwJwOcuznNiz7bu3Fbv17QtyQ / VPgAHagaxs3nKPs qqV¡QmohtOyOOtRQg9VbUDSHHMfl2FON / YBX / FMLA / PjxPmon9laMleWZKS2KFEDXv1Mxx6uesiSKaJ22h1TyJ4ZSf z¡JftyRsF¡ul7TU8moq + zORB9gGWZBnluorfp8498VY8Er / q8SEhF2¡lhgNkRrk9h6Uuo + jllmNDXmsdO¡hSx39CLE 6BCF9EKrKEVM5GhPPe4H9aBI / h7MD3A3CI6ry8SxioGt9Ncqsj81 FppebndMxTD¡WWzGEGsA == * Additional information on the next page.

MX 2019 67128

SYSTEM AND METHOD FOR STATISTICAL SCALE IN ONE

PRESSURE TO TALK PLATFORM (PTT) USING GROUPS

2017/009074

OF AFFINITY

Field of the Invention

The present invention relates in general to communications through a telecommunications network, and in particular modalities, to techniques and mechanisms for a system and method for elastic press-to-speak (PTT) scaling.

Background of the Invention

A PTT call service provides different types of call services such as one-on-one (1-1) calls, pre-arranged conversation group calls, chat group calls, and ad-hoc group calls. Rigorous restrictions on call setup time and unique service usage patterns make the

<td>servid</td><td>or call</td><td>PTT</td><td>be</td><td>very different</td><td>from</td><td>a</td><td>Service</td>

<td>call</td><td>conventional</td><td>from</td><td>voice</td><td colspan="3">through protocol</td><td>from Internet</td>

<td>(VOIP)</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td>

<td></td><td>In most</td><td>from</td><td>the</td><td>topologies of</td><td>net</td><td>IP,</td><td>is incurred</td>

at a significant cost in terms of latency and use of core network resources (translation ports, network addresses (NAT), session edge controller (SBC) sessions, etc.) when configuring an IP route between a client that resides in a user device and the server. This is due to the fact that IP networks are protected by different types of demilitarized zone (DMZ) devices, such as NAT, fire breakers, SBC, load levelers, etc. In these environments, it may be necessary to incorporate firewall / NAT traversal mechanisms that use appropriate protocols (for example, session traversal utilities for NAT (STUN) and traversal using relays around NAT (TURN)), use appropriate application protocols to open interfaces in SBC, and the like. The configuration of secure communication paths often involves key exchange mechanisms, which is added to the cost of latency and consumes resources on the network equipment used for downloading secure sockets layer (SSL) / transport layer security (TLS ). Therefore, in environments where connection configuration latency affects service usability, preset, persistent sessions between client and PTT server can be used to avoid or at least reduce call setup delays.

With recent advances in technology, it is now desirable to deploy several services in visualized environments that support elastic scalability and facilitate rapid deployment through agile and continuous integration procedures. However, it is challenging to realize the benefits of elastic scaling when applying these methods

2017/009074 to a PTT service because PTT services depend on long-term, persistent, pre-established sessions and connections for effective service distribution. In addition, operator-level PTT service deployments may have stringent service availability requirements and are generally required to support geographic redundancy (for example, deployments of multiple geographically distributed sites).

In addition, in a distributed architecture, communications between PTT users can result in PTT preset session configuration with different PTT call servers. Additional signaling may result to connect these users through different PTT call server instances, which causes additional latency, particularly in cloud-shared infrastructure environments where the network is not specifically optimized to meet the service requirements of PTT call. For a service, such as a PTT service, that has to overcome the RAN latencies and still meets the rigorous requirements of call setup of fractions of a second, even milliseconds of additional latency can negatively impact the service. Therefore, it is desirable to organize communication routes to

2017/009074 avoid additional breaks.

Brief Description of the Invention

Technical advantages are generally achieved by modalities of this description that describe systems and methods for providing elastic scaling in a PTT environment.

According to one modality, a method includes receiving, for a first press-to-talk service (PTT) hosted on a processor, a session initiation request from a user's PTT client and identifying, by the

2017/009074

<td>first</td><td colspan="3">PTT service, a</td><td>group of</td><td>related.</td><td>i dad</td><td>from</td><td>users</td><td>of the</td>

<td>user</td><td>o.</td><td>The</td><td>you would know</td><td>assign</td><td colspan="2">To the group</td><td>from</td><td>affinity</td><td>from</td>

<td>user</td><td>you</td><td>from</td><td>agree with</td><td colspan="2">a prediction</td><td>of c</td><td>Thu</td><td>the user</td><td>I know</td>

<td>common</td><td colspan="2">face</td><td>with first</td><td>users</td><td>in</td><td>the</td><td colspan="2">first group</td><td>from</td>

<td colspan="2">affinity</td><td>from</td><td>users of</td><td>way more</td><td colspan="2">frequent</td><td>what</td><td colspan="2">the seconds</td>

<td>user</td><td>you</td><td>in</td><td>different</td><td>groups of</td><td>related:</td><td>Ldad</td><td>from</td><td>users.</td><td>The</td>

The method also includes determining, for the first PTT service, a PTT call server for the user affinity group. The PTT call service serves the user and the first users that belong to the user affinity group.

According to another embodiment, a press-to-talk (PTT) platform component that includes: a processor and a computer-readable storage medium that stores programming for execution by the processor. The programming includes instructions to host a session initiation protocol (SIP) representative server service, receives an INVITE SIP request from a user's PTT client, and identifies a user user affinity group. The user is assigned to the user affinity group according to a prediction that the user will communicate with first users in the user affinity group more frequently than second users in different user affinity groups. The programming includes additional instructions to determine a PTT call server for the user affinity group. The PTT call server serves the user and the first users that belong to the user affinity group.

2017/009074

According to yet another modality, a press-to-talk (PTT) platform includes a plurality of service groups. Each of the plurality of service pools provides a different function, and the plurality of service pools includes a session initiation protocol (SIP) representative server service encapsulated in a first container pool and housed in one or more first processors The SIP representative server service is configured to receive a session initiation request from a user's PTT client, identifies a user's user affinity group, and determines a first PTT call server for the user affinity group. The first PTT call server serves all users that belong to the user affinity group and assigned to a deployment site where the first PTT call server is located. The PTT platform also includes a plurality of PTT call servers. Each PTT call server of the plurality of PTT call servers is encapsulated in a second container pool and is housed in one or more second processors. The first PTT call server is one of the plurality of PTT call servers. The PTT platform also includes a user activity tracker encapsulated in a third container pool and housed in one or more third-party processors. The user activity tracker is configured to assign the user to the user affinity group. The PTT also includes a service orchestrator configured to scale a PTT platform capacity according to one or more PTT service metrics.

Brief Description of the Figures

For a more complete understanding of the present description, and the advantages thereof, reference is now made to the following descriptions taken together with the attached figures, in which:

Figure 1 illustrates a diagram of a communications network mode according to some modalities;

2017/009074

Figure 2 illustrates a block diagram of infrastructure management in a PTT platform according to some modalities;

2017/009074

<td>The</td><td>Figure</td><td> 3</td><td>illustrates a</td><td>diagram</td><td>from</td><td>blocks</td><td>from</td>

<td>different</td><td colspan="2">components</td><td>of service</td><td colspan="3">on a PTT platform</td><td>from</td>

<td>agree with</td><td>some</td><td colspan="2">modalities;</td><td></td><td></td><td></td><td></td>

<td>The</td><td>Figure</td><td> 4</td><td>illustrates a</td><td>diagram</td><td>from</td><td>blocks</td><td>from</td>

interactions between layers in a PTT platform according to some modalities;

Figures 5 and 6 illustrate block diagrams of load balancing schemes for PTT communications according to some modalities;

Figure 7 illustrates a block diagram of transmissions of a session initiation protocol for PTT communications according to some modalities;

Figures 8, 9, and 10 illustrate block diagrams of use and deployment of user affinity groups for PTT communications according to some modalities;

Figure 11 illustrates a diagram of a mode of processing system; Y

Figure 12 illustrates a diagram of a transceiver mode.

The corresponding symbols and numbers in the different figures generally refer to corresponding parts unless otherwise indicated. The

2017/009074 figures are drawn to clearly illustrate the relevant aspects of the modalities and are not necessarily drawn to scale.

Detailed description of the invention

The realization and use of the modalities of this description are discussed in more detail below. It should be appreciated, however, that the concepts described herein can be incorporated in a wide variety of specific contexts, and that the specific modalities discussed herein are simply illustrative and do not serve to limit the scope of the claims. In addition, it should be understood that different changes, substitutions and modifications may be made herein without departing from the spirit and scope of this description as defined by the appended claims.

Different modalities are described within a specific context, that is, elastic scaling for a press-to-speak (PTT) system. However, different modalities can be applied to other systems and networks where elastic scaling is desirable.

Different modalities provide an architecture to carry out a virtualized, elastically scalable, highly available, and geographically distributed PTT system that can be deployed through one or more deployment sites. Different modalities provide mechanisms to make persistent and retrieve PTT preset sessions, mechanisms for dynamically ascending and descending scaling of the system's load handling capacity, mechanisms for handling overload events (for example, PTT group calls to large groups) , mechanisms to balance the PTT service load within and across different deployment sites, and the like. In addition, different modalities present a method to minimize or at least reduce PTT call setup delays by adding related PTT subscribers in affinity groups of PTT users and anchoring subscribers belonging to the same affinity group of PTT users to the same PTT call server in the same deployment site. For example, when serving users who communicate with each other frequently on the same server

2017/009074 PTT call, additional latency for inter-server call configuration is avoided or at least reduced.

As used herein, the term "server" can be used to refer to a physical application server or a virtual application server. In modes where the PTT call server is a virtual server, the PTT call server service can be encapsulated in one or more containers, deployed, in one or more virtual machines (for example, a virtual computer node), and hosted in a physical infrastructure of a cloud network as described in more detail below. In different modalities, the PTT user affinity group adds a group of users that can communicate with each other frequently as determined in a heuristic manner when analyzing the call patterns of different users in the system. For example, user affinity groups include a plurality of users, a service on the PTT platform (for example, user activity tracker service) predicts that they will communicate with each other frequently. PTT subscribers are assigned to an affinity group of PTT users, and different affinity groups of PTT users can be dynamically distributed through PTT call server instances.

Different modalities of communications systems can therefore achieve one or more of the following characteristics and / or non-limiting advantages: virtualization and scalability; massively scalable cloud compatible platform that supports multi-site deployments, dynamic load balancing, and elastic scalability; flexible deployments across different cloud environments that include an operator's private cloud infrastructure; use of software-defined networks (SDN) and optimized or at least enhanced network function virtualization (NFV); resilience and operational efficiency; self-serviceable service logic for

2017/009074 recover automatically or semi-automatically from the

2017/009074 component failure; simple and efficient operational procedures to ensure operator-level service for different subscribers; updates in progress of zero downtime, automated (or at least reduced downtime); and facilitation of agile and continuous integration processes for a faster launch of new features.

Figure 1 illustrates a communication system 100, which provides an architecture to support a PTT communications solution in accordance with some modalities. The communication system 100 includes client devices 102, a communication network 104, and a PTT platform 106. As used herein, the term "client device" refers to any component (or collection of components) capable of establishing a connection to a communications network, such as a user equipment (UE), a mobile station (STA), a cell phone, a tablet, a laptop, and other wireless devices. The applications (hereafter referred to as PTT clients) reside in client devices 102 to access different PTT functions.

The client devices 102 can communicate with the PTT platform 106 through the network 104 (for example, internet, an IP network, or the like), which can be accessed by client devices 102 through a cellular network deployed by a operator, a WiFi network, a radio access network (RAN), other wireless networks, a wired IP network, or combinations thereof, or the like. The network 104 may include one or more components configured to provide wired or wireless network access, such as an enhanced base station (eNB), a macrocell, a femtocell, a Wi-Fi access point (AP), combinations thereof, or similar. In addition, network 104 may operate in accordance with one or more communication protocols, for example, open mobile alliance (OMA), long-term evolution (LTE), advanced LTE (LTE-A), high-speed packet access ( HSPA), Wi-Fi 802.1la / b / g / n / ac. In some embodiments, network 104 may comprise other different devices, such as relays, low power nodes, etc. The network 104 may further include return network components, such as different gateways, routers, controllers, programmers, and the like.

Subscribers to the PTT solution (for example, users operating client devices 102) can be provided in the system 100 through operator interfaces (for example, cellular operators). PTT consumers (for example, companies) can manage these subscribers to form closed groups for PTT communications. The

2017/009074 PTT solution may be in interface with the operator, for example, by including connectivity to the operator's core network, billing interfaces, provisioning interfaces, legal interception interfaces, customer service interfaces, and the like. The PTT platform 106 may provide a plurality of PTT functions to client devices 102 through the PTT clients on the client devices 102 as described in more detail below.

2017/009074

In some embodiments, the PTT 106 platform uses container technology for virtualization of a PTT system architecture, such as the virtualization of PTT services provided. Sample container technologies may include Docker, Rocket, LXD, and the like although the architecture is not limited to a specific container technology. Virtualization using container technology can allow the PTT 106 platform to adopt a micro-service model in which service clusters are considered the building blocks of the system architecture. For example, each function provided for the PTT platform 106 can be virtualized in a single service grouping, and each service grouping can perform a different function on the PTT platform 106. The PTT system architecture includes a collection of independent service pools that communicate with each other through predefined interfaces to meet service workflows. The decomposition of the system into a set of services allows each service (for example, each function provided by the PTT platform) to be deployed and managed independently. Therefore, the system's resilience can be improved as individual services failures are located. In addition, a fast and agile deployment of services can also be achieved.

In some modalities, the PTT 106 platform incorporates distributed databases, clustering technologies, data analysis tools, and high-performance messaging intermediate support to provide a robust, scalable platform. The PTT 106 platform can use fully virtualized components with a layered approach for service orchestration, which allows the PTT 106 platform to be integrated into different cloud environments, such as an operator's private cloud infrastructure, a cloud infrastructure PTT, dedicated, combinations thereof, and the like.

In some modalities, the PTT 106 platform uses container technology for virtuaüzación. In one mode the cloud environment that provides container-level orchestration application programming interfaces (APIs), the PTT 106 platform can directly use the container-level orchestration APIs to instantiate service containers as necessary. In others

2017/009074 cloud environments without container-level orchestration API, the PTT 106 platform can provide its own container management layer that is built on top of a virtual machine management layer. This approach allows the PTT platform 106 to provide an individual container-based execution environment to different service components regardless of the physical deployment environment of the PTT platform 106. Therefore, the PTT 106 platform decouples the infrastructure deployment considerations from the service deployment. In

2017/009074

<td>the Fiqura</td><td colspan="2">2 illustrates a</td><td>modality</td><td>from</td><td>architecture</td><td>from</td>

<td>Management</td><td>infrastructure</td><td>in</td><td>layers of</td><td>a</td><td>platform</td><td>PTT</td>

<td> 106 .</td><td></td><td></td><td></td><td></td><td></td><td></td>

<td>How</td><td>is illustrated by</td><td>the</td><td>Figure 2</td><td>the</td><td>architecture</td><td>from</td>

Infrastructure management 200 of the PTT platform 106 includes a service orchestration layer 202, a container management layer 204, a virtual infrastructure management layer 206, and a physical infrastructure layer 208. Each layer may include a controller, such as a virtual controller housed in a processor to perform the different functions provided by the layer, a dedicated hardware controller, and the like. In one mode, the controllers of each layer are configured as part of a boot sequence procedure for the platform. These controllers can be hosted on dedicated physical hardware or in one or more virtual computer node instances of the physical infrastructure layer 208. In modes where the controllers are hosted in the physical infrastructure layer 208, specific hardware resources can be reserved for the purpose of hosting the drivers.

The service orchestration layer 202 is the highest abstraction layer in infrastructure management architecture 200. The service orchestration layer 202 is a layer at the top of which different service components operating the PTT system operate. A service orchestrator in the service orchestration layer 202 uses service metrics to scale service pools 210 (for example, container groups can be collectively called as a service pool) for each service component (for example, the different service components illustrated in Figure 3, below). The scaling of the service pools 210 may include transmitting scaling triggers to lower layers (eg, container management layer 204). In some embodiments, the scaling of service pools 210 can be in real time. These scaling triggers can be based on service metrics transmitted to the service orchestration layer 202 of lower layers (by

2017/009074 example, container management layer 204). The service metrics mode for a PTT platform can include, for example, preset PTT session numbers, PTT call setup speed, PTT call segment setup speed (e.g. latency), number of concurrently active PTT calls , numbers of concurrently active PTT call segments,

2017/009074

<td>j number</td><td>Lnstancias</td><td>from</td><td>codec</td><td>from</td><td>media in</td><td>use</td><td>active,</td>

<td>combine</td><td>s of</td><td colspan="2">same _t</td><td>Y</td><td>Similar.</td><td colspan="2">The layer of</td>

<td>orchestration</td><td>of servic</td><td>ios</td><td> 202</td><td>t amb</td><td>who can</td><td>create</td><td>new</td>

<td>instances</td><td colspan="2">of container</td><td>for</td><td colspan="3">replace instanc</td><td>ias of</td>

<td>container</td><td>failed,</td><td>by</td><td colspan="2">example,</td><td>with base</td><td>in</td><td>failures</td>

<td>transmitted</td><td>to the cape</td><td>from</td><td colspan="2">orchestra</td><td colspan="2">service ion</td><td>2 02 of</td>

<td>layers</td><td>infei</td><td>dores</td><td>(for example,</td><td>management layer</td><td>of container</td>

<td> 204) .</td><td>The</td><td>cap</td><td>Management</td><td>container 204</td><td>operates in the</td>

<td>part</td><td colspan="2">higher</td><td>of a group</td><td>of machines v:</td><td>Írtuales, by</td>

for example, in computer nodes 212 in virtual infrastructure management layer 206) to manage the distribution of service pools 210 across different computer nodes 212. For example, container management layer 204 may manifest container instances for each grouping of services 210 through computer nodes 212. In some embodiments, the container management layer 204 tracks platform metrics (e.g., computer processing unit (CPU) metrics, random access memory (RAM) metrics, combinations thereof, and the like) through from different virtual machines and use these metrics to distribute the service container load (for example, service pools 210) through computer nodes 212. The container management layer 204 can instantiate new computer nodes to scale the system when necessary based on platform metrics. For example, the container management layer 204 may transmit scaling triggers to the virtual infrastructure management layer 206 to instantiate new computer nodes or to remove computer nodes as desired. In some embodiments, the container management layer 204 can also transmit desired computer node profiles with scaling triggers to the virtual infrastructure management layer 206.

The container management layer 204 can ensure a desired redundancy in the system when distributing

2017/009074 container instances that belong to the same service component across multiple computer nodes. The container management layer 204 also activates the creation of new computer nodes to replace failed instances. The container management layer 204 also manages groupings of computer nodes with different profiles (eg, CPU, RAM, storage, network input / output capacity (I / O), and the like), and the management layer of container 204 places service pools 210 on computer nodes 212 with a suitable profile. The container management layer 204 can also comply with container affinity policies to ensure that groups of related containers (for example a PTT server and a media server) are placed on the same host. The platform design can determine which container groups (for example, which service groups) may be related. For example, when there is a relatively high probability of intercommunication between container groups (for example, a PTT call server and a PTT media server during a PTT call), placing these container groups together on the same host will reduce the latency (for example, latency of PTT call settings and floor control operations).

The virtual infrastructure management layer 206 provides a bridge between orchestration layers (for example, service orchestration layer 202 and container management layer 204) and the physical infrastructure (for example, physical infrastructure layer 208) of the platform PTT The virtual infrastructure management layer 206 provides an abstract interface to the infrastructure in the

2017/009074

<td>cloud, physi</td><td colspan="2">ca and allows</td><td colspan="2">the PTT platform</td><td> 106</td><td>connect</td><td>to</td>

<td>different</td><td>environments</td><td>in the</td><td>cloud</td><td></td><td></td><td></td><td></td>

<td>In</td><td>some</td><td>modal</td><td>ities,</td><td>the layer</td><td>from</td><td>management</td><td>from</td>

<td colspan="2">infrastructure v</td><td>irtual</td><td> 206</td><td>e jecuta</td><td>act j</td><td>.vadores</td><td>from</td>

2017/009074 scaling received from container management layer 204 and uses the underlying infrastructure management APIs (for example, OpenStack) to build computer nodes (for example, computer nodes 212) with a requested profile . In some embodiments, the requested profile may include a combination of CPU, RAM, storage, network input / output (I / O) capacity, and the like as requested by the container management layer 204.

The physical infrastructure layer 208 can be provided as part of the operator's private cloud, a public cloud, or a combination thereof. The physical infrastructure layer 208 is a physical implementation of the virtual infrastructure management layer 206. And different PTT services are encapsulated in containers and housed in physical hardware components (eg, processors) in the physical infrastructure layer 208. In some embodiments, physical infrastructure layer 208 may use commercially available ready-to-use components (COTS), which may allow the implementation of the PTT platform 106 without specialized hardware. In addition, the physical infrastructure layer 208 may be able to span multiple data centers at different sites to provide geographic redundancy for greater resilience.

Figure 3 illustrates a block diagram of service components 300 in accordance with some embodiments. Each service component 300 can be virtualized as a single service pool 210, distributed on virtual computer nodes 212, and implemented on a private / public cloud platform as described above with respect to Figure 2. The service components 300 can be organized into one or more functional layers, such as a session layer 302, a

2017/009074

<td>cap</td><td colspan="2">Serbian</td><td>io 304, and a</td><td>management layer</td><td>from</td><td>data 306.</td>

<td></td><td>In</td><td>a</td><td>modality, the</td><td>session layer</td><td> 302</td><td>may include</td>

<td>a</td><td>servic</td><td>io</td><td>of server</td><td>representative</td><td>from</td><td>protocol of</td>

<td colspan="2">initiation</td><td>from</td><td>session (SIP)</td><td>302a, a servic</td><td>io</td><td>of registrar</td>

302b, a notification service 302c, a session border controller (SBC) service 302d, an HTTP representative server service 302e, SMS sending service 302f, a quality of service (QoS) 302g control interface adapter, or a combination thereof. The SIP representative server service 302a can route SIP traffic to corresponding services (eg, call service, presence service, and the like); It serves as a SIP load leveler; download the connection management of the internal services client; it allows services to reach the client through a common connection; or a combination thereof. Registrar service 302b can maintain client connectivity information in a database

2017/009074 (DB) that is shared with all other services (or at least a subset of). The other services may use this data to route SIP messages to the client through an appropriate SIP representative server instance. Registrar service 302b can also track the status of representative server elements and identify / retrieve connections from past client sessions in the event of a representative server element failure. Notification service 302c allows all services (or at least a subset of) to send asynchronous notifications to the client through different mechanisms such as SIP, short message services (SMS), email, and the like. In some modes, customers can always keep a transport route active with the notification service for receiving SIP notification. The SBC 302d service receives traffic entering the PTT system of the Internet Protocol (IP) multimedia subsystem (IMS) core. The SBC 302d service provides media network address (NAT) and SIP application level gateway (ALG) translation functions. The HTTP 302e representative server service may receive some or all of the HTTP traffic with respect to provision, corporate data management, and client data management. The SMS 302f sending service is used by the 302c notification service to send SMS notifications related to the user's PTT service to the customer. Some examples of SMS notifications include service activation and deactivation messages, service maintenance alerts, and the like. The QoS 302g control interface adapter provides a customizable interface to the operator's QoS control system (for example policy function and charge rules reception (Rx) interface (PCRF)) to implement dynamic QoS control logic.

In one embodiment, service layer 304 may include PTT call session service 304a, broadcast call service 304b, presence service 304c, multimedia messaging service PTT 304d, legal interception service 304e, or a combination thereof . The PTT call service 304a provides an entry point to all call services (or at least a subset of) to the PTT platform 106. The PTT 304a call service manages pre-arranged PTT sessions, for example, when handling pre-arranged group and ad-group calls, one at a time (1-1) through pre-arranged and on-demand sessions.

2017/009074

4

The PTT 304a call service also implements predictive reactivation technology (for example, as described in U.S. Patent Number 8,478,261, entitled Predictive Wakeup for Push-To-Talk-Over-Cellular (PoC) Cali Setup Optimizations, filed on July 2, 2013, whose application is hereby incorporated by reference) to distribute faster call setup times. Broadcast call service 304b implements a broadcast call service that uses PTT call services. Broadcast call service 304b implements phased distribution algorithms to provide real-time distribution to as many users as possible while avoiding overload and congestion of radio access network (RAN) of PTT call service component. Presence service 304c implements presence and location services. Presence service 304c uses a notification service 302c for distribution of location and presence information effectively using algorithms optimized for RAN. The PTT 304d multimedia messaging service provides different messaging services such as instant personal alerts, geo-tagged text, multimedia messaging, and the like. The legal interception service 304e implements the legal interception services for all other PTT services with

2017/009074 based on different regulatory requirements.

In one embodiment, the data management layer 306 may include subscriber provision service 306a, user identity management service 306b, subscriber data management service 306c, corporate data management service 306d, or a combination of the same. Subscriber provision service 306a is used to manage a subscriber life cycle on the PTT platform 106. Provides account and subscriber management API to manage subscribers individually and / or in batches. The user identity management service 306b provides different mechanisms such as short message service (SMS), email, OAuth, markup language for security confirmations (SAME), and the like to verify different user identities. Service

2017/009074 subscriber data management 306c provides APIs to different clients to configure client data (for example, contacts, groups, call policies, and the like) as desired to use different PTT system services. The corporate data management service 306d provides APIs to allow corporate administrators to configure lists and contact groups for subscribers who belong to each account of the corporation.

Although Figure 3 illustrates specific service components, a PTT platform mode may include any combination of the above components. Other service components may also be included in a system mode depending on the platform design.

Figure 4 is a block diagram 400 of interactions between different layers / container management and service orchestration modules in a PTT platform mode (eg, PTT platform 106). In some modalities, service grouping management is a function of service orchestration. As part of the service grouping management, the PTT 106 platform can perform one or more of the following non-limiting functions: service configuration and installation, automatic system scaling based on one or more capacity indicators, automatic updating of a group of load levelers when new group members are added or removed, and migration of containers from a host (for example, one virtual computer node) to another when a host is overloaded.

As illustrated by Figure 4, the container management and orchestration modules of the PTT platform 106 include a service discovery module 402, a container manager 404, a service configuration module 406, a load monitor 408, a condition monitor 410, and an application image repository 412. The different modules interact with the

2017/009074 load levelers in order to manage different service containers 416. The cargo levelers on the telecommunications service platform 106 may be interface specific, and the telecommunications service platform 106 may include a load leveler 414a for an IMS interface, a 414b load leveler for a WiFi interface, combinations thereof, and the like.

When new 416 service containers are created and the application emerges successfully (for example, when the application is installed and all its interfaces are open), the 416 service containers record their availability with the service discovery module

2017/009074

<td> 402 .</td><td>Each</td><td>Contained</td><td>? from</td><td>Serbian:</td><td>The</td><td> 416</td><td>may</td><td>be</td><td>part</td><td>from</td><td>a</td>

<td colspan="2">group</td><td colspan="2">of services</td><td>for</td><td colspan="2">provided</td><td>ionar</td><td>a</td><td>Serbian:</td><td>io</td><td>PTT</td>

<td>how</td><td>I know</td><td>describe</td><td>with</td><td colspan="2">respect</td><td>to</td><td>the</td><td colspan="2">figures 2</td><td>Y</td><td> 3,</td>

previously. Service discovery module 402 can also detect when a service container 416 fails. When a new service container 416 is registered, service discovery module 402 executes logic to allow the interfaces of the new service container to be discovered. 416 for the other components (for example, other containers and modules) in the system. Depending on the service, the discovery capacity of a new service container may be limited to the local site of the new service container the discovery capacity may cover different

2017/009074 sites.

The container manager 404 encapsulates service specific orchestration logic for different service components in the PTT platform. Container manager 404 creates new container instances based on scaling triggers received from load monitor 408 and / or service failure events received from service discovery module 402. When a new service container 416 is instantiated, the container manager 404 can also start other containers and configure other services (eg, load levelers) to support the new service container 416. In some embodiments, container manager 404 ensures that service containers 416 of a service pool are distributed across different computer nodes (for example, virtual computer nodes 212, see figure 2) in order to provide redundancy desired (for example, K redundancy). Container manager 404 can also distribute service containers 416 through different available computer nodes (for example, virtual computer nodes 212, see figure 2) to balance container load.

The service configuration module 406 provides a generic template-based configuration for different services. When a new component (for example, a new service container 416) is instantiated, the component obtains a required service configuration from a corresponding template of a service grouping to which the component belongs. In order to support automatic elastic scalability, all elements in a service pool can operate using an identical service configuration. Therefore, by using these templates, the service configuration module 406 can also ensure that any change to the service configuration of a cluster is automatically propagated to all the services grouping elements in the cluster.

Load monitor 408 is part of the real-time analytical system. Load monitor 408 can use different metrics received from containers of

2017/009074 services 416 to determine capacity indicators for each service container 416. Load monitor 428 can then generate scaling triggers based on the analysis of these capacity metrics. For some services, capacity indicator metrics may include CPU usage, RAM usage, and the like. Load monitor 408 can also monitor other metrics for other services such as media sessions, number of active SIP dialogs, transaction throughput, and the like in order to determine system load.

Load monitor 408 can also track different virtual machines (for example, computer nodes) to see if a virtual machine is overloaded due to load deflection. When overload is detected due to load diversion, load monitor 408 can activate container manager 404 to migrate service containers 416 from the host virtual machine, overloaded to another virtual machine that has available capacity. In order to support fluid container migration, applications in service containers 416 can support a state of drainage in which applications exit slowly after completing existing tasks; or migrate all existing tasks.

Different service containers 416 periodically report their condition status to condition monitor 410. Service containers 416 can ensure that internal interfaces and subsystems in a container are functional by using appropriate internal diagnostic mechanisms. When a service container failure is detected, the condition monitor 410 propagates the fault information to the service discovery module 402 and the container manager 404 in order to activate different recovery functions. For example, service discovery module 402 may cancel the registration of

2017/009074 failed instances and create new replacement instances.

The application image repository 412 stores the application container images for different service components. When a new container instance is manifested, a required image is automatically obtained from the application image repository 412 for the container.

Different modalities implement a scalability model for PTT communications. As described above, service components are implemented as a grouping of application server containers, and the service load is distributed among different grouping elements. In different modalities, application servers can receive one or more of the following types of traffic through one or more interfaces: traffic initiated by the client / user, point-to-point traffic through different components, and asynchronous tasks. Traffic initiated by the client / user may include long sessions such as PTT preset sessions, short sessions such as PTT calls, transactional load traffic (e.g., data management, presence status updates, etc.), combinations of the Same, and the like. Point-to-point traffic may include traffic between different service components (for example, between different service groups, such as between a

2017/009074 presence service and a notification service as part of the service execution flow), between the same components (for example, between the same grouping of services) to transmit information through sessions with status control managed by different instances (for example, a PTT call between two clients whose pre-established PTT sessions connect to different PTT servers), combinations thereof, and the like. Asynchronous tasks may include expiration / update of sessions, data audits, combination thereof, and the like. Modalities of load balancing schemes for different types of traffic handled by application server containers in a PTT system are described below with respect to Figures 5 and 6 below.

Figure 5 illustrates a load balancing model 500 for the traffic initiated by the client / user. In one mode, all traffic originating from outside the PTT system can first be distributed dynamically across multiple deployment sites 512, which can be achieved using Global Server Load Balancing (GSLB) based on Domain Name System (DNS) Full Domain Names (FQDN) are provided to PTT clients for different services provided by the PTT system. A DNS-GSLB 502 component at each deployment site 512 serves as the domain authority for these

2017/009074

FQDN When performing a DNS query for these FQDNs, the DNS-GSLB 502 component returns the IP address that is selected for the PTT client based on a configured geographic load distribution policy. In one embodiment, the geographical load distribution policy can be based on geographic proximity. For example, the DNS-GSLB 502 component can be configured to direct traffic to a geographically closer deployment site 512 based on the IP address of an initiator. In another embodiment, the geographical load distribution policy may be based on a return policy to the weighted point of origin. For example, the DNS-GSLB distributes traffic to different deployment sites 512 in proportion to the weighting coefficient assigned to each site. In one embodiment, a weighting factor assigned to each of the plurality of geographically diverse deployment sites is proportional to an available support load capacity of a respective site of the plurality of geographically diverse deployment sites. In these modalities, some 512 deployment sites may be larger than other 512 deployment sites. Other load distribution policies may also be used in other modalities.

In some modalities, the DNS query is carried out based on the system receiving a SIP request

2017/009074

REGISTER of a PTT client for a session. Once a deployment site 512 is selected to meet the SIP REGISTER request of a PTT client, that deployment site 512 is considered the local site for the duration of that session. In some embodiments, all services used by the client are provided from the same local site, and SIP route information can be returned in a REGISTER response to the requesting PTT client. The PTT client uses this SIP route information to direct all subsequent SIP service requests to the local site. Similarly, a specific route information can be provided to a PTT client as part of the start session establishment procedure.

Within each deployment site, all service requests of PTT clients are routed through load levelers 504, which distributes traffic to corresponding service pools 506. As described above, each service pool 1306 includes one or more containers and can provide a different PTT service. Application servers in service pools 506 can communicate and share information using a common message bus 508 and distributed database 510. Load levelers 504 support server permanence for session-based workloads such as PTT pre-established sessions. sessions of

2017/009074 chat group, subscription dialogs etc. For example, load levelers 504 can maintain session-based workloads on the same server whenever possible. Transactional workloads such as messaging, presence updates, and the like can also be distributed through 506 service pools.

Unlike the load balancing for traffic initiated by the PTT client where a representative server load balancing component serves as the entry point for session requests, one or more different load balancing strategies can be used for internal traffic between different elements within a service group and between different service groupings. Load balancing strategies used by different service components for this type of traffic may include a representative server load leveler, a return to the point of origin with internal DNS, load balancing through intermediate messaging support, or a combination thereof. A modality of a load-level representative server may be similar to the PTT client traffic load balancing scheme described above with respect to Figure 5. Traffic is routed through a representative load-leveling server, which distributes traffic to group members of the

2017/009074 service grouping and also implements session permanence if desired for that service.

Figure 6 illustrates a load balancing scheme 600 for a load balancing scheme returning to the point of origin with internal DNS. In this scheme, each grouping of services on the PTT platform is provided with unique FQDNs at the deployment site level. An example format for site-level FQDNs can be: sitel.svcl.kptt-int.com. As part of the service registration procedure, a new container associates the IP address of its interface with the FQDN of the container's service pool. Therefore, the new container element becomes visible to other service elements (for example, other service groupings), and the container will receive an appropriate share of point-to-point traffic through the return to the point of origin with DNS . For example, when a component wishes to send a message to an even component, the component queries an internal DNS 602 for a list of active IPs for that service and randomly selects one of the IP addresses of the group returned from IP. The service discovery module 604 can automatically remove the IP of failed components from DNS 602 and ensures that no traffic is directed to an insensitive or failed component.

Load balancing through support

2017/009074 Intermediate messaging may include service components that use intermediate support oriented to distributed messages to benefit from the load-balancing logic provided by a message bus. A grouping of services links a shared message queue, and intermediate messaging support distributes traffic to different elements. If some items are overdue, the delay may manifest as an increasing queue size, and intermediate messaging support can automatically accelerate traffic directed towards that item until the queue size is reduced.

Figure 7 illustrates session initiation protocol according to some modalities. A PTT platform can support SIP INVITE dialogs and call signaling for session initiation. For example, a PTT client can transmit a SIP INVITE dialog to initiate a call session. You can also use other call session initiation requests. An INVITE dialogue mode (either preset or on demand) of a PTT client is not necessarily limited to the attention of an individual PTT call. An active INVITE dialog mode can be used to answer multiple PTT calls through the same media path. For example, instead of ending as soon as a PTT call is completed, an INVITE dialog is retained to handle PTT calls

2017/009074 later involving the PTT client. INVITE dialogs are specific to the PTT client where each PTT client uses a separate INVITE dialog. Depending on whether the

2017/009074

<td>dialogue</td><td>INVITE</td><td>it is</td><td>for</td><td>a preset session or ses</td><td colspan="2">low ion</td>

<td>demand</td><td colspan="2">, a tempor</td><td colspan="2">configurable idle hoist</td><td colspan="2">It can</td>

<td>use</td><td>r for</td><td colspan="2">govern</td><td>the time that is retained on</td><td colspan="2">dialogue</td>

<td>INVITE</td><td>when</td><td>do not</td><td>there is</td><td>no media activity</td><td>in</td><td>that</td>

<td>session.</td><td colspan="2">The figure</td><td>7 i</td><td>illustrates messaging flow</td><td> 700</td><td>what</td>

Configure a PTT call session mode. The messaging flow 700 supports INVITE dialog configuration of a PTT client of origin 702 and INVITE dialog configuration for a PTT termination client 704. The messaging flow 700 is applicable for preset INVIT dialogs or on demand for both the PTT client of origin 702 as the PTT termination client 704. Because an INVITE dialogue can handle multiple calls, the successful configuration of the INVITE dialog on both PTT 702 and 704 clients may not be sufficient to complete the call setup. Additional signaling can be carried out for call setup separately on a media route (for example, a real-time transport control protocol (RTCP)) that uses a media burst control protocol (MBCP), for example, as specified in the WCO standards 2.1.

In messaging flow 700, a termination PTT call server 708 uses a notification server 710 to activate termination PTT client 704 to configure an INVITE dialog when there is no INVITE dialogue active with the PTT client 704 to process an event Call termination. For example, when the terminating PTT call server 708 receives an INVITE SIP from the originating PTT client 702, the terminating PTT call server 708 determines whether there is an active INVITE dialogue established with the terminating PTT client 704. If it is not If there is no active INVITE dialog, the PTT termination server 708 can activate the aggression of this INVITE dialogue with the PTT termination client 704 through the notification server 710.

2017/009074

In addition, in messaging flow 700, the server of

<td>PTT call</td><td>from</td><td>origin</td><td>706 can</td><td>use</td><td>data</td><td>from</td><td>registry</td>

<td>SIP and data</td><td>from</td><td>group</td><td>affinity</td><td>of user</td><td colspan="2">ios (by</td><td>example,</td>

<td>obtained from</td><td>a</td><td>manager</td><td> or base of</td><td>Data of</td><td>group</td><td>from</td><td>affinity</td>

of users 712) to identify which PTT server in a PTT system is responsible for handling a termination section of a session. For example, the source PTT call server 706 may use SIP registration data and / or user affinity group data to select a terminating, appropriate PTT call server 708 from PTT servers available in the PTT system. Although the termination section is shown in Figure 7 as being handled by a separate PTT call server 7 08, the termination PTT call server 708 may be the same server as the source PTT call server 706. Alternatively, the terminating PTT client 704 can be registered with a different calling server, and the originating PTT calling server 706 will route the termination segment of a session through that server.

The messaging flow 700 in Figure 7 can be simplified for brevity. For example, a representative SIP server and network interface layer components have been omitted from Figure 7 for a short time. A session configuration message flow mode may include any number of additional messages with any number of additional components depending on the platform design.

Different modalities implement user affinity groups for efficient handling of PTT calls. In different embodiments, all subscribers belonging to a user affinity group within a deployment site are served by the same PTT call server at that site as illustrated by the block diagram 800 of Figure 8. In another mode, user PTT clients belonging to the same user affinity group can span multiple deployment sites, by

2017/009074 example, when geographic proximity is used to

2017/009074 determine a user's local site as described above. As shown in the PTT 1-1 call flow in Figure 7, additional inter-server communication is required to configure a PTT call between users that connect to different instances of the call server

PTT By using affinity groups of PTT users, the PTT call setup time is optimized (or at least improved) by ensuring that no additional latency is incurred by inter-server communication to connect all parties involved in a call PTT

With reference to Figure 8, a PTT 802 client can transmit a registration request (for example, a SIP REGISTER) to a registrar 804. As discussed above with respect to Figure 4, a DNS query can be carried out, and a deployment site is selected to comply with the SIP REGISTER request. The deployment site with which the PTT 802 client is registered is considered the local site of the PTT 802 client. SIP log data can be transmitted to a user affinity group database 806 to route any new INVITE session on demand for the PTT 802 client initiated by any PTT call server of any site through the local PTT client site 802. In some modalities, a local site for the PTT client is selected

802 according to a geographical proximity of the PTT client

802 to different deployment sites of the PTT platform. In some embodiments, a local site for the PTT 802 client is selected according to a return-to-origin algorithm, weighted as described above.

When the PTT 802 client sends a session initiation request (for example, a SIP INVITE dialog), a representative server 808 queries a database of the user affinity group 806 to identify the user affinity group to which the user belongs PTT 802 client. In different modalities, the PTT client is more likely

2017/009074

<td colspan="2">802 communicate</td><td>with</td><td>users</td><td>in</td><td>your group of</td><td>affinity of</td>

<td>users that</td><td colspan="2">others</td><td>users</td><td>what</td><td>belong to</td><td>different</td>

<td>afi groups</td><td>nity</td><td>from</td><td>users.</td><td>The</td><td colspan="2">SIP representative server</td>

<td>808 then</td><td>may</td><td colspan="2">relay</td><td>the</td><td>INVITE dialog</td><td>to the server</td>

PTT call currently assigned to service the applicable user affinity group. If the user affinity group is not currently assigned to any PTT call server, the SIP 808 representative server can select a PTT call server for the user affinity group based on the current load factor of different servers in the PTT system For example, the SIP 808 representative server can select a PTT call server for the user affinity group based on the processing load of all PTT call server instances at the deployment site when assigning the group of user affinity In these modes, the processing load of a PTT call server is dynamically determined using the one or more performance indicator metrics, such as, PTT call configuration latency, number of preset PTT sessions, active, number of active PTT calls , number of active PTT call sections, number of media codec resources in active use, and the like.

In addition, the SIP 808 representative server can activate the creation of a new PTT call server when none of the call servers on the deployment site have sufficient capacity to handle the user affinity group (for example, when all servers are PTT call currently deployed on the deployment site are at maximum capacity). In these modalities, the SIP 808 representative server can instruct a service orchestrator to create a new PTT call server for the deployment site. The SIP 808 representative server can then assign the user affinity group to the new PTT call server.

In Figure 8, the PTT call server assigned to the user affinity group is designated as PTT 810 call server. When the PTT 810 call server receives

2017/009074 an SIP INVITE of or any user belonging to an unassigned user affinity group, the PTT 810 call server takes responsibility for the user affinity group. After that, the PTT 810 call server can serve all users belonging to the user affinity group.

In some embodiments, each PTT call server has a dedicated group of media servers for its exclusive use (for example, media servers 908 in Figure

9). As far as possible, the PTT call server places INVITE dialogs of all clients that belong to a user affinity group on the same media server. However, if there are insufficient resources on the media server to host the entire user affinity group, the PTT call server can transfer some of the INVITE dialogs to other media servers. In these modes, the PTT call server places a first portion of the INVITE dialogs on the media server and a second portion of the INVITE dialogs on different media servers.

In different modalities, user affinity groups can be defined by an analytical system that uses the call logs provided by the PTT call servers. User affinity groups can be computed by a user activity tracking system 812 that uses the call logs provided by

2017/009074 different PTT call servers (which include the PTT 810 call server). The user activity tracker system 812 can be a virtual system (for example, a grouping of services), encapsulated in one or more containers, and deployed in a processor in a cloud system as described with respect to Figure 2 previous. For example, the user activity tracker system 812 can assign the PTT 802 client to an affinity group of users who have users, with which the PTT 802 client is more likely to communicate than with other users belonging to other groups of user affinity. PTT clients can be assigned to PTT user affinity groups based on one or more of: heuristic analysis of historical user call patterns and / or user PTT group membership pattern. For example, user affinity groups based on heuristic analysis of historical call patterns can group users who call each other frequently (for example, when a number of calls between users within a predefined period of time exceeds a threshold) Assign the same PTT user affinity group. As another example, user affinity groups based on group membership patterns can assign users who are members of the same pre-arranged PTT group to the same PTT user affinity group. In case of a conflict

2017/009074 (for example, one user qualifies for more than one user affinity group),

2017/009074 the user can be assigned to the PTT user affinity group in which that user has a greater number of connections through group membership relationships. Other user affinity group conflict resolution schemes can also be used.

L advantages as affinity groups of users can be described with respect to Figure 9. Figure 9 may include some similar components as Figure 8 where like reference numerals indicate like elements. Figure 9 illustrates different connections between a PTT 802 client and PTT system components according to some modalities. The PTT 802 system can maintain one or more of the following communication routes with the system

<td>PTT:</td><td>connection of</td><td>signal</td><td>izac</td><td>ion</td><td>from</td><td>servid</td><td>or</td><td>through</td><td>from</td><td>a</td>

<td colspan="3">representative server</td><td>Yep</td><td>in</td><td>cua</td><td>1qu ie ra</td><td>from</td><td>the yes</td><td>Messes</td><td>from</td>

<td>deplo:</td><td>Legue of yes</td><td>.stema</td><td>PTT</td><td colspan="3">(sometimes</td><td colspan="2">called &lt;</td><td>how</td><td>the</td>

<td>site</td><td>of deployment</td><td>_egue</td><td colspan="3">principal</td><td> 904) ,</td><td>a</td><td colspan="2">Connection</td><td>from</td>

<td>Notif:</td><td>location of</td><td colspan="2">recover</td><td>on</td><td>from</td><td>session</td><td>to</td><td>through</td><td>from</td><td>a</td>

<td colspan="3">representative server</td><td>Yep</td><td>in</td><td>a</td><td>site</td><td>from</td><td colspan="2">deployment</td><td>of the</td>

PTT system different from the main deployment site 904 (called as the geo-redundant deployment site 906), and at least one media route through each access network (for example, Wi-Fi and cellular) to a server PTT media

7

908 on the main deployment site 904. As described

2017/009074 above with respect to Figure 8, the PTT media server 908 can be a dedicated media server of a PTT call server 810, which can be selected for PTT 802 client based on an affinity group of users of the PTT 802 client.

Different modalities can implement one or more strategies to speed up the PTT session setup time. In one mode, regional affinity is used to decrease the PTT configuration time. For example, a PTT client is routed to a closer PTT server based on the location of the PTT client. This reduces the network travel time between the PTT client and the PTT server at the time of PTT call setup. In one mode, regional affinity is achieved by configuring DNS-GSLB to direct traffic to a geographically closer deployment site based on the IP address of the source PTT client. In another mode, PTT clients are directed to a preferred deployment site that uses static mapping of each client location (for example, cell location or GPS location coordinates) to specific deployment sites.

In addition, each affinity group of PTT users can be assigned to a preferred deployment site. The preferred deployment site may be a site that has connections with a greater number of users belonging to an affinity group of PTT users. At the time of registration, customers belonging to a PTT user affinity group can be redirected to the preferred deployment site assigned to the PTT user affinity group by a registrar (for example, registrar 804). In some modalities, the affinity group deployment site of

2017/009074

<td>users will</td><td colspan="2">Choose</td><td>(by</td><td>example for</td><td>the</td><td>s:</td><td>Lstema</td>

<td>tracker</td><td>exercise</td><td>from</td><td colspan="2">user 812) so</td><td>what</td><td>the</td><td>site</td>

<td>deployment</td><td>of the group</td><td>from</td><td>afini</td><td>-dad of users</td><td>it is</td><td>the</td><td>same</td>

<td>that a site</td><td>local that</td><td>from</td><td>other</td><td>form will be</td><td colspan="3">to asqnado to</td>

PTT clients independent of the association of user affinity groups for a greater number of clients belonging to the user affinity group. For example, a potential deployment site is selected for each PTT client that belongs to the PTT user affinity group. The selection of the potential deployment site may be independent of each association of user affinity groups of the PTT client (for example, based on geographical proximity, return to the weighted point of origin, or the like). After selecting the potential deployment sites, one of the potential deployment sites selected for a larger number of PTT clients belonging to the user affinity group is assigned to the user affinity group.

9

In another embodiment, customers belonging to an affinity group of PTT users can be assigned to multiple different deployment sites (for example, based on a geographical load distribution policy). In these modalities, a PTT call server at each deployment site is selected to serve all PTT clients that belong to the PTT user affinity group and assigned to the site. Therefore, PTT clients at different sites can be served by different PTT call server instances, but within the same deployment site, all PTT clients in a user affinity group are served by the same call server PTT

2017/009074

<td></td><td colspan="2">In a</td><td>modality,</td><td>I know</td><td>jtiliza permanence</td><td colspan="2">a session</td>

<td>for</td><td colspan="2">decrease</td><td>time</td><td>from</td><td>PTT configuration</td><td>. When</td><td>a</td>

<td colspan="2">PTT client</td><td>I know</td><td>connect to</td><td>a</td><td>PTT server, the</td><td>client</td><td>PTT</td>

<td>may</td><td>need</td><td>tar</td><td>recover</td><td>a</td><td>great deal of</td><td>data,</td><td>such</td>

<td>how,</td><td>profile</td><td>from</td><td colspan="2">el service</td><td>See PTT, lists</td><td colspan="2">of contacts</td>

and groups, user settings, and the like. Data recovery can contribute to additional delays to session setup time. In some modes, this additional delay is avoided (or at least reduced) by using session permanence to take advantage of database caching. The PTT user affinity group-based load distribution logic described above can ensure that a PTT client always reconnects to the same PTT server instance because all PTT clients of a user affinity group are served by a same PTT server. Therefore, the affinity groups of PTT users can force session permanence automatically to reduce delay

2017/009074 additional.

In some modalities, session management policies based on affinity and permanence result in load diversion. For example, some server instances may load more than other server instances over time. In order to correct the load diversion that results from the affinity / permanence policy mode, a PTT system (for example, a service orchestrator of Figure 2) can implement metric-based feedback loops in the analytical system, which reassign one or more affinity groups of PTT users from an overloaded server to a less loaded server when load diversion is detected. These metrics are also used to identify when all PTT call servers in the PTT system approach the level of total capacity utilization and to automatically generate up-scale triggers for the provision of new PTT call server instances. In some modalities, the metrics may include CPU utilization and / or RAM utilization. In some embodiments, the metrics used by the PTT platform may also include one or more of the following: PTT call configuration latency, number of preset PTT sessions, active, number of call sections and active PTT calls, number of instances of Media codec in active use, and the like.

In different modalities, the affinity groups of PTT users can also improve the resilience of PTT call service. When a PTT call server controls ownership of an affinity group of PTT users, the property is announced to all PTT call servers, even through an entry in a shared database. Each session / connection status of the client can also be recorded in a shared database so that other components are informed of the set of users served by each component in the PTT system. Therefore, when a component fails, active components can control old sessions of a failed component based on the information in the database.

Figure 10 illustrates block diagram 1000 of PTT call server recovery after failure. Figure 10 may illustrate similar system components such as Figure 8 where similar reference numbers indicate similar elements. When a PTT call server is terminated (for example, PTT call server 810),

2017/009074 the affinity groups of users served by the PTT 810 call server are registered to a new PTT 1002 call server. The failure of a PTT call server is

2017/009074 can detect by the service discovery module 1004 of the connection status monitors 1006 transmitted by each PTT call server (which includes PTT call server 810) in the system.

Also, when a PTT call server instance (for example, PTT call server 810) stops working, its user affinity group ownership records are invalidated and all user affinity groups managed by the calling server PTT 810 are now considered unassigned. Subsequently, when there is a new INVITE from / to a client that belongs to an unassigned user affinity group (which includes the unassigned user affinity group that results from the failure of the PTT 810 call server), the representative server SIP 808 selects a PTT call server (for example, PTT call server 1002) to serve the unassigned user affinity group. For example, the SIP 808 representative server may select a less loaded PTT call server to serve the unassigned user affinity group as described above. The PTT 1002 call server controls ownership of the user affinity group after receiving the SIP INVITE.

After the PTT 1002 call server controls ownership of a user affinity group, all INVITE sessions belonging to the clients in the user affinity group are served by the PTT 1002 call server. If the PTT 1002 call server finds that there is no active INVITE dialog when trying to initiate a call to a PTT client, the PTT 1002 call server can use a session recovery notification connection to activate a new INVITE session configuration by the PTT 802 client. In some embodiments, the PTT 1002 call server may transmit the session recovery notification to the PTT 802 client when the user affinity group is transferred to the PTT call server 1002, when another PTT client tries to call the PTT 802 client, or Similar. To facilitate these triggers, a PTT client can maintain at least two connection paths through different deployment sites with the notification service. In other modalities, the PTT client may be able to receive unsolicited traffic from a PTT call server, and the PTT client can maintain less than two connection paths in these modalities.

2017/009074

<td>In</td><td>some modal:</td><td>items,</td><td>the server of</td><td>call</td><td>PTT</td>

<td>1002 can</td><td>implement</td><td>logic</td><td>controlled by</td><td>event</td><td>for</td>

send reconnection triggers to the client to recover from previous sessions. For example, the PTT call server 1002 sends a reconnection trigger to a PTT client when the PTT call server 1002 is not able to find a connection to implement a call with a PTT client that has an unexpired SIP INVITE dialog. This event-controlled recovery approach ensures that network overflow is avoided due to aggressive reconnections or at least reduced when there are component failures. In addition, this event-controlled recovery logic may allow a load handled by the failed PTT call server 810 to be distributed evenly among the remaining available PTT call servers. Also, when a new PTT call server instance is created

2017/009074 by the service orchestration layer (see Figure 2) as a replacement for the failed instance, the event-driven nature of this recovery mechanism ensures that the load is gradually increased in the new instance.

In the case of a failure of a complete deployment site, methods modalities for redistribution of load of different services are applied to the other deployment sites. In an modality where compliance with affinity policies is prioritized, all affinity groups of PTT users managed by the failed deployment site are reassigned to the same alternate deployment site.

In another mode where the minimization of hardware resources is the priority, the affinity groups of PTT users managed by the failed deployment site are distributed across all available deployment sites, remaining taking into account the available capacity of each deployment site. When the failed deployment site has been recovered and has been put back into active service, the affinity groups of PTT users served by the deployed deployment site before the failure can be reassigned to the recovered deployment site.

Therefore, different modalities described above provide a virtual implementation of PTT service components that use container technology in a scalable system. User affinity groups can be implemented in the system. Each user affinity group includes a user group, which can frequently communicate with each other as determined by heuristic data of user call history, user call group membership, and the like. User affinity groups provide different advantageous features, such as reduced call initiation times, increased resilience, increased redundancy, and the like.

Figure 11 illustrates a block diagram of a

2017/009074 1100 processing system mode to carry out methods described herein, which can be installed on a host device. As shown, the processing system 1100 includes a processor 1104, a memory 1806, and interfaces 1110-1114, which can be arranged (or not) as shown in Figure 11. The processor 1104 can be any component or collection of components adapted to perform calculations and / or other tasks related to processing, and the memory 1806 can be any component or collection of components adapted to store programming and / or instructions for execution by the processor 1104. In one embodiment, memory 1106 includes a non-transient computer readable memory. The interfaces 1110, 1112, 1114 can be any component or collection of components that allow the processing system 1100 to communicate with other devices / components and / or a user. For example, one or more of the interfaces 1110, 1112, 1114 can be adapted to communicate data messages, control, or processor management 1104 to applications installed on the host device and / or a remote device. As another example, one or more of the interfaces 1110, 1112, 1114 can be adapted to allow a user or user device (e.g. personal computer (PC) etc.) to interact / communicate with the processing system 1800 The system of

2017/009074 processing 1100 may include additional components not shown in Figure 11, such as long-term storage (for example, non-volatile memory, etc.).

In some embodiments, the processing system 1100 is included in a network device that accesses, or is part of, another form of, a telecommunications network. In one embodiment, the processing system 1100 is in a network side device in a wired or wireless telecommunications network, such as a base station, or relay station, a programmer, a controller, a gateway, a router , an application server, or any other device in the telecommunications network. In other embodiments, the processing system 1100 is in a user-side device that accesses a wireless or wired telecommunications network, such as a mobile station, a user equipment (UE), a personal computer (PC), a tablet, a wearable communications device (for example, a smart watch, etc.), or any other device adapted to access a telecommunications network.

In some embodiments, one or more of the interfaces 1110, 1112, 1114 connects the processing system 1100 to a transceiver adapted to transmit and receive signaling through the telecommunications network. Figure 12 illustrates a block diagram of a transceiver

2017/009074

1200 adapted to transmit and receive signaling through

2017/009074 of a telecommunications network. The 1200 transceiver can be installed on a host device. As shown, the transceiver 12200 comprises an interface of the network side 1202, a coupler 1204, a transmitter 1206, a receiver 1208, a signal processor 1210, and an interface of the device side 1212. The network side interface 1202 may include any component or collection of components adapted to transmit or receive signaling through a wired or wireless telecommunications network. The coupler 1204 may include any component or collection of components adapted to facilitate bidirectional communication through the network side interface 1202. The transmitter 1206 may include any component or collection of components (e.g., up converter, power amplifier, etc.), adapted to convert a baseband signal into a modulated carrier signal suitable for transmission through the side interface network 1202. Receiver 1208 may include any component or collection of components (e.g., down converter, low noise amplifier, etc.), adapted to convert a carrier signal received through the network side interface 1202 to a baseband signal . The signal processor 1210 may include any component or collection of components adapted to convert a baseband signal to a data signal suitable for communication through the device side interfaces 1212, or vice versa. The device-side interfaces 1212 may include any component or collection of components adapted to communicate data signals between the signal processor 1210 and components within the host device (for example, the processing system 1100, local area network ports ( LAN), etc.).

The transceiver 1200 can transmit and receive signaling through any type of communication medium. In some embodiments, transceiver 1200 transmits and receives signaling through a wireless medium. For example, transceiver 1200 may be a wireless transceiver adapted to communicate in accordance with a wireless telecommunications protocol, such as a cellular protocol (eg, long-term evolution (LTE), etc.), an area network protocol wireless local (WLAN) (for example WiFi, etc.), or any other type of wireless protocol (for example, Bluetooth, near field communication (NFC), etc.). In these embodiments, the network side interface 1202 comprises one or more radiation / antenna elements. For example, the network side interface 1202 may include a single antenna, multiple separate antennas, or a multi-antenna array configured to

2017/009074 multilayer communication, for example, one input multiple outputs (SIMO), multiple inputs one output (MISO), multiple inputs and multiple outputs (MIMO), etc. In other embodiments, transceiver 1200 transmits and receives signaling through a wired medium, for example, twisted pair cable, coaxial cable, optical fiber, etc. Transceivers and / or specific processing systems can use all the components shown, or only a subset of the components, and integration levels may vary from device to device.

According to one modality, a method includes receiving, for a first press-to-talk (PTT) service hosted on a processor, a session initiation request from a user's PTT client and identifying, by the first PTT service, a user affinity group

2017/009074

<td>user</td><td>LO.</td><td>The</td><td>user</td><td>or I know</td><td>assign to</td><td>group of</td><td>affinity</td><td>from</td>

<td>user:</td><td>The</td><td>from</td><td>agreement</td><td>with</td><td>a prediction</td><td colspan="2">.on that the user</td><td>I know</td>

<td>common:</td><td colspan="4">Lcará with first</td><td>users in</td><td>The group of</td><td>affinity</td><td>from</td>

<td>user:</td><td>The</td><td>from</td><td>shape</td><td>plus</td><td colspan="2">frequent than seconds</td><td>users</td><td>in</td>

affinity groups of different users. The method also includes determining, for the first PTT service, a server of

<td>call</td><td>PTT</td><td colspan="2">for the group</td><td>affinity</td><td>from</td><td colspan="2">users.</td><td>The</td>

<td>server</td><td>from</td><td>PTT calls</td><td>to you</td><td>.Send the user</td><td>oy</td><td>the</td><td colspan="2">first</td>

<td>users</td><td>what</td><td>they belong to</td><td colspan="2">affinity group</td><td>from</td><td>usuai</td><td>two .</td><td></td>

<td colspan="3">In one mode,</td><td>the</td><td>user is as:</td><td>igna</td><td>to the</td><td>group</td><td>from</td>

user affinity, for a user activity tracking system, according to heuristic analysis of historical user call patterns. Historical call patterns are determined according to call records provided by a plurality of PTT call servers, wherein the PTT call server is one of the plurality of PTT call servers.

2017/009074

<td></td><td>In other</td><td>modal:</td><td>Ldad,</td><td>the</td><td>user</td><td>is assigned</td><td>to the</td><td>group of</td>

<td>refine</td><td colspan="2">User age,</td><td>by</td><td>a</td><td>system</td><td>tracker</td><td>from</td><td>exercise</td>

<td colspan="2">of user, of</td><td colspan="2">agree with</td><td>a</td><td>Pattern</td><td colspan="2">of belonging</td><td>of group</td>

of the user, and the user is assigned to a user affinity group that has a greater number of connections through group membership relationships where the user qualifies for more than one user affinity group.

In one embodiment, the PTT call server comprises a group of dedicated media servers. The PTT call server places user login requests and the first users belonging to the user affinity group on the same media server of the dedicated media server group when the same media server comprises enough resources to host all Login requests. The PTT call server places a first portion of the user login requests and the first users belonging to the user affinity group on the same media server of the dedicated media server group and a second portion of the requests of user login and the first users belonging to the user affinity group on a media server different from the dedicated media server group when the same media server does not understand enough

2017/009074

<td colspan="4">Resources to host all session.</td><td>the</td><td>request s</td><td>of initiation</td><td>from</td>

<td></td><td colspan="2">In a</td><td>modality,</td><td colspan="2">the determination</td><td>of the server</td><td>from</td>

<td>call</td><td>PTT</td><td>pa</td><td>ra the group</td><td>from</td><td>affinity of</td><td colspan="2">users includes</td>

<td>to assign</td><td>the</td><td colspan="2">affinity group</td><td>i dad</td><td>of users</td><td>to the server</td><td>from</td>

<td>call</td><td>PTT</td><td>from</td><td colspan="3">agreement with proc loads</td><td>scheduling of</td><td>a</td>

<td>plurali</td><td>give</td><td>from</td><td>servers</td><td>from</td><td>PTT call</td><td>at a site</td><td>from</td>

<td>display</td><td>gue</td><td>in</td><td colspan="3">where the call server</td><td>PTT is one of</td><td>the</td>

<td>plurali</td><td>give</td><td>from</td><td>servers</td><td>from</td><td>PTT call.</td><td>Charges</td><td>from</td>

Processing can be determined according to performance metrics of the plurality of PTT call servers. Performance indicator metrics include PTT call configuration latency, a number of pre-established, active PTT sessions, a number of active PTT calls, a number of active PTT call segments, a number of media codec resources in active use, or a combination thereof.

In one mode, the PTT call server determination includes activating call server creation

PTT on a deployment site when none of the

2017/009074 PTT call servers at the deployment site have sufficient capacity for the user affinity group and that assigns the user affinity group to the PTT call server.

In one embodiment, the method also includes reallocating the different user affinity group when overload assigned to the affinity group

In one mode, for a second PTT service, PTT client and assign, by PTT client to a first first deployment site of a PTT call server the PTT call server users.

The method further includes receiving, a request for registration of the second PTT service, the one for deployment, wherein that of a plurality of site sites is one of geographically dispersed deployment of a PTT platform that provides a PTT service to the user. The assignment of the PTT client to the first deployment site is in accordance with a geographical proximity of the PTT client to the first deployment site or a weighted return to the point of origin, where a weighting coefficient assigned to each of the plurality of geographically diverse deployment sites is proportional to an available load bearing capacity of a respective site of the plurality of geographically diverse deployment sites. The method may also include redirecting the PTT client to a second deployment site of the user affinity group when the deployment site is different from the second deployment site. The method may also include selecting potential deployment sites for each PTT client from the first users belonging to the user affinity group and assigning the second deployment site for the user affinity group. The selection of potential deployment sites is independent of the user affinity group, and the second deployment site is one of the potential deployment sites selected for a larger number of PTT clients of the first users belonging to the affinity group of users. The method may also include reallocating the PTT client to a second deployment site when the first deployment site fails. The second deployment site is a different one from the plurality of geographically diverse deployment sites than the

2017/009074

<td>first site</td><td>from</td><td>deployment.</td><td></td><td></td>

<td>In</td><td>a</td><td>modality,</td><td>the method includes</td><td>further</td>

<td>to transmit,</td><td>by</td><td>the server</td><td>PTT call, a menu</td><td>get out of</td>

reconnecting to the PTT client to restore a preset PTT session when the PTT call server detects that the PTT client is online and has no PTT session preset, active.

The PTT call server transmits the reconnection message to the PTT client when the user affinity group is assigned to the PTT call server. The PTT call server transmits the reconnection message when another PTT client makes a PTT call to the PTT client.

According to another modality, a platform press-to-talk (PTT) component that includes: a processor and a computer readable storage medium that stores programming for execution by the processor. Programming includes instructions to host

2017/009074

<td>a</td><td>service</td><td>from</td><td colspan="2">server</td><td colspan="2">representative of</td><td>protocol</td><td>from</td>

<td>in:</td><td>Lciation of</td><td>session</td><td>.ón</td><td>(YEP),</td><td>I received</td><td>_r one I requested</td><td colspan="2">Ltud SIP INVITE</td>

<td>from</td><td>a client</td><td>PTT</td><td>from</td><td colspan="2">an user,</td><td colspan="2">and identify a group</td><td>from</td>

user affinity of the user. The user is assigned to the user affinity group according to a prediction that the user will communicate with first users in the user affinity group more frequently than with second users in different user affinity groups. The programming also includes instructions for determining a PTT call server for the user affinity group. The PTT call server serves the user and the first users that belong to the user affinity group.

In one mode, the user is assigned to the user affinity group, by a user activity tracking system, according to heuristic analysis of the user's historical call patterns, membership patterns

2017/009074 of the user's group, or a combination thereof.

<td>In a</td><td>modality,</td><td>the</td><td>call server</td><td>PTT</td><td>is a</td>

<td colspan="2">PTT call service</td><td colspan="2">virtual encapsulated in</td><td>one</td><td>or more</td>

<td>containers and</td><td>housed in</td><td>one</td><td>or more processors.</td><td></td><td></td>

<td>In a</td><td>modality,</td><td>the</td><td>instructions for</td><td colspan="2">decide</td>

The PTT call server further includes instructions for assigning the user affinity group to the PTT calling server according to processing loads of a plurality of PTT calling servers at a deployment site, where the PTT calling server is one of the plurality of PTT call servers.

According to yet another modality, a press-to-talk (PTT) platform includes a plurality of service groups. Each of the plurality of service pools provides a different function, and the plurality of service pools includes a session initiation protocol (SIP) representative server service encapsulated in a first container pool and housed in one or more first processors The SIP representative server service is configured to receive a session initiation request from a user's PTT client, identifies a user's user affinity group, and determines a first PTT call server for the user affinity group. The first PTT call server serves all users belonging to the user affinity group and assigned to a deployment site where the first PTT call server is located. The PTT platform also includes a plurality of PTT call servers. Each PTT call server of the plurality of PTT call servers is encapsulated in a second grouping of containers and housed in one or more second processors. The first PTT call server is one of the plurality of PTT call servers. The PTT platform also includes a user activity tracker encapsulated in a third container pool and housed in one or more third-party processors. The user activity tracker is configured to assign the user to the user affinity group. The PTT also includes a service orchestrator configured to scale a PTT platform capacity according to one or more PTT service metrics.

In one embodiment, the service orchestrator automatically replaces an out-of-service container on the PTT platform with a new container.

Although the description has been described in detail, it should be understood that different changes, substitutions, and modifications can be made without departing from the spirit and scope of this description as defined by the appended claims. In addition, it is not proposed that the scope of the description be limited to the particular modalities

2017/009074 described herein, as a person skilled in the art will readily appreciate from this description that processes, machines, manufacturing, compositions of matter, means, methods, or steps, currently existing or to be developed later, they can perform substantially the same function or achieve substantially the same result as the corresponding modalities described herein. Accordingly, it is proposed that the appended claims include within their scope these processes, machines, manufacturing, compositions of matter, means, methods, or steps.

2017/009074

NEW OF THE INVENTION

Having described the present invention as above, it is considered as a novelty and, therefore, the content in the following is claimed as property: