KR20220010594A

KR20220010594A - 멀티캐스트 및 유니캐스트 매체 액세스 제어(mac) 주소 할당프로토콜(mumaap)

Info

Publication number: KR20220010594A
Application number: KR1020217034601A
Authority: KR
Inventors: 안토니오 데 라 올리바; 로버트 쥐. 가즈다
Original assignee: 인터디지탈 패튼 홀딩스, 인크
Priority date: 2019-04-25
Filing date: 2020-04-23
Publication date: 2022-01-25
Also published as: WO2020219693A1; EP3959858A1; US20240056413A1; CN113728606A; US20220224671A1; TW202228430A; TW202046695A; US11792154B2; CN113728606B

Abstract

멀티캐스트 및 유니캐스트 MAC 주소 할당 프로토콜(multicast and unicast MAC address assignment protocol; MUMAAP)에 대한 방법 및 장치가 여기에서 설명된다. 제1 노드는, 제2 노드의 유니캐스트 MAC 주소 또는 제2 노드와 연관된 멀티캐스트 MAC 주소에 기초하여, 제1 MAC 주소 또는 제1 범위의 MAC 주소를 포함할 수 있는 발견 메시지(discover message)를 제2 노드에 송신할 수 있다. 제1 노드는 제2 범위의 MAC 주소를 갖는 제안 메시지(offer message)를 수신할 수 있다. 제1 노드가 수신된 제2 범위의 MAC 주소들 중에서 제2 MAC 주소를 선택하면, 제1 노드는, 제2 MAC 주소 또는 제2 범위의 MAC 주소가 제1 노드에 할당됨을 표시하는 요청 메시지를 송신할 수 있다. 제1 노드는, 제2 MAC 주소 또는 제2 범위의 MAC 주소가 제1 노드에 할당됨을 표시하는 확인 응답 메시지(acknowledge message)를 수신할 수 있다.

Description

멀티캐스트 및 유니캐스트 매체 액세스 제어(MAC) 주소 할당 프로토콜(MUMAAP)

관련 출원에 대한 교차 참조

본 출원은 2019년 4월 25일에 출원된 미국 가출원 제62/838,687호의 이익을 주장하며, 그 내용은 여기에 참조로 포함된다.

IEEE 802.1CQ는 IEEE 802 네트워크에서 48 비트 및 64 비트 주소를 로컬로 고유하게 할당하기 위한 프로토콜, 절차 및 관리 객체를 지정하는 표준이다. 구체적으로, IEEE 802.1CQ는 모든 IEEE 802 액세스 기술(예컨대, IEEE 802.11, IEEE 802.3 등)에 대해 IEEE 802c에 정의된 구조화된 로컬 주소 계획(structured local address plan; SLAP)의 종단국(end-stations)에 유니캐스트 및 멀티캐스트 MAC 주소를 로컬로 할당하기 위해 계층 2 프로토콜을 연구하고 있다. 그러나, 예를 들어, IEEE 1722 MAC 주소 획득 프로토콜과 같은 현재 계층 2 프로토콜은 MAC 주소의 임의의 사전 구성 또는 사전 할당 없이 종단국에 대한 MAC 주소 할당을 지원하지 않는다. 따라서, IEEE 802.1CQ의 요건을 충족하려면 사전 구성이나 할당 없이 유니캐스트 및 멀티캐스트 MAC 주소를 할당하기 위한 프로토콜이 필요하다.

멀티캐스트 및 유니캐스트 MAC 주소 할당 프로토콜(multicast and unicast MAC address assignment protocol; MUMAAP)에 대한 방법 및 장치가 여기에서 설명된다. 예를 들어, 유선 또는 무선 네트워크의 제1 노드는 제2 노드에, 제2 노드의 유니캐스트 MAC 주소 또는 제2 노드와 연관된 멀티캐스트 MAC 주소에 기초하여, 제1 MAC 주소 또는 제1 범위의 MAC 주소를 포함하거나 포함하지 않을 수 있는 발견 메시지(discover message)를 송신할 수 있다. 발견 메시지가 제1 MAC 주소 또는 제1 범위의 MAC 주소를 포함하는 경우, 제1 MAC 주소 또는 제1 범위의 MAC 주소는 MUMAAP를 사용하여 제1 노드에 할당된 이전 MAC 주소 또는 주소 범위에 기초하여 결정될 수 있다. 그 다음, 제1 노드는 제1 노드에 할당될 수 있는 제2 범위의 MAC 주소를 갖는 제안 메시지(offer message)를 제2 노드로부터 수신할 수 있다. 제2 범위의 MAC 주소는 유니캐스트 MAC 주소의 범위 또는 멀티캐스트 주소의 범위를 포함할 수 있고, 제2 노드와 연관된 MAC 주소 풀(address pool), 제1 MAC 주소 또는 제1 범위의 MAC 주소 중 적어도 하나에 기초하여 제2 노드에 의해 결정될 수 있다. 제1 노드가 수신된 제2 범위의 MAC 주소들 중에서 제2 MAC 주소를 선택하면, 제1 노드는, 제2 MAC 주소 또는 제2 범위의 MAC 주소가 제1 범위에 할당됨을 나타내는 요청 메시지(request message)를 제2 노드에 송신할 수 있다. 선택된 제2 MAC 주소는 유니캐스트 MAC 주소 또는 멀티캐스트 MAC 주소일 수 있고, 제1 MAC 주소와 동일하거나 또는 제1 범위의 MAC 주소 내에 있을 수 있다. 그 후, 제1 노드는, 제2 MAC 주소 또는 제2 범위의 MAC 주소가 제1 노드에 할당됨을 나타내는 확인 응답 메시지(acknowledge message)를 제2 노드로부터 수신할 수 있다. 제1 노드는 미리 구성된 초기 MAC 주소를 갖거나 갖지 않는 클라이언트일 수 있고, 제2 노드는 서버일 수 있다.

첨부 도면과 함께 예로서 주어진 다음의 설명으로부터 보다 상세한 이해가 이루어질 수 있으며, 도면에서 유사한 참조 번호는 유사한 요소를 나타낸다.
도 1a는 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 통신 시스템을 도시하는 시스템도이다.
도 1b는 실시예에 따라 도 1a에 도시된 통신 시스템 내에서 사용될 수 있는 예시적인 무선 송수신 유닛(wireless transmit/receive unit; WTRU)을 도시하는 시스템도이다.
도 1c는 실시예에 따라 도 1a에서 예시되는 통신 시스템 내에서 사용될 수 있는 예시적인 무선 액세스 네트워크(radio access network; RAN) 및 예시적인 코어 네트워크(core network; CN)를 도시하는 시스템도이다.
도 1d는 실시예에 따라 도 1a에 도시된 통신 시스템 내에서 사용될 수 있는 추가의 예시적인 RAN 및 추가의 예시적인 CN을 도시하는 시스템도이다.
도 2는 멀티캐스트 및 유니캐스트 MAC 주소 할당 프로토콜(multicast and unicast MAC address assignment protocol; MUMAAP)이 구현되는 예시적인 통신 시스템을 도시하는 시스템도이다.
도 3은 예시적인 MUMAAP 절차를 도시하는 도면이다.

도 1a는 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 통신 시스템(100)을 도시하는 도면이다. 통신 시스템(100)은 예를 들어, 음성, 데이터, 비디오, 메시징, 브로드캐스트 등과 같은 콘텐츠를 다수의 무선 사용자에게 제공하는 다중 액세스 시스템일 수 있다. 통신 시스템(100)은 다수의 무선 사용자가 무선 대역폭을 포함하는 시스템 자원들의 공유를 통해 그러한 콘텐츠에 액세스하는 것을 가능하게 할 수 있다. 예를 들어, 통신 시스템들(100)은 CDMA(code division multiple access), TDMA(time division multiple access), FDMA(frequency division multiple access), OFDMA(orthogonal FDMA), SC-FDMA(single-carrier FDMA), ZT-UW-DFT-S-OFDM(zero-tail unique-word discrete Fourier transform Spread OFDM), UW-OFDM(unique word OFDM), 자원 블록 필터링된 OFDM, FBMC(filter bank multicarrier) 등과 같은 하나 이상의 채널 액세스 방법을 사용할 수 있다.

도 1a에서 도시되는 바와 같이, 통신 시스템(100)은 무선 송수신 유닛(WTRU)(102a, 102b, 102c, 102d), 무선 액세스 네트워크(radio access network; RAN)(104), 코어 네트워크(CN)(106), 공중 교환 전화망(public switched telephone network; PSTN)(108), 인터넷(110), 및 다른 네트워크(112)를 포함할 수도 있지만, 개시된 실시예는 임의의 수의 WTRU, 기지국(base station), 네트워크, 및/또는 네트워크 요소를 고려한다는 것이 인식될 것이다. WTRU들(102a, 102b, 102c, 102d) 각각은 무선 환경에서 동작하고 그리고/또는 통신하도록 구성된 임의의 유형의 디바이스일 수 있다. 예로서, WTRU들(102a, 102b, 102c, 102d) - 이들 중 임의의 것은 "스테이션(station)" 또는 노드라고 지칭될 수 있음 - 은 무선 신호들을 송신 및/또는 수신하도록 구성될 수 있고, 사용자 장비(user equipment; UE), 이동국, 고정 또는 이동 가입자 유닛, 네트워크 노드, 노드, 클라이언트, 가입 기반 유닛, 페이저, 셀룰러 전화, PDA(personal digital assistant), 스마트폰, 랩톱, 넷북, 개인용 컴퓨터, 무선 센서, 핫스폿 또는 Mi-Fi 디바이스, 사물 인터넷(Internet of Things; IoT) 디바이스, 시계 또는 다른 웨어러블, HMD(head-mounted display), 차량, 드론, 의료 디바이스 및 애플리케이션들(예컨대, 원격 수술), 산업 디바이스 및 애플리케이션들(예컨대, 산업 및/또는 자동화된 프로세싱 체인 상황들에서 동작하는 로봇 및/또는 다른 무선 디바이스들), 가전 디바이스, 상업 및/또는 산업 무선 네트워크들 상에서 동작하는 디바이스 등을 포함할 수 있다. WTRU들(102a, 102b, 102c, 및 102d) 중 임의의 것은 UE, 노드, 또는 클라이언트로 교환가능하게 지칭될 수 있다.

통신 시스템들(100)은 또한 기지국(114a) 및/또는 기지국(114b)을 포함할 수 있다. 기지국들(114a, 114b) 각각은 예를 들어, CN(106), 인터넷(110), 및/또는 다른 네트워크들(112)과 같은 하나 이상의 통신 네트워크에 대한 액세스를 용이하게 하기 위해 WTRU들(102a, 102b, 102c, 102d) 중 적어도 하나와 무선으로 인터페이싱하도록 구성된 임의의 유형의 디바이스일 수 있다. 예로서, 기지국들(114a, 114b)은 BTS(base transceiver station), NodeB, eNode B(eNB), 홈 노드 B, 홈 eNode B, 예를 들어, gNode B(gNB)와 같은 차세대 NodeB, 사이트 제어기(site controller), 액세스 포인트(access point; AP), 네트워크 노드, 노드, 서버, 무선 라우터 등일 수 있다. 기지국들(114a, 114b)은 단일 요소로서 각각 묘사되지만, 기지국들(114a, 114b)은 임의 수의 상호접속된 기지국들 및/또는 네트워크 요소들을 포함할 수 있다는 것을 알 것이다. 기지국(114a, 114b)은 노드 또는 서버로서 상호교환가능하게 지칭될 수 있다.

기지국(114a)은 RAN(104)의 일부일 수 있고, RAN(104)은 기지국 제어기(base station controller; BSC), 무선 네트워크 제어기(radio network controller; RNC), 릴레이 노드 등과 같은 다른 기지국 및/또는 네트워크 요소(도시 생략됨)를 또한 포함할 수 있다. 기지국(114a) 및/또는 기지국(114b)은 셀(도시되지 않음)이라고 지칭될 수 있는 하나 이상의 반송파 주파수 상에서 무선 신호들을 송신 및/또는 수신하도록 구성될 수 있다. 이러한 주파수들은 면허 스펙트럼 및 무면허 스펙트럼 또는 면허 스펙트럼과 무면허 스펙트럼의 조합 내에 있을 수 있다. 셀은 비교적 고정될 수 있거나 시간 경과에 따라 변할 수 있는 특정 지리 영역에 대한 무선 서비스를 위한 커버리지를 제공할 수 있다. 셀은 셀 섹터로 더 분할될 수 있다. 예를 들면, 기지국(114a)과 연관된 셀은 3개의 섹터로 분할될 수도 있다. 따라서, 하나의 실시예에서, 기지국(114a)은 3개의 송수신기, 즉, 셀의 각각의 섹터에 대해 하나의 송수신기를 포함할 수 있다. 실시예에서, 기지국(114a)은 MIMO(multiple-input multiple-output) 기술을 사용할 수 있고, 셀의 섹터마다 다수의 송수신기를 사용할 수 있다. 예를 들어, 신호들을 원하는 공간 방향들로 송신 및/또는 수신하기 위해 빔포밍(beamforming)이 사용될 수 있다.

기지국들(114a, 114b)은 임의의 적절한 무선 통신 링크(예컨대, RF(radio frequency), 마이크로파, 센티미터파, 마이크로미터파, IR(infrared), UV(ultraviolet), 가시광 등)일 수 있는 에어 인터페이스(116)를 통해 WTRU들(102a, 102b, 102c, 102d) 중 하나 이상과 통신할 수 있다. 에어 인터페이스(116)는 임의의 적절한 RAT(radio access technology)를 사용하여 확립될 수 있다.

더 구체적으로는, 위에서 언급된 바와 같이, 통신 시스템(100)은 다중 액세스 시스템일 수 있고 예를 들어, CDMA, TDMA, FDMA, OFDMA, SC-FDMA 등과 같은 하나 이상의 채널 액세스 방식을 활용할 수도 있다. 예를 들면, RAN(104) 내의 기지국(114a) 및 WTRU(102a, 102b, 102c)는, 광대역 CDMA(wideband CDMA; WCDMA)를 사용하여 무선 인터페이스(116)를 확립할 수 있는, 범용 이동 통신 시스템(Universal Mobile Telecommunications System; UMTS) 지상 무선 액세스(Terrestrial Radio Access)(UTRA)와 같은 무선 기술을 구현할 수 있다. WCDMA는 예를 들어, HSPA(High-Speed Packet Access) 및/또는 HSPA+(Evolved HSPA)와 같은 통신 프로토콜들을 포함할 수 있다. HSPA는 고속 다운링크(DL) 패킷 액세스(HSDPA) 및/또는 고속 업링크(UL) 패킷 액세스(HSUPA)를 포함할 수 있다.

실시예에서, 기지국(114a) 및 WTRU들(102a, 102b, 102c)은 예를 들어, LTE(Long Term Evolution) 및/또는 LTE-A(LTE-Advanced) 및/또는 LTE-A Pro(LTE-Advanced Pro)를 사용하여 에어 인터페이스(116)를 확립할 수 있는 E-UTRA(Evolved UMTS Terrestrial Radio Access)와 같은 무선 기술을 구현할 수 있다.

실시예에서, 기지국(114a) 및 WTRU들(102a, 102b, 102c)은 NR을 사용하여 에어 인터페이스(116)를 확립할 수 있는 NR 무선 액세스와 같은 무선 기술을 구현할 수 있다.

실시예에서, 기지국(114a) 및 WTRU들(102a, 102b, 102c)은 다수의 무선 액세스 기술을 구현할 수 있다. 예를 들어, 기지국(114a) 및 WTRU들(102a, 102b, 102c)은 예를 들어, 이중 접속성(dual connectivity; DC) 원리들을 사용하여 LTE 무선 액세스 및 NR 무선 액세스를 함께 구현할 수 있다. 따라서, WTRU들(102a, 102b, 102c)에 의해 사용되는 에어 인터페이스는 다수의 유형의 무선 액세스 기술들 및/또는 다수의 유형의 기지국들(예컨대, eNB 및 gNB)로/로부터 송신되는 송신물들에 의해 특성화될 수 있다.

다른 실시예에서, 기지국(114a) 및 WTRU들(102a, 102b, 102c)은 예를 들어, IEEE 802.11(즉, WiFi(Wireless Fidelity)), IEEE 802.16(즉, WiMAX(Worldwide Interoperability for Microwave Access)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, IS -2000(Interim Standard 2000), IS-95(Interim Standard 95), IS-856(Interim Standard 856), GSM(Global System for Mobile communications), EDGE(Enhanced Data rates for GSM Evolution), GERAN(GSM EDGE) 등과 같은 무선 기술들을 구현할 수 있다.

도 1a의 기지국(114b)은 예를 들어, 무선 라우터, 홈 Node B, 홈 eNode B, 또는 액세스 포인트일 수 있고, 예를 들어, 사업장, 집, 차량, 캠퍼스, 산업 시설, (예컨대, 드론들에 의한 사용을 위한) 에어 코리도(air corridor), 도로 등과 같은 국지화된 영역에서의 무선 접속성을 용이하게 하기 위해 임의의 적절한 RAT를 사용할 수 있다. 하나의 실시예에서, 기지국(114b) 및 WTRU(102c, 102d)는 무선 근거리 통신망(wireless local area network; WLAN)을 확립하기 위해 예를 들어, IEEE 802.11과 같은 무선 기술을 구현할 수 있다. 또 다른 실시예에서, 기지국(114b) 및 WTRU(102c, 102d)는 무선 사설 영역 네트워크(wireless personal area network; WPAN)를 확립하기 위해 예를 들어, IEEE 802.15와 같은 무선 기술을 구현할 수 있다. 또 다른 실시예에서, 기지국(114b) 및 WTRU들(102c, 102d)은 피코셀 또는 펨토셀을 확립하기 위해 셀룰러 기반 RAT(예컨대, WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR 등)를 사용할 수 있다. 도 1a에 도시된 바와 같이, 기지국(114b)은 인터넷(110)에 대한 직접 접속을 가질 수 있다. 따라서, 기지국(114b)은 CN(106)을 통해 인터넷(110)에 액세스하도록 요구되지 않을 수 있다.

RAN(104)은 음성, 데이터, 애플리케이션들, 및/또는 VoIP(voice over internet protocol) 서비스들을 WTRU들(102a, 102b, 102c, 102d) 중 하나 이상에 제공하도록 구성된 임의의 유형의 네트워크일 수 있는 CN(106)과 통신할 수 있다. 데이터는 예를 들어, 상이한 처리량 요건들, 레이턴시 요건들, 에러 허용 한계 요건들, 신뢰성 요건들, 데이터 처리량 요건들, 이동성 요건들 등과 같은 다양한 서비스 품질(quality of service; QoS) 요건들을 가질 수 있다. CN(106)은 호출 제어, 과금 서비스들, 이동 위치 기반 서비스들, 선불 통화, 인터넷 접속성, 비디오 배포 등을 제공하고 그리고/또는 예를 들어, 사용자 인증과 같은 하이 레벨 보안 기능들을 수행할 수 있다. 도 1a에 도시되진 않지만, RAN(104) 및/또는 CN(106)은, RAN(104)과 동일한 RAT 또는 상이한 RAT를 활용하는 다른 RAN과 직접 또는 간접 통신할 수 있음이 이해될 것이다. 예를 들어, NR 무선 기술을 사용하는 것일 수 있는 RAN(104)에 대한 접속에 더하여, CN(106)은 또한 GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, 또는 WiFi 무선 기술을 사용하여 또 다른 RAN(도시되지 않음)과 통신할 수 있다.

CN(106)은 또한 WTRU들(102a, 102b, 102c, 102d)이 PSTN(108), 인터넷(110), 및/또는 다른 네트워크들(112)에 액세스하기 위한 게이트웨이로서 역할을 할 수 있다. PSTN(108)은 POTS(plain old telephone service)를 제공하는 회선 교환 전화 네트워크들을 포함할 수 있다. 인터넷(110)은, 예를 들어, TCP/IP(transmission control protocol/internet protocol; 송신 제어 프로토콜/인터넷 프로토콜) 일군(suite)에서의 TCP, 사용자 데이터그램 프로토콜(user datagram protocol; UDP) 및 IP와 같은 공통 통신 프로토콜을 사용하는 상호접속된 컴퓨터 네트워크 및 디바이스의 글로벌 시스템을 포함할 수 있다. 네트워크들(112)은 다른 서비스 제공자들에 의해 소유되고 그리고/또는 운영되는 유선 및/또는 무선 통신 네트워크들을 포함할 수 있다. 예를 들어, 네트워크들(112)은 RAN(104)과 동일한 RAT 또는 상이한 RAT를 사용할 수 있는 하나 이상의 RAN에 접속된 또 다른 CN을 포함할 수 있다.

통신 시스템(100) 내의 WTRU들(102a, 102b, 102c, 102d) 중 일부 또는 전부는 다중-모드 능력들을 포함할 수 있다(예컨대, WTRU들(102a, 102b, 102c, 102d)은 상이한 무선 링크들을 통해 상이한 무선 네트워크들과 통신하기 위해 다수의 송수신기를 포함할 수 있다). 예를 들어, 도 1a에 도시된 WTRU(102c)는 셀룰러 기반 무선 기술을 사용할 수 있는 기지국(114a) 및 IEEE 802 무선 기술을 사용할 수 있는 기지국(114b)과 통신하도록 구성될 수 있다.

도 1b는 예시적인 WTRU(102)를 도시하는 시스템 도면이다. 도 1b에 도시된 바와 같이, WTRU(102)는 특히 프로세서(118), 송수신기(120), 송수신 요소(122), 스피커/마이크로폰(124), 키패드(126), 디스플레이/터치패드(128), 비착탈식 메모리(130), 착탈식 메모리(132), 전원(134), GPS(global positioning system) 칩셋(136), 및/또는 다른 주변기기들(138)을 포함할 수 있다. WTRU(102)는 한 실시예와 여전히 부합하면서 전술된 요소들의 임의의 부조합(sub-combination)을 포함할 수 있다는 것이 인식될 것이다.

프로세서(118)는 범용 프로세서, 특수 목적 프로세서, 전통적인 프로세서, DSP(digital signal processor), 복수의 마이크로프로세서, DSP 코어와 연관된 하나 이상의 마이크로프로세서, 제어기, 마이크로컨트롤러, ASIC(Application Specific Integrated Circuit), FPGA(Field Programmable Gate Arrays), 임의의 다른 유형의 IC, 상태 머신 등일 수 있다. 프로세서(118)는 WTRU(102)가 무선 환경에서 동작할 수 있게 하는 신호 코딩, 데이터 프로세싱, 전력 제어, 입출력 프로세싱, 및/또는 임의의 다른 기능을 수행할 수 있다. 프로세서(118)는, 송수신 요소(122)에 결합될 수 있는 송수신기(120)에 결합될 수 있다. 도 1b는 프로세서(118) 및 송수신기(120)를 별개의 컴포넌트들로서 도시하지만, 프로세서(118) 및 송수신기(120)는 전자 패키지 또는 칩 내에 함께 통합될 수 있다는 것을 알 것이다.

송수신 요소(122)는 에어 인터페이스(116)를 통해 기지국(예컨대, 기지국(114a))으로 신호들을 송신하거나 이 기지국으로부터 신호들을 수신하도록 구성될 수 있다. 예를 들면, 하나의 실시예에서, 송수신 요소(122)는 RF 신호를 송신하도록 그리고/또는 수신하도록 구성되는 안테나일 수 있다. 실시예에서, 송수신 요소(122)는, 예를 들면, IR, UV, 또는 가시광 신호를 송신 및/또는 수신하도록 구성되는 방출기(emitter)/검출기(detector)일 수 있다. 또 다른 실시예에서, 송수신 요소(122)는 RF 및 광 신호 둘 다를 송신하도록 그리고/또는 수신하도록 구성될 수 있다. 송수신 요소(122)가 무선 신호들의 임의의 조합을 송신 및/또는 수신하도록 구성될 수 있다는 것이 이해될 것이다.

송수신 요소(122)가 단일 요소로서 도 1b에 도시되지만, WTRU(102)는 임의의 수의 송수신 요소(122)를 포함할 수 있다. 더 구체적으로, WTRU(102)는 MIMO 기술을 사용할 수 있다. 따라서, 일 실시예에서, WTRU(102)는, 무선 인터페이스(116)를 통해 무선 신호를 송신 및 수신하기 위한 2개 이상의 송수신 요소(122)(예컨대, 다수의 안테나)를 포함할 수 있다.

송수신기(120)는 송수신 요소(122)에 의해 송신될 신호들을 변조하고 송수신 요소(122)에 의해 수신되는 신호들을 복조하도록 구성될 수 있다. 위에서 언급된 바와 같이, WTRU(102)는 다중 모드 성능을 가질 수 있다. 따라서, 송수신기(120)는, WTRU(102)가, 예를 들면, NR 및 IEEE 802.11과 같은 다수의 RAT를 통해 통신하는 것을 가능하게 하기 위한 다수의 송수신기를 포함할 수 있다.

WTRU(102)의 프로세서(118)는 스피커/마이크로폰(124), 키패드(126), 및/또는 디스플레이/터치패드(128)(예컨대, LCD(liquid crystal display) 디스플레이 유닛 또는 OLED(organic light emitting diode) 디스플레이 유닛)에 결합될 수 있고 그로부터 사용자 입력 데이터를 수신할 수 있다. 프로세서(118)는 또한 사용자 데이터를 스피커/마이크로폰(124), 키패드(126), 및/또는 디스플레이/터치패드(128)에 출력할 수 있다. 또한, 프로세서(118)는 비착탈식 메모리(130) 및/또는 착탈식 메모리(132)와 같은 임의의 유형의 적절한 메모리로부터의 정보에 액세스하고 그 안에 데이터를 저장할 수 있다. 비착탈식 메모리(130)는 랜덤 액세스 메모리(random-access memory; RAM), 판독 전용 메모리(read-only memory; ROM), 하드디스크, 또는 임의의 다른 유형의 메모리 스토리지 디바이스를 포함할 수 있다. 착탈식 메모리(132)는 가입자 식별 모듈(subscriber identity module; SIM) 카드, 메모리 스틱, 시큐어 디지털(secure digital; SD) 메모리 카드 등을 포함할 수 있다. 다른 실시예에서, 프로세서(118)는, WTRU(102) 상에 물리적으로 위치하지 않는 메모리, 예를 들어, 서버 또는 가정용 컴퓨터(도시되지 않음) 상의 메모리의 정보에 액세스할 수도 있고, 그리고 그 메모리에 데이터를 저장할 수 있다.

프로세서(118)는 전원(134)으로부터 전력을 수신할 수 있고, WTRU(102)의 다른 컴포넌트로 전력을 분배하도록 그리고/또는 그 전력을 제어하도록 구성될 수 있다. 전원(134)은 WTRU(102)에 전력을 공급하기 위한 임의의 적절한 디바이스일 수 있다. 예를 들어, 전원(134)은 하나 이상의 건전지 배터리(예컨대, 니켈-카드뮴(NiCd), 니켈-아연(NiZn), 니켈 금속 수소화물(NiMH), 리튬-이온(Li-ion) 등), 태양 전지들, 연료 전지들 등을 포함할 수 있다.

프로세서(118)는 또한 WTRU(102)의 현재 위치에 관한 위치 정보(예컨대, 경도 및 위도)를 제공하도록 구성될 수 있는 GPS 칩셋(136)에 결합될 수 있다. GPS 칩셋(136)으로부터의 정보에 더하여 또는 그 대신에, WTRU(102)는 기지국(예컨대, 기지국들(114a, 114b))으로부터 에어 인터페이스(116)를 통해 위치 정보를 수신하고 그리고/또는 2개 이상의 근처 기지국으로부터 수신되고 있는 신호들의 타이밍에 기초하여 그의 위치를 결정할 수 있다. 실시예와 부합한 채로 있으면서 WTRU(102)가 임의의 적당한 위치 결정 방법에 의해 위치 정보를 획득할 수 있다는 것을 잘 알 것이다.

프로세서(118)는 추가적인 특징들, 기능 및/또는 유선 또는 무선 접속성을 제공하는 하나 이상의 소프트웨어 및/또는 하드웨어 모듈을 포함할 수 있는 다른 주변기기들(138)에 추가로 결합될 수 있다. 예를 들어, 주변기기들(138)은 가속도계, 전자 나침반, 위성 송수신기, (화상들 및/또는 비디오를 위한) 디지털 카메라, 범용 직렬 버스(universal serial bus; USB) 포트, 진동 디바이스, 텔레비전 송수신기, 핸즈프리 헤드셋, 블루투스® 모듈, 주파수 변조(frequency modulated; FM) 무선 유닛, 디지털 음악 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저, 가상 현실 및/또는 증강 현실(VR/AR) 디바이스, 활동 추적기 등을 포함할 수 있다. 주변기기(138)는 하나 이상의 센서를 포함할 수 있다. 센서들은 자이로스코프, 가속도계, 홀 효과 센서, 자력계, 배향 센서, 근접 센서, 온도 센서, 시간 센서; 지리 위치 센서; 고도계, 광 센서, 터치 센서, 자력계, 기압계, 제스처 센서, 생체 인식 센서, 습도 센서 등 중 하나 이상일 수 있다.

WTRU(102)는 (예컨대, (예컨대, 송신을 위한) UL 및(예컨대, 수신을 위한) DL 둘 다에 대해 특정 서브프레임들과 연관된) 신호들의 일부 또는 전부의 송신 및 수신이 동반적이고 그리고/또는 동시적일 수 있는 전이중 무선 장치(full duplex radio)를 포함할 수 있다. 전이중 무선 장치는 하드웨어(예컨대, 초크(choke))를 통해 또는 프로세서(예컨대, 별개의 프로세서(도시되지 않음) 또는 프로세서(118))를 통한 신호 프로세싱을 통해 자기-간섭을 줄이고 그리고/또는 실질적으로 제거하는 간섭 관리 유닛을 포함할 수 있다. 실시예에서, WTRU(102)는 (예를 들어, (예컨대, 송신을 위한) UL 또는 (예컨대, 수신을 위한) DL에 대해 특정 서브프레임들과 연관된) 신호들의 일부 또는 전부의 송신 및 수신을 위한 반이중 무선 장치(half-duplex radio)를 포함할 수 있다.

도 1c는 실시예에 따른 RAN(104) 및 CN(106)을 도시하는 시스템도이다. 전술한 바와 같이, RAN(104)은 에어 인터페이스(116)를 통해 WTRU들(102a, 102b, 102c)과 통신하기 위해 E-UTRA 무선 기술을 사용할 수 있다. RAN(104)은 또한 CN(106)과 통신할 수 있다.

RAN(104)은 eNode-B(160a, 160b, 160c)를 포함할 수 있지만, RAN(104)은 실시예와 여전히 부합하면서 임의의 수의 eNode-B를 포함할 수 있다는 것이 인식될 것이다. eNode-B들(160a, 160b, 160c) 각각은 에어 인터페이스(116)를 통해 WTRU들(102a, 102b, 102c)과 통신하기 위해 하나 이상의 송수신기를 포함할 수 있다. 하나의 실시예에서, eNode-B(160a, 160b, 160c)는 MIMO 기술을 구현할 수 있다. 따라서, eNode-B(160a)는 예를 들어, WTRU(102a)에 무선 신호들을 송신하고 그리고/또는 그로부터 무선 신호들을 수신하기 위해 다수의 안테나를 사용할 수 있다.

eNode-B들(160a, 160b, 160c) 각각은 특정 셀(도시되지 않음)과 연관될 수 있고, 무선 자원 관리 결정들, 핸드오버 결정들, UL 및/또는 DL에서의 사용자들의 스케줄링 등을 핸들링하도록 구성될 수 있다. 도 1c에 도시된 바와 같이, eNodeB들(160a, 160b, 160c)은 X2 인터페이스를 통해 서로 통신할 수 있다.

도 1c에 도시된 CN(106)은 이동성 관리 엔티티(MME)(162), 서빙 게이트웨이(SGW)(164), 및 패킷 데이터 네트워크(PDN) 게이트웨이(PGW)(166)를 포함할 수 있다. 전술한 요소들이 CN(106)의 일부로서 묘사되지만, 이 요소들 중 임의의 것이 CN 운영자 이외의 엔티티에 의해 소유되고 그리고/또는 운영될 수 있다는 것이 이해될 것이다.

MME(162)는 S1 인터페이스를 통해 RAN(104) 내의 eNode-B들(162a, 162b, 162c) 각각에 접속될 수 있고, 제어 노드로서 역할을 할 수 있다. 예를 들어, MME(162)는 WTRU들(102a, 102b, 102c)의 사용자들을 인증하는 것, 베어러 활성화/비활성화, WTRU들(102a, 102b, 102c)의 초기 접속(initial attach) 동안 특정의 서빙 게이트웨이를 선택하는 것 등을 책임지고 있을 수 있다. MME(162)는 RAN(104)과, 예를 들어, GSM 및/또는 WCDMA와 같은 다른 무선 기술들을 사용하는 다른 RAN들(도시되지 않음) 간에 스위칭하기 위한 제어 평면 기능을 제공할 수 있다.

SGW(164)는 S1 인터페이스를 통해 RAN(104) 내의 eNode B들(160a, 160b, 160c) 각각에 접속될 수 있다. SGW(164)는 일반적으로 WTRU들(102a, 102b, 102c)로/로부터 사용자 데이터 패킷들을 라우팅하고 포워딩할 수 있다. SGW(164)는 eNode B들간의 핸드오버들 동안 사용자 평면들을 앵커링(anchoring)하는 것, WTRU들(102a, 102b, 102c)에 대해 DL 데이터가 사용 가능할 때 페이징(paging)을 트리거링하는 것, WTRU들(102a, 102b, 102c)의 상황들을 관리하고 저장하는 것 등과 같은 다른 기능들을 수행할 수 있다.

SGW(164)는 WTRU들(102a, 102b, 102c)과 IP-인에이블드 디바이스들 사이의 통신을 용이하게 하기 위해, 예를 들어, 인터넷(110)과 같은 패킷 교환 네트워크들에 대한 액세스를 WTRU들(102a, 102b, 102c)에 제공할 수 있는 PGW(166)에 접속될 수 있다.

CN(106)은 다른 네트워크들과의 통신을 용이하게 할 수 있다. 예를 들어, CN(106)은 WTRU들(102a, 102b, 102c)과 전통적인 지상선 통신 디바이스들 사이의 통신을 용이하게 하기 위해, 예를 들어, PSTN(108)과 같은 회선 교환 네트워크들에 대한 액세스를 WTRU들(102a, 102b, 102c)에 제공할 수 있다. 예를 들어, CN(106)은 CN(106)과 PSTN(108) 사이의 인터페이스로서 역할을 하는 IP 게이트웨이(예컨대, IMS(IP multimedia subsystem) 서버)를 포함할 수 있거나 그와 통신할 수 있다. 또한, CN(106)은 다른 서비스 제공자들에 의해 소유되고 그리고/또는 운영되는 다른 유선 및/또는 무선 네트워크들을 포함할 수 있는 다른 네트워크들(112)에 대한 액세스를 WTRU들(102a, 102b, 102c)에 제공할 수 있다.

WTRU가 도 1a 내지 1d에서 무선 단말기로서 설명되지만, 특정한 대표적 실시예들에서 그러한 단말기는 통신 네트워크와의 유선 통신 인터페이스들을 (예컨대, 일시적으로 또는 영구적으로) 사용할 수 있다는 것이 고려된다.

대표적 실시예에서, 다른 네트워크(112)는 WLAN일 수 있다.

인프라 기본 서비스 세트(Basic Service Set; BSS) 모드의 WLAN은 BSS에 대한 액세스 포인트(AP) 및 AP와 연관된 하나 이상의 스테이션(STA)을 가질 수 있다. AP는 BSS로 그리고/또는 BSS로부터 트래픽을 운반하는 분배 시스템(Distribution System; DS) 또는 또 다른 유형의 유선/무선 네트워크에 대한 액세스 또는 인터페이스를 가질 수 있다. BSS 외부로부터 비롯되는 STA들로의 트래픽은 AP를 통해 도착할 수 있고 STA들에 전달될 수 있다. STA들로부터 BSS 외부의 목적지들로 비롯되는 트래픽은 각각의 목적지들로 전달되도록 AP에 송신될 수 있다. BSS 내의 STA들 간의 트래픽은 AP를 통해 송신될 수 있는데, 예를 들어, 소스(source) STA는 트래픽을 AP에 송신할 수 있고, AP는 트래픽을 목적지 STA에 전달할 수 있다. BSS 내의 STA들 사이의 트래픽은 피어-투-피어 트래픽으로 간주되고 그리고/또는 지칭될 수 있다. 피어-투-피어 트래픽은 직접 링크 셋업(direct link setup; DLS)을 사용하여 소스 및 목적지 STA들 사이에서 (예컨대, 그들 사이에서 직접) 송신될 수 있다. 특정 대표적 실시예들에서, DLS는 802.11e DLS 또는 802.112 TDLS(tunneled DLS)를 사용할 수 있다. IBSS(Independent BSS) 모드를 사용하는 WLAN은 AP를 갖지 않을 수 있고, IBSS 내의 또는 IBSS를 사용하는 STA들(예컨대, 모든 STA들)은 서로 직접 통신할 수 있다. IBSS 통신 모드는 때때로 본 명세서에서 "애드혹(ad-hoc)" 통신 모드라고 지칭될 수 있다.

802.11ac 인프라 동작 모드 또는 유사한 동작 모드를 사용할 때, AP는 예를 들어, 주 채널과 같은 고정 채널 상에서 비컨을 송신할 수 있다. 주 채널은 고정된 폭(예컨대, 20MHz 폭의 대역폭) 또는 동적 설정 폭일 수 있다. 주 채널은 BSS의 동작 채널일 수 있으며, STA들에 의해 AP와의 접속을 확립하기 위해 사용될 수 있다. 특정 대표적 실시예들에서, CSMA/CA(Carrier Sense Multiple Access with Collision Avoidance)가 예를 들어, 802.11 시스템들에서 구현될 수 있다. CSMA/CA의 경우, AP를 포함하는 STA들(예컨대, 모든 STA)은 주 채널을 감지할 수 있다. 주 채널이 특정 STA에 의해 사용 중인 것으로 감지/검출 및/또는 결정되면, 특정 STA는 백오프될 수 있다. 하나의 STA(예컨대, 단지 하나의 스테이션)가 주어진 BSS에서 임의의 주어진 시간에 송신할 수 있다.

고처리량(High Throughput; HT) STA들은 예를 들어, 인접하거나 인접하지 않은 20MHz 채널과 주 20MHz 채널의 결합을 통해 통신을 위해 40MHz 폭의 채널을 사용하여 40MHz 폭의 채널을 형성할 수 있다.

초고처리량(Very High Throughput; VHT) STA들은 20MHz, 40MHz, 80MHz 및/또는 160MHz 폭의 채널들을 지원할 수 있다. 40MHz 및/또는 80MHz 채널들은 연속적인 20MHz 채널들을 결합함으로써 형성될 수 있다. 160MHz 채널은 8개의 연속적인 20MHz 채널을 결합함으로써 또는 80+80 구성이라고 지칭될 수 있는 2개의 비연속적인 80MHz 채널을 결합함으로써 형성될 수 있다. 80+80 구성의 경우, 데이터는 채널 인코딩 후에 데이터를 2개의 스트림으로 분할할 수 있는 세그먼트 파서를 통해 전달될 수 있다. IFFT(Inverse Fast Fourier Transform) 프로세싱 및 시간 도메인 프로세싱이 각각의 스트림에 대해 개별적으로 행해질 수 있다. 스트림들은 2개의 80MHz 채널에 매핑될 수 있고, 데이터는 송신 STA에 의해 송신될 수 있다. 수신 STA의 수신기에서, 80+80 구성에 대한 전술된 동작이 반전될 수 있고, 결합된 데이터는 매체 액세스 제어(Medium Access Control; MAC)에 송신될 수 있다.

802.11af 및 802.11ah에 의해 서브(sub) 1GHz 동작 모드가 지원된다. 채널 동작 대역폭들 및 반송파들은 802.11n 및 802.11ac에서 사용되는 것들에 비해 802.11af 및 802.11ah에서 감소된다. 802.11af는 TV 백색 공간(TV White Space; TVWS) 스펙트럼에서 5MHz, 10MHz 및 20MHz 대역폭들을 지원하고, 802.11ah는 비-TVWS 스펙트럼을 사용하는 1MHz, 2MHz, 4MHz, 8MHz 및 16MHz 대역폭들을 지원한다. 대표적 실시예에 따르면, 802.11ah는 예를 들어, 매크로 커버리지 영역 내의 MTC 디바이스들과 같은 미터 유형 제어/기계 유형 통신(Meter Type Control/Machine-Type Communications; MTC)을 지원할 수 있다. MTC 디바이스들은 특정 능력들 예를 들어, 특정의 그리고/또는 제한된 대역폭들에 대한 지원(예컨대, 그것들만의 지원)을 포함하는 제한된 능력들을 가질 수 있다. MTC 디바이스들은 (예컨대, 매우 긴 배터리 수명을 유지하기 위해) 문턱값을 초과하는 배터리 수명을 갖는 배터리를 포함할 수 있다.

802.11n, 802.11ac, 802.11af 및 802.11ah와 같은 다수의 채널 및 채널 대역폭을 지원할 수 있는 WLAN 시스템들은 주 채널로서 지정될 수 있는 채널을 포함한다. 주 채널은 BSS 내의 모든 STA들에 의해 지원되는 가장 큰 공통 동작 대역폭과 동일한 대역폭을 가질 수 있다. 주 채널의 대역폭은 BSS에서 동작하는 모든 STA들 중에서 가장 작은 대역폭 동작 모드를 지원하는 STA에 의해 설정 및/또는 제한될 수 있다. 802.11ah의 예에서, 주 채널은 AP 및 BSS 내의 다른 STA들이 2MHz, 4MHz, 8MHz, 16MHz 및/또는 다른 채널 대역폭 동작 모드들을 지원하더라도 1MHz 모드를 지원하는(예컨대, 오직 지원하는) STA들(예컨대, MTC 유형 디바이스들)에 대해 1MHz 폭일 수 있다. 반송파 감지 및/또는 네트워크 할당 벡터(Network Allocation Vector; NAV) 설정들은 주 채널의 상태에 의존할 수 있다. 주 채널이 예를 들어, STA(1MHz 동작 모드만을 지원함)의 AP로의 송신으로 인해 사용 중인 경우, 모든 가용 주파수 대역들은 가용 주파수 대역들의 대부분이 유휴 상태로 유지되더라도 사용 중인 것으로 간주될 수 있다.

미국에서, 802.11ah에 의해 사용될 수 있는 가용 주파수 대역들은 902MHz 내지 928MHz이다. 한국에서, 가용 주파수 대역들은 917.5MHz 내지 923.5MHz이다. 일본에서, 가용 주파수 대역들은 916.5MHz 내지 927.5MHz이다. 802.11ah에 대해 사용 가능한 총 대역폭은 국가 코드에 따라 6MHz 내지 26MHz이다.

도 1d는 실시예에 따른 RAN(104) 및 CN(106)을 도시하는 시스템 도면이다. 전술한 바와 같이, RAN(104)은 에어 인터페이스(116)를 통해 WTRU들(102a, 102b, 102c)과 통신하기 위해 NR 무선 기술을 사용할 수 있다. RAN(104)은 또한 CN(106)과 통신할 수 있다.

RAN(104)은 gNB(180a, 180b, 180c)를 포함할 수 있지만, RAN(104)은 실시예와 여전히 부합하면서 임의의 수의 gNB를 포함할 수도 있다는 것이 인식될 것이다. gNB들(180a, 180b, 180c) 각각은 에어 인터페이스(116)를 통해 WTRU들(102a, 102b, 102c)과 통신하기 위한 하나 이상의 송수신기를 포함할 수 있다. 하나의 실시예에서, gNB들(180a, 180b, 180c)은 MIMO 기술을 구현할 수 있다. 예를 들어, gNB들(180a, 180b)은 gNB들(180a, 180b, 180c)에 신호들을 송신하고 그리고/또는 그들로부터 신호들을 수신하기 위해 빔포밍을 사용할 수 있다. 따라서, gNB(180a)는 예를 들어, WTRU(102a)에 무선 신호들을 송신하고 그리고/또는 그로부터 무선 신호들을 수신하기 위해 다수의 안테나를 사용할 수 있다. 실시예에서, gNB들(180a, 180b, 180c)은 반송파 집성 기술을 구현할 수 있다. 예를 들어, gNB(180a)는 다수의 컴포넌트 반송파를 WTRU(102a)에 송신할 수 있다(도시되지 않음). 이러한 컴포넌트 반송파들의 서브세트는 무면허 스펙트럼 상에 있을 수 있는 반면, 나머지 컴포넌트 반송파들은 면허 스펙트럼 상에 있을 수 있다. 실시예에서, gNB들(180a, 180b, 180c)은 CoMP(Coordinated Multi-Point) 기술을 구현할 수 있다. 예를 들어, WTRU(102a)는 gNB(180a) 및 gNB(180b)(및/또는 gNB(180c))로부터 조정된 송신물들을 수신할 수 있다.

WTRU들(102a, 102b, 102c)은 확장가능 뉴머롤로지(scalable numerology)와 연관된 송신들을 사용하여 gNB들(180a, 180b, 180c)과 통신할 수 있다. 예를 들어, OFDM 심볼 간격 및/또는 OFDM 부반송파 간격은 상이한 송신들, 상이한 셀들, 및/또는 무선 송신 스펙트럼의 상이한 부분들에 대해 변할 수 있다. WTRU들(102a, 102b, 102c)은 (예컨대, 변하는 수의 OFDM 심벌들 및/또는 지속적인(lasting) 변하는 절대 시간 길이들을 포함하는) 다양한 또는 확장가능 길이들의 서브프레임 또는 송신 시간 간격(transmission time interval; TTI)들을 사용하여 gNB들(180a, 180b, 180c)과 통신할 수 있다.

gNB들(180a, 180b, 180c)은 독립형 구성 및/또는 비독립형 구성에서 WTRU들(102a, 102b, 102c)과 통신하도록 구성될 수 있다. 독립형 구성에서, WTRU들(102a, 102b, 102c)은 (예컨대, eNodeB들(160a, 160b, 160c)과 같은) 다른 RAN들에 또한 액세스하지 않고 gNB들(180a, 180b, 180c)과 통신할 수 있다. 독립형 구성에서, WTRU들(102a, 102b, 102c)은 이동성 앵커 포인트로서 gNB들(180a, 180b, 180c) 중 하나 이상을 사용할 수 있다. 독립형 구성에서, WTRU들(102a, 102b, 102c)은 무면허 대역 내의 신호들을 사용하여 gNB들(180a, 180b, 180c)과 통신할 수 있다. 비독립형 구성에서, WTRU들(102a, 102b, 102c)은 예를 들어, eNode-B들(160a, 160b, 160c)과 같은 또 다른 RAN과 또한 통신하면서/그에 접속하면서 gNB들(180a, 180b, 180c)과 통신/그에 접속할 수 있다. 예를 들어, WTRU들(102a, 102b, 102c)은 하나 이상의 gNB(180a, 180b, 180c) 및 하나 이상의 eNode-B(160a, 160b, 160c)와 실질적으로 동시에 통신하기 위해 DC 원리들을 구현할 수 있다. 비독립형 구성에서, eNode-B들(160a, 160b, 160c)은 WTRU들(102a, 102b, 102c)에 대한 이동성 앵커로서 역할을 할 수 있고, gNB들(180a, 180b, 180c)은 WTRU들(102a, 102b, 102c)을 서비스하기 위한 추가적인 커버리지 및/또는 처리량을 제공할 수 있다.

gNB들(180a, 180b, 180c) 각각은 특정의 셀(도시되지 않음)과 연관될 수 있고, 무선 자원 관리 결정들, 핸드오버 결정들, UL 및/또는 DL에서의 사용자들의 스케줄링, 네트워크 슬라이싱의 지원, DC, NR과 E-UTRA 사이의 연동, 사용자 평면 데이터의 사용자 평면 기능(User Plane Function; UPF)(184a, 184b)으로의 라우팅, 제어 평면 정보의 액세스 및 이동성 관리 기능(Access and Mobility Management Function; AMF)(182a, 182b)으로의 라우팅 등을 핸들링하도록 구성될 수 있다. 도 1d에 도시된 바와 같이, gNB들(180a, 180b, 180c)은 Xn 인터페이스를 통해 서로 통신할 수 있다.

도 1d에 도시된 CN(106)은 적어도 하나의 AMF(182a, 182b), 적어도 하나의 UPF(184a, 184b), 적어도 하나의 세션 관리 기능(Session Management Function; SMF)(183a, 183b), 및 가능하게는 데이터 네트워크(Data Network; DN)(185a, 185b)를 포함할 수 있다. 전술한 요소들이 CN(106)의 일부로서 묘사되지만, 이 요소들 중 임의의 것이 CN 운영자 이외의 엔티티에 의해 소유되고 그리고/또는 운영될 수 있다는 것이 이해될 것이다.

AMF(182a, 182b)는 N2 인터페이스를 통해 RAN(104) 내의 gNB들(180a, 180b, 180c) 중 하나 이상에 접속될 수 있고, 제어 노드로서 역할을 할 수 있다. 예를 들어, AMF(182a, 182b)는 WTRU들(102a, 102b, 102c)의 사용자들의 인증, 네트워크 슬라이싱(예컨대, 상이한 요건들을 갖는 상이한 프로토콜 데이터 유닛(protocol data unit; PDU) 세션들의 핸들링)에 대한 지원, 특정의 SMF(183a, 183b)의 선택, 등록 영역의 관리, 비액세스 계층(non-access stratum; NAS) 시그널링의 종료, 이동성 관리 등을 담당할 수 있다. 네트워크 슬라이싱은 WTRU들(102a, 102b, 102c)에 의해 사용되는 서비스들의 유형들에 기초하여 WTRU들(102a, 102b, 102c)에 대한 CN 지원을 맞춤화하기 위해 AMF(182a, 182b)에 의해 사용될 수 있다. 예를 들어, URLLC(ultra-reliable low latency) 액세스에 의존하는 서비스들, eMBB(enhanced massive mobile broadband) 액세스에 의존하는 서비스들, MTC 액세스에 대한 서비스들 등과 같은 상이한 사용 사례들에 대해 상이한 네트워크 슬라이스들이 확립될 수 있다. AMF(182a, 182b)는 RAN(104)과, 예를 들어, LTE, LTE-A, LTE-A Pro 및/또는 예를 들어, WiFi와 같은 비-3GPP 액세스 기술들과 같은 다른 무선 기술들을 사용하는 다른 RAN들(도시되지 않음) 사이에서 스위칭하기 위한 제어 평면 기능을 제공할 수 있다.

SMF(183a, 183b)는 N11 인터페이스를 통해 CN(106) 내의 AMF(182a, 182b)에 접속될 수 있다. SMF(183a, 183b)는 또한 N4 인터페이스를 통해 CN(106) 내의 UPF(184a, 184b)에 접속될 수 있다. SMF(183a, 183b)는 UPF(184a, 184b)를 선택 및 제어하고, UPF(184a, 184b)를 통한 트래픽의 라우팅을 구성할 수 있다. SMF(183a, 183b)는 예를 들어, UE IP 주소를 관리하고 할당하는 것, PDU 세션들을 관리하는 것, 정책 시행 및 QoS를 제어하는 것, DL 데이터 통지들을 제공하는 것 등과 같은 다른 기능들을 수행할 수 있다. PDU 세션 유형은 IP 기반, 비-IP 기반, 이더넷 기반 등일 수 있다.

UPF(184a, 184b)는 WTRU들(102a, 102b, 102c)과 IP 인에이블드 디바이스들 사이의 통신을 용이하게 하기 위해, 예를 들어, 인터넷(110)과 같은 패킷 교환 네트워크들에 대한 액세스를 WTRU들(102a, 102b, 102c)에 제공할 수 있는 N3 인터페이스를 통해 RAN(104) 내의 gNB들(180a, 180b, 180c) 중 하나 이상에 접속될 수 있다. UPF(184, 184b)는 예를 들어, 패킷들을 라우팅 및 포워딩하는 것, 사용자 평면 정책들을 시행하는 것, 멀티-홈 PDU 세션들을 지원하는 것, 사용자 평면 QoS를 핸들링하는 것, DL 패킷들을 버퍼링하는 것, 이동성 앵커링을 제공하는 것 등과 같은 다른 기능들을 수행할 수 있다.

CN(106)은 다른 네트워크들과의 통신을 용이하게 할 수 있다. 예를 들어, CN(106)은 CN(106)과 PSTN(108) 사이의 인터페이스로서 역할을 하는 IP 게이트웨이(예컨대, IMS(IP multimedia subsystem) 서버)를 포함할 수 있거나 그와 통신할 수 있다. 또한, CN(106)은 다른 서비스 제공자들에 의해 소유되고 그리고/또는 운영되는 다른 유선 및/또는 무선 네트워크들을 포함할 수 있는 다른 네트워크들(112)에 대한 액세스를 WTRU들(102a, 102b, 102c)에 제공할 수 있다. 하나의 실시예에서, WTRU들(102a, 102b, 102c)은 UPF(184a, 184b)에 대한 N3 인터페이스 및 UPF(184a, 184b)와 DN(185a, 185b) 사이의 N6 인터페이스를 경유해 UPF(184a, 184b)를 통해 로컬 DN(185a, 185b)에 접속될 수 있다.

도 1a 내지 도 1d, 및 도 1a 내지 도 1d의 대응하는 설명을 고려할 때, WTRU(102a-d), 기지국(114a-b), eNode-B(160a-c), MME(162), SGW(164), PGW(166), gNB(180a-c), AMF(182a-ab), UPF(184a-b), SMF(183a-b), DN(185a-b) 및/또는 본 명세서에 설명된 임의의 다른 디바이스(들) 중 하나 이상과 관련하여 본 명세서에 설명된 기능들 중 하나 이상 또는 전부는 하나 이상의 에뮬레이션 디바이스(도시되지 않음)에 의해 수행될 수 있다. 에뮬레이션 디바이스들은 본 명세서에 설명된 기능들 중 하나 이상 또는 전부를 에뮬레이션하도록 구성된 하나 이상의 디바이스일 수 있다. 예를 들어, 에뮬레이션 디바이스들은 다른 디바이스들을 테스트하고 그리고/또는 네트워크 및/또는 WTRU 기능들을 시뮬레이션하기 위해 사용될 수 있다.

에뮬레이션 디바이스들은 실험실 환경 및/또는 운영자 네트워크 환경에서 다른 디바이스들의 하나 이상의 테스트를 구현하도록 설계될 수 있다. 예를 들어, 하나 이상의 에뮬레이션 디바이스는 통신 네트워크 내의 다른 디바이스들을 테스트하기 위해 유선 및/또는 무선 통신 네트워크의 일부로서 완전히 또는 부분적으로 구현 및/또는 배치되면서 하나 이상의 또는 모든 기능들을 수행할 수 있다. 하나 이상의 에뮬레이션 디바이스는 유선 및/또는 무선 통신 네트워크의 일부로서 일시적으로 구현/배치되면서 하나 이상의 또는 모든 기능들을 수행할 수 있다. 에뮬레이션 디바이스는 테스트 및/또는 OTA(over-the-air) 무선 통신을 사용하여 테스트를 수행하기 위해 또 다른 디바이스에 직접 결합될 수 있다.

하나 이상의 에뮬레이션 디바이스는 유선 및/또는 무선 통신 네트워크의 일부로서 구현/배치되지 않으면서 모든 기능들을 포함하는 하나 이상의 기능을 수행할 수 있다. 예를 들어, 에뮬레이션 디바이스들은 하나 이상의 컴포넌트의 테스트를 구현하기 위해 테스트 실험실 및/또는 배치되지 않은(예컨대, 테스트) 유선 및/또는 무선 통신 네트워크에서의 테스트 시나리오에서 사용될 수 있다. 하나 이상의 에뮬레이션 디바이스는 테스트 장비일 수 있다. RF 회로(예컨대, 하나 이상의 안테나를 포함할 수 있음)를 통한 직접 RF 결합 및/또는 무선 통신이 데이터를 송신 및/또는 수신하기 위해 에뮬레이션 디바이스들에 의해 사용될 수 있다.

여기에서 논의된 바와 같이, 멀티캐스트 및 유니캐스트 MAC 주소 할당을 위해 IEEE 802.1CQ에 정의된 프로토콜은 두 가지 유형의 동작, 즉, 청구 기반 프로세스(claiming-based process)가 사용되고 스테이션으로부터 트리거되는 자체 할당(self-assignment) 및/또는 특정 풀(pool) 내의 주소를 할당할 엔티티에 스테이션이 접촉하는 서버 기반 절차로 명시될 수 있다. 두 변형 모두 공통 프로토콜에 통합될 수 있다.

프로토콜은 자체 청구 및 서버 기반 동작 모두에 대한 공통 메시지 세트를 제공할 수 있다. 이는 프로토콜을 간결하게 유지하고 전체 메시지 수를 줄이기 위해 수행할 수 있다. 자체 청구 프로토콜은 MAC 주소 자체 할당 프로토콜(MAC Address Self-Assignment Protocol; MASAP)이라고 하고 서버 기반 버전은 MAC 주소 서버 기반 할당 프로토콜(MAC Address Server based Assignment Protocol; MASBAP)이라고 한다.

MASAP 프로토콜은 IEEE 1722 MAC 주소 획득 프로토콜(MAC Address Acquisition Protocol; MAAP)을 기반으로 한다. IEEE 1722는 오디오/비디오 송신에서 흐름 식별자로 사용되기 위해 IEEE 1722에 할당된 주소 풀 중의 멀티캐스트 MAC 주소를 자체 청구하는 데만 사용되는 MAC 주소 획득 프로토콜(MAAP)을 정의한다. MAAP는 자체 청구에만 사용된다(예컨대, 서버 기반 할당을 지원하지 않을 수 있는 경우). 또한, MAAP는 인프라로부터의 임의의 지원 또는 멀티캐스트 MAC 주소의 할당을 포함하지 않는다. MAAP를 수행하는 스테이션에는 유니캐스트 MAC 주소가 할당되어 있다고 가정한다. 결과적으로 하나의 "있는 그대로(as-is)" 시나리오의 MAAP는 IEEE 802.1CQ의 필요를 충족하지 못할 수 있다.

MASAP는 네트워크에 서비스를 제공하는 프록시(예컨대, MUMAAP 프로토콜 구현함)로부터의 권한 있는 응답(authoritative responses)에 대한 지원을 포함할 수 있는데, 이 프록시는 네트워크의 모든 발견 메시지를 캡처 및 북키핑(book-keep)할 수 있으며 자체 청구 프로세스의 결과를 스테이션에 직접 알린다.

MASBAP 프로토콜은 주소의 초기 할당을 위한 4개의 메시지가 있다는 점에서 DHCP의 단순화된 버전과 제한된 방식으로 관련될 수 있다.

여기에서 논의된 바와 같이, 스테이션은 MUMAAP 프로토콜의 클라이언트 측을 실행하는 종단 노드(end node)일 수 있는 반면, 서버는 프록시 또는 서버에 관계없이 MUMAAP 프로토콜의 서버 측을 실행하는 인프라 측을 지칭할 수 있다. 서버는 운영자 네트워크 인프라 컴포넌트에 위치할 수 있고 그리고/또는 예를 들어, 게이트웨이, 액세스 포인트, 라우터, 홈 네트워크 제어기 또는 셋톱 박스와 같은 고객 구내 장비에 위치할 수 있다.

IEEE 1722 MAAP 프로토콜 및 DHCP는 여기에 참조로 포함된다. IEEE 1722 MAAP은 특정 범위 중에서 멀티캐스트 MAC 주소의 할당을 다룰 수 있다. 이 프로토콜은, 클라이언트가 자신에 배당되거나 할당된 유니캐스트 MAC 주소가 있다는 관점에서 동작할 수 있는데, 이는 802.1CQ의 경우가 아닐 수 있다. 또한, IEEE 1722는 유선 환경으로 제한될 수 있다. 따라서 IEEE 1722 MAAP에서 다뤄지지 않는 제어 비트에 기초하는 메시지 및 거동이 필요할 수 있다. 본 명세서에서 논의된 바와 같이, MAAP 프레임워크는 자체 할당 프로세스에서 중재할 수 있는 프록시와의 동작을 다루도록 확장될 수 있다. 또한, 여기에서 논의된 기술/실시예/프로토콜은 IEEE 1722 네트워크에서 MAAP의 동작을 대체할 수 있는데, 이는 원하는 경우 동일한 기능에 사용될 수 있고 예를 들어, 스테이션 ID 및 네트워크 ID와 같은 옵션을 포함하여 MAAP 전개(deployments) 문제(예컨대, 클라이언트가 MAAP를 실행하는 다수의 네트워크에 속할 때 주소 충돌의 발생)를 해결할 수 있기 때문이다.

MUMAAP는 DHCP와 유사한 4개의 메시지 교환(즉, 발견, 제안, 요청, 확인 응답)을 고려할 수 있다. 모든 메시지와 거동은 MUMAAP 프로토콜에 특유하다.

IEEE 802.1CQ 및 IEEE 802c에 정의된 대로 종단국에 로컬 유니캐스트 및 멀티캐스트 MAC 주소를 할당하기 위한 프로토콜을 정의할 필요가 있다. 이 프로토콜은 예를 들어, 자체 할당(즉, 자체 청구) 메커니즘을 통해 그리고/또는 서버를 고려하는 접근 방식을 통해 할당을 지원해야 할 수 있다. 프로토콜은 IEEE 802c에 정의된 4개의 사분면에서 로컬 유니캐스트 및 멀티캐스트 MAC 주소 할당을 지원해야 할 수도 있다.

여기에서 논의된 바와 같이, i) 자체 할당 및 ii) 서버 기반 할당의 두 가지 동작 변형을 갖는 로컬 및 멀티캐스트 MAC 주소 할당 프로토콜의 설계가 필요하다. 이 프로토콜은 인프라 지원 또는 독립 실행형 모드로 다수의 IEEE 802 기술에서 동작할 수 있어야 한다. 또한 두 가지 동작 모드에 대해 프로토콜 메시지 및 상태 머신의 정의가 필요할 수 있다. 또한, 임의의 사전 구성/할당/지정 없이 스테이션에 대한 주소 할당을 지원하거나 스테이션 및 사전 할당을 고려한 주소 할당 지원이 필요할 수 있다.

언급한 바와 같이, i) MAC 주소 자체 할당 프로토콜(MASAP) 및 ii) MAC 주소 서버 기반 할당 프로토콜(MASBAP)의 두 가지 차별화된 프로토콜 변형이 있을 수 있다. MASAP는 자체 할당 동작 모드에 대응하며 MASBAP은 서버 기반 할당에 사용된다. 두 프로토콜은 동일한 메시지 구조와 옵션을 공유할 수 있지만 각각에 대해 거동이 다른 방식으로 정의된다.

MASAP는 네트워크의 멀티캐스트 지원에 의존하는 발견, 방어 및 발표 메커니즘을 사용할 수 있다. 클라이언트는 IEEE 802.1CQ에 정의된 미리 확립된 범위 중에 로컬 유니캐스트 MAC 주소를 무작위로 선택하여 유니캐스트 MAC 주소 또는 MAC 주소 범위를 선택할 수 있다. 클라이언트가 로컬 유니캐스트 MAC 주소를 선택하면, 클라이언트는 (발견 메시지를 통해) 발견 메시지를 예를 들어, 모든 MASAP 클라이언트 또는 프록시가 청취하는, 미리 확립된 멀티캐스트 주소로 송신하여 MAC 주소 또는 MAC 주소 범위(예컨대, 유니캐스트 또는 멀티캐스트)의 가용성을 프로빙(probe)할 수 있다. 임의의 응답을 수신하지 않고 여러 발견 메시지를 송신한 후, 클라이언트는 주소가 자신에게 할당될 수 있음을 이해할 수 있다. 그 후에, 스테이션은 할당된(즉, 자체 할당된) 주소 범위를 요청하는 발견을 청취하고 네트워크 내에서 주기적으로 할당을 발표하는 방어 및 발표 단계들을 시작할 수 있다.

일부 양상에서 IEEE 1722와 유사할 수 있지만 또 다른 파라미터 및 메시지 세트가 사용되는 이 기본 동작은 일부 IEEE 802 기술(예컨대, IEEE 802.11)이 아직 연관되지 않은 스테이션(즉, 할당된 MAC 주소를 아직 갖지 않는 프로빙 단계를 수행하는 스테이션)에 대한 발견 메시지 수신을 지원하지 않을 수 있다는 사실을 설명하기 위해 확장될 수 있다. 따라서 MASAP를 통해 클라이언트가 요청한 상이한 할당들을 추적하고 발견을 발행하는 스테이션에 직접 응답하기 위해 네트워크(예컨대, IEEE 802.11 AP)의 프록시를 활성화함으로써 이 클라이언트 동작이 필요하다. 이것은 예를 들어, IEEE 802.11과 같은 기술에서 프로토콜의 동작을 허용할 뿐만 아니라 클라이언트가 즉시 확인(confirmation)을 수신할 수 있기 때문에 MAC 주소 할당 속도를 E또한 향상시킬 수 있다. MASAP는 MASBAP와는 다른 MAC 주소 범위를 할당에 사용할 수 있다.

MASBAP 서버가 네트워크에 있는 경우, 서버는 MASAP 발견 메시지에 응답하고 서버 기반 MAC 주소를 할당할 수 있다. 이 경우 네트워크의 MASAP 클라이언트는 방어 및 발표 메시지와 관련된 프로세스를 중지할 수 있다.

언급한 바와 같이 MASBAP은 DHCP(즉, 발견, 제안, 요청, 확인 응답)와 유사한 4개의 메시지 교환을 사용하여 스테이션에 주소를 할당할 수 있다. MASBAP에서와 같이 클라이언트는 자신의 메시지의 소스 주소로서 사용될 하나의 주소를 자동 생성하고 서버와 발견, 제안, 요청 및 ACK 메시지 교환을 시작할 수 있다. 제안에 대한 응답으로 서버 또는 프록시는 MAC 주소 또는 MAC 주소 범위를 클라이언트에 제공할 수 있다. 클라이언트는 별도의 서버로부터 여러 제안을 수신할 수 있다. 서버 동작은 무상태(stateless)일 수 있으므로, MAC 주소는 서버가 요청 메시지를 수신한 후에만 할당될 수 있다. 클라이언트가 네트워크에서 할당된 MAC 주소 또는 MAC 주소 범위를 사용한 후 서버는 클라이언트에 ACK를 발행할 수 있다.

MASAP는 IEEE 802c SLAP 정의에 따라 유니캐스트 및 멀티캐스트 MAC 주소를 자체 청구하는 데 사용될 수 있다. IEEE 1722 테이블 B.9 및 B.10에 의해 정의된 범위에서 멀티캐스트 MAC 주소를 청구하는 것은 본 개시의 범위를 벗어날 수 있고 IEEE 1722 MAAP에 정의된 규칙을 사용할 수 있다.

MASAP는 메시지 주소 지정을 위해 다음 규칙을 사용할 수 있다: 발견 메시지에 대한 소스 MAC 주소는 표 1에 표시된 범위에서 무작위로 선택될 수 있다; 방어 및 발표 메시지에 대한 소스 MAC 주소는 이전에 할당된 MAC 주소 또는 스테이션에 할당된 EUI-64/48을 사용할 수 있다; 발견 메시지에 대한 목적지 MAC 주소는 표 1에 지정된 멀티캐스트 MAC 주소에 대응한다; 그리고/또는 방어 및 발표 메시지에 대한 목적지 MAC 주소는 발견 메시지의 소스 MAC 주소에 대응한다. 소스 주소 및/또는 목적지 주소는 MSASP 패킷에 캡슐화될 수 있다.

주소 범위	기능
AE:00:00:80:00:00 - AE:00:00:8F:FF:FF(예로서)	발견 메시지를 위해 소스 주소를 무작위로 선택하기 위한 주소 범위
01:80:C2:10:00:0E (예로서)	발견 메시지에서 목적지로서 사용되는 멀티캐스트 주소

주소 할당

MASAP 프로토콜은 IEEE 1722 MAC 주소 획득 프로토콜(MAAP)과 유사할 수 있지만 상태 머신은 다를 수 있다. 이 문서에 정의된 MASAP 동작은 IEEE 1722에 지정된 유사한 상태 머신, 이벤트, 상수 및 타이머를 사용할 수 있다. 그러나 MASAP에서, MAAP는 네트워크에 있는 모든 발견 메시지를 캡처 및 북키핑할 수 있는, 네트워크에 서비스를 제공하는 프록시로부터 권위 있는 응답(예컨대, 발견 요청)을 지원하도록 확장될 수 있으며, 이는 자체 청구 프로세스의 결과를 스테이션에 직접 알릴 수 있다. 표 2는 추가 상태 전환(회색 셀)을 갖는 MAAP 프로토콜의 상태 머신을 보여준다. 이 표는 스테이션에 대한 상태 머신 전환만을 나타낸다.

		상태
		초기	발견	방어
이벤트	Begin!	generate_address^a ReserveAddress!	-X-	-X-
	Release! ^c	-X-	Stop probe_timer INITIAL	Stop announce_timer INITIAL
	Restart!	generate_address ReserveAddress!	-X-	-X-
	ReserveAddress!	init_maap_probe_count Start probe_timer sProbe DISCOVER	-X-	-X-
	rProbe! ^b	-X-	compare_MAC^d Stop probe_timer INITIAL/Restart!	sDefend
	rDefend! ^b	-X-	Stop probe_timer INITIAL/Restart!	compare_MAC^d Stop announce_timer INITIAL/Restart!
	rAnnounce! ^b	-X-	Stop probe_timer INITIAL/Restart!	compare_MAC^d Stop announce_timer INITIAL/Restart!
	probeCount!	-X-	Stop probe_timer Start announce_timer sAnnounce DEFEND	-X-
	announcetimer!	-X-	-X-	Start announce_timer sAnnounce
	probetimer!	-X-	Start probe_timer sProbe dec_maap_probe_count	-X-
	PortOperational!	generate_address^a ReserveAddress!	Stop probe_timer INITIAL/Restart!	Stop announce_timer INITIAL/Restart!
	rProxyAnswer(status == 1)	-X-	Stop probe_timer DEFEND	-X-
	rProxyAnswer(status == 2)	-X-	Stop probe_timer INITIAL/Restart!	Stop probe_timer INITIAL/Restart!
	rProxyAnswer(status == 3)	-X-	Stop probe_timer INITIAL/Restart!	Stop probe_timer INITIAL/Restart!
	rProxyAnswer(status == 3)	INITIAL/STOP	INITIAL/STOP	INITIAL/STOP

MASAP 상태 머신

^a Begin! 또는 PortOperational! 이벤트는 할당된 주소 범위로 시작될 수 있거나 MASAP가 generate_address 기능으로 주소 범위를 선택할 수 있다. 주소 범위가 Begin! 또는 PortOperational! 이벤트를 공급받으면, generate_address가 호출되지 않을 수 있고 공급된 주소 범위가 사용될 수 있다. 애플리케이션이 이전에 주소 범위를 얻었고 영구 저장소(persistent storage)에 액세스할 수 있는 경우, 애플리케이션은 이전 주소 범위를 기록하고 저장된 주소 범위를 재사용하려고 시도할 수 있다.

^b 이 상태 머신과 연관된 주소 범위와 충돌하는 수신된 발견, 방어 및 발표 PDU만이 rProbe!, rDefend!, 및 rAnnounce! 이벤트를 생성할 수 있다. 이 상태 머신과 연관된 주소 범위와 충돌하지 않는 모든 발견, 방어 및 발표 PDU는 무시될 수 있다.

^c Release! 이벤트가 수신되고 상태 머신이 INITIAL 상태로 돌아간 후, 이 상태 머신과 연관된 주소 범위는 사용 가능한(free) 것으로 간주될 수 있으며 상태 머신은 파괴될 수 있다.

^d compare_MAC 기능이 참(TRUE)을 반환하면, 추가 프로세싱 또는 프로토콜 동작이 수행되지 않고 프로토콜 상태가 변경되지 않을 수 있다.

실시예에서, 표 2에 표시된 바와 같이, Begin! 이벤트를 수신하자마자, 노드에서 실행 중인 상태 머신이 초기(INITIAL) 상태에서 generate_address 기능을 수행하고 ReserveAddress! 이벤트를 호출할 수 있다. ReserveAddress! 이벤트를 수신하자마자, 상태 머신은 init_maap_probe_count 기능을 수행하고 probe_timer를 시작할 수 있다. 노드는 발견 메시지(즉, sProbe)를 이웃 노드로 송신하고 방어 메시지가 이웃 노드로부터 수신되거나 probe_timer가 만료될 때까지 발견 상태에 진입한다. 방어 메시지가 이웃 노드로부터 수신되면, 상태 머신은 probe_timer를 중지하고 Restart!를 호출하여 초기 상태로 돌아갈 수 있다. Restart! 이벤트를 수신하자마자, 위에서 설명된 바와 같이 상태 머신이 generate_address 기능을 수행하고 ReserveAddress! 이벤트를 호출할 수 있다. probe_timer가 만료되었지만 방어 메시지가 수신되지 않으면, 상태 머신이 probetimer! 이벤트를 호출하고 start_probe_timer 기능을 수행하며 probe_count를 감소시킨다. 노드는 또한 발견 메시지(즉, sProbe)를 이웃 노드 또는 발견 상태의 또 다른 노드로 송신할 있다. probe_count가 0 아래로 내려가면, 상태 머신이 probeCount! 이벤트를 호출하고, probe_timer를 중지하며, announce_timer를 시작할 수 있다. probeCount! 이벤트를 수신하자마자, 스테이션은 발표 메시지(즉, sAnnounce)를 송신하고 방어 상태에 진입한다.

또 다른 실시예에서, 스테이션은 또 다른 스테이션(예컨대, AP)에 송신된 발견 메시지에 대한 응답으로 프록시 응답 또는 제안 메시지를 수신할 수 있다. 프록시 응답 또는 제안 메시지를 수신하자마자, 상태 머신은 다양한 상태 표시와 함께 rProxyAnswer 이벤트를 호출할 수 있다. 예를 들어, 프록시 응답 또는 제안 메시지의 상태 표시가 1과 같으면, 상태 머신은 probe_timer를 중지하고 스테이션은 방어 상태에 진입할 수 있다. 1과 같은 상태 표시는 스테이션이 할당하려고 하는 MAC 주소가 사용 가능하다고 표시할 수 있다. 프록시 응답 또는 제안 메시지의 상태 표시가 2 또는 3과 같으면, 상태 머신이 probe_timer를 중지하고 Restart! 이벤트를 호출할 수 있고, 스테이션은 초기 상태에 진입할 수 있다. 2 또는 3과 같은 상태 표시는 스테이션이 할당하려고 하는 MAC 주소를 사용할 수 없다고 표시할 수 있다. 이 실시예는 IEEE 802.11 네트워크에 적용될 수 있다.

MAAP와 유사하게, MASAP는 P2P(Peer to Peer) 기반으로 동작할 수 있으며, 여기서 스테이션은 특정 MAC 주소 범위의 상태에 대해 서로 동의한다. 그러나 네트워크에서 프록시가 사용 가능한 경우, MASAP는 프록시가 발견 메시지에 제안 메시지로 응답하면서 프로빙 시간을 줄일 수 있는 기회를 제공할 수 있다. 프록시를 사용하면 연관되지 않은 클라이언트가 발표 또는 방어 메시지를 청취할 수 없는 기술에서 프로토콜이 동작할 수도 있다. 발견 메시지가 제안 메시지에 의해 응답되는 경우, 스테이션은 방어 상태를 중지하고 발표 메시지의 송신을 생략할 수 있는데, 그 이유는 프록시가 주소 상태의 북키핑을 처리할 수 있기 때문이다.

IEEE 802.11은 AP에 연관된 스테이션이 사전 연관된 상태로 송신된 프레임을 청취할 수 없는 것과 같은 일련의 상이한 특성을 가지고 있다. 이것은 ANQP를 통해 AP로 전송될 수 있는 발견 메시지의 경우일 수 있다. 이 경우, MASAP 프로토콜은 발견 메시지에 응답할 수 있는 프록시와 함께 실행될 수 있다. 이 동작 모드는 발표 메시지의 사용을 생략할 수도 있는데, 그 이유는 연관되지 않은 프로빙 노드는 이러한 메시지를 수신하지 않아 쓸모가 없기 때문이다. 또한, 제안 메시지로 달성된 현재 거동(예컨대, 성공적인 할당의 AP에 의한 표시)이 예를 들어, DENIED_MAC_ADDRESS_POLICY_VIOLATION과 같은 코드를 포함하는 IEEE 802.11 재연관(Reassociation) 프레임의 사용을 통해 달성될 수도 있다.

MASBAP는, 클라이언트가 네트워크의 MASBAP 서버(들) 또는 프록시로부터 주소를 발견하고 요청하면서, IEEE 802c SLAP 정의에 따라 유니캐스트 및 멀티캐스트 MAC 주소를 할당하는 데 사용할 수 있다.

MASBAP은 메시지 주소 지정을 위해 다음 규칙을 사용할 수 있다: 발견 메시지를 위한 소스 MAC 주소는 표 3에 표시된 범위에서 무작위로 선택될 것이다; 제안 메시지는 MASBAP 클라이언트가 소스 MAC 주소로서 사용될 MAC 주소를 운반할 수 있다; 요청 메시지를 위한 소스 MAC 주소는 이전에 할당된 MAC 주소, 스테이션에 할당된 EUI-64/48, 또는 제안 메시지에 의해 제공된 MAC 주소를 사용할 것이다; 발견 메시지를 위한 목적지 MAC 주소는 표 1에 지정된 멀티캐스트 주소에 대응한다; 그리고/또는 제안 및 ACK 메시지를 위한 목적지 MAC 주소는 발견 메시지의 소스 MAC 주소에 또는 ACK의 경우 요청 메시지의 소스로 사용되는 MAC 주소에 대응한다.

MASBAP 프로토콜은 다음과 같은 클라이언트 상태 머신을 통해 정의될 수 있다.

클라이언트 상태 머신은 다음 이벤트를 사용할 수 있다(이벤트는 끝에 !로 표시됨): 상태 머신이 초기화되거나 재초기화되는 Begin! 이벤트; 상태 머신의 이 인스턴스와 연관된 주소 범위가 더 이상 사용되지 않는다고 시그널링하는 Release! 이벤트; 오류가 검출되었고 상태 머신이 다시 시작될 것임을 시그널링하는 Restart! 이벤트; MASBAP 프로세스의 시작을 시그널링하는 RequestAddress! 이벤트; 제안 메시지가 수신됨을 시그널링하는 rOffer! 이벤트; ACK 메시지가 수신됨을 시그널링하는 rACK! 이벤트; 타이머 TIMER가 만료됨을 시그널링하는 eTIMER_expire! 이벤트; 송신된 메시지 MESSAGE의 수가 그 최댓값에 도달했음을 시그널링하는 MESSAGE_count! 이벤트; 및/또는 포트가 동작 상태에 진입했음을 시그널링하는 PortOperational! 이벤트.

클라이언트 상태 머신은 다음 동작이나 기능을 사용할 수 있다: 이 네트워크에 대해 이전에 알려진 MAC 주소가 알려져 있는지 그리고 이 주소가 발견 메시지에 포함될 필요가 있는지 여부를 결정하는 Select_address; 이 특정 대여(lease)에 대한 타이머를 시작하는 Start_TIMER_timer; 이 특정 대여에 대한 타이머를 중지하는 Stop_TIMER_timer; 메시지 카운트 카운터를 0으로 설정하는 Reset_MESSAGE_count; MESSAGE 카운트 카운터를 1씩 증가시키는 Increment_MESSAGE_count; 발견 메시지를 송신하는 sDISCOVER; 요청 메시지를 송신하는 sREQUEST; Validate_requirements - 이 동작은 발견 메시지의 요청된 파라미터의 부분적 충족이 클라이언트의 동작에 충분하다는 것을 검사하고, 상태 머신이 계속될 수 있으면 1을 반환하고 그렇지 않으면 0을 반환함 - ; 및/또는 Select_offer - 다수의 제안 메시지들이 수신되는 경우, 이 동작은 프로세스를 계속하기 위해 이 메시지들 중 하나를 선택하고, 하나의 메시지를 선택하기 위한 매커니즘은 발견에 송신된 요청된 파라미터를 준수하는 레벨과 관련될 수 있음 -.

클라이언트 상태 머신은 표 3에 명시된 4개의 상태를 기반으로 할 수 있다.

상태	설명
초기	상태 머신의 시작
발견	발견이 송신됨, 응답을 대기 중
요청	제안이 수신됨, 요청이 송신됨, 응답을 대기 중
바운드(Bound)	주소가 선택됨, ACK가 수신됨

MASBAP 클라이언트 상태

표 4는 MASBAP 클라이언트의 상태 머신을 보여준다.

		상태
		초기	발견	요청	바운드
이벤트	Begin!	Select_address RequestAddress!	-X-	-X-	-X-
	Release!	-X-	Stop_OfferRcv_timer INITIAL	Stop_ACKRcv_timer INITIAL	Stop_LifeTime_timer INITIAL
	Restart!	Select_address RequestAddress!	Stop_OfferRcv_timer INITIAL	Stop_ACKRcv_timer INITIAL	Stop_LifeTime_timer INITIAL
	RequestAddress!	Reset_DISCOVER_count Start_OfferRcv_timer sDISCOVER DISCOVER	-X-	-X-	-X-
	rOffer!	-X-	Select_Offer Validate_requirements^a Stop_OfferRcv_timer sREQUEST Reset_REQUEST_count Start_ACKRcv_timer REQUEST	-X-	-X-
	rACK!(status=3)	-X-	Stop_ACKRcv_timer INITIAL	Stop_ACKRcv_timer INITIAL	-X-
	rACK!(status=4)	-X-	-X-	Stop_ACKRcv_timerStart_Lifetime_timer BOUND	-X-
	rACK!(status=5-7)	-X-	Stop_ACKRcv_timer INITIAL	Stop_ACKRcv_timer REQUEST/rOffer!	-X-
	rACK!(status=9)	-X-	Stop_ACKRcv_timer INITIAL	Stop_ACKRcv_timer INITIAL	-X-
	rACK!(status=11)	-X-	Stop_ACKRcv_timer INITIAL	Stop_ACKRcv_timer REQUEST/rOffer!	-X-
	eOfferRcv_expire!	-X-	Increment_DISCOVER_count sDISCOVER start_OfferRcv_timer	-X-	-X-
	eACKRcv_expire!	-X-	-X-	Increment_REQUEST_count sREQUEST start_ACKRcv_timer	-X-
	eLifeTime_expire! ^b	-X-	-X-	-X-	INIT/Restart!
	DISCOVER_count!	-X-	Stop_OfferRcv_timer INIT/Restart!	-X-	-X-
	REQUEST_count!	-X-	-X-	Stop_ACKRcv_timer INIT/Restart!	-X-
	PortOperational!	Select_address INITIAL/Request_Address!	INITIAL/Restart!	INITIAL/Restart!

MASBAP 클라이언트 상태 머신

^aValidate_requirements가 0을 반환하는 경우, OFFER_timer는 중지되지 않고 클라이언트는 다른 제안 메시지가 도착하기를 계속 기다린다.

^b 이 이벤트는 수명이 만료되기 전에 클라이언트가 리바인드(rebind)하려는 스테이션 ID 및 MAC 주소 범위를 포함하는 서버에 요청 메시지를 송신할 수 있는 수명 타이머의 만료를 표시한다.

MASBAP 서버와 관련하여, 해당 동작은 완전히 무상태일 수 있다. 클라이언트에 제공된 모든 정보는 ACK가 송신될 때까지 정보용(informational)(즉, 할당되지 않음)으로 취급되어야 한다. ACK를 송신한 후에만, 서버는 특정 스테이션에 할당된 MAC 주소 또는 MAC 주소 범위를 차단할 수 있다.

실시예에서, 표 4에 표시된 바와 같이, Begin! 이벤트를 수신하자마자, 노드에서 실행 중인 상태 머신이 select_address 기능을 수행하고 초기 상태에서 RequestAddress! 이벤트를 호출할 수 있다. RequestAddress! 이벤트를 수신하자마자, 상태 머신이 DISCOVER_count를 재설정하고 OfferRcv_timer를 시작할 수 있다. 노드는 또한, 발견 메시지를 프록시(또는 서버)에 송신하고 제안 메시지가 프록시로부터 수신되거나 OfferRcv_timer가 만료될 때까지 발견 상태에 진입할 수 있다. OfferRcv_timer가 만료되었지만 제안 메시지가 수신되지 않은 경우, 상태 머신은 eOfferRcv_expire! 이벤트를 호출할 수 있다. eOfferRcv_expire! 이벤트를 수신하자마자, 상태 머신이 DISCOVER_count를 증가시키고 OfferRcv_timer를 시작할 수 있다. 노드는 발견 상태의 프록시에 발견 메시지를 송신할 수도 있다. 제안 메시지가 프록시로부터 수신되면, 상태 머신이 rOffer! 이벤트를 호출할 수 있다. rOffer! 이벤트를 수신하자마자, 상태 머신은 제안을 선택하고, 요건을 검증하고, OfferRcv_timer를 중지하고, ACKRcv_timer를 시작하며, REQUEST_count를 재설정할 수 있다. 노드는 또한 프록시에 요청 메시지를 송신하고 ACK 메시지가 프록시로부터 수신되거나 ACKRcv_timer가 만료될 때까지 요청 상태에 진입할 수 있다.

ACKRcv_timer가 만료되었지만 ACK 메시지가 수신되지 않은 경우, 상태 머신은 eACKRcv_expire! 이벤트를 호출할 수 있다. eACKRcv_expire!를 수신하자마자, 상태 머신은 REQUEST_count를 증가시키고 ACKRcv_timer를 시작할 수 있다. 노드는 요청 상태의 프록시에 요청 메시지를 송신할 수도 있다. ACK 메시지가 프록시로부터 수신되면, 상태 머신은 다양한 상태 표시를 갖는 rACK! 이벤트를 호출할 수 있다. 예를 들어, 상태 표시 값이 3 또는 9이면, 상태 머신은 ACKRcv_timer를 중지하고 초기 상태로 돌아갈 수 있다. 상태 표시 값이 5, 6, 7 또는 11이면, 상태 머신은 ACKRcv_timer를 중지하고 rOffer! 이벤트를 호출하며 요청 상태로 돌아간다. 상태 표시 값이 4이면, 상태 머신은 ACKRcv_timer를 중지하고, Lifetime_timer를 시작하며, 바운드(BOUND) 상태로 진입할 수 있다. 바운드 상태에서, 노드에 MAC 주소가 할당되었고 노드는 Lifetime_timer를 중지할 수 있다.

일 실시예에서, 공격자가 서버에서 사용 가능한 모든 가능한 주소를 차단하려고 시도하는 주소 소진 공격으로부터 여기에서 논의된 바와 같은 프로토콜의 약점이 있을 수 있다. 일반적으로 옵션의 카운트 필드에 대한 한 가지 정의로, 서버와의 2^34개의 상호 작용이 필요할 수 있다. 서버에서 사용할 수 있는 MAC 주소 범위가 주소 공간의 48비트를 모두 포함하지 않는 상황에서는, 서버를 사용해 단일 반복으로 요청될 수 있는 최대 주소 수를 줄이는 것이 좋다. 클라이언트가 허용된 것보다 더 많은 주소를 요청하는 상황에서, 상태 11(파라미터 문제)을 갖는 ACK 메시지는 발견 또는 요청 메시지에 응답되어야 한다.

도 2는 멀티캐스트 및 유니캐스트 MAC 주소 할당 프로토콜(MUMAAP)이 구현되는 예시적인 통신 시스템(200)을 도시하는 시스템도이다. 도 2에 도시된 바와 같이, MUMAAP용 통신 시스템(200)은 노드(202a, 202b, 202c, 202d), 프록시(또는 서버)(210, 230), 및 프록시(또는 서버)(220)를 접속하는 네트워크 디바이스를 포함할 수 있다. 노드(202a, 202b, 202c, 202d)는 유선 또는 무선 신호를 송신 및/또는 수신하도록 구성된 클라이언트로 지칭될 수 있다. 노드(202a, 202b, 202c, 202d)의 예는 스테이션(STA), WTRU, 사용자 장비(UE), 이동국, 스마트폰, 랩톱, 넷북, 개인용 컴퓨터, 무선 센서, 사물인터넷(Internet of Things; IoT) 디바이스, 및 웨어러블 디바이스를 포함할 수 있지만 이에 제한되지 않는다. 프록시(210, 230)는 유선 또는 무선 신호를 송신 및/또는 수신하도록 구성된 서버로서 지칭될 수 있다. 프록시(210, 230)의 예는 서버, 기지국, 스위치, 사이트 제어기, 액세스 포인트(access point; AP), 하이퍼바이저 및 라우터를 포함할 수 있지만 이에 제한되지 않는다. 네트워크 디바이스(220)는 프록시(210, 230)를 접속할 수 있는 임의의 유형의 디바이스일 수 있다.

MUMAAP를 구현하는 일 실시예에서, 노드(202a)는 프록시(210)의 유니캐스트 매체 액세스 제어(MAC) 주소 또는 프록시(210)와 연관되거나 프록시(210)가 청취할 멀티캐스트 MAC 주소에 기초하여 발견 메시지를 프록시(210)에 송신할 수 있다. 발견 메시지는 MAC 주소 또는 MAC 주소 범위(즉, 제1 MAC 주소 또는 제1 MAC 주소 범위)를 포함하거나 포함하지 않을 수 있다. MAC 주소 또는 MAC 주소 범위가 발견 메시지에 포함된 경우, MAC 주소 또는 MAC 주소 범위는 이전 MAC 주소 할당 정보에 기초하여 결정될 수 있다. 이전 MAC 주소 할당 정보는 이전 MAC 주소 또는 MUMAAP를 사용하여 노드(202a)에 할당된 주소 범위를 포함할 수 있다. 대안적으로 또는 추가적으로, 발견 메시지에 포함된 MAC 주소 또는 MAC 주소의 범위는 무작위로 결정될 수 있다. 노드(202a)는 초기 MAC 주소로 미리 구성되거나 구성되지 않을 수 있음에 유의한다. 예를 들어, 노드(202a)의 네트워크 카드는 하드웨어에 MAC 주소 없이 제조되었다.

발견 메시지를 프록시(210)로 송신한 후, 노드(202a)는 카운터 값을 수신하고 예를 들어, 1만큼 증가시킬 것으로 예상되는 제안 메시지와 연관된 타이머를 개시할 수 있다. 카운터 값은 발견 메시지의 송신 횟수를 나타낼 수 있다. 프록시(210)로부터 제안 메시지가 수신되면, 타이머는 재설정되거나 초기화될 수 있다. 제안 메시지가 수신되지 않고, 타이머가 만료되지 않고, 카운터 값이 미리 결정된 수 미만인 경우, 노드(202a)는 프록시(210)의 유니캐스트 MAC 주소 또는 프록시(210)와 연관되거나 프록시(210)가 청취하고 있는 멀티캐스트 MAC 주소를 사용하여 발견 메시지를 프록시(210)에 재송신할 수 있다.

발견 메시지를 프록시(210)로 송신한 후, 노드(202a)는 프록시(210)로부터 제안을 수신할 수 있다. 제안은 노드(202a)에 할당될 수 있는 MAC 주소의 범위(즉, 제2 범위의 MAC 주소)를 포함할 수 있다. MAC 주소의 이 범위는 프록시(210)에서 사용 가능한 MAC 주소 풀에 기초하여 프록시(210)에 의해 결정될 수 있다. MAC 주소의 범위를 결정할 때, 프록시(210)는 또한 노드(202a)로부터 (발견 메시지에서) 수신된 MAC 주소 또는 MAC 주소의 범위를 고려할 수 있다. 프록시(210)에 의해 결정되는 MAC 주소의 범위는 유니캐스트 MAC 주소의 범위 또는 멀티캐스트 MAC 주소의 범위일 수 있다.

제안 메시지를 수신하자마자, 노드(202a)는 제안 메시지 내의 MAC 주소의 범위로부터 MAC 주소(즉, 제2 MAC 주소)를 선택할 수 있다. 선택된 MAC 주소는 노드(202a)에 할당될 유니캐스트 MAC 주소 또는 멀티캐스트 MAC 주소일 수 있다. 노드(202a)는 (제1) MAC 주소 또는 발견 메시지에서 송신된 (제1) MAC 주소 범위에 기초하여 (제2) MAC 주소를 선택할 수 있다. 예를 들어, 선택된 (제2) MAC 주소는 송신된 (제1) MAC 주소와 동일하거나 송신된 (제1) MAC 주소 범위 내에 있을 수 있다.

(제2) MAC 주소를 선택하자마자, 노드(202a)는 (제2) MAC 주소 또는 (제2) MAC 주소 범위를 포함하는 요청 메시지를 프록시(210)에 송신하여, (제2) MAC 주소 또는 (제2) MAC 주소 범위가 노드(202a)에 할당됨을 표시한다. 그 후, 노드(202a)는, 제2 MAC 주소 또는 제2 범위의 MAC 주소가 제1 노드에 할당됨을 표시하는 ACK 메시지를 프록시(210)로부터 수신할 수 있다.

MUMAAP를 구현하는 또 다른 실시예에서, 노드(202b)는 노드(202c)의 유니캐스트 매체 액세스 제어(MAC) 주소 또는 노드(202c)와 연관된(예컨대, 노드(202c)가 청취할) 멀티캐스트 MAC 주소에 기초하여 발견 메시지를 노드(202c)에 송신할 수 있다. 노드(202b)는 또한 카운터 및 타이머를 개시할 수 있다. 발견 메시지는 MAC 주소 또는 MAC 주소 범위를 포함할 수 있고 MAC 주소 또는 MAC 주소 범위가 사용 가능한지(즉, 노드(202b)에 할당될 수 있는지) 여부를 검증하기 위해 다른 노드(202a, 202c, 202d) 또는 프록시(210, 230)에 송신될 수 있다. MAC 주소 또는 MAC 주소의 범위는 노드(202b)에 이전에 할당된 MAC 주소 또는 MAC 주소의 범위에 기초하여 결정될 수 있다. 대안적으로 또는 추가적으로, 발견 메시지에 포함된 MAC 주소 또는 MAC 주소의 범위는 무작위로 결정될 수 있다. 노드(202b)는 초기 MAC 주소로 미리 구성되거나 구성되지 않을 수 있음에 유의한다. 예를 들어, 노드(202b)의 네트워크 카드는 하드웨어에 MAC 주소 없이 제조되었다.

타이머가 실행되는 동안 노드(202c)로부터 방어 메시지가 수신되면, 노드(202b)는 타이머를 중지하고 새로운 MAC 주소 또는 MAC 주소의 새로운 범위를 갖는 발견 메시지를 생성할 수 있다. 방어 메시지는 송신된 MAC 주소 또는 MAC 주소의 범위가 노드(202b)에 대한 할당을 위해 사용가능하지((즉, 노드(202c)에 의해 사용되지) 않음을 나타낼 수 있다. 새로운 MAC 주소 또는 MAC 주소의 새로운 범위가 생성되면, 노드(202b)는 노드(202c)의 유니캐스트 MAC 주소 또는 노드(202c)와 연관된(또는 노드(202c)가 청취 중인) 멀티캐스트 MAC 주소에 기초하여 발견 메시지를 노드(202c)에 송신할 수 있다. 방어 메시지가 수신되지 않았지만 타이머가 만료된 경우, 노드(202b)는 타이머를 재설정하고 카운터를 감소시킬 수 있다. 카운터가 0 아래로 내려가면, 노드(202b)는 MAC 주소 또는 MAC 주소의 범위가 노드(202b)에 할당됨을 표시하는 발표 메시지를 다른 노드(202a, 202c, 202d)에 송신할 수 있다.

또 다른 실시예에서, 노드(202d)(예컨대, 스테이션)는 프록시(230)의 유니캐스트 매체 액세스 제어(MAC) 주소 또는 프록시(230)와 연관된(또는 프록시(230)가 청취할) 멀티캐스트 MAC 주소에 기초하여 발견 메시지를 프록시(230)(예컨대, AP)로 송신할 수 있다. 발견 메시지는 MAC 주소 또는 MAC 주소의 범위가 노드(202d)에 대한 할당을 위해 사용 가능한지를 검증하기 위해 MAC 주소 또는 MAC 주소의 범위를 포함할 수 있다. MAC 주소 또는 MAC 주소의 범위는 노드(202d)에 이전에 할당된 MAC 주소 또는 MAC 주소의 범위에 기초하여 결정될 수 있다. 대안적으로 또는 추가적으로, 발견 메시지에 포함된 MAC 주소 또는 MAC 주소의 범위는 무작위로 결정될 수 있다. 노드(202d)는 초기 MAC 주소로 미리 구성되거나 구성되지 않을 수 있음에 유의한다. 발견 메시지에 응답하여, 노드(202d)는 프록시(230)로부터 다양한 상태 표시를 갖는 제안 메시지를 수신할 수 있다. 1과 동일한 상태 표시로, 노드(202d)는 MAC 주소 또는 발견 메시지에서 송신된 MAC 주소의 범위가 할당될 수 있다는 것을 이해할 수 있다. 2 또는 3과 동일한 상태 표시로, 노드(202d)는 발견 메시지에서 송신된 MAC 주소 또는 MAC 주소의 범위가 할당할 수 없거나 오류가 프록시(230)와 노드(202d) 사이에 발생되었다는 것을 이해할 수 있다.

도 3은 예시적인 MUMAAP 절차(300)를 예시하는 도면이며, 이는 본 명세서에 설명된 임의의 다른 실시예와 조합하여 사용될 수 있다. 단계(310)에서, 유선 또는 무선 네트워크의 제1 노드는 제2 노드의 유니캐스트 MAC 주소 또는 제2 노드와 연관되거나 제2 노드가 청취할 멀티캐스트 MAC 주소를 사용하여 발견 메시지를 제2 노드로 송신할 수 있다. 발견 메시지는 제1 MAC 주소 또는 제1 범위의 MAC 주소를 포함하거나 포함하지 않을 수 있다. 발견 메시지가 제1 MAC 주소 또는 제1 범위의 MAC 주소를 포함하는 경우, 제1 MAC 주소 또는 제1 범위의 MAC 주소는 이전 MAC 주소 할당 정보에 기초하여 결정될 수 있다. 예를 들어, 이전 MAC 주소 할당 정보는 제1 노드가 턴온되기 전에 제1 노드에 할당되었던 MAC 주소 또는 MAC 주소의 범위일 수 있다.

단계(320)에서, 제1 노드는 제2 노드로부터 제2 범위의 MAC 주소를 갖는 제안 메시지를 수신할 수 있다. 제2 범위의 MAC 주소는 제2 노드에 사용 가능한 MAC 주소 풀에 기초하여 제2 노드에 의해 결정될 수 있다. MAC 주소 또는 MAC 주소의 범위는 제2 범위의 MAC 주소에 기초하여 제1 노드에 할당될 수 있다. 제2 범위의 MAC 주소는 유니캐스트 MAC 주소들의 범위 또는 멀티캐스트 주소들의 범위를 포함할 수 있다.

단계(330)에서, 제1 노드는 제2 범위의 MAC 주소로부터 제2 MAC 주소를 선택할 수 있다. 선택된 제2 MAC 주소는 제1 MAC 주소와 동일하거나 제1 범위의 MAC 주소 내에 있을 수 있다. 제2 MAC 주소는 제1 노드에 할당될 유니캐스트 MAC 주소 또는 멀티캐스트 MAC 주소일 수 있다.

단계(340)에서, 제1 노드는, 제2 MAC 주소 또는 제2 범위의 MAC 주소가 제1 노드에 할당됨을 나타내는 요청 메시지를 제2 노드에 송신할 수 있다. 요청 메시지에 대한 응답으로, 단계(350)에서, 제1 노드는 제2 MAC 주소 또는 제2 범위의 MAC 주소가 네트워크의 제1 노드에 할당됨을 나타내는 확인 응답 메시지를 제2 노드로부터 수신할 수 있다. 제1 노드는 미리 구성된 초기 MAC 주소를 갖거나 갖지 않는 클라이언트일 수 있고, 제2 노드는 프록시 또는 서버일 수 있다. 발견, 제안, 요청 및 확인 응답 메시지 각각은 IEEE 802.1CQ를 나타내는 서브유형(subtype)과 함께 오디오/비디오 전송 프로토콜(Audio/Video Transport Protocol; AVTP)를 나타내는 프로토콜 유형으로 프레임에 캡슐화될 수 있다.

예시적인 메시지 형식에 대한 실시예가 여기에서 설명된다. 모든 MUMAAP 프레임의 EtherType은 표 5에 주어진 EtherType일 수 있다.

MUMAAP EtherType

FD₁₆(예로서)

MUMAAP EtherType

여기에서 논의된 프로토콜(들)의 메시지 형식은 프로토콜의 모든 메시지에 포함될 수 있는 공통 제어 헤더를 사용할 수 있다. 제어 헤더의 예는 표 6에 있다.

0 7 8 10 11 15 16 31
서브유형	ver	메시지_유형	제어_워드
쿠키			상태	길이

MUMAAP 기본 헤더

제어 헤더의 상이한 필드들은 다음과 같을 수 있다: 서브유형 유형(8비트) - 1-옥텟 서브유형 필드는 표 7에 정의된 대로 MUMAAP에 의해 운반되는 형식을 식별하고 MASAP와 MASBAP 프로토콜을 구별하는 데 사용됨 - ; 버전(3비트) - 프로토콜의 버전을 나타내는 3개의 비트가 있을 수 있음(여기에 개시된 바와 같이, 0으로 설정된 모든 비트는 프로토콜의 첫 번째 버전을 나타낼 수 있음) - ; 표 8에 정의된 바와 같이 정의된 MUMAAP 메시지 유형 중 하나를 포함하는 필드인 메시지_유형(message_type)(5비트) - MUMAAP 메시지가 예약된 메시지_유형으로 수신되는 경우, MUMAAP 프레임은 무시될 수 있음 - ; 표 9에 도시된 바와 같은 플래그를 포함할 수 있는 제어_워드(control_word)(16비트); MUMAAP 변형의 모든 새로운 트랜잭션에 대해 로컬 카운터로부터 증가되어야 하는 필드인 쿠키(16비트) - 또 다른 프레임을 수신한 결과로서 유래하는 프레임들은 이들이 동일한 대화(dialog)에 속하기 때문에 원래 프레임의 쿠키를 복사할 수 있음 - ; 상태(4비트) - 상태 코드는 표 10에서 선택될 수 있는 동작의 결과를 나타낼 수 있음 - ; 및/또는 옥텟 단위의 메시지 길이인 길이(12비트).

MUMAAP 서브유형
MUMAAP	01

MUMAAP 서브유형

값	기능	설명
0	---	예약됨
1	발견	MAC 주소(들)를 프로빙함
2	방어	MAC 주소(들)를 방어함
3	발표	MAC 주소(들)를 발표함
4	제안	프록시로부터의 프로빙 메시지에 대한 응답
5	제안	서버로부터의 MAC 할당 제안
6	요청	할당될 주소의 확인
7	ACK	서버로부터 스테이션으로의 할당 확인 또는 오류 보고
8-1024	--	예약됨

메시지 유형

비트	명칭	설명
0	AAI	1로 설정된 비트: AAI 공간의 주소가 요청/제공됨
1	ELI	1로 설정된 비트: ELI 공간의 주소가 요청/제공됨
2	SAI	1로 설정된 비트: SAI 공간의 주소가 요청/제공됨
3	예약됨	향후 사용을 위해 예약됨
4	64/48 비트	1로 설정된 비트: 64 비트 주소가 요청/제공됨0으로 설정된 비트: 48 비트 주소가 요청/제공됨
5	멀티캐스트/유니캐스트	1로 설정된 비트: 멀티캐스트 주소가 요청/제공됨 0으로 설정된 비트: 유니캐스트 주소가 요청/제공됨
6	인프라/스테이션	1로 설정된 비트: 메시지 소스는 서버/프록시이다. 0으로 설정된 비트: 메시지 소스는 엔드 노드이다.
7	MAC가 제공됨	1로 설정된 비트: MAC 주소가 제공된다. 0으로 설정된 비트: MAC 주소가 제공되지 않는다. 이 비트는 서버에 힌트로서 이미 사용된 MAC 주소를 제공하는 스테이션에 의해 사용된다.
8	스테이션 ID가 제공됨	1로 설정된 비트: 스테이션 ID가 제공된다. 0으로 설정된 비트: 스테이션 ID가 제공되지 않는다.
9	네트워크 ID가 제공됨	1로 설정된 비트: 네트워크 ID가 제공된다. 0으로 설정된 비트: 네트워크 ID가 제공되지 않는다.
10	코드 필드가 제공됨	1로 설정된 비트: 메시지가 코드 필드를 포함한다. 0으로 설정된 비트: 메시지가 코드 필드를 포함하지 않는다
11	특정 주소 유형	1로 설정된 비트: 특정 주소 유형 정보가 제공된다. 0으로 설정된 비트: 특정 주소 유형 정보가 제공되지 않는다
12	소스 MAC 주소가 제공됨	1로 설정된 비트: 요청의 소스로 사용될 특정 주소가 제공된다. 0으로 설정된 비트: 요청의 소스로서 사용될 특정 주소가 제공되지 않는다.
13-15	예약됨	향후 사용을 위해 예약됨

제어 워드 거동

값	설명
0	필드가 사용되지 않음
1	사용되지 않는 MAC 범위
2	사용 중인 MAC 범위
3	주어진 프리픽스에서 주소를 재생성하고 MASAP를 사용함
4	ACK - 할당이 수락됨
5	실패 - 할당이 완료될 수 없음
6	실패 - 요청된 사분면을 사용할 수 없음
7	실패 - 요청한 범위를 사용할 수 없음
8	제안이 제공됨
9	MASAP의 필수적 사용
10	MASBAP의 필수적 사용
11	파라미터 문제
12	제안이 제공됨 - 부분적 이행
13-15	예약됨

상태 값

MASAP 메시지는 운반되는 실제 메시지에 따라 프로토콜에 의해 송신될 수 있는 다양한 옵션을 포함할 수 있다. 초기에, 전송될 수 있는 옵션이 정의되고, 나중에 메시지에 추가될 수 있는 옵션이 각 메시지 및 각 메시지가 운반할 필요가 있는 값에 대해 표시될 수 있다. 모든 옵션에 대해 유형 필드가 표 11에 보여 진다. 길이는 옵션의 길이를 옥텟으로 표현한다.

유형 ID	설명
0	스테이션 ID
1	48비트 MAC 주소(범위)
2	64비트 MAC 주소(범위)
3	네트워크 ID
4	특정 MAC 범위
5	충돌 시 48비트 MAC 범위
6	충돌 시 64비트 MAC 범위
7	MAC 주소 카운트
8	수명

옵션 코드 값

스테이션 ID 옵션은 표 12에 보여진 바와 같이 스테이션의 식별자를 포함하기 위해 최대 255바이트를 제공할 수 있다.

유형	길이	스테이션 식별자
1 옥텟	1 옥텟	최대 255 옥텟

스테이션 ID

스테이션 ID가 자신과 일치하지 않는 발견, 발표 또는 방어와는 다른 메시지를 수신하는 스테이션의 모든 경우에, 패킷이 폐기(drop)되고 프로세싱이 중지되어야 한다.

48비트 MAC 주소(범위)의 경우, 이 옵션은 48비트의 MAC 주소와 요청된 주소의 양을 나타내는 16비트 숫자를 전송하기 위한 메커니즘을 제공할 수 있다. 범위가 아닌 단일 주소가 지정되길 원하면, 카운트가 1로 설정되어야 한다. 카운트가 1보다 크면, 카운트는 MAC 주소에서 시작하여 카운트까지의 다음 순차 주소를 포함하여 다수의 MAC 주소가 할당되거나 요청됨을 나타낼 수 있다. 예를 들어, 표 13을 참조한다.

유형	길이	MAC 주소	카운트
1 옥텟	1 옥텟	48 비트	16 비트

48 비트 MAC 주소

64비트 MAC 주소(범위)의 경우, 이 옵션은 64비트의 MAC 주소와 요청된 주소의 양을 나타내는 16비트 숫자를 전송하는 메커니즘을 제공할 수 있다. 범위가 아닌 단일 주소가 지정되길 원하면, 카운트가 1로 설정될 필요가 있을 수 있다. 예를 들어, 표 14를 참조한다.

유형	길이	MAC 주소	카운트
1 옥텟	1 옥텟	64 비트	16 비트

64 비트 MAC 주소

네트워크 ID의 경우, 이 옵션은 네트워크 식별자를 포함하기 위해 최대 255바이트를 제공할 수 있다. 예를 들어, 표 15를 참조한다.

유형	길이	네트워크 식별자
1 옥텟	1 옥텟	최대 255 옥텟

네트워크 ID

특정 MAC 범위의 경우, 서버가 스테이션이 특정 주소 공간에서 자체 청구(self-claiming)를 수행하도록 요청하기 위해 이 옵션이 포함될 수 있다. 예를 들어, 표 16을 참조한다.

유형	길이	MAC 주소 프리픽스 서브필드의 길이(바이트)	프리픽스 트림 서브필드(비트)	예약됨	MAC 주소 프리픽스(바이트)
1 옥텟	1 옥텟	3 비트	3 비트	2 비트	0 내지 8 바이트

특정 MAC 범위

MAC 주소 프리픽스 바이트 서브필드의 길이는 3비트의 서브필드일 수 있다. MAC 주소 프리픽스 서브필드의 길이가 1 내지 6의 값 중 하나로 설정되면, 해당 값은 MAC 주소 프리픽스 바이트 필드의 길이(예컨대, 옥텟)를 나타낼 수 있다. 일부 경우에, MAC 주소 프리픽스 바이트 서브필드의 길이가 0 또는 7로 설정되지 않는데, 그 이유는 그 값이 예약되어 있을 수 있기 때문이다.

프리픽스 트림 서브필드는 3비트의 서브필드일 수 있으며 0 내지 7의 값 중 하나를 취하며, 여기서 해당 값은 MAC 주소 프리픽스를 얻기 위해 MAC 주소 프리픽스 서브필드의 끝에서 잘릴 비트 수를 나타낸다. 즉, MAC 주소 프리픽스는 마지막 옥텟의 최상위 비트 중 일부가 잘린 후 MAC 주소 프리픽스 바이트 필드의 값으로서 표현될 수 있으며, 잘린 비트의 수는 프리픽스 트림 서브필드의 값과 같다.

MAC 주소 프리픽스 바이트 필드는 1 내지 8 옥텟의 필드일 수 있으며, 길이는 각 프리픽스 트림 서브필드에 대한 절단 전에, 주소 자체 할당과 관련된 MAC 주소 프리픽스의 전체 바이트를 포함할 수 있는, 정책 플래그 필드의 MAC 주소 프리픽스 서브필드의 길이에서 시그널링된다.

충돌하는 48비트 MAC 범위의 경우, 이 옵션은 충돌하는 48비트의 MAC 주소와 충돌하는 주소의 양을 나타내는 16비트 숫자를 전송하는 메커니즘을 제공할 수 있다. 범위가 아닌 단일 주소가 지정되길 원하면, 카운트가 1로 설정될 필요가 있을 수 있다. 예를 들어, 표 17을 참조한다.

유형	길이	MAC 주소	카운트
1 옥텟	1 옥텟	48 비트	16 비트

48 비트 MAC 범위

충돌하는 64비트 MAC 범위의 경우, 이 옵션은 충돌하는 64비트의 MAC 주소와 충돌하는 주소의 양을 나타내는 16비트 숫자를 전송하는 메커니즘을 제공할 수 있다. 범위가 아닌 단일 주소가 지정되길 원하면, 카운트가 1로 설정될 필요가 있을 수 있다. 예를 들어, 표 18을 참조한다.

유형	길이	MAC 주소	카운트
1 옥텟	1 옥텟	64 비트	16 비트

64 비트 MAC 범위

MAC 주소 카운트에 대해, 이 옵션은 스테이션이 MAC 주소 범위를 제공하지 않고 여러 주소를 요청할 수 있는 메커니즘을 제공할 수 있다. 예를 들어, 표 19를 참조한다.

유형	길이	MAC 주소 카운트
1 옥텟	1 옥텟	1 내지 2 옥텟

MAC 주소 카운트

MAC 주소 카운트 옵션이 요청에 없는 경우, 이 요청이 단일 MAC 주소에 대한 것이라고 가정될 수 있다.

수명의 경우, 이 옵션은 서버가 특정 MAC 주소 대여(leasing)에 대한 수명을 설정하게 할 수 있다. 예를 들어, 표 20을 참조한다.

유형	길이	수명
1 옥텟	1 옥텟	2 옥텟

수명

MASAP 프로토콜 메시지와 관련하여, 프로토콜을 자체 청구하는 것은 다음과 같은 메시지 정의를 사용할 수 있다. 발견의 경우, 이 메시지는 가용(free) MAC 주소 범위를 프로빙하기 위해 사용될 수 있다. 발견 메시지에는 표 21의 다음 옵션을 포함할 수 있다.

0 7 8 10 11 15 16 31
서브유형	ver	메시지_유형	제어_워드
쿠키			상태	길이
(선택사항) 스테이션 ID
48 비트 MAC 주소(범위) 또는 64비트 MAC 주소(범위)

발견

제어_워드의 경우, 다음 목록에 따라 비트가 1 또는 0으로 전환될 필요가 있을 수 있다: 비트 0 내지 2는 자체 청구되는 주소가 속한 사분면에 따라 1로 설정될 필요가 있을 수 있다; 비트 4는 자체 청구되는 주소가 64비트인지 또는 48비트인지를 나타낼 수 있다; 비트 5는 주소가 유니캐스트인지 또는 멀티캐스트인지를 나타낼 수 있다; 비트 6은 이 메시지가 스테이션에서 시작됨을 나타내는 0으로 설정될 수 있다; 그리고/또는 비트 7은 메시지가 MAC 주소를 운반함을 나타내는 1로 설정될 필요가 있을 수 있다.

상태의 경우, 이 필드는 이 메시지에서 0으로 설정될 필요가 있을 수 있다.

스테이션 ID의 경우, 이 ID는 이 메시지를 송신하는 스테이션의 ID를 선택적으로 포함할 수 있다.

48비트 MAC 주소(범위) 또는 64비트 MAC 주소(범위)의 경우, 이들은 요청되는 주소의 연속 범위 중 첫 번째 주소일 수 있다. 카운트 필드는 요청되는 주소의 수일 수 있다. 단일 주소만 요청되는 경우, 이 필드는 1로 설정될 수 있다.

방어와 관련하여, 이 메시지는 이미 획득한 MAC 주소 범위를 방어하는 데 사용될 수 있다. 예를 들어, 표 22를 참조한다.

0 7 8 10 11 15 16 31
서브유형	ver	메시지_유형	제어_워드
쿠키			상태	길이
(선택사항) 스테이션 ID
48 비트 MAC 주소(범위) 또는 64비트 MAC 주소(범위)
충돌 시 48 비트 MAC 범위 또는 충돌 시 64비트 MAC 범위

방어

제어_워드의 경우, 이 메시지를 트리거한 발견 메시지로부터의 값을 복사하여 비트가 1 또는 0으로 전환될 필요가 있을 수 있으며, 여기서: 비트 0 내지 2는 자체 청구되는 주소가 속한 사분면에 따라 1로 전환될 필요가 있을 수 있다; 비트 4는 자체 청구되는 주소가 64비트인지 또는 48비트인지를 나타낼 수 있다; 비트 5는 주소가 유니캐스트인지 또는 멀티캐스트인지를 나타낼 수 있다; 비트 6은 메시지가 스테이션에서 유래됨을 나타내는 0으로 설정될 수 있다; 그리고/또는 비트 7은 메시지가 MAC 주소를 운반함을 나타내는 1로 설정될 필요가 있을 수 있다.

스테이션 ID의 경우, 이 ID는 원래 발견 메시지로부터 복사될 수 있다. 이 메시지를 발생시키는 발견 메시지가 스테이션 ID를 포함하면, 이 옵션은 발견 메시지에 있는 옵션으로부터 복사될 필요가 있을 수 있다.

48비트 MAC 주소(범위) 또는 64비트 MAC 주소(범위)의 경우, 이들은 원래의 발견 메시지로부터 복사될 수 있다.

충돌 시 48비트 MAC 범위 또는 충돌 시 64비트 MAC 범위의 경우, 이들은 발견으로부터의 요청된 주소 범위와 충돌하는 첫 번째 주소로 설정될 수 있다. 이 경우 카운트는 그 범위에서 충돌하는 주소의 수로 설정될 수 있다.

발표와 관련하여 이 메시지는 이미 할당된 MAC 주소 범위를 발표하는 데 사용될 수 있다. 예를 들어, 표 23을 참조한다.

발표

제어_워드의 경우, 비트들은 다음 목록에 따라 1 또는 0으로 전환될 필요가 있을 수 있다: 비트 0 내지 2는 자체 청구되는 주소가 속한 사분면에 따라 1로 전환될 필요가 있을 수 있다; 비트 4는 자체 청구되는 주소가 64비트인지 또는 48비트인지를 나타낼 수 있다; 비트 5는 주소가 유니캐스트인지 또는 멀티캐스트인지를 나타낼 수 있다; 비트 6은 이 메시지가 스테이션에서 시작됨을 나타내는 0으로 설정될 수 있다; 그리고/또는 비트 7은 메시지가 MAC 주소를 운반함을 나타내는 1로 설정될 필요가 있을 수 있다.

48비트 MAC 주소(범위) 또는 64비트 MAC 주소(범위)의 경우, 이들은 스테이션에 할당되는 주소의 연속 범위 중 첫 번째 주소일 수 있다. 카운트 필드는 MAC 주소 필드에 제공된 주소부터 시작하여 할당된 주소들의 수일 수 있다. 단일 주소만이 요청되는 경우, 이 필드는 1로 설정될 수 있다.

제안과 관련하여, 이 메시지는 서버/프록시가 MAC 주소 범위를 프로빙하는 데 필요한 시간을 줄이는 데 사용할 수 있다. 이 메시지의 이면에 있는 아이디어는, 프록시가 네트워크에서 사용되는 주소를 북키핑하는 경우, 프록시가 프로빙되는 주소의 상태를 신속하게 나타낼 수 있다는 것이다. 이 메시지는 스테이션이 다른 MAC 주소 범위에서 프로빙을 반복하도록 요청하는 데 사용될 수도 있다. 예를 들어, 표 24를 참조한다.

0 7 8 10 11 15 16 31
서브유형	ver	메시지_유형	제어_워드
쿠키			상태	길이
(선택사항) 네트워크 ID
(선택사항) 특정 MAC 범위
(선택사항) 48 비트 MAC 주소(범위) 또는 64 비트 MAC 주소(범위)
(선택사항) 충돌 시 48 비트 MAC 범위 또는 충돌 시 64 비트 MAC 범위

제안

제어_워드의 경우, 비트들은 다음 목록에 따라 1 또는 0으로 전환될 필요가 있을 수 있다: 비트 0 내지 2는 자체 청구되는 주소가 속한 사분면에 따라 1로 전환될 필요가 있을 수 있다; 비트 4는 자체 청구되는 주소가 64비트인지 또는 48비트인지를 나타낼 수 있다; 비트 5는 주소가 유니캐스트인지 또는 멀티캐스트인지를 나타낼 수 있다; 비트 6은 이 메시지가 서버에서 시작됨을 나타내는 1로 설정될 수 있다; 그리고/또는 비트 7은, 특정 MAC 범위가 제공되는 경우에, 메시지가 MAC 주소 범위를 운반함을 나타내는 1로 설정될 필요가 있을 수 있다.

상태의 경우, 이 필드는 이 메시지에서 1, 2, 3 또는 12로 설정될 필요가 있을 수 있다. 각 코드의 의미는 다음과 같을 수 있다: 1은 MAC 범위가 사용 중이 아니며 주소가 스테이션에 직접 할당될 수 있음을 나타낸다; 2는 MAC 범위가 사용 중이고 스테이션이 즉시 다른 범위를 선택해야 함을 나타낸다; 3은 스테이션이 특정 MAC 범위 옵션에 제공된 범위에서 새 주소 또는 주소 범위를 생성하고 자체 청구를 다시 시도할 수 있음을 나타낸다. 상태가 값 3을 취하는 경우, 특정 MAC 범위 옵션이 제공될 수 있다; 그리고/또는 12는 MASAP가 네트워크에서 지원되지 않고 MASBAP이 사용될 필요가 있음을 나타낸다.

상태가 값 2를 취하는 경우, 48비트 MAC 주소(범위) 또는 64비트 MAC 주소(범위) 및 충돌하는 48비트 MAC 범위 또는 충돌하는 64비트 MAC 범위가 방어 메시지와 동일한 의미로 메시지에 있어야 할 수 있다.

네트워크 ID의 경우, 이 ID는 이 서버가 서비스하는 네트워크의 표시를 선택적으로 제공할 수 있다.

서버 기반 프로토콜이 다음 메시지를 정의하는 하나 이상의 MASBAP 프로토콜 메시지가 있을 수 있다.

발견은 네트워크의 임의의 프록시/서버와의 대화를 시작하는 데 사용될 수 있는 메시지이다. 예를 들어, 표 25를 참조한다.

0 7 8 10 11 15 16 31
서브유형	ver	메시지_유형	제어_워드
쿠키			상태	길이
(선택사항) 스테이션 ID
(선택사항) 특정 MAC 범위
(선택사항) 48 비트 MAC 주소(범위) 또는 64 비트 MAC 주소(범위)
(선택사항) MAC 주소 카운트

발견

제어_워드의 경우, 비트들은 다음 목록에 따라 1 또는 0으로 전환될 필요가 있을 수 있다: 비트 0 내지 2는, 주소가 요청되는 사분면에 따라 1로 전환될 필요가 있을 수 있다; 비트 4는 요청된 주소가 64비트인지 또는 48비트인지를 나타낼 수 있다; 비트 5는 요청된 주소가 유니캐스트인지 또는 멀티캐스트인지를 나타낼 수 있다; 비트 6은 이 메시지가 스테이션에서 시작됨을 나타내는 0으로 설정될 수 있다; 그리고/또는 비트 7은 메시지가 특정 MAC 범위 또는 48/64 MAC 주소(범위들)를 운반하는지에 따라 1 또는 0으로 설정될 필요가 있을 수 있다.

스테이션 ID의 경우, 이 ID는 이 메시지를 송신하는 스테이션의 ID를 선택적으로 포함할 수 있다. 메시지가 48비트 MAC 주소(범위) 또는 64비트 MAC 주소(범위)를 포함하는 경우 스테이션 ID가 필수적일 수 있다.

특정 MAC 범위는 요청되는 MAC 주소의 범위를 서버에 제공하는 데 사용될 수 있다. 서버는 이 옵션에 제공된 범위에 속하는 MAC 주소를 할당하려고 할 수 있다.

48비트 MAC 주소(범위) 또는 64비트 MAC 주소(범위)의 경우, 이 주소는 스테이션에 이전에 할당된 MAC 주소 또는 MAC 주소 범위를 제공하는 데 사용될 수 있다. 서버는 스테이션에 동일한 MAC 주소 또는 범위를 할당하려고 할 수 있다. 단일 주소만 요청되는 경우, 이 필드는 1로 설정될 수 있다.

MAC 주소 카운트는 MAC 주소가 속하는 범위를 정의하지 않고 주소 범위를 요청하는 데 사용될 수 있다. 48비트 MAC 주소(범위) 또는 64비트 MAC 주소(범위)가 제공된 경우 이 옵션이 추가되지 않을 수 있다. 두 옵션 모두 제공되지 않은 경우, 서버는 단일 MAC 주소가 요청된 것으로 가정할 수 있다.

제안과 관련하여 발견 메시지의 수신시, 서버는 가능한 MAC 주소 할당에 대한 제안을 클라이언트에 송신할 수 있다. 이 할당은 스테이션에 의해 제공되는 상이한 힌트들을 고려할 수 있다. 예를 들어, 표 26을 참조한다.

0 7 8 10 11 15 16 31
서브유형	ver	메시지_유형	제어_워드
쿠키			상태	길이
(선택사항) 네트워크 ID
(선택사항) 스테이션 ID
수명
48 비트 MAC 주소(범위) 또는 64비트 MAC 주소(범위)

제안

제어_워드의 경우, 이 비트들은 다음 목록에 따라 비트가 1 또는 0으로 전환될 필요가 있을 수 있다: 비트 0 내지 2는, 주소가 할당되는 사분면에 따라 1로 전환될 필요가 있을 수 있다. 비트 4는 할당된 주소가 64비트인지 또는 48비트인지를 나타낼 수 있다; 비트 5는 할당된 주소가 유니캐스트인지 또는 멀티캐스트인지를 나타낼 수 있다; 비트 6은 이 메시지가 서버에서 시작됨을 나타내는 1로 설정될 수 있다; 그리고/또는 비트 7은 메시지가 48/64 MAC 주소(범위)를 운반함을 나타내는 1로 설정될 필요가 있을 수 있다.

상태 필드는 진행 중인 프로세스를 나타내는 8 또는 발견에서 송신된 제약의 부분적 이행을 나타내는 12로 설정될 필요가 있을 수 있다.

네트워크 ID는 선택적으로 이 메시지를 송신하는 프록시가 속한 네트워크의 ID를 포함할 수 있다.

스테이션 ID는 발견 메시지로부터 스테이션 ID를 선택적으로 복사할 수 있다.

수명은 대여의 수명을 나타낼 수 있다. 수명 옵션은 제공될 필요가 있을 수 있다.

48비트 MAC 주소(범위) 또는 64비트 MAC 주소(범위)의 경우, 이들은 스테이션에 MAC 주소 또는 MAC 주소 범위를 제공하는 데 사용될 수 있다. 이 옵션은 이 메시지에 제공될 필요가 있을 수 있다.

요청 메시지와 관련하여, 스테이션은 제안 메시지의 수신시, 이 메시지를 통해 서버에 주소(들)의 할당을 확인(confirm)할 수 있다. 서버는 이 메시지가 수신되기 전에 할당된 주소를 고려하지 않을 수 있다. 예를 들어, 표 27을 참조한다.

요청

제어_워드의 경우, 이 비트들은 다음 목록에 따라 비트가 1 또는 0으로 전환될 필요가 있을 수 있다: 비트 0 내지 2는 주소가 할당되는 사분면에 따라 1로 전환될 필요가 있을 수 있다; 비트 4는 할당된 주소가 64비트인지 또는 48비트인지를 나타낼 수 있다; 비트 5는 할당된 주소가 유니캐스트인지 또는 멀티캐스트인지를 나타낼 수 있다; 비트 6은 이 메시지가 스테이션에서 시작됨을 나타내는 0으로 설정될 수 있다; 그리고/또는 비트 7은 메시지가 48/64 MAC 주소(범위)를 운반함을 나타내는 1로 설정될 필요가 있을 수 있다.

상태 필드는 0으로 설정될 필요가 있을 수 있다.

네트워크 ID는 제안 메시지의 네트워크 ID를 선택적으로 복사할 수 있다.

스테이션 ID는 선택적으로 이 스테이션 ID를 포함할 수 있다.

수명은 제안 메시지로부터 복사된 대여의 수명을 나타낼 수 있다.

48비트 MAC 주소(범위) 또는 64비트 MAC 주소(범위)의 경우, 이들은 제안 메시지로부터 복사될 수 있다.

ACK 메시지와 관련하여, 이 메시지는 스테이션이 주소 할당을 확인 응답하는 데 사용될 수 있다. 일부 경우에, 이 메시지는 할당 프로세스를 종료하기 위해 요청에 대한 응답으로 송신될 수 있지만, 이 메시지는 서버에 의해 스테이션에게 임의의 오류를 통지하고, 이 메시지를 사용해 발견 메시지에 응답하는 데 사용될 수도 있다. 예를 들어, 표 28을 참조한다.

0 7 8 10 11 15 16 31
서브유형	ver	메시지_유형	제어_워드
쿠키			상태	길이
(선택사항) 네트워크 ID
(선택사항) 스테이션 ID
(선택사항) 특정 MAC 범위

ACK

제어_워드 비트는 다음 목록에 따라 1 또는 0으로 전환될 필요가 있을 수 있다: 비트 0 내지 2는 주소가 할당되는 사분면에 따라 1로 전환될 필요가 있을 수 있다; 비트 4는 할당된 주소가 64비트인지 또는 48비트인지를 나타낼 수 있다; 비트 5는 할당된 주소가 유니캐스트인지 또는 멀티캐스트인지를 나타낼 수 있다; 비트 6은 이 메시지가 스테이션에서 시작됨을 나타내는 0으로 설정될 수 있다; 그리고/또는 비트 7은 메시지가 48/64 MAC 주소(범위)를 운반함을 나타내는 1로 설정될 필요가 있을 수 있다.

상태 필드는 다음과 같은 다수의 값들을 취할 수 있다: 3은, MASBAP가 사용 가능하지 않고, 스테이션은 특정 MAC 범위 옵션에 정의된 범위 내에서 MAC 주소 또는 범위를 생성하고 MASAP를 사용해야 함을 나타낼 수 있다; 4는 할당이 성공적으로 완료됨을 나타낼 수 있다; 5 내지 7은 스테이션에 의해 제공된 힌트를 고려하여 주소를 할당하는 동안의 실패를 나타낼 수 있다; 9는 MASBAP가 지원되지 않고 MASAP를 사용할 것임을 나타낼 수 있다; 그리고/또는 11은 서버에 의해 송신된 패킷과 스테이션에 의해 송신된 패킷 사이에 파라미터의 불일치가 있을 수 있음을 나타낼 수 있다. 경우 상태가 3의 값을 취하는 경우, 특정 MAC 범위 옵션이 제공될 필요가 있을 수 있다.

네트워크 ID는 프록시에 의해 서비스되는 네트워크의 ID를 선택적으로 포함할 수 있다.

스테이션 ID는 스테이션의 ID를 선택적으로 포함할 수 있다. 스테이션 ID가 요청 메시지에 제공된 경우, 이 옵션이 포함될 필요가 있을 수 있다.

특정 MAC 범위는 MASAP에 사용될 범위를 포함할 수 있다. 이 옵션은 상태 코드 3에 존재할 필요가 있을 수 있다.

ACK는 발견 및 요청의 응답으로 사용될 수 있다. 스테이션은 ACK 메시지가 수신될 때까지 할당이 완료된 것으로 간주하지 않을 수 있다.

특징들 및 요소들이 위에서 특정 조합들로 설명되었지만, 이 분야의 통상의 기술자는 각각 특징 또는 요소가 단독으로 또는 다른 특징들 및 요소들과의 임의의 조합으로 사용될 수 있다는 것을 이해할 것이다. 또한, 본원에서 설명되는 방법은, 컴퓨터 또는 프로세서에 의한 실행을 위해 컴퓨터 판독가능 매체에 통합되는 컴퓨터 프로그램, 소프트웨어, 또는 펌웨어로 구현될 수 있다. 컴퓨터 판독가능 매체들의 예들은 (유선 또는 무선 접속들을 통해 송신되는) 전자 신호들 및 컴퓨터 판독가능 저장 매체들을 포함한다. 컴퓨터 판독가능 저장 매체의 예들은 판독 전용 메모리(read only memory; ROM), 랜덤 액세스 메모리(random access memory; RAM), 레지스터, 캐시 메모리, 반도체 메모리 디바이스들, 예를 들어, 내장형 하드 디스크들 및 착탈식 디스크들과 같은 자기 매체들, 광자기 매체들, 및 예를 들어, CD-ROM 디스크들 및 디지털 다기능 디스크들(DVD들)과 같은 광학 매체들을 포함하지만, 이에 제한되지 않는다. 프로세서는 소프트웨어와 함께 WTRU, UE, 단말기, 기지국, RNC, 또는 임의의 호스트 컴퓨터에서 사용하기 위한 무선 주파수 송수신기를 구현하는 데 사용될 수 있다.

Claims

제1 노드에서 사용하기 위한 방법에 있어서,
제2 노드에, 상기 제2 노드의 유니캐스트 매체 액세스 제어(media access control; MAC) 주소 또는 상기 제2 노드와 연관된 멀티캐스트 MAC 주소에 기초하여, 제1 MAC 주소 또는 제1 범위의 MAC 주소를 포함하는 발견 메시지(discover message)를 송신하는 단계;
상기 제2 노드로부터, 상기 제1 노드에 할당될 수 있는 제2 범위의 MAC 주소를 갖는 제안 메시지(offer message)를 수신하는 단계;
제2 MAC 주소가 상기 제2 범위의 MAC 주소로부터 선택되는 조건에서, 상기 제2 노드에, 상기 제2 MAC 주소 또는 상기 제2 범위의 MAC 주소가 상기 제1 노드에 할당됨을 표시하는 요청 메시지를 송신하는 단계;
상기 제2 노드로부터, 상기 제2 MAC 주소 또는 상기 제2 범위의 MAC 주소가 상기 제1 노드에 할당됨을 표시하는 확인 응답 메시지(acknowledge message)를 수신하는 단계
를 포함하는, 제1 노드에서 사용하기 위한 방법.
제1항에 있어서, 이전 MAC 주소 할당에 기초하여, 상기 제1 MAC 주소 또는 상기 제1 범위의 MAC 주소를 결정하는 단계를 더 포함하는, 방법.
제1항에 있어서, 상기 제2 MAC 주소는 상기 제1 노드에 할당될 유니캐스트 MAC 주소 또는 상기 제1 노드에 할당될 멀티캐스트 MAC 주소인 것인, 방법.
제1항에 있어서, 상기 제2 범위의 MAC 주소는 유니캐스트 MAC 주소의 범위 또는 멀티캐스트 MAC 주소의 범위를 포함하는 것인, 방법.
제1항에 있어서, 상기 발견 메시지는 복수의 제어_워드 비트(control_word bits), 상태 필드, 상기 제1 노드의 식별, 및 MAC 주소 카운트를 더 포함하는 것인, 방법.
제1항에 있어서,
상기 제2 노드에 상기 발견 메시지를 송신하자마자, 상기 제안 메시지와 연관된 타이머를 시작하고 송신된 발견 메시지의 수를 표시하는 카운터를 증가시키는 단계; 및
상기 타이머가 만료되고 상기 카운터가 미리 결정된 카운트 수를 초과하지 않는 조건에서, 상기 제2 노드와 연관된 상기 유니캐스트 MAC 주소 또는 상기 제2 노드와 연관된 상기 멀티캐스트 MAC 주소에 기초하여 상기 제2 노드에 상기 발견 메시지를 재송신하는 단계
를 더 포함하는, 방법.
제1항에 있어서, 상기 제2 범위의 MAC 주소는 상기 제2 노드와 연관된 MAC 주소 풀(address pool), 상기 제1 MAC 주소 또는 상기 제1 범위의 MAC 주소 중 적어도 하나에 기초하여 결정되는 것인, 방법.
제1항에 있어서, 상기 제안 메시지는 복수의 제어_워드 비트, 상태 필드, 네트워크 식별, 상기 제2 노드의 식별, 및 수명(lifetime)을 더 포함하는 것인, 방법.
제1항에 있어서, 상기 제1 노드에 할당된 상기 제2 MAC 주소가 상기 제1 MAC 주소와 동일하거나 또는 상기 제1 노드에 할당된 상기 제2 MAC 주소가 상기 제1 범위의 MAC 주소 내에 있는 것인, 방법.
제1항에 있어서, 상기 발견 메시지의 소스 주소가 랜덤 MAC 주소 또는 글로벌 MAC 주소인 것인, 방법.
제1항에 있어서, 상기 제1 노드는 미리 구성된 초기 MAC 주소를 갖거나 갖지 않은 클라이언트이고 상기 제2 노드는 서버이며, 상기 미리 구성된 초기 MAC 주소는 로컬 주소 또는 글로벌 주소인 것인, 방법.
제1항에 있어서, 상기 발견 메시지, 제안 메시지, 요청 메시지, 및 확인 응답 메시지 각각은, 프로토콜 유형이 IEEE 802.1CQ를 표시하는 서브유형(subtype)을 갖는 오디오/비디오 전송 프로토콜(Audio/Video Transport Protocol; AVTP)임을 표시하는 표시자를 갖는 프레임에 캡슐화되는 것인, 방법.
제1 노드에 있어서,
제2 노드에, 상기 제2 노드의 유니캐스트 매체 액세스 제어(MAC) 주소 또는 상기 제2 노드와 연관된 멀티캐스트 MAC 주소에 기초하여, 제1 MAC 주소 또는 제1 범위의 MAC 주소를 포함하는 발견 메시지를 송신하도록 구성된 송신기;
상기 제2 노드로부터, 상기 제1 노드에 할당될 수 있는 제2 범위의 MAC 주소를 갖는 제안 메시지를 수신하도록 구성된 수신기
를 포함하고,
상기 송신기는 또한, 상기 제2 노드에, 제2 MAC 주소가 상기 제2 범위의 MAC 주소로부터 선택되는 조건에서, 상기 제2 MAC 주소 또는 상기 제2 범위의 MAC 주소가 상기 제1 노드에 할당됨을 표시하는 요청 메시지를 송신하도록 구성되며,
상기 수신기는 또한, 상기 제2 노드로부터, 상기 제2 MAC 주소 또는 상기 제2 범위의 MAC 주소가 상기 제1 노드에 할당됨을 표시하는 확인 응답 메시지를 수신하도록 구성되는 것인, 제1 노드.
제13항에 있어서, 이전 MAC 주소 할당에 기초하여, 상기 제1 MAC 주소 또는 상기 제1 범위의 MAC 주소를 결정하도록 구성된 프로세서를 더 포함하는, 제1 노드.
제14항에 있어서, 상기 프로세서는 또한, 상기 제2 노드에 상기 발견 메시지를 송신하자마자, 상기 제안 메시지와 연관된 타이머를 시작하고 송신된 발견 메시지의 수를 표시하는 카운터를 증가시키도록 구성되고, 상기 송신기는 또한, 상기 타이머가 만료되고 상기 카운터가 미리 결정된 카운트 수를 초과하지 않는 조건에서, 상기 제2 노드의 유니캐스트 MAC 주소 또는 상기 제2 노드와 연관된 상기 멀티캐스트 MAC 주소에 기초하여 상기 제2 노드에 상기 발견 메시지를 재송신하도록 구성되는 것인, 제1 노드.
제13항에 있어서, 상기 제2 MAC 주소는 상기 제1 노드에 할당될 유니캐스트 MAC 주소 또는 상기 제1 노드에 할당될 멀티캐스트 MAC 주소인 것인, 제1 노드.
제13항에 있어서, 상기 제2 범위의 MAC 주소는 유니캐스트 MAC 주소의 범위 또는 멀티캐스트 MAC 주소의 범위를 포함하는 것인, 제1 노드.
제13항에 있어서, 상기 제1 노드에 할당된 상기 제2 MAC 주소가 상기 제1 MAC 주소와 동일하거나 또는 상기 제1 노드에 할당된 상기 제2 MAC 주소가 상기 제1 범위의 MAC 주소 내에 있는 것인, 제1 노드.
제13항에 있어서, 상기 제1 노드는 미리 구성된 초기 MAC 주소를 갖거나 갖지 않은 클라이언트이고 상기 제2 노드는 서버이며, 상기 미리 구성된 초기 MAC 주소는 로컬 주소 또는 글로벌 주소인 것인, 제1 노드.
제1 노드에 있어서,
제2 노드에, 상기 제2 노드와 연관된 유니캐스트 매체 액세스 제어(MAC) 주소 또는 상기 제2 노드와 연관된 멀티캐스트 MAC 주소에 기초하여, 상기 제1 노드에 할당될 MAC 주소를 요청하는 발견 메시지를 송신하도록 구성된 송신기;
상기 제2 노드로부터, 상기 제1 노드에 할당될 수 있는 MAC 주소의 범위를 갖는 제안 메시지를 수신하도록 구성된 수신기
를 포함하고,
상기 송신기는, 상기 MAC 주소가 상기 MAC 주소의 범위로부터 선택되는 조건에서, 상기 제2 노드에, 상기 MAC 주소 또는 상기 MAC 주소의 범위가 상기 제1 노드에 할당됨을 표시하는 요청 메시지를 송신하도록 구성되며,
상기 수신기는, 상기 제2 노드로부터, 상기 MAC 주소 또는 상기 MAC 주소의 범위가 상기 제1 노드에 할당됨을 확인하는 확인 응답 메시지를 수신하도록 구성되는 것인, 제1 노드.