[go: up one dir, main page]

WO2017026846A1 - 인터넷 프로토콜 멀티미디어 서브시스템 네트워크의 장애 복구 지원 방법 및 이를 위한 장치 - Google Patents

인터넷 프로토콜 멀티미디어 서브시스템 네트워크의 장애 복구 지원 방법 및 이를 위한 장치 Download PDF

Info

Publication number
WO2017026846A1
WO2017026846A1 PCT/KR2016/008908 KR2016008908W WO2017026846A1 WO 2017026846 A1 WO2017026846 A1 WO 2017026846A1 KR 2016008908 W KR2016008908 W KR 2016008908W WO 2017026846 A1 WO2017026846 A1 WO 2017026846A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
pdn type
ims
cscf
ims network
Prior art date
Application number
PCT/KR2016/008908
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 엘지전자(주)
Publication of WO2017026846A1 publication Critical patent/WO2017026846A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • 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

  • the present invention relates to a wireless communication system, and more particularly, to a method for supporting disaster recovery of an IMS network and an apparatus for supporting the same.
  • Mobile communication systems have been developed to provide voice services while ensuring user activity.
  • the mobile communication system has expanded not only voice but also data service.As a result of the explosive increase in traffic, a shortage of resources and users are demanding higher speed services, a more advanced mobile communication system is required. have.
  • IPv6 Internet Engineering Task Force
  • IP Internet Protocol version 4
  • IMS IMS terminal and network nodes.
  • IBCF Interconnection Border Control Functions
  • IMS supports interworking between IPv4 and IPv6 (or communication function between IPv4 SIP application and IPv6 SIP application) by converting the IP version.
  • the conventional IMS recovery procedure proposes a method for resolving a failure by recognizing a failure of a corresponding node in the IMS network and then replacing the function of the failed node with another node.
  • this conventional IMS recovery procedure does not suggest a solution for a case where a failure occurs in the IBCF.
  • the purpose of this specification is to propose an alternative mechanism for providing an IMS service to a UE without problems even if a failure occurs in such an IBCF.
  • an IMS service directed from a first terminal to a second terminal Receiving a Session Initiation Protocol (SIP) INVITE request for requesting a request; If a first PDN type assigned to the first terminal is a PDN type that can be serviced by the IMS network, a second PDN type assigned to the second terminal is a PDN type that can be serviced by the IMS network.
  • SIP Session Initiation Protocol
  • the second PDN type is a PDN type that is not serviceable by the IMS network, forwarding the received SIP INVITE request to IBCF (Interconnection Border Control Functions); And when not receiving a response to the SIP INVITE request from the IBCF for a predetermined time, instructing the first terminal to retry the SIP INVITE request after a predetermined time, and at least one node included in the IMS network. Instructing to change the second PDN type of the second terminal; It may include.
  • the PDN type not serviceable by the IMS network may correspond to a PDN type not supported by the S-CSCF.
  • first PDN type may correspond to IP (Internet Protocol) version 4
  • second PDN type may correspond to IP version 6.
  • instructing to change the second PDN type of the second terminal may include: And instructing to change the second PDN type of the second terminal together with the identification information of the second terminal.
  • the identification information of the second terminal and the change of the second PDN type may be indicated by the P-CSCF to a packet data network gateway (P-GW) via a policy and charging rules function (PCRF).
  • P-GW packet data network gateway
  • PCRF policy and charging rules function
  • the identification information of the second terminal and the change of the second PDN type are instructed from the P-CSCF to the PCRF through an Rx AAR (Authorization Authentication Request) message and a Gx RAR (Re-Authorization Request) message. Can be directed to the P-GW from the PCRF.
  • Rx AAR Authorization Authentication Request
  • Gx RAR Re-Authorization Request
  • the service unavailable by the IMS network may be indicated to the second terminal by the P-CSCF.
  • instructing to change the second PDN type of the second terminal may include informing the home subscriber server (HSS) of the second terminal. And instructing a change of the second PDN type of the second terminal together with the identification information, and requesting deregistration of the second terminal.
  • HSS home subscriber server
  • identification information of the second terminal, change of the second PDN type, and deregistration of the second terminal are instructed to the Mobility Management Entity (MME) by the HSS, and the MME is instructed by the HSS.
  • MME Mobility Management Entity
  • the IMS connection to the IMS network of the second terminal may be released through the initiated MME initiated bearer deactivation procedure.
  • a method of operating a terminal for supporting an IP multimedia subsystem (restoration) procedure comprising: connecting to the IMS network by receiving a second PDN type;
  • the S-CSCF included in the IMS network supports a first PDN type, instructing another node to change the second PDN type due to a failure of an IBCF included in the IMS network; Disconnecting from the IMS network; And reconnecting with the IMS network with the first PDN type. It may include.
  • disconnecting from the IMS network may include receiving a P-GW initiated bearer deactivation procedure request from the P-GW.
  • reconnecting the IMS network with the first PDN type may include: requesting reconnection with the IMS network with a PDN type including the first PDN type; Receiving the first PDN type by the P-GW; And registering with the IMS network with the first PDN type. It may include.
  • the step of releasing the connection with the IMS network receiving an MME initiated Bearer deactivation procedure request from the MME, as a cause of the request
  • Receiving indication information regarding the first PDN type that is an acceptable PDN type may include.
  • reconnecting the IMS network with the first PDN type may include: requesting reconnection with the IMS network with a PDN type including the first PDN type; Receiving the first PDN type by the MME; And registering with the IMS network with the first PDN type. It may include.
  • reconnecting to the IMS network with the first PDN type may include requesting reconnection with the IMS network with a PDN type including the first PDN type. Doing; Receiving the first PDN type by the P-CSCF; And registering with the IMS network with the first PDN type. It may include.
  • the IMS service can be provided to the UE without problems.
  • FIG. 1 is a view briefly illustrating an EPS (Evolved Packet System) to which the present invention can be applied.
  • EPS Evolved Packet System
  • E-UTRAN evolved universal terrestrial radio access network
  • FIG. 3 illustrates the structure of an E-UTRAN and an EPC in a wireless communication system to which the present invention can be applied.
  • FIG. 4 shows a structure of a radio interface protocol between a terminal and an E-UTRAN in a wireless communication system to which the present invention can be applied.
  • FIG. 5 is a diagram exemplarily illustrating a structure of a physical channel in a wireless communication system to which the present invention can be applied.
  • FIG. 6 is a diagram for explaining a contention based random access procedure in a wireless communication system to which the present invention can be applied.
  • FIG. 7 is a diagram illustrating an IMS structure according to an embodiment of the present invention.
  • FIG. 8 is a diagram illustrating a preliminary procedure for IMS from a higher level perspective.
  • FIG. 9 is a diagram illustrating an embodiment when a failure occurs in the IBCF according to an embodiment of the present invention.
  • 10 and 11 illustrate an embodiment of changing a PDN type centering on a PCRF when providing a MO service.
  • FIGS. 12 and 13 illustrate an embodiment of changing a PDN type based on a PCRF when providing an MT service.
  • 16 and 17 illustrate an embodiment of changing a PDN type centering on an HSS when providing an MT service.
  • 20 and 21 illustrate an embodiment of changing a PDN type centering on a terminal when providing an MT service.
  • FIG. 22 is a flowchart illustrating a method of operating an S-CSCF to support an IMS network failure recovery procedure according to an embodiment of the present invention.
  • FIG. 23 is a flowchart illustrating a method of operating a terminal for supporting an IMS (IP Multimedia Subsystem) network failure recovery procedure according to an embodiment of the present invention.
  • IMS IP Multimedia Subsystem
  • 24 is a block diagram of a communication device according to one embodiment of the present invention.
  • 25 illustrates a block diagram of a communication device according to an embodiment of the present invention.
  • a base station has a meaning as a terminal node of a network that directly communicates with a terminal.
  • the specific operation described as performed by the base station in this document may be performed by an upper node of the base station in some cases. That is, it is obvious that various operations performed for communication with a terminal in a network composed of a plurality of network nodes including a base station may be performed by the base station or other network nodes other than the base station.
  • a 'base station (BS)' may be replaced by terms such as a fixed station, a Node B, an evolved-NodeB (eNB), a base transceiver system (BTS), an access point (AP), and the like. .
  • a 'terminal' may be fixed or mobile, and may include a user equipment (UE), a mobile station (MS), a user terminal (UT), a mobile subscriber station (MSS), a subscriber station (SS), and an AMS ( Advanced Mobile Station (WT), Wireless Terminal (WT), Machine-Type Communication (MTC) Device, Machine-to-Machine (M2M) Device, Device-to-Device (D2D) Device, etc.
  • UE user equipment
  • MS mobile station
  • UT user terminal
  • MSS mobile subscriber station
  • SS subscriber station
  • AMS Advanced Mobile Station
  • WT Wireless Terminal
  • MTC Machine-Type Communication
  • M2M Machine-to-Machine
  • D2D Device-to-Device
  • downlink means communication from a base station to a terminal
  • uplink means communication from a terminal to a base station.
  • a transmitter may be part of a base station, and a receiver may be part of a terminal.
  • a transmitter may be part of a terminal and a receiver may be part of a base station.
  • CDMA code division multiple access
  • FDMA frequency division multiple access
  • TDMA time division multiple access
  • OFDMA orthogonal frequency division multiple access
  • SC-FDMA single carrier frequency division multiple access
  • GSM global system for mobile communications
  • GPRS general packet radio service
  • EDGE enhanced data rates for GSM evolution
  • OFDMA may be implemented in a wireless technology such as IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802-20, evolved UTRA (E-UTRA).
  • UTRA is part of a universal mobile telecommunications system (UMTS).
  • 3rd generation partnership project (3GPP) long term evolution (LTE) is a part of evolved UMTS (E-UMTS) using E-UTRA, and employs OFDMA in downlink and SC-FDMA in uplink.
  • LTE-A (advanced) is the evolution of 3GPP LTE.
  • Embodiments of the present invention may be supported by standard documents disclosed in at least one of the wireless access systems IEEE 802, 3GPP and 3GPP2. That is, steps or parts which are not described to clearly reveal the technical spirit of the present invention among the embodiments of the present invention may be supported by the above documents. In addition, all terms disclosed in the present document can be described by the above standard document.
  • UMTS Universal Mobile Telecommunications System
  • GSM Global System for Mobile Communication
  • Evolved Packet System A network system consisting of an Evolved Packet Core (EPC), which is a packet switched core network based on Internet Protocol (IP), and an access network such as LTE and UTRAN.
  • EPC Evolved Packet Core
  • IP Internet Protocol
  • UMTS is an evolutionary network.
  • NodeB base station of UMTS network. It is installed outdoors and its coverage is macro cell size.
  • eNodeB base station of EPS network. It is installed outdoors and its coverage is macro cell size.
  • a terminal may be referred to in terms of terminal, mobile equipment (ME), mobile station (MS), and the like.
  • the terminal may be a portable device such as a laptop, a mobile phone, a personal digital assistant (PDA), a smartphone, a multimedia device, or the like, or may be a non-portable device such as a personal computer (PC) or a vehicle-mounted device.
  • the term "terminal” or “terminal” in the MTC related content may refer to an MTC terminal.
  • IMS IP Multimedia Subsystem
  • IMSI International Mobile Subscriber Identity
  • Machine Type Communication Communication performed by a machine without human intervention. It may also be referred to as M2M (Machine to Machine) communication.
  • MTC terminal MTC UE or MTC device or MTC device: a terminal (eg, vending machine, etc.) having a function of communicating via a mobile communication network (for example, communicating with an MTC server via a PLMN) and performing an MTC function; Meter reading, etc.).
  • MTC UE or MTC device or MTC device a terminal having a function of communicating via a mobile communication network (for example, communicating with an MTC server via a PLMN) and performing an MTC function; Meter reading, etc.).
  • MTC server A server on a network that manages an MTC terminal. It may exist inside or outside the mobile communication network. It may have an interface that an MTC user can access. In addition, the MTC server may provide MTC related services to other servers (Services Capability Server (SCS)), or the MTC server may be an MTC application server.
  • SCS Services Capability Server
  • MTC mobile broadband
  • services e.g., remote meter reading, volume movement tracking, weather sensors, etc.
  • (MTC) application server a server on a network where (MTC) applications run
  • MTC feature A function of a network to support an MTC application.
  • MTC monitoring is a feature for preparing for loss of equipment in an MTC application such as a remote meter reading
  • low mobility is a feature for an MTC application for an MTC terminal such as a vending machine.
  • the MTC user uses a service provided by the MTC server.
  • MTC subscriber An entity having a connection relationship with a network operator and providing a service to one or more MTC terminals.
  • MTC group A group of MTC terminals that share at least one MTC feature and belongs to an MTC subscriber.
  • SCS Services Capability Server
  • MTC-IWF MTC InterWorking Function
  • HPLMN Home PLMN
  • SCS provides the capability for use by one or more MTC applications.
  • External Identifier An identifier used by an external entity (e.g., an SCS or application server) of a 3GPP network to point to (or identify) an MTC terminal (or a subscriber to which the MTC terminal belongs). Globally unique.
  • the external identifier is composed of a domain identifier and a local identifier as follows.
  • Domain Identifier An identifier for identifying a domain in a control term of a mobile communication network operator.
  • One provider may use a domain identifier for each service to provide access to different services.
  • Local Identifier An identifier used to infer or obtain an International Mobile Subscriber Identity (IMSI). Local identifiers must be unique within the application domain and are managed by the mobile telecommunications network operator.
  • IMSI International Mobile Subscriber Identity
  • RAN Radio Access Network: a unit including a Node B, a Radio Network Controller (RNC), and an eNodeB controlling the Node B in a 3GPP network. It exists at the terminal end and provides connection to the core network.
  • RNC Radio Network Controller
  • HLR Home Location Register
  • HSS Home Subscriber Server
  • RANAP RAN Application Part: between the RAN and the node in charge of controlling the core network (ie, Mobility Management Entity (MME) / Serving General Packet Radio Service (GPRS) Supporting Node) / MSC (Mobile Switching Center) Interface.
  • MME Mobility Management Entity
  • GPRS General Packet Radio Service
  • MSC Mobile Switching Center
  • PLMN Public Land Mobile Network
  • Non-Access Stratum A functional layer for transmitting and receiving signaling and traffic messages between a terminal and a core network in a UMTS and EPS protocol stack. The main function is to support the mobility of the terminal and to support the session management procedure for establishing and maintaining an IP connection between the terminal and the PDN GW.
  • SEF Service Capability Exposure Function
  • FIG. 1 is a diagram briefly illustrating an EPS (Evolved Packet System) to which the present invention may be applied.
  • EPS Evolved Packet System
  • the network structure diagram of FIG. 1 briefly reconstructs a structure of an EPS (Evolved Packet System) including an Evolved Packet Core (EPC).
  • EPS Evolved Packet System
  • EPC Evolved Packet Core
  • EPC Evolved Packet Core
  • SAE System Architecture Evolution
  • SAE is a research project to determine network structure supporting mobility between various kinds of networks.
  • SAE aims to provide an optimized packet-based system, for example, supporting various radio access technologies on an IP basis and providing improved data transfer capability.
  • the EPC is a core network of an IP mobile communication system for a 3GPP LTE system and may support packet-based real-time and non-real-time services.
  • a conventional mobile communication system i.e., a second generation or third generation mobile communication system
  • the core network is divided into two distinct sub-domains of circuit-switched (CS) for voice and packet-switched (PS) for data.
  • CS circuit-switched
  • PS packet-switched
  • the function has been implemented.
  • the sub-domains of CS and PS have been unified into one IP domain.
  • the EPC may include various components, and in FIG. 1, some of them correspond to a Serving Gateway (SGW) (or S-GW), PDN GW (Packet Data Network Gateway) (or PGW or P-GW), A mobility management entity (MME), a Serving General Packet Radio Service (GPRS) Supporting Node (SGSN), and an enhanced Packet Data Gateway (ePDG) are shown.
  • SGW Serving Gateway
  • PDN GW Packet Data Network Gateway
  • MME mobility management entity
  • GPRS General Packet Radio Service
  • SGSN Serving General Packet Radio Service
  • ePDG enhanced Packet Data Gateway
  • the SGW acts as a boundary point between the radio access network (RAN) and the core network, and is an element that functions to maintain a data path between the eNodeB and the PDN GW.
  • the SGW serves as a local mobility anchor point. That is, packets may be routed through the SGW for mobility in the E-UTRAN (Universal Mobile Telecommunications System (Evolved-UMTS) Terrestrial Radio Access Network defined in 3GPP Release-8 or later).
  • E-UTRAN Universal Mobile Telecommunications System (Evolved-UMTS) Terrestrial Radio Access Network defined in 3GPP Release-8 or later.
  • SGW also provides mobility with other 3GPP networks (RANs defined before 3GPP Release-8, such as UTRAN or GERAN (Global System for Mobile Communication (GSM) / Enhanced Data rates for Global Evolution (EDGE) Radio Access Network). It can also function as an anchor point.
  • GSM Global System for Mobile Communication
  • EDGE Enhanced Data rates for Global Evolution
  • the PDN GW corresponds to the termination point of the data interface towards the packet data network.
  • the PDN GW may support policy enforcement features, packet filtering, charging support, and the like.
  • untrusted networks such as 3GPP networks and non-3GPP networks (e.g., Interworking Wireless Local Area Networks (I-WLANs), trusted divisions such as Code Division Multiple Access (CDMA) networks or Wimax). It can serve as an anchor point for mobility management with the network.
  • I-WLANs Interworking Wireless Local Area Networks
  • CDMA Code Division Multiple Access
  • FIG. 1 shows that the SGW and the PDN GW are configured as separate gateways, two gateways may be implemented according to a single gateway configuration option.
  • the MME is an element that performs signaling and control functions for supporting access to a network connection, allocation of network resources, tracking, paging, roaming, handover, and the like.
  • the MME controls the control plane functions related to subscriber and session management.
  • the MME manages a number of eNodeBs and performs signaling for the selection of a conventional gateway for handover to other 2G / 3G networks.
  • the MME also performs functions such as security procedures, terminal-to-network session handling, and idle terminal location management.
  • SGSN handles all packet data, such as user's mobility management and authentication to other 3GPP networks (eg GPRS networks).
  • 3GPP networks eg GPRS networks.
  • the ePDG acts as a secure node for untrusted non-3GPP networks (eg, I-WLAN, WiFi hotspots, etc.).
  • untrusted non-3GPP networks eg, I-WLAN, WiFi hotspots, etc.
  • a terminal having IP capability includes an IP service network provided by an operator (ie, an operator) via various elements in the EPC, based on 3GPP access as well as non-3GPP access.
  • an operator ie, an operator
  • 3GPP access based on 3GPP access as well as non-3GPP access.
  • IMS IMS
  • FIG. 1 illustrates various reference points (eg, S1-U, S1-MME, etc.).
  • a conceptual link defining two functions existing in different functional entities of E-UTRAN and EPC is defined as a reference point.
  • Table 1 below summarizes the reference points shown in FIG. 1.
  • various reference points may exist according to the network structure.
  • S2a and S2b correspond to non-3GPP interfaces.
  • S2a is a reference point that provides the user plane with relevant control and mobility resources between trusted non-3GPP access and PDN GW.
  • S2b is a reference point that provides the user plane with relevant control and mobility support between the ePDG and the PDN GW.
  • the PCRF Policy Control and Charging Rules Function
  • QoS quality of service
  • PCC Policy and Charging Control
  • Gx may correspond to a reference point for a control plane protocol between PCRF and P-GW.
  • the SGi may correspond to a reference point between the PDN GW and the PDN.
  • the PDN may be an operator external public or private PDN or may correspond to an operator PDN (eg, an IMS service).
  • E-UTRAN evolved universal terrestrial radio access network
  • the E-UTRAN system is an evolution from the existing UTRAN system and may be, for example, a 3GPP LTE / LTE-A system.
  • Communication networks are widely deployed to provide various communication services, such as voice (eg, Voice over Internet Protocol (VoIP)) over IMS and packet data.
  • voice eg, Voice over Internet Protocol (VoIP)
  • VoIP Voice over Internet Protocol
  • an E-UMTS network includes an E-UTRAN, an EPC, and one or more UEs.
  • the E-UTRAN consists of eNBs providing a control plane and a user plane protocol to the UE, and the eNBs are connected through an X2 interface.
  • X2 user plane interface (X2-U) is defined between eNBs.
  • the X2-U interface provides non guaranteed delivery of user plane packet data units (PDUs).
  • An X2 control plane interface (X2-CP) is defined between two neighboring eNBs.
  • X2-CP performs functions such as context transfer between eNBs, control of user plane tunnel between source eNB and target eNB, delivery of handover related messages, and uplink load management.
  • the eNB is connected to the terminal through a wireless interface and is connected to an evolved packet core (EPC) through the S1 interface.
  • EPC evolved packet core
  • the S1 user plane interface (S1-U) is defined between the eNB and the serving gateway (S-GW).
  • the S1 control plane interface (S1-MME) is defined between the eNB and the mobility management entity (MME).
  • the S1 interface performs an evolved packet system (EPS) bearer service management function, a non-access stratum (NAS) signaling transport function, network sharing, and MME load balancing function.
  • EPS evolved packet system
  • NAS non-access stratum
  • the S1 interface supports a many-to-many-relation between eNB and MME / S-GW.
  • MME provides NAS signaling security, access stratum (AS) security control, inter-CN inter-CN signaling to support mobility between 3GPP access networks, and performing and controlling paging retransmission.
  • PWS Public Alert System
  • FIG. 3 illustrates the structure of an E-UTRAN and an EPC in a wireless communication system to which the present invention can be applied.
  • an eNB may select a gateway (eg, MME), route to the gateway during radio resource control (RRC) activation, scheduling of a broadcast channel (BCH), and the like. Dynamic resource allocation to the UE in transmission, uplink and downlink, and may perform the function of mobility control connection in the LTE_ACTIVE state.
  • the gateway is responsible for paging initiation, LTE_IDLE state management, ciphering of the user plane, System Architecture Evolution (SAE) bearer control, and NAS signaling encryption. It can perform the functions of ciphering and integrity protection.
  • FIG. 4 shows a structure of a radio interface protocol between a terminal and an E-UTRAN in a wireless communication system to which the present invention can be applied.
  • FIG. 4 (a) shows the radio protocol structure for the control plane and FIG. 4 (b) shows the radio protocol structure for the user plane.
  • the layers of the air interface protocol between the terminal and the E-UTRAN are based on the lower three layers of the open system interconnection (OSI) standard model known in the art of communication systems. It may be divided into a first layer L1, a second layer L2, and a third layer L3.
  • the air interface protocol between the UE and the E-UTRAN consists of a physical layer, a data link layer, and a network layer horizontally, and vertically stacks a protocol stack for transmitting data information. (protocol stack) It is divided into a user plane and a control plane, which is a protocol stack for transmitting control signals.
  • the control plane refers to a path through which control messages used by the terminal and the network to manage a call are transmitted.
  • the user plane refers to a path through which data generated at an application layer, for example, voice data or Internet packet data, is transmitted.
  • an application layer for example, voice data or Internet packet data
  • a physical layer which is a first layer (L1), provides an information transfer service to a higher layer by using a physical channel.
  • the physical layer is connected to a medium access control (MAC) layer located at a higher level through a transport channel, and data is transmitted between the MAC layer and the physical layer through the transport channel.
  • Transport channels are classified according to how and with what characteristics data is transmitted over the air interface.
  • data is transmitted between different physical layers through a physical channel between a physical layer of a transmitter and a physical layer of a receiver.
  • the physical layer is modulated by an orthogonal frequency division multiplexing (OFDM) scheme and utilizes time and frequency as radio resources.
  • OFDM orthogonal frequency division multiplexing
  • a physical downlink control channel is a resource allocation of a paging channel (PCH) and a downlink shared channel (DL-SCH) and uplink shared channel (UL-SCH) to the UE.
  • PCH paging channel
  • DL-SCH downlink shared channel
  • UL-SCH uplink shared channel
  • the PDCCH may carry an UL grant that informs the UE of resource allocation of uplink transmission.
  • PDFICH physical control format indicator channel informs the UE of the number of OFDM symbols used for PDCCHs and is transmitted every subframe.
  • a physical HARQ indicator channel (PHICH) carries a HARQ acknowledgment (ACK) / non-acknowledge (NACK) signal in response to uplink transmission.
  • the physical uplink control channel (PUCCH) carries uplink control information such as HARQ ACK / NACK, downlink request and channel quality indicator (CQI) for downlink transmission.
  • a physical uplink shared channel (PUSCH) carries a UL-SCH.
  • the MAC layer of the second layer provides a service to a radio link control (RLC) layer, which is a higher layer, through a logical channel.
  • RLC radio link control
  • the MAC layer multiplexes / demultiplexes into a transport block provided as a physical channel on a transport channel of a MAC service data unit (SDU) belonging to the logical channel and mapping between the logical channel and the transport channel.
  • SDU MAC service data unit
  • the RLC layer of the second layer supports reliable data transmission. Functions of the RLC layer include concatenation, segmentation, and reassembly of RLC SDUs.
  • the RLC layer In order to guarantee the various quality of service (QoS) required by the radio bearer (RB), the RLC layer has a transparent mode (TM), an unacknowledged mode (UM) and an acknowledgment mode (AM). There are three modes of operation: acknowledge mode.
  • AM RLC provides error correction through an automatic repeat request (ARQ). Meanwhile, when the MAC layer performs an RLC function, the RLC layer may be included as a functional block of the MAC layer.
  • the packet data convergence protocol (PDCP) layer of the second layer (L2) performs user data transmission, header compression, and ciphering functions in the user plane.
  • Header compression is relatively large and large in order to allow efficient transmission of Internet protocol (IP) packets, such as IPv4 (internet protocol version 4) or IPv6 (internet protocol version 6), over a small bandwidth wireless interface. It means the function to reduce the IP packet header size that contains unnecessary control information.
  • IP Internet protocol
  • IPv4 Internet protocol version 4
  • IPv6 Internet protocol version 6
  • a radio resource control (RRC) layer located at the lowest part of the third layer L3 is defined only in the control plane.
  • the RRC layer serves to control radio resources between the terminal and the network.
  • the UE and the network exchange RRC messages with each other through the RRC layer.
  • the RRC layer controls the logical channel, transport channel and physical channel with respect to configuration, re-configuration and release of radio bearers.
  • the radio bearer means a logical path provided by the second layer (L2) for data transmission between the terminal and the network.
  • Establishing a radio bearer means defining characteristics of a radio protocol layer and a channel to provide a specific service, and setting each specific parameter and operation method.
  • the radio bearer may be further divided into two signaling radio bearers (SRBs) and data radio bearers (DRBs).
  • SRB is used as a path for transmitting RRC messages in the control plane
  • DRB is used as a path for transmitting user data in the user plane.
  • a non-access stratum (NAS) layer located above the RRC layer performs functions such as session management and mobility management.
  • NAS non-access stratum
  • One cell constituting the base station is set to one of the bandwidth, such as 1.25, 2.5, 5, 10, 20Mhz to provide a downlink or uplink transmission service to multiple terminals.
  • Different cells may be configured to provide different bandwidths.
  • a downlink transport channel for transmitting data from a network to a terminal includes a broadcast channel (BCH) for transmitting system information, a PCH for transmitting a paging message, and a DL-SCH for transmitting user traffic or control messages.
  • BCH broadcast channel
  • PCH for transmitting a paging message
  • DL-SCH for transmitting user traffic or control messages.
  • Traffic or control messages of the downlink multicast or broadcast service may be transmitted through the DL-SCH or may be transmitted through a separate downlink multicast channel (MCH).
  • an uplink transport channel for transmitting data from a terminal to a network includes a random access channel (RACH) for transmitting an initial control message, and an UL-SCH (uplink shared) for transmitting user traffic or a control message. channel).
  • RACH random access channel
  • UL-SCH uplink shared
  • the logical channel is on top of the transport channel and is mapped to the transport channel.
  • the logical channel may be divided into a control channel for transmitting control region information and a traffic channel for delivering user region information.
  • the control channel includes a broadcast control channel (BCCH), a paging control channel (PCCH), a common control channel (CCCH), a dedicated control channel (DCCH), multicast And a control channel (MCCH: multicast control channel).
  • Traffic channels include a dedicated traffic channel (DTCH) and a multicast traffic channel (MTCH).
  • PCCH is a downlink channel that carries paging information and is used when the network does not know the cell to which the UE belongs.
  • CCCH is used by a UE that does not have an RRC connection with the network.
  • the DCCH is a point-to-point bi-directional channel used by a terminal having an RRC connection for transferring dedicated control information between the UE and the network.
  • DTCH is a point-to-point channel dedicated to one terminal for transmitting user information that may exist in uplink and downlink.
  • MTCH is a point-to-multipoint downlink channel for carrying traffic data from the network to the UE.
  • the DCCH may be mapped to the UL-SCH
  • the DTCH may be mapped to the UL-SCH
  • the CCCH may be mapped to the UL-SCH.
  • the BCCH may be mapped with the BCH or DL-SCH
  • the PCCH may be mapped with the PCH
  • the DCCH may be mapped with the DL-SCH.
  • the DTCH may be mapped with the DL-SCH
  • the MCCH may be mapped with the MCH
  • the MTCH may be mapped with the MCH.
  • FIG. 5 is a diagram exemplarily illustrating a structure of a physical channel in a wireless communication system to which the present invention can be applied.
  • a physical channel transmits signaling and data through a radio resource including one or more subcarriers in a frequency domain and one or more symbols in a time domain.
  • One subframe having a length of 1.0 ms is composed of a plurality of symbols.
  • the specific symbol (s) of the subframe eg, the first symbol of the subframe
  • the PDCCH carries information about dynamically allocated resources (eg, a resource block, a modulation and coding scheme (MCS), etc.).
  • MCS modulation and coding scheme
  • the UE performs an RRC connection re-establishment procedure. Cases are performed.
  • a contention-based random access procedure in which the UE randomly selects and uses one preamble within a specific set And a non-contention based random access procedure using a random access preamble allocated by a base station only to a specific terminal.
  • FIG. 6 is a diagram for explaining a contention based random access procedure in a wireless communication system to which the present invention can be applied.
  • the UE randomly selects one random access preamble (RACH preamble) from a set of random access preambles indicated through system information or a handover command, and A physical RACH (PRACH) resource capable of transmitting a random access preamble is selected and transmitted.
  • RACH preamble random access preamble
  • PRACH physical RACH
  • the base station receiving the random access preamble from the terminal decodes the preamble and obtains an RA-RNTI.
  • the RA-RNTI associated with the PRACH in which the random access preamble is transmitted is determined according to the time-frequency resource of the random access preamble transmitted by the corresponding UE.
  • the base station transmits a random access response addressed to the RA-RNTI obtained through the preamble on the first message to the terminal.
  • the random access response includes a random access preamble identifier (RA preamble index / identifier), an uplink grant (UL grant) indicating an uplink radio resource, a temporary cell identifier (TC-RNTI), and a time synchronization value ( TAC: time alignment commands) may be included.
  • the TAC is information indicating a time synchronization value that the base station sends to the terminal to maintain uplink time alignment.
  • the terminal updates the uplink transmission timing by using the time synchronization value. When the terminal updates the time synchronization, a time alignment timer is started or restarted.
  • the UL grant includes an uplink resource allocation and a transmit power command (TPC) used for transmission of a scheduling message (third message), which will be described later. TPC is used to determine the transmit power for the scheduled PUSCH.
  • TPC transmit power command
  • the base station After the UE transmits the random access preamble, the base station attempts to receive its random access response within the random access response window indicated by the system information or the handover command, and PRACH
  • the PDCCH masked by the RA-RNTI corresponding to the PDCCH is detected, and the PDSCH indicated by the detected PDCCH is received.
  • the random access response information may be transmitted in the form of a MAC packet data unit (MAC PDU), and the MAC PDU may be transmitted through a PDSCH.
  • MAC PDU MAC packet data unit
  • the monitoring stops the random access response.
  • the random access response message is not received until the random access response window ends, or if a valid random access response having the same random access preamble identifier as the random access preamble transmitted to the base station is not received, the random access response is received. Is considered to have failed, and then the UE may perform preamble retransmission.
  • the terminal When the terminal receives a valid random access response to the terminal, it processes each of the information included in the random access response. That is, the terminal applies the TAC, and stores the TC-RNTI. In addition, by using the UL grant, the data stored in the buffer of the terminal or newly generated data is transmitted to the base station.
  • an RRC connection request generated in the RRC layer and delivered through the CCCH may be included in the third message and transmitted.
  • the RRC layer is generated in the RRC layer and CCCH.
  • the RRC connection reestablishment request delivered through the RRC connection reestablishment request may be included in the third message and transmitted. It may also include a NAS connection request message.
  • the third message should include the identifier of the terminal.
  • C-RNTI valid cell identifier allocated in the corresponding cell before the random access procedure
  • the UE If the UE transmits data corresponding to the UL grant, it starts a timer for contention resolution (contention resolution timer).
  • the base station When the base station receives the C-RNTI of the terminal through the third message from the terminal, the base station transmits a fourth message to the terminal using the received C-RNTI.
  • the unique identifier ie, S-TMSI or random number
  • the fourth message is transmitted using the TC-RNTI allocated to the terminal in the random access response.
  • the fourth message may include an RRC connection setup message.
  • the terminal After transmitting the data including its identifier through the UL grant included in the random access response, the terminal waits for an instruction of the base station to resolve the collision. That is, it attempts to receive a PDCCH to receive a specific message.
  • the third message transmitted in response to the UL grant is its C-RNTI
  • the identifier is a unique identifier (that is, In the case of S-TMSI or a random number, it attempts to receive the PDCCH using the TC-RNTI included in the random access response.
  • the terminal determines that the random access procedure has been normally performed, and terminates the random access procedure.
  • the terminal determines that the random access procedure has been normally performed, and terminates the random access procedure.
  • the terminal determines that the random access procedure is normally performed, and terminates the random access procedure.
  • the terminal acquires the C-RNTI through the fourth message, and then the terminal and the network transmit and receive a terminal-specific message using the C-RNTI.
  • the random access procedure is terminated by only transmitting the first message and transmitting the second message.
  • the terminal before the terminal transmits the random access preamble to the base station as the first message, the terminal is allocated a random access preamble from the base station, and transmits the allocated random access preamble to the base station as a first message, and sends a random access response from the base station.
  • the random access procedure is terminated by receiving.
  • 3GPP has standardized a terminal mechanism (or IFOM) based on IP flow mobility.
  • IFOM uses Dual Stack Mobile IP (DSMIP), a host-based mobility protocol.
  • DSMIP Dual Stack Mobile IP
  • NBIFOM Network-based IFOM
  • -UE supports dual radio to simultaneously perform 3GPP and WLAN access
  • 3GPP-related policies e.g., Policy and Charging Control (PCC), Access Network Discovery and Selection Function (ANDSF), Inter-System Routing policy (ISRP), Inter-System Mobility Policy (ISMP) to support NBIFOM) And relationships between RAN policies without ANDSF, etc.
  • PCC Policy and Charging Control
  • ANDSF Access Network Discovery and Selection Function
  • ISRP Inter-System Routing policy
  • ISMP Inter-System Mobility Policy
  • IMS IP Multimedia Subsystem
  • IMS IP Multimedia Subsystem
  • FIG. 7 is a diagram illustrating an IMS structure according to an embodiment of the present invention.
  • IMS may refer to a framework for providing a multimedia service on an IP network.
  • IMS provides independent access network to provide multimedia service environment common to wired and wireless network.
  • the IMS has a structure in which a service layer and a service layer are separated so that various services can be easily extended to a common control layer without having a service-dependent control function.
  • the IMS may include six functional blocks that are largely functionally divided as follows.
  • SIP Session Initiation Protocol
  • Proxy-CSCF Call Session Control Function
  • S-CSCF Serving-CSCF
  • User terminal information can be transmitted to the HSS.
  • the subscriber information received from the HSS can be stored and maintained. Find session initiation, termination, and SIP message paths.
  • Interrogation-CSCF This may correspond to a SIP server of a GW nature receiving SIP messages from other networks.
  • the user can select the HSS when registering a location.
  • the S-CSCF may be selected to transmit a message from the terminal.
  • the main storage information may include subscriber identification information (service subscription status), user authentication information, S-CSCF selection information, user profile information, and the like.
  • Subscription Locator Function When there are a plurality of HSSs in the IMS, the HSS information for each user is stored in order to find an HSS that stores specific user information.
  • MRFP Multimedia Resource Function Processor
  • -MRFC Multimedia Resource Function Controller
  • TAS Telephony AS
  • IM-AS IM-AS
  • MSG-AS MSG-AS
  • -PCRF Policy and Charging Rules Function
  • PCEF Charging Enforcement Function
  • It may correspond to a block providing an interworking function between an IMS network and an existing circuit switched network.
  • IP Multimedia-Media Gateway It can provide media conversion function such as voice and video between IP network and CS network.
  • MGCF MGW Control Function: can support signaling conversion between SIP and ISP. In addition, it is possible to control the IM-MGW.
  • -BGCF Bandout Gateway Control Function
  • SGW Signaling from the CS network can be converted to SIP.
  • SIP may be converted into an ISDN user part (ISP).
  • ISP ISDN user part
  • IMS has been outlined.
  • An IMS terminal (or device) accessing such an IMS must perform some preliminary procedures before starting an IMS related operation.
  • FIG. 8 is a diagram illustrating a preliminary procedure for IMS from a higher level perspective.
  • the following procedure may be sequentially performed for the IMS.
  • the IMS service provider may authorize the user to use the IMS service. This generally requires a pre-signed contract or reservation between the IMS network operator and the user. Such a contract is similar to a reservation that authorizes a user to perform outgoing / receiving over a wireless network.
  • the IMS terminal may be connected to an IP Connectivity Access Network (IP-CAN) such as GPRS (in GSM / UMTS network), Asymmetric Digital Subscriber Line (ADSL), or Wireless Local Access Network (WLAN).
  • IP-CAN IP Connectivity Access Network
  • the IP-CAN may provide a connection to an IMS home network or an IMS visited network.
  • the IMS terminal must obtain an IP address.
  • IP address may generally be assigned for a dynamically preset time by the IP-CAN operator.
  • the IMS terminal can find out the IP address of the P-CSCF serving as the entrance SIP proxy server. All SIP signaling transmitted by the IMS terminal may pass through the P-CSCF.
  • the IMS terminal may transmit and receive a SIP message (or signaling) with the P-CSCF.
  • the P-CSCF may be assigned to the IMS terminal for the IMS registration procedure, and the IMS registration procedure may generally be triggered when the IMS terminal is switched on / off.
  • the P-CSCF discovery procedure may be performed as part of the procedure for obtaining an IP-CAN connection or as a separate separate procedure.
  • the separate procedure may be performed as a means of Dynamic Host Configuration Protocol (DHCP) or DHCP for IPv6 (DHCPv6).
  • DHCP Dynamic Host Configuration Protocol
  • DHCPv6 DHCP for IPv6
  • the IMS terminal may register with the IMS network at the SIP application level. This can be done by regular SIP registration.
  • the IMS terminal needs to register with the IMS before initiating or receiving any other SIP signaling.
  • the IP-CAN layer may be independent of the IMS SIP layer.
  • registration at the IMS layer may be independent of registration at the IP-CAN layer.
  • This IMS registration procedure may allow the IMS network to obtain the IP address of the IMS terminal. It also allows the IMS network to authenticate users, enter security agreements, and approve session connections.
  • IPv6 IP version 6
  • 'IPv4' IP version 4
  • 3GPP analyzed the applicability of IPv6 for IMS. We anticipate that IPv6 will be the most common (or common) version of IP on the Internet, but contrary to these expectations, most of the Internet still operates IPv4, and only a few mobile networks currently support it. It is ready to be introduced.
  • IMS IMS terminal and network nodes.
  • IBCF Interconnection Border Control Functions
  • IMS supports interworking between IPv4 and IPv6 (or communication function between IPv4 SIP application and IPv6 SIP application) by converting the IP version.
  • the conventional IMS recovery procedure proposes a method for resolving a failure by recognizing a failure of a corresponding node in the IMS network and then replacing the function of the failed node with another node.
  • this conventional IMS recovery procedure does not suggest a solution for a case where a failure occurs in the IBCF.
  • an IPv4 PDN type terminal indicates a terminal having / supporting a PDN type of IPv4
  • an IPv6 PDN type terminal indicates a terminal having / supporting a PDN type of IPv6.
  • a P-CSCF may provide a service to an IPv4 PDN type terminal and an IPv6 PDN type terminal, but I-CSCF and S-CSCF may serve only an IPv4 PDN type terminal.
  • the IBCF may be located between the P-CSCF and the S-CSCF to convert the IP version (or PDN type) from IPv6 to IPv4 to support the I-CSCF / S-CSCF to provide a service.
  • the IP version (or PDN type) of the terminal is not changed. It is difficult to solve these problems unless. Therefore, in this specification, when the IBCF fails and thus cannot convert the IP version (or PDN type), the UE changes the IP version (or PDN type) to request the IMS service again, thereby causing the IMSF failure. We want to solve the service unavailability problem.
  • the P-CSCF can serve both an IPv4 PDN type terminal and an IPv6 PDN type terminal.
  • FIGS. 10 and 11 illustrate an embodiment of changing a PDN type centering on a PCRF when providing a MO service.
  • the UE requesting the MO service in FIGS. 10 and 11 may correspond to the UE registered in the IMS network by completing the preliminary procedure of FIG. 10.
  • a PDN type (or an IMS network of a terminal) that is not supported by some nodes (for example, S-CSCF) (or UE's IMS network) due to a failure in IBCF, a node performing IP version conversion function in the IMS network.
  • the service may not be provided to the terminal requesting the MO service (IMS service) with the IP version (S1110).
  • the P-CSCF may determine whether the PDN type conversion through the IBCF of the terminal is necessary by checking the PDN type of the terminal requesting the MO service. Whether PDN type conversion is required may be determined based on whether the PDN type currently configured / assigned to the UE is a PDN type supported by some nodes (eg, S-CSCF) in the IMS network.
  • some nodes eg, S-CSCF
  • the P-CSCF sends the IBCF a SIP INVITE message / request transmitted to request / initiate the IMS service from the terminal. Can be forwarded to (S1120).
  • the P-CSCF may not forward the SIP INVITE message / request transmitted from the UE to the IBCF.
  • the P-CSCF does not forward the SIP INVITE message / request to the IBCF, since the PDN type of the UE corresponds to the PDN type that can be serviced by the S-CSCF, the IMS service is normally provided and the following steps may be omitted. have.
  • the P-CSCF may not recognize the failure of the IBCF by not receiving a response to the SIP INVITE message / request according to step S1120 from the IBCF for a predetermined time (S1130).
  • the P-CSCF which has recognized the failure of the IBCF, needs to change the PDN type of the UE to receive the IMS service while notifying the terminal that the IMSF cannot be provided due to IBCF failure / failure through the PCRF. It may inform (S1140). More specifically, the P-CSCF transmits an Rx AAR (Authorization Authentication Request) message containing a “PDN_TYPE_CHANGE” indication to the PCRF, and the PCRF receives a Gx RAR (Re-Authorization Request) message containing the received “PDN_TYPE_CHANGE” indication. By transmitting to the P-GW (or PCEF), it can be informed that the PDN type change of the terminal is necessary due to the failure / failure of the IBCF.
  • Rx AAR Authorization Authentication Request
  • Gx RAR Re-Authorization Request
  • the P-GW may release the IMS PDN connection of the UE through the P-GW initiated bearer deactivation procedure (S1150).
  • the UE may re-request an IMS PDN connection with a PDN type different from the previous / last PDN type (S1160).
  • the following two embodiments may exist as a method of changing the PDN type differently from the previous PDN type.
  • the P-GW may set the cause to “PDN_TYPE_CHANGE” when requesting a bearer deactivation procedure.
  • the UE when re-requesting the IMS PDN connection, changes the PDN type to a type capable of providing service of the IMS node (or a PDN type different from the previously configured PDN type) (for example, IPv4).
  • the PDN connection can be re-requested (or requested to re-attach).
  • the UE sets a PDN type different from the PDN type used in the previous / last PDN connection request and performs IMS PDN connection through a UE requested PDN Connectivity request. Can be obtained.
  • the P-GW stores a terminal requiring a PDN type change (for example, storing identification information of the terminal separately), and when receiving a PDN connection request of the terminal, the P-GW may provide the IMS service to the terminal.
  • PDN type can be assigned / configured.
  • the P-GW may store / store a terminal requiring a PDN type change in advance, and when receiving a UE requested PDN Connectivity request by the terminal, the I-MS is transmitted to the IMS.
  • a PDN type (eg, IPv4) that can be serviced may be configured / assigned.
  • the UE may request a PDN connection with a PDN type including a PDN type (eg, IPv4) capable of providing IMS services.
  • the UE may establish a PDN connection with the changed PDN type and then complete the IMS registration procedure. Furthermore, the terminal may transmit a SIP INVITE message / request for requesting an IMS service (or MO service) to the IMS network.
  • the PDN type of the terminal corresponds to a type that can be serviced by an IMS network node (for example, S-CSCF)
  • an IMS network node for example, S-CSCF
  • the P-CSCF which has received the SIP INVITE message / request from the terminal, can transmit / forward the message directly to the S-CSCF without transmitting / forwarding the message to the IBCF. In this case, normal IMS service provision to the terminal is It is possible.
  • PDN type change (or IP) by recognizing the failure of the IBCF by the keep-alive mechanism of nodes (ie, P-CSCF or S-CSCF) that are logically directly connected to the IBCF. Version conversion) may also collectively change the PDN type of the terminal required.
  • the PDN type of the UE requesting service to the IMS network as in the present embodiment It is proposed to perform the PDN type change procedure only when this service type is not available.
  • FIGS. 12 and 13 illustrate an embodiment of changing a PDN type based on a PCRF when providing an MT service.
  • the UE requesting the MT service may correspond to a UE registered in the IMS network by completing the preliminary procedure of FIG. 8.
  • IBCF is divided into functions / concepts, and an interworking function between IMS networks is referred to as IBCF 1 and a PDN type (or IP version) conversion function is referred to as IBCF 2.
  • IBCF 1 operates normally in this drawing / example, and a failure occurs only in IBCF 2.
  • the description of the steps to be described below may be the same / similar to the description in Figures 12 and 13, overlapping description will be omitted.
  • a failure of IBCF 2 causes a PDN type (or an IMS network) not supported by some nodes (eg, S-CSCF) (or IMS networks) in the IMS network. It may be impossible to provide an MT service (or an IMS service) directed to a receiving terminal (MT UE) having an IP version (S1310).
  • an MT / IMS service request for a receiving terminal having a PDN type that cannot provide IMS service may occur (S1320).
  • the S-CSCF may check whether the PDN type conversion through the IBCF 2 is necessary by checking the PDN type of the receiving terminal. Whether PDN type conversion is required may be determined based on whether the PDN type of the receiving terminal corresponds to a PDN type supported by some nodes (eg, S-CSCF) in the IMS network. To this end, the S-CSCF may use the identification information of the receiving terminal included in the SIP INVITE message / receipt received for the IMS service request / initiation from the calling terminal.
  • the S-CSCF sends a SIP transmitted for requesting / initiating IMS service from the source UE (MO UE). You can forward INVITE messages / requests to IBCF 2. On the contrary, if it is determined that the PDN type conversion procedure is not necessary (for example, when the PDN type of the terminal is IPv4), the S-CSCF may not forward the SIP INVITE message / request transmitted from the originating terminal to IBCF 2. have.
  • the S-CSCF does not forward the SIP INVITE message / request to IBCF 2
  • the PDN type of the receiving terminal corresponds to a PDN type that can be serviced by S-CSCF, etc.
  • the IMS service is normally provided and the following steps are omitted. Can be.
  • the S-CSCF may recognize the failure of IBCF 2 by not receiving a response to the SIP INVITE message / request according to step S1320 (eg, 200 Trying response) from IBCF 2 for a predetermined time ( S1330).
  • the PDN type of the originating terminal corresponds to the type that can be serviced by the IMS network of the receiving terminal, but the PDN type of the receiving terminal is the receiving IMS (due to the failure of IBCF 2).
  • the originating terminal may resend the SIP INVITE message / request after a predetermined time by responding to the originating terminal with “500 Try After”. (S1340).
  • the S-CSCF responds to the calling terminal with “606 Not Acceptable with Warning 301 Incompatible network address formats”, thereby preventing the provision of the IMS service. It may be informed that (S1340).
  • step S1340 the S-CSCF confirming that the PDN type of the receiving terminal is a type that cannot provide a service, notifies the P-CSCF of the IBCF failure / failure notification together with the information of the receiving terminal (for example, Public User Identity). Can transmit The P-CSCF receiving the notification cannot provide the I-MS service to the receiving terminal due to IBCF failure / failure along with information (eg, public user identity) of the receiving terminal to the P-GW via PCRF. It may be informed that the PDN type needs to be changed (S1350).
  • the P-CSCF sends an Rx AAR message containing a “PDN_TYPE_CHANGE” indication to the PCRF, and the PCRF sends a Gx RAR message containing the received “PDN_TYPE_CHANGE” indication to the P-GW (or PCEF).
  • the P-GW or PCEF
  • the P-GW may release the IMS PDN connection of the UE through the P-GW initiated bearer deactivation procedure (S1360).
  • the UE may re-request an IMS PDN connection with a PDN type different from the previous PDN type (S1370).
  • the method of changing the PDN type differently from the previous PDN type includes an embodiment in which the receiving terminal re-requests the IMS PDN connection to the changed PDN type, or sets / assigns the PDN type whose P-GW is changed to the receiving terminal.
  • An embodiment may exist. Detailed descriptions related to these embodiments are overlapped with those described above with reference to FIGS. 10 and 11, and thus detailed descriptions thereof will be omitted.
  • the receiving terminal may complete the IMS registration procedure after establishing a PDN connection with the changed PDN type.
  • the changed PDN type of the receiving terminal corresponds to a type that can be serviced by an IMS network node (eg, S-CSCF) of the calling terminal, a separate IP version conversion procedure by IBCF 2 is unnecessary. Therefore, even if a failure occurs in IBCF 2 and the PDN type conversion is impossible, the IMS service (or MT service) can be normally provided.
  • IMS network node eg, S-CSCF
  • the failure of IBCF 2 is recognized by the keep-alive mechanism of nodes (ie, P-CSCF or S-CSCF) that are logically directly connected to IBCF 2, thereby changing the PDN type ( Alternatively, the PDN type of the receiving terminals requiring IP version conversion) may be collectively changed.
  • the PDN of the receiving terminal requesting a service to the IMS network as in the present embodiment. It is proposed to perform the PDN type change procedure only when the type is an unserviceable type.
  • FIGS. 14 and 15 illustrate an embodiment of changing a PDN type centering on an HSS when providing a MO service.
  • the UE requesting the MO service in FIGS. 14 and 15 may correspond to the UE registered in the IMS network by completing the preliminary procedure of FIG. 8.
  • the following description of the steps to be described later may be applied to the same / similar to the description in Figures 10 to 13, overlapping description is omitted.
  • a PDN type (or an IMS network of a terminal) that is not supported by another node (for example, S-CSCF) (or UE's IMS network) due to a failure in IBCF, a node that performs IP version conversion function in the IMS network.
  • the service may not be provided to the terminal requesting the MO service (IMS service) with the IP version (S1510).
  • the P-CSCF may determine whether the PDN type conversion through the IBCF of the terminal is necessary by checking the PDN type of the terminal requesting the MO service. Whether PDN type conversion is required may be determined based on whether the PDN type currently configured / assigned to the UE is a PDN type supported by some nodes (eg, S-CSCF) in the IMS network.
  • some nodes eg, S-CSCF
  • the P-CSCF sends the IBCF a SIP INVITE message / request transmitted to request / initiate the IMS service from the terminal. Can be forwarded to (S1520).
  • the P-CSCF may not forward the SIP INVITE message / request transmitted from the UE to the IBCF.
  • the P-CSCF may recognize a failure of the IBCF by not receiving a response to the SIP INVITE message / request according to step S1520 from the IBCF for a predetermined time (S1530).
  • the P-CSCF that recognizes the failure of the IBCF informs the S-CSCF that the IMSF cannot be provided due to the IBCF failure / failure, and indicates that the PDN type of the UE needs to be changed in order to receive the IMS service. It may be informed with information (for example, Public User Identity) (S1540).
  • information for example, Public User Identity
  • the S-CSCF may request the HSS to cancel the registration of the terminal (that is, the terminal corresponding to the received information) and inform the HSS that the PDN type of the terminal needs to be changed to provide the IMS service together with the terminal information. (S1550).
  • the HSS may update the status of the terminal corresponding to the received information of the terminal (ie, deregistration of the terminal) and inform the MME that the PDN type needs to be changed along with the terminal information (S1560).
  • the MME may release the IMS PDN connection of the UE through an MME initiated bearer deactivation procedure (S1570).
  • the terminal may re-request IMS PDN connection with a PDN type different from the previous / last PDN type (S1580).
  • the following two embodiments may exist in a method in which the UE changes to a PDN type different from the previous / last PDN type.
  • the MME may set the cause of transmitting to the terminal when the bearer deactivation procedure request (PDP type IPv4 only allowed) or "PDP type IPv6 only allowed".
  • the UE when re-requesting the IMS PDN connection, changes the PDN type to the allowed PDN type (or a PDN type different from the previously configured PDN type) indicated by the received cause, and re-requests the IMS PDN connection (or Request re-attach).
  • the UE acquires an IMS PDN connection by performing a UE requested PDN Connectivity request by setting / changing the PDN type to an allowed PDN type indicated by the cause obtained from the MME through a bearer deactivation procedure. can do.
  • the MME memorizes the terminal that needs to change the PDN type (for example, to store the identification information of the terminal separately) when receiving the PDN connection request of the terminal, the PDN type that can provide the IMS service to the terminal Can be assigned / set.
  • the MME may store / store a terminal requiring a PDN type change in advance, and when the UE receives a PDN Connectivity request by the terminal, the IMS service is provided to the terminal. It is possible to set / assign a possible PDN type (eg IPv4).
  • the UE may request a PDN connection with a PDN type including a PDN type (eg, IPv4) capable of providing IMS services.
  • the UE may establish a PDN connection with the changed PDN type and then complete the IMS registration procedure. Furthermore, the terminal may transmit a SIP INVITE message / request for requesting an IMS service (or MO service) to the IMS network.
  • the PDN type of the terminal corresponds to a type that can be serviced by an IMS network node (for example, S-CSCF)
  • an IMS network node for example, S-CSCF
  • the P-CSCF which has received the SIP INVITE message / request from the terminal, can transmit / forward the message directly to the S-CSCF without transmitting / forwarding the message to the IBCF. In this case, normal IMS service provision to the terminal is It is possible.
  • PDN type change (or IP) by recognizing the failure of the IBCF by the keep-alive mechanism of nodes (ie, P-CSCF or S-CSCF) that are logically directly connected to the IBCF. Version conversion) may also collectively change the PDN type of the terminal required.
  • the PDN type of the UE requesting service to the IMS network as in the present embodiment It is proposed to perform the PDN type change procedure only when this service type is not available.
  • FIGS. 16 and 17 illustrate an embodiment of changing a PDN type centering on an HSS when providing an MT service.
  • the UE requesting the MT service in FIGS. 18 and 19 may correspond to the UE registered in the IMS network by completing the preliminary procedure of FIG. 8.
  • the following description of the steps to be described later may be applied in the same / similar to the description in Figures 10 to 15, overlapping description is omitted.
  • IBCF interworking function between IMS networks is referred to as IBCF 1 and the PDN type (or IP version) conversion function is referred to as IBCF 2.
  • IBCF 1 operates normally in this drawing / example, and a failure occurs only in IBCF 2.
  • a failure of IBCF 2 causes a PDN type (or an IMS network) not supported by some nodes (eg, S-CSCF) (or IMS networks) in the IMS network. It may be impossible to provide an MT service (or an IMS service) directed to a receiving terminal (MT UE) having an IP version (S1710).
  • the S-CSCF may check whether the PDN type conversion through the IBCF 2 is necessary by checking the PDN type of the receiving terminal. Whether PDN type conversion is required may be determined based on whether the PDN type of the receiving terminal corresponds to a PDN type supported by some nodes (eg, S-CSCF) in the IMS network. To this end, the S-CSCF may use the identification information of the receiving terminal included in the SIP INVITE message / receipt received for the IMS service request / initiation from the calling terminal.
  • some nodes eg, S-CSCF
  • the S-CSCF sends a SIP transmitted for requesting / initiating IMS service from the source UE (MO UE). You can forward INVITE messages / requests to IBCF 2. On the contrary, if it is determined that the PDN type conversion procedure is not necessary (for example, when the PDN type of the terminal is IPv4), the S-CSCF may not forward the SIP INVITE message / request transmitted from the originating terminal to IBCF 2. have.
  • the S-CSCF may recognize the failure of IBCF 2 by not receiving a response to the SIP INVITE message / request according to step S1920 (eg, 200 Trying response) from IBCF 2 for a preset time ( S1730).
  • the PDN type of the originating terminal corresponds to the type that can be serviced by the IMS network of the receiving terminal, but the PDN type of the receiving terminal is (due to the failure of IBCF 2) the receiving terminal. If the service cannot be provided by the IMS network of the network (for example, IPv6), the calling terminal responds with “500 Try After” to cause the calling terminal to resend the SIP INVITE message / request after a certain time. It may be (S1740).
  • the S-CSCF responds to the calling terminal with “606 Not Acceptable with Warning 301 Incompatible network address formats”, thereby preventing the provision of the IMS service. It may be informed that (S1740).
  • step S1940 the S-CSCF confirming that the PDN type of the receiving terminal is a type that cannot be provided with the service, requests the HSS to cancel the registration of the receiving terminal together with the information of the receiving terminal (for example, Public User Identity). It may be informed that the PDN type of the receiving terminal needs to be changed in order to provide the IMS service (S1750).
  • the receiving terminal for example, Public User Identity
  • the HSS may inform the MME that the PDN type of the receiving terminal needs to be changed along with information of the receiving terminal (for example, public user identity) (S1760).
  • the MME may release the IMS PDN connection of the receiving terminal through an MME initiated bearer deactivation procedure (S1770).
  • the receiving terminal may re-request an IMS PDN connection with a PDN type different from the previous / last PDN type (S1780).
  • an embodiment in which the receiving terminal re-requests the IMS PDN connection with the PDN type directly changed or a PDN type whose MME is changed is configured / assigned to the receiving terminal.
  • An embodiment may exist. Detailed descriptions related to these embodiments are overlapped with those described above with reference to FIGS. 14 and 15, and thus detailed descriptions thereof will be omitted.
  • the receiving terminal may complete the IMS registration procedure after establishing a PDN connection with the changed PDN type.
  • the changed PDN type of the receiving terminal corresponds to a type that can be serviced by an IMS network node (eg, S-CSCF) of the calling terminal, a separate IP version conversion procedure by IBCF 2 is unnecessary. Therefore, even if a failure occurs in IBCF 2 and the PDN type conversion is impossible, the IMS service (or MT service) can be normally provided.
  • IMS network node eg, S-CSCF
  • the failure of IBCF 2 is recognized by the keep-alive mechanism of nodes (ie, P-CSCF or S-CSCF) that are logically directly connected to IBCF 2, thereby changing the PDN type ( Alternatively, the PDN type of the receiving terminals requiring IP version conversion) may be collectively changed.
  • the PDN of the receiving terminal requesting a service to the IMS network as in the present embodiment. It is proposed to perform the PDN type change procedure only when the type is an unserviceable type.
  • FIGS. 18 and 19 illustrate an embodiment of changing a PDN type centering on a terminal when providing a MO service.
  • the UE requesting the MO service in FIGS. 18 and 19 may correspond to the UE registered in the IMS network by completing the preliminary procedure of FIG. 8.
  • the description of the steps to be described below may be applied to the same / similar to the description in Figures 10 to 17, overlapping description will be omitted.
  • a PDN type (or an IMS network of a terminal) that is not supported by another node (for example, S-CSCF) (or UE's IMS network) due to a failure in IBCF, a node that performs IP version conversion function in the IMS network.
  • the service may not be provided to the terminal requesting the MO service (IMS service) with the IP version (S1910).
  • the P-CSCF may determine whether the PDN type conversion through the IBCF of the terminal is necessary by checking the PDN type of the terminal requesting the MO service. Whether PDN type conversion is required may be determined based on whether the PDN type currently configured / assigned to the UE is a PDN type supported by some nodes (eg, S-CSCF) in the IMS network.
  • some nodes eg, S-CSCF
  • the P-CSCF sends the IBCF a SIP INVITE message / request transmitted to request / initiate the IMS service from the terminal. Can be forwarded to (S1920).
  • the P-CSCF may not forward the SIP INVITE message / request transmitted from the UE to the IBCF.
  • the P-CSCF may not recognize the failure of the IBCF by not receiving a response to the SIP INVITE message / request according to step S1920 from the IBCF for a predetermined time (S1930).
  • the P-CSCF recognizing the failure of the IBCF, may transmit a "606 Not Acceptable with Warning 301 Incompatible network address format" message to the terminal in response to the SIP INVITE message / request of the terminal (S2140). At this time, the P-CSCF may include an “IP version incompatible” indication in the 606 Not Acceptable response. Through this, the P-CSCF may later allow the terminal to establish an IMS PDN connection as a PDN type that the IMS network can provide.
  • the UE may release the IMS PDN connection through the UE requested PDN disconnection procedure (S1950).
  • the UE may request the IMS PDN connection again by changing the PDN type to a PDN type different from the previous / last PDN type (S1960). As such, the UE may establish a PDN connection with the changed PDN type and then complete the IMS registration procedure. Furthermore, the terminal may transmit a SIP INVITE message / request for requesting an IMS service (or MO service) to the IMS network.
  • PDN type change (or IP) by recognizing the failure of the IBCF by the keep-alive mechanism of nodes (ie, P-CSCF or S-CSCF) that are logically directly connected to the IBCF. Version conversion) may also collectively change the PDN type of the terminal required.
  • the PDN type of the UE requesting service to the IMS network as in the present embodiment It is proposed to perform the PDN type change procedure only when this service type is not available.
  • FIGS. 20 and 21 illustrate an embodiment of changing a PDN type centering on a terminal when providing an MT service.
  • the UE requesting the MT service in FIGS. 20 and 21 may correspond to the UE registered in the IMS network by completing the preliminary procedure of FIG. 8.
  • the description of the steps to be described below may be the same / similar to the description in Figures 10 to 19, overlapping description will be omitted.
  • IBCF interworking function between IMS networks is referred to as IBCF 1 and the PDN type (or IP version) conversion function is referred to as IBCF 2.
  • IBCF 1 operates normally in this drawing / example, and a failure occurs only in IBCF 2.
  • a failure of IBCF 2 causes a PDN type (or an IMS network) not supported by some nodes (eg, S-CSCF) (or IMS networks) in the IMS network. It may be impossible to provide an MT service (or an IMS service) directed to a MT UE having an IP version (S2110).
  • an MT / IMS service request to a receiving terminal having a PDN type that cannot provide IMS service may occur (S2120).
  • the S-CSCF may check whether the PDN type conversion through the IBCF 2 is necessary by checking the PDN type of the receiving terminal. Whether PDN type conversion is required may be determined based on whether the PDN type of the receiving terminal corresponds to a PDN type supported by some nodes (eg, S-CSCF) in the IMS network. To this end, the S-CSCF may use the identification information of the receiving terminal included in the SIP INVITE message / receipt received for the IMS service request / initiation from the calling terminal.
  • the S-CSCF sends a SIP transmitted for requesting / initiating IMS service from the source UE (MO UE). You can forward INVITE messages / requests to IBCF 2. On the contrary, if it is determined that the PDN type conversion procedure is not necessary (for example, when the PDN type of the terminal is IPv4), the S-CSCF may not forward the SIP INVITE message / request transmitted from the originating terminal to IBCF 2. have.
  • the S-CSCF may recognize the failure of IBCF 2 by not receiving a response to the SIP INVITE message / request according to step S2120 (eg, 200 Trying response) from IBCF 2 for a preset time ( S2130).
  • the PDN type of the originating terminal corresponds to the type that can be serviced by the IMS network of the receiving terminal, but the PDN type of the receiving terminal is (due to the failure of IBCF 2) the receiving terminal. If the service cannot be provided by the IMS network of the network (for example, IPv6), the calling terminal responds with “500 Try After” to cause the calling terminal to resend the SIP INVITE message / request after a certain time. It may be (S2140).
  • step S2140 the S-CSCF confirming that the PDN type of the receiving terminal is a type that cannot provide a service, requests the P-CSCF to cancel the registration of the receiving terminal together with the information of the receiving terminal (for example, Public User Identity).
  • the failure / failure of the IBCF (or PDN type change of the receiving terminal is required to provide IMS service) may be notified (S2150).
  • the P-CSCF that has recognized the failure of the IBCF 2 may transmit a “606 Not Acceptable with Warning 301 Incompatible network address format” message / response to the receiving terminal (S2360). At this time, the P-CSCF may include an “IP version incompatible” indication in the 606 Not Acceptable message / response.
  • the receiving terminal may release the IMS PDN connection through the UE requested PDN disconnection procedure (S2170).
  • the receiving terminal may request the IMS PDN connection again by changing the PDN type to a PDN type different from the previous / last PDN type (S2180). As such, the receiving terminal may complete the IMS registration procedure after establishing a PDN connection with the changed PDN type. Furthermore, the receiving terminal may transmit a SIP INVITE message / request for requesting an IMS service (or MO service) to the IMS network.
  • the failure of IBCF 2 is recognized by the keep-alive mechanism of nodes (ie, P-CSCF or S-CSCF) that are logically directly connected to IBCF 2, thereby changing the PDN type ( Alternatively, the PDN type of the receiving terminals requiring IP version conversion) may be collectively changed.
  • the PDN of the receiving terminal requesting a service to the IMS network as in the present embodiment. It is proposed to perform the PDN type change procedure only when the type is an unserviceable type.
  • FIG. 22 is a flowchart illustrating a method of operating a Serving-CSCF (S-CSCF) to support an IP Multimedia Subsystem (IMS) network failure recovery procedure according to an embodiment of the present invention.
  • S-CSCF Serving-CSCF
  • IMS IP Multimedia Subsystem
  • the S-CSCF may receive a SIP INVITE request for requesting an IMS service from a first terminal to a second terminal (S2210).
  • the first terminal may correspond to the MO terminal in the above-described embodiments
  • the second terminal may correspond to the MT terminal.
  • the S-CSCF determines whether the second PDN type assigned to the second terminal is a PDN type serviceable by the IMS network. It may be (S2220).
  • the IMS network may refer to the IMS network of the second terminal side (ie, MT call receiving side).
  • the S-CSCF can find out the PDN types of the first and second terminals based on the information included in the SIP INVITE request received from the first terminal, and the corresponding PDN type can be newly serviced / supported by the IMS network. It is determined whether it is a PDN type.
  • the S-CSCF may transmit a SIP INVITE request to the IBCF (S2230). This is to change the second PDN type of the second terminal to the first PDN type through the IBCF.
  • the S-CSCF may instruct the first terminal to retry the SIP INVITE request after the predetermined time. Furthermore, the S-CSCF may instruct at least one node included in the IMS network to change the second PDN type of the second terminal.
  • At least one node may correspond to a P-CSCF or an HSS, and an embodiment instructing corresponding nodes to change the PDN type of the second terminal is as described above with reference to FIGS. 10 to 21.
  • FIG. 23 is a flowchart illustrating a method of operating a terminal for supporting an IMS (IP Multimedia Subsystem) network failure recovery procedure according to an embodiment of the present invention.
  • IMS IP Multimedia Subsystem
  • a UE may be allocated with a second PDN type and may be connected to an IMS network (S2310).
  • the terminal may correspond to the MT terminal in the above-described embodiments.
  • the IMS network may refer to the IMS network of the second terminal side (ie, MT call receiving side), and it is assumed that the corresponding network is capable of service / support only for the first PDN type.
  • the UE may be instructed to change the second PDN type from another node due to the failure of the IBCF included in the IMS network (S2320).
  • another node may correspond to a P-GW or an MME according to an embodiment.
  • the terminal may release the connection with the IMS network (S2330).
  • the UE may disconnect from the IMS network by receiving a P-GW initiated bearer deactivation procedure request from the P-GW. Can be. At this time, a change of the second PDN type of the UE may be received as a cause of the P-GW initiation bearer deactivation procedure request.
  • the UE may release the connection with the IMS network by receiving an MME initiated bearer deactivation procedure request from the MME.
  • the UE may receive indication information about the first PDN type, which is an acceptable PDN type as a cause of the MME initiation bearer deactivation procedure request.
  • the terminal may reconnect with the IMS network as the first PDN type (S2340).
  • the UE may request reconnection with the IMS network with a PDN type including the first PDN type, and may be allocated the first PDN type by another node (for example, P-GW or MME). have.
  • the terminal may be registered in the IMS network with the assigned first PDN type.
  • FIG. 24 illustrates a block diagram of a communication device according to an embodiment of the present invention.
  • a wireless communication system includes a network node 2410 and a plurality of terminals (UEs) 2420.
  • UEs terminals
  • the network node 2410 includes a processor 2411, a memory 2412, and a communication module 2413.
  • the processor 2411 implements the functions, processes, and / or methods proposed in FIGS. 1 to 24. Layers of the wired / wireless interface protocol may be implemented by the processor 2411.
  • the memory 2412 is connected to the processor 2411 and stores various information for driving the processor 2411.
  • the communication module 2413 is connected to the processor 2411 to transmit and / or receive wired / wireless signals.
  • a base station, an MME, an HSS, an SGW, a PGW, an application server, or the like may correspond thereto.
  • the communication module 2413 may include a radio frequency unit (RF) unit for transmitting / receiving a radio signal.
  • RF radio frequency unit
  • the terminal 2420 includes a processor 2421, a memory 2422, and a communication module (or RF unit) 2423.
  • the processor 2421 implements the functions, processes, and / or methods proposed in FIGS. 1 to 21. Layers of the air interface protocol may be implemented by the processor 2421.
  • the memory 2422 is connected to the processor 2421 and stores various information for driving the processor 2421.
  • the communication module 2423 is connected to the processor 2421 and transmits and / or receives a radio signal.
  • the memories 2412 and 2422 may be inside or outside the processors 2411 and 2421, and may be connected to the processors 2411 and 2421 by various well-known means.
  • the network node 2410 (when the base station) and / or the terminal 2420 may have a single antenna or multiple antennas.
  • 25 illustrates a block diagram of a communication device according to an embodiment of the present invention.
  • FIG. 25 is a diagram illustrating the terminal of FIG. 24 in more detail.
  • a terminal may include a processor (or a digital signal processor (DSP) 2510, an RF module (or an RF unit) 2535, and a power management module 2505).
  • the terminal may also include a single antenna or multiple antennas. Can be.
  • the processor 2510 implements the functions, processes, and / or methods proposed in FIGS. 1 to 23.
  • the layer of the air interface protocol may be implemented by the processor 2510.
  • the memory 2530 is connected to the processor 2510 and stores information related to the operation of the processor 2510.
  • the memory 2530 may be inside or outside the processor 2510 and may be connected to the processor 2510 by various well-known means.
  • the user enters command information, such as a telephone number, for example by pressing (or touching) a button on the keypad 2520 or by voice activation using the microphone 2550.
  • the processor 2510 receives such command information, processes the telephone number, and performs a proper function. Operational data may be extracted from the SIM card 2525 or the memory 2530.
  • the processor 2510 may display command information or driving information on the display 2515 for the user to recognize and for convenience.
  • the RF module 2535 is connected to the processor 2510 and transmits and / or receives an RF signal.
  • the processor 2510 transmits command information to the RF module 2535 to transmit, for example, a radio signal constituting voice communication data to initiate communication.
  • the RF module 2535 is composed of a receiver and a transmitter for receiving and transmitting a radio signal.
  • Antenna 2540 functions to transmit and receive wireless signals. Upon receiving the wireless signal, the RF module 2535 may forward the signal and convert the signal to baseband for processing by the processor 2510. The processed signal may be converted into audible or readable information output through the speaker 2545.
  • each component or feature is to be considered optional unless stated otherwise.
  • Each component or feature may be embodied in a form that is not combined with other components or features. It is also possible to combine some of the components and / or features to form an embodiment of the invention.
  • the order of the operations described in the embodiments of the present invention may be changed. Some components or features of one embodiment may be included in another embodiment or may be replaced with corresponding components or features of another embodiment. It is obvious that the claims may be combined to form an embodiment by combining claims that do not have an explicit citation relationship in the claims or as new claims by post-application correction.
  • Embodiments according to the present invention may be implemented by various means, for example, hardware, firmware, software, or a combination thereof.
  • an embodiment of the present invention may include one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), FPGAs ( field programmable gate arrays), processors, controllers, microcontrollers, microprocessors, and the like.
  • ASICs application specific integrated circuits
  • DSPs digital signal processors
  • DSPDs digital signal processing devices
  • PLDs programmable logic devices
  • FPGAs field programmable gate arrays
  • processors controllers, microcontrollers, microprocessors, and the like.
  • an embodiment of the present invention may be implemented in the form of a module, procedure, function, etc. that performs the functions or operations described above.
  • the software code may be stored in memory and driven by the processor.
  • the memory may be located inside or outside the processor, and may exchange data with the processor by various known means.

Landscapes

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

Abstract

IMS 네트워크 장애 복구 절차를 지원하기 위한 S-CSCF의 동작 방법에 있어서, 제1 단말로부터 제2 단말로 향하는 IMS 서비스를 요청하기 위한 SIP INVITE 요청을 수신하는 단계; 제1 단말에 할당된 제1 PDN 타입이 IMS 네트워크에 의해 서비스 가능한 PDN 타입인 경우, 제2 단말에 할당된 제2 PDN 타입이 IMS 네트워크에 의해 서비스 가능한 PDN 타입인지 판단하는 단계; 제2 PDN 타입이 IMS 네트워크에 의해 서비스 불가능한 PDN 타입인 경우, SIP INVITE 요청을 IBCF로 전달하는 단계; 및 IBCF로부터 SIP INVITE 요청에 대한 응답을 기설정된 시간 동안 미수신하는 경우, 제1 단말에게 기설정된 시간 후에 SIP INVITE 요청의 재시도를 지시하고, IMS 네트워크에 포함된 적어도 하나의 노드에 제2 단말의 제2 PDN 타입을 변경하도록 지시하는 단계; 를 포함할 수 있다.

Description

[규칙 제26조에 의한 보정 18.08.2016]　인터넷 프로토콜 멀티미디어 서브시스템 네트워크의 장애 복구 지원 방법 및 이를 위한 장치
본 발명은 무선 통신 시스템에 관한 것으로서, 보다 상세하게는 IMS 네트워크의 장애 복구를 지원하기 위한 방법 및 이를 지원하는 장치에 관한 것이다.
이동 통신 시스템은 사용자의 활동성을 보장하면서 음성 서비스를 제공하기 위해 개발되었다. 그러나 이동통신 시스템은 음성뿐 아니라 데이터 서비스까지 영역을 확장하였으며, 현재에는 폭발적인 트래픽의 증가로 인하여 자원의 부족 현상이 야기되고 사용자들이 보다 고속의 서비스에 대한 요구하므로, 보다 발전된 이동 통신 시스템이 요구되고 있다.
차세대 이동 통신 시스템의 요구 조건은 크게 폭발적인 데이터 트래픽의 수용, 사용자 당 전송률의 획기적인 증가, 대폭 증가된 연결 디바이스 개수의 수용, 매우 낮은 단대단 지연(End-to-End Latency), 고에너지 효율을 지원할 수 있어야 한다. 이를 위하여 이중 연결성(Dual Connectivity), 대규모 다중 입출력(Massive MIMO: Massive Multiple Input Multiple Output), 전이중(In-band Full Duplex), 비직교 다중접속(NOMA: Non-Orthogonal Multiple Access), 초광대역(Super wideband) 지원, 단말 네트워킹(Device Networking) 등 다양한 기술들이 연구되고 있다.
특히, 최근에는 전력 소모가 기기의 수명에 큰 영향을 미치는 기기를 위하여, 전력 소모를 줄이기 위한 다양한 기술들이 활발하게 연구되고 있는 실정이다.
3GPP에서 IMS의 설계 시, IETF(Internet Engineering Task Force) 표준에서 기존의 IP(Internet Protocol) 버전 4(이하, ‘IPv4’)와는 다른 별도의 IP 버전 6(이하, ‘IPv6’를 표준화하였다. 3GPP는 IMS를 위한 IPv6의 적용 가능성을 분석하였으며, IPv6는 인터넷 상에서 가장 흔한(또는 공통적인) IP 버전이 될 것이라고 예상하였다. 그러나, 이러한 예상과는 달리 현재 대부분의 인터넷에서는 여전히 IPv4를 운영하고 있으며, 현재 오로지 몇몇의 모바일 네트워크만이 IPv6를 도입할 준비가 되어있다.
따라서, 현재 IMS에서는 IMS 단말 및 네트워크 노드들에서 IPv6 및 IPv4의 상호 연동을 위한 듀얼 스택 실행(또는 듀얼 스택 변환 시스템)이 허용되고 있다. 특히, IMS에서 IBCF(Interconnection Border Control Functions)는 IP 버전을 변환함으로써 IPv4 및 IPv6 사이의 상호 연동(또는 IPv4 SIP 어플리케이션과 IPv6 SIP 어플리케이션 사이의 통신 기능)을 지원한다.
종래의 IMS 복구 절차는 IMS 네트워크에서 특정 노드에 장애가 발생했을 경우, 해당 노드의 장애를 인지한 후 장애가 발생한 노드의 기능을 다른 노드가 대신하도록 함으로써 장애를 해결하는 방안을 제안한다. 그러나, 이러한 종래의 IMS 복구 절차는 IBCF에서 장애가 발생한 경우에 대한 해결 방안은 제시하고 있지 않다.
따라서, 본 명세서에서는 이러한 IBCF에서 장애가 발생하더라도 IMS 서비스를 문제없이 단말에게 제공하기 위한 대안적인 메커니즘을 제안함을 그 목적으로 한다.
상술한 기술적 과제를 해결하기 위한 방법 및 장치에 관한 실시예를 제안한다. 본 발명에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 발명의 일 실시예에 따른 IMS(IP Multimedia Subsystem) 네트워크 장애 복구(restoration) 절차를 지원하기 위한 S-CSCF(Serving-CSCF)의 동작 방법에 있어서, 제1 단말로부터 제2 단말로 향하는 IMS 서비스를 요청하기 위한 SIP(Session Initiation Protocol) INVITE 요청을 수신하는 단계; 상기 제1 단말에 할당된 제1 PDN(Packet Data Network) 타입이 상기 IMS 네트워크에 의해 서비스 가능한 PDN 타입인 경우, 상기 제2 단말에 할당된 제2 PDN 타입이 상기 IMS 네트워크에 의해 서비스 가능한 PDN 타입인지 판단하는 단계; 상기 제2 PDN 타입이 상기 IMS 네트워크에 의해 서비스 불가능한 PDN 타입인 경우, 상기 수신한 SIP INVITE 요청을 IBCF(Interconnection Border Control Functions)로 전달하는 단계; 및 상기 IBCF로부터 상기 SIP INVITE 요청에 대한 응답을 기설정된 시간 동안 미수신하는 경우, 상기 제1 단말에게 기설정된 시간 후에 상기 SIP INVITE 요청의 재시도를 지시하고, 상기 IMS 네트워크에 포함된 적어도 하나의 노드에 상기 제2 단말의 상기 제2 PDN 타입을 변경하도록 지시하는 단계; 를 포함할 수 있다.
또한, 상기 IMS 네트워크에 의해 서비스 불가능한 PDN 타입은 상기 S-CSCF가 지원하지 않는 PDN 타입에 해당할 수 있다.
또한, 상기 제1 PDN 타입은 IP(Internet Protocol) 버전 4에 해당하며, 상기 제2 PDN 타입은 IP 버전 6에 해당할 수 있다.
또한, 상기 IMS 네트워크에 포함된 적어도 하나의 노드가 P-CSCF(Proxy-CSCF)에 해당하는 경우, 상기 제2 단말의 상기 제2 PDN 타입을 변경하도록 지시하는 단계는, 상기 P-CSCF에 상기 제2 단말의 식별 정보와 함께 상기 제2 단말의 상기 제2 PDN 타입을 변경하도록 지시하는 단계일 수 있다.
또한, 상기 제2 단말의 식별 정보 및 상기 제2 PDN 타입의 변경은, 상기 P-CSCF에 의해 PCRF(Policy and Charging Rules Function)를 거쳐 P-GW(Packet Data Network Gateway)로 지시될 수 있다.
또한, 상기 제2 단말의 식별 정보 및 상기 제2 PDN 타입의 변경은, Rx AAR(Authorization Authentication Request) 메시지를 통해 상기 P-CSCF로부터 상기 PCRF에게 지시되며, Gx RAR(Re-Authorization Request) 메시지를 통해 상기 PCRF로부터 상기 P-GW에게 지시될 수 있다.
또한, 상기 IMS 네트워크에 의한 서비스가 불가함은 상기 P-CSCF에 의해 상기 제2 단말에게 지시될 수 있다.
또한, 상기 IMS 네트워크에 포함된 적어도 하나의 노드가 HSS에 해당하는 경우, 상기 제2 단말의 상기 제2 PDN 타입을 변경하도록 지시하는 단계는, 상기 HSS(Home Subscriber Server)에 상기 제2 단말의 식별 정보와 함께 상기 제2 단말의 상기 제2 PDN 타입의 변경을 지시하고, 상기 제2 단말의 등록 취소를 요청하는 단계일 수 있다.
또한, 상기 제2 단말의 식별 정보, 상기 제2 PDN 타입의 변경 및 제2 단말의 등록 취소는, 상기 HSS에 의해 MME(Mobility Management Entity)에게 지시되며, 상기 HSS의 지시에 따라 상기 MME에 의해 개시된 MME 개시 베어러 비활성화 절차(MME initiated bearer deactivation)를 통해 상기 제2 단말의 상기 IMS 네트워크에 대한 IMS 연결이 해제될 수 있다.
또한, 본 발명의 다른 실시예에 따른 IMS(IP Multimedia Subsystem) 네트워크 장애 복구(restoration) 절차를 지원하기 위한 단말의 동작 방법에 있어서, 제2 PDN 타입을 할당 받아 상기 IMS 네트워크와 연결되는 단계; 로서, 상기 IMS 네트워크에 포함된 S-CSCF는 제1 PDN 타입을 지원함, 다른 노드로부터 상기 IMS 네트워크에 포함된 IBCF의 장애로 인하여 상기 제2 PDN 타입을 변경하도록 지시받는 단계; 상기 IMS 네트워크와의 연결을 해제하는 단계; 및 상기 제1 PDN 타입으로 상기 IMS 네트워크와 재연결되는 단계; 를 포함할 수 있다.
또한, 상기 다른 노드가 P-GW에 해당하는 경우, 상기 IMS 네트워크와의 연결을 해제하는 단계는, 상기 P-GW로부터 P-GW 개시 베어러 비활성화 절차(P-GW initiated Bearer deactivation procedure) 요청을 수신하되, 상기 절차 요청의 원인으로서 상기 제2 PDN 타입의 변경을 수신하는 단계; 를 포함할 수 있다.
또한, 상기 제1 PDN 타입으로 상기 IMS 네트워크와 재연결되는 단계는, 상기 제1 PDN 타입이 포함된 PDN 타입으로 상기 IMS 네트워크와의 재연결을 요청하는 단계; 상기 P-GW에 의해 상기 제1 PDN 타입을 할당 받는 단계; 및 상기 제1 PDN 타입으로 상기 IMS 네트워크에 등록되는 단계; 를 포함할 수 있다.
또한, 상기 다른 노드가 MME에 해당하는 경우, 상기 IMS 네트워크와의 연결을 해제하는 단계는, 상기 MME로부터 MME 개시 베어러 비활성화 절차(MME initiated Bearer deactivation procedure) 요청을 수신하되, 상기 절차 요청의 원인으로서 허용 가능한 PDN 타입인 상기 제1 PDN 타입에 관한 지시 정보를 수신하는 단계; 를 포함할 수 있다.
또한, 상기 제1 PDN 타입으로 상기 IMS 네트워크와 재연결되는 단계는, 상기 제1 PDN 타입이 포함된 PDN 타입으로 상기 IMS 네트워크와의 재연결을 요청하는 단계; 상기 MME에 의해 상기 제1 PDN 타입을 할당 받는 단계; 및 상기 제1 PDN 타입으로 상기 IMS 네트워크에 등록되는 단계; 를 포함할 수 있다.
또한, 상기 다른 노드가 P-CSCF에 해당하는 경우, 상기 제1 PDN 타입으로 상기 IMS 네트워크와 재연결되는 단계는, 상기 제1 PDN 타입이 포함된 PDN 타입으로 상기 IMS 네트워크와의 재연결을 요청하는 단계; 상기 P-CSCF에 의해 상기 제1 PDN 타입을 할당 받는 단계; 및 상기 제1 PDN 타입으로 상기 IMS 네트워크에 등록되는 단계; 를 포함할 수 있다.
본 발명의 일 실시예에 따르면, IMS 네트워크 내 IBCF에서 장애가 발생하더라도, IMS 서비스를 문제 없이 단말에게 제공할 수 있다는 효과를 갖는다.
본 발명에서 얻을 수 있는 효과는 이상에서 언급한 효과로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 발명에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되는, 첨부 도면은 본 발명에 대한 실시예를 제공하고, 상세한 설명과 함께 본 발명의 기술적 특징을 설명한다.
도 1은 본 발명이 적용될 수 있는 EPS(Evolved Packet System)을 간략히 예시하는 도면이다.
도 2는 본 발명이 적용될 수 있는 E-UTRAN(evolved universal terrestrial radio access network)의 네트워크 구조의 일 예를 나타낸다.
도 3은 본 발명이 적용될 수 있는 무선 통신 시스템에서 E-UTRAN 및 EPC의 구조를 예시한다.
도 4는 본 발명이 적용될 수 있는 무선 통신 시스템에서 단말과 E-UTRAN 사이의 무선 인터페이스 프로토콜(radio interface protocol) 구조를 나타낸다.
도 5는 본 발명이 적용될 수 있는 무선 통신 시스템에서 물리 채널의 구조를 간략히 예시하는 도면이다.
도 6은 본 발명이 적용될 수 있는 무선 통신 시스템에서 경쟁 기반 랜덤 액세스 절차를 설명하기 위한 도면이다.
도 7은 본 발명의 일 실시예에 따른 IMS 구조를 예시한 도면이다.
도 8은 상위 레벨 관점에서의 IMS를 위한 사전 절차를 예시한 도면이다.
도 9는 본 발명의 일 실시예에 따른 IBCF에서 장애가 발생한 경우의 실시예를 예시한 도면이다.
도 10 및 11은 MO 서비스 제공 시, PCRF를 중심으로 한 PDN 타입 변경 실시예를 예시한 도면이다.
도 12 및 13은 MT 서비스 제공 시, PCRF를 중심으로 한 PDN 타입 변경 실시예를 예시한 도면이다.
도 14 및 15는 MO 서비스 제공 시, HSS를 중심으로 한 PDN 타입 변경 실시예를 예시한 도면이다.
도 16 및 17은 MT 서비스 제공 시, HSS를 중심으로 한 PDN 타입 변경 실시예를 예시한 도면이다.
도 18 및 19는 MO 서비스 제공 시, 단말을 중심으로 한 PDN 타입 변경 실시예를 예시한 도면이다.
도 20 및 21은 MT 서비스 제공 시, 단말을 중심으로 한 PDN 타입 변경 실시예를 예시한 도면이다.
도 22는 본 발명의 일 실시예에 따른 IMS 네트워크 장애 복구 절차를 지원하기 위한 S-CSCF의 동작 방법을 예시한 순서도이다.
도 23은 본 발명의 일 실시예에 따른 IMS(IP Multimedia Subsystem) 네트워크 장애 복구(restoration) 절차를 지원하기 위한 단말의 동작 방법을 예시한 순서도이다.
도 24는 본 발명의 일 실시예에 따른 통신 장치의 블록 구성도를 예시한다.
도 25는 본 발명의 일 실시예에 따른 통신 장치의 블록 구성도를 예시한다.
이하, 본 발명에 따른 바람직한 실시 형태를 첨부된 도면을 참조하여 상세하게 설명한다. 첨부된 도면과 함께 이하에 개시될 상세한 설명은 본 발명의 예시적인 실시형태를 설명하고자 하는 것이며, 본 발명이 실시될 수 있는 유일한 실시형태를 나타내고자 하는 것이 아니다. 이하의 상세한 설명은 본 발명의 완전한 이해를 제공하기 위해서 구체적 세부사항을 포함한다. 그러나, 당업자는 본 발명이 이러한 구체적 세부사항 없이도 실시될 수 있음을 안다.
몇몇 경우, 본 발명의 개념이 모호해지는 것을 피하기 위하여 공지의 구조 및 장치는 생략되거나, 각 구조 및 장치의 핵심기능을 중심으로 한 블록도 형식으로 도시될 수 있다.
본 명세서에서 기지국은 단말과 직접적으로 통신을 수행하는 네트워크의 종단 노드(terminal node)로서의 의미를 갖는다. 본 문서에서 기지국에 의해 수행되는 것으로 설명된 특정 동작은 경우에 따라서는 기지국의 상위 노드(upper node)에 의해 수행될 수도 있다. 즉, 기지국을 포함하는 다수의 네트워크 노드들(network nodes)로 이루어지는 네트워크에서 단말과의 통신을 위해 수행되는 다양한 동작들은 기지국 또는 기지국 이외의 다른 네트워크 노드들에 의해 수행될 수 있음은 자명하다. '기지국(BS: Base Station)'은 고정국(fixed station), Node B, eNB(evolved-NodeB), BTS(base transceiver system), 액세스 포인트(AP: Access Point) 등의 용어에 의해 대체될 수 있다. 또한, '단말(Terminal)'은 고정되거나 이동성을 가질 수 있으며, UE(User Equipment), MS(Mobile Station), UT(user terminal), MSS(Mobile Subscriber Station), SS(Subscriber Station), AMS(Advanced Mobile Station), WT(Wireless terminal), MTC(Machine-Type Communication) 장치, M2M(Machine-to-Machine) 장치, D2D(Device-to-Device) 장치 등의 용어로 대체될 수 있다.
이하에서, 하향링크(DL: downlink)는 기지국에서 단말로의 통신을 의미하며, 상향링크(UL: uplink)는 단말에서 기지국으로의 통신을 의미한다. 하향링크에서 송신기는 기지국의 일부이고, 수신기는 단말의 일부일 수 있다. 상향링크에서 송신기는 단말의 일부이고, 수신기는 기지국의 일부일 수 있다.
이하의 설명에서 사용되는 특정 용어들은 본 발명의 이해를 돕기 위해서 제공된 것이며, 이러한 특정 용어의 사용은 본 발명의 기술적 사상을 벗어나지 않는 범위에서 다른 형태로 변경될 수 있다.
이하의 기술은 CDMA(code division multiple access), FDMA(frequency division multiple access), TDMA(time division multiple access), OFDMA(orthogonal frequency division multiple access), SC-FDMA(single carrier frequency division multiple access), NOMA(non-orthogonal multiple access) 등과 같은 다양한 무선 접속 시스템에 이용될 수 있다. CDMA는 UTRA(universal terrestrial radio access)나 CDMA2000과 같은 무선 기술(radio technology)로 구현될 수 있다. TDMA는 GSM(global system for mobile communications)/GPRS(general packet radio service)/EDGE(enhanced data rates for GSM evolution)와 같은 무선 기술로 구현될 수 있다. OFDMA는 IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802-20, E-UTRA(evolved UTRA) 등과 같은 무선 기술로 구현될 수 있다. UTRA는 UMTS(universal mobile telecommunications system)의 일부이다. 3GPP(3rd generation partnership project) LTE(long term evolution)은 E-UTRA를 사용하는 E-UMTS(evolved UMTS)의 일부로써, 하향링크에서 OFDMA를 채용하고 상향링크에서 SC-FDMA를 채용한다. LTE-A(advanced)는 3GPP LTE의 진화이다.
본 발명의 실시예들은 무선 접속 시스템들인 IEEE 802, 3GPP 및 3GPP2 중 적어도 하나에 개시된 표준 문서들에 의해 뒷받침될 수 있다. 즉, 본 발명의 실시예들 중 본 발명의 기술적 사상을 명확히 드러내기 위해 설명하지 않은 단계들 또는 부분들은 상기 문서들에 의해 뒷받침될 수 있다. 또한, 본 문서에서 개시하고 있는 모든 용어들은 상기 표준 문서에 의해 설명될 수 있다.
설명을 명확하게 하기 위해, 3GPP LTE/LTE-A를 위주로 기술하지만 본 발명의 기술적 특징이 이에 제한되는 것은 아니다.
본 문서에서 사용될 수 있는 용어들은 다음과 같이 정의된다.
- UMTS(Universal Mobile Telecommunications System): 3GPP에 의해서 개발된, GSM(Global System for Mobile Communication) 기반의 3 세대(Generation) 이동 통신 기술
- EPS(Evolved Packet System): IP(Internet Protocol) 기반의 패킷 교환(packet switched) 코어 네트워크인 EPC(Evolved Packet Core)와 LTE, UTRAN 등의 액세스 네트워크로 구성된 네트워크 시스템. UMTS가 진화된 형태의 네트워크이다.
- NodeB: UMTS 네트워크의 기지국. 옥외에 설치하며 커버리지는 매크로 셀(macro cell) 규모이다.
- eNodeB: EPS 네트워크의 기지국. 옥외에 설치하며 커버리지는 매크로 셀(macro cell) 규모이다.
- 단말(User Equipment): 사용자 기기. 단말은 단말(terminal), ME(Mobile Equipment), MS(Mobile Station) 등의 용어로 언급될 수 있다. 또한, 단말은 노트북, 휴대폰, PDA(Personal Digital Assistant), 스마트폰, 멀티미디어 기기 등과 같이 휴대 가능한 기기일 수 있고, 또는 PC(Personal Computer), 차량 탑재 장치와 같이 휴대 불가능한 기기일 수도 있다. MTC 관련 내용에서 단말 또는 단말이라는 용어는 MTC 단말을 지칭할 수 있다.
- IMS(IP Multimedia Subsystem): 멀티미디어 서비스를 IP 기반으로 제공하는 서브시스템.
- IMSI(International Mobile Subscriber Identity): 이동 통신 네트워크에서 국제적으로 고유하게 할당되는 사용자 식별자.
- MTC(Machine Type Communication): 사람의 개입 없이 머신에 의해 수행되는 통신. M2M(Machine to Machine) 통신이라고 지칭할 수도 있다.
- MTC 단말(MTC UE 또는 MTC device 또는 MTC 장치): 이동 통신 네트워크를 통한 통신(예를 들어, PLMN을 통해 MTC 서버와 통신) 기능을 가지고, MTC 기능을 수행하는 단말(예를 들어, 자판기, 검침기 등).
- MTC 서버(MTC server): MTC 단말을 관리하는 네트워크 상의 서버. 이동 통신 네트워크의 내부 또는 외부에 존재할 수 있다. MTC 사용자가 접근(access)할 수 있는 인터페이스를 가질 수 있다. 또한, MTC 서버는 다른 서버들에게 MTC 관련 서비스를 제공할 수도 있고(SCS(Services Capability Server) 형태), 자신이 MTC 어플리케이션 서버일 수도 있다.
- (MTC) 어플리케이션(application): (MTC가 적용되는) 서비스(예를 들어, 원격 검침, 물량 이동 추적, 기상 관측 센서 등)
- (MTC) 어플리케이션 서버: (MTC) 어플리케이션이 실행되는 네트워크 상의 서버
- MTC 특징(MTC feature): MTC 어플리케이션을 지원하기 위한 네트워크의 기능. 예를 들어, MTC 모니터링(monitoring)은 원격 검침 등의 MTC 어플리케이션에서 장비 분실 등을 대비하기 위한 특징이고, 낮은 이동성(low mobility)은 자판기와 같은 MTC 단말에 대한 MTC 어플리케이션을 위한 특징이다.
- MTC 사용자(MTC User): MTC 사용자는 MTC 서버에 의해 제공되는 서비스를 사용한다.
- MTC 가입자(MTC subscriber): 네트워크 오퍼레이터와 접속 관계를 가지고 있으며, 하나 이상의 MTC 단말에게 서비스를 제공하는 엔티티(entity)이다.
- MTC 그룹(MTC group): 적어도 하나 이상의 MTC 특징을 공유하며, MTC 가입자에 속한 MTC 단말의 그룹을 의미한다.
- 서비스 역량 서버(SCS: Services Capability Server): HPLMN(Home PLMN) 상의 MTC-IWF(MTC InterWorking Function) 및 MTC 단말과 통신하기 위한 엔티티로서, 3GPP 네트워크와 접속되어 있다. SCS는 하나 이상의 MTC 어플리케이션에 의한 사용을 위한 능력(capability)를 제공한다.
- 외부 식별자(External Identifier): 3GPP 네트워크의 외부 엔티티(예를 들어, SCS 또는 어플리케이션 서버)가 MTC 단말(또는 MTC 단말이 속한 가입자)을 가리키기(또는 식별하기) 위해 사용하는 식별자(identifier)로서 전세계적으로 고유(globally unique)하다. 외부 식별자는 다음과 같이 도메인 식별자(Domain Identifier)와 로컬 식별자(Local Identifier)로 구성된다.
- 도메인 식별자(Domain Identifier): 이동 통신 네트워크 사업자의 제어 항에 있는 도메인을 식별하기 위한 식별자. 하나의 사업자는 서로 다른 서비스로의 접속을 제공하기 위해 서비스 별로 도메인 식별자를 사용할 수 있다.
- 로컬 식별자(Local Identifier): IMSI(International Mobile Subscriber Identity)를 유추하거나 획득하는데 사용되는 식별자. 로컬 식별자는 어플리케이션 도메인 내에서는 고유(unique)해야 하며, 이동 통신 네트워크 사업자에 의해 관리된다.
- RAN(Radio Access Network): 3GPP 네트워크에서 Node B 및 이를 제어하는 RNC(Radio Network Controller), eNodeB를 포함하는 단위. 단말 단에 존재하며 코어 네트워크로의 연결을 제공한다.
- HLR(Home Location Register)/HSS(Home Subscriber Server): 3GPP 네트워크 내의 가입자 정보를 가지고 있는 데이터베이스. HSS는 설정 저장(configuration storage), 식별자 관리(identity management), 사용자 상태 저장 등의 기능을 수행할 수 있다.
- RANAP(RAN Application Part): RAN과 코어 네트워크의 제어를 담당하는 노드(즉, MME(Mobility Management Entity)/SGSN(Serving GPRS(General Packet Radio Service) Supporting Node)/MSC(Mobile Switching Center)) 사이의 인터페이스.
- PLMN(Public Land Mobile Network): 개인들에게 이동 통신 서비스를 제공할 목적으로 구성된 네트워크. 오퍼레이터 별로 구분되어 구성될 수 있다.
- NAS(Non-Access Stratum): UMTS, EPS 프로토콜 스택에서 단말과 코어 네트워크 간의 시그널링, 트래픽 메시지를 주고 받기 위한 기능적인 계층. 단말의 이동성을 지원하고, 단말과 PDN GW 간의 IP 연결을 수립 및 유지하는 세션 관리 절차를 지원하는 것을 주된 기능으로 한다.
- SCEF(Service Capability Exposure Function): 3GPP 네트워크 인터페이스에 의해 제공되는 서비스 및 능력(capability)를 안전하게 노출하기 위한 수단을 제공하는 서비스 능력 노출(service capability exposure)을 위한 3GPP 아키텍쳐 내 엔티티.
이하, 위와 같이 정의된 용어를 바탕으로 본 발명에 대하여 기술한다.
본 발명이 적용될 수 있는 시스템 일반
도 1은 본 발명이 적용될 수 있는 EPS (Evolved Packet System)을 간략히 예시하는 도면이다.
도 1의 네트워크 구조도는 EPC(Evolved Packet Core)를 포함하는 EPS(Evolved Packet System)의 구조를 이를 간략하게 재구성 한 것이다.
EPC(Evolved Packet Core)는 3GPP 기술들의 성능을 향상하기 위한 SAE(System Architecture Evolution)의 핵심적인 요소이다. SAE는 다양한 종류의 네트워크 간의 이동성을 지원하는 네트워크 구조를 결정하는 연구 과제에 해당한다. SAE는, 예를 들어, IP 기반으로 다양한 무선 접속 기술들을 지원하고 보다 향상된 데이터 전송 능력을 제공하는 등의 최적화된 패킷-기반 시스템을 제공하는 것을 목표로 한다.
구체적으로, EPC는 3GPP LTE 시스템을 위한 IP 이동 통신 시스템의 코어 네트워크(Core Network)이며, 패킷-기반 실시간 및 비실시간 서비스를 지원할 수 있다. 기존의 이동 통신 시스템(즉, 2 세대 또는 3 세대 이동 통신 시스템)에서는 음성을 위한 CS(Circuit-Switched) 및 데이터를 위한 PS(Packet-Switched)의 2 개의 구별되는 서브-도메인을 통해서 코어 네트워크의 기능이 구현되었다. 그러나, 3 세대 이동 통신 시스템의 진화인 3GPP LTE 시스템에서는, CS 및 PS의 서브-도메인들이 하나의 IP 도메인으로 단일화되었다. 즉, 3GPP LTE 시스템에서는, IP 능력(capability)을 가지는 단말과 단말 간의 연결이, IP 기반의 기지국(예를 들어, eNodeB(evolved Node B)), EPC, 애플리케이션 도메인(예를 들어, IMS)을 통하여 구성될 수 있다. 즉, EPC는 단-대-단(end-to-end) IP 서비스 구현에 필수적인 구조이다.
EPC는 다양한 구성요소들을 포함할 수 있으며, 도 1에서는 그 중에서 일부에 해당하는, SGW(Serving Gateway)(또는 S-GW), PDN GW(Packet Data Network Gateway)(또는 PGW 또는 P-GW), MME(Mobility Management Entity), SGSN(Serving GPRS(General Packet Radio Service) Supporting Node), ePDG(enhanced Packet Data Gateway)를 도시한다.
SGW는 무선 접속 네트워크(RAN)와 코어 네트워크 사이의 경계점으로서 동작하고, eNodeB와 PDN GW 사이의 데이터 경로를 유지하는 기능을 하는 요소이다. 또한, 단말이 eNodeB에 의해서 서빙(serving)되는 영역에 걸쳐 이동하는 경우, SGW는 로컬 이동성 앵커 포인트(anchor point)의 역할을 한다. 즉, E-UTRAN (3GPP 릴리즈-8 이후에서 정의되는 Evolved-UMTS(Universal Mobile Telecommunications System) Terrestrial Radio Access Network) 내에서의 이동성을 위해서 SGW를 통해서 패킷들이 라우팅될 수 있다. 또한, SGW는 다른 3GPP 네트워크(3GPP 릴리즈-8 전에 정의되는 RAN, 예를 들어, UTRAN 또는 GERAN(GSM(Global System for Mobile Communication)/EDGE(Enhanced Data rates for Global Evolution) Radio Access Network)와의 이동성을 위한 앵커 포인트로서 기능할 수도 있다.
PDN GW는 패킷 데이터 네트워크를 향한 데이터 인터페이스의 종단점(termination point)에 해당한다. PDN GW는 정책 집행 특징(policy enforcement features), 패킷 필터링(packet filtering), 과금 지원(charging support) 등을 지원할 수 있다. 또한, 3GPP 네트워크와 비-3GPP(non-3GPP) 네트워크 (예를 들어, I-WLAN(Interworking Wireless Local Area Network)과 같은 신뢰되지 않는 네트워크, CDMA(Code Division Multiple Access) 네트워크나 Wimax와 같은 신뢰되는 네트워크)와의 이동성 관리를 위한 앵커 포인트 역할을 할 수 있다.
도 1의 네트워크 구조의 예시에서는 SGW와 PDN GW가 별도의 게이트웨이로 구성되는 것을 나타내지만, 두 개의 게이트웨이가 단일 게이트웨이 구성 옵션(Single Gateway Configuration Option)에 따라 구현될 수도 있다.
MME는, 단말의 네트워크 연결에 대한 액세스, 네트워크 자원의 할당, 트래킹(tracking), 페이징(paging), 로밍(roaming) 및 핸드오버 등을 지원하기 위한 시그널링 및 제어 기능들을 수행하는 요소이다. MME는 가입자 및 세션 관리에 관련된 제어 평면 기능들을 제어한다. MME는 수많은 eNodeB들을 관리하고, 다른 2G/3G 네트워크에 대한 핸드오버를 위한 종래의 게이트웨이의 선택을 위한 시그널링을 수행한다. 또한, MME는 보안 과정(Security Procedures), 단말-대-네트워크 세션 핸들링(Terminal-to-network Session Handling), 유휴 단말 위치결정 관리(Idle Terminal Location Management) 등의 기능을 수행한다.
SGSN은 다른 3GPP 네트워크(예를 들어, GPRS 네트워크)에 대한 사용자의 이동성 관리 및 인증(authentication)과 같은 모든 패킷 데이터를 핸들링한다.
ePDG는 신뢰되지 않는 비-3GPP 네트워크(예를 들어, I-WLAN, WiFi 핫스팟(hotspot) 등)에 대한 보안 노드로서의 역할을 한다.
도 1을 참조하여 설명한 바와 같이, IP 능력을 가지는 단말은, 3GPP 액세스는 물론 비-3GPP 액세스 기반으로도 EPC 내의 다양한 요소들을 경유하여 사업자(즉, 오퍼레이터(operator))가 제공하는 IP 서비스 네트워크(예를 들어, IMS)에 액세스할 수 있다.
또한, 도 1에서는 다양한 레퍼런스 포인트들(예를 들어, S1-U, S1-MME 등)을 도시한다. 3GPP 시스템에서는 E-UTRAN 및 EPC의 상이한 기능 개체(functional entity)들에 존재하는 2 개의 기능을 연결하는 개념적인 링크를 레퍼런스 포인트(reference point)라고 정의한다. 다음의 표 1은 도 1에 도시된 레퍼런스 포인트를 정리한 것이다. 표 1의 예시들 외에도 네트워크 구조에 따라 다양한 레퍼런스 포인트(reference point)들이 존재할 수 있다.
Figure PCTKR2016008908-appb-T000001
도 1에 도시된 레퍼런스 포인트 중에서 S2a 및 S2b는 비-3GPP 인터페이스에 해당한다. S2a는 신뢰되는 비-3GPP 액세스 및 PDN GW 간의 관련 제어 및 이동성 자원을 사용자 플레인에 제공하는 레퍼런스 포인트이다. S2b는 ePDG 및 PDN GW 간의 관련 제어 및 이동성 지원을 사용자 플레인에 제공하는 레퍼런스 포인트이다.
PCRF(Policy Control and Charging Rules Function)은 단말에게 적용할 정책(Policy), 서비스 품질(QoS: Quality of Service) 등을 동적(dynamic)으로 적용하기 위한 정책 결정(Policy decision)을 수행하는 노드이다. PCRF에서 생성된 PCC(Policy and Charging Control) 규칙은 PDN GW로 전달된다.
본 도면에서 Gx는 PCRF와 P-GW 간의 제어 평면 프로토콜에 대한 레퍼런스 포인트에 해당할 수 있다. 또한, SGi는 PDN GW 및 PDN 사이의 레퍼런스 포인트에 해당할 수 있다. 여기서, PDN은 오퍼레이터 외부 공용 또는 사설 PDN이거나 오퍼레이터 내 PDN(예를 들어, IMS 서비스)에 해당할 수 있다.
도 2는 본 발명이 적용될 수 있는 E-UTRAN(evolved universal terrestrial radio access network)의 네트워크 구조의 일 예를 나타낸다.
E-UTRAN 시스템은 기존 UTRAN 시스템에서 진화한 시스템으로, 예를 들어, 3GPP LTE/LTE-A 시스템일 수 있다. 통신 네트워크는 IMS 및 패킷 데이터를 통해 음성(voice)(예를 들어, VoIP(Voice over Internet Protocol))과 같은 다양한 통신 서비스를 제공하기 위하여 광범위하게 배치된다.
도 2를 참조하면, E-UMTS 네트워크는 E-UTRAN, EPC 및 하나 이상의 UE를 포함한다. E-UTRAN은 단말에게 제어 평면(control plane)과 사용자 평면(user plane) 프로토콜을 제공하는 eNB들로 구성되고, eNB들은 X2 인터페이스를 통해 연결된다.
X2 사용자 평면 인터페이스(X2-U)는 eNB들 사이에 정의된다. X2-U 인터페이스는 사용자 평면 PDU(packet data unit)의 보장되지 않은 전달(non guaranteed delivery)을 제공한다. X2 제어 평면 인터페이스(X2-CP)는 두 개의 이웃 eNB 사이에 정의된다. X2-CP는 eNB 간의 컨텍스트(context) 전달, 소스 eNB와 타겟 eNB 사이의 사용자 평면 터널의 제어, 핸드오버 관련 메시지의 전달, 상향링크 부하 관리 등의 기능을 수행한다.
eNB은 무선인터페이스를 통해 단말과 연결되고 S1 인터페이스를 통해 EPC(evolved packet core)에 연결된다.
S1 사용자 평면 인터페이스(S1-U)는 eNB와 서빙 게이트웨이(S-GW: serving gateway) 사이에 정의된다. S1 제어 평면 인터페이스(S1-MME)는 eNB와 이동성 관리 개체(MME: mobility management entity) 사이에 정의된다. S1 인터페이스는 EPS(evolved packet system) 베어러 서비스 관리 기능, NAS(non-access stratum) 시그널링 트랜스포트 기능, 네트워크 쉐어링, MME 부하 밸런싱 기능 등을 수행한다. S1 인터페이스는 eNB와 MME/S-GW 간에 다수-대-다수 관계(many-to-many-relation)를 지원한다.
MME는 NAS 시그널링 보안(security), AS(Access Stratum) 보안(security) 제어, 3GPP 액세스 네트워크 간 이동성을 지원하기 위한 CN(Core Network) 노드 간(Inter-CN) 시그널링, (페이징 재전송의 수행 및 제어 포함하여) 아이들(IDLE) 모드 UE 도달성(reachability), (아이들 및 액티브 모드 단말을 위한) 트래킹 영역 식별자(TAI: Tracking Area Identity) 관리, PDN GW 및 SGW 선택, MME가 변경되는 핸드오버를 위한 MME 선택, 2G 또는 3G 3GPP 액세스 네트워크로의 핸드오버를 위한 SGSN 선택, 로밍(roaming), 인증(authentication), 전용 베어러 확립(dedicated bearer establishment)를 포함하는 베어러 관리 기능, 공공 경고 시스템(PWS: Public Warning System)(지진 및 쓰나미 경고 시스템(ETWS: Earthquake and Tsunami Warning System) 및 상용 모바일 경고 시스템(CMAS: Commercial Mobile Alert System) 포함) 메시지 전송의 지원 등의 다양한 기능을 수행할 수 있다.
도 3은 본 발명이 적용될 수 있는 무선 통신 시스템에서 E-UTRAN 및 EPC의 구조를 예시한다.
도 3을 참조하면, eNB는 게이트웨이(예를 들어, MME)의 선택, 무선 자원 제어(RRC: radio resource control) 활성(activation) 동안 게이트웨이로의 라우팅, 방송 채널(BCH: broadcast channel)의 스케줄링 및 전송, 상향링크 및 하향링크에서 UE로 동적 자원 할당, 그리고 LTE_ACTIVE 상태에서 이동성 제어 연결의 기능을 수행할 수 있다. 상술한 바와 같이, EPC 내에서 게이트웨이는 페이징 개시(orgination), LTE_IDLE 상태 관리, 사용자 평면(user plane)의 암호화(ciphering), 시스템 구조 진화(SAE: System Architecture Evolution) 베어러 제어, 그리고 NAS 시그널링의 암호화(ciphering) 및 무결성(intergrity) 보호의 기능을 수행할 수 있다.
도 4는 본 발명이 적용될 수 있는 무선 통신 시스템에서 단말과 E-UTRAN 사이의 무선 인터페이스 프로토콜(radio interface protocol) 구조를 나타낸다.
도 4(a)는 제어 평면(control plane)에 대한 무선 프로토콜 구조를 나타내고, 도 4(b)는 사용자 평면(user plane)에 대한 무선 프로토콜 구조를 나타낸다.
도 4를 참조하면, 단말과 E-UTRAN 사이의 무선 인터페이스 프로토콜의 계층들은 통신 시스템의 기술분야에 공지된 널리 알려진 개방형 시스템 간 상호접속(OSI: open system interconnection) 표준 모델의 하위 3 계층에 기초하여 제1 계층(L1), 제2 계층 (L2) 및 제3 계층 (L3)으로 분할될 수 있다. 단말과 E-UTRAN 사이의 무선 인터페이스 프로토콜은 수평적으로 물리계층(physical layer), 데이터링크 계층(data link layer) 및 네트워크 계층(network layer)으로 이루어지며, 수직적으로는 데이터 정보 전송을 위한 프로토콜 스택(protocol stack) 사용자 평면(user plane)과 제어신호(signaling) 전달을 위한 프로토콜 스택인 제어 평면(control plane)으로 구분된다.
제어평면은 단말과 네트워크가 호를 관리하기 위해서 이용하는 제어 메시지들이 전송되는 통로를 의미한다. 사용자 평면은 애플리케이션 계층에서 생성된 데이터, 예를 들어, 음성 데이터 또는 인터넷 패킷 데이터 등이 전송되는 통로를 의미한다. 이하, 무선 프로토콜의 제어평면과 사용자평면의 각 계층을 설명한다.
제1 계층(L1)인 물리 계층(PHY: physical layer)은 물리 채널(physical channel)을 사용함으로써 상위 계층으로의 정보 송신 서비스(information transfer service)를 제공한다. 물리 계층은 상위 레벨에 위치한 매체 접속 제어(MAC: medium access control) 계층으로 전송 채널(transport channel)을 통하여 연결되고, 전송 채널을 통하여 MAC 계층과 물리 계층 사이에서 데이터가 전송된다. 전송 채널은 무선 인터페이스를 통해 데이터가 어떻게 어떤 특징으로 전송되는가에 따라 분류된다. 그리고, 서로 다른 물리 계층 사이, 송신단의 물리 계층과 수신단의 물리 계층 간에는 물리 채널(physical channel)을 통해 데이터가 전송된다. 물리 계층은 OFDM(orthogonal frequency division multiplexing) 방식으로 변조되며, 시간과 주파수를 무선 자원으로 활용한다.
물리 계층에서 사용되는 몇몇 물리 제어 채널들이 있다. 물리 하향링크 제어 채널(PDCCH: physical downlink control channel)는 단말에게 페이징 채널(PCH: paging channel)와 하향링크 공유 채널(DL-SCH: downlink shared channel)의 자원 할당 및 상향링크 공유 채널(UL-SCH: uplink shared channel)과 관련된 HARQ(hybrid automatic repeat request) 정보를 알려준다. 또한, PDCCH는 단말에게 상향링크 전송의 자원 할당을 알려주는 상향링크 승인(UL grant)를 나를 수 있다. 물리 제어 포맷 지시자 채널(PDFICH: physical control format indicator channel)는 단말에게 PDCCH들에 사용되는 OFDM 심볼의 수를 알려주고, 매 서브프레임마다 전송된다. 물리 HARQ 지시자 채널(PHICH: physical HARQ indicator channel)는 상향링크 전송의 응답으로 HARQ ACK(acknowledge)/NACK(non-acknowledge) 신호를 나른다. 물리 상향링크 제어 채널(PUCCH: physical uplink control channel)은 하향링크 전송에 대한 HARQ ACK/NACK, 스케줄링 요청 및 채널 품질 지시자(CQI: channel quality indicator) 등과 같은 상향링크 제어 정보를 나른다. 물리 상향링크 공유 채널(PUSCH: physical uplink shared channel)은 UL-SCH을 나른다.
제2 계층(L2)의 MAC 계층은 논리 채널(logical channel)을 통하여 상위 계층인 무선 링크 제어(RLC: radio link control) 계층에게 서비스를 제공한다. 또한, MAC 계층은 논리 채널과 전송 채널 간의 맵핑 및 논리 채널에 속하는 MAC 서비스 데이터 유닛(SDU: service data unit)의 전송 채널 상에 물리 채널로 제공되는 전송 블록(transport block)으로의 다중화/역다중화 기능을 포함한다.
제2 계층(L2)의 RLC 계층은 신뢰성 있는 데이터 전송을 지원한다. RLC 계층의 기능은 RLC SDU의 연결(concatenation), 분할(segmentation) 및 재결합(reassembly)을 포함한다. 무선 베어러(RB: radio bearer)가 요구하는 다양한 QoS(quality of service)를 보장하기 위해, RLC 계층은 투명 모드(TM: transparent mode), 비확인 모드(UM: unacknowledged mode) 및 확인 모드(AM: acknowledge mode)의 세 가지의 동작 모드를 제공한다. AM RLC는 ARQ(automatic repeat request)를 통해 오류 정정을 제공한다. 한편, MAC 계층이 RLC 기능을 수행하는 경우에 RLC 계층은 MAC 계층의 기능 블록으로 포함될 수 있다.
제2 계층(L2)의 패킷 데이터 컨버전스 프로토콜(PDCP: packet data convergence protocol) 계층은 사용자 평면에서 사용자 데이터의 전달, 헤더 압축(header compression) 및 암호화(ciphering) 기능을 수행한다. 헤더 압축 기능은 작은 대역폭을 가지는 무선 인터페이스를 통하여 IPv4(internet protocol version 4) 또는 IPv6(internet protocol version 6)와 같은 인터넷 프로토콜(IP: internet protocol) 패킷을 효율적으로 전송되게 하기 위하여 상대적으로 크기가 크고 불필요한 제어 정보를 담고 있는 IP 패킷 헤더 사이즈를 줄이는 기능을 의미한다. 제어 평면에서의 PDCP 계층의 기능은 제어 평면 데이터의 전달 및 암호화/무결정 보호(integrity protection)을 포함한다.
제3 계층(L3)의 최하위 부분에 위치한 무선 자원 제어(RRC: radio resource control) 계층은 제어 평면에만 정의된다. RRC 계층은 단말과 네트워크 간의 무선 자원을 제어하는 역할을 수행한다. 이를 위해 단말과 네트워크는 RRC 계층을 통해 RRC 메시지를 서로 교환한다. RRC 계층은 무선 베어러들의 설정(configuration), 재설정(re-configuration) 및 해제(release)와 관련하여 논리 채널, 전송 채널 및 물리 채널을 제어한다. 무선 베어러는 단말과 네트워크 사이의 데이터 전송을 위하여 제2 계층(L2)에 의하여 제공되는 논리적인 경로를 의미한다. 무선 베어러가 설정된다는 것은 특정 서비스를 제공하기 위해 무선 프로토콜 계층 및 채널의 특성을 규정하고, 각각의 구체적인 파라미터 및 동작 방법을 설정하는 것을 의미한다. 무선 베어러는 다시 시그널링 무선 베어러(SRB: signaling RB)와 데이터 무선 베어러(DRB: data RB) 두 가지로 나눠 질 수 있다. SRB는 제어 평면에서 RRC 메시지를 전송하는 통로로 사용되며, DRB는 사용자 평면에서 사용자 데이터를 전송하는 통로로 사용된다.
RRC 계층 상위에 위치하는 NAS(non-access stratum) 계층은 세션 관리(session management)와 이동성 관리(mobility management) 등의 기능을 수행한다.
기지국을 구성하는 하나의 셀은 1.25, 2.5, 5, 10, 20Mhz 등의 대역폭 중 하나로 설정되어 여러 단말에게 하향 또는 상향 전송 서비스를 제공한다. 서로 다른 셀은 서로 다른 대역폭을 제공하도록 설정될 수 있다.
네트워크에서 단말로 데이터를 전송하는 하향 전송채널(downlink transport channel)은 시스템 정보를 전송하는 방송 채널(BCH: broadcast channel), 페이징 메시지를 전송하는 PCH, 사용자 트래픽이나 제어메시지를 전송하는 DL-SCH 등이 있다. 하향 멀티캐스트 또는 방송 서비스의 트래픽 또는 제어메시지의 경우 DL-SCH를 통해 전송될 수도 있고, 또는 별도의 하향 멀티캐스트 채널(MCH: multicast channel)을 통해 전송될 수도 있다. 한편, 단말에서 네트워크로 데이터를 전송하는 상향 전송채널(uplink transport channel)로는 초기 제어메시지를 전송하는 랜덤 액세스 채널(RACH: random access channel), 사용자 트래픽이나 제어메시지를 전송하는 UL-SCH(uplink shared channel)가 있다.
논리 채널(logical channel)은 전송 채널의 상위에 있으며, 전송 채널에 맵핑된다. 논리 채널은 제어 영역 정보의 전달을 위한 제어 채널과 사용자 영역 정보의 전달을 위한 트래픽 채널로 구분될 수 있다. 제어 채널로는 방송 제어 채널(BCCH: broadcast control channel), 페이징 제어 채널(PCCH: paging control channel), 공통 제어 채널(CCCH: common control channel), 전용 제어 채널(DCCH: dedicated control channel), 멀티캐스트 제어 채널(MCCH: multicast control channel) 등이 있다. 트래픽 채널로는 전용 트래픽 채널(DTCH: dedicated traffic channel), 멀티캐스트 트래픽 채널(MTCH: multicast traffic channel) 등이 있다. PCCH는 페이징 정보를 전달하는 하향링크 채널이고, 네트워크가 UE가 속한 셀을 모를 때 사용된다. CCCH는 네트워크와의 RRC 연결을 가지지 않는 UE에 의해 사용된다. MCCH 네트워크로부터 UE로의 MBMS(Multimedia Broadcast and Multicast Service) 제어 정보를 전달하기 위하여 사용되는 점-대-다점(point-to-multipoint) 하향링크 채널이다. DCCH는 UE와 네트워크 간에 전용 제어 정보를 전달하는 RRC 연결을 가지는 단말에 의해 사용되는 일-대-일(point-to-point) 양방향(bi-directional) 채널이다. DTCH는 상향링크 및 하향링크에서 존재할 수 있는 사용자 정보를 전달하기 위하여 하나의 단말에 전용되는 일-대-일(point-to-point) 채널이다. MTCH는 네트워크로부터 UE로의 트래픽 데이터를 전달하기 위하여 일-대-다(point-to-multipoint) 하향링크 채널이다.
논리 채널(logical channel)과 전송 채널(transport channel) 간 상향링크 연결의 경우, DCCH는 UL-SCH과 매핑될 수 있고, DTCH는 UL-SCH와 매핑될 수 있으며, CCCH는 UL-SCH와 매핑될 수 있다. 논리 채널(logical channel)과 전송 채널(transport channel) 간 하향링크 연결의 경우, BCCH는 BCH 또는 DL-SCH와 매핑될 수 있고, PCCH는 PCH와 매핑될 수 있으며, DCCH는 DL-SCH와 매핑될 수 있으며, DTCH는 DL-SCH와 매핑될 수 있으며, MCCH는 MCH와 매핑될 수 있으며, MTCH는 MCH와 매핑될 수 있다.
도 5는 본 발명이 적용될 수 있는 무선 통신 시스템에서 물리 채널의 구조를 간략히 예시하는 도면이다.
도 5를 참조하면, 물리 채널은 주파수 영역(frequency domain)에서 하나 이상의 서브캐리어와 시간 영역(time domain)에서 하나 이상의 심볼로 구성되는 무선 자원을 통해 시그널링 및 데이터를 전달한다.
1.0ms 길이를 가지는 하나의 서브프레임은 복수의 심볼로 구성된다. 서브프레임의 특정 심볼(들)(예를 들어, 서브프레임의 첫번째 심볼)은 PDCCH를 위해 사용될 수 있다. PDCCH는 동적으로 할당되는 자원에 대한 정보(예를 들어, 자원 블록(Resource Block), 변조 및 코딩 방식(MCS: Modulation and Coding Scheme) 등)를 나른다.
랜덤 액세스 절차(Random Access Procedure)
이하에서는 LTE/LTE-A 시스템에서 제공하는 랜덤 액세스 절차(random access procedure)에 대해 살펴본다.
랜덤 액세스 절차는 단말이 기지국과의 RRC 연결(RRC Connection)이 없어, RRC 아이들 상태에서 초기 접속 (initial access)을 수행하는 경우, RRC 연결 재-확립 절차(RRC connection re-establishment procedure)를 수행하는 경우 등에 수행된다.
LTE/LTE-A 시스템에서는 랜덤 액세스 프리앰블(random access preamble, RACH preamble)을 선택하는 과정에서, 특정한 집합 안에서 단말이 임의로 하나의 프리앰블을 선택하여 사용하는 경쟁 기반 랜덤 액세스 절차(contention based random access procedure)과 기지국이 특정 단말에게만 할당해준 랜덤 액세스 프리앰블을 사용하는 비 경쟁 기반 랜덤 액세스 절차(non-contention based random access procedure)을 모두 제공한다.
도 6은 본 발명이 적용될 수 있는 무선 통신 시스템에서 경쟁 기반 랜덤 액세스 절차를 설명하기 위한 도면이다.
(1) 제1 메시지(Msg 1, message 1)
먼저, 단말은 시스템 정보(system information) 또는 핸드오버 명령(handover command)을 통해 지시된 랜덤 액세스 프리앰블의 집합에서 임의로(randomly) 하나의 랜덤 액세스 프리앰블(random access preamble, RACH preamble)을 선택하고, 상기 랜덤 액세스 프리앰블을 전송할 수 있는 PRACH(physical RACH) 자원을 선택하여 전송한다.
단말로부터 랜덤 액세스 프리앰블을 수신한 기지국은 프리앰블을 디코딩하고, RA-RNTI를 획득한다. 랜덤 액세스 프리앰블이 전송된 PRACH와 관련된 RA-RNTI는 해당 단말이 전송한 랜덤 액세스 프리앰블의 시간-주파수 자원에 따라 결정된다.
(2) 제2 메시지(Msg 2, message 2)
기지국은 제1 메시지 상의 프리앰블을 통해서 획득한 RA-RNTI로 지시(address)되는 랜덤 액세스 응답(random access response)을 단말로 전송한다. 랜덤 액세스 응답에는 랜덤 액세스 프리앰블 구분자/식별자(RA preamble index/identifier), 상향링크 무선자원을 알려주는 상향링크 승인(UL grant), 임시 셀 식별자(TC-RNTI: Temporary Cell RNTI) 그리고 시간 동기 값(TAC: time alignment command)들이 포함될 수 있다. TAC는 기지국이 단말에게 상향링크 시간 정렬(time alignment)을 유지하기 위해 보내는 시간 동기 값을 지시하는 정보이다. 단말은 상기 시간 동기 값을 이용하여, 상향링크 전송 타이밍을 갱신한다. 단말이 시간 동기를 갱신하면, 시간 동기 타이머(time alignment timer)를 개시 또는 재시작한다. UL grant는 후술하는 스케줄링 메시지(제3 메시지)의 전송에 사용되는 상향링크 자원 할당 및 TPC(transmit power command)를 포함한다. TPC는 스케줄링된 PUSCH를 위한 전송 파워의 결정에 사용된다.
단말은 랜덤 액세스 프리앰블을 전송 후에, 기지국이 시스템 정보 또는 핸드오버 명령을 통해 지시된 랜덤 액세스 응답 윈도우(random access response window) 내에서 자신의 랜덤 액세스 응답(random access response)의 수신을 시도하며, PRACH에 대응되는 RA-RNTI로 마스킹된 PDCCH를 검출하고, 검출된 PDCCH에 의해 지시되는 PDSCH를 수신하게 된다. 랜덤 액세스 응답 정보는 MAC PDU(MAC packet data unit)의 형식으로 전송될 수 있으며, 상기 MAC PDU는 PDSCH을 통해 전달될 수 있다.
단말은 기지국에 전송하였던 랜덤 액세스 프리앰블과 동일한 랜덤 액세스 프리앰블 구분자/식별자를 가지는 랜덤 액세스 응답을 성공적으로 수신하면, 랜덤 액세스 응답의 모니터링을 중지한다. 반면, 랜덤 액세스 응답 윈도우가 종료될 때까지 랜덤 액세스 응답 메시지를 수신하지 못하거나, 기지국에 전송하였던 랜덤 액세스 프리앰블과 동일한 랜덤 액세스 프리앰블 구분자를 가지는 유효한 랜덤 액세스 응답을 수신하지 못한 경우 랜덤 액세스 응답의 수신은 실패하였다고 간주되고, 이후 단말은 프리앰블 재전송을 수행할 수 있다.
(3) 제3 메시지(Msg 3, message 3)
단말이 자신에게 유효한 랜덤 액세스 응답을 수신한 경우에는, 상기 랜덤 액세스 응답에 포함된 정보들을 각각 처리한다. 즉, 단말은 TAC을 적용시키고, TC-RNTI를 저장한다. 또한, UL grant를 이용하여, 단말의 버퍼에 저장된 데이터 또는 새롭게 생성된 데이터를 기지국으로 전송한다.
단말의 최초 접속의 경우, RRC 계층에서 생성되어 CCCH를 통해 전달된 RRC 연결 요청(RRC Connection Request)이 제3 메시지에 포함되어 전송될 수 있으며, RRC 연결 재확립 절차의 경우 RRC 계층에서 생성되어 CCCH를 통해 전달된 RRC 연결 재확립 요청(RRC Connection Re-establishment Request)이 제3 메시지에 포함되어 전송될 수 있다. 또한, NAS 접속 요청 메시지를 포함할 수도 있다.
제3 메시지는 단말의 식별자가 포함되어야 한다. 단말의 식별자를 포함시키는 방법으로는 두 가지 방법이 존재한다. 첫 번째 방법은 단말이 상기 랜덤 액세스 절차 이전에 이미 해당 셀에서 할당 받은 유효한 셀 식별자(C-RNTI)를 가지고 있었다면, 단말은 상기 UL grant에 대응하는 상향링크 전송 신호를 통해 자신의 셀 식별자를 전송한다. 반면에, 만약 랜덤 액세스 절차 이전에 유효한 셀 식별자를 할당 받지 못하였다면, 단말은 자신의 고유 식별자(예를 들면, S-TMSI 또는 임의 값(random number))를 포함하여 전송한다. 일반적으로 상기의 고유 식별자는 C-RNTI보다 길다.
단말은 상기 UL grant에 대응하는 데이터를 전송하였다면, 충돌 해결을 위한 타이머(contention resolution timer)를 개시한다.
(4) 제4 메시지(Msg 4, message 4)
기지국은 단말로부터 제3 메시지를 통해 해당 단말의 C-RNTI를 수신한 경우 수신한 C-RNTI를 이용하여 단말에게 제4 메시지를 전송한다. 반면, 단말로부터 제3 메시지를 통해 상기 고유 식별자(즉, S-TMSI 또는 임의 값(random number))를 수신한 경우, 랜덤 액세스 응답에서 해당 단말에게 할당한 TC-RNTI를 이용하여 제4 메시지를 단말에게 전송한다. 일례로, 제4 메시지는 RRC 연결 설정 메시지(RRC Connection Setup)가 포함할 수 있다.
단말은 랜덤 액세스 응답에 포함된 UL grant를 통해 자신의 식별자를 포함한 데이터를 전송한 이후, 충돌 해결을 위해 기지국의 지시를 기다린다. 즉, 특정 메시지를 수신하기 위해 PDCCH의 수신을 시도한다. 상기 PDCCH를 수신하는 방법에 있어서도 두 가지 방법이 존재한다. 앞에서 언급한 바와 같이 상기 UL grant에 대응하여 전송된 제3 메시지가 자신의 식별자가 C-RNTI인 경우, 자신의 C-RNTI를 이용하여 PDCCH의 수신을 시도하고, 상기 식별자가 고유 식별자(즉, S-TMSI 또는 임의 값(random number))인 경우에는, 랜덤 액세스 응답에 포함된 TC-RNTI를 이용하여 PDCCH의 수신을 시도한다. 그 후, 전자의 경우, 만약 상기 충돌 해결 타이머가 만료되기 전에 자신의 C-RNTI를 통해 PDCCH를 수신한 경우에, 단말은 정상적으로 랜덤 액세스 절차가 수행되었다고 판단하고, 랜덤 액세스 절차를 종료한다. 후자의 경우에는 상기 충돌 해결 타이머가 만료되기 전에 TC-RNTI를 통해 PDCCH를 수신하였다면, 상기 PDCCH가 지시하는 PDSCH이 전달하는 데이터를 확인한다. 만약 상기 데이터의 내용에 자신의 고유 식별자가 포함되어 있다면, 단말은 정상적으로 랜덤 액세스 절차가 수행되었다고 판단하고, 랜덤 액세스 절차를 종료한다. 제4 메시지를 통해 단말은 C-RNTI를 획득하고, 이후 단말과 네트워크는 C-RNTI를 이용하여 단말 특정 메시지(dedicated message)를 송수신하게 된다.
한편, 비경쟁 기반 임의접속 과정에서의 동작은 도 6에 도시된 경쟁 기반 임의접속 과정과 달리 제1 메시지 전송 및 제2 메시지 전송만으로 임의접속 절차가 종료되게 된다. 다만, 제1 메시지로서 단말이 기지국에 임의접속 프리앰블을 전송하기 전에 단말은 기지국으로부터 임의접속 프리앰블을 할당받게 되며, 이 할당받은 임의접속 프리앰블을 기지국에 제1 메시지로서 전송하고, 기지국으로부터 임의접속 응답을 수신함으로써 임의접속 절차가 종료되게 된다.
IFOM (IP Flow Mobility)
3GPP에서는 Release 10에서 IP 플로우 이동성에 기초한 단말 메커니즘(또는 IFOM)을 규격화하였다. 이로 인해, 3GPP 접속 네트워크와 WLAN 접속 네트워크를 동시에 사용할 수 있는 단말이 상기 두 접속 네트워크들 간에 IP 플로우 이동성을 수행할 수 있게 되었다. Release 10에서 작업한 IFOM은 호스트 기반의 이동성 프로토콜인 DSMIP(Dual Stack Mobile IP)를 사용한다. Release 13에서는 다음과 같은 목적을 가지고 NBIFOM(Network-based IFOM)이라는 work item으로 IP 플로우 이동성에 기초한 네트워크에 대한 작업을 진행하고자 한다.
- 단말은 3GPP 및 WLAN 접속을 동시에 수행하기 위한 dual radio를 지원
또한, 네트워크 기반 프로토콜(예를 들어, WLAN에 대한 PMIP(Proxy Mobile IP), S2a 및 S2b 기반 GTP)을 사용한 끊김 없는 오프로드 및 플로우 이동성과 관련된 아래와 같은 절차들이 연구될 예정이다.
- 복수의 네트워크들에 대한 동시 접속에 대한 PDN 연결 활성화의 지원
- 접속 시스템에 대한 PDN 연결에 속한 적어도 하나의 IP 플로우들의 연계
- 서로 다른 접속 시스템들 사이의 PDN 연결에 속한 적어도 하나의 IP 플로우의 이동
- 단말 및 네트워크에서의 IP 플로우 이동성을 위한 트리거들
- 단말-개시(UE-initiated) 및 네트워크-개시(network-initiated) NBIFOM
- NBIFOM을 지원하기 위한 3GPP 관련 정책들(예를 들어, PCC(Policy and Charging Control), ANDSF(Access Network Discovery and Selection Function), ISRP(Inter-System Routing policy), ISMP(Inter-System Mobility Policy), ANDSF 없는 RAN 정책 등) 사이의 충돌 및 관계
IMS(IP Multimedia Subsystem)
이하에서는 LTE/LTE-A 시스템에서 제공하는 IMS(IP Multimedia Subsystem)에 대해 살펴본다.
도 7은 본 발명의 일 실시예에 따른 IMS 구조를 예시한 도면이다.
IMS란, IP 망 상에서 멀티미디어 서비스를 제공하기 위한 프레임 워크를 지칭할 수 있다. IMS는 독립된 접속망을 제공하여 유무선 망에 공통적인 멀티미디어 서비스 환경을 제공한다. 또한, IMS는 제어 계층(service layer) 및 서비스 계층(service layer)를 분리하여, 여러 서비스가 서비스 종속적인 제어 기능을 가질 필요 없이 공통적인 제어 계층으로 쉽게 확장될 수 있는 구조를 갖는다.
IMS는 아래와 같이 크게 기능적으로 구별되는 6가지의 기능 블록들을 포함할 수 있다.
1. 세션 제어 기능 블록
IMS에서 가장 중요한 기능을 수행하는 블록이며, 아래와 같은 3종류의 SIP(Session Initiation Protocol) 서버로 구성될 수 있다.
- P-CSCF(Proxy-CSCF(Call Session Control Function)): 유저가 IMS 망에 접속하기 위해 최초로 접속하는 지점에 해당할 수 있다. SIP 메시지를 다른 CSCF에 전송할 수 있으며, 단말로부터 접속이 없는 경우, 세션을 종료할 수 있다.
- S-CSCF(Serving-CSCF): 유저 단말 정보를 HSS에 전송할 수 있다. HSS로부터 수신한 가입자 정보를 보관, 유지할 수 있다. 세션의 개시, 종료 및 SIP 메시지 경로를 찾을 수 있다.
- I-CSCF(Interrogation-CSCF): 다른 망으로부터 SIP 메시지를 수신하는 GW 성격의 SIP 서버에 해당할 수 있다. 유저가 위치 등록 시 HSS를 선택할 수 있다. S-CSCF를 선택하여 단말로부터의 메시지를 전송할 수 있다.
2. 홈 가입자 서버 블록
- HSS: 세션 제어, 서비스 제어에 필요한 모든 정보를 저장하고 있다. 단말의 물리적인 위치 정보를 저장하고 있는 HLR과 연동된다. 주요 저장 정보로는, 가입자 식별 정보(서비스 가입 상황), 유저 인증 정보, S-CSCF 선택 정보, 사용자 프로필 정보 등이 있을 수 있다.
- SLF(Subscription Locator Function): IMS 내 복수의 HSS들이 존재하는 경우, 특정 유저 정보를 저장하고 있는 HSS를 찾기 위하여 유저별 HSS 정보를 저장한다.
3. 멀티미디어 제어 기능 블록
- MRFP(Multimedia Resource Function Processor): 음성, 비디오 등 미디어 스트림을 믹싱, 생성 및 처리하는 기능을 제공한다.
- MRFC(Multimedia Resource Function Controller): SIP 메시지를 IMS 내의 다른 서버와 송수신하여 MRFP를 제어하는 기능을 담당한다.
4. AS(Application Service) 블록
어플리케이션 서비스를 제공하는 서버로서, TAS(Telephony AS), IM-AS, MSG-AS 등이 존재할 수 있다.
5. QoS 제어 블록
- PCRF(Policy and Charging Rules Function): QoS 제어에 필요한 정책을 결정하는 기능을 지원한다.
- PCEF(Policy and Charging Enforcement Function): 실제 미디어를 취급하는 GGSN(GPRS support node) 내에 존재하며, PCRF와 연동해서 각 세션마다 QoS 제어를 제공한다.
6. 기존 망과 연계된 GW 블록
IMS 망과 기존의 회선 교환 망과의 상호 연동 기능을 제공하는 블록에 해당할 수 있다.
- IM-MGW(IP Multimedia-Media Gateway): IP 네트워크와 CS 네트워크 사이에서 음성, 비디오 등의 미디어 변환 기능을 제공할 수 있다.
- MGCF(MGW Control Function): SIP과 ISP 간의 시그널링 변환을 지원할 수 있다. 또한, IM-MGW를 제어할 수 있다.
- BGCF(Breakout Gateway Control Function): CS 망으로의 착신 시, CS 망으로 전송할 MGCF를 선택한다.
- SGW(Signaling Gateway): CS 네트워크로부터의 시그널링을 SIP으로 변환할 수 있다. 또한, SIP을 ISUP(ISDN user part)으로 변환할 수 있다.
이상으로, IMS 구조를 개괄적으로 살펴보았다. 이러한 IMS에 접속하는 IMS 단말(또는 기기)은 IMS 관련 동작을 시작하기 전, 몇 가지 사전 절차를 반드시 수행해야 한다.
도 8은 상위 레벨 관점에서의 IMS를 위한 사전 절차를 예시한 도면이다.
도 8을 참조하면, IMS를 위한 사전 절차는 아래와 같은 단계들이 순차적으로 진행될 수 있다.
1. 우선, IMS 서비스 제공자는 유저가 IMS 서비스를 사용할 수 있도록 유저에게 권한을 부여할 수 있다. 이는 일반적으로 IMS 네트워크 오퍼레이터 및 유저 사이의 미리 서명된 계약 또는 예약을 요구한다. 이러한 계약은 사용자가 무선 네트워크를 통한 발신/수신을 수행할 수 있도록 권한을 부여하는 예약과 유사하다.
2. 다음으로, IMS 단말은 GPRS(GSM/UMTS 네트워크에서의), ADSL(Asymmetric Digital Subscriber Line), 또는 WLAN(Wireless Local Access Network)과 같은 IP-CAN(IP Connectivity Access Network)와 연결될 수 있다. IP-CAN은 IMS 홈 네트워크 또는 IMS 방문 네트워크로의 연결을 제공할 수 있다. 사전 절차의 한 부분으로서, IMS 단말은 IP 주소를 획득해야 한다. 이러한 IP 주소는 일반적으로 IP-CAN 오퍼레이터에 의해 동적으로 기설정된 시간 동안 할당될 수 있다.
3. 다음으로, IMS 단말은 출입 SIP 프록시 서버로서 기능하는 P-CSCF의 IP 주소를 발견할 수 있다. IMS 단말에 의해 전송되는 모든 SIP 시그널링은 P-CSCF를 통과할 수 있다. P-CSCF 발견 절차가 완료되었을 때, IMS 단말은 SIP 메시지(또는 시그널링)를 P-CSCF와 송수신할 수 있다. P-CSCF는 IMS 등록 절차를 위해 IMS 단말에 할당될 수 있으며, IMS 등록 절차는 일반적으로 IMS 단말이 스위치 온/오프되는 경우에 트리거링될 수 있다.
사용 중인 IP 연결 접속 네트워크에 기초하여, P-CSCF 발견 절차는 IP-CAN 연결을 획득하기 위한 절차의 한 부분으로서 또는 별도의 분리된 절차로서 수행될 수 있다. 분리된 절차는 DHCP(Dynamic Host Configuration Protocol) 또는 DHCPv6(DHCP for IPv6)의 한 수단으로서 수행될 수 있다.
4. 다음으로, IMS 단말은 SIP 어플리케이션 레벨에서 IMS 네트워크에 등록할 수 있다. 이는, 정기적인 SIP 등록에 의해 수행될 수 있다. IMS 단말은 어떤 다른 SIP 시그널링을 초기화 또는 수신하기 전에 IMS에 등록할 필요가 있다. IMS가 계층(또는 레이어)별로 모델링됨에 따라, IP-CAN 계층은 IMS SIP 계층과 독립될 수 있다. 따라서, IMS 계층에서의 등록은 IP-CAN 계층에서의 등록과는 독립적일 수 있다. 이러한 IMS 등록 절차는 IMS 네트워크가 IMS 단말의 IP 주소를 획득하게 할 수 있다. 이는 또한 IMS 네트워크가 유저를 인증하고, 보안 협약을 체결할 수 있으며, 세션 연결을 승인할 수 있다.
PDN 타입(또는 IP 버전) 변경 절차
3GPP에서 IMS의 설계 시, IETF 표준에서 기존의 IP 버전 4(이하, ‘IPv4’)와는 다른 별도의 IP 버전 6(이하, ‘IPv6’를 표준화하였다. 3GPP는 IMS를 위한 IPv6의 적용 가능성을 분석하였으며, IPv6는 인터넷 상에서 가장 흔한(또는 공통적인) IP 버전이 될 것이라고 예상하였다. 그러나, 이러한 예상과는 달리 현재 대부분의 인터넷에서는 여전히 IPv4를 운영하고 있으며, 현재 오로지 몇몇의 모바일 네트워크만이 IPv6를 도입할 준비가 되어있다.
따라서, 현재 IMS에서는 IMS 단말 및 네트워크 노드들에서 IPv6 및 IPv4의 상호 연동을 위한 듀얼 스택 실행(또는 듀얼 스택 변환 시스템)이 허용되고 있다. 특히, IMS에서 IBCF(Interconnection Border Control Functions)는 IP 버전을 변환함으로써 IPv4 및 IPv6 사이의 상호 연동(또는 IPv4 SIP 어플리케이션과 IPv6 SIP 어플리케이션 사이의 통신 기능)을 지원한다.
종래의 IMS 복구 절차는 IMS 네트워크에서 특정 노드에 장애가 발생했을 경우, 해당 노드의 장애를 인지한 후 장애가 발생한 노드의 기능을 다른 노드가 대신하도록 함으로써 장애를 해결하는 방안을 제안한다. 그러나, 이러한 종래의 IMS 복구 절차는 IBCF에서 장애가 발생한 경우에 대한 해결 방안은 제시하고 있지 않다.
도 9는 본 발명의 일 실시예에 따른 IBCF에서 장애가 발생한 경우의 실시예를 예시한 도면이다. 본 명세서에서 IPv4 PDN 타입 단말은 IPv4의 PDN 타입을 갖는/지원하는 단말을 지시하며, IPv6 PDN 타입 단말은 IPv6의 PDN 타입을 갖는/지원하는 단말을 지시한다.
IMS 망에서, P-CSCF는 IPv4 PDN 타입 단말과 IPv6 PDN 타입 단말로 서비스 제공이 가능하나, I-CSCF, S-CSCF 등은 IPv4 PDN 타입 단말만 서비스 가능한 경우가 있을 수 있다. 이 경우, IBCF는 P-CSCF 및 S-CSCF 사이에 위치하여 IP 버전(또는 PDN 타입)을 IPv6에서 IPv4로 변환해줌으로써 I-CSCF/S-CSCF가 서비스를 제공할 수 있도록 지원할 수 있다.
그러나, 본 도면에 도시한 바와 같이, IBCF에 장애가 발생하여 IP 버전을 IPv4로 변환하지 못해 IPv6 PDN 타입 단말에게 IMS 서비스를 제공할 수 없는 경우에는, 단말의 IP 버전(또는 PDN 타입)을 바꾸어 주지 않는 이상 이러한 문제를 해결하기 어렵다. 따라서, 본 명세서에서는 이렇듯 IBCF에 장애가 발생하여 IP 버전(또는 PDN 타입)을 변환해줄 수 없는 경우, 단말이 IP 버전(또는 PDN 타입)을 변경하여 IMS 서비스를 재요청하도록 하여 IBCF 장애 발생으로 인한 IMS 서비스 불가 문제를 해결하고자 한다.
이하에서는 단말이 발신(MO(Mobile Originated)) 또는 착신(MT(Mobile Terminated)) 서비스를 요청한 경우에서의 IMS 복구 절차를 제안한다. 또한, 이하에서 P-CSCF는 IPv4 PDN 타입 단말과 IPv6 PDN 타입의 단말을 모두 서비스할 수 있다고 가정한다.
도 10 및 11은 MO 서비스 제공 시, PCRF를 중심으로 한 PDN 타입 변경 실시예를 예시한 도면이다. 도 10 및 11에서 MO 서비스를 요청한 단말은 도 10의 사전 절차를 완료하여 IMS 망에 등록된 단말에 해당할 수 있다.
1. 우선, IMS 네트워크에서 IP 버전 변환 기능을 수행하는 노드인 IBCF에 장애가 발생하여 IMS 네트워크 내 일부 노드(예를 들어, S-CSCF)(또는 단말의 IMS 네트워크)가 지원하지 않는 PDN 타입(또는 IP 버전)으로 MO 서비스(IMS 서비스)를 요청하는 단말에게 서비스 제공이 불가능하게 될 수 있다(S1110).
2. 이러한 IBCF의 장애를 인지하기 전, P-CSCF는 MO 서비스를 요청한 단말의 PDN 타입을 체크하여 단말의 IBCF를 통한 PDN 타입 변환이 필요한지 여부를 판단할 수 있다. PDN 타입 변환 필요 여부는 현재 단말에 설정/할당된 PDN 타입이 IMS 네트워크 내 일부 노드(예를 들어, S-CSCF)가 지원하는 PDN 타입인지 여부를 기초로 판단될 수 있다.
만일, PDN 타입 변환 절차가 필요하다고 판단될 경우(예를 들어, 단말의 PDN 타입이 IPv6인 경우), P-CSCF는 단말로부터 IMS 서비스를 요청/개시하기 위해 전송된 SIP INVITE 메시지/요청을 IBCF로 포워딩할 수 있다(S1120). 반대로, PDN 타입 변환 절차가 필요하지 않다고 판단될 경우(예를 들어, 단말의 PDN 타입이 IPv4인 경우), P-CSCF는 단말로부터 전송된 SIP INVITE 메시지/요청을 IBCF로 포워딩하지 않을 수 있다. 후자의 경우, P-CSCF가 SIP INVITE 메시지/요청을 IBCF로 포워딩하지 않더라도 단말의 PDN 타입이 S-CSCF 등에 의해 서비스 가능한 PDN 타입에 해당하므로, 정상적으로 IMS 서비스가 제공되며 이하의 단계들은 생략될 수 있다.
3. P-CSCF는 S1120 단계에 따른 SIP INVITE 메시지/요청에 대한 응답을 기설정된 시간 동안 IBCF로부터 수신하지 못함으로써, IBCF의 장애를 인지할 수 있다(S1130).
4. IBCF의 장애를 인지한 P-CSCF는 PCRF를 거쳐 P-GW에 IBCF 장애/실패로 인해 단말에게 IMS 서비스의 제공 불가능함을 알림과 동시에 IMS 서비스를 제공받기 위해서는 단말의 PDN 타입 변경이 필요함을 알릴 수 있다(S1140). 보다 상세하게는, P-CSCF는 PCRF에게 “PDN_TYPE_CHANGE” 지시가 포함된 Rx AAR(Authorization Authentication Request) 메시지를 전송하고, PCRF는 수신한 “PDN_TYPE_CHANGE” 지시가 포함된 Gx RAR(Re-Authorization Request) 메시지를 P-GW(또는 PCEF)로 전송함으로써, IBCF의 장애/실패로 인해 단말의 PDN 타입 변경이 필요함을 알릴 수 있다.
5. P-GW는 P-GW 개시 베어러 비활성화 절차(P-GW initiated Bearer deactivation procedure)를 통해 단말의 IMS PDN 연결을 해제할 수 있다(S1150).
6. P-GW 개시 베어러 비활성화 절차가 완료된 후, 단말은 이전/마지막 PDN 타입과 다른 PDN 타입으로 IMS PDN 연결을 재요청할 수 있다(S1160).
이때, 단말이 이전 PDN 타입과 다르게 PDN 타입을 변경하는 방법으로는 아래와 같은 두 가지 실시예가 존재할 수 있다.
일 실시예로서, P-GW는 베어러 비활성화 절차 요청 시 원인(cause)을 “PDN_TYPE_CHANGE”로 설정할 수 있다. 해당 원인을 수신한 단말은 IMS PDN 연결 재요청 시, PDN 타입을 IMS 노드의 서비스 제공이 가능한 타입(또는 이전에 설정했던 PDN 타입과는 다른 PDN 타입)(예를 들어, IPv4)으로 변경하여 IMS PDN 연결을 재요청(또는 재접속(re-attach)을 요청)할 수 있다. 다시 말하면, 베어러 비활성화 절차가 완료된 후, 단말은 이전/마지막 PDN 연결 요청에 사용된 PDN 타입과는 다른 PDN 타입을 설정하여 단말에 의한 PDN 연결 요청(UE requested PDN Connectivity request)을 통해 IMS PDN 연결을 획득할 수 있다.
다른 실시예로서, P-GW는 PDN 타입 변경이 필요한 단말을 기억해 두었다가(예를 들어, 단말의 식별 정보를 별도로 저장) 해당 단말의 PDN 연결 요청을 수신하였을 때, 해당 단말에게 IMS 서비스 제공이 가능한 PDN 타입을 할당/설정해줄 수 있다. 다시 말하면, 베어러 비활성화 절차를 톨해 P-GW는 PDN 타입 변경이 필요한 단말을 미리 기억/저장해둘 수 있으며, 해당 단말에 의한 PDN 연결 요청(UE requested PDN Connectivity request)을 수신한 경우, 해당 단말에게 IMS 서비스가 가능한 PDN 타입(예를 들어, IPv4)을 설정/할당할 수 있다. 이때, 단말은 PDN 연결 요청 시, IMS 서비스 제공이 가능한 PDN 타입(예를 들어, IPv4)이 포함된 PDN 타입으로 PDN 연결을 요청할 수 있다.
이렇듯 단말은 변경된 PDN 타입으로 PDN 연결을 확립한 뒤, IMS 등록 절차를 완료할 수 있다. 나아가 단말은 IMS 서비스(또는 MO 서비스)를 요청하기 위한 SIP INVITE 메시지/요청을 IMS 네트워크로 전송할 수 있다. 이 경우, 단말의 PDN 타입은 IMS 네트워크 노드(예를 들어, S-CSCF)에 의해 서비스 제공 가능한 타입에 해당되므로, IBCF에 의한 별도의 IP 버전 변환 절차가 불필요하다. 따라서, 단말로부터 SIP INVITE 메시지/요청을 수신한 P-CSCF는 해당 메시지를 IBCF로 전송/포워딩하지 않고, S-CSCF로 바로 전송/포워딩할 수 있으며, 이 경우 해당 단말로의 정상적인 IMS 서비스 제공이 가능하다.
한편, 상술한 실시예에서와 달리, IBCF에 논리적으로 직접 연결되어 있는 노드들(즉, P-CSCF 또는 S-CSCF)의 Keep-alive 메커니즘으로 IBCF의 장애를 인지하여, PDN 타입 변경(또는 IP 버전 변환)이 필요한 단말들의 PDN 타입을 일괄적으로 변경해줄 수도 있다. 그러나, PDN 타입 변경에 따른 IMS 등록 과부화, EPC 시그널링 과부화 및 이미 서비스를 제공 받고 있는 단말에 대한 서비스 충돌 등의 문제를 방지하기 위해, 본 실시예에서와 같이 IMS 네트워크에 서비스를 요청한 단말의 PDN 타입이 서비스 불가능한 타입일 경우에만 PDN 타입 변경 절차를 수행할 것을 제안한다.
도 12 및 13은 MT 서비스 제공 시, PCRF를 중심으로 한 PDN 타입 변경 실시예를 예시한 도면이다.
도 12 및 13에서 MT 서비스를 요청한 단말은 도 8의 사전 절차를 완료하여 IMS 망에 등록된 단말에 해당할 수 있다. 또한, 이하에서는 설명의 편의를 위해 IBCF를 기능/개념적으로 나누어, IMS 망간의 상호 연동 기능은 IBCF 1, PDN 타입(또는 IP 버전) 변환 기능은 IBCF 2라 지칭하기로 한다. 또한, 본 도면/실시예에서 IBCF 1은 정상 동작하며, IBCF 2에만 장애가 발생한 경우를 가정한다. 또한, 이하에서 후술하는 단계들에 대한 설명은 도 12 및 13에서의 설명이 동일/유사하게 적용될 수 있으며, 중복되는 설명은 생략한다.
1. 우선, IMS 네트워크에서 IP 버전 변환 기능을 수행하는 노드인 IBCF 2에 장애가 발생하여, IMS 네트워크 내 일부 노드(예를 들어, S-CSCF)(또는 IMS 네트워크)가 지원하지 않는 PDN 타입(또는 IP 버전)을 갖는 수신 단말(MT UE)로 향하는 MT 서비스(또는 IMS 서비스)의 제공이 불가능하게 될 수 있다(S1310).
2. 이때, IBCF 2의 장애로 인해 IMS 서비스 제공이 불가능한 PDN 타입을 갖는 수신 단말로 향하는 MT/IMS 서비스 요청이 발생할 수 있다(S1320). 이러한 IBCF 2의 장애를 인지하기 전, S-CSCF는 수신 단말의 PDN 타입을 체크하여 IBCF 2를 통한 PDN 타입 변환이 필요한지 여부를 판단할 수 있다. PDN 타입 변환 필요 여부는 수신 단말의 PDN 타입이 IMS 네트워크 내 일부 노드(예를 들어, S-CSCF)가 지원하는 PDN 타입에 해당하는지 여부를 기초로 판단될 수 있다. 이를 위해, S-CSCF는 발신 단말로부터 IMS 서비스 요청/개시를 위해 수신한 SIP INVITE 메시지/요청에 포함되어 있는 수신 단말의 식별 정보를 이용할 수 있다.
만일, PDN 타입 변환 절차가 필요하다고 판단될 경우(예를 들어, 수신 단말의 PDN 타입이 IPv6인 경우), S-CSCF는 발신 단말(MO UE)로부터 IMS 서비스를 요청/개시하기 위해 전송된 SIP INVITE 메시지/요청을 IBCF 2로 포워딩할 수 있다. 반대로, PDN 타입 변환 절차가 필요하지 않다고 판단될 경우(예를 들어, 단말의 PDN 타입이 IPv4인 경우), S-CSCF는 발신 단말로부터 전송된 SIP INVITE 메시지/요청을 IBCF 2로 포워딩하지 않을 수 있다. 후자의 경우, S-CSCF가 SIP INVITE 메시지/요청을 IBCF 2로 포워딩하지 않더라도 수신 단말의 PDN 타입이 S-CSCF 등에 의해 서비스 가능한 PDN 타입에 해당하므로, 정상적으로 IMS 서비스가 제공되며 이하의 단계들은 생략될 수 있다.
3. S-CSCF는 S1320 단계에 따른 SIP INVITE 메시지/요청에 대한 응답(예를 들어, 200 Trying 응답)을 기설정된 시간 동안 IBCF 2로부터 수신하지 못함으로써, IBCF 2의 장애를 인지할 수 있다(S1330).
4. IBCF 2의 장애를 인지한 S-CSCF는, 발신 단말의 PDN 타입이 수신 단말의 IMS 네트워크에 의해 서비스 가능한 타입에 해당하나, 수신 단말의 PDN 타입이 (IBCF 2의 장애로 인해) 수신 IMS 네트워크에 의해 서비스 제공이 불가능한 타입인 경우(예를 들어, IPv6인 경우), 발신 단말에게 “500 Try After”로 응답함으로써 발신 단말로 하여금 일정 시간 이후에 SIP INVITE 메시지/요청을 재전송하도록 할 수 있다(S1340). 또한, 만일 발신 단말의 PDN 타입이 수신 단말의 IMS 네트워크에 의해 서비스 제공이 불가능한 경우, S-CSCF는 발신 단말에게 “606 Not Acceptable with Warning 301 Incompatible network address formats”로 응답함으로써 IMS 서비스의 제공이 불가함을 알릴 수 있다(S1340).
5, 6. S1340 단계에서 수신 단말의 PDN 타입이 서비스 제공 불가한 타입임을 확인한 S-CSCF는, P-CSCF에게 수신 단말의 정보(예를 들어, Public User Identity)와 함께 IBCF 장애/실패 알림을 전송할 수 있다. 이러한 알림을 수신한 P-CSCF는 PCRF를 거쳐 P-GW에게 수신 단말의 정보(예를 들어, Public User Identity)와 함께 IBCF 장애/실패로 인해 수신 단말에게 IMS 서비스의 제공 불가능하며, 수신 단말의 PDN 타입 변경이 필요함을 알릴 수 있다(S1350). 보다 상세하게는, P-CSCF는 PCRF에게 “PDN_TYPE_CHANGE” 지시가 포함된 Rx AAR 메시지를 전송하고, PCRF는 수신한 “PDN_TYPE_CHANGE” 지시가 포함된 Gx RAR 메시지를 P-GW(또는 PCEF)로 전송함으로써, IBCF 2의 장애/실패로 인해 수신 단말의 PDN 타입 변경이 필요함을 알릴 수 있다.
7. P-GW는 P-GW 개시 베어러 비활성화 절차(P-GW initiated Bearer deactivation procedure)를 통해 단말의 IMS PDN 연결을 해제할 수 있다(S1360).
6. P-GW 개시 베어러 비활성화 절차가 완료된 후, 단말은 이전 PDN 타입과 다른 PDN 타입으로 IMS PDN 연결을 재요청할 수 있다(S1370).
이때, 수신 단말이 이전 PDN 타입과 다르게 PDN 타입을 변경하는 방법에는 수신 단말이 직접 변경된 PDN 타입으로 IMS PDN 연결을 재요청하는 실시예, 또는 P-GW가 변경된 PDN 타입을 수신 단말에게 설정/할당해주는 실시예가 존재할 수 있다. 이러한 실시예들과 관련된 상세한 설명은 도 10 및 11과 관련하여 상술한 내용과 중복되므로 상세한 설명은 생략한다.
이렇듯 수신 단말은 변경된 PDN 타입으로 PDN 연결을 확립한 뒤, IMS 등록 절차를 완료할 수 있다. 이 경우, 수신 단말의 변경된 PDN 타입은 발신 단말의 IMS 네트워크 노드(예를 들어, S-CSCF)에 의해 서비스 제공 가능한 타입에 해당되므로, IBCF 2에 의한 별도의 IP 버전 변환 절차가 불필요하다. 따라서, IBCF 2에 장애가 발생하여 PDN 타입의 변환이 불가한 경우라도 정상적으로 IMS 서비스(또는 MT 서비스)의 제공이 가능하다.
한편, 상술한 실시예에서와 달리, IBCF 2에 논리적으로 직접 연결되어 있는 노드들(즉, P-CSCF 또는 S-CSCF)의 Keep-alive 메커니즘으로 IBCF 2의 장애를 인지하여, PDN 타입 변경(또는 IP 버전 변환)이 필요한 수신 단말들의 PDN 타입을 일괄적으로 변경해줄 수도 있다. 그러나, PDN 타입 변경에 따른 IMS 등록 과부화, EPC 시그널링 과부화 및 이미 서비스를 제공 받고 있는 단말에 대한 서비스 충돌 등의 문제를 방지하기 위해, 본 실시예에서와 같이 IMS 네트워크에 서비스를 요청한 수신 단말의 PDN 타입이 서비스 불가능한 타입일 경우에만 PDN 타입 변경 절차를 수행할 것을 제안한다.
도 14 및 15는 MO 서비스 제공 시, HSS를 중심으로 한 PDN 타입 변경 실시예를 예시한 도면이다. 도 14 및 15에서 MO 서비스를 요청한 단말은 도 8의 사전 절차를 완료하여 IMS 망에 등록된 단말에 해당할 수 있다. 또한, 이하에서 후술하는 단계들에 대한 설명은 도 10 내지 13에서의 설명이 동일/유사하게 적용될 수 있으며, 중복되는 설명은 생략한다.
1. 우선, IMS 네트워크에서 IP 버전 변환 기능을 수행하는 노드인 IBCF에 장애가 발생하여 IMS 네트워크 내 다른 노드(예를 들어, S-CSCF)(또는 단말의 IMS 네트워크)가 지원하지 않는 PDN 타입(또는 IP 버전)으로 MO 서비스(IMS 서비스)를 요청하는 단말에게 서비스 제공이 불가능하게 될 수 있다(S1510).
2. 이러한 IBCF의 장애를 인지하기 전, P-CSCF는 MO 서비스를 요청한 단말의 PDN 타입을 체크하여 단말의 IBCF를 통한 PDN 타입 변환이 필요한지 여부를 판단할 수 있다. PDN 타입 변환 필요 여부는 현재 단말에 설정/할당된 PDN 타입이 IMS 네트워크 내 일부 노드(예를 들어, S-CSCF)가 지원하는 PDN 타입인지 여부를 기초로 판단될 수 있다.
만일, PDN 타입 변환 절차가 필요하다고 판단될 경우(예를 들어, 단말의 PDN 타입이 IPv6인 경우), P-CSCF는 단말로부터 IMS 서비스를 요청/개시하기 위해 전송된 SIP INVITE 메시지/요청을 IBCF로 포워딩할 수 있다(S1520). 반대로, PDN 타입 변환 절차가 필요하지 않다고 판단될 경우(예를 들어, 단말의 PDN 타입이 IPv4인 경우), P-CSCF는 단말로부터 전송된 SIP INVITE 메시지/요청을 IBCF로 포워딩하지 않을 수 있다.
3. P-CSCF는 S1520 단계에 따른 SIP INVITE 메시지/요청에 대한 응답을 기설정된 시간 동안 IBCF로부터 수신하지 못함으로써, IBCF의 장애를 인지할 수 있다(S1530).
4. IBCF의 장애를 인지한 P-CSCF는 S-CSCF에 IBCF 장애/실패로 인해 단말에게 IMS 서비스의 제공 불가능함을 알리고, IMS 서비스를 제공받기 위해서는 단말의 PDN 타입 변경이 필요함을 해당 단말의 정보(예를 들어, Public User Identity)와 함께 알릴 수 있다(S1540).
5. S-CSCF는 HSS에 해당 단말(즉, 수신한 정보에 해당하는 단말)의 등록 취소를 요청하고, 해당 단말의 정보와 함께 IMS 서비스 제공을 위해 단말의 PDN 타입 변경이 필요함을 알릴 수 있다(S1550).
6. HSS는 수신한 단말의 정보에 해당하는 단말의 상태를 업데이트(즉, 단말의 등록 취소)하고, MME에게 단말의 정보와 함께 PDN 타입 변경이 필요함을 알릴 수 있다(S1560).
7. MME는 MME 개시 베어러 비활성화 절차(MME initiated Bearer deactivation procedure)를 통해 단말의 IMS PDN 연결을 해제할 수 있다(S1570).
8. MME 개시 베어러 비활성화 절차가 완료된 후, 단말은 이전/마지막 PDN 타입과 다른 PDN 타입으로 IMS PDN 연결을 재요청할 수 있다(S1580).
이때, 단말이 이전/마지막 PDN 타입과 다른 PDN 타입으로 변경하는 방법에는 아래와 같은 두 가지 실시예가 존재할 수 있다.
일 실시예로서, MME는 베어러 비활성화 절차 요청 시 단말로 전송하는 원인(cause)을 “PDP type IPv4 only allowed” 또는 “PDP type IPv6 only allowed”로 설정할 수 있다. 원인을 수신한 단말은 IMS PDN 연결 재요청 시, 수신한 원인이 지시하는 허용 PDN 타입(또는 이전에 설정했던 PDN 타입과는 다른 PDN 타입)으로 PDN 타입을 변경하여 IMS PDN 연결을 재요청(또는 재접속(re-attach)을 요청)할 수 있다. 다시 말하면, 단말은 베어러 비활성화 절차를 통해 MME로부터 획득한 원인이 지시하는 허용 PDN 타입으로 PDN 타입을 설정/변경하여 단말에 의한 PDN 연결 요청(UE requested PDN Connectivity request)을 수행함으로써 IMS PDN 연결을 획득할 수 있다.
다른 실시예로서, MME는 PDN 타입 변경이 필요한 단말을 기억해 두었다가(예를 들어, 단말의 식별 정보를 별도로 저장) 해당 단말의 PDN 연결 요청을 수신하였을 때, 해당 단말에게 IMS 서비스 제공이 가능한 PDN 타입을 할당/설정해줄 수 있다. 다시 말하면, 베어러 비활성화 절차를 통해 MME는 PDN 타입 변경이 필요한 단말을 미리 기억/저장해둘 수 있으며, 해당 단말에 의한 PDN 연결 요청(UE requested PDN Connectivity request)을 수신한 경우, 해당 단말에게 IMS 서비스가 가능한 PDN 타입(예를 들어, IPv4)을 설정/할당할 수 있다. 이때, 단말은 PDN 연결 요청 시, IMS 서비스 제공이 가능한 PDN 타입(예를 들어, IPv4)이 포함된 PDN 타입으로 PDN 연결을 요청할 수 있다.
이렇듯 단말은 변경된 PDN 타입으로 PDN 연결을 확립한 뒤, IMS 등록 절차를 완료할 수 있다. 나아가 단말은 IMS 서비스(또는 MO 서비스)를 요청하기 위한 SIP INVITE 메시지/요청을 IMS 네트워크로 전송할 수 있다. 이 경우, 단말의 PDN 타입은 IMS 네트워크 노드(예를 들어, S-CSCF)에 의해 서비스 제공 가능한 타입에 해당되므로, IBCF에 의한 별도의 IP 버전 변환 절차가 불필요하다. 따라서, 단말로부터 SIP INVITE 메시지/요청을 수신한 P-CSCF는 해당 메시지를 IBCF로 전송/포워딩하지 않고, S-CSCF로 바로 전송/포워딩할 수 있으며, 이 경우 해당 단말로의 정상적인 IMS 서비스 제공이 가능하다.
한편, 상술한 실시예에서와 달리, IBCF에 논리적으로 직접 연결되어 있는 노드들(즉, P-CSCF 또는 S-CSCF)의 Keep-alive 메커니즘으로 IBCF의 장애를 인지하여, PDN 타입 변경(또는 IP 버전 변환)이 필요한 단말들의 PDN 타입을 일괄적으로 변경해줄 수도 있다. 그러나, PDN 타입 변경에 따른 IMS 등록 과부화, EPC 시그널링 과부화 및 이미 서비스를 제공 받고 있는 단말에 대한 서비스 충돌 등의 문제를 방지하기 위해, 본 실시예에서와 같이 IMS 네트워크에 서비스를 요청한 단말의 PDN 타입이 서비스 불가능한 타입일 경우에만 PDN 타입 변경 절차를 수행할 것을 제안한다.
도 16 및 17은 MT 서비스 제공 시, HSS를 중심으로 한 PDN 타입 변경 실시예를 예시한 도면이다. 도 18 및 19에서 MT 서비스를 요청한 단말은 도 8의 사전 절차를 완료하여 IMS 망에 등록된 단말에 해당할 수 있다. 또한, 이하에서 후술하는 단계들에 대한 설명은 도 10 내지 15에서의 설명이 동일/유사하게 적용될 수 있으며, 중복되는 설명은 생략한다.
이하에서는 설명의 편의를 위해 IBCF를 기능/개념적으로 나누어, IMS 망간의 상호 연동 기능은 IBCF 1, PDN 타입(또는 IP 버전) 변환 기능은 IBCF 2라 지칭하기로 한다. 또한, 본 도면/실시예에서 IBCF 1은 정상 동작하며, IBCF 2에만 장애가 발생한 경우를 가정한다.
1. 우선, IMS 네트워크에서 IP 버전 변환 기능을 수행하는 노드인 IBCF 2에 장애가 발생하여, IMS 네트워크 내 일부 노드(예를 들어, S-CSCF)(또는 IMS 네트워크)가 지원하지 않는 PDN 타입(또는 IP 버전)을 갖는 수신 단말(MT UE)로 향하는 MT 서비스(또는 IMS 서비스)의 제공이 불가능하게 될 수 있다(S1710).
2. 이때, IBCF 2의 장애로 인해 IMS 서비스 제공이 불가능한 PDN 타입을 갖는 수신 단말로 향하는 MT/IMS 서비스 요청이 발생할 수 있다(S1720). 이러한 IBCF 2의 장애를 인지하기 전, S-CSCF는 수신 단말의 PDN 타입을 체크하여 IBCF 2를 통한 PDN 타입 변환이 필요한지 여부를 판단할 수 있다. PDN 타입 변환 필요 여부는 수신 단말의 PDN 타입이 IMS 네트워크 내 일부 노드(예를 들어, S-CSCF)가 지원하는 PDN 타입에 해당하는지 여부를 기초로 판단될 수 있다. 이를 위해, S-CSCF는 발신 단말로부터 IMS 서비스 요청/개시를 위해 수신한 SIP INVITE 메시지/요청에 포함되어 있는 수신 단말의 식별 정보를 이용할 수 있다.
만일, PDN 타입 변환 절차가 필요하다고 판단될 경우(예를 들어, 수신 단말의 PDN 타입이 IPv6인 경우), S-CSCF는 발신 단말(MO UE)로부터 IMS 서비스를 요청/개시하기 위해 전송된 SIP INVITE 메시지/요청을 IBCF 2로 포워딩할 수 있다. 반대로, PDN 타입 변환 절차가 필요하지 않다고 판단될 경우(예를 들어, 단말의 PDN 타입이 IPv4인 경우), S-CSCF는 발신 단말로부터 전송된 SIP INVITE 메시지/요청을 IBCF 2로 포워딩하지 않을 수 있다.
3. S-CSCF는 S1920 단계에 따른 SIP INVITE 메시지/요청에 대한 응답(예를 들어, 200 Trying 응답)을 기설정된 시간 동안 IBCF 2로부터 수신하지 못함으로써, IBCF 2의 장애를 인지할 수 있다(S1730).
4. IBCF 2의 장애를 인지한 S-CSCF는, 발신 단말의 PDN 타입이 수신 단말의 IMS 네트워크에 의해 서비스 가능한 타입에 해당하나, 수신 단말의 PDN 타입이 (IBCF 2의 장애로 인해) 수신 단말의 IMS 네트워크에 의해 서비스 제공이 불가능한 타입인 경우(예를 들어, IPv6인 경우), 발신 단말에게 “500 Try After”로 응답함으로써 발신 단말로 하여금 일정 시간 이후에 SIP INVITE 메시지/요청을 재전송하도록 할 수 있다(S1740). 또한, 만일 발신 단말의 PDN 타입이 수신 단말의 IMS 네트워크에 의해 서비스 제공이 불가능한 경우, S-CSCF는 발신 단말에게 “606 Not Acceptable with Warning 301 Incompatible network address formats”로 응답함으로써 IMS 서비스의 제공이 불가함을 알릴 수 있다(S1740).
5. S1940 단계에서 수신 단말의 PDN 타입이 서비스 제공 불가한 타입임을 확인한 S-CSCF는, HSS에게 수신 단말의 정보(예를 들어, Public User Identity)와 함께 수신 단말의 등록 취소를 요청함과 동시에 IMS 서비스 제공을 위해 수신 단말의 PDN 타입 변경이 필요함을 알릴 수 있다(S1750).
6. 이러한 알림을 수신한 HSS는 MME에게 수신 단말의 정보(예를 들어, Public User Identity)와 함께 수신 단말의 PDN 타입 변경이 필요함을 알릴 수 있다(S1760).
7. MME는 MME 개시 베어러 비활성화 절차(MME initiated Bearer deactivation procedure)를 통해 수신 단말의 IMS PDN 연결을 해제할 수 있다(S1770).
8. MME 개시 베어러 비활성화 절차가 완료된 후, 수신 단말은 이전/마지막 PDN 타입과 다른 PDN 타입으로 IMS PDN 연결을 재요청할 수 있다(S1780).
이때, 수신 단말이 이전/마지막 PDN 타입과 다른 PDN 타입으로 변경하는 방법에는 수신 단말이 직접 변경된 PDN 타입으로 IMS PDN 연결을 재요청하는 실시예, 또는 MME가 변경된 PDN 타입을 수신 단말에게 설정/할당해주는 실시예가 존재할 수 있다. 이러한 실시예들과 관련된 상세한 설명은 도 14 및 15와 관련하여 상술한 내용과 중복되므로 상세한 설명은 생략한다.
이렇듯 수신 단말은 변경된 PDN 타입으로 PDN 연결을 확립한 뒤, IMS 등록 절차를 완료할 수 있다. 이 경우, 수신 단말의 변경된 PDN 타입은 발신 단말의 IMS 네트워크 노드(예를 들어, S-CSCF)에 의해 서비스 제공 가능한 타입에 해당되므로, IBCF 2에 의한 별도의 IP 버전 변환 절차가 불필요하다. 따라서, IBCF 2에 장애가 발생하여 PDN 타입의 변환이 불가한 경우라도 정상적으로 IMS 서비스(또는 MT 서비스)의 제공이 가능하다.
한편, 상술한 실시예에서와 달리, IBCF 2에 논리적으로 직접 연결되어 있는 노드들(즉, P-CSCF 또는 S-CSCF)의 Keep-alive 메커니즘으로 IBCF 2의 장애를 인지하여, PDN 타입 변경(또는 IP 버전 변환)이 필요한 수신 단말들의 PDN 타입을 일괄적으로 변경해줄 수도 있다. 그러나, PDN 타입 변경에 따른 IMS 등록 과부화, EPC 시그널링 과부화 및 이미 서비스를 제공 받고 있는 단말에 대한 서비스 충돌 등의 문제를 방지하기 위해, 본 실시예에서와 같이 IMS 네트워크에 서비스를 요청한 수신 단말의 PDN 타입이 서비스 불가능한 타입일 경우에만 PDN 타입 변경 절차를 수행할 것을 제안한다.
도 18 및 19는 MO 서비스 제공 시, 단말을 중심으로 한 PDN 타입 변경 실시예를 예시한 도면이다. 도 18 및 19에서 MO 서비스를 요청한 단말은 도 8의 사전 절차를 완료하여 IMS 망에 등록된 단말에 해당할 수 있다. 또한, 이하에서 후술하는 단계들에 대한 설명은 도 10 내지 17에서의 설명이 동일/유사하게 적용될 수 있으며, 중복되는 설명은 생략한다.
1. 우선, IMS 네트워크에서 IP 버전 변환 기능을 수행하는 노드인 IBCF에 장애가 발생하여 IMS 네트워크 내 다른 노드(예를 들어, S-CSCF)(또는 단말의 IMS 네트워크)가 지원하지 않는 PDN 타입(또는 IP 버전)으로 MO 서비스(IMS 서비스)를 요청하는 단말에게 서비스 제공이 불가능하게 될 수 있다(S1910).
2. 이러한 IBCF의 장애를 인지하기 전, P-CSCF는 MO 서비스를 요청한 단말의 PDN 타입을 체크하여 단말의 IBCF를 통한 PDN 타입 변환이 필요한지 여부를 판단할 수 있다. PDN 타입 변환 필요 여부는 현재 단말에 설정/할당된 PDN 타입이 IMS 네트워크 내 일부 노드(예를 들어, S-CSCF)가 지원하는 PDN 타입인지 여부를 기초로 판단될 수 있다.
만일, PDN 타입 변환 절차가 필요하다고 판단될 경우(예를 들어, 단말의 PDN 타입이 IPv6인 경우), P-CSCF는 단말로부터 IMS 서비스를 요청/개시하기 위해 전송된 SIP INVITE 메시지/요청을 IBCF로 포워딩할 수 있다(S1920). 반대로, PDN 타입 변환 절차가 필요하지 않다고 판단될 경우(예를 들어, 단말의 PDN 타입이 IPv4인 경우), P-CSCF는 단말로부터 전송된 SIP INVITE 메시지/요청을 IBCF로 포워딩하지 않을 수 있다.
3. P-CSCF는 S1920 단계에 따른 SIP INVITE 메시지/요청에 대한 응답을 기설정된 시간 동안 IBCF로부터 수신하지 못함으로써, IBCF의 장애를 인지할 수 있다(S1930).
4. IBCF의 장애를 인지한 P-CSCF는, 단말의 SIP INVITE 메시지/요청에 대한 응답으로서 “606 Not Acceptable with Warning 301 Incompatible network address format” 메시지를 단말로 전송할 수 있다(S2140). 이때, P-CSCF는 606 Not Acceptable 응답에 “IP version incompatible(양립 불가한 IP 버전)” 지시를 포함시킬 수 있다. 이를 통해, P-CSCF는 추후에 단말이 IMS 네트워크가 서비스 제공 가능한 PDN 타입으로 IMS PDN 연결을 맺도록 할 수 있다.
5. 단말은 단말 요청 PDN 연결 해제 절차(UE requested PDN disconnection procedure)를 통해 IMS PDN 연결을 해제할 수 있다(S1950).
6. 연결 해제가 완료된 후, 단말은 이전/마지막 PDN 타입과 다른 PDN 타입으로 PDN 타입을 변경하여 IMS PDN 연결을 재요청할 수 있다(S1960). 이렇듯 단말은 변경된 PDN 타입으로 PDN 연결을 확립한 뒤, IMS 등록 절차를 완료할 수 있다. 나아가 단말은 IMS 서비스(또는 MO 서비스)를 요청하기 위한 SIP INVITE 메시지/요청을 IMS 네트워크로 전송할 수 있다.
한편, 상술한 실시예에서와 달리, IBCF에 논리적으로 직접 연결되어 있는 노드들(즉, P-CSCF 또는 S-CSCF)의 Keep-alive 메커니즘으로 IBCF의 장애를 인지하여, PDN 타입 변경(또는 IP 버전 변환)이 필요한 단말들의 PDN 타입을 일괄적으로 변경해줄 수도 있다. 그러나, PDN 타입 변경에 따른 IMS 등록 과부화, EPC 시그널링 과부화 및 이미 서비스를 제공 받고 있는 단말에 대한 서비스 충돌 등의 문제를 방지하기 위해, 본 실시예에서와 같이 IMS 네트워크에 서비스를 요청한 단말의 PDN 타입이 서비스 불가능한 타입일 경우에만 PDN 타입 변경 절차를 수행할 것을 제안한다.
도 20 및 21은 MT 서비스 제공 시, 단말을 중심으로 한 PDN 타입 변경 실시예를 예시한 도면이다. 도 20 및 21에서 MT 서비스를 요청한 단말은 도 8의 사전 절차를 완료하여 IMS 망에 등록된 단말에 해당할 수 있다. 또한, 이하에서 후술하는 단계들에 대한 설명은 도 10 내지 19에서의 설명이 동일/유사하게 적용될 수 있으며, 중복되는 설명은 생략한다.
이하에서는 설명의 편의를 위해 IBCF를 기능/개념적으로 나누어, IMS 망간의 상호 연동 기능은 IBCF 1, PDN 타입(또는 IP 버전) 변환 기능은 IBCF 2라 지칭하기로 한다. 또한, 본 도면/실시예에서 IBCF 1은 정상 동작하며, IBCF 2에만 장애가 발생한 경우를 가정한다.
1. 우선, IMS 네트워크에서 IP 버전 변환 기능을 수행하는 노드인 IBCF 2에 장애가 발생하여, IMS 네트워크 내 일부 노드(예를 들어, S-CSCF)(또는 IMS 네트워크)가 지원하지 않는 PDN 타입(또는 IP 버전)을 갖는 수신 단말(MT UE)로 향하는 MT 서비스(또는 IMS 서비스)의 제공이 불가능하게 될 수 있다(S2110).
2. 이때, IBCF 2의 장애로 인해 IMS 서비스 제공이 불가능한 PDN 타입을 갖는 수신 단말로 향하는 MT/IMS 서비스 요청이 발생할 수 있다(S2120). 이러한 IBCF 2의 장애를 인지하기 전, S-CSCF는 수신 단말의 PDN 타입을 체크하여 IBCF 2를 통한 PDN 타입 변환이 필요한지 여부를 판단할 수 있다. PDN 타입 변환 필요 여부는 수신 단말의 PDN 타입이 IMS 네트워크 내 일부 노드(예를 들어, S-CSCF)가 지원하는 PDN 타입에 해당하는지 여부를 기초로 판단될 수 있다. 이를 위해, S-CSCF는 발신 단말로부터 IMS 서비스 요청/개시를 위해 수신한 SIP INVITE 메시지/요청에 포함되어 있는 수신 단말의 식별 정보를 이용할 수 있다.
만일, PDN 타입 변환 절차가 필요하다고 판단될 경우(예를 들어, 수신 단말의 PDN 타입이 IPv6인 경우), S-CSCF는 발신 단말(MO UE)로부터 IMS 서비스를 요청/개시하기 위해 전송된 SIP INVITE 메시지/요청을 IBCF 2로 포워딩할 수 있다. 반대로, PDN 타입 변환 절차가 필요하지 않다고 판단될 경우(예를 들어, 단말의 PDN 타입이 IPv4인 경우), S-CSCF는 발신 단말로부터 전송된 SIP INVITE 메시지/요청을 IBCF 2로 포워딩하지 않을 수 있다.
3. S-CSCF는 S2120 단계에 따른 SIP INVITE 메시지/요청에 대한 응답(예를 들어, 200 Trying 응답)을 기설정된 시간 동안 IBCF 2로부터 수신하지 못함으로써, IBCF 2의 장애를 인지할 수 있다(S2130).
4. IBCF 2의 장애를 인지한 S-CSCF는, 발신 단말의 PDN 타입이 수신 단말의 IMS 네트워크에 의해 서비스 가능한 타입에 해당하나, 수신 단말의 PDN 타입이 (IBCF 2의 장애로 인해) 수신 단말의 IMS 네트워크에 의해 서비스 제공이 불가능한 타입인 경우(예를 들어, IPv6인 경우), 발신 단말에게 “500 Try After”로 응답함으로써 발신 단말로 하여금 일정 시간 이후에 SIP INVITE 메시지/요청을 재전송하도록 할 수 있다(S2140).
5. S2140 단계에서 수신 단말의 PDN 타입이 서비스 제공 불가한 타입임을 확인한 S-CSCF는, P-CSCF에게 수신 단말의 정보(예를 들어, Public User Identity)와 함께 수신 단말의 등록 취소를 요청함과 동시에 IBCF의 장애/실패(또는 IMS 서비스 제공을 위해 수신 단말의 PDN 타입 변경이 필요함)를 알릴 수 있다(S2150).
6. IBCF 2의 장애를 인지한 P-CSCF는, “606 Not Acceptable with Warning 301 Incompatible network address format” 메시지/응답을 수신 단말로 전송할 수 있다(S2360). 이때, P-CSCF는 606 Not Acceptable 메시지/응답에 “IP version incompatible(양립 불가한 IP 버전)” 지시를 포함시킬 수 있다.
7. 수신 단말은 단말 요청 PDN 연결 해제 절차(UE requested PDN disconnection procedure)를 통해 IMS PDN 연결을 해제할 수 있다(S2170).
8. 연결 해제가 완료된 후, 수신 단말은 이전/마지막 PDN 타입과 다른 PDN 타입으로 PDN 타입을 변경하여 IMS PDN 연결을 재요청할 수 있다(S2180). 이렇듯 수신 단말은 변경된 PDN 타입으로 PDN 연결을 확립한 뒤, IMS 등록 절차를 완료할 수 있다. 나아가 수신 단말은 IMS 서비스(또는 MO 서비스)를 요청하기 위한 SIP INVITE 메시지/요청을 IMS 네트워크로 전송할 수 있다.
한편, 상술한 실시예에서와 달리, IBCF 2에 논리적으로 직접 연결되어 있는 노드들(즉, P-CSCF 또는 S-CSCF)의 Keep-alive 메커니즘으로 IBCF 2의 장애를 인지하여, PDN 타입 변경(또는 IP 버전 변환)이 필요한 수신 단말들의 PDN 타입을 일괄적으로 변경해줄 수도 있다. 그러나, PDN 타입 변경에 따른 IMS 등록 과부화, EPC 시그널링 과부화 및 이미 서비스를 제공 받고 있는 단말에 대한 서비스 충돌 등의 문제를 방지하기 위해, 본 실시예에서와 같이 IMS 네트워크에 서비스를 요청한 수신 단말의 PDN 타입이 서비스 불가능한 타입일 경우에만 PDN 타입 변경 절차를 수행할 것을 제안한다.
도 22는 본 발명의 일 실시예에 따른 IMS(IP Multimedia Subsystem) 네트워크 장애 복구(restoration) 절차를 지원하기 위한 S-CSCF(Serving-CSCF)의 동작 방법을 예시한 순서도이다. 본 순서도와 관련하여, 도 12 내지 도 21의 설명이 동일하게 적용될 수 있으며, 중복되는 설명은 생략될 수 있다.
도 22를 참조하면, 우선, S-CSCF는 제1 단말로부터 제2 단말로 향하는 IMS 서비스를 요청하기 위한 SIP INVITE 요청을 수신할 수 있다(S2210). 여기서 제1 단말은 상술한 실시예들에서 MO 단말에 해당할 수 있으며, 제2 단말은 MT 단말에 해당할 수 있다.
다음으로, S-CSCF는 제1 단말에 할당된 제1 PDN 타입이 IMS 네트워크에 의해 서비스 가능한 PDN 타입인 경우, 제2 단말에 할당된 제2 PDN 타입이 IMS 네트워크에 의해 서비스 가능한 PDN 타입인지 판단할 수 있다(S2220). 여기서, IMS 네트워크는 제2 단말 측(즉, MT call 수신측)의 IMS 네트워크를 지칭할 수 있다. 본 단계에서, S-CSCF는 제1 단말로부터 수신한 SIP INVITE 요청에 포함된 정보를 기초로 제1 및 제2 단말의 PDN 타입을 알아낼 수 있으며, 해당 PDN 타입이 IMS 네트워크에 의새 서비스/지원 가능한 PDN 타입인지를 판단하게 된다.
다음으로, 만일 제2 단말의 제2 PDN 타입이 IMS 네트워크에 의해 서비스 불가능한 PDN 타입에 해당하는 경우, S-CSCF는 SIP INVITE 요청을 IBCF로 전달할 수 있다(S2230). 이는, IBCF를 통해 제2 단말의 제2 PDN 타입을 제1 PDN 타입으로 변경하기 위함이다.
다음으로, 만일 IBCF로부터 SIP INVITE 요청에 대한 응답을 기설정된 시간 동안 미수신하는 경우, S-CSCF는 제1 단말에게 기설정된 시간 후에 SIP INVITE 요청의 재시도를 지시할 수 있다. 나아가, S-CSCF는 IMS 네트워크에 포함된 적어도 하나의 노드에 제2 단말의 제2 PDN 타입을 변경하도록 지시할 수 있다.
여기서 적어도 하나의 노드는 P-CSCF 또는 HSS에 해당할 수 있으며, 해당 노드들로 제2 단말의 PDN 타입 변경을 지시하는 실시예는 앞서 도 10 내지 21과 관련하여 상술한 바와 같다.
도 23은 본 발명의 일 실시예에 따른 IMS(IP Multimedia Subsystem) 네트워크 장애 복구(restoration) 절차를 지원하기 위한 단말의 동작 방법을 예시한 순서도이다.
도 23을 참조하면, 우선, 단말은 제2 PDN 타입을 할당받아 IMS 네트워크와 연결될 수 있다(S2310). 본 순서도에서 단말은 상술한 실시예들에서 MT 단말에 해당할 수 있다. 또한, 여기서, IMS 네트워크는 제2 단말 측(즉, MT call 수신측)의 IMS 네트워크를 지칭할 수 있으며, 해당 네트워크는 제1 PDN 타입에 대해서만 서비스/지원이 가능하다고 가정한다.
다음으로, 단말은 다른 노드로부터 IMS 네트워크에 포함된 IBCF의 장애로 인하여 제2 PDN 타입을 변경하도록 지시받을 수 있다(S2320). 여기서 다른 노드는 실시예에 따라 P-GW 또는 MME에 해당할 수 있다.
다음으로, 단말은 IMS 네트워크와의 연결을 해제할 수 있다(S2330).
보다 상세하게는, 다른 노드가 P-GW에 해당하는 경우에는 단말은 P-GW로부터 P-GW 개시 베어러 비활성화 절차(P-GW initiated Bearer deactivation procedure) 요청을 수신함으로써 IMS 네트워크와의 연결을 해제할 수 있다. 이때, P-GW 개시 베어러 비활성화 절차 요청의 원인으로서 단말의 제2 PDN 타입의 변경을 수신할 수 있다.
또는, 다른 노드가 MME에 해당하는 경우, 단말은 MME로부터 MME 개시 베어러 비활성화 절차(MME initiated Bearer deactivation procedure) 요청을 수신함으로써 IMS 네트워크와의 연결을 해제할 수 있다. 이때, 단말은 MME 개시 베어러 비활성화 절차 요청의 원인으로서 허용 가능한 PDN 타입인 상기 제1 PDN 타입에 관한 지시 정보를 수신할 수 있다.
마지막으로, 단말은 제1 PDN 타입으로 IMS 네트워크와 재연결될 수 있다(S2340). 보다 상세하게는, 단말은 제1 PDN 타입이 포함된 PDN 타입으로 IMS 네트워크와의 재연결을 요청하여, 다른 노드(예를 들어, P-GW 또는 MME)에 의해 제1 PDN 타입을 할당 받을 수 있다. 그 결과, 단말은 할당받은 제1 PDN 타입으로 IMS 네트워크에 등록될 수 있다.
본 발명이 적용될 수 있는 장치 일반
도 24은 본 발명의 일 실시예에 따른 통신 장치의 블록 구성도를 예시한다.
도 24을 참조하면, 무선 통신 시스템은 네트워크 노드(2410)와 다수의 단말(UE)(2420)을 포함한다.
네트워크 노드(2410)는 프로세서(processor, 2411), 메모리(memory, 2412) 및 통신 모듈(communication module, 2413)을 포함한다. 프로세서(2411)는 앞서 도 1 내지 도 24에서 제안된 기능, 과정 및/또는 방법을 구현한다. 유/무선 인터페이스 프로토콜의 계층들은 프로세서(2411)에 의해 구현될 수 있다. 메모리(2412)는 프로세서(2411)와 연결되어, 프로세서(2411)를 구동하기 위한 다양한 정보를 저장한다. 통신 모듈(2413)은 프로세서(2411)와 연결되어, 유/무선 신호를 송신 및/또는 수신한다. 네트워크 노드(2410)의 일례로, 기지국, MME, HSS, SGW, PGW, 어플리케이션 서버 등이 이에 해당될 수 있다. 특히, 네트워크 노드(2410)가 기지국인 경우, 통신 모듈(2413)은 무선 신호를 송/수신하기 위한 RF부(radio frequency unit)을 포함할 수 있다.
단말(2420)은 프로세서(2421), 메모리(2422) 및 통신 모듈(또는 RF부)(2423)을 포함한다. 프로세서(2421)는 앞서 도 1 내지 도 21에서 제안된 기능, 과정 및/또는 방법을 구현한다. 무선 인터페이스 프로토콜의 계층들은 프로세서(2421)에 의해 구현될 수 있다. 메모리(2422)는 프로세서(2421)와 연결되어, 프로세서(2421)를 구동하기 위한 다양한 정보를 저장한다. 통신 모듈(2423)는 프로세서(2421)와 연결되어, 무선 신호를 송신 및/또는 수신한다.
메모리(2412, 2422)는 프로세서(2411, 2421) 내부 또는 외부에 있을 수 있고, 잘 알려진 다양한 수단으로 프로세서(2411, 2421)와 연결될 수 있다. 또한, 네트워크 노드(2410)(기지국인 경우) 및/또는 단말(2420)은 한 개의 안테나(single antenna) 또는 다중 안테나(multiple antenna)를 가질 수 있다.
도 25은 본 발명의 일 실시예에 따른 통신 장치의 블록 구성도를 예시한다.
특히, 도 25에서는 앞서 도 24의 단말을 보다 상세히 예시하는 도면이다.
도 25를 참조하면, 단말은 프로세서(또는 디지털 신호 프로세서(DSP: digital signal processor)(2510), RF 모듈(RF module)(또는 RF 유닛)(2535), 파워 관리 모듈(power management module)(2505), 안테나(antenna)(2540), 배터리(battery)(2555), 디스플레이(display)(2515), 키패드(keypad)(2520), 메모리(memory)(2530), 심카드(SIM(Subscriber Identification Module) card)(2525)(이 구성은 선택적임), 스피커(speaker)(2545) 및 마이크로폰(microphone)(2550)을 포함하여 구성될 수 있다. 단말은 또한 단일의 안테나 또는 다중의 안테나를 포함할 수 있다.
프로세서(2510)는 앞서 도 1 내지 도 23에서 제안된 기능, 과정 및/또는 방법을 구현한다. 무선 인터페이스 프로토콜의 계층은 프로세서(2510)에 의해 구현될 수 있다.
메모리(2530)는 프로세서(2510)와 연결되고, 프로세서(2510)의 동작과 관련된 정보를 저장한다. 메모리(2530)는 프로세서(2510) 내부 또는 외부에 있을 수 있고, 잘 알려진 다양한 수단으로 프로세서(2510)와 연결될 수 있다.
사용자는 예를 들어, 키패드(2520)의 버튼을 누르거나(혹은 터치하거나) 또는 마이크로폰(2550)를 이용한 음성 구동(voice activation)에 의해 전화 번호 등과 같은 명령 정보를 입력한다. 프로세서(2510)는 이러한 명령 정보를 수신하고, 전화 번호로 전화를 거는 등 적절한 기능을 수행하도록 처리한다. 구동 상의 데이터(operational data)는 심카드(2525) 또는 메모리(2530)로부터 추출할 수 있다. 또한, 프로세서(2510)는 사용자가 인지하고 또한 편의를 위해 명령 정보 또는 구동 정보를 디스플레이(2515) 상에 디스플레이할 수 있다.
RF 모듈(2535)는 프로세서(2510)에 연결되어, RF 신호를 송신 및/또는 수신한다. 프로세서(2510)는 통신을 개시하기 위하여 예를 들어, 음성 통신 데이터를 구성하는 무선 신호를 전송하도록 명령 정보를 RF 모듈(2535)에 전달한다. RF 모듈(2535)은 무선 신호를 수신 및 송신하기 위하여 수신기(receiver) 및 전송기(transmitter)로 구성된다. 안테나(2540)는 무선 신호를 송신 및 수신하는 기능을 한다. 무선 신호를 수신할 때, RF 모듈(2535)은 프로세서(2510)에 의해 처리하기 위하여 신호를 전달하고 기저 대역으로 신호를 변환할 수 있다. 처리된 신호는 스피커(2545)를 통해 출력되는 가청 또는 가독 정보로 변환될 수 있다.
이상에서 설명된 실시예들은 본 발명의 구성요소들과 특징들이 소정 형태로 결합된 것들이다. 각 구성요소 또는 특징은 별도의 명시적 언급이 없는 한 선택적인 것으로 고려되어야 한다. 각 구성요소 또는 특징은 다른 구성요소나 특징과 결합되지 않은 형태로 실시될 수 있다. 또한, 일부 구성요소들 및/또는 특징들을 결합하여 본 발명의 실시예를 구성하는 것도 가능하다. 본 발명의 실시예들에서 설명되는 동작들의 순서는 변경될 수 있다. 어느 실시예의 일부 구성이나 특징은 다른 실시예에 포함될 수 있고, 또는 다른 실시예의 대응하는 구성 또는 특징과 교체될 수 있다. 특허청구범위에서 명시적인 인용 관계가 있지 않은 청구항들을 결합하여 실시예를 구성하거나 출원 후의 보정에 의해 새로운 청구항으로 포함시킬 수 있음은 자명하다.
본 발명에 따른 실시예는 다양한 수단, 예를 들어, 하드웨어, 펌웨어(firmware), 소프트웨어 또는 그것들의 결합 등에 의해 구현될 수 있다. 하드웨어에 의한 구현의 경우, 본 발명의 일 실시예는 하나 또는 그 이상의 ASICs(application specific integrated circuits), DSPs(digital signal processors), DSPDs(digital signal processing devices), PLDs(programmable logic devices), FPGAs(field programmable gate arrays), 프로세서, 콘트롤러, 마이크로 콘트롤러, 마이크로 프로세서 등에 의해 구현될 수 있다.
펌웨어나 소프트웨어에 의한 구현의 경우, 본 발명의 일 실시예는 이상에서 설명된 기능 또는 동작들을 수행하는 모듈, 절차, 함수 등의 형태로 구현될 수 있다. 소프트웨어 코드는 메모리에 저장되어 프로세서에 의해 구동될 수 있다. 상기 메모리는 상기 프로세서 내부 또는 외부에 위치하여, 이미 공지된 다양한 수단에 의해 상기 프로세서와 데이터를 주고 받을 수 있다.
본 발명은 본 발명의 필수적 특징을 벗어나지 않는 범위에서 다른 특정한 형태로 구체화될 수 있음은 당업자에게 자명하다. 따라서, 상술한 상세한 설명은 모든 면에서 제한적으로 해석되어서는 아니 되고 예시적인 것으로 고려되어야 한다. 본 발명의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고, 본 발명의 등가적 범위 내에서의 모든 변경은 본 발명의 범위에 포함된다.
발명의 실시를 위한 다양한 형태가 발명의 실시를 위한 최선의 형태에서 설명되었다.
본 발명은 3GPP LTE/LTE-A 시스템에 적용되는 예를 중심으로 설명하였으나, 3GPP LTE/LTE-A 시스템 이외에도 다양한 무선 통신 시스템에 적용하는 것이 가능하다.

Claims (15)

  1. IMS(IP Multimedia Subsystem) 네트워크 장애 복구(restoration) 절차를 지원하기 위한 S-CSCF(Serving-CSCF)의 동작 방법에 있어서,
    제1 단말로부터 제2 단말로 향하는 IMS 서비스를 요청하기 위한 SIP(Session Initiation Protocol) INVITE 요청을 수신하는 단계;
    상기 제1 단말에 할당된 제1 PDN(Packet Data Network) 타입이 상기 IMS 네트워크에 의해 서비스 가능한 PDN 타입인 경우, 상기 제2 단말에 할당된 제2 PDN 타입이 상기 IMS 네트워크에 의해 서비스 가능한 PDN 타입인지 판단하는 단계;
    상기 제2 PDN 타입이 상기 IMS 네트워크에 의해 서비스 불가능한 PDN 타입인 경우, 상기 수신한 SIP INVITE 요청을 IBCF(Interconnection Border Control Functions)로 전달하는 단계; 및
    상기 IBCF로부터 상기 SIP INVITE 요청에 대한 응답을 기설정된 시간 동안 미수신하는 경우, 상기 제1 단말에게 기설정된 시간 후에 상기 SIP INVITE 요청의 재시도를 지시하고, 상기 IMS 네트워크에 포함된 적어도 하나의 노드에 상기 제2 단말의 상기 제2 PDN 타입을 변경하도록 지시하는 단계; 를 포함하는, S-CSCF의 동작 방법.
  2. 제 1 항에 있어서,
    상기 IMS 네트워크에 의해 서비스 불가능한 PDN 타입은 상기 S-CSCF가 지원하지 않는 PDN 타입에 해당하는, S-CSCF의 동작 방법.
  3. 제 1 항에 있어서,
    상기 제1 PDN 타입은 IP(Internet Protocol) 버전 4에 해당하며, 상기 제2 PDN 타입은 IP 버전 6에 해당하는, S-CSCF의 동작 방법.
  4. 제 1 항에 있어서,
    상기 IMS 네트워크에 포함된 적어도 하나의 노드가 P-CSCF(Proxy-CSCF)에 해당하는 경우, 상기 제2 단말의 상기 제2 PDN 타입을 변경하도록 지시하는 단계는,
    상기 P-CSCF에 상기 제2 단말의 식별 정보와 함께 상기 제2 단말의 상기 제2 PDN 타입을 변경하도록 지시하는 단계인, S-CSCF의 동작 방법.
  5. 제 4 항에 있어서,
    상기 제2 단말의 식별 정보 및 상기 제2 PDN 타입의 변경은, 상기 P-CSCF에 의해 PCRF(Policy and Charging Rules Function)를 거쳐 P-GW(Packet Data Network Gateway)로 지시되는, S-CSCF의 동작 방법.
  6. 제 5 항에 있어서,
    상기 제2 단말의 식별 정보 및 상기 제2 PDN 타입의 변경은,
    Rx AAR(Authorization Authentication Request) 메시지를 통해 상기 P-CSCF로부터 상기 PCRF에게 지시되며,
    Gx RAR(Re-Authorization Request) 메시지를 통해 상기 PCRF로부터 상기 P-GW에게 지시되는, S-CSCF의 동작 방법.
  7. 제 4 항에 있어서,
    상기 IMS 네트워크에 의한 서비스가 불가함은 상기 P-CSCF에 의해 상기 제2 단말에게 지시되는, S-CSCF의 동작 방법.
  8. 제 1 항에 있어서,
    상기 IMS 네트워크에 포함된 적어도 하나의 노드가 HSS에 해당하는 경우, 상기 제2 단말의 상기 제2 PDN 타입을 변경하도록 지시하는 단계는,
    상기 HSS(Home Subscriber Server)에 상기 제2 단말의 식별 정보와 함께 상기 제2 단말의 상기 제2 PDN 타입의 변경을 지시하고, 상기 제2 단말의 등록 취소를 요청하는 단계인, S-CSCF의 동작 방법.
  9. 제 8 항에 있어서,
    상기 제2 단말의 식별 정보, 상기 제2 PDN 타입의 변경 및 제2 단말의 등록 취소는, 상기 HSS에 의해 MME(Mobility Management Entity)에게 지시되며,
    상기 HSS의 지시에 따라 상기 MME에 의해 개시된 MME 개시 베어러 비활성화 절차(MME initiated bearer deactivation)를 통해 상기 제2 단말의 상기 IMS 네트워크에 대한 IMS 연결이 해제되는, S-CSCF의 동작 방법.
  10. IMS(IP Multimedia Subsystem) 네트워크 장애 복구(restoration) 절차를 지원하기 위한 단말의 동작 방법에 있어서,
    제2 PDN 타입을 할당 받아 상기 IMS 네트워크와 연결되는 단계; 로서, 상기 IMS 네트워크에 포함된 S-CSCF는 제1 PDN 타입을 지원함,
    다른 노드로부터 상기 IMS 네트워크에 포함된 IBCF의 장애로 인하여 상기 제2 PDN 타입을 변경하도록 지시받는 단계;
    상기 IMS 네트워크와의 연결을 해제하는 단계; 및
    상기 제1 PDN 타입으로 상기 IMS 네트워크와 재연결되는 단계; 를 포함하는, 단말의 동작 방법.
  11. 제 10 항에 있어서,
    상기 다른 노드가 P-GW에 해당하는 경우, 상기 IMS 네트워크와의 연결을 해제하는 단계는,
    상기 P-GW로부터 P-GW 개시 베어러 비활성화 절차(P-GW initiated Bearer deactivation procedure) 요청을 수신하되, 상기 절차 요청의 원인으로서 상기 제2 PDN 타입의 변경을 수신하는 단계; 를 포함하는, 단말의 동작 방법.
  12. 제 11 항에 있어서,
    상기 제1 PDN 타입으로 상기 IMS 네트워크와 재연결되는 단계는,
    상기 제1 PDN 타입이 포함된 PDN 타입으로 상기 IMS 네트워크와의 재연결을 요청하는 단계;
    상기 P-GW에 의해 상기 제1 PDN 타입을 할당 받는 단계; 및
    상기 제1 PDN 타입으로 상기 IMS 네트워크에 등록되는 단계; 를 포함하는, 단말의 동작 방법.
  13. 제 10 항에 있어서,
    상기 다른 노드가 MME에 해당하는 경우, 상기 IMS 네트워크와의 연결을 해제하는 단계는,
    상기 MME로부터 MME 개시 베어러 비활성화 절차(MME initiated Bearer deactivation procedure) 요청을 수신하되, 상기 절차 요청의 원인으로서 허용 가능한 PDN 타입인 상기 제1 PDN 타입에 관한 지시 정보를 수신하는 단계; 를 포함하는, 단말의 동작 방법.
  14. 제 13 항에 있어서,
    상기 제1 PDN 타입으로 상기 IMS 네트워크와 재연결되는 단계는,
    상기 제1 PDN 타입이 포함된 PDN 타입으로 상기 IMS 네트워크와의 재연결을 요청하는 단계;
    상기 MME에 의해 상기 제1 PDN 타입을 할당 받는 단계; 및
    상기 제1 PDN 타입으로 상기 IMS 네트워크에 등록되는 단계; 를 포함하는, 단말의 동작 방법.
  15. 제 10 항에 있어서,
    상기 다른 노드가 P-CSCF에 해당하는 경우, 상기 제1 PDN 타입으로 상기 IMS 네트워크와 재연결되는 단계는,
    상기 제1 PDN 타입이 포함된 PDN 타입으로 상기 IMS 네트워크와의 재연결을 요청하는 단계;
    상기 P-CSCF에 의해 상기 제1 PDN 타입을 할당 받는 단계; 및
    상기 제1 PDN 타입으로 상기 IMS 네트워크에 등록되는 단계; 를 포함하는, 단말의 동작 방법.
PCT/KR2016/008908 2015-08-12 2016-08-12 인터넷 프로토콜 멀티미디어 서브시스템 네트워크의 장애 복구 지원 방법 및 이를 위한 장치 WO2017026846A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201562204420P 2015-08-12 2015-08-12
US62/204,420 2015-08-12

Publications (1)

Publication Number Publication Date
WO2017026846A1 true WO2017026846A1 (ko) 2017-02-16

Family

ID=57983319

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2016/008908 WO2017026846A1 (ko) 2015-08-12 2016-08-12 인터넷 프로토콜 멀티미디어 서브시스템 네트워크의 장애 복구 지원 방법 및 이를 위한 장치

Country Status (1)

Country Link
WO (1) WO2017026846A1 (ko)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110213896A1 (en) * 2008-10-31 2011-09-01 Telefonaktiebolaget Lm Ericsson (Publ) Ims restoration procedures for multiple contacts
KR101173836B1 (ko) * 2011-03-17 2012-08-14 텔코웨어 주식회사 Ｉｍｓ망에서 ｓ-ｃｓｃｆ 장애 복구 후 착신 및 발신 호 처리 방법 및 그 시스템
US20130121255A1 (en) * 2010-07-23 2013-05-16 Jian Wang Gating control in a telecommunication system
WO2015044663A1 (en) * 2013-09-24 2015-04-02 Nec Europe Ltd P-cscf restoration

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110213896A1 (en) * 2008-10-31 2011-09-01 Telefonaktiebolaget Lm Ericsson (Publ) Ims restoration procedures for multiple contacts
US20130121255A1 (en) * 2010-07-23 2013-05-16 Jian Wang Gating control in a telecommunication system
KR101173836B1 (ko) * 2011-03-17 2012-08-14 텔코웨어 주식회사 Ｉｍｓ망에서 ｓ-ｃｓｃｆ 장애 복구 후 착신 및 발신 호 처리 방법 및 그 시스템
WO2015044663A1 (en) * 2013-09-24 2015-04-02 Nec Europe Ltd P-cscf restoration

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Digital Cellular Telecommunications System; UTMS: LTE: IMS Restoration Procedure", 3GPP TS 23.380 V12.0.0, 12 October 2014 (2014-10-12), XP014223494, Retrieved from the Internet <URL:http://www.etsi.org/deliver/etsi_ts/123300_123399/123380/12.00.00 _60/ts_123380v12000 0p.pdf> *

Similar Documents

Publication Publication Date Title
WO2018080230A1 (ko) 무선 통신 시스템에서 emm 모드를 결정하는 방법 및 이를 위한 장치
WO2018147698A1 (ko) 무선 통신 시스템에서 nas 메시지 송수신 방법 및 이를 위한 장치
WO2017188758A1 (ko) 무선 통신 시스템에서 nas 시그널링 유보/재개를 수행하기 위한 방법 및 이를 위한 장치
WO2017200269A1 (ko) 무선 통신 시스템에서 착신 데이터 제어 방법 및 이를 위한 장치
WO2018155908A1 (ko) 무선 통신 시스템에서 릴레이를 통한 데이터 송수신 방법 및 이를 위한 장치
WO2017126884A1 (ko) 무선 통신 시스템에서 혼잡 제어 방법 및 이를 위한 장치
WO2017171451A1 (ko) 무선 통신 시스템에서의 버퍼링된 데이터 전송 방법 및 이를 위한 장치
WO2018231007A1 (ko) 요청에 대한 응답 방법 및 네트워크 장치
WO2018128528A1 (ko) 무선 통신 시스템에서 pdu 세션 관리 방법 및 이를 위한 장치
WO2017164679A1 (ko) 무선 통신 시스템에서 트래킹 영역 업데이트 방법 및 이를 위한 장치
WO2017082682A1 (ko) 무선 통신 시스템에서의 데이터 전송 모드 선택 방법 및 이를 위한 장치
WO2018131984A1 (ko) 무선 통신 시스템에서 ue 설정 업데이트 방법 및 이를 위한 장치
WO2018174525A1 (ko) 무선 통신 시스템에서 계층간 상호작용 방법 및 이를 위한 장치
WO2017086717A1 (ko) 무선 통신 시스템에서 확장된 아이들 모드 불연속 수신 활성화 지원 방법 및 이를 위한 장치
WO2017142363A1 (ko) 서비스 요청 전송 및 사용자기기, 그리고 서비스 요청 수신 및 기지국
WO2017119802A1 (ko) 무선 통신 시스템에서 nidd(non-ip data delivery) 구성 설정 방법 및 이를 위한 장치
WO2017048042A1 (ko) 무선 통신 시스템에서의 페이징 절차를 수행하는 방법 및 이를 위한 장치
WO2018226072A2 (ko) 무선 통신 시스템에서 오버로드 제어 방법 및 이를 위한 장치
WO2018097599A1 (ko) 무선 통신 시스템에서의 등록 해제 방법 및 이를 위한 장치
WO2018088812A1 (ko) 핸드오버 방법 및 사용자기기
WO2017171250A2 (ko) 무선 통신 시스템에서의 pc5 자원 할당 방법 및 이를 위한 장치
WO2018079947A1 (ko) 무선 통신 시스템에서 ue 이동성을 지원하기 위한 방법 및 이를 위한 장치
WO2018128519A1 (ko) 무선 통신 시스템에서 리모트 ue와 연결을 가진 릴레이 ue가 네트워크와 연결 수행 방법 및 이를 위한 장치
WO2014058244A1 (ko) 페이징 처리 방법 및 다운링크 데이터 전달 방법
WO2016099138A1 (ko) 무선 통신 시스템에서 페이징 전송 방법 및 이를 위한 장치

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16835486

Country of ref document: EP

Kind code of ref document: A1