US20220086611A1 - Connected Vehicle Network Access Optimization Using an Intermediary Platform - Google Patents

Abstract

Concepts and technologies directed to connected vehicle network access optimization are disclosed herein. Embodiments can include a system that includes a processor and a memory storing computer-executable instructions that configure a processor to perform operations. The operations can include receiving an access probe message from a telematics control unit of a vehicle. The operations can include determining that the telematics control unit is not authorized to access a network communication service. The operations can further include generating an access redirect command that instructs a head unit of the vehicle to bypass a machine-to-machine platform so as to enable access to the network communication service via a network service portal. The operations can include providing the access redirect command to the telematics control unit of the vehicle.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This application is a continuation of and claims priority to U.S. Patent Application No. 16/283,316, entitled “Connected Vehicle Network Access Optimization Using an Intermediary Platform,” filed Feb. 22, 2019, now allowed, which is incorporated herein by reference in its entirety.
BACKGROUND
• Historically, communications networks were relegated to providing communicative coupling between communication equipment that was stationary and thus associated with a fixed or otherwise constant geographical location. With the rise of portable user equipment with wireless communication functionality, communicative coupling with a communications network and/or peer devices may occur from a variety of locations. The implementation of communicative coupling into vehicles can facilitate the advancement of autonomous vehicles that customers may use in their daily commutes along roadways, highways, and/or any other thoroughfare. Yet, as more vehicles are equipped with communication functionality, the communications network may limit network access only to recognized vehicles. In some instances, vehicles may attempt to communicate with the communications network irrespective of whether a particular vehicle is authorized to use that communications network. As more vehicles send communications between each other and/or with the communications network, the communications network may consume additional network resources to accommodate or otherwise support communicative coupling. As such, the amount of communications generated by vehicles may contribute to network congestion, which in turn can also affect end-to-end network latency.
SUMMARY
• The present disclosure is directed to connected vehicle network access optimization, according to various embodiments. According to one aspect of the concepts and technologies disclosed herein, a system is disclosed. In some embodiments, the system can include a core server, a machine-to-machine server, and/or a telematics control unit. In some embodiments, the system can include a processor and a memory. The memory can store computer-executable instructions that, in response to execution by the processor, cause the processor to perform operations. In some embodiments, the operations can include receiving an access probe message from a telematics control unit of a vehicle. The operations can include determining that the telematics control unit is not authorized to access a network communication service. The operations can include generating an access redirect command that instructs a head unit of the vehicle to bypass a machine-to-machine platform so as to enable access to the network communication service via a network service portal. The operations can include providing the access redirect command to the telematics control unit of the vehicle.
• In some embodiments, the access probe message comprises a probe uniform resource locator that is associated with the network communication service. In some embodiments, the access probe message requests forwarding of the access probe message to a core server associated with the network communication service. In some embodiments, the operations can further include preventing the access probe message from being forwarded to a core server associated with the network communication service. In some embodiments, the operations can further include generating an authorized access policy map associated with the network communication service, where the authorized access policy map is based on an access policy from a core server that supports the network communication service. In some embodiments, determining that the telematics control unit is not authorized to access the network communication service can be based on the telematics control unit having a telematics control unit identifier that does not correspond with an authorized identifier of the authorized access policy map. In some embodiments, the operations can further include receiving an access update message from the core server that supports the network communication service and instantiating an instance of an authorized identifier on the authorized access policy map for the telematics control unit of the vehicle.
• According to another aspect of the concepts and technologies disclosed herein, a method is disclosed according to an embodiment. In some embodiments, the method can include receiving, by a server of a serving network, an access probe message from a telematics control unit of a vehicle. The method can include determining, by the server, that the telematics control unit is not authorized to access a network communication service. The method can include generating, by the server, an access redirect command that instructs a head unit of the vehicle to bypass a machine-to-machine platform so as to enable access to the network communication service via a network service portal. The method can further include providing, by the server, the access redirect command to the telematics control unit of the vehicle.
• In some embodiments, the access probe message can include a probe uniform resource locator that is associated with the network communication service. In some embodiments, the access probe message requests forwarding of the access probe message to a core server associated with the network communication service. In some embodiments, the method can further include preventing, by the server, the access probe message from being forwarded to a core server associated with the network communication service. The method can further include generating, by the server, an authorized access policy map associated with the network communication service, where the authorized access policy map can be based on an access policy from a core server that supports the network communication service. In some embodiments, determining that the telematics control unit is not authorized to access the network communication service is based on the telematics control unit having a telematics control unit identifier that does not correspond with an authorized identifier of the authorized access policy map. The method can further include receiving, by the server, an access update message from the core server that supports the network communication service. The method can further include instantiating, by the server, an instance of an authorized identifier on the authorized access policy map for the telematics control unit of the vehicle.
• According to another aspect of the concepts and technologies disclosed herein, a computer storage medium is disclosed according to an embodiment. The computer storage medium can have computer-executable instructions stored thereon that, in response to execution by a processor, cause the processor to perform operations. The operations can include receiving an access probe message from a telematics control unit of a vehicle. The operations can include determining that the telematics control unit is not authorized to access a network communication service. The operations can include generating an access redirect command that instructs a head unit of the vehicle to bypass a machine-to-machine platform so as to enable access to the network communication service via a network service portal. The operations can include providing the access redirect command to the telematics control unit of the vehicle.
• In some embodiments, the access probe message can include a probe uniform resource locator that is associated with the network communication service, and the access probe message requests forwarding of the access probe message to a core server associated with the network communication service. In some embodiments, the operations further can include preventing the access probe message from being forwarded to a core server associated with the network communication service. The operations can further include generating an authorized access policy map associated with the network communication service, where the authorized access policy map is based on an access policy from a core server that supports the network communication service. In some embodiments, determining that the telematics control unit is not authorized to access the network communication service is based on the telematics control unit having a telematics control unit identifier that does not correspond with an authorized identifier of the authorized access policy map. In some embodiments, the operations further can include receiving an access update message from the core server that supports the network communication service, instantiating an instance of an authorized identifier on the authorized access policy map for the telematics control unit of the vehicle.
• It should be appreciated that the above-described subject matter may be implemented as a computer-controlled apparatus, a computer process, a computing system, a method, or as an article of manufacture such as a computer storage medium. These and various other features will be apparent from a reading of the following Detailed Description and a review of the associated drawings. This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended that this Summary be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 is a block diagram illustrating an example operating environment for implementing connected vehicle network access optimization, according to an illustrative embodiment.
• FIG. 2 is a block diagram illustrating aspects of a vehicle capable of implementing aspects of the embodiments disclosed herein.
• FIG. 3 is a flow diagram illustrating aspects of a method for network access optimization to support vehicle communications, according to an illustrative embodiment.
• FIG. 4 is a flow diagram illustrating aspects of another method for network access optimization to support vehicle communications, according to an illustrative embodiment.
• FIG. 5 is a diagram illustrating an example network capable of implementing aspects of the embodiments discussed herein.
• FIG. 6 is a block diagram illustrating an example computer system capable of implementing aspects of the embodiments presented and described herein.
• FIG. 7 is a diagram illustrating an example user equipment capable of implementing aspects of the concepts and technologies described herein according to embodiments of the present disclosure.
DETAILED DESCRIPTION
• The following detailed description is directed to connected vehicle network access optimization, according to various embodiments. Vehicles may be manufactured with various computer systems that can execute vehicle applications. Some vehicle applications may be configured to rely on network access so that certain functions, operations, and/or user interfaces and graphics may be presented to a user within the vehicle. In some instances, a vehicle application may be considered an over-the-top (“OTT”) application based on the OTT application relying on network infrastructure to deliver audio, video, information, calls, a combination thereof, or other content to and/or from a service and/or platform on a network. In some embodiments, an instance of an OTT application that is implemented or otherwise included for operation in and/or with a vehicle (e.g., executing on a vehicle head unit) may be referred to as a “vehicle OTT application.” In some embodiments, a developer of a vehicle OTT application may be pre-loaded and/or installed onto a vehicle head unit. Some vehicle OTT applications may operate with a configuration that assumes the state of network access is “always on” (i.e., the vehicle OTT application always has access to a network connection via the vehicle communication equipment) or “always denied” (i.e., the vehicle OTT application is always denied network access via the vehicle's communication equipment, such as a telematics control unit). In some instances, a vehicle OTT application may assume that access to a network is available because a connection to a network can be found. If a network connection is found (or assumed to be present), the vehicle OTT application may attempt to connect with a network service. Yet the connection and/or access to the network service may be denied due to the vehicle not being registered or otherwise authorized to use the network service. As more vehicles send and receive communications to/from the network, the communications network may consume additional network resources to accommodate or otherwise support attempts at network access to utilize a network service, despite the vehicle OTT application not being authorized for access via the vehicle. As such, the amount of communications generated by vehicles may contribute to network congestion, which may burden network infrastructure and in turn can also affect end-to-end network latency.
• Therefore, embodiments of the disclosure can provide connected vehicle network access optimization that enables various vehicle OTT applications to access a network service, while mitigating back-end network traffic that may burden or otherwise decrease network efficiency. Embodiments of the present disclosure provide a machine-to-machine platform that intercepts messages from a vehicle that are directed to a core server and/or an OTT server associated with execution of the vehicle OTT application. In various embodiments, all and/or any communications may initially be routed through the machine-to-machine platform irrespective of where the message is targeted or directed. In some embodiments, the machine-to-machine platform can enable a vehicle communications to bypass the machine-to-machine platform by creating and providing an access redirect command to the vehicle. If the vehicle (and thus also a telematics control unit of the vehicle) is not authorized to use the network communications service, embodiments of the present disclosure can enable the vehicle head unit to be informed that the vehicle is currently not authorized to use the network communication service (i.e., blocked) despite the vehicle being within a functioning service area of the serving network (i.e., within range of send/receiving communications with the serving network). Embodiments of the present disclosure can prevent the vehicle from receiving service from the OTT server via the serving network until the vehicle is authorized by the core server to use the network communications service. As such, the machine-to-machine server can provide, to the vehicle, an access redirect command that causes the vehicle's telematics control unit to directly contact the core server—without being routed through the machine-to-machine platform—so that the vehicle can access a network service portal and become authorized to utilize the network communication service so as to contact the OTT server through the machine-to-machine platform. By this, the vehicle head unit will not merely present “no service” when a vehicle is within communicative coupling range of the serving network but not authorized to use the network communication service, but rather the vehicle head unit and the vehicle telematics control unit can be configured to bypass the machine-to-machine platform so as to obtain authorization to use the network communication service. Once the machine-to-machine platform is updated to reflect the authorization for the vehicle, then communications (e.g., messages, media content streams, etc.) to/from the vehicle will be intercepted and rerouted through the machine-to-machine platform, and allowed to pass through (e.g., released, forwarded, routed, or otherwise provided) to the target destination, such as the OTT server associated with the vehicle OTT application. These and other aspects of the concepts and technologies disclosed herein will be illustrated and described in more detail below.
• While some of the subject matter described herein may occasionally be presented in the general context of program modules that execute in conjunction with the execution of an operating system and application programs on a computer system, those skilled in the art will recognize that other implementations may be performed in combination with other types of program modules. Generally, program modules include routines, programs, components, data structures, and other types of structures that perform particular tasks or implement particular abstract data types in response to execution on a processor so as to transform the processor into a particular machine. Moreover, those skilled in the art will appreciate that the subject matter described herein may be practiced with other computer system configurations, including hand-held devices, vehicle computer systems, network access nodes, network servers, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and other particularized, non-generic machines.
• Referring now toFIG. 1, aspects of an operatingenvironment100 for implementing various embodiments of the concepts and technologies disclosed herein pertaining to connected vehicle network access optimization will be described, according to an illustrative embodiment. It should be understood that the operatingenvironment100 and the various components thereof have been illustrated for clarity purposes to simplify the manner of discussion. Accordingly, additional and/or alternate components can be made available or otherwise implemented within the operatingenvironment100 without departing from the embodiments described herein. As such, the manner of discussion is provided such that one of ordinary skill in the technology can implement one or more embodiments described herein.
• The operatingenvironment100 shown inFIG. 1 includes one or more instance of aserving network102, one or more instances of anetwork access point104, a machine-to-machine platform (“M2M platform”)108, a machine-to-machine server (“M2M server”)110, a connected vehicle (“vehicle”)120, a communications network (“network”)130, one or more instances of anetwork access point132, and one or more instance of acore server134. The number of instances shown inFIG. 1 is for illustration purposes only and should not be construed as limiting in any way. Therefore, it is understood that zero, one, two, or more instances of each of the elements of the operatingenvironment100 shown inFIG. 1 may be provided in various embodiments.
• In the operatingenvironment100 shown inFIG. 1, an instance of the servingnetwork102 can refer to a radio access network that directly connects an instance of thevehicle120 to theM2M platform108, where theM2M platform108 controls and manages whether a device (e.g., the vehicle120) can access and utilize servers and services, such as but not limited to, an over-the-top server (“OTT server”)131, thecore server134, and/or anetwork communication service138, which are discussed in further detail below. The servingnetwork102 can include network infrastructure devices that can facilitate communication and messaging to and/or from an instance of thevehicle120 and/or thenetwork130. For example, the servingnetwork102 can include one or more instance of thenetwork access point104. Thenetwork access point104 can include, but should not be limited to, one or more of a base transceiver station, a wireless router, a femtocell, a Node B, an eNodeB, a gNodeB (i.e., an access point that incorporates New Radio access technology, such as LTE Advanced, and other 5G technology), a multi-standard metro cell node, an optical network terminal, and/or other network nodes or combinations thereof that are capable of providing communication to and/or from the servingnetwork102. In some embodiments, the servingnetwork102 may provide an initial point of contact for thevehicle120. TheM2M platform108 serves as an intermediary that enforces anaccess policy144 for use of, and access to, any of thenetwork130, theOTT server131, thecore server134, and/or thenetwork communication service138. As such, the servingnetwork102 may direct communications from thevehicle120 to theM2M platform108 to ensure network service compliance with access policy restrictions pertaining to the use of thenetwork communication service138, such as only allowing devices to use thenetwork communication service138 provided that they are identified in an authorized access policy map discussed below.
• TheM2M platform108 can include a connectivity management and handling system for supporting communications by various machine-to-machine and Internet of Things (“IoT”) devices, such as thevehicle120 and other wireless communication devices that can connect to, and interact with, the servingnetwork102. In some embodiments, theM2M platform108 may be referred to as an IoT platform that supports the servingnetwork102. In some embodiments, theM2M platform108 can include one or more instances of an M2M server, such as theM2M server110. In some embodiments, a communication service provider associated with thenetwork communication service138 may use theM2M platform108 to control network traffic that is directed to the network130 (and/or a core server, such as thecore server134 of the network130) so that network access and exposure of thenetwork communication service138 is limited to only those devices that are subscribed or otherwise authorized to utilize and access thenetwork communication service138. It is understood that theM2M platform108 can include various virtualized and/or non-virtualized non-generic network infrastructure devices that support and provide functionality for theM2M platform108, such as theM2M server110. An example of a computer system that can be configured as an embodiment of theM2M server110 is discussed with respect toFIG. 6. It is understood that other network infrastructure devices can support theM2M platform108, such as but not limited to, routers, switches, and any other device discussed with respect to theserving network102. In various embodiments, an instance of theM2M server110 can include one or more instances of a processing unit and a memory storage device, such as a processor111 and amemory112, respectively. The processor111 can include one or more instance of a processing unit and/or processing circuitry, which may execute to provide virtualized and/or non-virtualized processing. The processor111 can include a central processing unit, a graphics processing unit, a system-on-chip, a combination thereof, of the like. The processor111 can be configured substantially similar to a processing unit discussed with respect toFIG. 6. In some embodiments, thememory112 can include volatile and/or non-volatile memory implemented in any method or technology for storage of information such as computer-executable instructions, data structures, software program modules, or other data disclosed herein. It is understood that, use of the term “memory” and “computer storage medium” and variations thereof in the claims does not include, and shall not be construed to include, a wave or a signal per se and/or communication media. Thememory112 can include a computer storage device that is configured substantially similar to memory discussed further below with respect toFIG. 6. It should be understood that the examples provided are for illustration purposes only, and therefore should not be construed as limiting in any way.
• In various embodiments, thememory112 can store an authorized access policy map (“AAPM”)114 and a network exposure manager application (“NEMA”)118. In some embodiments, theAAPM114 can be generated and stored within theM2M platform108 based on theaccess policy144 that corresponds to thenetwork communication service138. TheNEMA118 can control which devices (e.g., instances of a telematics control unit) are authorized to access thenetwork communication service138, and in turn theNEMA118 can control whether one or more instances of a vehicle over-the-top application (“vehicle OTT application”)124 can operate, execute, and/or function on a vehicle head unit (“head unit”)122 of thevehicle120, specifically because thevehicle OTT application124 relies on thenetwork communication service138 to function and maintain execution. Without access by thevehicle OTT application124 to the network communication service138 (provided at least in part by thenetwork130 and/or the serving network102), execution of thevehicle OTT application124 cannot be sustained because thevehicle OTT application124 cannot contact an OTT server, such as theOTT server131. Further discussion of theAAPM114 and theNEMA118 will be provided below. It is understood that any of the servingnetwork102, theM2M platform108, and theM2M server110 may communicate with thevehicle120, thenetwork130, and any devices included therein. In some embodiments, theM2M platform108 may be associated with third party communication providers so as to provide IoT management for thenetwork communication service138. It is understood that the use of the term “service” is intended to correspond with one or more network operations that support handling of communications and messages (e.g., messages to and/or from the vehicle120) over the servingnetwork102 and/or thenetwork130. Therefore, any use of the term “service” in the claims shall not be construed or interpreted as being direct to, involving, or otherwise including a judicial exception (e.g., an abstract idea, etc.) or any other non-patentable subject matter. It should be understood that the examples provided are for illustration purposes only, and therefore should not be construed as limiting in any way.
• In the operatingenvironment100 shown inFIG. 1, an instance of thevehicle120 is represented as a car driving along a paved roadway, although this may not necessarily be the case for all embodiments. As used herein, the terms “vehicle” and “connected vehicle” (e.g., the vehicle120) refers to any ground-based vehicle that includes communication components and/or user equipment capable of sending and/or receiving communications with a network (e.g., the servingnetwork102 and/or the network130), where the ground-based vehicle can be configured to transport, carry, direct, and/or facilitate movement of one or more passengers, cargo, and/or objects. By way of example without limitation, an instance of thevehicle120 can be configured as a car, a truck, a van, a sport utility vehicle, a cross-over vehicle, a motorcycle, a motorized tricycle, a scooter, a go-kart, a golf cart, a fork lift, a bus, a semi-trailer truck, a racing vehicle, a snow-capable vehicle, earth-moving equipment, farming/agriculture equipment, single or multi-wheeled vehicle, combinations thereof, or the like. It is understood that instances of vehicles may use various power/engine mechanisms to provide movement and/or functionality, such as but not limited to motors and/or engines that employ the use of fuel, oil, batteries, combinations thereof, or the like. Although one instance of a vehicle (i.e., the vehicle120) is illustrated inFIG. 1, it is understood that less than two or more than two instances of a vehicle can be included in various embodiments of the operatingenvironment100. It should be understood that the examples provided are for illustration purposes only, and therefore should not be construed as limiting in any way.
• In some embodiments, an instance of thevehicle120 can be driven, controlled, directed, or otherwise operated by a person. In some embodiments, an instance of thevehicle120 may be configured to operate in at least a partially autonomous control mode. In some embodiments, an instance of thevehicle120 may be configured to operate as a fully autonomous vehicle. In some embodiments, an instance of thevehicle120 can operate as a “level 3” or “level 4” vehicle as defined by the National Highway Traffic Safety Administration (“NHTSA”). The NHTSA defines a level 3 vehicle as a limited self-driving automation vehicle that enables a driver to cede full control of all safety-critical functions under certain traffic or environmental conditions, and in those conditions to rely heavily on the vehicle to monitor for changes that require transition back to driver control. In a level 3 vehicle, the driver is expected to be available for occasional control, but with sufficiently comfortable transition time. By way of example, a limited self-driving automation vehicle may be available from WAYMO LLC, a subsidiary of ALPHABET INC.; TESLA INC.; and/or the VOLVO CARS CORPORATION. It should be understood that the examples provided are for illustration purposes only, and therefore should not be construed as limiting in any way. The NHTSA defines a level 4 vehicle as a fully self-driving automation vehicle that is designed to perform all safety-critical driving functions and monitor roadway conditions for an entire trip to a destination. Such fully self-driving design anticipates that a user will provide destination or navigation input, but the user is not expected to be available for control at any time during the trip. As such, a level 4 vehicle may include both occupied and unoccupied vehicles. Instances of thevehicle120 can include any combination of the aforementioned vehicle types and can have any combination of capabilities with regard to autonomy. It is understood that the aforementioned discussion of standards defined by the NHTSA are provided for illustration purposes only, and therefore should not be construed as limiting in any way. It is understood that alternate standards, specifications, and/or definitions used to describe levels of autonomous driving modes may be developed and/or adopted by various industry groups and/or companies, such as but not limited to the Society of Automotive Engineers (“SAE”) International, the Federal Communications Commission (“FCC”), the Institute of Electrical and Electronics Engineers (“IEEE”), or other industry group. Therefore, it should be understood that the examples provided are for illustration purposes only, and therefore should not be construed as limiting in any way.
• In some embodiments, an instance of thevehicle120 can include a vehicle head unit (“head unit”), such as thevehicle head unit122, and a telematics control unit (“TCU”)128. Thehead unit122 can include one or more instances of a display device (“display”) for presenting a user interface that can provide visual images. Thehead unit122 also can include (and/or be communicatively coupled to) input and output components that provide audio output and receive input from a user, such as via one or more speakers and/or microphones. In some embodiments, aninput127 can be provided to thehead unit122 via audio input, visual input, touch input, combinations thereof, or the like. In some embodiments, thehead unit122 can be configured to include (and/or be communicatively coupled to) a heads up display, a vehicle information display, a console display, safety mechanisms (e.g., blind-spot sensors, crash avoidance, lane detection, auto-steering, etc.), a combination thereof, or any other audio, visual, and/or haptic feedback mechanism that can communicate or convey information to a user associated with thevehicle120. In some embodiments, one or more instances of information and/or commands can be presented to a user of thevehicle120 through visual presentation and/or audio presentation via one or more instance of thehead unit122. In some embodiments, thehead unit122 and/or theTCU128 can be configured at least similar to a user equipment discussed with respect toFIG. 7. For example, various embodiments of thehead unit122 and/or theTCU128 can include elements discussed therein, such as one or more instance of a processor, memory, communications components, and the like. In some embodiments, thehead unit122 and/or theTCU128 can be configured substantially similar to a vehicle head unit and a TCU discussed with respect toFIG. 2. For clarity, aspects of elements from a user equipment that can be included within thehead unit122 and/or theTCU128 will be provided with respect toFIGS. 2 and 7. It should be understood that the examples provided are for illustration purposes only, and therefore should not be construed as limiting in any way.
• In various embodiments, thehead unit122 can include one or more instances of a vehicle OTT application, such as thevehicle OTT application124. Thevehicle OTT application124 can be stored in, and executed from, a memory storage device, such as a vehicle memory discussed with respect toFIG. 2. Examples of an instance of thevehicle OTT application124 can include, but should not be limited to, applications pertaining to social media, visual and/or audio calls, messaging, streaming media content (audio and/or video), geolocation mapping and/or traffic, news, weather, vehicle information, safety, or any other OTT application that can interact with and/or utilize a network communication service, such as thenetwork communication service138, which will be discussed below in further detail. It is understood that the examples provided are for illustration purposes only, and therefore should not be construed as limiting in any way. An instance of thevehicle OTT application124 can be associated with anapplication identifier126. Each instance of theapplication identifier126 can be a unique string that is associated with the particularvehicle OTT application124. Theapplication identifier126 can be included in messages to/from thevehicle120. Theapplication identifier126 can be used to determine whether the correspondingvehicle OTT application124 is authorized to access thenetwork communication service138 via thevehicle120. In some embodiments, theinput127 can trigger thehead unit122 to launch and/or execute an instance of thevehicle OTT application124. In some embodiments, theinput127 can be provided to thehead unit122 while thevehicle OTT application124 is already executing. Thevehicle OTT application124 may seek to connect and communicate with theOTT server131 because theOTT server131 may provide data, content, interfaces, and any other packet information that allows use and operation of thevehicle OTT application124. Further discussion of an instance of theOTT server131 is provided below. It is understood that the examples provided are for illustration purposes only, and therefore should not be construed as limiting in any way.
• In various embodiments, theTCU128 can be configured substantially similar to a TCU discussed with respect toFIG. 2. TheTCU128 can send, receive, and/or control communication flow to/from thehead unit122. TheTCU128 can include communication components and circuitry that provide and support communicative coupling with other devices and networks, such as but not limited to, the servingnetwork102, thenetwork130, theM2M platform108, and thecore server134. TheTCU128 can indicate an amount of signal strength, available network connections, and other information pertaining to communication to/from thevehicle120. In some embodiments, information provided by theTCU128 can be presented to a user via thehead unit122. TheTCU128 can expose one or more network communication interfaces that provide communication links to various network access points, such as thenetwork access points104 and/or132. TheTCU128 can provide and be associated with aTCU identifier128A. TheTCU identifier128A can be unique to thevehicle120 and/or theTCU128, and therefore be used by network infrastructure of the servingnetwork102 and/or thenetwork130 to determine whether thevehicle120 is authorized to access and utilize OTT applications and network services, such as thevehicle OTT application124 and/or thenetwork communication service138. In some embodiments, theTCU identifier128A may include and/or correspond with an international mobile equipment identity, a subscriber identity module number, an electronic serial number, a combination thereof, or another identifier assigned or associated with theTCU128. It is understood that the examples provided are for illustration purposes only, and therefore should not be construed as limiting in any way.
• In the operatingenvironment100 shown inFIG. 1, an instance of thenetwork130 can be in communication with one or more instances of the servingnetwork102, thevehicle120, user equipment, other network devices, combinations thereof, or the like. Thenetwork130 can include one or more instances of thenetwork access point132 and other network infrastructure devices. Thenetwork access point132 can be configured at least similar to one or more embodiments of thenetwork access point104 discussed above. In some embodiments, thenetwork130 can refer to and/or include a core network that has network devices, servers, services, applications, and functions that support legacy, current, and/or future standards, such as 3G, 4G, LTE, 5G, or later architecture. For example, in some embodiments, thenetwork130 can include, support, and/or provide one or more of an evolved universal mobile telecommunications system (“UMTS”), an evolved packet core (“EPC”), a terrestrial radio access (“E-UTRAN”) device, a mobility management entity (“MME”), a serving/packet data network (“PDN) gateway (“S/PGW”), a home subscriber server (“HSS”), a mobile edge computing (“MEC”) unit, a Policy & Charging rules function (“PCRF”), an Internet Protocol Multimedia Subsystem (“IMS”), a combination thereof, and/or any other systems, devices, and/or functions that may be included in one or more of 3G, 4G, LTE, 5G, or later network architecture and standards. In some embodiments, thenetwork130 may be referred to as a “core network” that provides a software defined network (“SDN”) architecture to support functionality and communication via 5G, New Radio, and/or other standards and protocols via the implementation of centralized and/or distributed network host devices (which may be virtualized and/or non-virtualized).
• In some embodiments, thenetwork130 can include one or more instance of a core server, such as thecore server134. Thecore server134 can include aprocessor135 and amemory136. Theprocessor135 can include one or more instance of a processing unit and/or processing circuitry, which may execute to provide virtualized and/or non-virtualized processing. Theprocessor135 can include a central processing unit, a graphics processing unit, a system-on-chip, a combination thereof, of the like. Theprocessor135 can be configured substantially similar to a processing unit discussed with respect toFIG. 6. In some embodiments, thememory136 can include volatile and/or non-volatile memory implemented in any method or technology for storage of information such as computer-executable instructions, data structures, software program modules, or other data disclosed herein. It is understood that, use of the term “memory” and “computer storage medium” and variations thereof in the claims does not include, and shall not be construed to include, a wave or a signal per se and/or communication media. Thememory136 can include a computer storage device that is configured substantially similar to memory discussed further below with respect toFIG. 6. It should be understood that the examples provided are for illustration purposes only, and therefore should not be construed as limiting in any way.
• In some embodiments, thecore server134 can reside in, and/or form a portion of, thenetwork130 and can, at least partially, support, host, or otherwise provide thenetwork communication service138 so as to enable various devices (e.g., theTCU128 of the vehicle120) to access and communicate with theOTT server131 via theserving network102 and/or thenetwork130. In some embodiments, thecore server134 can be configured to provide and/or support a policy control function (“PCF”)145 and an access and mobility function (“AMF”)146. In some embodiments, thenetwork130 and/or thecore server134 can, at least partially, support, host, or otherwise provide access to one or more of a session management function, an access and mobility management entity, an authentication server function, a user data management function, a user plane function, a network exposure function, unified data management (“UDM”), an application function (“AF”), an enhanced mobile broadband system (“eMBBS”), a combination thereof, and/or other applications, systems, and/or functions that may support a network architecture. It should be understood that the examples provided are for illustration purposes only, and therefore should not be construed as limiting in any way.
• In some embodiments, thecore server134 can store an instance of computer readable instructions so as to configure one or more processors to perform operations. In some embodiments, the computer readable instructions can be provided by acontrol application140 that is stored in thememory136. Thecore server134 can be associated with a communication service provider that supports and/or facilitates the operation of thenetwork communication service138. Thenetwork communication service138 enables user equipment and devices (e.g., theTCU128 of the vehicle120) to communicate over the servingnetwork102 and/or thenetwork130 so as to provide access and communicative coupling to devices and services associated with thevehicle OTT application124, such as theOTT server131. Thenetwork communication service138 can provide and include transport layer functionality across a network, such as the servingnetwork102 and/or thenetwork130, so that user equipment and devices (e.g., the vehicle120) can engage in wireless and/or wired communication coupling to access services and devices associated with thevehicle OTT application124, such as theOTT server131 that can provide a content data stream (“content stream”)166 to thevehicle OTT application124 executing on thevehicle120. Thecontent stream166 can include a successive, associated group of data packets that uniquely configure and transform a processor, display device, and other hardware resources of the vehicle120 (e.g., thehead unit122 and any other elements discussed with respect toFIG. 2) for continued execution of thevehicle OTT application124. In various embodiments, thecontent stream166 can provide one-way and/or two-way audio, video, images, user interfaces, text, combinations thereof, or any other information within data packets for operation by thevehicle120 and/or thehead unit122. Thecontent stream166 may be provided to a corresponding instance of thevehicle OTT application124 only after theM2M platform108 has determined that the corresponding vehicle120 (and thus theTCU128 and/or head unit122) is authorized to use thenetwork communication service138. For example, after theM2M platform108 redirects thevehicle120 to the network service portal142 (e.g., via an access redirect request discussed below) so as to bypass theM2M platform108 and cause theTCU128 to obtain authorization to thenetwork communications service138, theAAPM114 can be updated (i.e., reconfigured and instantiated with an authorization identifier that reflects the TCU128), thereby authorizing thevehicle OTT application124 to contact theOTT server131 via the M2M platform108 (which can intercept all communications as an intermediary to determine which communications should be allowed to pass through the servingnetwork102 and which communications should be blocked based on the particular vehicle from which the communication is sent). As such, if thevehicle120 is authorized to use the network communication service138 (e.g., based on thevehicle120 being identified in the AAPM114), then thecontent stream166 can be generated by theOTT server131, routed through theM2M platform108, and to theTCU128 and thehead unit122 of thevehicle120. It is understood that thevehicle120 can continue to use thenetwork communication service138 while thevehicle120 is within communicative coupling range of a corresponding network (e.g., the servingnetwork102 and/or the network130) and while thevehicle120 is authorized on theAAPM114 to use thenetwork communication service138, thereby allowing for pass-through communications via theM2M platform108. A communication service provider associated with thenetwork communication service138 can limit, manage, and/or control the use of, and access to, the servingnetwork102 and/ornetwork130 that provides a network path to theOTT server131.
• In various embodiments, thenetwork130 also can include one or more instance of theOTT server131. TheOTT server131 can be associated with an instance of thevehicle OTT application124. TheOTT server131 can provide content and data (e.g., a content stream of data packets and/or individual responses to requests) to thevehicle OTT application124 via theM2M platform108 because theM2M platform108 may enforce theaccess policy144 on behalf of thecore server134. For example, in an embodiment, thevehicle OTT application124 may execute streaming audio content that is provided by theOTT server131. Any of thehead unit122, thevehicle OTT application124, and theTCU128 may seek to communicate with theOTT server131 so that thevehicle OTT application124 can execute and/or maintain functionality for providing output within thevehicle120. However, access to theOTT server131 may depend on the vehicle120 (and/or one or more devices therein such as theTCU128, thehead unit122, etc.) being authorized to use thenetwork communication service138 so that communications from thevehicle120 can be routed to theOTT server131, which in turn may be hosted by thenetwork130.
• Use of thenetwork communication service138 that enables access to theOTT server131 may be enforced by theM2M platform108 and/or theM2M server110 based on theAAPM114 and/or an access policy, such as theaccess policy144. Thecontrol application140 can create and/or define an instance of theaccess policy144, where theaccess policy144 corresponds with access to thenetwork communication service138. Theaccess policy144 can be stored in network-accessible memory, such as thememory136. Theaccess policy144 may be defined and stored in a format that is readable by thecontrol application140, such as a data structure format, an executable routine, or other computer-executable and/or readable instructions. Theaccess policy144 can indicate parameters, rules, and/or instructions that must be met in order to allow and/or authorize use of thenetwork communication service138. For example, in some embodiments, theaccess policy144 can instruct or otherwise configure network infrastructure (e.g., thenetwork access point104, theM2M platform108, etc.) such that communications (e.g., messages and data) to and/or from any of thevehicle OTT application124, thehead unit122, theTCU128, thevehicle120, and/or theOTT server131 are to be routed through theM2M platform108 so that exposure and use of thenetwork communication service138 can be controlled to maintain network security.
• In various embodiments, theaccess policy144 may require that in order for a device to be authorized for ongoing communicative coupling with the servingnetwork102 and/or the network130 (including communicating with the OTT server131), the device must have or otherwise be associated with an instance of anequipment profile148 that reflects an active subscription with the communication service provider. An instance of theequipment profile148 can indicate that a user equipment and/or device (e.g., personal mobile phones, tablets, theTCU128 of thevehicle120 etc.) is authorized to use and/or have access to thenetwork communication service138 by having and recording an identifier associated with the device, such as an instance of a knownTCU identifier149. For example, a user associated with thevehicle120 may have a user equipment (e.g., a personal mobile phone) that is subscribed to thenetwork communication service138. Anetwork service portal142 can be associated with thenetwork communication service138. Thenetwork service portal142 can be hosted by the core server134 (or any other computer system associated with the network communication service138). Thenetwork service portal142 can provide a web page, application, or other user interface by which thevehicle120 can obtain or otherwise become permitted or otherwise authorized to use thenetwork communication service138. In some embodiments, a user associated with thevehicle120 may have to provide an instance of theinput127 to thehead unit122 so as to confirm that thevehicle120 will abide by theaccess policy144, thereby causing thecontrol application140 to create an instance of anequipment profile148 for theTCU128 of thevehicle120. If an equipment profile, such as theequipment profile148, associated with the user of thevehicle120 already exists, then thecontrol application140 can obtain that instance of theequipment profile148 and instantiate an identifier that reflects the identity of the TCU128 (or another device) of thevehicle120, such as the knownTCU identifier149. Instances of theequipment profile148 can be stored on thememory136. In some embodiments, theequipment profile148 may be part of a user account profile and/or can be linked to a subscription associated with the user and one or more devices that are authorized and permitted to engage in communicative coupling via thenetwork communication service138. An instance of theequipment profile148 can be associated with one or more corresponding device that is authorized to use thenetwork communication service138. For example, if a user has a mobile phone that is subscribed and authorized to use thenetwork communication service138, then the mobile phone will have (or be associated with) an instance of theequipment profile148 that provides an identifier associated with the user's mobile phone (e.g., a subscriber identity module identifier). In some embodiments, one instance of theequipment profile148 may store and identify multiple devices which are associated with a shared network account and/or subscription to thenetwork communication service138. For example, in some embodiments, the user may also be associated with thevehicle120, where thevehicle120 is capable of wireless communication via use of theTCU128. In some embodiments, prior to launching thevehicle OTT application124, the user may visit a network representative of the customer service provider and may initiate authorization to setup access to thenetwork communication service138 before thevehicle120 is in operation. However, a user may desire to enable thevehicle120 to engage in communicative coupling (e.g., to allow thevehicle OTT application124 to connect with the OTT server131) without going to see a network representative to manually setup thenetwork communication service138. Although the user may launch thevehicle OTT application124 and desire to access and use thenetwork communication service138 with thevehicle120, an instance of theequipment profile148 may not initially include an instance of a knownTCU identifier149 for the TCU128 (at the time in which thevehicle OTT application124 was launched via an instance of the input127), and therefore theM2M platform108 and/or thecore server134 may limit or otherwise prevent theTCU128 of thevehicle120 from accessing and using thenetwork communication service138, thereby preventing thevehicle OTT application124 from making contact with theOTT server131. TheTCU128 of thevehicle120 may be permitted to access and use thenetwork communication service138 only after an instance of theequipment profile148 stores an instance of the knownTCU identifier149 for theTCU128, and theM2M platform108 becomes aware that thevehicle120 is authorized to use the network communication service138 (e.g., theNEMA118 instantiating theAAPM114 with an instance of an authorizedidentifier116 that reflects theTCU identifier128A, and thus theTCU128 of thevehicle120, as further discussed below). The knownTCU identifier149 may be substantially similar to theTCU identifier128A, and therefore can identify thevehicle120 and/or theTCU128 associated with thevehicle120. TheTCU identifier128A (and thus also an instance of the known TCU identifier149) can refer to a unique identifier (e.g., an equipment identifier) for theTCU128 that operates in thevehicle120.
• TheM2M platform108 can enforce theaccess policy144 by confirming whether a device is authorized to use thenetwork communication service138. Specifically, theaccess policy144 can indicate that thenetwork communication service138 is allowed to be accessed and/or utilized only by devices (e.g., theTCU128 of the vehicle120) that have an instance of an identifier (e.g., the known TCU identifier149) that is associated with an instance of theequipment profile148. TheM2M platform108 can know, and/or be informed, of the state of the instance of theequipment profile148 via theAAPM114. TheAAPM114 can indicate which devices should be allowed to use theM2M platform108 to access thenetwork communication service138 based on whether an instance of an authorizedidentifier116 is present within theAAPM114. An instance of the authorizedidentifier116 provides an identity of a device that is authorized to access thenetwork communication service138 through theM2M platform108. Instances of authorized identifiers (e.g., any of authorizedidentifiers116A-N) can point to, or otherwise identify, a corresponding instance of the knownTCU identifier149 that is present and recorded within theequipment profile148 on thecore server134. The presence of an authorized identifier (e.g., any of authorizedidentifiers116A-N) within theAAPM114 indicates that a corresponding device is authorized to use thenetwork communication service138, and therefore theM2M platform108 can allow the corresponding device (e.g., theTCU128 of the vehicle120) to use thenetwork communication service138 andM2M platform108 in order to connect with theOTT server131. Therefore, if a message that is received by theM2M platform108 has an identifier (e.g., theTCU identifier128A) that matches one of the authorizedidentifiers116A-N of theAAPM114, then the corresponding device which sent the message (e.g., theTCU128 of the vehicle120) would be authorized to use thenetwork communication service138 and access theOTT server131 via theM2M platform108. If, however, the message includes an identifier that does not match any of the authorizedidentifiers116A-N of theAAPM114, then the corresponding device which sent the message would not be authorized to use thenetwork communication service138, thereby blocking messages from the device from being routed through theM2M platform108 to theOTT server131. For clarity, a brief discussion of an example communication flow will be provided with respect toFIG. 1. It should be understood that the examples provided are for illustration purposes only, and therefore should not be construed as limiting in any way.
• In various embodiments, the user of thevehicle120 may desire to execute thevehicle OTT application124 to provide output (e.g., audio and/or video data) via thehead unit122. The user can provide an instance of theinput127 to thehead unit122 to initiate execution of thevehicle OTT application124. Thehead unit122 can determine that thevehicle OTT application124 relies on a network connection to receive data for the vehicle OTT application124 (e.g., media data associated with an over-the-top service provided by the OTT server131). Thehead unit122 can generate an instance of anaccess probe message150 that requests access to thenetwork communication service138. Theaccess probe message150 can include a probe uniform resource locator (“probe URL”)152. Theprobe URL152 can refer to a network address string that is directed to a target destination that facilitates network communication for execution and operation of thevehicle OTT application124. Examples of the target destination can include thenetwork communication service138, thecore server134 associated with thenetwork communication service138, and/or theOTT server131. Theaccess probe message150 can also include theTCU identifier128A associated with theTCU128 of thevehicle120. At the time theinput127 is received by thehead unit122, thehead unit122 may not be aware of network reachability—that is, whether theTCU128 of thevehicle120 is authorized or otherwise permitted to use thenetwork communication service138. Thehead unit122 can pass or otherwise provide theaccess probe message150 to theTCU128. TheTCU128 can establish a connection with the servingnetwork102, and provide theaccess probe message150 to theserving network102.
• Thenetwork access point104 can relay theaccess probe message150 to theM2M platform108 of the servingnetwork102. TheNEMA118 may be executing on one or more servers of the M2M platform108 (e.g., the M2M server110). TheNEMA118 may receive and analyze theaccess probe message150. TheNEMA118 may determine that theaccess probe message150 is requesting forwarding to a target destination, such as one or more of thecore server134, thenetwork communication service138, and/or theOTT server131. Instead of forwarding theaccess probe message150 as requested, theNEMA118 may prevent theaccess probe message150 from being forwarded in order to confirm whether theTCU128 of thevehicle120 is authorized to access thenetwork communication service138. TheNEMA118 may access theAAPM114 and compare theTCU identifier128A against the authorizedidentifiers116A-N to determine whether a match exists. In some embodiments, if theAAPM114 indicates that one of the authorizedidentifiers116A-N matches or otherwise corresponds with theTCU identifier128A from theaccess probe message150, then theTCU128 of thevehicle120 is authorized to use thenetwork communication service138, so theNEMA118 permits the access probe message150 (or any other message) to be forwarded on from theM2M platform108 to the target destination. In another embodiment, if none of the authorizedidentifiers116A-N from theAAPM114 match or otherwise correspond with theTCU identifier128A, then theTCU128 is not authorized to access thenetwork communication service138.
• In embodiments where theNEMA118 determines that theTCU128 of thevehicle120 is not authorized to use thenetwork communication service138, theNEMA118 can generate anaccess redirect command154. Theaccess redirect command154 can instruct, via a redirect instruction, thehead unit122 of thevehicle120 to bypass theM2M platform108 so as to enable access to thenetwork communication service138 via thenetwork service portal142. Theaccess redirect command154 can include aredirect instruction156. In some embodiments, theaccess redirect command154 can conform to a Hypertext Transfer Protocol (HTTP) specification status code, such as but not limited to one or more ofHTTP status code302,303,307, or another status code discussed with respect to a standards document as understood by one of skill in the technology. Theredirect instruction156 can include aredirect URL158 that points to thenetwork service portal142 associated with thenetwork communication service138. Theredirect instruction156 can impart theredirect URL158 to thehead unit122 and/or theTCU128 so that theM2M platform108 is bypassed and access to thenetwork communication service138 can be enabled or otherwise obtained directly from thecore server134 via thenetwork service portal142, without being routed through theM2M platform108. TheNEMA118 can provide theaccess redirect command154 to theTCU128 of thevehicle120. In some embodiments, the access redirect command154 (and/or any other message discussed herein that is sent from and/or received by the vehicle120) can be configured according to a vehicle-to-network message format, such as but not limited to one or more of messaging in conformance with PC5, 802.11p, UU, LTE-V2X, or another standard that conforms with vehicle communications standards as understood by one of ordinary skill in the technology. In some embodiments, theaccess redirect command154 can provide the vehicle120 (and thus the TCU128) with a one-time bypass of theM2M platform108 so as to enable thevehicle120 to become authorized to use thenetwork communication service138 by contacting thecore server134 directly to access thenetwork service portal142 by bypassing theM2M platform108. Thus, if theM2M platform108 determines (after previously providing theaccess redirect command154 to the vehicle120) that thevehicle120 continues to be unauthorized to use thenetwork communication service138, then any communications from thevehicle120 can be intercepted and rerouted to theM2M platform108 so as to block and/or prevent the communications from reaching the target destination (e.g., the OTT server131), thereby preventing theOTT server131 from providing thecontent stream166 to thehead unit122 until theAAPM114 indicates that thevehicle120 is authorized to use thenetwork communication service138.
• In various embodiments, theTCU128 may receive theaccess redirect command154. In some embodiments, theTCU128 may relay or otherwise inform thehead unit122 of theaccess redirect command154 and any data included therein, such as theredirect instruction156 and theredirect URL158. TheTCU128 and/or thehead unit122 can generate an access redirect request message (“access redirect request”)160 based on theaccess redirect command154 and theredirect instruction156 from theM2M platform108. Theaccess redirect request160 can include theredirect URL158 that redirects theTCU128 to contact thenetwork service portal142 so as to bypass theM2M platform108 and enable thenetwork communication service138. TheTCU128 can send or otherwise provide theaccess redirect request160 to thecore server134 of thenetwork130 that hosts thenetwork service portal142. Theaccess redirect request160 can be routed from a network access point (e.g., any of thenetwork access points104,132) to thecore server134 such that theaccess redirect request160 is not intercepted by theM2M platform108 andM2M server110, thereby allowing theTCU128 to obtain access and authorization to thenetwork communication service138 via thenetwork service portal142. In some embodiments, thenetwork service portal142 can provide one or more user interfaces to thehead unit122 as to enable thevehicle120 to obtain authorization to use and access thenetwork communication service138. In various embodiments, the one or more user interfaces may be provided to theTCU128 and/or thehead unit122 in one or more instance of a network serviceportal response162. For example, in some embodiments, theaccess redirect request160 can include an instance of theTCU identifier128A associated with theTCU128. In some embodiments, while thevehicle120 is connected with thenetwork service portal142, the user can provide an instance of input to the head unit122 (and/or the TCU128) that indicates permission for the control application140 (on the core server134) to add the vehicle120 (and/or the TCU128) to a corresponding instance of theequipment profile148 so as to indicate that theTCU128 is an authorized device that is permitted to use thenetwork communication service138. In some embodiments, the user may also grant a communication service provider permission to change and/or upgrade a data plan for use of thevehicle120 with thenetwork communication service138. In various embodiments, thecontrol application140 can receive input from the user (e.g., via theTCU128 and/or thecontrol application140 engaging in one or more instances of theaccess redirect request160 and/or the network service portal response162) requesting access to and use of thenetwork communication service138 by thevehicle120. Thecontrol application140 can grant and enable theTCU128 of thevehicle120 to access thenetwork communication service138 by instantiating the knownTCU identifier149 within theequipment profile148 associated with thevehicle120 and/or user of thevehicle120. The knownTCU identifier149 that is recorded in theequipment profile148 matches, corresponds to, or otherwise reflects theTCU identifier128A associated with theTCU128 and thevehicle120 which is being granted permission to use thenetwork communication service138. To clarify, an instance of the knownTCU identifier149 that identifies (or otherwise corresponds with) the vehicle120 (and/or the TCU128) did not exist (or was not stored) in theequipment profile148 when thevehicle120 was unauthorized to use the network communication service138 (i.e., prior to theTCU128 of thevehicle120 being permitted to engage in use of thenetwork communication service138, and thus yet not permitted to contact the OTT server131). As such, the presence of the knownTCU identifier149 within theequipment profile148 indicates that a corresponding device (e.g., theTCU128 of the vehicle120) is permitted and authorized to use thenetwork communication service138. In some embodiments, theTCU128 may be informed that thevehicle120 is authorized to access thenetwork communication service138 via the network serviceportal response162.
• In various embodiments, when theequipment profile148 is updated to store an identifier (e.g., the known TCU identifier149) of a device that is now authorized to access thenetwork communication service138, thecontrol application140 may send anaccess update message170 to theNEMA118 of theM2M platform108. TheNEMA118 can extract and analyze the knownTCU identifier149 from theaccess update message170, and create an instance of the authorizedidentifier116 within the AAPM114 (e.g., any of the authorizedidentifiers116A-N) to correspond with, and identify, the knownTCU identifier149. As such, each instance of the authorizedidentifiers116A-N can correspond with and represent an identifier stored in an instance of the equipment profile148 (e.g., the authorizedidentifier116B being created and/or configured to represent the knownTCU identifier149 that is associated with theTCU128, theTCU identifier128A, and the vehicle120). When thevehicle120 initially sends theaccess probe message150 to theM2M platform108, theNEMA118 may not recognize thevehicle120 because theAAPM114 does not indicate that any of the authorizedidentifiers116A-N belong to theTCU128 of thevehicle120. Therefore, theM2M platform108 may deny thevehicle120 access to thenetwork communication service138 and prevent thevehicle OTT application124 from using theM2M platform108 to access theOTT server131. Yet once one of the authorizedidentifiers116A-N within theAAPM114 matches or otherwise corresponds with theTCU identifier128A provided by theTCU128, then theM2M platform108 may allow messages from thevehicle120 to pass through theM2M platform108 and use thenetwork communication service138.
• In some embodiments, once thevehicle120 is granted permission to use and engage in thenetwork communication service138, theTCU128 may send a subsequentaccess probe message150′. The subsequentaccess probe message150′ may include another instance of theprobe URL152, which is illustrated asprobe URL152′. The subsequentaccess probe message150′ may include theTCU identifier128A that is associated with theTCU128 and thevehicle120. TheM2M platform108 can determine that one of the authorizedidentifiers116A-N within theAAPM114 corresponds with theTCU identifier128A, and therefore theM2M platform108 can grant thevehicle120 access to thenetwork communication service138. In some embodiments, the subsequentaccess probe message150′ can be forwarded on to a target destination, such as one or more of thecore server134 and/or theOTT server131 via theM2M platform108. In some embodiments, thecore server134 and/orOTT server131 can receive the message sent from thevehicle120 via the M2M platform108 (e.g., theaccess probe message150 and/or the subsequentaccess probe message150′) and, in response, generate anaccess probe response164 that informs thevehicle120 that theTCU128 and thevehicle OTT application124 are permitted or otherwise authorized to connect with theOTT server131 because thevehicle120 is authorized to use thenetwork communication service138. In some embodiments, theaccess probe response164 can be sent from thecore server134 and/or theOTT server131 to thevehicle120 via the M2M platform108 (i.e., by theM2M platform108 being an intermediary point of access policy enforcement). In some embodiments, an instance of theaccess probe response164 can be provided directly to thevehicle120 so as to bypass theM2M platform108, where theaccess probe response164 can inform thevehicle120 that thehead unit122 and/or theTCU128 is authorized to use thenetwork communication service138. In some embodiments, thecontent stream166 may be provided to thevehicle OTT application124 after a subsequent instance of theaccess probe message150 is sent (e.g., an instance of the subsequentaccess probe message150′) to theM2M platform108, which determines that thevehicle120 is now authorized to use thenetwork communication service138. In some embodiments, when one or more of theM2M platform108 determines that thevehicle120 is authorized to use thenetwork communication service138, any previous and/or current communications that are directed a target destination (e.g., to the OTT server131) will no longer be blocked, but instead can be released, routed, and provided to the target destination (e.g., the OTT server131). TheM2M platform108 can continue to intercept communications (e.g., the content stream166) that are directed to and/or sent from thevehicle120 associated with thevehicle OTT application124, thereby enabling enforcement of the access policy and optimization of network resources because communications are routed to their final destination only when thecorresponding vehicle120 is authorized to use thenetwork communication service138.
• In some embodiments, if thevehicle120 and/orTCU128 violates one or more parameters of the access policy144 (e.g., exceed network usage, non-payment of service fee, nefarious network attacks from thevehicle120, etc.), thecontrol application140 may lock or otherwise prevent thevehicle120 from using thenetwork communication service138 by removing the knownTCU identifier149 from theequipment profile148. In turn, theNEMA118 may remove the corresponding authorized identifier from theAAPM114 so that when thevehicle120 attempts to contact theOTT server131 and/or thecore server134 to use thenetwork communication service138, theM2M platform108 can provide an access deniedresponse153 to inform thevehicle120 that access to thenetwork communication service138 has been withdrawn. It should be understood that the examples provided are for illustration purposes only, and therefore should not be construed as limiting in any way.
• FIG. 1 illustrates the operatingenvironment100 having one instance of the servingnetwork102, thenetwork access point104, theM2M platform108, theM2M server110, the processor111, thememory112, theAAPM114, the authorizedidentifiers116A-N, theNEMA118, thevehicle120, thehead unit122, thevehicle OTT application124, theapplication identifier126, theinput127, theTCU128, theTCU identifier128A, thenetwork130, theOTT server131, thenetwork access point132, thecore server134, theprocessor135, thememory136, thenetwork communication service138, thecontrol application140, thenetwork service portal142, theaccess policy144, thePCF145, theAMF146, theequipment profile148, the knownTCU identifier149, theaccess probe message150, theprobe URL152, the subsequentaccess probe message150′, theprobe URL152′, theaccess redirect command154, theredirect instruction156, theredirect URL158, theaccess redirect request160, and the network serviceportal response162, andaccess probe response164, and acontent stream166. It should be understood, however, that some implementations of the operatingenvironment100 can include zero, one, or more than one instances of the above listed elements shown inFIG. 1. As such, the illustrated embodiment of the operatingenvironment100 is understood to be illustrative and should not be construed as being limiting in any way.
• Turning now toFIG. 2 with continued reference toFIG. 1, a block diagram200 illustrating an instance of avehicle201 and aspects thereof will be described, according to an illustrative embodiment. It is understood that one or more instances of thevehicle120 illustrated and discussed with respect toFIG. 1 can be configured substantially similar to thevehicle201 shown and discussed with respect toFIG. 2. Thevehicle201 shown inFIG. 2 is illustrated for purposes of clarity of discussion, and therefore is provided as an example. It is understood that zero, one, or more than one instances of the components discussed herein with respect to thevehicle201 may be implemented in various embodiments. As such, the examples provided are for illustration purposes only, and therefore should not be construed as limiting in any way. The illustratedvehicle201 includes vehicle mechanical/electrical function components202, avehicle processor203, avehicle memory204, avehicle firmware206, avehicle operating system208, atelematics control unit209, one or morevehicle software application210, avehicle head unit211, adisplay211A, an input/output component211B, a vehiclewireless communications component212, an instance of avehicle communication interface218 that supports adirect transmission mode219, an instance of the network communication interface220 that supports thenetwork transmission mode221, a vehicle dedicated short-range communications (“DSRC”)component214, and a cellular vehicle-to-anything (“C-V2X”)component216. Each of these components will now be described in detail. It is understood that the term vehicle-to-anything (“V2X”) refers to a vehicle's communication ability (e.g., the vehicle201) through components (e.g., a telematics control unit) that are configured to communicate with one or more network or network infrastructure, such as the servingnetwork102, theM2M platform108, thenetwork130, theOTT server131, thecore server134, or the like. In some embodiments, a communication that is sent to and/or from a vehicle may be referred to as the implementation of vehicle-to-everything (“V2X”) communications, which can include one or more of vehicle-to-vehicle (“V2V”) communications, vehicle-to-infrastructure (“V2I”) communications, vehicle-to-network (“V2N”) communications, and/or vehicle-to-pedestrian (“V2P”) communications, and may facilitate communicative coupling between vehicles, infrastructure, a network, and/or pedestrians, respectively. It is understood that the examples provided are for illustration purposes only, and therefore should not be construed as limiting in any way.
• The vehicle mechanical/electrical function components202 can include mechanisms, circuitry, elements, and/or components of thevehicle201 that enable the vehicle to function and operate. For example, one or more instances of the vehicle mechanical/electrical function components202 can include, an engine, a transmission, a braking system, a transmission control unit, an engine control unit, a battery, an electrical system, a safety system, a heating ventilation and air conditioning system, a lighting system, a sensor system (e.g., a lane detection system, crash avoidance system, etc.), or any other component or element that may facilitate function of thevehicle201 and/or support one or more of the operations discussed herein.
• Thevehicle processor203 can include one or more hardware components that perform computations to process data, and/or to execute computer-executable instructions of one or more application programs such as the vehicle software application(s)210, one or more operating systems such as thevehicle operating system208, other software, and/or thevehicle firmware206. Thevehicle processor203 can include one or more central processing units (“CPUs”) and/or engine control units (“ECU”) configured with one or more processing cores. Thevehicle processor203 can include one or more graphics processing unit (“GPU”) configured to accelerate operations performed by one or more CPUs, and/or to perform computations to process data, and/or to execute computer-executable instructions of one or more application programs, operating systems, and/or other software that may or may not include instructions particular to graphics computations. In some embodiments, thevehicle processor203 can include one or more discrete GPUs. In some other embodiments, thevehicle processor203 can include CPU, ECU, and/or GPU components that are configured in accordance with a co-processing CPU/GPU computing model, wherein the sequential part of an application executes on the CPU and the computationally-intensive part is accelerated by the GPU. Thevehicle processor203 can include one or more system-on-chip (“SoC”) components along with one or more other components illustrated as being part of thevehicle201, including, for example, thevehicle memory204, the vehiclewireless communications component212, theDSRC component214, or some combination thereof. In some embodiments, thevehicle processor203 can be or can include one or more SNAPDRAGON SoCs, available from QUALCOMM of San Diego, Calif.; one or more TEGRA SoCs, available from NVIDIA of Santa Clara, Calif.; one or more HUMMINGBIRD SoCs, available from SAMSUNG of Seoul, South Korea; one or more Open Multimedia Application Platform (“OMAP”) SoCs, available from TEXAS INSTRUMENTS of Dallas, Tex.; one or more customized versions of any of the above SoCs; and/or one or more proprietary SoCs. Thevehicle processor203 can be or can include one or more hardware components architected in accordance with an ARM architecture, available for license from ARM HOLDINGS of Cambridge, United Kingdom. Alternatively, thevehicle processor203 can be or can include one or more hardware components architected in accordance with an x86 architecture, such an architecture available from INTEL CORPORATION of Mountain View, Calif., and others. Those skilled in the technology will appreciate the implementation of thevehicle processor203 can utilize various computation architectures, and as such, thevehicle processor203 should not be construed as being limited to any particular computation architecture or combination of computation architectures, including those explicitly disclosed herein.
• Thevehicle memory204 can include one or more hardware components that perform storage operations, including temporary or permanent storage operations. In some embodiments, thevehicle memory204 includes volatile and/or non-volatile memory implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, thevehicle operating system208, thevehicle firmware206, the vehicle software application(s)210, and/or other software, firmware, and/or other data disclosed herein. Computer storage media includes, but is not limited to, random access memory (“RAM”), read-only memory (“ROM”), Erasable Programmable ROM (“EPROM”), Electrically Erasable Programmable ROM (“EEPROM”), flash memory or other solid state memory technology, CD-ROM, digital versatile disks (“DVD”), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store data and which can be accessed by thevehicle processor203. Thevehicle memory204 may be configured substantially similar tomemory604 discussed with respect toFIG. 6. It is understood that one or more instances of thevehicle memory204 can be included in one or more of the components of the vehicle201 (and/or thevehicle120 fromFIG. 1), such as the vehicle head unit211 (and/or the head unit122) and/or the telematics control unit209 (and/or the telematics control unit128). As such, in the claims, the use of the phrase “vehicle memory” (or variations thereof) does not include waves or signals per se and/or communication media.
• Thevehicle firmware206, which in some embodiments may also be known as microcode, can be written onto a ROM of thevehicle memory204. Thevehicle firmware206 can be written on the ROM at the time of manufacturing and is used to execute programs on thevehicle processor203. In some embodiments, thevehicle firmware206 includes thevehicle operating system208. In some embodiments, thevehicle firmware206 is thevehicle operating system208. In some embodiments, thevehicle firmware206 and thevehicle operating system208 are closely integrated for performance of operations of thevehicle201.
• Thevehicle operating system208 can control the operation of at least a portion of thevehicle201. In some embodiments, thevehicle operating system208 includes the functionality of thevehicle firmware206 and/or the vehicle software application(s)210. Thevehicle operating system208 can be executed by thevehicle processor203 to cause thevehicle201 to perform various operations. Thevehicle operating system208 can include, by way of example without limitation, a member of the SYMBIAN OS family of operating systems from SYMBIAN LIMITED; a member of the WINDOWS OS, WINDOWS MOBILE OS, and/or WINDOWS PHONE OS families of operating systems from MICROSOFT CORPORATION; a member of the PALM WEBOS family of operating systems from HEWLETT PACKARD CORPORATION; a member of the BLACKBERRY OS family of operating systems from RESEARCH IN MOTION LIMITED; a member of the IOS family of operating systems, a memory of the CARPLAY family of operating systems, and/or a member of the OS X family of operating systems from APPLE INC.; a member of the ANDROID OS family and/or the ANDROID AUTO family of operating systems from GOOGLE INC.; an open-source software operating system build around the LINUX kernel; a member of a real-time operating system; a member of a portable operating system interface automotive open system architecture and/or other operating systems. These operating systems are merely illustrative of some contemplated operating systems that may be used in accordance with various embodiments of the concepts and technologies described herein and therefore should not be construed as being limiting in any way. The vehicle software application(s)210 can execute on top of thevehicle operating system208. The vehicle software application(s)210 can be executed by thevehicle processor203 to cause the vehicle201 (and/or components thereof, such as thevehicle head unit211 and/or the telematics control unit209) to perform various operations described herein. For example, the vehicle software application(s)210 can be part of a vehicle entertainment system, a vehicle navigation system, a vehicle “ECU”, and/or another computing system of the user vehicle. In some embodiments, the vehicle software application(s)210 can include one or more instances of thevehicle OTT application124 ofFIG. 1.
• Thetelematics control unit209 may be configured substantially similar to theTCU128 discussed with respect toFIG. 1. In some embodiments, thetelematics control unit209 may include and/or control the vehiclewireless communications components212 discussed below. Thetelematics control unit209 can include one or more instances of thevehicle processor203, thevehicle memory204, thevehicle operating system208, and/or thevehicle firmware206. Thetelematics control unit209 may be configured to control the inflow and/or outflow of communications to and/or from thevehicle201 via one or more of the vehiclewireless communications components212. In various embodiments, thetelematics control unit209 can control, provide, and/or facilitate wireless tracking, wireless diagnostics, device pairing, crash notification, and other communication to/from thevehicle201. In various embodiments, thetelematics control unit209 can include circuitry that operates as a network interface controller and can provide communication to thevehicle head unit211 and/or one or morevehicle software applications210. In various embodiments, thetelematics control unit209 can perform one or more functions and/or operations discussed herein, such as but not limited to operations discussed with respect toFIG. 1,FIG. 3, and/orFIG. 4.
• Thevehicle head unit211 may be configured substantially similar to thehead unit122 discussed above with respect toFIG. 1. In some embodiments, thevehicle head unit211 can include thedisplay211A that can be configured to present and/or provide audio output and/or video output via one or more user interface. Thedisplay211A of thevehicle head unit211 can have a display device that presents various user interfaces, requests, messages, and/or any other information (e.g., any of the messages, commands, requests, responses, and/or identifiers fromFIG. 1) to a user or other occupant associated with thevehicle120 and/or thevehicle201. In some embodiments, the input/output component211B can provide a user touch-screen, audio speakers, microphones, haptic feedback system, or other input and/or output device or component that can alert a user to various communications. As such, an instance of the input/output component211B and/or thedisplay211A can be implemented to enable theinput127 to be provided to thehead unit122 of thevehicle120.
• The vehiclewireless communications component212 can include one or more wireless wide area network (“WWAN”) components (e.g., radio transceivers, antenna, etc.) capable of facilitating communication with one or more WWANs, such as the servingnetwork102 and/or thenetwork130. In some embodiments, one or more instances of the vehiclewireless communications component212 can be configured to provide multi-mode wireless connectivity. For example, the vehiclewireless communications component212 may be configured to provide connectivity to theserving network102 and/or thenetwork130 and may provide functions in accordance with UMTS, LTE, 5G and New Radio standards, or via some other combination of technologies, and more particularly, one or more technologies that support cell broadcast functionality. In various embodiments, the vehiclewireless communications component212 can include one or more instances of a transceiver, sensors, cameras, circuitry, antennas, and any other components that can support and facilitate sending and/or receiving communications over thevehicle communication interface218 using thedirect transmission mode219 and/or the network communication interface220 using thenetwork transmission mode221. In some embodiments, thevehicle communication interface218 can be provided and/or hosted by theDSRC component214 and/or the C-V2X component216.
• Thedirect transmission mode219 refers to a communication routine (which may be executed by the telematics control unit209) by which a vehicle can communicate messages to/from another device (while within each other's communication range) without the messages being passed through an intermediary device of the network (e.g., without being handled by any of thenetwork access points104,132, thecore server134, theM2M platform108, etc.). In some embodiments, thedirect transmission mode219 can be provided over an 802.11x protocol (e.g., 802.11p or protocol within the 802.11 family of wireless local area network standards), which in some embodiments may be referred to as protocols and/or standards for dedicated short-range communications (“DSRC”). In some embodiments, thedirect transmission mode219 can be provided using specifications pertaining to cellular V2X (“C-V2X”), which is initially defined by the Third Generation Partnership Project (“3GPP”) Release 14, discussed in Release 15 and later. In various embodiments, standards and protocols of C-V2X may allow communication components to be configured to support the direct transmission mode219 (e.g., via a PC5 interface) and the network transmission mode221 (e.g., via a Uu interface). Thevehicle communication interface218 can be configured to use, support, and provide thedirect transmission mode219, and the network communication interface220 can be configured to use, support, and provide thenetwork transmission mode221. In various embodiments, thenetwork transmission mode221 refers to a vehicle communication routine (which may be executed by the telematics control unit209) by which the vehiclewireless communications component212 uses and communicates with network infrastructure (e.g., network devices of the servingnetwork102 and/or the network130) to transmit various communications that are directed to one or more device through a device of the network (i.e., network infrastructure), such as any of thenetwork access points104,132, theM2M platform108, and/or thecore server134. In some embodiments, one or more instances of a communication (e.g., any of theaccess probe message150, theaccess probe message150′, the access deniedresponse153, theaccess redirect command154, theaccess redirect request160, the network serviceportal response162, and/or the access probe response164) may be generated and/or received with a configuration that facilitates and supports the use of thenetwork transmission mode221.
• TheDSRC component214 can be a radio communications device and/or circuitry that can send and receive various communications (not shown) using thedirect transmission mode219. In some embodiments, theDSRC component214 is configured to operate within a 5.9 GHz radio frequency band as defined by the United States Department of Transportation. In some embodiments, theDSRC component214 is configured to operate within other radio frequency bands. In some embodiments, theDSRC component214 can operate using 802.11p or other technology.
• The C-V2X component216 can be a radio communications device and/or circuitry that can send and receive V2X communications using thedirect transmission mode219 and/or thenetwork transmission mode221. In some embodiments, the C-V2X component216 can operate in accordance with 3GPP Release 14 or later. The C-V2X component216 can support and provide thevehicle communication interface218 and/or the network communication interface220. In various embodiments, the C-V2X component216 can be configured to support 5G New Radio transmissions and direct communication transmissions so that communications may occur within and/or outside of a direct communication range. In some embodiments, the C-V2X component216 can transmit and receive communications over the direct transmission mode106 within an ITS spectrum, such as a 5.9 GHz ITS band. In some embodiments, the C-V2X component216 can provide transmission latency that is no more than a defined amount of milliseconds (e.g., less than 10 milliseconds). In some embodiments, theTCU128 can include, and/or be configured to invoke, the C-V2X component216 and/or thevehicle DSRC component214. It should be understood that the embodiment of thevehicle201 illustrated inFIG. 2 is provided as an example of a possible implementation of thevehicle120 discussed with respect toFIG. 1. The examples provided are for illustration purposes only, and therefore should not be construed as limiting in any way.
• Turning now toFIGS. 3 and 4 with continued references toFIGS. 1 and 2, aspects of amethod300 and amethod400 for embodiments pertaining to aspects of connected vehicle network access optimization will be described in detail, according to various illustrative embodiments. It should be understood that each of the operations of the one or more methods disclosed herein (e.g., themethod300 and/or themethod400 discussed below) are not necessarily presented in any particular order and that performance of some or all of the operations in an alternate order(s) is possible and is contemplated. It is also understood that any of the operations from the methods disclosed herein may be combined or otherwise arranged to yield another embodiment of a method that is within the scope of the concepts and technologies discussed herein. The operations have been presented in the demonstrated order for ease of description and illustration, and therefore should not be construed as limiting the various embodiments disclosed herein. Operations may be added, omitted, and/or performed simultaneously and/or sequentially, without departing from the scope of the concepts and technologies disclosed herein.
• It also should be understood that the methods disclosed herein can be ended at any time and need not be performed in its entirety. Some or all operations of the methods, and/or substantially equivalent operations, can be performed by execution of computer-readable instructions stored and included on a computer storage medium, as defined herein. The phrases “computer executable instructions,” and variants thereof (e.g., “computer-readable instructions”), as used herein, is used expansively to include routines, applications, modules, scripts, programs, plug-ins, data structures, algorithms, and the like. It is understood that any use of the term “module” (in the specification and claims) refers to a defined, callable set of computer-readable and executable instructions that, upon execution by a processor, configure at least a processor to perform at least a portion of one or more operations and functions discussed herein so as to transform, upon execution, processing resources and/or memory resources into a particular, non-generic, machine. Computer-readable instructions can be implemented on various system configurations including but not limited to one or more of single-processor or multiprocessor systems, minicomputers, user equipment, mainframe computers, personal computers, network servers, hand-held computing devices, microprocessor-based, programmable consumer electronics, a network platform, edge devices, vehicles, combinations thereof, and the like.
• Thus, it should be appreciated that the logical operations described herein are implemented (1) as a sequence of computer implemented acts or program modules running on a computing system and/or (2) as interconnected machine logic circuits or circuit modules within the computing system so as to provide a particular, non-generic machine device. The implementation is a matter of choice dependent on the performance and other requirements of the computing system. Accordingly, the logical operations described herein are referred to variously as states, operations, structural devices, acts, functions, instructions, and/or modules. These states, operations, structural devices, acts, functions, instructions, and/or modules may be implemented in software, in firmware, in special purpose digital logic, and any combination thereof. As used herein, the phrase “cause a processor to perform operations” and variants thereof is used to refer to causing and transforming a processor of a computing system or device, such as any component within one or more of thevehicle120, servingnetwork102, theM2M platform108, theM2M server110, thenetwork130, theOTT server131, and/or thecore server134, to perform one or more operations and/or causing one or more instances of a processor to direct other components of a computing system or device, to perform one or more of the operations.
• For purposes of illustrating and describing the concepts of the present disclosure, one or more of the operations of methods disclosed herein are described as being performed by one or more instance of theTCU128 and/or thehead unit122 of thevehicle120, theM2M server110 of theM2M platform108, thecore server134 associated with thenetwork communication service138, or a combination thereof, via execution of one or more computer-readable instructions configured so as to instruct and transform a processor. It should be understood that additional and/or alternative devices and/or network infrastructure devices can, in some embodiments, provide the functionality described herein via execution of one or more routines, applications, and/or other software including, but not limited to, thevehicle OTT application124, theNEMA118, thecontrol application140, thevehicle software application210, thevehicle firmware206, thevehicle operating system208, and/or any other computer executable instructions that can configure a device discussed herein, such as but not limited to one or more of theM2M platform108, theM2M server110, thevehicle120, theOTT server131, and/or thecore server134. Thus, the illustrated embodiments are illustrative, and should not be viewed as being limiting in any way.
• In various embodiments, any computer system of the M2M platform108 (e.g., the M2M server110) can execute an instance of theNEMA118 so as to cause one or more processor (e.g., an instance of the processor111) to perform at least a portion of one or more operations discussed herein. In various embodiments, execution of thecontrol application140 can cause one or more instances of acore server134 and/or theM2M server110 to perform one or more operations discussed herein. It should be understood that the examples provided are for illustration purposes only, and therefore should not be construed as limiting in any way. Themethod300 and themethod400 will be described with reference to one or more of theFIGS. 1 and 2.
• Turning now toFIG. 3, themethod300 for connected vehicle network access optimization is disclosed, according to an illustrative embodiment. In an embodiment, themethod300 can be performed by a computer system of the M2M platform108 (e.g., theM2M server110 that executes the processor111) that is configured by theNEMA118 to perform one or more operation discussed herein. TheM2M server110 can communicatively couple to thenetwork130 and thevehicle120. It is understood that one or more operations of themethod300 may be performed by, and/or in response to, any operation from another device and/or application, such as thecontrol application140 of thecore server134 and/or theTCU128 of thevehicle120. In various embodiments, themethod300 can begin atoperation302, where theNEMA118 can identify theaccess policy144 associated with thenetwork communications service138. TheNEMA118 can enforce theaccess policy144 by instructing one or more network infrastructure devices of the serving network102 (e.g., the network access point104) to route instances of messages or communications from the vehicle120 (e.g., the access probe message150) to theM2M server110 so that theM2M platform108 serves as an intermediary device for access policy enforcement.
• Fromoperation302, themethod300 can proceed tooperation304, where theNEMA118 may enforce theaccess policy144 by generating an instance of theAAPM114 for use by theM2M platform108. TheAAPM114 can be associated with thenetwork communication service138. TheAAPM114 can be based on theaccess policy144 from thecore server134 that supports thenetwork communication service138. Theaccess policy144 can indicate or otherwise require that thevehicle120 be authorized to use thenetwork communication service138 before one or more applications on the vehicle120 (e.g., the vehicle OTT application124) are permitted to use or otherwise maintain ongoing communicative coupling with the servingnetwork102 and/or thenetwork130 to access devices on and/or in communication with the network130 (e.g., the OTT server131).
• Fromoperation304, themethod300 can proceed tooperation306, where theNEMA118 can populate theAAPM114 with one or more authorized identifiers (e.g., the authorizedidentifiers116A-N) based on which identifiers (e.g., instances of the known TCU identifier149) are currently present within one or more equipment profiles (e.g., the equipment profile148) associated with thenetwork communication service138. For example, any device that is authorized to access and use thenetwork communication service138 will have a corresponding identifier (e.g., the known TCU identifier149) stored in an instance of an equipment profile associated with the device (e.g., instances of the equipment profile148). In turn, thecontrol application140 can provide, to theNEMA118, the identifiers associated with devices (e.g., the known TCU identifier149) that are authorized and permitted to use thenetwork communication service138. Therefore, if thevehicle120 sends, to theM2M server110, a message having an identifier included therein (e.g., theaccess probe message150 having theTCU identifier128A), but theAAPM114 does not have an authorized identifier (e.g., any of the authorizedidentifiers116A-N) matching or otherwise corresponding with the identifier from thevehicle120, then messages from thevehicle120 will not be permitted to pass through, or otherwise be routed via, theM2M platform108 to a target destination, such as theOTT server131, thecore server134, and/or any other device ofnetwork130 and/or the servingnetwork102.
• Fromoperation306, themethod300 can proceed tooperation308, where theNEMA118 can receive an instance of theaccess probe message150 from theTCU128 of thevehicle120. Theaccess probe message150 can include theprobe URL152. In some embodiments, theprobe URL152 can be associated with, or otherwise be directed to, thecore server134 and/or thenetwork communication service138. In some embodiments, theaccess probe message150 can request forwarding to thecore server134 associated with thenetwork communication service138. In some embodiments, theaccess probe message150 can include theTCU identifier128A associated with theTCU128 that sent theaccess probe message150. In some embodiments, theprobe URL152 may be associated with theOTT server131 and request access to theOTT server131, where theOTT server131 is associated with thevehicle OTT application124 of thevehicle120. In some embodiments, theaccess probe message150 may be routed to theM2M platform108 so that theM2M platform108 intercepts theaccess probe message150 before it can reach a target destination, such as thecore server134 and/or theOTT server131.
• Fromoperation308, themethod300 can proceed tooperation310, where theNEMA118 can prevent theaccess probe message150 from being forwarded on to a target destination, such as thecore server134 and/or theOTT server131. TheNEMA118 can suspend execution of the request to forward theaccess probe message150 on to a subsequent device so as to enable confirmation that thevehicle120 which sent the access probe message150 (specifically the TCU128) is authorized and permitted to use thenetwork communication service138. By preventing theaccess probe message150 from being forwarded, theNEMA118 can improve the performance of network devices by reducing the amount of traffic that is routed to thecore server134 from theM2M platform108. By this, theNEMA118 and theM2M platform108 can provide optimization of limited processing resources and memory resources (e.g., available via one or more instance of the M2M server110), while also improving the speed with which thevehicle120 can obtain network access and authorized to use thenetwork communication service138.
• Fromoperation310, themethod300 can proceed tooperation312, where theNEMA118 can determine whether the device which sent the message (e.g., theTCU128 of thevehicle120 that sent the access probe message150) is authorized to access and use (i.e., engage in ongoing communicative coupling) thenetwork communication service138. In some embodiments, to determine whether theTCU128 is authorized to access and use thenetwork communication service138, theNEMA118 may determine whether an identifier is provided in the received message (e.g., theTCU identifier128A provided in the access probe message150) that matches, identifies, or otherwise corresponds with at least one authorized identifier of an authorized access policy map (e.g., at least one of the authorizedidentifiers116A-N of the AAPM114). If theTCU identifier128A does not match one of the authorizedidentifiers116A-N of theAAPM114, then theTCU128 is not authorized to access and use thenetwork communication service138. If, however, theTCU identifier128A is found or otherwise reflected by at least one of the authorizedidentifiers116A-N of theAAPM114, then theTCU128 of thevehicle120 is authorized to access thenetwork communication service138, and thus permitted to contact a target destination via the M2M platform108 (e.g., engaging in communication with theOTT server131 using the network communication service138).
• In some embodiments, theNEMA118 can determine that theTCU128 is not authorized to access thenetwork communication service138, such as based on theTCU128 having aTCU identifier128A (which was included in the access probe message150) that does not correspond with any of the authorizedidentifiers116A-N of theAAPM114. In response to determining that theTCU128 is not authorized to access thenetwork communication service138, themethod300 can proceed along the NO path tooperation314. In response to determining that theTCU128 is authorized to access thenetwork communication service138, themethod300 can proceed along the YES path tooperation324. For clarity, a discussion of themethod300 proceeding along the NO path tooperation314 will be provided first, followed by a discussion proceeding along the YES path tooperation324.
• Atoperation314, theNEMA118 can generate theaccess redirect command154 that can include theredirect instruction156. Theredirect instruction156 can instruct thehead unit122 and/or theTCU128 to bypass theM2M platform108 so as to enable access to thenetwork communication service138 by contacting thenetwork service portal142 directly, that is without attempting to seek authorization for use of thenetwork communication service138 via theM2M platform108. Theredirect instruction156 can include theredirect URL158 that points to thecore server134 and/or thenetwork service portal142 associated with thenetwork communication service138. In some embodiments, theredirect instruction156 can instruct a network access point (e.g., any of thenetwork access points104,132) to permit a one-time bypass of theM2M platform108 so that thevehicle120 can contact thecore server134 and thenetwork service portal142 despite not yet being authorized to use thenetwork communication service138.
• Fromoperation314, themethod300 can proceed tooperation316, where theNEMA118 can provide theaccess redirect command154 to theTCU128 of thevehicle120. In some embodiments, themethod300 can proceed fromoperation316 to one or more operations discussed with respect toFIG. 4, such asoperation408 which are discussed below in further detail. In some embodiments, themethod300 can proceed fromoperation316 tooperation328, where themethod300 can end.
• In some other embodiments, fromoperation316, themethod300 can proceed tooperation318, where theNEMA118 can receive theaccess update message170 from thecore server134 that supports thenetwork communication service138. Theaccess update message170 may be provided by thecore server134 to theM2M platform108 in response to one of the equipment profiles being updated with an identifier to indicate a corresponding device is authorized and permitted to use thenetwork communication service138. For example, theTCU128 may generate theaccess redirect request160 based on theredirect instruction156, where theaccess redirect request160 can include theTCU identifier128A of theTCU128 and theredirect URL158 that points to thenetwork service portal142. TheTCU128 can send theaccess redirect request160 to thecore server134 so as to enable thevehicle120 to gain permission to use thenetwork communication service138 via thenetwork service portal142. The user may provide an instance of theinput127 to thenetwork service portal142 to instruct thecontrol application140 of thecore server134 to allow theTCU128 to access thenetwork communication service138. Thecore server134 can grant theTCU128 access to thenetwork communication service138 by referencing theTCU identifier128A within theequipment profile148 associated with thevehicle120, specifically by instantiating and recording an instance of the known TCU identifier149 (which corresponds with and reflects theTCU identifier128A) within theequipment profile148 associated with thevehicle120. In turn, thecontrol application140 of thecore server134 can inform theM2M platform108 of the TCU's128 ability to use thenetwork communication service138 by providing theaccess update message170 to theNEMA118, where theaccess update message170 can include the knownTCU identifier149. In some embodiments, theaccess update message170 can indicate that the knownTCU identifier149 pertains to theAAPM114 associated with thenetwork communication service138.
• Fromoperation318, themethod300 can proceed tooperation320, where theNEMA118 can obtain or otherwise access theAAPM114 that is associated with thenetwork communication service138.
• Fromoperation320, themethod300 can proceed tooperation322, where theNEMA118 can instantiate an instance of an authorized identifier within theAAPM114 so as to reflect theTCU128 of thevehicle120. For example, prior to receiving theaccess update message170, the authorizedidentifier116B may not yet exist within theAAPM114. TheNEMA118 can create and configure the authorizedidentifier116B to reflect (and thus correspond with) the knownTCU identifier149 from theaccess update message170. As such, the authorizedidentifier116B will now also correspond with theTCU identifier128A that identifies theTCU128. TheNEMA118 can update theAAPM114 by instantiating the authorizedidentifier116B for theTCU128 in theAAPM114. In some embodiments, fromoperation322, themethod300 can proceed tooperation328, where themethod300 can end.
• In some other embodiments, themethod300 can proceed fromoperation322 tooperation323, where theNEMA118 can receive a subsequentaccess probe message150′. In some embodiments, the subsequentaccess probe message150′ may be configured substantially similar to theaccess probe message150, and thus include an instance of theprobe URL152′ and theTCU identifier128A. The subsequentaccess probe message150′ may be received by theNEMA118 of theM2M platform108 subsequent to theAAPM114 being updated by thecore server134 based on theTCU128 being granted authorization by thecore server134 to use thenetwork communication service138. Fromoperation323, themethod300 can proceed to another iteration of theoperation312, where, in an embodiment, theNEMA118 can analyze the subsequentaccess probe message150′ and theAAPM114 to determine whether theTCU128 is authorized to access and use thenetwork communication service138. This time, when theNEMA118 analyzes theAAPM114, theNEMA118 can determine that one of the authorized identifiers (e.g., the authorizedidentifier116B) corresponds with theTCU identifier128A of theTCU128, where theTCU identifier128A was included in the subsequentaccess probe message150′. As such, theNEMA118 can determine that the TCU128 (and thus also the vehicle120) is now authorized to access and use thenetwork communication service138, which allows themethod300 to proceed along the YES path fromoperation312 tooperation324. In some embodiments, themethod300 may proceed fromoperation323 back tooperation312 and then along the YES fromoperation312 tooperation326. For clarity, a discussion ofoperation324 will be provided first, followed by a discussion ofoperation326.
• Atoperation324, theNEMA118 may seek to obtain anaccess probe response164 from a target destination with which thevehicle120 is attempting to communicate. For example, in an embodiment, the subsequentaccess probe message150′ may include theprobe URL152′ that is directed towards thecore server134 so as to confirm that thevehicle OTT application124 can begin communicating with theOTT server131 via theM2M platform108 while using thenetwork communication service138. Thecontrol application140 of thecore server134 may send theaccess probe response164 to theNEMA118 to confirm that thevehicle120 andTCU128 are permitted to use thenetwork communication service138 and route messages to theOTT server131 via theM2M platform108. In some embodiments, the subsequentaccess probe message150′ may also, and/or additionally, seek confirmation from theOTT server131 that thevehicle OTT application124 is authorized to engage in a content stream (or other communication data stream) with theTCU128 of thevehicle120. TheOTT server131 can indicate approval and authorization via the same, or another, instance of theaccess probe response164. Fromoperation324, themethod300 can proceed tooperation326.
• Whether themethod300 proceeds tooperation326 fromoperation312 or324, atoperation326, theM2M platform108 can enable and permit theTCU128 to access thenetwork communication service138 for engaging in ongoing and/or sustained communications to and/or from thevehicle OTT application124 via theM2M platform108. TheNEMA118 may instruct theTCU128 that theaccess policy144 associated with thenetwork communication service138 requires or otherwise mandates that communications to and/or from thevehicle120 pertaining to thevehicle OTT application124 must be routed or otherwise directed through theM2M platform108 in order to maintain authorization and permission to use thenetwork communication service138. As such, thevehicle OTT application124 may now be authorized to communicate with theOTT server131 based on theTCU128 directing or otherwise routing communications to via theM2M platform108 so as to maintain use of thenetwork communications service138.
• In some embodiments, if theTCU128 has already been granted authorization to use thenetwork communication service138, and subsequently attempts to bypass theM2M platform108 in routing communications to theOTT server131, thecontrol application140 and/or theNEMA118 may revoke the permission of theTCU128 to use thenetwork communication service138 by removing the authorized identifier associated with the TCU128 (e.g., the authorizedidentifier116B) from theAAPM114. TheNEMA118 may send thevehicle120 an instance of the access deniedresponse153 based on violation of theaccess policy144 due to an attempt to bypass theM2M platform108 after access to thenetwork communication service138 has already (or initially) been granted.
• Fromoperation326, themethod300 can proceed tooperation328, where themethod300 can end. It should be understood that the examples provided are for illustration purposes only, and therefore should not be construed as limiting in any way.
• Turning now toFIG. 4, themethod400 for connected vehicle network access optimization is disclosed, according to an illustrative embodiment. In an embodiment, themethod400 can be performed by theTCU128 and/or thehead unit122 executing an instance of a processor. It is understood that, in various embodiments, one or more of the operations may be performed by thehead unit122, theTCU128, and/or another computer system or user equipment of thevehicle120. It should be understood that the examples provided are for illustration purposes only, and therefore should not be construed as limiting in any way.
• In some embodiments, themethod400 can begin atoperation402, where theTCU128 can receive an instance of theinput127 from thehead unit122 of thevehicle120. In some embodiment, the instance of theinput127 can be associated with thevehicle OTT application124, and thus trigger thehead unit122 to launch thevehicle OTT application124. Thevehicle OTT application124 can request theTCU128 to establish a network connection so that thevehicle OTT application124 can communicate with theOTT server131.
• Fromoperation402, themethod400 can proceed tooperation404, where theTCU128 can identify thevehicle OTT application124 based on theapplication identifier126. TheTCU128 can confirm that thevehicle OTT application124 is requesting access to theOTT server131 by engaging in wireless communicative coupling.
• Fromoperation404, themethod400 can proceed tooperation406, where theTCU128 can generate theaccess probe message150 that is directed to thecore server134 to probe for access and authorization to thenetwork communication service138 so that thevehicle OTT application124 can communicate with theOTT server131. In various embodiments, theaccess probe message150 can be sent to theM2M platform108, which may perform one or more operations discussed with respect toFIG. 3.
• Fromoperation406, themethod400 can proceed tooperation408, where theTCU128 can receive a message from theM2M platform108, such as theaccess redirect command154 that includes theredirect instruction156.
• Fromoperation408, themethod400 can proceed tooperation410, where theTCU128 can determine whether the message that is received (e.g., the access redirect command154) authorizes theTCU128 to access thenetwork communication service138. In some embodiments, theTCU128 can determine that the message (e.g., the access redirect command154) includes theredirect instruction156 but does not yet indicate that access to thenetwork communication service138 has been authorized. If access to thenetwork communication service138 has not been authorized, themethod400 can proceed along the NO path tooperation412. If access to thenetwork communication service138 is indicated as being authorized, then themethod400 can proceed along the YES path tooperation422. For clarity, as discussion of the operations proceeding from the NO path tooperation412 will be discussed first, followed by a discussion of theoperation422 that proceeds from the YES path.
• Fromoperation410, themethod400 can proceed along the NO path tooperation412, where theTCU128 can invoke theredirect instruction156 from theaccess redirect command154 so as to bypass theM2M platform108.
• Fromoperation412, themethod400 can proceed tooperation414, where theTCU128 can generate theaccess redirect request160 based on theredirect instruction156. Theaccess redirect request160 can include theredirect URL158 and theTCU identifier128A associated with theTCU128. Theaccess redirect request160 can be directed to thecore server134 associated with thenetwork communication service138. Theredirect URL158 can point or otherwise direct theaccess redirect request160 to thenetwork service portal142 so as to request access and authorization to use thenetwork communication service138.
• Fromoperation414, themethod400 can proceed tooperation416, where theTCU128 can provide theaccess redirect request160 to thecore server134 associated with thenetwork communication service138. Theaccess redirect request160 can request access and authorization of thenetwork communication service138 via thenetwork service portal142.
• Fromoperation416, themethod400 can proceed tooperation418, where theTCU128 can obtain access to thenetwork communication service138 via thenetwork service portal142. Thecontrol application140 can update theequipment profile148 by using theTCU identifier128A to record, in theequipment profile148, the knownTCU identifier149 associated with theTCU128. TheTCU128 can receive the network serviceportal response162 indicating that access to thenetwork communication service138 has been granted and that communicative coupling can proceed via theM2M platform108.
• Fromoperation418, themethod400 can proceed tooperation420, where theTCU128 can generate the subsequentaccess probe message150′. In some embodiments, theaccess probe message150 may be referred to as a “first” access probe message and the subsequentaccess probe message150′ may be referred to as a “second” access probe message. Use of the terms “first” and “second” are provided for clarification purposes only, and therefore should not be construed as requiring a preference, importance, hierarchy, sequence, or the like. In some embodiments, themethod400 can proceed fromoperation420 tooperation424, where themethod400 can end.
• In some other embodiments, fromoperation420, themethod400 can proceed to another iteration of theoperation410. For example, in an embodiment, when theoperation410 is preceded byoperation420, theTCU128 can determine whether access to thenetwork communication service138 has been authorized by analyzing the network serviceportal response162. If the access to thenetwork communication service138 is granted, theTCU128 may proceed along the YES path tooperation422. Atoperation422, theTCU128 can initiate contact with theOTT server131 via theM2M platform108 by sending the subsequentaccess probe message150′ to theM2M platform108. TheTCU128 can receive theaccess probe response164 that confirms thatM2M platform108 authorizes theTCU128 to use the network communication service139 and contact theOTT server131 via theM2M platform108. TheTCU128 can then permit thevehicle OTT application124 to send a request (not shown) to theOTT server131 by way of theM2M platform108 so as to maintain execution of thevehicle OTT application124 on thehead unit122. Fromoperation422, themethod400 can proceed tooperation424, where themethod400 can end.
• Turning now toFIG. 5, a discussion of anetwork500 is illustrated, according to an illustrative embodiment. The servingnetwork102 and/or thenetwork130 shown inFIG. 1 can be configured substantially similar to include at least some of the elements of thenetwork500. Thenetwork500 can include acellular network502, apacket data network504, for example, the Internet, and a circuit switchednetwork506, for example, a publicly switched telephone network (“PSTN”). Thecellular network502 includes various components such as, but not limited to, base transceiver stations (“BTSs”), node-B's (“NBs”), e-Node-B's (“eNBs”), g-Node-B's (“gNBs”), base station controllers (“BSCs”), radio network controllers (“RNCs”), mobile switching centers (“MSCs”), mobile management entities (“MMEs”), short message service centers (“SMSCs”), multimedia messaging service centers (“MMSCs”), home location registers (“HLRs”), home subscriber servers (“HSSs”), visitor location registers (“VLRs”), charging platforms, billing platforms, voicemail platforms, GPRS core network components, location service nodes, an IP Multimedia Subsystem (“IMS”), 5G core components, 5G NR components, functions, applications, and the like. Thecellular network502 also includes radios and nodes for receiving and transmitting voice, data, and combinations thereof to and from radio transceivers, networks, thepacket data network504, and the circuit switchednetwork506.
• Amobile communications device508, such as, for example, a cellular telephone, a user equipment, a mobile terminal, a PDA, a laptop computer, a handheld computer, and combinations thereof, can be operatively connected to thecellular network502. Thecellular network502 can be configured as a 2G GSM network and can provide data communications via GPRS and/or EDGE. Additionally, or alternatively, thecellular network502 can be configured as a 3G UMTS network and can provide data communications via the HSPA protocol family, for example, HSDPA, EUL (also referred to as HSDPA), and HSPA+. Thecellular network502 also can be compatible with mobile communications standards such as but not limited to 4G, LTE, LTE Advanced, and/or 5G NR, as well as evolved and future mobile standards.
• Thepacket data network504 includes various devices, for example, servers, computers, databases, and other devices in communication with one another, as is generally understood. Thenetwork130 may be configured as an instance of thepacket data network504 so as to support thenetwork communication service138. Thepacket data network504 devices are accessible via one or more network links. The servers often store various files that are provided to a requesting device such as, for example, a computer, a terminal, a smartphone, or the like. Typically, the requesting device includes software (a “browser”) for executing a web page in a format readable by the browser or other software. Other files and/or data may be accessible via “links” and/or “pointers” in the retrieved files, as is generally understood. In some embodiments, thepacket data network504 includes or is in communication with the Internet. The circuit switchednetwork506 includes various hardware and software for providing circuit switched communications. The circuit switchednetwork506 may include, or may be, what is often referred to as a plain old telephone system (POTS). The functionality of a circuit switchednetwork506 or other circuit-switched network are generally known and will not be described herein in detail.
• The illustratedcellular network502 is shown in communication with thepacket data network504 and a circuit switchednetwork506, though it should be appreciated that this is not necessarily the case. One or more Internet-capable devices510, for example, a PC, a laptop, a portable device, theTCU128 of thevehicle120, or another suitable device, can communicate with one or morecellular networks502, and devices connected thereto, through thepacket data network504. It also should be appreciated that the Internet-capable device510 can communicate with thepacket data network504 through the circuit switchednetwork506, thecellular network502, and/or via other networks (not illustrated).
• As illustrated, acommunications device512, for example, a telephone, facsimile machine, modem, computer, or the like, can be in communication with the circuit switchednetwork506, and therethrough to thepacket data network504 and/or thecellular network502. It should be appreciated that thecommunications device512 can be an Internet-capable device, and can be substantially similar to the Internet-capable device510. In some embodiments, themobile communications device508, the Internet-capable device510, and/or thecommunication device512 can correspond with one or more computer systems discussed with respect toFIG. 1, such as but not limited to theTCU128 of thevehicle120, theM2M server110 of theM2M platform108, theOTT server131, and/or thecore server134. In the specification, the servingnetwork102, thenetwork130, /or thenetwork500 can refer broadly to, in some embodiments, any combination of thenetworks502,504,506. It should be appreciated that substantially all of the functionality described with reference to devices of the servingnetwork102, thenetwork130, and/or thenetwork500 can, in some embodiments, be performed by thecellular network502, thepacket data network504, and/or the circuit switchednetwork506, alone or in combination with other networks, network elements, and the like.
• FIG. 6 is a block diagram illustrating acomputer system600 can be configured to provide the functionality described herein related to connected vehicle network access optimization, in accordance with various embodiments of the concepts and technologies disclosed herein. In some embodiments, at least a portion of one or more of theM2M server110, thenetwork access point104, thenetwork access point132, theOTT server131, and/or thecore server134 illustrated and described herein can be configured as and/or can have an architecture similar or identical to thecomputer system600. In some embodiments, thehead unit122 and/or theTCU128 of thevehicle120, and/or at least a portion of thevehicle201 can be configured as and/or have an architecture that is similar or identical to thecomputer system600. Thecomputer system600 includes aprocessing unit602, amemory604, one or more user interface devices606, one or more input/output (“I/O”)devices608, and one ormore network devices610, each of which is operatively connected to a system bus612. The system bus612 enables bi-directional communication between theprocessing unit602, thememory604, the user interface devices606, the I/O devices608, and thenetwork devices610. In some embodiments, the processor111 and/or theprocessor135 can be configured substantially similar to theprocessing unit602. In various embodiments, one or more instances of theprocessing unit602 can be implemented within one or more devices and/or components of the operatingenvironment100, such as but not limited to one or more of thehead unit122, theTCU128, thenetwork access point104, the servingnetwork102, theM2M platform108, theM2M server110, thenetwork130, theOTT server131, thenetwork access point132, and/or thecore server134. In some embodiments, thevehicle processor203 can be configured substantially similar to an instance of theprocessing unit602. In some embodiments, thememory112, thememory136, and/or thevehicle memory204 can be configured substantially similar to thememory604. As such, one or more instances of thememory604 can be implemented within one or more devices and/or components of the operatingenvironment100, such as but not limited to one or more of thehead unit122, theTCU128, thenetwork access point104, the servingnetwork102, theM2M platform108, theM2M server110, thenetwork130, theOTT server131, thenetwork access point132, and/or thecore server134.
• Theprocessing unit602 may be a standard central processor that performs arithmetic and logical operations, a more specific purpose programmable logic controller (“PLC”), a programmable gate array, or other type of processor known to those skilled in the art and suitable for controlling the operation of the server computer. As used herein, the word “processor” and/or the phrase “processing unit” when used with regard to any architecture or system can include multiple processors or processing units distributed across and/or operating in parallel in a single machine or in multiple machines. Furthermore, processors and/or processing units can be used to support virtual processing environments. Processors and processing units also can include state machines, application-specific integrated circuits (“ASICs”), combinations thereof, or the like. Because processors and/or processing units are generally known to one of ordinary skill, the processors and processing units disclosed and discussed herein will not be described in further detail herein.
• Thememory604 communicates with theprocessing unit602 via the system bus612. In some embodiments, thememory604 is operatively connected to a memory controller (not shown) that enables communication with theprocessing unit602 via the system bus612. Thememory604 includes anoperating system614 and one ormore program modules616. Theoperating system614 can include, but is not limited to, members of the WINDOWS, WINDOWS CE, and/or WINDOWS MOBILE families of operating systems from MICROSOFT CORPORATION, the LINUX family of operating systems, the SYMBIAN family of operating systems from SYMBIAN LIMITED, the BREW family of operating systems from QUALCOMM CORPORATION, the MAC OS, iOS, and/or LEOPARD families of operating systems from APPLE CORPORATION, the FREEBSD family of operating systems, the SOLARIS family of operating systems from ORACLE CORPORATION, other operating systems, and the like.
• Theprogram modules616 may include various software, program modules, or other computer readable and/or executable instructions that configure hardware resources of thecomputer system600, such as but not limited to theprocessing unit602 described herein. Use of the term “module” refers to a defined set of computer readable instructions that transform a processor and/or other computing hardware upon execution by a processing unit, such as theprocessing unit602. In some embodiments, for example, theprogram modules616 can include theNEMA118, thecontrol application140, and/or other computer-readable instructions. These and/or other programs can be embodied in computer-readable media containing instructions that, when executed by theprocessing unit602, perform one or more of the operations and functions discussed with respect toFIG. 1 and/or themethods300 and/or400 described in detail above with respect toFIGS. 3 and 4. According to some embodiments, theprogram modules616 may be embodied in hardware, software, firmware, or any combination thereof. It should be understood that thememory604 also can be configured to store one or more instance of information and data discussed with respect toFIGS. 1, 2, 3, and/or4, such as but not limited to theAAPM114, the authorizedidentifiers116A-N, thenetwork communication service138, thenetwork service portal142, theaccess policy144, one or more instance of theequipment profile148, one or more instance of the knownTCU identifier149, theaccess probe message150, the access deniedresponse153, theaccess redirect command154, the network serviceportal response162, theaccess probe response164, thePCF145, theAMF146, or any other communication, message, data instance, instruction, and/or other data, if desired.
• By way of example, and not limitation, computer-readable media may include any available computer storage media or communication media that can be accessed by thecomputer system600. Communication media includes computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics changed or set in a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer-readable media.
• Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, Erasable Programmable ROM (“EPROM”), Electrically Erasable Programmable ROM (“EEPROM”), flash memory or other solid state memory technology, CD-ROM, digital versatile disks (“DVD”), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by thecomputer system600. In the claims, the phrases “memory”, “computer storage medium” and variations thereof does not include waves or signals per se and/or communication media.
• The user interface devices606 may include one or more devices with which a user accesses thecomputer system600. The user interface devices606 may include, but are not limited to, computers, servers, personal digital assistants, cellular phones, or any suitable computing devices that can communicate with thecomputer system600. The I/O devices608 enable a user to interface with theprogram modules616. In one embodiment, the I/O devices608 are operatively connected to an I/O controller (not shown) that enables communication with theprocessing unit602 via the system bus612. The I/O devices608 may include one or more input devices, such as, but not limited to, a keyboard, a mouse, or an electronic stylus. Further, the I/O devices608 may include one or more output devices, such as, but not limited to, a display screen or a printer.
• Thenetwork devices610 enable thecomputer system600 to communicate with other networks or remote systems via anetwork618, which may be configured substantially similar to one or more of the servingnetwork102, thenetwork130, and/or thenetwork500. Examples of thenetwork devices610 include, but are not limited to, a modem, a radio frequency (“RF”) or infrared (“IR”) transceiver, a telephonic interface, a bridge, a router, or a network card. Thenetwork618 may include a wireless network such as, but not limited to, a Wireless Local Area Network (“WLAN”) such as a WI-FI network, a Wireless Wide Area Network (“WWAN”), a Wireless Personal Area Network (“WPAN”) such as BLUETOOTH, a Wireless Metropolitan Area Network (“WMAN”) such a WiMAX network, or a cellular network. Alternatively, the network180 may be a wired network such as, but not limited to, a Wide Area Network (“WAN”) such as the Internet, a Local Area Network (“LAN”) such as the Ethernet, a wired Personal Area Network (“PAN”), or a wired Metropolitan Area Network (“MAN”). It should be understood that the examples provided are for illustration purposes only, and therefore should not be construed as limiting in any way.
• Turning now toFIG. 7, anillustrative user equipment700 and components thereof will be described. In some embodiments, thehead unit122, theTCU128, and/or other devices illustrated and described herein can be configured as and/or can have an architecture similar or identical to theuser equipment700 described herein inFIG. 7. In some embodiments, an instance of theuser equipment700 can be associated with a user of thevehicle120. It should be understood, however, that the various devices illustrated and described herein may or may not include the functionality described herein with reference toFIG. 7. While connections are not shown between the various components illustrated inFIG. 7, it should be understood that some, none, or all of the components illustrated inFIG. 7 can be configured to interact with one other to carry out various device functions. In some embodiments, the components are arranged so as to communicate via one or more busses (not shown). Thus, it should be understood thatFIG. 7 and the following description are intended to provide a general understanding of a suitable environment in which various aspects of embodiments can be implemented, and should not be construed as being limiting in any way.
• As illustrated inFIG. 7, theuser equipment700 can include adisplay702 for presenting data and information. According to various embodiments, thedisplay702 can be configured to present various graphical user interface (“GUI”) elements for presenting and/or modifying information associated with audiovisual content, an media content data stream, presenting text, images, video, virtual keypads and/or keyboards, messaging data, notification messages, metadata, internet content, device status, time, date, calendar data, device preferences, map and location data, combinations thereof, and/or the like. Theuser equipment700 also can include aprocessor704 and a memory or other data storage device (“memory”)706. Theprocessor704 can be configured to process data and/or can execute computer-executable instructions stored in thememory706. The computer-executable instructions executed by theprocessor704 can include, for example, anoperating system708, one ormore applications710 such as avehicle OTT application124 and/or a display application (not shown) that can present communications, data, and/or other computer-executable instructions stored in amemory706, and/or received by theuser equipment700. In some embodiments, theapplications710 also can include a user interface application (not illustrated inFIG. 7).
• The UI application can interface with theoperating system708 to facilitate any of the operations discussed herein and functionality for presenting audiovisual content and/or data stored at theuser equipment700 and/or stored elsewhere. It is understood that one or more instances of theoperating system708 may be included and operate within one or more systems discussed with respect to the operatingenvironment100, such as but not limited to thevehicle120, thehead unit122, and/or theTCU128. In some embodiments, theoperating system708 can include a member of the SYMBIAN OS family of operating systems from SYMBIAN LIMITED, a member of the WINDOWS MOBILE OS and/or WINDOWS PHONE OS families of operating systems from MICROSOFT CORPORATION, a member of the PALM WEBOS family of operating systems from HEWLETT PACKARD CORPORATION, a member of the BLACKBERRY OS family of operating systems from RESEARCH IN MOTION LIMITED, a member of the IOS family of operating systems from APPLE INC., a member of the ANDROID OS family of operating systems from GOOGLE INC., and/or other operating systems. These operating systems are merely illustrative of some contemplated operating systems that may be used in accordance with various embodiments of the concepts and technologies described herein and therefore should not be construed as being limiting in any way.
• Thevehicle OTT application124 can be executed by theprocessor704 to aid a user in presenting content, obtaining network access to use thenetwork communication service138, providing feedback, presenting an identifier (e.g., theTCU identifier128A), configuring settings, manipulating address book content and/or settings, multimode interaction, interacting withother applications710, and otherwise facilitating user interaction with theoperating system708, theapplications710, and/or other types or instances ofdata712 that can be stored at theuser equipment700, such as stored by thememory706. According to various embodiments, thedata712 can include, for example, instances of theapplication identifier126, theTCU identifier128A, theaccess probe message150, theprobe URL152, theaccess redirect command154, theredirect instruction156, theredirect URL158, theaccess redirect request160, the network serviceportal response162, thecontent stream166, the access deniedresponse153, theinput127, any other elements discussed with respect toFIG. 1 andFIG. 2, presence applications, visual voice mail applications, messaging applications, text-to-speech and speech-to-text applications, add-ons, plug-ins, email applications, music and/or streaming applications, video applications, camera applications, location-based service applications, power conservation applications, game applications, productivity applications, entertainment applications, enterprise applications, combinations thereof, and the like. Theapplications710, thedata712, and/or portions thereof can be stored in thememory706 and/or in afirmware714, and can be executed by theprocessor704. Thefirmware714 also can store code for execution during device power up and power down operations. It can be appreciated that thefirmware714 can be stored in a volatile or non-volatile data storage device including, but not limited to, thememory706 and/or a portion thereof.
• Theuser equipment700 also can include an input/output (“I/O”)interface716. One or more instances of the I/O interface716 can be included any computer system and/or device discussed inFIG. 1 (e.g., thehead unit122, theTCU128, theM2M server110, theOTT server131, thecore server134, etc.). The I/O interface716 can be configured to support the input/output of data such as a communication and/or message sent to and/or from the vehicle120 (and/or any data that can be sent within the vehicle120), and/or any other information or elements discussed with respect toFIGS. 1, 2, 3, and 4, user information, organization information, presence status information, user IDs, passwords, and application initiation (start-up) requests. In some embodiments, the I/O interface716 can include a hardwire connection such as a universal serial bus (“USB”) port, a mini-USB port, a micro-USB port, an audio jack, a PS2 port, an IEEE 1394 (“FIREWIRE”) port, a serial port, a parallel port, an Ethernet (RJ45) port, an RJ11 port, a proprietary port, combinations thereof, or the like. In some embodiments, theuser equipment700 can be configured to synchronize with another device to transfer content to and/or from theuser equipment700. In some embodiments, theuser equipment700 can be configured to receive updates to one or more of theapplications710 via the I/O interface716, though this is not necessarily the case. In some embodiments, the I/O interface716 accepts I/O devices such as keyboards, keypads, mice, interface tethers, printers, plotters, external storage, touch/multi-touch screens, touch pads, trackballs, joysticks, microphones, remote control devices, displays, projectors, medical equipment (e.g., stethoscopes, heart monitors, and other health metric monitors), modems, routers, external power sources, docking stations, combinations thereof, and the like. It should be appreciated that the I/O interface716 may be used for communications between theuser equipment700 and a network device or local device.
• Theuser equipment700 also can include acommunications component718. Thecommunications component718 can be configured to interface with theprocessor704 to facilitate wired and/or wireless communications with one or more networks such as the network180 and/or the RAN182 described herein. In some embodiments, other networks include networks that utilize non-cellular wireless technologies such as WI-FI or WIMAX. In some embodiments, thecommunications component718 includes a multimode communications subsystem for facilitating communications via the cellular network and one or more other networks. Thecommunications component718, in some embodiments, includes one or more transceivers. The one or more transceivers, if included, can be configured to communicate over the same and/or different wireless technology standards with respect to one another. For example, in some embodiments one or more of the transceivers of thecommunications component718 may be configured to communicate using GSM, CDMAONE, CDMA2000, LTE, and various other 2G, 3G, 4G, 5G, LTE, LTE Advanced, and greater generation technology standards. Moreover, thecommunications component718 may facilitate communications over various channel access methods (which may or may not be used by the aforementioned standards) including, but not limited to, TDMA, FDMA, W-CDMA, OFDMA, SDMA, and the like.
• In addition, thecommunications component718 may facilitate data communications using GPRS, EDGE, the HSPA protocol family including HSDPA, EUL or otherwise termed HSDPA, HSPA+, and various other current and future wireless data access standards. In the illustrated embodiment, thecommunications component718 can include a first transceiver (“TxRx”)720A that can operate in a first communications mode (e.g., GSM). Thecommunications component718 also can include an N^thtransceiver (“TxRx”)720N that can operate in a second communications mode relative to thefirst transceiver720A (e.g., UMTS). While twotransceivers720A-N (hereinafter collectively and/or generically referred to as “transceivers720”) are shown inFIG. 7, it should be appreciated that less than two, two, and/or more than two transceivers720 can be included in thecommunications component718.
• Thecommunications component718 also can include an alternative transceiver (“Alt TxRx”)722 for supporting other types and/or standards of communications. According to various contemplated embodiments, thealternative transceiver722 can communicate using various communications technologies such as, for example, WI-FI, WIMAX, BLUETOOTH, infrared, infrared data association (“IRDA”), near field communications (“NFC”), other RF technologies, combinations thereof, and the like. In some embodiments, thecommunications component718 also can facilitate reception from terrestrial radio networks, digital satellite radio networks, internet-based radio service networks, combinations thereof, and the like. Thecommunications component718 can process data from a network such as the Internet, an intranet, a broadband network, a WI-FI hotspot, an Internet service provider (“ISP”), a digital subscriber line (“DSL”) provider, a broadband provider, combinations thereof, or the like. In some embodiments, thecommunications component718 can support one or more communication modes discussed with respect toFIG. 2, such as thenetwork transmission mode221 over a Uu interface and/or thedirect transmission mode219 over a PC5 interface.
• Theuser equipment700 also can include one ormore sensors724. Thesensors724 can include temperature sensors, light sensors, air quality sensors, movement sensors, orientation sensors, noise sensors, proximity sensors, or the like. As such, it should be understood that thesensors724 can include, but are not limited to, accelerometers, magnetometers, gyroscopes, infrared sensors, noise sensors, microphones, combinations thereof, or the like. Additionally, audio capabilities for theuser equipment700 may be provided by an audio I/O component726. The audio I/O component726 of theuser equipment700 can include one or more speakers for the output of audio signals, one or more microphones for the collection and/or input of audio signals, and/or other audio input and/or output devices. In some embodiments, the audio I/O component726 maybe included as a component of thedisplay702. For example, in some embodiments, thedisplay702 can provide and present visual images and/or audio input and/or audio output. In some embodiments, the I/O interface716 can include direct communicative coupling with thedisplay702 and/or the audio I/O component726 so as to provide transfer and input and/or output of visual images (e.g., from the display702) and/or audio clips (e.g., from the audio I/O component726) to and/or from theuser equipment700.
• The illustrateduser equipment700 also can include a subscriber identity module (“SIM”)system728. TheSIM system728 can include a universal SIM (“USIM”), a universal integrated circuit card (“UICC”) and/or other identity devices. TheSIM system728 can include and/or can be connected to or inserted into an interface such as aslot interface730. In some embodiments, theslot interface730 can be configured to accept insertion of other identity cards or modules for accessing various types of networks. Additionally, or alternatively, theslot interface730 can be configured to accept multiple subscriber identity cards. Because other devices and/or modules for identifying users and/or theuser equipment700 are contemplated, it should be understood that these embodiments are illustrative, and should not be construed as being limiting in any way.
• Theuser equipment700 also can include an image capture and processing system732 (“image system”). Theimage system732 can be configured to capture or otherwise obtain photos, videos, and/or other visual information. As such, theimage system732 can include cameras, lenses, charge-coupled devices (“CCDs”), combinations thereof, or the like. Theuser equipment700 may also include avideo system734. Thevideo system734 can be configured to capture, process, record, modify, and/or store video content. Photos and videos obtained using theimage system732 and thevideo system734, respectively, may be added as message content to an MMS message, email message, and sent to another user equipment. The video and/or photo content also can be shared with other devices via various types of data transfers via wired and/or wireless user equipment as described herein.
• Theuser equipment700 also can include one ormore location components736. Thelocation components736 can be configured to send and/or receive signals to determine a geographic location of theuser equipment700. According to various embodiments, thelocation components736 can send and/or receive signals from global positioning system (“GPS”) devices, assisted-GPS (“A-GPS”) devices, WI-FI/WIMAX and/or cellular network triangulation data, combinations thereof, and the like. Thelocation component736 also can be configured to communicate with thecommunications component718 to retrieve triangulation data for determining a location of theuser equipment700. In some embodiments, thelocation component736 can interface with cellular network nodes, telephone lines, satellites, location transmitters and/or beacons, wireless network transmitters and receivers, combinations thereof, and the like. In some embodiments, thelocation component736 can include and/or can communicate with one or more of thesensors724 such as a compass, an accelerometer, and/or a gyroscope to determine the orientation of theuser equipment700. Using thelocation component736, theuser equipment700 can generate and/or receive data to identify its geographic location, or to transmit data used by other devices to determine the location of theuser equipment700. Thelocation component736 may include multiple components for determining the location and/or orientation of theuser equipment700.
• The illustrateduser equipment700 also can include apower source738. Thepower source738 can include one or more batteries, power supplies, power cells, and/or other power subsystems including alternating current (“AC”) and/or direct current (“DC”) power devices. Thepower source738 also can interface with an external power system or charging equipment via a power I/O component740. Because theuser equipment700 can include additional and/or alternative components, the above embodiment should be understood as being illustrative of one possible operating environment for various embodiments of the concepts and technologies described herein. The described embodiment of theuser equipment700 is illustrative, and therefore should not be construed as being limiting in any way.
• Based on the foregoing, it should be appreciated that concepts and technologies directed to connected vehicle network access optimization have been disclosed herein. Although the subject matter presented herein has been described in language specific to computer structural features, methodological and transformative acts, specific computing machinery, and computer-readable mediums, it is to be understood that the concepts and technologies disclosed herein are not necessarily limited to the specific features, acts, or mediums described herein. Rather, the specific features, acts and mediums are disclosed as example forms of implementing the concepts and technologies disclosed herein.
• The subject matter described above is provided by way of illustration only and should not be construed as limiting. Various modifications and changes may be made to the subject matter described herein without following the example embodiments and applications illustrated and described, and without departing from the true spirit and scope of the embodiments of the concepts and technologies disclosed herein.

Claims (20)

What is claimed is:

1. A telematics control unit comprising:

a processor; and

a memory storing computer-executable instructions that, in response to execution by the processor, cause the processor to perform operations comprising:

generating an access probe message directed to a core server associated with a network communication service that supports operation of a vehicle over-the-top application executing on a head unit of a vehicle, wherein the access probe message requests access to the network communication service,

sending the access probe message,

receiving, in response to the access probe message, an access redirect command from a machine-to-machine platform that controls access to the network communication service, wherein the access redirect command provides the head unit of the vehicle with a one-time bypass of the machine-to-machine platform so as to enable the vehicle to bypass the machine-to-machine platform and access the core server associated with the network communication service directly via a network service portal to become authorized to access the network communication service, and

generating, in response to the access redirect command, an access redirect request directed to the core server associated with the network communication service, wherein the access redirect request requests authorization to use the network communication service.

2. The telematics control unit ofclaim 1, wherein the access probe message comprises a probe uniform resource locator that is associated with the network communication service.

3. The telematics control unit ofclaim 1, wherein the access redirect command comprises a redirect uniform resource locator that points to the network service portal.

4. The telematics control unit ofclaim 3, wherein the access redirect request comprises the redirect uniform resource locator from the access redirect command.

5. The telematics control unit ofclaim 1, wherein receiving the access redirect command from the machine-to-machine platform is in response to the machine-to-machine platform determining that the telematics control unit is not authorized to access the network communication service.

6. The telematics control unit ofclaim 5, wherein determining that the telematics control unit is not authorized to access the network communication service is based on the telematics control unit having a telematics control unit identifier that does not correspond with an authorized identifier of an authorized access policy map.

7. The telematics control unit ofclaim 1, wherein the operations further comprise providing the access redirect request to the core server, wherein the access redirect request is not intercepted by the machine-to-machine platform.

8. A method comprising:

generating, by a telematics control unit, an access probe message directed to a core server associated with a network communication service that supports operation of a vehicle over-the-top application executing on a head unit of a vehicle, wherein the access probe message requests access to the network communication service;

sending, by the telematics control unit, the access probe message;

receiving, by the telematics control unit in response to the access probe message, an access redirect command from a machine-to-machine platform that controls access to the network communication service, wherein the access redirect command provides the head unit of the vehicle with a one-time bypass of the machine-to-machine platform so as to enable the vehicle to bypass the machine-to-machine platform and access the core server associated with the network communication service directly via a network service portal to become authorized to access the network communication service; and

generating, by the telematics control unit, in response to the access redirect command, an access redirect request directed to the core server associated with the network communication service, wherein the access redirect request requests authorization to use the network communication service.

9. The method ofclaim 8, wherein the access probe message comprises a probe uniform resource locator that is associated with the network communication service.

10. The method ofclaim 8, wherein the access redirect command comprises a redirect uniform resource locator that points to the network service portal.

11. The method ofclaim 10, wherein the access redirect request comprises the redirect uniform resource locator from the access redirect command.

12. The method ofclaim 8, wherein receiving the access redirect command from the machine-to-machine platform is in response to the machine-to-machine platform determining that the telematics control unit is not authorized to access the network communication service.

13. The method ofclaim 12, wherein determining that the telematics control unit is not authorized to access the network communication service is based on the telematics control unit having a telematics control unit identifier that does not correspond with an authorized identifier of an authorized access policy map.

14. The method ofclaim 8, wherein the method further comprises providing the access redirect request to the core server, wherein the access redirect request is not intercepted by the machine-to-machine platform.

15. A computer storage medium having computer-executable instructions stored thereon that, in response to execution by a processor of a telematics control unit, causes the processor to perform operations comprising:

generating an access probe message directed to a core server associated with a network communication service that supports operation of a vehicle over-the-top application executing on a head unit of a vehicle, wherein the access probe message requests access to the network communication service;

sending the access probe message;

receiving, in response to the access probe message, an access redirect command from a machine-to-machine platform that controls access to the network communication service, wherein the access redirect command provides the head unit of the vehicle with a one-time bypass of the machine-to-machine platform so as to enable the vehicle to bypass the machine-to-machine platform and access the core server associated with the network communication service directly via a network service portal to become authorized to access the network communication service; and

generating, in response to the access redirect command, an access redirect request directed to the core server associated with the network communication service, wherein the access redirect request requests authorization to use the network communication service.

16. The computer storage medium ofclaim 15, wherein the access probe message comprises a probe uniform resource locator that is associated with the network communication service.

17. The computer storage medium ofclaim 15, wherein the access redirect command comprises a redirect uniform resource locator that points to the network service portal.

18. The computer storage medium ofclaim 17, wherein the access redirect request comprises the redirect uniform resource locator from the access redirect command.

19. The computer storage medium ofclaim 15, wherein receiving the access redirect command from the machine-to-machine platform is in response to the machine-to-machine platform determining that the telematics control unit is not authorized to access the network communication service, and wherein determining that the telematics control unit is not authorized to access the network communication service is based on the telematics control unit having a telematics control unit identifier that does not correspond with an authorized identifier of an authorized access policy map.

20. The computer storage medium ofclaim 15, wherein the operations further comprise providing the access redirect request to the core server, wherein the access redirect request is not intercepted by the machine-to-machine platform.

Images