[go: up one dir, main page]

WO2017003215A1 - Procédé de routage et entité de réseau mettant en œuvre ce procédé - Google Patents

Procédé de routage et entité de réseau mettant en œuvre ce procédé Download PDF

Info

Publication number
WO2017003215A1
WO2017003215A1 PCT/KR2016/007027 KR2016007027W WO2017003215A1 WO 2017003215 A1 WO2017003215 A1 WO 2017003215A1 KR 2016007027 W KR2016007027 W KR 2016007027W WO 2017003215 A1 WO2017003215 A1 WO 2017003215A1
Authority
WO
WIPO (PCT)
Prior art keywords
client
communication
data
counterpart
server
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/KR2016/007027
Other languages
English (en)
Korean (ko)
Other versions
WO2017003215A8 (fr
Inventor
투이이피 주식회사
조광현
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
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
Priority claimed from KR1020160018413A external-priority patent/KR101785385B1/ko
Priority claimed from KR1020160079956A external-priority patent/KR101888952B1/ko
Application filed by Individual filed Critical Individual
Priority to US15/740,811 priority Critical patent/US10681755B2/en
Priority to CN201680050078.1A priority patent/CN108141721A/zh
Publication of WO2017003215A1 publication Critical patent/WO2017003215A1/fr
Publication of WO2017003215A8 publication Critical patent/WO2017003215A8/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

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/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/24—Accounting or billing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing

Definitions

  • the embodiments below relate to a routing method and a network entity performing the same.
  • 5G Recently, mobile communication technology targets 5G.
  • the evolution to 5G requires not only expansion of communication bandwidth but also improvement of data transmission speed.
  • Various communication methods may be applied to improve the data transmission speed.
  • a network routing technique is required to guarantee a quality of service (QoS) that can support voice calls.
  • QoS quality of service
  • P2P peer to peer
  • relay method among various communication methods, that is, in the case of communication that does not go through a network entity directly managed by a mobile service provider, It is difficult to carry out the billing.
  • a method of operating a communication device includes generating an intermediate key corresponding to peer to peer (P2P) communication between a client and a counterpart client; Transmitting the intermediate key to the counterpart client; Securing an intermediate path corresponding to the intermediate key; Receiving the data through the intermediary path from the client whose network address of the counterpart client has been changed and has not received an acknowledgment for the data sent to the counterpart client; And transmitting the data to the counterpart client when the counterpart client connects using the intermediate key.
  • P2P peer to peer
  • the generating of the intermediate key may include generating the intermediate key when connected to the counterpart client that has received the client's P2P communication request from the server.
  • the server may receive the intermediate key from the counterpart client, transmit the intermediate key to the client, and the step of securing the intermediate path may include: receiving the intermediate key from the client; Securing may be included.
  • the intermediate path may include a dedicated room of the client holding the intermediate key and the counterpart client.
  • the transmitting of the data to the counterpart client may include: receiving a connection request including the intermediate key from the counterpart client having the changed network address; And allowing an access according to the access request based on the intermediate key.
  • the intermediate key may correspond to an arbitrary value or may be generated based on unique information of the client and the counterpart client.
  • the client may receive an acknowledgment for the data received by the counterpart client from the communication device, and may later transmit data to the changed network address of the counterpart client.
  • an operation method of a server may include: receiving a P2P communication request from a client and transmitting the P2P communication request to a counterpart client; When the counterpart client accesses the server, generating an intermediate key and transmitting the intermediate key to the counterpart client and the client; Receiving the intermediate key from the client to secure an intermediate path corresponding to the intermediate key; Receiving the data through the intermediary path from the client whose network address of the counterpart client has been changed and has not received an acknowledgment for the data sent to the counterpart client; And transmitting the data to the counterpart client when the counterpart client reconnects using the intermediate key.
  • the intermediate path may include a dedicated room of the client holding the intermediate key and the counterpart client.
  • the transmitting of the data to the counterpart client may include: receiving a reconnection request including the intermediate key from the counterpart client having the changed network address; And allowing an access according to the reconnection request based on the intermediate key.
  • the intermediate key may correspond to an arbitrary value or may be generated based on unique information of the client and the counterpart client.
  • the client may receive an acknowledgment for the data received by the counterpart client and may later transmit data to the changed network address of the counterpart client.
  • the method may further include allocating a session identifier of the client to the client.
  • the transmitting of the question may include transmitting, to the question, first cryptographic information generated by encrypting identification information received from the client and access time information of the client, and receiving the answer.
  • the method may include receiving, as the answer, second cryptographic information generated by encrypting the first cryptographic information, and confirming whether the answer corresponds to the question by decrypting the second cryptographic information. And checking whether the extracted extraction information corresponds to the identification information and the access time information.
  • an operation method of a client may include transmitting a P2P communication request to a server; Receiving, from the server, a media key generated by a communication mediator for mediating communication between the client and the counterpart client and a network address of the counterpart client; Connecting with the communication media device using the media key; Transmitting data to the counterpart client using the network address; And when the network address is changed and fails to receive an acknowledgment for the data transmitted to the counterpart client, transmitting the data to the communication mediator, wherein the counterpart client uses the intermediary key. Connect to the communication medium and receive the data from the communication medium.
  • a medium path corresponding to the medium key can be secured.
  • the intermediate path may include a dedicated room of the client holding the intermediate key and the counterpart client.
  • the method may further include receiving a notification from the server that the network address has changed.
  • the counterpart client may further include receiving, from the counterpart client, an acknowledgment for the data received from the communication medium device.
  • the generating of the P2P communication path may include: sending a speed test request to the counterpart client; Receiving a test response to the speed test request from the counterpart client; And checking a response time of the counterpart client based on the test response.
  • the transmitting of the data may include transmitting the data to the communication medium device when the acknowledgment is not received within the response time.
  • Receiving the question comprises: transmitting identification information of the client to the server; And receiving, as the question, first cryptographic information generated by encrypting the identification information and the access time information of the client, and transmitting the answer, encrypting the first cryptographic information. And transmitting the encrypted second cryptographic information as the answer.
  • a method of operating a client when receiving a P2P communication request of a requesting client from a server; Receiving an intermediate key from the communication intermediate device; Reconnecting to the communication media device using the media key when the network address of the client is changed; Receiving the data from the communication medium device, receiving the data from the requesting client that has not received an acknowledgment for the data sent to the client; And sending an acknowledgment for the data to the requesting client.
  • a communication device including: a controller configured to generate a media key corresponding to peer-to-peer communication between a client and a counterpart client, and to secure a media path corresponding to the media key; And transmitting the media key to the counterpart client, and receiving the data through the intermediary path from the client that has changed the network address of the counterpart client and has not received an acknowledgment for the data sent to the counterpart client. And, when the counterpart client accesses using the intermediate key, transmits the data to the counterpart client.
  • the client sends a P2P communication request to the server, and receives from the server the media key and the network address of the counterpart client generated by the communication mediator for mediating communication between the client and the counterpart client, Connecting to the communication media device using a key, transmitting data to the counterpart client using the network address, and changing the network address, and failing to receive an acknowledgment for data transmitted to the counterpart client.
  • a connection unit for transmitting the data to the communication medium device; And a processor for controlling the connection unit, wherein the counterpart client connects to the communication medium apparatus using the medium key and receives the data from the communication medium apparatus.
  • the client When the client according to the other side receives the P2P communication request of the requesting client from the server, access the communication medium device, receive the medium key from the communication medium device, if the network address of the client is changed, the medium key Reconnect to the communication media device using the device, wherein the communication media device receives the data from the device to the requesting client that has not received an acknowledgment for the data sent to the client.
  • a connection unit receiving the data and transmitting an acknowledgment for the data to the requesting client; And a processor controlling the connection unit.
  • a method of operating a client comprising: establishing a peer to peer (P2P) communication path with a counterpart client; Transmitting a shared key to the counterpart client; Receiving data encrypted with the shared key through the P2P communication path; Decrypting the encrypted data using the shared key; And when the data is decrypted, updating decryption number information related to data usage of the client.
  • P2P peer to peer
  • the method may further include transmitting updated decryption number information to a server, and receiving guide information on the data usage amount from the server.
  • the guide information may include: excess information indicating whether the data usage amount exceeds a predetermined usage amount; Remaining information indicating available data capacity excluding the data usage amount among the predetermined usage amounts; And restriction information indicating whether there is a restriction on at least one of bandwidth and quality of the P2P communication of the client.
  • the received information may include updated decryption number information each time the shared client decrypts the encrypted data received through the P2P communication.
  • the network address of the client changes, transmitting change information indicating that the network address of the client changes to a server; Accessing a communication mediation device that secures an intermediate path corresponding to the P2P communication path; And receiving other data encrypted with the shared key of the counterpart client from the communication medium device, wherein the counterpart client receives an acknowledgment for the other data transmitted to the client from the client. If not, the other data may be transmitted to the communication medium.
  • the method may further include updating the decryption number information.
  • the establishing of the P2P communication path may include transmitting a P2P communication request to a server; Receiving, from the server, a media key generated by a communication mediator for mediating communication between the client and the counterpart client and a network address of the counterpart client; Accessing the communication media device using the media key; And establishing a P2P communication path with the counterpart client based on the network address when accessing the communication medium device.
  • the establishing of the P2P communication path may include: receiving a P2P communication request of the counterpart client from a server; When receiving the P2P communication request, accessing a communication mediation device that mediates communication between the client and the counterpart client; Receiving a media key from the communication media device and transmitting the media key to the server; Receiving test data from the counterpart client and establishing the P2P communication path, wherein the counterpart client receives the client's network address and the intermediate key from the server, and uses the intermediate key; Access to the communication media device, and transmit the test data to the client using the network address.
  • a client establishes a peer-to-peer communication path with a counterpart client, transmits a shared key to the counterpart client, and receives data encrypted with the shared key through the P2P communication path. ; And a controller that decrypts the encrypted data using the shared key and updates decryption number information related to data usage of a client when the data is decrypted.
  • the communication interface may transmit the decryption number information to a server and receive guide information on the data usage amount from the server.
  • the guide information may include: excess information indicating whether the data usage amount exceeds a predetermined usage amount; Remaining information indicating available data capacity excluding the data usage amount among the predetermined usage amounts; And restriction information indicating whether there is a restriction on at least one of bandwidth and quality of the P2P communication of the client.
  • the communication interface may receive information related to data usage of a shared client sharing a data quota allocated to the client, and the controller may update the decryption count information based on the received information. have.
  • the received information may include updated decryption number information each time the shared client decrypts the encrypted data received through the P2P communication.
  • the communication interface transmits change information indicating that the network address of the client is changed to a server, and accesses a communication medium device that secures an intermediate path corresponding to the P2P communication path. And receiving other data encrypted with the shared key of the counterpart client from the communication medium device, and when the counterpart client fails to receive an acknowledgment for the other data transmitted to the client from the client, Other data may be sent to the communication media device.
  • the controller may update the decryption number information when the other data is decrypted with the shared key.
  • the communication interface transmits a P2P communication request to a server, and receives from the server an intermediate key generated by a communication mediator for mediating communication between the client and the counterpart client and a network address of the counterpart client.
  • the P2P communication path with the counterpart client may be established based on the network address.
  • the communication interface receives a P2P communication request of the counterpart client from a server, and when receiving the P2P communication request, connects to a communication mediator that communicates communication between the client and the counterpart client, and from the communication medium.
  • Receiving the intermediate key transmitting the intermediate key to the server, receiving test data from the counterpart client, and establishing the P2P communication path, wherein the counterpart client is configured to receive the client's network address and the A media key may be received, the media key may be used to access the communication media device, and the test data may be transmitted to the client using the network address.
  • the client may communicate through an intermediate path corresponding to the P2P communication path, thereby improving network throughput.
  • charging for data usage of P2P communication may be performed.
  • charging based information may be generated via communication software.
  • FIGS. 1A to 1B are flowcharts illustrating an example of an operation of a communication system according to an exemplary embodiment.
  • FIG. 2 is a flowchart illustrating another example of an operation of a communication system according to an exemplary embodiment.
  • 3A to 3B are block diagrams illustrating a communication system according to an embodiment.
  • FIG. 4 is a diagram for describing an operation of a communication system, according to an exemplary embodiment.
  • FIG. 5 is a flowchart illustrating a method of operating a communication device, according to an exemplary embodiment.
  • FIG. 6 is a flowchart illustrating a method of operating a server, according to an exemplary embodiment.
  • FIG. 7 is a flowchart illustrating an example of a method of operating a client, according to an exemplary embodiment.
  • FIG. 8 is a flowchart illustrating another example of a method of operating a client, according to an exemplary embodiment.
  • FIG. 9 is a flowchart illustrating session maintenance between a client and a server, according to an exemplary embodiment.
  • FIGS. 10A and 10B are diagrams for describing another example of a method of operating a client, according to an exemplary embodiment.
  • FIG. 11 illustrates a sharing of a data quota allocated to a client according to an exemplary embodiment.
  • FIG. 12 is a block diagram illustrating an example of a client according to an exemplary embodiment.
  • FIG. 13 illustrates an example of a secure call dongle according to an exemplary embodiment.
  • FIGS. 1A to 1B are flowcharts illustrating an example of an operation of a communication system according to an exemplary embodiment.
  • a communication system includes a client 1, a server, an intermediary, and a client 2.
  • the server may establish a communication session (eg, a User Datagram Protocol (UDP) session) with each of Client 1 and Client 2.
  • a communication session eg, a User Datagram Protocol (UDP) session
  • UDP User Datagram Protocol
  • Client 1 sends a communication request to the server (110).
  • the client 1 may transmit a P2P communication request to the server through a UDP session for peer to peer (P2P) communication with the client 2.
  • P2P peer to peer
  • the server transmits a communication request of client 1 to client 2 (111).
  • the client 2 may connect with the intermediary 122. More specifically, when the client 2 receives the client 1's communication request from the server, the client 2 may attempt to connect to the intermediary, and the intermediary may allow the client 2 to connect. Accordingly, the client 2 can connect to the intermediary and maintain the connection.
  • the intermediary is a device that is physically distinct from the server, and may be an independent device on the network.
  • the intermediary may be included in the server, and may be any one of a plurality of units logically separated within the server.
  • the intermediary unit When the intermediary unit is connected to the client 2, the intermediary unit generates 113 an intermediary key.
  • the intermediary can generate an intermediary key with an arbitrary value.
  • the intermediary may generate the intermediary key based on the unique information of the client 1 and / or the client 2.
  • the unique information may include, for example, an identifier assigned to each of Client 1 and Client 2.
  • the intermediary sends the intermediary key to client 2 (114).
  • Client 2 sends the intermediate key to the server (115).
  • the server sends the client 2's network address and intermediate key to client 1 (116).
  • the network address may include, for example, an IP (Internet Protocol) address.
  • Client 1 sends the intermediary key to the intermediary (117).
  • Client 1 can access the intermediary by sending the intermediary key to the intermediary.
  • the client 1 can maintain a connection with the intermediary.
  • an intermediary path may be formed that corresponds to the connection relationship of client 1-mediated-client 2.
  • the intermediate path is a path to prepare for disconnection of the P2P communication path between the client 1 and the client 2.
  • the intermediary path may comprise dedicated rooms of Client 1 and Client 2 having the media key. Securing the intermediary path may mean that a dedicated room is created in the intermediary.
  • the intermediary may create a dedicated room where client 1 and client 2 can participate and other clients cannot participate.
  • Client 1 may send a speed test request to client 2 via the network address (119).
  • the client 1 may transmit test data for testing the P2P communication speed to the client 2.
  • Client 2 may send a test response to the speed test request to client 1 (120).
  • Client 1 can check the response time of Client 2.
  • Client 1 can check the P2P communication speed between Client 1 and Client 2.
  • Client 2 may transmit a speed test request to client 1 (121).
  • Client 1 may send a test response to the speed test request to client 2 (122).
  • Client 2 can check the response time of Client 1.
  • the speed test of client 2 may be performed simultaneously with the speed test of client 1.
  • the speed test of Client 1 and / or Client 2 may be repeated a predetermined number of times. For example, the speed test may be repeated two or more times.
  • Client 1 can send an additional speed test request to Client 2 upon receiving a test response from Client 2.
  • Client 2 may send a test response to the additional speed test request to client 1.
  • Client 1 can check the average response time of Client 2.
  • Client 2 can ascertain the average response time of Client 1.
  • a P2P communication path may be established between client 1 and client 2. Assume that client 1 is mapped to network address A, and client 2 is mapped to network address B. In this case, the P2P communication path A-B may be set.
  • Client 1 transmits the shared key to client 2 (123).
  • the shared key is used for encrypting and / or decrypting data.
  • the shared key may be transmitted through a P2P communication path.
  • Client 1 sends the shared key to Client 2.
  • client 1 may simultaneously send a speed test request and a shared key to client 2. If client 1 does not receive a test response from client 2, it can resend the rate test request and the shared key to client 2 at the same time. When client 1 receives a test response from client 2, it does not send a shared key when sending an additional speed test request to client 2.
  • Client 1 sends the shared key to Client 2 via a P2P communication path.
  • Client 1 may transmit the shared key to the server after connecting to the server, the server may transmit the shared key to the client 2.
  • client 1 may send a communication request and a shared key to a server at the same time, and the server may send a communication request and a shared key to client 2 at the same time.
  • Client 1 may send data 1 to client 2 (124).
  • data 1 may be encrypted with a shared key.
  • Data 1 may be a data fragment of the entire data.
  • Client 2 receives data 1 and decrypts data 1 using the shared key. Although not shown in FIG. 1A, when the client 2 decrypts the data 1, the client 2 updates the decoding count information. Let n be the decoding count information client 2 recorded before the client 2 receives the data 1. When the client 2 decrypts the data 1, the client 2 may update the decryption count information client 2 to n + 1. Client 2 may send an acknowledgment for data 1 to client 1 (125).
  • Data 2 may be a data fragment of the entire data and may be encrypted with a shared key, as described above.
  • client 2 may or may not receive an acknowledgment for data 2 from client 2 later than the response time (or average response time). In this case, client 1 transmits data 2 intermediary (128). If the client 1 does not receive the acknowledgment for the data 2 within the response time confirmed in the speed test step, the client 1 may transmit the data 2 to the intermediary. In other words, since the client 1 maintains the connection with the intermediary before P2P communication, when detecting an event related to not receiving the acknowledgment for a predetermined time, the client 1 may transmit data 2 to the intermediary. Client 1 may send data 2 to the intermediary through the intermediary path.
  • the interceptor stores data 2 in memory when data 2 is received from client 1.
  • the memory may include, for example, a memory corresponding to an intermediate path or a dedicated room.
  • the client 2 may inform the server that the network address has changed (129). If the network address of client 2 is changed from B to B ', client 2 may inform the server that the network address has changed from B to B'.
  • the server may receive change information indicating that the network address is changed from the client 2.
  • the change information may include the changed network address of the client 2. Accordingly, the server can confirm the changed network address of the client 2.
  • the server may perform a question and answer process with Client 2 to determine if the network entity mapped to B 'is Client 2.
  • the question and answer process will be described later with reference to FIG. 9.
  • the server may maintain a communication session with Client 2 through a question and answer process.
  • the server may inform client 1 that the network address of client 2 has changed (130).
  • the client 1 may receive the change information of the network address from the server. Accordingly, the client 1 can confirm the changed network address of the client 2.
  • Client 2 whose network address is mapped to B ', connects to the intermediary with an intermediate key (131).
  • the client 2 may attempt to connect to the intermediary by sending the intermediary key to the intermediary, and the intermediary may allow the client 2 to connect. Accordingly, the client 2 can connect to the intermediary.
  • the intermediary may transmit data 2 to the client 2 (132).
  • client 2 can join a private room using an intermediate key.
  • the client 2 may receive data 2 stored in a memory corresponding to the private room.
  • the client 2 may decrypt the data 2 using the public key.
  • the client 2 may update the decryption count information.
  • the client 2 may update the decryption count information client 2 to n + 2.
  • Client 2 may send an acknowledgment for data 2 to client 1 (133).
  • the client 1 When the client 1 receives the acknowledgment for the data 2, the client 1 may transmit the data 3 to the client 2 (134). P2P communication path is changed from A-B to A-B '.
  • Data 3 can be encrypted with a shared key.
  • Client 2 may receive data 3 and decrypt data 3 using the shared key. Client 2 may update the decryption count information. In the example described above, the client 2 may update the decryption count information client 2 to n + 3. Client 2 may send an acknowledgment for data 3 to client 1 (135).
  • client 2 transmits data 4 to client 1 (136).
  • Data 4 can be encrypted with a shared key.
  • Client 1 may receive data 4 and decrypt data 4 using the shared key. In addition, the client 1 may update its decryption number information. Assume that the decryption number information client 1 recorded before the client 1 receives the data 4 is m. When the client 1 decrypts the data 4, the decryption number information client 1 may be updated to m + 1.
  • Client 1 may send an acknowledgment for data 4 to client 2 (137).
  • Client 2 may send data 5 to client 1 (138).
  • the client 1 may change its network address due to movement.
  • client 2 may not receive an acknowledgment for data 5 within a predetermined time.
  • the client 2 may transmit data 5 to the intermediary (139).
  • Client 1 may inform the server that the network address has changed (140), and the server may inform client 2 that the network address of Client 1 has changed (141). Assume that Client 1's network address has changed from A to A '.
  • Client 1 can connect to the intermediary with the intermediary key (142). More specifically, the client 1 may attempt to connect to the intermediary by sending the intermediary key to the intermediary, and the intermediary may allow the client 1 to connect.
  • the intermediate unit may transmit data 5 to the client 1 (143).
  • Client 1 can receive data five.
  • data 5 may be encrypted with a shared key.
  • Client 1 can decrypt data 5 with the shared key and update the decryption number information.
  • the decryption count information client 1 may be updated to m + 2.
  • Client 1 may send an acknowledgment for data 5 to client 2 (144).
  • data 1-3 are transmitted to client 2 via a mobile operator's switchboard equipment (eg, a device that determines a Quality of Service (QoS) or Service Level Agreement (SLA)). It doesn't work.
  • data 4 through 5 are not transmitted to Client 1 through the mobile operator's switchboard equipment. In this case, charging for data 1 to 5 may be difficult.
  • the client 1 and the client 2 may update the decryption number information each time the received data is decrypted.
  • the decryption count information is information related to data usage, and is information that is the basis for billing.
  • the client 1 and the client 2 may transmit the decryption number information to the server according to a predetermined cycle so that charging for data usage may be performed. For example, Client 1 and Client 2 may transmit their decryption count information to the server once a day, once a week, or once a month. In addition, when the P2P communication ends, the client 1 and the client 2 may transmit the decryption number information to the server.
  • Client 1 and Client 2 may encrypt the decryption number information and transmit it to the server.
  • the server may determine the data usage of each of the client 1 and the client 2 based on the number of decryption information, and transmit the data usage of each of the client 1 and the client 2 to the billing system.
  • the billing system may generate billing information and transmit it to the server.
  • the server may generate the charging information based on the decoding count information.
  • Decryption number information related to the data usage of the P2P communication of the client 1 and the client 2 may be transmitted to the server, so that charging for the data usage of the P2P communication of the client 1 and the client 2 may be performed.
  • FIG. 2 is a flowchart illustrating another example of an operation of a communication system according to an exemplary embodiment.
  • the communication system includes a client 1, a server, and a client 2.
  • the intermediate unit described with reference to FIG. 1 may be included in the server.
  • Client 1 may send a communication request to the server (210).
  • the communication request may be a P2P communication request.
  • the server may send a communication request from client 1 to client 2 (211).
  • the client 2 may connect with the server (212). In other words, client 2 can connect to the server.
  • the server may generate an intermediate key (213).
  • the server may send the intermediate key to client 2 (214).
  • the server may send the intermediate key and the network address of client 2 to client 1 (215).
  • client 1's network address is A
  • client 2's network address is B.
  • Client 1 may transmit the intermediate key to the server (216).
  • the server receiving the intermediate key may secure an intermediate path corresponding to the intermediate key (217).
  • client 1 may send a speed test request to client 2 (218), and client 2 may send a test response to the speed test request to client 1 (219). Client 1 can check the response speed of Client 2. Similarly, client 2 may send a speed test request to client 1 (220) and may send a test response to client 2 driving speed test request to client 2 (221).
  • a P2P communication path may be established between client 1 and client 2.
  • Client 1 sends the shared key to client 2 (222).
  • Client 1 may encrypt data 1 with a shared key and transmit encrypted data 1 to client 2 (223).
  • Client 2 receives the encrypted data 1 and decrypts the encrypted data 1 using the shared key.
  • Client 2 updates the decryption count information.
  • Client 2 may send an acknowledgment to client 1 (224).
  • the client 1 When the client 1 receives the acknowledgment for the data 1, the client 1 may encrypt the data 2 with the shared key and transmit the encrypted data 2 to the client 2 (225).
  • the response speed of the client 2 may be lower than the response speed confirmed in the speed test or there may be no response from the client 2.
  • Client 1 may or may not receive an acknowledgment for encrypted data 2 later than the response rate identified in the rate test.
  • the client 1 may transmit the encrypted data 2 to the server through the intermediate path (227).
  • the server may store encrypted data 2 in a memory corresponding to each path or dedicated room.
  • client 2 may inform the server that the network address has changed (228).
  • the server may inform client 1 that the network address of client 2 has changed (229).
  • the client 2 can connect to the server using the intermediate key (230).
  • the server may send the encrypted data 2 to the client 2 (231).
  • Client 2 may receive the encrypted data 2 and decrypt it using the shared key.
  • the client 2 may update the decryption count information.
  • Client 2 may send an acknowledgment to client 1 (232).
  • the client 1 When the client 1 receives the acknowledgment for the data 2, the client 1 may transmit data 3 encrypted with the shared key to the client 2 (233). P2P communication through the P2P communication path A-B 'is started. When the client 2 receives the data 3, the client 2 may decrypt the data 3 with the shared key, and update the decryption number information. Client 2 may send an acknowledgment for data 3 to client 1 (234).
  • the client 2 may transmit data encrypted with the shared key to the client 1, and the client 1 may decrypt the encrypted data using the shared key.
  • Client 1 may update the decoding count information.
  • 3A to 3B are block diagrams illustrating a communication system according to an embodiment.
  • the client 310 includes a connector 311 and the client 320 includes a connector 321.
  • the server 330 includes a detector 331, a manager 332, and an intermediary 333.
  • connection unit 311 and the connection unit 321 may include a communication interface capable of P2P communication.
  • the client 310 may further include a processor (not shown) and a memory (not shown).
  • the processor may control the connection unit 311, and the memory may store intermediate keys.
  • the intermediate key may be stored in a secure call dongle which will be described later.
  • the client 320 may further include a processor (not shown) and a memory (not shown).
  • the processor controls the connection unit 321, and the memory may store intermediate keys.
  • the intermediate key may be stored in a secure call dongle which will be described later.
  • the detector 331, the manager 332, and the intermediary 333 may be implemented by a processor or a controller.
  • the connection unit 311 may transmit a P2P communication request to the server 330, and the server 330 may transmit a P2P communication request to the connection unit 321.
  • the connection unit 321 may access the intermediate unit 333.
  • the intermediate unit 333 may generate an intermediate key when the connection unit 321 connects.
  • the intermediary unit 333 may transmit the intermediary key to the connection unit 321.
  • the connection unit 321 may maintain a connection with the intermediate unit 333.
  • connection unit 321 may transmit the intermediate key to the management unit 332, and the management unit 332 may transmit the intermediate key and the network address of the counterpart client 330 to the connection unit 311.
  • the connection unit 311 may transmit the intermediate key to the intermediate unit 333 and may be connected to the intermediate unit 333 using the intermediate key.
  • the connection part 311 may maintain a connection with the intermediate part 333.
  • connection portion 311 and the connection portion 321 can maintain a connection to the intermediate portion 333 so that the intermediate path (or bypass path) having a connection relationship between the connection portion 311-the mediation 333-the connection portion 321 can be obtained. Can be secured.
  • Each path is a direct path between the connection part 311 and the connection part 321, that is, a path for preparing for disconnection of the P2P communication path.
  • the client 310 and the client 320 having the intermediate key can use the intermediate path, and other clients cannot use the intermediate path.
  • connection part 311 and the connection part 321 may be connected through a direct path.
  • the connection part 311 and the connection part 321 may be connected to each other through a P2P communication path A-B.
  • Client 310 and client 320 may share a shared key.
  • the client 310 may receive data encrypted with the shared key from the client 320 and decrypt the data using the shared key. The client 310 may update the decryption count information whenever decrypting. Similarly, the client 320 may receive data encrypted with the shared key from the client 310 and decrypt it using the shared key. The client 320 may update the decryption count information whenever decrypting.
  • the decryption number information of the client 310 may be encrypted and recorded in a memory and / or a secure call dongle which will be described later.
  • the decryption number information of the client 320 may be encrypted and recorded in a memory and / or a secure call dongle.
  • the network address of the client 320 may be changing.
  • the P2P communication path A-B may be disconnected, and the connection unit 321 may not receive data transmitted by the connection unit 311. Data may be missing. As a result, the connection unit 311 may not receive an acknowledgment for the data.
  • the connection unit 311 may transmit data to the intermediate unit 333.
  • the connection unit 321 may inform the sensing unit 331 that the network address of the client 320 has been changed.
  • the sensing unit 331 may inform the management unit 332 that the network address of the client 320 has changed, and the management unit 332 may inform the connection unit 311 that the network address of the client 320 has changed.
  • connection of the connection unit 321 to the intermediary unit 333 may be lost due to the change of the network address of the client 320.
  • the connection unit 321 may attempt to reconnect to the intermediate unit 333 by transmitting the intermediate key to the intermediate unit 333. Since the intermediate unit 333 has received the intermediate key corresponding to the client 320, the intermediate unit 333 may allow reconnection. When the connection unit 321 reconnects to the intermediate unit 333, the connection unit 321 may receive data from the intermediate unit 333.
  • the connector 321 may transmit an acknowledgment for data to the connector 311.
  • FIGS. 1A through 2 may be applied to FIG. 3A, and thus a detailed description thereof will be omitted.
  • the intermediary 333 may be physically distinguished from the server 330.
  • the intermediary unit 333 may be an independent device in the network.
  • FIGS. 1 to 3A may be applied to FIG. 3B, and thus detailed descriptions thereof will be omitted.
  • FIG. 4 is a diagram for describing an operation of a communication system, according to an exemplary embodiment.
  • the client is mapped to network address A, and the counterpart client is mapped to network address B.
  • Client and counterpart client communicate through P2P communication path A-B.
  • the client may transmit data 1 to the counterpart client 410, and the counterpart client may transmit an acknowledgment for data 1 to the client 411.
  • the network address of the counterpart client may be changed from B to B '(420).
  • the counterpart client may inform the server that its network address has changed (421), and the server may inform the client that the network address of the counterpart client has changed (422).
  • the client may transmit data 2 to the counterpart client mapped to the network address B '(423). That is, the client may transmit data 2 to the counterpart client through the P2P communication path A-B '.
  • the counterpart client may send an acknowledgment for data 2 to the client (424). Upon receiving the acknowledgment for data 2, the client may transmit data 3 to the counterpart client (425).
  • the network address of the counterpart client may be changed from B 'to B "(430).
  • the client may not receive an acknowledgment for data 3 from the counterpart client or may receive it late. If it is slow, the client may send data 3 intermediary 431.
  • the counterpart client may inform the server that the network address has changed (432), and the server can inform the client that the client's network address has changed. There is (433).
  • the partner client Since the partner client has an intermediate key, the partner client can access the intermediate unit using the intermediate key (434).
  • the intermediary may transmit data 3 to the counterpart client (435).
  • the counterpart client may send an acknowledgment for data 3 to the client (436).
  • the client may then transmit data to the counterpart client via the P2P communication path A-B ".
  • the P2P communication path is disconnected, so that client 1 and client 2 cannot maintain P2P communication continuously.
  • the client 1 and the client 2 may transmit and receive data with the intermediate unit by temporarily communicating with the intermediate unit. As a result, data loss can be prevented. In addition, network throughput may be improved.
  • FIG. 5 is a flowchart illustrating a method of operating a communication device, according to an exemplary embodiment.
  • the communication device may correspond to the intermediate unit described above.
  • the communication device generates an intermediate key corresponding to peer to peer (P2P) communication between a client and a counterpart client (510).
  • P2P peer to peer
  • the communication device transmits the intermediate key to the counterpart client (520).
  • the communication device secures an intermediate path corresponding to the intermediate key (530).
  • the communication device receives data through the intermediary path from the client whose network address of the counterpart client has changed and fails to receive an acknowledgment for the data sent to the counterpart client (540).
  • the client may transmit the data to the communication device.
  • the communication device transmits data to the counterpart client (550).
  • FIG. 6 is a flowchart illustrating a method of operating a server, according to an exemplary embodiment.
  • the server receives a P2P communication request from the client and transmits the P2P communication request to the counterpart client (610).
  • the server When the other client connects, the server generates an intermediate key and transmits the intermediate key to the other client and the client (620).
  • the server receives the intermediate key from the client to secure the intermediate path corresponding to the intermediate key (630).
  • the server receives the data through the intermediate path from the client that has not received the acknowledgment for the data transmitted to the counterpart client (640).
  • the server transmits data to the counterpart client (650).
  • 1A to 4 may be applied to the matters described with reference to FIG. 6, and thus detailed descriptions thereof will be omitted.
  • FIG. 7 is a flowchart illustrating an example of a method of operating a client, according to an exemplary embodiment.
  • the client transmits a P2P communication request to the server (710).
  • the client receives 720 from the server an intermediate key generated by the communication mediator for mediating communication between the client itself and the counterpart client and the network address of the counterpart client.
  • the communication mediator may correspond to the mediator described above.
  • the client connects to the communication media device using the media key (730).
  • the client transmits data to the counterpart client using the network address (740).
  • the data is transmitted to the communication mediator (750).
  • the counterpart client connects to the communication mediator using the media key with the changed network address and receives data from the communication mediator.
  • the client receives an acknowledgment for data from the counterpart client (760).
  • 1A to 4 may be applied to the matters described with reference to FIG. 7, and thus detailed description thereof will be omitted.
  • FIG. 8 is a flowchart illustrating another example of a method of operating a client, according to an exemplary embodiment.
  • FIG. 8 is a flowchart illustrating another example of a method of operating a client, according to an exemplary embodiment.
  • the client described with reference to FIG. 8 may correspond to client 2 of FIGS. 1A to 2.
  • a client when a client receives a P2P communication request of a requesting client from a server, the client accesses a communication medium device (810).
  • the requesting client may correspond to client 1 of FIGS. 1A-2.
  • the client receives an intermediate key from the communication intermediate device (820).
  • the communication mediator may correspond to the mediator described above.
  • the client reconnects to the communication media device using the media key (830).
  • the requesting client does not receive an acknowledgment for the data sent to the client. In this case, the requesting client transmits data to the communication medium device.
  • Communication mediated devices store data.
  • the client receives the data from the communication mediating device (840).
  • the client sends an acknowledgment for the data to the requesting client (850).
  • FIG. 9 is a flowchart illustrating session maintenance between a client and a server, according to an exemplary embodiment.
  • the client 910 connects to the server 911 (920).
  • the connection of the client 910 may be the initial connection.
  • the server 911 may receive identification information of the client 910 from the client 910, and may check a time value.
  • the time value may represent the time that the client 910 accesses the server 911.
  • the server 911 may encrypt the identification information and the time value of the client 910 using its E server ⁇ .
  • the server 911 may encrypt the identification information and the time value of the client 910 using the session key.
  • the server 911 may transmit a question to the client 910 (921).
  • the questions can be generated randomly.
  • the server 911 may transmit the encrypted identification information and the time value, that is, the E server ⁇ identification information, time value ⁇ , to the client 910 as a query. That is, the client 910 may receive the E server ⁇ identification information, time value ⁇ from the server 911.
  • the client 910 may transmit an answer to the server 911 (922). For example, the client 910 may encrypt the E server ⁇ identification information, time value ⁇ using E client ⁇ , which is its encryption method, and the E client ⁇ E server ⁇ identification information, time value ⁇ . In response, it may transmit to the server 911.
  • Server 911 may extract or acquire ⁇ E server identification information, the time value is generated from the client E ⁇ E server identification information, the time value ⁇ via the decoding corresponding to the client E ⁇ .
  • the server 911 may extract or obtain identification information and time value by decoding the E server ⁇ identification information, time value ⁇ .
  • the server 911 may check whether the answer corresponds to the question (923). For example, the server 911 may check whether the identification information and the time value obtained from the E client ⁇ E server ⁇ identification information, time value ⁇ correspond to the identification information and the confirmed time value received in step 910. have.
  • server 911 may maintain a communication session with client 910 (924).
  • the session can be, for example, a UDP session. If the answer does not correspond to the question, the server 911 may send a reconnection request to the client 910 (925).
  • the client 910 may transmit a P2P communication request to the server 911.
  • the client 910 may execute step 110 of FIG. 1A or step 210 of FIG. 2.
  • client 2 may connect to the server to inform the server that the network address has changed, and send its identification information to the server.
  • the server receives the identification information of the client 2 from a third party mapped to a network address different from that of the client 2 already known. In other words, the server does not know exactly whether the third party is Client 2 or a hacker.
  • the server can send the E server ⁇ client 2's identification information, time value ⁇ to the third party as a question, and the E client 2 ⁇ E server ⁇ identification information of client 2, time value ⁇ can be received as an answer.
  • the server uses the decryption technique corresponding to E client 2 ⁇ and the decryption technique corresponding to E server ⁇ to identify and time client 2's identification information from E client 2 ⁇ E server ⁇ identification information, time value ⁇ of E client 2. You can extract the value. That is, the answer corresponds to the question.
  • the server may confirm that the third is Client 2 and maintain a session with Client 2.
  • the server may inform that Client 2's network address has changed. In other words, the server can inform Client 1 that Client 2 has been mapped to a different network address.
  • a session identifier may be used to maintain a communication session. More specifically, when receiving a P2P communication request from the client 910, the server 911 may assign a session identifier to the client 910. The session identifier can be used to identify the client 910 on the network. The session identifier may be included in a header of a transmission unit of the client 910 (eg, a packet that the client 910 exchanges with the server 911, an intermediary, or a counterpart client). Even when the network address of the client 910 is changed, when the server 911 receives a transmission unit including a session identifier, the server 911 may maintain a communication session with the client 910.
  • FIGS. 10A and 10B are diagrams for describing another example of a method of operating a client, according to an exemplary embodiment.
  • FIG. 10A a flowchart of a method of operating a client is shown.
  • the client establishes a P2P communication path with the counterpart client (1010).
  • the client transmits the shared key to the counterpart client (1020).
  • the client receives the data encrypted with the shared key through the P2P communication path (1030).
  • the client decrypts the encrypted data using the shared key (1040).
  • the client updates the decryption number information related to charging for the data usage of the client (1050).
  • the client may transmit the updated decryption number information to the server.
  • the server may determine the data usage based on the updated number of decryption information. For example, the server may determine the data usage of the client by referring to a table in which a correspondence relationship between the number of decryption information and the data usage is recorded. The server can send the data usage to the charging system. The billing system may generate billing information using the data usage.
  • the server may generate the charging information based on the updated number of decryption information. For example, the server may generate charging information by referring to a table in which a correspondence relationship between decryption number information and charging information is recorded.
  • the server and / or billing system may check whether the data usage of the client exceeds a predetermined usage.
  • the predetermined usage amount may be a data quota corresponding to a communication plan subscribed to by a user of the client. That is, the predetermined usage amount may be a data quota allocated to the client.
  • the server and / or the billing system may generate guide information on data usage based on the verification result information.
  • the server and / or billing system may send the guide information to the client.
  • the guide information includes excess information indicating whether the data usage of the client has exceeded the predetermined usage, remaining information indicating available data capacity excluding the data usage among the predetermined usage, and bandwidth and quality for P2P communication. It may include at least one of the restriction information indicating whether there is a restriction on at least one of. For example, a predetermined usage amount is 2 GB (gigabyte) and data usage is 1 GB. The guide information may include remaining amount information indicating that 1 GB of data capacity remains. In addition, the guide information may include excess information indicating that data usage does not exceed a predetermined usage amount and / or restriction information indicating that bandwidth and quality for P2P communication are not limited. As another example, assume that the predetermined usage amount is 2 GB and the usage information is 2.5 GB.
  • the guide information may include excess information indicating that the usage information has exceeded a predetermined usage amount, remaining information indicating that there is no available data capacity, and restriction information indicating that there is a limitation on at least one of bandwidth and quality for P2P communication. have.
  • the guide information may include information that 0.5GB, which is a data usage exceeding a predetermined usage amount, will be additionally charged.
  • the client can visually display the guide information on the display.
  • the client may transmit a request for providing guide information to the server based on the user's input information, and the server may transmit the guide information to the client.
  • a client may share its assigned data quota with at least one other client. For example, assume that the data quota allocated to clients is 5GB. Clients can share 5GB of data quota with other clients. In other words, a client may form a shared group to share its data quota with shared clients in the shared group.
  • the client may receive information related to the data usage of the shared client from the server and / or the shared client, and update the decryption number information of the client based on the received information.
  • the received information may include, for example, updated decryption number information each time the shared client decrypts the encrypted data received through the P2P communication.
  • the client 1 sets up a P2P communication path with each of the clients 2 to 4 and receives data through each P2P communication path. More specifically, client 1 receives data a encrypted with shared key 1 from client 2, receives data b encrypted with shared key 2 from client 3, and receives data c encrypted with shared key 3 from client 4 do.
  • Each of the shared keys 1 to 3 may be identical to each other. Alternatively, the shared keys 1 to 3 may each be different. Alternatively, the shared keys 1 and 2 may be identical to each other and may be different from the shared key 3.
  • Client 1 can decrypt data a using shared key 1 and update decryption number information.
  • Client 1 can decrypt data b using shared key 2 and update the decryption count information.
  • the client 1 can decrypt the data c using the shared key 3 and update the decryption number information.
  • the decoding number information client 1 recorded before the client 1 performs P2P communication with each of the clients 2 to 4 is n.
  • the decryption count information client 1 may be updated to n + 3.
  • the decryption count information may be information related to billing for data usage or data usage of the client 1.
  • the client 1 may transmit its decryption number information to the server.
  • FIG. 11 illustrates a sharing of a data quota allocated to a client according to an exemplary embodiment.
  • the client 1110 may share its data quota with a sharing client in the sharing group 1120.
  • the sharing group 1120 may be formed based on the identifier. More specifically, an identifier is assigned to communication software that enables P2P communication of the client 1110. Communication software that enables P2P communication of clients 1121 and 1122 is assigned an identifier.
  • Client 1121 and client 1122 may display on the display a visual code (eg, a QR code) for registering client 1110 as a parent or master.
  • a visual code eg, a QR code
  • Each QR code may be, for example, an encoded key corresponding to each of client 1121 and client 1122.
  • the client 1110 may capture the visual code via optical means (eg, a camera) and extract a key from the captured QR code.
  • the client 1110 may send its identifier and key to the server, and the server may verify that the key is valid. For example, the server can check whether the number of available keys is zero. If the key is valid, the server may manage the client 1110 as the master or parent of the client 1121 and the client 1122, and the client 1121 and the client 1122 as slaves of the client 1110. Or it can be managed as a child.
  • the identifiers of the client 1121 and the client 1122 may be managed by grouping with the identifiers of the client 1110.
  • the server may also update the number of times the key is available.
  • client 1110 is a master and clients 1121 and 1122 are slaves.
  • Clients 1121 and 1122 may be defined as shared clients that can share the data quota assigned to client 1110.
  • the sharing clients 1121 and 1122 may receive the encrypted data by performing P2P communication.
  • the shared clients 1121 and 1122 may decrypt data using the shared key shared with the other party, and update the decryption number information.
  • the shared clients 1121 and 1122 may transmit the decryption number information to the server and / or the client 1110.
  • the client 1110 may receive information related to data usage of the shared clients 1121 and 1122, and may update its decryption number information based on the received information. For example, it is assumed that decryption number information of each of the shared client 1121 and the shared client 1122 is 100 and 200, respectively.
  • the client 1110 may receive decryption number information of the shared clients 1121 and 1122, and may add 300 to its decryption number information.
  • FIG. 12 is a block diagram illustrating an example of a client according to an exemplary embodiment.
  • the client 1200 includes a communication interface 1210 and a controller 1220.
  • the client 1200 includes a memory (not shown).
  • the memory stores communication software, and the controller 1220 executes the communication software.
  • an operation of the communication interface 1210 and an operation of the controller 12720 may be performed.
  • the communication interface 1210 establishes a peer to peer (P2P) communication path with a counterpart client.
  • the communication interface 1210 transmits a shared key to the counterpart client, and receives data encrypted with the shared key through a P2P communication path.
  • the controller 1220 decrypts the encrypted data using the shared key.
  • the controller 1220 updates decryption number information related to data usage of the client. Billing-based information can be generated via communication software.
  • the decryption number information may be stored in a memory and / or a secure call dongle.
  • FIG. 13 illustrates an example of a secure call dongle according to an exemplary embodiment.
  • FIG. 13 an example of a client 1300 and a secure call dongle 1310 is shown.
  • the secure call dongle 1310 may be detachable from the input / output interface of the client 1300.
  • Input and output interfaces include a micro USB port and an Apple® Lightning port.
  • the secure call dongle 1310 may be designed to be compatible with various input / output interfaces developed in the future.
  • the secure call dongle 1310 and the client 1300 may be connected through short-range wireless communication without physical contact.
  • Short-range wireless communication is, for example, Bluetooth, NFC, or Wi-Fi.
  • Near field communication is not limited to the above-described example.
  • the secure call dongle 1310 may include a certain amount of memory.
  • the memory may store communication software, a call history through the communication software, a messaging history, a message content, an attached file, and the like.
  • the secure call dongle 1310 may include a battery of a predetermined capacity. When the battery of the client 1300 is low, the secure call dongle 1310 may supply power to the client 1300 to allow a call for a predetermined time or more. Here, when the secure call dongle 1310 is connected to the client 1300 without physical contact, the secure call dongle 810 may wirelessly transmit power to the client 1300.
  • communication software When the secure call dongle 1310 is connected with the client 1300, communication software may be visually displayed on the display of the client 1300. As another example, when the secure call dongle 1310 is connected with the client 1300, communication software may be executed.
  • a secure call dongle 1310 may be distributed that includes a memory in which an identifier corresponding to the communication software is stored.
  • an identifier required for the secure call may be allocated to the communication software.
  • the secure call dongle 1310 may store decryption number information of the client 1300. For example, while the secure call dongle 1310 is connected with the client 1300, the client 1300 may receive the encrypted data by performing P2P communication, and update the decryption count information each time the data is decrypted. The secure call dongle 1310 may be stored.
  • the secure call dongle 1310 may store messages and / or contents transmitted and received through a chat room. Attributes are defined in data such as messages and / or content, so the data may or may not be moved out of the secure call dongle 1310.
  • the client 1300 may transmit a file stored in the secure call dongle 1310 to the outside only by obtaining a movement permission for the file from the original owner (or security manager) of the file.
  • the file may mean that an assigned identifier (where the identifier is an identifier assigned to the file) is recorded on the server, and the client 1300 indicates that the file is stored externally.
  • a message may be sent to the original owner (or security manager) 's client that it will be sent or moved. If the original owner (or security administrator) approves the transfer or movement of the file, the properties of the file may be overridden or modified. Accordingly, the file may be transmitted or moved outside the secure call dongle 1310.
  • the apparatus described above may be implemented as a hardware component, a software component, and / or a combination of hardware components and software components.
  • the devices and components described in the embodiments are, for example, processors, controllers, arithmetic logic units (ALUs), digital signal processors, microcomputers, field programmable gate arrays (FPGAs).
  • ALUs arithmetic logic units
  • FPGAs field programmable gate arrays
  • PLU programmable logic unit
  • the processing device may execute an operating system (OS) and one or more software applications running on the operating system.
  • the processing device may also access, store, manipulate, process, and generate data in response to the execution of the software.
  • processing device includes a plurality of processing elements and / or a plurality of types of processing elements. It can be seen that it may include.
  • the processing device may include a plurality of processors or one processor and one controller.
  • other processing configurations are possible, such as parallel processors.
  • the software may include a computer program, code, instructions, or a combination of one or more of the above, and configure the processing device to operate as desired, or process it independently or collectively. You can command the device.
  • Software and / or data may be any type of machine, component, physical device, virtual equipment, computer storage medium or device in order to be interpreted by or to provide instructions or data to the processing device. Or may be permanently or temporarily embodied in a signal wave to be transmitted.
  • the software may be distributed over networked computer systems so that they may be stored or executed in a distributed manner.
  • Software and data may be stored on one or more computer readable recording media.
  • the method according to the embodiment may be embodied in the form of program instructions that can be executed by various computer means and recorded in a computer readable medium.
  • the computer readable medium may include program instructions, data files, data structures, etc. alone or in combination.
  • the program instructions recorded on the media may be those specially designed and constructed for the purposes of the embodiments, or they may be of the kind well-known and available to those having skill in the computer software arts.
  • Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tape, optical media such as CD-ROMs, DVDs, and magnetic disks, such as floppy disks.
  • Examples of program instructions include not only machine code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like.
  • the hardware device described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé pour faire fonctionner un dispositif de communication. Un mode de réalisation comprend les étapes suivantes : génération d'une clé intermédiaire correspondant à une communication entre entités homologues (P2P) entre un client et un client de contrepartie; transmission de la clé intermédiaire au client de contrepartie; obtention d'un chemin intermédiaire correspondant à la clé intermédiaire; réception des données à travers le chemin intermédiaire de la part du client qui n'a pas reçu un accusé de réception pour les données transmises au client de contrepartie en raison d'un changement d'une adresse réseau du client de contrepartie; et transmission des données au client de contrepartie si le client de contrepartie accède à l'adresse de réseau modifiée en utilisant la clé intermédiaire.
PCT/KR2016/007027 2015-06-30 2016-06-30 Procédé de routage et entité de réseau mettant en œuvre ce procédé Ceased WO2017003215A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US15/740,811 US10681755B2 (en) 2015-06-30 2016-06-30 Routing method and network entity performing same
CN201680050078.1A CN108141721A (zh) 2015-06-30 2016-06-30 路由方法及执行此的网络实体

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
KR10-2015-0092951 2015-06-30
KR20150092951 2015-06-30
KR20150098354 2015-07-10
KR10-2015-0098354 2015-07-10
KR10-2016-0018413 2016-02-17
KR1020160018413A KR101785385B1 (ko) 2015-07-10 2016-02-17 네트워크 경로를 관리하는 방법 및 이를 수행하는 네트워크 엔티티
KR10-2016-0079956 2016-06-27
KR1020160079956A KR101888952B1 (ko) 2015-06-30 2016-06-27 클라이언트 및 클라이언트의 동작 방법

Publications (2)

Publication Number Publication Date
WO2017003215A1 true WO2017003215A1 (fr) 2017-01-05
WO2017003215A8 WO2017003215A8 (fr) 2017-12-28

Family

ID=57608587

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2016/007027 Ceased WO2017003215A1 (fr) 2015-06-30 2016-06-30 Procédé de routage et entité de réseau mettant en œuvre ce procédé

Country Status (1)

Country Link
WO (1) WO2017003215A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20030008952A (ko) * 2001-07-21 2003-01-29 주식회사 엠아이스트림 트리구조의 통신시스템 및 방법
US20090225986A1 (en) * 2008-03-06 2009-09-10 International Business Machines Corporation Non-Interactive Hierarchical Identity-Based Key-Agreement
WO2013048038A2 (fr) * 2011-09-26 2013-04-04 삼성에스디에스 주식회사 Système et procédé d'émission et de réception de messages d'homologue à homologue en utilisant une clé multimédia, et gestion de la clé multimédia
KR20150047554A (ko) * 2012-09-06 2015-05-04 코닌클리즈케 케이피엔 엔.브이. 장치간의 통신 세션을 확립하기 위한 방법
WO2015088296A1 (fr) * 2013-12-15 2015-06-18 삼성전자 주식회사 Procede de communication securise, et appareil et dispositif multimedia utilisant ce procede

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20030008952A (ko) * 2001-07-21 2003-01-29 주식회사 엠아이스트림 트리구조의 통신시스템 및 방법
US20090225986A1 (en) * 2008-03-06 2009-09-10 International Business Machines Corporation Non-Interactive Hierarchical Identity-Based Key-Agreement
WO2013048038A2 (fr) * 2011-09-26 2013-04-04 삼성에스디에스 주식회사 Système et procédé d'émission et de réception de messages d'homologue à homologue en utilisant une clé multimédia, et gestion de la clé multimédia
KR20150047554A (ko) * 2012-09-06 2015-05-04 코닌클리즈케 케이피엔 엔.브이. 장치간의 통신 세션을 확립하기 위한 방법
WO2015088296A1 (fr) * 2013-12-15 2015-06-18 삼성전자 주식회사 Procede de communication securise, et appareil et dispositif multimedia utilisant ce procede

Also Published As

Publication number Publication date
WO2017003215A8 (fr) 2017-12-28

Similar Documents

Publication Publication Date Title
WO2020190016A1 (fr) Procédé et dispositif permettant de fournir une authentification dans un système de traitement multimédia basé sur un réseau (nbmp)
WO2016024695A1 (fr) Procédé et appareil de téléchargement de profil de dispositifs de groupe
WO2020197221A1 (fr) Procédé de communication et dispositif de communication
WO2013025085A2 (fr) Appareil et procédé permettant de prendre en charge un nuage de famille dans un système informatique en nuage
WO2015016627A1 (fr) Procédé et dispositif permettant de connecter un seul dispositif ap parmi de multiples dispositifs ap dans le même réseau sur un terminal
WO2021040205A1 (fr) Dispositif électronique et procédé de transfert d'instruction de commande à un dispositif cible par un dispositif électronique
WO2015157942A1 (fr) Dispositif et procédé d'accès à un réseau sans fil
WO2022250500A1 (fr) Procédé et appareil pour configurer une adresse de commande d'accès au support (mac) pour une communication à bande ultra-large (uwb)
WO2016039576A2 (fr) Dispositif et procédé d'accès à une pluralité de réseaux dans un système de communications sans fil
WO2011155734A2 (fr) Procédé et dispositif de communication pour communiquer avec d'autres dispositifs
WO2016195199A1 (fr) Procédé de traitement de requête par un canal d'interrogation dans un système de communication sans fil et appareil associé
WO2015194836A1 (fr) Procédé et dispositif de partage de clé
WO2017007132A1 (fr) Procédé, appareil, et système de surveillance de session de communication de données chiffrées
WO2016013846A1 (fr) Procédé de traitement de message de demande dans un système de communications sans fil, et appareil associé
WO2022092918A1 (fr) Procédé et dispositif de paiement utilisant une communication à bande ultralarge (uwb)
WO2022245109A1 (fr) Procédé et dispositif pour réaliser une télémétrie de sécurité à bande ultralarge
WO2014171727A1 (fr) Appareil et procédé pour générer une hiérarchie de clés dans un réseau sans fil
WO2024136246A1 (fr) Système de commande d'accès au réseau et procédé associé
WO2023177238A1 (fr) Système de commande de connexion au réseau basé sur un contrôleur, et son procédé
WO2011037318A4 (fr) Procédé d'utilisation de droits à des contenus
WO2020153660A1 (fr) Dispositif et procédé de mise à jour d'un jeton d'immobilisateur dans un système de partage de clé numérique
WO2018110775A1 (fr) Appareil de gestion d'authentification de dispositif électronique
WO2022225298A1 (fr) Procédé et dispositif de paiement utilisant une communication à bande ultralarge (uwb)
WO2024136247A1 (fr) Système de commande de connexion réseau et procédé associé
WO2017003215A1 (fr) Procédé de routage et entité de réseau mettant en œuvre ce procédé

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

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15740811

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16818248

Country of ref document: EP

Kind code of ref document: A1