Предлагаемое решение для перепродажи тарифов eSIM

Данная статься является последней в цикле лекций по изучению процесса перепродажи тарифов eSIM и в ней мы будем рассматривать предлагаемое решение для перепродажи тарифов eSIM.

Большинство исследований, касающихся eSIM, было проведено в области безопасности, что вполне естественно, поскольку это все еще относительно новая технология и аспект безопасности чрезвычайно важен из-за связанной с ней конфиденциальной информации. Кроме того, поскольку спецификации от GSMA охватывают только случай одного оператора, который имеет контроль над системой удаленного обеспечения, это оставляет область того, как третья сторона может вписаться в экосистему eSIM и как они могут использовать eSIM, неисследованной.

В этой главе было разработано предложение по архитектуре повторной продажи подписок eSIM в стороннем мобильном приложении, начав с обсуждения различных ограничений и проблем, возникающих при использовании стороннего решения для повторной продажи, и описав пару альтернативных решений проблемы. Затем он переходит к описанию различных частей предлагаемого решения и того, как они взаимодействуют друг с другом. Затем эта глава заканчивается описанием нескольких поездок клиентов, призванных показать, как система может работать с точки зрения пользователя.

Самым большим ограничением при разработке и внедрении приложения для повторной продажи подписок eSIM является необходимость наличия прав доступа к eSIM в iOS и привилегий оператора в Android, чтобы можно было инициировать загрузку профиля непосредственно из приложения. И поскольку профиль принадлежит перевозчику и защищен им на всем пути от создания до установки на eUICC, как описано в разделах 3.2 и 3.3, никто, кроме перевозчика, которому он принадлежит, не может вносить изменения в профиль. Как операционные системы Android, так и iOS реализуют возможности eSIM таким образом, что только оператор может создать приложение для загрузки eSIM и управления им, а также предотвратить это от третьих сторон. Поскольку Apple заявляет, что права доступа к eSIM предназначены исключительно для операторов связи, третья сторона, возможно, никогда не сможет получить эти привилегии для своего приложения, по крайней мере, в течение периода времени, указанного в этом тезисе. Кроме того, как указывалось ранее, приложение для iOS сможет только загружать профили и не сможет управлять ими позже, например, переключаться между профилями, поскольку нет API для поддержки этих операций, которые были бы возможны в приложении для Android. Стороннее приложение для Android также, как объясняется в разделе 4.6.2, сможет получить привилегии оператора, необходимые для загрузки eSIM, только благодаря сотрудничеству с операторами, eSIM которых будет продаваться в приложении. Это делает приложение для Android более интересным при разработке и внедрении решения.

Нетехнической проблемой может быть тот факт, что операторы, возможно, не захотят продавать свои eSIM через стороннее приложение. Как обсуждалось в разделе 2.4, многие операторы опасаются, что eSIM в потребительских устройствах приведет к усилению конкуренции между операторами, что, в свою очередь, может привести к потере клиентов для некоторых операторов. Таким образом, заставить операторов продавать eSIM через приложение, где его можно напрямую сравнить с предложениями других операторов, может быть непросто.

В связи с возможностью того, что приложение для перепродажи eSIM может иметь или не иметь права доступа к eSIM или привилегии оператора, сразу возникают два возможных решения, по одному для каждой возможности. В этом разделе будут представлены эти два различных возможных решения проблемы повторной продажи подписок eSIM в приложении.

В первом решении пользователь может купить eSIM в приложении у предпочитаемого им оператора и получить взамен код активации, содержащий адрес SM-DP + и токен кода активации для профиля. Затем пользователь вводит их в настройки eSIM, которые уже существуют на устройстве, используемом для загрузки профилей eSIM и управления ими, то есть в LUI. Это означает, что приложение используется только для покупки и получения кода активации и фактически не используется для загрузки профилей eSIM или управления ими. Это самое простое решение, потому что приложению не понадобятся какие-либо особые привилегии или права доступа, но это негативно скажется на пользовательском опыте, поскольку в процессе для конечного пользователя задействовано больше шагов. Схема последовательности того, как это могло бы работать, приведена на рисунке 1.

Рисунок 1: Решение без привилегий оператора или прав eSIM.

Шаги, требуемые в этом решении и показанные на рисунке 6.1, будут следующими:

Обратите внимание, что шаг 3 может выполняться по-разному в зависимости от того, как оператор обрабатывает eSIM. Возможно, перевозчик уже заставил SMTP+ создать несколько профилей и сохранил коды активации для них в базе данных. Если это так, то на этом шаге не требуется никакого взаимодействия с SMTP+.

Вторым, более продвинутым решением было бы также позволить приложению обрабатывать связь с LPA, чтобы оно могло начать загрузку. Это устранит шаг, на котором пользователь должен вводить код активации вручную в настройки eSIM на устройстве, что сделает его более удобным для пользователя. Недостатком этого решения было бы то, что для связи с LPA приложение должно иметь права доступа eSIM в приложении iOS и привилегии оператора в приложении Android. Однако, если приложение для Android имеет эти привилегии оператора, тогда также можно будет делать больше с профилями eSIM в приложении, например, переключаться между профилями, для которых у него есть привилегии оператора, а также удалять их. Это будет невозможно в приложении iOS даже с правами доступа eSIM, поскольку единственными двумя доступными методами, касающимися eSIM, являются supportsCellularPlan(), который проверяет, поддерживает ли устройство eSIM, и addPlan(), который инициирует загрузку нового профиля. Нет никаких способов переключения или удаления профилей, как в Android, это всегда должно быть сделано из настроек eSIM на устройстве.

Шаги, требуемые в этом решении, которые показаны на схеме последовательности на рисунке 2, будут следующими:

1-4. Шаги 1-4 такие же, как и в ранее описанном решении. 5. Теперь приложение может, вместо отображения кода активации конечному пользователю, напрямую взаимодействовать с LPA и, следовательно, может запросить загрузку нового профиля с предоставленным кодом активации. Если используется код подтверждения, он все равно должен отображаться конечному пользователю, поскольку пользователь должен ввести его вручную. 6. LPD загружает профиль из SMTP+ и устанавливает его на eUICC.

Рисунок 2: Решение с привилегиями оператора и правами eSIM.

Это было бы предпочтительным решением, если это возможно, потому что, как указано в разделе 2.1.3, Герпотт и Мэй пишут в [5], что важно, чтобы разработка инструмента, используемого потребителем для управления профилем eSIM, была максимально простой в использовании, и это решение, в котором приложение могло бы выполнить загрузку без необходимости пользователю иметь дело с какими-либо QR-кодами или кодами активации, с точки зрения пользователей, является самым простым.

Этот интерфейс не стандартизирован и поэтому будет выглядеть по-разному у разных операторов. Наиболее простым решением было бы позволить приложению напрямую осуществлять связь с операторами, как показано на рисунках 1 и 2. Однако подобное решение также означало бы, поскольку интерфейсы могут выглядеть по-разному, что ко всем операторам, включенным в приложение для перепродажи eSIM, придется относиться по-разному, поскольку интерфейсы могут выглядеть по-разному. на этапе, когда приложение должно взаимодействовать с ними. Это усложнит добавление новых операторов в приложение, поскольку это будет включать в себя внедрение механизма, который может обрабатывать связь между этим конкретным оператором и приложением.

Чтобы обойти эту проблему, связанную с тем, что приложение должно иметь возможность взаимодействовать со всеми различными операторами, лучшим решением было бы, если бы приложение просто взаимодействовало с серверным сервером, содержащим коды активации для всех профилей различных планов, доступных для загрузки. Компания, стоящая за приложением, затем получит коды активации от участвующих перевозчиков и сможет обрабатывать как оплату, так и доставку кодов активации. Когда eSIM покупается в приложении, компания выплачивает большую часть дохода соответствующему оператору, но также оставляет небольшую долю для себя в качестве комиссионных. В качестве альтернативы компания могла бы покупать профили у операторов оптом по цене ниже розничной, а затем, когда eSIM будет продан в приложении, сохранить весь доход. У операторов связи в любом случае будут предварительно подготовлены профили eSIM, как в случае с предварительно распечатанными ваучерами eSIM, но вместо печати данных на карточке они будут отправлены и сохранены на сервере компании. Сами профили по-прежнему будут храниться на сервере carriers SM-DP+.

Это означает, что, когда пользователь хочет купить eSIM в приложении, оператору связи не нужно будет каким-либо образом участвовать, поскольку компания будет обрабатывать как оплату, так и доставку кода активации. Это упростило бы реализацию приложения, поскольку интерфейс к серверу будет выглядеть одинаково независимо от того, у какого оператора конечный пользователь желает приобрести eSIM. Это также упростило бы добавление новых операторов в приложение. Вместо этого проблема теперь будет заключаться в том, что этот сервер должен иметь возможность пополняться новыми кодами активации от операторов, когда они заканчиваются. Как это можно было бы сделать и работать, рассматриваться не будет, но более подробная информация о том, как мог бы работать сервер, приведена в разделе 6.

В любом из двух случаев, описанных выше, приложение должно иметь возможность взаимодействовать либо с операторами, либо с внутренним сервером, чтобы получить информацию о планах eSIM, которые в настоящее время предлагают различные операторы, чтобы иметь возможность представить их пользователю. Это делает приложение более динамичным, и планы eSIM можно легко добавлять, удалять или изменять без необходимости что-либо менять в приложении.

Как только профиль eSIM будет загружен и установлен на устройстве, он будет работать так же, как любая другая SIM-карта от оператора, которому он принадлежит. Так, например, если срок действия истек или объем данных, количество текстовых сообщений или минут разговора, оставшихся на eSIM, заканчивается, оператор будет обрабатывать это так же, как если бы eSIM был куплен непосредственно у оператора, обычно путем отправки текстового сообщения на пользователь. Затем пополнение предоплаченной SIM-карты производится так же, как и с обычной SIM-картой, т.е. для eSIM нет специального пополнения, поскольку для него используются те же пополнения, что и для обычных SIM-карт. Это означает, что пополнение можно купить в любом месте, где оператор продает пополнения для предоплаченных SIM-карт, например, непосредственно на своем веб-сайте и в своих магазинах, но его также можно приобрести в виде ваучера, который затем используется для пополнения eSIM в таких местах, как продуктовые магазины, автозаправочные станции. и в любом другом месте, которое является перепродажей для оператора. Таким образом, можно также продавать пополнения для eSIM в приложении, потому что, как уже упоминалось, подобные системы, которые позволяют третьим лицам продавать пополнения для предоплаченных SIM-карт, уже существуют и используются.

Если приложение должно поддерживать загрузку и, возможно, управление профилями eSIM, то оно должно взаимодействовать с LPA на устройстве. Это делается с помощью API для приложений Android и iOS соответственно. Однако, если решение состоит в том, чтобы позволить конечному пользователю вручную вводить код активации в настройки eSIM на устройстве, тогда приложению не нужно взаимодействовать с LPA на устройстве. По крайней мере, на устройстве Android можно разрешить приложению напрямую открывать настройки eSIM на устройстве, чтобы пользователям не нужно было самостоятельно находить эту настройку. Это делается путем создания намерения со строкой ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS в классе EuiccManager в качестве входных данных и запуска нового действия с этим намерением.

Интерфейс для конечного пользователя в приложении должен быть способен выполнять множество различных задач. Он должен быть способен предоставлять конечному пользователю интерфейс, в котором пользователь может выбрать страну, в которой eSIM должен быть действительным, а затем иметь возможность сравнивать операторов связи и предлагаемые ими планы eSIM для этой страны, а также предоставлять способ продолжить покупку, когда пользователь решит, из какой носитель и который eSIM планирует купить. После этого пользователю должен быть показан список всех возможных доступных способов оплаты, и он должен иметь возможность выбрать предпочитаемый им способ оплаты, а также ввести любые необходимые личные данные, такие как адрес электронной почты для подтверждения после покупки. После этого пользовательский интерфейс зависит от выбранного пользователем способа оплаты. Если, например, пользователь выбрал оплату картой, пользователю будет предоставлена возможность ввести данные своей карты.

Когда оплата будет завершена, следующий шаг будет зависеть от того, имеет ли приложение привилегии оператора или нет. Если этого не произойдет, пользователю должны быть даны указания о том, как установить профиль в настройках устройства, а также представлен код активации. Это можно сделать с помощью краткого текстового описания и, возможно, изображений или видео для дальнейшего разъяснения. Пользователю также может быть предоставлена возможность в приложении для Android, как обсуждалось ранее, перейти непосредственно к настройкам eSIM, например, нажав кнопку или ссылку.

Однако, если приложение имеет привилегии перевозчика, приложение может начать загрузку профиля. Это может занять некоторое время, поэтому пользователь должен быть проинформирован о том, что загрузка выполняется через пользовательский интерфейс. Кроме того, если требуется код подтверждения, интерфейс должен позволять пользователю вводить его. Когда загрузка будет завершена, пользователь должен быть уведомлен о том, что профиль был успешно загружен. Кроме того, если у приложения есть привилегии оператора, приложение сможет предоставить пользователю интерфейс с обзором всех профилей eSIM, установленных на устройстве, для которого у него есть привилегии оператора. Затем он может показать название оператора и подписку для каждого профиля, а также то, включена она или отключена. Пользователь также должен иметь возможность переключаться между профилями и удалять их из этого интерфейса. В дополнение к этому также должна быть возможность представить пользовательский интерфейс, в котором конечный пользователь сможет создать учетную запись, указав, например, свой адрес электронной почты и пароль, а затем войти в эту учетную запись. Почему это необходимо, будет объяснено в следующем разделе.

Несмотря на то, что, как указано в разделе 3.3.5, пока невозможно перенести профиль между устройствами, например, при покупке нового мобильного телефона, возможно, стоит иметь в виду, что эта операция может быть реализована в более поздних спецификациях, что приведет к тому, что приложение сможет также реализовать поддержку этой операции.

Большинству приложений требуется серверная часть для того, чтобы некоторые аспекты и функциональные возможности приложения работали должным образом, это может быть, например, для хранения данных, или в некоторых случаях большая часть логики приложения может даже находиться в серверной части. Существует несколько различных вариантов развертывания и реализации серверной части, и в зависимости от необходимости какой-то вариант может подойти лучше, чем другой. Серверная часть может, например, размещаться в облачной среде, но, конечно, также возможно разработать и разместить собственный серверная часть. Существует множество компаний, предлагающих услугу размещения серверной части в облаке, и главным преимуществом этого варианта является гибкость пропускной способности сервера и то, что сервис управляется поставщиком облачных услуг. Однако преимущество размещения собственного сервера заключается в том, что вы будете иметь полный контроль над ним, но при этом также будете нести ответственность за управление. Каким бы способом ни был размещен сервер, он все равно должен быть реализован с уровнем безопасности, подходящим для рассматриваемого приложения. В этом разделе будут обсуждены проблемы безопасности, связанные с серверной частью решения для перепродажи eSIM, и будут предложены некоторые меры, которые можно предпринять для обеспечения безопасности.

Как было описано ранее, серверная часть решения должна была бы взаимодействовать как с приложением, так и с различными операторами связи. Чтобы гарантировать, что отправленные данные не будут скомпрометированы, связь между всеми объектами должна быть защищена, а для обеспечения того, чтобы получатель данных был тем, кому они предназначены, необходима аутентификация.

Между серверной частью и операторами

Серверная часть должна взаимодействовать с операторами связи, чтобы получать новые коды активации для профилей eSIM, продаваемых в приложении. В дополнение к защите данных при их передаче от оператора к серверной части, серверная часть должна аутентифицировать оператора, чтобы убедиться, что это действительно тот оператор, с которым она поддерживает связь, и, что еще более важно, оператор должен аутентифицировать серверную часть, чтобы не отправлять коды активации для кого-то, кто выдает себя за внутренний сервер. Все это можно решить с помощью TLS (Transport Layer Security) с взаимной аутентификацией при общении. В начале каждого обмена данными выполняется рукопожатие TLS, при котором серверная часть отправляет свой сертификат оператору, а оператор отправляет свой сертификат серверной части. Затем обе стороны могут проверить действительность сертификатов и, если они являются подлинными, приступить к согласованию ключа, используемого для шифрования данных. Затем данные могут быть отправлены, зная, что обе стороны аутентифицированы, а данные защищены шифрованием.

Между приложением и серверной частью

Связь между серверной частью и приложением также должна быть защищена, чтобы коды активации, отправленные в приложение, не могли быть прочитаны кем-либо еще. Сервер также должен пройти аутентификацию в приложении. Как и в случае связи между серверной частью и операторами связи, решением этой проблемы может быть использование TLS. Тогда приложение может быть уверено, что оно действительно взаимодействует с серверной частью, проверив свой сертификат, и отправленные данные могут быть зашифрованы. Однако внутренний сервер также должен быть в состоянии определить, что код активации загружает тот же пользователь, который купил его в первую очередь. Таким образом, если, например, один пользователь покупает eSIM, никто другой, кроме этого пользователя, не должен иметь возможности загрузить код активации с внутреннего сервера для этого eSIM. Это означает, что пользователь также должен пройти аутентификацию в серверной части. Это не может быть решено с помощью сертификата, как это делает сервер, поскольку нереалистичным решением является то, что каждый пользователь должен иметь свой собственный сертификат. Однако одним из возможных решений может быть предоставление пользователю возможности создать учетную запись, например, с указанием адреса электронной почты и пароля, где эти учетные данные хранятся в серверной части. Затем адрес электронной почты будет однозначно идентифицировать пользователя, и пользователь сможет пройти аутентификацию, зная пароль. Затем пользователь может войти в свою учетную запись при покупке eSIM, что позволяет серверной части определить, какой это был пользователь, и позволяет только этому пользователю получить доступ к коду активации для рассматриваемого eSIM.

Как только коды активации окажутся на внутреннем сервере, они должны будут храниться там до тех пор, пока пользователь не загрузит их, например, в базу данных SQL (Structured Query Language). Кроме того, при использовании учетных записей для аутентификации пользователей эта информация учетной записи также должна быть сохранена в базе данных. В дополнение к другим механизмам защиты, таким как брандмауэры, для защиты сервера, коды активации также могут быть защищены при хранении в базе данных путем шифрования. Таким образом, в случае атаки, при которой злоумышленник получает информацию о содержимом базы данных, коды активации по-прежнему будут неизвестны злоумышленнику. Пароли, хранящиеся в базе данных, также должны быть защищены и не храниться в виде открытого текста, обычно это делается путем хэширования паролей и сохранения хэша.

Чтобы проиллюстрировать, как должен работать весь процесс и как информация передается между различными объектами, был создан рисунок 3. Здесь можно увидеть, как конечный пользователь, приложение eSIM и другие части устройства, внутренний сервер, а также операторы связи взаимодействуют друг с другом и работают вместе, чтобы включить приложение для повторной продажи eSIM. Стрелки на рисунке показывают, что подключенные объекты обмениваются данными друг с другом, а цифры на стрелках - это шаг в процессе, включающем обмен данными между подключенными объектами.

Рисунок 6.3: Рабочий процесс для предлагаемого решения.

Шаги в процессе, который позволяет повторно продавать приложение eSIM, следующие:

Шаги 1, 2 и 3 выполняются непрерывно и независимо от использования приложения для повторной продажи eSIM. Этот процесс аналогичен процессу в магазинах, продающих физические предоплаченные SIM-карты, за исключением того, что магазин теперь заменен внутренним сервером, а SIM-карты заменены кодами активации eSIM, которые хранятся в базе данных сервера. Клиент, то есть пользователь приложения, может затем просмотреть этот магазин и приобрести один из продуктов, который в данном случае является кодом активации.

Остальные этапы процесса касаются покупки и загрузки профилей eSIM:

Это иллюстрирует, как работает система, если приложение имеет права доступа к eSIM или привилегии оператора. Единственное отличие, если у него нет права доступа eSIM в iOS, заключается в том, что шаг 7 не может быть выполнен, а в Android без привилегий оператора на шаге 8 LPA сначала загрузит метаданные профиля, а затем приложению будет отказано в привилегиях оператора, и загрузка прекратится. Это означает, что пользователю придется выполнить шаг 7 вручную через настройки eSIM на устройстве, как объяснялось ранее.

В следующем разделе будет описано несколько вариантов клиентского опыта, показывающих, как приложение должно работать с точки зрения конечного пользователя.

Тут предполагается, что пользователь создал учетную запись в приложении и прошел аутентификацию, войдя в систему.

Литература

[1] D. Gleeson, eSIM Device Sales Forecast: Smartphones, Tablets, and Wearables, 2019–24, 2019.

https://ovum.informa.com/resources/product-content/esim-device-sales-forecast-smartphones-tablets-and-wearables-201924-ces004-000118

[2] E. Vahidian, Evolution of the SIM to eSIM, Norwegian University of Science and Technology, Department of Telematics, 2013.

http://hdl.handle.net/11250/262765

[3] D. G. Koshy, S. N. Rao, Evolution of SIM Cards – What’s Next?, Interna- tional Conference on Advances in Computing, Communications and Infor- matics (ICACCI), Bangalore, 2018, pp. 1963-1967.

https://ieeexplore.ieee.org/document/8554774

[4] B. A. Abdou, Commercializing eSIM for Network Operators, 2019 IEEE 5th World Forum on Internet of Things (WF-IoT), Limerick, Ireland, 2019, pp. 616-621.

https://ieeexplore.ieee.org/document/8767260

[5] T. J. Gerpott, S. May, Embedded Subscriber Identity Module eSIM, Business

& Information Systems Engineering 59, 2017, pp. 293–296. https://doi.org/10.1007/s12599-017-0474-4

[6] P. Hristova and J. Bryan, eSIM For The Roaming Consumer, Roaming Con- sultancy Company Limited, 2018.

http://marketing.uros.com/ROCCO Roaming Consumer eSIM%20Strategy%20Report%202018.pdf

[7] GSMA, eSIM Whitepaper, The what and how of Remote SIM Provisioning, 2018.

https://www.gsma.com/esim/wp-content/uploads/2018/12/esim-whitepaper.pdf

[8] M. Meyer, E. A. Quaglia and B. Smyth, An Overview of GSMA’s M2M Remote Provisioning Specification, 2019.

http://arxiv.org/abs/1906.02254

[9] A. Vesselkov, H. Hammainen and P. Ikalainen, Value networks of embedded SIM-based remote subscription management, 2015 Conference of Telecommu- nication, Media and Internet Techno-Economics (CTTE), Munich, 2015, pp. 1-7.

https://ieeexplore.ieee.org/document/7347220

[10] M. Tsurusawa, Latest Trends in Remote SIM Provisioning Technology, Special Feature - The future of cellular networks, New Breeze Vol. 29 No.3 Summer, 2017, pp. 1-10.

https://www.ituaj.jp/wp-content/uploads/2017/08/nb29-3_web.pdf

[11] J. Park, K. Baek and C. Kang, Secure Profile Provisioning Architecture for Embedded UICC, 2013 International Conference on Availability, Reliability and Security, Regensburg, 2013, pp. 297-303.

https://ieeexplore.ieee.org/document/6657256

[12] S. Chitroub, N. Zidouni, H. Aouadia, D. Blaid and R. Laouar, SIM Card of the Next-Generation Wireless Networks: Security, Potential Vulnerabilities and Solutions, 2018 2nd European Conference on Electrical Engineering and Computer Science (EECS), Bern, Switzerland, 2018, pp. 502-509.

https://ieeexplore.ieee.org/document/8910042

[13] M. Meyer, E. A. Quaglia and B. Smyth, Attacks against GSMA’s M2M Re- mote Provisioning, Financial Cryptography and Data Security, 2018, pp. 243- 252.

https://www.blackhat.com/docs/eu-17/materials/eu-17-Meyer-Attacks-Against-GSMAS-M2M-Remote-Provisioning-wp.pdf

[14] Ernst & Young Mobile network operator on-demand subscription management study, 2015.

https://www.ey.com/Publication/vwLUAssets/EY-mobile-network-operator-on-demand-subscription-management/%24FILE/EY-mobile-network-operator-on-demand-subscription-management.pdf

[15] GSMA, RSP Technical Specification Version 2.2.1, 2018. https://www.gsma.com/newsroom/wp-content/uploads//SGP.22-v2.2.1-2.pdf

[16] GSMA, RSP Architecture Version 2.2, 2017. https://www.gsma.com/newsroom/wp-content/uploads//SGP.21_v2.2.pdf

[17] T. Chang, eSIMS: Everything You Need to Know, WhistleOut, September 2019. https://www.whistleout.com/CellPhones/Guides/esims

[18] Huawei, HUAWEI P40 Specifications. https://consumer.huawei.com/en/phones/p40/specs/

[19] Apple, Find wireless carriers that offer eSIM service. https://support.apple.com/en-us/HT209096

[20] T-Mobile T-Mobile Prepaid eSIM app.

https://www.t-mobile.com/support/plans-features/t-mobile-esim-app

[21] Android, Application Fundamentals. https://developer.android.com/guide/components/fundamentals

[22] Android, Introduction to Activities. https://developer.android.com/guide/components/activities/intro-activities

[23] Android, Understand the Activity Lifecycle. https://developer.android.com/guide/components/activities/activity-lifecycle

[24] Android, Content providers. https://developer.android.com/guide/topics/providers/content-providers

[25] Android, Intents and Intent Filters. https://developer.android.com/guide/components/intents-filters

[26] Android, App Manifest Overview. https://developer.android.com/guide/topics/manifest/manifest-intro

[27] Android, Secure an Android Device.

https://source.android.com/security

[28] Android, Application Sandbox.

https://source.android.com/security/app-sandbox

[29] Android, Permissions overview. https://developer.android.com/guide/topics/permissions/overview

[30] Android, Implementing eSIM. https://source.android.com/devices/tech/connect/esim-overview

[31] Android, UICC Carrier Privileges. https://source.android.com/devices/tech/config/uicc

[32] Naveen, iOS Architecture, IntelliPaat, December 2019.

https://intellipaat.com/blog/tutorial/ios-tutorial/ios-architecture/

[33] Apple, Xcode.

https://developer.apple.com/documentation/xcode

[34] Apple, UIKit.

https://developer.apple.com/documentation/uikit

[35] Apple, About App Development with UIKit. https://developer.apple.com/documentation/uikit/about_app_development_with_uikit

[36] Apple, Managing Your App’s Life Cycle.

https://developer.apple.com/documentation/uikit/app_and_environment/managing_your_app_s_life_cycle Accessed: 2020-04-17.

[37] Apple, Scenes. https://developer.apple.com/documentation/uikit/app_and_environment/scenes

[38] Apple, Entitlements.

https://developer.apple.com/documentation/bundleresources/entitlements

[39] Apple, About Entitlements.

https://developer.apple.com/library/archive/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/AboutEntitlements.html

[40] Apple, Core Telephony. https://developer.apple.com/documentation/coretelephony

[41] Apple, CTCellularPlanProvisioning.

https://developer.apple.com/documentation/coretelephony/ ctcellularplanprovisioning

[42] Apple, addPlan(with:completionHandler:). https://developer.apple.com/documentation/coretelephony/ctcellularplanprovisioning/2981838-addplan

[43] Apple, CTCellularPlanProvisioningRequest.

https://developer.apple.com/documentation/coretelephony/ctcellularplanprovisioningrequest