NB-IoT: 어떻게 작동하나요? 파트 3: SCEF – 운영자 서비스에 대한 단일 액세스 창구

기사 "NB-IoT: 어떻게 작동하나요? 2 부"에서는 NB-IoT 네트워크의 패킷 코어 아키텍처에 대해 이야기하면서 새로운 SCEF 노드의 등장을 언급했습니다. 세 번째 부분에서는 그것이 무엇이며 왜 필요한지 설명합니다.

M2M 서비스를 만들 때 애플리케이션 개발자는 다음과 같은 질문에 직면합니다.

• 장치를 식별하는 방법
• 어떤 확인 및 인증 알고리즘을 사용할지;
• 장치와 상호 작용하기 위해 선택할 전송 프로토콜
• 장치에 데이터를 안정적으로 전달하는 방법;
• 그들과 데이터를 교환하기 위한 규칙을 구성하고 설정하는 방법;
• 온라인으로 자신의 상태에 대한 정보를 모니터링하고 얻는 방법
• 여러 장치에 데이터를 동시에 전달하는 방법
• 한 장치에서 여러 클라이언트로 동시에 데이터를 보내는 방법
• 장치 관리를 위해 추가 운영자 서비스에 대한 통합 액세스를 얻는 방법.

이 문제를 해결하려면 기술적으로 "과중한" 독점적인 솔루션을 만들어야 하며, 이로 인해 인건비와 서비스 출시 시간이 늘어납니다. 이것이 새로운 SCEF 노드가 구출되는 곳입니다.

3GPP에서 정의한 대로 SCEF(서비스 능력 노출 기능)는 3GPP 네트워크 인터페이스가 API를 통해 제공하는 서비스와 기능을 안전하게 노출하는 기능을 갖춘 3GPP 아키텍처의 완전히 새로운 구성 요소입니다.

간단히 말해서, SCEF는 직관적이고 표준화된 API 인터페이스를 통해 NB-IoT 네트워크에서 M2M 장치를 관리하기 위한 운영자 서비스에 액세스할 수 있는 단일 창인 네트워크와 애플리케이션 서버(AS) 사이의 중개자입니다.

SCEF는 운영자 네트워크의 복잡성을 숨겨 애플리케이션 개발자가 장치와 상호 작용하기 위한 복잡한 장치별 메커니즘을 추상화할 수 있도록 합니다.

SCEF API는 네트워크 프로토콜을 애플리케이션 개발자에게 친숙한 API로 변환함으로써 새로운 서비스 생성을 촉진하고 출시 시간을 단축합니다. 새로운 노드에는 모바일 장치 식별/인증, 장치와 AS 간의 데이터 교환 규칙 정의, 애플리케이션 개발자가 이러한 기능을 구현할 필요성을 없애고 이러한 기능을 운영자의 어깨로 이동시키는 기능도 포함되어 있습니다.

SCEF는 애플리케이션 서버의 인증 및 권한 부여, UE 이동성 유지, 데이터 전송 및 장치 트리거링, 추가 서비스에 대한 액세스 및 운영자 네트워크 기능에 필요한 인터페이스를 다룹니다.

AS에는 8GPP에 의해 표준화된 API(HTTP/JSON)인 단일 T3 인터페이스가 있습니다. T8을 제외한 모든 인터페이스는 DIAMETER 프로토콜을 기반으로 작동합니다(그림 1).

T6a – SCEF와 MME 간의 인터페이스입니다. 이동성/세션 관리 절차, 비IP 데이터 전송, 모니터링 이벤트 제공 및 이에 대한 보고서 수신에 사용됩니다.

S6t – SCEF와 HSS 간의 인터페이스입니다. 가입자 인증, 애플리케이션 서버 승인, 외부 ID와 IMSI/MSISDN 조합 획득, 모니터링 이벤트 프로비저닝 및 이에 대한 보고서 수신에 필요합니다.

S6m/T4 – SCEF에서 HSS 및 SMS-C로의 인터페이스(3GPP는 NB-IoT 네트워크에서 장치 트리거링 및 SMS 전송에 사용되는 MTC-IWF 노드를 정의합니다. 그러나 모든 구현에서 이 노드의 기능은 SCEF이므로 회로의 단순화를 위해 별도로 고려하지 않겠습니다.) SMS 전송 및 SMS 센터와의 상호 작용을 위한 라우팅 정보를 얻는 데 사용됩니다.

T8 – SCEF와 애플리케이션 서버의 상호 작용을 위한 API 인터페이스입니다. 제어 명령과 트래픽 모두 이 인터페이스를 통해 전송됩니다.

*실제로는 더 많은 인터페이스가 있으며 여기에는 가장 기본적인 인터페이스만 나열되어 있습니다. 전체 목록은 3GPP 23.682(4.3.2 참조점 목록)에 나와 있습니다.

SCEF의 주요 기능과 서비스는 다음과 같습니다.

• SIM 카드 식별자(IMSI)를 외부 ID에 연결하는 단계;
• 비IP 트래픽 전송(Non-IP Data Delivery, NIDD);
• 외부 그룹 ID를 사용한 그룹 작업
• 확인을 통한 데이터 전송 모드 지원;
• MO(Mobile Originated) 및 MT(Mobile Terminate) 데이터 버퍼링;
• 장치 및 애플리케이션 서버의 인증 및 승인;
• 여러 AS가 하나의 UE의 데이터를 동시에 사용합니다.
• 특수 UE 상태 모니터링 기능(MONTE – 모니터링 이벤트) 지원
• 장치 트리거링;
• 비IP 데이터 로밍을 제공합니다.

AS와 SCEF 간의 상호작용의 기본 원리는 소위 방식을 기반으로 합니다. 구독. 특정 UE에 대한 SCEF 서비스에 접근해야 하는 경우, 애플리케이션 서버는 요청된 서비스의 특정 API에 명령을 보내 구독을 생성하고 이에 대한 응답으로 고유 식별자를 수신해야 합니다. 그 후에는 이 서비스 프레임워크 내에서 UE와의 모든 추가 작업 및 통신이 이 식별자를 사용하여 발생합니다.

외부 ID: 범용 장치 식별자

SCEF를 통해 작업할 때 AS와 장치 간의 상호 작용 방식에서 가장 중요한 변경 사항 중 하나는 범용 식별자의 등장입니다. 이제 기존 2G/3G/LTE 네트워크에서와 같이 전화번호(MSISDN)나 IP 주소 대신 애플리케이션 서버의 장치 식별자가 "외부 ID"가 됩니다. 이는 애플리케이션 개발자에게 친숙한 형식으로 표준에 의해 정의됩니다. @ "

개발자는 더 이상 장치 인증 알고리즘을 구현할 필요가 없으며 네트워크가 이 기능을 완전히 대신합니다. 외부 ID는 IMSI에 연결되어 있으며 개발자는 특정 외부 ID에 액세스할 때 특정 SIM 카드와 상호 작용하는지 확인할 수 있습니다. SIM 칩을 사용할 때 외부 ID가 특정 장치를 고유하게 식별하는 완전히 독특한 상황이 발생합니다!

또한 여러 외부 ID를 하나의 IMSI에 연결할 수 있습니다. 외부 ID가 특정 장치의 특정 서비스를 담당하는 특정 애플리케이션을 고유하게 식별하는 경우 훨씬 더 흥미로운 상황이 발생합니다.

그룹 식별자(개별 외부 ID 집합을 포함하는 외부 그룹 ID)도 나타납니다. 이제 SCEF에 대한 한 번의 요청으로 AS는 그룹 작업을 시작할 수 있습니다. 즉, 단일 논리 그룹에 통합된 여러 장치에 데이터 또는 제어 명령을 보낼 수 있습니다.

AS 개발자의 경우 새로운 장치 식별자로의 전환이 즉각적으로 이루어질 수 없기 때문에 SCEF는 표준 번호인 MSISDN을 통해 UE와의 AS 통신 가능성을 남겨 두었습니다.

Non-IP 트래픽 전송(Non-IP Data Delivery, NIDD)

NB-IoT에서는 소량의 데이터 전송을 위한 메커니즘 최적화의 일환으로 기존의 IPv4, IPv6, IPv4v6 등 PDN 유형 외에 비IP라는 또 다른 유형이 등장했습니다. 이 경우, 장치(UE)에는 IP 주소가 할당되지 않으며 IP 프로토콜을 사용하지 않고 데이터가 전송됩니다. 이러한 연결에 대한 트래픽은 클래식 - MME -> SGW -> PGW, 그리고 PtP 터널을 통해 AS(그림 2) 또는 SCEF(그림 3)를 사용하는 두 가지 방법으로 라우팅될 수 있습니다.

고전적인 방법은 IP 헤더가 없기 때문에 전송되는 패킷의 크기를 줄이는 것을 제외하고는 IP 트래픽에 비해 특별한 이점을 제공하지 않습니다. SCEF를 사용하면 여러 가지 새로운 가능성이 열리고 장치와의 상호 작용 절차가 크게 단순화됩니다.

SCEF를 통해 데이터를 전송할 때 기존 IP 트래픽에 비해 두 가지 매우 중요한 이점이 나타납니다.


외부 ID를 통해 기기에 MT 트래픽 전달

클래식 IP 장치에 메시지를 보내려면 AS가 해당 IP 주소를 알아야 합니다. 여기서 문제가 발생합니다. 장치는 일반적으로 등록 시 "회색" IP 주소를 수신하므로 회색 주소가 흰색으로 변환되는 NAT 노드를 통해 인터넷에 있는 애플리케이션 서버와 통신합니다. 회색과 흰색 IP 주소의 조합은 NAT 설정에 따라 제한된 시간 동안 지속됩니다. 평균적으로 TCP 또는 UDP의 경우 5분을 넘지 않습니다. 즉, XNUMX분 이내에 이 장치와 데이터 교환이 없으면 연결이 끊어지고 AS와의 세션이 시작된 화이트 주소에서 더 이상 장치에 액세스할 수 없게 됩니다. 몇 가지 해결책이 있습니다:

1. 심장박동을 활용하세요. 연결이 설정되면 장치는 몇 분마다 AS와 패킷을 교환해야 하므로 NAT 변환이 종료되는 것을 방지할 수 있습니다. 그러나 여기서는 에너지 효율성에 대해 이야기 할 수 없습니다.

2. 필요한 경우 매번 AS의 장치에 대한 패키지 가용성을 확인하고 업링크로 메시지를 보냅니다.

3. 애플리케이션 서버와 장치가 동일한 서브넷에 있는 개인 APN(VRF)을 생성하고 장치에 고정 IP 주소를 할당합니다. 작동하겠지만 수천, 수만 대의 장치에 대해 이야기할 때는 거의 불가능합니다.

4. 마지막으로 가장 적합한 옵션은 IPv6을 사용하는 것입니다. IPv6 주소는 인터넷에서 직접 액세스할 수 있으므로 NAT가 필요하지 않습니다. 그러나 이 경우에도 장치를 다시 등록하면 새로운 IPv6 주소를 받게 되며 더 이상 이전 IPvXNUMX 주소를 사용하여 액세스할 수 없습니다.

따라서 장치의 새로운 IP 주소를 보고하기 위해서는 장치 식별자가 포함된 일부 초기화 패킷을 서버에 전송해야 합니다. 그런 다음 에너지 효율에도 영향을 미치는 AS의 확인 패킷을 기다립니다.

이러한 방법은 장치의 자율성에 대한 엄격한 요구 사항이 없고 결과적으로 방송 시간 및 트래픽에 대한 제한이 없는 2G/3G/LTE 장치에 적합합니다. 이러한 방법은 에너지 소비가 높기 때문에 NB-IoT에는 적합하지 않습니다.

SCEF는 이 문제를 해결합니다. AS의 유일한 장치 식별자는 외부 ID이므로 AS는 특정 외부 ID에 대해 SCEF에 데이터 패킷을 보내기만 하면 되고 나머지는 SCEF가 처리합니다. 장치가 PSM 또는 eDRX 절전 모드에 있는 경우 장치를 사용할 수 있게 되면 데이터가 버퍼링되고 전달됩니다. 장치가 트래픽에 사용 가능한 경우 데이터가 즉시 전달됩니다. 경영팀도 마찬가지다.

AS는 언제든지 버퍼링된 메시지를 UE에게 회수하거나 새로운 메시지로 교체할 수 있습니다.

버퍼링 메커니즘은 UE에서 AS로 MO 데이터를 전송할 때도 사용될 수 있습니다. 예를 들어 AS 서버에서 유지 관리 작업이 진행 중인 경우와 같이 SCEF가 AS에 데이터를 즉시 전달할 수 없는 경우 이러한 패킷은 버퍼링되어 AS를 사용할 수 있게 되는 즉시 전달되도록 보장됩니다.

위에서 언급한 바와 같이 AS(및 NIDD는 서비스임)에 대한 특정 서비스 및 UE에 대한 액세스는 SCEF 측의 규칙 및 정책에 의해 규제되며, 이는 여러 AS가 한 UE의 데이터를 동시에 사용할 수 있는 고유한 가능성을 허용합니다. 저것들. 여러 AS가 하나의 UE에 가입한 경우 UE로부터 데이터를 수신한 후 SCEF는 이를 가입된 모든 AS에 보냅니다. 이는 특수 장치 집합의 생성자가 여러 클라이언트 간에 데이터를 공유하는 경우에 매우 적합합니다. 예를 들어, NB-IoT에서 실행되는 기상 관측소 네트워크를 생성하면 해당 기상 관측소의 데이터를 여러 서비스에 동시에 판매할 수 있습니다.

보장된 메시지 전달 메커니즘

Reliable Data Service는 TCP의 핸드셰이크와 같은 프로토콜 수준의 특수 알고리즘을 사용하지 않고 MO 및 MT 메시지의 전달을 보장하기 위한 메커니즘입니다. 이는 UE와 SCEF 간에 교환될 때 메시지의 서비스 부분에 특수 플래그를 포함하여 작동합니다. 트래픽을 전송할 때 이 메커니즘을 활성화할지 여부는 AS에 의해 결정됩니다.

메커니즘이 활성화되면 UE는 MO 트래픽의 전달을 보장해야 할 때 패킷의 오버헤드 부분에 특수 플래그를 포함합니다. 이러한 패킷을 수신하면 SCEF는 확인 응답으로 UE에 응답합니다. UE가 승인 패킷을 수신하지 못하면 SCEF를 향한 패킷이 재전송됩니다. MT 트래픽에서도 같은 일이 발생합니다.

장치 모니터링(이벤트 모니터링 - MONTE)

위에서 언급한 바와 같이, SCEF 기능에는 무엇보다도 소위 UE의 상태를 모니터링하는 기능이 포함됩니다. 장치 모니터링. 그리고 새로운 식별자와 데이터 전송 메커니즘이 기존 절차의 최적화(매우 심각하기는 하지만)라면 MONTE는 2G/3G/LTE 네트워크에서는 사용할 수 없는 완전히 새로운 기능입니다. MONTE를 사용하면 AS는 연결 상태, 통신 가용성, 위치, 로밍 상태 등과 같은 장치 매개변수를 모니터링할 수 있습니다. 각각에 대해서는 나중에 조금 더 자세히 이야기하겠습니다.

장치 또는 장치 그룹에 대한 모니터링 이벤트를 활성화해야 하는 경우 AS는 외부 ID 또는 외부 그룹 ID, AS 식별자, 모니터링과 같은 매개변수가 포함된 해당 API MONTE 명령을 SCEF로 전송하여 해당 서비스에 가입합니다. 유형, AS가 수신하려는 보고서 수. AS가 요청을 실행할 권한이 있는 경우 SCEF는 유형에 따라 HSS 또는 MME에 이벤트를 제공합니다(그림 4). 이벤트가 발생하면 MME나 HSS는 SCEF로 보고서를 생성하고 SCEF는 이를 AS로 보냅니다.

“특정 지역에 존재하는 UE 수”를 제외한 모든 이벤트의 프로비저닝은 HSS를 통해 이루어집니다. "IMSI-IMEI 연결 변경" 및 "로밍 상태"라는 두 가지 이벤트가 HSS에서 직접 추적되고 나머지는 MME의 HSS에 의해 제공됩니다.
이벤트는 일회성일 수도 있고 주기적일 수도 있으며 유형에 따라 결정됩니다.

이벤트에 대한 보고서 전송(보고)은 이벤트를 SCEF로 직접 추적하는 노드에 의해 수행됩니다(그림 5).

중요 사항 : 모니터링 이벤트는 SCEF를 통해 연결된 비 IP 장치와 MME-SGW-PGW를 통해 전통적인 방식으로 데이터를 전송하는 IP 장치 모두에 적용될 수 있습니다.

각 모니터링 이벤트를 자세히 살펴보겠습니다.

연결 끊김 — UE가 더 이상 데이터 트래픽이나 시그널링에 사용할 수 없음을 AS에 알립니다. 이 이벤트는 UE에 대한 "모바일 연결 타이머"가 MME에서 만료될 때 발생합니다. 이러한 유형의 모니터링에 대한 요청에서 AS는 "최대 감지 시간" 값을 표시할 수 있습니다. 이 시간 동안 UE가 어떤 활동도 표시하지 않으면 AS는 UE를 사용할 수 없다는 알림을 받고 그 이유를 알립니다. 어떤 이유로든 UE가 네트워크에 의해 강제로 제거된 경우에도 이 이벤트가 발생합니다.

* 장치가 아직 사용 가능하다는 사실을 네트워크에 알리기 위해 주기적으로 업데이트 절차인 TAU(추적 영역 업데이트)를 시작합니다. 이 절차의 빈도는 타이머 T3412 또는 (PSM의 경우 T3412_extended)을 사용하여 네트워크에 의해 설정되며, 그 값은 Attach 절차 또는 다음 TAU 동안 장치로 전송됩니다. 모바일 연결 타이머는 일반적으로 T3412보다 몇 분 더 깁니다. UE가 "Mobilereachability Timer"가 만료되기 전에 TAU를 수행하지 않은 경우 네트워크는 더 이상 도달할 수 없는 것으로 간주합니다.

UE 도달 가능성 – UE가 DL 트래픽 또는 SMS에 사용 가능하게 되는 시기를 나타냅니다. 이는 UE가 페이징에 사용 가능해지거나(eDRX 모드의 UE에 대해) UE가 ECM-CONNECTED 모드에 들어갈 때(PSM 또는 eDRX 모드에 있는 UE에 대해) 발생합니다. TAU를 만들거나 업링크 패킷을 보냅니다.

위치 보고 – 이러한 유형의 모니터링 이벤트를 통해 AS는 UE의 위치를 ​​쿼리할 수 있습니다. 현재 위치(Current Location) 또는 마지막으로 알려진 위치(Last Known Location, 장치가 마지막으로 TAU를 수행하거나 트래픽을 전송한 셀 ID로 결정됨)를 요청할 수 있으며 이는 PSM 또는 eDRX 절전 장치와 관련이 있습니다. 모드. "현재 위치"의 경우 AS는 기기의 위치가 변경될 때마다 MME가 AS에 알리는 반복 응답을 요청할 수 있습니다.

IMSI-IMEI 연관 변경 – 이 이벤트가 활성화되면 SCEF는 IMSI(SIM 카드 식별자)와 IMEI(장치 식별자) 조합의 변경 사항을 모니터링하기 시작합니다. 이벤트가 발생하면 AS에게 알립니다. 예정된 교체 작업 중에 외부 ID를 장치에 자동으로 다시 바인딩하는 데 사용하거나 장치 도난에 대한 식별자 역할을 할 수 있습니다.

로밍 상태 – 이 유형의 모니터링은 UE가 홈 네트워크에 있는지 또는 로밍 파트너의 네트워크에 있는지 확인하기 위해 AS에서 사용됩니다. 선택적으로 장치가 등록된 사업자의 PLMN(Public Land Mobile Network)이 전송될 수 있습니다.

통신 실패 — 이 유형의 모니터링은 무선 액세스 네트워크(S1-AP 프로토콜)에서 수신된 연결 손실 이유(해제 원인 코드)를 기반으로 AS에 장치와의 통신 실패를 알립니다. 이 이벤트는 통신이 실패한 이유를 확인하는 데 도움이 될 수 있습니다. 예를 들어 eNodeb가 과부하된 경우(무선 리소스를 사용할 수 없음) 또는 장치 자체의 오류(UE 손실과 무선 연결)로 인해 네트워크 문제로 인해 발생합니다.

DDN 실패 후 가용성 – 이 이벤트는 통신 실패 후 장치를 사용할 수 있게 되었음을 AS에 알립니다. 장치에 데이터를 전송해야 할 필요가 있을 때 사용할 수 있지만, UE가 네트워크의 알림(페이징)에 응답하지 않고 데이터가 전달되지 않아 이전 시도가 성공하지 못한 경우에 사용할 수 있습니다. 이러한 유형의 모니터링이 UE에 대해 요청된 경우 장치가 수신 통신을 하거나 TAU를 수행하거나 데이터를 업링크로 전송하자마자 AS는 장치를 사용할 수 있게 되었다는 알림을 받게 됩니다. DDN(다운링크 데이터 알림) 절차는 MME와 S/P-GW 간에 작동하므로 이러한 모니터링은 IP 장치에서만 가능합니다.

PDN 연결 상태 – 장치 상태(PDN 연결 상태)가 변경되면 연결(PDN 활성화) 또는 연결 끊김(PDN 삭제)을 AS에 알립니다. 이는 AS가 UE와의 통신을 시작하거나 그 반대로 통신이 더 이상 가능하지 않음을 이해하는 데 사용될 수 있습니다. 이러한 유형의 모니터링은 IP 및 비IP 장치에 사용할 수 있습니다.

지리적 영역에 존재하는 UE 수 – 이 유형의 모니터링은 AS가 특정 지리적 영역에 있는 UE 수를 결정하는 데 사용됩니다.

장치 트리거링)

2G/3G 네트워크에서 네트워크의 등록 절차는 3단계로 이루어졌습니다. 먼저 장치를 SGSN에 등록하고(연결 절차), 필요한 경우 PDP 컨텍스트를 활성화했습니다. 즉, 패킷 게이트웨이(GGSN)와의 연결입니다. 데이터를 전송합니다. 2G 네트워크에서는 이 두 절차가 순차적으로 발생했습니다. 장치는 데이터 전송이 필요한 순간을 기다리지 않고 연결 절차가 완료된 직후 PDP를 활성화했습니다. LTE에서는 이 두 절차를 하나로 통합했는데, 즉 Attach 시 기기가 즉시 eNodeB를 거쳐 MME-SGW-PGW로 PDN 연결(3G/XNUMXG의 PDP와 유사) 활성화를 요청했다.

NB-IoT에서는 연결 방법을 "PDN 없이 연결", 즉 UE가 PDN 연결을 설정하지 않고 연결하는 것으로 정의합니다. 이 경우 트래픽 전송은 불가능하며, SMS 수신 또는 발신만 가능합니다. 이러한 장치에 PDN을 활성화하고 AS에 연결하라는 명령을 보내기 위해 "장치 트리거링" 기능이 개발되었습니다.

AS로부터 그러한 UE를 연결하라는 명령을 수신하면 SCEF는 SMS 센터를 통해 장치에 제어 SMS 전송을 시작합니다. SMS를 수신하면 장치는 PDN을 활성화하고 AS에 연결하여 추가 명령을 받거나 데이터를 전송합니다.

SCEF에서 장치 구독이 만료되는 경우가 있을 수 있습니다. 예, 구독에는 운영자가 설정하거나 AS와 합의한 고유한 수명이 있습니다. 만료되면 PDN은 MME에서 비활성화되고 해당 장치는 AS에서 사용할 수 없게 됩니다. 이 경우 "장치 트리거링" 기능도 도움이 될 것입니다. AS로부터 새로운 데이터를 수신하면 SCEF는 장치 연결 상태를 파악하고 SMS 채널을 통해 데이터를 전달합니다.

결론

물론 SCEF의 기능은 위에서 설명한 서비스에 국한되지 않고 지속적으로 발전하고 확장되고 있습니다. 현재 SCEF에는 이미 XNUMX개 이상의 서비스가 표준화되어 있습니다. 이제 우리는 개발자가 요구하는 주요 기능에 대해서만 다루었으며 나머지 내용은 향후 기사에서 다루겠습니다.

바로 의문이 생깁니다. 이 "기적의" 노드에 대한 테스트 접근 권한을 어떻게 얻어서 가능한 경우를 미리 테스트하고 디버깅할 수 있을까요? 모든 것이 매우 간단합니다. 모든 개발자는 iot.info@mts.ru로 요청을 보낼 수 있으며, 연결 목적, 가능한 경우에 대한 설명, 그리고 연락을 위한 연락처 정보만 기재하면 됩니다.

때까지 우리는 다시 만날!

저자 :

• 융합 솔루션 및 멀티미디어 서비스 부서의 수석 전문가 Sergey Novikov 사노프,
• 융합 솔루션 및 멀티미디어 서비스 부서 전문가 Alexey Lapshin 멍청한

출처 : habr.com