【発明の詳細な説明】
ストリーミング・プロトコルにおけるギャップ・カバレッジのための方法および
装置
発明の分野
本発明は、通信プロトコルに関し、さらに詳しくは、データ・ストリーミング
・プロトコルを提示する際にギャップ内でデータ・コンテンツをクライアントに
提供できる通信装置および方法に関する。
発明の背景
インターネット・データ・ストリーミング・プロトコルまたは任意のデータ・
ストリーミング・プロトコルを利用する場合、視聴者へのデータ配信の際にタイ
ム・ギャップまたは遅延が生じることが多い。データはテキストからなることが
あるが、ビデオまたは音声素材も含むことがある。これらのギャップは現在利用
されておらず、ユーザまたは視聴者の時間を無駄にして、ユーザまたは視聴者が
関心を失うことがある。
音声，ビデオまたは同様な情報を通信するためにインターネットのワールド・
ワイド・ウェッブ（ＷＷＷ）上で当
初利用されたデータ・ストリーミング・プロトコルは、データを収容するファイ
ルをサーバがクライアントに渡すものであった。ファイル全体を受信した後、ク
ライアントはファイルを再生または表示する。この機構は極めて遅く、ファイル
がクライアントによって受信されるまでに数分の遅延を要する場合が多かった。
しかし、ファイルが受信されると、休止やギャップがほとんどなく、リアルタイ
ムで再生できた。「データ・ストリーミング」は、特に、マルチメディア・コン
テンツを受信する場合に生じるこの著しい遅延に対処するために生まれた。基本
的には、データ・ストリーミングは、リアルタイム・データをパケットに分割し
て、このパケットをサーバからクライアントに送信することによって機能する。
クライアントは、多数のパケット（その数は以降のパケットの配信における予定
遅延(expected delay)に基づく）をバッファし、データ・セット全体（ビデオ，
音声または同様のファイル）を受信する前にデータの再生を開始する。データの
再生中または提示中に、データの残りが受信される。この機構は、システムのユ
ーザが体験する初期遅延を大幅に軽減する。
しかし、このストリーミング機構では、新たな問題が生じる。すなわち、以降
のパケットが予定通りタイムリーに着信せず、その結果ユーザへの提示中にギャ
ップが生じることがある。言い換えると、クライアントは、提示を開始する前に
十分なデータをバッファせずに、クライアントが
残りのデータを十分早く受信できないために、クライアント側でユーザに提示す
べきデータがなくなってしまう。既存のストリーミング機構は、単純に停止して
、提示を続けるための十分なデータが得られるまでユーザを待たせたままにする
。Real Audio社が採用するＲＴＳＰ(Real-Time Streaming Protocol)や、このプ
ロトコルの基盤となるＲＴＰ(Real-Time Transport Protocol)ＩＥＴＦ規格など
の既存のデータ・ストリーミング機構は、上記とほぼ同様にして機能する。従っ
て、ストリーミング・データの配信におけるこれらのギャップを効果的に利用す
る必要がある。
図面の簡単な説明
第１図は、本発明により、インターネット・ストリーミング・プロトコルでギ
ャップ・カバレッジを提供するシステムのブロック図である。
第２図は、本発明により、データ・ストリーミング・サーバにおいてギャップ
・カバレッジを提供するための方法を示すフローチャートである。
第３図は、本発明により、データ・ストリーミング・クライアント受信機にお
いてギャップ・カバレッジを受信するための方法を示すフローチャートである。
第４図は、本発明により、データ・ストリーミング・クライアント受信機にお
いてギャップ・カバレッジを提示す
るための方法を示すフローチャートである。
詳細な説明
サーバからクライアントにリアルタイム・データ１２(ビデオ・ソースなど)を
通信するために用いられるデータ・ストリーミング・プロトコルは、新たなタイ
プのコンテンツを識別し、伝達するように強化される。この新たなコンテンツは
、「カバレッジ・コンテンツ(coverage content)」１４またはギャップ・データ
であり、これは多分ある種の広告となる。必要な強化の詳細は、利用されるスト
リーミング・プロトコルおよびカバレッジ・コンテンツの厳密な性質に依存する
。
第１図を参照して、本発明によりデータ・ストリーミング・プロトコルにおい
てギャップ・カバレッジを提供するシステムを示す。好ましくは、システム１０
は、クライアントによって要求された要求データを格納し、かつギャップ・デー
タを格納するためのメモリ１５と、プロセッサ１７とによって構成される。好ま
しくは、プロセッサ１７は、要求データをクライアントにストリーミングするた
めのクライアント２０からの要求を受信するようにプログラミングされる。また
、プロセッサ１７は、ストリーミング・プロトコルを設定・開始するようにプロ
グラミングされる。また、プロセッサ１７は、データ・ストリーミング・プロ
トコル中の所定の時間でストリーミングできる適切なギャップ・データを選択で
きる。この所定の時間は、好ましくは、データ・ストリームの開始である。さら
に、プロセッサ１７は、適切なギャップ・データをフォーマット化する。
これが完了すると、所定のギャップ・データは所定の時間中に送信できる。もち
ろん、プロセッサ１７は、好ましくは、ギャップ・データが送信された後に、ク
ライアントへの要求データを送信・完了するようにプログラミングされる。サー
バ１６とクライアント２０との間のデータの送信は、好ましくは、インターネッ
トなどのデータ・ネットワーク１８上で行われる。
サーバは、識別されたカバレッジ・コンテンツ(すなわち、広告)、多分そのい
くつかのインスタンスを、さまざまなポイントでデータ・ストリーム内に挿入す
る。ストリームの開始、ならびにかなりの量のデータがストリーミングされた後
が、良好な箇所である。カバレッジ・コンテンツの性質は、単純で純粋なテキス
ト・メッセージ，静止画像，音声ファイル，短いビデオ・クリップなどでもよい
。カバレッジのタイプは、ストリーミングされるデータと整合性があるように選
択される。例えば、ビデオ・クリップは、ストリーミング音声用として適したカ
バレッジ・コンテンツではないが、ストリーミング長編ムービ用として適してい
る。
データ・ストリーミング・クライアント２０は、好まし
くは、データ・ストリーミング・クライアントによって要求された要求データを
格納するためのメモリ２４と、ギャップ・データを格納するためのメモリ２８と
によって構成される。また、データ・ストリーミング・クライアント２０は、デ
ータ・ストリーミング・クライアントへの要求データをサーバから要求し、サー
バから要求データおよび適切なギャップ・データを受信し、要求データを適切な
ギャップ・データから区別し、要求データを第１バッファ（２４）に格納し、適
切なギャップ・データを第２バッファ(２８)に格納するようにプログラミングさ
れたプロセッサ(２２，２６)によって構成される。理想的には、プロセッサは、
第１バッファのコンテンツが提示できるまで、第１バッファのコンテンツが満た
されるのを待つ間、第２バッファのコンテンツを提示するように、さらにプログ
ラミングされる。
クライアントは、データ・ストリームを受信し、カバレッジ・コンテンツを取
り除いて、これをローカル・カバレッジ・コンテンツ・バッファに保存する。次
に、クライアントは、通常のストリーミング機構と同様に、ストリーミング・デ
ータの受信，バッファおよび配信を行う。ストリーミング・バッファ（クライア
ント側にある）が空になると(あるいは、空に近くなると)、クライアントは、確
実な通常のストリーミング配信が継続できる程度にストリーミング・バッファが
再充填されるときまで、通常のストリ
ーミング出力をカバレッジ・コンテンツの適切な表現（クライアントのローカル
・カバレッジ・コンテンツ・バッファから取り出される）で置換する。なお、ク
ライアントのローカル・カバレッジ・コンテンツ・バッファ（第２バッファ２８
）は、サーバから来る、あるいはサーバからクライアントにストリーミングされ
るギャップ・データが不充分もしくは無い場合にクライアント側でローカルに提
供される、適切なギャップ・データで充填できる。
例えば、クライアントがサーバからムービを要求して、ストリーミングする場
合、カバレッジ・コンテンツは、ある製品の広告（多分、他のムービ）である一
つまたはそれ以上のグラフィックで構成されることがある。すなわち、プロセッ
サ26は、第２バッファのコンテンツを、第１バッファのコンテンツのフォーマッ
トと整合性のあるフォーマットに変換するようにプログラミングできる。ストリ
ーミング・バッファが非常に少なくなると、ストリーミング・データの配信の遅
延のために、クライアントはムービの提示を停止して、カバレッジ・コンテンツ
・グラフィックを（適切なビデオ・フォーマットにて）ユーザに提示する。スト
リーミング・データは、（望ましくは）着信し続け、ロほカル・ストリーミング
・バッファの再充填を開始する。これらのバッファがムービを継続するのに適切
な程度に再充填されると、クライアントはカバレッジ・コンテンツをムービで再
度置換し、通常のデータ・ストリーミング処理
に戻る。
もちろん、本発明の請求の範囲で、いくつかの変形例が考えられる。例えば、
本発明におけるギャップ・カバレッジ機構が可能なクライアントは、サーバから
適切なカバレッジ・コンテンツを受信しない場合に、広告などあらかじめ用意さ
れたカバレッジ・コンテンツ(canned coverage content)を含むことができる。
一般に、このあらかじめ用意されたカバレッジ・コンテンツは、クライアント側
でローカルに生成される。データ・ストリームは、最後の受信，サイクル，ある
いはサーバ側と調整した他の機構を含むさまざまなアルゴリズムに基づいて、ク
ライアントによって利用できる異なるカバレッジ・コンテンツ項目を含むことが
できる。さらに、データ・ストリーミング・プロトコルは、バッファが少ない場
合に、広告を挿入する適切な位置の「マーカー(markers)」を含むことができ、
それによりプログラムにおけるより適切なポイントで(例えば、ムービの幕間)、
広告挿入を行うことができる。クライアントのローカル・ストリーミング・バッ
ファが、リアル信号の提示が可能になる程度まで、充填されるのを待つ間の初期
遅延中に、広告を提示できる。本発明の範囲内の別の機能では、テキストとして
表現されるカバレッジ・コンテンツ素材を、必要に応じて、クライアントによっ
て音声またはビデオのいずれかあるいはその両方に変換できる。さらに、カバレ
ッジ・コンテンツまたはギャップ・データは、位置，
ザ嗜好,残りのバッテリ寿命あるいは他の条件に基づいて、クライアントによっ
てフィルタをかけることができる。すなわち、クライアント側のプロセッサは、
クライアントの位置，ユーザ嗜好および残りのバッテリ寿命（特に、クライアン
トが携帯装置の場合）などの条件に基づいて、第２バッファのコンテンツにフィ
ルタをかけるようにプログラミングできる。
第２図は、データ・ストリーミング・プロトコルにおいてギャップ・カバレッ
ジを提供するためのサーバ側での方法５０を示す。方法５０は、好ましくは、ス
テップ５２から開始し、ここでサーバは、要求データをクライアントにストリー
ミングするようにクライアントから要求を受信する。次に、ステップ５４におい
て、サーバはデータ・ストリームを設定・開始する。データ・ストリーミングの
設定・開始は、データ・ストリーム内に適切なギャップ・データが挿入されると
ころのマーカを与えることを含む。ステップ５６において、サーバは、データ・
ストリーム中の適切な時間でストリーミングできる適切なギャップ・データを選
択する。適切なギャップ・データは、特定の種類のデータ要求で送信されるよう
にプログラミングされるあらかじめ用意されたカバレッジ・データを含むことが
できる。次に、ステップ５８において、サーバは、好ましくはデータ・ストリー
ムの開始である所定の時間中に、あるいは大量のデータがすでに送信された後で
、適切なギャップ・データ
をフォーマット化し、送信する。最後に、ステップ６０において、サーバはクラ
イアントに要求データを送信し、完了する。
第３図および第４図は、クライアント側でデータ・ストリーミング・プロトコ
ルにおいて適切なギャップ・データを受信する方法７０および提示する方法９０
を示す。好ましくは、方法７０は、ステップ７２において要求データをクライア
ントにサーバからストリーミングすることを要求する段階と、次にステップ７４
において通常のストリーミング機構で一般に行われるようにしてデータ・ストリ
ームを設定・開始する段階とによって構成される。次にステップ７６において、
クライアントは、要求データおよび適切なギャップ・データをサーバから受信す
る。判定ブロック７８において、クライアントは要求データと適切なギャップ・
データとを区別する必要がある。判定ブロック７８において受信されたデータが
要求データである場合、この要求データはステップ８０において第１バッファに
格納される。判定ブロック７８において受信されたデータ適切なギャップ・デー
タである場合、この適切なギャップ・データはステップ８２において第２バッフ
ァに格納される。もちろん、方法７０は、データが受信されなくなるまで、ステ
ップ８４において更なるデータを探しつづける。
第４図を参照して、適切なギャップ・データを提示するための方法９０を示す
。ステップ９２において、クライア
ントは、ストリーミング・データの要求がサーバに送信されるまで待つ。サーバ
は、前述のように、要求を受信し、データをクライアントにストリーミングする
。ステップ９４において、クライアントは、クライアントのユーザへの提示を開
始するのに十分なデータになるまで、第１バッファすなわちローカル・ストリー
ミング・バッファが充填されるのを待つ。次に、ステップ９６において、方法は
、ローカル・ストリーミング・バッファからデータのブロックを取り出し、これ
をユーザへの提示のためにフォーマット化する。判定ブロック９８において、提
示が完了したかどうかについて判定が行われる。完了する場合、プロセスはステ
ップ１０６において終了する。提示が完了していない場合、判定ブロック１００
において別の問い合わせが行われ、ローカル・ストリーミング・バッファ（第１
バッファ）コンテンツがカットオフ・レベル以下であるかどうかを判定する。コ
ンテンツがカットオフ・レベル以下でない場合、ステップ９６で示すように、デ
ータの別のブロックがローカル・ストリーミング・バッファから取り出され、フ
ォーマット化される。コンテンツがカットオフ・レベル以下である場合、方法は
ステップ１０２に進み、ローカル・カバレッジ・コンテンツ・バッファ（第２バ
ッファ）からカバレッジ・コンテンツ（適切なギャップ・データ）を取得し、こ
のカバレッジ・コンテンツをフォーマット化して、提示する。なお、カバレッジ
・コンテンツをフォーマット化す
ることは、第２バッファのコンテンツを第１バッファのコンテンツのフォーマッ
トと整合性のあるフォーマットに変換することを含んでもよいことを理解された
い。再度、判定ブロック１０４において問い合わせが行われ、第１バッファのコ
ンテンツがカットオフ・レベル以上か、あるいは以下であるのかを判定する。ロ
ーカル・ストリーミング・バッファに十分なデータがある場合、方法はステップ
９６に戻る。ローカル・ストリーミング・バッファにおけるデータが不充分な場
合、方法はステップ１０２において更なるカバレッジ・コンテンツを取得する。
上記の説明は、一例に過ぎず、請求の範囲で規定する場合を除き、本発明をい
かなる点でも制限するものではない。DETAILED DESCRIPTION OF THE INVENTION
Method for gap coverage in a streaming protocol and
apparatus
Field of the invention
The present invention relates to communication protocols, and more particularly to data streaming.
・ Data content to client within gap when presenting protocol
A communication device and method that can be provided.
Background of the Invention
Internet Data Streaming Protocol or any data
When using a streaming protocol, a
There are often gaps or delays. Data can consist of text
But may also include video or audio material. These gaps are currently in use
Wasted, wasting user or viewer time,
You may lose interest.
World of the Internet for communicating voice, video or similar information
Applicable on Wide Web (WWW)
The first used data streaming protocol was a file containing data.
Server passed the file to the client. After receiving the entire file, click
The client plays or displays the file. This mechanism is extremely slow,
Often, it took a few minutes to be received by the client.
However, once the file is received, there are few pauses and gaps,
Was able to play back. “Data streaming” is particularly relevant for multimedia
Born to address this significant delay that occurs when receiving tents. Basic
Typically, data streaming divides real-time data into packets.
It works by sending this packet from the server to the client.
The client sends a large number of packets (the number of which will be
Buffer the delay (based on the expected delay) and the entire data set (video,
Playback of the data before receiving the audio or similar file). Data
During playback or presentation, the rest of the data is received. This mechanism is used by system users.
Significantly reduce the initial delay experienced by users.
However, this streaming mechanism introduces a new problem. That is,
Packets did not arrive in a timely manner as scheduled, and as a result
May occur. In other words, before the client starts presenting
Without buffering enough data, the client
Since the remaining data cannot be received quickly enough, the client will present it to the user.
There is no more data. Existing streaming mechanisms simply stop
, Leave the user waiting until enough data is available to continue the presentation
. RTSP (Real-Time Streaming Protocol) adopted by Real Audio
RTP (Real-Time Transport Protocol) IETF standard, etc.
'S existing data streaming mechanism works in much the same way as above. Follow
To take advantage of these gaps in streaming data delivery.
Need to be
BRIEF DESCRIPTION OF THE FIGURES
FIG. 1 is a block diagram of an Internet streaming protocol according to the present invention.
1 is a block diagram of a system for providing cap coverage. FIG.
FIG. 2 illustrates a gap in a data streaming server according to the present invention.
-A flowchart illustrating a method for providing coverage.
FIG. 3 illustrates a data streaming client receiver according to the present invention.
4 is a flowchart illustrating a method for receiving gap coverage.
FIG. 4 shows a data streaming client receiver according to the present invention.
Provide gap coverage
Is a flowchart showing a method for performing the above.
Detailed description
Real-time data 12 (video source, etc.) from server to client
The data streaming protocol used to communicate is
Enhanced to identify and communicate the content of the group. This new content
, "Coverage content" 14 or gap data
Which is probably some kind of advertisement. Details of the required enhancements can be found in the
Depends on the exact nature of the reaming protocol and coverage content
.
Referring to FIG. 1, the present invention relates to a data streaming protocol.
Figure 2 illustrates a system for providing gap coverage. Preferably, the system 10
Stores the requested data requested by the client and
A memory 15 for storing data and a processor 17. Like
Alternatively, the processor 17 may stream the requested data to the client.
Is programmed to receive a request from the client 20 for access. Also
, The processor 17 sets up and starts the streaming protocol.
Grammed. The processor 17 also includes a data streaming processor.
Select the appropriate gap data that can be streamed at a given time during the protocol
Wear. This predetermined time is preferably the start of a data stream. Further
Next, processor 17 formats the appropriate gap data.
When this is completed, the predetermined gap data can be transmitted during a predetermined time. Mochi
Of course, processor 17 preferably executes the query after the gap data has been transmitted.
It is programmed to send and complete the requested data to the client. Sir
Transmission of data between the server 16 and the client 20 is preferably via the Internet.
And over a data network 18 such as
The server sends the identified coverage content (i.e., advertisement), possibly
Insert several instances into the data stream at various points
You. Start of stream, as well as after a significant amount of data has been streamed
Is a good place. The nature of coverage content is simple and pure text
Messages, still images, audio files, short video clips, etc.
. Select the type of coverage to be consistent with the data being streamed.
Selected. For example, a video clip might be suitable for streaming audio.
Not a barrier content, but suitable for streaming feature-length movies
You.
Data streaming client 20 is preferred
The request data requested by the data streaming client.
A memory 24 for storing the gap data and a memory 28 for storing the gap data.
Composed of In addition, the data streaming client 20
Data streaming client requests data from the server,
Request data and appropriate gap data from the
The request data is stored in the first buffer (24) and distinguished from the gap data.
The second gap (28).
Processor (22, 26). Ideally, the processor
Until the contents of the first buffer can be presented, the contents of the first buffer are full.
While waiting for the content to be presented in the second buffer.
Rammed.
The client receives the data stream and retrieves the coverage content.
And save it in the local coverage content buffer. Next
In addition, the client sends the streaming data in the same way as a normal streaming mechanism.
It receives, buffers and distributes data. Streaming Buffer (Client
When the client is empty (or close to the sky), the client confirms that
Streaming buffer is large enough to continue
Normal storage until refill
Output to the appropriate representation of coverage content (client local
• Retrieved from the coverage content buffer). In addition,
Client's local coverage content buffer (second buffer 28)
) Comes from the server or is streamed from the server to the client
If there is insufficient or no gap data available, provide it locally on the client side.
Can be filled with the appropriate gap data provided.
For example, if a client requests a movie from a server and streams it
If the coverage content is an advertisement for one product (perhaps another movie)
It may consist of one or more graphics. That is, the processor
The server 26 formats the contents of the second buffer into the contents of the first buffer.
Can be programmed to convert to a format compatible with Story
Streaming buffer is too low, the delivery of streaming data may be delayed.
For the delay, the client stops presenting the movie and the coverage content
Present the graphic (in the appropriate video format) to the user. Strike
Reaming data will continue to arrive (preferably) and local streaming
-Start refilling the buffer. These buffers are appropriate for continuing the movie
Client reloads the coverage content with a movie
Normal data streaming processing
Return to
Of course, several modifications are possible within the scope of the claims of the invention. For example,
The client capable of the gap coverage mechanism in the present invention is a client from the server.
If you do not receive the appropriate coverage content,
And canned coverage content.
Generally, this pre-prepared coverage content is
Is generated locally. Data stream is last received, cycle is
Or based on various algorithms, including other mechanisms coordinated with the server side.
Includes different coverage content items available to clients
it can. In addition, data streaming protocols require less buffer space.
Where appropriate, you can include "markers" at the appropriate locations to insert the ad,
So at more appropriate points in the program (e.g. between movie breaks)
Ad insertion can be performed. Client's local streaming buffer
Initial while waiting for the camera to be filled to the extent that
During the delay, ads can be presented. Another feature within the scope of the present invention is as text.
The represented coverage content material can be used by the client as needed.
Can be converted to either audio or video or both. In addition, Kabale
Content or gap data is located,
Based on preferences, remaining battery life or other conditions
Can be filtered. That is, the processor on the client side
Client location, user preferences and remaining battery life (especially client
(If the mobile device is a mobile device).
Can be programmed to apply ruta.
FIG. 2 illustrates gap coverage in a data streaming protocol.
5 illustrates a server-side method 50 for providing a page. The method 50 preferably comprises a
Beginning at step 52, the server streams the requested data to the client.
Receive a request from a client to start Next, in step 54
Then, the server sets up and starts the data stream. Data streaming
Setting / starting is performed when appropriate gap data is inserted in the data stream.
Including providing roller markers. In step 56, the server sends the data
Choose the right gap data to stream at the right time in the stream
Select. Appropriate gap data should be transmitted in certain types of data requests.
May include pre-prepared coverage data programmed into
it can. Next, in step 58, the server preferably transmits the data stream.
During a predetermined time, which is the start of the system, or after a large amount of data has already been sent
, Appropriate gap data
Format and send. Finally, in step 60, the server
Send the requested data to the client and complete.
3 and 4 show the data streaming protocol on the client side.
Method 70 for receiving and presenting appropriate gap data at a file
Is shown. Preferably, the method 70 includes transmitting the requested data in step 72.
Requesting the client to stream from the server, and then step 74
Data streams as commonly done with normal streaming mechanisms in
And setting and starting the game. Next, in step 76,
The client receives the requested data and the appropriate gap data from the server
You. At decision block 78, the client compares the requested data with the appropriate gap
It is necessary to distinguish it from data. The data received at decision block 78 is
If so, this request data is stored in the first buffer in step 80.
Is stored. The appropriate gap data received at decision block 78
If so, the appropriate gap data is stored at step 82 in the second buffer.
Is stored in the Of course, method 70 continues until no data is received.
Continue to search for more data at step 84.
Referring to FIG. 4, a method 90 for presenting appropriate gap data is shown.
. In step 92, the client
The client waits until a request for streaming data is sent to the server. server
Receives the request and streams the data to the client, as described above
. In step 94, the client opens the presentation of the client to the user.
The first buffer, the local stream, until there is enough data to start
Wait for the mining buffer to fill. Next, in step 96, the method includes:
Fetches a block of data from the local streaming buffer,
Is formatted for presentation to the user. At decision block 98,
A determination is made as to whether the indication has been completed. If completed, the process
The process ends at step 106. If the presentation is not complete, decision block 100
Another query is made at the local streaming buffer (first
Buffer) Determine if content is below cutoff level. Ko
If the content is not below the cutoff level, as shown in step 96,
Another block of data is retrieved from the local streaming buffer and
Formatted. If the content is below the cutoff level, the method is
Proceeding to step 102, the local coverage content buffer (second buffer)
The coverage content (appropriate gap data) from
Format and present your coverage content. In addition, coverage
Format content
Formatting the contents of the second buffer with the contents of the first buffer
Understand that this may include converting to a format consistent with
No. Again, an inquiry is made in decision block 104 and the
Determine if the content is above or below the cutoff level. B
If there is enough data in the local streaming buffer, the method
Return to 96. Insufficient data in the local streaming buffer
If so, the method obtains additional coverage content at step 102.
The above description is merely an example, and the present invention is not described except as defined in the appended claims.
There are no restrictions in any way.