Methods and apparatuses for MC client connection authorization

Abstract

A method to be performed by a mission critical (MC) gateway (GW) user equipment (UE) in case of a connection authorization request including an identity, the method comprising: in an instance when a status of the identity is pre-authorized, enabling access for a MC client associated with the identity to a first set of services of a MC core network (NW); and in response to a notification from the MC core NW that the MC client associated with the identity is authenticated, further enabling access for the MC client to a second set of MC services of the MC core NW.

Description

METHODS AND APPARATUSES FOR MC CLIENT CONNECTION AUTHORIZATIONTECHNICAL FIELD

[0001] Various example embodiments generally relate to a wireless communication technique. More specifically, measures / mechanisms (including methods, apparatuses, and computer program products) are described for authorizing mission critical (MC) clients.BACKGROUND

[0002] Various example embodiments relate to considerations in a (e.g., mobile / wireless) communication system or network, such as a 5G / NR system and a next-generation system beyond 5G. For example, various example embodiments are applicable in a 3GPP-standardized mobile / wireless communication system or network of Release 18 onwards. State of the art is described in 3GPP TS 23.280 clause 11.

[0003] The present invention relates to a scenario illustrated in Fig. 4, in which a non- 3GPP device with an MC GW client can access MC services via an MC GW user equipment (UE). An MC service user on the non-3gpp device may access MC services via the MC GW UE, which requires connection authorization. However the existing procedures have security issues. A problem arises of how to authenticate the MC client, e.g. via an MC server in an MC network (NW), without undesired access to the MC NW by the MC client.LIST OF ACRONYMS AND ABBREVIATIONS

[0004] The following acronyms and abbreviations are used throughout the subject disclosure:3GPP 3rd Generation Partnership ProgramCN Core NetworkGW GatewayID IdentifierIDMS Identity Management ServerMC Mission CriticalUE User EquipmentSUMMARY

[0005] The invention is defined by the independent claims. The dependent claims describe optional example embodiments.

[0006] An exemplary method to be performed by a mission critical (MC) gateway (GW) user equipment (UE) in case of a connection authorization request. The connection authorization request includes an identity. The method comprises: In an instance when a status of the identity is pre-authorized, enabling access for a MC client associated with the identity to a first set of services of a MC core network (NW). The method further comprises: In response to a notification from the MC core NW that the MC client associated with the identity is authenticated, further enabling access for the MC client to a second set of MC services of the MC core NW.

[0007] An exemplary method to be performed by a mission critical (MC) core network (NW) in case of a connection authorization request. The connection authorization request includes an identity. The method comprises setting a status of the identity as pre-authorized. The method further comprises: In an instance when an MC client associated with the identity is successfully authenticated at the MC core NW, setting the status of the identity as authenticated and sending a notification to a MC gateway (GW) user equipment (UE) that the MC client associated with the identity is authenticated.

[0008] An exemplary apparatus comprises a mission critical (MC) gateway (GW) user equipment (UE). The apparatus further comprises at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform, in case of a connection authorization request: In an instance when a status of the identity is pre-authorized, enabling access for a MC client associated with the identity to a first set of services of a MC core network (NW); and in response to a notification from the MC core NW that the MC client associated with the identity is authenticated, further enabling access for the MC client to a second set of MC services of the MC core NW. The connection authorization request includes an identity.

[0009] An exemplary apparatus comprises a mission critical (MC) core network (NW), e.g. one ore more MC servers. The apparatus further comprises at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to, in case of a connection authorization request, setting a status of the identity as pre-authorized; and, in an instance when an MC client associated with the identity is successfully authenticated at the MC core NW, setting the status of the identity as authenticated and sending a notification to a MC gateway (GW) user equipment (UE) that the MC client associated with the identity is authenticated. The connection authorization request includes an identity.

[0010] An exemplary apparatus comprises a mission critical (MC) gateway (GW) user equipment (UE), comprising means for, in case of a connection authorization request, in an instance when a status of the identity is pre-authorized, enabling access for a MC client associated with the identity to a first set of services of a MC core network (NW); and, in response to a notification from the MC core NW that the MC client associated with the identityis authenticated, further enabling access for the MC client to a second set of MC services of the MC core NW. The connection authorization request includes an identity.

[0011] An exemplary apparatus comprising a mission critical (MC) core network (NW), comprising means for, in case of a connection authorization request, setting a status of the identity as pre-authorized; and, in an instance when an MC client associated with the identity is successfully authenticated at the MC core NW, setting the status of the identity as authenticated and sending a notification to a MC gateway (GW) user equipment (UE) that the MC client associated with the identity is authenticated. The connection authorization request includes an identity.

[0012] This summary is intended to provide a brief overview of some of the aspects and features according to the subject disclosure. Accordingly, it will be appreciated that the abovedescribed features are merely examples and should not be construed to narrow the scope of the subject disclosure in any way. Other features, aspects, and advantages of the subject disclosure will become apparent from the following detailed description, drawings, and claims.BRIEF DESCRIPTION OF THE DRAWINGS

[0013] A better understanding of the subject disclosure can be obtained when the following detailed description of various embodiments is considered in conjunction with the following drawings, in which:

[0014] FIG. 1 shows a schematic diagram of an example (mobile / wireless) communication system or network;

[0015] FIG. 2 shows a schematic diagram of an example wireless device or entity;

[0016] FIG. 3 shows a schematic diagram of an example network node or entity;

[0017] FIG. 4 illustrates a non-3GPP device with an MC GW client accessing MC services via an MC GW UE;

[0018] FIG. 5 illustrates a flowchart of a method to be performed by a MC GW UE in case of a connection authorization request;

[0019] FIG. 6 illustrate a flowchart of a method to be performed by a MC core NW in case of a connection authorization request;

[0020] FIG. 7 illustrates schematically a procedure for connection authorization with an MC server via an MC GW UE;

[0021] FIG. 8 illustrates schematically a MC GW UE;

[0022] FIG. 9 illustrates schematically a MC core NW;

[0023] FIGS. 10A and 10B illustrate schematic block diagrams showing structures of apparatuses according to embodiments of the subject disclosure.

[0024] DETAILED DESCRIPTION

[0025] The examples and embodiments set forth below represent information to enable those skilled in the art to practice the subject disclosure. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the description and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the description.

[0026] In the following description, numerous specific details are set forth. However, it is understood that embodiments may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail in order not to obscure the understanding of the description. Those of ordinary skill in the art, with the included description, will be able to implement appropriate functionality without undue experimentation.

[0027] References in the specification to "one embodiment," "an embodiment," "an example embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to implement such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0028] It is to be noted that the detailed description, at times, refers to one or more specifications being used as non-limiting and illustrative examples for certain architectures, network configurations and system deployments. More specifically, the detailed description refers to 3GPP standards, being used as non-limiting and illustrative examples. As such, the example embodiments provided herein can specifically employ terminology which is directly related thereto. Such terminology is only used in the context of the non-limiting and illustrative examples and is not intended to limit the example embodiments in any way. Rather, any other system configuration or deployment may be utilized while complying with what is described herein and / or example embodiments are applicable to it.

[0029] For example, various example embodiments are applicable in any (e.g., mobile / wireless) communication system, such as a 5G / NR system and a next-generation system beyond 5G. For example, various example embodiments are applicable in a 3GPP-standardized mobile / wireless communication system of Release 18 onwards.

[0030] Hereinafter, various example embodiments are described using several variants and / or alternatives. It is generally to be noted that, according to certain implementations or constraints, all the described variants and / or alternatives may be provided alone or in anyconceivable combination (e.g., also including combinations of individual features of these various variants and / or alternatives).

[0031] As used herein, the words "comprising" and "including" should be understood as not limiting the example embodiments to consist of only those features that have been mentioned, and example embodiments may also contain, among other things, e.g., features, structures, units, modules, or the like, that have not been specifically mentioned.

[0032] As used herein, "at least one of the following: " and "at least one of " and similar wording, like "one or more of", where the list of two or more elements are joined by "and" or "or", mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

[0033] As used herein, according to various example embodiments, any operations of sending or receiving may comprise actual transmission or communication operations, i.e., transmitting or communicating associated messages or signals, but may additionally or alternatively comprise related processing operations, i.e., preparing / generating / issuing associated messages or signals before sending and / or obtaining / handling / processing of associated messages or signals after receiving. For example, sending a message at / by an entity may comprise generating / issuing and / or transmitting / communicating thereof or a corresponding signal in / at / by the entity, and receiving a message at / by an entity may comprise obtaining / handling and / or processing thereof or a corresponding signal in / at / by the entity. As used herein, a message may refer to and / or encompass any kind of corresponding information, signal, or the like.

[0034] In the drawings, it is to be noted that lines / arrows interconnecting individual blocks or entities are generally meant to illustrate an operational coupling there-between, which may be a physical and / or logical coupling, which on the one hand is implementation-independent (e.g., wired, or wireless) and on the other hand may also comprise an arbitrary number of intermediary functional blocks or entities not shown. In flowcharts or sequence diagrams, the illustrated order of operations or actions is generally non-limiting and illustrative, and any other order of respective operations or actions is conceivable, if feasible.

[0035] As illustrated in Fig. 5, in case of a connection authorization request 510, wherein the connection authorization request includes an identity, a mission critical (MC) gateway (GW) user equipment (UE) performs: in an instance when a status of an identity is preauthorized, enabling 520 access for a MC client associated with the identity to a first set of services of a MC core network (NW), and, in response to a notification from the MC core NW that the MC client associated with the identity is authenticated, further enabling 530 access for the MC client to a second set of MC services of the MC core NW. For example, this allows to limit access for the MC client before authentication, so that it can only access the first set of MC services in the MC core NW. An exemplary MC GW UE is illustrated in Fig. 8.

[0036] The identity may be a number randomly drawn by a MC GW client. The connection authorization request may comprise an MC service identifier (ID). MC clients may be comprised by, e.g. a non-3GPP device, a 3GPP device or an MC UE.

[0037] The MC GW UE may send the connection authorization request to the MC core NW. The MC GW UE may receive a connection authorization response from the MC core NW, the connection authorization response indicating whether the status of the identity is preauthorized. The MC GW UE may send the connection authorization response to a MC GW client.

[0038] For example, the first set of services of a MC core NW are common services core services. The second set of MC services may comprise one or more of a MC video service, a MC data service, a MC audio service and a MC push to talk service. The first set of services may be provided by one or more MC servers of the MC core NW. The second set of services may be provided by one ore more servers of the MC core NW.

[0039] As illustrated in Fig. 6, in case of the connection authorization request 610, wherein the connection authorization request includes an identity, the MC core NW, e.g. one or more MC servers, perform: setting 620 the status of the identity as pre-authorized, and, in an instance when an MC client associated with the identity is successfully authenticated at the MC core NW, setting 630 the status of the identity as authenticated and sending a notification to the MC GW UE that the MC client associated with the identity is authenticated. An exemplary MC core NW is illustrated in Fig. 9.

[0040] As mentioned before, the connection authorization request may comprise an MC service identifier (ID). The identity may be a number randomly drawn by a MC gateway client.

[0041] For example, the MC core NW can reject setting the status of the identity as preauthorized if the MC core NW received the same MC service ID and the same identity for which the MC core NW already has set pre-authorized status.

[0042] The MC core NW may receive the connection authorization request from the MC GW UE. The MC core NW may send the connection authorization response to the MC GW UE, wherein the connection authorization response indicates whether the status of the identity is pre-authorized.

[0043] Before explaining further optional implementation details, certain general principles of a (mobile / wireless) communication system or network are briefly explained with reference to FIGS. 1 to 3 to assist in understanding the underlying technology.

[0044] FIG. 1 illustrates an example of a (mobile / wireless) communication system or network 100 that may be used for wireless communications. Communication system or network 100 includes wireless devices or entities, such as UEs 110 (e.g., 110A-110C), and network nodes or entities, such as radio access nodes 120 (e.g., 120A-120B) (e.g., eNBs, gNBs, etc.), connected to one or more network nodes or entities 130 via an interconnecting network 125. Communication system or network 100 may use any suitable deployment scenarios. UEs 110within coverage area 115 may each be capable of communicating directly with radio access nodes 120 over a wireless interface.

[0045] As an example, UE 110A may communicate with radio access node 120A over a wireless interface. That is, UE 110A may transmit wireless signals to and / or receive wireless signals from radio access node 120A. The wireless signals may contain voice traffic, data traffic, control signals, and / or any other suitable information.

[0046] As used herein, the term "user equipment" (UE) has the full breadth of its ordinary meaning and may refer to any type of wireless device or entity which can communicate with a network node or entity and / or with another UE in a cellular or mobile or wireless / mobile communication system. Examples of UE are target device, D2D UE, machine type UE or UE capable of machine-to-machine (M2M) communication, personal digital assistant, tablet, mobile terminal, smartphone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles, ProSe UE, vehicle-to-vehicle (V2V) UE, V2X UE, MTC UE, eMTC UE, FeMTC UE, UE Cat 0, UE Cat Ml, narrow band loT (NB-IoT) UE, UE Cat NB1, etc. Example embodiments of a UE are described in more detail below with respect to FIG. 2.

[0047] In some embodiments, an area of wireless signal coverage 115 associated with a radio access node 120 may be referred to as a cell. However, particularly with respect to the fifth generation (5G) / New Radio (NR) mobile communication concepts, beams may be used instead of cells and, as such, it is important to note that concepts described herein are equally applicable to both cells and beams.

[0048] With respect to a beam-based mobile communication system, the radio access node 120 (base station) may transmit a beamformed signal to the UE 110 in one or more transmit directions (transmission beam, Tx beam). The UE 110 may receive the beamformed signal from the base station 120 in one or more receive directions (reception beam, Rx beam). The UE 110 may also transmit a beamformed signal to the base station 120 in one or more directions and the base station 120 may receive the beamformed signal from the UE 110 in one or more directions. The base station 120 and the UE 110 may determine the best receive and transmit directions, e.g., best in the sense of these directions leading to the highest link quality or fulfilling other quality conditions in the most suitable manner, for each of the base station / UE pairs.

[0049] The interconnecting network 125 may refer to any interconnecting system capable of transmitting audio, video, signals, data, messages, etc., or any combination of the preceding. The interconnecting network 125 may include all or a portion of a public switched telephone network (PSTN), a public or private data network, a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a local, regional, or global communication or computer network such as the Internet, a wireline or wireless network, an enterprise intranet, or any other suitable communication link, including combinations thereof.

[0050] In some embodiments, the network node 130 may be a core network node, managing the establishment of communication sessions and other various other functionalitiesfor UEs 110. Examples of network node 130 may include mobile switching center (MSC), MME, serving gateway (SGW), packet data network gateway (PGW), operation and maintenance (O&M), operations support system (OSS), SON, positioning node (e.g., Enhanced Serving Mobile Location Center, E-SMLC), location server node, MDT node, etc. UEs 110 may exchange certain signals with the network node 130 using the non-access stratum (NAS) layer. In non-access stratum signaling, signals between UEs 110 and the network node 130 may be transparently passed through the radio access network. In some embodiments, radio access nodes 120 may interface with one or more network nodes 130 over an internode interface.

[0051] As used herein, the term "network node or entity" has the full breadth of its ordinary meaning and may correspond to any type of radio access node (or radio network node) or any network node, which can communicate with a UE and / or with another network node in a cellular or mobile or wireless communication system. Examples of network nodes are NodeB, MeNB, SeNB, a network node may belonging to MCG or SCG, base station (BS), multistandard radio (MSR) radio access node such as MSR BS, eNodeB, network controller, radio network controller (RNC), base station controller (BSC), relay, donor node controlling relay, base transceiver station (BTS), access point (AP), transmission point, transmission node, RRU, RRH, node in distributed antenna system (DAS), core network node (e.g., MSC, MME, etc.), O&M, OSS, Self-organizing Network (SON), positioning node (e.g., E-SMLC), MDT, test equipment, etc. Example embodiments of a network node are described in more detail below with respect to FIG. 3.

[0052] In some embodiments, radio access node 120 may be a distributed radio access node. The components of the radio access node 120, and their associated functions, may be separated into two main units (or sub-radio network nodes) which may be referred to as the central unit (CU) and the distributed unit (DU). Different distributed radio network node architectures are possible. For instance, in some architectures, a DU may be connected to a CU via dedicated wired or wireless link (e.g., an optical fiber cable) while in other architectures, a DU may be connected a CU via a transport network. Also, how the various functions of the radio access node 120 are separated between the CU(s) and DU(s) may vary depending on the chosen architecture.

[0053] Exemplary wireless communication systems are architectures standardized by the 3rd Generation Partnership Project (3GPP). A latest 3GPP based development is often referred to as the long-term evolution (LTE) of the Universal Mobile Telecommunications System (UMTS) radio-access technology (RAT). The various development stages of the 3GPP specifications are referred to as releases. More recent developments of the LTE are often referred to as LTE Advanced (LTE- A). The LTE (LTE-A) employs a radio mobile architecture known as the Evolved Universal Terrestrial Radio Access Network (E-UTRAN) and a core network known as the Evolved Packet Core (EPC). Base stations of such systems are known as evolved or enhanced Node Bs (eNBs) and provide E-UTRAN features such as user plane Packet Data Convergence / Radio Link Control / Medium Access Control / Physical layer protocol(PDCP / RLC / MAC / PHY) and control plane Radio Resource Control (RRC) protocol terminations towards the communication devices. Other RAT examples comprise those provided by base stations of systems that are based on technologies such as WLAN and / or Worldwide Interoperability for Microwave Access (WiMax). A base station can provide coverage for an entire cell or similar radio service area. Core network elements include Mobility Management Entity (MME), Serving Gateway (S-GW) and Packet Gateway (P-GW).

[0054] An example of a suitable communications system is the 5G or NR concept. Network architecture in NR may be similar to that of LTE-A. Base stations of NR systems may be known as next generation Node Bs (gNBs). Changes to the network architecture may depend on the need to support various radio technologies and finer Quality of Service (QoS) support, and some on-demand requirements for QoS levels to support Quality of Experience (QoE) of user point of view. Also network aware services and applications, and service and application aware networks may bring changes to the architecture. Those are related to Information Centric Network (ICN) and User-Centric Content Delivery Network (UC-CDN) approaches. NR may use multiple input-multiple output (MIMO) antennas, many more base stations or nodes than the LTE (a so-called small cell concept), including macro sites operating in co-operation with smaller stations and perhaps also employing a variety of radio technologies for better coverage and enhanced data rates.

[0055] Future networks may utilize network functions virtualization (NFV) which is a network architecture concept that proposes virtualizing network node functions into "building blocks" or entities that may be operationally connected or linked together to provide services. A virtualized network function (VNF) may comprise one or more virtual machines running instructions using standard or general type servers instead of customized hardware. Cloud computing or data storage may also be utilized. In radio communications this may mean node operations to be carried out, at least partly, in a server, host or node operationally coupled to a remote radio head. It is also possible that node operations will be distributed among a plurality of servers, nodes, or hosts. It should also be understood that the distribution of labor between core network operations and base station operations may differ from that of the LTE or even be non-existent.

[0056] An example 5G core network (CN) comprises functional entities. The CN is connected to a UE via the radio access network (RAN). An UPF (User Plane Function) whose role is called PSA (PDU Session Anchor) may be responsible for forwarding frames back and forth between the DN (data network) and the tunnels established over the 5G towards the UEs exchanging traffic with the data network (DN). The UPF is controlled by an SMF (Session Management Function) that receives policies from a PCF (Policy Control Function). The CN may also include an AMF (Access & Mobility Function).

[0057] Generally, all concepts disclosed herein may be applicable to different communication networks, comprising but not limited to LTE, LTE-A, 5G, 5G advanced, 6G, and other future or already implemented networks.

[0058] FIG. 2 is a schematic diagram of an example wireless device, UE 110, according to certain example embodiments. UE 110 may include one or more of at least one transceiver 210, at least one processor 220, at least one memory 230, and at least one network interface 240. In certain example embodiments, the transceiver 210 facilitates transmitting wireless signals to and receiving wireless signals from radio access node 120 (e.g., via transmitter(s) (Tx), receiver(s) (Rx) and antenna(s)). The processor 220 executes instructions to provide some or all of the functionalities described herein as being provided by a wireless device / entity or UE, and the memory 230 stores the instructions executed by the processor 220. In some embodiments, the processor 220 and the memory 230 form processing circuitry.

[0059] The processor 220 may include any suitable combination of hardware to execute instructions and manipulate data to perform some or all the described functions of a wireless device or entity, such as the functions of UE 110 described herein. In some embodiments, the processor 220 may include, for example, one or more computers, one or more central processing units (CPUs), one or more microprocessors, one or more application specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs) and / or other logic.

[0060] The memory 230 is generally operable to store instructions, such as a computer program, software, an application including one or more of logic, rules, algorithms, code, tables, etc. and / or other instructions capable of being executed by a processor 220. Examples of memory 230 include computer memory (for example, Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (for example, a hard disk), removable storage media (for example, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or or any other volatile or non-volatile, non- transitory computer-readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by the processor 220 of UE 110. For example, the memory 230 includes instructions causing the processor 220 to perform processing according to any corresponding methods described herein.

[0061] The network interface 240 is communicatively coupled to the processor 220 and may refer to any suitable device operable to receive input for UE 110, send output from UE 110, perform suitable processing of the input or output or both, communicate to other devices, or any combination thereof. The network interface 240 may include appropriate hardware (e.g., port, modem, network interface card, etc.) and software, including protocol conversion and data processing capabilities, to communicate through a network.

[0062] Other embodiments of UE 110 may include additional components beyond those shown in FIG. 2 that may be responsible for providing certain aspects of the wireless device’s functionalities, including any of the functionalities described herein and / or any additional functionalities (including any functionality necessary to support the mechanisms according to the subject disclosure). As an example, UE 110 may include input devices and circuits, output devices, and one or more synchronization units or circuits, which may be part of the processor 220. Input devices include mechanisms for entry of data into UE 110. For example, input devices may include input mechanisms, such as a microphone, input elements, a display, etc.Output devices may include mechanisms for outputting data in audio, video and / or hard copy format. For example, output devices may include a speaker, a display, etc.

[0063] In certain example embodiments, the wireless device UE 110 may comprise a series of modules configured to implement the functionalities of the wireless device described herein.

[0064] It will be appreciated that the various modules may be implemented as combination of hardware and software, for instance, the processor, memory, and transceiver(s) of UE 110 shown in FIG. 2. Certain example embodiments may also include additional modules to support additional and / or optional functionalities.

[0065] FIG. 3 is a schematic diagram of an example radio access node 120 or network node or entity 130 according to certain example embodiments. Radio access node 120 or network node or entity 130 may include one or more of at least one transceiver 310, at least one processor 320, at least one memory 330, and at least one network interface 340. In certain example embodiments, the transceiver 310 facilitates transmitting wireless signals to and receiving wireless signals from wireless devices, such as UE 110 (e.g., via transmitter(s) (Tx), receiver(s) (Rx), and antenna(s)). The processor 320 executes instructions to provide some or all the functionalities described herein as being provided by the radio access node 120 or the network node or entity 130, the memory 330 stores the instructions executed by the processor 320. In some embodiments, the processor 320 and the memory 330 form processing circuitry. The network interface 340 can communicate signals to backend network components, such as a gateway, switch, router, Internet, Public Switched Telephone Network (PSTN), core network nodes or radio network controllers, etc.

[0066] The processor 320 can include any suitable combination of hardware to execute instructions and manipulate data to perform some or all the described functions of the radio access node 120 or the network node or entity 130, such as those described herein. In some embodiments, the processor 320 may include, for example, one or more computers, one or more central processing units (CPUs), one or more microprocessors, one or more application specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs) and / or other logic.

[0067] The memory 330 is generally operable to store instructions, such as a computer program, software, an application including one or more of logic, rules, algorithms, code, tables, etc. and / or other instructions capable of being executed by a processor 320. Examples of memory 330 include computer memory (for example, Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (for example, a hard disk), removable storage media (for example, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or or any other volatile or non-volatile, non- transitory computer-readable and / or computer-executable memory devices that store information. For example, the memory 330 includes instructions causing the processor 320 to perform processing according to any corresponding methods described herein.

[0068] In certain example embodiments, the network interface 340 is communicatively coupled to the processor 320 and may refer to any suitable device operable to receive input for the radio access node 120 or the network node or entity 130, send output from the radio access node 120 or the network node or entity 130, perform suitable processing of the input or output or both, communicate to other devices, or any combination of the preceding. The network interface 340 may include appropriate hardware (e.g., port, modem, network interface card, etc.) and software, including protocol conversion and data processing capabilities, to communicate through a network.

[0069] Other example embodiments of the radio access node 120 or the network node or entity 130 can include additional components beyond those shown in FIG. 3 that may be responsible for providing certain aspects of the node’s functionalities, including any of the functionalities described herein and / or any additional functionalities (including any functionality necessary to support the solutions described herein). The various different types of radio access nodes or network nodes may include components having the same physical hardware but configured (e.g., via programming) to support different radio access technologies, or may represent partly or entirely different physical components.

[0070] Processors, interfaces, and memory similar to those described with respect to FIG. 3 may be included in other nodes or entities (such as UE 110, radio access node 120, etc.). Other nodes or entities may optionally include or not include a wireless interface (such as the transceiver described in FIG. 3).

[0071] In certain example embodiments, the radio access node 120 or the network node or entity 130 may comprise a series of modules configured to implement the functionalities of the radio access node 120 or the network node or entity 130 described herein.

[0072] It will be appreciated that the various modules may be implemented as combination of hardware and software, for instance, the processor, memory, and transceiver(s) of the radio access node 120 or the network node or entity 130 shown in FIG. 3. Certain example embodiments may also include additional modules to support additional and / or optional functionalities.

[0073] Fig. 7 shows an exemplary procedure for connection authorization with an MC server via an MC GW UE, e.g. for an MC service user that wishes to access MC services using a non-3GPP device. Possible pre-conditions are that the MC gateway client has been configured with the necessary parameters needed for connectivity with the MC gateway UE; the MC gateway client hosted at the non-3GPP device has been provided with an appropriate GW MC service ID; the MC GW UE has performed service authorization for one or more MC services with the MC system as described in 3GPP TS 23.379, 3GPP TS 23.281, and 3GPP TS 23.282; and / or the MC GW client has selected an MC GW UE or alternatively, the MC GW client has performed a selection by internal criteria, wherein the internal criteria are outside the scope of the present description.

[0074] At step 0 of Fig. 7, the MC GW UE registers / authorizes as a MC GW UE. During the registration / authorization process, the MC GW UE can indicate that the MC GW UE will function as an MC GW UE. The MC server, upon receiving an indication that the client will function as an MC GW UE, determines whether the client can function as an MC GW UE and, if it can, the MC server indicates that the client can function as an MC GW UE.

[0075] At step 1, the MC GW client requests connection via the MC GW UE with an MC server. The MC GW client provides an MC service identifier and a random number. This allows to avoid disclosing the identity of the MC user.

[0076] At step 2, the MC GW UE checks whether the provided random number is already registered (i.e., was used by another MC GW UE) and as indicated by the MC service identifier, is supported. The MC GW UE may also check whether sufficient resources are available or if any other local criteria are met. If the MC service is supported, the procedure may continue with step 3, otherwise the procedure may proceed with step 7.

[0077] At step 3, the MC GW UE sends the connection registration / authorization request to the MC server, e.g. an identity management server (IDMS).

[0078] At step 4, the MC server performs a pre-authorization check, to verify that access via the MC GW UE is permitted. An MC server shall reject the connection pre-authorization if the MC server received the same MC service ID and the same random number for which the MC server already has pre- authorized. The MC server stores the random number and marks as pre-authorized the MC GW client.

[0079] At step 5, the MC server sends the connection registration / authorization response to the MC GW UE.

[0080] At step 6, the MC GW UE marks the MC GW client as pre- authorized. Since the MC GW client is not (yet) authenticated, it cannot access to MC service via the MC GW UE. The MC GW UE stores the random number (and MC service ID). If the MC GW client is preauthorized, the MC GW UE enables that client to access only Common Services Core Services. If the MC GW client requests access to other services, e.g. an MC video service, an MC data service, an MC audio service and an MC push to talk service, the request shall be rejected.

[0081] At step 7, the MC GW UE sends the connection response to the MC GW client. The MC GW client enters ‘limited service’ state.

[0082] At step 8, the MC GW client authenticates according to TS 33.180 clause 5.1.2. The random number might be sent as part of the authentication procedure. When the MC user is authenticated, the MC server marks the MC GW client with the random number provided in step 3 as authenticated.

[0083] Steps 9a-d relate to an MC GW UE request as a first option: The MC GW UE requests the authentication status of the MC GW client. The request can include the random number. If the response to the request contains a successful authentication result, the MC GW UE shall mark the MC GW client as authenticated and provide access to all services. Therequest might be triggered by a request from the MC GW client to MC GW UE, e.g. as described with regard to 11.

[0084] Steps lOa-c relate to an MC server push as a second option: The MC server pushes the authentication result to the MC GW UE. The MC GW UE marks the MC GW client as authenticated and provides the MC GW client access to all services. The push might happen interleaved with the procedures in 8. The push message can include the random number.

[0085] Steps 9a-d and steps lOa-c represent options for how the MC GW UE may be informed about the authentication status. For example, either one or both of the two options can be implemented.

[0086] At stepl l, when the MC GW client has access to all services, it can proceed with the authorization process as specified in TS 33.180 clause 5.1.3

[0087] If the MC service user wishes to have access to another MC service, the above procedure may be repeated. The MC service user may select a different MC GW UE for the new MC service, if multiple MC GW UEs are available.

[0088] FIGS. 10A and 10B illustrate schematic block diagrams showing structures of apparatuses according to embodiments of the subject disclosure.

[0089] In FIGS. 10A and 10B, the blocks are basically configured to perform respective methods, procedures and / or functions as described above. It is to be noted that the individual blocks are meant to illustrate respective functional blocks implementing a respective function, process, or procedure, respectively. Such functional blocks are implementation-independent, i.e., may be implemented by means of any kind of hardware or software or combination thereof, respectively.

[0090] An apparatus according to at least one embodiment may represent or realize / embody (e.g., a part of) a UE or loT device as an example of a wireless device or entity. Such apparatus may be illustrated or realized as is shown in FIG. 2. The apparatus or the at least one processor 220 (e.g., together with instructions stored in the at least one memory 230) may be configured to transmit, to a non-terrestrial node, a registration request to authenticate to the network.

[0091] Further, the apparatus or the at least one processor 220 (e.g., together with instructions stored in the at least one memory 230) may be configured to receive, from the nonterrestrial node, a message comprising binding information associated with the non-terrestrial node to be used by the UE or loT device, the binding information being assigned to the UE or loT device.

[0092] Such apparatus may be illustrated or realized as is shown in FIG. 10A as apparatus 1000. The apparatus 1000 may comprise (at least) one or more unit / means / circuitry, denoted by transmitting section 1010, which represent any implementation for (or configured to) transmitting, to a non-terrestrial node, a registration request to authenticate to the network, and (at least) one or more unit / means / circuitry, denoted by receiving section 1020, which represent any implementation for (or configured to) receiving, from the non-terrestrial node, a messagecomprising binding information associated with the non-terrestrial node to be used by the UE or loT device, the binding information being assigned to the UE or loT device.

[0093] As indicated by dashed lines, the apparatus 1000 may comprise (at least) one or more unit / means / circuitry, denoted by processing section 1030, which represent any implementation for (or configured to) performing one or more operations described above.

[0094] Further, an apparatus according to at least one embodiment may represent or realize / embody (e.g., a part of) a non-terrestrial network entity (such as any kind of base station, or the like, incorporated in a satellite) as an example of a non-terrestrial network device or entity.

[0095] Such apparatus may be illustrated or realized as is shown in FIG. 3. The apparatus or the at least one processor 320 (e.g., together with instructions stored in the at least one memory 330) may be configured to receive, from a UE or loT device, a registration request to authenticate to the network.

[0096] Further, the apparatus or the at least one processor 320 (e.g., together with instructions stored in the at least one memory 330) may be configured to store the registration request and assign binding information associated with the non-terrestrial network entity to the UE or loT device responsive to a link between the non-terrestrial network entity and a terrestrial network entity (e.g., such as any kind of ground-based base station or the like) of the network to forward the registration request not being available. Also, the apparatus or the at least one processor 320 (e.g., together with instructions stored in the at least one memory 330) may be configured to transmit, to the UE or loT device, a message comprising the binding information to be used by the UE or loT device.

[0097] Such apparatus may be illustrated or realized as is shown in FIG. 10B as apparatus 1100. The apparatus 1100 may comprise (at least) one or more unit / means / circuitry, denoted by receiving section 1110, which represent any implementation for (or configured to) receiving, from a UE or loT device, a registration request to authenticate to the network, (at least) one or more unit / means / circuitry, denoted by storing and assigning (i.e., processing) section 1120, which represent any implementation for (or configured to) storing the registration request and assigning binding information associated with the non-terrestrial network entity to the UE or loT device responsive to a link between the non-terrestrial network entity and a terrestrial network entity of the network to forward the registration request not being available, and (at least) one or more unit / means / circuitry, denoted by transmitting section 1130, which represent any implementation for (or configured to) transmitting, to the UE or loT device, a message comprising the binding information to be used by the UE or loT device.

[0098] The apparatus 1100 may comprise (at least) one or more unit / means / circuitry (not shown in FIG. 10B), which represent any implementation for (or configured to) performing one or more operations described above.

[0099] For further details regarding the operability / functionality of the apparatuses (or units / means thereof) according to some embodiments of the subject disclosure, reference is made to the above description in connection with any one of FIGS. 1 to 10, respectively.

[0100] For further example embodiments and details regarding the operability / functionality of the apparatuses (or units / means thereof) and / or methods according to some embodiments, reference is made to the following sections. These sections supersede respective sections of Release 18 and / or Release 19 of 3GPP TS 23.280, which is hereby incorporated by reference. The following clauses are thus to be understood in the context of the 3GPP TS 23.280 standard.11 .5 Procedures and information flows11 .5.1 Connection authorisation mechanisms11.5.1.1 GeneralThe connection of non-3GPP devices via an MC gateway UE require authorisation verification by the MC system. Two different types of non-3GPP devices are supported, those which can host MC service client and those which cannot host MC service clients.11 .5.1 .2 Connection authorisation for non-3GPP devices that host an MC client11.5.1.2.1 GeneralThe solution is applied to non-3GPP devices which can host an MC client. The MC server performs authorization for the use of the MC gateway UE by the MC gateway client, i.e. the binding between the MC gateway UE and the MC gateway client is authorized and controlled by the MC server. The MC gateway client informs MC clients about the connection status.For the period of association between MC server, MC gateway client and MC gateway UE, the MC server maintains the assignment between MC clients to the MC gateway UE used. This assignment is cancelled again with the disconnection.11 .5.1 .2.2 Information flows11 .5.1 .2.2.1 Connection authorization requestTable 11.5.1.2.2.1-1 describes the information flow connection authorization request sent from the MC gateway client, which resides on a non-3GPP device, to the MC gateway UE, and from the MC gateway UE to the MC server.Table 11.5.1.2.2.1-1 : Connection authorization requestNOTE: The MC service ID used for MC service authorisation and the GW MC service ID used for connection authorization may have different values. Both identities are configured by the Mission Critical Organisation.11 .5.1 .2.2.2 Connection authorization responseTable 11.5.1.2.2.2-1 describes the information flow connection authorization response sent from the MC server to the MC gateway UE, and from the MC gateway UE to the MC gateway client residing on a non-3GPP device.Table 11.5.1.2.2.2-1 : Connection authorization response11 .5.1 .2.2.3 User authentication resultTable 11.5.1.2.2.3-1 describes the information flow user authentication result sent from the MC server to the MC gateway UE.Table 11.5.1.2.2.3-1 : User authentication result11 .5.1 .2.2.4 User authentication result responseTable 11.5.1.2.2.4-1 describes the information flow user authentication result response sent from the MC gateway UE to the MC server.Table 11.5.1.2.2.4-1 : User authentication result response11 .5.1 .2.3 Connection authorisation procedureThe procedure for connection authorisation via an MC gateway UE towards an MC server is shown in figure 11.5.1.2.3-1.Pre-conditionsThe MC service user wishes to have access to MC services using a non-3GPP device.The MC gateway client has been configured with the necessary parameters needed for connectivity with the MC gateway UE.- The MC gateway client hosted at the non-3GPP device has been provided with an appropriate GW MC service ID.- The MC gateway UE has performed service authorization for one or more MC services with the MC system as described in 3GPP TS 23.379

[0016] , 3GPP TS 23.281

[0012] , and 3GPP TS 23.282

[0013] ,- The MC gateway client has selected an MC gateway UE or alternatively, the MC gateway client has performed a selection by internal criteria.NOTE: The internal criteria are outside the scope of the present document.Figure 11.5.1.2.3-1 : Connection authorisation with an MC server via an MC gateway UE1. The MC gateway client requests connection authorization via the MC gateway UE with an MC server. The MC gateway client provides the Connection ID identifying the connection and the GW MC service ID indicating the requested MC service (e.g. MCPTT).2. The MC gateway UE checks whether the provided Connection ID is already registered (i.e. was used by another MC gateway UE) and the requested MC service, as indicated by the GW MC service ID, is supported by the MC gateway UE. The MC gateway UE may also check whether sufficient resources are available or if any other local criteriaare met. If the MC service is supported, the procedure continues with step 3, otherwise the procedure proceeds with step 7.NOTE: Further information to the MC gateway UE selection is in Annex D.3. The MC gateway UE sends the connection authorization request to the MC server (IdMS).4. The MC server performs a pre- authorization check, to verify that access via the MC gateway UE is permitted. An MC server shall reject the connection pre-authorization when the MC server receives connection authorization from a MC gateway client for a particular MC service for which the connection already exists with the same or different MC gateway UE. The MC server stores the Connection ID and marks the MC gateway client as pre- authorized.5. The MC server sends the connection authorization response to the MC gateway UE.6. The MC gateway UE marks the MC gateway client as pre-authorized and stores the Connection ID. The MC gateway client has now access only to CSC-1 services via the MC gateway UE. If the MC gateway client requests access to other services, the request shall be rejected.7. The MC gateway UE sends the connection authorization response to the MC gateway client. The MC gateway client enters CSC-1 service only state.8. The MC gateway client authenticates according to 3GPP TS 33.180

[0025] clause 5.1.2. The Connection ID shall be sent as part of the authentication procedure. When the MC user is authenticated, the MC server marks the MC gateway client as authenticated.9. The MC server sends the user authentication result to the MC gateway UE.10. The MC gateway UE marks the MC gateway client as authenticated and provides the MC gateway client access to MC services.11. The MC gateway UE sends the user authentication result response to the MC server.12. When the MC gateway client has access to MC services, it can proceed with the authorisation process as defined in 3GPP TS 33.180

[0025] clause 5.1.3If the MC service user wishes to have access to another MC service, the above procedure is repeated. The MC service user may select a different MC gateway UE for the new MC service, if multiple MC gateway UEs are available.11 .5.1 .3 Connection authorisation for non-3GPP devices that do not host an MC client1 1.5.1.3.1 GeneralThe clause is applied to non-3GPP devices which cannot host an MC client. The MC server performs authorization for the use of the MC gateway UE by the MC gateway client, i.e. the binding between the MC gateway UE and the MC client is authorized and controlled by the MC server.NOTE: The interworking between the MC gateway client hosted at the MC gateway UE and an MC service user is out of scope of the present document, nevertheless, the connection authorisation performed by the MC gateway UE shall enable the non- 3GPP devices to get the access to MC services requested by the service user.11 .5.1 .3.2 Information flows11 .5.1 .3.2.1 Connection authorization requestTable 11.5.1.3.2.1-1 describes the information flow connection authorization request sent from the MC service client, which resides on a MC gateway UE, to the MC server.Table 11.5.1.3.2.1-1 : Connection authorization requestNOTE: The MC service ID used for MC service authorisation and the GW MC service ID used for connection authorization may have different values. Both identities are configured by the Mission Critical Organisation.11 .5.1 .3.2.2 Connection authorization responseTable 11.5.1.3.2.2-1 describes the information flow connection authorization response sent from the MC server to the MC gateway client residing on the MC gateway UE.Table 11.5.1.3.2.2-1 : Connection authorization response11 .5.1 .3.3 Connection authorisation procedureThe procedure for connection authorisation of an MC gateway client hosted by the MC gateway UE towards an MC server is shown in figure 11.5.1.3.3-1.Pre-conditions- The MC service user wishes to have access to MC services using a non-3GPP device, where the MC gateway client and MC clients are hosted by the MC gateway UE.- The MC gateway client has selected an MC gateway UE or alternatively, the non-3GPP has performed a selection by internal criteria.NOTE: The internal criteria are outside the scope of the present document.- The MC gateway client, which is hosted by the MC gateway UE, has been configured with the necessary parameters needed for connectivity with the MC gateway UE.- The MC gateway UE has performed service authorization for one or more MC services with the MC system as described in 3GPP TS 23.379

[0016] , 3GPP TS 23.281

[0012] , and 3GPP TS 23.282

[0013] ].Figure 11.5.1.3.3-1 : Connection authorisation of an MC gateway client hosted by an MC gateway UE1. The MC gateway client, hosted by the MC gateway UE, requests connection authorization with an MC server by providing the GW MC service ID. The MC gateway UE sends the connection authorization request to the MC server.2. The MC server performs a connection authorization check, to verify that access using the MC gateway UE is permitted. An MC server shall reject the connection authorization when the MC server receives connection authorization from a MC gateway client for a particular MC service for which the connection already exists with the same or different MC gateway UE.3. The MC server sends the connection authorization response to the MC gateway client residing on the MC gateway UE.The MC gateway client has now access to the MC server and may continue with user authentication and service authorization.If the MC service user wishes to have access to another MC service, the above procedure is repeated. The MC service user may select a different MC gateway UE for the new MC service, if multiple MC gateway UEs are available.11.5.4 Disconnection mechanism11.5.4.1 GeneralA connection using an MC gateway UE by the corresponding MC gateway client can be cancelled over time or re-established using same or another MC gateway UE. The connection / disconnection mechanism allows the MC gateway client to disconnect the use of the corresponding MC gateway UE considering the various MC client hosting scenarios.Under certain circumstances, the connection with the corresponding MC gateway UE can change or has to be adjusted. The various reasons are detailed in the informative Annex D. For this purpose, the MC gateway UE can send a notification to the corresponding MC gateway client hosted on a non-3GPP device.11 .5.4.2 Disconnection for non-3GPP devices that host an MC client11.5.4.2.1 GeneralThe clause is applied to non-3GPP devices which can host an MC client. The MC gateway UE forwards the disconnection request to the corresponding MC server to disconnect the MC gateway UE to MC client connection.11.5.4.2.2 Information flows11.5.4.2.2.1 Disconnection requestTable 11.5.4.2.2.1-1 describes the information flow disconnection request sent from the MC client, which resides on a non-3GPP device, to the corresponding MC server via the MC gateway UE.Table 11.5.4.2.2.1-1 : Disconnection request11.5.4.2.2.2 Disconnection responseTable 11.5.4.2.2.2-1 describes the information flow disconnection response sent from the MC server to the MC gateway UE, and from the MC gateway UE to the MC client residing on a non-3GPP device.Table 11.5.1.2.2.2-1 : Disconnection response11 .5.4.2.2.3 Connection status notificationTable 11.5.4.2.2.3-1 describes the information flow connection status notification sent from the MC gateway UE to the MC client, which resides on a non-3GPP device.Table 11.5.4.2.2.3-1 : Connection status notification11.5.4.2.3 Disconnection procedureThe procedure for disconnection via an MC gateway UE towards an MC server is shown in figure 11.5.4.2.3-1.Pre-conditions- The MC service user has an authorized connection via an MC gateway UE to an MC server.- The MC clients have no communication ongoing, e.g. group communication.- The MC gateway client service user on a non-3GPP device wishes to disconnect the authorized connection.Figure 11.5.4.2.3-1 : Disconnection with an MC server via an MC gateway UE1. The MC gateway client requests disconnection via the MC gateway UE with an MC server. The MC gateway client of the MC service user provides the Connection ID which was created during the connection authorisation procedure (see clause 11.5.1.2) and the GW MC service ID indicating the MC service (e.g. MCPTT).2. The MC gateway UE sends the disconnection request to the MC server to disconnect the authorized connection between the MC gateway client and the MC server.3. The MC server verifies if the connection is active and updates the connection status as disconnected.4. The MC server sends the disconnection response to the MC gateway UE.5. The MC gateway UE updates MC gateway client connection status as disconnected.6. The MC gateway UE sends the disconnection response to the MC gateway client.11 .5.4.2.4 Connection status notificationThe procedure for connection status notification initiated by an MC gateway UE towards an MC gateway client is shown in figure 11.5.4.2.4-1 informs about the status of connection status that may result into a disconnection.Pre-conditions- The MC gateway client has an authorized connection via an MC gateway UE to an MC server.The MC gateway UE is no longer able to provide the requested service depending on reasons further detailed in Annex D.Figure 11.5.4.2.4-1 : Connection status notification to an authorized MC gateway client1. The MC gateway UE wants to disconnect the connection with an MC server for the corresponding MC gateway client. The MC gateway UE sends connection status notification to the MC gateway client using the corresponding Connection ID which was created during the connection authorisation procedure (see clause 11.5.1.2) the GW MC gateway ID and the GW MC service ID indicating the MC service (e.g. MCPTT).2. The connection status may result that the MC gateway client wants to disconnect the connection with the MC server (see disconnection in clause 11.5.4.2.3).11 .5.4.3 Disconnection for non-3GPP devices that do not host an MC client1 1.5.4.3.1 GeneralThe clause is applied to non-3GPP devices which cannot host an MC client. The MC server is requested to disconnect the MC gateway UE to MC client connection on demand.1 1.5.4.3.2 Information flows11.5.4.3.2.1 Disconnection requestTable 11.5.4.3.2.1-1 describes the information flow disconnection request sent from the MC client, which resides on a MC gateway UE, to the MC server.Table 11.5.4.3.2.1-1 : Disconnection request11.5.4.3.2.2 Disconnection responseTable 11.5.4.3.2.2-1 describes the information flow disconnection response sent from the MC server to the MC client residing on the MC gateway UE.Table 11.5.4.3.2.2-1 : Disconnection response11.5.4.3.3 Disconnection procedureThe procedure for disconnection of an MC gateway client hosted by the MC gateway UE towards an MC server is shown in figure 11.5.4.3.3-1.Pre-conditions- The MC service user has an authorized connection using an MC gateway UE to an MC server.- The MC clients have no communication ongoing, e.g. group communication.- The MC gateway client hosted on a MC gateway UE wishes to disconnect the authorized connection.Figure 11.5.4.3.3-1 : Disconnection of an MC client hosted by an MC gateway UE1. The MC gateway client, hosted by the MC gateway UE, sends a disconnection request to the corresponding MC server encompassing the GW MC service ID indicating the MC service (e.g. MCPTT).2. The MC server verifies if the connection is active and updates the connection status as disconnected.3. The MC server sends the disconnection response to the MC gateway client residing on the MC gateway UE.4. The MC gateway UE updates MC gateway client connection status to disconnected.18.1 GeneralThis clause describes the connection authorization procedure and the disconnection procedure to pre-authorize an MCPTT gateway client.18.2 MCPTT gateway client procedures18.2.1 Connection authorization requestIn order to get pre-authorized, the MCPTT gateway client:1) shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428

[0033] ;2) shall set the Request-URI to the MC GW MCPTT ID of the MCPTT gateway UE server in the MCPTT gateway UE;3) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcptt" (coded as specified in 3GPP TS 24.229 [4]), in the P-Asserted-Service-Id header field according to IETF RFC 6050 [9];4) shall include an application / vnd.3gpp.mcptt-info+xml MIME body with an <mcptt-Params> element containing a <connection-id> element set to a random number drawn by the MCPTT gateway client; and5) shall send the SIP MESSAGE request towards the MCPTT gateway UE server in the MCPTT gateway UE.18.3 MCPTT gateway UE procedures18.3.1 Receipt of a connection authorization requestUpon receiving a connection authorization request from an MCPTT gateway client, the MCPTT gateway UE server shall check whether the ICSI value in the P-Asserted-Service-Id header field is set to "um:urn-7:3gpp- service.ims.icsi.mcptt". If the ICSI value in the P-Asserted-Service-Id header field is set to "urn:um-7:3gpp- service.ims.icsi.mcptt", the MCPTT gateway UE server shall additionally check whether the connection identity in the <connection-id> element of the <mcptt-Params> element contained in the application / vnd.3gpp.mcptt- info+xml MIME body is marked as pre-authorized or authenticated.If the connection identity is marked as neither pre-authorized nor authenticated and the MCPTT gateway UE server accepts the connection authorization request, the MCPTT client in the MCPTT gateway UE:NOTE: The MCPTT client mentioned above differs from the MCPTT client shown in Figure 5.6.2-1. The MCPTT client in this clause refers to an MCPTT client hosted in the MCPTT gateway UE which has completed SIP registration for service authorization.1) shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [4] and IETF RFC 3428

[0033] ;2) shall set the Request-URI to the public service identity identifying the participating MCPTT gateway UE function;3) shall include an application / vnd.3gpp.mcptt-info+xml MIME body with the <mcptt-Params> element containing: a) an <mcptt-request-uri> element set to the MC GW MCPTT ID of the MCPTT gateway UE server; and b) a <connection-id> element set to the connection identity; and4) shall send the SIP MESSAGE request towards the MCPTT server according to the rules and procedures of 3GPP TS 24.229 [4],18.3.2 Receipt of a connection authorization responseThe MCPTT client in the MCPTT gateway UE shall consider a SIP 200 OK response including an application / vnd.3gpp.mcptt-info+xml MIME body with a <connection-id> element and a <pre-auth-result> element as a connection authorization response.Upon receiving a connection authorization response, if the <pre-auth-result> element is set to "true", the MCPTT gateway UE server:1) shall mark the connection identity in the <connection-id> element of the <mcptt-Params> element contained in the application / vnd.3gpp.mcptt-info+xml MIME body as pre-authorized; and2) shall forward the SIP 200 OK response according to the rules and procedures of 3GPP TS 24.229 [4].From then on, for an MCPTT client associated with the connection identity marked as pre-authorized, the MCPTT gateway server UE shall allow signalling with the IdM server only.18.4 MCPTT server procedures18.4.1 Receipt of a connection authorization requestUpon receiving a connection authorization request from an MCPTT client, the MCPTT server hosting an MCPTT gateway UE function shall check whether the connection identity in the <connection-id> element of the <mcptt-Params> element contained in the application / vnd.3gpp.mcptt-info+xml MIME body is marked as preauthorized or authenticated.If the connection identity is marked as neither pre-authorized nor authenticated and the MCPTT gateway UE function accepts the connection authorization request, the MCPTT gateway UE function:1) shall mark the connection identity as pre-authorized; and2) shall store the mapping between: a) the connection identity; and b) the MC GW MCPTT ID of the MCPTT gateway UE server included in the <mcptt-request-uri> element of the <mcptt-Params> element contained in the application / vnd.3gpp.mcptt-info+xml MIME body.Then, the MCPTT server:1) shall generate a SIP 200 OK response;2) shall include, in the SIP 200 OK response, an application / vnd.3gpp.mcptt-info+xml MIME body with: a) a <connection-id> element set to the connection identity; and b) a <pre-auth-result> element set to "true"; and3) shall send the SIP 200 OK response to the MCPTT client according to the rules and procedures of 3GPP TS 24.229 [4],6.2.2 Token exchange procedureUpon receiving:- an indication from the MC service client to acquire a security token for authentication of the MC service user with a partner IdM server; and- a connection identity, if the MC service client is associated with a MC gateway client which has successfully completed the connection authorization procedure (see 3GPP TS 24.379

[0012] , 3GPP TS 24.281

[0021] , and 3GPP TS 24.282

[0022] ); the IdM client:1) shall establish a TLS tunnel to the token endpoint of the home IdM server as specified in 3GPP TS 33.180

[0017] using the configured URL of the token endpoint of the IdM server as specified in the '7<x> / OnNetwork / AppServerInfo / IDMSTokenEndpoint" leaf node of the MCS UE initial configuration MO defined in 3GPP TS 24.483

[0011] and the clarifications in annex A;2) shall generate a Token Exchange Request message as specified in 3GPP TS 33.180

[0017] andIETF RFC 8693

[0018] with the following clarifications: a) shall generate an HTTP POST request method according to IETF RFC 7231

[0024] ; b) shall include the following parameters in the in the entity body of the HTTP POST request method using the "application / x-www-form-urlencoded" format as specified in W3C.REC-html401- 19991224 [7]: i) the grant_type parameter set to a value of "urn:ietf:params:oauth:grant-type:token-exchange" as specified in subclause B.7.2 of 3GPP TS 33.180

[0017] ; ii) the other required parameters as specified in subclause B.7.2 of 3GPP TS 33.180

[0017] ; and iii) the connection identity, if received from the MC service client; and3) shall send the HTTP POST request method towards the IdM server.Upon receipt of a Token Exchange Response message as specified in 3GPP TS 33.180

[0017] andIETF RFC 8693

[0018] , the IdM client:1) shall extract the security token contained in the access_token parameter of the received Token Exchange Response message; and2) shall temporarily store the extracted security token.NOTE 1: The security token can be used by the procedures of subclause 6.2.3 to obtain access tokens from the partner systems indicated by the resource parameter included in the Token Exchange Request message for access to the resources of that partner system.NOTE 2: The security token only needs to be stored until it's lifetime has expired or until it is replaced by a newly acquired security token.6.3.2 Token exchange procedureUpon receipt of a Token Exchange Request message as specified in IETF RFC 8693

[0018] via a secure TLS tunnel between the identity management client and the token endpoint of the IdM server, the IdM server:1) shall validate the received Token Exchange Request message as specified in IETF RFC 8693

[0018] ;2) shall generate a Token Exchange Response message as specified in IETF RFC 8693

[0018] and IETF RFC 6749 [5] with the following clarifications: a) shall generate an HTTP 200 (OK) response to the received Token Exchange Request message according to IETF RFC 7231

[0024] ; and b) include the parameters specified in subclause B.7.3 of 3GPP TS 33.180

[0017] serialized into a JavaScript Object Notation (JSON) structure as specified in IETF RFC 8693

[0018] and IETF RFC 7159

[0020] with the following clarification: i) include the parameters specified in subclause B.8 of 3GPP TS 33.180

[0017] in the security token included in the access_token parameter specified in subclause B.7.3 of 3GPP TS 33.180

[0017] ; and3) shall send the HTTP 200 (OK) response towards the IdM client.If the Token Exchange Request message includes a connection identity, the IdM server shall send the indication that the token exchange procedure was successful and the connection identity to the MC service server.

[0101] As explained above and reiterated below, the present disclosure includes, without limitation, the following example implementations.

[0102] For example, an apparatus comprises a mission critical (MC) gateway (GW) user equipment (UE), comprising: at least one processor; and at least one memory storinginstructions that, when executed by the at least one processor, cause the apparatus at least to, in case of a connection authorization request including an identity: in an instance when a status of the identity is pre-authorized, enabling access for a MC client associated with the identity to a first set of services of a MC core network (NW); and in response to a notification from the MC core NW that the MC client associated with the identity is authenticated, further enabling access for the MC client to a second set of MC services of the MC core NW. For example, the instructions are further configured to cause the apparatus at least to: sending the connection authorization request to the MC core NW and receiving a connection authorization response from the MC core NW, the connection authorization response indicating whether the status of the identity is pre-authorized. For example, the instructions are further configured to cause the apparatus at least to: sending the connection authorization response to a MC GW client. For example, the connection authorization request comprises an MC service identifier (ID). For example, the identity is a number randomly drawn by a MC GW client. For example, the second set of MC services comprises one or more of a MC video service, a MC data service, a MC audio service and a MC push to talk service. For example, the first set of services of a MC core NW is common services core services.

[0103] For example, an apparatus comprises a mission critical (MC) core network (NW), comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform in case of a connection authorization request including an identity: setting a status of the identity as preauthorized; and in an instance when an MC client associated with the identity is successfully authenticated at the MC core NW, setting the status of the identity as authenticated and sending a notification to a MC gateway (GW) user equipment (UE) that the MC client associated with the identity is authenticated. For example, the connection authorization request comprises an MC service identifier (ID). For example, the identity is a number randomly drawn by a MC gateway client. For example, the instructions are further configured to cause the apparatus at least to: rejecting the setting the status of the identity as pre-authorized if the MC core NW received the same MC service ID and the same identity for which the MC core NW already has set pre-authorized status. For example, the instructions are further configured to cause the apparatus at least to: receiving the connection authorization request from a MC GW UE, and sending a connection authorization response to the MC GW UE indicating whether the status of the identity is pre-authorized.

[0104] It should be understood that the apparatuses described may comprise or be coupled to other units or modules etc., such as radio parts or radio heads, used in or for transmission and / or reception. Although the apparatuses have been described as one entity, different modules and memory may be implemented in one or more physical or logical entities.

[0105] It is noted that whilst embodiments have been described in relation to LTE and 5G NR, similar principles can be applied in relation to other networks and communication systems where enforcing fast connection re-establishment is required. Therefore, although certainembodiments were described above by way of example with reference to certain example architectures for wireless networks, technologies and standards, embodiments may be applied to any other suitable forms of communication systems than those illustrated and described herein.

[0106] It is also noted herein that while the above describes exemplary embodiments, there are several variations and modifications which may be made to the disclosed solution without departing from the scope of the subject disclosure.

[0107] In general, the various exemplary embodiments may be implemented in hardware or special purpose circuits, software, logic, or any combination thereof. Some aspects of the subject disclosure may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor, or other computing device, although the subject disclosure is not limited thereto. While various aspects of the subject disclosure may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques, or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

[0108] Example embodiments of the subject disclosure may be implemented by computer software executable by a data processor of the mobile device, such as in the processor entity, or by hardware, or by a combination of software and hardware. Computer software or program, also called program product, including software routines, applets and / or macros, may be stored in any apparatus-readable data storage medium and they comprise program instructions to perform particular tasks. A computer program product may comprise one or more computerexecutable components which, when the program is run, are configured to carry out embodiments. The one or more computer-executable components may be at least one software code or portions of it.

[0109] Further in this regard it should be noted that any blocks of the logic flow as in the figures may represent program steps, or interconnected logic circuits, blocks and functions, or a combination of program steps and logic circuits, blocks, and functions. The software may be stored on such physical media as memory chips, or memory blocks implemented within the processor, magnetic media such as hard disk or floppy disks, and optical media such as for example DVD and the data variants thereof, CD. The physical media is a non-transitory media.

[0110] The memory may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory, and removable memory. The data processors may be of any type suitable to the local technical environment, and may comprise one or more of general-purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), applicationspecific integrated circuits (ASICs), FPGA, gate level circuits and processors based on multicore processor architecture, as non-limiting examples.

[0111] Example embodiments of the subject disclosure may be practiced in various components such as integrated circuit modules. The design of integrated circuits is by and large a highly automated process. Complex and powerful software tools are available for converting a logic level design into a semiconductor circuit design ready to be etched and formed on a semiconductor substrate.

[0112] The foregoing description has provided by way of non-limiting examples a full and informative description of the exemplary embodiment of the subject disclosure. However, various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings and the appended claims. However, all such and similar modifications of the teachings of this invention will still fall within the scope of the subject disclosure as defined in the appended claims. Indeed, there is a further embodiment comprising a combination of one or more embodiments with any of the other embodiments previously discussed.

Claims

CLAIMS1. A method to be performed by a mission critical (MC) gateway (GW) user equipment (UE) in case of a connection authorization request including an identity, the method comprising: in an instance when a status of the identity is pre-authorized, enabling access for a MC client associated with the identity to a first set of services of a MC core network (NW); and in response to a notification from the MC core NW that the MC client associated with the identity is authenticated, further enabling access for the MC client to a second set of MC services of the MC core NW.

2. The method of claim 1, further comprising: sending the connection authorization request to the MC core NW and receiving a connection authorization response from the MC core NW, the connection authorization response indicating whether the status of the identity is preauthorized.

3. The method of claim 2, further comprising: sending the connection authorization response to a MC GW client.

4. The method of claims 1-3, wherein the connection authorization request comprises an MC service identifier (ID).

5. The method of claims 1-4, wherein the identity is a number randomly drawn by a MC GW client.

6. The method of claims 1-5, wherein the second set of MC services comprises one or more of a MC video service, a MC data service, a MC audio service and a MC push to talk service.

7. The method of claims 1-6, wherein the first set of services of a MC core NW is common services core services.

8. A method to be performed by a mission critical (MC) core network (NW) in case of a connection authorization request including an identity, the method comprising: setting a status of the identity as pre-authorized; and in an instance when an MC client associated with the identity is successfully authenticated at the MC core NW, setting the status of the identity as authenticated and sending a notification to a MC gateway (GW) user equipment (UE) that the MC client associated with the identity is authenticated.

9. The method of claim 8, wherein the connection authorization request comprises an MC service identifier (ID).

10. The method of claims 8-9, wherein the identity is a number randomly drawn by a MC gateway client.

11. The method of claims 8-10, further comprising: rejecting the setting the status of the identity as pre-authorized if the MC core NW received the same MC service ID and the same identity for which the MC core NW already has set pre-authorized status.

12. The method of claims 8-11, further comprising: receiving the connection authorization request from a MC GW UE, and sending a connection authorization response to the MC GW UE indicating whether the status of the identity is pre- authorized.

13. An apparatus comprising a mission critical (MC) gateway (GW) user equipment (UE), comprising means for, in case of a connection authorization request including an identity, in an instance when a status of the identity is pre-authorized, enabling access for a MC client associated with the identity to a first set of services of a MC core network (NW); and in response to a notification from the MC core NW that the MC client associated with the identity is authenticated, further enabling access for the MC client to a second set of MC services of the MC core NW.

14. The apparatus of claim 13, further comprising means for: sending the connection authorization request to the MC core NW and receiving a connection authorization response from the MC core NW, the connection authorization response indicating whether the status of the identity is pre-authorized.

15. The apparatus of claim 14, further comprising means for: sending the connection authorization response to a MC GW client.

16. The apparatus of claims 14-15, wherein the connection authorization request comprises an MC service identifier (ID).

17. The apparatus of claims 13-16, wherein the identity is a number randomly drawn by a MC GW client.

18. The apparatus of claims 13-17, wherein the second set of MC services comprises one or more of a MC video service, a MC data service, a MC audio service and a MC push to talk service.

19. The apparatus of claims 13-18, wherein the first set of services of a MC core NW is common services core services.

20. An apparatus comprising a mission critical (MC) core network (NW), comprising means for, in case of a connection authorization request including an identity, setting a status of the identity as pre-authorized; and in an instance when an MC client associated with the identity is successfully authenticated at the MC core NW, setting the status of the identity as authenticated and sending a notification to a MC gateway (GW) user equipment (UE) that the MC client associated with the identity is authenticated.

21. The apparatus of claim 20, wherein the connection authorization request comprises an MC service identifier (ID).

22. The apparatus of claim 20-21, wherein the identity is a number randomly drawn by a MC gateway client.

23. The apparatus of claims 20-22, further comprising means for: rejecting the setting the status of the identity as pre-authorized if the MC core NW received the same MC service ID and the same identity for which the MC core NW already has set pre-authorized status.

24. The apparatus of claims 20-23, further comprising means for: receiving the connection authorization request from a MC GW UE, and sending a connection authorization response to the MC GW UE indicating whether the status of the identity is pre- authorized.

25. A computer program product comprising program instructions stored on a computer readable medium to execute a method of any of claims 1 to 12 when said program is executed on a computer.

Images