EP3295640A1 - User identities for ptt and mcptt - Google Patents

User identities for ptt and mcptt

Info

Publication number
EP3295640A1
EP3295640A1 EP15726018.3A EP15726018A EP3295640A1 EP 3295640 A1 EP3295640 A1 EP 3295640A1 EP 15726018 A EP15726018 A EP 15726018A EP 3295640 A1 EP3295640 A1 EP 3295640A1
Authority
EP
European Patent Office
Prior art keywords
identity
application
network
request
mcptt
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
EP15726018.3A
Other languages
German (de)
French (fr)
Other versions
EP3295640B1 (en
Inventor
Peter Leis
Rainer Liebhart
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Solutions and Networks Oy
Original Assignee
Nokia Solutions and Networks Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Solutions and Networks Oy filed Critical Nokia Solutions and Networks Oy
Publication of EP3295640A1 publication Critical patent/EP3295640A1/en
Application granted granted Critical
Publication of EP3295640B1 publication Critical patent/EP3295640B1/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1073—Registration or de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5069—Address allocation for group communication, multicast communication or broadcast communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/4061—Push-to services, e.g. push-to-talk or push-to-video
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/30—Types of network names
    • H04L2101/385—Uniform resource identifier for session initiation protocol [SIP URI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/30—Types of network names
    • H04L2101/395—Internet protocol multimedia private identity [IMPI]; Internet protocol multimedia public identity [IMPU]

Definitions

  • the present invention relates to an apparatus, a method, and a computer program product related to push to talk. More particularly, the present invention relates to an apparatus, a method, and a computer program product related to mission critical push to talk.
  • 3GPP SA6 is currently specifying Mission Critical Push To Talk (MCPTT) over LTE application.
  • MCPTT replicates the push to talk service behaviour provided in legacy systems like TETRA or P.25. This service is typically used for Public Safety applications.
  • MCPTT allows a user to talk to other users of a group similar to a Walkie Talkie communication service.
  • MCPTT supports two types of calls, namely a group call and a private call.
  • the group call allows one speaker to talk to a group of users, while the private call allows two MCPTT users to talk to each other.
  • the MCPTT server can leverage MCPTT specific user identities and alias information to setup MCPTT calls, both for group calls as for private calls.
  • MCPTT private calls will be routed via the MCPTT application server.
  • the MCPTT public user identity is an identity that is used to setup calls to a certain user.
  • the identities are of the form of a URI and may look like
  • an apparatus comprising requesting means adapted to request registering at a registrar device of a network domain by a registration request based on a network identity, wherein the registration request comprises the network identity and an application identity different from the network identity.
  • the apparatus may further comprise ciphering means adapted to cipher the application identity, wherein the registration request comprises the ciphered application identity.
  • an apparatus comprising supervising means adapted to supervise if an information in a registration request is received from a registrar of a network domain, wherein the information comprises an application identity of a user of a terminal device and a network identity; binding storing means adapted to store, based on the received information, a binding between the application identity and the network identity; determining means adapted to determine the network identity based on the binding and a received first request for establishing a communication to the terminal device; providing means adapted to provide, based on the received first request, to the network domain, a second request for establishing the communication towards the terminal device, wherein the second request is based on the determined network identity.
  • the first request for the communication may comprise the application identity.
  • the first request may request the communication for members of a group having a group identity; and the apparatus may further comprise group storing means adapted to store an association of the application identity to the group identity; deriving means adapted to derive the application identity from the association and the first request; and the determining means may be adapted to determine the network identity based on the binding and the application identity derived by the deriving means.
  • the information may comprise the application identity as ciphered data, and the apparatus may further comprise deciphering means adapted to decipher the ciphered data to obtain the application identity.
  • an apparatus comprising requesting circuitry configured to request registering at a registrar device of a network domain by a registration request based on a network identity, wherein the registration request comprises the network identity and an application identity different from the network identity.
  • the apparatus may further comprise ciphering circuitry configured to cipher the application identity, wherein the registration request comprises the ciphered application identity.
  • an apparatus comprising supervising circuitry configured to supervise if an information in a registration request is received from a registrar of a network domain, wherein the information comprises an application identity of a user of a terminal device and a network identity; binding storing circuitry configured to store, based on the received information, a binding between the application identity and the network identity; determining circuitry configured to determine the network identity based on the binding and a received first request for establishing a communication to the terminal device; providing circuitry configured to provide, based on the received first request, to the network domain, a second request for establishing the communication towards the terminal device, wherein the second request is based on the determined network identity.
  • the first request for the communication may comprise the application identity.
  • the first request may request the communication for members of a group having a group identity; and the apparatus may further comprise group storing circuitry configured to store an association of the application identity to the group identity; deriving circuitry configured to derive the application identity from the association and the first request; and the determining circuitry may be configured to determine the network identity based on the binding and the application identity derived by the deriving circuitry.
  • the information may comprise the application identity as ciphered data, and the apparatus may further comprise deciphering circuitry configured to decipher the ciphered data to obtain the application identity.
  • At least one of the network identity may be an identity of a session initiation protocol; and the application identity may be an identity of a push to talk application.
  • the application identity may be an identity of a mission critical push to talk application.
  • a method comprising requesting registering at a registrar device of a network domain by a registration request based on a network identity, wherein the registration request comprises the network identity and an application identity different from the network identity.
  • the method may further comprise ciphering the application identity, wherein the registration request comprises the ciphered application identity.
  • a method comprising supervising if an information in a registration request is received from a registrar of a network domain, wherein the information comprises an application identity of a user of a terminal device and a network identity; storing, based on the received information, a binding between the application identity and the network identity; determining the network identity based on the binding and a received first request for establishing a communication to the terminal device; providing, based on the received first request, to the network domain, a second request for establishing the communication towards the terminal device, wherein the second request is based on the determined network identity.
  • the first request for the communication may comprise the application identity.
  • the first request may request the communication for members of a group having a group identity; and the method may further comprise storing an association of the application identity to the group identity; deriving the application identity from the association and the first request; and the determining may comprise determining the network identity based on the binding and the derived application identity.
  • the information may comprise the application identity as ciphered data, and the method may further comprise deciphering the ciphered data to obtain the application identity.
  • At least one of the network identity may be an identity of a session initiation protocol; and the application identity may be an identity of a push to talk application.
  • the application identity may be an identity of a mission critical push to talk application.
  • Each of the methods according to the fifth and sixth aspects may be a method of providing a user identity.
  • a computer program product comprising a set of instructions which, when executed on an apparatus, is configured to cause the apparatus to carry out the method according to any of the fifth and sixth aspects.
  • the computer program product may be embodied as a computer-readable medium or directly loadable into a computer. According to some embodiments of the invention, at least one of the following advantages is provided:
  • Core network need not be configured to maintain application IDs such as MCPTT specific identities.
  • Fig. 1 shows a message flow according to an embodiment of the invention
  • Fig. 2 shows an apparatus according to an embodiment of the invention
  • Fig. 3 shows a method according to an embodiment of the invention
  • Fig. 4 shows an apparatus according to an embodiment of the invention
  • Fig. 5 shows a method according to an embodiment of the invention
  • Fig. 6 shows an apparatus according to an embodiment of the invention.
  • the apparatus is configured to perform the corresponding method, although in some cases only the apparatus or only the method are described.
  • MCPTT public user identity (MCPTT PU) is an example of an "application ID”
  • MCPTT is an example of an application.
  • An IMPU is an example of a "network ID”.
  • Some embodiments of the invention provide a procedure which allows using MCPTT specific identities to setup MCPTT calls when the MCPTT application is using IMS capabilities. More in detail, some embodiments provide a procedure which allows routing MCPTT call control messages based on SIP using MCPTT specific public user identities for the case that the MCPTT application uses IMS provided functions (e.g. SIP routing capabilities).
  • the application identities such as MCPTT user identities may be different to user identities used in IMS (IMPU/IMPI). If a mobile operator owns not only the LTE infrastructure (E- UTRAN, EPC) but also the IMS, then public user identities used in IMS are stored on the
  • the Public Safety service provider (provider of the MCPTT service) uses own identities. Another reason for an application identity different from the network identity may be functional addressing provided by the MCPTT service.
  • the user typically inputs his application identity into the terminal, more precisely, into a terminal application running on the terminal.
  • the IMS provider may not be allowed to correlate such a MCPTT identity with a user and track Public Safety users.
  • the network operator may also not want or is not able to setup an infrastructure to maintain MCPTT identities. More generally, a Public Safety service provider should be able to operate its MCPTT service independently and autonomously from the mobile operator (only interconnection between the two domains for exchange of signalling and user plane data is required).
  • the Public Safety provider should be aware of used IMS Public User Identities to enable proper routing of signalling messages through the IMS.
  • IMS requires IMS public user identities (IMPU) to be used in SIP signalling such that the S-CSCF can deliver the signalling to the appropriate user/UE.
  • IMPU IMS public user identities
  • Reason is that the S-CSCF acts as the SIP registrar and keeps the binding between the IMS public user identity and the UE's contact address (e.g. IP address). So, for terminating calls, the S-CSCF determines the contact (e.g. IP address) to which a request has to be delivered based on the IMS public user identity provided in the SIP message (e.g. in a SIP INVITE message).
  • MCPTT application in UE and in MCPTT AS
  • MCPTT public user identities as identifier in requests.
  • S-CSCF may not be aware of an association between MCPTT public user identity and IMPU.
  • the SIP REGISTER request contains IMS public user identity (in general: network identity) and MCPTT public user identity
  • one of the following encodings may be used for the application identity in the SIP REGISTER sent by the MCPTT UE: a new SIP header field, a body in the REGISTER request, or another appropriate encoding.
  • the application identity may be ciphered on a portion or the whole of the transmission from MCPTT UE (i.e. an UE having configured an MCPTT application) via IMS core to MCPTT AS.
  • the S-CSCF (representing part of an IMS core and acting as a SIP registrar) forwards both network identity and application identity to MCPTT AS.
  • S-CSCF packs the SIP REGISTER request which is received from the MCPTT UE into the body of the 3 rd party REG ISTER message which is sent to the MCPTT AS.
  • the MCPTT AS creates a binding between the network identity and the (possibly de-coded/de-ciphered) application identity. This is performed per MCPTT user. The binding is stored in the MCPTT AS.
  • the MCPTT AS creates a mapping table for each MCPTT group.
  • the mapping table shows the mapping between the group identity of the group and the application identity or identities comprised in the group.
  • the mapping table may store the binding between network identity and application identity per user.
  • the MCPTT AS will use the network identity of the MCPTT user as Request URI, wherein the network identity corresponds to the application identity.
  • the application identity may be additionally transmitted in the SIP INVITE message.
  • Fig. 1 shows an example message flow of an embodiment of the invention in detail for a MCPTT group call.
  • the application server receives a trigger to send out call control signalling to all members of MCPTT Group-x (see action 1 1 ).
  • the message flow of Fig. 2 does not show all IMS nodes, but rather shows a collapsed view.
  • Action 1 :
  • MCPTT UE-1 sends SIP REG ISTER (authentication is not shown, may be performed according to the prior art) towards IMS core.
  • SIP REGISTER contains the IMPU (network identity) in "To" header field as per regular SIP procedures.
  • the IMPU may be of the form sip:user1 published @home-operator.net
  • the SIP REG ISTER contains the MCPTT public user identity (application identity of a user of UE1 ).
  • the application identity may be encoded as a SIP header field or in the body of the SIP REG ISTER.
  • the application identity may be ciphered by the MCPTT application in the UE. Key distribution for the ciphering is not considered in the present application.
  • the application identity may have the form of a SIP URI, e.g.: sip: fireman-ioe-smith@fire.chicaqo.us
  • the S-CSCF creates the binding between IMS public user identity and contact address of UE-1 (e.g. IP address of UE-1 ).
  • UE-1 e.g. IP address of UE-1
  • the S-CSCF sends a 3 rd party REGISTER to the MCPTT AS to inform the MCPTT AS that MCPTT UE-1 has registered.
  • the 3 rd party REGISTER comprises both the IMS public user identity (network identity) and the MCPTT public user identity (application identity) received from UE-1 .
  • the S-CSCF packs the SIP REGISTER received in Action 2 into the body of the 3 rd party REGISTER.
  • Action 5
  • MCPTT AS receives the 3 rd party REGISTER. Based on the received IMS public user identity and the MCPTT public user identity, MCPTT AS detects that this is coming from a MCPTT user with the MCPTT public user identity. The MCPTT AS creates a binding between MCPTT public user identity (application identity) and IMPU (network identity), as shown in Table 1 . In addition, in the case shown in Table 1 , the user with the MCPTT public user identity is a member of Group-x. Hence, in the example, both application identity (MCPTT PU) and network identity (IMPU) are stored as being associated to Group-x.
  • application identity MCPTT PU
  • IMPU network identity
  • MCPTT AS may store two tables: one table storing the application identities of the members of the group, and a second table storing the binding of each of the application identities to the respective network identity.
  • MCPTT UE-2 (which may be different from MCPTT UE-1 ; alternatively, it may be the same UE with a different application identity, e.g. in case of functional addressing, if the same person (same UE) has two different functions) sends SIP REGISTER (authentication is not shown, may be performed according to the prior art) towards IMS core.
  • the SIP REGISTER contains the network identity (IMPU) in "To" header field as per regular SIP procedures.
  • the IMPU may be of the form sip:user2 published @home-operator.net
  • the SIP REGISTER contains the MCPTT public user identity (application identity of a user).
  • the application identity may be encoded as a SIP header field or in the body of the SIP REGISTER.
  • the application identity may be ciphered by the MCPTT application in the UE. Key distribution for the ciphering is not considered is the present application.
  • the application identity may have the form of a SIP URI, e.g.: sip: fireman-jeff-harper@fire.chicaqo.us
  • the S-CSCF creates the binding between network identity and contact address of UE-2 (e.g. IP address of UE-2).
  • the S-CSCF sends a 3 rd party REGISTER to the MCPTT AS to inform the MCPTT AS that MCPTT UE-2 has registered.
  • the 3 rd party REGISTER comprises both the network identity and the application identity.
  • the S-CSCF packs the SIP REGISTER received in Action 7 into the body of the 3 rd party REGISTER.
  • MCPTT AS receives the 3 rd party REGISTER. Based on the received IMS public user identity and the MCPTT public user identity, MCPTT AS detects that this is coming from a MCPTT user with the MCPTT public user identity (application identity). The MCPTT AS creates a binding between the application identity and the network identity (IMPU), as shown in Table 2.
  • the user with the application identity MCPTT public user identity
  • IMPU network identity
  • both application identity (MCPTT PU) and network identity (IMPU) are stored as being associated to Group-x.
  • MCPTT AS may store two tables: one table storing the application identities of the members of the group, and a second table storing the binding of each of the application identities to the respective network identity.
  • Actions 1 to 5 for UE-1 correspond to Actions 6 to 1 0 for UE-2.
  • the sequences of actions 1 to 5 and of actions 6 to 1 0 may be performed consecutively or fully or partially in parallel.
  • Action 1 1 may follow at any time after at least one of actions 1 to 5 and actions 6 to 1 0 has been performed. Hereinafter, it is assumed that both actions 1 to 5 and actions 6 to 1 0 are performed when action 1 1 happens. If actions 1 to 5 have not been performed before action 1 1 , SIP Invite in action 12 may not be successfully processed. If actions 6 to 1 0 have not been performed before action 1 1 , SIP Invite in action 14 may not be successfully processed.
  • MCPTT AS receives a trigger to send Call Control signalling to all members of Group-x (e.g. from the dispatcher or via OAM). Based on the bindings created for MCPTT Group-x (in step 5 and step 1 0), the MCPTT AS determines the related IMS public user identities that belong to the MCPTT users. The MCPTT AS will use these IMS public user identities as R-URI for the related SIP INVITE messages that have to be sent out (actions 1 2 and 14).
  • R-URI is useM public1 @home- operator.net, i.e. the IMPU (network identity) of UE-1 .
  • S-CSCF based on the binding between IMPU and contact address, rewrites the R-U RI to the Contact of MCPTT UE-1 and forwards the SIP INVITE to MCPTT UE-1 .
  • MCPTT AS sends out SIP INVITE to MCPTT UE-1
  • R-URI is user2 public1 @home- operator.net, i.e. the IMPU (network identity) of UE-2.
  • S-CSCF based on the binding between IMPU and contact address, rewrites the R-URI to the Contact of MCPTT UE-2 and forwards the SIP INVITE to MCPTT UE-2.
  • Fig. 2 shows an apparatus according to an embodiment of the invention.
  • the apparatus may be a terminal such as a U E, a MS etc., or an element thereof.
  • Fig. 3 shows a method according to an embodiment of the invention.
  • the apparatus according to Fig. 2 may perform the method of Fig. 3 but is not limited to this method.
  • the method of Fig. 3 may be performed by the apparatus of Fig. 2 but is not limited to being performed by this apparatus.
  • the apparatus comprises requesting means 1 10.
  • the requesting means 1 10 may be a requesting circuitry.
  • the requesting means 1 10 requests registering at a registrar device of a network domain (S1 10) based on a network identity of a first user.
  • the request to register is performed by a registration request (e.g. SIP REGISTER).
  • the registration request comprises the network identity (e.g. IMPU). I.e., the network identity may belong to the network domain.
  • the registration request comprises an application identity of a second user (e.g. MCPTT PU).
  • the application identity may be different from the network identity.
  • the application identity may belong to an application domain different from the network domain.
  • the network identity and the application identity belong to the same user of the apparatus (terminal). However, in general, they may belong to different users. For example, a first user may input his application identity into a terminal application which stores the application id. Then, the UICC comprising the network identity of the first user is exchanged such that the new UICC comprises a network identity of a second user. If the terminal application still stores the application identity of the first user, the registration request comprises the network identity of the second user and the application identity of the first user.
  • Fig. 4 shows an apparatus according to an embodiment of the invention.
  • the apparatus may be a registrar of an application, such as an application server an element thereof.
  • Fig. 5 shows a method according to an embodiment of the invention.
  • the apparatus according to Fig. 4 may perform the method of Fig. 5 but is not limited to this method.
  • Fig. 5 may be performed by the apparatus of Fig. 4 but is not limited to being performed by this apparatus.
  • the apparatus comprises supervising means 310, binding storing means 320, determining means 330, and providing means 340.
  • the supervising means 310, binding storing means 320, determining means 330, and providing means 340 may be a supervising circuitry, a binding storing circuitry, a determining circuitry, and a providing circuitry, respectively.
  • the supervising means 310 supervises, if an information is received in a registration request from a registrar of a network domain.
  • the information comprises an application identity of a user of a terminal device and a network identity.
  • the information (e.g. 3 rd party SIP REGISTER) may inform that the terminal device has registered to the network domain based on the network identity, and that the terminal device indicated to have the application identity.
  • the binding storing means 320 stores a binding between the application identity and the network identity (S320). The binding is based on the received information.
  • the determining means 330 determines the network identity based on the binding and a received request for a communication of the terminal device (S330).
  • the received request for the communication may be based on the application identity.
  • the received request for the communication may be based on a group id, wherein the apparatus stores an association of the application identifier and the group id.
  • the providing means 340 provides, based on the received request, to the network domain, a new request for establishing the communication towards the terminal device (S340).
  • the new request for establishing the communication is based on the network identity.
  • the new request for establishing the communication may be directed to a routing proxy of the network domain.
  • the registrar may also have a role of the routing proxy.
  • the registrar may be different from the routing proxy.
  • Fig. 6 shows an apparatus according to an embodiment of the invention.
  • the apparatus comprises at least one processor 610, at least one memory 620 including computer program code, and the at least one processor 610, with the at least one memory 620 and the computer program code, being arranged to cause the apparatus to at least perform at least one of the methods according to Figs. 3 and 5 and related description.
  • the IMS registrar e.g. S-CSCF
  • the IMS registrar is aware of both network identity (IMPU) and application identity (MCPTT PU) during registration.
  • the IMS registrar may remove the application identity from its memory after it has forwarded both network identity and application identity to MCPTT AS.
  • application identity may be ciphered, as described hereinabove as an option.
  • Embodiments of the invention are described related to MCPTT. However, embodiments of the invention may be applied to "simple" PTT, too. Furthermore, embodiments of the invention may be applied to other applications than MCPTT and PTT, if an identity used in the application should not be maintained in the IMS core network.
  • Some embodiments of the invention may be employed in a 3GPP network. They may be employed also in other 3GPP and non-3GPP mobile and fixed networks such as CDMA, EDGE, LTE, LTE-A, UTRAN, WiFi, WLAN networks, PSTN, etc.
  • a terminal may be a user equipment (UE) or another equipment which may attach to the radio access network of the respective technology.
  • UE user equipment
  • a terminal may be a laptop, a PDA, a tablet, a machine-to-machine communication device, etc.
  • One piece of information may be transmitted in one or plural messages from one entity to another entity. Each of these messages may comprise further (different) pieces of information.
  • Names of network elements, protocols, and methods are based on current standards. In other versions or other technologies, the names of these network elements and/or protocols and/or methods may be different, as long as they provide a corresponding functionality. If not otherwise stated or otherwise made clear from the context, the statement that two entities are different means that they perform different functions. It does not necessarily mean that they are based on different hardware. That is, each of the entities described in the present description may be based on a different hardware, or some or all of the entities may be based on the same hardware. It does not necessarily mean that they are based on different software. That is, each of the entities described in the present description may be based on different software, or some or all of the entities may be based on the same software.
  • example embodiments of the present invention provide, for example a terminal such as a UE, or a component thereof, an apparatus embodying the same, a method for controlling and/or operating the same, and computer program(s) controlling and/or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s).
  • example embodiments of the present invention provide, for example an application server such as a PTT AS or a MCPTT AS, or a component thereof, an apparatus embodying the same, a method for controlling and/or operating the same, and computer program(s) controlling and/or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s).
  • Implementations of any of the above described blocks, apparatuses, systems, techniques, means, entities, units, devices, or methods include, as non-limiting examples, implementations as hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, a virtual machine, or some combination thereof.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

It is provided a method, comprising supervising if an information in a registration request is received from a registrar of a network domain, wherein the information comprises an application identity of a user of a terminal device and a network identity; storing, based on the received information, a binding between the application identity and the network identity; determining the network identity based on the binding and a received first request for establishing a communication to the terminal device; providing, based on the received first request, to the network domain, a second request for establishing the communication towards the terminal device, wherein the second request is based on the determined network identity.

Description

Description Title
User identities for PTT and MCPTT
Field of the invention
The present invention relates to an apparatus, a method, and a computer program product related to push to talk. More particularly, the present invention relates to an apparatus, a method, and a computer program product related to mission critical push to talk.
Abbreviations
3GPP 3rd Generation Partnership Project
AS Application Server BM-SC Broadcast Multicast Service Center
CN Core Network
CSCF Call Session Control Function
EPC evolved Packet Core eMBMS evolved MBMS E-UTRAN evolved UTRAN
GPRS General Packet Radio Service
HSS Home Subscriber Server
ID Identifier
IMPI IMS Private User Identity IMPU IMS Public User Identity IMS IP Multimedia Subsystem
IP Internet Protocol
LTE Long Term Evolution
LTE- A LTE Advanced
MBMS Multimedia Broadcast Multicast Service
MCPTT Mission Critical Push To Talk
MCPTT PU MCPTT Public User Identity
MME Mobility Management Entity
MS Mobile Station
OAM Operation, Administration and Maintenance
PTT Push To Talk
RAN Radio Access Network
RTP Real-Time Transport Protocol
Request URI
System Architecture
S-CSCF Serving CSCF
SIP Session Initiation Protocol
SGSN Serving GPRS Support Node
TETRA Terrestrial Trunked Radio
Technical Specification
UE User Equipment
UICC Universal Integrated Circuit Card
UMTS Universal Mobile Telecommunications System
URI Uniform Resource Identifier UTRAN UMTS Terrestrial Radio Access Network
WiFi Wireless Fidelity
WLAN Wireless Local Area Network
Background of the invention
3GPP SA6 is currently specifying Mission Critical Push To Talk (MCPTT) over LTE application. MCPTT replicates the push to talk service behaviour provided in legacy systems like TETRA or P.25. This service is typically used for Public Safety applications.
The service has typically the following characteristics:
- Two or more users participate in a group communication ;
Users have to request for permission to talk, traditionally by pressing a button on their handset;
- Only one user can talk at a certain time, all others are just listeners.
One of the architectural alternatives for so called "on network operation" describes that the MCPTT application runs on top of the IP multimedia core network (IM CN) subsystem. The MCPTT architecture and procedures will be described in 3GPP TS 23.179 and the IMS architecture and procedures are described in 3GPP TS 23.228. Generally speaking, MCPTT allows a user to talk to other users of a group similar to a Walkie Talkie communication service.
MCPTT supports two types of calls, namely a group call and a private call. The group call allows one speaker to talk to a group of users, while the private call allows two MCPTT users to talk to each other. Typically, the MCPTT server can leverage MCPTT specific user identities and alias information to setup MCPTT calls, both for group calls as for private calls. MCPTT private calls will be routed via the MCPTT application server.
The MCPTT public user identity is an identity that is used to setup calls to a certain user. The identities are of the form of a URI and may look like
SIP URI fireman-ioe-smith@fire.chicaqo.us
Summary of the invention
It is an object of the present invention to improve the prior art.
According to a first aspect of the invention, there is provided an apparatus, comprising requesting means adapted to request registering at a registrar device of a network domain by a registration request based on a network identity, wherein the registration request comprises the network identity and an application identity different from the network identity.
The apparatus may further comprise ciphering means adapted to cipher the application identity, wherein the registration request comprises the ciphered application identity.
According to a second aspect of the invention, there is provided an apparatus, comprising supervising means adapted to supervise if an information in a registration request is received from a registrar of a network domain, wherein the information comprises an application identity of a user of a terminal device and a network identity; binding storing means adapted to store, based on the received information, a binding between the application identity and the network identity; determining means adapted to determine the network identity based on the binding and a received first request for establishing a communication to the terminal device; providing means adapted to provide, based on the received first request, to the network domain, a second request for establishing the communication towards the terminal device, wherein the second request is based on the determined network identity.
The first request for the communication may comprise the application identity.
The first request may request the communication for members of a group having a group identity; and the apparatus may further comprise group storing means adapted to store an association of the application identity to the group identity; deriving means adapted to derive the application identity from the association and the first request; and the determining means may be adapted to determine the network identity based on the binding and the application identity derived by the deriving means.
The information may comprise the application identity as ciphered data, and the apparatus may further comprise deciphering means adapted to decipher the ciphered data to obtain the application identity.
According to a third aspect of the invention, there is provided an apparatus, comprising requesting circuitry configured to request registering at a registrar device of a network domain by a registration request based on a network identity, wherein the registration request comprises the network identity and an application identity different from the network identity.
The apparatus may further comprise ciphering circuitry configured to cipher the application identity, wherein the registration request comprises the ciphered application identity.
According to a fourth aspect of the invention, there is provided an apparatus, comprising supervising circuitry configured to supervise if an information in a registration request is received from a registrar of a network domain, wherein the information comprises an application identity of a user of a terminal device and a network identity; binding storing circuitry configured to store, based on the received information, a binding between the application identity and the network identity; determining circuitry configured to determine the network identity based on the binding and a received first request for establishing a communication to the terminal device; providing circuitry configured to provide, based on the received first request, to the network domain, a second request for establishing the communication towards the terminal device, wherein the second request is based on the determined network identity.
The first request for the communication may comprise the application identity.
The first request may request the communication for members of a group having a group identity; and the apparatus may further comprise group storing circuitry configured to store an association of the application identity to the group identity; deriving circuitry configured to derive the application identity from the association and the first request; and the determining circuitry may be configured to determine the network identity based on the binding and the application identity derived by the deriving circuitry.
The information may comprise the application identity as ciphered data, and the apparatus may further comprise deciphering circuitry configured to decipher the ciphered data to obtain the application identity.
In the apparatus according to any of the first to fourth aspects, at least one of the network identity may be an identity of a session initiation protocol; and the application identity may be an identity of a push to talk application.
In the apparatus according to any of the first to fourth aspects, the application identity may be an identity of a mission critical push to talk application.
According to a fifth aspect of the invention, there is provided a method, comprising requesting registering at a registrar device of a network domain by a registration request based on a network identity, wherein the registration request comprises the network identity and an application identity different from the network identity.
The method may further comprise ciphering the application identity, wherein the registration request comprises the ciphered application identity.
According to a sixth aspect of the invention, there is provided a method, comprising supervising if an information in a registration request is received from a registrar of a network domain, wherein the information comprises an application identity of a user of a terminal device and a network identity; storing, based on the received information, a binding between the application identity and the network identity; determining the network identity based on the binding and a received first request for establishing a communication to the terminal device; providing, based on the received first request, to the network domain, a second request for establishing the communication towards the terminal device, wherein the second request is based on the determined network identity.
The first request for the communication may comprise the application identity. The first request may request the communication for members of a group having a group identity; and the method may further comprise storing an association of the application identity to the group identity; deriving the application identity from the association and the first request; and the determining may comprise determining the network identity based on the binding and the derived application identity.
The information may comprise the application identity as ciphered data, and the method may further comprise deciphering the ciphered data to obtain the application identity.
In the method according to any of the fifth and sixth aspects, at least one of the network identity may be an identity of a session initiation protocol; and the application identity may be an identity of a push to talk application.
In the method according to any of the fifth and sixth aspects, the application identity may be an identity of a mission critical push to talk application.
Each of the methods according to the fifth and sixth aspects may be a method of providing a user identity.
According to a seventh aspect of the invention, there is provided a computer program product comprising a set of instructions which, when executed on an apparatus, is configured to cause the apparatus to carry out the method according to any of the fifth and sixth aspects. The computer program product may be embodied as a computer-readable medium or directly loadable into a computer. According to some embodiments of the invention, at least one of the following advantages is provided:
MCPTT communication is enabled;
Core network need not be configured to maintain application IDs such as MCPTT specific identities.
It is to be understood that any of the above modifications can be applied singly or in combination to the respective aspects to which they refer, unless they are explicitly stated as excluding alternatives.
Brief description of the drawings
Further details, features, objects, and advantages are apparent from the following detailed description of the preferred embodiments of the present invention which is to be taken in conjunction with the appended drawings, wherein
Fig. 1 shows a message flow according to an embodiment of the invention; Fig. 2 shows an apparatus according to an embodiment of the invention; Fig. 3 shows a method according to an embodiment of the invention; Fig. 4 shows an apparatus according to an embodiment of the invention; Fig. 5 shows a method according to an embodiment of the invention; and Fig. 6 shows an apparatus according to an embodiment of the invention.
Detailed description of certain embodiments Herein below, certain embodiments of the present invention are described in detail with reference to the accompanying drawings, wherein the features of the embodiments can be freely combined with each other unless otherwise described. However, it is to be expressly understood that the description of certain embodiments is given for by way of example only, and that it is by no way intended to be understood as limiting the invention to the disclosed details.
Moreover, it is to be understood that the apparatus is configured to perform the corresponding method, although in some cases only the apparatus or only the method are described.
Throughout the present specification, an MCPTT public user identity (MCPTT PU) is an example of an "application ID", and MCPTT is an example of an application. An IMPU is an example of a "network ID".
Some embodiments of the invention provide a procedure which allows using MCPTT specific identities to setup MCPTT calls when the MCPTT application is using IMS capabilities. More in detail, some embodiments provide a procedure which allows routing MCPTT call control messages based on SIP using MCPTT specific public user identities for the case that the MCPTT application uses IMS provided functions (e.g. SIP routing capabilities).
The application identities such as MCPTT user identities may be different to user identities used in IMS (IMPU/IMPI). If a mobile operator owns not only the LTE infrastructure (E- UTRAN, EPC) but also the IMS, then public user identities used in IMS are stored on the
UICC and in the operator's HSS. On the other hand, for some reasons such as security reasons, the Public Safety service provider (provider of the MCPTT service) uses own identities. Another reason for an application identity different from the network identity may be functional addressing provided by the MCPTT service. The user typically inputs his application identity into the terminal, more precisely, into a terminal application running on the terminal. The IMS provider may not be allowed to correlate such a MCPTT identity with a user and track Public Safety users. The network operator may also not want or is not able to setup an infrastructure to maintain MCPTT identities. More generally, a Public Safety service provider should be able to operate its MCPTT service independently and autonomously from the mobile operator (only interconnection between the two domains for exchange of signalling and user plane data is required). On the other hand the Public Safety provider (MCPTT AS provider) should be aware of used IMS Public User Identities to enable proper routing of signalling messages through the IMS. IMS requires IMS public user identities (IMPU) to be used in SIP signalling such that the S-CSCF can deliver the signalling to the appropriate user/UE. Reason is that the S-CSCF acts as the SIP registrar and keeps the binding between the IMS public user identity and the UE's contact address (e.g. IP address). So, for terminating calls, the S-CSCF determines the contact (e.g. IP address) to which a request has to be delivered based on the IMS public user identity provided in the SIP message (e.g. in a SIP INVITE message).
However, the MCPTT application (in UE and in MCPTT AS) will use the MCPTT public user identities as identifier in requests. S-CSCF may not be aware of an association between MCPTT public user identity and IMPU.
According to some embodiments of the invention, the following procedure is performed:
• MCPTT user will register with IMS core. The SIP REGISTER request contains IMS public user identity (in general: network identity) and MCPTT public user identity
(in general: application identity).
o For example, one of the following encodings may be used for the application identity in the SIP REGISTER sent by the MCPTT UE: a new SIP header field, a body in the REGISTER request, or another appropriate encoding. Optionally, the application identity may be ciphered on a portion or the whole of the transmission from MCPTT UE (i.e. an UE having configured an MCPTT application) via IMS core to MCPTT AS.
• The S-CSCF (representing part of an IMS core and acting as a SIP registrar) forwards both network identity and application identity to MCPTT AS. For example, according to some embodiments of the invention, S-CSCF packs the SIP REGISTER request which is received from the MCPTT UE into the body of the 3rd party REG ISTER message which is sent to the MCPTT AS.
• The MCPTT AS creates a binding between the network identity and the (possibly de-coded/de-ciphered) application identity. This is performed per MCPTT user. The binding is stored in the MCPTT AS.
• If group calls are supported, the MCPTT AS creates a mapping table for each MCPTT group. The mapping table shows the mapping between the group identity of the group and the application identity or identities comprised in the group. In addition, the mapping table may store the binding between network identity and application identity per user.
• Whenever the MCPTT AS needs to send out a SIP INVITE to a MCPTT user, then the MCPTT AS will use the network identity of the MCPTT user as Request URI, wherein the network identity corresponds to the application identity. The application identity may be additionally transmitted in the SIP INVITE message.
This procedure may be used for one or both of MCPTT private and group calls. In case of private calls a SIP INVITE is establishing a session between two UEs, in case of group calls a UE can e.g. join an ongoing group call. Fig. 1 shows an example message flow of an embodiment of the invention in detail for a MCPTT group call. In this example, the application server receives a trigger to send out call control signalling to all members of MCPTT Group-x (see action 1 1 ). Note that the message flow of Fig. 2 does not show all IMS nodes, but rather shows a collapsed view. Action 1 :
MCPTT UE-1 sends SIP REG ISTER (authentication is not shown, may be performed according to the prior art) towards IMS core. The SIP REGISTER contains the IMPU (network identity) in "To" header field as per regular SIP procedures. The IMPU may be of the form sip:user1 publid @home-operator.net
In addition, the SIP REG ISTER contains the MCPTT public user identity (application identity of a user of UE1 ). Depending on detailed implementation, the application identity may be encoded as a SIP header field or in the body of the SIP REG ISTER. Optionally the application identity may be ciphered by the MCPTT application in the UE. Key distribution for the ciphering is not considered in the present application. The application identity may have the form of a SIP URI, e.g.: sip: fireman-ioe-smith@fire.chicaqo.us
Action 2:
As per normal SIP procedures, the S-CSCF (registrar) creates the binding between IMS public user identity and contact address of UE-1 (e.g. IP address of UE-1 ). Action 3:
The registration was successful, hence the S-CSCF sends 200 (OK). Action 4:
The S-CSCF sends a 3rd party REGISTER to the MCPTT AS to inform the MCPTT AS that MCPTT UE-1 has registered. The 3rd party REGISTER comprises both the IMS public user identity (network identity) and the MCPTT public user identity (application identity) received from UE-1 . For example, in some embodiments of the invention, the S-CSCF packs the SIP REGISTER received in Action 2 into the body of the 3rd party REGISTER. Action 5:
MCPTT AS receives the 3rd party REGISTER. Based on the received IMS public user identity and the MCPTT public user identity, MCPTT AS detects that this is coming from a MCPTT user with the MCPTT public user identity. The MCPTT AS creates a binding between MCPTT public user identity (application identity) and IMPU (network identity), as shown in Table 1 . In addition, in the case shown in Table 1 , the user with the MCPTT public user identity is a member of Group-x. Hence, in the example, both application identity (MCPTT PU) and network identity (IMPU) are stored as being associated to Group-x.
Group Member Information Information Description
element name Source in SIP
REGISTER Group-x 1 MCPTT PU New header or MCPTT Public User identity body or other sip: fireman-joe- information smith@fire. Chicago. us element
IMPU To: IMS Public User Identity
sip:user1_public1 @home- operator.net
Table 1 : Association of MCPTT PU and IMPU of member 1 ol Group-x
Alternatively, MCPTT AS may store two tables: one table storing the application identities of the members of the group, and a second table storing the binding of each of the application identities to the respective network identity.
Action 6:
MCPTT UE-2 (which may be different from MCPTT UE-1 ; alternatively, it may be the same UE with a different application identity, e.g. in case of functional addressing, if the same person (same UE) has two different functions) sends SIP REGISTER (authentication is not shown, may be performed according to the prior art) towards IMS core. The SIP REGISTER contains the network identity (IMPU) in "To" header field as per regular SIP procedures. The IMPU may be of the form sip:user2 publid @home-operator.net
In addition, the SIP REGISTER contains the MCPTT public user identity (application identity of a user). Depending on detailed implementation, the application identity may be encoded as a SIP header field or in the body of the SIP REGISTER. Optionally, the application identity may be ciphered by the MCPTT application in the UE. Key distribution for the ciphering is not considered is the present application. The application identity may have the form of a SIP URI, e.g.: sip: fireman-jeff-harper@fire.chicaqo.us
Action 7:
As per normal SIP procedures, the S-CSCF (registrar) creates the binding between network identity and contact address of UE-2 (e.g. IP address of UE-2). Action 8:
The registration was successful, hence the S-CSCF sends 200 (OK). Action 9:
The S-CSCF sends a 3rd party REGISTER to the MCPTT AS to inform the MCPTT AS that MCPTT UE-2 has registered. The 3rd party REGISTER comprises both the network identity and the application identity. For example, in some embodiments of the invention, the S-CSCF packs the SIP REGISTER received in Action 7 into the body of the 3rd party REGISTER.
Action 10:
MCPTT AS receives the 3rd party REGISTER. Based on the received IMS public user identity and the MCPTT public user identity, MCPTT AS detects that this is coming from a MCPTT user with the MCPTT public user identity (application identity). The MCPTT AS creates a binding between the application identity and the network identity (IMPU), as shown in Table 2. In addition, in the case shown in Table 2, the user with the application identity (MCPTT public user identity) is a member of Group-x. Hence, in the example, both application identity (MCPTT PU) and network identity (IMPU) are stored as being associated to Group-x.
Alternatively, MCPTT AS may store two tables: one table storing the application identities of the members of the group, and a second table storing the binding of each of the application identities to the respective network identity. Actions 1 to 5 for UE-1 correspond to Actions 6 to 1 0 for UE-2. The sequences of actions 1 to 5 and of actions 6 to 1 0 may be performed consecutively or fully or partially in parallel.
Action 1 1 may follow at any time after at least one of actions 1 to 5 and actions 6 to 1 0 has been performed. Hereinafter, it is assumed that both actions 1 to 5 and actions 6 to 1 0 are performed when action 1 1 happens. If actions 1 to 5 have not been performed before action 1 1 , SIP Invite in action 12 may not be successfully processed. If actions 6 to 1 0 have not been performed before action 1 1 , SIP Invite in action 14 may not be successfully processed.
Action 1 1 :
MCPTT AS receives a trigger to send Call Control signalling to all members of Group-x (e.g. from the dispatcher or via OAM). Based on the bindings created for MCPTT Group-x (in step 5 and step 1 0), the MCPTT AS determines the related IMS public user identities that belong to the MCPTT users. The MCPTT AS will use these IMS public user identities as R-URI for the related SIP INVITE messages that have to be sent out (actions 1 2 and 14).
Action 1 2:
MCPTT AS sends out SIP INVITE to MCPTT UE-1 , R-URI is useM public1 @home- operator.net, i.e. the IMPU (network identity) of UE-1 .
Action 1 3:
S-CSCF, based on the binding between IMPU and contact address, rewrites the R-U RI to the Contact of MCPTT UE-1 and forwards the SIP INVITE to MCPTT UE-1 .
Action 14:
MCPTT AS sends out SIP INVITE to MCPTT UE-1 , R-URI is user2 public1 @home- operator.net, i.e. the IMPU (network identity) of UE-2.
Action 1 5:
S-CSCF based on the binding between IMPU and contact address, rewrites the R-URI to the Contact of MCPTT UE-2 and forwards the SIP INVITE to MCPTT UE-2.
Fig. 2 shows an apparatus according to an embodiment of the invention. The apparatus may be a terminal such as a U E, a MS etc., or an element thereof. Fig. 3 shows a method according to an embodiment of the invention. The apparatus according to Fig. 2 may perform the method of Fig. 3 but is not limited to this method. The method of Fig. 3 may be performed by the apparatus of Fig. 2 but is not limited to being performed by this apparatus.
The apparatus comprises requesting means 1 10. The requesting means 1 10 may be a requesting circuitry.
The requesting means 1 10 requests registering at a registrar device of a network domain (S1 10) based on a network identity of a first user. The request to register is performed by a registration request (e.g. SIP REGISTER). The registration request comprises the network identity (e.g. IMPU). I.e., the network identity may belong to the network domain. Furthermore, the registration request comprises an application identity of a second user (e.g. MCPTT PU). The application identity may be different from the network identity. The application identity may belong to an application domain different from the network domain.
Typically, the network identity and the application identity belong to the same user of the apparatus (terminal). However, in general, they may belong to different users. For example, a first user may input his application identity into a terminal application which stores the application id. Then, the UICC comprising the network identity of the first user is exchanged such that the new UICC comprises a network identity of a second user. If the terminal application still stores the application identity of the first user, the registration request comprises the network identity of the second user and the application identity of the first user.
Fig. 4 shows an apparatus according to an embodiment of the invention. The apparatus may be a registrar of an application, such as an application server an element thereof. Fig. 5 shows a method according to an embodiment of the invention. The apparatus according to Fig. 4 may perform the method of Fig. 5 but is not limited to this method. The method of
Fig. 5 may be performed by the apparatus of Fig. 4 but is not limited to being performed by this apparatus. The apparatus comprises supervising means 310, binding storing means 320, determining means 330, and providing means 340. The supervising means 310, binding storing means 320, determining means 330, and providing means 340 may be a supervising circuitry, a binding storing circuitry, a determining circuitry, and a providing circuitry, respectively.
The supervising means 310 supervises, if an information is received in a registration request from a registrar of a network domain. The information comprises an application identity of a user of a terminal device and a network identity. The information (e.g. 3rd party SIP REGISTER) may inform that the terminal device has registered to the network domain based on the network identity, and that the terminal device indicated to have the application identity.
The binding storing means 320 stores a binding between the application identity and the network identity (S320). The binding is based on the received information.
The determining means 330 determines the network identity based on the binding and a received request for a communication of the terminal device (S330). The received request for the communication may be based on the application identity. Alternatively or in addition, the received request for the communication may be based on a group id, wherein the apparatus stores an association of the application identifier and the group id.
The providing means 340 provides, based on the received request, to the network domain, a new request for establishing the communication towards the terminal device (S340). The new request for establishing the communication is based on the network identity. The new request for establishing the communication may be directed to a routing proxy of the network domain. For example, the registrar may also have a role of the routing proxy. Alternatively, the registrar may be different from the routing proxy.
Fig. 6 shows an apparatus according to an embodiment of the invention. The apparatus comprises at least one processor 610, at least one memory 620 including computer program code, and the at least one processor 610, with the at least one memory 620 and the computer program code, being arranged to cause the apparatus to at least perform at least one of the methods according to Figs. 3 and 5 and related description. According to some embodiments of the invention, the IMS registrar (e.g. S-CSCF) is aware of both network identity (IMPU) and application identity (MCPTT PU) during registration. In order to reduce a potential security risk, the IMS registrar may remove the application identity from its memory after it has forwarded both network identity and application identity to MCPTT AS. Besides application identity may be ciphered, as described hereinabove as an option.
Embodiments of the invention are described related to MCPTT. However, embodiments of the invention may be applied to "simple" PTT, too. Furthermore, embodiments of the invention may be applied to other applications than MCPTT and PTT, if an identity used in the application should not be maintained in the IMS core network.
Some embodiments of the invention may be employed in a 3GPP network. They may be employed also in other 3GPP and non-3GPP mobile and fixed networks such as CDMA, EDGE, LTE, LTE-A, UTRAN, WiFi, WLAN networks, PSTN, etc.
A terminal may be a user equipment (UE) or another equipment which may attach to the radio access network of the respective technology. For example, a terminal may be a laptop, a PDA, a tablet, a machine-to-machine communication device, etc.
One piece of information may be transmitted in one or plural messages from one entity to another entity. Each of these messages may comprise further (different) pieces of information.
Names of network elements, protocols, and methods are based on current standards. In other versions or other technologies, the names of these network elements and/or protocols and/or methods may be different, as long as they provide a corresponding functionality. If not otherwise stated or otherwise made clear from the context, the statement that two entities are different means that they perform different functions. It does not necessarily mean that they are based on different hardware. That is, each of the entities described in the present description may be based on a different hardware, or some or all of the entities may be based on the same hardware. It does not necessarily mean that they are based on different software. That is, each of the entities described in the present description may be based on different software, or some or all of the entities may be based on the same software.
According to the above description, it should thus be apparent that example embodiments of the present invention provide, for example a terminal such as a UE, or a component thereof, an apparatus embodying the same, a method for controlling and/or operating the same, and computer program(s) controlling and/or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s). According to the above description, it should thus be apparent that example embodiments of the present invention provide, for example an application server such as a PTT AS or a MCPTT AS, or a component thereof, an apparatus embodying the same, a method for controlling and/or operating the same, and computer program(s) controlling and/or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s).
Implementations of any of the above described blocks, apparatuses, systems, techniques, means, entities, units, devices, or methods include, as non-limiting examples, implementations as hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, a virtual machine, or some combination thereof.
It is to be understood that what is described above is what is presently considered the preferred embodiments of the present invention. However, it should be noted that the description of the preferred embodiments is given by way of example only and that various modifications may be made without departing from the scope of the invention as defined by the appended claims.

Claims

Claims:
1 . Apparatus, comprising
requesting means adapted to request registering at a registrar device of a network domain by a registration request based on a network identity, wherein the registration request comprises the network identity and an application identity different from the network identity.
2. The apparatus according to claim 1 , further comprising
ciphering means adapted to cipher the application identity, wherein the registration request comprises the ciphered application identity.
3. Apparatus, comprising
supervising means adapted to supervise if an information in a registration request is received from a registrar of a network domain, wherein the information comprises an application identity of a user of a terminal device and a network identity;
binding storing means adapted to store, based on the received information, a binding between the application identity and the network identity;
determining means adapted to determine the network identity based on the binding and a received first request for establishing a communication to the terminal device;
providing means adapted to provide, based on the received first request, to the network domain, a second request for establishing the communication towards the terminal device, wherein the second request is based on the determined network identity.
4. The apparatus according to claim 3, wherein
the first request for the communication comprises the application identity.
5. The apparatus according to any of claims 3 and 4, wherein
the first request requests the communication for members of a group having a group identity; and the apparatus further comprises
group storing means adapted to store an association of the application identity to the group identity;
deriving means adapted to derive the application identity from the association and the first request; and the determining means is adapted to determine the network identity based on the binding and the application identity derived by the deriving means.
6. The apparatus according to any of claims 3 to 5, wherein
the information comprises the application identity as ciphered data, and the apparatus further comprises
deciphering means adapted to decipher the ciphered data to obtain the application identity.
7. The apparatus according to any of claims 1 to 6, wherein at least one of
the network identity is an identity of a session initiation protocol; and
the application identity is an identity of a push to talk application.
8. The apparatus according to any of claims 1 to 7, wherein the application identity is an identity of a mission critical push to talk application.
9. Method, comprising
requesting registering at a registrar device of a network domain by a registration request based on a network identity, wherein the registration request comprises the network identity and an application identity different from the network identity.
10. The method according to claim 9, further comprising
ciphering the application identity, wherein the registration request comprises the ciphered application identity.
1 1 . Method, comprising
supervising if an information in a registration request is received from a registrar of a network domain, wherein the information comprises an application identity of a user of a terminal device and a network identity;
storing, based on the received information, a binding between the application identity and the network identity;
determining the network identity based on the binding and a received first request for establishing a communication to the terminal device; providing, based on the received first request, to the network domain, a second request for establishing the communication towards the terminal device, wherein the second request is based on the determined network identity.
12. The method according to claim 1 1 , wherein
the first request for the communication comprises the application identity.
13. The method according to any of claims 1 1 and 1 2, wherein
the first request requests the communication for members of a group having a group identity; and the method further comprises
storing an association of the application identity to the group identity;
deriving the application identity from the association and the first request; and the determining comprises determining the network identity based on the binding and the derived application identity.
14. The method according to any of claims 1 1 to 13, wherein
the information comprises the application identity as ciphered data, and the method further comprises
deciphering the ciphered data to obtain the application identity.
15. The method according to any of claims 9 to 14, wherein at least one of
the network identity is an identity of a session initiation protocol; and
the application identity is an identity of a push to talk application.
16. The method according to any of claims 1 to 1 5, wherein the application identity is an identity of a mission critical push to talk application.
17. A computer program product comprising a set of instructions which, when executed on an apparatus, is configured to cause the apparatus to carry out the method according to any of claims 9 to 1 6.
18. The computer program product according to claim 17, embodied as a computer-readable medium or directly loadable into a computer.
EP15726018.3A 2015-05-13 2015-05-13 User identities for ptt and mcptt Active EP3295640B1 (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2015/060585 WO2016180488A1 (en) 2015-05-13 2015-05-13 User identities for ptt and mcptt

Publications (2)

Publication Number Publication Date
EP3295640A1 true EP3295640A1 (en) 2018-03-21
EP3295640B1 EP3295640B1 (en) 2022-03-23

Family

ID=53276838

Family Applications (1)

Application Number Title Priority Date Filing Date
EP15726018.3A Active EP3295640B1 (en) 2015-05-13 2015-05-13 User identities for ptt and mcptt

Country Status (3)

Country Link
US (1) US10182082B2 (en)
EP (1) EP3295640B1 (en)
WO (1) WO2016180488A1 (en)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11297111B2 (en) * 2015-06-30 2022-04-05 Blackberry Limited Establishing a session initiation protocol session
CN107135499A (en) * 2016-02-26 2017-09-05 华为技术有限公司 Data transmission method, the network equipment and terminal
US10986471B2 (en) * 2016-10-04 2021-04-20 Samsung Electronics Co., Ltd. Method and apparatus for transmitting a mission critical data message in a communication system
CN109274779B (en) * 2017-07-17 2020-09-25 华为技术有限公司 Alias management method and device
EP4128707A4 (en) * 2020-05-22 2023-09-06 Samsung Electronics Co., Ltd. METHOD AND APPARATUS FOR SHARING THE CAUSE OF MCX COMMUNICATION OVER A GIVEN SESSION
CN113727430B (en) 2020-05-26 2025-02-14 中兴通讯股份有限公司 Terminal registration processing method and device
US12388929B2 (en) * 2021-09-29 2025-08-12 Samsung Electronics Co., Ltd. Method and system for handling functional alias in conference event package
WO2023055089A1 (en) * 2021-09-29 2023-04-06 Samsung Electronics Co., Ltd. Method and system to create, update and remove the binding of functional alias with mcx group

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU7854100A (en) * 1999-10-05 2001-05-10 Nortel Networks Limited Key exchange for network architecture
DE10355265A1 (en) * 2003-11-26 2005-06-23 Siemens Ag Method for registering a communication device, associated communication device and registration unit
FI119314B (en) * 2006-02-01 2008-09-30 Teliasonera Ab Inter-system communication in a mobile communication system
US9967132B2 (en) * 2008-04-08 2018-05-08 Nokia Solutions And Networks Oy Correlating communication sessions
US9490990B2 (en) 2012-06-22 2016-11-08 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for machine-to-machine event data recording
GB201307811D0 (en) * 2013-04-30 2013-06-12 Metaswitch Networks Ltd Processing data
US10264623B2 (en) * 2014-06-30 2019-04-16 Lg Electronics Inc. Method and appartus for supporting a mission critical push to talk service in a wireless access system
US9775008B2 (en) * 2015-01-14 2017-09-26 Kodiak Networks, Inc. System and method for elastic scaling in a push to talk (PTT) platform using user affinity groups
US10362074B2 (en) * 2015-02-03 2019-07-23 Kodiak Networks, Inc Session management and notification mechanisms for push-to-talk (PTT)
US20160269876A1 (en) * 2015-03-13 2016-09-15 Motorola Solutions, Inc Method and apparatus for presenting user personalities for interoperable ptt across separate ptt networks

Also Published As

Publication number Publication date
WO2016180488A1 (en) 2016-11-17
EP3295640B1 (en) 2022-03-23
US20180131730A1 (en) 2018-05-10
US10182082B2 (en) 2019-01-15

Similar Documents

Publication Publication Date Title
US10182082B2 (en) User identities for PTT and MCPTT
GB2560134B (en) Method and apparatus for binding of a user-based public identity to a shared device in an internet protocol multimedia subsystem based communication system
KR101353209B1 (en) Securing messages associated with a multicast communication session within a wireless communications system
US10419895B2 (en) Method and system for identity management across multiple planes
CN101690099B (en) Method and system for providing IMS session continuity to a user equipment across a plurality of communication networks
JP2009517937A (en) Method and apparatus for distributing key information
US10499245B2 (en) Method for performing multiple authentications within service registration procedure
CN101330741A (en) A service redirection method for a user terminal sharing a public user ID
EP2456159B1 (en) Method and apparatus for user registration in ims
EP2421218B1 (en) Session transfer method, apparatus and system thereof
RU2600105C2 (en) Network object and method for controlling transmission of protocol data for initiation of communication session to user object in communication network
US11405764B2 (en) Multiple parallel WebRTC accesses to IMS
WO2013066036A1 (en) Method and apparatus for iut in a wireless communication system
US10412127B2 (en) Method and apparatus for establishing an additional session to an anonymous user
CN101115056A (en) A wireless network registration method, device and system
CN102223351B (en) Method and system for realizing voice continuity safety of single access system
Chiang et al. IMS-based centralized service continuity
CN102612017B (en) Mobile network obtains the method and system of IMS control point information
Rajavelsamy et al. Efficient registration procedure for multi-domain authentication for mission critical communication services
CN102612141B (en) Mobile switching centre obtains the method and system of IMS control point information
Chiang et al. Decentralised secure handover in IMS–based networks
WO2011134157A1 (en) Registration method, equipment and system for personal network element
CN102612048B (en) Mobile switching centre obtains the method and system of IMS control point information
Lan et al. Registration Procedure Improvements for IMS Core Networks via Satcom Access

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20171213

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SOLUTIONS AND NETWORKS OY

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

PUAG Search results despatched under rule 164(2) epc together with communication from examining division

Free format text: ORIGINAL CODE: 0009017

17Q First examination report despatched

Effective date: 20191014

B565 Issuance of search results under rule 164(2) epc

Effective date: 20191014

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 29/12 20060101ALI20191009BHEP

Ipc: H04L 29/06 20060101AFI20191009BHEP

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20211015

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602015077698

Country of ref document: DE

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 1478214

Country of ref document: AT

Kind code of ref document: T

Effective date: 20220415

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG9D

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20220323

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220323

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220323

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220623

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220323

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220323

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220623

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 1478214

Country of ref document: AT

Kind code of ref document: T

Effective date: 20220323

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220323

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220624

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220323

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220323

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220323

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220323

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220323

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220725

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220323

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220323

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220323

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220323

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220323

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220723

Ref country code: AL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220323

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602015077698

Country of ref document: DE

REG Reference to a national code

Ref country code: BE

Ref legal event code: MM

Effective date: 20220531

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220323

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220513

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220531

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220323

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220531

26N No opposition filed

Effective date: 20230102

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20220623

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220513

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220323

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220623

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220531

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220323

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO

Effective date: 20150513

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220323

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220323

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220323

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20250402

Year of fee payment: 11

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20250401

Year of fee payment: 11

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220323