Method For Supporting Lawful Interception Of Remote Prose Ue In Network Patent Application (2024)

U.S. patent application number 17/173577 was filed with the patent office on 2021-08-12 for method for supporting lawful interception of remote prose ue in network.The applicant listed for this patent is Samsung Electronics Co., Ltd.. Invention is credited to Youngkyo BAEK, Songyean CHO, Sunghoon KIM, Sung Hwan WON.

METHOD FOR SUPPORTING LAWFUL INTERCEPTION OF REMOTE PROSE UE INNETWORK

Abstract

The disclosure relates to a communication technique forconverging, with an IoT technology, a 5G communication system forsupporting a higher data transmission rate than a 4G system, and asystem therefor. The disclosure may be applied to intelligentservices, such as smart homes, smart buildings, smart cities, smartcars or connected cars, health care, digital education, retailbusinesses, and security and safety related services, on the basisof 5G communications technologies and IoT-related technologies. Amethod for operating relay UE in a mobile communication systemincludes transmitting, to a network node connected to the relay UE,a remote UE report message including remote UE information about aremote UE accessing a network via the relay UE, wherein the remoteUE information includes IP address information allocated to theremote UE; starting a timer upon transmitting the remote UE reportmessage to the network node; receiving, from the network node, aresponse message in reply to the remote UE report message; andstopping the timer upon receipt of the response message from thenetwork node. the IP address information includes an IP address andport information of the remote UE in case that IPv4 is used as anaddress type.

Related U.S. Patent Documents

Claims

1. An operation method by a relay user equipment (UE) in a mobilecommunication system, the method comprising: transmitting, to anetwork node connected to the relay UE, a remote UE report messageincluding remote UE information about a remote UE accessing anetwork via the relay UE, wherein the remote UE informationincludes Internet protocol (IP) address information allocated tothe remote UE; starting a timer upon transmitting the remote UEreport message to the network node; receiving, from the networknode, a response message in reply to the remote UE report message;and stopping the timer upon receipt of the response message fromthe network node, wherein the IP address information includes an IPaddress and port information of the remote UE in case that IPversion 4 (IPv4) is used as an address type.

2. The method of claim 1, wherein the remote UE informationcomprises user information associated with the remote UE.

3. The method of claim 2, wherein the IP address informationfurther includes an IP address or IPv6 prefix of the remote UE incase that IP version 6 (IPv6) is used as the address type.

4. The method of claim 2, wherein the user information comprises atleast one of International Mobile Subscriber Identity (IMSI),mobile subscriber integrated services digital network number(MSISDN), a session initiation protocol (SIP) uniform resourceidentifier (URI), user information for proximity-based service(ProSe), and Subscription Permanent Identifier (SUPI), GenericPublic Subscription Identifier (GPSI).

5. The method of claim 1, wherein the remote UE report message is acontrol message for a packet data network (PDN) connection in orderfor the relay UE to use the remote UE as a relay.

6. An operation method by a network node in a mobile communicationsystem, the method comprising: receiving, from a relay userequipment (UE), a remote UE report message including remote UEinformation about a remote UE accessing a network via the relay UE,wherein the remote UE information includes Internet protocol (IP)address information allocated to the remote UE; and transmitting,to the relay UE, a response message in reply to the remote UEreport message, wherein the IP address information includes an IPaddress and port information of the remote UE in case that IPversion 4 (IPv4) is used as an address type.

7. The method of claim 6, wherein the remote UE informationcomprises user information associated with the remote UE.

8. The method of claim 7, wherein the IP address informationincludes an IP address or IPv6 prefix of the remote UE in case thatIP version 6 (IPv6) is used as the address type.

9. The method of claim 7, wherein the user information comprises atleast one of International Mobile Subscriber Identity (IMSI),mobile subscriber integrated services digital network number(MSISDN), a session initiation protocol (SIP) uniform resourceidentifier (URI), user information for proximity-based service(ProSe), and Subscription Permanent Identifier (SUPI), GenericPublic Subscription Identifier (GPSI).

10. The method of claim 6, wherein the remote UE report message isa control message for a packet data network (PDN) connection inorder for the relay UE to use the remote UE as a relay.

11. A relay user equipment (UE) operating in a mobile communicationsystem, the relay UE comprising: a transceiver; and a controllercoupled with the transceiver and configured to control to:transmit, to a network node connected to the relay UE, a remote UEreport message including remote UE information about a remote UEaccessing a network via the relay UE, wherein the remote UEinformation includes Internet protocol (IP) address informationallocated to the remote UE, start a timer upon transmitting theremote UE report message to the network node, receive, from thenetwork function, a response message from the network node in replyto the remote UE report message, and stop the timer upon receipt ofthe response message from the network node, wherein the IP addressinformation includes an IP address and port information of theremote UE in case that IP version 4 (IPv4) is used as an addresstype.

12. The relay UE of claim 11, wherein the remote UE report messageis a control message for a packet data network (PDN) connection inorder for the relay UE to use the remote UE as a relay, and theremote UE information comprises Internet protocol (IP) addressinformation allocated to the remote UE and user informationassociated with the remote UE.

13. A network node operating in a mobile communication system, thenetwork node comprising: a transceiver; and a controller coupledwith the transceiver and configured to control to: receive, from arelay user equipment (UE), a remote UE report message includingremote UE information about a remote UE accessing a network via therelay UE, wherein the remote UE information includes Internetprotocol (IP) address information allocated to the remote UE, andtransmit, to the relay UE, a response message in reply to theremote UE report message, wherein the IP address informationincludes an IP address and port information of the remote UE incase that IP version 4 (IPv4) is used as an address type.

Description

CROSS-REFERENCE TO RELATED APPLICATION(S)

[0001] This application is a Continuation of U.S. Ser. No.15/763,386, which was filed in the U.S. Patent and Trademark Office(USPTO) on Mar. 26, 2018, which is a National Phase Entry of PCTInternational Application No. PCT/KR2016/010783, which was filed onSep. 26, 2016, and claims priority to U.S. Provisional PatentApplication No. 62/232,100, which was filed in the USPTO on Sep.24, 2015, the entire content of each of which is incorporatedherein by reference.

BACKGROUND

1. Field

[0002] The present invention relates to a method for supporting alawful interception on a remote user equipment (UE) accessing anetwork via a proximity services (ProSe) UE-network relay.

2. Description of Related Art

[0003] In order to meet the increasing demand for wireless datatraffic since the commercialization of 4th generation (4G)communication systems, the development focus is on the 5.sup.thgeneration (5G) or pre-5G communication system. For this reason,the 5G or pre-5G communication system is called a beyond 4G networkcommunication system or post long-term evolution (LTE) system.Implementation of the 5G communication system in millimeter wave(mmW) frequency bands (e.g., 60 GHz bands) is being considered toaccomplish higher data rates. In order to increase the propagationdistance by mitigating propagation loss in the 5G communicationsystem, discussions are underway about various techniques such asbeamforming, massive multiple-input multiple output (MIMO), fulldimensional MIMO (FD-MIMO), array antenna, analog beamforming, andlarge-scale antenna. Also, in order to enhance network performanceof the 5G communication system, developments are underway ofvarious techniques such as evolved small cell, advanced small cell,cloud radio access network (RAN), ultra-dense network,device-to-device (D2D) communication, wireless backhaul, movingnetwork, cooperative communication, coordinated multi-points(CoMP), and interference cancellation. Furthermore, the ongoingresearch includes the use of hybrid frequency shift keying (FSK)and quadrature amplitude modulation (QAM)(FQAM) and sliding windowsuperposition coding (SWSC) as advanced coding modulation (ACM),filter bank multi-carrier (FBMC), non-orthogonal multiple access(NOMA), and sparse code multiple access (SCMA).

[0004] Meanwhile, the Internet is evolving from a human-centriccommunication network in which information is generated andconsumed by humans to the Internet of things (IoT) in whichdistributed things or components exchange and process information.The combination of the cloud server-based Big data processingtechnology and the IoT begets Internet of everything (IoE)technology. In order to secure the sensing technology,wired/wireless communication and network infrastructure, serviceinterface technology, and security technology required forimplementing the IoT, recent research has focused on sensornetwork, machine-to-machine (M2M), and machine-type communication(MTC) technologies. In the IoT environment, it is possible toprovide an intelligent Internet Technology that is capable ofcollecting and analyzing data generated from connected things tocreate new values for human life. The IoT can be applied to variousfields such as smart home, smart building, smart city, smart car orconnected car, smart grid, health care, smart appliance, and smartmedical service through legacy information technology (IT) andconvergence of various industries.

[0005] Thus, there are various attempts to apply the IoT to the 5Gcommunication system. For example, the sensor network, M2M, and MTCtechnologies are implemented by means of the 5G communicationtechnologies such as beamforming, MIMO, and array antenna. Theapplication of the aforementioned cloud RAN as a big dataprocessing technology is an example of convergence between the 5Gand IoT technologies.

[0006] In order to meet the increasing demand for wireless datatraffic, discussions are underway about communication technologiesin various fields. Examples of the communication technologiesinclude device-to-device communication, frequency aggregationsystem for use of multiple cells, and multiantenna systems for useof massive antenna arrays.

SUMMARY

[0007] The present invention aims to provide a method forfacilitating lawful interception on a remote UE accessing a networkvia a ProSe UE-network relay.

[0008] Also, the present invention aims to provide a method fortransmitting a small size message in a cellular IoT (CIoT) networkstructure.

[0009] Also, the present invention aims to provide a method formanaging the quality of group communication.

[0010] Also, the present invention aims to provide a method forregistering with a mobile communication operator's network and anapplication server.

[0011] Also, the present invention aims to provide an efficientbroadcast-related signaling transmission method.

[0012] Also, the present invention aims to provide a callconnection method for a public safety network.

[0013] Also, the present invention aims to provide a method foridentifying a signaling and connection mode for a CIoT service.

[0014] In accordance with an aspect of the present invention, anoperation method of a relay user equipment (UE) in a mobilecommunication system includes transmitting a remote UE reportmessage including remote UE information about a remote UE accessinga network via the relay UE to a mobility management entity (MME)connected to the relay UE and receiving a response message from theMME in reply to the remote UE report message.

[0015] Preferably, the remote UE information comprises Internetprotocol (IP) address information allocated to the remote UE anduser information associated with the remote UE.

[0016] Preferably, the IP address information is an IP address orIPv6 prefix of the remote terminal for a case of using InternetProtocol version 6 (IPv6) and an IP address and port information ofthe remote terminal for a case of using Internet protocol version 4(IPv4).

[0017] Preferably, the user information includes at least one ofInternational Mobile Subscriber Identity (IMSI), mobile subscriberintegrated services digital network number (MSISDN), a sessioninitiation protocol (SIP) uniform resource identifier (URI), anduser information for proximity-based service (ProSe).

[0018] Preferably, the method further includes starting a timerupon transmitting the remote UE report message to the MME andstopping the timer upon receipt of the response message from theMME.

[0019] Preferably, the remote UE report message is a controlmessage for packet data network (PDN) connection in order for therelay UE to use the remote UE as a relay.

[0020] In accordance with another aspect of the present invention,an operation method of a mobility management entity (MME) in amobile communication system includes receiving a remote userequipment (UE) report message including remote UE information abouta remote UE accessing a network via a relay UE from the relay UEand transmitting a response message from the relay UE in reply tothe remote UE report message.

[0021] In accordance with another aspect of the present invention,a relay user equipment (UE) operating in a mobile communicationsystem includes a transceiver configured to transmit and receivesignals and a controller configured to control to transmit a remoteUE report message including remote UE information about a remote UEaccessing a network via the relay UE to a mobility managemententity (MME) connected to the relay UE and receive a responsemessage from the MME in reply to the remote UE report message.

[0022] In accordance with still another aspect of the presentinvention, a mobility management entity (MME) operating in a mobilecommunication system includes a transceiver configured to transmitand receive signals and a controller configured to control toreceive a remote user equipment (UE) report message includingremote UE information about a remote UE accessing a network via arelay UE from the relay UE and transmit a response message from therelay UE in reply to the remote UE report message.

[0023] The method and apparatus of the present invention isadvantageous in terms of facilitating lawful interception on aremote UE accessing a network via a ProSe UE-network relay.

[0024] Also, the method and apparatus of the present invention isadvantageous in terms of facilitating small size messagetransmission in a CIoT network structure.

[0025] Also, the method and apparatus of the present invention isadvantageous in terms of facilitating management of groupcommunication quality.

[0026] Also, the method and apparatus of the present invention isadvantageous in terms of facilitating registration with a mobilecommunication operator's network and an application server.

[0027] Also, the method and apparatus of the present invention isadvantageous in terms of facilitating transmission ofbroadcast-related signaling.

[0028] Also, the method and apparatus of the present invention isadvantageous in terms of facilitating a call connection in a publicsafety network.

[0029] Also, the method and apparatus of the present invention isadvantageous in terms of facilitating identification of a signalingand connection mode for a CIoT service.

BRIEF DESCRIPTION OF DRAWINGS

[0030] The above and other aspects, features, and advantages ofcertain embodiments of the present disclosure will be more apparentfrom the following description taken in conjunction with theaccompanying drawings, in which:

[0031] FIG. 1 is a diagram illustrating the ProSe networkarchitecture according to embodiment 1 of the presentinvention;

[0032] FIG. 2 is a signal flow diagram illustrating a procedure fora relay UE to transmit information about lawful interception on aremote UE according to embodiment 1 of the present invention;

[0033] FIG. 3 is a signal flow diagram illustrating a procedure fornotifying a network of disconnection with a remote UE according toembodiment 1 of the present invention;

[0034] FIG. 4 is a signal flow diagram illustrating a procedure fora relay UE to transmit lawful interception information on a remoteUE to a network according to embodiment 1 of the presentinvention;

[0035] FIG. 5A is a signal flow diagram illustrating a procedurefor notifying a network of disconnection with a remote UE accordingto embodiment 1 of the present invention;

[0036] FIG. 5B is a signal flow diagram illustrating a procedure ofcommunicating an ESM status message between a UE and a networkaccording to embodiment 1 of the present invention;

[0037] FIG. 6 is a diagram illustrating CIoT network architectureaccording to embodiment 2 of the present invention;

[0038] FIG. 7 is a diagram illustrating a procedure fortransmitting uplink non-IP data generated by a UE via an MME andSCEF;

[0039] FIG. 8 is a diagram illustrating a procedure of transmittingnon-IP data for a UE in roaming according to the second embodimentof the present invention;

[0040] FIG. 9 is a diagram illustrating a method for configuring asmall data transmission (SDT) or releasing the SDTconfiguration;

[0041] FIG. 10 is a diagram illustrating a procedure oftransmitting non-IP data from a server to a UE (mobile terminatedsmall data transmission procedure);

[0042] FIG. 11 is a diagram illustrating an MCPTT service calledpublic safety network system and configurations of an SIP Core forinterworking with an EPS, the EPS, and a UE;

[0043] FIG. 12 is a diagram illustrating a method for registrationwith a mobile communication operator's network and an applicationserver according to embodiment 4-1 of the present invention;

[0044] FIG. 13 is a diagram illustrating a method for registrationwith a mobile communication operator's network and an applicationserver according to embodiment 4-2 of the present invention;

[0045] FIG. 14 is a diagram illustrating a method for registrationwith a mobile communication operation's network and an applicationserver according to embodiment 4-3 of the present invention;

[0046] FIG. 15 is a diagram illustrating an AKA authenticationprocedure for MCPTT UE authentication between an MCPTT UE and anSIP Core (or IMS) according to embodiment 4-4 of the presentinvention;

[0047] FIG. 16 is a diagram illustrating an AKA authenticationprocedure for MCPTTUE authentication between an MCPTT UE and an SIPCore (or IMS) according to embodiment 4-5 of the presentinvention;

[0048] FIG. 17 is a diagram illustrating an AKA authenticationprocedure for MCPTTUE authentication between an MCPTT UE and an SIPCore (or IMS) according to embodiment 4-6 of the presentinvention;

[0049] FIG. 18 is a diagram illustrating an AKA authenticationprocedure for MCPTTUE authentication between an MCPTT UE and an SIPCore (or IMS) according to embodiment 4-7 of the presentinvention;

[0050] FIG. 19 is a diagram illustrating a procedure for an S-CSCFto attempt a third party registration upon detection of an IMSRegistration attempt according to embodiment 4-8 of the presentinvention;

[0051] FIG. 20 is a diagram illustrating a procedure for the casewhere the Registration message includes no MCPTT User ID and thereis encryption according to embodiment 4-9 of the presentinvention;

[0052] FIG. 21 is a diagram illustrating an MCPTT authenticationprocedure according to embodiment 4-10 of the presentinvention;

[0053] FIG. 22 is a diagram illustrating an MCPTT userauthentication procedure according to embodiment 4-11 of thepresent invention;

[0054] FIG. 23 is a diagram illustrating a broadcast-related signaltransmission method according to embodiment 5 of the presentinvention;

[0055] FIG. 24 is a diagram illustrating an MBSFN areaadministrated by multiple MCEs according to embodiment 5 of thepresent invention;

[0056] FIG. 25 is a diagram for explaining a dynamiccoordination-based MBMS session start procedure according toembodiment 5 of the present invention;

[0057] FIG. 26 is a diagram illustrating a staticcoordination-based MBMS session start procedure according toembodiment 5 of the present invention;

[0058] FIG. 27 is a diagram illustrating an S1 setup requestprocedure between an eNB and an MME according to embodiment 5 ofthe present invention;

[0059] FIG. 28 is a diagram illustrating an eNB configurationupdate procedure between an eNB and an MME according to embodiment5 of the present invention;

[0060] FIG. 29 is a diagram illustrating an S3 setup requestprocedure between an MCE and an MME according to embodiment 5 ofthe present invention;

[0061] FIG. 30 is a diagram illustrating an MCE configurationupdate procedure between an MCE and an MME according to embodiment5 of the present invention;

[0062] FIG. 31 is a diagram illustrating a method and procedure foran MCPTT UE to transmit an MCPTT Service Request to an MME and forthe MME to update and configure a Bearer Context according toembodiment 6 of the present invention;

[0063] FIG. 32 is a diagram illustrating a method and procedure foran MCPTT UE to transmit an MCPTT service Request to an MME and forthe MME to update and configure a Second bearer context accordingto embodiment 6 of the present invention;

[0064] FIG. 33 is a diagram illustrating a procedure for an MCPTTUE 3330 to receive a paging for an MCPTT service preferentially forreceiving data arriving with a high priority and establish a bearerpreferentially as the result of the paging according to anembodiment of the present invention;

[0065] FIG. 34 is a diagram illustrating a procedure for EPSentities to handle a paging for an MCPTT UE preferentially andestablish a bearer connection for providing the UE with an MCPTTservice preferentially according to embodiment 6 of the presentinvention;

[0066] FIG. 35 is a diagram illustrating a method for an MCPTT UEto notify an EPS network of its MCPTT capability in attaching tothe EPS network and a method and procedure for establishing abearer connection by notifying the EPS network of the cause ofattaching for use of the MCPTT service according to embodiment 6 ofthe present invention;

[0067] FIG. 36 is a diagram illustrating network architecture forsupporting CIoT services according to embodiment 7 of the presentinvention;

[0068] FIG. 37 is a diagram illustrating control plane dataexchange between a CIoT UE and a CIoT RAN and layer-specificinternal operations according to embodiment 7-1 of the presentinvention;

[0069] FIG. 38 is a diagram illustrating a procedure fortransmitting an RRC connection request message between a CIoT UEand a CIoT RAN according to embodiment 7-1 of the presentinvention;

[0070] FIG. 39 is a diagram illustrating an exemplary NAS messageaccording to embodiment 7-2 of the present invention;

[0071] FIG. 40 is a diagram illustrating another exemplary NASmessage according to embodiment 7-2 of the present invention;

[0072] FIG. 41 is a diagram illustrating a method for segmentinglarge data and then informing of a segmentation offset of thecurrent NAS PDU in association with the total segmentation length;and

[0073] FIG. 42 is a diagram illustrating a method for use of anindication indicating whether the current NAS PDU is the last oneof the successively transmitted NAS PDUs.

DETAILED DESCRIPTION

[0074] Exemplary embodiments of the present invention are describedin detail with reference to the accompanying drawings. Detaileddescriptions of well-known functions and structures incorporatedherein may be omitted to avoid obscuring the subject matter of thepresent invention. Further, the following terms are defined inconsideration of the functionality in the present invention, andthey may vary according to the intention of a user or an operator,usage, etc. Therefore, the definition should be made on the basisof the overall content of the present specification.

Embodiment 1

[0075] In order to provide a D2D proximity service via a ProSeUE-network (ProSe UE-NW) relay, ProSe network architecture may beproposed as shown in FIG. 1.

[0076] FIG. 1 is a diagram illustrating the ProSe networkarchitecture according to embodiment 1 of the presentinvention.

[0077] The relay UE (UE-NW relay UE) is located within the coverageof a base station (evolved Node B or eNB) and relays the serviceprovided in the cellular network to a remote UE.

[0078] In order to accomplish this, the UE-NW relay UE isregistered as a relay with an evolved packet core (EPS) network andprepares for the relay service by receiving information necessaryfor providing the relay service and establishing a packet datanetwork (PDN) connection to provide the remote UE with an IPservice. If the relay service is prepared, the UE-NW relay UE maybroadcast an announcement message to advertise its presence as arelay or receive a discovery solicitation message that a remote UEtransmits to discover a relay and, if a predetermined condition isfulfilled, transmit a discovery response message such that theremote UE discovers the UE-NW relay UE.

[0079] The remote UE selects one of the found UE-NW relay UEs andsets up a connection with the corresponding UE-NW relay UE toreceive a service provided through the network.

[0080] The present invention is directed to a method of lawfulinterception on a remote UE connected to an EPC network via a UE-NWrelay UE.

[0081] FIG. 2 is a signal flow diagram illustrating a procedure fora relay UE to transmit information about the lawful interception ona remote UE according to embodiment 1 of the present invention.

[0082] The remote UE 200 transmits a communication request messageto connect to the ProSe UE-NW relay UE 210 at step 201. Next, theremote UE and ProSe UE-NW relay UE authenticate each other mutuallythrough steps 202 and 211 and then, if necessary, the ProSe UE-NWrelay UE 210 may establish a PDN connection for relay at step212.

[0083] The remote UE 200 is allocated or sets an IP address via theProSe UE-NW relay UE 210 at step 203. At step 203, the ProSe UE-NWrelay UE 210 may acquire the IP address or port information alongwith the IP address for the remote UE 200.

[0084] The ProSe UE-NW relay UE 210 may acquire user information(User Info) of the remote UE 200 through steps 201, 202, and 211.The User Info may include at least one of international mobilesubscriber identity (IMSI), mobile subscriber integrated servicesdigital network number (MSISDN), session initiation protocoluniform resource identifier (SIP URI), and User information forProSe.

[0085] The ProSe UE-NW relay UE 210 which has acquired the userinformation sends, at step 214, the ProSe function 220 a remote UEInfo Report message including the information on the remote UE 200,i.e. IP address (or IP address and port information) and User Infoof the remote UE 200. The User Info may include at least one ofIMSI, MSISDN, SIP URI, and User Info for ProSe. In response to theremote UE Info Report message, the ProSe function 220 may transmitto the ProSe UE-NW relay UE 210 an ACK message at step 222.

[0086] At step 221, the ProSe function 220 may transmit to the HSS250 the information on the connection of the remote UE 200 that hasbeen received as above. The message transmitted at step 221 mayinclude at least one of a message type for location update, a ProSerelay access type indicative of a remote UE attempting a connectionvia a ProSe UE-NW relay UE, an IP address (or IP address and portinformation) allocated to the remote UE 200, and an IMSI and userinformation of the remote UE 200.

[0087] The User Info may include at least one of IMSI, MSISDN, SIPURI, and User Info information for ProSe. In reply, the HSS 250 maytransmit to the ProSe function a response message at step 251.

[0088] Meanwhile, a lawful interception agent acquires the IPaddress and port information of the remote UE 200 from the HSS 250or the ProSe function 220 at step 241 and performs lawfulinterception at step 242.

[0089] FIG. 3 is a diagram illustrating a procedure of updating theremote UE-related information in an EPC network when the connectionbetween a remote UE 300 and a relay UE 310 is released in the casewhere lawful interception is performed using the method of FIG. 2according to the first embodiment of the present invention.

[0090] The remote UE 300 is receiving a service via a relay at step301. If the connection between the remote UE 300 and the relay UE31 is released at step 302, the relay UE 310 sends the ProSefunction a Remote UE Info Report message to update the informationon the remote UE 300 at step 312.

[0091] The Remote UE Info Report message may include the userinformation of the remote UE 300 and a connection release indicatorindicative of connection release. The User Info may include atleast one of IMSI, MSISDN, SIP URI, and User Info information forProSe.

[0092] If the updated remote UE information is received, the ProSefunction 320 sends the HSS 350 the updated information of theremote UE 300 in association with the connection at step 321.

[0093] The message transmitted at step 321 may include at least oneof the information on the message type for location update, theinformation on the ProSe relay access released type informing ofthe release of the remote UE that is connected via the ProSe UE-NWrelay UE, and the IMSI information and user information of theremote UE 300.

[0094] The user information may include at least one of IMSI,MSISDN, SIP URI, and User Info information for ProSe. In reply, theHSS sends the ProSe function a response message at step 351.

[0095] FIG. 4 is a signal diagram illustrating a procedure for arelay UE 410 to transmit lawful interception information on aremote UE 400 to the EPS network according to the first embodimentof the present invention.

[0096] The relay UE 410 transmits to the ProSe function 420 theuser ID and IP address/port information for supporting lawfulinterception on the remote UE 400 in the EPC network; thisinformation is relayed to the HSS 450 in order for the GW 440 toperform lawful interception on the remote UE 400.

[0097] In the case where the relay UE 410 transmits the user ID andIP address/port information of the remote UE 400 to the GW 440 viathe MME 430 to support lawful interception, the information on theremote UE 400 may be conveyed by an NAS message transmitted fromthe relay UE 410 to the MME 430.

[0098] The remote UE 400 transmits a communication request messageto the ProSe UE-NW relay UE 410 for connection thereto at step 401.The remote UE 400 and the ProSe UE-NW relay UE 410 complete mutualauthentication at steps 402 and 411 and, if necessary, the ProSeUE-NW relay UE 410 may establish a new PDN connection for relay atstep 412.

[0099] An IP address is allocated or configured to the remote UE400 via the ProSe UE-NW relay UE 410 at step 403. At step 403, theProSe UE-NW relay UE 410 may acquire the IP address (or IP addressand port information) of the remote UE 400.

[0100] The ProSe UE-NW relay UE 410 may acquire User Info of theremote UE 400 through steps 401, 402, and 411. The User Info mayinclude at least one of IMSI, MSISDN, SIP URI, and User Infoinformation for ProSe.

[0101] The ProSe UE-NW relay UE 410 which has acquired the aboveinformation may transmit, at step 414, the MME 430 a remote UE InfoReport message including the remote UE information, i.e. IP addressinformation allocated to the remote UE and User Info of the remoteUE.

[0102] The IP address information may include an IP address or IPv6prefix information in case of using IPv6 or an IP address and portinformation in case of using IPv4.

[0103] The User Info may include at least one of IMSI, MSISDN, SIPURI, and User Info information for ProSe. In reply, the MME 430 maytransmit an ACK message to the ProSe UE-NW relay UE 410 at step432.

[0104] Meanwhile, the MME 430 may transmit to the HSS 450 theinformation on the connection of the remote UE at step 431. Themessage transmitted at step 431 may include at least one of amessage type for location update, a ProSe relay access typeindicative of the remote UE attempting connection via the ProSeUE-NW relay UE, IP address information allocated to the remote UE,and IMS and User Info of the remote UE 400.

[0105] The user information may include at least one of IMSI,MSISDN, SIP URI, and User Info information for ProSe. In reply, theHSS 450 may transmit a response message to the MME 430 at step451.

[0106] The information transmitted by the HSS 450 may be used forlocation update, UE identification, or UE authentication procedurein interoperation with the HSS 450 and S-CSCF during the use of theIMS service.

[0107] Meanwhile, the MME 430 may transmit to the G/W 440 theinformation on the connection of the remote UE 400 at step 432. TheRemote UE Info Report message may include the IP addressinformation allocated to the remote UE, IMSI information of theremote UE, and User Info.

[0108] The User Info may include at least one of IMSI, MSISDN, SIPURI, and User Info information for ProSe. In reply, the G/W 440 maytransmit a response message to the MME 430 at step 441.

[0109] Accordingly, the lawful interception agent performs lawfulinterception using the IP address and ports information of theremote UE by means of the G/W 440 at step 442.

[0110] FIG. 5A a diagram illustrating a procedure of updating aremote UE-related information in an EPC network when a connectionbetween the remote UE 500 and a relay UE 510 is released when thelawful interception is performed using the method of FIG. 4according to the first embodiment of the present invention.

[0111] The remote UE 500 is receiving the service via a relay atstep 501. If the connection between the remote UE 500 and the relayUE 510 is released at step 502, the relay UE 510 transmits to theMME, at step 512, a Remote UE Info Report message to update theinformation on the remote UE 500. The Remote UE Info Report messagemay include the User Info of the remote UE 500, a connectionrelease indicator indicative of connection release, and IP addressinformation. The User Info may include at least one of IMSI,MSISDN, SIP URI, and User Info information for ProSe.

[0112] The IP address information may include an IP address or IPv6prefix information in case of using IPv6 or an IP address and portinformation in case of using IPv4.

[0113] If the updated remote UE information is received, the MME530 may transmit the updated information to the HSS 550 at step531. The message transmitted at step 531 may include at least oneof the information on the message type for location update, theinformation on the ProSe relay access released type informing ofthe release of the remote UE that is connected via the ProSe UE-NWrelay UE, and the IMSI information and user information of theremote UE 500. The user information may include at least one ofIMSI, MSISDN, SIP URI, and User Info for ProSe. In reply, the HSS550 may transmit a response message to the MME 530 at step 551.

[0114] Upon receipt of the updated remote UE information, the MME530 may transmit to the G/W 540, at step 532, the updatedinformation on the connection of the remote UE. The Remote UE InfoReport message transmitted at step 532 may include the ProSe relayaccess released type informing of the release of the remote UE 500that is connected via the ProSe UE-NW relay UE and IMSI and UserInfo of the remote UE 500.

[0115] The User Info may include at least one of IMSI, MSISDN, SIPURI, and User Info information for ProSe. In reply, the G/W 540 maytransmit a response message to the MME 530 at step 541.

[0116] In the embodiments of FIGS. 4 and 5A, the steps for therelay UE to transmit the remote UE Info Report to the MME, i.e.,steps 414/433 and 512/533, may be implemented by using a separateNAS message as exemplified above.

[0117] According to an alternative embodiment, it may be possibleto transmit the remote UE Info Report using the legacy ESM STATUSmessage without ACK as follows.

[0118] FIG. 5B is a diagram illustrating a procedure ofcommunicating an ESM status message between a UE and a networkaccording to the first embodiment of the present invention.

[0119] The ESM status message is transmitted to report certainerror conditions detected in receiving ESM protocol data at anarbitrary time, to perform ProSe UE-NW relay, or share IPconnection information of the remote UE. The ESM status message maybe transmitted by an MME or a UE.

[0120] If an ESM entity of the UE receives the ESM status message,the UE may take an action determined by an ESM cause value in theESM status message.

[0121] #43(Invalid EPS bearer identity);

[0122] The UE stops the ESM procedure associated with the receivedEPS bearer identifier, stops a related timer, and deactivates thecorresponding EPS bearer context (without peer-to-peer signalingbetween UE and MME)

[0123] #81(Invalid PTI value);

[0124] The UE stops the ESM procedure associated with the receivedPTI value and stops a related timer.

[0125] #97(Message type non-existent or not implemented);

[0126] The UE stops the ESM procedure associated with the relatedPTI or EPS bearer identifier and stops a related timer.

[0127] On receipt of an ESM STATUS message with any other ESM causevalue, no state transition and no specific action shall be taken asseen from the radio interface, i.e. local actions are possible.

[0128] If the ESM status message is received along with any otherESM cause value, no state transition and no specific action istaken as seen from the radio interface (local actions arepossible).

[0129] If an ESM entity of the MME receives the ESM status message,the MME takes any other action according to the received ESM causevalue.

[0130] #43(Invalid EPS bearer identity);

[0131] The MME stops the ESM procedure associated with the receivedEPS bearer identifier, stops a related timer, and deactivates thecorresponding EPS bearer context (without peer-to-peer signalingbetween MME and UE).

[0132] #81(Invalid PTI value);

[0133] The MME stops the ESM procedure associated with the receivedPTI value and stops a related timer.

[0134] #97(Message type non-existent or not implemented);

[0135] The MME stops the ESM procedure associated with the PTI orEPS bearer identifier and stops a related timer.

[0136] If the ESM status message is received along with any otherESM cause value, the local actions to be taken by the MME may bechanged depending on implementation.

[0137] Hereinafter, a description is made of a timer related to theESM status message for a remote UE report.

[0138] The ESM status message may be used by the relay UE (ProSeUE-NW relay UE) for transmitting IP connection information of theremote UE to the network.

[0139] The relay UE starts a timer Txxxx when establishing orreleasing a PC5 direct link with the remote UE and transmits aremote UE report to the network using the ESM status message beforeexpiry of the timer Txxxx.

[0140] In this case, the ESM cause is set to #128 (Remote UE reporttransaction). The relay UE may transmit the remote UE report ofmultiple UEs in the ESM status message.

[0141] If the relay UE fails in transmitting the remote UE reportto the network using the ESM message before the expiry of the timerTxxxx, it may reset and restart the timer Txxxx and retransmit theEM status message. The retransmission may be repeated 4 times ormore depending on UE implementation.

[0142] If the MME receives the ESM status message for a remote UEreport, a remote UE information list associated with the relay UEis updated.

[0143] When the relay UE establishes or releases a PC5 direct linkwith a remote UE, it starts the timer Txxxx; transmits the remoteUE report to the network using the ESM status message before expiryof the timer Txxxx; and, if a timer Tyyy is running, resets thetimer Tyyy.

[0144] In this case, the ESM cause is set to #128(Remote UE reporttransaction). The relay UE may transmit the ESM status messageincluding the remote UE reports of multiple UEs.

[0145] If the relay UE fails in transmitting the remote UE reportto the network using the ESM message before the expiry of the timerTxxxx, it may reset and restart the timer Txxxx and retransmit theEM status message. The retransmission may be repeated 4 times ormore depending on UE implementation.

[0146] If the MME receives the ESM status message for a remote UEreport, a timer Tyyy is started, a remote UE information listassociated with the relay UE is updated, and, in reply, the MMEtransmits an ESM status message without any remote UE report IEincluding the ESM cause set to 128 (Remote UE report transaction)as acknowledgement before the expiry of the time Tyyy.

[0147] If the relay UE receives the acknowledgement, it stopsrunning of the timer Tyyy. However, if the relay UE fails inreceiving the acknowledgement before the expiry of the timer Tyyy,it resets/restarts the timer Tyyy and retransmits the ESM statusmessage. The retransmission may be repeated 4 times, the UE maystop the procedure upon the fifth expiry of the timer.

Embodiment 2

[0148] FIG. 6 is a diagram illustrating CIoT network architectureaccording to the second embodiment of the present invention.

[0149] In reference to FIG. 6, a CIoT serving gateway node (C-SGN)is a network entity, in particular a light-weighted core networkentity for CIoT, including an MME, an S-GW, and a P-GW.

[0150] In the network architecture, the T6a interface is aninterface for exchanging small size messages between an MME and anSCEF. FIG. 7 is a diagram illustrating a procedure for transmittinguplink non-IP data generated by the UE via the MME and SCEF. Here,the term "non-IP data" denotes the data in all data protocolformats with the exception of the IP format.

[0151] 1. The MME/SGSN/C-SGN 700 receives data from the UE via theRAN. The data may be received along with an indicator indicatingwhether the data is conveyed within IP packets. The MME/SGSN/C-SGN700 may check the data packet in order to transmit IP packets tothe P-GW or the PDN directly and non-IP packets via the SCEF.

[0152] In roaming scenarios, the MME 700 transmits data to the SCEF720 of the HPLMN via the IWK-SCEF. It may be possible to setMonitoring Event to small data transmission (SDT) to indicate themessage for data transmission.

[0153] 2a. The MME/SGSN 700 may transmit to the SCEF 720 a messageincluding non-IP data. This message includes an SCEF reference IDfor identifying the connection between the SCEF 720 and theMME.

[0154] 3. The SCEF 720 checks the SCEF Reference ID of the receivedmessage to acquire related SCS/AS Reference ID. The SCS/ASReference ID is an identifier for use between an application server(SCS/AS) and the SCEF, and the SCEF and the application server(SCS/AS) identify each other using this ID.

[0155] The message received by the SCEF 720 may include aMonitoring Destination Address, which is an address of theapplication server (SCS/AS). If the SCS/AS Reference ID is notincluded, it may be possible to determine the destination of thereceived message using the address of the SCS/AS. The SCEFtransmits the non-IP data received at step 2 to the destinationdetermined as above. Here, it may be possible to include the SCS/ASReference ID or any other identifier (External ID or MSISDN) forthe SCS/AS to identify the UE.

[0156] FIG. 8 is a diagram illustrating a procedure of transmittingnon-IP data for a UE in roaming according to the second embodimentof the present invention. The MME and IWK-SCEF are network entitieslocated in the roaming network, and the SCEF is located in the homenetwork.

[0157] 1. The MME/SGSN/C-SGN 800 receives data from the UE via aRAN. The data may be received along with an indicator indicatingwhether the data is conveyed within IP packets. The MME/SGSN/C-SGN800 may check the data packet in order to transmit IP packets tothe P-GW or the PDN directly and non-IP packets via the IWK-SCEF810. It may be possible to set Monitoring Event to small datatransmission (SDT) to indicate the message for datatransmission.

[0158] 2a. If the MME/SGSN 800 is configured to not use theIWK-SCEF 810, it may transmit the message to the SCEF 830 of thehome network directly. In this case, the MME/SGSN may generatebilling information in addition.

[0159] 2c. If the MME/SGSN is configured to transmit a message tothe IWK-SCEF 810 for the UE in roaming, it may transmit the messageconveying the non-IP data received from the UE to the IWK-SCEF.This message may include an SCEF Reference ID for use inidentifying the connection between the MME/SGSN and IWK-SCEF andbetween the MME/SGSN and the SCEF of the home network for theUE.

[0160] The IWK-SCEF 810 transmits the received message to the SCEF830. This message includes the non-IP data transmitted by the UEand the SCEF Reference ID for identifying the connection betweenthe SCEF 830 and the UE.

[0161] 3. The SCEF 830 may check the SCEF reference ID of thereceived message to acquire a related SCS/AS Reference ID. TheSCS/AS Reference ID is an identifier for use between an applicationserver (SCS/AS) and the SCEF, and the SCEF and the applicationserver (SCS/AS) identify each other using this ID. The messagereceived by the SCEF may include a Monitoring Destination Address,which is an address of the application server (SCS/AS). If theSCS/AS Reference ID is not included, it may be possible todetermine the destination of the received message using the addressof the SCS/AS. The SCEF transmits the non-IP data received at step2 to the destination determined as above. Here, it may be possibleto include the SCS/AS Reference ID or any other identifier(External ID or MSISDN) for the SCS/AS to identify the UE.

[0162] <MT Small Data Transmission>

[0163] 1. The SCS/AS transmits MT small data to the SCEF. The smalldata may be transmitted along with the SCS/AS Reference ID and/orSCS/AS Identifier.

[0164] 2. In the case of using the IWK-SCEF, the SCEF transmits theMT small data to the IWK-SCEF. The ID of the IWK-SCEF is obtainedas follows: It is possible to obtain an SCEF Reference IDassociated with the SCS/AS Reference ID received at step 1. Then,it is possible to obtain an IWK-SCEF ID associated with the SCEFReference ID.

[0165] The MT small data may be transmitted along with the SCEFReference ID and/or the SCEF ID. The IWK-SCEF transmits the MTsmall data to the MME/SGSN/C-SGN. Here, the routing information ofthe MME/SGSN/C-SGN is obtained as follows: It is possible to obtainthe Routing Information associated with the SCEF Reference IDreceived at this step. The MT small data may be transmitted alongwith the IMSI, SCEF Reference ID, SCEF ID, and/or IWK-SCEF ID. TheSCEF ID may be an address or name of the SCEF.

[0166] In the case of not using the IWK-SCEF, the SCEF transmitsthe MT small data to the MME/SGSN/C-SGN. Here, the RoutingInformation of the MME/SGSN/C-SGN is obtained as follows: It ispossible to obtain the Routing Information associated with the SCEFReference ID received at this step. The MT small data may betransmitted along with the IMSI for identifying the UE, the SCEFReference ID for identifying the connection between the UE and theSCEF, and/or the SCEF ID.

[0167] 3. The MME/SGSN/C-SGN that has received the MT small datamay transmit the MT small data to the UE identified by theIMSI.

[0168] The MME/SGSN/C-SGN may not serve the corresponding UE. Inthis case, the MME/SGSN/C-SGN may notify the SCEF, directly or viathe IWK-SCEF, that it cannot transmit the MT small data. At thistime, the SCEF may inquire to the HSS about the MME/SGSN/C-SGNrouting information for the corresponding UE. When making theinquiry, the SCEF may user an external ID or IMSI as the UE ID. TheHSS transmits the Routing information to the SCEF. At this time, itis not mandatory to transmit the IMSI information. Afterward, step2 is repeated. One thing different is that a newly received RoutingInformation is used and, in the case of using the IWK-SCEF, theSCEF transmits to the IWK-SCEF the Routing information along withthe MT small data.

[0169] <Configuration and Deletion of Monitoring Event:SDT>

[0170] Although the description is directed to the case where thereis an IWK-SCEF, it may be possible to cover the case where there isno IWK-SCEF by omitting steps 7, 8, and 9 and combining steps 6 and10.

[0171] FIG. 9 is a diagram illustrating a method for configuring asmall data transmission (SDT) or releasing the SDTconfiguration.

[0172] 1. The SCS/AS 940 may transmits a request for SDT to theSCEF. The request message may include an external ID or MSISDN, anSCS/AS ID for identifying the SCS/AS, an SCS/AS Reference ID foridentifying the connection between the SCS/AS 940 and the SCEF 930for the UE, and a parameter indicative of the SDTconfiguration.

[0173] The External ID is an identifier mapped to the IMSI in theHSS, and the SCEF 930 may recognize which IMSI corresponds to theExternal ID through signaling with the HSS 920. The parameterindicative of the SDT may include Traffic Category (see the tablebelow), uplink data size, downlink data size, maximum uplink datasize transmittable at a time, maximum downlink data sizetransmittable at a time, and message exchange frequency.

[0174] The MME/SGSN 900, C-SGN, SCEF 930, or IWK-SCEF 910 maycontrol uplink/downlink data transmission according to the TrafficCategory. For example, if the Traffic Category is set to MARperiodic report, the uplink data cannot have a size equal to orgreater than 200 bytes. Alternatively, if the Traffic Category isset to MAR periodic report, the uplink data arriving at an intervalshorter than 30 minutes is not transmitted.

[0175] The uplink data transmission control may be performed by theMME/SGSN/C-SGN 900, and the downlink data transmission control maybe performed by the SCEF 930 or the IWK-SCEF 910.

TABLE-US-00001 TABLE 4.3-1 Traffic Models for CIoT CategoryApplication example UL Data Size DL Data Size Frequency MobileAutonomous smoke alarm 20 bytes 0 Every few Reporting [MAR]detectors, power ACK payload months; exception reports failurenotifications size is assumed Every year from smart meters, to be 0bytes tamper notifications etc. Mobile Autonomous smart utility 20bytes with a 50% of UL data 1 day [40%], 2 Reporting (MAR)[gas/water/electric] cut off of 200 size hours [40%], 1 periodicreports metering reports, bytes i.e. ACK payload hour [15%], andsmart agriculture, payloads higher size is assumed 30 minutes [5%]smart environment than 200 bytes to be 0 bytes etc. are assumed tobe 200 bytes Network Command Switch on/off, device 0-20 bytes 20bytes 1 day [40%], 2 Switch on/off, device 50% of cases hours[40%], 1 report, request for require UL hour [15%], and meterreading response. 30 minutes [5%] Software Software 200 bytes witha 200 bytes with a 180 days update/reconfiguration patches/updatescut off of 2000 cut off of 2000 model bytes i.e. payload bytes i.e.payload higher than 2000 higher than 2000 bytes are assumed bytesare to be 2000 bytes. assumed to be 2000 bytes.

[0176] 2. The SCEF 930 may store the SCS/AS Reference ID, UE ID,and parameter for SDT that have been received at step 1. The SCEF930 may assign the SCEF Reference ID in response to the request.According to the policy of the operator, if the SCS/AS 940 is notallowed to perform SDT, if the request message is in a wrongformat, or if the transmission amount exceeds the amount allocatedfor SDT request of SCS/AS 940, the SCEF 930 transmits an errormessage to the SCS/AS 940 along with an appropriate cause value.The SCEF 930 may check the parameters for SDT. If at least one ofthe parameters is not compliant with the policy of the operator,the request is rejected.

[0177] 3. The SCEF 930 may transmit a request for SDT to the HSS920 based on the information received at the previous step. The HSSmay configure the parameters for SDT to the MME/SGSN/C-SGNaccording to the parameters included in the request message.

[0178] 4. The HSS 920 may inspect the request to determine whetherthe ID (External ID or MSISDN) of the corresponding UE is includedand the included parameters are acceptable by the mobilecommunication operator. The HSS 920 may check an ID for billing toaccept the request. If the request is rejected, a rejection messagewith a cause is transmitted to the SCEF 930.

[0179] 5. The HSS 920 transmits a message for configuring SDT tothe MME/SGSN/C-SGN 900. This message includes parameters forconfiguring SDT, SCEF ID, SCEF Reference ID, ID for billing, and UEID.

[0180] 6. The MME/SGSN/C-SGN 900 stores the parameters received atstep 5. Afterward, it starts data transmission for the UE. If theSDT-related setting values for configuration that are received fromthe HSS 920 are not appropriate for the policy of the mobilecommunication operator, the MME/SGSN/C-SGN 900 may transmit arejection message in response to the message received at step5.

[0181] 7. For the UE in roaming, the MME/SGSN/C-SGN 900 maytransmit SDT-related configuration parameters to the IWK-SCEF 910.This message may include the SCEF ID, SCEF Reference ID, ID forbilling, parameters for SDT, IMSI as a UE identifier, and Routinginformation for the MME/SGSN/C-SGN.

[0182] The IMSI and MME/SGSN/C-SGN Routing Information may betransmitted only in the case of using the IWK-SCEF 910 and/or ofSDT (or there is any task for information transmission via anyother SCS/AS and/or SCEF). The IWK-SCEF 910 may perform downlinkdata transmission using the IMSI and MME/SGSN/C-SGN RoutingInformation. The MME/SGSN/C-SGN may transmit the IMSI(s) receivedat step 5. The MME/SGSN/C-SGN Routing Information is theinformation on a core network entity serving the UE identified byeach IMSI. The IWK-SCEF maps the IMSI, Routing Information, andSCEF Reference ID and stores the mapping.

[0183] 8. The IWK-SCEF 910 may authorize the SDT request as theSCEF 930 does at step 6. If it fails to authorize the SDT request,the IWK-SCEF 910 transmits to the MME/SGSN/C-SGN 900 a rejectionmessage with an appropriate cause value.

[0184] If it succeeds in authorizing the SDT request, the IWK-SCEF910 stores the received parameters and transmits an ACK to theMME/SGSN/C-SGN 900 to notify that the SDT is configured.

[0185] 9. If it succeeds in authorizing the SDT request, theIWK-SCEF 910 stores the received parameters and transmits an ACK tothe MME/SGSN/C-SGN 900 to notify that the SDT is configured.

[0186] 10. The MME/SGSN/C-SGN 900 may verify the request receivedform the IWK-SCEF 910. It checks whether the SDT has applied forroaming and whether the service is available in the Home PLMN ofthe UE. If not allowed, the MME/SGSN/C-SGN 900 transmits an errormessage to the IWK-SCEF 910. In the case that the UE is not inroaming, the MME/SGSN/C-SGN 900 may check whether the SDT isavailable via the SCEF 930 after steps 5 and 6. If the SDT is notallowed for the corresponding UE, the MME/SGSN/C-SGN 900 maytransmit to the SCEF 930 a rejection message indicating that SDT isnot allowed.

[0187] 11. If the SDT configuration to the UE is successful, theMME/SGSN/C-SGN 900 may transmit to the HSS 920 an ACK to notifythat the SDT configuration has been performed successfully. Thismessage may be transmitted in response to the SDT requesttransmitted by the HSS 920 or the SCEF 930. This message is notlimited to the name of SDT and means a request message fortransmitting non-IP data.

[0188] 12. If the HSS 920 receives the message notifying that theSDT configuration was performed successfully from theMME/SGSN/C-SGN 900, it notifies the SCEF 930 that the SDTconfiguration was performed successfully. This message may includethe SCEF Reference ID for identifying the SCEF connection of theUE, IMSI of a UE identifier, routing information for transmittingthe message to the MME/SGSN/C-SGN, and IWK-SCEF ID for the UE inroaming. The IMSI and MME/SGSN/C-SGN Routing Information may betransmitted only in the case of using the IWK-SCEF and/or of SDT(or there is any task for information transmission via any otherSCS/AS and/or SCEF).

[0189] The IWK-SCEF 910 may perform downlink data transmissionusing the IMSI and MME/SGSN/C-SGN Routing Information. TheMME/SGSN/C-SGN 900 may transmit the IMSI(s) received at step 5. TheMME/SGSN/C-SGN Routing Information is the information on a corenetwork entity serving the UE identified by each IMSI. The IWK-SCEFmaps the IMSI, Routing Information, and SCEF Reference ID andstores the mapping.

[0190] 13. After checking that the SDT configuration to the UE issuccessful, the SCEF 930 may notify the SCS/AS 940 of thecompletion of the SDT configuration. This message may include theSCS/AS Reference ID and a cause value indicating that the SDT wasconfigured successfully.

[0191] <SDT: Small Data Transmission Procedures>

[0192] FIG. 10 is a diagram illustrating a procedure oftransmitting non-IP data from a server to a UE (mobile terminatedsmall data transmission procedure).

[0193] After completing SDT configuration to the UE, the SCS/AS1020 may transmit non-IP data to the UE. The SCS/AS 1020 maydetermine an SCS/AS Reference ID to use and an SCEF 1010 for use intransmission according to an SDT configuration procedure. As aresult of the SDT configuration procedure, the SCEF 1010 maydetermine the SCEF Reference ID for use in transmitting thereceived non-IP data received from the SCS/AS 1020 and the IMSI inuse by the UE.

[0194] 1. The SCS/AS 1020 transmits to the SCEF 1010 a messageincluding the non-IP data addressed to the UE. This messageincludes the SCS/AS reference ID and non-IP type of small dataaddressed to the UE.

[0195] 2. The SCEF 1010 checks the received SCS/AS reference ID todetermine the target MME/SGSN/C-SGN 1000 and identify the UE towhich the data is addressed to obtain the corresponding SCEFReference ID or IMSI. According to the policy of the operator, ifthe SCS/AS 1020 is not allowed to perform SDT or if the SDTfrequency exceeds the transmission frequency allowed for the SCS/AS1020, the SCEF 1010 may perform step 6 immediately and reject theSDT request.

[0196] 3. The SCEF 1010 transmits to the MME/SGSN/C-SGN 1000 theSDT request received at step 2. This message may include an SCEFReference ID for identifying the connection to the SCEF for the UE.This message may include an IMSI for identifying the UE. Thismessage also includes the non-IP data addressed to the UE.

[0197] 4. After receiving the request, the MME/SGSN/C-SGN 1000verifies the corresponding request. If the verification fails, theMME/SGSN/C-SGN 100 notifies the SCEF 1010 of the failure of SDT atstep 5. The failure cause may be indicative of the case where themobile communication operator does not provide the SDT serviceanymore, the SDT amount exceeds the amount allocated for SDT of theSCEF 1010, or SDT frequency exceeds the allowed transmissionfrequency.

[0198] As a result of checking the request received at step 3, ifit is determined that the SDT service is available, theMME/SGSN/C-SGN 1000 transmits the non-IP data received at step 3 tothe UE. The transmission may be performed through NASsignaling.

[0199] 5. After transmitting the non-IP data to the UE, theMME/SGSN/C-SGN 1000 transmits a response to the SCEF 1010 to notifythat the SDT request is processed. If the non-IP data transmissionto the UE fails or is not allowed, the MME/SGSN/C-SGN 1000 maynotify the SCEF 1010 of the failure of the SDT request.

[0200] 6. The SCEF 1010 may notify the SCS/AS 1020 of the result ofthe SDT request.

Embodiment 3

[0201] FIG. 11 is a diagram illustrating an MCPTT service calledpublic safety network system and configurations of an SIP Core forinterworking with EPS, the EPS, and a UE. In FIG. 11, the SIP coreis a system using a transmission protocol called SIP, and IMS is anexample thereof. The P-CSCF (proxy-call session control function)of the SIP Core has an Rx interface for the PCRF (policy andcharging rules function) of the EPS, the Rx interface being used toapply QoS and Policy for providing the UE with the MCPTTservice.

[0202] In reference to FIG. 11, the Rx interface may be definedbetween the PCRF and the P-CSCF and/or between the PCRF and MCPTTserver. If the PCRF exchanges information with two entities, it mayoccur that the MCPTT server and the P-CSCF may transmit mismatchinginformation, resulting in difficulty of QoS control for the UE.Otherwise, if the two entities transmit the same information, thismeans that one entity is signaling meaninglessly and thus it maynot be shown as preferable. Accordingly, it may be necessary toselect one of two options according to an operator policy and/orany other pre-configuration.

[0203] Accordingly, it is necessary for the home and serving PLMNsto identify the connection of the Rx interface. The MCPTTapplication server (AS) for providing the MCPTT service finds anentry point to the Home PLMN using an HPLMN ID. It may also findthe Entry point to the VPLMN using a Serving PLMN ID. The Entrypoint may be an S-CSCF of the SIP core or a P-GW of the EPS. TheSIP Core or EPS has the information for use in finding the PCRF inthe corresponding PLMN.

[0204] The MCPTT AS may have mapping information include a range ofIP addresses for use by the UE. Using this mapping information, itmay be possible to find a PLMN with the IP address in apredetermined range. For example, it may be possible to determinethat IP addresses from IP x to IP y are mapped to PLMN 1.

[0205] In roaming scenarios, the MCPTT AS receives the IP addressof the UE, an ID of the Home PLMN, and an ID of the Visited PLMNfrom the UE through signaling over the MCPTT-1 interface. If theentry point of the corresponding PLMN is configured and the relatedinformation matches the IP address of the UE and Home PLMNID/Visited PLMN ID, the MCPTT AS may find the PCRF in the PLMN ofthe UE. The MCPTT AS perform the operation of finding theinformation on the entry point and PCRF based on the mutual serviceagreement with the Home PLMN or Visited PLMN mobile communicationoperator.

[0206] The information that should be transmitted through the Rxinterface is as follows: [0207] Media or flow description (e.g.SDP); [0208] Priority; [0209] MCPTT Group ID; [0210] MCPTT User IDand/or IMPU; and/or [0211] Call type.

[0212] All or part of the above information may be transmitted fromthe MCPTT AS to the PCRF directly through the Rx interface ortransmitted from the MCPTT AS to the SIP core through the SIP-2interface and then from the P-CSCF to the PCRF through the Rxinterface. The PCRF may establish a new bearer or modify the bearerin use according to the collected information.

[0213] If the UE inserts a special tag into the INVITE header ofthe SIP message, the P-CSCF turns off the Rx control. In this case,the MCPTT server generates a PCC rule autonomously with the PCRF ofthe EPC through the Rx interface.

[0214] Alternatively, if the INVITE message as a SIP messagetransmitted by the UE includes special ICSI information, it may bepossible to delete the Rx control information in the P-CSCF. Thatis, the P-CSCF does not communicate with the PCRF through the Rxinterface. Instead, the MCPTT server generates the PCC rule withthe PCRF through the Rx interface.

Embodiment 4

[0215] FIG. 12 is a diagram illustrating a method for registrationwith a mobile communication operator's network and an applicationserver according to embodiment 4-1 of the present invention.

[0216] 1-a. If the user powers on the MCPTT UE 1200, the UE 1200performs an attach procedure to the LTE network 1210. During theattach procedure, the UE performs an LTE authentication procedureto obtain IP connectivity.

[0217] 1-b. The user enables the MCPTT Client. The MCPTT clientmeans an application for the MCPTT service. The MCPTT Clientaccesses the Identity Management Function 1220 with a URI. TheMCPTT Client configures an HTTPS connection with the IdentityManagement Function 1220 and establishes a TLS connection toperform the authentication procedure. The MCPTT user may access theIdentity Management function for user authentication using usercredentials (e.g., biometrics such as fingerprint and iris, secureduser ID, and ID/password).

[0218] The user credentials may include an MC User ID as a user IDfor a Mission Critical service. The UE 1200 may transmit a serviceidentifier. The service identifier may be used for identifying aspecific service among the MC services.

[0219] 1-c. The MCPTT Client may request to the Identity ManagementFunction 1220 for a Token. This Token is used for authenticatingthe UE in registration with the MCPTT AS 1250 (In the presentinvention, this Token is referred to as Token A). If the UE cannotaccess the SIP core (or IMS), has no Credential, or is not allowedto perform the registration procedure with the SIP core (or IMS),the MCPTT Client may additionally request for a Token for use inIMS registration (in the present invention, this Token is referredto as Token B). The ID management server may transmit a user ID forone or more services. This user ID may be referred to as MCPTT userID.

[0220] The MCPTT Client may acquire Tokens A and B from differentIdentity Management Functions 1220. One identity ManagementFunction 1220 may manage the Identity of the MCPTT AS 1250 whilethe other Identity Management Function 1220 may manage the Identityof the SIP Core (or IMS).

[0221] 2. The MCPTT UE 1200 establish a secure connection to theSIP Core (or IMS). Using this connection, the UE may perform aSIP-based authentication and registration procedure.

[0222] 3-a. The MCPTT UE 1200 performs the registration procedurewith the SIP core (or IMS). For this purpose, the UE transmits tothe SIP Core (or IMS) a SIP Registration message including the IMScredential or Token B. In the case of using Token B, the eP-CSCF1230 derives the IMS identity from the Token and transmits an OKresponse message in response to the SIP Registration messagetransmitted by the MCPTT UE 1200 including the IMS identity. TheIMS Identity is used afterward when the UE transmits an SIPmessage. The MCPTT Client allows the SIP Registration message toinclude Token A, which is delivered to the S-CSCF.

[0223] 3-b. The S-SCSF 1240 forwards Token A and IMS identity tothe MCPTT AS 1250. The MCPTT AS 1250 verifies Token A and, if theuser authentication is successful, transmits the MCPTT User ID tothe UE. The MCPTT User ID and IMS Identity are linked for a UE inthe MCPTT AS. The Registration procedure to the MCPTT AS 1250 maybe performed along with the SIP Core (or ISM) registrationprocedure.

[0224] FIG. 13 is a diagram illustrating a method for registrationwith a mobile communication operator's network and an applicationserver according to embodiment 4-2 of the present invention.

[0225] 1-a. If the user powers on the MCPTT UE 1300, the UEperforms an attach procedure to the LTE network 1310 and LTEauthentication and obtains the IP connectivity.

[0226] 1-b. The user enables the MCPTT Client. The MCPTT Clientaccesses the Identity Management Function 1320 with a URI. TheMCPTT Client accesses the Identity Management Function 1320 with aUR and establishes an HTTPS connection thereto. The MCPTT Clientestablishes the TLS connection to authenticate the IdentityManagement Function. The MCPTT user may access the IdentityManagement function for user authentication using user credentials(e.g., biometrics such as fingerprint and iris, secured user ID,and ID/password).

[0227] 1-c. The MCPTT Client may request to the Identity ManagementFunction 1320 for a Token. This Token is used for authenticatingthe UE in registration with the MCPTT AS 1350 (In the presentinvention, this Token is referred to as Token A). If the UE cannotaccess the SIP core (or IMS), has no Credential, or is not allowedto perform the registration procedure with the SIP core (or IMS),the MCPTT Client may additionally request for a Token for use inIMS registration (in the present invention, this Token is referredto as Token B).

[0228] The MCPTT Client may acquire Tokens A and B from differentIdentity Management Functions 1320. One identity ManagementFunction 1320 may manage the Identity of the MCPTT AS 1350 whilethe other Identity Management Function 1320 may manage the Identityof the SIP Core (or IMS).

[0229] 1-d. The MCPTT Client perform a registration procedure withthe MCPTT AS 1350. The MCPTT Client transmits Token A and IPmultimedia public identity (IMPU: public ID of the UE) to the MCPTTAS 1350. The MCPTT AS 1350 verifies Token A to derive the MCPTTUser ID. The UE 1300 may obtain the IMPU from the information setin the IP multimedia service identity (ISIM) or from Token B. TheMCPTT AS 1350 relates and stores the derived MCPTT User ID andIMPU.

[0230] 2. The MCPTT UE 1300 establish a secure connection to theSIP Core (or IMS). Using this connection, the UE may perform anSIP-based authentication and registration procedure.

[0231] 3-a. The MCPTT UE 1300 performs a registration procedurewith the SIP Core (or IMS). Here, it may be possible to perform theSIP registration using the ISIM or the IMS Credential (e.g., IMPU)obtained from Token B.

[0232] FIG. 14 is a diagram illustrating a method for registrationwith a mobile communication operation's network and an applicationserver according to embodiment 4-3 of the present invention.

[0233] 1. If the user powers on the MCPTT UE 1400, the UE performsan attach procedure to the LTE network 1410 and LTE authenticationand obtains the IP connectivity.

[0234] 2. The user enables the MCPTT Client 1400. The MCPTT Client1400 accesses the Identity Management Function 1420 with a URI andestablishes an HTTPS connection thereto. The MCPTT Client 1400 mayestablish a TLS connection to authenticate the Identity ManagementFunction 1420.

[0235] 3. The MCPTT client 1400 performs a user authenticationprocedure. For this purpose, the MCPTT Client 1400 transmits anAuthentication request message to the Identity Management Function1420. This message may include an IMPU, a user ID that can beidentified by the Identity Management Function 1420, or UserCredentials.

[0236] The user performs user authentication with biometrics suchas fingerprint and iris or secure user ID or user ID/password. Theuser credential may include an MC user ID. The UE may transmit aservice identifier. The service identifier may be used foridentifying a specific service among the MC services. For example,the service identifier may be used to identify the MCPTT. In thefollowing description, the user ID in use for the MCPTT service isreferred to as MCPTT user ID.

[0237] The Identity Management Function 1420 authenticates the userusing the User ID or User Credential. If the authentication issuccessful, the Identity Management Function 1420 generates a Tokenbased on the IMPU and User ID. The IMPU and User ID may be derivedfrom the Token generated as above. The Identity Management Function1420 transmits an authentication response message including theToken to the UE.

[0238] 4. The MCPTT Client 1400 transmits to the P-CSCF 1430 an SIPregistration message, which is forwarded to the I-CSCF and S-CSCF1440. The Registration message includes the IMPU/IMPI and User ID.Afterward, the MCPTT Client 1400 receives a request for IMS AKAauthentication (Challenged).

[0239] 5. The MCPTT Client 1400 that has received theauthentication request transmits an IMS AKA response and aRegistration message including the IMPU/IMPI or User ID to theI-CSCF and S-CSCF 1440. At this time, the MCPTT Client 1400includes the Token received at the previous step in themessage.

[0240] The IMS AKA response is verified by the S-CSCF 1440.

[0241] 6. If the IMS AKA response is valid, the S-CSCF 1440 mayperform a third party registration procedure with the MCPTT AS1450. The S-CSCF 1440 transmits to the MCPTT AS 1450 a Registermessage including the IMPU, User ID, and Token.

[0242] The MCPTT AS 1450 verifies the Token. If it is determinedthat the Token is valid, the MCPTT AS 1450 determines that thereceived User ID is valid. The MCPTT AS 1450 derives the User IDand IMPU from the Token and checks whether the User ID and IMPUcoincide with the User ID and IMPU received at the previous stepfrom the S-CSCF. If the User IDs and IMPUs coincide with eachother, the MCPTT AS 1450 relates and stores the IMPU and the UserID for use in identifying the message with the received IMPU orUser ID afterward. The MCPTT AS 1450 transmits an OK message forACK.

[0243] 7. The S-CSCF 1440 transmits the OK message to the MCPTTClient 1450.

[0244] FIG. 15 is a diagram illustrating an AKA authenticationprocedure for MCPTT UE authentication between an MCPTT UE and anSIP Core (or IMS) according to embodiment 4-4 of the presentinvention. It also shows a trusted node authentication procedurebetween the MCPTT UE and an MCPTT AS.

[0245] 1. If the user powers on the MCPTT UE 1500, the UE 1500performs an attach procedure to an LTE network 1510 and LTEauthentication and obtains the IP connectivity.

[0246] 2. The user enables the MCPTT Client. The MCPTT Clientaccesses the Identity Management Function 1520 with a URI andestablishes an HTTPS connection thereto. The MCPTT Clientestablishes a TLS connection to authenticate the IdentityManagement Function 1520.

[0247] 3. The MCPTT client performs a user authenticationprocedure. For this purpose, the MCPTT Client transmits anAuthentication request message to the Identity Management Function1520. This message may include an IMPU, a user ID that can beidentified by the Identity Management Function 1520, or UserCredentials. The user performs user authentication with biometricssuch as fingerprint and iris or secure user ID or user ID/password.The Identity Management Function 1520 authenticates the user usingthe User ID or User Credential. If the authentication issuccessful, the Identity Management Function 1520 generates a Tokenbased on the IMPU and User ID. The Token is configured inassociation with the IMPI and IMPU and authorized token scope.

[0248] The Identity Management Function 1520 transmits anauthentication response message including the Token.

[0249] 4. The UE 1500 performs an IMS registration procedure andIMS AKA for authenticating the signaling connection. The UEtransmits to the S-CSCF 1540 an IMS Registration message includingthe MCPTT User ID and Token for use in MCPTT Userauthentication.

[0250] 5. If the IMS AKA is successful, the S-CSCF 1540 performs athird party registration procedure with the MCPTT AS. Using theIMPU, MCPTT User ID, and Token received at step 4, the S-CSCFtransmits a Registration message to the MCPTT AS. The MCPTT server1500 verifies the Token and, if the Token is valid, determines thatthe received User ID is reliable.

[0251] Then the MCPTT server derives the IMPU and MCPTT User IDfrom the Token and checks whether the IMPU and MCPTT User IDcoincide with the IMPU and MCPTT User ID included in theRegistration message. If the check is successful, the MCPTT ASrelates the IMPU and MCPTT User Identity and stores therelationship. The MCPTT AS 1550 transmits to the S-CSCF 1540 an OKmessage for acknowledgement.

[0252] 6. The S-CSCF 1540 transmits to the MCPTT Client the OKmessage for acknowledgement.

[0253] FIG. 16 is a diagram illustrating an AKA authenticationprocedure for MCPTTUE authentication between an MCPTT UE and an SIPCore (or IMS) according to embodiment 4-5 of the presentinvention.

[0254] Although the encryption key can be transmitted directly, itmay be possible to exchange the key setup information. The MCPTT ASmay not perform decryption. In this case, the MCPTT AS, ifnecessary, may transmit to the ID management server and/or config.Management server an encrypted MCPTT group/user ID and receive thedecrypted MCPTT group/user ID.

[0255] Steps 1 to 3 of FIG. 16 are substantially identical withsteps 1 to 3 of FIG. 15 that have been described above; thus,detailed descriptions thereof are omitted herein.

[0256] The Identity Management Function 1620 authenticates the userusing the User ID and User Credential. If the authentication issuccessful, the Identity Management Function 1620 transmits anauthentication response message to the UE and notifies the MCPTT ASthat the UE has been authenticated. This message includes the IMPU,User ID, and Valid time for the authentication validity. Afterreceiving the above message, the MCPTT Server starts a ValidityTimer.

[0257] 4. The MCPTT Client 1600 transmits to the P-CSCF 1630 theRegistration message, which is forwarded to the I-CSCF and S-CSCF1640. The Registration message includes the IMPU/IMPI and encryptedUser ID. In order to avoid exposure of the MCPTT User Identity toother entities except the MCPTT AS, the MCPTT Client 1600 mayinclude the encrypted MCPTT User ID in the Registrationmessage.

[0258] The encryption key may be provided by the Configurationmanagement function instead of the Identity management function1620.

[0259] Afterward, the MCPTT Client 1600 is required for IMSAKA.

[0260] 5. After performing the IMS AKA, the MCPTT Client 1600transmits to the S-CSCF the IMS AKA response along with the IMPU,IMPI, and encrypted User ID.

[0261] The S-CSCF 1640 verifies the IMS AKA response.

[0262] 6. If the IMS AKA is successful, the S-CSCF 1640 performs athird party registration procedure with the MCPTT AS 1650. TheS-CSCF 1640 transmits to the MCPTT AS 1650 the Registration messageincluding the IMPU and User ID.

[0263] The MCPTT AS 1650 verifies the validity of the User ID andchecks whether the User ID and IMPU are identical with thosereceived at step 3-d and whether the Validity timer has not expiredyet. After the above process is successful, the MCPTT AS 1650relates the IMPU and User ID and stores the relationship. Therelated ID is used for mutual identification with the identifierthat is used in the message afterward. The MCPTT AS 1650 decodesthe encoded MCPTT User Identity.

[0264] The MCPTT Server 1650 transmits to the S-CSCF 1640 an OKmessage for acknowledgement.

[0265] 7. The S-CSCF 1640 transmits the OK message to the MCPTTClient 1600.

[0266] FIG. 17 is a diagram illustrating an AKA authenticationprocedure for MCPTTUE authentication between an MCPTT UE and an SIPCore (or IMS) according to embodiment 4-6 of the presentinvention.

[0267] If the IMS registration is successful, the S-CSCF performseven the third party registration. In the previous description ofthe invention, the IMS AKA is challenged after the Registration andthen the Registration is performed again. Although the encryptionkey can be transmitted directly, it may be possible to exchange thekey setup information. The MCPTT AS may not perform decryption. Inthis case, the MCPTT AS, if necessary, may transmit to the IDmanagement server and/or config. Management server an encryptedMCPTT group/user ID and receive the decrypted MCPTT group/userID.

[0268] FIG. 18 is a diagram illustrating an AKA authenticationprocedure for MCPTTUE authentication between an MCPTT UE and an SIPCore (or IMS) according to embodiment 4-7 of the presentinvention.

[0269] In FIG. 18, Token 1 is used for IMS authentication, Token 2is used for MCPTT AS authentication, and encrypted information maybe used.

[0270] Although the encryption key can be transmitted directly, itmay be possible to exchange the key setup information. The MCPTT ASmay not perform decryption. In this case, the MCPTT AS, ifnecessary, may transmit to the ID management server and/or config.Management server an encrypted MCPTT group/user ID and receive thedecrypted MCPTT group/user ID.

[0271] Steps 1 to 3 of FIG. 18 are identical with the steps 1 to 3of FIG. 15 that have been previously described; thus, detaileddescriptions thereof are omitted herein.

[0272] The Identity Management Function 1820 may provide the MCPTTClient 1800 with an encryption key. The encryption key is used forencrypting the MCPTT User Credential, and the SIP Core (or ISM)cannot decrypt the encrypted MCPTT User Credential.

[0273] The Identity Management function 1820 authenticates the userusing the user ID and user credentials. If the authentication issuccessful, the Identity Management function 1820 creates twoTokens. The two tokens are called Token 1 and Token 2. Token 1 iscreated based on a pair of IMPU and IMPI. The IMPU and IMPI may bederived from Token 1. Token 2 is created based on the IMPU and UserID. The IMPU and User ID may be derived from Token 2.

[0274] The Identity Management Function 1820 transmits to the MCPTTClient an authentication response message including Token 1 andToken 2.

[0275] 4. The MCPTT Client 1800 transmits to the eP-CSCF 1830 aRegistration message including the received Tokens and encryptedUser ID. In order to prevent the MCPTT User ID from being exposedto other entities except the MCPTT AS, the MCPTT Client 1800encrypts the User ID and includes the encrypted User ID in themessage.

[0276] The eP-CSCF 1830 verifies Token 1 to obtain the IMPU andIMPI. If Token 1 is verified successfully, the eP-CSCF 1830transmits to the S-CSCF a Registration message including the IMPU,IMPI, User ID, and Token 2. The S-CSCF 1840 performs a Trusted NodeAuthentication procedure as the Registration procedure without anyextra authentication procedure. The message may include anindicator indicating that the authentication has already beencarried out.

[0277] 5. The S-CSCF 1840 performs a third party registration withthe MCPTT AS 1850. The S-CSCF 1840 transmits to the MCPTT AS aRegistration message including the IMPU, encrypted User ID, andToken 2.

[0278] The MCPTT AS 1850 verifies Token 2. If the Token is verifiedsuccessfully, the MCPTT AS assumes that the User ID is valid andchecks whether the User ID and IMPU derived from Token 2 coincidewith the IMPU and User ID in the Registration message. If theymatch, the MCPTT AS 1850 relates the IMPU and MCPTT User ID andstores the relationship between the IMPU and MCPTT User ID. TheMCPTT AS decrypts the encrypted User ID. The MCPTT AS 1850 may havean encryption key received from the Identity management function orpreconfigured.

[0279] The MCPTT AS 1850 may transmit to the S-CSCF 1840 an OKmessage for acknowledgement.

[0280] 7. The S-CSCF 1840 transmits to the MCPTT Client 1800 the OKmessage for acknowledgement.

[0281] FIG. 19 is a diagram illustrating a procedure for an S-CSCFto attempt a third party registration upon detection of IMSRegistration attempt according to embodiment 4-8 of the presentinvention.

[0282] The MCPTT UE 1900 and the SIP Core (or IMS) perform the IMSAKA authentication to authenticate the MCPTT UE 1900. The S-CSCF1940 performs Trust Node Authentication for MCPTT Userauthentication between the MCPTT Client 1900 and the MCPTT Server1950. Although the encryption key can be transmitted directly, itmay be possible to exchange the key setup information. The MCPTT ASmay not perform decryption. In this case, the MCPTT AS, ifnecessary, may transmit to the ID management server and/or config.Management server an encrypted MCPTT group/user ID and receive thedecrypted MCPTT group/user ID.

[0283] Steps 1 to 3 of FIG. 19 are substantially identical withsteps 1 to 3 of FIG. 15 that have been described above; thus,detailed descriptions thereof are omitted herein.

[0284] The Identity Management Function 1920 may provide the MCPTTClient 1900 with an encryption key. The encryption key is used forencrypting the MCPTT User Identity. The encrypted MCPTT UserIdentity is not decrypted by the SIP Core (or IMS).

[0285] The encryption key may be provided by the Configurationmanagement function instead of the Identity Management Function1920.

[0286] In the scenario of FIG. 17, the encryption key and/or keysetup information may be explicitly transmitted to the MCPTT AS atstep 3-d.

[0287] Even in the scenario of FIG. 18, the encryption key and/orkey setup information is transmitted to the client at the similarlyapplicable step 3.

[0288] 4. The UE 1900 performs the IMS Registration and IMS AKAauthentication. The UE 1900 includes the MCPTT User identity andtoken in the Registration message for use in MCPTT Userauthentication. If the MCPTT User Identity is encrypted, the MCPTTClient includes the encrypted MCPTT User ID in the Registrationmessage.

[0289] 5. If the IMS AKA is successful, the S-CSCF 1940 performs athird party registration procedure with the MCPTT AS 1950. TheS-CSCF 1940 transmits to the MCPTT AS 1950 a Registration messageincluding the IMPU, MCPTT User ID, and Token. The MCPTT AS 1950verifies the Token and, if the Token is valid, assumes that theUser ID is valid. Then the MCPTT AS 1950 checks whether the IMPUand MCPTT User ID derived from the Token coincide with the IMPU andMCPTT User ID in the Registration message. If the check issuccessful, the MCPTT AS relates the IMPU and MCPTT User Identityand stores the relationship between the IMPU and MCPTT UserIdentity. Accordingly, it may be possible to identify the userrelated to the message received afterward with an IMPU or MCPTTUser Identity based on the MCPTT User Identity or IMPU.

[0290] The MCPTT AS 1950 decrypts the MCPTT User identity. TheMCPTT AS 1950 may have an encryption key received from the Identitymanagement function or preconfigured. The MCPTT AS 1950 maytransmit an OK message for acknowledgement.

[0291] FIG. 20 is a diagram illustrating a procedure for the casewhere the Registration message includes no MCPTT User ID and thereis encryption according to embodiment 4-9 of the presentinvention.

[0292] Steps 1 to 3 of FIG. 20 are identical with steps 1 to 3 ofFIG. 15 that have been described above; thus, detailed descriptionsthereof are omitted herein.

[0293] 4. If it is necessary to prevent the MCPTT User Identityfrom being exposed to the SIP Core or IMS, the MCPTT Clientincludes no MCPTT user ID in the Registration message.

[0294] 5. If the Registration message includes no MCPTT UserIdentity, the MCPTT AS does not verify the MCPTT User identity andIMPU derived from the Token. Instead, if the Token is valid, theMCPTT AS stores the MCPTT User Identity and IMPU derived from theToken and relates the MCPTT User Identity and IMPU for the MCPTTservice.

[0295] The MCPTT AS transmits an OK message foracknowledgement.

[0296] FIG. 21 is a diagram illustrating an MCPTT authenticationprocedure according to embodiment 4-10 of the presentinvention.

[0297] At power-on, the MCPTT UE 2100 performs LTE authentication.[0298] Step A: The UE 2100 performs the MCPTT User authenticationprocedure based on a Token according to the information configuredto the MCPTT Client. The UE 2100 obtains the Token from theIdentity Management Server 2120. The Token is used for MCPTTauthentication at step C.

[0299] The UE transmits to the Identity management server 2120 anMC User ID along with other User Credentials. A Service ID (e.g.,NYPD_MCPTT) may be provided too. The Identity Management Server2120 transmits a Service User ID, i.e., MCPTT User ID, to the UE inreply. It may be possible to derive the Service ID, i.e., MCPTTUser ID, from the Token. [0300] Step B: An IMS authenticationprocedure is performed between the MCPTT UE 2100 and the IMS 2130.[0301] Step C: The MCPTT user authentication is performed after theIMS authentication.

[0302] If the MCPTT Server 2140 is administered by the mobilecommunication operator, the Public Safety User Data Function(PS-UDF) or HSS stores the MCPTT User credential for MCPTT userauthentication. The Security information may be generated through amutual authentication procedure. If the MCPTT server 2140 isadministrated by a public security network agency, the PS-UDFstores the credential necessary for MCPTT user authentication, thesecurity information being created through the mutualauthentication procedure.

[0303] FIG. 22 is a diagram illustrating an MCPTT userauthentication procedure according to embodiment 4-11 of thepresent invention.

[0304] The MCPTT user authentication procedure through an MCPTT-1interface includes the steps as follows. [0305] SIP Digestauthentication (it means IMS registration.) [0306] Token basedauthentication.

[0307] 3. The Identity Management Function 2220 authenticates theuser using the MC User identity and MC User authenticationcredential. If the authentication is successful, the IdentityManagement Function 2220 may generate a Token based on the IMPU, MCUser ID, and Service ID. The Token may be encrypted along with theauthentication information related to the MCPTT User ID and IMPU.The MCPTT User ID may be explicitly transmitted to the UE orderived from the Token afterward.

[0308] The Identity Management Function 2220 may transmit to the UEan authentication response message including the Token.

[0309] 4. The INVITE message may not include the MCPTT User IDbecause the MCPTT User ID may be derived from the Token.

[0310] 5. The S-CSCF 2240 transmits to the MCPTT client 2200 an OKmessage for acknowledgement.

[0311] 6. If the IMS AKA authentication is successful, the S-CSCF2240 performs a third party registration with the MCPTT server2250. The S-CSCF 2240 transmits a Register message including theIMPU, MCPTT User ID, and Token. The MCPTT User ID may not beincluded in the message and, in this case, the MCPTT User ID may bederived from the Token. If no MCPTT user ID is received, the MCPTTUser ID derived from the Token is used as the MCPTT user ID of theUE. The MCPTT AS 2250 relates the IMPU and MCPTT User ID and storesthe relationship between the IMPU and MCPTT User ID.

Embodiment 5

[0312] Embodiment 5 relates to an efficient broadcast-relatedsignal transmission method and apparatus.

[0313] FIG. 23 is a diagram illustrating a broadcast-related signaltransmission method according to embodiment 5 of the presentinvention.

[0314] The UE may send an ECGI to the GCS AS. The GCS-AS 2340 maydetermine whether to transmit an ECGI list to the BM-SC 2330depending on the configuration information. The configurationinformation may become available for the GCS-AS 2340 as animplementation according to the operator policy or throughsignaling between the BM-SC 2330 and GCS-AS 2340.

[0315] 1. The GCS-AS 2340 sends the BM-SC 2330 an Activate MBMSBearer Request message through the MB2 interface for activating theMBMS bearer. This message may include a TMGI for identifying theMBMS bearer. This message may also include Flow ID, QoS, MBMSBroadcast area, and MBMS start time.

[0316] The Flow ID is included only when the TMGI is included andused for identifying a specific Flow in the MBMS traffic identifiedby the TMGI. If the Flow ID is included in the message, the BM-SCassociates the Flow ID with the TMSI or the MBMS Broadcast areaincluded in the message (Association). The QoS value is mapped to avalue indicative of a priority for the MBMS bearer. If the MBMSBroadcast Area includes a list of Cell IDs, the BM-SC 2330 maps theCell IDs to a set of the MBMS service area (SA). The GCS AS 2340may send the ECGI list along with the MBMS SA.

[0317] The BM-SC 2330 may ignore the MBMS SA and re-write with theMBMS SA obtained as described above. If the ECGI list is received,the BM-SC 2330 may include the MBMS SA in the Activate MBMS BearerResponse. The GCS-AS 2340 may configure the MBMS service data withthe MBMS SA. If the ECGI list is not received, the BM-SC 2330 maynot include the MBMS SA in the Activate MBMS Bearer Response.

[0318] In an alternative embodiment, at step 1, if the GCA AS 1240wishes to activate the MBMS bearer over the MB2 interface, the GCAAS 234 sends an Activate MBMS Bearer Request message to the BM-SC2330. This message may include TMGI, QoS, MBMS Broadcast Area, andStart time. The TMGI may be used to identify the MBMS bearer. TheMBMS Broadcast Area may include the list of MBMS service areaidentities, the list of cell IDs, or both the two lists.

[0319] If the MBMS Broadcast area includes the MBMS Service AreaIdentity list, the MBMS Service Area Identity may be checkedaccording to the Cell ID list or any other configurationinformation.

[0320] If the TMGI is included in the message, the BM-SC 2330determines whether the GCS-AS 2340 is authorized to use the TMGI.If the GCS-AS 2340 is not authorized to use the TMGI, the BM-SC2330 rejects the request. If the TMGI is not included in themessage, the BM-SC 2330 assigns an unused value for the TMGI.

[0321] The BM-SC 2330 allocates a Flow ID corresponding to the TMGIand MBMS Broadcast area. If the MBMS Broadcast area parameterincludes the list of Cell IDs, the BM-SC 2330 maps the Cell IDs tothe MBMS Service Area Identities. The cell ID mapping is performedaccording to the mobile communication operator policy. The BM-SC2330 includes the list of MBMS service identities in the MBMSSession Start message. The Cell ID list may also be included in theMBMS Session Start message. If another MBMS bearer with the sameTMGI is already activated, the BM-SC 2330 controls such that theMBMS broadcast area is not overlapping with that of the existingMBMS bearer. The BM-SC 2330 allocates a unique Flow ID to the newMBMS bearer.

[0322] Afterward, the BM-SC 2330 allocates MBMS resources to thecorresponding MBMS broadcast area for contents delivery over theMBMS Bearer and performs a Session Start procedure. The MBMS SAI(s)included in the MBMS Session Start Request message may be theinformation obtained from the cell identifier(s) received from theGCS-AS 2340. In general, the MBMS SAI(s) may be different from theMBMS SAI(s) sent by the GCS-AS 2340. In this case (including thecase where the MBMS SAI(s) is included in the Activate MBMS BearerRequest message sent by the GCS-AS and MBMS sent by the BM-SC;GCS-AS has not sent MBMS SAI(s)), the BM-SC 2330 may include theMBMS SAI(s) included in the MBMS Session Start Request message inthe Activate MBMS Bearer Response message.

[0323] 2. The BM-SC 2330 maps the Cell ID list (ECGIs) to theService area list (SAIs) and determines MBMS-GW(s) for the relatedareas.

[0324] 3. The BM-SC 2330 sends a Session Start message to theMBMS-GW(s) determined as above. This message may include 3GPPRelease-12 MBMS-related parameters and Cell ID list (List ofECGIs).

[0325] 4. The MBMS-GW 2320 sends the Session Start message to theinvolved MME(s). This message may include 3GPP Release-12MBMS-related parameters and Cell ID list (List of ECGIs).

[0326] 5. The MME 2310 sends the Session Start message to theinvolved MCE(s). This message may include 3GPP Release-12MBMS-related parameters and Cell ID list (List of ECGIs). The MME2310 may select the destination of the Session Start message usingthe existing parameters include the received ECGI list and MBMSSA.

[0327] The MME 2310 may have received the MCE identifier to whichan eNB or a cell of the eNB is linked in the S1 Setup or eNBConfiguration Update procedure. Alternatively, the MME 2310 mayhave received a list of cells or eNB linked to the MCE in the M3Setup or MCE Configuration Update procedure. The Session Startmessage may be sent to only an eNB corresponding to the ECGI listreceived using this information. Accordingly, it may be possible toselect a suitable MCE using the eNB-specific service MCEinformation and ECGI information in the S1 Setup or eNBConfiguration Update procedure.

[0328] It may be necessary for multiple MCEs to make consistentdecisions on the areas for MBMS transmission (e.g., in thedistributed MCE architecture). This may be achieved as follows.

[0329] <MBMS Session Start Procedure in Case an MBSFN Area isManaged by Multiple MCEs>

[0330] During the MBMS Session Start procedure, the MCE receives anMBMS Session Start request message from the MME through the M3interface. This message is transmitted for providing the eNB withthe MCCH-related information (radio information for MBMStransmission) and requesting to the eNB to establish a Bearer forMBMS to the UE and notify the UE of the MBMS session.

[0331] In order to achieve the MBSFN transmission, the cells in asignal MBSFN area must be configured with the same MCCH-relatedinformation. If an MBSFN area is controlled by a single MCE, it isobvious to use synchronized MCCH information. If multiple MBSFNareas are controlled by a signal MCE, e.g., due to distributed MCEarchitecture, there is a need of coordination of the MCCH-relatedinformation among the MCEs. In the distributed MCE architecture,all the distributed MCEs responsible for an MBSFN area must producethe same admission control result.

[0332] FIG. 24 is a diagram illustrating an MBSFN areaadministrated by multiple MCEs according to embodiment 5 of thepresent invention.

[0333] FIG. 24 shows how multiple cells in an MBSFN are providedwith the same MCCH-related information in the distributed MCEarchitecture.

[0334] FIG. 25 is a diagram for explaining a dynamiccoordination-based MBMS session start procedure according toembodiment 5 of the present invention. In particular, FIG. 25relates to an MBMS session start procedure in a case where multipleMCEs are managing an MBSFN area and the OAM dynamically providesMCCH-related information.

[0335] 1. The MME 2530 and MBMS GW perform the MBMS session Startprocedure.

[0336] 2. The network management (OAM) 2520 is notified of thesession start by the MME or the MCE from the MME or the MCE. TheMBMS session attributes are provided to the OAM 2520, whichgenerates the MCCH-related information based on the MBMS sessionattributes.

[0337] 3. The OAM 2520 provides the E-UTRAN 2500 and 2510 with theMCCH-related information.

[0338] The OAM 2520 may send the MBMS session attributes receivedfrom the MME 2530 to the E-UTRAN. In this case, the MME 2530 maynot send the MBMS Session Start request to the MCE through the M3interface.

[0339] 4. The E-UTRAN may set up RAN resources according to theinformation received from the OAM 2520.

[0340] FIG. 26 is a diagram illustrating a staticcoordination-based MBMS session start procedure according toembodiment 5 of the present invention. In particular, FIG. 26relates to an MBMS session start procedure in a case where multipleMCEs are managing an MBSFN area and the MCCH-related information isgenerated based on preconfigured static information.

[0341] 1. Multiple MCEs are configured to manage one MBSFN areaand, if receiving the same session attributes, generate the sameMCCH-related information.

[0342] 2. The MME 2630 and MBMS GW perform an MBMS Session Startprocedure.

[0343] 3. The MME 2630 sends an MBMS Session Start Request messageto the MCEs. The MCEs generate the same MCCH-related informationbased on a value preconfigured at step 1.

[0344] MBMS Session Start procedure in case an MBSFN area ismanaged by multiple MCEs. Step 5 is followed by subsequent steps asfollows (after MBMS Session Start procedure)

[0345] 6. The MCE maps the SAI list included in the receivedmessage to a list of MBSFNs and removes unused MBSFNs from thecorresponding ECGI list. The MCE allocates resources to theassigned or selected MBSFNs for the MBMS bearer. The MCE stores theCell ID list (list of ECGIs) of the MBSFNs for which the MBMSbearer has been activated.

[0346] 7. The MCE sends a Session Start Response message to theMME. This message may include 3GPP Release-12 MBMS-relatedparameters and the Cell ID list (List of ECGIs) of the cells forwhich the MBMS bearer has been activated by the Session startrequest.

[0347] 8. The MME sends the Session Start response message to theMBMS-GW. This message may include 3GPP Release-12 MBMS-relatedparameters and the Cell ID list (List of ECGIs) of the cells forwhich the MBMS bearer has been activated by the Session startrequest.

[0348] 9. The MBMS-GW sends the Session Start Response message tothe BM-SC. This message may include 3GPP Release-12 MBMS-relatedparameters and the Cell ID list (List of ECGIs) of the cells forwhich the MBMS bearer has been activated by the Session startrequest.

[0349] 10. The BM-SC sends an Activate MBMS Bearer Response messageto the GCS-AS. This message includes TMGI, Flow ID (if included inthe Activate MBMS bearer Request message, the same value isincluded; or it is the Flow ID allocated by the BM-SC), MBMSservice description, IP address and port number of the BM-SC foruser data transmission plane, and expiration time. The MBMS servicedescription includes MBMS bearer-related configuration informationincluding at least of information as follows that is specified inTS26.346: MBMS service Area, radiofrequency, IP multicast address,APN, etc. If the BM-SC has allocated a TMGI, the expiration timeindicates the expiration time of the corresponding TMGI. The BM-SCmay include the service Area in the service description only in apredetermined case.

[0350] Up to Rel-12, it is not necessary to include the servicearea. This is because the BM-SC uses the MBMS ASI(s) provided bythe GCS AS (as it is). The GCS-AS may include the MBMS ASI(s)included in the message transmitted at step 1 in the servicedescription to be transmitted to the UE.

[0351] In Rel-13, it becomes necessary to include the service Area.This is because the BM-SC may derive new MBMS SAI(s) from the cellID(s) received from the GCS AS (using the information configured tothe BM-SC together). This MBMS SAI(s) may differ from the MBMSSAI(s) received from the GCS AS (furthermore, the GCS AS maytransmit no MBMS SAI(s)). The GCS AS needs to know about the MBMSSAI(s) transmitted from the BM-SC to an MBMS downstream node. Thus,the BM-SC may send the MBMS SAI(s) delivered to the MBMS downstreamnode to the GCS AS, and the GCS SA sends the MBMS SAI(s) receivedfrom the BM-SC as part of the MBMS SAI(s) of the servicedescription destined for the UE.

[0352] If the BM-SC has mapped the Cell ID list to the MBMS ServiceArea identity at step 2, the service description must include thelist of the MBMS Service Area identity list that has been includedin the MBMS Session Start message by the BM-SC. Alternatively, ifthe BM-SC has mapped the Cell ID list to the MBMS Service Areaidentity at step 2, the Service description must include the listof the MBMS Service Area Identity list mapped to the Cell ID list.Alternatively, if the BM-SC has received (but not mapped) the cellID list at step 2, the service description must include the MBMSService Area Identity list that has been included in the MBMSSession Start message by the BM-SC. Alternatively, if the BM-SC hasreceived (but not mapped) the cell ID list at step 2, the Servicedescription must include the MBMS Service Area Identity list mappedto the Cell ID list.

[0353] If the BM-SC sends the Activate MBMS Bearer Response messagebefore the message of step 9 and if the list of ECGIs included inthe message of step 9 differs from the list of ECGSs included inthe message of step 1, the BM-SC may update the list of the ECGIsby sending a message including the list of ECGIs received at step 9to the GCS-AS in order to notify the list of the ECGIs for whichthe MBMS bearer has been activated.

[0354] The eNB and the MME may exchange the information on the MCEserved by the eNB using the following procedure and messages.

[0355] In embodiment 5, the S1 Setup and eNB Configuration Updateprocedures are performed as shown in FIGS. 27 and 28.

[0356] FIG. 27 is a diagram illustrating an S1 setup requestprocedure between an eNB and an MME according to embodiment 5 ofthe present invention.

[0357] In reference to FIG. 27, the eNB 2700 may send an S1 SETUPREQUEST to the MME 2710 and receive an SI SETUP RESPONSE from theMME 2710 in response to the SI SETUP REQUEST.

[0358] FIG. 28 is a diagram illustrating an eNB configurationupdate procedure between an eNB and an MME according to embodiment5 of the present invention.

[0359] In reference to FIG. 28, the eNB 2800 may send an ENBCONFIGURATION UPDATE to the MME 2810 and receive an ENBCONFIGURATION UPDATE ACKNOWLEDGEMENT from the MME 2810 in responseto the ENB CONFIGURATION UPDATE.

[0360] The S1 SETUP REQUEST message may be defined as follows.

TABLE-US-00002 IE/Group Name Presence Range IE type and referenceSemantics description Critically Assigned Critically Message Type M9.2.11 YES reject Global eNB ID M 9.2.1.37 YES reject eNB Name 0PrintableString YES ignore (SIZE(1 . . . 150, . . . )) SupportedTAs 1. (maxnoofTACs( Supported TAs in the eNB. GLOBAL reject>TAC M 9.2.3.7 Broadcasted TAC. >Broadcast PLMNs 1.(maxnoofBPLMNs) Broadcasted PLMNs. >>PLMN Identity M 9.2.3.8Default Paging DRX M 9.2.1.16 YES ignore CSG Id List 0.1 GLOBALreject >CSG Id M 1. <maxnoofCSGlds> 9.2.1.62 Serving MCE 09.2.1.xx YES ignore

TABLE-US-00003 Range bound Explanation maxnoofTACs Maximum no. ofTACs. Value is 256. maxnoofBPLMNs Maximum no. of Broadcasted PLMNs.Value is 6. maxnoofCSGIds Maximum no. of CSG Ids within the CSG IdList. Value is 256. maxnoofMCEs Maximum no. of MCEs. Value is256.

TABLE-US-00004 IE/Group Name Presence Range IE type and referenceSemantics description Critically Assigned Critically Message Type M9.2.11 YES reject eNB Name 0 PrintableString YES ignore (SIZE(1 . .. 150, . . . )) Supported TAs 0. <maxnoofTACs> Supported TAsin the eNB. GLOBAL reject >TAC M 9.2.3.7 Broadcasted TAC>Broadcast PLMNs 1. <maxnoofBPLMNs> Broadcasted PLMNs.>>PLMN Identity M 9.2.3.8 CSG Id List 0.1 GLOBAL reject>CSG Id 1. <maxnoofCSGlds> 9.2.1.62 Default Paging DRX M9.2.1.16 YES ignore Serving MCE 0 9.2.1.xx YES ignore

TABLE-US-00005 Range bound Explanation maxnoofTACs Maximum no. ofTACs. Value is 256. maxnoofBPLMNs Maximum no. of Broadcasted PLMNs.Value is 6. maxnoofCSGIds Maximum no. of CSG Ids within the CSG IdList. Value is 256.

[0361] Meanwhile, the Global MCE ID may be defined as follows. ThisID is used for M3 Setup between the MCE and MME or MCEConfiguration update.

TABLE-US-00006 IE/Group IE type and Semantics Name Presence Rangereference description PLMN M Identity MCE ID M OCTET STRING[SIZE[2]] MCE ID O OCTET STRING Extension of the Extension[SIZE[1]] Global MCE ID.

[0362] According to embodiment 5 of the present invention, theinformation on the eNB connected to the MCE may be exchangedbetween the MCE and MME using the procedures and messages as shownin FIGS. 29 and 30.

[0363] FIG. 29 is a diagram illustrating an S3 setup requestprocedure between an MCE and an MME according to embodiment 5 ofthe present invention.

[0364] In reference to FIG. 29, the MCE 2900 may send an S3 SETUPREQUEST to the MME 2910 and receive an S3 SETUP RESPONSE from theMME 2910 in response to the S3 SETUP REQUEST.

[0365] FIG. 30 is a diagram illustrating an MCE configurationupdate procedure between an MCE and an MME according to embodiment5 of the present invention.

[0366] In reference to FIG. 30, the MCE 300 may transmit an MCECONFIGURATION UPDATE to the MME 3010 and receive an MCECONFIGURATION UPDATE ACKNOWLEDGEMENT from the MME 3010 in responseto the MCE CONFIGURATION UPDATE.

[0367] The M3 Setup and MCE Configuration Update procedure areperformed as follows.

TABLE-US-00007 IE/Group Name Presence Range IE type and referenceSemantics description Critically Assigned Critically Message Type M9.2.11 YES reject Global eNB ID M 9.2.1.37 YES reject eNB Name 0PrintableString YES ignore (SIZE(1 . . . 150, . . . )) MBMS ServiceArea List 1 YES reject >MBMS Service Area List 1 to SupportedMBMS GLOBAL reject Item >maxnoofMBMS Service Area IdentitiesServiceAreaIdentities in the MCE PerMCE> >>MBMS ServiceArea 1 M OCTET MBMS Service Area STRING(2) Identities as defined inTS 23.003 [13]. eNB list cell list 1 to n > Global eNB IDECGI

TABLE-US-00008 Range bound Explanation maxnoofMBMSService Maximumno. of Service Area Identities AreaIdentitiesPerMCE per MCE. Thevalue for maxnoofMBMSServiceAreaIdentities is 65536.

Embodiment 6

[0368] Embodiment 6 proposes a method for allocating a highpriority to the UE using a public safety (Public-Safety LTE)service such that an MCPTT UE is allocated resources preferentiallyin the EPS and establishes a connection preferentially for datatransmission.

[0369] The public safety (Public Safety LTE: PS-LTE) provides auser with a public safety communication service using a missioncritical push to talk over LTE (MCPTT) technology. The MCPTT is oneof the technologies developed by 3GPP and provides functions of D2Dgroup communication, person-to-person communication, emergencycall, disaster alert, and ambient listening. In the presentinvention, the MCPTT is an example of public safety services andmay mean all public safety-related services.

[0370] The MCPTT system includes a UE, an evolved packet system(EPS), a session initiation protocol (SIP) Core, and an MCPTTApplication Server. The EPS may mean an LTE network, the SIP Coremay mean a network composed of core network entities using the SIPsuch as Internet multimedia subsystem (IMS). The MCPTT system maybe deployed in various topologies. The MCPTT operator may managethe SIP Core and MCPTT Application Server and interwork withanother operator's EPS to provide the service. It may also bepossible for the MCPTT operator to manage only the MCPTTApplication Server and interwork with another operator's EPS andSIP Core to provide the service.

[0371] The MCPTT service may include a group call, aperson-to-person call, and an emergency alert. The group callsupports a normal call for public security, an emergency call withthe highest priority for the case of an urgent/emergency situation,and an imminent peril call for the urgent/emergency situation withthe priority lower than that of the emergency call. Theperson-to-person call supports the normal call, Emergency Call, andthe ambient listening function for listening to the ambient soundaround the counterpart. The emergency alert is a function capableof alerting the urgent/emergency situation to the MCPTT system orother MCPTT users.

[0372] The emergency call provided by the MCPTT supports the groupcall unlike the legacy emergency call; thus, the UE has to have thecapability of receiving as well as transmitting an emergency call.The emergency call, imminent peril call, and emergency alert may behandled with priorities higher than that of the normal call in theEPS, SIP Core, and MCPTT Application Server. Thus, there arerequirements of faster connection establishment and data exchangefor such high priority calls in comparison with the othercalls.

[0373] The present invention proposes a method for assigning a highpriority to the UE using the public-safety network (MCPTT) in orderfor the MCPTT UE to be allocated resources and establish aconnection preferentially for data transmission in the EPS. Thecurrent EPS-based emergency call service is designed inconsideration of only the mobile originated situation withoutcontrol over the emergency MCPTT service. However, the MCPTTservice may have a high priority for dedicated-MCPTT UE networkservice in comparison with the normal service, and this requirementshould be applied to the EPS. Also, since the MCPTT supportstransmitting/receiving a group call or person-to-person call, theservice can be supported in a mobile terminated situation where theMCPTT UE has to reply to an MCPTT call as well as in the mobileoriginated situation. The present invention proposes a method forallocating a high priority to an MCPTT UE connected to the MCPTTsystem and, as a consequence, radio resources and notifying theMCPTT system that the UE attempting to access the system is anMCPTT UE.

[0374] Throughout the specification, the term MCPTT denotes one ofthe PS-LTE services including the services called by differentnames but supporting the D2D group call, person-to-person call, andurgency/emergency call. In the present invention, the MCPTT may becalled Public Safety service. The embodiments of the presentinvention may be applied to various radio communication systemssuch as WLAN and Bluetooth, as well as the communication systemdescribed herein, in a similar manner. In the present invention,the priority of the MCPTT service may be the priority allocated toone of the MCPTT services, e.g. emergency call service having thehighest priority and imminent peril call service having the nexthighest priority. The present invention is directed to a method forallocating a priority to an MCPTT UE and notifying the EPS networkthat the UE is an MCPTT UE in a mobile originated scenario in whichthe MCPTT UE preferentially initiates a connection to the EPSnetwork and a mobile terminated scenario in which the MCPTT UEreceives a paging from the EPS network for preferentiallytriggering a connection. In the present invention, the MCPTTservice is categorized into an MCPTT Normal Call as a basic MCPTTcall, an Emergency Call with the highest priority, an ImminentPeril Call with the next highest priority, and an Ambient Listeningfor allowing listening to ambient sounds and an Emergency Alertwith respective priorities.

[0375] Throughout the specification, the term EPS is the acronym ofEvolved Packet System and interchangeably referred to as LTEnetwork. The EPS is composed of an E-UTRAN including UEs and eNBand Evolved Packet Core (EPC) as a core network of the LTE system.The EPC is composed of MME, S-GW, P-GW, and PCRF. Throughout thespecification, the EPS connects to the SIP Core for access to theMCPTT service, and the SIP Core may denote a network of the corenetwork entities using the SIP or an IMS. Accordingly, an IMSentity such as P-CSCF specified in the specification denotes an SIPCore entity for MCPTT. Throughout the specification, the MCPTTApplication Server denotes a network entity for exchangingapplication layer information and may be any of variouslogical/physical entities required for implementing the MCPTTservice without being limited to the term "Application Server".

[0376] FIG. 31 is a diagram illustrating a method and procedure foran MCPTT UE to transmit an MCPTT Service Request to an MME and forthe MME to update and configure a Bearer Context according toembodiment 6 of the present invention.

[0377] FIG. 31 shows an embodiment of the present invention inwhich the MCPTT UE 3100 sends the MME 3120 an Extended ServiceRequest for establishing an MCPTT connection to the EPS networksuch that a bearer with the priority for the MCPTT is establishedto use radio resources.

[0378] FIG. 31 is a diagram illustrating a method and procedure foran MCPTT UE 3100 to transmit an MCPTT Service Request to the MME3120 to configure a bearer with a QoS suitable for MCPTT. The MCPTTUE 3100 may be categorized into one of a UE using the MCPTTservice, if necessary, while using the normal LTE service and anMCPTT service-dedicated UE.

[0379] In the present invention, the UE that is capable of usingthe normal service and MCPTT service is referred to asMCPTT-enabled UE, the UE that is capable of receiving only theMCPTT service as a dedicated MCPTT UE, and both the types of UEsare referred to as an MCPTT UE in a collective meaning, forconvenience of purpose.

[0380] 1. The MCPTT UE 3100 has to activate a bearer of the EPSnetwork for use of the MCPTT service and thus sends the MME 3120 anExtended Service Request message for triggering the EPS bearerestablishment. The Extended Service Request message includes aService Type Field that the MCPTT UE may set to a value indicatingthe MCPTT service type. The MCPTT-enabled UE that is receiving thenormal service may make an MCPTT service request upon detection ofa public safety situation or request for public safetycommunication. At this time, the Service Type Field is set to avalue indicating MCPTT service. The dedicated-MCPTT UE may also setthe Service Type Field to a value indicating MCPTT service.

[0381] The Service Type Field may be set to a value indicatingMCPTT service collectively or one of MCPTT services categorizedaccording to the MCPTT emergency situation. The field may also beset to a value indicating a detailed MCPTT service such as MCPTTGroup Call, MCPTT Emergency Call, MCPTT Imminent Peril Call, MCPTTEmergency Alert, Ambient Listening, and Private Call.

[0382] The MCPTT Emergency Call may be subcategorized into MCPTTEmergency Group Call for group communication and MCPTT EmergencyPrivate Call for peer-to-peer communication. The MCPTT UE may setthe Device Property field of the Extended Service Request to avalue for explicitly indicating that the UE is an MCPTT UE.

[0383] The dedicated-MCPTT UE may set the Device Property field ofthe Extended Service Request to a value for explicitly indicatingthat the UE is a dedicated MCPTT UE. In this case, the MME mayassume that the corresponding UE has the MCPTT service capabilitybased on only the Device Property field without the Service Typefield.

[0384] The Device Property field may indicate the MCPTT servicecapability and may be set to a value indicative of the MCPTT UEcollectively or a UE using one of sub-categorized MCPTT Emergencycall services. In more detail, the Device Property field may be setto a value indicative of one of the MCPTT services such as MCPTTEmergency Call, MCPTT Imminent Peril Call, MCPTT Ambient Listening,and MCPTT Private call. In the case that the Service Type or DeviceProperty field is set to a value indicative of an MCPTT Emergencyservice, the detailed MCPTT Emergency service may vary depending onthe EPS network operator or MCPTT service provider.

[0385] In order to make a resource request to the EPS network, theMCPTT UE 3100 may use the Extended Service Request message for theMCPTT Emergency service or a Service Request message for normalMCPTT service. If the Extended Service Request message is received,the MME checks at least one of the Service Type and Device Propertyfields of the Extended Service Request message to determine theMCPTT service to provide. The MME may check whether the UE thatwants to receive the MCPTT service is an MCPTT-enabled UE that isreceiving the normal service or a dedicated-MCPTT UE, and the MMEmay accept the request from the UE based on the UE context storedin its storage.

[0386] 2. The MME 3120 may also check whether the service requestedby the UE is the general MCPTT service or one of the MCPTTservices, i.e. Emergency Call, Imminent Peril Call, AmbientListening, Private Call, and Emergency Alert. The MME may alsodetermine that the MCPTT Emergency service is requested and applyspecific QoS corresponding to the MCPTT Emergency service.

[0387] 3. After checking the MCPTT service that the MCPTT UE 3100wants to use or can use, the MME may inquire to the HSS 3140 aboutQoS information to be provided to the UE for use of a specificMCPTT service. The QoS information may include a QCI value for QoSpriority identification and an ARP value indicative of the priorityfor preoccupying resources. The MME 3120 stores the acquiredinformation as an internal configuration value or MME EmergencyConfiguration Data for use in the subsequent part of theprocedure.

[0388] The procedure between the MME 3120 and HSS 3140 may beomitted and, in this case, the QoS value is determined according tothe internal configuration value stored in the MME 3120. Theinternal configuration value stored in the MME 3120 may be thevalue stored as a part of the MME Emergency Configuration Data.

[0389] 4. The MME 3120 determines the QoS upon receipt of theExtended Service Request message transmitted by the MCPTT UE 3100and updates the default bearer context of the UE to obtain the QoSvalue suitable for the MCPTT.

[0390] For example, if it is determined to provide the MCPTTEmergency service to the MCPTT UE that has transmitted the ExtendedService Request, the MME 3120 updates the Default Bearer Contextwith the corresponding QCI or ARP value. The MME 3120 stores theinformation indicating internally that the bearer configured in theabove procedure is the bearer for public safety.

[0391] 5. The MME 3120 updates the default bearer context of theMCPTT UE 3100 to match the MCPTT service, emergency service, ordetailed MCPTT service and then sends an Initial Context SetupRequest message to the eNB 3110 to request to establish a bearerwith the UE according to the updated bearer context.

[0392] 6. Upon receipt of the Initial Context Setup Request messagefrom the MME 3120, the eNB 2110 prepares for establishing a beareraccording to the bearer context, i.e. QoS information, contained inthe Initial Context Setup Request message and sends the UE 3100 anRRC Connection Reconfiguration message to establish a bearerbetween the UE 3100 and eNB 3110.

[0393] 7. After the bearer is established with the UE 3100, the eNB3110 sends the MME 3120 an Initial Context Setup Response messageto notify that the bearer ID of the bearer has been establishedbased on the QoS configured by the MME 3120 in response to theInitial Context Setup Request message. In the above procedure, theeNB 3110 may store the information indicating that the bearer forpublic safety is allocated to the UE 3100 and perform radioresource allocation and data transfer by allocating a high priorityto the bearer for the public safety in comparison with the priorityallocated to other normal services based on the storedinformation.

[0394] 8. After receiving the Initial Context Setup Responsemessage, the MME 3120 sends the S-GW/P-GW 3130 a Modify BearerRequest message for connection between the eNB 3110 and theS-GW/P-GW 3130 and, as a consequence, establishes a bearerconnection between the eNB 3110 and S-GW/P-GW 3130. The bearerconnection established between the UE 3100 and S-GW/P-GW 3130 viathe eNB 3110 is the connection having the QoS value configured bythe MME 3120 to match with the MCPTT Type during the aboveprocedure. The eNB 3110, MME 3120, or S-GW/P-GW 3130 may internallybind that the corresponding bearer is the bearer for publicsafety.

[0395] Since it may be known that the bearer has QCI and APR valuesof QoS higher than that of the default bearer in use or thecorresponding bearer is the bearer for public safety based on theinternal binding, the eNB 3110 or S-GW/P-GW 3130 may transfer datawith a priority higher than that of other bearers. After the bearerconnection has been established, the P-GW 3030 sends the PCRF thenewly established bearer and UE information to update a PCC rulefor use in charging and providing services.

[0396] In order to transmit the Extended Service Request message,the UE 3100 establishes an RRC connection with the eNB 3110. TheNAS layer of the UE 3100 configures a value of RRC EstablishmentCause and sends the value to the RRC layer of the UE 3100 duringthe RRC connection establishment between the UE 3100 and the eNB3110. The RRC Establishment Cause indicates one of MobileOriginated Signaling, Mobile Originated Data, Mobile TerminatedSignaling, and Mobile Terminated Data.

[0397] Afterward, the RRC layer of the UE 3100 generates an RRCmessage and sends the eNB 3110 a connection request.

[0398] The present invention proposes an identifier indicatingPublic Safety in the RRC Establishment Cause. This may indicate oneof Mobile Originated Public Safety Signaling, Mobile OriginatedPublic Safety Data, Mobile Terminated Public Safety Signaling, andMobile Terminated Dedicated-MCPTT UE data, or indicate PublicSafety collectively. Regardless of the name of the identifier, itincludes an RRC connection request cause value indicating a publicsafety service (including MCPTT).

[0399] In the case that the RRC establishment cause is configuredas above, the UE 3100 may avoid congestion control between the UE3100 and eNB 3110 (overriding congestion control) or Access Classbarring between the UE and eNB (Application level congestioncontrol for data communication (ACDC)).

[0400] The eNB 3110 stores the information indicating that the UE3100 transmitting the request with a cause value as public safetyUE so as to handle the UE preferentially, when handover isrequired, in comparison with other UEs.

[0401] FIG. 32 is a diagram illustrating a method and procedure foran MCPTT UE to transmit an MCPTT service Request to an MME and forthe MME to update and configure a Second bearer context accordingto embodiment 6 of the present invention.

[0402] FIG. 32 shows an embodiment of the present invention inwhich the MCPTT UE 3200 sends the MME 3220 an Extended ServiceRequest for establishing an MCPTT connection to the EPS networksuch that a bearer with the priority for the MCPTT is establishedto use radio resources.

[0403] Although the term Emergency is used to mean MCPTT servicescollectively in FIG. 32, it is obvious that the term Emergency mayindicate the MCPTT Emergency or a detailed MCPTT service. Also, itis obvious that the term Emergency may indicate the Public Safetyservice.

[0404] The MCPTT UE 3200 has to establish an EPS bearer for use ofthe MCPTT service and thus send the MME 3220 an Extended ServiceRequest message for triggering the EPS bearer establishment. TheExtended Service Request message may include a Service Type Fieldthat the MCPTT UE may set to a value indicating the MCPTT servicetype. The MCPTT UE that is receiving the normal service may make anMCPTT service request upon detection of a public safety situationor when a public safety call is required.

[0405] At this time, the Service Type Field is set to a valueindicating MCPTT service type. A dedicated-MCPTT UE may also setthe Service Type Field to indicate the MCPTT service. The ServiceType Field may be set to a value indicating MCPTT servicecollectively or one of MCPTT services categorized according to theMCPTT emergency situation. The sub-MCPTT services may include MCPTTGroup Call, MCPTT Emergency Call, MCPTT Imminent Peril Call, MCPTTEmergency Alert, Ambient Listening, and Private Call. The MCPTTEmergency Call may be subcategorized into MCPTT Emergency GroupCall for group communication and MCPTT Emergency Private Call forpeer-to-peer communication. The MCPTT UE may notify that it is anMCPTT-enabled UE explicitly by setting a Device Property field ofthe Extended Service Request message to a value indicative of theMCPTT-enabled UE. The dedicated-MCPTT UE may notify that it is adedicated-MCPTT UE explicitly by setting the Device Property fieldof the Extended Service Request message to a value indicative ofthe dedicated-MCPTT UE. In this case, the MME may recognize thatthe corresponding UE has the MCPTT service capability based on onlythe Device Property field without the Service Type field.

[0406] The Device Property field indicates the MCPTT servicecapability and may be set to a value indicative of theMCPTT-enabled UE collectively or one of categorized MCPTT Emergencycall service-enabled UEs.

[0407] In more detail, the Device Property field may be set to avalue indicative of one of the MCPTT services such as MCPTTEmergency Call, MCPTT Imminent Peril Call, MCPTT Ambient Listening,and MCPTT Private call. In the case that the Service Type or DeviceProperty field is set to a value indicative of an MCPTT Emergencyservice, the detailed MCPTT Emergency service may vary depending onthe EPS network operator or MCPTT service provider.

[0408] In order to make a resource request to the EPS network, theMCPTT UE 3200 may use the Extended Service Request message for theMCPTT Emergency service or a Service Request message for the normalMCPTT service. Upon receipt of the Extended Service Requestmessage, the MME 3220 checks at least one of the Service Type andDevice Property fields of the Extended Service Request message todetermine the MCPTT service to provide. The MME may also checkwhether the UE that wants to receive the MCPTT service is anMCPTT-enabled UE that is receiving the normal service or adedicated-MCPTT UE and accept the request from the UE based on theUE context stored in its storage.

[0409] The MME 3220 may also check whether the service requested bythe UE is the general MCPTT service or one of the MCPTT services,i.e. Emergency Call, Imminent Peril Call, Ambient Listening,Private Call, and Emergency Alert. The MME may also determine therequest for use of the MCPTT Emergency service and apply a specificQoS corresponding to the Emergency service.

[0410] This embodiment is different from the embodiment of FIG. 31in that the MME 3320 has the Secondary Default Bearer Context forMCPTT to allocate a bearer matching the QoS for MCPTT whenrequesting for the MCPTT service under the assumption that the UE3220 has the MCPTT capability.

[0411] Whether the UE 3200 supports the MCPTT service is handled inan alternative embodiment of the present invention. If the UE 3200having the MCPTT capability attaches to the network, the MME 3220may determine whether the UE is an MCPTT-enabled UE supporting boththe MCPTT service and normal service or a dedicated-MCPTT UEcapable of supporting only the MCPTT service based on the value ofthe MCPTT capability.

[0412] After performing the attach procedure of the MCPTT-enabledUE or dedicated-MCPTT UE, the MME 3220 configures a secondarydefault bearer context with the QoS value for MCPTT in preparationfor MCPTT service request.

[0413] The secondary default bearer context may be the context forgeneral MCPTT, the context for MCPTT Emergency, or the context forone of the subcategorized Emergency Call, Imminent Peril Call,Ambient Listening, Private Call, and Emergency Alert.

[0414] Although there may be multiple candidates of the secondarydefault context, a default bearer context is configured for theMCPTT service request that differs from the legacy default bearercontext; thus, the context is referred to as secondary defaultbearer context, and it is obvious that the term "secondary" doesnot mean any specific order of a context stored in the MME. Thesecondary default bearer context includes a corresponding QCI orARP value.

[0415] If the Extended Service Request message is received from theMCPTT UE 3200, the MME 3220 checks the MCPTT Type to determinewhether the UE 3200 has the capability for the service. Afterward,the MME 3220 selects the bearer context matching the MCPTT typerequested by the UE 3200 among the bearer contexts as the Secondarybearer context and initiates bearer connection establishment thatmatches with the QoS included in the context.

[0416] The MME 3220 sends the Initial Context Setup Request messageto the eNB based on the secondary default bearer context. If theInitial Context Setup Request message is received from the MME3220, the eNB 3210 prepares for establishing a bearer based on thebearer context, i.e. QoS information, contained in the InitialContext Setup Request message and sends an RRC ConnectionReconfiguration message to the MCPTT UE 3200 to establish thebearer between the UE and eNB.

[0417] After the bearer connection is established with the UE 3200,the eNB 3210 sends the MME 3220 an Initial Context Setup Responsemessage to notify the bearer ID of the bearer established based onthe QoS configured by the MME 3220 in response to the InitialContext Setup Request message.

[0418] If the Initial Context Setup Response message is received,the MME 3220 sends the S-GW/P-GW 3230 a Modify Bearer Requestmessage for connection between the eNB 3210 and S-GW/P-GW 3230 and,as a consequence, a bearer connection is established between theeNB 3210 and S-GW/P-GW 3230.

[0419] The bearer connection established between the UE 3200 andS-GW/P-GW 3230 via the eNB 3210 is a connection having the QoSvalue configured by the MME in match with the MCPTT Type during theabove procedure for transmitting data preferentially in comparisonwith data on other bearers.

[0420] The eNB 3210, MME 3220, or S-GW/P-GW 3230 may internallybind that the corresponding bearer is the bearer for public safety.Since it may be known that the bearer has QCI and APR values of QoShigher than that of the default bearer in use or the correspondingbearer is the bearer for public safety based on the internalbinding, the eNB 3210 or S-GW/P-GW 3230 may transfer data with apriority higher than that on other bearers. After the bearerconnection establishment has been completed, the P-GW 3230 sendsthe PCRF the newly established bearer and UE information to updatea PCC rule for use in charging and service provision.

[0421] FIG. 33 is a diagram illustrating a procedure for EPSentities to handle a paging for an MCPTT UE preferentially andestablish a bearer connection for providing the UE with an MCPTTservice according to embodiment 6 of the present invention.

[0422] FIG. 33 is a diagram illustrating a procedure for an MCPTTUE 3330 to receive a paging for an MCPTT service preferentially toreceive data arriving with a high priority and establish a bearerpreferentially as the result of the paging according to anembodiment of the present invention.

[0423] Although the term Emergency is used in FIG. 33, it isobvious that the term may be intended to denote the MCPTT servicein general or MCPTT Emergency or a subcategorized MCPTT service.The UE may receive the MCPTT service in the IDLE Mode. At thistime, the MCPTT service data is transmitted from the MCPTTApplication Server to the P-CSCF. The P-CSCF may determine whetherto preferentially process the signal that arrived from the MCPTTApplication Server. It may be possible to allocate a high priorityto the MCPTT services collectively or the MCPTT Emergency serviceor service-specific priorities to the detailed MCPTT services suchas Emergency Call, Imminent Peril Call, Ambient Listening, PrivateCall, and Emergency Alert.

[0424] The P-CSCF 3360 sends the P-GW 3330 the signal that arrivedfrom the MCPTT

[0425] Application Server, the signal including the informationindicating that the signal has a priority.

[0426] Alternatively, the P-CSCF 3360 may request to the PCRF 3350for allocating a high priority to the data that arrived from the IPaddress of the MCPTT Application Server 3370, and the PCRF 3350 mayrequest to the P-GW 3330 for reflecting the high priority to thedata that arrived from the IP address of the MCPTT ApplicationServer 3370 using the PCC Rule with or without updating thepolicy.

[0427] The P-GW 3330 may detect the arrival of a signal with a highpriority through the above procedure. In the case of not followingthe above procedure, when the MCPTT UE 3300 attaches, the P-GW 3330may have stored information indicating that the UE 3300 is adedicated-MCPTT UE and, if there is downlink data to transmit tothe corresponding UE, performs paging with a high priority.

[0428] The P-GW 3330 sends the MME 3320 a Downlink Notificationmessage for paging the UE. The P-GW 3330 may add an identifier tothe downlink notification message for identifying the MCPTT, MCPTTEmergency, or detailed MCPTT service.

[0429] In order to send the identifier using the downlinknotification message, it may be possible to set an Indication flagof the Downlink Notification message to a value indicating theMCPTT service, MCPTT Emergency, or detailed MCPTT service, or setthe ARP of the Downlink Notification message to a value indicatingthe MCPTT service, MCPTT Emergency, or detailed MCPTT service, orset the Paging and Service Information of the Downlink Notificationmessage to a value indicating MCPTT, MCPTT Emergency, or detailedMCPTT service.

[0430] On the basis of the received Downlink Notification message,the MME 3320 may determine that the data type of the downlink datais MCPTT, MCPTT Emergency, or detailed MCPTT service.

[0431] In the case of not following the above procedure, when theMCPTT UE 3300 attaches, the MME 3320 may have informationindicating that the UE 3300 is a dedicated-MCPTT UE and page thecorresponding UE 3300 with a high priority.

[0432] Afterward, the MME 3320 sends the eNB 3310 a paging messagehaving the information indicating that the paging message istransmitted for MCPTT, MCPTT Emergency, or detailed MCPTT serviceso as to be processed preferentially.

[0433] For this purpose, the MME 3320 may set the Paging Priorityof the paging message to a value matching the MCPTT service, MCPTTEmergency, or detailed MCPTT service. On the basis of the pagingmessage, the eNB 3310 may determine that the paging message shouldbe processed with a priority higher than that of other pagingmessages.

[0434] The MCPTT UE 3300 receives the paging and responds to theeNB 3310, and the eNB 3310 sends the MME 3320 an Initial UE messageupon receipt of the response from the MCPTT UE 3300 to request forbearer connection establishment with the MCPTT UE 3300.

[0435] On the basis of the received Initial UE message, the MME3320 may determine that the UE that has received the paging messagewith the priority is requesting for bearer connection. The MME 3320determines the context of the bearer allocated to the MCPTT UE andsets the QoS to a value matching the MCPTT service, MCPTTEmergency, or detailed MCPTT service.

[0436] After determining and authenticating the MCPTT service inwhich the MCPTT UE 3300 is interested, the MME 3320 inquires to theHSS about QoS information to be provided to the UE for use of aspecific MCPTT service.

[0437] The QoS information may include a QCI value for identifyingthe QoS priority and an ARP value indicating whether it is possibleto preoccupy the resources. The MME 3320 may store the obtainedinformation as an internal configuration value or part of the MMEEmergency Configuration Data for use in the subsequent part of theprocedure. The procedure between the MME 3320 and HSS 3340 may beomitted and, in this case, the QoS value is determined according tothe internal configuration value stored in the MME 3320.

[0438] The internal configuration value stored in the MME 3320 maybe the value stored as a part of the MME Emergency ConfigurationData. The MME 3320 determines the QoS for the bearer to beallocated to the MCPTT UE 3300 and updates the default data contextof the UE 3300 with the QoS value matching the MCPTT service.

[0439] For example, if it is determined to provide the MCPTTEmergency service to the MCPTT UE 3300 that has transmitted theExtended Service Request, the MME 3320 updates the Default BearerContext with the corresponding QCI or ARP value.

[0440] In an alternative embodiment of the present invention, theMME 3320 activates the Secondary Default Bearer Context stored forMCPTT. Afterward, the MME 3320 sends the eNB 3310 an InitialContext Setup Request message to request for bearer connectionestablishment with the UE 3300 according to the configured bearerContext.

[0441] Upon receipt of the Initial Context Setup Request messagefrom the MME 3320, the eNB 3310 prepares for establishing a beareraccording to the bearer context, i.e., QoS information, containedin the Initial Context Setup Request message and sends the UE 3300an RRC Connection Reconfiguration message to establish a bearerbetween the UE 3300 and eNB 3310.

[0442] After the bearer is established with the UE, the eNB 3310sends the MME 3320 an Initial Context Setup Response message tonotify the MME 3320 of the bearer ID of the bearer establishedbased on the QoS configured by the MME 3320 in response to theInitial Context Setup Request message. If the Initial Context SetupResponse message is received, the MME 3320 sends the S-GW/P-GW 3330a Modify Bearer Request message for connection between the eNB 3310and the S-GW/P-GW 3330 and, as a consequence, establishes a bearerconnection between the eNB 3310 and S-GW/P-GW 3330.

[0443] The bearer connection established between the UE 3300 andS-GW/P-GW 3330 via the eNB 3320 is the connection having the QoSvalue configured by the MME 3320 to match with the MCPTT Type so asto have a priority higher than that of other bearers. After thebearer connection is established, the P-GW 3330 sends the PCRF 3350the newly established bearer and UE information to update a PCCrule for use in charging and serving provision. Once the bearerconnection is established, the MCPTT UE 3300 can receive the MCPTTservice with the high priority in response to the request for theMCPTT service.

[0444] FIG. 34 is a diagram illustrating a procedure for EPSentities to handle a paging for an MCPTT UE preferentially andestablish a bearer connection for providing the UE with an MCPTTservice preferentially according to embodiment 6 of the presentinvention.

[0445] The embodiment of FIG. 34 is identical with the embodimentof FIG. 33 in that the P-GW 3430 receives MCPTT signaling from theP-CSCF 3460. Although the term Emergency is used in FIG. 34, it isobvious that the term may denote MCPTT services collectively, MCPTTEmergency, or a subcategorized MCPTT service.

[0446] This embodiment proposes a procedure in which the P-GW 3430receives a signal with a priority and requests for establishment ofa bearer connection with the priority. The bearer connection withthe priority may denote a bearer connection with a high QoS forMCPTT service, MCPTT Emergency service, or detailed MCPTTservice.

[0447] If a signal with the high priority is received from theP-CSCF 3460, the P-GW 3430 sends the MME 3420 a paging message anddetermines the QoS of the new bearer with the priority matching thehigh priority.

[0448] In the case of not following the above procedure, the P-GW3430 may have stored information indicating that the UE 3440 is adedicated-MCPTT UE and, if there is downlink data to transmit tothe corresponding UE 3400, determines to apply a QoS value of thehigh priority to the new bearer.

[0449] After determining the QoS, the P-GW 3430 sends the MME 3420an Update Bearer Request message including the QoS value having thehigh priority determined in the above procedure via the S-GW 3430.Upon receipt of the message, the MME 3420 determines the bearercontext to be allocated to the MCPTT UE 3400 based on theinformation included in the message.

[0450] In the case of not following the above procedure, the MME3420 may store the information indicating that the UE 3400 is adedicated-MCPTT UE, when the UE 3400 attaches, pages thecorresponding UE 3400 with the high priority. The MME 3420 mayupdate the default bearer context to establish a bearer connectionhaving the high priority and, in this case, the procedure mayfollow embodiment 1 of the present invention.

[0451] Alternatively, it may be possible to activate the storedsecondary default bearer context to establish a bearer connectionand, in this case, the procedure follows embodiment 2.

[0452] Alternatively, the MME 3420 may establish a dedicated bearerconnection matching the high priority. In this case, both thedefault bearer connection and dedicated bearer connection areestablished, and the MCPTT UE 3400 may receive the MCPTT serviceover the dedicated bearer.

[0453] Alternatively, the MME 3420 may establish a bearerconnection and, in this case, all of the bearer contexts aredeactivated, and a new bearer is established according to thebearer context determined newly by the MME 3420. The procedure forthe MME 3420 to negotiate with the MCPTT UE 3400 for bearerestablishment follows an alternative embodiment of the presentinvention.

[0454] FIG. 35 is a diagram illustrating a method for an MCPTT UEto notify an EPS network of its MCPTT capability in attaching tothe EPS network and a method and procedure for establishing abearer connection by notifying the EPS network of the cause ofattaching for use of the MCPTT service according to embodiment 6 ofthe present invention.

[0455] FIG. 35 is a diagram illustrating a method for an MCPTT UE3500 to notify the EPS network of its MCPTT capability in attachingto the EPS network, a method for notifying the MME 3520 of thecause of attaching for use of the MCPTT service, and a method andprocedure for establishing a bearer for the MCPTT service accordingto an embodiment of the present invention.

[0456] Although the term Emergency is used in FIG. 35, it isobvious that the term may be intended to denote public safetyservices, MCPTT service in a collective meaning, MCPTT Emergency,or a subcategorized MCPTT service. The MCPTT UE 3500 performs theAttach Procedure to connect to the EPS network. The MCPTT UE 3500may notify the MME 3520 of its MCPTT capability using an AttachRequest message as follows.

[0457] The MCPTT UE 3500 may use the Type field of the AttachRequest message to indicate MCPTT or MCPTT Emergency. The MCPTT UE3500 may also set an APN field of the Attach Request message to avalue indicating MCPTT APN to notify that it wants to access theMCPTT service.

[0458] The MCPTT UE 3500 may also set a UE network capability fieldor a Device Property field of the Attach Request message to a valueindicating MCPTT Capability.

[0459] The MCPTT UE 3500 may notify the network that it is an MCPTTUE using at least one of the above methods and notify the networkthat the MCPTT bearer connection should be established according tothe result of the Attach procedure using the Type and APN fields ofthe Attach Request message. The UE supporting both the MCPTTservice and normal service may set the UE network capability fieldto a value indicating Public Safety Capability in order to notifythe core network that it is a UE capable of using the MCPTT service(identical with the MCPTT-enabled UE in FIG. 31). If the UE networkcapability or device property field is set, this may indicate thatthe corresponding UE supports the MCPTT service. Thededicated-MCPTT UE that supports only the MCPTT service may set thedevice property field to a value indicating dedicated-MCPTT UE.

[0460] If the Attach request message configured as above isreceived, the MME configures the Secondary Bearer Context toprovide the UE with the MCPTT service as described with referenceto FIG. 32. The MCPTT UE 3500 sends the eNB 3510 an RRC ConnectionSetup Complete message including the Attach Request messageconfigured as above during the RRC Connection procedure along withan indicator (RRC Establishment Cause) indicating that the Attachrequest should be processed with the priority for the MCPTTservice. If the RRC Connection Setup Complete message including theindication and Attach Request message is received from the MCPTTUE, the eNB 3510 may process the Attach request from thecorresponding UE with a priority in comparison with that from otherUEs according to the indication and send the MME 3520 an Initial UEmessage including the Attach Request message and the indicatorindicating that the Attach request should be processedpreferentially.

[0461] Upon receipt of the Initial UE message, the MME 3520 mayprocess the request with a priority higher than that from othereNBs according to the indicator indicating that the Attach requestshould be processed with a priority. If the Attach Request messagecarried in the Initial UE message is received, the MME 3520 maydetermine the bearer context necessary for the UE 3500 according tothe value that the MCPTT UE has set in the Attach Requestmessage.

[0462] For example, if the type field of the Attach Request is setto Emergency and the APN field is set to MCPTT APN, the MME 3520may determine that the UE that has sent the Attach Request messageneeds an emergency bearer for MCPTT. Likewise, if the type field ofthe Attach Request message is set to MCPTT Emergency, the MME 3520may determine that the UE needs a bearer context for MCPTTEmergency. Although the Type field of the Attach Request message isnot set, if the UE network capability field or the Device Propertyfield is set to a value indicating the MCPTT capability of the UE,the MME may determine and store the bearer context matching theMCPTT service priority for the situation where the UE uses theMCPTT service.

[0463] After determining the bearer context through the aboveprocedure, the MME 3520 may inquire to the HSS 3540 about QoSinformation and perform an authentication procedure to determinewhether the UE 3500 supports the high QoS. The above procedure maybe omitted and, in this case, the MME 3520 may use internallystored MME Emergency Configuration data or a value stored in analternative way.

[0464] The MME 3520 sends the S-GW/P-GW 3530 a Create SessionRequest message for providing the UE 3500 with a bearer connectionand, in this case, the Indication Flag, Signaling PriorityIndication, or QoS of the Bearer Context of the Create SessionRequest message is set to a value indicating a high priority inorder for the S-GW/P-GW 3530 to process the corresponding requestwith a priority.

[0465] If the message is received, the S-GW/P-GW 3530 may check theIndication flag or Signaling Priority Indication so as to processthe request with a priority in comparison with the requests fromany other UE or MME 3520 or may check the QoS value contained inthe Bearer Context and determine, if the QoS value corresponds to aQCI or ARP with the high priority of Emergency, to process therequest preferentially.

[0466] The P-GW 3530 may accept the Create Session Request andnegotiate with the PCRF 3550 to update the PCC rule. Afterward, theP-GW 3530 sends the MME a Create Session Response message inresponse to the Create Session Request message, the Create SessionResponse message including the Secondary Default Bearer informationfor use by the MCPTT UE 3500 in receiving the MCPTT service or theDefault Bearer information for the MCPTT UE 3500 to activate thedefault bearer.

[0467] Upon receipt of the Create Session Response message, the MME3520 sends the eNB 3510 an Initial Context Setup Request messageincluding Attach Accept message and Bearer Context information, andthe eNB 3510 sends the UE an RRC Connection Reconfiguration messageincluding the Attach Accept message and establishes a bearerconnection with the UE according to the Bearer context contained inthe Initial Context Setup Request message.

[0468] If a bearer is established between the UE 3500 and the eNB3510, the eNB 3510 sends the MME 3520 an Initial Context SetupResponse message to notify the MME of the Bearer establishment, andthe MME 3520 sends the S-GW/P-GW 3530 a Modify Bearer Requestmessage to establish a bearer connection between the eNB 3510 andthe S-GW/P-GW 3530. The UE 3500 sends the MME 3520 an Attach Acceptmessage to end the Attach procedure.

[0469] (Although the public safety service priority notification ismade in the order of P-GW 3530.fwdarw.S-GW 3530.fwdarw.MME3520.fwdarw.eNB 3510 in the above description, it may not bemandatory to start from the P-GW. For example, the MME 3520 mayhave the information on the public safety capability of the UE andsend the relevant information to the eNB 3510 without anydedicated-MCPTT UE identifier transmitted from the P-GW 3530 to theMME 3520 via the S-GW 3530.)

[0470] In an embodiment of the present invention, an eNB 3510, MME3520, S-GW 3530, or P-GW 3530 may internally bind that the beareris not for public safety According to the result of the procedureof FIG. 35, the eNB 3510, MME 3520, or

[0471] S-GW/P-GW 3530 may internally bind that the corresponding UEneeds a public safety connection or that the bearer of thecorresponding UE has the QCI and ARP values for a QoS higher thanthat of the default bearer or the corresponding bearer is thebearer for the public safety UE.

[0472] Accordingly, it is possible to know that the bearerrequested by the UE is the public safety bearer based on the boundvalue. Thus, the eNB 3510 and S-GW/P-GW 3530 my process the datawith a priority higher than that of other bearers.

[0473] In order to deliver the Extended Service Request message,the UE 3500 establishes an RRC connection with the eNB 3510. TheNAS layer of the UE 3500 configures a value of RRC EstablishmentCause and sends the value to the RRC layer of the UE 3500 duringthe RRC connection establishment between the UE 3500 and the eNB3510.

[0474] The RRC Establishment Cause indicates one of MobileOriginated Signaling, Mobile Originated Data, Mobile TerminatedSignaling, and Mobile Terminated Data. Afterward, the RRC layer ofthe UE 3500 generates an RRC message and sends the eNB 3510 the RRCmessage for a connection request.

[0475] The present invention proposes an identifier indicatingPublic Safety in the RRC Establishment Cause. This may indicate oneof Mobile Originated Public Safety Signaling, Mobile OriginatedPublic Safety Data, Mobile Terminated Public Safety Signaling,and

[0476] Mobile Terminated Dedicated-MCPTT UE data, or indicatePublic Safety collectively. Regardless of the name of theidentifier, it includes an RRC connection request cause valueindicating a public safety service (including MCPTT).

[0477] In the case that the RRC establishment cause is configuredas above, the UE 3500 may avoid congestion between the UE 3500 andeNB 3510 (overriding congestion control) or Access Class barringbetween the UE 3500 and eNB 3510 (Application level congestioncontrol for data communication (ACDC)).

[0478] The eNB 3510 stores the information indicating that the UE3500 transmitting the request with a cause value is a public safetyUE so as to handle the UE preferentially, when handover isrequired, in comparison with other UEs. Also, the eNB 3510 maydetermine the UE 3500 as the UE requesting for the Public Safety(or MCPTT) service based on the received cause so as to allocate itto the Core Network dedicated to public safety (or MCPTT). In thecase of following the above function, if the public safety-relatedidentifier is received as the RRC Establishment Cause, the eNB 3510may request for connection to a public safety-dedicated MME orpublic safety-preferred MME during the MME selection procedure.

[0479] In an alternative embodiment, when the network is congested,the MME 3520 may not apply any back-off timer for the UE 3500connected to the network for the public safety service, but it maytreat the UE specially so as to allow for connection to the networkto be maintained always. In the congested network situation, the UE3500 that requests for normal service may wait for a predeterminedtime period for connection to the network because of the backofftimer. The UE 3500 that requests for the public safety service maybe identified by the MME according to the method proposed by thepresent invention and, in this case, no backoff timer is applied tothe UE even in the congested network situation.

Embodiment 7

[0480] The Internet is evolving from the human-centriccommunication network in which information is generated andconsumed by humans to the Internet of things (IoT) in whichdistributed things or components exchange and process information.The combination of the cloud server-based Big data processingtechnology and the IoT begets Internet of Everything technology. Inorder to secure the sensing technology, wired/wirelesscommunication and network infrastructure, service interfacetechnology, and security technology required for implementing theIoT, recent research has focused on sensor network, Machine toMachine (M2M), and Machine Type Communication technologies.

[0481] In the IoT environment, it is possible to provide anintelligent Internet Technology (IT) that is capable of collectingand analyzing data generated from the connected things to createnew values for human life. The IoT can be applied to various fieldssuch as smart home, smart building, smart city, smart car orconnected car, smart grid, health care, smart appliance, and smartmedical service, through convergence and integration of InformationTechnology (IT) technology with various industries.

[0482] The IoT technology is spotlighted in various fields, andcommunication operators and vendors are developing variousIoT-based applications and systems. Among the various IoTsolutions, the cellular IoT (hereinafter, referred to as CIoT),which operates in a licensed frequency band allocated to a cellularsystem, is receiving attention. This is because the cellular systemis capable of providing more reliable communication service thannon-cellular systems. The CIoT is being standardized under variousnames such as evolved Machine Type Communication (eMTC) and GlobalSystem for Mobile Communications Enhanced Data rates for GSMEvolution Radio Access network (GERAN CIoT) and, by nature of thestandardization activities, the needs of the communication operatorinfluence the standardization decision making.

[0483] The advanced communication technology that makes it possiblefor all things as well as users to communicate among each other isreferred to as Internet of things (IoT). For example, a user mayown various types of electronic devices that are connected by meansof mobile communication or short range communication technologiesand sensors to provide the user with convenient functions with theadvantage of efficient control of the devices. Such electronicdevices are referred to collectively as IoT devices. Anotherexemplary IoT service may be implemented in the meter readingservice with measurement devices that read for electricity andwater and deliver the read values through a network. Otherexemplary IoT services may be implemented in such a way ofinstalling IoT devices to monitor public places or remote areas forpublic safety such that the devices detect occurrence of a specificevent and report the progress of the event through a network. Otherexemplary IoT services may be implemented in such a way that homeelectric appliances equipped with a communication function aredeployed to report their operation status and thereby the usermakes a device trigger to command the electric appliance to performa specific operation.

[0484] An IoT device includes a mobile communication module forsupporting cellular communication or a short range communicationmodule for supporting a short range communication technology suchas Bluetooth, WLAN (Wi-Fi), ZigBee, and Near Field Communication(NFC).

[0485] An LTE UE may operate in an LTE frequency band or an ISMband.

[0486] Throughout the specification of the present invention, CIoTdenotes an IoT service using a cellular network. The cellularnetwork means a mobile communication network such as 2G networkrepresented by GERAN, 3G network represented by GPRS, and 4Gnetwork represented by LTE. The CIoT service means a cellularservice for supporting the IoT UEs and may denote a service fortransmitting small size data through the cellular network. The CIoTservice may include Machine Type Communication (MTC) services. Thecellular network is a concept including Core Networks as well asRadio Access Networks.

[0487] In the present invention, the data transmitted by a UE iscategorized into one of user plane data and control plane data. Theuser plane data is application-related traffic generated in use ofthe Internet services or IoT services, and the control plane datais the data carrying control information that is exchanged betweennetwork entities for use of the cellular network. The above termsmay be replaced by other terms distinguishing the packet carryingdata and control signal for providing the communication service inthe network.

[0488] For CIoT, the legacy network apparatuses may be modified.For example, there may be a dedicated CIoT eNB having the CIoTfunction in addition to the legacy eNB. In the present invention,for convenience the CIoT eNB is collectively referred to as CIoTRAN in the concept including both the dedicated CIoT eNB and legacyeNB having the CIoT function. The terms used in the presentinvention are not limitative of the invention, and they may bereplaced by the terms having equivalent technical meanings.Likewise, the core network as a part of the cellular network may beconfigured suitable for the CIoT service. In the present invention,a core network entity for CIoT is referred to as CIoT Core Network(CN) node, and the C-SGN used in the 3GPP is not limitative of theinvention and may be replaced by other terms having the equivalenttechnical meaning. The CIoT CN node may be an entity having thefunctions of the MME and serving gateway of the legacy LTE systemand even the function of the PDN Gateway.

[0489] The CIoT CN node may be capable of relaying the data from aUE to an Application server or the data from the Application Serverto the UE as well as performing CIoT UE context management,mobility management, and signaling session management. That is, theCIoT CN node may act as a gateway for the CIoT UE so as to routethe data from the CIoT RAN to the Application Server. In the casethat the CIoT CN node has the PDN Gateway function, it can transmitthe user plane data to the Application Server directly.

[0490] The CIoT CN node establishes a Control Plane connection withthe CIoT UE. In order for the CIoT CN node to establish the ControlPlane connection with the CIoT UE, the CIoT UE establishes aControl plan bearer (A.K.A. Signaling Radio Bearer (SRB)) with theCIoT RAN, and the CIoT RAN establishes an S1 bearer connection withthe CIoT CN node for communicating the Control plane data. As aconsequence, the CIoT UE establishes a Control plane bearerconnection with the CIoT CN node. The CIoT UE communicates with theCIoT RAN through the SRB established between the CIoT UE and CIoTRAN, and the CIoT RAN communicates with the CIoT CN node throughthe SI bearer established through the above procedure. Withoutlimitation to the terms used in the present invention, SRB denotesa bearer connection established in the radio resources for controlinformation signaling of the UE, and S1 bearer denotes theconnection for control information signaling between the CIoT RANand CIoT CN node.

[0491] Typically, the UEs, eNBs, and CN entities process thecontrol plane data and user plane data in different priorities. TheUEs, eNBs, and CN entities process the control plane data, i.e.,the data carrying control information, with a priority higher thanthe priority of the user plane data. The types of the control planedata include Attach message, Tracking Area Update message, ServiceRequest message, and EPS Session Management (ESM) message formanaging the session for the UE. The above messages are exchangedbetween the UE and the CN entity and called NAS message becausethey are processed at the NAS layer. The Control Plane datatransmitted by the UE is included in the NAS message, which istransmitted from the UE to the eNB in an RRC message. The eNBtransmits the NAS message carried in the RRC message to the CNentity (MME or CIoT CN node) through a Control planeconnection.

[0492] The CIoT UE is characterized by transmitting/receiving smalldata sporadically (infrequent small data transmission).Accordingly, there is no User Plane connection established betweenthe CIoT UE and CIoT CN node, but the Control Plane connectioncapable of transmitting User Plane data is established. Thus, it ispossible to omit the control information signaling process for userplane connection establishment and user plane encryption therebyimproving radio resource and network operation efficiency.

[0493] The RRC layers of the UE and eNB use a Signaling RadioBearer (SRB) to exchange RRC messages. The SRB includes SRB 0, SRB1, and SRB 2; the UE transmits an RRC message containing the NASmessage through the SRB 1 and SRB2. (Current NAS layer operation)The UE and the CN entity (e.g., MME) perform the procedure on theNAS layer. The network may control the UE, manage mobility, andestablish a connection through the NAS procedure. The NAS layers ofthe UE and CN entity exchange NAS messages to perform the NASprocedure. Since the NAS messages contain control information, theyare transmitted/received through the control plane.

[0494] If the UE transmits user data through the control plane forCIoT service, this may cause problems as follows.

[0495] Problems in RRC Layer

[0496] Since the NAS message is transmitted through SRB 1 and SRB 2that are used for transmitting control plane data in the RRC layer,the UE may transmit the user data contained in the NAS messagethrough the SRB that is used to transmit the control plane data.The eNB cannot distinguish among the control data transmitted bythe CIoT UE and normal UE and the user data transmitted by the CIoTUE, and it recognizes all the types of data as control data. (Sincethe data are received through the SRB) The eNB processes the datapreferentially as the control plane data. If it is difficult toreceive even the control data transmitted by some UEs because ofthe congestion at the eNB, this may cause a problem of failure inprocessing the control data transmitted by the CIoT UE or normal UEbecause of the CIoT UE's user data over the control plane. That is,it may fail to process the NAS message containing the control datatransmitted by the CIoT UE or normal UE because of the NAS messagecontaining the user data transmitted by the CIoT UE.

[0497] Problems in NAS Layer

[0498] The CIoT CN Node does not know whether the NAS messagereceived from the CIoT UE conveys control data or user data beforeit checks the data by itself. The CIoT CN node maps the controldata to GTP-C and the user data to a GTP-U to transmit that data tothe PDN gateway. Accordingly, the CIoT CN node checks the NASmessage received from the CIoT UE to determine whether the messageconveys control data or user data and then transmits the user datato the P-GW through a GTP-U tunnel. If the NAS message receivedfrom the CIoT UE conveys control data, the CIoT CN node performs aprocedure corresponding thereto or configures a control message tonegotiate with the P-GW through the GTP-C interface.

[0499] The traffic transmitted by a CIoT UE may be categorized intotwo types: 1) ACK-dependent traffic and 2) ACK-independent traffic.Since a large number of CIoT UEs connect to the network to performsmall data transmission, it is necessary to use the radio resourcesefficiently. Accordingly, in the case of 1) ACK-dependent traffic,it is necessary to maintain the RRC connection between the CIoT UEand CIoT RAN during a predetermined period and, in the case of 2)ACK-independent traffic, it is possible to transition to the RRCIDLE state after transmitting the data to save radio resources.Although the traffic transmitted by the CIoT UE is almost all smalldata, there is a use case requiring a relatively large amount ofdata such as a software update. In this case, since the NAS messageis split into several items of user data to be carried in a seriesof NAS messages, there is no need to maintain the connectionbetween the CIoT UE and CIoT RAN during the predetermined timeduration. If it is possible to identify whether the RRC connectionin use requires successive message transmission, the UE and CIoTRAN may perform an operation for maintaining the RRC connectionduring a predetermined time period. In contrast, if it is notnecessary to perform successive message transmission, the UE andCIoT RAN enter the RRC IDLE state to release the RRC connection andsave radio resources.

[0500] Embodiment 7 of the present invention proposes a method forcategorizing the CIoT traffic into multiple types and processingpredetermined traffic preferentially and a method fordifferentiating between dedicated CIoT network apparatus andCIoT-enabled normal network apparatus and controlling the dedicatedCIoT network apparatus to process more CIoT-related signals.

[0501] Embodiment 7 of the present invention is directed to UE andnetwork entity operations for supporting IoT in a cellular network.The CIoT is characterized in that a plurality of UEs may connect tothe network simultaneously and the network may transmit data to theplurality of UEs simultaneously. Accordingly, it is predicted thatthe network congestion is more significant than with the normalcellular system.

[0502] Although embodiment 7 of the present invention is directedto the 3GPP LTE system, the subject of the present invention may beapplied to all the types of radio communication systems such asWLAN and Bluetooth. The present invention proposes a method andapparatus for exchanging information on the Relay between the corenetwork and eNB for supporting the UE to Network delay function asone of ProSe functions for public safety service and a method andapparatus for the eNB to control the UE for supporting the Relayfunction.

[0503] Exemplary embodiments of the present invention are describedin detail with reference to the accompanying drawings. The samereference numbers are used throughout the drawings to refer to thesame or like parts. Detailed descriptions of well-known functionsand structures incorporated herein may be omitted to avoidobscuring the subject matter of the present invention. Further, thefollowing terms are defined in consideration of the functionalityin the present invention, and they may vary according to theintention of a user or an operator, usage, etc. Therefore, thedefinition should be made on the basis of the overall content ofthe present specification.

[0504] Although the descriptions of the embodiments of the presentinvention are directed to the radio access network (RAN), LTE, andevolved packet core (EPC) as a core network of the 3rd GenerationPartnership Project (3GPP) standard, it will be understood by thoseskilled in the art that the present invention can be applied toother communication systems having the similar technical backgroundand channel format, with a slight modification, without departingfrom the spirit and scope of the present invention. The termsintended to mean control information, user data to be transmittedto the Application Server, signaling for exchanging controlinformation between network entities, and components of theentities are just examples used for convenience of explanation. Theterms used in the following description are not limitative of theinvention and may be replaced by the terms having equivalenttechnical meanings.

[0505] For convenience of explanation, some of the terms anddefinitions given in the 3GPP LTE standard may be used. However,the present invention is not limited by the terms and definitionsand may be applied to other systems following different standards.In the following description, the terms "LTE UE" and "IoT UE" areused to denote a mobile terminal supporting radio communicationsuch as a Personal Digital Assistant (PDA), a smartphone, a mobilephone, a tablet computer, and a laptop computer; a measurementdevice for metering water, electricity, and temperature; an alertdevice for sensing and reporting a situation such as fire andearthquake; and an electric appliance equipped with a communicationfunction such as air conditioner, a refrigerator, an air cleaner, aboiler, and a cleaner. In addition to the aforementioned devices,all the types of things equipped with communication functions arereferred to as IoT UEs. Among the IoT UEs, a UE that uses acellular network is referred to as a CIoT UE. In the presentinvention, the device, function, and operation for the CIoT serviceincludes the device, function, and operation for small datatransmission in an LTE network. The IoT data may denote the datatransmitted by an IoT UE or small size data transmitted by acertain type of UE.

[0506] FIG. 36 is a diagram illustrating network architecture forsupporting CIoT services according to embodiment 7 of the presentinvention.

[0507] FIG. 36 is a diagram illustrating network architecture forCIoT. The network may include a dedicated CIoT eNB for supportingthe CIoT service and a CIoT-enabled eNB implemented by adding theCIoT function to a legacy eNB.

[0508] In the present invention, the dedicated CIoT eNB and theCIoT-enabled eNB are collectively referred to as CIoT RAN 3620 forconvenience of explanation. Likewise, the core network existing ina cellular network may be implemented as a dedicated CIoT CoreNetwork. In the present invention, a core network entity for CIoTis referred to as CIoT Core Network (CN) node, and the C-SGN usedin the 3GPP is not limitative of the invention and may be replacedby other terms having the equivalent technical meaning

[0509] The CIoT CN node 3630 may be capable of relaying the datafrom a UE to an Application Server 3640 or the data from theApplication Server 3640 to the UE as well as performing CIoT UEcontext management, mobility management, and signaling sessionmanagement. That is, the CIoT CN node 3630 may act as a gateway forthe CIoT UE 3600 so as to route the data from the CIoT RAN to theApplication Server 3640.

[0510] In this case, the CIoT CN node 3630 may establish a controlplane connection with the CIoT UE 3600 without any user planeconnection to transmit the CIoT data or small size data on thecontrol plane.

[0511] The CIoT traffic has characteristics of low data rate, smallsize, delay-tolerance, periodicity/aperiodicity (event-triggered),and response-dependency/independency. In more detail, the datatraffic related to an event-triggered report such as smoke alert,breakdown alert, power shortage alert, and temperature alert may betransmitted in uplink in the form of small size data withoutrequiring any response and may occur in an event-triggered mannerSuch traffic may occur during the public safety-related IoT serviceso as to have a priority higher than that of other data traffic. Inthe case of periodic-reporting traffic such as gas consumptionmeasurement report, water consumption measurement report, andelectricity consumption measurement report, small size data aretransmitted in uplink periodically everyminute/hour/day/month/year, and there may be a response to themeasurement report result. In the case of the data traffictriggering a specific operation such as power-on/off of the UE,small sized data are transmitted in uplink periodically andaperiodically, and there may be a response about the operationexecution result in downlink.

[0512] In this case, since the CIoT UE 3600 has to make a commandor execute a received command, if the data is not delivered in apredetermined time limit, this may cause device trigger delay anddegrade IoT service quality; therefore, it is necessary to processthis type of data preferentially in comparison with other types ofdata traffic. In the case of data traffic for software/firmwareupdate and configuration value update of the IoT UE, the data maybe relatively large in both the uplink and downlink and occurrelatively sporadically. Such data traffic may relate to a securityinformation update and configuration update of an IoT apparatusadded to the IoT proximity network.

Embodiment 7-1: Solutions in RRC Layer

[0513] FIG. 37 is a diagram illustrating control plane dataexchange between a CIoT UE and a CIoT RAN and layer-specificinternal operations according to embodiment 7-1 of the presentinvention. In FIG. 37, a part related to the proposal of embodiment701 is a procedure in which the NAS layer transfers an indicatorindicating the CIoT RRC establishment cause and call type, whenrequesting for establishment of a NAS signaling connection, and theRRC layer performs access control on the CIoT call type or selectsan SRB corresponding to the RRC establishment cause (regardless ofwhether the access control for CIoT call type has been performed ornot) to transmit the RRC message on the SRB.

[0514] In the legacy LTE operation, the NAS layer (also known as anEMM layer) sends a request for RRC connection (referred to as NASsignaling connection) to the RRC layer for transmitting an NASmessage. At this time, the NAS layer notifies the RRC layer of theRRC establishment cause and call type. The RRC establishment causeindicates the reason for the RRC connection request. The call typeindicates the type of the connection request for access control atthe RRC layer. The RRC layer determines the bearer to use, i.e.,SRB or DRB, and a logical channel to use based on the RRCestablishment cause and determines the access control to use basedon the call type. The access control is a function for controllingcongestion in the radio resources.

[0515] If it is necessary to transmit CIoT user data in the IDLEstate, the CIoT UE 3700 requests for an RRC connection to the RRClayer. Since the CIoT UE 3700 according to the present inventionuses an NAS message to transmit the CIoT user data, the NAS layerrequests to the RRC layer for an RRC connection.

[0516] The NAS layer sends the RRC layer the NAS message includingthe RRC connection establishment cause and call type through an NASprocedure. The present invention defines new RRC connectionestablishment cause and call type for CIoT and proposes an RRCoperation using newly defined RRC connection establishment causeand call type. The present invention also proposes an RRC operationfor notifying the RRC layer of a new RRC Connection Establishmentcause along with the legacy call type. The following description isdirected to a procedure for the RRC layer to check that the RRCconnection is requested for CIoT user data and to determine toperform access control according to the call type.

[0517] 1. A new RRC establishment cause indicating CIoT MobileOriginated (MO) Data or CIoT Mobile Terminated (MT) data is definedfor use when the NAS layer requests to the RRC layer for an NASsignaling connection to transmit CIoT user data. The phrase "MobileOriginated" suggests that the CIoT UE has data to transmit to thenetwork, and the phrase "Mobile Terminated" suggests that the CIoTUE 3700 has data to receive from the network. The term "CIoT data"suggests small data. The CIoT data may include, but is not limitedthereto, MO small data, MT small data, MO CIoT data, MT CIoT data,and RRC establishment cause values related to user data used forCIoT (in the present invention, the terms "MO CIoT Data" and "MTCIoT data" are used for convenience of purpose). The RRCestablishment cause may be contained in the RRC message in the formof a parameter. If the RRC establishment cause is received from theNAS layer, the RRC layer determines that the RRC connection requestis made for CIoT data. The RRC layer operation following the RRCestablishment cause determination is dealt with in another part ofthe present invention.

[0518] The NAS layer notifies the RRC layer of the call type alongwith the RRC establishment cause. (Description about the meaning oflegacy call types) The call type indicates one of Originatingsignaling (connection request for transmitting control plane data),Originating Call (connection request for transmitting user planedata), Terminating call (connection request for receiving userplane data), and emergency call (connection request for emergencyservice).

[0519] The present invention defines call types for connectionrequests for transmitting and receiving CIoT user data newly. Thatis, the call types called Originating CIoT data and terminatingCIoT data are defined. The Call type of Originating CIoT data isthe call type that suggests the connection request is fortransmitting CIoT User data.

[0520] The Terminating CIoT data is the call type that suggests theconnection request for transmitting CIoT user data. These types ofcalls may be called Originating CIoT call and Terminating CIoT callrespectively. The new call types are not limited to the above termsand may be called differently, if possible, to suggest the RRCconnection request for transmitting and receiving CIoT data orsmall data. The NAS layer notifies the RRC layer of the RRCEstablishment Cause for the above described CIoT user datatransmission and call type that suggests the CIoT connection. Ifthe NAS layer sends the RRC layer the call type, the RRC layer mayperform the access control matching the call type, and thedescription thereof is dealt with in another part of the presentinvention.

[0521] 2. The RRC establishment cause of section 1 is redefined,and the previously defined Call type is used. For example, the RRCEstablishment Causes called MO CIoT Data and MT CIoT Data are usedalong with the Call type of Originating Call and Terminating Call.On the basis of the received indicator, the RRC layer may determinethat the RRC connection request is made for CIoT data. The relatedRRC layer operation is dealt with in another part of the presentinvention. The RRC layer uses the access control according to thereceived call type as specified for the legacy system.

[0522] 3. The RRC establishment cause previously defined in section1 is used, and the Call type is redefined for CIoT. For example,the RRC Establishment Cause may be set to MO data or MT data. Thecall types defined in section 1 are used. The RRC layer performsthe access control matching the call type. Although the RRC layeruses the RRC Establishment Causes of legacy MO data and MT data,the RRC layer may determine that the RRC connection request is madefor transmitting CIoT user data based on the call type set toCIoT.

[0523] Depending on operation, the RRC layer may determine that theRRC connection request from the NAS layer is made for CIoT userdata. The CIoT user data is contained in the NAS message, and theNAS layer sends the RRC layer the NAS message associated with theindication along with the RRC establishment cause and call type.The RRC layer may determine that the NAS message contains the CIoTuser data on the basis of the proposed RRC Establishment cause andCall type. The RRC layer generates an RRC message including the NASmessage. That is, the RRC message includes the NAS message thatcontains the CIoT user data.

[0524] In the legacy operation, the RRC layer uses a SignalingRadio Bearer (SRB) for transmitting the NAS message. The SRBincludes SRB 0, SRB 1, and SRB 2. The NAS message is transmitted onSRB 1 or SRB 2. In the case of establishing the RRC connectionaccording to the EMM procedure (Attach, Tracking Area Update, andService Request) of the NAS layer, the NAS message for thecorresponding procedure is piggybacked on the RRC messagetransmitted through the SRB 1. Alternatively, the NAS message maybe transmitted through the SRB 2.

[0525] In a detailed embodiment, the NAS layer may piggyback theNAS message containing the CIoT user data caused by the EMMprocedure on an RRC control message. For example, it may bepossible to transmit the RRC control message including the ServiceRequest message (NAS) message) containing the CIoT User data. (Aninitial NAS message may be piggybacked on a legacy RRC message. Thepresent invention is directed to the case of processing the initialNAS message containing the CIoT user data). In this case, the NASlayer may notify the RRC layer that the corresponding servicerequest message contains the CIoT User Data using the RRCestablishment cause or Call type. Upon determination of this, theRRC layer determines to transmit the NAS message piggybacked on theRRC message through SRB 2 rather than SRB 1 because the NAS messagecontains CIoT user data. The SRB 2 has a priority lower than thatof the SRB 1. Accordingly, the legacy control data transmittedthrough the SRB 1 may have a priority higher that the user datatransmitted by the CIoT UE. In the case of not following theproposal of the present invention, the user data transmitted by theCIoT UE is contained in an NAS message and piggybacked on an RRCcontrol message so as to be transmitted through the SRB 1. Thismeans that the control data transmitted by other UEs and the CIoTuser data are handled as signals having the same priority; thus,the present invention is proposed to distinguish between the twodifferent types of signals.

[0526] In an alternative example, it may be possible to determineto transmit a NAS message piggybacked on an RRC message through theSRB 2.

[0527] In an alternative example, the RRC layer may transmit theRRC message including the RRC message containing the CIoT user datathrough the SRB 2 along with the RRC establishment cause or calltype to distinguish the NAS message from other NAS messagescontaining control data. That is, it may be possible to determinethat the NAS message containing the CIoT User Data has a prioritylower than that of other NAS messages based on the indication andtransmit the CIoT user data through the SRP 2 with thecorresponding priority.

[0528] In another alternative example, the RRC layer may transmitthe NAS message containing the CIoT user data through an SRB 3 thatis defined to have the lowest priority. The SRB 3 may be an SRBdefined newly to have the lowest priority and may denote a radiobearer for transmitting CIoT data or small size data.

[0529] In another alternative example, the RRC layer may not applyAS security to the RRC message carrying the NAS message related tothe RRC establishment cause or call type. The legacy operation isperformed in such a way of activating Access Stratum (AS) securitybetween the UE and eNB and then always applying the AS security tothe SRB 1 and SRB 2. If the AS security is applied, this means thatintegrity protection and encryption are applied to the RRC message.Since the CIoT UE, according to the present invention, transmitsthe CIoT user data in an NAS message to which NAS security isapplied, it may be possible to skip applying AS security; thus, theRRC layer checks this to determine that the AS security has alreadybeen activated and that AS security need not be applied, eventhough the NAS message is transmitted through the SRB 1 or SRB2.

[0530] In another embodiment of the present invention, the RRClayer may apply the Access Control to the RRC connection requestfor CIoT user data transmission. In the original operation, the RRClayer of the UE receives the information on the Access controlbased on the SIB information broadcast by the eNB. The AccessControl information may be contained in ac-BarringInfo field of theSIB, which is set to ac-BarringForMO-Data orac-BarringFor-MO-Signalling. This information is formatted asac-BarringConfig and defined as follows (TS 36.331):

[0531] ac-BarringFactor

[0532] If the random number drawn by the UE is lower than thisvalue, access is allowed. Otherwise the access is barred. Thevalues are interpreted in the range [0,1): p00=0, p05=0.05,p10=0.10, . . . , p95=0.95. Values other than p00 can only be setif all bits of the corresponding ac-BarringForSpecialAC are set to0.

[0533] According to the present invention, since the CIoT user datais carried in a NAS message, the legacy RRC layer may recognizethis as MO signaling and thus apply the ac-BarringForMO-signaling.Typically, because the barring factor for signaling is configuredto access with a probability higher than that of the barring factorfor data, the barring factor for signaling may be applied to eventhe case of transmitting the CIoT user data. The present inventionproposes the following operation to overcome the above problem. TheRRC layer checks the call type in the RRC connection requesttransmitted by the NAS layer. If the call type indicates CIoT datatransmission, the barring factor for ac-BarringForMO-data isapplied, even though the NAS message is transmitted through thecorresponding RRC connection. If the RRC establishment causeindicates CIoT user data, but nevertheless the call type indicatesMO signaling, the RRC layer may apply Ac-BarringForMO-data to thecorresponding request. The SIB broadcast by the eNB may includeac-barring information for CIoT. For example, the ac-barringinformation may be set to ac-BarringForCIoT orac-BarringForCIoT-data/ac-B arringForCIoT-signaling. It may bepossible to apply a single barring factor to all CIoT-relatedtransmissions or to apply different barring factors to the CIoTdata and CIoT signaling. If an SIB is received, the UE may performAccess Control for CIoT depending on the ac-barring information forCIoT that is included in the SIB.

[0534] FIG. 38 is a diagram illustrating a procedure fortransmitting an RRC connection request message between a CIoT UEand a CIoT RAN according to embodiment 7-1 of the presentinvention.

[0535] If the CIoT UE 3800 is in the RRC IDLE state at step 3801,the CIoT RAN 3810 performs SIB broadcast to the CIoT UE 3800 alongwith access barring information for CIoT at step 3802.

[0536] If the CIoT UE 3800 accepts the access barring informationfor CIoT at step 3803, it may determine at step 3804 whether an RRCconnection request for CIoT is made.

[0537] If it is determined that the RRC connection request for CIoTis made, the CIoT UE 3800 performs an access barring check at step3805. The CIoT UE 3800 determines at step 3806 whether its accessis barred and, if so, performs RRC Connection Establishment at step3807. Next, the CIoT UE 3800 sends the CIoT RAN 3810 an RRCConnection Request at step 3808.

Embodiment 7-2: Solutions in NAS Layer

[0538] The CIoT CN node has to be capable of transmitting the CIoTuser data received on the control plane to the P-GW through a userplane interface called GTP-U. Although the NAS message istransmitted on the control plane, the CIoT user data is carried inthe NAS message according to the present invention; thus, it isnecessary to distinguish the NAS message containing CIoT user datafrom the other NAS messages to transmit it to the P-GW through theGTP-U. The present invention proposes a method for distinguishingbetween these NAS messages.

[0539] FIG. 39 is a diagram illustrating an exemplary NAS messageaccording to embodiment 7-2 of the present invention.

[0540] 1. An NAS PDU for CIoT or small data transmission isconfigured such that the header of the NAS PDU 3920 includesindication 3900. This indication 3900 indicates whether thecorresponding NAS PDU 3920 contains Control Data or User Data. Thisindication may be configured to indicate one of control data anduser data or to indicate small data transmission. That is, theindication 3900 is not limited to any form or name, but it isconfigured as an identifier for use by the CIoT CN node todistinguish between the control data and user data.

[0541] The header of the proposed NAS PDU 3920 may include the NASsecurity indication 3910 as shown in FIG. 39. Since the NAS PDU3902 is integrity-protected with NAS security material andencrypted, a key index value for indicating the key used for theintegrity protection/encryption may be included. It may be possibleto provide information of the algorithm (EIA: Integrity Algorithm;EEA: Encryption Algorithm) used along with the key index.

[0542] 2. The CIoT RAN uses the indication indicating that theInitial UE message transmitted to the CIoT CN node contains CIoTuser data. The CIoT RAN also uses the indication indicating thatthe Uplink NAS Transport message transmitted to the CIoT CN nodecontains CIoT user data. These messages are exchanged through aninterface between the CIoT RAN and CIoT CN node. The CIoT RAN usesthe Initial UE message or Uplink NAS Transport message to transmitthe NAS message from the UE to the CIoT CN node.

[0543] In the case of using the Initial UE message, the RRCEstablishment Cause included in the Initial UE message is set to avalue indicating that the CIoT user data is contained. On the basisof this message, the CIoT CN node may determine that the NASmessage conveys the CIoT user data.

[0544] In the case of using the Uplink NAS Transport message, anewly defined message type is used to indicate the CIoT user data.The messages exchanged through the interface between the CIoT RANand CIoT CN node has a field called Message type, and aninformation element of this field that is called Type of Message isset to a value indicating a newly defined type of message fortransmitting the CIoT user data.

[0545] 3. The message being exchanged between the CIoT RAN and CIoTCN node has a field called Message type, and an information elementof this field that is called Type of Message is set to a valueindicating a newly defined type of message containing the CIoT userdata transmitted through the interface between the CIoT RAN andCIoT CN node.

[0546] If it is determined that the NAS message transmitted by theCIoT UE contains control data as a result of the operations ofsections 1, 2, and 3, the CIoT CN node sends the NAS message to theP-GW through the GTP-C and, otherwise, if it is determined that theNAS message contains user data, the CIoT CN node sends the NASmessage to the P-GW via the S-GW (legacy MME is implemented tooperate in this way).

[0547] In an alternative embodiment of the present invention, thetraffic transmitted by a CIoT UE is categorized into two types. Thefirst type of traffic requires ACK corresponding to the datatransmitted by the UE, and the second type of traffic does notrequire any ACK corresponding to the data transmitted by theUE.

[0548] 1. In the case that the CIoT UE transmits data that requiresACK, the CIoT UE and CIoT RAN maintain the RRC connection during apredetermined period for receiving the ACK. If the RRC connectionis broken before receiving the ACK, RRC signaling occurs toreestablish the RRC connection; thus, in order to avoid anyunnecessary process, it is preferable to maintain the RRCconnection established with the CIoT UE that has transmitted thedata requiring ACK during a predetermined time period.

[0549] 2. In the case that the CIoT UE transmits data that requiresno ACK, the CIoT UE and the CIoT RAN can release the RRC connectionimmediately. Since infrequent small data transmission is assumed,it is preferable for the CIoT UE to release the RRC connectionimmediately after transmitting the data requiring an ACK to saveradio resources.

[0550] As solutions for the above two cases, methods are proposedas follows.

[0551] First, the data type is identified based on the RRCestablishment cause. That is, the RRC establishment cause may beset to a value indicating CIoT Data with ACK or CIoT Data withoutACK to provide information on whether the corresponding RRCconnection request is made for the data requiring ACK or the datarequiring no ACK. However, the data is not limited to the term"CIoT" and may be called as any other name such as small datatransmission with/without ACK and may also include the meaning forthe RRC connection request for small data transmission.

[0552] Second, the data type is identified based on the RRC mode.That is, the CIoT UE requests to the CIoT RAN for an RRC connectionwith a distinguished RRC mode. There may be two modes: one is amode for maintaining the connection during a predetermined period,the other is a mode for transitioning to the IDLE stateimmediately. The two modes may be called by different names. Forexample, the mode for maintaining the connection during apredetermined period may be called a default mode or normal mode,or the mode for releasing the RRC connection (transitioning to theRRC IDLE state) immediately may be called as a default mode ornormal mode. The modes proposed in the present invention includeall of the modes for maintaining the connection during apredetermined period and the mode for transitioning to the IDLEstate immediately.

[0553] Third, an indication may be added to the NAS PDU. This aimsto allow the CIoT CN Node to know the RRC connectionmaintenance/release operation.

[0554] FIG. 40 is a diagram illustrating another exemplary NASmessage according to embodiment 7-2 of the present invention.

[0555] In reference to FIG. 40, the indication (Control Data/UserData) 4000 and the NAS Security indication 4010 follow anotherexample of the present invention. In this example, an acknowledgeindication 4030 is added to the NAS PDU 4020 such that the CIoT CNnode may determine whether it is necessary to transmit ACK to theCIoT UE depending on the acknowledgement indication.

[0556] If it is necessary to transmit ACK, a signal may betransmitted to the CIoT RAN to maintain the RRC connection. If itis not necessary to transmit ACK, a signal may be transmitted tothe CIoT RAN to release the RRC connection. The signal may includean identifier for identifying the CIoT UE, e.g., IMSI.

[0557] Although the CIoT UE basically operates to transmit smalldata infrequently, it may occur that the small data is transmittedsuccessively to report software update or continuous datareporting. It may occur that a large amount of data for softwareupdate is transmitted or received through several NAS messages orseveral different items of CIoT User Data are transmitted orreceived through different NAS messages. The CIoT RAN or CIoT CNnode may detect the presence of the continuous uplink or downlinktraffic and control to maintain the radio resources during apredetermined period or release the radio resources for savingavailable radio resources.

[0558] The first solution is to use an RRC mode indication. The RRCmode indication may be set to connection maintenance or connectionrelease. This method is identical with those proposed in otherembodiments of the present invention. In the case of being usedafter entering the mode for maintaining the RRC connection,however, the UE may request to the CIoT RAN for a RRC releaserequest using an RRC message (currently, the eNB operates so as tocommand the UE to release the connection). The CIoT RAN may releasethe RRC connection.

[0559] In the case of using the normal RRC connection method, i.e.,if the eNB determines whether to maintain the RRC connection usingan RRC inactivity timer, the CIoT UE may send the CIoT RAN an RRCconnection release request (currently, the eNB operates so as tocommand the UE to release the connection). The RRC Connectionrelease request message from the CIoT UE includes a cause valueindicating the cause of release, and the cause value may indicatecompletion of all transmissions. If this message is received, theCIoT RAN may send the UE an RRC Connection Release message torelease the RRC connection.

[0560] FIGS. 41 and 42 are diagrams illustrating other exemplaryNAS messages having a header to which an indication is added tonotify the CIoT CN node that continuous data transmission isperformed. The message may be configured as follows.

[0561] The method of FIG. 41 segments large data and then providesinformation of the segmentation offset of the current NAS PDU incomparison with the total segmentation length 4110. For example, ifthe data is a large size data segmented into 100 segments,information is provided that the 58.sup.th segment is the segmentoffset of 58.

[0562] The method of FIG. 42 is to use an indication 4210indicating whether the current NAS PDU is the last one of thesuccessively transmitted NAS PDUs. For example, if the indication4210 is set to true, i.e., if the current NAS PDU is the last NASPDU, the CIoT CN node assumes no more PDU transmission and commandsthe CIoT RAN to release the RRC connection or the user planeconnection for the CIoT UE (e.g., GTP UE connection with the P-GWand tunneling connection with the Application server) to saveavailable resources. If the indication is set to false, i.e., ifthe current NAS PDU is not the last NAS PDU, the CIoT CN nodeassumes further PDU transmission and commands the CIoT RAN tomaintain the RRC connection or user plane connection for the CIoTUE (e.g., GTP UE connection with the P-GW and tunneling connectionwith the Application server).

[0563] The NAS security indication of the first and second examplesis identical with that described in another part of the presentinvention.

* * * * *