Dynamic encryption pools used in public networks

A. General Information

Communications by telecom or Internet would use dynamic encryptions to protect its contents. The encryption algorithms don’t use a master decryption key, but dynamically changed encryption/decryption key.

The idea was from telecom technology in authentication. Telecom system authenticates a mobile phone using authentication by RANDU, SSD, and CAVE. We would use an SSD as a dynamic key to encrypt/decrypt a packet.

B. Internet and Telecommunications

1. Https

Currently we’re using https as an encryption technology in many countries, i.e. shared encryption technology.

2. Encryption

The issue was that there were not many encryptions available for many important organizations or general public use in telecom or Internet communications. So, computer industries would share a set of encryptions in many nations. Telecom industry should share another set of encryption algorithms.

It’s not easy to keep an encryption algorithm secret. The goal is to make hackers to crack any packets by running all cracking algorithms. This would take them months or years to decrypt a packet. By the way, a short email would include many packets, so hackers would be in trouble to decrypt an email.

3. Common pool and private pool of encryption algorithm

If there were many encryption algorithms, we could divide those in 2 pools of encryptions. Roamers from another place would communicate with a local telecom or Internet network by using the common pool of encryptions agreed by regulators or industries.

Private or local users could use either common pool or private pool of encryptions.

4. Methodology or protocol

Let’s assign the common pool of encryption by a unique version number or characters agreed in the applicable industry.

a. Common pool

-         The first communication message to an ISP or telecom network would be encryption version.

-         If the roamer couldn’t understand the private (local) version of encryption set, they would send a request to use the version of common pool.

-         The communication would then be in common pool’s algorithm.

Use of private encryption pool could be done easily with a version number. If the name of encryptions is changed, the version name would be changed, too.

b. Same set of encryption, but different names

Even hackers knew the encryption, but if they didn’t know which algorithm used in encrypting a packet, they must run all decryption possible algorithms to decrypt a packet, i.e. months or years to know the content of our message.

In a previous note, a computer and ISP must exchange encryption names and protocol to specify association of an encryption and a packet. This helps the ISP (or telecom operator) to decrypt a message easily as required by laws.

The key would be encryption names. If hackers didn’t know the encryption names, they would be forced to run all decryption algorithms.

To make decryption harder to hackers, we would change names of encryption algorithm or software regularly. Each location (ISP or telecom operator) could have different names for the same set of encryption algorithms. The protocol could be as follows

-          The first communication message to an ISP or telecom network would be encryption version or pool version.

-          If the common pool of algorithm was not available, the ISP would send a message to the user to download encryption software with unique names as well as its version number.

Because the whole industry only used a set of algorithms, thus let the user to download the encryption software should be fine, i.e. the device knew algorithm in other names.

C. Changing encryption names

Regulators or special teams could change names of encryptions or add new encryption algorithms at any time. They only need to change version names and allow users to download new encryptions.

Encoding local IP address

Figure 1. Sample of a network connection for an ISP

If we looked at the diagram, our computer is assigned a local IP address by our ISP for Internet communication, e.g. 192.168.2.1.

When we perform a remote access to another computer or server, our local IP address could be included in an Internet packet along with the global ISP’s IP address. This is to ensure that the return packet knew to route back to our ISP, and then our computer.

A typical IP address is 12 digits, i.e. 6 bytes.

If we encoded our local IP address in 3 characters or 3 bytes, we would save 3 bytes in communications. 3 bytes is 256 x 256 x 256 possible combination, i.e. ISP could offer unique connection to 16,777,216 computers within their network.

Let’s say our computer is temporarily assigned with a code ABF instead of 192.168.201.165. The ISP could insert this code, ABF, in the database, and send out a message to the gateway with its IP plus ABF as returned IP address, e.g. 265.378.109.243 + ABF instead of 265.378.109.243 + 192.168.201.165 in an IP packet. The Internet gateway only needs to route the return packet to 265.378.109.243, where the packet would be decoded and delivered to 192.168.201.165 based on the internal code ABF.

Similarly the Internet gateway could encode the IP address of its internal ISP server address before sending a packet out with its IP address and code of the internal ISP.

International Charity Office (ICO) Head Quarter Model v1.3

A. Introduction

During a fight to destroy worldwide neural networks military, people and many technical staff from many countries have seized assets from junk and fuckers using neural networks. Since the seized money and assets are complicated to distribute to all members participated in this mission, therefore ICO was established and used seized assets and money in charitable activity, helping unfortunate people worldwide, participating in some projects in each country to facilitate better life to local residents.

The assets seized also include important companies or organization that ICO cannot wind down. Thus ICO must manage those organizations as well as investing surplus cash while doing charitable activity in parallel.

The charitable activity would be submitted by ICO satellite offices to its head quarter based on the monetary amount required by an activity, e.g. above US$ 1M activity would require an approval by a staff from the ICO head quarter.

The assets are very large in size and monetary amount are also large, which would make ICO operating in many decades or centuries to come. This triggers a request to build a remote head quarter for ICO, i.e. a remote land far away from other cities. This reserved area would prohibit others to build residential units around to avoid deployment of any helmets or neural network’s equipment disturbing local staff. It would also be easier to provide security to local staff as money would motivate many junks and insane to penetrate this area.

B. Residential area for local staff

This area would include working offices with settings similar to a military base model written in a separate article, i.e. local RBS, LAN, computer, and mobile phone. To avoid hacking activity in the internal offices, local staff would check out a temporary mobile phone and/or a laptop for their trips outside of this head quarter. The checked out laptop and mobile phone would be scanned for hacking activity before wiping out and restoring to its original states upon return. To avoid fire balls flying, those mobile phone and laptop won’t store any credit card or password information, e.g. no mobile payment supported.

The working internal laptop should not be connected to the network in visitor’s area neither due to less security implemented in the visitor’s area.

The internal offices could also use short range WiFi enough to cover the office, i.e. it didn’t reach surrounding residential units.

The residential units also have Internet and low range WiFi to ensure that its networks couldn’t be reached from the visitor area. 

Figure 1. Settings of the ICO head quarter

C. Entertainment Center

Most of local staff are business staff, thus they would normally like a setting or regular activity as offered in a small town. However, they couldn’t download or install any games on provided laptop or mobile phone. All Internet games or applications could be downloaded at the separate Entertainment Center equipped with a dedicated Internet line to compensate the “no download policy”. This center, which is well designed, is not far away from residential units, i.e. just a short ride by car.

D. Visitor area

This area has a setting similar to a guest area in the military base model. This area would be up and running when there was a meeting activity occurred with outsiders such as executives of organizations managed by ICO. These executives would live in civil cities as they were, i.e. they don’t have to relocate to the local residential areas.

All executives would temporarily stay in those visitor’s condominiums while attending a meeting.

The visitor area also offers Internet communications.

After a meeting event, the system for visitor area would be scanned or restored to its original states. It should be shut down except the minimum heating and air conditioning systems could be running to keep the meeting area and visitor condominium in good shape.

Executives are advised to keep all documents on their laptop for a presentation, but they could also remote login back to their offices to fetch missing documents as long as they’re using a good tool such as VPN for better security from the visitor’s network.

E. Some security measures

Upon arrival to a nearest airport, all visitors’ laptop would be scanned by a security staff. Visitor would be assigned a temporary mobile phone with their personal phone number be forwarded to this temporary phone, i.e. this could be done by a security staff accompanied the visitor. The temporary mobile phone would be wiped out and restored to its original state upon return.

The only reason to scan visitor’s laptop from the airport to the head quarter is to be able to return the laptop back to visitor when they arrived at the office by car.

All visitors shouldn’t bring any electronic devices or equipment to enter a local office or residential units to avoid possible hacking activity embedded in those equipment, i.e. we cannot trust a device, but only visitors.

F. ICO satellite office’s settings

1. General information

This office is like a 9am - 5pm office with many staff with limited knowledge about technology. This office could be located in a small town, because staff’s competitive salaries were not very high and their jobs didn’t require setting of a large city.

2. Typical tasks

Majority of staff would spend most of their time reading newspaper, browsing Internet’s web site such as Facebook, LinkedIn, Google+, online news, etc. to search for any potential small/medium size projects. There is also a pool of larger projects listed at the head quarter to be executed.

Staff would carry out a reasonable time to perform a research for information related to an identified project. If the size of project is larger than US$ 1M, they would contact the head quarter with data for an approval. This pre-approval step would reduce “noise or disturbance” caused by insane, scammers, and junks.

In addition to self-research, local staff could contact head quarter for a contact of an independent consultant with better knowledge about the selected project. The consultant would help to prepare data and plan to submit to the head office.

After an approval of a project, local staff could hire a contractor to carry out plan for that project within allocated budget, i.e. as a manager. This could be done by another experience staff.

3. Equipment

The office setting is like a small company with a simple Packet Analyzer as a gateway to Internet. The main server could be incorporated into this gateway. The local area network would host a number of computers and a database server.

All computers are equipped with a simple Packet Analyzer. All computers must be shut down after working hours.

All mobile, VoIP, or landline phone used are local public phones.

Staff cannot install any applications or games on their office laptop/computers. Installation request on a laptop would be noticed by the main server. Installation would fail without previously approved by a system admin from the main server.

All communications to head office would use public Internet or public telephone’s infrastructure.

The last staff leaving the office would flip a switch to turn off the Internet gateway and disconnect the database server to outside Internet network. This would eliminate all hacking activity occurred after working hours.

The first staff arrived in the office would flip the switch on to start all servers and enter a code to unlock the server(s) as well as connecting the database server back to the LAN.

The best setting would be using Ethernet cable for the LAN and computers. However, short range of WiFi routers could be used just to cover the office areas.

G. Submitting a request for help to ICO

There should be a web site organized in regional postings. There is also a generic template to fill in request for a charitable project by ICO.

If a requester bothered an ICO staff, their request would be voided. This is to prevent harassment of ICO staff.

Important requests would be sorted in length of project, benefits, estimate costs, etc.

Smaller projects would follow simpler template.

H. Temporary security measures

Any ICO head office’s staff travels to surround cities would be accompanied by a security guard or a military personnel during the first few months since the beginning of the operations of the ICO head quarter. Perhaps many people and junks believed that any ICO staff knew a lot of business ideas, can offer special help in charitable projects, etc. thus they would follow to bother a staff.

After a few months of operations people and others would know that all key decisions are made by a group with careful discussions. Therefore they would stop harassing any ICO staff.

I. Proposed structures of ICO satellite offices

There was a proposal to set up a few satellite offices taking care of charitable projects in larger areas. All staff must be fluent in English. Offices are organized to support different time zones.

-         Head office located in Canada

-         Offices in Japan and South Korea for Asia

-         Office in Brazil with staff fluent in English, Portuguese, and Spanish for Latin America.

-         Offices in England and Germany for Europe

-         Offices in Israel, Sweden, and Australia for Middle East, Africa and Oceania

-         Offices in Russia to help mostly projects in Asia, Middle East, and Africa

-         A small number of Russia staff would help in Europe project.

-         Office in USA with staff fluent in English and Spanish for Latin America and North America

There is not an office per country, because ICO won’t carry out daily or annual projects in each country. There is also a budget allocation for each country, by the way.

J. Miscellaneous notes

ICO’s business is very large, so it could kill any competitors easily. However, ICO would not kill other business to form a monopoly networks, because it would be similar to communist’s business model. Communism doesn’t work.

ICO’s charity umbrella would help local residents to provide essential food or activity by themselves.

Most of work would be in Africa, Middle East, and Asia.

A typical project would be helping African to provide essential food by themselves. Let’s say it costs $3 for a pound of chicken in Canada, thus African couldn’t afford $3/lb + transportation cost to pay for chicken shipped from Canada. ICO doesn’t compete with Canadian business by helping African to setup local chicken farms to produce less expensive chicken to local residents. Similar projects would be fresh water, applicable vegetables (depending on local soil), and pig farms. Beef would be luxury food, thus Africans must raise cow by themselves.

Military base model for communications v1.4

A. Introduction

There was a discussion for setting up communications for military when they deployed at a location with a single Radio Base Station (RSB) tower and a control box. It then evolved to setting ups similar communications at a military base. 

The proposal diagram or design probably isn’t flexible, but the requirement or setup supports deployment of a single (compact) RBS tower and its RBS control box or more RBS towers and RBS control boxes.

In case that military or search/rescue team required more features than a single RBS control box offered, they should add a central server, i.e. another small box.

Most of equipment is “public-used” equipment except the packet analyzer, military satellite, and dynamic encryption algorithms. The RBS is a regular RBS using a special frequency band allocated to military instead of 5G frequency used in public. By using most of equipment used in public, the cost of system development and equipment would be less expensive.

Figure 1. A model of equipment network at a military base

B. RBS and its control box

We can use a 5G’s RBS including internal RAN to support Internet or VoIP communications. With RBS such as an APY with internal RAN, the system would be compact for deployment in a battle or search/rescue zone. This RBS would be configured to use another frequency band allocated to military.

The RBS would have 2 output cables, one for regular voice and one for IP communication (output from RAN). There would be 2 special cards connecting those outputs to an RBS control box, which is like a computer server such as EMS server.

The control box could offer simple telephone communications to its mobile phones as well as text messaging. Basically it functions is limited as compared to a telecom switch. The control box would take care of dynamic encryption with its mobile phones connecting via the RBS. The control box could offer simple broadcasting a message by voice or texts to all mobile phones connecting to its RBS.

Mobile users could talk or communicate directly to staff at the RBS control box.

C. Mobile Phone

Mobile phones are also used special frequency band with limited functionality such as voice communication, voice over IP, web browsing, dynamic encryption, etc.

There should be 2 interfaces or dial pads on each mobile phone. The users would use a dial pad to make regular calls to internal users at the base or using the other dial pad to make outgoing (friend’s) calls using VoIP on the mobile phone.  By separating 2 dial pads the software development, system settings, and network managing tasks would be easier.

Friend’s VoIP and Internet browsing would be redirected to the Internet Gateway, where a simple packet analyzer implemented to provide better security.

D. Satellite modem and router (Gateway)

There are cases that a staff base wanted to call another staff stationed in another base. Calls or texts would be redirected to the satellite modem and router, where messages would be relayed by military satellite networks.

We assumed that military equipment is better in security than Internet.

The long distance calls from a base to another base could also be VoIP (VoLTE) calls routed to the Internet Gateway using Internet network instead of satellite gateway. It’s up to system providers and military to pick a solution. This VoLTE option instead of regular voice calls could save military from buying special boxes to convert RBS voice messages at the receptionist’s landline or VoIP phone. Security and performance of voice calls using either gateway could be the same. Those calls would be rung on receiving mobile phone using VoLTE to make system design simpler.

E. Central server for telecom

This central server is like a simple version of co-located MSC/HLR and SCP/IN. It offers coordination and managing of all RBS control boxes and its mobile users. The central server only offers essential features to mobile users, i.e. it’s not a full version of a collocated MSC-HLR or SCP/IN.

The central server also equipped with dynamic encryption to communicate with all RBS control boxes through a local area network. This didn’t imply that the local area network is unsecured, but it is a useful setting in case that the central server and RBS boxes are located far apart and communicate with each other via a wireless LAN or a satellite LAN.

Central control box could broadcast voices or messages to all mobile users, a group of mobile users, or several groups of mobile users connecting to different RBS. The settings must be pre-configured by an interface.

F. Miscellaneous features

1. Local call or call to another base

The central server has a database for all phone numbers of staff in their base as well as most (remote) dialed phone numbers of staff in other bases. If the list of (remote) phone numbers is very long, they could only specify the receptionist phone numbers at other bases, where calls would be redirected by an operator or PBX at remote locations. 

When a mobile user calls to another base, the RBS control box sends a usual message to the central server to enquire a routing path. The return message from the central server would be the IP of the satellite modem and router or a gateway indicator (described later) to specify the satellite router plus required information. The RBS control box would relay voice calls toward the satellite modem and router for communications.

The packet for satellite calls could in VoIP or regular voice calls. The satellite router would need to pack the packet in correct (satellite packet) format. Actually if it was a VoIP call, it could remove the IP header/footer and insert an indicator for the satellite receiver to add back the required IP header/footer before packet delivery.

2. Different gateways

There are 2 gateways in the diagram above. One gateway is for Internet communication, and another is for satellite communication. We don’t want a message passed or came out of the wrong gateway.

To ensure correct communication with a gateway, the network could specify a list of destination IP addresses in central server and at each gateway. However it would be easier for gateway to decide if a message was destined out by its gate, we could add a special byte or indicator in each packet.

For example, (calls another base) the central server, which was communicated by a RBS control box for a call, determined if a voice message was not for a local user, it could add an (satellite) indicator to inform the RBS control box in a return message. The RBS control box would insert that (satellite) indicator in each voice/data packet to send it over the LAN, e.g. indicator 1 for satellite and 2 for Internet Gateway. The correct (indicated satellite router) gateway would pick up the message unpack it, remove the indicator, and pack it again in correct format before sending out to the satellite in this case.

The RBS control box would direct (private) VoIP calls, private text messages, or browsing Internet activity to the Internet gateway. Therefore it would pack the Internet gateway indicator in each IP packet before sending it over the LAN. The Internet gateway would remove that indicator and repack the message. The RBS control box would be able to distinguish if a call from a mobile user was a VoIP or a regular voice call.

3. Local mobile calls

When a mobile phone placed an internal call, the RBS control box would also send a message to the central server to enquire the location of the called mobile phone. The central server would return a message with last known location of the called mobile user. The RBS control box would redirect voice calls to the destined RBS control box. Because a military base is using private frequency band, thus it could broadcast a mobile paging signal by all RBS if the last known location was not correct.

The delivery of text messages from an RBS to another RBS is similar as voice call delivery.

G. Incoming call from VoIP (Internet) gateway, landline phone server, or satellite router

By default incoming call from a gateway would be routed to the central server, which determined where that call should be destined, e.g. to an RBS or local land PBX. After receiving a message from the central server, the gateway would route that call to a correct destination source.

H. Some security measures

Mobile phones, RBS, RBS control box, central server for telecom, Internet gateway, and satellite router are equipped with a simple packet analyzer and dynamic encryption of packets to prevent fraudulent access to the network.

Mobile phone and RBS should only support communications by using the special frequency band allocated for military, i.e. military’s mobile phone doesn’t support frequency bands used in public such as other 5G phones. This limits exposure of military stuff in public telecom networks.

Mobile phones don’t support mobile router feature. This also limits connection of normal/civil laptop or tablets to a military phone.

Military should be allocated a unique set of encryption algorithms for all bases. However, each base could name each algorithm a different name as they like, because this would make guessing harder to hackers. Military doesn’t have any policy to allow free roaming by laptop/phone from a base to another base. A (military personnel) visitor should contact IT staff of a visiting base to get a temporary phone or specific settings in their phones for communications. It’d be easier to give visitor a temporary phone, i.e. visitor could forward their personal calls to this temporary phone while visiting the base for a few days.

As a base has limited number of staff or personnel and equipment, military IT could try to change name of encryption algorithms after a few months by updating all devices or equipment using a physical cable connecting to a server. Basically updating over the air should be avoided.

To offer comfort to visitors, a base could reserve a guest area that offers free Internet and landline (or VoIP) public phones to all visitors. The Internet network in this area would be separated from the internal network discussed above. This area also supports WiFi with shorter range, i.e. enough to cover the guest area, but didn’t reach outside residents or internal networks. This area is also equipped with a simple packet analyzer at the Internet gateway. After each use by visitors, the area’s networks should be scanned for all files being modified or created during its operation, i.e. detecting if any hacking tools had been installed. The guest area could be shut down if nobody used it. If it’s simple, IT could restore the system images of all equipment in the guest area to clean all possible hacking patches after each use.

A visitor could organize a presentation in the guest area. However it’s not as secure system as in the internal network. The presentation slides should be self-contained, i.e. doesn’t require Internet access. This would help to protect a guest’s laptop as it’s connected directly to a projector.

A visiting military officer wouldn’t have access or remote login back to his base by plugging his laptop into the internal network due to different encryption names. This is also to protect the remote network from unauthorized rlogin, and to avoid sending a visitor's userid and password over Internet or satellite network.

If you wanted to avoid hacking patches on a mobile phone or laptop, then don’t allow any installation of applications or games on a phone or laptop. Users could browse Internet to read news or play some web games. Any installation request from a laptop or mobile phone would require an approval by a system administrator. This could be done by software on a laptop/phone to notify a system server for any installation attempt. Unless it’s previously approved by a system admin, any installation attempts would fail.

J. An example of a  mixed setting of communication lines

Depending on location of military camps, there could be mixed settings of communication lines between an RBS control box and its central server. WLAN could also be used as communication method in one of those RBS control box.

Figure 2. Mixed setting of communication lines.

Pre-authorizing Remote Login v1.1

A. Manually authorizing remote login

When I was working at Bestech, which developed a system to provide required airflow to underground miners, Bestech support staff sometimes has dialed in the mining office to collect data for statistic and maintenance.

I noticed that username and password couldn’t be secured to outsiders, so it’s risky to the Bestech system if a hacker uses its allocated username and password to login and change the airflow system.

It would be more secured if Bestech support staff called the local mining IT to inform that they would login to collect data. The local IT would open a port or gate to Bestech support staff. After the collection or maintenance, the Bestech staff would inform the local IT, so that port or gate could be closed to outsiders.

This protocol would lift responsibility of Bestech support staff from external hackers and make system more secured.

If there were many users often remote login through a gate, then internal IT staff would only remove that userid from remote access. The gate should be close if nobody used it.

B. Automate authorizing remote login

In highly secured organizations, technical staff also remote login to perform their tasks sometimes. Internal IT could offer manual authorizing remote login as above or automate authorizing remote login as specified below.

In both remote login methods, users should use a tool such as VPN to enhance security.

The internal server would offer 1 or 2 special encryption algorithms in addition to common pool of encryption algorithms to laptops that required to rlogin regularly, thus calling an internal IT staff would be troublesome or time consuming. There would be a common set of encryption algorithms that would be available to all users having access the internal networks by either method.

The VPN protocol would be a little bit different for regular access laptops

-         The laptop would send a message to request connection with internal server

-         The internal server would exchange messages to authenticate its userid and password by using the special pool of encryption algorithms.

-         After successful authentication, the server would inform the laptop a gate for that user entering internal system by a message.

-         The special pool of encryption would be used during communications

When the laptop logout, it would inform the internal server by a message to remove its userid and close the gate, if needed.

It would be easier to provide two different gates or ports to manually and automatically rlogin users due to controlling software and different pools of encryption algorithms.

To add another layer of security to prevent a case that hackers have replicated the ID of the automated laptop in order to remote login to the internal server, we could add another layer of validation, i.e. staff must inform IT before bringing a laptop home for rlogin. IT would add that laptop ID in the Internet gateway for rlogin. When that staff done with rlogin work from home, s/he should inform IT to remove that ID off from the Internet gateway. This protocol would eliminate the case of replicating ID of a laptop.

IT could also identify the authorized ISP for that laptop, if needed. For example, that laptop could only rlogin from only one ISP such as Bell Canada. If the laptop used another ISP such as Cogeco, Rogers, or Telus, it would fail in remote login.

Monitoring Camera

The Internet security is not reliable. Hackers could hack in any company or organization.

A. The worst case would be broadcasting your home camera across Internet, so you could view your home remotely. Hackers could eavesdrop your Internet or login in order to view your home security or activity with your username and password.

B. Why should bank trust a security firm to monitor their branch offices by monitoring its activity remotely over the Internet using video cameras? Hackers could see all activity in a bank including users depositing or withdrawing cash. This is unsecured.

What should a bank do with their monitoring camera?

1. Bank could use dynamic encryption of video streaming to an outside security office, so security guards could view its internal activity. Only a few external terminals were configured to receive video streaming.

2. Bank could also use close circuit camera. The video server stays inside a bank. They could offer the following:

- A locked box connecting to the video server for video access. This locked box is accessible on a bank wall, so police could open the box and view inside activity in case of a robbery. Who could open the box and plug a laptop in as it’s visible to all people around?

- Video transferring and live streaming in case of an alert button pressed. The video server would start live streaming of internal scenes over a preconfigured Internet link to a security or police office. The server could also transfer out video of older scenes such as periods of 15 minutes, 30 minutes, or 1 hour before alert button pressed. In a second round, it could also transfer video of 2 hours, 3 hours, or longer periods of time as previously configured after the first round of transferring completed. This is to ensure that required videos were available quickly to law enforcement in case of emergency in the first round of videos transfer.

- The video server doesn’t accept any remote login or actions from an external source, i.e. it would originate video transfer or live video. This could be done easily by a simple packet analyzer.

Compressing an IP packet

If we looked at the format of an IP packet below (image was taken from Internet), we could see that the Frame Header, IP header, and UDP header have occupied lots of space in an IP packet.

In some cases, the IP header contains the (main) IP address of the gateway and then the subnet IP address of the sender or receiver. This would leave little room for data in an IP packet.

Each network or relay node(s) would need to unpack an IP packet for the contained IP address in order to relay or pick it up.

If we could compress the entire IP packet except the Frame Header/Footer and main IP address or gateway IP address, this would give more room for the packet data. Internet networks would deliver IP packets based on its gateway IP address. The gateway would pick up the packet; decompress its contents including subnet IP, which could be encoded, and then deliver to its final destination or subnet.

By keeping the destination gateway IP and frame header/footer intact, this protocol offers backward compatibility to previous version of IP packets. New system would determine if a packet was compressed or not based on “included characters”. Gateway address, subnet IP address, and UDP address contain a specific “numeric” format.

Smart city, province, or country

Smart city with 5G and Internet networks

There are companies, which have been advertising smart cities with all information linked and displayed. I don’t think that is a good idea.

There could be an umbrella with all information databases from all public departments linked, e.g. city data, provincial data, federal data, public transportation, income tax agency, citizenship department, etc. With all information linked and analyzed, staff could have an overview of a city, province, or country quickly and accurately.

Could government ask private sectors for user data? I don’t think this is a good idea to ask private sectors such as private company, publicly traded company, wireless network operators, ISP, etc. to provide data or open databases. There is an issue of privacy, confidential information, trade secrets, etc. that governments should not get involve in case of leaking.

The packet analyzer team is different as they must monitor Internet, phone communications, etc. to provide secure and safety to everyone. They could ask wireless operators and ISP for secured links to a R/O mirrored database for that purpose. They could also link to some less sensitive government database such as public transportation for more information. However they should not ask private companies or sensitive government’s databases access, because if data was leaking, they would be blamed for that.

In brief, smart cities to monitor and control everything in a city could be done with current technologies, but we should not do so due to privacy, trade secrets, confidentiality, and secured data by different parties involved.