KR20160055823A - WebRTC 멀티미디어 클라이언트 애플리케이션 대신 클라이언트-기반 WebRTC 프록시에 의한 인입 WebRTC 트래픽의 선택적 멀티플렉싱 및/또는 유출 WebRTC 트래픽의 디-멀티플렉싱 - Google Patents
WebRTC 멀티미디어 클라이언트 애플리케이션 대신 클라이언트-기반 WebRTC 프록시에 의한 인입 WebRTC 트래픽의 선택적 멀티플렉싱 및/또는 유출 WebRTC 트래픽의 디-멀티플렉싱 Download PDFInfo
- Publication number
- KR20160055823A KR20160055823A KR1020167007840A KR20167007840A KR20160055823A KR 20160055823 A KR20160055823 A KR 20160055823A KR 1020167007840 A KR1020167007840 A KR 1020167007840A KR 20167007840 A KR20167007840 A KR 20167007840A KR 20160055823 A KR20160055823 A KR 20160055823A
- Authority
- KR
- South Korea
- Prior art keywords
- webrtc
- links
- link
- multiplexed stream
- stream
- Prior art date
Links
- 238000000034 method Methods 0.000 claims description 145
- 238000004891 communication Methods 0.000 claims description 115
- 239000012092 media component Substances 0.000 claims description 32
- 238000013519 translation Methods 0.000 claims description 6
- 230000001052 transient effect Effects 0.000 claims 1
- 230000006870 function Effects 0.000 description 40
- 230000008569 process Effects 0.000 description 38
- 230000011664 signaling Effects 0.000 description 30
- 238000007726 management method Methods 0.000 description 22
- 230000005540 biological transmission Effects 0.000 description 17
- 230000004044 response Effects 0.000 description 13
- 230000000977 initiatory effect Effects 0.000 description 11
- 230000001413 cellular effect Effects 0.000 description 9
- 238000005516 engineering process Methods 0.000 description 7
- 230000003287 optical effect Effects 0.000 description 7
- 238000012545 processing Methods 0.000 description 7
- 230000009467 reduction Effects 0.000 description 6
- 230000009471 action Effects 0.000 description 5
- 238000013459 approach Methods 0.000 description 5
- 238000007689 inspection Methods 0.000 description 5
- 230000007704 transition Effects 0.000 description 5
- 239000003795 chemical substances by application Substances 0.000 description 4
- 230000000694 effects Effects 0.000 description 4
- 238000013507 mapping Methods 0.000 description 4
- 230000001404 mediated effect Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 230000002829 reductive effect Effects 0.000 description 4
- 230000004913 activation Effects 0.000 description 3
- 238000013475 authorization Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 230000002452 interceptive effect Effects 0.000 description 3
- 230000002441 reversible effect Effects 0.000 description 3
- 230000001960 triggered effect Effects 0.000 description 3
- 230000005641 tunneling Effects 0.000 description 3
- 230000002730 additional effect Effects 0.000 description 2
- 238000012508 change request Methods 0.000 description 2
- 230000009849 deactivation Effects 0.000 description 2
- 230000003247 decreasing effect Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 239000000835 fiber Substances 0.000 description 2
- 230000007774 longterm Effects 0.000 description 2
- 238000005259 measurement Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000036961 partial effect Effects 0.000 description 2
- 238000013139 quantization Methods 0.000 description 2
- 230000003595 spectral effect Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 230000014616 translation Effects 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 241000760358 Enodes Species 0.000 description 1
- 125000002066 L-histidyl group Chemical group [H]N1C([H])=NC(C([H])([H])[C@](C(=O)[*])([H])N([H])[H])=C1[H] 0.000 description 1
- 230000010267 cellular communication Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 239000002245 particle Substances 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 230000001953 sensory effect Effects 0.000 description 1
- 239000013598 vector Substances 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/40—Support for services or applications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/256—NAT traversal
-
- H04L65/1003—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/1045—Proxies, e.g. for session initiation protocol [SIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1108—Web based protocols, e.g. webRTC
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/40—Support for services or applications
- H04L65/403—Arrangements for multi-party communication, e.g. for conferences
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/40—Support for services or applications
- H04L65/403—Arrangements for multi-party communication, e.g. for conferences
- H04L65/4038—Arrangements for multi-party communication, e.g. for conferences with floor control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/40—Support for services or applications
- H04L65/4061—Push-to services, e.g. push-to-talk or push-to-video
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/75—Media network packet handling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- H04W72/08—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/50—Allocation or scheduling criteria for wireless resources
- H04W72/54—Allocation or scheduling criteria for wireless resources based on quality criteria
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/0252—Traffic management, e.g. flow control or congestion control per individual bearer or channel
- H04W28/0257—Traffic management, e.g. flow control or congestion control per individual bearer or channel the individual bearer or channel having a maximum bit rate or a bit rate guarantee
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Quality & Reliability (AREA)
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
일 실시형태에서, 제 1 UE 상의 제 1 WebRTC 프록시 모듈은 제 1 UE 상의 제 1 WebRTC 멀티미디어 클라이언트 애플리케이션으로부터 멀티플렉싱된 스트림을 수신한다. 제 1 WebRTC 프록시 모듈은 적어도 제 1 및 제 2 디-멀티플렉싱된 스트림들로 디-멀티플렉싱한다. 제 1 WebRTC 프록시 모듈은 제 1 디-멀티플렉싱된 스트림을 QoS 를 가진 제 1 세트의 링크들을 통해서 제 2 UE 상의 제 2 WebRTC 프록시 모듈로 전송하고, 그리고 제 2 디-멀티플렉싱된 스트림을 제 2 세트의 링크들 상에서 제 2 WebRTC 프록시 모듈로 전송한다. 제 2 WebRTC 프록시 모듈은 제 1 및 제 2 디-멀티플렉싱된 스트림들을 재-멀티플렉싱하여 멀티플렉싱된 스트림의 원래 또는 압축된 버전을 획득하고, 그후 재-멀티플렉싱된 스트림을 제 2 UE 상의 제 2 WebRTC 멀티미디어 클라이언트 애플리케이션으로 전달한다.
Description
관련 출원들에 대한 상호-참조
본 특허 출원은 당해 출원과 동일한 발명자들에 의해 "SELECTIVELY MULTPLEXING INCOMING WEBRTC TRAFFIC AND/OR DE-MULTIPLEXING OUTGOING WEBRTC TRAFFIC BY A CLIENT-BASED WEBRTC PROXY ON BEHALF OF A WEBRTC MULTIMEDIA CLIENT APPLICATION" 란 제목으로 2013년 9월 16일자에 출원되어 본 양수인에게 양도된 가출원 번호 제 61/878,510호에 대해 우선권을 주장하며, 특별히 본원에서 참조로 전체적으로 포함된다.
발명의 분야
본 발명의 실시형태들은 웹 실시간 통신 (WebRTC; Web Real-Time Communication) 멀티미디어 클라이언트 애플리케이션 대신 클라이언트-기반 WebRTC 프록시에 의해 인입 웹 실시간 통신 (WebRTC) 트래픽을 선택적으로 멀티플렉싱하고 및/또는 유출 WebRTC 트래픽을 디-멀티플렉싱하는 것에 관한 것이다.
무선 통신 시스템들은 1세대 아날로그 무선 전화 서비스 (1G), (잠정적인 2.5G 및 2.75G 네트워크들을 포함한) 2세대 (2G) 디지털 무선 전화 서비스 및 3세대 (3G) 및 4세대 (4G) 고속 데이터 / 인터넷-가능한 무선 서비스들을 통한, 여러 세대들을 거쳐서 개발되어 왔다. 셀룰러 및 개인 통신 서비스 (PCS) 시스템들을 포함한, 많은 상이한 유형들의 무선 통신 시스템들이 현재 사용되고 있다. 기지의 셀룰러 시스템들의 예들은 셀룰러 AMPS (cellular Analog Advanced Mobile Phone System), 및 코드분할 다중접속 (CDMA), 주파수 분할 다중접속 (FDMA), 시분할 다중접속 (TDMA), TDMA 의 GSM (Global System for Mobile access) 변형, 및 TDMA 기술과 CDMA 기술 양자를 이용한 더 새로운 하이브리드 디지털 통신 시스템들에 기초한 디지털 셀룰러 시스템들을 포함한다.
좀더 최근에는, 롱텀 에볼류션 (LTE) 이 모바일 폰들 및 다른 데이터 터미널들에 대한 고속 데이터의 무선 통신을 위한 무선 통신 프로토콜로서 개발되었다. LTE 는 GSM 에 기초하며, EDGE (Enhanced Data rates for GSM Evolution) 와 같은 여러 GSM-관련 프로토콜들, 및 고속 패킷 액세스 (HSPA) 와 같은 범용 이동 통신 시스템 (UMTS) 프로토콜들로부터의 기여들을 포함한다.
IETF (Internet Engineering Task Force) 와 함께 월드와이드 웹 컨소시엄 (W3C) 은 2011 년에 웹 실시간 통신 (WebRTC) 으로 불리는 웹 개발자 기술의 개발을 시작하였다. WebRTC 는 종점들의 상대적인 로케이션에 관계없이 (예컨대, 동일한 사설 네트워크에서, 동일한 디바이스 상의 개개의 종점들이 별개의 네트워크 어드레스 변환 (NAT들) 및/또는 방화벽들 등 너머에 있든 아니든) 브라우저 (또는 종점) 가 하나 이상의 다른 종점들과의 피어-투-피어 (P2P) 실시간 통신에 참가가능하게 하는 프로토콜이다.
WebRTC 는 실시간 매체들의 송신을 위해 실시간 전송 프로토콜 (RTP) 을 레버리지한다. RTP 는 많은 상이한 매체들 유형들에 대한 전송 프로토콜로서 기능할 수 있는 유연한 프로토콜이다. 이들 매체들 유형들은 오디오 또는 비디오에의 맵핑으로서 넓게 분류될 수 있거나, 또는 연관된 오디오 또는 비디오 코덱, 대역폭 요구사항들, 오디오 또는 비디오 해상도, 등과 같은 정보를 지정함으로써 좀더 구체화될 수 있다. 더욱이, 메시 회의 모델 (mesh conferencing model) 에서, 다수의 매체들 스트림들이 클라이언트-기반 오디오 믹싱 또는 비디오 합성을 가능하게 하기 위해서 P2P 로 전송될 수도 있다.
WebRTC 를 통해서 통신하는 종점들이 개개의 종점들 사이의 종단간 (end-to-end) 접속들의 개수를 제한하는 하나 이상의 NAT들 및/또는 방화벽들에 의해 분리될 수 있기 때문에, WebRTC 는 단일 IP 어드레스 및 포트를 통해서 RTP 스트림들의 멀티플렉싱을 허용한다. 이러한 부분적인 제한으로 인해, 기존 WebRTC 사양들은 RTP 및 RTP 제어 프로토콜 (RTCP) 통신들에 멀티플렉싱이 채용되는 것을 권장한다. 다수의 유형들의 스트림들이 하나의 IP 어드레스 및 포트를 통해서 멀티플렉싱되는 경우, 차별화된 서비스 품질 (QoS) 을 상이한 유형들의 매체들에게 제공하는 것은 더욱 도전이 되고 있다.
일 실시형태에서, 제 1 UE 상의 제 1 WebRTC 프록시 모듈은 제 1 UE 상의 제 1 WebRTC 멀티미디어 클라이언트 애플리케이션으로부터 멀티플렉싱된 스트림을 수신한다. 제 1 WebRTC 프록시 모듈은 적어도 제 1 및 제 2 디-멀티플렉싱된 스트림들로 디-멀티플렉싱한다. 제 1 WebRTC 프록시 모듈은 제 1 디-멀티플렉싱된 스트림을 QoS 를 가진 제 1 세트의 링크들을 통해서 제 2 UE 상의 제 2 WebRTC 프록시 모듈로 전송하고, 그리고 제 2 디-멀티플렉싱된 스트림을 제 2 세트의 링크들 상에서 제 2 WebRTC 프록시 모듈로 전송한다. 제 2 WebRTC 프록시 모듈은 제 1 및 제 2 디-멀티플렉싱된 스트림들을 재-멀티플렉싱하여 멀티플렉싱된 스트림의 원래 또는 압축된 버전을 획득하고, 그후 재-멀티플렉싱된 스트림을 제 2 UE 상의 제 2 WebRTC 멀티미디어 클라이언트 애플리케이션으로 전달한다.
본 발명의 실시형태들 및 이의 부수하는 이점들 중 많은 이점들의 좀더 충분한 이해는, 본 발명의 한정이 아닌, 오직 예시를 위해 제시되는 첨부 도면들과 관련하여 고려될 때 다음 상세한 설명에 대한 참조에 의해 더 잘 이해되게 되므로, 용이하게 얻어질 것이다.
도 1 은 본 발명의 실시형태에 따른 무선 통신 시스템의 하이-레벨 시스템 아키텍처를 예시한다.
도 2a 는 본 발명의 일 실시형태에 따른, 1x EV-DO 네트워크에 대한 코어 네트워크의 패킷-스위칭 부분 및 무선 액세스 네트워크 (RAN) 의 예시적인 구성을 예시한다.
도 2b 는 본 발명의 일 실시형태에 따른, 3G UMTS W-CDMA 시스템 내 일반 패킷 무선 서비스 (GPRS) 코어 네트워크의 패킷-스위칭 부분 및 RAN 의 예시적인 구성을 예시한다.
도 2c 는 본 발명의 일 실시형태에 따른, 3G UMTS W-CDMA 시스템 내 GPRS 코어 네트워크의 패킷-스위칭 부분 및 RAN 의 다른 예시적인 구성을 예시한다.
도 2d 는 본 발명의 일 실시형태에 따른, EPS (Evolved Packet System) 또는 롱텀 에볼류션 (LTE) 네트워크에 기초하는 코어 네트워크의 패킷-스위칭 부분 및 RAN 의 예시적인 구성을 예시한다.
도 2e 는 본 발명의 일 실시형태에 따른, EPS 또는 LTE 네트워크에 접속된 강화 HRPD (enhanced High Rate Packet Data) RAN 및 또한 HRPD 코어 네트워크의 패킷-스위칭 부분의 예시적인 구성을 예시한다.
도 3 은 본 발명의 실시형태들에 따른 사용자 장비들 (UE들) 의 예들을 예시한다.
도 4 는 본 발명의 일 실시형태에 따른 기능을 수행하도록 구성된 로직을 포함하는 통신 디바이스를 예시한다.
도 5 는 본 발명의 일 실시형태에 따른, 클라이언트 애플리케이션 개시되는 방향성 QoS 관리 프로시저의 좀더 상세한 구현예를 예시한다.
도 6a 는 본 발명의 일 실시형태에 따른, 도 2a 에서와 같은 1x EV-DO 네트워크 (레거시 HRPD) 또는 도 2e 에서와 같은 eHRPD 네트워크에 의해 서빙되는 동안 하프 듀플렉스 PTT 세션에 참가하는 주어진 UE 에 대한, 도 5 의 프로세스의 예시적인 구현예를 예시한다.
도 6b 는 본 발명의 일 실시형태에 따른, 도 2b 또는 도 2c 에서와 같은 W-CDMA 네트워크에 의해 서빙되는 동안 하프 듀플렉스 PTT 세션에 참가하는 주어진 UE 에 대한, 도 5 의 프로세스의 예시적인 구현예를 예시한다.
도 6c 는 본 발명의 일 실시형태에 따른, 도 2d 에서의 LTE 네트워크에 의해 서빙되는 동안 하프 듀플렉스 PTT 세션을 일으키는 주어진 UE 에 대한, 도 5 의 프로세스의 예시적인 구현예를 예시한다.
도 7a 내지 도 7b 는 본 발명의 일 실시형태에 따른, 도 5 와 유사하지만 UE 클라이언트 애플리케이션 대신 애플리케이션 서버 (170) 에서 구현되는 선택적 QoS 제어 프로시저들에 관한 것이다.
도 7c 는 본 발명의 일 실시형태에 따른, 하프 듀플렉스 PTT 세션에 참가하는 주어진 UE (콜 발신자 또는 콜 타겟) 에 대한, LTE 네트워크 내에서의 도 7b 의 예시적인 구현예를 예시한다.
도 8a 는 본 발명의 일 실시형태에 따른, 코어 네트워크 개시되는 방향성 QoS 관리 프로시저의 좀더 상세한 구현예를 예시한다.
도 8b 는 본 발명의 일 실시형태에 따른, 도 8a 의 더욱 더 상세한 구현예를 각각 예시하며, 이에 따라서 LTE-특정의 및 W-CDMA-특정의 컴포넌트들 및 메시지들이 좀더 명시적으로 참조 표시된다.
도 8c 는 본 발명의 일 실시형태에 따른, 일부 다른 UE 에 의해 유래된 하프 듀플렉스 PTT 세션의 콜 타겟인 주어진 UE 에 대한, W-CDMA 네트워크 내에서의 도 8b 의 예시적인 구현예를 예시한다.
도 8d 는 본 발명의 일 실시형태에 따른, 하프 듀플렉스 PTT 세션의 콜 발신자인 주어진 UE 에 대한, LTE 네트워크 내에서의 도 8b 의 예시적인 구현예를 예시한다.
도 9a 는 본 발명의 일 실시형태에 따른, GBR 리소스들이 RAN 및 코어 네트워크에서 로컬로 관리되는 QoS 관리 프로시저를 예시한다.
도 9b 는 본 발명의 일 실시형태에 따른, 도 9a 의 더욱 더 상세한 구현예를 예시하며, 이에 따라서 LTE-특정의 컴포넌트들 및 메시지들이 각각 좀더 명시적으로 참조 표시된다.
도 10a 내지 도 10b 는 본 발명의 실시형태들에 따른, W-CDMA 및 EV-DO 아키텍쳐들에 있어 RAN-개시되는 타이머-기반의 방향성 QoS 흐름 관리 프로시저들을 각각 예시한다.
도 11 은 2개의 UE들 사이의 웹 실시간 통신 (WebRTC) 세션에 대한 종래의 트래픽의 흐름을 예시한다.
도 12a 는 본 발명의 일 실시형태에 따른, 동일한 서빙 네트워크에 의해 서빙되는 2개의 UE들 사이의 WebRTC 세션에 대한 트래픽의 흐름을 예시한다.
도 12b 는 본 발명의 일 실시형태에 따른, 상이한 서빙 네트워크들에 의해 서빙되는 2개의 UE들 사이의 WebRTC 세션에 대한 트래픽의 흐름을 예시한다.
도 13 은 본 발명의 일 실시형태에 따른, WebRTC 세션에 대한 QoS 링크를 설정하고 뒤이어서 소스 UE 에서 WebRTC 세션에서 디-멀티플렉싱하는 프로세스를 예시한다.
도 14 는 본 발명의 일 실시형태에 따른, UE-유래된 WebRTC 세션에 대한 서버-기반의 NW-개시되는 QoS 프로시저에 기초한, 도 13 의 프로세스의 LTE-특정의 구현예를 예시한다.
도 15 는 본 발명의 일 실시형태에 따른, UE-개시되는 QoS 프로시저에 기초한, 도 13 의 프로세스의 LTE-특정의 구현예를 예시한다.
도 16 은 본 발명의 일 실시형태에 따른, 다른 NW-개시되는 QoS 프로시저에 기초한, 도 13 의 프로세스의 부분의 예시적인 구현예를 예시한다.
도 17 은 본 발명의 일 실시형태에 따른, WebRTC 세션에 대한 QoS 링크를 셋업하고 뒤이어서 타겟 UE 에서 WebRTC 세션에서 재-멀티플렉싱하는 하이-레벨 프로세스에 관련된다.
도 1 은 본 발명의 실시형태에 따른 무선 통신 시스템의 하이-레벨 시스템 아키텍처를 예시한다.
도 2a 는 본 발명의 일 실시형태에 따른, 1x EV-DO 네트워크에 대한 코어 네트워크의 패킷-스위칭 부분 및 무선 액세스 네트워크 (RAN) 의 예시적인 구성을 예시한다.
도 2b 는 본 발명의 일 실시형태에 따른, 3G UMTS W-CDMA 시스템 내 일반 패킷 무선 서비스 (GPRS) 코어 네트워크의 패킷-스위칭 부분 및 RAN 의 예시적인 구성을 예시한다.
도 2c 는 본 발명의 일 실시형태에 따른, 3G UMTS W-CDMA 시스템 내 GPRS 코어 네트워크의 패킷-스위칭 부분 및 RAN 의 다른 예시적인 구성을 예시한다.
도 2d 는 본 발명의 일 실시형태에 따른, EPS (Evolved Packet System) 또는 롱텀 에볼류션 (LTE) 네트워크에 기초하는 코어 네트워크의 패킷-스위칭 부분 및 RAN 의 예시적인 구성을 예시한다.
도 2e 는 본 발명의 일 실시형태에 따른, EPS 또는 LTE 네트워크에 접속된 강화 HRPD (enhanced High Rate Packet Data) RAN 및 또한 HRPD 코어 네트워크의 패킷-스위칭 부분의 예시적인 구성을 예시한다.
도 3 은 본 발명의 실시형태들에 따른 사용자 장비들 (UE들) 의 예들을 예시한다.
도 4 는 본 발명의 일 실시형태에 따른 기능을 수행하도록 구성된 로직을 포함하는 통신 디바이스를 예시한다.
도 5 는 본 발명의 일 실시형태에 따른, 클라이언트 애플리케이션 개시되는 방향성 QoS 관리 프로시저의 좀더 상세한 구현예를 예시한다.
도 6a 는 본 발명의 일 실시형태에 따른, 도 2a 에서와 같은 1x EV-DO 네트워크 (레거시 HRPD) 또는 도 2e 에서와 같은 eHRPD 네트워크에 의해 서빙되는 동안 하프 듀플렉스 PTT 세션에 참가하는 주어진 UE 에 대한, 도 5 의 프로세스의 예시적인 구현예를 예시한다.
도 6b 는 본 발명의 일 실시형태에 따른, 도 2b 또는 도 2c 에서와 같은 W-CDMA 네트워크에 의해 서빙되는 동안 하프 듀플렉스 PTT 세션에 참가하는 주어진 UE 에 대한, 도 5 의 프로세스의 예시적인 구현예를 예시한다.
도 6c 는 본 발명의 일 실시형태에 따른, 도 2d 에서의 LTE 네트워크에 의해 서빙되는 동안 하프 듀플렉스 PTT 세션을 일으키는 주어진 UE 에 대한, 도 5 의 프로세스의 예시적인 구현예를 예시한다.
도 7a 내지 도 7b 는 본 발명의 일 실시형태에 따른, 도 5 와 유사하지만 UE 클라이언트 애플리케이션 대신 애플리케이션 서버 (170) 에서 구현되는 선택적 QoS 제어 프로시저들에 관한 것이다.
도 7c 는 본 발명의 일 실시형태에 따른, 하프 듀플렉스 PTT 세션에 참가하는 주어진 UE (콜 발신자 또는 콜 타겟) 에 대한, LTE 네트워크 내에서의 도 7b 의 예시적인 구현예를 예시한다.
도 8a 는 본 발명의 일 실시형태에 따른, 코어 네트워크 개시되는 방향성 QoS 관리 프로시저의 좀더 상세한 구현예를 예시한다.
도 8b 는 본 발명의 일 실시형태에 따른, 도 8a 의 더욱 더 상세한 구현예를 각각 예시하며, 이에 따라서 LTE-특정의 및 W-CDMA-특정의 컴포넌트들 및 메시지들이 좀더 명시적으로 참조 표시된다.
도 8c 는 본 발명의 일 실시형태에 따른, 일부 다른 UE 에 의해 유래된 하프 듀플렉스 PTT 세션의 콜 타겟인 주어진 UE 에 대한, W-CDMA 네트워크 내에서의 도 8b 의 예시적인 구현예를 예시한다.
도 8d 는 본 발명의 일 실시형태에 따른, 하프 듀플렉스 PTT 세션의 콜 발신자인 주어진 UE 에 대한, LTE 네트워크 내에서의 도 8b 의 예시적인 구현예를 예시한다.
도 9a 는 본 발명의 일 실시형태에 따른, GBR 리소스들이 RAN 및 코어 네트워크에서 로컬로 관리되는 QoS 관리 프로시저를 예시한다.
도 9b 는 본 발명의 일 실시형태에 따른, 도 9a 의 더욱 더 상세한 구현예를 예시하며, 이에 따라서 LTE-특정의 컴포넌트들 및 메시지들이 각각 좀더 명시적으로 참조 표시된다.
도 10a 내지 도 10b 는 본 발명의 실시형태들에 따른, W-CDMA 및 EV-DO 아키텍쳐들에 있어 RAN-개시되는 타이머-기반의 방향성 QoS 흐름 관리 프로시저들을 각각 예시한다.
도 11 은 2개의 UE들 사이의 웹 실시간 통신 (WebRTC) 세션에 대한 종래의 트래픽의 흐름을 예시한다.
도 12a 는 본 발명의 일 실시형태에 따른, 동일한 서빙 네트워크에 의해 서빙되는 2개의 UE들 사이의 WebRTC 세션에 대한 트래픽의 흐름을 예시한다.
도 12b 는 본 발명의 일 실시형태에 따른, 상이한 서빙 네트워크들에 의해 서빙되는 2개의 UE들 사이의 WebRTC 세션에 대한 트래픽의 흐름을 예시한다.
도 13 은 본 발명의 일 실시형태에 따른, WebRTC 세션에 대한 QoS 링크를 설정하고 뒤이어서 소스 UE 에서 WebRTC 세션에서 디-멀티플렉싱하는 프로세스를 예시한다.
도 14 는 본 발명의 일 실시형태에 따른, UE-유래된 WebRTC 세션에 대한 서버-기반의 NW-개시되는 QoS 프로시저에 기초한, 도 13 의 프로세스의 LTE-특정의 구현예를 예시한다.
도 15 는 본 발명의 일 실시형태에 따른, UE-개시되는 QoS 프로시저에 기초한, 도 13 의 프로세스의 LTE-특정의 구현예를 예시한다.
도 16 은 본 발명의 일 실시형태에 따른, 다른 NW-개시되는 QoS 프로시저에 기초한, 도 13 의 프로세스의 부분의 예시적인 구현예를 예시한다.
도 17 은 본 발명의 일 실시형태에 따른, WebRTC 세션에 대한 QoS 링크를 셋업하고 뒤이어서 타겟 UE 에서 WebRTC 세션에서 재-멀티플렉싱하는 하이-레벨 프로세스에 관련된다.
본 발명의 양태들은 본 발명의 특정의 실시형태들에 관련된 다음 설명 및 관련된 도면들에 개시된다. 본 발명의 범위로부터 일탈함이 없이 대체 실시형태들이 발명될 수도 있다. 게다가, 본 발명의 널리 공지된 엘리먼트들은 자세하게 설명되지 않거나 또는 본 발명의 관련된 세부 사항들을 흐리지 않도록 생략될 것이다.
단어들 "예시적인" 및/또는 "예" 는 본원에서 "예, 실례 (instance), 또는 예시로서 기능하는 것" 을 의미하기 위해 사용된다. 본원에서 "예시적인" 및/또는 "예" 로서 설명하는 임의의 실시형태는 다른 실시형태들보다 선호되거나 또는 유리한 것으로 반드시 간주되어서는 안된다. 이와 유사하게, 용어 "본 발명의 실시형태들" 은 본 발명의 모든 실시형태들이 설명하는 동작의 특성, 이점 또는 모드를 포함하도록 요구하지 않는다.
또, 많은 실시형태들이 예를 들어, 컴퓨팅 디바이스의 엘리먼트들에 의해 수행될 액션들의 시퀀스들의 관점에서 설명된다. 본원에서 설명하는 여러 액션들은 특정의 회로들 (예컨대, 주문형 집적회로들 (ASIC들)) 에 의해, 하나 이상의 프로세서들에 의해 실행되는 프로그램 명령들에 의해, 또는 양자의 조합에 의해 수행될 수 있음을 알 수 있을 것이다. 게다가, 본원에서 설명하는 액션들의 이들 시퀀스는 실행시, 연관된 프로세서로 하여금 본원에서 설명하는 기능을 수행할 수 있도록 하는 대응하는 컴퓨터 명령들의 세트를 안에 저장하고 있는 임의 유형의 컴퓨터 판독가능 저장 매체 내에 전체적으로 구현되는 것으로 간주될 수 있다. 따라서, 본 발명의 여러 양태들은 청구된 요지의 범위 내에 있는 것으로 모두 간주되는 다수의 상이한 유형들로 구현될 수도 있다. 게다가, 본원에서 설명하는 실시형태들의 각각에 대해, 임의의 이러한 실시형태들의 대응하는 유형은 예를 들어, 설명되는 액션을 수행하도록 "구성된 로직" 으로 본원에서 설명될 수도 있다.
본원에서 사용자 장비 (UE) 로서 지칭되는, 클라이언트 디바이스는 이동하거나 또는 고정되어 있을 수도 있으며, 무선 액세스 네트워크 (RAN) 와 통신할 수도 있다. 본원에서 사용될 때, 용어 "UE" 는 "액세스 단말기" 또는 "AT", "무선 디바이스", "가입자 디바이스", "가입자 터미널", "가입자국", "사용자 단말기" 또는 UT, "모바일 단말기", "이동국" 및 이의 변형들로서 상호교환가능하게 지칭될 수도 있다. 일반적으로, UE들은 RAN 을 통해서 코어 네트워크와 통신할 수 있으며, 코어 네트워크를 통해서 UE들이 인터넷과 같은 외부 네트워크들과 접속될 수 있다. 물론, 코어 네트워크 및/또는 인터넷에 접속하는 다른 메커니즘들이 또한 UE들에 대해, 예컨대 유선 액세스 네트워크들, (예컨대, IEEE 802.11, 등에 기초한) WiFi 네트워크들 및 기타 등등을 통해서 가능하다. UE들은 PC 카드들, 컴팩트한 플래시 디바이스들, 외부 또는 내부 모뎀들, 무선 또는 유선 전화기들 등을 포함하지만 이에 한정되지 않는, 다수의 유형들의 디바이스들 중 임의의 디바이스에 의해 구현될 수 있다. UE들이 신호들을 RAN 으로 전송할 수 있는 통신 링크는 업링크 채널 (예컨대, 역방향 트래픽 채널, 역방향 제어 채널, 액세스 채널, 등) 으로 불린다. RAN 이 신호들을 UE들로 전송할 수 있는 통신 링크는 다운링크 또는 순방향 링크 채널 (예컨대, 페이징 채널, 제어 채널, 브로드캐스트 채널, 순방향 트래픽 채널, 등) 으로 불린다. 본원에서 사용될 때, 용어 트래픽 채널 (TCH) 은 업링크 / 역방향 또는 다운링크 / 순방향 트래픽 채널을 지칭할 수 있다.
도 1 은 본 발명의 실시형태에 따른 무선 통신 시스템 (100) 의 하이-레벨 시스템 아키텍처를 예시한다. 무선 통신 시스템 (100) 은 UE들 1...N 을 포함한다. UE들 1...N 은 셀룰러 전화기들, 개인 휴대정보 단말기 (PDA들), 페이저들, 랩탑 컴퓨터, 데스크탑 컴퓨터 등을 포함할 수 있다. 예를 들어, 도 1 에서, UE들 1...2 는 셀룰러 콜링 폰들로서 예시되며, UE들 3...5 는 셀룰러 터치스크린 폰들 또는 스마트폰들로서 예시되며, UE N 은 데스크탑 컴퓨터 또는 PC 로서 예시된다.
도 1 을 참조하면, UE들 1...N 은 도 1 에 공중 인터페이스들 (104, 106, 108) 및/또는 직접 유선 접속으로서 나타낸 물리적인 통신 인터페이스 또는 계층을 통해서, 액세스 네트워크 (예컨대, RAN (120), 액세스 지점 (125), 등) 와 통신하도록 구성된다. 공중 인터페이스들 (104 및 106) 은 주어진 셀룰러 통신 프로토콜 (예컨대, CDMA, EVDO, eHRPD, GSM, EDGE, W-CDMA, LTE, 등) 을 따를 수 있으며, 한편 공중 인터페이스 (108) 는 무선 IP 프로토콜 (예컨대, IEEE 802.11) 을 따를 수 있다. RAN (120) 은 공중 인터페이스들 (104 및 106) 과 같은 공중 인터페이스들을 통해서 UE들을 서빙하는 복수의 액세스 지점들을 포함한다. RAN (120) 에서의 액세스 지점들은 액세스 노드들 또는 AN들, 액세스 지점들 또는 AP들, 기지국들 또는 BS들, 노드 B들, eNode B들 등으로서 지칭될 수 있다. 이들 액세스 지점들은 지상 액세스 지점들 (또는, 지상 스테이션들), 또는 위성 액세스 지점들일 수 있다. RAN (120) 은 RAN (120) 에 의해 서빙되는 UE들과 RAN (120) 에 의해 서빙되는 다른 UE들 또는 상이한 RAN 사이의 회선 스위칭 (CS) 콜들을 전적으로 (altogether) 브릿징하는 것을 포함한, 다양한 기능들을 수행할 수 있는 코어 네트워크 (140) 에 접속하도록 구성되며, 또한 인터넷 (175) 과 같은 외부 네트워크들과의 패킷-스위칭 (PS) 데이터의 교환을 중재할 수 있다. 인터넷 (175) 은 다수의 라우팅 에이전트들 및 프로세싱 에이전트들 (편의상 도 1 에 미도시) 을 포함한다. 도 1 에서, UE N 은 인터넷 (175) 에 직접 접속하는 (즉, WiFi 또는 802.11-기반의 네트워크의 이더넷 접속을 통해서 코어 네트워크 (140) 로부터 분리된) 것으로 도시된다. 그 때문에, 인터넷 (175) 은 코어 네트워크 (140) 를 통해서 UE N 과 UE들 1...N 사이에 패킷-스위칭 데이터 통신들을 브릿징하도록 기능할 수 있다. 또한, 도 1 에 도시된 것은 RAN (120) 으로부터 분리된 액세스 지점 (125) 이다. 액세스 지점 (125) 은 코어 네트워크 (140) 과 독립적인 인터넷 (175) 에 (예컨대, FiOS, 케이블 모뎀, 등과 같은 광학 통신 시스템을 통해서) 접속될 수도 있다. 공중 인터페이스 (108) 는 일 예에서 IEEE 802.11 와 같은 로컬 무선 접속을 통해서 UE 4 또는 UE 5 를 서빙할 수도 있다. UE N 은 (예컨대, 유선 및 무선 양쪽의 연결성을 가진 WiFi 라우터에 대한) 일 예에서 액세스 지점 (125) 자체에 대응할 수 있는 모뎀 또는 라우터에의 직접 접속과 같은, 인터넷 (175) 에의 유선 접속을 가진 데스크탑 컴퓨터로서 도시된다.
도 1 을 참조하면, 애플리케이션 서버 (170) 는 인터넷 (175), 코어 네트워크 (140), 또는 양쪽에 접속된 것으로 도시된다. 애플리케이션 서버 (170) 는 구조적으로 별개인 복수의 서버들로서 구현될 수 있거나, 또는 대안적으로 단일 서버에 대응할 수도 있다. 아래에서 좀더 자세하게 설명되는 바와 같이, 애플리케이션 서버 (170) 는 코어 네트워크 (140) 및/또는 인터넷 (175) 을 통해서 애플리케이션 서버 (170) 에 접속할 수 있는 UE들에게 하나 이상의 통신 서비스들 (예컨대, VoIP (Voice-over-Internet Protocol) 세션들, 푸시-투-토크 (PTT) 세션들, 그룹 통신 세션들, 소셜 네트워킹 서비스들, 등) 을 지원하도록 구성된다.
무선 통신 시스템 (100) 을 좀더 자세하게 설명하는 것을 돕기 위해, RAN (120) 및 코어 네트워크 (140) 에 대한 프로토콜-특정의 구현들의 예들이 아래에서 도 2a 내지 도 2d 와 관련하여 제공된다. 특히, RAN (120) 및 코어 네트워크 (140) 의 컴포넌트들은 패킷-스위칭 (PS) 통신들을 지원하는 것과 연관된 컴포넌트들에 대응하며, 이에 따라서 레거시 회선-교환 (CS) 컴포넌트들이 또한 이들 네트워크들에 존재할 수도 있지만, 임의의 레거시 CS-특정의 컴포넌트들은 도 2a 내지 도 2d 에 명시적으로 도시되지 않는다.
도 2a 는 본 발명의 일 실시형태에 따른, CDMA2000 1x EV-DO (Evolution-Data Optimized) 네트워크에서의 패킷-스위칭 통신들을 위한 코어 네트워크 (140) 및 RAN (120) 의 예시적인 구성을 예시한다. 도 2a 를 참조하면, RAN (120) 은 유선 백홀 인터페이스를 통해서 기지국 제어기 (BSC) (215A) 에 커플링된 복수의 기지국들 (BSs) (200A, 205A 및 210A) 을 포함한다. 단일 BSC 에 의해 제어되는 BS들의 그룹은 서브넷으로서 일괄하여 지칭된다. 당업자에 의해 인식되는 바와 같이, RAN (120) 은 다수의 BSC들 및 서브넷들을 포함할 수 있으며, 편의상 도 2a 에 단일 BSC 가 도시된다. BSC (215A) 는 A9 접속을 통해서 코어 네트워크 (140) 내 패킷 제어 기능부 (PCF) (220A) 와 통신한다. PCF (220A) 는 패킷 데이터에 관련된 BSC (215A) 에 대해 어떤 프로세싱 기능들을 수행한다. PCF (220A) 는 A11 접속을 통해서 코어 네트워크 (140) 내 패킷 데이터 서빙 노드 (PDSN) (225A) 와 통신한다. PDSN (225A) 은 점-대-점 (PPP) 세션들을 관리하는 것, 홈 에이전트 (HA) 및/또는 외부 에이전트 (FA) 로서 작용하는 것을 포함한, 다양한 기능들을 가지며, (아래에서 좀더 자세하게 설명된) GSM 및 UMTS 네트워크들에서의 게이트웨이 일반 패킷 무선 서비스 (GPRS) 지원 노드 (GGSN) 에 대한 기능에 있어 유사하다. PDSN (225A) 은 코어 네트워크 (140) 를 인터넷 (175) 과 같은, 외부 IP 네트워크들에 접속한다.
도 2b 는 본 발명의 일 실시형태에 따른, 3G UMTS W-CDMA 시스템 내에 GPRS 코어 네트워크로서 구성되는 코어 네트워크 (140) 의 패킷-스위칭 부분 및 RAN (120) 의 예시적인 구성을 예시한다. 도 2b 를 참조하면, RAN (120) 은 유선 백홀 인터페이스를 통해서 무선 네트워크 제어기 (RNC) (215B) 에 커플링된 복수의 노드 B들 (200B, 205B 및 210B) 을 포함한다. 1x EV-DO 네트워크들과 유사하게, 단일 RNC 에 의해 제어하는 노드 B들의 그룹은 서브넷으로서 일괄하여 지칭된다. 당업자에 의해 인식되는 바와 같이, RAN (120) 은 다수의 RNC들 및 서브넷들을 포함할 수 있으며, 편의상 도 2b 에 단일 RNC 가 도시된다. RNC (215B) 는 코어 네트워크 (140) 에서의 서빙 GRPS 지원 노드 (SGSN) (220B) 와 RAN (120) 에 의해 서빙되는 UE들 사이의 베어러 채널들 (즉, 데이터 채널들) 을 시그널링하고, 확립하고 그리고 분리하는 것을 담당한다. 링크 계층 암호화가 이용가능하면, RNC (215B) 는 또한 콘텐츠를, 공중 인터페이스를 통한 송신을 위해 그것을 RAN (120) 로 포워딩하기 전에 암호화한다. RNC (215B) 의 기능은 당업계에 널리 알려져 있으며, 간결성을 위해서 더 설명하지 않는다.
도 2b 에서, 코어 네트워크 (140) 는 위에서 언급한 SGSN (220B) (및 잠재적으로 다수의 다른 SGSN들도 또한) 및 GGSN (225B) 을 포함한다. 일반적으로, GPRS 는 IP 패킷들을 라우팅하기 위해 GSM 에서 사용되는 프로토콜이다. GPRS 코어 네트워크 (예컨대, GGSN (225B) 및 하나 이상의 SGSN들 (220B)) 는 GPRS 시스템의 중앙집중화된 부분이며, 또한 W-CDMA 기반의 3G 액세스 네트워크들에 대한 지원을 제공한다. GPRS 코어 네트워크는 GSM 및 W-CDMA 네트워크들에서의 모빌리티 관리, 세션 관리 및 IP 패킷 서비스들을 위한 전송을 제공하는 GSM 코어 네트워크 (즉, 코어 네트워크 (140)) 의 통합된 부분이다.
GPRS 터널링 프로토콜 (GTP) 은 GPRS 코어 네트워크의 IP 프로토콜을 정의하고 있다. GTP 는 GSM 또는 W-CDMA 네트워크의 최종 사용자들 (예컨대, UE들) 로 하여금 마치 GGSN (225B) 에서의 하나의 로케이션으로부터 처럼 인터넷 (175) 에 계속 접속하면서, 장소들 사이에 이동가능하게 하는 프로토콜이다. 이는 개개의 UE 의 데이터를 UE 의 현재의 SGSN (220B) 으로부터 개개의 UE 의 세션을 처리하고 있는 GGSN (225B) 으로 전달함으로써 달성된다.
GTP 의 3개의 형태들, 즉, (i) GTP-U, (ii) GTP-C 및 (iii) GTP' (GTP 프라임) 이 GPRS 코어 네트워크에 의해 사용된다. GTP-U 는 각각의 패킷 데이터 프로토콜 (PDP) 컨텍스트에 대해 분리된 터널들에서의 사용자 데이터의 전송용으로 사용된다. GTP-C 는 제어 시그널링 (예컨대, PDP 컨텍스트들의 셋업 및 삭제, GSN 도달가능성의 검증, 가입자가 하나의 SGSN 으로부터 다른 SGSN, 등으로 이동하는 경우와 같은 업데이트들 또는 변경들) 용으로 사용된다. GTP' 는 GSN들로부터 과금 기능부로의 과금 데이터의 전송용으로 사용된다.
도 2b 를 참조하면, GGSN (225B) 은 GPRS 백본 네트워크 (미도시) 와 인터넷 (175) 사이의 인터페이스로서 기능한다. GGSN (225B) 은 패킷 데이터 프로토콜 (PDP) 포맷 (예컨대, IP 또는 PPP) 과 연관된 패킷 데이터를 SGSN (220B) 으로부터 들어오는 GPRS 패킷들로부터 추출하고, 그 패킷들을 대응하는 패킷 데이터 네트워크 상으로 전송한다. 다른 방향에서, 인입하는 데이터 패킷들이 UE 에 접속된 GGSN 에 의해 RAN (120) 에 의해 서빙되는 타겟 UE 의 무선 액세스 베어러 (RAB) 를 관리하고 제어하는 SGSN (220B) 으로 안내된다. 이에 의해, GGSN (225B) 은 타겟 UE 의 현재의 SGSN 어드레스 및 그의 연관된 프로파일을 로케이션 레지스터에 (예컨대, PDP 컨텍스트 내에) 저장한다. GGSN (225B) 은 IP 어드레스 할당을 담당하며, 접속된 UE 에 대한 디폴트 라우터이다. GGSN (225B) 은 또한 인증 및 과금 기능들을 수행한다.
SGSN (220B) 은 일 예에서, 코어 네트워크 (140) 내 많은 SGSN들 중 하나를 나타낸다. 각각의 SGSN 은 연관된 지리적 서비스 영역 내 UE들로 그리고 그들로의 데이터 패킷들의 전달을 담당한다. SGSN (220B) 의 태스크들은 패킷 라우팅 및 전송, 모빌리티 관리 (예컨대, 부착/분리 및 로케이션 관리), 논리적 링크 관리, 및 인증 및 과금 기능들을 포함한다. SGSN (220B) 의 로케이션 레지스터는 로케이션 정보 (예컨대, 현재의 셀, 현재의 VLR) 및 SGSN (220B) 에 등록된 모든 GPRS 사용자들의 사용자 프로파일들 (예컨대, IMSI, 패킷 데이터 네트워크에 사용되는 PDP 어드레스(들)) 을, 예를 들어, 각각의 사용자 또는 UE 에 대한 하나 이상의 PDP 컨텍스트들 내에 저장한다. 따라서, SGSN들 (220B) 은 (i) GGSN (225B) 으로부터의 디-터널링 다운링크 GTP 패킷들, (ii) GGSN (225B) 으로부터의 업링크 터널 IP 패킷들, (iii) UE들이 SGSN 서비스 영역들 사이에 이동함에 따라서 모빌리티 관리를 수행하는 것 및 (iv) 모바일 가입자들에게 청구서를 발부하는 것을 담당한다. 당업자에 의해 인식되는 바와 같이, (i) - (iv) 를 제외하고는, GSM/EDGE 네트워크들용으로 구성된 SGSN들은 W-CDMA 네트워크들용으로 구성된 SGSN들에 비해 약간 상이한 기능을 갖는다.
RAN (120) (예컨대, 또는 UMTS 시스템 아키텍처에서, UTRAN) 은 무선 액세스 네트워크 애플리케이션 부분 (RANAP) 프로토콜을 통해서 SGSN (220B) 과 통신한다. RANAP 는 프레임 릴레이 (Frame Relay) 또는 IP 와 같은 송신 프로토콜과의 Iu 인터페이스 (Iu-ps) 를 통해서, 동작한다. SGSN (220B) 은 SGSN (220B) 및 다른 SGSN들 (미도시) 과 내부 GGSN들 (미도시) 사이의 IP-기반의 인터페이스인 Gn 인터페이스를 통해서 GGSN (225B) 과 통신하며, 위에서 정의된 GTP 프로토콜 (예컨대, GTP-U, GTP-C, GTP', 등) 을 이용한다. 도 2b 의 실시형태에서, SGSN (220B) 과 GGSN (225B) 사이의 Gn 은 GTP-C 및 GTP-U 양쪽을 수행한다. 도 2b 에 도시되지 않지만, Gn 인터페이스가 또한 도메인 네임 시스템 (DNS) 에 의해 사용된다. GGSN (225B) 은 공공 데이터 네트워크 (PDN) (미도시) 에, 그후에 인터넷 (175) 에, 직접 또는 무선 애플리케이션 프로토콜 (WAP) 게이트웨이를 통한 IP 프로토콜들과의 Gi 인터페이스를 통해서, 접속된다.
도 2c 는 본 발명의 일 실시형태에 따른, 3G UMTS W-CDMA 시스템 내에서 GPRS 코어 네트워크로서 구성되는 코어 네트워크 (140) 의 패킷-스위칭 부분 및 RAN (120) 의 다른 예시적인 구성을 예시한다. 도 2b 와 유사하게, 코어 네트워크 (140) 는 SGSN (220B) 및 GGSN (225B) 을 포함한다. 그러나, 도 2c 에서, 직접 터널 (Direct Tunnel) 은 SGSN (220B) 으로 하여금 PS 도메인 내 GGSN (225B) 과 RAN (120) 사이에, 직접 사용자 플레인 터널, GTP-U 를 확립가능하게 하는 Iu 모드에서 옵션적인 기능이다. 도 2c 에서의 SGSN (220B) 와 같은, 직접 터널 가능 SGSN 은 SGSN (220B) 이 직접 사용자 플레인 접속을 이용할 수 있는지 여부를 매 GGSN 마다 및 매 RNC 마다 구성될 수 있다. 도 2c 에서의 SGSN (220B) 은 제어 플레인 시그널링을 처리하며 직접 터널을 확립할 시점을 결정한다. PDP 컨텍스트에 할당된 RAB 가 해제될 때 (즉, PDP 컨텍스트가 유지될 때), 다운링크 패킷들을 처리가능하게 하기 위해서, GTP-U 터널이 GGSN (225B) 과 SGSN (220B) 사이에 확립된다.
도 2d 는 본 발명의 일 실시형태에 따른, EPS (Evolved Packet System) 또는 LTE 네트워크에 기초한, 코어 네트워크 (140) 의 패킷-스위칭 부분 및 RAN (120) 의 예시적인 구성을 예시한다. 도 2d 를 참조하면, 도 2b 내지 도 2c 에 나타낸 RAN (120) 과는 달리, EPS / LTE 네트워크에서의 RAN (120) 은 도 2b 내지 도 2c 의 RNC (215B) 없이, 복수의 진화된 노드 B들 (ENodeB들 또는 eNB들) (200D, 205D 및 210D) 로 구성된다. 이는 EPS / LTE 네트워크들에서의 ENodeB들이 코어 네트워크 (140) 와 통신하기 위해 RAN (120) 내에 별개의 제어기 (즉, RNC (215B)) 를 필요로 하지 않기 때문이다. 다시 말해서, 도 2b 내지 도 2c 의 RNC (215B) 의 기능 중 일부가 도 2d 에서 RAN (120) 의 각각의 개개의 eNodeB 에 내장된다.
도 2d 에서, 코어 네트워크 (140) 는 복수의 모빌리티 관리 엔터티들 (MME들) (215D 및 220D), HSS (Home Subscriber Server) (225D), 서빙 게이트웨이 (S-GW) (230D), 패킷 데이터 네트워크 게이트웨이 (P-GW) (235D) 및 정책 및 과금 규칙들 기능부 (PCRF) (240D) 를 포함한다. 이들 컴포넌트들, RAN (120) 및 인터넷 (175) 사이의 네트워크 인터페이스들이 도 2d 에 예시되며, (아래) 표 1 에 다음과 같이 정의된다:
|
네트워크
인터페이스 |
설명 |
| S1-MME | RAN (120) 과 MME (215D) 사이의 제어 플레인 프로토콜을 위한 참조 지점. |
| S1-U | 핸드오버 동안 매 베어러 당 사용자 플레인 터널링 및 인터-eNodeB 경로 스위칭을 위한 RAN (120) 과 S-GW (230D) 사이의 참조 지점. |
| S5 | S-GW (230D) 와 P-GW (235D) 사이에 사용자 플레인 터널링 및 터널 관리를 제공한다. 이는 UE 모빌리티로 인한 S-GW 리로케이션, 그리고 S-GW (230D) 가 요구된 PDN 연결을 위해 비-동일 위치에 배치된 P-GW 에 접속할 필요가 있는 경우 이용된다. |
| S6a | MME (215D) 와 HSS (225D) 사이의 진화된 시스템 (인증, 권한부여, 및 과금 [AAA] 인터페이스) 에의 사용자 액세스를 인증/인가하기 위한 가입 및 인증 데이터의 전송을 인에이블한다. |
| Gx | PCRF (240D) 로부터 정책 및 P-GW (235D) 에서의 과금 시행 기능부 (PCEF) 컴포넌트 (미도시) 로의 서비스 품질 (QoS) 정책 및 과금 규칙들의 전송을 제공한다. |
| S8 | 방문 공중 지상 모바일 네트워크 (VPLMN) 에서의 S-GW (230D) 와 홈 공중 지상 모바일 네트워크 (HPLMN) 에서의 P-GW (235D) 사이에 사용자 및 제어 플레인을 제공하는 인터-PLMN 참조 지점. S8 은 S5 의 인터-PLMN 변형이다. |
| S10 | MME 리로케이션 및 MME 간 정보 전송을 위한 MME들 215D 과 220D 사이의 참조 지점. |
| S11 | MME (215D) 와 S-GW (230D) 사이의 참조 지점. |
| SGi | 도 2d 에 인터넷 (175) 으로서 도시된, 패킷 데이터 네트워크와 P-GW (235D) 사이의 참조 지점. 패킷 데이터 네트워크는 (예컨대, IMS 서비스들의 제공을 위한) 인트라-운영자 패킷 데이터 네트워크 (intra-operator packet data network) 또는 운영자 외부 공공 또는 사설 패킷 데이터 네트워크일 수도 있다. 이 참조 지점은 3GPP 액세스들을 위한 Gi 에 대응한다. |
| X2 | UE 핸드오프들용으로 사용되는 2개의 상이한 eNodeB들 사이의 참조 지점. |
| Rx | PCRF (240D) 와 애플리케이션-레벨 세션 정보를 스위칭하는데 사용되는 애플리케이션 기능부 (AF) 사이의 참조 지점, 여기서 AF 는 도 1 에 애플리케이션 서버 (170) 로 표시된다. |
표 1 - EPS /
LTE
코어 네트워크 접속 정의들
도 2d 의 RAN (120) 및 코어 네트워크 (140) 에 도시된 컴포넌트들의 하이-레벨 설명이 이하 설명될 것이다. 그러나, 이들 컴포넌트들은 여러 3GPP TS 표준들의 분야에서 널리 알려져 있으며, 본원에서 포함되는 설명은 이들 컴포넌트들에 의해 수행되는 모든 기능들의 완전한 설명이 되도록 의도하지 않는다.
도 2d 를 참조하면, MME들 (215D 및 220D) 은 EPS 베어러들에 대한 제어 플레인 시그널링을 관리하도록 구성된다. MME 기능들은 비-액세스 계층 (NAS) 시그널링, NAS 시그널링 보안, 인터- 및 인트라-기술 핸드오버들을 위한 모빌리티 관리, P-GW 및 S-GW 선택, 및 MME 변화에 의한 핸드오버들을 위한 MME 선택을 포함한다.
도 2d 를 참조하면, S-GW (230D) 는 RAN (120) 측으로의 인터페이스를 종단하는 게이트웨이이다. EPS-기반의 시스템에 대한 코어 네트워크 (140) 와 연관된 각각의 UE 에 대해, 주어진 시간의 지점에서, 단일 S-GW 가 존재한다. GTP-기반 및 프록시 모바일 IPv6 (PMIP)-기반의 S5/S8 양쪽에 대한, S-GW (230D) 의 기능들은, 모빌리티 앵커 지점, 패킷 라우팅 및 포워딩, 및 연관된 EPS 베어러의 QoS 클래스 식별자 (QCI) 에 기초한 DiffServ 코드 지점 (DSCP) 을 설정하는 것을 포함한다.
도 2d 를 참조하면, P-GW (235D) 는 패킷 데이터 네트워크 (PDN), 예컨대, 인터넷 (175) 측으로의 SGi 인터페이스를 종단하는 게이트웨이이다. UE 가 다수의 PDN들에 액세스하고 있으면, 그 UE 에 대해 하나 보다 많은 P-GW 가 존재할 수도 있으며; 그러나, S5/S8 연결과 Gn/Gp 연결의 혼합은 일반적으로 그 UE 에 대해 동시에 지원되지 않는다. P-GW 기능들은 GTP-기반의 S5/S8 양쪽에 대해 다음을 포함한다: (심층 패킷 검사에 의한) 패킷 필터링, UE IP 어드레스 할당, 연관된 EPS 베어러의 QCI 에 기초하여 DSCP 를 설정하는 것, 인터 운영자간 요금을 과금, 3GPP TS 23.203 에 정의된 바와 같은 업링크 (UL) 및 다운링크 (DL) 베어러 바인딩, 3GPP TS 23.203 에 정의된 바와 같은 UL 베어러 바인딩 검증. P-GW (235D) 는 E-UTRAN, GERAN, 또는 UTRAN 중 임의의 것을 이용하여 GSM/EDGE 양쪽의 무선 액세스 네트워크 (GERAN)/UTRAN 단독 UE들 (UTRAN only UEs) 및 E-UTRAN-가능한 UE들에의 PDN 연결을 제공한다. P-GW (235D) 는 S5/S8 인터페이스를 통해서 E-UTRAN 만을 이용하여 E-UTRAN 가능한 UE들에의 PDN 연결을 제공한다.
도 2d 를 참조하면, PCRF (240D) 는 EPS-기반의 코어 네트워크 (140) 의 정책 및 과금 제어 엘리먼트이다. 비-로밍 시나리오에서, UE 의 인터넷 프로토콜 연결 액세스 네트워크 (IP-CAN) 세션과 연관된 HPLMN 에서 단일 PCRF 가 존재한다. PCRF 는 Rx 인터페이스 및 Gx 인터페이스를 종단한다. 트래픽의 로컬 브레이크아웃을 가지는 로밍 시나리오에서는, UE 의 IP-CAN 세션과 연관된 2개의 PCRF들이 존재할 수도 있다: 홈 PCRF (H-PCRF) 는 HPLMN 내에 상주하는 PCRF 이고, 방문 PCRF (V-PCRF) 는 방문 VPLMN 내에 상주하는 PCRF 이다. PCRF 는 3GPP TS 23.203 에서 좀더 자세히 설명되어 있으며, 이에 따라서 간결성을 위해 추가로 설명되지 않을 것이다. 도 2d 에서, (예컨대, 3GPP 전문용어에서 AF 로서 지칭될 수도 있는) 애플리케이션 서버 (170) 는 인터넷 (175) 을 통해서 코어 네트워크 (140) 에, 또는 대안적으로는, Rx 인터페이스를 통해서 직접 PCRF (240D) 에 접속된 것으로 도시된다. 일반적으로, 애플리케이션 서버 (170) (또는, AF) 는 코어 네트워크와의 IP 베어러 리소스들 (예컨대, UMTS PS 도메인/GPRS 도메인 리소스들/LTE PS 데이터 서비스들) 을 이용하는 애플리케이션을 제공하는 엘리먼트이다. 애플리케이션 기능의 일 예는 IP 멀티미디어 서브시스템 (IMS) 코어 네트워크 서브 시스템의 프록시-콜 세션 제어 기능 (P-CSCF) 이다. AF 는 Rx 참조 지점을 이용하여 세션 정보를 PCRF (240D) 에 제공한다. 셀룰러 네트워크를 통해서 IP 데이터 서비스들을 제공하는 임의의 다른 애플리케이션 서버는 또한 PCRF (240D) 에 Rx 참조 지점을 통해서 접속될 수 있다.
도 2e 는 본 발명의 일 실시형태에 따른, EPS 또는 LTE 네트워크 (140A) 에 접속된 HRPD (enhanced High Rate Packet Data) RAN 으로서 구성된 RAN (120) 및 또한 HRPD 코어 네트워크 (140B) 의 패킷-스위칭 부분의 일 예를 예시한다. 코어 네트워크 (140A) 는 도 2d 와 관련하여 위에서 설명된 코어 네트워크와 유사하게, EPS 또는 LTE 코어 네트워크이다.
도 2e 에서, eHRPD RAN 은 향상된 BSC (eBSC) 및 향상된 PCF (ePCF) (215E) 에 접속된 복수의 송수신기 기지국들 (BTSs) (200E, 205E 및 210E) 을 포함한다. eBSC/ePCF (215E) 는 S101 인터페이스를 통해서 EPS 코어 네트워크 (140A) 내의 MME들 215D 또는 220D 중 하나에, 그리고 EPS 코어 네트워크 (140A) 에서의 다른 엔터티들과 (예컨대, S103 인터페이스를 통해 S-GW (230D), S2a 인터페이스를 통해 P-GW (235D), Gxa 인터페이스를 통해 PCRF (240D), STa 인터페이스를 통해 3GPP AAA 서버 (도 2d 에 명시적으로 미도시), 등을) 인터페이스하기 위해 A10 및/또는 A11 인터페이스들을 통해 HRPD 서빙 게이트웨이 (HSGW) (220E) 에 접속할 수 있다. HSGW (220E) 는 HRPD 네트워크들과 EPS / LTE 네트워크들 사이의 상호작용을 제공하기 위해 3GPP2 에 정의되어 있다. 주지하고 있는 바와 같이, eHRPD RAN 및 HSGW (220E) 는 레거시 HRPD 네트워크들에서 이용불가능한 EPC / LTE 네트워크들에의 인터페이스 기능으로 구성된다.
eHRPD RAN 로 되돌아가면, EPS / LTE 네트워크 (140A) 와 인터페이스하는 것에 더해서, eHRPD RAN 은 또한 HRPD 네트워크 (140B) 와 같은 레거시 HRPD 네트워크들과 인터페이스할 수 있다. 주지하는 바와 같이, HRPD 네트워크 (140B) 는 도 2a 의 EV-DO 네트워크와 같은 레거시 HRPD 네트워크의 예시적인 구현예이다. 예를 들어, eBSC/ePCF (215E) 는 A12 인터페이스를 통해서 인증, 권한부여 및 과금 (AAA) 서버 (225E) 와, 또는 A10 또는 A11 인터페이스를 통해서 PDSN / FA (230E) 에 인터페이스할 수 있다. PDSN / FA (230E) 는 결국 HA (235A) 에 접속하며, 이를 통해서 인터넷 (175) 에 액세스될 수 있다. 도 2e 에서, 어떤 인터페이스들 (예컨대, A13, A16, H1, H2, 등) 은 명시적으로 설명되지 않지만 완전성을 위해 도시되며, HRPD 또는 eHRPD 에 정통한 당업자에 의해 이해될 것이다.
도 2b 내지 도 2e 를 참조하면, eHRPD RAN들 및 HSGWs (예컨대, 도 2e) 와 인터페이스하는 HRPD 코어 네트워크들 및 LTE 코어 네트워크들 (예컨대, 도 2d) 이 어떤 경우들에서 (예컨대, P-GW, GGSN, SGSN, 등에 의해) 네트워크-개시되는 서비스 품질 (QoS) 을 지원할 수 있을 명백히 알 수 있을 것이다.
도 3 은 본 발명의 실시형태들에 따른 UE들의 예들을 예시한다. 도 3 을 참조하면, UE (300A) 는 콜링 전화기 (calling telephone) 로서 예시되며, UE (300B) 는 터치스크린 디바이스 (예컨대, 스마트 폰, 태블릿 컴퓨터, 등) 로서 예시된다. 도 3 에 나타낸 바와 같이, UE (300A) 의 외부 케이싱은 당업계에 알려져 있는 바와 같이, 다른 컴포넌트들 중에서, 안테나 (305A), 디스플레이 (310A), 적어도 하나의 버튼 (315A) (예컨대, PTT 버튼, 전원 버튼, 볼륨 제어 버튼, 등) 및 키패드 (320A) 로 구성된다. 또한, UE (300B) 의 외부 케이싱은 당업계에 알려져 있는 바와 같이, 다른 컴포넌트들 중에서, 터치스크린 디스플레이 (305B), 주변의 버튼들 (310B, 315B, 320B 및 325B) (예컨대, 전력 제어 버튼, 볼륨 또는 진동 제어 버튼, 비행기 모드 토글 버튼, 등), 적어도 하나의 전면-패널 버튼 (330B) (예컨대, 홈 버튼, 등) 으로 구성된다. UE (300B) 의 일부로서 명시적으로 나타내지 않았지만, UE (300B) 는 WiFi 안테나들, 셀룰러 안테나들, 위성 측위 시스템 (SPS; satellite position system) 안테나들 (예컨대, 전지구 측위 시스템 (GPS) 안테나들) 등을 포함하지만 이에 한정되지 않는, UE (300B) 의 외부 케이싱에 내장되는 하나 이상의 통합된 안테나들 및/또는 하나 이상의 외부 안테나들을 포함할 수 있다.
UE들 (300A 및 300B) 과 같은, UE들의 내부 컴포넌트들은 상이한 하드웨어 구성들로 구현될 수 있지만, 내부 하드웨어 컴포넌트들에 대한 기본적인 하이-레벨 구성은 도 3 에 플랫폼 (302) 으로서 도시된다. 플랫폼 (302) 은 코어 네트워크 (140), 인터넷 (175) 및/또는 다른 원격 서버들 및 네트워크들 (예컨대, 애플리케이션 서버 (170), 웹 URL들, 등) 로부터 궁극적으로 유래할 수도 있는, RAN (120) 으로부터 송신된 소프트웨어 애플리케이션들, 데이터 및/또는 지령들을 수신하여 실행할 수 있다. 플랫폼 (302) 은 또한 로컬로 저장된 애플리케이션들을 RAN 상호작용 없이 독립적으로 실행할 수 있다. 플랫폼 (302) 은 주문형 집적회로 (ASIC) (308), 또는 다른 프로세서, 마이크로프로세서, 로직 회로, 또는 다른 데이터 프로세싱 디바이스에 동작가능하게 커플링된 송수신기 (306) 를 포함할 수 있다. ASIC (308) 또는 다른 프로세서는 무선 디바이스의 메모리 (312) 에서의 임의의 상주 프로그램들과 인터페이스하는 애플리케이션 프로그래밍 인터페이스 (API) (310) 계층을 실행한다. 메모리 (312) 는 판독 전용 또는 랜덤-액세스 메모리 (RAM 및 ROM), EEPROM, 플래시 카드들, 또는 컴퓨터 플랫폼들에 공통된 임의의 메모리를 포함할 수도 있다. 플랫폼 (302) 은 또한 메모리 (312) 에 능동적으로 사용되지 않는 애플리케이션들 뿐만 아니라, 다른 데이터도 저장할 수 있는 로컬 데이터베이스 (314) 를 포함할 수 있다. 로컬 데이터베이스 (314) 는 일반적으로 플래시 메모리 셀이지만, 자기 매체들, EEPROM, 광학 매체들, 테이프, 또는 소프트 또는 하드 디스크, 등과 같은, 당업계에 알려져 있는 바와 같은 임의의 2차 저장 디바이스일 수도 있다.
따라서, 본 개시물의 양태들은 본원에서 설명되는 기능들을 수행하는 능력을 포함하는 UE (예컨대, UE (300A, 300B), 등) 를 포함할 수 있다. 당업자들이 명백히 주지하고 있는 바와 같이, 여러 로직 엘리먼트들은 본원에서 개시되는 기능을 달성하기 위해 별개의 엘리먼트들로, 프로세서 상에서 실행되는 소프트웨어 모듈들로, 또는 소프트웨어와 하드웨어의 임의의 조합으로 구현될 수 있다. 예를 들어, ASIC (308), 메모리 (312), API (310) 및 로컬 데이터베이스 (314) 는 본원에서 개시되는 여러 기능들을 로드하고, 저장하고 그리고 실행하기 위해 협력적으로 모두 사용될 수도 있으며, 따라서 이들 기능들을 수행하는 로직은 여러 엘리먼트들에 걸쳐서 분산될 수도 있다. 대안적으로, 기능은 하나의 별개의 컴포넌트로 통합될 수 있다. 따라서, 도 3 에서 UE들 (300A 및 300B) 의 특징들은 단지 예시적인 것으로 간주되어야 하며 본 발명은 예시된 특징들 또는 배열에 한정되지 않는다.
UE들 (300A 및/또는 300B) 과 RAN (120) 사이의 무선 통신은 CDMA, W-CDMA, 시분할 다중접속 (TDMA), 주파수 분할 다중접속 (FDMA), 직교 주파수 분할 멀티플렉싱 (OFDM), GSM, 또는 무선 통신 네트워크 또는 데이터 통신 네트워크에서 사용될 수도 있는 다른 프로토콜들과 같은, 상이한 기술들에 기초할 수 있다. 위에서 설명한 바와 같이, 그리고 당업계에 알려져 있는 바와 같이, 보이스 송신 및/또는 데이터는 다양한 네트워크들 및 구성들을 이용하여 RAN 으로부터 UE들로 송신될 수 있다. 따라서, 본원에서 제공되는 예시들은 본 발명의 실시형태들에 한정하려는 것이 아니라, 단지 본 발명의 실시형태들의 양태들의 설명을 도우려는 것이다.
도 4 는 기능을 수행하도록 구성된 로직을 포함하는 통신 디바이스 (400) 를 예시한다. 통신 디바이스 (400) 는 UE들 (300A 또는 300B), RAN (120) 의 임의의 컴포넌트 (예컨대, BS들 (200A 내지 210A), BSC (215A), 노드 B들 (200B 내지 210B), RNC (215B), eNodeB들 (200D 내지 210D), 등), 코어 네트워크 (140) 의 임의의 컴포넌트 (예컨대, PCF (220A), PDSN (225A), SGSN (220B), GGSN (225B), MME (215D 또는 220D), HSS (225D), S-GW (230D), P-GW (235D), PCRF (240D)), 코어 네트워크 (140) 및/또는 인터넷 (175) (예컨대, 애플리케이션 서버 (170)) 와 커플링된 임의의 컴포넌트들 등을 포함하지만 이에 한정되지 않는, 위에서 언급한 통신 디바이스들 중 임의의 디바이스에 대응할 수 있다. 따라서, 통신 디바이스 (400) 는 도 1 의 무선 통신 시스템 (100) 을 통해서 하나 이상의 다른 엔터티들과 통신하도록 (또는, 그와의 통신을 촉진하도록) 구성되는 임의의 전자 디바이스에 대응할 수 있다.
도 4 를 참조하면, 통신 디바이스 (400) 는 정보를 수신하거나 및/또는 송신하도록 구성된 로직 (405) 을 포함한다. 일 예에서, 통신 디바이스 (400) 가 무선 통신 디바이스 (예컨대, UE (300A 또는 300B), BS들 (200A 내지 210A) 중 하나, 노드 B들 (200B 내지 210B) 중 하나, eNodeB들 (200D 내지 210D) 중 하나, 등) 에 대응하면, 정보를 수신하고 및/또는 송신하도록 구성된 로직 (405) 은 무선 송수신기 및 연관된 하드웨어 (예컨대, RF 안테나, 모뎀, 변조기 및/또는 복조기, 등) 과 같은 무선 통신 인터페이스 (예컨대, Bluetooth, WiFi, 2G, CDMA, W-CDMA, 3G, 4G, LTE, 등) 를 포함할 수 있다. 또 다른 예에서, 정보를 수신하거나 및/또는 송신하도록 구성된 로직 (405) 은 유선 통신 인터페이스 (예컨대, 직렬 접속, USB 또는 Firewire 접속, 인터넷 (175) 이 액세스될 수 있는 이더넷 접속, 등) 에 대응할 수 있다. 따라서, 통신 디바이스 (400) 가 일부 유형의 네트워크-기반의 서버 (예컨대, PDSN, SGSN, GGSN, S-GW, P-GW, MME, HSS, PCRF, 애플리케이션 (170), 등) 에 대응하면, 정보를 수신하거나 및/또는 송신하도록 구성된 로직 (405) 은 일 예에서, 네트워크-기반의 서버를 다른 통신 엔터티들에 이더넷 프로토콜을 통해서 접속하는 이더넷 카드에 대응할 수 있다. 추가적인 예에서, 정보를 수신하거나 및/또는 송신하도록 구성된 로직 (405) 은 통신 디바이스 (400) 가 그의 로컬 환경 (예컨대, 가속도계, 온도 센서, 광 센서, 로컬 RF 신호들을 모니터링하는 안테나 등) 을 모니터링할 수 있게 하는 감각 또는 측정 하드웨어를 포함할 수 있다. 정보를 수신하거나 및/또는 송신하도록 구성된 로직 (405) 은 또한 실행될 때, 정보를 수신하거나 및/또는 송신하도록 구성된 로직 (405) 의 연관된 하드웨어가 그의 수신 및/또는 송신 기능(들)을 수행하도록 하는 소프트웨어를 포함할 수 있다. 그러나, 정보를 수신하거나 및/또는 송신하도록 구성된 로직 (405) 은 소프트웨어에 단독으로 대응하지 않으며, 정보를 수신하거나 및/또는 송신하도록 구성된 로직 (405) 은 그의 기능을 달성하기 위해 하드웨어에 적어도 부분적으로 의존한다.
도 4 를 참조하면, 통신 디바이스 (400) 는 정보를 프로세싱하도록 구성된 로직 (410) 을 더 포함한다. 일 예에서, 정보를 프로세싱하도록 구성된 로직 (410) 은 적어도 프로세서를 포함할 수 있다. 정보를 프로세싱하도록 구성된 로직 (410) 에 의해 수행될 수 있는 프로세싱의 형태의 예시적인 구현예들은, 결정들을 수행하는 것, 접속들을 확립하는 것, 상이한 정보 옵션들 사이에 선택을 행하는 것, 데이터와 관련된 평가들을 수행하는 것, 측정 동작들을 수행하기 위해 통신 디바이스 (400) 에 커플링된 센서들과 상호작용하는 것, 정보를 하나의 포맷으로부터 또 다른 포맷으로 (예컨대, .wmv 로부터 .avi 로, 등과 같은 상이한 프로토콜들 사이에) 변환하는 것 등을 포함하지만 이에 한정되지 않는다. 예를 들어, 정보를 프로세싱하도록 구성된 로직 (410) 에 포함되는 프로세서는 범용 프로세서, 디지털 신호 프로세서 (DSP), ASIC, 필드 프로그래밍가능 게이트 어레이 (FPGA) 또는 다른 프로그래밍가능 로직 디바이스, 이산 게이트 또는 트랜지스터 로직, 이산 하드웨어 컴포넌트들, 또는 본원에서 설명한 기능들을 수행하도록 설계된 이들의 임의의 조합에 대응할 수 있다. 범용 프로세서는 마이크로프로세서일 수도 있으며, 그러나 대안적으로는, 프로세서는 임의의 종래의 프로세서, 제어기, 마이크로제어기 또는 상태 머신일 수도 있다. 프로세서는 또한 컴퓨팅 디바이스들의 조합, 예컨대, DSP 와 마이크로프로세서의 조합, 복수의 마이크로프로세서들, DSP 코어와 결합된 하나 이상의 마이크로프로세서들, 또는 임의의 다른 이러한 구성으로서 구현될 수도 있다. 정보를 프로세싱하도록 구성된 로직 (410) 은 또한 실행될 때, 정보를 프로세싱하도록 구성된 로직 (410) 의 연관된 하드웨어로 하여금 그의 프로세싱 기능(들)을 수행하도록 하는 소프트웨어를 포함할 수 있다. 그러나, 정보를 프로세싱하도록 구성된 로직 (410) 은 소프트웨어에 단독으로 대응하지 않으며, 정보를 프로세싱하도록 구성된 로직 (410) 은 그의 기능을 달성하기 위해 하드웨어에 적어도 부분적으로 의존한다.
도 4 를 참조하면, 통신 디바이스 (400) 는 정보를 저장하도록 구성된 로직 (415) 을 더 포함한다. 일 예에서, 정보를 저장하도록 구성된 로직 (415) 은 적어도 비일시적 메모리 및 연관된 하드웨어 (예컨대, 메모리 제어기, 등) 를 포함할 수 있다. 예를 들어, 정보를 저장하도록 구성된 로직 (415) 에 포함되는 비일시적 메모리는 RAM 메모리, 플래시 메모리, ROM 메모리, EPROM 메모리, EEPROM 메모리, 레지스터들, 하드 디스크, 착탈식 디스크, CD-ROM, 또는 당업계에 알려져 있는 임의의 다른 유형의 저장 매체에 대응할 수 있다. 정보를 저장하도록 구성된 로직 (415) 은 또한 실행될 때, 정보를 저장하도록 구성된 로직 (415) 의 연관된 하드웨어로 하여금, 그의 스토리지 기능(들)을 수행하도록 하는 소프트웨어를 포함할 수 있다. 그러나, 정보를 저장하도록 구성된 로직 (415) 은 소프트웨어에 단독으로 대응하지 않으며, 정보를 저장하도록 구성된 로직 (415) 은 그의 기능을 달성하기 위해 하드웨어에 적어도 부분적으로 의존한다.
도 4 를 참조하면, 통신 디바이스 (400) 는 정보를 제시하도록 구성된 로직 (420) 을 옵션으로 더 포함한다. 일 예에서, 정보를 제시하도록 구성된 로직 (420) 은 출력 디바이스 및 연관된 하드웨어를 적어도 포함할 수 있다. 예를 들어, 출력 디바이스는 비디오 출력 디바이스 (예컨대, 디스플레이 스크린, 비디오 정보를 운반할 수 있는 포트, 예컨대 USB, HDMI, 등), 오디오 출력 디바이스 (예컨대, 스피커들, 오디오 정보를 운반할 수 있는 포트, 예컨대 마이크로폰 잭, USB, HDMI, 등), 진동 디바이스 및/또는 정보가 출력용으로 포맷되거나 또는 통신 디바이스 (400) 의 사용자 또는 운영자에 의해 실제로 출력될 수 있는 임의의 다른 디바이스를 포함할 수 있다. 예를 들어, 통신 디바이스 (400) 가 도 3 에 나타낸 바와 같이 UE (300A) 또는 UE (300B) 와 대응하면, 정보를 제시하도록 구성된 로직 (420) 은 UE (300A) 의 디스플레이 (310A) 또는 UE (300B) 의 터치스크린 디스플레이 (305B) 를 포함할 수 있다. 추가적인 예에서, 정보를 제시하도록 구성된 로직 (420) 은 로컬 사용자 (예컨대, 네트워크 스위치들 또는 라우터들, 원격 서버들, 등) 를 갖지 않는 네트워크 통신 디바이스들과 같은, 어떤 통신 디바이스들에 대해 생략될 수 있다. 정보를 제시하도록 구성된 로직 (420) 은 또한 실행될 때, 정보를 제시하도록 구성된 로직 (420) 의 연관된 하드웨어로 하여금 그의 프리젠테이션 기능(들)을 수행하도록 하는 소프트웨어를 포함할 수 있다. 그러나, 정보를 제시하도록 구성된 로직 (420) 은 소프트웨어에 단독으로 의존하지 않으며, 정보를 제시하도록 구성된 로직 (420) 은 그의 기능을 달성하기 위해 하드웨어에 적어도 부분적으로 의존한다.
도 4 를 참조하면, 통신 디바이스 (400) 는 로컬 사용자 입력을 수신하도록 구성된 로직 (425) 을 옵션으로 더 포함한다. 일 예에서, 로컬 사용자 입력을 수신하도록 구성된 로직 (425) 은 사용자 입력 디바이스 및 연관된 하드웨어를 적어도 포함할 수 있다. 예를 들어, 사용자 입력 디바이스는 버튼들, 터치스크린 디스플레이, 키보드, 카메라, 오디오 입력 디바이스 (예컨대, 마이크로폰 잭, 등과 같은 오디오 정보를 운반하는 마이크로폰 또는 포트), 및/또는 정보가 통신 디바이스 (400) 의 사용자 또는 운영자로부터 수신될 수 있는 임의의 다른 디바이스를 포함할 수 있다. 예를 들어, 통신 디바이스 (400) 가 도 3 에 나타낸 바와 같이 UE (300A) 또는 UE (300B) 에 대응하면, 로컬 사용자 입력을 수신하도록 구성된 로직 (425) 은 키패드 (320A), 버튼들 (315A 또는 310B 내지 325B) 중 임의의 버튼, 터치스크린 디스플레이 (305B), 등을 포함할 수 있다. 추가적인 예에서, 로컬 사용자 입력을 수신하도록 구성된 로직 (425) 은 로컬 사용자 (예컨대, 네트워크 스위치들 또는 라우터들, 원격 서버들, 등) 를 갖지 않는 네트워크 통신 디바이스들과 같은, 어떤 통신 디바이스들에 대해 생략될 수 있다. 로컬 사용자 입력을 수신하도록 구성된 로직 (425) 은 또한 실행될 때, 로컬 사용자 입력을 수신하도록 구성된 로직 (425) 의 연관된 하드웨어로 하여금 그의 입력 수신 기능(들)을 수행하도록 하는 소프트웨어를 포함할 수 있다. 그러나, 로컬 사용자 입력을 수신하도록 구성된 로직 (425) 은 소프트웨어에 단독으로 의존하지 않으며, 로컬 사용자 입력을 수신하도록 구성된 로직 (425) 은 그의 기능을 달성하기 위해 하드웨어에 적어도 부분적으로 의존한다.
도 4 를 참조하면, 405 내지 425 의 구성된 로직들은 도 4 에 별개의 또는 별도의 블록들로서 도시되지만, 각각의 구성된 로직이 그의 기능을 수행하는 소프트웨어 및/또는 하드웨어가 부분적으로 중첩할 수 있음을 명백히 알 수 있을 것이다. 예를 들어, 405 내지 425 의 구성된 로직들의 기능을 촉진하기 위해 사용되는 임의의 소프트웨어는 405 내지 425 의 구성된 로직들이 각각이 정보를 저장하도록 구성된 로직 (415) 에 의해 저장되는 소프트웨어의 동작에 부분적으로 기초하여 그들의 기능 (즉, 이 경우, 소프트웨어 실행) 을 수행하도록, 정보를 저장하도록 구성된 로직 (415) 과 연관되는 비일시적 메모리에 저장될 수 있다. 이와 유사하게, 구성된 로직들 중 하나와 직접 연관되는 하드웨어는 다른 구성된 로직들에 의해 가끔 차용되거나 또는 사용될 수도 있다. 예를 들어, 정보를 프로세싱하도록 구성된 로직 (410) 의 프로세서는 정보를 수신하거나 및/또는 송신하도록 구성된 로직 (405) 이 정보를 프로세싱하도록 구성된 로직 (410) 과 연관되는 하드웨어 (즉, 프로세서) 의 동작에 부분적으로 기초하여 그의 기능 (즉, 이 경우, 데이터의 송신) 을 수행하도록, 정보를 수신하거나 및/또는 송신하도록 구성된 로직 (405) 에 의해 송신되기 전에 적합한 포맷으로 데이터를 포맷할 수 있다.
일반적으로, 명시적으로 달리 언급되지 않는 한, 본 개시물 전반에 걸쳐 사용될 때, 어구 "하도록 구성된 로직" 은 하드웨어로 적어도 부분적으로 구현되는 실시형태를 상기시키기 위해 의도되며, 하드웨어와 독립적인 소프트웨어-단독 구현예들에 맵핑하려고 의도되지 않는다. 또한, 여러 블록들에서 구성된 로직 또는 "하도록 구성된 로직" 은 특정의 로직 게이트들 또는 엘리먼트들에 한정되지 않으며, 그러나 일반적으로 본원에서 설명하는 기능을 (하드웨어 또는 하드웨어와 소프트웨어의 조합을 통해서) 수행하는 능력을 지칭한다는 것을 명백히 알 수 있을 것이다. 따라서, 여러 블록들에 예시된 바와 같은 구성된 로직들 또는 "하도록 구성된 로직" 은 단어 "로직" 을 공유함에도 불구하고 로직 게이트들 또는 로직 엘리먼트들로서 반드시 구현될 필요는 없다. 여러 블록들에서 로직 사이의 다른 상호작용들 또는 협력은 아래서 좀더 자세히 설명되는 실시형태들의 검토로부터 당업자에게 자명하게 될 것이다.
도 2a 에서의 1x EV-DO, 도 2b 내지 도 2c 에서의 UMTS-기반 W-CDMA, 도 2d 에서의 LTE 및 도 2e 에서의 eHRPD 와 같은 네트워크들을 통해서 동작하는 세션들은 서비스 품질 (QoS) 로서 지칭되는, 보장된 품질 레벨이 예약되는 채널들 (예컨대, RAB들, 흐름들, 등) 상에서 지원될 수 있다. 예를 들어, 특정의 채널 상에서 주어진 레벨의 QoS 를 확립하는 것은 그 채널 상에서의 최소 보장 비트 레이트 (GBR), 최대 지연, 지터, 레이턴시, 비트 에러 레이트 (BER) 등 중 하나 하나 이상을 제공할 수도 있다. QoS 리소스들은 VoIP (Voice-over IP) 세션들, 그룹 통신 세션들 (예컨대, PTT 세션들, 등), 온라인 게임들, IP TV, 및 기타 등등과 같은 실시간 또는 스트리밍 통신 세션들과 연관된 채널에 대해, 이들 세션들에 대한 끊김없는 종단간 패킷 전송을 보장하도록 돕기 위해, 예약될 (또는, 셋업될) 수 있다.
종래, QoS 베어러가 본원에서 App* 로서 표시된, 특정의 애플리케이션과 연관된 통신 세션 (예컨대, VoIP, PTT, 등) 에 대해 셋업되거나 또는 활성화될 때, QoS 는 통신 세션의 전체 지속기간 동안 업링크 및 다운링크 채널들 양쪽 상에서 셋업된다. 그러나, 당업자에 의해 인식되는 바와 같이, App* 통신 세션에 참가하는 주어진 UE 상의 클라이언트 애플리케이션은 통신 세션들에 대한 업링크 및 다운링크 채널들 양쪽 상에서 연속적으로 및/또는 동시에 송신하고 및/또는 수신하기 위해 높은 우선순위 트래픽을 가질 필요가 없다.
예를 들어, 하프 듀플렉스 App* 통신 세션 (예컨대, 1:1 또는 직접 콜, 또는 PTT 와 같은 그룹 콜) 에서, 플로어홀더 (floorholder) 는 업링크 채널 상에서 (즉, 비-플로어홀더들로) 송신하는데 높은 우선순위 트래픽을 가질 수도 있으며, 그러나 플로어홀더는 App* 세션의 하프 듀플렉스 성질로 인해 다운링크 채널 상에서 수신하는데 높은 우선순위 트래픽을 통상적으로 가지지 않을 것이다. 이와 유사하게, 위에서 언급된 하프 듀플렉스 App* 통신 세션에서, 비-플로어홀더(들) 은 다운링크 채널 상에서 (즉, 플로어홀더로부터) 수신하는데 높은 우선순위 트래픽을 가질 수도 있으며, 그러나 비-플로어홀더(들) 은 App* 세션의 하프 듀플렉스 성질로 인해 업링크 채널 상에서 송신하는데 높은 우선순위 트래픽을 통상적으로 가지지 않을 것이다. 또, 하프 듀플렉스 App* 세션 동안, 아무도 플로어를 유지하지 않는 (예컨대, 플로어-요청들을 제외한, 어느 하나의 방향에서 어떤 높은 우선순위 트래픽도 존재하지 않는) 시간들이 존재한다. 풀 듀플렉스 App* 통신 세션들 (예컨대, 1:1 또는 직접 콜) 로 전환하면, 콜에서의 주어진 당사자는 그들의 세션을 뮤트 (mute) 시킬 수도 있거나 또는 단지 대화하고 있지 않을 수도 있으며, 그결과 주어진 당사자가 업링크 채널 상에서 송신하는데 높은 우선순위 트래픽을 갖지 않는다. 주지하고 있는 바와 같이, 위에서 언급된 하프 듀플렉스 또는 풀 듀플렉스 App* 세션들 중 적어도 일부분 동안, App* 통신 세션 전반에 걸쳐서 양쪽의 방향들 (즉, 업링크 및 다운링크) 에서 개개의 세션 참가자에 대해 QoS 를 연속적으로 예약하는 것은, 각각의 QoS 예약이 시스템 (100) 의 전체 리소스 용량을 감소시키기 때문에 비효율적일 수 있다.
따라서, 본 발명의 실시형태들은 App* 통신 세션 동안 업링크 및/또는 다운링크 채널들에의 QoS 리소스들의 할당을 높은 우선순위 트래픽이 App* 통신 세션 동안 흐를 것으로 예상되는 (또는, 실제로 흐르고 있는) 방향 (예컨대, 업링크 및/또는 다운링크) 에 기초하여 동적 방식으로 선택적으로 증가시키거나 또는 감소시키는 것에 관한 것이다. 특히, 아래에서 설명되는 본 발명의 실시형태들은 애플리케이션 서버 (170) 에 의해 위에서 도 2a 내지 도 2e 에 도시된 코어 네트워크들 중 하나 이상을 가로질러 중재되도록 구성되는 QoS-기반의 통신 세션들에 관한 것이다.
예를 들어, QoS-기반의 App* 통신 세션들이 도 2a 에 도시된 1x EV-DO 코어 네트워크를 통해서 하나 이상의 UE들 사이에 중재되는 VoIP 세션들에 대응하는 경우에, 애플리케이션 서버 (170) 에 의해 관리되는 각각의 VoIP 세션은 QoS 가 잠재적으로 할당되는 3개의 (3) 흐름들 (즉, 콜 셋업 시그널링 흐름, 인콜 (incall) 시그널링 흐름 및 매체들 트래픽 흐름) 과 연관될 수도 있다. 1x EV-DO 코어 네트워크는 EV-DO 에 대한 QoS 셋업이 RAN (120) 에서 구현되므로, GBR QoS 를 예약가능한 파라미터로서 인식하지 않는다.
다른 예에서, QoS-기반의 App* 통신 세션들이 도 2b 또는 도 2c 에 도시된 바와 같이 UMTS-기반 W-CDMA 코어 네트워크를 통해서 하나 이상의 UE들 사이에 중재되는 VoIP 세션들에 대응하는 경우에, 각각의 VoIP 세션은 '상호작용' 트래픽 클래스 QoS 로 구성될 수 있으며, RAN (120) (즉, UTRAN) 에서 그리고 에어-인터페이스를 통해서 MAC-es/MAC-hs GBR 를 구성함으로써, 그리고, UL 에 대한 비-스케쥴링된 송신 승인을 이용하여, GBR QoS 를 수신할 수 있다. 1x EV-DO 코어 네트워크와 관련하여 상기 예와 유사하게, GBR QoS 리소스들은 예약되지 않으며, 단지 논리적 접속들만이 유지되어 W-CDMA 코어 네트워크가 GBR QoS 를 예약가능한 파라미터로서 인식되지 않기 때문에, "상호작용" 트래픽 클래스 (단지 RAN (120)) 에 대해 도 2b 내지 도 2c 의 W-CDMA 코어 네트워크에서 구성될 수 없다. 대안적으로, "대화" 트래픽 클래스가 "상호작용" 트래픽 클래스 대신 사용될 때, GBR QoS 리소스들은 UE 및 W-CDMA 코어 네트워크 양쪽에 의해 협상/수정될 수 있다. 일반적으로, VoIP 세션들은 W-CDMA 에서의 "대화 (Conversational)" 트래픽 클래스를 이용한다.
다른 예에서, QoS-기반의 App* 통신 세션들이 도 2d 에 도시된 LTE 코어 네트워크를 통해서 하나 이상의 UE들 사이에 중재되는 VoIP 세션들에 대응하는 경우에, 애플리케이션 서버 (170) 에 의해 관리되는 VoIP 세션들은 전용 애플리케이션-특정의 PDN 접속 (PDNApp * 로서 표시됨) 상에서 App* GBR QoS 베어러에 대해 "1" 의 QoS 클래스 식별자 (QCI) 또는 애플리케이션-특정의 QCI (QCIApp * 로서 표시됨) 를 이용하며, S5 접속이, 설령 UE 가 RRC-휴지 상태 (RRC-Idle state) 에 있을 때에도 유지되거나 또는 RRC 휴지-대-접속된 전이 (RRC Idle-to-Connected transition) 이후에 빨리 셋업되는 것을 필요로 한다. 따라서, 도 2a 의 1x EV-DO 코어 네트워크 및 도 2b 내지 도 2c 의 W-CDMA 코어 네트워크와는 달리, 도 2d 의 LTE 코어 네트워크는 그에 따라서, RAN (120) 에 더해서, 코어 네트워크 (140) 에서 GBR QoS 를 지원한다.
아래에서 좀더 자세히 설명되는 본 발명의 실시형태들은 (아래) 표 2 에 다음과 같이 요약된 바와 같이, 도 2a 내지 도 2b 의 코어 네트워크들 중 하나 이상 내에서의 동작을 위해 각각 구성된다:
|
실시형태
네임 |
실시형태 설명 | LTE | W-CDMA |
EV-DO
( 레거 시 HRPD ) |
eHRPD |
| #1 - 클라이언트 애플리케이션 개시되는 방향성 QoS 관리 [도 5 내지 도 6c] | UE 상의 애플리케이션은 콜의 형태 (하프 듀플렉스 또는 풀 듀플렉스) 및 콜의 활성 (플로어 개방, 플로어 활성화, 오디오 뮤트됨, 등) 에 기초하여 네트워크가 GBR QoS 흐름들을 (UL 또는 DL) 방향적으로 턴오프/수정시키도록 (증가시키거나 또는 감소시키도록) 요청한다 | 예 | 예 [대화의 트래픽 클래스에 대해] | 예 | 예 |
| #2 - 애플리케이션 서버 지원된 방향성 QoS 관리 [도 7a 내지 도 7b] | 애플리케이션 서버는 콜의 형태 (하프 듀플렉스 또는 풀 듀플렉스) 및 콜의 활성 (플로어 개방됨, 플로어 활성화됨, 오디오 뮤트됨, 등) 에 기초하여 네트워크가 그 콜에서 각각의 UE 에 대해 GBR QoS 흐름들을 방향적으로 (UL 또는 DL) 턴오프/수정시키도록 (증가시키거나 또는 감소시키도록) 요청한다 | 예 | 아니오 | 아니오 | 아니오 |
표 2 - 코어 네트워크 유형들에의 실시형태 적용가능성의 개관
도 5 는 본 발명의 일 실시형태에 따른, 클라이언트 애플리케이션 개시되는 방향성 QoS 관리 프로시저의 좀더 상세한 구현예를 예시한다. (상기) 표 2 에서 설명된 바와 같이, 클라이언트 애플리케이션 개시되는 방향성 QoS 관리 프로시저 (즉, 표 2 의 #1) 는 도 2a 의 1x EV-DO 코어 네트워크, 도 2b 내지 도 2c 의 W-CDMA 코어 네트워크 ("대화" 트래픽 클래스가 그 세션에 사용되는 경우), 도 2d 의 LTE 코어 네트워크 및/또는 도 2e 의 eHRPD 코어 네트워크에서 구현될 수 있다. 도 5 는 이들 코어 네트워크 유형들 중 임의의 유형에 일반적이며, 반면 도 6a 내지 도 6c 는 도 5 의 프로시저를 개개의 코어 네트워크 유형들에 맵핑하는 좀더 상세한 플로우차트들을 나타낸다.
도 5 를 참조하면, 주어진 UE 상의 App* 에 대한 클라이언트 애플리케이션은 App* 통신 세션 (예컨대, VoIP 세션, PTT 세션, 등) 을 개시하기로 결정한다 (500). 500 의 결정은 통신 세션을 시작하라는 주어진 UE 의 운영자에 의한 요청에 기초할 수 있으며, 이 경우, 주어진 UE 는 발신 UE 이다. 대안적으로, 500 의 결정은 일부 다른 엔터티에 의해 시작된 App* 통신 세션을 어나운스하는, 주어진 UE 에서 수신되는 콜 어나운스 메시지에 기초할 수 있으며, 이 경우, 주어진 UE 는 타겟 UE 이다. 도 5 의 실시형태에서, App* 클라이언트 애플리케이션이 주어진 UE 상에서 실행하고 있으며 App* 통신 세션들 (예컨대, VoIP 세션들, PTT 세션들, 등) 과 연관된 클라이언트-측 동작들을 처리하도록 구성된다고 가정한다.
505 에서, App* 클라이언트 애플리케이션은 개시될 App* 통신 세션이 하프 듀플렉스 또는 풀 듀플렉스인지 여부를 결정한다. 505 에서 App* 통신 세션이 하프 듀플렉스 (예컨대, PTT 콜) 라고 App* 클라이언트 애플리케이션이 결정하면, App* 클라이언트 애플리케이션은 주어진 UE 가 하프 듀플렉스 App* 세션에 대해 플로어를 현재 가지는지 (또는, 현재의 플로어홀더인지) 를 결정한다 (510). 510 에서 주어진 UE 가 플로어를 갖는다고 App* 클라이언트 애플리케이션이 결정하면, App* 클라이언트 애플리케이션은 업링크 (UL) QoS 리소스들의 임계치 레벨 (예컨대, 임계치 데이터 레이트 또는 kpbs 로 설정된 GBR) 이 하프 듀플렉스 App* 세션에 대해 주어진 UE 에 의한 업링크 매체들 송신들을 지원하기 위해 설정되는지 여부를 결정한다 (515). 주지하고 있는 바와 같이, 하프 듀플렉스 App* 세션에 대한 플로어홀더는, 플로어홀더로부터 UL 채널 상에서의 QoS 가 하프 듀플렉스 App* 세션에 대한 세션 품질을 향상시킬 수 있어, 비-플로어홀더들 또는 청취자들로서 하프 듀플렉스 App* 세션에 참가하는 타겟 UE(들) 로의 배포를 위해 UL 채널 상에서 높은 우선순위 매체들을 송신할 가능성이 있다. 도 6a 내지 도 6c 와 관련하여 아래에서 좀더 자세히 설명되는 바와 같이, 515 의 업링크 QoS 리소스 결정은, (i) 주어진 UE 가 도 2a 에서와 같은 1x EV-DO 네트워크 또는 도 2e 에서와 같은 eHRPD 네트워크에 의해 서빙되면, UL 매체들 트래픽 흐름에 대한 QoS 가 셋업되는지 여부를 결정하는 것, (ii) 주어진 UE 가 도 2b 내지 도 2c 에서와 같은 W-CDMA 네트워크 또는 도 2d 에서의 LTE 네트워크에 의해 서빙되면, UL 매체들 베어러가 하프 듀플렉스 세션을 지원하기 위해 적어도 임계치 GBR 로 구성되는지 여부를 결정하는 것을 포함할 수 있다.
515 에서 임계치 UL QoS 리소스들이 하프 듀플렉스 App* 세션에 대해 아직 셋업되지 않았다고 주어진 UE 상의 App* 클라이언트 애플리케이션이 결정하면, 520 에서, 주어진 UE 는 그 UL QoS 리소스들을 활성화시키고 및/또는 증가시키도록 요청한다. 예를 들어, 주어진 UE 가 도 2a 에서와 같은 1x EV-DO 네트워크에 의해 서빙되면, 520 에서, 주어진 UE 는 그 UL 매체들 트래픽 흐름에 대한 QoS 을 활성화시키도록 요청할 수 있다. 다른 예에서, 주어진 UE 가 도 2b 내지 도 2c 에서와 같은 W-CDMA 네트워크 또는 도 2d 에서의 LTE 네트워크에 의해 서빙되면, 520 에서, 주어진 UE 는 그의 UL 매체들 베어러 상에서의 그의 현재의 GBR 을 더 높은 GBR (예컨대, XApp * kpbs, 여기서, XApp * kpbs 는 App* 통신 세션들에 대한 애플리케이션-특정의 동적 데이터 레이트에 대응한다) 로 수정하도록 요청할 수 있다.
또, 510 에서, 주어진 UE 가 하프 듀플렉스 App* 세션에 대한 플로어를 갖는 것으로 결정되면, 주어진 UE 가 다운링크 (DL) 매체들에 대한 QoS 를 필요로 하지 않을 수도 있음을 명백히 알 수 있을 것이다. 따라서, 515-520 에서 (필요한 경우) UL 채널에 대한 QoS 를 선택적으로 셋업하거나 또는 증가시키는 것에 더해서, 525-530 에서, 주어진 UE 는 또한 App* 베어러에 대해 (필요한 경우) DL 채널에 대한 기존 QoS 리소스들을 선택적으로 해제 (tear down) 하거나 감소시킬 것이다. 따라서, App* 클라이언트 애플리케이션은, 하프 듀플렉스 App* 세션에 대해 주어진 UE 에서 DL 매체들 수신을 지원하기 위해 DL QoS 리소스들의 임계치 레벨이 설정되는지 여부를 결정한다 (525). 도 6a 내지 도 6c 와 관련하여 아래에서 좀더 자세히 설명되는 바와 같이, 525 의 DL QoS 리소스 결정은, (i) 주어진 UE 가 도 2a 에서와 같은 1x EV-DO 네트워크 또는 도 2e 에서와 같은 eHRPD 네트워크에 의해 서빙되면, DL 매체들 트래픽 흐름에 대한 QoS 가 셋업되는지 여부를 결정하는 것, (ii) 주어진 UE 가 도 2b 내지 도 2c 에서와 같은 W-CDMA 네트워크 또는 도 2d 에서의 LTE 네트워크에 의해 서빙되면, DL App* 매체들 베어러가 적어도 임계치 GBR 로 구성되는지 여부를 결정하는 것을 포함할 수 있다.
525 에서, 임계치 DL QoS 리소스들이 하프 듀플렉스 App* 세션에 대해 아직 셋업되지 않았다고 주어진 UE 상의 App* 클라이언트 애플리케이션이 결정하면, 530 에서, 주어진 UE 상의 App* 클라이언트 애플리케이션은 그 DL QoS 리소스들을 비활성화시키고 및/또는 감소시키도록 요청한다. 예를 들어, 주어진 UE 가 도 2a 에서와 같은 1x EV-DO 네트워크 또는 도 2e 에서와 같은 eHRPD 네트워크에 의해 서빙되면, 530 에서, 주어진 UE 는 DL 매체들 트래픽 흐름에 대한 그 QoS 를 비활성화시키거나 또는 턴오프시키도록 요청할 수 있다. 다른 예에서, 주어진 UE 가 도 2b 내지 도 2c 에서와 같은 W-CDMA 네트워크 또는 도 2d 에서의 LTE 네트워크에 의해 서빙되면, 530 에서, 주어진 UE 상의 App* 클라이언트 애플리케이션은 그의 DL 매체들 베어러 상에서의 그의 현재의 GBR 을 더 낮은 GBR 로 수정하도록 요청할 수 있다.
여전히 도 5 를 참조하고 510 의 하프 듀플렉스 플로어홀더 결정으로 되돌아가서, 510 에서, 주어진 UE 가 플로어를 갖지 않는다고 App* 클라이언트 애플리케이션이 결정하면, App* 클라이언트 애플리케이션은 다른 세션 참가자가 플로어를 유지하는지 여부 (즉, 어떤 엔터티로부터의 매체들이 하프 듀플렉스 App* 세션에 대해 DL 채널을 통해 수신되고 있는지 여부) 를 결정한다 (535). 주지하고 있는 바와 같이, 하프 듀플렉스 App* 세션에 대한 비-플로어홀더들 (또는, 타겟 UE들) 이 DL 상에서 높은 우선순위 매체들을 수신할 가능성이 있으며, 그 결과 비-플로어홀더들 또는 타겟 UE(들) 에 대한 DL 채널 상에서의 QoS 가 하프 듀플렉스 App* 세션에 대한 세션 품질을 향상시킬 수 있다. 따라서, 535에서, 다른 엔터티가 플로어를 유지한다고 (즉, 매체들이 주어진 UE 에서 하프 듀플렉스 App* 세션에 대해 수신되고 있다고) App* 클라이언트 애플리케이션이 결정하면, App* 클라이언트 애플리케이션은 (525 와 유사하게) 주어진 UE 에서 하프 듀플렉스 세션에 대해 DL 매체들 수신을 지원하기 위해 DL QoS 리소스들의 임계치 레벨이 설정되는지 여부를 결정한다 (540).
540 에서, 임계치 DL QoS 리소스들이 하프 듀플렉스 App* 세션에 대해 아직 셋업되지 않았다고 주어진 UE 상의 App* 클라이언트 애플리케이션이 결정하면, 545 에서, 주어진 UE 상의 App* 클라이언트 애플리케이션은 그 DL QoS 리소스들을 활성화시키고 및/또는 증가시키도록 요청한다. 예를 들어, 주어진 UE 가 도 2a 에서와 같은 1x EV-DO 네트워크 또는 도 2e 에서와 같은 eHRPD 네트워크에 의해 서빙되면, 545 에서, 주어진 UE 는 DL 매체들 트래픽 흐름에 대한 그 QoS 를 활성화시키도록 요청할 수 있다. 다른 예에서, 주어진 UE 가 도 2b 내지 도 2c 에서와 같은 W-CDMA 네트워크 또는 도 2d 에서의 LTE 네트워크에 의해 서빙되면, 545 에서, 주어진 UE 상의 App* 클라이언트 애플리케이션은 그의 DL 매체들 베어러 상에서의 그의 현재의 GBR 을 더 높은 GBR (예컨대, XApp * kpbs) 로 수정하도록 요청할 수 있다.
또, 510 에서, 주어진 UE 가 하프 듀플렉스 App* 세션에 대해 플로어를 갖지 않는 것으로 결정되면, 주어진 UE 가 UL 매체들에 대해 QoS 를 필요로 하지 않을 수도 있음을 명백히 알 수 있을 것이다. 따라서, 540-545 에서, (필요한 경우) DL 채널에 대해 QoS 를 선택적으로 셋업하는 것에 더해서, 550-555 에서, 주어진 UE 는 또한 (필요한 경우) UL 채널에 대한 기존 QoS 리소스들을 선택적으로 해제하거나 또는 감소시킬 것이다. 따라서, App* 클라이언트 애플리케이션은 (520 과 유사하게) 주어진 UE 에서 하프 듀플렉스 세션에 대해 UL 매체들 수신을 지원하기 위해 UL QoS 리소스들에 대한 임계치 레벨이 설정되는지 여부를 결정한다 (550).
550 에서, 임계치 UL QoS 리소스들이 하프 듀플렉스 App* 세션에 대해 이미 셋업되어 있다고 주어진 UE 상의 App* 클라이언트 애플리케이션이 결정하면, 555 에서, 주어진 UE 는 그 UL QoS 리소스들을 비활성화시키고 및/또는 감소시키도록 요청한다. 예를 들어, 주어진 UE 가 도 2a 에서와 같은 1x EV-DO 네트워크 또는 도 2e 에서와 같은 eHRPD 네트워크에 의해 서빙되면, 555 에서, 주어진 UE 상의 App* 클라이언트 애플리케이션은 그 UL 매체들 트래픽 흐름에 대한 QoS 를 비활성화시키거나 또는 턴오프시키도록 요청할 수 있다. 다른 예에서, 주어진 UE 가 도 2b 내지 도 2c 에서와 같은 W-CDMA 네트워크 또는 도 2d 에서의 LTE 네트워크에 의해 서빙되면, 555 에서, 주어진 UE 상의 App* 클라이언트 애플리케이션은 그의 UL 매체들 베어러 상에서의 그의 현재의 GBR 을 더 낮은 GBR (예컨대, 1 kpbs, 또는 일부 다른 공칭 데이터 레이트) 로 수정하도록 요청할 수 있다.
여전히 도 5 를 참조하고 535 의 결정으로 되돌아가서, 510 에서 App* 클라이언트 애플리케이션이 주어진 UE 자체가 플로어를 유지하지 않는다고 App* 클라이언트 애플리케이션이 결정한 후, 다른 플로어홀더가 존재하는지 여부를 결정하고, 535 에서, 어떤 UE 도 플로어를 유지하지 않는다고 App* 클라이언트 애플리케이션이 결정하면, App* 클라이언트 애플리케이션은 하프 듀플렉스 App* 세션에 대해 DL 및 UL 양쪽의 QoS 리소스들을 (적어도, 세션 참가자들 중 하나가 플로어를 부여받을 때까지) 감소시키거나 또는 비활성화하도록 결정한다 (560). 따라서, 560 이후, 프로세스는 525-530 및 550-555 양쪽으로 진행하며, 여기서, DL 및 UL QoS 리소스들이 (필요한 경우) 감소되며 및/또는 비활성화된다.
여전히 도 5 를 참조하고 505 의 듀플렉스 결정으로 되돌아가서, 통신 세션이 하프 듀플렉스 대신 풀 듀플렉스 (예컨대, VoIP 콜) 라고 App* 클라이언트 애플리케이션이 결정하면, App* 클라이언트 애플리케이션은 오디오가 풀 듀플렉스 App* 세션에 대해 뮤트되는지 여부를 결정한다 (565). 주지하고 있는 바와 같이, 오디오가 뮤트되면, 주어진 UE 의 운영자는 풀 듀플렉스 App* 세션에서 다른 UE(들) 을 청취하고 있지만 그의/그녀의 자신의 오디오가 다른 UE(들) 로 전달되는 것을 실제로 원하지 않는다. 565 에서, 풀 듀플렉스 App* 세션이 뮤트되어 있지 않다고 App* 클라이언트 애플리케이션이 결정하면, 풀 듀플렉스 App* 세션에 대한 UL 및 DL QoS 리소스들 양쪽이 (필요한 경우) 활성화되거나 또는 증가된다 (570). 예를 들어, 570 은 일 예에서, 515-520 및 550-555 의 실행에 대응할 수 있다. 그렇지 않고, 565 에서, 풀 듀플렉스 App* 세션이 뮤트되어 있다고 App* 클라이언트 애플리케이션이 결정하면, 프로세스는 540-555 로 진행하며, 여기서, DL QoS 리소스들이 (필요한 경우) 증가되거나 또는 활성화되고, UL QoS 리소스들이 (필요한 경우) 감소되거나 또는 비활성화된다.
도 6a 는 본 발명의 일 실시형태에 따른, 도 2a 에서와 같은 1x EV-DO 네트워크 (레거시 HRPD) 또는 도 2e 에서와 같은 eHRPD 네트워크에 의해 서빙되고 있는 동안 하프 듀플렉스 App* PTT 세션에 참가하는 주어진 UE 에 대한 도 5 의 프로세스의 예시적인 구현예를 예시한다. 도 6a 를 참조하면, 주어진 UE 가 휴지 상태에 있는 동안, App* 클라이언트 애플리케이션은 (예컨대, PTT 버튼 푸시에 응답하여) App* PTT 콜을 시작하기로 결정하며 (600A), App*클라이언트 애플리케이션은 (예컨대, 도 5 에서의 500-515 와 유사하게) 주어진 UE 가 플로어를 갖는다고 결정한다 (605A). 주어진 UE 가 App* PTT 콜에 대해 그의 UL 매체들 흐름에 대한 QoS 셋업을 아직 행하지 않았다고 가정하면, 주어진 UE 상의 App* 클라이언트 애플리케이션은 App* PTT 콜에 대한 DL 매체들 흐름이 아닌, 그의 UL 매체들 흐름에 대한 QoS 활성화를 요청한다. 이는 도 6a 에 도시되는데, 여기서 주어진 UE 가 UL 매체들 QoS 흐름을 표시하는 (그리고 DL 매체들 QoS 흐름을 표시하지 않는) ReservationOnRequest 메시지를 송신한다 (615A). 따라서, RAN (120) 은 (예컨대, 도 5 의 515-530 와 유사하게) DL 매체들 흐름에 대한 DL QoS 예약을 일시중지된 (suspended) 상태로 두면서, (1x EV-DO 에 정통한 당업자에 의해 용이하게 이해될, 620A 내지 640A 사이의 시그널링으로 도시된) UL 매체들 흐름에 대한 UL QoS 예약을 셋업한다. 도 6a 에 명시적으로 도시되지는 않지만, 주어진 UE 상의 App* 클라이언트 애플리케이션은 640A 이후에 매체들을 플로어홀더로서 송신하기 시작할 수 있다.
도 6a 를 참조하면, 주어진 UE 상의 App* 클라이언트 애플리케이션은 결국 플로어를 해제하고 (645A), App* 클라이언트 애플리케이션은 (도 5 의 510 및 535 와 유사하게) 다른 UE 가 App* PTT 세션에 대해 플로어를 갖는다고 결정한다 (650A). 따라서, 주어진 UE 는 DL 매체들 흐름에 대한 DL QoS 예약을 턴온시키고 (655A-660A), 도 5 의 540-555 와 유사하게, 주어진 UE 는 UL 매체들 흐름에 대한 UL QoS 예약을 해제한다 (665A-670A).
도 6a 를 참조하면, 다른 UE 는 플로어를 결국 해제하고 (675A), App* 클라이언트 애플리케이션은 (도 5 의 535 및 560 와 유사하게) 어떤 UE 도 App* PTT 세션에 대해 플로어를 갖지 않는다고 결정한다 (680A). 따라서, 도 5 의 525-530 및 550-555 와 유사하게, 주어진 UE 상의 App* 클라이언트 애플리케이션은 DL 매체들 흐름에 대한 DL QoS 예약 및 UL 매체들 흐름에 대한 UL QoS 예약 양자를 해제한다 (680A-690A).
도 6a 는 주어진 UE 가 App* PTT 콜에 대한 발신자인 예에 관한 것이지만, 도 6a 는 주어진 UE 가 App* PTT 콜에 대한 콜 타겟인 시나리오를 그 대신에 수용하도록 수정될 수 있음을 명백히 알 수 있을 것이다. 도 6a 의 콜 타겟 구현예에서, 콜 타겟 UE 상의 App* 클라이언트 애플리케이션은 (600A 에서와 같은 PTT 버튼 푸시 대신) 콜 어나운스먼트 메시지를 통해서 App* PTT 콜을 인식하게 되며, 콜 타겟 UE 는 App* PTT 콜을 (도 6a 에서의 플로어홀더 대신) 비-플로어홀더로서 시작할 것이다. 이들 차이들 이외에, App* 매체들 QoS 흐름에 대한 UL 및 DL QoS 는 도 6a 에서와 유사한 방법으로 콜 타겟 UE 에 대해 관리될 수 있다. 또한, 도 6a 에 명시적으로 나타내지는 않지만, 도 6a 는 도 6b 에서의 하프 듀플렉스 세션 예 대신, 풀 듀플렉스 예 (예컨대, 도 5 의 565, 570, 등) 와 같은, 도 5 의 추가적인 사용 사례들을 포괄하기 위해 확장될 수 있다. 또, 도 6a 는 600A 에서 주어진 UE 가 휴지일 때 (즉, 어떤 트래픽 채널 (TCH) 도 없을 때) App* PTT 콜이 개시되는 것으로 설명되지만, 도 6a 는 주어진 UE 가 이미 TCH 를 할당받아 있는 동안 (또는, 주어진 UE 로 사전-확립된 TCH 를 통해서 어나운스되는 동안, 타겟 UE 구현예) App* PTT 콜이 주어진 UE 에서 시작되도록 수정될 수 있음을 명백히 알 수 있을 것이다.
도 6b 는 본 발명의 일 실시형태에 따른, 도 2b 또는 도 2c 에서와 같은 W-CDMA 네트워크에 의해 서빙되는 동안 하프 듀플렉스 App* PTT 세션에 참가하는 주어진 UE 에 대한, 도 5 의 프로세스의 예시적인 구현예를 예시한다. 도 6b 를 참조하면, 주어진 UE 는 CELL_PCH 또는 URA_PCH 상태에서 동작하고 있으며 (600B), App* 클라이언트 애플리케이션은 (예컨대, 다른 UE 에서의 PTT 버튼 푸시에 응답하여) 일부 다른 UE 에 의해 시작되는 App* PTT 콜에 관련한 페이지를 수신하는데 (605B), 이는 CELL_DCH 상태로 전이하고 (615B), PTT 어나운스 메시지 (미도시) 를 수신하여 App* PTT 세션에 대한 RAB들을 셋업하기 위해 (620B), 주어진 UE 로 하여금 RAN (120) 에의 셀 업데이트 프로시저들을 수행하도록 (610B) 프롬프트한다. 특히, 620B 에서, RAN (120) 은 App* PTT 세션을 지원할 매체들 RAB 에 대해 UL 및 DL 양쪽 상에서 적어도 임계치 GBR (예컨대, XApp * kpbs) 를 할당한다.
도 6b 를 참조하면, (도 5 의 510 및 535 와 유사하게) 다른 UE 가 App* PTT 세션에 대한 플로어를 갖는다고 App* 클라이언트 애플리케이션이 결정한다고 (625B) 가정한다. 따라서, 620B 에서 주어진 UE 가 임계치 GBR 을 이미 할당받았기 때문에, App* 클라이언트 애플리케이션은 도 5 의 540-555 와 유사하게, DL 매체들 베어러에 할당된 GBR 을 XApp * kpbs 로 유지하지만 UL 매체들 베어러에 할당된 GBR 을 (예컨대, 1 kpbs 또는 일부 다른 공칭 레벨까지) 감소시키기로 결정한다. UL 매체들 베어러에 대한 GBR 감소가 도 6b 에 630B 내지 670B 사이의 시그널링에서 도시되며, 이 시그널링은 UMTS 및/또는 W-CDMA 에 정통한 당업자에 의해 용이하게 이해될 것이다.
도 6b 는 주어진 UE 가 App* PTT 콜에 대한 콜 타겟 UE 인 예에 관한 것이지만, 도 6b 는 주어진 UE 가 App* PTT 콜의 콜 발신자인 시나리오를 그 대신에 수용하도록 수정될 수 있음을 명백히 알 수 있을 것이다. 도 6b 의 콜 발신자 구현예에서, 콜 발신자 UE 상의 App* 클라이언트 애플리케이션은 (605B 에서와 같은 페이지 / 어나운스 프로시저 대신) PTT 버튼 푸시를 통해서 App* PTT 콜을 인식하게 될 수 있으며, 콜 발신자 UE 는 App* PTT 콜을 (도 6b 에서와 같은 비-플로어홀더 대신) 플로어홀더로서 시작할 것이다. 이들 차이들 이외에, App* 매체들 QoS 흐름에 대한 UL 및 DL QoS 는 콜 타겟 UE 에 대해 도 6b 에서와 유사한 방법으로 관리될 수 있다. 또한, 도 6b 에 명시적으로 도시되지는 않지만, 도 6b 는 도 6b 에서의 하프 듀플렉스 세션 예 대신 풀 듀플렉스 예 (예컨대, 도 5 의 565, 570, 등) 와 같은, 도 5 의 추가적인 사용 사례들을 포괄하도록 확장될 수 있다. 또, 도 6b 는 605B 에서, 주어진 UE 가 URA_PCH / CELL_PCH 상태에 있는 동안 수신되는 페이지에 기초하여 App* PTT 콜이 시작되는 것으로 설명되지만, 도 6b 는 주어진 UE 가 아직 CELL_DCH 상태에 있는 동안 App* PTT 세션에 대한 App* PTT 콜 콜 어나운스먼트가 도달하도록 (또는, CELL_DCH 상태에 있는 동안 App* 에 대한 PTT 버튼 푸시가 주어진 UE 에서 검출되도록, 발신 UE 구현예에 대해) 수정될 수도 있음을 명백히 알 수 있을 것이다.
도 6c 는 본 발명의 일 실시형태에 따른, 도 2d 에서의 LTE 네트워크에 의해 서빙되는 동안 하프 듀플렉스 App* PTT 세션을 시작하는 주어진 UE 에 대한, 도 5 의 프로세스의 예시적인 구현예를 예시한다. 도 6c 를 참조하면, 주어진 UE 는 무선 리소스 접속된 (RRC) 휴지 모드에서 동작하고 있으며 (600C), App* 클라이언트 애플리케이션은 (예컨대, 주어진 UE 상에서의 PTT 버튼 푸시에 응답하여) 하프 듀플렉스 App*PTT 세션을 개시하기로 결정한다 (605C). 주어진 UE 는 그후 RCC 접속된 상태로 전이하고 (615C) 셋업 하프 듀플렉스 App*PTT 세션의 매체들에 대한 비-GBR EPS 베어러들 및 전용 GBR EPS 베어러를 셋업하기 위해 (620C), RAN (120) (즉, eNodeB (205D) 와 같은, 주어진 UE 를 서빙하는 eNodeB) 과의 RCC 접속 셋업 및 서비스 요청 프로시저들을 수행한다 (610C). 특히, 620C 에서, eNodeB (205D) 는 MME (215B) 로부터 수신된 QoS 에 기초하여 App* PTT 세션을 지원할 App* GBR 매체들 베어러에 대해 적어도 UL 및 DL 양쪽 상에서 임계치 GBR (예컨대, XApp* kpbs) 을 할당한다.
도 6c 를 참조하면, (예컨대, 도 5 에서의 500-515 와 유사하게) 주어진 UE 가 플로어를 가진 하프 듀플렉스 App* PTT 세션을 시작할 것이라고 App* 클라이언트 애플리케이션이 결정한다고 (625C) 가정한다. 주어진 UE 가 그의 UL 매체들 베어러에 대한 QoS 셋업 (예컨대, 620C 에서 eNodeB (205D) 에 의해 UL 매체들 베어러에 할당된 GBR 의 XApp * kpbs) 을 이미 갖고 있기 때문에, 주어진 UE 상의 App* 클라이언트 애플리케이션은 XApp * kpbs 로부터 GBR 임계치 (예컨대, 1 kpbs 와 같은, 공칭 kpbs 레벨) 아래의 kpbs 레벨까지의 DL 매체들 베어러에 대한 QoS 감소를 요청한다. DL 매체들 베어러에 대한 GBR 감소가 도 6c 에 630C 와 665C 사이에서 도시되며, 이 시그널링은 LTE 에 정통한 당업자에 의해 용이하게 이해될 것이다.
도 6c 는 주어진 UE 가 App* PTT 콜에 대한 발신자인 예에 관한 것이지만, 도 6a 는 주어진 UE 가 App* PTT 콜에 대한 콜 타겟인 시나리오를 그 대신에 수용하도록 수정될 수 있음을 명백히 알 수 있을 것이다. 도 6c 의 콜 타겟 구현예에서, 콜 타겟 UE 상의 App* 클라이언트 애플리케이션은 (605C 에서와 같은 PTT 버튼 푸시 대신) 콜 어나운스먼트 메시지를 통해서 App* PTT 콜을 인식하게 되며, 콜 타겟 UE 는 App* PTT 콜을 (도 6c 에서와 같은 플로어홀더 대신) 비-플로어홀더로서 시작할 것이다. 이들 차이들 이외에, App* 매체들 QoS 흐름에 대한 UL 및 DL QoS 는 콜 타겟 UE 에 대해 도 6c 에서와 유사한 방법으로 관리될 수 있다. 또한, 도 6c 에 명시적으로 도시되지는 않지만, 도 6c 는 도 6c 에서의 하프 듀플렉스 세션 예 대신, 풀 듀플렉스 예 (예컨대, 도 5 의 565, 570, 등) 와 같은 도 5 의 추가적인 사용 사례들을 포괄하도록 확장될 수 있다. 또, 도 6c 는 주어진 UE 가 RCC-휴지 상태에 있을 때 605C 에서 App* PTT 콜이 시작되는 것으로 설명되지만, 도 6c 는 RRC-접속된 상태에 있는 동안 App* PTT 콜이 주어진 UE 에서 시작되도록 (또는, RRC-접속된 상태에 있는 동안 주어진 UE 로 어나운스되도록, 타겟 UE 구현예에 대해) 수정될 수 있음을 명백히 알 수 있을 것이다.
도 5 내지 도 6c 는 App* 통신 세션의 UL 및 DL 채널들 상에서의 선택적 QoS 제어를 위한 UE-측 또는 클라이언트 애플리케이션-기반의 프로시저에 대해 설명되지만, 도 7a 내지 도 7b 는 App* 통신 세션에 참가하는 UE들 대신, 애플리케이션 서버 (170) (예컨대, App* 통신 세션을 중재하도록 구성된 서버) 에서 구현되는 유사한 선택적 QoS 제어 프로시저에 관한 것이다. (상기) 표 2 에서 설명된 바와 같이, 애플리케이션 서버 지원 방향성 QoS 관리 프로시저 (즉, 표 2 의 #2) 는 도 2d 의 LTE 코어 네트워크에서 구현될 수 있으나, 도 2a 의 1x EV-DO 코어 네트워크, 또는 도 2b 내지 도 2c 의 W-CDMA 코어 네트워크, 또는 도 2e 의 eHRPD 네트워크에서는 표준-규격 구현이 불가능할 수도 있다.
도 7a 의 설명을 요약하기 위해, 도 7a 의 700 내지 770 은 아래에서 언급되는 것을 제외하고는, 도 5 의 500 내지 570 과 각각 유사하다. 도 5 는 App* 통신 세션에 참가하는 주어진 UE에서 전체적으로 구현되며, 한편 도 7a 는 App* 통신 세션을 중재하도록 구성된 애플리케이션 서버 (170) 에서 구현된다. 도 5 는 하나의 특정의 UE 에서 App* 클라이언트 애플리케이션에 의해 실행되는 프로시저를 나타내며, 한편 도 7a 는 (비록, 적어도 일 실시형태에서, 애플리케이션 서버 (170) 가 참가하는 UE들의 각각에 대해 도 7a 의 프로세스를 수행할 필요는 없지만) 통신 세션에 참가하는 각각의 UE 에 대해 애플리케이션 서버 (170) 에서 실행될 수 있는 프로시저를 나타낸다. 도 5 에서 주어진 UE 상의 App* 클라이언트 애플리케이션은 도 5 의 500 에서 사용자 요청 또는 주어진 UE 에서의 콜 어나운스 메시지의 수신에 기초하여 App* 통신 세션을 개시하기로 결정할 수도 있지만, 도 7a 의 700 에서 애플리케이션 서버 (170) 는 발신 UE 로부터의 콜 요청 메시지 및/또는 어나운스된 App* 통신 세션에 대한 수용을 나타내는 타겟 UE(들) 로부터의 콜 수용 메시지의 수신에 기초하여 App* 통신 세션을 개시하기로 결정할 수도 있다. 또, 풀 듀플렉스 App* 세션에서의 어떤 UE들이 그들의 세션들을 뮤트시킬 수도 있고 나머지들은 뮤트시키지 않을 수도 있음을, 그리고 어떤 UE들은 하프 듀플렉스 App* 세션에 대한 플로어홀더들일 수도 있고 다른 UE들은 비-플로어홀더들일 수도 있음을 명백히 알 수 있을 것이다. 따라서, 도 7a 에 도시된 여러 결정 블록들은 애플리케이션 서버 (170) 에 의해 평가되는 UE들의 각각에 대해 취해지는 상이한 절차적 경로들을 초래할 수도 있다. 마지막으로, 도 7a 프로시저가 LTE 에 관련되기 때문에, 도 7a 에 도시된 여러 QoS 평가들 및 변경들은 LTE 특정의 코어 네트워크 엘리먼트들에 맵핑할 수도 있다. 예를 들어, App* GBR QoS 베어러에 대한 UL QoS 를 증가시키라는 720 에서의 요청은 App* GBR QoS 베어러 상의 UL GBR 을 XApp * kpbs 까지 상승시키라는, 애플리케이션 서버 (170) 로부터 PCRF (240D) 또는 P-GW (235D) 로 발해지는 요청에 대응할 수도 있으며, App* GBR QoS 베어러 상의 DL QoS 를 감소시키라는 730 에서의 요청은 App* GBR QoS 베어러 상의 DL GBR 을 GBR 임계치 (예컨대, 1 kpbs 또는 일부 다른 공칭 데이터 레이트) 아래의 kpbs 등까지 감소시키라는, 애플리케이션 서버 (170) 로부터 PCRF (240D) 또는 P-GW (235D) 로 발해지는 요청에 대응할 수도 있다. 이들 차이들을 제외하고, 도 7a 의 나머지 동작은 도 5 와 유사하며, 도 7a 의 LTE 구현예는 주어진 UE 로부터 애플리케이션 서버 (170) 로 이동되는 (그리고 잠재적으로는 더 많은 UE들에 대해 수행되는) 어떤 동작들을 제외하고는, 도 6c 와 유사할 수 있다. 도 7b 의 700B 내지 770B 는 도 7a 의 700 내지 770 의 더욱 더 상세한 구현예를 각각 예시하며, 이에 따라서 LTE-특정의 컴포넌트들 및 메시지들이 참조 표시된다.
도 7c 는 본 발명의 일 실시형태에 따른, 하프 듀플렉스 App* PTT 세션에 참가하는 주어진 UE (콜 발신자 또는 콜 타겟) 에 대한 LTE 네트워크 내에서의 도 7b 의 예시적인 구현예를 예시한다. 도 7c 를 참조하면, 애플리케이션 서버 (170) 는 (예컨대, 도 7b 의 700B 및 705B 에서와 같이) 주어진 UE 에 대한 하프 듀플렉스 App* PTT 콜을 셋업하기로 결정하고 (700C), 및 애플리케이션 서버 (170) 는 (예컨대, 도 7b 의 710B 내지 730B 에서와 같이) 주어진 UE 가 플로어를 가짐에 따라서 UL App* GBR 베어러에 대한 최대 비트 레이트 (MBR) 가 플로어를 갖는다고 결정하고, DL GBR 를 낮은 kpbs, 예컨대 1 kpbs 와 동일하게 설정한다 (705C). 이러한 가정들을 고려하여, 710C 내지 760C 의 시그널링은 UL 및 DL App* GBR 베어러 설정들이 구현될 수 있는 방법의 LTE-구체적인 예를 나타낸다. 715C 에서, 예를 들어, PCRF (240D) 는 애플리케이션 서버 (170) 에 의해 제공된 MBS 를, 본원에서 XApp * 로서 표시되는, 지정된 MBS 를 달성하는데 적합한 GBR 값에 맵핑하는 로직을 실행하는 LTE 코어 네트워크 컴포넌트인 것으로 도시된다. 또한, 725 내지 750C 사이에 도시된 시그널링은 App* GBR 베어러가 UL 및 DL 상에서 이미 셋업되어 있는 시나리오 그리고 또한 App* GBR 베어러가 아직 셋업되어 있지 않는 시나리오를 포괄한다. App* GBR 베어러가 이미 셋업되어 있으면, UL App* GBR 베어러는 XApp * kpbs 에 머무르는 반면, DL App* GBR 베어러는 베어러 요청 업데이트 메시지 (Update Bearer Request message) 를 통해서 1 kpbs (또는, 일부 다른 공칭 kpbs) 까지 감소된다 (725C). App* GBR 베어러가 아직 셋업되어 있지 않으면, then UL App* GBR 베어러는 XApp * kpbs 에 대해 셋업되는 반면, DL App* GBR 베어러는 베어러 요청 생성 메시지 (Create Bearer Request message) 를 통해서 공칭 kpbs 로 설정된다 (725C). 이와 유사하게, App* GBR 베어러가 아직 셋업되어 있지 않으면 730C 에서 베어러 셋업 요청 메시지 (Bearer Setup Request message) 가 사용되며, App* GBR 베어러가 이미 셋업되어 있으면 730C 에서 베어러 수정 요청 메시지 (Bearer Modify Request message) 가 사용된다. 이와 유사하게, App* GBR 베어러가 아직 셋업되어 있지 않으면 750C 에서 베어러 응답 생성 메시지 (Create Bearer Response message) 가 사용되며, App* GBR 베어러가 이미 셋업되어 있으면 750C 에서 베어러 응답 업데이트 메시지 (Update Bearer Response message) 가 사용된다. 도 7c 에 도시된 나머지 시그널링은 App* GBR 베어러의 시작 상태에 독립적이며, LTE 에 정통한 당업자에 의해 쉽게 이해될 것이다. 도 7c 는 하프 듀플렉스 PTT 세션에 고유하지만, 도 7c 가 PTT 이외의 풀 듀플렉스 세션들 또는 하프 듀플렉스 세션들을 수용하도록 수정될 수 있음을 용이하게 알 수 있을 것이다.
도 8a 는 본 발명의 일 실시형태에 따른, 코어 네트워크 개시되는 방향성 QoS 관리 프로시저의 좀더 상세한 구현예를 예시한다. (상기) 표 2 에서 설명된 바와 같이, 코어 네트워크 개시되는 방향성 QoS 관리 프로시저 (즉, 표 2 의 #3) 는 도 2b 내지 도 2c 의 W-CDMA 코어 네트워크 ("대화" 트래픽 클래스가 세션에 대해 사용되면) 및/또는 도 2d 의 LTE 코어 네트워크에서 구현될 수 있지만, 도 2a 의 1x EV-DO 코어 네트워크 또는 도 2e 의 eHRPD 네트워크에서 표준-규격 구현이 불가능할 수도 있다. 예를 들어, W-CDMA 또는 UMTS 구현예에서, GGSN (225B) 또는 SGSN (220B) 은 도 8a 의 프로세스를 수행할 수도 있으며, LTE 구현예에서, P-GW (235D) 또는 S-GW (230D) 는 도 8a 의 프로세스를 수행할 수도 있다.
도 8a 를 참조하면, App* 통신 세션 (예컨대, 하프 듀플렉스 세션, 풀 듀플렉스 세션, 등) 에 대한 GBR 매체들 베어러의 셋업의 검출에 응답하여, 코어 네트워크 (140) 는 App* GBR 매체들 베어러 상의 UL 및 DL 트래픽을 모니터링하는 데이터 비활성 타이머들을 시작한다 (800). 어느 경우에나, 아래에서 설명되는 바와 같이, 일단 App* GBR 매체들 베어러가 App* 세션에 대해 활성화되면 데이터 비활성 타이머들이 실행하기 시작한다.
805 에서, 코어 네트워크 (140) 는 UL 또는 DL 트래픽이 통신 세션에 대해 App* GBR 매체들 베어러 상에서 검출되는지 여부를 결정한다. 특히, 코어 네트워크 (140) 는 App* 통신 세션에 대한 액세스 지점 네임 (APN) (즉, App*APN) 과 연관된 App* 트래픽이 UL 또는 DL 방향에서 검출되는지 여부를 결정한다 (805). 805 에서, UL 또는 DL 트래픽이 코어 네트워크 (140) 에 의해 검출되면, 트래픽이 검출된 각각의 방향 (UL 및/또는 DL) 에 대한 트래픽 비활성 타이머가 리셋된다 (810). 815 에서, 트래픽 비활성 타이머들이 여전히 실행하고 있는 (즉, 아직 만료되지 않은) 각각의 방향 (UL 및/또는 DL) 에 대해, 코어 네트워크 (140) 는 (예컨대, 도 5 의 515, 525, 540 및 550 과 유사하게) 임계치 GBR 이 App* GBR 매체들 베어러에 대해 개개의 방향에서 이미 셋업되어 있는지 여부를 결정한다. 그렇지 않으면, 코어 네트워크 (140) 는 임계치 GBR 을 아직 가지고 있지 않고 연관된 트래픽 비활성 타이머가 여전히 실행중에 있는 각각의 방향 (UL 또는 DL) 에서 GBR 을 (예컨대, XApp * kpbs 까지) 증가시킨다 (820). 주지하고 있는 바와 같이, UE 는 도 8c 에서 855C-890C 사이에 및/또는 도 8d 에서 850D-865D 사이에 도시된 바와 같이, 종단간 통신을 통해서, 820 의 QoS 조정 (또는, GBR 증가) 에 대해 통지받을 수 있다.
도 8a 를 참조하면, 코어 네트워크 (140) 는 UL 및 DL 트래픽 비활성 타이머들을 모니터링하여 UL 및 DL 트래픽 비활성 타이머들이 만료하는지 여부를 결정한다 (825). 825 에서 만료가 검출되면, 코어 네트워크 (140) 는 (예컨대, 도 5 의 515, 525, 540 및 550 과 유사하게) 만료가 검출되는 개개의 방향에서 App* GBR 매체들 베어러에 대해 임계치 GBR 이 이미 셋업되어 있는지 여부를 결정한다 (830). 그렇다면, 코어 네트워크 (140) 는 임계치 GBR 을 가지며 만료가 검출되는 각각의 방향 (UL 또는 DL) 에서 GBR 을 (예컨대, 1 kpbs 또는 일부 다른 공칭 레벨까지) 감소시키고 (835), 그후, 코어 네트워크 (140) 는 835 에서 감소된 방향성 채널 상에서 새로운 트래픽이 도달하는지 여부를 모니터링하고 (805), 코어 네트워크 (140) 는 또한 (있다면) 835에서 감소되지 않은 다른 방향성 채널에 대해 만료가 발생하는지 여부를 계속해서 모니터링할 수 있다 (825). 주지하고 있는 바와 같이, UE 는 도 8c 에서 855C-890C 사이에 및/또는 도 8d 에서 850D-865D 사이에 도시된 바와 같이, 종단간 통신을 통해서 830 의 QoS 조정 (또는, GBR 감소) 에 대해서 통지받을 수 있다. 도 8b 의 800B 내지 835B 는 도 8a 의 800 내지 835 의 더욱 더 상세한 구현예를 각각 예시하며, 이에 따라서 LTE-특정의 및 W-CDMA-특정의 컴포넌트들 및 메시지들이 좀더 명시적으로 참조 표시된다.
도 8c 는 본 발명의 일 실시형태에 따른, 일부 다른 UE 에 의해 시작되는 하프 듀플렉스 App* PTT 세션의 콜 타겟인 주어진 UE 에 대한 W-CDMA 네트워크 내에서의 도 8b 의 예시적인 구현예를 예시한다. 도 8c 를 참조하면, 800C 내지 820C 는 도 6b 의 600B 내지 620B 에 각각 대응한다. 825C 에서, SGSN (220B) 은 (도 8b 의 800B 내지 820B 에서와 같이) UL 및 DL 트래픽 비활성 타이머들을 시작하고 유지한다. 어떤 지점에서, (예컨대, 도 8c 의 825B 에서와 같이) SGSN들 (220B) UL 트래픽 비활성 타이머가 만료한다고 가정한다 (830C). 따라서, SGSN (220B) 은 App* UL GBR 베어러 상의 그의 GBR 을 공칭 레벨, 예컨대 1 kpbs 까지, GGSN (225B) 과의 835C 및 840C 의 시그널링을 통해서 감소시킨다. 845C 에서, GGSN (225B) 은 (App* GBR 베어러가 820C 에서 제시된 후) (도 8b 의 800B 내지 820B 에서와 같이) 825C 의 SGSN (220B) 의 타이머들에 독립적인 UL 및 DL 트래픽 비활성 타이머들을 시작하고 유지한다. 어떤 지점에서, (예컨대, 도 8c 의 825B 에서와 같이) GGSN (225B) 의 UL 트래픽 비활성 타이머가 만료한다고 (850C) 가정한다. 따라서, GGSN (225B) 은 RAN (120) 에게 App* UL GBR 베어러 상의 GBR 을 공칭 레벨, 예컨대 1 kpbs 까지, 855C 내지 895C 사이의 시그널링을 통해서 감소시키도록 프롬프트한다. 도 8c 는 하프 듀플렉스 PTT 세션에 고유하지만, 도 8c 가 어떻게 PTT 이외의 풀 듀플렉스 세션들 또는 하프 듀플렉스 세션들을 수용하도록 수정될 수 있는지를 용이하게 알 수 있을 것이다. 또한, 도 8c 는 콜 타겟 UE 에 고유하지만, 도 8c 가 어떻게 콜 발신자 UE 에 대해 수정될 수 있는지를 용이하게 알 수 있을 것이다 (예컨대, 805C 에서 수신되는 페이지 대신, PTT 버튼 푸시가 검출되는, 등). 또한, 도 8c 는 URA_PCH / CELL_PCH 상태에 있는 동안 805C 에서 페이지를 수신하는 주어진 UE 를 나타내지만, 대안 구현예에서, 주어진 UE 는 CELL_DCH 상태에 있는 동안 PTT 콜 어나운스먼트를 대안적으로 수신할 수 있다.
도 8d 는 본 발명의 일 실시형태에 따른, 하프 듀플렉스 App* PTT 세션의 콜 발신자인 주어진 UE 에 대한, LTE 네트워크 내에서의 도 8b 의 예시적인 구현예를 예시한다. 도 8d 를 참조하면, 800D 내지 820D 는 도 6c 의 600C 내지 620C 에 각각 대응한다. 825D 에서, S-GW (230D) 는 (도 8b 의 800B 내지 820B 에서와 같이) UL 및 DL 트래픽 비활성 타이머들을 시작하고 유지한다. 어떤 지점에서, (예컨대, 도 8c 의 825B 에서와 같이) S-GW (230D) 의 DL 트래픽 비활성 타이머가 만료한다고 (830D) 가정한다. 따라서, S-GW (230D) 는 App* DL GBR 베어러 상의 그의 GBR 을 공칭 레벨, 예컨대 1 kpbs 까지 감소시키고, P-GW / PCRF (235D / 240D) 에게 GBR 감소를 통지한다 (835D). 840D 에서, P-GW / PCRF (235D / 240D) 는 (App* GBR 이 820D 에서 제시된 후) (도 8b 의 800B 내지 820B 에서와 같이) 825D 의 S-GW (230D) 의 타이머들과는 독립적인 UL 및 DL 트래픽 비활성 타이머들을 시작하고 유지한다. 어떤 지점에서, (예컨대, 도 8c 의 825B 에서와 같이) P-GW / PCRF (235D / 240D 225B) 에 의해 유지된 DL 트래픽 비활성 타이머가 만료한다고 845D 가정한다. 따라서, P-GW / PCRF (235D / 240D) 는 850D 내지 874D 사이의 시그널링을 통하여, 서빙 eNodeB (205D) 에게 App* DL GBR 베어러 상에서의 GBR 을 공칭 레벨, 예컨대 1 kpbs 까지 감소시키도록 프롬프트한다. 도 8d 는 하프 듀플렉스 PTT 세션에 고유하지만, 어떻게 도 8d 가 PTT 이외의 풀 듀플렉스 세션들 또는 하프 듀플렉스 세션들을 수용하도록 수정될 수 있는지를 용이하게 알 수 있을 것이다. 또한, 도 8d 는 콜 발신자 UE 에 고유하지만, 도 8d 가 어떻게 콜 타겟 UE 에 대해 수정될 수 있는지를 용이하게 알 수 있을 것이다 (예컨대, 805D 에서 PTT 버튼 푸시 대신, PTT 페이지 또는 콜 어나운스먼트 메시지가 App* 세션에 도달할 수도 있다). 또한, 도 8d 는 RCC-휴지 상태로부터의 App* PTT 세션을 시작하는 주어진 UE 를 나타내지만, 대안 구현예에서, 주어진 UE 는 또한 RCC-접속된 상태에 여전히 있는 동안 App* PTT 세션을 시작할 수 있다.
도 9a 는 본 발명의 일 실시형태에 따른, GBR 리소스들이 RAN (120) 및 코어 네트워크 (140) 에서 로컬로 관리되는 QoS 관리 프로시저의 좀더 상세한 구현예를 예시한다. (상기) 표 2 에서 설명된 바와 같이, GBR 리소스들이 RAN (120) 및 코어 네트워크 (140) 에서 로컬로 관리되는 QoS 관리 프로시저 (즉, 표 2 의 #4) 는 도 2d 의 LTE 코어 네트워크에서 구현될 수 있지만, 도 2a 의 1x EV-DO 코어 네트워크, 또는 도 2b 내지 도 2c 의 W-CDMA 코어 네트워크, 또는 도 2e 의 eHRPD 네트워크에서는 표준-규격 구현이 불가능할 수도 있다.
도 9a 를 참조하면, App* 통신 세션 (예컨대, 하프 듀플렉스 App* 세션, 풀 듀플렉스 App* 세션, 등) 에 대한 App* GBR 매체들 베어러의 셋업의 검출에 응답하여, 통신 세션에 참가하는 특정의 UE 를 위한 RAN (120) 내 서빙 eNodeBs(들) 및 코어 네트워크 (140) (예컨대, P-GW (235D) 뿐만 아니라 S-GW (230D)) 양자가 App* GBR 매체들 베어러 상의 UL 및 DL 트래픽을 모니터링하는 데이터 비활성 타이머들을 시작한다 (900). 일반적으로, 도 9a 는 RAN (120) 이 또한 UL 및 DL 채널들 상에서의 QoS 리소스들 (예컨대, GBR) 을 제어하기 위해 UL 및 DL 트래픽 비활성 타이머들을 유지하는 것을 제외하고는, 도 8a 와 유사한 LTE 구현예에 대응한다. 다시 말해서, RAN (120) 및 LTE 코어 네트워크 컴포넌트들은 그들의 개개의 타이머들을 독립적으로 실행하며, RAN (120) 과 LTE 코어 네트워크 사이의 조정 (예컨대, 메시지들을 시그널링하는 것) 이 상이한 엔터티들에서 QoS 조정들을 구현하는데 이용될 필요가 없도록 그들 자신의 GBR 또는 QoS 조정들을 행한다; 즉, 각각의 LTE 컴포넌트는 그의 자신의 트래픽 비활성 타이머(들) 에 기초하여 QoS 결정들을 독립적으로 또는 일방적으로 행할 수 있다. 주지하고 있는 바와 같이, 이것은 각각의 LTE 컴포넌트가 GBR 또는 QoS 를 독립적인 방법으로 변경할 수 있다는 것을 의미하며, 그 결과, 조정된 QoS 를 가진 베어리가 할당되는 UE (또는, 클라이언트 디바이스) 는 UE 가 그의 공중 인터페이스 리소스들에 대해 RAN (120) 에 의해 구현되는 QoS 조정(들) 을 여전히 인식하더라도, 코어 네트워크에서 구현되는 QoS 조정(들) 을 통지받을 필요가 없다. 따라서, 이중 RAN 및 코어 네트워크 구현예를 제외하고는, 도 9a 의 900-935 는 도 8a 의 800-835 와 각각 유사하며, 간결성을 위해 추가로 설명되지 않을 것이다. 도 9b 의 900B 내지 935B 는 LTE-특정의 컴포넌트들 및 메시지들이 더욱 명시적으로 참조되는 도 9a 의 900 내지 935 의 더욱 더 상세한 구현예를 예시한다.
도 10a 내지 도 10b 는 본 발명의 실시형태들에 따른, W-CDMA 및 EV-DO 아키텍쳐들에 대한, RAN-개시되는 타이머-기반의 방향성 QoS 흐름 관리 프로시저들을 각각 예시한다. (상기) 표 2 에서 설명된 바와 같이, RAN-개시되는 타이머-기반의 방향성 QoS 흐름 관리 프로시저 (즉, 표 2 의 #5) 는 도 2b 내지 도 2c 의 W-CDMA 코어 네트워크에서 (도 10a 에 도시된 바와 같이, "상호작용" 트래픽 클래스가 세션에 대해 사용되면) 구현될 수 있거나, 또는 도 2a 의 1x EV-DO 코어 네트워크 (도 10b 에 도시) 에서 구현될 수 있지만, 도 2d 의 LTE 네트워크에서는 표준-규격 구현이 불가능할 수도 있다.
W-CDMA-특정의 구현예를 기술하는 도 10a 를 참조하면, 통신 세션 (예컨대, 하프 듀플렉스 App* 세션, 풀 듀플렉스 App* 세션, 등) 에 대한 App* 데이터 RAB 의 셋업의 검출에 응답하여, RAN (120) (즉, UTRAN) 은 App* 데이터 RAB 상에서의 UL 및 DL 트래픽을 모니터링하는 데이터 비활성 타이머들을 시작한다 (1000A). 특히, App* 데이터 RAB 는 "상호작용" 트래픽 클래스, 시그널링 표시 ("예") 및 ARP 속성들으로 구성되며 (1000A), 또는 대안적으로 App* 데이터 RAB 는 RAN (120) 이 "대화" 트래픽 클래스와 연관된 GBR 파라미터들이 수정될 수 있도록 재구성되는 것이 가능하면 "대화" 트래픽 클래스로 구성될 수 있다.
1005A 에서, RAN (120) 은 UL 또는 DL 트래픽이 통신 세션에 대해 App* 데이터 RAB 상에서 검출되는지 여부를 결정한다. 특히, RAN (120) 은 1005A 에서 App* 통신 세션에 대한 트래픽이 UL 또는 DL 방향에서 검출되는지 여부를 결정한다. 1005A 에서 UL 또는 DL 트래픽이 RAN (120) 에 의해 검출되면, 트래픽이 검출된 각각의 방향 (UL 및/또는 DL) 에 대한 트래픽 비활성 타이머가 리셋된다 (1010A). 1015A 에서, 트래픽 비활성 타이머들이 여전히 실행하고 있는 (즉, 아직 만료되지 않은) 각각의 방향 (UL 및/또는 DL) 에 대해, RAN (120) 은 (예컨대, 도 5 의 515, 525, 540 및 550 과 유사하게) 임계치 GBR 이 App* 데이터 RAB 에 대해 개개의 방향으로 이미 셋업되어 있는지 여부를 결정한다. 예를 들어, 1015A 에서, RAN (120) 은 MAC-es/MAC-hs GBR 이 데이터 RAB 의 UL 및/또는 DL 상에서 XApp * kpbs 로 설정되어 있는지 여부를 체크할 수 있다. 그렇지 않으면, RNC (215B) 는 RAN (120) 내 서빙 노드 B(들) 에게 임계치 GBR 를 여전히 가지지 않고 그 연관된 트래픽 비활성 타이머가 여전히 실행되고 있는 각각의 방향 (UL 또는 DL) 으로, GBR 을 (예컨대, XApp * kpbs 까지), 증가시키도록 요청한다 (1020A). 주지하고 있는 바와 같이, UE 는 QoS 조정이 공중 인터페이스 리소스 (즉, UE 와 RAN (120) 사이의 접속) 에 대해 구현되기 때문에, 1020A 의 QoS 조정 (또는, GBR 증가) 에 대해서 통지받을 수 있다.
도 10a 를 참조하면, 1025A 에서, RAN (120) 은 UL 데이터 트래픽이 App* 데이터 RAB 상에서 검출되는지를 추가로 결정하고, 서빙 노드 B 는 App* 데이터 RAB 가 UL 에 대한 GBR 을 지원하기 위해 비-스케쥴링된 송신 승인으로 구성되는지 여부를 체크한다 (1025A). 그렇다면, 어떤 추가적인 액션도 App* 데이터 RAB 에 대한 서빙 노드 B 에서의 UL GBR 을 셋업하는데 불필요하다 (1030A). 그렇지 않으면, 서빙 노드 B 는 UL 상에서의 비-스케쥴링된 송신 승인을 위해 App* 데이터 RAB 를 재구성한다 (1035A).
도 10a 를 참조하면, RAN (120) 은 UL 및 DL 트래픽 비활성 타이머들을 모니터링하여, UL 및 DL 트래픽 비활성 타이머들이 만료되는지 여부를 결정한다 (1040A). 만료가 1040A 에서 검출되면, RAN (120) 은 (예컨대, 도 5 의 515, 525, 540 및 550 과 유사하게) 임계치 GBR 이 만료가 검출되는 개개의 방향에서 GBR 매체들 베어러에 대해 아직 셋업되지 않은지 여부를 결정한다 (1045A). 예를 들어, 1045A 에서, RAN (120) 은 MAC-es/MAC-hs GBR 이 App* 데이터 RAB 의 UL 및/또는 DL 상에서 XApp * kpbs 로 설정되는지 여부를 체크할 수 있다. 임계치 GBR 이 UL 또는 DL 에 대해 그 만료된 방향으로 아직 셋업되어 있지 않으면, 프로세스는 1005A 로 복귀한다. 그렇지 않고, 임계치 GBR 이 UL 또는 DL 에 대해 그 만료된 방향으로 셋업되어 있으면, RNC (215B) 는 RAN (120) 내 서빙 노드 B(들) 에게 연관된 트래픽 비활성 타이머가 만료되며 임계치 GBR 을 가지는 각각의 방향 (UL 또는 DL) 에서, GBR 을 (예컨대, XApp * kpbs 까지) 감소시키도록 요청한다 (1050A). 주지하고 있는 바와 같이, UE 는 QoS 조정이 공중 인터페이스 리소스 (즉, UE 와 RAN (120) 사이의 접속) 에 대해 구현되기 때문에, 1050A 의 QoS 조정 (또는, GBR 감소) 에 대해서 통지받을 수 있다.
도 10a 를 참조하면, 1055A 에서, UL 트래픽 비활성 타이머가 1040A 에서 데이터 RAB 에 대해 만료되면, 서빙 노드 B 는 App* 데이터 RAB 가 UL 에 대한 GBR 을 지원하기 위해 비-스케쥴링된 송신 승인으로 구성되는지 여부를 체크한다 (1055A). 그렇지 않으면, 어떤 추가적인 액션도 불필요하다 (1060A). 그렇다면, 서빙 노드 B 는 UL 상에서의 스케쥴링된 송신 승인을 위해 App* 데이터 RAB 를 재구성한다 (1065A).
1x EV-DO -특정의 구현예를 기술하는 도 10b 를 참조하면, App* 통신 세션 (예컨대, 하프 듀플렉스 세션, 풀 듀플렉스 세션, 등) 에 대한 매체들 QoS 흐름의 셋업의 검출에 응답하여, RAN (120) 은 App* 매체들 QoS 흐름 상에서 UL 및 DL 트래픽을 모니터링하는 데이터 비활성 타이머들을 시작한다 (1000B).
1005B 에서, RAN (120) 은 UL 또는 DL 트래픽이 통신 세션에 대해 App* 매체들 QoS 흐름 상에서 검출되는지 여부를 결정한다. 1005B 에서 UL 또는 DL 트래픽이 RAN (120) 에 의해 검출되면, 트래픽이 검출된 각각의 방향 (UL 및/또는 DL) 에 대한 트래픽 비활성 타이머가 리셋된다 (1010B). 1015B 에서, 트래픽 비활성 타이머들이 여전히 실행하고 있는 (즉, 아직 만료되지 않은) 각각의 방향 (UL 및/또는 DL) 에 대해, RAN (120) 은 (예컨대, 도 5 의 515, 525, 540 및 550 과 유사하게) QoS 가 App* 매체들 QoS 흐름에 대해 개개의 방향으로 이미 셋업되어 있거나 또는 턴온되어 있는지 여부를 결정한다. 그렇다면, 프로세스는 1005B 로 복귀한다. 그렇지 않으면, RAN (120) 은 ReservationOnMessage 를 전송하여 그 활성이 검출된 방향에서 App* 매체들 QoS 흐름을 활성화한다 (1020B). 주지하고 있는 바와 같이, UE 는 QoS 흐름 활성화가 공중 인터페이스 리소스 (즉, UE 와 RAN (120) 사이의 접속) 에 대해 구현되기 때문에, 1020B 의 QoS 흐름 활성화에 대해 통지받을 수 있다.
도 10b 를 참조하면, RAN (120) 은 UL 및 DL 트래픽 비활성 타이머들을 모니터링하여, UL 및 DL 트래픽 비활성 타이머들이 만료하는지 여부를 결정한다 (1025B). 만료가 1025B 에서 검출되면, RAN (120) 은 (예컨대, 도 5 의 515, 525, 540 및 550 과 유사하게) QoS 가 만료가 검출된 개개의 방향에서 App* 매체들 QoS 흐름에 대해 이미 셋업되어 있거나 또는 턴온되어 있는지를 결정한다 (1030B). 그렇다면, 프로세스는 1005B 로 복귀한다. 그렇지 않고, QoS 가 연관된 트래픽 비활성 타이머가 만료된 방향에서 App* 매체들 QoS 흐름에 대해 셋업되었으면, RAN (120) 은 ReservationOffMessage 를 전송하여 만료가 검출된 방향에서 매체들 QoS 흐름을 비활성화한다 (1035B). 주지하고 있는 바와 같이, UE 는 QoS 흐름 비활성화가 공중 인터페이스 리소스 (즉, UE 와 RAN (120) 사이의 접속) 에 대해 구현되기 때문에, 1035B 의 QoS 흐름 비활성화에 대해 통지받을 수 있다.
IETF (Internet Engineering Task Force) 와 함께 월드와이트 웹 컨소시엄 (W3C) 은 2011 년에 웹 실시간 통신 (WebRTC) 으로 불리는 웹 개발자 기술의 개발을 시작하였다. WebRTC 는 종점들의 상대적인 로케이션에 관계없이 (예컨대, 동일한 사설 네트워크에서, 동일한 디바이스 상의 개개의 종점들이 별개의 네트워크 어드레스 변환 (NAT들) 및/또는 방화벽들 등 너머에 있든 아니든) 브라우저 (또는, 종점) 가 하나 이상의 다른 종점들과의 피어-투-피어 (P2P) 실시간 통신에 참가가능하게 하는 프로토콜이다.
WebRTC 는 실시간 매체들의 송신을 위해 실시간 전송 프로토콜 (RTP) 을 레버리지한다. RTP 는 많은 상이한 매체들 유형들에 대해 전송 프로토콜로서 기능할 수 있는 유연한 프로토콜 (flexible protocol) 이다. 이들 매체들 유형들은 오디오 또는 비디오에 맵핑하는 것으로 넓게 분류될 수 있거나, 또는 연관된 오디오 또는 비디오 코덱, 대역폭 요구사항들, 오디오 또는 비디오 해상도, 등과 같은 정보를 지정함으로써 좀더 구체화될 수 있다. 더욱이, 메시 회의 모델에서, 다수의 매체들 스트림들이 클라이언트-기반 오디오 믹싱 또는 비디오 합성을 가능하게 하기 위해 P2P 로 전송될 수도 있다.
WebRTC 를 통해서 통신하는 종점들이 개개의 종점들 사이의 종단간 접속들의 개수를 제한하는 하나 이상의 NAT들 및/또는 방화벽들에 의해 분리될 수 있기 때문에, WebRTC 는 단일 IP 어드레스 및 포트를 통한 RTP 스트림들의 멀티플렉싱을 허용한다. 이러한 부분적인 제한으로 인해, 기존 WebRTC 사양들은 RTP 및 RTP 제어 프로토콜 (RTCP) 통신들에 멀티플렉싱이 채용되도록 권장한다. 다수의 유형들의 스트림들이 하나의 IP 어드레스 및 포트 번호를 통해서 멀티플렉싱될 때, 차별화된 서비스 품질 (QoS) 을 상이한 유형들의 매체들에게 제공하는 것은 더욱 도전적이 된다.
예를 들어, 비-WebRTC 화상 회의 세션들에서는, 오디오 스트림이 비디오 스트림과 격리되어 유지되고 이에 따라서 오디오 스트림이 QoS 링크에 할당되고 비디오 스트림이 비-QoS 링크에 할당되는 것이 일반적이다. 이것은, 오디오 스트림이 일반적으로 비디오 스트림보다 더 적은 대역폭을 소비하기 때문이며, 그리고 비디오 스트림이 수신기에서의 에러-은닉 전략들, 순방향 에러 정정 코드들의 사용, 비디오 해상도를 감소시키는 것 등과 같은 프로시저들에 의해 도움을 받을 수 있기 때문이다.
WebRTC 에서 상이한 매체들 유형들에 대한 QoS 구별을 획득하는 종래의 접근법은 브라우저 자체에서의 멀티플렉싱을 불가능하게 하는 것이다. 그러나, 이는 브라우저에 변경들을 필요로 하며, 또한 브라우저가 상이한 매체들 유형들에 대해 다수의 종단간 접속들 (즉, 별개의 IP 어드레스들 및 포트 번호들) 을 설정하는 것이 가능할 것이라고 가정한다.
WebRTC 에서 상이한 매체들 유형들에 대한 QoS 구별을 획득하는 다른 종래의 접근법들은, 3GPP-정의된 QoS-이용가능 트래픽 흐름들이 IP-패킷 차별화된 서비스들 코드 지점 마킹들 (DSCP) 마킹들을 트리거 오프가능하게 하거나, 또는 3GPP-정의된 QoS-이용가능 트래픽 흐름들이 RTP 동기화 소스 (SSRC) 를 트리거 오프가능하게 하는 것이다. 그러나, 이들 종래의 접근법들의 각각은 패킷 필터들 및 트래픽 흐름 템플릿들에 결과적으로 영향을 미칠 3GPP 표준들에서는 변한다.
또 다른 종래의 접근법은 브라우저 자체가 위에서 설명한 UE-개시되는 QoS 특징을 레버리지하는 것으로, 이에 의해 UE 상의 브라우저가 QoS 링크를 셋업하고 적어도 오디오 미디어에 대한 멀티플렉싱을 바이패스하려고 시도할 것이다. 그러나, 이 접근법은 UE-개시되는 QoS 특징을 트리거링하기 위한 애플리케이션-유형에 의해 흐름들이 식별될 수 있도록 하기 위해서 WebRTC API 뿐만 아니라 브라우저 양쪽에 대한 변경들을 필요로 한다.
본 발명의 실시형태들은 WebRTC 멀티미디어 클라이언트 애플리케이션 (예컨대, 브라우저) 에 대한 및/또는 3GPP 시그널링 또는 네트워크 설계에 대한 변경을 요함이 없이, WebRTC 를 이용하는 통신 세션들에 대해 QoS 구별을 획득하는 것에 관한 것이다. 하이-레벨에서, 아래에서 설명되는 본 발명의 실시형태들은 WebRTC 멀티미디어 클라이언트 애플리케이션으로부터 획득된 멀티플렉싱된 RTP 스트림으로부터 어떤 미디어 컴포넌트(들)를 선택적으로 디-멀티플렉싱하고, 또한 인입하는 매체들을, WebRTC 멀티미디어 클라이언트 애플리케이션에 의해 예상되는 멀티플렉싱된 포맷으로 선택적으로 재-멀티플렉싱하는 프록시 모듈을 UE 에 제공한다.
도 11 은 2개의 UE들 사이의 WebRTC 세션에 대한 종래의 트래픽의 흐름을 예시한다. 도 11 을 참조하면, 제 1 UE (1100) (또는, UE 1) 에는 모바일 브라우징 애플리케이션과 같은, 제 1 WebRTC 멀티미디어 클라이언트 애플리케이션 (1105) 이 제공된다. WebRTC 멀티미디어 클라이언트 애플리케이션 (1105) 은 매체들 (예컨대, 오디오, 비디오, 등) 을 WebRTC 세션을 위한 단일 멀티플렉싱된 스트림 ("MUX") 으로 멀티플렉싱하고, 그후 하나 이상의 RTP / RTPC 패킷들 내 멀티플렉싱된 스트림을 단일 IP 어드레스 및 포트 번호를 통해서 서빙 네트워크 (1110) (예컨대, WiFi 네트워크, RAN (120), 등) 로 전달한다. 서빙 네트워크 (1110) 는 멀티플렉싱된 스트림을 서빙 네트워크 (1120) 로 전달하기 위해, NAT / 방화벽 통과 (firewall traversal) 기법들을 이용하여, NAT / 방화벽 (1115) 을 통한 접속을 뚫거나 또는 개방시킨다. 서빙 네트워크 (1120) 는 멀티플렉싱된 스트림을 UE 1 로부터, 다른 모바일 브라우징 애플리케이션과 같은 제 2 WebRTC 멀티미디어 클라이언트 애플리케이션 (1130) 이 제공된 제 2 UE (1125) (또는, UE 2) 로 전달한다. 주지하고 있는 바와 같이, 제 1 WebRTC 멀티미디어 클라이언트 애플리케이션 (1105) 이 MUX 를 디폴트로 발생하기 때문에, MUX 는 또한 UE들 1 및 2 이 양쪽다 UE들 1 과 2 사이의 통신이 NAT / 방화벽 통과 없이 가능하도록 동일한 서빙 네트워크에 의해 서빙되고 있는 시나리오에서 사용될 것이다.
도 12a 는 본 발명의 일 실시형태에 따른, 동일한 서빙 네트워크에 의해 서빙되는 2개의 UE들 사이의 WebRTC 세션에 대한 트래픽의 흐름을 예시한다. 도 12a 를 참조하면, 제 1 UE (1200) (또는, UE 1) 에는 모바일 브라우징 애플리케이션과 같은, 제 1 WebRTC 멀티미디어 클라이언트 애플리케이션 (1205) (또는, 제 1 WebRTC 종점) 이 제공된다. UE 1 에는 또한 제 1 WebRTC 프록시 모듈 (1210) 이 제공된다. 아래에서 좀더 자세하게 설명되는 바와 같이, 제 1 WebRTC 프록시 모듈 (1210) 은 제 1 WebRTC 멀티미디어 클라이언트 애플리케이션 (1205) 이 송신하려고 시도하고 있는 단일 멀티플렉싱된 스트림 ("MUX") 으로부터 매체들의 부분들을 선택적으로 디-멀티플렉싱하도록, 또한 제 1 WebRTC 멀티미디어 클라이언트 애플리케이션 (1205) 으로의 전달을 위해, 다른 UE 상의 다른 WebRTC 프록시 모듈에 의해 단일 멀티플렉싱된 스트림으로 디-멀티플렉싱된 다수의 인입하는 매체들 스트림들을 "재-멀티플렉싱"하도록 구성된다.
도 12a 를 참조하면, 일 예에서, 제 1 WebRTC 멀티미디어 클라이언트 애플리케이션 (1205) 은 도 11 의 WebRTC 멀티미디어 클라이언트 애플리케이션 (1105) 과 유사하게 (또는, 심지어 동일하게) 구성될 수 있다. 다시 말해서, 도 12a 의 실시형태는 동작을 위해 기존 WebRTC 멀티미디어 클라이언트 애플리케이션들에 대한 어떤 변경들을 엄격히 요구하지 않으며, WebRTC 종점들은 (이용가능한 경우) QoS 링크를 레버리지하기 위한 매체들 스트림들의 선택적 디-멀티플렉싱 및/또는 재-멀티플렉싱을 구현하기 위해, WebRTC 프록시 모듈 (1210) 을 필요로 하지만 "정상적으로" 계속 동작할 수 있다.
따라서, 제 1 WebRTC 멀티미디어 클라이언트 애플리케이션 (1205) 은 매체들 (예컨대, 오디오, 비디오, 등) 을 WebRTC 세션을 위한 단일 멀티플렉싱된 스트림 ("MUX") 으로 멀티플렉싱하고, 그리고 하나 이상의 RTP / RTPC 패킷들 내 MUX 를 서빙 네트워크 (1110) (예컨대, WiFi 네트워크, RAN (120), 등) 로 송신하려고 시도한다. 그러나, 도 12a 에서, MUX 를 도 11 에서와 같이 서빙 네트워크로 송신하는 대신, WebRTC 프록시 모듈 (1210) 은 특수 처리 (즉, 디-멀티플렉싱) 를 위해 MUX 를 인터셉트한다.
좀더 구체적으로, 도 12a 에서, UE 1 은 QoS 링크 (예컨대, 도 13 내지 도 17 에 대해 아래에서 좀더 자세히 설명되는 바와 같은, 프록시-개시되는, UE-개시되는 및/또는 NW-개시되는 QoS 획득 프로시저들을 통하여) 및 비-QoS 링크 양쪽다 획득가능하다고 가정된다. 본원에서 사용될 때, 용어 "비-QoS" 링크는 제로 QoS (또는, GBR) 를 가지는 임의의 접속, 베어러 또는 채널, 또는 대안적으로는, 제로 위에 여전히 있으면서 QoS 링크들이 정의되는 QoS 의 임계치 미만인 "중간" 레벨의 QoS (또는, GBR) 를 가지는 접속, 베어러 또는 채널을 지칭할 수 있다 (이에 의해 QoS 링크가 그 임계치보다 크거나 동일한 QoS 의 레벨을 가진다).
제 1 WebRTC 프록시 모듈 (1210) 은 일련의 QoS 규칙들을 적용하여, 제 1 WebRTC 멀티미디어 클라이언트 애플리케이션 (1205) 에 의해 멀티플렉싱된 스트림으로 이미 멀티플렉싱된 상위-우선순위 매체들을 식별한다. (아래) 표 3 은 본 발명의 실시형태들에 따른, 제 1 WebRTC 프록시 모듈 (1210) 에 의해 선택적 디-멀티플렉싱 프로시저의 부분으로서 시행될 수 있는 QoS 규칙들의 몇 개의 예들을 제공한다:
| 규칙 # | 매체들 유형 | QoS 링크 또는 비-QoS 링크? |
| 1 | 오디오 미디어 | QoS 링크 |
| 2 | '벌크' 비디오 미디어: B-프레임들 및/또는 P-프레임들 |
비-QoS 링크 |
| 3 | 비-벌크 비디오 미디어: I-프레임 또는 I-슬라이스; 헤더 정보 (예컨대, 매크로블록 (MB) 유형, 양자화 파라미터들 및/또는 모션 벡터들); 시퀀스 파라미터 세트 (SPS); 픽처 파라미터 세트 (PPS); 낮은 양자화 사이즈 (예컨대, 섬네일들, 등) 를 통한 픽처 프레임 또는 슬라이스의 대안적인 표현들; 및/또는 립 싱크 (Lip Sync) 정보. |
QoS 링크 (예컨대, 오디오 무음의 기간 동안) |
| 4 | 높은 우선순위 비-비디오 파일 데이터: 대응하는 파일에 대한 해독 키들; 헤더 정보 (예컨대, 파일 사이즈, 파일 유형 또는 MIME 유형, 이미지의 섬네일 버전); 및/또는 사이즈가 작고 높은 우선순위 콘텐츠를 포함하는 독립된 (self-contained) 파일 |
QoS 링크 (예컨대, 오디오 무음의 기간 동안) |
| 5 | 하위-우선순위 비-비디오 파일 데이터 | 비-QoS 링크 |
표 3 -
WebRTC
프록시 모듈에서의 디-
멀티플렉싱
동작에 대한 QoS 규칙 예들
(위에서) 표 3 에 있어, 어떤 비-오디오 데이터가 충분한 QoS 가 QoS 링크 상에서 이용가능하면 무음의 기간들 또는 오디오 활성의 기간들 동안 비-오디오 데이터를 QoS 링크로 이동시키는 것과 같은, 어떤 규칙들에 기초하여, 비-QoS 링크 대신, QoS 링크에 맵핑될 수 있으며, 그리고 (위 표 3 에 요약된) 이들 동일한 규칙들이 또한 어느 매체들 유형들이 비-QoS 링크 대신 QoS 링크 상에서 송신을 위해 디-멀티플렉싱되는지를 결정하는데 그 일련의 QoS 규칙들의 일부분으로서 이용될 수 있음을 명백히 알 수 있을 것이다. 따라서, QoS 링크 상에서 송신되는 매체들은 오디오에 엄격히 제한될 필요가 없으며, 그러나 비디오 미디어 및/또는 비-비디오 파일 매체들의 어떤 상위-우선순위 유형들도 또한 포함할 수 있다.
도 12a 로 되돌아 가서, 제 1 WebRTC 프록시 모듈 (1210) 이 일련의 QoS 규칙들에 기초하여 멀티플렉싱된 스트림 내에 존재하는 상위-우선순위 매체들을 식별가능하면, 제 1 WebRTC 프록시 모듈 (1210) 은 하위-우선순위 매체들 (예컨대, 벌크 비디오 미디어, 등) 로부터 상위-우선순위 매체들 (예컨대, 오디오 미디어 및/또는 제한된 양의 비디오 미디어, 예컨대 비디오 제어 프레임들, I-프레임들, 등) 을 디-멀티플렉싱한다 (또는, 스트립 아웃한다 (strip out)). 기능적으로, 제 1 WebRTC 프록시 모듈 (1210) 이 상위-우선순위 매체들을 포함하는 제 1 디-멀티플렉싱된 WebRTC 스트림 ("DE-MUX1") 및 하위-우선순위 매체들을 포함하는 제 2 디-멀티플렉싱된 WebRTC 스트림 ("DE-MUX2") 을 발생하는 한, 하위-우선순위 매체들이 또한 멀티플렉싱된 스트림으로부터 스트립 아웃될 (또는, 디-멀티플렉싱될) 수 있음을 알 수 있을 것이다. 제 1 WebRTC 프록시 모듈 (1210) 은 DE-MUX1 을 서빙 네트워크 (1215) 로 QoS 링크 상에서 송신하고, DE-MUX2 를 서빙 네트워크 (1215) 로 비-QoS 링크 상에서 송신한다.
추가 실시형태들에서, MUX 로부터 DE-MUX1 및 DE-MUX2 를 발생시키는 디-멀티플렉싱 동작은 트랜스코딩 (transcoding) 을 포함할 수 있다. 이것이 그 경우이면, (예컨대, 도 14 의 1435, 도 15 의 1540, 등에서) 제안 (offer)/응답 (answer) 교환의 일부로서, WebRTC-이용가능 브라우저들에 의해 지원되는 코덱 (예컨대, G.711, Opus, 등) 이 WebRTC 프록시 모듈 (1210) 에 의해 선택될 수 있다. 예를 들어, 스펙트럼의 효율이 소망되면, (본질적으로 압신된 (companded) PCM 인) G.711 가 AMR-NB 와 같은, 스펙트럼-효율적인 협대역 코덱을 트랜스코딩하는데 선택될 수 있다. 한편, 스펙트럼의 효율 및 오디오 품질 양쪽다 소망되면, 광대역 Opus 코덱 모드들 중 하나가 AMR-WB 에 대한 트랜스코딩을 위해 선택될 수 있다. 일 예에서, Opus 가 VoLTE 가 WebRTC 세션을 지원하는데 사용되는 경우, VoLTE 베어러들에 대해 디폴트로 선택될 수 있다.
도 12a 를 참조하면, 제 2 UE (1225) (또는, UE 2) 에는, UE 1 상에서의 제 1 WebRTC 멀티미디어 클라이언트 애플리케이션 (1205) 및 제 1 WebRTC 프록시 모듈 (1210) 과 유사하게 (또는 심지어 동일하게) 각각 구성될 수 있는, 제 2 WebRTC 멀티미디어 클라이언트 애플리케이션 (1230) (또는, 제 2 WebRTC 종점) 및 제 2 WebRTC 프록시 모듈 (1235) 이 제공된다고 가정한다. 또한, UE 1 와 유사하게, UE 2 가 QoS 링크 (예컨대, 도 13 내지 도 17 에 대해 아래에서 좀더 자세히 설명되는 바와 같은 UE-개시되는 또는 NW-개시되는 QoS 획득 프로시저를 통하여) 및 비-QoS 링크 양쪽다 획득가능하다고 가정한다.
도 12a 의 실시형태에서, UE들 1 및 2 양쪽다 DE-MUX1 및 DE-MUX2 가 NAT /방화벽 (1220) 을 통과할 필요가 없도록, 동일한 서빙 네트워크 (1215) 에 의해 서빙된다. 대신, 서빙 네트워크 (1215) 는 DE-MUX1 을 UE 2 로 UE 2 의 QoS 링크 상에서 송신하고, DE-MUX2 를 UE 2 로 UE 2 의 비-QoS 링크 상에서 송신한다. 제 2 WebRTC 프록시 모듈 (1210) 은 DE-MUX1 및 DE-MUX2 를 수신하고 그후 DE-MUX1 및 DE-MUX2 를 "재"-멀티플렉싱하여 제 1 WebRTC 멀티미디어 클라이언트 애플리케이션 (1205) 에 의해 제 1 WebRTC 프록시 모듈 (1210) 에 처음에 제공된 멀티플렉싱된 스트림 ("MUX") 을 재구성하거나 또는 복원한다. 다시 말해서, 제 2 WebRTC 프록시 모듈 (1235) 은 MUX 를 재구성하기 위해 제 1 WebRTC 프록시 모듈 (1210) 에 의해 수행되는 디-멀티플렉싱 프로시저를 역전시킨다. 제 2 WebRTC 프록시 모듈 (1235) 은 그후 그 재구성된 (또는, 재-멀티플렉싱된) MUX 를 WebRTC 멀티미디어 클라이언트 애플리케이션 (1230) 에 제공한다.
당업자에 의해 주지되는 바와 같이, QoS 는 부분적으로, UE들 1 및 2 가 양쪽다 동일한 서빙 네트워크 (1215) 에 의해 서빙되고 종단간 QoS 를 획득할 수 있기 때문에, 도 12a 에서 WebRTC 세션에 대해 매체들 (예컨대, 오디오 미디어, 상위-우선순위 비디오 미디어, 등) 의 일부를 전송하는데 사용된다. 이것은, 종래에는 WebRTC 멀티미디어 클라이언트 애플리케이션들이 MUX 내 멀티플렉싱된 매체들의 임의의 부분에 대해 QoS 를 셋업함이 없이, MUX 를 변경하는 것을 디폴트로 할 것이기 때문에, 도 11 에서 불가능하다.
도 12b 는 본 발명의 일 실시형태에 따른, 상이한 서빙 네트워크들에 의해 서빙되는 2개의 UE들 사이의 WebRTC 세션에 대한 트래픽의 흐름을 예시한다. 도 12b 는 도 12a 에서의 단일 서빙 네트워크 (1215) 가 UE들 1 및 2 를 각각 서빙하며 NAT / 방화벽 (1220) 에 의해 분리되는 2개의 별개의 서빙 네트워크들 (1215A 및 1215B) 로 대체된다는 점을 제외하고는, 도 12a 와 유사하다.
도 12b 에서, 서빙 네트워크 (1215A) 는 서빙 네트워크 (1215A) 가 UE 2 를 서빙하고 있지 않기 때문에, DE-MUX1 및/또는 DE-MUX2 를 UE 2 로 직접 송신하지 않는다. 대신, 서빙 네트워크 (1215A) 는 DE-MUX1 및 DE-MUX2 를 서빙 네트워크 (1215B) 로 전달하기 위해 NAT / 방화벽 통과 기법들을 이용하여 NAT / 방화벽 (1220) 을 통과하는 적어도 하나의 접속을 뚫거나 또는 개방시킨다. 일 예에서, 서빙 네트워크 (1215A) 는, DE-MUX1 및 DE-MUX2 양쪽을 서빙 네트워크 (1215B) 로 전달하는데, 단일 IP 어드레스 및 포트 번호가 사용될 수 있도록 DE-MUX1 및 DE-MUX2 를 단일 스트림으로 번들링할 수 있으며, 이에 의해 서빙 네트워크 (1215B) 가 그후 그 단일 스트림을 디-번들링하여 DE-MUX1 및 DE-MUX2 를 재구성한다. 대안적으로, 서빙 네트워크 (1215A) 는 DE-MUX1 및 DE-MUX2 에 대해 2개의 별개의 IP 어드레스들 및 포트 번호들을 단지 사용할 수 있다. 어쨌든, 설령 QoS 가 서빙 네트워크 (1215A) 로부터 서빙 네트워크 (1215B) 까지의 트렁크 상에서 이용불가능하더라도, 종단간 WebRTC 매체들 전송의 일부가 QoS 를 할당받도록 QoS 가 적어도 서빙 네트워크들 내에서 획득된다.
서빙 네트워크 (1215B) 는 DE-MUX1을 UE 2 로 UE 2 의 QoS 링크 상에서 송신하고, DE-MUX2 를 UE 2 로 UE 2 의 비-QoS 링크 상에서 송신한다. 제 2 WebRTC 프록시 모듈 (1210) 은 DE-MUX1 및 DE-MUX2 를 수신하고, 그후 DE-MUX1 및 DE-MUX2 를 "재"-멀티플렉싱하여 제 1 WebRTC 멀티미디어 클라이언트 애플리케이션 (1205) 에 의해 제 1 WebRTC 프록시 모듈 (1210) 에 처음에 제공된 멀티플렉싱된 스트림 ("MUX") 을 복원하거나 또는 재구성한다. 다시 말해서, 제 2 WebRTC 프록시 모듈 (1235) 은 MUX (예컨대, MUX 의 원래 버전 또는 MUX 의 상이한 버전, 예컨대 원래 MUX 로부터의 미디어 컴포넌트들의 일부 또는 모두의 압축된 버전들, 등을 포함한, MUX 의 압축된 또는 감소된-해상도 버전) 를 재구성하기 위해, 제 1 WebRTC 프록시 모듈 (1210) 에 의해 수행되는 디-멀티플렉싱 프로시저를 역전시킨다. 제 2 WebRTC 프록시 모듈 (1235) 은 그후 그 재구성된 (또는, 재-멀티플렉싱된) MUX 를 WebRTC 멀티미디어 클라이언트 애플리케이션 (1230) 에 제공한다.
도 12a 내지 도 12b 의 WebRTC 스트림들과 관련하여 설명된 디-멀티플렉싱 및 재-멀티플렉싱 동작들은, UE들 1 및 2 가 상위-우선순위 디-멀티플렉싱된 WebRTC 흐름, 또는 DE-MUX1 을 운반하기 위해 QoS 링크를 획득가능하다는 것에 기초한다. 도 12a 내지 도 12b 에서, QoS 링크가 이용가능하지만, 일반적으로, 부분적으로, MUX 가 벌크 비디오 콘텐츠와 같은, QoS 를 수신하지 않을 컴포넌트들을 포함하기 때문에, 그리고 또한 WebRTC 멀티미디어 클라이언트 애플리케이션이 심지어 그의 개개의 UE 에서 이용가능한 QoS 리소스들을 식별하는 능력을 반드시 가지지는 않기 때문에, WebRTC 멀티미디어 클라이언트 애플리케이션이 MUX 에 대해 QoS 를 획득하려고 시도하지 않는다고 단지 가정된다.
이를 감안하여, 도 13 내지 도 17 은 본 발명의 실시형태들에 따른, 위에서 설명된 디-멀티플렉싱 및/또는 재-멀티플렉싱 동작들과 함께 WebRTC 세션에 대해 QoS 를 선택적으로 설정하는 프로세스들을 예시한다. 특히, 도 13 은 본 발명의 일 실시형태에 따른, WebRTC 세션에 대한 QoS 링크을 설정하고 뒤이어서 WebRTC 세션에서 소스 UE 에서 디-멀티플렉싱하는 하이-레벨 프로세스를 예시한다.
도 13 과 관련하여, 시그널링은 주어진 UE 에 제공된 WebRTC 멀티미디어 클라이언트 애플리케이션 (예컨대, 도 12a 또는 도 12b 의 제 1 WebRTC 멀티미디어 클라이언트 애플리케이션 (1205) 또는 제 2 WebRTC 멀티미디어 클라이언트 애플리케이션 (1230)), 주어진 UE 에 제공된 WebRTC 프록시 모듈, 주어진 UE 를 서빙하고 있는 RAN (120), 코어 네트워크 (140) 및/또는 주어진 UE 와 관련된 WebRTC 세션의 개시 또는 잠재적인 개시를 표시하는 애플리케이션 서버 (170) 사이에 교환된다 (1300). 1300 으로부터의 시그널링에 기초하여, 주어진 UE 상의 WebRTC 프록시 모듈, RAN (120), 코어 네트워크 (140) 및/또는 애플리케이션 서버 (170) 는 1305, 1310, 1315 또는 1320 에서 QoS 링크를 주어진 UE 에 할당하기 위한 QoS 셋업 프로시저를 각각 개시한다.
일 예에서, 1300 에서, WebRTC 세션은 주어진 UE 에 의해 시작될 수도 있으며, 이 경우, 1300 의 시그널링은 WebRTC 멀티미디어 클라이언트 애플리케이션에 의해 발생되어 1305 에서 UE-개시되는 QoS 에 대해 WebRTC 프록시 모듈에 의해 인터셉트되는 세션 개시 메시지를 포함할 수 있다. 이 경우, 1305 는 도 5 내지 도 6c 와 관련하여 위에서 설명된 UE-개시되는 QoS 프로시저들과 다소 유사하며, 도 14 에서 특히 WebRTC 디-멀티플렉싱 구현예에 대해 아래에서 좀더 자세히 설명된다. 대안적으로, 1305 의 UE-개시되는 QoS 프로시저는 WebRTC 세션이 상이한 UE 에 의해 시작되는 시나리오에서 구현될 수 있다. 이 경우, WebRTC 세션에 대한 세션 어나운스먼트 메시지 및/또는 WebRTC 멀티미디어 클라이언트 애플리케이션에 의해 송신된 세션 수용 메시지가 UE-개시되는 QoS 프로시저를 트리거하기 위해 주어진 UE 에서의 WebRTC 프록시 모듈에 의해 사용될 수 있다.
추가적인 예에서, 1305 는 주어진 UE 가 그를 대신하여 QoS 를 셋업하도록 RAN (120) 및/또는 코어 네트워크 (140) 를 트리거하는 UE-개시되는 QoS 프로시저로서 구현될 필요가 없다. 대신, 다른 LTE-특정의 실시형태에서, WebRTC 프록시 모듈은 다른 종점이 VoLTE 호환가능하고 및/또는 그 자신의 WebRTC 프록시 모듈을 실행하고 있으면, 그 대신에 종단간 VoLTE 접속을 협상할 수 있다. 이와 같이 종단간 VoLTE 접속들을 확립하는 것은 WebRTC 에 대한 QoS 베어러 협상의 유연성을 제한하지만, 또한 UE-개시되는 및/또는 NW-개시되는 QoS 프로시저들을 구현할 필요성을 제거한다. 본원에서 사용될 때, QoS 셋업을 위한 종단간 VoLTE 구현예는 "프록시-개시되는" QoS 프로시저로서 지칭된다.
다른 예에서, 1300 에서, WebRTC 세션은 주어진 UE 에 의해 시작될 수도 있으며, 이 경우, 1300 의 시그널링은 WebRTC 멀티미디어 클라이언트 애플리케이션에 의해 발생되어 WebRTC 프록시 모듈에 의해 인터셉트되는 세션 개시 메시지를 포함할 수 있다. WebRTC 프록시 모듈은 그후 1320 에서 주어진 UE 가 QoS 링크를 할당받도록 초래하는 NW-개시되는 QoS 프로시저를 구현하도록 애플리케이션 서버 (170) 에게 프롬프트하기 위해 메시지를 애플리케이션 서버 (170) 로 전송한다. 이 경우, 1320 은 도 7a 내지 도 7c 에 대해 위에서 설명된 서버-기반의 NW-개시되는 QoS 프로시저들과 다소 유사하며, 도 15 에서 특히 WebRTC 디-멀티플렉싱 구현예에 대해 아래에서 좀더 자세히 설명된다. 대안적으로, 1320 의 서버-기반의 NW-개시되는 QoS 프로시저는 WebRTC 세션이 상이한 UE 에 의해 시작되는 시나리오에서 구현될 수 있다. 이 경우, WebRTC 세션에 대한 세션 어나운스먼트 메시지 및/또는 WebRTC 멀티미디어 클라이언트 애플리케이션에 의해 송신된 세션 수용 메시지가, 애플리케이션 서버 (170) 에게 서버-기반의 NW-개시되는 QoS 프로시저를 시작하도록 프롬프트하는 메시지를 애플리케이션 서버 (170) 로 트리거하기 위해 주어진 UE 에서의 WebRTC 프록시 모듈에 의해 사용될 수 있다.
다른 예에서, 1300 에서, 주어진 UE 가 WebRTC 세션의 발신자인지 여부에 관계 없이, RAN (120) 및/또는 코어 네트워크 (140) 는 애플리케이션-식별 정보를 평가할 수 있으며 및/또는 1310 및/또는 1315 에서 NW-개시되는 QoS 프로시저를 트리거하기 위해 심층-패킷 검사를 수행할 수 있다. 예를 들어, WebRTC 세션은 도 8a 내지 도 10b 에 대해 위에서 설명된 바와 같이 RAN (120) 및/또는 코어 네트워크에서 QoS 셋업을 트리거하는 App* 세션으로서 해석될 수 있다. 다른 예에서, WebRTC 트래픽 중 임의의 트래픽이 RAN (120) 및/또는 코어 네트워크 (140) 에 의한 심층-패킷 검사를 통해서 검사될 수 있다. 이 경우, RAN (120) 및/또는 코어 네트워크 (140) 가 그 세션을 WebRTC 에 관련되는 것으로 식별하면, RAN (120) 및/또는 코어 네트워크 (140) 는 QoS 링크를 주어진 UE 에 할당하는 NW-개시되는 QoS 프로시저를 트리거할 수 있다. 1310 및 1315 의 양태들은 도 8a 내지 도 10b 에 대해 위에서 설명된 NW-개시되는 QoS 프로시저들과 다소 유사하며, 도 16 에서 특히 WebRTC 디-멀티플렉싱 구현예에 대해 좀더 상세히 아래에서 설명된다.
따라서, 1305, 1310, 1315 및/또는 1320 가 구현된 후, 주어진 UE 는 QoS 링크 및 비-QoS 링크 양쪽을 할당받는다 (1325). WebRTC 멀티미디어 클라이언트 애플리케이션은 WebRTC 세션 동안 송신을 위해 상이한 유형들의 매체들 (예컨대, 오디오, 비디오, 등) 을 획득하고 (1330), WebRTC 멀티미디어 클라이언트 애플리케이션은 상이한 유형들의 매체들을 멀티플렉스 스트림 ("MUX") 로 멀티플렉싱한다 (1335). MUX 를 송신하려고 시도하는 동안, 주어진 UE 상의 WebRTC 프록시 모듈에 의해 MUX 가 그 대신에 인터셉트된다 (1340). WebRTC 프록시 모듈은 위에서 설명된 일련의 QoS 규칙들을 실행하여 MUX 내에 포함된 상위-우선순위 매체들 (예컨대, 오디오 미디어, 제한된 양의 비디오 미디어, 등) 을 식별한다 (1345). WebRTC 프록시 모듈은 그후 1345 에서 식별된 상위-우선순위 매체들을 디-멀티플렉싱하여, 상위-우선순위 매체들을 포함하는 제 1 디-멀티플렉싱된 WebRTC 스트림 ("DE-MUX1") 및 임의의 나머지 하위-우선순위 매체들을 포함하는 제 2 디-멀티플렉싱된 WebRTC 스트림 ("DE-MUX2") 을 발생한다 (1350). WebRTC 프록시 모듈은 DE-MUX1 를 RAN (120) 로 QoS 링크를 통해서 송신하고 (1355), WebRTC 프록시 모듈은 또한 DE-MUX2 를 RAN (120) 으로 비-QoS 링크 상에서 송신한다 (1360). 도 13 에 명시적으로 도시되지는 않지만, DE-MUX1 및 DE-MUX2 는 그후 도 12a 내지 도 12b 에서와 같이 타겟 UE (도 13 에 미도시) 로 전달될 수 있으며, 또한 아래에서 도 17 과 관련하여 좀더 자세히 설명된다.
도 14 는 본 발명의 일 실시형태에 따른, UE-유래된 WebRTC 세션에 대한 서버-기반의 NW-개시되는 QoS 프로시저에 기초한 도 13 의 프로세스의 LTE-특정의 구현예를 예시한다.
도 14 를 참조하면, 주어진 UE 상의 WebRTC 웹 브라우징 애플리케이션 ("브라우저") 이 WebRTC 프록시 모듈에 의해 인터셉트되는 콜 개시 메시지를 전송할 때 (1405), 주어진 UE 는 RRC-휴지 상태에 있다 (1400). 콜 개시 메시지의 수신은 애플리케이션 서버 (170) 가 NW-개시되는 QoS 프로시저를 트리거하도록 요청하기 위해, 사유 메시지 (proprietary message) 를 애플리케이션 서버 (170) 로 전송하도록 WebRTC 프록시 모듈을 트리거한다 (1410). 사유 메시지에 응답하여, 애플리케이션 서버 (170) 는 P-GW (235D) 및 PCRF (240D) 에의 Rx 접속을 통해서 베어러 협상을 개시한다 (1415).
주어진 UE 로 되돌아가서, 콜 개시 메시지의 수신은 또한 주어진 UE 를 RRC-휴지 상태로부터 RRC-접속된 상태로 전이시키기 위해 RRC 셋업 프로시저를 수행하도록 주어진 UE 를 트리거한다 (1420). 1420 에서 RRC 셋업이 완료될 때, 주어진 UE 가 RRC-접속된 상태에 진입하고 (1425), 그리고 WebRTC 프록시 모듈이 접속 표시를 브라우저로 전달한다 (1430). 여기서, 주어진 UE 는 비-GBR 베어러 (즉, 비-QoS 링크) 를 갖지만, 베어러 협상이 아직 완료되지 않았기 때문에 여전히 QoS 링크를 갖지 않는다 (1432). 브라우저 및 WebRTC 프록시 모듈이 제안/응답 교환을 실행하며 (1435) (예컨대, 이에 의해 WebRTC 프록시 모듈이 DE-MUX1 및/또는 DE-MUX2 에 사용될 트랜스코딩 코덱을 선택할 수 있다), 그후 브라우저가 WebRTC 세션 동안 송신을 위해 매체들을 구성하기 시작한다 (1440).
네트워크로 되돌아가면, P-GW (235D) 는 베어러 업데이트 요청 (update bearer request) 을 MME (215D) 로 전송하고 (1445), MME (215D) 는 베어러 수정 요청 (bearer modify request) 을 eNB (205D) 로 전송하여 (1450), eNB (205D) 및 주어진 UE 로 하여금, RRC 접속을 재구성하도록 프롬프트한다 (1455) (예컨대, RRC 접속 재구성 / 완료). eNB (205D) 가 그후 베어러 수정 응답 (bearer modify response) 을 MME (215D) 로 되송신하고, MME (215D) 가 베어러 업데이트 응답 (update bearer response) 을 P-GW (235D) 로 되송신한다. 상이하게 트리거되지만, 1445-1465 는 도 7c 의 725C-750C 와 다소 유사한다. 또한, WebRTC 세션이 App* 세션이면, GBR 베어러에 대해 설정된 GBR 은 App* (또는, 이 경우, WebRTC) 에 고유한 QoS 구성으로 도 7c 의 735C 에서와 같이 구성될 수 있다.
1445-1465 의 시그널링을 통해서 GBR 베어러 (또는, QoS 링크) 를 획득한 후, 브라우저는 MUX (예컨대, 송신을 위한 멀티플렉싱된 미디어 컴포넌트들을 가진 RTP/RTCP 패킷들의 스트림) 를 WebRTC 프록시 모듈로 송신하기 시작하며 (1470), WebRTC 프록시 모듈은 MUX 를 디-멀티플렉싱하여 DE-MUX1 및 DE-MUX2 를 발생시키고 그후 DE-MUX1 를 GBR 베어러 상에서 송신하고 (1475), DE-MUX2 를 비-GBR 베어러 상에서 송신한다 (1480).
도 15 는 본 발명의 일 실시형태에 따른, UE-개시되는 QoS 프로시저에 기초한 도 13 의 프로세스의 LTE-특정의 구현예를 예시한다.
도 15 를 참조하면, 주어진 UE 상의 WebRTC 웹 브라우징 애플리케이션 ("브라우저") 이 WebRTC 프록시 모듈에 의해 인터셉트되는 콜 개시 메시지를 전송할 때 (1505), 주어진 UE 는 RRC-휴지 상태에 있다 (1500). 콜 개시 메시지는 주어진 UE 를 RRC-휴지 상태로부터 RRC-접속된 상태로 전이시키기 위해 RRC 셋업 프로시저를 수행하도록 주어진 UE 를 트리거한다 (1510). 1510 에서 RRC 셋업이 완료될 때, 주어진 UE 는 RRC-접속된 상태에 진입하고 (1515), WebRTC 프록시 모듈은 접속 표시를 브라우저로 전달한다 (1520). 여기서, 주어진 UE 는 비-GBR 베어러 (즉, 비-QoS 링크) 를 갖지만 베어러 협상이 아직 완료되지 않았기 때문에 QoS 링크를 여전히 가지지 않는다 (1525).
도 15 의 실시형태에서, WebRTC 프록시 모듈은 QoS 링크를 획득하기 위해 UE-개시되는 QoS 프로시저를 실행하기로 결정한다. 일 예에서, 도 14 에서와 같은 NW-개시되는 QoS 프로시저가 QoS 링크를 획득하는데 실패하면, UE-개시되는 QoS 프로시저가 폴백 메커니즘으로서 사용될 수 있다. 예를 들어, 도 15 에 나타내지는 않지만, WebRTC 프록시 모듈은 도 14 의 1410 에서와 같이 사유 메시지를 전송하고 그후 타이머를 시작할 수 있으며, QoS 링크가 타이머의 만료 전에 획득되지 않으면, WebRTC 프록시 모듈이 UE-개시되는 QoS 프로시저를 실행할 수 있다. 대안적으로, WebRTC 프록시 모듈은 세션-유형이 WebRTC 이라는 것에 기초하여, NW-개시되는 QoS 프로시저를 먼저 시도하기를 대기하지 않고 UE-개시되는 QoS 프로시저를 실행하기로 자동적으로 결정할 수 있다.
어쨌든, 어떻게 WebRTC 프록시 모듈이 UE-개시되는 QoS 프로시저를 구현하는 결정에 도달하는지에 관계없이, UE-개시되는 QoS 프로시저는 베어러 리소스 변경 요청 메시지 (Request Bearer Resource Modification message) 를 주어진 UE 로부터 eNB (205D) 를 통해서 MME (215D) 로 송신함으로써 구현된다 (1530). 1530 의 베어러 리소스 변경 요청 메시지는 WebRTC 세션의 오디오 미디어 컴포넌트 (예컨대, 잠재적으로는, 제한된 양의 비디오 미디어 및/또는 파일 콘텐츠와 같은, 다른 미디어 컴포넌트들도 또한) 에 대한 GBR 베어러를 요청하도록 구성된다. MME (215D) 는 베어러 리소스 변경 요청 메시지를 수신하고, 베어러 리소스 지령을 P-GW (235D) 로 S-GW (230D) 를 통해서 전달한다 (1535). 여기서, 1540-1585 는 1540-1585 가 주어진 UE 에 의해 LTE 코어 네트워크 (140) 로 전달되는 메시지에 의해 트리거되는 반면, 1435-1480 이 애플리케이션 서버 (170) 에 의해 LTE 코어 네트워크 (140) 로 전달되는 메시지에 의해 트리거된다는 점을 제외하고는, 도 14 의 1435-1480 에 각각 실질적으로 대응한다.
도 16 은 본 발명의 일 실시형태에 따른, 다른 NW-개시되는 QoS 프로시저에 기초한 도 13 의 프로세스의 부분의 예시적인 구현예를 예시한다. 도 16 을 참조하면, 도 13 의 1300 에서 교환된 시그널링에 기초하여, RAN (120) 및/또는 코어 네트워크 (140) 는, (도 14 에서와 같이) 애플리케이션 서버 (170) 또는 (도 15에서와 같이) 주어진 UE 자체로부터 제공되는, 주어진 UE 에 대한 QoS 링크의 셋업을 트리거하라는 명시적인 요청 없이, 주어진 UE 에 대한 QoS 링크의 셋업을 트리거한다. 대신, RAN (120) 및/또는 코어 네트워크 (140) 는 시그널링 자체를 평가하여, (예컨대, 도 13 의 1310 및/또는 1315 와 유사하게) RAN (120) 및/또는 코어 네트워크 (140) 가 주어진 UE 에 대신하여 QoS 링크를 우선적으로 셋업해야 하는지 여부를 검출한다 (1600).
특히, RAN (120) 및/또는 코어 네트워크 (140) 는 확립 중인 세션이 WebRTC 이라고 식별할 수 있으며, 이 식별은 RAN (120) 및/또는 코어 네트워크 (140) 에게 NW-개시되는 QoS 프로시저를 트리거하도록 프롬프트할 수 있다. WebRTC 세션로서의 세션의 식별은 다수의 방법들로 수행될 수 있다. 예를 들어, WebRTC 애플리케이션은 위에서 자세하게 설명된 App* 에 대응할 수 있으며, 그 결과 세션의 WebRTC 성질이 애플리케이션-식별 정보 (예컨대, APN, 등) 에 기초하여 식별될 수 있다. 다른 예에서, RAN (120) 및/또는 코어 네트워크 (140) 는 WebRTC 세션의 셋업 동안 교환되는 하나 이상의 시그널링 패킷들에 대해 심층-패킷 검사를 수행할 수 있으며, 그 세션이 WebRTC 세션이라고 추론하는데 심층-패킷 검사가 이용될 수도 있다. 1600 에서 평가되는 시그널링은 업링크 및/또는 다운링크 시그널링 트래픽과 연관될 수 있다.
도 13 은 소스 UE 에서 WebRTC 세션에서 발생하는 디-멀티플렉싱에 집중하지만, 도 17 은 WebRTC 세션에 대한 QoS 링크를 설정하는 것에 뒤이어서 타겟 UE 에서 WebRTC 세션에서 재-멀티플렉싱하는 하이-레벨 프로세스에 관련된다. 물론, WebRTC 에서 UE 는 양방향 또는 2-방향 매체들 세션에 대해 소스 UE 및 타겟 UE 양자일 수 있으며, 그 결과 도 13 및 도 17 의 프로세스들이 소스 및 타겟 UE들 양쪽에서 병렬로 구현될 수 있다.
도 17 을 참조하면, 1700-1725 는 1300-1325 에 대응하며, 간결성을 위해 추가로 설명되지 않을 것이다. 1725 이후, 코어 네트워크 (140) 는 (예컨대, 도 12a 에서와 동일한 코어 네트워크 (140) 또는 도 12b 에서와 상이한 서빙 네트워크에 의해 서빙되는) 다른 UE 로부터 DE-MUX1 및 DE-MUX2 를 획득한다. 1730 에서, 코어 네트워크 (140) 는 RAN (120) 를 통해서, DE-MUX1 를 주어진 UE 로 QoS 링크 상에서, 그리고, DE-MUX2 를 주어진 UE 로 비-QoS 링크 상에서 송신한다 (1730). WebRTC 프록시 모듈은 WebRTC 멀티미디어 클라이언트 애플리케이션으로의 그들의 전달 전에 DE-MUX1 및 DE-MUX2 를 인터셉트하고 (1735), WebRTC 프록시 모듈은 DE-MUX1 및 DE-MUX2 를 재-멀티플렉싱하여 MUX 를 재구성한다 (1740). 다른 말로 하자면, 위에서 설명한 바와 같이, WebRTC 프록시 모듈은, 다른 UE 상의 WebRTC 멀티미디어 클라이언트 애플리케이션에 의해 처음에 준비된 바와 같은 MUX 를 재획득하기 위해 다른 UE 상의 WebRTC 프록시 모듈에 의해 수행되는 디-멀티플렉싱함으로써 MUX 를 재구성한다. WebRTC 프록시 모듈은 그후 MUX 를 WebRTC 멀티미디어 클라이언트 애플리케이션로 주어진 UE 상에서 전달한다 (1745).
또, 도 14 내지 도 16 은 QoS 링크가 어떻게 "디"-멀티플렉싱 상황에서 주어진 UE 에 대해 확립되는지에 대해, 도 13 의 프로세스의 상세한 구현예들을 설명하지만, 이들 동일한 QoS 셋업 프로시저들이 "재"-멀티플렉싱 컨텍스트에 대해 도 17 의 상황에서 사용될 수 있음을 명백히 알 수 있을 것이다. 다시 말해서, 1700-1725 사이에 확립된 QoS 링크는 도 14 에서와 같은 서버-기반의 NW-개시되는 QoS 프로시저, 도 15 에서와 같은 UE-개시되는 QoS 프로시저를 통해서, 및/또는 도 16 에서와 같은 서버-기반의 트리거와는 독립적인 NW-개시되는 QoS 프로시저에 의해 셋업될 수 있다. 또한, 위에서 언급한 바와 같이, 동일한 UE 는, 주어진 UE 에 제공된 WebRTC 프록시 모듈이 도 13 에서와 같이 유출 MUX 를 디-멀티플렉싱하는 것을, 또한 도 17 에서와 같이 다른 UE 로부터 인입 MUX 를 재구성하기 위해 인입 디-멀티플렉싱된 스트림을 재-멀티플렉싱하는 것을 담당할 수 있도록, 도 13 및 도 17 의 프로세스들 양자를 병렬로 수행할 수 있다.
또, 도 12a 내지 도 17 의 실시형태들이 "원래" 또는 "소스" MUX 및 "재-멀티플렉싱된" 또는 "재구성된" MUX 를 지칭하지만, MUX 의 원래 및 재구성된 버전들이 동일할 수 있거나 또는 대안적으로, 다소 상이할 수 있음 (예컨대, 재구성된 MUX 는 트랜스코딩 또는 다른 인자들, 등으로 인해 원래 MUX 에 비해 어떤 미디어 컴포넌트들에 대해 낮은 해상도를 갖도록 압축될 수도 있다) 을 명백히 알 수 있을 것이다.
또, 도 12a 내지 도 17 의 실시형태들은 일반적으로 2개 (2) 의 디-멀티플렉싱된 스트림들 (즉, DE-MUX1 및 DE-MUX2) 을 지칭하지만, 다른 실시형태들이 가용 QoS 및/또는 비-QoS 링크들의 개수에 따라서, 3개 (3) 또는 더 많은 디-멀티플렉싱된 스트림들 (예컨대, DE-MUX3, DE-MUX4, 등) 에 관련될 수 있음을 명백히 알 수 있을 것이다. 예를 들어, UE 가 높은 QoS 를 갖는 제 1 QoS 링크, 낮은 QoS 를 가진 제 2 QoS 링크 및 비-QoS 링크에 액세스하지만, WebRTC 프록시 모듈은 높은 우선순위 매체들을 가진 DE-MUX1, 중간-우선순위 매체들을 가진 DE-MUX2 및 낮은 우선순위 매체들을 가진 DE-MUX3 을 발생시킬 수 있다. WebRTC 프록시 모듈은 그후 DE-MUX1 를 제 1 QoS 링크 상에서, DE-MUX2 를 제 2 QoS 링크 상에서, 그리고 DE-MUX3 을 비-QoS 링크 상에서, 등등으로 전송할 수 있다.
추가적인 예에서, QoS 링크는 제 1 세트의 링크들에 대응할 수 있으며, 비-QoS 링크는 제 2 세트의 링크들에 대응할 수 있다. 제 1 세트의 링크들은 하나 이상의 QoS 링크들을 포함할 수 있으며, 제 2 세트의 링크들은 하나 이상의 비-QoS 링크들을 포함할 수 있다. 제 1 세트의 링크들에서의 각각의 링크는 DE-MUX 스트림을 운반할 수 있으며, 제 2 세트의 링크들에서의 각각의 링크는 또한 DE-MUX 스트림을 운반할 수 있다. 일반적으로, 상위-우선순위 매체들은 DE-MUX 스트림(들) 를 통해서 제 1 세트의 링크들 상에서 전송되는 반면, 하위-우선순위 매체들은 DE-MUX 스트림(들) 을 통해서 제 2 세트의 링크들 상에서 전송된다. 따라서, UE 가 다수의 QoS 링크들 및/또는 다수의 비-QoS 링크들에 액세스하는 시나리오들에서, UE 는 이들 다수의 링크들을 레버리지하여, 다수의 DE-MUX 스트림들을 (또는, 심지어 동일한 DE-MUX 스트림도 여분으로) 전송할 수 있다. 이에 의해, 실시형태들은 추가적인 링크들 (QoS 및/또는 비-QoS) 이 이용가능할 때 단일 DE-MUX 스트림이 QoS 링크 상에서 전송되는 것 및 단일 DE-MUX 스트림이 비-QoS 링크 상에서 전송되는 것에 한정되지 않는다. 특히, MUX 로부터의 추가적인 디-멀티플렉싱된 미디어 컴포넌트들은 전술한 '여분의' DE-MUX 스트림들 중 임의의 스트림 상에서 운반될 수 있다. 이와 유사하게, 타겟 UE 에서, '여분의' DE-MUX 스트림들 중 임의의 스트림은 MUX 를 재구성하기 위해 DE-MUX1 및 DE-MUX2 와 함께 재-멀티플렉싱될 수 있다.
본 발명의 다른 실시형태에서, 브라우저-유래된 멀티미디어 트래픽이 멀티플렉싱되지 않거나, 또는 부분적으로 멀티플렉싱되는 것이 가능하다. 다시 말해서, WebRTC 멀티미디어 클라이언트 애플리케이션으로부터의 출력은 MUX 일 필요는 없으며, 비-MUX1 및 비-MUX2 (즉, 2개의 비-멀티플렉싱된 RTP 스트림들), MUX1 및 MUX2 (예컨대, 2개의 부분적으로 멀티플렉싱된 RTP 스트림들), 또는 비-MUX1 및 MUX1 (예컨대, 비-멀티플렉싱된 RTP 스트림 및 멀티플렉싱된 RTP 스트림) 일 수 있다. 이들 경우들에서, WebRTC 프록시 모듈은 비-QoS 및 QoS 링크들에의 개개의 RTP 스트림들의 맵핑을 여전히 처리할 수 있다. 일 예로서, 브라우저가 오디오 트래픽을 하나의 RTP 스트림을 통해서 전송/수신하고 또한 다수의 비디오 트랙들을 다른 RTP 스트림을 통해서 전송/수신하는 다자 비디오 콜을 가정한다 (여기서, 비디오 트랙들은 콜에서 각각의 참가자에 고유할 것이다). WebRTC 프록시 모듈은 UE 가 QoS 및 비-QoS 링크들 양자에 액세스하는 것을 인식할 수도 있지만, 브라우저 (또는, WebRTC 멀티미디어 클라이언트 애플리케이션) 는 이 정보를 검출하는 능력을 반드시 갖지는 않는다. 따라서, WebRTC 멀티미디어 클라이언트 애플리케이션들은 디-멀티플렉싱을 필요로 하지 않는 RTP 스트림들을 발생시킬 수 있지만, WebRTC 프록시 모듈은, 디-멀티플렉싱 동작을 수행하는 대신, 개개의 RTP 스트림들을 적합한 링크 (즉, QoS 링크 또는 비-QoS 링크) 에 간단히 맵핑한다.
상기 실시형태들은 CDMA2000 네트워크들에서의 1x EV-DO 아키텍처, W-CDMA 또는 UMTS 네트워크들에서의 GPRS 아키텍처 및/또는 LTE-기반의 네트워크들에서의 EPS 아키텍처를 주로 참조하여 설명되었지만, 다른 실시형태들은 다른 유형들의 네트워크 아키텍쳐들 및/또는 프로토콜들에 관련될 수 있음을 명백히 알 수 있을 것이다.
당업자들은, 정보 및 신호들이 다양한 상이한 기술들 및 기법들 중 어느 것을 이용하여서도 표현될 수도 있다는 것을 알 수 있을 것이다. 예를 들어, 상기 설명 전반에 걸쳐서 인용될 수도 있는 데이터, 명령들, 지령들, 정보, 신호들, 비트들, 심볼들 및 칩들은, 전압들, 전류들, 전자기파들, 자기장들 또는 자기 입자들, 광학장들 또는 광학 입자들, 또는 이들의 임의의 조합으로 표현될 수도 있다.
또, 당업자들은, 본원에서 개시한 실시형태들과 관련하여 설명되는 여러가지 예시적인 로직 블록들, 모듈들, 회로들, 및 알고리즘 단계들이 전자적 하드웨어, 컴퓨터 소프트웨어, 또는 양쪽의 조합들로서 구현될 수도 있음을 명확히 알 수 있을 것이다. 이러한 하드웨어와 소프트웨어의 상호 교환가능성을 명확히 예시하기 위하여, 이상에서는, 여러 예시적인 컴포넌트들, 블록들, 모듈들, 회로들 및 단계들을 그들의 기능의 관점에서 일반적으로 설명되었다. 이런 기능이 하드웨어 또는 소프트웨어로 구현되는지 여부는 특정의 애플리케이션 및 전체 시스템에 부과되는 설계 제한 사항들에 의존한다. 숙련자들은 각각의 특정의 애플리케이션 마다 설명한 기능을 여러가지 방법으로 구현할 수도 있으며, 그러나 이런 구현 결정들이 본 발명의 범위로부터 일탈을 초래하는 것으로 해석되어서는 안된다.
본원에서 개시된 실시형태들과 관련하여 설명되는 여러가지 예시적인 로직 블록들, 모듈들, 및 회로들은, 범용 프로세서, 디지털 신호 프로세서 (DSP), 주문형 집적회로 (ASIC), 필드 프로그래밍가능 게이트 어레이 (FPGA) 또는 다른 프로그래밍가능 로직 디바이스, 이산 게이트 또는 트랜지스터 로직, 이산 하드웨어 컴포넌트들 또는 본원에서 설명한 기능들을 수행하도록 설계된 이들의 임의의 조합으로 구현되거나 또는 수행될 수도 있다. 범용 프로세서는 마이크로프로세서일 수도 있으며, 그러나 대안적으로는, 프로세서는 임의의 종래의 프로세서, 제어기, 마이크로제어기 또는 상태 머신일 수도 있다. 프로세서는 또한 컴퓨팅 디바이스들의 조합, 예컨대, DSP 와 마이크로프로세서의 조합, 복수의 마이크로프로세서들, DSP 코어와 결합된 하나 이상의 마이크로프로세서들, 또는 임의의 다른 이러한 구성으로서 구현될 수도 있다.
본원에서 개시되는 실시형태들과 관련하여 설명되는 방법들, 시퀀스들 또는 알고리즘들은 하드웨어로 직접, 프로세서에 의해 실행되는 소프트웨어 모듈로, 또는 이 둘의 조합으로 구현될 수도 있다. 소프트웨어 모듈은 RAM 메모리, 플래시 메모리, ROM 메모리, EPROM 메모리, EEPROM 메모리, 레지스터들, 하드 디스크, 착탈식 디스크, CD-ROM, 또는 당업계에 알려져 있는 임의의 다른 유형의 저장 매체에 상주할 수도 있다. 예시적인 저장매체는 프로세서가 저장 매체로부터 정보를 판독하고 저장 매체에 정보를 기록할 수 있도록 프로세서에 커플링된다. 대안적으로는, 저장 매체는 프로세서에 통합될 수도 있다. 프로세서 및 저장 매체는 ASIC 에 상주할 수도 있다. ASIC 는 사용자 단말기 (예컨대, UE) 에 상주할 수도 있다. 대안적으로는, 프로세서 및 저장 매체는 사용자 단말에 별개의 컴포넌트들로서 상주할 수도 있다.
하나 이상의 예시적인 실시형태들에서, 설명된 기능들은 하드웨어, 소프트웨어, 펌웨어 또는 이들의 임의의 조합으로 구현될 수도 있다. 소프트웨어로 구현되는 경우, 이 기능들은 컴퓨터-판독가능 매체 상에 하나 이상의 명령들 또는 코드로서 저장되거나 또는 전달될 수도 있다. 컴퓨터-판독가능 매체들은 한 장소로부터 또 다른 장소로 컴퓨터 프로그램의 전송을 용이하게 하는 임의의 매체를 포함한, 컴퓨터 저장 매체들 및 통신 매체들 양쪽을 포함한다. 저장 매체들은 컴퓨터에 의해 액세스될 수 있는 임의의 가용 매체들일 수 있다. 비한정적인 예로서, 이런 컴퓨터-판독가능 매체들은 RAM, ROM, EEPROM, CD-ROM 또는 다른 광디스크 스토리지, 자기디스크 스토리지 또는 다른 자기 저장 디바이스들, 또는 원하는 프로그램 코드를 명령들 또는 데이터 구조들의 형태로 전달하거나 또는 저장하는데 사용될 수 있고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 매체를 포함할 수 있다. 또한, 임의의 접속이 컴퓨터-판독가능 매체로 적절히 지칭된다. 예를 들어, 소프트웨어가 웹사이트, 서버, 또는 다른 원격 소스로부터 동축 케이블, 광섬유 케이블, 연선, 디지털 가입자 회선 (DSL), 또는 무선 기술들, 예컨대 적외선, 라디오, 및 마이크로파를 이용하여 송신되면, 동축 케이블, 광섬유 케이블, 연선, DSL, 또는 무선 기술들 예컨대 적외선, 라디오, 및 마이크로파가 그 매체의 정의에 포함된다. 디스크 (disk) 및 디스크 (disc) 는, 본원에서 사용할 때, 컴팩트 디스크 (CD), 레이저 디스크, 광 디스크, 디지털 다기능 디스크 (DVD), 플로피 디스크 및 Blu-ray 디스크를 포함하며, 디스크들 (disks) 은 데이터를 자기적으로 보통 재생하지만, 디스크들 (discs) 은 레이저로 데이터를 광학적으로 재생한다. 앞에서 언급한 것들의 결합들이 또한 컴퓨터-판독가능 매체들의 범위 내에 포함되어야 한다.
전술한 개시물은 본 발명의 예시적인 실시형태들을 나타내지만, 첨부된 청구범위에 의해 정의되는 바와 같은 본 발명의 범위로부터 일탈함이 없이 본원에서 여러 가지 변화들 및 변경들이 이루어질 수 있다는 점에 유의해야 한다. 본원에서 설명된 본 발명의 실시형태들에 따른, 방법 청구항들의 기능들, 단계들 및/또는 액션들은 임의의 특정의 순서로 수행될 필요가 없다. 더욱이, 본 발명의 엘리먼트들은 단수로 설명되거나 또는 청구될 수도 있지만, 그 단수에의 한정이 명시적으로 언급되지 않는 한, 복수가 고려된다.
Claims (35)
- 웹 실시간 통신 (WebRTC; Web Real-Time Communication) 세션에 참가되는 사용자 장비 (UE; user equipment) 에서 WebRTC 프록시 모듈을 동작시키는 방법으로서,
제 1 세트의 링크들 및 상기 제 1 세트의 링크들과는 상이한 제 2 세트의 링크들을 획득하는 단계로서, 상기 제 1 세트의 링크들에서의 각각의 링크에는 적어도 임계치 레벨의 서비스 품질 (QoS; Quality of Service) 이 할당되는, 상기 링크들을 획득하는 단계;
상기 WebRTC 세션 동안, WebRTC 멀티미디어 클라이언트 애플리케이션으로부터, 상기 WebRTC 멀티미디어 클라이언트 애플리케이션이 타겟 UE 상의 타겟 WebRTC 멀티미디어 클라이언트 애플리케이션으로 전달하려고 시도중이라는 멀티플렉싱된 스트림을 획득하는 단계로서, 상기 멀티플렉싱된 스트림은 제 1 미디어 컴포넌트 및 제 2 미디어 컴포넌트를 적어도 포함하는, 상기 멀티플렉싱된 스트림을 획득하는 단계;
상기 제 1 미디어 컴포넌트를 포함하는 제 1 디-멀티플렉싱된 스트림 및 상기 제 2 미디어 컴포넌트를 포함하는 제 2 디-멀티플렉싱된 스트림을 발생시키기 위해 상기 멀티플렉싱된 스트림을 디-멀티플렉싱하는 단계;
상기 타겟 UE 로의 전달을 위해 상기 제 1 세트의 링크들로부터의 제 1 링크 상에서 서빙 네트워크로 상기 제 1 디-멀티플렉싱된 스트림을 송신하는 단계; 및
상기 타겟 UE 로의 전달을 위해 상기 제 2 세트의 링크들로부터 제 2 링크 상에서 상기 서빙 네트워크로 상기 제 2 디-멀티플렉싱된 스트림을 송신하는 단계를 포함하는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 1 항에 있어서,
상기 제 2 세트의 링크들에서의 각각의 링크에는, 제로 QoS 또는 제로 QoS 보다 크고 상기 임계치 레벨의 QoS 미만인 중간 레벨의 QoS 가 할당되는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 2 항에 있어서,
상기 제 2 세트의 링크들에서의 적어도 하나의 링크에는 제로 QoS 가 할당되는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 2 항에 있어서,
상기 제 2 세트의 링크들에서의 적어도 하나의 링크에는 상기 중간 레벨의 QoS 가 할당되는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 2 항에 있어서,
상기 임계치 레벨의 QoS 는 상기 제 1 세트의 링크들에서의 각각의 링크에 대한 주어진 보장 비트 레이트 (GBR; Guaranteed Bit Rate) 를 적어도 포함하며,
상기 제 2 세트의 링크들에서의 각각의 링크는 제로 GBR 및/또는 상기 주어진 GBR 보다 낮은 GBR 을 갖는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 1 항에 있어서,
상기 제 1 세트의 링크들은 단지 상기 제 1 링크를 포함하며, 상기 제 2 세트의 링크들은 단지 상기 제 2 링크를 포함하는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 1 항에 있어서,
상기 제 1 세트의 링크들은 상기 제 1 링크 및 적어도 하나의 추가적인 링크를 포함하며,
상기 제 2 세트의 링크들은 단지 상기 제 2 링크를 포함하며,
상기 멀티플렉싱된 스트림은 적어도 하나의 추가적인 미디어 컴포넌트를 더 포함하며 상기 디-멀티플렉싱은 상기 멀티플렉싱된 스트림을 추가로 디-멀티플렉싱하여 상기 적어도 하나의 추가적인 미디어 컴포넌트를 포함하는 적어도 하나의 추가적인 디-멀티플렉싱된 스트림을 발생시키며,
상기 방법은:
상기 타겟 UE 로의 전달을 위해 상기 제 1 세트의 링크들로부터의 상기 적어도 하나의 추가적인 링크 상에서 상기 서빙 네트워크로 상기 적어도 하나의 추가적인 디-멀티플렉싱된 스트림을 송신하는 단계를 더 포함하는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 1 항에 있어서,
상기 제 2 세트의 링크들은 상기 제 2 링크 및 적어도 하나의 추가적인 링크를 포함하며,
상기 제 1 세트의 링크들은 단지 상기 제 1 링크를 포함하며,
상기 멀티플렉싱된 스트림은 적어도 하나의 추가적인 미디어 컴포넌트를 더 포함하며 상기 디-멀티플렉싱은 상기 멀티플렉싱된 스트림을 추가로 디-멀티플렉싱하여 상기 적어도 하나의 추가적인 미디어 컴포넌트를 포함하는 적어도 하나의 추가적인 디-멀티플렉싱된 스트림을 발생시키며,
상기 방법은:
상기 타겟 UE 로의 전달을 위해 상기 제 2 세트의 링크들로부터의 상기 적어도 하나의 추가적인 링크 상에서 상기 서빙 네트워크로 상기 적어도 하나의 추가적인 디-멀티플렉싱된 스트림을 송신하는 단계를 더 포함하는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 1 항에 있어서,
상기 제 1 세트의 링크들은 상기 제 1 링크 및 적어도 하나의 추가적인 링크를 포함하며,
상기 제 2 세트의 링크들은 상기 제 2 링크 및 하나 이상의 추가적인 링크들을 포함하며,
상기 멀티플렉싱된 스트림은 적어도 하나의 추가적인 미디어 컴포넌트를 더 포함하며 상기 디-멀티플렉싱은 상기 멀티플렉싱된 스트림을 추가로 디-멀티플렉싱하여 상기 적어도 하나의 추가적인 미디어 컴포넌트를 포함하는 적어도 하나의 추가적인 디-멀티플렉싱된 스트림을 발생시키며,
상기 멀티플렉싱된 스트림은 하나 이상의 추가적인 미디어 컴포넌트들을 더 포함하며 상기 디-멀티플렉싱은 상기 멀티플렉싱된 스트림을 추가로 디-멀티플렉싱하여 상기 하나 이상의 추가적인 미디어 컴포넌트들을 포함하는 하나 이상의 추가적인 디-멀티플렉싱된 스트림들을 발생시키며,
상기 방법은:
상기 타겟 UE 로의 전달을 위해 상기 제 1 세트의 링크들로부터의 상기 적어도 하나의 추가적인 링크 상에서 상기 서빙 네트워크로 상기 적어도 하나의 추가적인 디-멀티플렉싱된 스트림을 송신하는 단계; 및
상기 타겟 UE 로의 전달을 위해 상기 제 2 세트의 링크들로부터의 상기 하나 이상의 추가적인 링크들 상에서 상기 서빙 네트워크로 상기 하나 이상의 추가적인 디-멀티플렉싱된 스트림들을 송신하는 단계를 더 포함하는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 1 항에 있어서,
상기 제 1 미디어 컴포넌트는 상기 WebRTC 세션에 대한 오디오 미디어를 포함하며 상기 제 2 미디어 컴포넌트는 상기 WebRTC 세션에 대한 비디오 미디어를 포함하는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 1 항에 있어서,
상기 제 1 미디어 컴포넌트는 상기 WebRTC 세션에 대한 오디오 미디어 및 상위-우선순위 비디오 미디어를 포함하며,
상기 제 2 미디어 컴포넌트는 상기 WebRTC 세션에 대한 하위-우선순위 비디오 미디어를 포함하는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 1 항에 있어서,
상기 UE 및 상기 타겟 UE 는 상기 서빙 네트워크에 의해 각각 서빙되며,
상기 UE 와 상기 타겟 UE 사이의 종단간 접속은, 상기 UE 및 상기 타겟 UE 가 상기 서빙 네트워크에 의해 각각 서빙되는 것에 기초하여 네트워크간 네트워크 어드레스 변환 (NAT; Network Address Translation) 및/또는 네트워크간 방화벽을 통과하지 않는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 1 항에 있어서,
상기 타겟 UE 는 상기 UE 를 서빙하는 상기 서빙 네트워크와는 상이한 다른 서빙 네트워크에 의해 서빙되며,
상기 UE 와 상기 타겟 UE 사이의 종단간 접속은, 상기 UE 및 상기 타겟 UE 가 상이한 서빙 네트워크들에 의해 서빙되는 것에 기초하여 네트워크간 네트워크 어드레스 변환 (NAT) 및/또는 네트워크간 방화벽을 통과하는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 웹 실시간 통신 (WebRTC) 세션에 참가되는 사용자 장비 (UE) 에서 WebRTC 프록시 모듈을 동작시키는 방법으로서,
제 1 세트의 링크들 및 상기 제 1 세트의 링크들과는 상이한 제 2 세트의 링크들을 획득하는 단계로서, 상기 제 1 세트의 링크들에서의 각각의 링크에는 적어도 임계치 레벨의 서비스 품질 (QoS) 이 할당되는, 상기 링크들을 획득하는 단계;
상기 WebRTC 세션 동안, 상기 제 1 세트의 링크들로부터의 제 1 링크 상에서 서빙 네트워크로부터 제 1 스트림을 수신하고, 상기 제 2 세트의 링크들로부터의 제 2 링크 상에서 상기 서빙 네트워크로부터 제 2 스트림을 수신하는 단계로서, 상기 제 1 및 제 2 스트림들은 소스 UE 에서의 소스 WebRTC 멀티미디어 클라이언트 애플리케이션이 상기 UE 상의 WebRTC 멀티미디어 클라이언트 애플리케이션으로 전달하려고 시도중인 멀티플렉싱된 스트림의 디-멀티플렉싱된 부분들을 포함하는, 상기 수신하는 단계;
상기 멀티플렉싱된 스트림의 재구성된 버전을 생성하기 위해 상기 제 1 및 제 2 스트림들을 재-멀티플렉싱하는 단계; 및
상기 재-멀티플렉싱된 스트림을 상기 WebRTC 멀티미디어 클라이언트 애플리케이션으로 전달하는 단계를 포함하는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 14 항에 있어서,
상기 제 2 세트의 링크들에서의 각각의 링크에는, 제로 QoS 또는 제로 QoS 보다 크고 상기 임계치 레벨의 QoS 미만인 중간 레벨의 QoS 가 할당되는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 15 항에 있어서,
상기 제 2 세트의 링크들에서의 적어도 하나의 링크에는 제로 QoS 가 할당되는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 15 항에 있어서,
상기 제 2 세트의 링크들에서의 적어도 하나의 링크에는 상기 중간 레벨의 QoS 가 할당되는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 15 항에 있어서,
상기 임계치 레벨의 QoS 는 상기 제 1 세트의 링크들에서의 각각의 링크에 대한 주어진 보장 비트 레이트 (GBR) 를 적어도 포함하며,
상기 제 2 세트의 링크들에서의 각각의 링크는 제로 GBR 및/또는 상기 주어진 GBR 보다 낮은 GBR 을 갖는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 14 항에 있어서,
상기 제 1 세트의 링크들은 단지 상기 제 1 링크를 포함하며, 상기 제 2 세트의 링크들은 단지 상기 제 2 링크를 포함하는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 14 항에 있어서,
상기 제 1 세트의 링크들은 상기 제 1 링크 및 적어도 하나의 추가적인 링크를 포함하며,
상기 제 2 세트의 링크들은 단지 상기 제 2 링크를 포함하며,
상기 방법은:
상기 적어도 하나의 추가적인 링크 상에서 상기 서빙 네트워크로부터 적어도 하나의 추가적인 스트림을 수신하는 단계로서, 상기 적어도 하나의 추가적인 스트림은 상기 멀티플렉싱된 스트림으로부터의 적어도 하나의 추가적인 디-멀티플렉싱된 부분을 포함하는, 상기 적어도 하나의 추가적인 스트림을 수신하는 단계를 더 포함하며,
상기 재-멀티플렉싱은 상기 제 1 및 제 2 스트림들과 함께 상기 적어도 하나의 추가적인 스트림을 재-멀티플렉싱하여 상기 멀티플렉싱된 스트림의 상기 재구성된 버전을 생성하는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 14 항에 있어서,
상기 제 2 세트의 링크들은 상기 제 2 링크 및 적어도 하나의 추가적인 링크를 포함하며,
상기 제 1 세트의 링크들은 단지 상기 제 2 링크를 포함하며,
상기 방법은:
상기 적어도 하나의 추가적인 링크 상에서 상기 서빙 네트워크로부터 적어도 하나의 추가적인 스트림을 수신하는 단계로서, 상기 적어도 하나의 추가적인 스트림은 상기 멀티플렉싱된 스트림으로부터의 적어도 하나의 추가적인 디-멀티플렉싱된 부분을 포함하는, 상기 적어도 하나의 추가적인 스트림을 수신하는 단계를 더 포함하며,
상기 재-멀티플렉싱은 상기 제 1 및 제 2 스트림들과 함께 상기 적어도 하나의 추가적인 스트림을 재-멀티플렉싱하여 상기 멀티플렉싱된 스트림의 상기 재구성된 버전을 생성하는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 14 항에 있어서,
상기 제 1 세트의 링크들은 상기 제 1 링크 및 적어도 하나의 추가적인 링크를 포함하며,
상기 제 2 세트의 링크들은 상기 제 2 링크 및 하나 이상의 추가적인 링크들을 포함하며,
상기 방법은,
상기 적어도 하나의 추가적인 링크 상에서 상기 서빙 네트워크로부터 적어도 하나의 추가적인 스트림을 수신하는 단계로서, 상기 적어도 하나의 추가적인 스트림은 상기 멀티플렉싱된 스트림으로부터의 적어도 하나의 추가적인 디-멀티플렉싱된 부분을 포함하는, 상기 적어도 하나의 추가적인 스트림을 수신하는 단계; 및
상기 하나 이상의 추가적인 링크들 상에서 상기 서빙 네트워크로부터 하나 이상의 추가적인 스트림들을 수신하는 단계로서, 상기 하나 이상의 추가적인 스트림들은 상기 멀티플렉싱된 스트림으로부터의 하나 이상의 추가적인 디-멀티플렉싱된 부분들을 포함하는, 상기 하나 이상의 추가적인 스트림들을 수신하는 단계를 더 포함하며,
상기 재-멀티플렉싱은 상기 제 1 및 제 2 스트림들과 함께 상기 적어도 하나의 추가적인 스트림 및 상기 하나 이상의 추가적인 스트림들을 재-멀티플렉싱하여 상기 멀티플렉싱된 스트림의 상기 재구성된 버전을 생성하는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 14 항에 있어서,
상기 제 1 스트림은 상기 WebRTC 세션에 대한 오디오 미디어를 포함하며, 상기 제 2 스트림은 상기 WebRTC 세션에 대한 비디오 미디어를 포함하는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 14 항에 있어서,
상기 제 1 스트림은 상기 WebRTC 세션에 대한 오디오 미디어 및 상위-우선순위 비디오 미디어를 포함하며, 상기 제 2 스트림은 상기 WebRTC 세션에 대한 하위-우선순위 비디오 미디어를 포함하는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 14 항에 있어서,
상기 UE 및 상기 소스 UE 는 상기 서빙 네트워크에 의해 각각 서빙되며, 그리고
상기 UE 와 상기 소스 UE 사이의 종단간 접속은 상기 UE 및 상기 소스 UE 가 상기 서빙 네트워크에 의해 각각 서빙되는 것에 기초하여 네트워크간 네트워크 어드레스 변환 (NAT) 및/또는 네트워크간 방화벽을 통과하지 않는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 14 항에 있어서,
상기 소스 UE 는 상기 UE 를 서빙하는 상기 서빙 네트워크와는 상이한 다른 서빙 네트워크에 의해 서빙되며,
상기 UE 와 상기 소스 UE 사이의 종단간 접속은 상기 UE 및 상기 소스 UE 가 상이한 서빙 네트워크들에 의해 서빙되는 것에 기초하여 네트워크간 네트워크 어드레스 변환 (NAT) 및/또는 네트워크간 방화벽을 통과하는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 14 항에 있어서,
상기 멀티플렉싱된 스트림의 상기 재구성된 버전은 상기 소스 WebRTC 멀티미디어 클라이언트 애플리케이션에 의해 발생된 상기 멀티플렉싱된 스트림과 동일한, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 14 항에 있어서,
상기 멀티플렉싱된 스트림의 상기 재구성된 버전은 상기 소스 WebRTC 멀티미디어 클라이언트 애플리케이션에 의해 발생된 상기 멀티플렉싱된 스트림으로부터 수정되는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 제 28 항에 있어서,
상기 재구성된 버전은 상기 소스 WebRTC 멀티미디어 클라이언트 애플리케이션에 의해 발생된 상기 멀티플렉싱된 스트림에 비해 낮은 해상도로 압축되고 및/또는 구성되는, 웹 실시간 통신 (WebRTC) 프록시 모듈을 동작시키는 방법. - 웹 실시간 통신 (WebRTC) 세션에 참가되는 WebRTC 프록시 모듈을 실행하도록 구성된 사용자 장비 (UE) 로서,
제 1 세트의 링크들 및 상기 제 1 세트의 링크들과는 상이한 제 2 세트의 링크들을 획득하는 수단으로서, 상기 제 1 세트의 링크들에서의 각각의 링크에는 적어도 임계치 레벨의 서비스 품질 (QoS) 이 할당되는, 상기 링크들을 획득하는 수단;
상기 WebRTC 세션 동안, WebRTC 멀티미디어 클라이언트 애플리케이션으로부터, 상기 WebRTC 멀티미디어 클라이언트 애플리케이션이 타겟 UE 상의 타겟 WebRTC 멀티미디어 클라이언트 애플리케이션으로 전달하려고 시도중인 멀티플렉싱된 스트림을 획득하는 수단으로서, 상기 멀티플렉싱된 스트림은 제 1 미디어 컴포넌트 및 제 2 미디어 컴포넌트를 적어도 포함하는, 상기 멀티플렉싱된 스트림을 획득하는 수단;
상기 제 1 미디어 컴포넌트를 포함하는 제 1 디-멀티플렉싱된 스트림 및 상기 제 2 미디어 컴포넌트를 포함하는 제 2 디-멀티플렉싱된 스트림을 발생시키기 위해 상기 멀티플렉싱된 스트림을 디-멀티플렉싱하는 수단;
상기 타겟 UE 로의 전달을 위해 상기 제 1 세트의 링크들로부터의 제 1 링크 상에서 서빙 네트워크로 상기 제 1 디-멀티플렉싱된 스트림을 송신하는 수단; 및
상기 타겟 UE 로의 전달을 위해 상기 제 2 세트의 링크들로부터의 제 2 링크 상에서 상기 서빙 네트워크로 상기 제 2 디-멀티플렉싱된 스트림을 송신하는 수단을 포함하는, 웹 실시간 통신 (WebRTC) 세션에 참가되는 WebRTC 프록시 모듈을 실행하도록 구성된 사용자 장비 (UE). - 웹 실시간 통신 (WebRTC) 세션에 참가되는 WebRTC 프록시 모듈을 실행하도록 구성된 사용자 장비 (UE) 로서,
제 1 세트의 링크들 및 상기 제 1 세트의 링크들과는 상이한 제 2 세트의 링크들을 획득하는 수단으로서, 상기 제 1 세트의 링크들에서의 각각의 링크에는 적어도 임계치 레벨의 서비스 품질 (QoS) 이 할당되는, 상기 링크들을 획득하는 수단;
상기 WebRTC 세션 동안, 상기 제 1 세트의 링크들로부터의 제 1 링크 상에서 서빙 네트워크로부터 제 1 스트림을 수신하고, 상기 제 2 세트의 링크들로부터의 제 2 링크 상에서 상기 서빙 네트워크로부터 제 2 스트림을 수신하는 수단으로서, 상기 제 1 및 제 2 스트림들은 소스 UE 에서의 소스 WebRTC 멀티미디어 클라이언트 애플리케이션이 상기 UE 상의 WebRTC 멀티미디어 클라이언트 애플리케이션으로 전달하려고 시도중인 멀티플렉싱된 스트림의 디-멀티플렉싱된 부분들을 포함하는, 상기 수신하는 수단;
상기 멀티플렉싱된 스트림의 재구성된 버전을 생성하기 위해 상기 제 1 및 제 2 스트림들을 재-멀티플렉싱하는 수단; 및
상기 재-멀티플렉싱된 스트림을 상기 WebRTC 멀티미디어 클라이언트 애플리케이션으로 전달하는 수단을 포함하는, 웹 실시간 통신 (WebRTC) 세션에 참가되는 WebRTC 프록시 모듈을 실행하도록 구성된 사용자 장비 (UE). - 웹 실시간 통신 (WebRTC) 세션에 참가되는 WebRTC 프록시 모듈을 실행하도록 구성된 사용자 장비 (UE) 로서,
제 1 세트의 링크들 및 상기 제 1 세트의 링크들과는 상이한 제 2 세트의 링크들을 획득하도록 구성된 로직으로서, 상기 제 1 세트의 링크들에서의 각각의 링크에는 적어도 임계치 레벨의 서비스 품질 (QoS) 이 할당되는, 상기 링크들을 획득하도록 구성된 로직;
상기 WebRTC 세션 동안, WebRTC 멀티미디어 클라이언트 애플리케이션으로부터, 상기 WebRTC 멀티미디어 클라이언트 애플리케이션이 타겟 UE 상의 타겟 WebRTC 멀티미디어 클라이언트 애플리케이션으로 전달하려고 시도중인 멀티플렉싱된 스트림을 획득하도록 구성된 로직으로서, 상기 멀티플렉싱된 스트림은 제 1 미디어 컴포넌트 및 제 2 미디어 컴포넌트를 적어도 포함하는, 상기 멀티플렉싱된 스트림을 획득하도록 구성된 로직;
상기 제 1 미디어 컴포넌트를 포함하는 제 1 디-멀티플렉싱된 스트림 및 상기 제 2 미디어 컴포넌트를 포함하는 제 2 디-멀티플렉싱된 스트림을 발생시키기 위해 상기 멀티플렉싱된 스트림을 디-멀티플렉싱하도록 구성된 로직;
상기 타겟 UE 로의 전달을 위해 상기 제 1 세트의 링크들로부터의 제 1 링크 상에서 서빙 네트워크로 상기 제 1 디-멀티플렉싱된 스트림을 송신하도록 구성된 로직; 및
상기 타겟 UE 로의 전달을 위해 상기 제 2 세트의 링크들로부터의 제 2 링크 상에서 상기 서빙 네트워크로 상기 제 2 디-멀티플렉싱된 스트림을 송신하도록 구성된 로직을 포함하는, 웹 실시간 통신 (WebRTC) 세션에 참가되는 WebRTC 프록시 모듈을 실행하도록 구성된 사용자 장비 (UE). - 웹 실시간 통신 (WebRTC) 세션에 참가되는 WebRTC 프록시 모듈을 실행하도록 구성된 사용자 장비 (UE) 로서,
제 1 세트의 링크들 및 상기 제 1 세트의 링크들과는 상이한 제 2 세트의 링크들을 획득하도록 구성된 로직으로서, 상기 제 1 세트의 링크들에서의 각각의 링크에는 적어도 임계치 레벨의 서비스 품질 (QoS) 이 할당되는, 상기 링크들을 획득하도록 구성된 로직;
상기 WebRTC 세션 동안, 상기 제 1 세트의 링크들로부터의 제 1 링크 상에서 서빙 네트워크로부터 제 1 스트림을 수신하고, 상기 제 2 세트의 링크들로부터의 제 2 링크 상에서 상기 서빙 네트워크로부터 제 2 스트림을 수신하도록 구성된 로직으로서, 상기 제 1 및 제 2 스트림들은 소스 UE 에서의 소스 WebRTC 멀티미디어 클라이언트 애플리케이션이 상기 UE 상의 WebRTC 멀티미디어 클라이언트 애플리케이션으로 전달하려고 시도중인 멀티플렉싱된 스트림의 디-멀티플렉싱된 부분들을 포함하는, 상기 수신하도록 구성된 로직;
상기 멀티플렉싱된 스트림의 재구성된 버전을 생성하기 위해 상기 제 1 및 제 2 스트림들을 재-멀티플렉싱하도록 구성된 로직; 및
상기 재-멀티플렉싱된 스트림을 상기 WebRTC 멀티미디어 클라이언트 애플리케이션으로 전달하도록 구성된 로직을 포함하는, 웹 실시간 통신 (WebRTC) 세션에 참가되는 WebRTC 프록시 모듈을 실행하도록 구성된 사용자 장비 (UE). - 웹 실시간 통신 (WebRTC) 세션에 참가되는 WebRTC 프록시 모듈을 실행하도록 구성된 사용자 장비 (UE) 에 의해 실행될 때, 상기 UE 로 하여금, 동작들을 수행하도록 하는, 저장된 명령들을 포함하는 비일시적 컴퓨터-판독가능 매체로서,
상기 명령들은,
상기 UE 로 하여금, 제 1 세트의 링크들 및 상기 제 1 세트의 링크들과는 상이한 제 2 세트의 링크들을 획득하도록 하는 적어도 하나의 명령으로서, 상기 제 1 세트의 링크들에서의 각각의 링크에는 적어도 임계치 레벨의 서비스 품질 (QoS) 이 할당되는, 상기 링크들을 획득하도록 하는 적어도 하나의 명령;
상기 UE 로 하여금, 상기 WebRTC 세션 동안, WebRTC 멀티미디어 클라이언트 애플리케이션으로부터, 상기 WebRTC 멀티미디어 클라이언트 애플리케이션이 타겟 UE 상의 타겟 WebRTC 멀티미디어 클라이언트 애플리케이션으로 전달하려고 시도중인 멀티플렉싱된 스트림을 획득하도록 하는 적어도 하나의 명령으로서, 상기 멀티플렉싱된 스트림은 제 1 미디어 컴포넌트 및 제 2 미디어 컴포넌트를 적어도 포함하는, 상기 멀티플렉싱된 스트림을 획득하도록 하는 적어도 하나의 명령;
상기 UE 로 하여금, 상기 제 1 미디어 컴포넌트를 포함하는 제 1 디-멀티플렉싱된 스트림 및 상기 제 2 미디어 컴포넌트를 포함하는 제 2 디-멀티플렉싱된 스트림을 발생시키기 위해 상기 멀티플렉싱된 스트림을 디-멀티플렉싱하도록 하는 적어도 하나의 명령;
상기 UE 로 하여금, 상기 타겟 UE 로의 전달을 위해 상기 제 1 세트의 링크들로부터의 제 1 링크 상에서 서빙 네트워크로 상기 제 1 디-멀티플렉싱된 스트림을 송신하도록 하는 적어도 하나의 명령; 및
상기 UE 로 하여금, 상기 타겟 UE 로의 전달을 위해 상기 제 2 세트의 링크들로부터의 제 2 링크 상에서 상기 서빙 네트워크로 상기 제 2 디-멀티플렉싱된 스트림을 송신하도록 하는 적어도 하나의 명령을 포함하는, 비일시적 컴퓨터-판독가능 매체. - 웹 실시간 통신 (WebRTC) 세션에 참가되는 WebRTC 프록시 모듈을 실행하도록 구성된 사용자 장비 (UE) 에 의해 실행될 때, 상기 UE 로 하여금, 동작들을 수행하도록 하는, 저장된 명령들을 포함하는 비일시적 컴퓨터-판독가능 매체로서,
상기 명령들은,
상기 UE 로 하여금, 제 1 세트의 링크들 및 상기 제 1 세트의 링크들과는 상이한 제 2 세트의 링크들을 획득하도록 하는 적어도 하나의 명령으로서, 상기 제 1 세트의 링크들에서의 각각의 링크에는 적어도 임계치 레벨의 서비스 품질 (QoS) 이 할당되는, 상기 링크들을 획득하도록 하는 적어도 하나의 명령;
상기 UE 로 하여금, 상기 WebRTC 세션 동안, 상기 제 1 세트의 링크들로부터의 제 1 링크 상에서 서빙 네트워크로부터 제 1 스트림을 수신하고, 상기 제 2 세트의 링크들로부터의 제 2 링크 상에서 상기 서빙 네트워크로부터 제 2 스트림을 수신하도록 하는 적어도 하나의 명령으로서, 상기 제 1 및 제 2 스트림들은 소스 UE 에서의 소스 WebRTC 멀티미디어 클라이언트 애플리케이션이 상기 UE 상의 WebRTC 멀티미디어 클라이언트 애플리케이션으로 전달하려고 시도중인 멀티플렉싱된 스트림의 디-멀티플렉싱된 부분들을 포함하는, 상기 수신하도록 하는 적어도 하나의 명령;
상기 UE 로 하여금, 상기 멀티플렉싱된 스트림의 재구성된 버전을 생성하기 위해 상기 제 1 및 제 2 스트림들을 재-멀티플렉싱하도록 하는 적어도 하나의 명령; 및
상기 UE 로 하여금, 상기 재-멀티플렉싱된 스트림을 상기 WebRTC 멀티미디어 클라이언트 애플리케이션으로 전달하도록 하는 적어도 하나의 명령을 포함하는, 비일시적 컴퓨터-판독가능 매체.
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201361878510P | 2013-09-16 | 2013-09-16 | |
| US61/878,510 | 2013-09-16 | ||
| US14/484,026 | 2014-09-11 | ||
| US14/484,026 US9467480B2 (en) | 2013-09-16 | 2014-09-11 | Selectively multiplexing incoming WebRTC traffic and/or de-multiplexing outgoing WebRTC traffic by a client-based WebRTC proxy on behalf of a WebRTC multimedia client application |
| PCT/US2014/055554 WO2015038997A1 (en) | 2013-09-16 | 2014-09-15 | Selectively multplexing incoming webrtc traffic and/or de-multiplexing outgoing webrtc traffic by a client-based webrtc proxy on behalf of a webrtc multimedia client application |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| KR20160055823A true KR20160055823A (ko) | 2016-05-18 |
Family
ID=51660604
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020167007840A KR20160055823A (ko) | 2013-09-16 | 2014-09-15 | WebRTC 멀티미디어 클라이언트 애플리케이션 대신 클라이언트-기반 WebRTC 프록시에 의한 인입 WebRTC 트래픽의 선택적 멀티플렉싱 및/또는 유출 WebRTC 트래픽의 디-멀티플렉싱 |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US9467480B2 (ko) |
| EP (1) | EP3047624B1 (ko) |
| JP (1) | JP6423439B2 (ko) |
| KR (1) | KR20160055823A (ko) |
| CN (1) | CN105556923B (ko) |
| TW (1) | TW201521482A (ko) |
| WO (1) | WO2015038997A1 (ko) |
Families Citing this family (88)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10111055B2 (en) | 2004-11-23 | 2018-10-23 | Kodiak Networks, Inc. | Optimized methods for large group calling using unicast and multicast transport bearer for PoC |
| US10057105B2 (en) | 2004-11-23 | 2018-08-21 | Kodiak Networks, Inc. | Architecture framework to realize push-to-X services using cloudbased storage services |
| US10178513B2 (en) | 2004-11-23 | 2019-01-08 | Kodiak Networks, Inc. | Relay-mode and direct-mode operations for push-to-talk-over-cellular (PoC) using WiFi-technologies |
| US10116691B2 (en) | 2004-11-23 | 2018-10-30 | Kodiak Networks, Inc. | VoIP denial-of-service protection mechanisms from attack |
| US9467480B2 (en) * | 2013-09-16 | 2016-10-11 | Qualcomm Incorporated | Selectively multiplexing incoming WebRTC traffic and/or de-multiplexing outgoing WebRTC traffic by a client-based WebRTC proxy on behalf of a WebRTC multimedia client application |
| US9271149B2 (en) * | 2013-10-18 | 2016-02-23 | Verizon Patent And Licensing Inc. | Managing hidden security features in user equipment |
| CN104683402B (zh) * | 2013-11-29 | 2019-01-08 | 华为终端（东莞）有限公司 | 通信方法和用户设备 |
| US10361585B2 (en) | 2014-01-27 | 2019-07-23 | Ivani, LLC | Systems and methods to allow for a smart device |
| KR102279880B1 (ko) * | 2014-03-11 | 2021-07-21 | 삼성전자 주식회사 | 무선 통신 시스템에서 베어러의 비트레이트를 동적으로 운영하는 방법 및 장치 |
| WO2015199462A1 (en) * | 2014-06-27 | 2015-12-30 | Samsung Electronics Co., Ltd. | Method and apparatus for providing quality of service for web-based real-time communication |
| MX365073B (es) * | 2014-10-29 | 2019-05-22 | Kodiak Networks Inc | Sistema y metodo para hacer uso de comunicacion web en tiempo real para implementar soluciones de presiona para hablar. |
| CN107251610B (zh) * | 2015-05-20 | 2020-09-25 | 松下电器（美国）知识产权公司 | 通信节点、终端及通信控制方法 |
| CN106506319B (zh) * | 2015-09-07 | 2019-06-25 | 中国移动通信集团公司 | 网页实时通信中服务质量会话参数的传递方法及转换网关 |
| US9474042B1 (en) | 2015-09-16 | 2016-10-18 | Ivani, LLC | Detecting location within a network |
| US11350238B2 (en) | 2015-09-16 | 2022-05-31 | Ivani, LLC | Systems and methods for detecting the presence of a user at a computer |
| US10325641B2 (en) | 2017-08-10 | 2019-06-18 | Ivani, LLC | Detecting location within a network |
| US10382893B1 (en) | 2015-09-16 | 2019-08-13 | Ivani, LLC | Building system control utilizing building occupancy |
| US11533584B2 (en) | 2015-09-16 | 2022-12-20 | Ivani, LLC | Blockchain systems and methods for confirming presence |
| US10665284B2 (en) | 2015-09-16 | 2020-05-26 | Ivani, LLC | Detecting location within a network |
| US10455357B2 (en) | 2015-09-16 | 2019-10-22 | Ivani, LLC | Detecting location within a network |
| US10321270B2 (en) | 2015-09-16 | 2019-06-11 | Ivani, LLC | Reverse-beacon indoor positioning system using existing detection fields |
| WO2017062627A1 (en) * | 2015-10-06 | 2017-04-13 | Kodiak Networks, Inc. | System and method for improved push-to-talk communication performance |
| US10129307B2 (en) | 2015-10-06 | 2018-11-13 | Kodiak Networks Inc. | PTT network with radio condition aware media packet aggregation scheme |
| FR3043517A1 (fr) * | 2015-11-09 | 2017-05-12 | Orange | Procede et dispositif de gestion d'une prise de parole depuis un terminal mobile. |
| US10129853B2 (en) | 2016-06-08 | 2018-11-13 | Cognitive Systems Corp. | Operating a motion detection channel in a wireless communication network |
| WO2017215733A1 (en) * | 2016-06-14 | 2017-12-21 | Netent Product Services Ltd. | Live streaming of media for low-latency applications such as live casino gaming applications |
| US10785696B2 (en) | 2016-06-21 | 2020-09-22 | Huawei Technologies Co., Ltd. | Systems and methods for user plane path selection, reselection, and notification of user plane changes |
| CN107846379B (zh) * | 2016-09-18 | 2021-09-07 | 中兴通讯股份有限公司 | 一种视频会议系统中端口复用方法和服务器 |
| US10972552B2 (en) | 2016-09-30 | 2021-04-06 | Huawei Technologies Co., Ltd. | Method and system for user plane path selection |
| US10257669B2 (en) | 2016-12-01 | 2019-04-09 | Kodiak Networks, Inc. | PTX data analytic engine notifying group list of detected risk event |
| US10630529B2 (en) | 2016-12-29 | 2020-04-21 | Kodiak Networks, Inc. | System and method for push-to-talk (PTT) in mobile edge computing (MEC) |
| US10531420B2 (en) * | 2017-01-05 | 2020-01-07 | Huawei Technologies Co., Ltd. | Systems and methods for application-friendly protocol data unit (PDU) session management |
| US9743294B1 (en) | 2017-03-16 | 2017-08-22 | Cognitive Systems Corp. | Storing modem parameters for motion detection |
| US9927519B1 (en) | 2017-03-16 | 2018-03-27 | Cognitive Systems Corp. | Categorizing motion detected using wireless signals |
| US9989622B1 (en) | 2017-03-16 | 2018-06-05 | Cognitive Systems Corp. | Controlling radio states for motion detection |
| US10004076B1 (en) | 2017-03-16 | 2018-06-19 | Cognitive Systems Corp. | Selecting wireless communication channels based on signal quality metrics |
| US10051414B1 (en) | 2017-08-30 | 2018-08-14 | Cognitive Systems Corp. | Detecting motion based on decompositions of channel response variations |
| US11146834B1 (en) | 2017-09-28 | 2021-10-12 | Twitch Interactive, Inc. | Server-based encoded version selection |
| US10735783B1 (en) | 2017-09-28 | 2020-08-04 | Twitch Interactive, Inc. | Intra-rendition latency variation |
| AU2018352483B2 (en) * | 2017-10-19 | 2023-08-17 | Lazar Entertainment Inc. | Systems and methods for broadcasting live media streams |
| US10109167B1 (en) | 2017-10-20 | 2018-10-23 | Cognitive Systems Corp. | Motion localization in a wireless mesh network based on motion indicator values |
| US10228439B1 (en) | 2017-10-31 | 2019-03-12 | Cognitive Systems Corp. | Motion detection based on filtered statistical parameters of wireless signals |
| US10048350B1 (en) | 2017-10-31 | 2018-08-14 | Cognitive Systems Corp. | Motion detection based on groupings of statistical parameters of wireless signals |
| US9933517B1 (en) | 2017-11-03 | 2018-04-03 | Cognitive Systems Corp. | Time-alignment of motion detection signals using buffers |
| US10605908B2 (en) | 2017-11-15 | 2020-03-31 | Cognitive Systems Corp. | Motion detection based on beamforming dynamic information from wireless standard client devices |
| US10109168B1 (en) | 2017-11-16 | 2018-10-23 | Cognitive Systems Corp. | Motion localization based on channel response characteristics |
| US10852411B2 (en) | 2017-12-06 | 2020-12-01 | Cognitive Systems Corp. | Motion detection and localization based on bi-directional channel sounding |
| US10264405B1 (en) | 2017-12-06 | 2019-04-16 | Cognitive Systems Corp. | Motion detection in mesh networks |
| US10108903B1 (en) | 2017-12-08 | 2018-10-23 | Cognitive Systems Corp. | Motion detection based on machine learning of wireless signal properties |
| CN109922472B (zh) | 2017-12-13 | 2021-10-26 | 华为技术有限公司 | 用户策略的获取 |
| US10393866B1 (en) | 2018-03-26 | 2019-08-27 | Cognitive Systems Corp. | Detecting presence based on wireless signal analysis |
| US11464060B2 (en) * | 2018-04-26 | 2022-10-04 | Htc Corporation | Device and method of handling a radio resource control reestablishment |
| FI20185419A1 (en) | 2018-05-08 | 2019-11-09 | Telia Co Ab | communication Management |
| US10318890B1 (en) | 2018-05-23 | 2019-06-11 | Cognitive Systems Corp. | Training data for a motion detection system using data from a sensor device |
| US11579703B2 (en) | 2018-06-18 | 2023-02-14 | Cognitive Systems Corp. | Recognizing gestures based on wireless signals |
| US10986219B2 (en) | 2018-06-19 | 2021-04-20 | At&T Intellectual Property I, L.P. | LTE fault-tolerant signaling approach |
| US10455194B1 (en) * | 2018-11-27 | 2019-10-22 | Dialogic Corporation | Robust handling of sudden changes of bandwidth in selective forwarding unit conferences |
| US10506384B1 (en) | 2018-12-03 | 2019-12-10 | Cognitive Systems Corp. | Determining a location of motion detected from wireless signals based on prior probability |
| US11403543B2 (en) | 2018-12-03 | 2022-08-02 | Cognitive Systems Corp. | Determining a location of motion detected from wireless signals |
| US10499364B1 (en) | 2019-01-24 | 2019-12-03 | Cognitive Systems Corp. | Identifying static leaf nodes in a motion detection system |
| US10498467B1 (en) | 2019-01-24 | 2019-12-03 | Cognitive Systems Corp. | Classifying static leaf nodes in a motion detection system |
| CN109922046B (zh) * | 2019-01-30 | 2021-06-29 | 广东腾一科技有限公司 | 一种数据收发系统及方法 |
| JP7316054B2 (ja) * | 2019-01-31 | 2023-07-27 | 日本無線株式会社 | 同報配信システム |
| US10565860B1 (en) | 2019-03-21 | 2020-02-18 | Cognitive Systems Corp. | Offline tuning system for detecting new motion zones in a motion detection system |
| US11050800B2 (en) * | 2019-04-10 | 2021-06-29 | T-Mobile Usa, Inc. | Network assigning QoS for service based on codec exchanged peer-to-peer |
| US10459074B1 (en) | 2019-04-30 | 2019-10-29 | Cognitive Systems Corp. | Determining a location of motion detected from wireless signals based on wireless link counting |
| US10567914B1 (en) | 2019-04-30 | 2020-02-18 | Cognitive Systems Corp. | Initializing probability vectors for determining a location of motion detected from wireless signals |
| US10849006B1 (en) | 2019-04-30 | 2020-11-24 | Cognitive Systems Corp. | Controlling measurement rates in wireless sensing systems |
| US10600314B1 (en) | 2019-04-30 | 2020-03-24 | Cognitive Systems Corp. | Modifying sensitivity settings in a motion detection system |
| US10743143B1 (en) | 2019-05-15 | 2020-08-11 | Cognitive Systems Corp. | Determining a motion zone for a location of motion detected by wireless signals |
| US10404387B1 (en) | 2019-05-15 | 2019-09-03 | Cognitive Systems Corp. | Determining motion zones in a space traversed by wireless signals |
| US10460581B1 (en) | 2019-05-15 | 2019-10-29 | Cognitive Systems Corp. | Determining a confidence for a motion zone identified as a location of motion for motion detected by wireless signals |
| CN114365503A (zh) | 2019-07-23 | 2022-04-15 | 拉扎尔娱乐公司 | 实况媒体内容递送系统和方法 |
| WO2021030369A1 (en) | 2019-08-12 | 2021-02-18 | Social Microphone, Inc. | Optimizing data priority by managing network resources |
| US11006245B2 (en) | 2019-09-30 | 2021-05-11 | Cognitive Systems Corp. | Detecting a location of motion using wireless signals and topologies of wireless connectivity |
| US11570712B2 (en) | 2019-10-31 | 2023-01-31 | Cognitive Systems Corp. | Varying a rate of eliciting MIMO transmissions from wireless communication devices |
| CN114599991A (zh) | 2019-10-31 | 2022-06-07 | 认知系统公司 | 引发来自无线通信装置的mimo传输 |
| WO2021081635A1 (en) | 2019-10-31 | 2021-05-06 | Cognitive Systems Corp. | Using mimo training fields for motion detection |
| US10928503B1 (en) | 2020-03-03 | 2021-02-23 | Cognitive Systems Corp. | Using over-the-air signals for passive motion detection |
| US11304254B2 (en) | 2020-08-31 | 2022-04-12 | Cognitive Systems Corp. | Controlling motion topology in a standardized wireless communication network |
| CN112423007B (zh) * | 2020-11-09 | 2022-07-08 | 杭州叙简科技股份有限公司 | 一种基于组播的webrtc的视频流传输系统 |
| US11070399B1 (en) | 2020-11-30 | 2021-07-20 | Cognitive Systems Corp. | Filtering channel responses for motion detection |
| BE1029154B1 (fr) * | 2021-03-01 | 2022-09-27 | Selfsun | Dispositif et procédé pour une interaction entre un public et des acteurs |
| CN113613291B (zh) * | 2021-08-12 | 2024-02-02 | 中国联合网络通信集团有限公司 | 一种下行gbr业务流传送方法、终端及流量控制单元 |
| JP2023081226A (ja) | 2021-11-30 | 2023-06-09 | 株式会社リコー | 通信管理装置、通信システム、通信管理方法、及びプログラム |
| US11381628B1 (en) * | 2021-12-22 | 2022-07-05 | Hopin Ltd | Browser-based video production |
| CN115037978B (zh) * | 2022-07-13 | 2023-08-25 | 北京字跳网络技术有限公司 | 投屏方法及相关设备 |
| CN115442348B (zh) * | 2022-11-09 | 2023-01-24 | 成都华栖云科技有限公司 | 一种基于多协议多终端交互的教学实时互动方法及系统 |
Family Cites Families (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7552239B2 (en) * | 2001-05-14 | 2009-06-23 | Canon Information Systems, Inc. | Network device mimic support |
| US8265069B2 (en) * | 2005-06-23 | 2012-09-11 | Nokia Corporation | System, terminal, method, and computer program product for establishing a transport-level connection with a server located behind a network address translator and/or firewall |
| EP2127230A4 (en) | 2007-02-09 | 2014-12-31 | Onmobile Global Ltd | METHOD AND APPARATUS FOR ADAPTING MULTIMEDIA CONTENT IN TELECOMMUNICATIONS NETWORKS |
| EP2317733A1 (en) * | 2009-10-29 | 2011-05-04 | British Telecommunications public limited company | Communications system |
| US8335192B2 (en) * | 2010-04-13 | 2012-12-18 | Qualcomm Incorporated | Selectively transitioning between physical-layer networks during a streaming communication session within a wireless communications system |
| US8553631B2 (en) * | 2010-09-30 | 2013-10-08 | Motorola Solutions, Inc. | Methods for reducing set up time for communications among multiple user equipment in a long term evolution system |
| US20120287784A1 (en) * | 2011-05-10 | 2012-11-15 | Cisco Technology, Inc. | System and method for integrated quality of service in a wireless network environment |
| US20140044123A1 (en) | 2011-05-23 | 2014-02-13 | Twilio, Inc. | System and method for real time communicating with a client application |
| EP2745477B1 (en) * | 2011-08-18 | 2016-04-27 | VID SCALE, Inc. | Methods and systems for packet differentiation |
| US9319459B2 (en) * | 2011-09-19 | 2016-04-19 | Cisco Technology, Inc. | Services controlled session based flow interceptor |
| WO2013108121A2 (en) * | 2012-01-17 | 2013-07-25 | IPalive AB | A device, software module, system or business method for global real-time telecommunication |
| US9578546B2 (en) | 2012-08-31 | 2017-02-21 | Qualcomm Incorporated | Directional adjustment to quality of service based on predicted traffic activity on a link |
| US9497659B2 (en) | 2012-08-31 | 2016-11-15 | Qualcomm Incorporated | Directional adjustment to quality of service based on monitored traffic activity on a link |
| US9055554B2 (en) * | 2012-12-12 | 2015-06-09 | At&T Intellectual Property I, L.P. | Management of voice communications over long term evolution networks |
| US8861692B1 (en) * | 2013-05-15 | 2014-10-14 | Verizon Patent And Licensing Inc. | Web call access and egress to private network |
| US9444746B2 (en) | 2013-06-25 | 2016-09-13 | Qualcomm Incorporated | Selectively transferring high-priority non-audio data over a quality of service channel |
| US9467480B2 (en) * | 2013-09-16 | 2016-10-11 | Qualcomm Incorporated | Selectively multiplexing incoming WebRTC traffic and/or de-multiplexing outgoing WebRTC traffic by a client-based WebRTC proxy on behalf of a WebRTC multimedia client application |
-
2014
- 2014-09-11 US US14/484,026 patent/US9467480B2/en active Active
- 2014-09-15 TW TW103131809A patent/TW201521482A/zh unknown
- 2014-09-15 CN CN201480050856.8A patent/CN105556923B/zh not_active Expired - Fee Related
- 2014-09-15 EP EP14780936.2A patent/EP3047624B1/en active Active
- 2014-09-15 WO PCT/US2014/055554 patent/WO2015038997A1/en active Application Filing
- 2014-09-15 JP JP2016542845A patent/JP6423439B2/ja not_active Expired - Fee Related
- 2014-09-15 KR KR1020167007840A patent/KR20160055823A/ko not_active Application Discontinuation
Also Published As
| Publication number | Publication date |
|---|---|
| EP3047624A1 (en) | 2016-07-27 |
| EP3047624B1 (en) | 2017-07-05 |
| WO2015038997A1 (en) | 2015-03-19 |
| JP6423439B2 (ja) | 2018-11-14 |
| CN105556923A (zh) | 2016-05-04 |
| JP2016537920A (ja) | 2016-12-01 |
| US9467480B2 (en) | 2016-10-11 |
| US20150078295A1 (en) | 2015-03-19 |
| TW201521482A (zh) | 2015-06-01 |
| CN105556923B (zh) | 2018-08-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3047624B1 (en) | Selectively multiplexing incoming webrtc traffic and/or de-multiplexing outgoing webrtc traffic by a client-based webrtc proxy on behalf of a webrtc multimedia client application | |
| KR102125771B1 (ko) | 링크 상의 예측된 트래픽 활성도에 기초한 서비스 품질 | |
| EP2891359B1 (en) | Adjustment to quality of service based on predicted traffic activity on a link | |
| US9668166B2 (en) | Quality of service for web client based sessions | |
| KR101832721B1 (ko) | 셀룰라를 통한 서비스들에 대한 동적 서비스 품질 (qos) | |
| US9288816B2 (en) | Providing service based on quality of service resources in a long term evolution communications system | |
| US9554389B2 (en) | Selectively allocating quality of service to support multiple concurrent sessions for a client device | |
| EP3014825B1 (en) | Selectively transferring high-priority non-audio data over a quality of service channel | |
| US20140064124A1 (en) | Managing guaranteed bit rate quality of service resource allocation based on guaranteed bit rate data activity on a link | |
| US20140068098A1 (en) | Reducing network latency resulting from non-access stratum (nas) authentication for high performance content applications | |
| EP2941840B1 (en) | Selectively patching erasures in circuit-switched calls whose frame erasure rate rises above a threshold by establishing and synchronizing a voip stream |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| WITN | Application deemed withdrawn, e.g. because no request for examination was filed or no examination fee was paid |