Music website

A. Business case

Many music websites list and sell music CD, but they didn’t allow users to listen to a short demo clips in order to figure out if they knew and liked those songs before making a purchase.

Making CD music and shipping fees also added extra cost to music buyers.

Most of people listen to music over radio. They didn’t even know the title of a song. How could they know which songs to select? Some people preferred a few songs in a CD, but they have to purchase the entire disk, so many opted to listen to free music videos on YouTube.

Most of CD players in cars or at home supports mp3 player. Therefore people could select all favorite songs saved in a USB keys. A 64GB USB key could store hundreds of favorite songs for a long car trip without exchanging music CD.

Don’t forget that buyers could use any free software to convert music in a CD to mp3 files anyway. Thus selling CD didn’t prevent pirate CD or mp3.

Why didn’t music retailers let potential buyers listen to a short demo of a song in form of mp3 before making a decision?

B. Develop a website with demo songs

It's not hard to develop a web site to let users listen to 1/3 of a mp3 file, and decide to buy (add to cart) or not.

1. Convert all songs into mp3 files stored in sales directory

2. Use special mp3 software to cut the last 2/3 excluding end of file. Save these demo files associated to the original mp3 in the other folders in database.

3. On the web site, only shows partial demo mp3 files for users listening to.

4. If they wanted to buy, they could click on a button below that song to add it to shopping cart.

5. When user selected a song to buy and add to cart, web site saved the pointer of that partial mp3 file, which pointed to the original mp3 file in the another folder.

6. When users check out and pay; they also need to create an account with username & password for re-download. Show them a list of purchased original songs in mp3 for downloading. Those songs are stored in different folder(s) than the demo mp3 songs.

7. In the download page, give each user a reference number with their username and password. So, the can open the download page and download those again within 1 hour of payment with reference number, their username and password. This helps users with issues of home Internet interrupting their downloads, but prevent users shared the reference number for illegal downloads.

8. You can organize songs of an album in a folder, i.e. each album is in a folder. The only thing was the pointer from demo songs to original songs.

Example of pointers in database

Column #1 (demo)                            Column #2 (original songs)

d:\BangTam\Toivannho.mp3         f:\BangTam\TLTM\Toivannho.mp3

d:\DTLuan\Toivannho.mp3            f:\BangTam\TLTM\Toivannho.mp3

This is a duet song by both Bang Tam & Dang The Luan, but buyers may search under names of Bang Tam or Dang The Luan. However both showed to the same folders for demo and original songs.

So on the demo web page, it could play d:\BangTam\Toivannho.mp3 instead of d:\DTLuan\Toivannho.mp3 OR both pointed to the same file in database. It's about how you organize your database and folders as well as your website.

C. Search lyrics of a song

Most music listeners over the radio would likely remember a few phrases of a song. Therefore, storing lyrics of all listed songs for users to search would also be a good option.

Each search result, i.e. selected lyrics, would include a link to its demo song, so users could verify that. Of course, users could add that song in to their shopping cart as usual.

Telecom features used in military telecom model v1.23

A.       Version History

Date	Revision	Description	Author
2018-11-15	A	Documents created with features in subsequent revisions	Vinh Nguyen canvinh@gmail.com
2020-09-10	PB1	Added section 35 for number portability used by Telco or subscriber relocation	Vinh Nguyen
2020-09-11	PB2	Update section 35 for an option to use subscriber credentials replacing PIN code	Vinh Nguyen
2021-07-12	PB3	Adding section 36 for handling of military mobile phone also registered as a VoIP phone	Vinh Nguyen
2022-04-05	PB4	Adding section 37 for handling phone calls using satellite networks	Vinh Nguyen
2022-12-23	PB5	Add some clarification in the section 37	Vinh Nguyen

B. System Descriptions

1. Mobile users access telecom network

Figure 1. Protocols between a mobile phone, visiting RBS box, visiting server, and home server

Figure 1.1. A visitor is calling a user in his home zone

As shown in figure 1 & figure 1.1, the mobile station is required to contact his home server for a registration or placing a call in a visiting area or zone. The MS1’s home server authorizes roaming calls for MS1. The diagram didn’t show the authorization request for MS2 by the RBS server, but RBS simply queries local Subscriber Location server (described later) to get the home servers for both MS1 and MS2. In the figure 1.1, MS2 is located in the home of MS1. Both MS1 and MS2 are authorized by their home server.

The message Authorization Request includes both calling MS1 number and called MS2 number is for record, because MS2 could be located in another zone.

The message Authorizing roaming calls for MS1 + Orig node + called MS2 is a standard message. Orig node (server IP of called party or calling party) could be any central server, i.e. same as home sever of MS1 or another server.

The home base would pre-authorize a call and accept “call duration” for its subscriber reported by a visiting central server.

The home server could allow or reject call placed by its mobile users. Usually a rejection message could be tailored to inform user about its decision.

Figure 2. Process to figure out home server of a visitor with Subscriber Location’s database

1.1 Police roaming

Figure 2 showed the process to figure out the home central server of a visitor by an RBS box (Radio Base Station server). The subscriber location’s database would store country code, area code plus NPA and number (if needed) associated with a server’s IP address, thus the RBS server could send a request to the mobile user’s home server based on the associated IP.

This scenario is useful for police as they shared RBS boxes for city police, provincial (state) police, and RCMP (federal police). By sharing RBS boxes coupled with RBS to provide airwaves, police could save money and allow policer officers roaming across country freely.

However, any initial registration or calls in a visiting area or shared RBS would be first routed to its home central servers for authorization. This helps to improve ownership of mobile phones, monitored unauthorized network’s access, and lost mobile phones. 

The visiting server doesn’t have information of a visitor until the home server authorized and agreed.

Following telecom standard, when a mobile phone roams from an RBS to a target RBS, it will perform a registration with the target RBS. The target RBS would request registration authorization from home server of the mobile phone. If the home server authorized its subscriber’s roaming in that RBS, it would send an authorization message to that target RBS, and also send a message to the previous RBS to cancel authorized record of its mobile phone user.

1.2 Telco (telecom operator) subscribers roaming

For telco, this is also useful for some small telecom operator (small town) that didn’t have roaming agreement with other larger telco. So, telco are able to control roaming ability of its subscribers.

1.3 Long distance

This protocol is also allowed home server to prohibit its subscribers making long distance calls from a remote location without enough fund in his account.

Delivery of a call to a long distance location is not discussed in this diagram.

1.4 Sharing or sub-lease networks by telecom operator

This protocol allows a large telecom operator with licensed spectrum to sub-lease their air time to a contractor. The contractor only needs to invest in a pair of central server. The main telecom operator would manage all subscribers’ phone numbers in the Subscriber Location database.

2. Same phone number placed calls unreasonably by 2 users

This is a fraudulent case as the same mobile user could not place a call in Europe after placing call in New York 1 minute earlier.

This could be detected by an algorithm to figure out distance of the places, where calls occurred, between calls recorded in system. The easiest way would be an estimate distance between cities. However, using distance between RBS would provide a better estimate. The only issue was “portability of RBS” that would require update in database, if RBS relocated.

3. Two phone numbers and one mobile station

3.1 US Military

This scenario is applicable to a national military with worldwide military bases such as US military. For example, US have a military base in Japan and US military officers visited this base sometimes for a few days.

To make management of local number easily, US military in Japan could subscribe to a few local numbers and reserve those for its visitors.

·        Associated a reserved local phone number to its visitor

·        The visitor could use his US phone and place call normally to a US’s RBS to a Japanese local phone number

·         System would analyze the called number, and know it’s a local call

·        System would replace the visitor phone number with that local number and send out to the called party

·        The return message to the system would be translate from that reserved local number to the visitor mobile phone number.

·        Calls would be delivered to the visitor via the RBS as usual.

For call number display, system would simply display “US Military” for all visitors placing local calls.

After the visitor left the base, that reserved phone number is released. All calls to that number would be routed to receptionist or an answering machine. The answering message could be as generic as “This phone number is not used at the moment. Please contact local receptionist at XXX-YYY-ZZZZ, if needed.”

3.2 Telecom operators

People used 2 separate numbers or SIM cards, one for personal calls, and one for business calls.

Currently users have to switch SIM cards in their phone.

They could use 2 separate dial pads and enter SIM information such as serial numbers on dial pads, i.e. a dial pad for business and other for personal use.

4. Call to a visitor

Figure 3. Call delivery to a visitor authorized by its home base

As shown in figure 3, the home base delivers call from MS2 to MS1 visiting in another zone. This scenario and scenarios described in figure 1.1 are similar by letting the visiting RBS server to request a registration, call from, or call to a visitor. The process to authorize a subscriber in a visiting node is the same, and to handle calls from its subscriber and to deliver calls to its subscriber similar. It’s easier in software development and trouble shooting.

The scenarios described in figure 1, 2, and 3 are not included in telecommunication standards.

5. Customize dynamic encryption between each military base or each city for police

There is a table in database to list each military base associated to a directory or folder storing encryption used for communications between them. When a user placed a call or communicated by a computer to another base, proper encryption in associated folder would be used.

If communication between 2 bases leaked, IT staff of those bases only needed to change encryption used between them in its folder, i.e. only 2 bases.

This could be done in the gateways.

6. International Call Delivery

This is a private military network, thus they can negotiate roaming agreement between themselves. For example, call from a US military officer to a Canadian military officer could be routed from the US central server through a designated Internet Gateway to the nearest Canadian central server, where the originating US call is delivered.

To make management of common encryption easier, USA should have several Internet Gateways. Each gateway would be equipped with different encryption. For example, calls to Canada would be routed through a gateway in Chicago to Canada’s Internet Gateway in Ontario. Calls to Latin America would be routed through a gateway in California. Therefore, if communication between USA and Canada leaked, the only encryption between Chicago & Ontario needed to be updated.

7. Subscriber Location server

Since there are too many subscribers in a country for telecom operators to manage in a server, i.e. query a huge database table stored all subscribers’ phone numbers, which could be several tens of millions records. By the way this is not a problem for military or police in a country, because they have fewer subscribers.

To make database table smaller and distribute tasks among Subscriber Location servers and its databases, each state (province) would store its internal subscribers by full numbers as the area codes and NPA codes were a mess, i.e. unable to distinguish a location of a subscriber based on a phone number. Each internal phone number would be associated with the IP of its home central server, e.g. a city or a base.

Other state’s (province) phones would only be identified with area codes in the database table. If a visitor came from another state, the RBS queries its internal Subscriber Location server as usual. If the Subscriber Location server identified the “queried” number with that area code was out of state, so it would query the Subscriber Location server of that state for the IP of the visitor’s central server (visitor phone number was included). Upon receiving the home server's IP, it returns the result to the requesting RBS. The process is back to normal.

8. Prepaid long distance call

Figure 4. Process to handle a subscriber with prepaid long distance account

As shown in figure 4, the home center server would keep track and manage prepaid accounts especially in international roaming. The remaining minutes roaming calls would be sent by the home server to the serving RBS server, and finally delivered to its subscriber by the serving RBS.

The personalized disconnect message would be relayed to its subscriber by the RBS server.

9. Military deployment without Subscriber Location server

Figure 5. The visiting server requests subscriber’s home server for permission instead of RBS

In case of military deployment, station space is limited. Mobile subscribers or military personnel would contact each other in the same location or commanders at the central server most of the time. There is no need to deploy a Subscriber Location server. The RBS would be configured to request registration, call from, or call delivery permissions directly to its local central server, i.e. by pass the usual steps with a Subscriber Location server. All long distance calls would be handled by the central server connecting with other servers via its satellite gateway as usual.

Currently military plans to share its telecom network with federal employees. The military network will cover the entire country. However there are no federal offices in some states, thus Location Server is not needed. The (special configured) RBS would request registration, call delivery to a subscriber through its local central server directly. The visiting central server would perform the request for permissions of registration and call deliver to visitor's home server. Any central server has a database of telecom network anyway. The message would include its OPC (sender IP) and RBS’s IP to differentiate this request and usual request by an RBS. By the way, a pair (mirror servers) of Subscriber Location server is not very expensive, thus having its installed make configuration simpler. IT staff from a state can figure out the configuration of a telecom system in another state easily, i.e. no exception.

The only change in the RBS to support no-Subscriber Location server could be to replace the IP address of the Subscriber Location Server with the IP address of the visiting central server for permissions of registration and call delivery for a mobile subscriber. The visiting central server would have similar codes (which were developed for RBS communicating with a Subscriber Location server) as the RBS with its own IP address as the sender.

10. Originating long distance charges

Each country should use a different frequency than other countries to make hacking activities harder. Therefore a US military’s mobile phone may not be able to place a call in Canada’s RBS.

Since US military and Canadian military will deploy this telecom system nationwide, calls from a US officer in USA to any Canadian phone numbers including Canadian military numbers would be free of charges, and vice versa.

Each military phone has 2 dial pads, i.e. one for business with voice channel and one for personal use with VoLTE or VoIP over data channel. 

Business calls should be placed on the business dial pad, and will be routed to any locations around the world as long as there was a telephony system there. To minimize military expense, long distance calls would be routed through worldwide military networks first, and then connected to the closest telecom network, if not covered by this military telecom system.

Business calls used special RBS voice packets, i.e. not a standard mobile phone voice. At the beginning this telecom system is only intended for military used, so there was no need to convert RBS voice to popular voice standard such as ISUP. There is a new requirement to setup calls to external telecom operators, thus based on the dialed number, the originating central server would convert its RBS voice to a standard mobile telephony’s voice before sending messages out, so public telecom network could understand.

·        The military telecom network at remote location may not have the voice conversion mechanism, thus it’s better to get the originating node performed this task.

·        Any nodes must know if its originated call will be routed to an external telecom network and voice standards used over there.

·        It is easier for the originating node to convert RBS voice to an external node’s voice and convert back returned voice packets into RBS voice.

·        The connecting nodes only transfer voice packets by connecting to its local public telecom network’s voice trunks.

I heard that there was a voice packet’s standard with patent expired 50 years ago. This voice packet format is supported by worldwide telecom operators. Thus RBS voice packets would be converted into this voice format by the originating node, if conversation terminated in external telecom network.

Personal calls are only allowed to all free long distance calls, e.g. calls to Canada or USA. This could be implemented in any central server with a special class, e.g. 

·        LD-0:  is a default class. Phone is disabled.

·        LD-1: free calls to USA, Canada, Russia, and UK.

·        LD-2: system would query a table to return result to determine if it’s a free long distance call based on the dialled number, i.e. could be free calls to many countries.

Military personnel doesn’t have huge paid checks, thus allowing only free calls would be a better option.

11. Satellite Internet

There are many companies and organizations have satellites in orbits including USA, Canada, Russia, Europe, and Israel. Some of those satellite networks are strictly for military use. However some of them were phased out and replaced by modern satellites. We could update those obsolete satellites to provide Internet to remote zones with reasonable monthly fees.

Remote Internet service providers (ISP) needs to do followings

·        Purchase a satellite gateway used by those obsolete satellites.

·        Connect their main Internet server to a satellite gateway by using its standard protocol (input and output)

·        That local satellite would route the request based on destination IP address to a designated satellite in a country or nearest country.

·        On the ground there should be designated central server equipped with a satellite gateway to receive data and relay to the central server for processing.

·        The central server would route those Internet contents to its Internet gateway to deliver messages to final destination as usual.

·        To differentiate Internet used by local military personnel, the ISP must pay monthly fee to that base for a separate Internet line at its Internet gateway in addition to monthly fees in using their satellites. Because of this, there should be only one dedicated satellite and a base to offer this Internet service. Another important reason was that you didn’t want irrelevant traffic (not military traffic) to an important base such as military head quarter, satellite control hub, and busy traffic base (New York City). As soon as messages got to a dedicated base, traffic will be routed using regular fiber optical network, i.e. very fast.

There are not many satellites in the sky, and space agency knew all existing or new satellites in orbits. Therefore, space agencies could implement a routing network for satellites from different national providers to transfer data effectively for Internet as well as phone communications.

The satellite networks must support 2 routing methods, i.e. one for military use and the other for public. This could be done as follows

11.1 Indicators

Each satellite gateway could be configured with 2 indicators:

·        1^st indicator for owner of the gateway (satellite network owner) such as US Military or Canadian Military. This indicator could reserve 2 bytes of data.

·        2^nd indicator identifies users of that gateway in case US military loaned that gateway for Canadian military use in a short period of time. Users could also be a public ISP. This indicator could reserve 3 bytes of data, because there are many ISP in remote areas. By the way, each individual could apply for a satellite gateway for personal use in his vacation home, but it’s expensive.

11.2 Router 

Router would route military users’ traffic to the (nearest) destination base based on destination IP address using appropriate satellite networks.

All public users’ traffic would be routed to a dedicated base in each country. 

11.3 Routing by satellite networks

There are fewer satellites in a network than number of landline ISP or nodes, so satellite providers could team up to develop a special routing table for data transfer, i.e. kind of hard coded in database. For example, with knowledge of sender IP, destination IP, users, etc. There are special columns in database such as column #1 for originating node, #2 transfer node (could be another network, e.g. from USA to Russia), #3 destination node (could be a dedicated landline node). If a new satellite is in orbit, satellite providers only need to look at their map of all satellites and change routing database accordingly. There are not many new satellites per decade anyway.

12. Gateway communications with a central server

To make system effective and lift loads from the central server, the satellite gateway, Internet gateway, and WLAN hub should support the followings (RBS server has supported this)

·        The first packet came to a gateway, which could be a voice or Internet packet

·        Gateway would communicate with the central server including that packet

·        Central server would analyze that packet, and decide where that packet should go, e.g. Internet gateway or RBS server

·        The central server sends its decision to the requested gateway.

·        That gateway would then route that packet and subsequent packets to correct gateway or RBS server directly. A message to a gateway could include a series of packets, so the gateway must know which the last packet is.

·        The next time, messages from the same sender IP (OPC) and destination IP would trigger the same analyzing process.

A central server would normally log data concerning Internet usage and call usage by users. Thus by the end of Internet or call messages, a gateway should send the server the amount of data transfer.

The telecom system has standard protocol to inform server the end of conversation, i.e. duration of calls. Thus voice communication is not needed unless operators want a statistic for amount of data used in voice communications per user or entire system.

A statistic report, which could also be used for billings, should include timestamp, sender, receiver, Internet or voice, gateways involved in communications, amount of data transfer, etc. Each RBS server should also be considered as a gateway as it could send voice packets to other RBS servers or other gateways. Operators could generate a final monthly report for each user, entire base, voice data transfer, Internet data transfer, etc.

13. Sharing RBS servers among city police in Greater Toronto Area (GTA)

Figure 6. Diagram for a configuration of telecom network for GTA police

To optimize telecom system used by city police and provincial police, city police in Toronto, Markham, Ajax, Mississauga, etc. share RBS servers at specific locations. Figure 6 shows a sample of telecom network used in GTA.

An RBS server would query Subscriber Location server for home server of a mobile user, and then request its home central server to setup a call. There are many central servers connecting to an RBS in this case, thus provincial police (OPP) would be designated as the home central server for all RBS servers within GTA. 

To make similarity with other diagrams, OPP home server is like a visiting central server, and other city police servers operated as home central servers. From telco point of view, OPP home server is like the main server owned spectrum and RBS servers, other city police servers are like sub-contracting servers selling telephony services.

An RBS could have a table of servers' IP addresses, which could be used as GTA home central servers. OPP home server would be the first choice, and then other central servers in GTA in order. This helps uninterrupted operations of GTA telecom system in case OPP central server goes down.

Other provincial/city telecom networks would recognize OPP central server as the home server of all GTA users. Other lower priority central servers in GTA should also be included in other provincial/city telecom networks as possible GTA home servers.

If GTA police wanted, they could setup encryption folders in the same way as military network for communications between central servers in GTA. Other remote cities such as Peterborough, Kingston, or Montreal should always have separate encryption folders similar to a remote military base.

Ontario Police and Quebec Police should dedicate 2 nodes for inter-provincial exchanged messages. This is similar to military network in international roaming.

If (area code 416 or 905) Markham user (GTA) visited Kingston (remote city) and registered there, Kingston serving RBS Box would send a query request to its Subscriber Location server for the home server IP of that GTA user. Kingston’s Location Server would send a request to GTA’s Location Server (416 and 905 area codes) to obtain the home server IP of that Markham user and return it to Kingston’s Subscriber Location server, which in turn relayed information to the serving RBS. The serving RBS would contact Markham as the home server. Process would be similar to scenario of a visitor registered or made calls, which were described in other sections. [This scenario is probably the efficient way to deliver a call to a GTA user; however, telco may require call case setup by home/main server instead of a sub-contract server for charging capability.] See the charging scenarios’ diagrams for details of routing or setting up a call.

14. Mobile user hands off from an RBS to another RBS

Figure 7. Example of adjacent cells and a border cell

Sometime mobile user moved far away from a serving RBS that made communicating signals weak. Another RBS could provide stronger signals to this moving mobile user. Therefore hand off occurred to transfer current serving RBS to the better signal RBS.

As shown in figure 7, RBS Box 1 and RBS Box 2 controlling RBSs covering wireless signals in 2 areas are adjacent cells belonging to central server 1. The RBS Box 3 with RBS covers another area, and it is a border cell for RBS 1 and RBS 2.

The example showed cell structure used in TDMA standard. Handoff in TDMA doesn’t need any code as in CDMA standard. CDMA uses unique code to cover a cell site. Therefore any area covered by a code could be declared as a cell. Then system could perform handoff without using any code as in CDMA.

14.1 Inter-Node Hand off

This case the mobile user is moving from a serving RBS to another RBS belonging to another network controlled by a different central server. Usually a central server knows its RBS locations as well as adjacent RBS, i.e. adjacent cells and border cells. Those cells are declared in a central server.

In case of visitor: the visiting server measured/monitored signal strength between RBS and mobile user in a call, and if it dropped below a threshold. The serving central server would communicate with the target RBS for possible hand off because of its stronger signal strength. In this case, the target RBS server would contact user’s home server for authorization of the current call’s hand off as a visiting server. The process of authorizing subscriber is the same as roaming in a visiting node. If authorized, the target RBS handles that call continuously.

For billing purpose, the serving node would sent its part of call handling from beginning to time of handing off user to the target node, which bills the second half of that call.

14.2 Intra hand off

This case the mobile user is moving from a serving RBS to another RBS belonging to the same network controlled by a central server, e.g. changing from RBS 1 to RBS 2.

In case of visitor, the visiting server doesn’t need to inform his home server for roaming authorization of the current call’s handoff. However, the target RBS server should inform MS’s home server about its IP address in order for possible incoming calls to this MS in between current conversation. This could be a registration message after handoff performed successfully.

15. Paging and Multi-Node Paging (MNP)

This is a feature in mobile telephony network used in TDMA standard to page a mobile user in its covered areas (adjacent cells) as well as border cells to answer a call before reserving a voice channel for that user. MNP is similar to a feature called Multi-Exchange Paging (MEP) in TDMA standard. However each exchange is called a node in computer network, thus it is called MNP for easy understanding.

Referred to figure 7, each network knows its cell cites (adjacent cells) as well as its border cells. A mobile station (MS) is supposed to register to an RBS before making or receiving a phone call.

15.1 Paging

In case of a visitor, its home server informs the visiting exchange about its acceptance of charging. The serving RBS keeps track of all registered visitors or local mobile users in its database. User’s home central server also keeps track of the serving RBS’s IP address for its subscribers, so it can contact the right RBS in case of call delivery.

·        If a (visitor) user placed a call, during requesting call setup as in figure 1.1, the RBS also inform its central server about the presence of the mobile phone during a request to set up a call

·        In case of call delivery to a visitor as shown in figure 3 user’s home server would inform the serving RBS to request its central server to setup a call. In the request to setup a call, the serving RBS would also inform its home central server about the location or cell site of this mobile user.

15.2 Multi-Node Paging

Assuming that any MS would contact a serving RBS periodically to inform its presence (or registration), thus if an RBS didn’t receive that periodic beacon or registration, the MS is out of range. The RBS would remove (location) record of that mobile station.

MNP occurs when a mobile phone moved from a cell site (RBS1) to another cell site, but hasn’t registered yet there (MS1 is out of RBS1 range), but a call delivery happened in between. The user’s home server still has record about this serving RBS1, but the MS’s location record in RBS1 server was removed.

As shown in figure 3, upon receiving the “Request to setup call delivery” or “Routing Request” for MS1, recorded RBS1 would send a Request for paging MS1 to its home central server. The central server would order paging of MS1 to all adjacent cells of RBS1 as well as its border cells. There are 2 cases

·        MS1 answers paging from RBS2, which is in the network as RBS1. The RBS2 would request call setup to its home server as usual.

·        MS1 answers paging from RBS3, which is a border cell. The RBS3 would check IP of MS1’s home server from Subscriber Location server in order to get authorization. After authorizing task, RBS3 would request its home server to setup call delivery to MS1.

The above procedures have included “authorization” and regular paging process. The case of using MNP is very rare.

16. Some scenarios for call delivery to a visitor

Figure 8. A visitor calls a user at another node

The purpose of including Originating (Orig) node is for billing and setup call conversation.  Sometime the originating node is not the same as the home base of a visitor.  The information of originating node, visitor’s home base, or calling party’s node IP could be included in Request for call setup by an RBS too.

An RBS should include information about calling party, called party, and other data such as originating node IP, terminating node IP while setting up a call in request for setup call to its home server. Some information was from Subscriber Location server, originating RBS server, originating visitor’s home server, etc. depending on each call scenario. This helps its central server to match data in order to prevent frauds.

Figure 9. A user from another node calls a visitor

In call’s scenarios above, there could be short cut or optimized process to set up a call. However, by keeping the process similar with each other would shorten development time by reusing codes or subsystems. It’s also easier to add more features and trouble shooting in the future.

17. Registration in special cases

17.1 Overlapping cell’s coverage

Sometime a mobile station is hovering in an overlapping cell’s coverage, thus it would attempt to register in both RBSs periodically. A registration message would include signal strength when it reported to the mobile user’s home base. The home base would keep track and reject the registration with lower signal strength. In rejection message to the visiting server, the reason was included and relayed to the MS. This helps the visiting server to redo cell planning properly.

17.2 Intra handoff

The target RBS handling of the roaming mobile station would send a registration message request to visitor’s home page to handle the call after successful handoff. Roaming charge’s permission was not required for the same node. The home base would authorize the registration as usual, and the target RBS relayed it to the MS. It’s up to the MS to handle this registration message while handling call’s conversation.

The reason was simple as the home base keeps track of serving RBS location for its subscriber in order to deliver a call. If the target RBS or MS didn’t perform a registration for the mobile user after a successful handoff, the serving server would perform an MNP if there was another call request to this subscriber, i.e. its home server was not updated with latest serving RBS IP. It would be a better option for the MS to trigger a registration request to make the registration sequence completed.

17.3 Visiting node with registration messages

At the beginning, we wanted to keep Rejection of roaming and registration anonymous to a visiting server. However the visiting node needs to know issues about its cell planning as well as to avoid performing MNP all the time, which wastes processing power of all RBS in adjacent cells and border cells. Therefore the home base of a visitor will inform the visiting server of its decision in rejection of call or registration of its subscriber.

18. GPS Functionality

Having GPS function on a mobile phone is very useful for many scenarios, e.g. commanders know the positions of their troops. They could guide troops to avoid some areas based on GPS and local maps. GPS could also be used to estimate distance between calls, i.e. movement of mobile users to home central server as well as detecting frauds (1 phone number but 2 users).

However GPS involved the use of satellite network, which covers a large area with their signals. This means signals could be picked up and decrypted by the other sides about troops’ positions.

Currently mobile phones are hacked with something called SS7 hack. This releases positions and conversation of mobile users. We cannot tell if hackers could turn GPS on or off by looking at the mobile phone’s user interface or indicator.

GPS is useful, but it must be secured first before deploying it on mobile phones.

19. Miscellaneous notes about the system development

The original design was a single RBS plus an RBS box for military deployment using mobile phones. To minimize the cost of system development, 5G RBS equipped with military frequency was chosen. The RBS box is like a simple MSC. The RAN is included in an RBS to save space. The RAN input and output is then connected to the RBS box to provide Internet or data communications.

Since RBS box was used, we selected IP as a communication method for the entire network instead of standards used in wireless telecom. That’s why somebody said that we invented IP telephony.

As system evolved for supporting military base’s communications, a central server was included to function as an MSC, HLR, and SCP/IN coordinating tasks between many RBS boxes. This scenario is better than the current peer-to-peer system, because it’s easier in design, trouble shooting, and maintenance. We developed our design based on all parties’ concerns and avoided making system complicated, because buying the existing MSC, HLR, and SCP/IN could be less expensive and more stable, i.e. the existing system had been used and tested for decades.

The system was kept at simple level with telephony functionality, so telco could use this system in rural areas.

As US military was involved and they have many deployment scenarios such as battle fields, worldwide military bases, navy ships, US bases, etc. The use of satellite network and WLAN was included in network design. At first all key components are stationed within a LAN with RBS Box connecting to the LAN by private cables to provide better security.

This telecom system is also used by military of other countries with fewer communication gateways.

Police was in the picture in later design stage, and they have less demand in security, thus having RBS boxes connecting to its central server by Internet lines was selected. Of course, military could use the same settings, if it’s more secured than other communication methods. To save police money, police would share RBS and its servers with each other across country. Therefore, system design considered a few scenarios to support this configuration.

All communication signals would be encrypted dynamically to enhance security.

In brief system was designed with many telecom features, so we would select current telecom design in the market, and update those to fit in our design. Our design must support all system components, and a standalone RBS box.

TDMA (ANSI-41) is a good network standard, thus we have used a lot of its design.

Military in many countries and police will deploy this telecom system, thus this is a private system. Any telco, organizations, governments or private organization, which wants to use this system, must get permissions from the international military committee including US Military. 

20. International military deployment

Let assume that USA, Canada, England, and Germany deployed military together at a location, but each country commanded their military fleet.

In case of different frequencies for telecommunications were used by each military, US military could deploy a few RBS and lend mobile phones to each team in Canada, England, and Germany.

·        Each country would have phones programmed with their own country code and area code.

·        Each country would deploy their central servers connected to the each RBS by WLAN, cable, or satellite.

·        Each RBS box equipped with network card, WLAN card or satellite adaptor would configure to recognize country codes and area codes in order to dispatch phone calls to correct central server.

·        Canada and USA have the same country code, thus RBS Box must analyze area codes in addition to country code.

·        Subscriber Location server is not needed. The RBS box would recognize US central server as its main home server, if needed.

With this setting, each country could command their military fleet separately. All mobile users could call each other or other command centers.

21. Security concerns

21.1 Encoding outgoing packets or protocol encryption

Telecom system design started with a 5G RBS to lower development cost, quick deployment, and regular telecom features, so telecom operators could use system, i.e. spreading development costs to many stake holders such as military, police and telco.

Military is concerned with security and don’t want to share their system or technology used to other organizations, but we need a clear technical specification for a large and complex system in order to understand, trouble shoot, enhance system, etc. Therefore 5G RBS was selected, because it is the latest telecom standard.

In order to satisfy the request to make system proprietary or private to each national military and police, military could invest in proprietary dynamic encryption and encoding protocols. Private mobile users cannot roam in military network by the way, i.e. it’s a close system.

Figure 10. Network diagram for telecom system settings

Figure 11.  An example of communication settings

Figure 12. Encoding packets before sending out in a telecom standard protocol

As shown in figure 10, figure 11 and figure 12, central server and RBS box are hosted inside a LAN, thus it is secured or protected by gateways, which are equipped with a packet analyzer.

The only issue would be securing communications between nodes over the Internet, satellites, intranet, or WLAN. Usually telecom system providers are private organizations developing a standard telecom system used by many organizations or telecom operators, therefore we have to keep the protocol intact for roaming or inter communications.

In addition to proprietary dynamic encryption of each packet, military could play with protocol for internal communications as another layer of encryption or encoding. For example, encode communication between RBS and mobile station as shown in figure 11.

·        Central server follows telecom specification to communicate with RBS box as usual.

·        RBS box encodes the packet by toggling bits, flipping parameters, etc. before sending it to the RBS. (Assume that RBS didn’t check the integrity or meaning of each packet. Otherwise this task must be done in RBS.)

·        The RBS send out packets as usual over the air

·        The mobile station receives packets and flips parameters back to regular telecom packet for normal processing by telecom core system.

The above process could also be done for communications between gateways such as Internet gateway, satellite gateway, and WLAN gateway.

To make it more complicated, method of handling encryption folder described in earlier section could be used, i.e. different encoding algorithms for different pair of military bases.

By encoding protocols, telecom core system was not modified, thus telecom system providers could support it as usual, i.e. fixing bugs and upgrading as needed. The encoding procedures and software deployment would be handled separately by military.

In brief, US military or others could encode protocols for internal communications between their bases as often as they like. However communication to another country’s military base or external telco would require flipping data back to standard protocols before sending out.

The most security concern would be air interface between an RBS and mobile phones, because mobile phone was not equipped with powerful parallel processors in order to perform multiple encryptions. Other gateways could be super computers, thus those could encrypt a message multiple times before sending those to destination. To deploy or change encryption on mobile phones are required time, and it’s inconvenient as comparing to updating gateways.

21.2 Encoding and encrypting strategy

In order to support roaming by mobile phone users across military bases, we must offer common encryption and encoding for each mobile phone. Military also share its telecom network with federal employees, but they didn’t want to share their encryption algorithms on those phones, thus federal employee’s phone must have different set of encryption for the air interface.

The solution would be using a byte or 2 bytes in each air interface message to encode or identify encryption algorithms to be used by RBS Box or RBS to decrypt a message before processing. For example, 

Byte #2 in a registration message

·        Value = 0: encryption not used

·        Value = 1: common encryption for military

·        Value = 2: private encryption of local base

·        Value = 3: common encryption for federal employees

·        Value = 4: encryption for local federal employees in a province

·        Value = 5: common encryption used by all telecom operators

·        Value = 6: private encryption used by telecom operators in a country

·        Value = 7: private encryption used by a telecom operator

·        Value = 8: common encryption for police

·        Value = 9: private encryption for police in a city

·        Value = 10: private encryption for police in a province

·        Value = 11: common encryption for provincial public staff

·        Value = 12: private encryption for provincial public staff in a province

·        Value = 13: military visitor

·        Value = 14: federal staff’s visitor

·        Value = 15: police visitor

Byte #3 in a registration message

·        Value = 0: encoding not used

·        Value = 1: common encoding for military

·        Value = 2: private encoding of local base

·        Value = 3: common encoding for federal employees

·        Value = 4: encoding for local federal employees in a province

·        Value = 5: common encoding used by all telecom operators

·        Value = 6: private encoding used by telecom operators in a country

·        Value = 7: private encoding used by a telecom operator

·        Value = 8: common encoding for police

·        Value = 9: private encoding for police in a city

·        Value = 10: private encoding for police in a province

·        Value = 11: common encoding for provincial public staff

·        Value = 12: private encoding for provincial public staff in a province

·        Value = 13: military visitor

·        Value = 14: federal staff’s visitor

·        Value = 15: police visitor

The above example only classifies a few encryption and encoding options. It depends on current configurations and users of systems to make final protocol.

Based on the value of those bytes described above and received mobile phone number, system would decrypt and decode a message properly. For example, the same protocol is used in USA and Canada for US military and Canadian military respectively. Based on a US phone number or a Canadian phone number, system would treat it as local user in order to decrypt and decode correctly.

Military could reserve a few mobile phones for its visitors with different encryption and encoding algorithms. These users would have limited access to telecom system or infrastructure.

It is assumed that the RBS will broadcast messages using local encryption or encoding request to mobile phones within its range. The mobile phone would attempt to decrypt and decode the message. If the mobile phone could not decrypt or decode the message, it would request the RBS to use common encryption and encoding algorithms.

If the mobile phone could not figure out if it couldn’t decrypt or decode a message by itself, then the RBS must broadcast messages with a specific local indicator, e.g. California base, New York base, or Texas base, etc. If the mobile phone was from Chicago, it couldn’t recognize that local indicator. It would request common encryption and encoding algorithms from that RBS. The protocol suggested above must be updated accordingly.

It’s assumed that US military could not roam in a network in another country such as Canada. Therefore, an encryption’s location indicator (=2) could mean California base in USA, but Trenton base in Canada. Military staff should have known that they could not roam into another network, and system didn’t allow this neither based on the mobile phone number. The same argument applies to police (province or city) local indicator. If military or police staff wanted to roam in another country’s network, they should load their mobile phone with a 5G frequency band, i.e. connecting to their network via a public mobile telephony network instead of loading their phones with encryption/encoding algorithms used by another military or police’s network. 

A mobile phone is not equipped with powerful microprocessor(s) and big network’s database, thus it cannot process complicated tasks or complex decrypting/decoding algorithms. If you wanted a complex algorithm, you should figure out how to shift complex tasks to the RBS or RBS Box.

22. Military model without RBS Box

The system design started with a standalone 5G RBS to provide phone and Internet communication to mobile user, thus a RBS Box with function as a simple MSC was selected to manage and control the RBS.

If the system was designed to provide telecommunications for a military base, perhaps RBS box was not considered.

Cable from each RBS will be run to connect the RBS to the central server, i.e. RAN cable and RBS voice (C7) cable. The central server would be equipped with a RAN card and RBS voice card to handle RAN and C7 voice messages. There would be fewer options in this case as RBS could not connect to the central server using Internet, wireless LAN, or satellites network unless the RBS software was updated to support those configurations.

The RBS’ RAN cable is connected directly to its central server, thus Internet communication will be dispatched by the central server to a central RAN or to another Internet server as needed via the Internet gateway. If we connect the RBS’ RAN to its central RAN as in telco network, we must know the location of central RAN, i.e. more work.

Figure 13. Military telecom model without a RBS Box.

23. Some typical configuration scenario

23.1 Common settings

Each RBS Box could communicate with its central server by several ways, e.g. satellite, Internet, Ethernet cable, and wireless LAN. Therefore, system could prioritize preferred communication methods in automatic mode, e.g. switching from wireless LAN to satellite if the wireless card failed. However, an IT could override the automatic mode, if needed.

23.2 Navy

Navy ships would use wireless LAN to communicate with each other. The satellite gateway could be stationed in one of navy ship.

The wireless range could be up to 50 km, i.e. covering a large area. Therefore all navy ships of a fleet shouldn’t come close to land together. The ship closed to land should switch off its wireless LAN and use satellite for communications. If the navy ship used wireless LAN, its RBS Box would be the defending node, but it is not equipped with high processing power as other nodes. By using satellites, any communications could be validated by a powerful satellite center, i.e. detecting possible hacking activity.

24. Mobile router and remote login by a computer

Each mobile phone could act as a mobile router to other laptop or tablets. Each mobile phone could allow any laptop or tablet connected to it manually via WiFi in order to access public Internet or internal web site wirelessly.

The encryption algorithm would be common encryption used in public. Unless those laptops are military property, then it could be equipped with military’s encryption and encoding algorithms.

The mobile router allows military personnel to offer wireless public Internet to their family during a car trip, it does not mean to replace a home Internet.

The mobile router, RBS, RBS Box, and central server are acting as transfer stations to relay data from a laptop or tablet to public networks, i.e. those messages were not encrypted or encoded for external networks.

Military staff must use military laptop with special encryption and encoding algorithms for access of internal military network or working remotely. The mobile station is only performed as a transfer station.

25. Multiple frequency RBS

25.1 Military and Police network

Police forces are sharing RBS in each city, province, and across country. However, the RBS could be loaded with a special software subsystem in addition to 5G software. For example, we could equip a 5G RBS with 2 transceivers (antenna), one for 5G communications and one for a proprietary (special) frequency.

Incoming signals could be detected by the transmission layer’s software, 5G signals would be directed to 5G software subsystem. The process would be normal for 5G communications as described in early sections. 

If proprietary signals detected by the transmission software, it would be redirected to the new software subsystem for processing such as unpacking and validating in the RBS. Packets would then be sent to the RBS Box as usual, where signals would be dispatched to a special central server for further processing. RBS Box and special server may implement the same protocol as used by regular central server or different.

The above scenario could be used by Special Investigation Unit (SIU) of police force, where their data and communications would be stored in the special central server instead of regular central server as described above. All RBS Boxes across country or a province would recognize this special central server for communications.

Figure 14. An example of Police and SIU systems loaded on an RBS

25.2 Telecom operator’s network

Telecom operator could ask telecom system provider to implement a similar solution for providing 4G and 5G services by an RBS. An RBS could load 4G and 5G software and equipped with a 5G antennae and 4G (transceiver) antennae. Depending on calls from 4G or 5G subscribers, signals would be directed to the corresponding 4G or 5G subsystem respectively on the RBS.

The RBS would communicate with its MSC as usual, i.e. sending 4G or 5G request by subscribers to the MSC for further processing.

Figure 15. An example of 3G, 4G, and 5G subsystems loaded on an RBS

Figure 16. An example of implementation by reusing components on an RBS.

26. Navy Fleet communications

Usually navy forces are sailing around in a fleet or several ships at a time. Those ships are in middle of an ocean, thus there was nobody around and there was no cables connecting them together.

The communication settings for those ships would be wireless LAN (WLAN). One principal ship would be equipped with a WLAN hub operated by a skilled operator, and this ship would connect to satellites to provide voices and Internet to the entire fleet. Other branch ships would use standalone WLAN node to connect to the principal ship for external voice and data communications.

The principal ship would never park in any “foreign” harbors. Any branch ships could park in a harbor, and activate WLAN to connect to the principal ship, the range should be adjusted enough for communications.

In case of intruders or hacking activities detected by either principal or a parking ship, WLAN data communications would be cut off from the principal ship and the parking ship.

·        The parking ship would use standalone RBS and its box to provide local communications as usual. They shouldn’t use satellite router and modem to connect back to the satellite hub in this case.

·        The parking ship would activate emergency WLAN channel with only voices to the principal ship.

·        The principal ship activated the emergency (voice) channel to communicate with the parked ship to resolve hacking issues.

·        Operators of both ships would work out solution to resolve hacked issues before reactivating full functionality of WLAN communications as usual.

In case of emergency, the parked ship could communicate with principal ship or commanding center using equipped satellite router and modem as usual.

To automate process, the operator on principal ship could click a button on his console to switch voice-data WLAN communications to voice-only communication with the parked ship in trouble. The parked ship would accept the “switched” order to switch to voice-only communication automatically OR parked ship’s operator manually switches to this emergency mode. 

27. Alternative routing of services

As shown in figure 10 and figure 11, there are many gateways to the external network from a military base, e.g. satellites, Internet, WLAN, public landline network, etc. The central server could be configured to use an alternative route if the chosen routed congested or blocked. For example, calls should be routed via Internet gateway, but the local Internet was down. Central server could route that call via the satellite gateway or public landline network instead. The same strategy applies to data communications with appropriate gateway.

28. Scenarios for charging data for a subscriber from a subcontract server

It is assumed that the main server owned the spectrum and leased its wireless network to subcontract server selling air time. The main server would receive charging data from other network operators in case of either its subscribers or subcontract server’s servers roam in another wireless networks. Therefore the main server would request subcontract server to authorize a roaming call request for its subscriber internally, but main server would handle authorization or agree to roaming charges with other network operators instead of subcontract server. 

Figure 17. MS1 is a subscriber of a subcontract server connecting to a main server. MS1 hung up.

In figure 17, MS1 ended call. This is a call case of a subcontracted user made a call and then hung up. The main server handling of “ended call” user would inform the subcontracted server (MS1 home subcontract server); and MS1 & MS2’s central servers (MS1 & MS2 main server) about call time.

Figure 18. MS1 is a subscriber of a subcontract server connecting to a main server. MS2 hung up.


In figure 18, MS2 ended call. This is a call case of a subcontracted user made a call and then the called party hung up. The main server handling of “ended call” user would inform the subcontracted server (MS1 Home subcontract server); and MS1 & MS2’s central servers (MS1 & MS2 main server) about call time.

Figure 19. MS1 is a subscriber of a subcontract server connecting to a main server. MS2 hung up.

RBS received the message “Routing Request for ... with RBS IP” would send “Request setup call delivery to complete paging and setting up voice path as needed”

The main server handling of ended call would report “call time to concerned parties”

29. Backup system for phone calls or Internet services

In order to provide 24/7 services to a base in case of interrupted local central server, each RBS box would be configured to recognize the military head quarter server as a backup server.

·        Military server would store all subscribers of its forces in database. Those records would be active, but does not have any activity or updated by local servers normally. That means local servers do not need to update head quarter servers for daily activities of its subscribers.

·        Each RBS box would recognize the head quarter server as a legitimate central server

·        The communication between an RBS box with head quarter server would be common encryption, i.e. head quarter doesn’t need to store private encryption used by each military base.

·        Usually each phone call setup would be allowed within 1 minute. If a call could not be set up within a minute, system would automatically disconnect all parties concerned to avoid hanging records (zombie) in the system.

·        A local central server could be down for a reason during a call request. If a call placed from an RBS could not be completed within, e.g. 20 seconds, that RBS would attempt to connect with the head quarter server to complete the call setup.

·        Head quarter server would set up call for that user, and this is the only time the head quarter server stores data related to that call for billing purposes.

·        If the local server was up after 20 seconds and attempted to connect with that user’s RBS, the RBS should send a disconnect message to the local central server to release its records. The call should be handled by the head quarter server to simplify software implementation.

There should be only one backup system, i.e. head quarter server, because military does not want head quarter data stored at any local base.

A subscription or features allocated to each user could be different in a local central server and its head quarter server for security and usage purpose. For example, a California user could surf Internet using satellite, but at its head quarter that user could not use Internet or only Internet via regular cable.

30. Encryption policy

To make hacking activity harder, each military base would be responsible to their private or local protocol encryption, i.e. head quarter doesn’t know the over the air private encryption used by each base. Hacking activity would likely be concentrated in head quarter; therefore this was a risk of disposing over the air encryption’ security of local base, if hacked. Hackers would be forced to come to each base and attempted to hack to the local network.

To safeguard local over-the-air encryption, mobile phone would be synchronized with new (daily or weekly change) encryption by placing its handset into a personal cradle connected to local network.

Visitors to a base would be required to sync their handsets in an IT control room to get local encryption in order to make or receive phone calls.

Because protocol encryption could be easily implemented or designed by many software developers, the tasks to track down the author or obtaining the algorithms would be very difficult to hackers. Telephony system providers could hand over this security task to each military force.

For Telco, they may offer both common over-the-air encryption and private encryption to their subscribers downloaded over the air. Private subscribers would communicate with the local RBS or RBS server using private encryption. Visitors form another Telco would use common encryption, because their phone numbers are identified as visiting roamers. The common encryption could be updated by all Telco over the computer networks.

31.    Internet, RAN and Central RAN

Usually a RAN is connected to an RBS and sending data to its central RAN before dispatching to destination.

In this configuration the Internet communication from a handset would go to the associated RBS server, where first packet of data would go the central server to determine proper gateway to destination, such as Internet Gateway, satellite gateway, WLAN gateway, etc. To make it compatible to 5G system, those data packet would be encapsulated in an IP envelope (relevant heading of those packets could be removed and then added later at destination server) and send out toward its central RAN via selected gateway.

However the central server could add an indicator based on its analysis of the packet’s destination, i.e. within IP telephony network, it could remove the entire data packet heading or sending it directly to a central server at destination. The proprietary IP protocol could be used. This is optional for system developers as it is more complicated to develop, but processing time for sending each packet to destination would be faster.

By the way for telco 5G stuff, APY is very powerful for using as a platform of an RBS. The RAN could be incorporated into the APY to lower product costs. With this the RBS could send data directly to its central RAN. It should be faster and more efficient.

32.   Mobile Router Handling Sub-systems

Figure 20. Subsystems handling of devices connected to handset via WiFi interface

As shown in the figure 20, there are two Wireless Envelope Final Packing and Unpacking subsystems interfacing the wireless network for mobile telephony, i.e. one for military system and one for regular Telco network.

Military handset used proprietary frequencies, so it cannot roam in any regular Telco network. To make military handset roam-able, it must be able to handle public air wave spectrums. To make military phone secured, each handset should be loaded with separate mobile telephony system used by Telco, i.e. Mobile Telephony Subsystem for Telco Network. All phone calls using public airwaves would be handled by this subsystem, i.e. military software is safeguarded or untouched.

The only issue would be handling of devices connecting to a military handset via WiFi interface, i.e. handset acted as a mobile router. There are 3 cases, i.e.

a)     Military staff using a military laptop to login its military network via the WiFi router. This laptop should have a unique indicator recognized by the handset during exchanging messages with the WiFi System Interface Manager. Military staff is not recommended to use his “proprietary” laptop using public wireless network. The less exposing of sensitive equipment to public would be better in terms of security.

b)    Public laptops or tablets used by children or military staff to access public network via military wireless system.

c)      Public laptops or tablets used by children or military staff to access public network via Telco wireless system.

In case of (a), all message exchanged by the military laptop would be handled by the WiFi Packet Unpack and Pack Unit for Military subsystem. This system would simply unpack packet and preliminary pack data in required format before passing those to the WiFi System Interface Manager or Wireless Envelope Final Packing and Unpacking for Military Network for final processing including encryption and relevant packet envelope(s).

In case of (b), all message exchanged by the public laptop would be handled by the WiFi Packet Unpack and Pack Unit for Telco subsystem. This system would simply unpack packet and preliminary pack data in required format before passing those to the WiFi System Interface Manager or System Interface Manager or Wireless Envelope Final Packing and Unpacking for Military Network for final processing including encryption and relevant packet envelope(s). (If you wanted the WiFi Packet Unpack and Pack Unit for Military subsystem to handle packing and unpacking tasks, the system must know in advance that the handset is currently in military wireless network, i.e. system is well integrated. By using Telco packing and unpacking subsystem, the entire system is loosely coupled, WiFi Interface Unit only checks for military indicator from a WiFi message.)

In case of (c), all message exchanged by the any public laptop would be handled by the WiFi Packet Unpack and Pack Unit for Telco subsystem. This system would simply unpack packet and preliminary pack data in required format before passing those to the WiFi System Interface Manager or Wireless Envelope Final Packing and Unpacking for Telco Network for final processing including encryption and relevant packet envelope(s).

The above discussion is for dual mode mobile handsets using both military and public wireless network, i.e. 2 WiFi Pack and Unpack Units running separately. If military decided its handset is single mode, i.e. only used within military wireless network, then only a WiFi Pack and Unpack Unit is needed.

33.        Internet and mobile phone network in rural areas

By looking at the main diagram, we could see that communications between servers or RBS Boxes could be Internet or satellites.

Satellites communications are generally expensive for heavily usage.

Governments usually require network operators to provide Internet or phone communications in rural areas in order to own airwave spectrum for mobile telephony operations. Mobile operators could team up with an Internet operator to run fiber optical cables in small cities or rural areas to provide Internet services. Those locations could be connected to nearest larger city for full services using fiber optical cables or satellites. RBS Boxes and radio base stations could be installed in these remote locations to provide wireless access or telephony. RBS Boxes would be connected together using Internet lines. This would save both Internet Service Provider and Telco operators.

34.    Leasing RBS capacity to Telco wireless operators.

Military network (or police) network would cover the entire country with Radio Base Stations (RBS). However their usage is very low, thus Radio Base Station would be operated at very low processing power, i.e. under usage.

Military could lease its RBS capacity, especially in rural areas, to reliable Telco wireless operator(s). Telco would be responsible to sell its services and handle communications to public users according to telecommunication industry standards as well as providing a spectrum for RBS, i.e. each RBS operates with 2 different spectrums in parallel; one for military (police) and one for general public.

Military would load Telco’s telephony system on RBS to run it in parallel with military telephony system. Note that military system has different encryption and features for military users. There would be a subcontract server handles public users in this case. Military would handle the maintenance operations of this wireless network, and send monthly public user information, billing information, etc. to Telco, i.e. a part of data stored in the subcontract server.

Since military and police have policy to safeguard their networks to outsiders, having part of networks leased would make them think twice. To make their policy less impacted, public (leased) call’s traffic must be routed to the nearest gateway to public network or as soon as possible, i.e. having less public traffic in internal network. It should be noted that military and police has extra network capacity, thus they would likely help residents in rural areas with mobile telephony access via leasing its RBS and partial network to a Telco operator.

Let’s MS-A be the calling party and MS-B be the called party. MS-A and MS-B could be either a military (police) staff or a public user. We are concerned with the calling party phone number, because it would determine call traffic originated by a public user. By browsing call setup traffic’s diagrams in sections above, MS-A and MS-B were included in the sequence of messages. Therefore the mobile telephony network could redirect all calls involved public user based on MS-A to nearest public network via a gateway.

MS-B is irrelevant in this case as a military (police) staff could call to an internal colleague or a public user, where calls would be routed via military’s (police’s) network to the nearest gateway closed to the called party, MS-B.

35.   Phone Number Portability or Subscriber Relocation

To automate the process of a subscriber moving from a city to another city or changing telecom operators easily, telecom operator should assign a PIN code, which should include digits and alphabets, associated with the phone number. For example,

If a subscriber registered with Bell Canada in Quebec, Bell would give subscriber a phone number, e.g. 514-678-3425, and a PIN code such as BELLQC34526. The registration process was performed in the Subscriber Location Server and its home central server (serving the phone user) would be updated automatically by messages. The phone user should safe guard this PIN code. Assuming the subscriber moved from Quebec to Toronto of Ontario and registered with Rogers. Rogers would assign the subscriber with a Toronto phone number, e.g. 416-786-9879, and another PIN code ROGERON2456. In the registration process in the Rogers’ telephony system at their Subscriber Location Server (SLS), the SLS would send a deregistration request to the SLS of Bell Canada in Quebec for the subscriber including his old phone number (514-678-3425) and associated PIN code (BELLQC34526). SLS in Quebec would update (or remove the subscriber record in) its database and also update record of relevant home central server automatically. This process would be automated with that confidential PIN code.

The process of phone number portability would be performed when a subscriber was switching from a telco to another telco in the same city or area. It could be done with the same automatic process as described above for subscriber’s relocation by using his confidential PIN code.

If a subscriber lost his PIN code, the operator must contact the previous operator and carry out deregistration process manually.

The idea was using previous subscriber phone number as username and his PIN code as password in automatic deregistration process.

There is a way to automate deregistration process if user lost his previous PIN code. The password could be his full name or previous address including postal code. It is up to telecom operators to select which information was credible enough to replace the PIN code to automate deregistration process.

31.    Internet, RAN and Central RAN

Usually a RAN is connected to an RBS and sending data to its central RAN before dispatching to destination.

In this configuration the Internet communication from a handset would go to the associated RBS server, where first packet of data would go the central server to determine proper gateway to destination, such as Internet Gateway, satellite gateway, WLAN gateway, etc. To make it compatible to 5G system, those data packet would be encapsulated in an IP envelope (relevant heading of those packets could be removed and then added later at destination server) and send out toward its central RAN via selected gateway.

However the central server could add an indicator based on its analysis of the packet’s destination, i.e. within IP telephony network, it could remove the entire data packet heading or sending it directly to a central server at destination. The proprietary IP protocol could be used. This is optional for system developers as it is more complicated to develop, but processing time for sending each packet to destination would be faster.

By the way for telco 5G stuff, APY is very powerful for using as a platform of an RBS. The RAN could be incorporated into the APY to lower product costs. With this the RBS could send data directly to its central RAN. It should be faster and more efficient.

32.   Mobile Router Handling Sub-systems

Figure 20. Subsystems handling of devices connected to handset via WiFi interface

As shown in the figure 20, there are two Wireless Envelope Final Packing and Unpacking subsystems interfacing the wireless network for mobile telephony, i.e. one for military system and one for regular Telco network.

Military handset used proprietary frequencies, so it cannot roam in any regular Telco network. To make military handset roam-able, it must be able to handle public air wave spectrums. To make military phone secured, each handset should be loaded with separate mobile telephony system used by Telco, i.e. Mobile Telephony Subsystem for Telco Network. All phone calls using public airwaves would be handled by this subsystem, i.e. military software is safeguarded or untouched.

The only issue would be handling of devices connecting to a military handset via WiFi interface, i.e. handset acted as a mobile router. There are 3 cases, i.e.

a)     Military staff using a military laptop to login its military network via the WiFi router. This laptop should have a unique indicator recognized by the handset during exchanging messages with the WiFi System Interface Manager. Military staff is not recommended to use his “proprietary” laptop using public wireless network. The less exposing of sensitive equipment to public would be better in terms of security.

b)    Public laptops or tablets used by children or military staff to access public network via military wireless system.

c)      Public laptops or tablets used by children or military staff to access public network via Telco wireless system.

In case of (a), all message exchanged by the military laptop would be handled by the WiFi Packet Unpack and Pack Unit for Military subsystem. This system would simply unpack packet and preliminary pack data in required format before passing those to the WiFi System Interface Manager or Wireless Envelope Final Packing and Unpacking for Military Network for final processing including encryption and relevant packet envelope(s).

In case of (b), all message exchanged by the public laptop would be handled by the WiFi Packet Unpack and Pack Unit for Telco subsystem. This system would simply unpack packet and preliminary pack data in required format before passing those to the WiFi System Interface Manager or System Interface Manager or Wireless Envelope Final Packing and Unpacking for Military Network for final processing including encryption and relevant packet envelope(s). (If you wanted the WiFi Packet Unpack and Pack Unit for Military subsystem to handle packing and unpacking tasks, the system must know in advance that the handset is currently in military wireless network, i.e. system is well integrated. By using Telco packing and unpacking subsystem, the entire system is loosely coupled, WiFi Interface Unit only checks for military indicator from a WiFi message.)

In case of (c), all message exchanged by the any public laptop would be handled by the WiFi Packet Unpack and Pack Unit for Telco subsystem. This system would simply unpack packet and preliminary pack data in required format before passing those to the WiFi System Interface Manager or Wireless Envelope Final Packing and Unpacking for Telco Network for final processing including encryption and relevant packet envelope(s).

The above discussion is for dual mode mobile handsets using both military and public wireless network, i.e. 2 WiFi Pack and Unpack Units running separately. If military decided its handset is single mode, i.e. only used within military wireless network, then only a WiFi Pack and Unpack Unit is needed.

33.        Internet and mobile phone network in rural areas

By looking at the main diagram, we could see that communications between servers or RBS Boxes could be Internet or satellites.

Satellites communications are generally expensive for heavily usage.

Governments usually require network operators to provide Internet or phone communications in rural areas in order to own airwave spectrum for mobile telephony operations. Mobile operators could team up with an Internet operator to run fiber optical cables in small cities or rural areas to provide Internet services. Those locations could be connected to nearest larger city for full services using fiber optical cables or satellites. RBS Boxes and radio base stations could be installed in these remote locations to provide wireless access or telephony. RBS Boxes would be connected together using Internet lines. This would save both Internet Service Provider and Telco operators.

34. Internet and mobile phone network in rural areas

Military network (or police) network would cover the entire country with Radio Base Stations (RBS). However their usage is very low, thus Radio Base Station would be operated at very low processing power, i.e. under usage.

Military could lease its RBS capacity, especially in rural areas, to reliable Telco wireless operator(s). Telco would be responsible to sell its services and handle communications to public users according to telecommunication industry standards as well as providing a spectrum for RBS, i.e. each RBS operates with 2 different spectrums in parallel; one for military (police) and one for general public.

Military would load Telco’s telephony system on RBS to run it in parallel with military telephony system. Note that military system has different encryption and features for military users. There would be a subcontract server handles public users in this case. Military would handle the maintenance operations of this wireless network, and send monthly public user information, billing information, etc. to Telco, i.e. a part of data stored in the subcontract server.

Since military and police have policy to safeguard their networks to outsiders, having part of networks leased would make them think twice. To make their policy less impacted, public (leased) call’s traffic must be routed to the nearest gateway to public network or as soon as possible, i.e. having less public traffic in internal network. It should be noted that military and police has extra network capacity, thus they would likely help residents in rural areas with mobile telephony access via leasing its RBS and partial network to a Telco operator.

Let’s MS-A be the calling party and MS-B be the called party. MS-A and MS-B could be either a military (police) staff or a public user. We are concerned with the calling party phone number, because it would determine call traffic originated by a public user. By browsing call setup traffic’s diagrams in sections above, MS-A and MS-B were included in the sequence of messages. Therefore the mobile telephony network could redirect all calls involved public user based on MS-A to nearest public network via a gateway.

MS-B is irrelevant in this case as a military (police) staff could call to an internal colleague or a public user, where calls would be routed via military’s (police’s) network to the nearest gateway closed to the called party, MS-B.

35.   Phone Number Portability or Subscriber Relocation

To automate the process of a subscriber moving from a city to another city or changing telecom operators easily, telecom operator should assign a PIN code, which should include digits and alphabets, associated with the phone number. For example,

If a subscriber registered with Bell Canada in Quebec, Bell would give subscriber a phone number, e.g. 514-678-3425, and a PIN code such as BELLQC34526. The registration process was performed in the Subscriber Location Server and its home central server (serving the phone user) would be updated automatically by messages. The phone user should safe guard this PIN code. Assuming the subscriber moved from Quebec to Toronto of Ontario and registered with Rogers. Rogers would assign the subscriber with a Toronto phone number, e.g. 416-786-9879, and another PIN code ROGERON2456. In the registration process in the Rogers’ telephony system at their Subscriber Location Server (SLS), the SLS would send a deregistration request to the SLS of Bell Canada in Quebec for the subscriber including his old phone number (514-678-3425) and associated PIN code (BELLQC34526). SLS in Quebec would update (or remove the subscriber record in) its database and also update record of relevant home central server automatically. This process would be automated with that confidential PIN code.

The process of phone number portability would be performed when a subscriber was switching from a telco to another telco in the same city or area. It could be done with the same automatic process as described above for subscriber’s relocation by using his confidential PIN code.

If a subscriber lost his PIN code, the operator must contact the previous operator and carry out deregistration process manually.

The idea was using previous subscriber phone number as username and his PIN code as password in automatic deregistration process.

There is a way to automate deregistration process if user lost his previous PIN code. The password could be his full name or previous address including postal code. It is up to telecom operators to select which information was credible enough to replace the PIN code to automate deregistration process.

36. Dual mode mobile phone and VoIP phone

During the early days of deployment this mobile telephony system for military and police, 5G phones could only be supported by a military frequency, and military didn’t want it roaming to a telco networks as well as signaling used in military’s mobile telephone network different than telco, i.e. proprietary IP signaling and private encryption.

In order to make phones used or recognized by worldwide telecom networks, each military phone could be registered as a VoIP phone. All incoming calls routed to its central home server, where call processing would be started as for a mobile phone within military network. This was the simplest and fastest way to make system up and running quickly.

To make its mobile phone able to roam to a public telecom network in addition to install a public mobile system on the phone in parallel with military mobile system, there are 2 solutions

·         Each mobile phone would be registered as a mobile phone instead of VoIP phone

This solution may require additional work to update phone worldwide telco’s database. Telco system must recognize a home central server as an HLR and support IP communication, i.e. installing an IP node to convert IP signals or messages into their existing SS7 or C7 messages OR

·         Updating telco’s MSC to recognize a mobile phone could be functioned as both VoIP phone and mobile phone, so routing, paging, and charging functions could be carried out properly.

Usually when we dialed a landline phone number, MSC would route call request through a voice trunk, e.g. BT4 or ISUP, without involving the process of authenticating, locating, paging, and routing call to a mobile phone.

If a dual mode phone roamed to a public network and dial a number, the MSC would send a request to its (IP) home central server for authentication and authorization instead to its “home HLR” via SS7 signaling. The home central server would behave as either landline MSC or home HLR depending on the state or location of its mobile phone.

Military must install a gateway node to convert SS7 messages into IP messages for processing OR each telco would convert SS7 message into IP messages before sending out via Internet.

If telecom operators planned to deploy or use this IP mobile telephony system, they should implement nodes to convert SS7 or C7 messages in IP messages to communicate to military networks.

37. Handling of phone calls for remote users with satellite networks

This telephony system could be used for users in remote areas with satellite networks dispatching phone calls to a designated central server.

In scenario 1: assuming that an African user in a remote village places a phone call with local telecom operator to a user in California,

·         The serving satellite operator (e.g. Telesat) doesn’t have any satellite in California or USA, but has a special agreement with Bell Mobility (wireless telco in Canada) and satellite in Canada.

·         Call would be routed by satellite to Canada and connected to Bell Mobility network or central server

·         Bell Mobility would route this call to the user in California by its network as usual

·         The only draw back in this solution is “charging.” This (probably poor) user should be charge a “low” roaming fees.

·         This call may be required by regulator to label as call routed by both satellite and mobile telephony networks.

·         With African phone number, an indicator of Telesat, and Bell Mobility’s sender IP, we could tell the identity and how call was transferred.

In scenario 2: assuming passengers of a cross nationwide train wanted to place calls and surfing Internet on board. Usually they’re using GSM-R system for this, but we could also use this telephony system. Assuming passengers are travelling from Nova Scotia (Eastern Canada) to Vancouver of British Columbia (Western Canada).

·         Equipping the train wagons with sufficient capacity for passengers by using RBS and its RBS box.

·         The train could use Nova Scotia’s central server as its home servers and its passengers as roamers.

·         Passengers could connect to the on-train RBS and is RBS box, which is communicated with satellite system such as Telesat during the journey.

·         All calls or Internet traffic would be transferred back to the central server in Nova Scotia regardless of its location such as Quebec, Ontario, Manitoba, Alberta, etc.

·         Calls and Internet traffics would be handled by central server in Nova Scotia.

·         Similar as above arguments for call by African caller, calls and Internet usages must be charged with reasonable rates.

·         And all traffics would be “labeled” as traffics by both satellite and land systems.

For cross-border trains from Canada to USA, the RBS box should still use Telesat satellite network in USA (or other satellite operator if they’re inter-connected) to communicate or relay communications back to Nova Scotia central server to complete call or Internet traffics with destination users. The reason for not using RBS box to communicate with a central server of another telecom operator in USA is “private” communications implemented between an RBS box and its dedicated central server. Satellites are considered as transport layers for on land telecom.

In case of roaming train originated in Canada to USA, where the original satellite operators (Telesat) doesn’t have satellites, the train could switch to the US satellite operator (previously in agreement) to handle call and Internet traffics for its passengers. If the US satellite operator doesn’t have satellites in Canada or inter-connected with Telesat, the passenger’s voice/data traffics would be routed to an on-ground ISP (in USA) operated by the US satellite network. This ISP would then route traffics toward the central server of that RBS box by using Internet for further processing, e.g. central server in Nova Scotia. Of course the central server in Nova Scotia would communicate with this ISP for handling traffics with its moving RBS Box via the US satellite network.

The main reason to beam down traffic to an ISP in USA, where it will be routed to the central server in Nova Scotia, was to use on the ground infrastructure. In general, satellite system belongs to military. Military would kick out everyone to take over the entire satellite system, if needed. Therefore having traffic on the ground would safeguard those communications.

Military communications could be hand-off between different satellite systems, if they wanted. However civil communications should avoid relying on satellite networks as much as you can for the reason above.

*********************************************