IT자격증

오픈소스SW 라이선스의 특징

  - 라이선시는 해당 오픈소스SW를 자유롭게 사용할 수 있다.
  - 라이선시는 해당 오픈소스SW를 자유롭게 복제할 수 있으며,
    일정한 조건하에 재배포할 수 있다.
 - 라이선시는 해당 오픈소스SW를 자유롭게 수정하여 사용할 수 있으며, 
   일정한 조건하에 수정된 내용을 재배포할 수 있다.
 - 라이선시는 해당 오픈소스SW의 소소코드를 자유롭게 획득하고 접근할 수 있다.

라이선스별 내용

용어정리

구조적 방법론 (1970년대)

정보공학적 방법론 (1980년대)

객체지향 방법론 (1990년대)

CBD 방법론 (2000년대)

 - 재사용이 가능한 Component의 개발 또는 상용 컴포넌트들을 조합하여 어플리케이션 개발

RAD (Rapid Application Development)

- 조직이 전략적으로 중요한시스템을 빠르게 개발하면서도 개발비용을 줄이고 
   품질을 유지할 수 있게 해주는 방법론.
 - 제한된 범위의 단독시스템을 CASE를 사용하여 신속하게 개발하는 방법.
 - CAST Tool을 이용해서 고객과 같이 개발
 - 1~3개월 정도 소요
 - 위험이 낮은 Project에 적합
 - 단계 : JRP(분석) -> JAD(설계) -> 구축.운영
 - 필수요건 : ① SWAT
                  ② Database (Repository)
                  ③ Timebox (요구사항 관리)
                  ④ CASE ( 상위CASE - 요구사항 분석,설계
                                  중위CASE - 설계
                                  하위CASE - 소스코드)

RUP (Rational Unified Process)

UML을 기반으로 한 객체지향 소프트웨어 프로세스 모델
 - 예정된 일정과 예산에서 고객이 만족할 수 있는 소프트웨어 개발
 - Jacobson의 UseCase Driven 방법을 도입한 방법론이다.
 - 소프트웨어 개발의 전체 생명주기를 지원하는 프로젝트 FrameWork 이다.
 - 각 단계를 반복하면서 위험요소를 줄일 수 있다.
 - 반복을 하기 때문에 개발도중 요구사항 변경,환경변화등에 유연하게 대처가 가능
 - UseCase기반 , 아키텍쳐 중심 , 반복 점진적 개발 프로세스
 - 게발기간이 길고 대규모 시스템에 적합
단점 : 내용자체가 방대해서 처음 객체지향 방법론을 접하는 사람에게는 어렵다

                       * 인식,정련,구축,전이 단계는 각각 반복을 할 수 있다.

Clean Room Model

 - 시스템의 가장 핵심이 되는 부분을 최초 Increment(실행 가능한 프로토타입) 
   로 개발하여  사용자에게 피드백을 하여 새로운 요구를 끄집어 내거나 개발
   계획 자체를 다시 고쳐서 반복해서 증가분 소프트웨어를 개발시스템에 
   추가하여 가는 생각을 기초로 하고있다.
 - 소트프웨어를 정형적으로 명세화하고 여러 증분 (Increment)으로 나누어
   별도로 개발하고 검증하되 신뢰성을 결정하기 위해 통계적으로 테스트 한다.

1. 폭포수 모델

      - 개념 정립에서 구현까지 하향식 접근방법 (높은 추상화 단계 -> 낮은 추상화 단계)
      - 응용분야가 단순하고 잘 알고있는경우에 적합
      - 비전문가가 사용할 시스템 개발에 적합
      - 단계별 결과물이 명확해야 한다.
      - 설계와 코딩 및 테스트를 지연시킬 우려가 있다.
      - 시스템의 요구가 설계단계로 넘어가기전에 동결됨을 가정
     - 문서와 결과물 도출에 중점.
     -  단점 : 프로토타입과 재사용의 기회가 줄어든다
                 일정에 융통성이 없으며 이전단계로의 회귀,반복이 계속 된다면 소요자원이 계속 
                 증가할수 있다
                 최종단계가 가야지 결과물을 알수있다.
                 초기에 요구사항 정의가 어려움.
                 중요한 문제점의 발견이 늦어짐.
     - 용도 : 이미 잘알고 있는 문제나 연구중심의 소프트웨어 개발에 적합
                위험이 적은 프로젝트에 적합
                유사한 프로젝트 경험이 있는 경우
                요구사항이 명확히 정의되어 있는 경우


프로토타이핑 모델

      - 요구사항을 초기에 명세하기가 어려운 경우 적합 (요구사항이 모호함)
      - 프로토타입에는 사용자의 경험으로 가치있는 의견을 회수할 만한 기능만을 포함시킨다.
      - 예외처리, 회복, 표준이나 형식의 준수와 같은 것은 포함시키지 않는다.
      - 품질보다는 빠르게 만들어야 한다.
      - 장점 : 요구사항 도출이 용이.
                 시스템의 이해와 품질 향상
                 개발자와 사용자간 의사소통 원활
                 개발의 타당성 검증.
      - 단점 : 발주자가 프로토타입이 최종결과라 믿고 곧 소프트웨어가 개발될꺼라고 오해
                 폐기에 따른 비경제성
                 프로토타입이 전체시스템의 일부분임에도 불구하고 발주자가 개발일정 단축을 
                 요구할수 있어 품질을 저하시킬 수 있다.
               : 프로토타입이 과대선전되어 인수해야할 제품보다 더 많은 기능을 기대하게 된다.
               : 프로토타이핑 과정을 관리,통제 하기 어렵다
               : 중간과정을 점검할 수 있는 일정표와 산출물이 어렵다.
               : 발주자의 참여을 계획하는 것이 쉽지않다.             
      - 종류 : 실험적 프로타이핑 - 시제품 폐기
                 진화적 프로타이핑 - 나선형 모델


나선형 모델

      - 위험분석을 기반으로 한 반복개발
      - 선형모델의 체계적인 측면과 프로토타이핑의 반복적 특성을 결합시킨 형태의 모델
      - 계획수립 - 위험분석 - 개발 - 평가 
      - 대규모시스템을 개발하는데 적합
      - 각 확장단계에서 발생될 위험에 대한 이해와 대책이 가능하다.
      - 비선형적이며 반복적으로 개발이 진행되므로 소프트웨어 품질 중 강인성을 높일수 
       있는 방법이다.
      - 재정적, 기술적으로 위험부담이 큰 경우 위험분석을 해나가면서 시스템 발전
      - 요구사항이나 아키텍쳐를 이해하기 어렵거나, 근본적으로 성능에 문제가 되는 경우
     - 장점 : 정확한 사용자 요구사항 파악
                : 위험부담 감소
                : 품질확보
      - 단점 : 프로젝트 개발에 많은 시간 소요
                 프로젝트 관리에 어려움 
                 충분한 검증 미흡 (참조 사이트가 적음)


점증적 모델

      - 사용자 요구사항의 일부분 또는 제품의 일부분을 반복적으로 개발하여 최종제품을 
        완성하는 모델
         (폭포수모델 + 프로토타이핑 모델 + 나선형 모델)
      - 폭포수모델의 변형으로 증분을 따로 개발 후 통합하는 방법으로 포로토타입의 
        반복개념을 선형순차모델의  요소들에 결합시킨 것.
      - 프로토타이핑과 같이 반복적이나 각 점증이 갖는 제품 인도에 초점
      - Big Bang 릴리스를 보완하려는 방법이다.
      - 릴리스를 여러 번 나누어서 하면서 기능을 확장 개발해 나가는 방법
      ① 점증(증분)적(Incremental) 방법 : 기능별로 하나씩 개발하면서 릴리스 
      ② 반복(진화)적(Iterative) 방법 : 처음부터 전체기능을 개발하되 릴리스할때마다 
                                                그 기능을을 더 완벽히 개발
      - 장점 : 릴리스할때마다 사용자로부터 피드백을을 받아 사용자의 요구사항을
                 빠르게 반영할 수 있다.
               : 증분을 정확히 계획하고, 릴리스한다는 점에서 진화적 모형과는 다르며
              , 고객에게 모든 증분을
               릴리스하고 고객의 우선순위를 고려한다는 점에서 agile 방법론과 비슷하다.


V 모델

      - 폭포수모델에 시스템검증과 테스트 작업을 강조한 것이다.
      - 폭포수모형은 문서와 결과물에 중점을 두는 반면, V모델은 작업과 결과의 
         검증에 초점을 둔다,.
      - 장점 : 모든 단계에 확인과 검증 과정이 있어 오류를 줄일 수 있다
      - 단점 : 생명주기의 반복을 허용하지 않아 변경을 다루기가 쉽지않다.
                 작업이 종료되고 리뷰 후에는 관련된 결과물이 동결된다.
     - 적합 : 높은 신뢰성이 필요한 응용분야 (의료제어시스템, 원전제어시스템...)
                요구의 명세가 확실하여 개발하는 동안 변경이 없는경우에만 적합

대칭키 암호화

누군가에게 비밀스러운 내용을 전달하고 싶을 때 제일 간편한 방법은 작성자 즉 송신자가 직접
그 문서를 들고 수신자에게 전달해주면 된다.. 중간에 다른 전달자가 없으니깐 유출될 일도 
없겠죠.. 하지만 매번 직접 전달한다는 건 현대 사회에서는 당연히 불가능하겠져..
따라서 중간 전달자 (사람이던 기계이던 통신이던 네트워크이던..) 를 통해서 전달을 할 수 밖에
없는데 이런 경우  방법은 문서내용을 암호화해서 전달하고 수신자는 받은 문서를 복호화해서
내용을 확인하게 함으로써 중간에 문서를 강탈 당하더라도 내용은 암호화되어 있어서 
확인이 불가능할 것이다. 단 여기서의 문제점은 문서를 암호화 할때 사용한 키값을 수신자와
송신자가 각각 알고 있어야 한다는 점이다..  그래서 이 키를 전달하는 방법에 대해서도 다양하
해결책이 나오기도 하는데..이러한 암호화와 복호화를 동일한 키로 하는 방식을 '대칭키' 암호화
방식이라고 한다..

공개키 암호화

대칭키 암호화 방식의 약점은 키를 전달하는 과정에서 키를 분실하거나, 키를 가진 사람을 납치하는
방식 등으로 암호를 쉽게 풀어버릴 수 있다. 또, 키를 만들고 이를 전달하는 과정에서 발생하는
물리적 시간과 비용이 들면서 비효율적인 방식이라는 지적까지 나왔다.
이를 ‘키 분배 문제’라고 하는데, 이 문제를 해결하기 위해 ‘공개키 방식(=비대칭키 방식)’이
등장했다 
공개키 방식은 암호화할 때 사용하 키와 복호화할때 사용하는 키가 서로 다른 게 특징이다.
이러한 두개의 다른 키를 생성하는 방식으로 제일 가장 많이 쓰이는 방식이 소인수분해를
이용해 만든 RSA라는 공개키가 대표적인 암호화방식이다.. 1과 자신 이외에는 다른 약수가
없는 소수 두 개를 곱하고, 그 곱을 원래의 소수로 분해하는 방식으로 계산하기가 어려우며
시간도 많이 소요된다. 
하지만 안전하다고 굳게 믿었던 RSA 공개키의 보안은 최근 포털사이트와 은행 사이트 등에서
대규모 개인정보 유출사건이 터지면서 그 안전성이 위협을 받기 시작했다.


양자암호통신

공개키 암호화 방식중 RSA 공개키 방식은 수학적인 알고리즘에 의해 그 계산이 어렵다는 거지
불가능하다는 건 아니다. 즉 시간이 오래 걸려서 그렇지 언젠가는 그 소인수분해 문제를
풀수 있다는 것이다. 
1979년 개발된 최초의 RSA방식인 RSA-129는 당시 428비트의 키를 사용했는데. 당시엔 이
암호기술을 해독하기 위해 40,000조 년(年)이 걸린다고 알려졌지만. 이후 컴퓨터 기술이
비약적으로 발달하면서 1994년에 이르러 3개월로 단축되었다. 
결국 공개키 암호화 방식도 해킹의 위험으로부터 완전하게 벗어날 수 없기 때문에
새로운 암호키 분배방식이 필요하게 되었고 그래서 나온것이 양자암호키분배 방식이다.
양자암호키분배 방식의 가장 큰 특징은 양자의 중첩현상이 이용된다는 것이다.
일반 디지털 방식은 아시는바와 같이 0 과 1로 구성되어 있는데 양자암호키분배에서는
큐비트(QBit : Quantum bit) 를 사용한다. 즉 ‘0’과 ‘1’뿐만 아니라 ‘0’과 ‘1’을 동시에 가질
수 있어 겹치기 상태의 양자가 존재할 수 있다는 의미로서.(양자의 중첩) 이를 통해
제 3자가 전송 중인 양자의 정확한 정보를 취득하지 못하도록 방지할 수 있게 되는 것이다. 
또한 양자는 동일한 양자 상태를 복제할 수 없고, 한 번 측정한 후에는 측정 전의 상태로 
되돌릴 수 없는 특징이 있고. 이는 양자의 중첩성과 함께 양자암호통신의 안전성을 "
뒷받침하는 특징이라고 할수있다.
또하나의 가장 큰 특징은 도청자가 키의 정보를 탈취하기 위해 양자상태를 측정하고 나면,
양자상태가 바뀌기 때문에 해킹 시도 여부를 바로 알수 있다.

소프트웨어 안전성 분석의 필요성

소프트웨어의 규모가 커지고,복잡해지고, SW가 우리 생활 전반을 관리.지원.통제.조종하는 
영역이 날로 커지고 있지만 소프트웨어의 기능적 실패(Failure)를 발생시키는 위험(Hazard)
요소를 파악하고 사전 예방하는 것이 어려워지고 있다. 
이런 기능적 실패는 곧 대형사고로도 이어질수 있는데.. 예를 들면 안전 필수 시스템
(자율주행자동차, 원자력, 항공, 철도)에서의 기능적 사고는 소프트웨어적 문제를 넘어서
인명피해, 환경오염 등으로 이어지므로 기능적 실패 방지를 위해 예산과 인력 투입과 더불어
, SW의 안전성 분석 노력이 필요하다.


소프트웨어 안전성 분석의 개념

정의	시스템이 만족해야 할 안전성을 만족하는지 확인하는 활동 - 수용 또는 허용 가능한 위험성을 분류하고 설계, 제작 및 운영 단계에서 각종 안전    기능 또는 안전대책을 마련하여 위험성 크기를 줄이는 활동
목적	위험 식별, 위험 영향분석, 위험 원인 분석 - 분석 기법에 따라 한 가지 이상의 목적을 달성할 수 있기 때문에 목적에 따라 기법    선택
특징	① 귀납적〮◌연역적 방식 구분 : 위험과 위험의 원인을 도출하는 방법으로 구분 ② 상향식〮◌하향식 기법 구분 : 안전성 분석 수행 시 시스템을 바라보는 관점으로 구분 ③ 정성적〮◌정량적 결과 : 정성적은 도출이 쉽고 비용 절감, 정량적은 객관적이지만 복잡 ④ 분석시기, 분석가의 전문성 요구정도 : 사용 시기, 적용 대상, 분석 범위 등의 결정

                        < 출처 : 118회 정보관리기술사 모임 - 두드림 >



소프트웨어 안전성 분석 기법 소개

FTA (Fault Tree Analysis)

● 정의
- 특정 사고에 대한 연역적 해석을 통해 사건 사고의 원인 파악 및 설비결함, 작업 실수 등을
  발견 및 분석하는 기법
- 시스템의 기능과 고장에 대한 정보를 트리 구조로 제공
- 위험이 발생할 원인들을 분석할 수는 있으나, 위험을 찾아내는 기법은 아님.
- 항공,전자공학,원자력 등 다양한 분야에서 사용되고 있음
-  Root에 의도하지 않은 이벤트를 두고, 이를 발생시킬 수 있는  
   잠재적인  faulty event 또는 normal mode를 노드(node)로 표현
   하고 이것들은 and/or 를 사용해 시각화해서 보여주는 방식.
● 장점 : 개발의 모든 단계에서 사용가능함.

FMEA (Failure Mode and Effects Analysis)

●정의
- 컴포넌트(서브시스템) 자체에 고장발생 원인이 개입되는 것을 피하기 위한 기법이다.
  그래서 주로 분석/설계단계에서 고장발생원인을 사전에 제거하기 위한 목적으로 활용
- 고장 발생의 원인 및 중대 사고에 영향을 미치는 직접적인 원인인 서브시스템이나
  컴포넌트의 잠재적 고장 유형을 분석하는 기법 
- 심각도/발생도/검출도를 통해 고장으로 인한 시스템 영향 정량적 분석 
- 분석 결과에 따라 우선순위(RPN)을 부여하여 대응방안 수립
- 존재하고 있는 잠재적인 고장, 문제, 오류들이 사용자단까지 가기전에
  찾고(Identify), 정의하고(define), 제거하는(eliminate) 방식
- 먼저 모든 컴포넌트를 리스트형태로 정의하고, 각각의 고장모드(Failure Mode) 가
  영향을 미칠(Effects Analysis) 모든 컴포넌트, 시스템을 정의하고 각각의 고장모드의
  가능성과 심각성을 개선하는 단계로 진행

HAZOP (Hazard and Operability Analysis)

●정의
이 방법은 위험과 시스템운영상의 위협요소를 조사하는 기법이다.
기본적으로 시스템을 검토하고 잠재적인 위험을 찾는 것이 목적이며
브레인스토밍 단계에서 Guide Word를 이용한다는 특징이 있다.
- 시스템의 기능요건과 같은 매개번수와 가이드워드의 조합을 통해서 예상치 못한 
  동작과 그에 따른 영향을 분석하는 기법
- 도출된 행위가 시스템의 안전에 어떤 영향을 미칠수 있는 지 분석

- 보통 공장설비 프로세스에 존재하는 해저드(Hazard)와 운용상의 문제점
  (Operability Problems)을 찾아내는 정성적 분석 기법이다.
- HAZOP 분석은 시스템의 원래 의도한 설계와 차이가 있는 변이(deviations)를
  일련의 가이드워드(guidewords)를 활용하여 체계적으로 식별해 낸다

● HAZOP 분석 절차

 1) 분석대상 노드(Node) 선정
     - 어떤 프로세스상의 주요 변화가 발생하여 Hazard 와 운영상의 문제점이 발생
       할 가능성이 있는 프로세스의 한 부분을 말한다.
        ex) 액체온도가 변경되는 열교환기,  압력증가가 발생하는 펌프시스템

 2) 프로세스 파라미터 선정
     - 위험요인을 가진 시스템 구성요소의 물리적 특성
        ex) 온도,압력,

 3) 가이드워드(Guide word) 적용
     - 가이드워드는 분석 팀 멤버들이 프로세스 파라미터의 가능한 변이(deviations)를
       생각(상상)해 내는데 도움이 되는 짤막한 단어/문구들이다.
     - 가이드워드의 역할은 일련의 표준 질문을 프로세스 파라미터에 반복적으로
       적용하여 정상 조건으로부터 벗어나는 변이(deviations)를 체계적이고 일관성 있게
       도출하도록 해주는 것이다
     ex) 가이드워드

 4) 의도한 정상 설계에서 벗어나는 변이(deviations) 식별

• 가이드워드를 선정된 프로세스 파라미터에 적용하여 발생 가능한 변이(deviation)를
  찾는다.
  예를 들어 가이드워드 "No"가 파라미터 "flow"에 적용되면 "no flow" 라는 하나의
  deviation이 생성됨
• 아래와 같이 가이드워드와 프로세스 파라미터를 조합하는 매트릭스를 활용한다.
• 모든 가이드워드+파라미터조합이 의미 있는 것은 아니므로 매트릭스 상의
  빈 칸이 존재(분석이 필요 없는 경우)

 5) 변이를 초래하는 원인(causes) 파악

• 변이(deviation)가 발생하는 이유를 찾는다. 특정 변이를 초래하는 원인(causes)이
  한 가지 이상일 수도 있다.
• 발생 가능성이 지나치게 낮은 원인은 분석 팀의 판단에 따라 리스트에서 제외될
  수도 있다.
• 원인의 유형으로 크게 세 가지가 있다.
  - 사람 에러(Human error): 오퍼레이터, 설계가, 제조자, 기타 관련 작업자의 행위로
                                     인해 심각한 결과를 초래하는 위험이 발생
  - 장비 오류(Equipment failure): 기계적, 구조적, 운용상의 결함으로 인해 위험 발생
  - 외부 요인(External events): 외부 요인이 노드 운용에 영향을 주어 위험을 발생시킴
                                       (예, 정전, 수도 공급 중단, 날씨, 지진, 유관 노드의 장애 등)

 6) 변이로 인한 결과(consequences) 파악

     - 변이 발생에 따른 결과(피해, 문제점)를 파악한다.
       즉, 해당 변이가 시설 셧다운이나 제품 품질 저하 같은 프로세스 해저드(process hazards)
       와 운용 문제(operability problems)를 야기하는지 분석한다.
     - 변이의 영향은 안전성(safety), 환경(environmental), 경제성(economic) 측면에서 따져볼
        수 있다.

 7) 변이의 안전책(Safeguards) 고려

 8) HAZOP 분석 프로세스 반복 및 결과 보고서 작성

<발췌 : https://grapevine9700.tistory.com/216 >

소프트웨어를 개발하는 프로그래머라면 누구나 Refactoring 의 필요성을 공감하지만
실제 Refactoring을 하는 건 솔직히 엄두가 안난다.. 왜냐.. 괜히 잘 돌아가는 프로그램을
건드렸다가 에러라도 나면 어쩌나 하는 두려움이 들기 때문이다.
처음부터 코딩을 할때 어떤 코딩 Rule을 지키면서 한다면 그나마 refactoring 할 이유가
적어지지만 실제 코딩을 하다보면 결국 소스가 흔히 말하는 지저분하게 될수 밖에 없다.
중복되는 소스, 하나의 Function에 많은 기능을 구현, 캡슐화 대신 직접 멤버변수 참조 등
의 코딩 (Code Smell) 을 하게 된다는 말이다..

간단하게 Refactoring의 사례를 살펴보면 다음과 같아.
 - 기능변화 없이 중복제거, 단순화, 유연성 추가
   1.Method 정의 - 지나치게 긴 Method 를 분리
                       - 지나치게  긴 문장을 Method를 사용하여 단순화
   2.위치이동 - Method난 변수 위치를 적절한 Class로 이동
   3.캡슐화 - 멤버변수를 Get/Set 사용하여 캡슐화
   4.조건문 단순화 - 긴 조건문을 분할하거나 method 화 하여 단순화
   5.이름변경 - 이해하기 쉬운 이름으로 변경
   6.Indentation - 가독성이 있는 Indent로 재포맷


Refactoring 정의 및 개념

1. 원래 기능은 유지하면서 낮은 가독성, 중복된 로직, 확장 제한적 코드 등 
   (코드 스멜, Code Smell)을 제거함으로써 SW 내부 구조를 개선하여 코드 품질을 향상시키는
   SW 개선 기법
2. 외부 기능을 변경하지 않으면서 내부 구조를 개선하는 방법으로, Refactoring을 할 때는 기능을
   추가해서는 안 되고, 단지 코드의 구조에만 신경을 써야 한다.

Refactoring 대상 , Code Smell 종류

리펙토링(Refactoring) 주요 기법

Zigbee

ZigBee는 저속 전송 속도와 근거리 통신을 위해 ZigBee Alliance에서 개발한 무선 네트워크 기술인데
, 작은 크기로 전력 소모량이 적고 값이 싸 홈 네트워크 등 유비쿼터스 구축 솔루션으로 각광받고 있으며 
지능형 홈 네트워크, 빌딩등의 근거리 통신 시장과 산업용 기기 자동화, 물류, 휴먼 인터페이스, 
텔레매틱스, 환경 모니터링, 군사 등에 활용된다.

ZigBee 프로토콜은 
   ① 물리 계층,
   ② 미디어 액세스 제어(MAC) 계층,
   ③ 네트워크 계층,
   ④ 어플리케이션 계층
으로 이루어져 있다. ZigBee의 물리 계층과 MAC 계층은 IEEE 802.15.4 표준에 정의되어 있으며, 
그 외의 프로토콜 스택은 ZigBee 사양에 정의되어 있다. IEEE 802.15.4 초기 버전에서 유럽은 868MHz 
대역에서 20kbps를, 미국은 915MHz에서 40kbps를 지원하였다.

ZigBee 네트워크 계층은 트리 구조와 메쉬 구조를 위한 라우팅과 어드레싱를 지원하고 있으며, 
어플리케이션 프로파일로는 ZigBee Home Automation Public Profile과 ZigBee Smart Energy Profile이 
대표적으로 사용된다. 또 새로운 ZigBee 사양인 RF4CE는 가전의 원격 제어를 위한 솔루션과 스타 
토폴로지를 위한 간단한 네트워크 스택을 정의하고 있는데, RF4CE는 2.4GHz의 주파수 대역을
사용하고 AES-128을 이용한 보안을 제공한다.

Z-Wave

Z-Wave는 ZenSys가 주축이 된 Z-Wave Alliance에서 제정한 홈오토메이션 무선 전송 방식이며, 
Z-Wave의 주목적은 무선 네트워크에서 하나 이상의 노드들과 제어 유니트 사이에서 신뢰성 있는 
통신을 제공하는 것이다. 
Z-Wave는 물리 계층, 미디어 액세스 제어(MAC) 계층, 전송 계층, 라우팅 계층, 그리고 어플리케이션 계층
으로 구성되어 있으며, 900MHz 대역(유럽 : 869MHz, 미국 : 908MHz)과 2.4GHz 대역을 사용하면서 
9.6kbps, 40kbps, 그리고 200kbps의 속도를 제공한다.
Z-Wave 기술은 장치 간 통신을 위해 콘트롤러와 슬레이브의 두 가지 장치를 정의하는데, 
콘트롤러는 슬레이브에서 명령을 전송하며, 슬레이브는 명령에 대한 응답을 하거나 명령을 수행하는 
무선 센서 네트워크 기반의 IoT 기술 기능을 한다. Z-Wave의 라우팅 계층은 소스 라우팅 기반의 
라우팅을 지원한다

INSTEON

SmartLabs에서 개발한 INSTEON은 무선 기술을 활용하여 조명 스위치를 연결하는 기술로, 
RF 링크와 AC-전원 링크 간 메쉬 네트워크 토폴로지를 구성하여 작은 구역에서 장치 간 
통신을 실현한다. 
INSTEON 기술은 904MHz 대역에서 동작하며, 38.4 kbps 데이터 전송 속도를 제공한다. 
INSTEON의 디바이스들은 전송자의 역할, 수신자의 역할, 혹은 중계자의 역할을 수행할 수 있으며, 
동일한 구간에 위치하지 않은 디바이스들 간의 통신은 시간 구간 동기화 방법을 이용한 
멀티-홉 라우팅을 사용하여 가능하게 한다.

6LoWPAN  (IPv6 over Low Power WPAN)

비IP 네트워크 기술을 구현하고 있는 전통적 센서 노드 구조는 싱크 노드(Sink Node)를 통해 
인터넷과 연결되어 정보를 공유할 수가 있다. 이를 위해, 센서 노드는 6LoWPAN 같은 기술을 
적용할 필요가 있다. 
6LoWPAN(IPv6 over Low power WPAN)은 IEEE 802.15.43를 PHY/MAC으로 하는 저전력 WPAN상에 
IPv6를 탑재하여 기존 IP네트워크에 연결하는 기술이며, IPv6 기술로 인해 다양한 스마트 디바이스와 
센서 디바이스들이 IP 기반의 네트워크에 연결이 게이트웨이와 같은 중간 장치 없이 가능하게 되었다

Weightless

white space 무선 대역을 사용하는 사물 간 통신 기술이다. 
Weightless 통신 기술은 최근 몇 년 동안 급증하는 사물 통신의 요구 사항을 만족하기 위해 제안된
것으로 저비용,초저전력, 광역 통신, 신뢰성, 보안, 다수의 사물 단말 지원, 브로드캐스팅, small data burst 
등을 지원하는 기술을 포함하고 있다. 
이 같은 기능들을 지원하기 위하여 BPSK, QPSK, 16-QAM 등의 변조 기술을 사용하고 고속의 다운링
크는 500kbps~16Mbps, 저속의 다운링크는 2.5Kbps~500Kbps 속도를 지원한다.


D2D 통신 (Device to Device)

기지국, 무선접속 공유기(AP) 등의 네트워크 인프라를 거치지 않고 근거리에서 서로 다른 기기와 
통신하는 기술을 말한다.
여기에는 UPnP(Universal Plug and Play) DPWS(Device Profile for Web Services)
, WiFi Direct 등이 있으며, 모든 사물을 통신 주체로 하는 ‘M2M/IoT’ 기술에 포함되지만 범위가
무선통신이 가능한 기기간의 통신에 국한되어 있다.
대표적인 D2D 기술로는 모바일 블루투스를 들 수 있으며, 블루투스를 통해 자신의 스마트폰과
타인의 스마트폰을 연결했을 때 사진이나 데이터 자료 등과 같은 콘텐츠가 기기 간에 전송되는 
것과 같은 기술이다.

Beamforming (Spatial Filtering)

신호처리 기술로 안테나에서 전파를 원하는 특정 방향으로 전송/수신되는 직진 지향성을 
갖는 전파를 만들어내는 기술로 공간적으로 멀티플랙싱(공간분할 다중화)을 가능하게 하여 각
 안테나별로 위상정보를 조정하여 주변의 간섭을 제거하여 성능을 높이는 기술이다. 
이 기술은 실용화 되어 802.11ad 에 채택되었고, 이동전화망 2G,3G,4G,LTE에서도 사용중이다.

Beacon

 - 블루투스나 인간이 들을 수 없는 2.4GHz 비가청영역의 주파수를 이용해서 단말과 정보를 
   주고받는 기술로서
 - 일정한 주기로 전송되는 비지향성 단속형 신호를 사용하며
 - 근거리 저전력에 적합한 기술이다.
 - 주로 저전력 블루투스 (BLE : Bluetooth Low Energy) 4.0 장치 브로드 캐스팅을 이용한 
   근거리 저전력 기술
 - BLE 신호와 연동해 GPS정보 등 다양한 정보를 송수신하는 무선통신기술