今回は、あまり余所のブログでは取り上げられていない領域識別子（identifier）に注目してみた。
CLBeaconRegionオブジェクトの生成時に指定するidentifier（日本語で言うと、識別子）は、領域の識別子である。これはそのアプリケーション内で自由に決められるものである。
CLBeaconRegionオブジェクトの初期化処理（initWith...）には、次の種類がある。
- - (id)initWithProximityUUID:(NSUUID *)proximityUUID identifier:(NSString *)identifier;
- - (id)initWithProximityUUID:(NSUUID *)proximityUUID major:(CLBeaconMajorValue)major identifier:(NSString *)identifier;
- - (id)initWithProximityUUID:(NSUUID *)proximityUUID major:(CLBeaconMajorValue)major minor:(CLBeaconMinorValue)minor identifier:(NSString *)identifier;
したがって、識別子をつけられる対象は、次のような組み合わせだけである。
組み合わせ
- proximityUUID
- proximityUUID、Major
- proximityUUID、Major、Minor
ここからわかること、および、実際に動かしてわかったことがある：
1. 同じUUIDを持つデバイスが複数あるときに、３階層のグルーピングが可能である
2. 異なる組み合わせには、同じ識別子を付けられない
（実際、同じ識別子で異なるUUIDのCLBeaconRegionオブジェクトを作ろうとすると、後から作ったオブジェクトで上書きされてしまう）
3. 同じ組み合わせに対して、異なる識別子が付けられる
２つ目はあまり意識されていないところだと思うが、重要である。例えば、いろんなメーカーから購入したiBeaconデバイスを寄せ集めて、ひとつの領域を監視したいとする。しかし、そのようなiBeaconデバイスの中には、UUIDが予め決められていて、購入者が変更できないものもあるかもしれない。そうなると、これらのデバイスすべてを、同じ領域を表すためには使えないことになる。（たいていのiBeaconは、購入後もアプリケーションからUUIDが変更できるようになっている。）
この識別子、使い方によっては非常におもしろいことができる。ひとつのiBeaconに近づいたとか離れたとかといった使い方は基本中の基本で、本質的な使い方は、文字通り、領域にはいったかどうかである。例えば、同じUUID、MajorをもつiBeaconが、下図のように輪っかになっている場合は、そのUUIDとMajorの組に対して付けた識別子は、その赤い輪っかの領域を表す領域識別子として使用することができる。
３つ目の性質に着目すれば、同じビーコンでも異なる領域として使用可能なので、次図のように同じビーコンの配置に対して、いくつもの異なる領域が考えられる。（ただし、この場合、異なるビーコンには同じ識別子が使えないので、識別子自体をURLのようなドメイン構造にする工夫が必要となる。図では、aグループ、bグループ、cグループとしている。どのビーコンも２つの領域に属している。）
.png){kind=tracking}
.png){kind=tracking}
.png){kind=tracking}
これは、iBeaconを社会インフラとして考えた場合、非常に柔軟に扱えることを意味している。たとえば、ある区域にiBeaconを均等に配置しておき、適切な識別子を与えただけで、あるルートを表す領域が取得でき、iBeaconの電波を拾って道案内を行うなど、低コストなナビゲーションシステムが実現できる。
例えば、次の図のように大阪駅構内にiBeaconを配置しておく、御堂筋北口から中央きっぷ売り場への道順を表す領域（赤枠）や、御堂筋南口から高速バスターミナルまでの道順を表す領域（青枠）など、おなじiBeaconインフラに対して、ことなる領域を定義することが可能となる。
領域の識別子をうまく使うことが、柔軟で低コストなiBeaconサービスを提供するための必須条件であることは間違いないだろう。
.jpg)
