+

WO2016003177A1 - 저전력 단말의 통신 효과를 높이는 방법 및 장치 - Google Patents

저전력 단말의 통신 효과를 높이는 방법 및 장치 Download PDF

Info

Publication number
WO2016003177A1
WO2016003177A1 PCT/KR2015/006738 KR2015006738W WO2016003177A1 WO 2016003177 A1 WO2016003177 A1 WO 2016003177A1 KR 2015006738 W KR2015006738 W KR 2015006738W WO 2016003177 A1 WO2016003177 A1 WO 2016003177A1
Authority
WO
WIPO (PCT)
Prior art keywords
user terminal
message
low power
power mode
information
Prior art date
Application number
PCT/KR2015/006738
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 US15/321,452 priority Critical patent/US10327208B2/en
Publication of WO2016003177A1 publication Critical patent/WO2016003177A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. Transmission Power Control [TPC] or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0225—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal
    • H04W52/0229—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal where the received signal is a wanted signal
    • H04W52/0235—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal where the received signal is a wanted signal where the received signal is a power saving command
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. Transmission Power Control [TPC] or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0251—Power saving arrangements in terminal devices using monitoring of local events, e.g. events related to user activity
    • H04W52/0258—Power saving arrangements in terminal devices using monitoring of local events, e.g. events related to user activity controlling an operation mode according to history or models of usage information, e.g. activity schedule or time of day
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Definitions

  • Embodiments of the present disclosure relate to a method and an apparatus for effectively exchanging information between nodes in a wireless communication system. More specifically, the present invention relates to a method and apparatus for controlling to increase an effect of a communication function when a terminal transmitting and receiving a message through an operator network operates in a low power state.
  • wireless communication systems have been developed to provide voice services while guaranteeing user activity.
  • wireless communication systems are gradually expanding to not only voice but also data services, and to the extent that they can provide high speed data services.
  • a shortage of resources and users require faster services, and thus, a more advanced wireless communication system is required.
  • wireless communication systems have standardized various Radio Access Network (RAN) based technologies such as E-UTRAN / UTRAN / GERAN in The 3rd Generation Partnership Project (3GPP).
  • RAN Radio Access Network
  • a communication system based on 3GPP standards may support various types of services and types of terminals. For example, not only a communication terminal directly used by a person such as a smart phone, but also a communication of an Internet of Things (IoT) terminal with little or no human intervention can be supported.
  • the terminal may manage a terminal starting from a voice and multimedia service, or may provide a communication service for delivering specific information to the terminal or collecting specific information from the terminal.
  • IoT Internet of Things
  • a power save mode may be used to reduce power consumption.
  • a node communicating with the terminal for example, a server
  • the user terminal cannot transmit the information because it is a low power mode.
  • the user terminal if the user terminal operates in the low power mode, the user terminal cannot receive data.
  • a node that communicates with the terminal for example, a server generates data and attempts to transmit the terminal operating in the low power mode, the transmission may fail when the user terminal is in the low power mode and an unnecessary transmission attempt may occur. Accordingly, there is a need for a message reception control method for a user terminal operating in a low power mode.
  • an address assigned to the user terminal in particular, an external IP (Internet Protocol) address may be recovered.
  • the node that exchanges data with the user terminal for example, the server does not know whether or not the address of the user terminal, the data transmission and reception fails, and additional retransmission may occur. Accordingly, there is a need for a method of controlling to maintain an address for a user terminal operating in a low power mode.
  • a communication method of a user terminal in a mobile communication system for achieving the above technical problem, in the low power mode of the user terminal request to perform a message transmission and reception in another network entity instead of the user terminal Transmitting a low power mode request message including information to a mobility management entity (MME); Receiving whether to use a low power mode and application parameters from the MME; And operating in a low power mode according to the received parameter.
  • MME mobility management entity
  • the low power mode request message may include at least one of information on a time for which the user terminal stays in a low power state, an active timer, and information on an active flag.
  • the method may further include transmitting, by the user terminal, information to be transmitted by the other network entity to the other network entity during the low power mode state.
  • a method of communication of a mobility management entity for achieving the above technical problem, different from the user terminal in the low power mode state of the user terminal from the user terminal
  • HSS home subscriber server
  • the communication method of the service capability server (SCS: Service Capability Server) according to an embodiment of the present invention for achieving the above technical problem, the message transmission and reception in place of the user terminal in the low power mode state of the user terminal from the user terminal Receiving information requesting to perform; And performing a message transmission / reception with a server during a low power mode state of the user terminal.
  • SCS Service Capability Server
  • the transmitting and receiving of the message with the server may include transmitting a message to the server by setting a sender address or an external ID of the message as an address or external ID of the user terminal.
  • the communication unit for transmitting and receiving signals with other network entities; And transmitting a low power mode request message to a mobility management entity (MME) in a low power mode of the user terminal, the low power mode request message including information requesting to perform message transmission and reception at another network entity instead of the user terminal.
  • MME mobility management entity
  • a control unit configured to receive whether to use the low power mode and an application parameter from the controller, and to control to operate in the low power mode according to the received parameter.
  • a mobility management entity for achieving the above technical problem is a communication unit for transmitting and receiving signals with other network entities; Receiving a low power mode request message from the user terminal, the low power mode request message including information requesting to perform a message transmission and reception at another network entity instead of the user terminal in the low power mode state of the user terminal; A control unit configured to transmit an application parameter and to transmit information to a Home Subscriber Server (HSS) in a low power mode of the user terminal to request that another network entity transmit and receive a message instead of the user terminal; It may include.
  • HSS Home Subscriber Server
  • Service Capability Server (SCS) according to an embodiment of the present invention for achieving the above technical problem
  • Communication unit for transmitting and receiving signals with other network entities;
  • a control unit configured to receive information from the user terminal requesting to perform message transmission and reception on behalf of the user terminal in the low power mode state of the user terminal, and to control message transmission and reception with a server during the low power mode state of the user terminal.
  • an information transmission method for a terminal operating in a low power mode may be provided.
  • a method for controlling message reception for a user terminal operating in a low power mode may be provided.
  • a method of controlling to maintain an address for a user terminal operating in a low power mode may be provided.
  • FIG. 1 is a view showing the structure of a communication system according to an embodiment of the present invention.
  • FIG. 2 is a diagram illustrating an example of a flowchart of a method of exchanging address information of an SCS between a user terminal and a network according to an embodiment of the present invention.
  • FIG. 3 is a diagram illustrating an example of an operation of a communication system for transmitting a message for a user terminal in a low power mode according to an embodiment of the present invention.
  • FIG. 4 is a diagram illustrating another example of a flowchart of an operation of a communication system for transmitting a message for a user terminal in a low power mode according to an embodiment of the present invention.
  • FIG. 5 is a diagram illustrating another example of a flowchart of an operation of a communication system for transmitting a message for a user terminal in a low power mode according to an embodiment of the present invention.
  • FIG. 6 is a diagram illustrating an example of a flowchart of operations of a user terminal and a network according to an exemplary embodiment.
  • FIG. 7 is a diagram illustrating another example of a flowchart of an operation of receiving and processing a message on behalf of a user terminal according to an embodiment of the present invention.
  • FIG. 8 illustrates another example of a flowchart of a method of receiving a message when a user terminal uses a low power mode according to an embodiment of the present invention.
  • FIG. 9 is a diagram illustrating an example of a flowchart of an operation for maintaining a connection state to a user terminal according to an embodiment of the present invention.
  • FIG. 10 is a diagram illustrating an example of a flowchart of a method of notifying whether WLAN offloading is allowed when a user terminal changes a new location registration or RAT.
  • FIG. 11 is a diagram illustrating another example of a flowchart of a process of performing WLAN offloadability update for a user terminal according to one embodiment of the present invention.
  • FIG. 12 is a block diagram of an MME according to an embodiment of the present invention.
  • FIG. 13 is a block diagram of a user terminal according to an embodiment of the present invention.
  • each block of the flowchart illustrations and combinations of flowchart illustrations may be performed by computer program instructions. Since these computer program instructions may be mounted on a processor of a general purpose computer, special purpose computer, or other programmable data processing equipment, those instructions executed through the processor of the computer or other programmable data processing equipment may be described in flow chart block (s). It creates a means to perform the functions. These computer program instructions may be stored in a computer usable or computer readable memory that can be directed to a computer or other programmable data processing equipment to implement functionality in a particular manner, and thus the computer usable or computer readable memory. It is also possible for the instructions stored in to produce an article of manufacture containing instruction means for performing the functions described in the flowchart block (s).
  • Computer program instructions may also be mounted on a computer or other programmable data processing equipment, such that a series of operating steps may be performed on the computer or other programmable data processing equipment to create a computer-implemented process to create a computer or other programmable data. Instructions for performing the processing equipment may also provide steps for performing the functions described in the flowchart block (s).
  • each block may represent a portion of a module, segment, or code that includes one or more executable instructions for executing a specified logical function (s).
  • logical function e.g., a module, segment, or code that includes one or more executable instructions for executing a specified logical function (s).
  • the functions noted in the blocks may occur out of order.
  • the two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the corresponding function.
  • ' ⁇ part' used in the present embodiment refers to software or a hardware component such as an FPGA or an ASIC, and ' ⁇ part' performs certain roles.
  • ' ⁇ ' is not meant to be limited to software or hardware.
  • ' ⁇ Portion' may be configured to be in an addressable storage medium or may be configured to play one or more processors.
  • ' ⁇ ' means components such as software components, object-oriented software components, class components, and task components, and processes, functions, properties, procedures, and the like. Subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables.
  • the functionality provided within the components and the 'parts' may be combined into a smaller number of components and the 'parts' or further separated into additional components and the 'parts'.
  • the components and ' ⁇ ' may be implemented to play one or more CPUs in the device or secure multimedia card.
  • the present technology targeting the LTE system may be applied to a UTRAN / GERAN system having a similar system structure.
  • the eNB (RAN node) may be replaced by the RNC / BSC, the S-GW may be omitted or included in the SGSN, and the P-GW may correspond to the GGSN.
  • the MME may correspond to SGSN.
  • the bearer concept of the LTE system may correspond to the PDP context of the UTRAN / GERAN system.
  • the main target service will be assumed to be a message service.
  • embodiments of the present invention may be applied to other communication services, for example, IP-based data communication service or SMS. Applicable in a range that does not deviate greatly from the scope, this will be possible in the judgment of those skilled in the art of the present invention. Therefore, the term message used in an embodiment of the present invention may be substituted and applied to data, information, packets, and the like.
  • the communication system may be a mobile communication system based on LTE.
  • a radio access network of an LTE mobile communication system may be used interchangeably with an evolved Node B, EUTRAN, hereinafter eNB or Node B, or a base station 130 and a mobility management entity ( Mobility Management Entity (MME) 150 and Serving-Gate (S-GW) 140.
  • EUTRAN evolved Node B
  • EUTRAN evolved Node B
  • MME Mobility Management Entity
  • S-GW Serving-Gate
  • User equipment (hereinafter, may be used interchangeably with UE or UE) 100 may include eNB 130 and S-GW 140, and a packet data network-gateway (P-GW: PDN). -Access to an external network through the gateway (160).
  • P-GW packet data network-gateway
  • the user terminal In order to transmit and receive data through the PGW, the user terminal needs to create a PDN connection, and one PDN connection may include one or more EPS bearers.
  • An application server (AS) 110 is a device that exchanges information associated with an application at a user and application level.
  • the AS may be called a server in the general service model, and the AS may be a device equivalent to an application function (AF).
  • AF application function
  • the Policy and Charging Rules Function (PCRF) 120 is a device for controlling a policy related to a quality of service (QoS) of a user.
  • a policy and charging control (PCC) rule corresponding to the policy is transmitted to and applied to the P-GW 160.
  • the eNB 130 is a Radio Access Network (RAN) node and corresponds to an RNC of a Universal Terrestrial Radio Access Network (UTRAN) system and a Base Station Controller (BSC) of a GSM EDGE Radio Access Network (GERAN) system.
  • the eNB 130 is connected to the UE 100 through a radio channel and plays a role similar to that of the existing RNC / BSC.
  • the S-GW 140 is a device that provides a data bearer, and generates or removes a data bearer under the control of the MME 150.
  • the MME 150 is a device for various control functions.
  • One MME 150 may be connected to a plurality of base stations.
  • a home subscriber server is a node that stores subscription data about a user.
  • Service Capability Server (SCS) 180 is a node located between an operator network and an AS, and provides a function of increasing added value when an AS provides services to users through an operator network.
  • SCS applied to Internet of Things (IoT) (or Machine Type Communication (MTC)) service to increase service value may be referred to as IoT-SCS (or MTC-SCS).
  • IoT-SCS or MTC-SCS
  • SCS-Proxy because it may provide a proxy function for transmitting and receiving messages instead of the user terminal.
  • the name is used for convenience of description based on the characteristics of the function, and the main point of the embodiments of the present invention is specialized for a specific service (service using a communication function such as IoT or MTC).
  • IoT Internet of Things
  • MTC-SCS Machine Type Communication
  • SCS-Proxy because it may provide a proxy function for transmitting and receiving messages instead of the user terminal.
  • the name is used for convenience of description based on the characteristics of the function
  • An inter-working function (IWF) 190 is a device that performs protocol conversion or data processing while being located between each communication node / server.
  • the IWF used in the IoT (or MTC) environment may be referred to as IoT-IWF (or MTC-IWF).
  • a network address translation (NAT) 195 is a device that translates or maps an IP address between a provider internal network and a provider external network.
  • the structure of the communication system may include a mobile switching center (MSC) and a gateway mobile switching center (GMSC).
  • GMSC is a device that acts as a gateway to a carrier network for CS (Circuit Switched) service, for example, voice service or Short Messaging Service (SMS).
  • CS Circuit Switched
  • SMS Short Messaging Service
  • the MSC is a device that controls the CS domain.
  • FIG. 2 is a diagram illustrating an example of a flowchart of a method of exchanging address information of an SCS between a user terminal and a network according to an embodiment of the present invention.
  • the user terminal 210 may transmit a message for generating a PDN connection, for example, a PDN connectivity request message, to the MME 220. If the attach is in progress, the message may be included in the attach message and transmitted.
  • the PDN connection creation request message may include at least one of an access point name (APN), information indicating characteristics of a terminal that is not sensitive to low priority or transmission delay, and information requesting an address of an SCS. have. According to an embodiment, the information requesting the SCS address may be included in a protocol configuration option (PCO) and transmitted.
  • PPN access point name
  • PCO protocol configuration option
  • the MME 220 may include information indicating that the APN and the SCS address are requested in the message sent to the SGW 230, for example, a Create Session Request message. If the user terminal 210 includes information indicating that the SCS address is requested in the PCO, the MME 220 transmits the PCO received from the user terminal 210 to the SGW 230 according to an embodiment. You can also pass it by inserting it into a message.
  • the SGW 230 may generate a Create Session Request message based on the information received from the MME 220 and transmit the generated Session Request message to the PGW 240. That is, the information received from the MME 220 in step 273 may be delivered to the PGW 240 by the SGW 230.
  • the PGW 240 determines the SCS address to inform the user terminal 210 in step 277. Can be. At this time, the address of the SCS that the PGW 240 will inform the user terminal 210 may be determined by APN for the current connection or basic QoS information for the user terminal 210. During this process, the PGW 240 may perform a DNS query or exchange information with another network node.
  • the PGW 240 may send the determined address of the SCS in the message sent to the SGW 230, for example, a Create Session Response message.
  • the determined address of the SCS may be included in the PCO and transmitted to the SGW 230.
  • the SGW 230 may transmit a message, for example, a Create Session Response message, to the MME 220 according to the information received from the PGW 240.
  • the message transmitted to the MME 220 may include the address of the SCS or the PCO containing the address of the SCS.
  • the MME 220 may insert the SCS address received from the SGW 230 into a message transmitted to the user terminal 210, for example, an Activate Default Bearer Request message. If the address of the SCS is inserted into the PCO and received, according to an embodiment, the MME 220 may insert the PCO received from the SGW 230 into the message as it is and deliver it to the user terminal 210.
  • the user terminal 210 may identify the address of the SCS from the message received from the MME 220 and store the address.
  • the stored SCS address can be used later when utilizing the function of the SCS for message transmission and reception.
  • FIG. 3 is a diagram illustrating an example of an operation of a communication system for transmitting a message for a user terminal in a low power mode according to an embodiment of the present invention.
  • the user terminal 310 may decide to change the state to a power save mode (PSM) according to a terminal state, a request of a service application, and setting information.
  • PSM power save mode
  • the user terminal 310 may transmit a tracking area (TA) update request message to the MME 320 in step 373 to request the use of the low power state.
  • the TA update request message transmitted from the user terminal 310 to the MME 320 includes at least one of a periodic TAU timer, an active timer, and an active flag if necessary. Can be.
  • the Periodic TAU timer represents a time interval until the next TAU occurs. Therefore, the periodic TAU timer may be a value representing a time for the user terminal 310 to stay in the low power mode. If there is a message to be sent before the user terminal 310 enters a low power state, the user terminal 310 may send a TA update message by setting an active flag.
  • the user terminal 310 may explicitly include information for requesting the use of a function of performing a message transmission in a network instead of the user terminal 310 in the TA update request message.
  • the user terminal 310 may include information indicating the characteristics of the terminal that is not sensitive to low priority or transmission delay in the TA update request message.
  • the MME 320 may determine whether to use the low power mode and an application parameter (Periodic TAU timer, active timer) according to a TA update request from the user terminal.
  • the MME 320 may include the information in a TA update accept message transmitted to the user terminal 310.
  • the Periodic TAU timer represents a time interval until the next TAU occurs, and is a value representing the time that the user terminal 310 stays in the low power mode.
  • the MME 320 may request a user terminal 310 (for example, information indicating characteristics of a terminal that is not sensitive to low priority or transmission delay), characteristics of a PDN connection that the user terminal 310 has (APN, ARP).
  • Etc. internal settings, and subscription information may determine whether to apply a function for transmitting a message in the network instead of the user terminal 310.
  • the MME 320 may explicitly include the result in the TA update accept and transmit the result to the user terminal 310.
  • the user terminal 310 may obtain a parameter from the TA update accept message received from the MME 320, and apply the parameter to perform the operation for entering the low power mode.
  • the user terminal 310 may start the active timer and wait without changing the state to the low power mode until the active timer expires.
  • the MME 320 may notify the HSS or the IWF 330 that the user terminal 310 is switched to the low power mode.
  • the MME 320 may transmit information such as duration information of the low power mode of the user terminal 310 to the HSS or the IWF 330.
  • the user terminal 310 may determine whether a function for replacing data in the network is required when a server (or an external network) requests data transmission during its low power mode operation. This may be based on internal configuration information of the user terminal 310, or information included in the attach accept message received before or before the TA update accept (for example, instead of the user terminal 310, message transmission may be performed in a network. Or support for the function to perform).
  • the user terminal 310 may transmit the message to the SCS 350 before the active timer expires in step 381.
  • the message may be, for example, a message using IP communication, and more specifically, a message using COAP, MQTT, XMPP, or HTTP protocol.
  • the transmission code or cause of the message may be, for example, POST.
  • the message includes information indicating that the user terminal 310 operates in a low power mode, a time when the low power mode is applied, information for requesting a transmission operation instead of the user terminal 310, and a radio access to which the user terminal 310 is connected.
  • the message may also include an active timer.
  • the message may be delivered to the SCS 350 via the PGW 340 (step 383).
  • the destination address of the message may be set to the address of the SCS 350 received in advance.
  • the user terminal 310 may include its external ID in the message transmitted to the SCS 350. Meanwhile, the user terminal 310 determines whether to perform a series of operations for requesting a cycle by performing a transmission operation in a network instead of the user terminal while the user terminal 310 is in a low power mode.
  • the terminal 310 may utilize the RAT information that is being accessed.
  • the user terminal 310 may request the function only when the user terminal 310 is using a specific RAT, for example, a low transmission rate GERAN.
  • the SCS 350 may receive a message from the user terminal 310 in step 381 (and step 383). In this case, if the received message includes an active timer, in step 385, the SCS 350 may start the timer.
  • the SCS 350 operates in the low power mode of the user terminal 310 according to the message received in the previous steps (ie, steps 381 and 383), and should perform a message transmission operation instead of the user terminal 310. It can be seen.
  • the received time includes all of the low power maintenance time of the user terminal 310
  • the SCS 350 is included in the received message unless a separate message is received from the user terminal 310. It is assumed that the user terminal 310 operates in the low power mode during the low power mode holding time, and an operation of transmitting a message may be performed instead.
  • the SCS 350 may apply the operation of transmitting a message on behalf of the user terminal 310 from when the active timer expires.
  • the SCS 350 may distinguish between the user terminal 310 and the actual server, from the message sent by the user terminal 310, a source IP address, a port, and a real destination IP address. And ports.
  • the SCS 350 may store it.
  • the SCS 350 may utilize the RAT information that the user terminal 310 is connected to determine whether to perform the operation.
  • the SCS 350 may apply the function only when the user terminal 310 is using a specific RAT, for example, a low transmission rate GERAN.
  • the SCS 350 converts the protocol according to the type of the RAT to which the user terminal 310 is connected (that is, converts the message transmitted from the user terminal 310 to the CoAP into an HTTP message or sends the message to the user terminal 310). You can also decide whether to apply the protocol of the message to be sent from HTTP to CoAP).
  • the SCS 350 may transmit a message indicating that the message has been received to the user terminal 310.
  • This message may use the same protocol as the message transmitted by the user terminal 310, and the transmission code or cause may be set to 200 OK, for example.
  • the message may be transmitted to the user terminal 310 via the PGW 340 (step 389).
  • the user terminal 310 starts to operate in the low power mode in step 391.
  • the SCS 350 may receive a message from the server requesting the message transmission to the user terminal 310.
  • This message may be, for example, a message using IP communication, and more specifically, a message using COAP, MQTT, XMPP, or HTTP protocol.
  • the transmission code or cause of the message may be, for example, GET.
  • the SCS 350 may compare the stored information and the destination address (IP address and port) or external ID of the received message to compare whether there is a user terminal 310 having a matching address or ID.
  • the SCS 350 transmits a response message instead of the user terminal 310 in response to the message for the user terminal 310 operating in the low power mode. It can be seen that it is necessary to do.
  • the SCS 350 may send a response message instead of the user terminal 310.
  • This response message may be, for example, a message using IP communication, and more specifically, a message using COAP, MQTT, XMPP or HTTP protocol.
  • the transmission code or cause of the message may be, for example, 200 OK.
  • the message may include a message that the user terminal 310 has requested to transmit instead.
  • the sender address or external ID of the message may be set to the address or external ID of the user terminal 310 rather than the SCS 350. If the protocol of the message transmitted by the user terminal 310 and the protocol used by the server are different from each other, for example, when the user terminal 310 uses the CoAP protocol and the server uses the HTTP protocol, the SCS ( 350 may perform a protocol conversion.
  • the user terminal 310 operates in the low power mode in the already attached state, that is, the TA update process is performed.
  • the operation of the user terminal 310 and the network is performed by the user. It may also be applied when the attach process for the terminal 310 is performed. If the above embodiment is applied during the attach process, the TA update request message may be replaced by an attach request message and a TAU accept message by an attach accept message.
  • FIG. 4 is a diagram illustrating another example of a flowchart of an operation of a communication system for transmitting a message for a user terminal in a low power mode according to an embodiment of the present invention.
  • the user terminal 410 may decide to change the state to a power save mode (PSM) according to a terminal state, a request of a service application, configuration information, and the like.
  • PSM power save mode
  • the user terminal 410 may transmit a TA update request message to the MME 420 in step 473 to request the use of the low power state.
  • the TA update request message transmitted from the user terminal 410 to the MME 420 may include at least one of a periodic TAU timer, an active timer, and an active flag if necessary. If there is a message to be sent before the user terminal 410 enters the low power state, the user terminal 410 may send a TA update message by setting an active flag.
  • the user terminal 410 may explicitly include information for requesting the use of a function of performing a message transmission in a network instead of the user terminal 410 in the TA update request message.
  • the user terminal 410 may transmit information indicating the characteristics of the terminal that is not sensitive to low priority or transmission delay in the TA update request message.
  • the MME 420 may determine whether to use the low power mode and an application parameter (Periodic TAU timer, active timer) according to the TA update request of the user terminal 410.
  • the MME 420 may include the information in a TA update accept message transmitted to the user terminal 410.
  • the MME 420 may request the user terminal 410 (for example, information indicating characteristics of a terminal that is not sensitive to low priority or transmission delay), characteristics of a PDN connection of the user terminal 410 (APN, ARP). Etc.), internal settings, and subscription information may determine whether to apply a function for performing a message transmission in a network instead of the user terminal 410.
  • the MME 420 may explicitly include the result in the TA update accept and transmit the result to the user terminal 410.
  • the user terminal 410 may obtain a parameter from the TA update accept message received from the MME 420, and apply the parameter to perform the operation for entering the low power mode.
  • the user terminal 410 may start the active timer and wait without changing the state to the low power mode until the active timer expires.
  • the MME 420 may notify the HSS or the IWF 430 that the user terminal 410 is switched to the low power mode.
  • the MME 420 may inform the HSS or IWF 430 of at least one of an identifier, an IP address of the user terminal 410, a RAT to which the user terminal is connected, duration information of a low power mode, and an active timer. Can be passed together.
  • the HSS or IWF 430 stores the information received from the MME 420, and then whenever the information about the user terminal 410 is requested from the SCS 450, or whenever the state of the user terminal 410 is changed. At least one of the stored information may be transmitted to the SCS 450.
  • the user terminal 410 may determine whether a function for replacing this in the network is necessary. This may be based on internal configuration information of the user terminal 410 or information included in the attach accept message received before or before the TA update accept (for example, instead of the user terminal 410, message transmission may be performed in a network. Or support for the function to perform).
  • the user terminal 410 may transmit the message to the SCS 450 before the active timer expires.
  • the message may be, for example, a message using IP communication, and more specifically, a message using COAP, MQTT, XMPP, or HTTP protocol.
  • the transmission code or cause of the message may be, for example, POST.
  • the message may include one or more of information requesting a transmission operation instead of the user terminal 410, a message to be actually transmitted, and an external ID of the user terminal 410.
  • the message may be delivered to the SCS 450 via the PGW 440 (step 481).
  • the destination address of the message may be set to the address of the SCS 450 received in advance.
  • the SCS 450 may store information included in the message received from the user terminal 410.
  • the SCS 450 may receive a message from the user terminal 410 in steps 481 and 483.
  • the SCS 450 may transmit a message requesting the status information of the user terminal 410 to the HSS or the IWF 430 to confirm the status information of the user terminal 410. This operation may be performed when the state information on the user terminal 410 is not stored in the SCS 450 or when a validity timer for the user terminal 410 state information has expired. Can be.
  • the request message may include one or more of an external ID or an IP address of the user terminal 410.
  • the HSS or IWF 430 may perform an operation for obtaining status information of the user terminal 410 from the address of the message received in step 489. For example, the HSS or IWF 430 may map an external ID or IP address received from the SCS 450 to a 3GPP unique identifier (eg, IMSI), and use this to obtain status information of the user terminal 410. .
  • a 3GPP unique identifier eg, IMSI
  • the HSS or IWF 430 may transmit a message for notifying the SCS 450 of the state information of the user terminal 410 in step 491.
  • the HSS or IWF 430 may indicate an external ID of the user terminal 410, an IP address of the user terminal 410, and a current state of the user terminal 410 in the user terminal status information message sent to the SCS 450.
  • the message may include information indicating that a function of transmitting a message on behalf of the user terminal 410 should be applied during the low power mode of the user terminal 410.
  • the message may include an active timer. If the message includes an active timer, the SCS 450 starts the active timer upon receiving the message, and transmits the message instead of the user terminal 410 from the moment when the active timer expires. Applicable, the message may include a validity timer, which indicates a time when the state information of the user terminal 410 included in the currently transmitted message is valid. Upon receiving this message, the SCS 450 may store the information and determine the current time and the low power state of the user terminal 410 according to the information.
  • the HSS or IWF 430 may utilize the RAT information that the user terminal 410 is connected to determine whether to perform the operation (that is, the message proxy function). In particular, the HSS or IWF 430 may request the function only when the user terminal 410 is using a specific RAT, for example, a low transmission rate GERAN. In addition, the HSS or IWF 430 may convert the protocol according to the type of the RAT to which the user terminal 410 is connected (that is, convert the message transmitted by the user terminal 410 to CoAP into an HTTP message or transmit the message to the user terminal). You can also decide whether to request to apply the protocol of the message to switch from HTTP to CoAP.
  • the SCS 450 may recognize that the message transmission operation should be performed instead of the user terminal 410 according to the message received in the previous step.
  • the SCS 450 may distinguish a source address (Source IP address), a port, and a real destination address (destination IP address) from a message sent by the user terminal 410 to distinguish the user terminal 410 from the actual server. And ports.
  • the SCS 450 may store the external ID.
  • the SCS 450 may utilize the RAT information that the user terminal 410 is connected to determine whether to perform the operation.
  • the SCS 450 may apply the function only when the user terminal 410 is using a specific RAT, for example, a low transmission rate GERAN.
  • the SCS 450 converts the protocol according to the type of RAT to which the user terminal 410 is connected (that is, converts the message transmitted from the user terminal 410 to the CoAP into an HTTP message, or sends the message to the user terminal 410). You can decide whether to apply the protocol of the message to be sent from HTTP to CoAP).
  • the SCS 450 may transmit a message indicating that the message has been received to the user terminal 410.
  • This message may use the same protocol as the message transmitted by the user terminal 410, and the transmission code or cause may be set to 200 OK, for example.
  • the message may be transmitted to the user terminal 310 via the PGW 340 (step 494).
  • the SCS 450 determines whether to perform an operation of transmitting a message on behalf of the user terminal 410 according to the state information of the user terminal 410 received in step 491 from the HSS or IWF 430. Can be. If the message received from the HSS or IWF 430 includes information on the time when the user terminal 410 operates in the low power mode, the SCS 450 starts the timer according to the time, and the timer expires. Until a message is transmitted instead of the user terminal 410.
  • the user terminal starts to operate in the low power mode in step 495.
  • the SCS 450 may receive a message from the server requesting the message transmission to the user terminal 410.
  • This message may be, for example, a message using IP communication, and more specifically, a message using COAP, MQTT, XMPP, or HTTP protocol.
  • the transmission code or cause of the message may be, for example, GET.
  • the SCS 450 may compare the stored information and the destination address (IP address and port) or external ID of the received message to compare whether there is a user terminal 410 having a matching address or ID. If there is a user terminal 410 having a matching address or ID, the SCS 450 transmits a response message instead of the user terminal 410 in response to the message for the user terminal 410 operating in the low power mode. It can be seen that it is necessary to do.
  • the SCS 450 may send a response message instead of the user terminal 410.
  • This response message may be, for example, a message using IP communication, and more specifically, a message using COAP, MQTT, XMPP or HTTP protocol.
  • the transmission code or cause of the message may be, for example, 200 OK.
  • the message may include a message that the user terminal 410 has requested to transmit instead.
  • the sender address or external ID of the message may be set to the address or external ID of the user terminal 410 that is not the SCS 450. If the protocol of the message transmitted by the user terminal 410 and the protocol used by the server are different from each other, for example, when the user terminal 410 uses the CoAP protocol and the server uses the HTTP protocol, the SCS ( 450 may perform a protocol conversion.
  • the user terminal 410 operates in a low power mode in the already attached state, that is, the TA update process is performed.
  • operations of the user terminal 410 and the network are performed by the user. It may also be applied when the attach process for the terminal 410 is performed. If the above embodiment is applied during the attach process, the TA update request message may be replaced by an attach request message and a TAU accept message by an attach accept message.
  • FIG. 5 is a diagram illustrating another example of a flowchart of an operation of a communication system for transmitting a message for a user terminal in a low power mode according to an embodiment of the present invention.
  • the user terminal 510 may decide to change the state to a power save mode (PSM) according to a terminal state, a request of a service application, and setting information.
  • PSM power save mode
  • the user terminal 510 may transmit a TA update request message to the MME 520 in step 513 to request the use of the low power state.
  • the TA update request message transmitted from the user terminal 510 to the MME 4520 may include at least one of a periodic TAU timer, an active timer, and an active flag if necessary. If there is a message to be sent before the user terminal 510 enters a low power state, the user terminal 510 may send a TA update message by setting an active flag.
  • the user terminal 510 may explicitly include information for requesting the use of a function of performing a message transmission in a network instead of the user terminal 510 in the TA update request message.
  • the user terminal 510 may include information indicating characteristics of the terminal that is not sensitive to low priority or transmission delay in the TA update request message.
  • the MME 520 may determine whether to use the low power mode and an application parameter (periodic TAU timer, active timer) according to the TA update request of the user terminal 510.
  • the MME 520 may include the information in a TA update accept message transmitted to the user terminal 510.
  • the MME 520 may request a user terminal 510 (for example, information indicating characteristics of a terminal that is not sensitive to low priority or transmission delay), characteristics of a PDN connection that the user terminal 510 has (APN, ARP). Etc.), internal settings, and subscription information may determine whether to apply a function for transmitting a message in the network instead of the user terminal 510.
  • the MME 520 may explicitly include the result in the TA update accept and transmit the result to the user terminal 510.
  • the user terminal 510 may obtain a parameter from the TA update accept message received from the MME 520, and apply the parameter to enter the low power mode.
  • the user terminal 510 may start the active timer and wait without changing the state to the low power mode until the active timer expires.
  • the MME 520 may notify the HSS or the IWF 530 that the user terminal 510 has been switched to the low power mode.
  • the MME 520 may deliver the HSS or the IWF 530 together with at least one of an identifier of the user terminal 510, an IP address, duration information of a low power mode, and an active timer.
  • the HSS or IWF 530 stores the information received from the MME 520, and then whenever the information about the user terminal 510 is requested from the SCS 550, or the state of the user terminal 510 is changed. At least one of the stored information may be transmitted to the SCS 550.
  • the HSS or IWF 530 may transmit a message for notifying the SCS 550 of the state information of the user terminal 510.
  • the state information of the user terminal 510 is transmitted to the SCS 550 in that the state of the user terminal 510 is changed to a low power mode or the state of the user terminal 510 that is in a low power state is different. It can be done when the state is changed.
  • the HSS or IWF 530 sends an external ID of the user terminal 510, an IP address of the user terminal 510, and a current state of the user terminal 510 in the status information message of the user terminal 510 sent to the SCS 550.
  • the message may include information indicating that a function of transmitting a message on behalf of the user terminal 510 should be applied during the low power mode of the user terminal 510.
  • the message may include an active timer. If the message includes an active timer, the SCS 550 starts the active timer upon receiving the message, and transmits the message instead of the user terminal 510 from the moment when the active timer expires. Applicable Receiving this message, the SCS 550 stores the information, and can determine the current state and the low power state of the user terminal 510 according to the information.
  • the HSS or IWF 530 may utilize the RAT information that the user terminal 510 is connected to determine whether to perform the operation (that is, the message proxy function). In particular, the HSS or IWF 530 may request the function only when the user terminal 510 is using a specific RAT, for example, a low transmission rate GERAN. In addition, the HSS or IWF 530 may convert the protocol according to the type of RAT that the user terminal 510 is accessing (that is, convert the message transmitted by the user terminal 510 to CoAP into an HTTP message, or the user terminal 510). You can also decide whether to request the application of the protocol).
  • the user terminal 510 may determine whether a function for replacing the data in the network is required when the server (or the external network) requests data transmission during its low power mode operation. This may be based on internal configuration information of the user terminal 510 or information included in the attach accept message received before or before the TA update accept (for example, instead of the user terminal 510, message transmission may be performed in a network. Or support for the function to perform).
  • the user terminal 510 may transmit the message to the SCS 550 before the active timer expires in step 583.
  • the message may be, for example, a message using IP communication, and more specifically, a message using COAP, MQTT, XMPP, or HTTP protocol.
  • the transmission code or cause of the message may be, for example, POST.
  • the message may include one or more of information requesting a transmission operation instead of the user terminal 510, a message to be actually transmitted, and an external ID of the user terminal 510.
  • the message may be delivered to the SCS 550 via the PGW 540 (step 585).
  • the destination address of the message may be set to the address of the SCS 550 received in advance.
  • the SCS 550 may receive a message from the user terminal 510 in step 583 (and step 585).
  • the SCS 550 may know that the message transmission operation should be performed instead of the user terminal 510 according to the message received in the previous step.
  • the SCS 550 may include a source address (Source IP address), a port, a real destination address (destination IP address), and a message from a message sent by the user terminal 510 to distinguish the user terminal 510 and the real server. You can save the port.
  • the SCS 550 may store it.
  • the SCS 550 may utilize the RAT information that the user terminal 510 is connected to determine whether to perform the operation.
  • the SCS 550 may apply the function only when the user terminal 510 is using a specific RAT, for example, a low transmission rate GERAN.
  • the SCS 550 converts the protocol according to the type of the RAT to which the user terminal 510 is connected (that is, converts the message transmitted from the user terminal 510 to the CoAP into an HTTP message, or sends it to the user terminal 510). You can also decide whether to apply the protocol of the message to be sent from HTTP to CoAP).
  • the SCS 550 may transmit a message indicating that the message has been received to the user terminal 510.
  • This message may use the same protocol as the message transmitted by the user terminal 510, and the transmission code or cause may be set to 200 OK, for example.
  • the message may be transmitted to the user terminal 510 via the PGW 540 (step 589).
  • the SCS 550 may determine whether to perform an operation of transmitting a message on behalf of the user terminal 510 according to the state information of the user terminal 510 received in step 581 from the HSS or IWF 530. have. If the message received from the HSS or IWF 530 includes information on the time when the user terminal 510 operates in the low power mode, the SCS 550 starts the timer according to the time, and the timer expires. Until a message is transmitted instead of the user terminal 510.
  • the user terminal starts to operate in the low power mode in step 591.
  • the SCS 550 may receive a message from the server requesting message transmission to the user terminal 510.
  • This message may be, for example, a message using IP communication, and more specifically, a message using COAP, MQTT, XMPP, or HTTP protocol.
  • the transmission code or cause of the message may be, for example, GET.
  • the SCS 550 may compare the stored information and the destination address (IP address and port) or external ID of the received message to compare whether there is a user terminal 510 having a matching address or ID. If there is a user terminal 510 having a matching address or ID, the SCS 550 transmits a response message for the user terminal 510 operating in the low power mode instead of the user terminal 510. It can be seen that it is necessary to do.
  • the SCS 550 may send a response message instead of the user terminal 510.
  • This response message may be, for example, a message using IP communication, and more specifically, a message using COAP, MQTT, XMPP or HTTP protocol.
  • the transmission code or cause of the message may be, for example, 200 OK.
  • the message may include a message that the user terminal 510 has requested to transmit instead.
  • the sender address or external ID of the message may be set to the address or external ID of the user terminal 510 rather than the SCS 550. If the protocol of the message transmitted by the user terminal 510 and the protocol used by the server are different from each other, for example, when the user terminal 510 uses the CoAP protocol and the server uses the HTTP protocol, the SCS ( 550 may perform protocol conversion.
  • the user terminal 510 operates in the low power mode in the already attached state, that is, the TA update process is performed.
  • the operation of the user terminal 510 and the network is performed by the user. It may also be applied when the attach process for the terminal 510 is performed. If the above embodiment is applied during the attach process, the TA update request message may be replaced by an attach request message and a TAU accept message by an attach accept message.
  • FIG. 6 is a diagram illustrating an example of a flowchart of operations of a user terminal and a network according to an exemplary embodiment.
  • the user terminal 610 may decide to change the state to a power save mode (PSM) according to a terminal state, a request of a service application, and setting information.
  • PSM power save mode
  • the user terminal 610 may transmit a TA update request message to the MME 620 in step 673 to request the use of the low power state.
  • the TA update request message transmitted by the user terminal 610 to the MME 620 may include at least one of a periodic TAU timer, an active timer, and, if necessary, an active flag. If there is a message to be sent before the user terminal 610 enters the low power state, the user terminal 610 may send a TA update message by setting an active flag.
  • the user terminal 610 may explicitly include information for requesting a service for temporarily receiving and buffering a message instead of the user terminal 610 in the TA update request message.
  • the user terminal 610 may transmit information indicating the characteristics of the terminal that is not sensitive to low priority or transmission delay in the TA update request message.
  • the MME 620 may determine whether to use the low power mode and an application parameter (Periodic TAU timer, active timer) according to the TA update request of the user terminal 610.
  • the MME 620 may include the information in a TA update accept message transmitted to the user terminal 610.
  • the MME 620 may request a user terminal 610 (for example, information indicating characteristics of a terminal that is not sensitive to low priority or transmission delay), characteristics of a PDN connection of the user terminal 610 (APN, ARP). Etc.), internal settings, and subscription information may determine whether to apply a function of receiving and storing a message instead of the user terminal 610 in the network during the low power mode of the user terminal 610.
  • the MME 620 may explicitly include the result in the TA update accept and transmit the result to the user terminal 610.
  • the user terminal 610 may obtain a parameter from the TA update accept message received from the MME 620, and apply the parameter to perform the operation for entering the low power mode.
  • the user terminal 610 may start the active timer and wait without changing the state to the low power mode until the active timer expires.
  • the MME 620 may notify the HSS or the IWF 630 by transmitting a message that the user terminal 610 has been switched to the low power mode.
  • the MME 620 may deliver the HSS or the IWF 630 together with at least one of the identifier of the user terminal 610, the IP address, and the duration information of the low power mode.
  • the message may also include an active timer.
  • the message may include information indicating that a function of receiving and storing a message instead of the user terminal 610 should be applied.
  • the HSS or IWF 630 stores the information received from the MME 620, and then whenever the SCS 650 requests information about the user terminal 610, or whenever the state of the user terminal 610 changes, One or more of the stored information may be delivered to the SCS 650.
  • the HSS or IWF 630 may transmit a message for notifying the SCS 650 of status information of the user terminal 610.
  • the state information of the user terminal 610 is transmitted to the SCS 650 according to an embodiment of the present invention, in which the state of the user terminal 610 is changed to the low power mode or the state of the user terminal 610 in the low power state is different. It can be done when the state is changed.
  • the HSS or IWF 630 may indicate an external ID of the user terminal 610, an IP address of the user terminal 610, and a current state of the user terminal 610 in the status information message of the user terminal 610 sent to the SCS 650.
  • the message may include information indicating that a function of receiving and storing a message instead of the user terminal 610 should be applied.
  • the SCS 650 stores the information and can determine the current state and the low power state of the user terminal 610 according to the information.
  • the HSS or IWF 630 may utilize the RAT information that the user terminal 610 is connected to determine whether to perform the operation (that is, the message buffering function). In particular, the HSS or IWF 630 may request the function only when the user terminal 610 is using a specific RAT, for example, a low transmission rate GERAN. In addition, the HSS or IWF 630 may convert the protocol according to the type of RAT to which the user terminal 610 is connected (that is, convert the message transmitted from the user terminal 610 to CoAP into an HTTP message, or the user terminal 610 You can also decide whether to request to apply the protocol of the message to be sent).
  • the SCS 650 may start applying a function of receiving a message instead of the user terminal 610. If the user terminal 610 state information control message received by the SCS 650 includes an active timer, the SCS 650 starts a timer when the state information control message is received, so that the timer expires ( The function can be applied from the moment when it expires. On the other hand, the SCS 650 may utilize the RAT information that the user terminal 610 is connected to determine whether to perform the operation. In particular, the SCS 650 may apply the function only when the user terminal 610 is using a specific RAT, for example, a low transmission rate GERAN.
  • a specific RAT for example, a low transmission rate GERAN.
  • the SCS 650 converts the protocol according to the type of RAT to which the user terminal 610 is connected (that is, converts the message transmitted from the user terminal 610 to the CoAP into an HTTP message, or sends the message to the user terminal 610). You can decide whether to apply the protocol of the message to be sent from HTTP to CoAP).
  • the SCS 650 may receive a message directed to the user terminal 610 from the server 660 in operation 683.
  • the message may be, for example, a message using IP communication, and more specifically, a message using COAP, MQTT, XMPP, or HTTP protocol.
  • the transmission code or cause of the message may be, for example, POST or PUT.
  • the destination address of the message may be an address (or an external ID) of the user terminal 610.
  • the SCS 650 may know that the message reception operation should be performed instead of the user terminal 610 according to the information received and stored in the previous step. That is, the SCS 650 may check whether the destination address or the external ID of the received message is that of the user terminal 610 to which the message receiving function should be applied. If a message receiving function is needed instead of the user terminal 610, the SCS 650 may store the received message in step 685. Meanwhile, according to an embodiment, if the protocol used by the user terminal 610 for transmitting and receiving a message and the protocol used by the server are different from each other, for example, the user terminal 610 uses the CoAP protocol and the server uses the HTTP protocol. When using the SCS 650 may perform a protocol conversion.
  • the SCS 650 may transmit a message indicating that the message has been received to the server 660 in step 687.
  • This message may use the same protocol as the message sent by the previous server 660, and the transmission code or cause may be set to 200 OK, for example.
  • the sender address (or external ID) of the response message may be set to the IP address (or external ID) of the user terminal 610 that is not the SCS 650.
  • the user terminal 610 may start operating in the low power mode in step 688.
  • the user terminal 610 may switch to a state capable of transmitting and receiving data in the low power mode. This state transition may be, for example, to perform a TA update process after the periodic TAU timer expires.
  • the user terminal 610 may transmit a TA update or service request message to the MME 620.
  • the MME 620 may inform the HSS or IWF 630 that the state of the user terminal 610 has been switched to a mode capable of transmitting and receiving data in the low power mode.
  • the HSS or IWF 630 may transmit a message for notifying the SCS 650 of the state information of the user terminal 610 in step 695.
  • the state information of the user terminal 610 is transmitted to the SCS 650 in which the state of the user terminal 610 is changed to the low power mode, or the state of the user terminal 610 which was in the low power state is changed to another state. Can be done when.
  • the HSS or IWF 630 may indicate an external ID of the user terminal 610, an IP address of the user terminal 610, and a current state of the user terminal 610 in the status information message of the user terminal 610 sent to the SCS 650. At least one of information about a low power mode or not).
  • the message may include information indicating that messages that have been received instead of the user terminal 610 should be delivered to the user terminal 610.
  • step 697 the SCS 650 recognizes that the state of the user terminal 610 has changed according to the received message, and starts transmitting the stored message to the user terminal 610. If the protocol used by the user terminal 610 for transmitting and receiving a message and the protocol used by the server are different from each other, for example, the user terminal 610 uses the CoAP protocol and the server uses the HTTP protocol. 650 may perform a protocol conversion.
  • the message sent by the SCS 650 may be, for example, a message using IP communication, and more specifically, a message using COAP, MQTT, XMPP, or HTTP protocol.
  • the transmission code or cause of the message may be, for example, POST or PUT.
  • the recipient / destination address (IP address or external ID) of the message transmitted to the user terminal 610 by the SCS 650 is set to the user terminal 610, and the originating address is set to that of the SCS 650. Can be.
  • the user terminal 610 may send a response message to the SCS 650.
  • This response message is a message using IP communication, and more specifically, a message using a COAP, MQTT, XMPP or HTTP protocol.
  • the transmission code or cause of the message may be, for example, 200 OK.
  • the SCS 650 may process the response message on its own without transferring the response message back to the actual server (which sent the message) 660 in step 699.
  • the user terminal 610 operates in a low power mode in a state where it is already attached, that is, based on performing a TA update process.
  • operations of the user terminal 610 and the network are performed by the user. It may also be applied when the attach process for the terminal 610 is performed. If the above embodiment is applied during the attach process, the TA update request message may be replaced by an attach request message and a TAU accept message by an attach accept message.
  • FIG. 7 is a diagram illustrating another example of a flowchart of an operation of receiving and processing a message on behalf of a user terminal according to an embodiment of the present invention.
  • the user terminal 710 may decide to change the state to a power save mode (PSM) according to a terminal state, a request of a service application, and setting information.
  • PSM power save mode
  • the user terminal 710 may transmit a TA update request message to the MME 720 in step 773 to request the use of the low power state.
  • the TA update request message transmitted from the user terminal 710 to the MME 720 may include at least one of a periodic TAU timer, an active timer, and, if necessary, an active flag. If there is a message to be sent before the user terminal 710 enters the low power state, the user terminal 710 may send a TA update message by setting an active flag.
  • the user terminal 710 may explicitly include information for requesting a service for temporarily receiving and buffering a message instead of the user terminal 710 in the TA update request message.
  • the user terminal 710 may include information indicating the characteristics of the terminal that is not sensitive to low priority or transmission delay in the TA update request message.
  • the MME 720 may determine whether to use the low power mode and an application parameter (Periodic TAU timer, active timer) according to the TA update request of the user terminal 710.
  • the MME 720 may include the information in a TA update accept message transmitted to the user terminal 710.
  • the MME 720 may request a user terminal 710 (for example, information indicating characteristics of a terminal that is not sensitive to low priority or transmission delay) and characteristics of a PDN connection (APN, ARP) of the user terminal 710. Etc.), internal settings, and subscription information, the user terminal 710 may determine whether to apply a function of receiving and storing a message instead of the user terminal 710 in the network during the low power mode.
  • the MME 620 may explicitly include the result in the TA update accept and deliver the result to the user terminal 710.
  • the user terminal 710 may obtain a parameter from the TA update accept message received from the MME 720, and apply the parameter to perform the operation for entering the low power mode.
  • the user terminal 710 may start the active timer and wait without changing the state to the low power mode until the active timer expires.
  • an S1 or UE context release process may be performed between the base station 750 and the MME 720 for the user terminal 710 in the low power mode.
  • the MME 720 may notify the SGW 730 of the state change of the user terminal 710 and transmit a message for releasing the radio bearer, for example, a Release Access Bearers Request message.
  • This message includes information indicating that the user terminal 710 operates in a low power state, a time when the user terminal 710 operates in a low power mode, a RAT to which the user terminal 710 is connected, and a user terminal (for a relatively long time).
  • 710 may include information indicating that an operation for receiving and buffering a message is needed.
  • the MME 720 may utilize the RAT information that the user terminal 710 is accessing to determine whether to request a message storage function.
  • the MME 720 may request the function only when the user terminal 710 is using a specific RAT, for example, a low transmission rate GERAN.
  • the SGW 730 may apply an operation of receiving and storing a message for a relatively long time with respect to the user terminal 710. If the message received in step 780 includes the time that the user terminal 710 operates in the low power mode, the SGW 730 starts a timer upon receiving the message, so that the timer expires (ie, the low power mode). The operation may be applied until the operation time is reached). On the other hand, the SGW 730 may utilize the RAT information that the user terminal 710 is connected to determine whether to perform the operation. In particular, the SGW 730 may apply the function only when the user terminal 710 is using a specific RAT, for example, a low transmission rate GERAN.
  • a specific RAT for example, a low transmission rate GERAN.
  • the SGW 730 may convert the protocol according to the type of the RAT to which the user terminal 710 is connected (that is, convert the message transmitted from the user terminal 710 to the CoAP into an HTTP message or transmit the message to the user terminal 710). You can also decide whether to apply the protocol of the message to be sent from HTTP to CoAP).
  • the SGW 730 may receive a message directed to the user terminal 710 from the server.
  • the message may be included in a packet received from the PGW 740 through a GTP-U or GRE tunnel, and may be, for example, a message using IP communication, and more specifically, a COAP, MQTT, XMPP or HTTP protocol. It may be a message to use.
  • the transmission code or cause of the message may be, for example, POST or PUT.
  • the destination address of the message may be an address (or an external ID) of the user terminal 710.
  • the user terminal 710 starts to operate in the low power mode in step 778.
  • the user terminal 710 may switch to a state capable of transmitting and receiving data in the low power mode.
  • This state transition may be, for example, to perform a TA update process after the periodic TAU timer expires.
  • the user terminal 710 may deliver a TA update or service request message to the MME 720. If message transmission and reception is necessary, the user terminal 710 may transmit the TA update request message by including an active flag.
  • step 789 when the user terminal 710 is changed to a state capable of transmitting and receiving general data in the low power mode, the MME 720 checks whether there is a message received for the user terminal in the SGW 730 and is waiting to be transmitted. Can be performed. This is performed only when the active flag is not set in the TA update request message transmitted by the user terminal 710 according to an embodiment, or the SGW 730 is received by the MME 720 with respect to the user terminal 710. It may be based on receiving a message indicating that there is a message, that is, receiving a Downlink Data Notification message.
  • the MME 720 transmits a modify bearer request message to the SGW 730, and the message may include information on whether there is a message received and stored for the user terminal 710.
  • the SGW 730 may transmit a response message, for example, a modify bearer response message, to the MME 720 in step 791.
  • the message may include information indicating whether there is a message received and stored for the user terminal 710.
  • the MME 720 or the base station 750 in step 794 transmits a TA update accept message to the user terminal 710, there is a pending message for the user terminal 710 May contain information that indicates.
  • the MME 720 sets the UE context and radio bearer in the same manner as the user terminal 710 sets the active flag. This may be done.
  • the user terminal 710 may additionally perform a service request process.
  • the user terminal 710 enters a connected mode.
  • the SGW 730 may transmit a stored message to the user terminal 710.
  • the user terminal 710 operates in a low power mode in the already attached state, that is, the TA update process is performed.
  • operations of the user terminal 710 and the network are performed by the user. It may also be applied when the attach process for the terminal is performed. If the above embodiment is applied during the attach process, the TA update request message may be replaced by an attach request message and a TAU accept message by an attach accept message.
  • FIG. 8 illustrates another example of a flowchart of a method of receiving a message when a user terminal uses a low power mode according to an embodiment of the present invention.
  • the user terminal 810 may enter a low power mode in step 870.
  • This process may be performed using the steps included in the embodiment described in the above-described parts related to FIGS. 3 to 7 of the present invention. Meanwhile, during this process, the SGW 830 learns that the user terminal 810 is in an idle mode.
  • the PGW 840 may deliver it to the SGW 830 in step 871.
  • the SGW 830 may transmit a downlink data notification message to the MME 820 in step 872.
  • the MME 820 receiving the downlink data notification message from the SGW 830 may confirm that the user terminal 810 is in the low power mode in step 873.
  • the MME 820 may determine whether to apply a function of receiving and storing a message for a relatively long time for the user terminal 810 while the user terminal 810 is in a low power mode.
  • the MME 820 may transmit a response message to the SGW 830, for example, a downlink data notification ack.
  • the message includes information indicating that the user terminal 810 operates in a low power mode, a time when the user terminal 810 operates in a low power mode, a RAT to which the user terminal 810 is connected, and a user terminal 810.
  • the MME 820 may utilize the RAT information that the user terminal 810 is connected to determine whether to request the message storage function.
  • the MME 820 may request the function only when the user terminal 810 is using a specific RAT, for example, a low rate GERAN.
  • the SGW 830 may apply an operation of receiving and storing a message for the user terminal 810 for a relatively long time. If the message received in step 875 includes a time during which the user terminal 810 operates in the low power mode, the SGW 830 starts a timer upon receiving the message, so that the timer expires (ie, the low power mode). The operation may be applied until the operation time is reached). Meanwhile, the SGW 830 may use the RAT information to which the user terminal 810 is connected to determine whether to perform the operation. In particular, the SGW 830 may apply the function only when the user terminal 810 is using a specific RAT, for example, a low transmission rate GERAN.
  • a specific RAT for example, a low transmission rate GERAN.
  • the SGW 830 converts the protocol according to the type of RAT to which the user terminal 810 is connected (that is, converts the message transmitted from the user terminal 810 to the CoAP into an HTTP message, or sends the message to the user terminal 810). You can also decide whether to apply the protocol of the message to be sent from HTTP to CoAP).
  • the SGW 830 may receive a message directed to the user terminal from the server.
  • the message may be included in a packet received from the PGW 840 through a GTP-U or GRE tunnel, and may be, for example, a message using IP communication, and more specifically, a COAP, MQTT, XMPP or HTTP protocol. It may be a message to use.
  • the transmission code or cause of the message may be, for example, POST or PUT.
  • the destination address of the message may be an address (or an external ID) of the user terminal 810.
  • the user terminal 810 starts to operate in the low power mode.
  • the user terminal 810 may switch to a state capable of transmitting and receiving data in the low power mode.
  • This state transition may be, for example, to perform a TA update process after the periodic TAU timer expires.
  • the user terminal 810 may deliver a TA update or service request message to the MME 820. If message transmission / reception is required, the user terminal 810 may transmit the TA update request message by including an active flag.
  • step 884 when the user terminal 810 is changed to a state capable of transmitting and receiving general data in the low power mode, the MME 820 checks whether there is a message received for the user terminal in the SGW 830 and is waiting to be transmitted. Can be performed. This is performed only when the active flag is not set in the TA update request message transmitted by the user terminal 810 according to an embodiment, or the SGW 830 is received by the MME 820 with respect to the user terminal 810. It may be based on receiving a message indicating that there is a message, that is, receiving a Downlink Data Notification message.
  • the MME 820 transmits a modify bearer request message to the SGW 830, and the message may include information on whether there is a message received and stored for the user terminal 810.
  • the SGW 830 may transmit a response message, for example, a modify bearer response message, to the MME 820 in response to the modify bearer request message in step 885.
  • the message may include information indicating whether there is a message received and stored for the user terminal 810.
  • the MME 820 or the base station 850 transmits a TA update accept message to the user terminal 810 in step 887 that there is a pending message for the user terminal 810. May contain information that indicates.
  • the MME 820 sets a UE context and a radio bearer in the same manner as the user terminal 810 sets the active flag. This may be done.
  • the user terminal 810 may additionally perform a service request process.
  • step 888 the user terminal 810 enters the connected mode, and in step 889, the SGW 830 may transmit the stored message to the user terminal 810.
  • the user terminal 810 operates in a low power mode in a state where it is already attached, that is, based on performing a TA update process.
  • operations of the user terminal 810 and the network are performed by the user. It may also be applied when the attach process for the terminal is performed. If the above embodiment is applied during the attach process, the TA update request message may be replaced by an attach request message and a TAU accept message by an attach accept message.
  • the network NAT may release or retrieve IP address information allocated to the user terminal.
  • the message cannot be delivered to the user terminal in the low power mode, and the IP address is reset when the user terminal changes from the low power mode to the non-low power mode. You will need to register.
  • a node of the network for example, an SCS instead of the user terminal periodically transmits a message, for example, a keep-alive message, instead of the user terminal, thereby saving a low power mode. Let's look at how to ensure that the IP address for the user terminal to continue to operate.
  • FIG. 9 is a diagram illustrating an example of a flowchart of an operation for maintaining a connection state to a user terminal according to an embodiment of the present invention.
  • the user terminal 910 may decide to change a state to a power save mode (PSM) according to a terminal state, a request of a service application, configuration information, and the like.
  • PSM power save mode
  • the user terminal 910 may transmit a TA update request message to the MME 920 in step 973 to request the use of the low power state.
  • the TA update request message transmitted from the user terminal 910 to the MME 920 may include at least one of a periodic TAU timer, an active timer, and, if necessary, an active flag. If there is a message to be sent before the user terminal 910 enters the low power state, the user terminal 910 may send a TA update message by setting an active flag.
  • the user terminal 910 may explicitly include information requesting the use of a function of performing a message transmission for maintaining an IP address in a network instead of the user terminal 910 in the TA update request message. have.
  • the user terminal 910 may include information indicating the characteristics of the terminal that is not sensitive to low priority or transmission delay in the TA update request message.
  • the MME 920 may determine whether to use the low power mode and an application parameter (periodic TAU timer, active timer) according to the TA update request of the user terminal 910.
  • the MME 920 may include the information in a TA update accept message transmitted to the user terminal 910.
  • the MME 920 may request the user terminal 910 (for example, information indicating characteristics of a terminal that is not sensitive to low priority or transmission delay), characteristics of a PDN connection of the user terminal 910 (APN, ARP). Etc.), internal settings, and subscription information may determine whether to apply a function for transmitting a message for maintaining an IP address in a network instead of the user terminal 910.
  • the MME 920 may explicitly include the result in the TA update accept and transmit the result to the user terminal 910.
  • the user terminal 910 may obtain a parameter from the TA update accept message received from the MME 920, and apply the parameter to perform the operation for entering the low power mode.
  • the user terminal 910 may start the active timer and wait without changing the state to the low power mode until the active timer expires.
  • the MME 920 may notify the HSS or the IWF 930 that the user terminal 910 is switched to the low power mode.
  • the MME 920 may deliver the HSS or the IWF 930 together with at least one of an identifier of the user terminal 910, an IP address, duration information of a low power mode, and an active timer.
  • the HSS or IWF 930 stores the information received from the MME 920, and then whenever the SCS 940 requests information about the user terminal 910, or whenever the state of the user terminal 910 changes, One or more of the stored information may be delivered to the SCS 940.
  • the HSS or the IWF 930 may transmit a message for notifying the SCS 940 of the state information of the user terminal 910.
  • the state information of the user terminal 910 is transmitted to the SCS 940 according to an embodiment of the present invention, in which the state of the user terminal 910 is changed to the low power mode or the state of the user terminal 910 that is in the low power state is different. It can be done when the state is changed.
  • the HSS or IWF 930 may display an external ID of the user terminal 910, an IP address of the user terminal 910, and a current state of the user terminal 910 in the status information message of the user terminal 910 sent to the SCS 940.
  • the message may include information indicating that a function of transmitting a message for maintaining an IP address instead of the user terminal 910 should be applied during the low power mode of the user terminal 910.
  • the message may include an active timer. If the active timer is included, the SCS 940 may start the active timer when the message is received and apply the transmission function instead of the message from the moment when the active timer expires. Receiving this message, the SCS 940 stores the information and can determine the current state and the low power state of the user terminal 910 according to the information.
  • the user terminal 910 may determine whether a function for transmitting a keep-alive message is required in the network during its low power mode operation. This is based on internal configuration information of the user terminal 910 or information included in the attach accept message received before or before the TA update accept (eg, keep-alive in the network instead of the user terminal 910). Or whether there is support for a function for performing a message transmission). If the user terminal 910 is enabled, the user terminal 910 may transmit the message to the SCS 940 before the active timer expires in step 9841.
  • the message may be, for example, a message using IP communication, and more specifically, a message using TCP, COAP, MQTT, XMPP, or HTTP protocol.
  • the transmission code or cause of the message may be, for example, POST.
  • the message may include a TCP keep-alive message.
  • the message may include one or more of information requesting a transmission operation instead of the user terminal 910, a message to be actually transmitted, and an external ID of the user terminal 910.
  • the message may be delivered to the SCS 940 via the PGW.
  • the destination address of the message may be set to the address of the SCS 950 previously received.
  • the SCS 940 may receive a message from the user terminal 910.
  • the SCS 940 may know that the keep-alive message transmission operation should be performed instead of the user terminal 910 according to the message received in the previous step. Meanwhile, according to an embodiment, the SCS 940 may identify a source terminal (Source IP address), a port, and a real destination address (destination IP address) from a message sent by the user terminal 910 in order to distinguish the user terminal 910 from the actual server. And ports. When the user terminal 910 announces the external ID, the SCS 940 may store it.
  • Source IP address Source IP address
  • a port a port
  • destination IP address destination IP address
  • the SCS 940 may transmit a message indicating that the message has been received to the user terminal 910.
  • This message may use the same protocol as the message transmitted by the user terminal 910, and the transmission code or cause may be set to, for example, 200 OK.
  • the message may be transmitted to the user terminal 910 via a PGW.
  • the SCS 940 may determine whether to perform an operation of transmitting a message instead of the user terminal 910 according to the state information of the user terminal 910 received in step 979 from the HSS or IWF 930. If the message received from the HSS or IWF 930 includes a time for operating the user terminal 910 in the low power mode, the SCS 940 starts a timer according to the time, until the timer expires. An operation of transmitting a message instead of the user terminal 910 may be performed.
  • the user terminal 910 may start to operate in the low power mode in step 985.
  • the SCS 940 may periodically generate and transmit a keep-alive message for the user terminal 910 in steps 987 and 988.
  • This message may be, for example, a message using IP communication, and more specifically, a message using TCP, COAP, MQTT, XMPP or HTTP protocol.
  • the message transmitted at this time may be received from the user terminal 910 or may be generated directly by the SCS 940.
  • the sender address (IP address / port) or the external ID of the message may be set to the address or external ID of the user terminal 910 that is not the SCS 940.
  • the user terminal 910 is operated in a low power mode in the already attached state, that is, the TA update process is performed.
  • operations of the user terminal 910 and the network are performed by the user. It may also be applied when the attach process for the terminal 910 is performed. If the above embodiment is applied during the attach process, the TA update request message may be replaced by an attach request message and a TAU accept message by an attach accept message.
  • a node of the network for example, an SCS instead of the user terminal periodically transmits a message, for example, a keep-alive message, to the user terminal operating in the low power mode.
  • a message for example, a keep-alive message
  • the provider network determines whether the corresponding PDN connection is offloaded to a WLAN (WLAN) and informs the user terminal. Can be.
  • the user terminal may determine whether it is possible to offload the PDN connection to the WLAN according to the information received from the operator network.
  • FIG. 10 is a diagram illustrating an example of a flowchart of a method of notifying whether WLAN offloading is allowed when a user terminal changes a new location registration or RAT.
  • the user terminal 1010 may transmit a TA update (if E-UTRAN) or RA update (if UTRAN / GERAN) request message to the MME or SGSN 1020.
  • TA update if E-UTRAN
  • RA update if UTRAN / GERAN
  • the new MME or SGSN 1020 identifies the MME or SGSN 1025 in which the user terminal 1010 was originally registered, based on the user terminal 1010 identifier or the core network node identifier provided by the user terminal 1010, In step 1071, the node may transmit a message for requesting information about the user terminal 1010, for example, a context request message.
  • the old MME or SGSN 1025 may deliver a UE context for the user terminal 1010 to the new MME or SGSN 1020.
  • the message used at this time may be a context response message.
  • the context response message may include whether WLAN offloading is allowed for the PDN connection of the user terminal 1010, that is, WLAN offloadability may be transmitted.
  • the old MME or SGSN 1025 whether to allow / disallow WLAN offloading for the PDN connection (s) stored as one of the UE context or PDN context for the user terminal 1010, the new MME or The WLAN offloadability IE may be included in the PDN connection Information Element (IE) of the context response message sent to the SGSN 1020.
  • IE PDN connection Information Element
  • the context response message transmitted by the old MME or SGSN 1025 whether WLAN offloading is allowed for each APN (Access Point Name), as well as WLAN offloadability of a PDN connection already created between the user terminal 1010.
  • Information indicating whether or not may be additionally included and delivered to the new MME or SGSN 1020. In particular, the information may be part of a UE context or subscription data for the user terminal 1010.
  • the new MME or SGSN 1020 in step 1077, WLAN offloadability for the PDN connection that the user terminal 1010 currently has, and WLAN offloading for each APN. You can see whether it is allowed.
  • the new MME or SGSN 1010 may update this information according to its local configuration. If the information sent by the old MME or SGSN 1025 is different from the local configuration, the new MME or SGSN 1020 may update the WLAN offloadability of the user terminal 1010 by giving priority to its own setting. .
  • the new MME or SGSN 1020 may transmit a TA update or RA update accept message to the user terminal 1010.
  • This message may include updated WLAN offloadability information for the PDN connection (s) of the user terminal 1010.
  • the new MME or SGSN 1020 may include information on setting WLAN offloadability for each representative EPS bearer ID of the PDN connection in the TA update or RA update acceptance message to the user terminal 1010.
  • the user terminal 1010 that receives the TA update or RA update acceptance message from the new MME or SGSN 1020 should update the stored information according to the information if the updated WLAN offloadability information is included in the message.
  • the new MME or SGSN when a new MME or SGSN needs to update WLAN offloadability during the TA / RA update process, the new MME or SGSN does not notify the TA / RA update acceptance message, but initiates a separate Session Management (SM) process to notify the user terminal. It may be.
  • SM Session Management
  • FIG. 11 is a diagram illustrating another example of a flowchart of a process of performing WLAN offloadability update for a user terminal according to one embodiment of the present invention.
  • the user terminal 1110 may transmit a TA update (for E-UTRAN) or RA update (for UTRAN / GERAN) request message to the MME or SGSN 1120.
  • TA update for E-UTRAN
  • RA update for UTRAN / GERAN
  • the new MME or SGSN 1120 may determine the MME or SGSN 1125 to which the user terminal 1110 was originally registered, based on the user terminal identifier or the core network node identifier provided by the user terminal 1110. In operation 1173, the new MME or SGSN 1120 may transmit a message for requesting information about the user terminal 1110, for example, a context request message, to the node 1125.
  • the old MME or SGSN 1125 may transmit a UE context for the user terminal 1110 to the new MME or SGSN 1120.
  • the message used at this time may be a context response message.
  • the context response message may include whether WLAN offloading is allowed for the PDN connection of the user terminal 1110, that is, WLAN offloadability.
  • the new MME or SGSN 1125 whether to allow / disallow WLAN offloading for the PDN connection (s) that was stored as one of the UE context or PDN context for the user terminal 1110, the new MME or The WLAN offloadability IE may be included in the PDN connection Information Element (IE) of the context response message sent to the SGSN 1120.
  • IE PDN connection Information Element
  • APN Access Point Name
  • Information indicating whether or not may be additionally included and delivered to the new MME or SGSN 1120. In particular, the information may be part of the UE context or subscription data for the user terminal 1110.
  • the new MME or SGSN 1120 performs WLAN offloadability for the PDN connection that the user terminal 1110 currently has, and WLAN offloading for each APN. You can see whether it is allowed.
  • the new MME or SGSN 1120 may update this information according to its local configuration. If the information sent by the old MME or SGSN 1125 and its local configuration are different, the new MME or SGSN 1120 may update the WLAN offloadability of the user terminal 1110 by giving priority to its own setting. .
  • the new MME or SGSN 1120 may start a process for updating WLAN offloadability information for the user terminal 1110.
  • the new MME or SGSN 1120 may deliver a message for modifying bearer information for the user terminal 1110, for example, a modify bearer command message, to the SGW 1130.
  • the message may include WLAN offloadability information of a bearer that is a target for the user terminal 1110.
  • the WLAN offloadability information may be included as one of bearer contexts. If there are multiple PDN connections for the user terminal 1110 or two or more EPS bearers are included in one PDN connection, the new MME or SGSN 1120 is a representative bearer of the target PDN connection (ie, Default bearer information may be transmitted including the WLAN offloadability.
  • the SGW 1130 may deliver the information received from the new MME or SGSN 1120 to the PGW 1140.
  • a modify bearer command message may be used and may be transmitted to the PGW 1140 including the information received in step 1179.
  • the PGW 1140 transmits an Update Bearer Request message to the SGW 1130, which may include WLAN offloadability of the target PDN connection or EPS bearer.
  • the SGW 1130 may deliver the information to the new MME or SGSN 1120 using the same message.
  • the new MME or SGSN 1120 may transmit an SM message to the user terminal 1110 to update WLAN offloadability in step 1183.
  • This message may be a modify EPS bearer context request message or a modify PDP context request message, and this message may include WLAN offloadability of the target bearer.
  • the new MME or SGSN 1120 is a representative EPS bearer of the target PDN connection. In other words, the message is transmitted to the default bearer, and therefore, the message may include an identifier of the representative EPS bearer.
  • the WLAN offloadability information included in the message may be included in a new QoS IE or may be included in a separate WLAN offloadability IE.
  • the operation of the new MME or SGSN 1120 may be performed without signaling with the SGW 1130 / PGW 1140 (ie, steps X to X).
  • an SM message for example, an ESM status or ESM information message, to the user terminal 1110.
  • This message may include WLAN offloadability of the target bearer.
  • the new MME or SGSN is a representative EPS bearer of the target PDN connection (ie, The message is transmitted to the default bearer, and thus, the message may include an identifier of the representative EPS bearer.
  • the WLAN offloadability information included in the message may be included in a new QoS IE or may be included in a separate WLAN offloadability IE.
  • the new MME or SGSN may omit signaling with the SGW / PGW.
  • the user terminal 1110 that has received the SM message from the new MME or SGSN 1120, if the updated WLAN offloadability information is included in the message in step 185, must update the stored information according to this information.
  • WLAN offloading function or configuration may be different for each of the E-UTRAN and UTRAN.
  • the E-UTRAN supports the WLAN offloading function, but the UTRAN may not support the WLAN offloading function.
  • the PDN connection (or PDP context) of the user terminal WLAN offloadability needs to be updated.
  • the MME or SGSN should determine whether to apply ISR to the user terminal.
  • the MME may include information indicating whether WLAN offloading is supported in a context request / response / response ack message to the SGSN (or MME).
  • the SGSN (or MME) receiving the same may include information indicating whether WLAN offloading is supported in the own network in a context related message sent to the MME (or SGSN).
  • ISR can be activated only when the two networks support WLAN offloading.
  • a context exchange message is used to check whether two networks match WLAN offloading support. That is, in the above example, if the SGSN (or MME) receiving the context response message from the MME (or SGSN), whether the WLAN offloading function supported by the MME (or SGSN) indicated by the message supports the WLAN offloading function? ISR can only be applied if it matches, and the result determines whether the ISR supported / activated indicator is included in the context response ack message. If two networks cannot support whether WLAN offloading is different or the same, ISR cannot be activated for a user terminal.
  • FIG. 12 is a block diagram of an MME according to an embodiment of the present invention.
  • the MME may include a communication unit 1210 and a controller 1230 for controlling the overall operation of the MME.
  • the MME may further include a storage unit 1220.
  • the storage unit 1220 may store a program and data necessary for the operation of the MME.
  • the controller 1230 of the MME controls the MME to perform one of the above-described embodiments. For example, a low power mode request message is received from the user terminal, the low power mode request message including information requesting to perform a message transmission and reception at another network entity instead of the user terminal in the low power mode state of the user terminal, and the user terminal in a low power mode. Control whether or not to transmit whether to use and apply parameters, and to send to the Home Subscriber Server (HSS) the information requesting that other network entities transmit and receive messages in place of the user terminal in the low power mode of the user terminal. Can be.
  • HSS Home Subscriber Server
  • the communication unit 1210 may transmit and receive a signal according to any one of the above-described embodiments.
  • FIG. 13 is a block diagram of a user terminal according to an embodiment of the present invention.
  • the user terminal may include a communication unit 1310 and a controller 1330 for controlling the overall operation of the user terminal.
  • the user terminal may further include a storage unit 1320.
  • the storage unit 1320 may store programs and data necessary for the operation of the user terminal.
  • the controller 1330 of the user terminal controls the user terminal to perform any one of the above-described embodiments. For example, in a low power mode of the user terminal, a low power mode request message including information requesting to perform message transmission and reception at another network entity instead of the user terminal is transmitted to a mobility management entity (MME).
  • MME mobility management entity
  • the controller may receive whether to use the low power mode and application parameters from the MME, and control to operate in the low power mode according to the received parameter.
  • the communication unit 1310 may transmit and receive a signal according to any one of the above-described embodiments.
  • the user SCS may include a communication unit for transmitting and receiving a signal according to any one of the above embodiments and a control unit for controlling the overall operation of the SCS.
  • the SCS may further include a storage unit for storing a program, data, and the like, required for the operation of the SCS.
  • the base station may include a communication unit capable of transmitting and receiving a signal according to any one of the above-described embodiments and a control unit for controlling the overall operation of the base station.
  • the base station may further include a storage unit capable of storing programs and data necessary for the operation of the base station.
  • the other network entity may also include a control unit for controlling the overall operation of the network entity and a communication unit capable of communicating with other network entities.
  • the apparatus may further include a storage unit capable of storing a program and data necessary for its operation.
  • all steps and messages may be subject to selective execution or subject to omission.
  • the steps need not necessarily occur in order and may be reversed.
  • Message delivery doesn't necessarily have to happen in order, but can be reversed.
  • Each step and message can be performed independently.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

본 명세서의 실시 예는 무선 통신 시스템에서 각 노드 사이의 정보 교환을 효과적으로 하는 방법 및 장치에 관한 것으로, 본 발명의 일 실시 예에 따른 사용자 단말의 통신 방법은, 상기 사용자 단말의 저전력 모드 상태에서 상기 사용자 단말 대신 다른 네트워크 엔티티에서 메시지 송수신을 수행할 것을 요청하는 정보를 포함하는 저전력 모드 요청 메시지를 MME에게 전송하는 단계; 상기 MME로부터 저전력 모드 사용 여부 및 적용 파라메터를 수신하는 단계; 및 상기 수신한 파라메터에 따라 저전력 모드로 동작하는 단계;를 포함할 수 있다. 본 발명의 일 실시 예에 따르면, 저전력 모드로 동작하는 단말을 위한 정보 송신 방법이 제공될 수 있다.

Description

저전력 단말의 통신 효과를 높이는 방법 및 장치
본 명세서의 실시 예는 무선 통신 시스템에서 각 노드 사이의 정보 교환을 효과적으로 하는 방법 및 장치에 관한 것이다. 보다 구체적으로, 사업자 망을 통해 메시지를 송수신하는 단말이 저전력 상태로 동작할 때 통신 기능의 효과를 높이도록 제어하는 방법 및 장치에 관한 것이다.
일반적으로 무선 통신 시스템은 사용자의 활동성을 보장하면서 음성 서비스를 제공하기 위해 개발되었다. 그러나 무선 통신 시스템은 점차로 음성뿐 아니라 데이터 서비스까지 영역을 확장하고 있으며, 현재에는 고속의 데이터 서비스를 제공할 수 있는 정도까지 발전하였다. 그러나 현재 서비스가 제공되고 있는 무선 통신 시스템에서는 자원의 부족 현상 및 사용자들이 보다 고속의 서비스를 요구하므로, 보다 발전된 무선 통신 시스템이 요구되고 있다.
이러한 요구에 부응하여 무선 통신 시스템으로 3GPP(The 3rd Generation Partnership Project)에서 E-UTRAN/UTRAN/GERAN 등 다양한 RAN(Radio Access Network) 기반의 기술을 표준화하였다.
3GPP 표준 기반의 통신 시스템은 다양한 종류의 서비스 및 단말의 형태를 지원할 수 있다. 예를 들면, 스마트폰(smart phone)처럼 사람이 직접 사용하는 통신 단말뿐만 아니라, 사람의 개입이 적거나 아예 없는 사물 인터넷(IoT - Internet of Things) 단말의 통신도 지원할 수 있다. 또한, 음성, 멀티미디어 서비스로부터 시작해 단말을 관리(Device Management)하거나, 단말에게 특정 정보를 전달 또는 단말로부터 특정 정보를 수집하는 통신 서비스도 지원할 수 있다.
스마트폰(smart phone)이나 사물 인터넷(IoT - Internet of Things) 단말 모두 배터리를 가지고 동작하는 것이 일반적일 수 있다. 이러한 배터리를 사용하는 단말의 경우에, 전력 소모를 줄이기 위해 저전력 모드(power save mode)가 사용될 수 있다. 만약 단말이 저전력 모드로 동작할 때, 단말과 통신하는 노드, 예를 들면 서버에서 단말로부터 특정 정보를 수신해야 할 경우, 사용자 단말은 저전력 모드이므로 정보를 전송해 줄 수 없다. 때문에, 이와 같이 저전력 모드로 동작하는 단말을 위한 정보 송신 방법이 필요하다.
한편, 만약 사용자 단말이 저전력 모드로 동작하게 되면, 사용자 단말은 데이터를 수신할 수 없다. 이때, 저전력 모드로 동작하는 단말에 대해 단말과 통신하는 노드, 예를 들면 서버에서 데이터를 발생시켜 전송을 시도할 경우, 사용자 단말이 저전력 모드인 경우 전송이 실패하여 불필요한 전송 시도가 발생할 수 있다. 따라서, 저전력 모드로 동작하는 사용자 단말을 위한 메시지 수신 제어 방법이 필요하다.
한편, 사용자 단말이 장기간 저전력 모드에서 동작할 경우, 사용자 단말에 대한 데이터 송수신이 장기간 발생하지 않으므로, 사용자 단말에게 할당된 주소, 특히 외부 IP(Internet Protocol) 주소가 회수될 수 있다. 이 경우 사용자 단말과 데이터를 주고받는 노드, 예를 들면 서버는 사용자 단말의 주소 회수 여부를 알지 못하므로 데이터 송수신이 실패하고, 추가적인 재전송이 발생할 수 있다. 따라서, 저전력 모드로 동작하는 사용자 단말을 위해 주소를 유지하도록 제어하는 방법이 필요하다.
본 발명에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
상기의 기술적 과제를 달성하기 위한 본 발명의 일 실시예에 따른 이동 통신 시스템에서 사용자 단말의 통신 방법은, 상기 사용자 단말의 저전력 모드 상태에서 상기 사용자 단말 대신 다른 네트워크 엔티티에서 메시지 송수신을 수행할 것을 요청하는 정보를 포함하는 저전력 모드 요청 메시지를 이동성 관리 엔티티(MME: Mobility Management Entity)에게 전송하는 단계; 상기 MME로부터 저전력 모드 사용 여부 및 적용 파라메터를 수신하는 단계; 및 상기 수신한 파라메터에 따라 저전력 모드로 동작하는 단계;를 포함할 수 있다.
또한, 상기 저전력 모드 요청 메시지는 상기 사용자 단말이 저전력 상태에 머무르는 시간에 대한 정보, 액티브 타이머(active timer), 액트브 플래그에 대한 정보 중 적어도 하나를 포함할 수 있다.
또한, 상기 사용자 단말이 저전력 모드 상태 동안 상기 다른 네트워크 엔티티가 전송을 수행할 정보를 상기 다른 네트워크 엔티티에게 전송하는 단계;를 더 포함할 수 있다.
또한, 상기의 기술적 과제를 달성하기 위한 본 발명의 일 실시예에 따른 이동성 관리 엔티티(MME: Mobility Management Entity)의 통신 방법은, 사용자 단말로부터, 상기 사용자 단말의 저전력 모드 상태에서 상기 사용자 단말 대신 다른 네트워크 엔티티에서 메시지 송수신을 수행할 것을 요청하는 정보를 포함하는 저전력 모드 요청 메시지를 수신하는 단계; 상기 사용자 단말에게 저전력 모드 사용 여부 및 적용 파라메터를 송신하는 단계; 및 상기 사용자 단말의 저전력 모드 상태에서 상기 사용자 단말 대신 다른 네트워크 엔티티에서 메시지 송수신을 수행할 것을 요청하는 정보를 홈 가입자 서버(HSS: Home Subscriber Server)에게 전송하는 단계;를 포함할 수 있다.
또한, 상기의 기술적 과제를 달성하기 위한 본 발명의 일 실시예에 따른 서비스 능력 서버(SCS: Service Capability Server)의 통신 방법은, 사용자 단말로부터 상기 사용자 단말의 저전력 모드 상태에서 상기 사용자 단말 대신 메시지 송수신을 수행할 것을 요청하는 정보를 수신하는 단계; 및 사용자 단말의 저전력 모드 상태 동안 서버와 메시지 송수신을 수행하는 단계;를 포함할 수 있다.
또한, 상기 서버와 메시지 송수신을 수행하는 단계는, 메시지의 송신자 주소 또는 external ID를 상기 사용자 단말의 주소 또는 external ID로 설정하여 상기 서버에 메시지를 전송하는 단계;를 포함할 수 있다.
또한, 상기의 기술적 과제를 달성하기 위한 본 발명의 일 실시예에 따른 사용자 단말은, 다른 네트워크 엔티티와 신호를 송수신하는 통신부; 및 상기 사용자 단말의 저전력 모드 상태에서 상기 사용자 단말 대신 다른 네트워크 엔티티에서 메시지 송수신을 수행할 것을 요청하는 정보를 포함하는 저전력 모드 요청 메시지를 이동성 관리 엔티티(MME: Mobility Management Entity)에게 전송하고, 상기 MME로부터 저전력 모드 사용 여부 및 적용 파라메터를 수신하고, 상기 수신한 파라메터에 따라 저전력 모드로 동작하도록 제어하는 제어부;를 포함할 수 있다.
또한, 상기의 기술적 과제를 달성하기 위한 본 발명의 일 실시예에 따른 이동성 관리 엔티티(MME: Mobility Management Entity)는 다른 네트워크 엔티티와 신호를 송수신하는 통신부; 및 사용자 단말로부터, 상기 사용자 단말의 저전력 모드 상태에서 상기 사용자 단말 대신 다른 네트워크 엔티티에서 메시지 송수신을 수행할 것을 요청하는 정보를 포함하는 저전력 모드 요청 메시지를 수신하고, 상기 사용자 단말에게 저전력 모드 사용 여부 및 적용 파라메터를 송신하고, 상기 사용자 단말의 저전력 모드 상태에서 상기 사용자 단말 대신 다른 네트워크 엔티티에서 메시지 송수신을 수행할 것을 요청하는 정보를 홈 가입자 서버(HSS: Home Subscriber Server)에게 전송하도록 제어하는 제어부;를 포함할 수 있다.
또한, 상기의 기술적 과제를 달성하기 위한 본 발명의 일 실시예에 따른 서비스 능력 서버(SCS: Service Capability Server)는, 다른 네트워크 엔티티와 신호를 송수신하는 통신부; 및 사용자 단말로부터 상기 사용자 단말의 저전력 모드 상태에서 상기 사용자 단말 대신 메시지 송수신을 수행할 것을 요청하는 정보를 수신하고, 사용자 단말의 저전력 모드 상태 동안 서버와 메시지 송수신을 수행하도록 제어하는 제어부;를 포함할 수 있다.
본 발명의 일 실시 예에 따르면, 저전력 모드로 동작하는 단말을 위한 정보 송신 방법이 제공될 수 있다.
또한, 본 발명의 일 실시 예에 따르면 저전력 모드로 동작하는 사용자 단말을 위한 메시지 수신 제어 방법이 제공될 수 있다.
그리고, 본 발명의 일 실시 예에 따르면 저전력 모드로 동작하는 사용자 단말을 위해 주소를 유지하도록 제어하는 방법이 제공될 수 있다.
본 발명에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
또한, 그 외의 다양한 효과는 후술될 본 발명의 실시 예에 따른 상세한 설명에서 직접적 또는 암시적으로 개시될 것이다.
도 1은 본 발명의 일 실시 예에 따른 통신 시스템의 구조를 나타내는 도면이다.
도 2는 본 발명의 일 실시 예에 따른 사용자 단말과 네트워크 사이에서, SCS의 주소 정보를 교환하는 방법의 흐름도의 일 예를 나타내는 도면이다.
도 3은 본 발명의 일 실시 예에 따른 저전력 모드의 사용자 단말을 위해 메시지를 전송해주는 통신 시스템의 동작의 흐름도의 일 예를 나타내는 도면이다.
도 4는 본 발명의 일 실시 예에 따른 저전력 모드의 사용자 단말을 위해 메시지를 전송해주는 통신 시스템의 동작의 흐름도의 다른 일 예를 나타내는 도면이다.
도 5는 본 발명의 일 실시 예에 따른 저전력 모드의 사용자 단말을 위해 메시지를 전송해주는 통신 시스템의 동작의 흐름도의 또 다른 일 예를 나타내는 도면이다.
도 6은 본 발명의 일 실시 예에 따른 사용자 단말과 네트워크의 동작의 흐름도의 일 예를 나타내는 도면이다.
도 7은 본 발명의 일 실시예에 따른 사용자 단말 대신 메시지를 수신하여 처리하는 동작의 흐름도의 다른 일 예를 나타내는 도면이다.
도 8은 본 발명의 일 실시 예에 따른 사용자 단말이 저전력 모드를 사용할 때 메시지를 수신하는 방법의 흐름도의 또 다른 일 예를 나타내는 도면이다.
도 9는 본 발명의 일 실시예에 따른 사용자 단말에 대한 연결 상태를 유지하기 위한 동작의 흐름도의 일 예를 나타내는 도면이다.
도 10은 사용자 단말이 새로운 위치 등록 또는 RAT를 변경하였을 때, WLAN 오프로딩 허용 여부를 알리는 방법의 흐름도의 일 예를 나타낸 도면이다.
도 11은 본 발명의 일 실시 예에 따른 사용자 단말에 대해 WLAN offloadability 갱신을 수행하는 과정의 흐름도의 다른 일 예를 나타내는 도면이다.
도 12는 본 발명의 일 실시 예에 따른 MME의 블록 구성도이다.
도 13은 본 발명의 일 실시 예에 따른 사용자 단말의 블록 구성도이다.
이하, 본 발명의 실시 예를 첨부된 도면을 참조하여 상세하게 설명한다.
실시 예를 설명함에 있어서 본 발명이 속하는 기술 분야에 익히 알려져 있고 본 발명과 직접적으로 관련이 없는 기술 내용에 대해서는 설명을 생략한다. 이는 불필요한 설명을 생략함으로써 본 발명의 요지를 흐리지 않고 더욱 명확히 전달하기 위함이다. 그리고 후술되는 용어들은 본 발명에서의 기능을 고려하여 정의된 것으로서 이는 사용자 및 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.
마찬가지 이유로 첨부 도면에 있어서 일부 구성요소는 과장되거나 생략되거나 개략적으로 도시되었다. 또한, 각 구성요소의 크기는 실제 크기를 전적으로 반영하는 것이 아니다. 각 도면에서 동일한 또는 대응하는 구성요소에는 가능한 동일한 참조 번호를 부여하였다.
본 발명의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 발명은 이하에서 개시되는 실시 예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시 예들은 본 발명의 개시가 완전하도록 하고, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 발명은 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭할 수 있다.
이 때, 처리 흐름도 도면들의 각 블록과 흐름도 도면들의 조합들은 컴퓨터 프로그램 인스트럭션들에 의해 수행될 수 있음을 이해할 수 있을 것이다. 이들 컴퓨터 프로그램 인스트럭션들은 범용 컴퓨터, 특수용 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서에 탑재될 수 있으므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서를 통해 수행되는 그 인스트럭션들이 흐름도 블록(들)에서 설명된 기능들을 수행하는 수단을 생성하게 된다. 이들 컴퓨터 프로그램 인스트럭션들은 특정 방식으로 기능을 구현하기 위해 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 지향할 수 있는 컴퓨터 이용 가능 또는 컴퓨터 판독 가능 메모리에 저장되는 것도 가능하므로, 그 컴퓨터 이용가능 또는 컴퓨터 판독 가능 메모리에 저장된 인스트럭션들은 흐름도 블록(들)에서 설명된 기능을 수행하는 인스트럭션 수단을 내포하는 제조 품목을 생산하는 것도 가능하다. 컴퓨터 프로그램 인스트럭션들은 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에 탑재되는 것도 가능하므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에서 일련의 동작 단계들이 수행되어 컴퓨터로 실행되는 프로세스를 생성해서 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 수행하는 인스트럭션들은 흐름도 블록(들)에서 설명된 기능들을 실행하기 위한 단계들을 제공하는 것도 가능하다.
또한, 각 블록은 특정된 논리적 기능(들)을 실행하기 위한 하나 이상의 실행 가능한 인스트럭션들을 포함하는 모듈, 세그먼트 또는 코드의 일부를 나타낼 수 있다. 또, 몇 가지 대체 실행 예들에서는 블록들에서 언급된 기능들이 순서를 벗어나서 발생하는 것도 가능함을 주목해야 한다. 예컨대, 잇달아 도시되어 있는 두 개의 블록들은 사실 실질적으로 동시에 수행되는 것도 가능하고 또는 그 블록들이 때때로 해당하는 기능에 따라 역순으로 수행되는 것도 가능하다.
이 때, 본 실시 예에서 사용되는 '~부'라는 용어는 소프트웨어 또는 FPGA또는 ASIC과 같은 하드웨어 구성요소를 의미하며, '~부'는 어떤 역할들을 수행한다. 그렇지만 '~부'는 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. '~부'는 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 재생시키도록 구성될 수도 있다. 따라서, 일 예로서 '~부'는 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들, 및 변수들을 포함한다. 구성요소들과 '~부'들 안에서 제공되는 기능은 더 작은 수의 구성요소들 및 '~부'들로 결합되거나 추가적인 구성요소들과 '~부'들로 더 분리될 수 있다. 뿐만 아니라, 구성요소들 및 '~부'들은 디바이스 또는 보안 멀티미디어카드 내의 하나 또는 그 이상의 CPU들을 재생시키도록 구현될 수도 있다.
하기에서 본 발명의 실시 예들을 설명함에 있어 관련된 공지 기능 또는 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략할 것이다.
또한 본 발명의 실시 예들을 구체적으로 설명함에 있어서, 기본적인 3GPP(Third Generation Partnership Project) LTE 시스템을 주된 대상으로 할 것이지만, 본 발명의 실시 예들은 유사한 기술적 배경 및 시스템 형태를 가지는 여타의 통신/컴퓨터 시스템에도 본 발명의 범위를 크게 벗어나지 아니하는 범위에서 적용 가능하며, 이는 본 발명의 기술 분야에서 숙련된 기술적 지식을 가진 자의 판단으로 가능할 것이다.
예를 들면, LTE 시스템을 대상으로 한 본 기술은 유사한 시스템 구조를 갖는 UTRAN/GERAN 시스템에서도 적용될 수 있다. 이 경우 eNB(RAN 노드)는 RNC/BSC로 대치될 수 있으며, S-GW는 생략되거나 SGSN에 포함되고, P-GW는 GGSN에 대응될 수 있다. 또한, MME는 SGSN에 대응될 수 있다. 또한 LTE 시스템의 bearer개념은 UTRAN/GERAN 시스템의 PDP context에 대응될 수 있다.
한편, 본 발명의 실시 예들을 설명함에 있어서 주요한 대상 서비스를 메시지 서비스(Message)으로 가정할 것이지만, 본 발명의 실시 예들은 다른 통신 서비스, 예를 들면 IP 기반 데이터 통신 서비스나 SMS 등에도 본 발명의 범위를 크게 벗어나지 아니하는 범위에서 적용 가능하며, 이는 본 발명의 기술 분야에서 숙련된 기술적 지식을 가진 자의 판단으로 가능할 것이다. 따라서 본 발명의 실시 예에서 사용되는 메시지라는 용어는 데이터, 정보, 패킷 등으로 치환되어 적용될 수 있다.
도 1은 본 발명의 일 실시 예에 따른 통신 시스템의 구조를 나타내는 도면이다. 실시 예에 따라 상기 통신 시스템은 LTE를 기반으로 한 이동 통신 시스템일 수 있다.
도 1을 참조하면, 도시한 바와 같이 LTE 이동 통신 시스템의 무선 액세스 네트워크는 차세대 기지국(evolved Node B, EUTRAN, 이하 eNB 또는 Node B 또는 기지국과 혼용되어 사용될 수 있다)(130)과 이동성 관리 엔티티(MME: Mobility Management Entity)(150) 및 서빙 - 게이트웨이(S-GW: Serving - Gateway)(140)로 구성될 수 있다.
사용자 단말(User Equipment, 이하 UE 또는 단말과 혼용되어 사용될 수 있다)(100)은 eNB(130) 및 S-GW(140), 그리고 패킷 데이터 네트워크 - 게이트웨이(P-GW: PDN(Packet Data Network) - Gateway)(160)를 통해 외부 네트워크에 접속한다. 사용자 단말이 PGW를 통해 데이터를 송수신 하기 위해서는 PDN 연결(connection)을 생성해야 하며, 하나의 PDN connection은 하나 이상의 EPS 베어러(bearer)를 포함할 수 있다.
어플리케이션 서버(AS: Application Server)(110)는 사용자와 어플리케이션(application) 수준에서 어플리케이션 과 관련된 정보를 교환하는 장치이다. AS는 일반적인 서비스 모델에서 서버(server)로 불릴 수 있으며, 또한 AS는 어플리케이션 기능(AF: Application Function)과 동등한 장치일 수 있다.
한편, 도면에 나타나 있지는 않으나, 정책 및 과금 규칙 기능(PCRF: Policy and Charging Rules Function)(120)은 사용자의 QoS(Quality of Service)와 관련된 정책(policy)을 제어하는 장치이다. 그리고, 상기 정책에 해당하는 정책 및 과금 제어(PCC: Policy and Charging Control) 규칙(rule)은 P-GW(160)에게 전달되어 적용된다.
eNB(130)는 RAN(Radio Access Network) 노드로서 UTRAN(Universal Terrestrial Radio Access Network) 시스템의 RNC 그리고 GERAN(GSM EDGE Radio Access Network) 시스템의 BSC(Base Station Controller)에 대응된다. eNB(130)는 UE(100)와 무선 채널로 연결되며 기존 RNC/BSC와 유사한 역할을 수행한다.
LTE에서는 인터넷 프로토콜을 통한 VoIP(Voice over IP)와 같은 실시간 서비스를 비롯한 모든 사용자 트래픽이 공용 채널(shared channel)을 통해 서비스 되므로, UE(100)들의 상황 정보를 취합해서 스케줄링을 하는 장치가 필요하며 이를 eNB(130)가 담당한다.
S-GW(140)는 데이터 베어러를 제공하는 장치이며, MME(150)의 제어에 따라서 데이터 베어러를 생성하거나 제거한다.
MME(150)는 각 종 제어 기능을 담당하는 장치로 하나의 MME(150)는 다수의 기지국 들과 연결될 수 있다.
홈 가입자 서버(HSS: Home Subscriber Server)는 사용자에 대한 가입정보(Subscription data)를 저장하고 있는 노드이다.
서비스 능력 서버(SCS: Service Capability Server)(180)는 사업자 망과 AS 사이에 위치하는 노드로, AS가 사업자 망을 통해 사용자들에게 서비스를 제공할 때, 부가가치를 높일 수 있는 기능을 제공한다. 사물 인터넷(IoT: Internet of Things)(또는 MTC(Machine Type Communication)) 서비스에 적용되어 서비스 가치를 높이는 SCS는 IoT-SCS(또는 MTC-SCS)로 불릴 수 있다. 또한, 상기 엔터티는 사용자 단말 대신 메시지를 송수신하는 Proxy 기능을 제공할 수도 있으므로, SCS-Proxy라고 불릴 수 있다. 본 발명의 실시 예에서, 상기 명칭은 기능의 특성을 기반으로 설명의 편의를 위해 사용되는 것이며, 본 발명의 실시 예들의 주요한 요지는 특정 서비스(IoT나 MTC 등 통신 기능을 사용하는 서비스)에 특화되어 서비스에 도움을 주거나, 서비스의 질을 높이거나, 사업자의 설정에 따라 서비스를 제어하는 기능을 제공하는 모든 종류에 서버에 적용될 수 있음은 물론이다.
망 연동 장치(IWF: Inter-Working Function)(190)는 각 통신 노드/서버 사이에 위치하면서 프로토콜 변환이나 데이터 가공을 수행하는 장치이다. IoT(또는 MTC) 환경에 사용되는 IWF는 IoT-IWF(또는 MTC-IWF)로 불릴 수 있다.
네트워크 주소 변환(NAT: Network Address Translation)(195)은 사업자 내부 망과 사업자 외부 망 사이에서 IP 주소를 변환 또는 매핑해주는 역할을 수행하는 장치이다.
한편, 도면에는 생략되어 있으나, 통신 시스템의 구조에는 MSC(Mobile Switching Center)와 GMSC(Gateway Mobile Switching Center)가 포함될 수 있다. GMSC는 CS(Circuit Switched) 서비스, 예를 들면 음성 서비스나 SMS(Short Messaging Service)에 대한 사업자 망으로의 관문 역할을 하는 장치이다. 그리고 MSC는 CS 도메인에 대한 제어를 담당하는 장치이다.
이하에서 사용자 단말이 저전력 모드로 들어갔을 때 서버에서 사용자 단말의 정보(또는 메시지) 전송을 요청하는 경우, 사용자 단말 대신 다른 네트워크 엔티티(entity)가 상기 사용자 단말의 정보를 전달해 주어 단말의 저전력 모드를 유지할 수 있는 방법에 대하여 살펴보도록 한다.
도 2는 본 발명의 일 실시 예에 따른 사용자 단말과 네트워크 사이에서, SCS의 주소 정보를 교환하는 방법의 흐름도의 일 예를 나타내는 도면이다.
도 2를 참조하면, 271 단계에서 사용자 단말(210)은 MME(220)에게 PDN 연결을 생성하기 위한 메시지, 예를 들면 PDN 연결 요청(PDN connectivity request) 메시지를 전송할 수 있다. 만약 attach 과정 중이라면, 상기 메시지는 attach 메시지에 포함되어 전송될 수 있다. 상기 PDN 연결 생성 요청 메시지는, 엑세스 포인트 네임(APN: Access Point Name), 낮은 우선순위 또는 전송지연에 민감하지 않은 단말의 특성을 나타내는 정보, 그리고 SCS의 주소를 요청하는 정보 중 하나 이상이 포함될 수 있다. 실시 예에 따라, 상기 SCS 주소를 요청하는 정보는 프로토콜 설정 옵션(PCO: Protocol Configuration Option)에 포함되어 전송될 수 있다.
그 후, 273 단계에서 MME(220)는 SGW(230)에게 보내는 메시지, 예를 들면 세션 생성 요청(Create Session Request) 메시지에 APN과 SCS 주소를 요청함을 나타내는 정보를 포함하여 전송할 수 있다. 만약 사용자 단말(210)이 SCS 주소를 요청함을 나타내는 정보를 PCO에 포함하여 전송한 경우, 실시 예에 따라 MME(220)는 사용자 단말(210)로부터 수신된 PCO를 그대로 SGW(230)에게 보내는 메시지에 삽입하여 전달할 수도 있다.
275 단계에서 SGW(230)는 MME(220)로부터 수신한 정보를 기반으로 Create Session Request 메시지를 생성하여 PGW(240)에게 전송할 수 있다. 즉, 273 단계에서 MME(220)로부터 수신된 정보는 SGW(230)에 의해 PGW(240)에게 전달될 수 있다.
한편, PGW(240)는 SGW(230)로부터 수신된 요청 메시지에 사용자 단말(210)이 SCS 주소를 요청함을 나타내는 정보가 포함된 경우, 277 단계에서 사용자 단말(210)에게 알려줄 SCS 주소를 결정할 수 있다. 이 때 PGW(240)가 사용자 단말(210)에게 알려줄 SCS의 주소는, 현재 연결에 대한 APN 또는 사용자 단말(210)에 대한 기본 QoS 정보에 의해 결정될 수 있다. 이 과정 중에 PGW(240)는 상기 정보들을 이용하여 DNS 쿼리(query)를 수행하거나, 별도의 다른 네트워크 노드와 정보를 주고받을 수도 있다.
그 후, 279 단계에서 PGW(240)는 SGW(230)에게 보내는 메시지, 예를 들면 세션생성 응답(Create Session Response) 메시지에 결정된 SCS의 주소를 넣어서 보낼 수 있다. 실시 예에 따라, 상기 결정된 SCS의 주소는 PCO에 포함되어 SGW(230)에게 전달될 수도 있다.
그리고 281 단계에서 SGW(230)는 PGW(240)로부터 수신된 정보에 따라 MME(220)에게 메시지, 예를 들면 Create Session Response 메시지를 전송할 수 있다. 이때, 상기 MME(220)에게 전송되는 메시지에는 SCS의 주소 또는 SCS의 주소를 담고 있는 PCO가 포함될 수 있다.
283 단계에서 MME(220)는 사용자 단말(210)에게 전송하는 메시지, 예를 들면 디폴트 베어러 활성 요청(Activate Default Bearer Request) 메시지에 SGW(230)로부터 수신된 SCS의 주소를 넣어서 전송할 수 있다. 만약 SCS의 주소가 PCO에 삽입되어 수신된 경우, 실시 예에 따라 MME(220)는 SGW(230)로부터 수신한 PCO를 그대로 상기 메시지에 삽입하여 사용자 단말(210)에게 전달할 수 있다.
그리고 285 단계에서 사용자 단말(210)은 MME(220)로부터 수신한 메시지로부터 SCS의 주소를 파악하고, 이를 저장할 수 있다. 그리하여 이후 메시지 송수신에 SCS의 기능을 활용할 때 상기 저장된 SCS 주소를 사용할 수 있다.
도 3은 본 발명의 일 실시 예에 따른 저전력 모드의 사용자 단말을 위해 메시지를 전송해주는 통신 시스템의 동작의 흐름도의 일 예를 나타내는 도면이다.
도 3을 참고하면, 사용자 단말(310)은 371 단계에서 단말 상태, 서비스 응용의 요청, 설정 정보 등에 따라 저전력 모드(PSM: Power Save Mode)로 상태를 변경하기로 결정할 수 있다.
사용자 단말(310)은 저전력 상태 사용을 요청하기 위해, 373 단계에서TA(Tracking Area) 업데이트(update) 요청 메시지를 MME(320)에게 전달할 수 있다. 한편, 사용자 단말(310)이 MME(320)에게 전송하는 TA update 요청 메시지에는 주기적 TAU 타이머(Periodic TAU timer), 액티브 타이머(Active timer), 그리고 필요한 경우 액티브 플래그(active flag) 중 적어도 하나가 포함될 수 있다. Periodic TAU timer는 다음 TAU가 발생할 때까지의 시간 간격을 나타내며, 따라서 본 발명 전체에서 periodic TAU timer는 사용자 단말(310)이 저전력 모드에서 머무를 시간을 나타내는 값일 수 있다. 만약 사용자 단말(310)이 저전력 상태에 들어가기 전에 보낼 메시지가 있으면, 사용자 단말(310)은 active flag를 설정하여 TA update 메시지를 보낼 수 있다. 또한, 실시 예에 따라 사용자 단말(310)은 명시적으로 사용자 단말(310) 대신 네트워크에서 메시지 전송을 수행하는 기능 사용을 요청하는 정보를 상기 TA update 요청 메시지에 포함할 수 있다. 또한, 실시 예에 따라 사용자 단말(310)은 낮은 우선순위 또는 전송지연에 민감하지 않은 단말의 특성을 나타내는 정보를 상기 TA update 요청 메시지에 포함하여 전달할 수도 있다.
MME(320)는 사용자 단말의 TA update 요청에 따라 저전력 모드 사용 여부 및 적용 파라메터(Periodic TAU timer, active timer)를 결정할 수 있다. 그리고, 375 단계에서 MME(320)는 사용자 단말(310)에게 전송하는 TA 업데이트 수락(TA update accept) 메시지에, 상기 정보를 포함시킬 수 있다. Periodic TAU timer는 다음 TAU가 발생할 때까지의 시간 간격을 나타내며, 사용자 단말(310)이 저전력 모드에서 머무를 시간을 나타내는 값이다. MME(320)는 사용자 단말(310)의 요청(예를 들어, 낮은 우선순위 또는 전송지연에 민감하지 않은 단말의 특성을 나타내는 정보), 사용자 단말(310)이 가진 PDN 연결의 특성(APN, ARP 등), 내부 설정, 그리고 가입 정보 중 하나 이상을 바탕으로 사용자 단말(310)에 대해 사용자 단말(310) 대신 네트워크에서 메시지 전송을 수행하는 기능 적용 여부를 결정할 수 있다. 그리고, 실시 예에 따라 MME(320)는 그 결과를 명시적으로 TA update accept에 포함시켜 사용자 단말(310)에게 전달할 수 있다.
이후, 379 단계에서 사용자 단말(310)은 MME(320)로부터 수신한 TA update accept 메시지로부터 파라미터를 얻고, 이를 적용하여 저전력 모드로 진입하기 위한 동작을 수행할 수 있다. 특히, 사용자 단말(310)은 active timer를 시작하고, active timer가 만료(expire)될 때까지 저전력 모드로 상태를 변경하지 않고 대기할 수 있다.
한편, 377 단계에서 MME(320)는 HSS 또는 IWF(330)에게 사용자 단말(310)이 저전력 모드로 전환되었음을 알릴 수 있다. 이때, 실시 예에 따라 MME(320)는 HSS 또는 IWF(330)에게 상기 사용자 단말(310)의 저전력 모드의 지속 시간 정보 등의 정보를 함께 전달할 수 있다.
한편, 사용자 단말(310)은, 자신의 저전력 모드 동작 동안에 서버(또는 외부 망)에서 데이터 전송을 요청할 경우 이를 네트워크에서 대신해주는 기능이 필요한지 여부를 판단할 수 있다. 이는, 사용자 단말(310)의 내부 설정 정보를 기반으로 이루어지거나, 또는 상기 TA update accept 또는 그 전에 수신된 attach accept 메시지에 포함된 정보(예를 들면, 사용자 단말(310) 대신 네트워크에서 메시지 전송을 수행하는 기능에 대한 지원 여부)에 기반하여 이루어질 수 있다.
사용자 단말(310)은 만약 상기 기능 사용이 가능하고, 전송할 메시지가 있으면, 381 단계에서 active timer가 만료되기 전에 상기 메시지를 SCS(350)에게 전송할 수 있다. 상기 메시지는, 예를 들면 IP 통신을 사용하는 메시지일 수 있으며, 보다 구체적으로 COAP, MQTT, XMPP 또는 HTTP 프로토콜을 사용하는 메시지일 수 있다. 또한, 상기 메시지의 전송 코드(code) 또는 원인(cause)은 예를 들면 POST일 수 있다. 상기 메시지에는 사용자 단말(310)이 저전력 모드로 동작함을 나타내는 정보, 저전력 모드가 적용되는 시간, 사용자 단말(310) 대신 전송 동작을 요청하는 정보, 사용자 단말(310)이 접속 중인 RAT(Radio Access Technology, E-UTRAN/UTRAN/GERAN 중 하나를 나타내는 식별자), 그리고 실제 전송해야 할 메시지 중 하나 이상이 포함될 수 있다. 또한 상기 메시지는 active timer가 포함될 수 있다. 그리고, 실시 예에 따라 상기 메시지는 PGW(340)를 거쳐 SCS(350)까지 전달될 수 있다(383 단계). 상기 메시지의 목적지 주소는, 미리 수신한 SCS(350)의 주소로 설정될 수 있다. 실시 예에 따라 사용자 단말(310)은 자신의 외부 ID(external ID)를 SCS(350)에게 전송하는 메시지에 포함시킬 수 있다. 한편, 사용자 단말(310)은 상기 동작 즉, 사용자 단말(310)이 저전력 모드인 동안에 사용자 단말 대신 네트워크에서 전송 동작을 수행하여 주기를 요청하기 위한 일련의 동작을 수행할지 여부를 결정하기 위해, 사용자 단말(310)이 접속 중인 RAT 정보를 활용할 수 있다. 특히, 사용자 단말(310)은 특정 RAT, 예를 들면 전송률이 낮은 GERAN을 사용자 단말(310)이 사용 중인 경우에만 상기 기능을 요청할 수 있다.
상기와 같이 SCS(350)는 381 단계(및 383 단계)에서 사용자 단말(310)로부터 메시지를 수신할 수 있다. 이때 만약 수신된 메시지에 active timer가 포함된 경우, 385 단계에서 SCS(350)는 timer를 시작(start)할 수 있다.
이 경우, SCS(350)는 앞선 단계(즉, 381 단계 및 383 단계)에서 수신된 메시지에 따라 사용자 단말(310)이 저전력 모드로 동작하며, 사용자 단말(310) 대신 메시지 전송 동작을 수행해야 함을 알 수 있다. 이때, 실시 예에 따라 상기 수신된 메시지에 사용자 단말(310)의 저전력 모두 유지 시간이 포함된 경우, SCS(350)는 사용자 단말(310)로부터 별도의 메시지를 수신하지 않는 한 수신된 메시지에 포함된 저전력 모드 유지 시간 동안 사용자 단말(310)이 저전력 모드로 동작한다고 간주하고, 메시지를 대신 전송하는 동작을 수행할 수 있다. 또한, 만약 수신된 정보에 active timer가 포함된 경우, SCS(350)는 상기 사용자 단말(310) 대신 메시지를 전송하는 동작을 active timer가 만료(expire) 되었을 때부터 적용할 수 있다. 한편, 실시 예에 따라 SCS(350)는 사용자 단말(310) 및 실제 서버를 구분하기 위해, 사용자 단말(310)이 보낸 메시지로부터 소스 주소(Source IP 주소)와 포트, 실제 목적지 주소(destination IP 주소)와 포트를 저장할 수 있다. 또는, 사용자 단말(310)이 외부 ID(external ID)를 알린 경우, SCS(350)는 이를 저장할 수 있다. 한편, SCS(350)는 상기 동작을 수행할지 여부를 결정하기 위해, 사용자 단말(310)이 접속 중인 RAT 정보를 활용할 수 있다. 특히, SCS(350)는 특정 RAT, 예를 들면 전송률이 낮은 GERAN을 사용자 단말(310)이 사용 중인 경우에만 상기 기능을 적용할 수 있다. 또한, SCS(350)는 사용자 단말(310)이 접속 중인 RAT의 종류에 따라 프로토콜 전환(즉, 사용자 단말(310)이 CoAP로 전송한 메시지를, HTTP 메시지로 전환하거나, 사용자 단말(310)에게 전송해야 할 메시지의 프로토콜을 HTTP에서 CoAP로 전환) 기능 적용 여부를 결정할 수도 있다.
이후, 387 단계에서 SCS(350)는 사용자 단말(310)에게 메시지를 수신했음을 알리는 메시지를 전송할 수 있다. 이 메시지는 앞선 사용자 단말(310)이 전송하는 메시지와 동일한 프로토콜을 사용할 수 있으며, 전송 code 또는 cause는 예를 들면 200 OK로 설정될 수 있다. 한편, 실시 예에 따라 상기 메시지는 PGW(340)를 거쳐 사용자 단말(310)에게 전송될 수 있다(389 단계).
그리고, 사용자 단말(310)은 active timer가 만료되면, 391 단계에서 저전력 모드로 동작하기 시작한다.
이후, 393 단계에서 SCS(350)는 사용자 단말(310)에 대해 메시지 전송을 요구하는 메시지를 서버로부터 수신할 수 있다. 이 메시지는 예를 들면 IP 통신을 사용하는 메시지일 수 있으며, 보다 구체적으로 COAP, MQTT, XMPP 또는 HTTP 프로토콜을 사용하는 메시지일 수 있다. 또한, 상기 메시지의 전송 code 또는 cause는 예를 들면, GET일 수 있다. SCS(350)는 저장된 정보와 수신된 메시지의 목적지 주소(IP 주소와 포트) 또는 external ID를 비교하여, 일치하는 주소 또는 ID를 갖는 사용자 단말(310)이 있는지 비교할 수 있다. 그리고, 만약 일치하는 주소 또는 ID를 갖는 사용자 단말(310)이 있다면, SCS(350)는 저전력 모드로 동작하는 사용자 단말(310)에 대한 메시지에 대한 응답 메시지를 자신이 사용자 단말(310) 대신 전송하는 것이 필요함을 알 수 있다.
그리고, 395 단계에서 SCS(350)는 사용자 단말(310) 대신 응답 메시지를 보낼 수 있다. 이 응답 메시지는 예를 들면 IP 통신을 사용하는 메시지일 수 있으며, 보다 구체적으로 COAP, MQTT, XMPP 또는 HTTP 프로토콜을 사용하는 메시지일 수 있다. 또한, 상기 메시지의 전송 code 또는 cause는 예를 들면, 200 OK일 수 있다. 또한, 상기 메시지에는 사용자 단말(310)이 대신 전송해달라고 요청했던 메시지가 포함될 수 있다. 또한, 실시 예에 따라 상기 메시지의 송신자 주소 또는 external ID는, SCS(350)의 것이 아닌 사용자 단말(310)의 주소 또는 external ID로 설정될 수 있다. 만약 사용자 단말(310)이 전송한 메시지의 프로토콜과, 서버에서 사용하는 프로토콜이 서로 상이한 경우, 예를 들면 사용자 단말(310)은 CoAP 프로토콜을 사용하고, 서버는 HTTP 프로토콜을 사용하는 경우, SCS(350)는 프로토콜 변환을 수행할 수도 있다.
한편 상기 실시 예들 설명함에 있어 이미 attach 된 상태에서 사용자 단말(310)이 저전력 모드로 동작하기 위한 상황, 즉 TA update 과정을 수행하는 것을 기준으로 하였으나, 상기 사용자 단말(310) 및 네트워크의 동작은 사용자 단말(310)에 대한 attach 과정이 수행될 때도 적용될 수 있다. 만약 attach 과정 중에 상기 실시 예가 적용된다면, TA update request 메시지는 attach request 메시지, TAU accept 메시지는 attach accept 메시지로 바뀌어 적용될 수 있다.
도 4는 본 발명의 일 실시 예에 따른 저전력 모드의 사용자 단말을 위해 메시지를 전송해주는 통신 시스템의 동작의 흐름도의 다른 일 예를 나타내는 도면이다.
도 4를 참고하면, 사용자 단말(410)은 471 단계에서 단말 상태, 서비스 응용의 요청, 설정 정보 등에 따라 저전력 모드(PSM: Power Save Mode)로 상태를 변경하기로 결정할 수 있다.
사용자 단말(410)은 저전력 상태 사용을 요청하기 위해, 473 단계에서 TA update 요청 메시지를 MME(420)에게 전달할 수 있다. 한편, 사용자 단말(410)이 MME(420)에게 전송하는 TA update 요청 메시지에는 Periodic TAU timer, Active timer, 그리고 필요한 경우 active flag 중 적어도 하나가 포함될 수 있다. 만약 사용자 단말(410)이 저전력 상태에 들어가기 전에 보낼 메시지가 있으면, 사용자 단말(410)은 active flag를 설정하여 TA update 메시지를 보낼 수 있다. 또한, 실시 예에 따라 사용자 단말(410)은 명시적으로 사용자 단말(410) 대신 네트워크에서 메시지 전송을 수행하는 기능 사용을 요청하는 정보를 상기 TA update 요청 메시지에 포함할 수 있다. 또한, 실시 예에 따라 사용자 단말(410)은 낮은 우선순위 또는 전송지연에 민감하지 않은 단말의 특성을 나타내는 정보를 상기 TA update 요청 메시지에 포함하여 전달할 수도 있다.
MME(420)는 사용자 단말(410)의 TA update 요청에 따라 저전력 모드 사용 여부 및 적용 파라메터(Periodic TAU timer, active timer)를 결정할 수 있다. 그리고, 475 단계에서 MME(420)는 사용자 단말(410)에게 전송하는 TA update accept 메시지에, 상기 정보를 포함시킬 수 있다. MME(420)는 사용자 단말(410)의 요청(예를 들어, 낮은 우선순위 또는 전송지연에 민감하지 않은 단말의 특성을 나타내는 정보), 사용자 단말(410)이 가진 PDN 연결의 특성(APN, ARP 등), 내부 설정, 그리고 가입 정보 중 하나 이상을 바탕으로 사용자 단말(410)에 대해 사용자 단말(410) 대신 네트워크에서 메시지 전송을 수행하는 기능 적용 여부를 결정할 수 있다. 그리고, 실시 예에 따라 MME(420)는 그 결과를 명시적으로 TA update accept에 포함시켜 사용자 단말(410)에게 전달할 수 있다.
이후, 479 단계에서 사용자 단말(410)은 MME(420)로부터 수신한 TA update accept 메시지로부터 파라미터를 얻고, 이를 적용하여 저전력 모드로 진입하기 위한 동작을 수행할 수 있다. 특히, 사용자 단말(410)은 active timer를 시작하고, active timer가 만료(expire)될 때까지 저전력 모드로 상태를 변경하지 않고 대기할 수 있다.
한편, 477 단계에서 MME(420)는 HSS 또는 IWF(430)에게 사용자 단말(410)이 저전력 모드로 전환되었음을 알릴 수 있다. 이때, 실시 예에 따라 MME(420)는 HSS 또는 IWF(430)에게 사용자 단말(410)의 식별자, IP 주소, 사용자 단말이 접속 중인 RAT, 그리고 저전력 모드의 지속 시간 정보, active timer 중 하나 이상의 정보를 함께 전달할 수 있다. HSS 또는 IWF(430)는 MME(420)로부터 수신된 정보를 저장하고, 이후 SCS(450)로부터 사용자 단말(410)에 대한 정보가 요청되거나, 또는 사용자 단말(410)의 상태가 변경될 때 마다, 저장된 정보 중 하나 이상을 SCS(450)에게 전달해 줄 수 있다.
한편, 사용자 단말은(410) 자신의 저전력 모드 동작 동안에 서버(또는 외부 망)에서 데이터 전송을 요청할 경우 이를 네트워크에서 대신해주는 기능이 필요한지 여부를 판단할 수 있다. 이는, 사용자 단말(410)의 내부 설정 정보를 기반으로 이루어지거나, 또는 상기 TA update accept 또는 그 전에 수신된 attach accept 메시지에 포함된 정보(예를 들면, 사용자 단말(410) 대신 네트워크에서 메시지 전송을 수행하는 기능에 대한 지원 여부)에 기반하여 이루어질 수 있다.
사용자 단말(410)은 만약 상기 기능 사용이 가능하고, 전송할 메시지가 있으면, 481 단계에서 active timer가 만료되기 전에 상기 메시지를 SCS(450)에게 전송할 수 있다. 상기 메시지는, 예를 들면 IP 통신을 사용하는 메시지일 수 있으며, 보다 구체적으로 COAP, MQTT, XMPP 또는 HTTP 프로토콜을 사용하는 메시지일 수 있다. 또한, 상기 메시지의 전송 code 또는 cause는 예를 들면 POST일 수 있다. 상기 메시지에는 사용자 단말(410) 대신 전송 동작을 요청하는 정보, 그리고 실제 전송해야 할 메시지, 그리고 사용자 단말(410)의 external ID 중 하나 이상이 포함될 수 있다. 한편, 실시 예에 따라 상기 메시지는 PGW(440)를 거쳐 SCS(450)까지 전달될 수 있다(481 단계). 상기 메시지의 목적지 주소는, 미리 수신한 SCS(450)의 주소로 설정될 수 있다. 그리고 485 단계에서 SCS(450)는 상기 사용자 단말(410)로부터 수신된 메시지에 포함된 정보들을 저장할 수 있다.
상기와 같이 SCS(450)는 481 단계 및 483 단계에서 사용자 단말(410)로부터 메시지를 수신할 수 있다.
487 단계에서 SCS(450)는 사용자 단말(410)의 상태 정보를 확인하기 위해 HSS 또는 IWF(430)에게 사용자 단말(410)의 상태 정보를 묻는 메시지를 전송할 수 있다. 이 동작은 실시 예에 따라 사용자 단말(410)에 대한 상태 정보가 SCS(450)에 저장되어 있지 않거나, 또는 사용자 단말(410) 상태 정보에 대한 유효 타이머(validity timer)가 만료된 경우에 수행될 수 있다. 상기 요청 메시지에는 사용자 단말(410)의 외부 ID 또는 IP 주소 중 하나 이상이 포함될 수 있다.
SCS(450)로부터 요청 메시지를 수신한 HSS 또는 IWF(430)는, 489 단계에서 수신된 메시지의 주소로부터 사용자 단말(410)의 상태 정보를 얻기(derive)하기 위한 동작을 수행할 수 있다. 예를 들면, HSS 또는 IWF(430)는 SCS(450)로부터 수신한 외부 ID 또는 IP 주소를 3GPP 고유 식별자(예, IMSI)로 매핑하고, 이를 가지고 사용자 단말(410)의 상태 정보를 얻을 수 있다.
HSS 또는 IWF(430)는, 사용자 단말(410)의 상태 정보를 SCS(450)에게 알리기 위한 메시지를 491 단계에서 전송할 수 있다. HSS 또는 IWF(430)는 SCS(450)에게 보내는 사용자 단말 상태 정보 메시지에 사용자 단말(410)의 외부 ID, 사용자 단말(410)의 IP 주소, 사용자 단말(410)의 현재 상태(저전력 모드인지 아닌지), 사용자 단말(410)이 접속 중인 RAT, 저전력 모드가 적용되는 시간을 나타내는 타이머(예를 들어, periodic TAU timer) 중 적어도 하나 이상을 포함할 수 있다. 또한, 상기 메시지에는 사용자 단말(410)의 저전력 모드 동안 사용자 단말(410) 대신 메시지를 전송하는 기능을 적용해야 함을 나타내는 정보가 포함될 수 있다. 또한, 상기 메시지는 active timer가 포함될 수 있다. 만약 상기 메시지에 active timer가 포함된 경우 SCS(450)는 메시지를 수신하면 active timer를 시작(start)하고, active timer가 만료(expire)되는 순간부터 사용자 단말(410) 대신 메시지를 전송하는 기능을 적용할 수 있다. 또한, 상기 메시지에는 validity timer가 포함될 수 있는데, 이 timer는 현재 전송된 메시지에 포함된 사용자 단말(410)의 상태 정보가 유효한 시간을 나타낸다. 이 메시지를 수신한 SCS(450)는 이 정보들을 저장하고, 이 정보들에 따라 사용자 단말(410)의 현재 상태 및 저전력 상태가 지속될 시간을 파악할 수 있다.
한편, HSS 또는 IWF(430)는 상기 동작(즉, 메시지 proxy 기능)을 수행할지 여부를 결정하기 위해, 사용자 단말(410)이 접속 중인 RAT 정보를 활용할 수 있다. 특히, HSS 또는 IWF(430)은 특정 RAT, 예를 들면 전송률이 낮은 GERAN을 사용자 단말(410)이 사용 중인 경우에만 상기 기능을 요청할 수 있다. 또한, HSS 또는 IWF(430)는 사용자 단말(410)이 접속 중인 RAT의 종류에 따라 프로토콜 전환(즉, 사용자 단말(410)이 CoAP로 전송한 메시지를, HTTP 메시지로 전환하거나, 사용자 단말에게 전송해야 할 메시지의 프로토콜을 HTTP에서 CoAP로 전환) 기능 적용 요청 여부를 결정할 수도 있다.
SCS(450)는 앞선 단계에서 수신된 메시지에 따라 사용자 단말(410) 대신 메시지 전송 동작을 수행해야 함을 알 수 있다. 이때, 실시 예에 따라 SCS(450)는 사용자 단말(410) 및 실제 서버를 구분하기 위해, 사용자 단말(410)이 보낸 메시지로부터 소스 주소(Source IP 주소)와 포트, 실제 목적지 주소(destination IP 주소)와 포트를 저장할 수 있다. 또한, SCS(450)는 사용자 단말(410)이 외부 ID(external ID)를 알린 경우, 이를 저장할 수 있다. 한편, SCS(450)는 상기 동작을 수행할지 여부를 결정하기 위해, 사용자 단말(410)이 접속 중인 RAT 정보를 활용할 수 있다. 특히, SCS(450)는 특정 RAT, 예를 들면 전송률이 낮은 GERAN을 사용자 단말(410)이 사용 중인 경우에만 상기 기능을 적용할 수 있다. 또한, SCS(450)는 사용자 단말(410)이 접속 중인 RAT의 종류에 따라 프로토콜 전환(즉, 사용자 단말(410)이 CoAP로 전송한 메시지를, HTTP 메시지로 전환하거나, 사용자 단말(410)에게 전송해야 할 메시지의 프로토콜을 HTTP에서 CoAP로 전환) 기능 적용 여부를 결정할 수 있다.
이후, 493 단계에서 SCS(450)는 사용자 단말(410)에게 메시지를 수신했음을 알리는 메시지를 전송할 수 있다. 이 메시지는 앞선 사용자 단말(410)이 전송하는 메시지와 동일한 프로토콜을 사용할 수 있으며, 전송 code 또는 cause는 예를들면 200 OK로 설정될 수 있다. 한편, 실시 예에 따라 상기 메시지는 PGW(340)를 거쳐 사용자 단말(310)에게 전송될 수 있다(494 단계).
이후, 497 단계에서 SCS(450)는 HSS 또는 IWF(430)로부터 상기 491 단계에서 수신된 사용자 단말(410)의 상태 정보에 따라 사용자 단말(410) 대신 메시지를 전송하는 동작을 수행할지 여부를 결정할 수 있다. 만약, HSS 또는 IWF(430)로부터 수신된 메시지에 사용자 단말(410)이 저전력 모드로 동작하는 시간에 대한 정보가 포함된 경우, SCS(450)는 이에 시간에 따라 timer를 시작하고, timer가 만료될 때까지 사용자 단말(410) 대신 메시지를 전송하는 동작을 수행할 수 있다.
한편, 사용자 단말은 active timer가 만료되면, 495 단계에서 저전력 모드로 동작하기 시작한다.
이후, 498 단계에서 SCS(450)는 사용자 단말(410)에 대해 메시지 전송을 요구하는 메시지를 서버로부터 수신할 수 있다. 이 메시지는 예를 들면 IP 통신을 사용하는 메시지일 수 있으며, 보다 구체적으로 COAP, MQTT, XMPP 또는 HTTP 프로토콜을 사용하는 메시지일 수 있다. 또한, 상기 메시지의 전송 code 또는 cause는 예를 들면 GET일 수 있다. SCS(450)는 저장된 정보와 수신된 메시지의 목적지 주소(IP 주소와 포트) 또는 external ID를 비교하여, 일치하는 주소 또는 ID를 갖는 사용자 단말(410)이 있는지 비교할 수 있다. 그리고, 만약 일치하는 주소 또는 ID를 갖는 사용자 단말(410)이 있다면, SCS(450)는 저전력 모드로 동작하는 사용자 단말(410)에 대한 메시지에 대한 응답 메시지를 자신이 사용자 단말(410) 대신 전송하는 것이 필요함을 알 수 있다.
그리고, 499 단계에서 SCS(450)는 사용자 단말(410) 대신 응답 메시지를 보낼 수 있다. 이 응답 메시지는 예를 들면 IP 통신을 사용하는 메시지일 수 있으며, 보다 구체적으로 COAP, MQTT, XMPP 또는 HTTP 프로토콜을 사용하는 메시지일 수 있다. 또한, 상기 메시지의 전송 code 또는 cause는 예를 들면 200 OK일 수 있다. 또한, 상기 메시지에는 사용자 단말(410)이 대신 전송해달라고 요청했던 메시지가 포함될 수 있다. 또한, 실시 예에 따라 상기 메시지의 송신자 주소 또는 external ID는, SCS(450)의 것이 아닌 사용자 단말(410)의 주소 또는 external ID로 설정될 수 있다. 만약 사용자 단말(410)이 전송한 메시지의 프로토콜과, 서버에서 사용하는 프로토콜이 서로 상이한 경우, 예를 들면 사용자 단말(410)은 CoAP 프로토콜을 사용하고, 서버는 HTTP 프로토콜을 사용하는 경우, SCS(450)는 프로토콜 변환을 수행할 수도 있다.
한편 상기 실시 예들 설명함에 있어 이미 attach 된 상태에서 사용자 단말(410)이 저전력 모드로 동작하기 위한 상황, 즉 TA update 과정을 수행하는 것을 기준으로 하였으나, 상기 사용자 단말(410) 및 네트워크의 동작은 사용자 단말(410)에 대한 attach 과정이 수행될 때도 적용될 수 있다. 만약 attach 과정 중에 상기 실시 예가 적용된다면, TA update request 메시지는 attach request 메시지, TAU accept 메시지는 attach accept 메시지로 바뀌어 적용될 수 있다.
도 5는 본 발명의 일 실시 예에 따른 저전력 모드의 사용자 단말을 위해 메시지를 전송해주는 통신 시스템의 동작의 흐름도의 또 다른 일 예를 나타내는 도면이다.
도 5를 참고하면, 사용자 단말(510)은 571 단계에서 단말 상태, 서비스 응용의 요청, 설정 정보 등에 따라 저전력 모드(PSM: Power Save Mode)로 상태를 변경하기로 결정할 수 있다.
사용자 단말(510)은 저전력 상태 사용을 요청하기 위해, 513 단계에서 TA update 요청 메시지를 MME(520)에게 전달할 수 있다. 한편, 사용자 단말(510)이 MME(4520)에게 전송하는 TA update 요청 메시지에는 Periodic TAU timer, Active timer, 그리고 필요한 경우 active flag 중 적어도 하나가 포함될 수 있다. 만약 사용자 단말(510)이 저전력 상태에 들어가기 전에 보낼 메시지가 있으면, 사용자 단말(510)은 active flag를 설정하여 TA update 메시지를 보낼 수 있다. 또한, 실시 예에 따라 사용자 단말(510)은 명시적으로 사용자 단말(510) 대신 네트워크에서 메시지 전송을 수행하는 기능 사용을 요청하는 정보를 상기 TA update 요청 메시지에 포함할 수 있다. 또한, 실시 예에 따라 사용자 단말(510)은 낮은 우선순위 또는 전송지연에 민감하지 않은 단말의 특성을 나타내는 정보를 상기 TA update 요청 메시지에 포함하여 전달할 수도 있다.
MME(520)는 사용자 단말(510)의 TA update 요청에 따라 저전력 모드 사용 여부 및 적용 파라메터(Periodic TAU timer, active timer)를 결정할 수 있다. 그리고, 575 단계에서 MME(520)는 사용자 단말(510)에게 전송하는 TA update accept 메시지에, 상기 정보를 포함시킬 수 있다. MME(520)는 사용자 단말(510)의 요청(예를 들어, 낮은 우선순위 또는 전송지연에 민감하지 않은 단말의 특성을 나타내는 정보), 사용자 단말(510)이 가진 PDN 연결의 특성(APN, ARP 등), 내부 설정, 그리고 가입 정보 중 하나 이상을 바탕으로 사용자 단말(510)에 대해 사용자 단말(510) 대신 네트워크에서 메시지 전송을 수행하는 기능 적용 여부를 결정할 수 있다. 그리고, 실시 예에 따라 MME(520)는 그 결과를 명시적으로 TA update accept에 포함시켜 사용자 단말(510)에게 전달할 수 있다.
이후, 579 단계에서 사용자 단말(510)은 MME(520)로부터 수신한 TA update accept 메시지로부터 파라미터를 얻고, 이를 적용하여 저전력 모드로 진입하기 위한 동작을 수행할 수 있다. 특히, 사용자 단말(510)은 active timer를 시작하고, active timer가 만료(expire)될 때까지 저전력 모드로 상태를 변경하지 않고 대기할 수 있다.
한편, 577 단계에서 MME(520)는 HSS 또는 IWF(530)에게 사용자 단말(510)이 저전력 모드로 전환되었음을 알릴 수 있다. 이때, 실시 예에 따라 MME(520)는 HSS 또는 IWF(530)에게 사용자 단말(510)의 식별자, IP 주소, 그리고 저전력 모드의 지속 시간 정보, active timer 중 하나 이상의 정보를 함께 전달할 수 있다. HSS 또는 IWF(530)는 MME(520)로부터 수신된 정보를 저장하고, 이후 SCS(550)로부터 사용자 단말(510)에 대한 정보가 요청되거나, 또는 사용자 단말(510)의 상태가 변경될 때 마다, 저장된 정보 중 하나 이상을 SCS(550)에게 전달해 줄 수 있다.
이후, 581 단계에서 HSS 또는 IWF(530)는, 사용자 단말(510)의 상태 정보를 SCS(550)에게 알리기 위한 메시지를 전송할 수 있다. 실시 예에 따라 SCS(550)에게 사용자 단말(510)의 상태 정보가 전달되는 것은, 사용자 단말(510)이 저전력 모드로 상태가 변경되거나, 또는 저전력 상태에 있던 사용자 단말(510)의 상태가 다른 상태로 변경될 때 이루어질 수 있다. HSS 또는 IWF(530)는 SCS(550)에게 보내는 사용자 단말(510)의 상태 정보 메시지에 사용자 단말(510)의 외부 ID, 사용자 단말(510)의 IP 주소, 사용자 단말(510)의 현재 상태(저전력 모드인지 아닌지), 사용자 단말(510)이 접속 중인 RAT, 저전력 모드가 적용되는 시간을 나타내는 타이머(예를 들어, periodic TAU timer) 중 적어도 하나 이상을 포함할 수 있다. 또한, 상기 메시지에는 사용자 단말(510)의 저전력 모드 동안 사용자 단말(510) 대신 메시지를 전송하는 기능을 적용해야 함을 나타내는 정보가 포함될 수 있다. 또한, 상기 메시지는 active timer가 포함될 수 있다. 만약 상기 메시지에 active timer가 포함된 경우 SCS(550)는 메시지를 수신하면 active timer를 시작(start)하고, active timer가 만료(expire)되는 순간부터 사용자 단말(510) 대신 메시지를 전송하는 기능을 적용할 수 있다. 이 메시지를 수신한 SCS(550)는 이 정보들을 저장하고, 이 정보들에 따라 사용자 단말(510)의 현재 상태 및 저전력 상태가 지속될 시간을 파악할 수 있다.
한편, HSS 또는 IWF(530)는 상기 동작(즉, 메시지 proxy 기능)을 수행할지 여부를 결정하기 위해, 사용자 단말(510)이 접속 중인 RAT 정보를 활용할 수 있다. 특히, HSS 또는 IWF(530)은 특정 RAT, 예를 들면 전송률이 낮은 GERAN을 사용자 단말(510)이 사용 중인 경우에만 상기 기능을 요청할 수 있다. 또한, HSS 또는 IWF(530)는 사용자 단말(510)이 접속 중인 RAT의 종류에 따라 프로토콜 전환(즉, 사용자 단말(510)이 CoAP로 전송한 메시지를, HTTP 메시지로 전환하거나, 사용자 단말(510)에게 전송해야 할 메시지의 프로토콜을 HTTP에서 CoAP로 전환) 기능 적용 요청 여부를 결정할 수도 있다.
한편, 579 단계에서 사용자 단말(510)은, 자신의 저전력 모드 동작 동안에 서버(또는 외부 망)에서 데이터 전송을 요청할 경우 이를 네트워크에서 대신해주는 기능이 필요한지 여부를 판단할 수 있다. 이는, 사용자 단말(510)의 내부 설정 정보를 기반으로 이루어지거나, 또는 상기 TA update accept 또는 그 전에 수신된 attach accept 메시지에 포함된 정보(예를 들면, 사용자 단말(510) 대신 네트워크에서 메시지 전송을 수행하는 기능에 대한 지원 여부)에 기반하여 이루어질 수 있다.
사용자 단말(510)은 만약 상기 기능 사용이 가능하고, 전송할 메시지가 있으면, 583 단계에서 active timer가 만료되기 전에 상기 메시지를 SCS(550)에게 전송할 수 있다. 상기 메시지는, 예를 들면 IP 통신을 사용하는 메시지일 수 있으며, 보다 구체적으로 COAP, MQTT, XMPP 또는 HTTP 프로토콜을 사용하는 메시지일 수 있다. 또한, 상기 메시지의 전송 code 또는 cause는 예를 들면 POST일 수 있다. 상기 메시지에는 사용자 단말(510) 대신 전송 동작을 요청하는 정보, 그리고 실제 전송해야 할 메시지, 그리고 사용자 단말(510)의 external ID 중 하나 이상이 포함될 수 있다. 한편, 실시 예에 따라 상기 메시지는 PGW(540)를 거쳐 SCS(550)까지 전달될 수 있다(585 단계). 상기 메시지의 목적지 주소는, 미리 수신한 SCS(550)의 주소로 설정될 수 있다.
상기와 같이 SCS(550)는 583 단계(및 585 단계)에서 사용자 단말(510)로부터 메시지를 수신할 수 있다.
이때, SCS(550)는 앞선 단계에서 수신된 메시지에 따라 사용자 단말(510) 대신 메시지 전송 동작을 수행해야 함을 알 수 있다. 실시 예에 따라 SCS(550)는 사용자 단말(510) 및 실제 서버를 구분하기 위해, 사용자 단말(510)이 보낸 메시지로부터 소스 주소(Source IP 주소)와 포트, 실제 목적지 주소(destination IP 주소)와 포트를 저장할 수 있다. 또는 사용자 단말(510)이 외부 ID(external ID)를 알린 경우, SCS(550)는 이를 저장할 수 있다. 한편, SCS(550)는 상기 동작을 수행할지 여부를 결정하기 위해, 사용자 단말(510)이 접속 중인 RAT 정보를 활용할 수 있다. 특히, SCS(550)는 특정 RAT, 예를 들면 전송률이 낮은 GERAN을 사용자 단말(510)이 사용 중인 경우에만 상기 기능을 적용할 수 있다. 또한, SCS(550)는 사용자 단말(510)이 접속 중인 RAT의 종류에 따라 프로토콜 전환(즉, 사용자 단말(510)이 CoAP로 전송한 메시지를, HTTP 메시지로 전환하거나, 사용자 단말(510)에게 전송해야 할 메시지의 프로토콜을 HTTP에서 CoAP로 전환) 기능 적용 여부를 결정할 수도 있다.
이후, 587 단계에서 SCS(550)는 사용자 단말(510)에게 메시지를 수신했음을 알리는 메시지를 전송할 수 있다. 이 메시지는 앞선 사용자 단말(510)이 전송하는 메시지와 동일한 프로토콜을 사용할 수 있으며, 전송 code 또는 cause는 예를 들면 200 OK로 설정될 수 있다. 한편, 실시 예에 따라 상기 메시지는 PGW(540)를 거쳐 사용자 단말(510)에게 전송될 수 있다(589 단계).
이후, 593 단계에서 SCS(550)는 HSS 또는 IWF(530)로부터 581 단계에서 수신된 사용자 단말(510)의 상태 정보에 따라 사용자 단말(510) 대신 메시지를 전송하는 동작을 수행할지 여부를 결정할 수 있다. 만약, HSS 또는 IWF(530)로부터 수신된 메시지에 사용자 단말(510)이 저전력 모드로 동작하는 시간에 대한 정보가 포함된 경우, SCS(550)는 이에 시간에 따라 timer를 시작하고, timer가 만료될 때까지 사용자 단말(510) 대신 메시지를 전송하는 동작을 수행할 수 있다.
한편, 사용자 단말은 active timer가 만료되면, 591 단계에서 저전력 모드로 동작하기 시작한다.
이후, 595 단계에서 SCS(550)는 사용자 단말(510)에 대해 메시지 전송을 요구하는 메시지를 서버로부터 수신할 수 있다. 이 메시지는 예를 들면 IP 통신을 사용하는 메시지일 수 있으며, 보다 구체적으로 COAP, MQTT, XMPP 또는 HTTP 프로토콜을 사용하는 메시지일 수 있다. 또한, 상기 메시지의 전송 code 또는 cause는 예를 들면 GET일 수 있다. SCS(550)는 저장된 정보와 수신된 메시지의 목적지 주소(IP 주소와 포트) 또는 external ID를 비교하여, 일치하는 주소 또는 ID를 갖는 사용자 단말(510)이 있는지 비교할 수 있다. 그리고, 만약 일치하는 주소 또는 ID를 갖는 사용자 단말(510)이 있다면, SCS(550)는 저전력 모드로 동작하는 사용자 단말(510)에 대한 메시지에 대한 응답 메시지를 자신이 사용자 단말(510) 대신 전송하는 것이 필요함을 알 수 있다.
그리고, 597 단계에서 SCS(550)는 사용자 단말(510) 대신 응답 메시지를 보낼 수 있다. 이 응답 메시지는 예를 들면 IP 통신을 사용하는 메시지일 수 있으며, 보다 구체적으로 COAP, MQTT, XMPP 또는 HTTP 프로토콜을 사용하는 메시지일 수 있다. 또한, 상기 메시지의 전송 code 또는 cause는 예를 들면 200 OK일 수 있다. 또한, 상기 메시지에는 사용자 단말(510)이 대신 전송해달라고 요청했던 메시지가 포함될 수 있다. 또한, 실시 예에 따라 상기 메시지의 송신자 주소 또는 external ID는, SCS(550)의 것이 아닌 사용자 단말(510)의 주소 또는 external ID로 설정될 수 있다. 만약 사용자 단말(510)이 전송한 메시지의 프로토콜과, 서버에서 사용하는 프로토콜이 서로 상이한 경우, 예를 들면 사용자 단말(510)은 CoAP 프로토콜을 사용하고, 서버는 HTTP 프로토콜을 사용하는 경우, SCS(550)는 프로토콜 변환을 수행할 수도 있다.
한편 상기 실시 예들 설명함에 있어 이미 attach 된 상태에서 사용자 단말(510)이 저전력 모드로 동작하기 위한 상황, 즉 TA update 과정을 수행하는 것을 기준으로 하였으나, 상기 사용자 단말(510) 및 네트워크의 동작은 사용자 단말(510)에 대한 attach 과정이 수행될 때도 적용될 수 있다. 만약 attach 과정 중에 상기 실시 예가 적용된다면, TA update request 메시지는 attach request 메시지, TAU accept 메시지는 attach accept 메시지로 바뀌어 적용될 수 있다.
이상에서 사용자 단말이 저전력 모드로 들어갔을 때 서버에서 사용자 단말의 정보(또는 메시지) 전송을 요청하는 경우, 사용자 단말 대신 다른 네트워크 엔티티(entity)가 상기 사용자 단말의 정보를 전달해 주어 단말의 저전력 모드를 유지할 수 있는 방법에 대하여 살펴보았다.
그런데, 만약 사용자 단말이 저전력 모드라 데이터 송수신이 불가능할 때에 하향링크 메시지가 발생하고 네트워크에서 이를 전송시도 할 경우, 불필요한 전송 시그널링이 발생할 수 있다. 또한 메시지 전송 실패로 인한 네트워크의 메시지 폐기(discard)가 발생할 수 있다.
이하에서는 사용자 단말이 저전력 모드로 들어갔을 때, 사용자 단말에게 메시지 전달이 필요한 경우, 즉 하향링크 메시지가 발생했을 때 불필요한 전송 시도 또는 메시지 전송 누락을 방지하는 방법에 대하여 살펴보도록 한다.
도 6은 본 발명의 일 실시 예에 따른 사용자 단말과 네트워크의 동작의 흐름도의 일 예를 나타내는 도면이다.
도 6을 참고하면, 사용자 단말(610)은 671 단계에서 단말 상태, 서비스 응용의 요청, 설정 정보 등에 따라 저전력 모드(PSM: Power Save Mode)로 상태를 변경하기로 결정할 수 있다.
사용자 단말(610)은 저전력 상태 사용을 요청하기 위해, 673 단계에서 TA update 요청 메시지를 MME(620)에게 전달할 수 있다. 한편, 사용자 단말(610)이 MME(620)에게 전송하는 TA update 요청 메시지에는 Periodic TAU timer, Active timer, 그리고 필요한 경우 active flag 중 적어도 하나가 포함될 수 있다. 만약 사용자 단말(610)이 저전력 상태에 들어가기 전에 보낼 메시지가 있으면, 사용자 단말(610)은 active flag를 설정하여 TA update 메시지를 보낼 수 있다. 또한, 실시 예에 따라 사용자 단말(610)은 명시적으로 사용자 단말(610) 대신 일시적으로 메시지를 수신하고 저장(buffering)하는 서비스를 요청하는 정보를 상기 TA update 요청 메시지에 포함할 수 있다. 또한, 실시 예에 따라 사용자 단말(610)은 낮은 우선순위 또는 전송지연에 민감하지 않은 단말의 특성을 나타내는 정보를 상기 TA update 요청 메시지에 포함하여 전달할 수도 있다.
MME(620)는 사용자 단말(610)의 TA update 요청에 따라 저전력 모드 사용 여부 및 적용 파라메터(Periodic TAU timer, active timer)를 결정할 수 있다. 그리고, 675 단계에서 MME(620)는 사용자 단말(610)에게 전송하는 TA update accept 메시지에, 상기 정보를 포함시킬 수 있다. MME(620)는 사용자 단말(610)의 요청(예를 들어, 낮은 우선순위 또는 전송지연에 민감하지 않은 단말의 특성을 나타내는 정보), 사용자 단말(610)이 가진 PDN 연결의 특성(APN, ARP 등), 내부 설정, 그리고 가입 정보 중 하나 이상을 바탕으로 사용자 단말(610)의 저전력 모드 동안 네트워크에서 메시지를 사용자 단말(610) 대신 수신해 저장해 두는 기능의 적용 여부를 결정할 수 있다. 그리고, 실시 예에 따라 MME(620)는 그 결과를 명시적으로 TA update accept에 포함시켜 사용자 단말(610)에게 전달할 수 있다.
이후, 680 단계에서 사용자 단말(610)은 MME(620)로부터 수신한 TA update accept 메시지로부터 파라미터를 얻고, 이를 적용하여 저전력 모드로 진입하기 위한 동작을 수행할 수 있다. 특히, 사용자 단말(610)은 active timer를 시작하고, active timer가 만료(expire)될 때까지 저전력 모드로 상태를 변경하지 않고 대기할 수 있다.
한편, 677 단계에서 MME(620)는 HSS 또는 IWF(630)에게 사용자 단말(610)이 저전력 모드로 전환되었음을 메시지 전송을 통해 알릴 수 있다. 이때, 실시 예에 따라 MME(620)는 HSS 또는 IWF(630)에게 상기 사용자 단말(610)의 식별자, IP 주소, 그리고 저전력 모드의 지속 시간 정보 중 적어도 하나의 정보를 함께 전달할 수 있다. 또한 상기 메시지에는 active timer가 포함될 수 있다. 또한 상기 메시지에는 사용자 단말(610) 대신 메시지를 수신하고 저장하는 기능을 적용해야 함을 나타내는 정보가 포함될 수 있다. HSS 또는 IWF(630)는 MME(620)로부터 수신된 정보를 저장하고, 이후 SCS(650)로부터 사용자 단말(610)에 대한 정보 요청되거나, 또는 사용자 단말(610)의 상태가 변경될 때 마다, 저장된 정보 중 하나 이상을 SCS(650)에게 전달해 줄 수 있다.
이후, 679 단계에서 HSS 또는 IWF(630)는, 사용자 단말(610)의 상태 정보를 SCS(650)에게 알리기 위한 메시지를 전송할 수 있다. 실시 예에 따라 SCS(650)에게 사용자 단말(610)의 상태 정보가 전달되는 것은, 사용자 단말(610)이 저전력 모드로 상태가 변경되거나, 또는 저전력 상태에 있던 사용자 단말(610)의 상태가 다른 상태로 변경될 때 이루어질 수 있다. HSS 또는 IWF(630)는 SCS(650)에게 보내는 사용자 단말(610)의 상태 정보 메시지에 사용자 단말(610)의 외부 ID, 사용자 단말(610)의 IP 주소, 사용자 단말(610)의 현재 상태(저전력 모드인지 아닌지), 저전력 모드가 적용되는 시간을 나타내는 타이머(예를 들어, periodic TAU timer), 사용자 단말(610)이 접속 중인 RAT, active timer 중 적어도 하나 이상을 포함할 수 있다. 또한 상기 메시지에는 사용자 단말(610) 대신 메시지를 수신하고 저장하는 기능을 적용해야 함을 나타내는 정보가 포함될 수 있다. 이 메시지를 수신한 SCS(650)는 이 정보들을 저장하고, 이 정보들에 따라 사용자 단말(610)의 현재 상태 및 저전력 상태가 지속될 시간을 파악할 수 있다.
한편, HSS 또는 IWF(630)는 상기 동작(즉, 메시지 버퍼링 기능)을 수행할지 여부를 결정하기 위해, 사용자 단말(610)이 접속 중인 RAT 정보를 활용할 수 있다. 특히, HSS 또는 IWF(630)은 특정 RAT, 예를 들면 전송률이 낮은 GERAN을 사용자 단말(610)이 사용 중인 경우에만 상기 기능을 요청할 수 있다. 또한, HSS 또는 IWF(630)는 사용자 단말(610)이 접속 중인 RAT의 종류에 따라 프로토콜 전환(즉, 사용자 단말(610)이 CoAP로 전송한 메시지를, HTTP 메시지로 전환하거나, 사용자 단말(610)에게 전송해야할 메시지의 프로토콜을 HTTP에서 CoAP로 전환) 기능 적용 요청 여부를 결정할 수도 있다.
681 단계에서 SCS(650)는 사용자 단말(610) 대신 메시지를 수신하는 기능을 적용하기 시작할 수 있다. 만약 SCS(650)가 수신한 사용자 단말(610) 상태 정보 제어 메시지에 active timer가 포함된 경우, SCS(650)는 상태 정보 제어 메시지를 수신했을 때 timer를 시작(start)하여, timer가 만료(expire)된 순간부터 상기 기능을 적용할 수 있다. 한편, SCS(650)는 상기 동작을 수행할지 여부를 결정하기 위해, 사용자 단말(610)이 접속 중인 RAT 정보를 활용할 수 있다. 특히, SCS(650)는 특정 RAT, 예를 들면 전송률이 낮은 GERAN을 사용자 단말(610)이 사용 중인 경우에만 상기 기능을 적용할 수 있다. 또한, SCS(650)는 사용자 단말(610)이 접속 중인 RAT의 종류에 따라 프로토콜 전환(즉, 사용자 단말(610)이 CoAP로 전송한 메시지를, HTTP 메시지로 전환하거나, 사용자 단말(610)에게 전송해야 할 메시지의 프로토콜을 HTTP에서 CoAP로 전환) 기능 적용 여부를 결정할 수 있다.
이후, SCS(650)는 683 단계에서 서버(660)로부터 사용자 단말(610)로 향하는 메시지를 수신할 수 있다. 상기 메시지는, 예를 들면 IP 통신을 사용하는 메시지일 수 있으며, 보다 구체적으로 COAP, MQTT, XMPP 또는 HTTP 프로토콜을 사용하는 메시지일 수 있다. 또한, 상기 메시지의 전송 code 또는 cause는 예를 들면 POST 또는 PUT일 수 있다. 이때, 상기 메시지의 목적지 주소는, 사용자 단말(610)의 주소(또는 외부 ID)일 수 있다.
한편, SCS(650)는 앞선 단계에서 수신되어 저장된 정보에 따라 사용자 단말(610) 대신 메시지 수신 동작을 수행해야 함을 알 수 있다. 즉, SCS(650)는 수신된 메시지의 목적지 주소 또는 외부 ID가 메시지 수신 기능을 적용해야 할 사용자 단말(610)의 것인지를 확인할 수 있다. 만약 사용자 단말(610) 대신 메시지 수신 기능이 필요한 경우, 685 단계에서 SCS(650)는 수신된 메시지를 저장할 수 있다. 한편, 실시 예에 따라 만약 사용자 단말(610)이 메시지 송수신에 사용하는 프로토콜과, 서버에서 사용하는 프로토콜이 서로 상이한 경우, 예를 들면 사용자 단말(610)은 CoAP 프로토콜을 사용하고, 서버는 HTTP 프로토콜을 사용하는 경우, SCS(650)는 프로토콜 변환을 수행할 수도 있다.
이후, SCS(650)는 687 단계에서 서버(660)에게 메시지를 수신했음을 알리는 메시지를 전송할 수 있다. 이 메시지는 앞선 서버(660)가 전송한 메시지와 동일한 프로토콜을 사용할 수 있으며, 전송 code 또는 cause는 예를 들면 200 OK로 설정될 수 있다. 또한 이 응답 메시지의 발신자 주소(또는 외부 ID)는, SCS(650)의 것이 아닌 사용자 단말(610)의 IP주소(또는 외부 ID)로 설정될 수 있다.
한편, 사용자 단말(610)은 active timer가 만료되면, 688 단계에서 저전력 모드로 동작하기 시작할 수 있다.
그리고, 689 단계에서 사용자 단말(610)은 저전력 모드에서 데이터를 송수신할 수 있는 상태로 전환할 수 있다. 이 상태 전환은 예를 들면 periodic TAU timer가 만료되어 TA update 과정을 수행하기 위한 것일 수 있다.
그리고, 691 단계에서 사용자 단말(610)은 TA update 또는 service 요청 메시지를 MME(620)에게 전달할 수 있다.
이에 따라 693 단계에서 MME(620)는 HSS 또는 IWF(630)에게 사용자 단말(610)의 상태가 저전력 모드에서 데이터를 송수신할 수 있는 모드로 전환되었음을 알릴 수 있다.
HSS 또는 IWF(630)는 695 단계에서 사용자 단말(610)의 상태 정보를 SCS(650)에게 알리기 위한 메시지를 전송할 수 있다. SCS(650)에게 사용자 단말(610)의 상태 정보가 전달되는 것은, 사용자 단말(610)이 저전력 모드로 상태가 변경되거나, 또는 저전력 상태에 있던 사용자 단말(610)의 상태가 다른 상태로 변경될 때 이루어질 수 있다. HSS 또는 IWF(630)는 SCS(650)에게 보내는 사용자 단말(610)의 상태 정보 메시지에 사용자 단말(610)의 외부 ID, 사용자 단말(610)의 IP 주소, 사용자 단말(610)의 현재 상태(저전력 모드인지 아닌지)에 대한 정보 중 적어도 하나가 포함될 수 있다. 또한, 실시 예에 따라 상기 메시지에는 사용자 단말(610) 대신 메시지를 수신해 두었던 메시지들을 사용자 단말(610)에게 전달해야 함을 나타내는 정보가 포함될 수 있다.
이후, 697 단계에서 SCS(650)는 상기 수신된 메시지에 따라 사용자 단말(610)의 상태가 변경되었음을 인지하고, 저장된 메시지를 사용자 단말(610)에게 전송하기 시작한다. 만약 사용자 단말(610)이 메시지 송수신에 사용하는 프로토콜과, 서버에서 사용하는 프로토콜이 서로 상이한 경우, 예를 들면 사용자 단말(610)은 CoAP 프로토콜을 사용하고, 서버는 HTTP 프로토콜을 사용하는 경우, SCS(650)는 프로토콜 변환을 수행할 수도 있다.
SCS(650)가 보내는 메시지는 예를 들면 IP 통신을 사용하는 메시지일 수 있으며, 보다 구체적으로 COAP, MQTT, XMPP 또는 HTTP 프로토콜을 사용하는 메시지일 수 있다. 또한, 상기 메시지의 전송 code 또는 cause는 예를 들면 POST 또는 PUT일 수 있다. 이 때, SCS(650)가 사용자 단말(610)에게 전송하는 메시지의 수신자/목적지 주소(IP 주소 또는 외부 ID)는 사용자 단말(610)의 것으로, 발신측 주소는 SCS(650)의 것으로 설정될 수 있다.
이후, 698 단계에서 사용자 단말(610)은 응답 메시지를 SCS(650)에게 보낼 수 있다. 이 응답 메시지는 IP 통신을 사용하는 메시지이며, 보다 구체적으로 COAP, MQTT, XMPP 또는 HTTP 프로토콜을 사용하는 메시지일 수 있다. 또한, 상기 메시지의 전송 code 또는 cause는 예를 들면 200 OK일 수 있다.
사용자 단말(610)로부터 응답 메시지를 수신한 SCS(650)는, 699 단계에서 응답 메시지를 실제 서버(메시지를 전송했던)(660)까지 다시 전달하지 않고 자체적으로 처리할 수 있다.
한편 상기 실시 예들 설명함에 있어 이미 attach 된 상태에서 사용자 단말(610)이 저전력 모드로 동작하기 위한 상황, 즉 TA update 과정을 수행하는 것을 기준으로 하였으나, 상기 사용자 단말(610) 및 네트워크의 동작은 사용자 단말(610)에 대한 attach 과정이 수행될 때도 적용될 수 있다. 만약 attach 과정 중에 상기 실시 예가 적용된다면, TA update request 메시지는 attach request 메시지, TAU accept 메시지는 attach accept 메시지로 바뀌어 적용될 수 있다.
도 7은 본 발명의 일 실시예에 따른 사용자 단말 대신 메시지를 수신하여 처리하는 동작의 흐름도의 다른 일 예를 나타내는 도면이다.
도 7을 참고하면, 사용자 단말(710)은 771 단계에서 단말 상태, 서비스 응용의 요청, 설정 정보 등에 따라 저전력 모드(PSM: Power Save Mode)로 상태를 변경하기로 결정할 수 있다.
사용자 단말(710)은 저전력 상태 사용을 요청하기 위해, 773 단계에서 TA update 요청 메시지를 MME(720)에게 전달할 수 있다. 한편, 사용자 단말(710)이 MME(720)에게 전송하는 TA update 요청 메시지에는 Periodic TAU timer, Active timer, 그리고 필요한 경우 active flag 중 적어도 하나가 포함될 수 있다. 만약 사용자 단말(710)이 저전력 상태에 들어가기 전에 보낼 메시지가 있으면, 사용자 단말(710)은 active flag를 설정하여 TA update 메시지를 보낼 수 있다. 또한, 실시 예에 따라 사용자 단말(710)은 명시적으로 사용자 단말(710) 대신 일시적으로 메시지를 수신하고 저장(buffering)하는 서비스를 요청하는 정보를 상기 TA update 요청 메시지에 포함할 수 있다. 또한, 실시 예에 따라 사용자 단말(710)은 낮은 우선순위 또는 전송지연에 민감하지 않은 단말의 특성을 나타내는 정보를 상기 TA update 요청 메시지에 포함하여 전달할 수도 있다.
MME(720)는 사용자 단말(710)의 TA update 요청에 따라 저전력 모드 사용 여부 및 적용 파라메터(Periodic TAU timer, active timer)를 결정할 수 있다. 그리고, 775 단계에서 MME(720)는 사용자 단말(710)에게 전송하는 TA update accept 메시지에, 상기 정보를 포함시킬 수 있다. MME(720)는 사용자 단말(710)의 요청(예를 들어, 낮은 우선순위 또는 전송지연에 민감하지 않은 단말의 특성을 나타내는 정보), 사용자 단말(710)이 가진 PDN 연결의 특성(APN, ARP 등), 내부 설정, 그리고 가입 정보 중 하나 이상을 바탕으로 사용자 단말(710)이 저전력 모드 동안 네트워크에서 메시지를 사용자 단말(710) 대신 수신해 저장해 두는 기능 적용 여부를 결정할 수 있다. 그리고, 실시 예에 따라 MME(620)는 그 결과를 명시적으로 TA update accept에 포함시켜 사용자 단말(710)에게 전달할 수 있다.
이후, 777 단계에서 사용자 단말(710)은 MME(720)로부터 수신한 TA update accept 메시지로부터 파라미터를 얻고, 이를 적용하여 저전력 모드로 진입하기 위한 동작을 수행할 수 있다. 특히, 사용자 단말(710)은 active timer를 시작하고, active timer가 만료(expire)될 때까지 저전력 모드로 상태를 변경하지 않고 대기할 수 있다.
한편, 기지국(750)과 MME(720) 사이에서 저전력 모드인 사용자 단말(710)을 위해 S1 또는 UE context release 과정이 수행될 수 있다. 780 단계에서 MME(720)는 SGW(730)에게 사용자 단말(710)의 상태 변경을 알리고 radio bearer를 해제하기 위한 메시지, 예를 들면 Release Access Bearers Request 메시지를 전송할 수 있다. 이 메시지에는 사용자 단말(710)이 저전력 상태로 동작함을 나타내는 정보, 사용자 단말(710)이 저전력 모드로 동작하는 시간, 사용자 단말(710)이 접속 중인 RAT, 그리고 상대적으로 긴 시간 동안 사용자 단말(710) 대신 메시지를 수신해 저장(buffering)해 주는 동작이 필요함을 나타내는 정보가 포함될 수 있다. 한편, MME(720)는 메시지 저장 기능을 요청할지 여부를 결정하기 위해, 사용자 단말(710)이 접속 중인 RAT 정보를 활용할 수 있다. 특히, MME(720)는 특정 RAT, 예를 들면 전송률이 낮은 GERAN을 사용자 단말(710)이 사용 중인 경우에만 상기 기능을 요청할 수 있다.
그리고, 781 단계에서 SGW(730)는 사용자 단말(710)에 대해 상대적으로 긴 시간 동안 메시지를 수신해 저장해 주는 동작을 적용할 수 있다. 만약 780 단계에서 수신된 메시지에 사용자 단말(710)이 저전력 모드로 동작하는 시간이 포함된 경우, SGW(730)는 메시지를 수신하면 timer를 시작하여, timer가 만료(expire)(즉, 저전력 모드로 동작하는 시간에 다다르면)가 될 때까지 상기 동작을 적용할 수 있다. 한편, SGW(730)는 상기 동작을 수행할지 여부를 결정하기 위해, 사용자 단말(710)이 접속 중인 RAT 정보를 활용할 수 있다. 특히, SGW(730)는 특정 RAT, 예를 들면 전송률이 낮은 GERAN을 사용자 단말(710)이 사용 중인 경우에만 상기 기능을 적용할 수 있다. 또한, SGW(730)는 사용자 단말(710)이 접속 중인 RAT의 종류에 따라 프로토콜 전환(즉, 사용자 단말(710)이 CoAP로 전송한 메시지를, HTTP 메시지로 전환하거나, 사용자 단말(710)에게 전송해야할 메시지의 프로토콜을 HTTP에서 CoAP로 전환) 기능 적용 여부를 결정할 수도 있다.
이후, 787 단계에서 SGW(730)는 서버로부터 사용자 단말(710)로 향하는 메시지를 수신할 수 있다. 상기 메시지는, GTP-U 또는 GRE 터널을 통해 PGW(740)로부터 수신되는 패킷에 포함될 수 있으며, 예를 들면 IP 통신을 사용하는 메시지일 수 있으며, 보다 구체적으로 COAP, MQTT, XMPP 또는 HTTP 프로토콜을 사용하는 메시지일 수 있다. 또한, 상기 메시지의 전송 code 또는 cause는 예를 들면 POST 또는 PUT일 수 있다. 상기 메시지의 목적지 주소는, 사용자 단말(710)의 주소(또는 외부 ID)일 수 있다.
한편, 사용자 단말(710)은 active timer가 만료되면, 778 단계에서 저전력 모드로 동작하기 시작한다.
이후, 783 단계에서 사용자 단말(710)은 저전력 모드에서 데이터를 송수신할 수 있는 상태로 전환할 수 있다. 이 상태 전환은 예를 들면 periodic TAU timer가 만료되어 TA update 과정을 수행하기 위한 것일 수 있다.
그리고, 785 단계에서 사용자 단말(710)은 TA update 또는 service 요청 메시지를 MME(720)에게 전달할 수 있다. 만약 메시지 송수신이 필요한 경우, 사용자 단말(710)은 TA update 요청 메시지에 active flag를 포함하여 전송할 수 있다.
그에 따라 789 단계에서 MME(720)는 사용자 단말(710)이 저전력 모드에서 일반 데이터를 송수신할 수 있는 상태로 변경이 되면, SGW(730)에 사용자 단말에 대해 수신되어 전송 대기중인 메시지가 있는지 확인하는 과정을 수행할 수 있다. 이는, 실시 예에 따라 사용자 단말(710)이 전송한 TA update 요청 메시지에 active flag가 설정되지 않은 경우에 한해 이루어지거나, 또는 SGW(730)가 MME(720)에게 사용자 단말(710)에 대해 수신된 메시지가 있음을 알리는 메시지, 즉 Downlink Data Notification 메시지를 수신한 것이 기반해 이루어질 수도 있다.
그리고, 791 단계에서 MME(720)는 SGW(730)에게 modify bearer request 메시지를 전송하며, 이 메시지에는 사용자 단말(710)에 대해 수신되어 저장된 메시지가 있는지를 묻는 정보가 포함될 수 있다.
793 단계에서 SGW(730)는 MME(720)에게 791 단계의 modify bearer request 메시지에 대한 응답 메시지, 예를 들면 modify bearer response 메시지를 전송할 수 있다. 이때, 이 메시지에는 사용자 단말(710)에 대해 수신되어 저장된 메시지가 있는지 여부를 나타내는 정보가 포함될 수 있다.
이후 TA update 또는 service request 과정을 진행하며, 794 단계에서 MME(720) 또는 기지국(750)은 사용자 단말(710)에게 TA update accept 메시지를 전송하면서 사용자 단말(710)에 대해 pending된 메시지가 있음을 나타내는 정보를 포함할 수 있다. 이 과정 중, 사용자 단말(710)이 TA update 요청 메시지에 active flag를 설정하지 않았음에도 MME(720)가 사용자 단말(710)이 active flag을 설정했던 것과 동일하게 UE context 및 radio bearer를 설정하는 과정이 수행될 수도 있다. 또는, 사용자 단말(710)이 TA update 요청 메시지에 active flag를 설정하지 않았는데, 상기 정보를 수신하면, 추가로 service request 과정을 수행할 수도 있다.
이후 795 단계에서 사용자 단말(710)은 connected mode가 되며, 797 단계에서 SGW(730)는 저장하고 있던 메시지를 사용자 단말(710)에게 전송할 수 있다.
한편 상기 실시 예들 설명함에 있어 이미 attach 된 상태에서 사용자 단말(710)이 저전력 모드로 동작하기 위한 상황, 즉 TA update 과정을 수행하는 것을 기준으로 하였으나, 상기 사용자 단말(710) 및 네트워크의 동작은 사용자 단말에 대한 attach 과정이 수행될 때도 적용될 수 있다. 만약 attach 과정 중에 상기 실시 예가 적용된다면, TA update request 메시지는 attach request 메시지, TAU accept 메시지는 attach accept 메시지로 바뀌어 적용될 수 있다.
도 8은 본 발명의 일 실시 예에 따른 사용자 단말이 저전력 모드를 사용할 때 메시지를 수신하는 방법의 흐름도의 또 다른 일 예를 나타내는 도면이다.
도 8을 참고하면, 사용자 단말(810)은 870 단계에서 저전력 모드로 진입할 수 있다. 이 과정은 본 발명의 상술한 도 3 내지 도 7과 관련된 부분에서 설명한 실시예에 포함된 단계들을 이용해 이루어질 수 있다. 한편, 이 과정 중 SGW(830)는 사용자 단말(810)이 유휴 상태(idle mode)임을 알게 된다.
사용자 단말(810)에 대해 외부망에서 패킷이 도착하면, 871 단계에서 PGW(840)는 이를 SGW(830)에게 전달할 수 있다.
SGW(830)는 사용자 단말(810)에 대한 패킷이 도착하면, 872 단계에서 MME(820)에게 downlink data notification 메시지를 전송할 수 있다.
이때, SGW(830)로부터 downlink data notification 메시지를 수신한 MME(820)는 873 단계에서 사용자 단말(810)이 저전력 모드라는 것을 확인할 수 있다. 또한, MME(820)는 사용자 단말(810)이 저전력 모드인 동안 사용자 단말(810)을 위해 상대적으로 긴 시간 동안 메시지를 수신하여 저장해주는 기능을 적용할지 여부를 판단할 수 있다.
이후, 875 단계에서 MME(820)는 SGW(830)에게 보내는 응답 메시지, 예를 들면 downlink data notification ack를 전송할 수 있다. 이때, 상기 메시지에는 사용자 단말(810)이 저전력 모드로 동작함을 나타내는 정보, 사용자 단말(810)이 저전력 모드로 동작하는 시간, 사용자 단말(810)이 접속 중인 RAT, 그리고 사용자 단말(810)에 대해 상대적으로 긴 시간 동안 메시지를 수신하여 저장해 두어야 함을 나타내는 정보 중 하나 이상이 포함될 수 있다. 한편, MME(820)는 메시지 저장 기능을 요청할지 여부를 결정하기 위해, 사용자 단말(810)이 접속 중인 RAT 정보를 활용할 수 있다. 특히, MME(820)는 특정 RAT, 예를 들면 전송률이 낮은 GERAN을 사용자 단말(810)이 사용 중인 경우에만 상기 기능을 요청할 수 있다.
그리고, 877 단계에서 SGW(830)는 상대적으로 긴 시간 동안 사용자 단말(810)에 대한 메시지를 수신해 저장해 주는 동작을 적용할 수 있다. 만약 875 단계에서 수신된 메시지에 사용자 단말(810)이 저전력 모드로 동작하는 시간이 포함된 경우, SGW(830)는 메시지를 수신하면 timer를 시작하여, timer가 만료(expire)(즉, 저전력 모드로 동작하는 시간에 다다르면)가 될 때까지 상기 동작을 적용할 수 있다. 한편, SGW(830)는 상기 동작을 수행할지 여부를 결정하기 위해, 사용자 단말(810)이 접속 중인 RAT 정보를 활용할 수 있다. 특히, SGW(830)는 특정 RAT, 예를 들면 전송률이 낮은 GERAN을 사용자 단말(810)이 사용 중인 경우에만 상기 기능을 적용할 수 있다. 또한, SGW(830)는 사용자 단말(810)이 접속 중인 RAT의 종류에 따라 프로토콜 전환(즉, 사용자 단말(810)이 CoAP로 전송한 메시지를, HTTP 메시지로 전환하거나, 사용자 단말(810)에게 전송해야 할 메시지의 프로토콜을 HTTP에서 CoAP로 전환) 기능 적용 여부를 결정할 수도 있다.
그리고, 879 단계에서 SGW(830)는 서버로부터 사용자 단말로 향하는 메시지를 수신할 수 있다. 상기 메시지는, GTP-U 또는 GRE 터널을 통해 PGW(840)로부터 수신되는 패킷에 포함될 수 있으며, 예를 들면 IP 통신을 사용하는 메시지일 수 있으며, 보다 구체적으로 COAP, MQTT, XMPP 또는 HTTP 프로토콜을 사용하는 메시지일 수 있다. 또한, 상기 메시지의 전송 code 또는 cause는 예를 들면 POST 또는 PUT일 수 있다. 상기 메시지의 목적지 주소는, 사용자 단말(810)의 주소(또는 외부 ID)일 수 있다.
한편, 사용자 단말(810)은 active timer가 만료되면, 저전력 모드로 동작하기 시작한다.
이후, 881 단계에서 사용자 단말(810)은 저전력 모드에서 데이터를 송수신할 수 있는 상태로 전환할 수 있다. 이 상태 전환은 예를 들면 periodic TAU timer가 만료되어 TA update 과정을 수행하기 위한 것일 수 있다.
그리고, 883 단계에서 사용자 단말(810)은 TA update 또는 service 요청 메시지를 MME(820)에게 전달할 수 있다. 만약 메시지 송수신이 필요한 경우, 사용자 단말(810)은 TA update 요청 메시지에 active flag를 포함하여 전송할 수 있다.
그에 따라 884 단계에서 MME(820)는 사용자 단말(810)이 저전력 모드에서 일반 데이터를 송수신할 수 있는 상태로 변경이 되면, SGW(830)에 사용자 단말에 대해 수신되어 전송 대기중인 메시지가 있는지 확인하는 과정을 수행할 수 있다. 이는, 실시 예에 따라 사용자 단말(810)이 전송한 TA update 요청 메시지에 active flag가 설정되지 않은 경우에 한해 이루어지거나, 또는 SGW(830)가 MME(820)에게 사용자 단말(810)에 대해 수신된 메시지가 있음을 알리는 메시지, 즉 Downlink Data Notification 메시지를 수신한 것이 기반해 이루어질 수도 있다.
그리고, 885 단계에서 MME(820)는 SGW(830)에게 modify bearer request 메시지를 전송하며, 이 메시지에는 사용자 단말(810)에 대해 수신되어 저장된 메시지가 있는지를 묻는 정보가 포함될 수 있다.
886 단계에서 SGW(830)는 MME(820)에게 885 단계의 modify bearer request 메시지에 대한 응답 메시지, 예를 들면 modify bearer response 메시지를 전송할 수 있다. 이때, 이 메시지에는 사용자 단말(810)에 대해 수신되어 저장된 메시지가 있는지 여부를 나타내는 정보가 포함될 수 있다.
이후 TA update 또는 service request 과정을 진행하며, 887 단계에서 MME(820) 또는 기지국(850)은 사용자 단말(810)에게 TA update accept 메시지를 전송하면서 사용자 단말(810)에 대해 pending된 메시지가 있음을 나타내는 정보를 포함할 수 있다. 이 과정 중, 사용자 단말(810)이 TA update 요청 메시지에 active flag를 설정하지 않았음에도 MME(820)가 사용자 단말(810)이 active flag을 설정했던 것과 동일하게 UE context 및 radio bearer를 설정하는 과정이 수행될 수도 있다. 또는, 사용자 단말(810)이 TA update 요청 메시지에 active flag를 설정하지 않았는데, 상기 정보를 수신하면, 추가로 service request 과정을 수행할 수도 있다.
이후 888 단계에서 사용자 단말(810)은 connected mode가 되며, 889 단계에서SGW(830)는 저장하고 있던 메시지를 사용자 단말(810)에게 전송할 수 있다.
한편 상기 실시 예들 설명함에 있어 이미 attach 된 상태에서 사용자 단말(810)이 저전력 모드로 동작하기 위한 상황, 즉 TA update 과정을 수행하는 것을 기준으로 하였으나, 상기 사용자 단말(810) 및 네트워크의 동작은 사용자 단말에 대한 attach 과정이 수행될 때도 적용될 수 있다. 만약 attach 과정 중에 상기 실시 예가 적용된다면, TA update request 메시지는 attach request 메시지, TAU accept 메시지는 attach accept 메시지로 바뀌어 적용될 수 있다.
이상에서는 사용자 단말이 저전력 모드로 들어갔을 때, 사용자 단말에게 메시지 전달이 필요한 경우, 즉 하향링크 메시지가 발생했을 때 불필요한 전송 시도 또는 메시지 전송 누락을 방지하는 방법에 대하여 살펴보았다.
한편, 사용자 단말이 저전력 모드로 동작하여 상대적으로 오랜 기간 동안 데이터를 송수신하지 않으면, 네트워크(NAT)는 사용자 단말에게 할당한 IP 주소 정보를 해제하거나 회수할 수 있다. 이 경우, 사용자 단말에게 외부 망에서 접근할 수 있는 주소가 없어지므로, 저전력 모드의 사용자 단말에게 메시지가 전달될 수 없으며, 사용자 단말이 저전력 모드에서 비-저전력 모드로 상태를 바꿨을 때 IP 주소를 재등록 하는 과정을 필요로 하게 된다.
이하에서는, 상기 문제를 해결하기 위해 사용자 단말이 저전력 모드로 동작하면, 사용자 단말 대신 네트워크의 한 노드, 예를 들면 SCS가 사용자 단말 대신 메시지, 예를 들면 keep-alive 메시지를 주기적으로 전송하여 저전력 모드로 동작하는 사용자 단말에 대한 IP 주소가 계속 유효할 수 있도록 하는 방법에 대해서 살펴보도록 한다.
도 9는 본 발명의 일 실시예에 따른 사용자 단말에 대한 연결 상태를 유지하기 위한 동작의 흐름도의 일 예를 나타내는 도면이다.
도 9를 참고하면, 사용자 단말(910)은 971 단계에서 단말 상태, 서비스 응용의 요청, 설정 정보 등에 따라 저전력 모드(PSM: Power Save Mode)로 상태를 변경하기로 결정할 수 있다.
사용자 단말(910)은 저전력 상태 사용을 요청하기 위해, 973 단계에서 TA update 요청 메시지를 MME(920)에게 전달할 수 있다. 한편, 사용자 단말(910)이 MME(920)에게 전송하는 TA update 요청 메시지에는 Periodic TAU timer, Active timer, 그리고 필요한 경우 active flag 중 적어도 하나가 포함될 수 있다. 만약 사용자 단말(910)이 저전력 상태에 들어가기 전에 보낼 메시지가 있으면, 사용자 단말(910)은 active flag를 설정하여 TA update 메시지를 보낼 수 있다. 또한, 실시 예에 따라 사용자 단말(910)은 명시적으로 사용자 단말(910) 대신 네트워크에서 IP 주소를 유지하기 위한 메시지 전송을 수행하는 기능 사용을 요청하는 정보를 상기 TA update 요청 메시지에 포함할 수 있다. 또한, 실시 예에 따라 사용자 단말(910)은 낮은 우선순위 또는 전송지연에 민감하지 않은 단말의 특성을 나타내는 정보를 상기 TA update 요청 메시지에 포함하여 전달할 수도 있다.
MME(920)는 사용자 단말(910)의 TA update 요청에 따라 저전력 모드 사용 여부 및 적용 파라메터(Periodic TAU timer, active timer)를 결정할 수 있다. 그리고, 975 단계에서 MME(920)는 사용자 단말(910)에게 전송하는 TA update accept 메시지에, 상기 정보를 포함시킬 수 있다. MME(920)는 사용자 단말(910)의 요청(예를 들어, 낮은 우선순위 또는 전송지연에 민감하지 않은 단말의 특성을 나타내는 정보), 사용자 단말(910)이 가진 PDN 연결의 특성(APN, ARP 등), 내부 설정, 그리고 가입 정보 중 하나 이상을 바탕으로 사용자 단말(910)에 대해 사용자 단말(910) 대신 네트워크에서 IP 주소 유지를 위한 메시지 전송을 수행하는 기능 적용 여부를 결정할 수 있다. 그리고, 실시 예에 따라 MME(920)는 그 결과를 명시적으로 TA update accept에 포함시켜 사용자 단말(910)에게 전달할 수 있다.
이후, 980 단계에서 사용자 단말(910)은 MME(920)로부터 수신한 TA update accept 메시지로부터 파라미터를 얻고, 이를 적용하여 저전력 모드로 진입하기 위한 동작을 수행할 수 있다. 특히, 사용자 단말(910)은 active timer를 시작하고, active timer가 만료(expire)될 때까지 저전력 모드로 상태를 변경하지 않고 대기할 수 있다.
한편, 977 단계에서 MME(920)는 HSS 또는 IWF(930)에게 사용자 단말(910)이 저전력 모드로 전환되었음을 알릴 수 있다. 이때, 실시 예에 따라 MME(920)는 HSS 또는 IWF(930)에게 상기 사용자 단말(910)의 식별자, IP 주소, 그리고 저전력 모드의 지속 시간 정보, active timer 중 하나 이상의 정보를 함께 전달할 수 있다. HSS 또는 IWF(930)는 MME(920)로부터 수신된 정보를 저장하고, 이후 SCS(940)로부터 사용자 단말(910)에 대한 정보 요청되거나, 또는 사용자 단말(910)의 상태가 변경될 때 마다, 저장된 정보 중 하나 이상을 SCS(940)에게 전달해 줄 수 있다.
이후, 979 단계에서 HSS 또는 IWF(930)는, 사용자 단말(910)의 상태 정보를 SCS(940)에게 알리기 위한 메시지를 전송할 수 있다. 실시 예에 따라 SCS(940)에게 사용자 단말(910)의 상태 정보가 전달되는 것은, 사용자 단말(910)이 저전력 모드로 상태가 변경되거나, 또는 저전력 상태에 있던 사용자 단말(910)의 상태가 다른 상태로 변경될 때 이루어질 수 있다. HSS 또는 IWF(930)는 SCS(940)에게 보내는 사용자 단말(910)의 상태 정보 메시지에 사용자 단말(910)의 외부 ID, 사용자 단말(910)의 IP 주소, 사용자 단말(910)의 현재 상태(저전력 모드인지 아닌지), 저전력 모드가 적용되는 시간을 나타내는 타이머(예를 들어, periodic TAU timer) 중 적어도 하나 이상을 포함할 수 있다. 또한, 상기 메시지에는 사용자 단말(910)의 저전력 모드 동안 사용자 단말(910) 대신 IP 주소를 유지하기 위한 메시지를 전송하는 기능을 적용해야 함을 나타내는 정보가 포함될 수 있다. 또한, 실시 예에 따라 상기 메시지는 active timer가 포함될 수 있다. 그리고, 만약 active timer가 포함된 경우 SCS(940)는 메시지를 수신하면 active timer를 시작(start)하고, active timer가 만료(expire)되는 순간부터 메시지 대신 전송 기능을 적용할 수 있다. 이 메시지를 수신한 SCS(940)는 이 정보들을 저장하고, 이 정보들에 따라 사용자 단말(910)의 현재 상태 및 저전력 상태가 지속될 시간을 파악할 수 있다.
한편, 980 단계에서 사용자 단말(910)은 자신의 저전력 모드 동작 동안, 네트워크에서 keep-alive 메시지 전송을 대신해주는 기능이 필요한지 판단할 수 있다. 이는, 사용자 단말(910)의 내부 설정 정보를 기반으로 이루어지거나, 또는 상기 TA update accept 또는 그 전에 수신된 attach accept 메시지에 포함된 정보(예를 들면, 사용자 단말(910) 대신 네트워크에서 keep-alive 메시지 전송을 수행하는 기능에 대한 지원 여부)에 기반하여 이루어질 수 있다. 사용자 단말(910)은 만약 상기 기능 사용이 가능하면 9841 단계에서 active timer가 만료되기 전에 상기 메시지를 SCS(940)에게 전송할 수 있다. 상기 메시지는, 예를 들면 IP 통신을 사용하는 메시지일 수 있으며, 보다 구체적으로 TCP, COAP, MQTT, XMPP 또는 HTTP 프로토콜을 사용하는 메시지일 수 있다. 또한, 상기 메시지의 전송 code 또는 cause는 예를 들면 POST일 수 있다. 상기 메시지에는 TCP keep-alive 메시지가 포함될 수 있다. 상기 메시지에는 사용자 단말(910) 대신 전송 동작을 요청하는 정보, 그리고 실제 전송해야 할 메시지, 그리고 사용자 단말(910)의 external ID 중 하나 이상이 포함될 수 있다. 도시되지 않았지만, 실시 예에 따라 상기 메시지는 PGW를 거쳐 SCS(940)까지 전달될 수 있다. 상기 메시지의 목적지 주소는, 미리 수신한 SCS(950)의 주소로 설정될 수 있다.
상기와 같이 SCS(940)는 사용자 단말(910)로부터 메시지를 수신할 수 있다.
그리고, SCS(940)는 앞선 단계에서 수신된 메시지에 따라 사용자 단말(910) 대신 Keep-alive 메시지 전송 동작을 수행해야 함을 알 수 있다. 한편, 실시 예에 따라 SCS(940)는 사용자 단말(910) 및 실제 서버를 구분하기 위해, 사용자 단말(910)이 보낸 메시지로부터 소스 주소(Source IP 주소)와 포트, 실제 목적지 주소(destination IP 주소)와 포트를 저장할 수 있다. 사용자 단말(910)이 외부 ID(external ID)를 알린 경우, SCS(940)는 이를 저장할 수 있다.
이후, 984 단계에서 SCS(940)는 사용자 단말(910)에게 메시지를 수신했음을 알리는 메시지를 전송할 수 있다. 이 메시지는 앞선 사용자 단말(910)이 전송하는 메시지와 동일한 프로토콜을 사용할 수 있으며, 전송 code 또는 cause는 예를 들면 200 OK로 설정될 수 있다. 한편, 도시되지 않았지만 실시 예에 따라 상기 메시지는 PGW를 거쳐 사용자 단말(910)에게 전송될 수 있다.
그리고, SCS(940)는 HSS 또는 IWF(930)로부터 979 단계에서 수신된 사용자 단말(910)의 상태 정보에 따라 사용자 단말(910) 대신 메시지를 전송하는 동작을 수행할지 여부를 결정할 수 있다. 만약, HSS 또는 IWF(930)로부터 수신된 메시지에 사용자 단말(910)이 저전력 모드로 동작하는 시간이 포함된 경우, SCS(940)는 이에 시간에 따라 timer를 시작하고, timer가 만료될 때까지 사용자 단말(910) 대신 메시지를 전송하는 동작을 수행할 수 있다.
한편, 사용자 단말(910)은 active timer가 만료되면, 985 단계에서 저전력 모드로 동작하기 시작할 수 있다.
그리고, SCS(940)는 987 단계 및 988 단계에서 주기적으로 사용자 단말(910)을 위한 keep-alive 메시지를 생성하여 전송할 수 있다. 이 메시지는 예를 들면 IP 통신을 사용하는 메시지일 수 있으며, 보다 구체적으로 TCP, COAP, MQTT, XMPP 또는 HTTP 프로토콜을 사용하는 메시지일 수 있다. 이 때 전송되는 메시지는 사용자 단말(910)로부터 수신한 것이거나 또는 SCS(940)가 직접 생성한 것일 수 있다. 또한, 상기 메시지의 송신자 주소(IP주소/포트) 또는 external ID는, SCS(940)의 것이 아닌 사용자 단말(910)의 주소 또는 external ID로 설정될 수 있다.
한편 상기 실시 예들 설명함에 있어 이미 attach 된 상태에서 사용자 단말(910)이 저전력 모드로 동작하기 위한 상황, 즉 TA update 과정을 수행하는 것을 기준으로 하였으나, 상기 사용자 단말(910) 및 네트워크의 동작은 사용자 단말(910)에 대한 attach 과정이 수행될 때도 적용될 수 있다. 만약 attach 과정 중에 상기 실시 예가 적용된다면, TA update request 메시지는 attach request 메시지, TAU accept 메시지는 attach accept 메시지로 바뀌어 적용될 수 있다.
이상에서는, 사용자 단말이 저전력 모드로 동작하면, 사용자 단말 대신 네트워크의 한 노드, 예를 들면 SCS가 사용자 단말 대신 메시지, 예를 들면 keep-alive 메시지를 주기적으로 전송하여 저전력 모드로 동작하는 사용자 단말에 대한 IP 주소가 계속 유효할 수 있도록 하는 방법에 대해서 살펴보았다.
한편, 사용자 단말이 특정 망에서 접속하여 PDN 연결을 생성하거나 생성된 PDN 연결의 context를 수정하는 과정에서, 사업자 망은 해당 PDN 연결이 WLAN(Wireless LAN)으로 오프로딩 가능한지 여부 결정하여 사용자 단말에게 알릴 수 있다. 그리고, 사용자 단말은 사업자 망으로부터 수신된 정보에 따라, PDN 연결을 WLAN으로 오프로딩하는 것이 가능한지 판단할 수 있다.
그런데, 만약 사용자 단말이 다른 망 또는 영역으로 이동한 경우, 사용자 단말에 대한 WLAN 오프로딩 허용 여부는 새로 갱신되어야 한다. 이는, 사업자 또는 영역 별로 WLAN 오프로딩에 대한 망 구성 또는 설정이 다를 수 있기 때문이다. 특히 사용자 단말이 등록한 RAT(Radio Access Technology)가 바뀌는 경우, 예를 들면 E-UTRAN에서 UTRAN 또는 UTRAN에서 E-UTRAN으로 변경되는 경우, 이러한 동작이 필요할 수 있다.
도 10은 사용자 단말이 새로운 위치 등록 또는 RAT를 변경하였을 때, WLAN 오프로딩 허용 여부를 알리는 방법의 흐름도의 일 예를 나타낸 도면이다.
도 10을 참고하면, 1070 단계에서 사용자 단말(1010)은 MME 또는 SGSN(1020)에게 TA update(E-UTRAN인 경우) 또는 RA update(UTRAN/GERAN인 경우) 요청 메시지를 전송할 수 있다.
신규 MME 또는 SGSN(1020)은, 사용자 단말(1010)이 제공한 사용자 단말(1010) 식별자 또는 코어망 노드 식별자를 기반으로 사용자 단말(1010)이 원래 등록되었던 MME 또는 SGSN(1025)을 파악하고, 1071 단계에서 이 노드로 사용자 단말(1010)에 대한 정보를 요청하는 메시지, 예를 들면 context request 메시지를 전송할 수 있다.
이에 따라, 1075 단계에서 예전 MME 또는 SGSN(1025)은 사용자 단말(1010)에 대한 컨택스트(UE context)를 신규 MME 또는 SGSN(1020)에게 전달해 줄 수 있다. 이 때 사용되는 메시지는 context response 메시지일 수 있다. 상기 context response 메시지에는 사용자 단말(1010)의 PDN 연결에 대해 WLAN 오프로딩(offloading)이 허용되는지 여부, 즉 WLAN offloadability가 포함되어 전송될 수 있다.
보다 구체적으로, 예전 MME 또는 SGSN(1025)은, 사용자 단말(1010)에 대해 UE context 또는 PDN context의 하나로 저장되어 있던 PDN 연결(들)에 대한 WLAN 오프로딩 허용/비허용 여부를, 신규 MME 또는 SGSN(1020)에게 보내는 context response메시지의 PDN connection IE(Information Element)에 WLAN offloadability IE를 포함시켜 전달할 수 있다. 한편, 예전 MME 또는 SGSN(1025)이 전송하는 context response 메시지에는, 사용자 단말(1010)과의 사이에서 이미 생성된 PDN 연결의 WLAN offloadability 뿐만 아니라, APN(Access Point Name)별로 WLAN 오프로딩이 허용되는지 여부를 나타내는 정보가 추가로 포함되어 신규 MME 또는 SGSN(1020)에게 전달될 수도 있다. 특히 상기 정보는 사용자 단말(1010)에 대한 UE context 또는 가입정보(Subscription data)의 일부일 수 있다.
신규 MME 또는 SGSN(1020)은 예전 MME 또는 SGSN(1025)으로부터 수신한 context response 메시지에 따라, 1077 단계에서 사용자 단말(1010)이 현재 가지고 있는 PDN 연결에 대한 WLAN offloadability와, APN별로 WLAN 오프로딩이 허용되는지 여부를 알 수 있다. 신규 MME 또는 SGSN(1010)는 이 정보를 자신의 설정(local configuration)에 따라 갱신할 수 있다. 만약 예전 MME 또는 SGSN(1025)이 보낸 정보와 자신의 설정(local configuration)이 상이한 경우, 신규 MME 또는 SGSN(1020)은 자신의 설정을 우선해 사용자 단말(1010)의 WLAN offloadability를 갱신할 수 있다.
그리고 1079 단계에서 신규 MME 또는 SGSN(1020)은 사용자 단말(1010)에게 TA update 또는 RA update 수락(accept) 메시지를 전송할 수 있다. 이 메시지에는 사용자 단말(1010)의 PDN connection(들)에 대한 갱신된 WLAN offloadability 정보가 포함될 수 있다.
보다 구체적으로, 신규 MME 또는 SGSN(1020)은, TA update 또는 RA update 수락 메시지에 PDN 연결의 대표 EPS bearer ID 별로 WLAN offloadability를 설정한 정보를 포함해 사용자 단말(1010)에게 전달할 수 있다.
신규 MME 또는 SGSN(1020)으로부터 TA update 또는 RA update 수락 메시지를 수신한 사용자 단말(1010)은, 만약 상기 메시지에 갱신된 WLAN offloadability 정보가 포함된 경우, 이 정보에 따라 저장된 정보를 갱신하여야 한다.
한편, 신규 MME 또는 SGSN은 TA/RA update 과정 중 WLAN offloadability 갱신이 필요할 때, 이를 TA/RA update 수락 메시지로 알리는 것이 아니라, 별도의 SM(Session Management) 과정을 시작(initiate)해서 사용자 단말에게 알릴 수도 있다.
도 11은 본 발명의 일 실시 예에 따른 사용자 단말에 대해 WLAN offloadability 갱신을 수행하는 과정의 흐름도의 다른 일 예를 나타내는 도면이다.
도 11을 참고하면, 1171 단계에서 사용자 단말(1110)은 MME 또는 SGSN(1120)에게 TA update (E-UTRAN인 경우) 또는 RA update (UTRAN/GERAN인 경우) 요청 메시지를 전송할 수 있다.
신규 MME 또는 SGSN(1120)은, 사용자 단말(1110)이 제공한 사용자 단말 식별자 또는 코어망 노드 식별자를 기반으로 사용자 단말(1110)이 원래 등록되었던 MME 또는 SGSN(1125)을 파악할 수 있다. 그리고, 1173 단계에서 신규 MME 또는 SGSN(1120)은 이 노드(1125)에게 사용자 단말(1110)에 대한 정보를 요청하는 메시지, 예를 들면 context request 메시지를 전송할 수 있다.
이에 따라, 1175 단계에서 예전 MME 또는 SGSN(1125)은 사용자 단말(1110)에 대한 컨택스트(UE context)를 신규 MME 또는 SGSN(1120)에게 전달해 줄 수 있다. 이 때 사용되는 메시지는 context response 메시지일 수 있다. 상기 context response 메시지에는 사용자 단말(1110)의 PDN 연결에 대해 WLAN offloading이 허용되는지 여부, 즉 WLAN offloadability가 포함되어 전송될 수 있다.
보다 구체적으로, 예전 MME 또는 SGSN(1125)은, 사용자 단말(1110)에 대해 UE context 또는 PDN context의 하나로 저장되어 있던 PDN 연결(들)에 대한 WLAN 오프로딩 허용/비허용 여부를, 신규 MME 또는 SGSN(1120)에게 보내는 context response메시지의 PDN connection IE(Information Element)에 WLAN offloadability IE를 포함시켜 전달할 수 있다. 한편, 예전 MME 또는 SGSN(1125)이 전송하는 context response 메시지에는, 사용자 단말(1110)과의 사이에서 이미 생성된 PDN 연결의 WLAN offloadability 뿐만 아니라, APN(Access Point Name)별로 WLAN 오프로딩이 허용되는지 여부를 나타내는 정보가 추가로 포함되어 신규 MME 또는 SGSN(1120)에게 전달될 수도 있다. 특히 상기 정보는 사용자 단말(1110)에 대한 UE context 또는 가입정보(Subscription data)의 일부일 수 있다.
신규 MME 또는 SGSN(1120)은 예전 MME 또는 SGSN(1125)으로부터 수신한 context response 메시지에 따라, 1177 단계에서 사용자 단말(1110)이 현재 가지고 있는 PDN 연결에 대한 WLAN offloadability와, APN별로 WLAN 오프로딩이 허용되는지 여부를 알 수 있다. 신규 MME 또는 SGSN(1120)는 이 정보를 자신의 설정(local configuration)에 따라 갱신할 수 있다. 만약 예전 MME 또는 SGSN(1125)이 보낸 정보와 자신의 설정(local configuration)이 상이한 경우, 신규 MME또는 SGSN(1120)은 자신의 설정을 우선해 사용자 단말(1110)의 WLAN offloadability를 갱신할 수 있다.
그리고, 신규 MME 또는 SGSN(1120)은 사용자 단말(1110)에 대해 WLAN offloadability 정보를 갱신하기 위한 과정을 시작할 수 있다. 신규 MME 또는 SGSN(1120)은, SGW(1130)에게 사용자 단말(1110)에 대한 bearer 정보를 수정하기 위한 메시지, 예를 들면 modify bearer command 메시지를 전달할 수 있다. 그리고, 이 메시지에는 사용자 단말(1110)에 대해 대상이 되는 bearer의 WLAN offloadability 정보가 포함될 수 있다. 상기 WLAN offloadability 정보는 bearer context의 하나로 포함될 수 있다. 만약 사용자 단말(1110)에 대해 PDN 연결이 여러 개 있거나, 또는 하나의 PDN 연결에 두 개 이상의 EPS bearer가 포함되는 경우, 신규 MME 또는 SGSN(1120)은 대상이 되는 PDN 연결의 대표 bearer(즉, default bearer)에 대한 정보로 상기 WLAN offloadability를 포함하여 전송할 수 있다.
1180 단계에서 SGW(1130)는 신규 MME 또는 SGSN(1120)으로부터 수신된 정보를 PGW(1140)까지 전달할 수 있다. 이 때는 modify bearer command 메시지가 사용될 수 있으며, 상기 1179 단계에서 수신한 정보를 포함하여 PGW(1140)에게 전송할 수 있다.
1181 단계에서 PGW(1140)는 SGW(1130)에게 Update Bearer Request 메시지를 전송하며, 이 메시지에는 대상이 되는 PDN 연결 또는 EPS bearer의 WLAN offloadability가 포함될 수 있다.
1182 단계에서 SGW(1130)는 상기 정보를 동일한 메시지를 이용해 신규 MME 또는 SGSN(1120)에게 전달할 수 있다.
신규 MME 또는 SGSN(1120)은, 1183 단계에서 WLAN offloadability를 갱신하기 위해 사용자 단말(1110)에게 SM 메시지를 전송할 수 있다. 이 메시지는 modify EPS bearer context request 메시지 또는 modify PDP context request 메시지일 수 있으며, 이 메시지에는 대상이 되는 bearer의 WLAN offloadability가 포함될 수 있다. 만약, 사용자 단말(1110)이 여러 개의 PDN 연결을 가지고 있거나, 또는 하나의 PDN 연결에 두 개 이상의 EPS bearer를 포함하고 있는 경우, 신규 MME 또는 SGSN(1120)은 대상이 되는 PDN 연결의 대표 EPS bearer(즉, default bearer)를 대상으로 상기 메시지를 전송하며, 따라서 상기 메시지에는 대표 EPS bearer의 식별자가 포함될 수 있다. 또한, 상기 메시지에 포함되는 WLAN offloadability 정보는 New QoS IE에 포함되거나, 또는 별도의 WLAN offloadability IE에 포함될 수 있다. 신규 MME 또는 SGSN(1120)이 상기 동작을 수행하는 것은, SGW(1130)/PGW(1140)와의 시그널링(즉 단계 X~X) 없이도 수행될 수 있다.
한편, 본 발명의 다른 한 변형으로, 신규 MME 또는 SGSN(1120)은 사용자 단말(1110)에 대해 WLAN offloadability 갱신이 필요할 때, 사용자 단말(1110)에게 SM 메시지, 예를 들면 ESM status 또는 ESM information 메시지를 사용할 수 있다. 이 메시지에는 대상이 되는 bearer의 WLAN offloadability가 포함될 수 있다. 만약, 사용자 단말(1110)이 여러 개의 PDN 연결을 가지고 있거나, 또는 하나의 PDN 연결에 두 개 이상의 EPS bearer를 포함하고 있는 경우, 신규 MME 또는 SGSN은 대상이 되는 PDN 연결의 대표 EPS bearer(즉, default bearer)를 대상으로 상기 메시지를 전송하며, 따라서 상기 메시지에는 대표 EPS bearer의 식별자가 포함될 수 있다. 또한, 상기 메시지에 포함되는 WLAN offloadability 정보는 New QoS IE에 포함되거나, 또는 별도의 WLAN offloadability IE에 포함될 수 있다. 이 과정 중, 신규 MME 또는 SGSN은, SGW/PGW와의 시그널링을 생략할 수도 있다.
신규 MME 또는 SGSN(1120)으로부터 SM 메시지를 수신한 사용자 단말(1110)은, 185 단계에서 만약 상기 메시지에 갱신된 WLAN offloadability 정보가 포함된 경우, 이 정보에 따라 저장된 정보를 갱신하여야 한다.
한편, 만약 사업자 망에 E-UTRAN과 UTRAN이 공존하는 경우, E-UTRAN과 UTRAN 각각에 대해 WLAN offloading 기능이나 설정이 상이할 수 있다. 예를 들면, E-UTRAN은 WLAN offloading 기능을 지원하는데, UTRAN은 WLAN offloading 기능을 지원하지 않는 경우가 있을 수 있다. 만약 이 경우 사용자 단말이 E-UTRAN과 UTRAN 사이에서 이동하는 경우(즉, 사용자 단말이 RAT가 E-UTRAN과 UTRAN 둘 중 하나에서, 다른 하나로 변경되는 경우), 사용자 단말의 PDN 연결(또는 PDP context)의 WLAN offloadability는 새롭게 갱신되어야 할 필요가 있다.
따라서, 사용자 단말에 대해 ISR(Idle Mode Signaling Reduction)을 적용할지 여부를 결정할 때는, 사용자 단말이 WLAN offloading을 사용할지 여부와, E-UTRAN과 UTRAN의 WLAN offloading 지원 여부를 고려해야 한다. 만약, 사용자 단말이 Attach 또는 TA/RA update 요청을 보냈을 때, MME 또는 SGSN은 사용자 단말에 대해 ISR을 적용할 지 여부를 결정해야 한다. 이 과정 중에, MME(또는 SGSN)은, SGSN(또는 MME)에게 보내는 context 관련 메시지(context request/response/response ack) 메시지에, 자기 망에서 WLAN offloading을 지원하는지 여부를 나타내는 정보를 포함시킬 수 있으며, 이를 수신한 SGSN(또는 MME)는, MME(또는 SGSN)으로 보내는 context 관련 메시지에, 마찬가지로 자기 망에서 WLAN offloading을 지원하는지 여부를 나타내는 정보를 포함시킬 수 있다.
사용자 단말에 대해 ISR은 두 망의 WLAN offloading 지원 여부가 일치할 때만 활성화 될 수 있다. 두 망의 WLAN offloading 지원 일치 여부를 확인하기 위해서는 context 교환 메시지가 사용된다. 즉, 상기 예에서, 만약 MME(또는 SGSN)으로부터 context response메시지를 수신한 SGSN(또는 MME)는, MME(또는 SGSN)가 상기 메시지로 지시한 WLAN offloading 기능 지원 여부가 자신의 WLAN offloading 기능 지원 여부와 일치하는 경우에만, ISR을 적용할 수 있으며 그 결과에 따라 context response ack 메시지에 ISR supported/activated indicator를 포함할지를 결정한다. 만약 두 망의 WLAN offloading 지원 여부가 서로 상이하거나 같음을 확인할 수 없는 경우, 사용자 단말에 대해서 ISR은 활성화 될 수 없다.
도 12는 본 발명의 일 실시 예에 따른 MME의 블록 구성도이다.
도 12를 참고하면, MME는 통신부(1210) 및 상기 MME의 전반적인 동작을 제어하는 제어부(1230)를 포함할 수 있다. 또한, 상기 MME는 저장부(1220)를 더 포함할 수 있다.
상기 저장부(1220)는 MME의 동작에 필요한 프로그램 및 데이터 등을 저장할 수 있다.
MME의 제어부(1230)는 상술한 실시 예들 중 어느 하나의 동작을 수행하도록 MME를 제어한다. 예를 들면, 사용자 단말로부터, 상기 사용자 단말의 저전력 모드 상태에서 상기 사용자 단말 대신 다른 네트워크 엔티티에서 메시지 송수신을 수행할 것을 요청하는 정보를 포함하는 저전력 모드 요청 메시지를 수신하고, 상기 사용자 단말에게 저전력 모드 사용 여부 및 적용 파라메터를 송신하고, 상기 사용자 단말의 저전력 모드 상태에서 상기 사용자 단말 대신 다른 네트워크 엔티티에서 메시지 송수신을 수행할 것을 요청하는 정보를 홈 가입자 서버(HSS: Home Subscriber Server)에게 전송하도록 제어할 수 있다.
상기 통신부(1210)는 상술한 실시 예들 중 어느 하나에 따른 신호를 송수신할 수 있다.
도 13은 본 발명의 일 실시 예에 따른 사용자 단말의 블록 구성도이다.
도 13을 참고하면, 사용자 단말은 통신부(1310) 및 상기 사용자 단말의 전반적인 동작을 제어하는 제어부(1330)를 포함할 수 있다. 또한, 상기 사용자 단말은 저장부(1320)를 더 포함할 수 있다.
상기 저장부(1320)는 사용자 단말의 동작에 필요한 프로그램 및 데이터 등을 저장할 수 있다.
사용자 단말의 제어부(1330)는 상술한 실시 예들 중 어느 하나의 동작을 수행하도록 사용자 단말을 제어한다. 예를 들면, 상기 사용자 단말의 저전력 모드 상태에서 상기 사용자 단말 대신 다른 네트워크 엔티티에서 메시지 송수신을 수행할 것을 요청하는 정보를 포함하는 저전력 모드 요청 메시지를 이동성 관리 엔티티(MME: Mobility Management Entity)에게 전송하고, 상기 MME로부터 저전력 모드 사용 여부 및 적용 파라메터를 수신하고, 상기 수신한 파라메터에 따라 저전력 모드로 동작하도록 제어할 수 있다.
상기 통신부(1310)는 상술한 실시 예들 중 어느 하나에 따른 신호를 송수신할 수 있다.
한편, 도시되지 않았지만, 본 발명의 일 실시 예에 따른 사용자 SCS는 상술한 실시 예들 중 어느 하나에 따른 신호를 송수신할 수 있는 통신부 및 상기 SCS의 전반적인 동작을 제어하는 제어부를 포함할 수 있다. 그리고, SCS는 SCS의 동작에 필요한 프로그램 및 데이터 등을 저장할 수 있는 저장부를 더 포함할 수 있다.
또한, 본 발명의 일 실시 예에 따른 기지국은 상술한 실시 예들 중 어느 하나에 따른 신호를 송수신할 수 있는 통신부 및 상기 기지국의 전반적인 동작을 제어하는 제어부를 포함할 수 있다. 그리고, 기지국은 기지국의 동작에 필요한 프로그램 및 데이터 등을 저장할 수 있는 저장부를 더 포함할 수 있다.
나머지 네트워크 엔티티의 경우에도 그 네트워크 엔티티의 전반적인 동작을 제어하는 제어부 및 다른 네트워크 엔티티와 통신을 할 수 있는 통신부를 포함할 수 있다. 그리고, 그의 동작에 필요한 프로그램 및 데이터 등을 저장할 수 있는 저장부를 더 포함할 수 있다.
상술한 실시 예들에서, 모든 단계 및 메시지는 선택적인 수행의 대상이 되거나 생략의 대상이 될 수 있다. 또한 각 실시 예에서 단계들은 반드시 순서대로 일어날 필요는 없으며, 뒤바뀔 수 있다. 메시지 전달도 반드시 순서대로 일어날 필요는 없으며, 뒤바뀔 수 있다. 각 단계 및 메시지는 독립적으로 수행될 수 있다.
한편, 본 명세서와 도면에는 본 발명의 바람직한 실시 예에 대하여 개시하였으며, 비록 특정 용어들이 사용되었으나, 이는 단지 본 발명의 기술 내용을 쉽게 설명하고 발명의 이해를 돕기 위한 일반적인 의미에서 사용된 것이지, 본 발명의 범위를 한정하고자 하는 것은 아니다. 여기에 개시된 실시 예 외에도 본 발명의 기술적 사상에 바탕을 둔 다른 변형 예들이 실시 가능하다는 것은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에게 자명한 것이다.
따라서, 상기의 상세한 설명은 모든 면에서 제한적으로 해석되어서는 아니되고 예시적인 것으로 고려되어야 한다. 본 발명의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고, 본 발명의 등가적 범위 내에서의 모든 변경은 본 발명의 범위에 포함된다.

Claims (14)

  1. 사용자 단말의 통신 방법에 있어서,
    상기 사용자 단말의 저전력 모드 상태에서 상기 사용자 단말 대신 다른 네트워크 엔티티에서 메시지 송수신을 수행할 것을 요청하는 정보를 포함하는 저전력 모드 요청 메시지를 이동성 관리 엔티티(MME: Mobility Management Entity)에게 전송하는 단계;
    상기 MME로부터 저전력 모드 사용 여부 및 적용 파라메터를 수신하는 단계; 및
    상기 수신한 파라메터에 따라 저전력 모드로 동작하는 단계; 를 포함하는 사용자 단말의 통신 방법.
  2. 제1 항에 있어서,
    상기 저전력 모드 요청 메시지는 상기 사용자 단말이 저전력 상태에 머무르는 시간에 대한 정보, 액티브 타이머(active timer), 액트브 플래그에 대한 정보 중 적어도 하나를 포함하는 것을 특징으로 하는 사용자 단말의 통신 방법.
  3. 제1 항에 있어서,
    상기 사용자 단말이 저전력 모드 상태 동안 상기 다른 네트워크 엔티티가 전송을 수행할 정보를 상기 다른 네트워크 엔티티에게 전송하는 단계; 를 더 포함하는 것을 특징으로 하는 사용자 단말의 통신 방법.
  4. 이동성 관리 엔티티(MME: Mobility Management Entity)의 통신 방법에 있어서,
    사용자 단말로부터, 상기 사용자 단말의 저전력 모드 상태에서 상기 사용자 단말 대신 다른 네트워크 엔티티에서 메시지 송수신을 수행할 것을 요청하는 정보를 포함하는 저전력 모드 요청 메시지를 수신하는 단계;
    상기 사용자 단말에게 저전력 모드 사용 여부 및 적용 파라메터를 송신하는 단계; 및
    상기 사용자 단말의 저전력 모드 상태에서 상기 사용자 단말 대신 다른 네트워크 엔티티에서 메시지 송수신을 수행할 것을 요청하는 정보를 홈 가입자 서버(HSS: Home Subscriber Server)에게 전송하는 단계; 를 포함하는 MME의 통신 방법.
  5. 제4 항에 있어서,
    상기 저전력 모드 요청 메시지는 상기 사용자 단말이 저전력 상태에 머무르는 시간에 대한 정보, 액티브 타이머(active timer), 액트브 플래그에 대한 정보 중 적어도 하나를 포함하는 것을 특징으로 하는 MME의 통신 방법.
  6. 서비스 능력 서버(SCS: Service Capability Server)의 통신 방법에 있어서,
    사용자 단말로부터 상기 사용자 단말의 저전력 모드 상태에서 상기 사용자 단말 대신 메시지 송수신을 수행할 것을 요청하는 정보를 수신하는 단계; 및
    사용자 단말의 저전력 모드 상태 동안 서버와 메시지 송수신을 수행하는 단계; 를 포함하는 것을 특징으로 하는 SCS의 통신 방법.
  7. 제6 항에 있어서,
    상기 서버와 메시지 송수신을 수행하는 단계는, 메시지의 송신자 주소 또는 external ID를 상기 사용자 단말의 주소 또는 external ID로 설정하여 상기 서버에 메시지를 전송하는 단계; 를 포함하는 SCS의 통신 방법.
  8. 사용자 단말에 있어서,
    다른 네트워크 엔티티와 신호를 송수신하는 통신부; 및
    상기 사용자 단말의 저전력 모드 상태에서 상기 사용자 단말 대신 다른 네트워크 엔티티에서 메시지 송수신을 수행할 것을 요청하는 정보를 포함하는 저전력 모드 요청 메시지를 이동성 관리 엔티티(MME: Mobility Management Entity)에게 전송하고, 상기 MME로부터 저전력 모드 사용 여부 및 적용 파라메터를 수신하고, 상기 수신한 파라메터에 따라 저전력 모드로 동작하도록 제어하는 제어부; 를 포함하는 사용자 단말.
  9. 제8 항에 있어서,
    상기 저전력 모드 요청 메시지는 상기 사용자 단말이 저전력 상태에 머무르는 시간에 대한 정보, 액티브 타이머(active timer), 액트브 플래그에 대한 정보 중 적어도 하나를 포함하는 것을 특징으로 하는 사용자 단말.
  10. 제8 항에 있어서,
    상기 제어부는,
    상기 사용자 단말이 저전력 모드 상태 동안 상기 다른 네트워크 엔티티가 전송을 수행할 정보를 상기 다른 네트워크 엔티티에게 전송하도록 제어하는 것을 특징으로 하는 사용자 단말.
  11. 이동성 관리 엔티티(MME: Mobility Management Entity)에 있어서,
    다른 네트워크 엔티티와 신호를 송수신하는 통신부; 및
    사용자 단말로부터, 상기 사용자 단말의 저전력 모드 상태에서 상기 사용자 단말 대신 다른 네트워크 엔티티에서 메시지 송수신을 수행할 것을 요청하는 정보를 포함하는 저전력 모드 요청 메시지를 수신하고, 상기 사용자 단말에게 저전력 모드 사용 여부 및 적용 파라메터를 송신하고, 상기 사용자 단말의 저전력 모드 상태에서 상기 사용자 단말 대신 다른 네트워크 엔티티에서 메시지 송수신을 수행할 것을 요청하는 정보를 홈 가입자 서버(HSS: Home Subscriber Server)에게 전송하도록 제어하는 제어부; 를 포함하는 MME.
  12. 제11 항에 있어서,
    상기 저전력 모드 요청 메시지는 상기 사용자 단말이 저전력 상태에 머무르는 시간에 대한 정보, 액티브 타이머(active timer), 액트브 플래그에 대한 정보 중 적어도 하나를 포함하는 것을 특징으로 하는 MME.
  13. 서비스 능력 서버(SCS: Service Capability Server)에 있어서,
    다른 네트워크 엔티티와 신호를 송수신하는 통신부; 및
    사용자 단말로부터 상기 사용자 단말의 저전력 모드 상태에서 상기 사용자 단말 대신 메시지 송수신을 수행할 것을 요청하는 정보를 수신하고, 사용자 단말의 저전력 모드 상태 동안 서버와 메시지 송수신을 수행하도록 제어하는 제어부; 를 포함하는 SCS.
  14. 제13 항에 있어서,
    상기 제어부는,
    메시지의 송신자 주소 또는 external ID를 상기 사용자 단말의 주소 또는 external ID로 설정하여 상기 서버에 메시지를 전송하도록 제어하는 것을 특징으로 하는 SCS.
PCT/KR2015/006738 2014-06-30 2015-06-30 저전력 단말의 통신 효과를 높이는 방법 및 장치 WO2016003177A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US15/321,452 US10327208B2 (en) 2014-06-30 2015-06-30 Method and apparatus for increasing communication effectiveness of terminal in power-saving mode

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2014-0081291 2014-06-30
KR1020140081291A KR102151031B1 (ko) 2014-06-30 2014-06-30 저전력 단말의 통신 효과를 높이는 방법 및 장치

Publications (1)

Publication Number Publication Date
WO2016003177A1 true WO2016003177A1 (ko) 2016-01-07

Family

ID=55019630

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2015/006738 WO2016003177A1 (ko) 2014-06-30 2015-06-30 저전력 단말의 통신 효과를 높이는 방법 및 장치

Country Status (3)

Country Link
US (1) US10327208B2 (ko)
KR (1) KR102151031B1 (ko)
WO (1) WO2016003177A1 (ko)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI580299B (zh) * 2014-08-11 2017-04-21 Ｌｇ電子股份有限公司 用於在無線通訊系統中傳送下行鏈路資料的方法與設備
WO2016048208A1 (en) * 2014-09-25 2016-03-31 Telefonaktiebolaget L M Ericsson (Publ) Device mobility with coap
KR102035077B1 (ko) 2015-10-28 2019-10-23 후아웨이 테크놀러지 컴퍼니 리미티드 데이터 송신 방법 및 장치
WO2017112785A1 (en) * 2015-12-21 2017-06-29 Nokia Solutions And Networks Oy Internet protocol (ip) multimedia subsystem (ims) level awareness of high latency device
EP3484203B1 (en) * 2016-07-30 2021-09-08 Huawei Technologies Co., Ltd. Service data transmitting method and equipment
US11432244B2 (en) * 2017-03-24 2022-08-30 Telefonaktiebolaget Lm Ericsson (Publ) Method and device for determining power control configuration
EP3619931A4 (en) * 2017-05-04 2021-01-20 Deepak Das MOBILITY FUNCTIONALITY FOR A CLOUD ACCESS SYSTEM
US10212690B1 (en) * 2017-10-16 2019-02-19 Verizon Patenting and Licensing Inc. Mobility management entity support of user equipment using extended discontinuous reception and power saving mode
US11477735B2 (en) * 2018-04-06 2022-10-18 Blackberry Limited Increasing battery performance for a device that uses power saving features
US11516263B2 (en) * 2019-03-14 2022-11-29 T-Mobile Usa, Inc. Secure and transparent transport of application level protocols to non-IP data delivery communication channels
WO2021023299A1 (en) * 2019-08-08 2021-02-11 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for 5gs interworking handling
US11089065B2 (en) * 2019-08-30 2021-08-10 T-Mobile Usa, Inc. Efficient interactions to support internet-of-things (IoT) device power saving mode
KR102302616B1 (ko) * 2020-02-17 2021-09-14 주식회사 케이티 배터리 절감 기술 동적 적용 방법, 이를 구현한 단말 및 네트워크 장치
EP4115665B1 (en) * 2020-03-02 2024-04-24 Sony Group Corporation Paging area update
US11811651B2 (en) * 2020-09-11 2023-11-07 Juniper Networks, Inc. Apparatus, system, and method for steering traffic over network slices
CN114172973B (zh) * 2021-11-30 2023-12-19 深圳市国电科技通信有限公司 一种基于mqtt协议和698协议的数据转换处理方法及电子设备
KR20240078088A (ko) * 2022-11-25 2024-06-03 삼성전자주식회사 무선 통신 시스템에서 ue의 송신 전력을 제어하는 방법 및 장치

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20130042014A (ko) * 2010-08-27 2013-04-25 알까뗄 루슨트 머신형 통신의 특징 활성화를 위한 방법 및 이의 ｍｔｃ 디바이스
WO2013169376A1 (en) * 2012-05-09 2013-11-14 Interdigital Patent Holdings, Inc. Handling mtc long drx cycle/sleep lengths

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8477724B2 (en) * 2010-01-11 2013-07-02 Research In Motion Limited System and method for enabling session context continuity of local service availability in local cellular coverage
CN102948200B (zh) * 2010-06-21 2017-03-22 瑞典爱立信有限公司 无线通信系统中的方法和布置
TWI602412B (zh) * 2011-06-10 2017-10-11 內數位專利控股公司 執行鄰居發現的方法及裝置
US9049682B2 (en) 2011-07-14 2015-06-02 Lg Electronics Inc. Method and apparatus for idle mode operation for M2M communication
CN103634849B (zh) * 2012-08-27 2017-07-28 华为终端有限公司 用于传输数据的方法和设备

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20130042014A (ko) * 2010-08-27 2013-04-25 알까뗄 루슨트 머신형 통신의 특징 활성화를 위한 방법 및 이의 ｍｔｃ 디바이스
WO2013169376A1 (en) * 2012-05-09 2013-11-14 Interdigital Patent Holdings, Inc. Handling mtc long drx cycle/sleep lengths

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"Architecture enhancements to facilitate communications with packet data networks and applications (Release 12", 3GPP TS 23.682 V12.2.0, 24 June 2014 (2014-06-24), XP055250735 *
ERICSSON: "Power Saving Mode scope in CT1", C1-134583, 3GPP TSG-CT WG1 #85, 4 November 2013 (2013-11-04), San Francisco (CA) , USA, XP050730442 *
HUAWEI ET AL.: "UE Power Saving Mode", 3GPP TSG-SA WG2 #99, 26 September 2013 (2013-09-26), Xiamen, China, pages 2 - 133648, XP050726968 *

Also Published As

Publication number Publication date
US10327208B2 (en) 2019-06-18
KR102151031B1 (ko) 2020-09-02
KR20160002240A (ko) 2016-01-07
US20170164286A1 (en) 2017-06-08

Similar Documents

Publication Publication Date Title
WO2016003177A1 (ko) 저전력 단말의 통신 효과를 높이는 방법 및 장치
WO2016186416A1 (en) Method and device for supporting paging optimization
WO2021010693A1 (en) Method and apparatus for identifying user in ran communication system
WO2018143774A1 (en) Registration management method for terminal accessing 5g network on non-3gpp access
WO2018155934A1 (ko) 무선 통신 시스템에서 3GPP access를 통해 non-3GPP에 관련된 데이터를 수신하는 방법 및 이를 위한 장치
WO2011142567A2 (en) Handover method supporting terminal mobility
WO2014051387A1 (ko) 사용자 단말에서 데이터 송수신 장치 및 방법
WO2013009053A2 (en) Method and apparatus for supporting mobility of user equipment
WO2017191973A1 (ko) 무선 통신 시스템에서 리모트 ue의 위치 등록 수행 방법 및 이를 위한 장치
WO2018221942A1 (ko) 상향링크 서비스 품질을 관리하는 방법 및 상기 방법을 수행하는 기지국
WO2018038490A1 (ko) 무선 통신 네트워크에서 지역별 데이터 네트워크 구성을 위한 방법 및 시스템
WO2014185708A1 (en) System and method for ip session continuity in device-to-device communication system
WO2011147358A1 (zh) 机器类型通讯设备的业务控制方法和相关装置及系统
WO2013009008A1 (en) Method and terminal for performing detach procedure
WO2013051845A2 (ko) 이동 통신 시스템에서 사용자 단말의 접속 제어 방법 및 장치
WO2017126928A1 (ko) 연결 모드 변경 방법 및 이동성 관리 개체
WO2013141599A1 (ko) 무선 통신 시스템에서 mtc 그룹 트리거(trigger) 방법 및 장치
WO2015137787A1 (en) Method for supporting ue access control
WO2014112843A1 (ko) 혼잡 상황에서 서비스 레벨을 조절하는 방법 및 장치
WO2019160300A1 (ko) 복수의 네트워크 시스템에 접속할 수 있는 단말에 sm 신호를 전송하는 방법
EP3566509A1 (en) Registration management method for terminal accessing 5g network on non-3gpp access
EP3158816A1 (en) Method and apparatus for establishing user plane bearer
WO2015034195A1 (ko) 멀티 rat 환경에서 위치 갱신 (location area update) 방법 및 페이징을 송수신하는 방법
WO2018038412A1 (ko) 차세대 네트워크에서 복수의 액세스를 통해 접속을 수행하는 방법 및 사용자 장치
WO2013005992A2 (en) Method for avoiding handover failure

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: 15814294

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15321452

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: 15814294

Country of ref document: EP

Kind code of ref document: A1

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载