[go: up one dir, main page]

WO2017052342A1 - 리모트 프로세(remote prose) 단말에 대한 네트워크 망에서의 합법적 감청 지원 방안 - Google Patents

리모트 프로세(remote prose) 단말에 대한 네트워크 망에서의 합법적 감청 지원 방안 Download PDF

Info

Publication number
WO2017052342A1
WO2017052342A1 PCT/KR2016/010783 KR2016010783W WO2017052342A1 WO 2017052342 A1 WO2017052342 A1 WO 2017052342A1 KR 2016010783 W KR2016010783 W KR 2016010783W WO 2017052342 A1 WO2017052342 A1 WO 2017052342A1
Authority
WO
WIPO (PCT)
Prior art keywords
mcptt
terminal
message
mme
information
Prior art date
Application number
PCT/KR2016/010783
Other languages
English (en)
French (fr)
Inventor
백영교
원성환
김성훈
조성연
Original Assignee
삼성전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자 주식회사 filed Critical 삼성전자 주식회사
Priority to CN201680061602.5A priority Critical patent/CN108141751B/zh
Priority to US15/763,386 priority patent/US10924975B2/en
Publication of WO2017052342A1 publication Critical patent/WO2017052342A1/ko
Priority to US17/173,577 priority patent/US11627515B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H04W40/22—Communication route or path selection, e.g. power-based or shortest path routing using selective relaying for reaching a BTS [Base Transceiver Station] or an access point
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/30—Network architectures or network communication protocols for network security for supporting lawful interception, monitoring or retaining of communications or communication related information
    • H04L63/306—Network architectures or network communication protocols for network security for supporting lawful interception, monitoring or retaining of communications or communication related information intercepting packet switched data communications, e.g. Web, Internet or IMS communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/80—Arrangements enabling lawful interception [LI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/20—Transfer of user or subscriber data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
    • H04W8/24—Transfer of terminal data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/04—Terminal devices adapted for relaying to or from another terminal or user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/30—Types of network names
    • H04L2101/385—Uniform resource identifier for session initiation protocol [SIP URI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/618—Details of network addresses
    • H04L2101/654—International mobile subscriber identity [IMSI] numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4588—Network directories; Name-to-address mapping containing mobile subscriber information, e.g. home subscriber server [HSS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/11—Allocation or use of connection identifiers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/14—Direct-mode setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/27—Transitions between radio resource control [RRC] states
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/30—Connection release
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/40—Connection management for selective distribution or broadcast
    • H04W76/45—Connection management for selective distribution or broadcast for Push-to-Talk [PTT] or Push-to-Talk over cellular [PoC] services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/50—Connection management for emergency connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/005—Discovery of network devices, e.g. terminals

Definitions

  • the present invention relates to a method for supporting lawful interception for a remote UE accessing a network through a ProSe UE-Network Relay.
  • a 5G communication system or a pre-5G communication system is called a system after a 4G network (Beyond 4G Network) or a system after an LTE system (Post LTE).
  • 5G communication systems are being considered for implementation in the ultra-high frequency (mmWave) band (eg, such as the 60 Gigabit (60 GHz) band).
  • FD-MIMO massive array multiple input / output
  • FD-MIMO massive array multiple input / output
  • FD-MIMO massive array multiple input / output
  • Array antenna, analog beam-forming, and large scale antenna techniques are discussed.
  • 5G communication systems have advanced small cells, advanced small cells, cloud radio access network (cloud RAN), ultra-dense network (ultra-dense network) , Device to device communication (D2D), wireless backhaul, moving network, cooperative communication, coordinated multi-points (CoMP), and interference cancellation Technology development is underway.
  • cloud RAN cloud radio access network
  • ultra-dense network ultra-dense network
  • D2D Device to device communication
  • CoMP coordinated multi-points
  • Hybrid FSK and QAM Modulation FQAM
  • SWSC Slide Window Superposition Coding
  • ACM Advanced Coding Modulation
  • FBMC Fan Bank Multi Carrier
  • NOMA non orthogonal multiple access
  • SCMA sparse code multiple access
  • IoT Internet of Things
  • IoE Internet of Everything
  • M2M machine to machine
  • MTC Machine Type Communication
  • IoT intelligent Internet Technology (IT) service that collects and analyzes data generated from connected objects and creates new value in human life.
  • IoT is a field of smart home, smart building, smart city, smart car or connected car, smart grid, health care, smart home appliances, advanced medical services, etc. through convergence and complex of existing information technology (IT) technology and various industries. It can be applied to.
  • An object of the present invention is to support lawful interception for a remote UE accessing a network through a ProSe UE-Network Relay.
  • Another object of the present invention is to provide a method for delivering a small size message in a cellular IoT (CIoT) network structure.
  • CCIoT cellular IoT
  • an object of the present invention is to provide a method for registering in a mobile communication provider network and an application server.
  • Another object of the present invention is to provide an efficient broadcast related signaling delivery method.
  • an object of the present invention is to provide a call connection method for disaster safety nets.
  • UE relay user equipment
  • remote terminal information for the remote terminal remote terminal
  • MME mobility management entity
  • the remote terminal information includes IP address information assigned to the remote terminal, and user information for the remote terminal.
  • the IP address information is IP address or IPv6 prefix information for the remote terminal, and in case of using IPv4 (internet protocol version 4), the IP address information is It may be an IP address and port information for the remote terminal.
  • IPv6 internet protocol version 6
  • IPv4 internet protocol version 4
  • the user information includes at least one of International Mobile Subscriber Identity (IMSI), mobile subscriber integrated services digital network number (MSSISDN), session initiation protocol (SIP) uniform resource identifier (URI), and user information for Proximity-based service (ProSe). It can be one.
  • IMSI International Mobile Subscriber Identity
  • MSSISDN mobile subscriber integrated services digital network number
  • SIP session initiation protocol
  • URI uniform resource identifier
  • ProSe Proximity-based service
  • the operation method of the relay terminal may further include transmitting the remote terminal report message to the MME and driving a timer, and receiving the response message from the MME and stopping driving of the timer.
  • the remote terminal report message may be a control message for a packet data network (PDN) connection used by the relay terminal to relay the remote terminal.
  • PDN packet data network
  • a method of operating a mobility management entity includes remote terminal information on a remote UE connected to a network through a relay user equipment (UE). Receiving a remote terminal report message including the remote terminal report message, and transmitting a response message corresponding to the remote terminal report message to the relay terminal.
  • MME mobility management entity
  • a relay user equipment (UE) operating in a mobile communication system includes a transceiver for transmitting and receiving a signal, and a remote for a remote UE connecting to a network through the relay terminal. And a controller configured to transmit a remote terminal report message including terminal information to a mobility management entity (MME) connected to the relay terminal, and to receive a response message corresponding to the remote terminal report message from the MME.
  • MME mobility management entity
  • a mobility management entity (MME) operating in a mobile communication system includes a transceiver UE for transmitting and receiving a signal, and a remote UE connecting to a network through a relay user equipment (UE). And a control unit configured to receive a remote terminal report message including remote terminal information about a) from the relay terminal and to transmit a response message corresponding to the remote terminal report message to the relay terminal.
  • MME mobility management entity
  • Method and apparatus according to an embodiment of the present invention can effectively support the legal interception through the relay terminal in the network.
  • the method and apparatus according to an embodiment of the present invention can deliver a small size message in the cellular IoT (CIoT) network structure.
  • CoT cellular IoT
  • the method and apparatus according to an embodiment of the present invention may manage the quality of group communication.
  • the method and apparatus according to an embodiment of the present invention may be registered in a mobile communication provider network and an application server.
  • the method and apparatus according to an embodiment of the present invention may provide an efficient broadcast related signaling delivery method.
  • the method and apparatus according to an embodiment of the present invention can provide a call connection method for a disaster safety net.
  • the method and apparatus according to an embodiment of the present invention may provide a signaling and connection mode discrimination method for a cellular IoT service.
  • FIG. 1 is a diagram illustrating a ProSe network structure according to a first embodiment of the present invention.
  • FIG. 2 is a flowchart illustrating a process of transmitting, by a relay UE, legal interception information about a remote UE to a network according to a first embodiment of the present invention.
  • FIG. 3 is a flowchart illustrating a process of transmitting to a network that a connection with a remote UE has been disconnected according to a first embodiment of the present invention.
  • FIG. 4 is a flowchart illustrating a process in which a relay UE transmits lawful interception information about a remote UE to a network according to a first embodiment of the present invention.
  • FIG. 5 is a flowchart illustrating a process of transmitting to a network that a connection with a remote UE has been disconnected according to a first embodiment of the present invention.
  • FIG. 6 is a diagram illustrating a cellular IoT (CIoT) network structure according to a second embodiment of the present invention.
  • CCIoT cellular IoT
  • FIG. 7 illustrates a procedure for transmitting uplink non-IP data to be sent by a terminal through an MME and an SCEF according to a second embodiment of the present invention.
  • FIG 8 illustrates a procedure for transmitting non-IP data when the terminal is roaming according to the second embodiment of the present invention.
  • SDT small data transmission
  • FIG. 10 relates to a non-IP mobile terminated small data transmission procedure sent by a server to a terminal.
  • FIG. 11 illustrates an MCPTT service, which is referred to as a disaster safety net system, a SIP Core used to interwork it with an EPS, and a structure of an EPS and a terminal.
  • FIG. 12 is a diagram illustrating a method for registering in a mobile communication provider network and an application server according to embodiment 4-1 of the present invention.
  • FIG. 13 is a diagram illustrating a method for registering in a mobile communication provider network and an application server according to Embodiment 4-2 of the present invention.
  • FIG. 14 is a diagram illustrating a method for registering in a mobile communication provider network and an application server according to embodiment 4-3 of the present invention.
  • FIG. 15 is a diagram illustrating performing an IMS AKA authentication procedure for MCPTT UE authentication between an MCPTT UE and a SIP Core (or IMS) according to embodiment 4-4 of the present invention.
  • FIG. 16 illustrates an IMS AKA authentication procedure for MCPTT UE authentication between an MCPTT UE and a SIP Core (or IMS) according to embodiment 4-5 of the present invention.
  • FIG. 17 is a diagram illustrating performing an IMS AKA authentication procedure for MCPTT UE authentication between an MCPTT UE and a SIP Core (or IMS) according to embodiment 4-6 of the present invention.
  • FIG. 18 is a diagram illustrating performing an IMS AKA authentication procedure for MCPTT UE authentication between an MCPTT UE and a SIP Core (or IMS) according to embodiments 4-7 of the present invention.
  • FIG. 19 is a view showing that S-CSCF attempts 3rd party registration when attempting IMS Registraion according to embodiment 4-8 of the present invention.
  • 21 is a view for explaining the MCPTT authentication process according to embodiment 4-10 of the present invention.
  • FIG. 22 is a view for explaining the MCPTT user authentication procedure according to embodiment 4-11 of the present invention.
  • FIG. 23 is a diagram illustrating a broadcast-related signaling delivery method according to a fifth embodiment of the present invention.
  • FIG. 24 is a diagram of an MBSFN region operated by a plurality of MCEs according to the fifth embodiment of the present invention.
  • 25 is a diagram illustrating a dynamic coordination MBMS session initiation procedure according to the fifth embodiment of the present invention.
  • FIG. 26 is a diagram illustrating a static coordination MBMS session initiation procedure according to the fifth embodiment of the present invention.
  • FIG. 27 is a diagram illustrating an S1 setup request between a base station and an MME according to the fifth embodiment of the present invention.
  • FIG. 28 is a diagram illustrating a base station configuration update between a base station and an MME according to a fifth embodiment of the present invention.
  • 29 is a view illustrating an S3 setup request between an MCE and an MME according to the fifth embodiment of the present invention.
  • FIG. 30 is a diagram illustrating MCE configuration update between MCE and MME according to the fifth embodiment of the present invention.
  • FIG. 31 is a diagram illustrating a method and procedure for requesting a MCPTT Service Request from an MME by a MCPTT terminal according to a sixth embodiment of the present invention, and setting and changing a bearer context for the MME.
  • 32 is a diagram illustrating a method and procedure for a MCPTT terminal requesting a MCPTT Service Request from an MME and activating a second bearer context for the MME according to the sixth embodiment of the present invention.
  • FIG. 33 illustrates a procedure of priority processing in an EPS apparatus for receiving a paging for performing an MCPTT service by a MCPTT terminal and a procedure for establishing a bearer connection for an MCPTT service according to a sixth embodiment of the present invention.
  • FIG. 34 is a procedure in which an MCPTT terminal processes priority in an EPS device to receive paging for performing an MCPTT service and a procedure for establishing a priority bearer connection for an MCPTT service according to a sixth embodiment of the present invention. Indicates.
  • FIG. 35 is a diagram illustrating a method and procedure for establishing a bearer connection by informing that an MCPTT terminal is used and an MCPTT service when the MCPTT terminal is attached to an EPS network according to a sixth embodiment of the present invention.
  • FIG. 36 is a diagram illustrating a network architecture that supports a cellular IoT (CIoT) service according to the seventh embodiment of the present invention.
  • CCIoT cellular IoT
  • FIG. 37 is a view illustrating an operation for transmitting control plane data between an CIoT terminal and a CIoT RAN and an operation for each inner layer according to Embodiment 7-1 of the present invention.
  • 38 is a diagram illustrating an operation of transmitting an RRC connection request message between a CIoT terminal and a CIoT RAN according to embodiment 7-1 of the present invention.
  • 39 shows an example of a NAS message according to embodiment 7-2 of the present invention.
  • FIG. 40 shows another example of a NAS message according to embodiment 7-2 of the present invention.
  • FIG. 41 shows a method of informing a segmentation offset of a current NAS PDU compared to a total segmentation length after segmenting a large amount of data.
  • NAS PDU 42 is an indication indicating whether a NAS PDU currently transmitted is the last of consecutive NAS PDUs.
  • FIG. 1 a ProSe network structure for receiving a service through a network using a ProSe UE-NW relay through a proxy service between terminals is illustrated in FIG. 1. Can be.
  • FIG. 1 is a diagram illustrating a ProSe network structure according to a first embodiment of the present invention.
  • a relay terminal (UE-NW relay UE) is in the coverage of the base station (eNB) and performs a role of relay (relay) for delivering a service provided by the cellular network to the remote UE (remote UE).
  • a UE-NW relay UE registers a relay through an Evolved Packet Core (EPS) network and receives various information for providing a relay service, or receives a remote UE from a remote UE.
  • Prepare relay service such as creating PDN (Packet data Network) connection to provide IP service.
  • a relay terminal UE-NW relay UE
  • a remote UE receives a discovery solicitation message sent when a remote UE finds a relay and sends a discovery response message when a corresponding condition is met to discover a UE-NW relay UE.
  • the remote UE selects a desired relay among the discovered UE-NW relays to set up a connection between the corresponding UE-NW relay and the remote UE, and through this, the remote UE provides a service through the network. You can get it.
  • FIG. 2 is a flowchart illustrating a process of transmitting, by a relay UE, legal interception information about a remote UE to a network according to a first embodiment of the present invention.
  • the remote UE 200 sends a communication request message to access the ProSe UE-NW relay UE 210 (201). Accordingly, the authentication authentication is completed between the remote UE 200 and the ProSe UE-NW relay UE 210 through steps 202 and 211, and accordingly, the ProSe UE-NW relay UE 210 is configured for relay as needed.
  • a new packet data network (PDN) connection may be created (212).
  • the remote UE 200 allocates or sets an IP address through the ProSe UE-NW relay UE 210 (203).
  • the ProSe UE-NW relay UE 210 may acquire an IP address or IP address and port information about the remote UE 200.
  • the ProSe UE-NW relay UE 210 may obtain user information of the remote UE 200 through steps 201, 202, and 211.
  • the user info may be one of an international mobile subscriber identity (IMSI) or a mobile subscriber integrated services digital network number (MSISDN) or session initiation protocol (SIP) uniform resource identifier (URI) or user info information for a proximity-based service (ProSe) or May contain multiple values.
  • IMSI international mobile subscriber identity
  • MSISDN mobile subscriber integrated services digital network number
  • SIP session initiation protocol
  • URI uniform resource identifier
  • ProSe proximity-based service
  • the ProSe UE-NW relay UE 210 acquiring the user information informs the ProSe function 220 of the remote UE 200, that is, the IP address or IP address and port information assigned to the remote UE 200, and the remote UE.
  • a remote UE Info Report message 214 can be sent including the user info of 200.
  • the User Info may include one or several values of IMSI or MSISDN, SIP URI, or User Info information for ProSe.
  • the ProSe function 220 may send an ACK message to the ProSe UE-NW relay UE 210 (222).
  • the ProSe function 220 may transmit the received information about the access to the remote UE 200 to the HSS 250 (221).
  • the message of step 221 may include a message type for location update, may include a Prose relay access type indicating that the remote UE 200 is connected through the ProSe UE-NW relay, and also assigned to the remote UE 200.
  • the received IP address or IP address and port information, and IMSI information and user info of the remote UE 200 may be included.
  • the User Info may include one or several values of IMSI or MSISDN, SIP URI, or User Info information for ProSe.
  • the HSS may send a response message to the ProSe function (251).
  • the agent that requires lawful interception obtains the IP address and ports information for the remote UE 200 from the HSS 250 or ProSe function 220 (241), and performs the lawful Interception (242) ).
  • the remote UE 300 receives a service through a relay.
  • the relay UE 310 recognizing that the connection has been disconnected sends a Remote UE Info Report message to the ProSe Function 320. Sends information on the remote UE 300 is updated.
  • the Remote UE Info Report message may include a connection released indication indicating that the connection with the user info of the remote UE 300 has been disconnected.
  • the User Info may include one or several values of IMSI or MSISDN, SIP URI, or ProSe User Info of the remote UE 300.
  • the ProSe function 320 receiving the updated information of the remote UE 300 may transmit the updated information about the connection to the received remote UE 300 to the HSS 350 (321).
  • the message of step 321 may include a message type for location update, and may include a Prose relay access released type to indicate that the remote UE 300 connected through the ProSe UE-NW relay has been released. IMSI information and user info of the 300 may be included.
  • the User Info may include one or several values of IMSI or MSISDN, SIP URI, or User Info information for ProSe.
  • the HSS may send a response message to the ProSe function (351).
  • a relay UE 410 is a flowchart illustrating a process of transmitting lawful Interception information about a remote UE 400 to an EPS network.
  • the relay UE 410 transmits the user ID and IP address / port information of the remote UE 400 to the ProSe function 420 and transmits the information to the HSS (HSS).
  • HSS HSS
  • the GW 440 delivers information for performing lawful interception for the remote UE 400.
  • the relay UE 410 transfers the user ID and IP address / port information of the remote UE 400 to the MME 430 and considers transmitting this information to the GW 440.
  • the relay UE 410 proposes a method of transmitting information on the remote UE 400 to the MME 430 through a NAS message.
  • the remote UE 400 sends a communication request message to access the ProSe UE-NW relay UE 410 (401). Accordingly, authentication is completed between the remote UE 400 and the ProSe UE-NW relay UE 410 through steps 402 and 411, whereby the ProSe UE-NW relay UE 410 is configured to perform PDN for relay as needed. You can also create a new connection (412).
  • the remote UE 400 allocates or sets an IP address through the ProSe UE-NW relay UE 410 (403).
  • the ProSe UE-NW relay UE 410 may acquire an IP address or IP address and port information for the remote UE 400.
  • the ProSe UE-NW relay UE 410 may obtain a user info of the remote UE 400 through steps 401, 402, 411.
  • the User Info may include one or several values of IMSI or MSISDN, SIP URI, or User Info information for ProSe.
  • the ProSe UE-NW relay UE 410 acquiring the information may inform the MME 430 of the remote UE Info Report including information of the remote UE 400, that is, IP address information allocated to the remote UE, and user information of the remote UE.
  • Message 414 can be sent.
  • the IP address information means IP address or IPv6 prefix information for the remote UE 400 when using IPv6, and means IP address and port information for the remote UE 400 when using IPv4.
  • the User Info may include one or several values of IMSI or MSISDN, SIP URI, or User Info information for ProSe.
  • the MME 430 may send an ACK message to the ProSe UE-NW relay UE 410 (432).
  • the MME 430 may transmit the received information about the access to the remote UE 400 to the HSS 450 (431).
  • the message in step 431 may include a message type for location update, may include a Prose relay access type indicating that the remote UE 400 is connected through the ProSe UE-NW relay, and also assigned to the remote UE 400.
  • the received IP address information and the IMSI information and the user info of the remote UE 400 may be included.
  • the User Info may include one or several values of IMSI or MSISDN, SIP URI, or User Info information for ProSe.
  • the HSS 450 may send a response message to the MME 430 (451).
  • the information transmitted to the HSS 450 may be used in a process such as location update or UE identification or UE authentication by interworking with the HSS 450 and the S-CSCF in the process of using the IMS service.
  • the MME 430 may transmit the information about the connection to the received remote UE 400 to the G / W 440 (432).
  • the remote UE info report message in step 432 may include IP address information allocated to the remote UE, IMSI information of the remote UE, and user info.
  • the User Info may include one or several values of IMSI or MSISDN, SIP URI, or User Info information for ProSe.
  • the G / W 440 may send a response message to the MME 430 (441).
  • the agent requiring Lawful Interception performs Lawful Interception using the IP address and ports information of the corresponding remote UE in the G / W 440 (442).
  • the remote UE 500 receives a service through a relay.
  • the relay UE 510 that recognizes that the connection is disconnected sends a Remote UE Info Report message to the MME 530.
  • the information on the remote UE 500 is updated 512.
  • the Remote UE Info Report message may include a connection released indication and IP address information indicating that the connection with the user info of the remote UE 500 has been lost. have.
  • the User Info may include one or several values of IMSI or MSISDN, SIP URI, or ProSe User Info of the remote UE 500.
  • the IP address information means IP address or IPv6 prefix information for a remote UE when using IPv6, and IP address and port information when using IPv4.
  • the MME 530 receiving the updated remote UE information may transmit the updated information about the access to the received remote UE 500 to the HSS 550 (531).
  • the message of step 531 may include a message type for location update, and may include a Prose relay access released type to indicate that the remote UE 500 connected through the ProSe UE-NW relay has been released. It may also include IMSI information and User info of the UE 500.
  • the User Info may include one or several values of IMSI or MSISDN, SIP URI, or User Info information for ProSe.
  • the HSS 550 may send a response message to the MME 530 (551).
  • the MME 530 receiving the updated information of the remote UE 500 may transmit update information on the access to the received remote UE to the G / W 540 (532).
  • the Remote UE Info Report message in step 532 may include a Prose relay access released type to inform that the remote UE 500 that is accessed through the ProSe UE-NW relay has been released, and also includes IMSI information of the remote UE 500. It may also include User info.
  • the User Info may include one or several values of IMSI or MSISDN, SIP URI, or User Info information for ProSe.
  • the G / W 540 may send a response message to the MME 530 (541).
  • the relay UE may use a separate NAS message as in the above example in the process of sending a remote UE info report to the MME, that is, operations 414/433 or 512/533. have.
  • a remote UE info report when transmitted using an existing ESM STATUS message and the ACK is omitted, it may be transmitted as follows.
  • 5B is a diagram illustrating a process of transmitting and receiving an ESM status message between a terminal and a network according to the first embodiment.
  • the purpose of sending an ESM status message is for reporting at any time a specific error condition detected upon receipt of ESM protocol data, for process UE-network relay, or for IP connection information of a remote UE.
  • the ESM status message may be sent by the MME or may be sent by the UE.
  • the UE When the ESM entity of the UE receives the ESM status message, the UE takes different actions according to the received ESM cause value.
  • the UE stops the ESM procedure related to the received EPS bearer identifier, stops the associated timer and deactivates the corresponding EPS bearer context (without peer to peer signaling between the UE and the MME).
  • the UE stops the ESM procedure related to the received PTI value and stops the associated timer.
  • the UE stops the ESM procedure related to the associated PTI or EPS bearer identifier and stops the associated timer.
  • the MME makes a different operation according to the received ESM cause value.
  • the MME stops the ESM procedure related to the received EPS bearer identifier, stops the associated timer, and deactivates the corresponding EPS bearer context (without peer to peer signaling between the MME and the UE).
  • the MME stops the ESM procedure associated with the received PTI value and stops the associated timer.
  • the MME stops the ESM procedure related to the PTI or EPS bearer identifier and stops the associated timer.
  • the local action taken by the MME upon receiving an ESM status message along with any other ESM cause value may vary by implementation.
  • the ESM status message and associated timer for remote UE report are described below.
  • the ESM status message may be used by a relay UE (ProSe UE-to-network relay UE) to deliver IP connection information of the remote UE to the network.
  • a relay UE ProSe UE-to-network relay UE
  • the relay UE When the relay UE establishes or releases a PC5 direct link with the remote UE, the relay UE drives timer Txxxx and sends a remote UE report to the network via an ESM status message before the timer Txxxx expires.
  • the ESM cause is set to # 128 (Remote UE report transaction).
  • the relay UE may send remote UE reports of the plurality of UEs in the ESM status message.
  • the relay UE fails to send the remote UE report to the network via the ESM message before expiration of the timer Txxxx, the UE resets and restarts the timer Txxxx to resend the ESM status message.
  • the retransmission may be repeated four or more times according to the terminal implementation.
  • the remote UE information list connected with the relay UE is updated.
  • the relay UE drives the timer Txxxx, sends a remote UE report to the network via an ESM status message before the timer Txxxx expires, and the timer Tyyy If it is running, it resets and drives timer Tyyy.
  • the ESM cause is set to # 128 (Remote UE report transaction).
  • the relay UE may send remote UE reports of the plurality of UEs in the ESM status message.
  • the relay UE fails to send the remote UE report to the network via the ESM message before expiration of the timer Txxxx, the UE resets and restarts the timer Txxxx to resend the ESM status message.
  • the retransmission may be repeated four or more times according to the terminal implementation.
  • ESM status message is transmitted without Remote UE report IE configured as Remote UE report transaction.
  • the relay UE When the relay UE receives the acknowledgment, it stops driving the timer Tyyy that is running. However, if the relay UE does not receive the acknowledgment until expiration of timer Tyyy, the UE resets / restarts timer Tyyy to resend the ESM status message. The retransmission may be repeated four times, for example the UE may abort the procedure upon expiration of five times of timer Tyyy.
  • FIG. 6 is a diagram illustrating a cellular IoT (CIoT) network structure according to a second embodiment of the present invention.
  • CCIoT cellular IoT
  • a CIoT Serving Gateway Node is a network entity composed of a combination of an MME, an S-GW, and a P-GW, and refers to a lightweight Core Network entity for CIoT.
  • the T6a interface of the network structure is an interface for connecting between the MME and the SCEF, and a small size message may be transmitted using this interface.
  • FIG. 7 illustrates an uplink non-sending message to be sent by a terminal according to a second embodiment of the present invention. -Shows the procedure of transmitting IP data through MME and SCEF.
  • non-IP data means all data protocol types that do not have an IP structure.
  • the MME / SGSN / C-SGN 700 receives data from the UE via the RAN. At this time, an indicator for identifying whether the data is an IP packet may come. Alternatively, the MME / SGSN / C-SGN 700 can directly view the data packet and send it to the P-GW if it is an IP packet, or forward it directly to the PDN. .
  • the MME 700 transfers the SLMF 720 of the HPLMN through the IWK-SCEF.
  • the Monitoring Event As Small Data Transmission (SDT), this may indicate that the message is for data transmission.
  • the MME / SGSN 700 forwards the message to the SCEF 720 including the Non-IP data.
  • This message includes the SCEF Reference ID to identify the connection between the SCEF 720 and the MME.
  • the SCEF 720 checks the SCEF reference ID of the received message and obtains an SCS / AS Reference ID associated with it.
  • the SCS / AS Reference ID is an identifier used between the Application Server (SCS / AS) and the SCEF, and the SCEF and the Application Server (SCS / AS) identify each other using the ID.
  • the message received by the SCEF 720 may include a monitoring destination address, which means an address of an application server (SCS / AS). If there is no SCS / AS Reference ID, the destination of the received message can be determined using the address of the SCS / AS.
  • the SCEF transmits the non-IP data received in step 2 to the destination determined as described above.
  • the SCS / AS Reference ID or SCS / AS may include an identifier (External ID or MSISDN) for identifying the terminal.
  • MME and IWK-SCEF are network entitiy in Roaming network and SCEF is in Home network.
  • the MME / SGSN / C-SGN 800 receives data from the UE via the RAN. At this time, an indicator for identifying whether the received data is an IP packet may come. Alternatively, the MME / SGSN / C-SGN 800 may directly view the data packet and, if the IP packet is an IP packet, may be sent to the P-GW or directly transmitted to the PDN. If the IP packet is not an IP packet, the MME / SGSN / C-SGN 800 may transmit the IP packet. By setting the Monitoring Event as Small Data Transmission (SDT), this may indicate that the message is for data transmission.
  • SDT Small Data Transmission
  • the message may be sent directly to the SCEF 830 in the home network.
  • the MME / SGSN may additionally generate charging information accordingly.
  • the MME / SGS is configured to transmit a message to the IWK-SCEF 810 for the roaming terminal
  • the MME / SGSN forwards the message including the non-IP data received from the terminal to the IWK-SCEF.
  • the message may include an SCEF Reference ID, which is used to identify the connection between the MME / SGSN and the IWK-SCEF and the SCEF of the home network.
  • the IWK-SCEF 810 delivers the message received above to the SCEF 830.
  • the message includes non-IP data sent by the terminal and the SCEF Reference ID for identifying the connection between the SCEF 830 and the terminal.
  • the SCEF 830 checks the SCEF reference ID of the received message and obtains an SCS / AS Reference ID associated with it.
  • the SCS / AS Reference ID is an identifier used between the Application Server (SCS / AS) and the SCEF, and the SCEF 830 and the Application Server (SCS / AS) identify each other using the ID.
  • the message received by the SCEF may include a monitoring destination address, which means an address of an application server (SCS / AS). If there is no SCS / AS Reference ID, the destination of the received message can be determined using the address of the SCS / AS.
  • the SCEF transmits the non-IP data received in step 2 to the destination determined as described above.
  • the SCS / AS Reference ID or SCS / AS may include an identifier (External ID or MSISDN) for identifying the terminal.
  • SCS / AS forwards MT small data to SCEF.
  • the SCS / AS Reference ID and / or the SCS / AS Identifier may be delivered together with the small data.
  • IWK-SCEF SCEF forwards MT small data to IWK-SCEF.
  • ID of the target IWK-SCEF is found as follows: The SCEF Reference ID associated with the SCS / AS Reference ID received in step 1 is found. Find the IWK-SCEF ID associated with this SCEF Reference ID.
  • the SCEF Reference ID and / or the SCEF ID may be delivered together.
  • IWK-SCEF delivers MT small data to MME / SGSN / C-SGN.
  • the routing information of the target MME / SGSN / C-SGN is found as follows: The routing information associated with the SCEF Reference ID received in this step is found.
  • IMSI, SCEF Reference ID, SCEF ID and / or IWK-SCEF ID may be delivered together.
  • the SCEF ID may be an address or name indicating the SCEF.
  • Routing Information of the target MME / SGSN / C-SGN is found as follows: Find Routing Information associated with the SCEF Reference ID received in this step IMSI for identifying the UE when transmitting MT small data, UE and SCEF The SCEF Reference ID and / or the SCEF ID may be transmitted together to identify the inter-connection.
  • MME / SGSN / C-SGN which has received the MT small data, may deliver MT small data to the UE indicated by IMSI.
  • MME / SGSN / C-SGN may not serve the UE.
  • the MME / SGSN / C-SGN may inform the SCEF or the SCEF through the IWK-SCEF that MT small data cannot be delivered.
  • the SCEF may request the HSS for MME / SGSN / C-SGN routing information of the corresponding UE.
  • an external ID may be used as the ID of the UE or IMSI may be used.
  • the HSS gives routing information to the SCEF. It is not necessary to give IMSI information at this time. Then repeat step 2 above. The only difference is that it uses the newly received routing information.
  • SCEF delivers additional routing information with MT small data to IWK-SCEF.
  • SDT small data transmission
  • the SCS / AS 940 may send a request for Small Data Transmission (SDT) to the SCEF 930.
  • the request message includes an external ID for identifying a terminal or an MSISDN, an SCS / AS ID for identifying an SCS / AS, and an SCS / AS Reference for identifying a connection between an SCS / AS 940 and an SCEF 930 for a terminal. It contains an ID and a parameter to indicate that Small Data Transmission is to be set.
  • the External ID is an identifier mapped to the IMSI in the HSS, and the SCEF 930 knows which IMSI corresponds to the IMSI through signaling with the HSS 920.
  • Parameters indicating Small Data Transmission include the Traffic Category (see table below), the upstream data size, the downlink data size, the maximum uplink data size that can be sent at one time, the maximum downlink data size that can be sent at one time, and how often messages are sent and received. Frequency may be included.
  • the MME / SGSN 900, the C-SGN, the SCEF 930, and the IWK-SCEF 910 may control up / down data transmission according to the traffic category.
  • the traffic category is a MAR periodic report
  • the upstream data may not have a size larger than 200 bytes.
  • upstream data is not transmitted every 30 minutes or more.
  • the above-described data transmission control may be performed by the SCEF 930 or the IWK-SCEF 910 when the MME / SGSN / C-SGN 900 is the downlink in the uplink.
  • the SCEF 930 stores parameters for the SCS / AS Reference ID, the ID of the terminal, and the small data transmission received from step 1.
  • the SCEF 930 allocates an SCEF Reference ID for the request.
  • the SCS / AS 940 is not authorized to perform the SDT, or the request message is in the wrong format, or the SCS / AS 940 exceeds the quota for requesting the SDT. If so, the SCEF 930 forwards the error to the SCS / AS 940 with an appropriate Cause value.
  • the SCEF 930 checks the parameters for the SDT. If any of the parameters do not match the operator's policy, the request is rejected.
  • the SCEF 930 transmits a request for the SDT to the HSS 920 based on the information received in the above step.
  • the HSS can set parameters for the SDT in the MME / SGSN / C-SGN.
  • the HSS 920 examines the request and determines whether the ID (External ID or MSISDN) of the corresponding terminal exists and whether the included parameter is acceptable from the mobile service provider. The HSS 920 may check and permit the ID for charging. If not, send a reject message and reason to SCEF 930.
  • ID External ID or MSISDN
  • the HSS 920 sends a message to the MME / SGSN / C-SGN 900 to set up the SDT.
  • This message includes parameters for setting the SDT, SCEF ID, SCEF Reference ID, ID for charging, and ID of the terminal.
  • the MME / SGSN / C-SGN 900 stores the parameters received from step 5 above. Thereafter, data transmission can be started for the UE.
  • the MME / SGSN / C-SGN 900 may send a reject message in response to step 5 if the SDT related setting value set from the HSS 920 does not conform to the policy of the mobile communication operator.
  • the MME / SGSN / C-SGN 900 may transmit SDT related configuration parameters to the IWK-SCEF 910.
  • This message may include an SCEF ID, an SCEF Reference ID, an ID for charging, a parameter for an SDT, an IMSI, which is an identifier of a terminal, and routing information for MME / SGSN / C-SGN.
  • IMSI and MME / SGSN / C-SGN Routing Information are used by IWK-SCEF 910 and / or SDT (or other SCS / AS and / or SCEF for information delivery). Can only be delivered.
  • the IWK-SCEF 910 may perform downlink data transmission using IMSI and MME / SGSN / C-SGN Routing Information.
  • the MME / SGSN / C-SGN may deliver the IMSI (s) received in step 5.
  • MME / SGSN / C-SGN Routing Information is core network entity information served by UE indicated by each IMSI.
  • IWK-SCEF maps and stores IMSI, Routing Information and SCEF Reference ID.
  • the IWK-SCEF 910 may perform authorization for the SDT request, as performed by the SCEF 930 in step 6. If the authorization procedure for the SDT request fails, the MME / The reject message is sent to the SGSN / C-SGN 900.
  • the IWK-SCEF 910 stores the received parameter and sends an ACK to the MME / SGSN / C-SGN 900 to inform that the SDT is set.
  • the IWK-SCEF 910 stores the received parameter and sends an ACK to the MME / SGSN / C-SGN 900 to inform that the SDT is set.
  • the MME / SGSN / C-SGN 900 confirms the request received from the IWK-SCEF 910. Check whether the SDT is also applied to roaming, and whether or not the service is available for the Home PLMN of the terminal. If not allowed, send an error message to the IWK-SCEF 910. If the terminal is not roaming, the MME / SGSN / C-SGN 900 checks whether the terminal can use the SDT through the SCEF 930 following the procedure of steps 5 and 6. If the SDT is not allowed for the terminal, the MME / SGSN / C-SGN 900 transmits a rejection message indicating that the SDT is not allowed to the SCEF 930.
  • the MME / SGSN / C-SGN 900 sends an ACK to the HSS 920 to indicate that the SDT setup was successful.
  • the message may be performed in response to the SDT request sent by the HSS 920 or the SCEF 930.
  • the name of the message is not limited to the name SDT, but means a request message for transmitting non-IP data.
  • the HSS 920 If the HSS 920 has received from the MME / SGSN / C-SGN 900 that the SDT has been successfully performed through step 11, the HSS 920 informs the SCEF 930 that the establishment of the SDT has been successfully performed.
  • the message may include an SCEF Reference ID indicating an SCEF connection to the terminal, IMSI, which is an identifier of the terminal, routing information for sending a message to the MME / SGSN / C-SGN, and an IWK-SCEF ID if the roaming terminal was used.
  • IMSI and MME / SGSN / C-SGN Routing Information is only available if IWK-SCEF is used and / or if it is SDT (or other SCS / AS and / or SCEF is there for information delivery). Can be delivered.
  • the IWK-SCEF 910 may perform downlink data transmission using IMSI and MME / SGSN / C-SGN Routing Information.
  • the MME / SGSN / C-SGN 900 may deliver the IMSI (s) received in step 5.
  • MME / SGSN / C-SGN Routing Information is core network entity information served by UE indicated by each IMSI.
  • the IWK-SCEF 910 maps and stores IMSI, Routing Information, and SCEF Reference ID.
  • the SCEF 930 After confirming that the SDT setting for the terminal is completed, the SCEF 930 notifies the SCS / AS 940 that the SDT setting is completed.
  • the message may include a cause value indicating that the SCS / AS Reference ID and the SDT are successfully set.
  • FIG. 10 relates to a non-IP mobile terminated small data transmission procedure sent by a server to a terminal.
  • the SCS / AS 1020 may transmit non-IP data to the terminal after the SDT setting for the terminal is completed.
  • the SCS / AS 1020 may determine which SCS / AS Reference ID to use and which SCEF 1010 to transmit according to the SDT configuration procedure.
  • the SCEF 1010 may determine which SCEF Reference ID to use for non-IP data received from the SCS / AS 1020 and which IMSI the terminal uses.
  • the SCS / AS 1020 transmits a message to the SCEF 1010 including non-IP data to be sent to the UE.
  • This message contains SCS / AS reference ID and small data in non-IP format to send to UE.
  • the SCEF 1010 looks at the received SCS / AS reference ID, identifies which MME / SGSN / C-SGN 1000 should be sent, and which data is sent to which UE, and corresponds to the corresponding SCEF Reference ID or IMSI. Can be found. According to the carrier policy, if the SCS / AS 1020 is not authorized to perform the SDT or if the SCS / AS 1020 has exceeded the frequency that the SCS / AS 1020 can transmit, the SCEF 1010 immediately performs step 6 You can reject the SDT request.
  • the SCEF 1010 forwards the small data transmission request (SDT request) received from step 2 to the MME / SGSN / C-SGN 1000.
  • This message may include an SCEF Reference ID indicating the connection with the SCEF for the terminal.
  • the message may also include an IMSI for identifying the terminal.
  • This message includes non-IP data for transmission to the terminal.
  • step 5 After receiving the request, the MME / SGSN / C-SGN 1000 verifies the request. If it fails, step 5 notifies the SCEF 1010 that the small data transfer request (SDT request) has failed. The reason for the failure may be that the SDT service is no longer available due to the policy of the mobile communication service provider, or the transmission quota of the SDT that the SCEF 1010 can send is exceeded or the transmission frequency is exceeded.
  • the MME / SGSN / C-SGN 1000 determines that the SDT service can be provided as a result of confirming the request received from the step 3
  • the MME / SGSN / C-SGN 1000 receives the non-received message from the step 3 to the UE Send IP data. This is delivered via NAS signaling.
  • the MME / SGSN / C-SGN 1000 After passing the non-IP data to the terminal, the MME / SGSN / C-SGN 1000 sends a response back to the SCEF 1010 to inform that the SDT request has been processed. Or, if the non-IP data transmission to the terminal has failed or not allowed, the SCEF 1010 notifies the failure of the SDT request.
  • the SCEF 1010 notifies the SCS / AS 1020 of the result of the SDT request.
  • FIG. 11 illustrates an MCPTT service, which is referred to as a disaster safety net system, a SIP Core used to interwork it with an EPS, and an EPS and a UE structure.
  • the SIP Core of FIG. 11 is a system using a transport protocol called SIP, and an IMS is an example thereof.
  • P-CSCF of SIP Core has PCRF and Rx interface of EPS and can apply QoS and Policy to provide MCPTT service to UE by using this.
  • an Rx interface may be defined between the PCRF and the P-CSCF and / or between the PCRF and the MCPTT server. If the PCRF is operated while receiving information from two entities, the MCPTT server and the P-CSCF may give inconsistent information, so QoS control of the UE is difficult. Conversely, if two entities give the same information, one entity is not desirable because it is caused by meaningless signaling. Therefore, either one needs to be selected depending on operator policy and / or other pre-configurations.
  • MCPTT AS Application Server
  • MCPTT AS Application Server
  • the entry point may indicate the S-CSCF of the SIP core or the P-GW of the EPS.
  • the SIP Core or EPS contains information to find the PCRF in the PLMN.
  • the MCPTT AS may have mapping information including a range of IP addresses used by the terminal. Using this mapping information, you can find the PLMN for an IP address in a specific range. For example, it may be determined that IP x to IP y are mapped to PLMN 1.
  • the MCPTT AS receives the IP address of the terminal, the ID of the Home PLMN, and the ID of the Visited PLMN from the terminal through signaling through the MCPTT-1 interface. If the entry point of the corresponding PLMN is set, and this information matches the IP address of the terminal and the Home PLMN ID / Visited PLMN ID, the MCPTT AS may find the PCRF in the PLMN of the terminal. MCPTT AS has mutual service agreement with Home PLMN or Visited PLMN mobile service provider and performs the operation of searching for information about entry point and PCRF based on this.
  • the information that needs to be passed through Rx is:
  • All or part of the information may be delivered directly to the PCRF by the MCPTT AS through the Rx, or the MCPTT AS may be delivered to the SIP core through the SIP-2 interface so that the P-CSCF may deliver the PCRF through the Rx.
  • the PCRF may newly establish a bearer or modify an existing bearer according to the collected information.
  • the P-CSCF can release the Rx control.
  • MCPTT Server creates PCC rule directly through PCRF and Rx of EPC.
  • the Rx control information in the P-CSCF may be released. That is, P-CSCF does not negotiate with PCRF through Rx interface. Instead, the MCPTT server generates PCC rules through PCRF and Rx.
  • FIG. 12 is a diagram illustrating a method for registering in a mobile communication provider network and an application server according to embodiment 4-1 of the present invention.
  • the terminal 1200 accesses the LTE network 1210 by performing an attach procedure. Through the attach procedure, the terminal 1200 also performs an LTE authentication procedure and receives an IP connection.
  • MCPTT client means an application for MCPTT service.
  • the MCPTT Client accesses the Identity Management Function 1220 through the URI.
  • the MCPTT Client establishes an HTTPS connection with the Identity Management Function 1220 and establishes a TLS connection to perform an authentication procedure.
  • MCPTT user checks user authentication by accessing Identity Management function using user credentials (eg biometics such as fingerprint, iris recognition, or secure user ID, ID / password).
  • the user credential may include an MC User ID which is a user ID of the Mission Cricical Service.
  • the UE 1200 may transmit a service identifier.
  • the service identifier may indicate a specific service among MC services. For example, it can refer to PTT.
  • MCPTT Client requests Token to Identity Management Function (1220). This Token is used to authenticate the terminal when registering with the MCPTT AS 1250. If the terminal does not have a credential to access the SIP core (or IMS) or the terminal is not allowed to perform the registration procedure on the SIP core (or IMS), the MCPTT Client additionally performs IMS. You can request a Token for registration.
  • the ID management server may send a user ID for one or more services. This may be called an MCPTT user ID.
  • the MCPTT Client may obtain the Token A and Token B from different Identity Management Functions 1220.
  • One Identity Management Function 1220 may manage only an Identity for the MCPTT AS 1250, and another Identity Management Function 1220 may manage an Identity for a SIP Core (or IMS).
  • MCPTT terminal 1200 establishes a secure connection with the SIP Core (or IMS). Using this connection, the UE can perform SIP-based authentication and registration procedures.
  • MCPTT terminal 1200 performs a registration procedure to the SIP core (or IMS). To this end, the UE delivers a SIP Registration message to the SIP Core (or IMS) and includes an IMS credential or Token B.
  • Token B When Token B is used, the eP-CSCF 1230 derives the IMS identity from the Token, sends an OK response in response to the SIP Registration message sent from the MCTT terminal 1200, and includes the IMS identity. This IMS Identity is used later when the terminal sends a SIP message.
  • the MCPTT Client includes Token A in the SIP Registration message of this step, which is sent to the S-CSCF.
  • the S-SCSF 1240 forwards the Token A and IMS Identity to the MCPTT AS 1250.
  • the MCPTT AS 1250 checks Token A and, if the user authentication succeeds, delivers the MCPTT User ID to the terminal.
  • MCPTT User ID and IMS Identity are related to one UE in MCPTT AS.
  • the registration procedure to the MCPTT AS 1250 may be performed in conjunction with a SIP Core (or IMS) Registration procedure.
  • FIG. 13 is a diagram illustrating a method for registering in a mobile communication provider network and an application server according to Embodiment 4-2 of the present invention.
  • the terminal When the user turns on the MCPTT terminal 1300, the terminal performs an attach procedure to the LTE network 1310 to perform LTE authentication and obtain an IP connection.
  • the user runs the MCPTT Client.
  • the MCPTT Client uses the URI to access the Identity Management Function 1320 and establish an HTTPS connection with it. Establish a TLS connection to authenticate the Identity Management Function.
  • MCPTT user checks user authentication by accessing Identity Management function using user credentials (eg biometics such as fingerprint, iris recognition, or secure user ID, ID / password).
  • MCPTT Client requests Token to Identity Management Function (1320). This Token is used to authenticate the terminal when registering with the MCPTT AS 1350. If the terminal does not have a credential to access the SIP core (or IMS) or the terminal is not allowed to perform the registration procedure on the SIP core (or IMS), the MCPTT Client additionally performs IMS. You can request a Token for registration. (This is called Token B in the present invention)
  • the MCPTT Client may obtain the Token A and Token B from different Identity Management Functions 1320.
  • One Identity Management Function 1320 manages only the Identity for the MCPTT AS 1350 and the other Identity Management Function 1320 can manage the Identity for the SIP Core (or IMS).
  • MCPTT Client performs registration procedure on MCPTSS AS 1350.
  • the MCPTT Client delivers the Token A and IMPU (Terminal ID: IP Multimedia Public Identity) to the MCPTT AS 1350.
  • the MCPTT AS 1350 verifies the received Token A to derive the MCPTT User ID.
  • the UE 1300 may acquire the IMPU from information set in the ISIM (IP multimedia service identity) or from Token B.
  • the MCPTT AS 1350 associates and stores the MCPTT User ID and IMPU derived above.
  • 2.MCPTT terminal 1300 establishes a secure connection with the SIP Core (or IMS). Using this connection, the UE can perform SIP-based authentication and registration procedures.
  • MCPTT terminal 1300 performs a registration procedure to the SIP Core (or IMS).
  • IMS Credential eg IMPU
  • ISIM Session Initiation Protocol
  • Token B can be used for SIP registration.
  • FIG. 14 is a diagram illustrating a method for registering in a mobile communication provider network and an application server according to embodiment 4-3 of the present invention.
  • the terminal When the user turns on the MCPTT terminal 1400, the terminal performs an LTE procedure by performing an attach procedure to the LTE network 1410 and obtains an IP connection.
  • the user executes the MCPTT Client 1400.
  • the MCPTT Client 1400 connects to the Identity Management Function 1420 using a URI and establishes an HTTPS connection with it.
  • a TLS connection is established to authenticate the Identity Management Function 1420.
  • the MCPTT client 1400 performs the user authorization procedure.
  • the authentication request message is transmitted to the Identity Management Function 1420.
  • This message may include a user ID or a user credential that can be identified by the IMPU or Identity Management Function 1420.
  • the user checks user authentication by using biometics such as fingerprint and iris recognition, or secure user ID and ID / password.
  • the user credential may include an MC user ID.
  • the UE may also carry a service identifier.
  • the service identifier may indicate a specific service among MC services. For example, it can point to MCPTT. In this specification, just user ID refers to MCPTT user ID when the service is MCPTT.
  • the Identity Management Function 1420 authenticates a user using a User ID or User Credential. If authentication is successfully completed, Identity Management Function 1420 creates a Token based on IMPU and User ID. The generated token may be derived as an IMPU and a user ID. The identity management function 1420 includes the token in the authentication response message and transmits the token to the terminal.
  • the MCPTT Client 1400 sends a SIP registration message to the P-CSCF 1430, which is forwarded to the I-CSCF and S-CSCF 1440.
  • the registration message includes IMPU / IMPI, User ID, etc. Thereafter, the MCPTT Client 1400 is required for IMS AKA authentication. (Challenged)
  • the MCPTT Client 1400 which has been requested for authentication, transmits a registration message including an IMS AKA response and an IMPU / IMPI or User ID to the I-CSCF and the S-CSCF 1440. At this time, the MCPTT Client 1400 includes the Token received in the above procedure.
  • IMS AKA response is verified from S-CSCF 1440.
  • the S-CSCF 1440 performs a third party registration procedure with the MCPTT AS 1450.
  • the S-CSCF 1440 transmits a register message including an IMPU, a user ID, and a token to the MCPTT AS 1450.
  • the MCPTT AS 1450 verifies the Token. If it is determined that the token is valid, the MCPTT AS 1450 determines that the received User ID is valid. The user ID and IMPU are derived from the token, and it is checked whether the same is the same as the user ID and IMPU received from the S-CSCF in the above step. If a match is found, the MCPTT AS 1450 associates and stores the IMPU and the User ID, and later uses them to mutually identify the received message for the IMPU or the User ID. The MCPTT AS 1450 sends an ACK to confirm the ACK. do.
  • the S-CSCF 1440 delivers the received OK message to the MCPTT Client 1450.
  • FIG. 15 is a diagram illustrating performing an IMS AKA authentication procedure for MCPTT UE authentication between an MCPTT UE and a SIP Core (or IMS) according to embodiment 4-4 of the present invention. And it shows the TNA (Trusted Node Authentication) procedure between the MCPTT UE and MCPTT AS.
  • TNA Trusted Node Authentication
  • the terminal 1500 When the user turns on the MCPTT terminal 1500, the terminal 1500 performs an LTE authentication by performing an attach procedure to the LTE network 1510 and obtains an IP connection.
  • the user runs the MCPTT Client.
  • the MCPTT Client uses the URI to access the Identity Management Function 1520 and establish an HTTPS connection with it. Establish a TLS connection to authenticate the Identity Management Function (1520)
  • the MCPTT client performs the user authorization procedure.
  • the authentication request message is transmitted to the Identity Management Function 1520.
  • This message may include a user ID or user credential that can be identified by the IMPU or Identity Management Function 1520.
  • the user checks the user authentication using biometics such as fingerprint, iris recognition, or secured user ID, ID / password.
  • the Identity Management Function 1520 authenticates a user by using a user ID or a user credential. If authentication is successfully completed, Identity Management Function 1520 creates a Token based on IMPU and User ID. Tokens consist of an association between IMPI and IMPU, and a range of permitted Tokens.
  • the Identity Management Function 1520 transmits the Token in the authentication response message to the terminal.
  • the terminal 1500 performs IMS registration procedure and performs IMS AKA to perform authentication for signaling connection.
  • the terminal transmits to the S-CSCF 1540 including the MCPTT User ID and Token, which is used for MCPTT user authentication.
  • the S-CSCF 1540 performs a 3rd party registration procedure with the MCPTT AS.
  • the registration message is transmitted to the MCPTT AS using the IMPU, MCPTT User ID and Token received from step 4.
  • the MCPTT server 1550 verifies the Token, and if the Token is valid, the MCPTT AS determines that the received User ID is trusted.
  • the IMPU and MCPTT User ID are derived from the Token, and the IMPU and MCPTT User ID received from the registration message are checked to match. If the verification is successful, the MCPTT AS associates and stores the IMPU and the MCPTT User Identity. The MCPTT AS 1550 sends an Ok message to the S-CSCF 1540 and acknowledges it.
  • the S-CSCF 1540 transmits the Ok message to the MCPTT Client and acknowledges it.
  • FIG. 16 illustrates an IMS AKA authentication procedure for MCPTT UE authentication between an MCPTT UE and a SIP Core (or IMS) according to embodiment 4-5 of the present invention.
  • the encryption key can be delivered directly, but key setup information can be sent and received.
  • MCPTT AS may not be able to decrypt.
  • the MCPTT AS is connected to the ID Management server and / or config. You can send the encrypted MCPTT group / user ID to the Managemenet server and receive the decrypted MCPTT group / user ID.
  • Steps 1 to 3 performed in FIG. 16 are substantially the same as steps 1 to 3 of FIG. 15 described above, and thus a detailed description thereof will be omitted.
  • the Identity Management Function 1620 authenticates a user using a User ID and a User Credential. If the authentication is successful, the Identity Management Function 1620 transmits an authentication response message to the terminal, and informs the MCPTT AS that the terminal is authenticated. This message contains the IMPU, User ID, and Valid time for this valid authentication. After receiving the message, the MCPTT Server starts the Validity Timer.
  • the MCPTT Client 1600 sends a Registration message to the P-CSCF 1630, which is forwarded to the I-CSCF and S-CSCF 1640.
  • the registration message includes an IMPU / IMPI and an encrypted User ID.
  • the MCPTT Client 1600 encrypts the MCPTT User ID and includes it in the registration.
  • the configuration management function may provide an encryption key.
  • the MCPTT Client 1600 is then asked for an IMS AKA.
  • MCPTT Client 1600 performs IMS AKA and sends the response to S-CSCF with IMPU, IMPI, encrypted User ID.
  • S-CSCF 1640 verifies the IMS AKA response.
  • the S-CSCF 1640 performs a third party registration procedure with the MCPTT AS 1650.
  • the S-CSCF 1640 transmits a registration message to the MCPTT AS 1650 including the IMPU and the User ID.
  • the MCPTT AS 1650 determines that this User ID is valid, and checks whether the User ID and IMPU which are received in step 3-d are the same, and whether the Validity timer has not yet expired. After the procedure is successful, the MCPTT AS 1650 associates and stores the IMPU and User ID. This associated ID is used to mutually identify through an identifier of a terminal used in a later used message. The MCPTT AS 1650 decrypts the encrypted MCPTT User Identity.
  • the MCPTT server 1650 transmits an OK message to the S-CSCF 1640 and ACKs it.
  • the S-CSCF 1640 transmits the OK message to the MCPTT Client 1600 and ACKs.
  • FIG. 17 is a diagram illustrating performing an IMS AKA authentication procedure for MCPTT UE authentication between an MCPTT UE and a SIP Core (or IMS) according to embodiment 4-6 of the present invention.
  • MCPTT AS may not be able to decrypt.
  • the MCPTT AS is connected to the ID Management server and / or config. You can send the encrypted MCPTT group / user ID to the Managemenet server and receive the decrypted MCPTT group / user ID.
  • FIG. 18 is a diagram illustrating performing an IMS AKA authentication procedure for MCPTT UE authentication between an MCPTT UE and a SIP Core (or IMS) according to embodiments 4-7 of the present invention.
  • Token 1 is used for IMS authentication and Token 2 is used for MCPTT AS authentication, and encrypted information can be used.
  • the encryption key can be delivered directly, but key setup information can be sent and received.
  • MCPTT AS may not be able to decrypt.
  • the MCPTT AS is connected to the ID Management server and / or config. You can send the encrypted MCPTT group / user ID to the Managemenet server and receive the decrypted MCPTT group / user ID.
  • Steps 1 to 3 performed in FIG. 18 are substantially the same as steps 1 to 3 of FIG. 15 described above, and thus a detailed description thereof will be omitted.
  • the Identity Management Function 1820 may provide an encryption key to the MCPTT Client 1800. This encryption key is used to encrypt the MCPTT User Credential, which cannot be interpreted by the SIP Core (or IMS).
  • the Identity Management Function 1820 authenticates a user using a User ID and a User Credential. If authentication is successful, Identity Management Function 1820 creates two Tokens. We will call these Token 1 and Token 2. Token 1 is generated based on IMPU and IMPI pairs. From Token 1, IMPU and IMPI can be derived. Token 2 is created based on IMPU and User ID. The IMPU and User ID can be derived from Token 2.
  • the Identity Manageent Function 1820 transmits the Token 1 and Token 2 in the authentication response message to the MCPTT Client.
  • the MCPTT Client 1800 sends a registration message to the eP-CSCF 1830 including the received Tokens and the encrypted User ID.
  • the MCPTT Client 1800 encrypts the User ID and includes it in the message.
  • the eP-CSCF 1830 verifies Token 1 to obtain IMPU and IMPI. If Token 1 is verified, the eP-CSCF 1830 sends a Registration message to the S-CSCF, including IMPU, IMPI, User ID, and Token 2.
  • the S-CSCF 1840 performs a Trusted Node Authentication procedure to perform a registration procedure without an additional authentication procedure. This may include an indication that authentication has already been made.
  • the S-CSCF 1840 performs 3rd party registration with the MCPTT AS 1850.
  • S-CSCF 1840 transmits to MCPTT AS including IMPU, encrypted User ID, Token 2 in Registration message.
  • MCPTT AS 1850 verifies Token 2. If the Token is verified to be valid, the MCPTT AS determines that the User ID is valid, and checks whether the User ID and IMPU derived from Token 2 are the same as the IMPU and User ID received from the message. If it is determined to be the same, the MCPTT AS 1850 associates and stores the IMPU and the MCPTT User ID. The MCPTT AS decrypts the encrypted User ID. The MCPTT AS 1850 may have received an encryption key from the identity management function, or the encryption key may be set in advance.
  • the MCPTT AS 1850 transmits an OK message to the S-CSCF 1840 to ACK.
  • the S-CSCF 1840 transmits an Ok message to the MCPTT Client 1800 to ACK.
  • FIG. 19 is a view showing that S-CSCF attempts 3rd party registration when attempting IMS Registraion according to embodiment 4-8 of the present invention.
  • the S-CSCF 1940 performs MCPTT User authentication between the MCPTT Client 1900 and the MCPTT Server 1950.
  • the encryption key can be delivered directly, but key setup information can be sent and received.
  • MCPTT AS may not be able to decrypt.
  • the MCPTT AS is connected to the ID Management server and / or config. You can send the encrypted MCPTT group / user ID to the Managemenet server and receive the decrypted MCPTT group / user ID.
  • Steps 1 to 3 performed in FIG. 19 are substantially the same as steps 1 to 3 of FIG. 15, which will be omitted.
  • the Identity Management Function 1920 may provide an encryption key to the MCPTT Client 1900. This encryption key is used to encrypt the MCPTT User Identity. Encrypted MCPTT User Identity cannot be interpreted by the SIP Core (or IMS).
  • the Configuration management function may provide an encryption key.
  • step 3-d encryption key and / or key setup information may be delivered to the MCPTT AS.
  • the encryption key and / or key setup information is transmitted to the client.
  • Terminal 1900 performs IMS Registration and performs IMS AKA to authenticate.
  • the terminal 1900 includes an MCPTT user identity and a token in a registration message, which is used for MCPTT user authentication. If the MCPTT User Identity is encrypted, the MCPTT Client includes the encrypted MCPTT user ID in the Registration message.
  • the S-CSCF 1940 performs a third party registration procedure with the MCPTT AS 1950.
  • the S-CSCF 1940 transmits a registration message to the MCPTT AS 1950 including the IMPU, the MCPTT User ID, and the Token.
  • the MCPTT AS 1950 verifies the Token and determines that the User ID is valid if the Token is valid. And it is checked whether the IMPU and MCPTT User ID derived from the Token are the same as the MCPTT User ID and IMPU received from the Registration message. After confirming, MCPTT AS associates and stores the IMPU and MCPTT User Identity. Therefore, it is possible to identify which MCPTT User Identity or IMPU the message coming to IMPU or MCPTT User Identity later.
  • the MCPTT AS 1950 decrypts the MCPTT user identity.
  • the MCPTT AS 1950 may be provided with a key for decryption from the ID management function or may use a preset value.
  • the MCPTT AS 1950 sends an ACK message to ACK.
  • Steps 1 to 3 performed in FIG. 20 are substantially the same as steps 1 to 3 of FIG. 15, which will be omitted.
  • MCPTT Client does not include MCPTT User ID in Registration message.
  • the MCPTT AS does not verify the MCPTT user identity and IMPU derived from the Token. Instead, if the token is valid, it stores the MCPTT User Identity and IMPU derived from the token and associates them with the MCPTT service.
  • 21 is a view for explaining the MCPTT authentication process according to embodiment 4-10 of the present invention.
  • the MCPTT terminal 2100 After the power is turned on, the MCPTT terminal 2100 performs LTE authentication.
  • Step A According to the information set in the MCPTT Client, the terminal 2100 performs the MCPTT User authentication procedure based on the Token. The terminal 2100 obtains a token from the identity management server 2120. Token is used when MCPTT authentication is done in Step C.
  • the terminal delivers the MC User ID to the Identity Management Server 2120 and also transmits other User Credentials.
  • a Service ID (eg New York police_MCPTT) may also be provided.
  • the Identity Management Server 2120 returns a Service User ID, that is, an MCPTT User ID, to the terminal.
  • the service user ID that is, the MCPTT user ID, can be derived from the token.
  • Step B IMS authentication procedure is performed between the MCPTT terminal 2100 and the IMS 2130.
  • Step C After IMS authentication is performed, MCPTT user authentication is performed.
  • the Public Safety User Data Function (PS-UDF) or HSS stores an MCPTT user credential, which is used for MCPTT user authentication.
  • security information can be generated through mutual authentication.
  • the PS-UDF stores the credentials required for MCPTT user authentication and generates Sercurity information by mutual authentication.
  • FIG. 22 is a view for explaining the MCPTT user authentication procedure according to embodiment 4-11 of the present invention.
  • the following procedure may be performed.
  • the Identity Management Function 2220 authenticates the user using the MC User identity and the MC user authentication credential. If the authentication is successful, the identity management function 2220 generates a Token based on the IMPU, MC user ID, and Service ID. Alternatively, the token may be generated based on the IMPU and the MC service user ID (derived from the MC user ID and the service ID). Tokens can be encoded with associated authorization information such as MCPTT user ID and IMPU. The MCPTT User ID may not be explicitly delivered to the terminal, but instead can be derived later as a token.
  • the Identity Management Function 2220 includes the token in the authentication response message and delivers it to the terminal.
  • the INVITE message may not contain the MCPTT User ID.
  • the S-CSCF 2240 sends an ACK message to the MCPTT client 2200 to acknowledge.
  • S-CSCF 2240 performs 3rd party registration on MCPTT sever 2250.
  • the S-CSCF 2240 sends an IMPU, MCPTT User ID, and Token in a Register message.
  • the MCPTT User ID may not be included in the message. In this case, the MCPTT User ID may be derived using the Token.
  • the MCPTT server 2250 trusts the received MCPTT user ID if the token is valid. If there is no received MCPTT user ID, the MCPTT user ID derived from the token is used as the MCPTT user ID for the terminal.
  • the MCPTT AS 2250 stores the IMPU in association with the MCPTT User ID.
  • the fifth embodiment relates to an efficient broadcast related signaling delivery method and apparatus.
  • FIG. 23 is a diagram illustrating a broadcast-related signaling delivery method according to a fifth embodiment of the present invention.
  • the UE may send ECGI to the GCS AS 2340.
  • the GCS AS 2340 may determine whether to send an ECGI list to the BM-SC 2330 according to the configuration information.
  • the configuration information may be made available to the GCS AS 2340 according to an implementation policy according to an operator policy, or may be available to the GCS AS 2340 through signaling between the BM-SC 2330 and the GCS AS 2340. have.
  • the GCS AS 2340 In order for the GCS AS 2340 to activate the MBMS bearer with the MB2 interface, the GCS AS 2340 forwards an Activate MBMS Bearer Request message to the BM-SC 2330.
  • the message may include a TMGI, and the TMGI may identify an MBMS bearer. It can also include Flow ID, QoS, MBMS Broadcast area, and MBMS start time.
  • Flow ID is included only when TMGI is included and is used to distinguish a specific flow from MBMS traffic corresponding to TMGI. If a Flow ID is included in the message, the BM-SC associates it with the TMSI carried in the message and also the MBMS Broadcast area. (Association) The QoS value is mapped to a value representing priority for the MBMS bearer. If the MBMS Broadcast Area includes a list of Cell IDs, the BM-SC 2330 maps the Cell IDs to a set of MBMS service areas (SAs). The GCS AS 2340 may send the MBMS SA even when sending the ECGI list.
  • SA MBMS service areas
  • the BM-SC 2330 may ignore this MBMS SA and re-write to the MBMS SA obtained as described in the previous sentence.
  • the BM-SC 2330 puts the MBMS SA into the Activate MBMS Bearer Response.
  • the GCS AS 2340 may be used to configure MBMS service data. If the ECGI list is not received, the BM-SC 2330 does not put the MBMS SA in the Activate MBMS Bearer Response.
  • the GCA AS 2340 transmits an Activate MBMS Bearer request message to the BM-SC 2330.
  • the message may include TMGI, QoS, MBMS Broadcast Area, and Start time.
  • TMGI can identify the MBMS bearer.
  • the MBMS broadcast area may include a list of MBMS service area IDs, a list of cell IDs, or both.
  • the MBMS Broadcast area includes the MBMS Service Area Identity list
  • the MBMS Service Area Identity is checked according to the list of Cell IDs sent by the UE or other configuration information.
  • the BM-SC 2330 determines 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-SC 2330 rejects the request. If no TMGI is included in the message, the BM-SC 2330 assigns a TMGI value that has not been used so far.
  • the BM-SC 2330 allocates a Flow ID to the TMGI and MBMS Broadcast areas. If the MBMS Broadcast area parameter includes a list of Cell IDs, the BM-SC 2330 maps the Cell IDs to the MBMS Service Area Identity. Cell ID based mapping may be in accordance with the policy of the mobile carrier.
  • the BM-SC 2330 includes a list of MBMS service area identity in the MBMS Session Start message. In addition, the Cell ID list may be included in the MBMS Session Start message. If there is another MBMS bearer already activated for the same TMGI, the BM-SC 2330 controls the MBMS Broadcast arear to not overlap with the existing MBMS Bearer. The new MBMS Bearer is assigned a unique Flow ID to distinguish it.
  • the BM-SC 2330 allocates MBMS resources for the MBMS broadcast area and performs a Session Start procedure for contents delivery using the MBMS Bearer.
  • the MBMS SAI (s) in the MBMS Session Start Request message is a BM.
  • SC 2330 may be information obtained from cell identifier (s) received from GCS AS 2340. That is, more generally, it may be a different MBMS SAI (s) than the MBMS SAI (s) sent by the GCS AS 2340.
  • the BM-SC (2330).
  • the MBMS SAI (s) included in the MBMS Session Start Request message may be included in the Activate MBMS Bearer Response message.
  • the BM-SC 2330 maps Cell ID lists (ECGIs) to Service Area Lists (SAIs) and determines MBMS-GW (s) for the relevant area.
  • ECGIs Cell ID lists
  • SAIs Service Area Lists
  • MBMS-GW MBMS-GW
  • the BM-SC 2330 sends a Session Start message to the MBMS-GW (s) determined above.
  • the message includes a MBMS-related Paramter for 3GPP Release-12, and may include a Cell Id list (List of ECGIs).
  • TheMBMS-GW 2320 sends a Session Start message to the associated MME (s).
  • the message includes a MBMS-related Paramter for 3GPP Release-12, and may include a Cell Id list (List of ECGIs).
  • the MME 2310 sends a Session Start message to the related MCE (s) (involved MCE (s)).
  • the message includes a MBMS-related Paramter for 3GPP Release-12, and may include a Cell Id list (List of ECGIs).
  • a Cell Id list List of ECGIs.
  • the MME 2310 may have received an MCE identifier to which an eNB is connected or a cell in an eNB is connected during an S1 Setup or eNB Configuration Update process. Or, the list of cells or eNBs connected to the MCE may have been received during the M3 Setup or MCE Configuration Update process. Using this information, a Session Start message can be delivered only to an eNB corresponding to the received ECGI list. The MME may identify the eNB by looking at the Global eNB ID portion of the ECGI. Therefore, the appropriate MCE can be selected using the serving MCE information and ECGI information per eNB during S1 Setup or eNB Configuration Update.
  • MCE While performing MBMS Session Start procedure, MCE receives MBMS Session Start request message from MME through M3 interface. This message provides the base station with MCCH-related information (radio information for MBMS transmission), the base station establishes a bearer to send the MBMS to the terminal, and requests the terminal to inform the MBMS session.
  • MCCH-related information radio information for MBMS transmission
  • MBSFN transmission method In order to use the MBSFN transmission method, cells in one MBSFN area must be configured with the same MCCH-related information. If the MBSFN Area is controlled from one MCE, it is obvious that synchronized MCCH information will be used. If the MBSFN Area is controlled from multiple MCEs, for example, in case of having a distributed MCE structure, coordination of MCCH-related information between MCEs is necessary. In addition, when having a distributed MCE structure, all distributed MCEs must have the same admission control for MBMS session for one MBSFN area.
  • FIG. 24 is a diagram of an MBSFN region operated by a plurality of MCEs according to the fifth embodiment of the present invention.
  • FIG. 24 in a distributed MCE structure, it is shown how several cells in one MBSFN receive the same MCCH-related information.
  • FIG. 25 is a diagram illustrating a dynamic coordination MBMS session initiation procedure according to the fifth embodiment of the present invention.
  • FIG. 25 relates to an MBMS session initiation procedure when a plurality of MCEs operate an MBSFN area and the OAM dynamically provides MCCH-related information.
  • the MME 2530 and the MBMS GW perform an MBMS Session Start procedure.
  • the network management apparatus (OAM) 2520 is notified from the MME or MCE that the MME 2530 or the MCE has started an MBMS session. Attribute values for the MBMS session are delivered to the OAM 2520, and based on this value, the OAM 2520 generates MCCH related information.
  • the OAM 2520 provides MCCH-related information to the E-UTRANs 2500 and 2510.
  • the OAM 2520 may deliver the attribute value for the MBMS session received from the MME 2530 to the E-UTRAN.
  • the MME 2530 may not transmit the MBMS Session Start request to the MCE through the M3 interface.
  • the E-UTRAN sets up the RAN resource based on the information received from the OAM 2520.
  • FIG. 26 is a diagram illustrating a static coordination MBMS session initiation procedure according to the fifth embodiment of the present invention.
  • FIG. 26 relates to an MBMS session initiation procedure when a plurality of MCEs operate an MBSFN area and MCCH-related information is generated based on preset static information.
  • Multiple MCEs are configured to manage one MBSFN area, and these MCEs are configured to generate the same MCCH information if they are provided with the same session attribute.
  • the MME 2630 and the MBMS GW perform an MBMS Session Start procedure.
  • the MME 2630 forwards the MBMS Session Start Request message to the MCEs. According to a preset value in step 1, MCEs generate the same MCCH-related information.
  • MBMS Session Start procedure in case an MBSFN area is managed by multiple MCEs. (After performing MBMS Session Start procedure)
  • the MCE maps the SAI list received from the message to the list of MBSFN and removes the unused MBSFN from the corresponding ECGI list.
  • the MCE allocates resources for the MBMS Bearer to the assigned or selected MBSFNs.
  • the MCE stores a Cell Id list (list of ECGIs) of MBSFNs with MBMS Bearer enabled.
  • the MCE sends a Session Start response message to the MME.
  • the message includes an MBMS related Paramter for 3GPP Release-12, and may include a Cell Id list (List of ECGIs) in which an MBMS Bearer is activated by the session start request.
  • the MME forwards the Session Start Response message to the MBMS-GW.
  • the message includes a MBMS-related Paramter for 3GPP Release-12, and may include a Cell Id list (List of ECGIs) in which an MBMS Bearer is activated by the Session start request.
  • the message includes an MBMS related Paramter for 3GPP Release-12, and may include a Cell Id list (List of ECGIs) in which an MBMS Bearer is activated by the session start request.
  • MBMS related Paramter for 3GPP Release-12 may include a Cell Id list (List of ECGIs) in which an MBMS Bearer is activated by the session start request.
  • BM-SC sends Activate MBMS Bearer Response message to GCS AS.
  • the message includes the TMGI, the FlowID (if initially included in the Activate MBMS Bearer Request message, the same value or the Flow ID assigned from the BM-SC), the MBMS service description, and the user data transport plane. It contains the IP address and port number of the BM-SC and the expiration time.
  • the MBMS service description includes setting information related to the MBMS bearer, and includes at least one of the following information listed in TS 26.346. MBMS service area, radiofrequency, IP multicast address, APN, etc.
  • the expiration time indicates the expiration time of the TMGI when the BM-SC allocates a TMGI.
  • the BM-SC may include a serviceArea only in certain cases:
  • the BM-SC uses MBMS SAI (s) given by GCS AS.
  • the GCS AS may include the MBMS SAI (s) included in the message delivered in step 1 in the service description to be sent to the UE.
  • the BM-SC can receive the cell ID (s) from the GCS AS and derive the MBMS SAI (s) newly from it (using information set in the BM-SC). This may be different from the MBMS SAI (s) received from the GCS AS (even the GCS AS may not have sent the MBMS SAI (s)).
  • the GCS AS needs to be aware of the MBMS SAI (s) that the BM-SC actually delivers to the MBMS downstream nodes.
  • the BM-SC can deliver the MBMS SAI (s) delivered to the MBMS downstream node to the GCS AS, and the GCS SA receives the MBMS SAI (s) received from the BM-SC in the MBMS SAI (s) portion of the service description to be delivered to the UE. ) And send it to the UE.
  • the service description must include the list of MBMS service area identity that the BM-SC included in the MBMS Session Start message.
  • the service description must include a list of the cell ID list and the mapped MBMS service area identity.
  • the service description must include the MBMS Service Area Identity list that the BM-SC included in the MBMS Session Start message.
  • the Service Description MUST contain a list of MBMS Service Area IDs mapped to the Cell ID list.
  • the BM-SC sends an Activate MBMS Bearer Response message before receiving message 9, and if the List of ECGIs received in message 9 is different from the List of ECGIs received in message 1, the BM-SC will send a GCS. In order to inform the AS of the list of ECGIs in which the MBMS Bearer is currently activated, it can be updated by sending a message including the List of ECGIs received from the 9th to the GCS-AS.
  • the MCE information served by the base station between the base station and the MME may be exchanged using the following procedure and message.
  • the S1 Setup and the eNB Configuration Update process are performed as shown in FIGS. 27 and 28.
  • FIG. 27 is a diagram illustrating an S1 setup request between a base station and an MME according to the fifth embodiment of the present invention.
  • the base station 2700 may transmit an S1 SETUP REQUEST to the MME 2710 and receive an S1 SETUP RESPONSE corresponding to the S1 SETUP REQUEST from the MME 2710.
  • FIG. 28 is a diagram illustrating a base station configuration update between a base station and an MME according to a fifth embodiment of the present invention.
  • the base station 2800 may transmit an ENB CONFIGURATION UPDATE to the MME 2810 and receive an ENB CONFIGURATION UPDATE ACKNOWLEDGE corresponding to the ENB CONFIGURATION UPDATE from the MME 2810.
  • S1 SETUP REQUEST message can be defined as follows.
  • the ENB CONFIGURATION UPDATE message can be configured as follows:
  • the Global MCE ID may be defined as follows. This ID is used when establishing M3 Setup or updating MCE Configuration between MCE and MME.
  • the base station information connected to the MCE between the MCE and the MME according to the fifth embodiment of the present invention may be exchanged using the procedures and messages of FIGS. 29 and 30.
  • 29 is a view illustrating an S3 setup request between an MCE and an MME according to the fifth embodiment of the present invention.
  • the MCE 2900 may transmit an S3 SETUP REQUEST to the MME 2910 and receive an S3 SETUP RESPONSE corresponding to the S3 SETUP REQUEST from the MME 2910.
  • FIG. 30 is a diagram illustrating MCE configuration update between MCE and MME according to the fifth embodiment of the present invention.
  • the MCE 3000 may transmit an MCE CONFIGURATION UPDATE to the MME 3010 and receive an ENB CONFIGURATION UPDATE ACKNOWLEDGE corresponding to the ENB CONFIGURATION UPDATE from the MME 3010.
  • a high priority is given to a terminal using a public-safety LTE so that the MCPTT terminal can be allocated resources in EPS first, establish a connection first, and transmit data. Present the way.
  • MCPTT Mission Critical Push To Talk over LTE
  • 3GPP 3rd Generation Partnership Project
  • MCPTT Mission Critical Push To Talk over LTE
  • Public Safety is an example of a disaster safety net (Public Safety) service and may mean any service related to disaster safety net (Public Safety).
  • the MCPTT service consists of a UE, an Evolved Packet System (EPS), a Session Initiation Protocol (SIP) Core, and an MCPTT Application Server.
  • EPS may refer to LTE network
  • SIP Core refers to a network composed of core devices using Session Initiation Protocol.
  • IMS Internet Multimedia Subsystem.
  • the MCPTT service may be deployed in various structures. MCPTT operators can operate EPS, SIP Core, and MCPTT Application Server, and MCPTT operators can operate SIP Core and MCPTT Application Server and provide services in conjunction with EPS of other operators.
  • MCPTT service provider can operate only MCPTT Application Server and provide services by interworking with EPS and SIP Core of other service providers.
  • the MCPTT service can be divided into group call, one-to-one call, and emergency alert.
  • the group call provides a general call for public safety, an emergency call that provides communication with the highest priority in case of an emergency / emergency situation, and prepares for an impending emergency / emergency with lower priority than an emergency call. It can support Imminent Peril Call which enables group communication.
  • One-to-one calls support regular calls, emergency calls, and the Ambient Listening feature, which allows you to listen to the other party's surroundings.
  • the emergency notification refers to a function that can transmit its emergency / emergency situation to the MCPTT system or other MCPTT user as a notification, it may be called an emergency alert.
  • the emergency call provided by the MCPTT supports a group communication function, and thus the terminal should be able to receive as well as send an emergency call.
  • Emergency call, its next priority, Imminent Peril call, and Emergency Alert can all be processed in priority over general communication in EPS, SIP Core and MCPTT Application Server. Therefore, there is a requirement that a call requiring a high priority as above should be able to establish a connection and send and receive data faster than other calls.
  • the present invention provides a method for establishing a connection so that the MCPTT terminal can be allocated resources preferentially in the EPS and preferentially transmit data by giving a high priority to a terminal using a disaster safety net (hereinafter referred to as MCPTT).
  • MCPTT disaster safety net
  • the current emergency call control in EPS considers only the Mobile Originated situation, which is the case where the terminal attempts to make an emergency call by establishing a connection, and the MCPTT service is not separately controlled.
  • MCPTTs may have a higher priority than general services for disaster safety net services and should be applicable to EPS.
  • MCPTT can transmit / receive group call or one-to-one call, it should be able to support not only Mobile Originated situation but also Mobile Terminated situation that must answer MCPTT call coming to MCPTT terminal.
  • the present invention proposes a method in which the MCPTT terminal can have a high priority in using the MCPTT system, a method of allocating radio resources according to the method, and a method of notifying that the MCPTT terminal is an MCPTT terminal when accessing the MCPTT system.
  • MCPTT represents one of the disaster safety net services, and is a concept including a service having a different name supporting group communication between terminals and one-to-one communication, or emergency / emergency communication.
  • MCPTT may be replaced with the name Public Safety service.
  • Embodiments of the present invention may be similarly used in wireless communication, such as WLAN and Bluetooth, in addition to the described communication system.
  • the priority of the overall MCPTT service handled in the present invention may be a priority of a part of the MCPTT service, for example, an emergency call having the highest priority or an imminent peril call having a second priority.
  • the Mobile Originated scenario in which the MCPTT terminal initiates priority connection to the EPS network as a method for providing priority to the MCPTT terminal the Mobile Terminated scenario in which the MCPTT terminal receives priority from the EPS network and makes a priority connection
  • MCPTT The terminal will inform the EPS network that it is a MCPTT-enabled terminal and will explain how to access the terminal.
  • MCPTT Normal Call which means MCPTT Basic Call operation, Emergency Call having the highest priority, Imminent Peril Call, which is the next priority call, Ambient Listening, which is the ambient sound listening function, and Emergency Alert.
  • Different MCPTT services may provide different priorities.
  • EPS means Evolved Packet System or LTE network.
  • the EPS consists of an E-UTRAN between the UE and the eNB and an Evolved Packet Core (EPC), which is a core network of the LTE system.
  • EPC is composed of MME, S-GW, P-GW, PCRF and the like.
  • EPS is connected to a SIP Core in order to be connected to an MCPTT service, and the SIP Core may mean a network of core devices using a Session Initiation Protocol (SIP), and may refer to an Internet Multimedia Subsystem (IMS). Therefore, an IMS device such as P-CSCF referred to herein means a SIP Core device for MCPTT.
  • MCPTT Application Server means a network device for exchanging information of the Application layer for providing the MCPTT service, the meaning is not limited to the name of the Application Server various logical / physical devices required to configure the MCPTT service It may mean.
  • FIG. 31 is a diagram illustrating a method and procedure for requesting a MCPTT Service Request from an MME by a MCPTT terminal according to a sixth embodiment of the present invention, and setting and changing a bearer context for the MME.
  • the MCPTT terminal 3100 transmits an extended service request to the MME 3120 to establish an MCPTT connection to the EPS network, and receives a bearer having a priority corresponding to the MCPTT and wirelessly. Resources can be used.
  • FIG. 31 is a diagram illustrating a method and procedure for receiving a MCPTT UE 3100 requesting a Service Request for MCPTT from the MME 3120 and setting up a bearer applying QoS appropriate to the MCPTT.
  • the MCPTT terminal 3100 may be classified into a terminal using the MCPTT service and a terminal dedicated to the MCPTT service while using a general LTE service.
  • an MCPTT capable terminal a terminal capable of using both a normal service and an MCPTT
  • an MCPTT-only terminal a terminal capable of using only an MCPTT service
  • the MCPTT terminal 3100 needs to activate a bearer of the EPS network to use the MCPTT service, and initiates this request by sending an extended service request to the MME 3120.
  • the Extended Service Request message has a Service Type Field, and the MCPTT terminal 3100 may set and transmit an MCPTT service type in this field.
  • the MCPTT-capable terminal may request the MCPTT service due to the occurrence of the Public Safety situation or the communication for the Public Safety. At this time, MCPTT service type is set in the Service Type field and transmitted.
  • the MCPTT dedicated terminal may also request by indicating the MCPTT service in the Service Type Field.
  • the MCPTT service may be set to MCPTT that refers to the whole, or may be set to a value so that the MCPTT service can be distinguished from the MCPTT service. Or, it may be set to a value indicating a specific MCPTT service, such as MCPTT Group Call, MCPTT Emergency Call, MCPTT Imminent Peril Call, MCPTT Emergency Alert, Ambient Listening, or Private Call.
  • MCPTT Group Call MCPTT Group Call, MCPTT Emergency Call, MCPTT Imminent Peril Call, MCPTT Emergency Alert, Ambient Listening, or Private Call.
  • the MCPTT Emergency Call may be divided into an MCPTT Emergency Group Call, which represents an emergency group call, or an MCPTT Emergency Private Call, which represents an emergency one-to-one call.
  • the MCPTT terminal may specify that the MCPTT using terminal in the Device Property field of the Extended Service Request.
  • the MCPTT dedicated terminal may be specified in the Device Property field of the Extended Service Request to indicate that the MCPTT dedicated terminal.
  • the MME omits the Service Type field and can know that the UE uses the MCPTT service using only the Device Property field.
  • the Device Property may indicate the Capability for the MCPTT service, and may be set to indicate that the terminal uses the service related to the emergency among the MCPTT services by comprehensively indicating that the MCPTT is a UE or by classifying it as an MCPTT Emergency. Or in more detail, it may indicate the capability to use a specific MCPTT service, such as MCPTT Emergency Call, MCPTT Imminent Peril Call, MCPTT Ambient Listening, MCPTT Private call.
  • MCPTT Emergency Call MCPTT Imminent Peril Call
  • MCPTT Ambient Listening MCPTT Private call.
  • the MCPTT terminal 3100 When the MCPTT terminal 3100 wants to use a service that is MCPTT Emergency, the MCPTT terminal 3100 may use an extended service request, and a general MCPTT service may request a resource from the EPS network using a service request.
  • the MME can determine which MCPTT service to use by looking at the Service Type or Device Property, or both, included in the Extended Service Request.
  • the MME 3120 may also use the service for the overall MCPTT service, for emergency call of the MCPTT service, for Imminent Peril Call, for Ambient Listening, for Private Call, or for Emergency Alert. I can figure out. Alternatively, it may be determined that the MCPTT emergency service is used, and specific QoS for the service related to emergency may be applied.
  • the MME 3120 which has authenticated whether the MCPTT terminal 3100 determines which MCPTT service to use or can use the MCPTT service, may negotiate with the HSS 3140 to provide to the terminal to use a specific MCPTT service.
  • QoS information that can be obtained can be obtained.
  • the QoS information may include a QCI value for identifying a QoS priority and an ARP value for indicating whether a resource can be preempted first.
  • the MME 3120 stores the obtained information as an internal setting value or stores the information in MME Emergency Configuration Data and proceeds with the rest of the process.
  • the procedure between the MME 3120 and the HSS 3140 may be omitted, and in this case, the QoS value is determined according to an internal setting value stored in the MME 3120.
  • the internal setting value stored in the MME 3120 may be a value stored in the MME Emergency Configuration Data.
  • the MME 3120 modifies the Context for the Default Bearer of the terminal sending the request to have a QoS value suitable for the MCPTT service.
  • the MME 3120 changes the existing default bearer context to the corresponding QCI or ARP value.
  • the MME 3120 internally sets and stores that the bearer set in the above process is a bearer for public safety.
  • the MME 3120 changes the Default Bearer Context for the MCPTT UE 3100 according to the MCPTT service, the Emergency service, or the detailed MCPTT service, and then sends an Initial Context Setup Request to the eNB 3110. Request to establish bearer connection with UE according to the changed Bearer Context.
  • the eNB 3110 which has received the Initial Context Setup Request from the MME 3120, prepares for the creation of the bearer according to the Bearer Context, that is, the QoS information contained in the Initial Context Setup Request, and sends an RRC Connection Reconfiguration to the MCPTT UE 3100 to send the UE ( The bearer connection is established between the 3100 and the eNB 3110.
  • the eNB 3110 which has completed establishing the bearer connection with the UE 3100, sends an Initial Context Setup Response to the MME 3120 in response to the Initial Context Setup Request, and sets the QoS set by the MME 3120 with a bearer ID. Signals that the bearer has been set up.
  • the eNB 3110 may store that it is a bearer for public safety allocated to the terminal 3100. By using this information, the eNB 3110 may give priority to the bearer for public safety over other bearers for normal service, and allocate radio resources and data. You can transfer.
  • the MME 3120 receives the Initial Context Setup Response and sends a Modify Bearer Request to the S-GW / P-GW 3130 for connection between the eNB 3110 and the S-GW / P-GW 3130. And this results in a Bearer connection between the eNB 3110 and the S-GW / P-GW 3130.
  • the bearer connection established from the UE 3100 to the eNB 3110 and the S-GW / P-GW 3130 is a connection having a QoS value set by the MME 3120 according to the MCPTT Type in the above procedure.
  • the base station 3110 or the MME 3120 or the S-GW or P-GW 3130 may internally bind that the bearer is a bearer for public safety.
  • the base bearer 3110 and the S-GW / P-GW 3130 may have a different bearer because they may have a QCI or ARP value for higher QoS than the existing default bearer or may be known by binding that the bearer is a bearer for public safety. Can handle data delivery with higher priority.
  • P-GW (3130) that completes the establishment of the bearer connection can be used to provide a charging or service by updating the PCC rule by delivering the newly established bearer and terminal information to the PCRF.
  • the terminal 3100 In order to deliver the Extended Service Request message, the terminal 3100 establishes an RRC connection with the base station 3110.
  • the NAS layer of the terminal 3100 sets a value of RRC Establishment Cause and informs the RRC layer of the terminal 3100.
  • RRC Establishment Cause usually indicates whether it is Mobile Originated Signaling, Mobile Originated Data, Mobile Terminated Signaling, or Mobile Terminated Data.
  • the RRC layer of the UE 3100 constructs an RRC message and sends a connection request to the BS 3110.
  • the present invention proposes an identifier indicating that the RRC Establishment Cause is Public Safety.
  • This may be an identifier subdivided into Mobile Originated Public safety signaling, Mobile Originated Public safety data, Mobile Terminated Pubic safety signaling, Mobile Terminated public safety data, or may be an identifier representing overall Public Safety. Regardless of which identifier has what name, it contains the cause value for the RRC connection request indicating the public safety service (including MCPTT).
  • the terminal 3100 may avoid congestion control between the terminal 3100 and the base station 3110 (Overriding Congestion control) or an access class between the terminal 3100 and the base station 3110. Barring, application level congestion control for data communication (ACDC) can be avoided.
  • congestion control between the terminal 3100 and the base station 3110 (Overriding Congestion control) or an access class between the terminal 3100 and the base station 3110.
  • ACDC application level congestion control for data communication
  • the base station 3110 may store the public safety terminal for the terminal 3100 requested as the cause as described above, and if the terminal 3100 needs handover, the base station 3110 may process the other terminal.
  • 32 is a diagram illustrating a method and procedure for a MCPTT terminal requesting a MCPTT Service Request from an MME and activating a second bearer context for the MME according to the sixth embodiment of the present invention.
  • the MCPTT terminal 3200 is assigned to bearer having a priority corresponding to the MCPTT by transmitting an Extended Service Request to the MME 3220 to establish the connection for MCPTT in the EPS network Resources can be used.
  • the MCPTT terminal 3200 needs to activate a bearer of the EPS network in order to use the MCPTT service, and sends an extended service request to the MME 3220 to initiate this request.
  • the Extended Service Request message has a Service Type Field, and the MCPTT terminal 3200 can set and transmit an MCPTT service type in this field.
  • the MCPTT-capable terminal may request the MCPTT service due to the occurrence of the Public Safety situation or the communication for the Public Safety.
  • MCPTT service type is set in the Service Type field and transmitted.
  • the MCPTT dedicated terminal may also request by indicating the MCPTT service in the Service Type Field.
  • the MCPTT service may be set to MCPTT that refers to the whole, or may be set to a value so that the MCPTT service can be distinguished from the MCPTT service.
  • it may be set to a value indicating a specific MCPTT service such as MCPTT Group Call, MCPTT Emergency Call, or MCPTT Imminent Peril Call, MCPTT Emergency Alert, Ambient Listening, or Private Call.
  • the MCPTT Emergency Call may be divided into an MCPTT Emergency Group Call, which represents an emergency group call, or an MCPTT Emergency Private Call, which represents an emergency one-to-one call.
  • the MCPTT terminal may specify that the MCPTT using terminal in the Device Property field of the Extended Service Request.
  • the MCPTT dedicated terminal may be specified in the Device Property field of the Extended Service Request to indicate that the MCPTT dedicated terminal. In this case, the MME omits the Service Type field and can know that the UE uses the MCPTT service using only the Device Property field.
  • the Device Property may indicate the Capability for the MCPTT service, and may be set to indicate that the terminal uses the service related to the emergency among the MCPTT services by comprehensively indicating that the MCPTT is a UE or by classifying it as an MCPTT Emergency.
  • MCPTT Emergency Call MCPTT Imminent Peril Call
  • MCPTT Ambient Listening MCPTT Private call.
  • MCPTT Emergency Call MCPTT Imminent Peril Call
  • MCPTT Ambient Listening MCPTT Private call.
  • the MCPTT terminal 3200 may use the Extended Service Request when it wants to use the MCPTT Emergency service, and the general MCPTT service may request a resource from the EPS network using the Service Request.
  • the MME 3220 may determine which MCPTT service to use by looking at the Service Type or Device Property or both of the values included in the Extended Service Request.
  • the MME 3220 may determine whether to use the service for the overall MCPTT, emergency call of the MCPTT service, or Imminent Peril Call, Ambient Listening, Private Call, or Emergency Alert. Can be. Alternatively, it may be determined that the MCPTT emergency service is used, and specific QoS may be applied to the service related to the emergency.
  • FIG. 31 is distinguished from FIG. 31 in this embodiment in order that the MME 3220 knows in advance whether the terminal 3200 is a terminal capable of using the MCPTT service and requests a MCPTT service in order to allocate a bearer suitable for QoS for the MCPTT. It is storing Secondary Default Bearer Context for MCPTT.
  • the terminal 3200 is a terminal capable of using the MCPTT service will be described in another embodiment of the present invention. If the UE 3200 with MCPTT Capability has performed the Attach, the MME 3220 is an MCPTT capable terminal capable of using the MCPTT service and using the Normal Service, or an MCPTT dedicated terminal capable of using only the MCPTT service. It can be seen by looking at the value contained in MCPTT Capability.
  • the MME 3220 that performs the attachment procedure of the MCPTT capable terminal or the MCPTT dedicated terminal configures a secondary default bearer context having a QoS value for the MCPTT in preparation for requesting the MCPTT service.
  • the secondary default bearer context may be the context for the overall MCPTT, the context for the MCPTT Emergency service, or may have a separate context for Emergency Call, Imminent Peril Call, Ambient Listening, Private Call, and Emergency Alert.
  • Secondary Default Bearer Context is composed of the corresponding QCI or ARP value.
  • the MME 3220 may check the MCPTT Type and determine whether the terminal 3200 can use the service. After that, the bearer context corresponding to the MCPTT type requested by the terminal 3200 among the bearer contexts stored in the MME 3220 is selected as the secondary default bearer context, and the bearer connection establishment is started according to the QoS included in the context.
  • the MME 3220 transmits an Initial Context Setup Request to the eNB using a bearer context in a secondary default bearer context.
  • the eNB 3210 receives the Initial Context Setup Request from the MME 3220, the eNB 3210 prepares to generate a bearer according to Bearer Context, that is, QoS information contained in the Initial Context Setup Request, and sends an RRC Connection Reconfiguration to the MCPTT UE 3200 to between the UE and the eNB. Establish a bearer connection.
  • Bearer Context that is, QoS information contained in the Initial Context Setup Request
  • the eNB 3210 which has completed establishing the bearer connection with the UE 3200, sends an Initial Context Setup Response to the MME 3220 in response to the Initial Context Setup Request, and has a Bearer having QoS set by the MME 3220 with a Bearer ID. Signals that is set.
  • the MME 3220 After receiving the Initial Context Setup Response, the MME 3220 transmits a Modify Bearer Request to the S-GW / P-GW 3230 for the connection between the eNB 3210 and the S-GW / P-GW 3230. As a result, a bearer connection is established between the eNB 3210 and the S-GW / P-GW 3230.
  • the bearer connection established from the terminal 3200 to the eNB 3210 and the S-GW / P-GW 3230 is a connection having a QoS value set by the MME according to the MCPTT Type in the above procedure, and has a higher priority than other bearers. You can handle data delivery by rank.
  • the base station 3210 or the MME 3220 or the S-GW or P-GW 3230 may bind internally that the bearer is a bearer for public safety. Since the base bearer 3210 and the S-GW / P-GW 3230 may have a different bearer because they may have a QCI or ARP value for higher QoS than the existing default bearer or may be known by binding that the bearer is a bearer for public safety. Can handle data delivery with higher priority.
  • the P-GW 3230 which has completed the establishment of the bearer connection, may transmit the newly established bearer and terminal information to the PCRF to update the PCC rule and utilize it for charging or service provision.
  • FIG. 33 illustrates a procedure of priority processing in an EPS apparatus for receiving a paging for performing an MCPTT service by a MCPTT terminal and a procedure for establishing a bearer connection for an MCPTT service according to a sixth embodiment of the present invention.
  • the MCPTT terminal 3330 receives the data having a high priority from the MCPTT service, the bearer having priority as a result of the paging process and the result of applying paging
  • the terminal using the MCPTT service is in the IDLE Mode operation.
  • data on the use of the MCPTT service from the MCPTT service is transmitted from the MCPTT Application Server to the P-CSCF.
  • the P-CSCF may determine whether signaling arriving from the MCPTT Application Server should be processed with priority.
  • Overall priority can be given to MCPTT services, or high priority can be given to MCPTT Emergency services, or detailed MCPTT services such as Emergency Call, Imminent Peril Call, Ambient Listening, Private Call, Emergency Alert, etc. Services can be classified and given priority.
  • the P-CSCF 3360 forwards the P-GW 3330 to the P-GW 3330 including an indication that signaling from the MCPTT Application Service has priority.
  • the P-CSCF 3360 may request the PCRF 3350 to give a high priority to data from the IP address of the MCPTT application server 3370, and the PCRF 3350 may reflect this.
  • the P-GW 3330 may inform the PCC Rule to reflect the high priority of data arriving from the IP of the MCPTT application server 3370 or update the policy.
  • the P-GW 3330 may know that high priority signaling has arrived. If the above procedure is not followed, the P-GW 3330 may store the MCPTT dedicated terminal when the MCPTT terminal 3300 is attached, and perform paging at a high priority when there is downlink data to be transmitted to the corresponding terminal. Can be.
  • the P-GW 3330 delivers a Downlink Notification message to the MME 3320 for paging to the UE.
  • the P-GW 3330 may add an identifier to the Downlink Notification message indicating that the Downlink Notification is for MCPTT, MCPTT Emergency, or detailed MCPTT service.
  • the identifier is included in the downlink notification message by adding the identifier for the MCPTT service or MCPTT emergency or MCPTT detailed service to the indication flag of the downlink notification message, or corresponding to the emergency or the MCPTT service in the ARP setting value of the downlink notification message.
  • a corresponding value may be set, MCPTT information may be set in Paging and Service Information of Downlink Notification message, MCPTT Emergency information may be set, or detailed MCPTT service information may be set.
  • the MME 3320 may determine that the data type transmitted to the downlink is for MCPTT, MCPTT Emergency or detailed MCPTT service.
  • the MME 3320 may store the MCPTT-dedicated terminal when the MCPTT terminal 3300 is attached, and may set a high priority for the terminal 3300.
  • the MME 3320 then sends a paging message to the eNB 3310, which includes an indication that this paging should be processed with high priority for MCPTT or MCPTT Emergency or for detailed MCPTT service.
  • the MME 3320 may set the paging priority of the paging message according to the MCPTT service, the MCPTT Emergency, or the detailed MCPTT service.
  • the eNB 3310 may determine that the paging should be processed first, and may process it before other paging requests.
  • the MCPTT terminal 3300 listens to paging and responds to the eNB 3310, and the eNB 3310, which has received a response from the MCPTT terminal 3300, transmits an Initial UE message to the base station 3310 to transmit the MCPTT terminal 3300. Request to establish a bearer connection for.
  • the MME 3320 may receive an Initial UE message and may determine that the UE, which has received the paging having the priority, requests a bearer connection.
  • the MME 3320 determines a context of a bearer to be allocated to the MCPTT terminal, and sets a QoS value according to an MCPTT service, an MCPTT emergency, or a detailed MCPTT service.
  • the MME 3320 may negotiate with the HSS to obtain QoS information that can be provided to the terminal to use a specific MCPTT service.
  • the QoS information may include a QCI value for identifying a QoS priority and an ARP value for indicating whether a resource can be preempted first.
  • the MME 3320 may store the obtained information as an internal setting value or store the information in MME Emergency Configuration Data and proceed with the rest of the process. The procedure between the MME 3320 and the HSS 3340 may be omitted, in which case the QoS value is determined according to an internal setting value stored in the MME 3320.
  • the internal setting value stored in the MME 3320 may be a value stored in the MME Emergency Configuration Data.
  • the MME 3320 determines which QoS to provide for the bearer to be allocated to the MCPTT terminal 3300, and then modifies the context of the default bearer of the terminal 3300 which has sent the request to have a QoS value suitable for the MCPTT service.
  • the MME 3320 For example, if it is determined that the MME 3320 needs to provide the MCPTT emergency service to the MCPTT terminal 3300 which has sent the Extended Service Request, it changes the existing default bearer context to the corresponding QCI or ARP value.
  • the secondary default bearer context stored for MCPTT is activated. Thereafter, the MME 3320 sends an Initial Context Setup Request to the eNB 3310 and requests to establish a bearer connection with the UE 3300 according to the configured Bearer Context.
  • the eNB 3310 receives the Initial Context Setup Request from the MME 3320, the eNB 3310 prepares to generate a bearer according to Bearer Context, that is, QoS information contained in the Initial Context Setup Request, and sends an RRC Connection Reconfiguration to the MCPTT UE 3300 to transmit the UE 3300. Establish a Bearer connection between the eNB 3310.
  • the eNB 3310 which has completed establishing the bearer connection with the UE 3300, sends an Initial Context Setup Response to the MME 3320 in response to the Initial Context Setup Request, and has a Bearer having QoS set by the MME 3320 with a Bearer ID. Signals that is set.
  • the MME 3320 After receiving the Initial Context Setup Response, the MME 3320 transmits a Modify Bearer Request to the S-GW / P-GW 3330 for connection between the eNB 3310 and the S-GW / P-GW 3330. As a result, a bearer connection is established between the eNB 3310 and the S-GW / P-GW 3330.
  • the bearer connection established from the UE 3300 to the eNB 3310 and the S-GW / P-GW 3330 is a connection having a QoS value set by the MME 3320 according to the MCPTT Type in the above procedure, and the other Bearer Can handle data delivery with higher priority.
  • the P-GW 3330 which has completed the establishment of the bearer connection, may transmit the newly established bearer and terminal information to the PCRF 335 to update the PCC rule and use it for charging or service provision.
  • the MCPTT terminal 3300 may use the MCPTT service with a high priority in response to a request from the MCPTT service.
  • FIG. 34 is a procedure in which an MCPTT terminal processes priority in an EPS device to receive paging for performing an MCPTT service and a procedure for establishing a priority bearer connection for an MCPTT service according to a sixth embodiment of the present invention. Indicates.
  • FIG. 34 illustrates an embodiment according to the present invention, in which the P-GW 3430 receives MCPTT signaling from the P-CSCF 3460 as in the embodiment of FIG. 33.
  • the name Emergency is used in FIG. 34, it is obvious that the public safety service, the overall MCPTT service, the MCPTT Emergency, or the detailed MCPTT service may be represented.
  • Bearer connection with priority means bearer connection with high QoS for MCPTT service, bearer connection with high QoS for MCPTT emergency service, or bearer connection with high QoS according to detailed MCPTT service. can do.
  • the P-GW 3430 receives a high priority signaling from the P-CSCF 3460, the P-GW 3430 sends a paging message to the MME 3420 and then establishes some QoS to establish a bearer connection with the appropriate priority for the high priority. Determine if should be applied to new bearer.
  • the P-GW 3430 may store the MCPTT dedicated terminal when the MCPTT terminal 3400 is attached, and if there is downlink data to be transmitted to the terminal 3400, the P-GW 3430 may have a high priority. You can decide to apply the QoS value to the new bearer.
  • the P-GW 3430 After determining the QoS, the P-GW 3430 transmits an Update Bearer Request to the MME 3420 via the S-GW 3430, and sets and transmits a QoS value having a high priority determined in the procedure.
  • the MME 3420 receiving the message determines a bearer context to be allocated to the MCPTT terminal 3400 based on the information contained in the message.
  • the MME 3420 may store the MCPTT dedicated terminal when the MCPTT terminal 3400 is attached, and may set a high priority for the terminal 3400.
  • the MME 3420 may modify a context of an existing default bearer in order to establish a bearer connection having a high priority, in which case it may follow Embodiment 1 of the present invention.
  • Bearer connection establishment may be performed by activating the previously stored Secondary Default Bearer Context, in which case, according to Embodiment 2 of the present invention.
  • the MME 3420 may perform dedicated bearer connection establishment suitable for high priority. In this case, both the default bearer connection and the dedicated bearer connection are established, and the MCPTT terminal 3400 uses the MCPTT service through the dedicated bearer.
  • the MME 3420 may establish a new bearer connection. In this case, all existing bearer contexts are deactivated, and a new bearer is created according to the bearer context newly determined by the MME 3420.
  • the procedure in which the MME 3420 negotiates with the MCPTT terminal 3400 to generate a bearer is according to another embodiment of the present invention.
  • FIG. 35 is a diagram illustrating a method and procedure for establishing a bearer connection by informing that an MCPTT terminal is used and an MCPTT service when the MCPTT terminal is attached to an EPS network according to a sixth embodiment of the present invention.
  • MCPTT terminal 3500 attaches to the EPS network
  • a method for notifying that the MCPTT can be used and an MME 3520 for notifying the use of the MCPTT service through the attachment. It shows a method, and a method and procedure for establishing a bearer connection accordingly.
  • the MCPTT terminal 3500 performs an attach procedure to access the EPS network.
  • the MPCTT terminal 3500 may inform the MME 3520 that the terminal uses the MCPTT in the Attach Request message as follows.
  • the MCPTT terminal 3500 may indicate that the MCPTT is in the Type Field of the Attach Request message or may indicate that the MCPTT Emergency. In addition, the MCPTT terminal 3500 may set the MCPTT APN in the APN field of the Attach Request message to inform that it will access the MCPTT service.
  • the MCPTT terminal 3500 may set a value corresponding to the MCPTT Capability in the UE network capability of the Attach Request, and may indicate that the MCPTT terminal is a Device Property.
  • the MCPTT terminal 3500 may inform that it is an MCPTT terminal by performing at least one or more of the above methods, and may indicate that a bearer connection for MCPTT should be established as a result of attaching using the Type and APN fields of the Attach Request.
  • a terminal that can use both the MCPTT service and the normal service can inform the core network that the terminal can use the MCPTT service by indicating a public safety capability in the UE network capability. (Same as the MCPTT capable terminal in FIG. 31)
  • the operation of setting UE network capability or device property may indicate that the corresponding terminal is a terminal capable of using MCPTT. In case of an MCPTT-only terminal, only an MCPTT service may be used. In this case, it may indicate that the MCPTT is a dedicated terminal in the device property.
  • the MME receiving the attachment request configured as described above may preconfigure a secondary bearer context for the MCPPT service for the corresponding UE in the manner described in FIG. 32 of the present invention.
  • the MCPTT terminal 3500 transmits the Attach Request message configured as described above to the eNB 3510 including the RRC Connection Setup Complete message during the RRC connection procedure.
  • the MCPTT terminal 3500 processes the RRC message as a priority to connect the MCPTT service. It may include an indication that it should be. (RRC Establishment Cause)
  • the eNB 3510 which has received an RRC Connection Setup Complete message containing an Attach Request message together with the Indication from the MCPTT UE, may process a request of the UE before the requests of other UEs according to the Indication. Including an Attach Request message in the Initial UE message, and including the indication that it should be processed with a high priority, and delivers it to the MME 3520.
  • the MME 3520 may process the request before the request arrives from another eNB according to an indication that priority processing included in the message is required. Accordingly, the MME 3520 that receives the Attach Request message contained in the Initial UE Message may determine the context of a bearer required for the UE 3500 according to a value set when the MCPTT UE 3500 configures the Attach Request message. .
  • the MME 3520 may determine that the UE requesting the Attach needs an Emergency Bearer for MCPTT. Similarly, if the type of the Attach message indicates the MCPTT Emergency, it can determine the bearer context for the MCPTT Emergency to the terminal. In addition, even if the type of the Attach message is not set, whether UE can use the MCPTT in the UE Network Capability or if the MCPTT UE is set in the Device Property, the MCPTT service priority is set in case the UE uses the MCPTT service.
  • the appropriate Bearer Context can be determined and saved as the Secondary Default Bearer Context.
  • the MME 3520 which determines the bearer context by the same process as described above, may request and obtain QoS information from the HSS 3540, and may verify that the UE 3500 requesting the attachment may have high QoS. You can also do The above process may be omitted, and if omitted, the stored value may be used by the MME Emergency Configuration data or another method in the MME 3520.
  • the MME 3520 transmits a Create Session Request to the S-GW / P-GW 3530 in order to provide a bearer connection to the UE 3500 requesting the attach, and in this case, the S-GW / P-GW 3530.
  • a high priority value may be transmitted in the Indication Flag or Signaling Priority Indication of the Create Session Request message or the QoS value of the Bearer Context.
  • the S-GW / P-GW 3530 may check an indication flag or signaling priority indication to process the message more preferentially than a request from another terminal or the MME 3520, or to bearer information. By checking the contained QoS value, if it has a high priority QCI or ARP value corresponding to Emergency, it may be determined that the request should be processed first.
  • the P-GW 3530 may accept the Create Session Request and negotiate with the PCRF 3550 to update the PCC rule. Thereafter, the P-GW 3530 may respond to the Create Session Request with a Create Session Response, and the Secondary Default Bearer that may be activated when the MCPTT terminal 3500 wants to use the MCPTT service in the Create Session Response message. Information is included, or the current MCPTT terminal 3500 includes the Default Bearer information to be activated to transmit.
  • the MME 3520 receiving the message includes the Attach Accept message and the Bearer Context information in the Initial Context Setup Request, and the eNB 3510, which receives the message, transmits the Attach Accept in the RRC Connection Reconfiguration message, and the Initial Context Setup Request.
  • the bearer connection is established between the UE and the eNB 3510 according to the Bearer Context in.
  • the eNB 3510 When the bearer connection between the UE 3500 and the eNB 3510 is established, the eNB 3510 sends an initial context setup response to the MME 3520 to inform that the bearer is set up, and the MME 3520 sends an S-GW / P-GW ( 3530) sends a Modify Bearer Request to establish a Bearer connection between the eNB 3510 and the S-GW / P-GW 3530.
  • the terminal 3500 transmits an Attach Accept message to the MME 3520 to terminate the attach procedure.
  • an operation of notifying the priority for public safety leading to the P-GW 3530, the S-GW 3530, the MME 3520, and the eNB 3510 may mean a continuous operation, and the operation must be P. It may not be an operation subsequent to the GW 3530.
  • the MME 3520 knows that the terminal is a public safety terminal even if it is not a public safety identifier that extends from the P-GW 3530 to the S-GW and the MME 3520.
  • Related information may be delivered to the eNB 3510.
  • the base station or MME 3520 or the S-GW or P-GW 3530 may internally bind that the corresponding terminal or bearer is for public safety.
  • the bearer may have a QCI or ARP value for a higher QoS than the bearer, or may be bound according to the process of FIG.
  • the request for the corresponding terminal or bearer can be known as the purpose of public safety based on the bound value. Accordingly, the base station 3510 and the S-GW / P-GW 3530 may process data transfer at a higher priority than other bearers.
  • the terminal 3500 In order to deliver the Extended Service Request message, the terminal 3500 establishes an RRC connection with the base station 3510.
  • the NAS layer of the terminal 3500 sets a value of RRC Establishment Cause and informs the RRC layer of the terminal 3500.
  • RRC Establishment Cause usually indicates whether it is Mobile Originated Signaling, Mobile Originated Data, Mobile Terminated Signaling, or Mobile Terminated Data. Thereafter, the RRC layer of the UE 3500 constructs an RRC message and sends a connection request to the base station 3510.
  • the present invention proposes an identifier indicating that the RRC Establishment Cause is Public Safety.
  • This may be an identifier subdivided into Mobile Originated Public safety signaling, Mobile Originated Public safety data, Mobile Terminated Pubic safety signaling, Mobile Terminated public safety data, or may be an identifier representing overall Public Safety. Regardless of which identifier has what name, it contains the cause value for the RRC connection request indicating the public safety service (including MCPTT).
  • the terminal 3500 may avoid congestion control between the terminal 3500 and the base station 3510 (Overriding Congestion control) or an access class between the terminal 3500 and the base station 3510. Barring, application level congestion control for data communication (ACDC) can be avoided.
  • congestion control between the terminal 3500 and the base station 3510
  • ACDC application level congestion control for data communication
  • the base station 3510 may store the public safety terminal for the terminal 3500 requested as the cause, and if the terminal needs handover, the base station 3510 may preferentially process the other terminal.
  • the base station 3510 that has received the cause may detect that the terminal 3500 intends to use a public safety (or MCPTT) terminal and may allocate it to a core network dedicated to public safety (or MCPTT).
  • the base station 3510 which has received the public safety related identifier as the RRC Establishment Cause may request connection to the MME set as the Public Safety dedicated MME or the Public Safety priority MME when selecting the MME 3520.
  • the MME 3520 may specifically manage the terminal 3500 connected to the network for public safety service so that the MME 3520 may always be connected to the network without applying a back-off timer. .
  • the terminal 3500 using the normal service may wait without accessing the network for a predetermined time by applying a back-off timer.
  • the terminal 3500 using the public safety in a network congestion situation can identify that the terminal is a terminal using the public safety in the MME according to the method provided by the present invention. In this case, even if the network is congested, the back-off Network connection can be allowed without applying timer.
  • the Internet has evolved from a human-centered connection network where humans create and consume information, and an Internet of Things (IoT) network that exchanges and processes information among distributed components such as things.
  • IoT Internet of Things
  • IoE Internet of Everything
  • M2M machine to machine
  • MTC Machine Type Communication
  • IoT Internet technology
  • IoT is a field of smart home, smart building, smart city, smart car or connected car, smart grid, health care, smart home appliances, advanced medical services, etc. through convergence and complex of existing information technology (IT) technology and various industries. It can be applied to.
  • IoT technologies are in the spotlight in various fields, and service providers and vendors are developing various applications and systems using the IoT.
  • cellular IoT (hereinafter referred to as 'CIoT') using licensed frequency bands assigned to cellular systems is drawing attention.
  • eMTC evolved machine type communication
  • GERAN Global System for Mobile communications Enhanced Data rates for GSM Evolution Radio Access Network
  • Advanced communication technology enables communication between all things, not just between users, and is represented by the term Internet of Things (IoT).
  • IoT Internet of Things
  • a user may have several types of electronic devices, all of which may be connected to each other through mobile communication or short-range communication technology, various sensors, etc. to provide more convenient functions to the user or to efficiently control the devices. Do. Such electronic devices may be collectively referred to as IoT devices.
  • IoT devices there may be a measurement device that measures a building's electricity consumption, water usage, and the like and transmits the measured value through the network.
  • an IoT device can be installed in a public place or an isolated area for public safety, and the devices can notify the event situation through a network when a specific event occurs.
  • a device triggering operation may be performed in which a home appliance in a home includes a network connection function, which reports a state of the home appliance or instructs a user to perform a specific operation with the home appliance.
  • the IoT device includes a mobile communication module such as long term evolution (LTE) or a short range communication module such as Bluetooth, wireless LAN (WiFi), Zigbee, or near-field communication (NFC).
  • LTE long term evolution
  • WiFi wireless LAN
  • Zigbee Zigbee
  • NFC near-field communication
  • the LTE terminal may be operated on an LTE carrier frequency or may be operated on an ISM band.
  • CIoT represents an IoT service using a cellular network.
  • the cellular network means a mobile communication network, and includes 2G represented by GERAN, 3G represented by GPRS, and 4G represented by LTE.
  • the CIoT service refers to a cellular service for supporting an Internet of Things (IoT) terminal and may refer to a service for transmitting a small amount of data through a cellular network. It may also include a machine type communication (MTC) service.
  • IoT Internet of Things
  • MTC machine type communication
  • Cellular network is a concept that includes not only Radio Access Network but also Core Network.
  • the user plane data and control plane data sent by the terminal is distinguished.
  • User plane data refers to application-related traffic that a terminal uses while using an internet service or an IoT service
  • control plane data refers to data containing control information that the terminal exchanges with entities in order to use a cellular network.
  • the term is not limited to the above name, and other terms for distinguishing a packet sent for majoring data from a network and a control signal sent for providing a service may be used.
  • CIoT Existing network equipment can be changed for CIoT.
  • there may be a base station dedicated to CIoT and there may be a base station having a CIoT function added to an existing base station.
  • CIoT dedicated base station or a base station in which a CIoT function is added to an existing base station will be referred to as CIoT RAN for convenience.
  • the present invention is not limited to the terms, and other terms having equivalent technical meanings may be used.
  • Core Network existing in Cellular network can exist for CIoT.
  • the Core Network entitiy for CIoT will be referred to as CIoT CN Node (Core Network Node).
  • C-SGN 3GPP is called C-SGN, but is not limited to the term in the present invention, and other terms having equivalent technical meanings will be used.
  • CIoT CN Node refers to an entity including the functions of the MME and the Serving Gateway in the current LTE system, and may be an entity including the functions of the PDN Gateway.
  • the CIoT CN Node can deliver the terminal data to the application server or the data received from the application server, as well as the context management, mobility management, and signaling session management of the CIoT terminal. That is, the CIoT CN Node provides a gateway function to the CIoT terminal and may serve as a gateway for receiving data from the CIoT RAN and routing it to an application server. If the CIoT CN Node also includes the functionality of the PDN Gateway, the CIoT CN Node can send User Plane data directly to the Application Server.
  • the CIoT CN Node establishes a Control Plane connection with the CIoT terminal.
  • the CIoT terminal establishes a bearer (AKA SRB; Signaling Radio Bearer) for the control plane and the CIoT RAN, and the CIoT RAN transmits the CIoT CN Node and the control plane data.
  • AKA SRB Signaling Radio Bearer
  • the CIoT RAN transmits the CIoT CN Node and the control plane data.
  • Establish an S1 bearer connection As a result, the CIoT terminal establishes a connection between the CIoT CN Node and the control plane bearer.
  • CIoT terminal is established CIoT terminal?
  • the CIoT RAN is transmitted and received through the SRB, and the CIoT RAN transmits the corresponding control plane data through the CIoT CN Node and the S1 bearer established through the above procedure.
  • the above-described SRB or S1 Bearer is not limited to the name, SRB means a bearer connection established in the radio resources to transmit the control information signal of the terminal, S1 Bearer is between the CIoT RAN and CIoT CN Node The connection used to carry control information signals.
  • a terminal, a base station, and a core network entity process control plane data and user plane data at different priorities.
  • the terminal, the base station, and the core network entity process control plane data, that is, data containing control information, more preferentially than user plane data.
  • Types of control plane data include attachment, tracking area update, service request, and the like, and include an ESM (EPS Session Management) message for managing a session to be provided to the terminal.
  • the messages are messages exchanged between the terminal and the Core Network Entity. Since the messages are processed by the NAS layer, they may be referred to as NAS messages.
  • Data transmitted by the terminal to the control plane is included in the NAS message, the NAS message is included in the RRC message is transmitted from the terminal to the base station.
  • the base station delivers the NAS message of the received RRC message to the Core Network Entity (MME or CIoT CN Node) through the control plane connection.
  • MME Core Network Entity
  • CIoT terminal has a characteristic of intermittently transmitting and receiving small data. (Infrequent Small Data Transmission) Therefore, without establishing a user plane connection between the CIoT terminal and the CIoT CN Node, only the control plane connection can be established to transmit the user plane data through the control plane connection. As a result, it is possible to obtain efficiency at the radio resources and the network side by omitting a control information signaling procedure for establishing a user plane connection, a user plane encryption operation, or a user plane connection.
  • a Signaling Radio Bearer (SRB) is used to transmit the RRC message.
  • SRB currently has SRB 0, SRB 1, SRB 2, the UE transmits the SRB 1 and SRB 2 by putting a NAS message in the RRC message.
  • the UE and Core Network Entity (eg MME) perform a procedure in the NAS layer. Through the NAS procedure, the network controls the terminal, manages mobility, establishes a connection, and the like.
  • the NAS layer of the UE and the Core Network Entity performs a NAS procedure while exchanging NAS messages. This NAS message contains control information, so it is sent and received through the control plane.
  • the UE can transmit the user data contained in the NAS message through the SRB used to send the control plane data.
  • the base station receiving the message does not distinguish whether the received data is control data sent by the CIoT terminal or the general terminal or user data sent by the CIoT terminal, and recognizes all of the control data. Therefore, all of them are regarded as control plane data and processed with priority. If the base station is congested and it is difficult to receive even control data of some terminals, there may be a problem that the control data of the CIoT terminal or the general terminal cannot be processed due to the user data over control plane of the CIoT terminal. In other words, the NAS message containing the control data sent by the CIoT terminal or the general terminal may not be processed because of the NAS message containing the user data sent by the CIoT terminal.
  • the CIoT CN Node cannot know whether the NAS message received from the CIoT terminal is control data or user data before directly checking the data.
  • the CIoT CN Node should map control data to GTP-C and forward it to the PDN-gateway, and user data should map to GTP-U and forward it to the PDN-gateway. Therefore, the CIoT CN Node checks the NAS message received from the CIoT terminal to distinguish whether it is control data or user data, and then transmits the user data to the P-GW using a GTP-U tunnel.
  • a corresponding procedure or a control message may be configured to negotiate through the P-GW and the GTP-C interface.
  • the traffic sent by the CIoT terminal can be classified into two types. 1) When ACK is needed 2) When ACK is not needed. Since a large number of UEs access a network to perform small data transmission, efficient use of radio resources is important. Therefore, 1) if an ACK is required, it is necessary to maintain an RRC connection between the CIoT terminal and the CIoT RAN for a predetermined time, and 2) if no ACK is required, the radio resource can be saved by transitioning to the RRC_IDLE state immediately after data transmission. .
  • the user data is divided into several NAS messages and the user data is transmitted. Since the continuous NAS messages are transmitted, the CIoT terminal and the CIoT RAN need to maintain a certain time connection.
  • the UE and the CIoT RAN may perform an operation for maintaining the RRC connection for a predetermined time if the RRC connection currently being used is an RRC connection requiring continuous message delivery. On the contrary, if continuous message delivery is not needed, RRC_IDLE can be directly entered without maintaining the RRC connection, thus saving radio resources by not maintaining the RRC connection unnecessarily.
  • CIoT traffic types are classified to execute a specific traffic transmission preferentially, and CIoT-specific network equipment supporting CIoT-specific network equipment by classifying CIoT-only network equipment and general network equipment that supports CIoT has more CIoT related signaling.
  • CIoT-specific network equipment supporting CIoT-specific network equipment by classifying CIoT-only network equipment and general network equipment that supports CIoT has more CIoT related signaling.
  • a seventh embodiment of the present invention deals with the operation of a terminal and a network device for supporting IoT in a cellular network.
  • a feature of CIoT is that a large number of terminals can access the network at the same time, and the network can deliver data to a large number of terminals at the same time. As a result, network congestion is expected to intensify more than regular cellular systems.
  • the seventh embodiment of the present invention is described based on the LTE system defined in 3GPP, but can be similarly used in wireless communication such as WLAN and Bluetooth.
  • a method and apparatus for exchanging relay related information between a core network and a base station to support a UE to Network Relay function, which is one of ProSe functions for public safety service, and a base station to support a relay function proposes a method and apparatus for controlling a terminal.
  • 3GPP will mainly target a wireless access network, a core network LTE, and an evolved packet core (EPC), but the main points of the present invention are similar.
  • Other communication systems having a technical background may be applied in a slight modification without departing from the scope of the present invention, which may be determined by those skilled in the art.
  • a term referring to control information used in the following description a term meaning user data transmitted to an application server, a term meaning signaling for transmitting control information between network devices, and a configuration of a device. Terms and the like that refer to the elements are illustrated for convenience of description. Therefore, the present invention is not limited to the terms described below, and other terms having equivalent technical meanings may be used.
  • 3GPP LTE 3rd Generation Partnership Project Long Term Evolution
  • the present invention is not limited to the above terms and names, and may be equally applied to systems conforming to other standards.
  • LTE terminal and IoT terminal to be described below refers to a mobile terminal capable of wireless communication, for example a personal digital assistant (Personal Digital Assistant: PDA), a smart phone (Smart Phone), a mobile phone, a tablet having a communication function (tablet) It can be a computer, a laptop, etc.
  • PDA Personal Digital Assistant
  • Smart Phone Smart Phone
  • a terminal that checks and reports water consumption, electricity consumption, temperature, fire alarm, earthquake alarm, etc., and reports, air conditioner, refrigerator, air cleaner, boiler It may mean a home appliance having a communication function such as a cleaner. All communicable objects other than those mentioned above will be referred to as IoT terminals in the present invention.
  • a terminal using a cellular network among IoT terminals will be referred to as a CIoT terminal.
  • the CIoT terminal may refer to a terminal for transmitting a small amount of data in the LTE network.
  • Device, function, and operation for CIoT service of the present invention include device, function, and operation for Small Data Transmission in LTE network.
  • IoT data may refer to data sent by an IoT terminal or data of a small capacity sent by a terminal of some kind.
  • FIG. 36 is a diagram illustrating a network architecture that supports a cellular IoT (CIoT) service according to the seventh embodiment of the present invention.
  • CCIoT cellular IoT
  • a CIoT dedicated base station may exist in a network to support a CIoT service, and a base station in which a CIoT function is added to an existing base station may exist.
  • a CIoT dedicated base station and a base station in which a CIoT function is added to an existing base station will be referred to as a CIoT RAN 3620 for convenience.
  • Core Network existing in Cellular network can exist for CIoT only. In the present invention, this will be referred to as a CIoT CN Node (Core Network Node, 3630), and is currently called C-SGN in 3GPP, but is not limited to the term in the present invention, other terms having equivalent technical meanings may be used.
  • the CIoT CN Node 3630 may deliver the terminal data to the application server 3640 or the data received from the application server 3640 as well as the context management, mobility management, and signaling session management of the CIoT terminal 3600. . That is, the CIoT CN Node 3630 may provide a gateway function to the CIoT terminal 3600 and may serve as an S-GW / P-GW that receives data and routes the data to the Application Sever 3640.
  • the CIoT CN Node 3630 may establish a Control Plane connection with the CIoT terminal 3600 and may not establish a User Plane connection.
  • the CIoT CN Node 3630 may transmit CIoT data or data having a small capacity to the Control Plane.
  • CIoT traffic may have low data rate, small capacity, delay tolerant, periodic / aperiodic and response need / unnecessity. More specifically, in case of data traffic for event report such as smoke alarm, failure alarm, low power alarm, temperature alarm, small amount of data is sent only to Uplink, no response is required, and traffic does not occur all the time. There is a characteristic that occurs. Since the traffic may be used in IoT services related to public safety, the traffic may have a higher priority than other data traffic. In the case of data traffic that performs periodic reports such as gas usage measurement, water usage measurement, and electricity usage measurement, small volume data is sent to Uplink, and the results of the measurement report can be answered, and minutes / hours / days / months / years are received.
  • event report such as smoke alarm, failure alarm, low power alarm, temperature alarm
  • small amount of data is sent only to Uplink, no response is required, and traffic does not occur all the time. There is a characteristic that occurs. Since the traffic may be used in IoT services related
  • the CIoT terminal 3600 since the CIoT terminal 3600 should perform a command or receive a command, if the data is not transmitted within a predetermined time, device triggering may take a long time and may impair IoT service quality. May need to be processed.
  • data traffic for IoT / software update, setting value update, etc. a relatively large capacity can be used as uplink and downlink, which is relatively intermittent data traffic.
  • the data traffic may be used to update security related information or update configuration of IoT devices added in the IoT proximity network.
  • FIG. 37 is a view illustrating an operation for transmitting control plane data between an CIoT terminal and a CIoT RAN and an operation for each inner layer according to Embodiment 7-1 of the present invention.
  • the part related to the proposal of the seventh embodiment transmits the RRC establishment cause and the call type for CIoT as an indication when the NAS layer requests NAS signaling connection to the RRC layer.
  • the RRC message is transmitted to the corresponding SRB by selecting the SRB for the RRC establishment causen (whether or not performing the access control with the Call type for CIoT).
  • an NAS layer In general LTE operation, an NAS layer (Also known as EMM layer) requests an RRC connection (called a NAS signaling connection) for delivering a NAS message to the RRC layer.
  • the NAS layer delivers the RRC establishment Cause and Call Type to the RRC layer.
  • the RRC establishment cause is to identify the reason why the RRC connection is requested in the RRC layer in the RRC message.
  • Call Type is to classify connection request type to perform Access Control in RRC layer.
  • the RRC layer determines whether to transmit to SRB or DRB, to which logical channel to send, and to what access control to perform according to call type.
  • Access control is a function for controlling congestion of radio resources.
  • the CIoT UE 3700 When the CIoT UE 3700 is in the IDLE state and needs to send User Data for CIoT, the CIoT UE 3700 requests an RRC connection to the RRC layer. Since the CIoT UE 3700 according to the present invention sends User Data for CIoT in a NAS message, the CIoT UE 3700 requests an RRC connection from the NAS layer to the RRC layer.
  • the NAS layer delivers a NAS message using a NAS procedure, and transmits an RRC connection establishment Cause and a call type to the RRC layer when the NAS message is sent.
  • the NAS layer newly defines the RRC connection establishment cause and call type for CIoT, and proposes an RRC operation accordingly.
  • the RRC layer decides whether an RRC connection is necessary because of user data for CIoT, and determines to perform access control based on call type. Subsequent operations are described elsewhere.
  • the NAS layer defines a new RRC establishment cause, meaning that it is a Mobile Originated (MO) Data for CIoT or Moblie Terminated (MT) Data for CIoT as the NAS signaling connection is needed to send User Data for CIoT.
  • Mobile Originated means that there is data to be sent from the CIoT terminal 3700 to the network
  • Mobile Terminated means that there is data to be transmitted from the network by the CIoT terminal 3700.
  • Data for CIoT includes the meaning Small Data.
  • the name may be MO small data, MT small data, or MO CIoT Data, MT CIoT Data, and the like, and is not limited to the name, and includes all RRC establishment cause values associated with user data used for CIoT.
  • the RRC establishment cause is included as a parameter in the RRC message.
  • the RRC layer that receives the RRC establishment cause from the NAS layer may determine that the RRC connection request is due to CIoT data.
  • the operation of the RRC layer determined this is covered in another part of the present invention.
  • the NAS layer delivers the call type to the RRC layer along with the RRC establishment cause.
  • Call type is originating signaling (connection request for sending control plane data), originating call (connection request for sending user plane data), terminating call (user plane data) Whether the connection request for receiving a) or emergency call (connection request for emergency services).
  • a call type for a connection request for transmitting user data for CIoT or a connection request for receiving user data for CIoT is newly defined. That is, call type called Originating CIoT Data or Terminating CIoT Data can be defined. Call type called Originating CIoT Data is a call type indicating the connection request for transmitting user data for CIoT.
  • Terminating CIoT Data is a call type indicating the connection request for receiving user data for CIoT.
  • Each call type can be called Originating CIoT call or Terminating CIoT call.
  • the new call type may be referred to as a call type used when making an RRC connection request to transmit or receive CIoT data or small data, without being limited to a name.
  • the NAS layer delivers the above-described RRC Establishment Cause for CIoT User Data transmission and a Call Type indicating a connection for CIoT to the RRC layer.
  • the RRC layer may perform access control for the call type, which will be covered in another part of the present invention.
  • RRC layer receiving the indication may determine that the corresponding RRC connection request is a connection request due to CIoT data. The behavior of the RRC layer is covered elsewhere.
  • the RRC layer uses the received call type for access control according to the existing system method.
  • RRC establishment cause uses the previously defined value and newly defines Call type for CIoT.
  • RRC Establishment Cause is set to MO data or MT data.
  • Call type uses the type suggested in 1.
  • the RRC Layer performs access control for the call type.
  • the RRC establishment cause uses the existing MO data or MT data, the RRC layer can determine that the call type is for the CIoT and is an RRC connection request for transmitting user data for the CIoT.
  • the RRC layer may determine that the RRC connection request from the NAS layer is due to user data for CIoT.
  • User data for CIoT is contained in a NAS message, and the NAS layer delivers the NAS message associated with the indication together with the RRC establishment cause and call type to the RRC layer.
  • the RRC layer may determine the proposed RRC establishment cause and call type that the received NAS message contains User Data for CIoT.
  • the RRC layer includes the NAS message in an RRC message. That is, the RRC message includes a NAS message, and the NAS message includes User data for CIoT.
  • the RRC layer uses a Signaling Radio Bearer (SRB) to deliver NAS messages.
  • SRBs include SRB 0, SRB 1, and SRB 2.
  • NAS messages are forwarded to SRB 1 or SRB 2.
  • the NAS message for the procedure may be delivered to SRB 1 to piggyback the RRC message.
  • NAS messages are forwarded to SRB 2.
  • the NAS layer may piggyback User Data for CIoT into an RRC control message in a NAS message by an EMM procedure.
  • a user request for CIoT is included in a Service Request message (NAS message) and piggybacked to an RRC control message for transmission.
  • the RRC control message can piggyback the initial NAS message.
  • the present invention describes the processing when the user data for the CIoT is present despite the initial NAS message.
  • the NAS layer corresponds to the RRC layer.
  • RRC establishment Cause or Call type may indicate that the message contains User Data for CIoT.
  • the RRC layer may decide not to piggyback the NAS message to the RRC control message and to deliver it to SRB 1, but to SRB 2 because it is user data for CIoT.
  • SRB 2 has a lower priority than SRB 1. Therefore, the existing control data transmitted through SRB 1 may have a higher priority than the user data sent by the CIoT terminal.
  • the user data sent by the CIoT terminal may be piggybacked in the RRC control message and delivered to the SRB 1 in the NAS message. This means that Control Data and CIoT User Data sent by other terminals are recognized as signaling having the same priority, and the present invention is utilized to distinguish them.
  • the RRC layer delivers the RRC message containing the NAS message containing the user data for CIoT by using SRB 2, but in order to distinguish it from other NAS messages containing the control data, the RRC establishment cause or call type according to the present invention. Can be used.
  • the NAS message containing the CIoT user data may be determined to have a lower priority than other NAS messages, and priority processing may be applied when sending a message to SRB2.
  • the RRC layer may newly define SRB 3 having the lowest priority and transmit a NAS message containing user data for CIoT through SRB 3.
  • SRB 3 may be a newly defined SRB having the lowest priority, and may mean a radio bearer for transmitting CIoT related data or a radio bearer for transmitting small data.
  • the RRC layer may not apply AS security to an RRC message that delivers a NAS message related to the RRC establishment cause or call type.
  • AS security is always applied to SRB 1 and SRB 2 after AS (Access Stratum) security between the terminal and the base station is activated.
  • AS security means applying integrity protection and encrypting the RRC message.
  • the CIoT terminal according to the present invention transmits CIoT User Data as a NAS message, and may apply omission of AS security since NAS security is applied, and AS security is already activated by determining this in the RRC layer. AS security may not be applied even though NAS messages are sent via 1 or SRB 2.
  • the RRC layer may apply another access control to an RRC connection request for transmitting user data for CIoT.
  • the RRC layer of the terminal receives the information on the Access Control by viewing the SIB information broadcast by the base station.
  • Information about the Access Control is included in the SIB as a field called ac-BarringInfo, and appears as ac-BarringForMO-Data or ac-BarringFor-MO-Signalling. This information consists of information called ac-BarringConfig.
  • the existing RRC recognizes this as MO signaling and applies ac-BarringForMO-signaling.
  • the barring factor for signaling is set to access with a higher probability than the barring factor for data, the barring factor for signaling can be applied even though the user data for CIoT is transmitted.
  • the present invention proposes the following operation.
  • the RRC layer receives the call type while receiving an RRC connection request from the NAS layer. If the call type is a call type for CIoT data transfer, the RRC layer applies a factor for ac-BarringForMO-data despite the NAS message transfer for the corresponding RRC connection.
  • ac-barring information about CIoT may be included in SIB information broadcasted by a base station. For example, it could be ac-BarringForCIoT, or ac-BarringForCIoT-data / ac-BarringForCIoT-signaling.
  • One barring factor may be applied to all CIoT related items, or a barring factor may be applied to CIoT data or to CIoT signaling separately.
  • the terminal may perform access control for the CIoT according to the ac-barring information for the CIoT included in the SIB.
  • 38 is a diagram illustrating an operation of transmitting an RRC connection request message between a CIoT terminal and a CIoT RAN according to embodiment 7-1 of the present invention.
  • the CIoT RAN 3810 transmits an SIB broadcast to the CIoT terminal 3800 together with access barring information for the CIoT (3802).
  • the CIoT terminal 3800 may determine whether an RRC connection request for the CIoT is requested (3804).
  • the CIoT terminal 3800 When the RRC connection request for the CIoT is requested, the CIoT terminal 3800 performs an access barring check (3805). The CIoT terminal 3800 determines whether the access is barring (3806), and performs an RRC connection establishment (3807). Thereafter, the CIoT terminal 3800 transmits an RRC Connection Request to the CIoT RAN 3810 (3808).
  • the CIoT CN Node shall be able to transfer CIoT User data received to the Control plane to the P-GW via a User plane interface called GTP-U.
  • the NAS message is transmitted to the control plane, but according to the present invention, since the CIoT user data is contained in the NAS message, the NAS message must be distinguished and transmitted to the P-GW through the GTP-U. Therefore, we suggest a way to distinguish them.
  • 39 shows an example of a NAS message according to embodiment 7-2 of the present invention.
  • an indication 3900 is added to the header of the NAS PDU 3920.
  • the indication 3900 distinguishes whether the corresponding NAS PDU 3920 is Control Data or User Data.
  • the indication 3900 may be in a format having one value of control data / user data, may be in a format of referring to only one user data, or may be a single value indicating that small data transmission is used. That is, it is not limited to a form or a name, and means an entire identifier for distinguishing control data from user data in the CIoT CN Node.
  • the header of the NAS PDU 3920 proposed in FIG. 39 may include a NAS security indication 3910. Since the NAS PDU 3920 is integrity protected and encrypted as a NAS security material, a key index value indicating which key is integrity protected / encrypted may be included. The key index can be used to indicate EIA or EEA which algorithm is used. (EIA: Integrity Algorithm, EEA: Encryption Algorithm)
  • An indication indicating that the user data for the CIoT is used in the Initial UE message that the CIoT RAN sends to the CIoT CN Node.
  • an indication indicating that the CIoT RAN is User Data for CIoT is used in the Uplink NAS Transport that is sent to the CIoT CN Node.
  • the messages are all delivered at the interface between the CIoT RAN and the CIoT CN Node.
  • the CIoT RAN uses an Initial UE message or Uplink NAS Transport message to transmit the NAS message of the UE to the CIoT CN Node.
  • the RRC Establishment Cause included in the Initial UE message includes the RRC Establishment Cause, which means to send User Data for CIoT as described in the above.
  • the CIoT CN Node receiving this may determine that the corresponding NAS message is User Data for CIoT.
  • Uplink NAS Transport In case of using Uplink NAS Transport, it indicates User data for CIoT using newly defined Message Type.
  • the message delivered through the interface between the CIoT RAN and the CIoT CN Node has a file type called Message type, and a new type called Message for transmitting User Data for CIoT can be defined in the Information element called Type of Message in this field. .
  • the message delivered through the interface between the CIoT RAN and the CIoT CN Node has a filed called message type, and a new type called Message for transmitting User Data for CIoT is defined in the Information element called Type of Message in this field.
  • the message transmitted through the interface between the CIoT RAN and the CIoT CN Node may indicate that the message is for transmitting User Data for CIoT.
  • the CIoT CN Node distinguishes whether the NAS message sent by the CIoT terminal is control data or user data and transmits it to the P-GW through GTP-C in case of control data, and GTP in case of user data. Transmit to P-GW via -U.
  • the CIoT CN Node can transmit to the P-GW through the S-GW without directly transmitting to the P-GW. (MME is currently implemented that way)
  • traffic transmitted by a CIoT terminal may be classified into two types.
  • the first case is when ACK is required for data transmitted by the terminal, and the second case is when no ACK is required for data transmitted by the terminal.
  • the CIoT terminal and the CIoT RAN may receive an ACK by maintaining an RRC connection for a predetermined period. If the RRC connection is disconnected before receiving the ACK, the RRC signaling is generated to establish the RRC connection again, so that the RRC connection with the CIoT terminal that sent the data requiring the ACK is maintained for a predetermined time to reduce unnecessary procedures. can do.
  • the CIoT terminal and the CIoT RAN can be released immediately without having to maintain the RRC connection. Since the CIoT terminal assumes intermittent small data transmission (Infrequent Small Data Transmission), if the data does not need ACK, the RRC connection can be released immediately to secure available radio resources.
  • intermittent small data transmission Infrequent Small Data Transmission
  • the RRC establishment cause indicates whether the corresponding RRC connection request is due to data transmission requiring ACK or data transmission without ACK.
  • This is not limited to the name CIoT in the same way as small data transmission with / without ACK, and may include a meaning of an RRC connection request for small data transmission.
  • the CIoT terminal when the CIoT terminal requests an RRC connection to the CIoT RAN, the CIoT terminal distinguishes and requests an RRC mode.
  • the names for the two modes can vary. For example, maintaining a connection for a certain period of time may be the default or normal mode, and immediately disconnecting the RRC connection (going to RRC IDLE) may be the default or normal mode.
  • the mode proposed in the present invention includes both a mode including an operation of maintaining the RRC connection for a predetermined time, and a mode including an operation of immediately releasing the RRC connection.
  • indications can be added to NAS PDUs. This is to let the CIoT CN Node know the RRC connection hold / release operation.
  • FIG. 40 shows another example of a NAS message according to embodiment 7-2 of the present invention.
  • an Indication (Control Data / User data) 4000 and a NAS security indication 4010 follow another example of the present invention.
  • an Acknowledge indication 4020 may be added to the NAS PDU 4030 to determine whether the CIoT CN Node receiving the NAS message requires the ACK to the CIoT terminal that sent the NAS message.
  • the signaling may include an identifier for identifying a CIoT terminal, for example, IMSI.
  • the basic operation of the CIoT terminal is to transmit small data intermittently, but there may be a case where continuous small data needs to be transmitted for software update or continuous data reporting.
  • large data such as software update can be divided into multiple NAS messages to send or receive, or multiple different CIoT User Data can be sent or received in different NAS messages.
  • the CIoT RAN or CIoT CN Node recognizes that there is continuous uplink or downlink traffic as described above, so as to maintain radio resources for a certain time or release radio resources to secure available radio resources.
  • the RRC connection mode can be distinguished as connection maintenance or immediate release. This method is the same as the method of another embodiment of the present invention.
  • the UE may make an RRC release request to the CIoT RAN in an RRC message. (Currently, only the base station commands the release to the UE) CIoT RAN may release the RRC connection.
  • the CIoT terminal may transmit a request to release the RRC connection to the CIoT RAN.
  • This RRC Connection release request message from CIoT UE includes a cause value for the reason for releasing, and this cause value may indicate that all transmissions are completed.
  • the CIoT RAN receiving this may release the RRC connection by transmitting an RRC Connection Release to the UE.
  • 41 and 42 may add an indication to the header of the NAS PDU to let the CIoT CN Node know that there will be continuous data transmission.
  • it can be configured as follows.
  • FIG. 41 illustrates a method of informing a segmentation offset 4110 of a current NAS PDU relative to the total segmentation length after segmenting a large amount of data. For example, it is a large amount of data divided into 100 segments, and the 58th segmentation indicates 58 at the segment offset.
  • the CIoT CN Node determines that there will no longer be continuous transmission and informs the CIoT RAN that the RRC connection may be released, or CIoT Available resources can be secured by releasing the user plane connection (GTP-U connection with P-GW, Tunneling connection with Application Server, etc.) for the UE.
  • the user plane connection GTP-U connection with P-GW, Tunneling connection with Application Server, etc.
  • the CIoT CN Node determines that there will be more consecutive transmissions and the CIoT RAN operates to maintain the RRC connection, or the user plane for the CIoT UE. It can be operated to maintain more connections (GTP-U connection with P-GW, Tunneling connection with Application Server, etc.).
  • the NAS security indication of the first and second examples is the same as described in other parts of the present invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Technology Law (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

본 개시는 4G 시스템 이후 보다 높은 데이터 전송률을 지원하기 위한 5G 통신 시스템을 IoT 기술과 융합하는 통신 기법 및 그 시스템에 관한 것이다. 본 개시는 5G 통신 기술 및 IoT 관련 기술을 기반으로 지능형 서비스 (예를 들어, 스마트 홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 헬스 케어, 디지털 교육, 소매업, 보안 및 안전 관련 서비스 등)에 적용될 수 있다. 보다 구체적으로 본 발명의 이동 통신 시스템에서 릴레이 단말(relay user equipment(UE))의 동작 방법은, 릴레이 단말을 통해 네트워크에 접속하는 리모트 단말(remote UE)에 대한 리모트 단말 정보를 포함하는 리모트 단말 보고 메시지를 상기 릴레이 단말에 연결되는 MME(mobility management entity)로 전송하는 단계; 및 상기 리모트 단말 보고 메시지에 상응하는 응답 메시지를 상기 MME로부터 수신하는 단계를 포함한다.

Description

리모트 프로세(REMOTE PROSE) 단말에 대한 네트워크 망에서의 합법적 감청 지원 방안
본 발명은 프로세 단말(ProSe UE)-네트워크 릴레이(Network Relay)를 통해서네트워크 망에 접속하는 리모트 단말(remote UE)에 대한 합법적 감청(Lawful Interception)을지원하기 위한 방법에 관한 것이다.
4G 통신 시스템 상용화 이후 증가 추세에 있는 무선 데이터 트래픽 수요를 충족시키기 위해, 개선된 5G 통신 시스템 또는pre-5G 통신 시스템을개발하기 위한 노력이 이루어지고 있다. 이러한 이유로, 5G 통신 시스템 또는pre-5G 통신 시스템은 4G 네트워크 이후 (Beyond 4G Network) 통신 시스템 또는 LTE 시스템 이후 (Post LTE) 이후의 시스템이라 불리어지고 있다. 높은 데이터 전송률을 달성하기 위해, 5G 통신 시스템은 초고주파(mmWave) 대역 (예를 들어, 60기가(60GHz) 대역과 같은)에서의 구현이 고려되고 있다. 초고주파 대역에서의 전파의 경로손실 완화 및 전파의 전달 거리를 증가시키기 위해, 5G 통신 시스템에서는 빔포밍(beamforming), 거대 배열 다중 입출력(massive MIMO), 전차원 다중입출력(Full Dimensional MIMO: FD-MIMO), 어레이 안테나(array antenna), 아날로그 빔형성(analog beam-forming), 및 대규모 안테나 (large scale antenna) 기술들이 논의되고 있다. 또한 시스템의 네트워크 개선을 위해, 5G 통신 시스템에서는 진화된 소형 셀, 개선된 소형 셀 (advanced small cell), 클라우드 무선 액세스 네트워크 (cloud radio access network: cloud RAN), 초고밀도 네트워크 (ultra-dense network), 기기간 통신 (Device to Device communication: D2D), 무선 백홀 (wireless backhaul), 이동 네트워크 (moving network), 협력 통신 (cooperative communication), CoMP (Coordinated Multi-Points), 및 수신간섭제거 (interference cancellation) 등의 기술 개발이 이루어지고 있다. 이 밖에도, 5G 시스템에서는 진보된코딩 변조(Advanced Coding Modulation: ACM) 방식인 FQAM (Hybrid FSK and QAM Modulation) 및 SWSC (Sliding Window Superposition Coding)과, 진보된 접속 기술인 FBMC(Filter Bank Multi Carrier), NOMA(non orthogonal multiple access), 및SCMA(sparse code multiple access) 등이 개발되고 있다.
한편, 인터넷은 인간이 정보를 생성하고 소비하는 인간 중심의 연결 망에서, 사물 등 분산된 구성 요소들 간에 정보를 주고 받아 처리하는 IoT(Internet of Things, 사물인터넷) 망으로 진화하고 있다. 클라우드 서버 등과의 연결을 통한 빅데이터(Big data) 처리 기술 등이 IoT 기술에 결합된 IoE (Internet of Everything) 기술도 대두되고 있다. IoT를 구현하기 위해서, 센싱 기술, 유무선 통신 및 네트워크 인프라, 서비스 인터페이스 기술, 및 보안 기술과 같은 기술 요소 들이 요구되어, 최근에는 사물간의 연결을 위한 센서 네트워크(sensor network), 사물 통신(Machine to Machine, M2M), MTC(Machine Type Communication)등의 기술이 연구되고 있다.IoT 환경에서는 연결된 사물들에서 생성된 데이터를 수집, 분석하여 인간의 삶에 새로운 가치를 창출하는 지능형 IT(Internet Technology) 서비스가 제공될 수 있다. IoT는 기존의 IT(information technology)기술과 다양한 산업 간의 융합 및 복합을 통하여 스마트홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 스마트 그리드, 헬스 케어, 스마트 가전, 첨단의료서비스 등의 분야에 응용될 수 있다.
이에, 5G 통신 시스템을 IoT 망에 적용하기 위한 다양한 시도들이 이루어지고 있다. 예를 들어, 센서 네트워크(sensor network), 사물 통신(Machine to Machine, M2M), MTC(Machine Type Communication)등의 기술이 5G 통신 기술이 빔 포밍, MIMO, 및 어레이 안테나 등의 기법에 의해 구현되고 있는 것이다. 앞서 설명한 빅데이터 처리 기술로써 클라우드 무선 액세스 네트워크(cloud RAN)가 적용되는 것도 5G 기술과 IoT 기술 융합의 일 예라고 할 수 있을 것이다.
상기와 같이, 무선 데이터 트래픽 수요를 충족시키기 위해다양한 분야에서 통신 방법을 발전시키기 위한 논의가 진행 중이다. 예를 들어, 단말간 단말 통신, 복수 개의 셀을 운용하는 주파수 집적 시스템, 대규모 안테나를 사용하는 다중 안테나 시스템 등이 그것이다.
본 발명은 프로세 단말(ProSe UE)-네트워크 릴레이(Network Relay)를 통해서네트워크 망에 접속하는 리모트 단말(remote UE)에 대한 합법적 감청(Lawful Interception)을 지원하는 것을 목적으로 한다.
또한, 본 발명은 Cellular IoT (CIoT) 네트워크 구조에서 작은 크기의 메시지를 전달하는 방법을 제공하는 것을 목적으로 한다.
또한, 본 발명은 그룹 통신의 품질을 관리하는 방법을 제공하는 것을 목적으로 한다.
또한, 본 발명은 이동 통신 사업자 망과 응용 서버에 등록하는 방법을 제공하는 것을 목적으로 한다.
또한, 본 발명은 효율적인 방송 관련 시그널링 전달 방법을 제공하는 것을 목적으로 한다.
또한, 본 발명은 재난 안전망 용 호 연결 방법을 제공하는 것을 목적으로 한다.
또한, 본 발명은 Cellular IoT 서비스를 위한 시그널링과 연결 모드 구별 방법을 제공하는 것을 목적으로 한다.
상기와 같은 문제점을 해결하기 위한 본 발명의 이동 통신 시스템에서 릴레이 단말(relay user equipment(UE))의 동작 방법은, 릴레이 단말을 통해 네트워크에 접속하는 리모트 단말(remote UE)에 대한 리모트 단말 정보를 포함하는 리모트 단말 보고 메시지를 상기 릴레이 단말에 연결되는 MME(mobility management entity)로 전송하는 단계와, 상기 리모트 단말 보고 메시지에 상응하는 응답 메시지를 상기 MME로부터 수신하는 단계를 포함한다.
상기 리모트 단말 정보는, 상기 리모트 단말에 할당된 IP 주소(address) 정보, 및 상기 리모트 단말에 대한 사용자 정보를 포함한다.
IPv6 (internet protocol version 6)를 사용하는 경우, 상기 IP 주소 정보는 상기 리모트 단말에 대한 IP 주소 또는 IPv6 프리픽스(prefix) 정보이고, IPv4 (internet protocol version 4)를 사용하는 경우, 상기 IP 주소 정보는 상기 리모트 단말에 대한 IP 주소 및 포트 정보일 수 있다.
상기 사용자 정보는, IMSI (International Mobile Subscriber Identity), MSISDN (mobile subscriber integrated services digital network number), SIP (session initiation protocol) URI (uniform resource identifier), 및 ProSe (proximity-based service) 용 사용자 정보 중에서 적어도 하나일 수 있다.
상기 릴레이 단말의 동작 방법은 상기 리모트 단말 보고 메시지를 상기 MME로 전송하며 타이머를 구동하는 단계와, 상기 응답 메시지를 상기 MME로부터 수신하며 상기 타이머의 구동을 중단하는 단계를 더 포함할 수 있다.
상기 리모트 단말 보고 메시지는, 상기 릴레이 단말이 상기 리모트 단말을 릴레이(relay)하기 위해 사용하는 PDN (packet data network) 연결에 대한 제어 메시지일 수 있다.
본 발명의 실시예에 따른 이동 통신 시스템에서 MME(mobility management entity)의 동작 방법은, 릴레이 단말(relay user equipment(UE))을 통해 네트워크에 접속하는 리모트 단말(remote UE)에 대한 리모트 단말 정보를 포함하는 리모트 단말 보고 메시지를 상기 릴레이 단말로부터 수신하는 단계와, 상기 리모트 단말 보고 메시지에 상응하는 응답 메시지를 상기 릴레이 단말로 전송하는 단계를 포함한다.
본 발명의 실시예에 따른 이동 통신 시스템에서 동작하는 릴레이 단말(relay user equipment(UE))은, 신호를 송수신하는 송수신부, 및 릴레이 단말을 통해 네트워크에 접속하는 리모트 단말(remote UE)에 대한 리모트 단말 정보를 포함하는 리모트 단말 보고 메시지를 상기 릴레이 단말에 연결되는 MME(mobility management entity)로 전송하고, 상기 리모트 단말 보고 메시지에 상응하는 응답 메시지를 상기 MME로부터 수신하도록 제어하는 제어부를 포함한다.
본 발명의 실시예에 따른 이동 통신 시스템에서 동작하는 MME(mobility management entity)는, 신호를 송수신하는 송수신부, 및 릴레이 단말(relay user equipment(UE))을 통해 네트워크에 접속하는 리모트 단말(remote UE)에 대한 리모트 단말 정보를 포함하는 리모트 단말 보고 메시지를 상기 릴레이 단말로부터 수신하고, 상기 리모트 단말 보고 메시지에 상응하는 응답 메시지를 상기 릴레이 단말로 전송하도록 제어하는 제어부를 포함한다.
본 발명의 일 실시예에 따른 방법 및 장치는 네트워크 망에서 릴레이 단말을 통해 합법적 감청을 효과적으로 지원할 수 있다.
또한, 본 발명의 일 실시예에 따른 방법 및 장치는 Cellular IoT (CIoT) 네트워크 구조에서 작은 크기의 메시지를 전달할 수 있다.
또한, 본 발명의 일 실시예에 따른 방법 및 장치는 그룹 통신의 품질을 관리할 수 있다.
또한, 본 발명은 일 실시예에 따른 방법 및 장치는 이동 통신 사업자 망과 응용 서버에 등록할 수 있다.
또한, 본 발명의 일 실시예에 따른 방법 및 장치는 효율적인 방송 관련 시그널링 전달 방법을 제공할 수 있다.
또한, 본 발명의 일 실시예에 따른 방법 및 장치는 재난 안전망 용 호 연결 방법을 제공할 수 있다.
또한, 본 발명의 일 실시예에 따른 방법 및 장치는 Cellular IoT 서비스를 위한 시그널링과 연결 모드 구별 방법을 제공할 수 있다.
도1 은 본 발명의 제1 실시예에 따른프로세(ProSe) 망 구조를 도시한 도면이다.
도2는 본 발명의 제1 실시예에 따른릴레이 단말(relay UE)이리모트 단말(remote UE)에 대한 합법적 감청(Lawful Interception) 정보를 네트워크 망에 전달하는 과정을 나타내는 흐름도이다.
도3은 본 발명의 제1 실시예에 따른리모트 단말(remote UE)과의 접속이 끊어졌음을 네트워크 망에 전달하는 과정을 나타내는 흐름도이다.
도4는 본 발명의 제1 실시예에 따른릴레이 단말(relay UE)이리모트 단말(remote UE)에 대한 합법적 감청(Lawful Interception) 정보를 네트워크 망에 전달하는 과정을 나타내는 흐름도이다.
도5는 본 발명의 제1 실시예에 따른리모트 단말(remote UE)과의 접속이 끊어졌음을 네트워크 망에 전달하는 과정을 나타내는 흐름도이다.
도 6 은 본 발명의 제2 실시예에 따른 Cellular IoT (CIoT)네트워크 구조를 나타내는 도면이다.
도 7은 본 발명의 제2 실시예에 따라 단말이 보내고자 하는 상향 non-IP 데이터를 MME와 SCEF를 통하여 전송하는 절차를 나타낸다.
도 8은 본 발명의 제2 실시예에 따라 단말이 로밍 중인 경우 non-IP데이터를 전송하는 절차를 나타낸다.
도 9는 작은 데이터 전송(SDT: Small Data Transmission)을 설정하거나 설정을 해제하는 방법을 나타낸다.
도 10은 서버가 단말에게 보내는 non-IP 데이터 전송 절차(Mobile terminated small data transmission procedure)에 관한 것이다.
도 11 은 재난안전망 시스템으로 일컬어지는 MCPTT 서비스와, 이를 EPS와 연동하기 위해 사용되는 SIP Core, 그리고 EPS 및 단말의 구조를 나타낸다.
도 12 는 본 발명의 제4-1 실시예에 따라 이동 통신 사업자 망과 응용 서버에 등록하는 방법을 나타낸는 도면이다.
도 13은 본 발명의 제4-2 실시예에 따라 이동 통신 사업자 망과 응용 서버에 등록하는 방법을 나타낸는 도면이다.
도 14는 본 발명의 제4-3 실시예에 따라 이동 통신 사업자 망과 응용 서버에 등록하는 방법을 나타낸는 도면이다
도 15는 본 발명의 제4-4 실시예에 따른 MCPTT UE 인증을 위한 IMS AKA 인증 절차를 MCPTT UE와 SIP Core(혹은 IMS) 사이에 수행하는 것을 나타낸 도면이다.
도 16은 본 발명의 제4-5 실시예에 따른 MCPTT UE 인증을 위한 IMS AKA 인증 절차를 MCPTT UE와 SIP Core(혹은 IMS) 사이에 수행하는 것을 나타낸 도면이다.
도 17은 본 발명의 제4-6 실시예에 따른 MCPTT UE 인증을 위한 IMS AKA 인증 절차를 MCPTT UE와 SIP Core(혹은 IMS) 사이에 수행하는 것을 나타낸 도면이다.
도 18은 본 발명의 제4-7 실시예에 따른 MCPTT UE 인증을 위한 IMS AKA 인증 절차를 MCPTT UE와 SIP Core(혹은 IMS) 사이에 수행하는 것을 나타낸 도면이다.
도 19는 본 발명의 제4-8 실시예에 따른 IMS Registraion을 시도하면 S-CSCF가 3rd party registration을 시도하는 것을 나타낸 도면이다.
도 20은 본 발명의 제4-9 실시예에 따른 암호화 없이, Registration 메시지에 MCPTT User ID를 포함하지 않는 경우를 나타낸다.
도 21은 본 발명의 제4-10 실시예에 따른 MCPTT 인증 과정을 설명하기 위한 도면이다.
도 22는 본 발명의 제4-11 실시예에 따른 MCPTT 사용자 인증 절차를 설명하기 위한 도면이다.
도 23 은 본 발명의 제5 실시예에 따른 방송 관련 시그널링 전달 방법을 설명하는 도면이다.
도 24는 본 발명의 제5 실시예에 따른 복수의 MCE들에 의해 운영되는 MBSFN 영역에 관한 도면이다.
도 25는 본 발명의 제5 실시예에 따른 동적 조정 MBMS 세션 개시 절차를 설명하는 도면이다.
도 26은 본 발명의 제5 실시예에 따른 정적 조정 MBMS 세션 개시 절차를 설명하는 도면이다.
도 27은 본 발명의 제5 실시예에 따른 기지국과 MME 간 S1 셋업 요청을 설명하는 도면이다.
도 28은 본 발명의 제5 실시예에 따른 기지국과 MME 간 기지국 설정 업데이트를 설명하는 도면이다.
도 29는 본 발명의 제5 실시예에 따른 MCE와 MME간 S3 셋업 요청을 설명하는 도면이다.
도 30은 본 발명의 제5 실시예에 따른 MCE와 MME간 MCE 설정 업데이트를 설명하는 도면이다.
도 31 은 본 발명의 제6 실시예에 따른 MCPTT 단말이 MME에 MCPTT용 Service Request를 요청하고 MME가 그에 대한 Bearer Context를 변경하여 설정하는 방법 및 절차를 나타내는 도면이다.
도 32는 본 발명의 제6실시예에 따른 MCPTT 단말이 MME에 MCPTT용 Service Request를 요청하고 MME가 그에 대한 Second Bearer context를 활성화하는 방법 및 절차를 나타내는 도면이다.
도 33은 본 발명의 제6 실시예에 따른 MCPTT 단말이 MCPTT 서비스를 수행하기 위한 paging을 수신하기 위하여 EPS 장치에서 우선순위로 처리되는 절차 및 단말이 MCPTT 서비스에 대한 Bearer 연결을 수립하는 절차를 나타내는 도면이다.
도 34는 본 발명의 제6 실시예에 따른 MCPTT 단말이 MCPTT 서비스를 수행하기 위한 paging을 수신하기 위하여 EPS 장치에서 우선순위로 처리되는 절차 및 단말이 MCPTT 서비스에 대한 우선순위 Bearer 연결을 수립하는 절차를 나타낸다.
도 35는 본 발명의 제6 실시예에 따른 MCPTT 단말이 EPS 네트워크에 Attach 할 때, MCPTT 단말임을 알리는 방법 및 MCPTT 서비스를 이용하기 위함을 알려서 Bearer 연결을 수립하는 방법 및 절차를 나타내는 도면이다.
도 36 은 본 발명의 제7 실시예에 따른 Cellular IoT(CIoT) 서비스를 지원하는 네트워크 아키텍쳐(architecture)를 나타내는 도면이다.
도 37은 본 발명의 제7-1 실시예에 따른 CIoT 단말과 CIoT RAN 사이에 Control plane 데이터를 전달하는 동작 및 내부 layer 별 동작을 나타낸 도면이다.
도 38은 본 발명의 제7-1 실시예에 따른 CIoT 단말과 CIoT RAN 사이에 RRC 연결 요청 메시지를 전달하는 동작을 나타낸 도면이다.
도 39는 본 발명의 제7-2 실시예에 따른 NAS 메시지의 일 예를 나타낸다.
도 40은 본 발명의 본 발명의 제7-2 실시예에 따른 NAS 메시지의 다른 예를 나타낸다.
도 41은 대용량 데이터를 segmentation한 후 total segmentation length 대비 현재 NAS PDU의 segmentation offset을 알려주는 방법이다.
도 42는 현재 전송하는 NAS PDU가 연속적으로 전송하는 NAS PDU 중 마지막인지를 나타내는 indication이다.
이하 본 발명의 바람직한 실시 예를 첨부된 도면의 참조와 함께 상세히 설명한다. 그리고, 본 발명을 설명함에 있어서, 관련된 공지 기능 혹은 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단된 경우 그 상세한 설명은 생략할 것이다. 그리고 후술되는 용어들은 본 발명에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.
<제1 실시예>
한편, 단말간의프록시미티(Proximity) 서비스를 통해 프로세 단말(ProSe UE)-네트워크 릴레이(NW relay)를 이용하여 망을 통한 서비스를 받기위한 프로세(ProSe) 망 구조는 도 1과 같이 도식화 할 수 있다.
도1은 본 발명의 제1 실시예에 따른프로세(ProSe) 망 구조를 도시한 도면이다.
릴레이 단말(UE-NW relay UE)은기지국(eNB)의 커버리지 안에 있으면서 셀룰라 망에서 제공하는 서비스를 리모트 단말(remote UE)에게 전달하는 릴레이(relay)역할을 수행한다.
이를 위해서 릴레이 단말(UE-NW relay UE)은 EPS(Evolved Packet Core) 망을 통해서 릴레이(relay)임을 등록하고 릴레이(relay) 서비스를 제공하기 위한 각종 정보를 받아오거나, 리모트 단말(remote UE)에게 IP서비스를 제공해주기위한 PDN (Packet data Network) connection을 생성하는등의 relay서비스를 준비한다. 그리고, relay서비스가 준비가 된 경우에는 디스커버시 방법에 따라 릴레이 단말(UE-NW relay UE)이 직접 자신이 relay임을 알리기위한 어나운스먼트(announcement) 메시지를 방송하거나, 인근의 리모트 단말(remote UE)이 relay를 찾을 때 보내는 discovery solicitation 메시지를 수신하고 해당하는 조건에 맞는경우에 discovery response메시지를 보냄으로 리모트 단말(remote UE)이릴레이 단말(UE-NW relay UE)을 발견하게 된다.
리모트 단말(Remote UE)은 발견된 UE-NW relay중에서 원하는 relay를 선택하여 해당 UE-NW relay와 리모트 단말(remote UE) 간에 connection을 setup하고 이를 통해서 리모트 단말(remote UE)은 망을 통한 서비스를 받을수 있게된다.
본 발명에서는 이와 같이 UE-NW relay UE를 통해서 EPC망에 접속한 remote UE에 대한 Lawful Interception을 제공하기 위한 방안에 대해서 다루게된다.
도2는 본 발명의 제1 실시예에 따른릴레이 단말(relay UE)이리모트 단말(remote UE)에 대한 합법적 감청(Lawful Interception) 정보를 네트워크 망에 전달하는 과정을 나타내는 흐름도이다.
Remote UE(200)는 ProSe UE-NW relay UE(210)에게 접속하기위하여 통신 요청(Communication request) 메시지를 보낸다(201). 이에 따라서, 단계 202 및 211을 통해서 remote UE(200)와 ProSe UE-NW relay UE(210)사이에 인증인증이 완료되고, 이에 따라 ProSe UE-NW relay UE(210)는 필요에 따라서 relay를 위한 PDN(Packet data Network) connection을 새로 만들수 도 있다(212).
그리고, remote UE(200)는 ProSe UE-NW relay UE(210)를 통해서 IP 주소(address)를 할당 또는 설정하게 된다(203). 203단계에서 ProSe UE-NW relay UE(210)는 remote UE(200)에 대한 IP address 또는 IP address와 port정보를 획득할수 있다.
또한, ProSe UE-NW relay UE(210)는 단계 201,202,211과정을 통해서 remote UE(200)의 사용자 정보(User info)를 획득할 수도 있다. 상기 User Info는 IMSI(International Mobile Subscriber Identity)또는 MSISDN(mobile subscriber integrated services digital network number) 또는 SIP(session initiation protocol) URI(uniform resource identifier)또는 ProSe(proximity-based service)용 User Info정보 중 하나 또는 여러 개의 값을 포함할 수도 있다.
상기사용자 정보를 획득한 ProSe UE-NW relay UE(210)는 ProSe function(220)에게 remote UE(200)의 정보 즉 remote UE(200)에 할당된 IP address 또는 IP address와 port정보 그리고, remote UE(200)의 User info를 포함하는 remote UE Info Report메시지(214)를 보낼수 있다. 상기 User Info는 IMSI또는 MSISDN 또는 SIP URI또는 ProSe용 User Info정보 중 하나 또는 여러 개의 값을 포함할 수도 있다. 그 응답으로 ProSe function(220)은 ProSe UE-NW relay UE(210)에게 ACK메시지를 보낼수도 있다(222).
한편, ProSe function(220)은 상기 수신한 remote UE(200)에 대한 접속에 대한 정보를 HSS(250)에 전달할 수 있다(221). 221단계의 메시지는 location update를 위한 메시지 type을 포함할수 있고, ProSe UE-NW relay를 통해 접속하는 remote UE(200)임을 나타내는 Prose relay access type을 포함할 수 있고, 또한 remote UE(200)에 할당된 IP address 또는 IP address와 port정보 그리고, remote UE(200)의 IMSI정보와 User info를 포함할 수도 있다.
상기 User Info는 IMSI또는 MSISDN 또는 SIP URI또는 ProSe용 User Info정보 중 하나 또는 여러 개의 값을 포함할 수도 있다. 그 응답으로 HSS는 ProSe function에게 response 메시지를 보낼수도 있다(251).
한편, 합법적 감청(Lawful Interception)이 필요한 Agent는 HSS(250)혹은 ProSe function(220)으로부터 해당 remote UE(200)에 대한 IP address 및 ports정보를 획득하여(241), Lawful Interception을 수행한다(242).
도3을 참조하면 본 발명의 제1 실시예에 따라 도2의 방법으로 Lawful Interception을 하는 경우, remote UE(300)와 Relay UE(310)간의 연결이 끊어지는 경우에 EPC망에서 remote UE관련 정보를 업데이트 하는 과정을 나타낸다.
301과정에서 remote UE(300)는 Relay를 통해서 서비스를 받고 있다. 이때, 302단계와 같이 remote UE(300)와 Relay UE(310)간의 연결이 끊어지는 경우에, 연결이 끊어졌음을 인식한 Relay UE(310)는 ProSe Function(320)에게 Remote UE Info Report메시지를 보냄을 통해서 remote UE(300)에 대한 정보를 업데이트한다.
상기 Remote UE Info Report메시지는 remote UE(300)의 User info와 connection이 끊어졌음을 알리는 connection released indication을 포함 할 수도 있다. 상기 User Info는 remote UE(300)의 IMSI또는 MSISDN 또는 SIP URI또는 ProSe용 User Info정보 중 하나 또는 여러 개의 값을 포함할 수도 있다.
한편 업데이트된 remote UE(300)의 정보를 받은 ProSe function(320)은 상기 수신한 remote UE(300)에 대한 접속에 대한 업데이트 정보를 HSS(350)에 전달할 수 있다(321).
321단계의 메시지는 location update를 위한 메시지 type을 포함할수 있고, ProSe UE-NW relay를 통해 접속하는 remote UE(300)가 released됐음을 알리기위해 Prose relay access released type을 포함할 수 있고, 또한 remote UE(300)의 IMSI정보와 User info를 포함할 수도 있다.
상기 User Info는 IMSI또는 MSISDN 또는 SIP URI또는 ProSe용 User Info정보 중 하나 또는 여러 개의 값을 포함할 수도 있다. 그 응답으로 HSS는 ProSe function에게 response 메시지를 보낼수도 있다(351).
도4를 참조하면 본 발명의 제1 실시예에 따라 relay UE(410)가 remote UE(400)에 대한 Lawful Interception정보를 EPS망에 전달하는 과정의 흐름을 나타내는 도면이다.
remote UE(400)에 대한 EPC망에서의 Lawful Intercept지원을 위해 relay UE(410)가 ProSe function(420)에게 remote UE(400)의 user ID 및 IP address/port정보를 전달하고 이 정보를 HSS(450)에게 전달함을 통해서 GW(440)에서 remote UE(400)에 대한 Lawful Interception을 수행하기 위한 정보를 전달한다.
Lawful Intercept지원을 위한 방안으로서 relay UE(410)가 MME(430)에게 remote UE(400)의 user ID 및 IP address/port정보를 전달하고 이 정보를 GW(440)에 전달하는 방안 고려하는 경우에, relay UE(410)가 NAS메시지를 통해서 MME(430)에게 remote UE(400)에 대한 정보를 전달하는 방안을 제안한다.
Remote UE(400)는 ProSe UE-NW relay UE(410)에게 접속하기위하여 Communication request메시지를 보낸다(401). 이에 따라서, 단계 402 및 411을 통해서 remote UE(400)와 ProSe UE-NW relay UE(410)사이에 인증이 완료되고, 이에 따라 ProSe UE-NW relay UE(410)는 필요에 따라서 relay를 위한 PDN connection을 새로 만들수 도 있다(412).
그리고, remote UE(400)는 ProSe UE-NW relay UE(410)를 통해서 IP address를 할당 또는 설정하게 된다(403). 403단계에서 상기 ProSe UE-NW relay UE(410)는 remote UE(400)에 대한 IP address 또는 IP address와 port정보를 획득할 수 있다.
또한, ProSe UE-NW relay UE(410)는 단계 401,402,411과정을 통해서 remote UE(400)의 User info를 획득할 수도 있다. 상기 User Info는 IMSI또는 MSISDN 또는 SIP URI또는 ProSe용 User Info정보 중 하나 또는 여러 개의 값을 포함할 수도 있다.
상기 정보를 획득한 ProSe UE-NW relay UE(410)는 MME(430)에게 remote UE(400)의 정보 즉 remote UE에 할당된 IP address정보 그리고, remote UE의 User info를 포함하는 remote UE Info Report메시지(414)를 보낼 수 있다.
상기 IP address정보는 IPv6를 사용하는 경우 remote UE(400)에 대한 IP address 또는 IPv6 prefix정보를 의미하고, IPv4를 사용하는 경우에는 remote UE(400)에 대한 IP address와 port정보를 의미한다.
상기 User Info는 IMSI또는 MSISDN 또는 SIP URI또는 ProSe용 User Info정보 중 하나 또는 여러 개의 값을 포함할 수도 있다. 그 응답으로 MME(430)는 ProSe UE-NW relay UE(410)에게 ACK메시지를 보낼수도 있다(432).
한편, MME(430)는 상기 수신한 remote UE(400)에 대한 접속에 대한 정보를 HSS(450)에 전달할 수 있다(431). 431단계의 메시지는 location update를 위한 메시지 type을 포함할수 있고, ProSe UE-NW relay를 통해 접속하는 remote UE(400)임을 나타내는 Prose relay access type을 포함할 수 있고, 또한 remote UE(400)에 할당된 IP address 정보 그리고, remote UE(400)의 IMSI정보와 User info를 포함할 수도 있다.
상기 User Info는 IMSI또는 MSISDN 또는 SIP URI또는 ProSe용 User Info정보 중 하나 또는 여러 개의 값을 포함할 수도 있다. 그 응답으로 HSS(450)는 MME(430)에게 response 메시지를 보낼수도 있다(451).
HSS(450)에 전달된 정보는 IMS서비스를 이용하는 과정에서 HSS(450)와 S-CSCF등이 연동하여 location update또는 UE identification또는 UE authentication등의 과정에서 사용될 수 있다.
한편, MME(430)는 상기 수신한 remote UE(400)에 대한 접속에 대한 정보를 G/W(440)에 전달할 수 있다(432). 432단계의 Remote UE info Report메시지는 remote UE에 할당된 IP address 정보 그리고, remote UE의 IMSI정보와 User info를 포함할 수도 있다.
상기 User Info는 IMSI또는 MSISDN 또는 SIP URI또는 ProSe용 User Info정보 중 하나 또는 여러 개의 값을 포함할 수도 있다. 그 응답으로 G/W(440)는 MME(430)에게 response 메시지를 보낼수도 있다(441).
이에 따라서 Lawful Interception이 필요한 Agent는 G/W(440)에서 해당 remote UE에 대한 IP address 및 ports정보를 이용하여 Lawful Interception을 수행한다(442).
도5a를 참조하면 본 발명의 제1 실시예에 따라 도4의 방법으로 Lawful Interception을 하는 경우, remote UE(500)와 Relay UE(510)간의 연결이 끊어지는 경우에 EPC망에서 remote UE관련 정보를 업데이트 하는 과정을 나타낸다.
501과정에서 remote UE(500)는 Relay를 통해서 서비스를 받고 있다. 이때, 502단계와 같이 remote UE(500)와 Relay UE(510)간의 연결이 끊어지는 경우에, 연결이 끊어졌음을 인식한 Relay UE(510)는 MME(530)에게 Remote UE Info Report메시지를 보냄을 통해서 remote UE(500)에 대한 정보를 업데이트한다(512).상기 Remote UE Info Report메시지는 remote UE(500)의 User info와 connection이 끊어졌음을 알리는 connection released indication과 IP address정보를 포함 할 수도 있다. 상기 User Info는 remote UE(500)의 IMSI또는 MSISDN 또는 SIP URI또는 ProSe용 User Info정보 중 하나 또는 여러 개의 값을 포함할 수도 있다.
상기 IP address정보는 IPv6를 사용하는 경우 remote UE에 대한 IP address 또는 IPv6 prefix정보를 의미하고, IPv4를 사용하는 경우에는 IP address와 port정보를 의미한다.
한편 업데이트된 remote UE의 정보를 받은 MME(530)는 상기 수신한 remote UE(500)에 대한 접속에 대한 업데이트 정보를 HSS(550)에 전달할 수 있다(531). 531단계의 메시지는 location update를 위한 메시지 type을 포함할 수 있고, ProSe UE-NW relay를 통해 접속하는 remote UE(500)가 released됐음을 알리기위해 Prose relay access released type을 포함할 수 있고, 또한 remote UE(500)의 IMSI정보와 User info를 포함할 수도 있다. 상기 User Info는 IMSI또는 MSISDN 또는 SIP URI또는 ProSe용 User Info정보 중 하나 또는 여러 개의 값을 포함할 수도 있다. 그 응답으로 HSS(550)는 MME(530)에게 response 메시지를 보낼수도 있다(551).
한편, 업데이트된 remote UE(500)의 정보를 받은 MME(530)는 상기 수신한 remote UE에 대한 접속에 대한 업데이트 정보를 G/W(540)에 전달할 수 있다(532). 532단계의 Remote UE Info Report메시지는 ProSe UE-NW relay를 통해 접속하는 remote UE(500)가 released됐음을 알리기위해 Prose relay access released type을 포함할 수 있고, 또한 remote UE(500)의 IMSI정보와 User info를 포함할 수도 있다.
상기 User Info는 IMSI또는 MSISDN 또는 SIP URI또는 ProSe용 User Info정보 중 하나 또는 여러 개의 값을 포함할 수도 있다. 그 응답으로 G/W(540)는 MME(530)에게 response 메시지를 보낼 수도 있다(541).
상기 도 4와 도5a에 해당하는 실시예에서, relay UE가 MME에게 remote UE info report를 보내는 과정 즉 414/433단계 혹은 512/533단계의 동작에서 상기 예와 같이 별도의 NAS메시지를 사용할수 도 있다.
또하나의 실시 예로서 remote UE info report를 기존 ESM STATUS메시지를 이용해서 전송하고 ACK을 생략하는 경우 다음과 같이 전송할 수 있다.
도 5b 는 제1 실시예에 따른 단말과 네트워크 간 ESM 상태 메시지를 송수신하는 과정을 설명하는 도면이다.
ESM 상태 메시지를 송신하는 목적은 ESM 프로토콜 데이터 수신 시 검출되는 특정 에러 조건을 임의의 시간에 리포트하거나, 프로세 UE-네트워크 릴레이하거나, 리모트 UE의 IP연결 정보를 위한 것이다. 상기 ESM 상태 메시지는 MME에 의해 전송되거나, UE에 의해 전송될 수 있다.
UE의 ESM 엔티티가 ESM 상태 메시지를 수신하면, UE는 수신된 ESM cause value에 따라 다른 동작을 취한다.
#43(Invalid EPS bearer identity);
UE는 수신된 EPS 베어러 식별자에 관련된 ESM 절차를 중지하고, 관련 타이머를 중지하고, 상응하는 EPS 베어러 컨텍스트를 비활성화한다(UE와 MME 간 피어 투 피어 시그널링 없이).
#81(Invalid PTI value);
UE는 수신된 PTI value에 관련된 ESM 절차를 중지하고, 관련 타이머를 중지한다.
#97(Message type non-existent or not implemented);
UE는 관련된 PTI 또는 EPS bearer 식별자에 관련된 ESM 절차를 중지하고, 관련 타이머를 중지한다.
On receipt of an ESM STATUS message with any other ESM cause value no state transition and no specific action shall be taken as seen from the radio interface, i.e. local actions are possible.
어떤 다른 ESM cause value와 함께 ESM 상태 메시지를 수신하면, 무선 인터페이스로부터 보여지는 상태 변화가 없고 특정 동작 없다(로컬 동작은 가능).
MME의 ESM 엔티티가 ESM 상태 메시지를 수신하면, MME는 수신된 ESM cause value에 따라 다른 동작을 위한다.
#43(Invalid EPS bearer identity);
MME는 수신된 EPS 베어러 식별자에 관련된 ESM 절차를 중단하고, 관련 타이머를 중지하고, 해당하는 EPS 베어러 컨텍스트를 비활성화한다(MME와 UE 간 피어 투 피어 시그널링 없이).
#81(Invalid PTI value);
MME는 수신된 PTI value와 관련된 ESM 절차를 중단하고, 관련 타이머를 중지한다.
#97(Message type non-existent or not implemented);
MME는 PTI 또는 EPS 베어러 식별자에 관련된 ESM 절차를 중단하고, 관련 타이머를 중지한다.
임의의 다른 ESM cause value와 함께 ESM 상태 메시지를 수신 시 MME에 의해 취해지는 로컬 동작은 구현에 따라 달라질 수 있다.
이하, 리모트 UE 리포트를 위한 ESM 상태 메시지와 관련 타이머를 설명한다.
ESM 상태 메시지는 릴레이 UE (ProSe UE-to-network relay UE)가 리모트 UE의 IP 연결 정보를 네트워크로 전달하기 위해 사용될 수 있다.
릴레이 UE가 리모트 UE와 PC5 direct link를 설립하거나 해제할 때, 릴레이 UE는 타이머 Txxxx를 구동하고, 타이머 Txxxx가 만료되기 전에 ESM 상태 메시지를 통해 리모트 UE 리포트를 네트워크로 전송한다.
이 경우, ESM cause가 #128(Remote UE report transaction)로 설정된다. 릴레이 UE는 ESM 상태 메시지 내에 복수의 UE의 리모트 UE 리포트를 전송할 수 있다.
타이머 Txxxx의 만료 이전에 릴레이 UE가 ESM 메시지를 통해 네트워크로 리모트 UE 리포트를 전송하는데 실패하면, UE는 타이머 Txxxx를 재설정하고 재구동하여 ESM 상태 메시지를 재전송한다. 상기 재전송은 단말 구현에 따라 4회 이상 반복될 수 있다.
MME가 리모트 UE 리포트를 위한 ESM 상태 메시지를 수신하면, 릴레이 UE와 연결되는 리모트 UE 정보 리스트가 업데이트된다.
또한, 릴레이 UE가 리모트 UE와 PC5 direct link를 설립하거나 해제할 때, 릴레이 UE는 타이머 Txxxx를 구동하고, 타이머 Txxxx가 만료되기 전에 ESM 상태 메시지를 통해 리모트 UE 리포트를 네트워크로 전송하고, 타이머 Tyyy가 구동 중이면 타이머 Tyyy를 재설정하여 구동한다.
이 경우, ESM cause가 #128(Remote UE report transaction)로 설정된다. 릴레이 UE는 ESM 상태 메시지 내에 복수의 UE의 리모트 UE 리포트를 전송할 수 있다.
타이머 Txxxx의 만료 이전에 릴레이 UE가 ESM 메시지를 통해 네트워크로 리모트 UE 리포트를 전송하는데 실패하면, UE는 타이머 Txxxx를 재설정하고 재구동하여 ESM 상태 메시지를 재전송한다. 상기 재전송은 단말 구현에 따라 4회 이상 반복될 수 있다.
MME가 리모트 UE 리포트를 위한 ESM 상태 메시지를 수신하면, 타이머 Tyyy가 구동되고 릴레이 UE와 연결되는 리모트 UE 정보 리스트가 업데이트되고, 이에 응답하여 MME는 타이머 Tyyy 의 만료 이전에 acknowledgement로서 ESM cause가 128(Remote UE report transaction)로 설정된 Remote UE report IE 없이 ESM 상태 메시지를 전송한다.
릴레이 UE가 상기 acknowledgement를 수신하면, 구동 중인 타이머 Tyyy의 구동을 중단한다. 그러나, 릴레이 UE가 타이머 Tyyy의 만료까지 상기 acknowledgement를 수신하지 않으면 UE는 타이머 Tyyy를 재설정/재구동하여 ESM 상태 메시지를 재전송한다. 상기 재전송은 4회 반복될 수 있고, 예컨대, UE는 타이머 Tyyy의 5회 만료시 절차를 중단할 수 있다.
<제2 실시예>
도 6은 본 발명의 제2 실시예에 따른 Cellular IoT (CIoT)네트워크 구조를 나타내는 도면이다.
도 6을 참조하면, C-SGN(CIoT Serving Gateway Node）은 MME와 S-GW, P-GW의 조합으로 이루어진 Network Entity이며, CIoT를 위한 경량화된 Core Network Entity를 의미한다.
상기 네트워크 구조의 T6a Interface는 MME와 SCEF 사이를 연결하는 Interface이고, 이 Interface를 이용하여 작은 크기의 메시지를 전달할 수 있다.도 7은 본 발명의 제2 실시예에 따라 단말이 보내고자 하는 상향 non-IP 데이터를 MME와 SCEF를 통하여 전송하는 절차를 나타낸다. 여기서, Non-IP 데이터라함은 IP 구조를 가지지 않은 모든 데이터 프로토콜 형태를 의미한다.
1.MME/SGSN/C-SGN(700)은 UE로부터 RAN을 거쳐 데이터 받는다. 이때 상기 데이터가 IP packet인지 아닌지 구분해주는 지시자가 올 수 있다. 혹은 MME/SGSN/C-SGN(700)이 직접 데이터 패킷을 보고 IP packet이면 P-GW로 보내거나 직접 PDN으로 전달할 수 있고, IP packet이 아니면(즉 non-IP 이면) SCEF를 통해 전달할 수 있다.
로밍인 경우 MME(700)는 IWK-SCEF를 통해서 HPLMN의 SCEF(720)로 전달한다. Monitoring Event를 SDT(Small Data Transmission)이라고 설정하여, 데이터 전송에 대한 메시지임을 나타낼 수 있다.
2a. MME/SGSN(700)은 Non-IP 데이터를 포함하여 SCEF(720)에게 메시지를 전달한다. 이 메시지에는 SCEF Reference ID가 포함되어 SCEF(720)와 MME 사이의 연결을 식별할 수 있다.
3.SCEF(720)는 수신한 메시지의 SCEF reference ID를 확인하여, 이에 연관된 SCS/AS Reference ID를 획득한다. SCS/AS Reference ID는 Application server(SCS/AS)와 SCEF 간 사용되는 식별자이며, SCEF와 Application Server(SCS/AS)는 상기 ID를 이용하여 상호 식별한다.
SCEF(720)가 수신한 메시지에는 Monitoring Destination Address가 포함될 수 있으며, 이는 Application Server(SCS/AS)의 주소를 의미한다. SCS/AS Reference ID가 없다면, SCS/AS의 주소를 사용하여, 수신한 메시지의 목적지를 판단할 수 있다. SCEF는 상기와 같이 판단한 목적지로 2번에서 수신한 non-IP 데이터를 전송한다. 이 때 SCS/AS Reference ID 또는 SCS/AS에서 단말을 식별할 수 있는 식별자(External ID 또는 MSISDN)를 함께 포함할 수 있다.
도 8은은 본 발명의 제2 실시예에 따라 단말이 로밍 중인 경우 non-IP데이터를 전송하는 절차를 나타낸다. MME와 IWK-SCEF는 Roaming 망에 있는 네트워크 entitiy이고, SCEF는 Home 망에 있다.
1.MME/SGSN/C-SGN(800)은 UE로부터 RAN을 거쳐 데이터 받는다. 이때 받은 데이터가 IP packet인지 아닌지 구분해주는 지시자가 올 수 있다. 혹은 MME/SGSN/C-SGN(800)이 직접 데이터 패킷을 보고 IP packet이면 P-GW로 보내거나 직접 PDN으로 전달할 수 있고, IP packet이 아니면 IWK-SCEF(810)를 통해 전달할 수 있다. Monitoring Event를 SDT(Small Data Transmission)이라고 설정하여, 데이터 전송에 대한 메시지임을 나타낼 수 있다.
2a.MME/SGSN(800)이 IWK-SCEF(810)를 사용하지 않도록 설정되어 있다면, home 망에 있는 SCEF(830)로 바로 메시지를 전송할 수 있다. MME/SGSN은 이에 따라 추가적으로 과금 정보를 생성할 수 있다.
2c. MME/SGS)이 로밍 중인 단말에 대하여 IWK-SCEF(810)로 메시지를 전송하도록 설정되어 있다면, MME/SGSN은 단말로부터 수신한 non-IP 데이터를 포함한 메시지를IWK-SCEF로 전달한다. 상기 메시지에는 SCEF Reference ID가 포함될 수 있으며, 이는 단말에 대한 MME/SGSN과 IWK-SCEF, 그리고 Home망의 SCEF간 연결을 식별하기 위해 사용된다.
IWK-SCEF(810)는 상기에서 전달받은 메시지를 SCEF(830)에게 전달한다. 이 메시지에는 단말이 보낸 non-IP 데이터와 SCEF(830)와 단말간 연결을 식별할 수 있는 SCEF Reference ID가 포함된다.
3.SCEF(830)는 수신한 메시지의 SCEF reference ID를 확인하여, 이에 연관된 SCS/AS Reference ID를 획득한다. SCS/AS Reference ID는 Application server(SCS/AS)와 SCEF 간 사용되는 식별자이며, SCEF(830)와 Application Server(SCS/AS)는 상기 ID를 이용하여 상호 식별한다. SCEF가 수신한 메시지에는 Monitoring Destination Address가 포함될 수 있으며, 이는 Application Server(SCS/AS)의 주소를 의미한다. SCS/AS Reference ID가 없다면, SCS/AS의 주소를 사용하여, 수신한 메시지의 목적지를 판단할 수 있다. SCEF는 상기와 같이 판단한 목적지로 2번에서 수신한 non-IP 데이터를 전송한다. 이 때 SCS/AS Reference ID 또는 SCS/AS에서 단말을 식별할 수 있는 식별자(External ID 또는 MSISDN)를 함께 포함할 수 있다.
<MT small data transmission>
1.SCS/AS는 MT small data를 SCEF로 전달한다. 이때, small data와 함께 SCS/AS Reference ID 및/혹은 SCS/AS Identifier를 전달할 수 있다.
2.IWK-SCEF가 사용되는 경우, SCEF는 IWK-SCEF에게 MT small data를 전달한다. 이때 대상 IWK-SCEF의 ID는 다음과 같이 찾는다: 단계 1에서 수신한 SCS/AS Reference ID와 연관 지어진 SCEF Reference ID를 찾는다. 이 SCEF Reference ID에 연계된 IWK-SCEF ID를 찾는다.
MT small data를 전달할 때, SCEF Reference ID 및/혹은 SCEF ID를 함께 전달할 수 있다. IWK-SCEF는 MME/SGSN/C-SGN에게 MT small data를 전달한다. 이때 대상 MME/SGSN/C-SGN의 Routing Information은 다음과 같이 찾는다: 이 단계에서 수신한 SCEF Reference ID 와 연관 지어진 Routing Information을 찾는다. MT small data를 전달할 때, IMSI, SCEF Reference ID, SCEF ID 및/혹은 IWK-SCEF ID를 함께 전달할 수 있다. SCEF ID는 SCEF를 나타내는 주소 혹은 이름일 수 있다.
IWK-SCEF가 사용되지 않는 경우, SCEF는 MME/SGSN/C-SGN에게 MT small data를 전달한다. 이때 대상 MME/SGSN/C-SGN의 Routing Information은 다음과 같이 찾는다: 이 단계에서 수신한 SCEF Reference ID 와 연관 지어진 Routing Information을 찾는다MT small data를 전달할 때, 단말을 식별하기 위한 IMSI, 단말과 SCEF간 연결을 식별하기 위한SCEF Reference ID, 및/혹은 SCEF ID를 함께 전달할 수 있다.
3.MT small data를 수신한 MME/SGSN/C-SGN은 IMSI가 가리키는 UE에게 MT small data를 전달할 수 있다.
MME/SGSN/C-SGN은 해당 UE를 서빙하지 않을 수 있다. 이 경우, MME/SGSN/C-SGN은 SCEF에게, 혹은 IWK-SCEF를 거쳐 SCEF에게, MT small data를 전달할 수 없다고 알릴 수 있다. 이때, SCEF는 해당 UE의 MME/SGSN/C-SGN routing information을 HSS에게 요청할 수 있다. SCEF가 요청할 때, UE의 ID로 external ID를 쓰거나 IMSI를 사용할 수 있다. HSS는 Routing information을 SCEF에게 준다. 이때 IMSI 정보를 반드시 줄 필요는 없다. 이후 상기 단계 2를 반복한다. 한가지 다른 점은, 새로이 받은 Rouoting Information을 사용한다는 점, IWK-SCEF가 쓰이는 경우에, SCEF는 IWK-SCEF에게 MT small data와 함께 추가적으로 Routing Information을 전달한다는 것이다.
<Configuration and deletion of Monitoring Event: SDT>
IWK-SCEF가 있는 경우를 바탕으로 설명하겠지만, 간단히, 단계 7, 8, 9를 생략하고, 단계 6, 10을 적절히 합치면 IWK-SCEF가 없는 경우를 cover할 수 있다.
도 9는 작은 데이터 전송(SDT: Small Data Transmission)을 설정하거나 설정을 해제하는 방법을 나타낸다.
1.SCS/AS(940)는 SCEF(930)로 SDT (Small Data Transmission)에 대한 요청을 보낼 수 있다. 요청 메시지에는 단말을 식별할 수 있는 External ID 혹은 MSISDN, SCS/AS를 식별할 수 있는 SCS/AS ID,단말에 대한 SCS/AS(940)와 SCEF(930) 간 연결을 식별하는 SCS/AS Reference ID, 그리고 Small Data Transmission을 설정할 것임을 나타내는 parameter가 포함된다.
상기 External ID는 HSS에서 IMSI와 매핑이 되는 식별자이며, SCEF(930)는 HSS(920)와의 시그널링을 통해 어떤 IMSI에 해당하는 External ID인지 알게 된다. Small Data Transmission임을 나타내는 Parameter에는 Traffic Category(하기 표 참조), 상향 데이터 크기, 하향 데이터 크기, 한번에 보낼 수 있는 최대 상향 데이터 크기, 한번에 보낼 수 있는 최대 하향 데이터 크기, 그리고 얼마나 자주 메시지를 주고받는 지에 대한 빈도수가 포함될 수 있다.
MME/SGSN(900) 혹은 C-SGN, 또는 SCEF(930), IWK-SCEF(910)는 상향/하향 데이터 전송을 Traffic 카테고리에 따라 제어할 수 있다. 예를 들어, Traffic 카테고리가 MAR periodic 레포트라면, 상향 데이터는 200 바이트 이상의 사이즈를 가질 수 없다. 또 다른 예로, Traffic 카테고리가 MAR periodic 레포트라면, 상향 데이터는 매 30분보다 잦은 주기로 오는 데이터는 전송되지 않는다.
상술한 데이터 전송 제어는 상향 링크인 경우 MME/SGSN/C-SGN(900)이 하향 링크인 경우 SCEF(930) 혹은 IWK-SCEF(910)가 수행할 수 있다.
[Table 4.3-1 Traffic Models for Cellular IoT]
Figure PCTKR2016010783-appb-I000001
2. SCEF(930)는 단계1로부터 수신한 SCS/AS Reference ID, 단말의 ID, Small Data Transmission에 대한 파라메터를 저장한다. SCEF(930)는 상기 요청에 대한 SCEF Reference ID를 할당한다. 사업자의 정책에 따라, 해당 SCS/AS(940)가 SDT를 수행하도록 허가 받지 못했다면, 혹은 상기 요청 메시지가 잘못된 형식을 하고 있다면, 혹은 SCS/AS(940)가 SDT를 요청하기 위한 할당량을 넘어섰다면, SCEF(930)는 적절한 Cause 값과 함께 에러를 SCS/AS(940)에게 전달한다.SCEF(930)는 SDT에 대한 파라메터를 확인한다. 만약 파라메터 중 하나라도 사업자의 정책에 맞지 않으면, 상기 요청을 거절한다.
3.SCEF(930)는 상기 단계에서 수신한 정보를 바탕으로 HSS(920)에 SDT에 대한 요청을 전달한다. 이 요청 메시지에 포함된 파라메터에 따라 HSS는 MME/SGSN/C-SGN에 SDT를 위한 파라미터를 설정 할 수 있다.
4. HSS(920)는 상기 요청을 검수하여, 해당 단말의 ID(External ID 혹은 MSISDN)이 존재하는지, 포함된 파라메터가 이동통신사업자로부터 수용가능한 지를 판단한다. HSS(920)는 과금을 위한 ID를 확인하여 허가할 수 있다. 만약 허가되지 않았다면, SCEF(930)로 거절 메시지와 이유를 전송한다.
5.HSS(920)는 MME/SGSN/C-SGN(900)으로 SDT를 설정하기 위한 메시지를 보낸다. 이 메시지에는 SDT 설정을 위한 파라메터, SCEF ID, SCEF Reference ID, 과금을 위한 ID, 단말의 ID를 포함하여 전달한다.
6. MME/SGSN/C-SGN(900)은 상기 단계 5로부터 수신한 파라메터들을 저장한다. 그 후, UE에 대한 데이터 전송을 시작할 수 있다. MME/SGSN/C-SGN(900)은 HSS(920)로부터 설정받은 SDT 관련 설정값이 이동통신사업자의 정책에 맞지 않으면, 상기 단계 5에 대한 응답으로 거절메시지를 보낼 수 있다.
7.MME/SGSN/C-SGN(900)은 단말이 로밍 중인 단말인 경우, IWK-SCEF(910)에게 SDT관련 설정 파라메터를 전달할 수 있다. 이 메시지에는 SCEF ID, SCEF Reference ID, 과금을 위한 ID, SDT를 위한 파라메터, 단말의 식별자인 IMSI, 그리고 MME/SGSN/C-SGN에 대한 Routing 정보를 포함할 수 있다.
IMSI와 MME/SGSN/C-SGN Routing Information은 IWK-SCEF(910)가 쓰이는 경우 및/혹은SDT인 경우(혹은 그 밖의 SCS/AS 및/혹은 SCEF에 의해 전달되는 정보 전달을 위한 일이 있는 경우)에 한해 전달될 수 있다. IWK-SCEF(910)는 IMSI와 MME/SGSN/C-SGN Routing Information을 이용해 하향링크 데이터 전송을 할 수 있다. MME/SGSN/C-SGN은 단계 5에서 수신한 IMSI(s)를 전달할 수 있다. MME/SGSN/C-SGN Routing Information은 각 IMSI가 가리키는 UE가 서빙하는 핵심망 Entity 정보이다. IWK-SCEF는 IMSI, Routing Information과 SCEF Reference ID를 mapping시켜 저장해둔다.
8.IWK-SCEF(910)는 단계 6의 SCEF(930)가 수행하였듯이, SDT 요청에 대한 허가를 수행할 수 있다.상기 SDT 요청에 대한 허가 절차가 실패하였을 경우, 적절한 Cause 값과 함께 MME/SGSN/C-SGN(900)으로 거절 메시지를 보낸다.
상기 SDT 요청에 대한 허가가 성공하였을 경우, IWK-SCEF(910)는 수신한 파라메터를 저장하고, MME/SGSN/C-SGN(900)으로 ACK을 전송하여 SDT가 설정되었음을 알린다.
9. SDT 요청에 대한 허가가 성공하였을 경우, IWK-SCEF(910)는 수신한 파라메터를 저장하고, MME/SGSN/C-SGN(900)으로 ACK을 전송하여 SDT가 설정되었음을 알린다.
10.MME/SGSN/C-SGN(900)은 IWK-SCEF(910)로부터 수신한 요청을 확인한다. SDT가 로밍에도 적용되는 지를 확인하고, 단말의 Home PLMN에 대해서 서비스 가능한지 여부를 확인한다. 만약 허용되지 않았다면, 에러 메시지를 IWK-SCEF(910)로 전송한다. 로밍중인 단말이 아니라면, MME/SGSN/C-SGN(900)은 상기 단계 5와 단계 6의 절차에 이어, 해당 단말이 SCEF(930)를 통한 SDT를 사용가능한지 확인한다. 해당 단말에 대한 SDT가 허용되지 않았다면, MME/SGSN/C-SGN(900)은 SCEF(930)로 SDT가 허용되지 않았다는 거절 메시지를 전송한다.
11.단말에 대한 SDT 설정이 성공적이었다면, MME/SGSN/C-SGN(900)은 HSS(920)로 ACK을 보내어 SDT 설정이 성공적으로 수행되었음을 알린다. 상기 메시지는 HSS(920) 혹은 SCEF(930)가 보낸 SDT 요청에 대한 응답으로 수행될 수 있다. 메시지의 이름은 SDT라는 명칭에 국한되지 않으며, non-IP 데이터를 전송하기 위한 요청 메시지를 의미한다.
12.HSS(920)는 단계 11을 통하여 MME/SGSN/C-SGN(900)으로부터 SDT가 성공적으로 수행되었음을 수신하였다면, SCEF(930)로 SDT의 설정이 성공적으로 수행되었음을 알린다. 이 메시지에는 단말에 대한 SCEF 연결을 나타내는 SCEF Reference ID, 단말의 식별자인 IMSI, 그리고 MME/SGSN/C-SGN으로 메시지를 보내기 위한 routing 정보, 로밍 단말이었다면 IWK-SCEF ID를 포함할 수 있다. IMSI와 MME/SGSN/C-SGN Routing Information은 IWK-SCEF가 쓰이는 경우 및/혹은SDT인 경우(혹은 그 밖의 SCS/AS 및/혹은 SCEF에 의해 전달되는 정보 전달을 위한 일이 있는 경우)에 한해 전달될 수 있다.
IWK-SCEF(910)는 IMSI와 MME/SGSN/C-SGN Routing Information을 이용해 하향링크 데이터 전송을 할 수 있다. MME/SGSN/C-SGN(900)은 단계 5에서 수신한 IMSI(s)를 전달할 수 있다. MME/SGSN/C-SGN Routing Information은 각 IMSI가 가리키는 UE가 서빙하는 핵심망 Entity 정보이다. IWK-SCEF(910)는 IMSI, Routing Information과 SCEF Reference ID를 mapping시켜 저장해둔다.
13.단말에 대한 SDT 설정이 완료되었음을 확인한 SCEF(930)는 SCS/AS(940)로 SDT 설정이 완료되었음을 알린다. 상기 메시지에는 SCS/AS Reference ID와 SDT가 성공적으로 설정되었음을 나타내는 cause 값이 포함될 수 있다.
<작은 데아터 전송 절차(SDT:Small data transmission procedures)>
도 10은 서버가 단말에게 보내는 non-IP 데이터 전송 절차(Mobile terminated small data transmission procedure)에 관한 것이다.
SCS/AS(1020)는 단말에 대한 SDT 설정이 완료 된 후, 단말에게 non-IP 데이터를 전송할 수 있다. SCS/AS(1020)는 어떤 SCS/AS Reference ID를 사용할지, 어떤 SCEF(1010)로 전송할지를 SDT 설정 절차에 따라서 판단할 수 있다. SCEF(1010)는 SDT 설정 절차에 따른 결과로, SCS/AS(1020)로부터 수신한 non-IP 데이터를 어떤 SCEF Reference ID를 사용할지, 단말이 어떤 IMSI를 사용하는지 판단할 수 있다.
1.SCS/AS(1020)는 단말에게 보낼 non-IP 데이터를 포함하여 SCEF(1010)에게 메시지를 전송한다. 이 메시지에는 SCS/AS reference ID와 단말에게 보낼 non-IP 형식의 작은 데이터가 포함된다.
2.SCEF(1010)는 수신한 SCS/AS reference ID를 보고, 어떤 MME/SGSN/C-SGN(1000)으로 보내야할 지, 어떤 단말에게 보내는 데이터인지 식별하여, 이에 해당하는 SCEF Reference ID 혹은 IMSI를 찾을 수 있다. 이동통신사업자 정책에 따라, 만약 SCS/AS(1020)가 SDT를 수행하도록 허가 받지 못했거나, SCS/AS(1020)가 전송할 수 있는 빈도수를 초과하였다면, SCEF(1010)는 단계 6을 바로 수행하여 SDT 요청을 거절할 수 있다.
3.SCEF(1010)는 상기 2단계로부터 수신한 작은 데이터 전송 요청(SDT 요청)을 MME/SGSN/C-SGN(1000)에게 전달한다. 이 메시지에는 단말에 대한 SCEF와의 연결을 나타내는 SCEF Reference ID가 포함될 수 있다. 또한 이 메시지에는 단말을 식별하기 위한 IMSI가 포함될 수 있다. 그리고 이 메시지에는 단말에게 전송하기 위한 non-IP 데이터가 포함된다.
4.MME/SGSN/C-SGN(1000)은 상기 요청을 수신한 후, 해당 요청을 검증한다. 만약 실패하였다면 단계 5를 통하여 SCEF(1010)에게 작은 데이터 전송 요청(SDT 요청)이 실패했음을 알린다. 실패 이유는 이동통신사업자의 정책상 더 이상 SDT 서비스가 불가능하거나, SCEF(1010)가 보낼 수 있는 SDT의 전송 할당량이 초과되었거나, 전송 빈도수가 초과된 경우일 수 있다.
MME/SGSN/C-SGN(1000)이 상기 단계 3으로부터 수신한 요청을 확인할 결과, SDT 서비스 제공이 가능하다고 판단한 경우, MME/SGSN/C-SGN(1000)은 단말에게 단계 3으로부터 수신한 non-IP 데이터를 전송한다. 이는 NAS 시그널링을 통하여 전달된다.
5.단말에게 non-IP 데이터를 전달 한 후, MME/SGSN/C-SGN(1000)은 SCEF(1010)에게 응답을 보내어 SDT 요청이 처리되었음을 알린다. 혹은 단말에 대한 non-IP 데이터 전송이 실패하였거나 허가되지 않은 경우, SCEF(1010)에게 SDT 요청의 실패를 알린다.
6.SCEF(1010)는 SCS/AS(1020)에게 SDT 요청의 결과를 알린다.
<제3 실시예>
도 11은 재난안전망 시스템으로 일컬어지는 MCPTT 서비스와, 이를 EPS와 연동하기 위해 사용되는 SIP Core, 그리고 EPS 및 단말의 구조를 나타낸다. 도 11의 SIP Core는 SIP이라는 전송 프로토콜을 사용하는 시스템으로써, IMS가 그 일례이다. SIP Core의 P-CSCF는 EPS의 PCRF와 Rx 인터페이스를 갖고 있으며, 이를 이용하여 단말에게 MCPTT 서비스를 제공하기 위한 QoS 및 Policy를 적용할 수 있다.
도 11을 참조하면, Rx 인터페이스는 PCRF와 P-CSCF 사이 및/혹은 PCRF와 MCPTT server 사이에 정의될 수 있다. PCRF는 두 entity로부터 정보를 (주고) 받으면서 동작하게 된다면 MCPTT server와 P-CSCF가 각각 일치하지 않는 정보를 줄 수 있으므로, 단말에 대한 QoS 제어가 어렵다. 반대로 두 entity가 같은 정보를 준다면 한 entity는 의미 없는 시그널링이 일으키는 것이라 바람직한 동작이라 볼 수 없다. 따라서 operator policy 및/혹은 그 밖의 pre-configuration에 따라 둘 중 하나가 선택될 필요가 있다.
따라서 단말의 Home과 Serving PLMN은 Rx interface의 연결을 식별할 수 있어야 한다. MCPTT 서비스를 제공하는 MCPTT AS(Application Server)는 Home PLMN ID를 이용하여 HPLMN으로의 Entry point를 찾는다. 또는 단말의 Serving PLMN ID를 이용하여 VPLMN으로의 Entry point를 찾는다. Entry point는 SIP core의 S-CSCF를 나타내거나, EPS의 P-GW를 나타낼 수 있다. SIP Core나 EPS에는 해당 PLMN에서의 PCRF를 찾을 수 있는 정보를 갖고 있다.
MCPTT AS는 단말이 사용하는 IP 주소의 Range를 포함하는 매핑 정보를 가지고 있을 수 있다. 이 매핑 정보를 이용하여, 특정 범위(Range)에 있는 IP주소에 대한 PLMN을 찾을 수 있다. 예를 들어, IP x 부터 IP y까지는 PLMN 1에 매핑된다고 판단할 수 있다.
로밍상황에서, MCPTT AS는 단말의 IP주소 및 Home PLMN의 ID, Visited PLMN의 ID를 단말로부터 MCPTT-1 interface를 통한 시그널링으로 전달받는다. 해당 PLMN의 Entry point가 설정되어 있고, 이 정보가 단말의 IP 주소 및 Home PLMN ID/Visited PLMN ID와 매칭이 된다면, MCPTT AS는 단말의 PLMN에 있는 PCRF를 찾을 수 있다. MCPTT AS는 Home PLMN 혹은 Visited PLMN 이동통신 사업자와 상호 서비스 동의가 되어있으며, 이를 기반으로 Entry point에 대한 정보 및 PCRF를 찾는 동작을 수행한다.
Rx를 통해 전달되어야 하는 정보는 다음과 같다:
-Media or flow description (e.g. SDP);
-Priority;
-MCPTT Group ID;
-MCPTT User ID and/or IMPU; and/or
-Call type.
상기 정보 중 전체 혹은 일부는 MCPTT AS가 곧바로 Rx를 통해 PCRF로 전달할 수도 있고, MCPTT AS가 SIP-2 인터페이스를 통해 SIP core로 전달하여 P-CSCF가 Rx를 통해 PCRF로 전달할 수 있다. PCRF는 수집한 정보에 따라 bearer를 새로이 설립하거나 기존 bearer를 수정할 수 있다.
UE가 SIP 메시지의 INVITE 헤더에 특별한 tag를 넣으면 P-CSCF는 Rx 제어를 해제할 수 있다. 이 경우 MCPTT Server가 직접 EPC의 PCRF와 Rx를 통해서 PCC rule을 생성한다.
혹은 단말이 보내는 SIP 메시지인 INVITE 메시지에 특별 ICSI 정보가 담겨 있으면 P-CSCF 내 Rx 제어 정보를 해제할 수 있다. 즉 P-CSCF는 Rx interface를 통해서 PCRF와 교섭을 하지 않는다. 대신 MCPTT server가 PCRF와 Rx를 통해서 PCC rule 생성을 한다.
<제4 실시예>
도 12는 본 발명의 제4-1 실시예에 따라 이동 통신 사업자 망과 응용 서버에 등록하는 방법을 나타낸는 도면이다.
1-a.사용자가 MCPTT 단말(1200)을 켜면, 단말(1200)은 LTE망(1210)에 Attach 절차를 수행하여 접속한다. Attach 절차를 통하여 단말(1200)은 LTE 인증 절차도 수행하게 되고, IP 연결을 제공받는다.
1-b.사용자는 MCPTT Client를 동작시킨다. MCPTT client는 MCPTT 서비스를 위한 어플리케이션을 의미한다. MCPTT Client는 URI를 통해 Identity Management Function(1220)에 접속한다. MCPTT Client는 Identity Management Function(1220)과 HTTPS 연결을 맺고, TLS 연결을 수립하여 인증(Authenication) 절차를 수행한다. MCPTT 사용자는 사용자 Credentials(예: 지문, 홍채인식 등의 Biometics 또는 보안된 사용자 ID, ID/패스워드)을 이용하여 Identity Management function에 접속, 사용자 인증을 확인한다.
상기 user credential은 Mission Cricical 서비스의 user ID인 MC User ID를 포함할 수 있다. 또한 UE(1200)는 service 식별자를 전달할 수도 있다. Service 식별자는 MC 서비스 중 특정 서비스를 가리킬 수 있다. 예를 들어 PTT를 가리킬 수 있다.
1-c.MCPTT Client는 Identity Management Function(1220)으로 Token을 요청한다. 이 Token은 MCPTT AS(1250)에 등록을 할 때 단말을 인증하기 위해 사용된다. (이를 본 발명에서는 Token A라 칭한다) 단말이 SIP core(혹은 IMS)에 접속할 수 있는 Credential이 없거나, 단말이 SIP core(혹은 IMS)에 등록절차를 수행하기 위해 허용되지 않았다면, MCPTT Client는 추가적으로 IMS 등록을 위한 Token을 요청할 수 있다. (이를 본 발명에서는 Token B라 칭한다) ID management server는 하나 이상의 서비스에 대한 사용자 ID를 보내줄 수 있다.이는 MCPTT user ID라 불릴 수 있다.
MCPTT Client는 상기 Token A와 Token B를 각각 서로 다른 Identity Management Function(1220)으로부터 획득할 수 있다. 한 Identity Management Function(1220)은 MCPTT AS(1250)에 대한 Identity만 관리하고, 다른 Identity Management Function(1220)은 SIP Core(혹은 IMS)에 대한 Identity를 관리할 수 있다.
2.MCPTT 단말(1200)은 SIP Core(혹은 IMS)와 보안 연결을 수립한다. 이 연결을 이용하여 단말은 SIP 기반 인증 및 등록 절차를 수행할 수 있다.
3-a.MCPTT 단말(1200)은 SIP core(혹은 IMS)에 등록 절차를 수행한다. 이를 위해 단말은 SIP Registration 메시지를 SIP Core(혹은 IMS)로 전달하며, IMS credential 혹은 Token B를 포함한다. Token B가 사용되는 경우, eP-CSCF(1230)는 Token으로부터 IMS identity를 유도하고, MCTT 단말(1200)이 보낸 SIP Registration 메시지에 대한 응답으로 OK response를 보내면서, IMS identity를 포함하여 전달한다. 이 IMS Identity는 추후 단말이 SIP 메시지를 보낼 때 사용한다. MCPTT Client는 본 단계의 SIP Registration 메시지에 Token A를 포함하고, 이 Token A는 S-CSCF로 전달된다.
3-b.S-SCSF(1240)는 Token A와 IMS Identity를 MCPTT AS(1250)에게 전달한다. MCPTT AS(1250)는 Token A를 확인하여, 사용자 인증이 성공한 경우, MCPTT User ID를 단말에게 전달한다. MCPTT User ID와 IMS Identity는 MCPTT AS내에서 한 단말에 대하여 연관 되어 있다. MCPTT AS(1250)로의 Registration 절차는 SIP Core(혹은 IMS) Registration 절차와 함께 수행될 수 있다.
도 13은 본 발명의 제4-2 실시예에 따라 이동 통신 사업자 망과 응용 서버에 등록하는 방법을 나타낸는 도면이다.
1-a.사용자가 MCPTT 단말(1300)의 전원을 켜면, 단말은 LTE망(1310)에 Attach 절차를 수행하여 LTE 인증을 수행하고, IP 연결을 획득한다.
1-b.사용자는 MCPTT Client를 실행한다. MCPTT Client는 URI를 사용하여 Identity Management Function(1320)에 접속하고, 이와 HTTPS 연결을 수립한다. TLS 연결을 수립하여 Identity Management Function을 인증한다. MCPTT 사용자는 사용자 Credentials(예: 지문, 홍채인식 등의 Biometics 또는 보안된 사용자 ID, ID/패스워드)을 이용하여 Identity Management function에 접속, 사용자 인증을 확인한다.
1-c.MCPTT Client는 Identity Management Function(1320)으로 Token을 요청한다. 이 Token은 MCPTT AS(1350)에 등록을 할 때 단말을 인증하기 위해 사용된다. (이를 본 발명에서는 Token A라 칭한다) 단말이 SIP core(혹은 IMS)에 접속할 수 있는 Credential이 없거나, 단말이 SIP core(혹은 IMS)에 등록절차를 수행하기 위해 허용되지 않았다면, MCPTT Client는 추가적으로 IMS 등록을 위한 Token을 요청할 수 있다. (이를 본 발명에서는 Token B라 칭한다)
MCPTT Client는 상기 Token A와 Token B를 각각 서로 다른 Identity Management Function(1320)으로부터 획득할 수 있다. 한 Identity Management Function(1320)은 MCPTT AS(1350)에 대한 Identity만 관리하고, 다른 Identity Management Function(1320)은 SIP Core(혹은 IMS)에 대한 Identity를 관리할 수 있다.
1-d.MCPTT Client는 MCPTSS AS(1350)에 Registration 절차를 수행한다. MCPTT Client는 Token A와 IMPU(단말의 공개 ID: IP Multimedia Public Identity)를 MCPTT AS(1350)로 전달한다. MCPTT AS(1350)는 수신한 Token A를 검증하여 MCPTT User ID를 도출한다. UE(1300)는 IMPU를 ISIM(IP multimedia service identity)에 설정된 정보에서 획득하거나, Token B에서 획득할 수 있다. MCPTT AS(1350)는 상기에서 도출해낸 MCPTT User ID와 IMPU를 연관지어서 저장한다.
2.MCPTT 단말(1300)은 SIP Core(혹은 IMS)와 보안 연결을 수립한다. 이 연결을 이용하여 단말은 SIP 기반 인증 및 등록 절차를 수행할 수 있다
3-a.MCPTT 단말(1300)은 SIP Core(혹은 IMS)에 등록 절차를 수행한다. 이 때 ISIM이나 Token B에서 획득한 IMS Credential(예: IMPU)을 사용하여 SIP registration에 사용할 수 있다.
도 14는 본 발명의 제4-3 실시예에 따라 이동 통신 사업자 망과 응용 서버에 등록하는 방법을 나타낸는 도면이다
1.사용자가 MCPTT 단말(1400)의 전원을 켜면, 단말은 LTE망(1410)에 Attach 절차를 수행하여 LTE 인증을 수행하고, IP 연결을 획득한다
2.사용자는 MCPTT Client(1400)를 실행한다. MCPTT Client(1400)는 URI를 사용하여 Identity Management Function(1420)에 접속하고, 이와 HTTPS 연결을 수립한다. TLS 연결을 수립하여 Identity Management Function(1420)을 인증한다.
3.MCPTT client(1400)는 사용자 허가 (Authorisation) 절차를 수행한다. 이를 위하여 Authentication 요청 메시지를 Identity Management Function(1420)에게 전달한다. 이 메시지에는 IMPU 혹은 Identity Management Function(1420)에서 식별할 수 있는 user ID, 혹은 User Credential이 포함될 수 있다.
사용자는 User Credential을 지문, 홍채인식 등의 Biometics 또는 보안된 사용자 ID, ID/패스워드를 이용하여 사용자 인증을 확인한다. 상기 user credential은 MC user ID를 포함할 수 있다. 또한 UE는 service 식별자를 전달할 수도 있다. Service 식별자는 MC 서비스 중 특정 서비스를 가리킬 수 있다. 예를 들어 MCPTT를 가리킬 수 있다. 이 명세서에서 그냥 user ID는 서비스가 MCPTT인 경우에는 MCPTT user ID를 가리킨다.
Identity Management Function(1420)은 User ID 혹은 User Credential을 이용하여 사용자를 인증한다. 만약 인증이 성공적으로 완료되었으면, Identity Management Function(1420)은 IMPU와 User ID를 기반으로 Token을 생성한다. 이처럼 생성된 Token을 이용하여 IMPU와 User ID라 도출될 수 있다.Identity Management Function(1420)은 인증 응답 메시지에 Token을 포함하여 단말에게 전송한다.
4.MCPTT Client(1400)는 SIP registration 메시지를 P-CSCF(1430)에게 전송하고, 이 메시지는 I-CSCF와 S-CSCF(1440)로 전달된다. 상기 Registration 메시지는 IMPU/IMPI, User ID 등을 포함한다.이후, MCPTT Client(1400)는 IMS AKA 인증을 요구 받는다. (Challenged)
5.인증을 요구 받은 MCPTT Client(1400)는 IMS AKA 응답과 IMPU/IMPI 또는 User ID를 포함한 Registration 메시지를 I-CSCF와 S-CSCF(1440)에게 전달한다. 이 때 MCPTT Client(1400)는 상기 절차에서 수신한 Token을 포함한다.
IMS AKA 응답은 S-CSCF(1440)로부터 검증받는다.
6.IMS AKA 응답이 유효하면, S-CSCF(1440)는 MCPTT AS(1450)와 3rd party Registration 절차를 수행한다. S-CSCF(1440)는 IMPU와 User ID, Token을 포함한 Register 메시지를 MCPTT AS(1450)에게 전송한다.
MCPTT AS(1450)는 Token을 검증한다. Token이 유효한 것으로 판단되면, MCPTT AS(1450)는 수신한 User ID가 유효하다고 판단한다. 그리고 Token으로부터 User ID와 IMPU를 도출해내고, 이 것이 상기 단계에서 S-CSCF로부터 수신한 User ID 및 IMPU와 같은지 확인한다. 매칭이 되었다면, MCPTT AS(1450)는 IMPU와 User ID를 연관지어 저장하고, 추 후 IMPU 혹은 User ID에 대해서 수신한 메시지를 상호 식별하는데 사용한다.MCPTT AS(1450)는 OK message를 전송하여 ACK한다.
7.S-CSCF(1440)는 수신한 OK message를 MCPTT Client(1450)에게 전달한다.
도 15는 본 발명의 제4-4 실시예에 따른 MCPTT UE 인증을 위한 IMS AKA 인증 절차를 MCPTT UE와 SIP Core(혹은 IMS) 사이에 수행하는 것을 나타낸 도면이다. 그리고 MCPTT UE와 MCPTT AS 간 TNA(Trusted Node Authentication)절차를 나타낸다.
1. 사용자가 MCPTT 단말(1500)의 전원을 켜면, 단말(1500)은 LTE망(1510)에 Attach 절차를 수행하여 LTE 인증을 수행하고, IP 연결을 획득한다
2.사용자는 MCPTT Client를 실행한다. MCPTT Client는 URI를 사용하여 Identity Management Function(1520)에 접속하고, 이와 HTTPS 연결을 수립한다. TLS 연결을 수립하여 Identity Management Function(1520)을 인증한다
3. MCPTT client는 사용자 허가 (Authorisation) 절차를 수행한다. 이를 위하여 Authentication 요청 메시지를 Identity Management Function(1520)에게 전달한다. 이 메시지에는 IMPU 혹은 Identity Management Function(1520)에서 식별할 수 있는 user ID, 혹은 User Credential이 포함될 수 있다. 사용자는 User Credential을 지문, 홍채인식 등의 Biometics 또는 보안된 사용자 ID, ID/패스워드를 이용하여 사용자 인증을 확인한다Identity Management Function(1520)은 User ID 혹은 User Credential을 이용하여 사용자를 인증한다. 만약 인증이 성공적으로 완료되었으면, Identity Management Function(1520)은 IMPU와 User ID를 기반으로 Token을 생성한다. Token은 IMPI와 IMPU, 그리고 허가된 Token 범위로 연관되어 구성된다.
Identity Management Function(1520)은 인증 응답 메시지에 Token을 포함하여 단말에게 전송한다
4.단말(1500)은 IMS registration 절차를 수행하고, Signalling 연결에 대한 인증을 수행하기 위해 IMS AKA를 수행한다. 단말은 MCPTT User ID와 Token을 포함하여 S-CSCF(1540)로 전달하고, 이는 MCPTT User 인증을 위해서 사용된다.
5.IMS AKA가 성공적으로 수행되었다면, S-CSCF(1540)는 3rd party registration 절차를 MCPTT AS와 수행한다. 상기 단계 4로부터 전달받은 IMPU, MCPTT User ID와 Token을 이용하여, MCPTT AS에 Registration 메시지를 전송한다. MCPTT 서버(1550)는 Token을 검증하고, Token이 유효하면, MCPTT AS는 수신한 User ID를 신뢰한다고 판단한다.
그리고 Token으로부터 IMPU와 MCPTT User ID를 도출하여, 상기 Registration 메시지로부터 수신한 IMPU 및 MCPTT User ID와 일치하는지 확인한다. 확인에 성공하면, MCPTT AS는 IMPU와 MCPTT User Identity를 연관지어 저장한다.MCPTT AS(1550)는 Ok message를 S-CSCF(1540)로 보내어 ACK한다.
6.S-CSCF(1540)는 Ok message를 MCPTT Client에게 전송하여 ACK한다.
도 16은 본 발명의 제4-5 실시예에 따른 MCPTT UE 인증을 위한 IMS AKA 인증 절차를 MCPTT UE와 SIP Core(혹은 IMS) 사이에 수행하는 것을 나타낸 도면이다.
Encryption key를 직접적으로 전달할 수도 있지만, key setup 정보를 주고받을 수 있다. MCPTT AS는 decryption을 할 수 없을 수 있다. 이 경우, MCPTT AS는 ID Management server 및/혹은 config. Managemenet server에게 필요 시 encrypted MCPTT group/user ID를 보내주고, decrypted MCPTT group/user ID를 받을 수 있다.
도 16에서 수행되는 1 내지 3 단계는 앞서 설명한 도 15의 1 내지 3 단계와 실질적으로 동일하여 자세한 설명은 생략한다.
Identity Management Function(1620)은 User ID와 User Credential을 이용하여 사용자를 인증한다. 인증이 성공했다면, Identity Management Function(1620)은 인증 응답 메시지를 단말에게 전달하고, MCPTT AS에게 단말이 인증되었음을 알린다. 이 메시지에는 IMPU, User ID, 그리고 이 유효한 인증에 대한 Valid time이 포함된다. MCPTT Server는 상기 메시지를 수신 한 후, Validity Timer를 시작한다.
4.MCPTT Client(1600)는 P-CSCF(1630)로 Registration 메시지를 전송하고, 이 메시지는 I-CSCF와 S-CSCF(1640)로 전달된다. 상기 Registration 메시지는 IMPU/IMPI, 암호화된 User ID가 포함된다. MCPTT User Identity가 MCPTT AS외의 entity에 노출되지 않기 위해, MCPTT Client(1600)는 MCPTT User ID를 암호화하여 Registration에 포함한다
Identity management function(1620) 대신, Configuration management function이 encryption key를 제공할 수 있다.
그 후 MCPTT Client(1600)는 IMS AKA를 요구받는다.
5.MCPTT Client(1600)는 IMS AKA를 수행한 후 그 응답을 IMPU, IMPI, 암호화된 User ID와 함꼐 S-CSCF로 전달한다.
S-CSCF(1640)는 IMS AKA 응답을 검증한다.
6.IMS AKA가 성공적으로 수행되었다면, S-CSCF(1640)는 3rd party registration 절차를 MCPTT AS(1650)와 수행한다. S-CSCF(1640)는 Registration 메시지를 IMPU와 User ID를 포함하여 MCPTT AS(1650)에게 전송한다.
MCPTT AS(1650)는 이 User ID가 유효하다고 판단하고, 상기 단계 3-d에서 수신한 User ID, IMPU와 동일한지, 그리고 Validity timer가 아직 만료되지 않았는지 확인한다. 상기 절차가 성공적으로 진행된 후, MCPTT AS(1650)는 IMPU와 User ID를 연관 짓고 저장한다. 이 연관된 ID는 추후 사용되는 메시지에서 사용되는 단말의 식별자를 통해 상호 식별하기 위하여 사용된다. MCPTT AS(1650)는 암호화된 MCPTT User Identity를 복호화한다.
MCPTT Server(1650)는 OK Message를 S-CSCF(1640)로 전송하여 ACK한다.
7.S-CSCF(1640)는 OK message를 MCPTT Client(1600)에게 전달하여 ACK한다.
도 17은 본 발명의 제4-6 실시예에 따른 MCPTT UE 인증을 위한 IMS AKA 인증 절차를 MCPTT UE와 SIP Core(혹은 IMS) 사이에 수행하는 것을 나타낸 도면이다.
IMS registration을 수행하면, S-CSCF에서 3rd party registration까지 수행한다. 이전 발명의 내용은 Registration을 수행한후, IMS AKA를 수행하도록 Challenge 받은 후, 다시 Registration하는 절차를 나타낸다.Encryption key를 직접적으로 전달할 수도 있지만, key setup 정보를 주고받을 수 있다. MCPTT AS는 decryption을 할 수 없을 수 있다. 이 경우, MCPTT AS는 ID Management server 및/혹은 config. Managemenet server에게 필요 시 encrypted MCPTT group/user ID를 보내주고, decrypted MCPTT group/user ID를 받을 수 있다.
도 18은 본 발명의 제4-7 실시예에 따른 MCPTT UE 인증을 위한 IMS AKA 인증 절차를 MCPTT UE와 SIP Core(혹은 IMS) 사이에 수행하는 것을 나타낸 도면이다.
도 18에서는 Token 1을 IMS 인증에 사용하고, Token 2를 MCPTT AS 인증에 사용하는 발명으로, 암호화된 정보를 사용할 수 있다.
Encryption key를 직접적으로 전달할 수도 있지만, key setup 정보를 주고받을 수 있다. MCPTT AS는 decryption을 할 수 없을 수 있다. 이 경우, MCPTT AS는 ID Management server 및/혹은 config. Managemenet server에게 필요 시 encrypted MCPTT group/user ID를 보내주고, decrypted MCPTT group/user ID를 받을 수 있다.
도 18에서 수행되는 1 내지 3 단계는 앞서 설명한 도 15의 1 내지 3 단계와 실질적으로 동일하여 자세한 설명은 생략한다.
Identity Management Function(1820)은 MCPTT Client(1800)에게 암호화 키를 제공할 수 있다. 이 암호화 키는 MCPTT User Credential을 암호화하는데 쓰이고, 이는 SIP Core(혹은 IMS)에서 해석될 수 없다.
Identity Management Function(1820)은 User ID와 User Credential을 이용하여 사용자를 인증한다. 만약 인증이 성공적이라면, Identity Management Function(1820)은 Token 2개를 생성한다. 이를 Token 1과 Token 2로 칭하겠다. Token 1은 IMPU와 IMPI 쌍을 기반으로 생성된다. Token 1으로부터 IMPU와 IMPI가 도출될 수 있다. Token 2는 IMPU와 User ID 기반으로 생성된다. Token 2로부터 IMPU와 User ID가 도출될 수 있다.
Identity Manageent Function(1820)은 인증 응답 메시지에 Token 1과 Token 2를 포함하여 MCPTT Client에게 전송한다.
4.MCPTT Client(1800)는 수신한 Token들과 암호화된 User ID를 포함하여 Registration 메시지를 eP-CSCF(1830)에게 보낸다. MCPTT User ID가 MCPTT AS 외에 노출되지 않기 위해, MCPTT Client(1800)는 User ID를 암호화하여 메시지에 포함시킨다.
eP-CSCF(1830)는 Token 1을 검증하여 IMPU와 IMPI를 획득한다. Token 1의 검증이 성공했다면, eP-CSCF(1830)는 Registration 메시지를 IMPU, IMPI, User ID, Token 2를 포함하여 S-CSCF에게 전달한다. S-CSCF(1840)는 Trusted Node Authentication 절차를 수행하여 추가적인 인증절차 없이 Registration 절차를 수행한다. 이 때 인증이 이미 되었다는 Indication을 포함할 수 있다.
5.S-CSCF(1840)는 3rd party registration을 MCPTT AS(1850)와 수행한다. S-CSCF(1840)는 Registration 메시지에 IMPU, 암호화된 User ID, Token 2를 포함하여 MCPTT AS에 전송한다.
MCPTT AS(1850)는 Token 2를 검증한다. Token이 유효하다고 검증되었다면, MCPTT AS는 User ID가 유효하다고 판단하고, Token 2로부터 도출한 User ID와 IMPU가 상기 메시지로부터 수신한 IMPU, User ID와 동일한지 확인한다. 동일하게 판단이 되었다면, MCPTT AS(1850)는 IMPU와 MCPTT User ID를 연관지어서 저장한다. MCPTT AS는 암호화된 User ID를 복호화한다. MCPTT AS(1850)는 Identity management function으로부터 암호화 키를 수신했거나, 암호화 키가 미리 설정되었을 수 있다.
MCPTT AS(1850)는 OK message를 S-CSCF(1840)로 전송하여 ACK한다.
7.S-CSCF(1840)는 Ok message를 MCPTT Client(1800)에게 전송하여 ACK한다.
도 19는 본 발명의 제4-8 실시예에 따른 IMS Registraion을 시도하면 S-CSCF가 3rd party registration을 시도하는 것을 나타낸 도면이다.
MCPTT 단말(1900)과 SIP Core(혹은 IMS)는 IMS AKA 인증을 통해서 MCPTT 단말(1900)을 인증한다. TNA(Trusted Node Authentication)에 의해, S-CSCF(1940)가 MCPTT Client(1900)와 MCPTT Server(1950) 간의 MCPTT User 인증을 수행한다. Encryption key를 직접적으로 전달할 수도 있지만, key setup 정보를 주고받을 수 있다. MCPTT AS는 decryption을 할 수 없을 수 있다. 이 경우, MCPTT AS는 ID Management server 및/혹은 config. Managemenet server에게 필요 시 encrypted MCPTT group/user ID를 보내주고, decrypted MCPTT group/user ID를 받을 수 있다.
도 19에서 수행되는 1 내지 3 단계는 앞서 설명한 도 15의 1 내지 3 단계와 실질적으로 동일하여 자세한 설명은 생략한다.
Identity Management Function(1920)은 MCPTT Client(1900)에게 암호화 키를 제공할 수 있다. 이 암호화 키는 MCPTT User Identity를 암호화하는데 사용된다. 암호화된 MCPTT User Identity는 SIP Core(혹은 IMS)에서 해석되지 못한다.
Identity Management Function(1920) 대신에 Configuration management function이 암호화 키를 제공할 수 있다.
도 17을 기반으로 한다면, explicitly 단계 3-d에서 encryption key 및/혹은 key setup 정보가 MCPTT AS로 전달될 수 있다.
도 18을 기반으로 해도 비슷하게 응용 가능 단계 3에서 encryption key 및/혹은 key setup 정보가 client로 전달된다.
4.단말(1900)은 IMS Registration을 수행하고, IMS AKA를 수행하여 인증한다. 단말(1900)은 Registration 메시지에 MCPTT User identity와 token을 포함하고, 이는 MCPTT 사용자 인증에 사용된다. MCPTT User Identity가 암호화 되었다면, MCPTT Client는 암호화된 MCPTT user ID를 Registration 메시지에 포함한다.
5.IMS AKA가 성공적으로 수행되었다면, S-CSCF(1940)는 3rd party registration 절차를 MCPTT AS(1950)와 수행한다. S-CSCF(1940)는 Registration 메시지를 IMPU와 MCPTT User ID, Token을 포함하여 MCPTT AS(1950)에게 전송한다. MCPTT AS(1950)는 Token을 검증하여, Token이 유효하면 이 User ID가 유효하다고 판단한다. 그리고 Token으로부터 도출한 IMPU와 MCPTT User ID가 상기 Registration 메시지로부터 수신한 MCPTT User ID와 IMPU와 동일한지 확인한다. 확인을 마치고, MCPTT AS는 IMPU와 MCPTT User Identity를 연관짓고 저장한다. 따라서 추 후 IMPU 혹은 MCPTT User Identity에 대해서 오는 메시지가 어느 MCPTT User Identity 혹은 IMPU에 해당하는지를 식별할 수 있다.
MCPTT AS(1950)는 MCPTT user identity를 복호화한다. MCPTT AS(1950)는 복호화하기 위한 키를 ID management function으로부터 제공받았거나, 미리 설정받은 값을 이용할 수 있다.MCPTT AS(1950)는 OK message를 보내어 ACK한다.
도 20은 본 발명의 제4-9 실시예에 따른 암호화 없이, Registration 메시지에 MCPTT User ID를 포함하지 않는 경우를 나타낸다.
도 20에서 수행되는 1 내지 3 단계는 앞서 설명한 도 15의 1 내지 3 단계와 실질적으로 동일하여 자세한 설명은 생략한다.
4.MCPTT User Identity가 SIP Core 혹은 IMS에 노출되지 않아야한다면, MCPTT Client는 MCPTT User ID를 Registration 메시지에 포함하지 않는다.
5.만약 Registration 메시지가 MCPTT user identity를 포함하지 않는다면, MCPTT AS는 Token으로부터 도출해낸 MCPTT User identity와 IMPU를 검증하지 않는다. 대신 Token이 유효하다면, token으로부터 도출한 MCPTT User Identity 와 IMPU를 저장하고, 이 둘을 연관지어 MCPTT 서비스에 사용한다.
MCPTT AS는 Ok message를 전달하여 ACK한다.
도 21은 본 발명의 제4-10 실시예에 따른 MCPTT 인증 과정을 설명하기 위한 도면이다.
전원이 켜진 뒤, MCPTT 단말(2100)은 LTE 인증을 수행한다.
?Step A: MCPTT Client에 설정된 정보에 따라, 단말(2100)은 Token 기반으로 MCPTT User 인증 절차를 수행한다. 단말(2100)은 Identity Management Server(2120)로부터 Token을 획득한다. Token은 Step C에서 MCPTT 인증을 할 때 사용된다.
단말은 MC User ID를 Identity management server(2120)로 전달하고, 다른 User Credential도 함꼐 전달한다. Service ID(예: 뉴욕경찰_MCPTT)도 함께 제공될 수 있다. Identity Management Server(2120)는 Service User ID, 즉 MCPTT User ID를 단말에게 회신한다. Token으로부터 Service User ID, 즉 MCPTT User ID를 도출할 수 있다.
?Step B: MCPTT 단말(2100)과 IMS(2130) 사이에 IMS 인증 절차를 수행한다.
?Step C: IMS인증이 수행된 후, MCPTT user 인증이 수행된다.
MCPTT Server(2140)가 이동통신사업자에 의해서 관리될 경우, Public Safety user Data Function (PS-UDF) 또는 HSS는 MCPTT user credential을 저장하고 있고, 이는 MCPTT 사용자 인증에 쓰인다. 또한 상호 인증 절차를 통해서 Security 정보가 생성될 수 있다. MCPTT server(2140)가 공공 안전망 Agency에 의해서 관리 받는 경우, PS-UDF가 MCPTT 사용자 인증에 필요한 Credential을 저장하고 있고, 상호 인증 절차에 의해 Sercurity 정보를 생성한다.
도 22는 본 발명의 제4-11 실시예에 따른 MCPTT 사용자 인증 절차를 설명하기 위한 도면이다.
MCPTT-1 interface를 통한 MCPTT 사용자 인증 절차를 위해서, 아래의 절차가 수행될 수 있다.
-SIP Digest authentication (IMS registration을 의미함.)
-Token based authentication.
3. Identity Management Function(2220)은 MC User identity와 MC user 인증 credential을 이용하여 사용자를 인증한다. 인증이 성공적이면, Identity management function(2220)은 IMPU, MC user ID, Service ID를 기반으로 Token을 생성한다. 또는 Token은 IMPU, MC service user ID(MC user ID와 Service ID로부터 도출된)를 기반으로 생성될 수 있다. Token은 MCPTT user ID와 IMPU등 관련된 Authorisation 정보들과 함께 인코딩될 수 있다. MCPTT User ID는 단말에게 명시적으로 전달되지 않을 수 있으며, 대신 Token으로 추후에 도출가능하다.
Identity Management Function(2220)은 인증 응답메시지에 Token을 포함하여 단말에게 전달한다.
4. MCPTT User ID는 Token으로부터 도출될 수 있기 때문에, INVITE 메시지는 MCPTT User ID를 포함하지 않을 수 있다.
5.S-CSCF(2240)는 ok message를 MCPTT client(2200)에 보내어 ACK 한다.
6.IMS AKA 인증이 성공적으로 수행된 후, S-CSCF(2240)는 3rd party registration을 MCPTT sever(2250)에 대하여 수행한다. S-CSCF(2240)는 Register 메시지에 IMPU, MCPTT User ID, Token을 포함하여 보낸다. MCPTT User ID는 상기 메시지에 포함되지 않을 수 있으며, 이 경우 Token을 이용하여 MCPTT User ID를 도출해낼 수 있다. MCPTT server(2250)는 Token을 검증한 후, Token이 유효하면 수신한 MCPTT User ID를 신뢰한다. 수신한 MCPTT user ID가 없을 경우 Token으로부터 도출한 MCPTT User ID를 단말에 대한 MCPTT User ID로 사용한다. MCPTT AS(2250)는 IMPU와 MCPTT User ID를 연관지어 저장한다.
?
<제5 실시예>
제5 실시예는 효율적인 방송 관련 시그널링 전달 방법 및 장치에 관한 것이다.
도 23은 본 발명의 제5 실시예에 따른 방송 관련 시그널링 전달 방법을 설명하는 도면이다.
UE는 ECGI 를 GCS AS(2340)에 보낼 수 있다. GCS AS(2340)는 configuration 정보에 따라 BM-SC(2330)에게 ECGI list를 보낼지 말지를 정할 수 있다. 이 configuration 정보는 operator policy에 따라 구현에 따른 방법으로 GCS AS(2340)에게 available하게 할 수도 있고, BM-SC(2330)와 GCS AS (2340)간의 시그널링을 통해 GCS AS(2340)에게 available해질 수 있다.
1.GCS AS(2340)가 MB2 인터페이스로 MBMS bearer를 활성화 하기 위하여 GCS AS(2340)는 Activate MBMS Bearer Request 메시지를 BM-SC(2330)로 전달한다. 상기 메시지에는 TMGI를 포함할 수 있으며, 상기 TMGI는 MBMS bearer를 식별할 수 있다. 또한 Flow ID, QoS, MBMS Broadcast area, 그리고 MBMS 시작 시간을 포함할 수 있다.
Flow ID는 TMGI가 포함되었을 경우만 포함되며, TMGI에 해당하는 MBMS traffic에서 특정 Flow를 구별하기 위해 사용된다. Flow ID가 상기 메시지에 포함되었다면, BM-SC는 이를 상기 메시지에서 전달된 TMSI에 연관을 시키고, 또한 상기 MBMS Broadcast area에 연관을 시킨다. (Association) 상기 QoS 값은 MBMS bearer에 대한 우선순위를 나타내는 값으로 매핑된다. 만약 상기 MBMS Broadcast Area가 Cell ID의 list를 포함한다면, BM-SC(2330)는 Cell ID를 MBMS service area(SA)의 set에 매핑한다. GCS AS(2340)는 ECGI list를 보낼 때에도 MBMS SA를 보낼 수 있다.
BM-SC(2330)는 이 MBMS SA를 무시하고 앞 문장에서 설명한 대로 얻어낸 MBMS SA로 re-write할 수 있다. ECGI list를 수신한 경우, BM-SC(2330)는 MBMS SA를 Activate MBMS Bearer Response에 넣어서 준다. 이를 이용해서 GCS AS(2340)는 MBMS service data를 구성하는 데 사용할 수 있다. ECGI list를 수신하지 않았다면 BM-SC(2330)는 Activate MBMS Bearer Response에 MBMS SA를 넣지 않는다.
1단계에 대한 다른 세부 실시 예로, GCA AS(2340)가 MB2 interface로 MBMS bearer를 활성화 시키고 싶다면, GCA AS(2340)는 Activate MBMS Bearer request 메시지를 BM-SC(2330)로 전달한다. 상기 메시지에는 TMGI, QoS, MBMS Broadcast Area, 그리고 Start time이 포함될 수 있다. TMGI는 MBMS bearer를 식별할 수 있다. MBMS Broadcast area는 MBMS service Area Identity의 List를 포함하거나, Cell ID의 list를 포함하거나, 둘 다 포함할 수 있다.
MBMS Broadcast area가 MBMS Service Area Identity 리스트를 포함하고 있다면, MBMS Service Area Identity는 UE가 보낸 Cell ID의 list나 다른 설정 정보에 따라서 확인된다.
TMGI가 상기 메시지에 포함되었다면, BM-SC(2330)는 GCS-AS(2340)가 해당 TMGI를 사용할 수 있도록 허가 받았는지 판단한다. 만약 GCS-AS(2340)가 해당 TMGI를 사용하도록 허가 받지 않았다면, BM-SC(2330)는 상기 요청을 거절한다. TMGI가 상기 메시지에 포함되지 않았다면, BM-SC(2330)는 지금까지 사용되지 않은 TMGI값을 할당한다.
BM-SC(2330)는 상기 TMGI와 MBMS Broadcast area에 대해서 Flow ID를 할당한다. MBMS Broadcast area 파라메터가 Cell ID의 리스트를 포함하고 있다면, BM-SC(2330)는 Cell ID를 MBMS Service Area Identity에 매핑한다. Cell ID 기반 매핑은 이동통신 사업자의 정책에 따를 수 있다. BM-SC(2330)는 MBMS service area identity의 리스트를 MBMS Session Start message에 포함한다. 추가적으로 Cell ID 리스트도 MBMS Session Start message에 포함될 수 있다. 만약 같은 TMGI에 대해서 이미 활성화된 다른 MBMS bearer가 있다면, BM-SC(2330)는 현재 존재하는 MBMS Bearer에 대해서 MBMS Broadcast arear가 중복되지 않도록 제어한다. 그리고 새로운 MBMS Bearer에는 Unique한 Flow ID를 할당하여 구별한다.
그 후 BM-SC(2330)는 MBMS Bearer를 이용한 Contents delivery를 위하여, 해당 MBMS broadcast area에 대한 MBMS 자원을 할당하고 Session Start procedure를 수행한다.MBMS Session Start Request message에 들어가는 MBMS SAI(s)는 BM-SC(2330)가 GCS AS(2340)로부터 수신한 셀 식별자(들)로부터 얻어낸 정보일 수 있다. 즉, 보다 일반적으로 말해서 GCS AS(2340)가 보낸 MBMS SAI(s)와 다른 MBMS SAI(s)일 수 있다. 이 경우(GCS AS가 보내는 Activate MBMS Bearer Request 메시지에 포함된 MBMS SAI(s)와 BM-SC가 보내는 MBMS ;GCS AS가 MBMS SAI(s)를 안 보낸 경우도 포함), BM-SC(2330)는 MBMS Session Start Request message에 포함되는 MBMS SAI(s)를 Activate MBMS Bearer Response 메시지에 포함시킬 수 있다.
2.BM-SC(2330)는 Cell ID list(ECGIs)를 Service area list(SAIs)에 매핑하고, 관련 지역에 대한 MBMS-GW(s)를 결정한다.
3.BM-SC(2330)는 Session Start message를 상기에서 결정된 MBMS-GW(s)로 전송한다. 상기 메시지에는 3GPP Release-12에 맞는 MBMS 관련 Paramter가 포함되어 있으며, Cell Id list(List of ECGIs)가 포함될 수 있다.
4.MBMS-GW(2320)는 Session Start message를 관련된 MME(involved MME(s))에 전송한다. 상기 메시지에는 3GPP Release-12에 맞는 MBMS 관련 Paramter가 포함되어 있으며, Cell Id list(List of ECGIs)가 포함될 수 있다.
5.MME(2310)는 Session Start message를 관련된 MCE(involved MCE(s))에 전송한다. 상기 메시지에는3GPP Release-12에 맞는 MBMS 관련 Paramter가 포함되어 있으며, Cell Id list(List of ECGIs)가 포함될 수 있다. MME(2310)가 Session Start 메시지의 수신 대상을 고를 때, 수신한 ECGI list와 MBMS SA를 포함한 existing parameters를 이용할 수 있다.
MME(2310)는 S1 Setup 혹은 eNB Configuration Update 과정에서 eNB가 연결된 혹은 eNB 내 셀이 연결된 MCE 식별자를 수신했을 수 있다. 혹은 M3 Setup 또는 MCE Configuration Update 과정에서 MCE에 연결된 셀 혹은 eNB 목록을 수신했을 수 있다. 이 정보를 이용하여 수신한 ECGI list에 해당되는 eNB에게만 Session Start 메시지를 전달할 수 있다. MME는 ECGI의 Global eNB ID 부분을 보고 eNB를 식별할 수 있다. 따라서 S1 Setup 혹은 eNB Configuration Update 과정에서 eNB 별 서빙 MCE 정보와 ECGI 정보를 이용해 알맞은 MCE를 고를 수 있다.
여러 MCE들이 MBMS 전송이 이뤄지는 지역에 대해 일관성 있는 결정을 내려야 할 필요가 있을 수 있다 (예를 들어 distributed MCE 구조에서). 하기 내용은 이를 어떻게 achieve할 수 있는지에 대한 설명이다.
<MBMS Session Start procedure in case an MBSFN area is managed by multiple MCEs>
MBMS Session Start 절차를 수행하는 동안, MCE는 MME로부터 M3 interface를 통해 MBMS Session Start request 메시지를 받는다. 이 메시지는 기지국에게 MCCH 관련 정보(MBMS 전송을 위한 라디오 정보)를 제공하고 기지국이 단말에 대해서 MBMS를 보낼 Bearer를 수립하고, 단말에게 MBMS session에 대하여 알리도록 요청한다.
MBSFN 전송 방법을 사용하기 위하여, 하나의 MBSFN Area에 있는 셀들은 반드시 같은 MCCH 관련 정보로 설정되어 있어야 한다. 만약 MBSFN Area가 하나의 MCE로부터 제어된다면, 동기화된 MCCH 정보를 사용할 것임은 자명하다. 만약 MBSFN Area가 여러개의 MCE로부터 제어된다면, 예를 들어 분산된 MCE 구조를 갖는 경우, MCE간 MCCH 관련 정보의 coordination이 필요하다. 또한 분산된 MCE 구조를 갖는 경우, 모든 분산된 MCE들은 하나의 MBSFN area에 대해서 반드시 MBMS session에 대한 동일한 Admission control을 가져야한다.
도 24는 본 발명의 제5 실시예에 따른 복수의 MCE들에 의해 운영되는 MBSFN 영역에 관한 도면이다.
도 24를 참조하면, 분산된 MCE 구조에서, 어떻게 하나의 MBSFN에 있는 여러 Cell이 같은 MCCH 관련 정보를 제공 받는 지 나타낸다.
도 25는 본 발명의 제5 실시예에 따른 동적 조정 MBMS 세션 개시 절차를 설명하는 도면이다. 특히, 도 25는 복수의 MCE들이 MBSFN 영역을 운용하고 OAM이 MCCH 관련 정보를 동적으로 제공하는 경우 MBMS 세션 개시 절차에 관한 것이다.
1.MME(2530)와 MBMS GW는 MBMS Session Start 절차를 수행한다.
2.망 관리 장치(OAM, 2520)는, MME(2530) 혹은 MCE가 MBMS session을 시작했음을 MME 혹은 MCE로부터 알림 받는다. 상기 MBMS 세션에 대한 속성 값들은 OAM(2520)으로 전달되고, 이 값을 기반으로 OAM(2520)은 MCCH 관련 정보를 생성한다.
3.OAM(2520)은 E-UTRAN(2500, 2510)에게 MCCH 관련 정보를 제공한다.
OAM(2520)은 E-UTRAN에게 MME(2530)로부터 수신한 MBMS session에 대한 속성값을 전달할 수 있다. 이 경우 MME(2530)는 M3 interface를 통해서 MBMS Session Start request를 MCE에게 전달하지 않을 수 있다.
4.E-UTRAN은 OAM(2520)으로부터 수신한 정보를 기반으로 RAN 자원을 설정한다.
도 26은 본 발명의 제5 실시예에 따른 정적 조정 MBMS 세션 개시 절차를 설명하는 도면이다. 특히, 도 26은 복수의 MCE들이 MBSFN 영역을 운용하고 미리 설정된 정적 정보에 기반하여 MCCH 관련 정보가 생성되는 경우 MBMS 세션 개시 절차에 관한 것이다.
1.복수개의 MCE들은 하나의 MBSFN area를 관리하도록 설정되어 있고, 이 MCE들은 같은 session 속성을 제공 받았다면, 같은 MCCH 관련 정보를 생성하도록 설정되어 있다.
2.MME(2630)와 MBMS GW는 MBMS Session Start 절차를 수행한다.
3.MME(2630)는 MBMS Session Start 요청 메시지를 MCE들에게 전달한다. 단계 1에서 기 설정된 값에 따라, MCE들은 같은 MCCH 관련 정보를 생성한다.
MBMS Session Start procedure in case an MBSFN area is managed by multiple MCEs 이 전의 Step 5 부터 이어지는 단계는 아래와 같다. (MBMS Session Start 절차 수행 후)
6.MCE는 상기 메시지로부터 수신한 SAI list를 list of MBSFN에 매핑하고, 해당 ECGI list에서 사용되지 않는 MBSFN을 제거한다. MCE는 할당된 혹은 선택된 MBSFNs에 MBMS Bearer를 위한 자원을 할당한다. MCE는 MBMS Bearer가 활성화된 MBSFN의 Cell Id list(list of ECGIs)를 저장한다.
7.MCE는 Session Start response message를 MME에게 전달한다. 상기 메시지에는3GPP Release-12에 맞는 MBMS 관련 Paramter가 포함되어 있으며, 상기 Session start request에 의해서 MBMS Bearer가 활성화된 Cell Id list(List of ECGIs)가 포함될 수 있다.
8.MME는 Session Start response message를 MBMS-GW에게 전달한다. 상기 메시지에는3GPP Release-12에 맞는 MBMS 관련 Paramter가 포함되어 있으며,상기 Session start request에 의해서 MBMS Bearer가 활성화된 Cell Id list(List of ECGIs)가 포함될 수 있다.
9.MBMS-GW는 Session Start response message를 BM-SC에게 전달한다. 상기 메시지에는3GPP Release-12에 맞는 MBMS 관련 Paramter가 포함되어 있으며, 상기 Session start request에 의해서 MBMS Bearer가 활성화된 Cell Id list(List of ECGIs)가 포함될 수 있다.
10.BM-SC는 Activate MBMS Bearer Response message를 GCS AS로 보낸다. 상기 메시지는 TMGI, the FlowID (만약 처음 Activate MBMS Bearer Request 메시지에 포함되었다면, 그와 동일한 값이 포함된다. 혹은 BM-SC로부터 할당된 Flow ID이다.), MBMS service description, 사용자 데이터 전송 평면에 대한 BM-SC의 IP address 와 port 번호, 그리고 만료 시간(expiration time)을 포함한다. MBMS service description에는 MBMS bearer 관련 설정 정보가 포함되며, 이는 TS 26.346에 나열되어 있는 다음의 정보 중 적어도 하나를 포함한다. MBMS service Area, radiofrequency, IP multicast address, APN 등. 만료 시간(expiration time)은 BM-SC가 TMGI를 할당했을 경우, 해당 TMGI의 만료시간을 나타낸다.BM-SC는 특정 경우에만 serviceArea를 포함시킬 수 있다:
Rel-12까지는 service Area를 포함시킬 필요가 없었다. 왜냐하면, BM-SC는 GCS AS가 준 MBMS SAI(s)를 (그대로) 사용했기 때문이다. GCS AS는 UE에게 보낼 service description에 단계 1에서 전달되는 메시지에 포함시켰던 MBMS SAI(s)를 포함시킬 수 있다.
Rel-13부터는 serviceArea를 포함시킬 필요가 있는 경우가 생겼다. BM-SC는, GCS AS로부터 cell ID(s)를 받아 이로부터 (BM-SC에 설정된 정보를 함께 이용하여) 새로이 MBMS SAI(s)를 derive해낼 수 있기 때문이다. 이는 GCS AS로부터 수신한 MBMS SAI(s)와 다를 수 있다 (심지어, GCS AS는 MBMS SAI(s)를 안 보냈을 수도 있음). GCS AS는 BM-SC가 실제로 MBMS downstream node에게 전달하는 MBMS SAI(s)에 대해 인지할 필요가 있다. 그래서 BM-SC는 실제 MBMS downstream node에게 전달되는 MBMS SAI(s)를 GCS AS에게 전달할 수 있고, GCS SA는 UE에게 전달할 service description의 MBMS SAI(s) 부분에 BM-SC에게 받은 MBMS SAI(s)를 포함시켜 UE에게 보낸다.
BM-SC가 Step 2에서 Cell ID 리스트를 MBMS Service Area identity로 매핑했다면, Service description은 반드시BM-SC가 MBMS Session Start 메시지에 포함했던 MBMS service Area identity의 리스트를 포함해야한다. 또 다른 예로, BM-SC가 Step 2에서 Cell ID 리스트를 MBMS Service Area identity로 매핑했다면, Service description은 반드시 Cell ID 리스트와 매핑된 MBMS Service Area identity의 리스트를 포함해야한다. 또 다른 예로, BM-SC가 Step 2에서 cell ID 리스트를 수신했다면(매핑은 하지 않음), Service description은 반드시BM-SC가 MBMS Session Start 메시지에 포함했던 MBMS Service Area Identity 리스트를 포함해야한다. 또 다른 예로, BM-SC가 Step 2에서 cell ID 리스트를 수신했다면(매핑은 하지 않음), , Service description은 반드시 Cell ID 리스트와 매핑 한 MBMS Service Area identity의 리스트를 포함해야한다.
만약 BM-SC가 Activate MBMS Bearer Response 메시지를 9번 메시지를 수신하기 전에 보낸다면, 그리고 9번 메시지에서 수신한 List of ECGIs가 1번 메시지로 수신한 List of ECGIs와 다르다면, BM-SC는 GCS-AS에게 현재 MBMS Bearer가 Activate되어있는 list of ECGIs를 알려주기 위하여 GCS-AS에게 메시지를 9번으로부터 수신한 List of ECGIs를 포함한 메시지를 전송하여 Update할 수 있다.
기지국과 MME간에 기지국이 serving하는 MCE 정보는 아래의 프로시저와 메시지를 이용하여 교환할 수 있다.
제5 실시예에서 S1 Setup, eNB Configuration Update 과정은 도 27 및 도 28과 같이 이뤄진다.
도 27은 본 발명의 제5 실시예에 따른 기지국과 MME 간 S1 셋업 요청을 설명하는 도면이다.
도 27을 참조하면, 기지국(2700)은 MME(2710)로 S1 SETUP REQUEST를 전송하고, MME(2710)로부터 상기 S1 SETUP REQUEST에 상응하는 S1 SETUP RESPONSE를 수신할 수 있다.
도 28은 본 발명의 제5 실시예에 따른 기지국과 MME 간 기지국 설정 업데이트를 설명하는 도면이다.
도 28을 참조하면, 기지국(2800)은 MME(2810)로 ENB CONFIGURATION UPDATE를 전송하고, MME(2810)로부터 상기 ENB CONFIGURATION UPDATE에 상응하는 ENB CONFIGURATION UPDATE ACKNOWLEDGE를 수신할 수 있다.
S1 SETUP REQUEST 메시지는 다음과 같이 정의될 수 있다.
Figure PCTKR2016010783-appb-I000002
Figure PCTKR2016010783-appb-I000003
ENB CONFIGURATION UPDATE 메시지는 다음과 같이 구성될 수 있다
Figure PCTKR2016010783-appb-I000004
Figure PCTKR2016010783-appb-I000005
한편, Global MCE ID는 다음과 같이 정의될 수 있다. 이 ID는 MCE와 MME간 M3 Setup을 맺거나 MCE Configuration을 update할 때 사용된다.
Figure PCTKR2016010783-appb-I000006
본 발명이 제5 실시예에 따른 MCE와 MME간에 MCE와 연결된 기지국 정보는 도 29 및 도 30의 절차와 메시지를 이용하여 교환할 수 있다.
도 29는 본 발명의 제5 실시예에 따른 MCE와 MME간 S3 셋업 요청을 설명하는 도면이다.
도 29를 참조하면, MCE(2900)은 MME(2910)로 S3 SETUP REQUEST를 전송하고, MME(2910)로부터 상기 S3 SETUP REQUEST에 상응하는 S3 SETUP RESPONSE를 수신할 수 있다.
도 30은 본 발명의 제5 실시예에 따른 MCE와 MME간 MCE 설정 업데이트를 설명하는 도면이다.
도 30을 참조하면, MCE(3000)은 MME(3010)로 MCE CONFIGURATION UPDATE를 전송하고, MME(3010)로부터 상기 ENB CONFIGURATION UPDATE에 상응하는 ENB CONFIGURATION UPDATE ACKNOWLEDGE를 수신할 수 있다.
M3 Setup 및 MCE Configuration Update 과정은 다음과 같이 이뤄진다.
Figure PCTKR2016010783-appb-I000007
Figure PCTKR2016010783-appb-I000008
<제6 실시예>
제6 실시예는 재난 안전망(Public-Safety LTE)을 이용하는 단말에게 높은 우선순위를 부여하여 MCPTT 단말이 EPS에서 우선적으로 자원을 할당 받고, 우선적으로 연결을 수립하여 데이터 전송을 할 수 있도록 처리할 수 있는 방법을 제시한다.
재난 안전망(Public Safety LTE, PS-LTE)은 MCPTT(Mission Critical Push To Talk over LTE) 기술을 이용하여 사용자에게 공공 안전을 위한 통신을 할 수 있는 서비스를 제공한다. MCPTT는 3GPP에서 정의한 기술 중 하나이며, 사용자 간 그룹 통신, 일 대 일 통신, 긴급 통화, 재난 알림, 그리고 주변음 청취 등을 포함한 기능을 제공한다. 본 발명에서 MCPTT는 재난 안전망(Public Safety) 서비스의 한 예이며 재난 안전망(Public Safety) 관련한 모든 서비스를 의미할 수 있다.
MCPTT 서비스는 단말과 EPS(Evolved Packet System), SIP(Session Initiation Protocol) Core, 그리고 MCPTT Application Server로 구성된다. EPS는 LTE 망을 의미할 수 있으며, SIP Core는 Session Initiation Protocol을 사용하는 핵심 장치들로 이루어진 네트워크를 의미하며, 그 예로 IMS(Internet Multimedia Subsystem)가 있다. MCPTT 서비스는 다양한 구조로 배치될 수 있다. MCPTT 사업자가 EPS와 SIP Core, 그리고 MCPTT Application Server까지 운영할 수 있으며, MCPTT 사업자가 SIP Core와 MCPTT Application Server를 운영하며 다른 사업자의 EPS와 연동하여 서비스를 제공할 수 있다. 또한 MCPTT 사업자가 MCPTT Application Server만 운영하고 다른 사업자의 EPS와 SIP Core와 연동하여 서비스를 제공할 수 있다.
MCPTT 서비스는 그룹 통화와 일 대 일 통화, 그리고 긴급 알림(Emergency Alert)으로 구분할 수 있다. 그룹 통화는 공공 안전을 위하여 제공하는 일반 통화, 긴급/응급 상황이 발생 했을 경우에 대하여 최우선 순위로 통신을 제공할 수 있는 Emergency Call, 그리고 Emergency Call 보다 우선순위는 낮지만 임박한 긴급/응급 상황에 대비하여 그룹 통신을 할 수 있는 Imminent Peril Call을 지원할 수 있다. 일 대 일 통화는 일반 통화와 Emergency Call, 그리고 상대방의 주변 음을 청취할 수 있는 Ambient Listening 기능을 지원한다. 또한 긴급 알림은 자신의 긴급/응급 상황을 MCPTT 시스템 혹은 다른 MCPTT 사용자에게 알림으로 전달할 수 있는 기능을 의미하며, Emergency Alert이라고 부를 수 있다.
MCPTT가 제공하는 Emergency Call은 기존의 Emergency Call과 다르게 그룹 통신 기능을 지원하며, 따라서 단말이 Emergency call을 발신하는 것뿐만 아니라 수신도 할 수 있어야 한다. Emergency Call과 그 차 순위인 Imminent Peril call, 그리고 Emergency Alert 등 은 EPS, SIP Core 그리고 MCPTT Application Server단에서 모두 일반 통신보다 우선하여 처리될 수 있다. 따라서 상기와 같이 높은 우선순위가 필요한 call은 다른 Call 보다 더 빠른 시간에 연결이 수립되고 데이터를 주고받을 수 있어야 하는 요구사항이 존재한다.
본 발명은 재난 안전망(이하 MCPTT)을 이용하는 단말에게 높은 우선순위를 부여하여 MCPTT 단말이 EPS에서 우선적으로 자원을 할당 받고, 우선적으로 데이터 전송을 할 수 있도록 연결을 수립할 수 있는 방법을 제시한다. 현재 EPS에 존재하는 Emergency Call 제어는 단말이 연결을 수립하여 Emergency Call을 시도하고자 하는 경우 인 Mobile Originated 상황만 고려하고 있으며, MCPTT 서비스에 대한 제어는 따로 이루어지지 않고 있다. 하지만 MCPTT는 재난 안전망 서비스를 위해서 일반 서비스 보다 높은 우선순위를 가질 수 있으며, 이를 EPS에 적용할 수 있어야 한다. 또한 MCPTT는 그룹 통화 혹은 일 대 일 통화를 송/수신할 수 있으므로, Mobile Originated 상황뿐 만 아닌 MCPTT 단말에게 걸려오는 MCPTT Call에 대해서 응답해야 하는 Mobile Terminated 상황도 지원할 수 있어야 한다. 본 발명은 MCPTT 단말이 MCPTT 시스템을 이용함에 있어서 높은 우선순위를 가질 수 있는 방법과 그에 따른 무선 자원을 할당 받는 방법, 그리고 MCPTT 단말이 MCPTT 시스템에 접속할 때 MCPTT 단말임을 알리는 방법을 제안한다.
본 명세서 전반에서 MCPTT는 재난 안전망 서비스 중 하나를 나타내며, 단말 간 그룹 통신 및 일 대 일 통신, 또는 긴급/응급 통신을 지원하는 다른 이름을 가진 서비스를 포함한 개념이다. 본 발명에서 MCPTT는 Public Safety 서비스라는 명칭으로 대체될 수 있다. 본 발명의 실시 예는 설명된 통신 시스템 이외에도 WLAN, 블루투스 등 무선 통신 전반에서 유사하게 사용될 수 있다. 본 발명에서 다루는 MCPTT 서비스 전반에 대한 우선순위는 MCPTT 서비스 중 일부, 예를 들어 가장 높은 우선순위를 갖는 Emergency Call 이나 그보다 차선순위를 갖는 Imminent Peril Call 등의 특정 서비스에 대한 우선순위 일 수 있다. 본 발명에서는 MCPTT 단말에게 우선 순위를 제공하기 위한 방법으로 MCPTT 단말이 EPS 네트워크로 우선순위 연결을 개시하는 Mobile Originated 시나리오, MCPTT 단말이 EPS 네트워크로부터 Paging을 받아서 우선순위 연결을 하는 Mobile Terminated 시나리오, 그리고 MCPTT 단말이 EPS 네트워크에게 MCPTT 사용 단말임을 알리며 접속하는 방법에 대해서 다룰 것이다. 또한 본 발명에서는 MCPTT 서비스를 MCPTT 기본 Call 동작을 의미하는 MCPTT Normal Call, 가장 높은 우선순위를 가지는 긴급상황 Call인 Emergency Call, 차순위 Call인 Imminent Peril Call, 주변음 청취 기능인 Ambient Listening 그리고 Emergency Alert으로 구분하여 세부 MCPTT 서비스 마다 다른 우선순위를 제공할 수 있다.
본 명세서 전반에서 EPS는 Evolved Packet System 혹은 LTE 네트워크를 의미한다. EPS는 단말과 eNB 간의 E-UTRAN과 LTE 시스템의 코어 네트워크인 EPC(Evolved Packet Core)로 구성된다. EPC는 MME, S-GW, P-GW, PCRF 등으로 구성되어 있다. 본 명세서 전반에서 EPS는 MCPTT 서비스와 연결되기 위하여 SIP Core와 연결되며 SIP Core는 SIP(Session Initiation Protocol)을 사용하는 핵심 장치들의 네트워크를 의미하며, IMS(Internet Multimedia Subsystem)를 의미할 수 있다. 따라서 본 명세서에서 지칭하는 P-CSCF 등의 IMS 장치는 MCPTT를 위한 SIP Core 장치를 의미한다. 본 명세서 전반에서 MCPTT Application Server는 MCPTT 서비스를 제공하기 위한 Application 계층의 정보를 교환하는 네트워크 장치를 의미하며, 그 의미는 Application Server라는 이름에 국한되지 않고 MCPTT 서비스를 구성하기 위하여 필요한 다양한 논리적/물리적 장치를 의미할 수 있다.
도 31은 본 발명의 제6 실시예에 따른 MCPTT 단말이 MME에 MCPTT용 Service Request를 요청하고 MME가 그에 대한 Bearer Context를 변경하여 설정하는 방법 및 절차를 나타내는 도면이다.
도 31은 본 발명에 대한 실시 예로 써, MCPTT 단말(3100)은 EPS 네트워크에 MCPTT 용 연결 수립을 위하여 Extended Service Request를 MME(3120)로 전송하여 MCPTT에 해당하는 우선순위를 가지는 Bearer를 할당 받아 무선 자원을 사용할 수 있다.
도 31은 MCPTT 단말(3100)이 MME(3120)에게 MCPTT용 Service Request를 요청하여 MCPTT에 적합한 QoS를 적용한 Bearer를 설정 받는 방법 및 절차를 나타낸 도면이다. MCPTT 단말(3100)은 일반 LTE 서비스를 이용하면서 상황에 따라 MCPTT 서비스를 이용하는 단말과 MCPTT 서비스 전용 단말로 구분할 수 있다.
본 발명에서는 편의상 Normal service와 MCPTT를 모두 이용할 수 있는 단말을 MCPTT 가능 단말이라 칭하고 MCPTT 서비스만 이용할 수 있는 단말을 MCPTT 전용 단말이라 칭하며, 두 종류 모두를 포함한 경우 MCPTT 단말이라 칭하겠다.
1. MCPTT 단말(3100)은 MCPTT 서비스를 이용하기 위하여 EPS 네트워크의 Bearer를 활성화해야 하고 Extended Service Request를 MME(3120)에 보내어 이 요청을 개시하게 된다. Extended Service Request 메시지에는 Service Type Field가 있으며, MCPTT 단말(3100)은 이 Field에 MCPTT 서비스 타입을 설정하여 전송할 수 있다. MCPTT 가능 단말은 Normal Service를 이용하다가 Public Safety 상황이 발생하여 혹은 Public Safety를 위한 통신이 요구되어 MCPTT 서비스를 요청할 수 있다. 이 때 Service Type Field에 MCPTT 서비스 타입을 설정하여 전송한다. MCPTT 전용 단말도 Service Type Field에 MCPTT 서비스를 나타내서 요청할 수 있다.
MCPTT 서비스 타입으로는 MCPTT 서비스를 전체를 지칭하는 MCPTT로 설정될 수 있으며, 또는 MCPTT Emergency로 구분하여 MCPTT 서비스 중 Emergency에 관련된 서비스를 구분할 수 있도록 값을 설정할 수 있다. 또는 세부적으로 MCPTT Group Call, 혹은 MCPTT Emergency Call, 혹은 MCPTT Imminent Peril Call, 혹은 MCPTT Emergency Alert, 혹은 Ambient Listening, 혹은 Private Call과 같이 특정 MCPTT 서비스를 지칭하는 값으로 설정될 수 있다.
MCPTT Emergency Call은 긴급 그룹 통화를 의미하는 MCPTT Emergency Group Call 혹은 긴급 일 대 일 통화를 의미하는 MCPTT Emergency Private Call로 구분될 수 있다. 또한 MCPTT 단말은 Extended Service Request의 Device Property field에 MCPTT 이용 단말임을 명시할 수 있다.
MCPTT 전용 단말은 MCPTT 전용 단말임을 알리기 위하여 Extended Service Request의 Device Property field에 명시할 수 있다. 이 경우 MME는 상기 Service Type field를 생략하고 Device Property Field만으로 해당 단말이 MCPTT 서비스를 이용하는 단말임을 알 수 있다.
Device Property에는 MCPTT 서비스에 대한 Capability를 나타낼 수 있으며, MCPTT 이용 단말임을 포괄적으로 나타내거나, 또는 MCPTT Emergency로 구분하여 MCPTT 서비스 중 Emergency에 관련된 서비스를 이용하는 단말임을 나타내도록 값을 설정할 수 있다. 혹은 보다 세부적으로 MCPTT Emergency Call, MCPTT Imminent Peril Call, MCPTT Ambient Listening, MCPTT Private call과 같이 특정 MCPTT 서비스를 이용할 수 있는 Capability를 나타낼 수 있다. Service Type 혹은 Device Property에 MCPTT Emergency 서비스에 대해서 구별할 수 있는 값이 설정된 경우, MCPTT Emergency에 대하여 제공할 수 있는 세부적인 서비스는 EPS 네트워크 사업자 혹은 MCPTT 서비스 제공자마다 다르게 설정될 수 있다.
MCPTT 단말(3100)은 MCPTT Emergency인 서비스를 이용하고자 할 경우 Extended Service Request를 사용할 수 있고, 일반적인 MCPTT 서비스는 Service Request를 사용하여 EPS 네트워크에 자원을 요청할 수 있다. 상기와 같은 Extended Service Request를 수신한 MME는 Extended Service Request에 포함된 Service Type 혹은 Device Property, 혹은 두 가지 값 모두를 보고 어떤 MCPTT 서비스를 이용할 것인지 파악할 수 있다. 또한 Normal service를 이용하는 MCPTT 가능 단말이 MCPTT 서비스를 이용하고자 하는 것인지, 혹은 MCPTT 전용 단말이 MCPTT 서비스를 이용하고자 하는 것인지 파악할 수 있으며, MME가 저장하고 있는 단말의 Context 를통하여 단말의 요청을 허가할 수 있다.
2. 또한 MME(3120)는 MCPTT 전반에 대한 서비스인지, MCPTT 서비스 중 Emergency Call에 대하여, 혹은 Imminent Peril Call에 대하여, 혹은 Ambient Listening에 대하여, 혹은 Private Call에 대하여, 혹은 Emergency Alert에 대하여 서비스를 이용할 것인지 파악할 수 있다. 혹은 MCPTT Emergency 서비스를 이용한다고 판단하여 Emergency와 관련된 서비스에 대한 특정 QoS를 적용할 수 있다.
3. MCPTT 단말(3100)이 어떤 MCPTT 서비스를 이용할 지 판단 혹은 MCPTT 서비스를 이용할 수 있는 지에 대해서 인증한 MME(3120)는 HSS(3140)에 교섭하여 특정 MCPTT 서비스를 이용하기 위하여 상기 단말에게 제공할 수 있는 QoS 정보를 획득할 수 있다. QoS 정보로는 QoS 우선순위를 식별할 수 있는 QCI 값, 자원을 우선적으로 선점할 수 있는 지의 여부를 나타내는 ARP 값을 포함할 수 있다. MME(3120)는 획득한 정보를 내부 설정 값으로 저장하거나 MME Emergency Configuration Data에 저장하여 해당 값을 가지고 나머지 과정을 진행한다.
MME(3120)와 HSS(3140) 간의 절차는 생략될 수 있으며 이 경우 MME(3120)에 저장된 내부 설정 값에 따라서 QoS 값을 결정한다. MME(3120)에 저장된 내부 설정 값은 MME Emergency Configuration Data에 저장된 값일 수 있다.
4. MME(3120)는 MCPTT 단말(3100)이 보낸 Extended Service Request에 대하여 어떤 QoS를 제공할지 결정한 후, 상기 요청을 보낸 단말의 Default Bearer에 대한 Context를 MCPTT 서비스에 맞는 QoS 값을 갖도록 수정한다.
예를 들어, MME(3120)가 Extended Service Request를 보낸 MCPTT 단말(3100)에게 MCPTT Emergency 서비스를 제공 해야 한다고 판단했다면 그에 해당하는 QCI 또는 ARP 값으로 기존의 Default Bearer Context를 변경한다. MME(3120)는 상기 과정에서 설정된 Bearer가 Public Safety용 Bearer라는 것을 내부 설정하여 저장한다.
5. MME(3120)는 MCPTT 단말(3100)에 대한 Default Bearer Context를 MCPTT 서비스에 맞게 혹은 Emergency 서비스에 맞게 혹은 세부적인 MCPTT 서비스에 맞게 변경 한 후, eNB(3110)로 Initial Context Setup Request를 보내어 상기 변경한 Bearer Context 대로 단말과 Bearer 연결을 수립할 것을 요청한다.
6. MME(3120)로부터 Initial Context Setup Request를 수신한 eNB(3110)는 Initial Context Setup Request에 담긴 Bearer Context 즉 QoS 정보에 따라 Bearer 생성을 준비하며 MCPTT 단말(3100)에게 RRC Connection Reconfiguration을 보내어 단말(3100)과 eNB(3110) 간 Bearer 연결을 수립한다.
7. 단말(3100)과 Bearer 연결 수립을 완료한 eNB(3110)는 MME(3120)에게 Initial Context Setup Request에 대한 응답으로 Initial Context Setup Response를 보내어 어떤 Bearer ID로 MME(3120)가 설정한 QoS를 가진 Bearer가 설정되었음을 알린다. 상기 과정에서 eNB(3110)는 단말(3100)에게 할당된 Public Safety용 Bearer임을 저장할 수 있으며, 이 정보를 활용하여 다른 Normal Service용 Bearer보다 Public Safety용 Bearer에게 우선순위를 부여하여 무선자원 할당 및 Data transfer를 할 수 있다.
8. MME(3120)는 상기 Initial Context Setup Response를 수신한 후 eNB(3110)와 S-GW/P-GW(3130)의 연결을 위해서 Modify Bearer Request를 S-GW/P-GW(3130)에 전송하고, 이 결과로 eNB(3110)와 S-GW/P-GW(3130) 사이에 Bearer 연결이 수립된다. 단말(3100)부터 eNB(3110), 그리고 S-GW/P-GW(3130)까지 수립된 Bearer 연결은 상기 절차에서 MME(3120)가 MCPTT Type에 맞추어 설정한 QoS 값을 가진 연결이다. 기지국(3110) 혹은 MME(3120) 혹은 S-GW 혹은 P-GW(3130)는 해당 Bearer가 Public Safety용 Bearer임을 내부적으로 binding할 수 있다.
기존 Default bearer 보다 높은 QoS에 대한 QCI, ARP값을 가지고 있거나 혹은 해당 Bearer가 Public Safety용 Bearer임을 binding하여 알고 있을 수 있기 때문에, 기지국(3110) 및 S-GW/P-GW(3130)는 다른 Bearer 보다 높은 우선순위로 데이터 전달을 처리할 수 있다. Bearer 연결 수립이 완료된 P-GW(3130)는 PCRF에 새로 수립한 Bearer및 단말 정보를 전달하여 PCC rule을 업데이트하여 Charging 혹은 서비스 제공에 활용할 수 있다.
상기 Extended Service Request 메시지를 전달하기 위해 단말(3100)은 기지국(3110)과 RRC 연결을 맺게 된다. 단말(3100)은 기지국(3110)과 RRC 연결을 맺을 때, 단말(3100)의 NAS layer는 RRC Establishment Cause라는 값을 설정하여 단말(3100)의 RRC layer로 알려준다. RRC Establishment Cause는 보통 Mobile Originated Signaling인지, Mobile Originated Data인지, Mobile Terminated Signaling인지, Mobile Terminated Data 인지 등을 나타낸다.
그 후 단말(3100)의 RRC layer는 RRC 메시지를 구성하여 기지국(3110)으로 연결 요청을 보낸다.
본 발명에서는 RRC Establishment Cause에 Public Safety 임을 나타내는 식별자를 제안한다. 이는 Mobile Originated Public safety signaling, Mobile Originated Public safety data, Mobile Terminated Pubic safety signaling, Mobile Terminated public safety data 등으로 세분화된 식별자일 수 있으며, 혹은 Public Safety 전반을 나타내는 식별자 일 수 있다. 어떤 식별자가 어떤 이름을 갖건, Public safety 서비스(MCPTT 포함)를 나타내는 RRC 연결 요청에 대한 cause값을 포함한다.
단말(3100)은 상기와 같은 RRC establishment cause를 설정한 경우 단말(3100)과 기지국(3110) 간 혼잡 제어를 회피할 수 있으며(Overriding Congestion control) 혹은 단말(3100)과 기지국(3110) 간의 Access Class barring, Application level Congestion control for data communication(ACDC)를 회피할 수 있다.
또한 기지국(3110)은 상기와 같은 cause로 요청한 단말(3100)에 대하여 Public Safety 단말임을 저장, 후에 단말(3100)이 Handover가 필요한 경우 타 단말보다 우선하여 처리할 수 있다.
도 32는 본 발명의 제6실시예에 따른 MCPTT 단말이 MME에 MCPTT용 Service Request를 요청하고 MME가 그에 대한 Second Bearer context를 활성화하는 방법 및 절차를 나타내는 도면이다.
도 32는 본 발명에 대한 실시 예로써, MCPTT 단말(3200)은 EPS 네트워크에 MCPTT 용 연결 수립을 위하여 Extended Service Request를 MME(3220)로 전송하여 MCPTT에 해당하는 우선순위를 가지는 Bearer를 할당 받아 무선 자원을 사용할 수 있다.
도 32에서 Emergency라는 명칭을 사용했으나 MCPTT 서비스 전반을 나타내거나 MCPTT Emergency를 나타내거나 세부적인 MCPTT 서비스를 나타낼 수 있음은 자명하다. 또한 Public safety 서비스를 나타낼 수 있음은 자명하다.
MCPTT 단말(3200)은 MCPTT 서비스를 이용하기 위하여 EPS 네트워크의 Bearer를 활성화해야 하고 Extended Service Request를 MME(3220)에 보내어 이 요청을 개시하게 된다. Extended Service Request 메시지에는 Service Type Field가 있으며, MCPTT 단말(3200)은 이 Field에 MCPTT 서비스 타입을 설정하여 전송할 수 있다. MCPTT 가능 단말은 Normal Service를 이용하다가 Public Safety 상황이 발생하여 혹은 Public Safety를 위한 통신이 요구되어 MCPTT 서비스를 요청할 수 있다.
이 때 Service Type Field에 MCPTT 서비스 타입을 설정하여 전송한다. MCPTT 전용 단말도 Service Type Field에 MCPTT 서비스를 나타내서 요청할 수 있다. MCPTT 서비스 타입으로는 MCPTT 서비스를 전체를 지칭하는 MCPTT로 설정될 수 있으며, 또는 MCPTT Emergency로 구분하여 MCPTT 서비스 중 Emergency에 관련된 서비스를 구분할 수 있도록 값을 설정할 수 있다. 또한 세부적으로 MCPTT Group Call, 혹은 MCPTT Emergency Call, 혹은 혹은 MCPTT Imminent Peril Call, 혹은 MCPTT Emergency Alert, 혹은 Ambient Listening, 혹은 Private Call과 같이 특정 MCPTT 서비스를 지칭하는 값으로 설정될 수 있다. MCPTT Emergency Call은 긴급 그룹 통화를 의미하는 MCPTT Emergency Group Call 혹은 긴급 일 대 일 통화를 의미하는 MCPTT Emergency Private Call로 구분될 수 있다. 또한 MCPTT 단말은 Extended Service Request의 Device Property field에 MCPTT 이용 단말임을 명시할 수 있다. MCPTT 전용 단말은 MCPTT 전용 단말임을 알리기 위하여 Extended Service Request의 Device Property field에 명시할 수 있다. 이 경우 MME는 상기 Service Type field를 생략하고 Device Property Field만으로 해당 단말이 MCPTT 서비스를 이용하는 단말임을 알 수 있다.
Device Property에는 MCPTT 서비스에 대한 Capability를 나타낼 수 있으며, MCPTT 이용 단말임을 포괄적으로 나타내거나, 또는 MCPTT Emergency로 구분하여 MCPTT 서비스 중 Emergency에 관련된 서비스를 이용하는 단말임을 나타내도록 값을 설정할 수 있다.
혹은 보다 세부적으로 MCPTT Emergency Call, MCPTT Imminent Peril Call, MCPTT Ambient Listening, MCPTT Private call과 같이 특정 MCPTT 서비스를 이용할 수 있는 Capability를 나타낼 수 있다. Service Type 혹은 Device Property에 MCPTT Emergency 서비스에 대해서 구별할 수 있는 값이 설정된 경우, MCPTT Emergency에 대하여 제공할 수 있는 세부적인 서비스는 EPS 네트워크 사업자 혹은 MCPTT 서비스 제공자마다 다르게 설정될 수 있다.
MCPTT 단말(3200)은 MCPTT Emergency인 서비스를 이용하고자 할 경우 Extended Service Request를 사용할 수 있고, 일반적인 MCPTT 서비스는 Service Request를 사용하여 EPS 네트워크에 자원을 요청할 수 있다. 상기와 같은 Extended Service Request를 수신한 MME(3220)는 Extended Service Request에 포함된 Service Type 혹은 Device Property, 혹은 두 가지 값 모두를 보고 어떤 MCPTT 서비스를 이용할 것인지 파악할 수 있다. 또한 Normal service를 이용하는 MCPTT 가능 단말이 MCPTT 서비스를 이용하고자 하는 것인지, 혹은 MCPTT 전용 단말이 MCPTT 서비스를 이용하고자 하는 것인지 파악할 수 있으며, MME가 저장하고 있는 단말의 Context 를통하여 단말의 요청을 허가할 수 있다.
또한 MME(3220)는 MCPTT 전반에 대한 서비스 인지, MCPTT 서비스 중 Emergency Call에 대하여, 혹은 Imminent Peril Call에 대하여, 혹은 Ambient Listening에 대하여, 혹은 Private Call에 대하여, 혹은 Emergency Alert에 대하여 서비스를 이용할 것인지 파악할 수 있다. 혹은 MCPTT Emergency 서비스를 이용한다고 판단하여 Emergency와 관련된 서비스에 대해서 특정 QoS를 적용할 수 있다.
본 실시 예에 있어서 도 31과 구별되는 점은 MME(3220)가 단말(3200)이 MCPTT 서비스를 사용할 수 있는 단말인지의 여부를 미리 알고 MCPTT 서비스를 요청할 경우 MCPTT용 QoS에 맞는 Bearer를 할당하기 위하여 MCPTT 용 Secondary Default Bearer Context를 저장하고 있다는 것이다.
단말(3200)이 MCPTT 서비스를 사용할 수 있는 단말인지의 여부는 본 발명의 다른 실시 예에서 다룰 것이다. MCPTT Capability가 있는 단말(3200)이 Attach를 수행했다면, MME(3220)는 단말(3200)이 MCPTT 서비스를 이용할 수 있고 Normal Service도 이용할 수 있는 MCPTT 가능 단말이거나, MCPTT 서비스만 이용이 가능한 MCPTT 전용 단말임을 MCPTT Capability에 담긴 값을 보고 알 수 있다.
상기와 같이 MCPTT 가능 단말 혹은 MCPTT 전용 단말의 Attach procedure를 수행한 MME(3220)는 MCPTT 서비스를 요청할 것에 대비하여 MCPTT 용 QoS 값을 갖는 Secondary default bearer context를 설정하고 있는다.
Secondary default bearer context는 MCPTT 전반에 대한 context이거나, MCPTT Emergency 서비스에 대한 context이거나, 세부적으로 Emergency Call, Imminent Peril Call, Ambient Listening, Private Call, Emergency Alert에 대한 Context를 별도로 가지고 있을 수 있다.
Secondary Default Bearer context가 될 수 있는 후보 Context를 여러 개 가질 수 있으나, MCPTT용 Service Request가 왔을 때 기존의 Default Bearer Context와는 다른 Default Bearer context를 설정하는 것이기 때문에 Secondary Default Bearer Context라고 부를 수 있으며, Secondary라는 것이 MME에 저장된 Context 중 특정 순번을 의미하지는 않음은 자명하다. Secondary Default Bearer Context는 그에 해당하는 QCI 또는 ARP 값으로 구성되어 있다.
MCPTT 단말(3200)로부터 전달된 Extended Service Request를 수신한 MME(3220)는 MCPTT Type을 확인하고, 단말(3200)이 그 서비스를 이용할 수 있는지의 여부를 확인할 수 있다. 그 후 MME(3220) 내 저장된 Bearer Context 중 단말(3200)이 요청한 MCPTT Type에 맞는 Bearer Context를 Secondary Default bearer context로 선정하여 그 context에 포함된 QoS에 맞게 Bearer 연결 수립을 시작한다.
MME(3220)는 Secondary default bearer context에 있는 Bearer context를 이용하여 eNB에 Initial Context Setup Request를 전송한다. MME(3220)로부터 Initial Context Setup Request를 수신한 eNB(3210)는 Initial Context Setup Request에 담긴 Bearer Context 즉 QoS 정보에 따라 Bearer 생성을 준비하며 MCPTT 단말(3200)에게 RRC Connection Reconfiguration을 보내어 단말과 eNB 간 Bearer 연결을 수립한다.
단말(3200)과 Bearer 연결 수립을 완료한 eNB(3210)는 MME(3220)에게 Initial Context Setup Request에 대한 응답으로 Initial Context Setup Response를 보내어 어떤 Bearer ID로 MME(3220)가 설정한 QoS를 가진 Bearer가 설정되었음을 알린다.
MME(3220)는 상기 Initial Context Setup Response를 수신한 후 eNB(3210)와 S-GW/P-GW(3230)의 연결을 위해서 Modify Bearer Request를 S-GW/P-GW(3230)에 전송하고, 이 결과로 eNB(3210)와 S-GW/P-GW(3230) 사이에 Bearer 연결이 수립된다.
단말(3200)부터 eNB(3210), 그리고 S-GW/P-GW(3230)까지 수립된 Bearer 연결은 상기 절차에서 MME가 MCPTT Type에 맞추어 설정한 QoS 값을 가진 연결이며, 다른 Bearer 보다 높은 우선순위로 데이터 전달을 처리할 수 있다.
기지국(3210) 혹은 MME(3220) 혹은 S-GW 혹은 P-GW(3230)는 해당 Bearer가 Public Safety용 Bearer임을 내부적으로 binding할 수 있다. 기존 Default bearer 보다 높은 QoS에 대한 QCI, ARP값을 가지고 있거나 혹은 해당 Bearer가 Public Safety용 Bearer임을 binding하여 알고 있을 수 있기 때문에, 기지국(3210) 및 S-GW/P-GW(3230)는 다른 Bearer 보다 높은 우선순위로 데이터 전달을 처리할 수 있다. Bearer 연결 수립이 완료된 P-GW(3230)는 PCRF에 새로 수립한 Bearer및 단말 정보를 전달하여 PCC rule을 업데이트하여 Charging 혹은 서비스 제공에 활용할 수 있다.
도 33은 본 발명의 제6 실시예에 따른 MCPTT 단말이 MCPTT 서비스를 수행하기 위한 paging을 수신하기 위하여 EPS 장치에서 우선순위로 처리되는 절차 및 단말이 MCPTT 서비스에 대한 Bearer 연결을 수립하는 절차를 나타내는 도면이다.
도 33은 본 발명에 따른 실시 예로 써, MCPTT 단말(3330)이 MCPTT 서비스로부터 높은 우선순위를 가지는 데이터가 도착했을 경우 우선순위를 적용하여 paging을 받는 절차 및 paging에 따른 결과로 우선순위를 가지는 Bearer 연결을 수립하는 절차를 나타낸 도면이다.
도 33에서 Emergency라는 명칭을 사용했으나 Public Safety 서비스를 나타내거나MCPTT 서비스 전반을 나타내거나 MCPTT Emergency를 나타내거나 세부적인 MCPTT 서비스를 나타낼 수 있음은 자명하다. MCPTT 서비스를 사용하고 있는 단말은 IDLE Mode 동작 중에 있다. 이 때 MCPTT 서비스로부터 MCPTT 서비스 이용에 대한 데이터가 MCPTT Application Server로부터 P-CSCF로 전달된다. P-CSCF는 MCPTT Application Server로부터 도착한 시그널링이 우선순위를 가지고 처리되어야 하는지 판단할 수 있다. MCPTT 서비스에 대해서 전반적으로 높은 우선순위를 부여할 수 있으며, 또는 MCPTT Emergency 서비스에 대해서 높은 우선순위를 부여하거나, 혹은 세부적인 MCPTT 서비스인 Emergency Call, Imminent Peril Call, Ambient Listening, Private Call, Emergency Alert 등의 서비스를 구분하여 그에 맞는 우선순위를 부여할 수 있다.
P-CSCF(3360)는 MCPTT Application Service로부터 도착한 Signaling이 우선순위를 갖는다는 Indication을 포함하여 P-GW(3330)로 전달하게 된다.
또는 다른 방법으로써, P-CSCF(3360)가 PCRF(3350)에 MCPTT Application Server(3370)의 IP주소로부터 온 데이터에 대해서 높은 우선순위를 부여할 것을 요청할 수 있고, PCRF(3350)는 이를 반영하여 P-GW(3330)에 MCPTT Application Server(3370)의 IP로부터 도착한 데이터에 대해서 높은 우선순위를 반영해 줄 것을 PCC Rule로 알려주거나 정책을 업데이트해서 알려줄 수 있다.
상기 절차를 통하여 P-GW(3330)는 우선순위가 높은 시그널링이 도착했다는 것을 알게 될 수 있다. 상기 절차를 따르지 않은 경우, P-GW(3330)는 MCPTT 단말(3300)이 Attach 했을 때 MCPTT 전용 단말임을 저장하고 있을 수 있고, 해당 단말로 전송할 Downlink Data가 있을 경우 높은 우선순위로 Paging을 수행할 수 있다.
P-GW(3330)는 단말에게 Paging을 하기 위하여 MME(3320)로 Downlink Notification 메시지를 전달하게 된다. P-GW(3330)는 Downlink Notification 메시지에 이 Downlink Notification이 MCPTT 용, 혹은 MCPTT Emergency 용, 혹은 세부적인 MCPTT 서비스에 기인한 것이라는 식별자를 추가할 수 있다.
식별자를 Downlink Notification 메시지에 포함하는 방법으로 Downlink Notification 메시지의 Indication flag에 MCPTT 서비스 혹은 MCPTT Emergency 혹은 MCPTT 세부 서비스에 대한 식별자를 추가하여 설정하거나, Downlink Notification 메시지의 ARP setting 값에 Emergency에 대응되거나 MCPTT 서비스에 대응되는 값을 설정하거나, Downlink Notification 메시지의 Paging and Service Information에 MCPTT에 대한 정보를 설정하거나 MCPTT Emergency에 대한 정보를 설정하거나 세부적인 MCPTT 서비스에 대한 정보를 설정할 수 있다.
상기와 같은 Downlink Notification 메시지를 수신한 MME(3320)는 Downlink로 전달된 Data type이 MCPTT 용 혹은 MCPTT Emergency 용 혹은 세부적인 MCPTT 서비스 용임을 판단할 수 있다.
또는 상기 절차를 따르지 않은 경우, MME(3320)는 MCPTT 단말(3300)이 Attach 했을 때 MCPTT 전용 단말임을 저장하고 있을 수 있고, 해당 단말(3300)에 대한 Paging을 우선순위를 높게 둘 수 있다.
그 후 MME(3320)는 eNB(3310)로 Paging 메시지를 보내게 되고, 이 메시지에 이 paging이 MCPTT용 혹은 MCPTT Emergency 용 혹은 세부적인 MCPTT 서비스 용으로써 높은 우선순위로 처리되어야 한다는 Indication을 포함한다.
이를 위해 MME(3320)는 Paging 메시지의 Paging Priority 를 MCPTT 서비스에 맞게 혹은 MCPTT Emergency 에 맞게 혹은 세부적인 MCPTT 서비스에 맞게 설정할 수 있다. 상기 Paging 메시지를 수신한 eNB(3310)는 우선적으로 처리되어야 하는 Paging 임을 판단할 수 있고, 다른 Paging 요청보다 먼저 처리할 수 있다.
MCPTT 단말(3300)은 Paging을 듣고 eNB(3310)에 응답을 하게되고, MCPTT 단말(3300)의 응답을 수신한 eNB(3310)는 Initial UE Message를 기지국(3310)에 전송하여 MCPTT 단말(3300)에 대해 Bearer 연결 수립을 해줄 것을 요청한다.
MME(3320)는 Initial UE message를 수신하고, 상기 우선순위를 가지는 Paging을 수신한 단말이 Bearer 연결을 요청하는 것임을 판단할 수 있다. MME(3320)는 상기 MCPTT 단말에게 할당할 Bearer의 context를 결정하고, 이 때 MCPTT 서비스 혹은 MCPTT Emergency 혹은 세부적인 MCPTT 서비스에 따른 QoS 값을 설정한다.
MCPTT 단말(3300)이 어떤 MCPTT 서비스를 이용할 지 판단, 인증한 MME(3320)는 HSS에 교섭하여 특정 MCPTT 서비스를 이용하기 위하여 상기 단말에게 제공할 수 있는 QoS 정보를 획득할 수 있다.
QoS 정보로는 QoS 우선순위를 식별할 수 있는 QCI 값, 자원을 우선적으로 선점할 수 있는 지의 여부를 나타내는 ARP 값을 포함할 수 있다. MME(3320)는 획득한 정보를 내부 설정 값으로 저장하거나 MME Emergency Configuration Data에 저장하여 해당 값을 가지고 나머지 과정을 진행한다. MME(3320)와 HSS (3340)간의 절차는 생략될 수 있으며 이 경우 MME(3320)에 저장된 내부 설정 값에 따라서 QoS 값을 결정한다.
MME(3320)에 저장된 내부 설정 값은 MME Emergency Configuration Data에 저장된 값일 수 있다. MME(3320)는 MCPTT 단말(3300)에게 할당할 Bearer에 대해 어떤 QoS를 제공할지 결정한 후, 상기 요청을 보낸 단말(3300)의 Default Bearer에 대한 Context를 MCPTT 서비스에 맞는 QoS 값을 갖도록 수정한다.
예를 들어, MME(3320)가 Extended Service Request를 보낸 MCPTT 단말(3300)에게 MCPTT Emergency 서비스를 제공 해야 한다고 판단했다면 그에 해당하는 QCI 또는 ARP 값으로 기존의 Default Bearer Context를 변경한다.
혹은 본 발명의 다른 실시 예와 같이 MCPTT용으로 저장해둔 Secondary Default bearer Context를 활성화한다. 그 후 MME(3320)는 eNB(3310)로 Initial Context Setup Request를 보내어 상기 설정한 Bearer Context 대로 단말(3300)과 Bearer 연결을 수립할 것을 요청한다.
MME(3320)로부터 Initial Context Setup Request를 수신한 eNB(3310)는 Initial Context Setup Request에 담긴 Bearer Context 즉 QoS 정보에 따라 Bearer 생성을 준비하며 MCPTT 단말(3300)에게 RRC Connection Reconfiguration을 보내어 단말(3300)과 eNB(3310) 간 Bearer 연결을 수립한다.
단말(3300)과 Bearer 연결 수립을 완료한 eNB(3310)는 MME(3320)에게 Initial Context Setup Request에 대한 응답으로 Initial Context Setup Response를 보내어 어떤 Bearer ID로 MME(3320)가 설정한 QoS를 가진 Bearer가 설정되었음을 알린다. MME(3320)는 상기 Initial Context Setup Response를 수신한 후 eNB(3310)와 S-GW/P-GW(3330)의 연결을 위해서 Modify Bearer Request를 S-GW/P-GW(3330)에 전송하고, 이 결과로 eNB(3310)와 S-GW/P-GW(3330) 사이에 Bearer 연결이 수립된다.
단말(3300)부터 eNB(3310), 그리고 S-GW/P-GW(3330)까지 수립된 Bearer 연결은 상기 절차에서 MME(3320)가 MCPTT Type에 맞추어 설정한 QoS 값을 가진 연결이며, 다른 Bearer 보다 높은 우선순위로 데이터 전달을 처리할 수 있다. Bearer 연결 수립이 완료된 P-GW(3330)는 PCRF(335)에 새로 수립한 Bearer및 단말 정보를 전달하여 PCC rule을 업데이트하여 Charging 혹은 서비스 제공에 활용할 수 있다. Bearer 연결 수립이 완료 된 후 MCPTT 단말(3300)은 MCPTT 서비스로부터 온 요청에 응답하여 높은 우선순위를 가지고 MCPTT 서비스를 이용할 수 있다.
도 34는 본 발명의 제6 실시예에 따른 MCPTT 단말이 MCPTT 서비스를 수행하기 위한 paging을 수신하기 위하여 EPS 장치에서 우선순위로 처리되는 절차 및 단말이 MCPTT 서비스에 대한 우선순위 Bearer 연결을 수립하는 절차를 나타낸다.
도 34는 본 발명에 따른 실시 예로서, P-GW(3430)가 P-CSCF(3460)로부터 MCPTT 시그널링을 받는 것은 도 33에 따른 실시 예와 같다. 도 34에서 Emergency라는 명칭을 사용했으나Public Safety 서비스를 나타내거나 MCPTT 서비스 전반을 나타내거나 MCPTT Emergency를 나타내거나 세부적인 MCPTT 서비스를 나타낼 수 있음은 자명하다.
본 실시 예에서는 P-GW(3430)가 우선순위를 가지는 시그널링을 인식한 후, 우선순위를 갖는 Bearer 연결 수립을 요청하는 절차를 제안한다. 우선순위를 갖는 Bearer 연결은 MCPTT 서비스에 대하여 높은 QoS를 갖는 Bearer 연결을 의미하거나, MCPTT Emergency 서비스에 대하여 높은 QoS를 갖는 Bearer 연결을 의미하거나, 세부적인 MCPTT 서비스에 따라 높은 QoS를 갖는 Bearer 연결을 의미할 수 있다.
P-CSCF(3460)로부터 높은 우선순위를 갖는 시그널링을 수신한 P-GW(3430)는 MME(3420)에 Paging 메시지를 보내고 나서 높은 우선순위에 적합한 우선순위를 갖는Bearer 연결을 수립하기 위하여 어떤 QoS를 새 Bearer에 적용해야 할지 결정한다.
또는 상기 절차를 따르지 않은 경우, P-GW(3430)는 MCPTT 단말(3400)이 Attach 했을 때 MCPTT 전용 단말임을 저장하고 있을 수 있고, 해당 단말(3400)로 전송할 Downlink Data가 있을 경우 높은 우선순위의 QoS 값을 새 Bearer에 적용하기로 결정할 수 있다.
QoS를 결정한 P-GW(3430)는 S-GW(3430)를 거쳐 MME(3420)에 Update Bearer Request를 전송하고, 이 메시지에 상기 절차에서 결정한 높은 우선순위를 갖는 QoS 값을 설정하여 전송한다. 상기 메시지를 수신한 MME(3420)는 상기 메시지에 담긴 정보를 기반으로MCPTT 단말(3400)에게 할당할 Bearer Context를 결정한다.
또는 상기 절차를 따르지 않은 경우, MME(3420)는 MCPTT 단말(3400)이 Attach 했을 때 MCPTT 전용 단말임을 저장하고 있을 수 있고, 해당 단말(3400)에 대한 Paging을 우선순위를 높게 둘 수 있다. MME(3420)는 높은 우선순위를 가지는 Bearer 연결을 수립하기 위하여 기존에 존재하는 Default Bearer의 Context를 수정할 수 있으며, 이 경우 본 발명의 실시 예 1을 따를 수 있다.
다른 방법으로 기 저장해 놓았던 Secondary Default Bearer Context를 Activate하여 Bearer 연결 수립을 수행할 수 있으며, 이 경우 본 발명의 실시 예 2를 따른다.
또 다른 방법으로 MME(3420)는 높은 우선순위에 적합한 Dedicated Bearer 연결 수립을 수행할 수 있다. 이 경우 Default Bearer 연결과 Dedicated Bearer 연결이 모두 수립되며, MCPTT 단말(3400)은 Dedicated Bearer를 통하여 MCPTT 서비스를 이용하게 된다.
또 다른 방법으로 MME(3420)가 새로운 Bearer 연결을 수립할 수 있으며, 이 경우 기존의 Bearer context는 모두 deactivate 되고 MME(3420)가 새로 결정한 Bearer Context에 따른 새 Bearer가 생기게 된다. MME(3420)가 MCPTT 단말(3400)과 Bearer 생성을 위하여 교섭하는 절차는 본 발명의 다른 실시 예를 따른다.
도 35는 본 발명의 제6 실시예에 따른 MCPTT 단말이 EPS 네트워크에 Attach 할 때, MCPTT 단말임을 알리는 방법 및 MCPTT 서비스를 이용하기 위함을 알려서 Bearer 연결을 수립하는 방법 및 절차를 나타내는 도면이다.
도 35는 본 발명에 따른 실시 예로서, MCPTT 단말(3500)이 EPS 네트워크에 Attach를 할 때 MCPTT를 사용할 수 있는 단말임을 알리는 방법 및 Attach를 통하여 MCPTT 서비스를 사용하기 위함을 MME(3520)에게 알리는 방법, 그리고 그에 따른 Bearer 연결 수립 방법 및 절차를 나타낸 도면이다.
도 35에서 Emergency라는 명칭을 사용했으나 Public Safety 서비스를 나타내거나 MCPTT 서비스 전반을 나타내거나 MCPTT Emergency를 나타내거나 세부적인 MCPTT 서비스를 나타낼 수 있음은 자명하다. MCPTT 단말(3500)은 EPS 네트워크에 접속하기 위하여 Attach Procedure를 수행한다. MPCTT 단말(3500)은 Attach Request 메시지에 다음과 같은 방법으로 MCPTT를 사용하는 단말임을 MME(3520)에게 알릴 수 있다.
MCPTT 단말(3500)은 Attach Request 메시지의 Type Field에 MCPTT임을 나타내거나, MCPTT Emergency임을 나타낼 수 있다. 또한 MCPTT 단말(3500)은 Attach Request 메시지의 APN field에 MCPTT APN을 설정하여 자신이 MCPTT 서비스에 접속할 것임을 알릴 수 있다.
또한 MCPTT 단말(3500)은 Attach Request의 UE network capability에 MCPTT Capability에 해당하는 값을 설정할 수 있으며, Device Property에 MCPTT 단말임을 나타낼 수 있다.
MCPTT 단말(3500)은 상기 방법 중 적어도 하나 이상을 수행하여 MCPTT 단말임을 알릴 수 있으며, Attach Request의 Type 및 APN field를 이용하여 Attach의 결과 MCPTT 용 Bearer 연결이 수립되어야 한다는 것을 나타낼 수 있다. MCPTT 서비스와 Normal Service를 모두 이용할 수 있는 단말은 UE network Capability에 Public Safety Capability를 나타냄으로써 핵심망에게 자신이 MCPTT 서비스를 이용할 수 있는 단말임을 알릴 수 있다. (도31에서의 MCPTT 가능 단말과 동일) UE network Capability 또는 Device Property를 설정하는 동작은 해당 단말이 MCPTT를 사용할 수 있는 단말이라는 의미를 나타낼 수 있다.으며, MCPTT 전용 단말의 경우, MCPTT 서비스만 이용할 수 있기 때문에 Device Property에 MCPTT 전용 단말임을 나타낼 수 있다.
이와 같이 설정된 Attach request를 수신한 MME는 본 발명의 도 32에서 다룬 방식대로 해당 단말에 대하여 MCPPT 서비스를 위한 Secondary Bearer Context를 미리 구성할 수 있다. MCPTT 단말(3500)은 상기와 같이 구성한 Attach Request 메시지를 RRC Connection 절차 수행 중 RRC Connection Setup Complete 메시지에 포함하여 eNB(3510)로 전달하게 되고, 이 때 RRC 메시지에 MCPTT 서비스 연결을 위하여 우선순위로 처리되어야 한다는 Indication을 포함할 수 있다. (RRC Establishment Cause) 상기 Indication과 함께 Attach Request 메시지가 담긴 RRC Connection Setup Complete 메시지를 MCPTT 단말로부터 수신한 eNB(3510)는 상기 Indication을 따라 다른 단말들의 요청보다 먼저 상기 단말의 요청을 처리할 수 있으며, Initial UE message에 Attach Request 메시지를 포함하고, 높은 우선순위로 처리되어야 한다는 Indication을 포함하여 MME(3520)에게 전달한다.
상기 Initial UE message를 수신한 MME(3520)는 상기 메시지에 담긴 우선순위 처리가 필요하다는 Indication을 따라 다른 eNB에서 도착한 요청보다 먼저 상기 요청을 처리할 수 있다. 이에 따라 상기 Initial UE Message에 담긴 Attach Request 메시지를 수신한 MME(3520)는 MCPTT 단말(3500)이 Attach Request 메시지를 구성할 때 설정한 값에 따라 단말(3500)에게 필요한 Bearer의 Context를 결정할 수 있다.
예를 들어 Attach Request 메시지의 type이 Emergency이고 APN이 MCPTT APN을 나타내면, MME(3520)는 Attach를 요청한 단말이 MCPTT용 Emergency Bearer가 필요하다고 판단할 수 있다. 마찬가지로 Attach 메시지의 Type이 MCPTT Emergency를 나타내면, 그 단말에게 MCPTT Emergency에 대한 Bearer context를 결정할 수 있다. 또한 Attach 메시지의 Type 이 설정되어 있지 않더라도 UE network Capability에 단말의 MCPTT 사용 가능 여부가 표시되어 있거나, Device Property에 MCPTT 단말임이 설정되어 있다면 그 단말이 MCPTT 서비스를 사용할 경우에 대비하여 MCPTT 서비스 우선순위에 적합한 Bearer Context를 결정하여 Secondary Default Bearer Context로 저장할 수 있다.
상기에서 서술한 절차와 같은 과정으로 Bearer context를 결정한 MME(3520)는 HSS(3540)에 QoS 정보를 요청하여 획득할 수 있으며, Attach를 요청한 단말(3500)이 높은 QoS를 가질 수 있는 지 인증 절차를 수행할 수도 있다. 상기 과정은 생략될 수 있으며, 생략되었을 경우 MME(3520) 내부에 MME Emergency Configuration data 또는 다른 방법으로 저장된 값을 사용할 수 있다.
MME(3520)는 Attach를 요청한 단말(3500)에게 Bearer 연결을 제공해주기 위하여 S-GW/P-GW(3530)로 Create Session Request를 전송하고, 이 경우 S-GW/P-GW(3530)에서 해당 요청을 빨리 처리할 수 있도록 Create Session Request 메시지의 Indication Flag 혹은 Signaling Priority Indication 혹은 Bearer Context의 QoS 값에 높은 우선순위를 가지는 값을 포함하여 전송할 수 있다.
상기 메시지를 수신한 S-GW/P-GW(3530)는 Indication flag 혹은 Signaling Priority Indication을 확인하여 다른 단말 또는 MME(3520)로부터의 요청보다 더 우선적으로 메시지를 처리할 수 있으며, 또는 Bearer 정보에 담긴 QoS 값을 확인하여 Emergency에 준하는 높은 우선순위의 QCI 또는 ARP 값을 갖는다면 상기 요청을 우선적으로 처리해야 한다고 판단할 수 있다.
P-GW(3530)는 Create Session Request를 수락하고 PCRF(3550)와 교섭하여 PCC rule을 업데이트할 수 있다. 그 후 P-GW(3530)는 Create Session Response로 상기 Create Session Request에 대한 응답을 할 수 있으며, Create Session Response 메시지에는 MCPTT 단말(3500)이 MCPTT 서비스를 이용하고자 할 때 Activate 할 수 있는 Secondary Default Bearer 정보가 포함되거나, 현재 MCPTT 단말(3500)이 Activate해야할 Default Bearer 정보를 포함하여 전송한다.
이를 수신한 MME(3520)는 Initial Context Setup Request에 Attach Accept 메시지와 Bearer Context 정보를 포함하여 전달하게 되고, 이를 수신한 eNB(3510)는 RRC Connection Reconfiguration 메시지로 Attach Accept를 전달하고, Initial Context Setup Request에 있는 Bearer Context 대로 단말과 eNB(3510) 간 Bearer 연결을 수립하게 된다.
단말(3500)과 eNB(3510) 간 Bearer 연결이 수립되면 eNB(3510)는 Initial context Setup response를 MME(3520)에게 보내서 Bearer가 설정되었음을 알리고, MME(3520)는 S-GW/P-GW(3530)에게 Modify Bearer Request를 보내어 eNB(3510)와 S-GW/P-GW(3530) 간 Bearer 연결을 수립한다. 단말(3500)은 Attach Accept 메시지를 MME(3520)에게 전송하여 Attach 절차를 종료한다.
(상기 서술에서 P-GW(3530),?S-GW(3530), MME(3520), eNB(3510)로 이어지는 Public safety 용 우선순위를 알리는 동작은 연속된 동작을 의미할 수 있으며, 반드시 P-GW(3530)로부터 이어지는 동작은 아닐 수 있다. 예를 들어 P-GW(3530)에서 S-GW, MME(3520)까지 이어지는 public safety 식별자가 아니더라도 MME(3520)는 단말이 Public safety 단말임을 알고 eNB(3510)에게 관련 정보를 전달할 수 있다. )
본 발명에 대한 세부 실시 예로 기지국 혹은 MME(3520) 혹은 S-GW 혹은 P-GW(3530)는 해당 단말 혹은 Bearer가 Public Safety용임을 내부적으로 binding할 수 있다.
도 35에 의한 발명의 결과에 따라 기지국(3510), MME(3520), 또는 S-GW/P-GW(3530)는 해당 단말이 Public Safety용 연결이 필요함을, 혹은 해당 단말의 Bearer가 기존 Default bearer 보다 높은 QoS에 대한 QCI, ARP값을 가지고 있거나 혹은 해당 Bearer가 Public Safety용 단말의 Bearer임을 도 35의 과정을 따라 binding할 수 있다.
따라서 이 후 해당 단말 혹은 bearer에 대한 요청을 Binding된 값을 기반으로 Public safety 용도라고 알 수 있다. 따라서 기지국(3510) 및 S-GW/P-GW(3530)는 다른 Bearer 보다 높은 우선순위로 데이터 전달을 처리할 수 있다.
상기 Extended Service Request 메시지를 전달하기 위해 단말(3500)은 기지국(3510)과 RRC 연결을 맺게 된다. 단말(3500)은 기지국(3510)과 RRC 연결을 맺을 때, 단말(3500)의 NAS layer는 RRC Establishment Cause라는 값을 설정하여 단말(3500)의 RRC layer로 알려준다.
RRC Establishment Cause는 보통 Mobile Originated Signaling인지, Mobile Originated Data인지, Mobile Terminated Signaling인지, Mobile Terminated Data 인지 등을 나타낸다. 그 후 단말(3500)의 RRC layer는 RRC 메시지를 구성하여 기지국(3510)으로 연결 요청을 보낸다.
본 발명에서는 RRC Establishment Cause에 Public Safety 임을 나타내는 식별자를 제안한다. 이는 Mobile Originated Public safety signaling, Mobile Originated Public safety data, Mobile Terminated Pubic safety signaling, Mobile Terminated public safety data 등으로 세분화된 식별자일 수 있으며, 혹은 Public Safety 전반을 나타내는 식별자 일 수 있다. 어떤 식별자가 어떤 이름을 갖건, Public safety 서비스(MCPTT 포함)를 나타내는 RRC 연결 요청에 대한 cause값을 포함한다.
단말(3500)은 상기와 같은 RRC establishment cause를 설정한 경우 단말(3500)과 기지국(3510) 간 혼잡 제어를 회피할 수 있으며(Overriding Congestion control) 혹은 단말(3500)과 기지국(3510) 간의 Access Class barring, Application level Congestion control for data communication(ACDC)를 회피할 수 있다.
또한 기지국(3510)은 상기와 같은 cause로 요청한 단말(3500)에 대하여 Public Safety 단말임을 저장, 후에 단말이 Handover가 필요한 경우 타 단말보다 우선하여 처리할 수 있다. 혹은 상기 cause를 수신한 기지국(3510)은 단말(3500)이 Public Safety(혹은 MCPTT)를 사용하고자 하는 단말임을 감지하고 Public Safety(혹은 MCPTT) 전용 Core Network로 Allocate할 수 있다. 상기의 기능을 따르는 경우 RRC Establishment Cause로 Public safety 관련 식별자를 수신한 기지국(3510)은 MME(3520)를 선택할 때 Public Safety 전용 MME 혹은 Public Safety 우선 MME로 설정된 MME로 연결을 요청할 수 있다.
다른 세부 실시 예로, MME(3520)는 망이 혼잡할 때, Public Safety 서비스를 위해 망에 접속한 단말(3500)에 대해서는 Back-off timer를 적용하지 않고 항상 망에 연결될 수 있도록 특별히 관리할 수 있다. 망이 혼잡한 상황에서 normal service를 이용하는 단말(3500)은 Back-off timer를 적용받아 일정시간 동안 망에 접속을 하지 않고 대기할 수 있다. 망이 혼잡한 상황에서 Public Safety를 이용하는 단말(3500)은 본 발명에서 제공하는 방법에 따라 MME에서 해당 단말이 Public Safety를 이용하는 단말임을 식별할 수 있으며, 이 경우 망이 혼잡한 경우더라도 Back-off timer를 적용하지 않고 망 연결을 허용할 수 있다.
<제7 실시예>
인터넷은 인간이 정보를 생성하고 소비하는 인간 중심의 연결 망에서, 사물 등 분산된 구성 요소들 간에 정보를 주고 받아 처리하는 IoT(Internet of Things, 사물인터넷) 망으로 진화하고 있다. 클라우드 서버 등과의 연결을 통한 빅데이터(Big data) 처리 기술 등이 IoT 기술에 결합된 IoE (Internet of Everything) 기술도 대두되고 있다. IoT를 구현하기 위해서, 센싱 기술, 유무선 통신 및 네트워크 인프라, 서비스 인터페이스 기술, 및 보안 기술과 같은 기술 요소들이 요구되어, 최근에는 사물간의 연결을 위한 센서 네트워크(sensor network), 사물 통신(Machine to Machine, M2M), MTC(Machine Type Communication)등의 기술이 연구되고 있다.
IoT 환경에서는 연결된 사물들에서 생성된 데이터를 수집, 분석하여 인간의 삶에 새로운 가치를 창출하는 지능형 IT(Internet Technology) 서비스가 제공될 수 있다. IoT는 기존의 IT(information technology)기술과 다양한 산업 간의 융합 및 복합을 통하여 스마트홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 스마트 그리드, 헬스 케어, 스마트 가전, 첨단의료서비스 등의 분야에 응용될 수 있다.
다양한 분야에서 IoT 기술이 각광받고 있으며, 통신 사업자 및 제조업체(vendor)들은 IoT를 이용한 여러 어플리케이션들 및 시스템들을 개발하고 있다. 다양한 IoT 해법(solution)들 중 셀룰러 시스템에 할당된 허가된(licensed) 주파수 대역을 이용하는 특히 셀룰러(cellular) IoT(이하, 'CIoT')가 주목받고 있다. 셀룰러 시스템이 비(non)-셀룰러 시스템에 비해 상대적으로 안정적인(reliable) 통신을 제공할 수 있고, 이에 따라 안정적인 서비스를 제공할 수 있기 때문이다. CIoT와 관련하여, eMTC(evolved machine type communication), GERAN(Global System for Mobile communications Enhanced Data rates for GSM Evolution Radio Access Network) CIoT 등 표준화 활동이 활발히 진행 중이고, 표준화 활동의 특성상 통신 사업자들의 요구(need)가 표준 결정에 결정적인 영향을 끼치는 경우가 많다.
진보된 통신 기술은 사용자간뿐 만이 아니라, 모든 사물간 통신을 가능하게 하고 있으며, 이를 IoT(Internet Of Things)라는 용어로 대변되고 있다. 예를 들어, 사용자는 여러 종류의 전자 기기를 가질 수 있으며, 이 모든 전자 기기들이, 이동 통신 혹은 근거리 통신 기술, 각종 센서 등으로 서로 연결되어 사용자에게 보다 편리한 기능들을 제공하거나, 기기간 효율적인 제어가 가능하다. 이러한 전자 기기들을 IoT 기기로 통칭할 수 있다. 또 다른 IoT 서비스의 예로, 건물의 전기 사용량, 수도 사용량 등을 측정하여 네트워크를 통해 측정 값을 전달하는 측정 장비가 존재할 수 있다. 또 다른 예로, Public Safety를 위하여 공공장소 혹은 외딴 지역에 안전 상황을 파악하기 위한 IoT 장치를 설치할 수 있으며, 해당 장치들이 특정 Event가 발생했을 때 네트워크를 통하여 Event 상황을 알려줄 수 있다. 또 다른 예로, 가정 내 가전기기에 네트워크 접속 기능이 포함되어 가전기기의 상태를 Report하거나 사용자가 가전기기로 특정 동작을 수행하도록 명령을 내리는 Device Trigger 동작이 가능하다.
IoT 기기는 LTE(long term evolution) 등의 이동 통신 모듈 혹은 블루투스, 무선랜(WiFi), 지그비(Zigbee), NFC(Near-Field Communication) 등의 근거리 통신 모듈을 포함한다.
LTE 단말은 LTE 캐리어(carrier) 주파수 상에서 동작될 수도 있고, ISM 대역 상에서 동작될 수도 있다.
본 명세서 전반에서 CIoT는 Cellular 네트워크를 사용하는 IoT 서비스를 나타낸다. Cellular 네트워크란 이동통신망을 의미하며, GERAN으로 대표되는 2G, GPRS로 대표되는 3G, LTE로 대표되는 4G를 포함한다. CIoT 서비스란 IoT(Internet of Things) 단말을 지원하기 위한 Cellular 서비스를 의미하며, Cellular 네트워크를 통하여 작은 용량의 데이터를 전송하는 서비스를 의미할 수 있다. 또한 MTC(Machine Type Communication) 서비스를 포함할 수 있다. Cellular 네트워크는 Radio Access Network 뿐만 아니라 Core Network까지 포함한 개념이다.
본 발명에서는 단말이 보내는 User plane 데이터와 Control plane 데이터를 구별하고 있다. User Plane 데이터는 단말이 인터넷 서비스 혹은 IoT 서비스를 이용하면서 사용하는 Application 관련 Traffic을 의미하며, Control Plane 데이터는 단말이 Cellular 네트워크를 이용하기 위하여 entity들과 주고 받는 제어 정보를 담은 데이터를 의미한다. 상기 용어는 상기 명칭에 한정되는 것은 아니며, 네트워크에서 데이터를 전공하기 위하여 보내는 패킷과 서비스를 제공하기 위하여 보내는 제어 신호를 구분하는 다른 용어가 사용될 수 있다.
CIoT를 위하여 기존의 네트워크 장비가 변경될 수 있다. 예를 들어 CIoT 전용 기지국이 존재할 수 있으며, 기존 기지국에 CIoT 기능을 추가한 기지국이 존재할 수 있다. 본 발명에서 CIoT 전용 기지국 혹은 기존 기지국에 CIoT 기능이 추가된 기지국을 포함하여 편의상 CIoT RAN이라 칭하겠다. 본 발명에서 해당 용어에 한정되는 것은 아니며, 동등한 기술적 의미를 가지는 다른 용어가 사용될 수 있다. 마찬가지로 Cellular 네트워크망에 존재하는 Core Network도 CIoT용으로 존재할 수 있다. 본 발명에서는 CIoT용 Core Network entitiy를 CIoT CN Node(Core Network Node)라고 칭할 것이며, 현재 3GPP에서는 C-SGN이라 불리고 있으나 본 발명에서 해당 용어에 한정되는 것은 아니며, 동등한 기술적 의미를 가지는 다른 용어가 사용될 수 있다. CIoT CN Node는 현 LTE 시스템에서 MME와 Serving Gateway의 기능을 포함하는 Entity를 의미하며, PDN Gateway의 기능까지 포함하는 Entity일 수 있다.
CIoT CN Node는 CIoT 단말의 Context 관리, 이동성 관리, 시그널링 세션 관리뿐 아니라 단말의 데이터를 Application Server로 전달하거나 Application Server로부터 받은 데이터를 단말에게 전달할 수 있다. 즉 CIoT CN Node는 CIoT 단말에게 게이트웨이 기능을 제공하며, CIoT RAN으로부터 데이터를 받아서 Application Sever로 라우팅하는 게이트웨이 역할을 수행할 수 있다. CIoT CN Node가 PDN Gateway의 기능도 포함할 경우, CIoT CN Node가 직접 Application Server로 User Plane 데이터를 전송할 수 있다.
CIoT CN Node는 CIoT 단말과 Control Plane 연결을 맺는다. CIoT CN Node가 CIoT 단말과 Control Plane 연결을 수립하려면 CIoT 단말은 CIoT RAN과 Control plane 용 bearer(A.K.A SRB; Signaling Radio Bearer)를 수립하게 되고, CIoT RAN은 CIoT CN Node와 Control plane 데이터를 전송하기 위한 S1 bearer 연결을 수립한다. 이에 따른 결과로 CIoT 단말은 CIoT CN Node와 Control plane bearer 연결을 수립하게 된다. CIoT 단말은 상기 수립된 CIoT 단말 ? CIoT RAN 간 SRB를 통해서 송수신하고, CIoT RAN은 해당 Control Plane 데이터를 상기 절차를 통해 수립한 CIoT CN Node와 S1 bearer를 통하여 전달한다. 상기에서 설명한 SRB 혹은 S1 Bearer는 그 명칭에 의미가 국한되지 않으며, SRB는 단말의 제어 정보 시그널을 전달하기 위하여 무선 자원에서 수립되는 bearer 연결을 의미하고, S1 Bearer는 CIoT RAN과 CIoT CN Node 사이에 제어 정보 시그널을 전달하기 위하여 사용되는 연결을 의미한다.
일반적으로 단말, 기지국 및 Core Network Entity는 Control Plane 데이터와 User Plane 데이터를 다른 우선순위로 처리하고 있다. 단말, 기지국 및 Core Network Entity는 Control Plane 데이터, 즉 제어 정보를 담고 있는 데이터는 User Plane 데이터보다 더 우선적으로 처리한다. Control Plane 데이터의 종류로는 Attach, Tracking area update, Service request 등이 있고, 단말에게 제공할 Session을 관리하기 위한 ESM(EPS Session Management) message가 있다. 상기 메시지들은 단말과 Core Network Entity간 교환되는 메시지이며, 상기 메시지는 NAS layer에서 처리하기 때문에 이를 NAS 메시지라고 부를 수 있다. 단말이 Control Plane으로 전송하는 데이터는 NAS 메시지에 포함되고, NAS 메시지는 RRC 메시지에 포함되어 단말로부터 기지국으로 전송된다. 기지국은 수신한 RRC 메시지의 NAS 메시지를 Core Network Entity(MME 혹은 CIoT CN Node)로 Control plane 연결을 통해서 전달한다.
CIoT 단말은 작은 데이터를 간헐적으로 송수신하는 성격을 가지고 있다. (Infrequent Small Data Transmission) 따라서 CIoT 단말과 CIoT CN Node 사이에 User Plane 연결을 수립하지 않고, Control Plane 연결만 수립하여 Control Plane 연결을 통해서 User Plane 데이터를 전송할 수 있다. 이로 인하여 User Plane 연결 수립 또는 User Plane 암호화 동작 또는 User Plane 연결 수립을 위한 제어 정보 signaling 절차 등을 생략하여 무선 자원 및 네트워크 단에서 효율성을 얻을 수 있다.
단말 및 기지국의 RRC layer에서는 RRC 메시지를 전송하기 위하여 Signaling Radio Bearer(SRB)를 사용한다. SRB는 현재 SRB 0, SRB 1, SRB 2가 있으며, 단말은 RRC 메시지에 NAS 메시지를 담아서 SRB 1과 SRB 2를 통해 전송한다. (현재 NAS layer 동작) 단말 및 Core Network Entity(예를 들어 MME)는 NAS layer에서 Procedure를 수행한다. NAS procedure를 통해서 네트워크는 단말을 제어하고 이동성을 관리하고 연결을 수립하는 등의 동작을 수행한다. 단말 및 Core Network Entity의 NAS layer는 NAS 메시지를 주고 받으면서 NAS procedure를 수행한다. 이 NAS 메시지는 제어 정보를 포함하고 있기 때문에 Control Plane을 통해서 송수신한다.
CIoT 서비스를 제공하기 위하여 단말이 Control Plane을 이용하여 User Data를 보낼 경우, 다음과 같은 문제가 발생할 수 있다.
?RRC layer에서의 문제
RRC layer에서 Control Plane 데이터를 보내기 위하여 사용하는 SRB 1과 SRB 2를 이용해서 NAS 메시지를 보내기 때문에, 단말은 NAS 메시지에 담긴 User Data를 Control Plane 데이터를 보내기 위해서 사용하는 SRB를 통해서 전송 할 수 있다. 상기 메시지를 수신한 기지국은 수신한 데이터가 CIoT 단말 혹은 일반 단말이 보내는 Control data인지 CIoT 단말이 보내는 User Data인지 구별하지 못하고 모두 Control Data라고 인식한다. (SRB를 통해서 왔기 때문에) 따라서 모두 Control Plane 데이터라고 판단하여 우선순위 처리를 하게 된다. 만약 기지국이 혼잡하여 일부 단말의 Control Data 조차 수신하기 어려울 경우, CIoT 단말의 User Data over Control plane 때문에 CIoT 단말 혹은 일반 단말의 Control Data를 처리하지 못하는 문제가 생길 수 있다. 다시말해서, CIoT 단말 혹은 일반 단말이 보내는 control data가 담긴 NAS 메시지를 CIoT 단말이 보내는 User data가 담긴 NAS 메시지 때문에 처리하지 못할 수 있다는 것이다.
?NAS Layer에서의 문제
CIoT CN Node는 CIoT 단말로부터 수신한 NAS 메시지가 Control data인지 User data인지 직접 데이터를 확인해보기 전에 알 수 없다. CIoT CN Node는 control data는 GTP-C에 매핑하여 PDN-gateway로 전달해야하고, user data는 GTP-U에 매핑하여 PDN-gateway로 전달해야한다. 따라서 CIoT CN Node는 CIoT 단말로부터 수신한 NAS 메시지를 확인하여 Control data인지 User data인지 구별한 후, User data는 P-GW에 GTP-U tunnel을 이용하여 전송해야 한다. CIoT 단말로부터 수신한 NAS 메시지가 Control Data인 경우, 이에 상응하는 procedure를 수행하거나 control 메시지를 구성하여 P-GW와 GTP-C interface를 통해서 교섭할 수 있다.
또한 CIoT 단말이 보내는 Traffic은 두가지 종류로 구분할 수 있다. 1) ACK이 필요한 경우 2) ACK이 필요 없는 경우. CIoT 단말은 많은 수의 단말이 네트워크에 접속하여 Small Data Transmission을 수행하기 때문에 무선 자원의 효율적인 이용이 중요하다. 따라서 1) ACK이 필요한 경우 일정 시간 동안 CIoT 단말과 CIoT RAN 사이의 RRC 연결을 유지하는 동작이 필요하고, 2) ACK이 필요 없는 경우 데이터 전송 후 바로 RRC_IDLE 상태로 천이하여 무선 자원을 절약할 수 있다.
또한 CIoT 단말이 보내는 Traffic은 Small Data가 대부분이지만, Software update등 비교적 많은 용량을 필요로 하는 Use Case가 있다. 이 경우 여러 개의 NAS 메시지로 구분하여 User data를 전송하게 되며, 연속적인 NAS 메시지가 전달되기 때문에 CIoT 단말과 CIoT RAN은 일정 시간 연결을 유지할 필요가 있다. 단말 및 CIoT RAN은 현재 사용하는 RRC 연결이 연속적인 메시지 전달을 필요로 하는 RRC 연결인지 구분한다면, 일정시간 RRC 연결을 유지하기 위한 동작을 수행할 수 있다. 반대로 연속적인 메시지 전달이 필요 없는 경우 RRC 연결을 유지하지 않고 바로 RRC_IDLE로 진입하여 불필요하게 RRC 연결을 유지하지 않아 무선 자원을 절약할 수 있다.
본 발명의 제7 실시예에서는 CIoT 트래픽 종류를 구분하여 특정 트래픽 전송을 우선적으로 실행하는 방법, 그리고 CIoT 전용 네트워크 장비와 CIoT를 지원하는 일반 네트워크 장비를 구분하여 CIoT 전용 네트워크 장비에 더 많은 CIoT 관련 시그널링을 처리할 수 있도록 하는 방법을 제안한다.
본 발명의 제7 실시예는 Cellular 네트워크에서 IoT를 지원하기 위한 단말 및 네트워크 장치의 동작을 다루고 있다. CIoT의 특징은 많은 수의 단말이 동시에 네트워크에 접속할 수 있으며, 또한 네트워크가 많은 수의 단말에게 동시에 데이터를 전달할 수 있다. 따라서 네트워크 혼잡 상황이 일반 Cellular 시스템보다 심화될 것으로 예상된다.
본 발명의 제7 실시 예는 3GPP에서 정의한 LTE 시스템을 기반으로 설명하고 있으나, WLAN, 블루투스 등 무선 통신 전반에서 유사하게 사용될 수 있다. 본 발명에서 공공 안전 서비스(Public safety)를 위한 ProSe 기능 중 하나인 UE to Network Relay 기능을 지원하기 위하여 코어 네트워크와 기지국 간 Relay 관련 정보를 교환하는 방법 및 장치, 그리고 기지국에서 Relay 기능을 지원하기 위하여 단말을 제어하는 방법 및 장치를 제안하고자 한다.
이하, 첨부된 도면을 참조하여 본 발명의 바람직한 실시 예들을 상세히 설명한다. 이 때, 첨부된 도면에서 동일한 구성 요소는 가능한 동일한 부호로 나타내고 있음에 유의해야 한다. 또한 본 발명의 요지를 흐리게 할 수 있는 공지 기능 및 구성에 대한 상세한 설명은 생략할 것이다. 그리고 후술되는 용어들은 본 발명에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.
또한 본 발명의 실시 예들을 구체적으로 설명함에 있어서, 3GPP가 규격을 정한 무선 접속망, 코어 망인 LTE와 진화된 패킷 코어(EPC: Evolved Packet Core)를 주된 대상으로 할 것이지만, 본 발명의 주요한 요지는 유사한 기술적 배경을 가지는 여타의 통신 시스템에도 본 발명의 범위를 크게 벗어나지 아니하는 범위에서 약간의 변형으로 적용 가능하며, 이는 본 발명의 기술 분야에서 숙련된 기술적 지식을 가진 자의 판단으로 가능할 것이다. 이하 설명에서 사용되는 제어 정보를 지칭하는 용어, Application Server로 전달되는 사용자 데이터(User data)를의미하는 용어, 네트워크 장치 사이에 제어 정보 전달을 위한 시그널링을 의미하는 용어(Control data), 장치의 구성 요소를 지칭하는 용어 등은 설명의 편의를 위해 예시된 것이다. 따라서, 본 발명이 후술되는 용어들에 한정되는 것은 아니며, 동등한 기술적 의미를 가지는 다른 용어가 사용될 수 있다.
이하 설명의 편의를 위하여, 3GPP LTE(3rd Generation Partnership Project Long Term Evolution) 규격에서 정의하고 있는 용어 및 명칭들이 일부 사용될 수 있다. 하지만, 본 발명이 상기 용어 및 명칭들에 의해 한정되는 것은 아니며, 다른 규격에 따르는 시스템에도 동일하게 적용될 수 있다.
이하에서 기재될 LTE 단말 및 IoT단말은 무선 통신이 가능한 이동 단말을 의미하는 것으로, 일 예로서 통신 기능을 구비하는 개인 정보 단말기(Personal Digital Assistant: PDA), 스마트 폰(Smart Phone), 휴대폰, 태블릿(tablet) 컴퓨터, 노트북 등이 될 수 있으며, 개인 장비 외에 수도 사용량, 전기 사용량, 온도를 확인하는 측정 단말, 화재 경보기, 지진 경보기 등 상황을 인지하여 Report하는 단말, 에어컨, 냉장고, 공기청정기, 보일러, 청소기 등 통신 기능이 있는 가전기기를 의미할 수 있다. 상기 언급된 종류 외에 모든 통신 가능한 사물을 본 발명에서 IoT 단말이라 칭할 것이다. 또한 IoT 단말 중 Cellular 네트워크를 이용하는 단말은 CIoT 단말이라 칭하겠다. CIoT 단말은 LTE 네트워크에서 작은 용량의 데이터를 보내는 단말을 의미할 수 있다. 본 발명의 CIoT 서비스를 위한 장치 및 기능, 동작은 LTE 네트워크에서 Small Data Transmission을 위한 장치 및 기능, 동작을 포함한다. IoT 데이터는 IoT 단말이 보내는 데이터 혹은 어떠한 종류의 단말이 보내는 작은 용량의 데이터를 의미할 수 있다.
도 36은 본 발명의 제7 실시예에 따른 Cellular IoT(CIoT) 서비스를 지원하는 네트워크 아키텍쳐(architecture)를 나타내는 도면이다.
도 36은 CIoT를 위한 네트워크 아키텍처를 나타낸 도면이다. 네트워크에는 CIoT 서비스를 지원하기 위하여 CIoT 전용 기지국이 존재할 수 있으며, 기존 기지국에 CIoT 기능을 추가한 기지국이 존재할 수 있다.
본 발명에서 CIoT 전용 기지국과 기존 기지국에 CIoT 기능을 추가한 기지국을 편의상 CIoT RAN(3620)이라 칭하겠다. 마찬가지로 Cellular 네트워크망에 존재하는 Core Network도 CIoT 전용으로 존재할 수 있다. 본 발명에서는 이를 CIoT CN Node(Core Network Node, 3630)라고 칭할 것이며, 현재 3GPP에서는 C-SGN이라 불리고 있으나 본 발명에서 해당 용어에 한정되는 것은 아니며, 동등한 기술적 의미를 가지는 다른 용어가 사용될 수 있다.
CIoT CN Node(3630)는 CIoT 단말(3600)의 Context 관리, 이동성 관리, 시그널링 세션 관리뿐 아니라 단말의 데이터를 Application Server(3640)로 전달하거나 Application Server(3640)로부터 받은 데이터를 단말에게 전달할 수 있다. 즉 CIoT CN Node(3630)는 CIoT 단말(3600)에게 게이트웨이 기능을 제공하며, 데이터를 받아서 Application Sever(3640)로 라우팅하는 S-GW/P-GW 역할을 수행할 수 있다.
이 경우 CIoT CN Node(3630)는 CIoT 단말(3600)과 Control Plane 연결을 맺고 User Plane 연결을 맺지 않을 수 있으며, Control Plane으로 CIoT 데이터 혹은 작은 용량을 가지는 데이터를 Control Plane으로 전송할 수 있다.
CIoT 트래픽은 낮은 data rate와 작은 용량, delay tolerant, 주기적/비주기적(event성), Response 필요/불필요 특성을 가질 수 있다. 보다 구체적으로 연기 알람, 고장 알람, 전원 부족 알람, 온도 경보 등 event성 Report를 하는 데이터 트래픽의 경우, 작은 용량의 데이터를 Uplink로만 보내며 Response가 필요 없으며, 상시 발생하지 않고 이벤트가 발생했을 때만 트래픽이 발생하는 특징이 있다. 상기 트래픽은 Public safety와 관련된 IoT 서비스에서 사용될 수 있으므로 다른 데이터 트래픽 보다 높은 우선순위를 가질 수 있다. 가스 사용량 측정, 수도 사용량 측정, 전기 사용량 측정 등 주기적 Report를 하는 데이터 트래픽의 경우, 작은 용량의 데이터를 Uplink로 보내며, 측정 Report에 대한 결과를 응답 받을 수 있고, 분/시간/일/월/년 단위 등 주기적으로 상시 발행할 수 있다. 단말의 전원을 켜고 끄거나, 특정 동작을 수행하도록 Trigger하는 데이터 트래픽의 경우 작은 용량의 데이터를 Uplink로 보내며, 동작 수행에 대한 응답을 Downlink로 전달 받을 수 있으며, 주기적 혹은 비주기적으로 발생할 수 있다.
상기 데이터의 경우 CIoT 단말(3600)이 명령을 하거나 명령을 전달 받아 수행하여야 하므로 일정 시간 내 데이터가 전달되지 않으면 Device 트리거링에 오랜 시간이 걸려 IoT 서비스 품질을 저해할 수 있으므로 네트워크에서 다른 데이터 트래픽 보다 우선적으로 처리될 필요가 있을 수 있다. IoT 단말의 소프트웨어/펌웨어 업데이트, 설정 값 업데이트 등을 위한 데이터 트래픽의 경우, 비교적 큰 용량을 Uplink와 Downlink로 사용할 수 있으며, 비교적 간헐적으로 일어나는 데이터 트래픽이다. 상기 데이터 트래픽은 Security 관련 정보를 업데이트하거나 IoT 근접 네트워크 내 추가된 IoT 장비에 대한 설정 업데이트 등에 사용될 수도 있다.
<제7-1 실시예. RRC layer 에서의 솔루션>
도 37은 본 발명의 제7-1 실시예에 따른 CIoT 단말과 CIoT RAN 사이에 Control plane 데이터를 전달하는 동작 및 내부 layer 별 동작을 나타낸 도면이다. 도 37에서 제7 실시예의 제안과 관련된 부분은 NAS layer에서 RRC layer에 NAS signaling connection을 요청할 때 indication으로 CIoT 용 RRC establishment cause와 Call type을 전달해주면, RRC layer에서 CIoT용 Call Type에 대한 Access control을 수행하거나, (CIoT 용 Call type으로 Access control을 수행하였거나 혹은 수행하지 않았거나) 상기 RRC establishment causen에 대한 SRB를 선택하여 해당 SRB로 RRC 메시지를 전달하는 과정이다..
일반적인 LTE 동작으로 NAS layer(Also known as EMM layer)에서 RRC Layer에 NAS 메시지를 전달하기 위한 RRC 연결(이를 NAS signaling connection이라고 한다)을 요청한다. 이 때 NAS layer는 RRC establishment Cause와 Call Type을 RRC layer로 전달한다. RRC establishment cause는 RRC 메시지에 담겨서 RRC layer에서 RRC 연결이 요청된 이유를 구분하기 위함이다. Call Type은 RRC layer에서 Access Control을 수행하기 위하여 연결 요청 타입을 구분하기 위함이다. RRC layer는 상기 RRC establishment cause에 따라 SRB로 전달할지 DRB로 전달할지, 어느 Logical channel로 보낼 지, 그리고 Call type에 따라 어떤 Access control을 수행할지 판단한다. Access control은 무선 자원의 혼잡을 제어하기 위한 기능이다.
CIoT UE(3700)는 IDLE 상태에 있다가 CIoT용 User Data를 보낼 필요가 있을 때 RRC layer로 RRC connection을 요청한다. 본 발명에 따른 CIoT UE(3700)는 NAS 메시지에 CIoT용 User Data를 담아서 보내기 때문에, NAS layer에서 RRC layer로 RRC Connection을 요청한다.
NAS layer는 NAS procedure를 사용하여 NAS 메시지를 전달하고, NAS 메시지를 보낼 때 RRC layer로 RRC connection establishment Cause와 Call type을 전달한다. 본 발명에서는 NAS layer가 상기 RRC connection establishment cause와 Call type을 CIoT용으로 새로 정의하고, 그에 따른 RRC 동작을 제안하고자 한다. 혹은 RRC connection establishment cause를 기존의 값을 사용하되 새로운 Call type을 이용하여 RRC layer로 알리는 동작을 제안한다. 혹은 RRC Connection Establishment cause를 새로운 값을 사용하되 기존의 Call type을 이용하여 RRC layer로 알리는 동작을 제안한다. 아래 설명에서는 RRC layer가 RRC 연결이 CIoT용 User Data 때문에 필요한 것임을 판단하는 것, 그리고 Call type을 보고 Access control을 수행하도록 판단하는 것까지 다루고 있다. 이 후 동작은 다른 부분에서 설명한다.
1.NAS layer는 CIoT용 User Data를 보내기 위하여 NAS signaling connection이 필요하기 때문에 RRC layer로 CIoT용 Mobile Originated(MO) Data 혹은 CIoT 용 Moblie Terminated(MT) Data임을 의미하는 새로운 RRC establishment Cause를 정의한다. Mobile Originated라 함은 CIoT 단말(3700)에서 네트워크로 보낼 데이터가 있다는 것을 의미하며, Mobile Terminated라 함은 CIoT 단말(3700)이 네트워크로부터 전달 받을 데이터가 있다는 것을 의미한다. CIoT용 Data라는 용어는 Small Data라는 의미를 포함한다. 명칭은 MO small data, MT small data, 혹은 MO CIoT Data, MT CIoT Data 등이 될 수 있으며, 그 명칭에 국한되진 않고, CIoT를 위해 사용되는 User data와 연관된 RRC establishment cause 값을 다 포함한다. (본 발명에서는 편의상 MO CIoT Data, MT CIoT Data라고 사용하겠다) RRC establishment cause는 RRC 메시지 내에 parameter로 포함된다. NAS layer로부터 상기 RRC establishment cause를 수신한 RRC layer는 RRC 연결 요청이 CIoT Data 때문임을 판단할 수 있다. 이를 판단한 RRC layer의 동작은 본 발명의 다른 부분에 다룬다.
NAS layer는 RRC establishment cause와 함께 Call type도 RRC layer로 전달해준다. (현재 Call type의 의미에 대한 설명) Call type은 Originating 시그널링인지(Control plane data를 보내기 위한 연결 요청인지), Originating Call인지(User plane data를 보내기 위한 연결 요청 인지), Terminating Call 인지(User plane data를 수신하기 위한 연결 요청인지), Emergency call 인지(Emergency 서비스를 위한 연결 요청인지) 등에 따라 구분된다.
본 발명에서는 CIoT용 User Data를 전송하기 위한 연결 요청 혹은 CIoT 용 User Data를 수신하기 위한 연결 요청을 위한 Call type을 새로 정의한다. 즉, Originating CIoT Data 혹은 Terminating CIoT Data라는 Call type을 정의할 수 있다. Originating CIoT Data라는 Call type은 CIoT용 User Data를 전송하기 위한 연결 요청이라는 의미를 나타내는 Call Type이다.
Terminating CIoT Data라는 Call type은 CIoT용 User Data를 수신하기 위한 연결 요청이라는 의미를 나타내는 Call type이다. 각각 call type은 Originating CIoT call 혹은 Terminating CIoT call이라는 명칭으로 쓰일 수 있다. 상기 새로운 Call Type은 CIoT data 혹은 Small Data를 송신하기 위하여 혹은 수신하기 위하여 RRC 연결 요청을 할 때 사용하는 Call Type이면 명칭에 국한되지 않고 지칭할 수 있다. NAS Layer는 상기 명세한 CIoT용 User Data 전송을 위한 RRC Establishment Cause와 CIoT용 연결을 나타내는 Call Type을 RRC layer로 전달한다. NAS layer가 상기 Call type을 RRC layer에게 보내면, RRC layer는 상기 Call type에 맞는 Access Control을 수행할 수 있으며, 이 방법은 본 발명의 다른 부분에서 다루겠다.
2.1에서 RRC establishment cause만 새로 정의하여 사용하고 Call type은 기존에 정의된 Call type을 따른다. 예를 들어 MO CIoT Data와 MT CIoT Data라는 RRC Establishment Cause를 사용하고, Call type은 기존의 Originating Call 혹은 Terminating Call을 사용한다. 상기 indication을 수신한 RRC layer는 해당 RRC 연결 요청이 CIoT Data로 인한 연결 요청이라는 것을 판단할 수 있다. 이로 인한 RRC layer의 동작은 다른 부분에서 다루겠다. RRC layer는 수신한 Call type에 대해서 기존 시스템 방식 그대로 Access control에 사용한다.
3.1에서 RRC establishment cause는 기존에 정의된 값을 사용하고, Call type을 CIoT 용으로 새로 정의하여 사용한다. 예를 들어 RRC Establishment Cause는 MO data 혹은 MT data로 설정한다. Call type은 1에서 제안한 type을 사용한다. RRC Layer는 상기 Call type에 맞는 Access Control을 수행한다. RRC layer는 RRC Establishment Cause는 기존의 MO data 혹은 MT data를 사용하지만 Call type이 CIoT에 대한 것임을 보고 CIoT용 User data를 전송하기 위한 RRC 연결 요청임을 판단할 수 있다.
상기 동작에 따라 RRC layer는 NAS layer로부터 RRC 연결 요청이 CIoT용 User Data 때문이라는 것을 판단할 수 있다. CIoT용 User Data는 NAS 메시지에 담기고, NAS layer는 RRC layer에 RRC establishment cause 와 Call type과 함께 상기 indication과 연관된 NAS 메시지를 전달한다. RRC layer는 전달 받은 NAS 메시지가 CIoT용 User Data를 담고 있음을 상기 제안한 RRC Establishment cause와 Call type을 보고 판단할 수 있다. RRC layer는 상기 NAS 메시지를 RRC 메시지에 포함하여 구성한다. 즉 RRC 메시지는 NAS 메시지를 포함하고 있으며, NAS 메시지는 CIoT용 User data를 포함하고 있다.
기존 동작에 따르면, RRC layer는 NAS 메시지를 전달하기 위하여 Signaling Radio Bearer(SRB)를 이용한다. SRB는 SRB 0, SRB 1, SRB 2가 있다. NAS 메시지는 SRB 1 또는 SRB 2로 전달된다. NAS layer의 EMM procedure(Attach, Tracking Area Update, Service Request)로 인하여 RRC 연결이 수행될 때, 해당 procedure를 위한 NAS 메시지는 SRB 1로 전달하여 RRC 메시지에 piggyback할 수 있다. 다른 경우 NAS 메시지는 SRB 2로 전달된다.
세부 예로, NAS layer는 EMM procedure에 의한 NAS 메시지에 CIoT용 User Data를 RRC 제어 메시지에 Piggyback할 수 있다. 예를 들어 Service Request 메시지(NAS message)에 CIoT용 User Data를 담아서 RRC 제어 메시지에 piggyback하여 전송할 수 있다. (현재 RRC 제어 메시지가 initial NAS 메시지는 piggyback할 수 있음. 본 발명은 initial NAS 메시지임에도 불구하고 CIoT용 User Data를 갖고 있을 경우의 처리를 설명하고 있음) 이 경우 NAS layer는 RRC layer에 해당 Service request 메시지가 CIoT용 User Data를 담고 있다는 것을 RRC establishment Cause 또는 Call type으로 알려줄 수 있다. 이를 판단한 RRC layer는 상기 NAS 메시지를 RRC 제어 메시지에 piggyback하여 SRB 1으로 전달하는 것이 아니라, CIoT용 User Data이기 때문에 SRB 2로 전달하도록 결정할 수 있다. SRB 2는 SRB 1보다 우선순위가 낮다. 따라서 SRB 1을 통하여 전달되는 기존의 Control data들이 CIoT 단말이 보내는 User data 보다 높은 우선순위를 가질 수 있다. 본 발명의 제안 내용을 따르지 않으면, CIoT 단말이 보내는 User data는 NAS 메시지에 실린 채 RRC 제어 메시지에 piggyback되어 SRB 1으로 전달 될 수 있다. 이는 다른 단말들이 보내는 Control Data와 CIoT용 User Data를 같은 우선순위를 가지는 signaling으로 인지한다는 것이며, 이를 구분하기 위하여 본 발명이 활용된다.
또 다른 예로, RRC 메시지에 piggyback하되, piggyback된 NAS 메시지를 가진 RRC 메시지를 SRB 2로 전달하도록 결정할 수 있다.
또 다른 예로, RRC layer는 CIoT용 User Data가 담긴 NAS 메시지를 담은 RRC 메시지를 SRB 2를 이용하여 전달하지만, Control data를 담은 다른 NAS 메시지와 구별하기 위하여 상기 발명 내용에 따라 RRC establishment cause 혹은 call type을 사용할 수 있다. 다시 말해서 상기 indication을 이용하여 CIoT용 User Data가 담긴 NAS 메시지를 다른 NAS 메시지보다 낮은 우선순위를 가진다고 판단하여, SRB 2에 메시지를 실어 보낼 때 우선순위 처리를 적용할 수 있다.
또 다른 예로, RRC layer는 가장 낮은 우선순위를 갖는 SRB 3을 새로 정의하여 SRB 3을 통하여 CIoT 용 User data를 담은 NAS 메시지를 전송할 수 있다. SRB 3는 가장 낮은 우선순위를 갖는 새로 정의된 SRB 일 수 있으며, CIoT 관련 데이터를 전송하기 위한 Radio bearer, 혹은 Small data를 전송하기 위한 Radio bearer를 의미할 수 있다.
본 발명의 다른 예로, RRC layer는 상기 RRC establishment cause 혹은 call type과 관련된 NAS 메시지를 전달하는 RRC 메시지에 대해서 AS security를 적용하지 않을 수 있다. 현재 동작은 단말과 기지국간 AS(Access Stratum) security가 activate된 후에는 항상 SRB 1과 SRB 2에 대해서 AS security를 적용하게 되어 있다. AS security를 적용한다 함은, RRC 메시지에 integrity protection을 적용하고 Encryption을 한다는 것을 의미한다. 본 발명에 따른 CIoT 단말은 CIoT User Data를 NAS 메시지로 전송하게 되고, NAS security를 적용하여 전송하기 때문에 AS security를 적용하는 것을 생략할 수 있고, RRC layer에서 이를 판단하여 AS security가 이미 activate되었고 SRB 1이나 SRB 2를 통해 NAS 메시지를 전송함에도 불구하고 AS security를 적용하지 않을 수 있다.
본 발명의 다른 예로, RRC layer는 CIoT용 User Data 전송을 위한 RRC 연결 요청에 대하여 다른 Access Control을 적용할 수 있다. 원래 동작을 설명하자면, 단말의 RRC layer는 기지국이 Broadcast하는 SIB 정보를 보고 Access Control에 대한 정보를 수신한다. Access Control에 대한 정보는, ac-BarringInfo라는 field로 SIB에 포함되어 있고, ac-BarringForMO-Data 혹은 ac-BarringFor-MO-Signalling 등으로 나타난다. 이 정보는 ac-BarringConfig라는 정보로 구성되어 있고 이는
ac-BarringFactor
If the random number drawn by the UE is lower than this value, access is allowed. Otherwise the access is barred. The values 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 set if all bits of the corresponding ac-BarringForSpecialAC are set to 0.
위와같이 정의되어 있다. (TS 36.331)
본 발명에 따르면 CIoT용 User Data가 NAS메시지를 통하여 전달되기 때문에, 기존의 RRC라면 이를 MO signaling으로 인지하여 ac-BarringForMO-signaling을 적용할 것이다. 일반적으로 signaling을 위한 barring factor는 data를 위한 barring factor보다 더 높은 확률로 access하도록 설정되어 있기 때문에, CIoT용 User data를 전송하는 것임에도 불구하고 signaling을 위한 barring factor를 적용받을 수 있다. 이런 동작을 방지하기 위하여 본 발명은 다음과 같은 동작을 제안한다. RRC layer는 NAS layer로부터 RRC 연결 요청을 받으면서 Call type을 수신한다. RRC layer는 Call type이 CIoT data 전달을 위한 Call type일 경우 해당 RRC 연결에 대하여 NAS 메시지 전달임에도 불구하고 ac-BarringForMO-data에 대한 factor를 적용한다. 혹은 RRC layer는 Call type이 MO signaling이어도 RRC establishment cause가 CIoT용 User Data를 나타낸다면, 해당 요청에 대하여 Ac-BarringForMO-data를 적용할 수 있다. 또는 기지국이 Broadcast하는 SIB 정보에 CIoT에 대한 ac-barring 정보가 들어있을 수 있다. 예를 들어 ac-BarringForCIoT, 혹은 ac-BarringForCIoT-data/ac-BarringForCIoT-signaling이 될 수 있다. CIoT 관련된 모든 것에 대해서 하나의 barring factor를 적용할 수도 있고, CIoT data에 대해서 혹은 CIoT signaling에 대해서 따로 따로 barring factor를 적용할 수도 있다. 상기 SIB을 수신한 단말은 상기 SIB에 포함된 CIoT용 ac-barring 정보에 따라 CIoT에 대한 Access Control을 수행할 수 있다.
도 38은 본 발명의 제7-1 실시예에 따른 CIoT 단말과 CIoT RAN 사이에 RRC 연결 요청 메시지를 전달하는 동작을 나타낸 도면이다.
CIoT 단말(3800)이 RRC_IDLE 상태이면(3801), CIoT RAN(3810)은 CIoT를 위한 access barring information과 함께 SIB broadcast를 CIoT 단말(3800)로 전송한다(3802).
CIoT 단말(3800)이 CIoT를 위한 access barring information를 억셉트하면(3803), CIoT 단말(3800)은 CIoT를 위한 RRC connection request가 요청되는지 판단할 수 있다(3804).
CIoT를 위한 RRC connection request가 요청되면, CIoT 단말(3800)은 Access barring check을 수행한다(3805). CIoT 단말(3800)은 Access가 barring되는지 판단하고(3806), RRC connection Establishment를 수행한다(3807). 이후, CIoT 단말(3800)은 CIoT RAN(3810)으로 RRC Connection Request를 전송한다(3808).
<제7-2 실시예. NAS layer 에서의 솔루션>
CIoT CN Node는 Control plane으로 수신한 CIoT User data를 GTP-U라는 User plane interface를 통하여 P-GW에 전달할 수 있어야 한다. NAS 메시지는 Control plane으로 전달되지만 본 발명에 따르면 CIoT User data가 NAS 메시지에 담겨오기 때문에 이를 구별하여 GTP-U를 통해 P-GW에 전달할 수 있어야 한다. 따라서 이를 구별하는 방법을 제안한다
도 39는 본 발명의 제7-2 실시예에 따른 NAS 메시지의 일 예를 나타낸다.
1.NAS PDU를 CIoT 용 혹은 Small Data transmission용으로 구성할 때, NAS PDU(3920)의 header에 indication(3900)을 추가한다. indication(3900)은 해당 NAS PDU(3920)가 Control Data인지 User Data인지 구별한다. indication(3900)은 control data/user data 중 하나의 값을 갖는 형식이 될 수도 있고, user data 하나만 지칭하는 형식일 수도 있고, small data transmission용임을 나타내는 하나의 값일 수도 있다. 즉 형태나 명칭에 국한되지 않으며 CIoT CN Node에서 Control data와 User data를 구별할 수 있게 하는 식별자 전체를 의미한다.
도 39에서 제안하는 NAS PDU(3920)의 header에는 NAS security indication(3910)이 포함될 수 있다. 이는 NAS PDU(3920)가 NAS security material로 integrity protected, encrypted되어 있기 때문에, 어떤 key로 integrity protected/encrypted 되었는지 나타내는 key index 값이 포함될 수 있다. Key index와 함께 어떤 알고리즘 방식이 쓰였는지 EIA 혹은 EEA를 나타낼 수 있다. (EIA: Integrity Algorithm, EEA: Encryption Algorithm)
2. CIoT RAN이 CIoT CN Node에 보내는 Initial UE message에 CIoT용 User Data임을 나타내는 indication을 사용한다. 또는CIoT RAN이 CIoT CN Node에 보내는 Uplink NAS Transport에 CIoT용 User Data임을 나타내는 indication을 사용한다. 상기 메시지들은 모두 CIoT RAN과 CIoT CN Node 사이의interface에서 전달되는 메시지이다. CIoT RAN은 단말의 NAS 메시지를 CIoT CN Node에 전송하기 위하여 Initial UE message 혹은 Uplink NAS Transport라는 메시지를 사용한다.
Initial UE message를 이용하는 경우, Initial UE message에 포함되는 RRC Establishment Cause에 상기 발명의 내용에서 다룬대로 CIoT 용 User Data를 보냄을 의미하는 RRC Establishment Cause를 포함한다. 이를 수신한 CIoT CN Node는 해당 NAS 메시지가 CIoT용 User Data임을 판단할 수 있다.
Uplink NAS Transport를 이용하는 경우, 새로 정의된 Message Type을 사용하여 CIoT용 User data임을 나타낸다. CIoT RAN과 CIoT CN Node 사이의 Interface를 통해 전달되는 메시지는 Message type이라는 filed를 갖고 있으며, 이 field의 Type of Message라는 Information element에 CIoT용 User Data 전송을 위한 메시지라는 Type을 새로 정의하여 사용할 수 있다.
3. CIoT RAN과 CIoT CN Node 사이의 Interface를 통해 전달되는 메시지는 Message type이라는 filed를 갖고 있으며, 이 field의 Type of Message라는 Information element에 CIoT용 User Data 전송을 위한 메시지라는 Type을 새로 정의하여, CIoT RAN과 CIoT CN Node 사이의 Interface를 통해 전달되는 메시지가 CIoT용 User Data 전송을 위한 메시지라는 것을 나타낼 수 있다.
상기 1,2,3에 대한 결과로 CIoT CN Node는 CIoT 단말이 보낸 NAS 메시지가 Control data인지 User data인지 구별하여 Control Data인 경우 GTP-C를 통하여 P-GW로 전송하고, User data인 경우 GTP-U를 통하여 P-GW로 전송한다. CIoT CN Node는 바로 P-GW로 전송하지 않고 S-GW를 통하여 P-GW로 전송할 수 있다. (현재 MME는 그렇게 구현되어 있음)
본 발명의 다른 실시 예로 CIoT 단말이 보내는 Traffic을 두가지 종류로 구분할 수 있다. 첫번째는 단말이 보내는 데이터에 대해서 ACK이 필요한 경우, 두번째는 단말이 보내는 데이터에 대해서 ACK 필요 없는 경우이다.
1. CIoT 단말이 데이터를 전송하였고, 해당 데이터에 대한 ACK이 필요한 경우, CIoT 단말과 CIoT RAN은 일정 기간 동안 RRC 연결을 유지하여 ACK을 수신할 수 있다. ACK을 수신하기전에 RRC 연결이 끊어지면 다시 RRC 연결을 맺기 위하여 RRC signaling이 발생하기 때문에, 불필요한 절차를 줄이기 위하여 ACK이 필요한 데이터를 보낸 CIoT 단말과의 RRC 연결에 대해서 일정 시간 RRC 연결을 유지하도록 동작할 수 있다.
2. CIoT 단말이 데이터를 전송하였고, 해당 데이터에 대한 ACK이 필요 없는 경우, CIoT 단말과 CIoT RAN은 RRC 연결을 유지할 필요가 없이 바로 해제할 수 있다. CIoT 단말은 간헐적으로 작은 데이터를 보내는 것(Infrequent Small Data Transmission)을 가정하고 있기 때문에, ACK이 필요 없는 데이터라면 RRC 연결을 바로 해제하여 가용한 무선 자원을 확보할 수 있다.
상기 두가지에 대한 솔루션으로 다음과 같은 방법을 제안한다.
첫 째로, RRC establishment cause로 구별하는 것이다. 즉 RRC establishment cause에 CIoT Data with ACK 혹은 CIoT Data without ACK과 같은 식으로, 해당 RRC 연결 요청이 ACK이 필요한 데이터 전송 때문인지 ACK이 필요 없는 데이터 전송 때문인지 나타낸다. 이는 Small data transmission with/without ACK과 같은 식으로 CIoT란 명칭에 국한되지 않으며, Small data transmission을 위한 RRC 연결 요청에 대한 의미도 포함할 수 있다.
둘 째로, RRC Mode를 구별하는 방법이다. 즉 CIoT 단말이 CIoT RAN에 RRC 연결을 요청할 때, RRC Mode를 구별하여 요청한다. 두가지 모드가 있을 수 있으며 첫번째 모드는 Connection을 일정시간 유지하는 모드, 두번째 보드는 즉각적으로 IDLE로 천이하는 모드가 있을 수 있다. 두 모드에 대한 명칭은 여러가지일 수 있다. 예를 들어 일정 시간 Connection을 유지하는 것이 default 혹은 normal 모드일 수 있으며, Immediately RRC연결을 해제하는(RRC IDLE로 가는) 것이 default 혹은 normal 모드일 수 있다. 본 발명에서 제안하는 모드는 RRC Connection을 일정시간 유지하는 동작을 포함하는 모드, 그리고 RRC connection을 바로 해제하는 동작을 포함하는 모드 모두를 포함한다.
셋 째로, NAS PDU에 indication을 추가할 수 있다. 이는 CIoT CN Node가 RRC 연결 유지/해제 동작을 알게하기 위함이다.
도 40은 본 발명의 본 발명의 제7-2 실시예에 따른 NAS 메시지의 다른 예를 나타낸다.
도 40을 참조하면, Indication(Control Data/User data)(4000)와 NAS security indication(4010)은 본 발명의 다른 예를 따른다. 본 예에서는 Acknowledge indication(4020)을 NAS PDU(4030)에 추가하여 해당 NAS 메시지를 수신한 CIoT CN Node가 NAS 메시지를 보낸 CIoT 단말에게 ACK가 필요한지 ACK가 필요없는지 판단할 수 있다.
ACK가 필요하다고 판단한 경우, RRC 연결을 일정시간 유지하도록 CIoT RAN에 signaling할 수 있다. ACK가 필요 없다고 판단한 경우, RRC 연결을 해제하도록 CIoT RAN에 signaling할 수 있다. 상기 signaling은 CIoT 단말을 식별할 수 있는 식별자, 예를 들어 IMSI를 포함할 수 있다.
CIoT 단말은 간헐적으로 Small data를 전송하는 것이 기본 동작이지만, software update 혹은 연속적인 데이터 reporting을 위하여 연속적인 small data를 전송해야하는 경우가 생길 수 있다. 즉 software update와 같은 큰 데이터를 여러 개의 NAS 메시지로 나눠서 송신 혹은 수신하거나, 여러 개의 각기 다른 CIoT User Data를 각기 다른 NAS 메시지로 송신 혹은 수신할 수 있다. 상기와 같은 연속적인 Uplink 혹은 Downlink traffic이 있음을 CIoT RAN 혹은 CIoT CN Node가 인지하여 무선 자원을 일정 시간 유지하게 하거나 무선 자원을 해제하여 가용한 무선 자원을 확보할 수 있다.
이에 대한 솔루션으로 첫 째, RRC mode indication을 활용한 방법이 있을 수 있다. RRC Connection mode를 Connection 유지 혹은 즉각적인 release로 구별할 수 있다. 이 방법은 본 발명의 다른 실시 예의 방법과 동일하다. 단 RRC Connection을 유지하는 모드로 진입하여 사용하는 경우, 단말이 RRC 메시지로 RRC release 요청을 CIoT RAN에게 할 수 있다. (현재는 기지국이 단말에게 release를 명령하는 동작만 있음) CIoT RAN은 RRC 연결을 해제할 수 있다.
또 다른 예로 일반적인 RRC 연결 방법을 사용하는 경우, 즉 기지국에서 RRC inactivity timer를 이용하여 RRC connection의 유지를 판단하는 경우, CIoT 단말이 RRC Connection을 release하겠다는 요청을 CIoT RAN에게 전달할 수 있다. (현재는 기지국이 단말에게 release를 명령하는 동작만 있음) 이 RRC Connection release request 메시지 from CIoT UE에는 release하는 이유에 대해서 cause값이 포함되며, 이 cause 값에 모든 전송이 끝났음을 나타낼 수 있다. 이를 수신한 CIoT RAN은 RRC Connection Release를 단말에게 전송하여 RRC 연결을 해제할 수 있다.
도 41 및 도 42는 NAS PDU의 header에 indication을 추가하여 CIoT CN Node가 연속적인 data 전송이 있을 것임을 알게 할 수 있다. 예를 들어 아래와 같이 구성할 수 있다.
도 41은 대용량 데이터를 segmentation한 후 total segmentation length 대비 현재 NAS PDU의 segmentation offset(4110)을 알려주는 방법이다. 예를 들어 100개의 segment로 나눠진 대용량 데이터이며, 그 중 58번째 segmentation이라면 segment offset에 58을 나타낸다.
도 42는 현재 전송하는 NAS PDU가 연속적으로 전송하는 NAS PDU 중 마지막인지를 나타내는 indication(4210)이다. 예를 들어 해당 indication(4210)이 true일 경우, 즉 마지막 NAS PDU 전송임을 나타낼 경우, CIoT CN Node는 더 이상 연속적인 전송이 없을 것이라고 판단하고 CIoT RAN에게 RRC 연결을 해제해도 된다는 것을 알려주거나, CIoT UE를 위한 User plane 연결(P-GW와의 GTP-U 연결, Application Server와의 Tunneling 연결 등)을 해제하여 가용한 자원을 확보할 수 있다. 다른 예로 해당 indication이 false 인경우, 즉 마지막 NAS PDU 전송이 아님을 나타낼 경우, CIoT CN Node는 연속적인 전송이 더 있을 것이라고 판단하고 CIoT RAN이 RRC 연결을 유지하도록 동작하거나, CIoT UE를 위한 User plane 연결(P-GW와의 GTP-U 연결, Application Server와의 Tunneling 연결 등)을 더 유지하도록 동작할 수 있다.
상기 첫 번째, 두 번째 예의 NAS security indication은 본 발명의 다른 부분에서 설명한 것과 동일하다.

Claims (15)

  1. 이동 통신 시스템에서 릴레이 단말(relay user equipment(UE))의 동작 방법에 있어서,
    릴레이 단말을 통해 네트워크에 접속하는 리모트 단말(remote UE)에 대한 리모트 단말 정보를 포함하는 리모트 단말 보고 메시지를 상기 릴레이 단말에 연결되는 MME(mobility management entity)로 전송하는 단계; 및
    상기 리모트 단말 보고 메시지에 상응하는 응답 메시지를 상기 MME로부터 수신하는 단계를 포함하는 것을 특징으로 하는 방법.
  2. 제1항에 있어서, 상기 리모트 단말 정보는,
    상기 리모트 단말에 할당된 IP 주소(address) 정보, 및 상기 리모트 단말에 대한 사용자 정보를 포함하는 것을 특징으로 하는 방법.
  3. 제2항에 있어서,
    IPv6 (internet protocol version 6)를 사용하는 경우, 상기 IP 주소 정보는 상기 리모트 단말에 대한 IP 주소 또는 IPv6 프리픽스(prefix) 정보이고,
    IPv4 (internet protocol version 4)를 사용하는 경우, 상기 IP 주소 정보는 상기 리모트 단말에 대한 IP 주소 및 포트 정보인 것을 특징으로 하는 방법.
  4. 제2항에 있어서, 상기 사용자 정보는,
    IMSI (International Mobile Subscriber Identity), MSISDN (mobile subscriber integrated services digital network number), SIP (session initiation protocol) URI (uniform resource identifier), 및 ProSe (proximity-based service) 용 사용자 정보 중에서 적어도 하나인 것을 특징으로 하는 방법.
  5. 제1항에 있어서,
    상기 리모트 단말 보고 메시지를 상기 MME로 전송하며 타이머를 구동하는 단계; 및
    상기 응답 메시지를 상기 MME로부터 수신하며 상기 타이머의 구동을 중단하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  6. 제1항에 있어서, 상기 리모트 단말 보고 메시지는,
    상기 릴레이 단말이 상기 리모트 단말을 릴레이(relay)하기 위해 사용하는 PDN (packet data network) 연결에 대한 제어 메시지임을 특징으로 하는 방법.
  7. 이동 통신 시스템에서 MME(mobility management entity)의 동작 방법에 있어서,
    릴레이 단말(relay user equipment(UE))을 통해 네트워크에 접속하는 리모트 단말(remote UE)에 대한 리모트 단말 정보를 포함하는 리모트 단말 보고 메시지를 상기 릴레이 단말로부터 수신하는 단계; 및
    상기 리모트 단말 보고 메시지에 상응하는 응답 메시지를 상기 릴레이 단말로 전송하는 단계를 포함하는 것을 특징으로 하는 방법.
  8. 제7항에 있어서, 상기 리모트 단말 정보는,
    상기 리모트 단말에 할당된 IP 주소(address) 정보, 및 상기 리모트 단말에 대한 사용자 정보를 포함하는 것을 특징으로 하는 방법.
  9. 제8항에 있어서,
    IPv6 (internet protocol version 6)를 사용하는 경우, 상기 IP 주소 정보는 상기 리모트 단말에 대한 IP 주소 또는 IPv6 프리픽스(prefix) 정보이고,
    IPv4 (internet protocol version 4)를 사용하는 경우, 상기 IP 주소 정보는 상기 리모트 단말에 대한 IP 주소 및 포트 정보인 것을 특징으로 하는 방법.
  10. 제8항에 있어서, 상기 사용자 정보는,
    IMSI (International Mobile Subscriber Identity), MSISDN (mobile subscriber integrated services digital network number), SIP (session initiation protocol) URI (uniform resource identifier), 및 ProSe (proximity-based service) 용 사용자 정보 중에서 적어도 하나인 것을 특징으로 하는 방법.
  11. 제7항에 있어서, 상기 리모트 단말 보고 메시지는,
    상기 릴레이 단말이 상기 리모트 단말을 릴레이(relay)하기 위해 사용하는 PDN (packet data network) 연결에 대한 제어 메시지임을 특징으로 하는 방법.
  12. 이동 통신 시스템에서 동작하는 릴레이 단말(relay user equipment(UE))에 있어서,
    신호를 송수신하는 송수신부; 및
    릴레이 단말을 통해 네트워크에 접속하는 리모트 단말(remote UE)에 대한 리모트 단말 정보를 포함하는 리모트 단말 보고 메시지를 상기 릴레이 단말에 연결되는 MME(mobility management entity)로 전송하고, 상기 리모트 단말 보고 메시지에 상응하는 응답 메시지를 상기 MME로부터 수신하도록 제어하는 제어부를 포함하는 것을 특징으로 하는 릴레이 단말.
  13. 제12항에 있어서,
    상기 리모트 단말 보고 메시지는 상기 릴레이 단말이 상기 리모트 단말을 릴레이(relay)하기 위해 사용하는 PDN (packet data network) 연결에 대한 제어 메시지이고,
    상기 리모트 단말 정보는 상기 리모트 단말에 할당된 IP 주소(address) 정보, 및 상기 리모트 단말에 대한 사용자 정보를 포함하는 것을 특징으로 하는 릴레이 단말.
  14. 제12항에 있어서, 상기 제어부는,
    상기 리모트 단말 보고 메시지를 상기 MME로 전송하며 타이머를 구동하고, 상기 응답 메시지를 상기 MME로부터 수신하며 상기 타이머의 구동을 중단하는 것을 특징으로 하는 릴레이 단말.
  15. 이동 통신 시스템에서 동작하는 MME(mobility management entity)에 있어서,
    신호를 송수신하는 송수신부; 및
    릴레이 단말(relay user equipment(UE))을 통해 네트워크에 접속하는 리모트 단말(remote UE)에 대한 리모트 단말 정보를 포함하는 리모트 단말 보고 메시지를 상기 릴레이 단말로부터 수신하고, 상기 리모트 단말 보고 메시지에 상응하는 응답 메시지를 상기 릴레이 단말로 전송하도록 제어하는 제어부를 포함하는 것을 특징으로 하는 MME.
PCT/KR2016/010783 2015-09-24 2016-09-26 리모트 프로세(remote prose) 단말에 대한 네트워크 망에서의 합법적 감청 지원 방안 WO2017052342A1 (ko)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN201680061602.5A CN108141751B (zh) 2015-09-24 2016-09-26 用于在网络中支持对远程邻近服务ue的合法监听的方法
US15/763,386 US10924975B2 (en) 2015-09-24 2016-09-26 Method for supporting lawful interception of remote prose UE in network
US17/173,577 US11627515B2 (en) 2015-09-24 2021-02-11 Method for supporting lawful interception of remote ProSe UE in network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201562232100P 2015-09-24 2015-09-24
US62/232,100 2015-09-24

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US15/763,386 A-371-Of-International US10924975B2 (en) 2015-09-24 2016-09-26 Method for supporting lawful interception of remote prose UE in network
US17/173,577 Continuation US11627515B2 (en) 2015-09-24 2021-02-11 Method for supporting lawful interception of remote ProSe UE in network

Publications (1)

Publication Number Publication Date
WO2017052342A1 true WO2017052342A1 (ko) 2017-03-30

Family

ID=58386513

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2016/010783 WO2017052342A1 (ko) 2015-09-24 2016-09-26 리모트 프로세(remote prose) 단말에 대한 네트워크 망에서의 합법적 감청 지원 방안

Country Status (3)

Country Link
US (2) US10924975B2 (ko)
CN (1) CN108141751B (ko)
WO (1) WO2017052342A1 (ko)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018186552A1 (ko) * 2017-04-02 2018-10-11 엘지전자(주) 무선 통신 시스템에서 사이드링크 통신을 수행하기 위한 방법 및 이를 위한 장치
WO2019095261A1 (en) * 2017-11-17 2019-05-23 Telefonaktiebolaget Lm Ericsson (Publ) Methods and devices for group communication
WO2020034552A1 (en) * 2018-12-28 2020-02-20 Zte Corporation Configuration of user plane functions for wireless systems
WO2020071987A1 (en) * 2018-10-05 2020-04-09 Skyresponse Ab Method, receiving interface, computer program and computer program product for grouping incoming alarm calls
CN111052791A (zh) * 2017-11-09 2020-04-21 Oppo广东移动通信有限公司 一种接入控制的方法,设备及计算机可读介质和系统
EP3641365A4 (en) * 2017-07-11 2020-04-22 Huawei Technologies Co., Ltd. DEVICE ACCESS METHOD, DEVICE AND SYSTEM
CN111480353A (zh) * 2017-12-18 2020-07-31 皇家Kpn公司 用于经由具有中继能力的用户设备（ue）在远程ue与电信网络之间建立信令连接的方法和设备
WO2020242159A1 (ko) * 2019-05-24 2020-12-03 엘지전자 주식회사 무선 통신 시스템에서 pc5 동작을 위한 nas 메시지의 송수신에 관련된 동작 방법 및 이를 위한 장치
US12041659B2 (en) 2017-06-15 2024-07-16 Guangdong Oppo Telecommunications Corp., Ltd. Access control method and related product

Families Citing this family (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017057954A1 (ko) * 2015-09-30 2017-04-06 엘지전자 주식회사 무선 통신 시스템에서 콜 송수신 방법 및 이를 위한 장치
US11589208B2 (en) * 2015-11-06 2023-02-21 Samsung Electronics Co., Ltd. Method for transmitting data in CIoT system and device therefor
ES2922993T3 (es) * 2016-02-17 2022-09-22 Nec Corp Selección de plano de control y plano de usuario para la transmisión de datos
WO2017142363A1 (ko) * 2016-02-19 2017-08-24 엘지전자 주식회사 서비스 요청 전송 및 사용자기기, 그리고 서비스 요청 수신 및 기지국
CN109076020A (zh) * 2016-03-30 2018-12-21 Idac控股公司 用于在下一代无线网络中支持低移动性设备的系统和方法
KR102588488B1 (ko) 2016-04-01 2023-10-12 인터디지탈 패튼 홀딩스, 인크 서비스 슬라이스 선택 및 분리를 위한 방법
US10972552B2 (en) * 2016-09-30 2021-04-06 Huawei Technologies Co., Ltd. Method and system for user plane path selection
KR102449475B1 (ko) 2016-10-21 2022-09-30 삼성전자 주식회사 무선 통신 시스템에서 단말이 지원 가능한 네트워크 정보에 기반한 단말의 네트워크 접속 방법 및 장치
US10779144B2 (en) * 2016-12-30 2020-09-15 Electronics And Telecommunications Research Institute Method and apparatus for transmitting downlink data and uplink data in NB-IoT system
WO2018128505A1 (ko) * 2017-01-06 2018-07-12 엘지전자(주) 무선 통신 시스템에서 릴레이를 통한 데이터 송수신 방법 및 이를 위한 장치
WO2018128519A1 (ko) * 2017-01-09 2018-07-12 엘지전자 주식회사 무선 통신 시스템에서 리모트 ue와 연결을 가진 릴레이 ue가 네트워크와 연결 수행 방법 및 이를 위한 장치
US10932175B2 (en) * 2017-03-21 2021-02-23 Lg Electronics Inc. Method for relay terminal to select remote terminal where access control is applied due to network congestion and relay terminal performing method
CN115022825B (zh) * 2017-03-24 2024-02-09 三星电子株式会社 任务关键数据通信系统中管理短数据服务的方法和用户设备
US10772148B2 (en) 2017-04-28 2020-09-08 Kt Corporation Method and apparatus for managing PDU session between base station and core network in next-generation wireless network
US11128673B2 (en) * 2017-08-04 2021-09-21 Blackberry Limited Method and system for access and use of multiple ISIM or ISIM credentials
US10869255B2 (en) * 2018-06-22 2020-12-15 T-Mobile Usa, Inc. Telecommunications between remote terminal and relay terminal
WO2020003886A1 (en) * 2018-06-25 2020-01-02 Nec Corporation Ue behavior when the device is attached for emergency service
WO2020013742A1 (en) * 2018-07-13 2020-01-16 Telefonaktiebolaget Lm Ericsson (Publ) Verification of lawful interception data
WO2020022840A1 (en) 2018-07-26 2020-01-30 Samsung Electronics Co., Ltd. Method and apparatus for prioritizing mission critical push to talk traffic during an emergency
EP3605962B1 (en) 2018-07-30 2023-06-07 Nagravision Sàrl A method to transmit messages between a device and a remoter server
US10999074B2 (en) * 2018-07-31 2021-05-04 Apple Inc. Dual-token authentication for electronic devices
US10817276B2 (en) * 2018-09-26 2020-10-27 Oracle International Corporation Methods, systems, and computer readable media for machine type communication (MTC)/internet of things (IoT) device software updating
CN110972330B (zh) * 2018-09-28 2021-12-14 华为技术有限公司 终端设备升级方法及相关设备
US10631148B1 (en) * 2019-02-06 2020-04-21 Verizon Patent And Licensing Inc. Systems and methods for QoS aware SIM refresh
US11310320B2 (en) * 2019-04-01 2022-04-19 Mediatek Inc. Enhanced procedure transaction ID (PTI) error handling
KR102661459B1 (ko) 2019-04-02 2024-04-29 엘지전자 주식회사 네트워크 장애를 대처하기 위한 방안
KR102631108B1 (ko) * 2019-04-26 2024-01-30 삼성전자 주식회사 무선 통신 시스템에서 QoS Flow 기반으로 브로드캐스트와 그룹캐스트를 통한 단말 대 단말 직접 통신을 지원하는 방법
US11012430B1 (en) * 2019-11-04 2021-05-18 Sprint Communications Company L.P. User equipment relay mediated network channels with blockchain logging
US10966058B1 (en) * 2020-03-03 2021-03-30 Motorola Solutions, Inc. System and method of operating a communication device to provide location information within status notification messages
GB2593912B (en) * 2020-04-08 2022-09-14 Samsung Electronics Co Ltd Emergency services for user equipment
WO2022000488A1 (en) * 2020-07-03 2022-01-06 Lenovo (Beijing) Limited Methods and apparatuses for access control of a small size and infrequent data transmission
CN114339748B (zh) * 2020-09-30 2025-07-04 华为技术有限公司 一种鉴权方法及其装置
US20220182872A1 (en) * 2020-12-08 2022-06-09 Verizon Patent And Licensing Inc. Temporary priority elevation for non-high priority access users
JP7537341B2 (ja) * 2021-03-30 2024-08-21 株式会社デンソー 車両用通信システム、中継サーバ、車両用通信機
CN115769612A (zh) * 2021-04-09 2023-03-07 中兴通讯股份有限公司 用于无线通信的方法、装置和计算机程序产品
BR112023023206A2 (pt) * 2021-05-08 2024-01-30 Beijing Xiaomi Mobile Software Co Ltd Métodos para detecção de falha de conexão e de processamento de informações, dispositivo de comunicação, e, meio de armazenamento legível por computador não transitório
EP4338502A4 (en) * 2021-05-13 2025-01-15 Qualcomm Incorporated TRANSMISSION OF SMALL DATA NON-ACCESS STRATUM (NAS) MESSAGES AND UPLINK (UL) USER DATA PACKETS DURING AN IDLE RADIO RESOURCE MANAGEMENT (RRC) STATE
WO2023045436A1 (zh) * 2021-09-24 2023-03-30 大唐移动通信设备有限公司 一种信息发送方法及装置
WO2024020991A1 (en) * 2022-07-29 2024-02-01 Qualcomm Incorporated Resource configuration and selection for downlink small data transmissions
EP4333543A1 (en) * 2022-08-30 2024-03-06 British Telecommunications public limited company Telecommunications network and a method of operating a telecommunications network
KR20240033964A (ko) 2022-09-06 2024-03-13 주식회사 케이티 이동 단말기의 세컨드 디바이스 접속 제어 방법, 코어망의 세컨드 디바이스 접속 제어 방법 및 세컨드 디바이스 접속 제어 시스템
WO2024078922A1 (en) * 2022-10-10 2024-04-18 Telefonaktiebolaget Lm Ericsson (Publ) Key management for applications
CN116528227B (zh) * 2023-06-30 2023-09-29 中国电信股份有限公司 用户面安全配置方法、装置、电子设备及存储介质
WO2025026336A1 (en) * 2023-07-31 2025-02-06 Mediatek Singapore Pte. Ltd. Handling collision between remote ue report procedure and connection release
CN117079517B (zh) * 2023-10-16 2024-01-09 中孚安全技术有限公司 服务于保密教育的智能汽车窃密体验系统、方法及介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010026287A1 (en) * 2008-09-08 2010-03-11 Nokia Corporation Adaptive transmission modes for transparent relay
US20140016537A1 (en) * 2012-05-04 2014-01-16 Qualcomm Incorporated Associating terminal user equipment with user equipment relays
US20150029866A1 (en) * 2013-07-29 2015-01-29 Htc Corporation Method of relay discovery and communication in a wireless communications system
WO2015026111A1 (ko) * 2013-08-18 2015-02-26 엘지전자 주식회사 무선 통신 시스템에서 중계기 동작 방법 및 장치
WO2015119427A1 (en) * 2014-02-04 2015-08-13 Lg Electronics Inc. Method and apparatus for notifying out-of-coverage for d2d operation in wireless communication system

Family Cites Families (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3739640B2 (ja) 2000-08-28 2006-01-25 シャープ株式会社 液晶モジュールの製造方法
JP4415789B2 (ja) * 2004-08-20 2010-02-17 株式会社日立製作所 無線通信システム
US8521170B2 (en) * 2006-01-10 2013-08-27 Research In Motion Limited System and method for routing an incoming call to a proper domain in a network environment including IMS
CN101137204B (zh) 2006-08-30 2011-04-27 华为技术有限公司 移动通信系统及移动通信方法
CN101166359B (zh) 2006-10-16 2010-12-29 中兴通讯股份有限公司 移动通信系统的选择管理节点的方法
WO2009009940A1 (en) 2007-07-18 2009-01-22 Zte Corporation A mobile terminal registration method in a radio network
CN101355793B (zh) 2007-07-27 2011-08-31 华为技术有限公司 识别用户设备的方法和装置及临时标识传递和分配方法
CN102821382B (zh) 2008-06-18 2015-09-23 上海华为技术有限公司 一种用于接入的装置
CN102821381A (zh) 2008-06-18 2012-12-12 上海华为技术有限公司 接入、获取用户设备上下文及用户设备标识的方法和装置
JP5544428B2 (ja) 2009-11-23 2014-07-09 テレフオンアクチーボラゲット エル エム エリクソン（パブル） セルラー・モデムを含む関連電子デバイス・グループに対して定義されたポリシーに従ったアクセス制御
US8904167B2 (en) * 2010-01-22 2014-12-02 Qualcomm Incorporated Method and apparatus for securing wireless relay nodes
CN102811497A (zh) 2011-06-03 2012-12-05 中国移动通信集团公司 一种接入网络的方法、终端及系统
US8837500B2 (en) 2011-06-23 2014-09-16 Alcatel Lucent Service data flow direction/redirection
US8750179B2 (en) 2011-08-15 2014-06-10 Blackberry Limited Efficient multimedia broadcast multicast service continuity methods
KR101935785B1 (ko) 2011-08-16 2019-04-03 삼성전자 주식회사 무선통신시스템에서 멀티미디어 방송 서비스를 수신하는 방법 및 장치
WO2013049137A1 (en) 2011-09-30 2013-04-04 Interdigital Patent Holdings, Inc. Methods, apparatus and systems for enabling managed remote access
EP2590444B1 (en) 2011-11-04 2020-02-12 Alcatel Lucent Enhanced indication of network support of SRVCC and/or voice-over-IMS for an user equipment in an EPS network
US8983475B2 (en) 2012-02-16 2015-03-17 Futurewei Technologies, Inc. System and method for partner network sharing architecture
CN103731811B (zh) 2012-10-11 2018-08-31 中兴通讯股份有限公司 一种演进的分组核心网络实现移动性管理的方法和系统
JP6159475B2 (ja) 2013-05-13 2017-07-05 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． アクセス制御方法及び装置
CN104469695B (zh) * 2013-09-12 2019-02-05 华为技术有限公司 网络接入方法、近距离通信服务器、中继终端及终端
WO2015115862A1 (ko) 2014-01-30 2015-08-06 엘지전자 주식회사 무선 통신 시스템에서 단말에 의해 수행되는 d2d 동작 방법 및 상기 방법을 이용하는 단말
GB2523773A (en) 2014-03-04 2015-09-09 Nec Corp Communication system
KR102099642B1 (ko) 2014-03-31 2020-04-10 삼성전자 주식회사 단말 대 단말 통신에서 데이터 전송하는 방법 및 장치
US20150295826A1 (en) * 2014-04-09 2015-10-15 Aruba Networks, Inc. Offloading Packet Treatment using Modified Packet Headers in a Distributed Switch System
US10756804B2 (en) * 2014-05-08 2020-08-25 Apple Inc. Lawful intercept reporting in wireless networks using public safety relays
KR102324580B1 (ko) 2014-05-08 2021-11-12 인터디지탈 패튼 홀딩스, 인크 Ｕｅ를 전용 코어 네트워크 노드에 리디렉트하기 위한 방법들 및 이동성 관리 엔티티(ｍｍｅ)
KR102024332B1 (ko) 2014-06-17 2019-09-23 후아웨이 테크놀러지 컴퍼니 리미티드 Mme 재선택 방법 및 mme
WO2015196324A1 (zh) 2014-06-23 2015-12-30 华为技术有限公司 数据传输的方法、集中处理节点、网关及基站
US10355965B1 (en) 2014-07-14 2019-07-16 Sprint Communications Company L.P. Leveraging a capacity indicator of a mobility management entity
WO2016024832A1 (ko) 2014-08-13 2016-02-18 엘지전자 주식회사 애플리케이션 별 네트워크 액세스 차단 방법 및 사용자 장치
WO2016024848A1 (en) 2014-08-14 2016-02-18 Samsung Electronics Co., Ltd. Method and apparatus for selecting dedicated core network
US10897723B2 (en) 2014-09-26 2021-01-19 Telefonaktiebolaget Lm Ericsson (Publ) Managing overload in at least one core network
EP3198926A4 (en) 2014-09-26 2017-10-25 Telefonaktiebolaget LM Ericsson (publ) Managing overload in at least one core network
WO2016072814A1 (en) 2014-11-07 2016-05-12 Samsung Electronics Co., Ltd. Method and apparatus for transmitting group message to user equipment (ue)
WO2016111565A1 (en) 2015-01-07 2016-07-14 Lg Electronics Inc. Method and apparatus for optimizing load re-balancing for dedicated core network in wireless communication system
CN107211446B (zh) 2015-01-29 2021-08-20 三星电子株式会社 用于在载波聚合系统中发送下行链路控制信道信息的方法和装置
CN107211345B (zh) 2015-01-30 2020-07-24 交互数字专利控股公司 用于高优先级应用的接入控制
CN118555541A (zh) 2015-06-23 2024-08-27 交互数字专利控股公司 用于邻近服务通信的优先级处理
AU2016310558B2 (en) * 2015-08-26 2019-10-31 Telefonaktiebolaget Lm Ericsson (Publ) Method and device for lawful interception for proximity services
US10362559B2 (en) * 2015-09-07 2019-07-23 Lg Electronics Inc. Method for supporting device-to-device direct communication in wireless communication system, and apparatus therefor

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010026287A1 (en) * 2008-09-08 2010-03-11 Nokia Corporation Adaptive transmission modes for transparent relay
US20140016537A1 (en) * 2012-05-04 2014-01-16 Qualcomm Incorporated Associating terminal user equipment with user equipment relays
US20150029866A1 (en) * 2013-07-29 2015-01-29 Htc Corporation Method of relay discovery and communication in a wireless communications system
WO2015026111A1 (ko) * 2013-08-18 2015-02-26 엘지전자 주식회사 무선 통신 시스템에서 중계기 동작 방법 및 장치
WO2015119427A1 (en) * 2014-02-04 2015-08-13 Lg Electronics Inc. Method and apparatus for notifying out-of-coverage for d2d operation in wireless communication system

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018186552A1 (ko) * 2017-04-02 2018-10-11 엘지전자(주) 무선 통신 시스템에서 사이드링크 통신을 수행하기 위한 방법 및 이를 위한 장치
US11140732B2 (en) 2017-04-02 2021-10-05 Lg Electronics Inc. Method for performing sidelink communication in wireless communication system and apparatus therefor
US12041659B2 (en) 2017-06-15 2024-07-16 Guangdong Oppo Telecommunications Corp., Ltd. Access control method and related product
EP3641365A4 (en) * 2017-07-11 2020-04-22 Huawei Technologies Co., Ltd. DEVICE ACCESS METHOD, DEVICE AND SYSTEM
US11638139B2 (en) 2017-07-11 2023-04-25 Huawei Technologies Co., Ltd. Device access method, device, and system
US11019480B2 (en) 2017-07-11 2021-05-25 Huawei Technolgoies Co., Ltd. Device access method, device, and system
EP4087298A1 (en) * 2017-07-11 2022-11-09 Huawei Technologies Co., Ltd. Device access method, device, and system
US11153806B2 (en) 2017-11-09 2021-10-19 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Access control method and device, computer readable medium and system
CN111052791A (zh) * 2017-11-09 2020-04-21 Oppo广东移动通信有限公司 一种接入控制的方法,设备及计算机可读介质和系统
EP3703417A4 (en) * 2017-11-09 2020-10-28 Guangdong Oppo Mobile Telecommunications Corp., Ltd. ACCESS CONTROL PROCESS AND DEVICE, COMPUTER AND SYSTEM READABLE SUPPORT
CN111052791B (zh) * 2017-11-09 2021-10-08 Oppo广东移动通信有限公司 一种接入控制的方法,设备及计算机可读介质和系统
WO2019095261A1 (en) * 2017-11-17 2019-05-23 Telefonaktiebolaget Lm Ericsson (Publ) Methods and devices for group communication
US11785570B2 (en) 2017-12-18 2023-10-10 Koninklijke Kpn N.V. Method of, and devices for, establishing a signalling connection between a remote user equipment, UE, and a telecommunication network via a relay capable UE
CN111480353A (zh) * 2017-12-18 2020-07-31 皇家Kpn公司 用于经由具有中继能力的用户设备（ue）在远程ue与电信网络之间建立信令连接的方法和设备
CN111480353B (zh) * 2017-12-18 2023-10-27 皇家Kpn公司 用于在远程ue与电信网络之间建立信令连接的方法和设备
US11336769B2 (en) 2018-10-05 2022-05-17 Skyresponse Ab Method, receiving interface, computer program and computer program product for grouping incoming alarm calls
WO2020071987A1 (en) * 2018-10-05 2020-04-09 Skyresponse Ab Method, receiving interface, computer program and computer program product for grouping incoming alarm calls
WO2020034552A1 (en) * 2018-12-28 2020-02-20 Zte Corporation Configuration of user plane functions for wireless systems
US11882476B2 (en) 2018-12-28 2024-01-23 Zte Corporation Configuration of user plane functions for wireless systems
WO2020242159A1 (ko) * 2019-05-24 2020-12-03 엘지전자 주식회사 무선 통신 시스템에서 pc5 동작을 위한 nas 메시지의 송수신에 관련된 동작 방법 및 이를 위한 장치

Also Published As

Publication number Publication date
CN108141751B (zh) 2021-11-02
US20180295556A1 (en) 2018-10-11
US11627515B2 (en) 2023-04-11
US10924975B2 (en) 2021-02-16
US20210250843A1 (en) 2021-08-12
CN108141751A (zh) 2018-06-08

Similar Documents

Publication Publication Date Title
WO2017052342A1 (ko) 리모트 프로세(remote prose) 단말에 대한 네트워크 망에서의 합법적 감청 지원 방안
WO2018174516A1 (ko) 무선 통신 시스템에서 nas 메시지 처리 방법 및 이를 위한 장치
WO2021066353A1 (en) Method and apparatus for performing authorization for unmanned aerial system service in wireless communication system
WO2018155908A1 (ko) 무선 통신 시스템에서 릴레이를 통한 데이터 송수신 방법 및 이를 위한 장치
WO2018066876A1 (ko) 무선 통신 시스템에서 v2x 통신 지원 방법
WO2021034093A1 (ko) 릴레이를 위한 인증
WO2021034073A1 (ko) 비구조화 트래픽을 중계하기 위한 방법 및 릴레이 ue
WO2018110939A1 (ko) 무선 통신 시스템에서의 트래킹 영역 할당 방법 및 이를 위한 장치
WO2018174525A1 (ko) 무선 통신 시스템에서 계층간 상호작용 방법 및 이를 위한 장치
WO2017126892A1 (ko) 이동 통신 시스템에서 단말의 통신 방법 및 장치
WO2018231028A1 (ko) 무선 통신 시스템에서 단말의 등록 방법 및 이를 위한 장치
WO2019098623A1 (ko) 무선 통신 시스템에서의 ladn 서비스 지원 및 제공 방법과 이를 위한 장치
WO2017119802A1 (ko) 무선 통신 시스템에서 nidd(non-ip data delivery) 구성 설정 방법 및 이를 위한 장치
WO2018128505A1 (ko) 무선 통신 시스템에서 릴레이를 통한 데이터 송수신 방법 및 이를 위한 장치
WO2018070689A1 (ko) 무선 통신 시스템에서의 반영형 서비스 퀄리티 적용 방법 및 이를 위한 장치
WO2018131984A1 (ko) 무선 통신 시스템에서 ue 설정 업데이트 방법 및 이를 위한 장치
WO2018093168A1 (ko) 무선 통신 시스템에서의 네트워크 노드 선택 방법 및 이를 위한 장치
WO2021015598A1 (ko) 복수의 sim에 기초한 통신
WO2019031865A1 (ko) 무선 통신 시스템에서 rrc 연결 절차 수행 방법 및 이를 위한 장치
WO2018008970A1 (en) Method and apparatus for specified attach procedure and mobility and paging support in data communication network
WO2018008980A1 (ko) 무선 통신 시스템에서 사용자가 선호하는 자원 운용 선택 방법 및 이를 위한 장치
WO2021029512A1 (ko) 어플리케이션 서버의 변경에 관련된 통신
WO2021157974A1 (ko) 멀티 액세스 pdu 세션과 관련된 통신
WO2021040463A1 (ko) 3gpp ps data off에 관련된 통신
WO2019031901A1 (en) METHOD AND DEVICE FOR OPERATING AND CONTROLLING A DATA STREAM

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16849067

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15763386

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16849067

Country of ref document: EP

Kind code of ref document: A1