The advertisement packet your beacons send can contain custom data. However the space is very limited, around 31 bytes. About 16bytes of it goes to the 128bit "service UUID" of your beacon. The structure of the packet is defined by the bluetooth spec and it does have some overhead, so I'm not sure how much is actually available for the custom data.
The service UUID is an identifier which your iphone app will search for. The idea that each service has a unique identifier, so if an app wants to find heart rate monitors, it will scan for the heart rate monitor uuid. In iOS you can even do a wildcard scan, and it will return any ble advertisements it can find, regardless of the services it has. It is however recommended by Apple guidelines that you specify the service UUID.
There is no requirement for pairing in order to receive the advertisment packets from the beacon. There is also no theoretical limit that would prevent that the beacons couldn't be found, given an infinite amount of time.
I haven't heard anyone putting 500 advertising BLE beacons in the range of an iPhone to see how many it can detect. With 500 beacons advertising simultaneously there will be a lot of collisions between packets. This could theoretically be calculated with knowing the advertisement interval.
The iPhone scan window (how long the channels are actively listened to) and scan interval (how often the scanning window is entered) cannot be adjusted, isn't documented and cannot be relied to remain the same between versions. This means that there isn't a way to really calculate how the advertisements will be found.
There's some recommendations published by Apple about advertising: https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf
Oh, and by default iOS will filter the results so you get one notification per scan session, per beacon. You can set the "allow duplicates" option in the scan to get multiple notifications per scan session for each beacon if this is needed, but again, apple doesn't recommend it.
If you end up testing this with 500 beacons, or even > 10, I thin a lot of people would be interested in your results. I personally would also appreciate hearing about your experiences.
The HC-03/05 are Bluetooth modules were designed for serial communication. Note that these implement the classic version of the Bluetooth stack, not the Low Energy 4.0+ version of the standard,
By using two complementary modules, one master and one slave, you will be able to pair them and connect two independent serial streams (full duplex), one stream in the direction master to slave and the other stream in the direction slave to master.
An alternative to the previous is connecting another device (for instance, a mobile or a PC bluetooth dongle) to one of these modules which will act as master/slave.
The AT command set available for these modules, as far as the documentation goes, does not allow multiplexing: sending multiple streams (more than one), simultaneously, in a certain direction (for instance, master to slave).
A possible solution is to do the multiplexing yourself in either end of the communication, not in the bluetooth module, but outside of it,
- Let's say you connect a mobile application (running Android or iOS) with one of these modules. You could easily create your own message format for the serial communication, prepending an integer number which will indicate the number of channel.
A simplistic and very compact message format suitable for serial communications is the TLV (Type-Length-Value), which you may use for such an application,
http://en.wikipedia.org/wiki/Type-length-value
Best Answer
If there were just two channels (one for uplink, one for downlink) you could only connect to one device at a time, and you could not operate multiple Bluetooth Low Energy devices simultaneously (unless some arbitration system was implemented where devices would take turns at transmitting at the expense of data rate).
Multiple channels not only permit multiple BLE links to operate concurrently in the same area, they also enable the use of frequency hopping, where all BLE devices rapidly change channels in a predetermined pattern (direct sequence spread spectrum). This rapid switching of channels makes it difficult for any single source of interference to jam any of the data links.