KR20140139000A - 무선 네트워크에서 다른 이동국에 의한 이동국 세션의 스폰서링 - Google Patents

Abstract

무선 송수신 유닛(wireless transmit/receive unit: WTRU)에 의한 서비스 및 우선 트래픽 핸들링(즉, 데이터 접속성)을 위한 장치 및 방법이 설명된다. 제1 WTRU는 애플리케이션 서버(application server: AS)를 거쳐 제2 WTRU의 사용자 스폰서링을 개시할 수도 있다. 제1 WTRU는 AS로부터 서비스 트리거를 수신하고 서비스 트리거를 제2 WTRU에 포워딩할 수도 있다. 제2 WTRU는 이어서 AS로부터 서비스를 수신하기 위해 서비스 트리거를 사용하여 AS와 스폰서링된 세션을 개시할 수도 있다. 제1 WTRU는 또한 크레디트를 제2 WTRU에 전달하도록 AS에 요청할 수도 있다. AS는 온라인 과금 펑션(online charging function: OCF) 및 과금 데이터 펑션(charging data function: CDF)을 포함하는 과금 시스템과 직접 통신 링크를 설정할 수도 있다. AS는 제2 WTRU에 콘텐트를 전달하는 데 필요한 우선 트래픽 핸들링을 제공하도록 네트워크에 요청을 송신할 수도 있다.

Description

무선 네트워크에서 다른 이동국에 의한 이동국 세션의 스폰서링{SPONSORING OF A MOBILE STATION SESSION BY ANOTHER MOBILE STATION IN A WIRELESS NETWORK}

관련 출원의 상호 참조

본 출원은 2012년 11월 15일 출원된 미국 가출원 제61/726,919호 및 2012년 3월 21일 출원된 미국 가출원 제61/613,693호의 이익을 청구하며, 이 출원들의 내용은 본 명세서에 참조로서 합체되어 있다.

애플리케이션 공급자와 3세대 파트너쉽 프로젝트(third generation partnership program: 3GPP) 네트워크 사업자 코어 네트워크(core network: CN) 사이의 상호 작용을 지원하는 것이 바람직하다. 애플리케이션과 모바일 네트워크 사이의 긴밀한 상호 작용은 최종 사용자에 효율적으로 과금(charging) 및 빌링(billing)함으로써 구현될 수도 있다. 예를 들어, 애플리케이션 요금은 모바일 네트워크 사업자(mobile network operator: MNO)에 의해 최종 사용자에 송신된 청구서(bill)와 통합될 수도 있다. 현재, 사용자가 애플리케이션 서비스를 위해 다른 사용자를 스폰서링하는 것을 가능하게 하는 메커니즘이 존재하지 않는다.

무선 송수신 유닛(wireless transmit/receive unit: WTRU)에 의해, 스폰서링 서비스 및 우선 트래픽 핸들링(즉, 데이터 접속성)을 위한 장치 및 방법이 설명된다. 제1 WTRU는 제2 WTRU의 아이덴티티(identity)를 얻고 애플리케이션 서버(application server: AS)를 거쳐 제2 WTRU의 사용자 스폰서링을 개시할 수도 있다. 제1 WTRU는 AS로부터 서비스 트리거를 수신하고 서비스 트리거를 제2 WTRU에 포워딩할 수도 있다. 제2 WTRU는 이어서 AS로부터 서비스를 수신하기 위해 서비스 트리거를 사용하여 AS와의 스폰서링된 세션을 개시할 수도 있다. 제1 WTRU는 또한 제2 WTRU에 크레디트(credit)를 전달하도록 AS에 요청할 수도 있다. AS는 온라인 과금 펑션(online charging function: OCF) 및 과금 데이터 펑션(charging data function: CDF)을 포함하는 과금 시스템과 직접 통신 링크를 설정할 수도 있다. AS는 콘텐트를 제2 WTRU에 전달하기 위해 요구되는 우선 트래픽 핸들링을 제공하기 위한 요청을 네트워크에 송신할 수도 있다.

더 상세한 이해가 첨부 도면과 함께 예로서 제공된 이하의 설명으로부터 얻어질 수 있다.
도 1a는 하나 이상의 개시된 실시예가 구현될 수도 있는 예시적인 통신 시스템을 도시하고 있다.
도 1b는 도 1a에 도시되어 있는 통신 시스템 내에 사용될 수도 있는 예시적인 무선 송수신 유닛(wireless transmit/receive unit: WTRU)을 도시하고 있다.
도 1c는 도 1a에 도시되어 있는 통신 시스템 내에 사용될 수도 있는 예시적인 무선 액세스 네트워크 및 예시적인 코어 네트워크(core network: CN)를 도시하고 있다.
도 2는 과금 노드와 상호 접속된 애플리케이션 서버(application server: AS)를 포함하는 네트워크 아키텍처를 도시하고 있다.
도 3a 및 도 3b는 함께 취해져서, 애플리케이션 서버(AS)가 모바일 네트워크 사업자(mobile network operator: MNO)에 의해 소유되고 전개될 수도 있는 사용자 스폰서링 절차의 메시지 흐름도이다.
도 3c 및 도 3d는 함께 취해져서, 스폰서링 요청 절차의 메시지 흐름도이다.
도 3e 및 도 3f는 함께 취해져서, 스폰서링된 세션 개시를 위한 절차의 메시지 흐름도이다.
도 4는 애플리케이션 서비스 공급자가 액세스 공급자 네트워크와 협의를 설정할 수도 있는 아키텍처 콘텍스트(context)를 도시하고 있다.
도 5a 및 도 5b는 함께 취해져서, 사용자-기반 스폰서링을 구현하는 절차의 고레벨 메시지 흐름도이다.
도 6a 및 도 6b는 함께 취해져서, 다른 WTRU 대신에 WTRU 서비스를 스폰서링하는 애플리케이션 공급자를 위한 절차의 고레벨 메시지 흐름도이다.
도 7a, 도 7b 및 도 7c는 과금 이벤트가 제3 자 AS에 의해 3세대 파트너쉽 프로젝트(third generation partnership project: 3GPP) 코어 네트워크(CN)에 송신될 수 있게 하는 아키텍처 도면을 도시하고 있다.
도 8a 및 도 8b는 함께 취해져서, 사용자 스폰서링을 위한 절차의 고레벨 메시지 흐름도이다.
도 9는 2개의 상이한 WTRU의 사용자가 제1 MNO에 가입하고 있지만, WTRU 중 하나는 추가의 비용으로 제1 MNO에 가입자에 대한 우선 트래픽 핸들링을 제공하는 제2 MNO에서 로밍하는 홈-라우팅된 네트워크 아키텍처를 도시하고 있다.
도 10은 하나의 WTRU의 사용자가 다른 WTRU의 사용자를 위한 애플리케이션 서비스 및/또는 우선 트래픽 핸들링을 스폰서링하는 로컬 브레이크아웃(local breakout) 로밍 네트워크 아키텍처를 도시하고 있다.
도 11a 및 도 11b는 함께 취해져서, 동일한 MNO 및 로밍을 갖는 로컬 브레이크아웃 협동 케이스를 위한 절차의 고레벨 메시지 흐름도이다.
도 12a 및 도 12b는 함께 취해져서, 동일한 MNO 및 로밍을 갖는 홈-라우팅된 협동 케이스를 위한 절차의 고레벨 메시지 흐름도이다.
도 13은 상이한 MNO를 갖는 비-로밍 협동 케이스를 위한 절차의 고레벨 메시지 흐름도이다.
도 14는 상이한 MNO를 갖는 비-로밍 협동 케이스를 위한 절차의 고레벨 메시지 흐름도이다.
도 15는 상이한 MNO를 갖는 로밍 협동 케이스를 위한 절차의 고레벨 메시지 흐름도이다.
도 16은 상이한 MNO를 갖는 로밍 협동 케이스를 위한 절차의 고레벨 메시지 흐름도이다.
도 17은 동일한 MNO를 수반하고 비즈니스 협의를 수반하지 않는 비-협동 상황을 위한 절차의 고레벨 메시지 흐름도이다.
도 18은 상이한 MNO를 수반하고 비즈니스 협의를 수반하지 않는 비-협동 상황을 위한 절차의 고레벨 메시지 흐름도이다.
도 19는 과금 메시지가 스폰서링된 이벤트의 수신인을 식별하는 데 사용된 정보 요소(information element: IE)를 포함하도록 향상되는 절차의 고레벨 메시지 흐름도이다.
도 20a 및 도 20b는 함께 취해져서, WTRU 사용자들 사이에 크레디트를 전달하기 위한 절차의 고레벨 메시지 흐름도이다.

도 1a는 하나 이상의 개시된 실시예가 구현될 수도 있는 예시적인 통신 시스템(100)을 도시하고 있다. 통신 시스템(100)은 음성, 데이터, 비디오, 메시징, 브로드캐스트 등과 같은 콘텐트를 다수의 무선 사용자에게 제공하는 다중 액세스 시스템일 수 있다. 통신 시스템(100)은 무선 대역폭을 포함하는, 시스템 리소스의 공유를 통해 다수의 무선 사용자가 이러한 콘텐트에 액세스하는 것을 가능하게 할 수 있다. 예를 들어, 통신 시스템(100)은 코드 분할 다중 접속(code division multiple access: CDMA), 시분할 다중 접속(time division multiple access: TDMA), 주파수 분할 다중 접속(frequency division multiple access: FDMA), 직교 FDMA(OFDMA), 단일-반송파 FDMA(SC-FDMA) 등과 같은 하나 이상의 채널 액세스 방법을 이용할 수 있다.

도 1a에 도시되어 있는 바와 같이, 통신 시스템(100)은 무선 송수신 유닛(wireless transmit/receive unit: WTRU)(102a, 102b, 102c, 102d), 무선 액세스 네트워크(radio access network: RAN)(104), 코어 네트워크(core network: CN)(106), 공중 전화 교환 네트워크(public switched telephone network: PSTN)(108), 인터넷(110) 및 다른 네트워크(112)를 포함할 수 있지만, 개시된 실시예는 임의의 수의 WTRU, 기지국, 네트워크 및/또는 네트워크 요소를 고려한다는 것이 이해될 수 있을 것이다. 각각의 WTRU(102a, 102b, 102c, 102d)는 무선 환경에서 동작하고 그리고/또는 통신하도록 구성된 임의의 유형의 디바이스일 수 있다. 예로서, WTRU(102a, 102b, 102c, 102d)는 무선 신호를 전송 및/또는 수신하도록 구성될 수 있고, 사용자 장비(user equipment: UE), 이동국, 고정 또는 이동 가입자 유닛, 호출기, 휴대폰, 개인 휴대 정보 단말(personal digital assistant: PDA), 스마트폰, 랩탑, 넷북, 퍼스널 컴퓨터, 무선 센서, 소비자 전자 기기 등을 포함할 수 있다.

통신 시스템(100)은 기지국(114a) 및 이동국(114b)을 또한 포함할 수 있다. 각각의 기지국(114a, 114b)은 CN(106), 인터넷(110) 및/또는 다른 네트워크(112)와 같은 하나 이상의 통신 네트워크로의 액세스를 용이하게 하기 위해 WTRU(102a, 102b, 102c, 102d) 중 적어도 하나와 무선으로 인터페이스하도록 구성된 임의의 유형의 디바이스일 수 있다. 예로서, 기지국(114a, 114b)은 기지국 송수신기(base transceiver station: BTS), 노드-B, 진화된 노드-B(evolved Node-B: eNB), 홈 노드 B(home Node-B: HNB), 홈 eNB(HeNB), 사이트 콘트롤러, 액세스 포인트(access point: AP), 무선 라우터 등일 수 있다. 기지국(114a, 114b)은 단일 요소로서 각각 도시되어 있지만, 기지국(114a, 114b)은 임의의 수의 상호 접속된 기지국 및/또는 네트워크 요소를 포함할 수 있다는 것이 이해될 수 있을 것이다.

기지국(114a)은 기지국 콘트롤러(BSC), 무선 네트워크 콘트롤러(radio network controller: RNC), 릴레이 노드(relay node) 등과 같은 네트워크 요소(도시 생략) 및/또는 다른 기지국을 또한 포함할 수 있는, RAN(104)의 부분일 수 있다. 기지국(114a) 및/또는 기지국(114b)은 셀(도시 생략)이라 칭할 수 있는 특정 지리학적 영역 내에서 무선 신호를 전송 및/또는 수신하도록 구성될 수 있다. 셀은 또한 셀 섹터로 분할될 수 있다. 예를 들어, 기지국(114a)과 연계된 셀은 3개의 섹터로 분할될 수 있다. 따라서, 일 실시예에서, 기지국(114a)은 3개의 송수신기, 즉 셀의 각각의 섹터에 대해 하나씩의 송수신기를 포함할 수 있다. 다른 실시예에서, 기지국(114a)은 다중 입력 다중 출력(multiple-input multiple output: MIMO) 기술을 이용할 수 있고, 따라서 셀의 각각의 섹터에 대해 다수의 송수신기를 이용할 수 있다.

기지국(114a, 114b)은 임의의 적합한 무선 통신 링크[예를 들어, 무선 주파수(radio frequency: RF), 마이크로파, 적외선(infrared: IR), 자외선(ultraviolet: UV), 가시광 등]일 수 있는 공중 인터페이스(116)를 통해 WTRU(102a, 102b, 102c, 102d) 중 하나 이상과 통신할 수 있다. 공중 인터페이스(116)는 임의의 적합한 무선 액세스 기술(radio access technology: RAT)을 사용하여 설정될 수 있다.

더 구체적으로, 전술된 바와 같이, 통신 시스템(100)은 다중 접속 시스템일 수 있고, CDMA, TDMA, FDMA, OFDMA, SC-FDMA 등과 같은 하나 이상의 채널 액세스 방안을 채용할 수 있다. 예를 들어, RAN(104) 내의 기지국(114a) 및 WTRU(102a, 102b, 102c, 102c)은, 광대역(wideband) CDMA(WCDMA)를 사용하여 공중 인터페이스(116)를 설정할 수 있는 범용 이동 통신 시스템(universal mobile telecommunications system: UMTS) 지상 무선 접속(terrestrial radio access)(UTRA)과 같은 무선 기술을 구현할 수 있다. WCDMA는 고속 패킷 액세스(high-speed packet access: HSPA) 및/또는 진화된(evolved) HSPA(HSPA+)와 같은 통신 프로토콜을 포함할 수 있다. HSPA는 고속 하향링크 패킷 액세스(HSDPA) 및/또는 고속 상향링크 패킷 액세스(HSUPA)를 포함할 수 있다.

다른 실시예에서, 기지국(114a) 및 WTRU(102a, 102b, 102c)는 장기 진화(long term evolution: LTE) 및/또는 LTE-어드밴스드(advanced)(LTE-A)를 사용하여 공중 인터페이스(116)를 설정할 수 있는 진화된 UTRA(evolved UTRA: E-UTRA)와 같은 무선 기술을 구현할 수 있다.

다른 실시예에서, 기지국(114a) 및 WTRU(102a, 102b, 102c)는 IEEE 802.16[즉, 마이크로파 액세스를 위한 전세계 상호 운용성(worldwide interoperability for microwave access(WiMAX)], CDMA2000, CDMA2000 1X, CDMA 2000 진화된-데이터 최적화(evolution-data optimized: EV-DO), 인터림 표준(Interim Standard) 2000(IS-2000), 인터림 표준 95(IS-95), 인터림 표준 856(IS-856), 모바일 통신을 위한 글로벌 시스템(global system for mobile communications: GSM), GSM 전개를 위한 향상된 데이터 레이트(enhanced data rates for GSM Evolution: EDGE), GSM/EDGE(GERAN) 등과 같은 무선 기술을 구현할 수 있다.

도 1a의 기지국(114b)은 예를 들어 무선 라우터, HNB, HeNB 또는 AP일 수도 있고, 사업장, 가정, 차량, 대학 교정 등과 같은 로컬화된 영역에서 무선 접속성을 용이하게 하기 위해 임의의 적합한 RAT를 이용할 수도 있다. 일 실시예에서, 기지국(114b) 및 WTRU(102c, 102d)는 무선 근거리 통신망(wireless local area network: WLAN)을 설정하기 위해 IEEE 802.11과 같은 무선 기술을 구현할 수 있다. 다른 실시예에서, 기지국(114b) 및 WTRU(102c, 102d)는 무선 개인 영역 통신망(wireless personal area network: WPAN)을 설정하기 위해 IEEE 802.15와 같은 무선 기술을 구현할 수 있다. 또 다른 실시예에서, 기지국(114b) 및 WTRU(102c, 102d)는 피코셀(picocell) 또는 펨토셀(femtocell)을 설정하기 위해 셀룰러-기반 RAT(예를 들어, WCDMA, CDMA2000, GSM, LTE, LTE-A 등)를 이용할 수 있다. 도 1a에 도시되어 있는 바와 같이, 기지국(114b)은 인터넷(110)으로의 직접 접속을 가질 수 있다. 따라서, 기지국(114b)은 CN(106)을 통해 인터넷(110)에 액세스하도록 요구되지 않을 수도 있다.

RAN(104)은 음성, 데이터, 애플리케이션 및/또는 보이스 오버 인터넷 프로토콜(voice over Internet protocol: VoIP) 서비스를 WTRU(102a, 102b, 102c, 102d) 중 하나 이상에 제공하도록 구성된 임의의 유형의 네트워크일 수 있는 CN(106)과 통신할 수 있다. 예를 들어, CN(106)은 호 제어(call control), 과금 서비스, 모바일 위치-기반 서비스, 선불 통화, 인터넷 접속성, 비디오 배포 등을 제공할 수 있고, 그리고/또는 사용자 인증(authentication)과 같은 고레벨 보안 기능을 수행할 수 있다. 도 1a에는 도시되어 있지 않지만, RAN(104) 및/또는 CN(106)이 RAN(104)과 동일한 RAT 또는 상이한 RAT를 채용하는 다른 RAN과 직접 또는 간접 통신할 수 있다는 것이 이해될 수 있을 것이다. 예를 들어, E-UTRA 무선 기술을 이용할 수 있는 RAN(104)에 접속되는 것에 추가하여, CN(106)은 또한 GSM 무선 기술을 채용하는 다른 RAN(도시 생략)과 통신할 수도 있다.

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

통신 시스템(100) 내의 일부 또는 모든 WTRU(102a, 102b, 102c, 102d)는 멀티-모드 능력을 포함할 수 있는 데, 즉 WTRU(102a, 102b, 102c, 102d)는 상이한 무선 링크를 통해 상이한 무선 네트워크와 통신하기 위한 다수의 송수신기를 포함할 수 있다. 예를 들어, 도 1a에 도시되어 있는 WTRU(102c)는 셀룰러-기반 무선 기술을 채용할 수 있는 기지국(114a)과, 그리고 IEEE 802 무선 기술을 채용할 수 있는 기지국(114b)과 통신하도록 구성될 수 있다.

도 1b는 도 1a에 도시되어 있는 통신 시스템(100) 내에 사용될 수도 있는 예시적인 WTRU(102)을 도시하고 있다. 도 1b에 도시되어 있는 바와 같이, WTRU(102)는 프로세서(118), 송수신기(120), 송수신 요소(transmit/receive element)(예를 들어, 안테나)(122), 스피커/마이크로폰(124), 키패드(126), 디스플레이/터치패드(128), 비착탈식 메모리(130), 착탈식 메모리(132), 전원(134), 글로벌 포지셔닝 시스템(global positioning system: GPS) 칩셋(136) 및 주변 장치(138)를 포함할 수 있다. WTRU(102)는 실시예와의 일관성을 유지하면서 상기 요소들의 임의의 서브-조합을 포함할 수 있다는 것이 이해될 수 있을 것이다.

프로세서(118)는 범용 프로세서, 특정 용도 프로세서, 통상의 프로세서, 디지털 신호 프로세서(digital signal processor: DSP), 마이크로프로세서, DSP 코어와 연계하는 하나 이상의 마이크로프로세서, 콘트롤러, 마이크로콘트롤러, 응용 주문형 집적 회로(application specific integrated circuits: ASIC), 필드 프로그램 가능 게이트 어레이(field programmable gate array: FPGA) 회로, 집적 회로(integrated circuit: IC), 상태 머신(state machine) 등일 수 있다. 프로세서(118)는 신호 코딩, 데이터 프로세싱, 전력 제어, 입출력 프로세싱 및/또는 WTRU(102)가 무선 환경에서 동작하는 것을 가능하게 하는 임의의 다른 기능성을 수행할 수 있다. 프로세서(118)는 송수신 요소(122)에 결합될 수 있는 송수신기(120)에 결합될 수 있다. 도 1b는 프로세서(118) 및 송수신기(120)를 개별 구성 요소로서 도시하고 있지만, 프로세서(118) 및 송수신기(120)는 전자 패키지 또는 칩 내에 함께 일체화될 수도 있다.

송수신 요소(122)는 공중 인터페이스(116)를 통해 기지국[예를 들어, 기지국(114a)]에 신호를 전송하거나 기지국으로부터 신호를 수신하도록 구성될 수 있다. 예를 들어, 일 실시예에서, 송수신 요소(122)는 RF 신호를 전송 및/또는 수신하도록 구성된 안테나일 수 있다. 다른 실시예에서, 송수신 요소(122)는 예를 들어, IR, UV 또는 가시광 신호를 전송 및/또는 수신하도록 구성된 이미터/검출기일 수 있다. 또 다른 실시예에서, 송수신 요소(122)는 RF 신호 및 광 신호의 모두를 전송 및 수신하도록 구성될 수 있다. 송수신 요소(122)는 무선 신호의 임의의 조합을 전송 및/또는 수신하도록 구성될 수 있다.

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

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

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

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

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

프로세서(118)는 또한 부가의 특징, 기능성 및/또는 유선 또는 무선 접속성을 제공하는 하나 이상의 소프트웨어 및/또는 하드웨어 모듈을 포함할 수 있는 다른 주변 장치(138)에 결합될 수 있다. 예를 들어, 주변 장치(138)는 가속도계, 전자 나침반(e-compass), 위성 송수신기, 디지털 카메라(사진 또는 비디오를 위한), 범용 직렬 버스(universal serial bus: USB) 포트, 진동 디바이스, 텔레비전 송수신기, 핸즈프리 헤드셋, Bluetooth

모듈, 주파수 변조(frequency modulated: FM) 무선 유닛, 디지털 음악 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저 등을 포함할 수 있다.

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

RAN(104)은 eNB(140a, 140b, 140c)를 포함할 수 있지만, RAN(104)은 실시예와의 일관성을 유지하면서 임의의 수의 eNB를 포함할 수 있다는 것이 이해될 수 있을 것이다. eNB(140a, 140b, 140c)는 공중 인터페이스(116)를 통해 WTRU(102a, 102b, 102c)와 통신하기 위한 하나 이상의 송수신기를 각각 포함할 수 있다. 일 실시예에서, eNB(140a, 140b, 140c)는 MIMO 기술을 구현할 수 있다. 따라서, eNB(140a)는 예를 들어 WTRU(102a)에 무선 신호를 전송하고 WTRU(102a)로부터 무선 신호를 수신하기 위해 다중 안테나를 사용할 수 있다.

각각의 eNB(140a, 140b, 140c)는 특정 셀(도시 생략)과 연계될 수 있고, 무선 리소스 관리 결정, 핸드오버 결정, 상향링크 및/또는 하향링크에서의 사용자의 스케쥴링 등을 취급하도록 구성될 수 있다. 도 1c에 도시되어 있는 바와 같이, eNB(140a, 140b, 140c)는 X2 인터페이스를 통해 서로 통신할 수 있다.

도 1c에 도시되어 있는 CN(106)은 이동도 관리 엔티티(mobility management entity: MME)(142), 서빙 게이트웨이(144) 및 패킷 데이터 네트워크(packet data network: PDN) 게이트웨이(146)를 포함한다. 각각의 상기 요소는 CN(106)의 부분으로서 도시되어 있지만, 이들 요소들 중 임의의 하나는 CN 사업자 이외의 엔티티에 의해 소유되고 그리고/또는 운영될 수 있다는 것이 이해될 수 있을 것이다.

MME(142)는 S1 인터페이스를 통해 RAN(104) 내의 각각의 eNB(140a, 140b, 140c)에 접속될 수 있고 제어 노드로서 기능할 수 있다. 예를 들어, MME(142)는 WTRU(102a, 102b, 102c)의 사용자의 인증, 베어러(bearer) 활성화/비활성화, WTRU(102a, 102b, 102c)의 초기 연결 중에 특정 서빙 게이트웨이의 선택 등을 담당할 수 있다. MME(142)는 또한 RAN(104)과 GSM 또는 WCDMA와 같은 다른 무선 기술을 이용하는 다른 RAN(도시 생략) 사이의 스위칭을 위한 제어 평면 기능을 제공할 수 있다.

서빙 게이트웨이(144)는 S1 인터페이스를 통해 RAN(104) 내의 각각의 eNB(140a, 140b, 140c)에 접속될 수 있다. 서빙 게이트웨이(144)는 일반적으로 WTRU(102a, 102b, 102c)로/로부터 사용자 데이터 패킷을 라우팅하고 포워딩할 수 있다. 서빙 게이트웨이(144)는 eNB간 핸드오버(inter-eNB handover) 중에 사용자 평면 앵커링(anchoring), 하향링크 데이터가 WTRU(102a, 102b, 102c)를 위해 이용 가능할 때 페이징 트리거링, WTRU(102a, 102b, 102c)의 콘텍스트 관리 및 저장 등과 같은 다른 기능을 또한 수행할 수 있다.

서빙 게이트웨이(144)는 PDN 게이트웨이(146)에 또한 접속될 수 있고, 이 PDN 게이트웨이는 WTRU(102a, 102b, 102c)에 인터넷(110)과 같은 패킷 교환 네트워크로의 액세스를 제공할 수 있어, WTRU(102a, 102b, 102c)와 IP-인에이블 디바이스 사이의 통신을 용이하게 한다.

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

"스폰서"는 공용 육상 모바일 네트워크(public land mobile network: PLMN)의 가입자일 수도 있는 사람(예를 들어, WTRU의 사용자)일 수도 있다. 간단화를 위해, 스폰서는 본 출원에서 서비스에 액세스하고 스폰서링을 개시하는 데 사용된 디바이스일 수도 있는 "WTRU1"이라 칭할 수도 있다. 그럼에도 불구하고, 디바이스가 아닌 사람이 스폰서일 수도 있고, 이 사람은 서비스에 액세스하고 스폰서링을 개시하기 위해 다른 디바이스[예를 들어, 퍼스널 컴퓨터(personal computer: PC)]를 사용할 수도 있다. 유사하게, "스폰서링된 엔티티"는 또한 사람, 통상적으로 PLMN 가입자(예를 들어, WTRU의 사용자)일 수도 있다. 간단화를 위해, 스폰서링된 엔티티는 본 출원에서, 스폰서링된 이벤트를 소비하는 데 사용된 디바이스일 수도 있는 "WTRU2"라 칭할 수도 있다.

사용자가 애플리케이션 서비스를 위한 다른 사용자를 스폰서링할 수도 있다. 스폰서링된 이벤트의 스폰서(WTRU1)와 수신인(WTRU2)이 동일한 모바일 네트워크 사업자(MNO)의 가입자들일 수도 있을 때 또는 WTRU2)가 MNO의 가입자가 아닐 수도 있을 때 통합. WTRU1의 MNO와 AP 사이의 서비스 협동이 존재할 수도 있다. 로밍 시나리오 및 WTRU1 및 WTRU2의 사용자가 상이한 MNO의 가입자들일 수도 있는 케이스를 포함하는 어떠한 서비스 협동도 없는 케이스가 또한 존재할 수도 있다.

스폰서링은 다른 사람들과 서비스의 공유를 가능하게 할 수도 있다. 일 사용 케이스에, 사용자는 이들의 홈에서 친구를 방문할 수도 있다. 방문 사용자는 유료 라이브 이벤트 스트리밍 서비스에 액세스를 가질 수도 있고, 친구의 텔레비전(TV)으로 라이브 이벤트를 시청하기를 원할 수도 있다. 다른 사용자 케이스에, 쇼를 시청하는 사용자는 대중 교통수단으로 친구를 만날 수도 있고, 친구의 디바이스 상에서 쇼의 상연을 복제할 수도 있다. 대안적으로, 사용자는 이후에(예를 들어, 1주일 이내에) 쇼를 시청하기 위해 다른 사람에게 디지털 초대장을 송신할 수도 있다. 모든 케이스에, 초대자는 연계된 서비스 요금의 책임이 있을 수도 있다. 애플리케이션 공급자는 또한 특정 레벨의 사용량까지 소정 형태의 무료 공유를 가능하게 할 수도 있다.

몇몇 통합의 레벨은 애플리케이션 스폰서링과 연계된 요금이 스폰서에게 적절하게 빌링될 수도 있는 것을 보장하도록 규정될 수도 있다. 현재, 스폰서쉽 정보는 스폰서링이 다른 최종 사용자들에 의해 제공될 수도 있는 동적 상황을 위해 적용 가능하지 않을 수도 있다.

셀룰러 네트워크 가입자는 사용자 데이터 액세스, 정책 및 과금을 위해 셀룰러 네트워크와 상호 운영하기 위한 협의를 갖는 애플리케이션을 사용하기 위해 다른 가입자를 스폰서링할 수도 있다. WTRU1은 그 MNO와 사전 협의에 의해 입장할 수도 있어 스폰서쉽을 가능하게 하여, 가능하게는 이를 서비스의 세트에 한정할 수도 있다. 이 정보는 MNO 네트워크[홈 가입자 서버(home subscriber server: HSS), 가입자 프로파일 저장소(subscriber profile repository: SPR)/사용자 데이터 저장소(user data repository: UDR)]에 저장할 수도 있다. WTRU1은 다른 사용자를 스폰서링하기 위해 애플리케이션 서버(application server: AS)에 제안할 수도 있다. AS는 인증을 점검할 수도 있고(네트워크 내에서 그리고 잠재적으로 WTRU2와 함께), 적절한 트리거(예를 들어, 하이퍼링크)를 WTRU2에 직접 또는 WTRU1을 통해 제공함으로써 제안을 수락할 수도 있다. 이 시퀀스의 부분은 미리 수행될 수도 있다(예를 들어, AS는 1회용 스폰서쉽 토큰을 WTRU1에 미리 제공할 수도 있음). 다음에, WTRU1은 이후에 이러한 토큰을 포함하는 유니폼 리소스 로케이터(uniform resource locator: URL)에 통신할 수도 있다. 그 후에, (예를 들어, 트리거를 수신한 직후에 또는 이 트리거를 수신한 1주 후에), WTRU2는 스폰서링된 애플리케이션 세션을 개시할 수도 있다. 세션 서비스 품질(quality of service: QoS) 및 과금 구성 중에, 도 2에 도시되어 있는 정책 및 과금 규칙 펑션(policy and charging rules function: PCRF)(240)은 이 스폰서링이 인가될 수도 있는 것을 보장하기 위해 스폰서의 프로파일을 점검할 수도 있다. 세션은 이어서 진행할 수도 있다. 스폰서는 이후에 스폰서링된 세션에 대해 과금될 수도 있다.

본 명세서에 설명되어 있는 바와 같이, 소정의 애플리케이션 서비스의 사용자들 사이에 스폰서링 및 공유를 지원하는 향상된 3GPP CN 동작은 서비스 자체에 적용될 수도 있고, 뿐만 아니라 네트워크 리소스 사용량을 마찬가지로 커버할 수도 있다[예를 들어, 액세스 서비스에 대한 피스폰서(sponsoree)에 충분한 리소스를 제공함]. 이는 피스폰서의 계획이 이 서비스의 레벨을 가능하게 하지 않는 경우에도 해당할 수도 있다. 도 2를 참조하면, AS(205)는 3GPP CN 운영자와 협의를 미리 가질 수도 있어, AS(205)가 가입자 프로파일 액세스, QoS 및 과금을 위해 CN과 상호 운영하는 것을 가능하게 한다.

가능하게는 타겟 WTRU 다양한 제한, 유효 시간 또는 비용의 견지에서 다양한 제한을 포함하는 애플리케이션-기초로 다른 사람들에게 스폰서링하도록 사용자에 의한 협의를 특정하는 사용자 프로파일 정보 요소(information element: IE)가 HSS 또는 SPR/UDR에 저장될 수도 있다. 스폰서링에 관련된 애플리케이션 특유 제한은 또한 HSS 245 또는 AS(205)에 도입될 수도 있다. 예를 들어 콘텐트의 부분으로의 동시에 스폰서링된 액세스의 수에 대한 제한이 존재할 수도 있다. 그룹 스폰서링 및 전달 가능한 스폰서쉽 토큰에 관련된 부가의 가입자 프로파일 IE가 또한 포함될 수도 있다.

최종 사용자는 애플리케이션 서버를 수반하여 다른 사용자에게 스폰서쉽을 제안할 수도 있다. 이 스폰서쉽은 서비스 자체를 위한 것일 수도 있고, 뿐만 아니라 액세스 네트워크 내의 리소스 할당의 비용을 커버할 수도 있다. 이 프로세스 중에, AS(205)는 스폰서 사용자 프로파일에 액세스할 수도 있고, 이 동작이 가능화되는 것을 검증할 수도 있고, 이어서 이후의 사용을 위해 내부 스폰서링된 이벤트 기술자(descriptor)를 생성할 수도 있다. AS(205) 또는 스폰서는 마지막으로 동작의 WTRU 타겟에 스폰서링된 서비스를 액세스하기 위해 정보를 통신할 수도 있다.

AS(205)는 WTRU가 다른 WTRU에 통신하여 스폰서링된 이벤트로의 이들의 액세스를 제공할 수 있는 스폰서쉽 토큰을 WTRU에 제공할 수도 있다. 이들 토큰은 제한된 범주, 사용량 넘버 또는 유효성 기간을 가질 수 있다. 이들 토큰은 소정 형태의 사전 할당된 스폰서링된 이벤트 기술자와 AS(205)에서 연계될 수도 있다. 스폰서쉽 토큰은 다른 WTRU에 전달 가능하거나 전달 가능하지 않을 수도 있다.

WTRU는 다른 사용자에 의해 스폰서링된 애플리케이션 세션을 개시할 수도 있고, 여기서 AS(205)는 현존하는 스폰서링된 이벤트 기술자와 이 세션 개시를 정합하고, PCFR(240)를 통해 세션 QoS 및 과금을 구성하고, 임의의 과금이 특이한 과금키를 사용하여 스폰서를 향해 유도될 수도 있는 것을 보장한다. PCRF(240)는 스폰서와 스폰서링된 WTRU의 모두의 가입자 프로파일을 점검하여 스폰서링된 이벤트가 인가되는 것을 보장할 수도 있다. 인가되면, 세션은 정책 및 과금 시행 펑션(policy and charging enforcement function: PCEF)을 통해 구성될 수도 있다. 메시지는 AS(205)와 PCRF(240) 사이의 Rx 기준점(235)을 통해 도입될 수도 있어, AS(235)에 의해 PCFR(240)를 통한 사전 인가 점검을 가능하게 한다.

설명된 흐름의 부분들은 독립적으로 적용될 수도 있어, 이에 의해 일 측에서 WTRU가 다른 WTRU와 서비스를 공유하는 것을 가능하게 할 수도 있고, 반면 다른 측에서 WTRU가 다른 WTRU에 제공된 서비스에 대해 과금될 수도 있는 것을 AS(205)가 CN으로부터 요청하는 것을 가능하게 할 수도 있다.

WTRU-기반 스폰서링의 조건 모드가 구현될 수도 있어, 이에 의해 WTRU는 다른 WTRU가 현존하는 계정을 사용하여 서비스에 액세스하는 것이 가능하지 않으면, 다른 WTRU에 대한 서비스를 스폰서링할 준비가 된 것을 선언한다.

비-3GPP 콘텍스트에서, QoS, 과금 및 가입자 프로파일로의 액세스를 위한 액세스 공급자 네트워크와 통합된 애플리케이션 서비스가 WTRU-기반 스폰서링 또는 공유를 가능화할 수도 있다.

3GPP의 스폰서링 특징은 동작을 가능화하는 토큰을 얻기 위해 스폰서 WTRU1로부터의 요청을 포함할 수도 있다. 피스폰서 WTRU2는 WTRU1을 대신하여 AS(205)가 세션을 스폰서링하게 하기 위해 트리거의 형태로서 토큰을 AS에 제공할 수도 있다(세션 개시 시간에).

AS(205)와 3GPP CN 사이의 향상된 인터페이스는 과금 이벤트가 AS(205)에 의해 송신되는 것을 가능하게 하도록 사용될 수도 있고, 여기서 과금 이벤트는 실제 트래픽이 아니라, AS(205)에 의해 제공된 서비스에 관련한다. Rx 기준점(235)은 이 특징을 지원하도록 수정될 수도 있다. AS(205)와 과금 시스템 사이의 중간부로서 게이트웨이 펑션(가능하게는, PCRF 또는 P-GW와 통합됨)이 구현될 수도 있다. 직접 인터페이스가 제3 자 AS와 과금 시스템 사이에 설정될 수도 있다.

동일한 MNO를 갖는 협동 케이스를 표현하는 제1 실시예에서, WTRU1 및 WTRU2는 MNO Y의 가입자이다. MNO Y와 AP X 사이에 협의가 존재한다.

도 2는 과금 노드(210)와 상호 접속된 애플리케이션 서버(AS)(205)를 포함하는 네트워크 아키텍처(200)를 도시하고 있다. 과금 노드(210)는 온라인 과금 시스템(online charging system: OCS)(215) 및 오프라인 과금 시스템(offline charging system: OFCS)(220)을 포함할 수도 있다. 아키텍처(200)는 AS(205)와 모바일 노드(mobile node: MN)와 같은 무선 송수신 유닛(WTRU) 사이에 상호 접속을 제공할 수도 있다. AS(205) 및 과금 노드(210)는 Mo 기준점(225)(온라인 과금을 위한) 및/또는 Mf 기준점(230)(오프라인 과금을 위한)을 통해 직접 상호 접속될 수도 있다. Mo 기준점(225)은 다이어미터 베이스 프로토콜(Diameter base protocol)에 기초하는 Ro 인터페이스에 기초할 수도 있고, Mf 기준점(230)은 다이어미터 베이스 프로토콜에 기초하는 Rf 인터페이스에 기초할 수도 있다. 아키텍처(200)에서, 서비스(또는 콘텐트)에 액세스하는 것에 관련된 요금은 Mo 기준점(225) 및 Mf 기준점(230)을 통해 전달될 수도 있다.

오프라인 과금과 관련하여, Rf 인터페이스[및 따라서, 마찬가지로 Mf 기준점(230)]는 이벤트-기반 과금 및 세션-기반 과금을 지원할 수도 있다. AS(205)는 계정 기록 유형(EVENT 또는 START/INTERIM/STOP)의 계정 데이터를 포함하는 계정 요청(accounting-request: ACR)을 송신할 수도 있다. 온라인 과금과 관련하여, Ro[및 따라서, 마찬가지로 Mo 기준점(225)]는 중간 이벤트 과금, 유닛 적립을 갖는 이벤트 과금 및 유닛 적립을 갖는 세션 과금을 지원할 수도 있다. AS(205)는 적절한 값으로 설정된 CC-요청된 유형을 포함하는 크레디트-제어-요청(credit-control-request: CCR)을 송신할 수도 있다.

AS(205) 및 PCRF(240) 과금 인터페이스는 후술되는 바와 같이 발생할 수도 있다. AS(205)는 Mo 기준점(225) 또는 Mf 기준점(230)을 통해 제1 WTRU 사용자(WTRU1)에 과금할 수도 있기 때문에, 사용자 스폰서링은 서비스 및 접속성에 대해 상이하게 가능화될 수도 있다.

일 절차는 서비스 스폰서링[AS(205)에 의해 전달된 콘텐트를 위한 액세스의 비용]을 위해 적용 가능할 수도 있고, 다른 절차는 접속성 스폰서링[제2 WTRU(WTRU2)를 위한 만족스러운 경험 품질(quality of experience: QoE)을 갖고 이 콘텐트를 전달하도록 요구되는 우선 트래픽 핸들링을 위한 비용)]을 위해 적용 가능할 수도 있다. 이 절차는 WTRU2 보다는 WTRU1에 직접 과금함으로써 또는 WTRU2에 과금하고 스폰서로서 WTRU1의 아이덴티티를 포함함으로써 Mo 기준점(225) 또는 Mf 기준점(230)을 통해 AS(205)에 의해 수행될 수도 있는 서비스의 사용자 스폰서링(예를 들어, 콘텐트 액세스를 위한 비용)을 포함할 수도 있다. OCS(215) 및 OFCS(220)는 이 CDR이 WTRU2의 사용자 스폰서링에 관련되는 것을 진술하는 IE를 포함하는 WTRU1을 위한 과금 데이터 기록(charging data record: CDR)을 생성할 수도 있다. 따라서, WTRU1의 청구서는 요금과 함께 이 정보를 언급할 수도 있다.

다른 절차는 Rx 메시지에 사용자 스폰서 아이덴티티를 언급함으로써 Rx 인터페이스(235)를 통해 AS(205)에 의해 수행된 사용자 스폰서링을 포함할 수도 있다.

사용자 스폰서링 유형은 애플리케이션 계층에서 WTRU1에 의해 제어될 수도 있다. AS(205)에 송신된 사용자 스폰서링 요청에서, 사용자 스폰서는 이하의 선택: 서비스만, 우선 트래픽 핸들링(즉, 접속성)만 및 서비스 및 우선 트래픽 핸들링 중에 스폰서링의 유형을 선택할 수도 있다. AS(205)는 WTRU1에 의해 선택되었던 사용자 스폰서링 유형에 따라, 전술된 절차를 독립적으로 사용하여 동작할 수도 있다.

시스템은 OCS(215)에 사용자-스폰서링 관련 점검을 가능화할 수도 있다. PCRF(235)는 WTRU1이 사용자 스폰서링을 수행하기 위해 충분한 크레디트를 갖는지를 점검하기 위해 OCS(215)에 대한 그 현존하는 인터페이스를 사용할 수도 있다. 예를 들어, 특정 사용자-스폰서링 정책 카운터가 WTRU1을 위한 사용자-스폰서링 한도(예를 들어, 1개월당 최대 100 Mbytes의 데이터 트래픽이 스폰서링될 수도 있음)를 표현하도록 MNO에 의해 셋업될 수도 있다.

Rx 기준점(235)을 통한 스폰서 아이덴티티의 분류가 발생할 수도 있다. Rx 시그널링은 정규 스폰서(MNO와의 스폰서링 협의를 갖는 엔티티)와 사용자 스폰서(예를 들어, WTRU1과 같은 가입자) 사이를 구별하도록 향상될 수도 있다. PCRF(240)는 사업자 정책에 의해 가능화되면, 스폰서링된 우선 트래픽 핸들링 프로파일에 인가 점검을 수행할 수도 있고, 반면 사용자 스폰서링을 위한 인가 점검은 상이할 수도 있다(예를 들어, 이 경우에 인가는 WTRU1의 가입자 프로파일을 점검하는 것을 요구할 수도 있음). 엔티티와 사용자 스폰서 사이의 이 구별은 스폰서-아이덴티티의 포맷의 소정의 휴리스틱(heuristics)을 사용하여 가능화될 수 있다[예를 들어, 이동국 국제 가입자 디렉토리 넘버(mobile station international subscriber directory numbers: MSISDNs)가 사용자 스폰서링만을 위해 사용될 수도 있음]. 그럼에도 불구하고, 이는 스폰서-아이덴티티 스트링을 분석하는 것과 엔티티와 사용자 스폰서 아이덴티티의 모두의 포맷에 부가의 제한을 부여하는 것을 필요로 할 수도 있는 데, 이는 시스템에 복잡성을 추가하고, 불필요한 스폰서링 특징을 제한할 수도 있다.

이하의 예시적인 방법이 적절한 분류를 위해 사용될 수도 있다. 이들은 스폰서 아이덴티티의 분류의 구현의 2개의 예이다.

제1 예에서, 유형 UTF8String의 사용자-스폰서-아이덴티티가 사용될 수도 있다. 스폰서링된-접속성-데이터는 스폰서-아이덴티티(MNO와의 스폰서링 협의를 갖는 엔티티를 위한) 또는 사용자-스폰서-아이덴티티(모바일 네트워크의 가입자인 스폰서를 위한)인 하나의 유일한 하나의 스폰서 아이덴티티 속성값 쌍(attribute value pair: AVP)을 포함할 수도 있다.

대안적으로, 제2 등가 인코딩이 예로서 제공될 수도 있고, 여기서 스폰서-아이덴티티는 양 유형의 스폰서에 대해 사용될 수도 있지만, 지원된 값 SPONSOR_TYPE_ENTITY (0), 이 AVP가 존재하지 않으면 디폴트값(역호환성을 위해) 및 SPONSOR_TYPE_USER (1)을 갖는 새로운 열거된 AVP 센서-아이덴티티-유형이 추가될 수도 있다.

제3 대안예로서, AVP 정의의 변화가 없지만, 스폰서 유형을 전달하는 방식으로 스폰서-아이덴티티를 사용하도록 협의하기 위한 AP 및 MNO에 남겨둔다. 예를 들어, 사용자 스폰서를 식별하기 위한 MSISDN 또는 [email protected] 또는 WTRU 네트워크 액세스 식별자(network access identifier: NAI) 및 엔티티 스폰서를 식별하기 위한 다른 스트링.

Mf 기준점을 통한 스폰서 아이덴티티의 분류가 발생할 수도 있다. 2개의 전개 시나리오가 현존하는 스폰서링된 데이터 접속성 특징에 대해 존재한다. 제1 시나리오에서, PCRF는 스폰서링된 인터넷 프로토콜(IP) 흐름을 위한 서비스 특유 과금키를 할당할 수도 있다. 그 결과, 계정 기록 및 사용량 데이터의 이후의 상관이 과금키를 사용하여 수행될 수도 있다. 제2 시나리오에서, 스폰서 식별자 및 애플리케이션 서비스 공급자 아이덴티티는 스폰서 식별자 및 애플리케이션 서비스 공급자 아이덴티티는 PCRF로부터 PCEF로 정책 제어 및 과금(policy control and charging: PCC) 규칙에 포함될 수도 있고, 이 PCEF는 이 정보를 과금 노드에 제공할 수도 있다.

이 제2 시나리오에서, Mf 기준점 시그널링(Rf 시그널링에 등가인 것으로 가정됨)은 MNO와의 협의를 갖는 사용자 스폰서와 엔티티 사이의 구별을 가능화하도록 향상될 수도 있다. 그 결과, 과금 노드[예를 들어, 과금 데이터 펑션(charging data function: CDF)]는 계정 기록이 사용자 스폰서에 관련될 수도 있고, 이 사용자에 요금을 적용할 수도 있다는 것을 인식할 수도 있다.

이하는 이 분류의 구현의 예이다. 서비스-데이터-컨테이너 AVP는 ACR 메시지 내에 포함될 수도 있다. 서비스-데이터-컨테이너 AVP는 ACR에 포함될 수도 있는 서비스-정보 AVP에 포함될 수도 있는 패킷 교환(packet switched: PS) 정보 AVP에 포함될 수도 있다.

- 또는 -

제1 예에서, 유형 UTF8String의 사용자-스폰서-아이덴티티가 사용될 수도 있다. 스폰서링된-접속성-데이터는 스폰서-아이덴티티(MNO와의 스폰서링 협의를 갖는 엔티티를 위한) 또는 사용자-스폰서-아이덴티티(모바일 네트워크의 가입자인 스폰서를 위한)를 포함할 수도 있다.

대안적으로, 제2 등가 인코딩이 예로서 제공될 수도 있고, 여기서 스폰서-아이덴티티는 양 유형의 스폰서에 대해 사용될 수도 있지만, 지원된 값 SPONSOR_TYPE_ENTITY (0), 이 AVP가 존재하지 않으면 디폴트값(역호환성을 위해) 및 SPONSOR_TYPE_USER (1)을 갖는 새로운 열거된 AVP 센서-아이덴티티-유형이 추가될 수도 있다.

다른 대안예로서, AVP 정의의 변화가 없지만, 스폰서 유형을 전달하는 방식으로 스폰서-아이덴티티를 사용하도록 협의하기 위한 AP 및 MNO에 남겨둘 수도 있다(예를 들어, 사용자 스폰서를 식별하기 위한 MSISDN 또는 [email protected] 또는 WTRU-NAI 및 엔티티 스폰서를 식별하기 위한 다른 스트링).

Mo 기준점을 통한 스폰서 아이덴티티의 분류가 발생할 수도 있다. Mf 기준점에 대해(즉, 오프라인 과금 케이스에 대해) 전술된 향상은 서비스-데이터-컨테이너 AVP가 또한 크레디트-제어-요청 메시지 내에 포함될 수도 있기 때문에, Mo 기준점에 대해(즉, 온라인 과금 케이스에 대해) 마찬가지로 적용 가능할 수도 있다.

MNO에 의해 소유된 AS가 발생할 수도 있다. 실시예는 AS가 MNO에 의해 소유되고 전개되는 케이스로 확장될 수도 있다. 이 경우에 해결책의 실제 시그널링의 변화가 존재하지 않는다.

마이너 향상의 예는: AS가 통상적으로 '스폰서쉽 허가가 AS를 수반함' 부분에서 WTRU1의 인가를 점검하기 위해 PCRF와 대화하지 않을 것이라는 것을 포함한다.

협동 케이스를 표현하는 제2 실시예에서, 동일한 MNO, WTRU1 및 WTRU2는 MNO Y의 가입자들이다. MNO Y와 AP X 사이에 협의가 존재한다.

AS가 과금 노드와 상호 접속되는 아키텍처가 구성될 수도 있다. Mo/Mf를 통한 과금 노드와 AS의 직접 상호 접속은 사용자에 직접 과금하기 위해 AS에 의해 사용될 수도 있고, 사용자 스폰서는 스폰서 서비스만, 우선 트래픽 핸들링만 또는 양자 모두일 수도 있다. AS는 MNO에 의해 소유되어 전개될 수도 있다.

도 3a 및 도 3b는 함께 취해져서, AS가 MNO에 의해 소유되고 전개될 수도 있는 사용자 스폰서링 절차(300)의 메시지 흐름도이다. 사용자는 동일한 MNO의 다른 가입자를 위한 애플리케이션 세션을 스폰서링할 수도 있다. 콘텍스트 정보는 네트워크 구조체를 위해 제공될 수도 있고, 여기서 AS는 모바일 네트워크와의 협의를 갖는다. WTRU1 및 WTRU2는 동일한 모바일 네트워크의 가입자들일 수도 있다.

WTRU1은 협의를 갖는 AS에 의해 MNO에 제공된 서비스에 액세스할 수도 있다. WTRU1은 홈 네트워크 내에 있을 수도 있고 또는 로밍할 수도 있다. WTRU2는 동일한 MNO의 가입자일 수도 있다. WTRU2는 홈 네트워크에 있을 수도 있다. WTRU1은 예를 들어, AS에 의해 제공된 영화 서비스로부터 특정 영화의 스트리밍, 또는 최대 2주 내에 4시간 동안 이 서비스로부터 임의의 영화의 스트리밍과 같은 애플리케이션 세션을 스폰서링하도록 추구할 수도 있다.

도 3a에 도시되어 있는 바와 같이, 사용자 스폰서링 데이터는 WTRU1의 사용자 프로파일 및/또는 AS 내에 구성될 수도 있다(302). WTRU1은 WTRU2로부터 아이덴티티 및 인가를 얻을 수도 있고, WTRU1은 또한 대신에 WTRU2를 수반하지 않고 WTRU2의 사용자 또는 WTRU2 자체의 아이덴티티를 얻을 수도 있다(304). WTRU2의 사용자 스폰서링이 개시될 수도 있다(서비스 스폰서링 유형 파라미터 또는 접속성 스폰서링 유형 파라미터 중 적어도 하나)(306). AS는 WTRU1 가입자가 인가된 사용자 스폰서링 동작을 갖는지 여부를 점검할 수도 있다(HSS, SPR 또는 UDR로부터)(308). AS는 WTRU2에 서비스 트리거를 제공할 수도 있고, 또는 AS는 트리거를 WTRU1에 제공할 수도 있고, 이 WTRU1은 트리거를 WTRU2에 제공한다(310). WTRU1은 범주/시간에서 제한될 수도 있는(그리고 서비스 스폰서링 유형 또는 접속성 스폰서링 유형 중 적어도 하나와 연계됨) 스폰서쉽 토큰을 얻을 수도 있다(가능하게는, 미리, 예를 들어 사인업 시간에 또는 매달)(312). WTRU1은 가능하게는 WTRU2에 그와 같이 행하도록 인가를 요청한 후에, WTRU2에 트리거(예를 들어, 토큰을 포함하는 URL)를 제공할 수도 있다(314).

도 3b에 도시되어 있는 바와 같이, WTRU2는 트리거(예를 들어, 임베디드 토큰을 갖는 하이퍼링크)를 사용하여 스폰서링된 세션을 개시할 수도 있다(316). AS는 스폰서와 세션을 정합할 수도 있다(예를 들어, 토큰을 사용하여)(318). AS는 과금 시스템과 상호 작용할 수도 있고(예를 들어, 오프라인 과금을 위한 향상된 계정 기록을 또는 온라인 과금을 위한 향상된 크레디트 제어 요청을 송신함), AS는 이벤트-기반 상호 작용(세션 중 또는 후에 현재 또는 이후에 발생함) 또는 세션-기반 상호 작용을 사용할 수도 있다(320). 이 상호 작용은 서비스 비용이 WTRU1에(WTRU가 스폰서 서비스를 선택하면) 또는 다르게는 WTRU2의 사용자에게 과금될 수도 있는 것을 보장할 수도 있다. AS는 WTRU1의 사용자가 스폰서 접속성을 선택하면 사용자 스폰서로서 WTRU1의 사용자를 포함하여 Rx 인터페이스를 통해 PCRF(QoS, 과금)에 이 세션을 위한 네트워크 리소스를 요청할 수도 있다(이 경우에, 프로세스의 부분으로서, AS 및/또는 PCRF는 스폰서링이 허용되는지를 확인하기 위해 WTRU1 및 WTRU2의 프로파일 정보를 점검할 수도 있음)(322). PCRF는 PCC 규칙을 PCEF에 송신할 수도 있고, QoS 규칙을 액세스 네트워크 노드에 송신할 수도 있다. 온라인 케이스에, PCRF는 사용자-스폰서링을 위한 WTRU1의 크레디트 잔액을 점검하기 위해 Sy 인터페이스를 사용할 수도 있다. AS는 WTRU2에 대답하고 서비스 전달로 진행할 수도 있다(324). PCEF는 세션 사용량 정보를 과금 엔티티에 통신할 수도 있다(326). 스폰서링된 접속성을 위한 과금은 이후에 WTRU1에 빌링하는 데 사용될 수도 있고, 또는 WTRU1의 선불로부터 공제될 수도 있다(328).

도 3c 및 도 3d는 함께 취해져서, 스폰서링 요청 절차(330)의 메시지 흐름도이다. 도 3c에 도시되어 있는 바와 같이, 초기 통신이 WTRU1과 WTRU2 사이에 설정되어(오프라인 및/또는 온라인) 아이덴티티 및 의지 및 특유의 서비스에 대해 스폰서링하고/스폰서링되는 능력을 교환할 수도 있다. WTRU1은 스폰서쉽 요청 메시지(타겟: WTRU2, 범주: 특유의 콘텐트, 기간, 비용, 타임 윈도우 등)를 AS에 송신할 수도 있어 WTRU2를 스폰서링하도록 제안하고, WTRU2의 아이덴티티, 뿐만 아니라 스폰서링에 대한 범주 정보(예를 들어, 특정 콘텐트로의 액세스 또는 콘텐트의 카테고리로서 비용 또는 서비스 기간의 견지에서 제한)를 제공할 수도 있다(334). 이 요청은 애플리케이션 계층에서 수행될 수도 있고, 서비스는 이 스폰서링 특징을 위한 명시적 지원을 가질 수도 있다.

스폰서링 요청의 수신시에, AS는 WTRU1이 다른 사용자를 스폰서링하도록 인가되는지를 점검할 수도 있다. 이 점검의 목표는 사용자 경험을 향상시키는 것이다. 일반적으로, WTRU2가 애플리케이션 세션을 개시할 때 절차가 이후에 실패되게 하는 것보다는 이 스테이지에 절차를 정지하는 것이 더 사용자 친화적일 수도 있다. 이 점검은 다수의 방식으로 수행될 수도 있다.

제1 대안예(336)에서, UDR이 사용될 수도 있다. AS는 스폰서링에 관련된 WTRU1 프로파일 정보에 대해 UDR에 질의할 수도 있고, WTRU1이 WTRU2를 스폰서링하도록 인가된 것을 검증할 수도 있다.

제2 대안예(338)에서, AS는 HSS로부터 스폰서링에 관련된 WTRU1 프로파일 정보를 얻을 수도 있다.

도 3d에 도시되어 있는 바와 같이, 제3 대안예(340)에서, AS는 사전-인가를 위해 PCRF에 문의할 수도 있다. PCRF는 이어서 SPR/UDR로부터 WTRU1 프로파일 정보를 얻고, WTRU2를 스폰서링하기 위해 그 인가를 점검하고, AS에 대답할 수도 있다. 이는 AS와 Rx 사이에 PCRF 및 Rx 기준점으로의 변화를 요구할 수도 있다(예를 들어, 새로운 세션을 생성하거나 현재 세션을 수정하는 대신에 미래의 세션의 사전-인가를 요청하기 위해 AAR 메시지로의 수정).

WTRU2의 사용자 프로파일은 또한 이 스폰서링된 이벤트가 인가되는지를 검증하는 데 사용될 수도 있다. 예를 들어, 스폰서링된 이벤트 현재 이력은, 이러한 쿼터(quota)가 AS에 의해 부여된 것으로 가정하여, WTRU2 스폰서링된 쿼터가 초과되어 있다는 것을 나타낼 수도 있다.

AS는 예를 들어, WTRU1이 서비스에 사인온하고 스폰서링을 가능화하기 위해 애플리케이션 계정을 구성할 때 이 점검을 더 조기에 수행할 수도 있어, AS가 이 결과를 캐싱할 수도 있게 한다. AS는 이 점검을 생략할 수도 있는 데, 이는 WTRU1이 이 서비스에 대해 WTRU2를 스폰서링하도록 인가되지 않으면 WTRU2가 스폰서링된 서비스를 거절하게 할 수도 있다.

AS는 몇몇 요금이 수반되면 WTRU1로부터 확인을 요청할 수도 있다(342). WTRU1은 확인 전에 최종 요금을 재검토할 수도 있다. 이는 WTRU2가 적절한 IP 접속성 계획을 갖지 않으면 요구될 수도 있는 임의의 예측되지 않은 추가요금을 포함할 수도 있다. AS는 WTRU1로부터 확인 요청할 수도 있다. AS는 미래 사용을 위한 내부 스폰서링된 이벤트 기술자를 생성할 수도 있다(344). AS는 이벤트 기술자에 이하의 것: WTRU1 및 WTRU2의 아이덴티티, 토큰, 트리거 URL, 애플리케이션 레벨 범주, 스폰서링된 이벤트를 소비하기 위한 만료일 및 허용된 서비스 기간의 모두 또는 일부를 포함할 수도 있다.

AS는 WTRU1에 포지티브 또는 네거티브 성공 코드로 대답할 수도 있다(346, 348). 성공의 경우에, AS는 트리거(예를 들어, 스폰서링된 이벤트를 식별하는 토큰을 포함하는 스폰서링된 콘텐트로의 하이퍼링크)를 WTRU2에 제공할 수도 있다[단문 메시징 서비스(short messaging service: SMS)를 사용하여](346). AS는 WTRU1에 응답시에 이 정보를 제공할 수도 있고, WTRU1은 예를 들어 근거리 통신, SMS 또는 이메일을 사용하여 WTRU2에 이를 송신할 수도 있다(346).

도 3e 및 도 3e는 함께 취해져서, 스폰서링된 세션 개시를 위한 절차(350)의 메시지 흐름도이다. 도 3e에 도시되어 있는 바와 같이, WTRU2는 예를 들어 토큰을 포함하는 하이퍼링크를 추종함으로써, 스폰서링된 애플리케이션 세션을 개시할 수도 있다(352). 스폰서링된 애플리케이션 세션을 시작하기 위한 결정은 WTRU2의 사용자에 의해 개시될 수도 있다(예를 들어, 편리한 시간에 스폰서링된 쇼를 시청). WTRU1의 사용자는 진행중인 라이브쇼를 공유하도록 WTRU2의 사용자를 스폰서링할 수도 있다. WTRU2는 스폰서쉽 개시 프로세스가 완료되자마자 서비스를 수신하는 것을 시작할 수도 있다. 스폰서링된 애플리케이션은 또한 AS에 의해 개시될 수도 있다(예를 들어, AS는 스폰서링된 라이브쇼가 시작할 때 WTRU2에 SMS를 송신할 수도 있음). WTRU2로부터 애플리케이션 세션 요청의 수신시에, AS는 예를 들어 WTRU2에 의해 사용된 서비스 URL에 포함된 토큰을 사용하고 이 토큰을 AS에 저장된 스폰서링된 이벤트 기술자 데이터 구조와 정합하여, 그 스폰서와 이 세션을 정합할 수도 있다(354). AS는 진행 전에 인가 점검을 수행할 수도 있다. 예를 들어, 인가 점검은 동시에 동일한 비디오쇼의 오버-스폰서링을 방지할 수도 있고, 스폰서링 특징의 남용을 방지할 수도 있다. AS는 QoS 및 과금을 위한 애플리케이션 세션(예를 들어, Rx를 통한 AAR 메시지)을 구성하도록 PCRF와 통신할 수도 있다. 예를 들어, 세션 식별자, 과금키, 스폰서 아이덴티티, 애플리케이션 서비스 공급자 아이덴티티 및 스폰서링에 관련된 다른 파라미터를 포함할 수도 있는 AAR 메시지가 송신될 수도 있다(356).

PCRF는 이 스폰서링된 이벤트가 인가되는 것을 보장하기 위해(예를 들어, WTRU1의 프로파일이 이 특정 서비스의 스폰서링을 인가함) 스폰서의 프로파일을 점검할 수도 있다(SPR/UDR로부터)(358). 예를 들어, WTRU2는 스폰서링될 수도 있는 WTRU의 화이트 리스트의 부분일 수도 있다. WTRU2 프로파일은 또한 이 동일한 테스트를 위한 입력으로서 사용될 수도 있다(예를 들어, WTRU2가 소정 기간 내에 너무 많은 횟수 스폰서링되어 있으면, 스폰서링된 이벤트는 인가되지 않을 수도 있고 그리고/또는 WTRU2의 데이터 계획이 요구된 QoS를 지원하지 않으면, WTRU1 프로파일은 초과요금이 수용 가능한지 여부를 지시할 수도 있음). PCRF는 PCEF를 통해 세션을 구성할 수도 있다. PCEF는 OCS로의 Gy 인터페이스를 통해 또는 OFCS로의 Gz 인터페이스를 통해 OCS 또는 OFCS와 같은 과금 시스템 노드와 상호 작용할 수도 있다.

PCRF는 WTRU1 및 WTRU2 프로파일 및 AS로부터의 요청에 제공된 정보에 기초하여 스폰서링하기 위해 WTRU1 인가를 평가할 수도 있다(360). PCRF는 현재 세션을 위한 과금키를 포함하는 응답(예를 들어, AA 답변)을 AS에 송신할 수도 있다(362).

도 3f에 도시되어 있는 바와 같이, PCRF는 세션의 흐름(들)을 구성하기 위해 PCEF에 요청[예를 들어, 라우팅 영역(routing area: RA) 요청]을 송신할 수도 있다(364). PCEF는 QoS 규칙을 설치하거나 수정하고(366), 응답을 PCRF에 송신할 수도 있다(368). PCEF는 과금키에 관련된 과금 정보를 송신할 수도 있다(이 스폰서링된 이벤트에 대해 WTRU2를 위한 특유의 과금키 또는 대안적으로 애플리케이션 서비스 공급자 아이덴티티 및 스폰서 아이덴티티와 연계된 WTRU2를 위한 과금키를 사용하여)(370). 스폰서링된 이벤트를 위한 과금은 이후에 WTRU1의 가입자에 빌링하는 데 사용될 수도 있고, 또는 WTRU1의 가입자 선불로부터 공제될 수도 있다(372).

다중 WTRU는 동시에 지원될 수도 있다. 예를 들어, 이벤트의 편성자는 이벤트시에 존재하는 모든 사용자들을 향해 서비스를 스폰서링할 수 있다. AS는 그룹 스폰서링을 지원할 수도 있다. 즉, AS는 하나 초과의 최종 사용자를 위해 유효한 토큰을 제공하여 프로세싱할 수도 있다. 예를 들어, AS는 이들이 단일의 유효일 동안에 스폰서링된 세션을 개시하기만 하면, 최대 1,000명의 최종 사용자를 위해 유효한 토큰을 방출할 수도 있다. 또한, 토큰은 WTRU1(또는 AS)에 의해 모든 수신인에 제공될 수도 있다. 예를 들어, WTRU1은 다중 SMS 메시지를 모든 의도된 수신인에 송신할 수도 있고, 또는 대안적으로 웹 또는 인터넷 페이지 상에 토큰을 포스팅할 수도 있다. WTRU1의 가입자 프로파일은 그룹 스폰서링을 가능화/불능화하고 또는 그룹 스폰서링에 대한 제한을 부여하도록 새로운 IE를 포함할 수도 있다. 예를 들어, 그룹 스폰서링을 위한 최대수의 수신인이 포함될 수도 있고 그리고/또는 그룹 스폰서링을 위한 비용 제한이 가능화될 수도 있다. 이들 정보 요소는 단일 애플리케이션의 범주를 가질 수도 있고 또는 모든 애플리케이션에 대해 포괄적일 수도 있다.

전달 가능한 토큰이 또한 지원될 수도 있다. 즉, 토큰은 WTRU2로부터 WTRU3로 전송될 수도 있다. WTRU3는 이어서 토큰을 사용하여 서비스를 소비한다. 예를 들어, 사용자는 생일 선물로서 스폰서링된 서비스 링크(예를 들어, 라이브 스포츠 이벤트로의 액세스)를 친구에게 송신하지만, 이 친구는 쇼를 시청할 시간을 갖지 않고 링크를 그의 아들(상이한 가입 하에서 그 자신의 디바이스 상에서 쇼를 시청할 것임)에게 전달하기로 결정한다.

도 3a 및 도 3b에 제시되어 있는 메시지 흐름은 전달된 토큰에 적용될 수도 있다. 토큰은 AS에서 전달 가능 또는 전달 불가능으로서 마킹될 수도 있다. 예를 들어, WTRU1은 "WTRU1 가입자가 WTRU2의 스폰서링을 개시한다" 요청에서 목적지 WTRU2 아이덴티티를 제공함으로써 AS로부터 전달 불가능 토큰을 요청할 수도 있다. WTRU1은 요청에 WTRU2의 아이덴티티를 포함하지 않을 수도 있다. AS는 WTRU1이 WTRU1에 토큰을 제공하기 전에 전달 가능한 토큰을 얻도록 허용된다. WTRU2 또는 다른 WTRU3이 전달된 토큰을 사용하여 서비스에 액세스할 때, AS는 스폰서링된 세션과 토큰을 정합하고, WTRU2가 WTRU2로부터 원본 스폰서쉽 요청에 명시적으로 언급되어 있으면 WTRU3으로부터 요청을 거절할 수 있다. 명시적인 명령이 존재하지 않으면, 스폰서링된 서비스는 더 진행할 수도 있다.

AS는 스폰서링의 어떠한 결정된 타겟도 갖지 않는 토큰을 제공할 수도 있다(예를 들어, AS가 월별 토큰의 세트를 WTRU1에 제공하는 전술된 경우에). 이 경우에, AS는 전달된 토큰에 유사한 방식으로 WTRU2/WTRU3으로부터 서비스 요청을 프로세싱할 수도 있다. 부가의 가입자 프로파일 IE는 가능/불가능 전달 가능 스폰서링을 포함하도록 이 상황에서 이용될 수도 있다(애플리케이션당 기초로 그리고/또는 비용 제한과 연계되어).

전술된 절차의 부분 적용이 또한 수행될 수도 있다. 예를 들어, 상기 절차의 더 적은 단계가 독립적으로 수행될 수도 있다. 공유는 과금 상에 포커싱하지 않고 발생할 수도 있고, 사용자 스폰서링은 예비 교환 중에 발생할 수도 있다.

과금에 대한 영향이 없는 공유와 관련하여, 스폰서링은 공유로 대체될 수도 있다. WTRU1은 라이브쇼로의 액세스 및/또는 쇼의 스트리밍과 같은 서비스로의 액세스를 가능하게 하도록 WTRU2에 토큰을 제공할 수도 있다(가능하게는, WTRU1의 디바이스 상에서 현재 재생되는 쇼와 동기화됨).

토큰의 교환은 전술된 바와 같이 발생할 수도 있다. WTRU2는 AS를 갖는 애플리케이션 세션을 개시할 수도 있다. AS는 공유 토큰으로서 토큰을 해석할 수도 있다. AS는 PCRF에 송신된 세션 셋업 메시지(예를 들어, AAR)에 스폰서 아이덴티티를 포함하지 않을 수도 있다. 애플리케이션 세션 QoS 및 과금은 전술된 바와 같이 취급될 수도 있다.

조건 스폰서링이 또한 발생할 수도 있다. 조건 스폰서링에 대해, WTRU1은 WTRU2와 세션을 공유하고 그리고 필요하다면 단지 스폰서링하기를 원한다. 예를 들어, WTRU2가 이미 AS에 의해 제공된 서비스의 월별 가입자이면, 통상적으로 WTRU1이 WTRU2에 스폰서링할 필요는 없다. 조건 스폰서링이 AS에서(즉, 애플리케이션 계층에서) 구현될 수도 있다. 애플리케이션은 WTRU2가 이미 서비스의 가입자인지를 점검하고, WTRU2가 멤버이면, 애플리케이션은 PCRF를 향한 세션 셋업 메시지(예를 들어, 다이어미터 AAR)에 스폰서 아이덴티티를 제공하지 않을 수도 있다. WTRU2가 가입자가 아니면(또는 WTRU2의 가입이 WTRU1이 WTRU2와 공유하기를 원하는 특정 서비스를 포함하지 않음), 스폰서쉽이 예를 들어 전술된 흐름에 따라 진행될 수도 있다.

사용자가 예비 교환(예를 들어, 병합된 계정을 위한 지원) 없이 스폰서링하는 상황에서, AS는 WTRU2가 WTRU1에 의해 스폰서링되는 것을 미리 인지할 수도 있다. 예를 들어, 상이한 가입을 갖는 다수의 가족 멤버는 단지 하나의 계정을 사용하여 단일의 서비스에 액세스하도록 결정할 수도 있다. 이러한 단일의 계정은 이들 특유의 다른 사용자들을 위한 모든 서비스 액세스를 스폰서링하도록 구성될 수도 있다. 이를 지원하기 위해, 사용자 가입자 프로파일은 특유의 파라미터[예를 들어, Y의 비용 한도 내의(또는 무제한 비용 한도를 갖는) 애플리케이션 X에 대해 스폰서링하기 위한 WTRU의 리스트]를 포함할 수도 있다.

본 설명의 적용은 일반적인 비-3GPP 특유 콘텍스트를 위해 제공된다. QoS 및 과금을 제공하고 제3 자 애플리케이션 공급자를 위한 통합 후크를 제공하는 액세스 네트워크 사업자는 사용자 스폰서링 및 공유를 지원하도록 향상될 수도 있다.

도 4는 애플리케이션 서비스 공급자(405)가 액세스 공급자 네트워크(410)와의 협의를 설정할 수도 있는 아키텍처 콘텍스트(400)를 도시하고 있다. 이 협의의 부분으로서, 애플리케이션 서비스 공급자(405)는 액세스 공급자 네트워크(410)를 거쳐서 서비스에 액세스하는 WTRU(예를 들어, WTRU1 및 WTRU2)에 대한 QoS 및 과금을 제어할 수도 있다. 애플리케이션 서비스 공급자(405)는 또한 가입자 프로파일의 부분에 액세스할 수도 있다.

도 5a 및 도 5b는 함께 취해져서, 사용자-기반 스폰서링을 구현하는 절차(500)의 고레벨 메시지 흐름도이다.

도 5a에 도시되어 있는 바와 같이, 제1 페이즈(505)에서, 시간 t0(예를 들어, 가입 시간)에, WTRU1 가입자 프로파일은 스폰서링이 인가되는 것을 지시하기 위해 업데이트될 수 있다(가능하게는 제한: 서비스당, 타겟 WTRU당, 소스 WTRU당 등을 갖는 일부). 이 업데이트는 가입자(예를 들어, 웹서비스를 통해) 또는 액세스 네트워크 사업자(예를 들어, 계약에 기초하여)에 의해 입력될 수도 있다. AS 및/또는 가입자 프로파일은 부가의 스폰서링 관련 서비스 세팅(예를 들어, 동일한 콘텐트로의 최대수의 동시 스폰서링된 액세스)을 보유할 수도 있다.

제2 페이즈(510)에서, 시간 t1에, WTRU1 가입자가 WTRU2에 스폰서링하기를 원할 때, 스폰서쉽 허가는 AS를 수반할 수도 있다. WTRU1은 WTRU2로부터 아이덴티티 및 가능하게는 인가를 얻을 수도 있다(대신에, WTRU1은 WTRU2를 수반하지 않고 WTRU2의 아이덴티티를 얻을 수도 있음)(515). WTRU1 가입자는 WTRU2의 스폰서링을 개시할 수도 있다(520). AS는 WTRU1 가입자가 이 종류의 사업자가 인가되어 있는지 여부를 점검할 수도 있다(QoS/과금 제어로부터 또는 가입자 프로파일로부터)(525). AS는 WTRU2에 서비스 트리거를 제공할 수도 있고 또는 AS는 WTRU1에 트리거를 제공할 수도 있고, WTRU1은 트리거를 WTRU2에 제공할 수도 있다(530). 대안적인 제2 페이즈(535)에서, 시간 t1에, WTRU1 가입자가 WTRU2를 스폰서링하기를 원할 때, 스폰서쉽 허가는 AS를 수반하지 않을 수도 있다. 가능하게는 미리(예를 들어, 사인업 시간에 또는 매달), WTRU1은 범주/시간에서 제한될 수도 있는 스폰서쉽 토큰을 얻을 수도 있다(540). WTRU1은 가능하게는 그와 같이 행하도록 WTRU2에 인가를 요청한 후에 WTRU2에 트리거(예를 들어, 토큰을 포함하는 URL)를 제공할 수도 있다(545).

도 5b에 도시되어 있는 바와 같이, 제3 페이즈(550)에서, 시간 t2에, WTRU2 가입자가 스폰서링된 세션을 개시하기를 원할 때, WTRU2는 트리거(예를 들어, 임베디드 토큰을 갖는 하이퍼링크)를 사용하여 스폰서링된 세션을 개시할 수도 있다(555). AS는 스폰서와 세션을 정합할 수도 있다(예를 들어, 토큰을 사용하여)(560). AS는 QoS/과금을 위한 세션을 구성할 수도 있다(565). 프로세스의 부분으로서, AS는 스폰서링이 허용되는지를 확인하기 위해 스폰서의 프로파일 정보(WTRU1 가입자)를 점검할 수도 있다. QoS/과금 제어는 세션을 구성하는 데 사용될 수도 있다(570). AS는 WTRU2에 대답하고 서비스를 전달하는 것으로 진행할 수도 있다(575).

애플리케이션 공급자는 WTRU1을 대신하여 WTRU2를 스폰서링할 수도 있다. 스폰서는 3GPP CN 관점으로부터, 애플리케이션 공급자일 수도 있다. WTRU1은 WTRU1을 대신하여 WTRU2를 스폰서링하도록 AS를 트리거링할 수도 있다. HSS 및/또는 SPR/UDR 내의 가입자 프로파일은 여전히 스폰서쉽 관련 구성(AS가 스폰서쉽 토큰을 허가하기 전에 점검할 수 있음)을 포함할 수도 있고 그리고/또는 AS는 모든 이 정보를 내부에 저장할 수도 있다.

제1 예에서, 사용자 기반 스폰서링 WTRU는 고정 기반으로 과금될 수도 있다. AS에 의해 제공된 서비스의 가입자로서 WTRU1은 무료로 또는 고정된 부가의 가입 요금의 부분으로서(통상적으로 최대 비용 한도 또는 최대수의 스폰서링된 이벤트 내에서) 다른 WTRU를 스폰서링하도록 자격 부여될 수도 있다. 3GPP CN 관점으로부터, 애플리케이션 공급자는 WTRU를 스폰서링할 수도 있다. 내부적으로, AS는 WTRU1이 스폰서리을 위한 허용된 한도 내에 체류하는 것을 보장할 수도 있다(예를 들어, 스폰서링된 이벤트의 카운트 및/또는 서비스 비용의 합을 유지함으로써).

도 6a 및 도 6b는 함께 취해져서, 다른 WTRU를 대신하여 WTRU 서비스를 스폰서링하는 애플리케이션 공급자를 위한 절차(600)의 고레벨 메시지 흐름도이다. 스폰서링은 무료이거나 고정된 가입 패키지의 부분이기 때문에, AS는 스폰서링된 세션의 비용이 WTRU1의 청구서에 통합될 수도 있는 것을 보장할 필요가 없을 수도 있다.

도 6a에 도시되어 있는 바와 같이, 제1 페이즈(605)에서, 시간 t0(예를 들어, 가입 시간)에, HSS/SPR/UDR 상의 WTRU1 가입자 프로파일은 스폰서링에 관련된 IE로 파퓰레이팅될(populated) 수도 있다. AS 상의 WTRU1 가입자 프로파일은 또한 이러한 IE로 파퓰레이팅될 수도 있다.

제2 페이즈(610)에서, 시간 t1에, WTRU1 가입자가 WTRU2에 스폰서링하기를 원할 때, 스폰서쉽 허가는 AS를 수반할 수도 있다. WTRU1은 WTRU2로부터 아이덴티티 및 가능하게는 인가를 얻을 수도 있다(대신에, WTRU1은 WTRU2를 수반하지 않고 WTRU2의 아이덴티티를 얻을 수도 있음)(615). WTRU1 가입자는 WTRU2의 스폰서링을 개시할 수도 있다(620). AS는 WTRU1 가입자가 이 종류의 사업자가 인가되어 있는지 여부를 점검할 수도 있다(AS 내에서 또는 PCRF를 통해 UDR, HSS 또는 SPR로부터)(625). AS는 서비스 WTRU2에 트리거를 제공할 수도 있고 또는 AS는 WTRU1에 트리거를 제공할 수도 있고, WTRU1은 트리거를 WTRU2에 제공할 수도 있다(630). 대안적인 제2 페이즈(635)에서, 시간 t1에, WTRU1 가입자가 WTRU2를 스폰서링하기를 원할 때, 스폰서쉽 허가는 AS를 수반하지 않을 수도 있다. 가능하게는 미리(예를 들어, 사인업 시간에 또는 매달), WTRU1은 범주/시간에서 제한될 수도 있는 스폰서쉽 토큰을 얻을 수도 있다(640). WTRU1은 가능하게는 그와 같이 행하도록 WTRU2에 인가를 요청한 후에 WTRU2에 트리거(예를 들어, 토큰을 포함하는 URL)를 제공할 수도 있다(645).

도 6b에 도시되어 있는 바와 같이, 제3 페이즈(650)에서, 시간 t2에, WTRU2 가입자가 스폰서링된 세션을 개시하기를 원할 때, WTRU2는 트리거(예를 들어, 임베디드 토큰을 갖는 하이퍼링크)를 사용하여 스폰서링된 세션을 개시할 수도 있다(655). AS는 스폰서와 세션을 정합할 수도 있다(예를 들어, 토큰을 사용하여)(660). AS는 WTRU1의 내부 프로파일에(또는 대안적으로 HSS/UDR/SPR 내에) 스폰서쉽 사용량을 업데이트할 수도 있다. AS는 스폰서로서 애플리케이션 공급자를 사용하여(스폰서링된 접속성을 위한 정규 절차에 따라), PCRF에 세션을 구성할 수도 있다(QoS, 과금)(665). AS는 WTRU2에 대답하고 서비스를 전달하는 것으로 진행할 수도 있다(670).

스폰서 WTRU는 스폰서링된 세션 기초로 과금될 수도 있다. WTRU1의 사용자는 고정 지불의 외부에서 다른 WTRU를 스폰서링한다. 예를 들어, 모든 세션의 비용은 피스폰서의 사용량의 유효 시간에 기초한다. 다양한 재정 모델이 사용될 수도 있다(예를 들어, WTRU1은 특정 비용까지 무료로 다른 사람들을 스폰서링하고, 이어서 초과 사용량에 대해 지불할 수도 있음). 애플리케이션 공급자는 세션을 효과적으로 스폰서링한다(3GPP CN 관점으로부터). 따라서, AS는 소정 종류의 과금 이벤트를 사용하여 WTRU1의 가입자를 향해 요금을 재지향할 필요가 있다. 이들 과금 이벤트는 PCEF를 통해 통과하는 실제 세션에 관련되지 않고, 대신에 1회 비용(원샷 이벤트)을 지시하거나 시간 기반 과금 이벤트의 시작 또는 종료를 지시한다.

과금 이벤트의 구현의 일 예에서, Rx 인터페이스는 과금 이벤트가 AS에 의해 PCRF에 송신되는 것을 가능하게 하도록 향상될 수도 있다(예를 들어, XXX에 대해 WTRU1 과금, 서비스의 비용). 과금 이벤트는 PCRF 및 PCEF를 통해 과금 서버에 전달될 수도 있다. 더 상세하게, 새로운 "과금-이벤트-유형" 속성값 쌍(AVP) 유형이 규정될 수도 있고, "1회", "시작" 및 "정지"와 같은 값을 가질 수도 있다. 이 AVP는 과금 이벤트를 표현하기 위해 AA-요청 명령(AS로부터 PCRF로)에 사용될 수도 있다. 세션 ID 값 또는 범위는 과금 이벤트 유형을 위해 관련하도록 적립될 수도 있다(즉, 이 세션 ID는 결코 실제 세션에 관련되지 않음).

AS는 오프라인 및/또는 온라인 과금 시스템과 직접 상호 접속을 가질 수도 있다. 제3 자 AS와 과금 시스템 사이의 이들 새로운 인터페이스는 과금 트리거 펑션(AS)과 온라인 과금 펑션 사이에 Ro를, 그리고 과금 트리거 펑션(AS)과 오프라인 과금 펑션 사이에 Rf를 포함하는 기준점에 기초할 수도 있다.

AS는 과금 게이트웨이를 통해 과금 시스템(들)과 상호 접속할 수도 있다. 이 과금 게이트웨이는 과금 펑션에 대한 기준점으로의 과금 트리거 펑션의 역할을 가질 수도 있다. 기준점은 AS와 과금 게이트웨이 사이에 도입될 수도 있다. 이 기준점은 Ro, Rf 또는 이들 기준점의 기능성의 서브세트를 구현할 수도 있다.

도 7a, 도 7b 및 도 7c는 과금 이벤트가 제3 자 AS에 의해 3GPP CN에 송신되는 것을 가능하게 하는 아키텍처 도면을 도시하고 있다.

도 7a에서, 향상된 Rx 인터페이스(705)는 1회 과금 명령과 같은 과금 이벤트가 AS(710)에 의해 PCRF(715)에 송신되는 것을 가능하게 할 수도 있다.

도 7b에서, 온라인 과금 펑션(online charging function: OCF)(720) 및/또는 과금 데이터 펑션(charge data function: CDF)(725)과 같은 오프라인 과금 펑션으로의 직접 상호 접속이 과금 이벤트를 송신하기 위해 AS(730)에 의해 사용될 수도 있다.

도 7c에서, 과금 게이트웨이(745)를 통한 OCF(735) 및/또는 CDF(740)로의 간접 상호 접속이 과금 이벤트를 송신하기 위해 AS(750)에 의해 사용될 수도 있다.

도 8a 및 도 8b는 함께 취해져서, 사용자 스폰서링을 위한 절차(800)의 고레벨 메시지 흐름도이다. AS는 통상적으로, 스폰서쉽 허가가 AS 부분을 수반할 때 WTRU1의 인가를 점검하기 위해 PCRF와 대화하지 않을 수도 있다. 협동 케이스에, 동일한 MNO가 로밍 상황에 있는 상태에서, WTRU1 및 WTRU2는 동일한 MNO Y에 가입자가 되도록 가능화될 수도 있다. AP X는 MNO Y와 협의를 가질 수도 있다. WTRU2는 MNO W에서 로밍일 수도 있다. MNO W는 사용자에 대한 추가의 비용에서 MNO Y 가입자를 위한 우선 트래픽 핸들링을 제공하기 위해 MNO Y와의 로밍 협의를 가질 수도 있다.

도 8a에 도시되어 있는 바와 같이, HSS/SPR/UDR 상의 WTRU1 가입자 프로파일은 스폰서링에 관련된 IE로 파퓰레이팅될 수도 있다. AS 상의 WTRU1 가입자 프로파일은 또한 이러한 IE로 파퓰레이팅될 수도 있다(805).

스폰서쉽 허가가 AS를 수반할 때(810), WTRU1은 WTRU2로부터 아이덴티티 또는 인가를 얻을 수도 있고 또는 WTRU2를 수반하지 않고 WTRU2의 아이덴티티를 얻을 수도 있다(815). WTRU2의 사용자 스폰서링은 AS에 대해 WTRU1에 의해 개시될 수도 있다(서비스 스폰서링 유형 파라미터 또는 접속성 스폰서링 유형 파라미터 중 적어도 하나)(820). AS는 WTRU1 가입자가 사용자 스폰서링 동작이 인가되는지를 점검할 수도 있다(HSS, SPR 또는 UDR로부터)(825). AS는 WTRU2에 서비스 트리거를 제공할 수도 있고, 또는 AS는 서비스 트리거를 WTRU1에 제공할 수도 있고, 이는 서비스 트리거를 WTRU2에 제공한다(830).

스폰서쉽 허가가 AS를 수반하지 않을 때(835)(가능하게는, 미리, 예를 들어 사인업 시간에 또는 매달), WTRU1은 범주/시간에서 제한될 수도 있는(그리고, 서비스 또는 접속성 중 적어도 하나 중에 스폰서링 유형과 연계될 수도 있음) 스폰서쉽 토큰을 얻을 수도 있다(840). WTRU1은 가능하게는 그와 같이 행하도록 인가를 위해 WTRU2에 요청한 후에, WTRU2에 트리거(예를 들어, 토큰을 포함하는 URL)를 제공할 수도 있다.

도 8b에 도시되어 있는 바와 같이, WTRU2는 트리거(예를 들어, 임베디드 토큰을 갖는 하이퍼링크)를 사용하여 스폰서링된 세션을 개시할 수도 있다(850). AS는 스폰서와 세션을 정합할 수도 있고(예를 들어, 토큰을 사용하여), AS는 AS 내의 또는 HSS, UDR 또는 SPR 내의 WTRU1의 프로파일의 스폰서쉽 사용량을 업데이트할 수도 있고, AS는 WTRU1에 특유한 과금키를 선택할 수도 있다(855). AS는 과금 시스템(OCS 또는 OFCS)과 상호 작용할 수도 있다(예를 들어, 오프라인 과금을 위한 향상된 계정 기록 메시지 또는 온라인 과금을 위한 향상된 크레디트 제어 요청을 송신함으로써)(860). 이벤트-기반 상호 작용(세션 중 또는 후에 현재 또는 이후에 발생함) 또는 세션 기반 상호 작용은 서비스 비용이 WTRU1(WTRU1의 사용자가 스폰서 서비스를 선택하면)에 또는 WTRU2에 과금되는 것을 보장하는 데 사용될 수도 있다. WTRU1이 스폰서 접속성을 선택하면, AS는 는 Mo/Mf 기준점을 통해 WTRU1에 과금할 수도 있다(서비스 요금과 함께 또는 별도로)(860). AS는 WTRU1의 사용자가 스폰서 접속성을 선택하면(이 경우에 스폰서링된 접속성을 위한 정규 절차 후에) 스폰서로서 애플리케이션 공급자를 사용하여 Rx 인터페이스를 통해 PCRF 내에 세션(QoS 및 가능하게는 과금키)을 셋업할 수도 있다(865). PCRF는 과금 서브시스템과 통신할 수도 있는 PCEF에 PCC 규칙을 다운로드할 수도 있다. AS는 WTRU2에 대답하고 서비스를 전달하는 것으로 진행할 수도 있다(870).

도 9는 애플리케이션의 콘텍스트를 위한 네트워크 아키텍처(900)를 도시하고 있다. WTRU1 개입은 애플리케이션 계층에 있을 수도 있기 때문에, WTRU1은 후술된 해결책에 영향을 미치지 않고, 홈 네트워크 내에 또는 다른 PLMN 내에 표현될 수도 있다. WTRU2는 PLMN W에서 로밍할 수도 있다. 도 9는 홈-라우팅된 로밍 아키텍처를 도시하고 있고, 여기서 데이터 트래픽이 홈 네트워크를 통해 WTRU2로/로부터 라우팅될 수도 있다.

도 10은 다른 콘텍스트를 위한 네트워크 아키텍처(1000)를 도시하고 있다. WTRU2는 애플리케이션 계층에 있을 수도 있기 때문에, WTRU1은 후술된 해결책에 영향을 미치지 않고 홈 네트워크 내에 또는 다른 PLMN 내에 표현될 수도 있다. WTRU2의 WTRU2는 PLMN W에서 로밍한다. 도 10은 로컬 브레이크아웃 로밍 아키텍처를 도시하고 있고, 여기서 WTRU2로/로부터의 데이터 트래픽은 방문된 네트워크 PGW에서 브레이킹아웃될 수도 있다.

WTRU1은 애플리케이션 서비스 또는 우선 트래픽 핸들링 중 적어도 하나를 스폰서링할 수도 있다. 서비스의 사용자 스폰서링을 위해, AS는 WTRU1에 과금하기 위해 MNO Y를 갖는 Mo/Mf를 사용할 수도 있다. WTRU1이 WTRU2를 위한 우선 트래픽 핸들링을 스폰서링하면, AP X는 MNO Y와의 그 Rx 상호 접속을 통해 우선 트래픽 핸들링을 요청할 수도 있다. AP X는 Rx를 통한 요청에 스폰서 아이덴티티로서 WTRU1의 아이덴티티를 삽입할 수도 있다. PCRF Y는 WTRU1이 WTRU2를 스폰서링하도록 인가된 것을 보장하기 위해 점검을 수행할 수도 있고, 이어서 PCRF Y는 PCRF W를 통해 리소스를 요청하기 위해 S9를 사용한다.

WTRU1의 가입자 아이덴티티(ID)가 Rx를 통해 스폰서로서 설정될 수도 있는 로밍 케이스가 존재할 수도 있다. 로컬 브레이크아웃 케이스에서, PCRF Y는 S9를 통해 메시지 내에 스폰서 아이덴티티를 삽입할 수도 있다. PCRF W는 PDN GW W(또한 스폰서 아이덴티티를 포함함) 내에 PCC 규칙을 그리고 QoS 규칙을 액세스 노드에 다운로드할 수도 있다. PDN GW W는 스폰서에 과금할 수도 있다(즉, 사용자 아이덴티티로서 WTRU2를 사용하지만 스폰서로서 WTRU1을 언급하여 과금 관련 메시지를 송신하고, 또는 사용자 아이덴티티로서 WTRU1을 사용하고 가능하게는 WTRU2를 피스폰서로서 언급하여 과금 관련 메시지를 송신함). 마지막으로, WTRU1은 미리 적소에서 로밍 과금 메커니즘을 통해 과금될 수도 있다. 홈-라우팅 케이스에서, PCRF Y는 S9를 통해 메시지 내에 스폰서 아이덴티티를 삽입하거나 삽입하지 않을 수도 있다. PCRF W는 만일 존재하면 무시할 수도 있다. PCRF는 QoS 규칙을 액세스 노드에 다운로드할 수도 있다. 홈 네트워크에서, PDN GW Y는 스폰서에 과금할 수도 있다(즉, 사용자 아이덴티티로서 WTRU2를 사용하지만 스폰서로서 WTRU1을 언급하여 과금 관련 메시지를 송신하고, 또는 사용자 아이덴티티로서 WTRU1을 사용하고 가능하게는 피스폰서로서 WTRU2를 언급하여 과금 관련 메시지를 송신함). 마지막으로, WTRU1은 미리 적소에서 로밍 과금 메커니즘을 통해 과금될 수도 있다.

도 11a 및 도 11b는 함께 취해져서, 동일한 MNO 및 로밍을 갖는 로컬 브레이크아웃 협동 케이스를 위한 절차(1100)의 고레벨 메시지 흐름도이다. 그 결과, WTRU1은 OCS/OFCS Y를 통해 서비스에 대해 1회 그리고 WTRU1이 MNO W에서 로밍하였던것과 같이 MNO W를 통해 접속성에 대해 1회(즉, 우선 트래픽 핸들링) 과금될 수도 있다.

도 11a에 도시되어 있는 바와 같이, WTRU1의 사용자는 WTRU2의 사용자 스폰서링을 개시할 수도 있고(서비스 또는 접속성 중 적어도 하나), 이에 의해 WTRU2는 서비스 트리거를 얻을 수도 있다(비-로밍 케이스와 유사하게)(1105). WTRU2는 트리거(임베디드 토큰을 갖는 하이퍼링크)를 사용하여 스폰서링된 세션을 개시할 수도 있다(1110). AS는 스폰서와 세션을 정합할 수도 있고(예를 들어, 토큰을 사용하여, AS 내의 또는 HSS, UDR 또는 SPR 내의 WTRU1의 프로파일의 스폰서쉽 사용량을 업데이트함), AS는 WTRU1에 특유한 과금키를 선택할 수도 있다(1115). AS는 Rx 인터페이스를 통해 서비스 세션 트래픽을 위한 우선 트래픽 핸들링(WTRU1의 사용자의 스폰서 아이덴티티를 포함)을 셋업할 수도 있다(1120). PCRF는 사용자 스폰서링 인가를 위한 WTRU1의 가입자 프로파일을 점검할 수도 있고, 인터넷 프로토콜 접속성 액세스 네트워크(Internet protocol connectivity access network: IP-CAN) 세션 수정 절차의 부분으로서 WTRU2의 가입자 프로파일을 점검할 수도 있다(1125). 온라인 케이스에, PCRF는 사용자-스폰서링을 위한 WTRU1의 크레디트 잔액을 점검하기 위해 Sy 인터페이스를 사용할 수도 있다. WTRU2는 로밍할 수도 있기 때문에, PCRF Y는 PCRF에 IP-CAN 세션 수정 요청을 통신하기 위해 S9를 사용할 수도 있다(WTRU2는 사용자일 수도 있고, 스폰서 아이덴티티는 WTRU1의 사용자일 수도 있음)(1130).

도 11b에 도시되어 있는 바와 같이, 비-로밍 케이스에서와 같이, 세션 전, 중 및/또는 후에, WTRU1의 사용자가 서비스를 스폰서링하도록 선택하면, AS는 WTRU2의 서비스 액세스에 대해 WTRU1에 과금할 수도 있다(1135). PCRF W는 WTRU1의 사용자의 스폰서 아이덴티티를 포함하는 PCC 규칙을 PDN GW W에 다운로드하고, 또한 QoS 규칙을 액세스 노드 W에 다운로드할 수도 있다(1140). WTRU2는 우선 트래픽 핸들링을 갖는 서비스로의 액세스를 얻을 수도 있다(1145). PGW W는 Ro/Rf 인터페이스를 통해 OCS/OFCS에 과금 정보를 통신할 수도 있고, WTRU1은 세션의 스폰서로서 특정될 수도 있다(1150). 온라인 과금 케이스에, PGW W는 대신에 OCS W 대신에 직접 OCS Y와 통신할 수도 있다. 로밍 협의에 대해, MNO W 및 MNO Y 과금 시스템은 통신할 수도 있다(예를 들어, MNO W는 온라인 케이스에 WTRU1의 크레디트를 점검하고 적립해둘 수도 있고, MNO W는 오프라인 케이스에 CDR을 MNO Y에 제공할 수도 있음)(1155).

도 12a 및 도 12b는 함께 취해져서, 동일한 MNO 및 로밍을 갖는 홈-라우팅된 협동 케이스를 위한 절차(1200)의 고레벨 메시지 흐름도이다. 그 결과, WTRU1은 WTRU1이 MNO W에서 로밍했던 것처럼, OCS/OFCS Y를 통해 서비스에 대해 1회 그리고 MNO W를 통해 접속성에 대해 1회(즉, 우선 트래픽 핸들링) 과금될 수도 있다.

도 12a에 도시되어 있는 바와 같이, WTRU1의 사용자는 WTRU2의 사용자의 스폰서링(서비스 또는 접속성 중 적어도 하나)을 개시할 수도 있고, WTRU2는 서비스 트리거를 얻을 수도 있다(비-로밍 케이스에 유사하게)(1205). WTRU2는 트리거(예를 들어, 임베디드 토큰을 갖는 하이퍼링크)를 사용하여 스폰서링된 세션을 개시할 수도 있다. AS는 스폰서와 세션을 정합할 수도 있다(예를 들어, 토큰을 사용하여, AS 내의 또는 HSS, UDR 또는 SPR 내의 WTRU1의 프로파일의 스폰서쉽 사용량을 업데이트함)(1215). AS는 WTRU1에 특유한 과금키를 선택할 수도 있다. AS는 Rx 인터페이스를 통해 서비스 세션 트래픽을 위한 우선 트래픽 핸들링(WTRU1의 사용자의 스폰서 아이덴티티를 포함)을 셋업할 수도 있다(1220). PCRF는 사용자 스폰서링 인가를 위한 WTRU1의 가입자 프로파일을 점검할 수도 있고, IP-CAN 세션 수정 절차의 부분으로서 WTRU2의 가입자 프로파일을 점검할 수도 있다(1225). 온라인 케이스에, PCRF는 사용자-스폰서링을 위한 WTRU1의 크레디트 잔액을 점검하기 위해 Sy 인터페이스를 사용할 수도 있다. WTRU2는 로밍할 수도 있기 때문에, PCRF Y는 PCRF W에 IP-CAN 세션 수정 요청을 통신하기 위해 S9를 사용할 수도 있다(예를 들어, WTRU2가 사용자이고 스폰서 아이덴티티가 WTRU1의 사용자인 경우에 PCRF W에 QoS 규칙을 푸시함)(1230).

도 12b에 도시되어 있는 바와 같이, PCRF W는 PCW Y에 PCC 규칙(WTRU1의 스폰서 아이덴티티를 포함함)을 다운로드할 수도 있다(1235). PCRF W는 액세스 노드 W에 QoS 규칙을 다운로드할 수도 있다(1240). 비-로밍 케이스에서와 같이, 세션 전, 중 및/또는 후에, WTRU1이 서비스를 스폰서링하도록 선택하면, AS는 WTRU2의 서비스 액세스에 대해 WTRU1에 과금할 수도 있다(1245). WTRU2는 우선 트래픽 핸들링을 갖는 서비스에 액세스를 얻을 수도 있다(1250). PGW Y는 WTRU1이 세션의 스폰서로서 특정되는 Ro/Rf 인터페이스를 통해 OCS/OFCS에 과금 정보를 통신할 수도 있다(1255).

AP X는 Rx 인터페이스를 통해 스폰서로서 설정될 수도 있다. AP X는 스폰서를 모니터링하는 모든 메시지에 스폰서로서 WTRU1 대신에 사용될 수도 있다. 따라서, AP X는 관련 비용에 대해 MNO Y에 의해 과금될 수도 있다. 부가적으로, AS X는 우선 트래픽 핸들링의 비용을 반영하기 위해 Mo/Mf를 통해 WTRU1에 과금할 수도 있다.

WTRU1 및 WTRU2는 상이한 MNO(MNO Y 및 MNO Z, 각각)의 가입자들일 수도 있다. AP X는 MNO Y와의 협의를 가질 수도 있다. WTRU2는 그의 홈 네트워크에 있을 수도 있고 또는 로밍할 수도 있다. WTRU1은 서비스만을, 접속성만을 또는 양자 모두를 스폰서링하도록 선택할 수도 있다.

비-로밍 상황에서, WTRU2는 그의 홈 네트워크(Z)에 있다. WTRU1이 서비스 액세스에 대해 WTRU2를 스폰서링할 때, AS X는 Mo/Mf를 통해 WTRU1에 과금할 수도 있다. WTRU2는 다른 MNO의 가입자이다. WTRU1이 접속성(즉, 우선 트래픽 핸들링)에 대해 WTRU2를 스폰서링할 때, AP X는 PCRF Y를 통해 MNO Z 상에 네트워크 리소스를 적립하도록 Rx를 사용할 수도 있다. PCRF Y는 WTRU가 WTRU2를 스폰서링하도록 인가되는 것을 검증할 수도 있다. PCRF Y는 리소스를 효과적으로 적립할 수도 있는(예를 들어, PDN GW Z에 PCC 규칙을, 액세스 네트워크 Z 노드에 QoS 규칙을 다운로드함). PDN GW Z는 사용자로서 WTRU2를 그리고 스폰서로서 WTRU1을 사용하여, MNO Z의 과금 서브시스템과 과금 정보를 통신할 수도 있다. 마지막으로, WTRU1은 로밍 협의와 유사하게, MNO Z와 MNO Y 사이의 협의를 통해 과금될 수도 있다. 이 협의는 정상 로밍 협의의 마이너 확장으로서 효과적으로 보여질 수도 있고, 여기서 MNO Z는 MNO Y의 가입자인 사용자 스폰서를 대신하여 사용자에 대한 리소스를 적립하도록 협의한다.

도 13은 상이한 MNO를 갖는 비-로밍 협동 케이스를 위한 절차(1300)의 고레벨 메시지 흐름도를 도시하고 있다. 도 13에는 도시되어 있지 않지만, 각각의 PLMN(Y 및 Z)은 대응 PCRF(Y 및 Z) 및 액세스 노드(Y 및 Z)를 포함할 수도 있다. AS X는 서비스에 대해 WTRU1에 과금하고 PLMN Z 상에 네트워크 리소스를 적립하기 위해 PLMN Y와 그 서비스 협동을 사용할 수도 있다. 대안적으로, AP X는 MNO Z와의 비즈니스 관계 협의를 가질 수도 있다. WTRU1이 접속성에 대해 WTRU2를 스폰서링할 때, AS X는 PCRF Z를 통해 MNO Z 상에 네트워크 리소스를 직접 적립하기 위해 Rx를 사용할 수도 있다. 이 경우에, 이 단계에 앞서, AP X는 Mh를 통해 WTRU1의 가입자 프로파일에 액세스함으로써 WTRU2를 스폰서링하기 위해 WTRU1 인가를 검증할 수도 있다.

도 13에 도시되어 있는 바와 같이, WTRU1은 WTRU2의 사용자 스폰서링을 요청할 수도 있고, 트리거(서비스 스폰서링 유형 서비스 또는 접속성 스폰서링 유형 중 적어도 하나)를 얻을 수도 있다(1305). AS는 WTRU1의 사용자가 WTRU2의 사용자를 스폰서링하도록 인가되는 것을 검증할 수도 있다(1310). WTRU1은 WTRU2에 사용자 스폰서링 트리거를 전달할 수도 있다(1315). WTRU2는 AS 트리거를 사용하여 서비스에 액세스할 수도 있다(1320). AS는 서비스 액세스에 대해 WTRU1의 사용자에 과금할 수도 있다(Mo/Mf를 통해)(1325). AS는 Rx를 통해 리소스를 적립할 수도 있다(사용자가 WTRU2이고, 스폰서가 WTRU1인 경우)(1330). PCRF Y는 WTRU1에 대한 인가를 검증할 수도 있다(1335). PCRF Y는 S9를 통해 리소스를 적립할 수도 있다(사용자가 WTRU2이고, 스폰서가 WTRU1임)(1340). PCRF Z는 WTRU2에 대한 인가를 검증할 수도 있다(1345). PCRF Z는 리소스를 허가하고, PCW Z 및 액세스 노드 Z를 갖는 세션을 셋업할 수도 있다(1350). PLMN Z는 이어서 PLMN Y에 응답을 송신할 수도 있고(1355), PLMN Y는 이어서 AS X에 응답을 송신할 수도 있다(1360). WTRU2의 세션이 진행될 수도 있다(1365). WTRU1은 로밍형 협의를 통해 WTRU2의 접속성에 대해 과금될 수도 있다(1370).

도 14는 상이한 MNO를 갖는 비-로밍 협동 케이스를 위한 절차(1400)의 고레벨 메시지 흐름도를 도시하고 있다. 도 14에는 도시되어 있지 않지만, 각각의 PLMN(Y 및 Z)은 대응 PCRF(Y 및 Z) 및 액세스 노드(Y 및 Z)를 포함할 수도 있다. AS X는 PLMN Z 상에 네트워크 리소스를 적립하기 위해 서비스 및 PLMN Z와의 그 비즈니스 관계에 대해 WTRU1에 과금하도록 PLMN Y와의 그 서비스 협동을 사용할 수도 있다.

도 14에 도시되어 있는 바와 같이, WTRU1은 WTRU2의 사용자 스폰서링을 요청할 수도 있고, 트리거(서비스 스폰서링 유형 서비스 또는 접속성 스폰서링 유형 중 적어도 하나)를 얻을 수도 있다(1405). AS는 WTRU1의 사용자가 WTRU2의 사용자를 스폰서링하도록 인가되는 것을 검증할 수도 있다(1410). WTRU1은 WTRU2에 사용자 스폰서링 트리거를 전달할 수도 있다(1415). WTRU2는 AS 트리거를 사용하여 서비스에 액세스할 수도 있다(1420). AS는 서비스 액세스에 대해 WTRU1의 사용자에 과금할 수도 있다(Mo/Mf를 통해)(1425). AS는 Rx를 통해 리소스를 적립할 수도 있다(사용자가 WTRU2이고, 스폰서가 WTRU1인 경우)(1430). PCRF Z는 리소스를 허가하고, PCW Z 및 액세스 노드 Z를 갖는 세션을 셋업할 수도 있다(1435). PLMN Z는 AS X에 응답을 송신할 수도 있다(1440). WTRU2의 세션이 진행될 수도 있다(1445). WTRU1은 로밍형 협의를 통해 WTRU2의 접속성에 대해 과금될 수도 있다(1450).

WTRU2는 네트워크 W에서 로밍할 수도 있다. 메커니즘은 비-로밍 케이스에 유사하고, 주로 PCRF Z가 PLMN W에 네트워크 리소스를 적립하기 위해 S9를 사용할 수도 있는 점에서만 상이하다. WTRU1은 로밍형 협의를 통해 뿐만 아니라 비-로밍 케이스에서와 같이 WTRU2의 접속성에 대해 과금될 수도 있지만, 이 경우에 MNO W와 MNO Y 사이의 협의가 있다. 스폰서로서 WTRU1을 갖는 사용자 스폰서링된 요청을 수신할 때, PCRF W는 이러한 협의가 존재하거나 다르게는 스폰서링된 요청을 거절하는 것을 검증할 수도 있다.

도 15는 상이한 MNO를 갖는 로밍 협동 케이스를 위한 절차(1500)의 고레벨 메시지 흐름도를 도시하고 있다. 도 15에는 도시되어 있지 않지만, 각각의 PLMN(W, Y 및 Z)은 대응 PCRF(W, Y 및 Z) 및 액세스 노드(W, Y 및 Z)를 포함할 수도 있다. 도 15에 도시되어 있는 바와 같이, WTRU1은 WTRU2의 사용자 스폰서링을 요청할 수도 있고, 트리거(서비스 스폰서링 유형 서비스 또는 접속성 스폰서링 유형 중 적어도 하나)를 얻을 수도 있다(1505). AS는 WTRU1의 사용자가 WTRU2의 사용자를 스폰서링하도록 인가되는 것을 검증할 수도 있다(1510). WTRU1은 WTRU2에 사용자 스폰서링 트리거를 전달할 수도 있다(1515). WTRU2는 AS 트리거를 사용하여 서비스에 액세스할 수도 있다(1520). AS는 서비스 액세스에 대해 WTRU1의 사용자에 과금할 수도 있다(Mo/Mf를 통해)(1525). AS는 Rx를 통해 리소스를 적립할 수도 있다(사용자가 WTRU2이고, 스폰서가 WTRU1인 경우)(1530). PCRF Y는 WTRU1에 대한 인가를 검증할 수도 있다(1535). PCRF Y는 S9를 통해 리소스를 적립할 수도 있다(사용자가 WTRU2이고, 스폰서가 WTRU1임)(1540). PCRF Z는 S9를 통해 리소스를 적립할 수도 있다(사용자가 WTRU2이고, 스폰서가 WTRU1임)(1545). PCRF Z 및 W는 PGW Z(홈 라우팅된 액세스 케이스) 또는 PGW W(방문된 액세스 케이스) 및 액세스 노드 W를 수반하는 홈 라우팅된 또는 방문된 액세스 절차를 따라 리소스를 허가할 수도 있다(1550). PLMN W는 WTRU1의 사용자 스폰서링을 위해 PLMN Y로부터 인가를 수신할 수도 있다. 응답 메시지(1555)는 PLMN W로부터 PLMN Z로 PLMN Y로 AS X로 재차 캐스케이딩될(cascaded) 수도 있다. WTRU2의 세션이 진행될 수도 있다(1560). WTRU1은 W와 Y 사이의 로밍형 협의를 통해 WTRU2의 접속성에 대해 과금될 수도 있다(1565).

도 16은 상이한 MNO를 갖는 로밍 협동 케이스를 위한 절차(1600)의 고레벨 메시지 흐름도를 도시하고 있다. 도 16에는 도시되어 있지 않지만, 각각의 PLMN(W, Y 및 Z)은 대응 PCRF(W, Y 및 Z) 및 액세스 노드(W, Y 및 Z)를 포함할 수도 있다. 도 15에 도시되어 있는 시나리오와는 달리, 이 시나리오에서, 비즈니스 관계가 AS X와 PLMN Z 사이에 존재할 수도 있어, AX X가 PLMN Z와 직접 상호 작용하여 네트워크 리소스를 요청하는 것을 가능하게 한다. 도 16에 도시되어 있는 바와 같이, WTRU1은 WTRU2의 사용자 스폰서링을 요청할 수도 있고, 트리거(서비스 스폰서링 유형 서비스 또는 접속성 스폰서링 유형 중 적어도 하나)를 얻을 수도 있다(1605). AS는 WTRU1의 사용자가 WTRU2의 사용자를 스폰서링하도록 인가되는 것을 검증할 수도 있다(1610). WTRU1은 WTRU2에 사용자 스폰서링 트리거를 전달할 수도 있다(1615). WTRU2는 AS 트리거를 사용하여 서비스에 액세스할 수도 있다(1620). AS는 서비스 액세스에 대해 WTRU1의 사용자에 과금할 수도 있다(Mo/Mf를 통해)(1625). AS는 Rx를 통해 리소스를 적립할 수도 있다(사용자가 WTRU2이고, 스폰서가 WTRU1인 경우)(1630). PCRF Z는 S9를 통해 리소스를 적립할 수도 있다(사용자가 WTRU2이고, 스폰서가 WTRU1임)(1635). PCRF Z 및 PCRF W는 PGW Z(홈 라우팅된 액세스 케이스) 또는 PGW W(방문된 액세스 케이스) 및 액세스 노드 W를 수반하는 홈 라우팅된 또는 방문된 액세스 절차를 따라 리소스를 허가할 수도 있다(1640). PLMN W는 WTRU1의 사용자 스폰서링을 위해 PLMN Y로부터 인가를 수신할 수도 있다. 응답 메시지는 W로부터 Z로 AS X로 재차 캐스케이딩될 수도 있다(1645). WTRU2의 세션이 진행될 수도 있다(1650). WTRU1의 사용자는 W와 Y 사이의 로밍형 협의를 통해 WTRU2의 접속성에 대해 과금될 수도 있다(1655).

AP X는 WTRU1의 MNO Y와의 서비스 협동을 갖지 않을 수도 있다. WTRU1은 MNO Y와의 그 현재의 액세스 계획을 사용하여 AP X와 애플리케이션 세션을 개시할 수도 있다. 요구될 때, WTRU1은 세션을 위한 MNO Y에 의한 우선 트래픽 핸들링을 요청할 수도 있다. WTRU1은 프리뷰 기간 후에 우선 트래픽 핸들링을 확인할 수도 있다(또는 확인하지 않음). 확인될 때, WTRU1은 이후에 우선 트래픽 핸들링에 대해 빌링될 수도 있다.

상황에 따라, AP와 MNO 사이에 비즈니스 협의가 존재할 수도 있고 또는 존재하지 않을 수도 있다.

비즈니스 협의가 존재할 때, 서비스 협동이 존재하지 않을 수도 있다. 따라서, MNO Y는 AP X를 대신하여 WTRU1에 빌링하는 것이 가능하지 않을 수도 있다. 그럼에도 불구하고, AP X는 여전히 네트워크 리소스를 적립할 수도 있는 데(예를 들어, Rx를 통해), 이는 MNO Y와의 비즈니스 협의를 가질 수도 있기 때문이다. WTRU1을 과금하기 위해 Mo/Mf를 사용하는 대신에, AP X는 다른 메커니즘을 통해 WTRU1에 과금할 수도 있다(예를 들어, 크레디트 카드로부터 또는 AP X로부터 월별 명세서를 통해). 서비스 협동 협의가 존재하지 않더라도, MNO Y는 여전히 Rx를 통한 접속성의 사용자 스폰서링을 지원할 수도 있다(예를 들어, WTRU1은 WTRU2에 의한 네트워크 리소스 사용량을 위한 MNO Y에 의해 과금될 수도 있음).

비즈니스 협의가 존재하지 않을 때, 사용자는 우선 트래픽 핸들링을 얻을 수도 있다. 프리뷰 특징은 임의의 사용자가 우선 트래픽 핸들링에 요청하는 것을 가능하게 하도록 전개될 수도 있다. 사용자-스폰서링 방법은 특정 용도 AS(사용자 스폰서링 AS)의 이용을 통해 이 특징에 의해 완전하게 바이패스할 수도 있고, 이는 사용자 스폰서링 AS가 MNO Y와 이러한 협동을 가질 수도 있기 때문에, 협동 케이스에 미리 전개된 절차를 재사용하는 것을 가능하게 할 수도 있다.

비-로밍 상황에서 동일한 MNO를 갖고, 비즈니스 협의를 갖지 않는 비-협동 케이스에서, WTRU1 및 WTRU2는 모두 동일한 MNO Y의 가입자들일 수도 있다. MNO Y는 AP X와의 협의를 갖지 않을 수도 있다. WTRU1이 WTRU2의 세션의 스폰서링을 개시할 때, WTRU1은 1) 서비스만을 스폰서링하고, 2) MNO Y에 의한 우선순위 핸들링을 스폰서링하고, 또는 3) 서비스 및 MNO y에 의한 우선순위 핸들링의 모두를 스폰서링할 수도 있다.

케이스 1) 및 3)에서, 서비스/콘텐트 스폰서링은 AP X로부터 임의의 디지털 상품과 같은 것을 구매할 수도 있다. 이 프로세스는 애플리케이션 특정이고, 일 예에서(다른 가능한 시나리오 중에서) WTRU1은 AP X의 포털에서 구매를 수행하고, WTRU2에 이메일에 의해 송신될 수도 있는 하이퍼링크를 구비한다. AP X는 WTRU1에 과금할 수도 있다(예를 들어, WTRU1의 크레디트 카드 또는 다른 수단을 사용하여).

케이스 2) 및 3)에서, 사용자 스폰서링 AS가 존재할 수도 있다. 이 AS는 데이터 접속성을 위한 사용자 스폰서링 요청을 핸들링하는 책임이 있다. 사용자 스폰서링 AS는 예를 들어 MNO Y 또는 MNO Y와 서비스 협동 협의를 갖는 제3 자에 의해 전개된 전용 AS로서 전개될 수도 있다. WTRU1은 사용자 스폰서링 AS에 사용자 스폰서링 요청을 송신할 수도 있다. 이 요청은 만료 시간, 최대 시간 또는 비용 등, 뿐만 아니라 WTRU2가 아이덴티티를 언급할 수도 있다. WTRU1은 AS로부터 URL과 같은 트리거를 얻을 수도 있다. 대안적으로, AP는 (결정될) 사용자를 스폰서링하는 데 사용될 수도 있는 스폰서링 트리거를 미리 WTRU1에 제공할 수도 있다. WTRU1은 WTRU2에 트리거를 제공할 수도 있다. WTRU2는 이어서 트리거 뿐만 아니라 트래픽 필터와 같은 세션 정보를 포함하여, 사용자 스폰서링 AS에 우선 트래픽 핸들링을 요청할 수도 있다. 사용자 스폰서링 AS는 이어서 PCRF로의 Rx를 사용하여, WTRU2 대신에 세션 우선 트래픽 핸들링을 셋업할 수도 있다. 사용자 스폰서링 AS는 MNO에 의해 또는 MNO와의 AP 협동에 의해 동작된 AS이다.

도 17은 비-로밍 케이스(MNO Z의 WTRU2) 및 로밍 케이스(MNO W의 WTRU2)의 모두에 대한 동일한 MNO를 갖고 비즈니스 협의를 갖지 않는, 비-협동 케이스를 위한 절차(1700)의 고레벨 메시지 흐름도를 도시하고 있다.

동일한 MNO를 갖고 비즈니스 협의 및 로밍 상황을 갖지 않는 비-협동 케이스에, WTRU1과 같이 MNO Y의 가입자인 WTRU2는 MNO W에서 로밍한다. MNO W가 사용자에 대한 초과의 비용으로 사용자를 위한 우선 트래픽 핸들링을 제공하기 위해 MNO Y와의 로밍 협의를 갖는 것으로 가정하면, 전술된 케이스 1) 및 3)에서, 서비스/콘텐트 스폰서링은 MNO를 수반하지 않고 AP에 의해 수행될 수도 있다. 데이터 접속성의 사용자 스폰서링을 위해, 즉, 상기 케이스 2) 및 3)에, WTRU1은 사용자 스폰서링 AS Y를 통해 WTRU2의 우선 트래픽 핸들링을 스폰서링할 수도 있다. 이 변형예는 WTRU2가 도 17에 도시되어 있는 바와 같이 로밍하기 때문에 이제 우선 트래픽 핸들링을 설정하는 사용자 스폰서링 AS Y를 갖고 상기 비-로밍 변형예에 유사하다.

도 17에 도시되어 있는 바와 같이, WTRU1의 사용자는 WTRU2의 사용자의 사용자 스폰서링을 요청할 수도 있고, 트리거(스폰서링 유형 서비스)를 얻을 수도 있다(1705). WTRU1의 사용자는 WTRU2의 사용자 스폰서링을 요청하고 트리거(접속성만)를 얻을 수도 있다(1710). 대안적으로, WTRU1은 AS로부터 미리 사용자 스폰서링 트리거를 얻을 수도 있다(1715). WTRU1은 사용자 스폰서링 트리거를 WTRU2에 전달할 수도 있다(1720). WTRU2는 AS 트리거를 사용하여 서비스에 액세스할 수도 있다(1725). 애플리케이션 특정 스폰서링이 구현될 수도 있다(AS에 의해 과금된 WTRU1의 사용자)(1730). WTRU2의 사용자는 사용자 스폰서링 AS 트리거를 사용하여 우선 트래픽 핸들링을 요청할 수도 있다(1735). 사용자 스폰서링 AS는 비-로밍 케이스 또는 로밍 케이스에 대해 WTRU2의 사용자를 대신하여 우선 트래픽 핸들링을 셋업할 수도 있다(1740). WTRU1의 사용자는 로밍형 협의를 통해 MNO Y 또는 W에 의해 과금될 수도 있다.

도 18은 상이한 MNO를 수반하는 비-협동 상황을 위한 절차(1800)의 고레벨 메시지 흐름도를 도시하고 있다. WTRU2는 MNO Z의 가입자일 수도 있다(반면, WTRU1은 MNO Y의 가입자일 수도 있음). 제1 서브-케이스에, AP와 MNO Y 사이의 비즈니스 협의가 존재할 수도 있다. 제2 서브-케이스에, 이러한 비즈니스 협의가 존재하지 않을 수도 있다.

비즈니스 협의가 존재하는 경우에, 임의의 서비스 협동이 존재하지 않을 수도 있다. 따라서, MNO Y는 AP X를 대신하여 WTRU1에 빌링하는 것이 가능하지 않을 수도 있다. 그럼에도 불구하고, AP X는 여전히 네트워크 리소스를 적립할 수도 있다(예를 들어, Rx 인터페이스를 통해). AP X는 WTRU1을 대신하여 WTRU2를 스폰서링하는 것이 가능할 수도 있다. WTRU1에 과금하기 위해 Mo/Mf를 사용하는 대신에, AP X는 다른 메커니즘을 통해(예를 들어, 크레디트 카드를 통해 또는 AP X로부터의 월별 명세서를 통해) WTRU1에 과금할 수도 있다.

비-로밍 상황에서, 사용된 사용자 스폰서링 AS는 MNO Y 대신에 MNO Z에 의해(또는 협동하여) 전개될 수도 있다. MNO Z는 통상적으로 사용에 대해 초과의 비용으로 사용자를 위한 우선 트래픽 핸들링을 제공하기 위해 MNO Y와의 로밍 협의를 가질 수도 있다.

도 18에 도시되어 있는 바와 같이, WTRU1의 사용자는 WTRU2의 사용자의 사용자 스폰서링을 요청할 수도 있고, 트리거(스폰서링 유형 서비스)를 얻을 수도 있다(1805). WTRU1의 사용자는 WTRU2의 사용자 스폰서링을 요청할 수도 있고, 트리거(접속성만)를 얻을 수도 있다(1810). 대안적으로, WTRU1은 AS로부터 미리 사용자 스폰서링 트리거를 얻을 수도 있다(1815). WTRU1은 사용자 스폰서링 트리거를 WTRU2에 전달할 수도 있다(1820). WTRU2는 AS 트리거를 사용하여 서비스에 액세스할 수도 있다(1825). 애플리케이션 특정 스폰서링이 구현될 수도 있다(AS에 의해 과금된 WTRU1의 사용자)(1830). WTRU2의 사용자는 사용자 스폰서링 AS 트리거를 사용하여 우선 트래픽 핸들링을 요청할 수도 있다(1835). 사용자 스폰서링 AS는 비-로밍 케이스 또는 로밍 케이스에 대해 WTRU2의 사용자를 대신하여 우선 트래픽 핸들링을 셋업할 수도 있다(1840). WTRU1의 사용자는 로밍형 협의를 통해 MNO Z 또는 로밍형 협의를 통해 W에 의해 과금될 수도 있다.

MNO Z의 가입자인 WTRU2는 MNO W에 로밍할 수도 있다. MNO W가 사용자에 초과의 비용으로 사용자를 위한 우선 트래픽 핸들링을 제공하기 위해 MNO Y와의 로밍 협의를 가지면(즉, 로밍 협의가 WTRU2가 로밍하는 MNO와 WTRU1의 MNO 사이에 존재할 수도 있음), 서비스/콘텐트 스폰서링은 MNO를 수반하지 않고 AP에 의해 수행될 수도 있다. 데이터 접속성의 사용자 스폰서링을 위해, WTRU1은 사용자 스폰서링 AS Z를 통해 WTRU2의 우선 트래픽 핸들링을 스폰서링할 수도 있다. 이 변형예는 상기 비-로밍 변형예에 유사하다. 사용자 스폰서링 AS Z는 이제 WTRU2가 로밍하기 때문에, 우선 트래픽 핸들링을 설정하는 데 사용될 수도 있다.

WTRU1은 MNO Y의 가입자일 수도 있고 WTRU2는 MNO의 가입자가 아닐 수도 있다(예를 들어, ISDN 액세스 네트워크 가입자). AP X는 MNO Y와의 서비스 협동 협의를 가질 수도 있고, 또는 AP X는 이러한 협의를 갖지 않는다.

협동 케이스가 존재하는 상황에, 시작/정지 및 1회 이벤트를 지원하는 Rx를 통한 과금 이벤트 메시지가 사용될 수도 있다. AP와 MNO 사이의 직접 Mo/Mf 인터페이스가 마찬가지로 사용될 수도 있다. WTRU1의 청구서는 이 특정 요금이 실제로 WTRU2의 스폰서링된 세션이었다는 것을 언급할 수도 있다. 대안적으로, WTRU1의 청구서는 스폰서링된 아이덴티티(WTRU2, 캐롤 등)마다 하나의 아이템 대신에, 단일의 병합된 아이템에서 스폰서링된 이벤트에 대한 모든 요금을 재그룹화할 수도 있다 부가의 속성값 쌍(AVP)을 갖는 Mo/Mf 시그널링을 향상시키고 이를 사용함으로써 새로운 AVP는 ACR 메시지(Mf), CCR 메시지(Mo) 또는 다른 Mo/Mf 메시지에 있을 수도 있다. WTRU2가 MNO의 가입자가 아니기 때문에, 과금 메시지는 WTRU2의 사용자명을 사용하지 않아야 하고, 대신에 이들 메시지의 사용자명 AVP는 WTRU1의 네트워크 어드레스 식별자(Network Address Identifier: NAI)이어야 한다. 정규 과금과 사용자 스폰서링된 관련 과금 사이를 구별하기 위해, "사용자-스폰서링"이라 명명되는 새로운 AVP는 이 AVP가 존재하지 않을 때 디폴트값인 NOT_USER_SPONSORED (0) 및 현재 메시지가 사용자 스폰서링된 세션 또는 애플리케이션 특정 ID(예를 들어, 이 특정 스폰서링된 세션을 위해 일시적으로 할당된 사용자명), 이메일 어드레스, 프로세스의 부분으로서 WTRU1에 의해 제공되고 WTRU1만을 위해서만 의미있는 사용자명(예를 들어, WTRU1은 수신인으로서 "WTRU2"를 언급하고, 이 스트링은 실제 수신인을 WTRU1에 상기하기 위해서만 사용됨)와 같은 스폰서링된 사용자의 아이덴티티를 보유하는 UTF8String AVP에 관한 것인 것을 지시하는 USER_SPONSORED (1) 중 하나를 보유하는 열거된 AVP 또는 IP 어드레스이다.

도 19는 AS에 의해 CN(통상적으로 Mf를 통해 ACR 또는 Mo를 통해 CCR)에 송신된 과금 메시지가 스폰서링된 이벤트의 수신인을 식별하는 새로운 IE를 포함하도록 향상되어 있는 절차(1900)(AS가 Mo/Mf 기준점으로의 액세스를 갖는 아키텍처 선택에 따라)의 고레벨 메시지 흐름도를 도시하고 있다.

도 19에 도시되어 있는 바와 같이, WTRU2(다른 액세스 네트워크의)는 WTRU1으로부터 또는 AS로부터 서비스 트리거(예를 들어, URL)를 얻을 수도 있다(1905). WTRU2는 스폰서링된 세션을 개시할 수도 있다(1910). AS는 WTRU1의 프로파일로부터 인가를 검증할 수도 있다(1915). AS는 Mo/Mf를 통해 과금 시스템과 상호 작용할 수도 있다(예를 들어, 오프라인 과금을 위해 향상된 계정 기록 메시지 또는 온라인 과금을 위해 향상된 크레디트 제어 요청을 송신함)(1920). AS는 이벤트-기반 상호 작용(세션 중 또는 후에 현재 또는 이후에 발생함) 또는 세션-기반 상호 작용(세션 전, 세션 중 및 세션이 완료된 후에)을 사용할 수도 있다. 이 상호 작용은 서비스 비용이 WTRU1의 사용자에 과금되는 것을 보장할 수도 있다. AS는 WTRU2에 서비스를 전달할 수도 있다(1925).

비-협동 케이스에, AP X는 WTRU2의 데이터 접속성이 MNO Y의 제어 하에 있지 않기 때문에, WTRU1을 대신하여 WTRU2의 데이터 접속성 스폰서링을 가능화할 수 없다. AP X는 MNO Y와의 서비스 협의를 갖지 않고; 따라서 AP X는 Mo, Mf 또는 임의의 다른 인터페이스를 사용하여, MNO Y를 통해 서비스/콘텐트 액세스를 위해 WTRU1에 과금할 수 없다. 임의의 서비스/콘텐트 스폰서링이 AS에 의해 수행될 수도 있다(예를 들어, 애플리케이션이 크레디트 카드 서비스를 사용하여 과금을 관리하면 AS에 내부적으로).

WTRU1은 그 계정으로부터 WTRU2의 계정에 크레디트를 전달할 수도 있고, WTRU2는 WTRU1과 동일한 MNO 또는 상이한 MNO의 가입자일 수도 있고, WTRU2는 이어서 임의의 서비스 또는 데이터 접속성(전달 중에 WTRU1에 의해 설정된 제한을 갖거나 갖지 않고)을 갖고 크레디트를 소비할 수도 있다. WTRU1은 그녀의 계정으로부터 WTRU2의 계정으로 크레디트 전달을 요청하는 명령을 발행하여, 가능하게는 사용량에 대한 제한을 추가한다. 이후에, WTRU2가 MNO 과금 시스템을 통해 과금될 때, 과금 시스템은 사용량 조건이 충족되는지를 점검할 수도 있고, 이 경우에 WTRU1에 의해 제공된 크레디트가 사용된다. 다르게는, WTRU2는 정상적으로 과금될 수도 있다.

도 20a 및 도 20b는 함께 취해져서, WTRU1의 사용자가 WTRU2의 사용자에 크레디트를 전달하게 하기 위한 절차(2000)의 고레벨 메시지 흐름도이다. 새로운 크레디트 전달 지원 AS(credit transfer supporting AS: CTS-AS)가 사용될 수도 있다. CTS-AS는 크레디트 전달을 위한 요청을 수락할 수도 있고, 이어서 동작을 수행하기 위해 과금 시스템과 상호 작용할 수도 있다. CTS-AS는 MNO Y(및 교차-MNO 크레디트 전달을 지원하기 위해 MNO Z)와의 서비스 협동을 갖는 비-IMS AS로서 구현될 수도 있다. K라서, 초기 크레디트 전달 메시지(WTRU1으로부터 CTS-AS로)는 HTTP를 통해 XML과 같은 애플리케이션 계층 메시지로서 구현될 수도 있다. CTS-AS가 PLMN의 과금 시스템과 상호 접속하기 위해 Mo/Mf를 사용하는 경우에, CTS-AS는 WTRU1에 과금하기 위해(또는 과금 유닛을 적립하기 위해), 뿐만 아니라 WTRU2에 사용자-스폰서 크레디트를 허가/취소하기 위해 이들 인터페이스들을 사용할 수도 있다. 허가/취소 사용자-스폰서 크레디트 메시지는 Mo/Mf를 통한 새로운 메시지일 수도 있고 또는 이들은 Mo/Mf를 통한 현존하는 메시지 내에 새로운 정보 요소를 추가함으로써 가능화될 수도 있다. 허가/취소 사용자-스폰서 크레디트 메시지를 가능화하기 위한 현존하는 Mo/Mf(뿐만 아니라 Ro/Rf) 메시지 AVP에 대한 향상의 예는 전술된 바와 같이 전달될 수도 있는 스폰서 아이덴티티를 포함하고, 현존하는 요청-작용 AVP는 USER_SPONSORING_GRANT, USER_SPONSORING_GRANT_CANCELLATION과 같은 새로운 유형으로 확장될 수도 있고, 부가의 허가 정보(크레디트 금액 및 조건을 포함함)가 이하와 같이 새로운 AVP를 사용하여 전달될 수도 있다:

다중-서비스-크레디트-제어 AVP는 유형 그룹화된다. 예를 들어, 포함된 AVP "요청된-서비스-유닛"은 사용자 스폰서링된 허가된 금액을 보유하는 데 사용될 수도 있고(허가 요청시에), "사용자-서비스-유닛"은 실제 사용된 금액을 보유하는 데 사용될 수도 있다(취소 응답시에).

CTS-AS가 오프라인 또는 온라인 과금 시스템을 사용하여 WTRU1에 과금할 수도 있고(WTRU1의 가입자 프로파일에 따라), 이 CTS-AS는 MNO Y와의 그 서비스 협동을 통해 액세스할 수도 있다. CTS-AS는 예를 들어 양 경우에 이벤트 기반 과금을 사용할 수도 있다. 이 경우에, "적립금" 메시지가 실제로 전체 금액에 대한 요금이다. 허가에 시간 한도가 존재하면, CTS-AS는 미사용 부분에 대해 WTRU1에 환불할 수도 있다.

과금 노드(예를 들어, OCS; 예를 들어 CDF 펑션)는 사용자-스폰서링을 지원하고 관련 정보 요소의 세트: 스폰서링된 사용자 ID, 스폰서 ID, 조건 및 크레디트 계정을 유지하도록 향상된다. 이 정보는 과금 메시지(예를 들어, ACR 또는 CCR 메시지)의 수신시에 사용될 수도 있고, 정합이 존재하면, 계정에 과금하는 대신에 스폰서링된 크레디트를 소비할 수도 있다.

도 20a에 도시되어 있는 바와 같이, WTRU1은 WTRU2에 크레디트 전달을 요청할 수도 있다(조건과 연계될 수도 있음)(2005). 크레디트의 금액은 WTRU1의 계정에 적립될 수도 있다(2010). 허가 사용자 스폰서링된 크레디트가 WTRU2에 송신될 수도 있다(조건에 연계될 수도 있음)(2015). 과금 노드는 WTRU1의 조건(및 빌링 정보를 위한 WTRU1의 ID)과 스폰서링된 크레디트를 연계할 수도 있다(2020). WTRU2는 네트워크 리소스를 사용하고 그리고/또는 PDN Z와의 서비스 협동에 의해 AP에 의해 제공된 서비스를 소비할 수도 있다(2025). PDN Z 노드(예를 들어, PCRF) 또는 AS X는 WTRU2의 사용자에 과금할 수도 있다(2030). 과금 노드는 과금 정보(예를 들어, 애플리케이션명)를 WTRU1 사용자의 조건과 비교할 수도 있다(2035). 정합이 존재하면, WTRU1 사용자의 크레디트가 사용될 수도 있다. 이것이 충분하지 않으면, WTRU2 사용자의 정규 크레디트가 사용될 수도 있고, 나머지에 대해 정합이 존재하지 않으면, WTRU2의 정규 크레디트가 사용될 수도 있다.

도 20b에 도시되어 있는 바와 같이, WTRU2 사용자는 과금 시스템 정보에 기초하여 이후에 빌링될 수도 있다(2040). WTRU2 사용자의 청구서는 WTRU1의 사용자 아이덴티티 및 조건을 포함하는 특유의 아이템으로서 WTRU1의 사용자 스폰서링된 크레디트를 언급할 수도 있다. WTRU1의 사용자가 사용자 스폰서링된 크레디트 전달에 시간 한도를 설정하는 조건하에서(2045), WTRU1이 최대 시간 기간을 포함하는 경우에, 이 시점에 시간 기간은 이 특정 스폰서링을 위해 만료할 수도 있다(2050). WTRU2 사용자에 대한 사용자 스폰서링된 크레디트는 취소될 수도 있다(2055). 응답은 WTRU1의 사용자 크레디트가 얼마나 많이 실제로 사용되었는지를 지시한다(2060). WTRU1의 사용자는 소정 금액에 대해 과금될 수도 있고, 적립된 크레디트의 나머지는 릴리즈될 수도 있다(2065).

실시예

1. 무선 송수신 유닛(wireless transmit/receive unit: WTRU)에 의한 사용자 스폰서링의 방법으로서,

제1 WTRU가 애플리케이션 서버(application server: AS)를 거쳐 제2 WTRU의 사용자 스폰서링을 개시하는 단계;

제1 WTRU가 AS로부터 서비스 트리거를 수신하고 서비스 트리거를 제2 WTRU에 제공하는 단계;

제2 WTRU가 서비스 트리거를 사용하여 AS와의 스폰서링된 세션을 개시하는 단계; 및

AS가 제2 WTRU에 콘텐트를 전달하는 데 요구되는 우선 트래픽 핸들링을 제공하기 위해 네트워크에 요청을 송신하는 단계 - 제1 WTRU의 사용자는 우선 트래픽 핸들링에 대해 과금됨 -

를 포함하는 방법.

2. 실시예 1의 방법으로서,

AS가 온라인 과금 펑션(online charging function: OCF) 및 과금 데이터 펑션(charging data function: CDF)을 포함하는 과금 시스템과 직접 통신 링크를 설정하는 단계를 더 포함하는 방법.

3. 실시예 1 내지 2 중 어느 하나의 방법으로서,

제1 WTRU와 연계된 사용자 프로파일에 사용자 스폰서링 데이터를 구성하는 단계; 및

제1 WTRU가 제2 WTRU로부터 인가를 얻는 단계를 더 포함하는 방법.

4. 실시예 1 내지 3 중 어느 하나의 방법으로서, 서비스 트리거는 임베디드 토큰을 갖는 하이퍼링크와 연계되는 것인 방법.

5. 실시예 1 내지 4 중 어느 하나의 방법으로서, 서비스 트리거는 토큰을 포함하는 유니폼 리소스 로케이터(uniform resource locator: URL)와 연계되는 것인 방법.

6. 실시예 1 내지 5 중 어느 하나의 방법으로서, 제1 WTRU가 스폰서쉽 토큰을 얻는 단계를 더 포함하는 방법.

7. 실시예 1 내지 6 중 어느 하나의 방법으로서, 제1 WTRU의 가입자 프로파일은 애플리케이션 서버(application server: AS)에 상주하는 것인 방법.

8. 실시예 1 내지 7 중 어느 하나의 방법으로서, 제1 WTRU의 가입자 프로파일은 홈 가입자 서버(home subscriber server: HSS)에 상주하는 것인 방법.

9. 실시예 1 내지 8 중 어느 하나의 방법으로서, 제1 WTRU의 가입자 프로파일은 가입자 프로파일 저장소(subscriber profile repository: SPR)에 상주하는 것인 방법.

10. 실시예 1 내지 9 중 어느 하나의 방법으로서, 제1 WTRU의 가입자 프로파일은 사용자 데이터 저장소(user data repository: UDR)에 상주하는 것인 방법.

11. 실시예 1 내지 10 중 어느 하나의 방법으로서,

제1 WTRU는 크레디트를 제2 WTRU에 전달하도록 AS에 요청하는 단계를 더 포함하는 방법.

12. 무선 송수신 유닛(wireless transmit/receive unit: WTRU)에 의한 사용자 스폰서링의 방법으로서,

제1 WTRU가 애플리케이션 서버(application server: AS)로부터 제2 WTRU의 사용자 스폰서링을 요청하는 단계; 및

AS가 온라인 과금 펑션(online charging function: OCF) 및 과금 데이터 펑션(charging data function: CDF)을 포함하는 과금 시스템과 직접 통신 링크를 설정하는 단계

를 포함하는 방법.

13. 실시예 12의 방법으로서,

제1 WTRU가 AS로부터 사용자 스폰서링 트리거를 얻고 스폰서링 트리거를 제2 WTRU에 전달하는 단계;

제2 WTRU가 AS 트리거를 사용하여 AS로부터 서비스를 액세스하는 단계; 및

제2 WTRU와 AS 사이에 세션을 설정하는 단계를 더 포함하는 방법.

14. 실시예 12 내지 13 중 어느 하나의 방법으로서,

AS가 제2 WTRU에 콘텐트를 전달하는 데 필요한 우선 트래픽 핸들링을 제공하도록 네트워크에 요청을 송신하는 단계를 더 포함하고, 제1 WTRU의 사용자는 우선 트래픽 핸들링에 대해 과금되는 것인 방법.

15. 실시예 12 내지 14 중 어느 하나의 방법으로서, 제1 WTRU의 사용자는 로밍형 협의를 통해 제2 WTRU의 우선 트래픽 핸들링에 대해 과금되는 것인 방법.

16. 실시예 12 내지 15 중 어느 하나의 방법으로서,

AS가 제1 WTRU의 사용자가 제2 WTRU의 사용자를 스폰서링하도록 인가되는 것을 검증하는 단계;

제1 WTRU가 AS로부터 서비스 트리거를 수신하는 단계;

제1 WTRU가 서비스 트리거를 제2 WTRU에 제공하는 단계;

제2 WTRU가 서비스 트리거를 사용하여 AS와 스폰서링된 세션을 개시하는 단계; 및

제2 WTRU가 AS로부터 서비스를 수신하는 단계를 더 포함하는 방법.

17. 실시예 12 내지 16 중 어느 하나의 방법으로서,

제1 WTRU가 제2 WTRU에 크레디트를 전달하도록 AS에 요청하는 단계를 더 포함하는 방법.

18. 실시예 1 내지 17 중 어느 하나의 방법을 수행하도록 구성된 시스템.

19. 애플리케이션 서버(application server: AS)로서,

제2 무선 송수신 유닛(wireless transmit/receive unit: WTRU)을 스폰서링하는 제1 WTRU에 서비스 트리거를 전송하도록 구성된 송신기를 포함하고,

상기 송신기는 제2 WTRU에 콘텐트를 전달하는 데 필요한 우선 트래픽 핸들링을 제공하기 위해 네트워크에 요청을 전송하도록 더 구성되고, 제2 WTRU의 사용자는 온라인 과금 펑션(online charging function: OCF) 및 과금 데이터 펑션(charging data function: CDF)을 포함하는 과금 시스템을 거쳐 우선 트래픽 핸들링에 대해 과금되는 것인 애플리케이션 서버(AS).

20. 애플리케이션 서버(application server: AS)를 위한 방법으로서,

제2 무선 송수신 유닛(wireless transmit/receive unit: WTRU)을 스폰서링하는 제1 WTRU에 서비스 트리거를 전송하는 단계; 및

제2 WTRU에 콘텐트를 전달하는 데 필요한 우선 트래픽 핸들링을 제공하기 위해 네트워크에 요청을 전송하는 단계 - 제2 WTRU의 사용자는 온라인 과금 펑션(online charging function: OCF) 및 과금 데이터 펑션(charging data function: CDF)을 포함하는 과금 시스템을 거쳐 우선 트래픽 핸들링에 대해 과금됨 -

를 포함하는 방법.

21. 제1 무선 송수신 유닛(wireless transmit/receive unit: WTRU)으로서,

애플리케이션 서버(application server: AS)를 거쳐 제2 WTRU의 사용자 스폰서링을 개시하도록 구성된 송신기;

AS로부터 서비스 트리거를 수신하도록 구성된 수신기를 포함하고,

송신기는 제2 WTRU가 서비스 트리거를 사용하여 AS와 스폰서링된 세션을 개시할 수도 있도록 서비스 트리거를 제2 WTRU에 포워딩하도록 더 구성되고, 제1 WTRU의 사용자는 제2 WTRU에 제공된 서비스 및 우선 트래픽 핸들링에 대해 과금 시스템을 거쳐 과금되고, 과금 시스템은 온라인 과금 펑션(online charging function: OCF) 및 과금 데이터 펑션(charging data function: CDF)을 포함하는 제1 무선 송수신 유닛(WTRU).

22. 실시예 21의 제1 WTRU에 있어서, 서비스 트리거는 임베디드 토큰을 갖는 하이퍼링크와 연계되는 제1 WTRU.

23. 제1 무선 송수신 유닛(wireless transmit/receive unit: WTRU)을 위한 방법으로서,

애플리케이션 서버(application server: AS)를 거쳐 제2 WTRU의 사용자 스폰서링을 개시하는 단계;

AS로부터 서비스 트리거를 수신하는 단계; 및

제2 WTRU가 서비스 트리거를 사용하여 AS와 스폰서링된 세션을 개시할 수도 있도록 서비스 트리거를 제2 WTRU에 포워딩하는 단계 - 제1 WTRU의 사용자는 제2 WTRU에 제공된 서비스 및 우선 트래픽 핸들링에 대해 과금 시스템을 거쳐 과금되고, 과금 시스템은 온라인 과금 펑션(online charging function: OCF) 및 과금 데이터 펑션(charging data function: CDF)을 포함함 -

를 포함하는 방법.

24. 실시예 23의 방법으로서, 서비스 트리거는 임베디드 토큰을 갖는 하이퍼링크와 연계되는 것인 방법.

특징들 및 요소들이 특정 조합으로 전술되었지만, 당 기술 분야의 숙련자는 각각의 특징 또는 요소가 단독으로 또는 임의의 다른 특징들 및 요소들과 조합하여 사용될 수 있다는 것을 이해할 수 있을 것이다. 게다가, 본 명세서에 설명된 실시예들은 컴퓨터 또는 프로세서에 의해 실행을 위한 컴퓨터-판독 가능 매체에 합체된 컴퓨터 프로그램, 소프트웨어 또는 펌웨어에 구현될 수 있다. 컴퓨터-판독 가능 매체의 예는 전자 신호(유선 또는 무선 접속을 통해 전송됨) 및 컴퓨터-판독 가능 저장 매체를 포함한다. 컴퓨터-판독 가능 저장 매체의 예는 판독 전용 메모리(read only memory: ROM), 랜덤 액세스 메모리(random access memory: RAM), 레지스터, 캐시 메모리, 반도체 메모리 디바이스, 자기 매체(예를 들어, 내장 하드 디스크 및 이동식 디스크), 자기-광학 매체 및 콤팩트 디스크(compact disc: CD) 또는 디지털 다기능 디스크(digital versatile disc: DVD)와 같은 광학 매체를 포함하지만, 이들에 한정되는 것은 아니다. 소프트웨어와 연계하는 프로세서는 WTRU, UE, 단말, 기지국, 노드-B, eNB, HNB, HeNB, AP, RNC, 무선 라우터 또는 임의의 호스트 컴퓨터에 사용을 위한 무선 주파수 송수신기를 구현하는 데 사용될 수 있다.

Claims (20)

1. 무선 송수신 유닛(wireless transmit/receive unit: WTRU)에 의한 사용자 스폰서링의 방법으로서,
   제1 WTRU가 애플리케이션 서버(application server: AS)를 거쳐 제2 WTRU의 사용자 스폰서링을 개시하는 단계;
   상기 제1 WTRU가 상기 AS로부터 서비스 트리거를 수신하고 상기 서비스 트리거를 상기 제2 WTRU에 제공하는 단계;
   상기 제2 WTRU가 상기 서비스 트리거를 사용하여 상기 AS와의 스폰서링된 세션을 개시하는 단계; 및
   상기 AS가 상기 제2 WTRU에 콘텐트를 전달하는 데 요구되는 우선 트래픽 핸들링을 제공하기 위해 네트워크에 요청을 송신하는 단계 - 상기 제1 WTRU의 사용자는 우선 트래픽 핸들링에 대해 과금됨 -
   를 포함하는 방법.
2. 제1항에 있어서,
   상기 AS가 온라인 과금 펑션(online charging function: OCF) 및 과금 데이터 펑션(charging data function: CDF)을 포함하는 과금 시스템과 직접 통신 링크를 설정하는 단계를 더 포함하는 방법.
3. 제1항에 있어서,
   상기 제1 WTRU와 연계된 사용자 프로파일에 사용자 스폰서링 데이터를 구성하는 단계; 및
   상기 제1 WTRU가 상기 제2 WTRU로부터 인가를 얻는 단계를 더 포함하는 방법.
4. 제1항에 있어서, 상기 서비스 트리거는 임베디드 토큰을 갖는 하이퍼링크와 연계되는 것인 방법.
5. 제1항에 있어서, 상기 서비스 트리거는 토큰을 포함하는 유니폼 리소스 로케이터(uniform resource locator: URL)와 연계되는 것인 방법.
6. 제1항에 있어서, 상기 제1 WTRU가 스폰서쉽 토큰을 얻는 단계를 더 포함하는 방법.
7. 제1항에 있어서, 상기 제1 WTRU의 가입자 프로파일은 애플리케이션 서버(application server: AS)에 상주하는 것인 방법.
8. 제1항에 있어서, 상기 제1 WTRU의 가입자 프로파일은 홈 가입자 서버(home subscriber server: HSS)에 상주하는 것인 방법.
9. 제1항에 있어서, 상기 제1 WTRU의 가입자 프로파일은 가입자 프로파일 저장소(subscriber profile repository: SPR)에 상주하는 것인 방법.
10. 제1항에 있어서, 상기 제1 WTRU의 가입자 프로파일은 사용자 데이터 저장소(user data repository: UDR)에 상주하는 것인 방법.
11. 제1항에 있어서,
    상기 제1 WTRU는 크레디트를 제2 WTRU에 전달하도록 AS에 요청하는 단계를 더 포함하는 방법.
12. 무선 송수신 유닛(wireless transmit/receive unit: WTRU)에 의한 사용자 스폰서링의 방법으로서,
    제1 WTRU가 애플리케이션 서버(application server: AS)로부터 제2 WTRU의 사용자 스폰서링을 요청하는 단계; 및
    상기 AS가 온라인 과금 펑션(online charging function: OCF) 및 과금 데이터 펑션(charging data function: CDF)을 포함하는 과금 시스템과 직접 통신 링크를 설정하는 단계
    를 포함하는 방법.
13. 제12항에 있어서,
    상기 제1 WTRU가 상기 AS로부터 사용자 스폰서링 트리거를 얻고 상기 스폰서링 트리거를 상기 제2 WTRU에 전달하는 단계;
    상기 제2 WTRU가 AS 트리거를 사용하여 상기 AS로부터 서비스를 액세스하는 단계; 및
    상기 제2 WTRU와 상기 AS 사이에 세션을 설정하는 단계를 더 포함하는 방법.
14. 제13항에 있어서,
    상기 AS가 상기 제2 WTRU에 콘텐트를 전달하는 데 필요한 우선 트래픽 핸들링을 제공하도록 네트워크에 요청을 송신하는 단계를 더 포함하고, 상기 제1 WTRU의 사용자는 우선 트래픽 핸들링에 대해 과금되는 것인 방법.
15. 제12항에 있어서, 상기 제1 WTRU의 사용자는 로밍형 협의를 통해 상기 제2 WTRU의 우선 트래픽 핸들링에 대해 과금되는 것인 방법.
16. 제12항에 있어서,
    상기 AS가 상기 제1 WTRU의 사용자가 상기 제2 WTRU의 사용자를 스폰서링하도록 인가되는 것을 검증하는 단계;
    상기 제1 WTRU가 상기 AS로부터 서비스 트리거를 수신하는 단계;
    상기 제1 WTRU가 상기 서비스 트리거를 상기 제2 WTRU에 제공하는 단계;
    상기 제2 WTRU가 상기 서비스 트리거를 사용하여 상기 AS와 스폰서링된 세션을 개시하는 단계; 및
    상기 제2 WTRU가 상기 AS로부터 서비스를 수신하는 단계를 더 포함하는 방법.
17. 제12항에 있어서,
    상기 제1 WTRU가 상기 제2 WTRU에 크레디트를 전달하도록 AS에 요청하는 단계를 더 포함하는 방법.
18. 애플리케이션 서버(application server: AS)로서,
    제2 무선 송수신 유닛(wireless transmit/receive unit: WTRU)을 스폰서링하는 제1 WTRU에 서비스 트리거를 전송하도록 구성된 송신기를 포함하고,
    상기 송신기는 상기 제2 WTRU에 콘텐트를 전달하는 데 필요한 우선 트래픽 핸들링을 제공하기 위해 네트워크에 요청을 전송하도록 더 구성되고, 상기 제2 WTRU의 사용자는 온라인 과금 펑션(online charging function: OCF) 및 과금 데이터 펑션(charging data function: CDF)을 포함하는 과금 시스템을 거쳐 우선 트래픽 핸들링에 대해 과금되는 것인 애플리케이션 서버(AS).
19. 제1 무선 송수신 유닛(wireless transmit/receive unit: WTRU)으로서,
    애플리케이션 서버(application server: AS)를 거쳐 제2 WTRU의 사용자 스폰서링을 개시하도록 구성된 송신기;
    상기 AS로부터 서비스 트리거를 수신하도록 구성된 수신기를 포함하고,
    상기 송신기는 상기 제2 WTRU가 서비스 트리거를 사용하여 상기 AS와 스폰서링된 세션을 개시할 수도 있도록 상기 서비스 트리거를 상기 제2 WTRU에 포워딩하도록 더 구성되고, 상기 제1 WTRU의 사용자는 상기 제2 WTRU에 제공된 서비스 및 우선 트래픽 핸들링에 대해 과금 시스템을 거쳐 과금되고, 상기 과금 시스템은 온라인 과금 펑션(online charging function: OCF) 및 과금 데이터 펑션(charging data function: CDF)을 포함하는 제1 무선 송수신 유닛(WTRU).
20. 제19항에 있어서, 상기 서비스 트리거는 임베디드 토큰을 갖는 하이퍼링크와 연계되는 제1 WTRU.

Images