Patent Application
20250126680
The present invention generally relates to field of wireless communication, and more particularly to a method and system for managing the call setup related parameters.
5G mobile communication technologies define broad frequency bands such that high transmission rates and new services are possible, and can be implemented not only in “Sub 6 GHz” bands such as 3.5 GHz, but also in “Above 6 GHz” bands referred to as mmWave including 28 GHz and 39 GHz. In addition, it has been considered to implement 6G mobile communication technologies (referred to as Beyond 5G systems) in terahertz bands (for example, 95 GHz to 3 THz bands) in order to accomplish transmission rates fifty times faster than 5G mobile communication technologies and ultra-low latencies one-tenth of 5G mobile communication technologies.
At the beginning of the development of 5G mobile communication technologies, in order to support services and to satisfy performance requirements in connection with enhanced Mobile BroadBand (eMBB), Ultra Reliable Low Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), there has been ongoing standardization regarding beamforming and massive MIMO for mitigating radio-wave path loss and increasing radio-wave transmission distances in mmWave, supporting numerologies (for example, operating multiple subcarrier spacings) for efficiently utilizing mmWave resources and dynamic operation of slot formats, initial access technologies for supporting multi-beam transmission and broadbands, definition and operation of BWP (BandWidth Part), new channel coding methods such as a LDPC (Low Density Parity Check) code for large amount of data transmission and a polar code for highly reliable transmission of control information, L2 pre-processing, and network slicing for providing a dedicated network specialized to a specific service.
Currently, there are ongoing discussions regarding improvement and performance enhancement of initial 5G mobile communication technologies in view of services to be supported by 5G mobile communication technologies, and there has been physical layer standardization regarding technologies such as V2X (Vehicle-to-everything) for aiding driving determination by autonomous vehicles based on information regarding positions and states of vehicles transmitted by the vehicles and for enhancing user convenience, NR-U (New Radio Unlicensed) aimed at system operations conforming to various regulation-related requirements in unlicensed bands, NR UE Power Saving, Non-Terrestrial Network (NTN) which is UE-satellite direct communication for providing coverage in an area in which communication with terrestrial networks is unavailable, and positioning.
Moreover, there has been ongoing standardization in air interface architecture/protocol regarding technologies such as Industrial Internet of Things (IIoT) for supporting new services through interworking and convergence with other industries, IAB (Integrated Access and Backhaul) for providing a node for network service area expansion by supporting a wireless backhaul link and an access link in an integrated manner, mobility enhancement including conditional handover and DAPS (Dual Active Protocol Stack) handover, and two-step random access for simplifying random access procedures (2-step RACH for NR). There also has been ongoing standardization in system architecture/service regarding a 5G baseline architecture (for example, service based architecture or service based interface) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) for receiving services based on UE positions.
As 5G mobile communication systems are commercialized, connected devices that have been exponentially increasing will be connected to communication networks, and it is accordingly expected that enhanced functions and performances of 5G mobile communication systems and integrated operations of connected devices will be necessary. To this end, new research is scheduled in connection with extended Reality (XR) for efficiently supporting AR (Augmented Reality), VR (Virtual Reality), MR (Mixed Reality) and the like, 5G performance improvement and complexity reduction by utilizing Artificial Intelligence (AI) and Machine Learning (ML), AI service support, metaverse service support, and drone communication.
Furthermore, such development of 5G mobile communication systems will serve as a basis for developing not only new waveforms for providing coverage in terahertz bands of 6G mobile communication technologies, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), array antennas and large-scale antennas, metamaterial-based lenses and antennas for improving coverage of terahertz band signals, high-dimensional space multiplexing technology using OAM (Orbital Angular Momentum), and RIS (Reconfigurable Intelligent Surface), but also full-duplex technology for increasing frequency efficiency of 6G mobile communication technologies and improving system networks, AI-based communication technology for implementing system optimization by utilizing satellites and AI (Artificial Intelligence) from the design stage and internalizing end-to-end AI support functions, and next-generation distributed computing technology for implementing services at levels of complexity exceeding the limit of UE operation capability by utilizing ultrahigh-performance communication and computing resources.
This summary is provided to introduce a selection of concepts, in a simplified format, that are further described in the detailed description of the disclosure. This summary is neither intended to identify key or essential inventive concepts of the disclosure and nor is it intended for determining the scope of the disclosure.
In accordance with some example embodiments of the present subject matter, a method for handling at least one call set up parameter for a remotely initiated Mission Critical Push-To-Talk (MCPTT) call is disclosed. The method includes receiving, by a second MCPTT client, a remotely initiated MCPTT call request from a first MCPTT client via a MCPTT server to initiate a remote call, wherein the remotely initiated MCPTT call request comprises the at least one call set up parameter. The method includes notifying, by the second MCPTT client, the first MCPTT client, that the second MCPTT client received the remotely initiated MCPTT call request via the MCPTT server. The method includes initiating, by the second MCPTT client, the MCPTT remote call with one of the first MCPTT client and at least one other MCPTT client using the at least one call set up parameter and an indication.
In accordance with some example embodiments of the present subject matter, a system for handling at least one call set up parameter for a remotely initiated MCPTT call is disclosed. The system includes receiving, by a second MCPTT client, a remotely initiated MCPTT call request from a first MCPTT client via a MCPTT server to initiate a remote call, wherein the remotely initiated MCPTT call request comprises the at least one call set up parameter. The system includes notifying, by the second MCPTT client, the first MCPTT client, that the second MCPTT client received the remotely initiated MCPTT call request via the MCPTT server. The system includes initiating, by the second MCPTT client, the MCPTT remote call with one of the first MCPTT client and at least one other MCPTT client using the at least one call set up parameter and an indication.
To further clarify advantages and features of the present disclosure, a more particular description of the disclosure will be rendered by reference to specific embodiments thereof, which is illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the disclosure and are therefore not to be considered limiting of its scope. The disclosure will be described and explained with additional specificity and detail with the accompanying drawings.
These and other features, aspects, and advantages of the present disclosure will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:
Further, skilled artisans will appreciate that elements in the drawings are illustrated for simplicity and may not have necessarily been drawn to scale. For example, the flow charts illustrate the method in terms of the most prominent steps involved to help to improve understanding of aspects of the present disclosure. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the embodiments of the present disclosure so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having benefit of the description herein.
The Mission Critical services would be requiring a feature that allows an authorized user, typically a dispatcher, to cause a remote MCPTT client at MCPTT UE to initiate a MCPTT Private or MCPTT Group call by itself, without its user explicitly initiating the call by depressing the MCPTT switch. The remotely initiated MCPTT services communication procedures are described in the specification 3GPP TS 23.379. The purpose of this feature allows the dispatcher to listen to activities at the location of the remote MCPTT UE to find out what is happening around that MCPTT UE. The typical use cases for this feature are where a user incapacitated, a stolen MCPTT UE undercover operation, discreet surveillance of users or investigations, and could exist depending on the missions of the critical communications users and on legislations. There is a need for the communication to ensure it is set up even in case of resource congestion or to limit disturbance by other services and using required call setup parameters. Hence, it is essential for managing the required call setup parameters information by authorized user/remote MCPTT client/MCPTT server and desired behavior of the call.
There are number of call setup parameters that are required while initiating a call at remote MCPTT client at MCPTT UE such as requested application priority level, commencement mode, functional alias to be used as the called/calling party, requester of remotely initiated call request, indication of the call initiation is due to receiving of remotely initiated call request from authorized user, etc. Without these parameters the essential requirement of the remotely initiated call request feature can't be achieved (e.g. call to be established with highest priority or low priority etc).
Currently there is no mechanisms exists through which the authorized user can specify which call set up parameters to be used in the Private or Group communication which is triggered at the remote MCPTT client at MCPTT UE on receiving the remotely initiated call request.
There is a need to overcome above-mentioned drawbacks.
For promoting an understanding of the principles of the disclosure, reference will now be made to the embodiment illustrated in the drawings and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the disclosure is thereby intended, such alterations and further modifications in the illustrated system, and such further applications of the principles of the disclosure as illustrated therein being contemplated as would normally occur to one skilled in the art to which the disclosure relates.
It will be understood by those skilled in the art that the foregoing general description and the following detailed description are explanatory of the disclosure and are not intended to be restrictive thereof.
Reference throughout this specification to “an aspect”, “another aspect” or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, appearances of the phrase “in an embodiment”, “in another embodiment” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.
The terms “comprises”, “comprising”, or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process or method that comprises a list of steps does not include only those steps but may include other steps not expressly listed or inherent to such process or method. Similarly, one or more devices or sub-systems or elements or structures or components proceeded by “comprises . . . a” does not, without more constraints, preclude the existence of other devices or other sub-systems or other elements or other structures or other components or additional devices or additional sub-systems or additional elements or additional structures or additional components.
Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skilled in the art to which this disclosure belongs. The system, methods, and examples provided herein are illustrative only and not intended to be limiting.
The remote MCPTT call may be one of a remote private call and a remote group call. The remote private call may be placed between the at least two amongst the first MCPTT client 102, the second MCPTT client 106 and the at least one other MCPTT client. Furthermore, the remote group call may be placed between each of the first MCPTT client 102, the second MCPTT client 106 and the at least one other MCPTT client. Moving forward, the first MCPTT client 102, the second MCPTT client 106 and the at least one other MCPTT client may be a User Equipment (UE). Examples of the UE may include, but are not limited to, a smartphone, a tablet, a Personal Computer (PC), and a laptop. The remote MCPTT call may be placed via the MCPTT server 104 and the MCPTT server 104 may be serving as a communication medium between each of first MCPTT client 102, the second MCPTT client 106 and the at least one other MCPTT client.
Continuing with an embodiment of the present subject matter, the second MCPTT client 106 may be configured to receive a remotely initiated MCPTT call request. The remotely initiated MCPTT call request may be transmitted by the first MCPTT client 102 to request the second MCPTT client 106 to initiate the remote call. The remotely initiated MCPTT call request may be received by the second MCPTT client 106 via the MCPTT server 104 as the first MCPTT client 102 may transmit the remotely initiated MCPTT call request via the MCPTT server 104. Further, the remotely initiated MCPTT call request may include at least one call set up parameter.
In response to receiving the remotely initiated MCPTT call request, the second MCPTT client 106 may be configured to acknowledge a receiving of the remotely initiated MCPTT call request. For acknowledging, the second MCPTT client 106 may be configured to notify the first MCPTT client 102 that the second MCPTT client 106 received the remotely initiated MCPTT call request. The second MCPTT client 106 may be configured to notify the first MCPTT client 102 via the MCPTT server 104 such that the second MCPTT client 106 may notify the MCPTT server 104 and the MCPTT server 104 may further communicate with the first MCPTT client 102 to notify about the receiving of the remotely initiated MCPTT call request.
Continuing with the above embodiment, upon notifying the first MCPTT client 102, the second MCPTT client may be configured to initiate the MCPTT remote call. The MCPTT remote call may be initiated with one of the first MCPTT client and the at least one other MCPTT client. The remote MCPTT call may be initiated using the at least one call set up parameter received by the second MCPTT client 106 in the remotely initiated MCPTT call request and an indication related to the second MCPTT client 106.
The MCPTT server 104 may include a processor 202, a memory 204, data 206, module(s) 208, resource(s) 210, a display unit 212, a communication engine 214, an authorization engine 216.
In an embodiment, the processor 202, the memory 204, the data 206, the module(s) 208, the resource(s) 210, the display unit 212, the communication engine 214, and the authorization engine 216.
As would be appreciated, the MCPTT server 104, may be understood as one or more of a hardware, a software, a logic-based program, a configurable hardware, and the like. In an example, the processor 202 may be a single processing unit or a number of units, all of which could include multiple computing units. The processor 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, processor cores, multi-core processors, multiprocessors, state machines, logic circuitries, application-specific integrated circuits, field-programmable gate arrays and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor 202 may be configured to fetch and/or execute computer-readable instructions and/or data stored in the memory 204.
In an example, the memory 204 may include any non-transitory computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and/or dynamic random access memory (DRAM), and/or non-volatile memory, such as read-only memory (ROM), erasable programmable ROM (EPROM), flash memory, hard disks, optical disks, and/or magnetic tapes. The memory 204 may include the data 206. The data 206 serves, amongst other things, as a repository for storing data processed, received, and generated by one or more of the processor 202, the memory 204, the module(s) 208, the resource(s) 210, the display unit 212, the communication engine 214, and the authorization engine 216.
The module(s) 208, amongst other things, may include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement data types. The module(s) 208 may also be implemented as, signal processor(s), state machine(s), logic circuitries, and/or any other device or component that manipulate signals based on operational instructions.
Further, the module(s) 208 may be implemented in hardware, as instructions executed by at least one processing unit, e.g., processor 202, or by a combination thereof. The processing unit may be a general-purpose processor that executes instructions to cause the general-purpose processor to perform operations or, the processing unit may be dedicated to performing the required functions. In another aspect of the present disclosure, the module(s) 208 may be machine-readable instructions (software) which, when executed by a processor/processing unit, may perform any of the described functionalities.
In some example embodiments, the module(s) 208 may be machine-readable instructions (software) which, when executed by a processor 202/processing unit, perform any of the described functionalities.
The resource(s) 210 may be physical and/or virtual components of the MCPTT server 104 that provide inherent capabilities and/or contribute towards the performance of the MCPTT server 104. Examples of the resource(s) 210 may include, but are not limited to, a memory (e.g., the memory 204), a power unit (e.g., a battery), a display unit (e.g., the display unit 212) etc. The resource(s) 210 may include a power unit/battery unit, a network unit, etc., in addition to the processor 202, and the memory 204.
The display unit 212 may display various types of information (for example, media contents, multimedia data, text data, etc.) to the MCPTT server 104. The display unit 212 may include, but is not limited to, a liquid crystal display (LCD), a light-emitting diode (LED) display, an organic LED (OLED) display, a plasma cell display, an electronic ink array display, an electronic paper display, a flexible LCD, a flexible electrochromic display, and/or a flexible electrowetting display.
Continuing with the above embodiment, the communication engine 214 may be configured to receive a remotely initiated MCPTT call request from the first MCPTT client 102. The first MCPTT client 102 may transmit the remotely initiated MCPTT call request to the MCPTT server 104 with an intention of the remotely initiated MCPTT call request being forwarded to the second MCPTT client by the MCPTT server 104. The remotely initiated MCPTT call request may be transmitted to the second MCPTT client to request the second MCPTT client to initiate a remote MCPTT call with one of the first MCPTT client 102 and the at least one other MCPTT client. The remote MCPTT call may be one of a remote private call and a remote group call.
Further, the remotely initiated MCPTT call request may include at least one call set up parameter. Examples of the call set up parameters may include, but are not limited to, a requested application priority level, a requested commencement mode, a remotely initiated-call request indicator, a requester of the remotely initiated MCPTT call request, a functional alias to be used as the first MCPTT client 102 and the second MCPTT client 106. The function alias may be activated prior to utilizing by the first MCPTT client 102 and the second MCPTT client 106. In an embodiment of the present subject matter, the second MCPTT client 106 may be including the at least call set up parameter configured at the second MCPTT client 106 prior to receiving the remotely initiated MCPTT call request.
Continuing with the above embodiment, in response to receiving the remotely initiated MCPTT call request by the communication engine 214, the authorization engine 216 may be configured to perform a verification of the first MCPTT client 102. The verification may be performed to authorize the first MCPTT client 102. Moving forward, in response to a successful authorization of the first MCPTT client 102, the communication engine 214 may be configured to transmit the remotely initiated MCPTT call request to the second MCPTT client 106.
Subsequent to transmitting the remotely initiated MCPTT call request to the second MCPTT client 106, the communication engine 214 may be configured to receive a notification from the second MCPTT client 106. The notification may further be needed to be transmitted to the first MCPTT client 102. The notification may be an acknowledgement by the second MCPTT client 106 that the remotely initiated MCPTT client request is received by the second MCPTT client 106. In response, the communication engine 214 may be configured to transmit the notification to the first MCPTT client 102.
Subsequently, the remote MCPTT call may be one of a remote private call and a remote group call. In an embodiment of the present subject matter, the first MCPTT client 102 may be requesting the second MCPTT client 106 to initiate a remote private call with one of the first MCPTT client 102 and the at least one other MCPTT client. In another embodiment of the present subject matter, the first MCPTT client 102 may be requesting the second MCPTT client 106 to initiate the remote group call with one of the first MCPTT client 102, and the at least one other MCPTT client, and the at least other MCPTT client.
Further, examples of the at least one call set up parameter may include, but are not limited to, a requested application priority level, a requested commencement mode, a remotely initiated-call request indicator, a requester of the remotely initiated MCPTT call request, a functional alias to be used as the first MCPTT client 102 and the second MCPTT client 106. The function alias may be activated prior to utilizing by the first MCPTT client 102 and the second MCPTT client 106.
At step 302, the process 300 may include transmitting the remotely initiated MCPTT call request to the MCPTT server 104. The remotely initiated MCPTT call request may include the at least one call set up parameter. The remotely initiated MCPTT call request may be transmitted by the first MCPTT client 102. The MCPTT server 104 may be configured to receive the remotely initiated MCPTT call request. Subsequently, Table 1 depicts the at least one call set up parameter for the remotely initiated MCPTT call request from the first MCPTT client 102 to the MCPTT server 104 and from the MCPTT server 104 to the second MCPTT client 106.
At step 304, the process 300 may include checking by the MCPTT server 104 whether the first MCPTT client 102 is authorized to request the second MCPTT client 106 to initiate the remote MCPTT call upon receiving the remotely initiated MCPTT call request intended to be transmitted to the second MCPTT client 106 from the first MCPTT client 102.
At step 306, the process 300 may include transmitting by the MCPTT server 104, the remotely initiated MCPTT call request along with the at least one call set up parameter to the second MCPTT client 106 as intended by the first MCPTT client 102 at the time of transmitting the remotely initiated MCPTT call request to the MCPTT server 104. The remotely initiated MCPTT call request may be transmitted by the MCPTT server 104 in response to determining that the first MCPTT client 102 is authorized to request the second MCPTT client 106 to initiate the remote call. Continuing with the above embodiment, the second MCPTT client 106 may be configured to receive the remotely initiated MCPTT call request from the MCPTT server 104.
At step 308, the process 300 may include notifying the server 304 by the second MCPTT client 106 that the remotely initiated MCPTT call request is received by the second MCPTT client 106. In an embodiment, the MCPTT server 104 may be notified by transmitting a remotely initiated MCPTT call response by the second MCPTT client 106 to the MCPTT server 104.
At step 310, the process 300 may include notifying the first MCPTT client 102, by the MCPTT server 104 that the remotely initiated MCPTT call request is received by the second MCPTT client 106. The first MCPTT client 102 may be notified by the MCPTT server 104 by transmitting the remotely initiated MCPTT call response to the first MCPTT client 102.
At step 312, the process 300 may include initiating by the second MCPTT call the remote MCPTT call with one or more of the first MCPT client and the at least one other MCPTT client. In an embodiment, the second MCPTT client 106 may initiate the remote private call with one of the first MCPTT client 102 and the at least one other client as requested in the remotely initiated MCPTT call request. In another embodiment, the second MCPTT client 106 may initiate the remote group call with one of the first MCPTT client 102, and the at least one other CMPTT client, and the at least one other MCPTT client as requested in the remotely initiated MCPTT call request. The remote MCPTT call may be initiated by using the at least one call set up parameter transmitted by the first MCPTT client 102 and an indication related to the second MCPTT client 106. The indication may indicate indicates whether the initiation of the MCPTT remote call is due to receiving of the remotely initiated MCPTT call request from the first MCPTT client 102. In an embodiment of the present subject matter, the steps 308 and 310 may not occur as the remote call initiated by the second MCPTT client 106 may be identified as an acknowledgment that the second MCPTT client 106 received the remotely initiated MCPTT call request. In another embodiment of the present subject matter, the steps 308 and 310 may occur after the step 312.
In an embodiment of the present subject matter, the process 300 may disclose a prearranged group call procedure where the first MCPTT client 102 may be initiating an MCPTT group call also referred as the remote group call with a unicast signaling for communicating with the affiliated MCPTT members of a group such as the second MCPTT client 106 and the at least one other MCPTT client. If the initiating of the MCPTT group call is due to receiving of remotely initiated MCPTT call request and the at least one call setup parameter is shared in the remotely initiated MCPTT call request, then the at least one call setup parameter is used while initiating the MCPTT group call.
In another embodiment of the present subject matter, the process 300 may disclose a private call procedure where the first MCPTT client 102 may be initiating an MCPTT private call also referred as the remote group call with a unicast signaling for communicating with another MCPTT user such as the second MCPTT client 106, with or without a floor control enabled, and a commencement mode as automatic or manual. If the initiating of the MCPTT private call is due to receiving of the remotely initiated MCPTT call request and the at least one call setup parameter is shared in the remotely initiated MCPTT call request, then the at least one call setup parameter is used while initiating the MCPTT private call.
At step 402, the process 400 may include transmitting the remotely initiated MCPTT call request to the MCPTT server 104. The remotely initiated MCPTT call request may be transmitted by the first MCPTT client 102. The MCPTT server 104 may be configured to receive the remotely initiated MCPTT call request.
At step 404, the process 400 may include checking by the MCPTT server 104 whether the first MCPTT client 102 is authorized to request the second MCPTT client 106 to initiate the remote MCPTT call upon receiving the remotely initiated MCPTT call request intended to be transmitted to the second MCPTT client 106 from the first MCPTT client 102.
At step 406, the process 400 may include transmitting by the MCPTT server 104, the remotely initiated MCPTT call request to the second MCPTT client 106 as intended by the first MCPTT client 102 at the time of transmitting the remotely initiated MCPTT call request to the MCPTT server 104. The remotely initiated MCPTT call request may be transmitted by the MCPTT server 104 in response to determining that the first MCPTT client 102 is authorized to request the second MCPTT client 106 to initiate the remote call. Continuing with the above embodiment, the second MCPTT client 106 may be configured to receive the remotely initiated MCPTT call request from the MCPTT server 104.
At step 408, the process 400 may include notifying the server 404 by the second MCPTT client 106 that the remotely initiated MCPTT call request is received by the second MCPTT client 106. In an embodiment, the MCPTT server 104 may be notified by transmitting a remotely initiated MCPTT call response by the second MCPTT client 106 to the MCPTT server 104.
At step 410, the process 400 may include notifying the first MCPTT client 102, by the MCPTT server 104 that the remotely initiated MCPTT call request is received by the second MCPTT client 106. The first MCPTT client 102 may be notified by the MCPTT server 104 by transmitting the remotely initiated MCPTT call response to the first MCPTT client 102.
At step 412, the process 400 may include initiating by the second MCPTT call the remote MCPTT call with one or more of the first MCPT client and the at least one other MCPTT client with an implicit floor request. In an embodiment, the second MCPTT client 106 may initiate the remote private call with one of the first MCPTT client 102 and the at least one other client as requested in the remotely initiated MCPTT call request. In another embodiment, the second MCPTT client 106 may initiate the remote group call with one of the first MCPTT client 102, and the at least one other CMPTT client, and the at least one other MCPTT client as requested in the remotely initiated MCPTT call request. The remote MCPTT call may be initiated by using the at least one call set up parameter configured at the second MCPTT client 106, and an indication related to the second MCPTT client 106. The indication may indicate indicates whether the initiation of the MCPTT remote call is due to receiving of the remotely initiated MCPTT call request from the first MCPTT client 102. The at least one call set up parameter configured at the second MCPTT client 106 may require configuration information such as MCPTT user profile data (on and off network) as depicted in table 2 below.
Continuing with the above embodiment, the present subject matter may further include configuration information required for the at least one call setup parameter while initiating the remote MCPTT call on receiving the remotely initiated MCPTT call request that contain in MCPTT service configuration required to support a use of on-network/off-network MCPTT service.
In another embodiment, the present subject matter may further include a method for using the at least one call setup parameter configured at the MCPTT server 104. The MCPTT server 104 may be configured with the required at least one call setup parameter for the remote MCPTT call. On receiving the remotely initiated MCPTT call request from the first MCPTT client 102, the MCPTT server 104 may apply the relevant call setup parameters from the at least one call set up parameter for establishing a the MCPTT remote call.
Table 4 depicts the configuration information required for the at least one call setup parameter while initiating the remote MCPTT call on receiving the remotely initiated MCPTT call request that contain in the MCPTT service configuration required to support the use of on-network/off-network MCPTT service.
Alternatively, the configuration may be defined in the MCPTT user profile configuration data as depicted in table 5.
If the received call initiation request at MCX server for an MCPTT group call is due to receiving of remotely initiated MCPTT call request at MCX client at MCPTT UE then the MCPTT server applies the call setup parameters while establishing a call. The MCPTT group call may include the additional information such as requester of the remotely initiated MCPTT call request and indication of whether the call initiation is due to receiving of remotely initiated MCPTT call request from authorized user.
The private call procedure focuses on the case where an MCPTT client is initiating an MCPTT private call with unicast signaling for communicating with another MCPTT user, with or without floor control enabled, and commencement mode as automatic or manual.
If the received call initiation request at MCX server for an MCPTT private call is due to receiving of remotely initiated MCPTT call request at MCX client, then the MCX server applies the call setup parameters while establishing a call. The MCPTT private call may include the additional information such as requester of the remotely initiated MCPTT call request and indication of whether the call initiation is due to receiving of remotely initiated MCPTT call request from authorized user.
Table 6 depicts the information flow MCPTT private call request from the MCPTT client to the MCPTT server.
Table 7 depicts an information flow for the remotely initiated MCPTT call request for the remote private call from an MCPTT server to an MCPTT server. Information may be the at least one call set up parameter.
Table 8 depicts the information flow for the remotely initiated MCPTT call request for the remote private call from the MCPTT server to a MCPTT client such as the second MCPT client.
Table 9 depicts information flow group call request from the MCPTT client to the MCPTT server.
Table 10 describes the information flow group call request between the MCPTT servers.
Table 11 describes the information flow group call request from the MCPTT server to the MCPTT client.
The present subject matter includes the detailed flow for the remotely initiated private call initiation request procedures as follows. Upon receiving a request from a requesting MCPTT user such as the first MCPTT client 102 to send a remotely initiated private call request to another remote MCPTT user such as the second MCPTT client 106 to originate a private call to an identified MCPTT user, the MCPTT client:
Upon receiving a “SIP MESSAGE request for remotely initiated private call request for terminating client”, the MCPTT client shall extract the MCPTT ID of the identified MCPTT user from the <mcptt-called-party-id> element contained in the <anyExt> element of the <mcptt-Params> element of the <mcpttinfo> element contained in the application/vnd.3gpp.mcptt-info+xml MIME body contained in the received SIP MESSAGE request and any other actions based on received <notify-remote-user> element. if according to local policy on-demand sessions are to be used for remotely initiated private calls, shall invoke the procedures of clause 11.1.1.2.1.1 of 3GPP TS 24.379 to originate an MCPTT private call to the identified MCPTT user with the following clarifications:
If according to local policy pre-established sessions are to be used for remotely initiated private calls and a pre-established session is available, shall invoke the procedures of clause 11.1.1.2.2.1 of 3GPP TS 24.379 to originate an MCPTT private call to the identified MCPTT user with the following clarifications:
Upon receiving a request from the requesting MCPTT user to send a remotely initiated group call request to the remote MCPTT user for a targeted MCPTT group, the MCPTT client:
Further MCPTT client shall send the SIP MESSAGE request towards the MCPTT server according to rules and procedures of 3GPP TS 24.229.
Remote client procedures for handling remotely initiated group call request
Upon receiving a “SIP MESSAGE request for remotely initiated group call request for terminating client”, the MCPTT client:
The XML schema shall include the following new elements.
The <mcpttinfo> element is the root element of the XML document. The <mcpttinfo> element can contain subelements. NOTE 1: The subelements of the <mcpttinfo> are validated by the <xs: any namespace=“##any” processContents=“lax” minOccurs=“0” maxOccurs=“unbounded”/> particle of the <mcpttinfo> element.
If the <mcpttinfo> contains the <mcptt-Params> element then:
The MCPTT client procedure covers from terminating MCPTT client for receiving remotely initiated MCPTT call request for private call and group call. In the procedures, the term “requesting MCPTT user” is used to refer to the MCPTT user who sent a request to initiate a remotely initiated private call, the term “remote MCPTT user” is used to refer to the MCPTT user who is sent a request to initiate a remotely initiated private call; and, the term “identified MCPTT user” is used to refer to the MCPTT user to be invited to the remotely initiated private call.
Upon receiving a “SIP MESSAGE request for remotely initiated private call request for terminating client”, the MCPTT client:
Alternatively, the step 2c, 2d and step 3c 3d can be implemented as below:
Upon receiving a “SIP MESSAGE request for remotely initiated group call request for terminating client”, the MCPTT client:
Alternatively, the step 2b and step 3b can be implemented as below:
The new addition to the MCPTT user profile configuration document structure is specified. The <mcptt-user-profile> document:
The XML schema shall include the following new elements. These elements can be added under the anyExt element of the OnNetwork element of mcptt-user-profile root element.
The <uri-entry> element is of type “anyURI” and when it appears within:
The new addition to the MCPTT service configuration document structure is specified. The <service configuration> document:
The XML schema shall include the following new elements. These elements can be added under the anyExt element of the OnNetwork element of service-configuration-info root element.
In the <on-network> element:
Alternatively, the remotely-initiated-call-application-level-priority and remotely-initiated-call-commencement-mode elements and dependent data can be defined in the MCPTT user profile configuration data as below.
The new addition to the MCPTT user profile configuration document structure is specified. The <mcptt-user-profile> document:
The XML schema shall include the following new elements. These elements can be added under the anyExt element of the OnNetwork element of mcptt-user-profile root element.
MCPTT client procedures:
Upon receiving a request from an MCPTT user to establish an MCPTT private/group call, the MCPTT client shall generate an initial SIP INVITE/SIP REFER request, with the clarifications given below:
The MCPTT client:
Upon receipt of an initial SIP INVITE request. The MCPTT client:
The XML schema shall include the following new elements. These elements can be added under the anyExt element of the mcpttinfo element.
The <mcpttinfo> element is the root element of the XML document. The <mcpttinfo> element can contain subelements. NOTE 1: The subelements of the <mcpttinfo> are validated by the <xs: any namespace=“##any” processContents=“lax” minOccurs=“0” maxOccurs=“unbounded”/> particle of the <mcpttinfo> element.
If the <mcpttinfo> contains the <mcptt-Params> element then:
If the <mcpttinfo> contains the <mcptt-Params> element then:
The table 12 describes newly added pre-established session call control specific data fields.
The Remotely initiated MCPTT call request Indication field indicates that the call request is a result of receiving of a remotely initiated MCPTT call request. Table 13 describes the coding of the Remotely initiated MCPTT call request Indication field.
The <Remotely initiated MCPTT call request Indication field ID> value is a binary value and shall be set according to table 12. The <Remotely initiated MCPTT call request Indication length> value is a binary value and shall have the value ‘2’ indicating the total length in octets of the <Remotely initiated MCPTT call request Indication> value item. The <Remotely initiated MCPTT call request Indication> value is a 16-bit binary value with the following values.
The Remotely initiated MCPTT call request Initiator MCPTT User Identity field contains the MCPTT ID identifying the MCPTT user who has requested for remotely initiated MCPTT call request while initiating a call requested by a received remotely initiated MCPTT call request. Table 14 describes the coding of the Remotely initiated MCPTT call request Initiator MCPTT User Identity field.
The <Remotely initiated MCPTT call request Initiator MCPTT User Identity field ID> value is a binary value and shall be set according to table 12. The <Remotely initiated MCPTT call request Initiator MCPTT User Identity length> value is a binary value indicating the length in octets of the <Remotely initiated MCPTT call request Initiator MCPTT User Identity> value item except padding. The <Remotely initiated MCPTT call request Initiator MCPTT User Identity> value contains the MCPTT ID of the MCPTT user who has requested for remotely initiated MCPTT call request while initiating a call requested by a received remotely initiated MCPTT call request. The <Remotely initiated MCPTT call request Initiator MCPTT User Identity> value shall be coded as specified in the table 15. The MCPTT ID is specified in 3GPP TS 24.379.
If the length of the <Remotely initiated MCPTT call request Initiator MCPTT User Identity> value is not (2+multiple of 4) bytes, the <Remotely initiated MCPTT call request Initiator MCPTT User Identity> value shall be padded to (2+multiple of 4) bytes. The value of the padding bytes should be set to zero. The padding bytes shall be ignored.
The newly added fields are included in the connect message as defined in the table 16.
The Remotely initiated MCPTT call request Indication field is coded as described in clause 8.3.3.12.
The remotely initiated MCPTT call request Initiator MCPTT User Identity field is coded as described in clause 8.3.3.13.
Receive SIP INVITE request (R: SIP INVITE)
Upon receiving a SIP INVITE request from the controlling MCPTT function, if in automatic answer mode, the participating MCPTT function:
Upon receiving the SIP 200 (OK) response to the SIP re-INVITE request of the pre-established session a call as specified in 3GPP TS 24.379 (call setup with manual answer with pre-established session) the participating MCPTT function:
Upon reception of a Connect message, the MCPTT client:
At block 502, the method 500 includes receiving, by a second MCPTT client, a remotely initiated MCPTT call request from a first MCPTT client via a MCPTT server to initiate a remote call, wherein the remotely initiated MCPTT call request comprises the at least one call set up parameter.
At block 504, the method 500 includes, notifying, by the second MCPTT client, the first MCPTT client, that the second MCPTT client received the remotely initiated MCPTT call request via the MCPTT server.
At block 506, the method 500 includes, initiating, by the second MCPTT client, the MCPTT remote call with one of the first MCPTT client and another MCPTT client using the at least one call set up parameter and an indication.
The MCPTT client 600 may be the first MCPTT client, the second MCPTT client or at least one other MCPTT client in this disclosure.
Referring to the
The aforementioned components will now be described in detail.
The processor 610 may include one or more processors or other processing devices that control the provided function, process, and/or method. Operation of the MCPTT Client in this disclosure may be implemented by the processor 610.
The transceiver 620 may include a RF transmitter for up-converting and amplifying a transmitted signal, and a RF receiver for down-converting a frequency of a received signal. However, according to another embodiment, the transceiver 620 may be implemented by more or less components than those illustrated in components.
The transceiver 620 may be connected to the processor 610 and transmit and/or receive a signal. The signal may include control information and data. In addition, the transceiver 620 may receive the signal through a wireless channel and output the signal to the processor 610. The transceiver 620 may transmit a signal output from the processor 610 through the wireless channel.
The memory 630 may store the control information or the data included in a signal obtained by the MCPTT client 600. The memory 630 may be connected to the processor 610 and store at least one instruction or a protocol or a parameter for the provided function, process, and/or method. The memory 630 may include read-only memory (ROM) and/or random access memory (RAM) and/or hard disk and/or CDROM and/or DVD and/or other storage devices.
While specific language has been used to describe the present disclosure, any limitations arising on account thereto, are not intended. As would be apparent to a person in the art, various working modifications may be made to the method to implement the inventive concept as taught herein. The drawings and the foregoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment.
| Number | Date | Country | Kind |
|---|---|---|---|
| 202141035426 | Aug 2021 | IN | national |
| 2021 41035426 | Jul 2022 | IN | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/KR2022/011643 | 8/5/2022 | WO |
