JP2012526415A - デバイス間のメディアおよび/またはメディア移転を実装するためのシステムおよび方法 - Google Patents

デバイス間のメディアおよび/またはメディア移転を実装するためのシステムおよび方法 Download PDF

Info

Publication number
JP2012526415A
JP2012526415A JP2012508787A JP2012508787A JP2012526415A JP 2012526415 A JP2012526415 A JP 2012526415A JP 2012508787 A JP2012508787 A JP 2012508787A JP 2012508787 A JP2012508787 A JP 2012508787A JP 2012526415 A JP2012526415 A JP 2012526415A
Authority
JP
Japan
Prior art keywords
request
controller
session
sip
media
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2012508787A
Other languages
English (en)
Other versions
JP5518185B2 (ja
Inventor
アンドリュー アレン,
ベッカー, ジャン ヘンドリック ルーカス
エイドリアン バックリー,
ジャン−フィリップ コーミエー,
ヨン エ キム,
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
BlackBerry Ltd
Original Assignee
Research in Motion Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Research in Motion Ltd filed Critical Research in Motion Ltd
Publication of JP2012526415A publication Critical patent/JP2012526415A/ja
Application granted granted Critical
Publication of JP5518185B2 publication Critical patent/JP5518185B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40Support for services or applications
    • H04L65/403Arrangements for multi-party communication, e.g. for conferences
    • H04L65/4046Arrangements for multi-party communication, e.g. for conferences with distributed floor control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04BTRANSMISSION
    • H04B7/00Radio transmission systems, i.e. using radiation field
    • H04B7/24Radio transmission systems, i.e. using radiation field for communication between two or more posts
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H04L12/1818Conference organisation arrangements, e.g. handling schedules, setting up parameters needed by nodes to attend a conference, booking network resources, notifying involved parties
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H04L12/1822Conducting the conference, e.g. admission, detection, selection or grouping of participants, correlating users to one or more conference sessions, prioritising transmission
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1083In-session procedures
    • H04L65/1094Inter-user-equipment sessions transfer or sharing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • H04L65/1104Session initiation protocol [SIP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40Support for services or applications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40Support for services or applications
    • H04L65/403Arrangements for multi-party communication, e.g. for conferences
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W68/00User notification, e.g. alerting and paging, for incoming communication, change of service or the like
    • H04W68/02Arrangements for increasing efficiency of notification or paging channel
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/08Upper layer protocols
    • H04W80/10Upper layer protocols adapted for application session management, e.g. SIP [Session Initiation Protocol]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/189Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

制御を移転する方法が提供される。該方法は、協調セッションの制御を移転するための要求を、第1のユーザ機器(UE)から受信することを含む。該方法は、該受信された要求に応答して、該協調セッションの制御の移転の要求を第2のUEに送信することと、該第2のUEへの該送信された要求に応答して、該協調セッションの制御の移転の受諾の指示を受信することとを含む。該方法は、該第2のUEからの該受諾の指示の受信に応答して、該協調セッションの制御の状態の通知を該第1のUEに送信することを含む。

Description

(関連出願の引用)
本願は、米国仮特許出願第61/175,403号(2009年5月4日出願、本願と同名称)に基づく優先権を主張し、該出願は、参照により本明細書に引用される。
(技術分野)
本開示は、概して、移動通信システムにおけるセッションのためのメディアおよび/または制御機能管理に関し、より具体的には、デバイス間のメディアおよび/または制御機能移転を実装するためのシステムおよび方法に関する。
本明細書で使用される場合、「デバイス」という用語は、固定および携帯電話、携帯情報端末、手持ち式またはラップトップコンピュータ、スマートフォン、プリンタ、ファクス機、テレビ、セットトップボックス、および他のビデオ表示デバイス等の電子デバイス、家庭用音響機器および他の家庭用娯楽システム、家庭用監視および制御システム(例えば、家庭監視、アラームシステム、および気候制御システム)、コンピュータ化された冷蔵庫等の進化型家庭用電化製品、およびネットワーク通信能力を有する同様のデバイスを含むことができる、「移動局」(MS)、「ユーザエージェント」、または「ユーザ機器」(UE)という用語を指すことができる。いくつかの構成では、UEは、移動無線デバイスを指し得る。移動無線デバイスである、そのようなUEは、デバイスの内部にあるか、または取り外すことができる、メモリモジュールを含んでも含まなくてもよく、例は、加入者識別モジュール(SIM)、またはおそらくISIMアプリケーション、コンパクトフラッシュ(登録商標)、マイクロSD、R−UIM等を含む、UICCカード等であるが、それらに限定されない。SIM/UICC機能性はまた、ソフトウェアダウンロード可能なSIM/UICCセキュリティソフトウェアによって提供され得る。該用語はまた、デスクトップコンピュータ、セットトップボックス、TV、IPTV、またはネットワークノード等の、同様の能力を有するが容易に運搬可能ではないデバイスを指し得る。デバイスという用語はまた、固定型または移動性であり得る、SIPユーザエージェント(UA)という用語も対象とする。UAがネットワークノードである時、ネットワークノードは、UAまたは固定回線デバイス等の別の機能に代わって作用し、UAまたは固定回線デバイスをシミュレートまたはエミュレートすることができる。例えば、いくつかのUAについて、典型的にはデバイス上に常駐するIMS IPクライアントは、実際にネットワーク内に常駐し、最適化されたプロトコルを使用して、デバイスにSIPメッセージ情報を中継する。言い換えれば、伝統的にUAによって実行された、いくつかの機能は、遠隔UAの形態で分布することができ、その場合、遠隔UAは、ネットワーク内のUAを表す。「UA」という用語はまた、SIPセッションを含むことができるが、それに限定されない通信セッションを終了させることができる、任意のハードウェアまたはソフトウェア構成要素も指すことができる。また、「ユーザエージェント」、「UA」、「ユーザ機器」、「UE」、および「ノード」という用語は、本明細書中で同義的に使用される場合がある。 当業者であれば、これらの用語を本願内で交換可能に使用できることを理解するであろう。
UEは、高速データ通信を提供する無線通信ネットワーク内で動作し得る。例えば、UEは、グローバルシステムフォーモバイルコミュニケーションズ(Global System for Mobile Communications/GSM(登録商標))および汎用パケット無線サービス(General Packet Radio Service/GPRS)技術に従って動作し得る。現在、そのようなUEはさらに、GSM(登録商標)進化型高速データレート(Enhanced Data rates for GSM(登録商標) Evolution/EDGE)、または進化型GPRS(Enhanced GPRS/EGPRS)あるいは進化型GPRSフェーズ2(Enhanced GPRS Phase 2/EGPRS2)に従って動作し得る。UEが動作し得る他の無線ネットワークは、CDMA、UMTS、E−UTRAN、WiMax、およびWLAN(例えば、802.11)を含むが、それらに限定されない。UEはまた、xDSL、DOCSISケーブルネットワーク、イーサネット(登録商標)、または他の光ネットワーク等の固定ネットワーク環境内で動作し得る。いくつかのUEは、ある時に単一のアクセスネットワーク上、または同時に複数のアクセス技術を使用するいくつかのデバイスにおいて、2以上のアクセスネットワーク技術で動作することができるマルチモード動作が可能であり得る。
EDGE/EGPRS/EGPRS2は、増加したデータ伝送速度および向上したデータ伝送信頼性を可能にする、デジタル移動通信技術の例である。ネットワークはしばしば、2.75Gネットワーク技術として分類される。EDGEは、最初は北米で、約2003年以来、世界中でGSM(登録商標)ネットワークに導入されてきた。EDGE/EGPRS/EGPRS2は、インターネット接続を伴うもの等の任意のパケット交換用途で使用され得る。ビデオおよび他のマルチメディアサービス等の高速データ用途は、EGPRSの増加したデータ容量から利益を得る。UEはまた、Wimax、Wifi等であるがそれらに限定されない、他の無線技術で動作し得る。
通信ネットワークがますます複雑になるにつれて、ネットワークインフラストラクチャは、単一の電話回線、携帯電話、または他のUEに一意的にマップする、電話番号等の単一の識別という電話ベースの概念から離れつつある。例えば、セッション初期化プロトコル(Session Initiation Protocol/SIP)および他の関連インターネットベースの通信技術は、ネットワークへの複数のデバイスの登録をサポートし、各デバイスは、同じユーザ識別(例えば、SIPまたは電話ユニフォームリソース識別子(Tel Uniform Resource Identifier/URI)、または重複あるいは同一の識別群を共有する。この識別群は、暗示的登録セット(Implicit Registration Set/IRS)と呼ばれる。通信ネットワークの進化と一致して、SIPはまた、ネットワークとUEとの間に確立された同じセッション内で、テキスト、アプリケーション用のデータ、音声およびビデオ等を含むが、それらに限定されない種々のメディア種類をサポートすることも可能である。当業者であれば、デバイス/SIP UAは、ビデオをサポートする小型スクリーンまたはHDTVをサポートするIPTV等の異なる能力を有することができると理解するであろう。したがって、ビデオおよび音声構成要素を有した小型画面上で開始された2つ以上のデバイス/SIP UAの間のセッションが、ユーザがそれの近くにいた場合に、そのビデオ構成要素をHDTVに移動させた可能性があれば、有利となるであろう。この能力は、UE間移転(Inter UE Transfer/IUT)と呼ばれ、3GPP TS 23.237および3GPP TS 24.292で定義されている。
IUT、PNM、またはBlackBerry Uniteのような他のサービスにおいてネットワークおよび関連デバイスの効果的な動作を提供するために、いくつかのネットワークは、デバイス、または、それぞれネットワークサーバと関連する標的UE群内で送達することができるセッションを管理する能力を有する管理者またはコントローラUEを含む。その場合、管理者またはコントローラUEは、1つ以上の他のUEを介して利用可能となる種々の特徴/パラメータの動作を管理するように構成され得る。場合によっては、コントローラ機能は、コントローラUEから、コントローラ機能性を提供する能力を有する別のUEに移転され得る。場合によっては、複数のUEがコントローラの役割を果たし得る。場合によっては、コントローラUEは、パーソナルネットワーク管理(Personal Network Management/PNM)コントローラ機能性を実装し得る。場合によっては、UEは、アクセスネットワークにつき1つ、複数のユーザエージェントを有する。同様に、管理者またはコントローラUAは、1つ以上の他のUAを介して利用可能となる種々の特徴またはパラメータの動作を管理するように構成され得る。管理者またはコントローラUAはまた、管理者またはコントローラUEであり得る。以下では、UEおよびUAという用語はしばしば、文脈から明白ではない限り、交換可能に使用される。
SIPは、UEが、送信者の識別に応じて、どのUEに通信がアドレス指定されるかに基づいて、通信フィルタリングおよびサービスの転換を通知され得るように構成されることを可能にする。例えば、ユーザは、ユーザの携帯電話において直接ユーザに連絡するよう、特定の公衆ユーザ識別(家庭用電話番号またはEメールアドレス等)が家族に提供されることを可能にするように電話/通信転送サービスを構成し得、友人または家族が、個人用音声メールに転送され得る一方で、同僚は、最終的に企業用音声メールに転送するオフィス用電話に転送される。
そのようなものとして、SIPは、ユーザが複数のUEにわたって一貫した識別を有することを可能にし、UEは、家庭用電話、個人用携帯電話、仕事用電話、企業用携帯電話、別荘用電話、ラップトップコンピュータボイスオーバーIP(VoIP)クライアント、ファクス機等を含み得る。一貫した公衆ユーザ識別はまた、現在、いずれのUEをユーザが偶然使用していようと、ユーザが連絡可能となることを可能にする。この融通性は、アドレス帳の中の各ユーザを識別するために、デバイス指向の連絡先の広範なリストを維持すること、通信を確立しようとする場合に、どのデバイスが最良であるかを決定しなければならないことの必要性を最小限化し、各ユーザ(および全ての関連携帯電話、家庭用電話、コンピュータ等)が、単一の識別によって識別され得る。従って、ネットワークおよび/または終端ユーザに関する単一の識別のみを使用して、その個人に連絡する際に使用するための最も適切なUEを決定し、誰かと通信することが可能である。
SIPを実装し、管理者またはコントローラUEを有するネットワークでは、種々のメディア種類を含み得る、コンテンツを処理する最良の能力を有するUEに対して、新しいセッションが確立されることを確実にすることが望ましい。例えば、ビデオコンテンツを表示するための手段を持たない、またはテレビあるいはコンピュータ画面/モニタがユーザによる使用のために利用可能である時に非常に小さいビデオ画面を有する、従来のオフィス用電話上でビデオコンテンツを含むメディアを受け入れることは、最も適切ではないであろう。さらに、UEが、1つ以上のメディア種類を使用するセッションにすでに関与しており、UEがセッションに1つ以上のメディア種類を追加または修正する招待を受信すると、ユーザが、新しいメディア種類をサポートし、処理またはレンダリングすることができる異なるUEに、新しいメディア種類を移転するように要求することができるように、コントローラUEが識別されるべきである。例えば、ユーザがユーザの携帯電話上で音声セッションに従事し、ユーザが別のデバイス上で追加されたビデオストリーミングメディアを受け入れることを希望する場合、コントローラUEは、デバイス能力およびユーザ選好等に基づいて、追加されたビデオストリーミングメディアを受信し、表示するために、ラップトップPC等の別のデバイスを選択する能力をユーザに提供する。
加えて、ユーザは、セッションの時間中に、セッションのコントローラに異なるデバイスを使用し得る。例えば、ユーザは、外の庭で、セッションまたはセッションの1つ以上のメディア構成要素を携帯電話上で受け入れ、次いで、家の中に移動し、音声およびビデオ構成要素の両方をデスクトップコンピュータに移転し得、ここでユーザは、デスクトップコンピュータからセッションを制御することを希望するため、携帯電話からデスクトップコンピュータにセッションの制御も移転する。最後に、コントローラとしての機能性は、コントローラデバイスとなることが可能である一定のメンバーUE間でのみ移転され(例えば、基本的なテレビは、ユーザと相互作用してコントローラ機能性を果たす能力を有する可能性が低い)、ネットワークによってコントローラ機能を受け取るための権限を与えられるべきである。したがって、異なる加入者(例えば、家庭用電話およびテレビ等の共有デバイス)によって潜在的に使用することができる一式のUEの間で、セッション、メディア、およびコントローラ機能性の移転要求を配信し、処理するように、確実な機構を提供することが重要である。
本開示は、移動通信システムにおけるメディアおよび/または制御機能管理のためのシステムおよび方法、より具体的には、デバイス間のメディア移転および/または制御機能移転を実装するためのシステムおよび方法を提供することによって、前述の欠点を克服する。
一実施例では、第1のユーザ機器(UE)から、おそらく同じ団体に属する第2のUEにコントローラ機能を移転する方法は、第1のUEと第3のUEとの間でメディアコンテンツを伝達するためのセッションを確立することを含む。第1のUEは、最初に、セッションに対するコントローラ機能が割り当てられる。方法は、セッションに対するコントローラ機能の少なくとも一部を第2のUEに移転するための要求を第1のUEから受信することと、コントローラ機能を実装するための第2のUEの能力を決定することとを含む。第2のUEがコントローラとして動作する能力を有する場合に、方法は、セッションに対するコントローラ機能の少なくとも一部を第2のUEに割り当てることと、セッションに対するコントローラ機能の少なくとも一部を移転するための要求に応答して、第1のUEにセッションを解放するように通知することとを含む。
別の実施例では、第1のユーザ機器(UE)から第2のUEにコントローラ機能を移転する方法は、第1のUEと第3のUEとの間でメディアコンテンツを伝達するためのセッションを確立することを含む。第1のUEは、最初に、セッションに対するコントローラ機能が割り当てられ、第1のUEは、インターフェースを含む。方法は、第1のUEインターフェースを介して、第2のUEにセッションに対するコントローラ機能を移転するための要求を受信することと、セッションコントローラ機能移転要求をアプリケーションサーバに伝送することと、アプリケーションサーバから移転応答を受信することとを含む。第1のUEがセッションコントローラ機能を解放するべきであると移転応答が示す場合に、方法は、セッションコントローラ機能を解放することを含む。
別の実施例では、第1のユーザ機器(UE)と第3のUEとの間でメディアコンテンツを伝達するためのセッションを移転する方法は、第1のUEにセッションに対するコントローラ機能を割り当てることと、メディアコンテンツを伝達するためのセッションを第2のUEに移転するための要求を第1のUEから受信することと、メディアコンテンツを伝達するためのセッションを受信するための第2のUEの能力を決定することとを含む。第2のUEがメディアコンテンツを伝達するためのセッションを受信する能力を有する場合に、方法は、メディアコンテンツを伝達するためのセッションを第2のUEに移転することと、メディアコンテンツを伝達するためのセッションを第2のUEに移転するための要求に応答して、第1のUEにセッションを解放するように通知することとを含む。
ここで、本開示のより完全な理解のために、添付の図面および発明を実施するための形態と関連して、以下の簡単な説明を参照し、類似参照数字は、類似部品を表す。
図1は、ネットワークと関連付けられたUEの間でメディアおよびIUTコントローラ機能を移転するフロー例を図示する。 図2は、ネットワークに接続されたUEの間でIUTメディアおよび/またはコントローラ機能を果たすために本システムを実装するための例示的な通信ネットワークを図示する。 図3は、UEをIMSネットワークに登録してSCC ASへの登録を引き起こすためのフロー例を図示する。 図4は、コントローリUE、またはコントローラUEおよびコントローリUEの両方を含む、1つ以上のIUT可能UEを識別するための例示的な許容IUTリスト管理オブジェクトを図示する。 図5aおよび5bは、図4に示された例示的な許容IUTリストMOのパラメータおよびDDFを図示する。 図5aおよび5bは、図4に示された例示的な許容IUTリストMOのパラメータおよびDDFを図示する。 図5aおよび5bは、図4に示された例示的な許容IUTリストMOのパラメータおよびDDFを図示する。 図6は、承認が単一のコントローラUEのみから要求される、IUTコントローラ機能をUEに提供するためのフロー例を図示する。 図7は、承認が1つより多くのコントローラUEのみから要求される、IUTコントローラ機能をUEに提供するためのフロー例を図示する。 図8は、IUTコントローラUEによって要求されるように、メディアAおよびコントローラ機能をUEに移転するためのフロー例を図示する。 図9は、UE−1からUE−2にメディアAおよびコントローラ機能を移転するためのフロー例を図示し、着信セッション要求は、コントローラ機能識別子を含み、Gm参照点上で送達され、メディアAは、回路交換ネットワークを介して伝送される。 図10は、UE−1からUE−2にメディアAおよびコントローラ機能を移転するためのフロー例を図示し、着信セッション要求は、コントローラ機能識別子を含み、I1参照点上で送達され、メディアAは、CSネットワークを介して伝送される。 図11は、ユーザと関連付けられた複数のUEを図示し、協調セッションがUEの一部の間で確立されている。 図12aおよび12bは、セッション招待要求を受信する時に協調セッション確立を終了させるためのフロー例を図示する。 図12aおよび12bは、セッション招待要求を受信する時に協調セッション確立を終了させるためのフロー例を図示する。 図13は、第1のPS UEから第2のPS UEにIUTコントローラ機能性を移転するためのフロー例を図示し、第1および第2のUEは、同じベアラまたは異なるベアラを使用し得る。 図14は、Gm参照点を使用した、協調セッション内の別のUEへのメディア/コントローラ機能性移転のための代替メッセージフローの説明図である。 図15は、I1参照点を使用した、協調セッション内の別のUEへのメディア/コントローラ機能性移転のための代替メッセージフローの説明図である。 図16は、コントローラが開始した進行中セッション情報移転のための代替メッセージフローの説明図である。 図17は、ユーザエージェントの実施形態を含む、無線通信システムを図示する。 図18は、デジタル信号プロセッサ(DSP)およびメモリを含む、ユーザエージェントのブロック図を示す。 図19は、ユーザエージェントのプロセッサによって実装され得る、ソフトウェア環境を図示する。 図20は、ネットワーク間のセッション遷移の機会を提供する方法を実装するために好適な処理構成要素を含む、システムの実施例を図示する。 図21は、関連コントローラおよびコントローリUEを表すネットワーク内で情報を記憶するための例示的な構造の説明図である。 図22は、HSS内等のネットワークに記憶された例示的な情報の説明図である。 図23は、参照ビット値位置を伴う指標例の説明図である。
ここで、付属の図面を参照して本開示の種々の側面を説明し、類似数字は、全体を通して類似または対応する要素を指す。しかしながら、図面およびそれに関する詳細な説明は、請求された主題を開示される特定の形態に限定することを目的としていないことを理解されたい。むしろ、請求された主題の精神および範囲に入る全ての修正、同等物、および代替案の全てを対象とすることを意図する。
本明細書で使用される場合、「構成要素」、「システム」等の用語は、コンピュータ関連エンティティ、ハードウェア、ハードウェアおよびソフトウェアの組み合わせ、ソフトウェア、または実行中のソフトウェアを指すことを目的としている。例えば、構成要素は、プロセッサ上で作動するプロセス、プロセッサ、オブジェクト、実行ファイル、実行のスレッド、プログラム、および/またはコンピュータであり得るが、それらに限定されない。例証として、コンピュータ上で作動するアプリケーションおよびコンピュータの両方が、構成要素であり得る。1つ以上の構成要素がプロセスおよび/または実行のスレッド内に常駐し得、1つの構成要素が、1つのコンピュータ上に限局され、および/または2つ以上のコンピュータ間に分布され得る。
「例示的な」という言葉は、実施例、例、例証としての機能を果たすことを意味するために、本明細書で使用される。「例示的な」として本明細書で説明される任意の側面または設計は、必ずしも他の側面または設計と比べて好ましい、または有利として解釈されるわけではない。
さらに、開示された主題は、ソフトウェア、ファームウェア、ハードウェア、またはそれらの任意の組み合わせを生産して、本明細書で詳述される側面を実装するようにコンピュータまたはプロセッサベースのデバイスを制御するために、標準プログラミングおよび/または工学技法を使用して、システム、方法、装置、または製造品として実装され得る。本明細書で使用されるような「製造品」(または代替として、「コンピュータプログラム製品」)という用語は、コンピュータ可読デバイス、キャリア、またはメディアからアクセス可能なコンピュータプログラムを包含することを目的としている。例えば、コンピュータ可読媒体は、磁気記憶デバイス(例えば、ハードディスク、フロッピー(登録商標)ディスク、磁気帯、および同等物)、光ディスク(例えば、コンパクトディスク(CD)、デジタル多用途ディスク(DVD)、および同等物)、スマートカード、およびフラッシュメモリデバイス(例えば、カード、スティック、および同等物)を含むことができるが、それらに限定されない。加えて、電子メールを送受信する際に、またはインターネットあるいはローカルエリアネットワーク(LAN)等のネットワークにアクセスする際に使用されるデータ等の、コンピュータ可読電子データを搬送するために、搬送波を採用できることを理解されたい。当然ながら、当業者であれば、請求された主題の範囲または精神から逸脱することなく、多くの修正がこの構成に行われ得ることを認識するであろう。
本システムは、通信ネットワークと関連付けられたデバイス間でメディア移転または制御機能移転を実装するためのメディアおよび/または制御機能管理を提供する。1つの実装では、システムは、1つ以上のコントローラSIP UAまたはUEから、1つ以上のコントローリSIP UAまたはUEへ、セッションの1つ以上のメディア構成要素、またはいくつかあるいは全てのメディアフロー、および/またはコントローラ機能(IUTコントローラ)を移転するために、3GPP TS 23.237によるUE間移転(IUT)を行う。システムは、種々の通信ネットワークで実装され得、UEは、単一の共有識別(例えば、Tel URI、SIP URI、MSISDN、C−MSISDN、GRUU(Globally Routable User Agent URI:グローバルにルーティング可能なユーザエージェントURI)等)が割り当てられるか、またはネットワークと関連付けられた他のUEと重複する識別情報を有するように構成される。ネットワーク内では、各UEは、種々の通信セッションを開始し得、各セッションは、アプリケーション用のデータ(メディア種類アプリケーション)、声、テキスト、ビデオ(種々の符号化スキームを含む)、および音声等であるが、それらに限定されない複数のメディア種類を含み得る、データの通信を伴う。
1つの構成では、システムは、SIPをサポートし、非コントローラまたはコントローリSIP UAあるいはUEに加えて、種々の管理者またはコントローラSIP UAあるいはUEを有する、ネットワークを介して実装される。コントローラ機能は、それらに限定されないが、ネットワーク規則、操作者方針、ユーザ選好、または他のシステム要件に応じで、第1のコントローラUEから別のUEに移動されられ得る。場合によっては、コントローラまたはコントローリ機能を有するUEは、ネットワークを介して提供され得、コントローリUEは、同様の機能的能力およびシステム設計を有するコントローラUEと同様に構成される。UEの中の1つのUEが最初にネットワークに登録されると、無線サーバに登録されたコントローラ機能性をサポートする第1のUEは、自動的に管理者またはコントローラUEとして指定され得る。場合によっては、ネットワークが、コントローラ機能性をサポートするUEによって送信された協調セッションに対する初期移転要求を受信すると、UEは、自動的に管理者またはコントローラUEとして指定され得る。しかしながら、UEの集合の中の予備コントローラUEを決定するために、他のアルゴリズムが採用され得る。ネットワークに接続した後、ユーザは、随意で、ユーザによる、または他の関連ユーザによる制御下で、第1の登録されたUEから他の登録されたUEのうちの1つにコントローラ指定を変更し得る。
本システムを使用して、それぞれ共通の識別を共有する、複数のUEを伴うユーザに役立つネットワークは、種々のメディア種類を含むセッションに参加する招待を受信し得る。招待を受信した後、ネットワークは、招待に説明されたメディア種類、ユーザによって特定された好ましいUE、またはコントローラUEあるいはネットワークに利用可能な他の情報に従って、セッション招待(例えば、SIP INVITE、またはSIP Re−INVITE)をユーザのUEに移転、転送、または送信する。ユーザが、種々のメディア種類を使用したセッションにすでに関与し、申し入れ(例えば、セッション記述プロトコル(SDP OFFER))が、1つ以上のメディア種類を追加、削除、または修正する同じセッションに対して受信された場合、新しいメディア種類およびセッション制御機能を異なるUEに移転するコントローラUEが識別され得る。
1つの実装では、UE(例えば、ICS UE)が、IPベアラを使用してセッションを確立するためのSDPを含むSIP INVITE要求を受信すると、ICS UEは、3GPP TS 24.229に従うが、以下の明細に従ってセッションを確立する。第1に、SIP INVITE要求が、ICS UEと、サービス一貫性および連続性アプリケーションサーバ(SCC AS)との間の既存のダイアログ(または確立されつつあるダイアログ)に対応する、ダイアログパラメータを含むTarget−Dialogヘッダを含む場合、ICS UEは、Target−Dialogヘッダに含まれたダイアログパラメータによって識別されるダイアログと同じセッションの一部である、別のダイアログとしてSIP INVITE要求を扱う。第2に、SIP INVITE要求が、Target−Dialogヘッダを含まないが、ICS UEとSCC ASとの間に既存のダイアログ(または確立されつつあるダイアログ)がある場合、SCC ASは、この要求に対するダイアログパラメータが、ICS UEとSCC ASとの間の既存のダイアログ(または確立されつつあるダイアログ)上で受信されるTarget−Dialogヘッダの中で受信されるダイアログパラメータに対応するかどうかをチェックすることができ、もしそうであれば、ICS UEは、Target−Dialogヘッダが受信されたダイアログと同じセッションの一部である、別のダイアログとしてSIP INVITE要求を扱うことができる。この第2の明細は、要求が送信された順番外で着信する可能性を対象とし得る。
本システムに従ってIUTを実装するように構成されるコントローラUEは、異なるUE上で新しいアクセスレッグを作成することによって1つ以上のメディアフローをセッションに追加すること、異なるUE上の既存のアクセスレッグ上で1つ以上のメディアフローをセッションに追加すること、異なるUE上のアクセスレッグ上でセッションから1つ以上のメディアフローを除去すること、異なるUE上でMMTelサービス制御にメディアを提供すること(例えば、3GPP TS 22.173参照)、および異なるUE上でメディア特性の更新を提供することといった、1つ以上を行うように構成され得る。したがって、各コントローラUEは、SCC AS等の特定のネットワークエンティティまたはノードと固着された1つ以上のセッションを提供する、協調セッションを確立および/または解放するように構成され得る。進行中の協調セッションを維持しながら、各コントローラUEは、協調セッションのメディアフローを標的UEに移転し得る。さらに、各コントローラUEは、協調セッションを確立して、または確立せずに、利用可能な1つ以上のメディアフローの全てまたはいくつかを標的UEに移転するように構成され得る。全てのメディアフローを標的UEに移転する場合、コントローラUE上の既存のセッションが解放され得る。
1つのシステム実装例では、UE間移転(IUT)を実装するためには、SCC ASは、UE間移転の実行のためにS−CSCFに向けたISC参照点を使用する。例えば、IUTの使用可能性および実行のために、SCC ASは、最初に、以下で説明されるようなUE間移転に必要とされる情報を分析し、操作者方針およびユーザ選好に基づいて、どのアクセスネットワークが実行されるべきかを決定し得る。次いで、SCC ASは、操作者方針と整合しなければUE間移転を拒絶し得る。SCC ASは、登録後に、ホーム加入者サーバ(HSS)から、HSSの中のユーザプロファイルに記憶されたIMSプライベートユーザ識別に結びつけられたC MSISDNを回収し、第三者登録後に、HSSから、HSSの中のユーザプロファイルに記憶されたIMSプライベートユーザ識別に結びつけられた、UE間移転のためのコントローラ機能性を回収し得る。SCC ASはまた、UEが許可され、UE間移転のためのコントローラ機能性が可能であるかどうかを決定し、着信SIP INVITEまたは着信UE間移転要求の中で提供される情報を使用して、UE間移転要求を固着セッションと相関させ、同じまたは異なるアクセスネットワークを介して接続された同じIMSサブスクリプションに属する異なるUE間でIMS UE間移転を実行し得る。SCC ASはまた、IUT移転特有の課金データを提供し、コントローラUEに移転可能なUEの情報を提供し、種々のサービス連続性関連入力因子の分析に基づいて、UE間移転のための設定された操作者方針を更新するかどうかを決定し得る。SCC ASはまた、OMA DMを介して操作者方針(進行中のセッションのためのUE間移転手順を開始するためにも使用することができる操作者方針とユーザ選好との間の優先順位を含む)をUEに送信することによって、UE間移転のための操作者方針を生成して更新し、および、終端コントローラUEがUE間移転を開始することができるように、リモートパーティからの受信された着信セッション招待をコントローラUEに送信するかどうかを決定し得る。
概して、SCC ASは、セッション移転、セッション終了のために必要に応じて、あるいはセッションの設定中に追加のアクセスネットワーク上でメディアフローを追加するためのUEによる要求に応じて、あるいは1つ以上のアクセスネットワーク上で既存のセッションに対するメディアフローを追加および/削除するUEによる要求に応じて、1つ以上のアクセスネットワーク上でメディアフローを組み合わせるため、および/または分割するための機能性を提供する。
IMSセッションのメディアフローを処理する場合に、SCC ASは、セッションと関連付けられたサービスを考慮し得る。
特定のアクセスレッグ上でSIP METHOD(SIP INVITE等)を送るために、そのアクセスレッグに対応する特定の登録フローを識別することが必要である。
Draft−ietf−sip−outboundは、要求がUAまたはUEに到達に到達することができる複数の登録フロー上で、どのようにしてSIP UAまたはUEが登録できるかを説明する。3GPP IMSでサポートされているように、UEは、異なるアクセスネットワーク上で異なるフローを使用して登録するために、Draft−ietf−sip−outboundで定義される機構を使用する。異なるアクセスネットワーク上の各フローは、Draft−ietf−sip−outboundで定義されるように、SIP REGISTER要求のContactヘッダの中に異なる「reg−id」コンタクトヘッダパラメータを含み得る。登録する場合に、UEは、3GPP TS 24.229で説明されているように、SIP REGISTER要求にP−Access−Network−Infoヘッダを含む。3GPP TS 24.229による拡張P−Access−Network−Infoヘッダフィールドの構文例が、表1に示されている。
Figure 2012526415
P−Access−Network−Infoの構文から分かるように、access−typeは、SIP REGISTER要求が送られるネットワークによって使用されるアクセスネットワーク技術を示す。しかしながら、「reg−id」パラメータは登録フローを一意的に識別するが、特定の登録フロー上でSIP INVITE等のSIP METHODが方向付けられることを、ネットワークが指図することを可能にする現在の機構はない。これを可能にするためには、登録フローを識別するメディア特徴タグを定義し、SIP REGISTER要求のContactヘッダに含むことが可能である(「reg−id」パラメータはメディア特徴タグではない)。以下は、そのようなメディア特徴タグの2つの可能な実施形態の実施例である。当業者であれば、SIP UA/UEから同じ意味を伝えるために、適切な英数字の任意の構成を使用できることを理解するであろう。
表2に示された第1の実施例では、文字列がフローを識別するメディア特徴タグに含まれることを可能にする、特徴タグg.3gpp.icsflowが定義されている。この文字列は、「reg−id」パラメータと同じ識別子値(例えば、g.3gpp.icsflow=[regid])を含むことができ、または何らかの他の文字列を含むことができるが、1つの実装では、文字列は、各登録フローに対して異なる必要がある。ユーザが、メディア移転を行う場合に、どのアクセスレッグにメディア種類を移転することを希望をするかを示す(例えば、「internet」、「cableTv」、「cellular」、「WLAN」)ために、これらの標識を使用する必要があり得るため、UEは、ユーザが、メディア特徴タグで使用される文字列に人間が理解可能な標識を定義することを可能にすることができる。
Figure 2012526415
表3に示された別の実施例では、登録が直接携帯電話からであるか、またはネットワークノードからであるかを示し、また、どの登録フローが使用されているかを示すように、既存のg.3gpp.icsメディア特徴タグが強化されている。
Figure 2012526415
UEは、登録する場合に、SIP REGISTER要求のContactヘッダの中に、上記で説明されるようなフローの一意的な識別子を含む、メディア特徴タグとともに、SIP REGISTER要求の中に、そのアクセスレッグ上で使用されるアクセス技術の識別を含む、P−Access−Network−Infoヘッダを含む。
SCC ASまたは別のネットワークノードは、RFC 3860または強化された第三者登録手順(例えば、第三者SIP REGISTER要求の本文に含まれる着信SIP REGISTER要求)の通りに、登録イベントパッケージに登録することによって、メディア特徴タグを取得することができる。P−Access−Network−Infoヘッダはまた、第三者SIP REGISTER要求からSCC ASによって取得することもできる。
SCC ASはまた、例えば、3GPP TS 24.229で特定されるような任意の受信された第三者REGISTER要求(例えば、第三者REGISTER要求の本文に含まれる情報を含む)、3GPP TS 24.229で特定されるような任意の受信されたregイベントパッケージ、または3GPP TS 29.328および3GPP TS 29.329で特定されるようなShインターフェースからのIMS集中サービス(IMS Centralized Services/ICS)特有の要件を実装するために必要とする、登録状態情報を取得し得る。これらの機構を使用して、SCC ASは、特定のIP−CANに対応する特定のフロー上で要求を送ることができるために、P−Access−Network−Infoヘッダから、アクセス種類(access−type)および存在する場合はアクセスクラス(access−class)値、ならびにg.3gpp.icsflowメディア特徴タグの値を取得し、アクセス種類(access−type)および存在する場合はアクセスクラス(access−class)値を、g.3gpp.icsflowメディア特徴タグの値と関連付けることができる。
SCC ASまたは別のネットワークノードは、メディア特徴タグから取得されたアクセスレッグ/フロー識別子と関連して、P−Access−Network−Infoヘッダから取得されたアクセス種類および/またはアクセスクラス情報(おそらく関連位置情報を含む)を記憶する。P−CSCFはまた、ネットワークによって検証され、「np」(ネットワーク提供)パラメータを含むこと等によって示されるようなアクセスクラスおよびアクセス種類を含むP−Access−Network−Infoヘッダに、追加のアクセス種類またはアクセスクラス値を含むこともできることに留意されたい。可用性および操作者の方針に基づいて、UE提供P−Access−Network−Infoヘッダまたはネットワーク提供P−Access−Network−Infoヘッダ、あるいは両方からのアクセス種類および/またはアクセスクラスは、メディア特徴タグから取得されたアクセスレッグ/フローと関連して記憶され得る。
ある提供されたメディア種類を含む要求が、あるアクセスレッグ上で送られることを、操作者方針またはユーザ選好あるいはユーザ構成に基づいて、SCC AS(または別のネットワークノード)が決定する場合に、SCC AS(または別のネットワークノード)は、P−Access−Network−Infoヘッダからのアクセス種類および/またはアクセスクラスと関連して記憶されるメディア特徴タグから以前に取得された、アクセスレッグ/フロー識別子を取得する。次いで、SCC AS(または別のネットワークノード)は、要求が送られるアクセスレッグに対するアクセス種類および/またはアクセスクラスと関連付けられたアクセスレッグ/フロー識別子に設定された値を有するメディア特徴タグ(例えば、g.3gpp.icsflow)を含む、Accept−Contactヘッダを要求の中に含める。「require」および「explicit」というパラメータもまた、随意で、アクセスレッグ/フロー識別子を含むメディア特徴タグと関連付けられたAccept−Contactヘッダに含まれ得る。結果として、要求は、RFC 3841で説明されている機構を使用した所望のアクセスレッグを使用して、UEに送られ、それに対応して、要求が受け入れられた場合、そのアクセスレッグを使用してメディアも確立される。
いくつかの実装では、ネットワーク操作者の方針は、操作者によってネットワーク内で設定され、例えば、初期プロビジョニング中に、またはOMAデバイス管理を介して、UEに伝達することができる。操作者方針は、方針が操作者によって更新される時はいつでも、OMAデバイス管理を介して、UEに伝達され得る。
操作者方針は、それぞれのサポートされたメディアの種類、またはメディア群について、開始セッションおよびセッション移転に制限されるアクセスネットワークのリスト、開始セッションおよびセッション移転に対してSC能力を有するUEによって使用されるべき好ましいネットワーク(優先順位での)のリスト、いつアクセスネットワークが利用可能になり、セッション移転が可能であるか、および、標的アクセスネットワークが利用可能になり、セッション移転が可能である場合に、SC能力を伴うUEが、現在のアクセスネットワークよりも高い優先順位を伴う標的アクセスネットワークにメディアフローを移転し始める「べきである(shall)」/「はずである(should)」/「得る(may)」かどうかを示し得る。「べきである(shall)」を示すことによって、操作者は、可能な限り早く、ホーム操作者の好ましいアクセスネットワークのリストに従って、セッション移転を開始するようにUEに通告する。「はずである(should)」を示すことによって、ローカル動作環境情報(Local Operating Environment Information)を考慮した後にセッション移転が可能であり、望ましい場合、操作者は、ホーム操作者の好ましいアクセスネットワークのリストに従って、セッション移転を開始するようにUEに推奨する。「得る(may)」を示すことによって、ローカル動作環境情報を考慮した後にセッション移転が可能であり、望ましい場合、操作者は、(構成されている時に)ユーザ選好に従って、セッション移転を開始するか否かをUEに自由に決定させる。ユーザ選好が構成されない時はいつでも、UEは、ホーム操作者の好ましいアクセスネットワークのリストを考慮し得る。操作者方針はまた、部分的セッション移転の場合に、移転不可能なメディアフローを保持するか撤回するかを示し得る。概して、セッション移転のための操作者方針は、T−ADSのための操作者方針と一致する。
ユーザ選好は、例えば、好ましいアクセスを指示し得る。ローカル動作環境情報は、実装特異的であり得、無線環境情報、IP接続の質(ジッター、遅延、およびパケット損失)、用途特有の要件、メモリ考察、電力考察等の項目を備え得る。UEは、どのアクセスを進行中のセッションに使用するかを決定する場合に、またはセッション移転を開始することを考慮する前に、操作者方針、ユーザ選好、およびローカル動作環境情報を考慮し得る。概して、アクセス移転のためのユーザ選好は、ネットワークに移転されない。
IUTについて、UEは、Utインターフェースを介して、以下のユーザ選好をSCC ASに示し得、SCC ASは、UEがコントローラの役割を果たすことを許可され、そうすることができるかどうかを決定する場合、および、どのネットワークを着信セッションに使用するか、どのメディア種類をあるUE上で伝送するか、およびリモートパーティからの着信セッション招待をコントローラUEに送信するかどうかを決定するために、コントローラUEの役割を果たす好ましいUE、着信セッションのための好ましいアクセスネットワーク種類、ユーザの特定のUE上で受信される好ましいメディア種類、およびコントローラUE上でリモートパーティからの着信セッション招待を受信する選好といった、操作者方針およびユーザ選好を考慮し得る。
さらに、IUTについて、UEは、概して、IUTコントローラまたはコントローリ機能性をサポートするように構成される。終端UEの場合、UEは、遠隔末端がセッション招待を送信する場合に、進行中セッションに対してIUTを適用するために、コントローラUEになるように構成され得る。
メディア移転を行う場合に、メディアセッションが特定のアクセスレッグ上で1つ以上のメディア種類について確立されることをユーザが通告することを希望する場合、ユーザは、コントローラUE上で、特定のメディア種類に使用することを希望するアクセスレッグを選択することによって、これを示すことができる。ユーザが、メディア移転を行う場合に、どのアクセスレッグにメディア種類を移転することを希望をするかを示す(例えば、「internet」、「cableTv」、「cellular」、「WLAN」)ために、これらの標識を使用することができるように、UEは、ユーザが、メディア特徴タグで使用される文字列に人間が理解可能な標識を定義することを可能にすることができる。代替として、デバイスは、アクセス種類を登録する場合に、ユーザが読み取ることができる人間に可読なアクセス種類と、デバイスがサポートするアクセス種類との間に、マッピングを提供する。実施形態例は以下であるが、当業者であれば、マッピングは、制約が多く、または少なくなり得ることを理解し、その場合、人間に可読な英数字の文字列は、いくつかの可能なP−Access−Network−Infoヘッダアクセス種類値に対してマッピングされるという構想である。
例えば、WLAN = ”IEEE−802.11” / ”IEEE−802.11a” / ”IEEE−802.11b” / ”IEEE−802.11g” / ”IEEE−802.11n”
DSL = ”ADSL” / ”ADSL2” / ”ADSL2+” / ”RADSL” / ”SDSL” / ”HDSL” / ”HDSL2” / ”G.SHDSL” / ”VDSL” / ”IDSL”
Cellular = ”3GPP−GERAN” / ”3GPP−UTRAN−FDD” / ”3GPP−UTRAN−TDD” / ”3GPP−E−UTRAN−FDD” / ”3GPP−E−UTRAN−TDD”
CableTV = ”DOCSIS”。
例えば、ユーザが、WLANおよびCellular(例えば、EDGE/UMTS/LTE)アクセスの両方を同時にサポートする、マルチモード対応携帯電話を有する場合、ユーザは、音声および音響メディア種類にCellular接続を使用しながら、帯域幅の効率、費用の効率、またはより良好な画質という理由で、ビデオメディア種類がWLANアクセス上で受信されることを希望し得る。こうするために、UEは、移転されたメディア種類が送られる、ユーザが選択したアクセスレッグに対するアクセスレッグ/フロー識別子に設定された値を有するメディア特徴タグ(例えば、g.3gpp.icsflow)を含むAccept−Contactヘッダを、メディア移転を要求するために使用される要求(例えば、SIP REFER要求)の中に含める。「require」および「explicit」というパラメータもまた、随意で、アクセスレッグ/フロー識別子を含むメディア特徴タグと関連付けられたAccept−Contactヘッダに含まれ得る。Accept−Contactヘッダは、その値とともに、SIP REFER要求の場合、Refer−Toヘッダ内に埋め込むことができる。SCC AS(または別のネットワークノード)は、メディア移転要求を受信する場合に、次いで、メディアが移転されるUEに送信される要求の中に、メディア移転要求からのその値とともに、Accept−Contactヘッダを含む。これは、RFC 3841で説明されている機構を使用した所望のアクセスレッグを使用して、要求をUEに送らせ、それに対応して、要求が受け入れられた場合、そのアクセスレッグを使用してメディアも確立される。メディアが移転されるUEは、(上記の実施例等の)場合によっては、メディア移転要求を送信するコントローラUEの役割を果たす同じUEであり得ることに留意されたい。
図1は、ネットワークと関連付けられたSIP UAまたはUEの間でメディアおよび/またはIUTコントローラ機能を移転するように、本システムによって実装され得る、通信フロー例を図示する。フローは、第1のコントローラUE(UE−1)から第2のコントローリUE(UE−2)へ、2つのメディア構成要素を含むセッションのサービス制御を移転することを可能にする。第1および第2のUEの両方は、例えば、同じSIP URIまたはTel URIを共有すること、あるいは暗示的登録セット(Implicit Registration Set/IRS)によって定義される重複または同一公衆ユーザ識別を有することによって、同じ公衆ユーザ識別を共有し得る。しかしながら、それらは、IMSプライベート識別、IMSI、MIN等であるが、それらに限定されない、一意のプライベート識別を有する。この実施例では、UE−1は、そのセッションがSCC ASで固着される、遠隔UEとの確立されたマルチメディアセッションを有する。UE−1は、最初に、協調セッション制御を促進する。
図1に示されるように、マルチメディアセッションは、2つのメディア構成要素(メディアAおよびメディアB)を含み、UE−1は、IUTを介して、協調セッション制御およびメディア構成要素のうちの1つ(メディアA)をUE−2に移転することを望む。図示されるように、ステップ101では、UE−1は、移転要求をSCC ASに伝達または送信することによって、協調セッション制御およびメディア種類(メディアA)をUE−2に移転するプロセスを開始する。移転要求は、協調セッション制御およびメディア種類(メディアA)がUE−2に移転されることを示す。移転要求は、移転されるメディア種類を含むSDP(おそらくSIP REFER要求のRefer−Toヘッダに埋め込まれる)を含み得る。代替として、メディア種類は、移転要求の中で適切な特徴タグ等を信号伝達することによって示され得る。UE−2は、GRUU、SIP URI、Tel URI等によって識別され得るが、それらに限定されない。ステップ102では、SCC ASは、要求を識別し、検証プロセスを行う。検証プロセスは、UE−1がIUTを行うことを許可されているという検証を含み得、UE−2識別、この実施例では、UE−2のGRUUが、SCC AS(有効なREGISTRATIONが存在する)に記憶され、そのGRUUに対して、UE−1からの要求の中で受信されたものに合致するメディア特徴タグが記憶される。UE−2のGRUUが存在しない、または特徴タグが合致しない場合には、要求が拒絶され得る。代替として、検証プロセスは、SCC ASが承認されたUEのTel URI、SIP URIを回収することを含み得る。回収されたTel URI、SIP URIが、UE−1が使用できるものに合致する場合には、SCC ASは、回収されたTel URI、 SIP URIに合致する別の標的UEを識別し得る。次いで、SCC ASは、accept contactヘッダの中の特徴タグ、ならびにexplicitおよびrequiredパラメータが、要求を実施するものに対する代替的連絡先を選択するように設定されることを確実にする。
UE−1が、UE−2への協調セッション制御およびメディアAの移転を要求することを許可されている場合、SCC ASは、協調セッション制御およびメディアAがUE−2に移転されることを示す要求を、UE−2に伝達または送信し得る。例えば、SIP METHOD(例えば、SIP INVITE)は、協調セッション制御(IUTコントローラ機能)を示すメディア特徴タグとともに、UE−2のGRUUを標的として含み得る。SIP METHODは、「Explicit」および「Required」を伴う必要なメディア特徴タグを、Accept−Contactヘッダの中に含み得る。代替として、移転されるメディア種類を含む、SDPが含まれる。ステップ103では、システムは、UE−2とSCC ASとの間に協調セッション制御を確立する。この時点で、UE−2は、協調セッションのためのコントローラUEになる(IUTコントローラ機能を示すメディア特徴タグを受信することに基づく)。しかしながら、別の実装では、UE−1は、UE−1上で協調セッションを保持しながら、移転されるメディアを含む移転要求を送信し得る。この場合、移転要求は、協調セッション制御(IUTコントローラ機能)の指示、識別子、トークン、フラグ、またはメディア特徴タグを含まない。
1つの実装では、協調セッションは、おそらく、単一のIMSセッションとして遠隔レッグ上で提示されるSCC ASの中で固着される同じIMSサブスクリプションを共有する、2つ以上のUEの上で、論理的な一式の1つ以上のIPマルチメディアサブシステム(IMS)セッションを含む。遠隔レッグは、加入者の視点から見られるように、SCC ASとリモートパーティとの間の呼び出し制御レッグであり得る(追加の実施例については、回路交換メディアを使用するIMSセッションのための遠隔レッグの定義に対する3GPP TS 23.292を参照されたい)。
ステップ104では、UE−2とSCC ASとの間でメディアAを搬送するセッションが確立される。この時点で、システムは、随意で、UE−2との新しいセッションの確立に従って、SCC ASとリモートパーティとの間の遠隔レッグを更新し得る。例えば、遠隔レッグは、ビデオコーデック調整または変更を実装するように構成され得る(例えば、IPTVデバイスによって、またはそうでなければメディアを再交渉するために変更が必要とされるため)。UE−2への協調セッション制御の確立およびメディアAの移転の成功後、SCC ASは、ステップ105で、移転応答をUE−1に返送する(例えば、RFC 3515の通りの最終応答に対するSIP NOTIFY要求)。移転応答を受信した後、ステップ106で、UE−1上でメディアAを搬送する以前のセッションが解放され得、協調セッションが解放される。協調セッション制御の成功した移転後、UE−1は、協調セッションの一部としてのコントローリUE(セッション制御のためのコントローラUEより下位にありながら、メディアフロー(メディアB)を受信および/または伝送するUE)となり、UE−2は、コントローラUEの役割を担う。メディア種類(メディアA)は、UE−2とリモートパーティとの間で伝達され、メディア種類(メディアB)は、UE−1とリモートパーティとの間で伝達され続ける。移転が成功しなかった場合、SCC ASは、移転の失敗を示すメッセージをUE−1に返送する。メッセージは、SIP 488(Not Acceptable Here/受諾不可能)応答を含むことができるが、それらに限定されない。失敗の理由を示す応答に、警告が含まれ得る。移転の失敗を示すUE−1へのメッセージは、UE−2からの応答のSIPfragを本文に含む、SIP NOTIFY要求に含まれ得る。
図1に図示された通信フローは、UE間のメディアおよび協調セッション制御の移転を可能にする。メディアおよび協調セッション制御移転に加えて、上記のフローはまた、1つ以上のコントローラUEが標的UEにコントローラ機能を与えることを承認した後、UE間でコントローラ機能を移転し得る。
1つの実装では、(例えば、IMSサービス連続性のために)セッション移転を促進するために、UEは、セッション移転のための(例えば、上記で説明されるような)操作者方針を記憶し、適用するように構成され得る。UEはまた、現在の操作者方針、ユーザ選好、およびローカル動作環境情報を含むトリガ基準に基づいて、セッション移転手順を開始し、セッション移転動作を行うための必要な詳細をSCC ASに提供し得る。UEはまた、IUTに対するコントローラまたはコントローリ機能性をサポートする能力を提供し、現在の操作者方針およびユーザ選好に基づいて、IUT手順を開始し、IUTを行うための必要な詳細をSCC ASに提供し得る。
UEは、おそらく異なるアクセスネットワークを使用して、複数の登録コンテンツを有することができる。UEは、ネットワークまたはアプリケーションサーバ(Application Server/AS)におけるIUT方針および実装に応じて、いくらかまたは全てのメディア伝送に異なるネットワークを使用するように構成され得る。例えば、UEは、何らかの所定のユーザ選好またはネットワーク/操作者方針に従って、適切な性質を有するビデオ種類メディア伝送に、無線ローカルエリア(Wireless Local Area Network/WLAN)無線または何らかの他のアクセスネットワークを使用し得る。
性質または標的UEあるいは特定の標的UEを示す指標も、(例えば、同じデバイスによってサポートされる)アクセス技術を識別することが可能であり得る。上で説明される手順を使用した特定のアクセス技術を使用する、特定のアクセスレッグ上で、要求を送ることができる。
他のシステム実装では、コントローラUE機能性はまた、セットトップボックス等の物理的なボックスの中でホストされ得るか、またはパーソナルコンピュータ、メディアサーバ、ホームノードB、またはユーザによって物理的に操作されない他のデバイス上でホストされる、実行可能なソフトウェアであり得る。一実施例では、ユーザは、メディアシンクまたはコントローリUEによって包囲される。メディアシンクは、コントローラUEまたは他のメディアコントローラデバイスとの相互作用を可能にするか、またはそれを補完し得る。例えば、TVのリモコンが、停止および巻き戻しまたは他の機能を提供し、それらがメディアシンクまたはTVによって傍受され、種々の機能を処理するように構成されるデバイスまたはUEに転送され得る。いくつかの実装では、単一のボックスが、異なる外部の物理的デバイスに対する複数のSIP UAをサポートし得る。例えば、ホームサーバまたはセットトップボックスは、基本TV、レガシー固定回線電話、および非SIP使用可能家庭用娯楽システム等の他の接続された非SIP対応デバイスのための複数のSIP UAを実装し得る。
ここで図2を参照すると、IUTを行うために本システムを実装するための例示的な通信ネットワークが図示されている。ネットワーク212は、通信ネットワークであり、基地局、SCC AS、P(Proxy/プロキシ)−CSCF、S(Serving/サービング)−CSCF、およびI(Interrogating/問い合わせ)−CSCF等の呼び出しセッション制御機能(Call Session Control Function/CSCF)、移動交換センター(MSC)サーバ、IMS集中サービス(IMS Centralized Service/ICS)のMSC進化型、および/または、デバイス能力、ユーザ選好、IUTのためのコントローラUEおよびコントローリUEのリスト、デバイスごとのセッションレッグマッピング情報、および本システムを実装する際に使用される他の規則または制限を記憶するための種々のデータ記憶システム等の種々の構成要素を含む。ネットワーク212と通信することによって、UEは、ネットワークと関連(例えば、REGISTERED)し、ネットワーク212を通して、他の関連UE、またはネットワーク212を介して通信するように構成される他のデバイスと通信することができる。ユーザ214は、いくつかのUE216、218、および220を有する。UE216、218、および220は、例えば、IRSセットAにおいて、Tel URIまたはSIP URIによって定義され得る、単一の識別230を共有する。ユーザ222は、同様にネットワーク212に接続される、UE224および226を有する。UE224および226はまた、例えば、IRS Bによって、識別を共有する。
図2では、ユーザ214のUEは、いくつかの異なるデバイスを含む。UE216は、ビデオ能力を持たない携帯電話であり、UE218は、ボイスオーバーIP(VoIP)およびビデオ会議能力を有するラップトップであり、UE220は、ネットワーク212と通信するように構成されるが、最小限のユーザ入力能力を有する、テレビである。本実施例では、テレビ220は、ネットワーク212と通信するためのプロキシ221への配線接続によって接続される。プロキシ221は、ホームゲートウェイ、ケーブルボックス、セットトップボックス、またはネットワーク212と通信するための他のシステムを含み得る。プロキシ221は、無線で、または配線接続を介して、ネットワーク212と通信し得る。しかしながら、当業者であれば、プロキシ221のうちのいくらかまたは全てが、テレビ220に組み込まれ得ることを理解するであろう。UE216、218、および220のそれぞれが、ネットワーク212との接続を確立すると、IUTコントローラ機能は、ユーザ214と関連付けられたUEのうちの1つ以上に割り当てられ得る。IUTコントローラ機能は、UEの機能的能力、ユーザ選好、ネットワーク要件、またはユーザ214、ネットワーク212、あるいは通信ネットワーク212内の任意の他のエンティティを介して利用可能となる他のデータの任意の組み合わせを評価する、規則に基づいて、割り当てられ得る。本実施例では、UE216(携帯電話)が、最初にIUTコントローラ機能を割り当てられる。そして、UE216が、進行中のセッション上のあるメディアの移転要求をUE218および220のうちのいずれか1つに送信し得る。移転プロセスの一部として、UE216はまた、IUTコントローラ機能をUE218および220のうちのいずれかに移転するネットワーク212への要求を発行し得る。場合によっては、ネットワーク定義およびユーザ定義された規則に応じて、メディアおよびIUTコントローラ機能の一部または全てが、ユーザ222に属するUE224および226に移転され得る。
図2を参照すると、ユーザ214は、携帯電話216を使用して、ユーザ230に属するUE232への通話を開始し得る。携帯電話216がビデオをサポートしないため、確立されたセッションは、ビデオを伴わずに音声のみを含む。しかしながら、ユーザ230のUE232がビデオをサポートし、ユーザ230がビデオをセッションに追加することを希望する場合、ユーザ230は、ビデオをセッションに追加する要求または招待をユーザ214に発行し得る。携帯電話216がビデオを処理することができないため、ユーザ214が、ビデオを処理することができるUEにリダイレクトするようにUE216に通告しない限り、ビデオをセッションに追加することはできない。この実施例では、ビデオを進行中のセッションに追加する要求を受信すると、ユーザ214は、ビデオ会議能力を有するラップトップ218にビデオ種類を伴う要求をリダイレクトするようにUE216に通告し得る。ラップトップ218にビデオを伴う要求をリダイレクトするためには、携帯電話216は、ネットワーク212にビデオ種類を伴う要求をリダイレクトするために、SIP 3xx非最終応答等のメッセージを生成する(仮に、SIP 3xx応答等の最終SIP応答が使用された場合、セッション全体がリダイレクトされ得る)。システム実装に応じて、リモートパーティから新しいメディア種類を追加する要求を受信すると、ネットワーク(例えば、SCC AS)は、例えば、デバイス能力、ユーザ選好、またはネットワーク規則に基づいて、標的UEへの招待を自動的に開始し得る。代替として、携帯電話218によって提供されるユーザインターフェースは、ユーザ214が、メッセージをラップトップ218にリダイレクトするように携帯電話218に通告することを可能にし得る。ネットワーク212(例えば、SCC AS)が、要求をリダイレクトする要求を受信した後、ネットワーク212(例えば、SCC AS)は、ラップトップ218がビデオ種類メディアをサポートできることを検証する。これは、ラップトップ218のSIP REGISTRATIONの一部としてSCC AS212に渡され、REGISTRATIONラップトップ218のGRUUメディア特徴タグに対してSCC AS212に記憶された、メディア特徴タグを、SCC AS212が調べることから成る。
SCC AS212は、携帯電話216が出力先変更を要求する能力を有し、そのような要求を行う権限を与えられていることを検証する。これらの要件が満たされた場合、SCC AS212は、コントローラからのSIP METHOD(例えば、SIP INVITE)に含まれた特徴タグが、メディアがリダイレクトされるSIP Contactに対して記憶されているかどうかをチェックし得る。メディア特徴タグが存在する場合、SCC ASは、メディアタイプを含むSDPを伴う招待要求(例えば、SIP INVITE)を送信することによって、要求をラップトップ218にリダイレクトする。SCC ASはまた、RFC 3841による「Explicit」および「Required」を設定して、正しい標的がS−CSCFにおいて選択されることを確実にする。出力先変更および協調セッション確立が成功すると、携帯電話216は、ラップトップ218へのIUTコントローラ機能の移転を要求し得る。
本実施例では、IUTコントローラ機能性がラップトップ218に移転される。そして、ラップトップ218は、ユーザ214にアクセス可能な他のUEへのビデオ会議セッションを再び有するというオプションを有する。例えば、より多くの人々の集団による進行中のビデオ会議の閲覧を促進するために、ユーザ214は、ネットワーク212を介して通信するように構成されるラップトップ218上でビデオ会議を保持しながら、ビデオ会議上のメディアのいくらかまたは全てをテレビ220に複製することを希望し得る。この実施例では、テレビ220は、マイクロホンを含まない。そして、ユーザ214は、(IUTコントローラの状態を有する)ラップトップ218を使用して、進行中のビデオ会議セッションのビデオ部分のみをテレビ220に複製するようにネットワーク212に通告する。SCC ASが、移転後に、移転されたレッグからメディア種類を解放する1つの実装では、複製が要求されることを信号伝達する必要がある。複製は、新しいメディア特徴タグ、SDP変数、パラメータ、および/またはSIPヘッダを使用して、信号伝達され得る。移転するUEが、移転後に、移転されたレッグからメディア種類を解放する別の実装では、要求される複製の信号伝達は必要とされない。複製を承認すると、SCC AS212は、ビデオメディア種類を伴うセッション招待(SIP INVITE)等のメッセージをテレビ220に送信して、閲覧を促進する。しかしながら、セッションの音声部分は、ユーザ214がユーザ230と通信し続けることができるように、ラップトップ218にとどまる。この実施例では、テレビ220はまた、追加のメディア移転を開始するためのユーザ入力を受信するためのユーザインターフェースを持たない。したがって、IUTコントローラの状態は、ユーザ214がテレビ220から別のデバイスへビデオ会議のビデオ部分を移転し得るように、ラップトップ218にとどまる。IUTコントローラの状態がレガシーテレビ220に移転された場合、レガシーテレビ220が、そのような移転を開始するための適切なユーザインターフェースを提供することができないため、セッションを別のデバイスに移転する機構がない場合があり、セッションのビデオ部分はレガシーテレビ220にとどまったままとなる。
システム実装に応じて、種々の方針または制限が、各ユーザに対して確立され得るUEの数および組み合わせに適用され得る。例えば、ネットワークは、1つだけのIUTコントローラ対応UEがIUTコントローラになることができることを定める制限を実装し得、また、複数のIUTコントローラ対応UEが任意の協調セッションのためのIUTコントローラになることができ、複数のIUTコントローラ対応UEが、全ての協調セッションに対して複数のUEを伴うIUTコントローラになることができるが、同じ協調セッションにつき1つのIUTコントローラUEのみでくあることを定める制限を実装し得る。さらに、好ましいベアラ(例えば、回路交換またはパケット交換)が、ネットワーク規則、ユーザ選好、または任意の組み合わせによって特定され得る。例えば、好ましいベアラ設定は、例えば、発話メディア種類セッションについては回路交換、およびビデオ種類セッションについてはパケット交換であり、メディア種類およびデバイス能力に依存し得る。
ネットワーク(例えば、SCC AS)はまた、課金目的で、どのUEがIUTコントローラであるかという指示、IUTコントローラ機能を果たすUE識別、一式のUEが同じサブスクリプションに属することを示すIUTに対するサブスクリプションセット指示、およびベアラ指示(使用されているベアラに応じて、異なる課金があり得る)といった指示を使用し得る。
本システムでは、各UEは、(例えば、SCC ASまたは通信ネットワークの別の構成要素を介して)ネットワークと通信して、UEがIUTコントローラ機能性をサポートする能力を有するかどうかに関して、ネットワーク、この場合ではSCC ASに通告するように構成し得る。一実装では、UEは、SIP REGISTER、SIP PUBLISH、SIP SUBSCRIBE、SIP NOTIFY、SIP INVITE、SIP Re−INVITE、SIP UPDATE、SIP OPTIONS、およびSIP REFER等のSIP METHOD、または、例えば、SOAPあるいはHTTPを使用した、構成アクセスプロトコル(Configuration Access Protocol/XCAP)あるいはウェブサービスベースである、SIP応答(SIP Response)あるいはエクステンシブルマークアップランゲージ(eXtensible Markup Language)を含む、SIPメッセージ等を使用して、その能力をSCC ASに伝送する。UEがその能力をSCC ASに伝送するための1つの方法は、メディア特徴タグ、例えば、Contactヘッダの中のg.3gpp.iutを使用することである。例えば、Contactヘッダを含む、SIP REGISTER、SIP SUBSCRIBE、SIP NOTIFY、SIP INVITE、SIP Re−INVITE、SIP UPDATE、SIP OPTIONS、SIP PUBLISH、およびSIP REFER等のSIP METHODは、IUTコントローラ機能性のための特定のUEのサポートを示すIUTコントローラメディア特徴タグを含むように構成され得る。代替として、SIP 200 OK等のSIP応答も、UEのコントローラ能力を示すように構成され得る、Contactヘッダを含むことができる。
Contactヘッダを使用して実装されると、IUTコントローラ特徴タグは、例えば、3つの可能な値を含み得る(システムが種々の名前および属性を有する他の値を使用し得るため、例示的な値のみを説明する)。第1に、値「Active(能動)」は、IUTコントローラ特徴タグと関連付けられた連絡先アドレスを伴うUEが、セッションのためのIUTコントローラとしての役割を現在果たしていることを示し得る。第2に、値「Inactive(非能動)」は、IUTコントローラ特徴タグと関連付けられた連絡先アドレスを伴うUEが、セッションのためのIUTコントローリ(すなわち、アクティブIUTコントローラではなく)としての役割を現在果たしているが、IUTコントローラ役割を割り当てられることが可能であることを示し得る。第3に、値「Passive(受動)」は、IUTコントローラ特徴タグと関連付けられた連絡先アドレスを伴うUEが、セッションのためのIUTコントローリとしての役割を現在果たしており、IUTコントローラ役割を受け入れることが不可能であるか、または進んで受け入れようとしないことを示し得る。受動はまた、デバイスがコントローリとしての役割を果たすことができるが、コントローラ機能性を持たないことを意味することもできる。
いくつかの実装では、IUTコントローラ指示は、特定のUE上で、(Active,Inactive)または(Active,Passive)等の2つの特定の値を含み得る。値の定義例は、g.3gpp.iutcontroller=”active”、またはg.3gpp.iutcontroller=”passive”を含み得る。場合によっては、IUTコントローラ値は、バージョン指標が付与される。例えば、IUTコントローラ値は、「activeX」であり得、Xは、UEによってサポートされるIUTのバージョンを示す、0または1からYまでの値であり得る。別の実施例は、g.3gpp.iut=[capability]であり、それにより、能力は、「コントローラ」または「コントローリ」等であるIUTデバイスの能力を示す。コントローラは、「activecontroller」または「passcontroller」となるように拡張することができる。Activecontrollerは、SIP UA/UEがセッションのためのコントローラ活動を行っていることを意味し、passcontrollerは、SIP UA/UEがコントローラ能力を有するが、コントローラとしての役割を果たしていないことを意味する。特徴タグの定義例が、以下の表4で提供されるが、当業者であれば、SIP UA/UEから同じ意味を伝えるために、適切な英数字の任意の構築を使用できることを理解するであろう。
Figure 2012526415
他の実装では、IUTコントローラ機能をサポートするUEは、SIP、XCAP等を使用して、ユーザ選好に基づいてIUTコントローラ設定を有効または無効にするように、ユーザによって構成することができる。IUTコントローラUEまたはコントローリUEの有効化または無効化設定は、例えば、SIPまたはXCAPメッセージのXML MIME本文の中へ配置され得る。IUTコントローラ設定がUE上で有効にされる場合には、UEは、IUTコントローラUEとしての役割を果たす。IUTコントローラ設定がUE上で無効にされる場合には、UEは、IUTコントローリUEとしての役割を果たす。以下は、XMLにおいて特定のUEに対するIUTコントローラ機能性を設定する実施例である。
<?xml version=”1.0” encoding=”UTF−8”?>
<iutcont−settings xmlns=”urn:3gpp:params:xml:ns:ims:iutcont−settings”
xmlns:xsi=http://www.w3.org/2001/XMLSchema−instance
xsi:schemaLocation=”urn:3gpp:params:xml:ns:ims:iutcont−settings ”>
<entity id=”do39s8zksn2d98x”>
<iutcont−settings>
<interuetransfer−controller active=”true” />
</iutcont−settings>。
特定のUEがコントローラUEとしての役割を果たす能力を有し、かつそのように役割を果たすことが好まれるかどうかについて、ネットワークに通知することに加えて、本システムは、複数のベアラをサポートするUEが、UE能力およびユーザ選好等の情報を記憶するネットワークに、ユーザによって好ましいベアラを示すように構成されることを可能にする。UEに応じて、UEは、例えば、回路交換、パケット交換通信プロトコル、または両方を使用して、ネットワークと通信する能力を有し得る。複数のベアラをサポートするUEについて、SIP、XCAP、または他の符号化スキームを介したユーザ選好を通して、好ましいベアラが特定され得る。1つの実装では、好ましいベアラは、特定のメディア種類および/またはデバイス能力に従って特定される。例えば、特定のベアラは、特定の能力を有するデバイス上の特定のメディア種類に特定され得る。代替として、メディア種類および/またはデバイス能力にかかわらず、一般的なベアラ選好が全てのUEに特定され得る。ベアラ選好は、例えば、SIPまたはXCAPメッセージのXML MIME本文の中で特定され得る。以下は、XMLにおける例示的なコーディングを示す。
<?xml version=”1.0” encoding=”UTF−8”?>
<iutcont−settings xmlns=”urn:3gpp:params:xml:ns:ims:iutcont−settings”
xmlns:xsi=http://www.w3.org/2001/XMLSchema−instance
xsi:schemaLocation=”urn:3gpp:params:xml:ns:ims:bearer−settings ”>
<entity id=”do39s8zksn2d98x”>
<bearer−settings>
<preferred−bearer>PS</preferred−bearer>
</bear−settings>。
UEの能力、および随意でUEに対する好ましいベアラに関するユーザ選好を示すメッセージを受信すると、基地局、P−CSCF、S−CSCF、およびI−CSCFのような呼び出しセッション制御機能、移動交換センター(MSC)サーバ、ICS用のMSC進化型、またはSCC AS等の1つ以上のネットワーク構成要素は、IUTコントローラ機能がUE上でサポートされることと、コントローラとしてUEを使用する選好とをメッセージが含む場合、UEがコントローラとしての役割を果たすことを許可され、かつそのような役割を果たすことができることを検証し得る。一実施形態では、SCC ASはまた、受信されたメッセージが、サポートされたベアラ種類および/または特定のベアラ種類を使用する選好を含む場合に、UEが特定のベアラをサポートし、それを登録していることを検証し得る。
検証中に、SCC ASは、例えば、SIP REGISTER要求のContactヘッダの中のIUTコントローラメディア特徴タグを調べることによって、どのUEがコントローラであるべきかを決定する。1つの実装では、SCC ASは、サブスクリプション登録イベントパッケージまたは強化された第三者登録手順(第三者SIP REGISTER要求の本文に含まれる着信SIP REGISTER要求)を使用して、メディア特徴タグを取得する。SCC ASはまた、登録UEに使用することができるベアラを決定し得る。ネットワークの方針の中の好ましい/サポートされたベアラ値が、受信されたメッセージのものとは異なる場合、ネットワーク方針によって定義される好ましい/サポートされたベアラ値が優先し得る。要求は、上記で説明される手順を使用した特定のアクセス技術を使用する、特定のアクセスレッグまたは好ましいベアラ上で送ることができる。
UEがコントローラ機能の割当および/または特定のベアラ割当のある要件を満たすことを検証するために、ネットワークは、ユーザの公衆ユーザ識別、例えば、Tel URI、SIP URI等、ユーザのプライベートユーザ識別、例えば、IMSプライベートユーザ識別、IMSI等、どのUE(例えば、インスタンスID、IMEI、MIN、またはGRUU)が同じサブスクリプションセットに属するか、どのUEが同じIUTに属するか、どのUEがIUTコントローラ機能が可能であるか、インスタンスID、IMEI、MIN、グローバルにルーティング可能なユーザエージェントUA URI(Globally Routable UA URI/GRUU)等のデバイス識別、各デバイスへのデバイスニックネームマッピング、各デバイスと接続されたセッションレッグマッピング情報、各UE上のサポートされた好ましいベアラまたは無線アクセス技術(RAT)、複数のPSアクセス技術または複数のサブスクリプションあるいはピアツーピア(P2P)サービスをサポートし、RATまたはサブスクリプションあるいはP2Pサービスにつき少なくとも1つのUAを有する、UEまたは中間物に対するRATあたりの各UAを識別するアドレス、別のUEがコントローラ機能を取得することを可能にする承認規則、およびUEを説明するか、またはUEと関連付けられた他の情報を記憶する、データベースを維持する。このデータベースは、HSSに記憶され、Shインターフェースを使用してSCC ASによってアクセスされ得、または情報は、登録の結果としてS−CSCFから受信され得る。データベースは、ネットワーク内の他のエンティティ内に記憶することができる。おそらく、SCC ASの内部またはそれらの組み合わせである。1つの実装では、登録活動を行うために、ネットワークは、データベースの中のUEのIRSをチェックして、登録を要求するUEが、承認UEと同じIRSセットを有することを確認し得る。要求UEが、データベースに記憶された承認UEと同じIRSセットを使用する場合、IRSセットは、IMSプライベートIDによって表される特定の能力、およびUEがコントローラまたはコントローリであり得るかを示し得る。さらに、IRSセットは、UEが制御され得るのみかどうか、およびUEがサービスの内外で登録できるかどうかを示し得る。
本システムの動作中、ネットワークノードは、IUT UEのURIまたは識別のリスト(すなわち、IUT移転を要求するか、または移転されることができるIUT UEのURIまたは識別のリスト、あるいは同じIUTセットに属するコントローラおよびコントローリUEの一式のURI)を、コントローラUEまたは一式のIUT UEに配信し、どのUEがコントローラまたはコントローリであるか、どのUEがIUTコントローラ機能をサポートするか、およびどのUEがIUTコントローラ機能を移転されることができるかという識別を可能にする。IUT UEのURIまたは識別のリストは、デバイスニックネーム、URIあたりのサポートされたメディア種類、または各IUT UEの識別等の情報を含み得る。
UEがネットワークに登録する場合に、UEは、上で説明される特徴タグを含む。UEのGRUUは、登録プロセスの一部として記憶される。次いで、このGRUUは、URIとして全ての潜在的なコントローラUEに伝達される。送信される情報はまた、GRUUによって識別されるUEがIUTコントローラ、コントローラ(受動役割)およびコントローリ、コントローリ対応、またはレガシー対応である場合、適格性を含むこともできる。サポートされるメディア種類、登録されたRAT等も、UEがコントローラとしての役割を果たす場合にUEを支援するように伝達され得る。デバイスが再登録を行い、メディアタグ(例えば、登録されたRATを含む)が変化した場合には、これは、IUTコントローラ対応UEに送信される情報の更新を引き起こし得る。
図3に図示されるように、UEは、SCC ASへの登録を引き起こす、ステップ301で、IMSネットワークに登録する。SCC ASは、登録したデバイスがIUTセットの一部であるかどうかを決定する必要がある。これは、同じIRSにおいてIUT対応である1つから多くのUEがすでにあることをSCC ASが認識することによって決定され得、SCC ASが、ステップ302におけるYで、この決定を行うことができる場合には、SCC ASはステップ303でOMA DMサーバと通信する。SCC ASは、ステップ304で、必要なデバイス、または情報を必要とする他のデバイスに情報を伝達することができるように、OMA DMサーバに必要な識別を含むことができる。これは、インスタンスID、機器識別のリストを含み得る。これらは、登録プロセスで取得されているであろう。場合によっては、登録を行う前に、ICS UEがIMEIを有する場合、ICS UEは、3GPP TS 23.003で定義されるようなそのIMEIに基づいて、インスタンスIDを生成する。
UEが登録する時に送信される、何らかの形態のIUTグループ識別子(表5の実施例を参照)があり得る、別の実装では、この識別子は、異なるIRSからの加入者が同じIUTグループの中にいることを可能にするIUTグループを識別する。この場合、次いで、SCC ASは、UEが登録する時に、UEがIUTセットの一部であるかどうかをチェックする。IUTグループ識別子についての可能な実施形態は、新しいメディア特徴タグ、または以前に定義されたものの拡張であり得る。例えば、3.gpp.iutgroup=[variable]である。
Figure 2012526415
一実装では、IUT UEのURIまたは識別のリストを配信する場合に、サービングSCC ASのアドレスも含まれ、オープンモバイルアライアンスデバイス管理(Open Mobile Alliance Device Management/OMA DM)、クライアントプロビジョニング(Client Provisioning)、または他のデバイス管理およびプロビジョニングプロトコルを介して提供され得る。IUT UEのURIまたは識別のリストを配信するために、ネットワークは、非構造補足サービスデータ(Unstructured Supplementary Service Data/USSD)、ショートメッセージサービス(Short Message Service/SMS)、マルティメディアブロードキャストマルチキャストサービス(Multimedia Broadcast Multicast Service/MBMS)、セルブロードキャスト(CellBroadcast)、GERAN、UTRAN、LTE、WLAN、WiMax、またはCDMA2000上においてGPRS上で作動するIPパイプ等であるが、それらに限定されない無線輸送機構を使用し得る。識別URIは、TEL URI(E.164 numbers)、公衆ユーザ識別を含むSIP URI、またはグローバルにルーティング可能なユーザエージェントURI(Globally Routable User Agent URI/GRUU)であり得る。リストはまた、USIM、SIM、R−UIM、UICC、またはコンパクトフラッシュ(登録商標)であり得るが、それらに限定されない、リムーバルメモリモジュールで設定され得る。代替として、draft−ietf−sipping−config−frameworkで表されるようなSIP CONFIG FRAMEWORK等の、他の構成管理機構を使用することができる。
IUT UEのURIまたは識別のリストは、リストを再放送、送信、または伝達すること、リストが変更および更新された際のみ更新を放送すること、あるいは各コントローラUEが更新されたリストを要求することによって、周期的または非周期的に更新され得る。代替として、リストは、例えば、ユーザインターフェースを介して、更新された情報を各UEに直接伝達することによって、または更新されたリストを含む物理的メディアをUEに提供することによって、更新され得る。UE上のURIのリストは、IRSセットを使用し得る同じIUTグループに属する他のUEが登録または登録解除する場合に、更新される。IUT UEのURIまたは識別のリストを更新することは、S−CSCF、HSS、またはSCC AS等のサービングネットワーク内のHSS、S−CSCF、SCC AS等のサービングネットワークエンティティへ/から、UEが常に追加(あるいは登録)または除去(あるいは登録解除)され得るため、重要であり得る。更新は、上記で説明されるようなエントリの削除、追加、または修正を含み得る。SCC AS、DMサーバ等のネットワークノードは、IUT UEのURIまたは識別のリストを提供する。
図4は、1つ以上のIUT UEを識別するための例示的な許容IUTリスト管理オブジェクトを図示する。MO440は、固定ノードに対するゼロまたは1つのアカウントのプレースホルダとしての役割を果たし得る、ルートノード442を含む。許容IUTエントリ内部ノード444は、サブスクリプションセットIDのリストへの参照を提供するために使用され得、1つ以上のサブスクリプションセットIDのプレースホルダとしてランタイムノード446を含み得る。ランタイムノード446は、1つ以上のIUT UEに対するURIまたは識別、デバイスニックネーム、および/またはメディアトークンのリストへの参照を含み得る。追加のランタイムノード450は、IUT_URI(すなわち、各IUT UEのURIまたは識別)、デバイスニックネーム、およびメディアトークンデータセットのプレースホルダとして使用され得る。ランタイムノード450は、IUT_URI、デバイスニックネーム、メディアトークン、または他のデータを記憶するためのリーフ452、454、および456を含み得る。
UEに対して1つだけのサブスクリプションセットがある場合には、図示されたノードがMOに存在しなくてもよい。図示されたノードは、例えば、ユーザがIUT UEに対する複数のサブスクリプションセットを有する場合、拡張可能性の目的で追加され得る。IUT URI(すなわち、IUT UEのURIまたは識別)ノード、またはIUT URIに対応するデバイスニックネームノード、あるいはMOの中の両方等であるが、それらに限定されない、MO内に含まれる種々のノードがあり得る(それらは強制的ではない)。デバイスに対するメディアトークンノードも、MOに含まれ得る。図5aおよび5bは、図4に示された許容IUTリストMOのパラメータおよびDDFの詳細を図示する。IUT UEのURIまたは識別のリストを配信するために、基本ファイルも使用され得る。例示的な基本ファイル(Elementary File/EF)は、以下で規定れ、許容IUTリスト(EFAIUTL)、IUTデバイスニックネーム(EFIUTDN)、IUTメディアトークン(EFIUMT)、およびIUTコントローラ指示(EFIUTCONTI)定義を提供するために使用することができる。このようにしてEFを使用する場合に、EFは、例えば、USIM、SIM、R−UIM、UICC、またはコンパクトフラッシュ(登録商標)のうちのいずれかの上に含まれ得る。
第1の例示的なEFは、EFAIUTL(Allowed IUT Lists/許容IUTリスト)を含み、表6で図示されている。EFは、UEのIUT URI、すなわち、許容IUTリストに属するIUT UEのURIまたは識別(あるいはデバイスニックネーム)に対するコーディングを含み得る。さらに、リストの中の各IUT URI(またはデバイスニックネーム)について、対応するデバイスニックネーム(またはIUT URI)、メディアトークン、およびIUTコントローラ指示へのリンクが提供され得る。許容IUTリストTLVオブジェクトは、1つまたはいくつかのIUTリストTLVを含み得、各IUTリストTLVは、TEL URI、SIP URI、GRUU、インスタンスID、IMEI等の中の1つ以上と関連付けられる。例示的な許容IUTリスト情報が、以下の表7で図示されている。
Figure 2012526415
Figure 2012526415
表7では、IUTリストタグ’80’のコンテンツは、このTLVの値フィールドの中で提供される、TEL URI、SIP URI、GRUU、インスタンスID、IMEI等の中の1つ以上に適用可能である、IUTサブスクリプションセットあたりの許容IUTリストを含み得る。
IUTリストタグ’80’のコーディング例が図8に示されている。この実施例では、未使用のバイトを’FF’という値に設定することができる。
Figure 2012526415
別の例示的なEFは、図9に示されたEFIUTDN(IUT Device Nickname/IUTデバイスニックネーム)を含む。EFは、IUTデバイスニックネームを含むように構成され得る。この実施例では、IUT URIと対応するデバイスニックネームとの間の関連は、EFAIUTLにおいて提供される。概して、この実施例では、コーディングは、TS 31.101で定義されるようなUCS2コードオプションのうちの1つを使用して行われ得る。
Figure 2012526415
別の例示的なEFは、図10に示されたEFIUTMT(IUT Media Token/IUTメディアトークン)を含む。EFは、IUTメディアトークンを含む。この実施例では、IUTデバイスURIと対応するメディアトークンとの間の関連は、EFAIUTLにおいて提供される。
Figure 2012526415
このEFについて、IUTメディアトークンタグ例が表11に示されている。
Figure 2012526415
このEFについて、IUTメディアトークン情報例が表12に示されている。
Figure 2012526415
表12に示されたこの実施例では、IUTメディアトークンタグ’80’は、IUTメディアトークンのコンテンツ、例えば、テキスト、ビデオ、音声等を有し得、コーディングは、例えば、TS 31.101で定義されるようなUCS2コードオプションのうちの1つを使用して行われる。
別の例示的なEFは、図13に示されたEFIUTCONTI(IUT Controller Indication/IUTコントローラ指示)を含む。EFは、IUTコントローラ指示を含み得る。IUT URIと対応するIUTコントローラ指示との間の関連は、EFAIUTLにおいて提供される。IUTコントローラ指示は、テキスト形式で、またはアイコンで提供され得る。
Figure 2012526415
このEFでは、各指標種類に対する指標状態は、長さ1ビットであり得て、以下のように符号化または設定され得る。ビット値が1に等しい場合、指示をactiveに設定する。しかしながら、ビット値が0に等しい場合、指示をinactiveに設定する。例えば、図23は、参照ビット値位置を伴う指標例の説明図である。
IUT UEのURIまたは識別以外の追加の役立つ情報を伴わずに、IUT UEのURIまたは識別のリストを定義し、利用可能にすると、IUT UEは、他の識別されたUEに関する情報を収集するか、またはSCC AS、あるいはネットワークの他の構成要素と通信することによって、リストを修正するように一方的に作用することができる。一実施例では、IUTコントローラUEは、(例えば、200 OK応答の中の受信されたIUTコントローラ特徴タグを使用することによって)他のIUT UEの能力を決定するように、およびどれが現在利用可能であり、IUT対応であり、IUTコントローラ機能をUEに移転させることができるかを発見するように、リストの中で識別されるUEにSIP OPTIONSを送信する。IUTコントローリUEは、SIP OPTIONS要求等のメッセージに応答して返信される200(OK)応答等のメッセージを介して、IUTコントローラ/コントローリ機能性のサポートを示すメディア特徴タグを含む、他のUEの能力を取得することができる。
IUT UEのURIまたは識別のリストを決定し、随意で、そのリストへの更新を有すると、例えば、SCC AS、HSS等に記憶されたネットワーク内のデータベースは、コントローラUEおよびコントローリUEを識別する情報を記憶し得る。情報は、コンピュータデータベースまたは他の電子記憶媒体等の任意の好適な媒体に記憶され得る。データベースは、システム要件に従って任意の適切なテーブル構造を含み得る。図21は、(例えば、ホーム加入者サーバ(Home Subscriber Server/HSS)内の)関連コントローラおよびコントローリUEを表すネットワーク内で情報を記憶するための例示的な構造の説明図である。図21では、ユーザAは、IUTセットに属する3つのデバイスを有し、デバイスIは、IUTコントローラである。残りのデバイスは、IUTコントローリとして動作する。
図22は、HSS内等のネットワークに記憶された例示的な情報の説明図である。図22は、それぞれ同じサブスクリプションメンバーセットの下にある、3人のユーザに対するデータを示す。ユーザAおよびユーザBが、IUTコントローラ機能を有し、IUT承認規則を設定し得る一方で、ユーザCは、以下のテーブルの中のIUTコントローリとしての役割を果たす。
テーブル内で、サブスクリプションセットは、ローミング同意に従う同じサブスクリプションまたは異なるサブスクリプションに基づくIUT目的に対する、同じユーザの一式のUEである。サブスクリプションメンバーセットは、UE間移転を行うことが許可され、ローミング同意に従う同じ操作者のサブスクリプションまたは異なる操作者のサブスクリプションに属し得るメンバー間の一式のUEである。テーブル内で、IUT UEセットについて、各UEは、IUTコントローラUEまたはIUTコントローリUEとして区別される。各UEは、ニックネーム(例えば、「ベッドルームTV」、「私の携帯電話」等)でマッピングされ得る、GRUU、インスタンスID、またはIMEI等のデバイスIDを有する。さらに、各UEについて、テーブルは、そのUEに対して、あるメディア種類および形式をサポートする能力を定義する。
システム実装に応じて、コントローラおよびコントローリUEを表す情報は、種々のネットワーク構成要素に記憶され得、例えば、承認規則は、XDMSに記憶され得、XDMSに記憶された承認規則への文書リンクは、サブスクリプションデータベースに記憶され得る。一実施例では、各デバイスに対するメディアトークンのリンク、またはIUT制御のための種々の承認規則は、データベースまたは別のネットワークエンティティに記憶される。
ネットワークは、IUTを実装するためのサブスクリプションセット結合を行い得る。サブスクリプションセットは、操作者間同意(ネットワーク間で加入者情報および加入者のデバイス情報を交換する)に応じて、同じ操作者、または異なる操作者間のものであり得る。システムは、同じサブスクリプションセットに対するIUTをサポートし得る。同じ加入者セットは、ネットワーク上のIUTに対する「サブスクリプションセット指示」として示されるべきであり、指示は、同じサブスクリプションセットのメモリ(例えば、ME、USIM、またはISIM)の中のUEに設定され得る。
ネットワークはまた、「最後の好ましい構成」を記憶する能力も有するべきである。例えば、最初の呼び出しで、ユーザが2つのUEの間でビデオ呼び出しセッションを分割した場合(ID Iを有するデバイス上のビデオ、およびID IIを有するデバイス上のビデオ)、ネットワークは、この構成を後続のビデオ呼び出しのために持続させ、複数のUE上の呼び出し結果をもたらすように設定することができる。
ネットワークはまた、「コントローラとしての役割を果たした最後のUE」を記憶する能力も有するべきである。例えば、最初の通信で、協調セッションのために、UE−1は、IUTコントローラ機能としての役割を果たし、UE−2は、IUTコントローリUEとしての役割を果たしている。新しい協調セッションの最初の通信および確立の終了後、以前にコントローラUEとしての役割を果たしたUE−1は、以前の通信の終了後に後続の新しい通信のために、この最後のコントローラUE構成を持続させるように設定されたネットワーク内の情報に基づいて、コントローラUEになる。
UEがネットワークに登録する場合に、UEは、UEを識別する情報をネットワークに伝送する。登録情報は、UEがネットワーク内でコントローラ機能を割り当てられるという要求を含み得る。一実施例では、UEは、識別目的で、IMSプライベート識別、IMS公衆ユーザ識別、およびUEのインスタンスIDをネットワークに提供し、UEがIUTコントローラ対応であるという以前に識別されたような特徴タグを提供する。登録情報は、登録情報を調査することができるSCC ASに提供され得る。次いで、SCC ASは、UEおよびその加入者情報を記憶するデータベースに問い合わせをして、加入者および/またはUEの組み合わせがコントローラになることを許可されているかどうかを決定し得る。データベースは、ローカルまたは外部にあり得る。外部データベース例は、HSS、およびSCC ASの中の内部データベースを含む。登録情報は、ShインターフェースまたはCxインターフェースを介したServiceInfoフィールドを使用して伝送され得る。
上で記載される識別情報の組み合わせをチェックすることによって、SCC ASは、UEがコントローラとなる権限を与えられているか否かを決定することができる。したがって、SCC ASは、プライベートIDをチェックし得、この場合、全てのデバイスがコントローラになることを許可される。SCC ASは、プライベートIDおよびIMEIをチェックし得、この場合、このプライベートIDとともに使用されているデバイスのみがコントローラであり得る。または、SCC ASは、プライベートID、IMEI、および公衆IDをチェックし得、この場合、登録されているデバイス(IMEI)および公衆ユーザIDと組み合わせたプライベートIDがコントローラであり得る。
いくつかの実装では、UEが登録された後、SCC ASは、UEがコントローラとして承認されていることを識別するために後続のSIP方法で使用される、トークン、フラグ、または指示をUEに提供する。トークンまたは指示は、特徴タグ、新しいPヘッダ、またはXML本文に含まれ得る。代替として、SCC ASは、コントローラUEとなることが可能であるものとして、SCC ASの中のUEの登録記録をマークし得る。したがって、UEがINVITEまたは別のSIP METHODを送信する場合に、SCC ASは、その結合をチェックして、UEがコントローラ機能性を果たすことができるかどうかを決定し得る。
システムはまた、追加のチェックを行って、システムの中のデバイスがすでにコントローラとしての役割を果たしているかどうかを決定し得、別のデバイスがコントローラ機能性を要求する場合、システムは、要求を拒絶し、指示をデバイスに提供するか(指示は、帯域外信号伝達機構を含み得る)、または上で説明される規則によって要求を受け入れ得る。
特定のUEに対するコントローラ機能は、コントローラUEと関連付けられた同じユーザによって操作される他のUEを制御することに限定され得る。しかしながら、本システムのいくつかの実装では、1人のユーザの特定のコントローラUEは、特定のコントローラUEおよび他のUEが同じサブスクリプションメンバーシップの下にある場合、他のユーザに属する他のUE上でコントローラ機能を有し得る。その場合、特定のUEは、コントローラ機能を果たすために要求した標的UEによってコントローラ機能を果たすことができることを許可するために、ユーザが承認規則を設定することを可能にする機構を提供し得、SCC ASまたはXDMS等のネットワークは、承認規則を処理し、標的UEがコントローラ機能を果たすことを可能にするかどうかを決定し得る。コントローラ機能を果たすために、UEが、既存のコントローラUEからの同意、またはコントローラUEが指定した1つ以上の標的UEの同意を取得することが必要であり得る。場合によっては、無線サーバの中の任意の標的UEが、コントローラ機能を果たす権限を与えられ得る。UEは、時間的制限、機能的制限(例えば、特定のメディア種類の移転のみを可能にする)に基づいてコントローラ機能を果たし得、または永続的であり得る。コントローラ機能を他のユーザによって操作されるUEに移転するために、任意のコントローラUEが、時間的、機能的、または他の許可規則を設定することを割り当てられ得る。
図6は、承認が単一のコントローラUEのみから要求される場合、IUTコントローラ機能をUEに提供するためのフロー例を図示する。ステップ601では、コントローリUEは、IUTコントローラ機能を受信するように、要求メッセージをネットワークに送信する。ステップ602では、サーバ(例えば、S−CSCFまたはSCC ASを使用する)は、サーバ自体に、またはコントローラUEによって設定されるXDMSのような別のネットワークエンティティに記憶された承認規則を調べ、IUTコントローラ機能の割当に適用する時間的、機能的、または他の制限がないこと、ならびにIUTコントローラ割当のための承認がコントローラUEによって承認されることのみが必要であることを発見する。ステップ603では、ネットワークは、コントローラ機能を受信する標的コントローリUEを承認または承諾するように、要求メッセージをメッセージコントローラUEに送信する。ステップ604では、コントローラUEは、コントローラUEのユーザが要求を受け入れた場合にOK応答を送信する。このステップでは、コントローラUEのユーザは、一時的/永久的許可を設定し得る。場合によっては、一時的/永久的許可へのこれらの制限は、ネットワーク内で事前定義される。ステップ605では、サーバは、コントローラ機能をコントローリUEに与えるために、OK応答を送信する。ステップ604でのOK応答は、ステップ605のものとは異なり得る。サーバは、この応答に、a)一時的または永久的パスワード、およびb)トークン、識別子、または証明書を含み、標的コントローリUEがコントローラ機能を得ることを可能にし得る。標的UEが、IUTコントローラとしての役割を果たす一時的許可のみを受信した場合、現在のセッションを解放または退出するか、あるいはコントローリUE上のいくつかの設定またはパラメータを変更するためのユーザインターフェースを提供するプログラムを終了すると、一時的パスワードが無効になり得、したがって、標的UEはIUTコントローラ機能を保持しない。
図7は、承認または同意が1つより多くのコントローラUEから要求される場合、IUTコントローラ機能をUEに提供するためのフロー例を図示する。ステップ701では、コントローリUEは、IUTコントローラ機能を受信するように要求メッセージをサーバに送信する。ステップ702では、サーバは、既存のIUTコントローラ機能を有するUEを識別し、識別されたコントローラによって設定された承認規則を調べ、サーバがIUTコントローラ機能を有する1つ以上のユーザ(またはユーザのUE)による承認または同意を必要とすることを発見する。ユーザは、自分自身および/またはコントローラ機能を有する他のユーザを指定し得る。ステップ703では、ネットワークは、IUTコントローラ機能を受信する権限を標的コントローリUEに与えるように、要求メッセージをコントローラUEに送信する。ステップ704では、指定されたユーザが要求を受け入れた場合、指定されたユーザのUEがOK応答を送信する。指定されたコントローラUEは、IUTコントローラ機能の提供を承認する時に種々の許可または制限を設定し得る。代替として、種々の時間的、機能的、または永久的制限が、コントローラUEを伴うユーザによって定義され、ネットワーク内で伝送され得る。ステップ705では、サーバは、全ての指定されたユーザがコントローラ機能を与えることを承認した場合、OK応答を送信する。ステップ704のOK応答は、ステップ705のものとは異なり得る。コントローラUEがIUTコントローラ機能の提供に許可または他の制限を設定した場合、ネットワークは、標的コントローラUEに承認を発行する場合に、これらの制限を含める。標的UEが、IUTコントローラとしての役割を果たす一時的許可のみを受信した場合、現在のセッションを解放または退出するか、あるいはコントローリUE上のいくつかの設定またはパラメータを変更するようにユーザインターフェースを提供するプログラムを終了すると、一時的パスワードが無効になり得、したがって、標的UEはIUTコントローラ機能を保持しない。
システム実装に応じて、IUTコントローラUEは、セッション確立前、セッション確立中、または特定のセッションが確立された後に決定され得る。場合によっては、IUTコントローラ機能性をサポートする能力を有し、初期移転要求を送信するUEは、最初にIUTコントローラUEとして割り当てられる。IUTコントローラUEがセッション確立前に決定される場合、UEは、IUTコントローラUEとして動作するUEの能力および関連ユーザ選好に基づいて、IUTコントローラ機能の割当を要求し得る。UEは、ユーザが、IUT UEの利用可能なURIまたは識別のリストから、能動IUTコントローラとして1つのUEを割り当てることのみを可能にし得る。異なるIUTコントローラ設定を同じユーザに対する異なるUEに設定することができる。IUTコントローラがセッション確立時に割り当てられる場合、UEは、例えば、上記で説明されるような「Active」に設定されたIUTコントローラ特徴タグを伴うSIP INVITE、SIP re−INVITE、またはSIP REFER要求等のセッション設定要求を送信し得る。
場合によっては、SCC ASは、RFC 3841に従うAccept−Contactヘッダの中にIUTコントローラを示すメディア特徴タグを含むことによって、セッションへの全ての終端招待がIUTコントローラであるUEに送られることを確実にし得る。
場合によっては、任意の進行中のセッションに対する単一のIUTコントローラUEを割り当てることが望ましくてもよい。したがって、システムが単一のIUTコントローラUEを割り当てるのみであることを確実にするために、特定のUEにIUTコントローラ機能が割り当てられるという要求を受信した後、ネットワークは、要求UEがIUT制御が可能であること、例えば、IUTコントローラ能力を示すメディア特徴タグがcontactヘッダの中に存在すること、要求UEがIUTコントローラとなる権限を与えられていること(コントローラ機能性が上記で説明されるように許可されているかどうかを確認するように、このUEの登録と関連付けられたIMSプライベートユーザIDをチェックすることによって、承認が達成され得る)、ネットワークノードからの方針、例えば、1つだけのUEが任意の進行中のセッションのためのIUTコントローラになるべきであるというSCC ASまたは方針データベースからの方針があること、および同じユーザに対して他の割り当てられたIUTコントローラUEが存在しないことを検証し得る。これら全ての条件が満たされた場合、ネットワークは、要求UEがIUTコントローラとなるものであるという肯定的応答を送信する。ネットワークは、(例えば、GRUUを使用する)どのUEにIUTコントローラ機能が割り当てられているかを特定する指示を他のIUT UEに送信し得る。これは、通知に登録しているUEによって達成さ得、コントローラが割り当てられている時には、通知がコントローラのGRUUを含むUEに送信される。上記の条件のうちの1つ以上が満たされない場合、ネットワークは要求を拒絶し得る。要求を拒絶する際に、ネットワークは、要求を拒絶する理由を説明する理由コードを含み得る。
特定のUEをコントローラとして登録する場合に、承認されたユーザおよび/または承認されたUEのみにコントローラ機能が割り当てられることを確実にするように認証または承認機構を提供することが重要であり得る。一実施例では、IUTサブスクリプションは、ユーザサブスクリプションの他に家族サブスクリプションである。家族サブスクリプションは、父親、母親、および子供のサブスクリプションを含み得る。この実施例では、家庭サブスクリプション間の特定のUEが、コントローラUEになることを許可されていることを検証するために、ネットワーク内の承認機能が使用され得る。1つのネットワーク実装例は、2つの別個のレベルの承認を提供する。
第1に、ネットワークは、加入されているデバイスが、同じサブスクリプションメンバーに属することを許可されているかどうかを決定する。これは、フィルタ基準の結果であり得るが、次いで再度、SCC ASがこれを行っているものであるため、他のフィルタ基準がSIP方法をASに送信し得る。これがSIP REGISTRATIONを行うUEの結果としてIUT対応であるかどうかを示す、SCC ASまで透過的に進むHSSからのService Infoフィールドの中の何かがあり得る。例えば、場合によっては、加入されているデバイスがコントローラ機能を果たすことが可能であるかどうかを決定する情報がSCC ASにあり得る。代替として、情報は、IMSIまたはプライベート識別を介して提供され得る。例えば、全ての家族は同じ個人ネットワークに属するが、父親のみが、母親および子供の他のデバイス上でコントローラとしてデバイスを設定する能力を有する。
第2に、SCC ASは、登録UEが、IUTコントローラになることを許可されているかどうかを決定する。これは、登録されているUEのGRUU情報をチェックすることによって行われ得る。この情報は再度、HSSまたはSCC AS内に記憶され得、それにより、加入者は、どのデバイスがコントローラになり得るかを示す。代替として、UEが登録する時にプライベートIDがあるという点で、情報全体を登録メッセージにリンクすることが可能であり得る。プライベートIDは、UEがIUTを使用する能力を有するか否かを決定するために使用され得る。「コントローラを割り当てる(assign controller)」または「制御される(be controlled)」であり得る、IMSIプライベートID等の能力があり得る。よって、「コントローラを割り当てる」を伴うプライベートユーザIDに由来する任意のUEは、そのUEをコントローラとして設定することを許可される。
IRSにアクセスすることができるIMSプライベートIDは、あるプロファイルを有することができ、例えば、家庭サブスクリプションは、父親、母親、および2人の子供といった4つのIMSプライベートIDを含み得る。父親は、コントローラを割り当てることを許可されている唯一のものである。これらは、サブスクリプションメンバーセットと呼ばれ得る全て同じサブスクリプションメンバーである。
2つのIMSプライベートIDが、グループに対するコントローラを割り当てることができると仮定すると、権限を無効にしなければならず、またはコントローラになることを許可されている場合、別のUEがコントローラになるかどうかを通知される。現在コントローラである場合、変更を拒否するか、または変更を許可することができる。これは、ネットワーク内の状態の通知に登録することを必要とし、ネットワークが特定の方針を有するという通知を受信すると、制御能力を変更することができるかどうかを他のコントローラに尋ねることを必要とする。
IUTコントローラUEは、セッション確立前、セッション確立中、または別のUEへのIUTコントローラ移転機能を要求する時に決定することができる。セッション確立前にIUTコントローラUEを決定する場合に、UEは、UEの能力およびユーザ選好に基づいてIUTコントローラ機能を有するための要求を送信する。UEは、ユーザが、IUT UEに対するURIまたは識別から、1つより多くのUEを能動IUTコントローラにすることを可能にし得る。セッション確立中にIUTコントローラUEを決定する場合、および任意のIUTコントローラ対応UEによって別のUEへのIUTコントローラ機能移転を要求する場合に、UEは、IUTコントローラ機能を示すメディア特徴タグを伴うSIP INVITE、SIP re−INVITE、またはSIP REFER要求等の要求を送信する。メディア特徴タグは、移転されるIUTコントローラ機能を識別する、IMS通信サービス識別子(IMS Communication Service Identifier/ICSI)値またはIMSアプリケーション参照識別子(IMS Application Reference Identifier/IARI)であり得る。ネットワークが要求を受信すると、ネットワークは、要求UEがIUTコントローラになることが可能であること、要求UEがIUTコントローラとなる権限を与えられていること(コントローラ機能性が許可されているかどうかを確認するように、このUEの登録と関連付けられたIMSプライベートユーザIDをチェックすることによって、承認が達成される)、および複数のUEが任意の進行中のセッションまたは同じ協調セッションのためのIUTコントローラになるものであるという(例えば、方針データベースからの)方針があることをチェックする。
これら全ての条件が満たされた場合、ネットワークは、要求UEがIUTコントローラとなるものであるという肯定的応答を送信する。ネットワークは、(例えば、GRUUを使用する)どのUEがIUTコントローラであるかという指示を他のIUT UEに送信し得る。上の条件のうちの1つまたは1つより多くが満たされない場合、ネットワークは要求を拒絶し、随意で、要求が拒絶された理由を説明する理由コードを提供し得る。
IUTコントローラUEとして確立されると、コントローラUEは、メディア種類をあるコントローリUEに移転するように、またはIUTコントローラ機能を他のUEに移転するように、ネットワークに要求を発行し得る。IUTコントローラUEがメディアおよび/またはコントローラ機能をコントローリUEに移転するために、IUTコントローラUEは、SIP REFER要求等のメッセージを、ネットワーク、例えば、SCC ASに送信する。SIP REFER要求は、SCC ASがRefer−Toヘッダの中のURIによって識別されるコントローリUEに送信することになるSIP INVITE要求またはSIP Re−INVITE要求のSIPヘッダおよび/またはSDPコンテンツのうちの少なくともいくつか等の、REFER−TOヘッダの中のURI内に埋め込まれた別のメッセージを含み得る。コントローリUEに送信されるSIP INVITE要求またはSIP RE−INVITE要求は、コントローリUEに移転されるメディア種類を識別するデータを含み得る。制御がそれに移転されているとコントローリUEが決定することを可能にするために、SIP INVITE要求はまた、IUTコントローラ機能を識別する識別子も含む。この識別子は、a)SIPヘッダフィールドの中のIUTコントローラ機能を識別するURI、b)Request−URIの中またはTOヘッダ内のURIの中の新規SIP URIパラメータ(すなわち、IUTコントローラURIパラメータ)、c)(RFC 3841の通りに)Accept−Contactヘッダに含まれるIUTコントローラを示すメディア特徴タグ、d)Accept−Contactヘッダに含まれる「g.3gpp.app_ref」特徴等の、移転されるべきIUTコントローラ機能を識別するIMS通信サービス識別子(IMS Communication Service Identifier/ICSI)値またはIMSアプリケーション参照識別子(IMS Application Reference Identifier/IARI)(UEは、以前の登録場合に、RFC 3840の通りにSIP REGISTER要求のContactヘッダの中にメディア特徴タグを登録しているであろうことに留意されたい)、またはe)IUTコントローラ機能が移転されることを示す新規SIPヘッダフィールド(例えば、RFC 3427に従ったPヘッダ)を含み得る。別の実装では、3.gpp.iut特徴タグは、コントローラ機能が移転されていることを識別するように、追加のオプションを伴って拡張することができる。実施形態例が以下の表14に含まれる。
Figure 2012526415
他の実施例はまた、UEがコントローラ機能性を移転するための要求を行う場合に、UEがメディア特徴タグをコントローリ(controllee)に設定することも含むことができる。SCC ASが要求を受信すると、SCC ASは、メッセージが受信されたUEの状態をチェックする。UEの状態がコントローラとして割り当てられている場合、UEは、UEがコントローラ機能性をメッセージの中で識別された標的デバイスに伝達したがっていることを知る。SCC ASがメッセージを標的デバイスに送信する場合に、メッセージは、コントローラ機能性がUEに割り当てられていることを識別するトークンまたは識別子を含み得る。
図8の以下の実施例は、IUTコントローラUEによって要求されるように、第1のコントローラから別のUEにIUTコントローラ機能および/またはメディア種類を移転するためのフロー例を図示する。実施例では、UE−1は、SCC ASにおいて固着されるリモートパーティとの確立されたマルチメディアセッションを有する。マルチメディアセッションは、2つのメディア構成要素(メディアAおよびメディアB)を含み、UE−1は、協調セッション制御およびメディア種類のうちの1つ(メディアA)を別のUE−2に移転することを希望する。実施例では、UE−1およびUE−2は、同じアクセスネットワークベアラまたは異なるネットワークアクセスベアラを使用して、登録していてもよい。UE−1およびUE−2は、異なるネットワーク間インターネットプロトコル接続(Internet Protocol−Connection Across Network/IP−CAN)、例えば、UE−1上で3GPP IP−CAN、UE−2上で非3GPP IP−CANを使用し得る。固着されたSCC ASまたは別のネットワークエンティティは、各UEにどのようなベアラを使用するかを決定し得る。UE−1およびUE−2が同じ加入者に属することが仮定される。
UEがIP CANを介してIP接続を獲得する時はいつでも、UEは、TS 23.228で定義されているようにIMSに登録することができる。その場合、ユーザプロファイルは、IMSプライベートユーザ識別に結びつけられるC MSISDNを含む。S−CSCFは、SCC ASに向けた第三者登録を行うために、TS 23.218で定義された手順に従い得る。メディアにCSアクセスを使用する場合、UEは、TS 23.292で定義されているようにIMSに登録され得る。TS 23.228で定義されているようにIMSに登録する場合に、UEは、IUTに対するコントローラまたはコントローリ機能性をサポートするための能力を示し得る。S−CSCFがSCC ASに向けた第三者登録を行うためのSIP REGISTER要求例が、以下の表15に示される。
Figure 2012526415
Figure 2012526415
図8は、IUTコントローラUEによって要求されるように、IUTコントローラ機能をUEに移転するためのフローを図示する。ステップ801では、UE−1は、協調セッション制御およびメディア種類(メディアA)をUE2に移転することを決定する。UE−1は、要求をSCC ASに送信し、現在の協調セッション制御およびメディア種類(メディアA)がUE−2に移転されることを示す。ステップ802では、SCC AS(または任意の他のネットワーク構成要素)は、移転要求を識別し、UE−2がコントローラとしての役割を果たすことを許可され、かつそうすることが可能であることを検証し、UE−2が、適切な能力、例えば、RFC 3840の通りの特徴タグを登録していることを検証し、デバイス能力、ユーザ選好、および/またはネットワークの中の方針に基づいて、UE−2にどのようなベアラを使用するかを決定し、選択されたベアラがUE−2によって登録されているかどうかを決定する。ステップ803では、SCC ASは、GmまたはI1参照点、あるいは協調セッション制御およびメディア種類(メディアA)が移転されるものであることを示す他のデータ移転方法を使用して、セッション確立要求メッセージを生成し、UE−2に送信する。ステップ804では、協調セッション制御がUE−2とSCC ASとの間で確立される。UE−2は、確立された協調セッションのためのコントローラUEになる。ステップ805では、UE−2とリモートパーティとの間でメディア種類(メディアA)を伝達するためのセッションが確立される。この場合に、遠隔レッグがそれに応じて更新される。UE−2上での協調セッション制御およびメディア種類(メディアA)の確立の成功後、SCC ASは、ステップ806で、移転要求メッセージへの応答メッセージまたは移転要求メッセージの結果をUE−1に通知する別のメッセージ(例えば、RFC 3515の通りにSIP REFER要求の結果として受信された最終応答に対して送信される、SIP NOTIFY要求)をUE−1に送信する。最終的に、ステップ807では、UE−1上の以前のメディア種類(メディアA)セッションが解放され得、協調セッション制御が解放される。この場合に、UE−1がコントローリUEになる。
図9は、UE−1からUE−2にIUTコントローラ機能性を移転するためのフロー例を図示し、着信セッション要求は、Gm参照点上で送達され、メディアは、回路交換ネットワークを介して伝送される。MSCサーバ進化型ICSは、図示されたフローを実装するための相互作用エンティティの例示的なエンティティであり得る。代替として、相互作用エンティティは、レガシーMSCサーバおよびMGCFから成り得る。相互作用エンティティがMSCサーバおよびMGCFに対応する場合に、CSベアラ設定手順は、TS 23.292の図7.4.2.2.2−2のステップ11−17に従う。
図9を参照すると、ステップ901および902では、UE−1は、協調セッション制御およびメディアAをUE−2に移転することを決定する。したがって、UE−1は、IMSエンティティを介して要求をSCC ASに送信し、現在の協調セッション制御およびメディアAがUE−2に移転されることを示す。この実施例では、IUTコントローラUEは、1)ソースUE(Fromヘッダフィールド、P−Asserted−Identityヘッダフィールド、またはP−Served−Userヘッダフィールド内に含まれ得る)、2)標的UE(Refer−Toヘッダフィールド内に含まれ得る)、3)IUTコントローラ移転指示(Accept−Contactヘッダフィールド内に含まれ得、例えば、INVITE要求に埋め込まれるか、またはRefer−Toヘッダフィールドに埋め込まれる)、4)Target−Dialog−ID(標的UEがすでに協調セッションの一部である場合に、既存のダイアログ識別子を含むTarget−Dialogヘッダフィールド内に埋め込まれ得、これが標的UEに対する新しいセッションである時には、Target−Dialog−IDがない)、および5)メディア種類(例えば、音声、ビデオ、ファイル等)(例えば、Refer−Toヘッダフィールドに含まれる)といった、情報を有する要求を伝送することによって、SIP REFER等を介して移転要求を開始することができる。
ステップ905では、SCC ASは、要求(例えば、SIP REFER要求)を識別し、UE−2がコントローラとしての役割を果たすことを許可され、かつそうすることが可能であることを検証し、UE−2が、適切な能力、例えば、RFC 3840の通りの特徴タグを登録していること、デバイス能力、ユーザ選好、および/またはネットワークの中の方針に基づいて、UE−2にどのようなベアラを使用するか、選択されたベアラがUE−2によって登録されているかどうかを検証する。UE−2がコントローラとしての役割を果たすことを許可されていない場合、SCC ASは要求を拒絶し得る。UE−2が協調セッション制御移転を拒絶する場合、拒絶を示す好適な応答が送信される。応答は、移転を拒絶する理由を示し得る。そのような応答は、提供されるメディア種類またはコーデックが受諾不可能である場合に、SIP 488(Not Acceptable Here/受諾不可能)であり得る。失敗の理由を示す応答に、警告が含まれ得る。移転の失敗を示すUE−1へのメッセージは、UE−2からの応答のSIPfragを本文に含む、SIP NOTIFY要求に含まれ得る(例えば、SIP 488(Not Acceptable Here/受諾不可能)応答)。
ステップ906および907では、ステップ905で受信されたメッセージが、音声またはビデオに対するメディア移転を含む場合には、SCC ASは、セッション確立要求メッセージを生成し、UE−2に送信する。SIP INVITE要求、またはSIP REFERを受信した後に送信されるSIP re−INVITE等のセッション確立要求メッセージは、1)ソースUE(Referred−ByヘッダフィールドおよびP−Asserted−Identityヘッダフィールド、P−Preferred−Identityヘッダフィールド、またはP−Served−Userヘッダフィールド内に含まれ得る)、2)標的UE(ToヘッダフィールドおよびRequest−URIフィールドに含まれ得る)、3)IUTコントローラ移転指示(Accept−Contactヘッダフィールドに含まれ得る)、4)Target−Dialog−ID(標的UEがすでに協調セッションの一部である場合に、既存のダイアログ識別子を含むTarget−Dialogヘッダフィールド内に埋め込まれ得、これが標的UEに対する新しいセッションである時には、Target−Dialog−IDがない)、および5)メディア種類(例えば、音声、ビデオ、ファイル等)(例えば、INVITE要求に埋め込まれたSDPに含まれ得る)といった、情報を含む。要求はまた、このセッションを識別するCS呼び出しセットに使用される、PSI DNを含み得る。SDPが、ベアラがCS上で設定されることを可能にするM線を含む場合には、ステップ910では、UE−2は、B番号としてPSI DNを使用して、CS呼び出し設定メッセージを相互作用エンティティに送信する。ステップ911では、ICS用の進化型MSCサーバ等の相互作用エンティティは、呼び出し続行メッセージで応答し、CSベアラ制御信号伝達経路を設定し始める。ステップ912および913では、相互作用エンティティは、IMSエンティティを介してSCC ASに向けてSIP INVITEを送信する。SCC ASがステップ913でINVITEを受信する場合に、SCC ASは、セッション情報を回収するためにPSI DNを使用し得、ステップ916では、相互作用エンティティがIMSエンティティを介してSCC ASからSIP 200 OKを受信する場合に、相互作用エンンティティは、受信されたSIP 200 OK応答をCONNECTメッセージにマップし、それをUE−2に送信する。ステップ917では、CONNECTメッセージを受信する場合に、UE−2は、CONNECT ACKメッセージを相互作用エンティティに送信する。ステップ920では、UE−2、相互作用エンティティ、およびSCC ASは、CSベアラ制御信号伝達経路の設定を完了する。UE−2とSCC ASとの間の協調セッション制御が確立される。UE−2は、確立された協調セッションのためのコントローラUEになる。ステップ921では、UE−2とリモートパーティとの間のメディア種類(メディアA)通信の交換が確立される。この場合に、SDP情報が変更される必要があれば、それに応じて遠隔レッグが更新される。ステップ922および923では、UE−2上での協調セッション制御およびメディア種類(メディアA)の確立の成功後、SCC ASは、移転要求メッセージへの応答メッセージまたはSIP NOTIFY等を使用して移転要求メッセージの結果をUE−1に通知する別のメッセージをUE−1に送信する。最終的に、ステップ926では、UE−1上の以前のメディア種類(メディアA)セッションが解放され得、協調セッション制御が解放される。UE−1は、コントローリUEになる。上記の実施例では、従来の確認メッセージの通信を伴うステップは説明されていないことに留意されたい。UE−1からUE−2上で全てのメディアフローを移転する場合、UE−1上の既存のセッションは解放され得る。
図10は、UE−1からUE−2にコントローラ機能性およびメディアを移転するためのフローを図示し、着信セッション要求は、I1参照点上で送達され、メディアは、CSネットワークを介して伝送される。1つの実装では、MSCサーバ進化型ICSは、相互作用エンティティの例示的なエンティティであり得る。代替として、相互作用エンティティは、レガシーMSCサーバおよびMGCFから成り得る。相互作用エンティティがMSCサーバおよびMGCFに対応する場合に、CSベアラ設定手順は、TS 23.292の図7.4.2.2.2−2のステップ1011−1017に従う。
ステップ1001および1002では、UE−1は、協調セッション制御およびメディアAをUE−2に移転することを決定する。したがって、UE−1は、IMSエンティティを介して要求をSCC ASに送信し、現在の協調セッション制御およびメディアAがUE−2に移転されることを示す。1つの実装では、UE−1は、1)ソースUE(ヘッダフィールド、P−Asserted−Identityヘッダフィールド、またはP−Served−Userヘッダフィールド内に含まれ得る)、2)標的UE(Refer−Toヘッダフィールドに含まれ得る)、3)IUTコントローラ移転指示(Accept−Contactヘッダフィールド内に含まれ得、例えば、INVITE要求に埋め込まれるか、またはRefer−Toヘッダフィールドに埋め込まれる)、4)Target−Dialog(標的UEがすでに協調セッションの一部である場合に、既存のダイアログ識別子を含むTarget−Dialogヘッダフィールド内に含まれ得、これが標的UEに対する新しいセッションである時には、Target−Dialogがない)、および5)メディア種類(例えば、音声、ビデオ、ファイル等)(例えば、Refer−Toヘッダフィールドに含まれる)といった情報を用いて、SIP REFER方法等を介していそう要求を送信する。
ステップ1005では、SCC ASは、要求(例えば、SIP REFER要求)を識別する。UE−2がSCC ASにおいてSIP登録される場合、SCC ASは、UE−2がコントローラとしての役割を果たすことを許可され、かつそうすることが可能であることを検証し、UE−2が、適切な能力、例えば、RFC 3840の通りの特徴タグを登録していることを検証し、デバイス能力、ユーザ選好、および/またはネットワークの中の方針に基づいて、UE−2にどのようなベアラを使用するかを決定し、選択されたベアラがUE−2によって登録されているかどうかを決定する。UE−2がコントローラとしての役割を果たすことを許可されていない場合、SCC ASは要求を拒絶し得る。UE−2が協調セッション制御移転を拒絶する場合、拒絶を示す好適な応答、随意で拒絶の理由が送信される。
ステップ1006では、SCC ASは、UE−2がGm参照点によって到達可能ではないことを決定している。これは、例えば、UEが能動SIP登録を有さないためであり、別の実施例では、UE−2は、SIP登録され得るが、SCC ASは、Gm参照点が利用可能ではないことを、I1プロトコルを介して知らされているからである。ステップ1002で受信されたメッセージが、音声またはビデオ用のSDP線を含む場合、次いで、SCC ASは、着呼要求メッセージを生成し、I1参照点を介してUE−2に送信し、着呼要求メッセージは、IUTコントローラ機能性の指示、および、UE−2が選択されたベアラをまだ確立していない場合、USSD、SMS、MBMS、CellBroadcast、GERAN においてGPRS上で作動するIPパイプ、UTRAN、LTE、WLAN、WiMax、またはCDMA2000等であるが、それらに限定されない輸送機構を使用して、IUTコントローラ機能性の指示およびベアラ設定を確立するようにUE−2に誘起する指示を含む。
ステップ1007では、UE−2は、CS呼び出し設定メッセージを相互作用エンティティに送信し、ステップ1008では、相互作用エンティティは、呼び出し続行メッセージで応答し、CSベアラ制御信号伝達経路を設定し始める。ステップ1009および1010では、相互作用エンティティは、IMSエンティティを介してSCC ASに向けてSIP INVITEを送信する。ステップ1013では、相互作用エンティティがIMSエンティティを介してSCC ASからSIP 200 OKを受信する場合に、相互作用エンンティティは、受信されたSIP 200 OK応答をCONNECTメッセージにマップし、それをUE−2に送信する。
ステップ1014では、CONNECTメッセージを受信する場合に、UE−2は、CONNECT ACKメッセージを相互作用エンティティに送信し、ステップ1017では、UE−2、相互作用エンティティ、およびSCC ASは、CSベアラ制御信号伝達経路の設定を完了する。この場合に、UE−2とSCC ASとの間の協調セッション制御が確立される。UE−2は、確立された協調セッションのためのコントローラUEになる。
ステップ1018では、UE−2とリモートパーティとの間のメディア種類(メディアA)が確立される。この場合に、遠隔レッグがそれに応じて更新される。ステップ1019および1020では、UE−2上での協調セッション制御およびメディア種類(メディアA)の確立の成功後、SCC ASは、移転要求メッセージへの応答メッセージ、またはSIP NOTIFYメッセージ等を使用して移転要求メッセージの結果をUE−1に通知する別のメッセージをUE−1に送信する。ステップ1023では、UE−1上の以前のメディアAが解放され得、協調セッション制御が解放される。この場合に、UE−1はコントローリUEになる。上記の実施例では、従来の確認メッセージの通信を伴うステップは説明されていないことに留意されたい。UE−1からUE−2上で全てのメディアフローを移転する場合、UE−1上の既存のセッションは解放され得る。
上記の実施例は、的確なコントローラ対応UEへのIUTコントローラ機能またはメディアの移転の成功をもたらすフローを説明する。しかしながら、移転が成功しなかった場合、システムは、なぜ移転が失敗したのかという説明を提供する、種々のメッセージ応答理由コードまたは指示を要求UEに送信し得る。応答理由コードまたは指示例は、IUTコントローラ能力がないこと(よって、そのUEによって、コントローラの状態の正当な要求を行うことができない)、セッションのためのIUTコントローラUEがすでにあること(例えば、単一のUEのみがIUTコントローラであり得る場合)、UEが同じサブスクリプションの下にないこと、IUTコントローラの最大限度、利用不可能(登録されていない、バッテリがない等)、IUTコントローラとなる権限が与えられていない、サポートされていないメディア種類、サポートされていないメディア形式、同時セッションの最大数に達していないため、新規セッションを確立することが許可されていない、使用中である等を含む。応答理由コードまたは指示は、応答に含まれるSIP Warningヘッダ内に含まれ得る。場合によっては、拒絶応答および関連理由コードまたは指示は、SCC ASまたは他のネットワークノードにおいて受信される応答メッセージのSIPfrag包含部分内等のSIP NOTIFY要求の本文に含まれ得る。
本システムの動作中、IUTコントローラUEは、特定のUEまたはユーザと関連付けられた全てのUE上の進行中のセッションを説明する、通知を受信するように登録し得る。通知は、種々の進行中のセッション、ならびにそれらの関連コントローリおよび/またはコントローラUEを識別し得る。一実施例では、ユーザAが2つのセッションを開始しており、1つはユーザCおよびユーザDとのセッション、もう1つはユーザBとのセッションである。ユーザCおよびDとのセッションを参照すると、ユーザAは、自分のIUTコントローラUEセットに対する3つのセッションを有する(すなわち、デバイス1、2、および3)。ユーザBとの会話のために、ユーザAは、自分のIUT UEセット上に2つのセッションを有する(すなわち、デバイス2および3)。この実施例では、ユーザAは、ユーザのIUT UEと関連付けられた現在進行中のセッションを説明する、情報を知ることを希望し得る。その場合、ユーザAは、要求(例えば、SIP SUBSCRIBE)を送信し得、RFC 4235で説明されているようなダイアログイベントパッケージを使用して、Target−Dialogごとに以下の情報セットをともなう応答(例えば、SIP NOTIFY)を得る。
−Target−Dialog
−参加ユーザのID(SIP URI、TEL URI、またはニックネーム)
−IUTデバイスID/ニックネーム
−IUTコントローラデバイスID/ニックネーム
−セッションごとのメディア種類またはファイル(すなわち、特定の協調セッションのためのユーザAのデバイス上に3つの異なるセッションがあるという通知)。
図11に示された実施例で図示されるように、複数のUEが、全ての進行中のセッションのためにユーザAに存在し得る。ユーザAのデバイス60は、ユーザCのデバイス68または70との通信を伴う協調セッションXに対する移転要求をユーザAのデバイス64に発行しており、ユーザAのデバイス62は、ユーザBのデバイス66との通信を伴う協調セッションYに対する移転要求をユーザAのデバイス64に送信している。新規メディア種類の新規招待がユーザAのデバイス62上で受信された場合、新規招待をユーザAのデバイス64に移転するために、ユーザAのデバイス60を使用して、メディア移転要求またはリダイレクト要求を送信することが可能である。メディア移転要求またはリダイレクト要求の受諾が成功した場合、成功通知が、ユーザAのデバイス60および62である、セッションのためのコントローラUEまたは全てのIUTコントローラUEに移転される。ユーザ選好およびデバイス能力に応じて、ユーザは、全てのコントローラUE上で通知を受信するか、または全てのコントローラUEへの通知を受信するよりもむしろ、複数のコントローラUEの中で、どのコントローラUEが通知を受信するかを割り当てるように構成し得る。図11に示されるように、複数のUEがユーザAに存在する場合、1つだけのIUTコントローラUEが各協調セッションに存在する。そのようなものとして、特定の協調セッションのためのコントローラUEのみが、セッション状態がその特定の協調セッション上で変化した時に通知を受信する。
いくつかの実装では、任意のコントローラUEに伝送されるのに適格である、相当量の通知トラフィックがあり得る。フィルタリング機構は、制御UEに伝送されている通知トラフィックの量を最適化するように、ネットワークおよび/または各個別UE上の通知機構内で実装され得る。
セッションを終了するために、本システムの1つの実装では、最初にセッション確立の要求を受信し、セッション確立要求を受け入れることができるどんなUEにも、コントローラ機能が割り当てられ得る(そうでなければ、セッションを受け入れたUEがセッション上にとどまり、移転要求をユーザの別のUEに送信する能力を持たない)。リモートパーティから最初のセッション確立要求(例えば、SIP INVITE、SIP re−INVITE、またはSIP UPDATE)を受信すると、ネットワークは、コントローラである、および/またはコントローラ機能をサポートするUEに要求が送られることを確実にする必要があり得る。セッションが確立されると、終端ユーザは、協調セッション制御を同じユーザの別のUEに移転することを望み得る。標的UEがIUTコントローラ能力を持たず、IUTコントローラ UEではない場合には、標的UEは、他のUEへの移転要求を行うことができない。しかしながら、場合によっては、移転は、依然として行われ得る。例えば、UEは、ユーザがネットワーク上でリダイレクト設定を提供することを可能にし得、すなわち、招待要求が終端側に到達する場合に、ユーザによって割り当てられたコントローラUE等の特定のUEに要求をリダイレクトすることを可能にし得る。加えて、UEは、ユーザがユーザ選好を設定することを可能にして、おそらくメディア種類およびデバイス能力の組み合わせとして、セッション確立にどのベアラを使用すべきかを示し得る。例えば、2つのUEを有するユーザは、UE−1上の発話種類セッションにパケット交換ベアラを使用するように、およびUE−2上のビデオ種類セッションに回路交換ベアラを使用するように、ユーザ選好を設定し得る。
代替として、リダイレクト設定がない場合、終端ネットワークが招待要求を受信した場合、ネットワークは、UE上で招待を受諾するか、または別のUE(すなわち、コントローラUE)にリダイレクトするかをユーザに尋ねる要求を送信する。ユーザが別のUE(コントローラUEである)にリダイレクトすることを決定した場合には、ネットワークは、移転されるUE識別を含む応答を終端ネットワークに送信し、終端ネットワークは、招待要求をユーザによって割り当てられたUEに送信する。
代替として、リダイレクト設定がない場合、終端ネットワークが招待要求を受信した場合、UEは、招待を受諾するか、または別のUEにリダイレクトするかをユーザに尋ねる。ユーザが別のUE(すなわち、コントローラUE)にリダイレクトすることを決定した場合には、ネットワークは、リダイレクト要求を終端ネットワークに送信する。その場合、終端ネットワークは、招待要求をユーザによって割り当てられたUEに送信する。終端ネットワークが(例えば、SCC ASを介して)招待メッセージ(例えば、SIP INVITE、SIP re−INVITE、またはSIP UPDATE)を受信すると、終端ネットワークは、デバイス能力、ユーザ選好および/または方針、および終端UEにどのベアラを使用するかに基づいて、どの終端UEがIUTコントローラになるかを決定する。ネットワークは、終端UEが識別されたベアラに登録しているかどうかをチェックする。そうでなければ、ネットワークは、ベアラ登録を開始するように、指示を終端UEに送信し得る。ベアラ登録の成功後、ネットワークは、セッション制御およびあるメディア種類が標的終端UEに提示されることを示す、招待要求メッセージ(例えば、SIP INVITE)を(例えば、SCC ASを介して)送信する。AckまたはOK応答メッセージを受信すると、SCC ASは、メディアストリームが異なるUEにリダイレクトされているという指示をリモートパーティに送信し得る。
図12aおよび12bは、リモートパーティがセッション招待要求を送信した時に協調セッション確立を終了するためのフロー例を図示する。1つの実装では、MSCサーバ進化型ICSは、相互作用エンティティの例示的なエンティティであり得る。代替として、相互作用エンティティは、レガシーMSCサーバおよびMGCFから成り得る。フロー例は、UE−1が、IUTコントローラであるため、およびビデオ種類を用いたセッション確立にPSベアラを使用するために、デバイス能力/ユーザ選好を設定していることを仮定する。UE−2は、発話メディア種類を用いたセッション確立にCSベアラを使用するために、デバイス能力/ユーザ選好を設定している。図12aは、以下のような高レベルフローを示す。ステップ1101では、終端ネットワーク(例えば、SCC AS)が、招待メッセージ(例えば、SIP INVITEまたはSIP re−INVITE)を受信する。ステップ1102では、SCC ASは、デバイス能力、ユーザ選好および/または方針に基づいて、どの終端UEがIUTコントローラになるか、ならびに、デバイス能力、ユーザ選好および/または方針に基づいて、終端UEにどのベアラを使用するかを決定する。実施例では、SCC ASは、UE−1がIUTコントローラとしての役割を果たし、ビデオメディア種類とともにPSベアラを使用する一方で、UE−2が発話メディア種類とともにCSベアラを使用することを決定する。ステップ1103および1104では、SCC ASは、UE−2に向けた協調セッションを確立するために、IMSを介して招待要求メッセージ(例えば、SIP INVITE)を相互作用エンティティに送信する。ステップ1105では、相互作用エンティティは、CS呼び出し設定メッセージをUE−2に送信する。ステップ1106では、UE−2、相互作用エンティティ、およびSCC ASは、CSベアラ制御信号伝達経路の設定を完了し、SCC ASおよびリモートパーティは、遠隔レッグ確立を完了する。UE−2とSCC ASとの間の発話メディア種類を用いた協調セッション制御が確立され、SCC ASとリモートパーティの間の遠隔レッグが確立される。
ステップ1107および1108では、SCC ASは、IMSを介して招待要求メッセージ(例えば、SIP INVITE)をUE−1に送信する。ステップ1109では、UE−1とSCC ASとリモートパーティの間のビデオメディア種類を用いた協調セッション制御が確立され、SCC ASとリモートパーティの間の遠隔レッグが更新される。UE−1は、IUT移転要求を適用することを可能にする、協調セッション制御を得る。
図12aに図示されたステップでは、1つの実装において、UE−1およびUE−2が同じ加入者(すなわち、同じサブスクリプションセット)に属し、SCC ASが、UE−2上のCSネットワーク上で、および協調セッション制御を保持するUE−1上のPSネットワーク上で、協調セッションを確立すると決定すると仮定される。場合によっては、相互作用エンティティがMSCサーバおよびMGCFに対応する場合に、CSベアラ設定手順は、TS 23.292の図7.4.2.2.2−2のステップ11−17に従う。
図12bは、以下のように図12aよりも詳細なフローを図示する。ステップ1201では、終端ネットワーク(例えば、SCC AS)は、招待メッセージ(例えば、SIP INVITEまたはSIP re−INVITE)を受信する。ステップ1202では、SCC ASは、デバイス能力、ユーザ選好および/または方針に基づいて、どの終端UEがIUTコントローラになるか、ならびに、デバイス能力、ユーザ選好および/または方針に基づいて、終端UEにどのベアラを使用するかを決定する。実施例では、SCC ASは、UE−1がIUTコントローラとしての役割を果たし、ビデオメディア種類とともにPSベアラを使用する一方で、UE−2が発話メディア種類とともにCSベアラを使用することを決定する。ステップ1203および1204では、SCC ASは、UE−2に向けた協調セッションを確立するために、IMSを介して招待要求メッセージ(例えば、SIP INVITE)を相互作用エンティティに送信する。ステップ1205および1206では、相互作用エンティティは、CS呼び出し設定メッセージをUE−2に送信し、CS呼び出し接続メッセージを受信する。ステップ1207から1209では、SIP 200 OK応答メッセージが、IMSエンティティおよびSCC ASを介してリモートパーティに送信される。リモートパーティは、ステップ1210から1212で、相互作用エンティティに向けてSIP ACKを送信し、相互作用エンティティは、CONNECT応答メッセージをUE−2に送信する。ステップ1214では、UE−2とリモートパーティの間の発話メディア種類を用いたセッション制御が確立される。
ステップ1215から1217では、SCC ASは、ビデオメディア種類を用いたセッションを確立するように、招待要求メッセージ(例えば、SIP INVITE)を終端UE−1に送信する。この時点で、SCC ASを用いた協調セッション制御が確立され、終端UE−1がIUTコントローラになる。ステップ1218から1220で示されるように、相互作用エンティティおよびIMSエンティティを介してUE−2からSIP 200 OK応答を受信すると、SCC ASは、ステップ1221で遠隔レッグを更新するように、SIP UPDATEをリモートパーティに送信する。ステップ1222から1225におけるSIP応答の成功後、ステップ1226では、UE−1とSCC ASとの間のビデオメディア種類を用いたセッション制御が確立される。SCC ASとリモートパーティとの間の遠隔レッグが更新される。上記の実施例では、従来の確認メッセージの通信を伴うステップは完全には説明されていないことに留意されたい。
図13は、PS UE−1からPS UE−2にIUTコントローラ機能性を移転するためのフロー例を図示する。UE−1およびUE−2は、同じベアラまたは異なるベアラを使用し得る。たとえUE−1およびUE−2上でパケット交換ベアラを使用しても、UE−1上で3GPP IP−CANを、UE−2上で非3GPP IP−CANを使用することが可能であり得る。ステップ1301および1302では、UE1は、協調セッション制御およびメディアAをUE2に移転することを決定する。したがって、UE−1は、IMSエンティティを介して要求をSCC ASに送信し、現在のサービス制御およびメディア種類(メディアA)がUE2に送信されることを示す。ステップ1305では、SCC ASは、要求、例えば、SIP REFER要求を識別し、UE−2がコントローラとしての役割を果たすことを許可され、かつそうすることが可能であることを検証し、デバイス能力、ユーザ選好、および/またはネットワークの中の方針に基づいて、UE−2に使用されるPSベアラを決定する。
ステップ1306および1307では、SCC ASは、協調セッション制御およびメディア種類(メディアA)を示す、SIP INVITE要求(またはSIP re−INVITE)等のセッション確立要求メッセージを生成し、送信する。セッション確立要求は、上で説明されるAccept−Contactヘッダの中のフロー識別子メディア特徴タグを使用して、所望のアクセスレッグ(ベアラ)上で送ることができる。ステップ1312では、UE2とSCC ASとの間の協調セッション制御が確立される。UE 2は、確立された協調セッションのためのコントローラUEになる。ステップ1313では、UE2とリモートパーティとの間のメディア種類(メディアA)通信が確立される。遠隔レッグは、それに応じて更新される。ステップ1314および1315では、UE−2上での協調セッション制御およびメディア種類(メディアA)の確立の成功後、SCC ASは、移転要求メッセージへの応答メッセージまたはSIP NOTIFYメッセージ等の移転要求メッセージの結果を通知するメッセージをUE−1に送信する。ステップ1318では、UE−1上の以前のメディア種類(メディアA)および協調セッション制御が解放され得る。UE−1は、コントローリUEになる。上記の実施例では、従来の確認メッセージの通信を伴うステップは説明されていないことに留意されたい。
本システムおよび方法は、IUTコントローラ移転アプリケーションを提供するために使用され得る。本システムによって実装される方法例は、IUTコントローラ機能を果たせること、およびIUTコントローラ機能を果たせないことの少なくとも1つを示す。方法は、セッション初期化プロトコル(Session Initiation Protocol/SIP)メッセージにおいて、IUT:コントローラ機能をサポートできるという指示を提供するステップと、セッション初期化プロトコル(SIP)メッセージにおいて、IUT:コントローラ機能をサポートできないという指示を提供するステップとを含む。IUTコントローラ機能を果たせること、およびIUT:コントローラ機能をサポートできないことの少なくとも1つの指示は、メディア特徴タグを使用して示され得る。メディア特徴タグは、IUTコントローラとしての役割を果たすことができ、協調セッションのためのIUTコントローラとしての役割を現在果たしていることを示す「Active(能動)」、IUTコントローラとしての役割を果たすことができるが、協調セッションのためのIUTコントローラとしての役割を現在果たしていないことを示す「Inactive(非能動)」、および協調セッションのためのIUTコントローラとしての役割を果たすことができないことを示す「Passive(受動)」といった値のうちの少なくとも1つを示し得る。
実装に応じて、メディア特徴タグは、Contactヘッダ内に含まれ得る。セッション初期化プロトコル(Session Initiation Protocol/SIP)メッセージは、SIP REGISTER要求、SIP INVITE要求、SIP Re−INVITE要求、SIP UPDATE要求、SIP PRACK要求、SIP REFER要求、SIP PUBLISH要求、SIP MESSAGE要求、SIP SUBSCRIBE要求、SIP NOTIFY要求、SIP OPTIONS要求、およびSIP INFO要求のうちの1つを含み得る。
1つのデバイスから別のデバイスにIUTコントローラ機能を移転する方法例は、セッション初期化プロトコル(Session Initiation Protocol/SIP)メッセージにおいて、IUT:コントローラ機能の移転の指示を提供するステップを含み得る。IUT:コントローラ機能の移転の指示は、メディア特徴タグを使用して示され得る。メディア特徴タグは、Accept−Contactヘッダに含まれ得る。セッション初期化プロトコル(Session Initiation Protocol/SIP)メッセージは、SIP INVITE要求、SIP Re−INVITE要求、SIP UPDATE要求、SIP PRACK要求、SIP REFER要求、SIP PUBLISH要求、SIP MESSAGE要求、SIP SUBSCRIBE要求、SIP NOTIFY要求、SIP OPTIONS要求、およびSIP INFO要求のうちの1つを含み得る。メディア特徴タグは、それ自体がRefer−Toヘッダ内に含まれる、Accept−Contactヘッダに含まれ得る。
方法は、それに応じて、Successful IUT Transfer(IUT移転の成功)またはUnsuccessful IUT Transfer(IUT移転の不成功)のうちの1つの指示を受信するステップを含み得る。指示は、SIP応答、SIP UPDATE要求、SIP PRACK要求、SIP NOTIFY要求、SIP PUBLISH要求、SIP MESSAGE要求、SIP OPTIONS要求、またはSIP INFO要求を含み得る。代替として、指示は、Contactヘッダの中にある、SIP要求またはSIP応答の本文内にある、SIP要求またはSIP応答の本文中のSIPfrag内にある、またはXML形式で符号化される、メディア特徴タグのうちの1つであり得る。
代替として、方法は、1つの付着点から別の付着点にIUTコントローラ機能を移転するステップを提供し得る。付着点技術は、IEEE−802.11、IEEE−802.11a、IEEE−802.11b、IEEE−802.11g、IEEE−802.11n、3GPP−GERAN、3GPP−UTRAN−FDD、3GPP−UTRAN−TDD、3GPP−E−UTRAN−FDD、3GPP−E−UTRAN−TDD、ADSL、ADSL2、ADSL2+、RADSL、SDSL、HDSL、HDSL2、G.SHDSL、VDSL、IDSL、3GPP2−1X、3GPP2−1X−HRPD、3GPP2−UMB、DOCSIS、IEEE−802.3、IEEE−802.3a、IEEE−802.3e、IEEE−802.3i、IEEE−802.3j、IEEE−802.3u、IEEE−802.3ab、IEEE−802.3ae、IEEE−802.3ak、IEEE−802.3aq、IEEE−802.3an、IEEE−802.3y、IEEE−802.3z、IEEE−802.3y、3GPP−GERAN、3GPP−UTRAN、3GPP−E−UTRAN、3GPP−WLAN、3GPP−GAN、または3GPP−HSPAを含み得る。しかしながら、場合によっては、他のアクセス技術、クラス、または種類が採用され得る。
1つのデバイスから別のデバイスにIUTコントローラ機能を移転する別の方法例は、セッション初期化プロトコル(Session Initiation Protocol/SIP)メッセージにおいて、IUT:コントローラ機能の移転の指示を受信するステップを含む。IUT:コントローラ機能の移転の指示は、メディア特徴タグを使用して示され得る。メディア特徴タグは、Accept−Contactヘッダに含まれ得る。セッション初期化プロトコル(Session Initiation Protocol/SIP)メッセージは、SIP INVITE要求、SIP Re−INVITE要求、SIP UPDATE要求、SIP PRACK要求、SIP REFER要求、SIP PUBLISH要求、SIP MESSAGE要求、SIP SUBSCRIBE要求、SIP NOTIFY要求、SIP OPTIONS要求、およびSIP INFO要求のうちの1つ以上を含み得る。メディア特徴タグは、それ自体がRefer−Toヘッダ内に含まれる、Accept−Contactヘッダに含まれ得る。方法は、それに応じて、Successful IUT Transfer(IUT移転の成功)またはUnsuccessful IUT Transfer(IUT移転の不成功)のうちの1つの指示を送信するステップを含み得る。指示は、SIP応答、SIP UPDATE要求、SIP PRACK要求、SIP NOTIFY要求、SIP PUBLISH要求、SIP MESSAGE要求、SIP OPTIONS要求、またはSIP INFO要求のうちの1つに含まれ得る。指示は、Contactヘッダの中にある、SIP要求またはSIP応答の本文内にある、SIP要求またはSIP応答の本文中のSIPfrag内にある、またはXML形式で符号化される、メディア特徴タグのうちの1つであり得る。方法は、協調セッションのための能動IUTコントローラ機能を果たすステップを含み得る。
本システムはさらに、特定のアクセスアプリケーション上でSIP REQUESTを方向付けるように構成され得る。アクセスネットワーク上で登録フローを識別する方法例は、セッション初期化プロトコル(Session Initiation Protocol/SIP)REGISTER要求のP−Access−Network−Infoヘッダにおいて、REGISTER要求が輸送されるアクセスネットワークのアクセス種類を識別する、識別子を提供するステップと、セッション初期化プロトコル(SIP)REGISTER要求のContactヘッダにおいて、同じデバイスによる他の登録全体にわたり登録フローを一意的に識別する、メディア特徴タグを提供するステップとを含む。メディア特徴タグは、SIP REGISTER要求に含まれる「reg−id」contactヘッダパラメータから導出される値を含み得る。メディア特徴タグは、テキスト文字列である値を含み得る。メディア特徴タグは、ユーザによって入力されるテキスト文字列である値を含む。アクセスネットワーク上で登録フローを識別する方法例は、セッション初期化プロトコル(Session Initiation Protocol/SIP)REGISTER要求のP−Access−Network−Infoヘッダから、REGISTER要求が輸送されるアクセスネットワークのアクセス種類を識別する、識別子を取得するステップと、セッション初期化プロトコル(SIP)REGISTER要求のContactヘッダから、同じデバイスによる他の登録全体にわたり登録フローを一意的に識別する、メディア特徴タグを取得するステップと、アクセス種類またはアクセスクラスを、メディア特徴タグからの値と関連付けるステップとを含む。セッション初期化プロトコル(SIP)REGISTER要求のコンテンツは、受信された第3者REGISTER要求の本文、受信された第3者REGISTER要求の中のP−Access−Network−Infoヘッダ、およびSIP NOTIFY要求の本文内の登録イベントパッケージのうちの少なくとも1つを使用して、取得され得る。方法は、SIP要求を受信するか、またはSIP要求を生成するステップと、SIP要求が、アクセス種類またはアクセスクラス値によって識別される特定のアクセスレッグ上で送られるべきことを決定するステップと、アクセス種類またはアクセスクラス値と関連付けられたメディア特徴タグ値を回収するステップと、Accept−ContactヘッダのSIP要求の中に、回収されたメディア特徴タグ値を含むステップとを含み得る。SIP要求は、SIP INVITE要求、SIP Re−INVITE要求、SIP UPDATE要求、SIP PRACK要求、SIP REFER要求、SIP PUBLISH要求、SIP MESSAGE要求、SIP SUBSCRIBE要求、SIP OPTIONS要求、およびSIP INFO要求のうちの1つであり得る。
要求が送信されるアクセスネットワーク上で登録フローを識別する方法例は、SIP要求のAccept−Contactヘッダにおいて、デバイスの登録フローを一意的に識別する値を含む、メディア特徴タグを提供するステップを含む。メディア特徴タグは、テキスト文字列である値を含み得る。メディア特徴タグは、ユーザによって入力されるテキスト文字列である値を含み得る。SIP要求は、SIP INVITE要求、SIP Re−INVITE要求、SIP UPDATE要求、SIP PRACK要求、SIP REFER要求、SIP PUBLISH要求、SIP MESSAGE要求、SIP SUBSCRIBE要求、SIP OPTIONS要求、およびSIP INFO要求のうちの1つであり得る。メディア特徴タグは、それ自体がRefer−Toヘッダ内に含まれる、Accept−Contactヘッダに含まれ得る。
図14は、Gm参照点を使用した、協調セッション内の別のUEへのメディア/コントローラ機能性移転のための代替メッセージフローの説明図である。図14に図示されたメッセージフローは、UE−1からUE−2にメディアおよびIUTコントローラ機能性を移転する方法例を示し、着信セッションは、Gm参照点上で送達され、メディアは、CSネットワークを介して確立される。実施例では、UE−1およびUE−2が同じ加入者(すなわち、同じサブスクリプションセット)に属し、相互作用エンティティがICS用のMSC進化型に対応し、TS 23.292に示されている、Gm参照点を使用するCSメディアを用いた終了手順に従うことが仮定される。この実施例では、相互作用エンティティがMSCサーバおよびMGCFに対応する場合に、CSベアラ設定手順は、TS 23.292の図7.4.2.2.2−2のステップ11−17に従い得る。
図14を参照すると、ステップ1401では、UE1は、メディアAおよび協調セッション制御をUE2に移転することを決定し、現在の協調セッション制御およびメディアAがUE−2に移転されることを示す、移転要求をIMSエンティティに送信する。ステップ1402では、IMSエンティティは、移転要求をSCC ASに転送し、ステップ1403では、SCC ASは、移転要求を識別し、UE−2がコントローラとしての役割を果たすことを許可され、かつそうすることが可能であることを検証し、UE−2の能力、ユーザ選好、および/またはネットワークの中の方針に基づいて、T−ADSを行い、メディアAの設定のためのCSドメインを選択する。UE−2がコントローラとしての役割を果たすことを許可されていないか、または移転要求をうまく行うことができない場合、SCC ASは、理由とともに要求を拒絶し、以下のステップ後に停止する。
依然として図14を参照すると、ステップ1404では、SCC ASは、メディアAおよび協調セッション制御と、TS 23.292で示されるようなCSベアラ確立手順を開始するUE−2とを示す、INVITE要求を生成し、IMSエンティティに送信する。ステップ1405では、IMSエンティティは、受信されたINVITE要求をUE−2に転送し、ステップ1406では、UE−2は、CS呼び出し設定メッセージを相互作用エンティティに送信する。ステップ1407では、相互作用エンティティは、呼び出し続行メッセージで応答し、CSベアラ制御信号伝達経路を設定し始め、ステップ1408および1409では、相互作用エンティティは、IMSエンティティを介してSCC ASに向けてINVITEを送信する。ステップ1410では、UE−2、相互作用エンティティ、およびSCC ASは、CSベアラ制御信号伝達経路の設定を完了する。UE−2とSCC ASとの間の協調セッション制御が確立される。UE−2は、確立された協調セッションのためのコントローラUEになる。ステップ1411では、UE−2とリモートパーティとの間のメディアAが確立される。遠隔レッグが、それに応じて更新される。ステップ1412では、UE−2上での協調セッション制御およびメディアAの確立の成功後、SCC ASは、IUT移転結果メッセージをIMSエンティティに送信し、ステップ1413では、IMSエンティティは、IUT移転結果メッセージをUE−1に転送する。最終的に、ステップ1414では、以前のメディアAおよび協調セッション制御が解放される。UE1はコントローリUEになる。
図15は、I1参照点を使用した、協調セッション内の別のUEへのメディア/コントローラ機能性移転のための代替メッセージフローの説明図である。図15に図示されたメッセージフローは、UE−1からUE−2にIUTコントローラ機能性を移転する方法例を示し、着信セッションは、I1参照点上で送達され、メディアは、CSネットワークを介して確立される。実施例では、UE−1およびUE−2が同じ加入者(すなわち、同じサブスクリプションセット)に属し、相互作用エンティティがICS用のMSC進化型に対応し、TS 23.292に示されている、I1参照点を使用するCSメディアを用いた終了手順に従うことが仮定される。この実施例では、相互作用エンティティがMSCサーバおよびMGCFに対応する場合に、CSベアラ設定手順は、TS 23.292の図7.4.2.2.2−2のステップ11−17に従い得る。
図15を参照すると、ステップ1501では、UE1は、メディアAおよび協調セッション制御をUE2に移転することを決定し、現在の協調セッション制御およびメディアAがUE−2に移転されることを示す、移転要求をIMSエンティティに送信する。ステップ1502では、IMSエンティティは、移転要求をSCC ASに転送し、ステップ1503では、SCC ASは、移転要求を識別し、UE−2がコントローラとしての役割を果たすことを許可され、かつそうすることが可能であることを検証し、UE−2の能力、ユーザ選好、および/またはネットワークの中の方針に基づいて、T−ADSを行い、メディアAの設定のためのCSドメインを選択する。UE−2がコントローラとしての役割を果たすことを許可されていないか、または移転要求をうまく行うことができない場合、SCC ASは、理由とともに要求を拒絶し、以下のステップ後に停止する。ステップ1504では、SCC ASは、CSベアラ確立手順を開始するUE−2と、TS 23.292で示されるようにUE−2に移転される協調セッション制御およびメディアAおよびとを示す、着呼要求を生成し、I1参照点を介してUE−2に送信する。
依然として図15を参照すると、ステップ1505では、UE−2は、CS呼び出し設定メッセージを相互作用エンティティに送信し、ステップ1506では、相互作用エンティティは、呼び出し続行メッセージで応答し、CSベアラ制御信号伝達経路を設定し始める。ステップ1507および1508では、相互作用エンティティは、IMSエンティティを介してSCC ASに向けてINVITEを送信し、ステップ1509では、UE−2、相互作用エンティティ、およびSCC ASは、CSベアラ制御信号伝達経路の設定を完了する。UE−2とSCC ASとの間の協調セッション制御が確立される。UE−2は、確立された協調セッションのためのコントローラUEになる。ステップ1510では、UE−2とリモートパーティとの間のメディアAが確立される。遠隔レッグが、それに応じて更新される。ステップ1511では、UE−2上での協調セッション制御およびメディアAの確立の成功後、SCC ASは、IUT移転結果メッセージをIMSエンティティに送信する。ステップ1512では、IMSエンティティは、IUT移転結果メッセージをUE−1に転送し、ステップ1513では、以前のメディアAおよび協調セッション制御が解放される。UE1はコントローリUEになる。
図16は、コントローラが開始した進行中セッション情報移転のための代替メッセージフローの説明図である。図16に示された実施例では、UE−1、UE−2、およびUE−3は、同じユーザサブスクリプションの下にあり得る。UE−2とリモートパーティとの間のメディアAを用いた1つのセッション、およびUE−3とリモートパーティとの間のメディアBを用いた別のセッションがある。図16は、ユーザのIUT UEに対する全ての進行中セッション状態情報を要求する、UE−1の情報フローを提示する。
図16を参照すると、ステップ1601では、UE−1は、ユーザのIUT UEに対する進行中セッション状態情報についての要求をSCC ASに送信する。要求は、どのような情報が応答の中で取得されるかを含み得る。情報は、ユーザのIUT UEに対する進行中のセッション、進行中のセッションあたりのメディア種類、および/または進行中のセッションあたりのソースUEおよび標的UEを含み得る。ステップ1602では、SCC ASは、ユーザのIUT UEに対する全ての進行中のセッションをチェックし、要求された情報をフィルタにかけ、すなわち、UE−2とリモートパーティとの間のメディアAを用いた1つのセッションA、およびUE−3とリモートパーティとの間のメディアBを用いた別のセッションBがある。ステップ1603では、SCC ASは、UE−2およびUE−3上の進行中セッション状態情報についての応答をUE−1に送信する。
SCC ASが終端ICS UEに役立ち、初期フィルタ基準による初期SIP INVITE要求を受信し、T−ADSがPSドメイン中でメディアを送達することを選択する結果となる、本システムの実装では、SCC ASは、B2BUAとしての役割を果たすことができる。複数の連絡先がPSドメインで登録され、T−ADSが異なるIP−CANを使用して異なるメディア種類を確立することを選択する場合、SCC ASは、それぞれの選択されたPSドメインIP−CANについて、3GPP TS24.229に従ってSIP INVITE要求を作成することができる。SIP INVITE要求は、i)選択されたPSドメインIP−CANのアクセス種類またはアクセスクラスと登録時に関連付けられた値を含む、メディア特徴タグg.3gpp.icsflowと、パラメータ「require」および「explicit」とともに値「principal」を含む、メディア特徴タグg.3gpp.icsとを含むAccept−Contactヘッダ、およびii)このセッションのための既存のレッグがすでに存在するか、または異なるIP−CANを使用してSCC ASとICS UEとの間で確立されている過程にある場合、SCC ASとICS UEとの間のその既存のダイアログに対するダイアログパラメータを含む、Target−Dialogヘッダ(SCC ASは、ICS UEが同じセッションの一部として異なる要求を相関させることができるように、SIP INVITE要求にTarget−Dialogヘッダを含み得る)、およびiii)このIP−CANを使用して確立されるように選択される、メディア種類に対するSDPを含み得る。
複数の連絡先がPSドメインで登録され、T−ADSが同じIP−CAN上で全てのメディア種類を確立することを選択する場合、SCC ASは、3GPP TS24.229に従ってSIP INVITE要求を作成し得、要求の中に、i)選択されたPSドメインIP−CANのアクセス種類またはアクセスクラスと登録時に関連付けられた値を含む、メディア特徴タグg.3gpp.icsflowと、パラメータ「require」および「explicit」とともに値「principal」を含む、メディア特徴タグg.3gpp.icsとを含むAccept−Contactヘッダ、ii)このセッションのための既存のレッグがすでに存在するか、または異なるIP−CANを使用してSCC ASとICS UEとの間で確立されている過程にある場合、SCC ASとICS UEとの間のその既存のダイアログに対するダイアログパラメータを含む、Target−Dialogヘッダ(SCC ASは、ICS UEが同じセッションの一部として異なる要求を相関させることができるように、SIP INVITE要求にTarget−Dialogヘッダを含み得る)、およびiii)初期SIP INVITE要求に含まれる全てのメディア種類に対するSDPを含み得る。
単一の連絡先のみがPSドメインで登録される場合、SCC ASは、3GPP TS24.229に従ってSIP INVITE要求を作成し得、要求の中に、i)パラメータ「require」および「explicit」とともに値「principal」を含む、メディア特徴タグg.3gpp.icsを含むAccept−Contactヘッダ、およびii)初期SIP INVITE要求に含まれる全てのメディア種類に対するSDPを含み得る。
ここで図17を参照すると、例示的なUE1700の実施形態を含む、無線通信システムが図示されている。UEは、本開示の側面を実装するために動作可能であるが、本開示は、これらの実装に限定されるべきではない。携帯電話として図示されているが、UEは、無線ハンドセット、ポケットベル、携帯用情報端末(PDA)、携帯用コンピュータ、タブレットコンピュータ、ラップトップコンピュータ、スマートフォン、プリンタ、ファクス機、テレビ、セットトップボックス、および他のビデオ表示デバイス、家庭用音響機器および他の家庭用娯楽システム、家庭用監視および制御システム(例えば、家庭監視、アラームシステム、および気候制御システム)、およびコンピュータ化された冷蔵庫等の進化型家庭用電化製品を含む、種々の形態を成し得る。多くの好適なデバイスは、これらの機能のうちのいくつかはまた全てを組み合わせる。本開示のいくつかの実施形態では、UE1700は、携帯用、ラップトップ、またはタブレットコンピュータのような汎用コンピュータデバイスではないが、むしろ、携帯電話、無線ハンドセット、ポケットベル、PDA、または車載電気通信デバイス等の特殊用途通信デバイスである。UE1700はまた、デバイスであり得、デバイスを含み得、または、同様の機能を有するが、デスクトップコンピュータ、セットトップボックスまたはネットワークノード等の運搬可能ではないデバイスに含まれ得る。UE1700は、ゲーム、在庫管理、ジョブ制御、および/またはタスク管理機能等の、特殊活動をサポートし得る。
UE1700は、ディスプレイ702を含む。UE1700はまた、ユーザによる入力のために、概して704と呼ばれる、タッチセンサ式表面、キーボード、または他の入力キーも含む。キーボードは、QWERTY、Dvorak、AZERTY、および逐次タイプ等の、完全または縮小英数字キーボード、または電話キーパッドと関連するアルファベット文字を伴う従来の数字キーパッドであり得る。入力キーは、さらなる入力機能を提供するように内向きに押下され得る、トラックホイール、終了またはエスケープキー、トラックボール、および他のナビゲーションまたは機能キーを含み得る。UE1700は、ユーザが選択するためのオプション、ユーザが作動させるための制御、および/またはユーザが指図するためのカーソルあるいは他の指標を提示し得る。
UE1700はさらに、ダイヤルする番号、またはUE1700の動作を構成するための種々のパラメータ値を含む、ユーザからのデータ入力を受け取り得る。UE1700はさらに、ユーザコマンドに応じて、1つ以上のソフトウェアまたはファームウェアアプリケーションを実行し得る。これらのアプリケーションは、ユーザ相互作用に応じて種々のカスタマイズされた機能を果たすようにUE1700を構成し得る。加えて、UE1700は、例えば、無線基地局、無線アクセスポイント、またはピアUE1700から、無線でプログラムおよび/または構成され得る。
UE1700によって実行可能な種々のアプリケーションの中には、ディスプレイ702がウェブページを表示することを可能にするウェブブラウザがある。ウェブページは、無線ネットワークアクセスノード、携帯電話の基地局、ピアUE1700、または任意の他の無線通信ネットワークあるいはシステム1702との無線通信を介して、取得され得る。ネットワーク1702は、インターネット等の有線ネットワーク1704に連結される。無線リンクおよび有線ネットワークを介して、UE1700は、サーバ1706等の種々のサーバ上の情報にアクセスできる。サーバ1706は、ディスプレイ702上に示され得る、コンテンツを提供し得る。代替として、UE1700は、中継型またはホップ型の接続において、中間物としての役割果たすピアUE1700を通してネットワーク1702にアクセスし得る。
図18は、UE1700のブロック図を示す。UA1700の種々の既知の構成要素が描写されているが、実施形態では、記載された構成要素の一部および/または記載されていない追加の構成要素が、UE1700に含まれ得る。UE1700は、デジタル信号プロセッサ(DSP)1802と、メモリ1804とを含む。示されるように、UE1700はさらに、アンテナおよびフロントエンドユニット1806と、無線周波数(RF)送受信機1808と、アナログベースバンド処理ユニット1810と、マイクロホン1812と、イヤホンスピーカ1814と、ヘッドセットポート1816と、入力/出力インターフェース1818と、可撤性メモリカード1820と、ユニバーサルシリアルバス(USB)ポート1822と、短距離無線通信サブシステム1824と、アラート1826と、キーパッド1828と、タッチセンサ式表面を含み得る液晶ディスプレイ(LCD)1830と、LCDコントローラ1832と、電荷結合素子(CCD)カメラ1834と、カメラコントローラ1836と、グローバルポジショニングシステム(GPS)センサ1838とを含み得る。実施形態では、UE1700は、タッチセンサ式画面を提供しない、別の種類のディスプレイを含み得る。実施形態では、DSP1802は、入力/出力インターフェース1818を通過せずに、メモリ1804と直接通信し得る。
DSP1802または何らかの他の形態のコントローラあるいは中央処理ユニットは、メモリ1804に記憶された、またはDSP1802自体内に含まれるメモリに記憶された、組み込みソフトウェアまたはファームウェアに従って、UE1700の種々の構成要素を制御するように動作する。組み込みソフトウェアまたはファームウェアに加えて、DSP1802は、メモリ1804に記憶された、または、可撤性メモリカード1820のような携帯用データ記憶メディア等の情報担体媒体を介して、あるいは有線または無線ネットワーク通信を介して利用可能となった、他のアプリケーションを実行し得る。アプリケーションソフトウェアは、所望の機能性を提供するようにDSP1802を構成する、コンパイルされた一式の機械可読命令を備え得、または、アプリケーションソフトウェアは、DSP1802を間接的に構成するようにインタープリタまたはコンパイラによって処理される、高次ソフトウェア命令であり得る。
アンテナおよびフロントエンドユニット1806は、無線信号と電気信号との間で変換するように提供され得、UE1700が、セルラーネットワークまたは何らかの他の利用可能な無線通信ネットワークから、あるいはピアUE1700から、情報を送受信することを可能にする。実施形態では、アンテナおよびフロントエンドユニット1806は、ビーム形成および/または多重入出力(MIMO)動作をサポートするように、複数のアンテナを含み得る。当業者に公知であるように、MIMO動作は、困難なチャネル条件を克服するために、および/またはチャネルスループットを増加させるために使用することができる、空間的多様性を提供し得る。アンテナおよびフロントエンドユニット1806は、アンテナ同調および/またはインピーダンス整合構成要素、RF電力増幅器、および/または低雑音増幅器を含み得る。
RF送受信機1808は、周波数偏移を提供し、受信したRF信号をベースバンドに変換し、ベースバンド伝送信号をRFに変換する。いくつかの説明では、無線送受信機またはRF送受信機は、変調/復調、符号化/復号、インターリービング/デインターリービング、拡散/逆拡散、逆高速フーリエ変換(IFFT)/高速フーリエ変換(FFT)、周期的接頭辞添付/除去、および他の信号処理機能等の、他の信号処理機能性を含むと理解され得る。簡単にする目的で、ここでの説明は、RFおよび/または無線段階から、この信号処理の説明を分離し、その信号処理を、アナログベースバンド処理ユニット1810および/またはDSP1802あるいは他の中央処理ユニットに概念的に割り当てる。いくつかの実施形態では、RF送受信機1808、アンテナおよびフロントエンド1806の複数部分、およびアナログベースバンド処理ユニット1810が、1つ以上の処理ユニットおよび/または特定用途向け集積回路(ASIC)に組み入れられ得る。
アナログベースバンド処理ユニット1810は、入力および出力の種々のアナログ処理、例えば、マイクロホン1812およびハンドセット1816からの入力ならびにイヤホン1814およびハンドセット1816への出力のアナログ処理を提供し得る。そのためには、アナログベースバンド処理ユニット1810は、UE1700が携帯電話として使用されることを可能にする、内蔵マイクロホン1812およびイヤホンスピーカ1814に接続するためのポートを有し得る。アナログベースバンド処理ユニット1810はさらに、ヘッドセットまたは他のハンズフリーマイクロホンおよびスピーカ構成に接続するためのポートを含み得る。アナログベースバンド処理ユニット1810は、1つの信号方向にデジタル・アナログ変換を、反対の信号方向にアナログ・デジタル変換を提供し得る。いくつかの実施形態では、アナログベースバンド処理ユニット1810の機能性の少なくとも一部が、デジタル処理構成要素によって、例えば、DSP1802によって、または他の中央処理ユニットによって提供され得る。
DSP1802は、変調/復調、符号化/復号、インターリービング/デインターリービング、拡散/逆拡散、逆高速フーリエ変換(IFFT)/高速フーリエ変換(FFT)、周期的接頭辞添付/除去、および無線通信と関連する他の信号処理機能を行い得る。実施形態では、例えば、符号分割多重アクセス(CDMA)技術用途で、伝送器機能のために、DSP1802は、変調、符号化、インターリービング、および拡散を行い得、受信機機能のために、DSP1802は、逆拡散、デインターリービング、復号、および復調を行い得る。別の実施形態では、例えば、直交周波数分割多重アクセス(OFDMA)技術用途で、伝送器機能のために、DSP1802は、変調、符号化、インターリービング、逆高速フーリエ変換、および周期的接頭辞添付を行い得、受信機機能のために、DSP1802は、周期的接頭辞除去、高速フーリエ変換、デインターリービング、復号、および復調を行い得る。他の無線技術用途では、さらに他の信号処理機能、および信号処理機能の組み合わせが、DSP1802によって行われ得る。
DSP1802は、アナログベースバンド処理ユニット1810を介して無線ネットワークと通信し得る。いくつかの実施形態では、通信は、インターネット接続を提供し得、ユーザがインターネット上のコンテンツへのアクセスを獲得することと、Eメールおよびテキストメッセージを送受信することとを可能にする。入力/出力インターフェース1818は、DSP1802ならびに種々のメモリおよびインターフェースを相互接続する。
メモリ1804および可撤性メモリカード1820は、DSP1802の動作を構成するように、ソフトウェアおよびデータを提供し得る。インターフェースの中には、USBインターフェース1822および短距離無線通信サブシステム1824があり得る。USBインターフェース1822は、UE1700に課金するために使用され得、また、UE1700が周辺デバイスとして機能し、パーソナルコンピュータまたは他のコンピュータシステムと情報を交換することを可能にし得る。短距離無線通信サブシステム1824は、赤外線ポート、Bluetooth(登録商標)インターフェース、IEEE802.11に準拠する無線インターフェース、あるいは、UE1700が他の近くの携帯デバイスおよび/または無線基地局と無線通信することを可能にし得る、任意の他の短距離無線通信サブシステムを含み得る。
入力/出力インターフェース1818はさらに、誘起されると、例えば、ベルを鳴らす、メロディを再生する、または振動することによって、UE1700にユーザへ通知を提供させる、アラート1826にDSP1802を接続し得る。アラート1826は、無音で振動することによって、または特定の架電者に対して特定の事前に割り当てられたメロディを再生することによって、着信電話、新しいテキストメッセージ、および予約のリマインダ等の種々のイベントのうちのいずれかをユーザに警告するための機構としての機能を果たし得る。
キーパッド1828は、インターフェース1818を介してDSP1802に連結し、ユーザが選択を行い、情報を入力し、別様に入力をUE1700に提供するための1つの機構を提供する。キーボード1828は、QWERTY、Dvorak、AZERTY、および逐次タイプ等の、完全または縮小英数字キーボード、または電話キーパッドと関連するアルファベット文字を伴う従来の数字キーパッドであり得る。入力キーは、さらなる入力機能を提供するように内向きに押下され得る、トラックホイール、終了またはエスケープキー、トラックボール、および他のナビゲーションまたは機能キーを含み得る。別の入力機構は、タッチスクリーン能力を含み、また、ユーザにテキストおよび/またはグラフィックを表示し得る、LCD1830であり得る。LCDコントローラ1832は、DSP1802をLCD1830に連結する。
CCDカメラ1834は、装備された場合、UE1700がデジタル写真を撮ることを可能にする。DSP1802は、カメラコントローラ1836を介してCCDカメラ1834と通信する。別の実施形態では、電荷結合素子カメラ以外の技術に従って動作するカメラが採用され得る。GPSセンサ1838は、グローバルポジショニングシステム信号を復号するようにDSP1802に連結され、それにより、UE1700がその位置を決定することを可能にする。種々の他の周辺機器もまた、追加の機能、例えば、ラジオおよびテレビ受信を提供するように含まれ得る。
図19は、DSP1802によって実装され得る、ソフトウェア環境1902を図示する。DSP1802は、残りのソフトウェアが動作するプラットフォームを提供する、オペレーティングシステムドライバ1904を実行する。オペレーティングシステムドライバ1904は、アプリケーションソフトウェアにアクセス可能である標準化インターフェースを伴うUAハードウェアに対するドライバを提供する。 オペレーティングシステムドライバ1904は、UE1700上で作動するアプリケーション間で制御を移転する、アプリケーション管理サービス(「AMS」)1906を含む。図19には、ウェブブラウザアプリケーション1908、メディアプレーヤアプリケーション1910、およびJava(登録商標)アプレット1912も示される。ウェブブラウザアプリケーション1908は、ウェブブラウザとして動作するようにUE1700を構成し、ユーザが書式に情報を入力し、リンクを選択してウェブページを読み出し、閲覧することを可能にする。メディアプレーヤアプリケーション1910は、音声または視聴覚媒体を読み出し、再生するようにUE1700を構成する。Java(登録商標)アプレット1912は、ゲーム、ユーティリティ、および他の機能性を提供するようにUE1700を構成する。構成要素1914は、本明細書で説明される機能性を提供する場合がある。
UE1700、アクセスデバイス、および上記で説明される他の構成要素は、上記で説明される措置に関係する命令を実行することが可能である、処理構成要素を含む場合がある。図20は、本明細書で開示される1つ以上の実施形態を実装するために好適な処理構成要素2010を含む、システム2000の実施例を図示する。プロセッサ2010(中央処理装置(CPUまたはDSP)と呼ばれ得る)に加えて、システム2000は、ネットワーク接続デバイス2020、ランダムアクセスメモリ(RAM)2030、読み出し専用メモリ(ROM)2040、2次記憶装置2050、および入出力(I/O)デバイス2060を含む場合がある。いくつかの実施例では、最小数のHARQプロセスIDの決定を実装するためのプログラムが、ROM2040に記憶され得る。場合によっては、これらの構成要素のうちのいくつかが存在しなくてもよく、または相互と、または示されていない他の構成要素と種々の組み合わせで組み合わせられ得る。これらの構成要素は、単一の物理的実体に、または1つより多くの物理的実体に位置する場合がある。プロセッサ2010によって講じられるものとして本明細書で説明される、任意の措置は、プロセッサ2010によって単独で、または、図面に示されている、あるいは示されていない1つ以上の構成要素と併せて、プロセッサ2010によって講じられる場合がある。
プロセッサ2010は、それがネットワーク接続デバイス2020、RAM2030、ROM2040、または2次記憶装置2050(ハードディスク、フロッピー(登録商標)ディスク、または光ディスク等の、種々のディスクベースのシステムを含む場合がある)からアクセスする場合がある、命令、コード、コンピュータプログラム、またはスクリプトを実行する。1つだけのプロセッサ2010が示されているが、複数のプロセッサが存在し得る。したがって、命令は、プロセッサによって実行されるものとして論議され得るが、命令は、同時に、連続的に、または別様に、1つまたは複数のプロセッサによって実行され得る。プロセッサ2010は、1つ以上のCPUチップとして実装され得る。
ネットワーク接続デバイス2020は、モデム、モデムバンク、イーサネット(登録商標)デバイス、ユニバーサルシリアルバス(USB)インターフェースデバイス、シリアルインターフェース、トークンリングデバイス、光ファイバ分散データインターフェース(FDDI)デバイス、無線ローカルエリアネットワーク(WLAN)デバイス、符号分割多重アクセス(CDMA)デバイス、グローバルシステムフォーモバイルコミュニケーションズ(GSM(登録商標))無線送受信機デバイス等の無線送受信機デバイス、マイクロ波アクセス用の世界的相互運用性(WiMAX)デバイス、および/またはネットワークに接続するための他の周知のデバイスの形態を成し得る。これらのネットワーク接続デバイス2020は、プロセッサ2010が情報を受信する場合がある、またはプロセッサ2010が情報を出力する場合がある、インターネットまたは1つ以上の電気通信ネットワーク、あるいは他のネットワークと、プロセッサ2010が通信することを可能にし得る。
ネットワーク接続デバイス2020はまた、無線周波数信号またはマイクロ波周波数信号等の電磁波の形態で、データを無線で伝送および/または受信することが可能な1つ以上の送受信機構成要素2025も含む場合がある。代替として、データは、導電体の表面の中または上、同軸ケーブルの中、導波管の中、光ファイバ等の光媒体の中、あるいは他の媒体の中を伝播し得る。送受信機構成要素2025は、別個の受信および伝送ユニット、または単一の送受信機を含む場合がある。送受信機2025によって伝送または受信される情報は、プロセッサ2010によって処理されたデータ、またはプロセッサ2010によって実行される命令を含み得る。そのような情報は、例えば、コンピュータデータベースバンド信号または搬送波で具現化される信号の形態で、ネットワークから受信され、かつネットワークへ出力され得る。データは、データを処理または生成するか、あるいはデータを伝送または受信するために望ましい異なる順序に従って、順序付けられ得る。ベースバンド信号、搬送波に組み込まれた信号、または、現在使用されている、あるいは今後開発される他の種類の信号が、伝送媒体と呼ばれ、当業者に周知のいくつかの方法に従って生成され得る。
RAM2030は、揮発性データを記憶するため、およびおそらくプロセッサ2010によって実行される命令を記憶するために使用される場合がある。ROM2040は、典型的には2次記憶装置2050のメモリ容量よりも小さいメモリ容量を有する、不揮発性メモリデバイスである。ROM2040は、命令、およびおそらく命令の実行中に読み出されるデータを記憶するために使用される場合がある。RAM2030およびROM2040の両方へのアクセスは、典型的には、2次記憶装置2050へのアクセスよりも速い。2次記憶装置2050は、典型的には、1つ以上のディスクドライブまたはテープドライブから成り、RAM2030が全作業データを保持するほど十分に大きくない場合に、データの不揮発性記憶のために、またはオーバーフローデータ記憶デバイスとして使用される場合がある。2次記憶装置2050は、RAM2030にロードされるプログラムが実行のために選択されると、そのようなプログラムを記憶するために使用され得る。
I/Oデバイス2060は、液晶ディスプレイ(LCD)、タッチスクリーンディスプレイ、キーボード、キーパッド、スイッチ、ダイヤル、マウス、トラックボール、音声認識装置、カード読取装置、紙テープ読取装置、プリンタ、ビデオモニタ、または他の周知の入力デバイスを含み得る。 また、送受信機2025は、ネットワーク接続デバイス2020の構成要素であるかわりに、またはそれに加えて、I/Oデバイス2060の構成要素と見なされる場合がある。I/Oデバイス2060のうちのいくつかまたは全ては、ディスプレイおよび入力等のUE1700の以前に説明された図面に描写される種々の構成要素と実質的に同様であり得る。
いくつかの実施形態を本開示で提供したが、開示されたシステムおよび方法は、本開示の精神または範囲から逸脱することなく、多くの他の具体的形態で具現化され得ることを理解されたい。本実施例は、制限的ではなく例証的と見なされるものであり、本明細書で与えられる詳細に制限されることを意図するものではない。例えば、種々の要素または構成要素が組み合わされるか、または別のシステムに統合され得、または、ある特徴が省略されるか、あるいは実装されなくてもよい。
また、個別または別個のものとして種々の実施形態で説明および例証される、技術、システム、サブシステム、および方法は、本開示の範囲から逸脱することなく、他のシステム、モジュール、技術、または方法と組み合わされるか、あるいは統合され得る。相互に連結される、または直接連結される、あるいは通信するものとして示される、または論議される他の項目は、電気的であろうと、機械的であろうと、または別の方法であろうと、何らかのインターフェース、デバイス、または中間構成要素を通して、間接的に連結されるか、または通信し得る。変更、置換、および改変の他の実施例が、当業者によって究明可能であり、本明細書で開示される精神および範囲から逸脱することなく行うことができる。
別の実施例では、第1のユーザ機器(UE)と第3のUEとの間でメディアコンテンツを伝達するためのセッションを移転する方法は、第1のUEにセッションに対するコントローラ機能を割り当てることと、メディアコンテンツを伝達するためのセッションを第2のUEに移転するための要求を第1のUEから受信することと、メディアコンテンツを伝達するためのセッションを受信するための第2のUEの能力を決定することとを含む。第2のUEがメディアコンテンツを伝達するためのセッションを受信する能力を有する場合に、方法は、メディアコンテンツを伝達するためのセッションを第2のUEに移転することと、メディアコンテンツを伝達するためのセッションを第2のUEに移転するための要求に応答して、第1のUEにセッションを解放するように通知することとを含む。
本発明はさらに、例えば、以下を提供する。
(項目1)
制御を移転する方法であって、
協調セッションの制御を移転するための要求を、第1のユーザ機器(UE)から受信することと、
該受信された要求に応答して、該協調セッションの制御の移転の要求を第2のUEに送信することと、
該第2のUEへの該送信された要求に応答して、該協調セッションの制御の移転の受諾の指示を受信することと、
該第2のUEからの該受諾の指示の受信に応答して、該協調セッションの制御の状態の通知を該第1のUEに送信することと
を含む、方法。
(項目2)
前記受信された応答は、セッション初期化プロトコル(SIP)として符号化されている、項目1に記載の方法。
(項目3)
前記SIPメッセージは、SIP REFERメッセージである、項目2に記載の方法。
(項目4)
前記制御を移転するための要求を受信することに応答して、成功を示すNOTIFYメッセージを送信することをさらに含む、項目1に記載の方法。
(項目5)
前記協調セッションの制御の移転を要求するメッセージは、メディア移転の要求も含む、項目1に記載の方法。
(項目6)
プロセッサを備え、該プロセッサは、
協調セッションの制御を移転するための要求を、第1のユーザ機器(UE)から受信することと、
該受信された要求に応答して、該協調セッションの制御の移転の要求を第2のUEに送信することと、
該第2のUEへの該送信された要求に応答して、該協調セッションの制御の移転の受諾の指示を受信することと、
該第2のUEからの該受諾の指示の受信に応答して、該協調セッションの制御の状態の通知を該第1のUEに送信することと
を行うように構成されている、
ネットワークノード。
(項目7)
前記受信された応答は、SIPとして符号化されている、項目6に記載のネットワークノード。
(項目8)
前記SIPメッセージは、SIP REFERメッセージである、項目7に記載のネットワークノード。
(項目9)
前記制御を移転するための要求を受信することに応答して、成功を示すNOTIFYメッセージを送信することをさらに含む、項目6に記載のネットワークノード。
(項目10)
前記協調セッションの制御の移転を要求するメッセージは、メディア移転の要求も含む、項目6に記載のネットワークノード。
(項目11)
前記ネットワークノードは、サービス一貫性および連続性アプリケーションサーバ(SCC AS)を含む、項目6に記載のネットワークノード。
(項目12)
プロセッサを備え、該プロセッサは、
第1のユーザ機器(UE)から協調セッションの制御を移転するための要求を伝送することと、
該協調セッションの制御の状態の通知を受信することと
を行うように構成されている、
ユーザ機器(UE)。
(項目13)
前記状態の通知は、NOTIFYメッセージを含む、項目12に記載のUE。
(項目14)
前記協調セッションの制御の移転を要求するメッセージは、メディア移転の要求も含む、項目12に記載のUE。

Claims (14)

  1. 制御を移転する方法であって、
    協調セッションの制御を移転するための要求を、第1のユーザ機器(UE)から受信することと、
    該受信された要求に応答して、該協調セッションの制御の移転の要求を第2のUEに送信することと、
    該第2のUEへの該送信された要求に応答して、該協調セッションの制御の移転の受諾の指示を受信することと、
    該第2のUEからの該受諾の指示の受信に応答して、該協調セッションの制御の状態の通知を該第1のUEに送信することと
    を含む、方法。
  2. 前記受信された応答は、セッション初期化プロトコル(SIP)として符号化されている、請求項1に記載の方法。
  3. 前記SIPメッセージは、SIP REFERメッセージである、請求項2に記載の方法。
  4. 前記制御を移転するための要求を受信することに応答して、成功を示すNOTIFYメッセージを送信することをさらに含む、請求項1に記載の方法。
  5. 前記協調セッションの制御の移転を要求するメッセージは、メディア移転の要求も含む、請求項1に記載の方法。
  6. プロセッサを備え、該プロセッサは、
    協調セッションの制御を移転するための要求を、第1のユーザ機器(UE)から受信することと、
    該受信された要求に応答して、該協調セッションの制御の移転の要求を第2のUEに送信することと、
    該第2のUEへの該送信された要求に応答して、該協調セッションの制御の移転の受諾の指示を受信することと、
    該第2のUEからの該受諾の指示の受信に応答して、該協調セッションの制御の状態の通知を該第1のUEに送信することと
    を行うように構成されている、
    ネットワークノード。
  7. 前記受信された応答は、SIPとして符号化されている、請求項6に記載のネットワークノード。
  8. 前記SIPメッセージは、SIP REFERメッセージである、請求項7に記載のネットワークノード。
  9. 前記制御を移転するための要求を受信することに応答して、成功を示すNOTIFYメッセージを送信することをさらに含む、請求項6に記載のネットワークノード。
  10. 前記協調セッションの制御の移転を要求するメッセージは、メディア移転の要求も含む、請求項6に記載のネットワークノード。
  11. 前記ネットワークノードは、サービス一貫性および連続性アプリケーションサーバ(SCC AS)を含む、請求項6に記載のネットワークノード。
  12. プロセッサを備え、該プロセッサは、
    第1のユーザ機器(UE)から協調セッションの制御を移転するための要求を伝送することと、
    該協調セッションの制御の状態の通知を受信することと
    を行うように構成されている、
    ユーザ機器(UE)。
  13. 前記状態の通知は、NOTIFYメッセージを含む、請求項12に記載のUE。
  14. 前記協調セッションの制御の移転を要求するメッセージは、メディア移転の要求も含む、請求項12に記載のUE。
JP2012508787A 2009-05-04 2010-04-30 デバイス間のメディアおよび/またはメディア移転を実装するためのシステムおよび方法 Active JP5518185B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US17540309P 2009-05-04 2009-05-04
US61/175,403 2009-05-04
PCT/US2010/033228 WO2010129426A1 (en) 2009-05-04 2010-04-30 System and method for implementing a transfer of control of a collaborative session using sip protocol

Publications (2)

Publication Number Publication Date
JP2012526415A true JP2012526415A (ja) 2012-10-25
JP5518185B2 JP5518185B2 (ja) 2014-06-11

Family

ID=42272263

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012508787A Active JP5518185B2 (ja) 2009-05-04 2010-04-30 デバイス間のメディアおよび/またはメディア移転を実装するためのシステムおよび方法

Country Status (8)

Country Link
US (2) US20100312897A1 (ja)
EP (2) EP2428016B1 (ja)
JP (1) JP5518185B2 (ja)
KR (1) KR101332706B1 (ja)
CN (2) CN102656858A (ja)
CA (1) CA2760901C (ja)
ES (1) ES2959653T3 (ja)
WO (1) WO2010129426A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017034308A (ja) * 2015-07-28 2017-02-09 株式会社リコー 端末、通信システム、通信方法、及びプログラム

Families Citing this family (90)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8009586B2 (en) 2004-06-29 2011-08-30 Damaka, Inc. System and method for data transfer in a peer-to peer hybrid communication network
US8050272B2 (en) 2004-06-29 2011-11-01 Damaka, Inc. System and method for concurrent sessions in a peer-to-peer hybrid communications network
US7570636B2 (en) 2004-06-29 2009-08-04 Damaka, Inc. System and method for traversing a NAT device for peer-to-peer hybrid communications
US7933260B2 (en) 2004-06-29 2011-04-26 Damaka, Inc. System and method for routing and communicating in a heterogeneous network environment
US20150257038A1 (en) * 2007-02-05 2015-09-10 Wefi, Inc. Devices, systems, and methods for sharing network capacity
WO2009032854A2 (en) 2007-09-03 2009-03-12 Damaka, Inc. Device and method for maintaining a communication session during a network transition
US8862164B2 (en) 2007-09-28 2014-10-14 Damaka, Inc. System and method for transitioning a communication session between networks that are not commonly controlled
WO2009070718A1 (en) 2007-11-28 2009-06-04 Damaka, Inc. System and method for endpoint handoff in a hybrid peer-to-peer networking environment
US9641567B2 (en) * 2009-05-14 2017-05-02 Qualcomm Incorporated Controlling media and informing controller status in collaborative sessions
US9641564B2 (en) * 2009-05-14 2017-05-02 Qualcomm Incorporated Maintaining controllee information in collaborative sessions
EP2436222A4 (en) * 2009-05-26 2014-11-26 Nokia Corp METHOD AND DEVICE FOR TRANSMITTING A MEDIA MEETING
US8687593B2 (en) * 2009-08-28 2014-04-01 Futurewei Technologies, Inc. System and method for multimedia sharing in a collaborative session
US20110231560A1 (en) * 2009-09-11 2011-09-22 Arungundram Chandrasekaran Mahendran User Equipment (UE) Session Notification in a Collaborative Communication Session
JP5514916B2 (ja) * 2009-11-10 2014-06-04 インターデイジタル パテント ホールディングス インコーポレイテッド インターネットプロトコルマルチメディアサブシステムにおける協調セッションの制御権の移転およびデバイス間移転
TW201141162A (en) * 2009-12-15 2011-11-16 Interdigital Patent Holdings Inter-device mobility session release
US20110173292A1 (en) * 2010-01-11 2011-07-14 Interdigital Patent Holdings, Inc. Push based inter-operator inter-device transfer
US20110205937A1 (en) * 2010-01-12 2011-08-25 Interdigital Patent Holdings, Inc. Pull based inter-operator inter-device transfer
US8892646B2 (en) 2010-08-25 2014-11-18 Damaka, Inc. System and method for shared session appearance in a hybrid peer-to-peer environment
US8874785B2 (en) 2010-02-15 2014-10-28 Damaka, Inc. System and method for signaling and data tunneling in a peer-to-peer environment
US8725895B2 (en) 2010-02-15 2014-05-13 Damaka, Inc. NAT traversal by concurrently probing multiple candidates
US20110216701A1 (en) * 2010-03-04 2011-09-08 Interdigital Patent Holdings, Inc. Method and apparatus for identification and transfer in internet protocol multimedia subsystem collaborative sessions
JP5475921B2 (ja) 2010-03-18 2014-04-16 インターデイジタル パテント ホールディングス インコーポレイテッド ユーザ要素間セッション転送の認可
US9043488B2 (en) * 2010-03-29 2015-05-26 Damaka, Inc. System and method for session sweeping between devices
US9191416B2 (en) 2010-04-16 2015-11-17 Damaka, Inc. System and method for providing enterprise voice call continuity
WO2011132908A2 (ko) * 2010-04-19 2011-10-27 엘지전자 주식회사 단말간에 데이터를 협력하여 전송하는 방법 및 이를 위해 협력가능한 단말들을 클러스터링하는 방법
US9300696B2 (en) * 2010-04-22 2016-03-29 Lg Electronics Inc. Method of sharing one or more media in a session between terminals
US8352563B2 (en) 2010-04-29 2013-01-08 Damaka, Inc. System and method for peer-to-peer media routing using a third party instant messaging system for signaling
EP2566124A4 (en) * 2010-04-30 2013-05-01 Huawei Tech Co Ltd METHOD, DEVICE AND SYSTEM FOR ESTABLISHING COLLABORATIVE MEETINGS
CN102238152B (zh) * 2010-05-06 2015-09-23 华为技术有限公司 控制内容报告行为的方法、装置和系统
US8446900B2 (en) 2010-06-18 2013-05-21 Damaka, Inc. System and method for transferring a call between endpoints in a hybrid peer-to-peer network
US8611540B2 (en) 2010-06-23 2013-12-17 Damaka, Inc. System and method for secure messaging in a hybrid peer-to-peer network
EP2418817B1 (en) * 2010-08-12 2018-12-12 Deutsche Telekom AG Application server for managing communications towards a set of user entities
US9094423B2 (en) * 2010-08-13 2015-07-28 Qualcomm Incorporated Apparatus and methods for inter-user equipment transfers
US8468010B2 (en) 2010-09-24 2013-06-18 Damaka, Inc. System and method for language translation in a hybrid peer-to-peer environment
CN103155641B (zh) * 2010-10-04 2016-03-09 交互数字专利控股公司 用于包括媒体会话信息的协同会话的用户设备(ue)间转移(iut)
US8743781B2 (en) 2010-10-11 2014-06-03 Damaka, Inc. System and method for a reverse invitation in a hybrid peer-to-peer environment
EP2489235B1 (en) 2010-12-23 2019-10-30 BlackBerry Limited Card toolkit support for ip multimedia subsystem
US9064278B2 (en) * 2010-12-30 2015-06-23 Futurewei Technologies, Inc. System for managing, storing and providing shared digital content to users in a user relationship defined group in a multi-platform environment
US8761140B2 (en) 2011-02-08 2014-06-24 Htc Corporation Method of handling ownership transfer and related communication
CN102685606B (zh) * 2011-03-18 2016-05-25 华为终端有限公司 互联网协议电视中业务收看的方法和系统
US8407314B2 (en) 2011-04-04 2013-03-26 Damaka, Inc. System and method for sharing unsupported document types between communication devices
WO2012145817A1 (en) 2011-04-26 2012-11-01 Research In Motion Limited Transmission of the pdp content activation rejection cause codes to the uicc
CN102780678A (zh) * 2011-05-10 2012-11-14 华为终端有限公司 共享内容的方法和设备
US8694587B2 (en) 2011-05-17 2014-04-08 Damaka, Inc. System and method for transferring a call bridge between communication devices
JP5889559B2 (ja) * 2011-07-13 2016-03-22 ソニー株式会社 情報処理方法および情報処理システム
US8478890B2 (en) 2011-07-15 2013-07-02 Damaka, Inc. System and method for reliable virtual bi-directional data stream communications with single socket point-to-multipoint capability
JP5942354B2 (ja) 2011-07-22 2016-06-29 ソニー株式会社 無線通信装置、情報処理装置、通信システムおよび無線通信装置の制御方法
JP5948762B2 (ja) * 2011-08-26 2016-07-06 ソニー株式会社 情報処理装置、通信システムおよび情報処理装置の制御方法
WO2013044952A1 (en) * 2011-09-28 2013-04-04 Telefonaktiebolaget L M Ericsson (Publ) Extending sip p-served user header over ims interfaces
WO2013089452A1 (ko) * 2011-12-13 2013-06-20 엘지전자 주식회사 무선 통신 시스템에서 근접 서비스 제공 방법 및 장치
IN2014MN01774A (ja) * 2012-02-13 2015-07-03 Tata Comm America Inc
CN103379017B (zh) * 2012-04-13 2018-03-16 中兴通讯股份有限公司 语音留言方法及系统、融合消息服务器及客户端
FR2991530A1 (fr) * 2012-05-29 2013-12-06 France Telecom Procede et entite de traitement d'un message
CN103906074B (zh) * 2012-12-31 2018-01-12 华为技术有限公司 无线软件定义网络中进行通信的方法及其装置
US9609488B2 (en) 2013-02-01 2017-03-28 Qualcomm Incorporated Managing broadcast services
CN104079597B (zh) * 2013-03-26 2018-08-21 华为终端有限公司 媒体流的转移方法和用户设备
EP2816629A1 (en) * 2013-03-28 2014-12-24 Technische Universität München Energy storage cell
US8825814B1 (en) * 2013-05-23 2014-09-02 Vonage Network Llc Method and apparatus for minimizing application delay by pushing application notifications
US10951771B2 (en) * 2013-05-31 2021-03-16 Vonage Business Inc. Method and apparatus for call handling control
US9027032B2 (en) 2013-07-16 2015-05-05 Damaka, Inc. System and method for providing additional functionality to existing software in an integrated manner
US20150026351A1 (en) * 2013-07-19 2015-01-22 Bank Of America Corporation Online session transfer
CN103428208B (zh) * 2013-08-01 2016-04-27 清华大学 分布式sip重定向服务器及其构建方法
US9357016B2 (en) 2013-10-18 2016-05-31 Damaka, Inc. System and method for virtual parallel resource management
WO2015069154A1 (en) 2013-11-06 2015-05-14 Telefonaktiebolaget L M Ericsson (Publ) Methods and user equipments for exchanging service capabilities
US10033723B2 (en) 2013-12-18 2018-07-24 At&T Intellectual Property I, L.P. Methods, devices, and computer readable storage devices for authenticating devices having non-SIM based clients
US9913125B1 (en) 2014-05-12 2018-03-06 Sprint Communications Company L.P. Mobile data service control for a wireless communication device
KR20160009276A (ko) * 2014-07-16 2016-01-26 한국전자통신연구원 Ims 기반의 서비스 공유를 위한 마스터 ims 단말, ims 기반의 서비스 공유를 위한 슬레이브 ims 단말, ims 기반의 서비스 공유 시스템, 및 공유 방법.
US9871828B2 (en) * 2014-07-18 2018-01-16 T-Mobile Usa, Inc. Enhanced IMS services restriction and selection control for mobile devices roaming in foreign networks
CA2956617A1 (en) 2014-08-05 2016-02-11 Damaka, Inc. System and method for providing unified communications and collaboration (ucc) connectivity between incompatible systems
WO2016176862A1 (zh) * 2015-05-07 2016-11-10 华为技术有限公司 一种业务处理方法及用户设备
US10379808B1 (en) * 2015-09-29 2019-08-13 Amazon Technologies, Inc. Audio associating of computing devices
EP3360301B1 (en) * 2015-10-08 2021-08-11 Telefonaktiebolaget LM Ericsson (PUBL) Notifying changes in radio access technology
US10015671B2 (en) 2016-01-19 2018-07-03 T-Mobile Usa, Inc. Network service access control
US10425450B2 (en) * 2016-02-27 2019-09-24 Ofinno, Llc Mission critical communications
US9756179B1 (en) * 2016-03-07 2017-09-05 T-Mobile Usa, Inc. Multiple device and multiple line connected home and home monitoring
JP6753088B2 (ja) * 2016-03-18 2020-09-09 株式会社リコー 遠隔コミュニケーションシステム、通信端末、端末連携方法および端末連携プログラム
US10091025B2 (en) 2016-03-31 2018-10-02 Damaka, Inc. System and method for enabling use of a single user identifier across incompatible networks for UCC functionality
US10897507B2 (en) * 2016-04-01 2021-01-19 Qualcomm Incorporated Mechanism to enable connectivity sessions and IP session establishment
WO2017177382A1 (zh) * 2016-04-12 2017-10-19 广东欧珀移动通信有限公司 用于确定业务通信的编解码模式集的方法和装置
JP6217790B2 (ja) * 2016-06-02 2017-10-25 ソニー株式会社 無線通信装置、無線通信装置の制御方法およびプログラム
IT201700093693A1 (it) 2017-08-14 2019-02-14 St Microelectronics Srl Procedimento per trasmettere almeno un pacchetto di dati ip, relativo sistema e prodotto informatico
CN109586940B (zh) * 2017-09-29 2021-12-24 深圳市金溢科技股份有限公司 一种手持机及远程维护方法
US10375563B1 (en) 2018-04-05 2019-08-06 T-Mobile Usa, Inc. Systems and methods for web-based communications consolidation
US11195122B2 (en) * 2018-04-27 2021-12-07 International Business Machines Corporation Intelligent user notification during an event in an internet of things (IoT) computing environment
US11431767B2 (en) * 2018-05-29 2022-08-30 Sorenson Ip Holdings, Llc Changing a communication session
CN110730027B (zh) * 2018-07-16 2021-11-16 中国移动通信集团浙江有限公司 一种海洋卫星宽带通信方法及装置
US11438389B2 (en) * 2020-05-04 2022-09-06 Verizon Patent And Licensing Inc. Systems and methods for enhanced messaging for network- and user equipment-implemented call request handling
CN111641602B (zh) * 2020-05-13 2022-11-04 维沃移动通信有限公司 会话创建方法、装置及电子设备
CN114258102A (zh) * 2020-09-25 2022-03-29 维沃移动通信有限公司 传输业务数据的方法、装置、终端设备和网络设备
CN112295217B (zh) * 2020-11-17 2023-04-07 Oppo广东移动通信有限公司 设备加入方法、装置、电子设备及计算机可读介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004248165A (ja) * 2003-02-17 2004-09-02 Nippon Telegr & Teleph Corp <Ntt> セッションおよびメディア中継方法、転送方法、ならびにそのプログラムと記録媒体
JP2007104163A (ja) * 2005-10-03 2007-04-19 Matsushita Electric Ind Co Ltd 通信端末
JP2008048183A (ja) * 2006-08-17 2008-02-28 Kddi Corp グループ通信におけるサービス切替方法、サーバ、端末及びプログラム

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10283293A (ja) * 1997-03-31 1998-10-23 Nec Corp アプリケーション共有システム及びプログラムを記録した機械読み取り可能な記録媒体
US20050060411A1 (en) * 2003-09-16 2005-03-17 Stephane Coulombe System and method for adaptation of peer-to-peer multimedia sessions
FI20040871A (fi) 2004-06-23 2005-12-24 Teliasonera Finland Oyj Menetelmä, järjestelmä ja palvelin session siirtämiseksi tietoliikennejärjestelmässä
US20060072526A1 (en) * 2004-10-04 2006-04-06 Nokia Corporation Change of resource reservation for an IP session
CN1791267A (zh) * 2004-12-17 2006-06-21 华为技术有限公司 一种基于sip协议的会话切换方法和系统
GB0500483D0 (en) * 2005-01-11 2005-02-16 Nokia Corp Multi-party sessions in a communication system
KR100910801B1 (ko) * 2005-05-02 2009-08-04 엘지전자 주식회사 Sip 기반의 세션 셋업 방법 및 장치
US20070005696A1 (en) * 2005-07-01 2007-01-04 Beers Theodore W Method for host transfer in a virtual collaboration session
RU2327300C2 (ru) * 2005-08-12 2008-06-20 Самсунг Электроникс Ко., Лтд. Система и способ передачи системных сообщений в протоколе инициирования сеанса связи (sip)
EP1943801A1 (en) * 2005-10-31 2008-07-16 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Transfer of part of a push to talk session
US20070271338A1 (en) * 2006-05-18 2007-11-22 Thomas Anschutz Methods, systems, and products for synchronizing media experiences
US7751354B2 (en) * 2006-10-17 2010-07-06 Alcatel-Lucent Usa Inc. Methods of network-initiated partial session transfer
CN101232413B (zh) 2007-01-25 2012-11-21 华为技术有限公司 一种转移会话控制权的方法、系统和服务器
US20080281971A1 (en) * 2007-05-07 2008-11-13 Nokia Corporation Network multimedia communication using multiple devices
CN101316204B (zh) * 2007-05-28 2013-08-07 华为技术有限公司 会话移动方法和会话移动系统
US8572216B2 (en) * 2007-08-08 2013-10-29 Yahoo! Inc. Social network building
CN101370176B (zh) * 2007-08-17 2011-12-21 华为技术有限公司 多媒体会话在不同接入网络间转移的方法及装置
US8725874B2 (en) * 2007-09-27 2014-05-13 International Business Machines Corporation Dynamic determination of an ideal client-server for a collaborative application network
CA2721275C (en) * 2008-04-14 2014-05-20 Research In Motion Limited Apparatus, and associated method, for facilitating radio control system operation with an ics-capable wireless device
KR101457217B1 (ko) * 2008-05-02 2014-10-31 삼성전자주식회사 멀티클라이언트 간 세션 이동을 위한 시스템 및 방법
US8099089B2 (en) * 2008-05-13 2012-01-17 Nokia Corporation Method, user equipment and software product for media stream transfer between devices
WO2010081146A2 (en) * 2009-01-12 2010-07-15 Starent Networks, Corp Transferring sessions in a communications network

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004248165A (ja) * 2003-02-17 2004-09-02 Nippon Telegr & Teleph Corp <Ntt> セッションおよびメディア中継方法、転送方法、ならびにそのプログラムと記録媒体
JP2007104163A (ja) * 2005-10-03 2007-04-19 Matsushita Electric Ind Co Ltd 通信端末
JP2008048183A (ja) * 2006-08-17 2008-02-28 Kddi Corp グループ通信におけるサービス切替方法、サーバ、端末及びプログラム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017034308A (ja) * 2015-07-28 2017-02-09 株式会社リコー 端末、通信システム、通信方法、及びプログラム

Also Published As

Publication number Publication date
US10609099B2 (en) 2020-03-31
WO2010129426A1 (en) 2010-11-11
JP5518185B2 (ja) 2014-06-11
CN107070849B (zh) 2020-09-22
US20100312897A1 (en) 2010-12-09
CA2760901A1 (en) 2010-11-11
EP2428016A1 (en) 2012-03-14
EP2428016B1 (en) 2020-02-05
EP3661160A1 (en) 2020-06-03
EP3661160B1 (en) 2023-09-13
CN107070849A (zh) 2017-08-18
CN102656858A (zh) 2012-09-05
US20150312295A1 (en) 2015-10-29
CA2760901C (en) 2021-01-26
KR101332706B1 (ko) 2013-11-27
KR20120006075A (ko) 2012-01-17
EP3661160C0 (en) 2023-09-13
ES2959653T3 (es) 2024-02-27

Similar Documents

Publication Publication Date Title
JP5518185B2 (ja) デバイス間のメディアおよび/またはメディア移転を実装するためのシステムおよび方法
JP5452821B2 (ja) デバイス間のメディアおよび/またはメディア移転を実装するためのシステムおよび方法
KR101332713B1 (ko) 미디어 및 장치들 간의 미디어 이전을 구현하는 시스템 및 방법
JP5443392B2 (ja) パーソナルネットワークアクセス制御システムおよび方法
US9306986B2 (en) Method for controlling session and server using the same
EP2456171B1 (en) Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity
JP2012532504A (ja) 進化型パケットシステムのボイスサービスインジケータに基づいてボイスサービスにアクセスするシステムおよび方法
US20120185604A1 (en) System and method for indicating callee preferences
CA2774429C (en) Method for controlling session and server using the same
CA2824700A1 (en) System and method for indicating callee preferences

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130607

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130611

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130911

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20140328

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140401

R150 Certificate of patent or registration of utility model

Ref document number: 5518185

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250