# Mobile Personal Multi-Access Edge Computing Architecture Composed of Individual User Devices
## 2 Proposed Mobile Personal Multi-Access Edge Computing Architecture
### Detailed Operation Process of the Proposed Scheme  
The detailed operation process of the proposed scheme consists of three steps: mobile MECS registration step to utilize mobile node as MECS, service requester's request step for task offloading, and task offloading step of mMECS. A detailed description of the steps follows. **[Step01] Mobile MECS Registration:** In order to provide the task offloading service to the service requester by using the mobile node existing in the access MECS as the MECS, the mobile node performs a procedure of registering its own information in the access MECS. To this end, the proposed scheme uses the mobile Node Registration (mNR) message to register the mobile node with the access MECS. The mNR message is a message format defined to register with access MECS that the mobile node will utilize its computing resources to play a role as the MECS. Figure 4 shows the format and example of the mNR message. The mobile node name and address fields of the mNR message each represent the name and address of the mobile node, and the type field is the field used by accessing MECS to identify a message. The resource field is a field that contains metadata that records computing power such as CPU performance and memory capacity of the mobile node. The mobile node that decide to provide the MECS service sends the mNR message to the access MEC. In the proposed scheme, the mobile node that provides MECS service by sending mNR message to access MECS is named mMECS. Upon receipt of the mNR message, the access MECS records the information for mMECS management in the mMECS Management Table (mMT) based on field information from the mNR message. Figure 5 shows the example of the mMT. **Mobile MECS Management Table**  
Figure 4: The mNR message format and example. Figure 5: An example of mMT generated by the access Multi-Access Edge Computing Server (MECS). Since the proposed scheme utilizes mobile devices as MECS, it can provide low-latency service delivery than the traditional MEC architectures. However, since the mobile device is used as mMECS, it needs various considerations for continuous service delivery. Because the proposed scheme uses mobile devices as MECS, the access MECS needs to check whether or not mMECS has moved periodically. For this, the proposed scheme transmits segment information to mMECS and if it does not receive a response within a random time, it determines that mMECS has moved and retransmits segment information to another mMCES. In addition, in order to achieve optimal task offloading performance considering the different task processing speeds of mMECS, the proposed scheme utilizes the method for variable segment allocation. The variable segment allocation method works by allocating more segments to mMECS which can perform task offloading quickly. For example, due to the slow computing task offloading processing speed of mMECS, when access MECS receives the processed task segment lately, access MECS adjusts the number of segments to provide fast task offloading to the service requester. In other words, the mobile device that has completed the registration in the access MECS by performing the above procedure can play a role as the MECS, so that it is possible to provide the faster service delivery to the requesting service than the existing MEC architecture. **[Step02] Service Requester Request for Task Offloading:** In order for the service requester to request task offloading from mMECS, the proposed scheme initializes by sending metadata containing task offloading information to access MECS. For this purpose, the proposed scheme uses the task offloading request (TOR) message. The TOR message is used to request task offloading from access MECS by the service requester. Figure 6 shows the format and example of the TOR message. The name and address field represent the mobile device name and address information of the service requester requesting the task offloading service. The type field is used by access MECS to identify the TOR message.