WO2018155903A1 - 무선 통신 시스템에서 암호화 파라미터 값을 결정하기 위한 장치 및 방법 - Google Patents

무선 통신 시스템에서 암호화 파라미터 값을 결정하기 위한 장치 및 방법 Download PDF

Info

Publication number
WO2018155903A1
WO2018155903A1 PCT/KR2018/002132 KR2018002132W WO2018155903A1 WO 2018155903 A1 WO2018155903 A1 WO 2018155903A1 KR 2018002132 W KR2018002132 W KR 2018002132W WO 2018155903 A1 WO2018155903 A1 WO 2018155903A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
decompression
parameter value
failure
value
Prior art date
Application number
PCT/KR2018/002132
Other languages
English (en)
French (fr)
Inventor
윤태호
Original Assignee
삼성전자주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자주식회사 filed Critical 삼성전자주식회사
Priority to US16/487,284 priority Critical patent/US11770249B2/en
Publication of WO2018155903A1 publication Critical patent/WO2018155903A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/12—Transmitting and receiving encryption devices synchronised or initially set up in a particular manner
    • 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/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0433—Key management protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/04—Arrangements for maintaining operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/04—Error control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W56/00—Synchronisation arrangements
    • H04W56/001—Synchronization between nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/30—Compression, e.g. Merkle-Damgard construction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H04L63/205—Network architectures or network communication protocols for network security for managing network security; network security policies in general involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved

Definitions

  • the present disclosure generally relates to a wireless communication system, and more particularly, to an apparatus and a method for preventing data decryption failure in a wireless communication system.
  • VoIP voice over internet protocol
  • LTE long term evolution
  • VoIP voice over LTE
  • VoIP Voice calls over VoLTE use RoHC (Robust Header Compression), a technology that compresses headers of IP, UDP (User Datagram Protocol), and Real-time Transport Protocol (RTP) to save radio resources.
  • RoHC Robot Header Compression
  • UDP User Datagram Protocol
  • RTP Real-time Transport Protocol
  • the base station can significantly reduce the amount of data passing through the radio section by transmitting the header-compressed packets to each other and decompressing and restoring the received compressed packets.
  • the present disclosure provides an apparatus and method for determining encryption parameters of data in a wireless communication system.
  • the present disclosure also provides an apparatus and method for preventing a data decryption failure received in a wireless communication system.
  • the present disclosure also provides an apparatus and method for adjusting encryption parameters to prevent data decryption failures received in a wireless communication system.
  • the present disclosure also provides an apparatus and method for preventing encryption parameter mismatches when data loss occurs due to a wireless environment in a wireless communication system.
  • the present disclosure provides an apparatus and method for preventing voice call truncation due to a mismatch of a hyper frame number (HFN), which is one of decryption key values, in a wireless communication system.
  • HFN hyper frame number
  • a method of operating a receiver in a wireless communication system may include receiving a packet from a transmitter, performing a decryption using an encryption parameter on the received packet, and decrypting the received packet. Detecting a failure in decompression of the header, and adjusting a value of the encryption parameter in response to detecting the failure in decompression.
  • a receiving end device in a wireless communication system may perform a decoding process using a transmitting and receiving unit for receiving a packet from a transmitting end, an encryption parameter for the received packet, and compressing the decrypted packet header. And a control unit for detecting a failure of the release and adjusting a value of the encryption parameter in response to the detection of the failure for the decompression.
  • the apparatus and method according to various embodiments of the present disclosure may prevent decryption failure by detecting and automatically correcting an inconsistency of encryption parameters when packet loss occurs due to a wireless environment. This prevents the 1-way phenomenon of the voice call and prevents the disconnection of the voice call.
  • FIG. 1 illustrates a wireless communication system according to various embodiments of the present disclosure.
  • FIG. 2 is a block diagram of a receiver in a wireless communication system according to various embodiments of the present disclosure.
  • FIG. 3A illustrates a state control process of a compressor when using a Robust Header Compression (RoHC) scheme in a wireless communication system according to various embodiments of the present disclosure.
  • RoHC Robust Header Compression
  • 3B is a flowchart illustrating a state control process of a decompressor when using the RoHC method in a wireless communication system according to various embodiments of the present disclosure.
  • FIG. 4 illustrates a method of operating a receiver in a wireless communication system according to various embodiments of the present disclosure.
  • FIG. 5 illustrates a method for operation of a receiver through RoHC decompression in a wireless communication system according to various embodiments of the present disclosure.
  • FIG. 6 is a flowchart illustrating a method of operating a receiver after feedback transmission due to decompression failure in a wireless communication system according to various embodiments of the present disclosure.
  • the present disclosure relates to an apparatus and method for determining encryption parameters of data in a wireless communication system. Specifically, the present disclosure describes a technique for preventing encryption parameter de-synchronization when packet loss occurs due to a wireless environment in a wireless communication system.
  • control information eg, HFN, PDCP SN, etc.
  • terms referring to components of a device terms referring to communication technology, and the like are described. It is illustrated for convenience. Thus, the present disclosure is not limited to the terms described below, and other terms having equivalent technical meanings may be used.
  • LTE long term evolution
  • LTE-A LTE-advanced
  • the system includes an access network 130 that includes a terminal 110 and a base station 120, and an IP multimedia subsystem 140.
  • the terminal 110 is a user device and communicates with the base station 120 through a wireless channel.
  • the terminal 110 provides a voice over internet protocol (VoIP) function and executes an application for VoIP service according to a user's command. Accordingly, the terminal 110 may transmit and receive a voice packet for the VoIP service with the base station 120.
  • the terminal 110 may be a portable electronic device, and may be a smart phone, a portable terminal, a mobile phone, a mobile pad, or a media player. (media player), tablet computer (tablet computer), handheld computer (handheld computer) or a personal digital assistant (PDA).
  • the terminal 110 may be a stationary device.
  • the terminal 110 may be a device combining two or more functions of the above-described devices.
  • the base station 120 provides a wireless connection to the terminal 110.
  • the base station 120 is one of the entities constituting the access network 130 and has coverage including a certain geographical range.
  • the base station 120 includes an access point (AP), an evolved nodeB (eNB), a 5th generation node, a wireless point, It may be referred to as a transmission / reception point (TRP) or another term having an equivalent technical meaning.
  • AP access point
  • eNB evolved nodeB
  • TRP transmission / reception point
  • the terminal 110 and the base station 120 may each be a transmitting end or a receiving end in various embodiments described below. That is, when the terminal 110 receives data from the base station 120, the terminal 110 is a receiving end and the base station 120 is a transmitting end. In contrast, when the terminal 110 transmits data to the base station 120, the terminal 110 is a transmitting end and the base station 120 is a receiving end. Accordingly, in various embodiments of the present disclosure, the transmitting end may be the terminal 110 or the base station 120, and in this case, the receiving end may be the base station 120 or the terminal 110, respectively.
  • the access network 130 is a system for connecting the terminal 110 to an external network (eg, an internet protocol (IP) network).
  • IP internet protocol
  • the access network 130 may further include not only the base station 120 but also other objects such as a gateway and a mobility management entity (MME). Can be.
  • MME mobility management entity
  • IMS 140 is a subsystem for managing sessions. IMS 140 can operate independently of access network 130.
  • the IMS 140 may provide multimedia services such as voice, audio, video, and data based on IP.
  • VoIP voice over LTE
  • the voice packet is transmitted and received via the IMS 140.
  • IMS 140 may include a proxy-call session control function (P-CSCF), a serving-call session control function (S-CSCF), an interrogating-call session control function (I-CSCF), a PCRF, a home subscriberserver (HSS), and the like. Can be.
  • P-CSCF proxy-call session control function
  • S-CSCF serving-call session control function
  • I-CSCF interrogating-call session control function
  • PCRF home subscriberserver
  • HSS home subscriberserver
  • FIG. 2 is a block diagram of a receiver 200 in a wireless communication system according to various embodiments of the present disclosure.
  • 2 may be understood as a configuration of a terminal 110 or a base station 120.
  • the terms '... unit' and '... unit' used below mean a unit for processing at least one function or operation, which may be implemented by hardware or software, or a combination of hardware and software. have.
  • the receiver includes a communication unit 210, a storage unit 220, and a control unit 230.
  • the communication unit 210 performs functions for transmitting and receiving a signal through a wireless channel. For example, the communication unit 210 performs a baseband signal and bit string conversion function according to the physical layer standard of the system. For example, during data transmission, the communication unit 210 generates complex symbols by encoding and modulating a transmission bit string. In addition, when receiving data, the communication unit 210 restores the received bit string by demodulating and decoding the baseband signal. In addition, the communication unit 210 up-converts the baseband signal into a radio frequency (RF) band signal and transmits it through an antenna, and downconverts the RF band signal received through the antenna into a baseband signal.
  • RF radio frequency
  • the communication unit 210 may include a transmission filter, a reception filter, an amplifier, a mixer, an oscillator, a digital to analog convertor (DAC), an analog to digital convertor (ADC), and the like.
  • the communication unit 210 may include a plurality of transmission and reception paths.
  • the communication unit 210 may include at least one antenna array composed of a plurality of antenna elements.
  • the communication unit 210 may be composed of a digital unit and an analog unit, and the analog unit may be divided into a plurality of sub-units according to operating power, operating frequency, and the like. Can be configured.
  • the communication unit 210 transmits and receives a signal as described above. Accordingly, the communication unit 210 may be referred to as a 'transmitter', 'receiver' or 'transceiver'. In addition, in the following description, transmission and reception performed through a wireless channel are used by the communication unit 210 to mean that the above-described processing is performed.
  • the storage unit 220 stores data such as a basic program, an application program, and setting information for the operation of the receiver.
  • the storage unit 220 may be configured as a volatile memory, a nonvolatile memory, or a combination of the volatile memory and the nonvolatile memory.
  • the storage 220 provides the stored data at the request of the controller 230.
  • the controller 230 controls overall operations of the receiver. For example, the controller 230 transmits and receives a signal through the communication unit 210. In addition, the controller 230 records and reads data in the storage 220. To this end, the controller 230 may include at least one processor or a micro processor, or may be part of a processor. In addition, a part of the communication unit 210 and the control unit 230 may be referred to as a communication processor (CP). In particular, the controller 230 determines an encryption parameter according to a decompression failure in the receiver 200 according to various embodiments described below. To this end, the controller 230 may include a parameter determiner 231.
  • the parameter determiner 231 is a command set or code stored in the storage 220, and is at least temporarily a resided command / code or a storage space storing the command / code, or constitutes the controller 230. It may be part of a circuit.
  • the controller 230 controls the receiver to perform a procedure according to various embodiments described below.
  • a voice call using a VoIP service between the terminal 110 and the base station 120 may be performed.
  • a voice call service of an LTE system headers of IP, user datagram protocol (UDP), and real time protocol (RTP) are compressed for each profile in order to save radio resources.
  • Robust header compression (RoHC) compression is used.
  • the RoHC compression scheme is performed in LTE packet data convergence protocol (PDCP) stack. Since the data in the wireless section is all encrypted, the decompression operation is performed after the decoding operation of PDCP.
  • PDCP packet data convergence protocol
  • the receiving end receiving the VoLTE voice packet among the terminal 110 or the base station 120 receives the encrypted data after being compressed through the RoHC technique.
  • the receiving end decodes the received compressed packet and then decompresses the decoded packet through the RoHC compression technique.
  • an uplink or downlink loss may occur due to a radio frequency (RF) environment problem.
  • RF radio frequency
  • a loss (128 seconds) of 128 RTPs is generated based on a 7-bit PDCP sequence number (SN)
  • a hyper frame number (HFN) used as one of key values for decryption between the terminal and the base station is used. Inconsistencies will occur.
  • the COUNT value used for decoding the received voice packet is composed of a combination of HFN and PDCP SN.
  • the PDCP SN is transmitted from the base station 120 to the terminal 110, and increases by one for each protocol data unit (PDU).
  • PDU protocol data unit
  • HFN is calculated at the base station 120 and the terminal 110, respectively. Specifically, when the PDCP SN reaches the maximum value, the next PDCP SN becomes zero and the HFN increases by one. At this time, when the HFN mismatch occurs, the COUNT value is mismatched, and thus, a 1-way phenomenon may occur due to a decryption failure at the receiver 200. This can eventually lead to a call break.
  • an HFN re-sync function called a count check is defined.
  • RRC radio resource control
  • a transmitting end compresses and transmits a packet according to an RoHC compression technique, and a receiving end decodes a received packet according to a RoHC compression technique. Can be applied to any system.
  • the RoHC algorithm used for packet compression and decompression may be performed as follows.
  • 3A and 3B illustrate a control process of a compressed state when using an RoHC method in a wireless communication system according to an embodiment.
  • 3A illustrates a state control process of a compressor when using the RoHC method in a wireless communication system according to various embodiments of the present disclosure.
  • the compression unit compresses a header of a packet encrypted by an RoHC technique.
  • the RoHC technique is similar to the video compression technique. That is, if there is a base frame, a frame indicating a difference from the base frame is transmitted thereafter. In this way, it is possible to maintain a high compression rate even if the packet loss rate is high unless the base frame is lost.
  • the compression unit is placed in one of three states: initialization & refresh (IR) state 310, first-order (FO) state 320, and second order (SO) state 330.
  • IR state 310 is that the compression section has just been created or reconfigured, in which the entire packet header is transmitted.
  • the compression section always starts at IR state 310, in which the compression section sends the entire uncompressed packet header so that the decompression section can establish a complete context.
  • FO state 320 the compression unit recognizes and stores static fields such as IP addresses and port numbers, and transmits dynamic packet field differences. That is, in FO state 320, the dynamic field is partially compressed while the static field is compressed.
  • SO state 330 the compressor compresses all dynamic fields, such as the RTP sequence number, and sends only a logical sequence number and some checksum for verifying the next packet.
  • FO state 320 all static fields and most dynamic fields are compressed.
  • SO state 330 all dynamic fields are compressed periodically using sequence numbers and checksums.
  • the compression unit and the decompression unit may maintain context synchronization through a feedback channel.
  • ACK acknowledgment
  • the compression unit is changed to FO state 320 or SO state 330.
  • the compression unit is changed to the SO state 330.
  • the compressor continues to maintain the SO state 330 which compresses all the static and dynamic fields.
  • NACK negative acknowledgment
  • the compression unit When receiving the STATIC-NACK feedback in the SO state 330, the compression unit transitions to the IR state 310 to transmit the entire uncompressed packet header. In addition, even when receiving a STATIC-NACK feedback in the FO state 320, the compression unit transitions to the IR state 310 to transmit the entire uncompressed packet header. When the transition to the IR state 310, the compression unit maintains the IR state 310 until receiving the ACK again.
  • 3B is a flowchart illustrating a state control process of a decompressor when using the RoHC method in a wireless communication system according to various embodiments of the present disclosure.
  • the decompressor receives a compressed packet.
  • the decompression unit is in one of three states.
  • the decompression unit starts decompression in the no context 360 at the beginning of the packet flow.
  • the decompressor may change the static context 370 to receive a difference between a static field such as an IP address and a port number and some dynamic packet fields.
  • the static field difference information is obtained, and the dynamic field difference information such as the RTP sequence number is received (full context) 380.
  • the same state 380 is maintained.
  • the NACK may be transmitted to the compression unit and may be changed to state 370. If the decompression failure continues even when attempting to recover the data, the compression unit may transmit a STATIC-NACK and change the state to 360. When the state transitions to 360, the decompressor receives the entire packet header in which the header is not compressed.
  • the decompression operation according to the RoHC compression scheme is performed after the decoding of the received packet.
  • decryption failure due to encryption parameter HFN mismatch cannot be detected in the PDCP stack until header decompression according to RoHC compression scheme. Therefore, in order to detect an inconsistency of the HFN and to determine the necessity of changing the HFN value, decompression according to the RoHC algorithm should be preceded after decoding using the HFN value.
  • a procedure of detecting an inconsistency of an encryption parameter and changing an encryption parameter value at a packet receiving side may be performed as shown in FIGS. 4 to 6.
  • the receiving end 200 may be a terminal 110 or a base station 120.
  • the receiving end receives a packet. That is, the receiving end receives the packet whose header is compressed after being encrypted from the transmitting end.
  • the transmitting end encrypts a packet to be transmitted to the receiving end using an encryption parameter. Thereafter, the transmitting end compresses the encrypted packet using the RoHC compression technique and transmits the encrypted packet to the receiving end, and the receiving end receives the compressed packet from the transmitting end.
  • the value of the encryption parameter can be static or change dynamically. For example, the value of the encryption parameter may change depending on the number of packets sent.
  • the receiving end decrypts the received packet using an encryption parameter. That is, the receiving end decrypts the received packet. If the encryption parameter value related to the key value used at this time is not synchronized, the receiving end cannot decrypt the data transmitted from the transmitting end normally. In other words, when the encryption parameter value is not a normal value, the decrypted data is different from the data included in the transmitted packet. According to an embodiment, the receiving end performs decryption using the same encryption parameter value as the transmitting end.
  • the receiving end detects a failure of header decompression of the decoded packet. That is, the receiving end decompresses the header portion of the decoded packet, and if decompression is abnormally detected, the decompressor detects a decompression failure.
  • the receiving end may decompress the header of the decoded packet through the RoHC algorithm, and detect the decompression failure.
  • the receiving end may determine whether the decompression is successful through a cyclical redundancy check (CRC) test.
  • CRC cyclical redundancy check
  • the receiving end adjusts the encryption parameter value. That is, the receiving end may change the encryption parameter value based on the detected decompression failure of the packet header in comparison with a predefined criterion.
  • the receiving end may detect that header decompression of the decoded packet has failed through the RoHC algorithm, and may feed back a NACK or STATIC-NACK to the transmitting end. When the receiving end feeds back STATIC-NACK, the transmitting end transmits the header uncompressed packet. If the decompression fails despite receiving the header uncompressed packet, the receiving end may determine the cause of the decompression failure as a failure of decryption due to an encryption parameter error and adjust the encryption parameter value. For example, the receiving end may increase the encryption parameter value.
  • the receiving end 200 may be a terminal 110 or a base station 120.
  • a receiving end receives a packet. That is, the receiving end receives the packet whose header is compressed after being encrypted from the transmitting end.
  • the receiving end may receive a voice packet encrypted in the PDCP stack and compressed by the RoHC algorithm from the transmitting end.
  • the receiving end performs decryption on the received packet using an encryption parameter. That is, in the case of VoLTE according to an embodiment, the receiving end receives the compressed voice packet and performs decoding using the HFN value.
  • step 505 the receiving end decompresses the decoded packet header. That is, in the case of VoLTE according to an embodiment, the receiving end decompresses the compressed header according to the RoHC algorithm.
  • step 507 the receiving end determines whether decompression of the decoded packet has failed. That is, as a result of decompression in step 501, the receiving end determines whether header decompression of the decoded packet was successful. According to an embodiment of the present disclosure, the receiving end may determine whether the decompression is successful through the CRC check.
  • step 509 the receiving end transmits an ACK message.
  • the receiving end decompresses the header of the packet through the RoHC algorithm, and feeds back an ACK message when the decompression succeeds.
  • the transmitter fed back with the ACK message, maintains the SO state 330, compresses up to dynamic data, and transmits the packet.
  • the receiving end determines whether the static field is valid according to the decompression failure. That is, the receiver determines whether the static field values such as the IP address and the port number are valid for the decompressed header.
  • the receiving end may determine whether the static field value is valid and determine the type of message to be fed back to the transmitting end.
  • step 513 the receiving end transmits a NACK message.
  • the receiver feeds back a NACK message to the transmitter.
  • the sender receiving the NACK message returns to FO state 320, compresses the static field and some dynamic fields, and the dynamic field such as the RTP sequence number receives an uncompressed packet. Will be sent.
  • step 515 the receiver sends a STATIC-NACK message. That is, if the decompression failure occurs because the dynamic field value does not match and the static field value is invalid in step 511, the receiver feeds back a STATIC-NACK to the transmitter in step 515. As described with reference to FIG. 3A, the transmitter, which has received the STATIC-NACK message, returns to IR state 310 and transmits a packet in which the header is not compressed.
  • the receiving end receives the packet of the header uncompressed state.
  • the transmitter that has received the STATIC-NACK transitions to the IR state 310 to transmit a packet without RoHC compression, and the receiver receives the packet without the RoHC compression.
  • the receiving end decodes the received packet. That is, in the case of VoLTE according to an embodiment, the received voice packet is decrypted using the HFN value which is an encryption key value.
  • the receiving end determines whether decompression of the decoded packet has failed. That is, the receiver determines whether decompression failure is detected even for a packet received after the STATIC-NACK transmission. According to an embodiment, after feeding back the STATIC-NACK, the receiving end receives the IR packet from the transmitting end, and the IR packet includes the entire header information since the packet is in a header uncompressed state. The receiving end may determine that the decompression failure is not obtained when the entire header information is not normally obtained from the received packet. According to an embodiment, the receiving end may determine whether the decompression is successful through the CRC check. As such, the receiving end may determine whether a decryption failure, that is, a decryption failure due to an HFN mismatch occurs, by determining a decompression failure of the received packet after transmitting the STATIC-NACK.
  • the receiver If decompression is successful, the receiver returns to step 509. That is, when the RoHC decompression failure is not detected, the receiving end feeds back an ACK message to the transmitting end.
  • the transmitter that has received the ACK message feedback transmits the header compressed packet by changing from the IR state 310 due to the STATIC-NACK reception to the FO state 320 or the SO state 330.
  • the receiving end increments the encryption parameter. That is, when the RoHC decompression failure is detected, the receiving end may adjust the encryption parameter value. In the case of VoLTE according to an embodiment, when a RoHC decompression failure is detected, the receiving end may determine that the decryption failure due to a mismatch of the HFN, which is an encryption key, and increase the HFN value. At this time, the HFN value may be increased by 1, or may be increased by 1 or more by an experimental value.
  • 6 illustrates a method for an operation of a receiving end after feedback transmission according to a decompression failure in a wireless communication system according to various embodiments of the present disclosure. 6 illustrates an operation method of the receiver 200.
  • the receiving end 200 may be a terminal 110 or a base station 120.
  • the receiver transmits STATIC-NACK through RoHC feedback. That is, the receiving end feeds back the STATIC-NACK to the transmitting end according to the RoHC decompression failure of the previously received packet.
  • the process of transmitting the STATIC-NACK may be performed as in steps 501 to 515 illustrated in FIG. 5. That is, the receiving end performs RoHC decompression after decryption using HFN, which is an encryption key value, on the previously received packet, and if the RoHC decompression failure is detected and the static field value is not valid, the receiving end feeds back a STATIC-NACK to the transmitting end. .
  • the receiving end decodes the received packet. That is, the receiver decodes the packet received after the STATIC-NACK transmission. In the case of VoLTE according to an embodiment, the receiving end decodes the PDCP packet using a COUNT value composed of a combination of HFN and PDCP SN.
  • step 605 the receiving end determines RoHC decompression of the decoded packet. That is, the receiver determines whether RoHC decompression failure of the decoded packet occurs.
  • the transmitter receives STATIC-NACK feedback
  • the transmitter transmits an IR packet.
  • the IR packet includes the entire packet header with the header uncompressed. If the decompression failure is detected after receiving the IR packet, the receiving end may determine that the decoding fails due to the HFN mismatch.
  • the receiving end resets the decompression failure count parameter. That is, when RoHC decompression succeeds, the parameter determination unit 231 resets the parameter regarding the number of decompression failures to zero.
  • the parameter determiner 231 may set the trycount parameter value regarding the number of times of decompression failure to zero.
  • step 609 the receiving end normally processes the RoHC decompressed packet and delivers the packet to the corresponding module.
  • the receiving end determines whether the decompression failure count parameter value is larger than the reference value, and increases the failure count parameter value by one. That is, when RoHC decompression fails, the parameter determiner 231 determines whether the decompression failure count parameter trycount value accumulated before is greater than the predefined reference value N, and increases the trycount value by one.
  • the predefined reference value N is an arbitrary value equal to or greater than 1, and may be determined experimentally in consideration of the in-flight packet received until the receiver receives the IR packet even after the receiver transmits the STATIC-NACK. According to another embodiment, the failure count parameter trycount may increase 1 before comparison with N.
  • the receiving end increases the encryption parameter value and resets the decompression failure count parameter value. That is, the parameter determiner 231 increases the encryption parameter value and resets the parameter number of times of decompression failure.
  • the receiving end determines that the RoHC decompression failure occurs a predetermined number of times due to HFN mismatch according to packet loss, increases the HFN value by 1, and resets the trycount value to 0.
  • the received packets are then decoded using the increased HFN value. For example, the receiver performs decoding of the received packet by applying the increased HFN value, and determines whether RoHC decompression is successful.
  • the receiver may maintain the changed HFN value and determine the HFN value according to a conventional HFN calculation algorithm. According to an embodiment, when RoHC decompression succeeds, the receiving end may feed back an ACK message to the transmitting end. According to other embodiments, if RoHC decompression failure is detected even using the increased HFN value, the process of adjusting the HFN value may be repeated by comparing the decompression failure count with a predefined reference value.
  • step 615 the receiving end drops the packet. In other words, when the decompression failure count parameter value is less than or equal to the reference value, the receiving end may discard the packet.
  • a computer-readable storage medium for storing one or more programs (software modules) may be provided.
  • One or more programs stored in a computer readable storage medium are configured for execution by one or more processors in an electronic device.
  • One or more programs include instructions that cause an electronic device to execute methods in accordance with embodiments described in the claims or specifications of this disclosure.
  • Such programs include random access memory, non-volatile memory including flash memory, Read Only Memory (ROM), and electrically erasable programmable ROM.
  • ROM Read Only Memory
  • EEPROM Electrically Erasable Programmable Read Only Memory
  • magnetic disc storage device compact disc ROM (CD-ROM), digital versatile discs (DVDs) or other forms
  • CD-ROM compact disc ROM
  • DVDs digital versatile discs
  • It can be stored in an optical storage device, a magnetic cassette. Or, it may be stored in a memory composed of some or all of these combinations.
  • each configuration memory may be included in plural.
  • the program is accessed through a communication network consisting of a communication network such as the Internet, an intranet, a local area network (LAN), a wide area network (WLAN), or a storage area network (SAN), or a combination thereof. It may be stored in an attachable storage device that is accessible. Such a storage device may be connected to a device that performs an embodiment of the present disclosure through an external port. In addition, a separate storage device on a communication network may be connected to a device that performs an embodiment of the present disclosure.
  • a communication network such as the Internet, an intranet, a local area network (LAN), a wide area network (WLAN), or a storage area network (SAN), or a combination thereof. It may be stored in an attachable storage device that is accessible. Such a storage device may be connected to a device that performs an embodiment of the present disclosure through an external port. In addition, a separate storage device on a communication network may be connected to a device that performs an embodiment of the present disclosure.

Landscapes

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

Abstract

본 개시(disclosure)는 일반적으로 무선 통신 시스템에서 데이터 복호화 실패를 방지하기 위한 것으로, 수신단의 동작 방법은, 송신단으로부터 패킷을 수신하는 과정과, 상기 수신된 패킷에 대해 암호화 파라미터를 이용하여 복호화를 수행하는 과정과, 상기 복호화된 패킷 헤더의 압축 해제에 대한 실패를 감지하는 과정과, 상기 압축 해제에 대한 실패를 감지함에 따라, 상기 암호화 파라미터의 값을 조정하는 과정을 포함한다.

Description

무선 통신 시스템에서 암호화 파라미터 값을 결정하기 위한 장치 및 방법
본 개시(disclosure)는 일반적으로 무선 통신 시스템에 관한 것으로, 보다 구체적으로 무선 통신 시스템에서 데이터 복호화 실패를 방지하기 위한 장치 및 방법에 관한 것이다.
과거 이동 통신 시스템에서의 전화 서비스는 일반 전화 교환망(PSTN: publicswitched telephone network)을 통해 제공되었다. 그러나, 최근 통신 기술의 발달로 인해, 광대역의 이동 데이터 통신 서비스가 가능해졌고, 이에 따라, 데이터 통신에 기반한 인터넷(internet) 전화, 즉, VoIP(voice over internet protocol) 서비스가 제공되고 있다. 따라서, 사용자는 IP(internet protocol) 연결(connectivity)을 제공하는 접속 망(access network)을 통해 VoIP 통화를 이용할 수 있다.
현재 4세대 이동통신 시스템인 LTE(long term evolution) 시스템 역시 VoIP 서비스를 지원한다. LTE 시스템을 통해 제공되는 VoIP 서비스는 'VoLTE(voice over LTE)'라 지칭되기도 한다. VoLTE를 통한 음성통화는 무선 자원을 절약하기 위해 IP, UDP(user datagram protocol, RTP(real-time transport protocol)의 헤더(header)를 압축하는 기술인 RoHC(robust header compression)를 사용하고 있다. 단말과 기지국은 헤더가 압축된 패킷을 서로에게 전송하고, 수신한 압축 패킷을 압축 해제(decompress)하여 복원시킴으로써, 무선 구간을 지나는 데이터 양을 크게 줄일 수 있다.
상술한 바와 같은 논의를 바탕으로, 본 개시(disclosure)는, 무선 통신 시스템에서 데이터의 암호화 파라미터를 결정하기 위한 장치 및 방법을 제공한다.
또한, 본 개시는, 무선 통신 시스템에서 수신된 데이터 복호화 실패를 방지하기 위한 장치 및 방법을 제공한다.
또한, 본 개시는, 무선 통신 시스템에서 수신된 데이터 복호화 실패를 방지하기 위해 암호화 파라미터를 조정하기 위한 장치 및 방법을 제공한다.
또한, 본 개시는, 무선 통신 시스템에서 무선 환경에 의해 데이터 손실(loss)이 발생하는 경우 암호화 파라미터 불일치를 방지하기 위한 장치 및 방법을 제공한다.
또한, 본 개시는, 무선 통신 시스템에서 복호화 키(key) 값의 하나인 HFN(hyper frame number)의 불일치에 의한 음성 호 절단을 방지하기 위한 장치 및 방법을 제공한다.
본 개시의 다양한 실시 예들에 따르면, 무선 통신 시스템에서 수신단의 동작 방법은, 송신단으로부터 패킷을 수신하는 과정과, 상기 수신된 패킷에 대해 암호화 파라미터를 이용하여 복호화를 수행하는 과정과, 상기 복호화된 패킷 헤더의 압축 해제에 대한 실패를 감지하는 과정과, 상기 압축 해제에 대한 실패를 감지함에 따라, 상기 암호화 파라미터의 값을 조정하는 과정을 포함한다.
본 개시의 다양한 실시 예들에 따르면, 무선 통신 시스템에서 수신단 장치는, 송신단으로부터 패킷을 수신하는 송수신부와, 상기 수신된 패킷에 대해 암호화 파라미터를 이용하여 복호화를 수행하고, 상기 복호화된 패킷 헤더의 압축 해제에 대한 실패를 감지하고, 상기 압축 해제에 대한 실패를 감지함에 따라, 상기 암호화 파라미터의 값을 조정하는 제어부를 포함한다.
본 개시의 다양한 실시 예들에 따른 장치 및 방법은, 무선 환경에 의해 패킷 손실(loss)이 발생하는 경우, 암호화 파라미터의 불일치를 감지하고 자동 보정함으로써, 복호화 실패를 방지할 수 있다. 이를 통해, 음성 호의 1-way 현상을 방지하고, 음성 호의 단절을 방지할 수 있게 한다.
본 개시에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 개시가 속하는 기술 분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
도 1은 본 개시의 다양한 실시 예들에 따른 무선 통신 시스템을 도시한다.
도 2는 본 개시의 다양한 실시 예들에 따른 무선 통신 시스템에서 수신단의 블록 구성을 도시한다.
도 3a는 본 개시의 다양한 실시 예들에 따른 무선 통신 시스템에서 RoHC(robust header compression) 방식을 사용하는 경우 압축부(compressor)의 상태 제어 과정을 도시한다.
도 3b는 본 개시의 다양한 실시 예들에 따른 무선 통신 시스템에서 RoHC 방식을 사용하는 경우 압축 해제부(decompressor)의 상태 제어 과정을 도시한다.
도 4는 본 개시의 다양한 실시 예들에 따른 무선 통신 시스템에서 수신단의 동작 방법을 도시한다.
도 5는 본 개시의 다양한 실시 예들에 따른 무선 통신 시스템에서 RoHC 압축 해제를 통한 수신단의 동작을 위한 방법을 도시한다.
도 6은 본 개시의 다양한 실시 예들에 따른 무선 통신 시스템에서 압축 해제 실패에 따른 피드백 전송 후 수신단의 동작 방법을 도시한다.
본 개시에서 사용되는 용어들은 단지 특정한 실시 예를 설명하기 위해 사용된 것으로, 다른 실시 예의 범위를 한정하려는 의도가 아닐 수 있다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함할 수 있다. 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 용어들은 본 개시에 기재된 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가질 수 있다. 본 개시에 사용된 용어들 중 일반적인 사전에 정의된 용어들은, 관련 기술의 문맥상 가지는 의미와 동일 또는 유사한 의미로 해석될 수 있으며, 본 개시에서 명백하게 정의되지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다. 경우에 따라서, 본 개시에서 정의된 용어일지라도 본 개시의 실시 예들을 배제하도록 해석될 수 없다.
이하에서 설명되는 본 개시의 다양한 실시 예들에서는 하드웨어적인 접근 방법을 예시로서 설명한다. 하지만, 본 개시의 다양한 실시 예들에서는 하드웨어와 소프트웨어를 모두 사용하는 기술을 포함하고 있으므로, 본 개시의 다양한 실시 예들이 소프트웨어 기반의 접근 방법을 제외하는 것은 아니다.
이하 본 개시는 무선 통신 시스템에서 데이터의 암호화 파라미터를 결정하기 위한 장치 및 방법에 관한 것이다. 구체적으로, 본 개시는 무선 통신 시스템에서 무선 환경에 의해 패킷 손실(loss)이 발생하는 경우 암호화 파라미터 불일치(de-synchronization)를 방지하기 위한 기술을 설명한다.
이하 설명에서 사용되는 네트워크 객체(network entity)들을 지칭하는 용어, 제어 정보를 지칭하는 용어(예: HFN, PDCP SN 등), 장치의 구성 요소를 지칭하는 용어, 통신 기술을 지칭하는 용어 등은 설명의 편의를 위해 예시된 것이다. 따라서, 본 개시가 후술되는 용어들에 한정되는 것은 아니며, 동등한 기술적 의미를 가지는 다른 용어가 사용될 수 있다.
또한, 본 개시는, LTE(long term evolution) 시스템과 LTE-A(LTE-advanced) 시스템을 이용하여 다양한 실시 예들을 설명하지만, 이는 설명을 위한 예시일 뿐이다. 본 개시의 다양한 실시 예들은, 다른 통신 시스템에서도, 용이하게 변형되어 적용될 수 있다.
도 1은 본 개시의 다양한 실시 예들에 따른 무선 통신 시스템을 도시한다. 도 1을 참고하면, 시스템은 단말 110, 기지국 120을 포함하는 접속 망(access network) 130, IMS(IP multimediasubsystem)140을 포함한다.
단말 110은 사용자 장치로서, 기지국 120과 무선 채널을 통해 통신을 수행한다. 단말 110은 VoIP(voice over internet protocol) 기능을 제공하며, 사용자의 명령에 따라 VoIP 서비스를 위한 어플리케이션을 실행한다. 이에 따라, 단말 110은 기지국 120과 VoIP 서비스를 위한 음성 패킷을 송신 및 수신할 수 있다. 다양한 실시 예들에서, 단말 110은 휴대용 전자 장치(portable electronic device)일 수 있으며, 스마트폰(smart phone), 휴대용 단말기(portable terminal), 이동 전화(mobile phone), 이동 패드(mobile pad), 미디어 플레이어(media player), 태블릿 컴퓨터(tablet computer), 핸드헬드 컴퓨터(handheld computer) 또는 PDA(personal digital assistant) 중 하나일 수 있다. 다른 실시 예들에서, 단말 110은 고정된(stationary) 장치일 수 있다. 또한, 단말 110은 상술한 장치들 중 둘 이상의 기능들을 결합한 장치일 수 있다.
기지국 120은 단말 110에게 무선 접속을 제공한다. 기지국 120은 접속 망 130을 구성하는 객체(entity)들 중 하나로서, 일정 지리적 범위를 포함하는 커버리지(coverage)를 가진다. 기지국 120은 기지국(base station) 외에 '액세스 포인트(access point, AP)', '이노드비 (evolved nodeB, eNB), '5G 노드(5th generation node)', '무선 포인트(wireless point)', '송수신 포인트(transmission/reception point, TRP) 또는 이와 동등한 기술적 의미를 가지는 다른 용어로 지칭될 수 있다.
단말 110과 기지국 120은 후술하는 다양한 실시 예들에서 각각 송신단 또는 수신단일 수 있다. 즉, 단말 110이 기지국 120으로부터 데이터를 수신하는 경우, 단말 110이 수신단이고 기지국 120이 송신단이 된다. 반대로, 단말 110이 기지국 120으로 데이터를 송신하는 경우, 단말 110이 송신단이고 기지국 120이 수신단이 된다. 따라서, 본 개시의 다양한 실시 예들에서 송신단은 단말 110 또는 기지국 120일 수 있고, 이 경우 수신단은 각각 기지국 120 또는 단말 110이 될 수 있다.
접속 망 130은 단말 110을 외부 망(예: IP(internet protocol) 망)으로 연결하기 위한 시스템으로, 기지국 120은 물론, 게이트웨이(gateway), MME(mobility management entity) 등의 다른 객체를 더 포함할 수 있다.
IMS 140은 세션을 관리하는 서브시스템(subsystem)이다. IMS 140은 접속 망 130과 독립적으로 운용될 수 있다. IMS 140은 IP를 기반으로, 음성, 오디오, 비디오, 데이터 등의 멀티미디어(multimedia) 서비스를 제공할 수 있다. 단말 110이 상대방과 VoIP 서비스를 통해 음성 통화를 수행하는 경우, 음성 패킷은 IMS 140을 거쳐 송수신된다. 일 실시 예에 따라, 단말 110이 LTE망을 통해 VoLTE(voice over LTE) 음성 통화를 제공 받는 경우, 음성 패킷은 IMS 140을 거쳐 송수신 된다. IMS 140은 P-CSCF(proxy-call session control function),S-CSCF(serving-call session control function),I-CSCF(interrogating-call session control function), PCRF, HSS(home subscriberserver) 등을 포함할 수 있다.
도 2는 본 개시의 다양한 실시 예들에 따른 무선 통신 시스템에서 수신단 200의 블록 구성을 도시한다. 도 2는 단말 110 또는 기지국 120의 구성으로 이해될 수 있다. 이하 사용되는 '...부', '...기' 등의 용어는 적어도 하나의 기능이나 동작을 처리하는 단위를 의미하며, 이는 하드웨어나 소프트웨어, 또는, 하드웨어 및 소프트웨어의 결합으로 구현될 수 있다. 도 2에 도시된 바와 같이, 수신단은 통신부 210, 저장부 220, 제어부 230을 포함한다.
통신부 210은 무선 채널을 통해 신호를 송수신하기 위한 기능들을 수행한다. 예를 들어, 통신부 210은 시스템의 물리 계층 규격에 따라 기저대역 신호 및 비트열 간 변환 기능을 수행한다. 예를 들어, 데이터 송신 시, 통신부 210은 송신 비트열을 부호화 및 변조함으로써 복소 심벌들을 생성한다. 또한, 데이터 수신 시, 통신부 210은 기저대역 신호를 복조 및 복호화를 통해 수신 비트열을 복원한다. 또한, 통신부 210은 기저대역 신호를 RF(radio frequency) 대역 신호로 상향변환한 후 안테나를 통해 송신하고, 안테나를 통해 수신되는 RF 대역 신호를 기저대역 신호로 하향변환한다.
이를 위해, 통신부 210은 송신 필터, 수신 필터, 증폭기, 믹서(mixer), 오실레이터(oscillator), DAC(digital to analog convertor), ADC(analog to digital convertor) 등을 포함할 수 있다. 또한, 통신부 210은 다수의 송수신 경로(path)들을 포함할 수 있다. 나아가, 통신부 210은 다수의 안테나 요소들(antenna elements)로 구성된 적어도 하나의 안테나 어레이(antenna array)를 포함할 수 있다. 하드웨어의 측면에서, 통신부(210)는 디지털 유닛(digital unit) 및 아날로그 유닛(analog unit)으로 구성될 수 있으며, 아날로그 유닛은 동작 전력, 동작 주파수 등에 따라 다수의 서브 유닛(sub-unit)들로 구성될 수 있다.
통신부 210은 상술한 바와 같이 신호를 송신 및 수신한다. 이에 따라, 통신부 210은 '송신부', '수신부' 또는 '송수신부'로 지칭될 수 있다. 또한, 이하 설명에서 무선 채널을 통해 수행되는 송신 및 수신은 통신부 210에 의해 상술한 바와 같은 처리가 수행되는 것을 포함하는 의미로 사용된다.
저장부 220은 수신단의 동작을 위한 기본 프로그램, 응용 프로그램, 설정 정보 등의 데이터를 저장한다. 저장부 220은 휘발성 메모리, 비휘발성 메모리 또는 휘발성 메모리와 비휘발성 메모리의 조합으로 구성될 수 있다. 그리고, 저장부 220은 제어부 230의 요청에 따라 저장된 데이터를 제공한다.
제어부 230은 수신단의 전반적인 동작들을 제어한다. 예를 들어, 제어부 230은 통신부 210을 통해 신호를 송신 및 수신한다. 또한, 제어부 230은 저장부 220에 데이터를 기록하고, 읽는다. 이를 위해, 제어부 230은 적어도 하나의 프로세서(processor) 또는 마이크로(micro) 프로세서를 포함하거나, 또는, 프로세서의 일부일 수 있다. 또한, 통신부 210의 일부 및 제어부 230은 CP(communication processor)라 지칭될 수 있다. 특히, 제어부 230은 후술되는 다양한 실시 예들에 따라 수신단 200에서 압축 해제(decompression) 실패에 따라 암호화 파라미터를 결정한다. 이를 위해, 제어부 230은 파라미터 결정부 231을 포함할 수 있다. 여기서, 파라미터 결정부 231은 저장부 220에 저장된 명령어 집합 또는 코드로서, 적어도 일시적으로 제어부 230에 상주된(resided) 명령어/코드 또는 명령어/코드를 저장한 저장 공간이거나, 또는, 제어부 230을 구성하는 회로(circuitry)의 일부일 수 있다. 예를 들어, 상기 제어부 230은 수신단이 후술하는 다양한 실시 예들에 따르는 절차를 수행하도록 제어한다.
본 개시의 다양한 실시 예들에 따라, 단말 110과 기지국 120간 VoIP 서비스를 이용한 음성 통화가 진행될 수 있다. 일 실시 예에 따라, LTE 시스템의 음성 통화 서비스인 VoLTE의 경우, 무선 자원을 절약하기 위해 프로파일(profile)별로 IP, UDP(user datagram protocol), RTP(real time protocol)의 헤더(header)를 압축하는 기술인 RoHC(robust header compression) 압축 기법을 사용하게 된다. RoHC 압축 기법의 동작은 LTE의 PDCP(packet data convergence protocol) 스택(stack) 안에서 이루어지며 무선 구간의 데이터는 모두 암호화되어 있기 때문에 압축 해제 동작은 PDCP의 복호화(deciphering) 동작 이후에 이루어진다.
일 실시 예에 따라, 단말 110 또는 기지국 120 중 VoLTE 음성 패킷을 수신하는 수신단은 RoHC 기법을 통해 압축된 후 암호화된 데이터를 수신한다. 수신단은 수신된 압축 패킷을 복호화한 후, 복호화된 패킷을 RoHC 압축 기법을 통해 압축 해제한다. 이때, 무선 RF(radio frequency) 환경 문제로 인해 상향링크 또는 하향링크 손실(loss)이 발생할 수 있다. 일 실시 예에 따라, 7비트 PDCP SN(sequence number)기준으로 128개 RTP의 손실(약 2초)이 발생하면 단말과 기지국 사이에 복호화를 위한 키 값 중 하나로 사용되는 HFN(hyper frame number)의 불일치가 발생하게 된다. LTE 규격에 따르면, 수신된 음성 패킷의 복호화에 사용되는 COUNT 값은 HFN과 PDCP SN의 조합으로 구성되어 있다. 하향링크의 경우, PDCP SN은 기지국 120에서 단말 110으로 전송되며, PDU(protocol data unit)마다 1씩 증가한다. HFN은 기지국 120과 단말 110에서 각각 계산된다. 구체적으로, PDCP SN이 최대 값에 도달하는 경우 다음 PDCP SN은 0이 되고, HFN은 1 증가한다. 이때, HFN 불일치가 발생하게 되면, COUNT 값이 불일치하게 되고, 이에 따라, 수신단 200에서 복호화 실패에 의한 1-way현상이 발생할 수 있다. 이것은 결국 호 단절로 이어질 수 있다.
현재의 LTE 규격에서는 카운트 체크(count check)라는 HFN 재-동기화(re-sync) 기능이 정의되어 있다. 하지만, 추가적인 RRC(radio resource control) 설정을 위한 시그널링(signaling)이 필요하고, 추가 지연이 발생할 수 있기 때문에, 실시간성의 VoLTE 환경에는 적합하지 않다.
본 개시는 이러한 VoIP서비스 환경이나, LTE 환경에만 제한 되는 것은 아니다. 다른 실시 예들에 따라, 본 개시에서 제안하는 암호화 파라미터의 동기화를 위한 방법은, 송신단이 패킷을 암호화 후 RoHC 압축 기법에 따라 압축 전송하고, 수신단이 수신된 패킷을 복호화 후 RoHC 압축 기법에 따라 압축 해제하는 모든 시스템에 적용될 수 있다.
본 개시의 일 실시 예에 따라, 패킷 압축 및 압축 해제에 이용되는 RoHC 알고리즘은 다음과 같이 수행될 수 있다. 도 3a 및 도 3b는 일 실시 예에 따른 무선 통신 시스템에서 RoHC 방식을 사용하는 경우 압축 상태의 제어 과정을 도시한다.
도 3a는 본 개시의 다양한 실시 예들에 따른 무선 통신 시스템에서 RoHC 방식을 사용하는 경우 압축부(compressor)의 상태 제어 과정을 도시한다.
도 3a를 참고하면, 일 실시 예에 따라, 압축부는 RoHC 기법에 의해 암호화된 패킷의 헤더를 압축한다. RoHC 기법은 비디오 압축 기법과 유사하다. 즉, 베이스 프레임(base frame)이 있으면 그 이후로는 베이스 프레임과의 차이점을 표시한 프레임을 전송한다. 이런 방법을 통해, 베이스 프레임이 손실되지 않는 한 패킷 유실율이 높은 경우에도 높은 압축율을 유지할 수 있게 된다. 압축부는 IR(initialization & refresh) 상태 310, FO(first-order) 상태 320 및 SO(second order) 상태 330의 세가지 상태 중 하나에 놓이게 된다. IR 상태 310은 압축부가 방금 생성되거나 재설정된 상태로, 이 상태에서는 전체 패킷 헤더가 전송된다. 압축부는 언제나 IR 상태 310에서 시작하게 되며, 이 상태에서 압축부는 압축 해제부에서 완전한 컨텍스트(context)를 확립할 수 있도록 압축되지 않은 전체 패킷 헤더를 전송한다. FO 상태 320에서 압축부는 IP 주소, 포트 번호와 같은 정적인 필드를 인식하고 저장하며, 동적인 패킷 필드 차이를 전송한다. 즉, FO 상태 320은 정적 필드가 압축 되면서 부분적으로 동적 필드도 압축된 상태이다. SO 상태 330에서 압축부는 RTP 시퀀스 번호와 같은 모든 동적 필드를 압축하고, 단지 논리적인 시퀀스 번호와 다음 패킷을 검증하기 위한 일부 체크섬(checksum)만을 전송한다. 일반적으로 FO 상태 320에서는 모든 정적 필드와 대부분의 동적 필드가 압축되고, SO 상태 330에서는 시퀀스 번호와 체크섬을 사용하여 주기적으로 모든 동적 필드를 압축한다.
압축부가 O-모드(bidirectional optimistic mode)인 경우, 피드백 채널을 통해 압축부와 압축 해제부는 컨텍스트 동기화를 유지할 수 있다. 도 3a를 참고하면, IR 상태 310에서 ACK(acknowledgement)를 피드백받는 경우 압축부는 FO 상태 320 또는 SO 상태 330으로 변경된다. FO 상태 320에서 ACK를 피드백받는 경우 압축부는 SO 상태 330으로 변경된다. SO 상태 330에서 ACK를 피드백받는 경우 압축부는 계속해서 모든 정적 필드와 동적 필드를 압축하는 SO 상태 330을 유지하게 된다. 반면, SO 상태 330에서 NACK(negative acknowledgement)를 피드백받는 경우 압축부는 FO 상태 320으로 천이하여 정적 필드와 일부 동적 필드만을 압축하게 된다. SO 상태 330에서 STATIC-NACK을 피드백받는 경우 압축부는 IR 상태 310으로 천이하여 압축되지 않은 전체 패킷 헤더를 전송하게 된다. 또한, FO 상태 320에서 STATIC-NACK을 피드백받는 경우에도 압축부는 IR 상태 310으로 천이하여 압축되지 않은 전체 패킷 헤더를 전송하게 된다. IR 상태 310으로 천이된 경우 압축부는 다시 ACK를 수신하기 전까지 IR 상태 310을 유지한다.
도 3b는 본 개시의 다양한 실시 예들에 따른 무선 통신 시스템에서 RoHC 방식을 사용하는 경우 압축 해제부(decompressor)의 상태 제어 과정을 도시한다.
도 3b를 참고하면, 압축 해제부는 압축된 패킷을 수신한다. 압축 해제부는 세가지 상태 중 하나에 놓이게 된다. 압축 해제부는 패킷 흐름의 시작 지점에서 내용 정보가 없는 상태(no context) 360에서 압축 해제를 시작한다. 압축 해제부가 IR 패킷을 수신하여 전체 패킷 헤더 정보를 획득한 경우, IP 주소, 포트 번호와 같은 정적인 필드와 일부 동적인 패킷 필드의 차이를 전송 받는 상태(static context) 370으로 변경될 수 있다. 또는, 정적인 필드의 차이 정보까지 획득된 상태로, RTP 시퀀스 번호와 같은 동적 필드의 차이 정보를 수신 받는 상태(full context) 380에 놓이게 된다. 이때, 계속해서 압축 해제에 성공하면 동일한 상태 380을 유지하게 된다. 반면, 반복되는 압축 해제 실패가 발생하면 압축부로 NACK을 전송하고 상태 370으로 변경 될 수 있다. 데이터 복구 시도에도 계속된 압축 해제 실패가 발생하는 경우 압축부로 STATIC-NACK을 전송하고 상태 360으로 변경될 수 있다. 상태 360으로 천이하게 되면, 압축 해제부는 헤더가 압축되지 않은 전체 패킷 헤더를 수신하게 된다.
상술한 바와 같이, 단말 110과 기지국 120간 송수신되는 무선 구간의 데이터는 모두 암호화되어 있기 때문에, 수신된 패킷의 복호화 후 RoHC 압축 기법에 따른 압축 해제 동작이 이루어지게 된다. 일 실시 예에 따른 VoLTE의 경우, RoHC 압축 기법에 따른 헤더 압축 해제 이전까지는 암호화 파라미터 HFN 불일치로 인한 복호화 실패가 PDCP 스택에서 감지될 수 없다. 따라서, HFN의 불일치를 감지하고, HFN 값 변경의 필요성을 판단하기 위해서는, HFN 값을 이용한 복호화 후 RoHC 알고리즘에 따른 압축 해제가 선행되어야 한다.
본 개시의 다양한 실시 예들에 따라, 패킷을 수신하는 측에서 암호화 파라미터의 불일치를 감지하고, 암호화 파라미터 값을 변경하는 절차는 도 4 내지 도 6과 같이 수행될 수 있다.
도 4는 본 개시의 다양한 실시 예들에 따른 무선 통신 시스템에서 수신단의 동작을 위한 방법을 도시한다. 도 4는 수신단 200의 동작 방법을 예시한다. 수신단 200은 단말 110 또는 기지국 120일 수 있다.
도 4를 참고하면, 401 단계에서, 수신단은 패킷을 수신한다. 즉, 수신단은 송신단으로부터 암호화 된 후 헤더가 압축된 패킷을 수신한다. 일 실시 예에 따라, 송신단은 수신단으로 전송할 패킷을 암호화 파라미터를 이용하여 암호화한다. 이후, 송신단은 암호화된 패킷을 RoHC 압축 기법에 의해 압축하여 수신단으로 전송하고, 수신단은 송신단으로부터 압축된 패킷을 수신한다. 여기서, 암호화 파라미터의 값은 정적이거나 또는 동적으로 변화할 수 있다. 예를 들어, 암호화 파라미터의 값은 송신된 패킷의 개수에 따라 변화할 수 있다.
이후, 403 단계에서, 수신단은 수신된 패킷에 대해 암호화 파라미터를 이용하여 복호화를 수행한다. 즉, 수신단은 수신된 패킷에 대해 복호화를 수행하며, 이 때 사용되는 키 값에 관련된 암호화 파라미터 값이 동기화되지 아니한 경우, 수신단은 송신단에서 전송한 데이터를 정상적으로 복호화할 수 없다. 다시 말해, 암호화 파라미터 값이 정상적인 값이 아닌 경우, 복호화된 데이터는 전송된 패킷에 포함된 데이터와 차이가 생기게 된다. 일 실시 예에 따라, 수신단은 송신단과 동일한 암호화 파라미터 값을 이용하여 복호화를 수행한다.
405 단계에서, 수신단은 복호화된 패킷의 헤더 압축 해제에 대한 실패를 감지한다. 즉, 수신단은 복호화된 패킷의 헤더 부분을 압축 해제 하고, 압축 해제가 비정상적으로 이루어진 경우, 압축 해제 실패를 감지한다. 일 실시 예에 따라, 수신단은 RoHC 알고리즘을 통하여 복호화된 패킷의 헤더 압축 해제를 수행하고, 압축 해제 실패를 감지할 수 있다. 일 실시 예에 따라, 수신단은 CRC(cyclical redundancy check) 검사를 통해 압축 해제 성공 여부를 판단할 수 있다. 압축 해제 실패를 감지하는 경우, 도 3에 도시된 바와 같이, 압축 해제부의 상태는 변경되고, 압축부로 NACK 또는 STATIC-NACK을 피드백할 수 있다.
407단계에서, 수신단은 암호화 파라미터 값을 조정한다. 즉, 수신단은 감지된 패킷 헤더의 압축 해제 실패에 기초하여, 미리 정의된 기준과 비교하여 암호화 파라미터 값을 변경할 수 있다. 일 실시 예에 따라, 수신단은 RoHC 알고리즘을 통하여 복호화된 패킷의 헤더 압축 해제가 실패한 것을 감지하고 NACK 또는 STATIC-NACK을 송신단으로 피드백할 수 있다. 수신단이 STATIC-NACK을 피드백하는 경우, 송신단은 헤더 압축되지 않은 패킷을 전송하게 된다. 헤더 압축되지 않은 패킷을 수신하였음에도 불구하고 압축 해제가 실패되는 경우, 수신단은 압축 해제의 실패 원인을 암호화 파라미터 오류로 인한 복호화의 실패로 판단하고, 암호화 파라미터 값을 조정할 수 있다. 예를 들어, 수신단은 암호화 파라미터 값을 증가 시킬 수 있다.
도 5는 본 개시의 다양한 실시 예들에 따른 무선 통신 시스템에서 RoHC 압축 해제를 통한 수신단의 동작을 위한 방법을 도시한다. 도 5는 수신단 200의 동작 방법을 예시한다. 수신단 200은 단말 110 또는 기지국 120일 수 있다.
도 5를 참고하면, 501 단계에서, 수신단은 패킷을 수신한다. 즉, 수신단은 송신단으로부터 암호화 된 후 헤더가 압축된 패킷을 수신한다. 일 실시 예에 따른 VoLTE의 경우, 수신단은 PDCP 스택에서 암호화되고 RoHC 알고리즘에 의해 헤더가 압축된 음성 패킷을 송신단으로부터 수신할 수 있다.
이후, 503 단계에서, 수신단은 수신된 패킷에 대해 암호화 파라미터를 이용하여 복호화를 수행한다. 즉, 일 실시 예에 따른 VoLTE의 경우, 수신단은 압축된 음성 패킷을 수신하고, HFN 값을 이용하여 복호화를 수행한다.
505 단계에서, 수신단은 복호화된 패킷 헤더의 압축 해제를 수행한다. 즉, 일 실시 예에 따른 VoLTE의 경우, 수신단은 RoHC 알고리즘에 따라 압축된 헤더의 압축 해제를 수행한다.
507 단계에서, 수신단은 복호화된 패킷의 압축 해제의 실패 여부를 판단한다. 즉, 수신단은 501 단계에서의 압축 해제 수행 결과, 복호화된 패킷의 헤더 압축 해제가 성공하였는지 판단한다. 일 실시 예에 따라, 수신단은 CRC 검사를 통해 압축 해제 성공 여부를 판단할 수 있다.
압축 해제가 성공한 경우, 509 단계에서, 수신단은 ACK메시지를 전송한다. 일 실시 예에 따라, 수신단은 RoHC 알고리즘을 통하여 패킷의 헤더 압축 해제를 수행하고, 압축 해제에 성공한 경우 ACK 메시지를 피드백한다. 도 3a에서 상술한 바와 같이, ACK 메시지를 피드백받은 송신단은 SO 상태 330을 유지하고, 동적인 데이터까지 압축하여 패킷을 전송한다.
압축 해제가 실패한 경우, 511 단계에서, 수신단은 압축 해제 실패에 따라 정적(static) 필드가 유효한지 판단한다. 즉, 수신단은 압축 해제된 헤더에 대해 IP 주소, 포트 번호와 같은 정적인 필드 값의 유효 여부를 판단한다. 일 실시 예에 따라, 기지국과 단말 간 무선 환경의 문제로 패킷 유실이 발생하는 경우 수신단에서는 연속적인 RoHC 압축 해제 실패가 발생하게 된다. 이 경우, 수신단은 정적인 필드 값의 유효 여부를 판단하여 송신단으로 피드백할 메시지의 종류를 결정할 수 있다.
정적인 필드 값이 유효한 경우, 513 단계에서, 수신단은 NACK 메시지를 전송한다. 즉, 앞선 511 단계에서 정적인 필드 값은 유효하고 동적인 필드 값이 불일치하여 압축 해제 실패가 된 경우, 513 단계에서 수신단은 송신단으로 NACK 메시지를 피드백한다. 도 3a를 참고하여 설명한 바와 같이, NACK 메시지를 피드백받은 송신단은 FO 상태 320로 천이하고, 정적인 필드와 일부 동적인 필드를 압축하고, RTP 시퀀스 번호와 같은 동적 필드는 압축되지 않은 상태의 패킷을 전송하게 된다.
정적인 필드 값이 유효하지 않은 경우, 515 단계에서, 수신단은 STATIC-NACK 메시지를 전송한다. 즉, 앞선 511 단계에서 동적인 필드 값이 불일치하고 정적인 필드 값도 유효하지 않아 압축 해제 실패가 된 경우, 515 단계에서 수신단은 송신단으로 STATIC-NACK을 피드백한다. 도 3a를 참고하여 설명한 바와 같이, STATIC-NACK 메시지를 피드백받은 송신단은 IR 상태 310으로 천이하고, 헤더가 압축되지 않은 상태의 패킷을 전송하게 된다.
이후, 517 단계에서, 수신단은 헤더 압축되지 않은 상태의 패킷을 수신한다. 일 실시 예에 따라, STATIC-NACK을 피드백받은 송신단이 IR 상태 310으로 천이함으로써 RoHC 압축이 되지 않은 패킷을 전송하게 되고, 수신단은 이와 같은 RoHC 압축 되지 않은 상태의 패킷을 수신한다.
519 단계에서, 수신단은 수신된 패킷을 복호화 한다. 즉, 일 실시 예에 따른 VoLTE의 경우, 암호화 키 값인 HFN 값을 이용하여 수신된 음성 패킷의 복호화를 수행한다.
521 단계에서, 수신단은 복호화된 패킷의 압축 해제 실패 여부를 판단한다. 즉, 수신단은 STATIC-NACK 전송 이후에 수신된 패킷에 대해서도 압축 해제 실패가 감지되는지 판단한다. 일 실시 예에 따라, STATIC-NACK을 피드백한 이후에 수신단은 송신단으로부터 IR 패킷을 수신하며, IR 패킷은 헤더 압축이 되지 않은 상태의 패킷이므로 전체 헤더 정보를 포함한다. 수신단은 수신한 패킷으로부터 전체 헤더 정보를 정상적으로 획득하지 못하는 경우 압축 해제 실패로 판단할 수 있다. 일 실시 예에 따라 수신단은 CRC 검사를 통해 압축 해제 성공 여부를 판단할 수 있다. 이와 같이, 수신단은 STATIC-NACK을 전송한 이후 수신된 패킷의 압축 해제 실패에 대한 판단을 통해 복호화 실패, 즉, HFN 불일치로 인한 복호화 실패가 발생하였는지 판단할 수 있다.
압축 해제가 성공한 경우, 수신단은 509 단계로 돌아간다. 즉, RoHC 압축 해제 실패가 감지되지 않는 경우, 수신단은 송신단으로 ACK 메시지를 피드백한다. 도 3a를 참고하여 설명한 바와 같이, ACK 메시지를 피드백받은 송신단은 STATIC-NACK 수신으로 인한 IR 상태 310에서 FO 상태 320 혹은 SO 상태 330로 변경하여 헤더 압축된 패킷을 전송하게 된다.
압축 해제가 실패한 경우, 523 단계에서, 수신단은 암호화 파라미터를 증가시킨다. 즉, RoHC 압축 해제 실패가 감지되는 경우, 수신단은 암호화 파라미터 값을 조정할 수 있다. 일 실시 예에 따른 VoLTE의 경우, RoHC 압축 해제 실패가 감지되는 경우, 수신단은 암호화 키인 HFN의 불일치로 인한 복호화 실패로 판단할 수 있고, HFN 값을 증가시킬 수 있다. 이 때, HFN 값은 1씩 증가시킬 수 있으며, 또는 실험적인 값에 의해 1 이상을 증가시킬 수 있다.
도 6은 본 개시의 다양한 실시 예들에 따른 무선 통신 시스템에서 압축 해제 실패에 따른 피드백 전송 후 수신단의 동작을 위한 방법을 도시한다. 도 6은 수신단 200의 동작 방법을 예시한다. 수신단 200은 단말 110 또는 기지국 120일 수 있다.
도 6을 참고하면, 601 단계에서, 수신단은 RoHC 피드백으로 STATIC-NACK을 전송한다. 즉, 수신단은 이전에 수신한 패킷의 RoHC 압축 해제 실패에 따라 STATIC-NACK을 송신단으로 피드백한다. 일 실시 예에 따라, STATIC-NACK을 송신하기까지의 과정은 도 5에 도시된 501 단계부터 515 단계와 같이 수행될 수 있다. 즉, 수신단은 이전에 수신된 패킷에 대해 암호화 키 값인 HFN을 이용한 복호화 후 RoHC 압축 해제를 수행하고, RoHC 압축 해제 실패가 감지되고 정적 필드 값도 유효하지 않은 경우 STATIC-NACK을 송신단으로 피드백하게 된다.
이어, 603 단계에서, 수신단은 수신된 패킷을 복호화한다. 즉, 수신단은 STATIC-NACK 전송 이후 수신된 패킷을 복호화한다. 일 실시 예에 따른 VoLTE의 경우, 수신단은 HFN과 PDCP SN의 조합으로 구성된 COUNT 값을 이용하여 PDCP 패킷을 복호화 하게 된다.
605 단계에서, 수신단은 복호화된 패킷의 RoHC 압축 해제를 판단한다. 즉, 수신단은 복호화된 패킷의 RoHC 압축 해제 실패가 발생하는 지 결정한다. 일 실시 예에 따른 도 3을 참고하면, 송신단에서 STATIC-NACK 피드백을 수신하는 경우 송신단은 IR 패킷을 전송하게 된다. IR 패킷은 헤더가 압축되지 않은 상태의 전체 패킷 헤더를 포함한다. 수신단은 IR 패킷을 수신한 후 압축 해제 실패가 감지되는 경우, HFN 불일치에 따른 복호화 실패로 판단할 수 있다.
RoHC 압축 해제가 성공하는 경우, 607 단계에서, 수신단은 압축 해제 실패 횟수 파라미터를 리셋한다. 즉, RoHC 압축 해제가 성공하는 경우에는 파라미터 결정부 231은 압축 해제 실패 횟수에 관한 파라미터를 0으로 리셋한다. 일 실시 예에 따라, RoHC 압축 해제의 성공은 수신단에서 복호화와 압축 해제가 모두 성공하였다는 의미이므로, 본 개시가 상정하고 있는 무선 환경 문제에 의한 연속적인 패킷 손실 상황이 아니라고 판단할 수 있다. 따라서, 이 경우 파라미터 결정부 231은 압축 해제 실패 횟수에 관한 trycount 파라미터 값을 0으로 설정할 수 있다.
이어, 609 단계에서, 수신단은 RoHC 압축 해제된 패킷을 정상 처리하고, 패킷을 해당 모듈 등으로 전달한다.
RoHC 압축 해제가 실패하는 경우, 611 단계에서, 수신단은 압축 해제 실패 횟수 파라미터 값이 기준 값보다 큰 지 결정하고, 실패 횟수 파라미터 값을 1 증가 시킨다. 즉, RoHC 압축 해제가 실패하는 경우, 파라미터 결정부 231은 이전까지 누적된 압축 해제 실패 횟수 파라미터 trycount 값이 미리 정의된 기준 값 N보다 큰지 판단하고, trycount 값을 1 증가시킨다. 미리 정의된 기준 값 N은 1 이상인 임의의 값으로, 수신단이 STATIC-NACK을 전송한 이후에도 IR 패킷을 수신하기까지 수신되는 전송 중(in-flight) 패킷을 고려하여 실험적으로 결정될 수 있다. 다른 실시 예에 따라, 실패 횟수 파라미터 trycount값은 N과의 비교 전에 1을 증가시킬 수 있다.
압축 해제 실패 횟수 파라미터 값이 기준 값보다 큰 경우, 613 단계에서, 수신단은 암호화 파라미터 값을 증가시키고, 압축 해제 실패 횟수 파라미터 값을 리셋한다. 즉, 파라미터 결정부 231은 암호화 파라미터 값을 증가시키고, 압축 해제 실패 횟수 파라미터 값을 리셋한다. 일 실시 예에 따른 VoLTE의 경우, 수신단은 패킷 손실에 따라 HFN 불일치로 RoHC 압축 해제 실패가 일정 횟수 이상 발생하였다고 판단하여, HFN 값을 1 증가 시키고, trycount 값은 0으로 리셋한다. 이후 수신되는 패킷들은 증가된 HFN 값을 이용하여 복호화 된다. 예를 들어, 수신단은 증가된 HFN 값을 적용하여 수신된 패킷의 복호화를 수행하고, RoHC 압축 해제가 성공하는지 판단한다. RoHC 압축 해제가 성공하는 경우, 수신단은 변경된 HFN 값을 유지하고, 통상적인 HFN 계산 알고리즘에 따라 HFN 값을 결정할 수 있다. 일 실시 예에 따라, RoHC 압축 해제가 성공하는 경우 수신단은 송신단으로 ACK 메시지를 피드백할 수 있다. 다른 실시 예들에 따라, 만일 증가된 HFN 값을 이용하여도 RoHC 압축 해제 실패가 감지되는 경우, 압축 해제 실패 횟수와 미리 정의된 기준 값을 비교하여 HFN 값을 조정하는 과정을 반복할 수 있다.
압축 해제 실패 횟수 파라미터 값이 기준 값 이하인 경우, 615 단계에서, 수신단은 해당 패킷을 드롭(drop)한다. 다시 말해, 압축 해제 실패 횟수 파라미터 값이 기준 값 이하인 경우, 수신단은 해당 패킷을 폐기(discard)할 수 있다.
본 개시의 청구항 또는 명세서에 기재된 실시 예들에 따른 방법들은 하드웨어, 소프트웨어, 또는 하드웨어와 소프트웨어의 조합의 형태로 구현될(implemented) 수 있다.
소프트웨어로 구현하는 경우, 하나 이상의 프로그램(소프트웨어 모듈)을 저장하는 컴퓨터 판독 가능 저장 매체가 제공될 수 있다. 컴퓨터 판독 가능 저장 매체에 저장되는 하나 이상의 프로그램은, 전자 장치(device) 내의 하나 이상의 프로세서에 의해 실행 가능하도록 구성된다(configured for execution). 하나 이상의 프로그램은, 전자 장치로 하여금 본 개시의 청구항 또는 명세서에 기재된 실시 예들에 따른 방법들을 실행하게 하는 명령어(instructions)를 포함한다.
이러한 프로그램(소프트웨어 모듈, 소프트웨어)은 랜덤 액세스 메모리 (random access memory), 플래시(flash) 메모리를 포함하는 비휘발성(non-volatile) 메모리, 롬(ROM: Read Only Memory), 전기적 삭제가능 프로그램가능 롬(EEPROM: Electrically Erasable Programmable Read Only Memory), 자기 디스크 저장 장치(magnetic disc storage device), 컴팩트 디스크 롬(CD-ROM: Compact Disc-ROM), 디지털 다목적 디스크(DVDs: Digital Versatile Discs) 또는 다른 형태의 광학 저장 장치, 마그네틱 카세트(magnetic cassette)에 저장될 수 있다. 또는, 이들의 일부 또는 전부의 조합으로 구성된 메모리에 저장될 수 있다. 또한, 각각의 구성 메모리는 다수 개 포함될 수도 있다.
또한, 프로그램은 인터넷(Internet), 인트라넷(Intranet), LAN(Local Area Network), WLAN(Wide LAN), 또는 SAN(Storage Area Network)과 같은 통신 네트워크, 또는 이들의 조합으로 구성된 통신 네트워크를 통하여 접근(access)할 수 있는 부착 가능한(attachable) 저장 장치(storage device)에 저장될 수 있다. 이러한 저장 장치는 외부 포트를 통하여 본 개시의 실시 예를 수행하는 장치에 접속할 수 있다. 또한, 통신 네트워크상의 별도의 저장장치가 본 개시의 실시 예를 수행하는 장치에 접속할 수도 있다.
상술한 본 개시의 구체적인 실시 예들에서, 개시에 포함되는 구성 요소는 제시된 구체적인 실시 예에 따라 단수 또는 복수로 표현되었다. 그러나, 단수 또는 복수의 표현은 설명의 편의를 위해 제시한 상황에 적합하게 선택된 것으로서, 본 개시가 단수 또는 복수의 구성 요소에 제한되는 것은 아니며, 복수로 표현된 구성 요소라 하더라도 단수로 구성되거나, 단수로 표현된 구성 요소라 하더라도 복수로 구성될 수 있다.
한편 본 개시의 상세한 설명에서는 구체적인 실시 예에 관해 설명하였으나, 본 개시의 범위에서 벗어나지 않는 한도 내에서 여러 가지 변형이 가능함은 물론이다. 그러므로 본 개시의 범위는 설명된 실시 예에 국한되어 정해져서는 아니 되며 후술하는 특허청구의 범위뿐만 아니라 이 특허청구의 범위와 균등한 것들에 의해 정해져야 한다.

Claims (15)

  1. 무선 통신 시스템에서 수신단의 동작 방법에 있어서,
    송신단으로부터 패킷을 수신하는 과정과,
    상기 수신된 패킷에 대해 암호화 파라미터를 이용하여 복호화를 수행하는 과정과,
    상기 복호화된 패킷 헤더의 압축 해제에 대한 실패를 감지하는 과정과,
    상기 압축 해제에 대한 실패를 감지함에 따라, 상기 암호화 파라미터의 값을 조정하는 과정을 포함하는 방법.
  2. 청구항 1에 있어서,
    상기 패킷을 수신하는 과정은,
    이전에 수신한 패킷에 대한 압축 해제 실패 정보를 상기 송신단으로 전송하는 과정과,
    압축되지 않은 전체 헤더를 포함하는 상기 패킷을 상기 송신단으로부터 수신하는 과정을 포함하는 방법.
  3. 청구항 1에 있어서,
    상기 암호화 파라미터 값을 조정하는 과정은,
    상기 압축 해제에 대한 실패 횟수 파라미터 값을 미리 설정된 기준 값과 비교하는 과정과,
    상기 실패 횟수 파라미터 값이 미리 설정된 기준 값보다 큰 경우, 상기 암호화 파라미터 값을 증가시키는 과정을 포함하는 방법.
  4. 청구항 3에 있어서,
    상기 실패 횟수 파라미터 값이 미리 설정된 기준 값보다 큰 경우, 상기 실패 횟수 파라미터 값을 리셋하는 과정을 더 포함하는 방법.
  5. 청구항 3에 있어서,
    상기 실패 횟수 파라미터 값이 미리 설정된 기준 값 이하인 경우, 상기 실패 횟수 파라미터 값을 증가시키는 과정과,
    상기 수신된 패킷을 드롭(drop)하는 과정을 더 포함하는 방법.
  6. 청구항 3에 있어서,
    상기 증가된 암호화 파라미터 값을 이용하여 패킷의 복호화를 수행하는 과정과,
    상기 복호화된 패킷의 헤더 압축 해제가 실패하는 경우, 상기 증가된 암호화 파라미터 값을 다시 증가시키는 과정을 더 포함하는 방법.
  7. 청구항 6에 있어서,
    상기 복호화된 패킷의 헤더 압축 해제가 성공하는 경우, 상기 압축 해제 성공 정보를 상기 송신단으로 전송하는 과정과,
    상기 송신단으로부터 헤더 압축된 패킷을 수신하는 과정을 더 포함하는 방법.
  8. 청구항 6에 있어서,
    상기 복호화된 패킷의 헤더 압축 해제가 성공하는 경우, 상기 압축 해제에 대한 실패 횟수 파라미터 값을 리셋하는 과정을 더 포함하는 방법.
  9. 무선 통신 시스템에서 수신단 장치에 있어서,
    송신단으로부터 패킷을 수신하는 송수신부와,
    상기 수신된 패킷에 대해 암호화 파라미터를 이용하여 복호화를 수행하고, 상기 복호화된 패킷 헤더의 압축 해제에 대한 실패를 감지하고, 상기 압축 해제에 대한 실패를 감지함에 따라, 상기 암호화 파라미터의 값을 조정하는 제어부를 포함하는 장치.
  10. 청구항 9에 있어서,
    상기 송수신부는,
    이전에 수신한 패킷에 대한 압축 해제 실패 정보를 상기 송신단으로 전송하고,
    압축되지 않은 전체 헤더를 포함하는 상기 패킷을 상기 송신단으로부터 수신하는 장치.
  11. 청구항 9에 있어서,
    상기 제어부는,
    상기 압축 해제에 대한 실패 횟수 파라미터 값을 미리 설정된 기준 값과 비교하고,
    상기 실패 횟수 파라미터 값이 미리 설정된 기준 값보다 큰 경우, 상기 암호화 파라미터 값을 증가시키는 장치.
  12. 청구항 11에 있어서,
    상기 제어부는,
    상기 실패 횟수 파라미터 값이 미리 설정된 기준 값보다 큰 경우, 상기 실패 횟수 파라미터 값을 리셋하는 장치.
  13. 청구항 11에 있어서,
    상기 제어부는,
    상기 실패 횟수 파라미터 값이 미리 설정된 기준 값 이하인 경우, 상기 실패 횟수 파라미터 값을 증가시키고,
    상기 수신된 패킷을 드롭(drop)하는 장치.
  14. 청구항 11에 있어서,
    상기 제어부는,
    상기 증가된 암호화 파라미터 값을 이용하여 패킷의 복호화를 수행하고,
    상기 복호화된 패킷의 헤더 압축 해제가 실패하는 경우, 상기 증가된 암호화 파라미터 값을 다시 증가시키는 장치.
  15. 청구항 14에 있어서,
    상기 송수신부는,
    상기 복호화된 패킷의 헤더 압축 해제가 성공하는 경우, 상기 압축 해제 성공 정보를 상기 송신단으로 전송하고,
    상기 송신단으로부터 헤더 압축된 패킷을 수신하는 장치.
PCT/KR2018/002132 2017-02-21 2018-02-21 무선 통신 시스템에서 암호화 파라미터 값을 결정하기 위한 장치 및 방법 WO2018155903A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/487,284 US11770249B2 (en) 2017-02-21 2018-02-21 Apparatus and method for determining encoded parameter value in wireless communication system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020170022995A KR20180096370A (ko) 2017-02-21 2017-02-21 무선 통신 시스템에서 암호화 파라미터 값을 결정하기 위한 장치 및 방법
KR10-2017-0022995 2017-02-21

Publications (1)

Publication Number Publication Date
WO2018155903A1 true WO2018155903A1 (ko) 2018-08-30

Family

ID=63253754

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2018/002132 WO2018155903A1 (ko) 2017-02-21 2018-02-21 무선 통신 시스템에서 암호화 파라미터 값을 결정하기 위한 장치 및 방법

Country Status (3)

Country Link
US (1) US11770249B2 (ko)
KR (1) KR20180096370A (ko)
WO (1) WO2018155903A1 (ko)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2785091A1 (en) * 2013-03-26 2014-10-01 Alcatel Lucent Method, apparatus and computer program product for determining validity of Hyper Frame Numbers used for decoding PDCP units
US20150280905A1 (en) * 2014-04-01 2015-10-01 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for detecting and correcting pdcp hyper frame number (hfn) desynchronization
US20150382395A1 (en) * 2014-06-30 2015-12-31 Alcatel-Lucent Usa Inc. Method For Recovering From PDCP HFN De-Synchronization For VoLTE Call And Data Failure In RLC Layer
US20160142936A1 (en) * 2014-11-19 2016-05-19 Qualcomm Incorporated Methods and apparatus for synchronizing a user equipment with an hfn offset
KR20170004598A (ko) * 2015-07-03 2017-01-11 삼성전자주식회사 헤더 압축을 이용한 패킷 통신 방법 및 장치

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7647421B2 (en) * 2002-08-20 2010-01-12 Nokia Corporation Extension header compression
US7822067B2 (en) * 2003-08-08 2010-10-26 Qualcomm Incorporated Header compression enhancement for broadcast/multicast services
KR101525252B1 (ko) 2007-12-31 2015-06-02 삼성전자주식회사 무선 통신 시스템에서의 하이퍼 프레임 넘버 비동기 방지 방법
US9124425B2 (en) * 2009-06-30 2015-09-01 Nokia Technologies Oy Systems, methods, and apparatuses for ciphering error detection and recovery
CN102036307B (zh) * 2010-12-17 2016-04-13 中兴通讯股份有限公司 鲁棒性头压缩中提高上下文更新报文健壮性的方法和装置
US9084142B2 (en) * 2011-10-03 2015-07-14 Qualcomm Incorporated Activating and deactivating semi-persistent scheduling for an LTE VoIP radio bearer
KR102026725B1 (ko) 2012-01-09 2019-09-30 삼성전자 주식회사 무선 통신 시스템에서 핸드오버 방법 및 장치
US9313756B2 (en) 2012-10-10 2016-04-12 Qualcomm Incorporated Apparatus and methods for managing hyper frame number (HFN) de-synchronization in radio link control (RLC) unacknowledged mode (UM)
WO2016024148A1 (en) * 2014-08-15 2016-02-18 Telefonaktiebolaget L M Ericsson (Publ) Rohc optimizations for burst losses
US9923695B2 (en) * 2014-09-24 2018-03-20 Samsung Electronics Co., Ltd. Call processing method and apparatus for use in LTE system
EP3264779B1 (en) * 2016-06-30 2022-04-13 Apple Inc. Apparatus adapted for maintaining receiving data quality and method for receiving data
JP6847115B2 (ja) * 2016-08-12 2021-03-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 端末、基地局及び通信方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2785091A1 (en) * 2013-03-26 2014-10-01 Alcatel Lucent Method, apparatus and computer program product for determining validity of Hyper Frame Numbers used for decoding PDCP units
US20150280905A1 (en) * 2014-04-01 2015-10-01 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for detecting and correcting pdcp hyper frame number (hfn) desynchronization
US20150382395A1 (en) * 2014-06-30 2015-12-31 Alcatel-Lucent Usa Inc. Method For Recovering From PDCP HFN De-Synchronization For VoLTE Call And Data Failure In RLC Layer
US20160142936A1 (en) * 2014-11-19 2016-05-19 Qualcomm Incorporated Methods and apparatus for synchronizing a user equipment with an hfn offset
KR20170004598A (ko) * 2015-07-03 2017-01-11 삼성전자주식회사 헤더 압축을 이용한 패킷 통신 방법 및 장치

Also Published As

Publication number Publication date
US11770249B2 (en) 2023-09-26
KR20180096370A (ko) 2018-08-29
US20200022021A1 (en) 2020-01-16

Similar Documents

Publication Publication Date Title
US10750414B2 (en) System and method for handovers in a dual connectivity communications system
EP2375651B1 (en) Method for resuming header decompression in a multimedia broadcast/multicast service system
RU2501173C2 (ru) Системы, способы и устройства для обнаружения и исправления ошибки шифрования
US8189594B2 (en) Method of controlling header compression in wireless communication, wireless base station, and transmitter
JP5082768B2 (ja) 移動通信システム、移動通信方法、無線基地局装置、および端末
US20170222943A1 (en) Method and apparatus for reordering
KR20090069254A (ko) 지연에 영향을 받지 않는 데이터 전송을 가진 무선 통신을위한 시스템 및 방법
KR101918907B1 (ko) 높은 업링크 간섭 상태에서의 호출 연속성
EP3707875B1 (en) Transmitting device, receiving device, and methods performed therein for handling uplink data compression
WO2016048031A2 (en) Call processing method and apparatus for use in lte system
US8867391B2 (en) Method and apparatus for error correction ciphering in mobile communication system
US20040092276A1 (en) Cellular telephone system
US20160142937A1 (en) Techniques for compressing session initiation messages using templates for evolved data compression scheme (edcs)
KR20200076561A (ko) 차세대 이동 통신 시스템에서 pdcp 계층 장치 기반 보안키 확인 방법 및 장치
US20030177437A1 (en) Erroneous packet data convergence protocol data unit handling scheme in a wireless communication system
EP3198928B1 (en) Call processing method and apparatus for use in lte system
US20080137574A1 (en) Method and apparatus for handling data delivery in a wireless communications system
WO2018155903A1 (ko) 무선 통신 시스템에서 암호화 파라미터 값을 결정하기 위한 장치 및 방법
US10299162B2 (en) Robust header compression (RoHC) techniques for a dynamically changing extension bit
JP2017503449A (ja) 切り替え方法、ソース基地局、ターゲット基地局、システム、記憶媒体
WO2021100578A1 (ja) 制御装置および制御方法
WO2017082619A1 (ko) 무선 통신 시스템에서 음성 패킷의 크기를 제어하기 위한 장치 및 방법
KR20080053230A (ko) 무선통신시스템에서 재정렬을 처리하는 방법 및 장치
KR20200114978A (ko) 무선 통신 시스템에서 데이터를 송수신하는 방법 및 장치
WO2019004623A1 (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: 18756829

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

Country of ref document: EP

Kind code of ref document: A1